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）IETFトラスト（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.
このドキュメントの目標は、そのへの影響を最小限に抑えながら、フェイルオーバー後にL2TP層の回復時間を最小化すること[L2TPv3の] [L2TPv2] RFC 2661に拡張を導入することにより、L2TPエンドポイントの全体的な回復力を助けることであるとRFC 3931パフォーマンス。したがって、エンドポイントの全体的なアーキテクチャは、弾力性の努力にも支持していることが想定されます。
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つのオプションが利用可能である：最初のオプションは、バックアップのエンドポイントが完全に制御し、データセッションシーケンス番号に関して、アクティブなエンドポイントと同期していることを確実にするためです。他のオプションは、フェイルオーバー後にすべてのトンネルとそのセッションを再確立することです。最初のオプションの欠点は、特にトンネルとセッション凝集が増加すると、エンドポイントのアーキテクチャに大幅な性能と複雑さの影響を付加することです。第二の選択肢の欠点は、特に建築スケールとして、「サービスロス」の時間を増大させることです。
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スタートコントロール接続要求開始コントロール接続返信SCCRP ZLBゼロ長さボディのメッセージ属性
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
- Bが存在する場合、それは回復終点ともアクティブエンドポイントになるだろう。
- 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が存在しない場合、再起動後に、それはいくつかの永続ストレージ内のアクティブなトンネル/セッションに関する情報を保存して、回復のエンドポイントになる可能性があります。
- 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-マルチホップ]として、必要とされるかもしれません。
A device could have three kinds of failures:
デバイスは、障害の3種類を持つことができます：
i) Control Channel Failure
ⅰ）制御チャネルの失敗
ii) Data Channel Failure
ⅱ）データチャネル障害
iii) Control and Data Channel Failure
ⅲ）制御およびデータチャネル障害
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.
アクティブおよびリモートエンドポイントは、スタートコントロール接続要求（SCCRQ）にフェイルオーバー能力属性値ペア（AVP）を交換し、（前の通常の一部として、制御コネクション確立時（SCCRP）コントロール接続返信を開始しますフェイルオーバー）運転。セクション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
回復エンドポイントは、それが回復することを希望するすべての古いトンネルの回復トンネルと呼ばれる新しいコントロール接続を確立します。回復トンネルの目的は、単に対応する古いトンネルを回復することです。 /古いトンネルがあり、回復トンネルの間に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.
- 回復トンネルのSCCRQが回収されている古いトンネルを識別するために、セクション5.2で定義されたトンネル回復AVPを含まなければなりません。
- 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、ハロー、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の作用は独立でなければならないタイ・ブレーカーの範囲、および以下のように定義される：タイ・ブレーカーのAVPが非回復トンネルで使用する場合、O、タイ・ブレーカーの範囲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.
タイ・ブレーカーのAVPが回復トンネルで使用する場合、O、タイ・ブレーカー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の]セクション4.3に記載の古いトンネルは、制御メッセージ認証を実行するように構成された場合のL2TPv3トンネルの場合、回復トンネルは、（すなわち、ノンス値を交換する）制御メッセージ認証を使用しなければなりません。 L2TPv3のトンネルが回復トンネルで交換ノンス値にそのノンス値（両方のエンドポイント）をリセットする必要があり回収しました。
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.
制御チャネルリセット（セクション3.2.2）の前に回収されたトンネル上で受信された任意の制御パケットは、黙って破棄しなければなりません。
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の値）をリセットする必要があります。リモートエンドポイント上の制御チャネルが回復トンネルで有効SCCCNを取得する際にリセットされ、一方、回復エンドポイントの制御チャネルは、回復トンネルに有効SCCRPを取得する際にリセットされます。回復エンドポイントが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.
- それはクリア（またはクリアランスのためにマークされている）まで、ステップ後に、私は、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.
- リモートエンドポイント（回復エンドポイントのピア）は、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.
- エンドポイントは「N」順不同が、シーケンスパケットで受信した場合[たL2TPv3]の付録Cに示唆したように、フェイルオーバー時Nrの値をリセットするには、それは、着信パケットの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).
- エンドポイントの1つがNR値をリセットする（AVPフェイルオーバー能力の「D」ビットで示される）能力を示さない場合には、シーケンス番号を使用して、データ・チャネルは、非回復可能であると考えられます。これらのセッションは、コールを切断-通知（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:
セッションが確立または解体されたときに、制御チャネルに障害が発生した場合、そのピアが同じセッション非存在を考慮しながら、エンドポイントが確立した状態でセッションを検討するため、それが可能です。エンドポイント上の失敗が送信した直後に発生したときに二つのこのような状況が発生します。
- 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つのエンドポイント間のセッションの寿命の間に任意の時点でセッション状態を同期させるために導入されています。一方のエンドポイントは、そのセッション状態がそのピアののそれと矛盾することができることを、実装固有の方法で決定するか、または容疑者と、これらのメッセージが使用されています。
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メッセージは、少なくとも一つのFSS AVPを含まなければなりません。エンドポイントは、その前のFSQsの応答を取得する前に、別の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を送るでしょう。すべてのセッションは、エンドポイントが確立した状態のセッションのためにICRQを受信した場合、FSQ / FSRメカニズムを使用して同期される前に、したがって、それはCDNで、このようなICRQに反応しなければなりません。 CDNメッセージはそのローカルセッションIDに割り当てられたローカル/セッションID AVP（[L2TPv2]セクション4.4.4、[L2TPv3の]セクション5.4.4）を設定し、それが確立見なさというセッションをクリアする必要があります。新規セッションのための最低使用セッション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メッセージを使用して複数のFSQsに応えることができ、またはそれは、複数のFSRで1つのFSQに応答することができます。 FSSSは、それらが受信されたのと同じ順序で対応する必要はありません。各FSS AVPはFSQメッセージで受信するために、エンドポイントは、リモート・セッションの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ことがAVPでのセッションIDがゼロであった場合は、セッションをクリアする（CDNを送信せずに）サイレントローカルセッションを識別するために、リモートセッションIDフィールドを使用しなければなりません。それ以外の場合は、セッションが確立状態と回復であることを考慮しなければなりません。
This document introduces two new messages that could be sent over an established/recovered control connection.
この文書では、確立/復旧制御接続を介して送信される可能性があり二つの新しいメッセージを紹介します。
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:
以下のAVPはFSQ制御メッセージ内に存在していなければなりません。
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:
次のAVPは、FSR制御メッセージ内に存在することがあります。
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.
フェイルオーバー機能AVPは、Cビットを送ってはいけませんし、Dビットはクリア。
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:
トンネルの復旧AVPは、77属性タイプ、送信者が障害のため、このAVPで特定されたトンネルを回復したいことを示しています。次のようにAVPフォーマットが定義されています。
Tunnel Recovery AVP for L2TPv3 tunnels:
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.
これは、回復エンドポイントで使用されるようにNsとNrの値を示唆し、オプションのAVPです。このAVPが回復トンネル確立時SCCRPメッセージに存在する場合、回復エンドポイントはそれぞれの推奨値に回復トンネルのNsとNrの値を設定する必要があります。この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:
L2TPv2セッションの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
- Two Message Type (Attribute Type 0) Values (Section 10.2 [L2TPv3]):
- 2つのメッセージの種類（属性タイプ0）の値（10.2節[L2TPv3の]）：
Failover Session Query : 21
Failover Session Response : 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.
3.2.1項で述べた認証対策が使用されていない場合は、エンドポイントの代わりに偽装されたフェイルオーバー要求（トンネル回復AVPとSCCRQ）は、制御チャネル終端を引き起こす可能性があります。
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項で説明したように）使用された場合でも、認証手続きに失敗して偽装されたフェイルオーバー要求を発行することによって、エンドポイントからの操作トンネルのアイデンティティを学習することも可能です。 【のL2TPv3]のために - （1 2 ^ 32）の[L2TPv2]および1 - 偽装切替要求と後続の確率は、（1 2 ^ 16）で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.
レオ・フーバーは、フェールオーバーの概念の定義を支援するための提案を提供します。マークTownsley、カルロスPignataro、およびイグナシオGoyretは、文書を検討し、貴重な提案を提供しました。
Paul Howard Juniper Networks Vipin Jain Riverstone Networks Sam Henderson Cisco Systems Keyur Parikh Harris Corporations
ポール・ハワードジュニパーネットワークスVipinジャイナ教のRiverstone Networksのサム・ヘンダーソンシスコシステムズKeyurパリキハリス・コーポレーション
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、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]ラウ、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.、カルフーン、P.、およびR.ウィーラー、 "レイヤ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]ナドー、T.とK.コウシク、 "レイヤ2トンネリングプロトコル（バージョン3）管理情報ベース"、進歩、2006年8月に作業。
[BFD-MULTIHOP] Katz, D. and D. Ward, "BFD for Multihop Paths", Work in Progress, March 2007.
[BFD-マルチホップ]カッツ、D.とD.区、 "マルチホップパスのBFD"、進歩、2007年3月に作業。
Appendix A
付録A
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.
以下の説明は、例えば、トンネルのフェールオーバープロトコルの動作を概説します。フェイルオーバー・プロトコルは、並列に複数のトンネルを回収からエンドポイントを排除するものではありません。また、それぞれがすぐに回復するために、複数のFSS AVPを含め、エンドポイントが複数FSQsを送信することができます。
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)
セッション状態は、両方のエンドポイントがFSQsとクリーンアップ古いセッションを送信することが同期されている（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
Appendix B
付録B
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 = Bを想定）（古いTID = Aを想定）
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）のためのFSQsとのFSRは、両方のエンドポイントで回収トンネルで交換されます。
Appendix C
付録C
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で永久不一致になり、事態を悪化させることができます。以下対話は、正常にこのような状況に対処するために、ステップIIIを、セクション3.3に記載された動作の概要を示します。
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
シド= A、リモートシド= Bシド= B、リモートシド= Cシド= C、リモートシド= 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.
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ジャイナリバーストーン・ネットワーク5200グレートアメリカパークウェイサンタクララ、CA 95054 Eメール：vipinietf@yahoo.com
Paul W. Howard Juniper Networks 10 Technology Park Drive Westford, MA 01886 EMail: phoward@juniper.net
ポール・W・ハワードジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、MA 01886 Eメール：phoward@juniper.net
Sam Henderson Cisco Systems 7025 Kit Creek Rd. PO Box 14987 Research Triangle Park, NC 27709 EMail: samh@cisco.com
サム・ヘンダーソンシスコシステムズ7025キットクリークRdを。私書箱14987リサーチトライアングルパーク、NC 27709 Eメール：samh@cisco.com
Keyur Parikh Harris Corporation 4393 Digitalway Mason, OH 45040 EMail: kparikh@harris.com
ハリスコーポレーションkeyuraパリキ4393 dijitalabayaメイソン、オハイオ州45040 Eメール：কপারিখ@হ্যারিস.কম
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。