RFC 4565

Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols

📅 published July 2006, from ietf

Title Block: RFC 4565 🎀

Okay so this one is from July 2006 and it's an Informational RFC, which means it's a record of what happened, not a standard anyone has to follow 💅. It was written by D. Loher from Envysion, Inc., D. Nelson from Enterasys Networks, Inc., O. Volinsky from Colubris Networks, Inc., and B. Sarikaya from Huawei USA. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🦋

The title is Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols, and the whole thing is the evaluation team's own paper trail for picking among CAPWAP candidates. It's giving peer review drama 🍓

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 💜

Copyright Notice 🌸

Abstract 🧚

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team looked at the 4 candidate protocols that were submitted to the working group on June 26, 2005. So basically, this is the receipts for how the decision got made 🔥

Table of Contents 📋

1. Introduction ....................................................3
   1.1. Conventions Used in This Document ..........................3
   1.2. Terminology ................................................3
2. Process Description .............................................3
   2.1. Ratings ....................................................3
3. Member Statements ...............................................4
4. Protocol Proposals and Highlights ...............................5
   4.1. LWAPP ......................................................5
   4.2. SLAPP ......................................................6
   4.3. CTP ........................................................6
   4.4. WiCoP ......................................................7

5. Security Considerations .........................................7
6. Mandatory Objective Compliance Evaluation .......................8
   6.1. Logical Groups .............................................8
   6.2. Traffic Separation .........................................8
   6.3. STA Transparency ...........................................9
   6.4. Configuration Consistency .................................10
   6.5. Firmware Trigger ..........................................11
   6.6. Monitor and Exchange of System-wide Resource State ........12
   6.7. Resource Control ..........................................13
   6.8. Protocol Security .........................................15
   6.9. System-Wide Security ......................................16
   6.10. 802.11i Considerations ...................................17
   6.11. Interoperability .........................................17
   6.12. Protocol Specifications ..................................18
   6.13. Vendor Independence ......................................19
   6.14. Vendor Flexibility .......................................19
   6.15. NAT Traversal ............................................20
7. Desirable Objective Compliance Evaluation ......................20
   7.1. Multiple Authentication ...................................20
   7.2. Future Wireless Technologies ..............................21
   7.3. New IEEE Requirements .....................................21
   7.4. Interconnection (IPv6) ....................................22
   7.5. Access Control ............................................23
8. Evaluation Summary and Conclusions .............................24
9. Protocol Recommendation ........................................24
   9.1. High-Priority Recommendations Relevant to
        Mandatory Objectives ......................................25
        9.1.1. Information Elements ...............................25
        9.1.2. Control Channel Security ...........................25
        9.1.3. Data Tunneling Modes ...............................26
   9.2. Additional Recommendations Relevant to Desirable
        Objectives ................................................27
        9.2.1. Access Control .....................................27
        9.2.2. Removal of Layer 2 Encapsulation for Data
               Tunneling ..........................................28
        9.2.3. Data Encapsulation Standard ........................28
10. Normative References ..........................................29
11. Informative References ........................................29

1. Introduction 💖

Okay so the intro basically repeats the abstract, because it's the same evaluation team and the same 4 candidate protocols submitted on June 26, 2005. This is the process and findings record for the CAPWAP WG evaluation team, and yes, it's as iconic as it sounds ✨

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 [RFC2119]. Those capital words are the official BCP 14 vibes, so read them exactly as RFC 2119 says 🫶

1.2. Terminology 🦋

This document uses terminology defined in RFC 4118 [ARCH], RFC 4564 [OBJ], and IEEE 802.11i [802.11i]. So if a term feels unfamiliar, go check those first 🧚

2. Process Description 🌈

The process here was adopted from an earlier IETF evaluation in [RFC3127], so the team wasn't inventing this from scratch, they were borrowing a proven move 💅 The CAPWAP objectives in RFC 4564 [OBJ] set the scope and direction for the evaluators and were the main source of requirements. The team also leaned on their expert knowledge and professional experience to decide how well each candidate protocol met the working group objectives, so it wasn't just a checklist, it was real judgement 🔥

For each of the 4 candidate protocols, the evaluation document editor assigned 2 team members to write evaluation briefs. One member wrote a "Pro" brief and could take a generous interpretation of the proposal, so this evaluator could give the benefit of the doubt 🌸 The second evaluator wrote a "Con" brief and was required to use strict criteria when evaluating. Pro versus Con, it's the ultimate debate energy 😭

2.1. Ratings 💜

The "Pro" and "Con" members evaluated how well the candidate protocol met each objective, independently of each other. Each objective got scored as an 'F' for failure, 'P' for partial, or 'C' for completely meeting the objective 📋

F - Failure to Comply 💀

