RFC4565 日本語訳
4565 Evaluation of Candidate Control and Provisioning of WirelessAccess Points (CAPWAP) Protocols. D. Loher, D. Nelson, O. Volinsky,B. Sarikaya. July 2006. (Format: TXT=62929 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Loherがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4565年のEnvysion Inc.カテゴリ: 情報のD.ネルソンEnterasysはInc.B.Sarikaya Huawei米国2006年7月にInc.O.Volinsky Colubrisネットワークをネットワークでつなぎます。
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).
Copyright(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.
このドキュメントは工程履歴です、そして、Controlの調査結果とWireless Access Points作業部会(CAPWAP WG)の評価のProvisioningは組になります。 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. 序論…3 1.1. このドキュメントで中古のコンベンション…3 1.2. 用語…3 2. 記述を処理してください…3 2.1. 格付け…3 3. メンバー声明…4 4. 提案とハイライトについて議定書の中で述べてください…5 4.1. LWAPP…5 4.2. SLAPP…6 4.3. CTP…6 4.4. WiCoP…7
Loher, et al. Informational [Page 1] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[1ページ]のRFC4565評価
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. セキュリティ問題…7 6. 義務的な客観的な承諾評価…8 6.1. 論理的なグループ…8 6.2. トラフィック分離…8 6.3. STA透明…9 6.4. 構成の一貫性…10 6.5. ファームウェア引き金…11 6.6. システム全体のリソース状態のモニターと交換…12 6.7. リソースコントロール…13 6.8. セキュリティについて議定書の中で述べてください…15 6.9. システム全体のセキュリティ…16 6.10. 802.11 i問題…17 6.11. 相互運用性…17 6.12. 仕様を議定書の中で述べてください…18 6.13. ベンダー独立…19 6.14. ベンダーの柔軟性…19 6.15. NAT縦断…20 7. 望ましい客観的な承諾評価…20 7.1. 複数の認証…20 7.2. 将来の無線技術…21 7.3. 新しいIEEE要件…21 7.4. インタコネクト(IPv6)…22 7.5. コントロールにアクセスしてください…23 8. 評価概要と結論…24 9. 推薦について議定書の中で述べてください…24 9.1. 義務的な目的に関連している高優先度推薦…25 9.1.1. 情報要素…25 9.1.2. チャンネルセキュリティを制御してください…25 9.1.3. データトンネリングモード…26 9.2. 望ましい目的に関連している追加推薦…27 9.2.1. コントロールにアクセスしてください…27 9.2.2. データトンネリングのための層の2カプセル化の取り外し…28 9.2.3. データカプセル化規格…28 10. 標準の参照…29 11. 有益な参照…29
1. Introduction
1. 序論
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.
このドキュメントは工程履歴です、そして、Controlの調査結果とWireless Access Points作業部会(CAPWAP WG)の評価のProvisioningは組になります。 2005年6月26日にワーキンググループにそれらを提出したとき、評価チームは4つの候補プロトコルを見直しました。
Loher, et al. Informational [Page 2] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[2ページ]のRFC4565評価
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
This document uses terminology defined in RFC 4118 [ARCH], RFC 4564 [OBJ], and IEEE 802.11i [802.11i].
このドキュメントはRFC4118[ARCH]、RFC4564[OBJ]、およびIEEE 802.11i[802.11i]で定義された用語を使用します。
2. Process Description
2. プロセス記述
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]での前の評価から採用されました。 RFC4564[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人のチームメンバーを選任しました。 1人のメンバーが、「プロ」という要約を書くために割り当てられて、提案の寛大な解釈を取ることができました。 この評価者は疑問の利益を与えることができました。 2番目の評価者が、「まやかし」という要約を書くために選任されて、評価を実行するとき、厳しい評価基準を使用するのに必要でした。
2.1. Ratings
2.1. 格付け
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.
「プロ」と「まやかし」メンバーは、候補プロトコルが各目的をどれくらいよく満たしたかを独自に評価しました。 各目的が失敗、'P'のために'F'として得点された、部分的である、または、目的を完全に満たすための'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.
提案には、目的を扱う何らかの機能性がありますが、それは、不完全であるか、またはあいまいです。
Loher, et al. Informational [Page 3] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[3ページ]のRFC4565評価
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.
各候補者が概要について議論するように、4人の評価チームは電子会議を保持しました。 また、ワーキンググループいすのひとりもミーティングに顧問の資格で存在していました。 各評価者は詳細をサポートするのに要約を提示しました。 チームは、各目的のために問題に取り組んで、チーム格付けを提供しました。 これらの議論は議事録に記録されます。 チーム格付けは承諾評価に使用されます。
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.
候補プロトコルは彼らの草稿で書かれた情報だけで得点されました。 これは、特定のプロトコルが実際に要件の詳細を満たすかもしれないことを意味しますが、提案がその必要条件がどう満たされたかに述べもしませんし、説明もしませんし、参照をつけもしないなら、それは、より低く得点されるでしょうに。
3. Member Statements
3. メンバー声明
Darren Loher, Roving Planet
惑星を流浪させるダーレンLoher
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で雇われます。(Roving Planetはネットワークとセキュリティ管理にワイヤレス・ネットワークのためのソフトウェアを書きます)。 私には、ネットワークを設計して、経営しているという商業経験の11年以上があります。 私は、大学、大企業、および主要なインターネット接続サービス業者のために4年間以上ネットワークとネットワーク管理システムを実装して、運用しています。 私は、また、ソフトウェア開発経験を持っていて、非常に大きい分配されたDNSシステムを管理するシステムを含む書かれたウェブを拠点とするネットワークとシステム管理ツールを持っています。 私の最初のイベントがIETF28であり私は数年間IETF標準化過程を目撃しています。 私はめったに直接このポイント前の少しのワーキンググループ活動にも参加していません。 私が知っている限り、私の会社には、CAPWAPプロトコル差出を書いたどんな会社との直接の因果関係も全くありません。
David Nelson, Enterasys
デヴィッド・ネルソン、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、OのAAAの医師、およびM Areaを共同議長を務めさせて、私の会社のコアルータ工学グループで雇われます。 私は、以前にAAA WGでプロトコル評価チームの委員となって、RFC3127[RFC3127]の共著者です。 私はIEEE 802.11i任務群と、以前にWLANで採用している活発な貢献者でした。
Loher, et al. Informational [Page 4] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[4ページ]のRFC4565評価
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.
私の会社のグループを設計します。 私は提出されたプロトコルのいずれにも参加を全く持っていません。 私の会社には、従業員が差出の1つについて共同執筆した少なくとも1つの会社とのOEM関係がありますが、私はこのとき、私たちのWLAN製品に直接的な関与を全く持っていません。
Oleg Volinsky, Colubris Networks
オレーグ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のエンタープライズグループのWLANベンダーのメンバーです。 私には、デザインの10年間以上の経験とネットワーク製品のコアルータからホームネットワーク設備までの開発があります。 何年間もにわたって、私は様々なIETFグループに参加しています。 私は1年間以上のCAPWAP WGのメンバーです。 現在の地位では、私は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のコンピュータScienceの教授です。 モバイルネットワークのメンバーがワーキンググループを関係づけたので、私には、今までのところ、IETFの5年間の経験があります。 私は、頻繁なI-D貢献をして、1RFCの共著者です。 私はLWAPP、CTP、およびWiCoPを評価した評価草稿(アンディ・リーがいる)を提出しました。 また、私は輸送としてLWAPP、CTP、WiCoP、およびSLAPPを使用した別の草稿(CAPWAPHPの)を提出しました。 また、私は次世代アクセスポイント/コントローラアーキテクチャに研究関心を持っています。 私は、候補プロトコルドラフトのどれかにおけるかかわり合いを全く持たないで、また草稿のいずれも寄付していません。 私はスタッフが候補プロトコルのいずれも作成した会社のいずれでも働いていません。
4. Protocol Proposals and Highlights
4. プロトコル提案とハイライト
The following proposals were submitted as proposals to the CAPWAP working group.
提案としてCAPWAPワーキンググループに以下の提案を提出しました。
4.1. LWAPP
4.1. LWAPP
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はメリーランド大学情報システムSecurity LabのチャールズClancyから安全レビューを受け取りました。
Loher, et al. Informational [Page 5] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[5ページ]のRFC4565評価
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に関する重要な特色は処理のためにAccess Controller(西暦)にトンネルを堀って戻される生の802.11個のフレームのその使用です。 ともに地方の、そして、MACが分割されたモードで、管理とコントロールのために生の802.11個のフレームを西暦に送ります。 さらに、分裂-MACモードで、利用者データは生の802.11フォームで西暦にトンネルを堀られます。 他の無線技術に概念でLWAPPを使用できた間、LWAPPは802.11層から独立しているほんのわずかな基関数を定義します。
4.2. SLAPP
4.2. SLAPP
"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.
「安全なLight Access Pointプロトコル」[SLAPP]はGenericルート設定Encapsulation(GRE)などのよく知られて、確立した技術のコントロールチャンネル輸送の西暦、Wireless Termination Point(WTP)と提案された標準データグラムTransport Layer Security[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コントロールは、西暦によってすべてのモードの向こう側にSLAPPコントロールパケットでカプセル化されるネイティブの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モードで、802.3個のフレームとして西暦にGREを使用することで、利用者データフレームに、ブリッジされるか、またはトンネルを堀り返すかもしれません。 分裂-MACモードで、利用者データはネイティブの802.11個のフレームとして西暦にいつもトンネルを堀って戻されます。 利用者データの暗号化は西暦かWTPのどちらかで分裂-MACモードで実行されるかもしれません。
4.3. CTP
4.3. CTP
"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 Tunnelingプロトコル」[CTP]は、次にそれが暗号化された制御チャンネルでカプセル化する構成と管理データを定義するためにSimple Network Managementプロトコル(SNMP)の使用でそれ自体を区別します。 地方のMACプロトコルにもかかわらず、新しいバージョンにまた、分裂-MACサポートがあるとき、CTPは元々、設計されました。 さらに、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は西暦、WTPの間の管理とコントロールのために情報要素を定義します。 CTPコントロールメッセージはSTAセッション状態、構成、および統計に指定されます。
Loher, et al. Informational [Page 6] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[6ページ]のRFC4565評価
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はどんなネイティブのワイヤレスのフレームも西暦に送りません。 CTPは西暦、WTPの間のSTAセッション活動、移動性、および無線周波数(RF)資源管理へのコントロールメッセージを指定します。 CTP地方のMACモードは、ワイヤレス・ネットワークからの802.3のイーサネットへの統合機能がすべての利用者データのためにWTPで実行されると指定します。 利用者データは、WTPでブリッジされるか、WTPのCTPパケットの802.3個のフレームとしてカプセル化されて、または西暦にトンネルを堀られるかもしれません。
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操作のバージョンでは、それらの生の形式でワイヤレスの管理フレームを西暦に送ります。 利用者データフレームがWTPで局所的にブリッジされるかもしれないか、それらは、西暦に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. 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の拡大です。 これで、大部分のCTP1は提案されたCAPWAPプロトコルがフレキシブルになります。 しかしながら、それは既存の規格を利用することの代わりに新しいセキュリティとデータトンネリングメカニズムを定義します。
4.4. WiCoP
4.4. WiCoP
"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.
「無線LAN Controlプロトコル」[WICOP]はWireless LAN(WLAN)システムの新しい発見、構成、および管理を導入します。プロトコルはWTP交流能力交渉を統合する異なった発見メカニズムを定義します。
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はService(QoS)パラメタの802.11Qualityを定義します。 さらに、プロトコルは、IPsecや拡張認証プロトコル(EAP)などの標準のセキュリティと認証方法を使用するよう提案します。 プロトコルは、あいさつと共に上記のメソッドの明白な使用に詳細に立ち入る必要があります。 共同利用できるプロトコル実装を確実にするために、詳細な明白な仕様をユーザに提供するのは重要です。
5. Security Considerations
5. セキュリティ問題
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
それぞれの候補プロトコルには、Security Considerations部、およびセキュリティの特性があります。 CAPWAP目的ドキュメント[OBJ]はセキュリティ関連の要件を含んでいます。 評価チームが考えた、そして、候補プロトコルは、セキュリティがCAPWAP目的によって必要とされた特徴であるとどう実装するか。 そしてしかしながら、この評価チームがセキュリティチームでない。
Loher, et al. Informational [Page 7] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[7ページ]のRFC4565評価
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安全レビューを受けなければなりません。
6. Mandatory Objective Compliance Evaluation
6. 義務的な客観的な承諾評価
6.1. Logical Groups
6.1. 論理的なグループ
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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を加えてください」と呼ばれるコントロールメッセージを提供します。 このメッセージは西暦によって使用されて、固有のID(すなわち、Service Set Identifier(SSID))でWLANを作成します。 このWLANのWTPsには、それら自身のBasic Service Set Identifiers(BSSIDs)があります。 LWAPPはこの目的を満たします。
SLAPP
SLAPP
SLAPP explicitly supports 0-255 BSSIDs.
SLAPPは、0-255がBSSIDsであると明らかにサポートします。
CTP
CTP
CTP implements a NETWORK_ID attribute that allows a wireless- technology-independent way of creating logical groups. CTP meets this objective.
CTPは論理的なグループを創設するワイヤレスの技術から独立している方法を許容するNETWORK_ID属性を実装します。 CTPはこの目的を満たします。
WiCoP
WiCoP
WiCoP provides control tunnels to manage logical groups. There is one control tunnel for each logical group. WiCoP meets this objective.
WiCoPは、論理的なグループを経営するためにコントロールトンネルを提供します。 それぞれの論理的なグループあたり1つのコントロールトンネルがあります。 WiCoPはこの目的を満たします。
6.2. Traffic Separation
6.2. トラフィック分離
LWAPP:C, SLAPP:C, CTP:P, WiCoP:P
LWAPP: WiCoP: C、SLAPP: C、CTP: P、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はこの目的を満たします。
Loher, et al. Informational [Page 8] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[8ページ]のRFC4565評価
SLAPP
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プロトコルは、GREと共にコントロールが任意にDTLSを使用する利用者データであるとカプセル化します。 特定の注意では、SLAPPは利用者データがどう西暦と関連して扱われるかを定義する4「アーキテクチャモード」を定義します。 SLAPPはこの目的で言いなりになっています。
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 Object Identifiers(OIDs)を当てにするように見えましたが、なにも仕様では定義されませんでした。 必要なOIDsを定義するのに、CTPは完全に言いなりになるようになるでしょう。
WiCoP
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はこの目的を部分的に満たします。
6.3. STA Transparency
6.3. STA透明
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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/西暦の間の少しのメッセージ・フォーマットも定義してはいけません。
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を意識しているのを必要としません。 STAが802.11規格で相互作用しなければならないどんなメッセージもプロトコル基関数も定義されません。 LWAPPは完全に言いなりになっています。
SLAPP
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が802.11規格で相互作用しなければならないどんなメッセージもプロトコル基関数も定義されません。
Loher, et al. Informational [Page 9] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[9ページ]のRFC4565評価
CTP
CTP
CTP does not require a terminal to know CTP. So, CTP meets this objective.
CTPは、CTPを知るために端末を必要としません。 それで、CTPはこの目的を満たします。
WiCoP
WiCoP
WiCoP does not require a terminal to know WiCoP. So, WiCoP meets this objective.
WiCoPは、WiCoPを知るために端末を必要としません。 それで、WiCoPはこの目的を満たします。
6.4. Configuration Consistency
6.4. 構成の一貫性
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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
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.
SNMPのCTPの使用で、構成一貫性の照合は簡単になります。 MIBで指定されているところでは、1つがデフォルト値を利用するかもしれません。
WICOP
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と西暦の間の能力メッセージの交換から始まります。 次に、構成管理データをWTPに送ります。
Loher, et al. Informational [Page 10] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[10ページ]のRFC4565評価
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によって承認されます。
6.5. Firmware Trigger
6.5. ファームウェア引き金
LWAPP:P, SLAPP:P, CTP:P, WiCoP:C
LWAPP: WiCoP: P、SLAPP: P、CTP: P、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.
ファームウェアダウンロードは他の時ならいつでもで開始されるのではなく、単にJoinフェーズ(WTPが西暦への最初の仲間であることであるときに)でWTPによって開始されます。 西暦でリセットメッセージをWTPに送ることによって、間接的にファームウェアチェックとアップデートの「引き金となられることができるでしょう」。 結果として起こるリブートで、ファームウェアチェックとアップデートを実行するでしょう。 LWAPPは、州のマシンの始動フェーズにファームウェア引き金を使用できるだけであるので、部分的に言いなりになっています。
Loher, et al. Informational [Page 11] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[11ページ]のRFC4565評価
SLAPP
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であるときに実行されるアップデート手順は西暦への最初の接続です。 西暦でリセットメッセージを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で定義されるようにファームウェアアップグレード手順を実行しなければならないと指定します。 しかしながら、.5セクション5.2[CTP]が、SWアップデートReqメッセージが西暦によって送られるかもしれないと述べます。 これは、CTPがWTPの通常の実行状態の間西暦で引き起こされたソフトウェアアップデートをサポートすることができたのを間接的に含意します。 それで、CTPが完全に言いなりになるかもしれないように思えますが、提案は完全な承諾ためにはっきりさせられるべきです。
WiCoP
WiCoP
In WiCoP, firmware update may be triggered any time in the active state, so WiCoP is fully compliant.
WiCoPでは、ファームウェアのアップデートが活動的な状態でいつでも引き起こされるかもしれないので、WiCoPは完全に言いなりになっています。
6.6. Monitor and Exchange of System-wide Resource State
6.6. システム全体のリソース状態のモニターと交換
LWAPP:C, SLAPP:C, CTP:P, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: P、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.
評価チームはWTPsから統計に関連している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のMAC層の特性をカバーする802.11統計メッセージを定義します。 LWAPPは言いなりになっています。
SLAPP
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統計輸送は、制御チャンネルで供給されて、情報要素と呼ばれるSLAPPによって定義されたTLVsでコード化されます。 [SLAPP]6.1.3で.1に802.11構成と統計情報要素を供給します。 これらは、「広げ-可能」で、ベンダー特有の拡大を含んでいます。
Loher, et al. Informational [Page 12] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[12ページ]のRFC4565評価
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は統計で通知します」と呼ばれるコントロールメッセージを定義します。 このコントロールメッセージをSNMP OIDsの形に統計を含んでいて、WTPから西暦に送ります。 標準の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.
.10セクション5.3[CTP]が適切であるところで802.11MIBsの使用を推薦します。 しかしながら、提案は、追加構成と統計情報が必要であると認めますが、これらのMIB拡張子を指定しません。 CTPは、これらの拡大を提案に追加する必要があります。 また、統計と構成OIDsのこの最小のセットは、目的を完全に満たすために要件にならなければなりません。
WiCoP
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が西暦に送る必要がある15の統計を指定します。 WiCoPの新しいバージョンは西暦がモニターする必要があるどんな新しい統計にもWTPを扱うことができます。 WiCoPはこの目的を満たします。
6.7. Resource Control
6.7. 資源管理
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP: WiCoP: C、SLAPP: P、CTP: P、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は西暦によって送られたそれぞれのAddのモバイルRequestでそれぞれの付属新しい移動局へのWTPにモバイルステーションベースのQoS構成を許します。 パケット優先順位づけは個々のWTPsに残されます。 4 各ステーションが実施する異なったQoS方針を構成できます。 WTPでQoS方針を与えられた移動局に変えるのに要素を使用できるというモバイルQoSメッセージをアップデートしてください。 LWAPPはこれが802.11e 802.1pとIP TOSに合っているとき8QoSが方針であるとサポートするべきですが、この目的、4つのクラスにおいて、言いなりになっています。
Loher, et al. Informational [Page 13] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[13ページ]のRFC4565評価
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
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とDifferentiated Service Code Point(DSCP)マッピングを指定しますが、802.11eのどんな明白なサポートもSLAPPにありません。 WTPがサポートすることができた標準の能力の1つとして802.11eを加えて、QoSのクラスを写像する構成を許すメカニズムを指定するためにSLAPPをアップデートしなければなりません。
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と西暦がデータメッセージカプセル化に利用者データのQoSマークをコピーするのを必要とします。 このマッピングはCTP Headerの1バイトの方針分野によって達成されます。 しかしながら、既に利用者データをコピーする以外に、既存の印を写像するQoSの構成は全くCTPで定義されません。 異なって起こるようにマッピングを構成するのがSNMPを使用できたのが明確に思えますが、これを可能にするOIDsが全く定義されません。 部分的なコンプライアンスはこの目的のためにCTPに割り当てられます。
WiCoP
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格付けはFailedからPartialまでアップグレードしました。 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と西暦の間の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は明らかに少しの特定のMIBsも特定しません。 全体的に見て、WiCoPは資源管理CAPWAP目的を部分的に満たします。 与えられた目的で完全に言いなりになるために、プロトコルは、802.1pとDSCPマッピングを構成するためにクリア方法を特定する必要があります。
Loher, et al. Informational [Page 14] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[14ページ]のRFC4565評価
6.8. Protocol Security
6.8. プロトコルセキュリティ
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP: WiCoP: C、SLAPP: C、CTP: F、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目的によって必要とされた特徴であると実装するかどうか主として考えました。 このドキュメントのSecurity Considerations部を参照してください。
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にかぎ管理部分を含むセキュリティー対策が正しいように見えます。 1つの第三者安全レビューが実行されました。 しかしながら、CAPWAP特有の主要な交換メカニズムが定義されるので、さらなる安全レビューは保証されます。 LWAPPは目的で言いなりになっています。
SLAPP
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.
SLAPPプロトコルは、西暦でDTLSプロトコルを使用することでWTPの認証を実装します。 この振舞いは発見プロセスと802.11コントロールプロセスの両方で定義されます。 SLAPPは互いの、そして、非対称の認証を許します。 また、SLAPPはどう適切に認証を使用するかに関する有益な例を出します。 SLAPPはWTPによる西暦の認証のために別の有益な例を加えるはずです。 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は2つの理由でまだ目的に従っていません:
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は互いにセッションキーを引き出しません。 2番目に、認証がする2回のパーティーがキーを確認しないので、CTPは明白な互いの認証を実行しません。
Loher, et al. Informational [Page 15] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[15ページ]のRFC4565評価
WiCoP
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は概念で理解できますが、これらのメソッドがどう使用されるだろうかにおけるどんな明白な記述もありません。
6.9. System-Wide Security
6.9. システム全体のセキュリティ
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP: WiCoP: C、SLAPP: C、CTP: F、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
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.
SLAPPは、DTLSのすべてのコントロールとマネジメント・コミュニケーションを包装するので、言いなりになっています。 また、SLAPPは、発見から守る測定がDoS攻撃を要求することを勧めます。 DTLSは安全レビューを受けて、SLAPPの外に少なくとも1つの知られている実装を持っています。 この書くこと時点で、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は西暦からWTPへの認証のために新しくて、非設立されたメカニズムを紹介します。 完全な承諾において、仕様詳細がある確立したセキュリティー対策のCTPにおける使用の使用は好まれます。 あるいはまた、詳細な安全レビューを実行できました。 CTPはレッジ-ReqとAuth-Req洪水に対してどんなDoS攻撃緩和要件も指摘もしませんし、推薦もしませんし、指定もしません、レートリミタのように。 CTPがプロトコルセキュリティ目的で'F'を受けたので、また、'F'であるとシステム全体のセキュリティを評定しなければならないということになります。
WiCoP
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攻撃が脅威であると扱いません。 また、プロトコルセキュリティ目的のように、プロトコルは、明らかにトンネルと認証方法を説明する必要があります。
Loher, et al. Informational [Page 16] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[16ページ]のRFC4565評価
6.10. 802.11i Considerations
6.10. 802.11 i問題
LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
LWAPP: WiCoP: C、SLAPP: C、CTP: F、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.
暗号化がWTPで終えられている状態で、LWAPPは取り扱い802.11iのためにモードで明らかにメカニズムを定義します。 これを達成するために、西暦はAddのモバイルメッセージを使用することでWTPの暗号化された制御チャンネルを使用することでPairwise Transient Key(PTK)を送ります。 暗号化が西暦で終えられるとき、どんな特別な要件もありません。 LWAPPは言いなりになっています。
SLAPP
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とGroup Temporal Key(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.
CTPはWTPが暗号化終点であるときにWTPのキーを802.11i PTKとGTKに送るコントロールメッセージのための仕様を欠いています。 これに基づいて、CTPはこの目的のためのコンプライアンスに失敗します。 新しいコントロール経路情報要素を定義するか、または単にSNMP OIDsを定義することによって、この要件を扱うことができるでしょう。 これらのOIDsの輸送は、安全な制御チャンネルで含まれていて、したがって、保護されるでしょう。
WiCoP
WiCoP
WiCoP lacks documentation on how to handle 4-way handshake. The case for encryption at the AC needs clarification.
WiCoPはどう4ウェイ握手を扱うかに関するドキュメンテーションを欠いています。 西暦の暗号化のためのこの件は明確化を必要とします。
6.11. Interoperability
6.11. 相互運用性
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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データを許容するモードを欠いています。
Loher, et al. Informational [Page 17] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[17ページ]のRFC4565評価
frames to be tunneled back to the AC. A discussion of possible extensions and issues is discussed in the recommendations section of this evaluation.
西暦にトンネルを堀って戻られるために、縁どっています。 この評価の推薦部で可能な拡大と問題の議論について議論します。
SLAPP
SLAPP
SLAPP is compliant.
SLAPPは言いなりになっています。
CTP
CTP
CTP is compliant.
CTPは言いなりになっています。
WiCoP
WiCoP
WiCoP is compliant.
WiCoPは言いなりになっています。
6.12. Protocol Specifications
6.12. プロトコル仕様
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP: WiCoP: C、SLAPP: P、CTP: P、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
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
WiCoP
Due to the lack of specific tunnel specifications and authentication specifications, WiCoP is only partially compliant.
特定のトンネル仕様と認証仕様の不足のために、WiCoPは部分的に言いなりになっているだけです。
Loher, et al. Informational [Page 18] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[18ページ]のRFC4565評価
6.13. Vendor Independence
6.13. ベンダー独立
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、C
LWAPP
LWAPP
LWAPP is compliant.
LWAPPは言いなりになっています。
SLAPP
SLAPP
SLAPP is compliant.
SLAPPは言いなりになっています。
CTP
CTP
CTP is compliant.
CTPは言いなりになっています。
WiCoP
WiCoP
WiCoP is compliant.
WiCoPは言いなりになっています。
6.14. Vendor Flexibility
6.14. ベンダーの柔軟性
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、C
LWAPP
LWAPP
LWAPP is compliant.
LWAPPは言いなりになっています。
SLAPP
SLAPP
SLAPP is compliant.
SLAPPは言いなりになっています。
CTP
CTP
CTP is compliant.
CTPは言いなりになっています。
WiCoP
WiCoP
WiCoP is compliant.
WiCoPは言いなりになっています。
Loher, et al. Informational [Page 19] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[19ページ]のRFC4565評価
6.15. NAT Traversal
6.15. NAT縦断
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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は、それのため暗号化されたコントロールメッセージのペイロードの西暦、データ終了ポイントのIPアドレスを運びながら、特別な問題を必要とするかもしれません。 Network Address Translation(NAT)に打ち勝つために、終了ポイントが扱う西暦かデータがWTPの観点から翻訳されるなら、静的なNATマッピングは、NAT'ingデバイスに作成される必要があるかもしれません。 WTPはNATのスペースがネットワークでつなぐ隠しアドレスで機能するはずであることができます。
SLAPP
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
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のスペースが少しも特別な構成なしでネットワークでつなぐ隠しアドレスで機能できました。
7. Desirable Objective Compliance Evaluation
7. 望ましい客観的な承諾評価
7.1. Multiple Authentication
7.1. 複数の認証
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、C
LWAPP
LWAPP
LWAPP allows for multiple STA authentication mechanisms.
LWAPPは複数のSTA認証機構を考慮します。
SLAPP
SLAPP
SLAPP does not constrain other authentication techniques from being deployed.
SLAPPは、配布されるので、他の認証のテクニックを抑制しません。
Loher, et al. Informational [Page 20] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[20ページ]のRFC4565評価
CTP
CTP
CTP supports multiple STA authentication mechanisms.
CTPは、複数のSTA認証がメカニズムであるとサポートします。
WiCoP
WiCoP
WiCoP allows for multiple STA authentication mechanisms.
WiCoPは複数のSTA認証機構を考慮します。
7.2. Future Wireless Technologies
7.2. 将来の無線技術
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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
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の拡大です。(概念では、容易にSNMPに新しいMIBsのプラグを差し込まれることができました)。 この力添えはCTPを将来の無線技術をサポートするための特にフレキシブルな提案にします。 さらに、CTPは既に802.11に加えて複数のワイヤレスのプロトコルタイプを定義しました。
WiCoP
WiCoP
WiCoP could be used for other wireless technologies.
他の無線技術にWiCoPを使用できました。
7.3. New IEEE Requirements
7.3. 新しいIEEE要件
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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.
推進が多くの802.11に透明であることをそれを許容するネイティブの802.11フレームのLWAPPの大規模な使用は変化します。 しかしながら、それは西暦のパケット処理能力へのMAC層の変化を適合させることの重荷を取り除きます。
Loher, et al. Informational [Page 21] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[21ページ]のRFC4565評価
SLAPP
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.
ネイティブの802.11個のフレームのSLAPPのコントロールと管理の使用は802.11における変化への透明の基準をSLAPPに許容します。 また、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 OIDsは追加コントロールと管理機能のために容易に広げられます。 必要なら、ネイティブのワイヤレスのフレームを直接西暦に送ることができます。 ワイヤレスのMAC層の変化から西暦を保護するためにワイヤレスのフレームを802.3個のフレームにブリッジして、西暦にトンネルを堀って戻すことができます。 これらのオプションはワイヤレスのMAC層の変化に順応する多くの可能な方法を許容します。
WiCoP
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と西暦の間で新しい構成と新しい能力メッセージを必要とするかもしれません。 西暦は、新しい802.11コントロールと管理フレームを扱うように変更される必要があるでしょう。
7.4. Interconnection (IPv6)
7.4. インタコネクト(IPv6)
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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のために明らかに測定を定義します。 一部2つのコントロールメッセージのIPアドレスを運ぶので、LWAPPはこれにより敏感です。
SLAPP
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の上で少しも変化なしで作動するはずであることができます。
Loher, et al. Informational [Page 22] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[22ページ]のRFC4565評価
WiCoP
WiCoP
WiCoP is transparent to the interconnection layer and should be able to operate over IPv6 without changes.
WiCoPはインタコネクト層に透明であり、IPv6の上で変化なしで作動できるはずです。
7.5. Access Control
7.5. アクセス制御
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP: WiCoP: C、SLAPP: C、CTP: C、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はSTAアクセスコントロールを実行する目的のために西暦に送られた802.11個のネイティブの管理フレームを使用します。 WTPsはLWAPPの制御プロトコルJoinフェーズで認証されます。
SLAPP
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.
SLAPPには、WTPsにおいて複数の認証方法のサポートがあります。 さらに、SLAPPは西暦に送られた802.11個の管理フレームを通してSLAPPの情報要素基関数でSTAアクセスを制御できます。
CTP
CTP
CTP specifies STA access control primitives.
CTPはSTAアクセス制御基関数を指定します。
WiCoP
WiCoP
WiCoP specifies access control in [WICOP] section 5.2.2.
WiCoPは[WICOP]セクション5.2.2におけるアクセスコントロールを指定します。
Loher, et al. Informational [Page 23] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[23ページ]のRFC4565評価
8. Evaluation Summary and Conclusions
8. 評価概要と結論
See Figure 1 (section numbers correspond to RFC 4564 [OBJ]).
図1を見てください(セクション番号はRFC4564[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評価| LWAPP| SLAPP| CTP| WiCoP| |---------------------------------------------------------------| | 5.1.1 論理的なグループ| C| C| C| C| | 5.1.2 トラフィック分離| C| C| P| P| | 5.1.3 STA透明| C| C| C| C| | 5.1.4 コンフィグの一貫性| C| C| C| C| | 5.1.5 ファームウェア引き金| P| P| P| C| | 5.1.6 モニタシステム| C| C| P| C| | 5.1.7 資源管理| C| P| P| P| | 5.1.8 プロトコルセキュリティ| C| C| F| F| | 5.1.9 システムセキュリティ| C| C| F| F| | 5.1.10 802.11 iの考慮| C| C| F| P| |---------------------------------------------------------------| | 5.1.11 相互運用性| C| C| C| C| | 5.1.12 プロトコル仕様| C| P| P| P| | 5.1.13 ベンダー独立| C| C| C| C| | 5.1.14 ベンダーの柔軟性| C| C| C| C| | 5.1.15 NAT縦断| C| C| C| C| |---------------------------------------------------------------| | 望ましい| |---------------------------------------------------------------| | 5.2.1 複数の認証| C| C| C| C| | 5.2.2 将来のワイヤレス| C| C| C| C| | 5.2.3 新しいIEEE要件| C| C| C| C| | 5.2.4 インタコネクト(IPv6)| C| C| C| C| | 5.2.5 アクセスコントロール| C| C| C| C| ---------------------------------------------------------------
Figure 1: Summary Results
図1: 概要結果
9. Protocol Recommendation
9. プロトコル推薦
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プロトコルを作成するのは、この評価チームの意見です。
Loher, et al. Informational [Page 24] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[24ページ]のRFC4565評価
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プロトコルがこれらの問題と変化を扱うことによって提供されると信じています。
9.1. High-Priority Recommendations Relevant to Mandatory Objectives
9.1. 義務的な目的に関連している高優先度推薦
9.1.1. Information Elements
9.1.1. 情報要素
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ビットで。 評価チームは、より多くのビットが属性タイプと情報要素のために割り当てられることを強く勧めます。
9.1.2. Control Channel Security
9.1.2. コントロールチャンネルセキュリティ
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規格を再利用するよりさらに難しくなるということです。 まず最初に、新しいセキュリティプロトコルは、より長くて、より遅い承認がSecurity Area Directorateから処理する表面と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で絶えずより多くの配慮を受けています。 主要な交換メソッドと暗号スイートの伸展性は業界基準の最も良い習慣になっています。 これらの問題はIETF Security Area Advisory Group(SAAG)と63番目のIETFミーティングの間に持たれていたSecMech BOFの重要な話題です。
Loher, et al. Informational [Page 25] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[25ページ]のRFC4565評価
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はTransport Layer Security(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は提案されて、独占であるメソッドがあるこの良い仕事をします。 アップデートされた仕様が開発されているなら、それは少なくとも1つの義務的な認証と暗号メソッドを含むべきです。 例えば、義務的な認証方法としてあらかじめ共有されたキーとx.509証明書を指定できました、そして、義務的な暗号としてCBC-MACプロトコル(CCMP)があるエー・イー・エス(AES)カウンタModeを選定できました。
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のための未来を考えて、DTLSはCAPWAPに特定のセキュリティメソッドへの賢明な代替手段であるかもしれません。 さらに、DTLSの使用は提案された標準としてCAPWAP特有のセキュリティー対策の使用の上でおそらくCAPWAPの承認を速めるでしょう。
9.1.3. Data Tunneling Modes
9.1.3. データトンネリングモード
9.1.3.1. Support for Local MAC User Data Tunneling
9.1.3.1. 地方のMACには、利用者データがトンネリングであるとサポートしてください。
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から西暦に縁どって戻られるとき、私たちは利用者データのトンネリングを言っています。
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モードによるトンネリングデータはimplementersが地方のMACアーキテクチャを使用してさえいる間にいくつかの方法で革新される能力を提供します。 例えば、データが西暦に支持するか、またはLWAPP定義するユーザ、データ終了終点のトンネリングを通してフレキシブルな利用者データの移動性や、暗号化オプションや、速いhandoffsなどの機能を可能にすることができます。トンネリングは西暦と異なっているかもしれません。 さらに、声かビデオなどのユーザデータ・パケットの特別なQoSかアプリケーション意識している処理があります。 また、一般的な形式で利用者データをカプセル化するとき、将来の無線技術との改良された透明と互換性も可能です、802.3などのように、ネットワークにおけるアクセスポイントと西暦か他の終了ポイントの間で。
Loher, et al. Informational [Page 26] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[26ページ]のRFC4565評価
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層の変化が、西暦に透明なままで残っていて、利益の多くがトンネリングがもたらすことができるそのデータであることをまだ支持しているかもしれないなら。
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は2MACのワイヤレスの層から独立しているワイヤレスの情報(Signal Strength Indication(RSSI)とSignalから雑音へのRatio(SNR)を受ける)をトンネルを堀られた利用者データのための層1を含むヘッダーにサポートします。 異なったワイヤレスのMACsの向こう側に802.3の利用者データにトンネルを堀るときさえ、西暦の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.
革新的なimplementersは、このメソッドを使用することで他の多くの特徴を作成できそうでしょう。 しかしながら、LWAPPは、データフレームに西暦にトンネルを堀って戻すオプションを除くために地方のMACアーキテクチャを辛うじて定義します。 すべての提案と既存の独占産業実装の向こう側のWTPと西暦の間の802.3個のデータフレームにトンネルを堀る広いサポートを考えて、評価チームは、ワーキンググループが地方のMACのためのデータトンネリングモードがLWAPP提案に追加されて、標準のCAPWAPプロトコルの一部になると考えることを強く勧めます。
9.1.3.2. Mandatory and Optional Tunneling Modes
9.1.3.2. 義務的で任意のトンネリングモード
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.
1つ以上のトンネリングモードがCAPWAPプロトコルの一部であるなら、評価チームは、ワーキンググループが任意であるとして義務的であるとしての1つのメソッドと他のメソッドを選ぶことを勧めます。 さらに、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.
モードが義務的であるべき選択は、重要な決定であり、implementersがWTPsとACsの両方のための彼らのハードウェアとソフトウェア選択でしなければならない多くの決定に影響を与えるかもしれません。 評価チームは、ワーキンググループが、地方のMACデータトンネリングのこの問題を扱って、どのモードが義務的であるべきであるかを慎重に選ぶべきであると信じています。
9.2. Additional Recommendations Relevant to Desirable Objectives
9.2. 望ましい目的に関連している追加推薦
9.2.1. Access Control
9.2.1. アクセス制御
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-
コントロールがCTPとWiCoPで実装されたそれなどのようにそれとして貴重な特徴としての外で耐えるSTAアクセスの抽象化はちょうど802.11ではなく多くのタイプのワイヤレス・ネットワークの運用能力に基本的です。 LWAPPは、802.11としてステーションアクセスがコントロールであると実装します。
Loher, et al. Informational [Page 27] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[27ページ]のRFC4565評価
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は802.11結合からSTA Delete機能を抜き取りました。 しかしながら、Add STA機能は802.11結合の一部です。 802.11結合の外でSTAを加えるためにワイヤレスがMACの独立している機能であると実装するのは役に立つでしょう。
9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling
9.2.2. データトンネリングのための層2のカプセル化の取り外し
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のメソッドに余分であると信じています。 チームは、層2のメソッドカプセル化がLWAPPプロトコルから取り除かれることを勧めます。
9.2.3. Data Encapsulation Standard
9.2.3. データカプセル化規格
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と西暦の間の利用者データのカプセル化の使用を推薦します。 GREかLayer2Tunnelingプロトコル(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は複数のデータ型をカプセル化するように設計されています、将来の無線技術をサポートするために柔軟性を増強して。
Loher, et al. Informational [Page 28] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[28ページ]のRFC4565評価
10. Normative References
10. 引用規格
[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.
[アーチ]陽、L.、Zerfos、P.、およびE.Sadot、「ワイヤレス・アクセスのコントロールと食糧を供給するアーキテクチャ分類学は(CAPWAP)を指します」、RFC4118、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.(エド)、チェン、H.、八尾(ZH)、周、WH L.陽、「ワイヤレスのコントロールと食糧を供給する目的はポイント(CAPWAP)にアクセスします」、RFC4564、2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
11. Informative References
11. 有益な参照
[CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes,
"CAPWAP Tunneling Protocol (CTP)", Work in Progress, April
2005.
[CTP]シンとI.とフランシスコとP.とPakulski、K.とF.Backes、「プロトコル(CTP)にトンネルを堀るCAPWAP」処理中の作業(2005年4月)。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[DTLS]レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、2006年4月のRFC4347。
[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]カルフーン、P.、オハラ、B.、ケリー、S.、スーリ、R.、ウィリアムズ、M.、野兎(S.、およびN.カム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] ミットン、D.、セントジョンズ、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、B.ヴォルフ、「認証、承認、以下を説明すること」。 「プロトコル評価」、RFC3127、2001年6月。
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP :
Secure Light Access Point Protocol", Work in Progress, May
2005.
[SLAPP] ナラシマン、P.、ハーキン、D.、およびS.Ponnuswamy、「SLAPP:」 「安全な軽いアクセスポイントプロトコル」(処理中の作業)は2005がそうするかもしれません。
[WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
"Wireless LAN Control Protocol (WiCoP)", Work in Progress,
March 2005.
S.、Govindan、S.、Sugiura、M.、およびH.チェン、「ワイヤレスのLAN制御プロトコル(WiCoP)」という[WICOP]Iinoは進歩、2005年3月に働いています。
Loher, et al. Informational [Page 29] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[29ページ]のRFC4565評価
Authors' Addresses
作者のアドレス
Darren P. Loher Envysion, Inc. 2010 S. 8th Street Boulder, CO 80302 USA
2010秒間第8通りボウルダー、ダーレンP.Loher Envysion Inc.CO80302米国
Phone: +1.303.667.8761 EMail: dplore@gmail.com
以下に電話をしてください。 +1.303 .667 .8761 メール: dplore@gmail.com
David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Anover, MA 01810-1008 USA
デヴィッドB.ネルソンEnterasysネットワークInc.50ミニットマン道路Anover、MA01810-1008米国
Phone: +1.978.684.1330 EMail: dnelson@enterasys.com
以下に電話をしてください。 +1.978 .684 .1330 メール: dnelson@enterasys.com
Oleg Volinsky Colubris Networks, Inc. 200 West Street Waltham, MA 02451 USA
オレーグVolinsky Colubrisはウォルサム、Inc.200MA02451米国ウェスト・ストリートをネットワークでつなぎます。
Phone: +1.781.547.0329 EMail: ovolinsky@colubris.com
以下に電話をしてください。 +1.781 .547 .0329 メール: ovolinsky@colubris.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Behcet Sarikaya Huawei米国1700アルマ博士Suite100テキサス75075プラノ(米国)
Phone: +1.972.509.5599 EMail: sarikaya@ieee.org
以下に電話をしてください。 +1.972 .509 .5599 メール: sarikaya@ieee.org
Loher, et al. Informational [Page 30] RFC 4565 Evaluation of Candidate CAPWAP Protocols July 2006
Loher、他 候補CAPWAPプロトコル2006年7月の情報[30ページ]のRFC4565評価
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Loher, et al. Informational [Page 31]
Loher、他 情報[31ページ]
一覧
スポンサーリンク
