[要約] RFC 4951は、L2TPのフェイルオーバー拡張機能である"failover"についての要約と目的を提供しています。この拡張機能は、L2TPトンネルの冗長性と可用性を向上させることを目的としています。
Network Working Group V. Jain, Ed.
Request for Comments: 4951 Riverstone Networks
Category: Standards Track August 2007
Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
レイヤー2トンネリングプロトコル（L2TP）の拡張機能を失敗
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) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity.
レイヤー2トンネルプロトコル（L2TP）は、アクティブエンドポイント間で共有状態を持つ接続指向のプロトコルです。この共有状態の一部は動作に不可欠ですが、L2TP制御接続で使用されるパケットシーケンス番号など、本質的に揮発性がある場合があります。制御接続の片側の故障が発生すると、古い接続に関する情報を交換することにより、新しい制御接続が作成され、古い接続に関連付けられます。このようなメカニズムは、いくつかのミラーリングされた接続状態でのアクティブな失敗の代替品としてではなく、すぐに利用できることが特に困難なパラメーターの援助として意図されています。このドキュメントで定義されているL2TPへのプロトコル拡張は、状態回復を促進し、L2TPネットワークで追加の回復力を提供し、リモートシステムのレイヤー2接続を改善することを目的としています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Abbreviations ..............................................5
1.3. Specification of Requirements ..............................5
2. Overview ........................................................5
3. Failover Protocol ...............................................7
3.1. Failover Capability Negotiation ............................7
3.2. Failover Recovery Procedure ................................7
3.2.1. Recovery Tunnel Establishment .......................8
3.2.2. Control Channel Reset ..............................10
3.2.3. Data Channel Reset .................................10
3.3. Session State Synchronization .............................11
4. New Control Messages ...........................................12
4.1. Failover Session Query ....................................13
4.2. Failover Session Response .................................13
5. New Attribute Value Pairs ......................................14
5.1. Failover Capability AVP ...................................14
5.2. Tunnel Recovery AVP .......................................15
5.3. Suggested Control Sequence AVP ............................16
5.4. Failover Session State AVP ................................17
6. Configuration Parameters .......................................18
7. IANA Considerations ............................................19
8. Security Considerations ........................................19
9. Acknowledgements ...............................................19
10. Contributors ..................................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................20
Appendix A ........................................................21
Appendix B ........................................................23
Appendix C ........................................................24
The goal of this document is to aid the overall resiliency of an L2TP endpoint by introducing extensions to RFC 2661 [L2TPv2] and RFC 3931 [L2TPv3] that will minimize the recovery time of the L2TP layer after a failover, while minimizing the impact on its performance. Therefore, it is assumed that the endpoint's overall architecture is also supportive in the resiliency effort.
このドキュメントの目標は、RFC 2661 [L2TPV2]およびRFC 3931 [L2TPV3]に拡張機能を導入することにより、L2TPエンドポイントの全体的な回復力を支援することです。パフォーマンス。したがって、エンドポイントの全体的なアーキテクチャは、回復力の取り組みにも支持的であると想定されています。
To ensure proper operation of an L2TP endpoint after a failover, the associated information of the control connection and sessions between them must be correct and consistent. This includes both the configured and dynamic information. The configured information is assumed to be correct and consistent after a failover, otherwise the tunnels and sessions would not have been setup in the first place.
フェールオーバー後にL2TPエンドポイントの適切な操作を確保するには、制御接続の関連情報とそれらの間のセッションは正しく一貫している必要があります。これには、構成された情報と動的情報の両方が含まれます。構成された情報は、フェールオーバー後に正しく一貫していると想定されています。そうしないと、トンネルとセッションはそもそもセットアップされていませんでした。
The dynamic information, which is also referred to as stateful information, changes with the processing of the tunnel's control and data packets. Currently, the only such information that is essential to the tunnel's operation is its sequence numbers. For the tunnel control channel, the inconsistencies in its sequence numbers can result in the termination of the entire tunnel. For tunnel sessions, the inconsistency in its sequence numbers, when used, can cause significant data loss, which gives the perception of a "service loss" to the end user.
ステートフル情報とも呼ばれる動的情報は、トンネルの制御およびデータパケットの処理によって変更されます。現在、トンネルの操作に不可欠なそのような情報は、そのシーケンス番号です。トンネル制御チャネルの場合、シーケンス数の矛盾により、トンネル全体が終了する可能性があります。トンネルセッションの場合、そのシーケンス数の矛盾は、使用すると、大きなデータ損失を引き起こす可能性があり、エンドユーザーに「サービス損失」の認識が得られます。
Thus, an optimal resilient architecture that aims to minimize "service loss" after a failover, must make provisions for the tunnel's essential stateful information, i.e., its sequence numbers. Currently, there are two options available: the first option is to ensure that the backup endpoint is completely synchronized with the active endpoint, with respect to the control and data sessions sequence numbers. The other option is to reestablish all the tunnels and their sessions after a failover. The drawback of the first option is that it adds significant performance and complexity impact to the endpoint's architecture, especially as tunnel and session aggregation increases. The drawback of the second option is that it increases the "service loss" time, especially as the architecture scales.
したがって、フェールオーバー後の「サービス損失」を最小限に抑えることを目的とする最適な回復力のあるアーキテクチャは、トンネルの本質的な状態情報、つまりそのシーケンス番号の規定を作成する必要があります。現在、利用可能な2つのオプションがあります。最初のオプションは、制御およびデータセッションのシーケンス番号に関して、バックアップエンドポイントがアクティブエンドポイントと完全に同期されるようにすることです。もう1つのオプションは、フェイルオーバー後にすべてのトンネルとそのセッションを再確立することです。最初のオプションの欠点は、特にトンネルとセッションの集約が増加するにつれて、エンドポイントのアーキテクチャに大きなパフォーマンスと複雑さの影響を追加することです。2番目のオプションの欠点は、特にアーキテクチャスケールとして、「サービスの損失」時間を増やすことです。
To alleviate the above-mentioned drawbacks of the current options, this document introduces a mechanism to bring the dynamic stateful information of a tunnel to a correct and consistent state after a failure. The proposed mechanism defines the recovery of tunnels and sessions that were in an established state prior to the failure.
現在のオプションの上記の欠点を軽減するために、このドキュメントは、故障後にトンネルの動的なステートフルな情報を正しい状態にもたらすメカニズムを紹介します。提案されたメカニズムは、故障前に確立された状態にあったトンネルとセッションの回復を定義します。
Endpoint: L2TP control connection endpoint, i.e., either LAC or LNS (also known as LCCE in [L2TPv3]).
エンドポイント：L2TP制御接続エンドポイント、つまり、LACまたはLNS（[L2TPV3]でLCCEとも呼ばれます）。
Active Endpoint: An endpoint that is currently providing service.
アクティブエンドポイント：現在サービスを提供しているエンドポイント。
Backup Endpoint: A redundant endpoint standing by for the active endpoint that has its database of active tunnels and sessions in sync with its active endpoint.
バックアップエンドポイント：アクティブなトンネルとセッションのデータベースがアクティブエンドポイントと同期しているアクティブエンドポイントのために、冗長なエンドポイントが耐えられます。
Failed Endpoint: The endpoint that was the active endpoint at the time of the failure.
失敗したエンドポイント：障害時にアクティブなエンドポイントであったエンドポイント。
Recovery Endpoint: The endpoint that initiates the failover protocol to recover from the failure of an active endpoint.
回復エンドポイント：フェイルオーバープロトコルを開始してアクティブエンドポイントの障害から回復するエンドポイント。
Remote Endpoint: The endpoint that peers with active endpoint before failure and with recovery endpoint after failure.
リモートエンドポイント：故障前にアクティブなエンドポイントを備えたピアが、障害後に回復エンドポイントを使用するエンドポイント。
Failover: The action of a backup endpoint taking over the service of an active endpoint. This could be due to administrative action or failure of the active endpoint.
フェールオーバー：アクティブエンドポイントのサービスを引き継ぐバックアップエンドポイントのアクション。これは、管理アクションまたはアクティブエンドポイントの障害が原因である可能性があります。
Old Tunnel: A control connection that existed before failure and is subjected to recovery upon failover.
古いトンネル：故障前に存在し、フェールオーバー時に回復する制御接続。
Recovery Tunnel: A new control connection established only to recover an old tunnel.
回復トンネル：古いトンネルを回収するためにのみ確立された新しい制御接続。
Recovered Tunnel: After an old tunnel's control connection and sessions are restored using the mechanism described in this document, it is referred to as a Recovered Tunnel.
回収されたトンネル：古いトンネルの制御接続とセッションがこのドキュメントで説明されているメカニズムを使用して復元された後、回収されたトンネルと呼ばれます。
Control Channel Failure: Failure of the component responsible for establishing/maintaining tunnels and sessions at an endpoint.
制御チャネルの故障：エンドポイントでトンネルとセッションの確立/保守を担当するコンポーネントの障害。
Data Channel Failure: Failure of the component responsible for forwarding the L2TP encapsulated data.
データチャネルの障害：L2TPカプセル化データの転送を担当するコンポーネントの障害。
LAC L2TP Access Concentrator LNS L2TP Network Server LCCE L2TP Control Connection Endpoint AVP Attribute Value Pair SCCRQ Start-Control-Connection-Request SCCRP Start-Control-Connection-Reply ZLB Zero Length Body Message
LAC L2TPアクセス濃縮器LNS L2TPネットワークサーバーLCCE L2TPコントロール接続エンドポイントAVP属性値SCCRQ START-CONTOL-CONNECTION-REQUEST SCCRP START-CONTROL-CONNECTION-REPLY ZLB ZERO LESTE
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following diagram depicts the redundancy architecture and pertaining entities used to describe the failover protocol:
+--------------+
| L2TP active |
+----------+ ----| endpoint (A) |
| L2TP | / +--------------+
| endpoint |----------------------/
| (R) | \ +--------------+
+----------+ \ | L2TP backup |
----| endpoint (B) |
+--------------+
Active and backup endpoints may reside on the same device, however, they are not required to be that way. On other hand, some devices may not have a standby module altogether, in which case the failed endpoint, after reset, can become the recovery endpoint to recover from its prior failure.
アクティブおよびバックアップエンドポイントは同じデバイスに存在する場合がありますが、そのようにする必要はありません。一方、一部のデバイスには完全にスタンバイモジュールがない場合があります。その場合、リセット後、失敗したエンドポイントは、以前の障害から回復するための回復エンドポイントになる可能性があります。
Therefore, in the above diagram, upon A's (active endpoint's) failure:
したがって、上記の図では、A（アクティブエンドポイント）の障害について：
- Endpoint A would be called the failed endpoint.
- エンドポイントAは、失敗したエンドポイントと呼ばれます。
- If B is present, then it would become the recovery endpoint and also an active endpoint.
-
- If B is not present, then A could become the recovery endpoint after it restarts, provided it saved the information about active tunnels/sessions in some persistent storage.
- Bが存在しない場合、Aは再起動後に回復エンドポイントになる可能性があります。
- R does not initiate the failover protocol; rather it waits for a failure indication from recovery endpoint.
- Rはフェイルオーバープロトコルを開始しません。むしろ、回復エンドポイントからの障害表示が待っています。
This document assumes that the actual detection of a failure in the backup endpoint is done in an implementation-specific way. It also assumes that failure detection by the backup endpoint is faster than the L2TP control channel timeout between the active and remote endpoints. Typically, active and backup endpoints reside on the same physical device, allowing fast and reliable failure detection without the need to communicate between these endpoints over the network.
このドキュメントは、バックアップエンドポイントでの障害の実際の検出が実装固有の方法で行われることを前提としています。また、バックアップエンドポイントによる障害検出は、アクティブエンドポイントとリモートエンドポイント間のL2TP制御チャネルタイムアウトよりも高速であると想定しています。通常、アクティブなエンドポイントとバックアップエンドポイントは同じ物理デバイスに存在し、ネットワーク上のこれらのエンドポイント間で通信する必要なく、高速で信頼性の高い障害検出を可能にします。
Similarly, an active endpoint that acts also as a backup endpoint can easily start the recovery once it has rebooted. However, when the active and backup endpoints reside in separate devices, there is a need for communication between them in order to detect failures. As a solution for such situations, additional failure detection protocols, e.g., [BFD-MULTIHOP], may be needed.
同様に、バックアップエンドポイントとしても機能するアクティブなエンドポイントは、再起動すると簡単に回復を開始できます。ただし、アクティブエンドポイントとバックアップエンドポイントが別々のデバイスに存在する場合、障害を検出するためにそれらの間の通信が必要です。このような状況の解決策として、追加の障害検出プロトコル、たとえば[BFD-Multihop]が必要になる場合があります。
A device could have three kinds of failures:
デバイスには3種類の障害があります。
i) Control Channel Failure
i) 制御チャネル障害
ii) Data Channel Failure
ii）データチャネルの障害
iii) Control and Data Channel Failure
iii）制御およびデータチャネルの障害
The protocol described in this document specifies the recovery in conditions i) and iii). It is perceived that not much (stateful information) could be recovered via a control protocol exchange in case of ii).
このドキュメントで説明されているプロトコルは、条件i）およびiiiの回復を指定しています。IIの場合、コントロールプロトコル交換を介してそれほど（ステートフル情報）が回復することはできないと認識されています。
The failover protocol consists of three phases:
フェイルオーバープロトコルは、3つのフェーズで構成されています。
1) Failover Capability Negotiation: An active endpoint and a remote endpoint exchange failover capabilities and attributes to be used during the recovery process.
1) フェールオーバー機能の交渉：アクティブエンドポイントとリモートエンドポイント交換フェールオーバー機能と属性を回復プロセス中に使用する属性。
2) Failover Recovery: A recovery endpoint establishes a new L2TP control connection (called recovery tunnel) for every old tunnel that it wishes to recover. The recovery tunnel serves three purposes:
2) フェールオーバー回復：回復エンドポイントは、回復したいすべての古いトンネルの新しいL2TP制御接続（リカバリトンネルと呼ばれる）を確立します。回復トンネルは3つの目的を果たします。
- It identifies the old tunnel that is being recovered.
- 回収されている古いトンネルを識別します。
- It provides a means of authentication and a three-way handshake to ensure both ends agree on the failover for the specified old tunnel.
- 認証の手段と、指定された古いトンネルのフェールオーバーに両端が一致するようにするための3方向の握手を提供します。
- It could exchange the Ns and Nr values to be used in the recovered tunnel.
- 回収されたトンネルで使用するNSとNRの値を交換できます。
Upon establishing the recovery tunnel, two endpoints reset the control and data channel(s) on the recovered tunnel using the procedures described in Section 3.2.2 and Section 3.2.3, respectively. The recovery tunnel could be torn down after that, and sessions that were established resume traffic.
回復トンネルを確立すると、2つのエンドポイントは、それぞれセクション3.2.2およびセクション3.2.3で説明した手順を使用して、回収されたトンネルのコントロールとデータチャネルをリセットします。その後、回復トンネルを取り壊す可能性があり、確立されたセッションは交通を再開します。
3) Session State Synchronization: The session state synchronization process occurs on the recovered or the old tunnel and allows the two endpoints to agree on the state of the various sessions in the tunnel after failover. The inconsistency, which could arise due to the failure, is handled in the following manner: first, the two endpoints silently clear the sessions that were not in the established state. Then, they utilize Failover Session Query (FSQ) and Failover Session Response (FSR) on the recovered tunnel to obtain the state of sessions as known to the peer endpoint and clear the sessions accordingly.
3) セッション状態の同期：セッション状態の同期プロセスは、回復または古いトンネルで発生し、2つのエンドポイントがフェールオーバー後のトンネル内のさまざまなセッションの状態に同意できるようにします。失敗のために発生する可能性のある矛盾は、次の方法で処理されます。まず、2つのエンドポイントは、確立されていない状態ではないセッションを静かにクリアします。次に、回復したトンネルでフェイルオーバーセッションクエリ（FSQ）とフェイルオーバーセッション応答（FSR）を利用して、ピアエンドポイントに既知のセッションの状態を取得し、それに応じてセッションをクリアします。
The protocol consists of three steps describing specifications during the life of a control connection - before and after failover.
プロトコルは、フェールオーバーの前後に制御接続の存続期間中の仕様を説明する3つのステップで構成されています。
The active and remote endpoints exchange the Failover Capability attribute-value pair (AVP) in Start-Control-Connection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) during control connection establishment as a part of the normal (before failover) operation. The Failover Capability AVP, defined in Section 5.1, allows an endpoint to specify if it is control and/or data channel failover capable and the time allowed for the recovery for the tunnel.
アクティブおよびリモートエンドポイントは、コントロール接続の確立中に、通常の一部として（以前はコントロールコントロール接続-Request（SCCRQ）およびStart-Control-Connection-Reply（SCCRQ）のフェイルオーバー機能属性値ペア（AVP）を交換しますフェールオーバー）操作。セクション5.1で定義されているフェールオーバー機能AVPは、エンドポイントが制御および/またはデータチャネルフェールオーバーが対応できるかどうか、トンネルの回復に許可される時間を指定できるようにします。
The Failover Recovery Procedure described in this section is performed only if there was a control channel failure. The selection of the tunnels to be recovered is implementation specific.
このセクションで説明するフェールオーバー回復手順は、制御チャネル障害がある場合にのみ実行されます。回収されるトンネルの選択は実装固有です。
The Failover Recovery Procedure consists of following three steps, which are described in detail in the subsections below:
フェールオーバー回復手順は、次の3つのステップで構成されており、以下のサブセクションで詳しく説明しています。
- Recovery tunnel establishment
- 回復トンネルの確立
- Control channel reset
- コントロールチャネルリセット
- Data channel reset
- データチャネルリセット
The recovery endpoint establishes a new control connection, called recovery tunnel, for every old tunnel it wishes to recover. The purpose of the recovery tunnel is solely to recover the corresponding old tunnel. There is a one to one relationship between recovery tunnel and recovered/old tunnel
Recovery Endpointは、回復を希望するすべての古いトンネルに対して、回復トンネルと呼ばれる新しい制御接続を確立します。回復トンネルの目的は、単に対応する古いトンネルを回復することだけです。回復トンネルと回復/古いトンネルの間には1対1の関係があります
Recovery tunnel establishment considerations:
回復トンネルの確立に関する考慮事項：
- An LCCE MUST follow the procedures described in [L2TPv2] or [L2TPv3] to establish the recovery tunnel.
- LCCEは、[L2TPV2]または[L2TPV3]に記載されている手順に従って、回復トンネルを確立する必要があります。
- The recovery tunnel MUST use the same L2TP version (and establishment procedures) that was used for the old tunnel.
- 回復トンネルは、古いトンネルに使用されたのと同じL2TPバージョン（および設立手順）を使用する必要があります。
- The SCCRQ for Recovery tunnel MUST include the Tunnel Recovery AVP, defined in Section 5.2, to identify the old tunnel that is being recovered.
-
- The recovery tunnel MUST NOT include the Failover Capability AVP in its SCCRQ or SCCRP messages.
- 回復トンネルには、SCCRQまたはSCCRPメッセージにフェールオーバー機能AVPを含めてはなりません。
- An endpoint SHOULD NOT send any message other than the following on the recovery tunnel: SCCRQ, SCCRP, SCCCN, StopCCN, HELLO, ZLB, and ACK ([L2TPv3] only).
- エンドポイントは、回復トンネルの以下以外のメッセージを送信してはなりません：SCCRQ、SCCRP、SCCCN、STOPCCN、Hello、ZLB、およびACK（[L2TPV3]のみ）。
- An endpoint MUST NOT use any old Tunnel ID for the recovery tunnel. The old tunnels MUST be valid until the recovery process concludes.
- エンドポイントは、回復トンネルに古いトンネルIDを使用してはなりません。古いトンネルは、回復プロセスが終了するまで有効でなければなりません。
- An endpoint MUST use the Tie Breaker AVP (Section 4.4.3 [L2TPv2]) or Control Connection Tie Breaker AVP (Section 5.4.3 [L2TPv3]) in the setup of the recovery tunnel to ensure that only a single recovery tunnel (when both endpoints have simultaneous failover) is established to recover an old tunnel. The tunnel that wins the tie is used to decide the suggested Ns and Nr values on the recovered tunnel. Therefore, the endpoint that loses the tie, should reset the Ns and Nr values (Section 3.2.2) as if it were a remote endpoint. Appendix B illustrates the double failover scenario.
- エンドポイントは、リカバリトンネルのセットアップで、タイブレーカーAVP（セクション4.4.3 [L2TPV2]）またはコントロール接続タイブレーカーAVP（セクション5.4.3 [L2TPV3]）を使用する必要があります。エンドポイントには同時フェールオーバーがあります）は、古いトンネルを回収するために確立されています。ネクタイを獲得するトンネルは、回収されたトンネルで提案されたNSとNRの値を決定するために使用されます。したがって、ネクタイを失うエンドポイントは、まるでリモートエンドポイントであるかのようにNSとNRの値（セクション3.2.2）をリセットする必要があります。付録Bは、二重フェールオーバーシナリオを示しています。
- Tie Breaker AVP processing: The scope of a tie breaker AVP's action for recovery and non recovery tunnels must be independent, and is defined as follows: o When Tie Breaker AVP is used in a non recovery tunnel, the scope of the tie breaker AVP's action MUST only be within non recovery tunnels. Therefore, losing a tie against a non recovery tunnel MUST NOT result in termination of any recovery tunnel.
- タイブレーカーAVP処理：リカバリと非回復トンネルのためのタイブレーカーAVPのアクションの範囲は、次のように定義する必要があります。非回復トンネル内のみでなければなりません。したがって、非回復トンネルとのネクタイを失うと、回復トンネルが終了してはなりません。
o When a Tie Breaker AVP is used in a recovery tunnel, the scope of tie breaker AVP's action is further restricted to the recovery tunnel(s) for a single tunnel to be recovered. Thus, an implementation MUST apply the tie breaker received in a recovery tunnel only to those tunnels that are a) recovery tunnels, and b) associated with the same tunnel to be recovered. It MUST NOT impact the operation of non-recovery tunnels and recovery tunnels associated with other old tunnels to be recovered.
o タイブレーカーAVPが回復トンネルで使用されると、タイブレーカーAVPの作用の範囲は、回収される単一のトンネルの回収トンネルにさらに制限されます。したがって、実装は、回収トンネルにのみ回復トンネルで受け取ったネクタイブレーカーを、a）回復トンネルであるトンネルに適用する必要があり、b）同じトンネルに関連付けられて回収される必要があります。回収される他の古いトンネルに関連する非回復トンネルと回復トンネルの操作に影響を与えてはなりません。
Upon getting an SCCRQ with a Tunnel Recovery AVP, an endpoint validates the Recover Tunnel ID and the Recover Remote Tunnel ID and responds with an SCCRP. It MUST terminate the recovery tunnel if:
トンネル回復AVPを使用してSCCRQを取得すると、エンドポイントは回復トンネルIDと回復リモートトンネルIDを検証し、SCCRPで応答します。次の場合、回復トンネルを終了する必要があります。
- The Recover Tunnel ID or the Recover Remote Tunnel ID is unknown.
- 回復トンネルIDまたは回復リモートトンネルIDは不明です。
- The active or remote endpoint (prior to failover) had not indicated that it was failover capable.
- アクティブエンドポイントまたはリモートエンドポイント（フェイルオーバー前）は、フェイルオーバーが有能であることを示していませんでした。
- The L2TP version of recovery tunnel is different from the version used in the old tunnel.
- リカバリトンネルのL2TPバージョンは、古いトンネルで使用されるバージョンとは異なります。
If the remote endpoint accepts the SCCRQ, it SHOULD include the Suggested Control Sequence AVP, defined in Section 5.3, in the SCCRP message.
リモートエンドポイントがSCCRQを受け入れる場合、SCCRPメッセージにセクション5.3で定義されている提案された制御シーケンスAVPを含める必要があります。
Authentication considerations:
認証に関する考慮事項：
- To authenticate a peer endpoint during recovery tunnel establishment, an endpoint MUST follow the procedure described in either [L2TPv2] Section 5.1.1 or [L2TPv3] Section 4.3. It MUST use the same secret that was used to authenticate the old tunnel.
- 回復トンネルの確立中にピアエンドポイントを認証するには、エンドポイントは[L2TPV2]セクション5.1.1または[L2TPV3]セクション4.3のいずれかで説明されている手順に従う必要があります。古いトンネルを認証するために使用されたのと同じ秘密を使用する必要があります。
- Not being able to authenticate could be a reason to terminate the recovery tunnel.
- 認証できないことは、回復トンネルを終了する理由かもしれません。
- For L2TPv3 tunnels, a recovery tunnel MUST use the Control Message authentication (i.e., exchange the nonce values), as described in [L2TPv3] Section 4.3, if the old tunnel was configured to do control message authentication. An L2TPv3 recovered tunnel MUST reset its nonce values (both endpoints) to the nonce values exchanged in the recovery tunnel.
- L2TPV3トンネルの場合、リカバリトンネルは、[L2TPV3]セクション4.3で説明されているように、コントロールメッセージ認証を行うように構成されている場合、[L2TPV3]セクション4.3で説明されているように、コントロールメッセージ認証（つまり、非CE値を交換）を使用する必要があります。L2TPV3回収されたトンネルは、回復トンネルで交換されたNonCE値（両方のエンドポイント）をリセットする必要があります。
For any reason, if the recovery endpoint could not establish the recovery tunnel, then it MUST silently clear the old tunnel and sessions within, concluding that the recovery process has failed.
何らかの理由で、回復のエンドポイントが回復トンネルを確立できなかった場合、それは古いトンネルとセッションを静かにクリアし、回復プロセスが失敗したと結論付けなければなりません。
Any control packet received on the recovered tunnel before control channel reset (Section 3.2.2) MUST be silently discarded.
Control channel reset allows new control messages to be sent and received over the recovered tunnel.
コントロールチャネルリセットにより、新しいコントロールメッセージを回収したトンネル上で送信および受信できます。
Control channel reset procedure:
制御チャネルリセット手順：
- An endpoint SHOULD flush the transmit/receive windows and reset the control channel sequence numbers (i.e., Ns and Nr values) on the recovered tunnel. The control channel on the recovery endpoint is reset upon getting a valid SCCRP on the recovery tunnel, whereas the control channel on the remote endpoint is reset upon getting a valid SCCCN on the recovery tunnel. If the recovery endpoint did not receive the Suggested Control Sequence (SCS) AVP in the SCCRP then it MUST reset the Ns and Nr values to zero. If the remote endpoint opted to not send the SCS AVP then it MUST reset the Ns and Nr values to zero. Either endpoint can tear down the recovery tunnel after the control channel reset procedure is complete.
- エンドポイントは、送信/受信ウィンドウをフラッシュし、回収されたトンネルの制御チャネルシーケンス番号（つまり、NSおよびNR値）をリセットする必要があります。回復エンドポイントの制御チャネルは、回復トンネルで有効なSCCRPを取得するとリセットされますが、リモートエンドポイントの制御チャネルは、回復トンネルで有効なSCCCNを取得するとリセットされます。Recovery EndpointがSCCRPで提案された制御シーケンス（SCS）AVPを受信しなかった場合、NSとNRの値をゼロにリセットする必要があります。リモートエンドポイントがSCS AVPを送信しないことを選択した場合、NSとNRの値をゼロにリセットする必要があります。いずれかのエンドポイントは、制御チャネルリセット手順が完了した後、回復トンネルを取り壊すことができます。
- An endpoint MUST prevent the establishment of new sessions until it has cleared (or marked for clearance) the sessions that were not in an established state, i.e., until after Step I, Section 3.3 is complete.
- エンドポイントは、確立された状態ではないセッションをクリアする（またはクリアランスのためにマークされる）、つまりステップIの後までセクション3.3が完了するまで、新しいセッションの確立を防ぐ必要があります。
A data channel reset procedure is applicable only for the sessions using sequence numbers. For L2TPv3 data channel, the terms Nr and Ns in this document are used to mean "expected sequence number" and "sequence number", respectively.
データチャネルリセット手順は、シーケンス番号を使用したセッションにのみ適用できます。L2TPV3データチャネルの場合、このドキュメントのNRとNSという用語は、それぞれ「予想されるシーケンス番号」と「シーケンス番号」を意味するために使用されます。
Data channel reset procedure:
データチャネルリセット手順：
- The recovery endpoint sets the Ns value to zero.
- 回復エンドポイントは、NS値をゼロに設定します。
- The remote endpoint (recovery endpoint's peer) continues to use the Ns values it was using previously.
- リモートエンドポイント（Recovery Endpointのピア）は、以前に使用していたNS値を引き続き使用しています。
- To reset Nr values during failover, if an endpoint receives 'n' out of order but in sequence packets, then it MUST set the Nr value based on the Ns value of the incoming packets, as suggested in Appendix C of [L2TPv3]. The value of 'n' SHOULD be configurable.
- フェールオーバー中にNR値をリセットするには、エンドポイントが「n」を順不同で順番に受信したが、順番パケットで、[L2TPV3]の付録Cで示唆されているように、着信パケットのNS値に基づいてNR値を設定する必要があります。「n」の値は構成可能である必要があります。
- If one of the endpoints does not exhibit the capability (indicated in 'D' bit in the Failover Capability AVP) to reset the Nr value, then data channels using sequence numbers are considered non recoverable. Those sessions SHOULD be torn down by the recovery endpoint by sending a Call-Disconnect-Notify (CDN).
- エンドポイントのいずれかがNR値をリセットする機能（フェイルオーバー機能AVPの「d」ビットに示されている）を表示しない場合、シーケンス番号を使用してデータチャネルは回復不可であると見なされます。これらのセッションは、Call-Disconnect-Notify（CDN）を送信することにより、回復エンドポイントによって取り壊される必要があります。
- For data-channel-only failure, two endpoints MAY use the session state query/response mechanism on the control channel to synchronize the state of sessions as described in Section 3.3 below.
- データチャネルのみの障害の場合、2つのエンドポイントは、以下のセクション3.3で説明されているように、セッションの状態/応答メカニズムを制御チャネル上のセッション状態/応答メカニズムを使用して、セッションの状態を同期させることができます。
If a control channel failure happens when a session was being established or torn down, then it is possible for an endpoint to consider a session in an established state while its peer considers the same session non existent. Two such situations occur when failure on an endpoint occurs immediately after sending:
セッションが確立または取り壊されたときにコントロールチャネルの障害が発生した場合、エンドポイントは、同僚が同じセッションを存在しないと考えている間に、確立された状態でセッションを検討することができます。このような2つの状況は、送信後すぐにエンドポイントで障害が発生したときに発生します。
- A CDN message that never made it to the peer.
- ピアに到達しなかったCDNメッセージ。
- An ICCN message that never made it to the peer.
- ピアに到達しなかったICCNメッセージ。
The following mechanism MUST be used to identify and clear the sessions that exists on an endpoint, but not on its peer:
次のメカニズムを使用して、エンドポイントに存在するセッションを特定してクリアする必要がありますが、そのピアには存在しません。
Step I: For control channel failure, after the recovery tunnel is established, the sessions that were not in an established state MUST be silently cleared (i.e., without sending a CDN message) by each endpoint.
ステップI：制御チャネル障害の場合、回復トンネルが確立された後、確立された状態にないセッションは、各エンドポイントによって静かにクリアされなければなりません（つまり、CDNメッセージを送信せずに）。
Step II: Both endpoints MAY identify the sessions that might have been in inconsistent states, perhaps based on data channel inactivity. FSQ and FSR messages have been introduced to synchronize session state at any given point during the life of a session between two endpoints. These messages are used when one endpoint determines or suspects in an implementation specific manner that its session state could be inconsistent with that of its peer's.
ステップII：両方のエンドポイントは、おそらくデータチャネルの不活性に基づいて、一貫性のない状態にあった可能性のあるセッションを特定する場合があります。FSQおよびFSRメッセージは、2つのエンドポイント間のセッションの存続期間中の任意のポイントでセッション状態を同期するために導入されています。これらのメッセージは、1つのエンドポイントが、そのセッション状態がピアの状態と矛盾する可能性があることを実装固有の方法で決定または疑わせるときに使用されます。
Step III: An endpoint sends a Failover Session Query (FSQ) message to query the state of sessions as known to its peer. An FSQ message contains one Failover Session State (FSS) AVP, defined in Section 5.4, for each session it wishes to query. Multiple FSS AVPs could be included in one FSQ message. An FSQ message MUST include at least one FSS AVP. An endpoint MAY send another FSQ message before getting a response for its previous FSQs.
ステップIII：エンドポイントは、フェールオーバーセッションクエリ（FSQ）メッセージを送信して、ピアに知られているセッションの状態を照会します。FSQメッセージには、セクション5.4で定義されている1つのフェイルオーバーセッション状態（FSS）AVPが含まれています。複数のFSS AVPを1つのFSQメッセージに含めることができます。FSQメッセージには、少なくとも1つのFSS AVPを含める必要があります。エンドポイントは、以前のFSQの応答を取得する前に、別のFSQメッセージを送信する場合があります。
An inconsistency about a session's existence during failover could result in an endpoint selecting the same Session ID for a new session. In such a situation, it would send an ICRQ for an already established session. Therefore, before all sessions are synchronized using an FSQ/FSR mechanism, if endpoint receives an ICRQ for a session in an established state, then it MUST respond to such an ICRQ with a CDN. The CDN message must set Assigned/Local Session ID AVP ([L2TPv2] Section 4.4.4, [L2TPv3] Section 5.4.4) to its local Session ID and clear the session that it considered established. Use of a least recently used Session ID for the new sessions could help reduce this symptom during failover.
フェールオーバー中のセッションの存在に関する矛盾により、新しいセッションで同じセッションIDを選択するエンドポイントが発生する可能性があります。このような状況では、すでに確立されたセッションのためにICRQを送信します。したがって、すべてのセッションがFSQ/FSRメカニズムを使用して同期する前に、エンドポイントが確立された状態でのセッションのICRQを受信する場合、CDNでそのようなICRQに応答する必要があります。CDNメッセージは、割り当てられた/ローカルセッションID AVP（[L2TPV2]セクション4.4.4、[L2TPV3]セクション5.4.4）をローカルセッションIDに設定し、確立されたと考えられるセッションをクリアする必要があります。新しいセッションに最近使用されていないセッションIDの使用は、フェールオーバー中のこの症状を軽減するのに役立つ可能性があります。
When an endpoint receives an FSQ message, it MUST ensure that for each FSS AVP in the FSQ message, it includes an FSS AVP in the Failover Session Response (FSR) message. An endpoint could respond to multiple FSQs using one FSR message, or it could respond one FSQ with multiple FSRs. FSSs are not required to be responded in the same order in which they were received. For each FSS AVP received in FSQ messages, an endpoint MUST validate the Remote Session ID and determine if it is paired with the Session ID specified in the message. If an FSS AVP is not valid (i.e., session is non-existing or it is paired with different remote Session ID), then the Session ID field in the FSS AVP in the FSR MUST be set to zero. When session is discovered to be pairing with mismatching Session ID, the local session MUST not be cleared, but rather marked stale, to be queried later using an FSQ message. Appendix C presents an example dialogue between two endpoints with mismatching Session IDs.
エンドポイントがFSQメッセージを受信する場合、FSQメッセージの各FSS AVPに対して、フェイルオーバーセッション応答（FSR）メッセージにFSS AVPが含まれることを確認する必要があります。エンドポイントは、1つのFSRメッセージを使用して複数のFSQに応答するか、複数のFSRを使用して1つのFSQを応答できます。FSSは、受け取ったのと同じ順序で応答する必要はありません。FSQメッセージで受信した各FSS AVPについて、エンドポイントはリモートセッションIDを検証し、メッセージで指定されたセッションIDとペアになっているかどうかを判断する必要があります。FSS AVPが有効でない場合（つまり、セッションが存在しないか、異なるリモートセッションIDとペアになっています）、FSRのFSS AVPのセッションIDフィールドをゼロに設定する必要があります。セッションがセッションIDの不一致と組み合わせることが発見された場合、ローカルセッションをクリアする必要はなく、FSQメッセージを使用して後で照会するために、マークされた古くされている必要があります。付録Cは、セッションIDを不一致にする2つのエンドポイント間の対話の例を示しています。
When responding to an FSQ with an FSR message, the Remote Session ID in the FSS AVP of the FSR message is always set to the received value of the Session ID in the FSS AVP of the FSQ message.
FSRメッセージを使用してFSQに応答する場合、FSRメッセージのFSS AVPのリモートセッションIDは、FSQメッセージのFSS AVPのセッションIDの受信値に常に設定されます。
When an endpoint receives an FSR message, for each FSS AVP it MUST use the Remote Session ID field to identify the local session and silently (without sending a CDN) clear the session if the Session ID in the AVP was zero. Otherwise, it MUST consider the session to be in an established state and recovered.
エンドポイントがFSRメッセージを受信した場合、各FSS AVPに対して、リモートセッションIDフィールドを使用してローカルセッションを識別し、AVPのセッションIDがゼロの場合はセッションをクリアする必要があります。それ以外の場合は、セッションを確立された状態にして回復すると考える必要があります。
This document introduces two new messages that could be sent over an established/recovered control connection.
このドキュメントでは、確立/回復された制御接続を介して送信できる2つの新しいメッセージを紹介します。
The Failover Session Query (FSQ) control message is used by an endpoint during the recovery process to query the state of various sessions. It triggers a response from the peer, which contains the requested state of various sessions.
フェイルオーバーセッションクエリ（FSQ）コントロールメッセージは、回復プロセス中にエンドポイントによって使用され、さまざまなセッションの状態を照会します。さまざまなセッションの要求された状態を含むピアからの応答をトリガーします。
This control message is encoded as follows:
このコントロールメッセージは次のようにエンコードされます。
Vendor ID = 0 (IETF) Attribute Type = 21
ベンダーID = 0（IETF）属性タイプ= 21
The following AVPs MUST be present in the FSQ control message:
Message Type Failover Session State
メッセージタイプフェールオーバーセッションの状態
The following AVPs MAY be present in the FSQ control message:
次のAVPは、FSQコントロールメッセージに存在する場合があります。
Random Vector Message digest ([L2TPv3] tunnels only)
ランダムベクターメッセージダイジェスト（[L2TPV3]トンネルのみ）
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt.
他のAVPをこのコントロールメッセージに送信してはならず、受領時に無視する必要があります。
The M-bit on the Message Type AVP for this control message MUST be set to 0.
このコントロールメッセージのメッセージタイプAVPのMビットは0に設定する必要があります。
The Failover Session Response (FSR) control message is used by an endpoint during the recovery process to respond with the local state of various sessions. It is sent as a response to an FSQ message. An endpoint MAY choose to respond to an FSQ message with multiple FSR messages.
フェイルオーバーセッション応答（FSR）コントロールメッセージは、回復プロセス中にエンドポイントによって使用され、さまざまなセッションのローカル状態に応答します。FSQメッセージへの応答として送信されます。エンドポイントは、複数のFSRメッセージを使用してFSQメッセージに応答することを選択できます。
This control message is encoded as follows:
このコントロールメッセージは次のようにエンコードされます。
Vendor ID = 0 (IETF) Attribute Type = 22
ベンダーID = 0（IETF）属性タイプ= 22
The following AVPs MUST be present in the FSR control message:
次のAVPは、FSRコントロールメッセージに存在する必要があります。
Message Type Failover Session State
メッセージタイプフェールオーバーセッションの状態
The following AVPs MAY be present in the FSR control message:
Random Vector Message digest ([L2TPv3] tunnels only)
ランダムベクターメッセージダイジェスト（[L2TPV3]トンネルのみ）
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt.
他のAVPをこのコントロールメッセージに送信してはならず、受領時に無視する必要があります。
The M-bit on the Message Type AVP for this control message MUST be set to 0.
このコントロールメッセージのメッセージタイプAVPのMビットは0に設定する必要があります。
The following sections contain a list of new L2TP AVPs defined in this document.
次のセクションには、このドキュメントで定義されている新しいL2TP AVPのリストが含まれています。
The Failover Capability AVP, Attribute Type 76, indicates the capabilities of an endpoint required for the recovery process. The AVP format is defined as follows:
フェイルオーバー機能AVP属性タイプ76は、回復プロセスに必要なエンドポイントの機能を示します。AVP形式は次のように定義されています。
Failover Capability AVP
フェールオーバー機能AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 76 | Reserved |D|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit MUST be set to 0).
AVPが隠されている場合があります（Hビットは0または1に設定されています）。AVPは必須ではありません（Mビットは0に設定する必要があります）。
The C bit governs the failover capability for the control channel. When the C bit is set, it indicates that the endpoint can recover from a control channel failure using the procedure described in Section 3.2.2.
Cビットは、制御チャネルのフェールオーバー機能を管理します。Cビットが設定されると、セクション3.2.2で説明されている手順を使用して、エンドポイントが制御チャネル障害から回復できることを示します。
When the C bit is not set, it indicates that the endpoint cannot recover from a control channel failover. In this case, the D bit MUST be set. Note that a control channel failover in this case would be fatal for the tunnel and all associated data channels.
Cビットが設定されていない場合、エンドポイントがコントロールチャネルフェールオーバーから回復できないことを示します。この場合、dビットを設定する必要があります。この場合のコントロールチャネルフェールオーバーは、トンネルと関連するすべてのデータチャネルにとって致命的であることに注意してください。
The D bit governs the failover capability for data channels that use sequence numbers. Data channels that do not use sequence numbers do not need help to recover from a data channel failure.
Dビットは、シーケンス番号を使用するデータチャネルのフェールオーバー機能を管理します。シーケンス番号を使用しないデータチャネルでは、データチャネルの障害から回復するのに役立ちません。
When the D bit is set, it indicates that the endpoint is capable of resetting Nr value of data channels using the procedure described in Section 3.2.3 Data Channel reset procedure.
Dビットが設定されている場合、セクション3.2.3データチャネルリセット手順で説明されている手順を使用して、エンドポイントがデータチャネルのNR値をリセットできることを示します。
When the D bit is not set, it indicates that the endpoint cannot recover data channels that use sequence numbers. In the case of a failure, such data channels would be lost.
Dビットが設定されていない場合、エンドポイントがシーケンス番号を使用するデータチャネルを回復できないことを示します。障害の場合、そのようなデータチャネルは失われます。
The Failover Capability AVP MUST NOT be sent with C bit and D bit cleared.
The Recovery Time, applicable only when the C bit is set, is the time in milliseconds an endpoint asks its peer to wait before assuming the recovery process has failed. This timer starts when an endpoint's control channel timeout ([L2TPv2] Section 5.8, [L2TPv3] Section 4.2) is started, and is not stopped (before expiry) until an endpoint successfully authenticates its peer during recovery. A value of zero does not mean that failover will not occur, it means no additional time is requested from the peer. The timer is also stopped if a control channel message is acknowledged by the peer in the situation when there was no failover, but the loss of the control channel message was a temporary phenomenon.
Cビットが設定されている場合にのみ適用される回復時間は、ミリ秒単位での時間であり、エンドポイントが回復プロセスが失敗したと仮定する前にピアを待つように依頼します。このタイマーは、エンドポイントのコントロールチャネルタイムアウト（[L2TPV2]セクション5.8、[L2TPV3]セクション4.2）が開始されたときに起動し、エンドポイントが回復中にピアを正常に認証するまで（有効期限の前に）停止しません。ゼロの値は、フェイルオーバーが発生しないことを意味するものではなく、ピアから追加の時間が要求されないことを意味します。また、フェールオーバーがなかった状況でピアによってコントロールチャネルメッセージが認められている場合、タイマーは停止されますが、コントロールチャネルメッセージの損失は一時的な現象でした。
This AVP MUST NOT be included in any control message other than SCCRQ and SCCRP messages.
このAVPは、SCCRQおよびSCCRPメッセージ以外の制御メッセージに含めてはなりません。
The Tunnel Recovery AVP, Attribute Type 77, indicates that a sender would like to recover the tunnel identified in this AVP due to a failure. The AVP format is defined as follows: Tunnel Recovery AVP for L2TPv3 tunnels:
トンネル回復AVP属性タイプ77は、故障によりこのAVPで特定されたトンネルを回復したいことを示しています。AVP形式は、次のように定義されています。L2TPV3トンネルのトンネルリカバリAVP：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel Recovery AVP for L2TPv2 tunnels:
L2TPV2トンネルのトンネル回復AVP：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MUST not be hidden (the H-bit is set to 0). The AVP is mandatory (the M-bit is set to 1).
このAVPを非表示にしてはなりません（Hビットは0に設定されています）。AVPは必須です（Mビットは1に設定されています）。
The Recover Tunnel ID encodes the local Tunnel ID that an endpoint wants recovered. The Recover Remote Tunnel ID encodes the remote Tunnel ID corresponding to the old tunnel.
回復トンネルIDは、エンドポイントが回復したいローカルトンネルIDをエンコードします。回復リモートトンネルIDは、古いトンネルに対応するリモートトンネルIDをエンコードします。
This AVP MUST NOT be included in any control message other than the SCCRQ message when establishing a Recovery Tunnel.
このAVPは、回復トンネルを確立する際にSCCRQメッセージ以外の制御メッセージに含めてはなりません。
The Suggested Control Sequence (SCS) AVP, Attribute Type 78, specifies the Ns and Nr values to for the recovered tunnel. This AVP is included in an SCCRP message of a recovery tunnel by remote endpoint. The AVP format is defined as follows:
推奨される制御シーケンス（SCS）AVP、属性タイプ78は、回収されたトンネルに対してNSおよびNR値を指定します。このAVPは、リモートエンドポイントによる回復トンネルのSCCRPメッセージに含まれています。AVP形式は次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 78 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Ns | Suggested Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit is set to 0).
このAVPは隠されている可能性があります（Hビットは0または1に設定されています）。AVPは必須ではありません（Mビットは0に設定されています）。
This is an optional AVP, suggesting Ns and Nr values to be used by the recovery endpoint. If this AVP is present in an SCCRP message during recovery tunnel establishment, the recovery endpoint MUST set the Ns and Nr values of the recovered tunnel to the respective suggested values. When this AVP is not sent in an SCCRP or not present in an incoming SCCRP, the Ns and Nr values for the recovered tunnel are set to zero. Use of this AVP helps avoid the interference in the recovered tunnel's control channel with old control packets.
これはオプションのAVPであり、回復エンドポイントで使用されるNSとNRの値を示唆しています。このAVPが回復トンネルの確立中にSCCRPメッセージに存在する場合、回復したトンネルのNS値をそれぞれの提案された値に設定する必要があります。このAVPがSCCRPで送信されないか、着信SCCRPに存在しない場合、回収されたトンネルのNS値とNR値はゼロに設定されます。このAVPの使用は、古い制御パケットを使用した回収されたトンネルの制御チャネルの干渉を回避するのに役立ちます。
This AVP MUST NOT be included in any control message other than the SCCRP message when establishing a Recovery Tunnel.
このAVPは、回復トンネルを確立する際にSCCRPメッセージ以外の制御メッセージに含めてはなりません。
The Failover Session State (FSS) AVP, Attribute Type 79, is used to query the state of a session from the peer end to clear the sessions that otherwise would remain in an undefined state after failover. The AVP format is defined as follows:
フェイルオーバーセッション状態（FSS）AVP、属性タイプ79は、ピアエンドからセッションの状態を照会して、フェイルオーバー後に未定義の状態にとどまるセッションをクリアするために使用されます。AVP形式は次のように定義されています。
FSS AVP format for L2TPv3 sessions:
L2TPV3セッションのFSS AVP形式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FSS AVP format for L2TPv2 sessions:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is mandatory (the M-bit is set to 1).
このAVPは隠されている可能性があります（Hビットは0または1に設定されています）。AVPは必須です（Mビットは1に設定されています）。
The Session ID identifies the local Session ID that the sender had assigned, for which it would like to query the state on its peer. A Remote Session Id is the remote Session ID for the same session.
セッションIDは、送信者が割り当てたローカルセッションIDを識別します。リモートセッションIDは、同じセッションのリモートセッションIDです。
An FSS AVP MUST NOT be used in any message other than FSQ and FSR messages.
FSS AVPは、FSQおよびFSRメッセージ以外のメッセージで使用してはなりません。
An L2TP endpoint MAY expose the following configuration parameters to be specified for control connections:
L2TPエンドポイントは、制御接続用に指定する次の構成パラメーターを公開する場合があります。
- Control Channel Failover Capability: Failover Capability AVP (Section 5.1), C bit.
- 制御チャネルフェールオーバー機能：フェイルオーバー機能AVP（セクション5.1）、Cビット。
- Data Channel Failover Capability: Failover Capability AVP (Section 5.1), D bit.
- データチャネルフェールオーバー機能：フェイルオーバー機能AVP（セクション5.1）、Dビット。
- Recovery Time: Failover Capability AVP (Section 5.1).
- 回復時間：フェイルオーバー機能AVP（セクション5.1）。
The L2TP MIB defined in [L2TPv2-MIB] and [L2TPv3-MIB], defines a number of objects that may be used for monitoring the status L2TP nodes, but is seldom used for configuration purposes. It is expected that the above mentioned parameters will be configured by using a Command Line Interface (CLI) or other proprietary mechanism.
[L2TPV2-MIB]および[L2TPV3-MIB]で定義されているL2TP MIBは、ステータスL2TPノードの監視に使用できるが、構成目的で使用されることはめったにない多くのオブジェクトを定義します。上記のパラメーターは、コマンドラインインターフェイス（CLI）またはその他の独自のメカニズムを使用して構成されることが予想されます。
Asynchronous notifications for failover and recovery events may be sent by L2TP nodes to network management applications, but the specification of the protocol and format to be used for these notifications is out of the scope of this document.
フェイルオーバーおよび回復イベントの非同期通知は、L2TPノードによってネットワーク管理アプリケーションに送信される場合がありますが、これらの通知に使用されるプロトコルと形式の仕様は、このドキュメントの範囲外です。
This document defines the following values assigned by IANA.
このドキュメントは、IANAによって割り当てられた次の値を定義します。
- Four Control Message Attribute Value Pairs (Section 10.1 [L2TPv3]):
- 4つのコントロールメッセージ属性値ペア（セクション10.1 [L2TPV3]）：
Failover Capability : 76 Tunnel Recovery : 77 Suggested Control Sequence : 78 Failover Session State : 79
フェイルオーバー機能：76トンネル回復：77推奨制御シーケンス：78フェールオーバーセッション状態：79
- Two Message Type (Attribute Type 0) Values (Section 10.2 [L2TPv3]):
- 2つのメッセージタイプ（属性タイプ0）値（セクション10.2 [L2TPV3]）：
Failover Session Query : 21 Failover Session Response : 22
フェイルオーバーセッションクエリ：21フェイルオーバーセッション応答：22
A spoofed failover request (SCCRQ with Tunnel Recovery AVP) on behalf of an endpoint might cause a control channel termination if authentication measures mentioned in Section 3.2.1 are not used.
Even if the authentication measures (as described in Section 3.2.1) were used, it is still possible to learn an identity of an operational tunnel from an endpoint by issuing it spoofed failover requests that fail the authentication procedure. The probability of succeeding with a spoofed failover request is 1 in (2^16 - 1) for [L2TPv2] and 1 in (2^32 - 1) for [L2TPv3]. The discovered identity of an operational tunnel could then be misused to send control messages for a possible hindrance to the control connection. Typically, control messages that are outside the endpoint's receive window are discarded. However, if Suggested Control Sequence AVP (Section 5.3) is not used during the actual failover process, the sequence numbers might be reset to zero, thereby making the receive window predictable. To improve security under such circumstances, an endpoint may be configured with the possible set of recovery endpoints that could recover a tunnel, and use of Suggested Control Sequence AVP when recovering a tunnel.
（セクション3.2.1で説明されている）認証測定が使用されたとしても、認証手順に失敗するスプーフィングされたフェールオーバー要求を発行することにより、エンドポイントから運用トンネルの身元を学習することが依然として可能です。スプーフィングされたフェールオーバー要求で成功する確率は、[L2TPV2]の場合は1インチ（2^16-1）、[L2TPV3]で1インチ（2^32-1）です。その後、運用上のトンネルの発見されたアイデンティティは、コントロール接続に障害の可能性があるために制御メッセージを送信するために誤用される可能性があります。通常、エンドポイントの受信ウィンドウの外側にあるコントロールメッセージは破棄されます。ただし、実際のフェールオーバープロセス中に提案された制御シーケンスAVP（セクション5.3）が使用されない場合、シーケンス番号はゼロにリセットされ、受信ウィンドウを予測可能にする可能性があります。このような状況下でセキュリティを改善するために、トンネルを回復する可能性のある回復エンドポイントの可能なセットと、トンネルを回復する際に推奨される制御シーケンスAVPの使用でエンドポイントを構成することができます。
Leo Huber provided suggestions to help define the failover concept. Mark Townsley, Carlos Pignataro, and Ignacio Goyret reviewed the document and provided valuable suggestions.
Leo Huberは、フェールオーバーの概念を定義するのに役立つ提案を提供しました。マークタウンズリー、カルロスピグナタロ、イグナシオゴイレットがこの文書をレビューし、貴重な提案を提供しました。
Paul Howard Juniper Networks
Vipin Jain Riverstone Networks
Sam Henderson Cisco Systems
Keyur Parikh Harris Corporations
[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月。
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TPV2] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "層2トンネリングプロトコル" L2TP ""、RFC 2661、1999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[L2TPV3] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[L2TPv2-MIB] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two Tunneling Protocol "L2TP" Management Information Base", RFC 3371, August 2002.
[L2TPV2-MIB]洞窟、E。、Calhoun、P。、およびR. Wheeler、「レイヤー2つのトンネルプロトコル「L2TP」管理情報ベース」、RFC 3371、2002年8月。
[L2TPv3-MIB] Nadeau, T. and K. Koushik, "Layer Two Tunneling Protocol (version 3) Management Information Base", Work in Progress, August 2006.
[L2TPV3-MIB] Nadeau、T。およびK. Koushik、「レイヤー2トンネリングプロトコル（バージョン3）管理情報ベース」、2006年8月、作業進行中。
[BFD-MULTIHOP] Katz, D. and D. Ward, "BFD for Multihop Paths", Work in Progress, March 2007.
[BFD-Multihop] Katz、D。およびD. Ward、「Multihop Paths for Multihop Paths」、2007年3月の作業。
Description below outlines the failover protocol operation for an example tunnel. The failover protocol does not preclude an endpoint from recovering multiple tunnels in parallel. It also allows an endpoint to send multiple FSQs, each including multiple FSS AVPs, to recover quickly.
以下の説明サンプルトンネルのフェールオーバープロトコル操作の概要を示します。フェールオーバープロトコルは、エンドポイントが並行して複数のトンネルを回収することを妨げません。また、エンドポイントが複数のFSQを含む複数のFSQを迅速に回復できるようにすることができます。
Failover Capability Negotiation (Section 3.1):
フェールオーバー能力交渉（セクション3.1）：
Endpoint Peer
(assigned tid = x, failover capable)
SCCRQ --------------------------------------> validate SCCRQ
(assigned tid = y, failover capable)
validate <-------------------------------------- send SCCRP
SCCRP, etc.
.... <after tunnel gets created, sessions are established> ....
< This Node fails >
<このノードは失敗します>
The Recovery endpoint establishes the recovery tunnel (Section 3.2.1). Initiate recovery tunnel establishment for the old tunnel 'x':
回復エンドポイントは、回復トンネルを確立します（セクション3.2.1）。古いトンネル「X」の回復トンネル設立を開始します：
Recovery Endpoint Peer
回復エンドポイントピア
(assigned tid = z, Recovery AVP)
SCCRQ -----------------------------------> Detects failover
(recover tid = x, recover remote tid = y) validate SCCRQ
(Suggested Control Sequence AVP, Suggested Ns/Nr = 3/100)
validate <----------------------------------- send SCCRP
SCCRP (recover tid = y, recover remote tid = x)
reset Ns = 3, Nr = 100
on the recovered tunnel
SCCCN -----------------------------------> validate and reset
Ns = 100, Nr = 3 on
the recovered tunnel
Terminate the recovery tunnel
回復トンネルを終了します
tid = 'z'
StopCCN --------------------------------------> Cleanup 'w'
Session states are synchronized both endpoints may send FSQs and cleanup stale sessions (Section 3.3)
セッション状態は同期されます。両方のエンドポイントはFSQとクリーンアップの古いセッションを送信する可能性があります（セクション3.3）
(FSS AVP for sessions s1, s2, s3..)
send FSQ -------------------------------------> compute the state
of sessions in FSQ
(FSS AVP for sessions s1, s2, s3...)
deletes <-------------------------------------- send FSR
stale sessions, if any
(FSS AVP for sessions s7, s8, s9...)
compute <-------------------------------------- send FSQ
the sate of
sessions in FSQ
(FSS AVP for sessions s7, s8, s9...)
send FSR --------------------------------------> delete stale
sessions, if any
This section shows an example dialogue to illustrate double failure recovery. The notable difference, as described in Section 3.2.1, in the procedure from single failover scenario is the use of a tie breaker by one of the recovery endpoints to use the recovery tunnel established by its peer (also a recovery endpoint) as a recovery tunnel.
このセクションでは、二重の障害回復を示す対話の例を示します。セクション3.2.1で説明されているように、単一のフェイルオーバーシナリオの手順で説明されている顕著な違いは、回復エンドポイントの1つによるタイブレーカーの使用であり、ピアによって確立された回復トンネル（回復エンドポイント）によって確立された回復トンネルを回復として使用することです。トンネル。
Recovery endpoint Recovery endpoint
回復エンドポイントリカバリエンドポイント
(assume old tid = A) (assume old tid = B)
（古いtid = aと仮定）（古いtid = bと仮定）
Recovery AVP = (A, B)
SCCRQ -----------------------+
(with tie (recovery tunnel 'C') |
breaker |
AVP) |
Recovery AVP = (B, A) |
+- valid <--------------------------- Send SCCRQ
| SCCRQ (recovery tunnel 'D') | (with tie breaker AVP)
| This endpoint |
| loses tie; |
| Discards tunnel 'C' +--> Valid SCCRQ
| This endpoint wins tie;
| Discards SCCRQ
|
| (may include SCS AVP)
+->Send SCCRP -------------------------> Validate SCCRP
Reset 'B';
Set Ns, Nr values --+
|
|
|
Validate SCCN <---------------------- Send SCCN -------+
Reset 'A';
Set Ns, Nr values
FSQs and FSRs for the old tunnel (A, B) are exchanged on the recovered tunnel by both endpoints.
古いトンネル（A、B）のFSQおよびFSRは、両方のエンドポイントによって回収されたトンネルで交換されます。
Session ID mismatch could not be a result of failure on one of the endpoints. However, failover session recovery procedure could exacerbate the situation, resulting into a permanent mismatch in Session IDs between two endpoints. The dialogue below outlines the behavior described in Section 3.3, Step III to handle such situations gracefully.
セッションIDの不一致は、エンドポイントの1つでの障害の結果ではありませんでした。ただし、フェールオーバーセッションの回復手順は状況を悪化させる可能性があり、その結果、2つのエンドポイント間のセッションIDの永続的な不一致が生じます。以下の対話は、セクション3.3、ステップIIIで説明されている動作の概要を示しており、そのような状況を優雅に処理します。
Recovery endpoint Remote endpoint
回復エンドポイントリモートエンドポイント
(assume a mismatch) (assume a mismatch)
Sid = A, Remote Sid = B Sid = B, Remote Sid = C
Sid = C, Remote Sid = D
FSS AVP (A, B)
send FSQ -------------------------> No (B, A) pair exist;
rather (B, C) exist.
If it clears B then peer doesn't
know if C is stale on other end.
Instead if it marks B stale and queries the session state via FSQ, C would be cleared on the other end.
代わりに、それがBの古いものをマークし、FSQを介してセッション状態を照会する場合、Cは反対側でクリアされます。
FSS AVP (0, A)
Clears A <-------------------------- send FSR
... some time later ...
... 今度いつか ...
FSS AVP (B, C)
No (C,B) <-------------------------- send FSQ
Mark C Stale
FSS AVP (0, B)
Send FSR --------------------------> Clears B
Author Information
著者情報
Vipin Jain Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054 EMail: vipinietf@yahoo.com
Vipin Jain Riverstone Networks 5200 Great America Parkway Santa Clara、CA 95054メール：vipinietf@yahoo.com
Paul W. Howard Juniper Networks 10 Technology Park Drive Westford, MA 01886 EMail: phoward@juniper.net
ポール・W・ハワード・ジュニパーネットワーク10テクノロジーパークドライブマサチューセッツ州ウェストフォード01886メール：phoward@juniper.net
Sam Henderson Cisco Systems 7025 Kit Creek Rd. PO Box 14987 Research Triangle Park, NC 27709 EMail: samh@cisco.com
Sam Henderson Cisco Systems 7025 Kit Creek Rd。PO Box 14987リサーチトライアングルパーク、NC 27709メール：samh@cisco.com
Keyur Parikh Harris Corporation 4393 Digitalway Mason, OH 45040 EMail: kparikh@harris.com
Keyur Parikh Harris Corporation 4393 Digitalway Mason、OH 45040メール：kparikh@harris.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。