The evaluation team believes the proposal does not meet the objective. This could happen if the proposal is completely missing any functionality toward the objective. A proposal could also get an 'F' for implementing the objective improperly.

P - Partial Compliance 🙈

The proposal has some functionality that addresses the objective, but it's incomplete or ambiguous. Almost there, but not quite.

C - Compliant 👑

The proposal fully specifies functionality that meets the objective. The specification must be detailed enough that interoperable implementations are likely from reading the proposal alone. If the method is ambiguous or particularly complex, an explanation, use cases, or even diagrams may need to be supplied in order to receive a compliant rating. The bar is high, bestie, and it's giving perfectionism ✨

The 4-person evaluation team held a teleconference for each candidate to discuss the briefs. One of the working group chairs was also in the meeting in an advisory capacity. Each evaluator presented a brief with supporting details. The team talked through the issues and delivered one team rating for each objective. These discussions are written up in the meeting minutes, and the team ratings are what the compliance evaluation actually uses 🎀

The candidate protocols were scored only on the information written in their draft. This means a protocol might actually meet the specifics of a requirement, but if the proposal didn't state, describe, or reference how that requirement was met, it could get scored lower. So if it's not written down, it's not happening, iykyk 💅

3. Member Statements 🧚

Each team member gave a statement about their background and any connections to the candidate protocols. Here's the tea ☕

Darren Loher, Roving Planet 🌸

Darren is the senior architect at Roving Planet, which writes network and security management software for wireless networks. He has over 11 years of commercial experience designing and operating networks. He has implemented and operated networks and network management systems for a university, large enterprises, and a major Internet service provider for over 4 years. He also has software development experience and has written web-based network and systems management tools, including a system for managing a very large distributed DNS system. He has watched the IETF standards process for several years, with his first event being IETF 28, and he had rarely directly participated in working group activities before this point. To his knowledge, his company has no direct relationship with any companies that authored the CAPWAP protocol submissions. Clean hands 🫶

David Nelson, Enterasys 💜

David is currently cochair of the RADEXT WG and the AAA Doctor in the O&M Area, and works in the core router engineering group at his company. He has previously served on a protocol evaluation team in the AAA WG and is a coauthor of RFC 3127 [RFC3127]. He was an active contributor to the IEEE 802.11i task group and was previously employed in the WLAN engineering group at his company. He has had no participation in any of the submitted protocols. His company does have an OEM relationship with at least one company whose employees coauthored one of the submissions, but he has no direct involvement with their WLAN product at this time. Very transparent, very responsible 👑

Oleg Volinsky, Colubris Networks 🦋

Oleg is a member of the Enterprise group at Colubris Networks, a WLAN vendor. He has over 10 years of experience designing and developing network products, from core routers to home networking equipment. Over the years he has participated in various IETF groups. He has been a member of the CAPWAP WG for over a year. In his current position he has been monitoring CAPWAP standards developments and the potential integration of the resulting protocol into his company's products. He has not participated in any of the candidate protocol drafts, and he has not worked for any of the companies whose staff authored any of the candidate protocols. Pure objectivity energy 🌈

Behcet Sarikaya, University of Northern British Columbia ✨

Behcet is currently a Professor of Computer Science at UNBC. He has 5 years of experience in the IETF as a member of mobile networking-related working groups. He has made numerous I-D contributions and is a coauthor of one RFC. He submitted an evaluation draft, with Andy Lee, that evaluated LWAPP, CTP, and WiCoP. He also submitted another draft, on CAPWAPHP, that used LWAPP, CTP, WiCoP, and SLAPP as transport. He has research interests in next-generation access point and controller architectures too. He has no involvement in any of the candidate protocol drafts and has not contributed any of the drafts. He has not worked in any of the companies whose staff produced any of the candidate protocols. Academic and unbothered 🧚

4. Protocol Proposals and Highlights 💅

The following proposals were submitted to the CAPWAP working group as candidates. Let's meet them 🎀

(Part 1 of 6. More coming, bestie 💖)

4.1. LWAPP ✨

Okay bestie, first up is the "Light Weight Access Point Protocol" [LWAPP] 🦋 It was the very first CAPWAP protocol submitted to the Seamoby Working Group, so it's kind of the OG! It came with its own original ideas for authentication, user data encapsulation, and management and configuration information elements 💖 LWAPP started out as a "split MAC" protocol, but newer changes added local MAC support too 🙌 It also got a security review from Charles Clancy of the University of Maryland Information Systems Security Lab 🔐

