summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5412.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5412.txt')
-rw-r--r--doc/rfc/rfc5412.txt7003
1 files changed, 7003 insertions, 0 deletions
diff --git a/doc/rfc/rfc5412.txt b/doc/rfc/rfc5412.txt
new file mode 100644
index 0000000..a07df0f
--- /dev/null
+++ b/doc/rfc/rfc5412.txt
@@ -0,0 +1,7003 @@
+
+
+
+
+
+
+Independent Submission P. Calhoun
+Request for Comments: 5412 R. Suri
+Category: Historic N. Cam-Winget
+ISSN: 2070-1721 Cisco Systems, Inc.
+ M. Williams
+ GWhiz Arts & Sciences
+ S. Hares
+ B. O'Hara
+ S.Kelly
+ February 2010
+
+
+ Lightweight Access Point Protocol
+
+Abstract
+
+ In recent years, there has been a shift in wireless LAN (WLAN)
+ product architectures from autonomous access points to centralized
+ control of lightweight access points. The general goal has been to
+ move most of the traditional wireless functionality such as access
+ control (user authentication and authorization), mobility, and radio
+ management out of the access point into a centralized controller.
+
+ The IETF's CAPWAP (Control and Provisioning of Wireless Access
+ Points) WG has identified that a standards-based protocol is
+ necessary between a wireless Access Controller and Wireless
+ Termination Points (the latter are also commonly referred to as
+ Lightweight Access Points). This specification defines the
+ Lightweight Access Point Protocol (LWAPP), which addresses the
+ CAPWAP's (Control and Provisioning of Wireless Access Points)
+ protocol requirements. Although the LWAPP protocol is designed to be
+ flexible enough to be used for a variety of wireless technologies,
+ this specific document describes the base protocol and an extension
+ that allows it to be used with the IEEE's 802.11 wireless LAN
+ protocol.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for the historical record.
+
+ This document defines a Historic Document for the Internet community.
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+
+
+Calhoun, et al. Historic [Page 1]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5412.
+
+IESG Note
+
+ This RFC documents the LWAPP protocol as it was when submitted to the
+ IETF as a basis for further work in the CAPWAP Working Group, and
+ therefore it may resemble the CAPWAP protocol specification in RFC
+ 5415 as well as other IETF work. This RFC is being published solely
+ for the historical record. The protocol described in this RFC has
+ not been thoroughly reviewed and may contain errors and omissions.
+
+ RFC 5415 documents the standards track solution for the CAPWAP
+ Working Group and obsoletes any and all mechanisms defined in this
+ RFC. This RFC is not a candidate for any level of Internet Standard
+ and should not be used as a basis for any sort of Internet
+ deployment.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 2]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................8
+ 1.1. Conventions Used in This Document ..........................9
+ 2. Protocol Overview ..............................................10
+ 2.1. Wireless Binding Definition ...............................11
+ 2.2. LWAPP State Machine Definition ............................12
+ 3. LWAPP Transport Layers .........................................20
+ 3.1. LWAPP Transport Header ....................................21
+ 3.1.1. VER Field ..........................................21
+ 3.1.2. RID Field ..........................................21
+ 3.1.3. C Bit ..............................................21
+ 3.1.4. F Bit ..............................................21
+ 3.1.5. L Bit ..............................................22
+ 3.1.6. Fragment ID ........................................22
+ 3.1.7. Length .............................................22
+ 3.1.8. Status and WLANS ...................................22
+ 3.1.9. Payload ............................................22
+ 3.2. Using IEEE 802.3 MAC as LWAPP Transport ...................22
+ 3.2.1. Framing ............................................23
+ 3.2.2. AC Discovery .......................................23
+ 3.2.3. LWAPP Message Header Format over IEEE 802.3
+ MAC Transport ......................................23
+ 3.2.4. Fragmentation/Reassembly ...........................24
+ 3.2.5. Multiplexing .......................................24
+ 3.3. Using IP/UDP as LWAPP Transport ...........................24
+ 3.3.1. Framing ............................................24
+ 3.3.2. AC Discovery .......................................25
+ 3.3.3. LWAPP Message Header Format over IP/UDP Transport ..25
+ 3.3.4. Fragmentation/Reassembly for IPv4 ..................26
+ 3.3.5. Fragmentation/Reassembly for IPv6 ..................26
+ 3.3.6. Multiplexing .......................................26
+ 4. LWAPP Packet Definitions .......................................26
+ 4.1. LWAPP Data Messages .......................................27
+ 4.2. LWAPP Control Messages Overview ...........................27
+ 4.2.1. Control Message Format .............................28
+ 4.2.2. Message Element Format .............................29
+ 4.2.3. Quality of Service .................................31
+ 5. LWAPP Discovery Operations .....................................31
+ 5.1. Discovery Request .........................................31
+ 5.1.1. Discovery Type .....................................32
+ 5.1.2. WTP Descriptor .....................................33
+ 5.1.3. WTP Radio Information ..............................34
+ 5.2. Discovery Response ........................................34
+ 5.2.1. AC Address .........................................35
+ 5.2.2. AC Descriptor ......................................35
+ 5.2.3. AC Name ............................................36
+ 5.2.4. WTP Manager Control IPv4 Address ...................37
+
+
+
+Calhoun, et al. Historic [Page 3]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 5.2.5. WTP Manager Control IPv6 Address ...................37
+ 5.3. Primary Discovery Request .................................38
+ 5.3.1. Discovery Type .....................................38
+ 5.3.2. WTP Descriptor .....................................38
+ 5.3.3. WTP Radio Information ..............................38
+ 5.4. Primary Discovery Response ................................38
+ 5.4.1. AC Descriptor ......................................39
+ 5.4.2. AC Name ............................................39
+ 5.4.3. WTP Manager Control IPv4 Address ...................39
+ 5.4.4. WTP Manager Control IPv6 Address ...................39
+ 6. Control Channel Management .....................................39
+ 6.1. Join Request ..............................................39
+ 6.1.1. WTP Descriptor .....................................40
+ 6.1.2. AC Address .........................................40
+ 6.1.3. WTP Name ...........................................40
+ 6.1.4. Location Data ......................................41
+ 6.1.5. WTP Radio Information ..............................41
+ 6.1.6. Certificate ........................................41
+ 6.1.7. Session ID .........................................42
+ 6.1.8. Test ...............................................42
+ 6.1.9. XNonce .............................................42
+ 6.2. Join Response .............................................43
+ 6.2.1. Result Code ........................................44
+ 6.2.2. Status .............................................44
+ 6.2.3. Certificate ........................................45
+ 6.2.4. WTP Manager Data IPv4 Address ......................45
+ 6.2.5. WTP Manager Data IPv6 Address ......................45
+ 6.2.6. AC IPv4 List .......................................46
+ 6.2.7. AC IPv6 List .......................................46
+ 6.2.8. ANonce .............................................47
+ 6.2.9. PSK-MIC ............................................48
+ 6.3. Join ACK ..................................................48
+ 6.3.1. Session ID .........................................49
+ 6.3.2. WNonce .............................................49
+ 6.3.3. PSK-MIC ............................................49
+ 6.4. Join Confirm ..............................................49
+ 6.4.1. Session ID .........................................50
+ 6.4.2. PSK-MIC ............................................50
+ 6.5. Echo Request ..............................................50
+ 6.6. Echo Response .............................................50
+ 6.7. Key Update Request ........................................51
+ 6.7.1. Session ID .........................................51
+ 6.7.2. XNonce .............................................51
+ 6.8. Key Update Response .......................................51
+ 6.8.1. Session ID .........................................51
+ 6.8.2. ANonce .............................................51
+ 6.8.3. PSK-MIC ............................................52
+ 6.9. Key Update ACK ............................................52
+
+
+
+Calhoun, et al. Historic [Page 4]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 6.9.1. WNonce .............................................52
+ 6.9.2. PSK-MIC ............................................52
+ 6.10. Key Update Confirm .......................................52
+ 6.10.1. PSK-MIC ...........................................52
+ 6.11. Key Update Trigger .......................................52
+ 6.11.1. Session ID ........................................53
+ 7. WTP Configuration Management ...................................53
+ 7.1. Configuration Consistency .................................53
+ 7.2. Configure Request .........................................54
+ 7.2.1. Administrative State ...............................54
+ 7.2.2. AC Name ............................................55
+ 7.2.3. AC Name with Index .................................55
+ 7.2.4. WTP Board Data .....................................56
+ 7.2.5. Statistics Timer ...................................56
+ 7.2.6. WTP Static IP Address Information ..................57
+ 7.2.7. WTP Reboot Statistics ..............................58
+ 7.3. Configure Response ........................................58
+ 7.3.1. Decryption Error Report Period .....................59
+ 7.3.2. Change State Event .................................59
+ 7.3.3. LWAPP Timers .......................................60
+ 7.3.4. AC IPv4 List .......................................60
+ 7.3.5. AC IPv6 List .......................................61
+ 7.3.6. WTP Fallback .......................................61
+ 7.3.7. Idle Timeout .......................................61
+ 7.4. Configuration Update Request ..............................62
+ 7.4.1. WTP Name ...........................................62
+ 7.4.2. Change State Event .................................62
+ 7.4.3. Administrative State ...............................62
+ 7.4.4. Statistics Timer ...................................62
+ 7.4.5. Location Data ......................................62
+ 7.4.6. Decryption Error Report Period .....................62
+ 7.4.7. AC IPv4 List .......................................62
+ 7.4.8. AC IPv6 List .......................................62
+ 7.4.9. Add Blacklist Entry ................................63
+ 7.4.10. Delete Blacklist Entry ............................63
+ 7.4.11. Add Static Blacklist Entry ........................64
+ 7.4.12. Delete Static Blacklist Entry .....................64
+ 7.4.13. LWAPP Timers ......................................65
+ 7.4.14. AC Name with Index ................................65
+ 7.4.15. WTP Fallback ......................................65
+ 7.4.16. Idle Timeout ......................................65
+ 7.5. Configuration Update Response .............................65
+ 7.5.1. Result Code ........................................65
+ 7.6. Change State Event Request ................................65
+ 7.6.1. Change State Event .................................66
+ 7.7. Change State Event Response ...............................66
+ 7.8. Clear Config Indication ...................................66
+ 8. Device Management Operations ...................................66
+
+
+
+Calhoun, et al. Historic [Page 5]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 8.1. Image Data Request ........................................66
+ 8.1.1. Image Download .....................................67
+ 8.1.2. Image Data .........................................67
+ 8.2. Image Data Response .......................................68
+ 8.3. Reset Request .............................................68
+ 8.4. Reset Response ............................................68
+ 8.5. WTP Event Request .........................................68
+ 8.5.1. Decryption Error Report ............................69
+ 8.5.2. Duplicate IPv4 Address .............................69
+ 8.5.3. Duplicate IPv6 Address .............................70
+ 8.6. WTP Event Response ........................................70
+ 8.7. Data Transfer Request .....................................71
+ 8.7.1. Data Transfer Mode .................................71
+ 8.7.2. Data Transfer Data .................................71
+ 8.8. Data Transfer Response ....................................72
+ 9. Mobile Session Management ......................................72
+ 9.1. Mobile Config Request .....................................72
+ 9.1.1. Delete Mobile ......................................73
+ 9.2. Mobile Config Response ....................................73
+ 9.2.1. Result Code ........................................74
+ 10. LWAPP Security ................................................74
+ 10.1. Securing WTP-AC Communications ...........................74
+ 10.2. LWAPP Frame Encryption ...................................75
+ 10.3. Authenticated Key Exchange ...............................76
+ 10.3.1. Terminology .......................................76
+ 10.3.2. Initial Key Generation ............................77
+ 10.3.3. Refreshing Cryptographic Keys .....................81
+ 10.4. Certificate Usage ........................................82
+ 11. IEEE 802.11 Binding ...........................................82
+ 11.1. Division of Labor ........................................82
+ 11.1.1. Split MAC .........................................83
+ 11.1.2. Local MAC .........................................85
+ 11.2. Roaming Behavior and 802.11 Security .....................87
+ 11.3. Transport-Specific Bindings ..............................88
+ 11.3.1. Status and WLANS Field ............................88
+ 11.4. BSSID to WLAN ID Mapping .................................89
+ 11.5. Quality of Service .......................................89
+ 11.6. Data Message Bindings ....................................90
+ 11.7. Control Message Bindings .................................90
+ 11.7.1. Mobile Config Request .............................90
+ 11.7.2. WTP Event Request .................................96
+ 11.8. 802.11 Control Messages ..................................97
+ 11.8.1. IEEE 802.11 WLAN Config Request ...................98
+ 11.8.2. IEEE 802.11 WLAN Config Response .................103
+ 11.8.3. IEEE 802.11 WTP Event ............................103
+ 11.9. Message Element Bindings ................................105
+ 11.9.1. IEEE 802.11 WTP WLAN Radio Configuration .........105
+ 11.9.2. IEEE 802.11 Rate Set .............................107
+
+
+
+Calhoun, et al. Historic [Page 6]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 11.9.3. IEEE 802.11 Multi-Domain Capability ..............107
+ 11.9.4. IEEE 802.11 MAC Operation ........................108
+ 11.9.5. IEEE 802.11 Tx Power .............................109
+ 11.9.6. IEEE 802.11 Tx Power Level .......................110
+ 11.9.7. IEEE 802.11 Direct Sequence Control ..............110
+ 11.9.8. IEEE 802.11 OFDM Control .........................111
+ 11.9.9. IEEE 802.11 Antenna ..............................112
+ 11.9.10. IEEE 802.11 Supported Rates .....................113
+ 11.9.11. IEEE 802.11 CFP Status ..........................114
+ 11.9.12. IEEE 802.11 WTP Mode and Type ...................114
+ 11.9.13. IEEE 802.11 Broadcast Probe Mode ................115
+ 11.9.14. IEEE 802.11 WTP Quality of Service ..............115
+ 11.9.15. IEEE 802.11 MIC Error Report From Mobile ........117
+ 11.10. IEEE 802.11 Message Element Values .....................117
+ 12. LWAPP Protocol Timers ........................................118
+ 12.1. MaxDiscoveryInterval ....................................118
+ 12.2. SilentInterval ..........................................118
+ 12.3. NeighborDeadInterval ....................................118
+ 12.4. EchoInterval ............................................118
+ 12.5. DiscoveryInterval .......................................118
+ 12.6. RetransmitInterval ......................................119
+ 12.7. ResponseTimeout .........................................119
+ 12.8. KeyLifetime .............................................119
+ 13. LWAPP Protocol Variables .....................................119
+ 13.1. MaxDiscoveries ..........................................119
+ 13.2. DiscoveryCount ..........................................119
+ 13.3. RetransmitCount .........................................119
+ 13.4. MaxRetransmit ...........................................120
+ 14. NAT Considerations ...........................................120
+ 15. Security Considerations ......................................121
+ 15.1. Certificate-Based Session Key Establishment .............122
+ 15.2. PSK-Based Session Key Establishment .....................123
+ 16. Acknowledgements .............................................123
+ 17. References ...................................................123
+ 17.1. Normative References ....................................123
+ 17.2. Informative References ..................................124
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 7]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+1. Introduction
+
+ Unlike wired network elements, Wireless Termination Points (WTPs)
+ require a set of dynamic management and control functions related to
+ their primary task of connecting the wireless and wired mediums.
+ Today, protocols for managing WTPs are either manual static
+ configuration via HTTP, proprietary Layer 2-specific, or non-existent
+ (if the WTPs are self-contained). The emergence of simple 802.11
+ WTPs that are managed by a WLAN appliance or switch (also known as an
+ Access Controller, or AC) suggests that having a standardized,
+ interoperable protocol could radically simplify the deployment and
+ management of wireless networks. In many cases, the overall control
+ and management functions themselves are generic and could apply to an
+ AP for any wireless Layer 2 (L2) protocol. Being independent of
+ specific wireless Layer 2 technologies, such a protocol could better
+ support interoperability between Layer 2 devices and enable smoother
+ intertechnology handovers.
+
+ The details of how these functions would be implemented are dependent
+ on the particular Layer 2 wireless technology. Such a protocol would
+ need provisions for binding to specific technologies.
+
+ LWAPP assumes a network configuration that consists of multiple WTPs
+ communicating either via Layer 2 (Medium Access Control (MAC)) or
+ Layer 3 (IP) to an AC. The WTPs can be considered as remote radio
+ frequency (RF) interfaces, being controlled by the AC. The AC
+ forwards all L2 frames it wants to transmit to a WTP via the LWAPP
+ protocol. Packets from mobile nodes are forwarded by the WTP to the
+ AC, also via this protocol. Figure 1 illustrates this arrangement as
+ applied to an IEEE 802.11 binding.
+
+ +-+ 802.11 frames +-+
+ | |--------------------------------| |
+ | | +-+ | |
+ | |--------------| |---------------| |
+ | | 802.11 PHY/ | | LWAPP | |
+ | | MAC sublayer | | | |
+ +-+ +-+ +-+
+ STA WTP AC
+
+ Figure 1: LWAPP Architecture
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 8]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Security is another aspect of Wireless Termination Point management
+ that is not well served by existing solutions. Provisioning WTPs
+ with security credentials, and managing which WTPs are authorized to
+ provide service are today handled by proprietary solutions. Allowing
+ these functions to be performed from a centralized AC in an
+ interoperable fashion increases manageability and allows network
+ operators to more tightly control their wireless network
+ infrastructure.
+
+ This document describes the Lightweight Access Point Protocol
+ (LWAPP), allowing an AC to manage a collection of WTPs. The protocol
+ is defined to be independent of Layer 2 technology, but an 802.11
+ binding is provided for use in growing 802.11 wireless LAN networks.
+
+ Goals:
+
+ The following are goals for this protocol:
+
+ 1. Centralization of the bridging, forwarding, authentication, and
+ policy enforcement functions for a wireless network. Optionally,
+ the AC may also provide centralized encryption of user traffic.
+ This will permit reduced cost and higher efficiency when applying
+ the capabilities of network processing silicon to the wireless
+ network, as it has already been applied to wired LANs.
+
+ 2. Permit shifting of the higher-level protocol processing burden
+ away from the WTP. This leaves the computing resource of the WTP
+ to the timing-critical applications of wireless control and
+ access. This makes the most efficient use of the computing power
+ available in WTPs that are the subject of severe cost pressure.
+
+ 3. Providing a generic encapsulation and transport mechanism, the
+ protocol may be applied to other access point types in the future
+ by adding the binding.
+
+ The LWAPP protocol concerns itself solely with the interface between
+ the WTP and the AC. Inter-AC, or mobile-to-AC communication is
+ strictly outside the scope of this document.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 9]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+2. Protocol Overview
+
+ LWAPP is a generic protocol defining how Wireless Termination Points
+ communicate with Access Controllers. Wireless Termination Points and
+ Access Controllers may communicate either by means of Layer 2
+ protocols or by means of a routed IP network.
+
+ LWAPP messages and procedures defined in this document apply to both
+ types of transports unless specified otherwise. Transport
+ independence is achieved by defining formats for both MAC-level and
+ IP-level transport (see Section 3). Also defined are framing,
+ fragmentation/reassembly, and multiplexing services to LWAPP for each
+ transport type.
+
+ The LWAPP Transport layer carries two types of payload. LWAPP data
+ messages are forwarded wireless frames. LWAPP control messages are
+ management messages exchanged between a WTP and an AC. The LWAPP
+ transport header defines the "C-bit", which is used to distinguish
+ data and control traffic. When used over IP, the LWAPP data and
+ control traffic are also sent over separate UDP ports. Since both
+ data and control frames can exceed Path Maximum Transmission Unit
+ (PMTU), the payload of an LWAPP data or control message can be
+ fragmented. The fragmentation behavior is highly dependent upon the
+ lower-layer transport and is defined in Section 3.
+
+ The Lightweight Access Protocol (LWAPP) begins with a discovery
+ phase. The WTPs send a Discovery Request frame, causing any Access
+ Controller (AC), receiving that frame to respond with a Discovery
+ Response. From the Discovery Responses received, a WTP will select
+ an AC with which to associate, using the Join Request and Join
+ Response. The Join Request also provides an MTU discovery mechanism,
+ to determine whether there is support for the transport of large
+ frames between the WTP and its AC. If support for large frames is
+ not present, the LWAPP frames will be fragmented to the maximum
+ length discovered to be supported by the network.
+
+ Once the WTP and the AC have joined, a configuration exchange is
+ accomplished that will cause both devices to agree on version
+ information. During this exchange, the WTP may receive provisioning
+ settings. For the 802.11 binding, this information would typically
+ include a name (802.11 Service Set Identifier, SSID), and security
+ parameters, the data rates to be advertised, as well as the radio
+ channel (channels, if the WTP is capable of operating more than one
+ 802.11 MAC and Physical Layer (PHY) simultaneously) to be used.
+ Finally, the WTPs are enabled for operation.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 10]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ When the WTP and AC have completed the version and provision exchange
+ and the WTP is enabled, the LWAPP encapsulates the wireless frames
+ sent between them. LWAPP will fragment its packets, if the size of
+ the encapsulated wireless user data (Data) or protocol control
+ (Management) frames cause the resultant LWAPP packet to exceed the
+ MTU supported between the WTP and AC. Fragmented LWAPP packets are
+ reassembled to reconstitute the original encapsulated payload.
+
+ In addition to the functions thus far described, LWAPP also provides
+ for the delivery of commands from the AC to the WTP for the
+ management of devices that are communicating with the WTP. This may
+ include the creation of local data structures in the WTP for the
+ managed devices and the collection of statistical information about
+ the communication between the WTP and the 802.11 devices. LWAPP
+ provides the ability for the AC to obtain any statistical information
+ collected by the WTP.
+
+ LWAPP also provides for a keepalive feature that preserves the
+ communication channel between the WTP and AC. If the AC fails to
+ appear alive, the WTP will try to discover a new AC to communicate
+ through.
+
+ This document uses terminology defined in [5].
+
+2.1. Wireless Binding Definition
+
+ This draft standard specifies a protocol independent of a specific
+ wireless access point radio technology. Elements of the protocol are
+ designed to accommodate specific needs of each wireless technology in
+ a standard way. Implementation of this standard for a particular
+ wireless technology must follow the binding requirements defined for
+ that technology. This specification includes a binding for the IEEE
+ 802.11 (see Section 11).
+
+ When defining a binding for other technologies, the authors MUST
+ include any necessary definitions for technology-specific messages
+ and all technology-specific message elements for those messages. At
+ a minimum, a binding MUST provide the definition for a binding-
+ specific Statistics message element, which is carried in the WTP
+ Event Request message, and Add Mobile message element, which is
+ carried in the Mobile Configure Request. If any technology-specific
+ message elements are required for any of the existing LWAPP messages
+ defined in this specification, they MUST also be defined in the
+ technology-binding document.
+
+ The naming of binding-specific message elements MUST begin with the
+ name of the technology type, e.g., the binding for IEEE 802.11,
+ provided in this standard, begins with "IEEE 802.11".
+
+
+
+Calhoun, et al. Historic [Page 11]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+2.2. LWAPP State Machine Definition
+
+ The following state diagram represents the life cycle of a WTP-AC
+ session:
+
+ /-------------\
+ | v
+ | +------------+
+ | C| Idle |<-----------------------------------\
+ | +------------+<-----------------------\ |
+ | ^ |a ^ | |
+ | | | \----\ | |
+ | | | | +------------+ |
+ | | | | -------| Key Confirm| |
+ | | | | w/ +------------+ |
+ | | | | | ^ |
+ | | | |t V |5 |
+ | | | +-----------+ +------------+ |
+ | / | C| Run | | Key Update | |
+ | / | r+-----------+------>+------------+ |
+ | / | ^ |s u x| |
+ | | v | | | |
+ | | +--------------+ | | v |y
+ | | C| Discovery | q| \--------------->+-------+
+ | | b+--------------+ +-------------+ | Reset |
+ | | |d f| ^ | Configure |------->+-------+
+ | | | | | +-------------+p ^
+ | |e v | | ^ |
+ | +---------+ v |i 2| |
+ | C| Sulking | +------------+ +--------------+ |
+ | +---------+ C| Join |--->| Join-Confirm | |
+ | g+------------+z +--------------+ |
+ | |h m| 3| |4 |
+ | | | | v |o
+ |\ | | | +------------+
+ \\-----------------/ \--------+---->| Image Data |C
+ \------------------------------------/ +------------+n
+
+ Figure 2: LWAPP State Machine
+
+ The LWAPP state machine, depicted above, is used by both the AC and
+ the WTP. For every state defined, only certain messages are
+ permitted to be sent and received. In all of the LWAPP control
+ messages defined in this document, the state for which each command
+ is valid is specified.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 12]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Note that in the state diagram figure above, the 'C' character is
+ used to represent a condition that causes the state to remain the
+ same.
+
+ The following text discusses the various state transitions, and the
+ events that cause them.
+
+ Idle to Discovery (a): This is the initialization state.
+
+ WTP: The WTP enters the Discovery state prior to transmitting the
+ first Discovery Request (see Section 5.1). Upon entering
+ this state, the WTP sets the DiscoveryInterval timer (see
+ Section 12). The WTP resets the DiscoveryCount counter to
+ zero (0) (see Section 13). The WTP also clears all
+ information from ACs (e.g., AC Addresses) it may have
+ received during a previous discovery phase.
+
+ AC: The AC does not need to maintain state information for the
+ WTP upon reception of the Discovery Request, but it MUST
+ respond with a Discovery Response (see Section 5.2).
+
+ Discovery to Discovery (b): This is the state the WTP uses to
+ determine to which AC it wishes to connect.
+
+ WTP: This event occurs when the DiscoveryInterval timer expires.
+ The WTP transmits a Discovery Request to every AC to which
+ the WTP hasn't received a response. For every transition to
+ this event, the WTP increments the DisoveryCount counter.
+ See Section 5.1 for more information on how the WTP knows to
+ which ACs it should transmit the Discovery Requests. The
+ WTP restarts the DiscoveryInterval timer.
+
+ AC: This is a noop.
+
+ Discovery to Sulking (d): This state occurs on a WTP when Discovery
+ or connectivity to the AC fails.
+
+ WTP: The WTP enters this state when the DiscoveryInterval timer
+ expires and the DiscoveryCount variable is equal to the
+ MaxDiscoveries variable (see Section 13). Upon entering
+ this state, the WTP will start the SilentInterval timer.
+ While in the Sulking state, all LWAPP messages received are
+ ignored.
+
+ AC: This is a noop.
+
+ Sulking to Idle (e): This state occurs on a WTP when it must restart
+ the discovery phase.
+
+
+
+Calhoun, et al. Historic [Page 13]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ WTP: The WTP enters this state when the SilentInterval timer (see
+ Section 12) expires.
+
+ AC: This is a noop.
+
+ Discovery to Join (f): This state is used by the WTP to confirm its
+ commitment to an AC that it wishes to be provided service.
+
+ WTP: The WTP selects the best AC based on the information it
+ gathered during the discovery phase. It then transmits a
+ Join Request (see Section 6.1) to its preferred AC. The WTP
+ starts the WaitJoin timer (see Section 12).
+
+ AC: The AC enters this state for the given WTP upon reception of
+ a Join Request. The AC processes the request and responds
+ with a Join Response.
+
+ Join to Join (g): This state transition occurs during the join
+ phase.
+
+ WTP: The WTP enters this state when the WaitJoin timer expires,
+ and the underlying transport requires LWAPP MTU detection
+ (Section 3).
+
+ AC: This state occurs when the AC receives a retransmission of a
+ Join Request. The WTP processes the request and responds
+ with the Join Response.
+
+ Join to Idle (h): This state is used when the join process has
+ failed.
+
+ WTP: This state transition occurs if the WTP is configured to use
+ pre-shared key (PSK) security and receives a Join Response
+ that includes an invalid PSK-MIC (Message Integrity Check)
+ message element.
+
+ AC: The AC enters this state when it transmits an unsuccessful
+ Join Response.
+
+ Join to Discovery (i): This state is used when the join process has
+ failed.
+
+ WTP: The WTP enters this state when it receives an unsuccessful
+ Join Response. Upon entering this state, the WTP sets the
+ DiscoveryInterval timer (see Section 12). The WTP resets
+ the DiscoveryCount counter to zero (0) (see Section 13).
+ This state transition may also occur if the PSK-MIC (see
+ Section 6.2.9) message element is invalid.
+
+
+
+Calhoun, et al. Historic [Page 14]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ AC: This state transition is invalid.
+
+ Join to Join-Confirm (z): This state is used to provide key
+ confirmation during the join process.
+
+ WTP: This state is entered when the WTP receives a Join Response.
+ In the event that certificate-based security is utilized,
+ this transition will occur if the Certificate message
+ element is present and valid in the Join Response. For pre-
+ shared key security, the Join Response must include a valid
+ and authenticated PSK-MIC message element. The WTP MUST
+ respond with a Join ACK, which is used to provide key
+ confirmation.
+
+ AC: The AC enters this state when it receives a valid Join ACK.
+ For certificate-based security, the Join ACK MUST include
+ the WNonce message element. For pre-shared key security,
+ the message must include a valid PSK-MIC message element.
+ The AC MUST respond with a Join Confirm message, which
+ includes the Session Key message element.
+
+ Join-Confirm to Idle (3): This state is used when the join process
+ has failed.
+
+ WTP: This state transition occurs when the WTP receives an
+ invalid Join Confirm.
+
+ AC: The AC enters this state when it receives an invalid Join
+ ACK.
+
+ Join-Confirm to Configure (2): This state is used by the WTP and the
+ AC to exchange configuration information.
+
+ WTP: The WTP enters this state when it receives a successful Join
+ Confirm and determines that its version number and the
+ version number advertised by the AC are the same. The WTP
+ transmits the Configure Request (see Section 7.2) message to
+ the AC with a snapshot of its current configuration. The
+ WTP also starts the ResponseTimeout timer (see Section 12).
+
+ AC: This state transition occurs when the AC receives the
+ Configure Request from the WTP. The AC must transmit a
+ Configure Response (see Section 7.3) to the WTP, and may
+ include specific message elements to override the WTP's
+ configuration.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 15]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Join-Confirm to Image Data (4): This state is used by the WTP and
+ the AC to download executable firmware.
+
+ WTP: The WTP enters this state when it receives a successful Join
+ Confirm, and determines that its version number and the
+ version number advertised by the AC are different. The WTP
+ transmits the Image Data Request (see Section 8.1) message
+ requesting that the AC's latest firmware be initiated.
+
+ AC: This state transition occurs when the AC receives the Image
+ Data Request from the WTP. The AC must transmit an Image
+ Data Response (see Section 8.2) to the WTP, which includes a
+ portion of the firmware.
+
+ Image Data to Image Data (n): This state is used by the WTP and the
+ AC during the firmware download phase.
+
+ WTP: The WTP enters this state when it receives an Image Data
+ Response that indicates that the AC has more data to send.
+
+ AC: This state transition occurs when the AC receives the Image
+ Data Request from the WTP while already in this state, and
+ it detects that the firmware download has not completed.
+
+ Image Data to Reset (o): This state is used when the firmware
+ download is completed.
+
+ WTP: The WTP enters this state when it receives an Image Data
+ Response that indicates that the AC has no more data to
+ send, or if the underlying LWAPP transport indicates a link
+ failure. At this point, the WTP reboots itself.
+
+ AC: This state transition occurs when the AC receives the Image
+ Data Request from the WTP while already in this state, and
+ it detects that the firmware download has completed or if
+ the underlying LWAPP transport indicates a link failure.
+ Note that the AC itself does not reset, but it places the
+ specific WTP's context it is communicating with in the reset
+ state: meaning that it clears all state associated with the
+ WTP.
+
+ Configure to Reset (p): This state transition occurs if the
+ configure phase fails.
+
+ WTP: The WTP enters this state when the reliable transport fails
+ to deliver the Configure Request, or if the ResponseTimeout
+ timer (see Section 12) expires.
+
+
+
+
+Calhoun, et al. Historic [Page 16]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ AC: This state transition occurs if the AC is unable to transmit
+ the Configure Response to a specific WTP. Note that the AC
+ itself does not reset, but it places the specific WTP's
+ context it is communicating with in the reset state: meaning
+ that it clears all state associated with the WTP.
+
+ Configure to Run (q): This state transition occurs when the WTP and
+ AC enter their normal state of operation.
+
+ WTP: The WTP enters this state when it receives a successful
+ Configure Response from the AC. The WTP initializes the
+ HeartBeat timer (see Section 12), and transmits the Change
+ State Event Request message (see Section 7.6).
+
+ AC: This state transition occurs when the AC receives the Change
+ State Event Request (see Section 7.6) from the WTP. The AC
+ responds with a Change State Event Response (see Section
+ 7.7) message. The AC must start the Session ID and
+ NeighborDead timers (see Section 12).
+
+ Run to Run (r): This is the normal state of operation.
+
+ WTP: This is the WTP's normal state of operation, and there are
+ many events that cause this to occur:
+
+ Configuration Update: The WTP receives a Configuration Update
+ Request (see Section 7.4). The WTP MUST respond with a
+ Configuration Update Response (see Section 7.5).
+
+ Change State Event: The WTP receives a Change State Event
+ Response, or determines that it must initiate a Change State
+ Event Request, as a result of a failure or change in the state
+ of a radio.
+
+ Echo Request: The WTP receives an Echo Request message
+ (Section 6.5), to which it MUST respond with an Echo Response
+ (see Section 6.6).
+
+ Clear Config Indication: The WTP receives a Clear Config
+ Indication message (Section 7.8). The WTP MUST reset its
+ configuration back to manufacturer defaults.
+
+ WTP Event: The WTP generates a WTP Event Request to send
+ information to the AC (Section 8.5). The WTP receives a WTP
+ Event Response from the AC (Section 8.6).
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 17]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Data Transfer: The WTP generates a Data Transfer Request to
+ the AC (Section 8.7). The WTP receives a Data Transfer
+ Response from the AC (Section 8.8).
+
+ WLAN Config Request: The WTP receives a WLAN Config Request
+ message (Section 11.8.1), to which it MUST respond with a WLAN
+ Config Response (see Section 11.8.2).
+
+ Mobile Config Request: The WTP receives an Mobile Config
+ Request message (Section 9.1), to which it MUST respond with a
+ Mobile Config Response (see Section 9.2).
+
+ AC: This is the AC's normal state of operation, and there are
+ many events that cause this to occur:
+
+ Configuration Update: The AC sends a Configuration Update
+ Request (see Section 7.4) to the WTP to update its
+ configuration. The AC receives a Configuration Update Response
+ (see Section 7.5) from the WTP.
+
+ Change State Event: The AC receives a Change State Event
+ Request (see Section 7.6), to which it MUST respond with the
+ Change State Event Response (see Section 7.7).
+
+ Echo: The AC sends an Echo Request message (Section 6.5) or
+ receives the associated Echo Response (see Section 6.6) from
+ the WTP.
+
+ Clear Config Indication: The AC sends a Clear Config
+ Indication message (Section 7.8).
+
+ WLAN Config: The AC sends a WLAN Config Request message
+ (Section 11.8.1) or receives the associated WLAN Config
+ Response (see Section 11.8.2) from the WTP.
+
+ Mobile Config: The AC sends a Mobile Config Request message
+ (Section 9.1) or receives the associated Mobile Config Response
+ (see Section 9.2) from the WTP.
+
+ Data Transfer: The AC receives a Data Transfer Request from
+ the AC (see Section 8.7) and MUST generate the associated Data
+ Transfer Response message (see Section 8.8).
+
+ WTP Event: The AC receives a WTP Event Request from the AC
+ (see Section 8.5) and MUST generate the associated WTP Event
+ Response message (see Section 8.6).
+
+
+
+
+
+Calhoun, et al. Historic [Page 18]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Run to Reset (s): This event occurs when the AC wishes for the WTP
+ to reboot.
+
+ WTP: The WTP enters this state when it receives a Reset Request
+ (see Section 8.3). It must respond with a Reset Response
+ (see Section 8.4), and once the reliable transport
+ acknowledgement has been received, it must reboot itself.
+
+ AC: This state transition occurs either through some
+ administrative action, or via some internal event on the AC
+ that causes it to request that the WTP disconnect. Note
+ that the AC itself does not reset, but it places the
+ specific WTPs context it is communicating with in the reset
+ state.
+
+ Run to Idle (t): This event occurs when an error occurs in the
+ communication between the WTP and the AC.
+
+ WTP: The WTP enters this state when the underlying reliable
+ transport is unable to transmit a message within the
+ RetransmitInterval timer (see Section 12), and the maximum
+ number of RetransmitCount counter has reached the
+ MaxRetransmit variable (see Section 13).
+
+ AC: The AC enters this state when the underlying reliable
+ transport in unable to transmit a message within the
+ RetransmitInterval timer (see Section 12), and the maximum
+ number of RetransmitCount counter has reached the
+ MaxRetransmit variable (see Section 13).
+
+ Run to Key Update (u): This event occurs when the WTP and the AC are
+ to exchange new keying material, with which it must use to protect
+ all future messages.
+
+ WTP: This state transition occurs when the KeyLifetime timer
+ expires (see Section 12).
+
+ AC: The WTP enters this state when it receives a Key Update
+ Request (see Section 6.7).
+
+ Key Update to Key Confirm (w): This event occurs during the rekey
+ phase and is used to complete the loop.
+
+ WTP: This state transition occurs when the WTP receives the Key
+ Update Response. The WTP MUST only accept the message if it
+ is authentic. The WTP responds to this response with a Key
+ Update ACK.
+
+
+
+
+Calhoun, et al. Historic [Page 19]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ AC: The AC enters this state when it receives an authenticated
+ Key Update ACK message.
+
+ Key Confirm to Run (5): This event occurs when the rekey exchange
+ phase is completed.
+
+ WTP: This state transition occurs when the WTP receives the Key
+ Update Confirm. The newly derived encryption key and
+ Initialization Vector (IV) must be plumbed into the crypto
+ module after validating the message's authentication.
+
+ AC: The AC enters this state when it transmits the Key Update
+ Confirm message. The newly derived encryption key and IV
+ must be plumbed into the crypto module after transmitting a
+ Key Update Confirm message.
+
+ Key Update to Reset (x): This event occurs when the key exchange
+ phase times out.
+
+ WTP: This state transition occurs when the WTP does not receive a
+ Key Update Response from the AC.
+
+ AC: The AC enters this state when it is unable to process a Key
+ Update Request.
+
+ Reset to Idle (y): This event occurs when the state machine is
+ restarted.
+
+ WTP: The WTP reboots itself. After rebooting, the WTP will start
+ its LWAPP state machine in the Idle state.
+
+ AC: The AC clears out any state associated with the WTP. The AC
+ generally does this as a result of the reliable link layer
+ timing out.
+
+3. LWAPP Transport Layers
+
+ The LWAPP protocol can operate at Layer 2 or 3. For Layer 2 support,
+ the LWAPP messages are carried in a native Ethernet frame. As such,
+ the protocol is not routable and depends upon Layer 2 connectivity
+ between the WTP and the AC. Layer 3 support is provided by
+ encapsulating the LWAPP messages within UDP.
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 20]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+3.1. LWAPP Transport Header
+
+ All LWAPP protocol packets are encapsulated using a common header
+ format, regardless of the transport used to carry the frames.
+ However, certain flags are not applicable for a given transport, and
+ it is therefore necessary to refer to the specific transport section
+ in order to determine which flags are valid.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |VER| RID |C|F|L| Frag ID | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status/WLANs | Payload... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1. VER Field
+
+ A 2-bit field that contains the version of LWAPP used in this packet.
+ The value for this document is 0.
+
+3.1.2. RID Field
+
+ A 3-bit field that contains the Radio ID number for this packet.
+ WTPs with multiple radios but a single MAC address use this field to
+ indicate which radio is associated with the packet.
+
+3.1.3. C Bit
+
+ The control message 'C' bit indicates whether this packet carries a
+ data or control message. When this bit is zero (0), the packet
+ carries an LWAPP data message in the payload (see Section 4.1). When
+ this bit is one (1), the packet carries an LWAPP control message as
+ defined in Section 4.2 for consumption by the addressed destination.
+
+3.1.4. F Bit
+
+ The Fragment 'F' bit indicates whether this packet is a fragment.
+ When this bit is one (1), the packet is a fragment and MUST be
+ combined with the other corresponding fragments to reassemble the
+ complete information exchanged between the WTP and AC.
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 21]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+3.1.5. L Bit
+
+ The Not Last 'L' bit is valid only if the 'F' bit is set and
+ indicates whether the packet contains the last fragment of a
+ fragmented exchange between the WTP and AC. When this bit is 1, the
+ packet is not the last fragment. When this bit is 0, the packet is
+ the last fragment.
+
+3.1.6. Fragment ID
+
+ An 8-bit field whose value is assigned to each group of fragments
+ making up a complete set. The Fragment ID space is managed
+ individually for every WTP/AC pair. The value of Fragment ID is
+ incremented with each new set of fragments. The Fragment ID wraps to
+ zero after the maximum value has been used to identify a set of
+ fragments. LWAPP only supports up to 2 fragments per frame.
+
+3.1.7. Length
+
+ The 16-bit length field contains the number of bytes in the Payload.
+ The field is encoded as an unsigned number. If the LWAPP packet is
+ encrypted, the length field includes the Advanced Encryption Standard
+ Counter with CBC-MAC (AES-CCM) MIC (see Section 10.2 for more
+ information).
+
+3.1.8. Status and WLANS
+
+ The interpretation of this 16-bit field is binding-specific. Refer
+ to the transport portion of the binding for a wireless technology for
+ the specification.
+
+3.1.9. Payload
+
+ This field contains the header for an LWAPP data message or LWAPP
+ control message, followed by the data associated with that message.
+
+3.2. Using IEEE 802.3 MAC as LWAPP Transport
+
+ This section describes how the LWAPP protocol is provided over native
+ Ethernet frames. An LWAPP packet is formed from the MAC frame
+ header, followed by the LWAPP message header. The following figure
+ provides an example of the frame formats used when LWAPP is used over
+ the IEEE 802.3 transport.
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 22]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Layer 2 LWAPP Data Frame
+ +-----------------------------------------------------------+
+ | MAC Header | LWAPP Header [C=0] | Forwarded Data ... |
+ +-----------------------------------------------------------+
+
+ Layer 2 LWAPP Control Frame
+ +---------------------------------------------------+
+ | MAC Header | LWAPP Header [C=1] | Control Message |
+ +---------------------------------------------------+
+ | Message Elements ... |
+ +----------------------+
+
+3.2.1. Framing
+
+ Source Address
+
+ A MAC address belonging to the interface from which this message is
+ sent. If multiple source addresses are configured on an interface,
+ then the one chosen is implementation-dependent.
+
+ Destination Address
+
+ A MAC address belonging to the interface to which this message is to
+ be sent. This destination address MAY be either an individual
+ address or a multicast address, if more than one destination
+ interface is intended.
+
+ Ethertype
+
+ The Ethertype field is set to 0x88bb.
+
+3.2.2. AC Discovery
+
+ When run over IEEE 802.3, LWAPP messages are distributed to a
+ specific MAC-level broadcast domain. The AC discovery mechanism used
+ with this transport is for a WTP to transmit a Discovery Request
+ message to a broadcast destination MAC address. The ACs will receive
+ this message and reply based on their policy.
+
+3.2.3. LWAPP Message Header Format over IEEE 802.3 MAC Transport
+
+ All of the fields described in Section 3.1 are used when LWAPP uses
+ the IEEE 802.3 MAC transport.
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 23]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+3.2.4. Fragmentation/Reassembly
+
+ Fragmentation at the MAC layer is managed using the F, L, and Frag ID
+ fields of the LWAPP message header. The LWAPP protocol only allows a
+ single packet to be fragmented into 2, which is sufficient for a
+ frame that exceeds MTU due to LWAPP encapsulation. When used with
+ Layer 2 (Ethernet) transport, both fragments MUST include the LWAPP
+ header.
+
+3.2.5. Multiplexing
+
+ LWAPP control messages and data messages are distinguished by the 'C'
+ bit in the LWAPP message header.
+
+3.3. Using IP/UDP as LWAPP Transport
+
+ This section defines how LWAPP makes use of IP/UDP transport between
+ the WTP and the AC. When this transport is used, the MAC layer is
+ controlled by the IP stack, and there are therefore no special MAC-
+ layer requirements. The following figure provides an example of the
+ frame formats used when LWAPP is used over the IP/UDP transport. IP
+ stacks can be either IPv4 or IPv6.
+
+ Layer 3 LWAPP Data Frame
+ +--------------------------------------------+
+ | MAC Header | IP | UDP | LWAPP Header [C=0] |
+ +--------------------------------------------+
+ |Forwarded Data ... |
+ +-------------------+
+
+ Layer 3 LWAPP Control Frame
+ +--------------------------------------------+
+ | MAC Header | IP | UDP | LWAPP Header [C=1] |
+ +--------------------------------------------+
+ | Control Message | Message Elements ... |
+ +-----------------+----------------------+
+
+3.3.1. Framing
+
+ Communication between the WTP and AC is established according to the
+ standard UDP client/server model. The connection is initiated by the
+ WTP (client) to the well-known UDP port of the AC (server) used for
+ control messages. This UDP port number of the AC is 12222 for LWAPP
+ data and 12223 for LWAPP control frames.
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 24]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+3.3.2. AC Discovery
+
+ When LWAPP is run over routed IP networks, the WTP and the AC do not
+ need to reside in the same IP subnet (broadcast domain). However, in
+ the event the peers reside on separate subnets, there must exist a
+ mechanism for the WTP to discover the AC.
+
+ As the WTP attempts to establish communication with the AC, it sends
+ the Discovery Request message and receives the corresponding response
+ message from the AC. The WTP must send the Discovery Request message
+ to either the limited broadcast IP address (255.255.255.255), a well
+ known multicast address, or the unicast IP address of the AC. Upon
+ receipt of the message, the AC issues a Discovery Response message to
+ the unicast IP address of the WTP, regardless of whether a Discovery
+ Request was sent as a broadcast, multicast, or unicast message.
+
+ Whether the WTP uses a limited IP broadcast, multicast or unicast IP
+ address is implementation-dependent.
+
+ In order for a WTP to transmit a Discovery Request to a unicast
+ 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
+ storage is implementation-dependent. However, additional dynamic
+ schemes are possible: for example:
+
+ DHCP: A comma-delimited, ASCII-encoded list of AC IP addresses is
+ embedded inside a DHCP vendor-specific option 43 extension.
+ An example of the actual format of the vendor-specific payload
+ for IPv4 is of the form "10.1.1.1, 10.1.1.2".
+
+ DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to one or
+ more AC addresses.
+
+3.3.3. LWAPP Message Header Format over IP/UDP Transport
+
+ All of the fields described in Section 3.1 are used when LWAPP uses
+ the IPv4/UDP or IPv6/UDP transport, with the following exceptions.
+
+3.3.3.1. F Bit
+
+ This flag field is not used with this transport, and MUST be set to
+ zero.
+
+3.3.3.2. L Bit
+
+ This flag field is not used with this transport, and MUST be set to
+ zero.
+
+
+
+
+Calhoun, et al. Historic [Page 25]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+3.3.3.3. Frag ID
+
+ This field is not used with this transport, and MUST be set to zero.
+
+3.3.4. Fragmentation/Reassembly for IPv4
+
+ When LWAPP is implemented at L3, the transport layer uses IP
+ fragmentation to fragment and reassemble LWAPP messages that are
+ longer than the MTU size used by either the WTP or AC. The details
+ of IP fragmentation are covered in [8]. When used with the IP
+ transport, only the first fragment would include the LWAPP header.
+
+3.3.5. Fragmentation/Reassembly for IPv6
+
+ IPv6 does MTU discovery so fragmentation and re-assembly is not
+ necessary for UDP packets.
+
+3.3.6. Multiplexing
+
+ LWAPP messages convey control information between WTP and AC, as well
+ as binding specific data frames or binding specific management
+ frames. As such, LWAPP messages need to be multiplexed in the
+ transport sub-layer and be delivered to the proper software entities
+ in the endpoints of the protocol. However, the 'C' bit is still used
+ to differentiate between data and control frames.
+
+ In case of Layer 3 connection, multiplexing is achieved by use of
+ different UDP ports for control and data packets (see Section 3.3.1).
+
+ As part of the Join procedure, the WTP and AC may negotiate different
+ IP Addresses for data or control messages. The IP address returned
+ in the AP Manager Control IP Address message element is used to
+ inform the WTP with the IP address to which it must send all control
+ frames. The AP Manager Data IP Address message element MAY be
+ present only if the AC has a different IP address that the WTP is to
+ use to send its data LWAPP frames.
+
+ In the event the WTP and AC are separated by a NAT, with the WTP
+ using private IP address space, it is the responsibility of the NAT
+ to manage appropriate UDP port mapping.
+
+4. LWAPP Packet Definitions
+
+ This section contains the packet types and format. The LWAPP
+ protocol is designed to be transport-agnostic by specifying packet
+ formats for both MAC frames and IP packets. An LWAPP packet consists
+ of an LWAPP Transport Layer packet header followed by an LWAPP
+ message.
+
+
+
+Calhoun, et al. Historic [Page 26]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Transport details can be found in Section 3.
+
+4.1. LWAPP Data Messages
+
+ An LWAPP data message is a forwarded wireless frame. When forwarding
+ wireless frames, the sender simply encapsulates the wireless frame in
+ an LWAPP data packet, using the appropriate transport rules defined
+ in Section 3.
+
+ In the event that the encapsulated frame would exceed the transport
+ layer's MTU, the sender is responsible for the fragmentation of the
+ frame, as specified in the transport-specific section of Section 3.
+
+ The actual format of the encapsulated LWAPP data frame is subject to
+ the rules defined under the specific wireless technology binding.
+
+4.2. LWAPP Control Messages Overview
+
+ The LWAPP Control protocol provides a control channel between the WTP
+ and the AC. The control channel is the series of control messages
+ between the WTP and AC, associated with a session ID and key.
+ Control messages are divided into the following distinct message
+ types:
+
+ Discovery: LWAPP Discovery messages are used to identify potential
+ ACs, their load and capabilities.
+
+ Control Channel Management: Messages that fall within this
+ classification are used for the discovery of ACs by the WTPs as
+ well as the establishment and maintenance of an LWAPP control
+ channel.
+
+ WTP Configuration: The WTP Configuration messages are used by the AC
+ to push a specific configuration to the WTPs with which it has a
+ control channel. Messages that deal with the retrieval of
+ statistics from the WTP also fall in this category.
+
+ Mobile Session Management: Mobile Session Management messages are
+ used by the AC to push specific mobile policies to the WTP.
+
+ Firmware Management: Messages in this category are used by the AC to
+ push a new firmware image down to the WTP.
+
+ Control Channel, WTP Configuration, and Mobile Session Management
+ MUST be implemented. Firmware Management MAY be implemented.
+
+ In addition, technology-specific bindings may introduce new control
+ channel commands that depart from the above list.
+
+
+
+Calhoun, et al. Historic [Page 27]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+4.2.1. Control Message Format
+
+ All LWAPP control messages are sent encapsulated within the LWAPP
+ header (see Section 3.1). Immediately following the header is the
+ LWAPP control header, which has the following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message Type | Seq Num | Msg Element Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Msg Element [0..N] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.2.1.1. Message Type
+
+ The Message Type field identifies the function of the LWAPP control
+ message. The valid values for a Message Type are the following:
+
+ Description Value
+ Discovery Request 1
+ Discovery Response 2
+ Join Request 3
+ Join Response 4
+ Join ACK 5
+ Join Confirm 6
+ Unused 7-9
+ Configure Request 10
+ Configure Response 11
+ Configuration Update Request 12
+ Configuration Update Response 13
+ WTP Event Request 14
+ WTP Event Response 15
+ Change State Event Request 16
+ Change State Event Response 17
+ Unused 18-21
+ Echo Request 22
+ Echo Response 23
+ Image Data Request 24
+ Image Data Response 25
+ Reset Request 26
+ Reset Response 27
+ Unused 28-29
+ Key Update Request 30
+ Key Update Response 31
+ Primary Discovery Request 32
+
+
+
+Calhoun, et al. Historic [Page 28]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Primary Discovery Response 33
+ Data Transfer Request 34
+ Data Transfer Response 35
+ Clear Config Indication 36
+ WLAN Config Request 37
+ WLAN Config Response 38
+ Mobile Config Request 39
+ Mobile Config Response 40
+
+4.2.1.2. Sequence Number
+
+ The Sequence Number field is an identifier value to match request/
+ response packet exchanges. When an LWAPP packet with a request
+ message type is received, the value of the Sequence Number field is
+ copied into the corresponding response packet.
+
+ When an LWAPP control frame is sent, its internal sequence number
+ counter is monotonically incremented, ensuring that no two requests
+ pending have the same sequence number. This field will wrap back to
+ zero.
+
+4.2.1.3. Message Element Length
+
+ The length field indicates the number of bytes following the Session
+ ID field. If the LWAPP packet is encrypted, the length field
+ includes the AES-CCM MIC (see Section 10.2 for more information).
+
+4.2.1.4. Session ID
+
+ The Session ID is a 32-bit unsigned integer that is used to identify
+ the security context for encrypted exchanges between the WTP and the
+ AC. Note that a Session ID is a random value that MUST be unique
+ between a given AC and any of the WTPs with which it may be
+ communicating.
+
+4.2.1.5. Message Element [0..N]
+
+ The message element(s) carry the information pertinent to each of the
+ control message types. Every control message in this specification
+ specifies which message elements are permitted.
+
+4.2.2. Message Element Format
+
+ The message element is used to carry information pertinent to a
+ control message. Every message element is identified by the Type
+ field, whose numbering space is managed via IANA (see Section 16).
+ The total length of the message elements is indicated in the Message
+ Element Length field.
+
+
+
+Calhoun, et al. Historic [Page 29]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ All of the message element definitions in this document use a diagram
+ similar to the one below in order to depict their formats. Note that
+ in order to simplify this specification, these diagrams do not
+ include the header fields (Type and Length). However, in each
+ message element description, the header's field values will be
+ defined.
+
+ Note that additional message elements may be defined in separate IETF
+ documents.
+
+ The format of a message element uses the TLV format shown here:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Value ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where Type (8 bits) identifies the character of the information
+ carried in the Value field and Length (16 bits) indicates the number
+ of bytes in the Value field.
+
+4.2.2.1. Generic Message Elements
+
+ This section includes message elements that are not bound to a
+ specific control message.
+
+4.2.2.1.1. Vendor Specific
+
+ The Vendor-Specific Payload is used to communicate vendor-specific
+ information between the WTP and the AC. The value contains the
+ following format:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Element ID | Value... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 104 for Vendor Specific
+
+ Length: >= 7
+
+ Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI
+ Network Management Private Enterprise Codes" [13].
+
+
+
+
+Calhoun, et al. Historic [Page 30]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Element ID: A 16-bit Element Identifier that is managed by the
+ vendor.
+
+ Value: The value associated with the vendor-specific element.
+
+4.2.3. Quality of Service
+
+ It is recommended that LWAPP control messages be sent by both the AC
+ and the WTP with an appropriate Quality-of-Service precedence value,
+ ensuring that congestion in the network minimizes occurrences of
+ LWAPP control channel disconnects. Therefore, a Quality-of-Service-
+ enabled LWAPP device should use:
+
+ 802.1P: The precedence value of 7 SHOULD be used.
+
+ DSCP: The Differentiated Services Code Point (DSCP) tag value of 46
+ SHOULD be used.
+
+5. LWAPP Discovery Operations
+
+ The Discovery messages are used by a WTP to determine which ACs are
+ available to provide service, as well as the capabilities and load of
+ the ACs.
+
+5.1. Discovery Request
+
+ The Discovery Request is used by the WTP to automatically discover
+ potential ACs available in the network. A WTP must transmit this
+ command even if it has a statically configured AC, as it is a
+ required step in the LWAPP state machine.
+
+ Discovery Requests MUST be sent by a WTP in the Discover state after
+ waiting for a random delay less of than MaxDiscoveryInterval, after a
+ WTP first comes up or is (re)initialized. A WTP MUST send no more
+ than a maximum of MaxDiscoveries discoveries, waiting for a random
+ delay less than MaxDiscoveryInterval between each successive
+ discovery.
+
+ This is to prevent an explosion of WTP Discoveries. An example of
+ this occurring would be when many WTPs are powered on at the same
+ time.
+
+ Discovery Requests MUST be sent by a WTP when no Echo Responses are
+ received for NeighborDeadInterval and the WTP returns to the Idle
+ state. Discovery Requests are sent after NeighborDeadInterval, they
+ MUST be sent after waiting for a random delay less than
+
+
+
+
+
+Calhoun, et al. Historic [Page 31]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ MaxDiscoveryInterval. A WTP MAY send up to a maximum of
+ MaxDiscoveries discoveries, waiting for a random delay less than
+ MaxDiscoveryInterval between each successive discovery.
+
+ If a Discovery Response is not received after sending the maximum
+ number of Discovery Requests, the WTP enters the Sulking state and
+ MUST wait for an interval equal to SilentInterval before sending
+ further Discovery Requests.
+
+ The Discovery Request message may be sent as a unicast, broadcast, or
+ multicast message.
+
+ Upon receiving a Discovery Request, the AC will respond with a
+ Discovery Response sent to the address in the source address of the
+ received Discovery Request.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+5.1.1. Discovery Type
+
+ The Discovery message element is used to configure a WTP to operate
+ in a specific mode.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Discovery Type|
+ +-+-+-+-+-+-+-+-+
+
+ Type: 58 for Discovery Type
+
+ Length: 1
+
+ Discovery Type: An 8-bit value indicating how the AC was
+ discovered. The following values are supported:
+
+ 0 - Broadcast
+
+ 1 - Configured
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 32]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+5.1.2. WTP Descriptor
+
+ The WTP Descriptor message element is used by the WTP to communicate
+ its current hardware/firmware configuration. The value contains the
+ following fields.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hardware Version |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Software Version |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Boot Version |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Max Radios | Radios in use | Encryption Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 3 for WTP Descriptor
+
+ Length: 16
+
+ Hardware Version: A 32-bit integer representing the WTP's hardware
+ version number.
+
+ Software Version: A 32-bit integer representing the WTP's Firmware
+ version number.
+
+ Boot Version: A 32-bit integer representing the WTP's boot loader's
+ version number.
+
+ Max Radios: An 8-bit value representing the number of radios (where
+ each radio is identified via the RID field) supported by the WTP.
+
+ Radios in Use: An 8-bit value representing the number of radios
+ present in the WTP.
+
+ Encryption Capabilities: This 16-bit field is used by the WTP to
+ communicate its capabilities to the AC. Since most WTPs support
+ link-layer encryption, the AC may make use of these services.
+ There are binding-dependent encryption capabilites. A WTP that
+ does not have any encryption capabilities would set this field to
+ zero (0). Refer to the specific binding for the specification.
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 33]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+5.1.3. WTP Radio Information
+
+ The WTP Radio Information message element is used to communicate the
+ radio information in a specific slot. The Discovery Request MUST
+ include one such message element per radio in the WTP. The Radio-
+ Type field is used by the AC in order to determine which technology-
+ specific binding is to be used with the WTP.
+
+ The value contains two fields, as shown:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Radio Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 4 for WTP Radio Information
+
+ Length: 2
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ Radio Type: The type of radio present. The following values are
+ supported:
+
+ 1 - 802.11bg: An 802.11bg radio.
+
+ 2 - 802.11a: An 802.11a radio.
+
+ 3 - 802.16: An 802.16 radio.
+
+ 4 - Ultra Wideband: A UWB radio.
+
+ 7 - all: Used to specify all radios in the WTP.
+
+5.2. Discovery Response
+
+ The Discovery Response is a mechanism by which an AC advertises its
+ services to requesting WTPs.
+
+ Discovery Responses are sent by an AC after receiving a Discovery
+ Request.
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 34]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ When a WTP receives a Discovery Response, it MUST wait for an
+ interval not less than DiscoveryInterval for receipt of additional
+ Discovery Responses. After the DiscoveryInterval elapses, the WTP
+ enters the Joining state and will select one of the ACs that sent a
+ Discovery Response and send a Join Request to that AC.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+5.2.1. AC Address
+
+ The AC Address message element is used to communicate the identity of
+ the AC. The value contains two fields, as shown:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 2 for AC Address
+
+ Length: 7
+
+ Reserved: MUST be set to zero
+
+ MAC Address: The MAC address of the AC
+
+5.2.2. AC Descriptor
+
+ The AC Descriptor message element is used by the AC to communicate
+ its current state. The value contains the following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Hardware Version ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HW Ver | Software Version ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SW Ver | Stations | Limit |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Limit | Radios | Max Radio |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Max Radio | Security |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Calhoun, et al. Historic [Page 35]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Type: 6 for AC Descriptor
+
+ Length: 17
+
+ Reserved: MUST be set to zero
+
+ Hardware Version: A 32-bit integer representing the AC's hardware
+ version number.
+
+ Software Version: A 32-bit integer representing the AC's Firmware
+ version number.
+
+ Stations: A 16-bit integer representing the number of mobile
+ stations currently associated with the AC.
+
+ Limit: A 16-bit integer representing the maximum number of stations
+ supported by the AC.
+
+ Radios: A 16-bit integer representing the number of WTPs currently
+ attached to the AC.
+
+ Max Radio: A 16-bit integer representing the maximum number of WTPs
+ supported by the AC.
+
+ Security: An 8-bit bitmask specifying the security schemes
+ supported by the AC. The following values are supported (see
+ Section 10):
+
+ 1 - X.509 Certificate-Based
+
+ 2 - Pre-Shared Secret
+
+5.2.3. AC Name
+
+ The AC Name message element contains an ASCII representation of the
+ AC's identity. The value is a variable-length byte string. The
+ string is NOT zero terminated.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Name ...
+ +-+-+-+-+-+-+-+-+
+
+ Type: 31 for AC Name
+
+ Length: > 0
+
+
+
+
+Calhoun, et al. Historic [Page 36]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Name: A variable-length ASCII string containing the AC's name.
+
+5.2.4. WTP Manager Control IPv4 Address
+
+ The WTP Manager 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 interfaces available on the AC, and their current load.
+ This message element is useful for the WTP to perform load balancing
+ across multiple interfaces.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 99 for WTP Manager Control IPv4 Address
+
+ Length: 6
+
+ IP Address: The IP address of an interface.
+
+ WTP Count: The number of WTPs currently connected to the interface.
+
+5.2.5. WTP Manager Control IPv6 Address
+
+ The WTP Manager 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 interfaces available on the AC, and their current load.
+ This message element is useful for the WTP to perform load balancing
+ across multiple interfaces.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Calhoun, et al. Historic [Page 37]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Type: 137 for WTP Manager Control IPv6 Address
+
+ Length: 6
+
+ IP Address: The IP address of an interface.
+
+ WTP Count: The number of WTPs currently connected to the interface.
+
+5.3. Primary Discovery Request
+
+ The Primary Discovery Request is sent by the WTP in order to
+ determine whether its preferred (or primary) AC is available.
+
+ Primary Discovery Requests are sent by a WTP when it has a primary AC
+ configured, and is connected to another AC. This generally occurs as
+ a result of a failover, and is used by the WTP as a means to discover
+ when its primary AC becomes available. As a consequence, this
+ message is only sent by a WTP when it is in the Run state.
+
+ The frequency of the Primary Discovery Requests should be no more
+ often than the sending of the Echo Request message.
+
+ Upon receiving a Discovery Request, the AC will respond with a
+ Primary Discovery Response sent to the address in the source address
+ of the received Primary Discovery Request.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+5.3.1. Discovery Type
+
+ The Discovery Type message element is defined in Section 5.1.1.
+
+5.3.2. WTP Descriptor
+
+ The WTP Descriptor message element is defined in Section 5.1.2.
+
+5.3.3. WTP Radio Information
+
+ A WTP Radio Information message element must be present for every
+ radio in the WTP. This message element is defined in Section 5.1.3.
+
+5.4. Primary Discovery Response
+
+ The Primary Discovery Response is a mechanism by which an AC
+ advertises its availability and services to requesting WTPs that are
+ configured to have the AC as its primary AC.
+
+
+
+
+Calhoun, et al. Historic [Page 38]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Primary Discovery Responses are sent by an AC after receiving a
+ Primary Discovery Request.
+
+ When a WTP receives a Primary Discovery Response, it may opt to
+ establish an LWAPP connection to its primary AC, based on the
+ configuration of the WTP Fallback Status message element on the WTP.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+5.4.1. AC Descriptor
+
+ The Discovery Type message element is defined in Section 5.2.2.
+
+5.4.2. AC Name
+
+ The AC Name message element is defined in Section 5.2.3.
+
+5.4.3. WTP Manager Control IPv4 Address
+
+ A WTP Radio Information message element MAY be present for every
+ radio in the WTP that is reachable via IPv4. This message element is
+ defined in Section 5.2.4.
+
+5.4.4. WTP Manager Control IPv6 Address
+
+ A WTP Radio Information message element must be present for every
+ radio in the WTP that is reachable via IPv6. This message element is
+ defined in Section 5.2.5.
+
+6. Control Channel Management
+
+ The Control Channel Management messages are used by the WTP and AC to
+ create and maintain a channel of communication on which various other
+ commands may be transmitted, such as configuration, firmware update,
+ etc.
+
+6.1. Join Request
+
+ The Join Request is used by a WTP to inform an AC that it wishes to
+ provide services through it.
+
+ Join Requests are sent by a WTP in the Joining state after receiving
+ one or more Discovery Responses. The Join Request is also used as an
+ MTU discovery mechanism by the WTP. The WTP issues a Join Request
+ with a Test message element, bringing the total size of the message
+ to exceed MTU.
+
+
+
+
+Calhoun, et al. Historic [Page 39]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ If the transport used does not provide MTU path discovery, the
+ initial Join Request is padded with the Test message element to 1596
+ bytes. If a Join Response is received, the WTP can forward frames
+ without requiring any fragmentation. If no Join Response is
+ received, it issues a second Join Request padded with the Test
+ payload to a total of 1500 bytes. The WTP continues to cycle from
+ large (1596) to small (1500) packets until a Join Response has been
+ received, or until both packets' sizes have been retransmitted 3
+ times. If the Join Response is not received after the maximum number
+ of retransmissions, the WTP MUST abandon the AC and restart the
+ discovery phase.
+
+ When an AC receives a Join Request, it will respond with a Join
+ Response. If the certificate-based security mechanism is used, the
+ AC validates the certificate found in the request. If valid, the AC
+ generates a session key that will be used to secure the control
+ frames it exchanges with the WTP. When the AC issues the Join
+ Response, the AC creates a context for the session with the WTP.
+
+ If the pre-shared session key security mechanism is used, the AC
+ saves the WTP's nonce, found in the WNonce message element, and
+ creates its own nonce, which it includes in the ANonce message
+ element. Finally, the AC creates the PSK-MIC, which is computed
+ using a key that is derived from the PSK.
+
+ A Join Request that includes both a WNonce and a Certificate message
+ element MUST be considered invalid.
+
+ Details on the key generation are found in Section 10.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.1.1. WTP Descriptor
+
+ The WTP Descriptor message element is defined in Section 5.1.2.
+
+6.1.2. AC Address
+
+ The AC Address message element is defined in Section 5.2.1.
+
+6.1.3. WTP Name
+
+ The WTP Name message element value is a variable-length byte string.
+ The string is NOT zero terminated.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 40]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Name ...
+ +-+-+-+-+-+-+-+-+
+
+ Type: 5 for WTP Name
+
+ Length: > 0
+
+ Name: A non-zero-terminated string containing the WTP's name.
+
+6.1.4. Location Data
+
+ The Location Data message element is a variable-length byte string
+ containing user-defined location information (e.g., "Next to
+ Fridge"). The string is NOT zero terminated.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Location ...
+ +-+-+-+-+-+-+-+-+
+
+ Type: 35 for Location Data
+
+ Length: > 0
+
+ Location: A non-zero-terminated string containing the WTP's
+ location.
+
+6.1.5. WTP Radio Information
+
+ A WTP Radio Information message element must be present for every
+ radio in the WTP. This message element is defined in Section 5.1.3.
+
+6.1.6. Certificate
+
+ The Certificate message element value is a byte string containing a
+ DER-encoded x.509v3 certificate. This message element is only
+ included if the LWAPP security type used between the WTP and the AC
+ makes use of certificates (see Section 10 for more information).
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Certificate...
+ +-+-+-+-+-+-+-+-+
+
+
+
+Calhoun, et al. Historic [Page 41]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Type: 44 for Certificate
+
+ Length: > 0
+
+ Certificate: A non-zero-terminated string containing the device's
+ certificate.
+
+6.1.7. Session ID
+
+ The Session ID message element value contains a randomly generated
+ [4] unsigned 32-bit integer.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 45 for Session ID
+
+ Length: 4
+
+ Session ID: 32-bit random session identifier.
+
+6.1.8. Test
+
+ The Test message element is used as padding to perform MTU discovery,
+ and it MAY contain any value, of any length.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Padding ...
+ +-+-+-+-+-+-+-+-+
+
+ Type: 18 for Test
+
+ Length: > 0
+
+ Padding: A variable-length pad.
+
+6.1.9. XNonce
+
+ The XNonce is used by the WTP to communicate its random nonce during
+ the join or rekey phase. See Section 10 for more information.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 42]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 111 for XNonce
+
+ Length: 16
+
+ Nonce: 1 16-octet random nonce.
+
+6.2. Join Response
+
+ The Join Response is sent by the AC to indicate to a WTP whether it
+ is capable and willing to provide service to it.
+
+ Join Responses are sent by the AC after receiving a Join Request.
+ Once the Join Response has been sent, the Heartbeat timer is
+ initiated for the session to EchoInterval. Expiration of the timer
+ will result in deletion of the AC-WTP session. The timer is
+ refreshed upon receipt of the Echo Request.
+
+ If the security method used is certificate-based, when a WTP receives
+ a Join Response, it enters the Joined state and initiates either a
+ Configure Request or Image Data to the AC to which it is now joined.
+ Upon entering the Joined state, the WTP begins timing an interval
+ equal to NeighborDeadInterval. Expiration of the timer will result
+ in the transmission of the Echo Request.
+
+ If the security method used is pre-shared-secret-based, when a WTP
+ receives a Join Response that includes a valid PSK-MIC message
+ element, it responds with a Join ACK that also MUST include a locally
+ computed PSK-MIC message element.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 43]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+6.2.1. Result Code
+
+ The Result Code message element value is a 32-bit integer value,
+ indicating the result of the request operation corresponding to the
+ sequence number in the message. The Result Code is included in a
+ successful Join Response.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 2 for Result Code
+
+ Length: 4
+
+ Result Code: The following values are defined:
+
+ 0 Success
+
+ 1 Failure (AC List message element MUST be present)
+
+6.2.2. Status
+
+ The Status message element is sent by the AC to the WTP in a non-
+ successful Join Response message. This message element is used to
+ indicate the reason for the failure and should only be accompanied
+ with a Result Code message element that indicates a failure.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Status |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 60 for Status
+
+ Length: 1
+
+ Status: The Status field indicates the reason for an LWAPP failure.
+ The following values are supported:
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 44]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 1 - Reserved - do not use
+
+ 2 - Resource Depletion
+
+ 3 - Unknown Source
+
+ 4 - Incorrect Data
+
+6.2.3. Certificate
+
+ The Certificate message element is defined in Section 6.1.6. Note
+ this message element is only included if the WTP and the AC make use
+ of certificate-based security as defined in Section 10.
+
+6.2.4. WTP Manager Data IPv4 Address
+
+ The WTP Manager Data IPv4 Address message element is optionally sent
+ by the AC to the WTP during the join phase. If present, the IP
+ Address contained in this message element is the address the WTP is
+ to use when sending any of its LWAPP data frames.
+
+ Note that this message element is only valid when LWAPP uses the
+ IP/UDP Layer 3 transport.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 138 for WTP Manager Data IPv4 Address
+
+ Length: 4
+
+ IP Address: The IP address of an interface.
+
+6.2.5. WTP Manager Data IPv6 Address
+
+ The WTP Manager Data IPv6 Address message element is optionally sent
+ by the AC to the WTP during the join phase. If present, the IP
+ Address contained in this message element is the address the WTP is
+ to use when sending any of its LWAPP data frames.
+
+ Note that this message element is only valid when LWAPP uses the
+ IP/UDP Layer 3 transport.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 45]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 139 for WTP Manager Data IPv6 Address
+
+ Length: 4
+
+ IP Address: The IP address of an interface.
+
+6.2.6. AC IPv4 List
+
+ The AC List message element is used to configure a WTP with the
+ latest list of ACs in a cluster. This message element MUST be
+ included if the Join Response returns a failure indicating that the
+ AC cannot handle the WTP at this time, allowing the WTP to find an
+ alternate AC to which to connect.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AC IP Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 59 for AC List
+
+ Length: >= 4
+
+ AC IP Address: An array of 32-bit integers containing an AC's IPv4
+ Address.
+
+6.2.7. AC IPv6 List
+
+ The AC List message element is used to configure a WTP with the
+ latest list of ACs in a cluster. This message element MUST be
+ included if the Join Response returns a failure indicating that the
+ AC cannot handle the WTP at this time, allowing the WTP to find an
+ alternate AC to which to connect.
+
+
+
+
+
+Calhoun, et al. Historic [Page 46]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AC IP Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AC IP Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AC IP Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | AC IP Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 141 for AC List
+
+ Length: >= 4
+
+ AC IP Address: An array of 32-bit integers containing an AC's IPv6
+ Address.
+
+6.2.8. ANonce
+
+ The ANonce message element is sent by an AC during the join or rekey
+ phase. The contents of the ANonce are encrypted as described in
+ Section 10 for more information.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 108 for ANonce
+
+ Length: 16
+
+ Nonce: An encrypted, 16-octet random nonce.
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 47]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+6.2.9. PSK-MIC
+
+ The PSK-MIC message element includes a message integrity check, whose
+ purpose is to provide confirmation to the peer that the sender has
+ the proper session key. This message element is only included if the
+ security method used between the WTP and the AC is the pre-shared
+ secret mechanism. See Section 10 for more information.
+
+ When present, the PSK-MIC message element MUST be the last message
+ element in the message. The MIC is computed over the complete LWAPP
+ packet, from the LWAPP control header as defined in Section 4.2.1 to
+ the end of the packet (which MUST be this PSK-MIC message element).
+ The MIC field in this message element and the Sequence Number field
+ in the LWAPP control header MUST be set to zeroes prior to computing
+ the MIC. The length field in the LWAPP control header must already
+ include this message element prior to computing the MIC.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SPI | MIC ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 109 for PSK-MIC
+
+ Length: > 1
+
+ SPI: The Security Parameter Index (SPI) field specifies the
+ cryptographic algorithm used to create the message integrity
+ check. The following values are supported:
+
+ 0 - Unused
+
+ 1 - HMAC-SHA-1 (RFC 2104 [15])
+
+ MIC: A 20-octet Message Integrity Check.
+
+6.3. Join ACK
+
+ The Join ACK message is sent by the WTP upon receiving a Join
+ Response, which has a valid PSK-MIC message element, as a means of
+ providing key confirmation to the AC. The Join ACK is only used in
+ the case where the WTP makes use of the pre-shared key LWAPP mode
+ (see Section 10 for more information).
+
+ Note that the AC should never receive this message unless the
+ security method used between the WTP and the AC is pre-shared-secret-
+ based.
+
+
+
+Calhoun, et al. Historic [Page 48]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.3.1. Session ID
+
+ The Session ID message element is defined in Section 6.1.7.
+
+6.3.2. WNonce
+
+ The WNonce message element is sent by a WTP during the join or rekey
+ phase. The contents of the ANonce are encrypted as described in
+ Section 10 for more information.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Nonce |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 107 for WNonce
+
+ Length: 16
+
+ Nonce: An encrypted, 16-octet random nonce.
+
+6.3.3. PSK-MIC
+
+ The PSK-MIC message element is defined in Section 6.2.9.
+
+6.4. Join Confirm
+
+ The Join Confirm message is sent by the AC upon receiving a Join ACK,
+ which has a valid PSK-MIC message element, as a means of providing
+ key confirmation to the WTP. The Join Confirm is only used in the
+ case where the WTP makes use of the pre-shared key LWAPP mode (see
+ Section 10 for more information).
+
+ If the security method used is pre-shared-key-based, when a WTP
+ receives a Join Confirm, it enters the Joined state and initiates
+ either a Configure Request or Image Data to the AC to which it is now
+
+
+
+
+
+Calhoun, et al. Historic [Page 49]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ joined. Upon entering the Joined state, the WTP begins timing an
+ interval equal to NeighborDeadInterval. Expiration of the timer will
+ result in the transmission of the Echo Request.
+
+ This message is never received, or sent, when the security type used
+ between the WTP and the AC is certificated-based.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.4.1. Session ID
+
+ The Session ID message element is defined in Section 6.1.7.
+
+6.4.2. PSK-MIC
+
+ The PSK-MIC message element is defined in Section 6.2.9.
+
+6.5. Echo Request
+
+ The Echo Request message is a keepalive mechanism for the LWAPP
+ control message.
+
+ Echo Requests are sent periodically by a WTP in the Run state (see
+ Figure 2) to determine the state of the connection between the WTP
+ and the AC. The Echo Request is sent by the WTP when the Heartbeat
+ timer expires, and it MUST start its NeighborDeadInterval timer.
+
+ The Echo Request carries no message elements.
+
+ When an AC receives an Echo Request, it responds with an Echo
+ Response.
+
+6.6. Echo Response
+
+ The Echo Response acknowledges the Echo Request, and is only accepted
+ while in the Run state (see Figure 2).
+
+ Echo Responses are sent by an AC after receiving an Echo Request.
+ After transmitting the Echo Response, the AC should reset its
+ Heartbeat timer to expire in the value configured for EchoInterval.
+ If another Echo request is not received by the AC when the timer
+ expires, the AC SHOULD consider the WTP to no longer be reachable.
+
+ The Echo Response carries no message elements.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 50]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ When a WTP receives an Echo Response it stops the
+ NeighborDeadInterval timer, and starts the Heartbeat timer to
+ EchoInterval.
+
+ If the NeighborDeadInterval timer expires prior to receiving an Echo
+ Response, the WTP enters the Idle state.
+
+6.7. Key Update Request
+
+ The Key Update Request is used by the WTP to initiate the rekeying
+ phase. This message is sent by a WTP when in the Run state and MUST
+ include a new unique Session Identifier. This message MUST also
+ include a unique nonce in the XNonce message element, which is used
+ to protect against replay attacks (see Section 10).
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.7.1. Session ID
+
+ The Session ID message element is defined in Section 6.1.7.
+
+6.7.2. XNonce
+
+ The XNonce message element is defined in Section 6.1.9.
+
+6.8. Key Update Response
+
+ The Key Update Response is sent by the AC in response to the request
+ message, and includes an encrypted ANonce, which is used to derive
+ new session keys. This message MUST include a Session Identifier
+ message element, whose value MUST be identical to the one found in
+ the Key Update Request.
+
+ The AC MUST include a PSK-MIC message element, which provides message
+ integrity over the whole message.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.8.1. Session ID
+
+ The Session ID message element is defined in Section 6.1.7.
+
+6.8.2. ANonce
+
+ The ANonce message element is defined in Section 6.2.8.
+
+
+
+
+Calhoun, et al. Historic [Page 51]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+6.8.3. PSK-MIC
+
+ The PSK-MIC message element is defined in Section 6.2.9.
+
+6.9. Key Update ACK
+
+ The Key Update ACK is sent by the WTP and includes an encrypted
+ version of the WTP's nonce, which is used in the key derivation
+ process. The session keys derived are then used as new LWAPP control
+ message encryption keys (see Section 10).
+
+ The WTP MUST include a PSK-MIC message element, which provides
+ message integrity over the whole message.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.9.1. WNonce
+
+ The WNonce message element is defined in Section 6.3.2.
+
+6.9.2. PSK-MIC
+
+ The PSK-MIC message element is defined in Section 6.2.9.
+
+6.10. Key Update Confirm
+
+ The Key Update Confirm closes the rekeying loop, and allows the WTP
+ to recognize that the AC has received and processed the Key Update
+ messages. At this point, the WTP updates its session key in its
+ crypto engine, and the associated Initialization Vector, ensuring
+ that all future LWAPP control frames are encrypted with the newly
+ derived encryption key.
+
+ The WTP MUST include a PSK-MIC message element, which provides
+ message integrity over the whole message.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.10.1. PSK-MIC
+
+ The PSK-MIC message element is defined in Section 6.2.9.
+
+6.11. Key Update Trigger
+
+ The Key Update Trigger is used by the AC to request that a Key Update
+ Request be initiated by the WTP.
+
+
+
+Calhoun, et al. Historic [Page 52]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Key Update Triggers are sent by an AC in the Run state to inform the
+ WTP to initiate a Key Update Request message.
+
+ When a WTP receives a Key Update Trigger, it generates a Key Update
+ Request.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+6.11.1. Session ID
+
+ The Session ID message element is defined in Section 6.1.7.
+
+7. WTP Configuration Management
+
+ The Wireless Termination Point Configuration messages are used to
+ exchange configuration between the AC and the WTP.
+
+7.1. Configuration Consistency
+
+ The LWAPP protocol provides flexibility in how WTP configuration is
+ managed. To put it simply, a WTP has one of two options:
+
+ 1. The WTP retains no configuration and simply abides by the
+ configuration provided by the AC.
+
+ 2. The WTP retains the configuration of parameters provided by the AC
+ that are non-default values.
+
+ If the WTP opts to save configuration locally, the LWAPP protocol
+ state machine defines the "Configure" state, which is used during the
+ initial binding WTP-AC phase, which allows for configuration
+ exchange. During this period, the WTP sends its current
+ configuration overrides to the AC via the Configure Request message.
+ A configuration override is a parameter that is non-default. One
+ example is that in the LWAPP protocol, the default antenna
+ configuration is an internal-omni antenna. However, a WTP that
+ either has no internal antennas, or has been explicitely configured
+ by the AC to use external antennas would send its antenna
+ configuration during the configure phase, allowing the AC to become
+ aware of the WTP's current configuration.
+
+ Once the WTP has provided its configuration to the AC, the AC sends
+ down its own configuration. This allows the WTP to inherit the
+ configuration and policies on the AC.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 53]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ An LWAPP AC maintains a copy of each active WTP's configuration.
+ There is no need for versioning or other means to identify
+ configuration changes. If a WTP becomes inactive, the AC MAY delete
+ the configuration associated with it. If a WTP were to fail, and
+ connect to a new AC, it would provide its overridden configuration
+ parameters, allowing the new AC to be aware of the WTP's
+ configuration.
+
+ As a consequence, this model allows for resiliency, whereby in light
+ of an AC failure, another AC could provide service to the WTP. In
+ this scenario, the new AC would be automatically updated on any
+ possible WTP configuration changes -- eliminating the need for Inter-
+ AC communication or the need for all ACs to be aware of the
+ configuration of all WTPs in the network.
+
+ Once the LWAPP protocol enters the Run state, the WTPs begin to
+ provide service. However, it is quite common for administrators to
+ require that configuration changes be made while the network is
+ operational. Therefore, the Configuration Update Request is sent by
+ the AC to the WTP in order to make these changes at run-time.
+
+7.2. Configure Request
+
+ The Configure Request message is sent by a WTP to send its current
+ configuration to its AC.
+
+ Configure Requests are sent by a WTP after receiving a Join Response,
+ while in the Configure state.
+
+ The Configure Request carries binding-specific message elements.
+ Refer to the appropriate binding for the definition of this
+ structure.
+
+ When an AC receives a Configure Request, it will act upon the content
+ of the packet and respond to the WTP with a Configure Response.
+
+ The Configure Request includes multiple Administrative State message
+ elements. There is one such message element for the WTP, and then
+ one per radio in the WTP.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+7.2.1. Administrative State
+
+ The Administrative Event message element is used to communicate the
+ state of a particular radio. The value contains the following
+ fields.
+
+
+
+Calhoun, et al. Historic [Page 54]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Admin State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 27 for Administrative State
+
+ Length: 2
+
+ Radio ID: An 8-bit value representing the radio to configure. The
+ Radio ID field may also include the value of 0xff, which is used
+ to identify the WTP itself. Therefore, if an AC wishes to change
+ the administrative state of a WTP, it would include 0xff in the
+ Radio ID field.
+
+ Admin State: An 8-bit value representing the administrative state
+ of the radio. The following values are supported:
+
+ 1 - Enabled
+
+ 2 - Disabled
+
+7.2.2. AC Name
+
+ The AC Name message element is defined in Section 5.2.3.
+
+7.2.3. AC Name with Index
+
+ The AC Name with Index message element is sent by the AC to the WTP
+ to configure preferred ACs. The number of instances where this
+ message element would be present is equal to the number of ACs
+ configured on the WTP.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Index | AC Name...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 90 for AC Name with Index
+
+ Length: 5
+
+ Index: The index of the preferred server (e.g., 1=primary,
+ 2=secondary).
+
+ AC Name: A variable-length ASCII string containing the AC's name.
+
+
+
+Calhoun, et al. Historic [Page 55]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.2.4. WTP Board Data
+
+ The WTP Board Data message element is sent by the WTP to the AC and
+ contains information about the hardware present.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Card ID | Card Revision |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Model |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Model |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Serial Number ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ethernet MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ethernet MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 50 for WTP Board Data
+
+ Length: 26
+
+ Card ID: A hardware identifier.
+
+ Card Revision: 4-byte Revision of the card.
+
+ WTP Model: 8-byte WTP Model Number.
+
+ WTP Serial Number: 24-byte WTP Serial Number.
+
+ Reserved: A 4-byte reserved field that MUST be set to zero (0).
+
+ Ethernet MAC Address: MAC address of the WTP's Ethernet interface.
+
+7.2.5. Statistics Timer
+
+ The Statistics Timer message element value is used by the AC to
+ inform the WTP of the frequency that it expects to receive updated
+ statistics.
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 56]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Statistics Timer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 37 for Statistics Timer
+
+ Length: 2
+
+ Statistics Timer: A 16-bit unsigned integer indicating the time, in
+ seconds.
+
+7.2.6. WTP Static IP Address Information
+
+ The WTP Static IP Address Information message element is used by an
+ AC to configure or clear a previously configured static IP address on
+ a WTP.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Netmask |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Gateway |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Static |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 82 for WTP Static IP Address Information
+
+ Length: 13
+
+ IP Address: The IP address to assign to the WTP.
+
+ Netmask: The IP Netmask.
+
+ Gateway: The IP address of the gateway.
+
+ Netmask: The IP Netmask.
+
+ Static: An 8-bit Boolean stating whether or not the WTP should use
+ a static IP address. A value of zero disables the static IP
+ address, while a value of one enables it.
+
+
+
+
+
+Calhoun, et al. Historic [Page 57]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.2.7. WTP Reboot Statistics
+
+ The WTP Reboot Statistics message element is sent by the WTP to the
+ AC to communicate information about reasons why reboots have
+ occurred.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Crash Count | LWAPP Initiated Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link Failure Count | Failure Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 67 for WTP Reboot Statistics
+
+ Length: 7
+
+ Crash Count: The number of reboots that have occurred due to a WTP
+ crash.
+
+ LWAPP Initiated Count: The number of reboots that have occurred at
+ the request of some LWAPP message, such as a change in
+ configuration that required a reboot or an explicit LWAPP reset
+ request.
+
+ Link Failure Count: The number of times that an LWAPP connection
+ with an AC has failed.
+
+ Failure Type: The last WTP failure. The following values are
+ supported:
+
+ 0 - Link Failure
+
+ 1 - LWAPP Initiated
+
+ 2 - WTP Crash
+
+7.3. Configure Response
+
+ The Configure Response message is sent by an AC and provides an
+ opportunity for the AC to override a WTP's requested configuration.
+
+ Configure Responses are sent by an AC after receiving a Configure
+ Request.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 58]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The Configure Response carries binding-specific message elements.
+ Refer to the appropriate binding for the definition of this
+ structure.
+
+ When a WTP receives a Configure Response, it acts upon the content of
+ the packet, as appropriate. If the Configure Response message
+ includes a Change State Event message element that causes a change in
+ the operational state of one of the Radios, the WTP will transmit a
+ Change State Event to the AC as an acknowledgement of the change in
+ state.
+
+ The following subsections define the message elements that MUST be
+ included in this LWAPP operation.
+
+7.3.1. Decryption Error Report Period
+
+ The Decryption Error Report Period message element value is used by
+ the AC to inform the WTP of how frequently it should send decryption
+ error report messages.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Report Interval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 38 for Decryption Error Report Period
+
+ Length: 3
+
+ Radio ID: The Radio Identifier: typically refers to some interface
+ index on the WTP.
+
+ Report Interval: A 16-bit, unsigned integer indicating the time, in
+ seconds.
+
+7.3.2. Change State Event
+
+ The WTP Radio Information message element is used to communicate the
+ operational state of a radio. The value contains two fields, as
+ shown.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | State | Cause |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Calhoun, et al. Historic [Page 59]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Type: 26 for Change State Event
+
+ Length: 3
+
+ Radio ID: The Radio Identifier: typically refers to some interface
+ index on the WTP.
+
+ State: An 8-bit Boolean value representing the state of the radio.
+ A value of one disables the radio, while a value of two enables
+ it.
+
+ Cause: In the event of a radio being inoperable, the Cause field
+ would contain the reason the radio is out of service. The
+ following values are supported:
+
+ 0 - Normal
+
+ 1 - Radio Failure
+
+ 2 - Software Failure
+
+7.3.3. LWAPP Timers
+
+ The LWAPP Timers message element is used by an AC to configure LWAPP
+ timers on a WTP.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Discovery | Echo Request |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 68 for LWAPP Timers
+
+ Length: 2
+
+ Discovery: The number of seconds between LWAPP Discovery packets
+ when the WTP is in the discovery mode.
+
+ Echo Request: The number of seconds between WTP Echo Request LWAPP
+ messages.
+
+7.3.4. AC IPv4 List
+
+ The AC List message element is defined in Section 6.2.6.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 60]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.3.5. AC IPv6 List
+
+ The AC List message element is defined in Section 6.2.7.
+
+7.3.6. WTP Fallback
+
+ The WTP Fallback message element is sent by the AC to the WTP to
+ enable or disable automatic LWAPP fallback in the event that a WTP
+ detects its preferred AC, and is not currently connected to it.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Mode |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 91 for WTP Fallback
+
+ Length: 1
+
+ Mode: The 8-bit Boolean value indicates the status of automatic
+ LWAPP fallback on the WTP. A value of zero disables the fallback
+ feature, while a value of one enables it. When enabled, if the
+ WTP detects that its primary AC is available, and it is not
+ connected to it, it SHOULD automatically disconnect from its
+ current AC and reconnect to its primary. If disabled, the WTP
+ will only reconnect to its primary through manual intervention
+ (e.g., through the Reset Request command).
+
+7.3.7. Idle Timeout
+
+ The Idle Timeout message element is sent by the AC to the WTP to
+ provide it with the idle timeout that it should enforce on its active
+ mobile station entries.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timeout |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 97 for Idle Timeout
+
+ Length: 4
+
+ Timeout: The current idle timeout to be enforced by the WTP.
+
+
+
+
+
+Calhoun, et al. Historic [Page 61]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.4. Configuration Update Request
+
+ Configure Update Requests are sent by the AC to provision the WTP
+ while in the Run state. This is used to modify the configuration of
+ the WTP while it is operational.
+
+ When an AC receives a Configuration Update Request it will respond
+ with a Configuration Update Response, with the appropriate Result
+ Code.
+
+ The following subsections define the message elements introduced by
+ this LWAPP operation.
+
+7.4.1. WTP Name
+
+ The WTP Name message element is defined in Section 6.1.3.
+
+7.4.2. Change State Event
+
+ The Change State Event message element is defined in Section 7.3.2.
+
+7.4.3. Administrative State
+
+ The Administrative State message element is defined in Section 7.2.1.
+
+7.4.4. Statistics Timer
+
+ The Statistics Timer message element is defined in Section 7.2.5.
+
+7.4.5. Location Data
+
+ The Location Data message element is defined in Section 6.1.4.
+
+7.4.6. Decryption Error Report Period
+
+ The Decryption Error Report Period message element is defined in
+ Section 7.3.1.
+
+7.4.7. AC IPv4 List
+
+ The AC List message element is defined in Section 6.2.6.
+
+7.4.8. AC IPv6 List
+
+ The AC List message element is defined in Section 6.2.7.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 62]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.4.9. Add Blacklist Entry
+
+ The Add Blacklist Entry message element is used by an AC to add a
+ blacklist entry on a WTP, ensuring that the WTP no longer provides
+ any service to the MAC addresses provided in the message. The MAC
+ addresses provided in this message element are not expected to be
+ saved in non-volative memory on the WTP.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 65 for Add Blacklist Entry
+
+ Length: >= 7
+
+ Num of Entries: The number of MAC addresses in the array.
+
+ MAC Address: An array of MAC addresses to add to the blacklist
+ entry.
+
+7.4.10. Delete Blacklist Entry
+
+ The Delete Blacklist Entry message element is used by an AC to delete
+ a previously added blacklist entry on a WTP, ensuring that the WTP
+ provides service to the MAC addresses provided in the message.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 66 for Delete Blacklist Entry
+
+ Length: >= 7
+
+ Num of Entries: The number of MAC addresses in the array.
+
+ MAC Address: An array of MAC addresses to delete from the blacklist
+ entry.
+
+
+
+
+Calhoun, et al. Historic [Page 63]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.4.11. Add Static Blacklist Entry
+
+ The Add Static Blacklist Entry message element is used by an AC to
+ add a permanent Blacklist Entry on a WTP, ensuring that the WTP no
+ longer provides any service to the MAC addresses provided in the
+ message. The MAC addresses provided in this message element are
+ expected to be saved in non-volative memory on the WTP.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 70 for Delete Blacklist Entry
+
+ Length: >= 7
+
+ Num of Entries: The number of MAC addresses in the array.
+
+ MAC Address: An array of MAC addresses to add to the permanent
+ blacklist entry.
+
+7.4.12. Delete Static Blacklist Entry
+
+ The Delete Static Blacklist Entry message element is used by an AC to
+ delete a previously added static blacklist entry on a WTP, ensuring
+ that the WTP provides service to the MAC addresses provided in the
+ message.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 71 for Delete Blacklist Entry
+
+ Length: >= 7
+
+ Num of Entries: The number of MAC addresses in the array.
+
+ MAC Address: An array of MAC addresses to delete from the static
+ blacklist entry.
+
+
+
+Calhoun, et al. Historic [Page 64]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+7.4.13. LWAPP Timers
+
+ The LWAPP Timers message element is defined in Section 7.3.3.
+
+7.4.14. AC Name with Index
+
+ The AC Name with Index message element is defined in Section 7.2.3.
+
+7.4.15. WTP Fallback
+
+ The WTP Fallback message element is defined in Section 7.3.6.
+
+7.4.16. Idle Timeout
+
+ The Idle Timeout message element is defined in Section 7.3.7.
+
+7.5. Configuration Update Response
+
+ The Configuration Update Response is the acknowledgement message for
+ the Configuration Update Request.
+
+ Configuration Update Responses are sent by a WTP after receiving a
+ Configuration Update Request.
+
+ When an AC receives a Configure Update Response, the result code
+ indicates if the WTP successfully accepted the configuration.
+
+ The following subsections define the message elements that must be
+ present in this LWAPP operation.
+
+7.5.1. Result Code
+
+ The Result Code message element is defined in Section 6.2.1.
+
+7.6. Change State Event Request
+
+ The Change State Event is used by the WTP to inform the AC of a
+ change in the operational state.
+
+ The Change State Event message is sent by the WTP when it receives a
+ Configuration Response that includes a Change State Event message
+ element. It is also sent in the event that the WTP detects an
+ operational failure with a radio. The Change State Event may be sent
+ in either the Configure or Run state (see Figure 2).
+
+ When an AC receives a Change State Event it will respond with a
+ Change State Event Response and make any necessary modifications to
+ internal WTP data structures.
+
+
+
+Calhoun, et al. Historic [Page 65]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The following subsections define the message elements that must be
+ present in this LWAPP operation.
+
+7.6.1. Change State Event
+
+ The Change State Event message element is defined in Section 7.3.2.
+
+7.7. Change State Event Response
+
+ The Change State Event Response acknowledges the Change State Event.
+
+ Change State Event Responses are sent by a WTP after receiving a
+ Change State Event.
+
+ The Change State Event Response carries no message elements. Its
+ purpose is to acknowledge the receipt of the Change State Event.
+
+ The WTP does not need to perform any special processing of the Change
+ State Event Response message.
+
+7.8. Clear Config Indication
+
+ The Clear Config Indication is used to reset a WTP's configuration.
+
+ The Clear Config Indication is sent by an AC to request that a WTP
+ reset its configuration to manufacturing defaults. The Clear Config
+ Indication message is sent while in the Run LWAPP state.
+
+ The Reset Request carries no message elements.
+
+ When a WTP receives a Clear Config Indication, it will reset its
+ configuration to manufacturing defaults.
+
+8. Device Management Operations
+
+ This section defines LWAPP operations responsible for debugging,
+ gathering statistics, logging, and firmware management.
+
+8.1. Image Data Request
+
+ The Image Data Request is used to update firmware on the WTP. This
+ message and its companion response are used by the AC to ensure that
+ the image being run on each WTP is appropriate.
+
+ Image Data Requests are exchanged between the WTP and the AC to
+ download a new program image to a WTP.
+
+ When a WTP or AC receives an Image Data Request, it will respond with
+
+
+
+Calhoun, et al. Historic [Page 66]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ an Image Data Response.
+
+ The format of the Image Data and Image Download message elements are
+ described in the following subsections.
+
+8.1.1. Image Download
+
+ The Image Download message element is sent by the WTP to the AC and
+ contains the image filename. The value is a variable-length byte
+ string. The string is NOT zero terminated.
+
+8.1.2. Image Data
+
+ The Image Data message element is present when sent by the AC and
+ contains the following fields.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Opcode | Checksum | Image Data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Image Data ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 33 for Image Data
+
+ Length: >= 5
+
+ Opcode: An 8-bit value representing the transfer opcode. The
+ following values are supported:
+
+ 3 - Image Data is included.
+
+ 5 - An error occurred. Transfer is aborted.
+
+ Checksum: A 16-bit value containing a checksum of the Image Data
+ that follows.
+
+ Image Data: The Image Data field contains 1024 characters, unless
+ the payload being sent is the last one (end of file).
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 67]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+8.2. Image Data Response
+
+ The Image Data Response acknowledges the Image Data Request.
+
+ An Image Data Responses is sent in response to an Image Data Request.
+ Its purpose is to acknowledge the receipt of the Image Data Request
+ packet.
+
+ The Image Data Response carries no message elements.
+
+ No action is necessary on receipt.
+
+8.3. Reset Request
+
+ The Reset Request is used to cause a WTP to reboot.
+
+ Reset Requests are sent by an AC to cause a WTP to reinitialize its
+ operation.
+
+ The Reset Request carries no message elements.
+
+ When a WTP receives a Reset Request it will respond with a Reset
+ Response and then reinitialize itself.
+
+8.4. Reset Response
+
+ The Reset Response acknowledges the Reset Request.
+
+ Reset Responses are sent by a WTP after receiving a Reset Request.
+
+ The Reset Response carries no message elements. Its purpose is to
+ acknowledge the receipt of the Reset Request.
+
+ When an AC receives a Reset Response, it is notified that the WTP
+ will now reinitialize its operation.
+
+8.5. WTP Event Request
+
+ The WTP Event Request is used by a WTP to send information to its AC.
+ These types of events may be periodical, or some asynchronous event
+ on the WTP. For instance, a WTP collects statistics and uses the WTP
+ Event Request to transmit this information to the AC.
+
+ When an AC receives a WTP Event Request, it will respond with a WTP
+ Event Request.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 68]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The WTP Event Request message MUST contain one of the following
+ message element described in the next subsections, or a message
+ element that is defined for a specific technology.
+
+8.5.1. Decryption Error Report
+
+ The Decryption Error Report message element value is used by the WTP
+ to inform the AC of decryption errors that have occurred since the
+ last report.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID |Num Of Entries | Mobile MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Mobile MAC Address[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 39 for Decryption Error Report
+
+ Length: >= 8
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ Num Of Entries: An 8-bit unsigned integer indicating the number of
+ mobile MAC addresses.
+
+ Mobile MAC Address: An array of mobile station MAC addresses that
+ have caused decryption errors.
+
+8.5.2. Duplicate IPv4 Address
+
+ The Duplicate IPv4 Address message element is used by a WTP to inform
+ an AC that it has detected another host using the same IP address it
+ is currently using.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 77 for Duplicate IPv4 Address
+
+
+
+Calhoun, et al. Historic [Page 69]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Length: 10
+
+ IP Address: The IP address currently used by the WTP.
+
+ MAC Address: The MAC address of the offending device.
+
+8.5.3. Duplicate IPv6 Address
+
+ The Duplicate IPv6 Address message element is used by a WTP to inform
+ an AC that it has detected another host using the same IP address it
+ is currently using.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 77 for Duplicate IPv6 Address
+
+ Length: 10
+
+ IP Address: The IP address currently used by the WTP.
+
+ MAC Address: The MAC address of the offending device.
+
+8.6. WTP Event Response
+
+ The WTP Event Response acknowledges the WTP Event Request.
+
+ WTP Event Responses are sent by an AC after receiving a WTP Event
+ Request.
+
+ The WTP Event Response carries no message elements.
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 70]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+8.7. Data Transfer Request
+
+ The Data Transfer Request is used to upload debug information from
+ the WTP to the AC.
+
+ Data Transfer Requests are sent by the WTP to the AC when it
+ determines that it has important information to send to the AC. For
+ instance, if the WTP detects that its previous reboot was caused by a
+ system crash, it would want to send the crash file to the AC. The
+ remote debugger function in the WTP also uses the Data Transfer
+ Request in order to send console output to the AC for debugging
+ purposes.
+
+ When an AC receives a Data Transfer Request, it will respond with a
+ Data Transfer Response. The AC may log the information received as
+ it sees fit.
+
+ The Data Transfer Request message MUST contain ONE of the following
+ message element described in the next subsection.
+
+8.7.1. Data Transfer Mode
+
+ The Data Transfer Mode message element is used by the AC to request
+ information from the WTP for debugging purposes.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Data Type |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 52 for Data Transfer Mode
+
+ Length: 1
+
+ Data Type: An 8-bit value describing the type of information being
+ requested. The following values are supported:
+
+ 1 - WTP Crash Data
+
+ 2 - WTP Memory Dump
+
+8.7.2. Data Transfer Data
+
+ The Data Transfer Data message element is used by the WTP to provide
+ information to the AC for debugging purposes.
+
+
+
+
+
+Calhoun, et al. Historic [Page 71]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data Type | Data Length | Data ....
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 53 for Data Transfer Data
+
+ Length: >= 3
+
+ Data Type: An 8-bit value describing the type of information being
+ sent. The following values are supported:
+
+ 1 - WTP Crash Data
+
+ 2 - WTP Memory Dump
+
+ Data Length: Length of data field.
+
+ Data: Debug information.
+
+8.8. Data Transfer Response
+
+ The Data Transfer Response acknowledges the Data Transfer Request.
+
+ A Data Transfer Response is sent in response to a Data Transfer
+ Request. Its purpose is to acknowledge the receipt of the Data
+ Transfer Request packet.
+
+ The Data Transfer Response carries no message elements.
+
+ Upon receipt of a Data Transfer Response, the WTP transmits more
+ information, if any is available.
+
+9. Mobile Session Management
+
+ Messages in this section are used by the AC to create, modify, or
+ delete mobile station session state on the WTPs.
+
+9.1. Mobile Config Request
+
+ The Mobile Config Request message is used to create, modify, or
+ delete mobile session state on a WTP. The message is sent by the AC
+ to the WTP, and may contain one or more message elements. The
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 72]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ message elements for this LWAPP control message include information
+ that is generally highly technology-specific. Therefore, please
+ refer to the appropriate binding section or document for the
+ definitions of the messages elements that may be used in this control
+ message.
+
+ This section defines the format of the Delete Mobile message element,
+ since it does not contain any technology-specific information.
+
+9.1.1. Delete Mobile
+
+ The Delete Mobile message element is used by the AC to inform a WTP
+ that it should no longer provide service to a particular mobile
+ station. The WTP must terminate service immediately upon receiving
+ this message element.
+
+ The transmission of a Delete Mobile message element could occur for
+ various reasons, including administrative reasons, as a result of the
+ fact that the mobile has roamed to another WTP, etc.
+
+ Once access has been terminated for a given station, any future
+ packets received from the mobile must result in a deauthenticate
+ message, as specified in [6].
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 30 for Delete Mobile
+
+ Length: 7
+
+ Radio ID: An 8-bit value representing the radio
+
+ MAC Address: The mobile station's MAC address
+
+9.2. Mobile Config Response
+
+ The Mobile Configuration Response is used to acknowledge a previously
+ received Mobile Configuration Request, and includes a Result Code
+ message element that indicates whether an error occurred on the WTP.
+
+ This message requires no special processing and is only used to
+ acknowledge the Mobile Configuration Request.
+
+
+
+Calhoun, et al. Historic [Page 73]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The Data Transfer Request message MUST contain the message elements
+ described in the next subsection.
+
+9.2.1. Result Code
+
+ The Result Code message element is defined in Section 6.2.1.
+
+10. LWAPP Security
+
+ Note: This version only defines a certificate and a shared-secret-
+ based mechanism to secure control LWAPP traffic exchanged between the
+ WTP and the AC.
+
+10.1. Securing WTP-AC Communications
+
+ While it is generally straightforward to produce network
+ installations in which the communications medium between the WTP and
+ AC is not accessible to the casual user (e.g., these LAN segments are
+ isolated, and no RJ45 or other access ports exist between the WTP and
+ the AC), this will not always be the case. Furthermore, a determined
+ attacker may resort to various, more sophisticated monitoring and/or
+ access techniques, thereby compromising the integrity of this
+ connection.
+
+ In general, a certain level of threat on the local (wired) LAN is
+ expected and accepted in most computing environments. That is, it is
+ expected that in order to provide users with an acceptable level of
+ service and maintain reasonable productivity levels, a certain amount
+ of risk must be tolerated. It is generally believed that a certain
+ perimeter is maintained around such LANs, that an attacker must have
+ access to the building(s) in which such LANs exist, and that they
+ must be able to "plug in" to the LAN in order to access the network.
+
+ With these things in mind, we can begin to assess the general
+ security requirements for AC-WTP communications. While an in-depth
+ security analysis of threats and risks to these communications is
+ beyond the scope of this document, some discussion of the motivation
+ for various security-related design choices is useful. The
+ assumptions driving the security design thus far include the
+ following:
+
+ o WTP-AC communications take place over a wired connection that may
+ be accessible to a sophisticated attacker.
+
+ o access to this connection is not trivial for an outsider (i.e.,
+ someone who does not "belong" in the building) to access.
+
+
+
+
+
+Calhoun, et al. Historic [Page 74]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o if authentication and/or privacy of end-to-end traffic for which
+ the WTP and AC are intermediaries is required, this may be
+ provided via IPsec [14].
+
+ o privacy and authentication for at least some WTP-AC control
+ traffic is required (e.g., Wired Equivalent Privacy (WEP) keys for
+ user sessions, passed from the AC to the WTP).
+
+ o the AC can be trusted to generate strong cryptographic keys.
+
+ The AC-WTP traffic can be considered to consist of two types: data
+ traffic (e.g., to or from an end user), and control traffic, which is
+ strictly between the AC and WTP. Since data traffic may be secured
+ using IPsec (or some other end-to-end security mechanism), we confine
+ our solution to control traffic. The resulting security consists of
+ two components: an authenticated key exchange and control traffic
+ security encapsulation. The security encapsulation is accomplished
+ using AES-CCM, described in [3]. This encapsulation provides for
+ strong AES-based authentication and encryption [2]. The exchange of
+ cryptographic keys used for CCM is described below.
+
+10.2. LWAPP Frame Encryption
+
+ While the LWAPP protocol uses AES-CCM to encrypt control traffic, it
+ is important to note that not all control frames are encrypted. The
+ LWAPP discovery and join phase are not encrypted. The Discovery
+ messages are sent in the clear since there does not exist a security
+ association between the WTP and the AC during the discovery phase.
+ The join phase is an authenticated exchange used to negotiate
+ symmetric session keys (see Section 10.3).
+
+ Once the join phase has been successfully completed, the LWAPP state
+ machine Figure 2 will move to the Configure state, at which time all
+ LWAPP control frames are encrypted using AES-CCM.
+
+ Encryption of a control message begins at the Message Element field:
+ meaning the Msg Type, Seq Num, Msg Element Length, and Session ID
+ fields are left intact (see Section 4.2.1).
+
+ The AES-CCM 12-byte authentication data is appended to the end of the
+ message. The authentication data is calculated from the start of the
+ LWAPP packet and includes the complete LWAPP control header (see
+ Section 4.2.1).
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 75]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The AES-CCM block cipher protocol requires an initialization vector.
+ The LWAPP protocol requires that the WTP and the AC maintain two
+ separate IVs, one for transmission and one for reception. The IV
+ derived during the key exchange phase by both the WTP and the AC is
+ used as the base for all encrypted packets with a new key.
+
+10.3. Authenticated Key Exchange
+
+ This section describes the key management component of the LWAPP
+ protocol. There are two modes supported by LWAPP: certificate and
+ pre-shared key.
+
+10.3.1. Terminology
+
+ This section details the key management protocol that makes use of
+ pre-shared secrets.
+
+ The following notations are used throughout this section:
+
+ o PSK - the pre-shared key shared between the WTP and the AC.
+
+ o Kpriv - the private key of a public-private key pair.
+
+ o Kpub - the public key of the pair.
+
+ o SessionID - a randomly generated LWAPP session identifier,
+ provided by the WTP in the Join Request.
+
+ o E-x{Kpub, M} - RSA encryption of M using X's public key.
+
+ o D-x{Kpriv, C} - RSA decryption of C using X's private key.
+
+ o AES-CMAC(key, packet) - A message integrity check, using AES-CMAC
+ and key, of the complete LWAPP packet, with the Sequence Number
+ field and the payload of the PSK-MIC message element set to zero.
+
+ o AES-E(key, plaintext) - Plaintext is encrypted with key, using
+ AES.
+
+ o AES-D(key, ciphertext) - ciphertext is decrypted with key, using
+ AES.
+
+ o Certificate-AC - AC's Certificate.
+
+ o Certificate-WTP - WTP's Certificate.
+
+ o WTP-MAC - The WTP's MAC address.
+
+
+
+
+Calhoun, et al. Historic [Page 76]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o AC-MAC - The AC's MAC address.
+
+ o RK0 - the root key, which is created through a Key Derivation
+ Function (KDF) function.
+
+ o RK0E - the root Encryption key, derived from RK0.
+
+ o RK0M - the root MIC key, derived from RK0.
+
+ o SK1 - the session key.
+
+ o SK1C - the session confirmation key, derived from SK.
+
+ o SK1E - the session encryption key, derived from SK.
+
+ o SK1W - the session keywrap key, derived from SK (see RFC 3394
+ [9]).
+
+ o WNonce - The WTP's randomly generated nonce.
+
+ o ANonce - The AC's randomly generated nonce.
+
+ o EWNonce - The payload of the WNonce message element, which
+ includes the WNonce.
+
+ o EANonce - The payload of the ANonce message element, which
+ includes the ANonce.
+
+10.3.2. Initial Key Generation
+
+ The AC and WTP accomplish mutual authentication and a cryptographic
+ key exchange in a dual round trip using the Join Request, Join
+ Response, Join ACK, and Join Confirm (see Section 6.1).
+
+ The following text describes the exchange between the WTP and the AC
+ that creates a session key, which is used to secure LWAPP control
+ messages.
+
+ o The WTP creates a Join Request using the following process:
+
+ o If certificate-based security is used, the WTP adds the
+ Certificate message element (see Section 6.1.6) with its
+ contents set to Certificate-WTP.
+
+ o The WTP adds the Session ID message element (see Section 6.1.7)
+ with the contents set to a randomly generated session
+ identifier (see RFC 1750 [4]). The WTP MUST save the Session
+ ID in order to validate the Join Response.
+
+
+
+Calhoun, et al. Historic [Page 77]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o The WTP creates a random nonce, included in the XNonce message
+ element (see Section 6.1.9). The WTP MUST save the XNonce to
+ validate the Join Response.
+
+ o The WTP transmits the Join Request to the AC.
+
+ o Upon receiving the Join Request, the AC uses the following
+ process:
+
+ o The AC creates the Join Response, and ensures that the Session
+ ID message element matches the value found in the Join Request.
+
+ o If certificate-based security is used, the AC:
+
+ o adds the Certificate-AC to the Certificate message element.
+
+ o creates a random 'AC Nonce' and encrypts it using the
+ following algorithm E-wtp(Kpub, XNonce XOR 'AC Nonce'). The
+ encrypted contents are added to the ANonce's message element
+ payload.
+
+ o If a pre-shared-key-based security is used, the AC:
+
+ o creates RK0 through the following algorithm: RK0 = KDF-
+ 256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || AC-
+ MAC}, where WTP-MAC is the WTP's MAC address in the form
+ "xx:xx:xx:xx:xx:xx". Similarly, the AC-MAC is an ASCII
+ encoding of the AC's MAC address, of the form "xx:xx:xx:xx:
+ xx:xx". The resulting K0 is split into the following:
+
+ o The first 16 octets are known as RK0E, and are used as an
+ encryption key.
+
+ o The second 16 octets are known as RK0M, and are used for
+ MIC'ing purposes.
+
+ o The AC creates a random 'AC Nonce' and encrypts it using the
+ following algorithm: AES-E(RK0E, XNonce XOR 'AC Nonce').
+ The encrypted contents are added to the ANonce's message
+ element payload.
+
+ o The AC adds a MIC to the contents of the Join Response using
+ AES-CMAC(RK0M, Join Response) and adds the resulting hash to
+ the PSK-MIC (Section 6.2.9) message element.
+
+ o Upon receiving the Join Response, the WTP uses the following
+ process:
+
+
+
+
+Calhoun, et al. Historic [Page 78]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o If a pre-shared key is used, the WTP authenticates the Join
+ Response's PSK-MIC message element. If authentication fails,
+ the packet is dropped.
+
+ o The WTP decrypts the ANonce message element and XOR's the value
+ with XNonce to retrieve the 'AC Nonce'. The ANonce payload is
+ referred to as ciphertext below:
+
+ o If a pre-shared key is used, use AES-D(RK0E, ciphertext).
+ The 'AC Nonce' is then recovered using XNonce XOR plaintext.
+
+ o If certificates are used, use d-wtp(Kpriv, ciphertext). The
+ 'AC Nonce' is then recovered using XNonce XOR plaintext.
+
+ o The WTP creates a random 'WTP Nonce'.
+
+ o The WTP uses the KDF function to create a 64-octet session key
+ (SK). The KDF function used is as follows: KDF-512{'WTP Nonce'
+ || 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC-MAC}. The
+ KDF function is defined in [7].
+
+ o SK is then broken down into three separate session keys with
+ different purposes:
+
+ o The first 16 octets are known as SK1C, and are used as a
+ confirmation key.
+
+ o The second 16 octets are known as SK1E, and are as the
+ encryption key.
+
+ o The third 16 octets are known as SK1D, and are used as the
+ keywrap key.
+
+ o The fourth 16 octets are known as IV, and are used as the
+ Initialization Vector during encryption.
+
+ o The WTP creates the Join ACK message.
+
+ o If certificate-based security is used, the AC:
+
+ o encrypts the 'WTP Nonce' using the following algorithm: E-
+ ac(Kpub, 'WTP Nonce'). The encrypted contents are added to
+ the WNonce's message element payload.
+
+ o If a pre-shared-key-based security is used, the AC:
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 79]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o encrypts the 'WTP Nonce' using the following algorithm:
+ AES-E(RK0E, 'WTP Nonce'). The encrypted contents are added
+ to the WNonce's message element payload.
+
+ o The WTP adds a MIC to the contents of the Join ACK using
+ AES-CMAC(SK1M, Join ACK) and adds the resulting hash to the
+ PSK-MIC (Section 6.2.9) message element.
+
+ o The WTP then transmits the Join ACK to the AC.
+
+ o Upon receiving the Join ACK, the AC uses the following process:
+
+ o The AC authenticates the Join ACK through the PSK-MIC message
+ element. If authentic, the AC decrypts the WNonce message
+ element to retrieve the 'WTP Nonce'. If the Join ACK cannot be
+ authenticated, the packet is dropped.
+
+ o The AC decrypts the WNonce message element to retrieve the 'WTP
+ Nonce'. The WNonce payload is referred to as ciphertext below:
+
+ o If a pre-shared key is used, use AES-D(RK0E, ciphertext).
+ The plaintext is then considered the 'WTP Nonce'.
+
+ o If certificates are used, use d-ac(Kpriv, ciphertext). The
+ plaintext is then considered the 'WTP Nonce'.
+
+ o The AC then uses the KDF function to create a 64-octet session
+ key (SK). The KDF function used is as follows: KDF-512{'WTP
+ Nonce' || 'AC Nonce', "LWAPP Key Generation", WTP-MAC ||
+ AC-MAC}. The KDF function is defined in [7]. The SK is split
+ into SK1C, SK1E, SK1D, and IV, as previously noted.
+
+ o The AC creates the Join Confirm.
+
+ o The AC adds a MIC to the contents of the Join Confirm using
+ AES-CMAC(SK1M, Join Confirm) and adds the resulting hash to the
+ MIC (Section 6.2.9) message element.
+
+ o The AC then transmits the Join Confirm to the WTP.
+
+ o Upon receiving the Join Confirm, the WTP uses the following
+ process:
+
+ o The WTP authenticates the Join Confirm through the PSK-MIC
+ message element. If the Join Confirm cannot be authenticated,
+ the packet is dropped.
+
+
+
+
+
+Calhoun, et al. Historic [Page 80]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o SK1E is now plumbed into the AC and WTP's crypto engine as the
+ AES-CCM LWAPP control encryption session key. Furthermore, the
+ random IV is used as the base Initialization Vector. From this
+ point on, all control protocol payloads between the WTP and AC are
+ encrypted and authenticated using the new session key.
+
+10.3.3. Refreshing Cryptographic Keys
+
+ Since AC-WTP associations will tend to be relatively long-lived, it
+ is sensible to periodically refresh the encryption and authentication
+ keys; this is referred to as "rekeying". When the key lifetime
+ reaches 95% of the configured value, identified in the KeyLifetime
+ timer (see Section 12), the rekeying will proceed as follows:
+
+ o The WTP creates RK0 through the previously defined KDF algorithm:
+ RK0 = KDF-256{SK1D, "LWAPP PSK Top K0" || Session ID || WTP-MAC ||
+ AC-MAC}. Note that the difference in this specific instance is
+ that SK1D that was previously generated is used instead of the
+ PSK. Note this is used in both the certificate and pre-shared key
+ modes. The resulting RK0 creates RK0E, RK0M.
+
+ o The remaining steps used are identical to the join process, with
+ the exception that the rekey messages are used instead of join
+ messages, and the fact that the messages are encrypted using the
+ previously created SK1E. This means the Join Request is replaced
+ with the Rekey Request, the Join Response is replaced with the
+ Rekey Response, etc. The two differences between the rekey and
+ the join process are:
+
+ o The Certificate-WTP and Certificate-AC are not included in the
+ Rekey-Request and Rekey-Response, respectively.
+
+ o Regardless of whether certificates or pre-shared keys were used
+ in the initial key derivation, the process now uses the pre-
+ shared key mode only, using SK1D as the "PSK".
+
+ o The Key Update Request is sent to the AC.
+
+ o The newly created SK1E is now plumbed into the AC and WTP's crypto
+ engine as the AES-CCM LWAPP control encryption session key.
+ Furthermore, the new random IV is used as the base Initialization
+ Vector. From this point on, all control protocol payloads between
+ the WTP and AC are encrypted and authenticated using the new
+ session key.
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 81]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ If either the WTP or the AC do not receive an expected response by
+ the time the ResponseTimeout timer expires (see Section 12), the
+ WTP MUST delete the new and old session information, and reset the
+ state machine to the Idle state.
+
+ Following a rekey process, both the WTP and the AC keep the
+ previous encryption for 5-10 seconds in order to be able to
+ process packets that arrive out of order.
+
+10.4. Certificate Usage
+
+ Validation of the certificates 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
+ 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
+ distinguishable from the certificate used by the WTP. To accomplish
+ this differentiation, the x.509v3 certificates MUST include the
+ Extensions field [10] and MUST include the NetscapeComment [11]
+ extension.
+
+ For an AC, the value of the NetscapeComment extension MUST be the
+ string "CAPWAP AC Device Certificate". For a WTP, the value of the
+ NetscapeComment extension MUST be the string "CAPWAP WTP Device
+ Certificate".
+
+ Part of the LWAPP certificate validation process includes ensuring
+ that the proper string is included in the NetscapeComment extension,
+ and only allowing the LWAPP session to be established if the
+ extension does not represent the same role as the device validating
+ the certificate. For instance, a WTP MUST NOT accept a certificate
+ whose NetscapeComment field is set to "CAPWAP WTP Device
+ Certificate".
+
+11. IEEE 802.11 Binding
+
+ This section defines the extensions required for the LWAPP protocol
+ to be used with the IEEE 802.11 protocol.
+
+11.1. Division of Labor
+
+ The LWAPP protocol, when used with IEEE 802.11 devices, requires a
+ specific behavior from the WTP and the AC, specifically in terms of
+ which 802.11 protocol functions are handled.
+
+ For both the Split and Local MAC approaches, the CAPWAP functions, as
+ defined in the taxonomy specification, reside in the AC.
+
+
+
+
+
+Calhoun, et al. Historic [Page 82]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+11.1.1. Split MAC
+
+ This section shows the division of labor between the WTP and the AC
+ in a Split MAC architecture. Figure 3 shows the clear separation of
+ functionality among LWAPP components.
+
+ Function Location
+ Distribution Service AC
+ Integration Service AC
+ Beacon Generation WTP
+ Probe Response WTP
+ Power Mgmt/Packet Buffering WTP
+ Fragmentation/Defragmentation WTP
+ Assoc/Disassoc/Reassoc AC
+
+ 802.11e
+ Classifying AC
+ Scheduling WTP/AC
+ Queuing WTP
+
+ 802.11i
+ 802.1X/EAP AC
+ Key Management AC
+ 802.11 Encryption/Decryption WTP or AC
+
+ Figure 3: Mapping of 802.11 Functions for Split MAC Architecture
+
+ The Distribution and Integration services reside on the AC, and
+ therefore all user data is tunneled between the WTP and the AC. As
+ noted above, all real-time 802.11 services, including the control
+ protocol and the beacon and Probe Response frames, are handled on the
+ WTP.
+
+ All remaining 802.11 MAC management frames are supported on the AC,
+ including the Association Request, which allows the AC to be involved
+ in the access policy enforcement portion of the 802.11 protocol. The
+ 802.1X and 802.11i key management function are also located on the
+ AC.
+
+ While the admission control component of 802.11e resides on the AC,
+ the real-time scheduling and queuing functions are on the WTP. Note
+ that this does not exclude the AC from providing additional policing
+ and scheduling functionality.
+
+ Note that in the following figure, the use of '( - )' indicates that
+ processing of the frames is done on the WTP.
+
+
+
+
+
+Calhoun, et al. Historic [Page 83]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Client WTP AC
+
+ Beacon
+ <-----------------------------
+ Probe Request
+ ----------------------------( - )------------------------->
+ Probe Response
+ <-----------------------------
+ 802.11 AUTH/Association
+ <--------------------------------------------------------->
+ Add Mobile (Clear Text, 802.1X Only)
+ <------------------------->
+ 802.1X Authentication & 802.11i Key Exchange
+ <--------------------------------------------------------->
+ Add Mobile (AES-CCMP, PTK=x)
+ <------------------------->
+ 802.11 Action Frames
+ <--------------------------------------------------------->
+ 802.11 DATA (1)
+ <---------------------------( - )------------------------->
+
+ Figure 4: Split MAC Message Flow
+
+ Figure 4 provides an illustration of the division of labor in a Split
+ MAC architecture. In this example, a WLAN has been created that is
+ configured for 802.11i, using AES-CCMP for privacy. The following
+ process occurs:
+
+ o The WTP generates the 802.11 beacon frames, using information
+ provided to it through the Add WLAN (see Section 11.8.1.1) message
+ element.
+
+ o The WTP processes the Probe Request and responds with a
+ corresponding Probe Response. The problem request is then
+ forwarded to the AC for optional processing.
+
+ o The WTP forwards the 802.11 Authentication and Association frames
+ to the AC, which is responsible for responding to the client.
+
+ o Once the association is complete, the AC transmits an LWAPP Add
+ Mobile Request to the WTP (see Section 11.7.1.1). In the above
+ example, the WLAN is configured for 802.1X, and therefore the
+ '802.1X only' policy bit is enabled.
+
+ o If the WTP is providing encryption/decryption services, once the
+ client has completed the 802.11i key exchange, the AC transmits
+ another Add Mobile Request to the WTP, stating the security policy
+ to enforce for the client (in this case AES-CCMP), as well as the
+
+
+
+Calhoun, et al. Historic [Page 84]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ encryption key to use. If encryption/decryption is handled in the
+ AC, the Add Mobile Request would have the encryption policy set to
+ "Clear Text".
+
+ o The WTP forwards any 802.11 Action frames received to the AC.
+
+ o All client data frames are tunneled between the WTP and the AC.
+ Note that the WTP is responsible for encrypting and decrypting
+ frames, if it was indicated in the Add Mobile Request.
+
+11.1.2. Local MAC
+
+ This section shows the division of labor between the WTP and the AC
+ in a Local MAC architecture. Figure 5 shows the clear separation of
+ functionality among LWAPP components.
+
+ Function Location
+ Distribution Service WTP
+ Integration Service WTP
+ Beacon Generation WTP
+ Probe Response WTP
+ Power Mgmt/Packet Buffering WTP
+ Fragmentation/Defragmentation WTP
+ Assoc/Disassoc/Reassoc WTP
+
+ 802.11e
+ Classifying WTP
+ Scheduling WTP
+ Queuing WTP
+
+ 802.11i
+ 802.1X/EAP AC
+ Key Management AC
+ 802.11 Encryption/Decryption WTP
+
+ Figure 5: Mapping of 802.11 Functions for Local AP Architecture
+
+ Given that Distribution and Integration Services exist on the WTP,
+ client data frames are not forwarded to the AC, with the exception
+ listed in the following paragraphs.
+
+ While the MAC is terminated on the WTP, it is necessary for the AC to
+ be aware of mobility events within the WTPs. As a consequence, the
+ WTP MUST forward the 802.11 Association Requests to the AC, and the
+ AC MAY reply with a failed Association Response if it deems it
+ necessary.
+
+
+
+
+
+Calhoun, et al. Historic [Page 85]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The 802.1X and 802.11i Key Management function resides in the AC.
+ Therefore, the WTP MUST forward all 802.1X/Key Management frames to
+ the AC and forward the associated responses to the station.
+
+ Note that in the following figure, the use of '( - )' indicates that
+ processing of the frames is done on the WTP.
+
+
+ Client WTP AC
+
+ Beacon
+ <-----------------------------
+ Probe
+ <---------------------------->
+ 802.11 AUTH
+ <-----------------------------
+ 802.11 Association
+ <---------------------------( - )------------------------->
+ Add Mobile (Clear Text, 802.1X Only)
+ <------------------------->
+ 802.1X Authentication & 802.11i Key Exchange
+ <--------------------------------------------------------->
+ 802.11 Action Frames
+ <--------------------------------------------------------->
+ Add Mobile (AES-CCMP, PTK=x)
+ <------------------------->
+ 802.11 DATA
+ <----------------------------->
+
+ Figure 6: Local MAC Message Flow
+
+ Figure 6 provides an illustration of the division of labor in a Local
+ MAC architecture. In this example, a WLAN has been created that is
+ configured for 802.11i, using AES-CCMP for privacy. The following
+ process occurs:
+
+ o The WTP generates the 802.11 beacon frames, using information
+ provided to it through the Add WLAN (see Section 11.8.1.1) message
+ element.
+
+ o The WTP processes the Probe Request and responds with a
+ corresponding Probe Response.
+
+ o The WTP forwards the 802.11 Authentication and Association frames
+ to the AC, which is responsible for responding to the client.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 86]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ o Once the association is complete, the AC transmits an LWAPP Add
+ Mobile Request to the WTP (see Section 11.7.1.1. In the above
+ example, the WLAN is configured for 802.1X, and therefore the
+ '802.1X only' policy bit is enabled.
+
+ o The WTP forwards all 802.1X and 802.11i key exchange messages to
+ the AC for processing.
+
+ o The AC transmits another Add Mobile Request to the WTP, stating
+ the security policy to enforce for the client (in this case, AES-
+ CCMP), as well as the encryption key to use. The Add Mobile
+ Request MAY include a VLAN name, which when present is used by the
+ WTP to identify the VLAN on which the user's data frames are to be
+ bridged.
+
+ o The WTP forwards any 802.11 Action frames received to the AC.
+
+ o The WTP locally bridges all client data frames, and provides the
+ necessary encryption and decryption services.
+
+11.2. Roaming Behavior and 802.11 Security
+
+ It is important that LWAPP implementations react properly to mobile
+ devices associating to the networks in how they generate Add Mobile
+ and Delete Mobile messages. This section expands upon the examples
+ provided in the previous section, and describes how the LWAPP control
+ protocol is used in order to provide secure roaming.
+
+ Once a client has successfully associated with the network in a
+ secure fashion, it is likely to attempt to roam to another access
+ point. Figure 7 shows an example of a currently associated station
+ moving from its "Old WTP" to a new "WTP". The figure is useful for
+ multiple different security policies, including standard 802.1X and
+ dynamic WEP keys, WPA or even WPA2 both with key caching (where the
+ 802.1x exchange would be bypassed) and without.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 87]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Client Old WTP WTP AC
+
+ Association Request/Response
+ <--------------------------------------( - )-------------->
+ Add Mobile (Clear Text, 802.1X Only)
+ <---------------->
+ 802.1X Authentication (if no key cache entry exists)
+ <--------------------------------------( - )-------------->
+ 802.11i 4-way Key Exchange
+ <--------------------------------------( - )-------------->
+ Delete Mobile
+ <---------------------------------->
+ Add Mobile (AES-CCMP, PTK=x)
+ <---------------->
+
+ Figure 7: Client Roaming Example
+
+11.3. Transport-Specific Bindings
+
+ All LWAPP transports have the following IEEE 802.11 specific
+ bindings:
+
+11.3.1. Status and WLANS Field
+
+ The interpretation of this 16-bit field depends on the direction of
+ transmission of the packet. Refer to the figure in Section 3.1.
+
+ Status
+
+ When an LWAPP packet is transmitted from a WTP to an AC, this field
+ is called the Status field and indicates radio resource information
+ associated with the frame. When the message is an LWAPP control
+ message this field is transmitted as zero.
+
+ The Status field is divided into the signal strength and signal-to-
+ noise ratio with which an IEEE 802.11 frame was received, encoded in
+ the following manner:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RSSI | SNR |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ RSSI: RSSI is a signed, 8-bit value. It is the received signal
+ strength indication, in dBm.
+
+
+
+
+
+Calhoun, et al. Historic [Page 88]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ SNR: SNR is a signed, 8-bit value. It is the signal-to-noise ratio
+ of the received IEEE 802.11 frame, in dB.
+
+ WLANs field: When an LWAPP data message is transmitted from an AC
+ to a WTP, this 16-bit field indicates on which WLANs the
+ encapsulated IEEE 802.11 frame is to be transmitted. For unicast
+ packets, this field is not used by the WTP. For broadcast or
+ multicast packets, the WTP might require this information if it
+ provides encryption services.
+
+ Given that a single broadcast or multicast packet might need to be
+ sent to multiple wireless LANs (presumably each with a different
+ broadcast key), this field is defined as a bit field. A bit set
+ indicates a WLAN ID (see Section 11.8.1.1), which will be sent the
+ data. The WLANS field is encoded in the following manner:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WLAN ID(s) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+11.4. BSSID to WLAN ID Mapping
+
+ The LWAPP protocol makes assumptions regarding the BSSIDs used on the
+ WTP. It is a requirement for the WTP to use a contiguous block of
+ BSSIDs. The WLAN Identifier field, which is managed by the AC, is
+ used as an offset into the BSSID list.
+
+ For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00,
+ and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see
+ Section 11.8.1.1), the BSSID for the specific WLAN on the WTP would
+ be 00:01:02:00:00:02.
+
+ The WTP communicates the maximum number of BSSIDs that it supports
+ during the Config Request within the IEEE 802.11 WTP WLAN Radio
+ Configuration message element (see Section 11.9.1).
+
+11.5. Quality of Service
+
+ It is recommended that 802.11 MAC management be sent by both the AC
+ and the WTP with appropriate Quality-of-Service (QoS) values,
+ ensuring that congestion in the network minimizes occurrences of
+ packet loss. Therefore, a QoS-enabled LWAPP device should use:
+
+ 802.1P: The precedence value of 6 SHOULD be used for all 802.11 MAC
+ management messages, except for Probe Requests, which SHOULD use
+ 4.
+
+
+
+Calhoun, et al. Historic [Page 89]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ DSCP: The DSCP tag value of 46 SHOULD be used for all 802.11 MAC
+ management messages, except for Probe Requests, which SHOULD use
+ 34.
+
+11.6. Data Message Bindings
+
+ There are no LWAPP data message bindings for IEEE 802.11.
+
+11.7. Control Message Bindings
+
+ The IEEE 802.11 binding has the following control message
+ definitions.
+
+11.7.1. Mobile Config Request
+
+ This section contains the 802.11-specific message elements that are
+ used with the Mobile Config Request.
+
+11.7.1.1. Add Mobile
+
+ The Add Mobile Request is used by the AC to inform a WTP that it
+ should forward traffic from a particular mobile station. The Add
+ Mobile Request may also include security parameters that must be
+ enforced by the WTP for the particular mobile.
+
+ When the AC sends an Add Mobile Request, it includes any security
+ parameters that may be required. An AC that wishes to update a
+ mobile's policy on a WTP may do so by simply sending a new Add Mobile
+ message element.
+
+ When a WTP receives an Add Mobile message element, it must first
+ override any existing state it may have for the mobile station in
+ question. The latest Add Mobile overrides any previously received
+ messages. If the Add Mobile message element's EAP-Only bit is set,
+ the WTP MUST drop all 802.11 packets that do not contain EAP packets.
+ Note that when EAP Only is set, the Encryption Policy field MAY have
+ additional values, and therefore it is possible to inform a WTP to
+ only accept encrypted EAP packets. Once the mobile station has
+ successfully completed EAP authentication, the AC must send a new Add
+ Mobile message element to push the session key down to the WTP as
+ well as to remove the EAP Only restriction.
+
+ If the QoS field is set, the WTP MUST observe and provide policing of
+ the 802.11e priority tag to ensure that it does not exceed the value
+ provided by the AC.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 90]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Association ID | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |E|C| Encryption Policy |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Encrypt Policy | Session Key... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pairwise TSC... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pairwise RSC... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Capabilities | WLAN ID | WME Mode |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 802.11e Mode | Qos | Supported Rates |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Supported Rates |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VLAN Name...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 29 for Add Mobile
+
+ Length: 36
+
+ Radio ID: An 8-bit value representing the radio.
+
+ Association ID: A 16-bit value specifying the 802.11 Association
+ Identifier.
+
+ MAC Address: The mobile station's MAC address.
+
+ E: The 1-bit field is set by the AC to inform the WTP that it MUST
+ NOT accept any 802.11 data frames, other than 802.1X frames. This
+ is the equivalent of the WTP's 802.1X port for the mobile station
+ to be in the closed state. When set, the WTP MUST drop any
+ non-802.1X packets it receives from the mobile station.
+
+ C: The 1-bit field is set by the AC to inform the WTP that
+ encryption services will be provided by the AC. When set, the WTP
+ SHOULD police frames received from stations to ensure that they
+ comply to the stated encryption policy, but does not need to take
+ specific cryptographic action on the frame. Similarly, for
+ transmitted frames, the WTP only needs to forward already
+ encrypted frames.
+
+
+
+Calhoun, et al. Historic [Page 91]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Encryption Policy: The policy field informs the WTP how to handle
+ packets from/to the mobile station. The following values are
+ supported:
+
+ 0 - Encrypt WEP 104: All packets to/from the mobile station must
+ be encrypted using a standard 104-bit WEP.
+
+ 1 - Clear Text: All packets to/from the mobile station do not
+ require any additional crypto processing by the WTP.
+
+ 2 - Encrypt WEP 40: All packets to/from the mobile station must
+ be encrypted using a standard 40-bit WEP.
+
+ 3 - Encrypt WEP 128: All packets to/from the mobile station must
+ be encrypted using a standard 128-bit WEP.
+
+ 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
+ must be encrypted using a 128-bit AES-CCMP [7].
+
+ 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
+ be encrypted using Temporal Key Integrity Protocol (TKIP) and
+ authenticated using Michael [16].
+
+ Session Key: A 32-octet session key the WTP is to use when
+ encrypting traffic to or decrypting traffic from the mobile
+ station. The type of key is determined based on the Encryption
+ Policy field.
+
+ Pairwise TSC: The TKIP Sequence Counter (TSC) to use for unicast
+ packets transmitted to the mobile.
+
+ Pairwise RSC: The Receive Sequence Counter (RSC) to use for unicast
+ packets received from the mobile.
+
+ Capabilities: A 16-bit field containing the 802.11 capabilities to
+ use with the mobile.
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier.
+
+ WME Mode: An 8-bit Boolean used to identify whether the station is
+ WME capable. A value of zero is used to indicate that the station
+ is not Wireless Multimedia Extension (WME) capable, while a value
+ of one means that the station is WME capable.
+
+ 802.11e Mode: An 8-bit Boolean used to identify whether the station
+ is 802.11e-capable. A value of zero is used to indicate that the
+ station is not 802.11e-capable, while a value of one means that
+ the station is 802.11e-capable.
+
+
+
+Calhoun, et al. Historic [Page 92]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ QoS: An 8-bit value specifying the QoS policy to enforce for the
+ station. The following values are supported: PRC: TO CHECK
+
+ 0 - Silver (Best Effort)
+
+ 1 - Gold (Video)
+
+ 2 - Platinum (Voice)
+
+ 3 - Bronze (Background)
+
+ Supported Rates: The supported rates to be used with the mobile
+ station.
+
+ VLAN Name: An optional variable string containing the VLAN Name on
+ which the WTP is to locally bridge user data. Note that this
+ field is only valid with Local MAC WTPs.
+
+11.7.1.2. IEEE 802.11 Mobile Session Key
+
+ The Mobile Session Key Payload message element is sent when the AC
+ determines that encryption of a mobile station must be performed in
+ the WTP. This message element MUST NOT be present without the Add
+ Mobile message element, and MUST NOT be sent if the WTP had not
+ specifically advertised support for the requested encryption scheme
+ (see Section 11.7.1.1).
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address | Encryption Policy |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Encryption Policy | Session Key... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 105 for IEEE 802.11 Mobile Session Key
+
+ Length: >= 11
+
+ MAC Address: The mobile station's MAC address.
+
+ Encryption Policy: The policy field informs the WTP how to handle
+ packets from/to the mobile station. The following values are
+ supported:
+
+
+
+
+
+Calhoun, et al. Historic [Page 93]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 0 - Encrypt WEP 104: All packets to/from the mobile station must
+ be encrypted using a standard 104-bit WEP.
+
+ 1 - Clear Text: All packets to/from the mobile station do not
+ require any additional crypto processing by the WTP.
+
+ 2 - Encrypt WEP 40: All packets to/from the mobile station must
+ be encrypted using a standard 40-bit WEP.
+
+ 3 - Encrypt WEP 128: All packets to/from the mobile station must
+ be encrypted using a standard 128-bit WEP.
+
+ 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
+ must be encrypted using a 128-bit AES-CCMP [7].
+
+ 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
+ be encrypted using TKIP and authenticated using Michael [16].
+
+ Session Key: The session key the WTP is to use when encrypting
+ traffic to/from the mobile station.
+
+11.7.1.3. Station QoS Profile
+
+ The Station QoS Profile Payload message element contains the maximum
+ 802.11e priority tag that may be used by the station. Any packets
+ received that exceed the value encoded in this message element must
+ either be dropped or tagged using the maximum value permitted to the
+ user. The priority tag must be between zero (0) and seven (7).
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address | 802.1P Precedence Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 140 for IEEE 802.11 Station QoS Profile
+
+ Length: 12
+
+ MAC Address: The mobile station's MAC address.
+
+ 802.1P Precedence Tag: The maximum 802.1P precedence value that the
+ WTP will allow in the Traffic Identifier (TID) field in the
+ extended 802.11e QoS Data header.
+
+
+
+
+
+Calhoun, et al. Historic [Page 94]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+11.7.1.4. IEEE 802.11 Update Mobile QoS
+
+ The Update Mobile QoS message element is used to change the Quality-
+ of-Service policy on the WTP for a given mobile station.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Association ID | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address | QoS Profile | Vlan Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DSCP Tag | 802.1P Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 106 for IEEE 802.11 Update Mobile QoS
+
+ Length: 14
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ Association ID: The 802.11 Association Identifier.
+
+ MAC Address: The mobile station's MAC address.
+
+ QoS Profile: An 8-bit value specifying the QoS policy to enforce
+ for the station. The following values are supported:
+
+ 0 - Silver (Best Effort)
+
+ 1 - Gold (Video)
+
+ 2 - Platinum (Voice)
+
+ 3 - Bronze (Background)
+
+ VLAN Identifier: PRC.
+
+ DSCP Tag: The DSCP label to use if packets are to be DSCP tagged.
+
+ 802.1P Tag: The 802.1P precedence value to use if packets are to be
+ 802.1P-tagged.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 95]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+11.7.2. WTP Event Request
+
+ This section contains the 802.11-specific message elements that are
+ used with the WTP Event Request message.
+
+11.7.2.1. IEEE 802.11 Statistics
+
+ The Statistics message element is sent by the WTP to transmit its
+ current statistics. The value contains the following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Tx Fragment Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Tx Fragment Cnt| Multicast Tx Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Mcast Tx Cnt | Failed Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Failed Count | Retry Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Retry Count | Multiple Retry Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Multi Retry Cnt| Frame Duplicate Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Frame Dup Cnt | RTS Success Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |RTS Success Cnt| RTS Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |RTS Failure Cnt| ACK Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |ACK Failure Cnt| Rx Fragment Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Rx Fragment Cnt| Multicast RX Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Mcast Rx Cnt | FCS Error Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FCS Error Cnt| Tx Frame Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tx Frame Cnt | Decryption Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Decryption Errs|
+ +-+-+-+-+-+-+-+-+
+
+ Type: 38 for Statistics
+
+ Length: 57
+
+
+
+
+Calhoun, et al. Historic [Page 96]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Radio ID: An 8-bit value representing the radio.
+
+ Tx Fragment Count: A 32-bit value representing the number of
+ fragmented frames transmitted.
+
+ Multicast Tx Count: A 32-bit value representing the number of
+ multicast frames transmitted.
+
+ Failed Count: A 32-bit value representing the transmit excessive
+ retries.
+
+ Retry Count: A 32-bit value representing the number of transmit
+ retries.
+
+ Multiple Retry Count: A 32-bit value representing the number of
+ transmits that required more than one retry.
+
+ Frame Duplicate Count: A 32-bit value representing the duplicate
+ frames received.
+
+ RTS Success Count: A 32-bit value representing the number of
+ successfully transmitted Ready To Send (RTS).
+
+ RTS Failure Count: A 32-bit value representing the failed
+ transmitted RTS.
+
+ ACK Failure Count: A 32-bit value representing the number of failed
+ acknowledgements.
+
+ Rx Fragment Count: A 32-bit value representing the number of
+ fragmented frames received.
+
+ Multicast RX Count: A 32-bit value representing the number of
+ multicast frames received.
+
+ FCS Error Count: A 32-bit value representing the number of Frame
+ Check Sequence (FCS) failures.
+
+ Decryption Errors: A 32-bit value representing the number of
+ Decryption errors that occurred on the WTP. Note that this field
+ is only valid in cases where the WTP provides encryption/
+ decryption services.
+
+11.8. 802.11 Control Messages
+
+ This section will define LWAPP control messages that are specific to
+ the IEEE 802.11 binding.
+
+
+
+
+Calhoun, et al. Historic [Page 97]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+11.8.1. IEEE 802.11 WLAN Config Request
+
+ 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
+ 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
+ either some manual administrative process (e.g., deleting a WLAN), or
+ automatically to create a WLAN on a WTP. When sent automatically to
+ create a WLAN, this control message is sent after the LWAPP
+ Configuration Request message has been received by the WTP.
+
+ Upon receiving this control message, the WTP will modify the
+ necessary services, and transmit an IEEE 802.11 WLAN Configuration
+ Response.
+
+ An WTP MAY provide service for more than one WLAN: therefore, every
+ 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
+ IEEE 802.11 WLAN Configuration Request messages that include the Add
+ WLAN message element.
+
+ Since the index is the primary identifier for a WLAN, an AC SHOULD
+ attempt to ensure that the same WLAN is identified through the same
+ index number on all of its WTPs. An AC that does not follow this
+ approach MUST find some other means of maintaining a WLAN Identifier
+ to SSID mapping table.
+
+ The following subsections define the message elements that are of
+ value for this LWAPP operation. Only one message MUST be present.
+
+11.8.1.1. IEEE 802.11 Add WLAN
+
+ The Add WLAN message element is used by the AC to define a wireless
+ LAN on the WTP. The value contains the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 98]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN Capability | WLAN ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Encryption Policy |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Index | Shared Key | WPA Data Len |WPA IE Data ...|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RSN Data Len |RSN IE Data ...| Reserved .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | QoS | Auth Type |Broadcast SSID | Reserved... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSID ... |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 7 for IEEE 802.11 Add WLAN
+
+ Length: >= 298
+
+ Radio ID: An 8-bit value representing the radio.
+
+ WLAN Capability: A 16-bit value containing the capabilities to be
+ advertised by the WTP within the Probe and Beacon messages.
+
+ WLAN ID: A 16-bit value specifying the WLAN Identifier.
+
+ Encryption Policy: A 32-bit value specifying the encryption scheme
+ to apply to traffic to and from the mobile station.
+
+ The following values are supported:
+
+ 0 - Encrypt WEP 104: All packets to/from the mobile station must
+ be encrypted using a standard 104-bit WEP.
+
+ 1 - Clear Text: All packets to/from the mobile station do not
+ require any additional crypto processing by the WTP.
+
+ 2 - Encrypt WEP 40: All packets to/from the mobile station must
+ be encrypted using a standard 40-bit WEP.
+
+ 3 - Encrypt WEP 128: All packets to/from the mobile station must
+ be encrypted using a standard 128-bit WEP.
+
+
+
+
+Calhoun, et al. Historic [Page 99]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
+ must be encrypted using a 128-bit AES-CCMP [7].
+
+ 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
+ be encrypted using TKIP and authenticated using Michael [16].
+
+ 6 - Encrypt CKIP: All packets to/from the mobile station must be
+ encrypted using Cisco TKIP.
+
+ Key: A 32-byte session key to use with the encryption policy.
+
+ Key-Index: The Key Index associated with the key.
+
+ Shared Key: A 1-byte Boolean that specifies whether the key
+ included in the Key field is a shared WEP key. A value of zero is
+ used to state that the key is not a shared WEP key, while a value
+ of one is used to state that the key is a shared WEP key.
+
+ WPA Data Len: Length of the WPA Information Element (IE).
+
+ WPA IE: A 32-byte field containing the WPA Information Element.
+
+ RSN Data Len: Length of the Robust Security Network (RSN) IE.
+
+ RSN IE: A 64-byte field containing the RSN Information Element.
+
+ Reserved: A 49-byte reserved field, which MUST be set to zero (0).
+
+ WME Data Len: Length of the WME IE.
+
+ WME IE: A 32-byte field containing the WME Information Element.
+
+ DOT11E Data Len: Length of the 802.11e IE.
+
+ DOT11E IE: A 32-byte field containing the 802.11e Information
+ Element.
+
+ QOS: An 8-bit value specifying the QoS policy to enforce for the
+ station.
+
+ The following values are supported:
+
+ 0 - Silver (Best Effort)
+
+ 1 - Gold (Video)
+
+ 2 - Platinum (Voice)
+
+
+
+
+Calhoun, et al. Historic [Page 100]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 3 - Bronze (Background)
+
+ Auth Type: An 8-bit value specifying the station's authentication
+ type.
+
+ The following values are supported:
+
+ 0 - Open System
+
+ 1 - WEP Shared Key
+
+ 2 - WPA/WPA2 802.1X
+
+ 3 - WPA/WPA2 PSK
+
+ Broadcast SSID: A Boolean indicating whether the SSID is to be
+ broadcast by the WTP. A value of zero disables SSID broadcast,
+ while a value of one enables it.
+
+ Reserved: A 40-byte reserved field.
+
+ SSID: The SSID attribute is the service set identifier that will be
+ advertised by the WTP for this WLAN.
+
+11.8.1.2. IEEE 802.11 Delete WLAN
+
+ The Delete WLAN message element is used to inform the WTP that a
+ previously created WLAN is to be deleted. The value contains the
+ following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 28 for IEEE 802.11 Delete WLAN
+
+ Length: 3
+
+ Radio ID: An 8-bit value representing the radio
+
+ WLAN ID: A 16-bit value specifying the WLAN Identifier
+
+11.8.1.3. IEEE 802.11 Update WLAN
+
+ The Update WLAN message element is used by the AC to define a
+ wireless LAN on the WTP. The value contains the following format:
+
+
+
+Calhoun, et al. Historic [Page 101]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID |Encrypt Policy |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Encryption Policy | Key... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Index | Shared Key | WLAN Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 34 for IEEE 802.11 Update WLAN
+
+ Length: 43
+
+ Radio ID: An 8-bit value representing the radio.
+
+ WLAN ID: A 16-bit value specifying the WLAN Identifier.
+
+ Encryption Policy: A 32-bit value specifying the encryption scheme
+ to apply to traffic to and from the mobile station.
+
+ The following values are supported:
+
+ 0 - Encrypt WEP 104: All packets to/from the mobile station must
+ be encrypted using a standard 104-bit WEP.
+
+ 1 - Clear Text: All packets to/from the mobile station do not
+ require any additional crypto processing by the WTP.
+
+ 2 - Encrypt WEP 40: All packets to/from the mobile station must
+ be encrypted using a standard 40-bit WEP.
+
+ 3 - Encrypt WEP 128: All packets to/from the mobile station must
+ be encrypted using a standard 128-bit WEP.
+
+ 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
+ must be encrypted using a 128-bit AES-CCMP [7].
+
+ 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
+ be encrypted using TKIP and authenticated using Michael [16].
+
+ 6 - Encrypt CKIP: All packets to/from the mobile station must be
+ encrypted using Cisco TKIP.
+
+ Key: A 32-byte session key to use with the encryption policy.
+
+
+
+
+Calhoun, et al. Historic [Page 102]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Key-Index: The Key Index associated with the key.
+
+ Shared Key: A 1-byte Boolean that specifies whether the key
+ included in the Key field is a shared WEP key. A value of zero
+ means that the key is not a shared WEP key, while a value of one
+ is used to state that the key is a shared WEP key.
+
+ WLAN Capability: A 16-bit value containing the capabilities to be
+ advertised by the WTP within the Probe and Beacon messages.
+
+11.8.2. IEEE 802.11 WLAN Config Response
+
+ The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the
+ AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
+ Configuration Request.
+
+ This LWAPP control message does not include any message elements.
+
+11.8.3. IEEE 802.11 WTP Event
+
+ The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order
+ to report asynchronous events to the AC. There is no reply message
+ expected from the AC, except that the message is acknowledged via the
+ reliable transport.
+
+ When the AC receives the IEEE 802.11 WTP Event, it will take whatever
+ action is necessary, depending upon the message elements present in
+ the message.
+
+ The IEEE 802.11 WTP Event message MUST contain one of the following
+ message elements described in the next subsections.
+
+11.8.3.1. IEEE 802.11 MIC Countermeasures
+
+ The MIC Countermeasures message element is sent by the WTP to the AC
+ to indicate the occurrence of a MIC failure.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 61 for IEEE 802.11 MIC Countermeasures
+
+ Length: 8
+
+
+
+Calhoun, et al. Historic [Page 103]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier,
+ on which the MIC failure occurred.
+
+ MAC Address: The MAC address of the mobile station that caused the
+ MIC failure.
+
+11.8.3.2. IEEE 802.11 WTP Radio Fail Alarm Indication
+
+ The WTP Radio Fail Alarm Indication message element is sent by the
+ WTP to the AC when it detects a radio failure.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Type | Status | Pad |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 95 for WTP Radio Fail Alarm Indication
+
+ Length: 4
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ Type: The type of radio failure detected. The following values are
+ supported:
+
+ 1 - Receiver
+
+ 2 - Transmitter
+
+ Status: An 8-bit Boolean indicating whether the radio failure is
+ being reported or cleared. A value of zero is used to clear the
+ event, while a value of one is used to report the event.
+
+ Pad: Reserved field MUST be set to zero (0).
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 104]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+11.9. Message Element Bindings
+
+ The IEEE 802.11 Message Element binding has the following
+ definitions:
+
+ Conf Conf Conf Add
+ Req Resp Upd Mobile
+
+ IEEE 802.11 WTP WLAN Radio Configuration X X X
+ IEEE 802.11 Rate Set X X
+ IEEE 802.11 Multi-domain Capability X X X
+ IEEE 802.11 MAC Operation X X X
+ IEEE 802.11 Tx Power X X X
+ IEEE 802.11 Tx Power Level X
+ IEEE 802.11 Direct Sequence Control X X X
+ IEEE 802.11 OFDM Control X X X
+ IEEE 802.11 Supported Rates X X
+ IEEE 802.11 Antenna X X X
+ IEEE 802.11 CFP Status X X
+ IEEE 802.11 Broadcast Probe Mode X X
+ IEEE 802.11 WTP Mode and Type X? X
+ IEEE 802.11 WTP Quality of Service X X
+ IEEE 802.11 MIC Error Report From Mobile X
+ IEEE 802.11 Update Mobile QoS X
+ IEEE 802.11 Mobile Session Key X
+
+11.9.1. IEEE 802.11 WTP WLAN Radio Configuration
+
+ The WTP WLAN radio configuration is used by the AC to configure a
+ Radio on the WTP. The message element value contains the following
+ Fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Occupancy Limit |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CFP Per | CFP Maximum Duration | BSS ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSS ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSS ID | Beacon Period | DTIM Per |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Country String |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num Of BSSIDs |
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+Calhoun, et al. Historic [Page 105]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration
+
+ Length: 20
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Reserved: MUST be set to zero
+
+ Occupancy Limit: This attribute indicates the maximum amount of
+ time, in Time Units (TUs), that a point coordinator MAY control
+ the usage of the wireless medium without relinquishing control for
+ long enough to allow at least one instance of Distributed
+ Coordination Function (DCF) access to the medium. The default
+ value of this attribute SHOULD be 100, and the maximum value
+ SHOULD be 1000.
+
+ CFP Period: The attribute describes the number of DTIM intervals
+ between the start of Contention-Free Periods (CFPs).
+
+ CFP Maximum Duration: The attribute describes the maximum duration
+ of the CFP in TU that MAY be generated by the Point Coordination
+ Function (PCF).
+
+ BSSID: The WLAN Radio's base MAC address. For WTPs that support
+ more than a single WLAN, the value of the WLAN Identifier is added
+ to the last octet of the BSSID. Therefore, a WTP that supports 16
+ WLANs MUST have 16 MAC addresses reserved for it, and the last
+ nibble is used to represent the WLAN ID.
+
+ Beacon Period: This attribute specifies the number of TUs that a
+ station uses for scheduling Beacon transmissions. This value is
+ transmitted in Beacon and Probe Response frames.
+
+ DTIM Period: This attribute specifies the number of Beacon
+ intervals that elapses between transmission of Beacons frames
+ containing a TIM element whose DTIM Count field is 0. This value
+ is transmitted in the DTIM Period field of Beacon frames.
+
+ Country Code: This attribute identifies the country in which the
+ station is operating. The first two octets of this string is the
+ two-character country code as described in document ISO/IEC 3166-
+ 1. The third octet MUST be one of the following:
+
+ 1. an ASCII space character, if the regulations under which the
+ station is operating encompass all environments in the country,
+
+ 2. an ASCII 'O' character, if the regulations under which the station
+ is operating are for an outdoor environment only, or
+
+
+
+Calhoun, et al. Historic [Page 106]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 3. an ASCII 'I' character, if the regulations under which the station
+ is operating are for an indoor environment only.
+
+ Number of BSSIDs: This attribute contains the maximum number of
+ BSSIDs supported by the WTP. This value restricts the number of
+ logical networks supported by the WTP.
+
+11.9.2. IEEE 802.11 Rate Set
+
+ The Rate Set message element value is sent by the AC and contains the
+ supported operational rates. It contains the following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Rate Set |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 16 for IEEE 802.11 Rate Set
+
+ Length: 4
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Rate Set: The AC generates the Rate Set that the WTP is to include
+ in its Beacon and Probe messages.
+
+11.9.3. IEEE 802.11 Multi-Domain Capability
+
+ The Multi-Domain Capability message element is used by the AC to
+ inform the WTP of regulatory limits. The value contains the
+ following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | First Channel # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of Channels | Max Tx Power Level |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 10 for IEEE 802.11 Multi-Domain Capability
+
+ Length: 8
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Reserved: MUST be set to zero
+
+
+
+Calhoun, et al. Historic [Page 107]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ First Channel #: This attribute indicates the value of the lowest
+ channel number in the subband for the associated domain country
+ string.
+
+ Number of Channels: This attribute indicates the value of the total
+ number of channels allowed in the subband for the associated
+ domain country string.
+
+ Max Tx Power Level: This attribute indicates the maximum transmit
+ power, in dBm, allowed in the subband for the associated domain
+ country string.
+
+11.9.4. IEEE 802.11 MAC Operation
+
+ The MAC Operation message element is sent by the AC to set the 802.11
+ MAC parameters on the WTP. The value contains the following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | RTS Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Short Retry | Long Retry | Fragmentation Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tx MSDU Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rx MSDU Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 11 for IEEE 802.11 MAC Operation
+
+ Length: 16
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Reserved: MUST be set to zero
+
+ RTS Threshold: This attribute indicates the number of octets in a
+ Management Protocol Data Unit (MPDU), below which an RTS/CTS
+ (clear to send) handshake MUST NOT be performed. An RTS/CTS
+ handshake MUST be performed at the beginning of any frame exchange
+ sequence where the MPDU is of type Data or Management, the MPDU
+ has an individual address in the Address1 field, and the length of
+ the MPDU is greater than this threshold. Setting this attribute
+ to be larger than the maximum MAC Service Data Unit (MSDU) size
+ MUST have the effect of turning off the RTS/CTS handshake for
+ frames of Data or Management type transmitted by this Station
+ (STA). Setting this attribute to zero MUST have the effect of
+
+
+
+Calhoun, et al. Historic [Page 108]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ turning on the RTS/CTS handshake for all frames of Data or
+ Management type transmitted by this STA. The default value of
+ this attribute MUST be 2347.
+
+ Short Retry: This attribute indicates the maximum number of
+ transmission attempts of a frame, the length of which is less than
+ or equal to RTSThreshold, that MUST be made before a failure
+ condition is indicated. The default value of this attribute MUST
+ be 7.
+
+ Long Retry: This attribute indicates the maximum number of
+ transmission attempts of a frame, the length of which is greater
+ than dot11RTSThreshold, that MUST be made before a failure
+ condition is indicated. The default value of this attribute MUST
+ be 4.
+
+ Fragmentation Threshold: This attribute specifies the current
+ maximum size, in octets, of the MPDU that MAY be delivered to the
+ PHY. An MSDU MUST be broken into fragments if its size exceeds
+ the value of this attribute after adding MAC headers and trailers.
+ An MSDU or MAC Management Protocol Data Unit (MMPDU) MUST be
+ fragmented when the resulting frame has an individual address in
+ the Address1 field, and the length of the frame is larger than
+ this threshold. The default value for this attribute MUST be the
+ lesser of 2346 or the aMPDUMaxLength of the attached PHY and MUST
+ never exceed the lesser of 2346 or the aMPDUMaxLength of the
+ attached PHY. The value of this attribute MUST never be less than
+ 256.
+
+ Tx MSDU Lifetime: This attribute specifies the elapsed time in TU,
+ after the initial transmission of an MSDU, after which, further
+ attempts to transmit the MSDU MUST be terminated. The default
+ value of this attribute MUST be 512.
+
+ Rx MSDU Lifetime: This attribute specifies the elapsed time, in TU,
+ after the initial reception of a fragmented MMPDU or MSDU, after
+ which, further attempts to reassemble the MMPDU or MSDU MUST be
+ terminated. The default value MUST be 512.
+
+11.9.5. IEEE 802.11 Tx Power
+
+ The Tx Power message element value is bi-directional. When sent by
+ the WTP, it contains the current power level of the radio in
+ question. When sent by the AC, it contains the power level to which
+ the WTP MUST adhere:
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 109]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Current Tx Power |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 12 for IEEE 802.11 Tx Power
+
+ Length: 4
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Reserved: MUST be set to zero
+
+ Current Tx Power: This attribute contains the transmit output power
+ in mW.
+
+11.9.6. IEEE 802.11 Tx Power Level
+
+ The Tx Power Level message element is sent by the WTP and contains
+ the different power levels supported. The value contains the
+ following fields:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Num Levels | Power Level [n] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 13 for IEEE 802.11 Tx Power Level
+
+ Length: >= 4
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Num Levels: The number of power level attributes.
+
+ Power Level: Each power level fields contains a supported power
+ level, in mW.
+
+11.9.7. IEEE 802.11 Direct Sequence Control
+
+ The Direct Sequence Control message element is a bi-directional
+ element. When sent by the WTP, it contains the current state. When
+ sent by the AC, the WTP MUST adhere to the values. This element is
+ only used for 802.11b radios. The value has the following fields.
+
+
+
+
+
+Calhoun, et al. Historic [Page 110]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Current Chan | Current CCA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Energy Detect Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 14 for IEEE 802.11 Direct Sequence Control
+
+ Length: 8
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Reserved: MUST be set to zero
+
+ Current Channel: This attribute contains the current operating
+ frequency channel of the Direct Sequence Spread Spectrum (DSSS)
+ PHY.
+
+ Current CCA: The current Controlled Channel Access (CCA) method in
+ operation. Valid values are:
+
+ 1 - energy detect only (edonly)
+
+ 2 - carrier sense only (csonly)
+
+ 4 - carrier sense and energy detect (edandcs)
+
+ 8 - carrier sense with timer (cswithtimer)
+
+ 16 - high-rate carrier sense and energy detect (hrcsanded)
+
+ Energy Detect Threshold: The current Energy Detect Threshold being
+ used by the DSSS PHY.
+
+11.9.8. IEEE 802.11 OFDM Control
+
+ The Orthogonal Frequency Division Multiplexing (OFDM) Control message
+ element is a bi-directional element. When sent by the WTP, it
+ contains the current state. When sent by the AC, the WTP MUST adhere
+ to the values. This element is only used for 802.11a radios. The
+ value contains the following fields:
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 111]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Current Chan | Band Support |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TI Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 15 for IEEE 802.11 OFDM Control
+
+ Length: 8
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Reserved: MUST be set to zero
+
+ Current Channel: This attribute contains the current operating
+ frequency channel of the OFDM PHY.
+
+ Band Supported: The capability of the OFDM PHY implementation to
+ operate in the three U-NII bands. Coded as an integer value of a
+ 3-bit field as follows:
+
+ Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII
+ band
+
+ Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII
+ band
+
+ Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII
+ band
+
+ For example, for an implementation capable of operating in the
+ lower and mid bands, this attribute would take the value.
+
+ TI Threshold: The threshold being used to detect a busy medium
+ (frequency). CCA MUST report a busy medium upon detecting the
+ RSSI above this threshold.
+
+11.9.9. IEEE 802.11 Antenna
+
+ The Antenna message element is communicated by the WTP to the AC to
+ provide information on the antennas available. The AC MAY use this
+ element to reconfigure the WTP's antennas. The value contains the
+ following fields:
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 112]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Diversity | Combiner | Antenna Cnt |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Antenna Selection [0..N] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 41 for IEEE 802.11 Antenna
+
+ Length: >= 8
+
+ Radio ID: An 8-bit value representing the radio to configure.
+
+ Diversity: An 8-bit value specifying whether the antenna is to
+ provide receive diversity. The following values are supported:
+
+ 0 - Disabled
+
+ 1 - Enabled (may only be true if the antenna can be used as a
+ receive antenna)
+
+ Combiner: An 8-bit value specifying the combiner selection. The
+ following values are supported:
+
+ 1 - Sectorized (Left)
+
+ 2 - Sectorized (Right)
+
+ 3 - Omni
+
+ 4 - Mimo
+
+ Antenna Count: An 8-bit value specifying the number of Antenna
+ Selection fields.
+
+ Antenna Selection: One 8-bit antenna configuration value per
+ antenna in the WTP. The following values are supported:
+
+ 1 - Internal Antenna
+
+ 2 - External Antenna
+
+11.9.10. IEEE 802.11 Supported Rates
+
+ The Supported Rates message element is sent by the WTP to indicate
+ the rates that it supports. The value contains the following fields:
+
+
+
+
+Calhoun, et al. Historic [Page 113]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Supported Rates |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 16 for IEEE 802.11 Supported Rates
+
+ Length: 4
+
+ Radio ID: An 8-bit value representing the radio.
+
+ Supported Rates: The WTP includes the Supported Rates that its
+ hardware supports. The format is identical to the Rate Set
+ message element.
+
+11.9.11. IEEE 802.11 CFP Status
+
+ The CFP Status message element is sent to provide the CF Polling
+ configuration.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 48 for IEEE 802.11 CFP Status
+
+ Length: 2
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ Status: An 8-bit Boolean containing the status of the CF Polling
+ feature. A value of zero disables CFP Status, while a value of
+ one enables it.
+
+11.9.12. IEEE 802.11 WTP Mode and Type
+
+ The WTP Mode and Type message element is used to configure a WTP to
+ operate in a specific mode.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Mode | Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Calhoun, et al. Historic [Page 114]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Type: 54 for IEEE 802.11 WTP Mode and Type
+
+ Length: 2
+
+ Mode: An 8-bit value describing the type of information being sent.
+ The following values are supported:
+
+ 0 - Split MAC
+
+ 2 - Local MAC
+
+ Type: The type field is not currently used.
+
+11.9.13. IEEE 802.11 Broadcast Probe Mode
+
+ The Broadcast Probe Mode message element indicates whether a WTP will
+ respond to NULL SSID Probe requests. Since broadcast NULL Probes are
+ not sent to a specific BSSID, the WTP cannot know which SSID the
+ sending station is querying. Therefore, this behavior must be global
+ to the WTP.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Status |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 51 for IEEE 802.11 Broadcast Probe Mode
+
+ Length: 1
+
+ Status: An 8-bit Boolean indicating the status of whether a WTP
+ shall respond to a NULL SSID Probe request. A value of zero
+ disables the NULL SSID Probe response, while a value of one
+ enables it.
+
+11.9.14. IEEE 802.11 WTP Quality of Service
+
+ The WTP Quality of Service message element value is sent by the AC to
+ the WTP to communicate quality-of-service configuration information.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Tag Packets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 57 for IEEE 802.11 WTP Quality of Service
+
+
+
+Calhoun, et al. Historic [Page 115]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Length: 12
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ Tag Packets: A value indicating whether LWAPP packets should be
+ tagged for QoS purposes. The following values are currently
+ supported:
+
+ 0 - Untagged
+
+ 1 - 802.1P
+
+ 2 - DSCP
+
+ Immediately following the above header is the following data
+ structure. This data structure will be repeated five times, once
+ for every QoS profile. The order of the QoS profiles is Uranium,
+ Platinum, Gold, Silver, and Bronze.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Queue Depth | CWMin | CWMax |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CWMax | AIFS | CBR |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Dot1P Tag | DSCP Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Queue Depth: The number of packets that can be on the specific QoS
+ transmit queue at any given time.
+
+ CWMin: The Contention Window minimum value for the QoS transmit
+ queue.
+
+ CWMax: The Contention Window maximum value for the QoS transmit
+ queue.
+
+ AIFS: The Arbitration Inter Frame Spacing to use for the QoS
+ transmit queue.
+
+ CBR: The Constant Bit Rate (CBR) value to observe for the QoS
+ transmit queue.
+
+ Dot1P Tag: The 802.1P precedence value to use if packets are to be
+ 802.1P tagged.
+
+
+
+
+Calhoun, et al. Historic [Page 116]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ DSCP Tag: The DSCP label to use if packets are to be DSCP tagged.
+
+11.9.15. IEEE 802.11 MIC Error Report From Mobile
+
+ The MIC Error Report From Mobile message element is sent by an AC to
+ a WTP when it receives a MIC failure notification via the Error bit
+ in the EAP over LAN (EAPOL)-Key frame.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Client MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Client MAC Address | BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 79 for IEEE 802.11 MIC Error Report From Mobile
+
+ Length: 14
+
+ Client MAC Address: The Client MAC address of the station reporting
+ the MIC failure.
+
+ BSSID: The BSSID on which the MIC failure is being reported.
+
+ Radio ID: The Radio Identifier, typically refers to some interface
+ index on the WTP.
+
+ WLAN ID: The WLAN ID on which the MIC failure is being reported.
+
+11.10. IEEE 802.11 Message Element Values
+
+ This section lists IEEE 802.11-specific values for any generic LWAPP
+ message elements that include fields whose values are technology-
+ specific.
+
+ IEEE 802.11 uses the following values:
+
+ 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7].
+
+ 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in
+ [16].
+
+
+
+
+
+Calhoun, et al. Historic [Page 117]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+12. LWAPP Protocol Timers
+
+ A WTP or AC that implements LWAPP discovery MUST implement the
+ following timers.
+
+12.1. MaxDiscoveryInterval
+
+ The maximum time allowed between sending Discovery Requests from the
+ interface, in seconds. Must be no less than 2 seconds and no greater
+ than 180 seconds.
+
+ Default: 20 seconds.
+
+12.2. SilentInterval
+
+ The minimum time, in seconds, a WTP MUST wait after failing to
+ receive any responses to its Discovery Requests, before it MAY again
+ send Discovery Requests.
+
+ Default: 30
+
+12.3. NeighborDeadInterval
+
+ The minimum time, in seconds, a WTP MUST wait without having received
+ Echo Responses to its Echo Requests, before the destination for the
+ Echo Request may be considered dead. Must be no less than
+ 2*EchoInterval seconds and no greater than 240 seconds.
+
+ Default: 60
+
+12.4. EchoInterval
+
+ The minimum time, in seconds, between sending Echo Requests to the AC
+ with which the WTP has joined.
+
+ Default: 30
+
+12.5. DiscoveryInterval
+
+ The minimum time, in seconds, that a WTP MUST wait after receiving a
+ Discovery Response, before sending a Join Request.
+
+ Default: 5
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 118]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+12.6. RetransmitInterval
+
+ The minimum time, in seconds, that a non-acknowledged LWAPP packet
+ will be retransmitted.
+
+ Default: 3
+
+12.7. ResponseTimeout
+
+ The minimum time, in seconds, in which an LWAPP Request message must
+ be responded to.
+
+ Default: 1
+
+12.8. KeyLifetime
+
+ The maximum time, in seconds, that an LWAPP session key is valid.
+
+ Default: 28800
+
+13. LWAPP Protocol Variables
+
+ A WTP or AC that implements LWAPP discovery MUST allow for the
+ following variables to be configured by system management; default
+ values are specified so as to make it unnecessary to configure any of
+ these variables in many cases.
+
+13.1. MaxDiscoveries
+
+ The maximum number of Discovery Requests that will be sent after a
+ WTP boots.
+
+ Default: 10
+
+13.2. DiscoveryCount
+
+ The number of discoveries transmitted by a WTP to a single AC. This
+ is a monotonically increasing counter.
+
+13.3. RetransmitCount
+
+ The number of retransmissions for a given LWAPP packet. This is a
+ monotonically increasing counter.
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 119]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+13.4. MaxRetransmit
+
+ The maximum number of retransmissions for a given LWAPP packet before
+ the link layer considers the peer dead.
+
+ Default: 5
+
+14. NAT Considerations
+
+ There are two specific situations where a NAT system may be used in
+ conjunction with LWAPP. The first consists of a configuration where
+ the WTP is behind a NAT system. Given that all communication is
+ initiated by the WTP, and all communication is performed over IP
+ using a single UDP port, the protocol easily traverses NAT systems in
+ this configuration.
+
+ The second configuration is one where the AC sits behind a NAT, and
+ there are two main issues that exist in this situation. First, an AC
+ communicates its interfaces and associated WTP load on these
+ interfaces, through the WTP Manager Control IP Address. This message
+ element is currently mandatory, and if NAT compliance became an
+ issue, it would be possible to either:
+
+ 1. make the WTP Manager Control IP Address optional, allowing the WTP
+ to simply use the known IP address. However, note that this
+ approach would eliminate the ability to perform load balancing of
+ WTP across ACs, and therefore is not the recommended approach.
+
+ 2. allow an AC to be able to configure a NAT'ed address for every
+ associated AC that would generally be communicated in the WTP
+ Manager Control IP Address message element.
+
+ 3. require that if a WTP determines that the AC List message element
+ consists of a set of IP addresses that are different from the AC's
+ IP address it is currently communicating with, then assume that
+ NAT is being enforced, and require that the WTP communicate with
+ the original AC's IP address (and ignore the WTP Manager Control
+ IP Address message element(s)).
+
+ Another issue related to having an AC behind a NAT system is LWAPP's
+ support for the CAPWAP Objective to allow the control and data plane
+ to be separated. In order to support this requirement, the LWAPP
+ protocol defines the WTP Manager Data IP Address message element,
+ which allows the AC to inform the WTP that the LWAPP data frames are
+ to be forwarded to a separate IP address. This feature MUST be
+ disabled when an AC is behind a NAT. However, there is no easy way
+ to provide some default mechanism that satisfies both the data/
+
+
+
+
+Calhoun, et al. Historic [Page 120]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ control separation and NAT objectives, as they directly conflict with
+ each other. As a consequence, user intervention will be required to
+ support such networks.
+
+ LWAPP has a feature that allows for all of the AC's identities
+ supporting a group of WTPs to be communicated through the AC List
+ message element. This feature must be disabled when the AC is behind
+ a NAT and the IP address that is embedded would be invalid.
+
+ The LWAPP protocol has a feature that allows an AC to configure a
+ static IP address on a WTP. The WTP Static IP Address Information
+ message element provides such a function; however, this feature
+ SHOULD NOT be used in NAT'ed environments, unless the administrator
+ is familiar with the internal IP addressing scheme within the WTP's
+ private network, and does not rely on the public address seen by the
+ AC.
+
+ When a WTP detects the duplicate address condition, it generates a
+ message to the AC, which includes the Duplicate IP Address message
+ element. Once again, it is important to note that the IP address
+ embedded within this message element would be different from the
+ public IP address seen by the AC.
+
+15. Security Considerations
+
+ LWAPP uses either an authenticated key exchange or key agreement
+ mechanism to ensure peer authenticity and establish fresh session
+ keys to protect the LWAPP communications.
+
+ The LWAPP protocol defines a join phase, which allows a WTP to bind a
+ session with an AC. During this process, a session key is mutually
+ derived, and secured either through an X.509 certificate or a pre-
+ shared key. The resulting key exchange generates an encryption
+ session key, which is used to encrypt the LWAPP control packets, and
+ a key derivation key.
+
+ During the established secure communication, the WTP and AC may rekey
+ using the key update process, which is identical to the join phase,
+ meaning the session keys are mutually derived. However, the exchange
+ described for pre-shared session keys is always used for the key
+ update, with the pre-shared key set to the derivation key created
+ either during the join, or the last key update if one has occurred.
+ The key update results in a new derivation key, which is used in the
+ next key update, as well as an encryption session key to encrypt the
+ LWAPP control packets.
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 121]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ Replay protection of the Join Request is handled through an exchange
+ of nonces during the join (or key update) phase. The Join Request
+ includes an XNonce, which is included in the AC's authenticated Join
+ Reply's encrypted ANonce message element, allowing for the two
+ messages to be bound. Upon receipt of the Join Reply, the WTP
+ generates the WNonce, and generates a set of session keys using a KDF
+ function. One of these keys is used to MIC the Join ACK. The AC
+ responds with a Join Confirm, which must also include a MIC, and
+ therefore be capable of deriving the same set of session keys.
+
+ In both the X.509 certificate and pre-shared key modes, an
+ initialization vector is created through the above mentioned KDF
+ function. The IV and the KDF created encryption key are used to
+ encrypt the LWAPP control frames.
+
+ Given that authentication in the Join exchange does not occur until
+ the WTP transmits the Join ACK message, it is crucial that an AC not
+ delete any state for a WTP it is servicing until an authentication
+ Join ACK has been received. Otherwise, a potential Denial-of-Service
+ attack exists, whereby sending a spoofed Join Request for a valid WTP
+ would cause the AC to reset the WTP's connection.
+
+ It is important to note that Perfect Forward Secrecy is not a
+ requirement for the LWAPP protocol.
+
+ Note that the LWAPP protocol does not add any new vulnerabilities to
+ 802.11 infrastructure that makes use of WEP for encryption purposes.
+ However, implementors SHOULD discourage the use of WEP to allow the
+ market to move towards technically sound cryptographic solutions,
+ such as 802.11i.
+
+15.1. Certificate-Based Session Key Establishment
+
+ LWAPP uses public key cryptography to ensure trust between the WTP
+ and the AC. One question that periodically arises is why the Join
+ Request is not signed. Signing this request would not be optimal for
+ the following reasons:
+
+ 1. The Join Request is replayable, so a signature doesn't provide
+ much protection unless the switches keep track of all previous
+ Join Requests from a given WTP.
+
+ 2. Replay detection is handled during the Join Reply and Join ACK
+ messages.
+
+ 3. A signed Join Request provides a potential Denial-of-Service
+ attack on the AC, which would have to authenticate each
+ (potentially malicious) message.
+
+
+
+Calhoun, et al. Historic [Page 122]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ The WTP-Certificate that is included in the Join Request MUST be
+ validated by the AC. It is also good practice that the AC perform
+ some form of authorization, ensuring that the WTP in question is
+ allowed to establish an LWAPP session with it.
+
+15.2. PSK-Based Session Key Establishment
+
+ Use of a fixed shared secret of limited entropy (for example, a PSK
+ that is relatively short, or was chosen by a human and thus may
+ contain less entropy than its length would imply) may allow an
+ attacker to perform a brute-force or dictionary attack to recover the
+ secret.
+
+ It is RECOMMENDED that implementations that allow the administrator
+ to manually configure the PSK also provide a functionality for
+ generating a new random PSK, taking RFC 1750 [4] into account.
+
+ Since the key generation does not expose the nonces in plaintext,
+ there are no practical passive attacks possible.
+
+16. Acknowledgements
+
+ The authors wish to thank Michael Vakulenko for contributing text
+ that describes how LWAPP can be used over a Layer 3 (IP) network.
+
+ The authors would also like to thanks Russ Housley and Charles Clancy
+ for their assistance in providing a security review of the LWAPP
+ specification. Charles' review can be found in [12].
+
+17. References
+
+17.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] National Institute of Standards and Technology, "Advanced
+ Encryption Standard (AES)", FIPS PUB 197, November 2001,
+ <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
+
+ [3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-
+ MAC (CCM)", RFC 3610, September 2003.
+
+ [4] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [5] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related
+ Terminology", RFC 3753, June 2004.
+
+
+
+Calhoun, et al. Historic [Page 123]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+ [6] "Information technology - Telecommunications and information
+ exchange between systems - Local and metropolitan area networks
+ - Specific requirements - Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) specifications", IEEE
+ Standard 802.11, 2007,
+ <http://standards.ieee.org/getieee802/download/802.11-2007.pdf>
+
+ [7] "Information technology - Telecommunications and information
+ exchange between systems - Local and metropolitan area networks
+ - Specific requirements - Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) specifications Amendment
+ 6: Medium Access Control (MAC) Security Enhancements", IEEE
+ Standard 802.11i, July 2004,
+ http://standards.ieee.org/getieee802/download/802.11i-2004.pdf
+
+ [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, July
+ 1982.
+
+ [9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES)
+ Key Wrap Algorithm", RFC 3394, September 2002.
+
+ [10] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
+ R., and W. Polk, "Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL) Profile", RFC
+ 5280, May 2008.
+
+ [11] "Netscape-Defined Certificate Extensions",
+ <http://www.redhat.com/docs/manuals/cert-
+ system/admin/7.1/app_ext.html#35336>.
+
+ [12] Clancy, C., "Security Review of the Light-Weight Access Point
+ Protocol", May 2005,
+ <http://www.cs.umd.edu/~clancy/docs/lwapp-review.pdf>.
+
+17.2. Informative References
+
+ [13] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by
+ an On-line Database", RFC 3232, January 2002.
+
+ [14] Kent, S. and K. Seo, "Security Architecture for the Internet
+ Protocol", RFC 4301, December 2005.
+
+ [15] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+ for Message Authentication", RFC 2104, February 1997.
+
+ [16] "WiFi Protected Access (WPA) rev 1.6", April 2003.
+
+
+
+
+
+Calhoun, et al. Historic [Page 124]
+
+RFC 5412 Lightweight Access Point Protocol February 2010
+
+
+Authors' Addresses
+
+ Pat R. Calhoun
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ Phone: +1 408-853-5269
+ EMail: pcalhoun@cisco.com
+
+ Rohit Suri
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ Phone: +1 408-853-5548
+ EMail: rsuri@cisco.com
+
+ Nancy Cam-Winget
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ Phone: +1 408-853-0532
+ EMail: ncamwing@cisco.com
+
+ Scott Kelly
+ EMail: scott@hyperthought.com
+
+
+ Michael Glenn Williams
+ GWhiz Arts & Sciences
+ 1560 Newbury Road, Suite 1-204
+ Newbury Park, CA 91320
+ Phone: +1 805-499-1994
+ EMail: gwhiz@gwhiz.com
+
+
+ Sue Hares
+ Phone: +1 734-604-0332
+ EMail: shares@ndzh.com
+
+ Bob O'Hara
+ EMail: bob.ohara@computer.org
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Historic [Page 125]
+