[要約] RFC 8350は、CAPWAPにおけるデータフレームの代替トンネルカプセル化に関する仕様です。このRFCの目的は、CAPWAPネットワークでのデータフレームの効率的な転送を可能にするための新しいトンネルカプセル化方法を提供することです。
Internet Engineering Task Force (IETF) R. Zhang
Request for Comments: 8350 China Telecom
Category: Experimental R. Pazhyannur
ISSN: 2070-1721 S. Gundavelli
Cisco
Z. Cao
H. Deng
Z. Du
Huawei
April 2018
Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
ワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）におけるデータフレームの代替トンネルカプセル化
Abstract
概要
Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP Data Channel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP.
ワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）は、ワイヤレス伝送ポイント（WTP）とアクセスコントローラ（AC）の間でステーションのデータフレームをカプセル化するためのプロトコルです。具体的には、ステーションのIEEE 802.11データフレームをローカルにブリッジするか、ACにトンネリングできます。トンネリングされると、CAPWAPデータチャネルがトンネリングに使用されます。多くの展開では、データフレームをAC以外のエンティティ（アクセスルータ（AR）など）にカプセル化することが望まれます。さらに、WTPとアクセスルータ間で異なるトンネルカプセル化モードを使用することも望ましい場合があります。このドキュメントでは、この機能をサポートするCAPWAPプロトコルの拡張を定義し、代替トンネルカプセル化と呼びます。代替トンネルカプセル化では、1）WTPが非管理データフレームをACとは異なるエンドポイントにトンネリングし、2）WTPがIP-IP、IP-GRE、CAPWAPなどの多くの既知のカプセル化タイプの1つを使用してトンネリングできます。 。 WTPは、検出および参加プロセス中に代替トンネルカプセル化のサポートをアドバタイズし、ACは、WTPを構成するときに、サポートされている代替トンネルカプセル化タイプの1つを選択できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8350.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8350で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 7
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. History of the Document . . . . . . . . . . . . . . . . . 8
2. Alternate Tunnel Encapsulation Overview . . . . . . . . . . . 9
3. Extensions for CAPWAP Protocol Message Elements . . . . . . . 11
3.1. Supported Alternate Tunnel Encapsulations . . . . . . . . 11
3.2. Alternate Tunnel Encapsulations Type . . . . . . . . . . 11
3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication . . . 12
4. Alternate Tunnel Types . . . . . . . . . . . . . . . . . . . 13
4.1. CAPWAP-Based Alternate Tunnel . . . . . . . . . . . . . . 13
4.2. PMIPv6-Based Alternate Tunnel . . . . . . . . . . . . . . 14
4.3. GRE-Based Alternate Tunnel . . . . . . . . . . . . . . . 15
5. Alternate Tunnel Information Elements . . . . . . . . . . . . 16
5.1. Access Router Information Elements . . . . . . . . . . . 16
5.1.1. AR IPv4 List Element . . . . . . . . . . . . . . . . 16
5.1.2. AR IPv6 List Element . . . . . . . . . . . . . . . . 17
5.2. Tunnel DTLS Policy Element . . . . . . . . . . . . . . . 17
5.3. IEEE 802.11 Tagging Mode Policy Element . . . . . . . . . 19
5.4. CAPWAP Transport Protocol Element . . . . . . . . . . . . 20
5.5. GRE Key Element . . . . . . . . . . . . . . . . . . . . . 22
5.6. IPv6 MTU Element . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Service Providers are deploying very large Wi-Fi networks containing hundreds of thousands of Access Points (APs), which are referred to as Wireless Transmission Points (WTPs) in Control and Provisioning of Wireless Access Points (CAPWAP) terminology [RFC5415]. These networks are designed to carry traffic generated from mobile users. The volume in mobile user traffic is already very large and expected to continue growing rapidly. As a result, operators are looking for scalable solutions that can meet the increasing demand. The scalability requirement can be met by splitting the control/ management plane from the data plane. This enables the data plane to scale independent of the control/management plane. This specification provides a way to enable such separation.
サービスプロバイダーは、数十万のアクセスポイント（AP）を含む非常に大規模なWi-Fiネットワークを展開しています。これは、ワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）の用語でワイヤレス伝送ポイント（WTP）と呼ばれています[RFC5415]。これらのネットワークは、モバイルユーザーから生成されたトラフィックを伝送するように設計されています。モバイルユーザートラフィックの量はすでに非常に多く、急速に増加し続けると予想されます。その結果、オペレーターは増大する需要を満たすことができるスケーラブルなソリューションを探しています。データプレーンからコントロール/管理プレーンを分割することにより、スケーラビリティ要件を満たすことができます。これにより、データプレーンは、コントロール/管理プレーンから独立してスケーリングできます。この仕様は、そのような分離を可能にする方法を提供します。
CAPWAP [RFC5415] [RFC5416] defines a tunnel mode that describes how the WTP handles the data plane (user traffic). The following types are defined:
CAPWAP [RFC5415] [RFC5416]は、WTPがデータプレーン（ユーザートラフィック）を処理する方法を記述するトンネルモードを定義します。次のタイプが定義されています。
o Local Bridging: All data frames are locally bridged.
o ローカルブリッジング：すべてのデータフレームはローカルでブリッジングされます。
o IEEE 802.3 Tunnel: All data frames are tunneled to the Access Controller (AC) in IEEE 802.3 format.
o IEEE 802.3トンネル：すべてのデータフレームは、IEEE 802.3形式でアクセスコントローラー（AC）にトンネリングされます。
o IEEE 802.11 Tunnel: All data frames are tunneled to the AC in IEEE 802.11 format.
o IEEE 802.11トンネル：すべてのデータフレームは、IEEE 802.11形式でACにトンネリングされます。
Figure 1 describes a system with Local Bridging. The AC is in a centralized location. The data plane is locally bridged by the WTPs; this leads to a system with a centralized control plane and a distributed data plane. This system has two benefits: 1) it reduces the scale requirement on the data traffic handling capability of the AC, and 2) it leads to more efficient/optimal routing of data traffic while maintaining centralized control/management.
図1は、ローカルブリッジングを備えたシステムを示しています。 ACは集中管理された場所にあります。データプレーンは、WTPによってローカルにブリッジされます。これにより、集中制御プレーンと分散データプレーンを備えたシステムが実現します。このシステムには2つの利点があります。1）ACのデータトラフィック処理機能に対するスケール要件を軽減し、2）集中制御/管理を維持しながら、データトラフィックのルーティングをより効率的/最適化します。
Locally Bridged
+-----+ Data Frames +----------------+
| WTP |===============| Access Router |
+-----+ +----------------+
\\
\\ CAPWAP Control Channel +----------+
++=========================| AC |
// CAPWAP Data Channel: | |
// IEEE 802.11 Mgmt Traffic +----------+
//
+-----+ +----------------+
| WTP |============== | Access Router |
+-----+ +----------------+
Locally Bridged
Data Frames
Figure 1: Centralized Control with Distributed Data
図1：分散データによる集中管理
The AC handles control of WTPs. In addition, the AC also handles the IEEE 802.11 management traffic to/from the stations. There is a CAPWAP Control and Data Channel between the WTP and the AC. Note that even though there is no user traffic transported between the WTP and AC, there is still a CAPWAP Data Channel. The CAPWAP Data Channel carries the IEEE 802.11 management traffic (like IEEE 802.11 Action Frames).
ACはWTPの制御を処理します。さらに、ACはステーションとの間のIEEE 802.11管理トラフィックも処理します。 WTPとACの間にCAPWAPコントロールとデータチャネルがあります。 WTPとACの間で転送されるユーザートラフィックがない場合でも、CAPWAPデータチャネルが存在することに注意してください。 CAPWAPデータチャネルは、IEEE 802.11管理トラフィック（IEEE 802.11アクションフレームなど）を伝送します。
Figure 2 shows a system where the tunnel mode is configured to tunnel data frames between the WTP and the AC using either the IEEE 802.3 Tunnel or 802.11 Tunnel configurations. Operators deploy this configuration when they need to tunnel the user traffic. The tunneling requirement may be driven by the need to apply policy at the AC. This requirement could be met in the locally bridged system (Figure 1) if the Access Router (AR) implemented the required policy. However, in many deployments, the operator managing the WTP is different than the operator managing the Access Router. When the operators are different, the policy has to be enforced in a tunnel termination point in the WTP operator's network.
図2は、IEEE 802.3トンネルまたは802.11トンネル構成のいずれかを使用して、WTPとACの間でデータフレームをトンネルするようにトンネルモードが構成されているシステムを示しています。オペレーターは、ユーザートラフィックをトンネリングする必要があるときにこの構成を展開します。トンネリング要件は、ACでポリシーを適用する必要性によって引き起こされる場合があります。この要件は、アクセスルーター（AR）が必要なポリシーを実装した場合、ローカルにブリッジされたシステム（図1）で満たすことができます。ただし、多くの展開では、WTPを管理するオペレーターは、アクセスルーターを管理するオペレーターとは異なります。オペレーターが異なる場合、WTPオペレーターのネットワーク内のトンネル終端ポイントでポリシーを実施する必要があります。
+-----+
| WTP |
+-----+
\\
\\ CAPWAP Control Channel +----------+
++=========================| AC |
// CAPWAP Data Channel: | |
// IEEE 802.11 Mgmt Traffic | |
// Data Frames +----------+
//
+-----+
| WTP |
+-----+
Figure 2: Centralized Control and Centralized Data
図2：集中管理と集中データ
The key difference with the locally bridged system is that the data frames are tunneled to the AC instead of being locally bridged. There are two shortcomings with the system in Figure 2: 1) it does not allow the WTP to tunnel data frames to an endpoint different from the AC, and 2) it does not allow the WTP to tunnel data frames using any encapsulation other than CAPWAP (as specified in Section 4.4.2 of [RFC5415]).
ローカルブリッジシステムとの主な違いは、データフレームがローカルブリッジではなくACにトンネルされることです。図2のシステムには2つの欠点があります。1）WTPがACとは異なるエンドポイントにデータフレームをトンネリングできない、2）WTPがCAPWAP以外のカプセル化を使用してデータフレームをトンネリングできない（[RFC5415]のセクション4.4.2で指定）。
Figure 3 shows a system where the WTP tunnels data frames to an alternate entity different from the AC. The WTP also uses an alternate tunnel encapsulation such as Layer 2 Tunneling Protocol (L2TP), L2TPv3, IP-in-IP, IP/GRE, etc. This enables 1) independent scaling of data plane and 2) leveraging of commonly used tunnel encapsulations such as L2TP, GRE, etc.
図3は、WTPがデータフレームをACとは異なる代替エンティティにトンネルするシステムを示しています。 WTPは、レイヤー2トンネリングプロトコル（L2TP）、L2TPv3、IP-in-IP、IP / GREなどの代替トンネルカプセル化も使用します。これにより、1）データプレーンの独立したスケーリングと2）一般的に使用されるトンネルカプセル化の活用が可能になります。 L2TP、GREなど
Alternate Tunnel to AR (L2TPv3, IP-IP, CAPWAP, etc.)
_________
+-----+ ( ) +-----------------+
| WTP |======+Internet +==============|Access Router(AR)|
+-----+ (_________) +-----------------+
\\ ________ CAPWAP Control
\\ ( ) Channel +--------+
++=+Internet+========================| AC |
// (________)CAPWAP Data Channel: +--------+
// IEEE 802.11 Mgmt Traffic
// _________
+-----+ ( ) +----------------+
| WTP |====+Internet +================| Access Router |
+-----+ (_________) +----------------+
Alternate Tunnel to AR (L2TPv3, IP-in-IP, CAPWAP, etc.)
Figure 3: Centralized Control with an Alternate Tunnel for Data
図3：データの代替トンネルを使用した集中管理
The WTP may support widely used encapsulation types such as L2TP, L2TPv3, IP-in-IP, IP/GRE, etc. The WTP advertises the different alternate tunnel encapsulation types it can support. The AC configures one of the advertised types. As is shown in Figure 3, there is a CAPWAP Control and Data Channel between the WTP and AC. The CAPWAP Data Channel carries the stations' management traffic, as in the case of the locally bridged system. The main reason to maintain a CAPWAP Data Channel is to maintain similarity with the locally bridged system. The WTP maintains three tunnels: CAPWAP Control, CAPWAP Data, and another alternate tunnel for the data frames. The data frames are transported by an alternate tunnel between the WTP and a tunnel termination point, such as an Access Router. This specification describes how the alternate tunnel can be established. The specification defines message elements for the WTP to advertise support for alternate tunnel encapsulation, for the AC to configure alternate tunnel encapsulation, and for the WTP to report failure of the alternate tunnel.
WTPは、L2TP、L2TPv3、IP-in-IP、IP / GREなどの広く使用されているカプセル化タイプをサポートする場合があります。WTPは、サポートできるさまざまな代替トンネルカプセル化タイプをアドバタイズします。 ACは、アドバタイズされたタイプの1つを構成します。図3に示すように、WTPとACの間にCAPWAPコントロールとデータチャネルがあります。 CAPWAPデータチャネルは、ローカルでブリッジされたシステムの場合と同様に、ステーションの管理トラフィックを伝送します。 CAPWAPデータチャネルを維持する主な理由は、ローカルにブリッジされたシステムとの類似性を維持するためです。 WTPは、CAPWAPコントロール、CAPWAPデータ、およびデータフレーム用のもう1つの代替トンネルの3つのトンネルを維持します。データフレームは、WTPとアクセスルーターなどのトンネルターミネーションポイント間の代替トンネルによって転送されます。この仕様では、代替トンネルを確立する方法について説明します。この仕様では、WTPが代替トンネルカプセル化のサポートをアドバタイズし、ACが代替トンネルカプセル化を構成し、WTPが代替トンネルの障害を報告するためのメッセージ要素を定義しています。
The alternate tunnel encapsulation also supports the third-party WLAN service provider scenario (i.e., Virtual Network Operator (VNO)). Under this scenario, the WLAN provider owns the WTP and AC resources while the VNOs can rent the WTP resources from the WLAN provider for network access. The AC belonging to the WLAN service provider manages the WTPs in the centralized mode.
代替トンネルカプセル化は、サードパーティのWLANサービスプロバイダーシナリオ（つまり、仮想ネットワークオペレーター（VNO））もサポートします。このシナリオでは、WLANプロバイダーがWTPおよびACリソースを所有し、VNOはネットワークアクセスのためにWLANプロバイダーからWTPリソースをレンタルできます。 WLANサービスプロバイダーに属するACは、集中モードでWTPを管理します。
As shown in Figure 4, VNO 1 and VNO 2 don't possess the network access resources; however, they provide services by acquiring resources from the WLAN provider. Since a WTP is capable of supporting up to 16 Service Set Identifiers (SSIDs), the WLAN provider may provide network access service for different providers with different SSIDs. For example, SSID1 is advertised by the WTP for VNO 1 while SSID2 is advertised by the WTP for VNO 2. Therefore, the data traffic from the user can be directly steered to the corresponding Access Router of the VNO who owns that user. As is shown in Figure 4, AC can notify multiple AR addresses for load balancing or redundancy.
図4に示すように、VNO 1とVNO 2はネットワークアクセスリソースを所有していません。ただし、WLANプロバイダーからリソースを取得してサービスを提供します。 WTPは最大16のサービスセット識別子（SSID）をサポートできるため、WLANプロバイダーは、異なるSSIDを持つ異なるプロバイダーにネットワークアクセスサービスを提供できます。たとえば、SSID1はVNO 1のWTPによってアドバタイズされ、SSID2はVNO 2のWTPによってアドバタイズされます。したがって、ユーザーからのデータトラフィックは、そのユーザーを所有するVNOの対応するアクセスルータに直接誘導できます。図4に示すように、ACは複数のARアドレスに通知して、負荷分散または冗長性を実現できます。
+----+
| AC |
+--+-+
CAPWAP-CTL |
+-----------------+
| CAPWAP-DATA: IEEE 802.11 Mgmt Traffic
|
WLAN Provider| VNO 1
+-----+ CAPWAP-DATA (SSID1) +---------------+
SSID1 | WTP +--------------------------|Access Router 1|
SSID2 +--+-++ +---------------+
| |
| | VNO 1
| | GRE-DATA (SSID1) +---------------+
| +---------------------------|Access Router 2|
| +---------------+
|
| VNO 2
| CAPWAP-DATA (SSID2) +---------------+
+-----------------------------|Access Router 3|
+---------------+
Figure 4: Third-Party WLAN Service Provider
図4：サードパーティのWLANサービスプロバイダー
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Station (STA): A device that contains an IEEE 802.11-conformant Medium Access Control (MAC) and Physical layer (PHY) interface to the Wireless Medium (WM).
ステーション（STA）：ワイヤレスメディア（WM）へのIEEE 802.11準拠のメディアアクセス制御（MAC）および物理層（PHY）インターフェイスを含むデバイス。
Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein.
アクセスコントローラー（AC）：データプレーン、コントロールプレーン、管理プレーン、またはそれらの組み合わせでネットワークインフラストラクチャへのWTPアクセスを提供するネットワークエンティティ。
Access Router (AR): A specialized router usually residing at the edge or boundary of a network. This router ensures the connectivity of its network with external networks, a wide area network, or the Internet.
アクセスルーター（AR）：通常、ネットワークのエッジまたは境界にある専用ルーター。このルーターは、外部ネットワーク、広域ネットワーク、またはインターネットとのネットワークの接続を保証します。
Wireless Termination Point (WTP): The physical or network entity that contains a Radio Frequency (RF) antenna and wireless Physical layer (PHY) to transmit and receive station traffic for wireless access networks.
ワイヤレスターミネーションポイント（WTP）：無線アクセスネットワークのステーショントラフィックを送受信するための無線周波数（RF）アンテナとワイヤレス物理層（PHY）を含む物理エンティティまたはネットワークエンティティ。
CAPWAP Control Channel: A bidirectional 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 bidirectional 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. In certain WTP modes, the CAPWAP Data Channel only transports IEEE 802.11 management frames and not the data plane (user traffic).
CAPWAPデータチャネル：AC IPアドレス、WTP IPアドレス、ACデータポート、WTPデータポート、およびCAPWAPデータパケットが送受信されるトランスポート層プロトコル（UDPまたはUDP-Lite）によって定義される双方向フロー。特定のWTPモードでは、CAPWAPデータチャネルはIEEE 802.11管理フレームのみを転送し、データプレーン（ユーザートラフィック）は転送しません。
This document was started to accommodate Service Providers' need of a more flexible deployment mode with alternative tunnels [RFC7494]. Experiments and tests have been done for this alternate tunnel network infrastructure. However important, the deployment of relevant technology is yet to be completed. This Experimental document is intended to serve as an archival record for any future work on the operational and deployment requirements.
このドキュメントは、サービスプロバイダーの代替トンネルを備えたより柔軟な展開モードの必要性に対応するために開始されました[RFC7494]。この代替トンネルネットワークインフラストラクチャに対して実験とテストが行われました。ただし、重要なのは、関連するテクノロジーの導入がまだ完了していないことです。この実験的なドキュメントは、運用および展開の要件に関する今後の作業のアーカイブレコードとして機能することを目的としています。
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| WTP | | AC |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|Join Request [ Supported Alternate |
| Tunnel Encapsulations ] |
|---------------------------------------->|
| |
|Join Response |
|<----------------------------------------|
| |
|IEEE 802.11 WLAN Configuration Request [ |
| IEEE 802.11 Add WLAN, |
| Alternate Tunnel Encapsulation ( |
| Tunnel Type, Tunnel Info Element) |
| ] |
|<----------------------------------------|
| |
| |
+-+-+-+-+-+-+ |
| Setup | |
| Alternate | |
| Tunnel | |
+-+-+-+-+-+-+ |
|IEEE 802.11 WLAN Configuration Response |
|[ Alternate Tunnel Encapsulation ( |
| Tunnel Type, Tunnel Info Element) ] |
|---------------------------------------->|
| |
+-+-+-+-+-+-+ |
| Tunnel | |
| Failure | |
+-+-+-+-+-+-+ |
|WTP Alternate Tunnel Failure Indication |
|(Report Failure (AR Address(es))) |
|---------------------------------------->|
| |
+-+-+-+-+-+-+-+ |
| Tunnel | |
| Established | |
+-+-+-+-+-+-+-+ |
|WTP Alternate Tunnel Failure Indication |
|(Report Clearing Failure) |
|---------------------------------------->|
| |
Figure 5: Setup of an Alternate Tunnel
図5：代替トンネルの設定
The above example describes how the alternate tunnel encapsulation may be established. When the WTP joins the AC, it should indicate its alternate tunnel encapsulation capability. The AC determines whether an alternate tunnel configuration is required. If an appropriate alternate tunnel type is selected, then the AC provides the Alternate Tunnel Encapsulations Type message element containing the tunnel type and a tunnel-specific information element. The tunnel-specific information element, for example, may contain information like the IP address of the tunnel termination point. The WTP sets up the alternate tunnel using the Alternate Tunnel Encapsulations Type message element.
上記の例では、代替トンネルカプセル化を確立する方法を説明しています。 WTPがACに参加すると、代替のトンネルカプセル化機能を示す必要があります。 ACは、代替トンネル構成が必要かどうかを決定します。適切な代替トンネルタイプが選択されている場合、ACは、トンネルタイプとトンネル固有の情報要素を含む代替トンネルカプセル化タイプメッセージ要素を提供します。たとえば、トンネル固有の情報要素には、トンネル終端ポイントのIPアドレスなどの情報が含まれている場合があります。 WTPは、Alternate Tunnel Encapsulations Typeメッセージ要素を使用して代替トンネルをセットアップします。
Since an AC can configure a WTP with more than one AR available for the WTP to establish the data tunnel(s) for user traffic, it may be useful for the WTP to communicate the selected AR. To enable this, the IEEE 802.11 WLAN Configuration Response may carry the Alternate Tunnel Encapsulations Type message element containing the AR list element corresponding to the selected AR as shown in Figure 5.
ACは、WTPがユーザートラフィック用のデータトンネルを確立するために使用可能な複数のARでWTPを構成できるため、WTPが選択したARを通信するのに役立つ場合があります。これを可能にするために、IEEE 802.11 WLAN構成応答は、図5に示すように、選択されたARに対応するARリスト要素を含む代替トンネルカプセル化タイプメッセージ要素を運ぶことができます。
On detecting a tunnel failure, the WTP SHALL forward data frames to the AC and discard the frames. In addition, the WTP may dissociate existing clients and refuse association requests from new clients. Depending on the implementation and deployment scenario, the AC may choose to reconfigure the WLAN (on the WTP) to a Local Bridging mode or to tunnel frames to the AC. When the WTP detects an alternate tunnel failure, the WTP informs the AC using a message element, IEEE 802.11 WTP Alternate Tunnel Failure Indication (defined in Section 3.3). It MAY be carried in the WTP Event Request message, which is defined in [RFC5415].
トンネル障害を検出すると、WTPはデータフレームをACに転送し、フレームを破棄する必要があります。さらに、WTPは既存のクライアントの関連付けを解除し、新しいクライアントからの関連付け要求を拒否する場合があります。実装と展開のシナリオに応じて、ACは（WTPで）WLANをローカルブリッジングモードに再構成するか、フレームをACにトンネルすることを選択できます。 WTPが代替トンネル障害を検出すると、WTPはメッセージ要素であるIEEE 802.11 WTP代替トンネル障害表示（3.3で定義）を使用してACに通知します。これは、[RFC5415]で定義されているWTPイベント要求メッセージで伝達される場合があります。
The WTP also needs to notify the AC of which AR(s) are unavailable. Particularly, in the VNO scenario, the AC of the WLAN service provider needs to maintain the association of the AR addresses of the VNOs and SSIDs and provide this information to the WTP for the purpose of load balancing or master-slave mode.
また、WTPはACに使用できないARを通知する必要があります。特に、VNOシナリオでは、WLANサービスプロバイダーのACは、VNOとSSIDのARアドレスの関連付けを維持し、ロードバランシングまたはマスタースレーブモードのためにこの情報をWTPに提供する必要があります。
The message element has a Status field that indicates whether the message is reporting a failure or clearing the previously reported failure.
メッセージ要素には、メッセージが失敗を報告しているか、以前に報告された失敗をクリアしているかを示すStatusフィールドがあります。
For the case where an AC is unreachable but the tunnel endpoint is still reachable, the WTP behavior is up to the implementation. For example, the WTP could choose to either tear down the alternate tunnel or let the existing user's traffic continue to be tunneled.
ACに到達できなくてもトンネルエンドポイントに到達できる場合、WTPの動作は実装次第です。たとえば、WTPは、代替トンネルを破棄するか、既存のユーザーのトラフィックを引き続きトンネルさせるかを選択できます。
This message element is sent by a WTP to communicate its capability to support alternate tunnel encapsulations. The message element contains the following fields:
このメッセージ要素は、代替トンネルカプセル化をサポートする機能を通信するために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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type 1 | Tunnel-Type 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Tunnel-Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Supported Alternate Tunnel Encapsulations
図6：サポートされる代替トンネルカプセル化
o Type: 54 for Supported Alternate Tunnel Encapsulations Type
o タイプ：サポートされている代替トンネルカプセル化タイプの場合は54
o Length: The length in bytes; two bytes for each Alternative Tunnel-Type that is included
o 長さ：バイト単位の長さ。含まれる代替トンネルタイプごとに2バイト
o Tunnel-Type: This is identified by the value defined in Section 3.2. There may be one or more Tunnel-Types, as is shown in Figure 6.
o トンネルタイプ：セクション3.2で定義された値によって識別されます。図6に示すように、1つ以上のトンネルタイプが存在する場合があります。
This message element can be sent by the AC, allows the AC to select the alternate tunnel encapsulation, and may be provided along with the IEEE 802.11 Add WLAN message element. When the message element is present, the following fields of the IEEE 802.11 Add WLAN element SHALL be set as follows: MAC mode is set to 0 (Local MAC), and Tunnel Mode is set to 0 (Local Bridging). Besides, the message element can also be sent by the WTP to communicate the selected AR(s).
このメッセージ要素は、ACによって送信でき、ACが代替トンネルカプセル化を選択できるようにし、IEEE 802.11 Add WLANメッセージ要素とともに提供される場合があります。メッセージ要素が存在する場合、IEEE 802.11 Add WLAN要素の次のフィールドを次のように設定する必要があります。MACモードは0（ローカルMAC）に設定され、トンネルモードは0（ローカルブリッジング）に設定されます。さらに、メッセージ要素は、選択したARを通信するためにWTPから送信することもできます。
The message element contains the following fields:
メッセージ要素には次のフィールドが含まれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info Element
+-+-+-+-+-+-+-+-+-+
Figure 7: Alternate Tunnel Encapsulations Type
図7：代替トンネルカプセル化タイプ
o Type: 55 for Alternate Tunnel Encapsulations Type
o タイプ：代替トンネルカプセル化タイプの場合は55
o Length: > 4
o 長さ：> 4
o Tunnel-Type: The Tunnel-Type is specified by a 2-byte value. This specification defines the values from 0 to 6 as given below. The remaining values are reserved for future use.
o Tunnel-Type：Tunnel-Typeは2バイトの値で指定されます。この仕様では、以下のように0〜6の値を定義しています。残りの値は、将来の使用のために予約されています。
* 0: CAPWAP. This refers to a CAPWAP Data Channel described in [RFC5415] and [RFC5416].
* 0：CAPWAP。これは、[RFC5415]と[RFC5416]で説明されているCAPWAPデータチャネルを指します。
* 1: L2TP. This refers to tunnel encapsulation described in [RFC2661].
* 1：L2TP。これは、[RFC2661]で説明されているトンネルカプセル化を指します。
* 2: L2TPv3. This refers to tunnel encapsulation described in [RFC3931].
* 2：L2TPv3。これは、[RFC3931]で説明されているトンネルカプセル化を指します。
* 3: IP-in-IP. This refers to tunnel encapsulation described in [RFC2003].
* 3：IP-in-IP。これは、[RFC2003]で説明されているトンネルカプセル化を指します。
* 4: PMIPv6-UDP. This refers to the UDP encapsulation mode for Proxy Mobile IPv6 (PMIPv6) described in [RFC5844]. This encapsulation mode is the basic encapsulation mode and does not include the TLV header specified in Section 7.2 of [RFC5845].
* 4：PMIPv6-UDP。これは、[RFC5844]で説明されているプロキシモバイルIPv6（PMIPv6）のUDPカプセル化モードを指します。このカプセル化モードは基本的なカプセル化モードであり、[RFC5845]のセクション7.2で指定されたTLVヘッダーを含みません。
* 5: GRE. This refers to GRE tunnel encapsulation as described in [RFC2784].
* 5：GRE。これは、[RFC2784]で説明されているGREトンネルカプセル化を指します。
* 6: GTPv1-U. This refers to the GPRS Tunnelling Protocol (GTP) User Plane mode as described in [TS.3GPP.29.281].
* 6：GTPv1-U。これは、[TS.3GPP.29.281]で説明されているGPRSトンネリングプロトコル（GTP）ユーザープレーンモードを指します。
o Info Element: This field contains tunnel-specific configuration parameters to enable the WTP to set up the alternate tunnel. This specification provides details for this element for CAPWAP, PMIPv6, and GRE. This specification reserves the tunnel type values for the key tunnel types and defines the most common message elements. It is anticipated that message elements for the other protocols (like L2TPv3) will be defined in other specifications in the future.
o 情報要素：このフィールドには、WTPが代替トンネルをセットアップできるようにするためのトンネル固有の構成パラメーターが含まれています。この仕様は、CAPWAP、PMIPv6、およびGREのこの要素の詳細を提供します。この仕様では、主要なトンネルタイプのトンネルタイプ値を予約し、最も一般的なメッセージ要素を定義しています。他のプロトコル（L2TPv3など）のメッセージ要素は、将来、他の仕様で定義される予定です。
The WTP MAY include the Alternate Tunnel Failure Indication message in a WTP Event Request message to inform the AC about the status of the alternate tunnel. For the case where the WTP establishes data tunnels with multiple ARs (e.g., under a VNO scenario), the WTP needs to notify the AC of which AR(s) are unavailable. The message element contains the following fields:
WTPは、代替トンネルのステータスについてACに通知するために、WTPイベント要求メッセージに代替トンネル障害表示メッセージを含めることができます（MAY）。 WTPが複数のARを使用してデータトンネルを確立する場合（たとえば、VNOシナリオの場合）、WTPはACに、使用できないARを通知する必要があります。メッセージ要素には次のフィールドが含まれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WLAN ID | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IEEE 802.11 WTP Alternate Tunnel Failure Indication
図8：IEEE 802.11 WTP代替トンネル障害表示
o Type: 1062 for IEEE 802.11 WTP Alternate Tunnel Failure Indication
o タイプ：IEEE 802.11 WTP代替トンネル障害表示の場合は1062
o Length: > 4
o 長さ：> 4
o WLAN ID: An 8-bit value specifying the WLAN Identifier. The value MUST be between 1 and 16.
o WLAN ID：WLAN識別子を指定する8ビットの値。値は1から16の間でなければなりません。
o Status: An 8-bit boolean indicating whether the radio failure is being reported or cleared. A value of 0 is used to clear the event, while a value of 1 is used to report the event.
o ステータス：無線障害が報告されているかクリアされているかを示す8ビットのブール値。値0はイベントのクリアに使用され、値1はイベントの報告に使用されます。
o Reserved: MUST be set to a value of 0 and MUST be ignored by the receiver.
o 予約済み：値0に設定する必要があり、受信者は無視する必要があります。
o Access Router Information Element: The IPv4 or IPv6 address of the Access Router that terminates the alternate tunnel. The Access Router Information Elements allow the WTP to notify the AC of which AR(s) are unavailable.
o アクセスルーター情報要素：代替トンネルを終了するアクセスルーターのIPv4またはIPv6アドレス。アクセスルーター情報要素を使用すると、WTPはACに使用できないARを通知できます。
If the CAPWAP encapsulation is selected by the AC and configured by the AC to the WTP, the Info Element field defined in Section 3.2 SHOULD contain the following information:
CAPWAPカプセル化がACによって選択され、ACによってWTPに構成されている場合、セクション3.2で定義された情報要素フィールドには、以下の情報が含まれている必要があります（SHOULD）。
o Access Router Information: The IPv4 or IPv6 address of the Access Router for the alternate tunnel.
o アクセスルーター情報：代替トンネルのアクセスルーターのIPv4またはIPv6アドレス。
o Tunnel DTLS Policy: The CAPWAP protocol allows optional protection of data packets using DTLS. Use of data packet protection on a WTP is not mandatory but is determined by the associated AC policy. (This is consistent with the WTP behavior described in [RFC5415].)
o トンネルDTLSポリシー：CAPWAPプロトコルでは、DTLSを使用してデータパケットをオプションで保護できます。 WTPでのデータパケット保護の使用は必須ではありませんが、関連するACポリシーによって決定されます。 （これは、[RFC5415]で説明されているWTPの動作と一致しています。）
o IEEE 802.11 Tagging Mode Policy: It is used to specify how the CAPWAP Data Channel packets are to be tagged for QoS purposes (see [RFC5416] for more details).
o IEEE 802.11タギングモードポリシー：QoSの目的でCAPWAPデータチャネルパケットにタグを付ける方法を指定するために使用されます（詳細については、[RFC5416]を参照してください）。
o CAPWAP Transport Protocol: The CAPWAP protocol supports both UDP and UDP-Lite (see [RFC3828]). When run over IPv4, UDP is used for the CAPWAP Data Channels. When run over IPv6, the CAPWAP Data Channel may use either UDP or UDP-Lite.
o CAPWAPトランスポートプロトコル：CAPWAPプロトコルは、UDPとUDP-Liteの両方をサポートします（[RFC3828]を参照）。 IPv4で実行すると、CAPWAPデータチャネルにUDPが使用されます。 IPv6で実行する場合、CAPWAPデータチャネルはUDPまたはUDP-Liteのいずれかを使用できます。
The message element structure for CAPWAP encapsulation is shown in Figure 9:
CAPWAPカプセル化のメッセージ要素構造を図9に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type=0 | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Tunnel DTLS Policy Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IEEE 802.11 Tagging Mode Policy Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. CAPWAP Transport Protocol Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Alternate Tunnel Encapsulation - CAPWAP
図9：代替トンネルカプセル化-CAPWAP
A user plane based on PMIPv6 (defined in [RFC5213]) can also be used as an alternate tunnel encapsulation between the WTP and the AR. In this scenario, a WTP acts as the Mobile Access Gateway (MAG) function that manages the mobility-related signaling for a station that is attached to the WTP IEEE 802.11 radio access. The Local Mobility Anchor (LMA) function is at the AR. If PMIPv6 UDP encapsulation is selected by the AC and configured by the AC to a WTP, the Info Element field defined in Section 3.2 SHOULD contain the following information:
PMIPv6（[RFC5213]で定義）に基づくユーザープレーンは、WTPとAR間の代替トンネルカプセル化としても使用できます。このシナリオでは、WTPは、WTP IEEE 802.11無線アクセスに接続されているステーションのモビリティ関連のシグナリングを管理するモバイルアクセスゲートウェイ（MAG）機能として機能します。ローカルモビリティアンカー（LMA）機能はARにあります。 PMIPv6 UDPカプセル化がACによって選択され、ACによってWTPに構成されている場合、セクション3.2で定義された情報要素フィールドには、以下の情報が含まれている必要があります（SHOULD）。
o Access Router (acting as LMA) Information: IPv4 or IPv6 address for the alternate tunnel endpoint.
o アクセスルーター（LMAとして機能）情報：代替トンネルエンドポイントのIPv4またはIPv6アドレス。
The message element structure for PMIPv6 encapsulation is shown in Figure 10:
PMIPv6カプセル化のメッセージ要素構造を図10に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type=4 | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Alternate Tunnel Encapsulation - PMIPv6
図10：代替トンネルカプセル化-PMIPv6
A user plane based on Generic Routing Encapsulation (defined in [RFC2784]) can also be used as an alternate tunnel encapsulation between the WTP and the AR. In this scenario, a WTP and the Access Router represent the two endpoints of the GRE tunnel. If GRE is selected by the AC and configured by the AC to a WTP, the Info Element field defined in Section 3.2 SHOULD contain the following information:
Generic Routing Encapsulation（[RFC2784]で定義）に基づくユーザープレーンは、WTPとAR間の代替トンネルカプセル化としても使用できます。このシナリオでは、WTPとアクセスルーターがGREトンネルの2つのエンドポイントを表しています。 GREがACによって選択され、ACによってWTPに構成されている場合、セクション3.2で定義された情報要素フィールドには、以下の情報が含まれている必要があります（SHOULD）。
o Access Router Information: The IPv4 or IPv6 address for the alternate tunnel endpoint.
o アクセスルーター情報：代替トンネルエンドポイントのIPv4またはIPv6アドレス。
o GRE Key Information: The Key field is intended to be used for identifying an individual traffic flow within a tunnel [RFC2890].
o GREキー情報：キーフィールドは、トンネル内の個々のトラフィックフローを識別するために使用することを目的としています[RFC2890]。
The message element structure for GRE is shown in Figure 11:
GREのメッセージ要素構造を図11に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type=5 | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. GRE Key Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Alternate Tunnel Encapsulation - GRE
図11：代替トンネルカプセル化-GRE
This section defines the various elements described in Sections 4.1, 4.2, and 4.3.
このセクションでは、セクション4.1、4.2、および4.3で説明されているさまざまな要素を定義します。
These information elements can only be included in the Alternate Tunnel Encapsulations Type message element and the IEEE 802.11 WTP Alternate Tunnel Failure Indication message element as their sub-elements.
これらの情報要素は、代替要素として、代替トンネルカプセル化タイプメッセージ要素とIEEE 802.11 WTP代替トンネル障害表示メッセージ要素にのみ含めることができます。
The Access Router Information Elements allow the AC to notify a WTP of which AR(s) are available for establishing a data tunnel. The AR information may be an IPv4 or IPv6 address. For any Tunnel-Type, this information element SHOULD be included in the Alternate Tunnel Encapsulations Type message element.
アクセスルーター情報要素により、ACはWTPにデータトンネルの確立に使用可能なARを通知できます。 AR情報はIPv4またはIPv6アドレスの場合があります。 Tunnel-Typeの場合、この情報要素は代替トンネルカプセル化タイプのメッセージ要素に含まれる必要があります（SHOULD）。
If the Alternate Tunnel Encapsulations Type message element is sent by the WTP to communicate the selected AR(s), this Access Router Information Element SHOULD be included in it.
選択したARを通信するために代替トンネルカプセル化タイプメッセージ要素がWTPによって送信される場合、このアクセスルーター情報要素をそれに含める必要があります（SHOULD）。
The following are the Access Router Information Elements defined in this specification. The AC can use one of them to notify the WTP about the destination information of the data tunnel. The Elements containing the AR IPv4 address MUST NOT be used if an IPv6 Data Channel with IPv6 transport is used.
以下は、この仕様で定義されているアクセスルーター情報要素です。 ACはそれらの1つを使用して、データトンネルの宛先情報についてWTPに通知できます。 IPv6トランスポートのIPv6データチャネルを使用する場合、AR IPv4アドレスを含む要素を使用してはなりません（MUST NOT）。
This element (see Figure 12) is used by the AC to configure a WTP with the AR IPv4 address available for the WTP to establish the data tunnel for user traffic.
ACはこの要素（図12を参照）を使用して、WTPがユーザートラフィックのデータトンネルを確立するために使用できるAR IPv4アドレスで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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR IPv4 Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv4 Address-1 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv4 Address-2 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv4 Address-N .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: AR IPv4 List Element
図12：AR IPv4リスト要素
Type: 0
タイプ：0
Length: This refers to the total length in octets of the element, excluding the Type and Length fields.
長さ：これは、タイプフィールドと長さフィールドを除く、要素のオクテット単位の全長を指します。
AR IPv4 Address: The IPv4 address of the AR. At least one IPv4 address SHALL be present. Multiple addresses may be provided for load balancing or redundancy.
AR IPv4アドレス：ARのIPv4アドレス。少なくとも1つのIPv4アドレスが存在する必要があります。負荷分散または冗長性のために、複数のアドレスが提供される場合があります。
This element (see Figure 13) is used by the AC to configure a WTP with the AR IPv6 address available for the WTP to establish the data tunnel for user traffic.
ACはこの要素（図13を参照）を使用して、WTPがユーザートラフィックのデータトンネルを確立するために使用できるAR IPv6アドレスで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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR IPv6 Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv6 Address-1 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv6 Address-2 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv6 Address-N .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: AR IPv6 List Element
図13：AR IPv6リスト要素
Type: 1
タイプ：1
Length: This refers to the total length in octets of the element excluding the Type and Length fields.
長さ：これは、タイプおよび長さフィールドを除く、要素のオクテット単位の全長を指します。
AR IPv6 Address: The IPv6 address of the AR. At least one IPv6 address SHALL be present. Multiple addresses may be provided for load balancing or redundancy.
AR IPv6アドレス：ARのIPv6アドレス。少なくとも1つのIPv6アドレスが存在する必要があります。負荷分散または冗長性のために、複数のアドレスが提供される場合があります。
The AC distributes its Datagram Transport Layer Security (DTLS) usage policy for the CAPWAP data tunnel between a WTP and the AR. There are multiple supported options, which are represented by the bit fields below as defined in AC Descriptor message elements. The WTP MUST abide by one of the options for tunneling user traffic with AR. The Tunnel DTLS Policy Element obeys the definition in [RFC5415]. If, for reliability reasons, the AC has provided more than one AR address in the Access Router Information Element, the same Tunnel DTLS Policy (the last one in Figure 14) is generally applied for all tunnels associated with those ARs. Otherwise, Tunnel DTLS Policy MUST be bonded together with each of the Access Router Information Elements, and the WTP will enforce the independent tunnel DTLS policy for each tunnel with a specific AR.
ACは、WTPとARの間のCAPWAPデータトンネルのデータグラムトランスポート層セキュリティ（DTLS）使用ポリシーを配布します。サポートされている複数のオプションがあり、AC記述子メッセージ要素で定義されている以下のビットフィールドで表されます。 WTPは、ARでユーザートラフィックをトンネリングするためのオプションの1つに従う必要があります。トンネルDTLSポリシー要素は、[RFC5415]の定義に従います。信頼性の理由で、ACがアクセスルーター情報要素に複数のARアドレスを提供した場合、同じトンネルDTLSポリシー（図14の最後のポリシー）は一般に、それらのARに関連付けられたすべてのトンネルに適用されます。それ以外の場合、トンネルDTLSポリシーは各アクセスルータ情報要素と結合する必要があり、WTPは特定のARを持つ各トンネルに独立したトンネル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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tunnel DTLS Policy Element Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D|C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D|C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ...... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D|C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Tunnel DTLS Policy Element
図14：トンネルDTLSポリシー要素
Type: 2
タイプ：2
Length: This refers to the total length in octets of the element excluding the Type and Length fields.
長さ：これは、タイプおよび長さフィールドを除く、要素のオクテット単位の全長を指します。
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to 0 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.
予約済み：将来使用するための予約済みビットのセット。このプロトコルに準拠するすべての実装は、その実装でサポートされているプロトコルのバージョンで予約されているビットを0に設定する必要があります。レシーバーは、サポートするプロトコルのバージョンに対して定義されていないすべてのビットを無視する必要があります。
D: DTLS-Enabled Data Channel Supported (see [RFC5415]).
D：DTLS対応のデータチャネルをサポート（[RFC5415]を参照）。
C: Clear Text Data Channel Supported (see [RFC5415]).
C：クリアテキストデータチャネルをサポート（[RFC5415]を参照）。
R: A reserved bit for future use (see [RFC5415]).
R：将来使用するための予約済みビット（[RFC5415]を参照）。
AR Information: This means Access Router Information Element. In this context, each address in AR Information MUST be one of previously specified AR addresses.
AR情報：これは、アクセスルーター情報要素を意味します。このコンテキストでは、AR情報の各アドレスは、以前に指定されたARアドレスの1つである必要があります。
In Figure 14, the last element that has no AR Information is the default tunnel DTLS policy, which provides options for any address not previously mentioned. Therefore, the AR Information field here is optional. In this element, if all ARs share the same tunnel DTLS policy, there won't be an AR Information field or its specific tunnel DTLS policy.
図14で、AR情報を持たない最後の要素はデフォルトのトンネルDTLSポリシーで、これは前述のアドレスにオプションを提供します。したがって、ここのAR情報フィールドはオプションです。この要素では、すべてのARが同じトンネルDTLSポリシーを共有する場合、AR情報フィールドまたはその特定のトンネルDTLSポリシーはありません。
In IEEE 802.11 networks, the IEEE 802.11 Tagging Mode Policy Element is used to specify how the WTP applies the QoS tagging policy when receiving the packets from stations on a particular radio. When the WTP sends out the packet to data channel to the AR(s), the packets have to be tagged for QoS purposes (see [RFC5416]).
IEEE 802.11ネットワークでは、IEEE 802.11タグモードポリシー要素を使用して、特定の無線のステーションからパケットを受信するときに、WTPがQoSタグポリシーを適用する方法を指定します。 WTPがパケットをデータチャネルに送信してARに送信する場合、QoSの目的でパケットにタグを付ける必要があります（[RFC5416]を参照）。
The IEEE 802.11 Tagging Mode Policy abides by the IEEE 802.11 WTP Quality of Service defined in Section 6.22 of [RFC5416].
IEEE 802.11タギングモードポリシーは、[RFC5416]のセクション6.22で定義されているIEEE 802.11 WTPサービス品質に準拠しています。
If, for reliability reasons, the AC has provided more than one AR address in the Access Router Information Element, the same IEEE 802.11 Tagging Mode Policy (the last one in Figure 15) is generally applied for all tunnels associated with those ARs. Otherwise, IEEE 802.11 Tagging Mode Policy MUST be bonded together with each of the Access Router Information Elements, and the WTP will enforce the independent IEEE 802.11 Tagging Mode Policy for each tunnel with a specific AR.
信頼性の理由で、ACがアクセスルーター情報要素で複数のARアドレスを提供した場合、同じIEEE 802.11タグ付けモードポリシー（図15の最後のポリシー）が、それらのARに関連付けられたすべてのトンネルに通常適用されます。それ以外の場合、IEEE 802.11タギングモードポリシーは各アクセスルーター情報要素と結合する必要があり、WTPは特定のARを持つ各トンネルに独立したIEEE 802.11タギングモードポリシーを適用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tagging Mode Policy Ele. Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |P|Q|D|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |P|Q|D|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ...... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |P|Q|D|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: IEEE 802.11 Tagging Mode Policy Element
図15：IEEE 802.11タギングモードポリシー要素
Type: 3
タイプ：3
Length: This refers to the total length in octets of the element excluding the Type and Length fields.
長さ：これは、タイプおよび長さフィールドを除く、要素のオクテット単位の全長を指します。
Reserved: A set of reserved bits for future use.
予約済み：将来使用するための予約済みビットのセット。
P: When set, the WTP is to employ the IEEE 802.1p QoS mechanism (see [RFC5416]).
P：設定すると、WTPはIEEE 802.1p QoSメカニズムを採用します（[RFC5416]を参照）。
Q: When the 'P' bit is set, the 'Q' bit is used by the AC to communicate to the WTP how IEEE 802.1p QoS is to be enforced (see [RFC5416]).
Q：「P」ビットが設定されている場合、「Q」ビットはACによって使用され、IEEE 802.1p QoSがどのように施行されるかをWTPに通信します（[RFC5416]を参照）。
D: When set, the WTP is to employ the DSCP QoS mechanism (see [RFC5416]).
D：設定すると、WTPはDSCP QoSメカニズムを採用します（[RFC5416]を参照）。
O: When the 'D' bit is set, the 'O' bit is used by the AC to communicate to the WTP how Differentiated Services Code Point (DSCP) QoS is to be enforced on the outer (tunneled) header (see [RFC5416]).
O：「D」ビットが設定されている場合、「O」ビットはACがWTPと通信するために使用され、DTP（Differentiated Services Code Point）QoSが外部（トンネル）ヘッダーに適用される方法を伝えます（[RFC5416 ]）。
I: When the 'D' bit is set, the 'I' bit is used by the AC to communicate to the WTP how DSCP QoS is to be enforced on the station's packet (inner) header (see [RFC5416]).
I：「D」ビットが設定されている場合、「I」ビットはACがWTPに通信するために使用され、ステーションのパケット（内部）ヘッダーにDSCP QoSを適用する方法を伝えます（[RFC5416]を参照）。
AR Information: This means Access Router Information Element. In this context, each address in AR information MUST be one of the previously specified AR addresses.
AR情報：これは、アクセスルーター情報要素を意味します。このコンテキストでは、AR情報の各アドレスは、以前に指定されたARアドレスの1つである必要があります。
In Figure 15, the last element that has no AR information is the default IEEE 802.11 Tagging Mode Policy, which provides options for any address not previously mentioned. Therefore, the AR Information field here is optional. If all ARs share the same IEEE 802.11 Tagging Mode Policy, in this element, there will not be an AR Information field and its specific IEEE 802.11 Tagging Mode Policy.
図15で、AR情報を持たない最後の要素は、デフォルトのIEEE 802.11 Tagging Mode Policyであり、これは前述のアドレスにオプションを提供します。したがって、ここのAR情報フィールドはオプションです。すべてのARが同じIEEE 802.11タグモードポリシーを共有する場合、この要素には、AR情報フィールドとその特定のIEEE 802.11タグモードポリシーはありません。
The CAPWAP data tunnel supports both UDP and UDP-Lite (see [RFC3828]). When run over IPv4, UDP is used for the CAPWAP Data Channels. When run over IPv6, the CAPWAP Data Channel may use either UDP or UDP-Lite. The AC specifies and configures the WTP for which the transport protocol is to be used for the CAPWAP data tunnel.
CAPWAPデータトンネルは、UDPとUDP-Liteの両方をサポートします（[RFC3828]を参照）。 IPv4で実行すると、CAPWAPデータチャネルにUDPが使用されます。 IPv6で実行する場合、CAPWAPデータチャネルはUDPまたはUDP-Liteのいずれかを使用できます。 ACは、CAPWAPデータトンネルにトランスポートプロトコルを使用するWTPを指定および構成します。
The CAPWAP Transport Protocol Element abides by the definition in Section 4.6.14 of [RFC5415].
CAPWAPトランスポートプロトコル要素は、[RFC5415]のセクション4.6.14の定義に従います。
If, for reliability reasons, the AC has provided more than one AR address in the Access Router Information Element, the same CAPWAP Transport Protocol (the last one in Figure 16) is generally applied for all tunnels associated with those ARs. Otherwise, CAPWAP Transport Protocol MUST be bonded together with each of the Access Router Information Elements, and the WTP will enforce the independent CAPWAP Transport Protocol for each tunnel with a specific AR.
信頼性の理由で、ACがアクセスルーター情報要素に複数のARアドレスを提供した場合、同じCAPWAPトランスポートプロトコル（図16の最後のプロトコル）は通常、それらのARに関連付けられたすべてのトンネルに適用されます。それ以外の場合は、CAPWAPトランスポートプロトコルを各アクセスルータ情報要素と結合する必要があり、WTPは特定のARを持つ各トンネルに独立した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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ...... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: CAPWAP Transport Protocol Element
図16：CAPWAPトランスポートプロトコル要素
Type: 4
タイプ：4
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 and if the AR address contained in the AR Information Element is an IPv4 address.
1-UDP-Lite：UDP-LiteトランスポートプロトコルはCAPWAPデータチャネルに使用されます。 CAPWAP制御チャネルがIPv4で使用されている場合、およびAR情報要素に含まれているARアドレスがIPv4アドレスである場合、このオプションを使用してはならないことに注意してください。
2 - UDP: The UDP transport protocol is to be used for the CAPWAP Data Channel.
2-UDP：UDPトランスポートプロトコルはCAPWAPデータチャネルに使用されます。
AR Information: This means Access Router Information Element. In this context, each address in AR information MUST be one of the previously specified AR addresses.
AR情報：これは、アクセスルーター情報要素を意味します。このコンテキストでは、AR情報の各アドレスは、以前に指定されたARアドレスの1つである必要があります。
In Figure 16, the last element that has no AR information is the default CAPWAP Transport Protocol, which provides options for any address not previously mentioned. Therefore, the AR Information field here is optional. If all ARs share the same CAPWAP Transport Protocol, in this element, there will not be an AR Information field and its specific CAPWAP Transport Protocol.
図16で、AR情報を持たない最後の要素はデフォルトのCAPWAPトランスポートプロトコルで、これは前述のアドレスにオプションを提供します。したがって、ここのAR情報フィールドはオプションです。すべてのARが同じCAPWAPトランスポートプロトコルを共有する場合、この要素には、AR情報フィールドとその特定のCAPWAPトランスポートプロトコルはありません。
If a WTP receives the GRE Key Element in the Alternate Tunnel Encapsulations Type message element for GRE selection, the WTP MUST insert the GRE Key to the encapsulation packet (see [RFC2890]). An AR acting as a decapsulating tunnel endpoint identifies packets belonging to a traffic flow based on the Key value.
WTPがGRE選択の代替トンネルカプセル化タイプメッセージ要素でGREキー要素を受信する場合、WTPはカプセル化パケットにGREキーを挿入する必要があります（[RFC2890]を参照）。カプセル開放トンネルエンドポイントとして機能するARは、キー値に基づいて、トラフィックフローに属するパケットを識別します。
The GRE Key Element field contains a 4-octet number defined in [RFC2890].
GRE Key Elementフィールドには、[RFC2890]で定義されている4オクテット番号が含まれています。
If, for reliability reasons, the AC has provided more than one AR address in the Access Router Information Element, a GRE Key Element MAY be bonded together with each of the Access Router Information Elements, and the WTP will enforce the independent GRE Key for each tunnel with a specific AR.
信頼性の理由で、ACがアクセスルーター情報要素に複数のARアドレスを提供した場合、GREキー要素を各アクセスルーター情報要素と結合することができ、WTPはそれぞれに独立したGREキーを適用します特定のARのトンネル。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ...... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: GRE Key Element
図17：GREキー要素
Type: 5
タイプ：5
Length: This refers to the total length in octets of the element excluding the Type and Length fields.
長さ：これは、タイプおよび長さフィールドを除く、要素のオクテット単位の全長を指します。
GRE Key: The Key field contains a 4-octet number that is inserted by the WTP according to [RFC2890].
GREキー：キーフィールドには、[RFC2890]に従ってWTPによって挿入される4オクテット番号が含まれます。
AR Information: This means Access Router Information Element. In this context, it SHOULD be restricted to a single address and MUST be the address of one of previously specified AR addresses.
AR情報：これは、アクセスルーター情報要素を意味します。この文脈では、それは単一のアドレスに制限されるべきで（SHOULD）、以前に指定されたARアドレスの1つのアドレスでなければなりません。
Any address not explicitly mentioned here does not have a GRE key.
ここで明示的に言及されていないアドレスにはGREキーがありません。
If AC has chosen a tunneling mechanism based on IPv6, it SHOULD support the minimum IPv6 MTU requirements [RFC8200]. This issue is described in [ARCH-TUNNELS]. AC SHOULD inform the WTP about the IPv6 MTU information in the Tunnel Info Element field.
ACがIPv6に基づくトンネリングメカニズムを選択した場合、それは最小IPv6 MTU要件[RFC8200]をサポートする必要があります（SHOULD）。この問題は、[ARCH-TUNNELS]で説明されています。 AC SHOULDは、トンネル情報要素フィールドのIPv6 MTU情報についてWTPに通知する必要があります。
If, for reliability reasons, the AC has provided more than one AR address in the Access Router Information Element, an IPv6 MTU Element MAY be bonded together with each of the Access Router Information Elements, and the WTP will enforce the independent IPv6 MTU for each tunnel with a specific AR.
信頼性の理由で、ACがアクセスルーター情報要素に複数のARアドレスを提供した場合、IPv6 MTU要素を各アクセスルーター情報要素と結合することができ、WTPはそれぞれに独立したIPv6 MTUを適用します特定のARのトンネル。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 MTU Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum IPv6 MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum IPv6 MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: IPv6 MTU Element
図18：IPv6 MTU要素
Type: 6
タイプ：6
Length: This refers to the total length in octets of the element excluding the Type and Length fields.
長さ：これは、タイプおよび長さフィールドを除く、要素のオクテット単位の全長を指します。
Minimum IPv6 MTU: The field contains a 2-octet number indicating the minimum IPv6 MTU in the tunnel.
最小IPv6 MTU：このフィールドには、トンネル内の最小IPv6 MTUを示す2オクテット番号が含まれています。
AR Information: This means Access Router Information Element. In this context, each address in AR information MUST be one of previously specified AR addresses.
AR情報：これは、アクセスルーター情報要素を意味します。このコンテキストでは、AR情報の各アドレスは、以前に指定されたARアドレスの1つである必要があります。
Per this document, IANA has registered the following values in the existing "CAPWAP Message Element Type" registry, defined in [RFC5415].
このドキュメントによれば、IANAは、[RFC5415]で定義されている既存の「CAPWAPメッセージ要素タイプ」レジストリに次の値を登録しています。
o 54: Supported Alternate Tunnel Encapsulations Type as defined in Section 3.1.
o 54：セクション3.1で定義されている、サポートされる代替トンネルカプセル化タイプ。
o 55: Alternate Tunnel Encapsulations Type as defined in Section 3.2.
o 55：セクション3.2で定義されている代替トンネルカプセル化タイプ。
o 1062: IEEE 802.11 WTP Alternate Tunnel Failure Indication as defined in Section 3.3.
o 1062：セクション3.3で定義されているIEEE 802.11 WTP代替トンネル障害表示。
Per this document, IANA has created a registry called "Alternate Tunnel-Types" under "CAPWAP Parameters". This specification defines the Alternate Tunnel Encapsulations Type message element. This element contains a field Tunnel-Type. The namespace for the field is 16 bits (0-65535). This specification defines values 0 through 6 and can be found in Section 3.2. Future allocations of values in this namespace are to be assigned by IANA using the "Specification Required" policy [RFC8126]. The registry format is given below.
このドキュメントに従って、IANAは「CAPWAP Parameters」の下に「Alternate Tunnel-Types」と呼ばれるレジストリを作成しました。この仕様は、Alternate Tunnel Encapsulations Typeメッセージ要素を定義します。この要素には、フィールドTunnel-Typeが含まれています。フィールドの名前空間は16ビット（0〜65535）です。この仕様は0から6までの値を定義しており、セクション3.2に記載されています。この名前空間の値の将来の割り当ては、「仕様が必要です」ポリシー[RFC8126]を使用してIANAによって割り当てられます。レジストリの形式は次のとおりです。
Description Value Reference
CAPWAP 0 [RFC5415] [RFC5416]
L2TP 1 [RFC2661]
L2TPv3 2 [RFC3931]
IP-IP 3 [RFC2003]
PMIPv6-UDP 4 [RFC5844]
GRE 5 [RFC2784]
GTPv1-U 6 [TS.3GPP.29.281]
Per this document, IANA has created a registry called "Alternate Tunnel Sub-elements" under "CAPWAP Parameters". This specification defines the Alternate Tunnel Sub-elements. Currently, these information elements can only be included in the Alternate Tunnel Encapsulations Type message element with the IEEE 802.11 WTP Alternate Tunnel Failure Indication message element as its sub-elements. These information elements contain a Type field. The namespace for the field is 16 bits (0-65535). This specification defines values 0 through 6 in Section 5. This namespace is managed by IANA, and assignments require an Expert Review [RFC8126].
このドキュメントに従って、IANAは「CAPWAP Parameters」の下に「Alternate Tunnel Sub-elements」と呼ばれるレジストリを作成しました。この仕様は、代替トンネルサブエレメントを定義しています。現在、これらの情報要素は、IEEE 802.11 WTP代替トンネル障害表示メッセージ要素をサブ要素として持つ代替トンネルカプセル化タイプメッセージ要素にのみ含めることができます。これらの情報要素には、Typeフィールドが含まれています。フィールドの名前空間は16ビット（0〜65535）です。この仕様では、セクション5で0〜6の値を定義しています。この名前空間はIANAによって管理されており、割り当てにはエキスパートレビュー[RFC8126]が必要です。
Description Value AR IPv4 List 0 AR IPv6 List 1 Tunnel DTLS Policy 2 IEEE 802.11 Tagging Mode Policy 3 CAPWAP Transport Protocol 4 GRE Key 5 IPv6 MTU 6
説明値AR IPv4リスト0 AR IPv6リスト1トンネルDTLSポリシー2 IEEE 802.11タギングモードポリシー3 CAPWAPトランスポートプロトコル4 GREキー5 IPv6 MTU 6
This document introduces three new CAPWAP WTP message elements. These elements are transported within CAPWAP Control messages as the existing message elements. Therefore, this document does not introduce any new security risks to the control plane compared to [RFC5415] and [RFC5416]. In the data plane, if the encapsulation type selected itself is not secured, it is suggested to protect the tunnel by using known secure methods, such as IPsec.
このドキュメントでは、3つの新しいCAPWAP WTPメッセージ要素を紹介します。これらの要素は、CAPWAPコントロールメッセージ内で既存のメッセージ要素として転送されます。したがって、このドキュメントでは、[RFC5415]および[RFC5416]と比較して、コントロールプレーンに新しいセキュリティリスクを導入していません。データプレーンでは、選択されたカプセル化タイプ自体が保護されていない場合、IPsecなどの既知の安全な方法を使用してトンネルを保護することをお勧めします。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, <https://www.rfc-editor.org/info/rfc2003>.
[RFC2003]パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、DOI 10.17487 / RFC2003、1996年10月、<https://www.rfc-editor.org/info/rfc2003>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, DOI 10.17487/RFC2661, August 1999, <https://www.rfc-editor.org/info/rfc2661>.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター、「レイヤー2トンネリングプロトコル "L2TP"」、RFC 2661、DOI 10.17487 / RFC2661 、1999年8月、<https://www.rfc-editor.org/info/rfc2661>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T。、ハンクス、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<https ：//www.rfc-editor.org/info/rfc2784>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
[RFC2890] Dommety、G。、「Key and Sequence Number Extensions to GRE」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<https://www.rfc-editor.org/info/rfc2890>。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <https://www.rfc-editor.org/info/rfc3828>.
[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<https://www.rfc-editor.org/info/rfc3828>。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <https://www.rfc-editor.org/info/rfc3931>.
[RFC3931] Lau、J.、Ed。、Townsley、M.、Ed。、I。Goyret、Ed。、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、DOI 10.17487 / RFC3931、2005年3月、<https://www.rfc-editor.org/info/rfc3931>。
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, <https://www.rfc-editor.org/info/rfc5415>.
[RFC5415] Calhoun、P.、Ed。、Montemurro、M.、Ed。、and D. Stanley、Ed。、 "Control And Provisioning of Wireless Access Points（CAPWAP）Protocol Specification"、RFC 5415、DOI 10.17487 / RFC5415、 2009年3月、<https://www.rfc-editor.org/info/rfc5415>。
[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, DOI 10.17487/RFC5416, March 2009, <https://www.rfc-editor.org/info/rfc5416>.
[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、DOI 10.17487 / RFC5416、2009年3月、<https://www.rfc-editor.org/info/rfc5416>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[ARCH-TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, draft-ietf-intarea-tunnels-08, January 2018.
[ARCH-TUNNELS] Touch、J。およびM. Townsley、「インターネットアーキテクチャのIPトンネル」、作業中、draft-ietf-intarea-tunnels-08、2018年1月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <https://www.rfc-editor.org/info/rfc5213>.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、DOI 10.17487 / RFC5213、August 2008、<https ：//www.rfc-editor.org/info/rfc5213>。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, <https://www.rfc-editor.org/info/rfc5844>.
[RFC5844]脇川、R.、S。ガンダベリ、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、DOI 10.17487 / RFC5844、2010年5月、<https://www.rfc-editor.org/info/rfc5844>。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, <https://www.rfc-editor.org/info/rfc5845>.
[RFC5845] Muhanna、A.、Khalil、M.、Gundavelli、S。、およびK. Leung、「Generic Routing Encapsulation（GRE）Key Option for Proxy Mobile IPv6」、RFC 5845、DOI 10.17487 / RFC5845、2010年6月、< https://www.rfc-editor.org/info/rfc5845>。
[RFC7494] Shao, C., Deng, H., Pazhyannur, R., Bari, F., Zhang, R., and S. Matsushima, "IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 7494, DOI 10.17487/RFC7494, April 2015, <https://www.rfc-editor.org/info/rfc7494>.
[RFC7494] Shao、C.、Deng、H.、Pazhyannur、R.、Bari、F.、Zhang、R.、S。Matsushima、「IEEE 802.11 Medium Access Control（MAC）Profile for Control and Provisioning of Wireless Accessポイント（CAPWAP）」、RFC 7494、DOI 10.17487 / RFC7494、2015年4月、<https://www.rfc-editor.org/info/rfc7494>。
[TS.3GPP.29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281, V13.1.0, March 2016.
[TS.3GPP.29.281] 3GPP、「General Packet Radio System（GPRS）Tunneling Protocol User Plane（GTPv1-U）」、3GPP TS 29.281、V13.1.0、March 2016。
Contributors
貢献者
The authors would like to thank Andreas Schultz, Hong Liu, Yifan Chen, Chunju Shao, Li Xue, Jianjie You, Jin Li, Joe Touch, Alexey Melnikov, Kathleen Moriarty, Mirja Kuehlewind, Catherine Meadows, and Paul Kyzivat for their valuable comments.
著者は、貴重なコメントを提供してくれたAndreas Schultz、Hong Liu、Yifan Chen、Chunju Shao、Li Xue、Jianjie You、Jin Li、Joe Touch、Alexey Melnikov、Kathleen Moriarty、Mirja Kuehlewind、Catherine Meadows、Paul Kyzivatに感謝します。
Authors' Addresses
著者のアドレス
Rong Zhang China Telecom No.109 Zhongshandadao avenue Guangzhou 510630 China
Ron and Zhang China通信no.109 Z Hongshanが510630中国広州に到着
Email: zhangr@gsta.com
Rajesh S. Pazhyannur Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
Rajesh S. Pazhyannur Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: rpazhyan@cisco.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: sgundave@cisco.com
Zhen Cao Huawei Xinxi Rd. 3 Beijing 100085 China
ZおよびNCああああUAはシステムRDでXです。3北京100085中国
Email: zhencao.ietf@gmail.com Hui Deng Huawei Xinxi Rd. 3 Beijing 100085 China
メール：Chastity。I ETF@Gmail.com Hui den GH UAはRDでXです。3北京100085中国
Email: denghui02@gmail.com
Zongpeng Du Huawei No.156 Beiqing Rd. Z-park, HaiDian District Beijing 100095 China
Z on Gaopeng duh UA is no.156 be i青RD。Z-park、ha ID Ian District Beijing 100095 China
Email: duzongpeng@huawei.com