LWAPP is the most detailed CAPWAP proposal, no cap 🔥 It gives a thorough spec for discovery, security, and system management. It's really focused on 802.11 WLAN-specific monitoring and configuration 📡 The big feature is that raw 802.11 frames get tunneled back to the Access Controller (AC) for processing 💅 In both local-MAC and split-MAC modes, raw 802.11 frames go to the AC for management and control. And in split-MAC mode, user data gets tunneled to the AC in raw 802.11 form too 🌸 In theory LWAPP could work with other wireless technologies, but it defines very few primitives that don't depend on the 802.11 layer, so it's giving 802.11-only vibes 🙈

4.2. SLAPP

"Secure Light Access Point Protocol" [SLAPP] is serving well-known, established tech 🎀 It uses Generic Routing Encapsulation (GRE) for user data tunneling between the AC and the Wireless Termination Point (WTP), and it uses the proposed standard Datagram Transport Layer Security [DTLS] for the control channel transport 🫶

SLAPP supports 4 modes of operation: 2 local-MAC modes and 2 split-MAC modes 🧚 STA control can be handled by the AC using native 802.11 frames that get encapsulated in SLAPP control packets across all modes. (Quick reminder, STA means a wireless station, which is usually a laptop 💻)

In the SLAPP local-MAC modes, user data frames can be bridged or tunneled back to the AC using GRE as 802.3 frames 🍓 In the split-MAC modes, user data always gets tunneled back to the AC as native 802.11 frames 💜 Encryption of user data can happen at either the AC or the WTP in split-MAC mode 🔐

4.3. CTP

"CAPWAP Tunneling Protocol" [CTP] stands out because it uses Simple Network Management Protocol (SNMP) to define configuration and management data, which then gets encapsulated in an encrypted control channel 🌈 CTP was originally designed as a local-MAC protocol, but the new version has split-MAC support too ✨ It was also designed from the very start to work with multiple wireless technologies, which is so iconic 👑

CTP defines information elements for management and control between the AC and WTP 🧠 Its control messages cover STA session state, configuration, and statistics 📊

In local-MAC mode, CTP doesn't forward any native wireless frames to the AC 🙅‍♀️ It specifies control messages for STA session activity, mobility, and radio frequency (RF) resource management between the AC and WTP 📶 In CTP's local-MAC mode, the integration function from the wireless network to 802.3 Ethernet happens at the WTP for all user data 🦋 User data can either be bridged at the WTP, or encapsulated as 802.3 frames in CTP packets at the WTP and tunneled to the AC 💖

CTP's split-MAC mode is defined as an extension of local-MAC mode 🧩 In CTP's version of split-MAC operation, wireless management frames get forwarded to the AC in their raw format 🛰️ User data frames can be bridged locally at the WTP, or they can be encapsulated in CTP packets and tunneled to the AC in their native wireless form 🌸

CTP gives you STA control abstraction, methods for extending the forwarding of multiple types of native wireless management frames, and lots of options for user data tunneling 🎀 Configuration management is an extension of SNMP, which makes CTP one of the most flexible of the proposed CAPWAP protocols 🏆 Hold up though, it defines new security and data tunneling mechanisms instead of leveraging existing standards 😬

4.4. WiCoP

"Wireless LAN Control Protocol" [WICOP] brings new discovery, configuration, and management for Wireless LAN (WLAN) systems 🌟 It defines a distinct discovery mechanism that also handles WTP-AC capabilities negotiation 🤝

WiCoP defines 802.11 Quality of Service (QoS) parameters 🎯 It also proposes using standard security and authentication methods like IPsec and Extensible Authentication Protocol (EAP) 🔑 The protocol still needs to get into detail about how those mentioned methods are explicitly used 📝 For interoperable implementations, it's critical to give users a detailed, unambiguous specification, periodt 💅

5. Security Considerations 🔐

Each of the candidate protocols has a Security Considerations section, along with its security properties 🛡️ The CAPWAP objectives document [OBJ] contains security-related requirements 📜 The evaluation team checked whether and how the candidate protocols implement the security features that the CAPWAP objectives require 🔍 BUT, and this is a big but 😭, this evaluation team is not a security team and did not perform a thorough security evaluation or tests 🙈 Any protocol coming out of the CAPWAP working group must go through an IETF security review in order to fully meet the objectives 🚨

6. Mandatory Objective Compliance Evaluation 📋

6.1. Logical Groups

LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

LWAPP

LWAPP has a control message called "Add WLAN" 🎀 The AC uses it to create a WLAN with a unique ID, which is its Service Set Identifier (SSID) 🆔 The WTPs in that WLAN each have their own Basic Service Set Identifiers (BSSIDs) 🌷 LWAPP meets this objective ✅

SLAPP

SLAPP explicitly supports 0-255 BSSIDs 💫

CTP

CTP implements a NETWORK_ID attribute, which is a wireless-technology-independent way of creating logical groups 🦋 CTP meets this objective ✅

