draft-ietf-capwap-protocol-specification-13.txt   draft-ietf-capwap-protocol-specification-14.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track M. Montemurro, Editor Intended status: Standards Track M. Montemurro, Editor
Expires: March 23, 2009 Research In Motion Expires: April 17, 2009 Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
September 19, 2008 October 14, 2008
CAPWAP Protocol Specification CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-13 draft-ietf-capwap-protocol-specification-14
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2009. This Internet-Draft will expire on April 17, 2009.
Abstract Abstract
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol, meeting the objectives defined by Access Points (CAPWAP) Protocol, meeting the objectives defined by
the CAPWAP working group in RFC 4564. The CAPWAP protocol is the CAPWAP working group in RFC 4564. The CAPWAP protocol is
designed to be flexible, allowing it to be used for a variety of designed to be flexible, allowing it to be used for a variety of
wireless technologies. This document describes the base CAPWAP wireless technologies. This document describes the base CAPWAP
protocol, while separate binding extensions will enable its use with protocol, while separate binding extensions will enable its use with
additional wireless technologies. additional wireless technologies.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 16 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 16
2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18
2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 32 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 32
2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 34 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 34
2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 34 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 34
2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 36 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 36
2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 36 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 36
2.4.4. DTLS EndPoint Authentication and Authorization . . . 37 2.4.4. DTLS EndPoint Authentication and Authorization . . . 37
3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 41 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 41
3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 41 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 41
3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 41 3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 42
3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 42 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 42
3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 43
3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . 43 3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . 44
4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 45 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 45
4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . 47 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . 47
4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 47 4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 47
4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . 48 4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . 48
4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 51 4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 51
4.4.1. CAPWAP Data Channel Keepalive . . . . . . . . . . . . 51 4.4.1. CAPWAP Data Channel Keepalive . . . . . . . . . . . . 51
4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 52 4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 52
4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 53 4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 53
4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . 53 4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . 53
4.5.1. Control Message Format . . . . . . . . . . . . . . . 54 4.5.1. Control Message Format . . . . . . . . . . . . . . . 54
4.5.2. Control Message Quality of Service . . . . . . . . . 57 4.5.2. Quality of Service . . . . . . . . . . . . . . . . . 57
4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 57 4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 58
4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 59 4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 59
4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 61 4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 61
4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 64 4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 64
4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 64 4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 65
4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 65 4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 65
4.6.5. AC Name with Priority . . . . . . . . . . . . . . . . 65 4.6.5. AC Name with Priority . . . . . . . . . . . . . . . . 66
4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 66 4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 66
4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 66 4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 67
4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 67 4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 67
4.6.9. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 68 4.6.9. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 68
4.6.10. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 68 4.6.10. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 69
4.6.11. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 69 4.6.11. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 69
4.6.12. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 70 4.6.12. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 70
4.6.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 70 4.6.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 70
4.6.14. CAPWAP Transport Protocol . . . . . . . . . . . . . . 71 4.6.14. CAPWAP Transport Protocol . . . . . . . . . . . . . . 71
4.6.15. Data Transfer Data . . . . . . . . . . . . . . . . . 72 4.6.15. Data Transfer Data . . . . . . . . . . . . . . . . . 72
4.6.16. Data Transfer Mode . . . . . . . . . . . . . . . . . 73 4.6.16. Data Transfer Mode . . . . . . . . . . . . . . . . . 73
4.6.17. Decryption Error Report . . . . . . . . . . . . . . . 73 4.6.17. Decryption Error Report . . . . . . . . . . . . . . . 73
4.6.18. Decryption Error Report Period . . . . . . . . . . . 74 4.6.18. Decryption Error Report Period . . . . . . . . . . . 74
4.6.19. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 74 4.6.19. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 75
4.6.20. Delete Station . . . . . . . . . . . . . . . . . . . 75 4.6.20. Delete Station . . . . . . . . . . . . . . . . . . . 75
4.6.21. Discovery Type . . . . . . . . . . . . . . . . . . . 76 4.6.21. Discovery Type . . . . . . . . . . . . . . . . . . . 76
4.6.22. Duplicate IPv4 Address . . . . . . . . . . . . . . . 76 4.6.22. Duplicate IPv4 Address . . . . . . . . . . . . . . . 76
4.6.23. Duplicate IPv6 Address . . . . . . . . . . . . . . . 77 4.6.23. Duplicate IPv6 Address . . . . . . . . . . . . . . . 77
4.6.24. Idle Timeout . . . . . . . . . . . . . . . . . . . . 78 4.6.24. Idle Timeout . . . . . . . . . . . . . . . . . . . . 78
4.6.25. Image Data . . . . . . . . . . . . . . . . . . . . . 78 4.6.25. Image Data . . . . . . . . . . . . . . . . . . . . . 79
4.6.26. Image Identifier . . . . . . . . . . . . . . . . . . 79 4.6.26. Image Identifier . . . . . . . . . . . . . . . . . . 79
4.6.27. Image Information . . . . . . . . . . . . . . . . . . 79 4.6.27. Image Information . . . . . . . . . . . . . . . . . . 80
4.6.28. Initiate Download . . . . . . . . . . . . . . . . . . 80 4.6.28. Initiate Download . . . . . . . . . . . . . . . . . . 81
4.6.29. Location Data . . . . . . . . . . . . . . . . . . . . 80 4.6.29. Location Data . . . . . . . . . . . . . . . . . . . . 81
4.6.30. Maximum Message Length . . . . . . . . . . . . . . . 81 4.6.30. Maximum Message Length . . . . . . . . . . . . . . . 81
4.6.31. MTU Discovery Padding . . . . . . . . . . . . . . . . 81 4.6.31. MTU Discovery Padding . . . . . . . . . . . . . . . . 82
4.6.32. Radio Administrative State . . . . . . . . . . . . . 82 4.6.32. Radio Administrative State . . . . . . . . . . . . . 82
4.6.33. Radio Operational State . . . . . . . . . . . . . . . 82 4.6.33. Radio Operational State . . . . . . . . . . . . . . . 83
4.6.34. Result Code . . . . . . . . . . . . . . . . . . . . . 83 4.6.34. Result Code . . . . . . . . . . . . . . . . . . . . . 84
4.6.35. Returned Message Element . . . . . . . . . . . . . . 85 4.6.35. Returned Message Element . . . . . . . . . . . . . . 86
4.6.36. Session ID . . . . . . . . . . . . . . . . . . . . . 86 4.6.36. Session ID . . . . . . . . . . . . . . . . . . . . . 86
4.6.37. Statistics Timer . . . . . . . . . . . . . . . . . . 86 4.6.37. Statistics Timer . . . . . . . . . . . . . . . . . . 87
4.6.38. Vendor Specific Payload . . . . . . . . . . . . . . . 87 4.6.38. Vendor Specific Payload . . . . . . . . . . . . . . . 87
4.6.39. WTP Board Data . . . . . . . . . . . . . . . . . . . 87 4.6.39. WTP Board Data . . . . . . . . . . . . . . . . . . . 88
4.6.40. WTP Descriptor . . . . . . . . . . . . . . . . . . . 89 4.6.40. WTP Descriptor . . . . . . . . . . . . . . . . . . . 89
4.6.41. WTP Fallback . . . . . . . . . . . . . . . . . . . . 91 4.6.41. WTP Fallback . . . . . . . . . . . . . . . . . . . . 92
4.6.42. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 92 4.6.42. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 92
4.6.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 93 4.6.43. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 93
4.6.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 93 4.6.44. WTP Name . . . . . . . . . . . . . . . . . . . . . . 94
4.6.45. WTP Radio Statistics . . . . . . . . . . . . . . . . 94 4.6.45. WTP Radio Statistics . . . . . . . . . . . . . . . . 94
4.6.46. WTP Reboot Statistics . . . . . . . . . . . . . . . . 95 4.6.46. WTP Reboot Statistics . . . . . . . . . . . . . . . . 96
4.6.47. WTP Static IP Address Information . . . . . . . . . . 97 4.6.47. WTP Static IP Address Information . . . . . . . . . . 97
4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 97 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 98
4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 97 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 98
4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 98 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 98
4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 98 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 99
4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 98 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 99
4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 98 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 99
4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 98 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 99
4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 98 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 99
4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 99 4.7.8. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 99
4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 99 4.7.9. ImageDataStartTimer . . . . . . . . . . . . . . . . . 99
4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 99 4.7.10. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 100
4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 99 4.7.11. ReportInterval . . . . . . . . . . . . . . . . . . . 100
4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 99 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 100
4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 99 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 100
4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 100 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 100
4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 100 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 100
4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 100 4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 101
4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 100 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 101
4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 100 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 101
4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 100 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 101
4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 100 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 101
4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 101 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 101
4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 101 4.8.5. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 101
4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 101 4.8.6. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 101
4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 101 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 102
4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 101 4.8.8. RetransmitCount . . . . . . . . . . . . . . . . . . . 102
4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 101 4.8.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 102
4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 101 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . 102
4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 101 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 102
4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 102 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 102
4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 102 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 102
4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 102 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 102
4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 102 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 103
4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 102 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 103
4.9.7. Static IP Address . . . . . . . . . . . . . . . . . . 102 4.9.7. Static IP Address . . . . . . . . . . . . . . . . . . 103
4.9.8. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 102 4.9.8. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 103
4.9.9. WTPLocation . . . . . . . . . . . . . . . . . . . . . 102 4.9.9. WTPLocation . . . . . . . . . . . . . . . . . . . . . 103
4.9.10. WTPName . . . . . . . . . . . . . . . . . . . . . . . 102 4.9.10. WTPName . . . . . . . . . . . . . . . . . . . . . . . 103
5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 103 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 104
5.1. Discovery Request Message . . . . . . . . . . . . . . . 103 5.1. Discovery Request Message . . . . . . . . . . . . . . . 104
5.2. Discovery Response Message . . . . . . . . . . . . . . . 104 5.2. Discovery Response Message . . . . . . . . . . . . . . . 105
5.3. Primary Discovery Request Message . . . . . . . . . . . 105 5.3. Primary Discovery Request Message . . . . . . . . . . . 106
5.4. Primary Discovery Response . . . . . . . . . . . . . . . 106 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 107
6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 108 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 109
6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 108 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 109
6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 109 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 110
7. Control Channel Management . . . . . . . . . . . . . . . . . 112 7. Control Channel Management . . . . . . . . . . . . . . . . . 113
7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 112 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 113
7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 112 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 113
8. WTP Configuration Management . . . . . . . . . . . . . . . . 114 8. WTP Configuration Management . . . . . . . . . . . . . . . . 115
8.1. Configuration Consistency . . . . . . . . . . . . . . . 114 8.1. Configuration Consistency . . . . . . . . . . . . . . . 115
8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 115 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 116
8.2. Configuration Status Request . . . . . . . . . . . . . . 115 8.2. Configuration Status Request . . . . . . . . . . . . . . 116
8.3. Configuration Status Response . . . . . . . . . . . . . 116 8.3. Configuration Status Response . . . . . . . . . . . . . 117
8.4. Configuration Update Request . . . . . . . . . . . . . . 117 8.4. Configuration Update Request . . . . . . . . . . . . . . 118
8.5. Configuration Update Response . . . . . . . . . . . . . 118 8.5. Configuration Update Response . . . . . . . . . . . . . 119
8.6. Change State Event Request . . . . . . . . . . . . . . . 118 8.6. Change State Event Request . . . . . . . . . . . . . . . 119
8.7. Change State Event Response . . . . . . . . . . . . . . 120 8.7. Change State Event Response . . . . . . . . . . . . . . 121
8.8. Clear Configuration Request . . . . . . . . . . . . . . 120 8.8. Clear Configuration Request . . . . . . . . . . . . . . 121
8.9. Clear Configuration Response . . . . . . . . . . . . . . 120 8.9. Clear Configuration Response . . . . . . . . . . . . . . 121
9. Device Management Operations . . . . . . . . . . . . . . . . 122 9. Device Management Operations . . . . . . . . . . . . . . . . 123
9.1. Firmware Management . . . . . . . . . . . . . . . . . . 122 9.1. Firmware Management . . . . . . . . . . . . . . . . . . 123
9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 126 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 127
9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 127 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 128
9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 128 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . 129
9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 129 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 130
9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 129 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . 130
9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 130 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 131
9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 130 9.6. Data Transfer . . . . . . . . . . . . . . . . . . . . . 131
9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 131 9.6.1. Data Transfer Request . . . . . . . . . . . . . . . . 132
9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 132 9.6.2. Data Transfer Response . . . . . . . . . . . . . . . 133
10. Station Session Management . . . . . . . . . . . . . . . . . 134 10. Station Session Management . . . . . . . . . . . . . . . . . 135
10.1. Station Configuration Request . . . . . . . . . . . . . 134 10.1. Station Configuration Request . . . . . . . . . . . . . 135
10.2. Station Configuration Response . . . . . . . . . . . . . 134 10.2. Station Configuration Response . . . . . . . . . . . . . 135
11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 136 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 137
12. Security Considerations . . . . . . . . . . . . . . . . . . . 138 12. Security Considerations . . . . . . . . . . . . . . . . . . . 139
12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 138 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 139
12.1.1. Converting Protected Data into Unprotected Data . . . 139 12.1.1. Converting Protected Data into Unprotected Data . . . 140
12.1.2. Converting Unprotected Data into Protected Data 12.1.2. Converting Unprotected Data into Protected Data
(Insertion) . . . . . . . . . . . . . . . . . . . . . 139 (Insertion) . . . . . . . . . . . . . . . . . . . . . 140
12.1.3. Deletion of Protected Records . . . . . . . . . . . . 139 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 140
12.1.4. Insertion of Unprotected Records . . . . . . . . . . 139 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 140
12.1.5. Use of MD5 . . . . . . . . . . . . . . . . . . . . . 139 12.1.5. Use of MD5 . . . . . . . . . . . . . . . . . . . . . 140
12.2. Session ID Security . . . . . . . . . . . . . . . . . . 139 12.1.6. CAPWAP Fragmentation . . . . . . . . . . . . . . . . 140
12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 140 12.2. Session ID Security . . . . . . . . . . . . . . . . . . 141
12.4. Interference with a DTLS Session . . . . . . . . . . . . 141 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . 141
12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 141 12.4. Interference with a DTLS Session . . . . . . . . . . . . 142
12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 142 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . 142
12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 143 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 143
12.8. AAA Security . . . . . . . . . . . . . . . . . . . . . . 144 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . 144
13. Operational Considerations . . . . . . . . . . . . . . . . . 145 12.8. Use of MAC Address in CN Field . . . . . . . . . . . . . 145
14. Transport Considerations . . . . . . . . . . . . . . . . . . 146 12.9. AAA Security . . . . . . . . . . . . . . . . . . . . . . 145
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147 12.10. WTP Firmware . . . . . . . . . . . . . . . . . . . . . . 146
15.1. Multicast Address . . . . . . . . . . . . . . . . . . . 147 13. Operational Considerations . . . . . . . . . . . . . . . . . 147
15.2. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 147 14. Transport Considerations . . . . . . . . . . . . . . . . . . 148
15.3. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 148 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149
15.4. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 148 15.1. IPv4 Multicast Address . . . . . . . . . . . . . . . . . 149
15.5. CAPWAP Control Message Flags . . . . . . . . . . . . . . 148 15.2. IPv6 Multicast Address . . . . . . . . . . . . . . . . . 149
15.6. CAPWAP Message Element Type . . . . . . . . . . . . . . 148 15.3. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 149
15.7. Wireless Binding Identifiers . . . . . . . . . . . . . . 149 15.4. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 150
15.8. AC Security Types . . . . . . . . . . . . . . . . . . . 149 15.5. CAPWAP Header Flags . . . . . . . . . . . . . . . . . . 150
15.9. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 149 15.6. CAPWAP Control Message Flags . . . . . . . . . . . . . . 150
15.10. AC Information Type . . . . . . . . . . . . . . . . . . 150 15.7. CAPWAP Message Element Type . . . . . . . . . . . . . . 151
15.11. CAPWAP Transport Protocol Types . . . . . . . . . . . . 150 15.8. Wireless Binding Identifiers . . . . . . . . . . . . . . 151
15.12. Data Transfer Type . . . . . . . . . . . . . . . . . . . 150 15.9. AC Security Types . . . . . . . . . . . . . . . . . . . 151
15.13. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 151 15.10. AC DTLS Policy . . . . . . . . . . . . . . . . . . . . . 152
15.14. Discovery Types . . . . . . . . . . . . . . . . . . . . 151 15.11. AC Information Type . . . . . . . . . . . . . . . . . . 152
15.15. Radio Admin State . . . . . . . . . . . . . . . . . . . 151 15.12. CAPWAP Transport Protocol Types . . . . . . . . . . . . 152
15.16. Radio Operational State . . . . . . . . . . . . . . . . 151 15.13. Data Transfer Type . . . . . . . . . . . . . . . . . . . 152
15.17. Radio Failure Causes . . . . . . . . . . . . . . . . . . 152 15.14. Data Transfer Mode . . . . . . . . . . . . . . . . . . . 153
15.18. Result Code . . . . . . . . . . . . . . . . . . . . . . 152 15.15. Discovery Types . . . . . . . . . . . . . . . . . . . . 153
15.19. Returned Message Element Reason . . . . . . . . . . . . 152 15.16. Radio Admin State . . . . . . . . . . . . . . . . . . . 153
15.20. WTP Board Data Type . . . . . . . . . . . . . . . . . . 152 15.17. Radio Operational State . . . . . . . . . . . . . . . . 154
15.21. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 153 15.18. Radio Failure Causes . . . . . . . . . . . . . . . . . . 154
15.22. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 153 15.19. Result Code . . . . . . . . . . . . . . . . . . . . . . 154
15.23. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 153 15.20. Returned Message Element Reason . . . . . . . . . . . . 154
15.24. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 154 15.21. WTP Board Data Type . . . . . . . . . . . . . . . . . . 155
15.25. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 154 15.22. WTP Descriptor Type . . . . . . . . . . . . . . . . . . 155
15.26. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 154 15.23. WTP Fallback Mode . . . . . . . . . . . . . . . . . . . 155
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 155 15.24. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . . 155
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 156 15.25. WTP MAC Type . . . . . . . . . . . . . . . . . . . . . . 156
17.1. Normative References . . . . . . . . . . . . . . . . . . 156 15.26. WTP Radio Stats Failure Type . . . . . . . . . . . . . . 156
17.2. Informational References . . . . . . . . . . . . . . . . 157 15.27. WTP Reboot Stats Failure Type . . . . . . . . . . . . . 156
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 157
Intellectual Property and Copyright Statements . . . . . . . . . 160 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 158
17.1. Normative References . . . . . . . . . . . . . . . . . . 158
17.2. Informational References . . . . . . . . . . . . . . . . 160
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
Intellectual Property and Copyright Statements . . . . . . . . . 163
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,
and meets the Objectives for Control and Provisioning of Wireless and meets the Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP) [RFC4564]. Access Points (CAPWAP) [RFC4564].
skipping to change at page 12, line 11 skipping to change at page 12, line 11
station traffic for wireless access networks. station traffic for wireless access networks.
This document uses additional terminology defined in [RFC3753]. This document uses additional terminology defined in [RFC3753].
2. Protocol Overview 2. Protocol Overview
The CAPWAP protocol is a generic protocol defining AC and WTP control The CAPWAP protocol is a generic protocol defining AC and WTP control
and data plane communication via a CAPWAP protocol transport and data plane communication via a CAPWAP protocol transport
mechanism. CAPWAP control messages, and optionally CAPWAP data mechanism. CAPWAP control messages, and optionally CAPWAP data
messages, are secured using Datagram Transport Layer Security (DTLS) messages, are secured using Datagram Transport Layer Security (DTLS)
[RFC4346]. DTLS is a standards-track IETF protocol based upon TLS. [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS.
The underlying security-related protocol mechanisms of TLS have been The underlying security-related protocol mechanisms of TLS have been
successfully deployed for many years. successfully deployed for many years.
The CAPWAP protocol Transport layer carries two types of payload, The CAPWAP protocol Transport layer carries two types of payload,
CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data
messages encapsulate forwarded wireless frames. CAPWAP protocol messages encapsulate forwarded wireless frames. CAPWAP protocol
Control messages are management messages exchanged between a WTP and Control messages are management messages exchanged between a WTP and
an AC. The CAPWAP Data and Control packets are sent over separate an AC. The CAPWAP Data and Control packets are sent over separate
UDP ports. Since both data and control packets can exceed the UDP ports. Since both data and control packets can exceed the
Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data
skipping to change at page 26, line 27 skipping to change at page 26, line 27
starts the DTLSSessionDelete timer (see Section 4.7.6). starts the DTLSSessionDelete timer (see Section 4.7.6).
Image Data to Image Data (j): The Image Data state is used by the Image Data to Image Data (j): The Image Data state is used by the
WTP and the AC during the firmware download phase. WTP and the AC during the firmware download phase.
WTP: The WTP enters the Image Data state when it receives an WTP: The WTP enters the Image Data state when it receives an
Image Data Response message indicating that the AC has more Image Data Response message indicating that the AC has more
data to send. This state transition also occurs when the WTP data to send. This state transition also occurs when the WTP
receives the subsequent Image Data Requests, at which time it receives the subsequent Image Data Requests, at which time it
resets the ImageDataStartTimer time to ensure it receives the resets the ImageDataStartTimer time to ensure it receives the
next expected Image Data Request from the AC. next expected Image Data Request from the AC. This state
transition can also occur when the WTP's EchoInterval timer
(see Section 4.7.7) expires, in which case the WTP transmits an
Echo Request message (see Section 7.1), and resets its
EchoInterval timer. The state transition also occurs when the
WTP receives an Echo Response from the AC (see Section 7.2.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs either when the AC receives the
Data Response message from the WTP while already in the Image Image Data Response message from the WTP while already in the
Data state. Image Data state. This state transition also occurs when the
AC receives an Echo Request (see Section 7.1) from the WTP, in
which case it responds with an Echo Response (see Section 7.2),
and resets its EchoInterval timer (see Section 4.7.7).
Image Data to Reset (k): This state transition is used to reset the Image Data to Reset (k): This state transition is used to reset the
DTLS connection prior to restarting the WTP after an image DTLS connection prior to restarting the WTP after an image
download. download.
WTP: When an image download completes, or if the WTP: When an image download completes, or if the
ImageDataStartTimer timer expires, the WTP enters the Reset ImageDataStartTimer timer expires, the WTP enters the Reset
state. The WTP MAY also transition to this state upon state. The WTP MAY also transition to this state upon
receiving an Image Data Response message from the AC (see receiving an Image Data Response message from the AC (see
Section 9.1.2) indicating a failure. Section 9.1.2) indicating a failure.
skipping to change at page 27, line 24 skipping to change at page 27, line 31
DTLSReassemblyFailure or DTLSPeerDisconnect (see DTLSReassemblyFailure or DTLSPeerDisconnect (see
Section 2.3.2.2). The AC MAY tear down the DTLS session if it Section 2.3.2.2). The AC MAY tear down the DTLS session if it
receives frequent DTLSDecapFailure notifications. The AC receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6). starts the DTLSSessionDelete timer (see Section 4.7.6).
Configure to Data Check (m): This state transition occurs when the Configure to Data Check (m): This state transition occurs when the
WTP and AC confirm the configuration. WTP and AC confirm the configuration.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Configuration Status Response message from the AC. The WTP Configuration Status Response message from the AC. The WTP
initializes the EchoInterval timer (see Section 4.7), and
transmits the Change State Event Request message (see transmits the Change State Event Request message (see
Section 8.6). Section 8.6).
AC: This state transition occurs when the AC receives the Change AC: This state transition occurs when the AC receives the Change
State Event Request message (see Section 8.6) from the WTP. State Event Request message (see Section 8.6) from the WTP.
The AC responds with a Change State Event Response message (see The AC responds with a Change State Event Response message (see
Section 8.7). The AC MUST start the DataCheckTimer timer and Section 8.7). The AC MUST start the DataCheckTimer timer and
stops the ChangeStatePendingTimer timer (see Section 4.7). stops the ChangeStatePendingTimer timer (see Section 4.7).
Data Check to DTLS Teardown (n): This transition occurs when the WTP Data Check to DTLS Teardown (n): This transition occurs when the WTP
skipping to change at page 28, line 14 skipping to change at page 28, line 18
Data Check to Run (o): This state transition occurs when the linkage Data Check to Run (o): This state transition occurs when the linkage
between the control and data channels is established, causing the between the control and data channels is established, causing the
WTP and AC to enter their normal state of operation. WTP and AC to enter their normal state of operation.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Change State Event Response message from the AC. The WTP Change State Event Response message from the AC. The WTP
initiates the data channel, which MAY require the establishment initiates the data channel, which MAY require the establishment
of a DTLS session, starts the DataChannelKeepAlive timer (see of a DTLS session, starts the DataChannelKeepAlive timer (see
Section 4.7.2) and transmits a Data Channel Keep Alive packet Section 4.7.2) and transmits a Data Channel Keep Alive packet
(see Section 4.4.1). The WTP then starts the (see Section 4.4.1). The WTP then starts the EchoInterval
DataChannelDeadInterval timer (see Section 4.7). timer and DataChannelDeadInterval timer (see Section 4.7).
AC: This state transition occurs when the AC receives the Data AC: This state transition occurs when the AC receives the Data
Channel Keep Alive packet (see Section 4.4.1), with a Session Channel Keep Alive packet (see Section 4.4.1), with a Session
ID message element matching that included by the WTP in the ID message element matching that included by the WTP in the
Join Request message. The AC disables the DataCheckTimer Join Request message. The AC disables the DataCheckTimer
timer. Note that if AC policy is to require the data channel timer. Note that if AC policy is to require the data channel
to be encrypted, this process would also require the to be encrypted, this process would also require the
establishment of a data channel DTLS session. Upon receiving establishment of a data channel DTLS session. Upon receiving
the Data Channel Keep Alive packet, the AC transmits its own the Data Channel Keep Alive packet, the AC transmits its own
Data Channel Keep Alive packet. Data Channel Keep Alive packet.
skipping to change at page 39, line 17 skipping to change at page 39, line 17
Certificate authorization by the AC and WTP is required so that only Certificate authorization by the AC and WTP is required so that only
an AC may perform the functions of an AC and that only a WTP may an AC may perform the functions of an AC and that only a WTP may
perform the functions of a WTP. This restriction of functions to the perform the functions of a WTP. This restriction of functions to the
AC or WTP requires that the certificates used by the AC MUST be AC or WTP requires that the certificates used by the AC MUST be
distinguishable from the certificate used by the WTP. To accomplish distinguishable from the certificate used by the WTP. To accomplish
this differentiation, the x.509 certificates MUST include the this differentiation, the x.509 certificates MUST include the
Extended Key Usage (EKU) certificate extension [RFC5280]. Extended Key Usage (EKU) certificate extension [RFC5280].
The EKU field indicates one or more purposes for which a certificate The EKU field indicates one or more purposes for which a certificate
may be used. It is an essential part in authorization. Its syntax may be used. It is an essential part in authorization. Its syntax
is as follows: is described in [RFC5280] and [ISO.9834-1.1993] and is as follows:
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER KeyPurposeId ::= OBJECT IDENTIFIER
Here we define two KeyPurposeId values, one for the WTP and one for Here we define two KeyPurposeId values, one for the WTP and one for
the AC. Inclusion of one of these two values indicates a certificate the AC. Inclusion of one of these two values indicates a certificate
is authorized for use by a WTP or AC, respectively. These values are is authorized for use by a WTP or AC, respectively. These values are
formatted as id-kp fields. formatted as id-kp fields.
skipping to change at page 40, line 5 skipping to change at page 40, line 5
Part of the CAPWAP certificate validation process includes ensuring Part of the CAPWAP certificate validation process includes ensuring
that the proper EKU is included and allowing the CAPWAP session to be that the proper EKU is included and allowing the CAPWAP session to be
established only if the extension properly represents the device. established only if the extension properly represents the device.
For instance, an AC SHOULD NOT accept a connection request from For instance, an AC SHOULD NOT accept a connection request from
another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is
present in the certificate. present in the certificate.
CAPWAP implementations MUST support certificates where the common CAPWAP implementations MUST support certificates where the common
name (CN) for both the WTP and AC is the MAC address of that device. name (CN) for both the WTP and AC is the MAC address of that device.
The MAC address MUST be formatted as ASCII HEX, e.g. The MAC address MUST be encoded in the PrintableString format, using
01:23:45:67:89:ab. Note that the CN field MAY contain either of the the well recognized MAC address format of 01:23:45:67:89:ab. The CN
EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64]
MAC Address formats. This seemingly unconventional use of the CN
field is consistent with other standards that rely on device
certificates that are provisioned during the manufacturing process,
such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX
[WiMAX]. See Section 12.8 for more information on the use of the MAC
Address in the CN field.
ACs and WTPs MUST authorize (e.g. through access control lists) ACs and WTPs MUST authorize (e.g. through access control lists)
certificates of devices to which they are connecting, e.g., based on certificates of devices to which they are connecting, e.g., based on
the issuer, MAC address, or organizational information specified in the issuer, MAC address, or organizational information specified in
the certificate. The identities specified in the certificates bind a the certificate. The identities specified in the certificates bind a
particular DTLS session to a specific pair of mutually-authenticated particular DTLS session to a specific pair of mutually-authenticated
and authorized MAC addresses. The particulars of authorization and authorized MAC addresses. The particulars of authorization
filter construction are implementation details which are, for the filter construction are implementation details which are, for the
most part, not within the scope of this specification. However, at most part, not within the scope of this specification. However, at
minimum, all devices MUST verify that the appropriate EKU bit is set minimum, all devices MUST verify that the appropriate EKU bit is set
skipping to change at page 41, line 23 skipping to change at page 41, line 23
the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is
the default transport protocol for the CAPWAP data channel. However, the default transport protocol for the CAPWAP data channel. However,
if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is
used for the CAPWAP data channel. used for the CAPWAP data channel.
This section describes how the CAPWAP protocol is carried over IP and This section describes how the CAPWAP protocol is carried over IP and
UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol
message element Section 4.6.14 describes the rules to use in message element Section 4.6.14 describes the rules to use in
determining which transport protocol is to be used. determining which transport protocol is to be used.
In order for CAPWAP to be compatible with potential middleboxes in
the network, CAPWAP implementations MUST send return traffic from the
same port on which it received traffic from a given peer. Further,
any unsolicited requests generated by a CAPWAP node MUST be sent on
the same port.
3.1. UDP Transport 3.1. UDP Transport
One of the CAPWAP protocol requirements is to allow a WTP to reside One of the CAPWAP protocol requirements is to allow a WTP to reside
behind a middlebox, firewall and/or Network Address Translation (NAT) behind a middlebox, firewall and/or Network Address Translation (NAT)
device. Since a CAPWAP session is initiated by the WTP (client) to device. Since a CAPWAP session is initiated by the WTP (client) to
the well-known UDP port of the AC (server), the use of UDP is a the well-known UDP port of the AC (server), the use of UDP is a
logical choice. When CAPWAP is run over IPv4, the UDP checksum field logical choice. When CAPWAP is run over IPv4, the UDP checksum field
in CAPWAP packets MUST be set to zero. in CAPWAP packets MUST be set to zero.
CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP protocol control packets sent from the WTP to the AC use the
skipping to change at page 42, line 23 skipping to change at page 42, line 32
A WTP and an AC will frequently not reside in the same IP subnet A WTP and an AC will frequently not reside in the same IP subnet
(broadcast domain). When this occurs, the WTP must be capable of (broadcast domain). When this occurs, the WTP must be capable of
discovering the AC, without requiring that multicast services are discovering the AC, without requiring that multicast services are
enabled in the network. enabled in the network.
When the WTP attempts to establish communication with an AC, it sends When the WTP attempts to establish communication with an AC, it sends
the Discovery Request message and receives the Discovery Response the Discovery Request message and receives the Discovery Response
message from the AC(s). The WTP MUST send the Discovery Request message from the AC(s). The WTP MUST send the Discovery Request
message to either the limited broadcast IP address (255.255.255.255), message to either the limited broadcast IP address (255.255.255.255),
a well known multicast address or to the unicast IP address of the the well known CAPWAP multicast address (xx.xx.xx.xx) or to the
AC. For IPv6 networks, since broadcast does not exist, the use of unicast IP address of the AC. For IPv6 networks, since broadcast
"All ACs multicast address" is used instead. Upon receipt of the does not exist, the use of "All ACs multicast address" is used
Discovery Request message, the AC sends a Discovery Response message instead. Upon receipt of the Discovery Request message, the AC sends
to the unicast IP address of the WTP, regardless of whether the a Discovery Response message to the unicast IP address of the WTP,
Discovery Request message was sent as a broadcast, multicast or regardless of whether the Discovery Request message was sent as a
unicast message. broadcast, multicast or unicast message.
WTP use of a limited IP broadcast, multicast or unicast IP address is WTP use of a limited IP broadcast, multicast or unicast IP address is
implementation dependent. implementation dependent. ACs, on the other hand, MUST support
broadcast, multicast and unicast discovery.
When a WTP transmits a Discovery Request message to a unicast When a WTP transmits a Discovery Request message to a unicast
address, the WTP must first obtain the IP address of the AC. Any address, the WTP must first obtain the IP address of the AC. Any
static configuration of an AC's IP address on the WTP non-volatile static configuration of an AC's IP address on the WTP non-volatile
storage is implementation dependent. However, additional dynamic storage is implementation dependent. However, additional dynamic
schemes are possible, for example: schemes are possible, for example:
DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on DHCP: See [I-D.ietf-capwap-dhc-ac-option] for more information on
the use of DHCP to discover AC IP addresses. the use of DHCP to discover AC IP addresses.
skipping to change at page 43, line 41 skipping to change at page 44, line 5
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 topology including firewall, NAT and middlebox in any network topology including firewall, NAT and middlebox
devices. devices.
It is important to note that the fragmentation mechanism employed by
CAPWAP has known limitations and deficiencies, which are similar to
those described in [RFC4963]. The limited size of the Fragment ID
field (see Section 4.3 can cause wrapping of the field, and hence
cause fragments from different datagrams to be incorrectly spliced
together (known as "mis-associated"). For example, a 100Mpbs link
with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause
the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP
implementors are warned to properly size their buffers for reassembly
purposes based on the expected wireless technology throughput.
CAPWAP implementations SHOULD perform MTU Discovery (see
Section 3.5), which can avoid the need for fragmentation. At the
time of writing of this specification, most enterprise switching and
routing infrastructure were capable of supporting "mini-jumbo" frames
(1800 bytes), which eliminates the need for fragmentation (assuming
the station's MTU is 1500 bytes). The need for fragmentation
typically continues to exist when the WTP communicates with the AC
over a Wide Area Network (WAN). Therefore, future versions of the
CAPWAP protocol SHOULD either consider increasing the size of the
Fragment ID field, or provide alternatives extensions.
3.5. MTU Discovery 3.5. MTU Discovery
Once a WTP has discovered the AC it wishes to establish a CAPWAP Once a WTP has discovered the AC it wishes to establish a CAPWAP
session with, it SHOULD perform a Path MTU (PMTU) discovery. One session with, it SHOULD perform a Path MTU (PMTU) discovery. One
recommendation for performing PMTU discovery is to have the WTP recommendation for performing PMTU discovery is to have the WTP
transmit Discovery Request (see Section 5.1) messages, and include transmit Discovery Request (see Section 5.1) messages, and include
the MTU Discovery Padding message element (see Section 4.6.31). The the MTU Discovery Padding message element (see Section 4.6.31). The
actual procedures used for PMTU discovery are described in [RFC1191], actual procedures used for PMTU discovery are described in [RFC1191],
for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively,
implementers MAY use the procedures defined in [RFC4821]. The WTP implementers MAY use the procedures defined in [RFC4821]. The WTP
skipping to change at page 47, line 27 skipping to change at page 47, line 27
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Version| Type | |Version| Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Version: A 4 bit field which contains the version of CAPWAP used in Version: A 4 bit field which contains the version of CAPWAP used in
this packet. The value for this specification is zero (0). this packet. The value for this specification is zero (0).
Payload Type: A 4 bit field which specifies the payload type that Type: A 4 bit field which specifies the payload type that follows
follows the UDP header. The following values are supported: the UDP header. The following values are supported:
0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3)
immediately follows the UDP header. If the packet is received immediately follows the UDP header. If the packet is received
on the CAPWAP data channel, the CAPWAP stack MUST treat the on the CAPWAP data channel, the CAPWAP stack MUST treat the
packet as a clear text CAPWAP data packet. If received on the packet as a clear text CAPWAP data packet. If received on the
CAPWAP control channel, the CAPWAP stack MUST treat the packet CAPWAP control channel, the CAPWAP stack MUST treat the packet
as a clear text CAPWAP control packet. If the control packet as a clear text CAPWAP control packet. If the control packet
is not a Discovery Request or Discovery Response packet, the is not a Discovery Request or Discovery Response packet, the
packet MUST be dropped. packet MUST be dropped.
skipping to change at page 49, line 10 skipping to change at page 49, line 10
the CAPWAP DTLS Header is present, the version number in both the CAPWAP DTLS Header is present, the version number in both
CAPWAP Preambles MUST match. The reason for this duplicate field CAPWAP Preambles MUST match. The reason for this duplicate field
is to avoid any possible tampering of the version field in the is to avoid any possible tampering of the version field in the
preamble which is not encrypted or authenticated. preamble which is not encrypted or authenticated.
HLEN: A 5 bit field containing the length of the CAPWAP transport HLEN: A 5 bit field containing the length of the CAPWAP transport
header in 4 byte words (Similar to IP header length). This length header in 4 byte words (Similar to IP header length). This length
includes the optional headers. includes the optional headers.
RID: A 5 bit field which contains the Radio ID number for this RID: A 5 bit field which contains the Radio ID number for this
packet. Given that MAC Addresses are not necessarily unique packet, whose value is between one (1) and 31. Given that MAC
across physical radios in a WTP, the Radio Identifier (RID) field Addresses are not necessarily unique across physical radios in a
is used to indicate which physical radio the message is associated WTP, the Radio Identifier (RID) field is used to indicate which
with. physical radio the message is associated with.
WBID: A 5 bit field which is the wireless binding identifier. The WBID: A 5 bit field which is the wireless binding identifier. The
identifier will indicate the type of wireless packet associated identifier will indicate the type of wireless packet associated
with the radio. The following values are defined: with the radio. The following values are defined:
0 - Reserved 0 - Reserved
1 - IEEE 802.11 1 - IEEE 802.11
2 - Reserved 2 - Reserved
skipping to change at page 50, line 19 skipping to change at page 50, line 19
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
supported by that implementation. Receivers MUST ignore all bits supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support. not defined for the version of the protocol they support.
Fragment ID: A 16 bit field whose value is assigned to each group of Fragment ID: A 16 bit field whose value is assigned to each group of
fragments making up a complete set. The fragment ID space is fragments making up a complete set. The fragment ID space is
managed individually for every WTP/AC pair. The value of Fragment managed individually for each direction for every WTP/AC pair.
ID is incremented with each new set of fragments. The Fragment ID The value of Fragment ID is incremented with each new set of
wraps to zero after the maximum value has been used to identify a fragments. The Fragment ID wraps to zero after the maximum value
set of fragments. has been used to identify a set of fragments.
Fragment Offset: A 13 bit field that indicates where in the payload Fragment Offset: A 13 bit field that indicates where in the payload
this fragment belongs during re-assembly. This field is valid this fragment belongs during re-assembly. This field is valid
when the 'F' bit is set to 1. The fragment offset is measured in when the 'F' bit is set to 1. The fragment offset is measured in
units of 8 octets (64 bits). The first fragment has offset zero. units of 8 octets (64 bits). The first fragment has offset zero.
Note the CAPWAP protocol does not allow for overlapping fragments. Note the CAPWAP protocol does not allow for overlapping fragments.
Reserved: The 3-bit field is reserved for future use. All Reserved: The 3-bit field is reserved for future use. All
implementations complying with this protocol MUST set to zero any implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by bits that are reserved in the version of the protocol supported by
skipping to change at page 57, line 32 skipping to change at page 57, line 32
When a WTP or AC receives a CAPWAP message with a message element When a WTP or AC receives a CAPWAP message with a message element
that the WTP or AC does not recognize, the CAPWAP message is that the WTP or AC does not recognize, the CAPWAP message is
discarded. If the received message was a Request message for which discarded. If the received message was a Request message for which
the corresponding Response message carries message elements, then a the corresponding Response message carries message elements, then a
corresponding Response message with a Result Code message element corresponding Response message with a Result Code message element
indicating "Failure - Unrecognized Message Element" and one or more indicating "Failure - Unrecognized Message Element" and one or more
Returned Message Element message elements is included, containing the Returned Message Element message elements is included, containing the
unrecognized message element(s). unrecognized message element(s).
4.5.2. Control Message Quality of Service 4.5.2. Quality of Service
The CAPWAP base protocol does not provide any Quality of Service
(QoS) recommendations for use with the CAPWAP data messages. Any
wireless specific CAPWAP binding specification that has QoS
requirements MUST define the application of QoS to the CAPWAP data
messages.
The IP header also includes the Explicit Congestion Notification
(ECN) bits [RFC3168]. When packets received from stations are
encapsulated by the WTP, the ECN bits are set to zero (0) in the
outer header. The WTP does not modify the ECN bits in the original
station's packet header. This mode of operation is detailed as the
"limited functionality option" in [RFC3168].
4.5.2.1. Applying QoS to CAPWAP Control Message
It is recommended that CAPWAP control messages be sent by both the AC It is recommended that CAPWAP control messages be sent by both the AC
and the WTP with an appropriate Quality of Service precedence value, and the WTP with an appropriate Quality of Service precedence value,
ensuring that congestion in the network minimizes occurrences of ensuring that congestion in the network minimizes occurrences of
CAPWAP control channel disconnects. Therefore, a Quality of Service CAPWAP control channel disconnects. Therefore, a Quality of Service
enabled CAPWAP device SHOULD use the following values: enabled CAPWAP device SHOULD use the following values:
802.1Q: The priority tag of 7 SHOULD be used. 802.1Q: The priority tag of 7 SHOULD be used.
DSCP: The DSCP value of 46 SHOULD be used. DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which
is described in [RFC2474]).
4.5.3. Retransmissions 4.5.3. Retransmissions
The CAPWAP control protocol operates as a reliable transport. For The CAPWAP control protocol operates as a reliable transport. For
each Request message, a Response message is defined, which is used to each Request message, a Response message is defined, which is used to
acknowledge receipt of the Request message. In addition, the control acknowledge receipt of the Request message. In addition, the control
header Sequence Number field is used to pair the Request and Response header Sequence Number field is used to pair the Request and Response
messages (see Section 4.5.1). messages (see Section 4.5.1).
Response messages are not explicitly acknowledged, therefore if a Response messages are not explicitly acknowledged, therefore if a
Response message is not received, the original Request message is Response message is not received, the original Request message is
retransmitted. retransmitted.
Implementations MUST keep track of the Sequence Number of the last Implementations MUST keep track of the Sequence Number of the last
received Request message, and MUST cache the corresponding Response received Request message, and MUST cache the corresponding Response
message. If a retransmission with the same Sequence Number is message. If a retransmission with the same Sequence Number is
received, the cached Response message MUST be retransmitted without received, the cached Response message MUST be retransmitted without
re-processing the Request. If an older Request message (with smaller re-processing the Request. If an older Request message is received,
Sequence Number modulo 32) is received, it MUST be ignored. A newer meaning one where the sequence number is smaller, it MUST be ignored.
Request message (with larger Sequence Number modulo 32) is processed A newer Request message, meaning one whose sequence number is larger,
as usual. is processed as usual.
Note: A sequence number is considered "smaller" when s1 is smaller
than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2
and (s1-s2)>128)
Both the WTP and the AC can only have a single request outstanding at Both the WTP and the AC can only have a single request outstanding at
any given time. Retransmitted Request messages MUST NOT be altered any given time. Retransmitted Request messages MUST NOT be altered
by the sender. by the sender.
After transmitting a Request message, the RetransmitInterval (see After transmitting a Request message, the RetransmitInterval (see
Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are
used to determine if the original Request message needs to be used to determine if the original Request message needs to be
retransmitted. The RetransmitInterval timer is used the first time retransmitted. The RetransmitInterval timer is used the first time
the Request is retransmitted. The timer is then doubled every the Request is retransmitted. The timer is then doubled every
skipping to change at page 58, line 38 skipping to change at page 59, line 10
If the sender stops retransmitting a Request message before reaching If the sender stops retransmitting a Request message before reaching
MaxRetransmit retransmissions (which leads to transition to DTLS MaxRetransmit retransmissions (which leads to transition to DTLS
Teardown, as described in Section 2.3.1), it cannot know whether the Teardown, as described in Section 2.3.1), it cannot know whether the
recipient received and processed the Request or not. In most recipient received and processed the Request or not. In most
situations, the sender SHOULD NOT do this, and instead continue situations, the sender SHOULD NOT do this, and instead continue
retransmitting until a Response message is received, or transition to retransmitting until a Response message is received, or transition to
DTLS Teardown occurs. However, if the sender does decide to continue DTLS Teardown occurs. However, if the sender does decide to continue
the connection with a new or modified Request message, the new the connection with a new or modified Request message, the new
message MUST have a new Sequence Number, and be treated as a new message MUST have a new Sequence Number, and be treated as a new
Request message by the receiver. Request message by the receiver. Note that there is a high chance
that both the WTP and the AC's sequence numbers will become out of
sync.
When a Request message is retransmitted, it MUST be re-encrypted via 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 59, line 46 skipping to change at page 60, line 20
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | | Value ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 16 bit Type field identifies the information carried in the Value The 16 bit Type field identifies the information carried in the Value
field and Length (16 bits) indicates the number of bytes in the Value field and Length (16 bits) indicates the number of bytes in the Value
field. Type field values are allocated as follows: field. The value of zero (0) is reserved and MUST NOT be used. The
rest of the Type field values are allocated as follows:
Usage Type Values Usage Type Values
CAPWAP Protocol Message Elements 1 - 1023 CAPWAP Protocol Message Elements 1 - 1023
IEEE 802.11 Message Elements 1024 - 2047 IEEE 802.11 Message Elements 1024 - 2047
Reserved for Future Use 2048 - 3071 Reserved for Future Use 2048 - 3071
EPCGlobal Message Elements 3072 - 4095 EPCGlobal Message Elements 3072 - 4095
Reserved for Future Use 4096 - 65024 Reserved for Future Use 4096 - 65535
The table below lists the CAPWAP protocol Message Elements and their The table below lists the CAPWAP protocol Message Elements and their
Type values. Type values.
CAPWAP Message Element Type Value CAPWAP Message Element Type Value
AC Descriptor 1 AC Descriptor 1
AC IPv4 List 2 AC IPv4 List 2
AC IPv6 List 3 AC IPv6 List 3
AC Name 4 AC Name 4
skipping to change at page 68, line 4 skipping to change at page 68, line 19
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Length | MAC Address ... | Radio ID | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name... | VLAN Name...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 8 for Add Station Type: 8 for Add Station
Length: >= 8 Length: >= 8
Radio ID: An 8-bit value representing the radio
Radio ID: An 8-bit value representing the radio, whose value is
between one (1) and 31.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The following formats,
and lengths, are supported [EUI-48] and [EUI-64]. and lengths, are supported [EUI-48] and [EUI-64].
MAC Address: The station's MAC Address MAC Address: The station's MAC Address
VLAN Name: An optional variable length UTF-8 encoded VLAN Name: An optional variable length UTF-8 encoded
string[RFC3629], with a maximum length of 512 octets, containing string[RFC3629], with a maximum length of 512 octets, containing
the VLAN Name on which the WTP is to locally bridge user data. the VLAN Name on which the WTP is to locally bridge user data.
Note this field is only valid with WTPs configured in Local MAC Note this field is only valid with WTPs configured in Local MAC
mode. mode.
4.6.9. CAPWAP Control IPv4 Address 4.6.9. CAPWAP Control IPv4 Address
The CAPWAP Control IPv4 Address message element is sent by the AC to The CAPWAP Control IPv4 Address message element is sent by the AC to
the WTP during the discovery process and is used by the AC to provide the WTP during the discovery process and is used by the AC to provide
the interfaces available on the AC, and the current number of WTPs the interfaces available on the AC, and the current number of WTPs
connected. When multiple CAPWAP Control IPV4 Address message connected. When multiple CAPWAP Control IPV4 Address message
elements are returned, the WTP SHOULD perform load balancing across elements are returned, the WTP SHOULD perform load balancing across
the multiple interfaces. the multiple interfaces (see Section 6.1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count | | WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Control IPv4 Address Type: 10 for CAPWAP Control IPv4 Address
Length: 6 Length: 6
IP Address: The IP Address of an interface. IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface, WTP Count: The number of WTPs currently connected to the interface,
with a maximum value of 65535. with a maximum value of 65535.
4.6.10. CAPWAP Control IPv6 Address 4.6.10. CAPWAP Control IPv6 Address
skipping to change at page 68, line 49 skipping to change at page 69, line 19
WTP Count: The number of WTPs currently connected to the interface, WTP Count: The number of WTPs currently connected to the interface,
with a maximum value of 65535. with a maximum value of 65535.
4.6.10. CAPWAP Control IPv6 Address 4.6.10. CAPWAP Control IPv6 Address
The CAPWAP Control IPv6 Address message element is sent by the AC to The CAPWAP Control IPv6 Address message element is sent by the AC to
the WTP during the discovery process and is used by the AC to provide the WTP during the discovery process and is used by the AC to provide
the interfaces available on the AC, and the current number of WTPs the interfaces available on the AC, and the current number of WTPs
connected. This message element is useful for the WTP to perform connected. This message element is useful for the WTP to perform
load balancing across multiple interfaces. load balancing across multiple interfaces (see Section 6.1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 72, line 6 skipping to change at page 72, line 19
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 51 for CAPWAP Transport Protocol Type: 51 for CAPWAP Transport Protocol
Length: 1 Length: 1
Transport: The transport to use for the CAPWAP data channel. The Transport: The transport to use for the CAPWAP data channel. The
following enumerated values are supported: following enumerated values are supported:
1 - UDP-Lite: The UDP-Lite transport protocol is to be used for 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for
the CAPWAP data channel. Note that this option is illegal is the CAPWAP data channel. Note that this option MUST NOT be
either the WTP or the AC uses IPv4. used if the CAPWAP control channel is being used over IPv4.
2 - UDP: The UDP transport protocol is to be used for the CAPWAP 2 - UDP: The UDP transport protocol is to be used for the CAPWAP
data channel. data channel.
4.6.15. Data Transfer Data 4.6.15. Data Transfer Data
The Data Transfer Data message element is used by the WTP to provide The Data Transfer Data message element is used by the WTP to provide
information to the AC for debugging purposes. information to the AC for debugging purposes.
0 1 2 3 0 1 2 3
skipping to change at page 73, line 48 skipping to change at page 74, line 16
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 | Length | MAC Address... | Radio ID |Num Of Entries | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report Type: 15 for Decryption Error Report
Length: >= 9 Length: >= 9
Radio ID: The Radio Identifier refers to an interface index on the Radio ID: The Radio Identifier refers to an interface index on the
WTP. WTP, whose value is between one (1) and 31.
Num of Entries: The number of instances of the Length/MAC Addresses Num of Entries: The number of instances of the Length/MAC Addresses
fields in the array. This field MUST NOT exceed the value of 255. fields in the array. This field MUST NOT exceed the value of 255.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The following formats,
and lengths, are supported [EUI-48] and [EUI-64]. and lengths, are supported [EUI-48] and [EUI-64].
MAC Address: MAC addresses of the station that has caused MAC Address: MAC addresses of the station that has caused
decryption errors. decryption errors.
skipping to change at page 74, line 33 skipping to change at page 74, line 46
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 | Report Interval | | Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for Decryption Error Report Period Type: 16 for Decryption Error Report Period
Length: 3 Length: 3
Radio ID: The Radio Identifier refers to an interface index on the Radio ID: The Radio Identifier refers to an interface index on the
WTP. WTP, whose value is between one (1) and 31.
Report Interval: A 16-bit unsigned integer indicating the time, in Report Interval: A 16-bit unsigned integer indicating the time, in
seconds. The default value for this message element can be found seconds. The default value for this message element can be found
in Section 4.7.11. in Section 4.7.11.
4.6.19. Delete MAC ACL Entry 4.6.19. 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.
skipping to change at page 75, line 38 skipping to change at page 76, line 4
Event Request message, to inform the AC that a particular station is Event Request message, to inform the AC that a particular station is
no longer being provided service. This could occur as a result of an no longer being provided service. This could occur as a result of an
Idle Timeout (see section 4.4.43), due to internal resource shortages Idle Timeout (see section 4.4.43), due to internal resource shortages
or for some other reason. or for some other reason.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Length | MAC Address... | Radio ID | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18 for Delete Station Type: 18 for Delete Station
Length: >= 8 Length: >= 8
Radio ID: An 8-bit value representing the radio Radio ID: An 8-bit value representing the radio, whose value is
between one (1) and 31.
Length: The length of the MAC Address field. The following formats, Length: The length of the MAC Address field. The following formats,
and lengths, are supported [EUI-48] and [EUI-64]. and lengths, are supported [EUI-48] and [EUI-64].
MAC Address: The station's MAC Address MAC Address: The station's MAC Address
4.6.21. Discovery Type 4.6.21. Discovery Type
The Discovery Type message element is used by the WTP to indicate how The Discovery Type message element is used by the WTP to indicate how
it has come to know about the existence of the AC to which it is it has come to know about the existence of the AC to which it is
skipping to change at page 82, line 31 skipping to change at page 83, line 10
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State | | Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 31 for Radio Administrative State Type: 31 for Radio Administrative State
Length: 2 Length: 2
Radio ID: An 8-bit value representing the radio to configure. The Radio ID: An 8-bit value representing the radio to configure, whose
Radio ID field MAY also include the value of 0xff, which is used value is between one (1) and 31. The Radio ID field MAY also
to identify the WTP. If an AC wishes to change the administrative include the value of 0xff, which is used to identify the WTP. If
state of a WTP, it includes 0xff in the Radio ID field. an AC wishes to change the administrative state of a WTP, it
includes 0xff in the Radio ID field.
Admin State: An 8-bit value representing the administrative state Admin State: An 8-bit value representing the administrative state
of the radio. The default value for the Admin State field is of the radio. The default value for the Admin State field is
listed in Section 4.8.1. The following enumerated values are listed in Section 4.8.1. The following enumerated values are
supported: supported:
0 - Reserved 0 - Reserved
1 - Enabled 1 - Enabled
skipping to change at page 83, line 21 skipping to change at page 84, line 4
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 | State | Cause | | Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 32 for Radio Operational State Type: 32 for Radio Operational State
Length: 3 Length: 3
Radio ID: The Radio Identifier refers to an interface index on the Radio ID: The Radio Identifier refers to an interface index on the
WTP. A value of 0xFF is invalid, as it is not possible to change WTP, whose value is between one (1) and 31. A value of 0xFF is
the WTP's operational state. invalid, as it is not possible to change the WTP's operational
state.
State: An 8-bit boolean value representing the state of the radio. State: An 8-bit boolean value representing the state of the radio.
The following enumerated values are supported: The following enumerated values are supported:
0 - Reserved 0 - Reserved
1 - Enabled 1 - Enabled
2 - Disabled 2 - Disabled
skipping to change at page 86, line 32 skipping to change at page 87, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 35 for Session ID Type: 35 for Session ID
Length: 32 Length: 16
Session ID: A 128-bit unsigned integer used as a random session Session ID: A 128-bit unsigned integer used as a random session
identifier identifier
4.6.37. Statistics Timer 4.6.37. Statistics Timer
The Statistics Timer message element value is used by the AC to The Statistics Timer message element value is used by the AC to
inform the WTP of the frequency with which it expects to receive inform the WTP of the frequency with which it expects to receive
updated statistics. updated statistics.
skipping to change at page 87, line 17 skipping to change at page 87, line 49
Statistics Timer: A 16-bit unsigned integer indicating the time, in Statistics Timer: A 16-bit unsigned integer indicating the time, in
seconds. The default value for this timer is specified in seconds. The default value for this timer is specified in
Section 4.7.14. Section 4.7.14.
4.6.38. Vendor Specific Payload 4.6.38. Vendor Specific Payload
The Vendor Specific Payload message element is used to communicate The Vendor Specific Payload message element is used to communicate
vendor specific information between the WTP and the AC. The Vendor vendor specific information between the WTP and the AC. The Vendor
Specific Payload message element MAY be present in any CAPWAP Specific Payload message element MAY be present in any CAPWAP
message. The message element uses the following format: message. The exchange of vendor specific data between the MUST NOT
modify the behavior of the base CAPWAP protocol and state machine.
The message element uses the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Data... | Element ID | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Payload Type: 37 for Vendor Specific Payload
skipping to change at page 89, line 27 skipping to change at page 90, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt| | Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element... | Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Descriptor Type: 39 for WTP Descriptor
Length: >= 31 Length: >= 33
Max Radios: An 8-bit value representing the number of radios (where Max Radios: An 8-bit value representing the number of radios (where
each radio is identified via the Radio ID field) supported by the each radio is identified via the Radio ID field) supported by the
WTP. WTP.
Radios in use: An 8-bit value representing the number of radios in Radios in use: An 8-bit value representing the number of radios in
use in the WTP. use in the WTP.
Num Encrypt: The number of 3 byte Encryption Sub-Elements that Num Encrypt: The number of 3 byte Encryption Sub-Elements that
follow this field. The value of the Num Encrypt field MUST be follow this field. The value of the Num Encrypt field MUST be
skipping to change at page 94, line 38 skipping to change at page 95, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Update Count | Channel Change Count | | Config Update Count | Channel Change Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Band Change Count | Current Noise Floor | | Band Change Count | Current Noise Floor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 47 for WTP Radio Statistics Type: 47 for WTP Radio Statistics
Length: 20 Length: 20
Radio ID: The radio ID of the radio to which the statistics apply. Radio ID: The radio ID of the radio to which the statistics apply,
whose value is between one (1) and 31.
Last Failure Type: The last WTP failure. The following enumerated Last Failure Type: The last WTP failure. The following enumerated
values are supported: values are supported:
0 - Statistic Not Supported 0 - Statistic Not Supported
1 - Software Failure 1 - Software Failure
2 - Hardware Failure 2 - Hardware Failure
3 - Other Failure 3 - Other Failure
255 - Unknown (e.g., WTP doesn't keep track of info) 255 - Unknown (e.g., WTP doesn't keep track of info)
Reset Count: The number of times that that the radio has been Reset Count: The number of times that that the radio has been
reset. reset.
SW Failure Count: The number of times that the radio has failed due SW Failure Count: The number of times that the radio has failed due
to software related reasons. to software related reasons.
skipping to change at page 108, line 15 skipping to change at page 109, line 15
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 AC to indicate that it will or will Response message is used by the AC to indicate that it will or will
not provide service. not provide service.
6.1. Join Request 6.1. Join Request
The Join Request message is used by a WTP to request service through The Join Request message is used by a WTP to request service through
the AC. A Join Request message is sent by a WTP after (optionally) the AC. If the WTP is performing the optional AC discovery process
receiving one or more Discovery Response messages, and completion of (see Section 3.3), the join process occurs after the WTP has received
DTLS session establishment. When an AC receives a Join Request one or more Discovery Response messages. During the discovery
message it responds with a Join Response message. process, an AC MAY return more than one CAPWAP Control IPv4 Address
or CAPWAP Control IPv6 Address message elements. When more than one
such message element is returned, the WTP SHOULD perform "load
balancing" by choosing the interface that is servicing the least
number of WTPs (known through the WTP Count field of the message
element). Note, however, that other load balancing algorithms are
also permitted. Once the WTP has determined its preferred AC, and
its associated interface, to connect to, it establishes the DTLS
session, and transmits the Join Request over the secured control
channel. When an AC receives a Join Request message it responds with
a Join Response message.
Upon completion of the DTLS handshake, and receiving the Upon completion of the DTLS handshake, and receiving the
DTLSEstablished notification, the WTP sends the Join Request message DTLSEstablished notification, the WTP sends the Join Request message
to the AC. When the AC is notified of the DTLS session to the AC. When the AC is notified of the DTLS session
establishment, it does not clear the WaitDTLS timer until it has establishment, it does not clear the WaitDTLS timer until it has
received the Join Request message, at which time it sends a Join received the Join Request message, at which time it sends a Join
Response message to the WTP, indicating success or failure. Response message to the WTP, indicating success or failure.
One or more WTP Radio Information message elements (see Section 2.1) One or more WTP Radio Information message elements (see Section 2.1)
are included in the Join Request to request service for the CAPWAP are included in the Join Request to request service for the CAPWAP
skipping to change at page 112, line 19 skipping to change at page 113, line 19
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 Image
(see Section 2.3) to determine the state of the control connection Data or Run state (see Section 2.3) to determine the state of the
between the WTP and the AC. The Echo Request message is sent by the control connection between the WTP and the AC. The Echo Request
WTP when the EchoInterval timer expires. message is sent by the WTP when the EchoInterval timer expires.
The Echo Request message is sent by the WTP when in the Run State. The 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 following message elements MAY be included in the Echo Request The following message elements MAY be included in the Echo Request
message: message:
o Vendor Specific Payload, see Section 4.6.38 o Vendor Specific Payload, see Section 4.6.38
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
skipping to change at page 122, line 18 skipping to change at page 123, line 18
gathering statistics, logging, and firmware management. The gathering statistics, logging, and firmware management. The
management operations defined in this section are used by the AC to management operations defined in this section are used by the AC to
either push/pull information to/from the WTP, or request that the WTP either push/pull information to/from the WTP, or request that the WTP
reboot. This section does not deal with the management of the AC per reboot. This section does not deal with the management of the AC per
se, and assumes that the AC is operational and configured. se, and assumes that the AC is operational and configured.
9.1. Firmware Management 9.1. Firmware Management
This section describes the firmware download procedures used by the This section describes the firmware download procedures used by the
CAPWAP protocol. Firmware download can occur during the Image Data CAPWAP protocol. Firmware download can occur during the Image Data
or Run state. or Run state. The former allows the download to occur at boot time,
while the latter is used to trigger the download while an active
CAPWAP session exists. It is important to note that the CAPWAP
protocol does not provide the ability for the AC to identify whether
the firmware information provided by the WTP is correct, nor whether
the WTP is properly storing the firmware (see Section 12.10 for more
information.
Figure 6 provides an example of a WTP that performs a firmware Figure 6 provides an example of a WTP that performs a firmware
upgrade while in the Image Data state. In this example, the WTP does upgrade while in the Image Data state. In this example, the WTP does
not already have the requested firmware (Image Identifier = x), and not already have the requested firmware (Image Identifier = x), and
downloads the image from the AC. downloads the image from the AC.
WTP AC WTP AC
Join Request Join Request
--------------------------------------------------------> -------------------------------------------------------->
skipping to change at page 136, line 16 skipping to change at page 137, line 16
There are three specific situations in which a NAT deployment may be There are three specific situations in which a NAT deployment may be
used in conjunction with a CAPWAP-enabled deployment. The first used in conjunction with a CAPWAP-enabled deployment. The first
consists of a configuration in which a single WTP is behind a NAT consists of a configuration in which a single WTP is behind a NAT
system. Since all communication is initiated by the WTP, and all system. Since all communication is initiated by the WTP, and all
communication is performed over IP using two UDP ports, the protocol communication is performed over IP using two UDP ports, the protocol
easily traverses NAT systems in this configuration. easily traverses NAT systems in this configuration.
In the second case, two or more WTPs are deployed behind the same NAT In the second case, two or more WTPs are deployed behind the same NAT
system. Here, the AC would receive multiple connection requests from system. Here, the AC would receive multiple connection requests from
the same IP address, and cannot differentiate the originating WTP of the same IP address, and therefore cannot use the WTP's IP address
the connection requests. The CAPWAP Data Check state, which alone to bind the CAPWAP control and data channel. The CAPWAP Data
establishes the data plane connection and communicates the CAPWAP Check state, which establishes the data plane connection and
Data Channel Keepalive, includes the Session Identifier message communicates the CAPWAP Data Channel Keepalive, includes the Session
element, which is used to bind the control and data plane. Use of Identifier message element, which is used to bind the control and
the Session Identifier message element enables the AC to match the data plane. Use of the Session Identifier message element enables
control and data plane flows from multiple WTPs behind the same NAT the AC to match the control and data plane flows from multiple WTPs
system (multiple WTPs sharing the same IP address). behind the same NAT system (multiple WTPs sharing the same IP
address). CAPWAP implementations MUST also use DTLS session
information on any encrypted CAPWAP channel to validate the source of
both the control and data plane, as described in Section 12.2.
In the third configuration, the AC is deployed behind a NAT. Two In the third configuration, the AC is deployed behind a NAT. In this
issues exist in this situation. First, an AC communicates its case, the AC is not reachable by the WTP unless a specific rule has
interfaces and corresponding WTP load using the CAPWAP Control IPv4 been configured on the NAT to translate the address and redirect
Address and CAPWAP Control IPv6 Address message elements. This CAPWAP messages to the AC. This deployment presents two issues.
message element is mandatory, but contains invalid information if a First, an AC communicates its interfaces and corresponding WTP load
middlebox is present between the AC and WTP. The WTP MUST NOT using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address
utilize the information in these message elements if it detects a NAT message elements. This message element is mandatory, but contains IP
(as described in the CAPWAP Transport Protocol message element). addresses that are only valid in the private address space used by
Note this would disable the load balancing capabilities of the CAPWAP the AC, which is not reachable by the WTP. The WTP MUST NOT utilize
protocol. Alternatively, the AC could have a configured NAT'ed the information in these message elements if it detects a NAT (as
address, which it would include in either of the two control address described in the CAPWAP Transport Protocol message element in
message elements. Section 4.6.14). Second, since the addresses cannot be used by the
WTP, this effectively disables the load balancing capabilities (see
Section 6.1) of the CAPWAP protocol. Alternatively, the AC could
have a configured NAT'ed address, which it would include in either of
the two control address message elements, and the NAT would need to
be configured accordingly.
In order for a CAPWAP WTP or AC to detect whether a middlebox is In order for a CAPWAP WTP or AC to detect whether a middlebox is
present, both the Join Request (see Section 6.1) and the Join present, both the Join Request (see Section 6.1) and the Join
Response (see Section 6.2) include either the CAPWAP Local IPv4 Response (see Section 6.2) include either the CAPWAP Local IPv4
Address (see Section 4.6.11), or the CAPWAP Local IPv6 Address (see Address (see Section 4.6.11), or the CAPWAP Local IPv6 Address (see
Section 4.6.12) message element. Upon receiving one of these Section 4.6.12) message element. Upon receiving one of these
messages, if the packet's source IP address differs from the address messages, if the packet's source IP address differs from the address
found in either one of these message elements, it indicates that a found in either one of these message elements, it indicates that a
middlebox is present. middlebox is present.
In order for CAPWAP to be compatible with potential middleboxes in
the network, CAPWAP implementations MUST send return traffic from the
same port on which it received traffic from a given peer. Further,
any unsolicited requests generated by a CAPWAP node MUST be sent on
the same port.
Note that this middlebox detection technique is not foolproof. If
the public IP address assigned to the NAT is identical to the private
IP address used by the AC, detection by the WTP would fail. This
failure can lead to various protocol errors, so it is therefore
necessary for deployments to ensure that the NAT's IP address is not
the same as the ACs.
The CAPWAP protocol allows for all of the AC identities supporting a The CAPWAP protocol allows for all of the AC identities supporting a
group of WTPs to be communicated through the AC List message element. group of WTPs to be communicated through the AC List message element.
This feature MUST be ignored by the WTP when it detects the AC is This feature MUST be ignored by the WTP when it detects the AC is
behind a middlebox. behind a middlebox.
The CAPWAP protocol allows an AC to configure a static IP address on The CAPWAP protocol allows an AC to configure a static IP address on
a WTP using the WTP Static IP Address Information message element. a WTP using the WTP Static IP Address Information message element.
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
skipping to change at page 139, line 48 skipping to change at page 140, line 48
12.1.5. Use of MD5 12.1.5. Use of MD5
The Image Information Section 4.6.27) message element makes use of The Image Information Section 4.6.27) message element makes use of
MD5 to compute the hash field. The authenticity and integrity of the MD5 to compute the hash field. The authenticity and integrity of the
image file is protected by DTLS, and in this context, MD5 is not used image file is protected by DTLS, and in this context, MD5 is not used
as a cryptographically secure hash, but just as a basic checksum. as a cryptographically secure hash, but just as a basic checksum.
Therefore, the use of MD5 is not considered a security vulnerability, Therefore, the use of MD5 is not considered a security vulnerability,
and no mechanisms for algorithm agility are provided. and no mechanisms for algorithm agility are provided.
12.1.6. CAPWAP Fragmentation
RFC 4963 [RFC4963] describes a possible security vulnerability where
a malicious entity can "corrupt" a flow by injecting fragments. By
sending "high" fragments (those with offset greater than zero) with a
forged source address, the attacker can deliberately cause
corruption. The use of DTLS on the CAPWAP Data channel can be used
to avoid this possible vulnerability.
12.2. Session ID Security 12.2. Session ID Security
Since DTLS does not export a unique session identifier, there can be Since DTLS does not export a unique session identifier, there can be
no explicit protocol binding between the DTLS layer and CAPWAP layer. no explicit protocol binding between the DTLS layer and CAPWAP layer.
As a result, implementations MUST provide a mechanism for performing As a result, implementations MUST provide a mechanism for performing
this binding. For example, an AC MUST NOT associate decrypted DTLS this binding. For example, an AC MUST NOT associate decrypted DTLS
control packets with a particular WTP session based solely on the control packets with a particular WTP session based solely on the
Session ID in the packet header. Instead, identification should be Session ID in the packet header. Instead, identification should be
done based on which DTLS session decrypted the packet. Otherwise one done based on which DTLS session decrypted the packet. Otherwise one
authenticated WTP could spoof another authenticated WTP by altering authenticated WTP could spoof another authenticated WTP by altering
skipping to change at page 144, line 12 skipping to change at page 145, line 21
Proper validation of certificates typically requires checking to Proper validation of certificates typically requires checking to
ensure the certificate has not yet expired. If devices have a real- ensure the certificate has not yet expired. If devices have a real-
time clock, they SHOULD verify the certificate validity dates. If no time clock, they SHOULD verify the certificate validity dates. If no
real-time clock is available, the device SHOULD make a best-effort real-time clock is available, the device SHOULD make a best-effort
attempt to validate the certificate validity dates through other attempt to validate the certificate validity dates through other
means. Failure to check a certificate's temporal validity can make a means. Failure to check a certificate's temporal validity can make a
device vulnerable to man-in-the-middle attacks launched using device vulnerable to man-in-the-middle attacks launched using
compromised, expired certificates, and therefore devices should make compromised, expired certificates, and therefore devices should make
every effort to perform this validation. every effort to perform this validation.
12.8. AAA Security 12.8. Use of MAC Address in CN Field
The CAPWAP protocol is an evolution of an existing protocol
[I-D.ohara-capwap-lwapp] which is implemented on a large number of
already deployed ACs and WTPs. Everyone of these devices have an
existing X.509 certificate, which is provisioned at manufacturing
time. These X.509 certificates use the device's MAC Address in the
Common Name (CN) field. It is well understood that encoding the MAC
Address in the CN field is less than optimal, and using the
SubjectAltName field would be preferable. However, at the time of
publication, there is no URN specification that allows for the MAC
Address to be used in the SubjectAltName field. As such a
specification is published by the IETF, future versions of the CAPWAP
protocol MAY require support for the new URN scheme.
12.9. AAA Security
The AAA protocol is used to distribute EAP keys to the ACs, and The AAA protocol is used to distribute EAP keys to the ACs, and
consequently its security is important to the overall system consequently its security is important to the overall system
security. When used with TLS or IPsec, security guidelines specified security. When used with TLS or IPsec, security guidelines specified
in RFC 3539 [RFC3539] SHOULD be followed. in RFC 3539 [RFC3539] SHOULD be followed.
In general, the link between the AC and AAA server SHOULD be secured In general, the link between the AC and AAA server SHOULD be secured
using a strong ciphersuite keyed with mutually authenticated session using a strong ciphersuite keyed with mutually authenticated session
keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared
secret authentication as it is often vulnerable to dictionary secret authentication as it is often vulnerable to dictionary
attacks, but rather SHOULD use stronger underlying security attacks, but rather SHOULD use stronger underlying security
mechanisms. mechanisms.
12.10. WTP Firmware
The CAPWAP protocol defines a mechanism by which the AC downloads new
firmware to the WTP. During the session establishment process, the
WTP provides information about its current firmware to the AC. The
AC then decides whether the WTP's firmware needs to be updated. It
is important to note that the CAPWAP specification makes the explicit
assumption that the WTP is providing the correct firmware version to
the AC, and is therefore not lying. Fruther, during the firmware
download process, the CAPWAP protocol does not provide any mechanisms
to recognize whether the WTP is actually storing the firmware for
future use.
13. Operational Considerations 13. Operational Considerations
The CAPWAP protocol assumes that it is the only configuration The CAPWAP protocol assumes that it is the only configuration
interface to the WTP to configure parameters that are specified in interface to the WTP to configure parameters that are specified in
the CAPWAP specifications. While the use of a separate management the CAPWAP specifications. While the use of a separate management
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.
skipping to change at page 146, line 29 skipping to change at page 148, line 29
AC. The WG discussed various options for providing congestion AC. The WG discussed various options for providing congestion
control on this channel. However, due to performance problems with control on this channel. However, due to performance problems with
TCP when it is run over another congestion control mechanism and the TCP when it is run over another congestion control mechanism and the
fact that the vast majority of traffic run over the CAPWAP data fact that the vast majority of traffic run over the CAPWAP data
channel is likely to be congestion-controlled IP traffic, the CAPWAP channel is likely to be congestion-controlled IP traffic, the CAPWAP
WG felt that specifying a congestion control mechanism for the CAPWAP WG felt that specifying a congestion control mechanism for the CAPWAP
data channel would be more likely to cause problems than to resolve data channel would be more likely to cause problems than to resolve
any. any.
Because there is no congestion control mechanism specified for the Because there is no congestion control mechanism specified for the
CAPWAP data channel, it is recommended that non-congestion-controlled CAPWAP data channel, it is RECOMMENDED that non-congestion-controlled
traffic not be tunneled over CAPWAP. When a significant amount of traffic not be tunneled over CAPWAP. When a significant amount of
non-congestion-controlled traffic is expected to be present on a non-congestion-controlled traffic is expected to be present on a
WLAN, the CAPWAP connection between the AC and the WTP for that LAN WLAN, the CAPWAP connection between the AC and the WTP for that LAN
should be configured to remain in Local MAC mode with Distribution should be configured to remain in Local MAC mode with Distribution
function at the WTP. function at the WTP.
The lock step nature of the CAPWAP protocol's control channel can The lock step nature of the CAPWAP protocol's control channel can
cause the firmware download process to take some time, depending upon cause the firmware download process to take some time, depending upon
the RTT. This is not expected to be a problem since the CAPWAP the RTT. This is not expected to be a problem since the CAPWAP
protocol allows firmware to be downloaded while the WTP provides protocol allows firmware to be downloaded while the WTP provides
service to wireless clients/devices. service to wireless clients/devices.
It is necessary for the WTP and AC to configure their MTU based on It is necessary for the WTP and AC to configure their MTU based on
the capabilities of the path. See Section 3.5 for more information. the capabilities of the path. See Section 3.5 for more information.
The CAPWAP protocol supports Explicit Congestion Notification (ECN)
through mode of operation named "limited functionality option",
detailed in [RFC3168]. Future versions of the CAPWAP protocol should
consider supporting the "full functionality option", which may
require some explicit signalling within the CAPWAP control protocol.
15. IANA Considerations 15. IANA Considerations
This section details the actions to be taken by IANA during the This section details the actions to be taken by IANA during the
publication of the specification. There are numerous registries that publication of the specification. There are numerous registries that
need to be created, and the contents, document action (see [RFC5226], need to be created, and the contents, document action (see [RFC5226],
and registry format are all included below. Note that in cases where and registry format are all included below. Note that in cases where
bit fields are referred to, the bit numbering is left to right, where bit fields are referred to, the bit numbering is left to right, where
the leftmost bit is labelled as bit zero (0). the leftmost bit is labelled as bit zero (0).
For registration requests where an Expert Review is required, a For registration requests where an Expert Review is required, a
skipping to change at page 147, line 33 skipping to change at page 149, line 33
post a request to the CAPWAP WG mailing list (or a successor post a request to the CAPWAP WG mailing list (or a successor
designated by the Area Director) for comment and review. Before a designated by the Area Director) for comment and review. Before a
period of 30 days has passed, the Designated Expert will either period of 30 days has passed, the Designated Expert will either
approve or deny the registration request and publish a notice of the approve or deny the registration request and publish a notice of the
decision to the CAPWAP WG mailing list or its successor, as well as decision to the CAPWAP WG mailing list or its successor, as well as
informing IANA. A denial notice must be justified by an explanation, informing IANA. A denial notice must be justified by an explanation,
and in the cases where it is possible, concrete suggestions on how and in the cases where it is possible, concrete suggestions on how
the request can be modified so as to become acceptable should be the request can be modified so as to become acceptable should be
provided. provided.
15.1. Multicast Address 15.1. IPv4 Multicast Address
This document requires a new organization local multicast address This document requires a new IPv4 multicast address called
called the "All ACs multicast address" from the IPv6 multicast "capwap-ac" from the Local Network Control Block IPv4 multicast
address registry [to be removed upon publication address registry [to be removed upon publication
http://www.iana.org/assignments/multicast-addresses]. The new
multicast address is to replace the text xx.xx.xx.xx in Section 3.3.
15.2. IPv6 Multicast Address
This document requires a new organization local multicast address
called the "All ACs multicast address" from the Variable Scope IPv6
multicast address registry [to be removed upon publication
http://www.iana.org/assignments/ipv6-multicast-addresses]. The new http://www.iana.org/assignments/ipv6-multicast-addresses]. The new
multicast address is to be inserted in Section 3.3. multicast address is to be inserted in Section 3.3.
15.2. UDP Port 15.3. UDP Port
This document requires a two UDP Ports organization local multicast This document requires a two UDP Ports organization local multicast
address from the registered port numbers registry [to be removed upon address from the registered port numbers registry [to be removed upon
publication http://www.iana.org/assignments/port-numbers]. The new publication http://www.iana.org/assignments/port-numbers]. The new
UDP Ports numbers have already been assigned and can be found in UDP Ports numbers have already been assigned and can be found in
Section 3.1. The following values are being registered: Section 3.1. The following values are being registered:
Keyword Decimal Description References Keyword Decimal Description References
------- ------- ----------- ---------- ------- ------- ----------- ----------
capwap-control 5246/udp CAPWAP Control Protocol This Document capwap-control 5246/udp CAPWAP Control Protocol This Document
capwap-data 5247/udp CAPWAP Data Protocol This Document capwap-data 5247/udp CAPWAP Data Protocol This Document
15.3. CAPWAP Message Types 15.4. CAPWAP Message Types
The Message Type field in the CAPWAP header (see Section 4.5.1.1) is The Message Type field in the CAPWAP header (see Section 4.5.1.1) is
used to identify the operation performed by the message. There are used 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 [RFC5226]. of the field containing the IANA Enterprise Number [RFC5226].
IANA will create and maintain the CAPWAP Message Types registry for IANA will create and maintain the CAPWAP Message Types registry for
all message types whose Enterprise Number is set to zero (0). The all message types whose Enterprise Number is set to zero (0). The
namespace is 32 bits (0-4294967295), where the value of zero (0) is namespace is 32 bits (0-4294967295), where the value of zero (0) is
reserved and must not be assigned. The values one (1) through 26 are reserved and must not be assigned. The values one (1) through 26 are
allocated in this specification, and can be found in Section 4.5.1.1. allocated in this specification, and can be found in Section 4.5.1.1.
Any new assignments of a CAPWAP Message Type, whose Enterprise Number Any new assignments of a CAPWAP Message Type, whose Enterprise Number
is set to zero (0) requires a Expert Review. The format of the is set to zero (0) requires a Expert Review. The format of the
registry to be maintained by IANA has the following format: registry to be maintained by IANA has the following format:
CAPWAP Control Message Message Type Reference CAPWAP Control Message Message Type Reference
Value Value
15.4. CAPWAP Header Flags 15.5. CAPWAP Header Flags
The Flags field in the CAPWAP header (see Section 4.3) is 9 bits in The Flags field in the CAPWAP header (see Section 4.3) is 9 bits in
length and is used to identify any special treatment related to the length and is used to identify any special treatment related to the
message. This specification defines bits zero (0) through five (5), message. This specification defines bits zero (0) through five (5),
while bits six (6) through eight (8) are reserved. There are while bits six (6) through eight (8) are reserved. There are
currently three unused, reserved bits which are managed by IANA and currently three unused, reserved bits which are managed by IANA and
whose assignment requires a Expert Review. IANA will create the whose assignment requires a Expert Review. IANA will create the
CAPWAP Header Flags registry, whose format is: CAPWAP Header Flags registry, whose format is:
Flag Field Name Bit Position Reference Flag Field Name Bit Position Reference
15.5. CAPWAP Control Message Flags 15.6. CAPWAP Control Message Flags
The Flags field in the CAPWAP Control Message header (see The Flags field in the CAPWAP Control Message header (see
Section 4.5.1.4) is used to identify any special treatment related to Section 4.5.1.4) is used to identify any special treatment related to
the control message. There are currently eight (8) unused, reserved the control message. There are currently eight (8) unused, reserved
bits. These bits whose assignment is managed by IANA and requires a bits. These bits whose assignment is managed by IANA and requires a
Expert Review. IANA will create the CAPWAP Control Message Flags Expert Review. IANA will create the CAPWAP Control Message Flags
registry, whose format is: registry, whose format is:
Flag Field Name Bit Position Reference Flag Field Name Bit Position Reference
15.6. CAPWAP Message Element Type 15.7. CAPWAP Message Element Type
The Type field in the CAPWAP Message Element header (see Section 4.6) The Type field in the CAPWAP Message Element header (see Section 4.6)
is used to identify the data being transported. The namespace is 16 is used to identify the data being transported. The namespace is 16
bits (0-65535), where the value of zero (0) is reserved and must not bits (0-65535), where the value of zero (0) is reserved and must not
be assigned. The values one (1) through 52 are allocated in this be assigned. The values one (1) through 52 are allocated in this
specification, and can be found in Section 4.5.1.1. specification, and can be found in Section 4.5.1.1.
The 16 bit namespace is further divided into blocks of addresses that The 16 bit namespace is further divided into blocks of addresses that
are reserved for specific CAPWAP wireless bindings. The following are reserved for specific CAPWAP wireless bindings. The following
blocks are reserved: blocks are reserved:
skipping to change at page 149, line 20 skipping to change at page 151, line 30
CAPWAP Protocol Message Elements 1 - 1023 CAPWAP Protocol Message Elements 1 - 1023
IEEE 802.11 Message Elements 1024 - 2047 IEEE 802.11 Message Elements 1024 - 2047
EPCGlobal Message Elements 3072 - 4095 EPCGlobal Message Elements 3072 - 4095
This namespace is managed by IANA and assignments require a Expert This namespace is managed by IANA and assignments require a Expert
Review. IANA will create the CAPWAP Message Element Type registry, Review. IANA will create the CAPWAP Message Element Type registry,
whose format is: whose format is:
CAPWAP Message Element Type Value Reference CAPWAP Message Element Type Value Reference
15.7. Wireless Binding Identifiers 15.8. Wireless Binding Identifiers
The Wireless Binding Identifier (WBID) field in the CAPWAP header The Wireless Binding Identifier (WBID) field in the CAPWAP header
(see Section 4.3) is used to identify the wireless technology (see Section 4.3) is used to identify the wireless technology
associated with the packet. This specification allocates the values associated with the packet. This specification allocates the values
one (1) and three (3). Due to the limited address space available, a one (1) and three (3). Due to the limited address space available, a
new WBID request requires Expert Review. IANA will create the CAPWAP new WBID request requires Expert Review. IANA will create the CAPWAP
Wireless Binding Identifier registry, whose format is: Wireless Binding Identifier registry, whose format is:
CAPWAP Wireless Binding Identifier Type Value Reference CAPWAP Wireless Binding Identifier Type Value Reference
15.8. AC Security Types 15.9. AC Security Types
The Security field in the AC Descriptor message element (see The Security field in the AC Descriptor message element (see
Section 4.6.1) is 8 bits in length and used to identify the Section 4.6.1) is 8 bits in length and used to identify the
authentication methods available on the AC. This specification authentication methods available on the AC. This specification
defines bits five (5) and six (6), while bits zero (0) through four defines bits five (5) and six (6), while bits zero (0) through four
(4) as well as bit seven (7) are reserved and unused. These reserved (4) as well as bit seven (7) are reserved and unused. These reserved
bits are managed by IANA and assignment requires a Standards Action. bits are managed by IANA and assignment requires a Standards Action.
IANA will create the AC Security Types registry, whose format is: IANA will create the AC Security Types registry, whose format is:
AC Security Type Bit Position Reference AC Security Type Bit Position Reference
15.9. AC DTLS Policy 15.10. AC DTLS Policy
The DTLS Policy field in the AC Descriptor message element (see The DTLS Policy field in the AC Descriptor message element (see
Section 4.6.1) is 8 bits in length and used to identify whether the Section 4.6.1) is 8 bits in length and used to identify whether the
CAPWAP Data Channel is to be secured. This specification defines CAPWAP Data Channel is to be secured. This specification defines
bits five (5) and six (6), while bits zero (0) through four (4) as bits five (5) and six (6), while bits zero (0) through four (4) as
well as bit seven (7) are reserved and unused. These reserved bits well as bit seven (7) are reserved and unused. These reserved bits
are managed by IANA and assignment requires a Standards Action. IANA are managed by IANA and assignment requires a Standards Action. IANA
will create the AC DTLS Policy registry, whose format is: will create the AC DTLS Policy registry, whose format is:
AC DTLS Policy Bit Position Reference AC DTLS Policy Bit Position Reference
15.10. AC Information Type 15.11. AC Information Type
The Information Type field in the AC Descriptor message element (see The Information Type field in the AC Descriptor message element (see
Section 4.6.1) is used to represent information about the AC. The Section 4.6.1) is used to represent information about the AC. The
namespace is 16 bits (0-65535), where the value of zero (0) is namespace is 16 bits (0-65535), where the value of zero (0) is
reserved and must not be assigned. This field, combined with the AC reserved and must not be assigned. This field, combined with the AC
Information Vendor ID, allows vendors to use a private namespace. Information Vendor ID, allows vendors to use a private namespace.
This specification defines the AC Information Type namespace when the This specification defines the AC Information Type namespace when the
AC Information Vendor ID is set to zero (0), for which the values AC Information Vendor ID is set to zero (0), for which the values
four (4) and five (5) are allocated in this specification, and can be four (4) and five (5) are allocated in this specification, and can be
found in Section 4.6.1. This namespace is managed by IANA and found in Section 4.6.1. This namespace is managed by IANA and
assignments require a Expert Review. IANA will create the AC assignments require a Expert Review. IANA will create the AC
Information Type registry, whose format is: Information Type registry, whose format is:
AC Information Type Type Value Reference AC Information Type Type Value Reference
15.11. CAPWAP Transport Protocol Types 15.12. CAPWAP Transport Protocol Types
The Transport field in the CAPWAP Transport Protocol message element The Transport field in the CAPWAP Transport Protocol message element
(see Section 4.6.14) is used to identify the transport to use for the (see Section 4.6.14) is used to identify the transport to use for the
CAPWAP Data Channel. The namespace is 8 bits (0-255), where the CAPWAP Data Channel. The namespace is 8 bits (0-255), where the
value of zero (0) is reserved and must not be assigned. The values value of zero (0) is reserved and must not be assigned. The values
one (1) and two (2) are allocated in this specification, and can be one (1) and two (2) are allocated in this specification, and can be
found in Section 4.6.14. This namespace is managed by IANA and found in Section 4.6.14. This namespace is managed by IANA and
assignments require a Expert Review. IANA will create the CAPWAP assignments require a Expert Review. IANA will create the CAPWAP
Transport Protocol Types registry, whose format is: Transport Protocol Types registry, whose format is:
CAPWAP Transport Protocol Type Type Value Reference CAPWAP Transport Protocol Type Type Value Reference
15.12. Data Transfer Type 15.13. Data Transfer Type
The Data Type field in the Data Transfer Data message element (see The Data Type field in the Data Transfer Data message element (see
Section 4.6.15) and Image Data message element (see Section 4.6.25) Section 4.6.15) and Image Data message element (see Section 4.6.25)
is used to provide information about the data being carried. The is used to provide information about the data being carried. The
namespace is 8 bits (0-255), where the value of zero (0) is reserved namespace is 8 bits (0-255), where the value of zero (0) is reserved
and must not be assigned. The values one (1), two (2) and five (5) and must not be assigned. The values one (1), two (2) and five (5)
are allocated in this specification, and can be found in are allocated in this specification, and can be found in
Section 4.6.15. This namespace is managed by IANA and assignments Section 4.6.15. This namespace is managed by IANA and assignments
require a Expert Review. IANA will create the Data Transfer Type require a Expert Review. IANA will create the Data Transfer Type
registry, whose format is: registry, whose format is:
Data Transfer Type Type Value Reference Data Transfer Type Type Value Reference
15.13. Data Transfer Mode 15.14. Data Transfer Mode
The Data Mode field in the Data Transfer Data message element (see The Data Mode field in the Data Transfer Data message element (see
Section 4.6.15) and Data Transfer Mode message element (see Section 4.6.15) and Data Transfer Mode message element (see
Section 15.13) is used to provide information about the data being Section 15.14) is used to provide information about the data being
carried. The namespace is 8 bits (0-255), where the value of zero carried. The namespace is 8 bits (0-255), where the value of zero
(0) is reserved and must not be assigned. The values one (1) and two (0) is reserved and must not be assigned. The values one (1) and two
(2) are allocated in this specification, and can be found in (2) are allocated in this specification, and can be found in
Section 15.13. This namespace is managed by IANA and assignments Section 15.14. This namespace is managed by IANA and assignments
require a Expert Review. IANA will create the Data Transfer Mode require a Expert Review. IANA will create the Data Transfer Mode
registry, whose format is: registry, whose format is:
Data Transfer Mode Type Value Reference Data Transfer Mode Type Value Reference
15.14. Discovery Types 15.15. Discovery Types
The Discovery Type field in the Discovery Type message element (see The Discovery Type field in the Discovery Type message element (see
Section 4.6.21) is used by the WTP to indicate to the AC how it was Section 4.6.21) is used by the WTP to indicate to the AC how it was
discovered. The namespace is 8 bits (0-255). The values zero (0) discovered. The namespace is 8 bits (0-255). The values zero (0)
through four (4) are allocated in this specification, and can be through four (4) are allocated in this specification, and can be
found in Section 4.6.21. This namespace is managed by IANA and found in Section 4.6.21. This namespace is managed by IANA and
assignments require a Expert Review. IANA will create the Discovery assignments require a Expert Review. IANA will create the Discovery
Types registry, whose format is: Types registry, whose format is:
Discovery Types Type Value Reference Discovery Types Type Value Reference
15.15. Radio Admin State 15.16. Radio Admin State
The Radio Admin field in the Radio Administrative State message The Radio Admin field in the Radio Administrative State message
element (see Section 4.6.32) is used by the WTP to represent the element (see Section 4.6.32) is used by the WTP to represent the
state of its radios. The namespace is 8 bits (0-255), where the state of its radios. The namespace is 8 bits (0-255), where the
value of zero (0) is reserved and must not be assigned. The values value of zero (0) is reserved and must not be assigned. The values
one (1) and two (2) are allocated in this specification, and can be one (1) and two (2) are allocated in this specification, and can be
found in Section 4.6.32. This namespace is managed by IANA and found in Section 4.6.32. This namespace is managed by IANA and
assignments require a Expert Review. IANA will create the Radio assignments require a Expert Review. IANA will create the Radio
Admin State registry, whose format is: Admin State registry, whose format is:
Radio Admin State Type Value Reference Radio Admin State Type Value Reference
15.16. Radio Operational State 15.17. Radio Operational State
The State field in the Radio Operational State message element (see The State field in the Radio Operational State message element (see
Section 4.6.33) is used by the WTP to represent the operational state Section 4.6.33) is used by the WTP to represent the operational state
of its radios. The namespace is 8 bits (0-255), where the value of of its radios. The namespace is 8 bits (0-255), where the value of
zero (0) is reserved and must not be assigned. The values one (1) zero (0) is reserved and must not be assigned. The values one (1)
and two (2) are allocated in this specification, and can be found in and two (2) are allocated in this specification, and can be found in
Section 4.6.33. This namespace is managed by IANA and assignments Section 4.6.33. This namespace is managed by IANA and assignments
require a Expert Review. IANA will create the Radio Operational require a Expert Review. IANA will create the Radio Operational
State registry, whose format is: State registry, whose format is:
Radio Operational State Type Value Reference Radio Operational State Type Value Reference
15.17. Radio Failure Causes 15.18. Radio Failure Causes
The Cause field in the Radio Operational State message element (see The Cause field in the Radio Operational State message element (see
Section 4.6.33) is used by the WTP to represent the reason why a Section 4.6.33) is used by the WTP to represent the reason why a
radio may have failed. The namespace is 8 bits (0-255), where the radio may have failed. The namespace is 8 bits (0-255), where the
value of zero (0) through three (3) are allocated in this value of zero (0) through three (3) are allocated in this
specification, and can be found in Section 4.6.33. This namespace is specification, and can be found in Section 4.6.33. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the Radio Failure Causes registry, whose format is: create the Radio Failure Causes registry, whose format is:
Radio Failure Causes Type Value Reference Radio Failure Causes Type Value Reference
15.18. Result Code 15.19. Result Code
The Result Code field in the Result Code message element (see The Result Code field in the Result Code message element (see
Section 4.6.34) is used to indicate the success, or failure, of a Section 4.6.34) is used to indicate the success, or failure, of a
CAPWAP control message. The namespace is 32 bits (0-4294967295), CAPWAP control message. The namespace is 32 bits (0-4294967295),
where the value of zero (0) through 22 are allocated in this where the value of zero (0) through 22 are allocated in this
specification, and can be found in Section 4.6.34. This namespace is specification, and can be found in Section 4.6.34. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the Result Code registry, whose format is: create the Result Code registry, whose format is:
Result Code Type Value Reference Result Code Type Value Reference
15.19. Returned Message Element Reason 15.20. Returned Message Element Reason
The Reason field in the Returned Message Element message element (see The Reason field in the Returned Message Element message element (see
Section 4.6.35) is used to indicate the reason why a message element Section 4.6.35) is used to indicate the reason why a message element
was not processed successfully. The namespace is 8 bits (0-255), was not processed successfully. The namespace is 8 bits (0-255),
where the value of zero (0) is reserved and must not be assigned. where the value of zero (0) is reserved and must not be assigned.
The values one (1) through four (4) are allocated in this The values one (1) through four (4) are allocated in this
specification, and can be found in Section 4.6.35. This namespace is specification, and can be found in Section 4.6.35. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the Returned Message Element Reason registry, whose format is: create the Returned Message Element Reason registry, whose format is:
Returned Message Element Reason Type Value Reference Returned Message Element Reason Type Value Reference
15.20. WTP Board Data Type 15.21. WTP Board Data Type
The Board Data Type field in the WTP Board Data message element (see The Board Data Type field in the WTP Board Data message element (see
Section 4.6.39) is used to represent information about the WTP Section 4.6.39) is used to represent information about the WTP
hardware. The namespace is 16 bits (0-65535). The WTP Board Data hardware. The namespace is 16 bits (0-65535). The WTP Board Data
Type values zero (0) through four (4) are allocated in this Type values zero (0) through four (4) are allocated in this
specification, and can be found in Section 4.6.39. This namespace is specification, and can be found in Section 4.6.39. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the WTP Board Data Type registry, whose format is: create the WTP Board Data Type registry, whose format is:
WTP Board Data Type Type Value Reference WTP Board Data Type Type Value Reference
15.21. WTP Descriptor Type 15.22. WTP Descriptor Type
The Descriptor Type field in the WTP Descriptor message element (see The Descriptor Type field in the WTP Descriptor message element (see
Section 4.6.40) is used to represent information about the WTP Section 4.6.40) is used to represent information about the WTP
software. The namespace is 16 bits (0-65535). This field, combined software. The namespace is 16 bits (0-65535). This field, combined
with the Descriptor Vendor ID, allows vendors to use a private with the Descriptor Vendor ID, allows vendors to use a private
namespace. This specification defines the WTP Descriptor Type namespace. This specification defines the WTP Descriptor Type
namespace when the Descriptor Vendor ID is set to zero (0), for which namespace when the Descriptor Vendor ID is set to zero (0), for which
the values zero (0) through three (3) are allocated in this the values zero (0) through three (3) are allocated in this
specification, and can be found in Section 4.6.40. This namespace is specification, and can be found in Section 4.6.40. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the WTP Board Data Type registry, whose format is: create the WTP Board Data Type registry, whose format is:
WTP Descriptor Type Type Value Reference WTP Descriptor Type Type Value Reference
15.22. WTP Fallback Mode 15.23. WTP Fallback Mode
The Mode field in the WTP Fallback message element (see The Mode field in the WTP Fallback message element (see
Section 4.6.41) is used to indicate to the WTP the type of AC Section 4.6.41) is used to indicate to the WTP the type of AC
fallback mechanism it should employ. The namespace is 8 bits fallback mechanism it should employ. The namespace is 8 bits
(0-255), where the value of zero (0) is reserved and must not be (0-255), where the value of zero (0) is reserved and must not be
assigned. The values one (1) and two (2) are allocated in this assigned. The values one (1) and two (2) are allocated in this
specification, and can be found in Section 4.6.41. This namespace is specification, and can be found in Section 4.6.41. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the WTP Fallback Mode registry, whose format is: create the WTP Fallback Mode registry, whose format is:
WTP Fallback Mode Type Value Reference WTP Fallback Mode Type Value Reference
15.23. WTP Frame Tunnel Mode 15.24. WTP Frame Tunnel Mode
The Tunnel Type field in the WTP Frame Tunnel Mode message element The Tunnel Type field in the WTP Frame Tunnel Mode message element
(see Section 4.6.42) is 8 bits and is used to indicate the type of (see Section 4.6.42) is 8 bits and is used to indicate the type of
tunneling to use between the WTP and the AC. This specification tunneling to use between the WTP and the AC. This specification
defines bits four (4) through six (6), while bits zero (0) through defines bits four (4) through six (6), while bits zero (0) through
four (4) as well as bit seven (7) are reserved and unused. These four (4) as well as bit seven (7) are reserved and unused. These
reserved bits are managed by IANA and assignment requires a Expert reserved bits are managed by IANA and assignment requires a Expert
Review. IANA will create the AC DTLS Policy registry, whose format Review. IANA will create the AC DTLS Policy registry, whose format
is: is:
WTP Frame Tunnel Mode Bit Position Reference WTP Frame Tunnel Mode Bit Position Reference
15.24. WTP MAC Type 15.25. WTP MAC Type
The MAC Type field in the WTP MAC Type message element (see The MAC Type field in the WTP MAC Type message element (see
Section 4.6.43) is used to indicate the type of MAC to use in Section 4.6.43) is used to indicate the type of MAC to use in
tunneled frames between the WTP and the AC. The namespace is 8 bits tunneled frames between the WTP and the AC. The namespace is 8 bits
(0-255), where the value of zero (0) through two (2) are allocated in (0-255), where the value of zero (0) through two (2) are allocated in
this specification, and can be found in Section 4.6.43. This this specification, and can be found in Section 4.6.43. This
namespace is managed by IANA and assignments require a Expert Review. namespace is managed by IANA and assignments require a Expert Review.
IANA will create the WTP MAC Type registry, whose format is: IANA will create the WTP MAC Type registry, whose format is:
WTP MAC Type Type Value Reference WTP MAC Type Type Value Reference
15.25. WTP Radio Stats Failure Type 15.26. WTP Radio Stats Failure Type
The Last Failure Type field in the WTP Radio Statistics message The Last Failure Type field in the WTP Radio Statistics message
element (see Section 4.6.45) is used to indicate the last WTP element (see Section 4.6.45) is used to indicate the last WTP
failure. The namespace is 8 bits (0-255), where the value of zero failure. The namespace is 8 bits (0-255), where the value of zero
(0) through three (3) as well as the value 255 are allocated in this (0) through three (3) as well as the value 255 are allocated in this
specification, and can be found in Section 4.6.45. This namespace is specification, and can be found in Section 4.6.45. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the WTP Radio Stats Failure Type registry, whose format is: create the WTP Radio Stats Failure Type registry, whose format is:
WTP Radio Stats Failure Type Type Value Reference WTP Radio Stats Failure Type Type Value Reference
15.26. WTP Reboot Stats Failure Type 15.27. WTP Reboot Stats Failure Type
The Last Failure Type field in the WTP Reboot Statistics message The Last Failure Type field in the WTP Reboot Statistics message
element (see Section 4.6.46) is used to indicate the last reboot element (see Section 4.6.46) is used to indicate the last reboot
reason. The namespace is 8 bits (0-255), where the value of zero (0) reason. The namespace is 8 bits (0-255), where the value of zero (0)
through five (5) as well as the value 255 are allocated in this through five (5) as well as the value 255 are allocated in this
specification, and can be found in Section 4.6.46. This namespace is specification, and can be found in Section 4.6.46. This namespace is
managed by IANA and assignments require a Expert Review. IANA will managed by IANA and assignments require a Expert Review. IANA will
create the WTP Reboot Stats Failure Type registry, whose format is: create the WTP Reboot Stats Failure Type registry, whose format is:
WTP Reboot Stats Failure Type Type Value Reference WTP Reboot Stats Failure Type Type Value Reference
skipping to change at page 156, line 9 skipping to change at page 158, line 9
Eronen, Saravanan Govindan, Peter Nilsson, David Perkins and Yong Eronen, Saravanan Govindan, Peter Nilsson, David Perkins and Yong
Zhang. Zhang.
Michael Vakulenko contributed text to describe how CAPWAP can be used Michael Vakulenko contributed text to describe how CAPWAP can be used
over layer 3 (IP/UDP) networks. over layer 3 (IP/UDP) networks.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
Requirement Levels", BCP 14, RFC 2119, March 1997. November 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
Housley, R., and W. Polk, "Internet X.509 Public Key for IP version 6", RFC 1981, August 1996.
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
(IPv6) Specification", RFC 2460, December 1998. Errors at High Data Rates", RFC 4963, July 2007.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
for IP version 6", RFC 1981, August 1996. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
specifying the location of services (DNS SRV)", RFC 2782, Housley, R., and W. Polk, "Internet X.509 Public Key
February 2000. Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [ISO.9834-1.1993]
10646", STD 63, RFC 3629, November 2003. International Organization for Standardization,
"Procedures for the operation of OSI registration
authorities - part 1: general procedures", ISO Standard
9834-1, 1993.
[I-D.ietf-capwap-protocol-binding-ieee80211] [I-D.ietf-capwap-protocol-binding-ieee80211]
Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP
Protocol Binding for IEEE 802.11", Protocol Binding for IEEE 802.11",
draft-ietf-capwap-protocol-binding-ieee80211-08 (work in draft-ietf-capwap-protocol-binding-ieee80211-10 (work in
progress), September 2008. progress), September 2008.
[I-D.ietf-capwap-dhc-ac-option] [I-D.ietf-capwap-dhc-ac-option]
Calhoun, P., "CAPWAP Access Controller DHCP Option", Calhoun, P., "CAPWAP Access Controller DHCP Option",
draft-ietf-capwap-dhc-ac-option-01 (work in progress), draft-ietf-capwap-dhc-ac-option-01 (work in progress),
March 2008. March 2008.
[FRAME-EXT] [FRAME-EXT]
IEEE, "IEEE Standard 802.3as-2006", 2005. IEEE, "IEEE Standard 802.3as-2006", 2005.
17.2. Informational References 17.2. Informational References
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
"Objectives for Control and Provisioning of Wireless "Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006. Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[I-D.ohara-capwap-lwapp] [I-D.ohara-capwap-lwapp]
Calhoun, P., "Light Weight Access Point Protocol", Calhoun, P., "Light Weight Access Point Protocol",
draft-ohara-capwap-lwapp-04 (work in progress), draft-ohara-capwap-lwapp-04 (work in progress),
March 2007. March 2007.
[I-D.narasimhan-ietf-slapp] [I-D.narasimhan-ietf-slapp]
Narasimhan, P., "SLAPP : Secure Light Access Point Narasimhan, P., "SLAPP : Secure Light Access Point
Protocol", draft-narasimhan-ietf-slapp-01 (work in Protocol", draft-narasimhan-ietf-slapp-01 (work in
progress), March 2006. progress), March 2006.
skipping to change at page 159, line 5 skipping to change at page 160, line 44
[EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique
Identifier", Dec 2005. Identifier", Dec 2005.
[EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY". REGISTRATION AUTHORITY".
[EPCGlobal] [EPCGlobal]
"See http://www.epcglobalinc.org/home". "See http://www.epcglobalinc.org/home".
[PacketCable]
"PacketCable Security Specification PKT-SP-SEC-I12-
050812", August 2005, <PacketCable>.
[CableLabs]
"OpenCable System Security Specification OC-SP-SEC-I07-
061031", October 2006, <CableLabs>.
[WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved
Specification V1.0.1", April 2008, <WiMAX>.
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-902-3240 Phone: +1 408-902-3240
Email: pcalhoun@cisco.com Email: pcalhoun@cisco.com
 End of changes. 119 change blocks. 
294 lines changed or deleted 489 lines changed or added

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