Network Working Group D. Loher
Request for Comments: 4565 Envysion, Inc.
Category: Informational D. Nelson
Enterasys Networks, Inc.
O. Volinsky
Colubris Networks, Inc.
B. Sarikaya
Huawei USA
July 2006
Network Working Group D. Loher
Request for Comments: 4565 Envysion, Inc.
Category: Informational D. Nelson
Enterasys Networks, Inc.
O. Volinsky
Colubris Networks, Inc.
B. Sarikaya
Huawei USA
July 2006
Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols
无线接入点（CAPWAP）协议候选控制和供应评估
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.
本文件记录了无线接入点控制和供应工作组（CAPWAP WG）评估小组的过程和结果。评估小组在2005年6月26日提交给工作组时审查了4份候选方案。
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
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
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
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 reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.
本文件记录了无线接入点控制和供应工作组（CAPWAP WG）评估小组的过程和结果。评估小组在2005年6月26日提交给工作组时审查了4份候选方案。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses terminology defined in RFC 4118 [ARCH], RFC 4564 [OBJ], and IEEE 802.11i [802.11i].
本文件使用RFC 4118[ARCH]、RFC 4564[OBJ]和IEEE 802.11i[802.11i]中定义的术语。
The process to be described here has been adopted from a previous evaluation in IETF [RFC3127]. The CAPWAP objectives in RFC 4564 [OBJ] were used to set the scope and direction for the evaluators and was the primary source of requirements. However, the evaluation team also used their expert knowledge and professional experience to consider how well a candidate protocol met the working group objectives.
此处描述的过程采用了IETF[RFC3127]中先前的评估。RFC 4564[OBJ]中的CAPWAP目标用于确定评估人员的范围和方向，是需求的主要来源。然而，评估小组也使用他们的专家知识和专业经验来考虑候选协议如何符合工作组目标。
For each of the 4 candidate protocols, the evaluation document editor assigned 2 team members to write evaluation briefs. One member was assigned to write a "Pro" brief and could take a generous interpretation of the proposal; this evaluator could grant benefit of doubt. A second evaluator was assigned to write a "Con" brief and was required to use strict criteria when performing the evaluation.
对于4个候选方案中的每一个，评估文档编辑器分配2名团队成员编写评估简报。一名成员被指派编写一份“赞成”的简报，可以对提案作出慷慨的解释；这个评估者可以给予怀疑的好处。另一名评估员被指派编写“Con”简报，并要求在执行评估时使用严格的标准。
The "Pro" and "Con" members independently evaluated how well the candidate protocol met each objective. Each objective was scored as an 'F' for failure, 'P' for partial, or 'C' for completely meeting the objective.
“赞成”和“反对”的成员独立评估候选方案达到每个目标的程度。每个目标得分为“F”表示失败，“P”表示部分目标，或“C”表示完全达到目标。
F - Failure to Comply
F-未能遵守
The evaluation team believes the proposal does not meet the objective. This could be due to the proposal completely missing any functionality towards the objective. A proposal could also receive an 'F' for improperly implementing the objective.
评估小组认为提案不符合目标。这可能是因为提案完全没有实现目标的任何功能。提案也可能因未正确实施目标而被判“F”。
P - Partial Compliance
P-部分顺应性
The proposal has some functionality that addresses the objective, but it is incomplete or ambiguous.
该提案具有一些针对目标的功能，但不完整或不明确。
C - Compliant
C兼容
The proposal fully specifies functionality meeting 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 4-person evaluation team held a teleconference for each candidate to discuss the briefs. One of the working group chairs was also present at the meeting in an advisory capacity. Each evaluator presented a brief with supporting details. The team discussed the issues and delivered a team rating for each objective. These discussions are documented in the meeting minutes. The team ratings are used for the compliance evaluation.
四人评估小组为每位候选人召开了电话会议，讨论简报。工作组主席之一也以咨询身份出席了会议。每位评估员都提交了一份简要说明，其中包含支持性细节。团队讨论了这些问题，并对每个目标进行了团队评分。这些讨论记录在会议记录中。团队评级用于合规性评估。
The candidate protocols were scored only on the information written in their draft. This means that a particular protocol might actually meet the specifics of a requirement, but if the proposal did not state, describe, or reference how that requirement was met, it might be scored lower.
候选方案仅根据草案中的信息评分。这意味着一个特定的协议实际上可能满足一个需求的具体情况，但是如果提案没有说明、描述或引用如何满足该需求，那么它的得分可能会更低。
Darren Loher, Roving Planet
达伦·洛赫，漫游星球
I am employed as the senior architect at Roving Planet, which writes network and security management software for wireless networks. I have over 11 years of commercial experience designing and operating networks. I have implemented and operated networks and network management systems for a university, large enterprises, and a major Internet service provider for over 4 years. I also have software development experience and have written web-based network and systems management tools including a system for managing a very large distributed DNS system. I have witnessed the IETF standards process for several years, my first event being IETF 28. I have rarely directly participated in any working group activities before this point. To my knowledge, my company has no direct relationship with any companies that have authored the CAPWAP protocol submissions.
我在Roving Planet担任高级架构师，该公司为无线网络编写网络和安全管理软件。我有超过11年的商业网络设计和运营经验。我为一所大学、大型企业和一家大型互联网服务提供商实施和运营网络和网络管理系统已经超过4年。我还拥有软件开发经验，并编写了基于web的网络和系统管理工具，包括用于管理大型分布式DNS系统的系统。几年来，我见证了IETF标准过程，我的第一个事件是IETF 28。我以前很少直接参加任何工作组的活动。据我所知，我的公司与任何编写CAPWAP协议的公司没有直接关系。
David Nelson, Enterasys
大卫·纳尔逊，企业
I am currently cochair of the RADEXT WG, AAA Doctor in O&M Area, and employed in the core router engineering group of my company. I have previously served on a protocol evaluation team in the AAA WG, and am a coauthor of RFC 3127 [RFC3127]. I was an active contributor in the IEEE 802.11i task group, and previously employed in the WLAN
我目前是RADEXT WG的联合主席，运维领域的AAA博士，受雇于我公司的核心路由器工程组。我之前曾在AAA工作组的一个方案评估团队中任职，并且是RFC 3127[RFC3127]的合著者。我是IEEE 802.11i任务组的积极贡献者，之前受雇于WLAN
engineering group of my company. I have had no participation in any of the submitted protocols. My company does have an OEM relationship with at least one company whose employees have coauthored one of the submissions, but I have no direct involvement with our WLAN product at this time.
我公司的工程组。我没有参与任何提交的协议。我的公司确实与至少一家公司有OEM关系，该公司的员工共同撰写了一份意见书，但我目前没有直接参与我们的WLAN产品。
Oleg Volinsky, Colubris Networks
Oleg Volinsky，Colubris网络公司
I am a member of the Enterprise group of Colubris Networks, a WLAN vendor. I have over 10 years of experience in design and development of network products from core routers to home networking equipment. Over years I have participated in various IETF groups. I have been a member of CAPWAP WG for over a year. In my current position I have been monitoring the developments of CAPWAP standards and potential integration of the resulting protocol into the company's products. I have not participated in any of the candidate protocol drafts. I have not worked for any of the companies whose staff authored any of the candidate protocols.
我是无线局域网供应商Colubris Networks企业集团的成员。我有超过10年的设计和开发网络产品的经验，从核心路由器到家庭网络设备。多年来，我参加了各种IETF小组。我已经成为CAPWAP工作组的成员一年多了。在我目前的职位上，我一直在监控CAPWAP标准的发展以及由此产生的协议与公司产品的潜在集成。我没有参与任何候选协议草案。我没有为任何一家公司工作过，这些公司的员工编写了任何候选协议。
Behcet Sarikaya, University of Northern British Columbia
Behcet Sarikaya，北英属哥伦比亚大学
I am currently Professor of Computer Science at UNBC. I have so far 5 years of experience in IETF as a member of mobile networking-related working groups. I have made numerous I-D contributions and am a coauthor of one RFC. I have submitted an evaluation draft (with Andy Lee) that evaluated LWAPP, CTP, and WiCoP. Also I submitted another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP, and SLAPP as transport. I also have research interests on next-generation access point/controller architectures. I have no involvement in any of the candidate protocol drafts, have not contributed any of the drafts. I have not worked in any of the companies whose staff has produced any of the candidate protocols.
我目前是UNBC的计算机科学教授。到目前为止，我作为移动网络相关工作组的成员，在IETF有5年的工作经验。我已经做出了许多I-D贡献，并且是一个RFC的合著者。我（与Andy Lee）提交了一份评估草案，对LWAPP、CTP和WiCoP进行了评估。我还提交了另一个草案（关于CAPWAPHP），它使用LWAPP、CTP、WiCoP和SLAPP作为传输。我还对下一代接入点/控制器体系结构感兴趣。我没有参与任何候选协议草案，也没有提交任何草案。我没有在任何一家公司工作过，这些公司的员工制定了任何候选协议。
The following proposals were submitted as proposals to the CAPWAP working group.
以下提案作为提案提交给CAPWAP工作组。
The "Light Weight Access Point Protocol" [LWAPP] was the first CAPWAP protocol originally submitted to Seamoby Working Group. LWAPP proposes original solutions for authentication and user data encapsulation as well as management and configuration information elements. LWAPP originated as a "split MAC" protocol, but recent changes have added local MAC support as well. LWAPP has received a security review from Charles Clancy of the University of Maryland Information Systems Security Lab.
“轻量级接入点协议”[LWAPP]是最初提交给Seamoby工作组的第一个CAPWAP协议。LWAPP为身份验证和用户数据封装以及管理和配置信息元素提出了原始解决方案。LWAPP最初是一种“分割MAC”协议，但最近的变化也增加了本地MAC支持。LWAPP已经收到了马里兰大学信息系统安全实验室Charles Clancy的安全审查。
LWAPP is the most detailed CAPWAP proposal. It provides a thorough specification of the discovery, security, and system management methods. LWAPP focuses on the 802.11 WLAN-specific monitoring and configuration. A key feature of LWAPP is its use of raw 802.11 frames that are tunneled back to the Access Controller (AC) for processing. In both local- and split-MAC modes, raw 802.11 frames are forwarded to the AC for management and control. In addition, in split-MAC mode, user data is tunneled in raw 802.11 form to the AC. While in concept, LWAPP could be used for other wireless technologies, LWAPP defines very few primitives that are independent of the 802.11 layer.
LWAPP是最详细的CAPWAP提案。它提供了发现、安全性和系统管理方法的全面规范。LWAPP专注于802.11 WLAN特定的监控和配置。LWAPP的一个关键功能是使用原始802.11帧，这些帧通过隧道传输回访问控制器（AC）进行处理。在本地和拆分MAC模式下，原始802.11帧被转发到AC进行管理和控制。此外，在拆分MAC模式下，用户数据以原始802.11形式通过隧道传输到AC。在概念上，LWAPP可用于其他无线技术，但LWAPP定义的原语很少独立于802.11层。
"Secure Light Access Point Protocol" [SLAPP] distinguishes itself with the use of well-known, established technologies such as Generic Routing Encapsulation (GRE) for user data tunneling between the AC and Wireless Termination Point (WTP) and the proposed standard Datagram Transport Layer Security [DTLS] for the control channel transport.
“安全光接入点协议”[SLAPP]与众所周知的、已建立的技术的使用相区别，例如用于AC和无线终端点（WTP）之间的用户数据隧道的通用路由封装（GRE）和用于控制信道传输的拟议标准数据报传输层安全[DTLS]。
4 modes of operation are supported, 2 local-MAC modes and 2 split-MAC modes. STA control may be performed by the AC using native 802.11 frames that are encapsulated in SLAPP control packets across all modes. (STA refers to a wireless station, typically a laptop.)
支持4种操作模式，2种本地MAC模式和2种拆分MAC模式。STA控制可由AC使用封装在所有模式的SLAP控制分组中的本机802.11帧来执行。（STA指无线电台，通常为笔记本电脑。）
In SLAPP local-MAC modes, user data frames may be bridged or tunneled back using GRE to the AC as 802.3 frames. In the split-MAC modes, user data is always tunneled back to the AC as native 802.11 frames. Encryption of user data may be performed at either the AC or the WTP in split-MAC mode.
在SLAPP本地MAC模式下，用户数据帧可以使用GRE桥接或隧道回AC as 802.3帧。在拆分MAC模式下，用户数据始终作为本机802.11帧通过隧道传回AC。用户数据的加密可以在分割MAC模式下在AC或WTP处执行。
"CAPWAP Tunneling Protocol" [CTP] distinguishes itself with its use of Simple Network Management Protocol (SNMP) to define configuration and management data that it then encapsulates in an encrypted control channel. CTP was originally designed as a local-MAC protocol but the new version has split-MAC support as well. In addition, CTP is clearly designed from the beginning to be compatible with multiple wireless technologies.
“CAPWAP隧道协议”[CTP]的独特之处在于它使用简单网络管理协议（SNMP）来定义配置和管理数据，然后将这些数据封装在加密的控制通道中。CTP最初设计为本地MAC协议，但新版本也提供了对MAC的支持。此外，CTP从一开始就被明确设计为兼容多种无线技术。
CTP defines information elements for management and control between the AC and WTP. CTP control messages are specified for STA session state, configuration, and statistics.
CTP定义了AC和WTP之间管理和控制的信息元素。为STA会话状态、配置和统计信息指定CTP控制消息。
In local-MAC mode, CTP does not forward any native wireless frames to the AC. CTP specifies control messages for STA session activity, mobility, and radio frequency (RF) resource management between the AC and WTP. CTP local-MAC mode specifies that the integration function from the wireless network to 802.3 Ethernet is performed at the WTP for all user data. User data may either be bridged at the WTP or encapsulated as 802.3 frames in CTP packets at the WTP and tunneled to the AC.
在本地MAC模式下，CTP不向AC转发任何本机无线帧。CTP为AC和WTP之间的STA会话活动、移动性和射频（RF）资源管理指定控制消息。CTP local MAC模式指定在WTP为所有用户数据执行从无线网络到802.3以太网的集成功能。用户数据可以在WTP处桥接，或者在WTP处封装为CTP分组中的802.3帧，并通过隧道传输到AC。
CTP's split-MAC mode is defined as an extension to local-MAC mode. In CTP's version of split-MAC operation, wireless management frames are forwarded in their raw format to the AC. User data frames may be bridged locally at the WTP, or they may be encapsulated in CTP packets and tunneled in their native wireless form to the AC.
CTP的分割MAC模式被定义为本地MAC模式的扩展。在CTP版本的分割MAC操作中，无线管理帧以其原始格式转发到AC。用户数据帧可以在WTP本地桥接，或者可以封装在CTP分组中，并以其本机无线形式隧道传输到AC。
CTP supplies STA control abstraction, methods for extending the forwarding of multiple types of native wireless management frames, and many options for user data tunneling. Configuration management is an extension of SNMP. This makes CTP one of the most flexible of the proposed CAPWAP protocols. However, it does define new security and data tunneling mechanisms instead of leveraging existing standards.
CTP提供STA控制抽象、扩展多种本机无线管理帧转发的方法，以及用户数据隧道的许多选项。配置管理是SNMP的扩展。这使得CTP成为提议的CAPWAP协议中最灵活的协议之一。然而，它确实定义了新的安全性和数据隧道机制，而不是利用现有的标准。
"Wireless LAN Control Protocol" [WICOP] introduces new discovery, configuration, and management of Wireless LAN (WLAN) systems. The protocol defines a distinct discovery mechanism that integrates WTP-AC capabilities negotiation.
“无线局域网控制协议”[WICOP]介绍了无线局域网（WLAN）系统的新发现、配置和管理。该协议定义了一种独特的发现机制，该机制集成了WTP-AC协商功能。
WiCoP defines 802.11 Quality of Service (QoS) parameters. In addition, the protocol proposes to use standard security and authentication methods such as IPsec and Extensible Authentication Protocol (EAP). The protocol needs to go into detail with regards to explicit use of the above-mentioned methods. To ensure interoperable protocol implementations, it is critical to provide users with detailed unambiguous specification.
WiCoP定义了802.11服务质量（QoS）参数。此外，该协议建议使用标准的安全和身份验证方法，如IPsec和可扩展身份验证协议（EAP）。协议需要详细说明上述方法的明确使用。为了确保可互操作的协议实现，向用户提供详细的明确规范是至关重要的。
Each of the candidate protocols has a Security Considerations section, as well as security properties. The CAPWAP objectives document [OBJ] contains security-related requirements. The evaluation team has considered if and how the candidate protocols implement the security features required by the CAPWAP objectives. However, this evaluation team is not a security team and has not
每个候选协议都有一个安全注意事项部分以及安全属性。CAPWAP目标文件[OBJ]包含安全相关要求。评估小组已考虑候选协议是否以及如何实现CAPWAP目标所需的安全功能。但是，该评估团队不是安全团队，也没有
performed a thorough security evaluation or tests. Any protocol coming out of the CAPWAP working group must undergo an IETF security review in order to fully meet the objectives.
进行了彻底的安全评估或测试。CAPWAP工作组制定的任何协议都必须经过IETF安全审查，以完全达到目标。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP provides a control message called "Add WLAN". This message is used by the AC to create a WLAN with a unique ID, i.e., its Service Set Identifier (SSID). The WTPs in this WLAN have their own Basic Service Set Identifiers (BSSIDs). LWAPP meets this objective.
LWAPP提供一条名为“添加WLAN”的控制消息。AC使用此消息创建具有唯一ID（即其服务集标识符（SSID））的WLAN。此WLAN中的WTP具有自己的基本服务集标识符（BSSID）。LWAPP符合这一目标。
SLAPP
拍打
SLAPP explicitly supports 0-255 BSSIDs.
SLAP显式支持0-255个BSSID。
CTP
CTP
CTP implements a NETWORK_ID attribute that allows a wireless-technology-independent way of creating logical groups. CTP meets this objective.
CTP实现了一个网络ID属性，该属性允许以与无线技术无关的方式创建逻辑组。CTP符合这一目标。
WiCoP
女巫
WiCoP provides control tunnels to manage logical groups. There is one control tunnel for each logical group. WiCoP meets this objective.
WiCoP提供控制隧道来管理逻辑组。每个逻辑组有一个控制通道。WiCoP实现了这一目标。
LWAPP:C, SLAPP:C, CTP:P, WiCoP:P
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
LWAPP separates control messages from data messages using "C-bit". "C-bit" is defined in the LWAPP transport header. When C-bit is equal to zero, the message is a data message. When C-bit is equal to one, the message is a control message. So, LWAPP meets this objective.
LWAPP使用“C位”将控制消息与数据消息分离。“C位”在LWAPP传输头中定义。当C位等于零时，该消息为数据消息。当C位等于1时，该消息为控制消息。因此，LWAPP符合这一目标。
SLAPP
拍打
The SLAPP protocol encapsulates control using DTLS and optionally, user data with GRE. Of particular note, SLAPP defines 4 "architecture modes" that define how user data is handled in relation to the AC. SLAPP is compliant with this objective.
SLAPP协议使用DTL封装控件，还可以选择使用GRE封装用户数据。特别值得注意的是，SLAP定义了4种“架构模式”，它们定义了如何处理与AC相关的用户数据。SLAP符合这一目标。
CTP
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 opted to rate CTP as only partially compliant. It appears that 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.
CTP为控制和数据定义了单独的数据包帧类型。然而，评估团队无法找到配置用户数据隧道的方法，因此选择将CTP评定为仅部分符合。CTP似乎依赖SNMP MIB对象标识符（OID）来实现此功能，但规范中未定义任何OID。定义必要的OID将使CTP完全兼容。
WiCoP
女巫
WiCoP provides for separation between control and data channels. However, tunneling methods are not explicitly described. Because of this, WiCoP partially meets this objective.
WiCoP提供了控制通道和数据通道之间的分离。然而，没有明确描述隧道方法。因此，WiCoP部分实现了这一目标。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
If a protocol does not indicate that STA needs to know about the protocol, then this objective is met.
如果协议未表明STA需要了解协议，则满足此目标。
The protocol must not define any message formats between STA and WTP/AC.
协议不得定义STA和WTP/AC之间的任何消息格式。
LWAPP
LWAPP
LWAPP does not require a STA to be aware of LWAPP. No messages or protocol primitives are defined that the STA must interact with beyond the 802.11 standard. LWAPP is fully compliant.
LWAPP不要求STA知道LWAPP。除了802.11标准之外，没有定义STA必须与之交互的消息或协议原语。LWAPP完全兼容。
SLAPP
拍打
SLAPP places no requirements on STA network elements. No messages or protocol primitives are defined that the STA must interact with beyond the 802.11 standard.
SLAPP对STA网络元素没有任何要求。必须与标准STA.11之外定义的任何消息进行交互。
CTP
CTP
CTP does not require a terminal to know CTP. So, CTP meets this objective.
CTP不要求终端知道CTP。因此，CTP符合这一目标。
WiCoP
女巫
WiCoP does not require a terminal to know WiCoP. So, WiCoP meets this objective.
WiCoP不要求终端知道WiCoP。因此，WiCoP符合这一目标。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
Given the objective of 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 for configuration be implemented for configuration verification.
鉴于维护802.11无线网络中涉及的大量网络元件的配置的目标，评估小组建议实施配置令牌、密钥或序列号，以进行配置验证。
LWAPP
LWAPP
It is possible to obtain and verify all configurable values through LWAPP. Notably, LWAPP takes an approach that only "non-default" settings (defaults are specified by LWAPP) are necessary for transmission when performing configuration consistency checks. This behavior is explicitly specified in LWAPP. LWAPP is compliant with this objective.
可以通过LWAPP获取并验证所有可配置值。值得注意的是，LWAPP采用的方法是，在执行配置一致性检查时，传输只需要“非默认”设置（默认值由LWAPP指定）。此行为在LWAPP中明确指定。LWAPP符合这一目标。
SLAPP
拍打
Numerous events and statistics are available to report configuration changes and WTP state. SLAPP does not have any built-in abilities to minimize or optimize configuration consistency verification, but it is compliant with the objective.
许多事件和统计信息可用于报告配置更改和WTP状态。SLAPP没有任何内置功能来最小化或优化配置一致性验证，但它符合目标。
CTP
CTP
CTP's use of SNMP makes configuration consistency checking straightforward. Where specified in a MIB, one could take advantage of default values.
CTP对SNMP的使用使得配置一致性检查变得简单。在MIB中指定的位置，可以利用默认值。
WICOP
女巫
The WiCoP configuration starts with exchange of capability messages between the WTP and AC. Next, configuration control data is sent to the WTP.
WiCoP配置从WTP和AC之间的能力消息交换开始。接下来，配置控制数据被发送到WTP。
WiCoP defines configuration values in groups of configuration data messages. In addition, the protocol supports configuration using MIB objects. To maintain data consistency, each configuration message from the AC is acknowledged by the WTP.
WiCoP在配置数据消息组中定义配置值。此外，该协议支持使用MIB对象进行配置。为保持数据一致性，WTP确认来自AC的每个配置消息。
LWAPP:P, SLAPP:P, CTP:P, WiCoP:C
LWAPP:P, SLAPP:P, CTP:P, WiCoP:C
The evaluation team considered the objective and determined that for full compliance, the protocol state machine must support the ability to initiate the process for checking and performing a firmware update independently of other functions.
评估团队考虑了该目标，并确定，为了完全符合要求，协议状态机必须能够独立于其他功能启动检查和执行固件更新的过程。
Many protocols perform a firmware check and update procedure only on system startup time. This method received a partial compliance. The team believed that performing the firmware check only at startup time was unnecessarily limiting and that allowing it to occur at any time in the state machine did not increase complexity of the protocol. Allowing the firmware update process to be initiated during the running state allows more possibilities for minimizing downtime of the WTP during the firmware update process.
许多协议仅在系统启动时执行固件检查和更新过程。该方法得到了部分遵从性。该团队认为，仅在启动时执行固件检查是不必要的限制，允许它在状态机中的任何时间发生并不会增加协议的复杂性。允许在运行状态下启动固件更新过程，允许在固件更新过程中尽可能减少WTP的停机时间。
For example, the firmware check and download of the image over the network could potentially occur while the WTP was in a running state. After the file transfer was complete, the WTP could be rebooted just once and begin running the new firmware image. This could pose a meaningful reduction in downtime when the firmware image is large, the link for loading the file is very slow, or the WTP reboot time is long.
例如，当WTP处于运行状态时，可能会通过网络进行固件检查和映像下载。文件传输完成后，WTP可以重新启动一次并开始运行新的固件映像。当固件映像较大、加载文件的链接非常慢或WTP重新启动时间较长时，这可能会显著减少停机时间。
A protocol would only fail compliance if no method was specified for updating of firmware.
只有在没有指定固件更新方法的情况下，协议才会失败。
LWAPP
LWAPP
Firmware download is initiated by the WTP only at the Join phase (when a WTP is first associating with an AC) and not at any other time. The firmware check and update could be "triggered" indirectly by the AC by sending a reset message to the WTP. The resulting reboot would cause a firmware check and update to be performed. LWAPP is partially compliant because its firmware trigger can only be used in the startup phases of the state machine.
固件下载仅在加入阶段（当WTP首次与AC关联时）由WTP启动，而不是在任何其他时间。AC可通过向WTP发送重置消息间接“触发”固件检查和更新。由此产生的重新启动将导致执行固件检查和更新。LWAPP部分兼容，因为其固件触发器只能在状态机的启动阶段使用。
SLAPP
拍打
SLAP includes a firmware check and update procedure that is performed when a WTP is first connecting to an AC. The firmware check and update can only be "triggered" indirectly by the AC 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.
SLAP包括在WTP首次连接到AC时执行的固件检查和更新程序。固件检查和更新只能由AC通过向WTP发送重置消息间接“触发”。SLAPP部分兼容，因为其固件触发器只能在状态机的启动阶段使用。
CTP
CTP
The CTP state machine specifies that the firmware upgrade procedure must be performed immediately after the authentication exchange as defined in section 6.2 of [CTP]. However, section 5.2.5 of [CTP] states that the SW-Update-Req message MAY be sent by the AC. This indirectly implies that CTP could support an AC-triggered software update during the regular running state of the WTP. So it seems that CTP might be fully compliant, but the proposal should be clarified for full compliance.
CTP状态机规定，固件升级程序必须在[CTP]第6.2节中定义的身份验证交换后立即执行。然而，[CTP]第5.2.5节规定，SW Update Req消息可由AC发送。这间接意味着CTP可在WTP正常运行状态期间支持AC触发的软件更新。因此，似乎CTP可能完全合规，但应澄清该提案以确保完全合规。
WiCoP
女巫
In WiCoP, firmware update may be triggered any time in the active state, so WiCoP is fully compliant.
在WiCoP中，固件更新可以在活动状态下随时触发，因此WiCoP完全兼容。
LWAPP:C, SLAPP:C, CTP:P, WiCoP:C
LWAPP:C, SLAPP:C, CTP:P, WiCoP:C
The evaluation team focused on the protocols supplying 3 methods relevant to statistics from WTPs: The ability to transport statistics, a minimum set of standard data, and the ability to extend what data could be reported or collected.
评估小组将重点放在提供与WTP统计数据相关的3种方法的协议上：传输统计数据的能力、最低标准数据集以及扩展可报告或收集的数据的能力。
LWAPP
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.
WTP使用“事件请求”消息发送统计信息。LWAPP定义了一条802.11统计信息，该信息涵盖802.11 MAC层属性。LWAPP是兼容的。
SLAPP
拍打
WLAN statistics transport is supplied via the control channel and encoded in SLAPP-defined TLVs called information elements. 802.11 configuration and statistics information elements are supplied in [SLAPP] 6.1.3.1. These are extendable and include vendor-specific extensions.
WLAN统计数据传输通过控制通道提供，并在SLAP定义的TLV（称为信息元素）中编码。802.11配置和统计信息元素在[SLAPP]6.1.3.1中提供。这些是可扩展的，包括特定于供应商的扩展。
CTP
CTP
CTP defines a control message called "CTP Stats-Notify". This control message contains statistics in the form of SNMP OIDs and is sent from the WTP to AC. This approach is novel because it leverages the use of standard SNMP.
CTP定义了一个名为“CTP Stats Notify”的控制消息。此控制消息包含SNMP OID形式的统计信息，并从WTP发送到AC。此方法很新颖，因为它利用了标准SNMP的使用。
Section 5.3.10 of [CTP] recommends the use of 802.11 MIBs where applicable. However, the proposal acknowledges that additional configuration and statistics information is required, but does not specify these MIB extensions. CTP needs to add these extensions to the proposal. Also, this minimum set of statistics and configuration OIDs must become requirements in order to fully meet the objective.
[CTP]第5.3.10节建议在适用的情况下使用802.11 MIB。但是，该提案承认需要额外的配置和统计信息，但没有指定这些MIB扩展。CTP需要将这些扩展添加到提案中。此外，为了完全满足目标，这组最小的统计信息和配置OID必须成为需求。
WiCoP
女巫
The feedback control message sent by the WTP contains many statistics. WiCoP specifies 15 statistics that the WTP needs to send to the AC. New versions of WiCoP can address any new statistics that the AC needs to monitor the WTP. WiCoP meets this objective.
WTP发送的反馈控制消息包含许多统计信息。WiCoP指定了WTP需要发送给AC的15个统计数据。WiCoP的新版本可以处理AC需要监控WTP的任何新统计数据。WiCoP实现了这一目标。
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
The evaluation team interpreted the resource control objective to mean that the CAPWAP protocol must map 802.11e QoS markings to the wired network. This mapping must include any encapsulation or tunneling of user data defined by the CAPWAP protocol. Of particular note, the evaluation team agreed that the CAPWAP protocol should supply an explicit capability to configure this mapping. Since most of the protocols relied only on the 802.11e statically defined mapping, most received a partial compliance.
评估小组将资源控制目标解释为，CAPWAP协议必须将802.11e QoS标记映射到有线网络。此映射必须包括CAPWAP协议定义的用户数据的任何封装或隧道。特别值得注意的是，评估小组同意，CAPWAP协议应提供配置此映射的明确功能。由于大多数协议仅依赖于802.11e静态定义的映射，因此大多数协议都得到了部分遵从性。
LWAPP
LWAPP
LWAPP defines its own custom TLV structure, which consists of an 8-bit type or class of information value and an additional 8-bit value that indexes to a specific variable.
LWAPP定义了自己的自定义TLV结构，该结构由一个8位类型或类别的信息值和一个附加的8位值组成，该值对特定变量进行索引。
LWAPP allows the mobile station-based QoS configuration in each Add Mobile Request sent by AC to WTP for each new mobile station that is attached. Packet prioritization is left to individual WTPs. 4 different QoS policies for each station to enforce can be configured. Update Mobile QoS message element can be used to change QoS policy at the WTP for a given mobile station. LWAPP should support 8 QoS policies as this matches 802.11e 802.1p and IP TOS, but for this objective, 4 classes is compliant.
LWAPP允许在AC向WTP发送的每个附加新移动站的每个添加移动请求中进行基于移动站的QoS配置。数据包优先级由各个WTP决定。可以为每个要实施的站点配置4种不同的QoS策略。更新移动QoS消息元素可用于在WTP处更改给定移动站的QoS策略。LWAPP应支持8个QoS策略，因为这与802.11e 802.1p和IP TOS相匹配，但为此目标，4个类是兼容的。
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 also enables the wireless traffic to be flexibly mapped to the wired segment.
总体而言，LWAPP符合资源控制目标。它支持QoS配置和映射。该控制可以在逻辑组的基础上应用，并且还使得无线业务能够灵活地映射到有线段。
SLAPP
拍打
Although 802.11e specifies 802.1p and Differentiated Service Code Point (DSCP) mappings, there is no explicit support for 802.11e in SLAPP. SLAPP must be updated to add 802.11e as one of the standard capabilities that a WTP could support and specify a mechanism that would allow configuration of mapping the QoS classes.
尽管802.11e指定了802.1p和区分服务代码点（DSCP）映射，但SLAP中没有对802.11e的明确支持。必须更新SLAP，将802.11e添加为WTP可以支持的标准功能之一，并指定允许配置映射QoS类的机制。
CTP
CTP
CTP requires that the WTP and AC copy the QoS marking of user data to the data message encapsulation. This mapping is accomplished by the CTP Header's 1-byte policy field. However, no configuration of QoS mapping other than copying the user data's already existing markings is defined in CTP. It seems clear that SNMP could be used to configure the mapping to occur differently, but no OIDs are defined that would enable this. Partial compliance is assigned to CTP for this objective.
CTP要求WTP和AC将用户数据的QoS标记复制到数据消息封装中。此映射由CTP标头的1字节策略字段完成。但是，CTP中没有定义除了复制用户数据已有标记之外的QoS映射配置。很明显，可以使用SNMP来配置不同的映射，但是没有定义能够实现这一点的OID。部分合规性分配给CTP以实现此目标。
WiCoP
女巫
Note: WiCoP rating for resource control objectives has been upgraded from Failed to Partial. After an additional review of the WiCoP protocol proposal, it was determined that the protocol partially meets resource control objectives.
注：资源控制目标的WiCoP评级已从失败升级为部分。在对WiCoP协议提案进行额外审查后，确定该协议部分满足资源控制目标。
WiCoP protocol starts its QoS configuration with 802.11e capability exchange between the WTP and AC. The QoS capabilities primitives are included in the capability messages.
WiCoP协议通过WTP和AC之间的802.11e能力交换开始其QoS配置。QoS能力原语包含在能力消息中。
WiCoP defines the QoS-Value message that contains 802.11e configuration parameters. This is sent for each group supported by the WTP. WiCoP does not provide an explicit method for configuration of DSCP tags and 802.1P precedence values. It is possible to configure these parameters through SNMP OID configuration method, but WiCoP does not explicitly identify any specific MIBs. Overall, WiCoP partially meets resource control CAPWAP objectives. In order to be fully compliant with the given objective, the protocol needs to identify a clear method to configure 802.1p and DSCP mappings.
WiCoP定义包含802.11e配置参数的QoS值消息。这是为WTP支持的每个组发送的。WiCoP没有为DSCP标签和802.1P优先级值的配置提供明确的方法。可以通过SNMP OID配置方法配置这些参数，但WiCoP没有明确标识任何特定的MIB。总体而言，WiCoP部分满足资源控制CAPWAP目标。为了完全符合给定的目标，协议需要确定一种明确的方法来配置802.1p和DSCP映射。
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
For the purposes of the protocol security objective, the evaluation team primarily considered whether or not the candidate protocols implement the security features required by the CAPWAP objectives. Please refer to the Security Considerations section of this document.
出于协议安全目标的目的，评估团队主要考虑候选协议是否实现CAPWAP目标所需的安全功能。请参阅本文档的安全注意事项部分。
LWAPP
LWAPP
It appears that the security mechanisms, including the key management portions in LWAPP, are correct. One third-party security review has been performed. However, further security review is warranted since a CAPWAP-specific key exchange mechanism is defined. LWAPP is compliant with the objective.
似乎安全机制（包括LWAPP中的密钥管理部分）是正确的。已经进行了一次第三方安全审查。但是，由于定义了CAPWAP特定的密钥交换机制，因此需要进行进一步的安全审查。LWAPP符合目标。
SLAPP
拍打
The SLAPP protocol implements authentication of the WTP by the AC using the DTLS protocol. This behavior is defined in both the discovery process and the 802.11 control process. SLAPP allows mutual and asymmetric authentication. SLAPP also gives informative examples of how to properly use the authentication. SLAPP should add another informative example for authentication of the AC by the WTP. SLAPP is compliant with the objective.
SLAP协议使用DTLS协议实现AC对WTP的身份验证。此行为在发现过程和802.11控制过程中都有定义。SLAPP允许相互和非对称身份验证。SLAPP还提供了如何正确使用身份验证的示例。SLAP应添加另一个信息示例，用于WTP对AC进行身份验证。SLAPP符合目标。
CTP
CTP
The original presentation at IETF63 of the preliminary findings of the evaluation team reported that CTP failed this objective. This was on the basis of asymmetric authentication not being supported by CTP. This was due to a misunderstanding of what was meant by asymmetric authentication by the evaluation team. The definitions of the terminology used in [OBJ] were clarified on the CAPWAP mailing list. CTP in fact does implement a form of asymmetric authentication through the use of public keys.
评估小组最初在IETF63上的初步调查结果报告称，CTP未能实现这一目标。这是基于CTP不支持的不对称身份验证。这是因为评估小组对非对称认证的含义存在误解。[OBJ]中使用的术语定义已在CAPWAP邮件列表中阐明。事实上，CTP确实通过使用公钥实现了一种形式的非对称身份验证。
However, CTP still fails to comply with the objective for two reasons:
然而，CTP仍然未能达到目标，原因有两个：
First, CTP does not mutually derive session keys. Second, CTP does not perform explicit mutual authentication because the 2 parties authenticating do not confirm the keys.
首先，CTP不会相互派生会话密钥。其次，CTP不执行显式相互身份验证，因为身份验证的两方不确认密钥。
WiCoP
女巫
There is not enough specific information to implement WiCoP protocol security features. Although in concept EAP and IPsec make sense, there is no explicit description on how these methods would be used.
没有足够的具体信息来实现WiCoP协议安全功能。虽然EAP和IPsec在概念上是有意义的，但对于如何使用这些方法没有明确的描述。
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP
LWAPP
LWAPP wraps all control and management communication in its authenticated and encrypted control channel. LWAPP does not seem particularly vulnerable to Denial of Service (DoS). LWAPP should make a recommendation that the Join method be throttled to reduce the impact of DoS attacks against it. Use of an established security mechanism such as IPsec would be preferred. However, LWAPP's independent security review lent enough confidence to declare LWAPP compliant with the objective.
LWAPP将所有控制和管理通信封装在其经过身份验证和加密的控制通道中。LWAPP似乎并不特别容易受到拒绝服务（DoS）的攻击。LWAPP应建议限制Join方法，以减少DoS攻击对其的影响。最好使用已建立的安全机制，如IPsec。然而，LWAPP的独立安全审查为宣布LWAPP符合目标提供了足够的信心。
SLAPP
拍打
SLAPP is compliant due to wrapping all control and management communication in DTLS. SLAPP also recommends measures to protect against discovery request DoS attacks. DTLS has undergone security review and has at least one known implementation outside of SLAPP. At the time of this writing, DTLS is pending proposed standard status in the IETF.
由于将所有控制和管理通信包装在DTLS中，因此SLAP是兼容的。SLAP还建议采取措施防止发现请求DoS攻击。DTLS已经过安全审查，并且在SLAP之外至少有一个已知的实现。在撰写本文时，DTLS正在IETF中等待拟定的标准状态。
CTP
CTP
CTP introduces a new, unestablished mechanism for AC-to-WTP authentication. For complete compliance, use of an established security mechanism with detailed specifications for its use in CTP is preferred. Alternatively, a detailed security review could be performed. CTP does not point out or recommend or specify any DoS attack mitigation requirements against Reg-Req and Auth-Req floods, such as a rate limiter. Because CTP received an 'F' on its protocol security objective, it follows that system-wide security must also be rated 'F'.
CTP为AC到WTP身份验证引入了一种新的、未建立的机制。为了完全符合要求，最好使用已建立的安全机制以及在CTP中使用的详细规范。或者，可以进行详细的安全审查。CTP没有针对Reg Req和Auth Req洪水指出、建议或指定任何DoS攻击缓解要求，例如速率限制器。由于CTP的协议安全目标为“F”，因此系统范围的安全性也必须为“F”。
WiCoP
女巫
WiCop does not address DoS attack threats. Also, as with the protocol security objective, the protocol needs to explicitly describe its tunnel and authentication methods.
WiCop不解决DoS攻击威胁。此外，与协议安全目标一样，协议需要明确描述其隧道和身份验证方法。
LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
LWAPP
LWAPP
LWAPP explicitly defines mechanisms for handling 802.11i in its modes with encryption terminated at the WTP. In order to accomplish this, the AC sends the Pairwise Transient Key (PTK) using the encrypted control channel to the WTP using the Add Mobile message. When encryption is terminated at the AC, there are no special requirements. LWAPP is compliant.
LWAPP明确定义了在WTP终止加密的模式下处理802.11i的机制。为了实现这一点，AC使用加密控制信道将成对瞬态密钥（PTK）发送到使用添加移动消息的WTP。当加密在AC处终止时，没有特殊要求。LWAPP是兼容的。
SLAPP
拍打
SLAPP defines a control message to send the PTK and Group Temporal Key (GTK) to the WTP when the WTP is the encryption endpoint. This control message is carried on the DTLS protected control channel. SLAPP is compliant.
SLAPP定义了一条控制消息，当WTP是加密端点时，该消息将PTK和组临时密钥（GTK）发送到WTP。此控制消息在DTLS保护的控制通道上传输。SLAPP是兼容的。
CTP
CTP
CTP lacks a specification for a control message to send 802.11i PTK and GTK keys to a WTP when the WTP is an encryption endpoint. Based on this, CTP fails compliance for this objective. This requirement could be addressed either by defining new control channel information elements or by simply defining SNMP OIDs. The transport of these OIDs would be contained in the secure control channel and therefore protected.
当WTP是加密端点时，CTP缺少向WTP发送802.11i PTK和GTK密钥的控制消息规范。基于此，CTP未能实现这一目标。可以通过定义新的控制通道信息元素或简单地定义SNMP OID来满足此要求。这些OID的传输将包含在安全控制通道中，因此受到保护。
WiCoP
女巫
WiCoP lacks documentation on how to handle 4-way handshake. The case for encryption at the AC needs clarification.
WiCoP缺乏关于如何处理4向握手的文档。AC的加密案例需要澄清。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP supports both split- and local-MAC architectures and is therefore compliant to the letter of the objectives. LWAPP is particularly rich in its support of the split-MAC architecture. However, LWAPP's support of local-MAC is somewhat limited and could be expanded. LWAPP is lacking a mode that allows local-MAC data
LWAPP支持拆分和本地MAC架构，因此符合目标书。LWAPP对拆分MAC架构的支持尤其丰富。然而，LWAPP对本地MAC的支持有限，可以扩展。LWAPP缺少允许本地MAC数据的模式
frames to be tunneled back to the AC. A discussion of possible extensions and issues is discussed in the recommendations section of this evaluation.
框架通过隧道返回AC。本评估的建议部分讨论了可能的扩展和问题。
SLAPP
拍打
SLAPP is compliant.
SLAPP是兼容的。
CTP
CTP
CTP is compliant.
CTP是合规的。
WiCoP
女巫
WiCoP is compliant.
WiCoP是合规的。
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP
LWAPP
LWAPP is nearly fully documented. Only a few sections are noted as incomplete. Detailed descriptions are often given to explain the purpose of the protocol primitives defined that should encourage interoperable implementations.
LWAPP几乎有完整的文档记录。只有少数章节被认为是不完整的。通常会给出详细的描述来解释定义的协议原语的目的，这些原语应该鼓励可互操作的实现。
SLAPP
拍打
SLAPP is largely implementable from its specification. It contains enough information to perform an interoperable implementation for its basic elements; however, additional informative references or examples should be provided covering use of information elements, configuring multiple logical groups, and so on.
SLAPP在很大程度上可以从其规范中实现。它包含足够的信息，可以对其基本元素执行可互操作的实现；但是，应提供额外的信息参考或示例，包括信息元素的使用、配置多个逻辑组等。
CTP
CTP
As noted earlier, there are a few areas where CTP lacks a complete specification, primarily due to the lack of specific MIB definitions.
如前所述，CTP在一些领域缺乏完整的规范，主要原因是缺乏特定的MIB定义。
WiCoP
女巫
Due to the lack of specific tunnel specifications and authentication specifications, WiCoP is only partially compliant.
由于缺乏特定的隧道规范和身份验证规范，WiCoP仅部分兼容。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP is compliant.
LWAPP是兼容的。
SLAPP
拍打
SLAPP is compliant.
SLAPP是兼容的。
CTP
CTP
CTP is compliant.
CTP是合规的。
WiCoP
女巫
WiCoP is compliant.
WiCoP是合规的。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP is compliant.
LWAPP是兼容的。
SLAPP
拍打
SLAPP is compliant.
SLAPP是兼容的。
CTP
CTP
CTP is compliant.
CTP是合规的。
WiCoP
女巫
WiCoP is compliant.
WiCoP是合规的。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP may require special considerations due to it carrying the IP address of the AC and data termination points in the payload of encrypted control messages. To overcome Network Address Translation (NAT), static NAT mappings may need to be created at the NAT'ing device if the AC or data termination points addresses are translated from the point of view of the WTP. A WTP should be able to function in the hidden address space of a NAT'd network.
LWAPP可能需要特别考虑，因为它在加密控制消息的有效载荷中承载AC的IP地址和数据终止点。为了克服网络地址转换（NAT），如果从WTP的角度转换AC或数据端点地址，则可能需要在NAT设备上创建静态NAT映射。WTP应该能够在NAT网络的隐藏地址空间中运行。
SLAPP
拍打
SLAPP places no out-of-the-ordinary constraints regarding NAT. A WTP could function in the hidden address space of a NAT'd network without any special configuration.
SLAPP并没有设置关于NAT的异常约束。WTP可以在NAT网络的隐藏地址空间中运行，无需任何特殊配置。
CTP
CTP
CTP places no out-of-the-ordinary constraints regarding NAT. A WTP could function in the hidden address space of a NAT'd network without any special configuration.
CTP对NAT并没有超出常规的限制。WTP可以在NAT网络的隐藏地址空间中运行，无需任何特殊配置。
WiCoP
女巫
WiCoP places no out-of-the-ordinary constraints regarding NAT. A WTP could function in the hidden address space of a NAT'd network without any special configuration.
WiCoP并没有对NAT设置异常约束。WTP可以在NAT网络的隐藏地址空间中运行，无需任何特殊配置。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP allows for multiple STA authentication mechanisms.
LWAPP允许多个STA身份验证机制。
SLAPP
拍打
SLAPP does not constrain other authentication techniques from being deployed.
SLAPP不限制部署其他身份验证技术。
CTP
CTP
CTP supports multiple STA authentication mechanisms.
CTP支持多种STA身份验证机制。
WiCoP
女巫
WiCoP allows for multiple STA authentication mechanisms.
WiCoP允许多个STA身份验证机制。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP could be used for other wireless technologies. However, LWAPP defines very few primitives that are independent of the 802.11 layer.
LWAPP可用于其他无线技术。然而，LWAPP定义了很少几个独立于802.11层的原语。
SLAPP
拍打
SLAPP could be used for other wireless technologies. However, SLAPP defines very few primitives that are independent of the 802.11 layer.
SLAPP可以用于其他无线技术。然而，SLAPP定义了很少几个独立于802.11层的原语。
CTP
CTP
CTP supplies STA control abstraction, methods for extending the forwarding of multiple types of native wireless management frames, and many options for user data tunneling. Configuration management is an extension of SNMP, to which new MIBs could, in concept, be easily plugged in. This helps makes CTP a particularly flexible proposal for supporting future wireless technologies. In addition, CTP has already defined multiple wireless protocol types in addition to 802.11.
CTP提供STA控制抽象、扩展多种本机无线管理帧转发的方法，以及用户数据隧道的许多选项。配置管理是SNMP的扩展，从概念上讲，新的MIB可以很容易地插入SNMP。支持无线CTP技术有助于实现未来的灵活性。此外，除了802.11之外，CTP已经定义了多种无线协议类型。
WiCoP
女巫
WiCoP could be used for other wireless technologies.
WiCoP可用于其他无线技术。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP's extensive use of native 802.11 frame forwarding allows it to be transparent to many 802.11 changes. It, however, shifts the burden of adapting MAC layer changes to the packet processing capabilities of the AC.
LWAPP广泛使用本机802.11帧转发，使其对许多802.11更改透明。然而，它将适应MAC层变化的负担转移到AC的分组处理能力。
SLAPP
拍打
SLAPP's use of native 802.11 frames for control and management allows SLAPP a measure of transparency to changes in 802.11. Because SLAPP also supports a mode that tunnels user data as 802.3 frames, it has additional architectural options for adapting to changes on the wireless infrastructure.
SLAPP使用本机802.11帧进行控制和管理，使SLAPP能够对802.11中的更改进行透明测量。由于SLAPP还支持将用户数据隧道化为802.3帧的模式，因此它具有额外的体系结构选项以适应无线基础设施的变化。
CTP
CTP
CTP has perhaps the greatest ability to adapt to changes in IEEE requirements. Architecturally speaking, CTP has several options available for adapting to change. SNMP OIDs are easily extended for additional control and management functions. Native wireless frames can be forwarded directly to the AC if necessary. Wireless frames can be bridged to 802.3 frames and tunneled back to the AC to protect the AC from changes at the wireless MAC layer. These options allow many possible ways to adapt to change of the wireless MAC layer.
CTP也许具有最大的能力来适应IEEE要求的变化。从架构上讲，CTP有几个选项可用于适应变化。SNMP OID易于扩展以实现额外的控制和管理功能。如有必要，本机无线帧可以直接转发到AC。无线帧可以桥接到802.3帧并通过隧道传输回AC，以保护AC不受无线MAC层变化的影响。这些选项允许许多可能的方式来适应无线MAC层的变化。
WiCoP
女巫
Because WiCoP uses 802.11 frames for the data transport, it is transparent to most IEEE changes. Any new IEEE requirements may need new configuration and new capability messages between the WTP and AC. The AC would need to be modified to handle new 802.11 control and management frames.
由于WiCoP使用802.11帧进行数据传输，因此它对大多数IEEE更改是透明的。任何新的IEEE要求可能需要WTP和AC之间的新配置和新功能消息。AC需要修改以处理新的802.11控制和管理帧。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP explicitly defines measures for accommodating IPv6. LWAPP is more sensitive to this in part because it carries IP addresses in two control messages.
LWAPP明确定义了适应IPv6的措施。LWAPP对此更加敏感，部分原因是它在两条控制消息中携带IP地址。
SLAPP
拍打
SLAPP is transparent to the interconnection layer. DTLS and GRE will both operate over IPv6.
SLAPP对互连层是透明的。DTLS和GRE都将在IPv6上运行。
CTP
CTP
CTP is transparent to the interconnection layer. CTP should be able to operate over IPv6 without any changes.
CTP对互连层是透明的。CTP应该能够在IPv6上运行，而无需任何更改。
WiCoP
女巫
WiCoP is transparent to the interconnection layer and should be able to operate over IPv6 without changes.
WiCoP对互连层是透明的，应该能够在IPv6上运行，而无需更改。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP
LWAPP uses native 802.11 management frames forwarded to the AC for the purpose of performing STA access control. WTPs are authenticated in LWAPP's control protocol Join phase.
LWAPP使用转发到AC的本机802.11管理帧来执行STA访问控制。WTP在LWAPP的控制协议加入阶段进行身份验证。
SLAPP
拍打
SLAPP has support for multiple authentication methods for WTPs. In addition, SLAPP can control STA access via 802.11 management frames forwarded to the AC or via SLAPP's information element primitives.
SLAP支持WTP的多种身份验证方法。此外，SLAP可以通过转发给AC的802.11管理帧或通过SLAP的信息元素原语来控制STA访问。
CTP
CTP
CTP specifies STA access control primitives.
CTP指定STA访问控制原语。
WiCoP
女巫
WiCoP specifies access control in [WICOP] section 5.2.2.
WiCoP在[WiCoP]第5.2.2节中规定了访问控制。
See Figure 1 (section numbers correspond to RFC 4564 [OBJ]).
参见图1（截面编号对应于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 |
---------------------------------------------------------------
---------------------------------------------------------------
| 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
图1：汇总结果
The proposals presented offer a variety of novel features that together would deliver a full-featured, flexible, and extensible CAPWAP protocol. The most novel of these features leverage existing standards where feasible. It is this evaluation team's opinion that a mix of the capabilities of the proposals will produce the best CAPWAP protocol.
所提出的方案提供了多种新颖的功能，这些功能将共同提供功能齐全、灵活且可扩展的CAPWAP协议。这些功能中最新颖的是在可行的情况下利用现有标准。该评估小组认为，提案的综合能力将产生最佳的CAPWAP协议。
The recommended features are described below. Many of these novel capabilities come from CTP and SLAPP and WiCoP. However, LWAPP has the most complete base protocol and is flexible enough to be extended or modified by the working group. We therefore recommend that LWAPP be used as the basis for the CAPWAP protocol.
推荐的功能如下所述。许多新功能来自CTP、SLAPP和WiCoP。然而，LWAPP拥有最完整的基本协议，并且足够灵活，可以由工作组进行扩展或修改。因此，我们建议将LWAPP用作CAPWAP协议的基础。
The evaluation team recommends that the working group carefully consider the following issues and recommended changes. The evaluation team believes that a more complete CAPWAP protocol will be delivered by addressing these issues and changes.
评估小组建议工作组仔细考虑以下问题并建议更改。评估小组认为，通过解决这些问题和变化，将提供更完整的CAPWAP协议。
LWAPP's attribute value pair system meets the objectives as defined by the working group. However, it has only 8 bits assigned for attribute types, with an additional 8 bits for a specific element within an attribute type. The evaluation team strongly recommends that a larger number of bits be assigned for attribute types and information elements.
LWAPP的属性-值对系统符合工作组定义的目标。但是，它只为属性类型分配了8位，为属性类型中的特定元素分配了额外的8位。评估小组强烈建议为属性类型和信息元素分配更多的位。
LWAPP's security mechanisms appear satisfactory and could serve CAPWAP going forward. However, the evaluation team recommends adoption of a standard security protocol for the control channel.
LWAPP的安全机制似乎令人满意，可以为CAPWAP的发展提供服务。但是，评估小组建议对控制通道采用标准安全协议。
There are several motivations for a standards-based security protocol, but the primary disadvantage of a new security protocol is that it will take longer and be more difficult to standardize than reusing an existing IETF standard. First, a new security protocol will face a longer, slower approval processes from the Security Area Directorate and the IESG. The new CAPWAP security protocol will need to pass several tests including the following:
基于标准的安全协议有多种动机，但新安全协议的主要缺点是，与重用现有IETF标准相比，标准化所需时间更长，难度更大。首先，新的安全协议将面临来自安全领域理事会和IESG的更长、更慢的审批流程。新的CAPWAP安全协议需要通过多项测试，包括以下测试：
What is uniquely required by CAPWAP that is not available from an existing standard protocol? How will CAPWAP's security protocol meet security area requirements for extensibility, such as the ability to support future cipher suites and new key exchange methods? How does this ability compare to established security protocols that have these capabilities?
CAPWAP唯一需要的是什么，而现有标准协议无法提供？CAPWAP的安全协议如何满足安全领域对扩展性的要求，例如支持未来密码套件和新密钥交换方法的能力？与具有这些功能的已建立安全协议相比，该功能如何？
Points such as these are continually receiving more attention in the industry and in the IETF. Extensibility of key exchange methods and cipher suites are becoming industry standard best practices. These issues are important topics in the IETF Security Area Advisory Group (SAAG) and the SecMech BOF, held during the 63rd IETF meeting.
此类问题在业界和IETF中不断受到更多关注。密钥交换方法和密码套件的可扩展性正在成为行业标准的最佳实践。这些问题是第63次IETF会议期间举行的IETF安全区域咨询小组（SAAG）和SecMech BOF的重要议题。
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 presents a UDP variant of Transport Layer Security (TLS). Although DTLS is relatively new, TLS is a heavily used, tried-and-tested security protocol.
通过采用适当的协议，可以消除现有的安全问题。IPsec或DTLS可以作为LWAPP规范的替代标准。DTLS提供了传输层安全性（TLS）的UDP变体。虽然DTLS相对较新，但TLS是一种被大量使用、尝试和测试的安全协议。
The evaluation team recommends that whatever security protocol is 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 and 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.
评估小组建议，无论为CAPWAP指定了何种安全协议，都必须详细描述其用例。LWAPP通过其建议的专有方法在这方面做得很好。如果制定了更新的规范，则应至少包含一种强制认证和密码方法。例如，可以将预共享密钥和x.509证书指定为强制身份验证方法，并且可以选择使用CBC-MAC协议（CCMP）的高级加密标准（AES）计数器模式作为强制密码。
Given the possibilities for code reuse, industry reliance on TLS, and the future for TLS, DTLS may be a wise alternative to a security method specific to CAPWAP. In addition, use of DTLS would likely expedite the approval of CAPWAP as a proposed standard over the use of CAPWAP-specific security mechanisms.
考虑到代码重用的可能性、行业对TLS的依赖以及TLS的未来，DTL可能是CAPWAP特定安全方法的明智选择。此外，使用DTL可能会加快批准CAPWAP，将其作为使用CAPWAP特定安全机制的拟议标准。
The issue of data encapsulation is closely related to the split- and local-MAC architectures. The split-MAC architecture requires some form of data tunneling. All the proposals except LWAPP offer a method of tunneling in local-MAC mode as well. By local-MAC data tunneling, we mean the tunneling of user data as 802.3 Ethernet frames back to the AC from a WTP that is otherwise in local-MAC mode.
数据封装问题与拆分和本地MAC架构密切相关。拆分MAC体系结构需要某种形式的数据隧道。除LWAPP之外的所有方案也提供了本地MAC模式下的隧道方法。通过本地MAC数据隧道，我们指的是将用户数据作为802.3以太网帧从处于本地MAC模式的WTP传输回AC。
Tunneling data in local-MAC mode offers the ability for implementers to innovate in several ways even while using a local-MAC architecture. For example, functions such as mobility, flexible user data encryption options, and fast handoffs can be enabled through tunneling of user data back to an AC, or as LWAPP defines, a data termination endpoint, which could be different from the AC. In addition, there are special QoS or application-aware treatments of user data packets such as voice or video. Improved transparency and compatibility with future wireless technologies are also possible when encapsulating user data in a common format, such as 802.3, between the access point and the AC or other termination point in the network.
本地MAC模式下的隧道数据为实现者提供了以多种方式进行创新的能力，即使在使用本地MAC体系结构时也是如此。例如，移动、灵活的用户数据加密选项和快速切换等功能可以通过将用户数据隧道传输回AC或LWAPP定义的数据终端来实现，这可能不同于AC。此外，对用户数据包（如语音或视频）有特殊的QoS或应用程序感知处理。当在接入点和网络中的AC或其他终端点之间以诸如802.3之类的公共格式封装用户数据时，也可以提高透明度和与未来无线技术的兼容性。
Another possibility is when a native wireless MAC changes in the future, if 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 remain transparent to an AC and still maintain many of the benefits that data tunneling can bring.
另一种可能性是，当本机无线MAC将来发生变化时，如果支持此MAC变化的新WTP也可以支持无线MAC->802.3集成功能，则无线MAC层变化可能对AC保持透明，并且仍然保持数据隧道可以带来的许多好处。
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 the use of RSSI and SNR at the AC may be retained even when tunneling 802.3 user data across different wireless MACs.
LWAPP确实支持隧道用户数据的报头，该报头包含独立于无线第2层MAC的第1层无线信息（接收信号强度指示（RSSI）和信噪比（SNR））。即使在通过不同的无线mac对802.3用户数据进行隧道传输时，也可以保留与在AC处使用RSSI和SNR相关的创新。
It is likely that many other features could be created by innovative implementers using this method. However, LWAPP narrowly defines the local-MAC architecture to exclude an 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 a data tunneling mode for local-MAC be added to the LWAPP proposal and become part of the standard CAPWAP protocol.
创新的实现者可能会使用这种方法创建许多其他特性。然而，LWAPP狭义地定义了本地MAC架构，以排除将数据帧隧道传输回AC的选项。鉴于在所有提案和现有专有行业实施中广泛支持WTP和AC之间的802.3数据帧隧道传输，评估小组强烈建议工作组考虑将本地MAC的数据隧道模式添加到LWAPP建议中，并成为标准CAPWAP协议的一部分。
If more than one tunneling mode is part of the CAPWAP protocol, the evaluation team recommends that the working group choose one method as mandatory and other methods as optional. In addition, the CAPWAP protocol must implement the ability to negotiate which tunneling methods are supported through a capabilities exchange. This allows ACs and WTPs freedom to implement a variety of modes but always have the option of falling back to a common mode.
如果CAPWAP协议中包含多个隧道模式，评估小组建议工作组选择一种方法作为强制性方法，其他方法作为可选方法。此外，CAPWAP协议必须实现通过功能交换协商支持哪些隧道方法的能力。这允许ACs和WTPs自由地实现各种模式，但始终可以选择退回到公共模式。
The choice of which mode(s) should be mandatory is an important decision and may impact many decisions implementers have to make with their hardware and software choices for both WTPs and ACs. The evaluation team believes that the working group should address this issue of local-MAC data tunneling and carefully choose which mode(s) should be mandatory.
选择哪种模式是强制性的是一项重要决策，可能会影响实施者对WTP和ACs的硬件和软件选择所做的许多决策。评估小组认为，工作组应解决本地MAC数据隧道问题，并仔细选择强制模式。
Abstraction of STA access control, such as that implemented in CTP and WiCoP, stands out as a valuable feature as it is fundamental to the operational capabilities of many types of wireless networks, not just 802.11. LWAPP implements station access control as an 802.11-
STA访问控制的抽象，例如CTP和WiCoP中实现的访问控制，是一个有价值的特性，因为它是许多类型无线网络（而不仅仅是802.11）的操作能力的基础。LWAPP作为802.11实现站点访问控制-
specific function via forwarding of 802.11 control frames to the access controller. LWAPP has abstracted the STA Delete function out of the 802.11 binding. However, the Add STA function is 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.
通过将802.11控制帧转发至接入控制器的特定功能。LWAPP已将STA Delete函数从802.11绑定中抽象出来。但是，添加STA功能是802.11绑定的一部分。在802.11绑定之外添加STA时，实现与无线MAC无关的功能将非常有用。
LWAPP currently specifies layer 2 and layer 3 methods for data tunneling. The evaluation team believes that the layer 2 method is redundant to the layer 3 method. The team recommends that the layer 2 method encapsulation be removed from the LWAPP protocol.
LWAPP目前指定数据隧道的第2层和第3层方法。评估小组认为，第2层方法与第3层方法相比是多余的。团队建议从LWAPP协议中删除第2层方法封装。
LWAPP's layer 3 data encapsulation meets the working group objectives. However, the evaluation team recommends the use of a standards-based protocol for encapsulation of 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.
LWAPP的第3层数据封装符合工作组的目标。然而，评估小组建议使用基于标准的协议来封装WTP和AC之间的用户数据。GRE或第2层隧道协议（L2TP）可以作为数据隧道的基于标准的封装协议。
Using a standard gives the opportunity for code reuse, whether it is off-the-shelf microcode for processors, code modules that can be purchased for real-time operating systems, or open-source implementations for Unix-based systems. In addition, L2TP and GRE are designed to encapsulate multiple data types, increasing flexibility for supporting future wireless technologies.
使用标准提供了代码重用的机会，无论是用于处理器的现成微码、可购买用于实时操作系统的代码模块，还是用于基于Unix的系统的开源实现。此外，L2TP和GRE设计用于封装多种数据类型，增加了支持未来无线技术的灵活性。
[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC) Security Enhancements", July 2004.
[802.11i]IEEE标准802.11i，“媒体访问控制（MAC）安全增强”，2004年7月。
[ARCH] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[ARCH]Yang，L.，Zerfos，P.，和E.Sadot，“无线接入点控制和供应（CAPWAP）的体系结构分类”，RFC 4118，2005年6月。
[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.
[OBJ]Govindan，S.，Ed.，Cheng，H.，Yao，ZH.，Zhou，WH.，和L.Yang，“无线接入点（CAPWAP）的控制和供应目标”，RFC 4564，2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes, "CAPWAP Tunneling Protocol (CTP)", Work in Progress, April 2005.
[CTP]Singh，I.，Francisco，P.，Pakulski，K.，和F.Backes，“CAPWAP隧道协议（CTP）”，正在进行的工作，2005年4月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[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.
[LWAPP]Calhoun，P.，O'Hara，B.，Kelly，S.，Suri，R.，Williams，M.，Hares，S.，和N.Cam Winget，“轻型接入点协议（LWAPP）”，正在进行的工作，2005年3月。
[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.
[RFC3127]密顿、圣约翰、巴克利、纳尔逊、帕蒂尔、史蒂文斯和沃尔夫，“认证、授权和会计：协议评估”，RFC 3127，2001年6月。
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP : Secure Light Access Point Protocol", Work in Progress, May 2005.
[SLAPP]Narasimhan，P.，Harkins，D.，和S.Ponnuswamy，“SLAPP：安全光接入点协议”，正在进行的工作，2005年5月。
[WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng, "Wireless LAN Control Protocol (WiCoP)", Work in Progress, March 2005.
[WICOP]Iino，S.，Govindan，S.，Sugiura，M.，和H.Cheng，“无线局域网控制协议（WICOP）”，正在进行的工作，2005年3月。
Authors' Addresses
作者地址
Darren P. Loher Envysion, Inc. 2010 S. 8th Street Boulder, CO 80302 USA
Darren P.Loher Envysion，Inc.2010美国科罗拉多州博尔德南八街，邮编80302
Phone: +1.303.667.8761
EMail: dplore@gmail.com
Phone: +1.303.667.8761
EMail: dplore@gmail.com
David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Anover, MA 01810-1008 USA
David B.Nelson Enterasys Networks，Inc.美国马萨诸塞州安诺威市Minuteman路50号01810-1008
Phone: +1.978.684.1330
EMail: dnelson@enterasys.com
Phone: +1.978.684.1330
EMail: dnelson@enterasys.com
Oleg Volinsky Colubris Networks, Inc. 200 West Street Waltham, MA 02451 USA
Oleg Volinsky Colubris Networks，Inc.美国马萨诸塞州沃尔瑟姆西街200号，邮编02451
Phone: +1.781.547.0329
EMail: ovolinsky@colubris.com
Phone: +1.781.547.0329
EMail: ovolinsky@colubris.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Behcet Sarikaya Huawei USA 1700 Alma Dr.Suite 100 Plano，TX 75075 USA
Phone: +1.972.509.5599
EMail: sarikaya@ieee.org
Phone: +1.972.509.5599
EMail: sarikaya@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。