WiCoP

WiCoP provides control tunnels to manage logical groups 🧚 There is one control tunnel for each logical group 💜 WiCoP meets this objective ✅

6.2. Traffic Separation

LWAPP:C, SLAPP:C, CTP:P, WiCoP:P

If a protocol distinguishes a data message from a control message, then it meets this objective 💅

LWAPP

LWAPP separates control messages from data messages using the "C-bit" 🔀 The C-bit is defined in the LWAPP transport header 📦 When the C-bit is equal to zero, the message is a data message. When the C-bit is equal to one, the message is a control message 🙌 So LWAPP meets this objective ✅

SLAPP

SLAPP encapsulates control using DTLS and, optionally, user data with GRE 🎀 Of particular note, SLAPP defines 4 "architecture modes" that set how user data is handled in relation to the AC 🌸 SLAPP is compliant with this objective ✅

CTP

CTP defines separate packet frame types for control and data 📦 However, the evaluation team could not find a way to configure the tunneling of user data, so it rated CTP as only partially compliant 😬 It looks like CTP would rely on SNMP MIB Object Identifiers (OIDs) for this function, but none were defined in the specification 🙈 Defining the necessary OIDs would make CTP fully compliant 💖

WiCoP

WiCoP provides for separation between control and data channels 🛤️ However, tunneling methods aren't explicitly described, so WiCoP only partially meets this objective 🥲

6.3. STA Transparency

LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

If a protocol doesn't indicate that a STA needs to know about the protocol, then this objective is met 🦋

The protocol must not define any message formats between STA and WTP/AC 🚫

LWAPP

LWAPP doesn't require a STA to be aware of LWAPP 🙌 No messages or protocol primitives are defined that the STA has to interact with beyond the 802.11 standard 📡 LWAPP is fully compliant 👑

SLAPP

SLAPP places no requirements on STA network elements 🌈 No messages or protocol primitives are defined that the STA has to interact with beyond the 802.11 standard ✨

CTP

CTP doesn't require a terminal to know CTP, so CTP meets this objective ✅

WiCoP

WiCoP doesn't require a terminal to know WiCoP, so WiCoP meets this objective ✅

6.4. Configuration Consistency

LWAPP:C, SLAPP:C, CTP:C, WiCoP:C

Since the goal is maintaining configurations for a large number of network elements involved in 802.11 wireless networks, the evaluation team would like to recommend that a token, key, or serial number be implemented for configuration verification 🔢

LWAPP

It's possible to obtain and verify all configurable values through LWAPP 🙌 Notably, LWAPP only needs "non-default" settings (defaults are specified by LWAPP) to be transmitted when performing configuration consistency checks 🧹 This behavior is explicitly specified in LWAPP, so LWAPP is compliant with this objective ✅

SLAPP

Numerous events and statistics are available to report configuration changes and WTP state 📈 SLAPP doesn't have any built-in abilities to minimize or optimize configuration consistency verification, but it is compliant with the objective ✅

CTP

CTP's use of SNMP makes configuration consistency checking straightforward 🎯 Where a MIB specifies it, you can take advantage of default values 💅

WICOP

The WiCoP configuration starts with an exchange of capability messages between the WTP and AC 🤝 After that, configuration control data is sent to the WTP 📨

WiCoP defines configuration values in groups of configuration data messages 🗂️ The protocol also supports configuration using MIB objects 🧩 To maintain data consistency, the WTP acknowledges each configuration message from the AC 💌 ✨

6.5. Firmware Trigger ✨

LWAPP:P, SLAPP:P, CTP:P, WiCoP:C 💅

okay so the evaluation team looked at this objective and decided that for full compliance, the protocol state machine has to be able to kick off the process of checking for and performing a firmware update independently of its other functions 🎀

many protocols only do a firmware check and update when the system starts up 🥱 this got a partial compliance rating. the team felt that only checking at startup was unnecessarily limiting, and that letting it happen at any point in the state machine didn't make the protocol any more complicated 🧠 letting the firmware update start while the device is in its running state gives you way more options for keeping the WTP's downtime low during an update 💖

for example, the firmware check and the download of the image over the network could happen while the WTP is running. once the file transfer is done, the WTP only has to reboot once to start running the new firmware image ✨ this could be a seriously big downtime win when the image is large, the link used to load the file is really slow, or the WTP takes ages to reboot 🐢

a protocol would only fail compliance if no method at all was specified for updating firmware. 😭

LWAPP

LWAPP only starts a firmware download from the WTP during the Join phase (when a WTP is first associating with an AC), and never at any other time 🙈 the AC can "trigger" the check and update indirectly by sending a reset message to the WTP. the reboot that follows then makes the WTP do a firmware check and update 🔄 LWAPP is only partially compliant because its firmware trigger can only be used in the startup phases of the state machine 🥲

