draft-ietf-capwap-protocol-binding-ieee80211-05.txt   draft-ietf-capwap-protocol-binding-ieee80211-06.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 19, 2008 M. Montemurro, Editor Expires: August 24, 2008 M. Montemurro, Editor
Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
November 16, 2007 February 21, 2008
CAPWAP Protocol Binding for IEEE 802.11 CAPWAP Protocol Binding for IEEE 802.11
draft-ietf-capwap-protocol-binding-ieee80211-05 draft-ietf-capwap-protocol-binding-ieee80211-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Wireless LAN product architectures have evolved from single Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized autonomous access points to systems consisting of a centralized
Access Controller (AC) and Wireless Termination Points (WTPs). The Access Controller (AC) and Wireless Termination Points (WTPs). The
general goal of centralized control architectures is to move access general goal of centralized control architectures is to move access
control, including user authentication and authorization, mobility control, including user authentication and authorization, mobility
management and radio management from the single access point to a management and radio management from the single access point to a
centralized controller. centralized controller.
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol Binding Specification for use with Access Points (CAPWAP) Protocol Binding Specification for use with
the IEEE 802.11 Wireless Local Area Network protocol. The CAPWAP the IEEE 802.11 Wireless Local Area Network protocol. The CAPWAP
Protocol Specification is defined separately [3]. Protocol Specification is defined separately [3].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6
2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6
2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 12
2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 13
2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 14
2.5. Quality of Service for IEEE 802.11 MAC Management
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 15
3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 16
3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 16
3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 17
4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 18
5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 20
5.1. Discovery Request Message . . . . . . . . . . . . . . . . 20
5.2. Discovery Response Message . . . . . . . . . . . . . . . . 20
5.3. Primary Discovery Request Message . . . . . . . . . . . . 20
5.4. Primary Discovery Response Message . . . . . . . . . . . . 20
5.5. Join Request Message . . . . . . . . . . . . . . . . . . . 20
5.6. Join Response Message . . . . . . . . . . . . . . . . . . 21
5.7. Configuration Status Message . . . . . . . . . . . . . . . 21
5.8. Configuration Status Response Message . . . . . . . . . . 21
5.9. Configuration Update Request Message . . . . . . . . . . . 22
5.10. Station Configuration Request . . . . . . . . . . . . . . 23
5.11. Change State Event Request . . . . . . . . . . . . . . . . 23
5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 23
6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 24
6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 24
6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 28
6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 29
6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 30
6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 30
6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 31
6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 32
6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 34
6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 34
6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 35
6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 36
6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 37
6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 39
6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 40
6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 40
6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 42
6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 46
6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 46
6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 47
6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 47
6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 48
6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 50
6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 51
6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 53
6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 53
7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 55
7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 55
7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 55
7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 55
7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 55
7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 55
7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 55
7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 55
7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 55
8. Technology Specific Message Element Values . . . . . . . . . . 56
9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 57
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.1. Normative References . . . . . . . . . . . . . . . . . . . 61
12.2. Informational References . . . . . . . . . . . . . . . . . 61
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 63
1. Introduction 1. Introduction
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol Binding Specification for use with Access Points (CAPWAP) Protocol Binding Specification for use with
the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP
control message fields, new control messages and message elements are control message fields, new control messages and message elements are
defined. The minimum required definitions for a binding-specific defined. The minimum required definitions for a binding-specific
Statistics message element, Station message element, and WTP Radio Statistics message element, Station message element, and WTP Radio
Information message element are included. Information message element are included.
skipping to change at page 6, line 4 skipping to change at page 7, line 4
Classifying AC Classifying AC
Scheduling WTP/AC Scheduling WTP/AC
Queuing WTP Queuing WTP
IEEE 802.11 RSN IEEE 802.11 RSN
IEEE 802.1X/EAP AC IEEE 802.1X/EAP AC
RSNA Key Management AC RSNA Key Management AC
IEEE 802.11 Encryption/Decryption WTP/AC IEEE 802.11 Encryption/Decryption WTP/AC
Figure 1: Mapping of 802.11 Functions for Split MAC Architecture Figure 1: Mapping of 802.11 Functions for Split MAC Architecture
In a Split MAC Architecture,the Distribution and Integration services In a Split MAC Architecture, the Distribution and Integration
reside on the AC, and therefore all user data is tunneled between the services reside on the AC, and therefore all user data is tunneled
WTP and the AC. As noted above, all real-time IEEE 802.11 services, between the WTP and the AC. As noted above, all real-time IEEE
including the Beacon and Probe Response frames, are handled on the 802.11 services, including the Beacon and Probe Response frames, are
WTP. handled on the WTP.
All remaining IEEE 802.11 MAC management frames are supported on the All remaining IEEE 802.11 MAC management frames are supported on the
AC, including the Association Request frame which allows the AC to be AC, including the Association Request frame which allows the AC to be
involved in the access policy enforcement portion of the IEEE 802.11 involved in the access policy enforcement portion of the IEEE 802.11
protocol. The IEEE 802.1X and IEEE 802.11 key management function protocol. The IEEE 802.1X and IEEE 802.11 key management function
are also located on the AC. This implies that the AAA client also are also located on the AC. This implies that the AAA client also
resides on the AC. resides on the AC.
While the admission control component of IEEE 802.11 resides on the While the admission control component of IEEE 802.11 resides on the
AC, the real time scheduling and queuing functions are on the WTP. AC, the real time scheduling and queuing functions are on the WTP.
skipping to change at page 7, line 25 skipping to change at page 8, line 25
o The WTP processes the Probe Request frame and responds with a o The WTP processes the Probe Request frame and responds with a
corresponding Probe Response frame. The Probe Request frame is corresponding Probe Response frame. The Probe Request frame is
then forwarded to the AC for optional processing. then forwarded to the AC for optional processing.
o The WTP forwards the IEEEE 802.11 Authentication and Association o The WTP forwards the IEEEE 802.11 Authentication and Association
frames to the AC, which is responsible for responding to the frames to the AC, which is responsible for responding to the
client. client.
o Once the association is complete, the AC transmits a Station o Once the association is complete, the AC transmits a Station
Configuration Request message, which includes an Add Station Configuration Request message, which includes an Add Station
message element, to the WTP (see Section 4.5.8 in [3]). In the message element, to the WTP (see Section 4.6.8 in [3]). In the
above example, the WLAN was configured for IEEE 802.1X. above example, the WLAN was configured for IEEE 802.1X.
o If the WTP is providing encryption/decryption services, once the o If the WTP is providing encryption/decryption services, once the
client has completed the IEEE 802.11 key exchange, the AC client has completed the IEEE 802.11 key exchange, the AC
transmits another Station Configuration Request message which transmits another Station Configuration Request message which
includes an Add Station message element, an IEEE 802.11 Station includes an Add Station message element, an IEEE 802.11 Station
message element, an IEEE 802.11 Station Session Key message message element, an IEEE 802.11 Station Session Key message
element and an IEEE 802.11 Information Element message element element and an IEEE 802.11 Information Element message element
which includes the RSNIE to the WTP, delivering the security which includes the RSNIE to the WTP, delivering the security
policy to enforce for the station (in this case AES-CCMP), and the policy to enforce for the station (in this case AES-CCMP), and the
skipping to change at page 8, line 5 skipping to change at page 9, line 5
o All IEEE 802.11 station data frames are tunneled between the WTP o All IEEE 802.11 station data frames are tunneled between the WTP
and the AC. and the AC.
The WTP SHALL include the IEEE 802.11 MAC header contents in all The WTP SHALL include the IEEE 802.11 MAC header contents in all
frames transmitted to the AC. frames transmitted to the AC.
When 802.11 encryption/decryption is performed at the WTP, the WTP When 802.11 encryption/decryption is performed at the WTP, the WTP
MUST decrypt the uplink frames, MUST set the Protected Frame field to MUST decrypt the uplink frames, MUST set the Protected Frame field to
0, and MUST make the frame format consistent with that of an 0, and MUST make the frame format consistent with that of an
unprotected 802.11 frame prior to transmitting the frames to the AC. unprotected 802.11 frame prior to transmitting the frames to the AC.
The fields added to an 802.11 protected frame, i.e., IV/EIV, MIC,and The fields added to an 802.11 protected frame (i.e., IV/EIV, MIC, and
ICV , MUST be stripped off prior to transmission from the WTP to AC. ICV) MUST be stripped off prior to transmission from the WTP to AC.
For downlink frames, the Protected Frame field MUST be set to 0 by For downlink frames, the Protected Frame field MUST be set to 0 by
the AC as the frame being sent is unencrypted. The WTP MUST apply the AC as the frame being sent is unencrypted. The WTP MUST apply
the required protection policy for the WLAN, and set the Protected the required protection policy for the WLAN, and set the Protected
Frame field on transmission over the air. The Protected Frame field Frame field on transmission over the air. The Protected Frame field
always needs to accurately indicate the status of the 802.11 frame always needs to accurately indicate the status of the 802.11 frame
that is carrying it. that is carrying it.
When 802.11 encryption/decryption is performed at the AC,the WTP When 802.11 encryption/decryption is performed at the AC,the WTP
SHALL NOT decrypt the uplink frames prior to transmitting the frames SHALL NOT decrypt the uplink frames prior to transmitting the frames
to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header
skipping to change at page 10, line 50 skipping to change at page 11, line 50
element. element.
o The WTP processes a Probe Request frame and responds with a o The WTP processes a Probe Request frame and responds with a
corresponding Probe Response frame. corresponding Probe Response frame.
o The WTP forwards the IEEE 802.11 Authentication and Association o The WTP forwards the IEEE 802.11 Authentication and Association
frames to the AC. frames to the AC.
o Once the association is complete, the AC transmits a Station o Once the association is complete, the AC transmits a Station
Configuration Request message, which includes the Add Station Configuration Request message, which includes the Add Station
message element, to the WTP (see Section 10.1 in [3]). In the message element, to the WTP (see Section 4.6.8 in [3]). In the
above example, the WLAN is configured for IEEE 802.1X, and above example, the WLAN is configured for IEEE 802.1X, and
therefore the '802.1X only' policy bit is enabled. therefore the '802.1X only' policy bit is enabled.
o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange
messages to the AC for processing. messages to the AC for processing.
o The AC transmits another Station Configuration Request message o The AC transmits another Station Configuration Request message
including an Add Station message element, an IEEE 802.11 Station including an Add Station message element, an IEEE 802.11 Station
message element, an IEEE 802.11 Station Session Key message message element, an IEEE 802.11 Station Session Key message
element and an IEEE 802.11 Information Element message element element and an IEEE 802.11 Information Element message element
skipping to change at page 15, line 10 skipping to change at page 16, line 10
When the AC sends a WLAN Configuration Request message (see When the AC sends a WLAN Configuration Request message (see
Section 3.1) or receives the corresponding WLAN Configuration Section 3.1) or receives the corresponding WLAN Configuration
Response message (see Section 3.2) from the WTP, it remains in the Response message (see Section 3.2) from the WTP, it remains in the
Run state. Run state.
3. IEEE 802.11 Specific CAPWAP Control Messages 3. IEEE 802.11 Specific CAPWAP Control Messages
This section defines CAPWAP Control Messages that are specific to the This section defines CAPWAP Control Messages that are specific to the
IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN
Configuration Request and IEEE 802.11 WLAN Configuration Response. Configuration Request and IEEE 802.11 WLAN Configuration Response.
See Section 4.4 in [3] for CAPWAP Control message definitions and the See Section 4.5 in [3] for CAPWAP Control message definitions and the
derivation of the Message Type value from the IANA Enterprise number. derivation of the Message Type value from the IANA Enterprise number.
The valid message types for IEEE 802.11 specific control messages are The valid message types for IEEE 802.11 specific control messages are
listed below. The IANA Enterprise number used with these messages is listed below. The IANA Enterprise number used with these messages is
13277. 13277.
CAPWAP Control Message Message Type CAPWAP Control Message Message Type
Value Value
IEEE 802.11 WLAN Configuration Request 3398912 IEEE 802.11 WLAN Configuration Request 3398912
IEEE 802.11 WLAN Configuration Response 3398913 IEEE 802.11 WLAN Configuration Response 3398913
3.1. IEEE 802.11 WLAN Configuration Request 3.1. IEEE 802.11 WLAN Configuration Request
The IEEE 802.11 WLAN Configuration Request is sent by the AC to the The IEEE 802.11 WLAN Configuration Request is sent by the AC to the
WTP in order to change services provided by the WTP. This control WTP in order to change services provided by the WTP. This control
message is used to either create, update or delete a WLAN on the WTP. message is used to either create, update or delete a WLAN on the WTP.
The IEEE 802.11 WLAN Configuration Request is sent as a result of The IEEE 802.11 WLAN Configuration Request is sent as a result of
either some manual admistrative process (e.g., deleting a WLAN), or either some manual administrative process (e.g., deleting a WLAN), or
automatically to create a WLAN on a WTP. When sent automatically to automatically to create a WLAN on a WTP. When sent automatically to
create a WLAN, this control message is sent after the CAPWAP create a WLAN, this control message is sent after the CAPWAP
Configuration Update Request message (see Section 8.5 in [3]) has Configuration Update Request message (see Section 8.4 in [3]) has
been received by the WTP. been received by the WTP.
Upon receiving this control message, the WTP will modify the Upon receiving this control message, the WTP will modify the
necessary services, and transmit an IEEE 802.11 WLAN Configuration necessary services, and transmit an IEEE 802.11 WLAN Configuration
Response. Response.
A WTP MAY provide service for more than one WLAN, therefore every A WTP MAY provide service for more than one WLAN, therefore every
WLAN is identified through a numerical index. For instance, a WTP WLAN is identified through a numerical index. For instance, a WTP
that is capable of supporting up to 16 SSIDs, could accept up to 16 that is capable of supporting up to 16 SSIDs, could accept up to 16
IEEE 802.11 WLAN Configuration Request messages that include the Add IEEE 802.11 WLAN Configuration Request messages that include the Add
skipping to change at page 16, line 17 skipping to change at page 17, line 17
o IEEE 802.11 Add WLAN, see Section 6.1 o IEEE 802.11 Add WLAN, see Section 6.1
o IEEE 802.11 Delete WLAN, see Section 6.4 o IEEE 802.11 Delete WLAN, see Section 6.4
o IEEE 802.11 Update WLAN, see Section 6.21 o IEEE 802.11 Update WLAN, see Section 6.21
The following message element MAY be present. The following message element MAY be present.
o IEEE 802.11 Information Element, see Section 6.6 o IEEE 802.11 Information Element, see Section 6.6
o Vendor Specific Payload, see [3]
3.2. IEEE 802.11 WLAN Configuration Response 3.2. IEEE 802.11 WLAN Configuration Response
The IEEE 802.11 WLAN Configuration Response message is sent by the The IEEE 802.11 WLAN Configuration Response message is sent by the
WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11
WLAN Configuration Request message, and to indicate that the WLAN Configuration Request message, and to indicate that the
requested configuration was successfully applied, or that an error requested configuration was successfully applied, or that an error
related to the processing of the IEEE 802.11 WLAN Configuration related to the processing of the IEEE 802.11 WLAN Configuration
Request message occurred on the WTP. Request message occurred on the WTP.
The following message element MAY be included in the IEEE 802.11 WLAN The following message element MAY be included in the IEEE 802.11 WLAN
Configuration Response message. Configuration Response message.
o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3
o Vendor Specific Payload, see [3]
The following message element MUST be included in the IEEE 802.11 The following message element MUST be included in the IEEE 802.11
WLAN Configuration Response message. WLAN Configuration Response message.
o Result Code, see Section 4.5.31 in [3] o Result Code, see Section 4.6.35 in [3]
4. CAPWAP Data Message Bindings 4. CAPWAP Data Message Bindings
This section describes the CAPWAP Data Message bindings to support This section describes the CAPWAP Data Message bindings to support
transport of IEEE 802.11 frames. transport of IEEE 802.11 frames.
Payload encapsulation: The CAPWAP protocol defines the CAPWAP data Payload encapsulation: The CAPWAP protocol defines the CAPWAP data
message, which is used to encapsulate a wireless payload. For message, which is used to encapsulate a wireless payload. For
IEEE 802.11, the IEEE 802.11 header and payload are encapsulated IEEE 802.11, the IEEE 802.11 header and payload are encapsulated
(excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS
checksum is handled by the WTP. This allows the WTP to validate checksum is handled by the WTP. This allows the WTP to validate
an IEEE 802.11 frame prior to sending it to the AC. Similarly, an IEEE 802.11 frame prior to sending it to the AC. Similarly,
when an AC wishes to transmit a frame to a station, the WTP when an AC wishes to transmit a frame to a station, the WTP
computes and adds the FCS checksum. computes and adds the FCS checksum.
Optional Wireless Specific Information: The optional CAPWAP header Optional Wireless Specific Information: This optional CAPWAP header
field (see Section 4.2 in [3]) is only used with CAPWAP data field (see Section 4.3 in [3]) is only used with CAPWAP data
messages, and it serves two purposes, depending upon the direction messages, and it serves two purposes, depending upon the direction
of the message. For messages from the WTP to the AC, the field of the message. For messages from the WTP to the AC, the field
uses the format described in the "IEEE 802.11 Frame Info" field uses the format described in the "IEEE 802.11 Frame Info" field
(see below). However, for messages sent by the AC to the WTP, the (see below). However, for messages sent by the AC to the WTP, the
format used is described in the "Destination WLANs" field (also format used is described in the "Destination WLANs" field (also
defined below). defined below).
Note that in both cases, the two optional headers fit in the
"Data" field of the Wireless Specific Information header.
IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a
station over the air, it is encapsulated and this field is used to station over the air, it is encapsulated and this field is used to
include radio and PHY specific information associated with the include radio and PHY specific information associated with the
frame. frame.
The IEEE 802.11 Frame Info field has the following format: The IEEE 802.11 Frame Info field has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 27 skipping to change at page 23, line 27
5.11. Change State Event Request 5.11. Change State Event Request
The following IEEE 802.11 specific message elements MAY included in The following IEEE 802.11 specific message elements MAY included in
the CAPWAP Station Configuration Request message. the CAPWAP Station Configuration Request message.
o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24
5.12. WTP Event Request 5.12. WTP Event Request
The following IEEE 802.11 specific message elements MAY be included The following IEEE 802.11 specific message elements MAY be included
in the CAPWAP WTP Event Request message.More than one of each message in the CAPWAP WTP Event Request message. More than one of each
element listed MAY be included. message element listed MAY be included.
o IEEE 802.11 MIC Countermeasures, see Section 6.8 o IEEE 802.11 MIC Countermeasures, see Section 6.8
o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12
o IEEE 802.11 Statistics, see Section 6.16 o IEEE 802.11 Statistics, see Section 6.16
6. IEEE 802.11 Message Element Definitions 6. IEEE 802.11 Message Element Definitions
The following IEEE 802.11 specific message elements are defined in The following IEEE 802.11 specific message elements are defined in
skipping to change at page 25, line 37 skipping to change at page 26, line 37
Key Length: A 16-bit value representing the length of the Key Key Length: A 16-bit value representing the length of the Key
field. field.
Key: A 32 byte Session Key to use to provide data privacy. For Key: A 32 byte Session Key to use to provide data privacy. For
encryption schemes that employ a separate encryption key for encryption schemes that employ a separate encryption key for
unicast and multicast traffic, the key included here only applies unicast and multicast traffic, the key included here only applies
to multicast frames, and the cipher suite is specified in an to multicast frames, and the cipher suite is specified in an
accompanied RSN Information Element. In these scenarios, the key accompanied RSN Information Element. In these scenarios, the key
and cipher information is communicated via the Add Station message and cipher information is communicated via the Add Station message
element, see Section 4.5.8 in [3] and the IEEE 802.11 Station element, see Section 4.6.8 in [3] and the IEEE 802.11 Station
Session Key message element, see Section 6.15. Session Key message element, see Section 6.15.
Group TSC A 48-bit value containing the Transmit Sequence Counter Group TSC A 48-bit value containing the Transmit Sequence Counter
for the updated group key. The WTP will set the TSC for for the updated group key. The WTP will set the TSC for
broadcast/multicast frames to this value for the updated group broadcast/multicast frames to this value for the updated group
key. key.
QOS: An 8-bit value specifying the default QOS policy for the WTP QOS: An 8-bit value specifying the default QOS policy for the WTP
to apply to network traffic received for a non-WMM enabled STA. to apply to network traffic received for a non-WMM enabled STA.
skipping to change at page 26, line 25 skipping to change at page 27, line 25
The following values are supported: The following values are supported:
0 - Open System 0 - Open System
1 - WEP Shared Key 1 - WEP Shared Key
MAC Mode: This field specifies whether the WTP should support the MAC Mode: This field specifies whether the WTP should support the
WLAN in Local or Split MAC modes. Note that the AC MUST NOT WLAN in Local or Split MAC modes. Note that the AC MUST NOT
request a mode of operation that was not advertised by the WTP request a mode of operation that was not advertised by the WTP
during the discovery process (see Section 4.4.42 in [3]). The during the discovery process (see Section 4.6.46 in [3]). The
following values are supported: following values are supported:
0 - Local-MAC: Service for the WLAN is to be provided in Local 0 - Local-MAC: Service for the WLAN is to be provided in Local
MAC mode. MAC mode.
1 - Split-MAC: Service for the WLAN is to be provided in Split 1 - Split-MAC: Service for the WLAN is to be provided in Split
MAC mode. MAC mode.
Tunnel Mode: This field specifies the frame tunneling type to be Tunnel Mode: This field specifies the frame tunneling type to be
used for 802.11 data frames from all stations associated with the used for 802.11 data frames from all stations associated with the
WLAN. The AC MUST NOT request a mode of operation that was not WLAN. The AC MUST NOT request a mode of operation that was not
advertised by the WTP during the discovery process (see Section advertised by the WTP during the discovery process (see Section
4.4.40 in [3]). IEEE 802.11 managment frames SHALL be tunneled 4.6.43 in [3]). IEEE 802.11 management frames SHALL be tunneled
using 802.11 Tunnel mode. The following values are supported: using 802.11 Tunnel mode. The following values are supported:
0 - Local Bridging: All user traffic is to be locally bridged. 0 - Local Bridging: All user traffic is to be locally bridged.
1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC
in 802.3 format (see Section 4.2 in [3]). in 802.3 format (see Section 4.3 in [3]).
2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC
in 802.11 format. in 802.11 format.
Supress SSID: A boolean indicating whether the SSID is to be Supress SSID: A boolean indicating whether the SSID is to be
advertised by the WTP. A value of zero supresses the SSID in the advertised by the WTP. A value of zero suppresses the SSID in the
802.11 Beacon and Probe Response frames, while a value of one will 802.11 Beacon and Probe Response frames, while a value of one will
cause the WTP to populate the field. cause the WTP to populate the field.
SSID: The SSID attribute is the service set identifier that will be SSID: The SSID attribute is the service set identifier that will be
advertised by the WTP for this WLAN. advertised by the WTP for this WLAN.
6.2. IEEE 802.11 Antenna 6.2. IEEE 802.11 Antenna
The IEEE 802.11 Antenna message element is communicated by the WTP to The IEEE 802.11 Antenna message element is communicated by the WTP to
the AC to provide information on the antennas available. The AC MAY the AC to provide information on the antennas available. The AC MAY
skipping to change at page 32, line 39 skipping to change at page 33, line 39
An MSDU or MMPDU MUST be fragmented when the resulting frame has An MSDU or MMPDU MUST be fragmented when the resulting frame has
an individual address in the Address1 field, and the length of the an individual address in the Address1 field, and the length of the
frame is larger than this threshold. The default value for this frame is larger than this threshold. The default value for this
attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the
attached PHY and MUST never exceed the lesser of 2346 or the attached PHY and MUST never exceed the lesser of 2346 or the
aMPDUMaxLength of the attached PHY. The value of this attribute aMPDUMaxLength of the attached PHY. The value of this attribute
MUST never be less than 256. The value of this field comes from MUST never be less than 256. The value of this field comes from
the IEEE 802.11 dot11FragmentationThreshold MIB element, (see the IEEE 802.11 dot11FragmentationThreshold MIB element, (see
[2]). [2]).
Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, Tx MSDU Lifetime: This attribute specifies the elapsed time in TU,
after the initial transmission of an MSDU, after which further after the initial transmission of an MSDU, after which further
attempts to transmit the MSDU MUST be terminated. The default attempts to transmit the MSDU MUST be terminated. The default
value of this attribute MUST be 512. The value of this field value of this attribute MUST be 512. The value of this field
comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB
element, (see [2]). element, (see [2]).
Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, Rx MSDU Lifetime: This attribute specifies the elapsed time in TU,
after the initial reception of a fragmented MMPDU or MSDU, after after the initial reception of a fragmented MMPDU or MSDU, after
which further attempts to reassemble the MMPDU or MSDU MUST be which further attempts to reassemble the MMPDU or MSDU MUST be
terminated. The default value MUST be 512. The value of this terminated. The default value MUST be 512. The value of this
skipping to change at page 34, line 16 skipping to change at page 35, line 16
Length: 8 Length: 8
Radio ID: An 8-bit value representing the radio to configure. Radio ID: An 8-bit value representing the radio to configure.
Reserved: All implementations complying with this protocol MUST set Reserved: All implementations complying with this protocol MUST set
to zero any bits that are reserved in the version of the protocol to zero 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.
First Channnel #: This attribute indicates the value of the lowest First Channnel #: This attribute indicates the value of the lowest
channel number in the subband for the associated domain country channel number in the sub-band for the associated domain country
string. The value of this field comes from the IEEE 802.11 string. The value of this field comes from the IEEE 802.11
dot11FirstChannelNumber MIB element (see [2]). dot11FirstChannelNumber MIB element (see [2]).
Number of Channels: This attribute indicates the value of the total Number of Channels: This attribute indicates the value of the total
number of channels allowed in the subband for the associated number of channels allowed in the sub-band for the associated
domain country string. The value of this field comes from the domain country string. The value of this field comes from the
IEEE 802.11 dot11NumberofChannels MIB element (see [2]). IEEE 802.11 dot11NumberofChannels MIB element (see [2]).
Max Tx Power Level: This attribute indicates the maximum transmit Max Tx Power Level: This attribute indicates the maximum transmit
power, in dBm, allowed in the subband for the associated domain power, in dBm, allowed in the sub-band for the associated domain
country string. The value of this field comes from the IEEE country string. The value of this field comes from the IEEE
802.11 dot11MaximumTransmitPowerLevel MIB element (see [2]). 802.11 dot11MaximumTransmitPowerLevel MIB element (see [2]).
6.10. IEEE 802.11 OFDM Control 6.10. IEEE 802.11 OFDM Control
The IEEE 802.11 OFDM Control message element is a bi-directional The IEEE 802.11 OFDM Control message element is a bi-directional
element. When sent by the WTP, it contains the current state. When element. When sent by the WTP, it contains the current state. When
sent by the AC, the WTP MUST adhere to the received values. This sent by the AC, the WTP MUST adhere to the received values. This
message element is only used for 802.11a radios and contains the message element is only used for 802.11a radios and contains the
following fields: following fields:
skipping to change at page 48, line 50 skipping to change at page 49, line 50
field. field.
Key: A 32 byte Session Key to use to provide data privacy. For Key: A 32 byte Session Key to use to provide data privacy. For
static WEP keys, which is true when the 'Key Status' bit is set to static WEP keys, which is true when the 'Key Status' bit is set to
one, this key is used for both unicast and multicast traffic. For one, this key is used for both unicast and multicast traffic. For
encryption schemes that employ a separate encryption key for encryption schemes that employ a separate encryption key for
unicast and multicast traffic, the key included hereonly applies unicast and multicast traffic, the key included hereonly applies
to multicast data, and the cipher suite is specified in an to multicast data, and the cipher suite is specified in an
accompanied RSN Information Element. In these scenarios, the key, accompanied RSN Information Element. In these scenarios, the key,
and cipher information, is communicated via the Add Station and cipher information, is communicated via the Add Station
message element, see Section 4.5.8 in [3]. message element, see Section 4.6.8 in [3].
6.22. IEEE 802.11 WTP Quality of Service 6.22. IEEE 802.11 WTP Quality of Service
The IEEE 802.11 WTP Quality of Service message element value is sent The IEEE 802.11 WTP Quality of Service message element value is sent
by the AC to the WTP to communicate quality of service configuration by the AC to the WTP to communicate quality of service configuration
information. information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 56, line 15 skipping to change at page 57, line 15
9. Security Considerations 9. Security Considerations
This section describes security considerations for using IEEE 802.11 This section describes security considerations for using IEEE 802.11
with the CAPWAP protocol. with the CAPWAP protocol.
9.1. IEEE 802.11 Security 9.1. IEEE 802.11 Security
When used with an IEEE 802.11 infrastructure with WEP encryption, the When used with an IEEE 802.11 infrastructure with WEP encryption, the
CAPWAP protocol does not add any new vulnerabilities. Derived CAPWAP protocol does not add any new vulnerabilities. Derived
session keys between the STA and WTP can be compromised, resulting in session keys between the STA and WTP can be compromised, resulting in
many well-documented attacks. Implementors SHOULD discourage the use many well-documented attacks. Implementers SHOULD discourage the use
of WEP and encourage use of technically sound cryptographic solutions of WEP and encourage use of technically sound cryptographic solutions
such as those in an IEEE 802.11 RSN. such as those in an IEEE 802.11 RSN.
STA authentication is performed using IEEE 802.lX, and consequently STA authentication is performed using IEEE 802.lX, and consequently
EAP. Implementors SHOULD use EAP methods meeting the requirements EAP. Implementers SHOULD use EAP methods meeting the requirements
specified [5]. specified [5].
When used with IEEE 802.11 RSN security, the CAPWAP protocol may When used with IEEE 802.11 RSN security, the CAPWAP protocol may
introduce new vulnerabilities, depending on whether the link security introduce new vulnerabilities, depending on whether the link security
(packet encryption and integrity verification) is provided by the WTP (packet encryption and integrity verification) is provided by the WTP
or the AC. When the link security function is provided by the AC, no or the AC. When the link security function is provided by the AC, no
new security concerns are introduced. new security concerns are introduced.
However, when the WTP provides link security, a new vulnerability However, when the WTP provides link security, a new vulnerability
will exist when the following conditions are true: will exist when the following conditions are true:
skipping to change at page 60, line 20 skipping to change at page 61, line 20
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] "Information technology - Telecommunications and information [2] "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks exchange between systems - Local and metropolitan area networks
- Specific requirements - Part 11: Wireless LAN Medium Access - Specific requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications", Control (MAC) and Physical Layer (PHY) specifications",
IEEE Standard 802.11, 1999, IEEE Standard 802.11, 1999,
<http://standards.ieee.org/getieee802/download/802.11-1999.pdf>. <http://standards.ieee.org/getieee802/download/802.11-1999.pdf>.
[3] Calhoun, P., "CAPWAP Protocol Specification", [3] Calhoun, P., "CAPWAP Protocol Specification",
draft-ietf-capwap-protocol-specification-07 (work in progress), draft-ietf-capwap-protocol-specification-09 (work in progress),
June 2007. February 2008.
[4] "Information technology - Telecommunications and information [4] "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks exchange between systems - Local and metropolitan area networks
- Specific requirements - Part 11: Wireless LAN Medium Access - Specific requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications Amendment Control (MAC) and Physical Layer (PHY) specifications Amendment
6: Medium Access Control (MAC) Security Enhancements", 6: Medium Access Control (MAC) Security Enhancements",
IEEE Standard 802.11i, July 2004, IEEE Standard 802.11i, July 2004,
<http://standards.ieee.org/getieee802/download/ <http://standards.ieee.org/getieee802/download/
802.11i-2004.pdf>. 802.11i-2004.pdf>.
skipping to change at page 62, line 7 skipping to change at page 63, line 7
Dorothy Stanley Dorothy Stanley
Aruba Networks Aruba Networks
1322 Crossman Ave 1322 Crossman Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Phone: +1 630-363-1389 Phone: +1 630-363-1389
Email: dstanley@arubanetworks.com Email: dstanley@arubanetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 33 change blocks. 
37 lines changed or deleted 123 lines changed or added

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