draft-ietf-capwap-protocol-specification-05.txt   draft-ietf-capwap-protocol-specification-06.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: September 5, 2007 M. Montemurro, Editor Expires: September 11, 2007 M. Montemurro, Editor
Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
March 4, 2007
CAPWAP Protocol Specification CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-05 draft-ietf-capwap-protocol-specification-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2007. This Internet-Draft will expire on September 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF
CAPWAP working group protocol requirements. The CAPWAP protocol is CAPWAP working group protocol requirements. The CAPWAP protocol is
designed to be flexible, allowing it to be used for a variety of designed to be flexible, allowing it to be used for a variety of
wireless technologies. This document describes the base CAPWAP wireless technologies. This document describes the base CAPWAP
protocol. The CAPWAP protocol binding which defines extensions for protocol. The CAPWAP protocol binding which defines extensions for
use with the IEEE 802.11 wireless LAN protocol is available in [13]. use with the IEEE 802.11 wireless LAN protocol is available in [14].
Extensions are expected to be defined to enable use of the CAPWAP Extensions are expected to be defined to enable use of the CAPWAP
protocol with additional wireless technologies. protocol with additional wireless technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Conventions used in this document . . . . . . . . . . . . 8 1.2. Conventions used in this document . . . . . . . . . . . . 8
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 14 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 14
2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 16 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 16
2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 27 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 27
2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 29 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 29
2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 29 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 29
2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 30 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 30
2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 31 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 31
2.4.4. DTLS EndPoint Authentication and Authorization . . . 32 2.4.4. DTLS EndPoint Authentication and Authorization . . . 32
3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 36 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 36
3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 36 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 36
3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 36 3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 36
3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 37 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 36
4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 38 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 38
4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . . 40 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 39
4.2. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 40 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . . 41
4.3. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 44 4.2. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 44 4.3. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 45
4.3.2. Data Payload . . . . . . . . . . . . . . . . . . . . 45 4.3.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 45
4.3.3. Establishment of a DTLS Data Channel . . . . . . . . 46 4.3.2. Data Payload . . . . . . . . . . . . . . . . . . . . 46
4.4. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 46 4.3.3. Establishment of a DTLS Data Channel . . . . . . . . 47
4.4.1. Control Message Format . . . . . . . . . . . . . . . 47 4.4. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 47
4.4.2. Control Message Quality of Service . . . . . . . . . 49 4.4.1. Control Message Format . . . . . . . . . . . . . . . 48
4.4.3. Retransmissions . . . . . . . . . . . . . . . . . . . 50 4.4.2. Control Message Quality of Service . . . . . . . . . 51
4.5. CAPWAP Protocol Message Elements . . . . . . . . . . . . 50 4.4.3. Retransmissions . . . . . . . . . . . . . . . . . . . 51
4.5.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 53 4.5. CAPWAP Protocol Message Elements . . . . . . . . . . . . 52
4.5.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 54 4.5.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 54
4.5.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 55 4.5.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 56
4.5.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 57
4.5.5. AC Name with Index . . . . . . . . . . . . . . . . . 56 4.5.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 57
4.5.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 56 4.5.5. AC Name with Index . . . . . . . . . . . . . . . . . 58
4.5.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 57 4.5.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 58
4.5.8. Add Station . . . . . . . . . . . . . . . . . . . . . 57 4.5.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 59
4.5.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 58 4.5.8. Add Station . . . . . . . . . . . . . . . . . . . . . 59
4.5.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 58 4.5.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 60
4.5.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 59 4.5.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 61
4.5.12. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 60 4.5.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 61
4.5.13. Data Transfer Data . . . . . . . . . . . . . . . . . 60 4.5.12. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 62
4.5.14. Data Transfer Mode . . . . . . . . . . . . . . . . . 61 4.5.13. Data Transfer Data . . . . . . . . . . . . . . . . . 63
4.5.15. Decryption Error Report . . . . . . . . . . . . . . . 61 4.5.14. Data Transfer Mode . . . . . . . . . . . . . . . . . 63
4.5.16. Decryption Error Report Period . . . . . . . . . . . 62 4.5.15. Decryption Error Report . . . . . . . . . . . . . . . 64
4.5.17. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 62 4.5.16. Decryption Error Report Period . . . . . . . . . . . 64
4.5.18. Delete Station . . . . . . . . . . . . . . . . . . . 63 4.5.17. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 65
4.5.19. Delete Static MAC ACL Entry . . . . . . . . . . . . . 63 4.5.18. Delete Station . . . . . . . . . . . . . . . . . . . 66
4.5.20. Discovery Type . . . . . . . . . . . . . . . . . . . 64 4.5.19. Delete Static MAC ACL Entry . . . . . . . . . . . . . 66
4.5.21. Duplicate IPv4 Address . . . . . . . . . . . . . . . 65 4.5.20. Discovery Type . . . . . . . . . . . . . . . . . . . 67
4.5.22. Duplicate IPv6 Address . . . . . . . . . . . . . . . 65 4.5.21. Duplicate IPv4 Address . . . . . . . . . . . . . . . 68
4.5.23. Idle Timeout . . . . . . . . . . . . . . . . . . . . 66 4.5.22. Duplicate IPv6 Address . . . . . . . . . . . . . . . 69
4.5.24. Image Data . . . . . . . . . . . . . . . . . . . . . 67 4.5.23. Idle Timeout . . . . . . . . . . . . . . . . . . . . 70
4.5.25. Image Identifier . . . . . . . . . . . . . . . . . . 67 4.5.24. Image Data . . . . . . . . . . . . . . . . . . . . . 70
4.5.26. Image Information . . . . . . . . . . . . . . . . . . 68 4.5.25. Image Identifier . . . . . . . . . . . . . . . . . . 71
4.5.27. Initiate Download . . . . . . . . . . . . . . . . . . 69 4.5.26. Image Information . . . . . . . . . . . . . . . . . . 71
4.5.28. Location Data . . . . . . . . . . . . . . . . . . . . 69 4.5.27. Initiate Download . . . . . . . . . . . . . . . . . . 72
4.5.29. Maximum Message Length . . . . . . . . . . . . . . . 69 4.5.28. Location Data . . . . . . . . . . . . . . . . . . . . 72
4.5.30. MTU Discovery Padding . . . . . . . . . . . . . . . . 70 4.5.29. Maximum Message Length . . . . . . . . . . . . . . . 73
4.5.31. Radio Administrative State . . . . . . . . . . . . . 70 4.5.30. MTU Discovery Padding . . . . . . . . . . . . . . . . 73
4.5.32. Radio Operational State . . . . . . . . . . . . . . . 71 4.5.31. Radio Administrative State . . . . . . . . . . . . . 74
4.5.33. Result Code . . . . . . . . . . . . . . . . . . . . . 72 4.5.32. Radio Operational State . . . . . . . . . . . . . . . 74
4.5.34. Returned Message Element . . . . . . . . . . . . . . 73 4.5.33. Result Code . . . . . . . . . . . . . . . . . . . . . 75
4.5.35. Session ID . . . . . . . . . . . . . . . . . . . . . 74 4.5.34. Returned Message Element . . . . . . . . . . . . . . 77
4.5.36. Statistics Timer . . . . . . . . . . . . . . . . . . 74 4.5.35. Session ID . . . . . . . . . . . . . . . . . . . . . 77
4.5.37. Vendor Specific Payload . . . . . . . . . . . . . . . 75 4.5.36. Statistics Timer . . . . . . . . . . . . . . . . . . 78
4.5.38. WTP Board Data . . . . . . . . . . . . . . . . . . . 75 4.5.37. Vendor Specific Payload . . . . . . . . . . . . . . . 78
4.5.39. WTP Descriptor . . . . . . . . . . . . . . . . . . . 76 4.5.38. WTP Board Data . . . . . . . . . . . . . . . . . . . 79
4.5.40. WTP Fallback . . . . . . . . . . . . . . . . . . . . 78 4.5.39. WTP Descriptor . . . . . . . . . . . . . . . . . . . 80
4.5.41. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 79 4.5.40. WTP Fallback . . . . . . . . . . . . . . . . . . . . 81
4.5.42. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 80 4.5.41. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 82
4.5.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 80 4.5.42. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 83
4.5.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 81 4.5.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 83
4.5.45. WTP Operational Statistics . . . . . . . . . . . . . 81 4.5.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 84
4.5.46. WTP Radio Statistics . . . . . . . . . . . . . . . . 82 4.5.45. WTP Operational Statistics . . . . . . . . . . . . . 84
4.5.47. WTP Reboot Statistics . . . . . . . . . . . . . . . . 83 4.5.46. WTP Radio Statistics . . . . . . . . . . . . . . . . 85
4.5.48. WTP Static IP Address Information . . . . . . . . . . 84 4.5.47. WTP Reboot Statistics . . . . . . . . . . . . . . . . 86
4.6. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 85 4.5.48. WTP Static IP Address Information . . . . . . . . . . 88
4.6.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 85 4.6. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 89
4.6.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 85 4.6.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 89
4.6.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 86 4.6.2. DataChannelDeadInterval . . . . . . . . . . . . . . . 89
4.6.4. DiscoveryInterval . . . . . . . . . . . . . . . . . . 86 4.6.3. DiscoveryInterval . . . . . . . . . . . . . . . . . . 89
4.6.5. DTLSRehandshake . . . . . . . . . . . . . . . . . . . 86 4.6.4. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 89
4.6.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 86 4.6.5. EchoInterval . . . . . . . . . . . . . . . . . . . . 89
4.6.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 86 4.6.6. KeyLifetime . . . . . . . . . . . . . . . . . . . . . 90
4.6.8. KeyLifetime . . . . . . . . . . . . . . . . . . . . . 86 4.6.7. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 90
4.6.9. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 87 4.6.8. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 90
4.6.10. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 87 4.6.9. NeighborDeadInterval . . . . . . . . . . . . . . . . 90
4.6.11. NeighborDeadInterval . . . . . . . . . . . . . . . . 87 4.6.10. ResponseTimeout . . . . . . . . . . . . . . . . . . . 90
4.6.12. ResponseTimeout . . . . . . . . . . . . . . . . . . . 87 4.6.11. RetransmitInterval . . . . . . . . . . . . . . . . . 90
4.6.13. RetransmitInterval . . . . . . . . . . . . . . . . . 87 4.6.12. SilentInterval . . . . . . . . . . . . . . . . . . . 91
4.6.14. SilentInterval . . . . . . . . . . . . . . . . . . . 87 4.6.13. StatisticsTimer . . . . . . . . . . . . . . . . . . . 91
4.6.15. StatisticsTimer . . . . . . . . . . . . . . . . . . . 88 4.6.14. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 91
4.6.16. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 88 4.6.15. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 91
4.6.17. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 88 4.7. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 91
4.7. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 88 4.7.1. AdminState . . . . . . . . . . . . . . . . . . . . . 91
4.7.1. AdminState . . . . . . . . . . . . . . . . . . . . . 88 4.7.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 91
4.7.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 88 4.7.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 92
4.7.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 88 4.7.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 92
4.7.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 88 4.7.5. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 92
4.7.5. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 89 4.7.6. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 92
4.7.6. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 89 4.7.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 92
4.7.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 89 4.7.8. ReportInterval . . . . . . . . . . . . . . . . . . . 92
4.7.8. ReportInterval . . . . . . . . . . . . . . . . . . . 89 4.7.9. RetransmitCount . . . . . . . . . . . . . . . . . . . 92
4.7.9. RetransmitCount . . . . . . . . . . . . . . . . . . . 89 4.7.10. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 92
4.7.10. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 89 4.8. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 92
4.8. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 89 4.8.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 93
4.8.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 89 4.8.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 93
4.8.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 89 4.8.3. LastRebootReason . . . . . . . . . . . . . . . . . . 93
4.8.3. LastRebootReason . . . . . . . . . . . . . . . . . . 90 4.8.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 93
4.8.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 90 4.8.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 93
4.8.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 90 4.8.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 93
4.8.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 90 4.8.7. Static ACL Table . . . . . . . . . . . . . . . . . . 93
4.8.7. Static ACL Table . . . . . . . . . . . . . . . . . . 90 4.8.8. Static IP Address . . . . . . . . . . . . . . . . . . 93
4.8.8. Static IP Address . . . . . . . . . . . . . . . . . . 90 4.8.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 93
4.8.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 90 4.8.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 93
4.8.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 90 4.8.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 94
4.8.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 90 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 95
5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 91 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 95
5.1. Discovery Request Message . . . . . . . . . . . . . . . . 91 5.2. Discovery Response Message . . . . . . . . . . . . . . . 96
5.2. Discovery Response Message . . . . . . . . . . . . . . . 92 5.3. Primary Discovery Request Message . . . . . . . . . . . . 97
5.3. Primary Discovery Request Message . . . . . . . . . . . . 93 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 98
5.4. Primary Discovery Response . . . . . . . . . . . . . . . 94 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 100
6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 95 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 100
6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 95 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 101
6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 96 7. Control Channel Management . . . . . . . . . . . . . . . . . 103
7. Control Channel Management . . . . . . . . . . . . . . . . . 98 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 103
7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 98 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 103
7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 98 8. WTP Configuration Management . . . . . . . . . . . . . . . . 105
8. WTP Configuration Management . . . . . . . . . . . . . . . . 100 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 105
8.1. Configuration Consistency . . . . . . . . . . . . . . . . 100 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 106
8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 101 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 106
8.2. Configuration Status . . . . . . . . . . . . . . . . . . 101 8.3. Configuration Status Response . . . . . . . . . . . . . . 107
8.3. Configuration Status Response . . . . . . . . . . . . . . 102 8.4. Configuration Update Request . . . . . . . . . . . . . . 108
8.4. Configuration Update Request . . . . . . . . . . . . . . 103 8.5. Configuration Update Response . . . . . . . . . . . . . . 109
8.5. Configuration Update Response . . . . . . . . . . . . . . 104 8.6. Change State Event Request . . . . . . . . . . . . . . . 109
8.6. Change State Event Request . . . . . . . . . . . . . . . 104 8.7. Change State Event Response . . . . . . . . . . . . . . . 110
8.7. Change State Event Response . . . . . . . . . . . . . . . 105 8.8. Clear Configuration Request . . . . . . . . . . . . . . . 111
8.8. Clear Configuration Request . . . . . . . . . . . . . . . 106 8.9. Clear Configuration Response . . . . . . . . . . . . . . 111
8.9. Clear Configuration Response . . . . . . . . . . . . . . 106 9. Device Management Operations . . . . . . . . . . . . . . . . 112
9. Device Management Operations . . . . . . . . . . . . . . . . 107 9.1. Firmware Management . . . . . . . . . . . . . . . . . . . 112
9.1. Firmware Management . . . . . . . . . . . . . . . . . . . 107 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 115
9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 110 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 116
9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 111 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . . 117
9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . . 112 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 117
9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 112 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . . 118
9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . . 113 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 119
9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 114 9.6. Data Transfer Request . . . . . . . . . . . . . . . . . . 119
9.6. Data Transfer Request . . . . . . . . . . . . . . . . . . 114 9.7. Data Transfer Response . . . . . . . . . . . . . . . . . 119
9.7. Data Transfer Response . . . . . . . . . . . . . . . . . 114 10. Station Session Management . . . . . . . . . . . . . . . . . 121
10. Station Session Management . . . . . . . . . . . . . . . . . 116 10.1. Station Configuration Request . . . . . . . . . . . . . . 121
10.1. Station Configuration Request . . . . . . . . . . . . . . 116 10.2. Station Configuration Response . . . . . . . . . . . . . 121
10.2. Station Configuration Response . . . . . . . . . . . . . 116 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 122
11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 117 12. Security Considerations . . . . . . . . . . . . . . . . . . . 124
12. Security Considerations . . . . . . . . . . . . . . . . . . . 119 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 124
12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 119 12.1.1. Converting Protected Data into Unprotected Data . . . 125
12.1.1. Converting Protected Data into Unprotected Data . . . 120
12.1.2. Converting Unprotected Data into Protected Data 12.1.2. Converting Unprotected Data into Protected Data
(Insertion) . . . . . . . . . . . . . . . . . . . . . 120 (Insertion) . . . . . . . . . . . . . . . . . . . . . 125
12.1.3. Deletion of Protected Records . . . . . . . . . . . . 120 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 125
12.1.4. Insertion of Unprotected Records . . . . . . . . . . 120 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 125
12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 120 12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 125
12.3. Discovery Attacks . . . . . . . . . . . . . . . . . . . . 121 12.3. Discovery Attacks . . . . . . . . . . . . . . . . . . . . 126
12.4. Interference with a DTLS Session . . . . . . . . . . . . 121 12.4. Interference with a DTLS Session . . . . . . . . . . . . 126
12.5. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 121 12.5. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 126
12.6. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 122 12.6. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 127
12.7. AAA Security . . . . . . . . . . . . . . . . . . . . . . 123 12.7. AAA Security . . . . . . . . . . . . . . . . . . . . . . 128
13. Management Considerations . . . . . . . . . . . . . . . . . . 124 13. Management Considerations . . . . . . . . . . . . . . . . . . 129
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130
14.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 125 14.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 130
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 126 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 131
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 132
16.1. Normative References . . . . . . . . . . . . . . . . . . 127 16.1. Normative References . . . . . . . . . . . . . . . . . . 132
16.2. Informational References . . . . . . . . . . . . . . . . 127 16.2. Informational References . . . . . . . . . . . . . . . . 133
16.3. Informational References . . . . . . . . . . . . . . . . 128 16.3. Informational References . . . . . . . . . . . . . . . . 133
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 134
Intellectual Property and Copyright Statements . . . . . . . . . 130 Intellectual Property and Copyright Statements . . . . . . . . . 135
1. Introduction 1. Introduction
This document describes the CAPWAP Protocol, a standard, This document describes the CAPWAP Protocol, a standard,
interoperable protocol which enables an Access Controller (AC) to interoperable protocol which enables an Access Controller (AC) to
manage a collection of Wireless Termination Points (WTPs). The manage a collection of Wireless Termination Points (WTPs). The
CAPWAP protocol is defined to be independent of layer 2 technology. CAPWAP protocol is defined to be independent of layer 2 technology.
The emergence of centralized IEEE 802.11 Wireless Local Area Network The emergence of centralized IEEE 802.11 Wireless Local Area Network
(WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by
an Access Controller (AC) suggested that a standards based, an Access Controller (AC) suggested that a standards based,
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 [13] to support use contained). An IEEE 802.11 binding is defined in [14] to support use
of the CAPWAP protocol with IEEE 802.11 WLAN networks. of the 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 RF interfaces controlled by the AC. The CAPWAP
protocol supports two modes of operation: Split and Local MAC. In protocol supports two modes of operation: Split and Local MAC. In
Split MAC mode all L2 wireless data and management frames are Split MAC mode all L2 wireless data and management frames are
encapsulated via the CAPWAP protocol and exchanged between the AC and encapsulated via the CAPWAP protocol and exchanged between the AC and
the WTP. As shown in Figure 1, the wireless frames received from a the WTP. As shown in Figure 1, the wireless frames received from a
mobile device, which is referred to in this specification as a mobile device, which is referred to in this specification as a
skipping to change at page 12, line 41 skipping to change at page 12, line 41
Discovery, Primary Discovery and Join Request and Response Discovery, Primary Discovery and Join Request and Response
messages, indicating the binding specific radio types supported at messages, indicating the binding specific radio types supported at
the WTP and AC. the WTP 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 [13], begins with "IEEE 802.11". provided in [14], begins with "IEEE 802.11".
The CAPWAP binding concept is also used in any future specifications The CAPWAP binding concept is also used in any future specifications
that add functionality to either the base CAPWAP protocol that add functionality to either the base CAPWAP protocol
specification, or any published CAPWAP binding specification. A specification, or any published CAPWAP binding specification. A
separate WTP Radio Information message element MUST be created to separate WTP Radio Information message element MUST be created to
properly advertise support for the specification. This mechanism properly advertise support for the specification. This mechanism
allows for future protocol extensibility, while providing the allows for future protocol extensibility, while providing the
necessary capabilities advertisement, through the WTP Radio necessary capabilities advertisement, through the WTP Radio
Information message element, to ensure WTP/AC interoperability. Information message element, to ensure WTP/AC interoperability.
skipping to change at page 18, line 29 skipping to change at page 18, line 29
qualifiers in the DTLSListen command to only accept session qualifiers in the DTLSListen command to only accept session
requests from specific WTPs. requests from specific WTPs.
Discovery to DTLS Setup (f): This transition occurs to establish a Discovery to DTLS Setup (f): This transition occurs to establish a
secure DTLS session with the peer. secure DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart WTP: The WTP initiates this transition by invoking the DTLSStart
command (see Section 2.3.2.1), which starts the DTLS session command (see Section 2.3.2.1), which starts the DTLS session
establishment with the chosen AC. The decision of which AC to establishment with the chosen AC. The decision of which AC to
connect to is the result of the discovery phase, which is connect to is the result of the discovery phase, which is
described in Section 3.2. described in Section 3.3.
AC: The AC initiates this transition by invoking the DTLSListen AC: The AC initiates this transition by invoking the DTLSListen
command (see Section 2.3.2.1), which informs the DTLS stack command (see Section 2.3.2.1), which informs the DTLS stack
that it is willing to listen for an incoming session. The AC that it is willing to listen for an incoming session. The AC
MAY have maintained state information when it received the MAY have maintained state information when it received the
Discovery Request message to provide optional qualifiers in the Discovery Request message to provide optional qualifiers in the
DTLSListen command to only accept session requests from a DTLSListen command to only accept session requests from a
specific WTP. Note that maintaining state information based on specific WTP. Note that maintaining state information based on
an unsecured Discovery Request message MAY lead to a Denial of an unsecured Discovery Request message MAY lead to a Denial of
Service attack. Therefore the AC SHOULD ensure that the state Service attack. Therefore the AC SHOULD ensure that the state
skipping to change at page 23, line 34 skipping to change at page 23, line 34
following DTLS notifications: DTLSAborted, following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if it Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. receives frequent DTLSDecapFailure notifications.
Configure to Data Check (t): This state transition occurs when the Configure to Data Check (t): 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
initializes the HeartBeat timer (see Section 4.6), and initializes the EchoInterval timer (see Section 4.6), and
transmits the Change State Event Request message (see transmits the Change State Event Request message (see
Section 8.6). Section 8.6).
AC: This state transition occurs when the AC receives the Change AC: This state transition occurs when the AC receives the Change
State Event Request message (see Section 8.6) from the WTP. State Event Request message (see Section 8.6) from the WTP.
The AC responds with a Change State Event Response message (see The AC responds with a Change State Event Response message (see
Section 8.7). The AC must start the NeighborDeadInterval timer Section 8.7). The AC must start the NeighborDeadInterval timer
(see Section 4.6). (see Section 4.6).
Data Check to Run (u): This state transition occurs when the linkage Data Check to Run (u): This state transition occurs when the linkage
skipping to change at page 28, line 9 skipping to change at page 28, line 9
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 3 becomes the below occurs, the target CAPWAP state shown in Figure 3 becomes the
current state. current state.
Below is a list of the API notifications: Below is a list of the API notifications:
o DTLSIncomingSession 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
that a secure channel now exists, using the parameters provided that a secure channel now exists, using the parameters provided
during the DTLS initialization process. When this notification is during the DTLS initialization process. When this notification is
received, the FailedDTLSSessionCount counter is reset to zero. received, the FailedDTLSSessionCount counter is reset to zero.
skipping to change at page 31, line 4 skipping to change at page 31, line 4
return some unique identifier to the CAPWAP module to enable return some unique identifier to the CAPWAP module to enable
subsequent establishment of a DTLS-encrypted data channel, if subsequent establishment of a DTLS-encrypted data channel, if
necessary. necessary.
2.4.2. DTLS Session Establishment 2.4.2. DTLS Session Establishment
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 the AC to connect to. 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 receiving the DTLSIncomingSession WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize
DTLS notification, the AC sets the WaitDTLS timer. If the DTLS notification, the AC sets the WaitDTLS timer. If the
DTLSEstablished notification is not received prior to timer DTLSEstablished notification is not received prior to timer
expiration, the DTLS session is aborted by issuing the 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 does not respond to any DTLS messages sent by the WTP, the If the AC does not respond to any DTLS messages sent by the WTP, the
skipping to change at page 32, line 44 skipping to change at page 32, line 44
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 preshared
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
Note that only block ciphers are currently recommended for use with Note that only block ciphers are currently recommended for use with
DTLS. To understand the reasoning behind this, see [16]. At DTLS. To understand the reasoning behind this, see [17]. At
present, the following algorithms MUST be supported when using present, the following algorithms MUST be supported when using
certificates for CAPWAP authentication: certificates for CAPWAP authentication:
o TLS_RSA_WITH_AES_128_CBC_SHA o TLS_RSA_WITH_AES_128_CBC_SHA
The following algorithms SHOULD be supported when using certificates: The following algorithms SHOULD be supported when using certificates:
o TLS_DH_RSA_WITH_AES_128_CBC_SHA o TLS_DH_RSA_WITH_AES_128_CBC_SHA
The following algorithms MAY be supported when using certificates: The following algorithms MAY be supported when using certificates:
skipping to change at page 36, line 7 skipping to change at page 36, line 7
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
The CAPWAP protocol uses UDP as a transport protocol, and can be used Communication between a WTP and an AC is established according to the
with IPv4 or IPv6. This section details the specifics of how the standard UDP client/server model. The CAPWAP protocol supports two
CAPWAP protocol works with IP. different transport protocols. When used over IPv4, the UDP protocol
is utilized. When CAPWAP is used over IPv6, the UDP-Lite RFC 3828
[13] is used. This section details the specifics of how the CAPWAP
protocol works with IP.
3.1. UDP Transport 3.1. UDP Transport
Communication between a WTP and an AC is established according to the One of the CAPWAP protocol requirements is to allow a WTP to reside
standard UDP client/server model. One of the CAPWAP protocol behind a firewall and/or Network Address Translation (NAT) device.
requirements is to allow a WTP to reside behind a firewall and/or Since the connection is initiated by the WTP (client) to the well-
Network Address Translation (NAT) device. Since the connection is known UDP port of the AC (server), the use of UDP is a logical
initiated by the WTP (client) to the well-known UDP port of the AC choice. The UDP checksum field in CAPWAP packets MUST be set to
(server), the use of UDP is a logical choice. zero.
CAPWAP protocol control packets sent between the WTP and the AC use CAPWAP protocol control packets sent between the WTP and the AC use
well known UDP port [to be IANA assigned]. CAPWAP protocol data well known UDP port [to be IANA assigned]. CAPWAP protocol data
packets sent between the WTP and the AC use UDP port [to be IANA packets sent between the WTP and the AC use UDP port [to be IANA
assigned]. assigned].
3.2. AC Discovery 3.2. UDP-Lite Transport
When CAPWAP is run over IPv6, the UDP-Lite is used as the transport.
The reason for using UDP-Lite is because when UDP is run over IPv6,
it MUST NOT have its checksum field set to zero, which increases the
processing cost for each CAPWAP packet. When UDP-Lite is used, the
checksum field MUST have a coverage of 8 RFC 3828 [13].
As defined in RFC 3828 [13], UDP-Lite uses the same port assignments
as UDP.
3.3. AC Discovery
The AC discovery phase allows the WTP to determine which ACs are 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 chose 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
skipping to change at page 37, line 38 skipping to change at page 38, line 4
The Name to IP Address mapping is handled via the Discovery message The Name to IP Address mapping is handled via the Discovery message
exchange, in which the ACs provide their identity in the AC Name (see exchange, in which the ACs provide their identity in the AC Name (see
Section 4.5.4) message element in the Discovery Response message. Section 4.5.4) message element in the Discovery Response 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.3. 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 "middle box"
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 configuration. in any network configuration.
skipping to change at page 39, line 20 skipping to change at page 40, line 20
DTLS Secured CAPWAP Data Packet: DTLS Secured CAPWAP Data Packet:
+-------------------------------------------------------+ +-------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
| Hdr | Hdr | Preamble| Hdr | Hdr | Payload | Trlr | | Hdr | Hdr | Preamble| Hdr | Hdr | Payload | Trlr |
+-------------------------------------------------------+ +-------------------------------------------------------+
\------ authenticated -----/ \------ authenticated -----/
\------- encrypted --------/ \------- encrypted --------/
UDP Header: All CAPWAP packets are encapsulated within UDP. Section UDP Header: All CAPWAP packets are encapsulated within UDP. Section
Section 3.1 defines the specific UDP usage. Section 3 defines the specific UDP usage.
CAPWAP Preamble: All CAPWAP protocol packets are prefixed with the CAPWAP Preamble: All CAPWAP protocol packets are prefixed with the
CAPWAP Preamble header, used to identify the frame type that CAPWAP Preamble header, used to identify the frame type that
follows. The CAPWAP Preamble header is defined in Section 4.1. follows. The CAPWAP Preamble header is defined in Section 4.1.
DTLS Header: The DTLS header provides authentication and encrytion DTLS Header: The DTLS header provides authentication and encrytion
services to the CAPWAP payload it encapsulates. This protocol is services to the CAPWAP payload it encapsulates. This protocol is
defined in RFC 4347 [9]. defined in RFC 4347 [9].
CAPWAP Header: All CAPWAP protocol packets use a common header that CAPWAP Header: All CAPWAP protocol packets use a common header that
skipping to change at page 40, line 36 skipping to change at page 41, line 36
0 - Clear text. If the packet is received on the data UDP port, 0 - Clear text. If the packet is received on the data UDP port,
the CAPWAP stack MUST treat the packet as a clear text CAPWAP the CAPWAP stack MUST treat the packet as a clear text CAPWAP
data packet. If received on the control UDP port, the CAPWAP data packet. If received on the control UDP port, the CAPWAP
stack MUST treat the packet as a clear text CAPWAP control stack MUST treat the packet as a clear text CAPWAP control
packet. If the control packet is not a Discovery Request or packet. If the control packet is not a Discovery Request or
Response packet, the packet MUST be dropped. Response packet, the packet MUST be dropped.
1 - DTLS Payload. The packet is a DTLS packet and MAY be a data 1 - DTLS Payload. The packet is a DTLS packet and MAY be a data
or control packet, based on the UDP port it was received on or control packet, based on the UDP port it was received on
(see Section 3.1). (see Section 3).
Reserved: The 24-bit field is reserved for future use. All Reserved: The 24-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.
4.2. CAPWAP Header 4.2. CAPWAP Header
All CAPWAP protocol messages are encapsulated using a common header All CAPWAP protocol messages are encapsulated using a common header
skipping to change at page 42, line 31 skipping to change at page 43, line 31
the last fragment. When this bit is 0, the packet is not the last the last fragment. When this bit is 0, the packet is not the last
fragment. 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 M bit is used to indicate that the Radio MAC Address optional
header is present. This is used to communicate the MAC address of header is present. This is used to communicate the MAC address of
the receiving radio. This field MUST NOT be set to one in packets the receiving radio.
sent by the AC to the WTP.
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 Keep
Alive packet. This packet is used to map the data channel to the Alive packet. This packet is used to map the data channel to the
control channel for the specified Session ID and to maintain 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 data
packets containing user 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
skipping to change at page 43, line 30 skipping to change at page 44, line 30
converted to 802.3 by the WTP. This field is only present if the converted to 802.3 by the WTP. This field is only present if the
'M' bit is set. The HLEN field assumes 4 byte alignment, and this 'M' bit is set. The HLEN field assumes 4 byte alignment, and this
field MUST be padded with zeroes (0x00) if it is not 4 byte field MUST be padded with zeroes (0x00) if it is not 4 byte
aligned. 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 | Type | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The number of bytes in the MAC Address field. The length Type: The format of the MAC Address field. The following values
field is present since some technologies (e.g., IEEE 802.16) are supported:
use 64 bit MAC addresses.
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: The MAC Address of the receiving radio. MAC Address: The MAC Address of the receiving radio.
Wireless Specific Information: This optional field contains Wireless Specific Information: This optional field contains
technology specific information that may be used to carry per technology specific information that may be used to carry per
packet wireless information. This field is only present if the packet wireless information. This field is only present if the
'W' bit is set. The HLEN field assumes 4 byte alignment, and this 'W' bit is set. The HLEN field assumes 4 byte alignment, and this
field MUST be padded with zeroes (0x00) if it is not 4 byte field MUST be padded with zeroes (0x00) if it is not 4 byte
aligned. aligned.
skipping to change at page 45, line 51 skipping to change at page 47, line 9
The CAPWAP protocol also defines the native wireless encapsulation The CAPWAP protocol also defines the native wireless encapsulation
mode. The format of the encapsulated CAPWAP data frame is subject to mode. The format of the encapsulated CAPWAP data frame is subject to
the rules defined by the specific wireless technology binding. Each the rules defined by the specific wireless technology binding. Each
wireless technology binding MUST contain a section entitled "Payload wireless technology binding MUST contain a section entitled "Payload
Encapsulation", which defines the format of the wireless payload that Encapsulation", which defines the format of the wireless payload that
is encapsulated within CAPWAP Data packets. is encapsulated within CAPWAP Data packets.
If the encapsulated frame would exceed the transport layer's MTU, the If the encapsulated frame would exceed the transport layer's MTU, the
sender is responsible for fragmentation of the frame, as specified in sender is responsible for fragmentation of the frame, as specified in
Section 3.3. Section 3.4.
4.3.3. Establishment of a DTLS Data Channel 4.3.3. Establishment of a DTLS Data Channel
If the AC and WTP are configured to tunnel the data channel over If the AC and WTP are configured to tunnel the data channel over
DTLS, the proper DTLS session must be initiated. To avoid having to DTLS, the proper DTLS session must be initiated. To avoid having to
reauthenticate and reauthorize an AC and WTP, the DTLS data channel reauthenticate and reauthorize an AC and WTP, the DTLS data channel
MUST be initiated using the TLS session resumption feature [11]. MUST be initiated using the TLS session resumption feature [11].
When establishing the DTLS-encrypted data channel, the WTP MUST When establishing the DTLS-encrypted data channel, the WTP MUST
provide the identifier returned during the initialization of the provide the identifier returned during the initialization of the
skipping to change at page 50, line 33 skipping to change at page 52, line 16
respond to a retransmitted Request messages with minimal local respond to a retransmitted Request messages with minimal local
processing. Retransmitted Request messages MUST NOT be altered by processing. Retransmitted Request messages MUST NOT be altered by
the sender. The sender MUST assume that the original Request message the sender. The sender MUST assume that the original Request message
was processed, but that the Response message was lost. Any was processed, but that the Response message was lost. Any
alterations to the original Request message MUST have a new Sequence alterations to the original Request message MUST have a new Sequence
Number, and be treated as a new Request message by the receiver. Number, and be treated as a new Request message by the receiver.
After transmitting a Request message, the RetransmitInterval (see After transmitting a Request message, the RetransmitInterval (see
Section 4.6) timer and MaxRetransmit (see Section 4.7) variable are Section 4.6) timer and MaxRetransmit (see Section 4.7) 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. Response messages are not subject to these timers. retransmitted. The RetransmitInterval timer is used the first time
the Request is retransmitted. The timer is then doubled every
subsequent time the same Request message is retransmitted, up to
MaxRetransmit but no more than half the EchoInterval timer (see
Section 4.6.5). Response messages are not subject to these timers.
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
skipping to change at page 57, line 16 skipping to change at page 59, line 16
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. expected to be saved in non-volatile memory on the WTP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] | | Num of Entries| Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 7 for Add MAC ACL Entry Type: 7 for Add MAC ACL Entry
Length: >= 7 Length: >= 8
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of instances of the Type/MAC Addresses
fields in the array.
MAC Address: An array of MAC Addresses to add to the ACL. Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: MAC Addresses to add to the ACL.
4.5.8. Add Station 4.5.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
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 | MAC Address | | Radio ID | Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | VLAN Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+
Type: 8 for Add Station Type: 8 for Add Station
Length: >= 7 Length: >= 8
Radio ID: An 8-bit value representing the radio Radio ID: An 8-bit value representing the radio
Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: The station's MAC Address MAC Address: The station's MAC Address
VLAN Name: An optional variable length UTF-8 encoded string VLAN Name: An optional variable length UTF-8 encoded string
containing the VLAN Name on which the WTP is to locally bridge containing the VLAN Name on which the WTP is to locally bridge
user data. Note this field is only valid with WTPs configured in user data. Note this field is only valid with WTPs configured in
Local MAC mode. Local MAC mode.
4.5.9. Add Static MAC ACL Entry 4.5.9. Add Static MAC ACL Entry
The Add Static MAC ACL Entry message element is used by an AC to add The Add Static MAC ACL Entry message element is used by an AC to add
a permanent ACL entry on a WTP, ensuring that the WTP no longer a permanent ACL entry on a WTP, ensuring that the WTP no longer
provides any service to the MAC addresses provided in the message. provides any service to the MAC addresses provided in the message.
The MAC Addresses provided in this message element are expected to be The MAC Addresses provided in this message element are expected to be
saved in non-volative memory on the WTP. saved in non-volative memory on the WTP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] | | Num of Entries| Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 9 for Add Static MAC ACL Entry Type: 9 for Add Static MAC ACL Entry
Length: >= 7 Length: >= 8
Num of Entries: The number of instances of the Type/MAC Addresses
fields in the array.
Num of Entries: The number of MAC Addresses in the array. Type: The format of the following MAC Address field. One of the
following values are supported:
MAC Address: An array of MAC Addresses to add to the permanent ACL. 1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: MAC Addresses to add to the permanent ACL.
4.5.10. CAPWAP Control IPv4 Address 4.5.10. 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. the multiple interfaces.
skipping to change at page 60, line 25 skipping to change at page 62, line 47
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. when the WTP is in the discovery phase.
Echo Request: The number of seconds between WTP Echo Request CAPWAP Echo Request: The number of seconds between WTP Echo Request CAPWAP
messages. The default value for this message element is specified messages. The default value for this message element is specified
in Section 4.6.7. in Section 4.6.5.
4.5.13. Data Transfer Data 4.5.13. Data Transfer Data
The Data Transfer Data message element is used by the WTP to provide The Data Transfer Data message element is used by the WTP to provide
information to the AC for debugging purposes. information to the AC for debugging purposes.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Length | Data .... | Data Type | Data Length | Data ....
skipping to change at page 61, line 41 skipping to change at page 64, line 19
4.5.15. Decryption Error Report 4.5.15. 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
to inform the AC of decryption errors that have occurred since the to inform the AC of decryption errors that have occurred since the
last report. Note that this error reporting mechanism is not used if last report. Note that this error reporting mechanism is not used if
encryption and decryption services are provided in the AC. encryption and decryption services are provided in the AC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID |Num Of Entries | Station MAC Address | | Radio ID |Num Of Entries | Type |MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Station MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report Type: 15 for Decryption Error Report
Length: >= 8 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. WTP.
Num Of Entries: An 8-bit unsigned integer indicating the number of Num of Entries: The number of instances of the Type/MAC Addresses
station MAC addresses. fields in the array.
Station MAC Address: An array of station MAC addresses that have Type: The format of the following MAC Address field. One of the
caused decryption errors. following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: MAC addresses of the station that has caused
decryption errors.
4.5.16. Decryption Error Report Period 4.5.16. 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 62, line 47 skipping to change at page 65, line 31
4.5.17. Delete MAC ACL Entry 4.5.17. Delete MAC ACL Entry
The Delete MAC ACL Entry message element is used by an AC to delete a The Delete MAC ACL Entry message element is used by an AC to delete a
MAC ACL entry on a WTP, ensuring that the WTP provides service to the MAC ACL entry on a WTP, ensuring that the WTP provides service to the
MAC addresses provided in the message. MAC addresses provided in the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] | | Num of Entries| Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 17 for Delete MAC ACL Entry Type: 17 for Delete MAC ACL Entry
Length: >= 7 Length: >= 8
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of instances of the Type/MAC Addresses
fields in the array.
Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
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.5.18. Delete Station 4.5.18. 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.
skipping to change at page 63, line 32 skipping to change at page 66, line 25
The Delete Station message element MAY be sent by the WTP, in the WTP The Delete Station message element MAY be sent by the WTP, in the WTP
Event Request message, to inform the AC that a particular station is 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 | MAC Address | | Radio ID | Type | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18 for Delete Station Type: 18 for Delete Station
Length: 7 Length: >= 8
Radio ID: An 8-bit value representing the radio Radio ID: An 8-bit value representing the radio
Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: The station's MAC Address MAC Address: The station's MAC Address
4.5.19. Delete Static MAC ACL Entry 4.5.19. Delete Static MAC ACL Entry
The Delete Static MAC ACL Entry message element is used by an AC to The Delete Static MAC ACL Entry message element is used by an AC to
delete a previously added static MAC ACL entry on a WTP, ensuring delete a previously added static MAC ACL entry on a WTP, ensuring
that the WTP provides service to the MAC addresses provided in the that the WTP provides service to the MAC addresses provided in the
message. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] | | Num of Entries| Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 19 for Delete Static MAC ACL Entry Type: 19 for Delete Static MAC ACL Entry
Length: >= 7 Length: >= 8
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of instances of the Type/MAC Addresses
fields in the array.
Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: An array of MAC Addresses to delete from the static MAC Address: An array of MAC Addresses to delete from the static
MAC ACL entry. MAC ACL entry.
4.5.20. Discovery Type 4.5.20. 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.
skipping to change at page 65, line 21 skipping to change at page 68, line 27
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 MUSY 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | Status | Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 21 for Duplicate IPv4 Address Type: 21 for Duplicate IPv4 Address
Length: 11 Length: >= 12
IP Address: The IP Address currently used by the WTP. IP Address: The IP Address currently used by the WTP.
MAC Address: The MAC Address of the offending device.
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.
Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: The MAC Address of the offending device.
4.5.22. Duplicate IPv6 Address 4.5.22. 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
message element with the status set to 0. message element with the status set to 0.
skipping to change at page 66, line 16 skipping to change at page 69, line 27
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | Status | Type | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 23 for Duplicate IPv6 Address Type: 23 for Duplicate IPv6 Address
Length: 22 Length: >= 24
IP Address: The IP Address currently used by the WTP. IP Address: The IP Address currently used by the WTP.
MAC Address: The MAC Address of the offending device.
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.
Type: The format of the following MAC Address field. One of the
following values are supported:
1 - MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.
2 - EUI-64 [19] which is a 64 bit MAC Address.
MAC Address: The MAC Address of the offending device.
4.5.23. Idle Timeout 4.5.23. 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 |
skipping to change at page 75, line 12 skipping to change at page 78, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer | | Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 36 for Statistics Timer Type: 36 for Statistics Timer
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.6.15. Section 4.6.13.
4.5.37. Vendor Specific Payload 4.5.37. Vendor Specific Payload
The Vendor Specific Payload message element is used to communicate The Vendor Specific Payload message element is used to communicate
vendor specific information between the WTP and the AC. The message vendor specific information between the WTP and the AC. The message
element uses the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 75, line 27 skipping to change at page 79, line 4
vendor specific information between the WTP and the AC. The message vendor specific information between the WTP and the AC. The message
element uses the following format: element uses the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... | | Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Type: 37 for Vendor Specific
Length: >= 7 Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" [15] Network Management Private Enterprise Codes" [16]
Element ID: A 16-bit Element Identifier which is managed by the Element ID: A 16-bit Element Identifier which is managed by the
vendor. vendor.
Value: The value associated with the vendor specific element. Value: The value associated with the vendor specific element.
4.5.38. WTP Board Data 4.5.38. 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.
skipping to change at page 85, line 48 skipping to change at page 89, line 23
This section contains the CAPWAP timers. This section contains the CAPWAP timers.
4.6.1. ChangeStatePendingTimer 4.6.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. The default value is 25 Configuration Status Response message. The default value is 25
seconds. seconds.
4.6.2. DataChannelKeepAlive 4.6.2. DataChannelDeadInterval
The minimum time, in seconds, between sending Data Channel Keep Alive
packets to the AC that the WTP has joined. The default value is 30
seconds.
4.6.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: 5 Default: 5
4.6.4. DiscoveryInterval 4.6.3. DiscoveryInterval
The minimum time, in seconds, that a WTP MUST wait after receiving a The minimum time, in seconds, that a WTP MUST wait after receiving a
Discovery Response message, before initiating a DTLS handshake. Discovery Response message, before initiating a DTLS handshake.
Default: 5 Default: 5
4.6.5. DTLSRehandshake 4.6.4. DTLSSessionDelete
The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to
complete.
Default: 10
4.6.6. DTLSSessionDelete
The minimum time, in seconds, a WTP MUST wait for DTLS session The minimum time, in seconds, a WTP MUST wait for DTLS session
deletion. deletion.
Default: 5 Default: 5
4.6.7. EchoInterval 4.6.5. EchoInterval
The minimum time, in seconds, between sending Echo Request messages The minimum time, in seconds, between sending Echo Request messages
to the AC with which the WTP has joined. to the AC with which the WTP has joined.
Default: 30 Default: 30
4.6.8. KeyLifetime 4.6.6. KeyLifetime
The maximum time, in seconds, which a CAPWAP DTLS session key is The maximum time, in seconds, which a CAPWAP DTLS session key is
valid. valid.
Default: 28800 Default: 28800
4.6.9. MaxDiscoveryInterval 4.6.7. MaxDiscoveryInterval
The maximum time allowed between sending Discovery Request messages, The maximum time allowed between sending Discovery Request messages,
in seconds. This value MUST be no less than 2 seconds and no greater in seconds. This value MUST be no less than 2 seconds and no greater
than 180 seconds. than 180 seconds.
Default: 20 seconds. Default: 20 seconds.
4.6.10. MaxFailedDTLSSessionRetry 4.6.8. 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.6.11. NeighborDeadInterval 4.6.9. NeighborDeadInterval
The minimum time, in seconds, a WTP MUST wait without having received The minimum time, in seconds, a WTP MUST wait without having received
an Echo Response message to its Echo Request message, before the an Echo Response message to its Echo Request message, before the
destination for the Echo Request may be considered dead. This value destination for the Echo Request may be considered dead. This value
MUST be no less than 2*EchoInterval seconds and no greater than 240 MUST be no less than 2*EchoInterval seconds and no greater than 240
seconds. seconds.
Default: 60 Default: 60
4.6.12. ResponseTimeout 4.6.10. ResponseTimeout
The minimum time, in seconds, in which the WTP or AC must respond to The minimum time, in seconds, in which the WTP or AC must respond to
a CAPWAP Request message. a CAPWAP Request message.
Default: 1 Default: 1
4.6.13. RetransmitInterval 4.6.11. 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.6.14. SilentInterval 4.6.12. 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 a
establish DTLS session. For an AC, this is the minimum time, in establish 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 Default: 30
4.6.15. StatisticsTimer 4.6.13. StatisticsTimer
The default Statistics Interval is 120 seconds. The default Statistics Interval is 120 seconds.
4.6.16. WaitDTLS 4.6.14. WaitDTLS
The maximum time, in seconds, a WTP MUST wait without having received The maximum time, in seconds, a WTP MUST wait without having received
a DTLS Handshake message from an AC. This timer must be greater than a DTLS Handshake message from an AC. This timer must be greater than
30 seconds. 30 seconds.
Default: 60 Default: 60
4.6.17. WaitJoin 4.6.15. WaitJoin
The maximum time, in seconds, after which the DTLS session has been The maximum time, in seconds, after which the DTLS session has been
established that the AC will wait before receiving a Join Request established that the AC will wait before receiving a Join Request
message. This timer must be greater than 30 seconds. message. This timer must be greater than 30 seconds.
Default: 60 Default: 60
4.7. CAPWAP Protocol Variables 4.7. CAPWAP Protocol Variables
A WTP or AC that implements the CAPWAP Discovery phase MUST allow for A WTP or AC that implements the CAPWAP Discovery phase MUST allow for
skipping to change at page 94, line 43 skipping to change at page 98, line 43
The Primary Discovery Response message is sent by the AC when in the The Primary Discovery Response message is sent by the AC when in the
Idle State. The WTP does not transmit this message. Idle State. The WTP does not transmit this message.
The following message elements MUST be included in the Primary The following message elements MUST be included in the Primary
Discovery Response message. Discovery Response message.
o AC Descriptor, see Section 4.5.1 o AC Descriptor, see Section 4.5.1
o AC Name, see Section 4.5.4 o AC Name, see Section 4.5.4
o CAPWAP Control IPv4 Address, see Section 4.5.10
o CAPWAP Control IPv6 Address, see Section 4.5.11
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).
One of the following message elements MUST be included in the
Discovery Response Message:
o CAPWAP Control IPv4 Address, see Section 4.5.10
o CAPWAP Control IPv6 Address, see Section 4.5.11
6. CAPWAP Join Operations 6. CAPWAP Join Operations
The Join Request message is used by a WTP to request service from an The Join Request message is used by a WTP to request service from an
AC after a DTLS connection is established to that AC. The Join AC after a DTLS connection is established to that AC. The Join
Response message is used by the the AC to indicate that it will or Response message is used by the the AC to indicate that it will or
will not provide service. will not provide service.
6.1. Join Request 6.1. Join Request
The Join Request message is used by a WTP to request service through The Join Request message is used by a WTP to request service through
skipping to change at page 97, line 29 skipping to change at page 102, line 29
The following message elements MUST be included in the Join Response The following message elements MUST be included in the Join Response
message. message.
o Result Code, see Section 4.5.33 o Result Code, see Section 4.5.33
o AC Descriptor, see Section 4.5.1 o AC Descriptor, see Section 4.5.1
o AC Name, see Section 4.5.4 o AC Name, see Section 4.5.4
o CAPWAP Control IPv4 Address, see Section 4.5.10
o CAPWAP Control IPv6 Address, see Section 4.5.11
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). Protocols (see Section 2.1).
One of the following message elements MUST be included in the
Discovery Response Message:
o CAPWAP Control IPv4 Address, see Section 4.5.10
o CAPWAP Control IPv6 Address, see Section 4.5.11
7. Control Channel Management 7. Control Channel Management
The Control Channel Management messages are used by the WTP and AC to The Control Channel Management messages are used by the WTP and AC to
maintain a control communication channel. CAPWAP control messages, maintain a control communication channel. CAPWAP control messages,
such as the WTP Event Request message sent from the WTP to the AC such as the WTP Event Request message sent from the WTP to the AC
indicate to the AC that the WTP is operational. When such control indicate to the AC that the WTP is operational. When such control
messages are not being sent, the Echo Request and Echo Response messages are not being sent, the Echo Request and Echo Response
messages are used to maintain the control communication channel. messages are used to maintain the control communication channel.
7.1. Echo Request 7.1. Echo Request
The Echo Request message is a keep-alive mechanism for CAPWAP control The Echo Request message is a keep-alive mechanism for CAPWAP control
messages. messages.
Echo Request messages are sent periodically by a WTP in the Run state Echo Request messages are sent periodically by a WTP in the Run state
(see Section 2.3) to determine the state of the control connection (see Section 2.3) to determine the state of the control connection
between the WTP and the AC. The Echo Request message is sent by the between the WTP and the AC. The Echo Request message is sent by the
WTP when the Heartbeat timer expires. The WTP MUST start its WTP when the EchoInterval timer expires. The WTP MUST start its
NeighborDeadInterval timer when the Heartbeat timer expires. NeighborDeadInterval timer when the EchoInterval timer expires.
The Echo Request message is sent by the WTP when in the Run State. The Echo Request message is sent by the WTP when in the Run State.
The AC does not transmit this message. The AC does not transmit this message.
The Echo Request message carries no message elements. The Echo Request message carries no message elements.
When an AC receives an Echo Request message it responds with an Echo When an AC receives an Echo Request message it responds with an Echo
Response message. Response message.
7.2. Echo Response 7.2. Echo Response
The Echo Response message acknowledges the Echo Request message. The Echo Response message acknowledges the Echo Request message.
An Echo Response message is sent by an AC after receiving an Echo An Echo Response message is sent by an AC after receiving an
Request message. After transmitting the Echo Response message, the EchoRequest message. After transmitting the Echo Response message,
AC SHOULD reset its Heartbeat timer to expire in the value configured the AC SHOULD reset its EchoInterval timer. If another Echo Request
for EchoInterval. If another Echo Request message or other control message or other control message is not received by the AC when the
message is not received by the AC when the timer expires, the AC timer expires, the AC SHOULD consider the WTP to be no longer
SHOULD consider the WTP to be no longer reachable. reachable.
The Echo Response message is sent by the AC when in the Run State. The Echo Response message is sent by the AC when in the Run State.
The WTP does not transmit this message. The WTP does not transmit this message.
The Echo Response message carries no message elements. The Echo Response message carries no message elements.
When a WTP receives an Echo Response message it stops the When a WTP receives an Echo Response message it stops the
NeighborDeadInterval timer, and initializes the Heartbeat timer to NeighborDeadInterval timer, and initializes the EchoInterval to the
the EchoInterval. configured value.
If the NeighborDeadInterval timer expires prior to receiving an Echo If the NeighborDeadInterval timer expires prior to receiving an Echo
Response message, or other control message, the WTP enters the Idle Response message, or other control message, the WTP enters the Idle
state. state.
8. WTP Configuration Management 8. WTP Configuration Management
WTP Configuration messages are used to exchange configuration WTP Configuration messages are used to exchange configuration
information between the AC and the WTP. information between the AC and the WTP.
skipping to change at page 119, line 5 skipping to change at page 123, line 17
This message element SHOULD NOT be used in NAT'ed environments, This message element SHOULD NOT be used in NAT'ed environments,
unless the administrator is familiar with the internal IP addressing unless the administrator is familiar with the internal IP addressing
scheme within the WTP's private network, and does not rely on the scheme within the WTP's private network, and does not rely on the
public address seen by the AC. public address seen by the AC.
When a WTP detects the duplicate address condition, it generates a When a WTP detects the duplicate address condition, it generates a
message to the AC, which includes the Duplicate IP Address message message to the AC, which includes the Duplicate IP Address message
element. The IP Address embedded within this message element is element. The IP Address embedded within this message element is
different from the public IP address seen by the AC. different from the public IP address seen by the AC.
When CAPWAP is run over IPv6, NAT support can only be provided if the
IPv6 NAT system is capable of performing address translation over the
UDP-Lite 3828 protocol [13]. A protocol interoperability issues will
exist if the NAT system is being utilized for IPv4/IPv6 address
translation.
12. Security Considerations 12. Security Considerations
This section describes security considerations for the CAPWAP This section describes security considerations for the CAPWAP
protocol. It also provides security recommendations for protocols protocol. It also provides security recommendations for protocols
used in conjunction with CAPWAP. used in conjunction with CAPWAP.
12.1. CAPWAP Security 12.1. CAPWAP Security
As it is currently specified, the CAPWAP protocol sits between the As it is currently specified, the CAPWAP protocol sits between the
security mechanisms specified by the wireless link layer protocol security mechanisms specified by the wireless link layer protocol
skipping to change at page 122, line 34 skipping to change at page 127, line 34
capability for generation of new random PSKs, taking RFC 1750 [2] capability for generation of new random PSKs, taking RFC 1750 [2]
into account. into account.
o Preshared keys SHOULD be periodically updated. Implementations o Preshared keys SHOULD be periodically updated. Implementations
may facilitate this by providing an administrative interface for may facilitate this by providing an administrative interface for
automatic key generation and periodic update, or it may be automatic key generation and periodic update, or it may be
accomplished manually instead. accomplished manually instead.
Every pairwise combination of WTP and AC on the network SHOULD have a Every pairwise combination of WTP and AC on the network SHOULD have a
unqiue PSK. This prevents the domino effect (see Guidance for AAA unqiue PSK. This prevents the domino effect (see Guidance for AAA
Key Management [14]). If PSKs are tied to specific WTPs, then Key Management [15]). If PSKs are tied to specific WTPs, then
knowledge of the PSK implies a binding to a specified identity that knowledge of the PSK implies a binding to a specified identity that
can be authorized. can be authorized.
If PSKs are shared, this binding between device and identity is no If PSKs are shared, this binding between device and identity is no
longer possible. Compromise of one WTP can yield compromise of longer possible. Compromise of one WTP can yield compromise of
another WTP, violating the CAPWAP security hierarchy. Consequently, another WTP, violating the CAPWAP security hierarchy. Consequently,
sharing keys between WTPs is NOT RECOMMENDED. sharing keys between WTPs is NOT RECOMMENDED.
12.6. Use of Certificates in CAPWAP 12.6. Use of Certificates in CAPWAP
skipping to change at page 125, line 9 skipping to change at page 130, line 9
protocol MAY be used for the purposes of monitoring the WTP directly, protocol MAY be used for the purposes of monitoring the WTP directly,
configuring the WTP through a separate management interface is not configuring the WTP through a separate management interface is not
recommended. Configuring the WTP through a separate protocol, such recommended. Configuring the WTP through a separate protocol, such
as via a CLI or SNMP, could lead to the AC state being out of sync as via a CLI or SNMP, could lead to the AC state being out of sync
with the WTP. with the WTP.
14. IANA Considerations 14. IANA Considerations
A separate UDP port for data channel communications is (currently) A separate UDP port for data channel communications is (currently)
the selected demultiplexing mechanism, and a port must be assigned the selected demultiplexing mechanism, and a port must be assigned
for this purpose. for this purpose in section Section 3.1. The UDP port numbers are
listed by IANA at http://www.iana.org/assignments/port-numbers.
IANA needs to assign a DHCP code point, currently identified as TBD IANA needs to assign a DHCP code point, currently identified as TBD
in the Section 3.2. DHCP options are defined in RFC 1533 [10], and in the Section 3.3. DHCP options are defined in RFC 1533 [10], and
are listed by IANA at are listed by IANA at
http://www.iana.org/assignments/bootp-dhcp-parameters. http://www.iana.org/assignments/bootp-dhcp-parameters.
IANA needs to assign an organization local multicast address called IANA needs to assign an organization local multicast address called
the "All ACs multicast address" from the IPv6 multicast address the "All ACs multicast address" from the IPv6 multicast address
registry in Section 3.2 registry in Section 3.3
14.1. CAPWAP Message Types 14.1. CAPWAP Message Types
The Message Type field in the CAPWAP header (Section 4.4.1.1) is used The Message Type field in the CAPWAP header (Section 4.4.1.1) is used
to identify the operation performed by the message. There are to identify the operation performed by the message. There are
multiple namespaces, which is identified via the first three octets multiple namespaces, which is identified via the first three octets
of the field containing the IANA Enterprise Number [12]. When the of the field containing the IANA Enterprise Number [12]. When the
Enterprise Number is set to zero, the message types are reserved for Enterprise Number is set to zero, the message types are reserved for
use by the base CAPWAP specification which are controlled and use by the base CAPWAP specification which are controlled and
maintained by IANA. maintained by IANA.
skipping to change at page 127, line 47 skipping to change at page 132, line 47
[10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, October 1993. Extensions", RFC 1533, October 1993.
[11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[13] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
RFC 3828, July 2004.
16.2. Informational References 16.2. Informational References
[13] "draft-ietf-capwap-protocol-binding-specification-ieee802dot11- [14] "draft-ietf-capwap-protocol-binding-specification-ieee802dot11-
02". 02".
16.3. Informational References 16.3. Informational References
[14] "draft-housley-aaa-key-mgmt-06". [15] "draft-housley-aaa-key-mgmt-06".
[15] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [16] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
[16] Modadugu et al, N., "The Design and Implementation of Datagram [17] Modadugu et al, N., "The Design and Implementation of Datagram
TLS", Feb 2004. TLS", Feb 2004.
[18] IEEE, "Guidelines for use of a 48-bit Extended Unique
Identifier", Dec 2005.
[19] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY".
Editors' Addresses Editors' Addresses
Pat R. Calhoun Pat R. Calhoun
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408-853-5269 Phone: +1 408-853-5269
Email: pcalhoun@cisco.com Email: pcalhoun@cisco.com
 End of changes. 102 change blocks. 
302 lines changed or deleted 381 lines changed or added

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