SLAPP

SLAP has a firmware check and update procedure that runs when a WTP is first connecting to an AC 🔌 same deal here: the AC can only "trigger" it indirectly by sending a reset message to the WTP. SLAPP is partially compliant because its firmware trigger can only be used in the startup phases of the state machine 💅

CTP

the CTP state machine says the firmware upgrade procedure must be performed immediately after the authentication exchange, as defined in section 6.2 of [CTP] 🔐 BUT section 5.2.5 of [CTP] says the SW-Update-Req message MAY be sent by the AC 👀 which kinda implies that CTP could support an AC-triggered software update during the regular running state of the WTP 🤔 so CTP might be fully compliant, but the proposal needs to be clarified to get there 🫶

WiCoP

in WiCoP, a firmware update may be triggered any time in the active state, so WiCoP is fully compliant 👑 slay

6.6. Monitor and Exchange of System-wide Resource State 📊

LWAPP:C, SLAPP:C, CTP:P, WiCoP:C

the evaluation team focused on the protocols that provide 3 things relevant to statistics from WTPs: the ability to transport statistics, a minimum set of standard data, and the ability to extend what data can be reported or collected 🧁

LWAPP

statistics are sent by the WTP using an "Event Request" message 📨 LWAPP defines an 802.11 statistics message that covers 802.11 MAC layer properties. LWAPP is compliant ✅

SLAPP

WLAN statistics transport is handled over the control channel and encoded in SLAPP-defined TLVs called information elements 🧩 the 802.11 configuration and statistics information elements are listed in [SLAPP] 6.1.3.1. they're extendable and include vendor-specific extensions 💜 compliant!

CTP

CTP defines a control message called "CTP Stats-Notify" 📣 it carries statistics in the form of SNMP OIDs and gets sent from the WTP to the AC. this approach is novel because it leverages standard SNMP 🤯

section 5.3.10 of [CTP] recommends using 802.11 MIBs where they apply 📚 but the proposal admits that extra configuration and statistics information is needed and doesn't specify those MIB extensions 🙃 CTP needs to add these extensions to the proposal. also, this minimum set of statistics and configuration OIDs has to become requirements before it can fully meet the objective 🥺

WiCoP

the feedback control message sent by the WTP holds lots of statistics 📈 WiCoP specifies 15 statistics that the WTP needs to send to the AC. new versions of WiCoP can cover any new statistics the AC needs to monitor the WTP 🌈 WiCoP meets this objective, periodt 💅

6.7. Resource Control 🎀

LWAPP:C, SLAPP:P, CTP:P, WiCoP:P

the evaluation team read the resource control objective as meaning that the CAPWAP protocol has to map 802.11e QoS markings onto the wired network 🛣️ that mapping has to cover any encapsulation or tunneling of user data that CAPWAP defines. the team also agreed that CAPWAP should give an explicit capability to configure this mapping ⚙️ since most of the protocols only relied on the statically defined 802.11e mapping, most of them got a partial compliance rating 😬

LWAPP

LWAPP defines its own custom TLV structure, made of an 8-bit type or class of information value plus an extra 8-bit value that indexes a specific variable 🧩

LWAPP allows mobile station-based QoS configuration in each Add Mobile Request the AC sends to the WTP for each new mobile station that attaches 📲 packet prioritization is left up to the individual WTPs. 4 different QoS policies can be configured for each station to enforce 🍓 the Update Mobile QoS message element can change the QoS policy at the WTP for a given mobile station 🔁 LWAPP should support 8 QoS policies since that matches 802.11e, 802.1p and IP TOS, but for this objective, 4 classes is compliant ✅

overall, LWAPP conforms to the resource control objective 🥳 it enables QoS configuration and mapping. the control can be applied on a logical group basis, and it lets wireless traffic be flexibly mapped to the wired segment 🦋

SLAPP

okay so 802.11e does specify 802.1p and Differentiated Service Code Point (DSCP) mappings, but there's no explicit support for 802.11e in SLAPP 😭 SLAPP has to be updated to add 802.11e as one of the standard capabilities a WTP could support, and to specify a mechanism that lets you configure the mapping of the QoS classes 🛠️

CTP

CTP requires that the WTP and AC copy the QoS marking of user data into the data message encapsulation 📋 this mapping is done by the 1-byte policy field in the CTP Header 🧾 however, no configuration of QoS mapping other than copying the user data's existing markings is defined in CTP. it seems clear that SNMP could be used to make the mapping work differently, but no OIDs are defined that would make that possible 🙈 partial compliance for CTP on this one 🫠

WiCoP

