Network Working Group P. Calhoun, Ed.
Request for Comments: 5415 Cisco Systems, Inc.
Category: Standards Track M. Montemurro, Ed.
Research In Motion
D. Stanley, Ed.
Aruba Networks
March 2009
Control And Provisioning of Wireless Access Points (CAPWAP)
Protocol Specification
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies.
この仕様は、無線技術の種々のために使用することができるように、CAPWAPプロトコルは柔軟であるように設計されているRFC 4564.にCAPWAPワーキンググループによって定義された目標を達成し、無線アクセスポイント（CAPWAP）プロトコルの制御およびプロビジョニングを定義します。別のバインディングの拡張機能が追加無線技術での使用を可能にする一方、この文書では、基本CAPWAPプロトコルを記述します。
Table of Contents
目次
1. Introduction ....................................................7
1.1. Goals ......................................................8
1.2. Conventions Used in This Document ..........................9
1.3. Contributing Authors .......................................9
1.4. Terminology ...............................................10
2. Protocol Overview ..............................................11
2.1. Wireless Binding Definition ...............................12
2.2. CAPWAP Session Establishment Overview .....................13
2.3. CAPWAP State Machine Definition ...........................15
2.3.1. CAPWAP Protocol State Transitions ..................17
2.3.2. CAPWAP/DTLS Interface ..............................31
2.4. Use of DTLS in the CAPWAP Protocol ........................33
2.4.1. DTLS Handshake Processing ..........................33
2.4.2. DTLS Session Establishment .........................35
2.4.3. DTLS Error Handling ................................35
2.4.4. DTLS Endpoint Authentication and Authorization .....36
3. CAPWAP Transport ...............................................40
3.1. UDP Transport .............................................40
3.2. UDP-Lite Transport ........................................41
3.3. AC Discovery ..............................................41
3.4. Fragmentation/Reassembly ..................................42
3.5. MTU Discovery .............................................43
4. CAPWAP Packet Formats ..........................................43
4.1. CAPWAP Preamble ...........................................46
4.2. CAPWAP DTLS Header ........................................46
4.3. CAPWAP Header .............................................47
4.4. CAPWAP Data Messages ......................................50
4.4.1. CAPWAP Data Channel Keep-Alive .....................51
4.4.2. Data Payload .......................................52
4.4.3. Establishment of a DTLS Data Channel ...............52
4.5. CAPWAP Control Messages ...................................52
4.5.1. Control Message Format .............................53
4.5.2. Quality of Service .................................56
4.5.3. Retransmissions ....................................57
4.6. CAPWAP Protocol Message Elements ..........................58
4.6.1. AC Descriptor ......................................61
4.6.2. AC IPv4 List .......................................64
4.6.3. AC IPv6 List .......................................64
4.6.4. AC Name ............................................65
4.6.5. AC Name with Priority ..............................65
4.6.6. AC Timestamp .......................................66
4.6.7. Add MAC ACL Entry ..................................66
4.6.8. Add Station ........................................67
4.6.9. CAPWAP Control IPv4 Address ........................68
4.6.10. CAPWAP Control IPv6 Address .......................68
4.6.11. CAPWAP Local IPv4 Address .........................69
4.6.12. CAPWAP Local IPv6 Address .........................69
4.6.13. CAPWAP Timers .....................................70
4.6.14. CAPWAP Transport Protocol .........................71
4.6.15. Data Transfer Data ................................72
4.6.16. Data Transfer Mode ................................73
4.6.17. Decryption Error Report ...........................73
4.6.18. Decryption Error Report Period ....................74
4.6.19. Delete MAC ACL Entry ..............................74
4.6.20. Delete Station ....................................75
4.6.21. Discovery Type ....................................75
4.6.22. Duplicate IPv4 Address ............................76
4.6.23. Duplicate IPv6 Address ............................77
4.6.24. Idle Timeout ......................................78
4.6.25. ECN Support .......................................78
4.6.26. Image Data ........................................79
4.6.27. Image Identifier ..................................79
4.6.28. Image Information .................................80
4.6.29. Initiate Download .................................81
4.6.30. Location Data .....................................81
4.6.31. Maximum Message Length ............................81
4.6.32. MTU Discovery Padding .............................82
4.6.33. Radio Administrative State ........................82
4.6.34. Radio Operational State ...........................83
4.6.35. Result Code .......................................84
4.6.36. Returned Message Element ..........................85
4.6.37. Session ID ........................................86
4.6.38. Statistics Timer ..................................87
4.6.39. Vendor Specific Payload ...........................87
4.6.40. WTP Board Data ....................................88
4.6.41. WTP Descriptor ....................................89
4.6.42. WTP Fallback ......................................92
4.6.43. WTP Frame Tunnel Mode .............................92
4.6.44. WTP MAC Type ......................................93
4.6.45. WTP Name ..........................................94
4.6.46. WTP Radio Statistics ..............................94
4.6.47. WTP Reboot Statistics .............................96
4.6.48. WTP Static IP Address Information .................97
4.7. CAPWAP Protocol Timers ....................................98
4.7.1. ChangeStatePendingTimer ............................98
4.7.2. DataChannelKeepAlive ...............................98
4.7.3. DataChannelDeadInterval ............................99
4.7.4. DataCheckTimer .....................................99
4.7.5. DiscoveryInterval ..................................99
4.7.6. DTLSSessionDelete ..................................99
4.7.7. EchoInterval .......................................99
4.7.8. IdleTimeout ........................................99
4.7.9. ImageDataStartTimer ...............................100
4.7.10. MaxDiscoveryInterval .............................100
4.7.11. ReportInterval ...................................100
4.7.12. RetransmitInterval ...............................100
4.7.13. SilentInterval ...................................100
4.7.14. StatisticsTimer ..................................100
4.7.15. WaitDTLS .........................................101
4.7.16. WaitJoin .........................................101
4.8. CAPWAP Protocol Variables ................................101
4.8.1. AdminState ........................................101
4.8.2. DiscoveryCount ....................................101
4.8.3. FailedDTLSAuthFailCount ...........................101
4.8.4. FailedDTLSSessionCount ............................101
4.8.5. MaxDiscoveries ....................................102
4.8.6. MaxFailedDTLSSessionRetry .........................102
4.8.7. MaxRetransmit .....................................102
4.8.8. RetransmitCount ...................................102
4.8.9. WTPFallBack .......................................102
4.9. WTP Saved Variables ......................................102
4.9.1. AdminRebootCount ..................................102
4.9.2. FrameEncapType ....................................102
4.9.3. LastRebootReason ..................................103
4.9.4. MacType ...........................................103
4.9.5. PreferredACs ......................................103
4.9.6. RebootCount .......................................103
4.9.7. Static IP Address .................................103
4.9.8. WTPLinkFailureCount ...............................103
4.9.9. WTPLocation .......................................103
4.9.10. WTPName ..........................................103
5. CAPWAP Discovery Operations ...................................103
5.1. Discovery Request Message ................................103
5.2. Discovery Response Message ...............................105
5.3. Primary Discovery Request Message ........................106
5.4. Primary Discovery Response ...............................107
6. CAPWAP Join Operations ........................................108
6.1. Join Request .............................................108
6.2. Join Response ............................................110
7. Control Channel Management ....................................111
7.1. Echo Request .............................................111
7.2. Echo Response ............................................112
8. WTP Configuration Management ..................................112
8.1. Configuration Consistency ................................112
8.1.1. Configuration Flexibility .........................113
8.2. Configuration Status Request .............................114
8.3. Configuration Status Response ............................115
8.4. Configuration Update Request .............................116
8.5. Configuration Update Response ............................117
8.6. Change State Event Request ...............................117
8.7. Change State Event Response ..............................118
8.8. Clear Configuration Request ..............................119
8.9. Clear Configuration Response .............................119
9. Device Management Operations ..................................120
9.1. Firmware Management ......................................120
9.1.1. Image Data Request ................................124
9.1.2. Image Data Response ...............................125
9.2. Reset Request ............................................126
9.3. Reset Response ...........................................127
9.4. WTP Event Request ........................................127
9.5. WTP Event Response .......................................128
9.6. Data Transfer ............................................128
9.6.1. Data Transfer Request .............................130
9.6.2. Data Transfer Response ............................131
10. Station Session Management ...................................131
10.1. Station Configuration Request ...........................131
10.2. Station Configuration Response ..........................132
11. NAT Considerations ...........................................132
12. Security Considerations ......................................134
12.1. CAPWAP Security .........................................134
12.1.1. Converting Protected Data into Unprotected Data ..135
12.1.2. Converting Unprotected Data into
Protected Data (Insertion) .......................135
12.1.3. Deletion of Protected Records ....................135
12.1.4. Insertion of Unprotected Records .................135
12.1.5. Use of MD5 .......................................136
12.1.6. CAPWAP Fragmentation .............................136
12.2. Session ID Security .....................................136
12.3. Discovery or DTLS Setup Attacks .........................137
12.4. Interference with a DTLS Session ........................137
12.5. CAPWAP Pre-Provisioning .................................138
12.6. Use of Pre-Shared Keys in CAPWAP ........................139
12.7. Use of Certificates in CAPWAP ...........................140
12.8. Use of MAC Address in CN Field ..........................140
12.9. AAA Security ............................................141
12.10. WTP Firmware ...........................................141
13. Operational Considerations ...................................141
14. Transport Considerations .....................................142
15. IANA Considerations ..........................................143
15.1. IPv4 Multicast Address ..................................143
15.2. IPv6 Multicast Address ..................................144
15.3. UDP Port ................................................144
15.4. CAPWAP Message Types ....................................144
15.5. CAPWAP Header Flags .....................................144
15.6. CAPWAP Control Message Flags ............................145
15.7. CAPWAP Message Element Type .............................145
15.8. CAPWAP Wireless Binding Identifiers .....................145
15.9. AC Security Types .......................................146
15.10. AC DTLS Policy .........................................146
15.11. AC Information Type ....................................146
15.12. CAPWAP Transport Protocol Types ........................146
15.13. Data Transfer Type .....................................147
15.14. Data Transfer Mode .....................................147
15.15. Discovery Types ........................................147
15.16. ECN Support ............................................148
15.17. Radio Admin State ......................................148
15.18. Radio Operational State ................................148
15.19. Radio Failure Causes ...................................148
15.20. Result Code ............................................149
15.21. Returned Message Element Reason ........................149
15.22. WTP Board Data Type ....................................149
15.23. WTP Descriptor Type ....................................149
15.24. WTP Fallback Mode ......................................150
15.25. WTP Frame Tunnel Mode ..................................150
15.26. WTP MAC Type ...........................................150
15.27. WTP Radio Stats Failure Type ...........................151
15.28. WTP Reboot Stats Failure Type ..........................151
16. Acknowledgments ..............................................151
17. References ...................................................151
17.1. Normative References ....................................151
17.2. Informative References ..................................153
This document describes the CAPWAP protocol, a standard, interoperable protocol that enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). The CAPWAP protocol is defined to be independent of Layer 2 (L2) technology, and meets the objectives in "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4564].
この文書では、ワイヤレスターミネーションポイント（WTPs）のコレクションを管理するために、アクセスコントローラ（AC）を有効にCAPWAPプロトコル、標準、相互運用可能なプロトコルを記述しています。 CAPWAPプロトコルは、レイヤ2（L2）技術とは無関係であると定義され、「無線アクセスポイント（CAPWAP）の制御およびプロビジョニング用の目的」[RFC4564]に目標を満たしています。
The emergence of centralized IEEE 802.11 Wireless Local Area Network (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by an Access Controller (AC), suggested that a standards-based, interoperable protocol could radically simplify the deployment and management of wireless networks. WTPs require a set of dynamic management and control functions related to their primary task of connecting the wireless and wired mediums. Traditional protocols for managing WTPs are either manual static configuration via HTTP, proprietary Layer 2-specific or non-existent (if the WTPs are self-contained). An IEEE 802.11 binding is defined in [RFC5416] to support use of the CAPWAP protocol with IEEE 802.11 WLAN networks.
シンプルなIEEE 802.11 WTPsは、アクセスコントローラ（AC）によって管理される集中型のIEEE 802.11ワイヤレスローカルエリアネットワーク（WLAN）アーキテクチャの出現は、標準ベースの、相互運用可能なプロトコルが根本ワイヤレスネットワークの導入と管理を簡素化することが示唆されました。 WTPsは、無線および有線媒体を接続するそれらの主要タスクに関連する動的な管理および制御機能のセットを必要とします。 WTPsを管理するための伝統的なプロトコルは、HTTP、2特異的または非存在独自のレイヤ（WTPsが自己完結している場合）のいずれかを介して手動で静的な設定です。結合IEEE 802.11は、IEEE 802.11 WLANネットワークとCAPWAPプロトコルの使用をサポートするために、[RFC5416]で定義されています。
CAPWAP assumes a network configuration consisting of multiple WTPs communicating via the Internet Protocol (IP) to an AC. WTPs are viewed as remote radio frequency (RF) interfaces controlled by the AC. The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control). In Split MAC mode, all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. As shown in Figure 1, the wireless frames received from a mobile device, which is referred to in this specification as a Station (STA), are directly encapsulated by the WTP and forwarded to the AC.
CAPWAPはACへのインターネットプロトコル（IP）を介して通信する複数WTPsからなるネットワーク構成を想定しています。 WTPsはACにより制御される遠隔無線周波数（RF）インタフェースとみなされます。スプリットとローカルMAC（媒体アクセス制御）：CAPWAPプロトコルは、2つの動作モードをサポートしています。スプリットMACモードでは、すべてのL2無線データや管理フレームは、CAPWAPプロトコルを介してカプセル化され、ACとWTPとの間で交換しました。図1に示すように、無線フレームは、ステーション（STA）は、直接WTPによりカプセル化され、ACに転送されるように、本明細書で言及されているモバイルデバイスから受信しました。
+-+ wireless frames +-+
| |--------------------------------| |
| | +-+ | |
| |--------------| |---------------| |
| |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
Figure 1: Representative CAPWAP Architecture for Split MAC
図1：スプリットMACのための代表的なCAPWAPアーキテクチャ
The Local MAC mode of operation allows for the data frames to be either locally bridged or tunneled as 802.3 frames. The latter implies that the WTP performs the 802.11 Integration function. In either case, the L2 wireless management frames are processed locally by the WTP and then forwarded to the AC. Figure 2 shows the Local MAC mode, in which a station transmits a wireless frame that is encapsulated in an 802.3 frame and forwarded to the AC.
操作のローカルMACモードは、ローカル802.3フレームとして架橋またはトンネリングされるいずれかのデータフレームを可能にします。後者は、WTPが802.11統合機能を実行することを意味します。いずれの場合においても、L2無線管理フレームは、WTPにより局所的に処理され、その後、ACに転送されます。図2は、局が802.3フレームにカプセル化し、ACに転送された無線フレームを送信するローカルMACモードを示します。
+-+wireless frames +-+ 802.3 frames +-+
| |----------------| |--------------| |
| | | | | |
| |----------------| |--------------| |
| |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
Figure 2: Representative CAPWAP Architecture for Local MAC
図2：ローカルMACのための代表的なCAPWAPアーキテクチャ
Provisioning WTPs with security credentials and managing which WTPs are authorized to provide service are traditionally handled by proprietary solutions. Allowing these functions to be performed from a centralized AC in an interoperable fashion increases manageability and allows network operators to more tightly control their wireless network infrastructure.
WTPsがサービスを提供するために許可されているセキュリティ資格情報と管理とプロビジョニングWTPsは伝統的に独自のソリューションによって処理されます。これらの機能は、相互運用可能な方法で集中ACから実行されることを可能にすることは、管理が増加し、ネットワークオペレータは、より緊密にその無線ネットワークインフラストラクチャを制御することを可能にします。
The goals for the CAPWAP protocol are listed below:
CAPWAPプロトコルの目標は次のとおりです。
1. To centralize the authentication and policy enforcement functions for a wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs.
1.ワイヤレスネットワークの認証とポリシー適用機能を一元化します。 ACはまた、集中ブリッジ、転送、およびユーザトラフィックの暗号化を提供することができます。これらの機能の集中化は、有線LANと同様に、無線ネットワークへのネットワーク処理シリコンの機能を適用することによって、コスト削減とより高い効率を可能にします。
2. To enable shifting of the higher-level protocol processing from the WTP. This leaves the time-critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs, which are subject to severe cost pressure.
WTPからより高いレベルのプロトコル処理のシフトを可能にする2。これは深刻なコストの圧力を受けているWTPsで利用可能なコンピューティングパワーを効率的に利用して、無線制御およびWTPでのアクセスのタイムクリティカルなアプリケーションを残します。
3. To provide an extensible protocol that is not bound to a specific wireless technology. Extensibility is provided via a generic encapsulation and transport mechanism, enabling the CAPWAP protocol to be applied to many access point types in the future, via a specific wireless binding.
3.特定の無線技術にバインドされていない拡張可能なプロトコルを提供します。拡張性は、特異的結合の無線を介して、将来的に多くのアクセスポイントタイプに適用されるCAPWAPプロトコルを可能にする一般的なカプセル化およびトランスポート機構を介して設けられています。
The CAPWAP protocol concerns itself solely with the interface between the WTP and the AC. Inter-AC and station-to-AC communication are strictly outside the scope of this document.
単独WTPとACとの間のインターフェースを有するCAPWAPプロトコル懸念自体。インターACとステーションとAC通信は、この文書の範囲外に厳密です。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This section lists and acknowledges the authors of significant text and concepts included in this specification.
このセクションとは、この仕様書に含まれて重要なテキストや概念の著者を認めています。
The CAPWAP Working Group selected the Lightweight Access Point Protocol (LWAPP) [LWAPP] to be used as the basis of the CAPWAP protocol specification. The following people are authors of the LWAPP document:
CAPWAPワーキンググループはCAPWAPプロトコル仕様の基礎として使用するLightweightアクセスポイントプロトコル（LWAPP）LWAPP]を選択しました。次の人はLWAPP文書の作者です。
Bob O'Hara Email: bob.ohara@computer.org
ボブ・オハラEメール：bob.ohara@computer.org
Pat Calhoun, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-902-3240, Email: pcalhoun@cisco.com
パットカルフーン、シスコシステムズ、株式会社170西タスマン・ドライブ、サンノゼ、CA 95134電話：+1 408-902-3240、電子メール：pcalhoun@cisco.com
Rohit Suri, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-5548, Email: rsuri@cisco.com
Rohitスリ、シスコシステムズ、株式会社170西タスマン・ドライブ、サンノゼ、CA 95134電話：+1 408-853-5548、電子メール：rsuri@cisco.com
Nancy Cam Winget, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-0532, Email: ncamwing@cisco.com
ナンシー・カム・ウィンゲット、シスコシステムズ、株式会社170西タスマン・ドライブ、サンノゼ、CA 95134電話：+1 408-853-0532、電子メール：ncamwing@cisco.com
Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
スコット・ケリー、アルバネットワークス1322クロスマンアベニュー、サニーベール、CA 94089電話：+1 408-754-8408、電子メール：skelly@arubanetworks.com
Michael Glenn Williams, Nokia, Inc. 313 Fairchild Drive, Mountain View, CA 94043 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com
マイケル・グレン・ウィリアムズ、ノキア社313フェアチャイルドドライブ、マウンテンビュー、CA 94043電話：+1 650-714-7758、電子メール：Michael.G.Williams@Nokia.com
Sue Hares, Green Hills Software 825 Victors Way, Suite 100, Ann Arbor, MI 48108 Phone: +1 734 222 1610, Email: shares@ndzh.com
スーノウサギ、グリーンヒルズ・ソフトウェア825ビクターズウェイ、スイート100、アナーバー、MI 48108電話：+1 734 222 1610、Eメール：shares@ndzh.com
Datagram Transport Layer Security (DTLS) [RFC4347] is used as the security solution for the CAPWAP protocol. The following people are authors of significant DTLS-related text included in this document:
データグラムトランスポート層セキュリティ（DTLS）[RFC4347]はCAPWAPプロトコルのためのセキュリティソリューションとして使用されています。次の人は、この文書に含まれる重要なDTLS関連のテキストの著者です：
Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408 Email: skelly@arubanetworks.com
スコット・ケリー、アルバネットワークス1322クロスマンアベニュー、サニーベール、CA 94089電話：+1 408-754-8408電子メール：skelly@arubanetworks.com
Eric Rescorla, Network Resonance 2483 El Camino Real, #212,Palo Alto CA, 94303 Email: ekr@networkresonance.com
エリックレスコラ、ネットワークレゾナンス2483エル・カミノレアル、＃212、パロアルトCA、94303 Eメール：ekr@networkresonance.com
The concept of using DTLS to secure the CAPWAP protocol was part of the Secure Light Access Point Protocol (SLAPP) proposal [SLAPP]. The following people are authors of the SLAPP proposal:
CAPWAPプロトコルを確保するためにDTLSを使用するという概念は、セキュアライトアクセスポイントプロトコル（SLAPP）の提案[SLAPP]の一部でした。次の人はSLAPP提案の作者です。
Partha Narasimhan, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-480-4716 Email: partha@arubanetworks.com
Partha Narasimhan、アルバネットワークス1322クロスマンアベニュー、サニーベール、CA 94089電話：+1 408-480-4716電子メール：partha@arubanetworks.com
Dan Harkins Trapeze Networks 5753 W. Las Positas Blvd, Pleasanton, CA 94588 Phone: +1-925-474-2212 EMail: dharkins@trpz.com
ダンハーキンズブランコNetworksの5753 W.ラスポシタスブルバード、プレザントン、CA 94588電話：+ 1-925-474-2212 Eメール：dharkins@trpz.com
Subbu Ponnuswamy, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-1213 Email: subbu@arubanetworks.com
Subbu Ponnuswamy、アルバネットワークス1322クロスマンアベニュー、サニーベール、CA 94089電話：+1 408-754-1213電子メール：subbu@arubanetworks.com
The following individuals contributed significant security-related text to the document [RFC5418]:
以下の個人は、ドキュメント[RFC5418]への重要なセキュリティ関連のテキストを寄付しました：
T. Charles Clancy, Laboratory for Telecommunications Sciences, 8080 Greenmead Drive, College Park, MD 20740 Phone: +1 240-373-5069, Email: clancy@ltsnet.net
T.チャールズ・クランシー、テレコミュニケーション科学研究所、8080 Greenmeadドライブ、カレッジパーク、MD 20740電話：+1 240-373-5069、電子メール：clancy@ltsnet.net
Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: scott@hyperthought.com
スコット・ケリー、アルバネットワークス1322クロスマンアベニュー、サニーベール、CA 94089電話：+1 408-754-8408、電子メール：scott@hyperthought.com
Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein.
アクセスコントローラ（AC）：データプレーン、制御プレーン、管理プレーン、またはその中の組み合わせたネットワークインフラストラクチャにWTPへのアクセスを提供するネットワークエンティティ。
CAPWAP Control Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC control port, WTP control port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Control packets are sent and received.
CAPWAP制御チャネル：CAPWAP制御パケットが送信及び受信されるにわたってAC IPアドレス、WTP IPアドレス、AC制御ポート、WTP制御ポート、およびトランスポート層プロトコル（UDPまたはUDP-Liteの）によって定義された双方向フロー。
CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Data packets are sent and received.
CAPWAPデータチャネル：CAPWAPデータパケットが送信され、受信されるにわたってAC IPアドレス、WTP IPアドレス、ACデータポート、WTPデータポート、およびトランスポート層プロトコル（UDPまたはUDP-Liteの）によって定義された双方向フロー。
Station (STA): A device that contains an interface to a wireless medium (WM).
ステーション（STA）：無線媒体（WM）へのインターフェースを含むデバイス。
Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and wireless Physical Layer (PHY) to transmit and receive station traffic for wireless access networks.
ワイヤレスターミネーションポイント（WTP）：無線アクセスネットワークのステーショントラフィックを送信および受信するRFアンテナと無線物理層（PHY）を含む物理またはネットワークエンティティ。
This document uses additional terminology defined in [RFC3753].
この文書では、[RFC3753]で定義された追加的な用語を使用しています。
The CAPWAP protocol is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS. The underlying security-related protocol mechanisms of TLS have been successfully deployed for many years.
CAPWAPプロトコルはCAPWAPプロトコルトランスポート機構を介してACとWTP制御及びデータプレーンの通信を定義する一般的なプロトコルです。 CAPWAP制御メッセージ、および必要に応じてCAPWAPデータメッセージは、データグラムトランスポート層セキュリティ（DTLS）[RFC4347]を使用して固定されています。 DTLSは、TLSに基づいた標準化過程のIETFプロトコルです。 TLSの基礎となるセキュリティ関連のプロトコルメカニズムが正常に長年にわたって展開されています。
The CAPWAP protocol transport layer carries two types of payload, CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data messages encapsulate forwarded wireless frames. CAPWAP protocol Control messages are management messages exchanged between a WTP and an AC. The CAPWAP Data and Control packets are sent over separate UDP ports. Since both data and control packets can exceed the Maximum Transmission Unit (MTU) length, the payload of a CAPWAP Data or Control message can be fragmented. The fragmentation behavior is defined in Section 3.
CAPWAPプロトコルトランスポート層は、ペイロードの二種類、CAPWAPデータメッセージとCAPWAP制御メッセージを運びます。 CAPWAPデータメッセージは転送された無線フレームをカプセル化します。 CAPWAPプロトコル制御メッセージは、管理メッセージはWTPとACとの間で交換されます。 CAPWAPデータおよび制御パケットは、別々のUDPポートを介して送信されます。データおよび制御パケットの両方が、最大伝送単位（MTU）の長さを超えることができるので、CAPWAPデータまたは制御メッセージのペイロードを断片化することができます。フラグメンテーションの動作は第3節で定義されています。
The CAPWAP Protocol begins with a Discovery phase. The WTPs send a Discovery Request message, causing any Access Controller (AC) receiving the message to respond with a Discovery Response message. From the Discovery Response messages received, a WTP selects an AC with which to establish a secure DTLS session. In order to establish the secure DTLS connection, the WTP will need some amount of pre-provisioning, which is specified in Section 12.5. CAPWAP protocol messages will be fragmented to the maximum length discovered to be supported by the network.
CAPWAPプロトコルは、発見フェーズで始まります。 WTPsは発見応答メッセージで応答するメッセージを受信し、任意のアクセスコントローラ（AC）を引き起こし、ディスカバリ要求メッセージを送信します。受信ディスカバリー応答メッセージからは、WTPは、安全なDTLSセッションを確立するとの交流を選択します。安全なDTLS接続を確立するためには、WTPは、セクション12.5で指定された事前プロビジョニング、ある程度の量が必要になります。 CAPWAPプロトコル・メッセージは、ネットワークによってサポートされることが発見最大長さに断片化されるであろう。
Once the WTP and the AC have completed DTLS session establishment, a configuration exchange occurs in which both devices agree on version information. During this exchange, the WTP may receive provisioning settings. The WTP is then enabled for operation.
WTPとACがDTLSセッションの確立が完了したら、コンフィギュレーション・交換は、両方のデバイスがバージョン情報に同意するが発生します。この交換時には、WTPは、プロビジョニングの設定を受け取ることができます。 WTPは、動作可能です。
When the WTP and AC have completed the version and provision exchange and the WTP is enabled, the CAPWAP protocol is used to encapsulate the wireless data frames sent between the WTP and AC. The CAPWAP protocol will fragment the L2 frames if the size of the encapsulated wireless user data (Data) or protocol control (Management) frames causes the resulting CAPWAP protocol packet to exceed the MTU supported between the WTP and AC. Fragmented CAPWAP packets are reassembled to reconstitute the original encapsulated payload. MTU Discovery and Fragmentation are described in Section 3.
WTPとACバージョンと規定交換を完了し、WTPが有効になっている場合、CAPWAPプロトコルは、WTPとACとの間で送信される無線データフレームをカプセル化するために使用されます。カプセル化された無線ユーザデータ（DATA）又はプロトコル制御（管理）フレームのサイズがMTUをWTPとACとの間に支持超え得CAPWAPプロトコルパケットが発生する場合CAPWAPプロトコルがL2フレームを断片化します。断片化されたCAPWAPパケットは元のカプセル化されたペイロードを再構成する再組み立てされます。 MTUディスカバリおよび断片はセクション3に記載されています。
The CAPWAP protocol provides for the delivery of commands from the AC to the WTP for the management of stations that are communicating with the WTP. This may include the creation of local data structures in the WTP for the stations and the collection of statistical information about the communication between the WTP and the stations. The CAPWAP protocol provides a mechanism for the AC to obtain statistical information collected by the WTP.
CAPWAPプロトコルはWTPと通信している局の管理のためのWTPにACからのコマンドの送達を提供します。これは、ステーションとWTPと局間の通信に関する統計情報の収集のためのWTP内のローカルデータ構造の作成を含むことができます。 CAPWAPプロトコルは、ACは、WTPにより収集された統計情報を取得するためのメカニズムを提供します。
The CAPWAP protocol provides for a keep-alive feature that preserves the communication channel between the WTP and AC. If the AC fails to appear alive, the WTP will try to discover a new AC.
CAPWAPプロトコルはWTPとACとの間の通信チャネルを保持キープアライブ機能を提供します。 ACが生き表示されない場合、WTPは新しいACを発見しようとします。
The CAPWAP protocol is independent of a specific WTP radio technology, as well its associated wireless link layer protocol. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST follow the binding requirements defined for that technology.
CAPWAPプロトコルは、特定のWTPの無線技術とは無関係に、ならびにそれに関連する無線リンク層プロトコルです。 CAPWAPプロトコルの要素は、標準的な方法で、各無線技術の特定のニーズに対応するように設計されています。特定の無線技術のためのCAPWAPプロトコルの実装は、その技術のために定義された結合要件に従わなければなりません。
When defining a binding for wireless technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. At a minimum, a binding MUST provide:
無線技術のバインディングを定義する場合、著者は、技術固有のメッセージのために必要なすべての定義とそれらのメッセージのためのすべての技術固有のメッセージ要素を含まなければなりません。最低でも、結合は提供しなければなりません：
1. The definition for a binding-specific Statistics message element, carried in the WTP Event Request message.
WTPイベント要求メッセージで運ば結合固有の統計メッセージ要素1.定義。
2. A message element carried in the Station Configuration Request message to configure station information on the WTP.
2.ステーション構成要求メッセージで運ばれたメッセージ要素は、WTPでステーション情報を設定します。
3. A WTP Radio Information message element carried in the Discovery, Primary Discovery, and Join Request and Response messages, indicating the binding-specific radio types supported at the WTP and AC.
3. A WTP無線情報メッセージ検出、プライマリディスカバリで運ば要素、およびWTPとACに支持結合特異無線タイプを示す、要求メッセージと応答メッセージに参加します。
If technology-specific message elements are required for any of the existing CAPWAP messages defined in this specification, they MUST also be defined in the technology binding document.
技術固有のメッセージ要素は、この仕様で定義されている既存のCAPWAPメッセージのいずれかのために必要とされる場合は、それらも技術バインディング文書で定義する必要があります。
The naming of binding-specific message elements MUST begin with the name of the technology type, e.g., the binding for IEEE 802.11, provided in [RFC5416], begins with "IEEE 802.11".
バインディング固有のメッセージ要素の命名は、技術タイプの名前で始まる必要があり、例えば、[RFC5416]に設けられたIEEE 802.11、バインディングは、「IEEE 802.11」で始まります。
The CAPWAP binding concept MUST also be used in any future specifications that add functionality to either the base CAPWAP protocol specification, or any published CAPWAP binding specification. A separate WTP Radio Information message element MUST be created to properly advertise support for the specification. This mechanism allows for future protocol extensibility, while providing the necessary capabilities advertisement, through the WTP Radio Information message element, to ensure WTP/AC interoperability.
CAPWAP結合コンセプトは、ベースCAPWAPプロトコル仕様、または任意の公表CAPWAPバインディング仕様のいずれかに機能を追加する任意の将来の仕様で使用しなければなりません。別のWTPラジオ情報メッセージ要素が適切に仕様をサポートすることを通知するために作成する必要があります。 WTP / AC相互運用性を確保するために、WTPラジオ情報メッセージ要素を介して、必要な機能の広告を提供しながら、このメカニズムは、将来のプロトコルの拡張を可能にします。
This section describes the session establishment process message exchanges between a CAPWAP WTP and AC. The annotated ladder diagram shows the AC on the right, the WTP on the left, and assumes the use of certificates for DTLS authentication. The CAPWAP protocol state machine is described in detail in Section 2.3. Note that DTLS allows certain messages to be aggregated into a single frame, which is denoted via an asterisk in Figure 3.
このセクションでは、CAPWAP WTPとACとの間のセッション確立処理のメッセージ交換を記述する。注釈付きのラダー図は右側のAC、左のWTPを示しており、DTLS認証用の証明書の使用を想定しています。 CAPWAPプロトコルステートマシンは、セクション2.3に詳細に記載されています。 DTLSは、特定のメッセージは、図3にアスタリスクを介して示される単一のフレームに集約することが可能になることに留意されたいです。
============ ============
WTP AC
============ ============
[----------- begin optional discovery ------------]
Discover Request
------------------------------------>
Discover Response
<------------------------------------
[----------- end optional discovery ------------]
(-- begin DTLS handshake --)
（ - 始まりDTLSはハンドシェイク - ）
ClientHello
------------------------------------>
HelloVerifyRequest (with cookie)
<------------------------------------
ClientHello (with cookie)
------------------------------------>
ServerHello,
Certificate,
ServerHelloDone*
<------------------------------------
(-- WTP callout for AC authorization --)
（ - ACの承認のためのWTPコールアウト - ）
Certificate (optional),
ClientKeyExchange,
CertificateVerify (optional),
ChangeCipherSpec,
Finished*
------------------------------------>
(-- AC callout for WTP authorization --)
（ - WTPの承認のためのACコールアウト - ）
ChangeCipherSpec,
Finished*
<------------------------------------
(-- DTLS session is established now --)
（ - DTLSセッションは、現在確立されています - ）
Join Request
------------------------------------>
Join Response
<------------------------------------
[-- Join State Complete --]
(-- assume image is up to date --)
（ - イメージが最新のものであると仮定 - ）
Configuration Status Request
------------------------------------>
Configuration Status Response
<------------------------------------
[-- Configure State Complete --]
Change State Event Request
------------------------------------>
Change State Event Response
<------------------------------------
[-- Data Check State Complete --]
(-- enter RUN state --)
（ - RUN状態に入ります - ）
:
:
Echo Request
------------------------------------>
Echo Response
<------------------------------------
:
:
Event Request
------------------------------------>
Event Response
<------------------------------------
:
:
Figure 3: CAPWAP Control Protocol Exchange
図3：CAPWAP制御プロトコル交換
At the end of the illustrated CAPWAP message exchange, the AC and WTP are securely exchanging CAPWAP Control messages. This illustration is provided to clarify protocol operation, and does not include any possible error conditions. Section 2.3 provides a detailed description of the corresponding state machine.
図示のCAPWAPメッセージ交換の終了時に、ACおよびWTPを確実CAPWAP制御メッセージを交換しています。この図は、プロトコルの動作を明確にするために設けられており、任意の可能なエラー条件が含まれていません。セクション2.3は、対応するステートマシンの詳細な説明を提供します。
The following state diagram represents the lifecycle of a WTP-AC session. Use of DTLS by the CAPWAP protocol results in the juxtaposition of two nominally separate yet tightly bound state machines. The DTLS and CAPWAP state machines are coupled through an API consisting of commands (see Section 2.3.2.1) and notifications (see Section 2.3.2.2). Certain transitions in the DTLS state machine are triggered by commands from the CAPWAP state machine, while certain transitions in the CAPWAP state machine are triggered by notifications from the DTLS state machine.
次の状態図は、WTP-ACセッションのライフサイクルを表します。 2台の名目上の別々まだ強固に結合した状態マシンの並置でCAPWAPプロトコルの結果によるDTLSを使用します。 DTLSとCAPWAPステートマシンは、コマンドからなるAPIを介して接続されているとの通知（2.3.2.2項を参照してください）（2.3.2.1項を参照してください）。 CAPWAP状態マシンにおける特定の遷移がDTLSステートマシンからの通知によってトリガーされる間DTLSステートマシンにおける特定の遷移は、CAPWAP状態マシンからのコマンドによってトリガされます。
/-------------------------------------\
| /-------------------------\|
| p| ||
| q+----------+ r +------------+ ||
| | Run |-->| Reset |-\||
| +----------+ +------------+ |||
n| o ^ ^ ^ s|||
+------------+--------/ | | |||
| Data Check | /-------/ | |||
+------------+<-------\ | | |||
| | | |||
/------------------+--------\ | |||
f| m| h| j v k| |||
+--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data ||||
+--------+ n +-----------+ +--------------+|||
^ |g i| l| |||
| | \-------------------\ | |||
| \--------------------------------------\| | |||
\------------------------\ || | |||
/--------------<----------------+---------------\ || | |||
| /------------<----------------+-------------\ | || | |||
| | 4 |d t| | vv v vvv
| | +----------------+ +--------------+ +-----------+
| | | DTLS Setup | | DTLS Connect |-->| DTLS TD |
/-|-|---+----------------+ +--------------+ e +-----------+
| | | |$ ^ ^ |5 ^6 ^ ^ |w
v v v | | | | \-------\ | | |
| | | | | | \---------\ | | /-----------/ |
| | | | | \--\ | | | | |
| | | | | | | | | | |
| | | v 3| 1 |% # v | |a |b v
| | \->+------+-->+------+ +-----------+ +--------+
| | | Idle | | Disc | | Authorize | | Dead |
| | +------+<--+------+ +-----------+ +--------+
| | ^ 0^ 2 |!
| | | | | +-------+
*| |u | \---------+---| Start |
| | |@ | +-------+
| \->+---------+<------/
\--->| Sulking |
+---------+&
Figure 4: CAPWAP Integrated State Machine
図4：CAPWAP統合ステートマシン
The CAPWAP protocol state machine, depicted above, is used by both the AC and the WTP. In cases where states are not shared (i.e., not implemented in one or the other of the AC or WTP), this is explicitly called out in the transition descriptions below. For every state defined, only certain messages are permitted to be sent and received. The CAPWAP Control message definitions specify the state(s) in which each message is valid.
上記図示CAPWAPプロトコルステートマシンは、ACおよびWTPの両方で使用されています。状態が共有されていない場合（すなわち、一つまたはACまたはWTPの他に実装されていない）、これは、明示的に以下の遷移の説明に呼び出されます。定義されたすべての状態のために、唯一の特定のメッセージを送信し、受信することが許可されています。 CAPWAP制御メッセージの定義は、各メッセージが有効である状態（複数可）を指定します。
Since the WTP only communicates with a single AC, it only has a single instance of the CAPWAP state machine. The state machine works differently on the AC since it communicates with many WTPs. The AC uses the concept of three threads. Note that the term thread used here does not necessarily imply that implementers must use threads, but it is one possible way of implementing the AC's state machine.
WTPは、単一のACと通信するので、それが唯一のCAPWAP状態機械の単一のインスタンスを有します。それは多くのWTPsと通信するので、状態マシンは、AC上で動作が異なります。 ACは、3つのスレッドの概念を使用しています。ここで使用する用語のスレッドは、必ずしも実装がスレッドを使用しなければならないことを意味するものではありませんが、それはACのステートマシンを実装するための1つの可能な方法であることに注意してください。
Listener Thread: The AC's Listener thread handles inbound DTLS session establishment requests, through the DTLSListen command. Upon creation, the Listener thread starts in the DTLS Setup state. Once a DTLS session has been validated, which occurs when the state machine enters the "Authorize" state, the Listener thread creates a WTP session-specific Service thread and state context. The state machine transitions in Figure 4 are represented by numerals. It is necessary for the AC to protect itself against various attacks that exist with non-authenticated frames. See Section 12 for more information.
リスナースレッド：ACのリスナースレッドがDTLSListenコマンドによって、インバウンドDTLSセッション確立要求を処理します。作成時に、リスナースレッドはDTLSの設定状態で起動します。 DTLSセッションが検証されたら、ステートマシンは「承認」状態に入ったときに発生する、リスナースレッドは、WTPのセッション固有のサービススレッドと状態のコンテキストを作成します。図4のステートマシン遷移は、数字で表されています。 ACは、非認証フレームに存在するさまざまな攻撃から自身を保護する必要があります。詳細については、セクション12を参照してください。
Discovery Thread: The AC's Discovery thread is responsible for receiving, and responding to, Discovery Request messages. The state machine transitions in Figure 4 are represented by numerals. Note that the Discovery thread does not maintain any per-WTP-specific context information, and a single state context exists. It is necessary for the AC to protect itself against various attacks that exist with non-authenticated frames. See Section 12 for more information.
ディスカバリースレッド：ACの発見スレッドが受信し、ディスカバリ要求メッセージに応答する責任があります。図4のステートマシン遷移は、数字で表されています。ディスカバリスレッドが任意ごとWTP固有のコンテキスト情報を維持しないことに注意してください、そして単一の状態コンテキストが存在します。 ACは、非認証フレームに存在するさまざまな攻撃から自身を保護する必要があります。詳細については、セクション12を参照してください。
Service Thread: The AC's Service thread handles the per-WTP states, and one such thread exists per-WTP connection. This thread is created by the Listener thread when the Authorize state is reached. When created, the Service thread inherits a copy of the state machine context from the Listener thread. When communication with the WTP is complete, the Service thread is terminated and all associated resources are released. The state machine transitions in Figure 4 are represented by alphabetic and punctuation characters.
サービススレッド：ACのサービススレッドごとのWTPの状態を処理し、そのようなスレッドごとのWTPの接続が存在します。承認状態に達したときに、このスレッドはリスナースレッドによって作成されます。作成された場合には、サービススレッドはリスナースレッドからステートマシンのコンテキストのコピーを継承します。 WTPとの通信が完了すると、サービスのスレッドが終了し、関連するすべてのリソースが解放されます。図4のステートマシン遷移は英字と句読点文字で表されます。
This section describes the various state transitions, and the events that cause them. This section does not discuss interactions between DTLS- and CAPWAP-specific states. Those interactions, and DTLS-specific states and transitions, are discussed in Section 2.3.2.
このセクションでは、さまざまな状態遷移、およびそれらの原因となるイベントについて説明します。このセクションでは、DTLS-とCAPWAP固有状態間の相互作用については説明しません。これらの相互作用、及びDTLS固有状態及び遷移は、セクション2.3.2に記載されています。
Start to Idle (0): This transition occurs once device initialization is complete.
Idleに開始します（0）：デバイスの初期化が完了すると、この遷移が発生しました。
WTP: This state transition is used to start the WTP's CAPWAP state machine.
WTP：この状態遷移はWTPのCAPWAP状態マシンを起動するために使用されます。
AC: The AC creates the Discovery and Listener threads and starts the CAPWAP state machine.
AC：ACディスカバリーとリスナースレッドを作成し、CAPWAPステートマシンを起動します。
Idle to Discovery (1): This transition occurs to support the CAPWAP discovery process.
ディスカバリーアイドル（1）：この遷移は、CAPWAPディスカバリプロセスをサポートするために発生します。
WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request message (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 4.7). The WTP resets the DiscoveryCount counter to zero (0) (see Section 4.8). The WTP also clears all information from ACs it may have received during a previous Discovery phase.
WTP：WTP（セクション5.1を参照）前第ディスカバリ要求メッセージを送信する発見状態に入ります。この状態に入ると、WTPは（4.7節を参照）DiscoveryIntervalタイマーを設定します。 WTP（0）（セクション4.8参照）がゼロにDiscoveryCountカウンタをリセットします。 WTPはまた、以前発見フェーズ中に受信している可能性がACSからのすべての情報をクリアします。
AC: This state transition is executed by the AC's Discovery thread, and occurs when a Discovery Request message is received. The AC SHOULD respond with a Discovery Response message (see Section 5.2).
AC：この状態遷移はACのディスカバリスレッドによって実行され、ディスカバリ要求メッセージを受信したときに発生されます。 ACは、ディスカバリ応答メッセージで応答すべきである（5.2節を参照してください）。
Discovery to Discovery (#): In the Discovery state, the WTP determines to which AC to connect.
ディスカバリ（＃）の発見：発見状態では、WTPは、ACが接続するかを決定します。
WTP: This transition occurs when the DiscoveryInterval timer expires. If the WTP is configured with a list of ACs, it transmits a Discovery Request message to every AC from which it has not received a Discovery Response message. For every transition to this event, the WTP increments the DiscoveryCount counter. See Section 5.1 for more information on how the WTP knows the ACs to which it should transmit the Discovery Request messages. The WTP restarts the DiscoveryInterval timer whenever it transmits Discovery Request messages.
WTP：DiscoveryIntervalタイマーが満了したときにこの遷移が発生します。 WTPがACSのリストで構成されている場合、それは発見応答メッセージを受信していない、そこからすべてのACにディスカバリ要求メッセージを送信します。このイベントへのすべての移行については、WTPはDiscoveryCountカウンタをインクリメント。 WTPは、それがディスカバリ要求メッセージを送信先となるACSを知っている方法の詳細については、セクション5.1を参照してください。 WTPは、ディスカバリ要求メッセージを送信するたびにDiscoveryIntervalタイマーを再起動します。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
Discovery to Idle (2): This transition occurs on the AC's Discovery thread when the Discovery processing is complete.
発見は、アイドル（2）：ディスカバリー処理が完了したときにこの遷移は、ACの発見スレッドで発生します。
WTP: This is an invalid state transition for the WTP.
WTP：これはWTPのための無効な状態遷移です。
AC: This state transition is executed by the AC's Discovery thread when it has transmitted the Discovery Response, in response to a Discovery Request.
AC：それはディスカバリー要求に応答して、ディスカバリー・レスポンスを送信したときに、この状態遷移はACのディスカバリーのスレッドによって実行されます。
Discovery to Sulking (!): This transition occurs on a WTP when AC Discovery fails.
Sulkingに発見（！）：この移行は、ACディスカバリーが失敗したWTPで発生します。
WTP: The WTP enters this state when the DiscoveryInterval timer expires and the DiscoveryCount variable is equal to the MaxDiscoveries variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP protocol messages MUST be ignored.
WTP：DiscoveryIntervalタイマーが満了とDiscoveryCount変数は、変数MaxDiscoveries（4.8節を参照）に等しい場合WTPがこの状態に入ります。この状態に入ると、WTPはSilentIntervalタイマーを起動する必要があります。 Sulking状態にある一方で、受信したすべてのCAPWAPプロトコルメッセージは無視しなければなりません。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
Sulking to Idle (@): This transition occurs on a WTP when it must restart the Discovery phase.
（@）IdleにSulking：それはディスカバリー・フェーズを再起動する必要があります場合は、この移行は、WTPで発生します。
WTP: The WTP enters this state when the SilentInterval timer (see Section 4.7) expires. The FailedDTLSSessionCount, DiscoveryCount, and FailedDTLSAuthFailCount counters are reset to zero.
WTP：SilentIntervalタイマーは（4.7節を参照）を満了したときにWTPがこの状態に入ります。 FailedDTLSSessionCount、DiscoveryCount、およびFailedDTLSAuthFailCountカウンタがゼロにリセットされます。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
Sulking to Sulking (&): The Sulking state provides the silent period, minimizing the possibility for Denial-of-Service (DoS) attacks.
SulkingにSulking（＆）：Sulking状態がサービス拒否（DoS）攻撃の可能性を最小限に抑える、サイレント期間を提供します。
WTP: All packets received from the AC while in the sulking state are ignored.
WTPは：sulking状態で無視されている間、すべてのパケットがACから受け取りました。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
Idle to DTLS Setup (3): This transition occurs to establish a secure DTLS session with the peer.
DTLSセットアップアイドル（3）：この遷移は、ピアとのセキュアDTLSセッションを確立するために発生します。
WTP: The WTP initiates this transition by invoking the DTLSStart command (see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC and the WaitDTLS timer is started (see Section 4.7). When the Discovery phase is bypassed, it is assumed the WTP has locally configured ACs.
WTP：WTPは（4.7節を参照）DTLSStartコマンドを呼び出すことによって、この移行を開始します（セクション2.3.2.1を参照）、選ばれたACでDTLSセッションの確立を開始し、WaitDTLSタイマーが開始されています。発見フェーズがバイパスされる場合は、WTPがローカルACSを構成しているものとします。
AC: Upon entering the Idle state from the Start state, the newly created Listener thread automatically transitions to the DTLS Setup and invokes the DTLSListen command (see Section 2.3.2.1), and the WaitDTLS timer is started (see Section 4.7).
AC：スタート状態からアイドル状態に入ると、新しく作成されたリスナースレッドは自動的にDTLSの設定に移行し、DTLSListenコマンドを起動します（2.3.2.1項を参照）、およびWaitDTLSタイマーが開始される（4.7節を参照してください）。
Discovery to DTLS Setup (%): This transition occurs to establish a secure DTLS session with the peer.
DTLSセットアップ（％）の発見：この遷移は、ピアとのセキュアDTLSセッションを確立するために発生します。
WTP: The WTP initiates this transition by invoking the DTLSStart command (see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC. The decision of to which AC to connect is the result of the Discovery phase, which is described in Section 3.3.
WTP：WTPは、（セクション2.3.2.1を参照）DTLSStartコマンドを呼び出すことによって、この移行を開始する選択されたACとDTLSセッションの確立を開始します。接続するためにACの決定は、セクション3.3に記載されている発見フェーズの結果です。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
DTLS Setup to Idle ($): This transition occurs when the DTLS connection setup fails.
DTLSのセットアップが（$）をIdleに：DTLS接続のセットアップが失敗したときにこの遷移が発生します。
WTP: The WTP initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired.
WTP：それはDTLSからDTLSEstablishFail通知を受信した場合WTP（セクション2.3.2.2を参照）、この状態遷移を開始し、FailedDTLSSessionCount又はFailedDTLSAuthFailCountカウンタ（セクション4.8を参照）MaxFailedDTLSSessionRetry変数の値に達していません。このエラー通知は、安全なDTLSセッションの確立を中止します。この通知を受信した場合、FailedDTLSSessionCountカウンタがインクリメントされます。 WaitDTLSタイマーが期限切れになった場合には、この状態遷移が発生します。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
DTLS Setup to Sulking (*): This transition occurs when repeated attempts to set up the DTLS connection have failed.
Sulking（*）にDTLSセットアップ：DTLS接続を設定するために繰り返し試みが失敗したときに、この移行が発生します。
WTP: The WTP enters this state when the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP and DTLS protocol messages received MUST be ignored.
WTP：WTPはFailedDTLSSessionCount又はFailedDTLSAuthFailCountカウンタ（セクション4.8を参照）MaxFailedDTLSSessionRetry変数の値に達したときにこの状態に入ります。この状態に入ると、WTPはSilentIntervalタイマーを起動する必要があります。 Sulking状態にあるものの、すべてが受信CAPWAPとDTLSプロトコルメッセージは無視しなければなりません受け取りました。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS Session failed to be established.
DTLSセットアップにDTLSセットアップ（4）：DTLSセッションを確立することに失敗した場合、この遷移が起こります。
WTP: This is an invalid state transition for the WTP.
WTP：これはWTPのための無効な状態遷移です。
AC: The AC's Listener initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. The Listener thread then invokes the DTLSListen command (see Section 2.3.2.1).
AC：それはDTLS（2.3.2.2項を参照）からDTLSEstablishFail通知を受信したときにACのリスナーは、この状態遷移を開始します。このエラー通知は、安全なDTLSセッションの確立を中止します。この通知を受信した場合、FailedDTLSSessionCountカウンタがインクリメントされます。リスナースレッドは、（2.3.2.1項を参照）DTLSListenコマンドを起動します。
DTLS Setup to Authorize (5): This transition occurs when an incoming DTLS session is being established, and the DTLS stack needs authorization to proceed with the session establishment.
認可するDTLSセットアップ（5）：着信DTLSセッションが確立され、及びDTLSスタックがセッション確立を続行する許可を必要とする場合、この遷移が起こります。
WTP: This state transition occurs when the WTP receives the DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon entering this state, the WTP performs an authorization check against the AC credentials. See Section 2.4.4 for more information on AC authorization.
WTP：WTP（セクション2.3.2.2を参照）DTLSPeerAuthorize通知を受信した場合、この状態遷移が起こります。この状態に入ると、WTPはACの資格に対する認証チェックを実行します。 ACの承認についての詳細は、2.4.4項を参照してください。
AC: This state transition is handled by the AC's Listener thread when the DTLS module initiates the DTLSPeerAuthorize notification (see Section 2.3.2.2). The Listener thread forks an instance of the Service thread, along with a copy of the state context. Once created, the Service thread performs an authorization check against the WTP credentials. See Section 2.4.4 for more information on WTP authorization.
AC：この状態遷移は、（セクション2.3.2.2を参照）DTLSモジュールはDTLSPeerAuthorize通知を開始したときにACのリスナー・スレッドによって処理されます。リスナースレッドフォーク状態コンテキストのコピーと一緒にサービスのスレッドのインスタンスを、。作成した後は、サービススレッドはWTPの資格に対する認証チェックを実行します。 WTPの認証の詳細については、セクション2.4.4を参照してください。
Authorize to DTLS Setup (6): This transition is executed by the Listener thread to enable it to listen for new incoming sessions.
DTLSセットアップするには、authorize（6）：この移行は、新しい着信セッションをリッスンすることを可能にするために、リスナーのスレッドで実行されます。
WTP: This is an invalid state transition for the WTP.
WTP：これはWTPのための無効な状態遷移です。
AC: This state transition occurs when the AC's Listener thread has created the WTP context and the Service thread. The Listener thread then invokes the DTLSListen command (see Section 2.3.2.1).
AC：ACのリスナースレッドがWTPコンテキストおよびサービスのスレッドを作成したときに、この状態遷移が発生します。リスナースレッドは、（2.3.2.1項を参照）DTLSListenコマンドを起動します。
Authorize to DTLS Connect (a): This transition occurs to notify the DTLS stack that the session should be established.
DTLS接続を許可（A）：この遷移はDTLSセッションが確立されるべきであることをスタックに通知するために発生します。
WTP: This state transition occurs when the WTP has successfully authorized the AC's credentials (see Section 2.4.4). This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1).
WTP：WTPが正常にACの資格情報（セクション2.4.4を参照）を承認したときに、この状態遷移が発生します。これはDTLSAccept DTLSコマンドを呼び出すことによって行われます（2.3.2.1項を参照してください）。
AC: This state transition occurs when the AC has successfully authorized the WTP's credentials (see Section 2.4.4). This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1).
AC：ACが正常にWTPの資格情報（セクション2.4.4を参照）を承認したときに、この状態遷移が発生します。これはDTLSAccept DTLSコマンドを呼び出すことによって行われます（2.3.2.1項を参照してください）。
Authorize to DTLS Teardown (b): This transition occurs to notify the DTLS stack that the session should be aborted.
DTLSティアダウン（B）に許可：この遷移はDTLSセッションが中止されるべきであることをスタックに通知するために発生します。
WTP: This state transition occurs when the WTP has been unable to authorize the AC, using the AC credentials. The WTP then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTPはACの資格情報を使用して、ACを許可することができなかった場合、この状態遷移が起こります。 WTPは、その後DTLSAbortSessionコマンドを呼び出すことによってDTLSセッションを中止します（2.3.2.1項を参照してください）。 WaitDTLSタイマーが期限切れになった場合には、この状態遷移が発生します。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: This state transition occurs when the AC has been unable to authorize the WTP, using the WTP credentials. The AC then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：ACはWTPの資格情報を使用して、WTPを許可することができなかった場合、この状態遷移が起こります。 ACはその後、DTLSAbortSessionコマンドを呼び出すことによってDTLSセッションを中止します（2.3.2.1項を参照してください）。 WaitDTLSタイマーが期限切れになった場合には、この状態遷移が発生します。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Session failed to be established.
DTLSティアダウンにDTLS接続（C）：DTLSセッションを確立することに失敗した場合、この遷移が起こります。
WTP: This state transition occurs when the WTP receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this transition occurs due to the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount is incremented; otherwise, the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTPはDTLSセッションがうまく確立されなかったことを示す（セクション2.3.2.2参照）DTLSAborted又はDTLSAuthenticateFail通知のいずれかを受信した場合、この状態遷移が起こります。この遷移はDTLSAuthenticateFail通知のために発生した場合、FailedDTLSAuthFailCountがインクリメントされます。それ以外の場合は、FailedDTLSSessionCountカウンタがインクリメントされます。 WaitDTLSタイマーが期限切れになった場合には、この状態遷移が発生します。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: This state transition occurs when the AC receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established, and both of the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：ACはDTLSAborted又はDTLSAuthenticateFail通知のいずれかを受信する（セクション2.3.2.2を参照）、DTLSセッションがうまく確立されなかったことを示し、そしてFailedDTLSAuthFailCountとFailedDTLSSessionCountカウンタの両方がMaxFailedDTLSSessionRetryの値に達していない場合、この状態遷移が起こります変数（4.8節を参照してください）。 WaitDTLSタイマーが期限切れになった場合には、この状態遷移が発生します。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established.
DTLS接続は、（d）に参加するには：DTLSセッションが正常に確立されたときに、この遷移が発生します。
WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the
WTP：WTPはDTLSセッションがうまく確立されたことを示す（セクション2.3.2.2を参照）DTLSEstablished通知を受信した場合、この状態遷移が起こります。この通知を受信した場合、
FailedDTLSSessionCount counter is set to zero. The WTP
enters the Join state by transmitting the Join Request to
the AC. The WTP stops the WaitDTLS timer.
AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The AC stops the WaitDTLS timer, and starts the WaitJoin timer.
AC：ACはDTLSセッションが正常に確立されたことを示す、DTLSEstablished通知（セクション2.3.2.2を参照）を受信すると、この状態遷移が起こります。この通知を受信したとき、FailedDTLSSessionCountカウンタはゼロに設定されます。 ACはWaitDTLSタイマーを停止し、WaitJoinタイマーを開始します。
Join to DTLS Teardown (e): This transition occurs when the join process has failed.
DTLSティアダウン（E）に参加：参加プロセスが失敗したときに、この移行が発生します。
WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, or if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTPがエラーを含む結果コードメッセージ要素と加入応答メッセージを受信したとき、または加入応答メッセージにACによって提供される画像識別子がWTPの現在実行中のファームウェアのバージョンとは異なり、WTPを持っている場合は、この状態遷移が発生しますその不揮発性メモリに要求された画像。これは、（セクション2.3.2.1を参照）DTLSShutdownコマンドを開始するためのWTPの原因となります。 DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect：WTPは、以下のDTLSのいずれかの通知を受信した場合、この移行にも発生します。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: This state transition occurs either if the WaitJoin timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：この状態遷移はWaitJoinタイマが満了した場合、またはACがエラーを含む結果コードメッセージ要素と加入応答メッセージを送信した場合のいずれかで起こります。これは、（セクション2.3.2.1を参照）DTLSShutdownコマンドを開始するために、ACの原因となります。 DTLSAborted、DTLSReassemblyFailure、又はDTLSPeerDisconnect：ACは、以下DTLS通知のいずれかを受信した場合、この遷移が発生します。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
Join to Image Data (f): This state transition is used by the WTP and the AC to download executable firmware.
画像データ（F）に参加：この状態遷移は、実行可能なファームウェアをダウンロードしてWTPとACで使用されています。
WTP: The WTP enters the Image Data state when it receives a successful Join Response message and determines that the software version in the Image Identifier message element is not the same as its currently running image. The WTP also detects that the requested image version is not currently available in the WTP's non-volatile storage (see Section 9.1 for a full description of the firmware download process). The WTP initializes the EchoInterval timer (see
WTP：それは成功した加入応答メッセージを受信して、画像識別メッセージ要素におけるソフトウェアのバージョンが、現在実行中のイメージと同じでないと判断した場合WTPは、画像データの状態になります。 WTPはまた、要求されたイメージのバージョンは現在、WTPの不揮発性ストレージ（ファームウェアのダウンロード・プロセスの完全な記述については、セクション9.1を参照）で利用できないことを検出します。 WTPはEchoIntervalタイマーを初期化する（参照
Section 4.7), and transmits the Image Data Request message
(see Section 9.1.1) requesting the start of the firmware
download.
AC: This state transition occurs when the AC receives the Image Data Request message from the WTP, after having sent its Join Response to the WTP. The AC stops the WaitJoin timer. The AC MUST transmit an Image Data Response message (see Section 9.1.2) to the WTP, which includes a portion of the firmware.
ACは：ACはWTPへの加入応答を送信した後、WTPからの画像データ要求メッセージを受信したときに、この状態遷移が発生します。 ACはWaitJoinタイマーを停止します。 ACは、ファームウェアの一部を含むWTPに（セクション9.1.2を参照）画像データ応答メッセージを送信しなければなりません。
Join to Configure (g): This state transition is used by the WTP and the AC to exchange configuration information.
（g）を構成する参加：この状態遷移は、コンフィギュレーション情報を交換するためにWTPとACで使用されます。
WTP: The WTP enters the Configure state when it receives a successful Join Response message, and determines that the included Image Identifier message element is the same as its currently running image. The WTP transmits the Configuration Status Request message (see Section 8.2) to the AC with message elements describing its current configuration.
WTP：WTPは、それが成功した加入応答メッセージを受信したときの設定状態になり、そして含まれる画像識別子のメッセージ要素が現在実行中のイメージと同じであると判断します。 WTPは、その現在の構成を説明するメッセージ要素を有するACに設定状態要求メッセージ（セクション8.2を参照）を送信します。
AC: This state transition occurs when it receives the Configuration Status Request message from the WTP (see Section 8.2), which MAY include specific message elements to override the WTP's configuration. The AC stops the WaitJoin timer. The AC transmits the Configuration Status Response message (see Section 8.3) and starts the ChangeStatePendingTimer timer (see Section 4.7).
AC：それはWTPの設定を上書きするには、特定のメッセージの要素を含んでもよいWTP（8.2節を参照）、から構成ステータス要求メッセージを受信したときに、この状態遷移が発生します。 ACはWaitJoinタイマーを停止します。 ACは、設定ステータス応答メッセージを送信する（8.3節を参照）、ChangeStatePendingTimerタイマー（4.7節を参照）を開始します。
Configure to Reset (h): This state transition is used to reset the connection either due to an error during the configuration phase, or when the WTP determines it needs to reset in order for the new configuration to take effect. The CAPWAP Reset command is used to indicate to the peer that it will initiate a DTLS teardown.
（h）をリセットするように構成：この状態遷移は、構成フェーズエラーに起因するいずれかの接続をリセットするために使用され、またはWTPが判断した場合、それを有効にする新しい構成のためにリセットする必要があります。 CAPWAPリセットコマンドは、それがDTLSのティアダウンを開始するピアに示すために使用されます。
WTP: The WTP enters the Reset state when it receives a Configuration Status Response message indicating an error or when it determines that a reset of the WTP is required, due to the characteristics of a new configuration.
WTP：それはWTPのリセットにより新しい構成の特性に、必要であると判断した場合にエラーを示すか、コンフィギュレーション・ステータス応答メッセージを受信した場合WTPはリセット状態に入ります。
AC: The AC transitions to the Reset state when it receives a Change State Event message from the WTP that contains an error for which AC policy does not permit the WTP to provide service. This state transition also occurs when the AC ChangeStatePendingTimer timer expires.
AC：それはACポリシーは、サービスを提供するために、WTPを許可しないためにエラーが含まれていWTPからの変更状態イベントメッセージを受信したときにACがリセット状態に移行します。 AC ChangeStatePendingTimerタイマーが満了したとき、この状態遷移が発生します。
Configure to DTLS Teardown (i): This transition occurs when the configuration process aborts due to a DTLS error.
DTLSティアダウン（I）に設定する：構成プロセスはDTLSエラーのため中止したときにこの遷移が発生します。
WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect（2.3.2.2項を参照してください）：WTP：それは、次のDTLSのいずれかの通知を受信したときWTPはこの状態に入ります。それは頻繁DTLSDecapFailure通知を受信した場合、WTPは、DTLSセッションを切断するかもしれません。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect（2.3.2.2項を参照してください）：AC：それは、次のDTLSのいずれかの通知を受信したときACはこの状態に入ります。それは頻繁DTLSDecapFailure通知を受信した場合、ACは、DTLSセッションを切断するかもしれません。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
Image Data to Image Data (j): The Image Data state is used by the WTP and the AC during the firmware download phase.
画像データに画像データ（J）：画像データの状態は、ファームウェアのダウンロード・フェーズ中WTPとACで使用されています。
WTP: The WTP enters the Image Data state when it receives an Image Data Response message indicating that the AC has more data to send. This state transition also occurs when the WTP receives the subsequent Image Data Requests, at which time it resets the ImageDataStartTimer time to ensure it receives the next expected Image Data Request from the AC. This state transition can also occur when the WTP's EchoInterval timer (see Section 4.7.7) expires, in which case the WTP transmits an Echo Request message (see Section 7.1), and resets its EchoInterval timer. The state transition also occurs when the WTP receives an Echo Response from the AC (see Section 7.2).
WTP：それはACを送信するためのより多くのデータを持っていることを示す画像データの応答メッセージを受信したときにWTPは、画像データの状態になります。 WTPは、それがACからの次の予想画像データ要求を受信確保するImageDataStartTimer時間をリセットし、その時点で次の画像データ要求を受信すると、この状態遷移が発生します。この状態遷移はまた、WTPが、エコー要求メッセージを送信する（セクション7.1を参照）、そのEchoIntervalタイマーをリセットする場合、WTPのEchoIntervalタイマ（セクション4.7.7を参照）が経過し、起こり得ます。 WTPは、AC（セクション7.2を参照）からのエコー応答を受信すると、状態遷移が発生します。
AC: This state transition occurs when the AC receives the Image Data Response message from the WTP while already in the Image Data state. This state transition also occurs when the AC receives an Echo Request (see Section 7.1) from the WTP, in which case it responds with an Echo Response (see Section 7.2), and resets its EchoInterval timer (see Section 4.7.7).
AC：画像データの状態ですでにながらACはWTPからの画像データの応答メッセージを受信したときに、この状態遷移が発生します。 ACは、それがエコー応答で応答する（セクション7.2を参照）、そのEchoIntervalタイマーをリセットする場合、WTPからエコー要求（セクション7.1を参照）、（セクション4.7.7を参照）を受信した場合、この状態遷移が発生します。
Image Data to Reset (k): This state transition is used to reset the DTLS connection prior to restarting the WTP after an image download.
画像データ（K）をリセットする：この状態遷移は、画像をダウンロードした後、WTPを再開する前にDTLS接続をリセットするために使用されます。
WTP: When an image download completes, or if the ImageDataStartTimer timer expires, the WTP enters the Reset state. The WTP MAY also transition to this state upon receiving an Image Data Response message from the AC (see Section 9.1.2) indicating a failure.
WTP：画像のダウンロードが完了、またはImageDataStartTimerタイマーが満了した場合、WTPはリセット状態になります。 WTPはまた失敗を示すAC（セクション9.1.2を参照）からの画像データ応答メッセージを受信すると、この状態に遷移することができます。
AC: The AC enters the Reset state either when the image transfer has successfully completed or an error occurs during the image download process.
AC：画像転送が正常に完了したか、またはエラーが画像のダウンロード処理中に発生した場合、ACは、いずれかのリセット状態に入ります。
Image Data to DTLS Teardown (l): This transition occurs when the firmware download process aborts due to a DTLS error.
DTLSティアダウンの画像データ（L）：ファームウェアダウンロードプロセスがDTLSエラーのため中止したときにこの遷移が発生します。
WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect（2.3.2.2項を参照してください）：WTP：それは、次のDTLSのいずれかの通知を受信したときWTPはこの状態に入ります。それは頻繁DTLSDecapFailure通知を受信した場合、WTPは、DTLSセッションを切断するかもしれません。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect（2.3.2.2項を参照してください）：AC：それは、次のDTLSのいずれかの通知を受信したときACはこの状態に入ります。それは頻繁DTLSDecapFailure通知を受信した場合、ACは、DTLSセッションを切断するかもしれません。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
Configure to Data Check (m): This state transition occurs when the WTP and AC confirm the configuration.
データチェック（M）に設定する：WTPとACが設定を確認すると、この状態遷移が起こります。
WTP: The WTP enters this state when it receives a successful Configuration Status Response message from the AC. The WTP transmits the Change State Event Request message (see Section 8.6).
WTP：それはACから成功した設定ステータス応答メッセージを受信したときにWTPがこの状態に入ります。 WTPは（8.6節を参照）を変更状態イベント要求メッセージを送信します。
AC: This state transition occurs when the AC receives the Change State Event Request message (see Section 8.6) from the WTP. The AC responds with a Change State Event Response message (see Section 8.7). The AC MUST start the DataCheckTimer timer and stops the ChangeStatePendingTimer timer (see Section 4.7).
AC：ACは変更状態イベント要求メッセージを受信したときに、この状態遷移は、WTPから（8.6節を参照）が発生します。 ACは変更状態イベント応答メッセージで応答（セクション8.7を参照してください）。 ACはDataCheckTimerタイマーを起動し、ChangeStatePendingTimerタイマー（4.7節を参照）を停止しなければなりません。
Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange.
DTLSティアダウンへのデータチェック（中）：WTOは、データチェック交換を完了していない場合、この移行が発生します。
WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP retransmission timeout occurs. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：CAPWAPの再送タイムアウトが発生する前にWTPが変更状態イベント応答メッセージを受信しない場合、この状態遷移が発生します。基本的な信頼性の高い輸送のRetransmitCountカウンタがMaxRetransmit変数を（4.7節を参照）に達した場合にはWTPにも、この状態に移行します。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: The AC enters this state when the DataCheckTimer timer expires (see Section 4.7). The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：DataCheckTimerタイマーが満了したときACがこの状態に入る（4.7節を参照してください）。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
Data Check to Run (o): This state transition occurs when the linkage between the control and data channels is established, causing the WTP and AC to enter their normal state of operation.
制御とデータチャネルとの間の結合が確立されたときにWTPを引き起こし、この状態遷移が発生し、AC動作のそれらの通常の状態を入力する：データチェック（O）実行します。
WTP: The WTP enters this state when it receives a successful Change State Event Response message from the AC. The WTP initiates the data channel, which MAY require the establishment of a DTLS session, starts the DataChannelKeepAlive timer (see Section 4.7.2) and transmits a Data Channel Keep-Alive packet (see Section 4.4.1). The WTP then starts the EchoInterval timer and DataChannelDeadInterval timer (see Section 4.7).
WTP：それはACからの成功の変更状態イベント応答メッセージを受信したときにWTPがこの状態に入ります。 WTPは、DTLSセッションの確立を必要とするかもしれデータチャネルを、開始し、DataChannelKeepAliveタイマーを起動する（第4.7.2項を参照）、およびデータチャネルキープアライブパケットを（4.4.1項を参照）を送信します。 WTPは、（4.7節を参照）EchoIntervalタイマーとDataChannelDeadIntervalタイマーを開始します。
AC: This state transition occurs when the AC receives the Data Channel Keep-Alive packet (see Section 4.4.1), with a Session ID message element matching that included by the WTP in the Join Request message. The AC disables the DataCheckTimer timer. Note that if AC policy is to require the data channel to be encrypted, this process would also require the establishment of a data channel DTLS session. Upon receiving the Data Channel Keep-Alive packet, the AC transmits its own Data Channel Keep Alive packet.
AC：AC参加要求メッセージにWTPにより含まれるセッションIDメッセージ要素のマッチングと、データチャネルキープアライブパケット（セクション4.4.1を参照）を受信すると、この状態遷移が起こります。 ACはDataCheckTimerタイマーを無効にします。 ACポリシーを暗号化するデータ・チャネルを必要とする場合、このプロセスは、データ・チャネル・DTLSセッションの確立が必要となることに注意してください。データチャネルは、キープアライブパケットを受信すると、ACは、独自のデータチャネルは、キープアライブパケットを送信します。
Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down.
DTLSティアダウン（P）に実行エラーがDTLSセッションが解体させる、DTLSスタックで発生したとき、この状態遷移が起こります。
WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect（2.3.2.2項を参照してください）：WTP：それは、次のDTLSのいずれかの通知を受信したときWTPはこの状態に入ります。それは頻繁DTLSDecapFailure通知を受信した場合、WTPは、DTLSセッションを切断するかもしれません。基本的な信頼性の高い輸送のRetransmitCountカウンタがMaxRetransmit変数を（4.7節を参照）に達した場合にはWTPにも、この状態に移行します。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) expires. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
DTLSAborted、DTLSReassemblyFailure、またはDTLSPeerDisconnect（2.3.2.2項を参照してください）：AC：それは、次のDTLSのいずれかの通知を受信したときACはこの状態に入ります。それは頻繁DTLSDecapFailure通知を受信した場合、ACは、DTLSセッションを切断するかもしれません。基本的な信頼性の高い輸送のRetransmitCountカウンタがMaxRetransmit変数に達している場合は、この状態にAC遷移は（4.7節を参照してください）。 ACのEchoIntervalタイマーが（セクション4.7.7を参照）が経過すると、この状態遷移が発生します。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
Run to Run (q): This is the normal state of operation.
（Q）を実行するために実行します。これは通常の動作状態です。
WTP: This is the WTP's normal state of operation. The WTP resets its EchoInterval timer whenever it transmits a request to the AC. There are many events that result in this state transition:
WTP：これは、操作のWTPの通常の状態です。 WTPは、それがACにリクエストを送信するたびにそのEchoIntervalタイマーをリセットします。この状態遷移につながる多くのイベントがあります。
Configuration Update: The WTP receives a Configuration
Update Request message (see Section 8.4). The WTP
MUST respond with a Configuration Update Response
message (see Section 8.5).
Change State Event: The WTP receives a Change State Event Response message, or determines that it must initiate a Change State Event Request message, as a result of a failure or change in the state of a radio.
変更状態イベント：WTPが変更状態イベント応答メッセージを受信、またはそれはラジオの状態で故障や変化の結果として、変更状態イベント要求メッセージを開始しなければならないことを決定します。
Echo Request: The WTP sends an Echo Request message (Section 7.1) or receives the corresponding Echo Response message, (see Section 7.2) from the AC. When the WTP receives the Echo Response, it resets its EchoInterval timer (see Section 4.7.7).
エコー要求：WTPは、エコー要求メッセージ（7.1節）を送信するか、ACからの対応するエコー応答メッセージを、（セクション7.2を参照）を受信します。 WTPは、エコー応答を受信すると、それは（セクション4.7.7を参照）そのEchoIntervalタイマーをリセットします。
Clear Config Request: The WTP receives a Clear Configuration Request message (see Section 8.8) and MUST generate a corresponding Clear Configuration Response message (see Section 8.9). The WTP MUST reset its configuration back to manufacturer defaults.
クリアコンフィグ要求：WTPは（8.9節を参照）をクリア構成要求メッセージを受信する（8.8節を参照）、対応するクリア設定応答メッセージを生成しなければなりません。 WTPは、メーカーのデフォルト値に戻って、その設定をリセットする必要があります。
WTP Event: The WTP sends a WTP Event Request message, delivering information to the AC (see Section 9.4). The WTP receives a WTP Event Response message from the AC (see Section 9.5).
WTPイベント：WTPは、AC（9.4節を参照）に情報を提供する、WTPイベント要求メッセージを送信します。 WTPは、AC（セクション9.5を参照）からWTPイベント応答メッセージを受信します。
Data Transfer: The WTP sends a Data Transfer Request or Data Transfer Response message to the AC (see Section 9.6). The WTP receives a Data Transfer Request or Data Transfer Response message from the AC (see Section 9.6). Upon receipt of a Data Transfer Request, the WTP transmits a Data Transfer Response to the AC.
データ転送：WTPはACへのデータ転送要求またはデータ転送応答メッセージを送る（節9.6を参照）。 WTPは、AC（セクション9.6を参照）からのデータ転送要求又はデータ転送応答メッセージを受信します。データ転送要求を受信すると、WTPはACへのデータ転送応答を送信します。
Station Configuration Request: The WTP receives a Station Configuration Request message (see Section 10.1), to which it MUST respond with a Station Configuration Response message (see Section 10.2).
駅のコンフィギュレーション要求：WTPが、それは駅のコンフィギュレーション応答メッセージで応答しなければならないために駅のコンフィギュレーション要求メッセージを（10.1節を参照）、受信（10.2節を参照してください）。
AC: This is the AC's normal state of operation. Note that the receipt of any Request from the WTP causes the AC to reset its EchoInterval timer (see Section 4.7.7).
AC：これは、操作のACの通常の状態です。 （セクション4.7.7を参照）WTPからの要求の受信はACはそのEchoIntervalタイマーをリセットする原因となることに注意してください。
Configuration Update: The AC sends a Configuration Update
Request message (see Section 8.4) to the WTP to update
its configuration. The AC receives a Configuration
Update Response message (see Section 8.5) from the
WTP.
Change State Event: The AC receives a Change State Event Request message (see Section 8.6), to which it MUST respond with the Change State Event Response message (see Section 8.7).
変更状態イベント：ACは変更状態イベント・リクエスト・メッセージそれが変更状態イベント応答メッセージで応じなければなりませんし、（8.6節を参照）（8.7項を参照）を受信します。
Echo Request: The AC receives an Echo Request message (see Section 7.1), to which it MUST respond with an Echo Response message (see Section 7.2).
エコー要求：ACは、それがエコー応答メッセージで応答しなければならないためにEcho Requestメッセージを（7.1節を参照）、受信する（7.2節を参照してください）。
Clear Config Response: The AC sends a Clear Configuration Request message (see Section 8.8) to the WTP to clear its configuration. The AC receives a Clear Configuration Response message from the WTP (see Section 8.9).
クリアコンフィグ応答：AC、その構成をクリアするにはWTPに（8.8節を参照）をクリア構成要求メッセージを送信します。 ACは、WTP（8.9節を参照）からクリア設定応答メッセージを受信します。
WTP Event: The AC receives a WTP Event Request message from the WTP (see Section 9.4) and MUST generate a corresponding WTP Event Response message (see Section 9.5).
WTPイベント：ACは、WTP（セクション9.4を参照）からWTPイベント要求メッセージを受信し、対応するWTPイベント応答メッセージ（セクション9.5を参照）を生成しなければなりません。
Data Transfer: The AC sends a Data Transfer Request or Data Transfer Response message to the WTP (see Section 9.6). The AC receives a Data Transfer Request
データ転送：ACは、WTP（セクション9.6を参照）へのデータ転送要求またはデータ転送応答メッセージを送信します。 ACは、データ転送要求を受け、
or Data Transfer Response message from the WTP (see
Section 9.6). Upon receipt of a Data Transfer
Request, the AC transmits a Data Transfer Response to
the WTP.
Station Configuration Request: The AC sends a Station Configuration Request message (see Section 10.1) or receives the corresponding Station Configuration Response message (see Section 10.2) from the WTP.
駅のコンフィギュレーション要求：ACは、WTPから（10.2節を参照）駅コンフィギュレーション要求メッセージを送信する（第10.1節を参照）、または対応するステーションの設定応答メッセージを受信します。
Run to Reset (r): This state transition is used when either the AC or WTP tears down the connection. This may occur as part of normal operation, or due to error conditions.
（r）をリセットするために実行：ACまたはWTPのいずれかが接続を切断すると、この状態遷移が使用されます。これは、通常の動作の一部として、またはによるエラー条件に起こり得ます。
WTP: The WTP enters the Reset state when it receives a Reset Request message from the AC.
WTP：それはACからのリセット要求メッセージを受信したときにWTPはリセット状態に入ります。
AC: The AC enters the Reset state when it transmits a Reset Request message to the WTP.
AC：これはWTPにリセット要求メッセージを送信する場合ACはリセット状態に入ります。
Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete to terminate the DTLS session.
DTLSティアダウン（複数可）にリセット：CAPWAPリセットがDTLSセッションを終了する完了すると、この遷移が発生します。
WTP: This state transition occurs when the WTP transmits a Reset Response message. The WTP does not invoke the DTLSShutdown command (see Section 2.3.2.1). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTPがリセット応答メッセージを送信すると、この状態遷移が起こります。 WTP（セクション2.3.2.1を参照）DTLSShutdownコマンドを起動しません。 WTPはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
AC: This state transition occurs when the AC receives a Reset Response message. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：ACリセット応答メッセージを受信すると、この状態遷移が起こります。これは、（セクション2.3.2.1を参照）DTLSShutdownコマンドを開始するために、ACの原因となります。 ACはDTLSSessionDeleteタイマー（4.7.6項を参照）を開始します。
DTLS Teardown to Idle (t): This transition occurs when the DTLS session has been shut down.
DTLSティアダウンは、（T）アイドル：DTLSセッションがシャットダウンされたとき、この遷移が発生します。
WTP: This state transition occurs when the WTP has successfully cleaned up all resources associated with the control plane DTLS session, or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shut down, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared.
WTP：WTPが正常にコントロールプレーンDTLSセッションに関連付けられているすべてのリソースをクリーンアップしたとき、またはDTLSSessionDeleteタイマーは（4.7.6項を参照）を満了した場合、この状態遷移が発生します。 DTLSセッションがデータプレーンのために確立された場合に、データ・プレーン・DTLSセッションはまた、シャットダウン、およびすべてのリソースが解放されます。ステート・マシンの現在のインスタンスに設定された任意のタイマもクリアされます。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
DTLS Teardown to Sulking (u): This transition occurs when repeated attempts to setup the DTLS connection have failed.
SulkingにDTLSティアダウン（U）：セットアップを繰り返し試みDTLS接続が失敗した場合、この遷移が起こります。
WTP: The WTP enters this state when the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP and DTLS protocol messages received MUST be ignored.
WTP：WTPはFailedDTLSSessionCount又はFailedDTLSAuthFailCountカウンタ（セクション4.8を参照）MaxFailedDTLSSessionRetry変数の値に達したときにこの状態に入ります。この状態に入ると、WTPはSilentIntervalタイマーを起動する必要があります。 Sulking状態にあるものの、すべてが受信CAPWAPとDTLSプロトコルメッセージは無視しなければなりません受け取りました。
AC: This is an invalid state transition for the AC.
AC：これはACのための無効な状態遷移です。
DTLS Teardown to Dead (w): This transition occurs when the DTLS session has been shut down.
デッドにDTLSティアダウン（W）：DTLSセッションがシャットダウンされたとき、この遷移が起こります。
WTP: This is an invalid state transition for the WTP.
WTP：これはWTPのための無効な状態遷移です。
AC: This state transition occurs when the AC has successfully cleaned up all resources associated with the control plane DTLS session , or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shut down, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. The AC's Service thread is terminated.
AC：ACが正常にコントロールプレーンDTLSセッションに関連付けられているすべてのリソースをクリーンアップしたとき、またはDTLSSessionDeleteタイマーは（4.7.6項を参照）を満了した場合、この状態遷移が発生します。 DTLSセッションがデータプレーンのために確立された場合に、データ・プレーン・DTLSセッションはまた、シャットダウン、およびすべてのリソースが解放されます。ステート・マシンの現在のインスタンスに設定された任意のタイマもクリアされます。 ACのサービススレッドが終了されます。
This section describes the DTLS Commands used by CAPWAP, and the notifications received from DTLS to the CAPWAP protocol stack.
このセクションでは、CAPWAPによって使用DTLSコマンドを記述し、通知はCAPWAPプロトコルスタックにDTLSから受け取りました。
Six commands are defined for the CAPWAP to DTLS API. These "commands" are conceptual, and may be implemented as one or more function calls. This API definition is provided to clarify interactions between the DTLS and CAPWAP components of the integrated CAPWAP state machine.
6つのコマンドは、DTLSのAPIへのCAPWAPのために定義されています。これらの「コマンド」は概念的なものであり、一つ以上の関数呼び出しとして実装されてもよいです。このAPIの定義は、統合されたCAPWAP状態マシンのDTLSとCAPWAPコンポーネント間の相互作用を明確にするために設けられています。
Below is a list of the minimal command APIs:
以下は、最小限のコマンドAPIのリストは以下のとおりです。
o DTLSStart is sent to the DTLS component to cause a DTLS session to be established. Upon invoking the DTLSStart command, the WaitDTLS timer is started. The WTP initiates this DTLS command, as the AC does not initiate DTLS sessions.
O DTLSStartはDTLSセッションを確立させるようにDTLSコンポーネントに送信されます。 DTLSStartコマンドを呼び出す際に、WaitDTLSタイマーが開始されます。 ACは、DTLSセッションを開始しないようWTPは、このDTLSコマンドを開始します。
o DTLSListen is sent to the DTLS component to allow the DTLS component to listen for incoming DTLS session requests.
O DTLSListenはDTLSコンポーネントが入ってくるDTLSセッション要求をリッスンできるようにするためにDTLSコンポーネントに送信されます。
o DTLSAccept is sent to the DTLS component to allow the DTLS session establishment to continue successfully.
O DTLSAcceptはDTLSセッションの確立が成功し続けることができるようにDTLSコンポーネントに送信されます。
o DTLSAbortSession is sent to the DTLS component to cause the session that is in the process of being established to be aborted. This command is also sent when the WaitDTLS timer expires. When this command is executed, the FailedDTLSSessionCount counter is incremented.
O DTLSAbortSessionを中止するために確立されたプロセスであるセッションを引き起こすDTLSコンポーネントに送信されます。 WaitDTLSタイマーが満了したとき、このコマンドも送信されます。このコマンドを実行すると、FailedDTLSSessionCountカウンタがインクリメントされます。
o DTLSShutdown is sent to the DTLS component to cause session teardown.
O DTLSShutdownは、セッションのティアダウンを引き起こすことがDTLSコンポーネントに送信されます。
o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU size used by the DTLS component. See Section 3.5 for more information on MTU Discovery. The default size is 1468 bytes.
O DTLSMtuUpdateはDTLSコンポーネントによって使用されるMTUサイズを変更するためにCAPWAPコンポーネントによって送信されます。 MTUディスカバリーの詳細については、セクション3.5を参照してください。デフォルトのサイズは1468バイトです。
DTLS notifications are defined for the DTLS to CAPWAP API. These "notifications" are conceptual and may be implemented in numerous ways (e.g., as function return values). This API definition is provided to clarify interactions between the DTLS and CAPWAP components of the integrated CAPWAP state machine. It is important to note that the notifications listed below MAY cause the CAPWAP state machine to jump from one state to another using a state transition not listed in Section 2.3.1. When a notification listed below occurs, the target CAPWAP state shown in Figure 4 becomes the current state.
DTLS通知は、CAPWAPのAPIへのDTLSのために定義されています。これらの「通知」は、概念的なものであり、（関数の戻り値として、例えば）多数の方法で実施することができます。このAPIの定義は、統合されたCAPWAP状態マシンのDTLSとCAPWAPコンポーネント間の相互作用を明確にするために設けられています。なお、以下に記載された通知がCAPWAPステートマシンは、セクション2.3.1に記載されていない状態遷移を使用してある状態から別の状態にジャンプし得ることに留意することが重要です。下記の通知が発生した場合、図4に示す目標CAPWAP状態が現在の状態になります。
Below is a list of the API notifications:
以下は、APIの通知のリストは、次のとおりです。
o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS session establishment once the peer's identity has been received. This notification MAY be used by the CAPWAP component to authorize the session, based on the peer's identity. The authorization process will lead to the CAPWAP component initiating either the DTLSAccept or DTLSAbortSession commands.
ピアの識別情報を受信した後、O DTLSPeerAuthorizeはDTLSセッション確立中にCAPWAPコンポーネントに送信されます。この通知は、ピアの識別情報に基づいて、セッションを許可するためにCAPWAPコンポーネントによって使用されるかもしれません。承認プロセスは、どちらかDTLSAcceptまたはDTLSAbortSessionコマンドを開始CAPWAPコンポーネントにつながります。
o DTLSEstablished is sent to the CAPWAP component to indicate that a secure channel now exists, using the parameters provided during the DTLS initialization process. When this notification is received, the FailedDTLSSessionCount counter is reset to zero. When this notification is received, the WaitDTLS timer is stopped.
O DTLSEstablishedはDTLS初期化プロセス中に提供されたパラメータを使用して、セキュアチャネルが現在存在することを示すために、CAPWAPコンポーネントに送信されます。この通知を受信したとき、FailedDTLSSessionCountカウンタがゼロにリセットされます。この通知を受信した場合、WaitDTLSタイマーが停止しています。
o DTLSEstablishFail is sent when the DTLS session establishment has failed, either due to a local error or due to the peer rejecting the session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented.
DTLSセッションの確立が原因ローカルエラーまたはによるセッション確立を拒絶ピアのいずれか、失敗した場合、O DTLSEstablishFailが送信されます。この通知を受信した場合、FailedDTLSSessionCountカウンタがインクリメントされます。
o DTLSAuthenticateFail is sent when DTLS session establishment has failed due to an authentication error. When this notification is received, the FailedDTLSAuthFailCount counter is incremented.
DTLSセッションの確立に失敗したとき、O DTLSAuthenticateFailが原因認証エラーに送信されます。この通知を受信した場合、FailedDTLSAuthFailCountカウンタがインクリメントされます。
o DTLSAborted is sent to the CAPWAP component to indicate that session abort (as requested by CAPWAP) is complete; this occurs to confirm a DTLS session abort or when the WaitDTLS timer expires. When this notification is received, the WaitDTLS timer is stopped.
O DTLSAbortedは、そのセッションのアボートを（CAPWAPによって要求されるように）完了を示すために、CAPWAPコンポーネントに送信されます。これは、中止またはWaitDTLSタイマーが満了したときにDTLSセッションを確認するために発生します。この通知を受信した場合、WaitDTLSタイマーが停止しています。
o DTLSReassemblyFailure MAY be sent to the CAPWAP component to indicate DTLS fragment reassembly failure.
O DTLSReassemblyFailureはDTLSフラグメント再構成の失敗を示すために、CAPWAPコンポーネントに送ってもよいです。
o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP module to indicate an encryption/authentication failure. This notification is intended for informative purposes only, and is not intended to cause a change in the CAPWAP state machine (see Section 12.4).
O DTLSDecapFailureは、カプセル化解除の失敗を示すために、CAPWAPモジュールに送ってもよいです。 DTLSDecapFailureは、暗号化/認証失敗を示すために、CAPWAPモジュールに送ってもよいです。この通知は有益な目的とするものであり、CAPWAP状態機械（12.4節を参照）に変化を生じさせることを意図していません。
o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the DTLS session has been torn down. Note that this notification is only received if the DTLS session has been established.
O DTLSPeerDisconnectが取り壊されたDTLSセッションを示すために、CAPWAPコンポーネントに送信されます。 DTLSセッションが確立されている場合は、この通知にのみ受信されることに注意してください。
DTLS is used as a tightly integrated, secure wrapper for the CAPWAP protocol. In this document, DTLS and CAPWAP are discussed as nominally distinct entities; however, they are very closely coupled, and may even be implemented inseparably. Since there are DTLS library implementations currently available, and since security protocols (e.g., IPsec, TLS) are often implemented in widely available acceleration hardware, it is both convenient and forward-looking to maintain a modular distinction in this document.
DTLSは、CAPWAPプロトコルの緊密に統合され、安全なラッパーとして使用されます。この文書では、DTLSとCAPWAPは、名目上の別個のエンティティとして議論されています。しかし、彼らは非常に密接に結合され、さらには不可分実施することができます。ライブラリの実装は、現在利用可能なDTLS、およびセキュリティプロトコル以降があるので（例えば、IPsecの、TLS）は、多くの場合、広く利用可能な加速ハードウェアに実装され、それは便利でもある前向きこの文書に記載されているモジュラー区別を維持します。
This section describes a detailed walk-through of the interactions between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be encountered during the normal course of operation.
このセクションでは、彼らは通常の動作過程で遭遇するであろうと（DTLSにCAPWAP）「コマンド」と「通知」（CAPWAPにDTLS）を経由して、DTLSモジュールとCAPWAPモジュール間の相互作用の詳細なウォークスルーを説明しています。
Details of the DTLS handshake process are specified in [RFC4347]. This section describes the interactions between the DTLS session establishment process and the CAPWAP protocol. Note that the conceptual DTLS state is shown below to help understand the point at which the DTLS states transition. In the normal case, the DTLS handshake will proceed as shown in Figure 5. (NOTE: this example uses certificates, but pre-shared keys are also supported.)
DTLSハンドシェイク処理の詳細については、[RFC4347]で指定されています。このセクションでは、DTLSセッション確立処理とCAPWAPプロトコル間の相互作用を記述する。概念的DTLS状態は時点でDTLS状態遷移を理解するために以下に示されることに留意されたいです。図5に示すように、通常の場合、DTLSハンドシェークが進行する（注：この例では、証明書を使用するが、事前共有キーもサポートされています。）
============ ============
WTP AC
============ ============
ClientHello ------>
<------ HelloVerifyRequest
(with cookie)
ClientHello ------>
(with cookie)
<------ ServerHello
<------ Certificate
<------ ServerHelloDone
(WTP callout for AC authorization occurs in CAPWAP Auth state)
（AC認証用WTPコールアウトは、CAPWAP認証状態で起こります）
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished ------>
(AC callout for WTP authorization
occurs in CAPWAP Auth state)
ChangeCipherSpec
<------ Finished
Figure 5: DTLS Handshake
図5：DTLS握手
DTLS, as specified, provides its own retransmit timers with an exponential back-off. [RFC4347] does not specify how long retransmissions should continue. Consequently, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module.
DTLSは、指定されたように、指数関数的なバックオフと共に、自身の再送信タイマーを提供します。 [RFC4347]は再送信が継続する期間を指定していません。その結果、不完全なDTLSハンドシェイクがタイムアウトすることは完全にCAPWAPモジュールの責任です。
The DTLS implementation used by CAPWAP MUST support TLS Session Resumption. Session resumption is typically used to establish the DTLS session used for the data channel. Since the data channel uses different port numbers than the control channel, the DTLS implementation on the WTP MUST provide an interface that allows the CAPWAP module to request session resumption despite the use of the different port numbers (TLS implementations usually attempt session resumption only when connecting to the same IP address and port number). Note that session resumption is not guaranteed to occur, and a full DTLS handshake may occur instead.
CAPWAPによって使用されるDTLS実装は、TLSセッション再開をサポートしなければなりません。セッション再開は、典型的には、データチャネルに使用DTLSセッションを確立するために使用されます。データチャネルは制御チャネルとは異なるポート番号を使用するので、WTPにDTLS実装は（TLSの実装は、通常、接続する場合にのみ、セッション再開を試みるCAPWAPモジュールは、異なるポート番号を使用するにもかかわらず、セッションの再開を要求することを可能にするインタフェースを提供しなければなりません同じIPアドレスとポート番号へ）。なお、セッションの再開が発生することが保証されていない、とフルDTLSハンドシェイクが代わりに発生することがあります。
The DTLS implementation used by CAPWAP MUST use replay detection, per Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles retransmissions by re-encrypting lost frames, any duplicate DTLS frames are either unintentional or malicious and should be silently discarded.
CAPWAPで使用DTLS実装は、[RFC4347]のセクション3.3あたり、リプレイ検出を使用しなければなりません。 CAPWAPプロトコルは、失われたフレームを再暗号化することによって再送信を扱うので、重複DTLSフレームは、いずれかの意図しないまたは悪意のあるであり、静かに捨てられるべきです。
The WTP, either through the Discovery process or through pre-configuration, determines to which AC to connect. The WTP uses the DTLSStart command to request that a secure connection be established to the selected AC. Prior to initiation of the DTLS handshake, the WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS timer. If the DTLSEstablished notification is not received prior to timer expiration, the DTLS session is aborted by issuing the DTLSAbortSession DTLS command. This notification causes the CAPWAP module to transition to the Idle state. Upon receiving a DTLSEstablished notification, the WaitDTLS timer is deactivated.
WTPは、いずれかのディスカバリプロセスを介して、または事前構成によって、ACが接続するかを決定します。 WTPは、セキュア接続を選択ACに確立する要求にDTLSStartコマンドを使用します。 DTLSハンドシェイクの開始前に、WTPはWaitDTLSタイマーを設定します。 DTLSStartまたはDTLSListenコマンドを起動すると、WTPとACは、それぞれ、WaitDTLSタイマーを設定します。 DTLSEstablished通知がタイマ満了前に受信されない場合は、DTLSセッションはDTLSAbortSession DTLSコマンドを発行することによって中止されます。この通知は、アイドル状態に遷移するCAPWAPモジュールを引き起こします。 DTLSEstablished通知を受信すると、WaitDTLSタイマーが解除されます。
If the AC or WTP does not respond to any DTLS handshake messages sent by its peer, the DTLS specification calls for the message to be retransmitted. Note that during the handshake, when both the AC and the WTP are expecting additional handshake messages, they both retransmit if an expected message has not been received (note that retransmissions for CAPWAP Control messages work differently: all CAPWAP Control messages are either requests or responses, and the peer who sent the request is responsible for retransmissions).
ACまたはWTPは、任意のDTLSに応答しない場合はそのピアによって送信されたメッセージをハンドシェイク、DTLS仕様は、再送信されるメッセージのために呼び出します。すべてのCAPWAP制御メッセージは、要求または応答のいずれかです：ACとWTPの両方が追加のハンドシェイクメッセージを期待している際にハンドシェイク中に、彼らは、予想されるメッセージが受信されていない場合は、両方の再送信は、（CAPWAP制御メッセージのための再送信が異なる動作をすることに注意していることに注意してください、および要求を送信したピア）は、再送信する責任があります。
If the WTP or the AC does not receive an expected DTLS handshake message despite of retransmissions, the WaitDTLS timer will eventually expire, and the session will be terminated. This can happen if communication between the peers has completely failed, or if one of the peers sent a DTLS Alert message that was lost in transit (DTLS does not retransmit Alert messages).
WTPまたはACは、再送信のにもかかわらず、予想DTLS握手メッセージを受信しない場合、WaitDTLSタイマーが最終的に期限切れになり、セッションが終了します。ピア間の通信が完全に失敗した場合、またはピアの1つは、（DTLSが警告メッセージを再送しない）輸送中に紛失したDTLS警告メッセージを送信した場合に発生します。
If a cookie fails to validate, this could represent a WTP error, or it could represent a DoS attack. Hence, AC resource utilization SHOULD be minimized. The AC MAY log a message indicating the failure, and SHOULD treat the message as though no cookie were present.
クッキーは、検証に失敗した場合、これはWTPのエラーを表すことができ、またはそれは、DoS攻撃を表すことができます。従って、ACリソース使用率が最小化されるべきです。 ACは、失敗を示すメッセージをログに記録することができ、クッキーが存在しないかのようにメッセージを処理すべきです。
Since DTLS Handshake messages are potentially larger than the maximum record size, DTLS supports fragmenting of Handshake messages across multiple records. There are several potential causes of re-assembly errors, including overlapping and/or lost fragments. The DTLS component MUST send a DTLSReassemblyFailure notification to the CAPWAP component. Whether precise information is given along with notification is an implementation issue, and hence is beyond the scope of this document. Upon receipt of such an error, the CAPWAP component SHOULD log an appropriate error message. Whether processing continues or the DTLS session is terminated is implementation dependent.
DTLS握手メッセージは最大レコード・サイズよりも潜在的に大きいので、DTLSは、複数のレコード間のハンドシェイクメッセージの断片化をサポートしています。重複および/または失われたフラグメントを含む、再組立誤差、いくつかの潜在的な原因があります。 DTLSコンポーネントは、CAPWAPコンポーネントにDTLSReassemblyFailure通知を送らなければなりません。正確な情報を通知と共に与えられるかどうかの実装上の問題であり、したがって、この文書の範囲外です。このようなエラーを受信すると、CAPWAP成分は、適切なエラーメッセージをログに記録します。処理を継続またはDTLSセッションが終了したかどうかは実装依存です。
DTLS decapsulation errors consist of three types: decryption errors, authentication errors, and malformed DTLS record headers. Since DTLS authenticates the data prior to encapsulation, if decryption fails, it is difficult to detect this without first attempting to authenticate the packet. If authentication fails, a decryption error is also likely, but not guaranteed. Rather than attempt to derive (and require the implementation of) algorithms for detecting decryption failures, decryption failures are reported as authentication failures. The DTLS component MUST provide a DTLSDecapFailure notification to the CAPWAP component when such errors occur. If a malformed DTLS record header is detected, the packets SHOULD be silently discarded, and the receiver MAY log an error message.
復号化エラー、認証エラー、不正な形式のDTLSレコードヘッダ：DTLSカプセル化解除のエラーが3種類で構成されています。 DTLSは、カプセル化する前にデータを認証するので、復号化が失敗した場合、最初のパケットを認証しようとせずに、これを検出することは困難です。認証が失敗した場合、復号化エラーもありそうですが、保証の限りではありません。導出（との実装が必要です）復号化の失敗を検出するためのアルゴリズムをしようとするのではなく、復号化の失敗は、認証の失敗として報告されています。このようなエラーが発生したときDTLS成分はCAPWAPコンポーネントにDTLSDecapFailure通知を提供しなければなりません。不正なDTLSレコードヘッダが検出された場合、パケットは、黙って破棄されるべきであり、受信機は、エラーメッセージを記録することがあります。
There is currently only one encapsulation error defined: MTU exceeded. As part of DTLS session establishment, the CAPWAP component informs the DTLS component of the MTU size. This may be dynamically modified at any time when the CAPWAP component sends the DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). The value provided to the DTLS stack is the result of the MTU Discovery process, which is described in Section 3.5. The DTLS component returns this notification to the CAPWAP component whenever a transmission request will result in a packet that exceeds the MTU.
定義された唯一のカプセル化誤差は現在あり：MTUを超えました。 DTLSセッション確立の一環として、CAPWAP成分がMTUサイズのDTLSコンポーネントに通知します。これは、動的にCAPWAP成分がDTLS成分（セクション2.3.2.1を参照）DTLSMtuUpdateコマンドを送信し、いつでも変更することができます。 DTLSスタックに提供された値は、セクション3.5に記載されているMTU Discoveryプロセスの結果です。 DTLS成分は、送信要求がMTUを超えるパケットをもたらすたびにCAPWAPコンポーネントにこの通知を返します。
DTLS supports endpoint authentication with certificates or pre-shared keys. The TLS algorithm suites for each endpoint authentication method are described below.
DTLSは、証明書または事前共有キーを使用してエンドポイント認証をサポートしています。各エンドポイントの認証方式のためのTLSアルゴリズムスイートは、以下に記載されています。
CAPWAP implementations only use cipher suites that are recommended for use with DTLS, see [DTLS-DESIGN]. At present, the following algorithms MUST be supported when using certificates for CAPWAP authentication:
CAPWAPの実装は、[DTLS-DESIGN]見DTLSでの使用は推奨されている暗号スイートを使用します。 CAPWAP認証用の証明書を使用している場合現時点では、次のアルゴリズムをサポートしなければなりません。
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
O TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms SHOULD be supported when using certificates:
証明書を使用する場合は、次のアルゴリズムがサポートされる必要があります。
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]
O TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms MAY be supported when using certificates:
証明書を使用する場合は、次のアルゴリズムがサポートされることがあります。
o TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]
O TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246]
O TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246]
Additional ciphers MAY be defined in subsequent CAPWAP specifications.
追加の暗号は、その後のCAPWAP仕様で定義されてもよいです。
Pre-shared keys present significant challenges from a security perspective, and for that reason, their use is strongly discouraged. Several methods for authenticating with pre-shared keys are defined [RFC4279], and we focus on the following two:
事前共有キーは、セキュリティの観点から重要な課題を提示し、その理由のため、その使用は強くお勧めします。事前共有キーで認証するためのいくつかの方法は、[RFC4279]に定義されている、と我々は次の2つに焦点を当てます。
o Pre-Shared Key (PSK) key exchange algorithm - simplest method, ciphersuites use only symmetric key algorithms.
O事前共有鍵（PSK）鍵交換アルゴリズム - 最も簡単な方法は、暗号スイートは、対称鍵アルゴリズムを使用します。
o DHE_PSK key exchange algorithm - use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS).
O DHE_PSK鍵交換アルゴリズム - のDiffie-Hellman交換を認証するためにPSKを使用しています。これらの暗号スイートは、辞書攻撃に対するいくつかの追加の保護を提供し、また、完全転送秘密（PFS）を提供します。
The first approach (plain PSK) is susceptible to passive dictionary attacks; hence, while this algorithm MUST be supported, special care should be taken when choosing that method. In particular, user-readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD be strongly discouraged.
最初のアプローチ（無地PSK）は、受動的辞書攻撃を受けやすいです。このアルゴリズムがサポートする必要がありますが、その方法を選択する際に、したがって、特別な注意が必要です。特に、ユーザが読み取り可能なパスフレーズを使用してはいけません、と短いPSKsの使用が強く推奨されるべきである（SHOULD）。
The following cryptographic algorithms MUST be supported when using pre-shared keys:
事前共有キーを使用する場合は、次の暗号化アルゴリズムをサポートしなければなりません。
o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246]
O TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246]
O TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms MAY be supported when using pre-shared keys:
事前共有キーを使用する場合は、次のアルゴリズムがサポートされることがあります。
o TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246]
O TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246]
O TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246]
Additional ciphers MAY be defined in following CAPWAP specifications.
追加の暗号はCAPWAP仕様を次のように定義されるかもしれません。
Certificate authorization by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509 certificates MUST include the Extended Key Usage (EKU) certificate extension [RFC5280].
唯一ACはACの機能を実行できるようにACとWTPにより、証明書の認証が必要とされるのみWTPはWTPの機能を実行することができること。 ACまたはWTPへの機能のこの制限は、ACで使用される証明書はWTPで使用される証明書と区別していなければなりませんことを必要とします。この分化を達成するために、X.509証明書は拡張キー使用法（EKU）証明書拡張[RFC5280]を含まなければなりません。
The EKU field indicates one or more purposes for which a certificate may be used. It is an essential part in authorization. Its syntax is described in [RFC5280] and [ISO.9834-1.1993] and is as follows:
EKUフィールドは、証明書が使用されるための1つ以上の目的を示しています。これは、承認に不可欠な部分です。その構文は、[RFC5280]に記載の[ISO.9834-1.1993]と以下の通りであります：
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
Here we define two KeyPurposeId values, one for the WTP and one for the AC. Inclusion of one of these two values indicates a certificate is authorized for use by a WTP or AC, respectively. These values are formatted as id-kp fields.
ここでは、2つのKeyPurposeId値、WTP用とACのための1つを定義します。これら2つの値のいずれかを含めることは、証明書は、それぞれ、WTP又はACによる使用のために認可されていることを示します。これらの値は、ID-KPフィールドとしてフォーマットされます。
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
All capwap devices MUST support the ExtendedKeyUsage certificate extension if it is present in a certificate. If the extension is present, then the certificate MUST have either the id-kp-capwapAC or the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. Similarly, if the extension is present, a device MUST have the id-kp-capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP.
それは、証明書に存在している場合、すべてのCAPWAPのデバイスは、extendedKeyUsageの証明書拡張をサポートしなければなりません。拡張子が存在する場合、証明書は、ID-KP-capwapACまたはID-KP-anyExtendedKeyUsage keyPurposeIDいずれかがACとして作用しなければならない必要があります。拡張が存在する場合は同様に、デバイスは、ID-KP-capwapWTPまたはID-KP-anyExtendedKeyUsage keyPurposeIDはWTPとして作用しなければならない必要があります。
Part of the CAPWAP certificate validation process includes ensuring that the proper EKU is included and allowing the CAPWAP session to be established only if the extension properly represents the device. For instance, an AC SHOULD NOT accept a connection request from another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is present in the certificate.
CAPWAP証明書検証プロセスの一部は、適切なEKUが含まれていることを保証し、拡張が正しくデバイスを表す場合にのみ、CAPWAPセッションを確立することを可能に備えています。例えば、ACは、別のACからの接続要求を受け入れてはならず、したがって、ID-KP-capwapWTP EKUは、証明書内に存在することを確かめなければなりません。
CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device.
CAPWAP実装はWTPとACの両方のための共通名（CN）は、そのデバイスのMACアドレスである証明書をサポートしなければなりません。
The MAC address MUST be encoded in the PrintableString format, using the well-recognized MAC address format of 01:23:45:67:89:ab. The CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs], and WiMAX [WiMAX]. See Section 12.8 for more information on the use of the MAC address in the CN field.
67：45：23：89：AB MACアドレスが01のよく認識されたMACアドレス形式を使用して、はPrintableString形式で符号化されなければなりません。 CNフィールドは、EUI-48 [EUI-48]またはEUI-64 [EUI-64] MACアドレス形式のいずれかを含むかもしれません。 CNフィールドのこの一見型破りな使用は、パケット・ケーブル[PacketCableの]、ケーブルラボ[CableLabsの]、およびWiMAX [WiMAXの】として製造プロセス中にプロビジョニングされているデバイス証明書に依存する他の規格と一致しています。 CNフィールド内のMACアドレスの使用の詳細については、セクション12.8を参照してください。
ACs and WTPs MUST authorize (e.g., through access control lists) certificates of devices to which they are connecting, e.g., based on the issuer, MAC address, or organizational information specified in the certificate. The identities specified in the certificates bind a particular DTLS session to a specific pair of mutually authenticated and authorized MAC addresses. The particulars of authorization filter construction are implementation details which are, for the most part, not within the scope of this specification. However, at minimum, all devices MUST verify that the appropriate EKU bit is set according to the role of the peer device (AC versus WTP), and that the issuer of the certificate is appropriate for the domain in question.
ACSとWTPsは、彼らが発行者、MACアドレス、または証明書に指定された組織情報に基づいて、例えば、接続先の機器（例えば、アクセス制御リストを介して）証明書を承認しなければなりません。証明書で指定されたアイデンティティは、相互認証と認可のMACアドレスの特定のペアに特定のDTLSセッションをバインドします。認証フィルタ構造の詳細はありません、この仕様の範囲内で、ほとんどの部分は、ある実装の詳細です。しかし、最低限、すべてのデバイスは、ピアデバイス（WTP対AC）の役割に応じた適切なEKUビットが設定されていることを確認しなければならない、と証明書の発行者は、問題のドメインのために適切であること。
When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST contain the "PSK identity hint" field and the ClientKeyExchange message MUST contain the "PSK identity" field. These fields are used to help the WTP select the appropriate PSK for use with the AC, and then indicate to the AC which key is being used. When PSKs are provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for the key MUST be specified.
DTLSは、PSK暗号の組み合わせを使用する場合、ServerKeyExchangeメッセージは、「PSKのアイデンティティのヒント」フィールドを含まなければならないし、ClientKeyExchangeメッセージは、「PSKアイデンティティ」フィールドを含まなければなりません。これらのフィールドは、WTPがACでの使用に適しPSKを選択するのに役立つ、し、キーが使用されているACに示すために使用されています。 PSKsはWTPsとACSにプロビジョニングされ、両方のキーのPSKヒントとPSKアイデンティティを指定しなければならないとき。
The PSK Hint SHOULD uniquely identify the AC and the PSK Identity SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints and identities be the ASCII HEX-formatted MAC addresses of the respective devices, since each pairwise combination of WTP and AC SHOULD have a unique PSK. The PSK Hint and Identity SHOULD be sufficient to perform authorization, as simply having knowledge of a PSK does not necessarily imply authorization.
PSKヒントを一意ACを識別すべきであるとPSKアイデンティティは一意WTPを識別すべきです。 WTPとACの各ペアごとの組み合わせがユニークPSKを持っているはずなので、これらのヒントとアイデンティティは、各機器のASCIIのHEXフォーマットのMACアドレスであることが推奨されます。 PSKヒントとアイデンティティは、単に、必ずしも承認を意味するものではないPSKの知識を有するものとして、認証を実行するために十分であるべきです。
If a single PSK is being used for multiple devices on a CAPWAP network, which is NOT RECOMMENDED, the PSK Hint and Identity can no longer be a MAC address, so appropriate hints and identities SHOULD be selected to identify the group of devices to which the PSK is provisioned.
単一PSKは推奨されていませんCAPWAPネットワーク上の複数のデバイスに使用されている場合は、PSKのヒントとアイデンティティは、もはやMACアドレスになることはできませんので、適切なヒントとアイデンティティはへのデバイスのグループを識別するために選択する必要がありますPSKは、プロビジョニングされます。
Communication between a WTP and an AC is established using the standard UDP client/server model. The CAPWAP protocol supports both UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, UDP is used for the CAPWAP Control and Data channels.
WTPとAC間の通信は、標準のUDPクライアント/サーバモデルを使用して確立されます。 CAPWAPプロトコルはUDPとUDP-Liteの[RFC3828]の転送プロトコルの両方をサポートしています。 IPv4の上で実行すると、UDPは、CAPWAP制御およびデータチャネルに使用されます。
When run over IPv6, the CAPWAP Control channel always uses UDP, while the CAPWAP Data channel may use either UDP or UDP-Lite. UDP-Lite is the default transport protocol for the CAPWAP Data channel. However, if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is used for the CAPWAP Data channel.
IPv6の上で実行すると、CAPWAPデータチャネルはUDPまたはUDP-Liteのいずれかを使用することができる一方で、CAPWAP制御チャネルは常に、UDPを使用しています。 UDP-LiteはCAPWAPデータチャネルのデフォルトのトランスポートプロトコルです。 IPv6ゲートウェイにミドルまたはIPv4が発見された場合は、UDPはCAPWAPデータチャネルに使用されます。
This section describes how the CAPWAP protocol is carried over IP and UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol message element, Section 4.6.14, describes the rules to use in determining which transport protocol is to be used.
このセクションでは、CAPWAPプロトコルはIPおよびUDP / UDP-Liteの転送プロトコルを通して実行される方法を説明します。 CAPWAPトランスポートプロトコルメッセージ要素、セクション4.6.14は、使用されるべきトランスポートプロトコルを決定する際に使用するためのルールが記載されています。
In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which they received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port.
ネットワーク内の潜在的な中間装置と互換性を持つようにCAPWAPためには、CAPWAP実装は、それらが所与のピアからのトラフィックを受信したポートと同じポートからの戻りトラフィックを送信しなければなりません。さらに、CAPWAPノードによって生成された未承諾の要求は、同じポートで送信されなければなりません。
One of the CAPWAP protocol requirements is to allow a WTP to reside behind a middlebox, firewall, and/or Network Address Translation (NAT) device. Since a CAPWAP session is initiated by the WTP (client) to the well-known UDP port of the AC (server), the use of UDP is a logical choice. When CAPWAP is run over IPv4, the UDP checksum field in CAPWAP packets MUST be set to zero.
CAPWAPプロトコル要件の1つは、WTPがミドル、ファイアウォール、および/またはネットワークアドレス変換（NAT）デバイスの背後に常駐できるようにすることです。 CAPWAPセッションはAC（サーバー）のよく知られたUDPポートへのWTP（クライアント）によって開始されているので、UDPの使用は論理的な選択です。 CAPWAPはIPv4の上で実行されると、CAPWAPパケット内のUDPチェックサムフィールドはゼロに設定しなければなりません。
CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP Control channel, as defined in Section 1.4. The CAPWAP control port at the AC is the well-known UDP port 5246. The CAPWAP control port at the WTP can be any port selected by the WTP.
セクション1.4で定義されるようにACにWTPから送信されたCAPWAPプロトコル制御パケットは、CAPWAP制御チャネルを使用します。 ACでCAPWAP制御ポートは、周知のUDPポート5246. WTPにより選択された任意のポートであり得るWTPでCAPWAP制御ポートです。
CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP Data channel, as defined in Section 1.4. The CAPWAP data port at the AC is the well-known UDP port 5247. If an AC permits the administrator to change the CAPWAP control port, the CAPWAP data port MUST be the next consecutive port number. The CAPWAP data port at the WTP can be any port selected by the WTP.
セクション1.4で定義されるようにACにWTPから送信されたCAPWAPプロトコル・データ・パケットは、CAPWAPデータチャネルを使用します。 ACは、CAPWAP制御ポートを変更するには、管理者が許可する場合ACでCAPWAPデータポートは、周知のUDPポート5247.あり、CAPWAPデータポートは、次の連続したポート番号でなければなりません。 WTPでのCAPWAPデータポートは、WTPが選択した任意のポートにすることができます。
When CAPWAP is run over IPv6, UDP-Lite is the default transport protocol, which reduces the checksum processing required for each packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP-Lite is used, the checksum field MUST have a coverage of 8 [RFC3828].
CAPWAPがIPv6上で実行されたときに、UDP-Liteは、（IPv6を介しUDPの使用[RFC2460]と比較して）、各パケットのために必要なチェックサム処理を低減するデフォルトのトランスポートプロトコルです。 UDP-Liteのを使用する場合は、チェックサムフィールドは、8 [RFC3828]のカバレッジを持たなければなりません。
UDP-Lite uses the same port assignments as UDP.
UDP-LiteはUDPと同じポート割り当てを使用しています。
The AC Discovery phase allows the WTP to determine which ACs are available and choose the best AC with which to establish a CAPWAP session. The Discovery phase occurs when the WTP enters the optional Discovery state. A WTP does not need to complete the AC Discovery phase if it uses a pre-configured AC. This section details the mechanism used by a WTP to dynamically discover candidate ACs.
AC発見フェーズは、WTPが利用可能なACのかを決定し、CAPWAPセッションを確立するとの最高のACを選択することができます。 WTPは、任意の検出状態に入るときに発見フェーズが発生します。 WTPは、それが事前に設定されたACを使用している場合、AC発見フェーズを完了する必要はありません。このセクションでは、動的に候補ACSを発見するためにWTPが使用するメカニズムを詳しく説明しています。
A WTP and an AC will frequently not reside in the same IP subnet (broadcast domain). When this occurs, the WTP must be capable of discovering the AC, without requiring that multicast services are enabled in the network.
WTPとACが頻繁に同じIPサブネット（ブロードキャストドメイン）内に存在しないであろう。これが発生すると、WTPは、マルチキャストサービスがネットワーク内で有効になっていることを必要とせず、ACを発見することができなければなりません。
When the WTP attempts to establish communication with an AC, it sends the Discovery Request message and receives the Discovery Response message from the AC(s). The WTP MUST send the Discovery Request message to either the limited broadcast IP address (255.255.255.255), the well-known CAPWAP multicast address (224.0.1.140), or to the unicast IP address of the AC. For IPv6 networks, since broadcast does not exist, the use of "All ACs multicast address" (FF0X:0:0:0:0: 0:0:18C) is used instead. Upon receipt of the Discovery Request message, the AC sends a Discovery Response message to the unicast IP address of the WTP, regardless of whether the Discovery Request message was sent as a broadcast, multicast, or unicast message.
WTPは、ACとの通信を確立しようとすると、それが発見要求メッセージを送信し、AC（S）から発見応答メッセージを受信します。 WTPは、いずれかの制限されたブロードキャストIPアドレス（255.255.255.255）、よく知られたCAPWAPマルチキャストアドレス（224.0.1.140）、またはACのユニキャストIPアドレスにディスカバリ要求メッセージを送らなければなりません。 IPv6ネットワークの場合、放送が存在しないため、 "すべてのACSマルチキャストアドレス" の使用（FF0X：0：0：0：0：0：0：18C）の代わりに使用されています。ディスカバリ要求メッセージを受信すると、ACは関係なく、ディスカバリ要求メッセージは、ブロードキャスト、マルチキャスト、またはユニキャストメッセージとして送信されたかどうかの、WTPのユニキャストIPアドレスに発見応答メッセージを送信します。
WTP use of a limited IP broadcast, multicast, or unicast IP address is implementation dependent. ACs, on the other hand, MUST support broadcast, multicast, and unicast discovery.
限られたIPブロードキャスト、マルチキャスト、またはユニキャストIPアドレスのWTPの使用は実装依存です。 ACSは、他の一方で、ブロードキャスト、マルチキャスト、およびユニキャストの発見をサポートしなければなりません。
When a WTP transmits a Discovery Request message to a unicast address, the WTP must first obtain the IP address of the AC. Any static configuration of an AC's IP address on the WTP non-volatile storage is implementation dependent. However, additional dynamic schemes are possible, for example:
WTPがユニキャストアドレスにディスカバリ要求メッセージを送信すると、WTPは、第1のACのIPアドレスを取得しなければなりません。 WTPの不揮発性ストレージにACのIPアドレスのいずれかの静的な構成は実装依存です。しかし、追加の動的なスキームは、例えば、可能です。
DHCP: See [RFC5417] for more information on the use of DHCP to discover AC IP addresses.
DHCP：[RFC5417]を参照してください。DHCPの使用方法の詳細については、AC IPアドレスを発見します。
DNS: The WTP MAY support use of DNS Service Records (SRVs) [RFC2782] to discover the AC address(es). In this case, the WTP first obtains (e.g., from local configuration) the correct domain name suffix (e.g., "example.com") and performs an SRV lookup with Service name "capwap-control" and Proto "udp". Thus, the name resolved in DNS would be, e.g., "_capwap-control._udp.example.com". Note that the SRV record MAY specify a non-default port number for the control channel; the port number for the data channel is the next port number (control channel port + 1).
DNS：WTPはACアドレスを発見するためにDNSサービスレコード（のSRV）[RFC2782]の使用をサポートするかもしれません。この場合、（ローカル構成から、例えば、）WTP最初取得正しいドメイン名サフィックス（例えば、「example.com」）とサービス名「CAPWAPコントロール」およびプロト「UDP」とSRVルックアップを行います。したがって、DNSで解決された名前は、例えば、「_capwap-control._udp.example.com」になります。 SRVレコードは、制御チャネル用のデフォルト以外のポート番号を指定することに注意してください。データチャネル用のポート番号は、次のポート番号（制御チャネルポート+ 1）です。
An AC MAY also communicate alternative ACs to the WTP within the Discovery Response message through the AC IPv4 List (see Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses provided in these two message elements are intended to help the WTP discover additional ACs through means other than those listed above.
ACはまた、（セクション4.6.2を参照）AC IPv4のリスト（セクション4.6.2を参照）、AC IPv6のリストを発見応答メッセージ内WTPの代替ACSを通信することができます。これら2つのメッセージ要素内に設けられたアドレスは、WTPが上記以外の手段を介して追加のACSを発見に役立つことを意図しています。
The AC Name with Priority message element (see Section 4.6.5) is used to communicate a list of preferred ACs to the WTP. The WTP SHOULD attempt to utilize the ACs listed in the order provided by the AC. The Name-to-IP Address mapping is handled via the Discovery message exchange, in which the ACs provide their identity in the AC Name (see Section 4.6.4) message element in the Discovery Response message.
優先メッセージ要素（セクション4.6.5を参照）とAC NameはWTPに好ましいのACのリストを通信するために使用されます。 WTPは、ACによって提供される順にリストされているACSを利用しようとするべきです。名からIPアドレスへのマッピングがACSはACの名前で自分のアイデンティティを提供する発見メッセージの交換を介して処理されるディスカバリー応答メッセージにメッセージ要素（セクション4.6.4を参照してください）。
Once the WTP has received Discovery Response messages from the candidate ACs, it MAY use other factors to determine the preferred AC. For instance, each binding defines a WTP Radio Information message element (see Section 2.1), which the AC includes in Discovery Response messages. The presence of one or more of these message elements is used to identify the CAPWAP bindings supported by the AC. A WTP MAY connect to an AC based on the supported bindings advertised.
WTP候補ACSからのディスカバリ応答メッセージを受信した後、それは好ましいACを決定する他の要因を使用するかもしれません。例えば、各結合は、ACが発見応答メッセージに含まWTPラジオ情報メッセージ要素（セクション2.1を参照）、定義します。これらのメッセージ要素のうちの1つまたは複数の存在は、ACによってサポートCAPWAPバインディングを識別するために使用されます。 WTPは、宣伝サポートバインディングに基づいてACに接続することができます。
While fragmentation and reassembly services are provided by IP, the CAPWAP protocol also provides such services. Environments where the CAPWAP protocol is used involve firewall, NAT, and "middlebox" devices, which tend to drop IP fragments to minimize possible DoS attacks. By providing fragmentation and reassembly at the application layer, any fragmentation required due to the tunneling component of the CAPWAP protocol becomes transparent to these intermediate devices. Consequently, the CAPWAP protocol can be used in any network topology including firewall, NAT, and middlebox devices.
フラグメンテーションと再組立サービスはIPによって提供されているが、CAPWAPプロトコルはまた、そのようなサービスを提供します。 CAPWAPプロトコルが使用されている環境では、ファイアウォール、NAT、および可能なDoS攻撃を最小限にするためにIPフラグメントをドロップする傾向があり、「ミドル」デバイスを伴います。起因CAPWAPプロトコルのトンネリングコンポーネントにアプリケーション層、必要な任意の断片に断片化と再アセンブリを提供することにより、これらの中間デバイスに透明になります。従って、CAPWAPプロトコルは、ファイアウォール、NAT、およびミドルデバイスを含む任意のネットワークトポロジで使用することができます。
It is important to note that the fragmentation mechanism employed by CAPWAP has known limitations and deficiencies, which are similar to those described in [RFC4963]. The limited size of the Fragment ID field (see Section 4.3) can cause wrapping of the field, and hence cause fragments from different datagrams to be incorrectly spliced together (known as "mis-associated"). For example, a 100Mpbs link with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP implementers are warned to properly size their buffers for reassembly purposes based on the expected wireless technology throughput.
CAPWAPによって採用フラグメンテーションメカニズムは[RFC4963]に記載のものと類似している制限および欠点を、知っていることに注意することが重要です。フラグメントIDフィールドの制限された大きさ（4.3節を参照）フィールドのラッピングを引き起こし、それゆえ異なるデータグラムのフラグメントが誤って（「MIS-関連」として知られている）を一緒にスプライシングさせることができます。例えば、1500年のMTU（1450バイトで断片化を引き起こす）と100Mpbsリンクは8秒でフラグメントIDフィールドラップを引き起こします。その結果、CAPWAP実装者が適切に予想される無線技術のスループットに基づいて再構築目的のためにそのバッファをサイズに警告しています。
CAPWAP implementations SHOULD perform MTU Discovery (see Section 3.5), which can avoid the need for fragmentation. At the time of writing of this specification, most enterprise switching and routing infrastructure were capable of supporting "mini-jumbo" frames (1800 bytes), which eliminates the need for fragmentation (assuming the station's MTU is 1500 bytes). The need for fragmentation typically continues to exist when the WTP communicates with the AC over a Wide Area Network (WAN). Therefore, future versions of the CAPWAP protocol SHOULD consider either increasing the size of the Fragment ID field or providing alternative extensions.
CAPWAP実装は断片化の必要性を回避することができMTUディスカバリーを（3.5節を参照）、実行する必要があります。本明細書の執筆時点で、ほとんどの企業のスイッチングおよびルーティングインフラストラクチャは、（ステーションのMTUは1500バイトであると仮定して）の断片化の必要性を排除する、「ミニジャンボ」フレーム（1800バイト）をサポートすることができました。断片化の必要性は、典型的には、WTPがワイドエリアネットワーク（WAN）を介してACと通信するときに存在し続けます。そのため、CAPWAPプロトコルの将来のバージョンは、フラグメントIDフィールドのサイズを大きくしたり、代替の拡張機能を提供するいずれか検討すべきです。
Once a WTP has discovered the AC with which it wishes to establish a CAPWAP session, it SHOULD perform a Path MTU (PMTU) discovery. One recommendation for performing PMTU discovery is to have the WTP transmit Discovery Request (see Section 5.1) messages, and include the MTU Discovery Padding message element (see Section 4.6.32). The actual procedures used for PMTU discovery are described in [RFC1191] for IPv4; for IPv6, [RFC1981] SHOULD be used. Alternatively, implementers MAY use the procedures defined in [RFC4821]. The WTP SHOULD also periodically re-evaluate the PMTU using the guidelines provided in these two RFCs, using the Primary Discovery Request (see Section 5.3) along with the MTU Discovery Padding message element (see Section 4.6.32). When the MTU is initially known, or updated in the case where an existing session already exists, the discovered PMTU is used to configure the DTLS component (see Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit the MTU, defined in Section 3.4.
WTPは、それがCAPWAPセッションを確立することを希望するとの交流を発見したら、それはパスMTU（PMTU）の発見を実行する必要があります。 PMTUディスカバリを実行するための一つの推薦はWTPメッセージ（セクション5.1を参照）、（セクション4.6.32を参照）MTUディスカバリパディングメッセージ要素を含む探索要求を送信させることです。 PMTU発見のために使用される実際の手順は、IPv4の[RFC1191]に記載されています。 IPv6用に、[RFC1981]は使用されるべきです。代替として、実装者は[RFC4821]で定義された手順を使用するかもしれません。 WTPはまた、定期的にMTUディスカバリーパディングメッセージ要素と一緒にプライマリディスカバリ要求を（5.3節を参照）を使用して、これらの二つのRFCで提供されたガイドラインを使用してPMTUを再評価すべきである（セクション4.6.32を参照してください）。非DTLSフレームがMTUに合うように断片化される必要がありながら、MTUが最初に知られている、または既存のセッションが既に存在する場合には更新されると、発見されたPMTUがDTLSコンポーネントを設定するために使用され、（2.3.2.1項を参照してください） 、3.4節で定義されています。
This section contains the CAPWAP protocol packet formats. A CAPWAP protocol packet consists of one or more CAPWAP Transport Layer packet headers followed by a CAPWAP message. The CAPWAP message can be either of type Control or Data, where Control packets carry signaling, and Data packets carry user payloads. The CAPWAP frame formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP Data and Control packets are defined below.
このセクションでは、CAPWAPプロトコルのパケットフォーマットが含まれています。 CAPWAPプロトコルパケットは、CAPWAPメッセージに続く一つ以上のCAPWAPトランスポート層パケットヘッダから成ります。 CAPWAPメッセージのタイプまたはコントロールパケットがシグナリング運び、データパケットは、ユーザペイロードを運ぶデータのいずれかとすることができます。 CAPWAPデータパケットに対して、及びDTLSためCAPWAPフレームフォーマットはCAPWAPデータや制御パケットが以下に定義されるカプセル化されました。
The CAPWAP Control protocol includes two messages that are never protected by DTLS: the Discovery Request message and the Discovery Response message. These messages need to be in the clear to allow the CAPWAP protocol to properly identify and process them. The format of these packets are as follows:
ディスカバリー要求メッセージとディスカバリー応答メッセージ：CAPWAP制御プロトコルは、DTLSにより保護されることはありません2つのメッセージを含んでいます。これらのメッセージは、CAPWAPプロトコルが適切に識別し、それらを処理できるように明確にする必要があります。次のようにこれらのパケットのフォーマットは以下のとおりです。
CAPWAP Control Packet (Discovery Request/Response):
+-------------------------------------------+
| IP | UDP | CAPWAP | Control | Message |
| Hdr | Hdr | Header | Header | Element(s) |
+-------------------------------------------+
All other CAPWAP Control protocol messages MUST be protected via the DTLS protocol, which ensures that the packets are both authenticated and encrypted. These packets include the CAPWAP DTLS Header, which is described in Section 4.2. The format of these packets is as follows:
他のすべてのCAPWAP制御プロトコルメッセージは、パケットが認証および暗号化されていることを保証DTLSプロトコルを経由して保護しなければなりません。これらのパケットは、セクション4.2に記載されてCAPWAP DTLSヘッダを含みます。次のようにこれらのパケットのフォーマットは次のとおりです。
CAPWAP Control Packet (DTLS Security Required):
+------------------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr |
+------------------------------------------------------------------+
\---------- authenticated -----------/
\------------- encrypted ------------/
The CAPWAP protocol allows optional protection of data packets, using DTLS. Use of data packet protection is determined by AC policy. When DTLS is utilized, the optional CAPWAP DTLS Header is present, which is described in Section 4.2. The format of CAPWAP Data packets is shown below:
CAPWAPプロトコルは、DTLSを使用して、データパケットのオプションの保護を可能にします。データパケットの保護の使用はACポリシーによって決定されます。 DTLSを利用する場合、任意CAPWAP DTLSヘッダセクション4.2に記載されている、存在しています。 CAPWAPデータパケットのフォーマットを以下に示します。
CAPWAP Plain Text Data Packet :
+-------------------------------+
| IP | UDP | CAPWAP | Wireless |
| Hdr | Hdr | Header | Payload |
+-------------------------------+
DTLS Secured CAPWAP Data Packet:
+--------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr |
+--------------------------------------------------------+
\------ authenticated -----/
\------- encrypted --------/
UDP Header: All CAPWAP packets are encapsulated within either UDP, or UDP-Lite when used over IPv6. Section 3 defines the specific UDP or UDP-Lite usage.
UDPヘッダ：IPv6の上で使用すると、すべてのCAPWAPパケットはUDP、またはUDP-Liteのいずれかの中に封入されています。第3節では、特定のUDPまたはUDP-Liteの使用方法を定義します。
CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are prefixed with the CAPWAP DTLS Header (see Section 4.2).
CAPWAP DTLSヘッダー：CAPWAPプロトコルパケット暗号化されたすべてのDTLSはCAPWAP DTLSヘッダー（セクション4.2を参照）が付いています。
DTLS Header: The DTLS Header provides authentication and encryption services to the CAPWAP payload it encapsulates. This protocol is defined in [RFC4347].
DTLSヘッダー：DTLSヘッダーは、それがカプセル化CAPWAPペイロードに認証および暗号化サービスを提供します。このプロトコルは、[RFC4347]で定義されています。
CAPWAP Header: All CAPWAP protocol packets use a common header that immediately follows the CAPWAP preamble or DTLS Header. The CAPWAP Header is defined in Section 4.3.
CAPWAPヘッダ：すべてのCAPWAPプロトコルパケットは、直ちにCAPWAPプリアンブルまたはDTLSヘッダに続く共通ヘッダを使用します。 CAPWAPヘッダは、セクション4.3で定義されています。
Wireless Payload: A CAPWAP protocol packet that contains a wireless payload is a CAPWAP Data packet. The CAPWAP protocol does not specify the format of the wireless payload, which is defined by the appropriate wireless standard. Additional information is in Section 4.4.
無線ペイロード無線ペイロードを含むCAPWAPプロトコルパケットはCAPWAPデータパケットです。 CAPWAPプロトコルは、適切な無線規格によって定義されている無線ペイロードのフォーマットを指定していません。追加情報は、セクション4.4です。
Control Header: The CAPWAP protocol includes a signaling component, known as the CAPWAP Control protocol. All CAPWAP Control packets include a Control Header, which is defined in Section 4.5.1. CAPWAP Data packets do not contain a Control Header field.
制御ヘッダ：CAPWAPプロトコルは、CAPWAP制御プロトコルとして知られているシグナル伝達成分を含みます。すべてのCAPWAP制御パケットは、4.5.1項で定義されている制御ヘッダが含まれます。 CAPWAPデータパケットは、制御ヘッダフィールドが含まれていません。
Message Elements: A CAPWAP Control packet includes one or more message elements, which are found immediately following the Control Header. These message elements are in a Type/Length/Value style header, defined in Section 4.6.
メッセージ要素：CAPWAP制御パケットは、制御ヘッダの直後に見出される1つまたは複数のメッセージ要素を含みます。これらのメッセージ要素は、セクション4.6で定義されたタイプ/長さ/値スタイルのヘッダにあります。
A CAPWAP implementation MUST be capable of receiving a reassembled CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY indicate that it supports a higher maximum message length, by including the Maximum Message Length message element, see Section 4.6.31, in the Join Request message or the Join Response message.
CAPWAP実装は、長さ4096バイトの再組み立てCAPWAPメッセージを受信することができなければなりません。 CAPWAPの実装は、それが参加要求メッセージには、セクション4.6.31を参照するか、または応答メッセージに参加し、最大メッセージ長メッセージ要素を含むことによって、より高い最大メッセージ長をサポートしていることを示すことができます。
The CAPWAP preamble is common to all CAPWAP transport headers and is used to identify the header type that immediately follows. The reason for this preamble is to avoid needing to perform byte comparisons in order to guess whether or not the frame is DTLS encrypted. It also provides an extensibility framework that can be used to support additional transport types. The format of the preamble is as follows:
CAPWAPプリアンブルは全てCAPWAP転送ヘッダに共通であり、すぐに次のヘッダタイプを識別するために使用されます。このプリアンブル理由は、フレームがDTLSが暗号化されているかどうかを推測するために、バイトの比較を実行する必要がないようにすることです。また、追加のトランスポートタイプをサポートするために使用することができる拡張フレームワークを提供します。次のようにプリアンブルの形式は次のとおりです。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version| Type |
+-+-+-+-+-+-+-+-+
Version: A 4-bit field that contains the version of CAPWAP used in this packet. The value for this specification is zero (0).
バージョン：このパケットに使用されるCAPWAPのバージョンが含まれている4ビットのフィールド。この仕様の値はゼロ（0）です。
Type: A 4-bit field that specifies the payload type that follows the UDP header. The following values are supported:
タイプ：UDPヘッダに続くペイロードタイプを指定する4ビットのフィールド。次の値がサポートされています。
0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) immediately follows the UDP header. If the packet is received on the CAPWAP Data channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP Data packet. If received on the CAPWAP Control channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP Control packet. If the control packet is not a Discovery Request or Discovery Response packet, the packet MUST be dropped.
0 - CAPWAPヘッダー。 CAPWAPヘッダ（4.3節を参照）、すぐにUDPヘッダの後に続きます。パケットは、CAPWAPデータチャネル上で受信された場合、CAPWAPスタックはクリアテキストCAPWAPデータパケットとしてパケットを扱わなければなりません。 CAPWAP制御チャネル上で受信した場合は、CAPWAPスタックはクリアテキストCAPWAP制御パケットとしてパケットを扱わなければなりません。制御パケットは、ディスカバリー要求またはディスカバリ応答パケットでない場合、パケットは廃棄されなければなりません。
1 - CAPWAP DTLS Header. The CAPWAP DTLS Header (and DTLS packet) immediately follows the UDP header (see Section 4.2).
1 - CAPWAP DTLSヘッダー。 CAPWAP DTLSヘッダ（及びDTLSパケット）が直ちにUDPヘッダ（セクション4.2を参照）に従います。
The CAPWAP DTLS Header is used to identify the packet as a DTLS encrypted packet. The first eight bits include the common CAPWAP Preamble. The remaining 24 bits are padding to ensure 4-byte alignment, and MAY be used in a future version of the protocol. The DTLS packet [RFC4347] always immediately follows this header. The format of the CAPWAP DTLS Header is as follows:
CAPWAP DTLSヘッダーは、DTLS暗号化されたパケットとしてパケットを識別するために使用されます。最初の8ビットは、共通のCAPWAPプリアンブルを含みます。残りの24ビットはパディングが4バイト整列を保証するために、プロトコルの将来のバージョンで使用されてもよいです。 DTLSパケット[RFC4347]は常にすぐにこのヘッダの後に続きます。次のようにCAPWAP DTLSヘッダーの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble's Payload Type field MUST be set to one (1).
CAPWAPプリアンブル：CAPWAPプリアンブルは、セクション4.1で定義されています。 CAPWAP前文のペイロードタイプフィールドが1（1）に設定しなければなりません。
Reserved: The 24-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
予約：24ビットのフィールドは、将来の使用のために予約されています。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
All CAPWAP protocol messages are encapsulated using a common header format, regardless of the CAPWAP Control or CAPWAP Data transport used to carry the messages. However, certain flags are not applicable for a given transport. Refer to the specific transport section in order to determine which flags are valid.
すべてのCAPWAPプロトコルメッセージは関係なく、メッセージを運ぶために使用CAPWAP ControlまたはCAPWAPデータトランスポートの、共通ヘッダフォーマットを用いてカプセル化されます。しかし、特定のフラグは、与えられた輸送には適用されません。有効であるフラグを決定するために、特定のトランスポートセクションを参照してください。
Note that the optional fields defined in this section MUST be present in the precise order shown below.
このセクションで定義されたオプションのフィールドは、以下に示す正確な順序で存在しなければならないことに留意されたいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Frag Offset |Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Radio MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble's Payload Type field MUST be set to zero (0). If the CAPWAP DTLS Header is present, the version number in both CAPWAP Preambles MUST match. The reason for this duplicate field is to avoid any possible tampering of the version field in the preamble that is not encrypted or authenticated.
CAPWAPプリアンブル：CAPWAPプリアンブルは、セクション4.1で定義されています。 CAPWAP前文のペイロードタイプフィールドがゼロ（0）に設定しなければなりません。 CAPWAP DTLSヘッダが存在する場合、両方のCAPWAPプリアンブルにバージョン番号が一致しなければなりません。この重複したフィールドの理由は、暗号化や認証されていないプリアンブルにバージョンフィールドのいずれかの可能な改ざんを避けるためです。
HLEN: A 5-bit field containing the length of the CAPWAP transport header in 4-byte words (similar to IP header length). This length includes the optional headers.
HLEN：（IPヘッダ長と同様）4バイトワードでCAPWAPトランスポートヘッダの長さを含む5ビットのフィールド。この長さは、任意のヘッダを含みます。
RID: A 5-bit field that contains the Radio ID number for this packet, whose value is between one (1) and 31. Given that MAC Addresses are not necessarily unique across physical radios in a WTP, the Radio Identifier (RID) field is used to indicate with which physical radio the message is associated.
RID：このパケットの無線ID番号を含む5ビットのフィールド、その値がMACアドレスはWTP、ラジオ識別子（RID）フィールド内の物理無線横切っ必ずしも一意ではないことを考えると、（1）1〜31でありますメッセージが関連付けられている物理的な無線機とを示すために使用されます。
WBID: A 5-bit field that is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The following values are defined:
WBID：無線結合識別子である5ビットのフィールド。識別子は、無線に関連した無線パケットのタイプを示すであろう。次の値が定義されています。
0 - Reserved
0 - 予約
1 - IEEE 802.11
1 - IEEE 802.11
2 - Reserved
2 - 予約
3 - EPCGlobal [EPCGlobal]
3 - EPCグローバル[EPCグローバル]
T: The Type 'T' bit indicates the format of the frame being transported in the payload. When this bit is set to one (1), the payload has the native frame format indicated by the WBID field. When this bit is zero (0), the payload is an IEEE 802.3 frame.
T：タイプ「T」ビットは、ペイロード内に輸送されるフレームのフォーマットを示しています。このビットが1に設定されている場合（1）、ペイロードはWBIDフィールドによって示さネイティブフレームフォーマットを有しています。このビットがゼロ（0）である場合、ペイロードは、IEEE 802.3フレームです。
F: The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC.
F：フラグメント「F」ビットは、このパケットがフラグメントであるかどうかを示します。このビットが1（1）、パケットがフラグメントである、完全な情報を再構築するために、他の対応するフラグメントと組み合わせなければならないときWTPとACとの間で交換。
L: The Last 'L' bit is valid only if the 'F' bit is set and indicates whether the packet contains the last fragment of a fragmented exchange between WTP and AC. When this bit is one (1), the packet is the last fragment. When this bit is (zero) 0, the packet is not the last fragment.
L：最後の「L」ビットは「F」ビットが設定されている場合にのみ有効で、パケットはWTPとAC間の断片化された為替の最後の断片が含まれているかどうかを示します。このビットが1（1）である場合、パケットが最後のフラグメントです。このビットが0（ゼロ）である場合、パケットが最後のフラグメントではありません。
W: The Wireless 'W' bit is used to specify whether the optional Wireless Specific Information field is present in the header. A value of one (1) is used to represent the fact that the optional header is present.
W：ワイヤレス「W」ビットは、任意のワイヤレス固有情報フィールドがヘッダ内に存在するかどうかを指定するために使用されます。 1（1）の値は、オプションヘッダが存在することを表すために使用されます。
M: The Radio MAC 'M' bit is used to indicate that the Radio MAC Address optional header is present. This is used to communicate the MAC address of the receiving radio.
M：無線MAC「M」ビットは、無線MACは、オプションヘッダが存在するアドレスことを示すために使用されます。これは、受信無線のMACアドレスを通信するために使用されます。
K: The Keep-Alive 'K' bit indicates the packet is a Data Channel Keep-Alive packet. This packet is used to map the data channel to the control channel for the specified Session ID and to maintain freshness of the data channel. The 'K' bit MUST NOT be set for data packets containing user data.
K：キープアライブ「K」ビットは、パケットがデータチャネルキープアライブパケットであることを示しています。このパケットは、指定されたセッションIDのための制御チャネルにデータチャネルをマッピングするために、データチャネルの鮮度を維持するために使用されます。 「K」ビットは、ユーザデータを含むデータパケットのために設定してはいけません。
Flags: A set of reserved bits for future flags in the CAPWAP Header. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
フラグ：CAPWAPヘッダの将来のフラグのために予約されたビットのセット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
Fragment ID: A 16-bit field whose value is assigned to each group of fragments making up a complete set. The Fragment ID space is managed individually for each direction for every WTP/AC pair. The value of Fragment ID is incremented with each new set of fragments. The Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments.
フラグメントID：その値は完全なセットを構成するフラグメントの各グループに割り当てられる16ビットのフィールド。フラグメントID空間は、すべてのWTP / AC対について、各方向ごとに個別に管理されています。フラグメントIDの値は、フラグメントのそれぞれの新しいセットでインクリメントされます。最大値は、フラグメントのセットを同定するために使用された後のフラグメントIDはゼロにラップ。
Fragment Offset: A 13-bit field that indicates where in the payload this fragment belongs during re-assembly. This field is valid when the 'F' bit is set to 1. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. Note that the CAPWAP protocol does not allow for overlapping fragments.
フラグメントオフセット：ペイロードにこの断片再組み立て時に属する場所を示す13ビットのフィールド。 「F」ビットが1に8つのオクテット（64ビット）の単位で測定されたフラグメントオフセットに設定されている場合、このフィールドは有効です。最初のフラグメントはゼロオフセットしています。 CAPWAPプロトコルは重複断片を許可しないことに注意してください。
Reserved: The 3-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
予約：3ビットのフィールドは、将来の使用のために予約されています。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
Radio MAC Address: This optional field contains the MAC address of the radio receiving the packet. Because the native wireless frame format to IEEE 802.3 format causes the MAC address of the WTP's radio to be lost, this field allows the address to be communicated to the AC. This field is only present if the 'M' bit is set. The HLEN field assumes 4-byte alignment, and this field MUST be padded with zeroes (0x00) if it is not 4-byte aligned.
ラジオMACアドレス：このオプションフィールドは、パケットを受信した無線のMACアドレスが含まれています。 IEEE 802.3フォーマットへのネイティブ無線フレームフォーマットは、WTPの無線のMACアドレスが失われているため、このフィールドには、アドレスがACに伝達することができます。 「M」ビットが設定されている場合のみ、このフィールドが存在しています。 HLENフィールドは、4バイトのアラインメントを仮定し、それが整列4バイトでない場合、このフィールドはゼロ（0×00）で埋めなければなりません。
The field contains the basic format:
フィールドには、基本フォーマットが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length of the MAC address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: The MAC address of the receiving radio.
MACアドレス：ラジオ受信のMACアドレス。
Wireless Specific Information: This optional field contains technology-specific information that may be used to carry per-packet wireless information. This field is only present if the 'W' bit is set. The WBID field in the CAPWAP Header is used to identify the format of the Wireless-Specific Information optional field. The HLEN field assumes 4-byte alignment, and this field MUST be padded with zeroes (0x00) if it is not 4-byte aligned.
ワイヤレス固有の情報：このオプションフィールドは、パケット単位の無線情報を運ぶために使用することができる技術固有の情報が含まれています。 「W」ビットが設定されている場合のみ、このフィールドが存在しています。 CAPWAPヘッダのWBIDフィールドは、ワイヤレス固有の情報オプションフィールドのフォーマットを識別するために使用されます。 HLENフィールドは、4バイトのアラインメントを仮定し、それが整列4バイトでない場合、このフィールドはゼロ（0×00）で埋めなければなりません。
The Wireless-Specific Information field uses the following format:
ワイヤレス固有の情報フィールドは次の形式を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The 8-bit field contains the length of the data field, with a maximum size of 255.
長さ：8ビットのフィールドは、255の最大サイズと、データフィールドの長さを含みます。
Data: Wireless-specific information, defined by the wireless-specific binding specified in the CAPWAP Header's WBID field.
データ：無線固有で定義されたワイヤレス固有の情報は、CAPWAPヘッダのWBIDフィールドで指定されたバインディング。
Payload: This field contains the header for a CAPWAP Data Message or CAPWAP Control Message, followed by the data contained in the message.
ペイロード：このフィールドは、メッセージに含まれるデータに続く、CAPWAPデータメッセージまたはCAPWAP制御メッセージのヘッダーを含んでいます。
There are two different types of CAPWAP Data packets: CAPWAP Data Channel Keep-Alive packets and Data Payload packets. The first is used by the WTP to synchronize the control and data channels and to maintain freshness of the data channel. The second is used to transmit user payloads between the AC and WTP. This section describes both types of CAPWAP Data packet formats.
CAPWAPデータチャネルは、キープアライブパケットとデータペイロードパケット：CAPWAPデータパケットの2種類があります。最初は、制御及びデータチャネルを同期するために、データチャネルの鮮度を維持するために、WTPにより使用されます。第二は、ACとWTPの間のユーザペイロードを送信するために使用されます。このセクションでは、CAPWAPデータパケットフォーマットの両方のタイプについて説明します。
Both CAPWAP Data messages are transmitted on the CAPWAP Data channel.
どちらのCAPWAPデータメッセージはCAPWAPデータチャネルで送信されます。
The CAPWAP Data Channel Keep-Alive packet is used to bind the CAPWAP control channel with the data channel, and to maintain freshness of the data channel, ensuring that the channel is still functioning. The CAPWAP Data Channel Keep-Alive packet is transmitted by the WTP when the DataChannelKeepAlive timer expires (see Section 4.7.2). When the CAPWAP Data Channel Keep-Alive packet is transmitted, the WTP sets the DataChannelDeadInterval timer.
CAPWAPデータチャネルキープアライブパケットは、データチャネルとのCAPWAP制御チャネルをバインドすると、チャンネルがまだ機能していることを確認して、データチャネルの鮮度を維持するために使用されます。 CAPWAPデータチャネルキープアライブパケットがDataChannelKeepAliveタイマーが切れるWTPによって送信される（第4.7.2項を参照してください）。 CAPWAPデータチャネルキープアライブパケットが送信されると、WTPはDataChannelDeadIntervalタイマーを設定します。
In the CAPWAP Data Channel Keep-Alive packet, all of the fields in the CAPWAP Header, except the HLEN field and the 'K' bit, are set to zero upon transmission. Upon receiving a CAPWAP Data Channel Keep-Alive packet, the AC transmits a CAPWAP Data Channel Keep-Alive packet back to the WTP. The contents of the transmitted packet are identical to the contents of the received packet.
CAPWAPデータチャネルは、キープアライブパケットでは、CAPWAPヘッダ内のすべてのフィールドは、HLENフィールドと「K」ビットを除いて、送信時にゼロに設定されています。 CAPWAPデータチャネルキープアライブパケットを受信すると、ACはバックWTPにCAPWAPデータチャネルキープアライブパケットを送信します。送信されたパケットの内容は、受信したパケットの内容と同一です。
Upon receiving a CAPWAP Data Channel Keep-Alive packet, the WTP cancels the DataChannelDeadInterval timer and resets the DataChannelKeepAlive timer. The CAPWAP Data Channel Keep-Alive packet is retransmitted by the WTP in the same manner as the CAPWAP Control messages. If the DataChannelDeadInterval timer expires, the WTP tears down the control DTLS session, and the data DTLS session if one existed.
CAPWAPデータチャネルキープアライブパケットを受信すると、WTPはDataChannelDeadIntervalタイマーをキャンセルし、DataChannelKeepAliveタイマーをリセットします。 CAPWAPデータチャネルキープアライブパケットは、CAPWAP制御メッセージと同様にWTPによって再送されます。 DataChannelDeadIntervalタイマーが期限切れになった場合、WTPは1つが存在していた場合に制御DTLSセッション、およびデータDTLSセッションを切断します。
The CAPWAP Data Channel Keep-Alive packet contains the following payload immediately following the CAPWAP Header (see Section 4.3).
CAPWAPデータチャネルは、キープアライブパケットがすぐにCAPWAPヘッダ（4.3節を参照）、次の次のペイロードが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Element Length | Message Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Element Length: The 16-bit Length field indicates the number of bytes following the CAPWAP Header, with a maximum size of 65535.
メッセージ要素長さ：16ビット長のフィールド65535の最大サイズと、CAPWAPヘッダに続くバイト数を示します。
Message Element[0..N]: The message element(s) carry the information pertinent to each of the CAPWAP Data Channel Keep-Alive message. The following message elements MUST be present in this CAPWAP message:
メッセージ要素が[0..N]：メッセージ・エレメント（S）は、CAPWAPデータチャネルキープアライブメッセージの各々に関連する情報を運びます。次のメッセージ要素は、このCAPWAPメッセージの中に存在していなければなりません。
Session ID, see Section 4.6.37.
セッションIDは、セクション4.6.37を参照してください。
A CAPWAP protocol Data Payload packet encapsulates a forwarded wireless frame. The CAPWAP protocol defines two different modes of encapsulation: IEEE 802.3 and native wireless. IEEE 802.3 encapsulation requires that for 802.11 frames, the 802.11 *Integration* function be performed in the WTP. An IEEE 802.3- encapsulated user payload frame has the following format:
CAPWAPプロトコルデータペイロードパケットが転送された無線フレームをカプセル化します。 IEEE 802.3およびネイティブワイヤレス：CAPWAPプロトコルは、カプセル化の2つの異なるモードを定義しています。 IEEE 802.3カプセル化は802.11フレームのために、802.11 *統合*機能はWTPで行う必要があります。 IEEE 802.3-カプセル化されたユーザ・ペイロード・フレームは、次の形式を有します。
+------------------------------------------------------+
| IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
+------------------------------------------------------+
The CAPWAP protocol also defines the native wireless encapsulation mode. The format of the encapsulated CAPWAP Data frame is subject to the rules defined by the specific wireless technology binding. Each wireless technology binding MUST contain a section entitled "Payload Encapsulation", which defines the format of the wireless payload that is encapsulated within CAPWAP Data packets.
CAPWAPプロトコルはまた、ネイティブ無線カプセル化モードを定義します。カプセル化されたCAPWAPデータフレームのフォーマットは、特異的結合の無線技術によって定義された規則の対象となります。バインディング各無線技術は、CAPWAPデータパケット内にカプセル化された無線ペイロードのフォーマットを定義する「ペイロードカプセル化」と題するセクションを含まなければなりません。
For 802.3 payload frames, the 802.3 frame is encapsulated (excluding the IEEE 802.3 Preamble, Start Frame Delimiter (SFD), and Frame Check Sequence (FCS) fields). If the encapsulated frame would exceed the transport layer's MTU, the sender is responsible for the fragmentation of the frame, as specified in Section 3.4. The CAPWAP protocol can support IEEE 802.3 frames whose length is defined in the IEEE 802.3as specification [FRAME-EXT].
802.3ペイロードフレームの場合、802.3フレームは（フレームデリミタ（SFD）、およびフレームチェックシーケンス（FCS）フィールドを起動し、IEEE 802.3前文を除く）に封入されます。カプセル化されたフレームは、トランスポート層のMTUを超えてしまう場合は、送信者は3.4節で指定されるように、フレームの断片化を担当しています。 CAPWAPプロトコルは、その長さIEEE 802.3as仕様[FRAME-EXT]で定義されているIEEE 802.3フレームをサポートすることができます。
If the AC and WTP are configured to tunnel the data channel over DTLS, the proper DTLS session must be initiated. To avoid having to reauthenticate and reauthorize an AC and WTP, the DTLS data channel SHOULD be initiated using the TLS session resumption feature [RFC5246].
ACとWTPがトンネルにDTLSを介してデータ・チャネルを構成している場合は、適切なDTLSセッションが開始されなければなりません。 ACとWTPを再認証及び再認証することを避けるために、DTLSデータチャネルは、TLSセッション再開機能[RFC5246]を使用して開始されるべきです。
The AC DTLS implementation MUST NOT initiate a data channel session for a DTLS session for which there is no active control channel session.
AC DTLS実装は、アクティブな制御チャネル・セッションが存在しないいるDTLSセッションのデータ・チャネル・セッションを開始してはいけません。
The CAPWAP Control protocol provides a control channel between the WTP and the AC. Control messages are divided into the following message types:
CAPWAP制御プロトコルは、WTPとACとの間の制御チャネルを提供します。制御メッセージは、次のメッセージタイプに分けられます。
Discovery: CAPWAP Discovery messages are used to identify potential ACs, their load and capabilities.
ディスカバリー：CAPWAPディスカバリメッセージは、潜在的なACS、彼らの負荷や能力を識別するために使用されています。
Join: CAPWAP Join messages are used by a WTP to request service from an AC, and for the AC to respond to the WTP.
参加：CAPWAPメッセージがACからのサービスを要求するためにWTPで使用されて参加し、そしてACのためのWTPに応答します。
Control Channel Management: CAPWAP Control channel management messages are used to maintain the control channel.
制御チャネル管理：CAPWAP制御チャネル管理メッセージは、制御チャネルを維持するために使用されています。
WTP Configuration Management: The WTP Configuration messages are used by the AC to deliver a specific configuration to the WTP. Messages that retrieve statistics from a WTP are also included in WTP Configuration Management.
WTP構成管理：WTPの設定メッセージは、WTPに特定の構成を提供するためにACで使用されています。 WTPからの統計情報を取得するメッセージは、WTP構成管理に含まれています。
Station Session Management: Station Session Management messages are used by the AC to deliver specific station policies to the WTP.
駅セッション管理：駅セッション管理メッセージはWTPに固有の駅方針を実現するためにACで使用されています。
Device Management Operations: Device management operations are used to request and deliver a firmware image to the WTP.
デバイス管理の操作：デバイス管理操作が要求に使用し、WTPにファームウェアイメージを実現しています。
Binding-Specific CAPWAP Management Messages: Messages in this category are used by the AC and the WTP to exchange protocol-specific CAPWAP management messages. These messages may or may not be used to change the link state of a station.
バインディング固有CAPWAP管理メッセージを：このカテゴリーのメッセージは、プロトコル固有のCAPWAP管理メッセージを交換するためにACおよびWTPで使用されています。これらのメッセージは、またはステーションのリンク状態を変更するために使用してもしなくてもよいです。
Discovery, Join, Control Channel Management, WTP Configuration Management, and Station Session Management CAPWAP Control messages MUST be implemented. Device Management Operations messages MAY be implemented.
ディスカバリー、参加、コントロールチャネル管理、WTP構成管理、およびセッション管理ステーションCAPWAP制御メッセージを実装する必要があります。デバイス管理操作のメッセージが実装されてもよいです。
CAPWAP Control messages sent from the WTP to the AC indicate that the WTP is operational, providing an implicit keep-alive mechanism for the WTP. The Control Channel Management Echo Request and Echo Response messages provide an explicit keep-alive mechanism when other CAPWAP Control messages are not exchanged.
ACにWTPから送られたCAPWAP制御メッセージはWTPの暗黙的なキープアライブメカニズムを提供し、WTPが動作可能であることを示しています。制御チャネル管理エコー要求とエコー応答メッセージは、他のCAPWAP制御メッセージが交換されない、明示的なキープアライブメカニズムを提供します。
All CAPWAP Control messages are sent encapsulated within the CAPWAP Header (see Section 4.3). Immediately following the CAPWAP Header is the control header, which has the following format:
すべてのCAPWAP制御メッセージは、（4.3節を参照）CAPWAPヘッダ内にカプセル化送信されます。直後CAPWAPヘッダは、以下のフォーマットを有する制御ヘッダ、です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq Num | Msg Element Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type field identifies the function of the CAPWAP Control message. To provide extensibility, the Message Type field is comprised of an IANA Enterprise Number [RFC3232] and an enterprise-specific message type number. The first three octets contain the IANA Enterprise Number in network byte order, with zero used for CAPWAP base protocol (this specification) defined message types. The last octet is the enterprise-specific message type number, which has a range from 0 to 255.
メッセージタイプフィールドは、CAPWAP制御メッセージの機能を識別します。拡張性を提供するために、メッセージタイプフィールドはIANAエンタープライズ番号[RFC3232]と企業固有のメッセージタイプ番号から構成されています。最初の3つのオクテットは、CAPWAPベースプロトコル（本明細書）定義されたメッセージタイプに使用ゼロで、ネットワークバイト順でIANAエンタープライズ番号を含みます。最後のオクテットは、0から255までの範囲を有している企業固有のメッセージタイプ番号、です。
The Message Type field is defined as:
メッセージタイプフィールドは、以下のように定義されています。
Message Type =
IANA Enterprise Number * 256 +
Enterprise Specific Message Type Number
The CAPWAP protocol reliability mechanism requires that messages be defined in pairs, consisting of both a Request and a Response message. The Response message MUST acknowledge the Request message. The assignment of CAPWAP Control Message Type Values always occurs in pairs. All Request messages have odd numbered Message Type Values, and all Response messages have even numbered Message Type Values. The Request value MUST be assigned first. As an example, assigning a Message Type Value of 3 for a Request message and 4 for a Response message is valid, while assigning a Message Type Value of 4 for a Response message and 5 for the corresponding Request message is invalid.
CAPWAPプロトコルの信頼性メカニズムは、メッセージが要求および応答メッセージの両方からなるペアで定義されることを必要とします。応答メッセージは、要求メッセージを確認する必要があります。 CAPWAP制御メッセージタイプ値の割り当ては、常にペアで発生します。すべての要求メッセージは、奇数メッセージタイプ値の番号が付けられており、すべての応答メッセージにもメッセージタイプ値の番号が付けられています。要求値は、最初に割り当てなければなりません。対応する要求メッセージに対する応答メッセージ及び5 4のメッセージ・タイプ値を割り当てることは無効であるが、一例として、応答メッセージを要求メッセージおよび4の3のメッセージタイプ値を割り当てることは、有効です。
When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored.
WTPまたはACが奇数番号を認識していないメッセージ・タイプ値フィールドを持つメッセージを受信している場合、メッセージ・タイプ値フィールドの番号を1つインクリメントし、含むメッセージタイプ値フィールドを有する応答メッセージをインクリメントします値と値（認識されていない要求）と結果コードメッセージ要素を含む受信したメッセージの送信者に戻されます。不明なメッセージ・タイプが偶数の場合、メッセージは無視されます。
The valid values for CAPWAP Control Message Types are specified in the table below:
CAPWAP制御メッセージタイプの有効な値は以下の表に指定されています。
CAPWAP Control Message Message Type
Value
Discovery Request 1
Discovery Response 2
Join Request 3
Join Response 4
Configuration Status Request 5
Configuration Status Response 6
Configuration Update Request 7
Configuration Update Response 8
WTP Event Request 9
WTP Event Response 10
Change State Event Request 11
Change State Event Response 12
Echo Request 13
Echo Response 14
Image Data Request 15
Image Data Response 16
Reset Request 17
Reset Response 18
Primary Discovery Request 19
Primary Discovery Response 20
Data Transfer Request 21
Data Transfer Response 22
Clear Configuration Request 23
Clear Configuration Response 24
Station Configuration Request 25
Station Configuration Response 26
The Sequence Number field is an identifier value used to match Request and Response packets. When a CAPWAP packet with a Request Message Type Value is received, the value of the Sequence Number field is copied into the corresponding Response message.
シーケンス番号フィールドは、リクエストとレスポンスパケットを一致させるために使用される識別子の値です。要求メッセージタイプ値を有するCAPWAPパケットが受信されると、シーケンス番号フィールドの値が対応する応答メッセージにコピーされます。
When a CAPWAP Control message is sent, the sender's internal sequence number counter is monotonically incremented, ensuring that no two pending Request messages have the same sequence number. The Sequence Number field wraps back to zero.
CAPWAP制御メッセージが送信されると、送信者の内部シーケンス番号カウンタは単調に何の2つの保留中の要求メッセージは、同じシーケンス番号を持っていないことを保証し、インクリメントされます。シーケンス番号フィールドはゼロに戻ってラップします。
The Length field indicates the number of bytes following the Sequence Number field.
Lengthフィールドは、シーケンス番号フィールドに続くバイト数を示します。
The Flags field MUST be set to zero.
Flagsフィールドをゼロに設定しなければなりません。
The message element(s) carry the information pertinent to each of the control message types. Every control message in this specification specifies which message elements are permitted.
メッセージ・エレメント（S）は、制御メッセージタイプのそれぞれに関連する情報を運びます。この仕様のすべての制御メッセージは、メッセージ要素が許可されるかを指定します。
When a WTP or AC receives a CAPWAP message without a message element that is specified as mandatory for the CAPWAP message, then the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Missing Mandatory Message Element" is returned to the sender.
WTPまたはACは、CAPWAPメッセージのために必須として指定されたメッセージ要素なしCAPWAPメッセージを受信すると、次いで、CAPWAPメッセージが破棄されます。受信したメッセージが要求メッセージに対する応答メッセージは、メッセージ要素を担持しているため場合、示す結果コードをメッセージ要素と対応する応答メッセージ「エラー - 不足している必須のメッセージ要素は、」送信者に返されます。
When a WTP or AC receives a CAPWAP message with a message element that the WTP or AC does not recognize, the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Unrecognized Message Element" and one or more Returned Message Element message elements is included, containing the unrecognized message element(s).
WTPまたはACはWTPまたはACが認識しないというメッセージ要素を有するCAPWAPメッセージを受信すると、CAPWAPメッセージは破棄されます。含む、含まれている - 「認識できないメッセージ要素障害」および1つまたは複数の返されたメッセージ要素のメッセージ要素を受信したメッセージは、対応する応答メッセージは、メッセージ要素、示す結果コードをメッセージ要素と、対応する応答メッセージを担持するための要求メッセージであった場合認識されていないメッセージ・エレメント（S）。
The CAPWAP base protocol does not provide any Quality of Service (QoS) recommendations for use with the CAPWAP Data messages. Any wireless-specific CAPWAP binding specification that has QoS requirements MUST define the application of QoS to the CAPWAP Data messages.
CAPWAPベースプロトコルはCAPWAPデータメッセージで使用するための任意のサービス品質（QoS）の勧告を提供していません。 QoS要件を持つすべての無線特有のCAPWAPバインディング仕様は、CAPWAPデータメッセージへのQoSの適用を定義しなければなりません。
The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two levels of ECN functionality: full functionality and limited functionality. CAPWAP ACs and WTPs SHALL implement the limited functionality and are RECOMMENDED to implement the full functionality described in [RFC3168].
IPヘッダはまた、明示的輻輳通知（ECN）ビット[RFC3168]を含みます。完全な機能と制限された機能：[RFC3168]のセクション9.1.1は、ECN機能の二つのレベルを記述する。 CAPWAP ACSとWTPsは、限られた機能を実施しなければならないし、[RFC3168]に記載のすべての機能を実装するために推奨されています。
It is recommended that CAPWAP Control messages be sent by both the AC and the WTP with an appropriate Quality-of-Service precedence value, ensuring that congestion in the network minimizes occurrences of CAPWAP Control channel disconnects. Therefore, a QoS-enabled CAPWAP device SHOULD use the following values:
ネットワーク内の輻輳がCAPWAP制御チャネル切断の発生を最小限に抑えることを保証する、CAPWAP制御メッセージは、適切なサービス品質優先順位値とACとWTP両方で送信することが推奨されます。そのため、QoS対応CAPWAPデバイスは、以下の値を使用する必要があります。
DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which is described in [RFC2474]).
DSCP：CS6ホップ単位挙動サービスクラスが使用されるべきであり、[RFC2474]に記載されています）。
The CAPWAP Control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1).
CAPWAP制御プロトコルは、信頼性の高いトランスポートとして動作します。各要求メッセージに対する応答メッセージは、要求メッセージの受信を確認するために使用され、定義されます。また、制御ヘッダシーケンス番号フィールドは、要求メッセージと応答メッセージをペアリングするために使用される（セクション4.5.1参照）。
Response messages are not explicitly acknowledged; therefore, if a Response message is not received, the original Request message is retransmitted.
応答メッセージは、明示的に認められていません。応答メッセージが受信されない場合、したがって、元の要求メッセージが再送されます。
Implementations MUST keep track of the sequence number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same sequence number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message is received, meaning one where the sequence number is smaller, it MUST be ignored. A newer Request message, meaning one whose sequence number is larger, is processed as usual.
実装は、最後に受信したRequestメッセージのシーケンス番号を追跡する必要があり、対応する応答メッセージをキャッシュしなければなりません。同じシーケンス番号の再送を受信した場合、キャッシュされた応答メッセージは、再処理要求なしに再送信されなければなりません。古い要求メッセージを受信した場合、シーケンス番号が小さい場合、1を意味し、それを無視しなければなりません。配列番号大きいものを意味新しい要求メッセージは、通常通りに処理されます。
Note: A sequence number is considered "smaller" when s1 is smaller than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2 and (s1-s2)>128).
注：S1はS2モジューロ256よりも小さい場合、シーケンス番号は、 "小さい" と考えられる場合に限り、（S1 <S2と（S2-S1）<128）または（S1> S2と（S1-S2）> 128）。
Both the WTP and the AC can only have a single request outstanding at any given time. Retransmitted Request messages MUST NOT be altered by the sender.
WTPとACの両方が唯一の任意の時点で優れた単一の要求を持つことができます。再送された要求メッセージは、送信者が変更しないでください。
After transmitting a Request message, the RetransmitInterval (see Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are used to determine if the original Request message needs to be retransmitted. The RetransmitInterval timer is used the first time the Request is retransmitted. The timer is then doubled every subsequent time the same Request message is retransmitted, up to MaxRetransmit but no more than half the EchoInterval timer (see Section 4.7.7). Response messages are not subject to these timers.
Requestメッセージを送信した後、RetransmitIntervalタイマとMaxRetransmit変数が元の要求メッセージを再送信する必要があるかどうかを決定するために使用される（セクション4.8参照）（セクション4.7参照します）。 RetransmitIntervalタイマーは、要求が再送信された最初の時間を使用しています。タイマーは、同じ要求メッセージがMaxRetransmitまで、再送された後続のすべての時間が、半分以下EchoIntervalタイマーを（セクション4.7.7を参照）が倍増しています。応答メッセージは、これらのタイマーの対象にはなりません。
If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new sequence number, and be treated as a new Request message by the receiver. Note that there is a high chance that both the WTP and the AC's sequence numbers will become out of sync.
送信者は、（2.3.1項で説明したように、DTLSティアダウンへの移行につながる）MaxRetransmit再送信に達する前に要求メッセージを再送信を停止した場合は、受信者が受信し、処理要求をするか否かを知ることはできません。ほとんどの状況では、送信者はこれを行うには、代わりに応答メッセージが受信されるまで再送信を続行、またはDTLSティアダウンへの移行が発生しない（SHOULD NOT）。送信者が新規または変更要求メッセージとの接続を継続することを決定しない場合は、新しいメッセージは、新しいシーケンス番号を持たなければならない、と受信して、新しい要求メッセージとして扱われます。 WTPとACのシーケンス番号の両方が同期してなることを高い可能性があることに注意してください。
When a Request message is retransmitted, it MUST be re-encrypted via the DTLS stack. If the peer had received the Request message, and the corresponding Response message was lost, it is necessary to ensure that retransmitted Request messages are not identified as replays by the DTLS stack. Similarly, any cached Response messages that are retransmitted as a result of receiving a retransmitted Request message MUST be re-encrypted via DTLS.
要求メッセージが再送された場合は、DTLSスタックを経由して再暗号化されなければなりません。ピアは、要求メッセージを受け取っていた、とそれに対応する応答メッセージが失われた場合には、再送された要求メッセージがDTLSスタックによってリプレイとして識別されていないことを確認する必要があります。同様に、再送要求メッセージを受信した結果として、再送されたすべてのキャッシュされた応答メッセージは、DTLSを介して再暗号化しなければなりません。
Duplicate Response messages, identified by the Sequence Number field in the CAPWAP Control message header, SHOULD be discarded upon receipt.
CAPWAP制御メッセージヘッダ内のシーケンス番号フィールドによって識別された応答メッセージを、複製、受信時に廃棄されるべきです。
This section defines the CAPWAP Protocol message elements that are included in CAPWAP protocol control messages.
このセクションでは、CAPWAPプロトコル制御メッセージに含まれるCAPWAPプロトコルメッセージ要素を定義します。
Message elements are used to carry information needed in control messages. Every message element is identified by the Type Value field, defined below. The total length of the message elements is indicated in the message element's length field.
メッセージ要素は、制御メッセージに必要な情報を運ぶために使用されています。すべてのメッセージ要素を以下のように定義タイプ値フィールドによって識別されます。メッセージ要素の全長は、メッセージ要素の長さフィールドに示されています。
All of the message element definitions in this document use a diagram similar to the one below in order to depict its format. Note that to simplify this specification, these diagrams do not include the header fields (Type and Length). The header field values are defined in the message element descriptions.
この文書に記載されているメッセージ要素定義の全ては、その形式を描写するために、次のような図を使用します。これらの図は、ヘッダ・フィールド（タイプおよび長さ）を含まない、本明細書を簡略化することに注意してください。ヘッダフィールド値は、メッセージ要素の記述で定義されています。
Unless otherwise specified, a control message that lists a set of supported (or expected) message elements MUST NOT expect the message elements to be in any specific order. The sender MAY include the message elements in any order. Unless otherwise noted, one message element of each type is present in a given control message.
特に指定しない限り、サポートされる（あるいは期待）メッセージ要素のセットを一覧表示制御メッセージは、メッセージ要素は任意の特定の順序であることを予想してはいけません。送信者は、任意の順序でメッセージの要素を含んでもよいです。特に断りのない限り、各タイプの1つのメッセージ要素は、与えられた制御メッセージ内に存在します。
Unless otherwise specified, any configuration information sent by the AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) for more information).
特に指定しない限り、WTPにACによって送信されるすべての構成情報は、より多くの情報について（8.1節を参照））は、不揮発性記憶装置に保存することができます。
Additional message elements may be defined in separate IETF documents.
追加のメッセージ要素は、別々のIETF文書で定義されていてもよいです。
The format of a message element uses the TLV format shown here:
メッセージ要素の形式は、ここに示されているTLVフォーマットを使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... |
+-+-+-+-+-+-+-+-+
The 16-bit Type field identifies the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. The value of zero (0) is reserved and MUST NOT be used. The rest of the Type field values are allocated as follows:
16ビットのタイプフィールドは、Valueフィールドと長さ（16ビット）で運ばれた情報を識別する値フィールドのバイト数を示します。ゼロ（0）の値は予約されており、使用してはいけません。次のようにタイプフィールド値の残りが割り当てられます。
Usage Type Values
使用タイプ値
CAPWAP Protocol Message Elements 1 - 1023 IEEE 802.11 Message Elements 1024 - 2047 Reserved for Future Use 2048 - 3071 EPCGlobal Message Elements 3072 - 4095 Reserved for Future Use 4096 - 65535
CAPWAPプロトコルのメッセージ要素の1から1023 IEEE 802.11のメッセージ要素1024から2047将来の使用のために予約さ2048から3071のEPCglobalのメッセージ要素3072から4095に予約将来使用するために4096から65535
The table below lists the CAPWAP protocol Message Elements and their Type values.
以下の表は、CAPWAPプロトコルメッセージ要素とそのタイプの値を示しています。
CAPWAP Message Element Type Value
CAPWAPメッセージ要素タイプ値
AC Descriptor 1 AC IPv4 List 2 AC IPv6 List 3 AC Name 4 AC Name with Priority 5 AC Timestamp 6 Add MAC ACL Entry 7 Add Station 8 Reserved 9 CAPWAP Control IPV4 Address 10 CAPWAP Control IPV6 Address 11 CAPWAP Local IPV4 Address 30 CAPWAP Local IPV6 Address 50 CAPWAP Timers 12 CAPWAP Transport Protocol 51 Data Transfer Data 13 Data Transfer Mode 14 Decryption Error Report 15 Decryption Error Report Period 16 Delete MAC ACL Entry 17 Delete Station 18 Reserved 19 Discovery Type 20 Duplicate IPv4 Address 21 Duplicate IPv6 Address 22 ECN Support 53 Idle Timeout 23 Image Data 24 Image Identifier 25 Image Information 26 Initiate Download 27 Location Data 28 Maximum Message Length 29 MTU Discovery Padding 52 Radio Administrative State 31 Radio Operational State 32 Result Code 33 Returned Message Element 34 Session ID 35 Statistics Timer 36 Vendor Specific Payload 37 WTP Board Data 38 WTP Descriptor 39 WTP Fallback 40 WTP Frame Tunnel Mode 41 Reserved 42
AC記述子1 AC IPv4の一覧2 AC IPv6の一覧3 AC名4 AC名と優先5 ACタイムスタンプ6 MAC ACLエントリは、7局8予約9 CAPWAPコントロールIPv4アドレス10 CAPWAPコントロールIPv6アドレス11 CAPWAPローカルIPv4アドレス30 CAPWAPローカルIPv6を投稿50はCAPWAPタイマ12 CAPWAP転送プロトコル51データデータ13データ転送モードの転送アドレス14復号エラーレポート15復号エラーレポート期間16の削除MAC ACLエントリ17ステーション18予約を削除し19ディスカバリータイプ20重複IPv4アドレス21重複IPv6アドレス22 ECNサポート53アイドルタイムアウト23画像データ24画像識別子25映像情報26がダウンロード27ロケーションデータ28最大メッセージ長29 MTUディスカバリパディング52無線管理状態31ラジオ操作状態32結果コード33返されたメッセージ要素34セッションID 35統計タイマ36ベンダー固有ペイロードを開始37 WTPボードデータ38 WTP記述子39 WTPフォールバック40 WTPフレームトンネルモード41予約42
Reserved 43 WTP MAC Type 44 WTP Name 45 Unused/Reserved 46 WTP Radio Statistics 47 WTP Reboot Statistics 48 WTP Static IP Address Information 49
予約済み43 WTP MACタイプ44 WTP名45未使用/予約済み46 WTPラジオ統計47 WTPをリブート統計48 WTP静的IPアドレス情報49
The AC Descriptor message element is used by the AC to communicate its current state. The value contains the following fields.
AC記述子メッセージ要素は、その現在の状態を通信するためにACによって使用されます。値は、次のフィールドが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Active WTPs | Max WTPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | R-MAC Field | Reserved1 | DTLS Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1 for AC Descriptor
タイプ：1 AC記述子のために
Length: >= 12
長さ：> = 12
Stations: The number of stations currently served by the AC
駅：駅の数は現在ACで提供
Limit: The maximum number of stations supported by the AC
リミット：ACでサポートされているステーションの最大数
Active WTPs: The number of WTPs currently attached to the AC
アクティブWTPs：WTPsの数は、現在、ACに接続します
Max WTPs: The maximum number of WTPs supported by the AC
最大WTPs：ACによってサポートWTPsの最大数
Security: An 8-bit mask specifying the authentication credential type supported by the AC (see Section 2.4.4). The field has the following format:
セキュリティ：ACでサポートされている認証資格情報の種類を指定する8ビット・マスク（2.4.4項を参照してください）。フィールドの形式は次のとおりです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |S|X|R|
+-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
予約：将来の使用のために予約されたビットのセット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
S: The AC supports the pre-shared secret authentication, as described in Section 12.6.
S：12.6項で説明したようにACは、事前共有秘密認証をサポートしています。
X: The AC supports X.509 Certificate authentication, as described in Section 12.7.
X：12.7項で説明したようにACは、X.509証明書認証をサポートしています。
R: A reserved bit for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
R：将来の使用のために予約ビット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
R-MAC Field: The AC supports the optional Radio MAC Address field in the CAPWAP transport header (see Section 4.3). The following enumerated values are supported:
R-MACフィールド：ACは、CAPWAPトランスポートヘッダに任意の無線MACアドレスフィールドをサポート（4.3節を参照）。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - Supported
1 - サポートされています
2 - Not Supported
2 - サポートされていません
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
予約：将来の使用のために予約されたビットのセット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
DTLS Policy: The AC communicates its policy on the use of DTLS for the CAPWAP data channel. The AC MAY communicate more than one supported option, represented by the bit field below. The WTP MUST abide by one of the options communicated by AC. The field has the following format:
DTLSポリシー：ACは、CAPWAPデータチャネルのためのDTLSの使用に関する方針を伝えます。 ACは、以下のビットフィールドによって表される複数のサポートオプションを、通信することができます。 WTPはACによって通信のオプションのいずれかを遵守しなければなりません。フィールドの形式は次のとおりです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |D|C|R|
+-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
予約：将来の使用のために予約されたビットのセット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
D: DTLS-Enabled Data Channel Supported
D：DTLS対応のデータチャネルがサポートされています
C: Clear Text Data Channel Supported
C：クリアテキストデータチャネルはサポートされています
R: A reserved bit for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
R：将来の使用のために予約ビット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
AC Information Sub-Element: The AC Descriptor message element contains multiple AC Information sub-elements, and defines two sub-types, each of which MUST be present. The AC Information sub-element has the following format:
AC情報サブ要素：ACディスクリプタメッセージ要素は、複数のAC情報のサブ要素が含まれており、存在しなければならないそれぞれが2つのサブタイプを定義します。 AC情報サブ要素の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Type | AC Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AC Information Vendor Identifier: A 32-bit value containing the IANA-assigned "Structure of Management Information (SMI) Network Management Private Enterprise Codes".
AC情報ベンダー識別子：IANAによって割り当てられた「管理情報（SMI）ネットワーク管理プライベートエンタープライズコードの構造」を含む32ビットの値。
AC Information Type: Vendor-specific encoding of AC information in the UTF-8 format [RFC3629]. The following enumerated values are supported. Both the Hardware and Software Version sub-elements MUST be included in the AC Descriptor message element. The values listed below are used in conjunction with the AC Information Vendor Identifier field, whose value MUST be set to zero (0). This field, combined with the AC Information Vendor Identifier set to a non-zero (0) value, allows vendors to use a private namespace.
AC情報タイプ：UTF-8フォーマット[RFC3629]でのAC情報のベンダー固有のエンコード。以下の列挙値がサポートされています。ハードウェアおよびソフトウェアバージョンのサブ要素の両方がAC記述子メッセージ要素に含まれなければなりません。下記の値は、値ゼロ（0）に設定しなければならないAC情報ベンダ識別子フィールドと併せて使用されています。 AC情報ベンダー識別子がゼロ（0）の値に設定組み合わせるこのフィールドは、ベンダーがプライベート名前空間を使用することを可能にします。
4 - Hardware Version: The AC's hardware version number.
4 - ハードウェアのバージョン：ACのハードウェアのバージョン番号。
5 - Software Version: The AC's Software (firmware) version number.
5 - ソフトウェアバージョン：ACのソフトウェア（ファームウェア）のバージョン番号。
AC Information Length: Length of vendor-specific encoding of AC information, with a maximum size of 1024.
AC情報の長さ：AC情報のベンダー固有のエンコーディングの長さ1024の最大サイズを有します。
AC Information Data: Vendor-specific encoding of AC information.
AC情報データ：AC情報のベンダー固有のエンコード。
The AC IPv4 List message element is used to configure a WTP with the latest list of ACs available for the WTP to join.
AC IPv4の一覧メッセージ要素は、WTPが参加するために利用可能なACの最新のリストとWTPを設定するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for AC IPv4 List
タイプ：AC IPv4のリストのための2
Length: >= 4
長さ：> = 4
AC IP Address: An array of 32-bit integers containing AC IPv4 Addresses, containing no more than 1024 addresses.
AC IPアドレス：ACのIPv4アドレスを含む32ビット整数のアレイ、全く1024の以上のアドレスを含んでいません。
The AC IPv6 List message element is used to configure a WTP with the latest list of ACs available for the WTP to join.
AC IPv6の一覧メッセージ要素は、WTPが参加するために利用可能なACの最新のリストとWTPを設定するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 for AC IPV6 List
タイプ：AC IPV6 Listの3
Length: >= 16
長さ：> = 16
AC IP Address: An array of 128-bit integers containing AC IPv6 Addresses, containing no more than 1024 addresses.
AC IPアドレス：AC IPv6アドレスを含む128ビットの整数の配列、せいぜい1024個のアドレスを含んでいません。
The AC Name message element contains an UTF-8 [RFC3629] representation of the AC identity. The value is a variable-length byte string. The string is NOT zero terminated.
AC名メッセージ要素はAC同一のUTF-8 [RFC3629]表現を含みます。値は、可変長のバイト列です。文字列が終了し、ゼロではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Type: 4 for AC Name
タイプ：4 AC名用
Length: >= 1
長さ：> = 1
Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC's name, whose maximum size MUST NOT exceed 512 bytes.
名前：最大サイズ512のバイトを超えてはならないACの名前を含む可変長UTF-8でエンコードされた文字列[RFC3629]。
The AC Name with Priority message element is sent by the AC to the WTP to configure preferred ACs. The number of instances of this message element is equal to the number of ACs configured on the WTP. The WTP also uses this message element to send its configuration to the AC.
優先メッセージ要素とAC名前好ましいACSを設定するWTPにACによって送信されます。このメッセージ・エレメントのインスタンスの数は、WTPに設定さのACの数に等しいです。 WTPはまた、ACにその設定を送信するには、このメッセージの要素を使用しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 for AC Name with Priority
タイプ：5優先順位のAC名について
Length: >= 2
長さ：> = 2
Priority: A value between 1 and 255 specifying the priority order of the preferred AC. For instance, the value of one (1) is used to set the primary AC, the value of two (2) is used to set the secondary, etc.
優先順位：好適なACの優先順位を指定する1〜255の値。プライマリACを設定するために使用され、例えば、一方の値が（1）では、2つの値（2）は二次、等を設定するために使用され
AC Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC name, whose maximum size MUST NOT exceed 512 bytes.
AC名：最大サイズが512のバイトを超えてはならないAC名を含む可変長UTF-8でエンコードされた文字列[RFC3629]。
The AC Timestamp message element is sent by the AC to synchronize the WTP clock.
ACタイムスタンプメッセージ要素は、WTPのクロックを同期させるためにACによって送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Timestamp
タイプ：6 ACタイムスタンプのために
Length: 4
長さ：4
Timestamp: The AC's current time, allowing all of the WTPs to be time synchronized in the format defined by Network Time Protocol (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of the NTP time are included in this field.
タイムスタンプ：ACの現在時刻、WTPsの全てを許可するには時間がRFC 1305 [RFC1305]でネットワークタイムプロトコル（NTP）によって定義されたフォーマットで同期します。 NTPタイムの唯一の上位32ビットがこのフィールドに含まれています。
The Add MAC Access Control List (ACL) Entry message element is used by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP no longer provides service to the MAC addresses provided in the message. The MAC addresses provided in this message element are not expected to be saved in non-volatile memory on the WTP. The MAC ACL table on the WTP is cleared every time the WTP establishes a new session with an AC.
追加MACアクセス制御リスト（ACL）エントリメッセージ要素は、WTPは、もはやメッセージで提供されたMACアドレスにサービスを提供することを保証しません、WTPのMAC ACLリストのエントリを追加するためにACで使用されています。このメッセージ要素で提供MACアドレスは、WTPの不揮発性メモリに保存されることが予想されていません。 WTPのMAC ACLテーブルには、WTPはACとの新しいセッションを確立するたびにクリアされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 7 for Add MAC ACL Entry
タイプ：7 MAC ACLエントリの追加について
Length: >= 8
長さ：> = 8
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This value MUST NOT exceed 255.
エントリのNUM：配列の長さ/ MAC Addressフィールドのインスタンスの数。この値は255を超えてはなりません。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: MAC addresses to add to the ACL.
MACアドレス：MACはACLに追加するアドレス。
The Add Station message element is used by the AC to inform a WTP that it should forward traffic for a station. The Add Station message element is accompanied by technology-specific binding information element(s), which may include security parameters. Consequently, the security parameters MUST be applied by the WTP for the station.
追加ステーションメッセージ要素は、それが駅のトラフィックを転送する必要があることをWTPを知らせるためにACで使用されています。追加ステーションのメッセージ要素は、セキュリティパラメータを含むことができる技術的結合の情報要素（複数可）、を伴います。これにより、セキュリティパラメータは、ステーションのためにWTPによって適用されなければなりません。
After station policy has been delivered to the WTP through the Add Station message element, an AC MAY change any policies by sending a modified Add Station message element. When a WTP receives an Add Station message element for an existing station, it MUST override any existing state for the station.
駅のポリシーは駅を追加メッセージ素子を介してWTPに配信された後、ACは修正ステーションを追加メッセージ要素を送信することにより、任意のポリシーを変更することがあります。 WTPは、既存のステーションの追加ステーションのメッセージ要素を受信すると、それは駅の既存の状態をオーバーライドする必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+
Type: 8 for Add Station
タイプ：8ステーションを追加のための
Length: >= 8
長さ：> = 8
Radio ID: An 8-bit value representing the radio, whose value is between one (1) and 31.
無線ID：無線を表す8ビットの値で、その値は1（1）と31の間です。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: The station's MAC address.
MACアドレス：ステーションのMACアドレス。
VLAN Name: An optional variable-length UTF-8 encoded string [RFC3629], with a maximum length of 512 octets, containing the VLAN Name on which the WTP is to locally bridge user data. Note this field is only valid with WTPs configured in Local MAC mode.
VLAN名：WTPがローカルブリッジユーザデータにされているVLAN名を含む512オクテットの最大長さを有する任意可変長UTF-8でエンコードされた文字列[RFC3629]、。このフィールドは、ローカルMACモードで構成WTPsでのみ有効であることに注意してください。
The CAPWAP Control IPv4 Address message element is sent by the AC to the WTP during the Discovery process and is used by the AC to provide the interfaces available on the AC, and the current number of WTPs connected. When multiple CAPWAP Control IPV4 Address message elements are returned, the WTP SHOULD perform load balancing across the multiple interfaces (see Section 6.1).
CAPWAPコントロールのIPv4アドレスメッセージ要素は、検出プロセス中WTPにACによって送信され、ACで利用可能なインターフェース、及び接続WTPsの現在の数を提供するためにACによって使用されます。複数のCAPWAP制御IPV4アドレスメッセージ要素が返されたとき、WTPは、複数のインターフェースを横切って負荷分散を実行する必要があり（セクション6.1を参照）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Control IPv4 Address
タイプ：CAPWAPコントロールIPv4アドレスのための10
Length: 6
長さ：6
IP Address: The IP address of an interface.
IPアドレス：インターフェイスのIPアドレス。
WTP Count: The number of WTPs currently connected to the interface, with a maximum value of 65535.
WTP数：WTPsの数は現在65535の最大値を用いて、インターフェースに接続されています。
The CAPWAP Control IPv6 Address message element is sent by the AC to the WTP during the Discovery process and is used by the AC to provide the interfaces available on the AC, and the current number of WTPs connected. This message element is useful for the WTP to perform load balancing across multiple interfaces (see Section 6.1).
CAPWAPコントロールのIPv6アドレスメッセージ要素は、検出プロセス中WTPにACによって送信され、ACで利用可能なインターフェース、及び接続WTPsの現在の数を提供するためにACによって使用されます。 WTPは、複数のインターフェイス間の負荷バランシングを実行するために、このメッセージ要素が有用である（6.1節を参照）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for CAPWAP Control IPv6 Address
タイプ：CAPWAPコントロールIPv6アドレスのための11
Length: 18
長さ：18
IP Address: The IP address of an interface.
IPアドレス：インターフェイスのIPアドレス。
WTP Count: The number of WTPs currently connected to the interface, with a maximum value of 65535.
WTP数：WTPsの数は現在65535の最大値を用いて、インターフェースに接続されています。
The CAPWAP Local IPv4 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv4 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element.
CAPWAPローカルのIPv4アドレスメッセージ要素が加入応答で、いずれかのWTPによって、参加要求で、またはACによって送信されます。 CAPWAPローカルのIPv4アドレスメッセージ要素は、送信機のIPアドレスを通信するために使用されます。受信機は、ミドルボックスは、メッセージ要素の値に対してパケットの送信元IPアドレスを比較することにより、2つのピア間に存在するかどうかを決定するためにこれを使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for CAPWAP Local IPv4 Address
タイプ：CAPWAPローカルIPv4アドレスのための30
Length: 4
長さ：4
IP Address: The IP address of the sender.
IPアドレス：送信者のIPアドレス。
The CAPWAP Local IPv6 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv6 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element.
CAPWAPローカルIPv6アドレスメッセージ要素が加入応答で、いずれかのWTPによって、参加要求で、またはACによって送信されます。 CAPWAPローカルIPv6アドレスメッセージ要素は、送信機のIPアドレスを通信するために使用されます。受信機は、ミドルボックスは、メッセージ要素の値に対してパケットの送信元IPアドレスを比較することにより、2つのピア間に存在するかどうかを決定するためにこれを使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 50 for CAPWAP Local IPv6 Address
タイプ：CAPWAPローカルIPv6アドレスのための50
Length: 16
長さ：16
IP Address: The IP address of the sender.
IPアドレス：送信者のIPアドレス。
The CAPWAP Timers message element is used by an AC to configure CAPWAP timers on a WTP.
CAPWAPタイマメッセージ要素はWTPにCAPWAPタイマーを設定するためにACによって使用されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12 for CAPWAP Timers
タイプ：12 CAPWAPタイマーのための
Length: 2
長さ：2
Discovery: The number of seconds between CAPWAP Discovery messages, when the WTP is in the Discovery phase. This value is used to configure the MaxDiscoveryInterval timer (see Section 4.7.10).
ディスカバリー：CAPWAPディスカバリメッセージ間の秒数、WTPが発見フェーズです。この値は、（セクション4.7.10を参照してください）MaxDiscoveryIntervalタイマーを設定するために使用されます。
Echo Request: The number of seconds between WTP Echo Request CAPWAP messages. This value is used to configure the EchoInterval timer (see Section 4.7.7). The AC sets its EchoInterval timer to this value, plus the maximum retransmission time as described in Section 4.5.3.
エコー要求：WTPエコー要求CAPWAPメッセージ間の秒数。この値はEchoIntervalタイマーを設定するために使用される（セクション4.7.7を参照してください）。 ACは、この値にEchoIntervalタイマー、プラス4.5.3で説明したように、最大再送信時間を設定します。
When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be used (see Section 3). The CAPWAP IPv6 Transport Protocol message element is used by either the WTP or the AC to signal which transport protocol is to be used for the CAPWAP data channel.
CAPWAPがIPv6上で実行されると、UDP-LiteのまたはUDPトランスポートは（セクション3を参照）を使用することができます。 CAPWAP IPv6のトランスポートプロトコルのメッセージ要素は、CAPWAPデータチャネルに使用されるべきトランスポートプロトコルシグナリングするWTPまたはACのいずれかで使用されます。
Upon receiving the Join Request, the AC MAY set the CAPWAP Transport Protocol to UDP-Lite in the Join Response message if the CAPWAP message was received over IPv6, and the CAPWAP Local IPv6 Address message element (see Section 4.6.12) is present and no middlebox was detected (see Section 11).
参加要求を受信すると存在しているCAPWAPメッセージがIPv6を介して受信された場合、ACは、参加応答メッセージにUDP-LiteのにCAPWAPトランスポートプロトコルを設定することができ、CAPWAPローカルIPv6アドレスメッセージ要素は、（セクション4.6.12を参照）何ミドル（セクション11を参照）検出されませんでした。
Upon receiving the Join Response, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in the Configuration Status Request or Image Data Request message if the AC advertised support for UDP-Lite, the message was received over IPv6, the CAPWAP Local IPv6 Address message element (see Section 4.6.12) and no middlebox was detected (see Section 11). Upon receiving either the Configuration Status Request or the Image Data Request, the AC MUST observe the preference indicated by the WTP in the CAPWAP Transport Protocol, as long as it is consistent with what the AC advertised in the Join Response.
参加応答を受信すると、WTPは、ACはUDP-Liteのサポートをアドバタイズした場合、メッセージがIPv6、CAPWAPローカルIPv6アドレスを介して受信されたコンフィギュレーション・ステータス要求や画像データ要求メッセージにUDP-LiteのにCAPWAPトランスポートプロトコルを設定することができメッセージ・エレメント（セクション4.6.12を参照のこと）およびNOミドルは検出されなかった（セクション11を参照）。コンフィギュレーション・ステータス要求や画像データ要求のいずれかを受信すると、ACは、それがACが加入応答で宣伝するものと一致しているとして、CAPWAPトランスポートプロトコルにWTPで示さ好みを観察しなければなりません。
For any other condition, the CAPWAP Transport Protocol MUST be set to UDP.
その他の条件については、CAPWAPトランスポートプロトコルはUDPに設定しなければなりません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
Type: 51 for CAPWAP Transport Protocol
タイプ：CAPWAPトランスポートプロトコルのための51
Length: 1
長さ：1
Transport: The transport to use for the CAPWAP Data channel. The following enumerated values are supported:
交通：CAPWAPデータ・チャネルのために使用するトランスポート。以下の列挙値がサポートされています。
1 - UDP-Lite: The UDP-Lite transport protocol is to be used for the CAPWAP Data channel. Note that this option MUST NOT be used if the CAPWAP Control channel is being used over IPv4.
1 - UDP-Liteは：UDP-Liteのトランスポートプロトコルは、CAPWAPデータチャネルに使用されます。 CAPWAP制御チャネルはIPv4の上で使用されている場合は、このオプションを使用してはいけないことに注意してください。
2 - UDP: The UDP transport protocol is to be used for the CAPWAP Data channel.
2 - UDP：UDPトランスポートプロトコルは、CAPWAPデータチャネルに使用されます。
The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes.
データ転送データメッセージ要素は、デバッグ用ACに情報を提供するために、WTPにより使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Mode | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ....
+-+-+-+-+-+-+-+-+
Type: 13 for Data Transfer Data
タイプ：データ転送データのための13
Length: >= 5
長さ：> = 5
Data Type: An 8-bit value representing the transfer Data Type. The following enumerated values are supported:
データタイプ：転送データタイプを示す8ビット値。以下の列挙値がサポートされています。
1 - Transfer data is included.
1 - 転送データが含まれています。
2 - Last Transfer Data Block is included (End of File (EOF)).
2 - データブロックは、（ファイルの終わり（EOF））を含まれている最後の転送。
5 - An error occurred. Transfer is aborted.
5 - エラーが発生しました。転送が中断されます。
Data Mode: An 8-bit value describing the type of information being transmitted. The following enumerated values are supported:
データモード：送信される情報のタイプを記述する8ビット値。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - WTP Crash Data
1 - WTPクラッシュデータ
2 - WTP Memory Dump
2 - WTPのメモリダンプ
Data Length: Length of data field, with a maximum size of 65535.
データ長：データフィールドの長さ、65535の最大サイズを持ちます。
Data: Data being transferred from the WTP to the AC, whose type is identified via the Data Mode field.
データ：データは、そのタイプのデータModeフィールドによって識別されたAC、にWTPから転送されます。
The Data Transfer Mode message element is used by the WTP to indicate the type of data transfer information it is sending to the AC for debugging purposes.
データ転送モードメッセージ要素は、デバッグ目的のためにACに送信されたデータ転送情報の種類を示すために、WTPにより使用されます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Data Mode |
+-+-+-+-+-+-+-+-+
Type: 14 for Data Transfer Mode
タイプ：データ転送モードのための14
Length: 1
長さ：1
Data Mode: An 8-bit value describing the type of information being requested. The following enumerated values are supported:
データモード：要求された情報の種類を記述した8ビット値。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - WTP Crash Data
1 - WTPクラッシュデータ
2 - WTP Memory Dump
2 - WTPのメモリダンプ
The Decryption Error Report message element value is used by the WTP to inform the AC of decryption errors that have occurred since the last report. Note that this error reporting mechanism is not used if encryption and decryption services are provided in the AC.
復号化エラーレポートメッセージ要素の値は、最後のレポート以降に発生した復号化エラーのACを知らせるためにWTPで使用されています。暗号化と復号化サービスはACで提供されている場合は、このエラー報告メカニズムが使用されていないことに注意してください。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID |Num Of Entries | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report
タイプ：15復号化エラーレポートのために
Length: >= 9
長さ：> = 9
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31.
無線ID：無線識別子値1（1）と31の間であるWTP、上のインターフェースインデックスを指します。
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This field MUST NOT exceed the value of 255.
エントリのNUM：配列の長さ/ MAC Addressフィールドのインスタンスの数。このフィールドには、255の値を超えてはなりません。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: MAC address of the station that has caused decryption errors.
MACアドレス：復号化エラーが発生したステーションのMACアドレス。
The Decryption Error Report Period message element value is used by the AC to inform the WTP how frequently it should send decryption error report messages. Note that this error reporting mechanism is not used if encryption and decryption services are provided in the AC.
復号化エラーレポート期間メッセージ要素の値は、それが復号エラーレポートメッセージを送信する頻度WTPを知らせるためにACで使用されています。暗号化と復号化サービスはACで提供されている場合は、このエラー報告メカニズムが使用されていないことに注意してください。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for Decryption Error Report Period
タイプ：復号化エラーレポート期間の16
Length: 3
長さ：3
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31.
無線ID：無線識別子値1（1）と31の間であるWTP、上のインターフェースインデックスを指します。
Report Interval: A 16-bit unsigned integer indicating the time, in seconds. The default value for this message element can be found in Section 4.7.11.
レポート間隔：時間を秒単位で示す16ビットの符号なし整数。このメッセージ要素のデフォルト値は、セクション4.7.11で見つけることができます。
The Delete MAC ACL Entry message element is used by an AC to delete a MAC ACL entry on a WTP, ensuring that the WTP provides service to the MAC addresses provided in the message.
削除MAC ACLエントリメッセージ要素は、WTPがメッセージ内に設けられたMACアドレスにサービスを提供することを保証する、WTPにMAC ACLエントリを削除するためにACによって使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 17 for Delete MAC ACL Entry
タイプ：削除MAC ACLエントリのための17
Length: >= 8
長さ：> = 8
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This field MUST NOT exceed the value of 255.
エントリのNUM：配列の長さ/ MAC Addressフィールドのインスタンスの数。このフィールドには、255の値を超えてはなりません。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: An array of MAC addresses to delete from the ACL.
MACアドレス：MACの配列は、ACLから削除するアドレス。
The Delete Station message element is used by the AC to inform a WTP that it should no longer provide service to a particular station. The WTP MUST terminate service to the station immediately upon receiving this message element.
削除ステーションメッセージ要素は、それがもはや特定のステーションにサービスを提供するべきではないということWTPを知らせるためにACで使用されています。 WTPは、すぐにこのメッセージ要素を受信するステーションへのサービスを停止しなければなりません。
The transmission of a Delete Station message element could occur for various reasons, including for administrative reasons, or if the station has roamed to another WTP.
削除ステーションメッセージ要素の伝送は、管理上の理由など、様々な理由で発生する可能性があり、又はステーションは、別のWTPにローミングしている場合。
The Delete Station message element MAY be sent by the WTP, in the WTP Event Request message, to inform the AC that a particular station is no longer being provided service. This could occur as a result of an Idle Timeout (see section 4.4.43), due to internal resource shortages or for some other reason.
削除ステーションメッセージ要素は、特定の局がもはやサービスを提供されていることACを通知しないように、WTPイベント要求メッセージに、WTPによって送信されてもよいです。これは、内部リソース不足、または他の何らかの理由で、アイドルタイムアウト（セクション4.4.43を参照のこと）の結果として発生する可能性があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18 for Delete Station
タイプ：削除ステーションの18
Length: >= 8
長さ：> = 8
Radio ID: An 8-bit value representing the radio, whose value is between one (1) and 31.
無線ID：無線を表す8ビットの値で、その値は1（1）と31の間です。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: The station's MAC address.
MACアドレス：ステーションのMACアドレス。
The Discovery Type message element is used by the WTP to indicate how it has come to know about the existence of the AC to which it is sending the Discovery Request message.
ディスカバリータイプのメッセージ要素は、それがディスカバリ要求メッセージを送信しているためにACの存在を知るようになったかを示すために、WTPで使用されています。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Discovery Type|
+-+-+-+-+-+-+-+-+
Type: 20 for Discovery Type
タイプ：20ディスカバリーの種類について
Length: 1
長さ：1
Discovery Type: An 8-bit value indicating how the WTP discovered the AC. The following enumerated values are supported:
ディスカバリーのタイプ：WTPはACを発見したかを示す8ビットの値。以下の列挙値がサポートされています。
0 - Unknown
0 - 不明
1 - Static Configuration
1 - 静的構成
2 - DHCP
DHCP - 2
3 - DNS
DNS - 3
4 - AC Referral (used when the AC was configured either through the AC IPv4 List or AC IPv6 List message element)
4 - （ACは、いずれかのAC IPv4のリストまたはAC IPv6のリストメッセージ要素を介して設定されたときに使用）AC紹介
The Duplicate IPv4 Address message element is used by a WTP to inform an AC that it has detected another IP device using the same IP address that the WTP is currently using.
重複したIPv4アドレスメッセージ要素は、WTPが現在使用している同じIPアドレスを使用して別のIPデバイスを検出したことをACに通知するためにWTPによって使用されます。
The WTP MUST transmit this message element with the status set to 1 after it has detected a duplicate IP address. When the WTP detects that the duplicate IP address has been cleared, it MUST send this message element with the status set to 0.
WTPは、それが重複したIPアドレスを検出した後に1に設定された状態で、このメッセージ要素を送信しなければなりません。 WTPは、重複したIPアドレスがクリアされたことを検出すると、それが0に設定された状態で、このメッセージ要素を送らなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 21 for Duplicate IPv4 Address
タイプ：重複IPv4アドレスのための21
Length: >= 12
長さ：> = 12
IP Address: The IP address currently used by the WTP.
IPアドレス：現在WTPが使用するIPアドレス。
Status: The status of the duplicate IP address. The value MUST be set to 1 when a duplicate address is detected, and 0 when the duplicate address has been cleared.
ステータス：重複したIPアドレスの状態。重複アドレスがクリアされたときに値が重複アドレスが検出された1及び0に設定しなければなりません。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: The MAC address of the offending device.
MACアドレス：問題のあるデバイスのMACアドレス。
The Duplicate IPv6 Address message element is used by a WTP to inform an AC that it has detected another host using the same IP address that the WTP is currently using.
重複したIPv6アドレスメッセージ要素は、WTPが現在使用している同じIPアドレスを使用して別のホストを検出したことをACに通知するためにWTPによって使用されます。
The WTP MUST transmit this message element with the status set to 1 after it has detected a duplicate IP address. When the WTP detects that the duplicate IP address has been cleared, it MUST send this message element with the status set to 0.
WTPは、それが重複したIPアドレスを検出した後に1に設定された状態で、このメッセージ要素を送信しなければなりません。 WTPは、重複したIPアドレスがクリアされたことを検出すると、それが0に設定された状態で、このメッセージ要素を送らなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22 for Duplicate IPv6 Address
タイプ：重複IPv6アドレスのための22
Length: >= 24
長さ：> = 24
IP Address: The IP address currently used by the WTP.
IPアドレス：現在WTPが使用するIPアドレス。
Status: The status of the duplicate IP address. The value MUST be set to 1 when a duplicate address is detected, and 0 when the duplicate address has been cleared.
ステータス：重複したIPアドレスの状態。重複アドレスがクリアされたときに値が重複アドレスが検出された1及び0に設定しなければなりません。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
長さ：MACアドレスフィールドの長さ。フォーマットおよび[EUI-48]で指定された長さおよび[EUI-64]はサポートされています。
MAC Address: The MAC address of the offending device.
MACアドレス：問題のあるデバイスのMACアドレス。
The Idle Timeout message element is sent by the AC to the WTP to provide the Idle Timeout value that the WTP SHOULD enforce for its active stations. The value applies to all radios on the WTP.
アイドルタイムアウトメッセージ要素はWTPがそのアクティブ端末のために強制するアイドルタイムアウト値を提供するために、WTPにACによって送信されます。値はWTP上のすべての無線に適用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 23 for Idle Timeout
タイプ：アイドルタイムアウトのために23
Length: 4
長さ：4
Timeout: The current Idle Timeout, in seconds, to be enforced by the WTP. The default value for this message element is specified in Section 4.7.8.
タイムアウト：現在のアイドルタイムアウト（秒）は、WTPによって強制されます。このメッセージ要素のデフォルト値は、セクション4.7.8で指定されています。
The ECN Support message element is sent by both the WTP and the AC to indicate their support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168].
ECNサポートメッセージ要素は[RFC3168]で定義されるように、明示的輻輳通知（ECN）ビットのための彼らのサポートを示すために、WTPとACの両方によって送信されます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ECN Support |
+-+-+-+-+-+-+-+-+
Type: 53 for ECN Support
タイプ：53 ECNのサポートのために
Length: 1
長さ：1
ECN Support: An 8-bit value representing the sender's support for ECN, as defined in [RFC3168]. All CAPWAP Implementations MUST support the Limited ECN Support mode. Full ECN Support is used if both the WTP and AC advertise the capability for "Full and Limited ECN" Support; otherwise, Limited ECN Support is used.
ECNサポート：[RFC3168]で定義されるようECNのための送信者のサポートを表す8ビット値。すべてのCAPWAP実装は限定ECNサポートモードをサポートしなければなりません。 WTPとACの両方が「完全かつ限定ECN」サポートのための機能をアドバタイズ場合は全ECNサポートが使用されています。それ以外の場合は、リミテッドECNサポートが使用されています。
0 - Limited ECN Support
0 - 限定ECNのサポート
1 - Full and Limited ECN Support
1 - フル及び限定ECNのサポート
The Image Data message element is present in the Image Data Request message sent by the AC and contains the following fields.
画像データのメッセージ要素はACで送出された画像データ要求メッセージ中に存在し、次のフィールドが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24 for Image Data
タイプ：画像データの24
Length: >= 1
長さ：> = 1
Data Type: An 8-bit value representing the image Data Type. The following enumerated values are supported:
データタイプ：画像データの種類を表す8ビット値。以下の列挙値がサポートされています。
1 - Image data is included.
1 - 画像データが含まれています。
2 - Last Image Data Block is included (EOF).
2 - 最後の画像データブロックは、（EOF）が含まれます。
5 - An error occurred. Transfer is aborted.
5 - エラーが発生しました。転送が中断されます。
Data: The Image Data field contains up to 1024 characters, and its length is inferred from this message element's length field. If the block being sent is the last one, the Data Type field is set to 2. The AC MAY opt to abort the data transfer by setting the Data Type field to 5. When the Data Type field is 5, the Value field has a zero length.
データは、画像データのフィールドは、1024文字まで含まれており、その長さは、このメッセージ要素の長さフィールドから推論されます。送信されたブロックが最後のものである場合には、データタイプフィールドは、ACは、Data Typeフィールドが5である場合には、Valueフィールドが持つデータ型フィールドに5を設定することで、データ転送を中止することを選ぶかもしれない2に設定されています長さがゼロ。
The Image Identifier message element is sent by the AC to the WTP to indicate the expected active software version that is to be run on the WTP. The WTP sends the Image Identifier message element in order to request a specific software version from the AC. The actual download process is defined in Section 9.1. The value is a variable-length UTF-8 encoded string [RFC3629], which is NOT zero terminated.
画像識別メッセージ要素は、WTP上で実行されると予想アクティブなソフトウェアのバージョンを示すために、WTPにACによって送信されます。 WTPは、ACから特定のソフトウェアバージョンを要求するために、画像識別子のメッセージ要素を送信します。実際のダウンロード・プロセスは、セクション9.1で定義されています。値は終了ゼロではない可変長UTF-8でエンコードされた文字列[RFC3629]です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 25 for Image Identifier
タイプ：画像識別のための25
Length: >= 5
長さ：> = 5
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes".
ベンダー識別子：IANAによって割り当てられた「SMIネットワーク管理プライベートエンタープライズコード」を含む32ビットの値。
Data: A variable-length UTF-8 encoded string [RFC3629] containing the firmware identifier to be run on the WTP, whose length MUST NOT exceed 1024 octets. The length of this field is inferred from this message element's length field.
データ：長さが1024個のオクテットを超えてはならないWTP上で実行されるファームウェア識別子を含む可変長UTF-8でエンコードされた文字列[RFC3629]。このフィールドの長さは、このメッセージ要素の長さフィールドから推論されます。
The Image Information message element is present in the Image Data Response message sent by the AC to the WTP and contains the following fields.
画像情報のメッセージ要素は、WTPにACで送出された画像データ応答メッセージ中に存在し、次のフィールドが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Image Information
タイプ：画像情報26
Length: 20
長さ：20
File Size: A 32-bit value containing the size of the file, in bytes, that will be transferred by the AC to the WTP.
ファイルサイズ：ファイルのサイズを含む32ビット値、バイト単位で、WTPにACによって転送されるであろう。
Hash: A 16-octet MD5 hash of the image using the procedures defined in [RFC1321].
ハッシュ：[RFC1321]で定義された手順を使用して画像の16オクテットMD5ハッシュ。
The Initiate Download message element is used by the WTP to inform the AC that the AC SHOULD initiate a firmware upgrade. The AC subsequently transmits an Image Data Request message, which includes the Image Data message element. This message element does not contain any data.
ダウンロードメッセージを開始する要素は、ACは、ファームウェアのアップグレードを開始すべきことをACに通知するために、WTPで使用されています。 ACはその後、画像データメッセージ要素を含む画像データ要求メッセージを送信します。このメッセージ要素は、任意のデータが含まれていません。
Type: 27 for Initiate Download
タイプ：27ダウンロードを開始するための
Length: 0
長さ：0
The Location Data message element is a variable-length byte UTF-8 encoded string [RFC3629] containing user-defined location information (e.g., "Next to Fridge"). This information is configurable by the network administrator, and allows the WTP location to be determined. The string is not zero terminated.
ロケーションデータメッセージ要素（例えば、「次の冷蔵庫に」）、ユーザー定義の位置情報を含む可変長のバイトUTF-8でエンコードされた文字列[RFC3629]です。この情報は、ネットワーク管理者によって設定可能であり、WTPの位置を決定することを可能にします。文字列が終了し、ゼロではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| Location ...
+-+-+-+-+-+-+-+-+-
Type: 28 for Location Data
タイプ：28場所データの
Length: >= 1
長さ：> = 1
Location: A non-zero-terminated UTF-8 encoded string [RFC3629] containing the WTP location, whose maximum size MUST NOT exceed 1024.
場所：最大サイズ1024を超えてはならないWTP位置を含む非ゼロで終了するUTF-8でエンコードされた文字列[RFC3629]。
The Maximum Message Length message element is included in the Join Request message by the WTP to indicate the maximum CAPWAP message length that it supports to the AC. The Maximum Message Length message element is optionally included in Join Response message by the AC to indicate the maximum CAPWAP message length that it supports to the WTP.
最大メッセージ長メッセージ要素は、それがACにサポート最大CAPWAPメッセージの長さを示すために、WTPにより参加要求メッセージに含まれています。最大メッセージ長メッセージ要素は、必要に応じて、それはWTPにサポート最大CAPWAPメッセージの長さを示すために、ACによって応答メッセージを参加に含まれています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 29 for Maximum Message Length
タイプ：29メッセージの最大長について
Length: 2
長さ：2
Maximum Message Length A 16-bit unsigned integer indicating the maximum message length.
最大メッセージ長メッセージの最大長を示す16ビットの符号なし整数。
The MTU Discovery Padding message element is used as padding to perform MTU discovery, and MUST contain octets of value 0xFF, of any length.
MTUディスカバリパディングメッセージ要素は、MTU探索を実行するためにパディングとして使用され、任意の長さの値は0xFFのオクテットを含まなければなりません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding...
+-+-+-+-+-+-+-+-
Type: 52 for MTU Discovery Padding
タイプ：MTUディスカバリーパディングのための52
Length: Variable
長さ：可変
Pad: A variable-length pad, filled with the value 0xFF.
パッド：値は0xFFで満たされた可変長パッド。
The Radio Administrative State message element is used to communicate the state of a particular radio. The Radio Administrative State message element is sent by the AC to change the state of the WTP. The WTP saves the value, to ensure that it remains across WTP resets. The WTP communicates this message element during the configuration phase, in the Configuration Status Request message, to ensure that the AC has the WTP radio current administrative state settings. The message element contains the following fields:
無線管理状態メッセージ要素は、特定の無線の状態を通信するために使用されます。無線管理状態メッセージ要素はWTPの状態を変更するためにACによって送信されます。 WTPは、WTPのリセット全体で残っていることを確認するために、値を保存します。 WTPは、ACは、WTPラジオ現在の管理状態の設定を持っていることを保証するために、設定ステータス要求メッセージでは、構成フェーズ中にこのメッセージ要素を通信します。メッセージ要素は、以下のフィールドが含まれています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 31 for Radio Administrative State
タイプ：31ラジオの管理状態について
Length: 2
長さ：2
Radio ID: An 8-bit value representing the radio to configure, whose value is between one (1) and 31. The Radio ID field MAY also include the value of 0xff, which is used to identify the WTP. If an AC wishes to change the administrative state of a WTP, it includes 0xff in the Radio ID field.
無線ID：設定するためのラジオを表す8ビットの値で、その値は1（1）と31.無線IDフィールド間でもWTPを識別するために使用される値0xFFを含んでもよいです。 ACは、WTPの管理状態を変更したい場合は、無線IDフィールドには0xFFを含みます。
Admin State: An 8-bit value representing the administrative state of the radio. The default value for the Admin State field is listed in Section 4.8.1. The following enumerated values are supported:
Admin State：ラジオの管理状態を表す8ビットの値。 Admin Stateフィールドのデフォルト値は、セクション4.8.1に記載されています。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - Enabled
1 - 有効
2 - Disabled
2 - [無効]
The Radio Operational State message element is sent by the WTP to the AC to communicate a radio's operational state. This message element is included in the Configuration Update Response message by the WTP if it was requested to change the state of its radio, via the Radio Administrative State message element, but was unable to comply to the request. This message element is included in the Change State Event message when a WTP radio state was changed unexpectedly. This could occur due to a hardware failure. Note that the operational state setting is not saved on the WTP, and therefore does not remain across WTP resets. The value contains three fields, as shown below.
ラジオ操作状態メッセージ要素は、無線の動作状態を通信するためにACにWTPによって送信されます。このメッセージ要素は、それがその電波の状態を変更するように要求された場合、WTPによって設定の更新応答メッセージに含まれる無線管理状態メッセージ素子を介して、しかし、要求に応じることができなかったです。 WTPの無線状態が予期せず変更されたときに、このメッセージ要素が変更状態イベントメッセージに含まれています。これは、ハードウェア障害が原因発生する可能性があります。動作状態の設定がWTPに保存されていないことに注意してくださいので、WTPリセット後には残りません。以下に示すように値は、3つのフィールドが含まれています。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 32 for Radio Operational State
タイプ：32ラジオ運用状況について
Length: 3
長さ：3
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31. A value of 0xFF is invalid, as it is not possible to change the WTP's operational state.
無線ID：無線識別子値1（1）と31との間であり、WTPの動作状態を変更することはできないとしての0xFFの値は、無効であるWTP、上のインターフェースインデックスを指します。
State: An 8-bit Boolean value representing the state of the radio. The following enumerated values are supported:
状態：ラジオの状態を表す8ビットのブール値。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - Enabled
1 - 有効
2 - Disabled
2 - [無効]
Cause: When a radio is inoperable, the cause field contains the reason the radio is out of service. The following enumerated values are supported:
原因：ラジオが動作不能である場合には、原因フィールドは、ラジオがサービスの外にある理由が含まれています。以下の列挙値がサポートされています。
0 - Normal
0 - ノーマル
1 - Radio Failure
1 - ラジオの失敗
2 - Software Failure
2 - ソフトウェア障害
3 - Administratively Set
3 - 管理上設定してください
The Result Code message element value is a 32-bit integer value, indicating the result of the Request message corresponding to the sequence number included in the Response message.
結果コードメッセージ要素の値は、応答メッセージに含まれるシーケンス番号に対応する要求メッセージの結果を示す、32ビットの整数値です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 33 for Result Code
タイプ：結果コードのための33
Length: 4
長さ：4
Result Code: The following enumerated values are defined:
結果コード：以下の列挙値が定義されています。
0 Success
0成功
1 Failure (AC List Message Element MUST Be Present)
1つの失敗（AC一覧メッセージ要素が存在している必要があります）
2 Success (NAT Detected)
2成功（NAT検出）
3 Join Failure (Unspecified)
3故障（未指定）に参加
4 Join Failure (Resource Depletion)
4失敗に参加（資源枯渇）
5 Join Failure (Unknown Source)
5失敗（不明なソース）に参加
6 Join Failure (Incorrect Data)
6失敗（不正なデータ）に参加
7 Join Failure (Session ID Already in Use)
7故障に参加（セッションIDすでに使用中）
8 Join Failure (WTP Hardware Not Supported)
8失敗に参加（WTPハードウェアがサポートされていません）
9 Join Failure (Binding Not Supported)
9故障に参加（サポートされていないバインディング）
10 Reset Failure (Unable to Reset)
10リセット失敗（リセットすることができません）
11 Reset Failure (Firmware Write Error)
11リセット失敗（ファームウェアの書き込みエラー）
12 Configuration Failure (Unable to Apply Requested Configuration - Service Provided Anyhow)
12構成障害（要求された構成を適用することができません - サービスは、とにかく提供します）
13 Configuration Failure (Unable to Apply Requested Configuration - Service Not Provided)
13構成障害（要求された構成を適用することができません - サービスが提供されていません）
14 Image Data Error (Invalid Checksum)
14画像データエラー（無効なチェックサム）
15 Image Data Error (Invalid Data Length)
15画像データエラー（無効なデータ長）
16 Image Data Error (Other Error)
16画像データエラー（その他のエラー）
17 Image Data Error (Image Already Present)
17画像データエラー（画像既に存在しています）
18 Message Unexpected (Invalid in Current State)
予期しない18のメッセージ（現在の状態では無効）
19 Message Unexpected (Unrecognized Request)
19メッセージ予期しない（認識されないリクエスト）
20 Failure - Missing Mandatory Message Element
20失敗 - 必須のメッセージ要素がありません
21 Failure - Unrecognized Message Element
21故障 - 認識されないメッセージ要素
22 Data Transfer Error (No Information to Transfer)
22データ転送エラー（転送する情報がありません）
The Returned Message Element is sent by the WTP in the Change State Event Request message to communicate to the AC which message elements in the Configuration Status Response it was unable to apply locally. The Returned Message Element message element contains a result code indicating the reason that the configuration could not be applied, and encapsulates the failed message element.
返されたメッセージ要素は、ローカルに適用することができませんでした設定ステータス応答でACメッセージ要素と通信するために変更状態イベント要求メッセージにWTPによって送られます。返されたメッセージ要素のメッセージ要素は、コンフィギュレーションを適用することができなかった理由を示す結果コードが含まれ、失敗したメッセージ要素をカプセル化します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Length | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for Returned Message Element
タイプ：34返されたメッセージの要素について
Length: >= 6
長さ：> = 6
Reason: The reason the configuration in the offending message element could not be applied by the WTP. The following enumerated values are supported:
理由：問題のメッセージ要素内の構成はWTPによって適用することができなかった理由。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - Unknown Message Element
1 - 不明メッセージ要素
2 - Unsupported Message Element
2 - サポートされていないメッセージ要素
3 - Unknown Message Element Value
3 - 不明なメッセージ要素値
4 - Unsupported Message Element Value
4 - サポートされていないメッセージ要素の値
Length: The length of the Message Element field, which MUST NOT exceed 255 octets.
長さ：255個のオクテットを超えてはならないメッセージ要素フィールドの長さ。
Message Element: The Message Element field encapsulates the message element sent by the AC in the Configuration Status Response message that caused the error.
メッセージ要素：メッセージ要素のフィールドは、エラーの原因となった設定ステータス応答メッセージにACによって送信されたメッセージ要素をカプセル化します。
The Session ID message element value contains a randomly generated unsigned 128-bit integer.
セッションIDメッセージ要素値はランダムに生成された符号なしの128ビットの整数を含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 35 for Session ID
タイプ：35セッションIDについて
Length: 16
長さ：16
Session ID: A 128-bit unsigned integer used as a random session identifier
セッションID：ランダムセッション識別子として使用される128ビットの符号なし整数
The Statistics Timer message element value is used by the AC to inform the WTP of the frequency with which it expects to receive updated statistics.
統計タイマーメッセージ要素の値は、それが更新される統計を受け取ることを期待する頻度のWTPを知らせるためにACで使用されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 36 for Statistics Timer
タイプ：統計タイマーのための36
Length: 2
長さ：2
Statistics Timer: A 16-bit unsigned integer indicating the time, in seconds. The default value for this timer is specified in Section 4.7.14.
統計タイマー：時間を秒単位で示す16ビットの符号なし整数。このタイマーのデフォルト値は、セクション4.7.14に指定されています。
The Vendor Specific Payload message element is used to communicate vendor-specific information between the WTP and the AC. The Vendor Specific Payload message element MAY be present in any CAPWAP message. The exchange of vendor-specific data between the MUST NOT modify the behavior of the base CAPWAP protocol and state machine. The message element uses the following format:
ベンダー固有ペイロードメッセージ要素は、WTPとACとの間のベンダー固有情報を通信するために使用されます。ベンダー固有ペイロードメッセージ要素は、任意のCAPWAPメッセージの中に存在してもよいです。間のベンダー固有のデータの交換は、基本CAPWAPプロトコルステートマシンの動作を変更してはいけません。メッセージ要素は次の形式を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Payload
タイプ：ベンダー固有のペイロードのための37
Length: >= 7
長さ：> = 7
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC3232].
ベンダ識別子：IANAによって割り当てられた「SMIネットワーク管理プライベート企業コード」[RFC3232]を含む32ビット値。
Element ID: A 16-bit Element Identifier that is managed by the vendor.
エレメントID：ベンダによって管理されている16ビット要素識別子。
Data: Variable-length vendor-specific information, whose contents and format are proprietary and understood based on the Element ID field. This field MUST NOT exceed 2048 octets.
データ：可変長ベンダー固有情報、内容およびフォーマット独自であり、要素IDフィールドに基づいて理解されます。このフィールドは、2048オクテットを超えてはなりません。
The WTP Board Data message element is sent by the WTP to the AC and contains information about the hardware present.
WTPボードデータメッセージ要素は、ACにWTPによって送信され、ハードウェアに存在に関する情報が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for WTP Board Data
タイプ：WTPボード・データのための38
Length: >=14
長さ：> = 14
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes", identifying the WTP hardware manufacturer. The Vendor Identifier field MUST NOT be set to zero.
ベンダ識別子：IANAによって割り当てられた「SMIネットワーク管理プライベート企業コード」を含む32ビット値、WTPのハードウェアの製造元を識別する。ベンダー識別子フィールドはゼロに設定することはできません。
Board Data Sub-Element: The WTP Board Data message element contains multiple Board Data sub-elements, some of which are mandatory and some are optional, as described below. The Board Data Type values are not extensible by vendors, and are therefore not coupled along with the Vendor Identifier field. The Board Data sub-element has the following format:
ボードデータサブ要素：WTPボードデータメッセージ要素は必須であり、以下に説明するようにいくつかは、任意であるいくつかの複数ボードデータのサブ要素を含んでいます。ボードデータ型の値は、ベンダーによって拡張可能ではないので、ベンダ識別子フィールドと一緒に結合されていません。ボード・データサブ要素の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Type | Board Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Board Data Type: The Board Data Type field identifies the data being encoded. The CAPWAP protocol defines the following values, and each of these types identify whether their presence is mandatory or optional:
ボードデータタイプ：ボード・データ・タイプ・フィールドは、符号化されているデータを識別します。 CAPWAPプロトコルは、以下の値を定義し、これらのタイプの各々は、それらの存在が必須またはオプションであるか否かを識別する。
0 - WTP Model Number: The WTP Model Number MUST be included in the WTP Board Data message element.
0 - WTPモデル番号：WTPモデル番号は、WTP用ボード・データメッセージ要素に含まれなければなりません。
1 - WTP Serial Number: The WTP Serial Number MUST be included in the WTP Board Data message element.
1 - WTPシリアル番号：WTPシリアル番号はWTPボードデータメッセージ要素に含まれなければなりません。
2 - Board ID: A hardware identifier, which MAY be included in the WTP Board Data message element.
2 - ボードID：WTPボードデータメッセージ要素に含まれるかもしれハードウェア識別子、。
3 - Board Revision: A revision number of the board, which MAY be included in the WTP Board Data message element.
3 - ボードリビジョン：WTPボードデータメッセージ要素に含まれるかもしれボードのリビジョン番号。
4 - Base MAC Address: The WTP's Base MAC address, which MAY be assigned to the primary Ethernet interface.
4 - ベースMACアドレス：プライマリイーサネットインターフェイスに割り当てることができ、WTPのベースMACアドレス、。
Board Data Length: The length of the data in the Board Data Value field, whose length MUST NOT exceed 1024 octets.
ボード・データの長さ：長さ1024個のオクテットを超えてはならないボードデータ値フィールド内のデータの長さ。
Board Data Value: The data associated with the Board Data Type field for this Board Data sub-element.
ボード・データ値：このボードのデータサブ要素用ボード・データ・タイプ・フィールドに関連付けられたデータ。
The WTP Descriptor message element is used by a WTP to communicate its current hardware and software (firmware) configuration. The value contains the following fields:
WTPディスクリプタメッセージ要素は、現在のハードウェアおよびソフトウェア（ファームウェア）の設定を通信するためにWTPによって使用されます。値は次のフィールドがあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Descriptor
タイプ：WTP記述子のための39
Length: >= 33
長さ：> = 33
Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the Radio ID field) supported by the WTP.
最大ラジオ：WTPによってサポート（各無線ラジオIDフィールドによって識別される）無線の数を示す8ビットの値。
Radios in use: An 8-bit value representing the number of radios in use in the WTP.
使用中のラジオ：WTPで使用されている無線の数を示す8ビットの値。
Num Encrypt: The number of 3-byte Encryption sub-elements that follow this field. The value of the Num Encrypt field MUST be between one (1) and 255.
num個の暗号化：このフィールドに続く3バイトの暗号化サブ要素の数。民暗号化フィールドの値は1（1）と255の間でなければなりません。
Encryption Sub-Element: The WTP Descriptor message element MUST contain at least one Encryption sub-element. One sub-element is present for each binding supported by the WTP. The Encryption sub-element has the following format:
暗号化サブ要素：WTPディスクリプタメッセージ要素は、少なくとも1つの暗号化サブ要素を含まなければなりません。それぞれがWTPによってサポート結合のための一つのサブ要素が存在しています。暗号化サブ要素の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resvd| WBID | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resvd: The 3-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
Resvdは：3ビットのフィールドは、将来の使用のために予約されています。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
WBID: A 5-bit field that is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The WBIDs defined in this specification can be found in Section 4.3.
WBID：無線結合識別子である5ビットのフィールド。識別子は、無線に関連した無線パケットのタイプを示すであろう。この仕様で定義されたWBIDsは、4.3節に記載されています。
Encryption Capabilities: This 16-bit field is used by the WTP to communicate its capabilities to the AC. A WTP that does not have any encryption capabilities sets this field to zero (0). Refer to the specific wireless binding for further specification of the Encryption Capabilities field.
暗号化機能：この16ビットのフィールドは、ACにその機能を通信するためにWTPによって使用されます。任意の暗号化機能を持っていないWTPはゼロ（0）にこのフィールドを設定します。暗号化機能分野の更なる仕様のための特異的結合のワイヤレスを参照してください。
Descriptor Sub-Element: The WTP Descriptor message element contains multiple Descriptor sub-elements, some of which are mandatory and some are optional, as described below. The Descriptor sub-element has the following format:
ディスクリプタサブ要素：WTP記述メッセージ要素は必須であり、以下に説明するようにいくつかは、任意であるいくつかの複数の記述子のサブ要素を含んでいます。ディスクリプタサブ要素は、次の形式を有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Type | Descriptor Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes".
記述子ベンダー識別子：IANAによって割り当てられた「SMIネットワーク管理プライベートエンタープライズコード」を含む32ビットの値。
Descriptor Type: The Descriptor Type field identifies the data being encoded. The format of the data is vendor-specific encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol defines the following values, and each of these types identify whether their presence is mandatory or optional. The values listed below are used in conjunction with the Descriptor Vendor Identifier field, whose value MUST be set to zero (0). This field, combined with the Descriptor Vendor Identifier set to a non-zero (0) value, allows vendors to use a private namespace.
記述子タイプ：記述子タイプ・フィールドは、符号化されたデータを識別する。データのフォーマットは、UTF-8フォーマット[RFC3629]で符号化ベンダー固有です。 CAPWAPプロトコルは、以下の値を定義し、これらのタイプの各々は、それらの存在が必須またはオプションであるか否かを識別する。以下に示す値は、値ゼロ（0）に設定しなければならないディスクリプタのベンダ識別子フィールドと併せて使用されています。ディスクリプタのベンダ識別子と組み合わされ、このフィールドが非ゼロ（0）の値に設定され、ベンダーがプライベート名前空間を使用することを可能にします。
0 - Hardware Version: The WTP hardware version number MUST be present.
0 - ハードウェアバージョン：WTPハードウェアのバージョン番号が存在しなければなりません。
1 - Active Software Version: The WTP running software version number MUST be present.
1 - アクティブソフトウェアバージョン：WTP実行しているソフトウェアのバージョン番号が存在しなければなりません。
2 - Boot Version: The WTP boot loader version number MUST be present.
2 - ブートバージョン：WTPブートローダーのバージョン番号が存在しなければなりません。
3 - Other Software Version: The WTP non-running software (firmware) version number MAY be present. This type is used to communicate alternate software versions that are available on the WTP's non-volatile storage.
3 - その他のソフトウェアバージョン：WTP非実行中のソフトウェア（ファームウェア）のバージョン番号が存在してもよいです。このタイプは、WTPの不揮発性記憶装置で使用可能な代替のソフトウェアバージョンを通信するために使用されます。
Descriptor Length: Length of the vendor-specific encoding of the Descriptor Data field, whose length MUST NOT exceed 1024 octets.
記述子の長さ：長さ1024個のオクテットを超えてはならない記述データフィールドのベンダー固有のエンコーディングの長さ。
Descriptor Data: Vendor-specific data of WTP information encoded in the UTF-8 format [RFC3629].
記述子データ：UTF-8フォーマット[RFC3629]に符号化WTP情報のベンダー固有のデータ。
The WTP Fallback message element is sent by the AC to the WTP to enable or disable automatic CAPWAP fallback in the event that a WTP detects its preferred AC to which it is not currently connected.
WTPフォールバックメッセージ要素はWTPが、それが現在接続されていないために、その好ましいACを検出した場合に自動CAPWAPフォールバックを有効または無効にWTPにACによって送信されます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
Type: 40 for WTP Fallback
タイプ：WTPフォールバックのために40
Length: 1
長さ：1
Mode: The 8-bit value indicates the status of automatic CAPWAP fallback on the WTP. When enabled, if the WTP detects that its primary AC is available, and that the WTP is not connected to the primary AC, the WTP SHOULD automatically disconnect from its current AC and reconnect to its primary AC. If disabled, the WTP will only reconnect to its primary AC through manual intervention (e.g., through the Reset Request message). The default value for this field is specified in Section 4.8.9. The following enumerated values are supported:
モード：8ビット値はWTPに自動CAPWAPフォールバックの状態を示しています。 WTPは、その一次ACが利用可能であることを検出し、WTPがプライマリACに接続されていないことと、有効にすると、WTPは自動的に現在のACから切断し、その一次ACに再接続すべきです。無効にした場合、WTPは（例えば、リセット要求メッセージを介して）手動での介入を通じて、その主ACに再接続します。このフィールドのデフォルト値は、セクション4.8.9で指定されています。以下の列挙値がサポートされています。
0 - Reserved
0 - 予約
1 - Enabled
1 - 有効
2 - Disabled
2 - [無効]
The WTP Frame Tunnel Mode message element allows the WTP to communicate the tunneling modes of operation that it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy.
WTPフレームトンネルモードメッセージ要素は、WTPは、それがACにサポート操作のトンネリングモードを通信することを可能にします。すべてのタイプのサポートをアドバタイズWTPは、ACはそのローカルポリシーに基づいて、使用されるタイプを選択することができます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reservd|N|E|L|U|
+-+-+-+-+-+-+-+-+
Type: 41 for WTP Frame Tunnel Mode
タイプ：WTPフレームトンネルモードのための41
Length: 1
長さ：1
Reservd: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
Reservd：将来の使用のために予約されたビットのセット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
N: Native Frame Tunnel mode requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see for example Section 4.4)
N：ネイティブフレームトンネルモード結合無線によって定義されるように、ネイティブ無線フレームとしてすべてのユーザーペイロードをカプセル化するためにWTPとACを必要とする（例えば、4.4節を参照されたいです）
E: The 802.3 Frame Tunnel Mode requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.4). All user traffic is tunneled to the AC. This value MUST NOT be used when the WTP MAC Type is set to Split MAC.
E：802.3フレームトンネルモードは、ネイティブのIEEE 802.3フレーム（4.4節を参照）として、すべてのユーザペイロードをカプセル化するために、WTPとACが必要です。すべてのユーザトラフィックはACにトンネリングされます。 WTP MACタイプはスプリットMACに設定されている場合は、この値を使用してはいけません。
L: When Local Bridging is used, the WTP does not tunnel user traffic to the AC; all user traffic is locally bridged. This value MUST NOT be used when the WTP MAC Type is set to Split MAC.
L：ローカルブリッジを使用する場合、WTPはACへのトンネルのユーザトラフィックをしません。すべてのユーザトラフィックはローカルでブリッジされます。 WTP MACタイプはスプリットMACに設定されている場合は、この値を使用してはいけません。
R: A reserved bit for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
R：将来の使用のために予約ビット。このプロトコルに準拠するすべての実装は、実装によってサポートされるプロトコルのバージョンに予約されているいずれかのビットをゼロに設定しなければなりません。レシーバは、サポートするプロトコルのバージョン用に定義されていないすべてのビットを無視しなければなりません。
The WTP MAC-Type message element allows the WTP to communicate its mode of operation to the AC. A WTP that advertises support for both modes allows the AC to select the mode to use, based on local policy.
WTP MAC型のメッセージ要素は、WTPがACにその動作モードを通信することを可能にします。両方のモードのサポートをアドバタイズWTPは、ローカルポリシーに基づいて、ACを使用するモードを選択することを可能にします。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MAC Type |
+-+-+-+-+-+-+-+-+
Type: 44 for WTP MAC Type
タイプ：WTP MACタイプのために44
Length: 1
長さ：1
MAC Type: The MAC mode of operation supported by the WTP. The following enumerated values are supported:
MACタイプ：WTPでサポートされている操作のMACモード。以下の列挙値がサポートされています。
0 - Local MAC: Local MAC is the default mode that MUST be supported by all WTPs. When tunneling is enabled (see Section 4.6.43), the encapsulated frames MUST be in the 802.3 format (see Section 4.4.2), unless a wireless management or control frame which MAY be in its native format. Any CAPWAP binding needs to specify the format of management and control wireless frames.
0 - ローカルMAC：ローカルMACは、すべてのWTPsでサポートしなければならないデフォルトのモードです。トンネリングは、（セクション4.6.43を参照）が有効である場合、カプセル化されたフレームは、そのネイティブ形式であってもよく、無線管理または制御フレームがない限り、（セクション4.4.2を参照）802.3形式でなければなりません。どれCAPWAPは、経営の形式を指定し、無線フレームを制御するためのニーズを結合します。
1 - Split MAC: Split MAC support is optional, and allows the AC to receive and process native wireless frames.
1 - スプリットMAC：スプリットMACのサポートはオプションであり、ACはネイティブ無線フレームを受信して処理することを可能にします。
2 - Both: WTP is capable of supporting both Local MAC and Split MAC.
2 - 両方：WTPはローカルMACとスプリットMACの両方をサポートすることが可能です。
The WTP Name message element is a variable-length byte UTF-8 encoded string [RFC3629]. The string is not zero terminated.
WTP名メッセージ要素は、可変長バイトUTF-8でエンコードされた文字列[RFC3629]です。文字列が終了し、ゼロではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| WTP Name ...
+-+-+-+-+-+-+-+-+-
Type: 45 for WTP Name
タイプ：45 WTP名用
Length: >= 1
長さ：> = 1
WTP Name: A non-zero-terminated UTF-8 encoded string [RFC3629] containing the WTP name, whose maximum size MUST NOT exceed 512 bytes.
WTP名：非ゼロで終了するUTF-8でエンコードされた文字列[RFC3629]の最大サイズ512のバイトを超えてはならないWTP名を含みます。
The WTP Radio Statistics message element is sent by the WTP to the AC to communicate statistics on radio behavior and reasons why the WTP radio has been reset. These counters are never reset on the WTP, and will therefore roll over to zero when the maximum size has been reached.
WTPラジオ統計メッセージ要素は、無線動作とWTP無線がリセットされた理由に関する統計情報を通信するためにACにWTPによって送信されます。これらのカウンタは、WTPにリセットされることはありませんし、最大サイズに達したとき、そのためにゼロにロールオーバーされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Last Fail Type| Reset Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Failure Count | HW Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Failure Count | Unknown Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Update Count | Channel Change Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Band Change Count | Current Noise Floor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 47 for WTP Radio Statistics
タイプ：WTPラジオ統計47
Length: 20
長さ：20
Radio ID: The radio ID of the radio to which the statistics apply, whose value is between one (1) and 31.
無線ID：統計が適用される無線の無線ID、その値は1（1）と31の間です。
Last Failure Type: The last WTP failure. The following enumerated values are supported:
最後のエラーの種類：最後のWTPの失敗。以下の列挙値がサポートされています。
0 - Statistic Not Supported
0 - 統計がサポートされていません
1 - Software Failure
1 - ソフトウェア障害
2 - Hardware Failure
2 - ハードウェア障害
3 - Other Failure
3 - その他の障害
255 - Unknown (e.g., WTP doesn't keep track of info)
255 - 不明（例えば、WTPは、情報を追跡していません）
Reset Count: The number of times that the radio has been reset.
カウントをリセット：ラジオがリセットされた回数。
SW Failure Count: The number of times that the radio has failed due to software-related reasons.
SWの障害カウント：ラジオによるソフトウェア関連の理由に失敗した回数。
HW Failure Count: The number of times that the radio has failed due to hardware-related reasons.
HW障害カウント：ラジオは、ハードウェア関連の理由が原因で失敗した回数。
Other Failure Count: The number of times that the radio has failed due to known reasons, other than software or hardware failure.
その他の障害カウント：ラジオが原因ソフトウェアまたはハードウェア障害以外の公知の理由に失敗した回数。
Unknown Failure Count: The number of times that the radio has failed for unknown reasons.
不明なエラー数：ラジオが不明な理由で失敗した回数。
Config Update Count: The number of times that the radio configuration has been updated.
コンフィグアップデート数：無線構成が更新された回数を。
Channel Change Count: The number of times that the radio channel has been changed.
チャンネル変更数：無線チャネルが変更された回数を。
Band Change Count: The number of times that the radio has changed frequency bands.
帯域変更数：ラジオ周波数帯を変更した回数。
Current Noise Floor: A signed integer that indicates the noise floor of the radio receiver in units of dBm.
電流ノイズフロア：DBMの単位でラジオ受信機のノイズフロアを示す符号付き整数。
The WTP Reboot Statistics message element is sent by the WTP to the AC to communicate reasons why WTP reboots have occurred. These counters are never reset on the WTP, and will therefore roll over to zero when the maximum size has been reached.
WTPリブート統計メッセージ要素は、WTPが再起動が発生した理由を伝えるためにACにWTPによって送信されます。これらのカウンタは、WTPにリセットされることはありませんし、最大サイズに達したとき、そのためにゼロにロールオーバーされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reboot Count | AC Initiated Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Failure Count | SW Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Failure Count | Other Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Failure Count |Last Failure Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 48 for WTP Reboot Statistics
タイプ：WTPをリブート統計48
Length: 15
長さ：15
Reboot Count: The number of reboots that have occurred due to a WTP crash. A value of 65535 implies that this information is not available on the WTP.
再起動の数：WTPのクラッシュが原因で発生した再起動の回数。 65535の値は、この情報がWTPに利用できないことを意味します。
AC Initiated Count: The number of reboots that have occurred at the request of a CAPWAP protocol message, such as a change in configuration that required a reboot or an explicit CAPWAP protocol reset request. A value of 65535 implies that this information is not available on the WTP.
AC開始数：そのようなリブートまたは明示CAPWAPプロトコルリセット要求を必要な構成の変化としてCAPWAPプロトコルメッセージの要求で発生したリブートの回数。 65535の値は、この情報がWTPに利用できないことを意味します。
Link Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to link failure.
リンク障害カウント：ACでのCAPWAPプロトコル接続は、リンク障害が原因で失敗した回数。
SW Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to software-related reasons.
SWの障害カウント：ACでのCAPWAPプロトコル接続は、ソフトウェア関連の理由が原因で失敗した回数。
HW Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to hardware-related reasons.
HW失敗数：ACとCAPWAPプロトコル接続は、ハードウェア関連の理由に起因して失敗した回数。
Other Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to known reasons, other than AC initiated, link, SW or HW failure.
その他の障害カウント：ACでのCAPWAPプロトコル接続がAC以外の公知の理由、が原因で失敗した回数は、リンク、SWまたはHW故障、開始しました。
Unknown Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed for unknown reasons.
不明なエラー数：ACでのCAPWAPプロトコル接続が不明な理由で失敗した回数。
Last Failure Type: The failure type of the most recent WTP failure. The following enumerated values are supported:
最後のエラーの種類：最新のWTPの障害の障害のタイプ。以下の列挙値がサポートされています。
0 - Not Supported
0 - サポートされていません
1 - AC Initiated (see Section 9.2)
1 - AC開始（セクション9.2を参照）
2 - Link Failure
2 - リンク障害
3 - Software Failure
3 - ソフトウェア障害
4 - Hardware Failure
4 - ハードウェア障害
5 - Other Failure
5 - その他の障害
255 - Unknown (e.g., WTP doesn't keep track of info)
255 - 不明（例えば、WTPは、情報を追跡していません）
The WTP Static IP Address Information message element is used by an AC to configure or clear a previously configured static IP address on a WTP. IPv6 WTPs are expected to use dynamic addresses.
WTP静的IPアドレス情報メッセージ要素は、WTPに以前に設定した静的IPアドレスを設定またはクリアするためにACで使用されています。 IPv6のWTPsは、動的アドレスを使用することが期待されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static |
+-+-+-+-+-+-+-+-+
Type: 49 for WTP Static IP Address Information
タイプ：49 WTP静的IPアドレス情報について
Length: 13
長さ：13
IP Address: The IP address to assign to the WTP. This field is only valid if the static field is set to one.
IPアドレス：WTPに割り当てるIPアドレス。静的フィールドが1に設定されている場合、このフィールドにのみ有効です。
Netmask: The IP Netmask. This field is only valid if the static field is set to one.
ネットマスク：IPネットマスク。静的フィールドが1に設定されている場合、このフィールドにのみ有効です。
Gateway: The IP address of the gateway. This field is only valid if the static field is set to one.
ゲートウェイ：ゲートウェイのIPアドレス。静的フィールドが1に設定されている場合、このフィールドにのみ有効です。
Static: An 8-bit Boolean stating whether or not the WTP should use a static IP address. A value of zero disables the static IP address, while a value of one enables it.
静的：8ビットのブールWTPは、静的IPアドレスを使用する必要があるかどうかを述べます。一方の値がそれを可能にしながら、ゼロの値は、静的IPアドレスを無効にします。
This section contains the definition of the CAPWAP timers.
このセクションでは、CAPWAPタイマーの定義が含まれています。
The maximum time, in seconds, the AC will wait for the Change State Event Request from the WTP after having transmitted a successful Configuration Status Response message.
最大時間は、秒単位で、ACは、成功したコンフィギュレーションステータス応答メッセージを送信した後WTPからの変更状態イベント要求を待ちます。
Default: 25 seconds
デフォルト：25秒
The DataChannelKeepAlive timer is used by the WTP to determine the next opportunity when it must transmit the Data Channel Keep-Alive, in seconds.
DataChannelKeepAliveタイマーは、データチャネルがキープアライブ、秒単位で送信しなければならない次の機会を決定するためにWTPで使用されています。
Default: 30 seconds
デフォルト：30秒
The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep-Alive packet before the destination for the Data Channel Keep-Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds.
データチャネルは、キープアライブパケットの送信先が死んだと考えることができる前の最小時間は、秒単位で、WTPは、データチャネルは、キープアライブパケットを受信せずに待たなければなりません。このタイマーの値は240秒その2 * DataChannelKeepAlive秒未満と大きくないnoでなければなりません。
Default: 60
デフォルト：60
The number of seconds the AC will wait for the Data Channel Keep Alive, which is required by the CAPWAP state machine's Data Check state. The AC resets the state machine if this timer expires prior to transitioning to the next state.
秒数は、ACは、データチャネルは、キープアライブを待ち、CAPWAPステートマシンのデータチェック状態によって必要とされます。このタイマーは、次の状態に移行する前に期限切れになった場合にはACは、ステートマシンをリセットします。
Default: 30
デフォルト：30
The minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response message, before initiating a DTLS handshake.
最小時間は、秒単位で、WTPはDTLSハンドシェイクを開始する前に、ディスカバリー応答メッセージを受信した後、待機しなければならないことを。
Default: 5
デフォルト：5
The minimum time, in seconds, a WTP MUST wait for DTLS session deletion.
最小時間は、秒単位で、WTPはDTLSセッションの削除のために待たなければなりません。
Default: 5
デフォルト：5
The minimum time, in seconds, between sending Echo Request messages to the AC with which the WTP has joined.
最小時間は、秒単位で、ACにエコー要求メッセージを送信する間れるWTPが参加しました。
Default: 30
デフォルト：30
The default Idle Timeout is 300 seconds.
デフォルトのアイドルタイムアウトは300秒です。
The number of seconds the WTP will wait for its peer to transmit the Image Data Request.
秒数WTPは、画像データの要求を送信するピアを待ちます。
Default: 30
デフォルト：30
The maximum time allowed between sending Discovery Request messages, in seconds. This value MUST be no less than 2 seconds and no greater than 180 seconds.
秒で、ディスカバリ要求メッセージを送信する間の最大時間。この値には2秒未満、180秒以下でなければなりません。
Default: 20 seconds.
デフォルト：20秒。
The ReportInterval is used by the WTP to determine the interval the WTP uses between sending the Decryption Error message elements to inform the AC of decryption errors, in seconds.
ReportIntervalはWTPは秒単位で、復号エラーのACを知らせるために復号エラーメッセージ要素を送信の間に使用する間隔を決定するために、WTPにより使用されます。
The default Report Interval is 120 seconds.
デフォルトのレポート間隔は120秒です。
The minimum time, in seconds, in which a non-acknowledged CAPWAP packet will be retransmitted.
最小時間は、秒単位で、その非を認めCAPWAPパケットが再送されるでしょう。
Default: 3
デフォルト：3
For a WTP, this is the minimum time, in seconds, a WTP MUST wait before it MAY again send Discovery Request messages or attempt to establish a DTLS session. For an AC, this is the minimum time, in seconds, during which the AC SHOULD ignore all CAPWAP and DTLS packets received from the WTP that is in the Sulking state.
それが再びディスカバリ要求メッセージを送信したり、DTLSセッションを確立しようとするかもしれ前WTPの場合、これは最小時間で、秒単位で、WTPは待たなければなりません。 ACの場合、これはACがすべてのCAPWAPを無視すべきであり、DTLSパケットがSulking状態であるWTPから受信その間秒の最小時間は、です。
Default: 30 seconds
デフォルト：30秒
The StatisticsTimer is used by the WTP to determine the interval the WTP uses between the WTP Events Requests it transmits to the AC to communicate its statistics, in seconds.
StatisticsTimerはWTPが、それは秒単位で、その統計情報を通信するためにACに送信要求WTPイベント間の使用期間を決定するためにWTPによって使用されます。
Default: 120 seconds
デフォルト：120秒
The maximum time, in seconds, a WTP MUST wait without having received a DTLS Handshake message from an AC. This timer MUST be greater than 30 seconds.
最大時間は、秒単位で、WTPはACからDTLSハンドシェイクメッセージを受信せずに待機しなければなりません。このタイマーは30秒よりも大きくなければなりません。
Default: 60
デフォルト：60
The maximum time, in seconds, an AC will wait after the DTLS session has been established until it receives the Join Request from the WTP. This timer MUST be greater than 20 seconds.
DTLSセッションが確立された後、それはWTPからの参加要求を受信するまでの最大時間は、秒単位で、ACがお待ちしております。このタイマーは20秒よりも大きくなければなりません。
Default: 60
デフォルト：60
This section defines the CAPWAP protocol variables, which are used for various protocol functions. Some of these variables are configurable, while others are counters or have a fixed value. For non-counter-related variables, default values are specified. However, when a WTP's variable configuration is explicitly overridden by an AC, the WTP MUST save the new value.
このセクションでは、様々なプロトコル機能のために使用されるCAPWAPプロトコル変数を定義します。他の人がカウンターされているか、固定値を持っていながら、これらの変数のいくつかは、設定可能です。非カウンタ関連の変数の場合、デフォルト値が指定されています。 WTPの変数の設定が明示的にACによって上書きされている場合しかし、WTPは、新しい値を保存する必要があります。
The default Administrative State value is enabled (1).
デフォルトの管理状態の値が有効になっている（1）。
The number of Discovery Request messages transmitted by a WTP to a single AC. This is a monotonically increasing counter.
単一ACにWTPが送信したディスカバリ要求メッセージの数。これは単調に増加するカウンタです。
The number of failed DTLS session establishment attempts due to authentication failures.
認証の失敗に起因する障害が発生したDTLSセッション確立の試行回数。
The number of failed DTLS session establishment attempts.
失敗したDTLSセッション確立の試行回数。
The maximum number of Discovery Request messages that will be sent after a WTP boots.
WTPの起動後に送信されますディスカバリ要求メッセージの最大数。
Default: 10
デフォルト：10
The maximum number of failed DTLS session establishment attempts before the CAPWAP device enters a silent period.
CAPWAP装置の前に失敗したDTLSセッション確立の試みの最大数は、無音期間に入ります。
Default: 3
デフォルト：3
The maximum number of retransmissions for a given CAPWAP packet before the link layer considers the peer dead.
リンク層の前に与えられたCAPWAPパケットの再送信の最大数は、ピアが死んだと考えています。
Default: 5
デフォルト：5
The number of retransmissions for a given CAPWAP packet. This is a monotonically increasing counter.
与えられたCAPWAPパケットの再送回数。これは単調に増加するカウンタです。
The default WTP Fallback value is enabled (1).
デフォルトWTPフォールバックの値が有効になっている（1）。
In addition to the values defined in Section 4.8, the following values SHOULD be saved on the WTP in non-volatile memory. CAPWAP wireless bindings MAY define additional values that SHOULD be stored on the WTP.
セクション4.8で定義された値に加えて、以下の値が不揮発性メモリにWTPに保存されるべきです。 CAPWAP無線バインディングはWTPに格納されるべき追加の値を定義することができます。
The number of times the WTP has rebooted administratively, defined in Section 4.6.47.
回WTPの数は、行政再起動セクション4.6.47で定義されています。
For WTPs that support multiple Frame Encapsulation Types, it is useful to save the value configured by the AC. The Frame Encapsulation Type is defined in Section 4.6.43.
複数のフレームのカプセル化タイプをサポートWTPsの場合は、ACによって設定された値を保存するのに便利です。フレームカプセル化タイプは、セクション4.6.43で定義されています。
The reason why the WTP last rebooted, defined in Section 4.6.47.
セクション4.6.47で定義されたWTPが最後の再起動理由、。
For WTPs that support multiple MAC-Types, it is useful to save the value configured by the AC. The MAC-Type is defined in Section 4.6.44.
複数のMAC-タイプをサポートWTPsの場合は、ACによって設定された値を保存するのに便利です。 MAC-Typeは、セクション4.6.44で定義されています。
The preferred ACs, with the index, defined in Section 4.6.5.
好適ACS、セクション4.6.5で定義されたインデックス、と。
The number of times the WTP has rebooted, defined in Section 4.6.47.
回WTPの数は、セクション4.6.47で定義され、再起動しました。
The static IP address assigned to the WTP, as configured by the WTP Static IP address Information message element (see Section 4.6.48).
WTP静的IPアドレス情報メッセージ要素によって構成されるように、WTPに割り当てられた静的IPアドレス（セクション4.6.48を参照のこと）。
The number of times the link to the AC has failed, see Section 4.6.47.
ACへのリンクが失敗した回数は、セクション4.6.47を参照してください。
The WTP Location, defined in Section 4.6.30.
セクション4.6.30で定義されたWTP場所、。
The WTP Name, defined in Section 4.6.45.
WTP名は、セクション4.6.45で定義されています。
The Discovery messages are used by a WTP to determine which ACs are available to provide service, and the capabilities and load of the ACs.
ディスカバリーメッセージは、サービスを提供するために使用可能なACのかを決定するためにWTPで使用される、とACSの機能とロードされています。
The Discovery Request message is used by the WTP to automatically discover potential ACs available in the network. The Discovery Request message provides ACs with the primary capabilities of the
ディスカバリーRequestメッセージは自動的にネットワークで利用可能な潜在的なACSを発見するためにWTPで使用されています。ディスカバリー要求メッセージは、の主な機能とACSを提供します
WTP. A WTP must exchange this information to ensure subsequent exchanges with the ACs are consistent with the WTP's functional characteristics.
WTP。 WTPは、ACSは、WTPの機能的特徴と一致していると、その後の交換を確実にするためにこの情報を交換しなければなりません。
Discovery Request messages MUST be sent by a WTP in the Discover state after waiting for a random delay less than MaxDiscoveryInterval, after a WTP first comes up or is (re)initialized. A WTP MUST send no more than the maximum of MaxDiscoveries Discovery Request messages, waiting for a random delay less than MaxDiscoveryInterval between each successive message.
WTPは、最初に起動するか、（再）初期化された後、ディスカバリ要求メッセージは、MaxDiscoveryInterval未満のランダムな遅延を待って発見状態でWTPで送らなければなりません。 WTPは、連続する各メッセージの間MaxDiscoveryInterval未満のランダムな遅延を待って、MaxDiscoveriesディスカバリ要求メッセージの最大値以下で送ってはなりません。
This is to prevent an explosion of WTP Discovery Request messages. An example of this occurring is when many WTPs are powered on at the same time.
これは、WTPディスカバリ要求メッセージの爆発を防ぐためです。多くのWTPsが同時に電源がオンしているときに、この発生の例があります。
If a Discovery Response message is not received after sending the maximum number of Discovery Request messages, the WTP enters the Sulking state and MUST wait for an interval equal to SilentInterval before sending further Discovery Request messages.
ディスカバリ応答メッセージがディスカバリ要求メッセージの最大数を送信した後に受信されない場合、WTPはSulking状態に入り、さらにディスカバリ要求メッセージを送信する前SilentIntervalに等しい間隔を待たなければなりません。
Upon receiving a Discovery Request message, the AC will respond with a Discovery Response message sent to the address in the source address of the received Discovery Request message. Once a Discovery Response has been received, if the WTP decides to establish a session with the responding AC, it SHOULD perform an MTU discovery, using the process described in Section 3.5.
ディスカバリ要求メッセージを受信すると、ACは、受信したディスカバリ要求メッセージの送信元アドレスのアドレスに送信された発見応答メッセージで応答します。ディスカバリー応答が受信されるとWTPが応答ACとのセッションを確立することを決定した場合、それはセクション3.5で説明したプロセスを使用して、MTUディスカバリを実行する必要があります。
It is possible for the AC to receive a clear text Discovery Request message while a DTLS session is already active with the WTP. This is most likely the case if the WTP has rebooted, perhaps due to a software or power failure, but could also be caused by a DoS attack. In such cases, any WTP state, including the state machine instance, MUST NOT be cleared until another DTLS session has been successfully established, communicated via the DTLSSessionEstablished DTLS notification (see Section 2.3.2.2).
DTLSセッションがすでにWTPとアクティブである間にACがクリアテキスト発見要求メッセージを受信することが可能です。 WTPは、ソフトウェアまたは電源障害に起因する、おそらく、再起動しただけでなく、DoS攻撃によって引き起こされることができれば、これが最も可能性の高いケースです。別のDTLSセッションが正常に確立されるまで、このような場合には、ステートマシンのインスタンスを含む任意のWTP状態が、DTLSSessionEstablished DTLS通知を介して通信、クリアされてはいけません（セクション2.3.2.2を参照）。
The binding specific WTP Radio Information message element (see Section 2.1) is included in the Discovery Request message to advertise WTP support for one or more CAPWAP bindings.
特異的結合WTPラジオ情報メッセージ要素は、（セクション2.1を参照）は、1つまたは複数のCAPWAPバインディングのWTPサポートを広告する発見要求メッセージに含まれています。
The Discovery Request message is sent by the WTP when in the Discovery state. The AC does not transmit this message.
ディスカバリーRequestメッセージは時に発見状態でWTPによって送られます。 ACは、このメッセージを送信しません。
The following message elements MUST be included in the Discovery Request message:
次のメッセージ要素は、ディスカバリ要求メッセージに含まれなければなりません：
o Discovery Type, see Section 4.6.21
ディスカバリーO型、セクション4.6.21を参照してください
o WTP Board Data, see Section 4.6.40
WTPボード・データO、セクション4.6.40を参照してください
o WTP Descriptor, see Section 4.6.41
O WTP記述子は、セクション4.6.41を参照してください
o WTP Frame Tunnel Mode, see Section 4.6.43
O WTPフレームトンネルモード、セクション4.6.43を参照してください
o WTP MAC Type, see Section 4.6.44
WTP MACタイプO、セクション4.6.44を参照してください
o WTP Radio Information message element(s) that the WTP supports; These are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1).
WTPがサポートO WTPラジオ情報メッセージ要素（単数または複数）;これらは、個々のリンク層プロトコルバインディングCAPWAP（セクション2.1を参照）によって定義されます。
The following message elements MAY be included in the Discovery Request message:
次のメッセージ要素は、ディスカバリ要求メッセージに含まれることがあります。
o MTU Discovery Padding, see Section 4.6.32
O MTUディスカバリーパディングは、セクション4.6.32を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Discovery Response message provides a mechanism for an AC to advertise its services to requesting WTPs.
ディスカバリー応答メッセージは、ACがWTPsを要求し、そのサービスを宣伝するためのメカニズムを提供します。
When a WTP receives a Discovery Response message, it MUST wait for an interval not less than DiscoveryInterval for receipt of additional Discovery Response messages. After the DiscoveryInterval elapses, the WTP enters the DTLS-Init state and selects one of the ACs that sent a Discovery Response message and send a DTLS Handshake to that AC.
WTPが発見応答メッセージを受信すると、追加のディスカバリ応答メッセージの受信のためのDiscoveryInterval以上の間隔を待たねばなりません。経過DiscoveryInterval後、WTPはDTLS-INIT状態に入り、ディスカバリ応答メッセージを送信し、そのACにDTLSハンドシェイクを送信するのACのいずれかを選択します。
One or more binding-specific WTP Radio Information message elements (see Section 2.1) are included in the Discovery Request message to advertise AC support for the CAPWAP bindings. The AC MAY include only the bindings it shares in common with the WTP, known through the WTP Radio Information message elements received in the Discovery Request message, or it MAY include all of the bindings supported. The WTP MAY use the supported bindings in its AC decision process. Note that if the WTP joins an AC that does not support a specific CAPWAP binding, service for that binding MUST NOT be provided by the WTP.
一つ以上の結合特異WTPラジオ情報メッセージ要素は（セクション2.1を参照）CAPWAPバインディングのACサポートを広告する発見要求メッセージに含まれています。 ACは、ディスカバリ要求メッセージで受信したWTP無線情報メッセージ要素を介して公知のWTP、共通に共有するだけのバインディングを含んでいてもよく、またはそれはサポートされているバインディングの全てを含み得ます。 WTPはそのACの決定プロセスでサポートされているバインディングを使用するかもしれません。 WTPはACに加入している場合、その結合のための具体的なCAPWAPバインディング、サービスはWTPによって提供されてはなりませんサポートしていないということに注意してください。
The Discovery Response message is sent by the AC when in the Idle state. The WTP does not transmit this message.
ディスカバリー応答メッセージは、アイドル時の状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message elements MUST be included in the Discovery Response Message: o AC Descriptor, see Section 4.6.1
次のメッセージ要素が発見応答メッセージに含まれなければならない：AC記述子O、セクション4.6.1を参照してください
o AC Name, see Section 4.6.4
ACの名前O、セクション4.6.4を参照してください
o WTP Radio Information message element(s) that the AC supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
ACがサポートするWTPラジオ情報メッセージ要素（複数可）O;これらは、プロトコルバインディング個々のリンク層CAPWAP（詳細はセクション2.1を参照）によって定義されます。
o One of the following message elements MUST be included in the Discovery Response Message:
O次のメッセージ要素の一つが発見応答メッセージに含まれなければなりません。
* CAPWAP Control IPv4 Address, see Section 4.6.9
* CAPWAPコントロールIPv4アドレス、セクション4.6.9を参照してください
* CAPWAP Control IPv6 Address, see Section 4.6.10
* CAPWAPコントロールIPv6アドレス、セクション4.6.10を参照してください
The following message elements MAY be included in the Discovery Response message:
次のメッセージ要素が発見応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Primary Discovery Request message is sent by the WTP to:
プライマリディスカバリ要求メッセージは、WTPでに送信されます。
o determine whether its preferred (or primary) AC is available, or
Oその好ましい（または一次）ACが利用可能であるかどうかを決定する、または
o perform a Path MTU Discovery (see Section 3.5).
OパスMTUディスカバリを（3.5節を参照）を行います。
A Primary Discovery Request message is sent by a WTP when it has a primary AC configured, and is connected to another AC. This generally occurs as a result of a failover, and is used by the WTP as a means to discover when its primary AC becomes available. Since the WTP only has a single instance of the CAPWAP state machine, the Primary Discovery Request is sent by the WTP when in the Run state. The AC does not transmit this message.
プライマリディスカバリ要求メッセージは、それが構成された一次ACを有する場合WTPにより送信され、別のACに接続されています。これは、一般に、フェイルオーバーの結果として発生し、その一次ACが使用可能になったときに発見するための手段としてWTPで使用されます。 WTPのみCAPWAP・ステート・マシンの単一のインスタンスを持っているので、プライマリディスカバリ要求をしたときに実行状態にWTPによって送られます。 ACは、このメッセージを送信しません。
The frequency of the Primary Discovery Request messages should be no more often than the sending of the Echo Request message.
プライマリディスカバリ要求メッセージの頻度は、エコー要求メッセージの送信よりも、何より頻繁にあってはなりません。
Upon receipt of a Primary Discovery Request message, the AC responds with a Primary Discovery Response message sent to the address in the source address of the received Primary Discovery Request message.
プライマリディスカバリ要求メッセージを受信すると、ACは、受信されたプライマリディスカバリ要求メッセージの送信元アドレスのアドレスに送信されたプライマリディスカバリ応答メッセージで応答します。
The following message elements MUST be included in the Primary Discovery Request message.
次のメッセージ要素は、プライマリディスカバリ要求メッセージに含まれなければなりません。
o Discovery Type, see Section 4.6.21
ディスカバリーO型、セクション4.6.21を参照してください
o WTP Board Data, see Section 4.6.40
WTPボード・データO、セクション4.6.40を参照してください
o WTP Descriptor, see Section 4.6.41
O WTP記述子は、セクション4.6.41を参照してください
o WTP Frame Tunnel Mode, see Section 4.6.43
O WTPフレームトンネルモード、セクション4.6.43を参照してください
o WTP MAC Type, see Section 4.6.44
WTP MACタイプO、セクション4.6.44を参照してください
o WTP Radio Information message element(s) that the WTP supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
WTPがサポートO WTPラジオ情報メッセージ要素（単数または複数）;これらは、プロトコルバインディング個々のリンク層CAPWAP（詳細はセクション2.1を参照）によって定義されます。
The following message elements MAY be included in the Primary Discovery Request message:
次のメッセージ要素は、プライマリディスカバリ要求メッセージに含まれることがあります。
o MTU Discovery Padding, see Section 4.6.32
O MTUディスカバリーパディングは、セクション4.6.32を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Primary Discovery Response message enables an AC to advertise its availability and services to requesting WTPs that are configured to have the AC as its primary AC.
プライマリディスカバリ応答メッセージは、その主要なACとACを有するように構成されているWTPsを要求し、その可用性やサービスを宣伝するためにACを可能にします。
The Primary Discovery Response message is sent by an AC after receiving a Primary Discovery Request message.
プライマリディスカバリ応答メッセージは、プライマリディスカバリ要求メッセージを受信した後、ACによって送信されます。
When a WTP receives a Primary Discovery Response message, it may establish a CAPWAP protocol connection to its primary AC, based on the configuration of the WTP Fallback Status message element on the WTP.
WTPは、プライマリディスカバリ応答メッセージを受信すると、WTPにWTPフォールバックステータスメッセージ要素の構成に基づいて、その主要なACにCAPWAPプロトコル接続を確立することができます。
The Primary Discovery Response message is sent by the AC when in the Idle state. The WTP does not transmit this message.
プライマリディスカバリ応答メッセージは、アイドル時の状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message elements MUST be included in the Primary Discovery Response message.
次のメッセージ要素は、プライマリディスカバリ応答メッセージに含まれなければなりません。
o AC Descriptor, see Section 4.6.1
AC記述子O、4.6.1項を参照してください
o AC Name, see Section 4.6.4
ACの名前O、セクション4.6.4を参照してください
o WTP Radio Information message element(s) that the AC supports; These are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
ACがサポートするWTPラジオ情報メッセージ要素（複数可）O;これらは、プロトコルバインディング個々のリンク層CAPWAP（詳細はセクション2.1を参照）によって定義されます。
One of the following message elements MUST be included in the Discovery Response Message:
次のメッセージ要素の一つが発見応答メッセージに含まれなければなりません。
o CAPWAP Control IPv4 Address, see Section 4.6.9
CAPWAPコントロールIPv4アドレスO、セクション4.6.9を参照してください
o CAPWAP Control IPv6 Address, see Section 4.6.10
CAPWAPコントロールIPv6アドレスO、セクション4.6.10を参照してください
The following message elements MAY be included in the Primary Discovery Response message:
次のメッセージ要素は、プライマリディスカバリ応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Join Request message is used by a WTP to request service from an AC after a DTLS connection is established to that AC. The Join Response message is used by the AC to indicate that it will or will not provide service.
参加要求メッセージはDTLS接続がそのACに確立された後にACからのサービスを要求するためにWTPによって使用されます。参加応答メッセージは、それがやサービスを提供することはありませんということを示すために、ACで使用されています。
The Join Request message is used by a WTP to request service through the AC. If the WTP is performing the optional AC Discovery process (see Section 3.3), the join process occurs after the WTP has received one or more Discovery Response messages. During the Discovery process, an AC MAY return more than one CAPWAP Control IPv4 Address or CAPWAP Control IPv6 Address message elements. When more than one such message element is returned, the WTP SHOULD perform "load balancing" by choosing the interface that is servicing the least number of WTPs (known through the WTP Count field of the message element). Note, however, that other load balancing algorithms are also permitted. Once the WTP has determined its preferred AC, and its associated interface, to which to connect, it establishes the DTLS session, and transmits the Join Request over the secured control channel. When an AC receives a Join Request message it responds with a Join Response message.
参加要求メッセージはACを通じてサービスを要求するためにWTPで使用されています。 WTPは、オプションのAC検出プロセスを実行している場合（3.3節を参照）WTPは、1つ以上のディスカバリ応答メッセージを受信した後、参加プロセスが起こります。ディスカバリプロセス中に、ACは、複数のCAPWAP制御IPv4アドレスまたはCAPWAPコントロールのIPv6アドレスメッセージ要素を返すことができます。以上のようなメッセージ要素が返されたとき、WTPは、（メッセージ要素のフィールドカウントWTPを通して知られている）WTPsの最小数をサービスしているインターフェイスを選択して「負荷分散」を実行する必要があります。他の負荷分散アルゴリズムも許可されていること、しかし、注意してください。 WTPは、どの接続するために、その好ましいAC、およびそれに関連するインタフェースを決定すると、それはDTLSセッションを確立し、保護された制御チャネルを介して参加要求を送信します。 ACは、参加要求メッセージを受信した場合には、参加応答メッセージで応答します。
Upon completion of the DTLS handshake and receipt of the DTLSEstablished notification, the WTP sends the Join Request message to the AC. When the AC is notified of the DTLS session establishment, it does not clear the WaitDTLS timer until it has received the Join Request message, at which time it sends a Join Response message to the WTP, indicating success or failure.
DTLSEstablished通知のDTLSハンドシェーク及び受信が完了すると、WTPはACへ参加要求メッセージを送信します。 ACは、DTLSセッションの確立が通知されると、それが成功または失敗を示す、WTPに参加応答メッセージを送信し、その時点で参加要求メッセージを受信するまで、それはWaitDTLS・タイマをクリアしません。
One or more WTP Radio Information message elements (see Section 2.1) are included in the Join Request to request service for the CAPWAP bindings by the AC. Including a binding that is unsupported by the AC will result in a failed Join Response.
一つ以上のWTPラジオ情報メッセージ・エレメント（セクション2.1を参照）ACによってCAPWAPバインディングのサービスを要求する参加要求に含まれています。それを結合はACによってサポートされていない含めると参加失敗応答になります。
If the AC rejects the Join Request, it sends a Join Response message with a failure indication and initiates an abort of the DTLS session via the DTLSAbort command.
ACは、参加要求を拒否した場合、それは失敗の表示に加入応答メッセージを送信し、DTLSAbortコマンドを経由してDTLSセッションの中断を開始します。
If an invalid (i.e., malformed) Join Request message is received, the message MUST be silently discarded by the AC. No response is sent to the WTP. The AC SHOULD log this event.
無効な参加（即ち、不正な形式の）要求メッセージを受信した場合、メッセージは静かにACによって廃棄されなければなりません。いいえレスポンスはWTPに送信されません。 ACは、このイベントをログに記録すべきです。
The Join Request is sent by the WTP when in the Join State. The AC does not transmit this message.
参加要求をするときに参加州のWTPによって送信されます。 ACは、このメッセージを送信しません。
The following message elements MUST be included in the Join Request message.
次のメッセージ要素は、参加要求メッセージに含まれなければなりません。
o Location Data, see Section 4.6.30
位置データO、セクション4.6.30を参照してください
o WTP Board Data, see Section 4.6.40
WTPボード・データO、セクション4.6.40を参照してください
o WTP Descriptor, see Section 4.6.41
O WTP記述子は、セクション4.6.41を参照してください
o WTP Name, see Section 4.6.45
WTP名前O、セクション4.6.45を参照してください
o Session ID, see Section 4.6.37
セッションID O、セクション4.6.37を参照してください
o WTP Frame Tunnel Mode, see Section 4.6.43
O WTPフレームトンネルモード、セクション4.6.43を参照してください
o WTP MAC Type, see Section 4.6.44
WTP MACタイプO、セクション4.6.44を参照してください
o WTP Radio Information message element(s) that the WTP supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
WTPがサポートO WTPラジオ情報メッセージ要素（単数または複数）;これらは、プロトコルバインディング個々のリンク層CAPWAP（詳細はセクション2.1を参照）によって定義されます。
o ECN Support, see Section 4.6.25
ECNサポートO、セクション4.6.25を参照してください
At least one of the following message element MUST be included in the Join Request message.
次のメッセージ要素の少なくとも一方は、参加要求メッセージに含まれなければなりません。
o CAPWAP Local IPv4 Address, see Section 4.6.11
CAPWAPローカルIPv4アドレスO、セクション4.6.11を参照してください
o CAPWAP Local IPv6 Address, see Section 4.6.12
CAPWAPローカルIPv6アドレスO、セクション4.6.12を参照してください
The following message element MAY be included in the Join Request message.
次のメッセージ要素は、参加要求メッセージに含まれるかもしれません。
o CAPWAP Transport Protocol, see Section 4.6.14
CAPWAPトランスポートプロトコルO、セクション4.6.14を参照してください
o Maximum Message Length, see Section 4.6.31
O最大メッセージ長は、セクション4.6.31を参照してください
o WTP Reboot Statistics, see Section 4.6.47
O WTPをリブート統計は、セクション4.6.47を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Join Response message is sent by the AC to indicate to a WTP that it is capable and willing to provide service to the WTP.
参加応答メッセージは、それが可能とWTPにサービスを提供していく所存ですWTPに示すためにACによって送信されます。
The WTP, receiving a Join Response message, checks for success or failure. If the message indicates success, the WTP clears the WaitDTLS timer for the session and proceeds to the Configure state.
加入応答メッセージを受信したWTPは、成功か失敗かをチェックします。メッセージは成功を示している場合、WTPは、設定状態へのセッションを進めるためのWaitDTLSタイマをクリア。
If the WaitDTLS Timer expires prior to reception of the Join Response message, the WTP MUST terminate the handshake, deallocate session state and initiate the DTLSAbort command.
WaitDTLSタイマが加入応答メッセージを受信する前に満了した場合、WTPは、ハンドシェイクを終了割当て解除セッション状態とDTLSAbortコマンドを開始しなければなりません。
If an invalid (malformed) Join Response message is received, the WTP SHOULD log an informative message detailing the error. This error MUST be treated in the same manner as AC non-responsiveness. The WaitDTLS timer will eventually expire, and the WTP MAY (if it is so configured) attempt to join a new AC.
無効（不正な）応答メッセージに参加を受信した場合、WTPは、エラーの詳細情報メッセージをログに記録すべきです。このエラーは、AC非応答と同様に処理されなければなりません。 （それがそのように構成されている場合）WaitDTLSタイマーは、最終的に新しいACに参加しようとすると有効期限が切れると、WTP MAYます。
If one of the WTP Radio Information message elements (see Section 2.1) in the Join Request message requested support for a CAPWAP binding that the AC does not support, the AC sets the Result Code message element to "Binding Not Supported".
WTPラジオ情報メッセージ要素の1つが（2.1節を参照）に参加要求メッセージはACがサポートされていないことを結合CAPWAPのための支援を要請して、ACは、「サポートされていない結合」する結果コードメッセージ要素を設定します。
The AC includes the Image Identifier message element to indicate the software version it expects the WTP to run. This information is used to determine whether the WTP MUST change its currently running firmware image or download a new version (see Section 9.1.1).
ACは、WTPを実行する予定のソフトウェアのバージョンを示すために、画像識別メッセージ要素を含んでいます。この情報は、WTPが現在実行中のファームウェアイメージを変更したり、新しいバージョンをダウンロードする必要があるかどうかを判断するために使用されます（9.1.1項を参照してください）。
The Join Response message is sent by the AC when in the Join State. The WTP does not transmit this message.
参加応答メッセージは時に参加州のACによって送信されます。 WTPは、このメッセージを送信しません。
The following message elements MUST be included in the Join Response message.
次のメッセージ要素が加入応答メッセージに含まれなければなりません。
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
o AC Descriptor, see Section 4.6.1
AC記述子O、4.6.1項を参照してください
o AC Name, see Section 4.6.4
ACの名前O、セクション4.6.4を参照してください
o WTP Radio Information message element(s) that the AC supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1).
ACがサポートするWTPラジオ情報メッセージ要素（複数可）O;これらは、個々のリンク層プロトコルバインディングCAPWAP（セクション2.1を参照）によって定義されます。
o ECN Support, see Section 4.6.25
ECNサポートO、セクション4.6.25を参照してください
One of the following message elements MUST be included in the Join Response Message:
次のメッセージ要素の一つは、参加応答メッセージに含まれなければなりません。
o CAPWAP Control IPv4 Address, see Section 4.6.9
CAPWAPコントロールIPv4アドレスO、セクション4.6.9を参照してください
o CAPWAP Control IPv6 Address, see Section 4.6.10
CAPWAPコントロールIPv6アドレスO、セクション4.6.10を参照してください
One of the following message elements MUST be included in the Join Response Message:
次のメッセージ要素の一つは、参加応答メッセージに含まれなければなりません。
o CAPWAP Local IPv4 Address, see Section 4.6.11
CAPWAPローカルIPv4アドレスO、セクション4.6.11を参照してください
o CAPWAP Local IPv6 Address, see Section 4.6.12
CAPWAPローカルIPv6アドレスO、セクション4.6.12を参照してください
The following message elements MAY be included in the Join Response message.
次のメッセージ要素は、参加応答メッセージに含まれるかもしれません。
o AC IPv4 List, see Section 4.6.2
AC IPv4の一覧O、4.6.2項を参照してください
o AC IPv6 List, see Section 4.6.3
AC IPv6の一覧O、4.6.3項を参照してください
o CAPWAP Transport Protocol, see Section 4.6.14
CAPWAPトランスポートプロトコルO、セクション4.6.14を参照してください
o Image Identifier, see Section 4.6.27
Oイメージ識別子は、セクション4.6.27を参照してください
o Maximum Message Length, see Section 4.6.31
O最大メッセージ長は、セクション4.6.31を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Control Channel Management messages are used by the WTP and AC to maintain a control communication channel. CAPWAP Control messages, such as the WTP Event Request message sent from the WTP to the AC indicate to the AC that the WTP is operational. When such control messages are not being sent, the Echo Request and Echo Response messages are used to maintain the control communication channel.
制御チャネル管理メッセージは、制御通信チャネルを維持するために、WTPとACで使用されています。こうしたACへのWTPから送られたWTPイベント要求メッセージとしてCAPWAP制御メッセージは、WTPが動作しているACに示します。このような制御メッセージが送信されていない場合、エコー要求およびエコー応答メッセージは、制御通信チャネルを維持するために使用されます。
The Echo Request message is a keep-alive mechanism for CAPWAP control messages.
Echo Requestメッセージは、CAPWAP制御メッセージ用のキープアライブメカニズムです。
Echo Request messages are sent periodically by a WTP in the Image Data or Run state (see Section 2.3) to determine the state of the control connection between the WTP and the AC. The Echo Request message is sent by the WTP when the EchoInterval timer expires.
エコー要求メッセージは、WTPとAC間の制御接続の状態を判断する（2.3節を参照）は、画像データやファイル名を指定して実行状態にWTPによって定期的に送信されます。 EchoIntervalタイマーが満了したときにエコー要求メッセージは、WTPによって送られます。
The Echo Request message is sent by the WTP when in the Run state. The AC does not transmit this message.
Echo Requestメッセージは、ときRun状態でWTPによって送られます。 ACは、このメッセージを送信しません。
The following message elements MAY be included in the Echo Request message:
次のメッセージ要素は、Echo Requestメッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
When an AC receives an Echo Request message it responds with an Echo Response message.
ACは、Echo Requestメッセージを受信した場合には、エコー応答メッセージで応答します。
The Echo Response message acknowledges the Echo Request message.
エコー応答メッセージは、Echo Requestメッセージを承認します。
An Echo Response message is sent by an AC after receiving an Echo Request message. After transmitting the Echo Response message, the AC SHOULD reset its EchoInterval timer (see Section 4.7.7). If another Echo Request message or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be no longer reachable.
エコー応答メッセージは、Echo Requestメッセージを受信した後、ACによって送信されます。エコー応答メッセージを送信した後、ACはそのEchoIntervalタイマー（セクション4.7.7を参照）をリセットする必要があります。タイマーが満了したときに別のエコー要求メッセージまたは他の制御メッセージがACによって受信されない場合は、ACは、WTPはもはや到達可能でないために検討すべきです。
The Echo Response message is sent by the AC when in the Run state. The WTP does not transmit this message.
エコー応答メッセージはときRun状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message elements MAY be included in the Echo Response message:
次のメッセージ要素は、エコー応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
When a WTP receives an Echo Response message it initializes the EchoInterval to the configured value.
WTPは、エコー応答メッセージを受信した場合には、設定された値にEchoIntervalを初期化します。
WTP Configuration messages are used to exchange configuration information between the AC and the WTP.
WTPの設定メッセージは、ACとWTPの間で設定情報を交換するために使用されています。
The CAPWAP protocol provides flexibility in how WTP configuration is managed. A WTP can behave in one of two ways, which is implementation specific:
CAPWAPプロトコルは、WTPの設定の管理方法に柔軟性を提供します。 WTPは実装特異的である、2つの方法のいずれかで振る舞うことができます。
1. The WTP retains no configuration and accepts the configuration provided by the AC.
1. WTPにはコンフィギュレーションを保持しておらず、ACによって提供される構成を受け入れます。
2. The WTP saves the configuration of parameters provided by the AC that are non-default values into local non-volatile memory, and are enforced during the WTP's power up initialization phase.
2. WTPは、ローカル不揮発性メモリへの非デフォルト値であり、WTPのパワーアップ初期化フェーズ中に適用されるACによって提供されたパラメータの設定を保存します。
If the WTP opts to save configuration locally, the CAPWAP protocol state machine defines the Configure state, which allows for configuration exchange. In the Configure state, the WTP sends its current configuration overrides to the AC via the Configuration Status Request message. A configuration override is a non-default parameter. As an example, in the CAPWAP protocol, the default antenna configuration is internal omni antenna. A WTP that either has no internal antennas, or has been explicitly configured by the AC to use external antennas, sends its antenna configuration during the configure phase, allowing the AC to become aware of the WTP's current configuration.
WTPがローカル設定を保存することを選択した場合は、CAPWAPプロトコルステートマシンは、構成交換を可能にする設定状態を定義します。設定の状態では、WTPは、設定ステータス要求メッセージを介してACに現在の設定の上書きを送信します。コンフィギュレーション・オーバーライドは、デフォルト以外のパラメータです。一例として、CAPWAPプロトコルで、デフォルトのアンテナ構成は、内部オムニアンテナです。 WTPはどちらかは内部アンテナを持っていない、または明示的に外部アンテナを使用するACによって構成されていることを、WTPの現在の設定を自覚するためにACを許可するには、configureの段階でそのアンテナ構成を送信します。
Once the WTP has provided its configuration to the AC, the AC sends its configuration to the WTP. This allows the WTP to receive configuration and policies from the AC.
WTPはACにその設定を提供していたら、ACはWTPにその設定を送信します。これは、WTPはACからの設定とポリシーを受け取ることができます。
The AC maintains a copy of each active WTP configuration. There is no need for versioning or other means to identify configuration changes. If a WTP becomes inactive, the AC MAY delete the inactive WTP configuration. If a WTP fails, and connects to a new AC, the WTP provides its overridden configuration parameters, allowing the new AC to be aware of the WTP configuration.
ACは、各アクティブWTP構成のコピーを維持します。バージョン管理や構成の変更を識別するための他の手段のための必要はありません。 WTPが非アクティブになる場合は、ACは非アクティブWTPの設定を削除することができます。 WTPは失敗し、新しいACに接続する場合、WTPは新しいACは、WTPの設定を認識することができ、その上書きされた設定パラメータを提供します。
This model allows for resiliency in case of an AC failure, ensuring another AC can provide service to the WTP. A new AC would be automatically updated with WTP configuration changes, eliminating the need for inter-AC communication and the need for all ACs to be aware of the configuration of all WTPs in the network.
このモデルは、WTPにサービスを提供することができる別のACを確保する、AC障害が発生した場合に復元力を可能にします。新しいACは自動的に相互交流通信の必要性と、すべてのACSは、ネットワーク内のすべてのWTPsの構成を意識する必要がなくなり、WTPの設定変更で更新されます。
Once the CAPWAP protocol enters the Run state, the WTPs begin to provide service. It is common for administrators to require that configuration changes be made while the network is operational. Therefore, the Configuration Update Request is sent by the AC to the WTP to make these changes at run-time.
CAPWAPプロトコルが実行状態に入ると、WTPsは、サービスを提供し始めます。管理者は、ネットワークが動作している間、設定の変更が行われることを要求するのが一般的です。そのため、設定更新要求は実行時にこれらの変更を行うためにWTPにACによって送信されます。
The CAPWAP protocol provides the flexibility to configure and manage WTPs of varying design and functional characteristics. When a WTP first discovers an AC, it provides primary functional information relating to its type of MAC and to the nature of frames to be exchanged. The AC configures the WTP appropriately. The AC also establishes corresponding internal state for the WTP.
CAPWAPプロトコルは、様々なデザインと機能特性のWTPsを構成および管理するための柔軟性を提供します。 WTPは、第1の交流を検出すると、それはMACのその種類及び交換されるフレームの性質に関連する主要な機能情報を提供します。 ACは、適切にWTPを設定します。 ACはまた、WTPのための対応する内部状態を確立します。
The Configuration Status Request message is sent by a WTP to deliver its current configuration to the AC.
設定ステータス要求メッセージは、ACに、現在のコンフィギュレーションを提供するためにWTPによって送信されます。
The Configuration Status Request message carries binding-specific message elements. Refer to the appropriate binding for the definition of this structure.
設定ステータス要求メッセージは、バインディング固有のメッセージ要素を運びます。この構造体の定義については、結合に適切なを参照してください。
When an AC receives a Configuration Status Request message, it acts upon the content of the message and responds to the WTP with a Configuration Status Response message.
ACが設定ステータス要求メッセージを受信すると、メッセージの内容に作用し、設定ステータス応答メッセージでWTPに応答します。
The Configuration Status Request message includes multiple Radio Administrative State message elements, one for the WTP, and one for each radio in the WTP.
設定状態要求メッセージは、複数の無線管理状態メッセージ要素、WTPのための1つ、およびWTPの各無線のいずれかを含みます。
The Configuration Status Request message is sent by the WTP when in the Configure State. The AC does not transmit this message.
設定ステータス要求メッセージをするときの設定状態にWTPによって送られます。 ACは、このメッセージを送信しません。
The following message elements MUST be included in the Configuration Status Request message.
次のメッセージ要素が設定ステータス要求メッセージに含まれなければなりません。
o AC Name, see Section 4.6.4
ACの名前O、セクション4.6.4を参照してください
o Radio Administrative State, see Section 4.6.33
Oラジオ管理状態は、セクション4.6.33を参照してください
o Statistics Timer, see Section 4.6.38
統計タイマーO、セクション4.6.38を参照してください
o WTP Reboot Statistics, see Section 4.6.47
O WTPをリブート統計は、セクション4.6.47を参照してください
The following message elements MAY be included in the Configuration Status Request message.
次のメッセージ要素が設定ステータス要求メッセージに含まれるかもしれません。
o AC Name with Priority, see Section 4.6.5
優先順位のAC名O、セクション4.6.5を参照してください
o CAPWAP Transport Protocol, see Section 4.6.14
CAPWAPトランスポートプロトコルO、セクション4.6.14を参照してください
o WTP Static IP Address Information, see Section 4.6.48
O WTP静的IPアドレス情報は、セクション4.6.48を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Configuration Status Response message is sent by an AC and provides a mechanism for the AC to override a WTP's requested configuration.
設定ステータス応答メッセージは、ACによって送信され、ACは、WTPの要求された設定を上書きするためのメカニズムを提供しています。
A Configuration Status Response message is sent by an AC after receiving a Configuration Status Request message.
設定ステータス応答メッセージは、設定ステータス要求メッセージを受信した後、ACによって送信されます。
The Configuration Status Response message carries binding-specific message elements. Refer to the appropriate binding for the definition of this structure.
設定ステータス応答メッセージは、バインディング固有のメッセージ要素を運びます。この構造体の定義については、結合に適切なを参照してください。
When a WTP receives a Configuration Status Response message, it acts upon the content of the message, as appropriate. If the Configuration Status Response message includes a Radio Operational State message element that causes a change in the operational state of one of the radios, the WTP transmits a Change State Event to the AC, as an acknowledgement of the change in state.
WTPが設定ステータス応答メッセージを受信すると、それは、必要に応じて、メッセージの内容に作用します。設定ステータス応答メッセージは、無線のいずれかの動作状態を変化させるラジオ操作状態メッセージ要素が含まれている場合、WTPは、状態の変化の確認応答として、ACへの変更状態イベントを送信します。
The Configuration Status Response message is sent by the AC when in the Configure state. The WTP does not transmit this message.
設定ステータス応答メッセージをするときの設定状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message elements MUST be included in the Configuration Status Response message.
次のメッセージ要素が設定ステータス応答メッセージに含まれなければなりません。
o CAPWAP Timers, see Section 4.6.13
CAPWAPタイマーO、セクション4.6.13を参照してください
o Decryption Error Report Period, see Section 4.6.18
復号化エラーレポート期間O、セクション4.6.18を参照してください
o Idle Timeout, see Section 4.6.24
Oアイドルタイムアウトは、セクション4.6.24を参照してください
o WTP Fallback, see Section 4.6.42
WTPフォールバックO、セクション4.6.42を参照してください
One or both of the following message elements MUST be included in the Configuration Status Response message:
次のメッセージ要素の一方または両方が設定ステータス応答メッセージに含まれなければなりません：
o AC IPv4 List, see Section 4.6.2
AC IPv4の一覧O、4.6.2項を参照してください
o AC IPv6 List, see Section 4.6.3
AC IPv6の一覧O、4.6.3項を参照してください
The following message element MAY be included in the Configuration Status Response message.
次のメッセージ要素は、設定ステータス応答メッセージに含まれるかもしれません。
o WTP Static IP Address Information, see Section 4.6.48
O WTP静的IPアドレス情報は、セクション4.6.48を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
Configuration Update Request messages are sent by the AC to provision the WTP while in the Run state. This is used to modify the configuration of the WTP while it is operational.
ファイル名を指定して実行状態にしながら、構成更新要求メッセージは、WTP提供にACによって送信されます。これは、それが動作している間、WTPの設定を変更するために使用されます。
When a WTP receives a Configuration Update Request message, it responds with a Configuration Update Response message, with a Result Code message element indicating the result of the configuration request.
WTPは、コンフィギュレーション更新要求メッセージを受信すると、コンフィギュレーション要求の結果を示す結果コードメッセージ要素で、設定の更新応答メッセージで応答します。
The AC includes the Image Identifier message element (see Section 4.6.27) to force the WTP to update its firmware while in the Run state. The WTP MAY proceed to download the requested firmware if it determines the version specified in the Image Identifier message element is not in its non-volatile storage by transmitting an Image Data Request (see Section 9.1.1) that includes the Initiate Download message element (see Section 4.6.29).
ACは、実行状態にある間、そのファームウェアを更新するためにWTPを強制的に画像識別子メッセージ要素（セクション4.6.27を参照）を含みます。それは画像データ要求を送信することにより、その不揮発性ストレージに画像識別メッセージ要素で指定されたバージョンをされていない判断した場合WTPは、要求されたファームウェアをダウンロードに進むことができる（ダウンロードメッセージを開始する要素を含んでいる（9.1.1項を参照してください）セクション4.6.29）を参照してください。
The Configuration Update Request is sent by the AC when in the Run state. The WTP does not transmit this message.
コンフィギュレーションの更新要求をしたときに実行状態でACによって送信されます。 WTPは、このメッセージを送信しません。
One or more of the following message elements MAY be included in the Configuration Update message:
次のメッセージ要素の1つ以上が構成更新メッセージに含まれることがあります。
o AC Name with Priority, see Section 4.6.5
優先順位のAC名O、セクション4.6.5を参照してください
o AC Timestamp, see Section 4.6.6
ACタイムスタンプO、セクション4.6.6を参照してください
o Add MAC ACL Entry, see Section 4.6.7
Oセクション4.6.7を参照してください、MAC ACLエントリの追加
o CAPWAP Timers, see Section 4.6.13
CAPWAPタイマーO、セクション4.6.13を参照してください
o Decryption Error Report Period, see Section 4.6.18
復号化エラーレポート期間O、セクション4.6.18を参照してください
o Delete MAC ACL Entry, see Section 4.6.19
O MAC ACLエントリを削除し、セクション4.6.19を参照してください
o Idle Timeout, see Section 4.6.24
Oアイドルタイムアウトは、セクション4.6.24を参照してください
o Location Data, see Section 4.6.30
位置データO、セクション4.6.30を参照してください
o Radio Administrative State, see Section 4.6.33
Oラジオ管理状態は、セクション4.6.33を参照してください
o Statistics Timer, see Section 4.6.38
統計タイマーO、セクション4.6.38を参照してください
o WTP Fallback, see Section 4.6.42
WTPフォールバックO、セクション4.6.42を参照してください
o WTP Name, see Section 4.6.45
WTP名前O、セクション4.6.45を参照してください
o WTP Static IP Address Information, see Section 4.6.48
O WTP静的IPアドレス情報は、セクション4.6.48を参照してください
o Image Identifier, see Section 4.6.27
Oイメージ識別子は、セクション4.6.27を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Configuration Update Response message is the acknowledgement message for the Configuration Update Request message.
設定の更新応答メッセージは、設定更新要求メッセージのための確認メッセージです。
The Configuration Update Response message is sent by a WTP after receiving a Configuration Update Request message.
設定の更新応答メッセージは、設定更新要求メッセージを受信した後、WTPによって送られます。
When an AC receives a Configuration Update Response message, the result code indicates if the WTP successfully accepted the configuration.
ACは、構成更新応答メッセージを受信するとWTPが正常な構成を受け入れた場合、結果コードを示します。
The Configuration Update Response message is sent by the WTP when in the Run state. The AC does not transmit this message.
ときに実行状態に設定更新応答メッセージは、WTPによって送られます。 ACは、このメッセージを送信しません。
The following message element MUST be present in the Configuration Update message.
次のメッセージ要素は、Configuration Updateメッセージ中に存在しなければなりません。
Result Code, see Section 4.6.35
結果コードは、セクション4.6.35を参照してください
The following message elements MAY be present in the Configuration Update Response message.
次のメッセージ要素は、設定の更新応答メッセージ中に存在してもよいです。
o Radio Operational State, see Section 4.6.34
Oラジオ動作状態が、セクション4.6.34を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Change State Event Request message is used by the WTP for two main purposes:
変更状態イベント要求メッセージは、2つの主な目的のためにWTPで使用されます。
o When sent by the WTP following the reception of a Configuration Status Response message from the AC, the WTP uses the Change State Event Request message to provide an update on the WTP radio's operational state and to confirm that the configuration provided by the AC was successfully applied.
ACからの設定ステータス応答メッセージの受信次WTPにより送信された場合には、O、WTPはWTPラジオの運転状態にアップデートを提供し、ACから提供された設定が正常であることを確認するために変更状態イベント要求メッセージを使用しています適用されます。
o When sent during the Run state, the WTP uses the Change State Event Request message to notify the AC of an unexpected change in the WTP's radio operational state.
実行状態の間に送られた場合には、O、WTPはWTPのラジオ動作状態での予期しない変更のACを通知する変更状態イベント要求メッセージを使用しています。
When an AC receives a Change State Event Request message it responds with a Change State Event Response message and modifies its data structures for the WTP as needed. The AC MAY decide not to provide service to the WTP if it receives an error, based on local policy, and to transition to the Reset state.
ACは変更状態イベント要求メッセージを受信した場合には、変更状態イベント応答メッセージで応答し、必要に応じてWTPのためのデータ構造を変更します。 ACは、それがエラーを受信した場合、ローカルポリシーに基づいて、WTPにサービスを提供しないことを決定してもよいし、リセット状態に遷移します。
The Change State Event Request message is sent by a WTP to acknowledge or report an error condition to the AC for a requested configuration in the Configuration Status Response message. The Change State Event Request message includes the Result Code message element, which indicates whether the configuration was successfully applied. If the WTP is unable to apply a specific configuration request, it indicates the failure by including one or more Returned Message Element message elements (see Section 4.6.36).
変更状態イベント要求メッセージは、承認または設定ステータス応答メッセージで要求された構成のためのACにエラー状態を報告するためにWTPによって送信されます。変更状態イベント要求メッセージは、設定が正常に適用されたかどうかを示す結果コードメッセージ要素を含んでいます。 WTPは、特定の構成要求を適用することができない場合、これは、1つのまたは複数の返されたメッセージ要素のメッセージ要素（セクション4.6.36を参照のこと）などによって失敗を示します。
The Change State Event Request message is sent by the WTP in the Configure or Run state. The AC does not transmit this message.
変更状態イベント要求メッセージは、設定およびファイル名を指定して実行状態にWTPによって送られます。 ACは、このメッセージを送信しません。
The WTP MAY save its configuration to persistent storage prior to transmitting the response. However, this is implementation specific and is not required.
WTPは、前の応答を送信する永続ストレージにその設定を保存することがあります。しかし、これは実装固有のものであり、必要とされていません。
The following message elements MUST be present in the Change State Event Request message.
次のメッセージ要素が変更状態イベント要求メッセージ中に存在しなければなりません。
o Radio Operational State, see Section 4.6.34
Oラジオ動作状態が、セクション4.6.34を参照してください
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
One or more of the following message elements MAY be present in the Change State Event Request message:
次のメッセージ要素の1つ以上が変更状態イベント要求メッセージ内に存在することがあります。
o Returned Message Element(s), see Section 4.6.36
O返されたメッセージ要素（複数可）、セクション4.6.36を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Change State Event Response message acknowledges the Change State Event Request message.
変更状態イベント応答メッセージは、変更状態イベント要求メッセージを承認します。
A Change State Event Response message is sent by an AC in response to a Change State Event Request message.
変更状態イベント応答メッセージは、状態の変更イベント要求メッセージに応答してACによって送られます。
The Change State Event Response message is sent by the AC when in the Configure or Run state. The WTP does not transmit this message.
変更状態イベント応答メッセージをするときの設定やファイル名を指定して実行状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message element MAY be included in the Change State Event Response message:
次のメッセージ要素は変更状態イベント応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The WTP does not take any action upon receipt of the Change State Event Response message.
WTPは変更状態イベント応答メッセージの受信時に任意のアクションを取ることはありません。
The Clear Configuration Request message is used to reset the WTP configuration.
クリア設定要求メッセージは、WTPの設定をリセットするために使用されます。
The Clear Configuration Request message is sent by an AC to request that a WTP reset its configuration to the manufacturing default configuration. The Clear Config Request message is sent while in the Run state.
クリア設定要求メッセージは、WTPが製造デフォルト設定にその設定をリセットすることを要求するためにACによって送信されます。クリアコンフィグ要求メッセージは、ファイル名を指定して実行状態にある間に送信されます。
The Clear Configuration Request is sent by the AC when in the Run state. The WTP does not transmit this message.
クリア構成要求をしたときに実行状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message element MAY be included in the Clear Configuration Request message:
次のメッセージ要素はクリア設定要求メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
When a WTP receives a Clear Configuration Request message, it resets its configuration to the manufacturing default configuration.
WTPがクリアの設定要求メッセージを受信すると、それは製造デフォルト設定にその設定をリセットします。
The Clear Configuration Response message is sent by the WTP after receiving a Clear Configuration Request message and resetting its configuration parameters to the manufacturing default values.
クリア設定の応答メッセージは、クリアの設定要求メッセージを受信し、製造時のデフォルト値にその設定パラメータをリセットした後WTPによって送られます。
The Clear Configuration Response is sent by the WTP when in the Run state. The AC does not transmit this message.
クリア設定の応答はときRun状態でWTPによって送られます。 ACは、このメッセージを送信しません。
The Clear Configuration Response message MUST include the following message element:
クリア設定の応答メッセージには、次のメッセージ要素を含める必要があります。
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
The following message element MAY be included in the Clear Configuration Request message:
次のメッセージ要素はクリア設定要求メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
This section defines CAPWAP operations responsible for debugging, gathering statistics, logging, and firmware management. The management operations defined in this section are used by the AC to either push/pull information to/from the WTP, or request that the WTP reboot. This section does not deal with the management of the AC per se, and assumes that the AC is operational and configured.
このセクションでは、デバッグ、統計情報を収集、ロギング、およびファームウェアの管理を担当CAPWAPオペレーションを定義します。このセクションで定義された管理操作は、プッシュ/ WTPへ/から情報を引き出し、またはWTPリブートすることを要求するために、いずれかのACで使用されます。このセクションでは、AC自体の管理に対処し、ACが動作して構成されていることを前提としていません。
This section describes the firmware download procedures used by the CAPWAP protocol. Firmware download can occur during the Image Data or Run state. The former allows the download to occur at boot time, while the latter is used to trigger the download while an active CAPWAP session exists. It is important to note that the CAPWAP protocol does not provide the ability for the AC to identify whether the firmware information provided by the WTP is correct or whether the WTP is properly storing the firmware (see Section 12.10 for more information).
このセクションでは、CAPWAPプロトコルによって使用されるファームウェアのダウンロード手順について説明します。ファームウェアのダウンロードは、画像データや実行状態の間に発生する可能性があります。前者は後者がアクティブCAPWAPセッションが存在する間、ダウンロードをトリガするために使用されるダウンロードは、ブート時に発生することを可能にします。 CAPWAPプロトコルはACがWTPによって提供されるファームウェア情報が正しいかWTPが適切に（詳細については、セクション12.10を参照）ファームウェアを記憶しているかどうかを識別するための能力を提供しないことに留意することが重要です。
Figure 6 provides an example of a WTP that performs a firmware upgrade while in the Image Data state. In this example, the WTP does not already have the requested firmware (Image Identifier = x), and downloads the image from the AC.
図6は、画像データの状態にある間にファームウェアアップグレードを行うWTPの例を提供します。この例では、WTPは既に要求されたファームウェア（画像識別子= X）を有し、そしてACから画像をダウンロードしません。
WTP AC
WTP AC
Join Request
-------------------------------------------------------->
Join Response (Image Identifier = x)
<------------------------------------------------------
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
Image Data Request (Image Data = Data)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
.....
。。。。。
Image Data Request (Image Data = EOF)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
(WTP enters the Reset State)
（WTPはリセット状態になります）
Figure 6: WTP Firmware Download Case 1
図6：WTPファームウェアのダウンロードケース1
Figure 7 provides an example in which the WTP has the image specified by the AC in its non-volatile storage, but is not its current running image. In this case, the WTP opts to NOT download the firmware and immediately reset to the requested image.
図7は、WTPは、その不揮発性記憶装置にACで指定された画像を有しているが、その現在の実行イメージない例を提供します。この場合、WTPは、ファームウェアをダウンロードし、すぐに要求された画像にリセットしないことを選択します。
WTP AC
WTP AC
Join Request
-------------------------------------------------------->
Join Response (Image Identifier = x)
<------------------------------------------------------
(WTP enters the Reset State)
（WTPはリセット状態になります）
Figure 7: WTP Firmware Download Case 2
図7：WTPファームウェアのダウンロードケース2
Figure 8 provides an example of a WTP that performs a firmware upgrade while in the Run state. This mode of firmware upgrade allows the WTP to download its image while continuing to provide service. The WTP will not automatically reset until it is notified by the AC, with a Reset Request message.
図8は、実行状態にある間にファームウェアアップグレードを行うWTPの例を提供します。ファームウェアのアップグレードのこのモードは、サービスを提供し続けながら、WTPはその画像をダウンロードすることができます。それはACによって通知されるまでWTPは自動的にリセット要求メッセージと、リセットされません。
WTP AC
WTP AC
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Response (Result Code = Success)
-------------------------------------------------------->
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
Image Data Request (Image Data = Data)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
.....
。。。。。
Image Data Request (Image Data = EOF)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
.....
。。。。。
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
Reset Response (Result Code = Success)
-------------------------------------------------------->
Figure 8: WTP Firmware Download Case 3
図8：WTPファームウェアのダウンロードケース3
Figure 9 provides another example of the firmware download while in the Run state. In this example, the WTP already has the image specified by the AC in its non-volatile storage. The WTP opts to NOT download the firmware. The WTP resets upon receipt of a Reset Request message from the AC.
図9は、実行状態にある間にファームウェアダウンロードの別の例を提供します。この例では、WTPは既に不揮発性記憶装置にACで指定された画像を有しています。 WTPは、ファームウェアをダウンロードしないことを選択します。 WTPは、ACからのリセット要求メッセージを受信するとリセットされます。
WTP AC
WTP AC
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Response (Result Code = Already Have Image)
-------------------------------------------------------->
.....
。。。。。
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
Reset Response (Result Code = Success)
-------------------------------------------------------->
Figure 9: WTP Firmware Download Case 4
図9：WTPファームウェアのダウンロードケース4
The Image Data Request message is used to update firmware on the WTP. This message and its companion Response message are used by the AC to ensure that the image being run on each WTP is appropriate.
画像データ要求メッセージは、WTPのファームウェアを更新するために使用されます。このメッセージとそのコンパニオン応答メッセージは各WTP上で実行される画像が適切であることを保証するために、ACで使用されます。
Image Data Request messages are exchanged between the WTP and the AC to download a new firmware image to the WTP. When a WTP or AC receives an Image Data Request message, it responds with an Image Data Response message. The message elements contained within the Image Data Request message are required to determine the intent of the request.
画像データ要求メッセージは、WTPに新しいファームウェアイメージをダウンロードしてWTPとAC間で交換されています。 WTPまたはACは、画像データ要求メッセージを受信すると、画像データの応答メッセージで応答します。画像データ要求メッセージ内に含まれるメッセージの要素は、要求の意図を決定するのに必要とされます。
The decision that new firmware is to be downloaded to the WTP can occur in one of two ways:
新しいファームウェアがWTPにダウンロードされる決定は、2つの方法のいずれかで発生する可能性があります。
When the WTP joins the AC, the Join Response message includes the Image Identifier message element, which informs the WTP of the firmware it is expected to run. If the WTP does not currently have the requested firmware version, it transmits an Image Data Request message, with the appropriate Image Identifier message element. If the WTP already has the requested firmware in its non-volatile flash, but is not its currently running image, it simply resets to run the proper firmware.
WTPはACに参加すると、参加応答メッセージは、実行すると予想されているファームウェアのWTPを知らせる画像識別メッセージ要素を含んでいます。 WTPが現在要求ファームウェアのバージョンを持っていない場合は、適切な画像識別メッセージ要素と、画像データ要求メッセージを送信します。 WTPは、すでにその不揮発性フラッシュメモリに要求されたファームウェアを有するが、その現在実行中のイメージではない場合、それは単に適切なファームウェアを実行するためにリセットされます。
Once the WTP is in the Run state, it is possible for the AC to cause the WTP to initiate a firmware download by sending a Configuration Update Request message with the Image Identifier message elements. This will cause the WTP to transmit an Image
WTPがRUN状態になるとACは、画像識別メッセージ要素で構成更新要求メッセージを送信することにより、ファームウェアのダウンロードを開始するために、WTPを引き起こすすることが可能です。これは、WTPは、画像を送信するようになります
Data Request with the Image Identifier and the Initiate Download message elements. Note that when the firmware is downloaded in this way, the WTP does not automatically reset after the download is complete. The WTP will only reset when it receives a Reset Request message from the AC. If the WTP already had the requested firmware version in its non-volatile storage, the WTP does not transmit the Image Data Request message and responds with a Configuration Update Response message with the Result Code set to Image Already Present.
画像の識別子と開始ダウンロードメッセージ要素とデータ要求。ファームウェアはこのようにダウンロードされたときにダウンロードが完了した後、WTPは自動的にリセットされないことに注意してください。それはACからのリセット要求メッセージを受信したときにWTPにのみリセットされます。 WTPは、すでにその不揮発性ストレージに要求されたファームウェアのバージョンを持っていた場合は、WTPは、画像データ要求メッセージを送信し、既に存在している画像に設定する結果コードとコンフィギュレーションの更新応答メッセージで応答しません。
Regardless of how the download was initiated, once the AC receives an Image Data Request message with the Image Identifier message element, it begins the transfer process by transmitting an Image Data Request message that includes the Image Data message element. This continues until the firmware image has been transferred.
かかわらず、ACは、画像識別メッセージ要素を持つ画像データ要求メッセージを受信すると、ダウンロードが開始されたかの、それは、画像データのメッセージ要素を含む画像データ要求メッセージを送信することにより、転送プロセスを開始します。ファームウェアイメージが転送されるまでこれが続きます。
The Image Data Request message is sent by the WTP or the AC when in the Image Data or Run state.
画像データ要求メッセージは、WTPまたはAC画像データやRun状態で送信されます。
The following message elements MAY be included in the Image Data Request message:
次のメッセージ要素は、画像データ要求メッセージに含まれることがあります。
o CAPWAP Transport Protocol, see Section 4.6.14
CAPWAPトランスポートプロトコルO、セクション4.6.14を参照してください
o Image Data, see Section 4.6.26
O画像データは、セクション4.6.26を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The following message elements MAY be included in the Image Data Request message when sent by the WTP:
WTPによって送信されたときに、次のメッセージ要素は、画像データ要求メッセージに含まれることがあります。
o Image Identifier, see Section 4.6.27
Oイメージ識別子は、セクション4.6.27を参照してください
o Initiate Download, see Section 4.6.29
Oセクション4.6.29を参照してください、ダウンロードを開始
The Image Data Response message acknowledges the Image Data Request message.
画像データの応答メッセージは、画像データ要求メッセージを承認します。
An Image Data Response message is sent in response to a received Image Data Request message. Its purpose is to acknowledge the receipt of the Image Data Request message. The Result Code is included to indicate whether a previously sent Image Data Request message was invalid.
画像データ応答メッセージを受信した画像データ要求メッセージに応答して送信されます。その目的は、画像データ要求メッセージの受信を確認することです。結果コードは、以前に送られた画像データ要求メッセージが無効であったかどうかを示すために含まれています。
The Image Data Response message is sent by the WTP or the AC when in the Image Data or Run state.
画像データ応答メッセージは、WTPまたはAC画像データやRun状態で送信されます。
The following message element MUST be included in the Image Data Response message:
次のメッセージ要素は、画像データの応答メッセージに含まれなければなりません：
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
The following message element MAY be included in the Image Data Response message:
次のメッセージ要素は、画像データの応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The following message element MAY be included in the Image Data Response message when sent by the AC:
ACによって送信されたときに、次のメッセージ要素は、画像データの応答メッセージに含まれることがあります。
o Image Information, see Section 4.6.28
O画像情報は、セクション4.6.28を参照してください
Upon receiving an Image Data Response message indicating an error, the WTP MAY retransmit a previous Image Data Request message, or abandon the firmware download to the WTP by transitioning to the Reset state.
エラーを示す画像データ応答メッセージを受信すると、WTPは、前回の画像データ要求メッセージを再送信することができる、またはリセット状態に遷移することによってWTPへのファームウェアのダウンロードを放棄します。
The Reset Request message is used to cause a WTP to reboot.
リセット要求メッセージは、WTPを再起動させるために使用されています。
A Reset Request message is sent by an AC to cause a WTP to reinitialize its operation. If the AC includes the Image Identifier message element (see Section 4.6.27), it indicates to the WTP that it SHOULD use that version of software upon reboot.
リセット要求メッセージは、その操作を再初期化するためにWTPを引き起こすためにACによって送信されます。 AC（セクション4.6.27を参照のこと）画像識別子メッセージ要素を含む場合、それは再起動時に、ソフトウェアのバージョンを使用することをWTPに示します。
The Reset Request is sent by the AC when in the Run state. The WTP does not transmit this message.
リセット要求をしたときに実行状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message element MUST be included in the Reset Request message:
次のメッセージ要素は、リセット要求メッセージに含まれなければなりません：
o Image Identifier, see Section 4.6.27
Oイメージ識別子は、セクション4.6.27を参照してください
The following message element MAY be included in the Reset Request message:
次のメッセージ要素は、リセット要求メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
When a WTP receives a Reset Request message, it responds with a Reset Response message indicating success and then reinitializes itself. If the WTP is unable to write to its non-volatile storage, to ensure that it runs the requested software version indicated in the Image Identifier message element, it MAY send the appropriate Result Code message element, but MUST reboot. If the WTP is unable to reset, including a hardware reset, it sends a Reset Response message to the AC with a Result Code message element indicating failure. The AC no longer provides service to the WTP.
WTPは、リセット要求メッセージを受信すると、それが成功したことを示すリセット応答メッセージで応答して、自分自身を再初期化します。 WTPは、それが画像識別メッセージ要素に示されている要求されたソフトウェアのバージョンを実行することを保証するために、その不揮発性ストレージに書き込むことができない場合は、適切な結果コードメッセージ要素を送るかもしれませが、再起動する必要があります。 WTPは、ハードウェアリセットを含め、リセットすることができない場合、それが失敗したことを示す結果コードメッセージ要素とACにリセット応答メッセージを送信します。 ACはもはやWTPにサービスを提供していません。
The Reset Response message acknowledges the Reset Request message.
リセット応答メッセージは、リセット要求メッセージを承認します。
A Reset Response message is sent by the WTP after receiving a Reset Request message.
リセット応答メッセージは、リセット要求メッセージを受信した後、WTPによって送られます。
The Reset Response is sent by the WTP when in the Run state. The AC does not transmit this message.
リセット応答をしたときに実行状態でWTPによって送信されます。 ACは、このメッセージを送信しません。
The following message elements MAY be included in the Reset Response message.
次のメッセージ要素がリセット応答メッセージに含まれるかもしれません。
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
When an AC receives a successful Reset Response message, it is notified that the WTP will reinitialize its operation. An AC that receives a Reset Response message indicating failure may opt to no longer provide service to the WTP.
ACが成功リセット応答メッセージを受信すると、WTPはその動作を再初期化することが通知されます。もはやに選ぶんWTPにサービスを提供することが失敗したことを示すリセット応答メッセージを受信AC。
The WTP Event Request message is used by a WTP to send information to its AC. The WTP Event Request message MAY be sent periodically, or sent in response to an asynchronous event on the WTP. For example, a WTP MAY collect statistics and use the WTP Event Request message to transmit the statistics to the AC.
WTPイベント要求メッセージは、そのACに情報を送信するためにWTPで使用されています。 WTPイベント要求メッセージは定期的に送信、またはWTP上の非同期イベントへの応答で送信することができます。例えば、WTPは、統計を収集し、ACに統計情報を送信するためにWTPイベント要求メッセージを使用するかもしれません。
When an AC receives a WTP Event Request message it will respond with a WTP Event Response message.
ACは、WTPイベント要求メッセージを受信した場合には、WTPイベント応答メッセージで応答します。
The presence of the Delete Station message element is used by the WTP to inform the AC that it is no longer providing service to the station. This could be the result of an Idle Timeout (see Section 4.6.24), due to resource shortages, or some other reason.
削除ステーションメッセージ要素の存在は、それがもはや駅にサービスを提供していることをACに通知しないようにWTPで使用されています。これは、リソース不足、またはその他の理由によるアイドルタイムアウト（セクション4.6.24を参照）の結果である可能性があります。
The WTP Event Request message is sent by the WTP when in the Run state. The AC does not transmit this message.
WTPイベント要求メッセージは時にファイル名を指定して実行状態にWTPによって送られます。 ACは、このメッセージを送信しません。
The WTP Event Request message MUST contain one of the message elements listed below, or a message element that is defined for a specific wireless technology. More than one of each message element listed MAY be included in the WTP Event Request message.
WTPイベント要求メッセージは、下記のメッセージ要素の一つ、または特定の無線技術のために定義されたメッセージ要素を含まなければなりません。リストされた各メッセージ要素の複数のWTPイベント要求メッセージに含まれるかもしれません。
o Decryption Error Report, see Section 4.6.17
復号化エラーレポートO、セクション4.6.17を参照してください
o Duplicate IPv4 Address, see Section 4.6.22
重複IPv4アドレスO、セクション4.6.22を参照してください
o Duplicate IPv6 Address, see Section 4.6.23
重複IPv6アドレスO、セクション4.6.23を参照してください
o WTP Radio Statistics, see Section 4.6.46
O WTPラジオ統計は、セクション4.6.46を参照してください
o WTP Reboot Statistics, see Section 4.6.47
O WTPをリブート統計は、セクション4.6.47を参照してください
o Delete Station, see Section 4.6.20
Oステーションを削除し、セクション4.6.20を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The WTP Event Response message acknowledges receipt of the WTP Event Request message.
WTPイベント応答メッセージは、WTPイベント要求メッセージの受信を確認します。
A WTP Event Response message is sent by an AC after receiving a WTP Event Request message.
WTPイベント応答メッセージはWTPイベント要求メッセージを受信した後にACによって送られます。
The WTP Event Response message is sent by the AC when in the Run state. The WTP does not transmit this message.
WTPイベント応答メッセージはときRun状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following message element MAY be included in the WTP Event Response message:
次のメッセージ要素は、WTPイベント応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
This section describes the data transfer procedures used by the CAPWAP protocol. The data transfer mechanism is used to upload information available at the WTP to the AC, such as crash or debug information. The data transfer messages can only be exchanged while in the Run state.
このセクションでは、CAPWAPプロトコルによって使用されるデータ転送手順を記載しています。データ転送機構は、クラッシュまたはデバッグ情報として、ACにWTPで入手可能な情報をアップロードするために使用されます。ファイル名を指定して実行状態にある間のデータ転送メッセージのみを交換することができます。
Figure 10 provides an example of an AC that requests that the WTP transfer its latest crash file. Once the WTP acknowledges that it has information to send, via the Data Transfer Response, it transmits its own Data Transfer Request. Upon receipt, the AC responds with a
図10は、WTPはその最新のクラッシュファイルを転送することを要求したACの例を提供します。 WTPは、それがデータ転送応答を介して、送信するための情報を持っていることを認識したら、それはそれ自身のデータ転送要求を送信します。受信すると、ACがで応答します
Data Transfer Response, and the exchange continues until the WTP transmits a Data Transfer Data message element that indicates an End of File (EOF).
WTPは、ファイル（EOF）の終了を示すデータ転送データメッセージ要素を送信するまで、データ転送応答は、交換が継続されます。
WTP AC
WTP AC
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Response (Result Code = Success)
-------------------------------------------------------->
Data Transfer Request (Data Transfer Data = Data)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
.....
。。。。。
Data Transfer Request (Data Transfer Data = EOF)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
Figure 10: WTP Data Transfer Case 1
図10：WTPデータ転送ケース1
Figure 11 provides an example of an AC that requests that the WTP transfer its latest crash file. However, in this example, the WTP does not have any crash information to send, and therefore sends a Data Transfer Response with a Result Code indicating the error.
図11は、WTPはその最新のクラッシュファイルを転送することを要求したACの例を提供します。しかし、この例では、WTPは、送信するすべてのクラッシュ情報を持っていないので、エラーを示す結果コードとデータ転送応答を送信します。
WTP AC
WTP AC
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Response (Result Code = Data Transfer
Error (No Information to Transfer))
-------------------------------------------------------->
Figure 11: WTP Data Transfer Case 2
図11：WTPデータ転送ケース2
The Data Transfer Request message is used to deliver debug information from the WTP to the AC.
データ転送要求メッセージはACへのWTPからデバッグ情報を配信するために使用されます。
The Data Transfer Request messages can be sent either by the AC or the WTP. When sent by the AC, it is used to request that data be transmitted from the WTP to the AC, and includes the Data Transfer Mode message element, which specifies the information desired by the AC. The Data Transfer Request is sent by the WTP in order to transfer actual data to the AC, through the Data Transfer Data message element.
データ転送要求メッセージは、ACまたはWTPのいずれかによって送信することができます。 ACによって送信された場合には、データがWTPからACに送信することを要求するために使用され、ACが所望する情報を指定するデータ転送モードメッセージ要素を含んでいます。データ転送要求、データ転送データメッセージ要素を介して、ACに実際のデータを転送するためにWTPによって送信されます。
Given that the CAPWAP protocol minimizes the need for WTPs to be directly managed, the Data Transfer Request is an important troubleshooting tool used by the AC to retrieve information that may be available on the WTP. For instance, some WTP implementations may store crash information to help manufacturers identify software faults. The Data Transfer Request message can be used to send such information from the WTP to the AC. Another possible use would be to allow a remote debugger function in the WTP to use the Data Transfer Request message to send console output to the AC for debugging purposes.
CAPWAPプロトコルが直接管理するWTPsの必要性を最小限に抑えることを考えると、データ転送要求は、WTPに利用できる情報を取得するためにACで使用される重要なトラブルシューティングツールです。例えば、いくつかのWTP実装はメーカーがソフトウェア障害を識別するのに役立つクラッシュ情報を保存することができます。データ転送要求メッセージをACにWTPからそのような情報を送信するために使用することができます。別の可能な用途は、デバッグ目的でACにコンソール出力を送信するためにデータ転送要求メッセージを使用してWTPでのリモートデバッガ機能を許可するようになります。
When the WTP or AC receives a Data Transfer Request message, it responds to the WTP with a Data Transfer Response message. The AC MAY log the information received through the Data Transfer Data message element.
WTPまたはACは、データ転送要求メッセージを受信すると、データ転送応答メッセージでWTPに応答します。 ACは、データ転送データ・メッセージ要素を介して受信した情報を記録することがあります。
The Data Transfer Request message is sent by the WTP or AC when in the Run state.
データ転送要求メッセージは、実行状態のWTPまたはACによって送信されます。
When sent by the AC, the Data Transfer Request message MUST contain the following message element:
ACによって送信された場合、データ転送要求メッセージは、次のメッセージ要素を含まなければなりません：
o Data Transfer Mode, see Section 4.6.16
Oデータ転送モードは、セクション4.6.16を参照してください
When sent by the WTP, the Data Transfer Request message MUST contain the following message element:
WTPにより送信された場合は、データ転送要求メッセージは、次のメッセージ要素を含まなければなりません：
o Data Transfer Data, see Section 4.6.15
Oデータ転送データは、セクション4.6.15を参照してください
Regardless of whether the Data Transfer Request is sent by the AC or WTP, the following message element MAY be included in the Data Transfer Request message:
かかわらず、データ転送要求をACまたはWTPにより送信されるかどうかの、次のメッセージ要素は、データ転送要求メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Data Transfer Response message acknowledges the Data Transfer Request message.
データ転送応答メッセージには、データ転送要求メッセージを承認します。
A Data Transfer Response message is sent in response to a received Data Transfer Request message. Its purpose is to acknowledge receipt of the Data Transfer Request message. When sent by the WTP, the Result Code message element is used to indicate whether the data transfer requested by the AC can be completed. When sent by the AC, the Result Code message element is used to indicate receipt of the data transferred in the Data Transfer Request message.
データ転送応答メッセージは、受信データ転送要求メッセージに応答して送信されます。その目的は、データ転送要求メッセージの受信を確認することです。 WTPによって送信された場合、結果コードメッセージ要素はACによって要求されたデータ転送を完了することができるかどうかを示すために使用されます。 ACによって送信された場合、結果コードメッセージ要素は、データ転送要求メッセージで転送されるデータの受信を示すために使用されます。
The Data Transfer Response message is sent by the WTP or AC when in the Run state.
データ転送応答メッセージは、WTPまたはAC Run状態で送信されます。
The following message element MUST be included in the Data Transfer Response message:
次のメッセージ要素は、データ転送応答メッセージに含まれなければなりません：
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
The following message element MAY be included in the Data Transfer Response message:
次のメッセージ要素は、データ転送応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available.
より多くの情報が利用可能である場合、データ転送応答メッセージを受信すると、WTPは、より多くの情報を送信します。
Messages in this section are used by the AC to create, modify, or delete station session state on the WTPs.
このセクションのメッセージは、作成、変更、またはWTPsに駅のセッション状態を削除するためにACで使用されています。
The Station Configuration Request message is used to create, modify, or delete station session state on a WTP. The message is sent by the AC to the WTP, and MAY contain one or more message elements. The message elements for this CAPWAP Control message include information that is generally highly technology specific. Refer to the appropriate binding document for definitions of the messages elements that are included in this control message.
駅コンフィギュレーション要求メッセージを作成、変更、またはWTPに駅のセッション状態を削除するために使用されます。メッセージはWTPにACによって送信され、1つまたは複数のメッセージの元素を含んでいてもよいです。このCAPWAP制御メッセージのメッセージ要素は、一般に、高度に技術固有の情報が含まれます。この制御メッセージに含まれるメッセージの要素の定義のために適切な結合ドキュメントを参照。
The Station Configuration Request message is sent by the AC when in the Run state. The WTP does not transmit this message.
駅構成要求メッセージはときRun状態でACによって送信されます。 WTPは、このメッセージを送信しません。
The following CAPWAP Control message elements MAY be included in the Station Configuration Request message. More than one of each message element listed MAY be included in the Station Configuration Request message:
以下のCAPWAP制御メッセージ要素は、駅のコンフィギュレーション要求メッセージに含まれるかもしれません。リストされた各メッセージ要素の複数のステーション構成要求メッセージに含まれることがあります。
o Add Station, see Section 4.6.8
Oセクション4.6.8を参照してください、駅を追加
o Delete Station, see Section 4.6.20
Oステーションを削除し、セクション4.6.20を参照してください
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Station Configuration Response message is used to acknowledge a previously received Station Configuration Request message.
駅コンフィギュレーション応答メッセージは、以前に受信ステーション構成要求メッセージを確認するために使用されます。
The Station Configuration Response message is sent by the WTP when in the Run state. The AC does not transmit this message.
駅コンフィギュレーション応答メッセージは、ときRun状態でWTPによって送られます。 ACは、このメッセージを送信しません。
The following message element MUST be present in the Station Configuration Response message:
次のメッセージ要素は、駅のコンフィギュレーション応答メッセージ中に存在しなければなりません：
o Result Code, see Section 4.6.35
Oセクション4.6.35を参照してください、コードの結果
The following message element MAY be included in the Station Configuration Response message:
次のメッセージ要素は、駅のコンフィギュレーション応答メッセージに含まれることがあります。
o Vendor Specific Payload, see Section 4.6.39
ベンダー固有ペイロードO、セクション4.6.39を参照してください
The Result Code message element indicates that the requested configuration was successfully applied, or that an error related to processing of the Station Configuration Request message occurred on the WTP.
結果コードメッセージ要素は、要求された設定が正常に適用されたこと、またはステーション構成要求メッセージの処理に関連するエラーがWTPに発生したことを示しています。
There are three specific situations in which a NAT deployment may be used in conjunction with a CAPWAP-enabled deployment. The first consists of a configuration in which a single WTP is behind a NAT system. Since all communication is initiated by the WTP, and all communication is performed over IP using two UDP ports, the protocol easily traverses NAT systems in this configuration.
NAT展開がCAPWAP対応の展開と併せて使用することができる、3つの特定の状況があります。最初は、単一のWTPは、NATシステムの背後にあるれた構成から成ります。すべての通信は、WTPにより開始され、すべての通信は、IPは、2つのUDPポートを使用して上に行われるため、プロトコルが簡単にこの構成でNATシステムを横断します。
In the second case, two or more WTPs are deployed behind the same NAT system. Here, the AC would receive multiple connection requests from the same IP address, and therefore cannot use the WTP's IP address alone to bind the CAPWAP Control and Data channel. The CAPWAP Data Check state, which establishes the data plane connection and communicates the CAPWAP Data Channel Keep-Alive, includes the Session Identifier message element, which is used to bind the control and data plane. Use of the Session Identifier message element enables the AC to match the control and data plane flows from multiple WTPs behind the same NAT system (multiple WTPs sharing the same IP address). CAPWAP implementations MUST also use DTLS session information on any encrypted CAPWAP channel to validate the source of both the control and data plane, as described in Section 12.2.
第二のケースでは、2つ以上のWTPsが同じNATシステムの背後に配備されています。ここで、ACは、同じIPアドレスからの複数の接続要求を受け取ることになるので、CAPWAP制御およびデータチャネルをバインドするために単独でWTPのIPアドレスを使用することはできません。 CAPWAPデータがデータプレーン接続を確立し、CAPWAPデータチャネルは、キープアライブ通信状態を確認し、制御およびデータプレーンを結合するために使用されたセッション識別子メッセージ要素を含みます。セッション識別子メッセージ要素の使用は、ACは、制御およびデータプレーンは、同じNATシステム（複数WTPs同じIPアドレスを共有する）の背後にある複数WTPsから流れと一致することができます。 CAPWAP実装はまた、セクション12.2で説明したように、制御およびデータプレーンの両方のソースを検証するために、任意の暗号化されたCAPWAPチャネル上DTLSセッション情報を使用しなければなりません。
In the third configuration, the AC is deployed behind a NAT. In this case, the AC is not reachable by the WTP unless a specific rule has been configured on the NAT to translate the address and redirect CAPWAP messages to the AC. This deployment presents two issues. First, an AC communicates its interfaces and corresponding WTP load using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address message elements. This message element is mandatory, but contains IP addresses that are only valid in the private address space used by the AC, which is not reachable by the WTP. The WTP MUST NOT utilize the information in these message elements if it detects a NAT (as described in the CAPWAP Transport Protocol message element in Section 4.6.14). Second, since the addresses cannot be used by the WTP, this effectively disables the load-balancing capabilities (see Section 6.1) of the CAPWAP protocol. Alternatively, the AC could have a configured NAT'ed address, which it would include in either of the two control address message elements, and the NAT would need to be configured accordingly.
第三の構成において、ACは、NATの背後に配備されています。特定のルールは、アドレスを変換し、ACにCAPWAPメッセージをリダイレクトするために、NATに設定されていない限り、この場合には、ACは、WTPで到達可能ではありません。この展開には二つの問題を提示します。まず、ACは、CAPWAP制御IPv4アドレスとCAPWAPコントロールのIPv6アドレスメッセージ要素を使用して、そのインターフェイスおよび対応するWTP負荷を伝達します。このメッセージ要素は必須ですが、WTPで到達できないACで使用されるプライベートアドレス空間でのみ有効であるIPアドレスが含まれています。 （セクション4.6.14にCAPWAPトランスポートプロトコルのメッセージ要素で説明したように）、それはNATを検出した場合WTPは、これらのメッセージ要素内の情報を利用してはなりません。アドレスはWTPで使用することができないので、第二に、これは事実上のロードバランシング機能を無効にCAPWAPプロトコルの（6.1節を参照してください）。代替的に、ACは、2つの制御アドレスメッセージ要素のいずれかに含まれる構成NATによるアドレスを有することができ、及びNATはそれに応じて設定する必要があります。
In order for a CAPWAP WTP or AC to detect whether a middlebox is present, both the Join Request (see Section 6.1) and the Join Response (see Section 6.2) include either the CAPWAP Local IPv4 Address (see Section 4.6.11) or the CAPWAP Local IPv6 Address (see Section 4.6.12) message element. Upon receiving one of these messages, if the packet's source IP address differs from the address found in either one of these message elements, it indicates that a middlebox is present.
CAPWAP WTPまたはAC（セクション6.1を参照）の要求に参加して、応答に参加し、両方の、ミドルが存在するかどうかを検出するためには（セクション6.2を参照）CAPWAPローカルIPv4アドレス（セクション4.6.11を参照）、またはいずれかを含みますCAPWAPローカルIPv6アドレスは、メッセージの要素（セクション4.6.12を参照してください）。パケットの送信元IPアドレスが、これらのメッセージ要素のいずれかで見つかったアドレスと異なる場合、これらのメッセージのいずれかを受信すると、それがミドルボックスが存在することを示します。
In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which it received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port.
ネットワーク内の潜在的な中間装置と互換性を持つようにCAPWAPためには、CAPWAP実装は、それが与えられたピアからのトラフィックを受信したポートと同じポートからの戻りトラフィックを送信しなければなりません。さらに、CAPWAPノードによって生成された未承諾の要求は、同じポートで送信されなければなりません。
Note that this middlebox detection technique is not foolproof. If the public IP address assigned to the NAT is identical to the private IP address used by the AC, detection by the WTP would fail. This failure can lead to various protocol errors, so it is therefore necessary for deployments to ensure that the NAT's IP address is not the same as the ACs.
このミドル検出技術は誰にでもないことに注意してください。 NATに割り当てられたパブリックIPアドレスは、ACで使用されるプライベートIPアドレスと同一であれば、WTPによる検出は失敗します。この障害は、さまざまなプロトコルエラーにつながることができますので、展開がNATのIPアドレスは、ACSと同じでないことを確認することが必要があります。
The CAPWAP protocol allows for all of the AC identities supporting a group of WTPs to be communicated through the AC List message element. This feature MUST be ignored by the WTP when it detects the AC is behind a middlebox.
CAPWAPプロトコルはACリストメッセージ要素を介して通信するWTPsのグループをサポートするACアイデンティティのすべてを可能にします。それはACはミドルの背後にある検出したときに、この機能は、WTPを無視しなければなりません。
The CAPWAP protocol allows an AC to configure a static IP address on a WTP using the WTP Static IP Address Information message element. This message element SHOULD NOT be used in NAT'ed environments, unless the administrator is familiar with the internal IP addressing scheme within the WTP's private network, and does not rely on the public address seen by the AC.
CAPWAPプロトコルは、ACは、WTP静的IPアドレス情報メッセージ要素を使用してWTPに静的IPアドレスを設定することができます。このメッセージ要素は、管理者がWTPのプライベートネットワーク内の内部IPアドレス指定方式に精通している場合を除き、NATによる環境で使用すべきではない、とACで見られるパブリックアドレスに依存しません。
When a WTP detects the duplicate address condition, it generates a message to the AC, which includes the Duplicate IP Address message element. The IP address embedded within this message element is different from the public IP address seen by the AC.
WTPは、重複アドレス状態を検出すると、それが重複IPアドレス・メッセージ要素を含むACにメッセージを生成します。このメッセージ要素内に埋め込まれたIPアドレスは、ACから見たパブリックIPアドレスと異なっています。
This section describes security considerations for the CAPWAP protocol. It also provides security recommendations for protocols used in conjunction with CAPWAP.
このセクションでは、CAPWAPプロトコルのセキュリティの考慮事項について説明します。また、CAPWAPと組み合わせて使用されるプロトコルのためのセキュリティに関する推奨事項を提供します。
As it is currently specified, the CAPWAP protocol sits between the security mechanisms specified by the wireless link layer protocol (e.g., IEEE 802.11i) and Authentication, Authorization, and Accounting (AAA). One goal of CAPWAP is to bootstrap trust between the STA and WTP using a series of preestablished trust relationships:
それは現在指定されているように、CAPWAPプロトコルは無線リンク層プロトコル（例えば、IEEE 802.11i規格）、認証、許可、アカウンティング（AAA）によって指定されたセキュリティメカニズムとの間に座っています。 CAPWAPの目標の1つは、予め設定された信頼関係のシリーズを使用してSTAとWTPの間に信頼関係をブートストラップすることです：
STA WTP AC AAA
==============================================
DTLS Cred AAA Cred
<------------><------------->
EAP Credential
<------------------------------------------>
wireless link layer
(e.g., 802.11 PTK)
<--------------> or
<--------------------------->
(derived)
Figure 12: STA Session Setup
図12：STAのセッション設定
Within CAPWAP, DTLS is used to secure the link between the WTP and AC. In addition to securing control messages, it's also a link in this chain of trust for establishing link layer keys. Consequently, much rests on the security of DTLS.
CAPWAPの中で、DTLSはWTPとACとの間のリンクを保護するために使用されます。制御メッセージを確保することに加えて、それはまた、リンク層のキーを確立するための信頼のこのチェーン内のリンクです。その結果、多くはDTLSのセキュリティにかかっています。
In some CAPWAP deployment scenarios, there are two channels between the WTP and AC: the control channel, carrying CAPWAP Control messages, and the data channel, over which client data packets are tunneled between the AC and WTP. Typically, the control channel is secured by DTLS, while the data channel is not.
CAPWAP制御メッセージを運ぶ制御チャネル、およびクライアントデータパケットは、ACとWTPの間でトンネリングされた上でデータチャネル、：一部のCAPWAPの展開シナリオでは、2つのWTPとAC間のチャネルがあります。データチャネルがないが、典型的には、制御チャネルは、DTLSによって固定されています。
The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into unprotected data and attempting to convert un-protected data into protected data. These concerns are addressed below.
パラレル保護および保護されていないチャネルの使用は、特別な配慮に値するが、脅威を作成しません。保護されていないデータに保護されたデータを変換しようとすると、保護されたデータに保護されていないデータを変換しようとする2つの潜在的な懸念があります。これらの懸念は、以下のアドレス指定されます。
Since CAPWAP does not support authentication-only ciphers (i.e., all supported ciphersuites include encryption and authentication), it is not possible to convert protected data into unprotected data. Since encrypted data is (ideally) indistinguishable from random data, the probability of an encrypted packet passing for a well-formed packet is effectively zero.
CAPWAP（すなわち、すべてのサポートされている暗号スイートは、暗号化と認証を含む）認証のみ暗号をサポートしていないので、保護されていないデータに保護されたデータを変換することは不可能です。暗号化されたデータは、（理想的に）ランダムなデータと区別できないので、十分に形成されたパケットのために通過する暗号化されたパケットの確率は事実上ゼロです。
The use of message authentication makes it impossible for the attacker to forge protected records. This makes conversion of unprotected records to protected records impossible.
メッセージ認証の使用は、それは不可能、攻撃者が保護されたレコードを偽造することを可能にします。これが不可能な保護されたレコードへの保護されていないレコードの変換を行います。
An attacker could remove protected records from the stream, though not undetectably so, due the built-in reliability of the underlying CAPWAP protocol. In the worst case, the attacker would remove the same record repeatedly, resulting in a CAPWAP session timeout and restart. This is effectively a DoS attack, and could be accomplished by a man in the middle regardless of the CAPWAP protocol security mechanisms chosen.
内蔵のため、基礎となるCAPWAPプロトコルの信頼性、攻撃者は、いない検出できないのでかかわらず、ストリームから保護されたレコードを削除することができます。最悪の場合、攻撃者は、CAPWAPセッションタイムアウトと再起動で、その結果、繰り返し同じレコードを削除します。これは、効果的にDoS攻撃である、と関係なく、選択されたCAPWAPプロトコルのセキュリティメカニズムの中央に人によって達成することができます。
An attacker could inject packets into the unprotected channel, but this may become evident if sequence number desynchronization occurs as a result. Only if the attacker is a man in the middle (MITM) can packets be inserted undetectably. This is a consequence of that channel's lack of protection, and not a new threat resulting from the CAPWAP security mechanism.
攻撃者が保護されていないチャンネルにパケットを挿入できるが、シーケンス番号の非同期化が結果として発生した場合、これは明らかになることができます。攻撃者がある場合にのみ、中間（MITM）における男性はパケットが検出不可能に挿入することができます。これは、そのチャンネルの保護の欠如ではなく、CAPWAPのセキュリティ・メカニズムに起因する新たな脅威の結果です。
The Image Information message element (Section 4.6.28) makes use of MD5 to compute the hash field. The authenticity and integrity of the image file is protected by DTLS, and in this context, MD5 is not used as a cryptographically secure hash, but just as a basic checksum. Therefore, the use of MD5 is not considered a security vulnerability, and no mechanisms for algorithm agility are provided.
映像情報メッセージ要素（セクション4.6.28）は、ハッシュフィールドを計算するMD5を利用します。しかし、ただ基本的なチェックサムとして、画像ファイルの信憑性と整合性がDTLSによって保護されており、この文脈では、MD5は暗号学的に安全なハッシュとして使用されていません。したがって、MD5の使用は、セキュリティ上の脆弱性が考慮されていない、とアルゴリズムの機敏性のためのメカニズムが提供されていません。
RFC 4963 [RFC4963] describes a possible security vulnerability where a malicious entity can "corrupt" a flow by injecting fragments. By sending "high" fragments (those with offset greater than zero) with a forged source address, the attacker can deliberately cause corruption. The use of DTLS on the CAPWAP Data channel can be used to avoid this possible vulnerability.
RFC 4963 [RFC4963]は断片を注入することにより、フロー悪意のあるエンティティは、「壊れた」可能性のあるセキュリティ上の脆弱性を説明しています。偽造送信元アドレスを「高」の断片（持つものがゼロよりも大きいオフセット）を送信することにより、攻撃者は故意に破損を引き起こす可能性があります。 CAPWAPデータチャネル上DTLSの使用は、この可能性脆弱性を回避するために使用することができます。
Since DTLS does not export a unique session identifier, there can be no explicit protocol binding between the DTLS layer and CAPWAP layer. As a result, implementations MUST provide a mechanism for performing this binding. For example, an AC MUST NOT associate decrypted DTLS control packets with a particular WTP session based solely on the Session ID in the packet header. Instead, identification should be done based on which DTLS session decrypted the packet. Otherwise, one authenticated WTP could spoof another authenticated WTP by altering the Session ID in the encrypted CAPWAP Header.
DTLSは、一意のセッションIDをエクスポートしませんので、DTLS層とCAPWAP層の間の結合を明示的なプロトコルではあり得ません。結果として、実装は、この結合を行うための機構を提供しなければなりません。例えば、ACは、単にパケットヘッダのセッションIDに基づいて特定のWTPセッションで復号DTLS制御パケットを関連付けてはいけません。代わりに、識別はパケットを復号化したDTLSセッションに基づいて行われるべきです。それ以外の場合は、1つの認証されたWTPは、暗号化されたCAPWAPヘッダにセッションIDを変更することによって、別の認証されたWTPをだますことができます。
It should be noted that when the CAPWAP Data channel is unencrypted, the WTP Session ID is exposed and possibly known to adversaries and other WTPs. This would allow the forgery of the source of data-channel traffic. This, however, should not be a surprise for unencrypted data channels. When the data channel is encrypted, the Session ID is not exposed, and therefore can safely be used to associate a data and control channel. The 128-bit length of the Session ID mitigates online guessing attacks where an adversarial, authenticated WTP tries to correlate his own data channel with another WTP's control channel. Note that for encrypted data channels, the Session ID should only be used for correlation for the first packet immediately after the initial DTLS handshake. Future correlation should instead be done via identification of a packet's DTLS session.
CAPWAPデータチャネルが暗号化されていないとき、WTPセッションIDが露出し、おそらく敵や他のWTPsに知られていることに留意すべきです。これは、データ・チャネルトラフィックの送信元の偽造が可能になります。しかし、これは、暗号化されていないデータ・チャネルのために驚くべきことではありません。データチャネルが暗号化されている場合、セッションIDが露出しないので、安全にデータ及び制御チャネルを関連付けるために使用することができます。セッションIDの128ビット長が敵対オンライン推測攻撃を軽減し、WTPは別のWTPの制御チャネルに自分のデータチャネルを相関しようとする認証済み。暗号化されたデータ・チャネルのために、セッションIDのみがすぐに初期DTLSハンドシェークの後の最初のパケットの相関のために使用する必要があることに注意してください。今後の相関関係ではなく、パケットのDTLSセッションの識別を介して行われるべきです。
Since the Discovery Request messages are sent in the clear, it is important that AC implementations NOT assume that receiving a Discovery Request message from a WTP implies that the WTP has rebooted, and consequently tear down any active DTLS sessions. Discovery Request messages can easily be spoofed by malicious devices, so it is important that the AC maintain two separate sets of states for the WTP until the DTLSSessionEstablished notification is received, indicating that the WTP was authenticated. Once a new DTLS session is successfully established, any state referring to the old session can be cleared.
ディスカバリ要求メッセージは平文で送信されるので、AC実装がWTPから探索要求メッセージを受信すると、WTPが再起動したことを意味すると仮定し、その結果、任意のアクティブなDTLSセッションを切断しないことが重要です。ディスカバリ要求メッセージを容易に悪意のあるデバイスによって偽装ので、ACは、WTPが認証されたことを示す、DTLSSessionEstablished通知を受信するまでWTPに対する状態の二つの別個のセットを維持することが重要であることができます。新しいDTLSセッションが正常に確立されたら、古いセッションを参照するすべての状態をクリアすることができます。
Similarly, when the AC is entering the DTLS Setup phase, it SHOULD NOT assume that the WTP has reset, and therefore should not discard active state until the DTLS session has been successfully established. While the HelloVerifyRequest provides some protection against denial-of-service (DoS) attacks on the AC, an adversary capable of receiving packets at a valid address (or a malfunctioning or misconfigured WTP) may repeatedly attempt DTLS handshakes with the AC, potentially creating a resource shortage. If either the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations MAY choose to rate-limit new DTLS handshakes for some period of time. It is RECOMMENDED that implementations choosing to implement rate-limiting use a random discard technique, rather than mimicking the WTP's sulking behavior. This will ensure that messages from valid WTPs will have some probability of eliciting a response, even in the face of a significant DoS attack.
ACは、DTLSセットアップフェーズに入っている場合も同様に、それはWTPがリセットされたことを仮定するべきではありません、とDTLSセッションが正常に確立されるまで、したがって、アクティブ状態を捨てるべきではありません。 HelloVerifyRequestはACでサービス拒否（DoS）攻撃に対するある程度の保護を提供するが、有効なアドレス（または誤動作や誤設定WTP）でパケットを受信することができる敵を繰り返し、潜在的に作成、ACとDTLSハンドシェイクを試みることができますリソース不足。 FailedDTLSSessionCountまたはFailedDTLSAuthFailCountカウンタのいずれかがMaxFailedDTLSSessionRetry変数（4.8節を参照）の値に達した場合、実装は、ある程度の期間のための新しいDTLSハンドシェーク制限を評価するに選ぶかもしれません。実装が律速というWTPのsulkingの挙動を模倣するよりも、ランダム廃棄技法を使用を実装するために選択することが推奨されます。これは、有効なWTPsからのメッセージでも重要なDoS攻撃に直面して、応答を誘発するいくつかの可能性を持っていることを保証します。
Some CAPWAP implementations may wish to restrict the DTLS setup process to only those peers that have been configured in the access control list, authorizing only those clients to initiate a DTLS handshake. Note that the impact of this on mitigating denial-of-service attacks against the DTLS layer is minimal, because DTLS already uses client-side cookies to minimize processor consumption attacks.
いくつかのCAPWAP実装はDTLSハンドシェイクを開始するために、クライアントだけを許可、アクセス制御リストに設定されているもののみのピアにDTLSのセットアッププロセスを制限することを望むかもしれません。 DTLSがすでにプロセッサの消費攻撃を最小限に抑えるために、クライアント側のクッキーを使用しているためDTLS層に対するサービス拒否攻撃を軽減する上で、このの影響は、最小限であることに注意してください。
If a WTP or AC repeatedly receives packets that fail DTLS authentication or decryption, this could indicate a DTLS desynchronization between the AC and WTP, a link prone to undetectable bit errors, or an attacker trying to disrupt a DTLS session.
WTPまたはACを繰り返しDTLS認証や暗号解読に失敗したパケットを受信した場合、これはACとWTP、検出不可能なビットエラーを起こしやすいのリンク、またはDTLSセッションを混乱させるしようとしている攻撃者の間でDTLSの非同期化を示す可能性があります。
In the state machine (section 2.3), transitions to the DTLS Tear Down (TD) state can be triggered by frequently receiving DTLS packets with authentication or decryption errors. The threshold or technique for deciding when to move to the tear down state should be chosen carefully. Being able to easily transition to DTLS TD allows easy detection of malfunctioning devices, but allows for denial-of-service attacks. Making it difficult to transition to DTLS TD prevents denial-of-service attacks, but makes it more difficult to detect and reset a malfunctioning session. Implementers should set this policy with care.
ステートマシン（セクション2.3）で、DTLSへ遷移は取り壊す（TD）の状態が頻繁に認証または復号エラーでDTLSパケットを受信することによってトリガーすることができます。ダウン状態の涙に移動したときに決定するためのしきい値や技術は、慎重に選択する必要があります。簡単にDTLS TDに移行することが可能であることは誤動作のデバイスを容易に検出することができますが、サービス拒否攻撃が可能になります。 DTLS TDに移行することが困難になり、サービス拒否攻撃を防ぎ、それはより困難に検出し、誤動作セッションをリセットすることができます。実装者は注意して、このポリシーを設定する必要があります。
In order for CAPWAP to establish a secure communication with a peer, some level of pre-provisioning on both the WTP and AC is necessary. This section will detail the minimal number of configuration parameters.
CAPWAPピアとのセキュアな通信を確立するために、WTPとACの両方で事前プロビジョニングのいくつかのレベルが必要です。このセクションでは、意志の詳細設定パラメータの最小数。
When using pre-shared keys, it is necessary to configure the pre-shared key for each possible peer with which a DTLS session may be established. To support this mode of operation, one or more entries of the following table may be configured on either the AC or WTP:
事前共有キーを使用する場合、DTLSセッションが確立されてもよいと各可能なピアの事前共有キーを設定する必要があります。この動作モードをサポートするために、次の表の1つまたは複数のエントリは、ACまたはWTPのいずれかで構成されてもよいです。
o Identity: The identity of the peering AC or WTP. This format MAY be in the form of either an IP address or host name (the latter of which needs to be resolved to an IP address using DNS).
Oのアイデンティティ：ピアリングACまたはWTPのアイデンティティ。このフォーマットは、IPアドレスまたはホスト名（DNSを使用して、IPアドレスに解決する必要がある後者）のいずれかの形態であってもよいです。
o Key: The pre-shared key for use with the peer when establishing the DTLS session (see Section 12.6 for more information).
Oキー：DTLSセッションを確立するピアで使用する事前共有キーが（詳細については、12.6項を参照してください）。
o PSK Identity: Identity hint associated with the provisioned key (see Section 2.4.4.4 for more information).
O PSKアイデンティティ：プロビジョニングキーに関連付けられているアイデンティティのヒント（詳細については、セクション2.4.4.4を参照）。
When using certificates, the following items need to be pre-provisioned:
証明書を使用する場合、以下の項目を事前にプロビジョニングする必要があります。
o Device Certificate: The local device's certificate (see Section 12.7 for more information).
Oデバイス証明書：ローカルデバイスの証明書（詳細については、12.7節を参照してください）。
o Trust Anchor: Trusted root certificate chain used to validate any certificate received from CAPWAP peers. Note that one or more root certificates MAY be configured on a given device.
Oトラストアンカー：CAPWAPピアから受信した証明書を検証するために使用される信頼されたルート証明書チェーン。一つ以上のルート証明書が与えられたデバイス上で設定されるかもしれないことに注意してください。
Regardless of the authentication method, the following item needs to be pre-provisioned: o Access Control List: The access control list table contains the identities of one or more CAPWAP peers, along with a rule. The rule is used to determine whether communication with the peer is permitted (see Section 2.4.4.3 for more information).
かかわらず、認証方法の、以下の項目が事前にプロビジョニングする必要があります：アクセス制御リスト○：アクセスコントロールリストテーブルは、ルールと一緒に、一つ以上のCAPWAPピアのアイデンティティが含まれています。ルールは（詳細については、セクション2.4.4.3を参照）ピアとの通信が許可されるかどうかを決定するために使用されます。
While use of pre-shared keys may provide deployment and provisioning advantages not found in public-key-based deployments, it also introduces a number of operational and security concerns. In particular, because the keys must typically be entered manually, it is common for people to base them on memorable words or phrases. These are referred to as "low entropy passwords/passphrases".
事前共有キーの使用は、公開鍵ベースの展開では見られない展開とプロビジョニングの利点を提供し得るが、それはまた、運用やセキュリティの問題の数を導入しています。キーは通常、手動で入力しなければならないので、特に、人々が記憶に残る単語やフレーズにそれらをベースにするために一般的です。これらは、「低エントロピーパスワード/パスフレーズ」と呼ばれています。
Use of low-entropy pre-shared keys, coupled with the fact that the keys are often not frequently updated, tends to significantly increase exposure. For these reasons, the following recommendations are made:
キーは、多くの場合、頻繁に更新されていないという事実と相まって、低エントロピー事前共有キーの使用は、大幅にリスクを増加させる傾向があります。これらの理由から、以下の勧告が行われます。
o When DTLS is used with a pre-shared key (PSK) ciphersuite, each WTP SHOULD have a unique PSK. Since WTPs will likely be widely deployed, their physical security is not guaranteed. If PSKs are not unique for each WTP, key reuse would allow the compromise of one WTP to result in the compromise of others.
DTLSは、事前共有鍵（PSK）暗号の組み合わせで使用する場合、O、各WTPは、固有のPSKを有するべきです。 WTPsはそう広く展開されますので、その物理的なセキュリティを保証するものではありません。 PSKsは、各WTPのために一意でない場合は、キーの再利用は、1 WTPの妥協が他の妥協をもたらすことができるようになります。
o Generating PSKs from low entropy passwords is NOT RECOMMENDED.
O低エントロピーパスワードから生成PSKsはお勧めしません。
o It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a capability for generation of new random PSKs, taking RFC 4086 [RFC4086] into account.
O管理者が手動でPSKを設定することが可能な実装も考慮にRFC 4086 [RFC4086]を取って、新しいランダムPSKsを生成するための機能を提供することを推奨しています。
o Pre-shared keys SHOULD be periodically updated. Implementations MAY facilitate this by providing an administrative interface for automatic key generation and periodic update, or it MAY be accomplished manually instead.
O事前共有キーは定期的に更新する必要があります。実装は自動キー生成および定期更新の管理インターフェースを提供することによって、これを容易にすることができる、またはその代わりに、手動で行うことができます。
Every pairwise combination of WTP and AC on the network SHOULD have a unique PSK. This prevents the domino effect (see "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" [RFC4962]). If PSKs are tied to specific WTPs, then knowledge of the PSK implies a binding to a specified identity that can be authorized.
ネットワーク上のWTPとACのすべてのペアごとの組み合わせがユニークPSKを持つべきである（SHOULD）。これは、（[RFC4962]「認証、認可、アカウンティング（AAA）キー管理のためのガイダンス」を参照）ドミノ効果を防ぐことができます。 PSKsが特定WTPsに関連付けられている場合は、PSKの知識を許可することができ、指定のアイデンティティへの結合を意味します。
If PSKs are shared, this binding between device and identity is no longer possible. Compromise of one WTP can yield compromise of another WTP, violating the CAPWAP security hierarchy. Consequently, sharing keys between WTPs is NOT RECOMMENDED.
PSKsが共有されている場合は、デバイスとアイデンティティとの間の結合、このことはもはや不可能です。 1 WTPの妥協はCAPWAPセキュリティ階層に違反し、別のWTPの妥協点を得ることができます。その結果、WTPs間の共有キーは推奨されません。
For public-key-based DTLS deployments, each device SHOULD have unique credentials, with an extended key usage authorizing the device to act as either a WTP or AC. If devices do not have unique credentials, it is possible that by compromising one device, any other device using the same credential may also be considered to be compromised.
公開鍵ベースのDTLSの展開については、各デバイスは、WTPまたはACとして動作するデバイスを許可する拡張キー使用法とのユニークな資格情報を持っている必要があります。デバイスは独自の資格情報を持っていない場合、一つのデバイスを犠牲にすることによって、同じ資格情報を使用して、他のデバイスでも危険にさらされると考えてよいことがあります。
Certificate validation involves checking a large variety of things. Since the necessary things to validate are often environment-specific, many are beyond the scope of this document. In this section, we provide some basic guidance on certificate validation.
証明書の検証は、物事の多種多様なチェックが含まれます。検証するために必要なものは、多くの場合、環境固有なので、多くの人がこのドキュメントの範囲を超えています。このセクションでは、証明書の検証上のいくつかの基本的な指針を提供します。
Each device is responsible for authenticating and authorizing devices with which they communicate. Authentication entails validation of the chain of trust leading to the peer certificate, followed by the peer certificate itself. Implementations SHOULD also provide a secure method for verifying that the credential in question has not been revoked.
各デバイスは、それらが通信するデバイスを認証および認可する責任があります。認証は、ピア証明書自体に続くピア証明書に至る信頼の連鎖の検証を伴います。実装はまた、問題の資格が失効していないことを確認するための安全な方法を提供する必要があります。
Note that if the WTP relies on the AC for network connectivity (e.g., the AC is a Layer 2 switch to which the WTP is directly connected), the WTP may not be able to contact an Online Certificate Status Protocol (OCSP) server or otherwise obtain an up-to-date Certificate Revocation List (CRL) if a compromised AC doesn't explicitly permit this. This cannot be avoided, except through effective physical security and monitoring measures at the AC.
なお、WTPは、ネットワーク接続用のACに依存している場合、WTPは（OCSP）サーバーまたはその他のオンライン証明書状態プロトコルに連絡することができないかもしれない（例えば、ACは、WTPが直接接続されているレイヤ2スイッチです）妥協ACはこれを明示的に許可しない場合、最新の証明書失効リスト（CRL）を得ます。これは、ACでの効果的な物理的なセキュリティおよび監視措置を通じて除き、避けることができません。
Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real-time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD make a best-effort attempt to validate the certificate validity dates through other means. Failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation.
証明書の適切な検証は、通常、証明書がまだ有効期限が切れていないことを確認するためのチェックが必要です。デバイスは、リアルタイムクロックを持っている場合は、証明書の有効期間を確認する必要があります。何のリアルタイムクロックが利用できない場合、デバイスは、他の手段を通じて、証明書の有効期間を検証するベストエフォート型試みを行う必要があります。証明書の一時的な有効性を確認するために失敗すると、man-in-the-middle攻撃に対して脆弱性が損なわ、期限切れの証明書を使用して、そのための装置は、この検証を実行するためにあらゆる努力をするべきである進水デバイスを作ることができます。
The CAPWAP protocol is an evolution of an existing protocol [LWAPP], which is implemented on a large number of already deployed ACs and WTPs. Every one of these devices has an existing X.509 certificate, which is provisioned at the time of manufacturing. These X.509 certificates use the device's MAC address in the Common Name (CN) field. It is well understood that encoding the MAC address in the CN field is less than optimal, and using the SubjectAltName field would be preferable. However, at the time of publication, there is no URN specification that allows for the MAC address to be used in the SubjectAltName field. As such a specification is published by the IETF, future versions of the CAPWAP protocol MAY require support for the new URN scheme.
CAPWAPプロトコルが既に展開ACSおよびWTPs多数の上に実装されている既存のプロトコル[LWAPP]の進化です。これらのデバイスの一つ一つは、製造時にプロビジョニングされた既存のX.509証明書を持っています。これらのX.509証明書は、共通名（CN）フィールドに、デバイスのMACアドレスを使用します。よくCNフィールドにMACアドレスをコードする最適未満であることが理解される、とのSubjectAltNameフィールドを使用することが好ましいであろう。しかし、出版時に、のSubjectAltNameフィールドに使用されるMACアドレスを可能にするいかなるURN仕様は存在しません。そのような仕様は、IETFによって公開されているとおり、CAPWAPプロトコルの将来のバージョンは、新しいURNスキームのサポートが必要な場合があります。
The AAA protocol is used to distribute Extensible Authentication Protocol (EAP) keys to the ACs, and consequently its security is important to the overall system security. When used with Transport Layer Security (TLS) or IPsec, security guidelines specified in RFC 3539 [RFC3539] SHOULD be followed.
AAAプロトコルは、ACSに拡張認証プロトコル（EAP）キーを配布するために使用され、その結果、そのセキュリティはシステム全体のセキュリティにとって重要です。トランスポート層セキュリティ（TLS）やIPsecで使用する場合、セキュリティガイドラインは、RFC 3539 [RFC3539]で指定に従う必要がある（SHOULD）。
In general, the link between the AC and AAA server SHOULD be secured using a strong ciphersuite keyed with mutually authenticated session keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared secret authentication as it is often vulnerable to dictionary attacks, but rather SHOULD use stronger underlying security mechanisms.
一般的に、ACとAAAサーバとの間のリンクは、相互認証されたセッションキーとキー止め強い暗号スイートを使用して保護されるべきです。実装は、基本的なRADIUSのみに依存すべきではない、それは多くの場合、辞書攻撃に対して脆弱であるのではなく、より強力な基本的なセキュリティ・メカニズムを使用すべきであるとして秘密の認証を共有しました。
The CAPWAP protocol defines a mechanism by which the AC downloads new firmware to the WTP. During the session establishment process, the WTP provides information about its current firmware to the AC. The AC then decides whether the WTP's firmware needs to be updated. It is important to note that the CAPWAP specification makes the explicit assumption that the WTP is providing the correct firmware version to the AC, and is therefore not lying. Further, during the firmware download process, the CAPWAP protocol does not provide any mechanisms to recognize whether the WTP is actually storing the firmware for future use.
CAPWAPプロトコルは、ACがWTPに新しいファームウェアをダウンロードするメカニズムを定義します。セッション確立処理中に、WTPはACへの現在のファームウェアに関する情報を提供します。 ACは、WTPのファームウェアを更新する必要があるかどうかを決定します。 CAPWAP仕様はWTPがACに正しいファームウェアバージョンを提供していることを明示的な仮定を作ることに注意することが重要であり、そのために横たわっていません。さらに、ファームウェアのダウンロードプロセス中に、CAPWAPプロトコルは、WTPが実際に将来の使用のためのファームウェアを格納しているかどうかを認識するために、任意のメカニズムを提供していません。
The CAPWAP protocol assumes that it is the only configuration interface to the WTP to configure parameters that are specified in the CAPWAP specifications. While the use of a separate management protocol MAY be used for the purposes of monitoring the WTP directly, configuring the WTP through a separate management interface is not recommended. Configuring the WTP through a separate protocol, such as via a command line interface (CLI) or Simple Network Management Protocol (SNMP), could lead to the AC state being out of sync with the WTP.
CAPWAPプロトコルは、CAPWAP仕様で指定されたパラメータを設定するWTPにのみ設定インターフェースであることを前提としています。別の管理プロトコルの使用が直接WTPを監視する目的で使用することができるが、別の管理インターフェースを介してWTPを構成することは推奨されません。そのようなコマンドラインインタフェース（CLI）または簡易ネットワーク管理プロトコル（SNMP）を介してのように、別のプロトコルを介してWTPの設定、AC状態はWTPと同期してあることにつながる可能性があります。
The CAPWAP protocol does not deal with the management of the ACs. The AC is assumed to be configured through some separate management interface, which could be via a proprietary CLI, SNMP, Network Configuration Protocol (NETCONF), or some other management protocol.
CAPWAPプロトコルは、ACSの管理を扱っていません。 ACはプロプライエタリCLI、SNMP、ネットワーク構成プロトコル（NETCONF）、またはいくつかの他の管理プロトコルを介してであり得るいくつかの別の管理インターフェースを介して構成されているものとします。
The CAPWAP protocol's control channel is fairly lightweight from a traffic perspective. Once the WTP has been configured, the WTP sends periodic statistics. Further, the specification calls for a keep-alive packet to be sent on the protocol's data channel to make sure that any possible middleboxes (e.g., NAT) maintain their UDP state. The overhead associated with the control and data channel is not expected to impact network traffic. That said, the CAPWAP protocol does allow for the frequency of these packets to be modified through the DataChannelKeepAlive and StatisticsTimer (see Section 4.7.2 and Section 4.7.14, respectively).
CAPWAPプロトコルの制御チャネルは、トラフィックの観点からかなり軽量です。 WTPが設定されたら、WTPは、定期的に統計情報を送信します。さらに、仕様はすべての可能なミドルボックスは、（例えば、NATが）自分のUDPの状態を維持することを確認するために、プロトコルのデータチャネル上で送信されるキープアライブパケットを要求します。制御及びデータチャネルに関連するオーバーヘッドは、ネットワークトラフィックに影響を与えないと予想されます。これらのパケットの頻度を可能にないと述べ、CAPWAPプロトコルはDataChannelKeepAliveとStatisticsTimer（セクション4.7.2及びセクション4.7.14を参照して、それぞれ）を介して変更されます。
The CAPWAP WG carefully considered the congestion control requirements of the CAPWAP protocol, both for the CAPWAP Control and Data channels.
CAPWAP WGは慎重にCAPWAP制御およびデータチャネル用の両方、CAPWAPプロトコルの輻輳制御要件を検討しました。
CAPWAP specifies a single-threaded command/response protocol to be used on the control channel, and we have specified that an exponential back-off algorithm should be used when commands are retransmitted. When CAPWAP runs in its default mode (Local MAC), the control channel is the only CAPWAP channel.
CAPWAPは、制御チャネル上で使用されるシングルスレッドのコマンド/応答プロトコルを指定し、我々はコマンドが再送されるとき、指数バックオフアルゴリズムを使用することを指定しました。 CAPWAPがデフォルトモード（ローカルMAC）で実行すると、制御チャネルはCAPWAPチャネルです。
However, CAPWAP can also be run in Split MAC mode, in which case there will be a DTLS-encrypted data channel between each WTP and the AC. The WG discussed various options for providing congestion control on this channel. However, due to performance problems with TCP when it is run over another congestion control mechanism and the fact that the vast majority of traffic run over the CAPWAP Data channel is likely to be congestion-controlled IP traffic, the CAPWAP WG felt that specifying a congestion control mechanism for the CAPWAP Data channel would be more likely to cause problems than to resolve any.
しかし、CAPWAPは、各WTPとAC間のDTLS暗号化データチャネルが存在します、その場合には、スプリットMACモードで実行することができます。 WGはこのチャネルでの輻輳制御を提供するためのさまざまなオプションを議論しました。しかし、それは別の輻輳制御機構とCAPWAPデータチャネルを介してトラフィックの実行の大半が輻輳制御のIPトラフィックである可能性が高いという事実の上に実行されるTCPのパフォーマンスの問題のために、CAPWAP WGは、輻輳を指定していることを感じましたCAPWAPデータチャネル用制御機構は、いずれかを解決するよりも、問題を引き起こす可能性が高いだろう。
Because there is no congestion control mechanism specified for the CAPWAP Data channel, it is RECOMMENDED that non-congestion-controlled traffic not be tunneled over CAPWAP. When a significant amount of non-congestion-controlled traffic is expected to be present on a WLAN, the CAPWAP connection between the AC and the WTP for that LAN should be configured to remain in Local MAC mode with Distribution function at the WTP.
CAPWAPデータチャネル用に指定された輻輳制御機構が存在しないので、非輻輳制御トラフィックはCAPWAP上でトンネリングしないことをお勧めします。非輻輳制御トラフィックのかなりの量がWLANに存在することが予想される場合、そのLAN用のACとWTPの間のCAPWAP接続がWTPに分布関数とローカルMACモードを維持するように構成されるべきです。
The lock step nature of the CAPWAP protocol's control channel can cause the firmware download process to take some time, depending upon the round-trip time (RTT). This is not expected to be a problem since the CAPWAP protocol allows firmware to be downloaded while the WTP provides service to wireless clients/devices.
CAPWAPプロトコルの制御チャネルのロックステップ性質は、ラウンドトリップ時間（RTT）に応じて、いくつかの時間を取るために、ファームウェアのダウンロードプロセスを引き起こす可能性があります。 WTPは、無線クライアント/デバイスにサービスを提供しながら、CAPWAPプロトコルは、ファームウェアをダウンロードすることができますので、これは問題ではないと予想されます。
It is necessary for the WTP and AC to configure their MTU based on the capabilities of the path. See Section 3.5 for more information.
WTPとACパスの能力に基づいて自分のMTUを設定することが必要です。詳細については、セクション3.5を参照してください。
The CAPWAP protocol mandates support of the Explicit Congestion Notification (ECN) through a mode of operation named "limited functionality option", detailed in section 9.1.1 of [RFC3168]. Future versions of the CAPWAP protocol should consider mandating support for the "full functionality option".
[RFC3168]のセクション9.1.1で詳細「限定された機能のオプション」と名付けられた動作のモードを介して明示的輻輳通知（ECN）のCAPWAPプロトコル義務付けサポート。 CAPWAPプロトコルの将来のバージョンでは、「完全な機能オプション」のサポートを義務化を検討すべきです。
This section details the actions that IANA has taken in preparation for publication of the specification. Numerous registries have been created, and the contents, document action (see [RFC5226], and registry format are all included below. Note that in cases where bit fields are referred to, the bit numbering is left to right, where the leftmost bit is labeled as bit zero (0).
このセクションでは、IANAは、仕様書の出版の準備のためにとった行動を詳しく説明します。多数のレジストリ作成、およびコンテンツされている、ドキュメントアクションは（[RFC5226]、およびレジストリ形式はすべて以下に含まれる参照。左端のビットであり、ビットフィールドが参照される場合には、ビット番号は、左から右にされることに注意してくださいビットがゼロ（0）としてラベル。
For future registration requests where an Expert Review is required, a Designated Expert should be consulted, which is appointed by the responsible IESG Area Director. The intention is that any allocation will be accompanied by a published RFC, but given that other SDOs may want to create standards built on top of CAPWAP, a document the Designated Expert can review is also acceptable. IANA should allow for allocation of values prior to documents being approved for publication, so the Designated Expert can approve allocations once it seems clear that publication will occur. The Designated Expert will post a request to the CAPWAP WG mailing list (or a successor designated by the Area Director) for comment and review. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the CAPWAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
専門家レビューが必要とされ、将来の登録要求について、指定Expertは責任をIESGエリアディレクターによって任命され、相談する必要があります。その意図は、任意の割り当てが公開RFCを伴うが、他のSDOは、CAPWAPの上に構築された基準を作成することができますことを考えると、指定Expertが確認できる書類でも許容されるということです。出版物が発生することが明らかに思える一度指定Expertは配分を承認することができるようにIANAは、事前公表のために承認された文書への値の割り当てを可能にしなければなりません。指定ExpertはコメントとレビューのためCAPWAP WGメーリングリストへの要求（または地域ディレクターが指定する後継）を掲載します。 30日間の期間が経過する前に、指定Expertは承認または登録要求を拒否し、CAPWAP WGメーリングリストやその後継者に決定の通知を発行するだけでなく、IANAに通知しますか。拒否通知は説明によって正当化されなければならない、それが可能である場合には、許容可能となるように要求を変更することができる方法についての具体的な提案が提供されるべきです。
IANA has registered a new IPv4 multicast address called "capwap-ac" from the Internetwork Control Block IPv4 multicast address registry; see Section 3.3.
IANAは、インターネットワーク制御ブロックのIPv4マルチキャストアドレスレジストリから「CAPWAP-AC」と呼ばれる新しいIPv4マルチキャストアドレスを登録しています。 3.3節を参照してください。
IANA has registered a new organization local multicast address called the "All ACs multicast address" in the Variable Scope IPv6 multicast address registry; see Section 3.3.
IANAは、ローカルマルチキャストアドレスは、変数のスコープIPv6マルチキャストアドレスのレジストリで「すべてのACSマルチキャストアドレス」と呼ばれる新しい組織を登録しています。 3.3節を参照してください。
IANA registered two new UDP Ports, which are organization-local multicast addresses, in the registered port numbers registry; see Section 3.1. The following values have been registered:
IANAは登録されているポート番号のレジストリに、組織ローカルマルチキャストアドレスである二つの新しいUDPポートを、登録されました。 3.1節を参照してください。以下の値が登録されています：
Keyword Decimal Description References
------- ------- ----------- ----------
capwap-control 5246/udp CAPWAP Control Protocol This Document
capwap-data 5247/udp CAPWAP Data Protocol This Document
The Message Type field in the CAPWAP Header (see Section 4.5.1.1) is used to identify the operation performed by the message. There are multiple namespaces, which are identified via the first three octets of the field containing the IANA Enterprise Number [RFC5226].
CAPWAPヘッダのメッセージタイプフィールドは（セクション4.5.1.1を参照）メッセージによって動作を識別するために使用されます。 IANAエンタープライズ番号[RFC5226]を含むフィールドの最初の3つのオクテットを介して識別されている複数の名前空間があります。
IANA maintains the CAPWAP Message Types registry for all message types whose Enterprise Number is set to zero (0). The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 26 are allocated in this specification, and can be found in Section 4.5.1.1. Any new assignments of a CAPWAP Message Type whose Enterprise Number is set to zero (0) requires an Expert Review. The registry maintained by IANA has the following format:
IANAは、企業の数はゼロ（0）に設定されているすべてのメッセージタイプのためのCAPWAPメッセージタイプのレジストリを維持します。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値は1（1）26を介して、本明細書に割り当てられ、そしてセクション4.5.1.1に見出すことができます。エンタープライズ数字のゼロ（0）に設定されているCAPWAPメッセージタイプのいずれかの新しい割り当ては、専門家のレビューが必要です。 IANAによって維持され、レジストリの形式は次のとおりです。
CAPWAP Control Message Message Type Reference
Value
The Flags field in the CAPWAP Header (see Section 4.3) is 9 bits in length and is used to identify any special treatment related to the message. This specification defines bits zero (0) through five (5), while bits six (6) through eight (8) are reserved. There are currently three unused, reserved bits that are managed by IANA and whose assignment require an Expert Review. IANA created the CAPWAP Header Flags registry, whose format is:
CAPWAPヘッダ内のフラグ・フィールド（セクション4.3を参照）、長さが9ビットであり、メッセージに関連する特別な処理を識別するために使用されます。ビット6（6）は、8（8）を介しが予約されている間、本明細書では、5（5）を介してビットがゼロ（0）を定義します。その割り当てエキスパートレビューが必要でIANAによって管理されている3つの未使用、予約ビットは現在ありません。 IANAは、そのフォーマットであるCAPWAPヘッダフラグレジストリを作成しました：
Flag Field Name Bit Position Reference
フラグ・フィールド名ビット位置基準
The Flags field in the CAPWAP Control Message header (see Section 4.5.1.4) is used to identify any special treatment related to the control message. There are currently eight (8) unused, reserved bits. The assignment of these bits is managed by IANA and requires an Expert Review. IANA created the CAPWAP Control Message Flags registry, whose format is:
CAPWAP制御メッセージヘッダ内のフラグフィールドは（セクション4.5.1.4参照）の制御メッセージに関連する任意の特別な処理を識別するために使用されます。 8つの未使用、予約ビットが現在存在します。これらのビットの割り当てはIANAによって管理され、専門家のレビューを必要としています。 IANAは、そのフォーマットであるCAPWAP制御メッセージフラグレジストリを作成しました：
Flag Field Name Bit Position Reference
フラグ・フィールド名ビット位置基準
The Type field in the CAPWAP Message Element header (see Section 4.6) is used to identify the data being transported. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 53 are allocated in this specification, and can be found in Section 4.5.1.1.
CAPWAPメッセージ要素ヘッダ内のタイプフィールドは（セクション4.6を参照）に搬送されるデータを識別するために使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない16ビット（0〜65535）です。値は1（1）53を介して、本明細書に割り当てられ、そしてセクション4.5.1.1に見出すことができます。
The 16-bit namespace is further divided into blocks of addresses that are reserved for specific CAPWAP wireless bindings. The following blocks are reserved:
16ビットの名前空間は、さらに、特定のCAPWAP無線バインディングのために予約されているアドレスのブロックに分割されます。次のブロックが予約されています：
CAPWAP Protocol Message Elements 1 - 1023
IEEE 802.11 Message Elements 1024 - 2047
EPCGlobal Message Elements 3072 - 4095
This namespace is managed by IANA and assignments require an Expert Review. IANA created the CAPWAP Message Element Type registry, whose format is:
この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるCAPWAPメッセージエレメントタイプレジストリを作成しました：
CAPWAP Message Element Type Value Reference
CAPWAPメッセージ要素タイプ値リファレンス
The Wireless Binding Identifier (WBID) field in the CAPWAP Header (see Section 4.3) is used to identify the wireless technology associated with the packet. This specification allocates the values one (1) and three (3). Due to the limited address space available, a new WBID request requires Expert Review. IANA created the CAPWAP Wireless Binding Identifier registry, whose format is:
CAPWAPヘッダ（4.3節を参照）に無線結合識別子（WBID）フィールドは、パケットに関連付けられている無線技術を識別するために使用されます。この仕様は、値1を割り当てる（1）と3（3）。 、利用可能な限られたアドレス空間に、新しいWBID要求がエキスパートレビューが必要です。 IANAは、そのフォーマットであるCAPWAPワイヤレスバインディング識別子レジストリを作成しました：
CAPWAP Wireless Binding Identifier Type Value Reference
CAPWAPワイヤレスは、識別子タイプ値の参照をバインド
The Security field in the AC Descriptor message element (see Section 4.6.1) is 8 bits in length and is used to identify the authentication methods available on the AC. This specification defines bits five (5) and six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires Standards Action. IANA created the AC Security Types registry, whose format is:
AC記述子メッセージ要素におけるセキュリティフィールド（セクション4.6.1を参照）、長さが8ビットであり、ACで利用可能な認証方法を識別するために使用されます。ビットがゼロ（0）（4）4を介して、ならびにビット7つの予約済みと未使用している間、この仕様は、ビット5（5）、六（6）を定義します。これらの予約ビットは、IANAによって管理され、割り当ては標準アクションが必要です。 IANAは、そのフォーマットであるACセキュリティタイプレジストリを作成しました：
AC Security Type Bit Position Reference
ACセキュリティタイプビット位置基準
The DTLS Policy field in the AC Descriptor message element (see Section 4.6.1) is 8 bits in length and is used to identify whether the CAPWAP Data Channel is to be secured. This specification defines bits five (5) and six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires Standards Action. IANA created the AC DTLS Policy registry, whose format is:
AC記述子メッセージ要素におけるDTLSポリシーフィールド（セクション4.6.1を参照）、長さが8ビットであり、CAPWAPデータチャネルを確保すべきであるかどうかを識別するために使用されます。ビットがゼロ（0）（4）4を介して、ならびにビット7つの予約済みと未使用している間、この仕様は、ビット5（5）、六（6）を定義します。これらの予約ビットは、IANAによって管理され、割り当ては標準アクションが必要です。 IANAは、そのフォーマットであるAC DTLSポリシーレジストリを作成しました：
AC DTLS Policy Bit Position Reference
AC DTLSポリシービット位置基準
The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. This field, combined with the AC Information Vendor ID, allows vendors to use a private namespace. This specification defines the AC Information Type namespace when the AC Information Vendor ID is set to zero (0), for which the values four (4) and five (5) are allocated in this specification, and can be found in Section 4.6.1. This namespace is managed by IANA and assignments require an Expert Review. IANA created the AC Information Type registry, whose format is:
AC記述子メッセージ要素（セクション4.6.1を参照）における情報種別フィールドはACについての情報を表すために使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない16ビット（0〜65535）です。 AC情報ベンダーIDと組み合わせて、このフィールドは、ベンダーがプライベート名前空間を使用することができます。この仕様は、AC情報ベンダーIDがゼロに設定されているAC情報タイプ名前空間を定義し（0）、これに対する値4（4）及び5（5）本明細書に割り当てられ、4.6.1項に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるAC情報タイプレジストリを作成しました：
AC Information Type Type Value Reference
AC情報タイプタイプ値リファレンス
The Transport field in the CAPWAP Transport Protocol message element (see Section 4.6.14) is used to identify the transport to use for the CAPWAP Data Channel. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.14. This namespace is managed by IANA and assignments require an Expert Review. IANA created the CAPWAP Transport Protocol Types registry, whose format is:
CAPWAPトランスポートプロトコルメッセージ要素（セクション4.6.14を参照）における交通フィールドはCAPWAPデータチャネルに使用するトランスポートを識別するために使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値1は、（1）及び（2）は、2つは、本明細書に割り当てられ、そしてセクション4.6.14に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるCAPWAPトランスポートプロトコルの種類レジストリを作成しました：
CAPWAP Transport Protocol Type Type Value Reference
CAPWAPトランスポートプロトコルタイプタイプ値リファレンス
The Data Type field in the Data Transfer Data message element (see Section 4.6.15) and Image Data message element (see Section 4.6.26) is used to provide information about the data being carried. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1), two (2), and five (5) are allocated in this specification, and can be found in Section 4.6.15. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Data Transfer Type registry, whose format is:
データ転送データメッセージ要素内のデータタイプフィールドは、搬送されるデータに関する情報を提供するために使用されている画像データメッセージ要素（セクション4.6.26を参照のこと）（セクション4.6.15を参照のこと）。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値は1（1）、2つ（2）、及び5（5）は、この明細書に配置され、第4.6.15に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、その形式でのデータ転送タイプのレジストリを作成しました：
Data Transfer Type Type Value Reference
データ転送タイプのタイプ値リファレンス
The Data Mode field in the Data Transfer Data message element (see Section 4.6.15) and Data Transfer Mode message element (see Section 15.14) is used to provide information about the data being carried. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 15.14. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Data Transfer Mode registry, whose format is:
データ転送データメッセージ要素におけるデータモードフィールドは、搬送されるデータに関する情報を提供するために使用され、データ転送モードメッセージ要素（セクション15.14を参照）（セクション4.6.15を参照のこと）。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値1は、（1）及び（2）は、2つは、本明細書に割り当てられ、そしてセクション15.14に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットでデータ転送モードのレジストリを作成しました：
Data Transfer Mode Type Value Reference
データ転送モードの種類値リファレンス
The Discovery Type field in the Discovery Type message element (see Section 4.6.21) is used by the WTP to indicate to the AC how it was discovered. The namespace is 8 bits (0-255). The values zero (0) through four (4) are allocated in this specification and can be found in Section 4.6.21. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Discovery Types registry, whose format is:
ディスカバリータイプメッセージ要素（セクション4.6.21を参照）で発見Typeフィールドは、それが発見された方法をACに示すために、WTPで使用されています。名前空間は、8ビット（0〜255）です。ゼロ（0）〜4の値が（4）本明細書に割り当てられ、セクション4.6.21に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるディスカバリー・タイプのレジストリを作成しました：
Discovery Types Type Value Reference
ディスカバリー型タイプ値リファレンス
The ECN Support field in the ECN Support message element (see Section 4.6.25) is used by the WTP to represent its ECN Support. The namespace is 8 bits (0-255). The values zero (0) and one (1) are allocated in this specification, and can be found in Section 4.6.25. This namespace is managed by IANA and assignments require an Expert Review. IANA created the ECN Support registry, whose format is:
ECNサポートメッセージ要素（セクション4.6.25を参照のこと）におけるECNサポートフィールドは、ECNサポートを表すためにWTPによって使用されます。名前空間は、8ビット（0〜255）です。値がゼロ（0）と1つ（1）本明細書に割り当てられ、そしてセクション4.6.25に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるECNサポートレジストリを作成しました：
ECN Support Type Value Reference
ECNサポートタイプ値リファレンス
The Radio Admin field in the Radio Administrative State message element (see Section 4.6.33) is used by the WTP to represent the state of its radios. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.33. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Radio Admin State registry, whose format is:
無線管理状態メッセージ要素（セクション4.6.33を参照のこと）におけるラジオ管理フィールドは、その無線機の状態を表すためにWTPによって使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値1は、（1）及び（2）は、2つは、本明細書に割り当てられ、そしてセクション4.6.33に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、その形式でラジオのAdmin Stateレジストリを作成しました：
Radio Admin State Type Value Reference
ラジオのAdmin Stateタイプ値の参照
The State field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the operational state of its radios. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.34. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Radio Operational State registry, whose format is:
ラジオ操作状態メッセージ要素（セクション4.6.34を参照のこと）における状態フィールドは、その無線機の動作状態を表すためにWTPによって使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値1は、（1）及び（2）は、2つは、本明細書に割り当てられ、そしてセクション4.6.34に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、その形式でラジオオペレーショナル・ステートレジストリを作成しました：
Radio Operational State Type Value Reference
ラジオ運用状態のタイプ値の参照
The Cause field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the reason a radio may have failed. The namespace is 8 bits (0-255), where the value of zero (0) through three (3) are allocated in this specification, and can be found in Section 4.6.34. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Radio Failure Causes registry, whose format is:
ラジオ操作状態メッセージ要素（セクション4.6.34を参照のこと）における原因フィールドは、無線が失敗したかもしれない理由を表すためにWTPによって使用されます。名前空間は、8ビット（0〜255）、（3）本明細書に割り当てられ、そしてセクション4.6.34に見出すことができる値ゼロ（0）が3を介してです。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、その形式でラジオ障害の原因レジストリを作成しました：
Radio Failure Causes Type Value Reference
ラジオの障害タイプ値リファレンス原因
The Result Code field in the Result Code message element (see Section 4.6.35) is used to indicate the success or failure of a CAPWAP Control message. The namespace is 32 bits (0-4294967295), where the value of zero (0) through 22 are allocated in this specification, and can be found in Section 4.6.35. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Result Code registry, whose format is:
結果コードメッセージ要素（セクション4.6.35を参照）の結果コードフィールドは、CAPWAP制御メッセージの成功または失敗を示すために使用されます。名前空間は、22を介してゼロ（0）の値は、本明細書に割り当てられ、そしてセクション4.6.35に見出すことができる32ビット（0〜4294967295）です。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、その形式で結果コードレジストリを作成しました：
Result Code Type Value Reference
コードタイプ値リファレンス結果
The Reason field in the Returned Message Element message element (see Section 4.6.36) is used to indicate the reason why a message element was not processed successfully. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) through four (4) are allocated in this specification, and can be found in Section 4.6.36. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Returned Message Element Reason registry, whose format is:
返されたメッセージ要素のメッセージ要素（セクション4.6.36を参照）における理由フィールドは、メッセージ要素が正常に処理されなかった理由を示すために使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値は1（1）は、4つの（4）を介して、本明細書に割り当てられ、そしてセクション4.6.36に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットで返されたメッセージ要素理由レジストリを作成しました：
Returned Message Element Reason Type Value Reference
返されたメッセージ要素理由タイプ値リファレンス
The Board Data Type field in the WTP Board Data message element (see Section 4.6.40) is used to represent information about the WTP hardware. The namespace is 16 bits (0-65535). The WTP Board Data Type values zero (0) through four (4) are allocated in this specification, and can be found in Section 4.6.40. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Board Data Type registry, whose format is:
WTPボードデータメッセージ要素（セクション4.6.40を参照のこと）におけるボードデータ型フィールドがWTPハードウェアに関する情報を表すために使用されます。名前空間は、16ビット（0〜65535）です。 WTPボードデータ型がゼロ（0）〜4値（4）本明細書に割り当てられ、そしてセクション4.6.40に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるWTPボード・データ・タイプのレジストリを作成しました：
WTP Board Data Type Type Value Reference
WTPボードデータタイプタイプ値リファレンス
The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.41) is used to represent information about the WTP software. The namespace is 16 bits (0-65535). This field, combined with the Descriptor Vendor ID, allows vendors to use a private namespace. This specification defines the WTP Descriptor Type namespace when the Descriptor Vendor ID is set to zero (0), for which the values zero (0) through three (3) are allocated in this specification, and can be found in Section 4.6.41. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Board Data Type registry, whose format is:
WTPディスクリプタメッセージ要素内の記述子タイプ・フィールド（セクション4.6.41を参照のこと）WTPソフトウェアに関する情報を表すために使用されます。名前空間は、16ビット（0〜65535）です。記述子のベンダーIDと組み合わせて、このフィールドは、ベンダーがプライベート名前空間を使用することができます。ディスクリプタのベンダIDがゼロに設定されているときに、この仕様はWTPディスクリプタ型名前空間を定義し（0）、これの値はゼロ（0）が3〜（3）本明細書に割り当てられ、そしてセクション4.6.41に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるWTPボード・データ・タイプのレジストリを作成しました：
WTP Descriptor Type Type Value Reference
WTP記述子タイプタイプ値リファレンス
The Mode field in the WTP Fallback message element (see Section 4.6.42) is used to indicate the type of AC fallback mechanism the WTP should employ. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.42. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Fallback Mode registry, whose format is:
WTPフォールバック・メッセージ・エレメント（セクション4.6.42を参照のこと）におけるモードフィールドは、WTPが採用すべきACフォールバックメカニズムのタイプを示すために使用されます。名前空間は、値ゼロ（0）が予約されており、割り当てられてはならない8ビット（0〜255）です。値1は、（1）及び（2）は、2つは、本明細書に割り当てられ、そしてセクション4.6.42に見出すことができます。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるWTPフォールバックモードのレジストリを作成しました：
WTP Fallback Mode Type Value Reference
WTPフォールバックモードタイプ値リファレンス
The Tunnel Type field in the WTP Frame Tunnel Mode message element (see Section 4.6.43) is 8 bits and is used to indicate the type of tunneling to use between the WTP and the AC. This specification defines bits four (4) through six (6), while bits zero (0) through three (3) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires an Expert Review. IANA created the WTP Frame Tunnel Mode registry, whose format is:
WTPフレームトンネルモードメッセージ要素（セクション4.6.43を参照のこと）におけるトンネルタイプフィールドは8ビットであり、WTPとACとの間に使用するトンネルの種類を示すために使用されます。ビットがゼロ（0）は、3つの（3）と同様にビット7〜（7）予約済みと未使用している間、この明細書は、6（6）を介してビット4（4）を規定します。これらの予約ビットは、IANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるWTPフレームトンネルモードのレジストリを作成しました：
WTP Frame Tunnel Mode Bit Position Reference
WTPフレームトンネルモードのビット位置基準
The MAC Type field in the WTP MAC Type message element (see Section 4.6.44) is used to indicate the type of MAC to use in tunneled frames between the WTP and the AC. The namespace is 8 bits (0-255), where the value of zero (0) through two (2) are allocated in this specification, and can be found in Section 4.6.44. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP MAC Type registry, whose format is:
WTP MACタイプのメッセージ要素内のMACタイプフィールドは（セクション4.6.44を参照のこと）WTPとACとの間のトンネリングフレームで使用するMACのタイプを示すために使用されます。名前空間は、2つ（2）〜（0）の値は、本明細書に割り当てられ、そしてセクション4.6.44に見出すことができる場合、8ビット（0〜255）です。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるWTP MACタイプのレジストリを作成しました：
WTP MAC Type Type Value Reference
WTP MACタイプタイプ値リファレンス
The Last Failure Type field in the WTP Radio Statistics message element (see Section 4.6.46) is used to indicate the last WTP failure. The namespace is 8 bits (0-255), where the value of zero (0) through three (3) as well as the value 255 are allocated in this specification, and can be found in Section 4.6.46. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Radio Stats Failure Type registry, whose format is:
WTPラジオ統計メッセージ要素（セクション4.6.46を参照してください）最後のエラーの種類フィールドは、最後のWTPの失敗を示すために使用されます。名前空間は、8ビット（0〜255）であり、3つの貫通ゼロ（0）の値（3）同様に値255が本明細書に割り当てられ、そしてセクション4.6.46に見出すことができるよう。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、そのフォーマットであるWTPラジオ統計エラーの種類レジストリを作成しました：
WTP Radio Stats Failure Type Type Value Reference
WTPラジオ統計エラーの種類のタイプ値リファレンス
The Last Failure Type field in the WTP Reboot Statistics message element (see Section 4.6.47) is used to indicate the last reboot reason. The namespace is 8 bits (0-255), where the value of zero (0) through five (5) as well as the value 255 are allocated in this specification, and can be found in Section 4.6.47. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Reboot Stats Failure Type registry, whose format is:
WTPをリブート統計メッセージ要素（セクション4.6.47を参照してください）最後のエラーの種類のフィールドが最後の再起動の理由を示すために使用されます。名前空間は、8ビット（0〜255）であり、ゼロ（0）（5）5を介して、ならびに値255の値は、本明細書に割り当てられ、そしてセクション4.6.47に見出すことができる場合。この名前空間はIANAによって管理され、割り当てはエキスパートレビューが必要です。 IANAは、その形式でWTPをリブート統計エラーの種類レジストリを作成しました：
WTP Reboot Stats Failure Type Type Value Reference
WTPをリブート統計エラーの種類のタイプ値リファレンス
The following individuals are acknowledged for their contributions to this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi Eronen, Saravanan Govindan, Peter Nilsson, David Perkins, and Yong Zhang.
Puneet Agarwalさん、Abhijitチョードリー、パシEronen、Saravananゴヴィンダン、ピーター・ニルソン、デビッド・パーキンス、およびヨンジュン張：以下の個人は、このプロトコル仕様への貢献のために認められています。
Michael Vakulenko contributed text to describe how CAPWAP can be used over Layer 3 (IP/UDP) networks.
マイケルVakulenkoはCAPWAPは、レイヤ3（IP / UDP）ネットワーク上で使用することができます方法を説明するテキストを貢献しました。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、1305 RFC、1992年3月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B.、およびJ.木材、 "認証、認可およびアカウンティング（AAA）のトランスポート・プロファイル"、RFC 3539、2003年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、ピンク、S.、ヨンソン、L-E。、およびG. Fairhurst、 "軽量ユーザーデータグラムプロトコル（UDP-Liteの）"、RFC 3828、2004年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279] Eronen、P.とH. Tschofenig、RFC 4279 "トランスポート層セキュリティ（TLS）のための事前共有鍵暗号の組み合わせ"、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963] Heffner、J.、マティス、M.、およびB.チャンドラー、 "高速データレートでのIPv4の再構築エラー"、RFC 4963、2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[ISO.9834-1.1993] International Organization for Standardization, "Procedures for the operation of OSI registration authorities - part 1: general procedures", ISO Standard 9834-1, 1993.
[ISO.9834-1.1993]国際標準化機構、「OSI登録局の動作のための手順 - パート1：一般的な手順」、ISO規格9834から1、1993。
[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5416]カルフーン、P.、エド。、モンテムッロ、M.、エド。、およびD.スタンレー、エド。、 "コントロールおよびワイヤレスアクセスのプロビジョニングポイント（CAPWAP）IEEE 802.11のためのプロトコルバインディング"、RFC 5416、2009年3月。
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option", RFC 5417, March 2009.
[RFC5417]カルフーン、P.、 "コントロールおよびワイヤレスアクセスポイント（CAPWAP）アクセスコントローラDHCPオプションのプロビジョニング"、RFC 5417、2009月。
[FRAME-EXT] IEEE, "IEEE Standard 802.3as-2006", 2005.
[FRAME-EXT] IEEE、 "IEEE標準802.3as-2006"、2005年。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]レイノルズ、J.、 "番号が割り当てられ：RFC 1700は、オンラインデータベースで置き換えられる"、RFC 3232、2002年1月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC4564]ゴヴィンダン、S.、チェン、H.、八尾、ZH。、周、WH。、およびL.ヤン、RFC 4564、2006年7月 "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のための目標"。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley氏、R。およびB. Aboba、 "認証、許可、アカウンティング（AAA）キー管理のための指針"、BCP 132、RFC 4962、2007年7月。
[LWAPP] Calhoun, P., O'Hara, B., Suri, R., Cam Winget, N., Kelly, S., Williams, M., and S. Hares, "Lightweight Access Point Protocol", Work in Progress, March 2007.
【LWAPP]カルフーン、P.、オハラ、B.、スリ、R.、カムウィンゲット、N.、ケリー、S.、ウィリアムズ、M.、およびS.野兎、 "Lightweightアクセスポイントプロトコル" は、で働きます進歩、2007年3月。
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP: Secure Light Access Point Protocol", Work in Progress, May 2005.
[SLAPP] Narasimhan、P.、ハーキンズ、D.、およびS. Ponnuswamy、 "SLAPP：ライトアクセスポイントプロトコルセキュア"、進歩、2005年5月に作業を。
[DTLS-DESIGN] Modadugu, et al., N., "The Design and Implementation of Datagram TLS", Feb 2004.
[DTLS-DESIGN]らModadugu、。、2004年2月、N.、 "データグラムTLSの設計と実装"。
[EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique Identifier", Dec 2005.
、2005年12月[EUI-48] IEEE、 "48ビット拡張一意識別子の使用のためのガイドライン"。
[EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY".
[EUI-64] IEEE、 "64ビットのグローバル識別子（EUI-64）登録機関のためのガイドライン"。
[EPCGlobal] "See http://www.epcglobalinc.org/home".
[EPCグローバル] "http://www.epcglobalinc.org/homeを参照してください"。
[PacketCable] "PacketCable Security Specification PKT-SP-SEC-I12-050812", August 2005, <PacketCable>.
[PacketCableの] "PacketCableのセキュリティ仕様PKT-SP-SEC-I12-050812"、2005年8月、<PacketCableの>。
[CableLabs] "OpenCable System Security Specification OC-SP-SEC-I07-061031", October 2006, <CableLabs>.
[CableLabsの] "オープンケーブルシステム・セキュリティ仕様OC-SP-SEC-I07-061031"、2006年10月、<CableLabsの>。
[WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved Specification V1.0.1", April 2008, <WiMAX>.
[WiMAXの] "WiMAXフォーラムX.509デバイス証明書プロファイル承認仕様V1.0.1"、2008年4月、<WiMAXの>。
[RFC5418] Kelly, S. and C. Clancy, "Control And Provisioning for Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments", RFC 5418, March 2009.
[RFC5418]ケリー、S.とC.クランシー、 "IEEE 802.11の展開のための無線アクセスポイント（CAPWAP）脅威の分析のための管理とプロビジョニング"、RFC 5418、2009月。
Editors' Addresses
エディタのアドレス
Pat R. Calhoun (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
パットR.カルフーン（エディタ）は、シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
Phone: +1 408-902-3240 EMail: pcalhoun@cisco.com
電話：+1 408-902-3240電子メール：pcalhoun@cisco.com
Michael P. Montemurro (editor) Research In Motion 5090 Commerce Blvd Mississauga, ON L4W 5M4 Canada
L4W 5M4カナダONマイケル・P.モンテムッロ（エディタ）モーション5090コマースブルバードミシソーガの研究、
Phone: +1 905-629-4746 x4999 EMail: mmontemurro@rim.com
電話：+1 905-629-4746 x4999メール：mmontemurro@rim.com
Dorothy Stanley (editor) Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
ドロシー・スタンレー（エディタ）アルバネットワークス1322クロスマンアベニューサニーベール、CA 94089
Phone: +1 630-363-1389 EMail: dstanley@arubanetworks.com
電話：+1 630-363-1389電子メール：dstanley@arubanetworks.com