[要約] RFC 5415は、無線アクセスポイントの制御とプロビジョニングを行うためのCAPWAPプロトコルの仕様書です。このRFCの目的は、異なるベンダーのアクセスポイントを統一的に管理するためのプロトコルを提供することです。
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
ワイヤレスアクセスポイント（CAPWAP）プロトコル仕様の制御とプロビジョニング
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
この仕様は、RFC 4564のCAPWAPワーキンググループによって定義された目的を満たしているワイヤレスアクセスポイント（CAPWAP）プロトコルの制御とプロビジョニングを定義します。CapWapプロトコルは、さまざまなワイヤレステクノロジーに使用できるように設計されています。このドキュメントでは、Base 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].
このドキュメントでは、アクセスコントローラー（AC）がワイヤレス終了ポイント（WTPS）のコレクションを管理できるようにする標準の相互運用可能なプロトコルである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には、ワイヤレス媒体と有線媒体を接続するという主要なタスクに関連する一連の動的管理および制御機能が必要です。WTPを管理するための従来のプロトコルは、HTTP、独自のレイヤー2固有の、または存在しない（WTPが自己完結型である場合）を介した手動静的構成です。IEEE 802.11バインディングは[RFC5416]で定義されており、IEEE 802.11 WLANネットワークを使用したCapWapプロトコルの使用をサポートしています。
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は、インターネットプロトコル（IP）を介してACに通信する複数のWTPで構成されるネットワーク構成を想定しています。WTPは、ACによって制御されるリモート無線周波数（RF）インターフェイスと見なされます。CAPWAPプロトコルは、スプリットマックとローカルMAC（ミディアムアクセス制御）の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：スプリットマックの代表的な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をプロビジョニングし、どのWTPがサービスを提供することを許可されているかを管理することは、従来、独自のソリューションによって処理されます。これらの機能を集中型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.
2. WTPからの高レベルプロトコル処理のシフトを有効にするため。これにより、WTPでのワイヤレス制御とアクセスの時間的に批判的なアプリケーションが残り、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.
CAPWAPプロトコルは、WTPとACの間のインターフェースのみに関係しています。Inter-ACおよびStation-to-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プロトコル仕様の基礎として使用される軽量アクセスポイントプロトコル（LWAPP）[LWAPP]を選択しました。次の人はLWAPP文書の著者です。
Bob O'Hara Email: bob.ohara@computer.org
ボブ・オハラメール：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
パットカルホーン、Cisco Systems、Inc。170 West Tasman Drive、San Jose、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 Suri、Cisco Systems、Inc。170 West Tasman Drive、San Jose、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
Nancy Cam Winget、Cisco Systems、Inc。170 West Tasman Drive、San Jose、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クロスマンアベニュー、サニーベール、カリフォルニア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
Michael Glenn Williams、Nokia、Inc。313 Fairchild Drive、Mountain View、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
Sue Hares、Green Hills Software 825 Victors Way、Suite 100、Ann Arbor、MI 48108電話：1 734 222 1610、電子メール：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クロスマンアベニュー、サニーベール、カリフォルニア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
Eric Rescorla、Network Resonance 2483 El Camino Real、＃212、Palo Alto CA、94303メール：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:
DTLSを使用してCapWapプロトコルを保護するという概念は、安全なライトアクセスポイントプロトコル（SLAPP）提案[SLAPP]の一部でした。次の人々は、SLAPP提案の著者です。
Partha Narasimhan, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-480-4716 Email: partha@arubanetworks.com
Partha Narasimhan、Aruba Networks 1322 Crossman Ave、Sunnyvale、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
Dan Harkins Trapeze Networks 5753 W. Las Positas Blvd、プレザント、CA 94588電話：1-925-474-2212メール：dharkins@trpz.com
Subbu Ponnuswamy, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-1213 Email: subbu@arubanetworks.com
Subbu Ponnuswamy、Aruba Networks 1322 Crossman Ave、Sunnyvale、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グリーンミードドライブ、カレッジパーク、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クロスマンアベニュー、カリフォルニア州サニーベール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.
Access Controller（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制御チャネル：AC IPアドレス、WTP IPアドレス、ACコントロールポート、WTP制御ポート、およびCAPWAP制御パケットが送信および受信される輸送層プロトコル（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データチャネル：AC IPアドレス、WTP IPアドレス、ACデータポート、WTPデータポート、およびCAPWAPデータパケットが送信および受信されるトランスポートレイヤープロトコル（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コントロールメッセージ、およびオプションでは、データグラムトランスポートレイヤーセキュリティ（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プロトコルトランスポートレイヤーには、2種類のペイロード、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セッションを確立するためのACを選択します。安全な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の間に送信されるワイヤレスデータフレームをカプセル化します。カプセル化されたワイヤレスユーザーデータ（データ）またはプロトコル制御（管理）フレームのサイズが、結果のCAPWAPプロトコルパケットがWTPとACの間でサポートされるMTUを超えると、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と通信しているステーションの管理のために、ACからWTPへのコマンドの配信を提供します。これには、ステーションの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.
1. WTPイベントリクエストメッセージに含まれるバインディング固有の統計メッセージ要素の定義。
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. 発見、主要な発見、および結合リクエストと応答のメッセージに掲載された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で詳しく説明しています。DTLは、特定のメッセージを単一のフレームに集約できるようにすることに注意してください。これは、図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 --)
（ - 実行状態を入力 - ）
: :
：：：
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.
Illustrated 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セッションのライフサイクルを表しています。CAPWAPプロトコルによるDTLを使用すると、2つの名目上分離されているが密接に結合した状態マシンが並置されます。DTLSおよびCAPWAP状態マシンは、コマンド（セクション2.3.2.1を参照）と通知（セクション2.3.2.2を参照）で構成されるAPIを介して結合されます。DTLS状態マシンの特定の遷移は、CAPWAP状態マシンからのコマンドによってトリガーされますが、CAPWAP状態マシンの特定の遷移は、DTLS状態マシンからの通知によってトリガーされます。
/-------------------------------------\
| /-------------------------\|
| 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状態マシンの単一インスタンスのみがあります。州のマシンは、多くのWTPと通信するため、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ごとの状態を処理し、1つのスレッドが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 Stateマシンを起動します。
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はDiscoveryIntervalタイマーを設定します（セクション4.7を参照）。WTPは、DiscoveryCountカウンターをゼロ（0）にリセットします（セクション4.8を参照）。また、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.
IDLE（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変数に等しい場合、WTPはこの状態に入ります（セクション4.8を参照）。この状態に入ると、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.
Sulking to Idle（@）：この遷移は、発見フェーズを再起動する必要がある場合に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：WTPは、SilentIntervalタイマー（セクション4.7を参照）が期限切れになったときにこの状態に入ります。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 to 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は、選択したACでDTLSセッション確立を開始し、WaitDTLSタイマーを開始するDTLSセッションの確立を開始するDTLSSTARTコマンド（セクション2.3.2.1を参照）を呼び出してこの遷移を開始します（セクション4.7を参照）。発見フェーズがバイパスされると、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は、選択したACでDTLSセッションの確立を開始するDTLSSTARTコマンド（セクション2.3.2.1を参照）を呼び出すことにより、この遷移を開始します。どの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：WTPは、DTLSからDTLSESTABLISHFAIL通知を受け取ったときにこの状態の遷移を開始し（セクション2.3.2.2を参照）、失敗したDTLSSSESSIONCOUNTまたはFAILEDDTLSAUTHFAILCOUNTカウンターは、MaxFailedDTLSSessionreTryRetryRetryの値に達していません（セクション4.8を参照）。このエラー通知は、安全な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カウンターがMaxFailedDTLSSessessessessretry変数の値に達すると、この状態に入ります（セクション4.8を参照）。この状態に入ると、WTPはSilentIntervalタイマーを起動する必要があります。Sulking Stateでは、受信したすべての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：ACのリスナーは、DTLSからDTLSESTABLISHFAIL通知を受信したときにこの状態遷移を開始します（セクション2.3.2.2を参照）。このエラー通知は、安全なDTLSセッションの確立を中止します。この通知が受信されると、FailedDtlsSessionCountカウントカウンターが増加します。リスナースレッドは、DTLSListenコマンドを呼び出します（セクション2.3.2.1を参照）。
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がDTLSpeerauthorize通知を受信したときに発生します（セクション2.3.2.2を参照）。この状態に入ると、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：この状態遷移は、DTLSモジュールがDTLSpeerauthorize通知を開始するときにACのリスナースレッドによって処理されます（セクション2.3.2.2を参照）。リスナースレッドは、State Contextのコピーとともに、サービススレッドのインスタンスを分岐します。作成されると、サービススレッドは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セットアップ（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コンテキストとサービススレッドを作成したときに発生します。リスナースレッドは、DTLSListenコマンドを呼び出します（セクション2.3.2.1を参照）。
Authorize to DTLS Connect (a): This transition occurs to notify the DTLS stack that the session should be established.
DTLS Connect（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 Teardown（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：この状態遷移は、AC資格情報を使用してWTPが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 Teardown（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がDTLSABORTEDまたはDTLSAUTHENTICEALFAIL通知のいずれかを受信したときに発生します（セクション2.3.2.2を参照）。DTLSセッションが正常に確立されなかったことを示します。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またはDTLSAUTHENTICEEFAIL通知のいずれかを受信したときに発生します（セクション2.3.2.2を参照）。DTLSセッションが正常に確立されておらず、FailedDTLSauthFailCountとFailedDTLSSessionCountsの両方がMAXFAILEDDTLSSSSSSESSESSESTRSSTLSの価値に達していないことを示しています。変数（セクション4.8を参照）。この状態の遷移は、WaitDTLSタイマーの有効期限が切れた場合にも発生します。ACはDTLSSessionDeleteタイマーを開始します（セクション4.7.6を参照）。
DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established.
DTLS Connect to Join（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 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.
WTP：この状態遷移は、WTPがDTLSESTABLED通知を受信したときに発生します（セクション2.3.2.2を参照）。DTLSセッションが正常に確立されたことを示します。この通知を受信すると、FailedDtlsSessionCountカウントカウンターがゼロに設定されます。WTPは、ACに結合要求を送信することにより、結合状態に入ります。WTPはWaitDTLSタイマーを停止します。
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がDTLSESTABLED通知を受信したときに発生します（セクション2.3.2.2を参照）。DTLSセッションが正常に確立されたことを示します。この通知を受信すると、FailedDtlsSessionCountカウントカウンターがゼロに設定されます。ACはwaitdtlsタイマーを停止し、waitjoinタイマーを開始します。
Join to DTLS Teardown (e): This transition occurs when the join process has failed.
DTLS Teardown（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がエラーを含む結果コードメッセージ要素を使用して結合応答メッセージを受信したとき、またはJoin ResponseメッセージでACによって提供された画像識別子がWTPの現在実行中のファームウェアバージョンとは異なり、WTPが持っている場合に発生します。その非揮発性メモリに要求された画像。これにより、WTPはDTLSShutdownコマンドを開始します（セクション2.3.2.1を参照）。この遷移は、WTPが次のDTLS通知のいずれかを受信した場合にも発生します：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT。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：この状態の遷移は、待機ジーインタイマーの有効期限が切れる場合、またはACがエラーを含む結果コードメッセージ要素を使用して結合応答メッセージを送信する場合に発生します。これにより、ACはDTLSShutdownコマンドを開始します（セクション2.3.2.1を参照）。この遷移は、ACが次のDTLS通知のいずれかを受信した場合にも発生します：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT。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.
Image Data（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 Section 4.7), and transmits the Image Data Request message (see Section 9.1.1) requesting the start of the firmware download.
WTP：WTPは、成功したJoin Responseメッセージを受信すると画像データ状態に入り、画像識別子メッセージ要素のソフトウェアバージョンが現在実行中の画像と同じではないと判断します。また、WTPは、WTPの不揮発性ストレージで現在使用できていないことを要求された画像バージョンが現在利用できないことも検出します（ファームウェアのダウンロードプロセスの完全な説明については、セクション9.1を参照）。WTPは、エコーインターバルタイマー（セクション4.7を参照）を初期化し、ファームウェアのダウンロードの開始を要求する画像データ要求メッセージ（セクション9.1.1を参照）を送信します。
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は、ファームウェアの一部を含む画像データ応答メッセージ（セクション9.1.2を参照）をWTPに送信する必要があります。
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は、成功した結合応答メッセージを受信するときにConfigure状態に入り、含まれている画像識別子メッセージ要素が現在実行中の画像と同じであると判断します。WTPは、現在の構成を説明するメッセージ要素を使用して、構成ステータス要求メッセージ（セクション8.2を参照）をACに送信します。
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から構成ステータス要求メッセージを受信すると発生します（セクション8.2を参照）。これには、WTPの構成をオーバーライドする特定のメッセージ要素が含まれる場合があります。ACはWaitJoinタイマーを停止します。ACは、構成ステータス応答メッセージ（セクション8.3を参照）を送信し、shangestatependingTimerタイマー（セクション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は、ACポリシーがWTPがサービスを提供することを許可しないエラーを含むWTPから変更状態イベントメッセージを受信するときにリセット状態に移行します。この状態の遷移は、Ac changestatependingTimerタイマーの有効期限が切れたときにも発生します。
Configure to DTLS Teardown (i): This transition occurs when the configuration process aborts due to a DTLS error.
DTLS Teardown（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).
WTP：WTPは、次のDTLS通知のいずれかを受信すると、この状態に入ります：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT（セクション2.3.2.2を参照）。WTPは、頻繁にDTLSDECAPFAILURE通知を受信した場合、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).
AC：ACは、次のDTLS通知のいずれかを受け取ると、この状態に入ります：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT（セクション2.3.2.2を参照）。ACは、頻繁にDTLSDecapFailure通知を受信した場合、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：WTPは、ACに送信するデータが増えることを示す画像データ応答メッセージを受信すると、画像データ状態に入ります。この状態の遷移は、WTPが後続の画像データ要求を受信したときにも発生します。その時点で、ImagedatastAstartimer時間をリセットして、ACから次の予想される画像データ要求を受信するようにします。この状態の遷移は、WTPのエコーインターバルタイマー（セクション4.7.7を参照）の有効期限が切れたときにも発生する可能性があります。この場合、WTPはエコー要求メッセージを送信し（セクション7.1を参照）、エコーインターバルタイマーをリセットします。状態遷移は、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がWTPからエコー要求（セクション7.1を参照）を受信した場合にも発生します。この場合、エコー応答（セクション7.2を参照）で応答し、エコーインターバルタイマー（セクション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 Teardown（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).
WTP：WTPは、次のDTLS通知のいずれかを受信すると、この状態に入ります：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT（セクション2.3.2.2を参照）。WTPは、頻繁にDTLSDECAPFAILURE通知を受信した場合、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).
AC：ACは、次のDTLS通知のいずれかを受け取ると、この状態に入ります：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT（セクション2.3.2.2を参照）。ACは、頻繁にDTLSDecapFailure通知を受信した場合、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：WTPは、ACから成功した構成ステータス応答メッセージを受信するとこの状態に入ります。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タイマーを起動し、shangestatependingTimerタイマーを停止する必要があります（セクション4.7を参照）。
Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange.
DTLS TERWODS（N）へのデータチェック：この遷移は、WTPがデータチェック交換を完了しないときに発生します。
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が変更状態イベント応答メッセージを受信しない場合、この状態遷移が発生します。また、基礎となる信頼できるトランスポートの再送信カウントカウンターがMaxretransmit変数に到達した場合、WTPはこの状態にも移行します（セクション4.7を参照）。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：ACは、Datachecktimerタイマーが期限切れになるとこの状態に入ります（セクション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.
実行するデータチェック（o）：この状態遷移は、制御チャネルとデータチャネルの間のリンクが確立されたときに発生し、WTPとACが通常の動作状態に入ります。
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：WTPは、ACから変更された状態イベント応答メッセージを成功させると、この状態に入ります。WTPは、DTLSセッションの確立が必要になる場合があるデータチャネルを開始し、データチャネルキーパー型タイマーを開始し（セクション4.7.2を参照）、データチャネルキープアリブパケットを送信します（セクション4.4.1を参照）。WTPは、エコーインターバルタイマーとDatachannelDeadeadIntervalタイマーを開始します（セクション4.7を参照）。
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がデータチャネルのキープアライブパケットを受信したときに発生します（セクション4.4.1を参照）。ACはDatachecktimerタイマーを無効にします。ACポリシーがデータチャネルの暗号化を要求する場合、このプロセスにはデータチャネルDTLSセッションの確立が必要であることに注意してください。Data Channel Keep-Aliveパケットを受信すると、ACは独自のデータチャネルKeep Aliveパケットを送信します。
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 Teardown（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).
WTP：WTPは、次のDTLS通知のいずれかを受信すると、この状態に入ります：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT（セクション2.3.2.2を参照）。WTPは、頻繁にDTLSDECAPFAILURE通知を受信した場合、DTLSセッションを取り壊す可能性があります。また、基礎となる信頼できるトランスポートの再送信カウントカウンターがMaxretransmit変数に到達した場合、WTPはこの状態にも移行します（セクション4.7を参照）。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).
AC：ACは、次のDTLS通知のいずれかを受け取ると、この状態に入ります：DTLSABORTED、DTLSREASSEMBLYFAILURE、またはDTLSPEERDISCONNECT（セクション2.3.2.2を参照）。ACは、頻繁にDTLSDecapFailure通知を受信した場合、DTLSセッションを取り壊す可能性があります。基礎となる信頼できる輸送の再送信カウントカウンターがMaxretransmit変数に到達した場合、ACはこの状態に移行します（セクション4.7を参照）。この状態の遷移は、ACのエコーインターバルタイマー（セクション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にリクエストを送信するたびに、エコーインターバルタイマーをリセットします。この状態の移行につながる多くのイベントがあります。
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).
構成更新：WTPは、構成更新リクエストメッセージを受信します（セクション8.4を参照）。WTPは、構成更新応答メッセージで応答する必要があります（セクション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を参照）。
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.
CLEAR設定要求：WTPはクリア構成要求メッセージ（セクション8.8を参照）を受信し、対応するクリア構成応答メッセージを生成する必要があります（セクション8.9を参照）。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はWTPイベント要求メッセージを送信し、ACに情報を配信します（セクション9.4を参照）。WTPは、ACからWTPイベント応答メッセージを受信します（セクション9.5を参照）。
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の通常の動作状態です。WTPからのリクエストの受領により、ACはエコーインターバルタイマーをリセットすることに注意してください（セクション4.7.7を参照）。
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.
構成更新：ACは、構成の更新メッセージ（セクション8.4を参照）をWTPに送信して、構成を更新します。ACは、WTPから構成更新応答メッセージ（セクション8.5を参照）を受信します。
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を参照）を受信します。
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はエコーリクエストメッセージ（セクション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からWTPイベント要求メッセージを受信し（セクション9.4を参照）、対応する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 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.
データ転送：ACは、データ転送要求またはデータ転送応答メッセージをWTPに送信します（セクション9.6を参照）。ACは、WTPからデータ転送要求またはデータ転送応答メッセージを受信します（セクション9.6を参照）。データ転送要求を受け取ると、ACは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は、ステーション構成要求メッセージ（セクション10.1を参照）を送信するか、WTPから対応するステーション構成応答メッセージ（セクション10.2を参照）を受信します。
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：WTPは、ACからリセットリクエストメッセージを受信するとリセット状態に入ります。
AC: The AC enters the Reset state when it transmits a Reset Request message to the WTP.
AC：ACは、リセットリクエストメッセージをWTPに送信すると、リセット状態に入ります。
Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete to terminate the DTLS session.
DTLS Teardown（S）にリセット：この遷移は、DTLSセッションを終了するためにCapWapリセットが完了したときに発生します。
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はDTLSShutdownコマンドを呼び出しません（セクション2.3.2.1を参照）。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がリセット応答メッセージを受信したときに発生します。これにより、ACはDTLSShutdownコマンドを開始します（セクション2.3.2.1を参照）。ACはDTLSSessionDeleteタイマーを開始します（セクション4.7.6を参照）。
DTLS Teardown to Idle (t): This transition occurs when the DTLS session has been shut down.
IDLE（T）へのDTLS分解：この移行は、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.
DTLS Sulking（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カウンターがMaxFailedDTLSSessessessessretry変数の値に達すると、この状態に入ります（セクション4.8を参照）。この状態に入ると、WTPはSilentIntervalタイマーを起動する必要があります。Sulking Stateでは、受信したすべての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 Dead（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コマンドと、DTLSからCAPWAPプロトコルスタックへの通知について説明します。
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.
DTLS APIへのCapWapに対して6つのコマンドが定義されています。これらの「コマンド」は概念的であり、1つ以上の関数呼び出しとして実装される場合があります。このAPI定義は、統合されたCAPWAP状態マシンのDTLと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はCAPWAPコンポーネントによって送信され、DTLSコンポーネントが使用するMTUサイズを変更します。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通知は、DTLS to CapWap APIに対して定義されています。これらの「通知」は概念的であり、さまざまな方法で実装される場合があります（たとえば、関数の戻り値として）。このAPI定義は、統合されたCAPWAP状態マシンのDTLとCAPWAPコンポーネント間の相互作用を明確にするために提供されます。以下にリストされている通知により、CAPWAP状態マシンは、セクション2.3.1にリストされていない状態遷移を使用して、ある状態から別の状態にジャンプする可能性があることに注意することが重要です。以下にリストされている通知が発生すると、図4に示すターゲットキャップワップ状態が現在の状態になります。
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コンポーネントに送信されます。この通知は、PeerのIDに基づいて、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 DTLSESTABLEDISHEDは、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.
o DTLSESTABLISHFAILは、DTLSセッションの確立が失敗したときに送信されます。この通知が受信されると、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.
o DTLSAuthenticateFailは、認証エラーのためにDTLSセッションの確立が失敗したときに送信されます。この通知が受信されると、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が要求する）が完了したことを示します。これは、DTLSセッションが中止されたことを確認するため、またはwaitdtlsタイマーが期限切れになったときに発生します。この通知が受信されると、waitdtlsタイマーが停止します。
o DTLSReassemblyFailure MAY be sent to the CAPWAP component to indicate DTLS fragment reassembly failure.
o DTLSREASSEMBLYFAILUREをCAPWAPコンポーネントに送信して、DTLSフラグメントの再組み立て障害を示すことができます。
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がCAPWAPコンポーネントに送信され、DTLSセッションが取り壊されていることを示します。この通知は、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）と「通知」（dtls to capwap）を介して、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 Auth状態で発生します）
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished ------>
(AC callout for WTP authorization occurs in CAPWAP Auth state)
（WTP認証のためのACコールアウトは、CAPWAP認証状態で発生します）
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実装は、異なるポート番号の使用にもかかわらず、CAPWAPモジュールがセッション再開を要求できるようにするインターフェイスを提供する必要があります（TLS実装は通常、接続する場合にのみセッション再開を試みます同じ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はDTLSSTARTコマンドを使用して、選択したACに安全な接続を確立するように要求します。DTLSハンドシェイクを開始する前に、WTPはWaitDTLSタイマーを設定します。DTLSSTARTまたはDTLSLISTENコマンドを呼び出すと、それぞれWTPとACがWAITDTLSタイマーを設定します。タイマーの有効期限の前にDTLSESTABLED通知が受信されない場合、DTLSセッションはDTLSABORTSESSION DTLSコマンドを発行することにより中止されます。この通知により、CAPWAPモジュールはアイドル状態に移行します。DTLSESTABLED通知を受信すると、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仕様はメッセージを再送信することを呼び出します。握手中に、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.
Cookieが検証に失敗した場合、これはWTPエラーを表すか、DOS攻撃を表す可能性があります。したがって、ACリソースの使用率を最小限に抑える必要があります。ACは、障害を示すメッセージをログに記録し、メッセージをCookieが存在しないかのように扱う必要があります。
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コンポーネントは、DTLSREASSEMBLYFAILURE通知をCAPWAPコンポーネントに送信する必要があります。通知とともに正確な情報が提供されるかどうかは実装の問題であり、したがって、このドキュメントの範囲を超えています。このようなエラーを受け取ると、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.
現在、定義されているカプセル化エラーは1つだけです。MTUを超えています。DTLSセッションの確立の一環として、CapWapコンポーネントはMTUサイズのDTLSコンポーネントを通知します。これは、CAPWAPコンポーネントがDTLSMTUUPDATEコマンドをDTLSコンポーネントに送信するときにいつでも動的に変更できます（セクション2.3.2.1を参照）。DTLSスタックに提供される値は、セクション3.5で説明されているMTU発見プロセスの結果です。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で使用することをお勧めする暗号スイートのみを使用しています。[DTLS-Design]を参照してください。現在、CAPWAP認証に証明書を使用する場合、次のアルゴリズムをサポートする必要があります。
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] The following algorithms SHOULD be supported when using certificates:
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]証明書を使用する場合、次のアルゴリズムをサポートする必要があります。
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 Pre -Shared Key（PSK）キーエクスチェンジアルゴリズム - 最も単純な方法、Ciphersuitesは対称キーアルゴリズムのみを使用します。
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キーエクスチェンジアルゴリズム - PSKを使用して、Diffie -Hellman Exchangeを認証します。これらのciphersuitesは、辞書攻撃に対する追加の保護を提供し、完全な前方秘密（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）は、受動的な辞書攻撃の影響を受けやすいです。したがって、このアルゴリズムをサポートする必要がありますが、その方法を選択する際には特別な注意を払う必要があります。特に、ユーザー読み取り可能なパスフレーズを使用しないでください。短いPSKの使用は強く落胆する必要があります。
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とWTPによる証明書の承認が必要で、ACのみがACの関数を実行し、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値を定義します。1つはWTP用、もう1つはAC用です。これら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デバイスは、証明書に存在する場合は、拡張キーセージ証明書延長をサポートする必要があります。拡張機能が存在する場合、証明書にはID-KP-CAPWAPACまたはACとして機能するID-KP-AnyextededKeyUsage keypurposeIdのいずれかが必要です。同様に、拡張機能が存在する場合、デバイスにはID-KP-CAPWAPWTPまたはID-KP-AnyextededKeyUsage keypurposeIdが必要です。
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.
MACアドレスは、01：23：45：67：89：ABのよく知られているMACアドレス形式を使用して、PrintAblestring形式でエンコードする必要があります。CNフィールドには、EUI-48 [EUI-48]またはEUI-64 [EUI-64] MACアドレス形式のいずれかを含めることができます。CNフィールドのこの一見型破りな使用は、パケットケーブル[パケット可能]、ケーブルラボ[ケイブルレラブ]、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アドレス、または組織情報に基づいて、たとえば接続しているデバイスの証明書を許可する必要があります（たとえば、アクセス制御リストを介して）。証明書で指定されたアイデンティティは、特定のDTLSセッションを相互に認証された特定のMACアドレスの特定のペアに結合します。承認フィルター構築の詳細は、ほとんどの場合、この仕様の範囲内ではない実装の詳細です。ただし、少なくともすべてのデバイスは、適切なEKUビットがピアデバイス（AC対WTP）の役割に応じて設定されていること、および証明書の発行者が問題のドメインに適していることを確認する必要があります。
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 CipherSuitesを使用する場合、ServerKeyExchangeメッセージには「PSK IDヒント」フィールドが含まれている必要があり、Client KeyExchangeメッセージには「PSK ID」フィールドが含まれている必要があります。これらのフィールドは、WTPがACで使用するための適切なPSKを選択し、ACに使用されているキーをACに示すために使用されます。PSKがWTPSおよびACSにプロビジョニングされる場合、キーのPSKヒントとPSK IDの両方を指定する必要があります。
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のIDは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.
CAPWAPネットワーク上の複数のデバイスに単一のPSKが推奨されない場合、PSKヒントとIDはもはやMACアドレスではないため、適切なヒントとIDを選択するために、適切なヒントとIDを選択する必要があります。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を使用しますが、CapWapデータチャネルはUDPまたはUDP-Liteを使用できます。UDP-Liteは、CAPWAPデータチャネルのデフォルトのトランスポートプロトコルです。ただし、MiddleboxまたはIPv4からIPv6 Gatewayが発見されている場合、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 Transport Protocolメッセージ要素であるセクション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.
WTPからACに送信されたCAPWAPプロトコル制御パケットは、セクション1.4で定義されているように、CAPWAP制御チャネルを使用します。ACのCAPWAP制御ポートは、よく知られているUDPポート5246です。WTPのCapWap Controlポートは、WTPによって選択された任意のポートになります。
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.
WTPからACに送信されたCAPWAPプロトコルデータパケットは、セクション1.4で定義されているように、CAPWAPデータチャネルを使用します。ACのCAPWAPデータポートはよく知られているUDPポート5247です。ACが管理者にCapWap Controlポートの変更を許可する場合、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の使用と比較して）。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はどのACSが利用可能かを決定し、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との通信を確立しようとすると、Discovery Requestメッセージが送信され、AC（S）からDiscovery Responseメッセージが受信されます。WTPは、発見要求メッセージを、限られたブロードキャストIPアドレス（255.255.255.255）、よく知られているCapWapマルチキャストアドレス（224.0.1.140）、またはACのユニキャストIPアドレスのいずれかに送信する必要があります。IPv6ネットワークの場合、ブロードキャストは存在しないため、代わりに「すべてのACSマルチキャストアドレス」（FF0x：0：0：0：0：0：18c）の使用が使用されます。Discovery Requestメッセージを受信すると、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.
WTP限られたIPブロードキャスト、マルチキャスト、またはユニキャストIPアドレスの使用は実装に依存します。一方、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: DHCP: See [RFC5417] for more information on the use of DHCP to discover AC IP addresses.
WTPがディスカバリーリクエストメッセージをユニキャストアドレスに送信する場合、WTPは最初にACのIPアドレスを取得する必要があります。WTPの不揮発性ストレージ上のACのIPアドレスの静的構成は、実装に依存します。ただし、たとえば、追加の動的スキームが可能です。DHCP：AC IPアドレスを発見するためのDHCPの使用に関する詳細については、[RFC5417]を参照してください。
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は、DNSサービスレコード（SRVS）[RFC2782]の使用をサポートしてACアドレス（ES）を発見できます。この場合、WTPは最初に正しいドメイン名の接尾辞（「Example.com」など）を最初に取得し、サービス名「CapWap-Control」およびProto "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は、AC IPv4リスト（セクション4.6.2を参照）およびAC IPv6リスト（セクション4.6.2を参照）を介して、ディスカバリー応答メッセージ内のWTPに代替ACSを通知する場合があります。これら2つのメッセージ要素で提供されるアドレスは、上記の手段以外の手段を通じてWTPが追加のACを発見するのを支援することを目的としています。
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.
優先メッセージ要素を持つAC名（セクション4.6.5を参照）は、優先ACSのリストをWTPに通信するために使用されます。WTPは、ACが提供する順序でリストされているACSを利用しようとする必要があります。名前からIPへのアドレスマッピングは、Discovery Message Exchangeを介して処理され、ACSはAC名（セクション4.6.4を参照）でIDを提供します（セクション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、および「Middlebox」デバイスが含まれます。これは、可能なDOS攻撃を最小限に抑えるためにIPフラグメントをドロップする傾向があります。アプリケーション層で断片化と再組み立てを提供することにより、CapWapプロトコルのトンネリングコンポーネントが原因で必要な断片化は、これらの中間デバイスに対して透明になります。したがって、CapWapプロトコルは、ファイアウォール、NAT、およびMiddleboxデバイスなどのネットワークトポロジで使用できます。
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を参照）は、フィールドのラッピングを引き起こす可能性があり、したがって、異なるデータグラムのフラグメントが誤ってスプライシングされます（「誤関連」として知られています）。たとえば、1500のMTUとの100MPBSリンク（1450バイトでフラグメンテーションを引き起こす）は、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を参照）。これにより、断片化の必要性を回避できます。この仕様の執筆時点で、ほとんどのエンタープライズスイッチングおよびルーティングインフラストラクチャは、「ミニジャンボ」フレーム（1800バイト）をサポートすることができ、断片化の必要性を排除します（ステーションのMTUが1500バイトであると仮定）。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セッションを確立したいACを発見したら、PATH MTU（PMTU）発見を実行する必要があります。PMTU発見を実行するための推奨事項の1つは、WTP送信ディスカバリーリクエスト（セクション5.1を参照）メッセージを提供し、MTUディスカバリーパディングメッセージ要素（セクション4.6.32を参照）を含めることです。PMTU発見に使用される実際の手順は、IPv4の[RFC1191]で説明されています。IPv6の場合、[RFC1981]を使用する必要があります。あるいは、実装者は[RFC4821]で定義されている手順を使用する場合があります。また、WTPは、MTUディスカバリーパディングメッセージ要素（セクション4.6.32を参照）とともに、主要な発見要求（セクション5.3を参照）を使用して、これら2つのRFCで提供されるガイドラインを使用してPMTUを定期的に再評価する必要があります。MTUが最初に既知の場合、または既存のセッションが既に存在する場合に更新された場合、発見されたPMTUを使用してDTLSコンポーネントを構成します（セクション2.3.2.1を参照）、非DTLSフレームはMTUに適合するために断片化する必要があります、セクション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プロトコルパケットは、1つ以上のCAPWAPトランスポートレイヤーパケットヘッダーに続いてCAPWAPメッセージが続きます。CAPWAPメッセージは、制御パケットが信号を運ぶタイプコントロールまたはデータのいずれかで、データパケットにユーザーのペイロードがあります。CapWapデータパケットのCapWapフレーム形式、およびDTLSのカプセル化された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 Controlプロトコルには、DTLSによって保護されない2つのメッセージが含まれています。DiscoveryリクエストメッセージとDiscovery Responseメッセージです。これらのメッセージは、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プロトコルは、DTLを使用して、データパケットのオプションの保護を可能にします。データパケット保護の使用は、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ヘッダー：すべてのCAPWAPパケットは、IPv6を介して使用する場合、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ヘッダー：すべてのDTLS暗号化されたCAPWAPプロトコルパケットには、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 Preambleまたは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 Controlパケットには、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の実装は、最大メッセージの長さメッセージ要素を含めることにより、より高い最大メッセージ長をサポートすることを示している場合があります。
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 Preambleは、すべての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スタックはパケットをClear Text CapWapデータパケットとして扱う必要があります。CapWap Control Channelで受信した場合、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ビットには、Common CapWap Preambleが含まれます。残りの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 Preamble：CapWap Preambleはセクション4.1で定義されています。CapWap Preambleのペイロードタイプフィールドは、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コントロールまたは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 Preamble：CapWap Preambleはセクション4.1で定義されています。CapWap Preambleのペイロードタイプフィールドは、ゼロ（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：4バイトの単語（IPヘッダーの長さと同様）でCapWap Transport Headerの長さを含む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ビットフィールド。その値は1つ（1）と31の間にあります。MACアドレスがWTPの物理ラジオ全体で必ずしも一意ではないことを考えると、無線識別子（RID）フィールドメッセージが関連付けられている物理無線を示すために使用されます。
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- epcglobal [epcglobal]
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つの場合、パケットはフラグメントであり、他の対応するフラグメントと組み合わせて、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つの値は、オプションのヘッダーが存在するという事実を表すために使用されます。
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：Radio Mac 'M'ビットは、Radio 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バイトのアラインがない場合はゼロ（0x00）でパディングする必要があります。
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バイトのアラインがない場合はゼロ（0x00）でパディングする必要があります。
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 Controlメッセージのヘッダーが含まれ、その後にメッセージに含まれるデータが含まれます。
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 Data Channel Keep-Aliveパケットとデータペイロードパケットの2つの異なるタイプがあります。1つ目は、WTPが制御チャネルとデータチャネルを同期させ、データチャネルの新鮮さを維持するために使用されます。2番目は、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 Data Channel Keep-Aliveパケットは、CapWap Control Channelをデータチャネルにバインドし、データチャネルの新鮮さを維持し、チャネルがまだ機能していることを確認するために使用されます。CapWap Data Channel Keep-Aliveパケットは、DataChannelKeePaliveタイマーの有効期限が切れると、WTPによって送信されます（セクション4.7.2を参照）。CapWap Data Channel Keep-Aliveパケットが送信されると、WTPはDataChannelDeadeadIntervalタイマーを設定します。
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 Data Channel Keep-Aliveパケットでは、HLENフィールドと「K」ビットを除くCapWapヘッダーのすべてのフィールドが、伝送時にゼロに設定されています。CapWap Data Channel Keep-Aliveパケットを受信すると、ACはCapWap Data Channel Keep-AliveパケットをWTPに送信します。送信されたパケットの内容は、受信したパケットの内容と同じです。
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 Data Channel Keep-Aliveパケットを受信すると、WTPはDataChannelDeadedIntervalタイマーをキャンセルし、DatachannelKeepaliveタイマーをリセットします。CapWap Data Channel Keep-Aliveパケットは、CapWap Controlメッセージと同じ方法でWTPによって再送信されます。DataChannelDeadedIntervalタイマーが期限切れになった場合、WTPはコントロールDTLSセッションを引き裂き、データDTLSセッションが存在した場合はDTLSセッションを裂けます。
The CAPWAP Data Channel Keep-Alive packet contains the following payload immediately following the CAPWAP Header (see Section 4.3).
CapWap Data Channel Keep-Aliveパケットには、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ビットの長さフィールドは、CapWapヘッダーに続くバイト数を示し、最大サイズは65535です。
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]：メッセージ要素は、各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プロトコルデータペイロードパケットは、転送されたワイヤレスフレームをカプセル化します。CAPWAPプロトコルは、カプセル化の2つの異なるモードを定義します：IEEE 802.3とネイティブワイヤレス。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フレームがカプセル化されています（IEEE 802.3プリアンブル、開始フレームデリミッター（SFD）、およびフレームチェックシーケンス（FCS）フィールドを除く）。カプセル化されたフレームが輸送層のMTUを超える場合、セクション3.4で指定されているように、送信者はフレームの断片化に責任を負います。CAPWAPプロトコルは、IEEE 802.3フレームをサポートできます。その長さはIEEE 802.3AS仕様[Frame-Ext]で定義されています。
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を再認証して再承認する必要がないようにするには、TLSセッション再開機能[RFC5246]を使用してDTLSデータチャネルを開始する必要があります。
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 Discoveryメッセージは、潜在的な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 Joinメッセージは、WTPがACからサービスを要求するために使用され、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構成メッセージは、ACがWTPに特定の構成を配信するために使用されます。WTPから統計を取得するメッセージは、WTP構成管理にも含まれています。
Station Session Management: Station Session Management messages are used by the AC to deliver specific station policies to the WTP.
ステーションセッション管理：ステーションセッション管理メッセージは、ACがWTPに特定のステーションポリシーを提供するために使用されます。
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管理メッセージ：このカテゴリのメッセージは、ACとWTPによってプロトコル固有のCAPWAP管理メッセージを交換するために使用されます。これらのメッセージは、ステーションのリンク状態を変更するために使用される場合と使用できない場合があります。
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 Controlメッセージを実装する必要があります。デバイス管理操作メッセージが実装される場合があります。
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.
WTPからACに送信された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コントロールメッセージは、CAPWAPヘッダー内でカプセル化されて送信されます（セクション4.3を参照）。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 Controlメッセージの関数を識別します。拡張性を提供するために、メッセージタイプフィールドは、IANAエンタープライズ番号[RFC3232]とエンタープライズ固有のメッセージタイプ番号で構成されています。最初の3つのオクテットには、ネットワークバイトの順序でIANAエンタープライズ番号が含まれており、ゼロはcapWapベースプロトコル（この仕様）が定義されたメッセージタイプに使用されます。最後のオクテットは、エンタープライズ固有のメッセージタイプ番号で、0〜255の範囲です。
The Message Type field is defined as:
メッセージタイプフィールドは次のように定義されています。
Message Type = IANA Enterprise Number * 256 + Enterprise Specific Message Type Number
メッセージタイプ= IANAエンタープライズ番号 * 256エンタープライズ固有のメッセージタイプ番号
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 Controlメッセージタイプの値の割り当ては、常にペアで発生します。すべてのリクエストメッセージには奇数のメッセージタイプ値があり、すべての応答メッセージにはメッセージタイプの値が偶数あります。リクエスト値を最初に割り当てる必要があります。例として、リクエストメッセージに対してメッセージタイプ値を3、応答メッセージに4の割り当ては有効です。また、応答メッセージにメッセージタイプ値4を割り当て、対応するリクエストメッセージに5を割り当てることは無効です。
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 Controlメッセージが送信されると、送信者の内部シーケンス番号カウンターが単調に増加し、2つの保留中のリクエストメッセージが同じシーケンス番号を持たないようにします。シーケンス番号フィールドはゼロに戻ります。
The Length field indicates the number of bytes following the Sequence Number field.
長さフィールドは、シーケンス番号フィールドに続くバイト数を示します。
The Flags field MUST be set to zero.
フラグフィールドはゼロに設定する必要があります。
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.
メッセージ要素には、各コントロールメッセージタイプに関連する情報が含まれています。この仕様のすべてのコントロールメッセージは、許可されているメッセージ要素を指定します。
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つ以上の返されたメッセージ要素要素を示す結果コードメッセージ要素を含む対応する応答メッセージが含まれています。認識されていないメッセージ要素。
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バインディング仕様は、QOSのCAPWAPデータメッセージへの適用を定義する必要があります。
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機能の2つのレベルというレベルの完全な機能と限られた機能について説明しています。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:
適切なサービス品質の優先順位値を使用して、ACとWTPの両方からCAPWAP制御メッセージを送信し、ネットワーク内の輻輳がCAPWAP制御チャネルの発生を最小限に抑えることを保証することをお勧めします。したがって、QOS対応のCAPWAPデバイスは、次の値を使用する必要があります。
802.1Q: The priority tag of 7 SHOULD be used.
802.1Q：7の優先タグを使用する必要があります。
DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which is described in [RFC2474]).
DSCP：[RFC2474]で説明されているCS6 PERホップ行動サービスクラスを使用する必要があります。
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.
実装は、最後に受信したリクエストメッセージのシーケンス番号を追跡する必要があり、対応する応答メッセージをキャッシュする必要があります。同じシーケンス番号を使用した再送信を受信した場合、要求を再処理することなく、キャッシュされた応答メッセージを再送信する必要があります。古い要求メッセージが受信された場合、つまりシーケンス番号が小さくなっている場合は無視する必要があります。シーケンス番号が大きいものを意味する新しい要求メッセージは、通常どおり処理されます。
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および（S2-S1）<128）または（S1> S2および（S1-S2）> 128）の場合のみ、S1がS2 Modulo 256よりも小さい場合、シーケンス番号は「小さい」と見なされます。
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の両方は、いつでも1つのリクエストのみを発行することができます。再送信要求メッセージは、送信者によって変更されてはなりません。
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.
リクエストメッセージを送信した後、retransmitinterval（セクション4.7を参照）タイマーとmaxretransmit（セクション4.8を参照）変数を使用して、元のリクエストメッセージを再送信する必要があるかどうかを判断します。RecransmitIntervalタイマーは、リクエストが最初に再送信されるときに使用されます。その後、タイマーはその後の時間ごとに2倍になり、同じ要求メッセージが再送信され、MaxRetRansmitまではエコーインターバルタイマーの半分以下になります（セクション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への移行が発生します。ただし、送信者が新しいまたは変更されたリクエストメッセージとの接続を継続することを決定した場合、新しいメッセージには新しいシーケンス番号が必要であり、受信者による新しいリクエストメッセージとして扱われる必要があります。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スタックによるリプレイとして識別されないことを確認する必要があります。同様に、再送信リクエストメッセージが受信された結果として再送信されるキャッシュされた応答メッセージは、DTLを介して再暗号化する必要があります。
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).
特に指定されていない限り、ACからWTPに送信された構成情報は、詳細については不揮発性ストレージ（セクション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ビット型フィールドは、値フィールドに掲載される情報を識別し、長さ（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
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
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
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
タイプ：AC記述子の場合
Length: >= 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：ACに現在接続されているWTPSの数
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：ACは、セクション12.6で説明されているように、事前に共有された秘密認証をサポートします。
X: The AC supports X.509 Certificate authentication, as described in Section 12.7.
X：ACは、セクション12.7で説明されているように、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 Transport Headerのオプションのラジオ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によって伝達されるオプションの1つを順守する必要があります。フィールドには次の形式があります。
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形式でのAC情報のベンダー固有のエンコーディング[RFC3629]。次の列挙値がサポートされています。ハードウェアバージョンとソフトウェアバージョンの両方のサブエレメントは、AC記述子メッセージ要素に含める必要があります。以下にリストされている値は、AC情報ベンダー識別子フィールドと組み合わせて使用され、その値はゼロ（0）に設定する必要があります。このフィールドは、ゼロ以外の（0）値に設定されたAC情報ベンダー識別子と組み合わせて、ベンダーがプライベートネームスペースを使用できるようにします。
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情報の長さ：最大サイズの1024のAC情報のベンダー固有のエンコードの長さ。
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が参加できる最新のACSリストを使用して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
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が参加できる最新のACSリストを使用して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リストの3
Length: >= 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 IDのUTF-8 [RFC3629]表現が含まれています。値は、可変長バイト文字列です。文字列はゼロ終端ではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Type: 4 for AC Name
タイプ：AC名の4
Length: >= 1
Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC's name, whose maximum size MUST NOT exceed 512 bytes.
名前：ACの名前を含む可変長UTF-8エンコード文字列[RFC3629]。最大サイズは512バイトを超えてはなりません。
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名は、ACによってWTPに送信され、優先ACSを構成します。このメッセージ要素のインスタンスの数は、WTPで構成されたACSの数に等しくなります。また、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
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の値。たとえば、1つの値の値を使用してプライマリACを設定し、2つの値はセカンダリなどを設定するために使用されます。
AC Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC name, whose maximum size MUST NOT exceed 512 bytes.
AC名：AC名を含む可変長UTF-8エンコード文字列[RFC3629]。最大サイズは512バイトを超えてはなりません。
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
タイプ：ACタイムスタンプ用6
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の現在の時刻。すべてのWTPが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.
Add Mac Access Control List（ACL）エントリメッセージ要素は、ACによって使用されてWTPにMac ACLリストエントリを追加し、WTPがメッセージに記載されているMacアドレスにサービスを提供しなくなるようにします。このメッセージ要素で提供されるMACアドレスは、WTPの不揮発性メモリに保存されるとは予想されていません。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: 7 for Add MAC ACL Entry
タイプ：Mac ACLエントリを追加するには7
Length: >= 8
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This value MUST NOT exceed 255.
エントリの数：アレイ内の長さ/MACアドレスフィールドのインスタンスの数。この値は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アドレス：ACLに追加するMACアドレス。
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.
ADDステーションメッセージ要素は、ACがWTPにステーションのトラフィックを転送する必要があることを通知するために使用されます。ADDステーションメッセージ要素には、セキュリティパラメーターが含まれる場合がある技術固有のバインディング情報要素が伴います。したがって、セキュリティパラメーターは、ステーションの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.
ADDステーションメッセージ要素を介してステーションポリシーがWTPに配信された後、ACは変更されたADDステーションメッセージ要素を送信することにより、ポリシーを変更する場合があります。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
タイプ：追加ステーションを追加します
Length: >= 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 Control IPv4アドレスメッセージ要素は、発見プロセス中にACによってWTPに送信され、ACによってACで利用可能なインターフェイスと現在のWTPの数を提供するために使用されます。複数の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 Control 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カウント：現在インターフェイスに接続されているWTPの数、最大値は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 Control IPv6アドレスメッセージ要素は、発見プロセス中にACによってWTPに送信され、ACでACで利用可能なインターフェイスと現在のWTPの数を提供するために使用されます。このメッセージ要素は、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 Control 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カウント：現在インターフェイスに接続されているWTPの数、最大値は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アドレスメッセージ要素は、Join RequestでWTP、またはJOIN応答で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アドレスメッセージ要素は、Join Requestで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
タイプ：50 capwapローカルIPv6アドレスの場合
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タイマーメッセージ要素は、ACによってWTPでCapWapタイマーを構成するために使用されます。
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
タイプ：CapWapタイマー用12
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).
発見：WTPが発見フェーズにある場合のCapWap Discoveryメッセージの間の秒数。この値は、MaxDiscoveryIntervalタイマーの構成に使用されます（セクション4.7.10を参照）。
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メッセージの間の秒数。この値は、エコーインターバルタイマーの構成に使用されます（セクション4.7.7を参照）。ACは、エコーインターバルタイマーをこの値に設定し、セクション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トランスポートプロトコルメッセージ要素は、WTPまたはACのいずれかで使用され、CAPWAPデータチャネルに使用する輸送プロトコルを信号します。
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).
結合リクエストを受信すると、ACはIPv6を介してCapWapメッセージが受信され、CAPWAPローカルIPv6アドレスメッセージ要素（セクション4.6.12を参照）が存在する場合、結合応答メッセージでCapWap Transport ProtocolをUDP-Liteに設定する場合があり、ミドルボックスは検出されませんでした（セクション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はCAPWAP Transport ProtocolをConfiguration Status RequestまたはImage Data RequestメッセージでUDP-Liteに設定することができます。ACがUDP-Liteのサポートを宣伝した場合、メッセージはIPv6を介して受信されました。メッセージ要素（セクション4.6.12を参照）とミドルボックスは検出されませんでした（セクション11を参照）。構成ステータスリクエストまたは画像データ要求のいずれかを受信すると、ACは、ACが結合応答で宣伝したものと一致している限り、CAPWAPトランスポートプロトコルのWTPで示される好みを観察する必要があります。
For any other condition, the CAPWAP Transport Protocol MUST be set to UDP.
他の条件については、CapWap Transport ProtocolをUDPに設定する必要があります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
Type: 51 for CAPWAP Transport Protocol
タイプ：51 CapWap Transport Protocolの場合
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 Transport Protocolは、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.
データ転送データメッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Mode | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ....
+-+-+-+-+-+-+-+-+
Type: 13 for Data Transfer Data
タイプ：データ転送データについては13
Length: >= 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.
データ：WTPからACに転送されるデータは、データモードフィールドを介してタイプが識別されます。
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.
データ転送モードメッセージ要素は、WTPによって使用され、デバッグ目的でACに送信しているデータ転送情報のタイプを示します。
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.
復号化エラーレポートメッセージ要素値は、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 |Num Of Entries | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report
タイプ：復号化エラーレポートの場合は15
Length: >= 9
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31.
無線ID：無線識別子は、WTPのインターフェイスインデックスを指します。WTPの値は1（1）から31の間です。
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.
エントリの数：アレイ内の長さ/MACアドレスフィールドのインスタンスの数。このフィールドは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.
復号化エラーレポート期間メッセージ要素値は、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 | 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：無線識別子は、WTPのインターフェイスインデックスを指します。WTPの値は1（1）から31の間です。
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エントリメッセージ要素は、ACによってWTPのMac ACLエントリを削除するために使用され、WTPがメッセージに提供されているMacアドレスにサービスを提供するようにします。
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
タイプ：17 Mac ACLエントリを削除します
Length: >= 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.
長さ：> = 8エントリの数：配列内の長さ/Macアドレスフィールドのインスタンスの数。このフィールドは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アドレス：ACLから削除するためのMacアドレスの配列。
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.
削除ステーションメッセージ要素は、ACがWTPに特定のステーションにサービスを提供しなくなってはならないことを通知するために使用されます。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.
削除ステーションメッセージ要素の送信は、管理上の理由を含め、さまざまな理由で発生する可能性があります。
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.
削除ステーションメッセージ要素は、WTPイベントリクエストメッセージでWTPによって送信され、特定のステーションがもはや提供されていないことをACに通知できます。これは、内部リソース不足のため、または他の理由により、アイドルタイムアウトの結果として発生する可能性があります（セクション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
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.
Discovery Typeメッセージ要素は、WTPによって使用され、Discoveryリクエストメッセージを送信しているACの存在についてどのように知るようになったかを示します。
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
2 -DHCP
3 - DNS
3 -DNS
4 - AC Referral (used when the AC was configured either through the AC IPv4 List or AC IPv6 List message element)
4 -AC紹介（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によって使用されて、WTPが現在使用しているのと同じIPアドレスを使用して別のIPデバイスを検出したことをACに通知します。
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に設定してこのメッセージ要素を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
タイプ：21重複するIPv4アドレスの場合
Length: >= 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に設定する必要があります。
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によって使用されて、WTPが現在使用しているのと同じIPアドレスを使用して別のホストを検出したことをACに通知します。
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に設定してこのメッセージ要素を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
タイプ：22 IPv6アドレスを重複しています
Length: >= 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に設定する必要があります。
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.
アイドルタイムアウトメッセージ要素は、ACによってWTPに送信され、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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].
[RFC3168]で定義されているように、ECNサポートメッセージ要素はWTPとACの両方によって送信され、ACの両方が明示的な輻輳通知（ECN）ビットに対するサポートを示すことを示します。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ECN Support |
+-+-+-+-+-+-+-+-+
Type: 53 for ECN Support
タイプ：ECNサポート用53
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
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文字が含まれており、その長さはこのメッセージ要素の長さフィールドから推測されます。送信されるブロックが最後のものである場合、データ型フィールドは2に設定されます。ACは、データ型フィールドを5に設定してデータ転送を中止することを選択できます。データ型フィールドが5の場合、値フィールドにはaがあります。ゼロの長さ。
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.
画像識別子メッセージ要素は、ACによってWTPに送信され、WTPで実行される予想アクティブソフトウェアバージョンを示します。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
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.
画像情報メッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
ファイルサイズ：ACによってWTPに転送されるファイルのサイズをバイト単位で含む32ビット値。
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.
eatiateのダウンロードメッセージ要素は、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]です（例：「Fridgeの隣」）。この情報は、ネットワーク管理者によって構成可能であり、WTPの場所を決定できます。文字列はゼロ終端ではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| Location ...
+-+-+-+-+-+-+-+-+-
Type: 28 for Location Data
タイプ：ロケーションデータの28
Length: >= 1
Location: A non-zero-terminated UTF-8 encoded string [RFC3629] containing the WTP location, whose maximum size MUST NOT exceed 1024.
場所：WTPの位置を含むゼロターミネートされていないUTF-8エンコード文字列[RFC3629]。最大サイズは1024を超えてはなりません。
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のJoin Requestメッセージに含まれています。最大メッセージの長さメッセージ要素は、ACによるJoin Responseメッセージにオプションで含まれており、WTPをサポートする最大CAPWAPメッセージの長さを示します。
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
タイプ：最大メッセージ長の場合
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.
PAD：値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
タイプ：無線管理状態の場合
Length: 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.
長さ：2ラジオ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:
管理状態：無線の管理状態を表す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.
ラジオの動作状態メッセージ要素は、WTPによってACに送信され、ラジオの運用状態を通信します。このメッセージ要素は、無線管理状態のメッセージ要素を介して、無線の状態を変更するように要求された場合、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：無線識別子は、WTPの値が1つ（1）と31の間にあるWTPのインターフェイスインデックスを指します。WTPの動作状態を変更することはできないため、0xffの値は無効です。
State: An 8-bit Boolean value representing the state of the radio. The following enumerated values are supported: 0 - Reserved
状態：無線の状態を表す8ビットのブール値。次の列挙値がサポートされています：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) 6 Join Failure (Incorrect Data)
5参加障害（不明なソース）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.
返されたメッセージ要素は、Change Stateイベントリクエストメッセージの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Length | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for Returned Message Element
タイプ：返されたメッセージ要素の場合は34
Length: >= 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
タイプ：セッションIDの35
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.
Statistics Timerメッセージ要素値は、ACによって使用され、WTPに更新された統計を受信すると予想される頻度を通知します。
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 Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC3232].
長さ：> = 7ベンダー識別子：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ボードデータメッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for WTP Board Data
タイプ：WTPボードデータの38
Length: >=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.
ベンダー識別子：WTPハードウェアメーカーを識別するIANAが割り当てられた「SMIネットワーク管理プライベートエンタープライズコード」を含む32ビット値。ベンダー識別子フィールドをゼロに設定してはなりません。
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 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.
長さ：> = 33最大ラジオ：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バイトの暗号化サブエレメントの数。num暗号フィールドの値は、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でサポートされている各バインディングに1つのサブ要素が存在します。暗号化サブエレメントには、次の形式があります。
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ビットフィールド。識別子は、無線に関連付けられたワイヤレスパケットのタイプを示します。この仕様で定義されているWBIDは、セクション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ビットフィールドは、WTPによってその機能をACに通信するために使用されます。暗号化機能を持たない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:
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フォールバックメッセージ要素は、ACによってWTPに送信され、WTPが現在接続されていない優先ACを検出した場合に自動CapWapフォールバックを有効または無効にします。
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での自動キャップワップフォールバックのステータスを示します。有効にすると、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フレームトンネルモードでは、WTPとACがネイティブIEEE 802.3フレームとしてすべてのユーザーペイロードをカプセル化する必要があります（セクション4.4を参照）。すべてのユーザートラフィックが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 Length: 1
タイプ：WTPの場合44 MACタイプ長：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は、すべてのWTPでサポートする必要があるデフォルトモードです。トンネリングが有効になっている場合（セクション4.6.43を参照）、カプセル化されたフレームは、ネイティブ形式にある可能性のあるワイヤレス管理または制御フレームがない限り、802.3形式（セクション4.4.2を参照）でなければなりません。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とSplit 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
タイプ：WTP名の45
Length: >= 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名：最大サイズが512バイトを超えてはならないWTP名を含む、ゼロターミネートされていないUTF-8エンコード文字列[RFC3629]。
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が開始された、リンク、SW、またはHW障害以外の既知の理由により、ACとのCAPWAPプロトコル接続が失敗した回数。
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アドレス情報メッセージメッセージ要素は、ACによって使用され、WTPで以前に構成された静的IPアドレスを構成またはクリアするために使用されます。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
タイプ：WTP静的IPアドレス情報の49
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.
静的：WTPが静的IPアドレスを使用するかどうかを示す8ビットのブール値。ゼロの値は静的IPアドレスを無効にし、1つの値はそれを有効にします。
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が待機する必要があります。このタイマーの値は、2*DataChannelKeepalive秒以上でなければならず、240秒ではありません。
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 State Machineのデータチェック状態で必要です。このタイマーが次の状態に移行する前に期限切れになった場合、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.
DTLSハンドシェイクを開始する前に、WTPが発見応答メッセージを受信した後、WTPが待つ必要がある最低時間。
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.
最小時間は、wtpが結合したACにエコーリクエストメッセージを送信するまでの数秒で。
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によって使用されて、decryptionエラーメッセージ要素を送信して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.
WTPの場合、これは最小時間であり、秒単位で、WTPは再び発見要求メッセージを送信するか、DTLSセッションを確立しようとする前に待つ必要があります。ACの場合、これは秒単位で最小時間であり、その間、ACはSulking状態にあるWTPから受信したすべてのCAPWAPおよびDTLSパケットを無視する必要があります。
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がWTPが使用する間隔を決定するために使用され、WTPイベントがACに送信して統計を数秒で通信する間隔を決定します。
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.
最大時間は、秒単位で、ACからDTLSハンドシェイクメッセージを受信せずにWTPを待つ必要があります。このタイマーは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.
最大時間は、秒単位で、WTPから参加要求を受信するまでDTLSセッションが確立された後、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.
WTPによって送信されたディスカバリーリクエストメッセージの数は、単一のACに送信されます。これは単調に増加するカウンターです。
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.
WTPが最後に再起動した理由は、セクション4.6.47で定義されています。
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タイプは、セクション4.6.44で定義されています。
The preferred ACs, with the index, defined in Section 4.6.5.
セクション4.6.5で定義されているインデックス付きの優先ACS。
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.
セクション4.6.45で定義されているWTP名。
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.
ディスカバリーメッセージは、WTPによって使用されて、どのACSがサービスを提供するために利用可能であるか、および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 WTP. A WTP must exchange this information to ensure subsequent exchanges with the ACs are consistent with the WTP's functional characteristics.
Discovery Requestメッセージは、WTPによって使用され、ネットワークで利用可能な潜在的なACを自動的に発見します。Discovery Requestメッセージは、ACSに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は、最大のMaxDiscoveries Discoveryリクエストメッセージ以下を送信する必要があり、各連続メッセージの間にMaxDiscoveryIntervalよりも少ないランダムな遅延を待っています。
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ディスカバリーリクエストメッセージの爆発を防ぐためです。この発生の例は、多くのWTPが同時に電源を入れている場合です。
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はsul ining状態に入り、さらにディスカバリーリクエストメッセージを送信する前に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攻撃によって引き起こされる可能性もあります。そのような場合、State Machineインスタンスを含むWTP状態は、別のDTLSセッションが正常に確立されるまでクリアされてはなりません。
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.
ディスカバリーリクエストメッセージは、ディスカバリー状態のときにWTPによって送信されます。ACはこのメッセージを送信しません。
The following message elements MUST be included in the Discovery Request message:
次のメッセージ要素は、ディスカバリーリクエストメッセージに含める必要があります。
o Discovery Type, see Section 4.6.21 o WTP Board Data, see Section 4.6.40
o 発見タイプ、セクション4.6.21 o WTPボードデータを参照してください。セクション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
o WTP MACタイプ、セクション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).
o WTPがサポートする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-ISIT状態に入り、Discovery Responseメッセージを送信し、DTLSハンドシェイクをそのACに送信するACSの1つを選択します。
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.
1つ以上のバインディング固有のWTP無線情報メッセージ要素（セクション2.1を参照）が、CapWapバインディングのACサポートを宣伝するディスカバリーリクエストメッセージに含まれています。ACには、WTPと共通するバインディングのみが含まれている場合があります。WTPは、ディスカバリーリクエストメッセージで受信されたWTP無線情報メッセージ要素を通じて既知であるか、サポートされているすべてのバインディングが含まれる場合があります。WTPは、AC決定プロセスでサポートされているバインディングを使用する場合があります。WTPが特定のCAPWAPバインディングをサポートしないACに結合した場合、そのバインディングのサービスを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
次のメッセージ要素は、ディスカバリー応答メッセージに含める必要があります。OAC記述子、セクション4.6.1を参照してください。
o AC Name, see Section 4.6.4
o AC名、セクション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).
o ACがサポートするWTP無線情報メッセージ要素。これらは、個々のリンクレイヤー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 Control 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構成があり、別のACに接続されている場合にWTPによって送信されます。これは一般に、フェールオーバーの結果として発生し、WTPによって使用されているのは、プライマリACがいつ利用可能になるかを発見する手段として使用されます。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.
一次発見要求メッセージの頻度は、Echo要求メッセージの送信よりも頻繁にはないはずです。
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 WTP Board Data, see Section 4.6.40
o 発見タイプ、セクション4.6.21 o WTPボードデータを参照してください。セクション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
o WTP MACタイプ、セクション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).
o WTPがサポートする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をプライマリACとして構成されているWTPSを要求するために、その可用性とサービスを宣伝することができます。
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
o AC記述子、セクション4.6.1を参照してください
o AC Name, see Section 4.6.4
o AC名、セクション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).
o ACがサポートするWTP無線情報メッセージ要素。これらは、個々のリンクレイヤー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
o CAPWAPコントロールIPv4アドレス、セクション4.6.9を参照してください
o CAPWAP Control IPv6 Address, see Section 4.6.10
o CapWap Control IPv6アドレス、セクション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.
Join Requestメッセージは、DTLS接続がそのACに確立された後、ACからサービスを要求するためにWTPによって使用されます。Join Responseメッセージは、ACがサービスを提供する、または提供しないことを示すために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.
Join Requestメッセージは、ACを介してサービスを要求するためにWTPによって使用されます。WTPがオプションのAC発見プロセスを実行している場合（セクション3.3を参照）、WTPが1つ以上のディスカバリー応答メッセージを受信した後に結合プロセスが発生します。発見プロセス中、ACは複数のCAPWAPコントロールIPv4アドレスまたはCAPWAPコントロールIPv6アドレスメッセージ要素を返す場合があります。複数のそのようなメッセージ要素が返されると、WTPは、最小数のWTP（メッセージ要素のWTPカウントフィールドを通じて既知）を保護するインターフェイスを選択することにより、「ロードバランシング」を実行する必要があります。ただし、他の負荷分散アルゴリズムも許可されていることに注意してください。WTPが優先ACと接続する関連インターフェイスを決定すると、DTLSセッションを確立し、セキュリティ済みのコントロールチャネルに参加要求を送信します。ACがJoin Requestメッセージを受信すると、Join Responseメッセージで応答します。
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.
DTLSハンドシェイクが完了し、DTLSESTABLED通知を受け取ると、WTPはJOINリクエストメッセージをACに送信します。ACにDTLSセッションの確立が通知された場合、Join Requestメッセージが受信されるまで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.
1つ以上の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がJoinリクエストを拒否した場合、障害表示を備えたJOIN Responseメッセージを送信し、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.
次のメッセージ要素をJoin Requestメッセージに含める必要があります。
o Location Data, see Section 4.6.30
o 位置データ、セクション4.6.30を参照してください
o WTP Board Data, see Section 4.6.40
o WTPボードデータ、セクション4.6.40を参照してください
o WTP Descriptor, see Section 4.6.41
o WTP記述子、セクション4.6.41を参照してください
o WTP Name, see Section 4.6.45
o WTP名、セクション4.6.45を参照してください
o Session ID, see Section 4.6.37
o セッションID、セクション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
o WTP MACタイプ、セクション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).
o WTPがサポートするWTP無線情報メッセージ要素。これらは、個々のリンクレイヤーCAPWAPバインディングプロトコルによって定義されます（詳細については、セクション2.1を参照）。
o ECN Support, see Section 4.6.25
o ECNサポート、セクション4.6.25を参照してください
At least one of the following message element MUST be included in the Join Request message.
次のメッセージ要素の少なくとも1つをJoin Requestメッセージに含める必要があります。
o CAPWAP Local IPv4 Address, see Section 4.6.11
o CAPWAPローカルIPv4アドレス、セクション4.6.11を参照してください
o CAPWAP Local IPv6 Address, see Section 4.6.12
o CAPWAPローカルIPv6アドレス、セクション4.6.12を参照してください
The following message element MAY be included in the Join Request message.
次のメッセージ要素は、Join Requestメッセージに含まれる場合があります。
o CAPWAP Transport Protocol, see Section 4.6.14
o CapWap Transport Protocol、セクション4.6.14を参照してください
o Maximum Message Length, see Section 4.6.31 o WTP Reboot Statistics, see Section 4.6.47
o 最大メッセージの長さ、セクション4.6.31 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にサービスを提供することをいとわないことを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タイマーをクリアし、Configure Stateに進みます。
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.
Join Responseメッセージを受信する前に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タイマーは最終的に期限切れになり、WTPは（そのように構成されている場合）新しいACに参加しようとします。
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".
Join RequestメッセージのWTP無線情報メッセージ要素（セクション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.
次のメッセージ要素をJoin Responseメッセージに含める必要があります。
o Result Code, see Section 4.6.35
o 結果コード、セクション4.6.35を参照してください
o AC Descriptor, see Section 4.6.1
o AC記述子、セクション4.6.1を参照してください
o AC Name, see Section 4.6.4
o AC名、セクション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).
o ACがサポートするWTP無線情報メッセージ要素。これらは、個々のリンクレイヤーCAPWAPバインディングプロトコルによって定義されます（セクション2.1を参照）。
o ECN Support, see Section 4.6.25
o ECNサポート、セクション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
o CAPWAPコントロールIPv4アドレス、セクション4.6.9を参照してください
o CAPWAP Control IPv6 Address, see Section 4.6.10
o CapWap Control IPv6アドレス、セクション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
o CAPWAPローカルIPv4アドレス、セクション4.6.11を参照してください
o CAPWAP Local IPv6 Address, see Section 4.6.12
o CAPWAPローカルIPv6アドレス、セクション4.6.12を参照してください
The following message elements MAY be included in the Join Response message.
次のメッセージ要素は、Join Responseメッセージに含まれる場合があります。
o AC IPv4 List, see Section 4.6.2
o AC IPv4リスト、セクション4.6.2を参照してください
o AC IPv6 List, see Section 4.6.3
o AC IPv6リスト、セクション4.6.3を参照してください
o CAPWAP Transport Protocol, see Section 4.6.14
o CapWap Transport Protocol、セクション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によって使用され、制御通信チャネルを維持します。WTPからACに送信されたWTPイベントリクエストメッセージなどのCAPWAP制御メッセージは、WTPが動作していることをACに示します。このような制御メッセージが送信されていない場合、エコーリクエストとエコー応答メッセージを使用して、制御通信チャネルを維持します。
The Echo Request message is a keep-alive mechanism for CAPWAP control messages.
Echo要求メッセージは、CapWap Controlメッセージのキープアライブメカニズムです。
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によって定期的に送信され（セクション2.3を参照）、WTPとACの間の制御接続の状態を決定します。エコーインターバルタイマーの有効期限が切れると、ECHO要求メッセージはWTPによって送信されます。
The Echo Request message is sent by the WTP when in the Run state. The AC does not transmit this message.
ECHO要求メッセージは、実行状態のときにWTPによって送信されます。ACはこのメッセージを送信しません。
The following message elements MAY be included in the Echo Request message:
次のメッセージ要素は、エコーリクエストメッセージに含まれる場合があります。
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がエコーリクエストメッセージを受信すると、エコー応答メッセージで応答します。
The Echo Response message acknowledges the Echo Request message.
Echo Responseメッセージは、Echo要求メッセージを確認します。
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.
エコーリクエストメッセージを受信した後、エコー応答メッセージがACによって送信されます。エコー応答メッセージを送信した後、ACはエコーインターバルタイマーをリセットする必要があります（セクション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.
エコー応答メッセージは、実行状態のときに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がエコー応答メッセージを受信すると、エコーインターバルを構成された値に初期化します。
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: 1. The WTP retains no configuration and accepts the configuration provided by the AC.
CAPWAPプロトコルは、WTP構成の管理方法に柔軟性を提供します。WTPは、実装固有の2つの方法のいずれかで動作できます。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は、非デフォルト値であるACによって提供されるパラメーターの構成をローカル非揮発性メモリに保存し、WTPのパワーアップ初期化フェーズ中に施行されます。
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プロトコル状態マシンは、構成交換を可能にする構成状態を定義します。Configure Stateでは、WTPは、構成ステータス要求メッセージを介して現在の構成オーバーライドをACに送信します。構成オーバーライドは、非デフォルトパラメーターです。例として、CAPWAPプロトコルでは、デフォルトのアンテナ構成は内部OMNIアンテナです。内部アンテナがない、またはACによって外部アンテナを使用するように明示的に構成されているWTPは、構成フェーズ中にアンテナ構成を送信し、ACがWTPの現在の構成を認識できるようにします。
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.
このモデルは、AC障害の場合に復元力を可能にし、別のACがWTPにサービスを提供できるようにします。WTP構成の変更で新しいACが自動的に更新され、INTER-AC通信の必要性とすべてのACSがネットワーク内のすべての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はサービスを提供し始めます。管理者は、ネットワークが動作している間に構成の変更を行うことを要求することが一般的です。したがって、構成更新リクエストはACからWTPに送信され、実行時にこれらの変更を行います。
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プロトコルは、さまざまな設計および機能特性のWTPを構成および管理する柔軟性を提供します。WTPが最初にACを発見すると、交換するフレームのタイプとフレームの性質に関連する主要な機能情報を提供します。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用の複数の無線管理状態メッセージ要素、およびWTPの各ラジオ用の複数の無線管理状態メッセージ要素が含まれます。
The Configuration Status Request message is sent by the WTP when in the Configure State. The AC does not transmit this message.
Configuration Status Requestメッセージは、Configure Stateの場合にWTPによって送信されます。ACはこのメッセージを送信しません。
The following message elements MUST be included in the Configuration Status Request message.
次のメッセージ要素を構成ステータス要求メッセージに含める必要があります。
o AC Name, see Section 4.6.4
o AC名、セクション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
o AC名を優先して、セクション4.6.5を参照してください
o CAPWAP Transport Protocol, see Section 4.6.14
o CapWap Transport Protocol、セクション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が構成ステータス応答メッセージを受信すると、必要に応じてメッセージの内容に作用します。構成ステータス応答メッセージに、ラジオの1つの運用状態の変更を引き起こす無線動作状態メッセージ要素が含まれている場合、WTPは状態の変更を認めるために、変更状態イベントをACに送信します。
The Configuration Status Response message is sent by the AC when in the Configure state. The WTP does not transmit this message.
構成ステータス応答メッセージは、Configure Stateの場合、ACによって送信されます。WTPはこのメッセージを送信しません。
The following message elements MUST be included in the Configuration Status Response message.
次のメッセージ要素を構成ステータス応答メッセージに含める必要があります。
o CAPWAP Timers, see Section 4.6.13
o CapWapタイマー、セクション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
o WTPフォールバック、セクション4.6.42を参照してください
One or both of the following message elements MUST be included in the Configuration Status Response message:
次のメッセージ要素の1つまたは両方は、構成ステータス応答メッセージに含める必要があります。
o AC IPv4 List, see Section 4.6.2
o AC IPv4リスト、セクション4.6.2を参照してください
o AC IPv6 List, see Section 4.6.3
o AC IPv6リスト、セクション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には、画像識別子メッセージ要素（セクション4.6.27を参照）が含まれており、実行状態の間にWTPにファームウェアを更新するように強制します。WTPは、画像識別子メッセージ要素で指定されたバージョンが画像データ要素を送信することにより不揮発性ストレージではない場合に、要求されたファームウェアをダウンロードすることを進めることができます（開始メッセージ要素を含む画像データ要素（セクション9.1.1を参照）（セクション9.1.1を参照）（セクション9.1.1を参照）（セクション9.1.1を参照）（セクション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
o AC名を優先して、セクション4.6.5を参照してください
o AC Timestamp, see Section 4.6.6
o ACタイムスタンプ、セクション4.6.6を参照してください
o Add MAC ACL Entry, see Section 4.6.7
o Mac ACLエントリを追加します。セクション4.6.7を参照してください
o CAPWAP Timers, see Section 4.6.13
o CapWapタイマー、セクション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
o WTPフォールバック、セクション4.6.42を参照してください
o WTP Name, see Section 4.6.45 o WTP Static IP Address Information, see Section 4.6.48
o WTP名、セクション4.6.45を参照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.
Configuration Update Responseメッセージは、Configuration Update Requestメッセージの確認メッセージです。
The Configuration Update Response message is sent by a WTP after receiving a Configuration Update Request message.
構成更新リクエストメッセージを受信した後、Configuration Update Responseメッセージは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.
実行状態の場合、Configuration Update ResponseメッセージはWTPによって送信されます。ACはこのメッセージを送信しません。
The following message element MUST be present in the Configuration Update message.
次のメッセージ要素は、構成更新メッセージに存在する必要があります。
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.
o ACからの構成ステータス応答メッセージの受信後にWTPによって送信されると、WTPはChange State Event Requestメッセージを使用して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はChange State Event Requestメッセージを使用して、ACにWTPの無線運用状態に予期しない変更を通知します。
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.
Configureまたは実行状態の場合、変更状態イベント応答メッセージは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.
Clear Configuration Requestメッセージは、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.
Clear Configuration RequestメッセージはACによって送信され、WTPがその構成を製造デフォルト構成にリセットするように要求します。Clear Config要求メッセージは、実行状態で送信されます。
The Clear Configuration Request is sent by the AC when in the Run state. The WTP does not transmit this message.
Clear Configurationリクエストは、実行状態のときにACによって送信されます。WTPはこのメッセージを送信しません。
The following message element MAY be included in the Clear Configuration Request message:
次のメッセージ要素は、Clear Configurationリクエストメッセージに含めることができます。
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.
Clear Configuration Reponseメッセージは、Clear Configuration Requestメッセージを受信し、その構成パラメーターを製造デフォルト値にリセットした後、WTPによって送信されます。
The Clear Configuration Response is sent by the WTP when in the Run state. The AC does not transmit this message.
CLEAR構成応答は、実行状態のときに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:
次のメッセージ要素は、Clear Configurationリクエストメッセージに含めることができます。
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操作を定義します。このセクションで定義されている管理操作は、ACがWTPに出入りする情報をプッシュ/プルするか、WTPの再起動を要求するために使用されます。このセクションは、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プロトコルは、WTPが提供するファームウェア情報が正しいかどうか、またはWTPがファームウェアを適切に保存しているかどうかをACが識別する機能を提供しないことに注意することが重要です（詳細については、セクション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には要求されたファームウェア（Image Identifier = 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はサービスを提供し続けながら画像をダウンロードできます。WTPは、リセットリクエストメッセージを使用して、ACによって通知されるまで自動的にリセットされません。
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とACの間で交換され、新しいファームウェアイメージをWTPにダウンロードします。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に結合すると、Join Responseメッセージには、実行されるファームウェアのWTPに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 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は画像識別子とIntiateのダウンロードメッセージ要素を使用して画像データ要求を送信します。この方法でファームウェアがダウンロードされた場合、ダウンロードが完了した後にWTPが自動的にリセットされないことに注意してください。WTPは、ACからリセットリクエストメッセージを受信した場合にのみリセットされます。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によって送信されます。
The following message elements MAY be included in the Image Data Request message:
次のメッセージ要素は、画像データリクエストメッセージに含まれる場合があります。
o CAPWAP Transport Protocol, see Section 4.6.14
o CapWap Transport Protocol、セクション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によって送信されます。
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.
リセット要求メッセージは、ACによって送信され、WTPが操作を再現します。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が操作を再現することが通知されます。障害を示すリセット応答メッセージを受信するACは、WTPへのサービスを提供しなくなる場合があります。
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イベントリクエストメッセージは、WTPによってそのACに情報を送信するために使用されます。WTPイベントリクエストメッセージは、定期的に送信されるか、WTPの非同期イベントに応じて送信される場合があります。たとえば、WTPは統計を収集し、WTPイベント要求メッセージを使用して統計をACに送信する場合があります。
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.
Delete Stationメッセージ要素の存在は、WTPによって使用され、ACにステーションへのサービスを提供しなくなったことを通知します。これは、リソース不足またはその他の理由により、アイドルタイムアウトの結果である可能性があります（セクション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イベントリクエストメッセージには、以下にリストされているメッセージ要素の1つ、または特定のワイヤレステクノロジー用に定義されているメッセージ要素を含める必要があります。リストされている各メッセージ要素の複数がWTPイベントリクエストメッセージに含まれる場合があります。
o Decryption Error Report, see Section 4.6.17
o 復号化エラーレポート、セクション4.6.17を参照してください
o Duplicate IPv4 Address, see Section 4.6.22
o IPv4アドレスを複製します。セクション4.6.22を参照してください
o Duplicate IPv6 Address, see Section 4.6.23
o IPv6アドレスを複製します。セクション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イベント応答メッセージは、実行状態のときに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プロトコルで使用されるデータ転送手順について説明します。データ転送メカニズムは、クラッシュやデバッグ情報など、WTPで利用可能なACに利用可能な情報をアップロードするために使用されます。データ転送メッセージは、実行状態でのみ交換できます。
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 Data Transfer Response, and the exchange continues until the WTP transmits a Data Transfer Data message element that indicates an End of File (EOF).
図10は、WTPが最新のクラッシュファイルを転送することを要求するACの例を示しています。WTPが、データ転送応答を介して送信する情報があることを認めたら、独自のデータ転送要求を送信します。受信すると、ACはデータ転送応答で応答し、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.
データ転送要求メッセージは、WTPからACにデバッグ情報を配信するために使用されます。
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を直接管理する必要性を最小限に抑えることを考えると、データ転送要求は、ACが使用する重要なトラブルシューティングツールであり、WTPで利用可能な情報を取得します。たとえば、一部のWTP実装は、クラッシュ情報を保存して、製造業者がソフトウェアの障害を特定できるようにする場合があります。データ転送要求メッセージを使用して、WTPからACにそのような情報を送信できます。別の使用可能な用途は、WTPのリモートデバッガー関数がデータ転送要求メッセージを使用して、デバッグ目的でコンソール出力をACに送信できるようにすることです。
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によって送信されます。
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.
このセクションのメッセージは、ACがWTPSでステーションセッション状態を作成、変更、または削除するために使用されます。
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でステーションセッションの状態を作成、変更、または削除するために使用されます。メッセージはACからWTPに送信され、1つ以上のメッセージ要素が含まれる場合があります。このCapWap Controlメッセージのメッセージ要素には、一般的に高度にテクノロジー固有の情報が含まれます。このコントロールメッセージに含まれるメッセージ要素の定義については、適切なバインディングドキュメントを参照してください。
The Station Configuration Request message is sent by the AC when in the Run state. The WTP does not transmit this message.
ステーション構成要求メッセージは、実行状態のときに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コントロールメッセージ要素は、ステーション構成要素メッセージに含まれる場合があります。リストされている各メッセージ要素の1つ以上が、ステーション構成要求メッセージに含まれる場合があります。
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.
ステーション構成応答メッセージは、実行状態のときに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.
CapWap対応展開と組み合わせてNAT展開を使用できる3つの特定の状況があります。最初は、単一のWTPがNATシステムの背後にある構成で構成されています。すべての通信はWTPによって開始され、すべての通信が2つのUDPポートを使用してIPを介して実行されるため、この構成でプロトコルは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番目のケースでは、2つ以上のWTPが同じNATシステムの背後に展開されます。ここで、ACは同じIPアドレスから複数の接続要求を受信するため、WTPのIPアドレスのみを使用してCapWapコントロールとデータチャネルをバインドすることはできません。データプレーン接続を確立し、CapWap Data Channel Keep-Aliveを通信するCapWapデータチェック状態には、コントロールとデータプレーンをバインドするために使用されるセッション識別子メッセージ要素が含まれます。セッション識別子メッセージ要素を使用すると、ACは、同じNATシステム（同じIPアドレスを共有する複数のwtps）の背後にある複数の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.
3番目の構成では、ACはNATの背後に展開されます。この場合、特定のルールがNAT上に構成されていない限り、ACはACに到達できません。アドレスを翻訳し、CAPWAPメッセージをACにリダイレクトします。この展開は2つの問題を提示します。まず、ACは、CAPWAPコントロールIPv4アドレスとCAPWAPコントロールIPv6アドレスメッセージ要素を使用して、そのインターフェイスと対応するWTP負荷を通知します。このメッセージ要素は必須ですが、ACが使用するプライベートアドレススペースでのみ有効なIPアドレスが含まれていますが、これはWTPが到達できません。WTPは、NATを検出した場合、これらのメッセージ要素に情報を利用してはなりません（セクション4.6.14のCAPWAP輸送プロトコルメッセージ要素で説明されています）。第二に、アドレスはWTPで使用できないため、CAPWAPプロトコルの負荷分散機能（セクション6.1を参照）を効果的に無効にします。あるいは、ACには構成されたNAT'DADDRESSを持つことができます。これは、2つのコントロールアドレスメッセージ要素のいずれかに含まれ、それに応じて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プロトコルにより、WTPのグループをサポートするすべてのAC IDがACリストメッセージ要素を介して通信できます。この機能は、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アドレス指定スキームに精通しており、ACが見たパブリックアドレスに依存していない場合を除き、NATの環境で使用すべきではありません。
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が複製アドレス条件を検出すると、ACへのメッセージが生成されます。これには、重複するIPアドレスメッセージ要素が含まれます。このメッセージ要素に埋め込まれた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展開シナリオでは、WTPとACの間に2つのチャネルがあります。CAPWAPコントロールメッセージとデータチャネルを運ぶコントロールチャネルと、クライアントデータパケットがACとWTPの間にトンネル化されています。通常、コントロールチャネルはDTLによって保護されますが、データチャネルはそうではありません。
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を使用してハッシュフィールドを計算します。画像ファイルの信頼性と整合性はDTLによって保護されており、この文脈では、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データチャネルでのDTLの使用を使用して、この脆弱性を回避できます。
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は一意のセッション識別子をエクスポートしないため、DTLS層とCapWapレイヤーの間に明示的なプロトコル結合はありません。その結果、実装はこのバインディングを実行するためのメカニズムを提供する必要があります。たとえば、ACは、パケットヘッダーのセッションIDのみに基づいて、復号化されたDTLS制御パケットを特定のWTPセッションに関連付けてはなりません。代わりに、識別は、どの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が公開され、敵や他のWTPに知られている可能性があることに注意する必要があります。これにより、データチャネルトラフィックのソースの偽造が可能になります。ただし、これは暗号化されていないデータチャネルにとって驚きではありません。データチャネルが暗号化されている場合、セッション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セッションを取り壊すことを意味することが重要です。Discovery Requestメッセージは悪意のあるデバイスによって簡単にスプーフィングできます。そのため、DTLSSessionが設定された通知が受信されるまで、ACがWTPの2つの別々の状態セットを維持することが重要です。これは、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セッションが正常に確立されるまでアクティブ状態を破棄すべきではありません。HelloverifeRequestは、ACに対するサービス拒否（DOS）攻撃に対するある程度の保護を提供しますが、有効なアドレス（または誤動作または誤解されたWTP）でパケットを受信できる敵対者は、ACでDTLSハンドシェイクを繰り返し試み、潜在的に作成する可能性があります。リソース不足。FailedDtlsSessionCountまたはFailedDtlsauthFailCountカウンターがMaxFailedDtlsSessionRetry変数の値に達する場合（セクション4.8を参照）、実装は、ある期間の新しいDTLSハンドシェイクを評価することを選択できます。レート制限を実装することを選択する実装は、WTPのsul笑行動を模倣するのではなく、ランダム破棄技術を使用することをお勧めします。これにより、有効なWTPからのメッセージが、重要な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はすでにクライアント側のCookieを使用してプロセッサ消費攻撃を最小限に抑えているため、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 ID：プロビジョニングされたキーに関連付けられたIDヒント（詳細については、セクション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 Trust Anchor：CapWapのピアから受け取った証明書を検証するために使用される信頼できるルート証明書チェーン。特定のデバイスで1つ以上のルート証明書を構成できることに注意してください。
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).
認証方法に関係なく、次の項目を事前に解決する必要があります。Oアクセス制御リスト：アクセス制御リストテーブルには、1つ以上のCapWapピアのIDがルールとともに含まれています。このルールは、ピアとの通信が許可されているかどうかを判断するために使用されます（詳細については、セクション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.
o DTLSが事前に共有キー（PSK）CipherSuiteで使用される場合、各WTPには一意のPSKが必要です。WTPは広く展開される可能性が高いため、物理的なセキュリティは保証されていません。PSKがWTPごとに一意でない場合、キーの再利用により、1つのWTPの妥協が他のWTPの妥協をもたらすことができます。
o Generating PSKs from low entropy passwords is NOT RECOMMENDED.
o 低エントロピーパスワードからPSKを生成することは推奨されません。
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]を考慮に入れて、新しいランダムPSKの生成の機能を提供することをお勧めします。
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が必要です。これにより、ドミノ効果が防止されます（「認証、承認、および会計（AAA）主要な管理」[RFC4962]のガイダンスを参照）。PSKが特定の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.
PSKが共有されている場合、デバイスとID間のこのバインディングはもはや不可能です。あるWTPの妥協は、別のWTPの妥協をもたらし、CAPWAPセキュリティ階層に違反する可能性があります。その結果、WTP間でキーを共有することはお勧めしません。
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.
Public-KeyベースのDTLSデプロイメントの場合、各デバイスには一意の資格情報が必要であり、拡張されたキー使用法により、デバイスがWTPまたはACとして機能することを許可します。デバイスに一意の資格情報がない場合、1つのデバイスを侵害することにより、同じ資格情報を使用して他のデバイスも侵害されると見なされる可能性があります。
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に依存している場合（たとえば、ACはWTPが直接接続されているレイヤー2スイッチです）、WTPはオンライン証明書ステータスプロトコル（OCSP）サーバーに連絡できない場合がある場合があることに注意してください。侵害された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.
通常、証明書の適切な検証では、証明書がまだ期限切れになっていないことを確認するためにチェックが必要です。デバイスにリアルタイムクロックがある場合、証明書の有効性の日付を確認する必要があります。リアルタイムのクロックが利用できない場合、デバイスは他の手段を通じて証明書の有効性の日付を検証しようとする最良の試みを行う必要があります。証明書の時間的妥当性を確認できないと、妥協した有効期限が切れた証明書を使用して起動された中間攻撃に対してデバイスを脆弱にする可能性があるため、デバイスはこの検証を実行するためにあらゆる努力を払う必要があります。
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プロトコルは、既存のプロトコル[LWAPP]の進化であり、既に展開されている多数のACSおよびWTPに実装されています。これらのデバイスのすべてには、製造時にプロビジョニングされている既存のX.509証明書があります。これらのX.509証明書は、共通名（CN）フィールドでデバイスのMACアドレスを使用します。CNフィールドのMACアドレスをエンコードすることは最適ではないことがよく理解されており、sumberaltaltnameフィールドを使用することが望ましいでしょう。ただし、出版時には、MACアドレスをsumbesaltnameフィールドで使用できるようにする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）キーを配布するために使用されるため、そのセキュリティはシステム全体のセキュリティにとって重要です。Transport Layer Security（TLS）またはIPSECで使用する場合は、RFC 3539 [RFC3539]で指定されたセキュリティガイドラインに従う必要があります。
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サーバーの間のリンクは、相互に認証されたセッションキーを備えた強力なCiphersuiteを使用して保護する必要があります。実装は、辞書攻撃に対して脆弱であることが多いため、基本的な半径の共有秘密認証だけに依存するべきではなく、より強力な基礎となるセキュリティメカニズムを使用する必要があります。
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はスプリットMACモードで実行することもできます。この場合、各WTPとACの間にDTLS暗号化されたデータチャネルがあります。WGは、このチャネルで混雑制御を提供するためのさまざまなオプションについて議論しました。ただし、TCPが別の輻輳制御メカニズムを介して実行されたときのパフォーマンスの問題により、およびCapWapデータチャネル上でトラフィックの大部分が輻輳制御IPトラフィックである可能性が高いという事実により、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 Data Channelに指定された輻輳制御メカニズムはないため、非合成制御トラフィックを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".
CAPWAPプロトコルは、[RFC3168]のセクション9.1.1で詳述されている「限定機能オプション」という名前の操作モードを通じて、明示的な輻輳通知（ECN）のサポートを義務付けています。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.
将来の登録要求のために、専門家のレビューが必要な場合、指定された専門家に相談する必要があります。これは、責任あるIESGエリアディレクターによって任命されます。意図は、すべての割り当てに公開されたRFCが伴うことですが、他のSDOがCapWapの上に構築された標準を作成したい場合があるため、指定された専門家がレビューできる文書も受け入れられます。IANAは、公開が承認される前に、文書が承認される前に値の割り当てを許可する必要があります。そのため、出版物が発生することが明らかになったら、指定された専門家は割り当てを承認できます。指定された専門家は、コメントとレビューのために、CAPWAP WGメーリングリスト（またはエリアディレクターによって指定された後継者）にリクエストを投稿します。30日間が経過する前に、指定された専門家は登録要求を承認または拒否し、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は、登録されたポート番号レジストリに組織ローカルマルチキャストアドレスである2つの新しい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メッセージタイプレジストリを維持します。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値1〜26はこの仕様に割り当てられ、セクション4.5.1.1に記載されています。エンタープライズ番号がゼロ（0）に設定されているCAPWAPメッセージタイプの新しい割り当てには、専門家のレビューが必要です。IANAによって維持されているレジストリには、次の形式があります。
CAPWAP Control Message Message Type Reference Value
capwapコントロールメッセージメッセージタイプ参照値
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ビットで、メッセージに関連する特別な治療を特定するために使用されます。この仕様はビットゼロ（0）から5（5）を定義し、ビット6から8（8）は予約されています。現在、IANAによって管理されており、その割り当てには専門家のレビューが必要な3つの未使用の予約済みビットがあります。IANAはCapWap Header Flagsレジストリを作成しました。
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 Controlメッセージヘッダー（セクション4.5.1.4を参照）のフラグフィールドは、コントロールメッセージに関連する特別な処理を特定するために使用されます。現在、8つの未使用の予約済みビットがあります。これらのビットの割り当てはIANAによって管理されており、専門家のレビューが必要です。IANAはCapWap Control Message Flagsレジストリを作成しました。
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を参照）は、輸送されているデータを識別するために使用されます。名前空間は16ビット（0-65535）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で割り当てられており、セクション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ヘッダーのワイヤレスバインディング識別子（WBID）フィールド（セクション4.3を参照）を使用して、パケットに関連するワイヤレステクノロジーを識別します。この仕様には、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で利用可能な認証方法を識別するために使用されます。この仕様はビット5（5）と6（6）を定義し、ビットゼロ（0）から4（4）とビット7（7）は予約されていないと未使用です。これらの予約ビットは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データチャネルを保護するかどうかを識別するために使用されます。この仕様はビット5（5）と6（6）を定義し、ビットゼロ（0）から4（4）とビット7（7）は予約されていないと未使用です。これらの予約ビットは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に関する情報を表すために使用されます。名前空間は16ビット（0-65535）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。このフィールドは、AC情報ベンダーIDと組み合わせて、ベンダーがプライベートネームスペースを使用できるようにします。この仕様では、AC情報ベンダーIDがゼロ（0）に設定されている場合、AC情報タイプの名前空間を定義します。この仕様は、この仕様で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 Transport Protocolメッセージ要素の輸送フィールド（セクション4.6.14を参照）を使用して、CAPWAPデータチャネルに使用するトランスポートを特定します。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で1つ（1）と2つ（2）が割り当てられており、セクション4.6.14に記載されています。この名前空間はIANAによって管理されており、割り当てには専門家のレビューが必要です。IANAは、CapWap Transport Protocol Types Registryを作成しました。
CAPWAP Transport Protocol Type Type Value Reference
CapWap Transport Protocol Type Value Reference
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.15を参照）および画像データメッセージ要素（セクション4.6.26を参照）のデータ型フィールドは、実施されているデータに関する情報を提供するために使用されます。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で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:
データ転送データメッセージ要素（セクション4.6.15を参照）およびデータ転送モードメッセージ要素（セクション15.14を参照）のデータモードフィールドは、実施されているデータに関する情報を提供するために使用されます。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で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:
Discovery Type Message要素のディスカバリータイプフィールド（セクション4.6.21を参照）は、WTPによって使用され、ACにどのように発見されたかを示します。名前空間は8ビット（0-255）です。値ゼロ（0）から4（4）はこの仕様で割り当てられ、セクション4.6.21に記載されています。この名前空間はIANAによって管理されており、割り当てには専門家のレビューが必要です。IANAは、フォーマットが次のようなDiscovery Typesレジストリを作成しました。
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サポートメッセージ要素のECNサポートフィールド（セクション4.6.25を参照）は、WTPによってECNサポートを表すために使用されます。名前空間は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がラジオの状態を表すために使用しています。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で1つ（1）と2つ（2）が割り当てられており、セクション4.6.33に記載されています。この名前空間はIANAによって管理されており、割り当てには専門家のレビューが必要です。IANAはラジオ管理者状態レジストリを作成しました。その形式は次のとおりです。
Radio Admin State Type Value Reference
ラジオ管理者状態のタイプの値参照
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がラジオの運用状態を表すために使用します。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で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）で、ゼロ（0）から3（3）の値がこの仕様に割り当てられ、セクション4.6.34に記載されています。この名前空間は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コントロールメッセージの成功または失敗を示します。名前空間は32ビット（0-4294967295）で、ゼロ（0）から22の値がこの仕様で割り当てられ、セクション4.6.35に記載されています。この名前空間は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を参照）の[要素]の理由を使用して、メッセージ要素が正常に処理されなかった理由を示します。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で割り当てられ、セクション4.6.36に記載されています。この名前空間はIANAによって管理されており、割り当てには専門家のレビューが必要です。IANAは、返されたメッセージ要素Reason Registryを作成しました。その形式は次のとおりです。
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がゼロ（0）に設定されている場合、WTP記述子タイプ名空間を定義します。この仕様は、この仕様でゼロ（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フォールバックメカニズムのタイプを示すために使用されます。名前空間は8ビット（0-255）で、ゼロ（0）の値が予約されており、割り当てられてはなりません。値は、この仕様で割り当てられ、セクション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の間で使用するトンネリングのタイプを示すために使用されます。この仕様では、ビット4から6（6）を定義しますが、ビットゼロ（0）から3（3）とビット7（7）は予約および未使用です。これらの予約ビットは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のタイプを示すために使用されます。名前空間は8ビット（0-255）で、ゼロ（0）から2（2）の値がこの仕様に割り当てられ、セクション4.6.44に記載されています。この名前空間は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）で、ゼロ（0）から3（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 Choudhury、Pasi Eronen、Saravanan Govindan、Peter Nilsson、David Perkins、Yong Zhang。
Michael Vakulenko contributed text to describe how CAPWAP can be used over Layer 3 (IP/UDP) networks.
Michael Vakulenkoは、レイヤー3（IP/UDP）ネットワークでCapWapを使用する方法を説明するためにテキストを提供しました。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、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] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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. Wood、「認証、認可、会計（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.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（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] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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、「輸送層セキュリティのための事前共有キーシファースーツ（TLS）」、RFC 4279、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、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.、Mathis、M。、およびB. Chandler、「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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、and W. Polk、 "Internet 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 Standard 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] Calhoun、P.、Ed。、Montemurro、M.、ed。、およびD. Stanley、ed。、「IEEE 802.11のワイヤレスアクセスポイント（CAPWAP）プロトコル結合の制御とプロビジョニング」、RFC 5416、2009年3月。
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option", RFC 5417, March 2009.
[RFC5417] Calhoun、P。、「ワイヤレスアクセスポイント（CAPWAP）アクセスコントローラーDHCPオプションの制御とプロビジョニング」、RFC 5417、2009年3月。
[FRAME-EXT] IEEE, "IEEE Standard 802.3as-2006", 2005.
[Frame-Ext] IEEE、「IEEE Standard 802.3AS-2006」、2005年。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] Reynolds、J。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] MANER、J。およびM. Kojo、「Mobility関連用語」、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] Govindan、S.、Cheng、H.、Yao、Zh。、Zhou、Wh。、およびL. Yang、「ワイヤレスアクセスポイントの制御とプロビジョニングの目的（CAPWAP）、RFC 4564、2006年7月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。and 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] Calhoun、P.、O'hara、B.、Suri、R.、Cam Winget、N.、Kelly、S.、Williams、M。、およびS. Hares、「軽量アクセスポイントプロトコル」、作業進捗、2007年3月。
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP: Secure Light Access Point Protocol", Work in Progress, May 2005.
[Slapp] Narasimhan、P.、Harkins、D。、およびS. Ponnuswamy、「Slapp：Secure light Access Point Protocol」、2005年5月の作業。
[DTLS-DESIGN] Modadugu, et al., N., "The Design and Implementation of Datagram TLS", Feb 2004.
[DTLS-Design] Modadugu、et al。、N。、「Datagram TLSの設計と実装」、2004年2月。
[EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique Identifier", Dec 2005.
[EUI-48] IEEE、「48ビット拡張ユニークな識別子の使用に関するガイドライン」、2005年12月。
[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".
[epcglobal] "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月、<CacketCable>。
[CableLabs] "OpenCable System Security Specification OC-SP-SEC-I07-061031", October 2006, <CableLabs>.
[CableLabs] "OpenCable System Security Specification 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 Forum 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] Kelly、S。and C. Clancy、「IEEE 802.11展開のワイヤレスアクセスポイント（CAPWAP）脅威分析の制御とプロビジョニング」、RFC 5418、2009年3月。
Editors' Addresses
編集者のアドレス
Pat R. Calhoun (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
パットR.カルホーン（編集者）Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
Phone: +1 408-902-3240
EMail: pcalhoun@cisco.com
Michael P. Montemurro (editor) Research In Motion 5090 Commerce Blvd Mississauga, ON L4W 5M4 Canada
Michael P. Montemurro（Editor）Research in Motion 5090 Commerce Blvd Mississauga、L4W 5M4 Canada
Phone: +1 905-629-4746 x4999
EMail: mmontemurro@rim.com
Dorothy Stanley (editor) Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
Dorothy Stanley（編集者）Aruba Networks 1322 Crossman Ave Sunnyvale、CA 94089
Phone: +1 630-363-1389
EMail: dstanley@arubanetworks.com