Note: WiCoP's rating for the resource control objective has been upgraded from Failed to Partial. 🆙 after another look at the WiCoP protocol proposal, it was decided that the protocol partially meets the resource control objectives 🎉

WiCoP starts its QoS configuration with an 802.11e capability exchange between the WTP and AC 🤝 the QoS capabilities primitives ride along in the capability messages.

WiCoP defines the QoS-Value message, which carries 802.11e configuration parameters 💌 it's sent for each group the WTP supports. WiCoP doesn't give an explicit method for configuring DSCP tags and 802.1P precedence values 🙃 these parameters could be set through the SNMP OID configuration method, but WiCoP doesn't explicitly identify any specific MIBs 📉 overall, WiCoP partially meets the resource control CAPWAP objectives. to be fully compliant, the protocol needs to identify a clear method for configuring the 802.1p and DSCP mappings 🔑

6.8. Protocol Security 🔐

LWAPP:C, SLAPP:C, CTP:F, WiCoP:F

WiCoP has no out-of-the-ordinary NAT constraints either 🙌 a WTP could function in the hidden address space of a NAT'd network without any special configuration 🫧

WiCoP specifies access control in [WICOP] section 5.2.2 📖

8. Evaluation Summary and Conclusions ✨

okay bestie, this is the big summary moment 💅 check out Figure 1 (the section numbers match RFC 4564 [OBJ]) 🦋

 ---------------------------------------------------------------
| CAPWAP Evaluation              | LWAPP | SLAPP | CTP | WiCoP  |
|---------------------------------------------------------------|
| 5.1.1  Logical Groups          |    C  |   C   |  C  |   C    |
| 5.1.2  Traffic Separation      |    C  |   C   |  P  |   P    |
| 5.1.3  STA Transparency        |    C  |   C   |  C  |   C    |
| 5.1.4  Config Consistency      |    C  |   C   |  C  |   C    |
| 5.1.5  Firmware Trigger        |    P  |   P   |  P  |   C    |
| 5.1.6  Monitor System          |    C  |   C   |  P  |   C    |
| 5.1.7  Resource Control        |    C  |   P   |  P  |   P    |
| 5.1.8  Protocol Security       |    C  |   C   |  F  |   F    |
| 5.1.9  System Security         |    C  |   C   |  F  |   F    |
| 5.1.10 802.11i Consideration   |    C  |   C   |  F  |   P    |
|---------------------------------------------------------------|
| 5.1.11 Interoperability        |    C  |   C   |  C  |   C    |
| 5.1.12 Protocol Specifications |    C  |   P   |  P  |   P    |
| 5.1.13 Vendor Independence     |    C  |   C   |  C  |   C    |
| 5.1.14 Vendor Flexibility      |    C  |   C   |  C  |   C    |
| 5.1.15 NAT Traversal           |    C  |   C   |  C  |   C    |
|---------------------------------------------------------------|
| Desirable                                                     |
|---------------------------------------------------------------|
| 5.2.1  Multiple Authentication |    C  |   C   |  C  |   C    |
| 5.2.2  Future Wireless         |    C  |   C   |  C  |   C    |
| 5.2.3  New IEEE Requirements   |    C  |   C   |  C  |   C    |
| 5.2.4  Interconnection (IPv6)  |    C  |   C   |  C  |   C    |
| 5.2.5  Access Control          |    C  |   C   |  C  |   C    |
 ---------------------------------------------------------------

                         Figure 1: Summary Results

9. Protocol Recommendation 👑

okay so the proposals had SO many cool features 🌈 like, put them all together and you'd get a full-featured, flexible, and extensible CAPWAP protocol 😭 the most iconic ones are the ones that lean on existing standards wherever that's doable ✨ and honestly, the evaluation team's take is that a mix of everybody's best stuff = the best CAPWAP protocol. periodt 💅

the recommended features are below 🎀 a lot of the novel capabilities come from CTP, SLAPP, and WiCoP. BUT LWAPP has the most complete base protocol and is flexible enough to be extended or modified by the working group, so the team recommends using LWAPP as the basis for the CAPWAP protocol 💖

the evaluation team also wants the working group to carefully consider the following issues and recommended changes 🧚 they believe a more complete CAPWAP protocol will come out of addressing these issues and changes 🫶

9.1. High-Priority Recommendations Relevant to Mandatory Objectives

9.1.1. Information Elements

LWAPP's attribute value pair system meets the objectives as defined by the working group 🍓 however, it only has 8 bits assigned for attribute types, plus an additional 8 bits for a specific element within an attribute type 😬 the evaluation team strongly recommends assigning a larger number of bits for attribute types and information elements 🔥

9.1.2. Control Channel Security

LWAPP's security mechanisms look satisfactory and could serve CAPWAP going forward 💅 however, the evaluation team recommends adopting a standard security protocol for the control channel 🔐

there are several motivations for a standards-based security protocol, but the main downside of a new security protocol is that it will take longer and be harder to standardize than reusing an existing IETF standard 😭 first, a new security protocol will face a longer, slower approval process from the Security Area Directorate and the IESG 💀 the new CAPWAP security protocol will also need to pass several tests, including the following:

what is uniquely required by CAPWAP that isn't available from an existing standard protocol? how will CAPWAP's security protocol meet security area requirements for extensibility, like the ability to support future cipher suites and new key exchange methods? how does that ability compare to established security protocols that already have these capabilities? 🤔

these points keep getting more attention in the industry and in the IETF 👀 extensibility of key exchange methods and cipher suites is becoming an industry standard best practice 🌸 these issues are big topics in the IETF Security Area Advisory Group (SAAG) and the SecMech BOF, which were held during the 63rd IETF meeting 🎀

these issues could be nullified by adopting an appropriate existing standard security protocol 🦋 IPsec or DTLS could be a standards alternative to LWAPP's specification. DTLS is a UDP variant of Transport Layer Security (TLS) 💜 DTLS is relatively new, but TLS is a heavily used, tried-and-tested security protocol 👑

the evaluation team recommends that whatever security protocol gets specified for CAPWAP, its use cases must be described in detail ✨ LWAPP does a good job of this with its proposed, proprietary method. if an updated specification is developed, it should contain at least one mandatory authentication method and at least one mandatory cipher method 🫶 for example, pre-shared key and x.509 certificates could be specified as mandatory authentication methods, and Advanced Encryption Standard (AES) Counter Mode with CBC-MAC Protocol (CCMP) could be selected as a mandatory cipher 🔥

given the possibilities for code reuse, the industry's reliance on TLS, and the future of TLS, DTLS may be a wise alternative to a security method specific to CAPWAP 🌈 on top of that, using DTLS would likely expedite the approval of CAPWAP as a proposed standard, compared with using CAPWAP-specific security mechanisms 🚀

9.1.3. Data Tunneling Modes

9.1.3.1. Support for Local MAC User Data Tunneling

okay the data encapsulation issue is closely tied to the split- and local-MAC architectures 🧩 the split-MAC architecture requires some form of data tunneling. all the proposals except LWAPP also offer a method of tunneling in local-MAC mode 🙈 by local-MAC data tunneling, we mean tunneling user data as 802.3 Ethernet frames back to the AC from a WTP that is otherwise in local-MAC mode 🧚

tunneling data in local-MAC mode gives implementers a bunch of ways to innovate even while using a local-MAC architecture ✨ for example, functions like mobility, flexible user data encryption options, and fast handoffs can be enabled by tunneling user data back to an AC, or, as LWAPP defines it, a data termination endpoint that could be different from the AC 🦋 there are also special QoS or application-aware treatments of user data packets, like voice or video 🎀 plus, improved transparency and compatibility with future wireless technologies are possible when user data is encapsulated in a common format, such as 802.3, between the access point and the AC or other termination point in the network 💖

another possibility: if a native wireless MAC changes in the future, and a new WTP that supports this MAC change can also support a wireless MAC -> 802.3 integration function, then the wireless MAC layer change may stay transparent to an AC while still keeping many of the benefits that data tunneling brings 🌸

LWAPP does support a header for tunneled user data that contains layer 1 wireless information (Received Signal Strength Indication (RSSI) and Signal-to-Noise Ratio (SNR)) that is independent of the wireless layer 2 MAC 📡 innovations related to using RSSI and SNR at the AC may be kept even when 802.3 user data is tunneled across different wireless MACs 🌟

honestly, lots of other features could be created by innovative implementers using this method 🤯 however, LWAPP narrowly defines the local-MAC architecture to exclude the option of tunneling data frames back to the AC 😤 given the broad support for tunneling 802.3 data frames between the WTP and AC across all the proposals and existing proprietary industry implementations, the evaluation team strongly recommends that the working group consider adding a data tunneling mode for local-MAC to the LWAPP proposal, so it becomes part of the standard CAPWAP protocol 👑

9.1.3.2. Mandatory and Optional Tunneling Modes

if more than one tunneling mode becomes part of the CAPWAP protocol, the evaluation team recommends that the working group choose one method as mandatory and the other methods as optional 🎀 also, the CAPWAP protocol must implement the ability to negotiate which tunneling methods are supported through a capabilities exchange 🤝 this gives ACs and WTPs the freedom to implement a variety of modes while always having the option to fall back to a common mode 🦋

picking which mode(s) should be mandatory is a big decision 🥺 it may affect a lot of the choices implementers have to make with their hardware and software for both WTPs and ACs 💅 the evaluation team believes the working group should address this issue of local-MAC data tunneling and carefully choose which mode(s) should be mandatory 🫶

9.2. Additional Recommendations Relevant to Desirable Objectives

9.2.1. Access Control

abstraction of STA access control, like what CTP and WiCoP implement, is a valuable feature 🌟 it's fundamental to the operational capabilities of many types of wireless networks, not just 802.11 🌈 LWAPP implements station access control as an 802.11-specific function, by forwarding 802.11 control frames to the access controller 🙄 LWAPP has abstracted the STA Delete function out of the 802.11 binding, but the Add STA function is still part of the 802.11 binding 😬 it would be useful to implement the wireless MAC independent functions for adding a STA outside of the 802.11 binding 💜

9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling

LWAPP currently specifies layer 2 and layer 3 methods for data tunneling 🧩 the evaluation team believes the layer 2 method is redundant to the layer 3 method 🤷‍♀️ so the team recommends removing the layer 2 method encapsulation from the LWAPP protocol 🗑️✨

9.2.3. Data Encapsulation Standard

LWAPP's layer 3 data encapsulation meets the working group objectives 🎉 however, the evaluation team recommends using a standards-based protocol for encapsulating user data between the WTP and AC 🍓 GRE or Layer 2 Tunneling Protocol (L2TP) could make good candidates as standards-based encapsulation protocols for data tunneling 🦋

using a standard opens the door to code reuse, whether that's off-the-shelf microcode for processors, code modules you can buy for real-time operating systems, or open-source implementations for Unix-based systems 🛠️💖 plus, L2TP and GRE are designed to encapsulate multiple data types, which adds flexibility for supporting future wireless technologies 🌈

10. Normative References 📚

okay bestie, this is the shortlist of docs the spec leans on the hardest 🫶 you need these to really get it.

[802.11i]  IEEE Standard 802.11i, "Medium Access Control (MAC)
           Security Enhancements", July 2004.

[ARCH]     Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
           for Control and Provisioning of Wireless Access Points
           (CAPWAP)", RFC 4118, June 2005.

[OBJ]      Govindan, S., Ed., Cheng, H., Yao, ZH., Zhou, WH., and L.
           Yang, "Objectives for Control and Provisioning of Wireless
           Access Points (CAPWAP)", RFC 4564, July 2006.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, March 1997.

11. Informative References 🧚

these ones are the extra reading 💅 super helpful for context, but the spec doesn't need you to know them to get the main ideas.

[CTP]      Singh , I., Francisco, P., Pakulski , K., and F. Backes,
           "CAPWAP Tunneling Protocol (CTP)", Work in Progress, April
           2005.

[DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security", RFC 4347, April 2006.

[LWAPP]    Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams,
           M., Hares, S., and N. Cam Winget, "Light Weight Access
           Point Protocol (LWAPP)", Work in Progress, March 2005.

[RFC3127]  Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil,
           B., Stevens, M., and B. Wolff, "Authentication,
           Authorization, and Accounting: Protocol Evaluation", RFC
           3127, June 2001.

[SLAPP]    Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP :
           Secure Light Access Point Protocol", Work in Progress, May
           2005.

[WICOP]    Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
           "Wireless LAN Control Protocol (WiCoP)", Work in Progress,
           March 2005.

Authors' Addresses ✨

meet the squad who wrote this 🎀 here's how to reach each of them:

Darren P. Loher
Envysion, Inc.
2010 S. 8th Street
Boulder, CO  80302
USA

Phone: +1.303.667.8761
EMail: dplore@gmail.com


David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Anover, MA  01810-1008
USA

Phone: +1.978.684.1330
EMail: dnelson@enterasys.com


Oleg Volinsky
Colubris Networks, Inc.
200 West Street
Waltham, MA  02451
USA

Phone: +1.781.547.0329
EMail: ovolinsky@colubris.com


Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX  75075
USA

Phone: +1.972.509.5599
EMail: sarikaya@ieee.org

Full Copyright Statement 💜

okay so the legal part, but make it quick 😭 the copyright is held by The Internet Society (2006).

this document is covered by the rights, licenses and restrictions in BCP 78. except for what that BCP says, the authors keep all of their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🦋

the IETF doesn't take a side on whether any IPR claims about this tech are valid or how wide they reach, and it hasn't independently gone hunting for them either. if you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 🌸

any IPR disclosures sent to the IETF Secretariat, plus assurances of licenses, or the results of any attempt to get a general license or permission for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💖

Acknowledgement 🌈

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) ✨ thank you, IASA, you're iconic 👑

📦 where this page comes from

ietf: rfc4565 2006-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms