[要約] RFC 3931は、L2TPv3プロトコルに関する仕様を定義しています。 L2TPv3は、異なるネットワーク間でレイヤ2トンネリングを提供するためのプロトコルです。 このRFCの目的は、L2TPv3の機能と動作を明確にし、ネットワーク間の接続性を向上させることです。
Network Working Group J. Lau, Ed.
Request for Comments: 3931 M. Townsley, Ed.
Category: Standards Track Cisco Systems
I. Goyret, Ed.
Lucent Technologies
March 2005
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
レイヤー2トンネリングプロトコル-バージョン3（L2TPv3）
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 Internet Society (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated.
このドキュメントでは、レイヤ2トンネリングプロトコル（L2TPv3）の「バージョン3」について説明します。 L2TPv3は、2つのIPノード間の複数のレイヤ2接続をトンネリングするための基本制御プロトコルとカプセル化を定義します。追加のドキュメントには、エミュレートされる各データリンクタイプの詳細が記載されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4
1.2. Specification of Requirements. . . . . . . . . . . . . . 4
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10
3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
3.2.1. L2TP Control Message Header. . . . . . . . . . . 11
3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12
3.3. Control Connection Management. . . . . . . . . . . . . . 13
3.3.1. Control Connection Establishment . . . . . . . . 14
3.3.2. Control Connection Teardown. . . . . . . . . . . 14
3.4. Session Management . . . . . . . . . . . . . . . . . . . 15
3.4.1. Session Establishment for an Incoming Call . . . 15
3.4.2. Session Establishment for an Outgoing Call . . . 15
3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18
4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20
4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21
4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23
4.3. Control Message Authentication . . . . . . . . . . . . . 25
4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26
4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28
4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. General Control Message AVPs . . . . . . . . . . 36
5.4.2. Result and Error Codes . . . . . . . . . . . . . 40
5.4.3. Control Connection Management AVPs . . . . . . . 43
5.4.4. Session Management AVPs. . . . . . . . . . . . . 48
5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57
6. Control Connection Protocol Specification. . . . . . . . . . . 59
6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61
6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
7. Control Connection State Machines. . . . . . . . . . . . . . . 68
7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68
7.2. Control Connection States. . . . . . . . . . . . . . . . 69
7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72
7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73
7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75
7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76
7.5. Termination of a Control Connection. . . . . . . . . . . 77
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
8.1. Control Connection Endpoint and Message Security . . . . 78
8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
9. Internationalization Considerations. . . . . . . . . . . . . . 79
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 85
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94
The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism for tunneling Layer 2 (L2) "circuits" across a packet-oriented data network (e.g., over IP). L2TP, as originally defined in RFC 2661, is a standard method for tunneling Point-to-Point Protocol (PPP) [RFC1661] sessions. L2TP has since been adopted for tunneling a number of other L2 protocols. In order to provide greater modularity, this document describes the base L2TP protocol, independent of the L2 payload that is being tunneled.
レイヤー2トンネリングプロトコル（L2TP）は、パケット指向のデータネットワーク（IPなど）全体でレイヤー2（L2）の「回線」をトンネリングするための動的メカニズムを提供します。元々RFC 2661で定義されているL2TPは、ポイントツーポイントプロトコル（PPP）[RFC1661]セッションをトンネリングするための標準的な方法です。 L2TPは、他の多くのL2プロトコルのトンネリングに採用されています。より優れたモジュール性を提供するために、このドキュメントでは、トンネリングされるL2ペイロードに関係なく、基本L2TPプロトコルについて説明します。
The base L2TP protocol defined in this document consists of (1) the control protocol for dynamic creation, maintenance, and teardown of L2TP sessions, and (2) the L2TP data encapsulation to multiplex and demultiplex L2 data streams between two L2TP nodes across an IP network. Additional documents are expected to be published for each L2 data link emulation type (a.k.a. pseudowire-type) supported by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will contain any pseudowire-type specific details that are outside the scope of this base specification.
このドキュメントで定義されている基本L2TPプロトコルは、（1）L2TPセッションの動的な作成、保守、および破棄のための制御プロトコル、および（2）L2TPデータカプセル化により、IP上の2つのL2TPノード間でL2データストリームを多重化および逆多重化します。通信網。 L2TPがサポートする各L2データリンクエミュレーションタイプ（別名、疑似配線タイプ）（つまり、PPP、イーサネット、フレームリレーなど）について、追加のドキュメントが公開される予定です。これらのドキュメントには、この基本仕様の範囲外の疑似配線タイプ固有の詳細が含まれます。
When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as defined in RFC 2661 will be referred to as "L2TPv2", corresponding to the value in the Version field of an L2TP header. (Layer 2 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, L2TP as defined in this document will be referred to as "L2TPv3". Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in general.
L2TPv2とL2TPv3の間の指定が必要な場合、RFC 2661で定義されているL2TPは「L2TPv2」と呼ばれ、L2TPヘッダーのVersionフィールドの値に対応します。 （レイヤ2転送、L2F、[RFC2341]は「バージョン1」として定義されていました。）このドキュメントで定義されているL2TPは、「L2TPv3」と呼ばれることがあります。それ以外の場合、頭字語「L2TP」は一般にL2TPv3またはL2TPを指します。
Many of the protocol constructs described in this document are carried over from RFC 2661. Changes include clarifications based on years of interoperability and deployment experience as well as modifications to either improve protocol operation or provide a clearer separation from PPP. The intent of these modifications is to achieve a healthy balance between code reuse, interoperability experience, and a directed evolution of L2TP as it is applied to new tasks.
このドキュメントで説明されているプロトコルコンストラクトの多くは、RFC 2661から引き継がれています。変更には、長年の相互運用性と展開の経験に基づく説明のほか、プロトコルの動作を改善するか、PPPから明確に分離するための変更が含まれます。これらの変更の目的は、コードの再利用、相互運用性のエクスペリエンス、および新しいタスクに適用されるL2TPの有向進化の間の健全なバランスを達成することです。
Notable differences between L2TPv2 and L2TPv3 include the following:
L2TPv2とL2TPv3の顕著な違いは次のとおりです。
Separation of all PPP-related AVPs, references, etc., including a portion of the L2TP data header that was specific to the needs of PPP. The PPP-specific constructs are described in a companion document.
PPPのニーズに固有のL2TPデータヘッダーの一部を含む、すべてのPPP関連のAVP、参照などの分離。 PPP固有の構成については、関連ドキュメントに記載されています。
Transition from a 16-bit Session ID and Tunnel ID to a 32-bit Session ID and Control Connection ID, respectively.
16ビットのセッションIDおよびトンネルIDから、それぞれ32ビットのセッションIDおよびコントロール接続IDへの移行。
Extension of the Tunnel Authentication mechanism to cover the entire control message rather than just a portion of certain messages.
トンネル認証メカニズムの拡張により、特定のメッセージの一部ではなく、制御メッセージ全体をカバーします。
Details of these changes and a recommendation for transitioning to L2TPv3 are discussed in Section 4.7.
これらの変更の詳細とL2TPv3への移行に関する推奨事項については、セクション4.7で説明します。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Attribute Value Pair (AVP)
属性値ペア（AVP）
The variable-length concatenation of a unique Attribute (represented by an integer), a length field, and a Value containing the actual value identified by the attribute. Zero or more AVPs make up the body of control messages, which are used in the establishment, maintenance, and teardown of control connections. This basic construct is sometimes referred to as a Type-Length-Value (TLV) in some specifications. (See also: Control Connection, Control Message.)
一意の属性（整数で表される）、長さフィールド、および属性によって識別される実際の値を含む値の可変長連結。 0個以上のAVPが制御メッセージの本文を構成し、制御接続の確立、保守、および破棄に使用されます。この基本構成は、一部の仕様ではType-Length-Value（TLV）と呼ばれることがあります。 （参照：コントロール接続、コントロールメッセージ。）
Call (Circuit Up)
呼び出し（回路上）
The action of transitioning a circuit on an L2TP Access Concentrator (LAC) to an "up" or "active" state. A call may be dynamically established through signaling properties (e.g., an incoming or outgoing call through the Public Switched Telephone Network (PSTN)) or statically configured (e.g., provisioning a Virtual Circuit on an interface). A call is defined by its properties (e.g., type of call, called number, etc.) and its data traffic. (See also: Circuit, Session, Incoming Call, Outgoing Call, Outgoing Call Request.)
L2TPアクセスコンセントレータ（LAC）上の回線を「アップ」または「アクティブ」状態に移行するアクション。呼び出しは、シグナリングプロパティ（例：公衆交換電話網（PSTN）を介した着信呼び出しまたは発信呼び出し）を通じて動的に確立されるか、静的に構成されます（たとえば、インターフェイスで仮想回線をプロビジョニングする）。コールは、そのプロパティ（コールのタイプ、着信番号など）とそのデータトラフィックによって定義されます。 （参照：回線、セッション、着信、発信、発信要求。）
Circuit
回路
A general term identifying any one of a wide range of L2 connections. A circuit may be virtual in nature (e.g., an ATM PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct correlation to a physical layer (e.g., an RS-232 serial line). Circuits may be statically configured with a relatively long-lived uptime, or dynamically established with signaling to govern the establishment, maintenance, and teardown of the circuit. For the purposes of this document, a statically configured circuit is considered to be essentially the same as a very simple, long-lived, dynamic circuit. (See also: Call, Remote System.)
広範囲のL2接続のいずれかを識別する一般的な用語。回線は、事実上仮想的なもの（ATM PVC、IEEE 802 VLAN、L2TPセッションなど）である場合と、物理層（RS-232シリアルラインなど）と直接相関している場合があります。回線は、比較的長い稼働時間で静的に構成するか、シグナリングで動的に確立して、回線の確立、保守、および破棄を制御できます。このドキュメントでは、静的に構成された回路は、非常に単純で長寿命の動的回路と基本的に同じであると見なされます。 （参照：コール、リモートシステム。）
Client
クライアント
(See Remote System.)
（リモートシステムを参照してください。）
Control Connection
制御接続
An L2TP control connection is a reliable control channel that is used to establish, maintain, and release individual L2TP sessions as well as the control connection itself. (See also: Control Message, Data Channel.)
L2TP制御接続は、個々のL2TPセッションおよび制御接続自体を確立、維持、および解放するために使用される信頼できる制御チャネルです。 （参照：コントロールメッセージ、データチャネル。）
Control Message
制御メッセージ
An L2TP message used by the control connection. (See also: Control Connection.)
制御接続で使用されるL2TPメッセージ。 （参照：コントロール接続。）
Data Message
データメッセージ
Message used by the data channel. (a.k.a. Data Packet, See also: Data Channel.)
データチャネルで使用されるメッセージ。 （別名、データパケット、「データチャネル」も参照してください。）
Data Channel
データチャンネル
The channel for L2TP-encapsulated data traffic that passes between two LCCEs over a Packet-Switched Network (i.e., IP). (See also: Control Connection, Data Message.)
パケット交換ネットワーク（IP）を介して2つのLCCE間を通過するL2TPカプセル化データトラフィックのチャネル。 （参照：コントロール接続、データメッセージ。）
Incoming Call
電話の着信
The action of receiving a call (circuit up event) on an LAC. The call may have been placed by a remote system (e.g., a phone call over a PSTN), or it may have been triggered by a local event (e.g., interesting traffic routed to a virtual interface). An incoming call that needs to be tunneled (as determined by the LAC) results in the generation of an L2TP ICRQ message. (See also: Call, Outgoing Call, Outgoing Call Request.)
LACでコールを受信するアクション（サーキットアップイベント）。呼び出しは、リモートシステム（PSTNを介した電話など）によって行われたか、ローカルイベント（たとえば、仮想インターフェイスにルーティングされた対象トラフィック）によってトリガーされた可能性があります。トンネリングが必要な着信コール（LACによって決定される）により、L2TP ICRQメッセージが生成されます。 （参照：通話、発信通話、発信通話リクエスト。）
L2TP Access Concentrator (LAC)
L2TPアクセスコンセントレータ（LAC）
If an L2TP Control Connection Endpoint (LCCE) is being used to cross-connect an L2TP session directly to a data link, we refer to it as an L2TP Access Concentrator (LAC). An LCCE may act as both an L2TP Network Server (LNS) for some sessions and an LAC for others, so these terms must only be used within the context of a given set of sessions unless the LCCE is in fact single purpose for a given topology. (See also: LCCE, LNS.)
L2TPコントロール接続エンドポイント（LCCE）を使用してL2TPセッションをデータリンクに直接相互接続する場合、それをL2TPアクセスコンセントレータ（LAC）と呼びます。 LCCEは、一部のセッションのL2TPネットワークサーバー（LNS）と他のセッションのLACの両方として機能する可能性があるため、LCCEが特定のトポロジの単一の目的でない限り、これらの用語は特定のセッションのコンテキスト内でのみ使用する必要があります。 。 （LCCE、LNSも参照してください。）
L2TP Control Connection Endpoint (LCCE)
L2TPコントロール接続エンドポイント（LCCE）
An L2TP node that exists at either end of an L2TP control connection. May also be referred to as an LAC or LNS, depending on whether tunneled frames are processed at the data link (LAC) or network layer (LNS). (See also: LAC, LNS.)
L2TP制御接続の両端に存在するL2TPノード。トンネルフレームがデータリンク（LAC）で処理されるかネットワークレイヤー（LNS）で処理されるかに応じて、LACまたはLNSと呼ばれることもあります。 （参照：LAC、LNS。）
L2TP Network Server (LNS)
L2TPネットワークサーバー（LNS）
If a given L2TP session is terminated at the L2TP node and the encapsulated network layer (L3) packet processed on a virtual interface, we refer to this L2TP node as an L2TP Network Server (LNS). A given LCCE may act as both an LNS for some sessions and an LAC for others, so these terms must only be used within the context of a given set of sessions unless the LCCE is in fact single purpose for a given topology. (See also: LCCE, LAC.)
特定のL2TPセッションがL2TPノードで終了し、カプセル化されたネットワーク層（L3）パケットが仮想インターフェイスで処理される場合、このL2TPノードをL2TPネットワークサーバー（LNS）と呼びます。特定のLCCEは一部のセッションのLNSと他のセッションのLACの両方として機能する可能性があるため、LCCEが実際に特定のトポロジの単一の目的でない限り、これらの用語は特定のセッションのコンテキスト内でのみ使用する必要があります。 （LCCE、LACも参照してください。）
Outgoing Call
発信
The action of placing a call by an LAC, typically in response to policy directed by the peer in an Outgoing Call Request. (See also: Call, Incoming Call, Outgoing Call Request.)
LACによってコールを発信するアクション。通常、発信コールリクエストでピアによって指示されたポリシーに応答して。 （参照：通話、着信、発信要求）
Outgoing Call Request
発信リクエスト
A request sent to an LAC to place an outgoing call. The request contains specific information not known a priori by the LAC (e.g., a number to dial). (See also: Call, Incoming Call, Outgoing Call.)
発信コールを行うためにLACに送信される要求。リクエストには、LACによってアプリオリに知られていない特定の情報（ダイヤルする番号など）が含まれています。 （参照：通話、着信、発信）
Packet-Switched Network (PSN)
パケット交換ネットワーク（PSN）
A network that uses packet switching technology for data delivery. For L2TPv3, this layer is principally IP. Other examples include MPLS, Frame Relay, and ATM.
データ配信にパケット交換技術を使用するネットワーク。 L2TPv3の場合、この層は主にIPです。他の例としては、MPLS、フレームリレー、ATMなどがあります。
Peer
仲間
When used in context with L2TP, Peer refers to the far end of an L2TP control connection (i.e., the remote LCCE). An LAC's peer may be either an LNS or another LAC. Similarly, an LNS's peer may be either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
ピアは、L2TPとの関連で使用される場合、L2TP制御接続（つまり、リモートLCCE）の遠端を指します。 LACのピアは、LNSまたは別のLACのいずれかです。同様に、LNSのピアは、LACまたは別のLNSのいずれかです。 （LAC、LCCE、LNSも参照してください。）
Pseudowire (PW)
シュードビル（PO）
An emulated circuit as it traverses a PSN. There is one Pseudowire per L2TP Session. (See also: Packet-Switched Network, Session.)
PSNを通過するエミュレート回路。 L2TPセッションごとに1つの疑似配線があります。 （参照：パケット交換ネットワーク、セッション。）
Pseudowire Type
疑似配線タイプ
The payload type being carried within an L2TP session. Examples include PPP, Ethernet, and Frame Relay. (See also: Session.)
L2TPセッション内で伝送されるペイロードタイプ。例には、PPP、イーサネット、およびフレームリレーが含まれます。 （参照：セッション。）
Remote System
リモートシステム
An end system or router connected by a circuit to an LAC.
回線によってLACに接続されたエンドシステムまたはルーター。
Session
セッション
An L2TP session is the entity that is created between two LCCEs in order to exchange parameters for and maintain an emulated L2 connection. Multiple sessions may be associated with a single Control Connection.
L2TPセッションは、エミュレートされたL2接続のパラメータを交換して維持するために2つのLCCE間で作成されるエンティティです。複数のセッションを単一のコントロール接続に関連付けることができます。
Zero-Length Body (ZLB) Message
ゼロレングスボディ（ZLB）メッセージ
A control message with only an L2TP header. ZLB messages are used only to acknowledge messages on the L2TP reliable control connection. (See also: Control Message.)
L2TPヘッダーのみを持つ制御メッセージ。 ZLBメッセージは、L2TPの信頼性の高い制御接続上のメッセージを確認するためにのみ使用されます。 （参照：コントロールメッセージ）
L2TP operates between two L2TP Control Connection Endpoints (LCCEs), tunneling traffic across a packet network. There are three predominant tunneling models in which L2TP operates: LAC-LNS (or vice versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. (Dotted lines designate network connections. Solid lines designate circuit connections.)
L2TPは2つのL2TPコントロール接続エンドポイント（LCCE）間で動作し、パケットネットワーク全体でトラフィックをトンネリングします。 L2TPが動作する主なトンネルモデルには、LAC-LNS（またはその逆）、LAC-LAC、およびLNS-LNSの3つがあります。これらのモデルを以下に示します。 （点線はネットワーク接続を示します。実線は回路接続を示します。）
Figure 2.0: L2TP Reference Models
図2.0：L2TP参照モデル
(a) LAC-LNS Reference Model: On one side, the LAC receives traffic from an L2 circuit, which it forwards via L2TP across an IP or other packet-based network. On the other side, an LNS logically terminates the L2 circuit locally and routes network traffic to the home network. The action of session establishment is driven by the LAC (as an incoming call) or the LNS (as an outgoing call).
（a）LAC-LNSリファレンスモデル：一方の側では、LACはL2回線からトラフィックを受信し、L2TPを介してIPまたはその他のパケットベースのネットワークを介して転送します。一方、LNSはL2回線をローカルで論理的に終端し、ネットワークトラフィックをホームネットワークにルーティングします。セッション確立のアクションは、LAC（着信コールとして）またはLNS（発信コールとして）によって駆動されます。
+-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+
remote
system
|<-- emulated service -->|
|<----------- L2 service ------------>|
(b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. Each LAC forwards circuit traffic from the remote system to the peer LAC using L2TP, and vice versa. In its simplest form, an LAC acts as a simple cross-connect between a circuit to a remote system and an L2TP session. This model typically involves symmetric establishment; that is, either side of the connection may initiate a session at any time (or simultaneously, in which a tie breaking mechanism is utilized).
（b）LAC-LAC参照モデル：このモデルでは、両方のLCCEがLACです。各LACは、L2TPを使用してリモートシステムからピアLACに、またはその逆に回線トラフィックを転送します。 LACは、その最も単純な形式では、回線からリモートシステムへの単純な相互接続とL2TPセッションとして機能します。このモデルには通常、対称的な確立が含まれます。つまり、接続のいずれかの側がいつでも（または同時に、タイブレイキングメカニズムが使用されているときに）セッションを開始できます。
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A user-level, traffic-generated, or signaled event typically drives session establishment from one side of the tunnel. For example, a tunnel generated from a PC by a user, or automatically by customer premises equipment.
（c）LNS-LNS参照モデル：このモデルには、LCCEとして2つのLNSがあります。ユーザーレベルの、トラフィックによって生成された、または通知されたイベントは、通常、トンネルの片側からセッションの確立を促進します。たとえば、ユーザーによってPCから生成されたトンネル、または顧客宅内機器によって自動的に生成されたトンネル。
+-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
Note: In L2TPv2, user-driven tunneling of this type is often referred to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part of a software package on a host is sometimes referred to as an "LAC Client" [RFC2661].
注：L2TPv2では、このタイプのユーザー主導のトンネリングは「自発的トンネリング」と呼ばれることがよくあります[RFC2809]。さらに、ホスト上のソフトウェアパッケージの一部として機能するLNSは、「LACクライアント」[RFC2661]と呼ばれることもあります。
L2TP is comprised of two types of messages, control messages and data messages (sometimes referred to as "control packets" and "data packets", respectively). Control messages are used in the establishment, maintenance, and clearing of control connections and sessions. These messages utilize a reliable control channel within L2TP to guarantee delivery (see Section 4.2 for details). Data messages are used to encapsulate the L2 traffic being carried over the L2TP session. Unlike control messages, data messages are not retransmitted when packet loss occurs.
L2TPは、制御メッセージとデータメッセージの2種類のメッセージで構成されます（それぞれ「制御パケット」と「データパケット」と呼ばれることもあります）。制御メッセージは、制御接続とセッションの確立、保守、およびクリアで使用されます。これらのメッセージは、L2TP内の信頼できる制御チャネルを利用して配信を保証します（詳細については、セクション4.2を参照）。データメッセージは、L2TPセッションで伝送されるL2トラフィックをカプセル化するために使用されます。制御メッセージとは異なり、パケット損失が発生してもデータメッセージは再送信されません。
The L2TPv3 control message format defined in this document borrows largely from L2TPv2. These control messages are used in conjunction with the associated protocol state machines that govern the dynamic setup, maintenance, and teardown for L2TP sessions. The data message format for tunneling data packets may be utilized with or without the L2TP control channel, either via manual configuration or via other signaling methods to pre-configure or distribute L2TP session information. Utilization of the L2TP data message format with other signaling methods is outside the scope of this document.
このドキュメントで定義されているL2TPv3制御メッセージ形式は、主にL2TPv2を借用したものです。これらの制御メッセージは、L2TPセッションの動的セットアップ、メンテナンス、およびティアダウンを管理する関連プロトコルステートマシンと組み合わせて使用されます。データパケットをトンネリングするためのデータメッセージ形式は、L2TPセッション情報を事前に構成または配信するために、手動構成または他のシグナリング方法を介して、L2TP制御チャネルの有無にかかわらず利用できます。他のシグナリング方式でのL2TPデータメッセージフォーマットの利用は、このドキュメントの範囲外です。
Figure 3.0: L2TPv3 Structure
図3.0：L2TPv3構造
+-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+
Figure 3.0 depicts the relationship of control messages and data messages over the L2TP control and data channels, respectively. Data messages are passed over an unreliable data channel, encapsulated by an L2TP header, and sent over a Packet-Switched Network (PSN) such as IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over a reliable L2TP control channel, which operates over the same PSN.
図3.0は、L2TP制御チャネルとデータチャネル上の制御メッセージとデータメッセージの関係をそれぞれ示しています。データメッセージは、信頼性の低いデータチャネルを介して渡され、L2TPヘッダーによってカプセル化され、IP、UDP、フレームリレー、ATM、MPLSなどのパケット交換ネットワーク（PSN）を介して送信されます。制御メッセージは、信頼性の高いL2TPを介して送信されます。同じPSNで動作する制御チャネル。
The necessary setup for tunneling a session with L2TP consists of two steps: (1) Establishing the control connection, and (2) establishing a session as triggered by an incoming call or outgoing call. An L2TP session MUST be established before L2TP can begin to forward session frames. Multiple sessions may be bound to a single control connection, and multiple control connections may exist between the same two LCCEs.
L2TPでセッションをトンネリングするために必要な設定は、（1）制御接続の確立、（2）着信呼び出しまたは発信呼び出しによってトリガーされるセッションの確立という2つのステップで構成されます。 L2TPがセッションフレームの転送を開始する前に、L2TPセッションを確立する必要があります。複数のセッションが単一の制御接続にバインドされる場合があり、同じ2つのLCCE間に複数の制御接続が存在する場合があります。
The Message Type AVP (see Section 5.4.1) defines the specific type of control message being sent.
メッセージタイプAVP（セクション5.4.1を参照）は、送信される制御メッセージの特定のタイプを定義します。
This document defines the following control message types (see Sections 6.1 through 6.15 for details on the construction and use of each message):
このドキュメントでは、次の制御メッセージタイプを定義しています（各メッセージの作成と使用の詳細については、セクション6.1から6.15を参照してください）。
Control Connection Management
接続管理の制御
0 (reserved) 1 (SCCRQ) Start-Control-Connection-Request 2 (SCCRP) Start-Control-Connection-Reply 3 (SCCCN) Start-Control-Connection-Connected 4 (StopCCN) Stop-Control-Connection-Notification 5 (reserved) 6 (HELLO) Hello 20 (ACK) Explicit Acknowledgement
0（予約済み）1（SCCRQ）Start-Control-Connection-Request 2（SCCRP）Start-Control-Connection-Reply 3（SCCCN）Start-Control-Connection-Connected 4（StopCCN）Stop-Control-Connection-Notification 5（予約済み）6（HELLO）Hello 20（ACK）明示的確認応答
Call Management
通話管理
7 (OCRQ) Outgoing-Call-Request 8 (OCRP) Outgoing-Call-Reply 9 (OCCN) Outgoing-Call-Connected 10 (ICRQ) Incoming-Call-Request 11 (ICRP) Incoming-Call-Reply 12 (ICCN) Incoming-Call-Connected 13 (reserved) 14 (CDN) Call-Disconnect-Notify
7（OCRQ）発信呼び出し要求8（OCRP）発信呼び出し応答9（OCCN）発信呼び出し接続10（ICRQ）着信呼び出し要求11（ICRP）着信呼び出し応答12（ICCN）着信-Call-Connected 13（予約済み）14（CDN）Call-Disconnect-Notify
Error Reporting
エラー報告
15 (WEN) WAN-Error-Notify
15（WEN）WAN-Error-Notify
Link Status Change Reporting
リンクステータス変更レポート
16 (SLI) Set-Link-Info
16（SLI）Set-Link-Info
This section defines header formats for L2TP control messages and L2TP data messages. All values are placed into their respective fields and sent in network order (high-order octets first).
このセクションでは、L2TP制御メッセージとL2TPデータメッセージのヘッダー形式を定義します。すべての値はそれぞれのフィールドに配置され、ネットワーク順で送信されます（高次オクテットが最初）。
The L2TP control message header provides information for the reliable transport of messages that govern the establishment, maintenance, and teardown of L2TP sessions. By default, control messages are sent over the underlying media in-band with L2TP data messages.
L2TP制御メッセージヘッダーは、L2TPセッションの確立、保守、および破棄を管理するメッセージの信頼できるトランスポートに関する情報を提供します。デフォルトでは、制御メッセージは、L2TPデータメッセージとともに、基盤となるメディアインバンドを介して送信されます。
The L2TP control message header is formatted as follows:
L2TP制御メッセージヘッダーの形式は次のとおりです。
Figure 3.2.1: L2TP Control Message Header
図3.2.1：L2TP制御メッセージヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 1, indicating that this is a control message.
Tビットは、これが制御メッセージであることを示す1に設定する必要があります。
The L and S bits MUST be set to 1, indicating that the Length field and sequence numbers are present.
LおよびSビットは、長さフィールドとシーケンス番号が存在することを示す1に設定する必要があります。
The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages.
xビットは将来の拡張のために予約されています。送信メッセージではすべての予約ビットを0に設定し、受信メッセージでは無視する必要があります。
The Ver field indicates the version of the L2TP control message header described in this document. On sending, this field MUST be set to 3 for all messages (unless operating in an environment that includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 4.1 for details).
Verフィールドは、このドキュメントで説明されているL2TPコントロールメッセージヘッダーのバージョンを示します。送信時には、すべてのメッセージに対してこのフィールドを3に設定する必要があります（L2TPv2 [RFC2661]やL2F [RFC2341]を含む環境で動作している場合を除きます。詳細については、セクション4.1を参照してください）。
The Length field indicates the total length of the message in octets, always calculated from the start of the control message header itself (beginning with the T bit).
長さフィールドは、メッセージの合計長をオクテットで示し、常に制御メッセージヘッダー自体の先頭から計算されます（Tビットで始まります）。
The Control Connection ID field contains the identifier for the control connection. L2TP control connections are named by identifiers that have local significance only. That is, the same control connection will be given unique Control Connection IDs by each LCCE from within each endpoint's own Control Connection ID number space. As such, the Control Connection ID in each message is that of the intended recipient, not the sender. Non-zero Control Connection IDs are selected and exchanged as Assigned Control Connection ID AVPs during the creation of a control connection.
「制御接続ID」フィールドには、制御接続のIDが含まれています。 L2TP制御接続は、ローカルでのみ意味を持つ識別子によって名前が付けられます。つまり、同じ制御接続には、各LCCEによって、各エンドポイントの独自の制御接続ID番号スペース内から固有の制御接続IDが与えられます。そのため、各メッセージのコントロール接続IDは、送信者ではなく、目的の受信者のIDです。ゼロ以外のコントロール接続IDは、コントロール接続の作成中に、割り当てられたコントロール接続ID AVPとして選択および交換されます。
Ns indicates the sequence number for this control message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See Section 4.2 for more information on using this field.
Nsは、この制御メッセージのシーケンス番号を示し、0から始まり、送信されるメッセージごとに1（モジュロ2 ** 16）ずつ増加します。このフィールドの使用の詳細については、セクション4.2を参照してください。
Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-order message received plus one (modulo 2**16). See Section 4.2 for more information on using this field.
Nrは、次に受信する制御メッセージで予期されるシーケンス番号を示します。したがって、Nrは、最後に受信した順序付きメッセージのNsに1を加えた数（2 ** 16を法とする）に設定されます。このフィールドの使用の詳細については、セクション4.2を参照してください。
In general, an L2TP data message consists of a (1) Session Header, (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as depicted below.
一般に、L2TPデータメッセージは、以下に示すように、（1）セッションヘッダー、（2）オプションのL2固有サブレイヤー、および（3）トンネルペイロードで構成されます。
Figure 3.2.2: L2TP Data Message Header
図3.2.2：L2TPデータメッセージヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TP Session Header is specific to the encapsulating PSN over which the L2TP traffic is delivered. The Session Header MUST provide (1) a method of distinguishing traffic among multiple L2TP data sessions and (2) a method of distinguishing data messages from control messages.
L2TPセッションヘッダーは、L2TPトラフィックが配信されるカプセル化PSNに固有です。セッションヘッダーは、（1）複数のL2TPデータセッション間でトラフィックを区別する方法、および（2）データメッセージを制御メッセージから区別する方法を提供する必要があります。
Each type of encapsulating PSN MUST define its own session header, clearly identifying the format of the header and parameters necessary to setup the session. Section 4.1 defines two session headers, one for transport over UDP and one for transport over IP.
カプセル化PSNの各タイプは、独自のセッションヘッダーを定義して、セッションのセットアップに必要なヘッダーとパラメーターの形式を明確に識別しなければなりません（MUST）。セクション4.1では、UDPを介した転送用とIPを介した転送用の2つのセッションヘッダーを定義しています。
The L2-Specific Sublayer is an intermediary layer between the L2TP session header and the start of the tunneled frame. It contains control fields that are used to facilitate the tunneling of each frame (e.g., sequence numbers or flags). The Default L2-Specific Sublayer for L2TPv3 is defined in Section 4.6.
L2固有のサブレイヤーは、L2TPセッションヘッダーとトンネルフレームの開始との間の中間レイヤーです。各フレームのトンネリングを容易にするために使用される制御フィールド（シーケンス番号やフラグなど）が含まれています。 L2TPv3のデフォルトのL2固有のサブレイヤーは、セクション4.6で定義されています。
The Data Message Header is followed by the Tunnel Payload, including any necessary L2 framing as defined in the payload-specific companion documents.
データメッセージヘッダーの後には、ペイロード固有の関連ドキュメントで定義されている必要なL2フレーミングを含む、トンネルペイロードが続きます。
The L2TP control connection handles dynamic establishment, teardown, and maintenance of the L2TP sessions and of the control connection itself. The reliable delivery of control messages is described in Section 4.2.
L2TP制御接続は、L2TPセッションと制御接続自体の動的な確立、破棄、および保守を処理します。制御メッセージの信頼できる配信については、セクション4.2で説明します。
This section describes typical control connection establishment and teardown exchanges. It is important to note that, in the diagrams that follow, the reliable control message delivery mechanism exists independently of the L2TP state machine. For instance, Explicit Acknowledgement (ACK) messages may be sent after any of the control messages indicated in the exchanges below if an acknowledgment is not piggybacked on a later control message.
このセクションでは、一般的な制御接続の確立と破棄の交換について説明します。次の図では、信頼性の高い制御メッセージ配信メカニズムがL2TPステートマシンとは無関係に存在することに注意することが重要です。たとえば、確認応答が後の制御メッセージにピギーバックされていない場合、以下の交換で示されている制御メッセージの後に明示的確認応答（ACK）メッセージが送信されます。
LCCEs are identified during control connection establishment either by the Host Name AVP, the Router ID AVP, or a combination of the two (see Section 5.4.3). The identity of a peer LCCE is central to selecting proper configuration parameters (i.e., Hello interval, window size, etc.) for a control connection, as well as for determining how to set up associated sessions within the control connection, password lookup for control connection authentication, control connection level tie breaking, etc.
LCCEは、制御接続の確立中に、ホスト名AVP、ルーターID AVP、またはこれら2つの組み合わせ（5.4.3を参照）によって識別されます。ピアLCCEのIDは、制御接続の適切な構成パラメーター（つまり、Helloインターバル、ウィンドウサイズなど）の選択、および制御接続内の関連セッションのセットアップ方法の決定、制御のパスワード検索の中心です接続認証、接続レベルのタイブレークの制御など
Establishment of the control connection involves an exchange of AVPs that identifies the peer and its capabilities.
制御接続の確立には、ピアとその機能を識別するAVPの交換が含まれます。
A three-message exchange is used to establish the control connection. The following is a typical message exchange:
制御接続を確立するには、3つのメッセージ交換が使用されます。以下は、一般的なメッセージ交換です。
LCCE A LCCE B
------ ------
SCCRQ ->
<- SCCRP
SCCCN ->
Control connection teardown may be initiated by either LCCE and is accomplished by sending a single StopCCN control message. As part of the reliable control message delivery mechanism, the recipient of a StopCCN MUST send an ACK message to acknowledge receipt of the message and maintain enough control connection state to properly accept StopCCN retransmissions over at least a full retransmission cycle (in case the ACK message is lost). The recommended time for a full retransmission cycle is at least 31 seconds (see Section 4.2). The following is an example of a typical control message exchange:
制御接続の解放は、LCCEによって開始され、単一のStopCCN制御メッセージを送信することによって実行されます。信頼性の高い制御メッセージ配信メカニズムの一部として、StopCCNの受信者はACKメッセージを送信してメッセージの受信を確認し、少なくとも完全な再送信サイクルでStopCCN再送信を適切に受け入れるのに十分な制御接続状態を維持する必要があります（ACKメッセージの場合）失われます）。完全な再送信サイクルの推奨時間は少なくとも31秒です（セクション4.2を参照）。次に、一般的な制御メッセージ交換の例を示します。
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
(Wait) (Clean up)
（待って）（片付け）
An implementation may shut down an entire control connection and all sessions associated with the control connection by sending the StopCCN. Thus, it is not necessary to clear each session individually when tearing down the whole control connection.
実装は、StopCCNを送信することにより、制御接続全体と制御接続に関連付けられたすべてのセッションをシャットダウンできます。したがって、制御接続全体を破棄するときに、各セッションを個別にクリアする必要はありません。
After successful control connection establishment, individual sessions may be created. Each session corresponds to a single data stream between the two LCCEs. This section describes the typical call establishment and teardown exchanges.
制御接続の確立に成功すると、個々のセッションが作成される場合があります。各セッションは、2つのLCCE間の単一のデータストリームに対応します。このセクションでは、一般的なコールの確立と破棄の交換について説明します。
A three-message exchange is used to establish the session. The following is a typical sequence of events:
3つのメッセージ交換がセッションの確立に使用されます。以下は、イベントの一般的なシーケンスです。
LCCE A LCCE B
------ ------
(Call
Detected)
ICRQ -> <- ICRP (Call Accepted)
ICRQ-> <-ICRP（通話受付）
ICCN ->
ICCN->
A three-message exchange is used to set up the session. The following is a typical sequence of events:
3つのメッセージ交換がセッションのセットアップに使用されます。以下は、イベントの一般的なシーケンスです。
LCCE A LCCE B
------ ------
<- OCRQ
OCRP ->
(Perform Call Operation)
（通話操作を行う）
OCCN ->
OCCN->
(Call Operation Completed Successfully)
（通話操作は正常に完了しました）
Session teardown may be initiated by either the LAC or LNS and is accomplished by sending a CDN control message. After the last session is cleared, the control connection MAY be torn down as well (and typically is). The following is an example of a typical control message exchange:
セッションティアダウンは、LACまたはLNSのいずれかによって開始され、CDN制御メッセージを送信することによって実行されます。最後のセッションがクリアされた後、制御接続も切断される場合があります（通常は切断されます）。次に、一般的な制御メッセージ交換の例を示します。
LCCE A LCCE B
------ ------
CDN ->
(Clean up)
(Clean up)
（掃除）
L2TP may operate over a variety of PSNs. There are two modes described for operation over IP, L2TP directly over IP (see Section 4.1.1) and L2TP over UDP (see Section 4.1.2). L2TPv3 implementations MUST support L2TP over IP and SHOULD support L2TP over UDP for better NAT and firewall traversal, and for easier migration from L2TPv2.
L2TPはさまざまなPSNで動作します。 IPを介した操作について説明されている2つのモードがあります。IPを介したL2TP（セクション4.1.1を参照）とUDPを介したL2TP（セクション4.1.2を参照）です。 L2TPv3実装は、L2TP over IPをサポートする必要があり、NATとファイアウォールトラバーサルを改善し、L2TPv2からの移行を容易にするために、L2TP over UDPをサポートする必要があります。
L2TP over other PSNs may be defined, but the specifics are outside the scope of this document. Examples of L2TPv2 over other PSNs include [RFC3070] and [RFC3355].
他のPSN上のL2TPを定義することもできますが、詳細はこのドキュメントの範囲外です。他のPSN上のL2TPv2の例には、[RFC3070]と[RFC3355]が含まれます。
The following field definitions are defined for use in all L2TP Session Header encapsulations.
次のフィールド定義は、すべてのL2TPセッションヘッダーカプセル化で使用するために定義されています。
Session ID
セッションID
A 32-bit field containing a non-zero identifier for a session. L2TP sessions are named by identifiers that have local significance only. That is, the same logical session will be given different Session IDs by each end of the control connection for the life of the session. When the L2TP control connection is used for session establishment, Session IDs are selected and exchanged as Local Session ID AVPs during the creation of a session. The Session ID alone provides the necessary context for all further packet processing, including the presence, size, and value of the Cookie, the type of L2-Specific Sublayer, and the type of payload being tunneled.
セッションのゼロ以外の識別子を含む32ビットのフィールド。 L2TPセッションは、ローカルでのみ意味を持つ識別子によって名前が付けられます。つまり、同じ論理セッションには、セッションの存続期間中、制御接続の両端で異なるセッションIDが与えられます。 L2TP制御接続がセッションの確立に使用される場合、セッションの作成中にセッションIDが選択され、ローカルセッションID AVPとして交換されます。セッションIDだけで、Cookieの存在、サイズ、値、L2固有のサブレイヤーのタイプ、トンネルされるペイロードのタイプなど、以降のすべてのパケット処理に必要なコンテキストが提供されます。
Cookie
クッキー
The optional Cookie field contains a variable-length value (maximum 64 bits) used to check the association of a received data message with the session identified by the Session ID. The Cookie MUST be set to the configured or signaled random value for this session. The Cookie provides an additional level of guarantee that a data message has been directed to the proper session by the Session ID. A well-chosen Cookie may prevent inadvertent misdirection of stray packets with recently reused Session IDs, Session IDs subject to packet corruption, etc. The Cookie may also provide protection against some specific malicious packet insertion attacks, as described in Section 8.2.
オプションのCookieフィールドには、受信したデータメッセージとセッションIDで識別されるセッションとの関連付けを確認するために使用される可変長の値（最大64ビット）が含まれています。 Cookieは、このセッションの構成済みまたは通知済みのランダムな値に設定する必要があります。 Cookieは、データメッセージがセッションIDによって適切なセッションに送信されたことを保証する追加のレベルを提供します。適切に選択されたCookieは、最近再利用されたセッションID、パケットの破損の影響を受けやすいセッションIDなどを含む、迷惑パケットの誤った方向転換を防ぐことができます。Cookieは、セクション8.2で説明されているように、特定の悪意のあるパケット挿入攻撃に対する保護を提供する場合もあります。
When the L2TP control connection is used for session establishment, random Cookie values are selected and exchanged as Assigned Cookie AVPs during session creation.
L2TP制御接続がセッションの確立に使用される場合、ランダムなCookie値が選択され、セッションの作成中に割り当てられたCookie AVPとして交換されます。
L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol ID 115.
L2TPv3 over IP（両方のバージョン）は、IANAによって割り当てられたIPプロトコルID 115を利用します。
Unlike L2TP over UDP, the L2TPv3 session header over IP is free of any restrictions imposed by coexistence with L2TPv2 and L2F. As such, the header format has been designed to optimize packet processing. The following session header format is utilized when operating L2TPv3 over IP:
L2TP over UDPとは異なり、IP上のL2TPv3セッションヘッダーには、L2TPv2およびL2Fとの共存によって課される制限がありません。そのため、ヘッダー形式はパケット処理を最適化するように設計されています。 L2TPv3 over IPを操作する場合、次のセッションヘッダー形式が使用されます。
Figure 4.1.1.1: L2TPv3 Session Header Over IP
図4.1.1.1：IP上のL2TPv3セッションヘッダー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID and Cookie fields are as defined in Section 4.1. The Session ID of zero is reserved for use by L2TP control messages (see Section 4.1.1.2).
セッションIDおよびCookieフィールドは、セクション4.1で定義されています。ゼロのセッションIDは、L2TP制御メッセージで使用するために予約されています（セクション4.1.1.2を参照）。
Unlike L2TP over UDP, which uses the T bit to distinguish between L2TP control and data packets, L2TP over IP uses the reserved Session ID of zero (0) when sending control messages. It is presumed that checking for the zero Session ID is more efficient -- both in header size for data packets and in processing speed for distinguishing between control and data messages -- than checking a single bit.
Tビットを使用してL2TP制御パケットとデータパケットを区別するL2TP over UDPとは異なり、L2TP over IPは制御メッセージを送信するときに予約済みのセッションIDゼロ（0）を使用します。単一のビットをチェックするよりも、ゼロセッションIDをチェックする方が（データパケットのヘッダーサイズと制御メッセージとデータメッセージを区別するための処理速度の両方で）効率的であると考えられます。
The entire control message header over IP, including the zero session ID, appears as follows:
ゼロセッションIDを含む、IP上の制御メッセージヘッダー全体は、次のように表示されます。
Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
図4.1.1.2：IPを介したL2TPv3制御メッセージヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Named fields are as defined in Section 3.2.1. Note that the Length field is still calculated from the beginning of the control message header, beginning with the T bit. It does NOT include the "(32 bits of zeros)" depicted above.
名前付きフィールドは、セクション3.2.1で定義されています。長さフィールドは、制御メッセージヘッダーの先頭から、Tビットで計算されることに注意してください。上記の「（32ビットのゼロ）」は含まれません。
When operating directly over IP, L2TP packets lose the ability to take advantage of the UDP checksum as a simple packet integrity check, which is of particular concern for L2TP control messages. Control Message Authentication (see Section 4.3), even with an empty password field, provides for a sufficient packet integrity check and SHOULD always be enabled.
IPを介して直接操作する場合、L2TPパケットは、UDPチェックサムを単純なパケット整合性チェックとして利用する機能を失います。これは、L2TP制御メッセージに特に関係があります。制御メッセージ認証（セクション4.3を参照）は、パスワードフィールドが空の場合でも、十分なパケット整合性チェックを提供し、常に有効にする必要があります（SHOULD）。
L2TPv3 over UDP must consider other L2 tunneling protocols that may be operating in the same environment, including L2TPv2 [RFC2661] and L2F [RFC2341].
L2TPv3 over UDPは、L2TPv2 [RFC2661]やL2F [RFC2341]など、同じ環境で動作している可能性のある他のL2トンネリングプロトコルを考慮する必要があります。
While there are efficiencies gained by running L2TP directly over IP, there are possible side effects as well. For instance, L2TP over IP is not as NAT-friendly as L2TP over UDP.
L2TPをIPを介して直接実行することで効率が向上しますが、副作用も発生する可能性があります。たとえば、L2TP over IPはL2TP over UDPほどNATに適していません。
The following session header format is utilized when operating L2TPv3 over UDP:
UDPを介してL2TPv3を操作する場合、次のセッションヘッダー形式が使用されます。
Figure 4.1.2.1: L2TPv3 Session Header over UDP
図4.1.2.1：UDP上のL2TPv3セッションヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 0, indicating that this is a data message.
Tビットは0に設定する必要があります。これは、これがデータメッセージであることを示します。
The x bits and Reserved field are reserved for future extensions. All reserved values MUST be set to 0 on outgoing messages and ignored on incoming messages.
xビットとReservedフィールドは、将来の拡張のために予約されています。すべての予約済みの値は、送信メッセージでは0に設定し、受信メッセージでは無視する必要があります。
The Ver field MUST be set to 3, indicating an L2TPv3 message.
Verフィールドは、L2TPv3メッセージを示す3に設定する必要があります。
Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2 [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, for UDP mode on a system that supports both versions of L2TP, it is important that the Ver field be inspected first to determine the Version of the header before acting upon any of these bits.
最初のビット1、4、6、および7はL2TPv2 [RFC2661]で意味があり、非推奨になり、L2TPv3で予約済みとしてマークされていることに注意してください。したがって、L2TPの両方のバージョンをサポートするシステムのUDPモードでは、これらのビットのいずれかを処理する前に、Verフィールドを最初に検査してヘッダーのバージョンを判別することが重要です。
The Session ID and Cookie fields are as defined in Section 4.1.
セッションIDおよびCookieフィールドは、セクション4.1で定義されています。
The method for UDP Port Selection defined in this section is identical to that defined for L2TPv2 [RFC2661].
このセクションで定義されているUDPポート選択の方法は、L2TPv2 [RFC2661]で定義されている方法と同じです。
When negotiating a control connection over UDP, control messages MUST be sent as UDP datagrams using the registered UDP port 1701 [RFC1700]. The initiator of an L2TP control connection picks an available source UDP port (which may or may not be 1701) and sends to the desired destination address at port 1701. The recipient picks a free port on its own system (which may or may not be 1701) and sends its reply to the initiator's UDP port and address, setting its own source port to the free port it found.
UDPを介して制御接続をネゴシエートする場合、登録されたUDPポート1701 [RFC1700]を使用して、制御メッセージをUDPデータグラムとして送信する必要があります。 L2TP制御接続のイニシエーターは、利用可能なソースUDPポート（1701の場合もそうでない場合もある）を選択し、ポート1701で目的の宛先アドレスに送信します。 1701）そして、その応答をイニシエータのUDPポートとアドレスに送信し、独自のソースポートを、見つかった空きポートに設定します。
Any subsequent traffic associated with this control connection (either control traffic or data traffic from a session established through this control connection) must use these same UDP ports.
この制御接続に関連する後続のトラフィック（この制御接続を介して確立されたセッションからの制御トラフィックまたはデータトラフィック）は、これらと同じUDPポートを使用する必要があります。
It has been suggested that having the recipient choose an arbitrary source port (as opposed to using the destination port in the packet initiating the control connection, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementations should consider the potential implication of this capability before choosing an arbitrary source port. A NAT device that can pass TFTP traffic with variant UDP ports should be able to pass L2TP UDP traffic since both protocols employ similar policies with regard to UDP port selection.
受信者に任意の送信元ポートを選択させると（制御接続を開始するパケットで宛先ポートを使用するのではなく、1701など）、L2TPが一部のNATデバイスを通過するのが難しくなる可能性があることが示唆されています。実装では、任意のソースポートを選択する前に、この機能の潜在的な影響を考慮する必要があります。バリアントUDPポートでTFTPトラフィックを渡すことができるNATデバイスは、L2TP UDPトラフィックを渡すことができるはずです。これは、どちらのプロトコルもUDPポートの選択に関して同様のポリシーを採用しているためです。
The tunneled frames that L2TP carry often have their own checksums or integrity checks, rendering the UDP checksum redundant for much of the L2TP data message contents. Thus, UDP checksums MAY be disabled in order to reduce the associated packet processing burden at the L2TP endpoints.
L2TPが伝送するトンネルフレームには、独自のチェックサムまたは整合性チェックが含まれることが多く、L2TPデータメッセージの内容の大部分に対してUDPチェックサムが冗長になります。したがって、L2TPエンドポイントでの関連するパケット処理の負担を軽減するために、UDPチェックサムを無効にすることができます。
The L2TP header itself does not have its own checksum or integrity check. However, use of the L2TP Session ID and Cookie pair guards against accepting an L2TP data message if corruption of the Session ID or associated Cookie has occurred. When the L2-Specific Sublayer is present in the L2TP header, there is no built-in integrity check for the information contained therein if UDP checksums or some other integrity check is not employed. IPsec (see Section 4.1.3) may be used for strong integrity protection of the entire contents of L2TP data messages.
L2TPヘッダー自体には、独自のチェックサムまたは整合性チェックはありません。ただし、L2TPセッションIDとCookieのペアを使用すると、セッションIDまたは関連するCookieの破損が発生した場合に、L2TPデータメッセージが受け入れられないようになります。 L2固有のサブレイヤーがL2TPヘッダーに存在する場合、UDPチェックサムまたはその他の整合性チェックを使用しないと、そこに含まれる情報の組み込みの整合性チェックは行われません。 IPsec（セクション4.1.3を参照）は、L2TPデータメッセージのコンテンツ全体の強力な整合性保護に使用できます。
UDP checksums MUST be enabled for L2TP control messages.
L2TP制御メッセージでは、UDPチェックサムを有効にする必要があります。
The L2TP data channel does not provide cryptographic security of any kind. If the L2TP data channel operates over a public or untrusted IP network where privacy of the L2TP data is of concern or sophisticated attacks against L2TP are expected to occur, IPsec [RFC2401] MUST be made available to secure the L2TP traffic.
L2TPデータチャネルは、いかなる種類の暗号化セキュリティも提供しません。 L2TPデータチャネルがL2TPデータのプライバシーが懸念されるパブリックまたは信頼できないIPネットワーク上で動作する場合、またはL2TPに対する高度な攻撃が発生すると予想される場合、L2TPトラフィックを保護するためにIPsec [RFC2401]を使用できるようにする必要があります。
Either L2TP over UDP or L2TP over IP may be secured with IPsec. [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 possesses identical characteristics to IPsec as L2TPv2 when running over UDP and implementations MUST follow the same recommendation. When operating over IP directly, [RFC3193] still applies, though references to UDP source and destination ports (in particular, those in Section 4, "IPsec Filtering details when protecting L2TP") may be ignored. Instead, the selectors used to identify L2TPv3 traffic are simply the source and destination IP addresses for the tunnel endpoints together with the L2TPv3 IP protocol type, 115.
L2TP over UDPまたはL2TP over IPは、IPsecで保護できます。 [RFC3193]は、L2TPv2を保護するための推奨方法を定義しています。 L2TPv3は、UDPを介して実行する場合、L2TPv2と同じIPsecと同じ特性を持ち、実装は同じ推奨に従う必要があります。 IPで直接操作する場合、[RFC3193]は引き続き適用されますが、UDPの送信元および宛先ポート（特に、セクション4「L2TPを保護する場合のIPsecフィルタリングの詳細」の参照）への参照は無視される場合があります。代わりに、L2TPv3トラフィックの識別に使用されるセレクターは、L2TPv3 IPプロトコルタイプ115とともに、トンネルエンドポイントの送信元および宛先IPアドレスにすぎません。
In addition to IP transport security, IPsec defines a mode of operation that allows tunneling of IP packets. The packet-level encryption and authentication provided by IPsec tunnel mode and that provided by L2TP secured with IPsec provide an equivalent level of security for these requirements.
IPトランスポートセキュリティに加えて、IPsecはIPパケットのトンネリングを可能にする動作モードを定義します。 IPsecトンネルモードによって提供されるパケットレベルの暗号化と認証、およびIPsecで保護されたL2TPによって提供されるものは、これらの要件に対して同等レベルのセキュリティを提供します。
IPsec also defines access control features that are required of a compliant IPsec implementation. These features allow filtering of packets based upon network and transport layer characteristics such as IP address, ports, etc. In the L2TP tunneling model, analogous filtering may be performed at the network layer above L2TP. These network layer access control features may be handled at an LCCE via vendor-specific authorization features, or at the network layer itself by using IPsec transport mode end-to-end between the communicating hosts. The requirements for access control mechanisms are not a part of the L2TP specification, and as such, are outside the scope of this document.
IPsecは、準拠したIPsec実装に必要なアクセス制御機能も定義します。これらの機能により、IPアドレス、ポートなどのネットワークおよびトランスポート層の特性に基づいてパケットをフィルタリングできます。L2TPトンネリングモデルでは、L2TPの上のネットワーク層で類似のフィルタリングを実行できます。これらのネットワーク層アクセス制御機能は、ベンダー固有の認証機能を介してLCCEで処理するか、通信ホスト間でエンドツーエンドのIPsecトランスポートモードを使用してネットワーク層自体で処理できます。アクセス制御メカニズムの要件はL2TP仕様の一部ではないため、このドキュメントの範囲外です。
Protecting the L2TP packet stream with IPsec does, in turn, also protect the data within the tunneled session packets while transported from one LCCE to the other. Such protection must not be considered a substitution for end-to-end security between communicating hosts or applications.
L2TPパケットストリームをIPsecで保護すると、1つのLCCEから別のLCCEに転送されている間、トンネルセッションパケット内のデータも保護されます。そのような保護は、通信しているホストまたはアプリケーション間のエンドツーエンドのセキュリティの代替と見なしてはなりません。
Fragmentation and reassembly in network equipment generally require significantly greater resources than sending or receiving a packet as a single unit. As such, fragmentation and reassembly should be avoided whenever possible. Ideal solutions for avoiding fragmentation include proper configuration and management of MTU sizes among the Remote System, the LCCE, and the IP network, as well as adaptive measures that operate with the originating host (e.g., [RFC1191], [RFC1981]) to reduce the packet sizes at the source.
ネットワーク機器でのフラグメンテーションと再構成には、一般に、パケットを単一のユニットとして送受信するよりもはるかに多くのリソースが必要です。そのため、断片化と再構成は可能な限り回避する必要があります。断片化を回避するための理想的なソリューションには、リモートシステム、LCCE、およびIPネットワーク間でのMTUサイズの適切な構成と管理、および元のホスト（たとえば[RFC1191]、[RFC1981]）と連携して動作する適応策が含まれます。送信元でのパケットサイズ。
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation. This creates two (or more) L2TP packets, each carrying an IPv4 fragment with its associated framing. This ultimately has the effect of placing the burden of fragmentation on the LCCE, while reassembly occurs on the IPv4 destination host.
LCCEは、パケットをL2TPにカプセル化する前にパケットをフラグメント化してもよい（MAY）。たとえば、IPv4パケットがリモートシステムからLCCEに到着し、関連するフレーミング、L2TP、およびIPでカプセル化した後、LCCEピアへの利用可能なパスMTUに適合しない場合、ローカルLCCEはIPv4フラグメンテーションを実行することがあります。トンネルカプセル化前のパケット。これにより、2つ（またはそれ以上）のL2TPパケットが作成され、それぞれがIPv4フラグメントとそれに関連するフレーミングを伝送します。これには最終的に、LCCEに断片化の負担をかける効果があり、IPv4宛先ホストで再構成が行われます。
If an IPv6 packet arrives at an LCCE from a Remote System that, after encapsulation with associated framing, L2TP and IP, does not fit in the available path MTU towards its L2TP peer, the Generic Packet Tunneling specification [RFC2473], Section 7.1 SHOULD be followed. In this case, the LCCE should either send an ICMP Packet Too Big message to the data source, or fragment the resultant L2TP/IP packet (for reassembly by the L2TP peer).
IPv6パケットがリモートシステムからLCCEに到着し、関連するフレーミング、L2TPおよびIPでカプセル化した後、L2TPピアへの利用可能なパスMTUに適合しない場合、Generic Packet Tunneling仕様[RFC2473]、セクション7.1続く。この場合、LCCEはICMP Packet Too Bigメッセージをデータソースに送信するか、結果のL2TP / IPパケットをフラグメント化する必要があります（L2TPピアによる再構成のため）。
If the amount of traffic requiring fragmentation and reassembly is rather light, or there are sufficiently optimized mechanisms at the tunnel endpoints, fragmentation of the L2TP/IP packet may be sufficient for accommodating mismatched MTUs that cannot be managed by more efficient means. This method effectively emulates a larger MTU between tunnel endpoints and should work for any type of L2- encapsulated packet. Note that IPv6 does not support "in-flight" fragmentation of data packets. Thus, unlike IPv4, the MTU of the path towards an L2TP peer must be known in advance (or the last resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6 fragmentation may occur at the LCCE.
断片化と再構成を必要とするトラフィックの量がかなり少ない場合、またはトンネルエンドポイントで十分に最適化されたメカニズムがある場合、L2TP / IPパケットの断片化は、より効率的な手段では管理できない不一致のMTUに対応するのに十分な場合があります。この方法は、トンネルエンドポイント間のより大きなMTUを効果的にエミュレートし、どのタイプのL2カプセル化パケットでも機能するはずです。 IPv6はデータパケットの「処理中」の断片化をサポートしないことに注意してください。したがって、IPv4とは異なり、LCCEでIPv6フラグメンテーションが発生するように、L2TPピアに向かうパスのMTU（または使用される最後の手段IPv6の最小MTU 1280バイト）を事前に知っておく必要があります。
In summary, attempting to control the source MTU by communicating with the originating host, forcing that an MTU be sufficiently large on the path between LCCE peers to tunnel a frame from any other interface without fragmentation, fragmenting IP packets before encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP packet between the tunnel endpoints, are all valid methods for managing MTU mismatches. Some are clearly better than others depending on the given deployment. For example, a passive monitoring application using L2TP would certainly not wish to have ICMP messages sent to a traffic source. Further, if the links connecting a set of LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that the MTU of all links being tunneled by L2TP have smaller MTUs (e.g., 1500 bytes), then any IP fragmentation and reassembly enabled on the participating LCCEs would never be utilized. An implementation MUST implement at least one of the methods described in this section for managing mismatched MTUs, based on careful consideration of how the final product will be deployed.
要約すると、発信元ホストと通信することによりソースMTUを制御しようとし、LCCEピア間のパスでMTUを十分に大きくして、断片化せずに他のインターフェイスからフレームをトンネルし、L2TP / IPでカプセル化する前にIPパケットを断片化します。または、トンネルエンドポイント間で結果のL2TP / IPパケットを断片化することは、すべてMTUの不一致を管理するための有効な方法です。特定の展開によっては、他のものより明らかに優れているものもあります。たとえば、L2TPを使用するパッシブモニタリングアプリケーションでは、トラフィックソースにICMPメッセージが送信されることは望ましくありません。さらに、LCCEのセットを接続するリンクのMTUが非常に大きい場合（SDH / SONETなど）、L2TPによってトンネリングされるすべてのリンクのMTUのMTUが小さいことがわかっている場合（1500バイトなど）、IPフラグメンテーション参加しているLCCEで有効にされた再構成は使用されません。実装は、最終製品がどのように展開されるかを慎重に検討して、不一致のMTUを管理するために、このセクションで説明する方法の少なくとも1つを実装する必要があります。
L2TP-specific fragmentation and reassembly methods, which may or may not depend on the characteristics of the type of link being tunneled (e.g., judicious packing of ATM cells), may be defined as well, but these methods are outside the scope of this document.
トンネリングされるリンクのタイプの特性に依存する場合としない場合があるL2TP固有の断片化および再構成方法（ATMセルの賢明なパッキングなど）も定義できますが、これらの方法はこのドキュメントの範囲外です。
L2TP provides a lower level reliable delivery service for all control messages. The Nr and Ns fields of the control message header (see Section 3.2.1) belong to this delivery mechanism. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages. The reliable control messaging mechanism is a sliding window mechanism that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for each control connection.
L2TPは、すべての制御メッセージに低レベルの信頼できる配信サービスを提供します。制御メッセージヘッダーのNrおよびNsフィールド（セクション3.2.1を参照）は、この配信メカニズムに属します。 L2TPの上位レベルの機能は、制御メッセージの再送信や順序付けには関係しません。信頼性の高い制御メッセージングメカニズムは、制御メッセージの再送信と輻輳制御を提供するスライディングウィンドウメカニズムです。各ピアは、制御接続ごとに個別のシーケンス番号状態を維持します。
The message sequence number, Ns, begins at 0. Each subsequent message is sent with the next increment of the sequence number. The sequence number is thus a free-running counter represented modulo 65536. The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32767 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered a duplicate of a message already received and ignored from processing. However, in order to ensure that all messages are acknowledged properly (particularly in the case of a lost ACK message), receipt of duplicate messages MUST be acknowledged by the reliable delivery mechanism. This acknowledgment may either piggybacked on a message in queue or sent explicitly via an ACK message.
メッセージのシーケンス番号Nsは0から始まります。後続の各メッセージは、シーケンス番号の次の増分で送信されます。したがって、シーケンス番号は、65536を法として表されるフリーランニングカウンターです。受信メッセージのヘッダー内のシーケンス番号は、その値が最後に受信した番号とその前の番号の範囲内にある場合、最後に受信した番号以下であると見なされます。 32767の値を含みます。たとえば、最後に受信したシーケンス番号が15の場合、シーケンス番号0〜15、および32784〜65535のメッセージは、以下と見なされます。このようなメッセージは、すでに受信され、処理から無視されたメッセージの複製と見なされます。ただし、すべてのメッセージが適切に確認されるようにするため（特に、ACKメッセージが失われた場合）、重複メッセージの受信は、信頼できる配信メカニズムによって確認されなければなりません（MUST）。この確認応答は、キュー内のメッセージに便乗するか、ACKメッセージを介して明示的に送信されます。
All control messages take up one slot in the control message sequence number space, except the ACK message. Thus, Ns is not incremented after an ACK message is sent.
すべての制御メッセージは、ACKメッセージを除いて、制御メッセージシーケンス番号スペースで1つのスロットを占有します。したがって、ACKメッセージが送信された後、Nsは増分されません。
The last received message number, Nr, is used to acknowledge messages received by an L2TP peer. It contains the sequence number of the message the peer expects to receive next (e.g., the last Ns of a non-ACK message received plus 1, modulo 65536). While the Nr in a received ACK message is used to flush messages from the local retransmit queue (see below), the Nr of the next message sent is not updated by the Ns of the ACK message. Nr SHOULD be sanity-checked before flushing the retransmit queue. For instance, if the Nr received in a control message is greater than the last Ns sent plus 1 modulo 65536, the control message is clearly invalid.
最後に受信したメッセージ番号Nrは、L2TPピアが受信したメッセージを確認するために使用されます。これには、ピアが次に受信することを期待しているメッセージのシーケンス番号が含まれます（たとえば、受信した非ACKメッセージの最後のNに1、65536を法として）。受信したACKメッセージのNrは、ローカルの再送信キューからメッセージをフラッシュするために使用されますが（以下を参照）、送信された次のメッセージのNrは、ACKメッセージのNsによって更新されません。再送信キューをフラッシュする前に、健全性チェックを行う必要があります（SHOULD）。たとえば、制御メッセージで受信されたNrが、送信された最後のNsに65536を法とする1より大きい場合、制御メッセージは明らかに無効です。
The reliable delivery mechanism at a receiving peer is responsible for making sure that control messages are delivered in order and without duplication to the upper level. Messages arriving out-of-order may be queued for in-order delivery when the missing messages are received. Alternatively, they may be discarded, thus requiring a retransmission by the peer. When dropping out-of-order control packets, Nr MAY be updated before the packet is discarded.
受信ピアの信頼できる配信メカニズムは、制御メッセージが順序どおりに、かつ上位レベルに重複することなく配信されるようにする責任があります。順序が狂って到着したメッセージは、不足しているメッセージが受信されたときに、順序どおりの配信のためにキューに入れられる場合があります。あるいは、それらは破棄されてもよく、したがって、ピアによる再送信が必要です。順不同の制御パケットをドロップする場合、Nrはパケットが破棄される前に更新される場合があります。
Each control connection maintains a queue of control messages to be transmitted to its peer. The message at the front of the queue is sent with a given Ns value and is held until a control message arrives from the peer in which the Nr field indicates receipt of this message. After a period of time (a recommended default is 1 second but SHOULD be configurable) passes without acknowledgment, the message is retransmitted. The retransmitted message contains the same Ns value, but the Nr value MUST be updated with the sequence number of the next expected message.
各制御接続は、そのピアに送信される制御メッセージのキューを維持します。キューの前のメッセージは、指定されたNs値で送信され、Nrフィールドがこのメッセージの受信を示すピアから制御メッセージが到着するまで保持されます。確認応答なしに一定の時間が経過すると（推奨されるデフォルトは1秒ですが、構成可能である必要があります）、メッセージは再送信されます。再送信されたメッセージには同じNs値が含まれていますが、Nr値は次に予期されるメッセージのシーケンス番号で更新する必要があります。
Each subsequent retransmission of a message MUST employ an exponential backoff interval. Thus, if the first retransmission occurred after 1 second, the next retransmission should occur after 2 seconds has elapsed, then 4 seconds, etc. An implementation MAY place a cap upon the maximum interval between retransmissions. This cap SHOULD be no less than 8 seconds per retransmission. If no peer response is detected after several retransmissions (a recommended default is 10, but MUST be configurable), the control connection and all associated sessions MUST be cleared. As it is the first message to establish a control connection, the SCCRQ MAY employ a different retransmission maximum than other control messages in order to help facilitate failover to alternate LCCEs in a timely fashion.
メッセージの後続の各再送信では、指数バックオフ間隔を使用する必要があります。したがって、最初の再送信が1秒後に発生した場合、次の再送信は2秒が経過した後に発生し、4秒が経過するなどします。実装は、再送信間の最大間隔に上限を設定できます（MAY）。この上限は、再送信ごとに8秒以上である必要があります。数回の再送信後にピア応答が検出されない場合（推奨されるデフォルトは10ですが、構成可能でなければなりません）、制御接続とすべての関連セッションをクリアする必要があります。制御接続を確立する最初のメッセージであるため、SCCRQは他の制御メッセージとは異なる再送信の最大値を使用して、適時の代替LCCEへのフェイルオーバーを容易にすることができます。
When a control connection is being shut down for reasons other than loss of connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8 + 8... seconds), or until the StopCCN message itself has been acknowledged.
接続の喪失以外の理由で制御接続がシャットダウンされている場合、最後のメッセージStopCCNメッセージが送信された後、完全な再送信間隔の間、状態と信頼できる配信メカニズムを維持および運用する必要があります（たとえば、1 + 2 + 4 + 8 + 8 ...秒）、またはStopCCNメッセージ自体が確認されるまで。
A sliding window mechanism is used for control message transmission and retransmission. Consider two peers, A and B. Suppose A specifies a Receive Window Size AVP with a value of N in the SCCRQ or SCCRP message. B is now allowed to have a maximum of N outstanding (i.e., unacknowledged) control messages. Once N messages have been sent, B must wait for an acknowledgment from A that advances the window before sending new control messages. An implementation may advertise a non-zero receive window as small or as large as it wishes, depending on its own ability to process incoming messages before sending an acknowledgement. Each peer MUST limit the number of unacknowledged messages it will send before receiving an acknowledgement by this Receive Window Size. The actual internal unacknowledged message send-queue depth may be further limited by local resource allocation or by dynamic slow-start and congestion-avoidance mechanisms.
スライディングウィンドウメカニズムは、制御メッセージの送信と再送信に使用されます。 2つのピアAとBについて考えてみます。Aが、SCCRQまたはSCCRPメッセージで値Nの受信ウィンドウサイズAVPを指定しているとします。 Bは、最大N個の未処理（つまり、未確認）の制御メッセージを持つことができます。 N個のメッセージが送信されると、Bは新しい制御メッセージを送信する前に、ウィンドウを進めるAからの確認応答を待つ必要があります。実装は、確認応答を送信する前に着信メッセージを処理する独自の機能に応じて、ゼロ以外の受信ウィンドウを必要なだけ小さくまたは大きくアドバタイズできます。各ピアは、この受信ウィンドウサイズで確認応答を受信する前に、送信する未確認メッセージの数を制限する必要があります。実際の内部未確認メッセージ送信キューの深さは、ローカルリソースの割り当てまたは動的なスロースタートと輻輳回避メカニズムによってさらに制限される場合があります。
When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized. A recommended procedure is described in Appendix A. A peer MAY drop messages, but MUST NOT actively delay acknowledgment of messages as a technique for flow control of control messages. Appendix B contains examples of control message transmission, acknowledgment, and retransmission.
制御メッセージを再送信するときは、スロースタートと輻輳回避ウィンドウの調整手順を使用する必要があります（SHOULD）。推奨手順は、付録Aで説明されています。ピアはメッセージをドロップできますが、制御メッセージのフロー制御の手法として、メッセージの確認応答をアクティブに遅延させてはなりません（MUST NOT）。付録Bには、制御メッセージの送信、確認、および再送信の例が含まれています。
L2TP incorporates an optional authentication and integrity check for all control messages. This mechanism consists of a computed one-way hash over the header and body of the L2TP control message, a pre-configured shared secret, and a local and remote nonce (random value) exchanged via the Control Message Authentication Nonce AVP. This per-message authentication and integrity check is designed to perform a mutual authentication between L2TP nodes, perform integrity checking of all control messages, and guard against control message spoofing and replay attacks that would otherwise be trivial to mount.
L2TPには、すべての制御メッセージに対するオプションの認証と整合性チェックが組み込まれています。このメカニズムは、L2TP制御メッセージのヘッダーと本文に対する計算された一方向ハッシュ、事前構成された共有シークレット、および制御メッセージ認証ノンスAVPを介して交換されるローカルおよびリモートのナンス（ランダムな値）で構成されます。このメッセージごとの認証と整合性チェックは、L2TPノード間で相互認証を実行し、すべての制御メッセージの整合性チェックを実行し、さもなければマウントするのが簡単な制御メッセージのなりすましやリプレイ攻撃から保護するように設計されています。
At least one shared secret (password) MUST exist between communicating L2TP nodes to enable Control Message Authentication. See Section 5.4.3 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.
制御メッセージ認証を有効にするには、通信するL2TPノード間に少なくとも1つの共有シークレット（パスワード）が存在する必要があります。メッセージダイジェストの計算、および制御メッセージ認証ノンスとメッセージダイジェストAVPの構築の詳細については、セクション5.4.3を参照してください。
L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a shared secret and one-way hash calculation. The principal difference is that, instead of computing the hash over selected contents of a received control message (e.g., the Challenge AVP and Message Type) as in L2TPv2, the entire message is used in the hash in L2TPv3. In addition, instead of including the hash digest in just the SCCRP and SCCCN messages, it is now included in all L2TP messages.
L2TPv3制御メッセージ認証は、共有シークレットと一方向ハッシュ計算を使用する点でL2TPv2 [RFC2661]トンネル認証に似ています。主な違いは、L2TPv2のように、受信した制御メッセージ（チャレンジAVPやメッセージタイプなど）の選択されたコンテンツのハッシュを計算する代わりに、L2TPv3のハッシュでメッセージ全体が使用されることです。さらに、ハッシュダイジェストをSCCRPおよびSCCCNメッセージだけに含める代わりに、すべてのL2TPメッセージに含まれるようになりました。
The Control Message Authentication mechanism is optional, and may be disabled if both peers agree. For example, if IPsec is already being used for security and integrity checking between the LCCEs, the function of the L2TP mechanism becomes redundant and may be disabled.
制御メッセージ認証メカニズムはオプションであり、両方のピアが同意する場合は無効にすることができます。たとえば、LCCE間のセキュリティおよび整合性チェックにIPsecがすでに使用されている場合、L2TPメカニズムの機能は冗長になり、無効になる可能性があります。
Presence of the Control Message Authentication Nonce AVP in an SCCRQ or SCCRP message serves as indication to a peer that Control Message Authentication is enabled. If an SCCRQ or SCCRP contains a Control Message Authentication Nonce AVP, the receiver of the message MUST respond with a Message Digest AVP in all subsequent messages sent. Control Message Authentication is always bidirectional; either both sides participate in authentication, or neither does.
SCCRQまたはSCCRPメッセージ内の制御メッセージ認証ノンスAVPの存在は、制御メッセージ認証が有効になっていることをピアに示します。 SCCRQまたはSCCRPに制御メッセージ認証ノンスAVPが含まれている場合、メッセージの受信者は、送信される後続のすべてのメッセージでメッセージダイジェストAVPで応答する必要があります。制御メッセージ認証は常に双方向です。両方が認証に参加するか、どちらも参加しません。
If Control Message Authentication is disabled, the Message Digest AVP still MAY be sent as an integrity check of the message. The integrity check is calculated as in Section 5.4.3, with an empty zero-length shared secret, local nonce, and remote nonce. If an invalid Message Digest is received, it should be assumed that the message has been corrupted in transit and the message dropped accordingly.
メッセージ認証の制御が無効になっている場合でも、メッセージダイジェストAVPをメッセージの整合性チェックとして送信できます（MAY）。整合性チェックは、セクション5.4.3と同様に、長さがゼロの共有シークレット、ローカルナンス、およびリモートナンスを使用して計算されます。無効なメッセージダイジェストが受信された場合、メッセージは送信中に破損しており、それに応じてメッセージがドロップされたと見なされます。
Implementations MAY rate-limit control messages, particularly SCCRQ messages, upon receipt for performance reasons or for protection against denial of service attacks.
実装は、パフォーマンス上の理由から、またはサービス拒否攻撃に対する保護のために、受信時にレート制限制御メッセージ（特にSCCRQメッセージ）を制限する場合があります。
L2TP employs a keepalive mechanism to detect loss of connectivity between a pair of LCCEs. This is accomplished by injecting Hello control messages (see Section 6.5) after a period of time has elapsed since the last data message or control message was received on an L2TP session or control connection, respectively. As with any other control message, if the Hello message is not reliably delivered, the sending LCCE declares that the control connection is down and resets its state for the control connection. This behavior ensures that a connectivity failure between the LCCEs is detected independently by each end of a control connection.
L2TPは、キープアライブメカニズムを使用して、LCCEのペア間の接続の喪失を検出します。これは、最後のデータメッセージまたは制御メッセージがそれぞれL2TPセッションまたは制御接続で受信されてから一定期間が経過した後に、Hello制御メッセージ（6.5節を参照）を挿入することによって実現されます。他の制御メッセージと同様に、Helloメッセージが確実に配信されない場合、送信LCCEは制御接続がダウンしていることを宣言し、制御接続の状態をリセットします。この動作により、LCCE間の接続障害が制御接続の両端で個別に検出されることが保証されます。
Since the control channel is operated in-band with data traffic over the PSN, this single mechanism can be used to infer basic data connectivity between a pair of LCCEs for all sessions associated with the control connection.
制御チャネルはPSN上のデータトラフィックとインバンドで動作するため、この単一のメカニズムを使用して、制御接続に関連付けられたすべてのセッションのLCCEペア間の基本的なデータ接続を推測できます。
Periodic keepalive for the control connection MUST be implemented by sending a Hello if a period of time (a recommended default is 60 seconds, but MUST be configurable) has passed without receiving any message (data or control) from the peer. An LCCE sending Hello messages across multiple control connections between the same LCCE endpoints MUST employ a jittered timer mechanism to prevent grouping of Hello messages.
ピアからメッセージ（データまたはコントロール）を受信せずに一定期間（推奨されるデフォルトは60秒ですが、構成可能でなければなりません）が経過した場合は、制御接続の定期的なキープアライブをHelloを送信して実装する必要があります。同じLCCEエンドポイント間の複数の制御接続でHelloメッセージを送信するLCCEは、ジッタータイマーメカニズムを使用して、Helloメッセージのグループ化を防止する必要があります。
Once session establishment is complete, circuit frames are received at an LCCE, encapsulated in L2TP (with appropriate attention to framing, as described in documents for the particular pseudowire type), and forwarded over the appropriate session. For every outgoing data message, the sender places the identifier specified in the Local Session ID AVP (received from peer during session establishment) in the Session ID field of the L2TP data header. In this manner, session frames are multiplexed and demultiplexed between a given pair of LCCEs. Multiple control connections may exist between a given pair of LCCEs, and multiple sessions may be associated with a given control connection.
セッションの確立が完了すると、回路フレームはLCCEで受信され、L2TPでカプセル化され（特定の疑似配線タイプのドキュメントで説明されているように、フレーミングに適切に注意して）、適切なセッションで転送されます。すべての発信データメッセージについて、送信者はローカルセッションID AVPで指定された識別子（セッション確立中にピアから受信）をL2TPデータヘッダーのセッションIDフィールドに配置します。このようにして、セッションフレームはLCCEの特定のペア間で多重化および逆多重化されます。 LCCEの特定のペア間に複数の制御接続が存在し、複数のセッションが特定の制御接続に関連付けられている場合があります。
The peer LCCE receiving the L2TP data packet identifies the session with which the packet is associated by the Session ID in the data packet's header. The LCCE then checks the Cookie field in the data packet against the Cookie value received in the Assigned Cookie AVP during session establishment. It is important for implementers to note that the Cookie field check occurs after looking up the session context by the Session ID, and as such, consists merely of a value match of the Cookie field and that stored in the retrieved context. There is no need to perform a lookup across the Session ID and Cookie as a single value. Any received data packets that contain invalid Session IDs or associated Cookie values MUST be dropped. Finally, the LCCE either forwards the network packet within the tunneled frame (e.g., as an LNS) or switches the frame to a circuit (e.g., as an LAC).
L2TPデータパケットを受信するピアLCCEは、データパケットのヘッダーのセッションIDによって、パケットが関連付けられているセッションを識別します。次に、LCCEは、データパケットのCookieフィールドを、セッションの確立中に割り当てられたCookie AVPで受信したCookie値と照合します。実装者にとって、CookieフィールドのチェックはセッションIDでセッションコンテキストを検索した後に行われるため、Cookieフィールドと取得したコンテキストに格納された値の一致のみで構成されることに注意することが重要です。セッションIDとCookieを単一の値として検索する必要はありません。無効なセッションIDまたは関連付けられたCookie値を含む受信データパケットはすべてドロップする必要があります。最後に、LCCEはネットワークパケットをトンネルフレーム内で転送するか（たとえば、LNSとして）、またはフレームを回線に切り替えます（たとえば、LACとして）。
This document defines a Default L2-Specific Sublayer format (see Section 3.2.2) that a pseudowire may use for features such as sequencing support, L2 interworking, OAM, or other per-data-packet operations. The Default L2-Specific Sublayer SHOULD be used by a given PW type to support these features if it is adequate, and its presence is requested by a peer during session negotiation. Alternative sublayers MAY be defined (e.g., an encapsulation with a larger Sequence Number field or timing information) and identified for use via the L2-Specific Sublayer Type AVP.
このドキュメントでは、疑似配線がシーケンスサポート、L2インターワーキング、OAM、その他のデータパケットごとの操作などの機能に使用できるデフォルトのL2固有のサブレイヤ形式（セクション3.2.2を参照）を定義しています。デフォルトのL2固有のサブレイヤーは、適切な場合にこれらの機能をサポートするために、特定のPWタイプによって使用されるべきであり、その存在は、セッションネゴシエーション中にピアによって要求されます。代替サブレイヤーを定義して（たとえば、より大きなシーケンス番号フィールドまたはタイミング情報を含むカプセル化）、L2固有のサブレイヤータイプAVPを介して使用するために識別できます。
Figure 4.6: Default L2-Specific Sublayer Format
図4.6：デフォルトのL2固有のサブレイヤー形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S (Sequence) bit is set to 1 when the Sequence Number contains a valid number for this sequenced frame. If the S bit is set to zero, the Sequence Number contents are undefined and MUST be ignored by the receiver.
シーケンス番号にこのシーケンスされたフレームの有効な番号が含まれている場合、S（シーケンス）ビットは1に設定されます。 Sビットが0に設定されている場合、シーケンス番号の内容は未定義であり、受信者は無視する必要があります。
The Sequence Number field contains a free-running counter of 2^24 sequence numbers. If the number in this field is valid, the S bit MUST be set to 1. The Sequence Number begins at zero, which is a valid sequence number. (In this way, implementations inserting sequence numbers do not have to "skip" zero when incrementing.) The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding (2^23-1) values, inclusive.
シーケンス番号フィールドには、2 ^ 24のシーケンス番号のフリーランニングカウンターが含まれています。このフィールドの番号が有効な場合、Sビットを1に設定する必要があります。シーケンス番号は、有効なシーケンス番号であるゼロから始まります。 （このようにして、シーケンス番号を挿入する実装は、インクリメントするときにゼロを「スキップ」する必要はありません。）値が次の範囲内にある場合、受信メッセージのヘッダーのシーケンス番号は、最後に受信した番号以下であると見なされます。最後に受信した数とその前の（2 ^ 23-1）の値を含みます。
The Sequence Number field may be used to detect lost, duplicate, or out-of-order packets within a given session.
シーケンス番号フィールドは、特定のセッション内の失われたパケット、重複したパケット、または順序が正しくないパケットを検出するために使用できます。
When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP data channel, this part of the link has the characteristic of being able to reorder, duplicate, or silently drop packets. Reordering may break some non-IP protocols or L2 control traffic being carried by the link. Silent dropping or duplication of packets may break protocols that assume per-packet indications of error, such as TCP header compression. While a common mechanism for packet sequence detection is provided, the sequence dependency characteristics of individual protocols are outside the scope of this document.
L2フレームがL2TP-over-IPまたはL2TP-over-UDP / IPデータチャネルを介して伝送される場合、リンクのこの部分には、パケットを並べ替えたり、複製したり、サイレントにドロップしたりできるという特性があります。並べ替えにより、一部の非IPプロトコルまたはリンクによって伝送されているL2制御トラフィックが壊れる可能性があります。サイレントドロップまたはパケットの複製により、TCPヘッダー圧縮など、パケットごとのエラーを示すプロトコルが機能しなくなる場合があります。パケットシーケンス検出の一般的なメカニズムが提供されていますが、個々のプロトコルのシーケンス依存特性はこのドキュメントの範囲外です。
If any protocol being transported by over L2TP data channels cannot tolerate misordering of data packets, packet duplication, or silent packet loss, sequencing may be enabled on some or all packets by using the S bit and Sequence Number field defined in the Default L2- Specific Sublayer (see Section 4.6). For a given L2TP session, each LCCE is responsible for communicating to its peer the level of sequencing support that it requires of data packets that it receives. Mechanisms to advertise this information during session negotiation are provided (see Data Sequencing AVP in Section 5.4.4).
L2TPデータチャネルを介して転送されるプロトコルがデータパケットの順序の乱れ、パケットの複製、またはサイレントパケット損失を許容できない場合、デフォルトのL2固有で定義されているSビットとシーケンス番号フィールドを使用して、一部またはすべてのパケットでシーケンスを有効にできます。サブレイヤー（セクション4.6を参照）。特定のL2TPセッションでは、各LCCEは、受信するデータパケットに必要なシーケンスサポートのレベルをピアに通信します。セッションネゴシエーション中にこの情報をアドバタイズするメカニズムが提供されます（セクション5.4.4のデータシーケンスAVPを参照）。
When determining whether a packet is in or out of sequence, an implementation SHOULD utilize a method that is resilient to temporary dropouts in connectivity coupled with high per-session packet rates. The recommended method is outlined in Appendix C.
パケットがシーケンス内にあるのかシーケンス外にあるのかを判断する場合、実装では、セッションごとのパケットレートが高く、接続性の一時的なドロップアウトに対して耐性のある方法を使用する必要があります。推奨される方法の概要は、付録Cにあります。
L2TPv2 and L2TPv3 environments should be able to coexist while a migration to L2TPv3 is made. Migration issues are discussed for each media type in this section. Most issues apply only to implementations that require both L2TPv2 and L2TPv3 operation.
L2TPv3への移行が行われている間、L2TPv2およびL2TPv3環境は共存できるはずです。このセクションでは、メディアの種類ごとに移行の問題について説明します。ほとんどの問題は、L2TPv2とL2TPv3の両方の動作を必要とする実装にのみ適用されます。
However, even L2TPv3-only implementations must at least be mindful of these issues in order to interoperate with implementations that support both versions.
ただし、L2TPv3のみの実装であっても、両方のバージョンをサポートする実装と相互運用するためには、少なくともこれらの問題に注意する必要があります。
L2TPv3 implementations running strictly over IP with no desire to interoperate with L2TPv2 implementations may safely disregard most migration issues from L2TPv2. All control messages and data messages are sent as described in this document, without normative reference to RFC 2661.
L2TPv2実装と相互運用することを望まずにIP上で厳密に実行されているL2TPv3実装は、L2TPv2からのほとんどの移行問題を安全に無視できます。すべての制御メッセージとデータメッセージは、RFC 2661への規範的な参照なしで、このドキュメントで説明されているように送信されます。
If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only if it is not available, then L2TPv3 over UDP with automatic fallback (see Section 4.7.3) MUST be used. There is no deterministic method for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over IP is supported by sending an SCCRQ and waiting for a response, but this could be problematic during periods of packet loss between L2TP nodes.
L2TPv3を介してPPPをトンネリングし、利用できない場合にのみL2TPv2にフォールバックしたい場合は、自動フォールバックを備えたUDPを介したL2TPv3（セクション4.7.3を参照）を使用する必要があります。 L2TPv3 over IPからL2TPv2またはUDPを介したL2TPv3への自動フォールバックの決定的な方法はありません。 L2TPv3 over IPがサポートされているかどうかは、SCCRQを送信して応答を待つことで推測できますが、L2TPノード間のパケット損失の期間中に問題が発生する可能性があります。
The format of the L2TPv3 over UDP header is defined in Section 4.1.2.1.
L2TPv3 over UDPヘッダーのフォーマットは、セクション4.1.2.1で定義されています。
When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 and shares the first two octets of header format with L2TPv2. The Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets. If an implementation is capable of operating in L2TPv2 or L2TPv3 modes, it is possible to automatically detect whether a peer can support L2TPv2 or L2TPv3 and operate accordingly. The details of this fallback capability is defined in the following section.
UDPで動作する場合、L2TPv3はL2TPv2と同じポート（1701）を使用し、ヘッダー形式の最初の2オクテットをL2TPv2と共有します。 Verフィールドは、L2TPv2パケットとL2TPv3パケットを区別するために使用されます。実装がL2TPv2またはL2TPv3モードで動作できる場合、ピアがL2TPv2またはL2TPv3をサポートし、それに応じて動作できるかどうかを自動的に検出できます。このフォールバック機能の詳細は、次のセクションで定義されています。
When running over UDP, an implementation may detect whether a peer is L2TPv3-capable by sending a special SCCRQ that is properly formatted for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ with its Ver field set to 2 (for L2TPv2), and ensuring that any L2TPv3-specific AVPs (i.e., AVPs present within this document and not defined within RFC 2661) in the message are sent with each M bit set to 0, and that all L2TPv2 AVPs are present as they would be for L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3, the value contained in the space of the control message header utilized by the 32-bit Control Connection ID in L2TPv3, and the 16- bit Tunnel ID and 16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This effectively hides the fact that there are a pair of 16-bit fields in L2TPv2, and a single 32-bit field in L2TPv3.
UDPで実行する場合、実装は、L2TPv2とL2TPv3の両方に対して適切にフォーマットされた特別なSCCRQを送信することにより、ピアがL2TPv3対応かどうかを検出できます。これは、Verフィールドを2（L2TPv2の場合）に設定してSCCRQを送信し、メッセージ内のL2TPv3固有のAVP（つまり、このドキュメント内に存在し、RFC 2661内で定義されていない）が各Mとともに送信されるようにすることで実現されます。ビットが0に設定され、すべてのL2TPv2 AVPがL2TPv2の場合と同様に存在する。これは、L2TPv2のみの実装でL2TPv3 AVPが無視されるようにするために行われます。 L2TPv2とL2TPv3の両方で、L2TPv3の32ビットのコントロール接続ID、およびL2TPv2の16ビットのトンネルIDと16ビットのセッションIDが使用するコントロールメッセージヘッダーのスペースに含まれる値は常にSCCRQの場合は0。これにより、L2TPv2には16ビットのフィールドのペアが1つあり、L2TPv3には32ビットのフィールドが1つあるという事実が事実上隠されます。
If the peer implementation is L2TPv3-capable, a control message with the Ver field set to 3 and an L2TPv3 header and message format will be sent in response to the SCCRQ. Operation may then continue as L2TPv3. If a message is received with the Ver field set to 2, it must be assumed that the peer implementation is L2TPv2-only, thus enabling fallback to L2TPv2 mode to safely occur.
ピアの実装がL2TPv3対応の場合、Verフィールドが3に設定された制御メッセージとL2TPv3ヘッダーおよびメッセージフォーマットがSCCRQへの応答として送信されます。その後、操作はL2TPv3として続行できます。 Verフィールドを2に設定してメッセージを受信した場合、ピアの実装はL2TPv2のみであり、L2TPv2モードへのフォールバックが安全に行われるようにする必要があります。
Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 implementations over UDP be liberal in accepting an SCCRQ control message with the Ver field set to 2 or 3 and the presence of L2TPv2- specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 AVPs (e.g., those defined in RFC 2661 and not in this document) within an SCCRQ with the Ver field set to 2 (even if the M bit is set on the L2TPv2-specific AVPs).
注：L2TPv2 / v3自動検出モードでは、Verフィールドが2または3に設定され、L2TPv2固有のAVPが存在するSCCRQ制御メッセージを受け入れる際に、UDP上のすべてのL2TPv3実装が自由になる必要があります。 L2TPv3のみの実装では、Verフィールドが2に設定されたSCCRQ内のすべてのL2TPv2 AVP（たとえば、RFC 2661で定義され、このドキュメントでは定義されていないもの）を無視する必要があります（L2TPv2固有のAVPでMビットが設定されている場合でも）。
To maximize extensibility while permitting interoperability, a uniform method for encoding message types is used throughout L2TP. This encoding will be termed AVP (Attribute Value Pair) for the remainder of this document.
相互運用性を確保しながら拡張性を最大化するために、メッセージタイプをエンコードするための統一された方法がL2TP全体で使用されます。このドキュメントの残りの部分では、このエンコーディングをAVP（属性値ペア）と呼びます。
Each AVP is encoded as follows:
各AVPは次のようにエンコードされます。
Figure 5.1: AVP Format
図5.1：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 | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits comprise a bit mask that describes the general attributes of the AVP. Two bits are defined in this document; the remaining bits are reserved for future extensions. Reserved bits MUST be set to 0 when sent and ignored upon receipt.
最初の6ビットは、AVPの一般的な属性を説明するビットマスクで構成されます。このドキュメントでは2ビットが定義されています。残りのビットは将来の拡張のために予約されています。予約ビットは送信時に0に設定し、受信時に無視する必要があります。
Mandatory (M) bit: Controls the behavior required of an implementation that receives an unrecognized AVP. The M bit of a given AVP MUST only be inspected and acted upon if the AVP is unrecognized (see Section 5.2).
必須（M）ビット：認識されないAVPを受信する実装に必要な動作を制御します。与えられたAVPのMビットは、AVPが認識されない場合にのみ検査および実行されなければなりません（セクション5.2を参照）。
Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP. Section 5.3 describes the procedure for performing AVP hiding.
非表示（H）ビット：AVPの属性値フィールドのデータの非表示を識別します。この機能を使用すると、ユーザーパスワードなどの機密データがAVPのクリアテキストとして渡されるのを回避できます。セクション5.3では、AVP非表示を実行する手順について説明します。
Length: Contains the number of octets (including the Overall Length and bit mask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets.
長さ：このAVPに含まれるオクテットの数（全長とビットマスクフィールドを含む）が含まれます。長さは、6 +オクテットの属性値フィールドの長さとして計算できます。
The field itself is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. The minimum Length of an AVP is 6. If the Length is 6, then the Attribute Value field is absent.
フィールド自体は10ビットであり、1つのAVPで最大1023オクテットのデータを許可します。 AVPの最小長は6です。長さが6の場合、属性値フィールドはありません。
Vendor ID: The IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC1700] value. The value 0, corresponding to IETF-adopted attribute values, is used for all AVPs defined within this document. Any vendor wishing to implement its own L2TP extensions can use its own Vendor ID along with private Attribute values, guaranteeing that they will not collide with any other vendor's extensions or future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this feature to the first 65,535 enterprises.
ベンダーID：IANAが割り当てた「SMIネットワーク管理プライベートエンタープライズコード」[RFC1700]の値。 IETF採用の属性値に対応する値0は、このドキュメントで定義されているすべてのAVPに使用されます。独自のL2TP拡張機能を実装したいベンダーは、プライベート属性値とともに独自のベンダーIDを使用して、他のベンダーの拡張機能や将来のIETF拡張機能と衝突しないことを保証できます。ベンダーIDには16ビットが割り当てられているため、この機能は最初の65,535の企業に限定されています。
Attribute Type: A 2-octet value with a unique interpretation across all AVPs defined under a given Vendor ID.
属性タイプ：特定のベンダーIDで定義されたすべてのAVPにわたって一意の解釈を持つ2オクテット値。
Attribute Value: This is the actual value as indicated by the Vendor ID and Attribute Type. It follows immediately after the Attribute Type field and runs for the remaining octets indicated in the Length (i.e., Length minus 6 octets of header). This field is absent if the Length is 6.
属性値：これは、ベンダーIDと属性タイプによって示される実際の値です。 Attribute Typeフィールドの直後に続き、Lengthに示されている残りのオクテット（つまり、Lengthから6オクテットのヘッダーを引いたもの）に対して実行されます。長さが6の場合、このフィールドはありません。
In the event that the 16-bit Vendor ID space is exhausted, vendor-specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the following manner:
16ビットのベンダーIDスペースが使い果たされた場合、32ビットのベンダーIDを持つベンダー固有のAVPは、次の方法でカプセル化する必要があります。
Figure 5.2: Extended Vendor ID AVP Format
図5.2：拡張ベンダーID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 58 | 32-bit Vendor ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space within the Attribute Value field. Multiple AVPs of this type may exist in any message. The 16-bit Vendor ID MUST be 0, indicating that this is an IETF-defined AVP, and the Attribute Type MUST be 58, indicating that what follows is a vendor-specific AVP with a 32-bit Vendor ID code. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP MUST be set to 0. The Length of the AVP is 12 plus the length of the Attribute Value.
このAVPは、属性値フィールド内に32ビットのベンダーIDスペースを持つベンダー固有のAVPをエンコードします。このタイプの複数のAVPがメッセージに存在する場合があります。 16ビットのベンダーIDは0でなければならず（MUST）、これはIETFで定義されたAVPであることを示し、属性タイプは58でなければならず（MUST）、32ビットのベンダーIDコードを持つベンダー固有のAVPであることを示します。このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります。AVPの長さは12に属性値の長さを加えたものです。
If the M bit is set on an AVP that is unrecognized by its recipient, the session or control connection associated with the control message containing the AVP MUST be shut down. If the control message containing the unrecognized AVP is associated with a session (e.g., an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a CDN with a Result Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut down. If the control message containing the unrecognized AVP is associated with establishment or maintenance of a Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the associated Control Connection MUST be issued a StopCCN with Result Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut down. If the M bit is not set on an unrecognized AVP, the AVP MUST be ignored when received, processing the control message as if the AVP were not present.
Mビットが受信者に認識されないAVPに設定されている場合、AVPを含む制御メッセージに関連付けられているセッションまたは制御接続をシャットダウンする必要があります。認識されないAVPを含む制御メッセージがセッション（たとえば、ICRQ、ICRP、ICCN、SLIなど）に関連付けられている場合、そのセッションには、結果コード2およびエラーコード8（セクション5.4.2で定義されています）、シャットダウンします。認識されないAVPを含む制御メッセージが制御接続の確立または保守（SCCRQ、SCCRP、SCCCN、Helloなど）に関連付けられている場合、関連付けられた制御接続は、結果コード2およびエラーコード8のStopCCNを発行する必要があります。 （5.4.2項で定義）、シャットダウンします。 Mビットが認識されないAVPで設定されていない場合、AVPは受信時に無視され、AVPが存在しないかのように制御メッセージを処理する必要があります。
Receipt of an unrecognized AVP that has the M bit set is catastrophic to the session or control connection with which it is associated. Thus, the M bit should only be set for AVPs that are deemed crucial to proper operation of the session or control connection by the sender. AVPs that are considered crucial by the sender may vary by application and configured options. In no case shall a receiver of an AVP "validate" if the M bit is set on a recognized AVP. If the AVP is recognized (as all AVPs defined in this document MUST be for a compliant L2TPv3 specification), then by definition, the M bit is of no consequence.
Mビットが設定された認識されないAVPを受信すると、それが関連付けられているセッションまたは制御接続にとって致命的です。したがって、Mビットは、セッションの適切な操作または送信者による接続の制御に不可欠と見なされるAVPに対してのみ設定する必要があります。送信者によって重要と見なされるAVPは、アプリケーションおよび構成されたオプションによって異なる場合があります。認識されたAVPにMビットが設定されている場合、AVPの受信者は「検証」しないでください。 AVPが認識されている場合（このドキュメントで定義されているすべてのAVPは、準拠するL2TPv3仕様でなければならないため）、定義により、Mビットは重要ではありません。
The sender of an AVP is free to set its M bit to 1 or 0 based on whether the configured application strictly requires the value contained in the AVP to be recognized or not. For example, "Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and desired, and 1 if not.
AVPの送信者は、構成されたアプリケーションがAVPに含まれている値の認識を厳密に要求するかどうかに基づいて、Mビットを1または0に自由に設定できます。たとえば、4.7.3項の「自動L2TPv2フォールバック」では、L2TPv2へのフォールバックがサポートされ、必要な場合はすべての新しいL2TPv3 AVPのMビットを0に設定し、そうでない場合は1に設定する必要があります。
The M bit is useful as extra assurance for support of critical AVP extensions. However, more explicit methods may be available to determine support for a given feature rather than using the M bit alone. For example, if a new AVP is defined in a message for which there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP message), rather than simply sending an AVP in the message with the M bit set, availability of the extension may be identified by sending an AVP in the request message and expecting a corresponding AVP in a reply message. This more explicit method, when possible, is preferred.
Mビットは、重要なAVP拡張機能のサポートの追加保証として役立ちます。ただし、Mビットのみを使用するのではなく、特定の機能のサポートを決定するために、より明示的な方法を使用できる場合があります。たとえば、Mビットが設定されたメッセージでAVPを単に送信するのではなく、常にメッセージ応答があるメッセージ（つまり、ICRQ、ICRP、SCCRQ、またはSCCRPメッセージ）に新しいAVPが定義されている場合、拡張機能の可用性は、要求メッセージでAVPを送信し、応答メッセージで対応するAVPを期待することで識別できます。可能であれば、このより明示的な方法が推奨されます。
The M bit also plays a role in determining whether or not a malformed or out-of-range value within an AVP should be ignored or should result in termination of a session or control connection (see Section 7.1 for more details).
Mビットは、AVP内の不正な値または範囲外の値を無視するか、セッションまたは制御接続を終了する必要があるかどうかを決定する役割も果たします（詳細については、セクション7.1を参照）。
The H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden or present in cleartext. This feature can be used to hide sensitive control message data such as user passwords, IDs, or other vital information.
各AVPのヘッダーのHビットは、AVPのコンテンツが非表示であるかクリアテキストで存在するかを受信ピアに示すメカニズムを提供します。この機能を使用して、ユーザーパスワード、ID、その他の重要な情報などの機密性の高い制御メッセージデータを非表示にすることができます。
The H bit MUST only be set if (1) a shared secret exists between the LCCEs and (2) Control Message Authentication is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a given control message, at least one Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1.
Hビットは、（1）LCCE間に共有秘密が存在し、かつ（2）制御メッセージ認証が有効になっている場合にのみ設定する必要があります（セクション4.3を参照）。 Hビットが特定の制御メッセージのAVPに設定されている場合、少なくとも1つのランダムベクトルAVPもメッセージに存在し、Hビットが1の最初のAVPの前になければなりません（MUST）。
The shared secret between LCCEs is used to derive a unique shared key for hiding and unhiding calculations. The derived shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with the key consisting of the shared secret, and with the data being hashed consisting of a single octet containing the value 1.
LCCE間の共有秘密は、計算を非表示および再表示するための一意の共有キーを導出するために使用されます。派生共有キーは、HMAC-MD5キー付きハッシュ[RFC2104]を介して取得されます。キーは共有シークレットで構成され、ハッシュされるデータは、値1を含む単一オクテットで構成されます。
shared_key = HMAC_MD5 (shared_secret, 1)
shared_key = HMAC_MD5（shared_secret、1）
Hiding an AVP value is done in several steps. The first step is to take the length and value fields of the original (cleartext) AVP and encode them into the Hidden AVP Subformat, which appears as follows:
AVP値の非表示は、いくつかのステップで実行されます。最初のステップは、元の（クリアテキスト）AVPの長さと値のフィールドを取得し、次のように非表示のAVPサブフォーマットにエンコードすることです。
Figure 5.3: Hidden AVP Subformat
図5.3：非表示の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value: This is length of the Original Attribute Value to be obscured in octets. This is necessary to determine the original length of the Attribute Value that is lost when the additional Padding is added.
元の属性値の長さ：これは、オクテットで隠される元の属性値の長さです。これは、追加のパディングが追加されたときに失われる属性値の元の長さを決定するために必要です。
Original Attribute Value: Attribute Value that is to be obscured.
元の属性値：隠される属性値。
Padding: Random additional octets used to obscure length of the Attribute Value that is being hidden.
パディング：非表示になっている属性値の長さを隠すために使用されるランダムな追加オクテット。
To mask the size of the data being hidden, the resulting subformat MAY be padded as shown above. Padding does NOT alter the value placed in the Length of Original Attribute Value field, but does alter the length of the resultant AVP that is being created. For example, if an Attribute Value to be hidden is 4 octets in length, the unhidden AVP length would be 10 octets (6 + Attribute Value length). After hiding, the length of the AVP would become 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. Thus, if Padding is 12 octets, the AVP length would be 6 + 4 + 2 + 12 = 24 octets.
非表示にされるデータのサイズをマスクするために、結果のサブフォーマットは上記のようにパディングされる場合があります。パディングは、「元の属性値の長さ」フィールドに配置された値を変更しませんが、作成される結果のAVPの長さを変更します。たとえば、非表示にする属性値の長さが4オクテットの場合、非表示でないAVPの長さは10オクテット（6 +属性値の長さ）になります。非表示の後、AVPの長さは6 +属性値の長さ+元の属性値の長さフィールドのサイズ+パディングになります。したがって、パディングが12オクテットの場合、AVPの長さは6 + 4 + 2 + 12 = 24オクテットになります。
Next, an MD5 [RFC1321] hash is performed (in network byte order) on the concatenation of the following:
次に、次の連結に対してMD5 [RFC1321]ハッシュが（ネットワークバイト順で）実行されます。
+ the 2-octet Attribute number of the AVP + the shared key + an arbitrary length random vector
+ AVPの2オクテットの属性番号+共有キー+任意の長さのランダムベクトル
The value of the random vector used in this hash is passed in the value field of a Random Vector AVP. This Random Vector AVP must be placed in the message by the sender before any hidden AVPs. The same random vector may be used for more than one hidden AVP in the same message, but not for hiding two or more instances of an AVP with the same Attribute Type unless the Attribute Values in the two AVPs are also identical. When a different random vector is used for the hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in the control message before the first AVP to which it applies.
このハッシュで使用されるランダムベクトルの値は、ランダムベクトルAVPの値フィールドに渡されます。このランダムベクトルAVPは、非表示のAVPの前に送信者がメッセージに配置する必要があります。同じランダムベクトルを同じメッセージの複数の非表示AVPに使用できますが、2つのAVPの属性値が同じでない限り、同じ属性タイプのAVPの複数のインスタンスを非表示にすることはできません。異なるランダムベクトルが後続のAVPの非表示に使用される場合、新しいランダムベクトルAVPは、それが適用される最初のAVPの前に制御メッセージに配置される必要があります。
The MD5 hash value is then XORed with the first 16-octet (or less) segment of the Hidden AVP Subformat and placed in the Attribute Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, the Subformat is transformed as if the Attribute Value field had been padded to 16 octets before the XOR. Only the actual octets present in the Subformat are modified, and the length of the AVP is not altered.
次に、MD5ハッシュ値は、非表示AVPサブフォーマットの最初の16オクテット（またはそれ以下）セグメントとXORされ、非表示AVPの属性値フィールドに配置されます。非表示のAVPサブフォーマットが16オクテット未満の場合、サブフォーマットは、属性値フィールドがXORの前に16オクテットにパディングされたかのように変換されます。サブフォーマットに存在する実際のオクテットのみが変更され、AVPの長さは変更されません。
If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared key followed by the result of the first XOR. That hash is XORed with the second 16-octet (or less) segment of the Subformat and placed in the corresponding octets of the Value field of the Hidden AVP.
サブフォーマットが16オクテットより長い場合、共有キーとそれに続く最初のXORの結果で構成されるオクテットのストリームに対して、2番目の一方向MD5ハッシュが計算されます。そのハッシュは、サブフォーマットの2番目の16オクテット（またはそれ以下）セグメントとXORされ、非表示AVPの値フィールドの対応するオクテットに配置されます。
If necessary, this operation is repeated, with the shared key used along with each XOR result to generate the next hash to XOR the next segment of the value with.
必要に応じて、この操作が繰り返され、共有キーが各XOR結果とともに使用されて、次のハッシュを生成して値の次のセグメントをXORします。
The hiding method was adapted from [RFC2865], which was taken from the "Mixing in the Plaintext" section in the book "Network Security" by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of the method follows:
隠蔽方法は、Kaufman、Perlman、Speciner [KPS]の著書「Network Security」の「Mixing in the Plaintext」セクションから引用された[RFC2865]から採用されました。メソッドの詳細な説明は次のとおりです。
Call the shared key S, the Random Vector RV, and the Attribute Type A. Break the value field into 16-octet chunks p_1, p_2, etc., with the last one padded at the end with random data to a 16-octet boundary. Call the ciphertext blocks c_1, c_2, etc. We will also define intermediate values b_1, b_2, etc.
共有キーS、ランダムベクトルRV、および属性タイプAを呼び出します。値フィールドを16オクテットのチャンクp_1、p_2などに分割します。最後のチャンクには、16オクテットの境界までランダムデータが最後に埋め込まれます。 。暗号文ブロックc_1、c_2などを呼び出します。中間値b_1、b_2なども定義します。
b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1
b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2
. .
. .
. .
b_i = MD5 (S + c_i-1) c_i = p_i xor b_i
The String will contain c_1 + c_2 +...+ c_i, where "+" denotes concatenation.
文字列にはc_1 + c_2 + ... + c_iが含まれます。「+」は連結を示します。
On receipt, the random vector is taken from the last Random Vector AVP encountered in the message prior to the AVP to be unhidden. The above process is then reversed to yield the original value.
受信すると、ランダムベクトルは、AVPが表示される前に、メッセージで遭遇した最後のランダムベクトルAVPから取得されます。次に、上記のプロセスを逆にして元の値を取得します。
The following sections contain a list of all L2TP AVPs defined in this document.
次のセクションには、このドキュメントで定義されているすべてのL2TP AVPのリストが含まれています。
Following the name of the AVP is a list indicating the message types that utilize each AVP. After each AVP title follows a short description of the purpose of the AVP, a detail (including a graphic) of the format for the Attribute Value, and any additional information needed for proper use of the AVP.
AVPの名前の後には、各AVPを利用するメッセージタイプを示すリストがあります。各AVPタイトルの後に、AVPの目的の簡単な説明、属性値の形式の詳細（グラフィックを含む）、およびAVPの適切な使用に必要な追加情報が続きます。
Message Type (All Messages)
メッセージタイプ（すべてのメッセージ）
The Message Type AVP, Attribute Type 0, identifies the control message herein and defines the context in which the exact meaning of the following AVPs will be determined.
メッセージタイプAVP、属性タイプ0は、ここで制御メッセージを識別し、次のAVPの正確な意味が決定されるコンテキストを定義します。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type is a 2-octet unsigned integer.
メッセージタイプは2オクテットの符号なし整数です。
The Message Type AVP MUST be the first AVP in a message, immediately following the control message header (defined in Section 3.2.1). See Section 3.1 for the list of defined control message types and their identifiers.
メッセージタイプAVPは、メッセージの最初のAVPである必要があり、制御メッセージヘッダー（セクション3.2.1で定義）の直後に続きます。定義されている制御メッセージタイプとその識別子のリストについては、セクション3.1を参照してください。
The Mandatory (M) bit within the Message Type AVP has special meaning. Rather than an indication as to whether the AVP itself should be ignored if not recognized, it is an indication as to whether the control message itself should be ignored. If the M bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the control connection MUST be cleared. If the M bit is not set, then the implementation may ignore an unknown message type. The M bit MUST be set to 1 for all message types defined in this document. This AVP MUST NOT be hidden (the H bit MUST be 0). The Length of this AVP is 8.
メッセージタイプAVP内の必須（M）ビットには特別な意味があります。認識されない場合にAVP自体を無視する必要があるかどうかを示すのではなく、制御メッセージ自体を無視する必要があるかどうかを示します。 MビットがメッセージタイプAVP内で設定されており、メッセージタイプが実装に対して不明である場合、制御接続をクリアする必要があります。 Mビットが設定されていない場合、実装は不明なメッセージタイプを無視する可能性があります。このドキュメントで定義されているすべてのメッセージタイプについて、Mビットを1に設定する必要があります。このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPの長さは8です。
A vendor-specific control message may be defined by setting the Vendor ID of the Message Type AVP to a value other than the IETF Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be the first AVP in the control message.
ベンダー固有の制御メッセージは、メッセージタイプAVPのベンダーIDをIETFベンダーID 0以外の値に設定することで定義できます（セクション5.1を参照）。メッセージタイプAVPは、制御メッセージの最初のAVPである必要があります。
Message Digest (All Messages)
メッセージダイジェスト（すべてのメッセージ）
The Message Digest AVP, Attribute Type 59 is used as an integrity and authentication check of the L2TP Control Message header and body.
メッセージダイジェストAVP、属性タイプ59は、L2TP制御メッセージのヘッダーと本文の整合性と認証チェックとして使用されます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 or 20 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Digest Type is a one-octet integer indicating the Digest calculation algorithm:
ダイジェストタイプは、ダイジェスト計算アルゴリズムを示す1オクテットの整数です。
0 HMAC-MD5 [RFC2104] 1 HMAC-SHA-1 [RFC2104]
0 HMAC-MD5 [RFC2104] 1 HMAC-SHA-1 [RFC2104]
Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1 (HMAC-SHA-1) SHOULD be supported.
ダイジェストタイプ0（HMAC-MD5）をサポートする必要がありますが、ダイジェストタイプ1（HMAC-SHA-1）はサポートする必要があります（SHOULD）。
The Message Digest is of variable length and contains the result of the control message authentication and integrity calculation. For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16 bytes. For Digest Type 1 (HMAC-SHA-1) the length of the digest MUST be 20 bytes.
メッセージダイジェストは可変長であり、制御メッセージの認証と整合性の計算の結果が含まれます。ダイジェストタイプ0（HMAC-MD5）の場合、ダイジェストの長さは16バイトにする必要があります。ダイジェストタイプ1（HMAC-SHA-1）の場合、ダイジェストの長さは20バイトである必要があります。
If Control Message Authentication is enabled, at least one Message Digest AVP MUST be present in all messages and MUST be placed immediately after the Message Type AVP. This forces the Message Digest AVP to begin at a well-known and fixed offset. A second Message Digest AVP MAY be present in a message and MUST be placed directly after the first Message Digest AVP.
制御メッセージ認証が有効な場合、少なくとも1つのメッセージダイジェストAVPがすべてのメッセージに存在しなければならず、メッセージタイプAVPの直後に配置されなければなりません（MUST）。これにより、メッセージダイジェストAVPは既知の固定オフセットから開始されます。 2番目のメッセージダイジェストAVPがメッセージ内に存在する場合があり、最初のメッセージダイジェストAVPの直後に配置する必要があります。
The shared secret between LCCEs is used to derive a unique shared key for Control Message Authentication calculations. The derived shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with the key consisting of the shared secret, and with the data being hashed consisting of a single octet containing the value 2.
LCCE間の共有秘密は、制御メッセージ認証計算のための一意の共有鍵を導出するために使用されます。派生共有キーは、HMAC-MD5キー付きハッシュ[RFC2104]を介して取得されます。キーは共有シークレットで構成され、ハッシュされるデータは、値2を含む単一オクテットで構成されます。
shared_key = HMAC_MD5 (shared_secret, 2)
shared_key = HMAC_MD5（shared_secret、2）
Calculation of the Message Digest is as follows for all messages other than the SCCRQ (where "+" refers to concatenation):
メッセージダイジェストの計算は、SCCRQ以外のすべてのメッセージに対して次のようになります（「+」は連結を指します）。
Message Digest = HMAC_Hash (shared_key, local_nonce + remote_nonce + control_message)
メッセージダイジェスト= HMAC_Hash（shared_key、local_nonce + remote_nonce + control_message）
HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type (MD5 or SHA1)
HMAC_Hash：ダイジェストタイプ（MD5またはSHA1）で識別されるHMACハッシュアルゴリズム
local_nonce: Nonce chosen locally and advertised to the remote LCCE.
local_nonce：ローカルで選択され、リモートLCCEにアドバタイズされるノンス。
remote_nonce: Nonce received from the remote LCCE
remote_nonce：リモートLCCEから受信したnonce
(The local_nonce and remote_nonce are advertised via the Control Message Authentication Nonce AVP, also defined in this section.)
（local_nonceとremote_nonceは、このセクションでも定義されている制御メッセージ認証ノンスAVPを介して通知されます。）
shared_key: Derived shared key for this control connection
shared_key：この制御接続の派生共有キー
control_message: The entire contents of the L2TP control message, including the control message header and all AVPs. Note that the control message header in this case begins after the all-zero Session ID when running over IP (see Section 4.1.1.2), and after the UDP header when running over UDP (see Section 4.1.2.1).
control_message：制御メッセージヘッダーとすべてのAVPを含む、L2TP制御メッセージの内容全体。この場合の制御メッセージヘッダーは、IPを介して実行する場合はすべてゼロのセッションIDの後に始まり（セクション4.1.1.2を参照）、UDPを介して実行する場合はUDPヘッダーの後に始まります（セクション4.1.2.1を参照）。
When calculating the Message Digest, the Message Digest AVP MUST be present within the control message with the Digest Type set to its proper value, but the Message Digest itself set to zeros.
メッセージダイジェストを計算するとき、メッセージダイジェストAVPは、ダイジェストタイプを適切な値に設定して、コントロールメッセージ内に存在する必要がありますが、メッセージダイジェスト自体はゼロに設定されています。
When receiving a control message, the contents of the Message Digest AVP MUST be compared against the expected digest value based on local calculation. This is done by performing the same digest calculation above, with the local_nonce and remote_nonce reversed. This message authenticity and integrity checking MUST be performed before utilizing any information contained within the control message. If the calculation fails, the message MUST be dropped.
制御メッセージを受信するとき、メッセージダイジェストAVPのコンテンツは、ローカル計算に基づいて予想されるダイジェスト値と比較する必要があります。これは、local_nonceとremote_nonceを逆にして、上記と同じダイジェスト計算を実行することによって行われます。このメッセージの信頼性と整合性のチェックは、制御メッセージに含まれる情報を利用する前に実行する必要があります。計算が失敗した場合は、メッセージをドロップする必要があります。
The SCCRQ has special treatment as it is the initial message commencing a new control connection. As such, there is only one nonce available. Since the nonce is present within the message itself as part of the Control Message Authentication Nonce AVP, there is no need to use it in the calculation explicitly. Calculation of the SCCRQ Message Digest is performed as follows:
SCCRQは新しい制御接続を開始する最初のメッセージであるため、特別な扱いがあります。そのため、利用できるnonceは1つだけです。 nonceは、制御メッセージ認証ノンスAVPの一部としてメッセージ自体に存在するため、計算で明示的に使用する必要はありません。 SCCRQメッセージダイジェストの計算は、次のように実行されます。
Message Digest = HMAC_Hash (shared_key, control_message)
メッセージダイジェスト= HMAC_Hash（shared_key、control_message）
To allow for graceful switchover to a new shared secret or hash algorithm, two Message Digest AVPs MAY be present in a control message, and two shared secrets MAY be configured for a given LCCE. If two Message Digest AVPs are received in a control message, the message MUST be accepted if either Message Digest is valid. If two shared secrets are configured, each (separately) MUST be used for calculating a digest to be compared to the Message Digest(s) received. When calculating a digest for a control message, the Value field for both of the Message Digest AVPs MUST be set to zero.
新しい共有シークレットまたはハッシュアルゴリズムへの適切なスイッチオーバーを可能にするために、2つのメッセージダイジェストAVPが制御メッセージに存在する場合があり、2つの共有シークレットが特定のLCCEに構成される場合があります。制御メッセージで2つのメッセージダイジェストAVPが受信された場合、いずれかのメッセージダイジェストが有効であれば、メッセージを受け入れる必要があります。 2つの共有シークレットが構成されている場合、受信したメッセージダイジェストと比較するダイジェストを計算するために、それぞれ個別に使用する必要があります。制御メッセージのダイジェストを計算するときは、両方のメッセージダイジェストAVPの値フィールドをゼロに設定する必要があります。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type 2 (HMAC-SHA-1).
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。長さは、ダイジェストタイプ1（HMAC-MD5）の場合は23、ダイジェストタイプ2（HMAC-SHA-1）の場合は27です。
Control Message Authentication Nonce (SCCRQ, SCCRP)
制御メッセージ認証ノンス（SCCRQ、SCCRP）
The Control Message Authentication Nonce AVP, Attribute Type 73, MUST contain a cryptographically random value [RFC1750]. This value is used for Control Message Authentication.
コントロールメッセージ認証ノンスAVP、属性タイプ73は、暗号的にランダムな値[RFC1750]を含んでいる必要があります。この値は、制御メッセージ認証に使用されます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce is of arbitrary length, though at least 16 octets is
recommended. The Nonce contains the random value for use in the
Control Message Authentication hash calculation (see Message
Digest AVP definition in this section).
If Control Message Authentication is enabled, this AVP MUST be present in the SCCRQ and SCCRP messages.
制御メッセージ認証が有効な場合、このAVPはSCCRQおよびSCCRPメッセージに存在する必要があります。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 6 plus the length of the Nonce.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは6にノンスの長さを加えたものです。
Random Vector (All Messages)
ランダムベクトル（すべてのメッセージ）
The Random Vector AVP, Attribute Type 36, MUST contain a cryptographically random value [RFC1750]. This value is used for AVP Hiding.
ランダムベクトルAVP、属性タイプ36は、暗号的にランダムな値[RFC1750]を含んでいる必要があります。この値はAVP非表示に使用されます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String is of arbitrary length, though at least 16 octets is recommended. The string contains the random vector for use in computing the MD5 hash to retrieve or hide the Attribute Value of a hidden AVP (see Section 5.3).
ランダムオクテット文字列は任意の長さですが、少なくとも16オクテットが推奨されます。文字列には、MD5ハッシュを計算して非表示のAVPの属性値を取得または非表示にするために使用するランダムベクトルが含まれます（セクション5.3を参照）。
More than one Random Vector AVP may appear in a message, in which case a hidden AVP uses the Random Vector AVP most closely preceding it. As such, at least one Random Vector AVP MUST precede the first AVP with the H bit set.
メッセージに複数のランダムベクトルAVPが表示される場合があります。その場合、非表示のAVPは、直前のランダムベクトルAVPを使用します。そのため、少なくとも1つのランダムベクトルAVPは、Hビットが設定された最初のAVPの前になければなりません（MUST）。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 6 plus the length of the Random Octet String.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは6にランダムオクテットストリングの長さを加えたものです。
Result Code (StopCCN, CDN)
結果コード（StopCCN、CDN）
The Result Code AVP, Attribute Type 1, indicates the reason for terminating the control connection or session.
結果コードAVP、属性タイプ1は、制御接続またはセッションを終了する理由を示します。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message ... (optional, arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code is a 2-octet unsigned integer. The optional Error Code is a 2-octet unsigned integer. An optional Error Message can follow the Error Code field. Presence of the Error Code and Message is indicated by the AVP Length field. The Error Message contains an arbitrary string providing further (human-readable) text associated with the condition. Human-readable text in all error messages MUST be provided in the UTF-8 charset [RFC3629] using the Default Language [RFC2277].
結果コードは2オクテットの符号なし整数です。オプションのエラーコードは、2オクテットの符号なし整数です。オプションのエラーメッセージは、エラーコードフィールドの後に続きます。エラーコードとメッセージの存在は、AVP長さフィールドで示されます。エラーメッセージには、条件に関連付けられた追加の（人間が読める）テキストを提供する任意の文字列が含まれます。すべてのエラーメッセージ内の人間が読めるテキストは、デフォルト言語[RFC2277]を使用してUTF-8文字セット[RFC3629]で提供する必要があります。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length is 8 if there is no Error Code or Message, 10 if there is an Error Code and no Error Message, or 10 plus the length of the Error Message if there is an Error Code and Message.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。長さは、エラーコードまたはメッセージがない場合は8、エラーコードおよびエラーメッセージがない場合は10、エラーコードおよびメッセージがある場合は10にエラーメッセージの長さを加えたものです。
Defined Result Code values for the StopCCN message are as follows:
StopCCNメッセージに定義されている結果コードの値は次のとおりです。
0 - Reserved. 1 - General request to clear control connection. 2 - General error, Error Code indicates the problem. 3 - Control connection already exists. 4 - Requester is not authorized to establish a control connection. 5 - The protocol version of the requester is not supported, Error Code indicates highest version supported. 6 - Requester is being shut down. 7 - Finite state machine error or timeout
0-予約済み。 1-制御接続をクリアするための一般的な要求。 2-一般的なエラー。エラーコードは問題を示します。 3-制御接続はすでに存在しています。 4-リクエスターは制御接続を確立することを許可されていません。 5-リクエスタのプロトコルバージョンはサポートされていません。エラーコードは、サポートされている最も高いバージョンを示しています。 6-リクエスターはシャットダウンされています。 7-有限状態マシンエラーまたはタイムアウト
General Result Code values for the CDN message are as follows:
CDNメッセージの一般的な結果コードの値は次のとおりです。
0 - Reserved. 1 - Session disconnected due to loss of carrier or circuit disconnect. 2 - Session disconnected for the reason indicated in Error Code. 3 - Session disconnected for administrative reasons. 4 - Session establishment failed due to lack of appropriate facilities being available (temporary condition).
0-予約済み。 1-キャリアの損失または回線の切断により、セッションが切断されました。 2-エラーコードに示された理由により、セッションが切断されました。 3-管理上の理由でセッションが切断されました。 4-適切な設備が利用できないため（一時的な状態）、セッションの確立に失敗しました。
5 - Session establishment failed due to lack of appropriate facilities being available (permanent condition). 13 - Session not established due to losing tie breaker. 14 - Session not established due to unsupported PW type. 15 - Session not established, sequencing required without valid L2-Specific Sublayer. 16 - Finite state machine error or timeout.
5-適切な設備が利用できないため（永続的な状態）、セッションの確立に失敗しました。 13-タイブレーカーを失ったため、セッションが確立されませんでした。 14-サポートされていないPWタイプのため、セッションは確立されませんでした。 15-セッションが確立されていません。有効なL2固有のサブレイヤーなしでシーケンスが必要です。 16-有限状態マシンエラーまたはタイムアウト。
Additional service-specific Result Codes are defined outside this document.
追加のサービス固有の結果コードは、このドキュメントの外で定義されています。
The Error Codes defined below pertain to types of errors that are not specific to any particular L2TP request, but rather to protocol or message format errors. If an L2TP reply indicates in its Result Code that a General Error occurred, the General Error value should be examined to determine what the error was. The currently defined General Error codes and their meanings are as follows:
以下に定義するエラーコードは、特定のL2TP要求に固有ではなく、プロトコルまたはメッセージ形式のエラーに関連するエラーの種類に関連しています。 L2TP応答がその結果コードで一般エラーが発生したことを示している場合、一般エラー値を調べてエラーが何であったかを判別する必要があります。現在定義されている一般的なエラーコードとその意味は次のとおりです。
0 - No General Error. 1 - No control connection exists yet for this pair of LCCEs. 2 - Length is wrong. 3 - One of the field values was out of range. 4 - Insufficient resources to handle this operation now. 5 - Invalid Session ID. 6 - A generic vendor-specific error occurred. 7 - Try another. If initiator is aware of other possible responder destinations, it should try one of them. This can be used to guide an LAC or LNS based on policy. 8 - The session or control connection was shut down due to receipt of an unknown AVP with the M bit set (see Section 5.2). The Error Message SHOULD contain the attribute of the offending AVP in (human-readable) text form. 9 - Try another directed. If an LAC or LNS is aware of other possible destinations, it should inform the initiator of the control connection or session. The Error Message MUST contain a comma-separated list of addresses from which the initiator may choose. If the L2TP data channel runs over IPv4, then this would be a comma-separated list of IP addresses in the canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2, 192.0.2.3") in the UTF-8 charset [RFC3629] using the Default Language [RFC2277]. If there are no servers for the LAC or LNS to suggest, then Error Code 7 should be used. For IPv4, the delimiter between addresses MUST be precisely a single comma and a single space. For IPv6, each literal address MUST be enclosed in "[" and "]" characters, following the encoding described in [RFC2732].
0-一般エラーなし。 1-このLCCEのペアに対する制御接続はまだありません。 2-長さが間違っています。 3-フィールド値の1つが範囲外でした。 4-現在、この操作を処理するにはリソースが不足しています。 5-無効なセッションID。 6-一般的なベンダー固有のエラーが発生しました。 7-別を試してください。イニシエーターが他の可能なレスポンダー宛先を認識している場合、それらのいずれかを試行する必要があります。これは、ポリシーに基づいてLACまたはLNSをガイドするために使用できます。 8-Mビットが設定された不明なAVPを受信したため、セッションまたは制御接続がシャットダウンされました（セクション5.2を参照）。エラーメッセージには、問題のあるAVPの属性が（人間が読み取れる）テキスト形式で含まれている必要があります（SHOULD）。 9-別の監督を試してください。 LACまたはLNSが他の可能な宛先を認識している場合は、制御接続またはセッションの開始側に通知する必要があります。エラーメッセージには、イニシエーターが選択できるアドレスのコンマ区切りリストを含める必要があります。 L2TPデータチャネルがIPv4で実行されている場合、これは、UTF-8の正規のドット付き10進形式（たとえば、「192.0.2.1、192.0.2.2、192.0.2.3」）のIPアドレスのコンマ区切りリストになります。デフォルト言語[RFC2277]を使用した文字セット[RFC3629]。 LACまたはLNSが提案するサーバーがない場合は、エラーコード7を使用する必要があります。 IPv4の場合、アドレス間の区切り文字は、正確に単一のコンマと単一のスペースでなければなりません。 IPv6の場合、[RFC2732]で説明されているエンコーディングに従って、各リテラルアドレスを "["および "]"文字で囲む必要があります。
When a General Error Code of 6 is used, additional information about the error SHOULD be included in the Error Message field. A vendor-specific AVP MAY be sent to more precisely detail a vendor-specific problem.
一般エラーコード6を使用する場合、エラーに関する追加情報を[エラーメッセージ]フィールドに含める必要があります（SHOULD）。ベンダー固有のAVPを送信して、ベンダー固有の問題をより正確に詳細化できます。
Control Connection Tie Breaker (SCCRQ)
制御接続タイブレーカー（SCCRQ）
The Control Connection Tie Breaker AVP, Attribute Type 5, indicates that the sender desires a single control connection to exist between a given pair of LCCEs.
制御接続タイブレーカーAVP、属性タイプ5は、送信者がLCCEの特定のペア間に存在する単一の制御接続を望んでいることを示します。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Connection Tie Breaker Value is an 8-octet random value that is used to choose a single control connection when two LCCEs request a control connection concurrently. The recipient of a SCCRQ must check to see if a SCCRQ has been sent to the peer; if so, a tie has been detected. In this case, the LCCE must compare its Control Connection Tie Breaker value with the one received in the SCCRQ. The lower value "wins", and the "loser" MUST discard its control connection. A StopCCN SHOULD be sent by the winner as an explicit rejection for the losing SCCRQ. In the case in which a tie breaker is present on both sides and the value is equal, both sides MUST discard their control connections and restart control connection negotiation with a new, random tie breaker value.
制御接続タイブレーカー値は、2つのLCCEが制御接続を同時に要求したときに単一の制御接続を選択するために使用される8オクテットのランダムな値です。 SCCRQの受信者は、SCCRQがピアに送信されたかどうかを確認する必要があります。もしそうなら、同点が検出されました。この場合、LCCEはそのコントロール接続タイブレーカー値をSCCRQで受信した値と比較する必要があります。低い値は「勝ち」、そして「敗者」はその制御接続を破棄しなければなりません。勝者はStopCCNを送信して、負けたSCCRQを明示的に拒否する必要があります（SHOULD）。タイブレーカーが両側に存在し、値が等しい場合、両側は制御接続を破棄し、新しいランダムなタイブレーカー値で制御接続ネゴシエーションを再開する必要があります。
If a tie breaker is received and an outstanding SCCRQ has no tie breaker value, the initiator that included the Control Connection Tie Breaker AVP "wins". If neither side issues a tie breaker, then two separate control connections are opened.
タイブレーカーが受信され、未解決のSCCRQにタイブレーカー値がない場合、コントロール接続タイブレーカーAVPを含むイニシエーターが「勝ち」ます。どちらの側もタイブレーカーを発行しない場合、2つの個別の制御接続が開かれます。
Applications that employ a distinct and well-known initiator have no need for tie breaking, and MAY omit this AVP or disable tie breaking functionality. Applications that require tie breaking also require that an LCCE be uniquely identifiable upon receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via the Router ID AVP.
別個のよく知られているイニシエーターを採用するアプリケーションでは、タイブレイキングの必要はありません。このAVPを省略したり、タイブレイキング機能を無効にしたりできます。タイブレークを必要とするアプリケーションでは、SCCRQの受信時にLCCEが一意に識別可能であることも必要です。 L2TP over IPの場合、これはルーターID AVPを介して実行する必要があります。
Note that in [RFC2661], this AVP is referred to as the "Tie Breaker AVP" and is applicable only to a control connection. In L2TPv3, the AVP serves the same purpose of tie breaking, but is applicable to a control connection or a session. The Control Connection Tie Breaker AVP (present only in Control Connection messages) and Session Tie Breaker AVP (present only in Session messages), are described separately in this document, but share the same Attribute type of 5.
[RFC2661]では、このAVPは「タイブレーカーAVP」と呼ばれ、制御接続にのみ適用できることに注意してください。 L2TPv3では、AVPはタイブレイキングと同じ目的を果たしますが、制御接続またはセッションに適用できます。コントロール接続タイブレーカーAVP（コントロール接続メッセージにのみ存在）とセッションタイブレーカーAVP（セッションメッセージにのみ存在）は、このドキュメントでは個別に説明されていますが、同じ属性タイプ5を共有しています。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The length of this AVP is 14.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは14です。
Host Name (SCCRQ, SCCRP)
ホスト名（SCCRQ、SCCRP）
The Host Name AVP, Attribute Type 7, indicates the name of the issuing LAC or LNS, encoded in the US-ASCII charset.
ホスト名AVP、属性タイプ7は、US-ASCII文字セットでエンコードされた、発行LACまたはLNSの名前を示します。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name is of arbitrary length, but MUST be at least 1 octet.
ホスト名は任意の長さですが、少なくとも1オクテットでなければなりません。
This name should be as broadly unique as possible; for hosts participating in DNS [RFC1034], a host name with fully qualified domain would be appropriate. The Host Name AVP and/or Router ID AVP MUST be used to identify an LCCE as described in Section 3.3.
この名前は、できるだけ広く一意である必要があります。 DNS [RFC1034]に参加しているホストの場合、完全修飾ドメインのホスト名が適切です。セクション3.3で説明されているように、LCCEを識別するには、ホスト名AVPやルーターID AVPを使用する必要があります。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 6 plus the length of the Host Name.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは6にホスト名の長さを加えたものです。
Router ID (SCCRQ, SCCRP)
ルーターID（SCCRQ、SCCRP）
The Router ID AVP, Attribute Type 60, is an identifier used to identify an LCCE for control connection setup, tie breaking, and/or tunnel authentication.
ルーターID AVP、属性タイプ60は、制御接続のセットアップ、タイブレイク、トンネル認証などのLCCEを識別するために使用される識別子です。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Router Identifier is a 4-octet unsigned integer. Its value is unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name AVP and/or Router ID AVP MUST be used to identify an LCCE as described in Section 3.3.
ルーター識別子は4オクテットの符号なし整数です。その値は、[RFC2072]のセクション8.1に従って、特定のLCCEに固有です。セクション3.3で説明されているように、LCCEを識別するには、ホスト名AVPやルーターID AVPを使用する必要があります。
Implementations MUST NOT assume that Router Identifier is a valid IP address. The Router Identifier for L2TP over IPv6 can be obtained from an IPv4 address (if available) or via unspecified implementation-specific means.
実装では、ルーター識別子が有効なIPアドレスであると想定してはなりません。 L2TP over IPv6のルーター識別子は、IPv4アドレス（利用可能な場合）から、または不特定の実装固有の手段を介して取得できます。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 10.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは10です。
Vendor Name (SCCRQ, SCCRP)
ベンダー名（SCCRQ、SCCRP）
The Vendor Name AVP, Attribute Type 8, contains a vendor-specific (possibly human-readable) string describing the type of LAC or LNS being used.
ベンダー名AVP、属性タイプ8には、使用されているLACまたはLNSのタイプを説明するベンダー固有の（おそらく人間が読める）文字列が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor Name is the indicated number of octets representing the vendor string. Human-readable text for this AVP MUST be provided in the US-ASCII charset [RFC1958, RFC2277].
ベンダー名は、ベンダー文字列を表す指定されたオクテット数です。このAVPの人間が読めるテキストは、US-ASCII文字セット[RFC1958、RFC2277]で提供する必要があります。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 6 plus the length of the Vendor Name.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は、6にベンダー名の長さを加えたものです。
Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
割り当てられた制御接続ID（SCCRQ、SCCRP、StopCCN）
The Assigned Control Connection ID AVP, Attribute Type 61, contains the ID being assigned to this control connection by the sender.
割り当てられたコントロール接続ID AVP、属性タイプ61には、送信者によってこのコントロール接続に割り当てられているIDが含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Control Connection ID is a 4-octet non-zero unsigned integer.
割り当てられた制御接続IDは、4オクテットのゼロ以外の符号なし整数です。
The Assigned Control Connection ID AVP establishes the identifier used to multiplex and demultiplex multiple control connections between a pair of LCCEs. Once the Assigned Control Connection ID AVP has been received by an LCCE, the Control Connection ID specified in the AVP MUST be included in the Control Connection ID field of all control packets sent to the peer for the lifetime of the control connection. Before the Assigned Control Connection ID AVP is received from a peer, all control messages MUST be sent to that peer with a Control Connection ID value of 0 in the header. Because a Control Connection ID value of 0 is used in this special manner, the zero value MUST NOT be sent as an Assigned Control Connection ID value.
割り当てられた制御接続ID AVPは、LCCEのペア間の複数の制御接続を多重化および逆多重化するために使用される識別子を確立します。割り当てられた制御接続ID AVPがLCCEによって受信されると、AVPで指定された制御接続IDは、制御接続の存続期間中にピアに送信されるすべての制御パケットの制御接続IDフィールドに含まれなければなりません（MUST）。割り当てられた制御接続ID AVPがピアから受信される前に、すべての制御メッセージは、ヘッダーに制御接続ID値0を付けてそのピアに送信される必要があります。この特別な方法でコントロール接続ID値0が使用されるため、ゼロ値は割り当てられたコントロール接続ID値として送信してはなりません（MUST NOT）。
Under certain circumstances, an LCCE may need to send a StopCCN to a peer without having yet received an Assigned Control Connection ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet). In this case, the Assigned Control Connection ID AVP that had been sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the Assigned Control Connection ID AVP in the StopCCN. This policy allows the peer to try to identify the appropriate control connection via a reverse lookup.
特定の状況下では、LCCEは、ピアから割り当てられた制御接続ID AVPをまだ受信していない（つまり、SCCRQが送信され、SCCRPがまだ受信されていない）場合に、StopCCNをピアに送信する必要があります。この場合、以前にピアに送信された（つまり、SCCRQで）割り当てられた制御接続ID AVPは、StopCCNで割り当てられた制御接続ID AVPとして送信する必要があります。このポリシーにより、ピアは逆引き参照を介して適切な制御接続を識別しようとします。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は10です。
Receive Window Size (SCCRQ, SCCRP)
受信ウィンドウサイズ（SCCRQ、SCCRP）
The Receive Window Size AVP, Attribute Type 10, specifies the receive window size being offered to the remote peer.
受信ウィンドウサイズAVP、属性タイプ10は、リモートピアに提供される受信ウィンドウサイズを指定します。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2-octet unsigned integer.
ウィンドウサイズは2オクテットの符号なし整数です。
If absent, the peer must assume a Window Size of 4 for its transmit window.
存在しない場合、ピアは送信ウィンドウのウィンドウサイズを4と想定する必要があります。
The remote peer may send the specified number of control messages before it must wait for an acknowledgment. See Section 4.2 for more information on reliable control message delivery.
リモートピアは、確認応答を待機する前に、指定された数の制御メッセージを送信できます。信頼性の高い制御メッセージ配信の詳細については、セクション4.2を参照してください。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 8.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは8です。
Pseudowire Capabilities List (SCCRQ, SCCRP)
疑似配線機能リスト（SCCRQ、SCCRP）
The Pseudowire Capabilities List (PW Capabilities List) AVP, Attribute Type 62, indicates the L2 payload types the sender can support. The specific payload type of a given session is identified by the Pseudowire Type AVP.
疑似配線機能リスト（PW機能リスト）AVP、属性タイプ62は、送信者がサポートできるL2ペイロードタイプを示します。特定のセッションの特定のペイロードタイプは、疑似配線タイプAVPによって識別されます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined PW types that may appear in this list are managed by IANA and will appear in associated pseudowire-specific documents for each PW type.
このリストに表示される可能性のある定義済みのPWタイプはIANAによって管理され、各PWタイプの関連する疑似配線固有のドキュメントに表示されます。
If a sender includes a given PW type in the PW Capabilities List AVP, the sender assumes full responsibility for supporting that particular payload, such as any payload-specific AVPs, L2-Specific Sublayer, or control messages that may be defined in the appropriate companion document.
送信者がPW機能リストAVPに特定のPWタイプを含める場合、送信者は、特定のペイロード（ペイロード固有のAVP、L2固有のサブレイヤー、または適切なコンパニオンで定義される可能性のある制御メッセージなど）をサポートする全責任を負います。資料。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8 octets with one PW type specified, plus 2 octets for each additional PW type.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は、1つのPWタイプが指定された8オクテットと、追加のPWタイプごとに2オクテットです。
Preferred Language (SCCRQ, SCCRP)
優先言語（SCCRQ、SCCRP）
The Preferred Language AVP, Attribute Type 72, provides a method for an LCCE to indicate to the peer the language in which human-readable messages it sends SHOULD be composed. This AVP contains a single language tag or language range [RFC3066].
優先言語AVP、属性タイプ72は、LCCEがピアに送信する、人間が読めるメッセージを構成する言語をピアに示す方法を提供します（SHOULD）。このAVPには、単一の言語タグまたは言語範囲[RFC3066]が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Language... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Preferred Language is the indicated number of octets representing the language tag or language range, encoded in the US-ASCII charset.
優先言語は、US-ASCII文字セットでエンコードされた、言語タグまたは言語範囲を表す指定オクテット数です。
It is not required to send a Preferred Language AVP. If (1) an LCCE does not signify a language preference by the inclusion of this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or (3) the requested language is not supported by the peer LCCE, the default language [RFC2277] MUST be used for all internationalized strings sent by the peer.
優先言語AVPを送信する必要はありません。 （1）SCCRQまたはSCCRPにこのAVPを含めることによってLCCEが言語設定を示さない場合、（2）優先言語AVPが認識されない、または（3）要求された言語がピアLCCEでサポートされていない場合、デフォルト言語[RFC2277]は、ピアによって送信されるすべての国際化された文字列に使用されなければなりません（MUST）。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 6 plus the length of the Preferred Language.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は、6に優先言語の長さを加えたものです。
Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
ローカルセッションID（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、CDN、WEN、SLI）
The Local Session ID AVP (analogous to the Assigned Session ID in L2TPv2), Attribute Type 63, contains the identifier being assigned to this session by the sender.
ローカルセッションID AVP（L2TPv2の割り当て済みセッションIDに類似）、属性タイプ63には、送信者によってこのセッションに割り当てられている識別子が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Local Session ID is a 4-octet non-zero unsigned integer.
ローカルセッションIDは、4オクテットのゼロ以外の符号なし整数です。
The Local Session ID AVP establishes the two identifiers used to multiplex and demultiplex sessions between two LCCEs. Each LCCE chooses any free value it desires, and sends it to the remote LCCE using this AVP. The remote LCCE MUST then send all data packets associated with this session using this value. Additionally, for all session-oriented control messages sent after this AVP is received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this value in the Remote Session ID AVP.
ローカルセッションID AVPは、2つのLCCE間のセッションを多重化および逆多重化するために使用される2つの識別子を確立します。各LCCEは必要な無料の値を選択し、このAVPを使用してリモートLCCEに送信します。次に、リモートLCCEは、この値を使用して、このセッションに関連付けられたすべてのデータパケットを送信する必要があります。さらに、このAVPの受信後に送信されたすべてのセッション指向の制御メッセージ（ICRP、ICCN、CDN、SLIなど）の場合、リモートLCCEはこの値をリモートセッションID AVPにエコーする必要があります。
Note that a Session ID value is unidirectional. Because each LCCE chooses its Session ID independent of its peer LCCE, the value does not have to match in each direction for a given session.
セッションIDの値は単方向であることに注意してください。各LCCEはピアLCCEとは関係なくセッションIDを選択するため、特定のセッションの各方向で値を一致させる必要はありません。
See Section 4.1 for additional information about the Session ID.
セッションIDの詳細については、セクション4.1を参照してください。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に1に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は10です。
Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
リモートセッションID（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、CDN、WEN、SLI）
The Remote Session ID AVP, Attribute Type 64, contains the identifier that was assigned to this session by the peer.
リモートセッションID AVP、属性タイプ64には、ピアによってこのセッションに割り当てられた識別子が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote Session ID is a 4-octet non-zero unsigned integer.
リモートセッションIDは、4オクテットのゼロ以外の符号なし整数です。
The Remote Session ID AVP MUST be present in all session-level control messages. The AVP's value echoes the session identifier advertised by the peer via the Local Session ID AVP. It is the same value that will be used in all transmitted data messages by this side of the session. In most cases, this identifier is sufficient for the peer to look up session-level context for this control message.
リモートセッションID AVPは、すべてのセッションレベルの制御メッセージに存在する必要があります。 AVPの値は、ローカルセッションID AVPを介してピアによってアドバタイズされたセッション識別子をエコーします。セッションのこちら側で送信されるすべてのデータメッセージで使用される値と同じです。ほとんどの場合、この識別子は、ピアがこの制御メッセージのセッションレベルのコンテキストを検索するのに十分です。
When a session-level control message must be sent to the peer before the Local Session ID AVP has been received, the value of the Remote Session ID AVP MUST be set to zero. Additionally, the Local Session ID AVP (sent in a previous control message for this session) MUST be included in the control message. The peer must then use the Local Session ID AVP to perform a reverse lookup to find its session context. Session-level control messages defined in this document that might be subject to a reverse lookup by a receiving peer include the CDN, WEN, and SLI.
ローカルセッションID AVPを受信する前にセッションレベルの制御メッセージをピアに送信する必要がある場合、リモートセッションID AVPの値をゼロに設定する必要があります。さらに、ローカルセッションID AVP（このセッションの前の制御メッセージで送信された）が制御メッセージに含まれている必要があります。次に、ピアはローカルセッションID AVPを使用して逆引きを実行し、そのセッションコンテキストを見つける必要があります。このドキュメントで定義されているセッションレベルの制御メッセージには、受信ピアによる逆引きの対象となる可能性があり、CDN、WEN、およびSLIが含まれます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は10です。
Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)
割り当てられたCookie（ICRQ、ICRP、OCRQ、OCRP）
The Assigned Cookie AVP, Attribute Type 65, contains the Cookie value being assigned to this session by the sender.
割り当てられたCookie AVP、属性タイプ65には、送信者によってこのセッションに割り当てられているCookie値が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Cookie (32 or 64 bits) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Cookie is a 4-octet or 8-octet random value.
割り当てられたCookieは、4オクテットまたは8オクテットのランダムな値です。
The Assigned Cookie AVP contains the value used to check the association of a received data message with the session identified by the Session ID. All data messages sent to a peer MUST use the Assigned Cookie sent by the peer in this AVP. The value's length (0, 32, or 64 bits) is obtained by the length of the AVP.
割り当てられたCookie AVPには、受信したデータメッセージとセッションIDで識別されるセッションとの関連付けを確認するために使用される値が含まれています。ピアに送信されるすべてのデータメッセージは、このAVPのピアによって送信される割り当てられたCookieを使用する必要があります。値の長さ（0、32、または64ビット）は、AVPの長さによって取得されます。
A missing Assigned Cookie AVP or Assigned Cookie Value of zero length indicates that the Cookie field should not be present in any data packets sent to the LCCE sending this AVP.
割り当てられたCookie AVPまたは長さがゼロの割り当てられたCookie値がない場合は、このAVPを送信するLCCEに送信されるデータパケットにCookieフィールドが存在しないことを示します。
See Section 4.1 for additional information about the Assigned Cookie.
割り当てられたCookieの詳細については、セクション4.1を参照してください。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP may be 6, 10, or 14 octets.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は、6、10、または14オクテットです。
Serial Number (ICRQ, OCRQ)
シリアル番号（ICRQ、OCRQ）
The Serial Number AVP, Attribute Type 15, contains an identifier assigned by the LAC or LNS to this session.
シリアル番号AVP、属性タイプ15には、LACまたはLNSによってこのセッションに割り当てられた識別子が含まれています。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Serial Number is a 32-bit value.
シリアル番号は32ビット値です。
The Serial Number is intended to be an easy reference for administrators on both ends of a control connection to use when investigating session failure problems. Serial Numbers should be set to progressively increasing values, which are likely to be unique for a significant period of time across all interconnected LNSs and LACs.
シリアル番号は、制御接続の両端の管理者がセッション障害の問題を調査するときに使用する簡単なリファレンスになることを目的としています。シリアル番号は、徐々に増加する値に設定する必要があります。これは、相互接続されたすべてのLNSおよびLAC全体でかなりの期間にわたって一意になる可能性があります。
Note that in RFC 2661, this value was referred to as the "Call Serial Number AVP". It serves the same purpose and has the same attribute value and composition.
RFC 2661では、この値は「Call Serial Number AVP」と呼ばれていたことに注意してください。同じ目的を果たし、同じ属性値と構成を持っています。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は10です。
Remote End ID (ICRQ, OCRQ)
リモートエンドID（ICRQ、OCRQ）
The Remote End ID AVP, Attribute Type 66, contains an identifier used to bind L2TP sessions to a given circuit, interface, or bridging instance. It also may be used to detect session-level ties.
リモートエンドID AVPの属性タイプ66には、L2TPセッションを特定の回線、インターフェース、またはブリッジングインスタンスにバインドするために使用される識別子が含まれています。また、セッションレベルの関係を検出するためにも使用できます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote End Identifier ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote End Identifier field is a variable-length field whose
value is unique for a given LCCE peer, as described in Section
3.3.
A session-level tie is detected if an LCCE receives an ICRQ or OCRQ with an End ID AVP whose value matches that which was just sent in an outgoing ICRQ or OCRQ to the same peer. If the two values match, an LCCE recognizes that a tie exists (i.e., both LCCEs are attempting to establish sessions for the same circuit). The tie is broken by the Session Tie Breaker AVP.
LCCEが、同じIDへの発信ICRQまたはOCRQで送信されたばかりの値と一致する値を持つEnd ID AVPを持つICRQまたはOCRQを受信すると、セッションレベルのタイが検出されます。 2つの値が一致する場合、LCCEはタイが存在することを認識します（つまり、両方のLCCEが同じ回線のセッションを確立しようとしています）。ネクタイはセッションタイブレーカーAVPによって切断されます。
By default, the LAC-LAC cross-connect application (see Section 2(b)) of L2TP over an IP network MUST utilize the Router ID AVP and Remote End ID AVP to associate a circuit to an L2TP session. Other AVPs MAY be used for LCCE or circuit identification as specified in companion documents.
デフォルトでは、IPネットワークを介したL2TPのLAC-LACクロスコネクトアプリケーション（セクション2（b）を参照）は、ルーターID AVPおよびリモートエンドID AVPを使用して、回線をL2TPセッションに関連付ける必要があります。他のAVPは、関連ドキュメントで指定されているLCCEまたは回路の識別に使用できます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 6 plus the length of the Remote End Identifier value.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は、6にリモートエンド識別子の値の長さを加えたものです。
Session Tie Breaker (ICRQ, OCRQ)
セッションタイブレーカー（ICRQ、OCRQ）
The Session Tie Breaker AVP, Attribute Type 5, is used to break ties when two peers concurrently attempt to establish a session for the same circuit.
セッションタイブレーカーAVP、属性タイプ5は、2つのピアが同時に同じ回線のセッションを確立しようとしたときに、関係を解除するために使用されます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session Tie Breaker Value is an 8-octet random value that is used to choose a session when two LCCEs concurrently request a session for the same circuit. A tie is detected by examining the peer's identity (described in Section 3.3) plus the per-session shared value communicated via the End ID AVP. In the case of a tie, the recipient of an ICRQ or OCRQ must compare the received tie breaker value with the one that it sent earlier. The LCCE with the lower value "wins" and MUST send a CDN with result code set to 13 (as defined in Section 5.4.2) in response to the losing ICRQ or OCRQ. In the case in which a tie is detected, tie breakers are sent by both sides, and the tie breaker values are equal, both sides MUST discard their sessions and restart session negotiation with new random tie breaker values.
セッションタイブレーカー値は、2つのLCCEが同じ回線のセッションを同時に要求するときにセッションを選択するために使用される8オクテットのランダムな値です。同点は、ピアのID（セクション3.3で説明）と、End ID AVPを介して通信されるセッションごとの共有値を調べることによって検出されます。タイの場合、ICRQまたはOCRQの受信者は、受信したタイブレーカーの値を、以前に送信したタイブレーカーの値と比較する必要があります。低い値のLCCEは「勝ち」、ICRQまたはOCRQの喪失に応答して、結果コードを13に設定したCDN（5.4.2で定義）を送信する必要があります。タイが検出され、タイブレーカーが両側から送信され、タイブレーカーの値が等しい場合、両側がセッションを破棄し、新しいランダムタイブレーカーの値でセッションネゴシエーションを再開する必要があります。
If a tie is detected but only one side sends a Session Tie Breaker AVP, the session initiator that included the Session Tie Breaker AVP "wins". If neither side issues a tie breaker, then both sides MUST tear down the session.
タイが検出されたが、片側だけがセッションタイブレーカーAVPを送信した場合、セッションタイブレーカーAVPを含んでいたセッションイニシエーターが「勝ち」ます。どちらの側もタイブレーカーを発行しない場合、両側がセッションを破棄する必要があります。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 14.
このAVPは非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さは14です。
Pseudowire Type (ICRQ, OCRQ)
疑似配線タイプ（ICRQ、OCRQ）
The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates the L2 payload type of the packets that will be tunneled using this L2TP session.
疑似配線タイプ（PWタイプ）AVP、属性タイプ68は、このL2TPセッションを使用してトンネリングされるパケットのL2ペイロードタイプを示します。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer MUST NOT request an incoming or outgoing call with a PW Type AVP specifying a value not advertised in the PW Capabilities List AVP it received during control connection establishment. Attempts to do so MUST result in the call being rejected via a CDN with the Result Code set to 14 (see Section 5.4.2).
ピアは、制御接続の確立中に受信したPW機能リストAVPでアドバタイズされていない値を指定するPWタイプAVPで着信または発信呼び出しを要求してはなりません（MUST NOT）。そうする試みは、結果コードが14に設定されたCDN経由でコールが拒否されることになります（セクション5.4.2を参照）。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は8です。
L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
L2固有のサブレイヤー（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The L2-Specific Sublayer AVP, Attribute Type 69, indicates the presence and format of the L2-Specific Sublayer the sender of this AVP requires on all incoming data packets for this L2TP session.
L2固有のサブレイヤーAVP、属性タイプ69は、このL2TPセッションのすべての着信データパケットでこのAVPの送信者が必要とするL2固有のサブレイヤーの存在とフォーマットを示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2-Specific Sublayer Type is a 2-octet unsigned integer with
the following values defined in this document:
0 - There is no L2-Specific Sublayer present. 1 - The Default L2-Specific Sublayer (defined in Section 4.6) is used.
0-L2固有のサブレイヤーが存在しません。 1-デフォルトのL2固有のサブレイヤー（セクション4.6で定義）が使用されます。
If this AVP is received and has a value other than zero, the receiving LCCE MUST include the identified L2-Specific Sublayer in its outgoing data messages. If the AVP is not received, it is assumed that there is no sublayer present.
このAVPが受信され、ゼロ以外の値がある場合、受信LCCEは、識別されたL2固有のサブレイヤーを送信データメッセージに含める必要があります。 AVPが受信されない場合、サブレイヤーが存在しないと見なされます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は8です。
Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
データシーケンス（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The Data Sequencing AVP, Attribute Type 70, indicates that the sender requires some or all of the data packets that it receives to be sequenced.
データシーケンスAVP、属性タイプ70は、送信者が受信するデータパケットの一部またはすべてをシーケンスする必要があることを示します。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequencing Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data Sequencing Level is a 2-octet unsigned integer indicating the degree of incoming data traffic that the sender of this AVP wishes to be marked with sequence numbers.
データシーケンスレベルは2オクテットの符号なし整数で、このAVPの送信者がシーケンス番号でマークされることを希望する着信データトラフィックの程度を示します。
Defined Data Sequencing Levels are as follows:
定義されたデータシーケンスレベルは次のとおりです。
0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
0-着信データパケットはシーケンス処理を必要としません。 1-シーケンスが必要なのは非IPデータパケットのみです。 2-すべての着信データパケットにはシーケンス処理が必要です。
If a Data Sequencing Level of 0 is specified, there is no need to send packets with sequence numbers. If sequence numbers are sent, they will be ignored upon receipt. If no Data Sequencing AVP is received, a Data Sequencing Level of 0 is assumed.
データシーケンスレベル0が指定されている場合、シーケンス番号付きのパケットを送信する必要はありません。シーケンス番号が送信された場合、それらは受信時に無視されます。データシーケンスAVPが受信されない場合、データシーケンスレベル0が想定されます。
If a Data Sequencing Level of 1 is specified, only non-IP traffic carried within the tunneled L2 frame should have sequence numbers applied. Non-IP traffic here refers to any packets that cannot be classified as an IP packet within their respective L2 framing (e.g., a PPP control packet or NETBIOS frame encapsulated by Frame Relay before being tunneled). All traffic that can be classified as IP MUST be sent with no sequencing (i.e., the S bit in the L2- Specific Sublayer is set to zero). If a packet is unable to be classified at all (e.g., because it has been compressed or encrypted at layer 2) or if an implementation is unable to perform such classification within L2 frames, all packets MUST be provided with sequence numbers (essentially falling back to a Data Sequencing Level of 2).
データシーケンスレベル1が指定されている場合、トンネルL2フレーム内で伝送される非IPトラフィックのみにシーケンス番号を適用する必要があります。ここでの非IPトラフィックとは、それぞれのL2フレーミング内でIPパケットとして分類できないすべてのパケットを指します（たとえば、トンネルされる前にフレームリレーによってカプセル化されたPPP制御パケットまたはNETBIOSフレーム）。 IPとして分類できるすべてのトラフィックは、シーケンスなしで送信する必要があります（つまり、L2固有のサブレイヤーのSビットはゼロに設定されます）。パケットをまったく分類できない場合（たとえば、レイヤー2で圧縮または暗号化されているため）、または実装がL2フレーム内でそのような分類を実行できない場合は、すべてのパケットにシーケンス番号を指定する必要があります（基本的にフォールバック） 2のデータシーケンスレベルに）。
If a Data Sequencing Level of 2 is specified, all traffic MUST be sequenced.
データシーケンスレベル2が指定されている場合、すべてのトラフィックをシーケンス処理する必要があります。
Data sequencing may only be requested when there is an L2-Specific Sublayer present that can provide sequence numbers. If sequencing is requested without requesting a L2-Specific Sublayer AVP, the session MUST be disconnected with a Result Code of 15 (see Section 5.4.2).
データシーケンスは、シーケンス番号を提供できるL2固有のサブレイヤーが存在する場合にのみ要求できます。 L2固有のサブレイヤーAVPを要求せずにシーケンスが要求された場合、セッションは結果コード15で切断される必要があります（セクション5.4.2を参照）。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は8です。
Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
Tx接続速度（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The Tx Connect Speed BPS AVP, Attribute Type 74, contains the speed of the facility chosen for the connection attempt.
Tx接続速度BPS AVP、属性タイプ74には、接続試行のために選択されたファシリティの速度が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tx Connect Speed BPS is an 8-octet value indicating the speed in bits per second. A value of zero indicates that the speed is indeterminable or that there is no physical point-to-point link.
Tx Connect Speed BPSは、ビット/秒で速度を示す8オクテットの値です。ゼロの値は、速度が不確定であること、または物理的なポイントツーポイントリンクがないことを示します。
When the optional Rx Connect Speed AVP is present, the value in this AVP represents the transmit connect speed from the perspective of the LAC (i.e., data flowing from the LAC to the remote system). When the optional Rx Connect Speed AVP is NOT present, the connection speed between the remote system and LAC is assumed to be symmetric and is represented by the single value in this AVP.
オプションのRx接続速度AVPが存在する場合、このAVPの値は、LACの観点からの送信接続速度を表します（つまり、LACからリモートシステムに流れるデータ）。オプションのRx Connect Speed AVPが存在しない場合、リモートシステムとLAC間の接続速度は対称であると見なされ、このAVPの単一の値で表されます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 14.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は14です。
Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
Rx接続速度（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The Rx Connect Speed AVP, Attribute Type 75, represents the speed of the connection from the perspective of the LAC (i.e., data flowing from the remote system to the LAC).
Rx接続速度AVP、属性タイプ75は、LACの観点からの接続の速度（つまり、リモートシステムからLACに流れるデータ）を表します。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connect Speed BPS is an 8-octet value indicating the speed in bits per second. A value of zero indicates that the speed is indeterminable or that there is no physical point-to-point link.
接続速度BPSは、ビット/秒で速度を示す8オクテットの値です。ゼロの値は、速度が不確定であること、または物理的なポイントツーポイントリンクがないことを示します。
Presence of this AVP implies that the connection speed may be asymmetric with respect to the transmit connect speed given in the Tx Connect Speed AVP.
このAVPの存在は、Tx Connect Speed AVPで指定された送信接続速度に対して、接続速度が非対称になる可能性があることを意味します。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 14.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は14です。
Physical Channel ID (ICRQ, ICRP, OCRP)
物理チャネルID（ICRQ、ICRP、OCRP）
The Physical Channel ID AVP, Attribute Type 25, contains the vendor-specific physical channel number used for a call.
物理チャネルID AVP、属性タイプ25には、コールに使用されるベンダー固有の物理チャネル番号が含まれています。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4-octet value intended to be used for
logging purposes only.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は10です。
Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)
回線ステータス（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、SLI）
The Circuit Status AVP, Attribute Type 71, indicates the initial status of or a status change in the circuit to which the session is bound.
Circuit Status AVP、Attribute Type 71は、セッションがバインドされている回線の初期ステータスまたはステータス変更を示します。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The A (Active) bit indicates whether the circuit is up/active/ready (1) or down/inactive/not-ready (0).
A（アクティブ）ビットは、回路がアップ/アクティブ/準備完了（1）か、ダウン/非アクティブ/準備未完了（0）かを示します。
The N (New) bit indicates whether the circuit status indication is for a new circuit (1) or an existing circuit (0). Links that have a similar mechanism available (e.g., Frame Relay) MUST map the setting of this bit to the associated signaling for that link. Otherwise, the New bit SHOULD still be set the first time the L2TP session is established after provisioning.
N（新規）ビットは、回路ステータス表示が新しい回路（1）か既存の回路（0）かを示します。利用可能な同様のメカニズム（例えば、フレームリレー）を持つリンクは、このビットの設定をそのリンクの関連するシグナリングにマップしなければなりません（MUST）。それ以外の場合は、プロビジョニング後に初めてL2TPセッションが確立されたときに、新しいビットを設定する必要があります（SHOULD）。
The remaining bits are reserved for future use. Reserved bits MUST be set to 0 when sending and ignored upon receipt.
残りのビットは将来の使用のために予約されています。予約ビットは送信時に0に設定し、受信時に無視する必要があります。
The Circuit Status AVP is used to advertise whether a circuit or interface bound to an L2TP session is up and ready to send and/or receive traffic. Different circuit types have different names for status types. For example, HDLC primary and secondary stations refer to a circuit as being "Receive Ready" or "Receive Not Ready", while Frame Relay refers to a circuit as "Active" or "Inactive". This AVP adopts the latter terminology, though the concept remains the same regardless of the PW type for the L2TP session.
Circuit Status AVPは、L2TPセッションにバインドされた回線またはインターフェイスがアップしていて、トラフィックを送受信する準備ができているかどうかをアドバタイズするために使用されます。回路タイプごとに、ステータスタイプの名前が異なります。たとえば、HDLCプライマリおよびセカンダリステーションは回線を「Receive Ready」または「Receive Not Ready」と呼び、フレームリレーは回線を「Active」または「Inactive」と呼びます。このAVPは後者の用語を採用していますが、概念はL2TPセッションのPWタイプに関係なく同じです。
In the simplest case, the circuit to which this AVP refers is a single physical interface, port, or circuit, depending on the application and the session setup. The status indication in this AVP may then be used to provide simple ILMI interworking for a variety of circuit types. For virtual or multipoint interfaces, the Circuit Status AVP is still utilized, but in this case, it refers to the state of an internal structure or a logical set of circuits. Each PW-specific companion document MUST specify precisely how this AVP is translated for each circuit type.
最も単純なケースでは、このAVPが参照する回線は、アプリケーションとセッションのセットアップに応じて、単一の物理インターフェイス、ポート、または回線です。次に、このAVPのステータス表示を使用して、さまざまな種類の回路に簡単なILMIインターワーキングを提供できます。仮想またはマルチポイントインターフェイスの場合、Circuit Status AVPは引き続き使用されますが、この場合は、内部構造または論理セットの回路の状態を指します。各PW固有の関連ドキュメントは、このAVPが各回線タイプに対してどのように変換されるかを正確に指定する必要があります。
If this AVP is received with a Not Active notification for a given L2TP session, all data traffic for that session MUST cease (or not begin) in the direction of the sender of the Circuit Status AVP until the circuit is advertised as Active.
このAVPが特定のL2TPセッションの非アクティブ通知とともに受信される場合、そのセッションのすべてのデータトラフィックは、回路がアクティブとしてアドバタイズされるまで、回路ステータスAVPの送信者の方向で停止する（または開始しない）必要があります。
The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, OCRQ, and OCRP messages. Often, the circuit type will be marked Active when initiated, but subsequently MAY be advertised as Inactive. This indicates that an L2TP session is to be created, but that the interface or circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI control messages all MAY contain this AVP to update the status of the circuit after establishment of the L2TP session is requested.
Circuit Statusは、ICRQ、ICRP、OCRQ、およびOCRPメッセージでこのAVPによってアドバタイズされる必要があります。多くの場合、回線タイプは開始時にアクティブとマークされますが、その後非アクティブとしてアドバタイズされる場合があります。これは、L2TPセッションが作成されることを示していますが、インターフェイスまたは回線はまだトラフィックを渡す準備ができていません。 ICCN、OCCN、およびSLI制御メッセージにはすべて、L2TPセッションの確立が要求された後に回線のステータスを更新するために、このAVPが含まれている場合があります。
If additional circuit status information is needed for a given PW type, any new PW-specific AVPs MUST be defined in a separate document. This AVP is only for general circuit status information generally applicable to all circuit/interface types.
特定のPWタイプに追加の回線ステータス情報が必要な場合は、新しいPW固有のAVPを別のドキュメントで定義する必要があります。このAVPは、すべての回線/インターフェイスタイプに一般的に適用される一般的な回線ステータス情報専用です。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは1に設定する必要があります（SHOULD）が異なります（セクション5.2を参照）。このAVPの長さ（非表示前）は8です。
Circuit Errors (WEN)
回路エラー（WEN）
The Circuit Errors AVP, Attribute Type 34, conveys circuit error information to the peer.
回線エラーAVP、属性タイプ34は、回線エラー情報をピアに伝えます。
The Attribute Value field for this AVP has the following format:
この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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
以下のフィールドが定義されています。
Reserved: 2 octets of Reserved data is present (providing longword alignment within the AVP of the following values). Reserved data MUST be zero on sending and ignored upon receipt. Hardware Overruns: Number of receive buffer overruns since call was established. Buffer Overruns: Number of buffer overruns detected since call was established. Timeout Errors: Number of timeouts since call was established. Alignment Errors: Number of alignment errors since call was established.
予約済み：2オクテットの予約済みデータが存在します（次の値のAVP内でロングワードアラインメントを提供します）。予約済みのデータは送信時にゼロであり、受信時に無視されなければなりません。ハードウェアオーバーラン：呼び出しが確立されてからの受信バッファーオーバーランの数。バッファオーバーラン：コールが確立されてから検出されたバッファオーバーランの数。タイムアウトエラー：コールが確立されてからのタイムアウトの数。整列エラー：呼び出しが確立されてからの整列エラーの数。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 32.
このAVPは非表示にすることができます（Hビットは0または1の場合があります）。このAVPのMビットは0に設定する必要があります（SHOULD）が、異なる場合があります（セクション5.2を参照）。このAVPの長さ（非表示前）は32です。
The following control messages are used to establish, maintain, and tear down L2TP control connections. All data packets are sent in network order (high-order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility.
次の制御メッセージは、L2TP制御接続を確立、維持、および破棄するために使用されます。すべてのデータパケットはネットワーク順で送信されます（高次オクテットが最初）。 「予約済み」または「空」のフィールドは、プロトコルの拡張性を考慮して0の値として送信する必要があります。
The exchanges in which these messages are involved are outlined in Section 3.3.
これらのメッセージが関係する交換については、セクション3.3で概説されています。
Start-Control-Connection-Request (SCCRQ) is a control message used to initiate a control connection between two LCCEs. It is sent by either the LAC or the LNS to begin the control connection establishment process.
Start-Control-Connection-Request（SCCRQ）は、2つのLCCE間の制御接続を開始するために使用される制御メッセージです。これは、制御接続確立プロセスを開始するためにLACまたはLNSのいずれかによって送信されます。
The following AVPs MUST be present in the SCCRQ:
以下のAVPがSCCRQに存在している必要があります。
Message Type Host Name Router ID Assigned Control Connection ID Pseudowire Capabilities List
メッセージタイプホスト名ルーターID割り当てられた制御接続ID疑似配線機能リスト
The following AVPs MAY be present in the SCCRQ:
以下のAVPがSCCRQに存在する場合があります。
Random Vector Control Message Authentication Nonce Message Digest Control Connection Tie Breaker Vendor Name Receive Window Size Preferred Language
ランダムベクトル制御メッセージ認証ノンスメッセージダイジェスト制御接続タイブレーカーベンダー名受信ウィンドウサイズ優先言語
Start-Control-Connection-Reply (SCCRP) is the control message sent in reply to a received SCCRQ message. The SCCRP is used to indicate that the SCCRQ was accepted and that establishment of the control connection should continue.
Start-Control-Connection-Reply（SCCRP）は、受信したSCCRQメッセージへの応答として送信される制御メッセージです。 SCCRPは、SCCRQが受け入れられ、制御接続の確立を続行する必要があることを示すために使用されます。
The following AVPs MUST be present in the SCCRP:
次のAVPがSCCRPに存在する必要があります。
Message Type Host Name Router ID Assigned Control Connection ID Pseudowire Capabilities List
メッセージタイプホスト名ルーターID割り当てられた制御接続ID疑似配線機能リスト
The following AVPs MAY be present in the SCCRP:
以下のAVPがSCCRPに存在する場合があります。
Random Vector Control Message Authentication Nonce Message Digest Vendor Name Receive Window Size Preferred Language
ランダムベクトル制御メッセージ認証ノンスメッセージダイジェストベンダー名受信ウィンドウサイズ優先言語
Start-Control-Connection-Connected (SCCCN) is the control message sent in reply to an SCCRP. The SCCCN completes the control connection establishment process.
Start-Control-Connection-Connected（SCCCN）は、SCCRPへの応答として送信される制御メッセージです。 SCCCNは、制御接続確立プロセスを完了します。
The following AVP MUST be present in the SCCCN:
次のAVPがSCCCNに存在する必要があります。
Message Type
メッセージタイプ
The following AVP MAY be present in the SCCCN:
次のAVPがSCCCNに存在する場合があります。
Random Vector Message Digest
ランダムベクトルメッセージダイジェスト
Stop-Control-Connection-Notification (StopCCN) is the control message sent by either LCCE to inform its peer that the control connection is being shut down and that the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit session control messages). The reason for issuing this request is indicated in the Result Code AVP. There is no explicit reply to the message, only the implicit ACK that is received by the reliable control message delivery layer.
Stop-Control-Connection-Notification（StopCCN）は、どちらかのLCCEが送信する制御メッセージであり、制御接続がシャットダウンされていること、および制御接続を閉じる必要があることをピアに通知します。さらに、すべてのアクティブなセッションが暗黙的にクリアされます（明示的なセッション制御メッセージを送信せずに）。この要求を発行する理由は、結果コードAVPに示されています。メッセージへの明示的な応答はなく、信頼できる制御メッセージ配信層によって受信される暗黙のACKのみです。
The following AVPs MUST be present in the StopCCN:
次のAVPがStopCCNに存在している必要があります。
Message Type Result Code
メッセージタイプ結果コード
The following AVPs MAY be present in the StopCCN:
次のAVPがStopCCNに存在する場合があります。
Random Vector Message Digest Assigned Control Connection ID
ランダムベクターメッセージダイジェストに割り当てられたコントロール接続ID
Note that the Assigned Control Connection ID MUST be present if the StopCCN is sent after an SCCRQ or SCCRP message has been sent.
SCCRQまたはSCCRPメッセージが送信された後にStopCCNが送信される場合は、割り当てられた制御接続IDが存在する必要があることに注意してください。
The Hello (HELLO) message is an L2TP control message sent by either peer of a control connection. This control message is used as a "keepalive" for the control connection. See Section 4.2 for a description of the keepalive mechanism.
Hello（HELLO）メッセージは、制御接続のいずれかのピアによって送信されるL2TP制御メッセージです。この制御メッセージは、制御接続の「キープアライブ」として使用されます。キープアライブメカニズムの説明については、セクション4.2を参照してください。
HELLO messages are global to the control connection. The Session ID in a HELLO message MUST be 0.
HELLOメッセージは、制御接続に対してグローバルです。 HELLOメッセージのセッションIDは0でなければなりません。
The following AVP MUST be present in the HELLO:
次のAVPがHELLOに存在する必要があります。
Message Type
メッセージタイプ
The following AVP MAY be present in the HELLO:
次のAVPがHELLOに存在する場合があります。
Random Vector Message Digest
ランダムベクトルメッセージダイジェスト
Incoming-Call-Request (ICRQ) is the control message sent by an LCCE to a peer when an incoming call is detected (although the ICRQ may also be sent as a result of a local event). It is the first in a three-message exchange used for establishing a session via an L2TP control connection.
Incoming-Call-Request（ICRQ）は、着信コールが検出されたときにLCCEからピアに送信される制御メッセージです（ただし、ローカルイベントの結果としてICRQが送信されることもあります）。これは、L2TP制御接続を介してセッションを確立するために使用される3つのメッセージ交換の最初のものです。
The ICRQ is used to indicate that a session is to be established between an LCCE and a peer. The sender of an ICRQ provides the peer with parameter information for the session. However, the sender makes no demands about how the session is terminated at the peer (i.e., whether the L2 traffic is processed locally, forwarded, etc.).
ICRQは、LCCEとピア間でセッションが確立されることを示すために使用されます。 ICRQの送信者は、ピアにセッションのパラメーター情報を提供します。ただし、送信者はセッションがピアでどのように終了するか（つまり、L2トラフィックがローカルで処理されるか、転送されるかなど）を要求しません。
The following AVPs MUST be present in the ICRQ:
以下のAVPがICRQに存在する必要があります。
Message Type Local Session ID Remote Session ID Serial Number Pseudowire Type Remote End ID Circuit Status
メッセージタイプローカルセッションIDリモートセッションIDシリアル番号疑似配線タイプリモートエンドID回線ステータス
The following AVPs MAY be present in the ICRQ:
以下のAVPがICRQに存在する場合があります。
Random Vector Message Digest Assigned Cookie Session Tie Breaker L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Physical Channel ID
ランダムベクトルメッセージダイジェスト割り当て済みCookieセッションタイブレーカーL2固有のサブレイヤーデータシーケンスTx接続速度Rx接続速度物理チャネルID
Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in response to a received ICRQ. It is the second in the three-message exchange used for establishing sessions within an L2TP control connection.
Incoming-Call-Reply（ICRP）は、受信したICRQへの応答としてLCCEによって送信される制御メッセージです。これは、L2TP制御接続内でセッションを確立するために使用される3つのメッセージ交換の2番目です。
The ICRP is used to indicate that the ICRQ was successful and that the peer should establish (i.e., answer) the incoming call if it has not already done so. It also allows the sender to indicate specific parameters about the L2TP session.
ICRPは、ICRQが成功したこと、およびピアが着信コールをまだ確立していない場合は確立する（応答する）必要があることを示すために使用されます。また、送信者がL2TPセッションに関する特定のパラメーターを示すこともできます。
The following AVPs MUST be present in the ICRP:
次のAVPがICRPに存在している必要があります。
Message Type Local Session ID Remote Session ID Circuit Status
メッセージタイプローカルセッションIDリモートセッションID回線ステータス
The following AVPs MAY be present in the ICRP:
以下のAVPがICRPに存在する場合があります。
Random Vector Message Digest Assigned Cookie L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Physical Channel ID
ランダムベクトルメッセージダイジェスト割り当て済みCookie L2固有のサブレイヤーデータシーケンスTx接続速度Rx接続速度物理チャネルID
Incoming-Call-Connected (ICCN) is the control message sent by the LCCE that originally sent an ICRQ upon receiving an ICRP from its peer. It is the final message in the three-message exchange used for establishing L2TP sessions.
Incoming-Call-Connected（ICCN）は、LCCEが送信した制御メッセージであり、ピアからICRPを受信したときに最初にICRQを送信しました。これは、L2TPセッションの確立に使用される3つのメッセージ交換の最後のメッセージです。
The ICCN is used to indicate that the ICRP was accepted, that the call has been established, and that the L2TP session should move to the established state. It also allows the sender to indicate specific parameters about the established call (parameters that may not have been available at the time the ICRQ was issued).
ICCNは、ICRPが受け入れられたこと、呼び出しが確立されたこと、およびL2TPセッションが確立された状態に移行することを示すために使用されます。また、送信者は、確立された呼び出しに関する特定のパラメーター（ICRQの発行時に利用できなかった可能性のあるパラメーター）を示すこともできます。
The following AVPs MUST be present in the ICCN:
次のAVPがICCNに存在する必要があります。
Message Type Local Session ID Remote Session ID
メッセージタイプローカルセッションIDリモートセッションID
The following AVPs MAY be present in the ICCN:
以下のAVPがICCNに存在する場合があります。
Random Vector Message Digest L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Circuit Status
ランダムベクトルメッセージダイジェストL2固有のサブレイヤデータシーケンスTx接続速度Rx接続速度回路のステータス
Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE to an LAC to indicate that an outbound call at the LAC is to be established based on specific destination information sent in this message. It is the first in a three-message exchange used for establishing a session and placing a call on behalf of the initiating LCCE.
Outgoing-Call-Request（OCRQ）は、LCCEからLACに送信される制御メッセージであり、LACでのアウトバウンドコールが、このメッセージで送信される特定の宛先情報に基づいて確立されることを示します。これは、セッションの確立と開始LCCEに代わって電話をかけるために使用される3つのメッセージ交換の最初のものです。
Note that a call may be any L2 connection requiring well-known destination information to be sent from an LCCE to an LAC. This call could be a dialup connection to the PSTN, an SVC connection, the IP address of another LCCE, or any other destination dictated by the sender of this message.
コールは、よく知られた宛先情報をLCCEからLACに送信する必要がある任意のL2接続である可能性があることに注意してください。この呼び出しは、PSTNへのダイヤルアップ接続、SVC接続、別のLCCEのIPアドレス、またはこのメッセージの送信者によって指示されたその他の宛先である可能性があります。
The following AVPs MUST be present in the OCRQ:
以下のAVPがOCRQに存在している必要があります。
Message Type Local Session ID Remote Session ID Serial Number Pseudowire Type Remote End ID Circuit Status
メッセージタイプローカルセッションIDリモートセッションIDシリアル番号疑似配線タイプリモートエンドID回線ステータス
The following AVPs MAY be present in the OCRQ:
以下のAVPがOCRQに存在してもよい：
Random Vector Message Digest Assigned Cookie Tx Connect Speed Rx Connect Speed Session Tie Breaker L2-Specific Sublayer Data Sequencing
ランダムベクトルメッセージダイジェスト割り当て済みCookie Tx接続速度Rx接続速度セッションタイブレーカーL2固有のサブレイヤーデータシーケンス
Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to an LCCE in response to a received OCRQ. It is the second in a three-message exchange used for establishing a session within an L2TP control connection.
Outgoing-Call-Reply（OCRP）は、受信したOCRQに応答してLACからLCCEに送信される制御メッセージです。これは、L2TP制御接続内でセッションを確立するために使用される3つのメッセージ交換の2番目です。
OCRP is used to indicate that the LAC has been able to attempt the outbound call. The message returns any relevant parameters regarding the call attempt. Data MUST NOT be forwarded until the OCCN is received, which indicates that the call has been placed.
OCRPは、LACがアウトバウンドコールを試行できたことを示すために使用されます。メッセージは、コール試行に関連するパラメータを返します。 OCCNが受信されるまで、データを転送してはなりません。これは、呼び出しが行われたことを示します。
The following AVPs MUST be present in the OCRP:
次のAVPがOCRPに存在する必要があります。
Message Type Local Session ID Remote Session ID Circuit Status
メッセージタイプローカルセッションIDリモートセッションID回線ステータス
The following AVPs MAY be present in the OCRP:
次のAVPがOCRPに存在する場合があります。
Random Vector Message Digest Assigned Cookie L2-Specific Sublayer Tx Connect Speed Rx Connect Speed Data Sequencing Physical Channel ID
ランダムベクトルメッセージダイジェスト割り当て済みCookie L2固有のサブレイヤーTx接続速度Rx接続速度データシーケンス物理チャネルID
Outgoing-Call-Connected (OCCN) is the control message sent by an LAC to another LCCE after the OCRP and after the outgoing call has been completed. It is the final message in a three-message exchange used for establishing a session.
Outgoing-Call-Connected（OCCN）は、OCRPの後、および発信呼び出しが完了した後に、LACから別のLCCEに送信される制御メッセージです。これは、セッションの確立に使用される3つのメッセージ交換の最後のメッセージです。
OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LCCE who requested the call about the particular parameters obtained after the call was established.
OCCNは、要求された発信呼び出しの結果が成功したことを示すために使用されます。また、コールの確立後に取得された特定のパラメータについて、コールを要求したLCCEに情報を提供します。
The following AVPs MUST be present in the OCCN:
次のAVPがOCCNに存在している必要があります。
Message Type Local Session ID Remote Session ID
メッセージタイプローカルセッションIDリモートセッションID
The following AVPs MAY be present in the OCCN:
次のAVPがOCCNに存在する場合があります。
Random Vector Message Digest L2-Specific Sublayer Tx Connect Speed Rx Connect Speed Data Sequencing Circuit Status
ランダムベクトルメッセージダイジェストL2固有のサブレイヤーTx接続速度Rx接続速度データシーケンス回路のステータス
The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE to request disconnection of a specific session. Its purpose is to inform the peer of the disconnection and the reason for the disconnection. The peer MUST clean up any resources, and does not send back any indication of success or failure for such cleanup.
Call-Disconnect-Notify（CDN）は、LCCEが特定のセッションの切断を要求するために送信する制御メッセージです。その目的は、ピアに切断と切断の理由を通知することです。ピアはすべてのリソースをクリーンアップする必要があり、そのようなクリーンアップの成功または失敗の兆候を返送しません。
The following AVPs MUST be present in the CDN:
以下のAVPがCDNに存在している必要があります。
Message Type Result Code Local Session ID Remote Session ID
メッセージタイプ結果コードローカルセッションIDリモートセッションID
The following AVP MAY be present in the CDN:
次のAVPがCDNに存在する場合があります。
Random Vector Message Digest
ランダムベクトルメッセージダイジェスト
The WAN-Error-Notify (WEN) is a control message sent from an LAC to an LNS to indicate WAN error conditions. The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established.
WAN-Error-Notify（WEN）は、WANエラー状態を示すためにLACからLNSに送信される制御メッセージです。このメッセージのカウンターは累積されます。このメッセージは、エラーが発生した場合にのみ送信し、60秒ごとに送信する必要があります。カウンタは、新しいコールが確立されるとリセットされます。
The following AVPs MUST be present in the WEN:
次のAVPがWENに存在する必要があります。
Message Type Local Session ID Remote Session ID Circuit Errors
メッセージタイプローカルセッションIDリモートセッションID回線エラー
The following AVP MAY be present in the WEN:
次のAVPがWENに存在する場合があります。
Random Vector Message Digest
ランダムベクトルメッセージダイジェスト
The Set-Link-Info control message is sent by an LCCE to convey link or circuit status change information regarding the circuit associated with this L2TP session. For example, if PPP renegotiates LCP at an LNS or between an LAC and a Remote System, or if a forwarded Frame Relay VC transitions to Active or Inactive at an LAC, an SLI message SHOULD be sent to indicate this event. Precise details of when the SLI is sent, what PW type-specific AVPs must be present, and how those AVPs should be interpreted by the receiving peer are outside the scope of this document. These details should be described in the associated pseudowire-specific documents that require use of this message.
Set-Link-Info制御メッセージは、LCCEによって送信され、このL2TPセッションに関連付けられた回線に関するリンクまたは回線のステータス変更情報を伝えます。たとえば、PPPがLNSまたはLACとリモートシステムの間でLCPを再ネゴシエートする場合、または転送されたフレームリレーVCがLACでアクティブまたは非アクティブに移行する場合、このイベントを示すためにSLIメッセージを送信する必要があります（SHOULD）。 SLIが送信されるタイミング、存在する必要があるPWタイプ固有のAVP、およびそれらのAVPが受信ピアによってどのように解釈されるかについての詳細は、このドキュメントの範囲外です。これらの詳細は、このメッセージの使用を必要とする関連する疑似配線固有のドキュメントで説明する必要があります。
The following AVPs MUST be present in the SLI:
以下のAVPがSLIに存在する必要があります。
Message Type Local Session ID Remote Session ID
メッセージタイプローカルセッションIDリモートセッションID
The following AVPs MAY be present in the SLI:
以下のAVPがSLIに存在する場合があります。
Random Vector Message Digest Circuit Status
ランダムベクトルメッセージダイジェスト回路のステータス
The Explicit Acknowledgement (ACK) message is used only to acknowledge receipt of a message or messages on the control connection (e.g., for purposes of updating Ns and Nr values). Receipt of this message does not trigger an event for the L2TP protocol state machine.
明示的確認応答（ACK）メッセージは、制御接続での1つまたは複数のメッセージの受信を確認するためにのみ使用されます（たとえば、NsとNrの値を更新する目的で）。このメッセージを受信しても、L2TPプロトコルステートマシンのイベントはトリガーされません。
A message received without any AVPs (including the Message Type AVP), is referred to as a Zero Length Body (ZLB) message, and serves the same function as the Explicit Acknowledgement. ZLB messages are only permitted when Control Message Authentication defined in Section 4.3 is not enabled.
AVP（メッセージタイプAVPを含む）なしで受信されたメッセージは、Zero Length Body（ZLB）メッセージと呼ばれ、明示的確認応答と同じ機能を果たします。 ZLBメッセージは、セクション4.3で定義された制御メッセージ認証が有効になっていない場合にのみ許可されます。
The following AVPs MAY be present in the ACK message:
次のAVPがACKメッセージに存在する場合があります。
Message Type Message Digest
メッセージタイプメッセージダイジェスト
The state tables defined in this section govern the exchange of control messages defined in Section 6. Tables are defined for incoming call placement and outgoing call placement, as well as for initiation of the control connection itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying reliable control message delivery mechanism (see Section 4.2).
このセクションで定義されている状態テーブルは、セクション6で定義されている制御メッセージの交換を管理します。テーブルは、着信呼び出しの配置と発信呼び出しの配置、および制御接続自体の開始に対して定義されます。状態テーブルは、タイムアウトと再送信の動作をエンコードしません。これは、基礎となる信頼できる制御メッセージ配信メカニズムで処理されるためです（セクション4.2を参照）。
Receipt of an invalid or unrecoverable malformed control message SHOULD be logged appropriately and the control connection cleared to ensure recovery to a known state. The control connection may then be restarted by the initiator.
無効または回復不可能な不正な制御メッセージの受信は適切にログに記録し、既知の状態に確実に回復するために制御接続をクリアする必要があります（SHOULD）。その後、制御接続はイニシエーターによって再開されます。
An invalid control message is defined as (1) a message that contains a Message Type marked as mandatory (see Section 5.4.1) but that is unknown to the implementation, or (2) a control message that is received in the wrong state.
無効な制御メッセージは、（1）必須としてマークされたメッセージタイプ（セクション5.4.1を参照）を含むが、実装には不明なメッセージ、または（2）誤った状態で受信された制御メッセージとして定義されます。
Examples of malformed control messages include (1) a message that has an invalid value in its header, (2) a message that contains an AVP that is formatted incorrectly or whose value is out of range, and (3) a message that is missing a required AVP. A control message with a malformed header MUST be discarded.
不正な形式の制御メッセージの例には、（1）ヘッダーに無効な値が含まれているメッセージ、（2）正しくフォーマットされていない、または値が範囲外のAVPが含まれているメッセージ、および（3）欠落しているメッセージが含まれます。必要なAVP。不正な形式のヘッダーを持つ制御メッセージは破棄されなければなりません（MUST）。
When possible, a malformed AVP should be treated as an unrecognized AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD be made to determine the importance of the malformed AVP, and thus, the severity of the malformation to the entire control message. If the M bit can be reasonably inspected within the malformed AVP and is determined to be set, then as with an unrecognized AVP, the associated session or control connection MUST be shut down. If the M bit is inspected and is found to be 0, the AVP MUST be ignored (assuming recovery from the AVP malformation is indeed possible).
可能であれば、不正なAVPは認識されないAVPとして扱われる必要があります（セクション5.2を参照）。したがって、Mビットを検査する試みは、不正な形式のAVPの重要性、つまり制御メッセージ全体に対する不正の重大度を判断するために行われる必要があります（SHOULD）。不正なAVP内でMビットを適切に検査でき、設定されていると判断された場合、認識されないAVPと同様に、関連するセッションまたは制御接続をシャットダウンする必要があります。 Mビットが検査され、0であることが判明した場合、AVPを無視する必要があります（AVPの奇形からの回復が実際に可能であると想定）。
This policy must not be considered as a license to send malformed AVPs, but rather, as a guide towards how to handle an improperly formatted message if one is received. It is impossible to list all potential malformations of a given message and give advice for each. One example of a malformed AVP situation that should be recoverable is if the Rx Connect Speed AVP is received with a length of 10 rather than 14, implying that the connect speed bits-per-second is being formatted in 4 octets rather than 8. If the AVP does not have its M bit set (as would typically be the case), this condition is not considered catastrophic. As such, the control message should be accepted as though the AVP were not present (though a local error message may be logged).
このポリシーは、不正な形式のAVPを送信するためのライセンスではなく、不適切にフォーマットされたメッセージを受信した場合の処理方法のガイドと見なす必要があります。特定のメッセージのすべての潜在的な奇形をリストし、それぞれに助言を与えることは不可能です。回復可能である必要がある不正なAVP状況の1つの例は、Rx Connect Speed AVPが14ではなく10の長さで受信された場合、接続速度ビット/秒が8ではなく4オクテットでフォーマットされていることを意味します。 AVPにMビットが設定されていない（通常の場合）ので、この状態は致命的とは見なされません。そのため、AVPが存在しないかのように制御メッセージを受け入れる必要があります（ローカルエラーメッセージがログに記録される場合があります）。
In several cases in the following tables, a protocol message is sent, and then a "clean up" occurs. Note that, regardless of the initiator of the control connection destruction, the reliable delivery mechanism must be allowed to run (see Section 4.2) before destroying the control connection. This permits the control connection management messages to be reliably delivered to the peer.
次の表のいくつかのケースでは、プロトコルメッセージが送信された後、「クリーンアップ」が行われます。制御接続の破棄の開始者に関係なく、信頼できる配信メカニズムは、制御接続を破棄する前に実行を許可する必要があります（セクション4.2を参照）。これにより、制御接続管理メッセージを確実にピアに配信できます。
Appendix B.1 contains an example of lock-step control connection establishment.
付録B.1には、ロックステップ制御接続の確立の例が含まれています。
The L2TP control connection protocol is not distinguishable between the two LCCEs but is distinguishable between the originator and receiver. The originating peer is the one that first initiates establishment of the control connection. (In a tie breaker situation, this is the winner of the tie.) Since either the LAC or the LNS can be the originator, a collision can occur. See the Control Connection Tie Breaker AVP in Section 5.4.3 for a description of this and its resolution.
L2TP制御接続プロトコルは、2つのLCCE間では区別できませんが、発信側と受信側では区別できます。発信ピアは、最初に制御接続の確立を開始するピアです。 （タイ・ブレーカーの状況では、これはタイの勝者です。）LACまたはLNSのいずれかがオリジネーターになる可能性があるため、衝突が発生する可能性があります。これとその解決策の説明については、セクション5.4.3の制御接続タイブレーカーAVPを参照してください。
State Event Action New State
----- ----- ------ ---------
idle Local open Send SCCRQ wait-ctl-reply
request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable
アイドルSCCRQを受信、SCCRPを送信wait-ctl-connを受け入れ可能
idle Receive SCCRQ, Send StopCCN, idle not acceptable clean up
アイドル受信SCCRQ、送信StopCCN、アイドルは受け入れられないクリーンアップ
idle Receive SCCRP Send StopCCN, idle clean up
アイドル受信SCCRP送信StopCCN、アイドルクリーンアップ
idle Receive SCCCN Send StopCCN, idle clean up
アイドル受信SCCCN送信StopCCN、アイドルクリーンアップ
wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable send control-conn open event to waiting sessions
wait-ctl-reply SCCRPの受信、SCCCNの送信、待機セッションへの受け入れ可能な送信制御接続オープンイベントの確立
wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable clean up
wait-ctl-reply SCCRPの受信、StopCCNの送信、アイドルは受け入れられないクリーンアップ
wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn lose tie breaker, Clean up losing SCCRQ acceptable connection
wait-ctl-reply SCCRQの受信、SCCRPの送信、wait-ctl-connによるタイブレーカーの喪失、SCCRQの受け入れ可能な接続の喪失のクリーンアップ
wait-ctl-reply Receive SCCRQ, Send StopCCN, idle lose tie breaker, Clean up losing SCCRQ unacceptable connection
wait-ctl-reply SCCRQの受信、StopCCNの送信、タイブレーカーのアイドル喪失、SCCRQの許容できない接続の喪失のクリーンアップ
wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply win tie breaker losing connection
wait-ctl-reply SCCRQを受信し、Stop-CCNを送信して、wait-ctl-reply win tie breakerが接続を失う
wait-ctl-reply Receive SCCCN Send StopCCN, idle clean up
wait-ctl-reply SCCCNの受信StopCCNの送信、アイドルクリーンアップ
wait-ctl-conn Receive SCCCN, Send control-conn established acceptable open event to waiting sessions
wait-ctl-conn SCCCNの受信、待機中のセッションへのcontrol-connの確立された受け入れ可能なオープンイベントの送信
wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable clean up
wait-ctl-conn SCCCNの受信、StopCCNの送信、アイドルは受け入れられないクリーンアップ
wait-ctl-conn Receive SCCRQ, Send StopCCN, idle SCCRP clean up
wait-ctl-conn SCCRQ受信、StopCCN送信、アイドルSCCRPクリーンアップ
established Local open Send control-conn established request open event to (new call) waiting sessions
確立されたローカルオープンコントロール接続確立要求オープンイベントを（新しい呼び出し）待機セッションに送信
established Administrative Send StopCCN, idle control-conn clean up close event
確立された管理送信StopCCN、アイドル状態の制御接続クリーンアップクローズイベント
established Receive SCCRQ, Send StopCCN, idle SCCRP, SCCCN clean up
確立された受信SCCRQ、送信StopCCN、アイドルSCCRP、SCCCNクリーンアップ
idle, Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established The states associated with an LCCE for control connection establishment are as follows:
アイドル、Receive StopCCNのクリーンアップアイドル待機-ctl-reply、待機-ctl-conn、確立済み制御接続確立のためのLCCEに関連する状態は次のとおりです。
idle Both initiator and recipient start from this state. An initiator transmits an SCCRQ, while a recipient remains in the idle state until receiving an SCCRQ.
idleイニシエーターと受信者の両方がこの状態から開始します。イニシエーターはSCCRQを送信し、受信者はSCCRQを受信するまでアイドル状態のままです。
wait-ctl-reply The originator checks to see if another connection has been requested from the same peer, and if so, handles the collision situation described in Section 5.4.3.
wait-ctl-reply発信者は、同じピアから別の接続がリクエストされているかどうかを確認し、リクエストされている場合は、セクション5.4.3で説明されている衝突状況を処理します。
wait-ctl-conn Awaiting an SCCCN. If the SCCCN is valid, the control connection is established; otherwise, it is torn down (sending a StopCCN with the proper result and/or error code).
wait-ctl-conn SCCCNを待機しています。 SCCCNが有効な場合、制御接続が確立されます。それ以外の場合は、破棄されます（適切な結果やエラーコードとともにStopCCNを送信します）。
established An established connection may be terminated by either a local condition or the receipt of a StopCCN. In the event of a local termination, the originator MUST send a StopCCN and clean up the control connection. If the originator receives a StopCCN, it MUST also clean up the control connection.
確立された接続は、ローカル条件またはStopCCNの受信のいずれかによって終了できます。ローカル終了の場合、発信者はStopCCNを送信し、制御接続をクリーンアップする必要があります。発信者がStopCCNを受信した場合は、制御接続もクリーンアップする必要があります。
An ICRQ is generated by an LCCE, typically in response to an incoming call or a local event. Once the LCCE sends the ICRQ, it waits for a response from the peer. However, it may choose to postpone establishment of the call (e.g., answering the call, bringing up the circuit) until the peer has indicated with an ICRP that it will accept the call. The peer may choose not to accept the call if, for instance, there are insufficient resources to handle an additional session.
ICRQはLCCEによって生成され、通常は着信コールまたはローカルイベントに応答します。 LCCEがICRQを送信すると、ピアからの応答を待ちます。ただし、ピアがコールを受け入れることをICRPで示すまで、コールの確立を延期する（たとえば、コールに応答する、回線を始動する）ことを選択できます。ピアは、たとえば、追加のセッションを処理するためのリソースが不足している場合、コールを受け入れないことを選択できます。
If the peer chooses to accept the call, it responds with an ICRP. When the local LCCE receives the ICRP, it attempts to establish the call. A final call connected message, the ICCN, is sent from the local LCCE to the peer to indicate that the call states for both LCCEs should enter the established state. If the call is terminated before the peer can accept it, a CDN is sent by the local LCCE to indicate this condition.
ピアがコールを受け入れることを選択した場合、ピアはICRPで応答します。ローカルLCCEがICRPを受信すると、コールの確立を試みます。最後のコール接続メッセージであるICCNは、ローカルLCCEからピアに送信され、両方のLCCEのコール状態が確立済み状態になることを示します。ピアがコールを受け入れる前にコールが終了すると、ローカルLCCEによってCDNが送信され、この状態を示します。
When a call transitions to a "disconnected" or "down" state, the call is cleared normally, and the local LCCE sends a CDN. Similarly, if the peer wishes to clear a call, it sends a CDN and cleans up its session.
コールが「切断」または「ダウン」状態に移行すると、コールは正常にクリアされ、ローカルLCCEがCDNを送信します。同様に、ピアがコールをクリアしたい場合は、CDNを送信してセッションをクリーンアップします。
State Event Action New State
----- ----- ------ ---------
idle Call signal or Initiate local wait-control-conn ready to receive control-conn incoming conn open
アイドルコール信号またはローカル待機制御接続を開始して、制御接続の着信接続を受信する準備ができています
idle Receive ICCN, Clean up idle ICRP, CDN
アイドル受信ICCN、クリーンアップアイドルICRP、CDN
wait-control- Bearer line drop Clean up idle conn or local close request
wait-control- Bearer line dropアイドル状態の接続またはローカルのクローズ要求をクリーンアップします
wait-control- control-conn-open Send ICRQ wait-reply conn
wait-control- control-conn-open ICRQ送信-返信-connを送信
wait-reply Receive ICRP, Send ICCN established acceptable
待機応答ICRPを受信、ICCNを送信可能
wait-reply Receive ICRP, Send CDN, idle Not acceptable clean up
待機応答ICRPの受信、CDNの送信、アイドル受け入れられないクリーンアップ
wait-reply Receive ICRQ, Process as idle lose tie breaker ICRQ Recipient (Section 7.3.2)
待機応答ICRQを受信し、アイドルがタイブレーカーICRQ受信者を失うと処理します（セクション7.3.2）。
wait-reply Receive ICRQ, Send CDN wait-reply win tie breaker for losing session
ICRQを受信して待機し、セッションを失った場合はCDNを送信して返信を獲得する
wait-reply Receive CDN, Clean up idle ICCN
待機応答CDNの受信、アイドルICCNのクリーンアップ
wait-reply Local close Send CDN, idle request clean up
待機応答ローカルクローズCDNの送信、アイドルリクエストのクリーンアップ
established Receive CDN Clean up idle
確立された受信CDNクリーンアップアイドル
established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up
確立された受信ICRQ、送信CDN、アイドルICRP、ICCNクリーンアップ
established Local close Send CDN, idle request clean up
確立されたローカルクローズCDNの送信、アイドルリクエストのクリーンアップ
The states associated with the ICRQ sender are as follows:
ICRQ送信者に関連付けられている状態は次のとおりです。
idle The LCCE detects an incoming call on one of its interfaces (e.g., an analog PSTN line rings, or an ATM PVC is provisioned), or a local event occurs. The LCCE initiates its control connection establishment state machine and moves to a state waiting for confirmation of the existence of a control connection.
アイドルLCCEがそのインターフェースの1つ（たとえば、アナログPSTN回線リング、またはATM PVCがプロビジョニングされている）で着信呼び出しを検出するか、ローカルイベントが発生します。 LCCEは、制御接続確立状態マシンを開始し、制御接続の存在の確認を待機する状態に移行します。
wait-control-conn In this state, the session is waiting for either the control connection to be opened or for verification that the control connection is already open. Once an indication that the control connection has been opened is received, session control messages may be exchanged. The first of these messages is the ICRQ.
wait-control-connこの状態では、セッションは、制御接続が開かれるか、制御接続がすでに開かれていることの確認を待っています。制御接続が開かれたという指示が受信されると、セッション制御メッセージが交換されます。これらのメッセージの最初はICRQです。
wait-reply The ICRQ sender receives either (1) a CDN indicating the peer is not willing to accept the call (general error or do not accept) and moves back into the idle state, or (2) an ICRP indicating the call is accepted. In the latter case, the LCCE sends an ICCN and enters the established state.
待機応答ICRQ送信者は、（1）ピアがコールを受け入れる用意がない（一般的なエラーまたは受け入れない）ことを示すCDNを受信し、アイドル状態に戻るか、（2）コールが受け入れられたことを示すICRPを受信します。 。後者の場合、LCCEはICCNを送信し、確立状態に入ります。
established Data is exchanged over the session. The call may be cleared by any of the following: + An event on the connected interface: The LCCE sends a CDN. + Receipt of a CDN: The LCCE cleans up, disconnecting the call. + A local reason: The LCCE sends a CDN.
確立されたデータはセッションを介して交換されます。呼び出しは、次のいずれかによってクリアされる可能性があります。+接続されたインターフェースのイベント：LCCEがCDNを送信します。 + CDNの受信：LCCEがクリーンアップし、通話を切断します。 +ローカルな理由：LCCEがCDNを送信します。
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle not acceptable clean up
アイドルICRQの受信、CDNの送信、アイドルは受け入れられないクリーンアップ
idle Receive ICRP Send CDN idle clean up
アイドル受信ICRP送信CDNアイドルクリーンアップ
idle Receive ICCN Clean up idle
アイドル受信ICCNクリーンアップアイドル
wait-connect Receive ICCN, Prepare for established acceptable data
待機接続ICCNの受信、確立された受け入れ可能なデータの準備
wait-connect Receive ICCN, Send CDN, idle not acceptable clean up
待機接続ICCNの受信、CDNの送信、アイドルは受け入れられないクリーンアップ
wait-connect Receive ICRQ, Send CDN, idle ICRP clean up
待機接続ICRQ受信、CDN送信、アイドルICRPクリーンアップ
idle, Receive CDN Clean up idle wait-connect, established
アイドル、CDNの受信、アイドル待機接続のクリーンアップ、確立
wait-connect Local close Send CDN, idle established request clean up
待機接続ローカルクローズCDNの送信、アイドル状態の確立された要求のクリーンアップ
established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up
確立された受信ICRQ、送信CDN、アイドルICRP、ICCNクリーンアップ
The states associated with the ICRQ recipient are as follows:
ICRQ受信者に関連付けられている状態は次のとおりです。
idle An ICRQ is received. If the request is not acceptable, a CDN is sent back to the peer LCCE, and the local LCCE remains in the idle state. If the ICRQ is acceptable, an ICRP is sent. The session moves to the wait-connect state.
ICRQを受信しました。要求が受け入れられない場合、CDNがピアLCCEに送り返され、ローカルLCCEはアイドル状態のままになります。 ICRQが受け入れ可能である場合、ICRPが送信されます。セッションは接続待ち状態に移行します。
wait-connect The local LCCE is waiting for an ICCN from the peer. Upon receipt of the ICCN, the local LCCE moves to established state.
wait-connectローカルLCCEは、ピアからのICCNを待っています。 ICCNを受信すると、ローカルLCCEは確立状態に移行します。
established The session is terminated either by sending a CDN or by receiving a CDN from the peer. Clean up follows on both sides regardless of the initiator.
確立済みセッションは、CDNを送信するか、ピアからCDNを受信することによって終了します。イニシエーターに関係なく、両側でクリーンアップを行います。
Outgoing calls instruct an LAC to place a call. There are three messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first sends an OCRQ to an LAC to request an outgoing call. The LAC MUST respond to the OCRQ with an OCRP once it determines that the proper facilities exist to place the call and that the call is administratively authorized. Once the outbound call is connected, the LAC sends an OCCN to the peer indicating the final result of the call attempt.
発信コールは、LACにコールを発信するように指示します。発信コールには、OCRQ、OCRP、およびOCCNの3つのメッセージがあります。 LCCEは最初にOCRQをLACに送信して、発信コールを要求します。 LACは、コールを発信するための適切なファシリティが存在し、コールが管理上許可されていると判断すると、OCRPでOCRQに応答する必要があります。発信コールが接続されると、LACはOCCNをピアに送信し、コール試行の最終結果を示します。
State Event Action New State
----- ----- ------ ---------
idle Local open Initiate local wait-control-conn
request control-conn-open
idle Receive OCCN, Clean up idle OCRP
アイドルOCCNの受信、アイドルOCRPのクリーンアップ
wait-control- control-conn-open Send OCRQ wait-reply conn
wait-control- control-conn-open OCRQ待機応答connを送信します
wait-reply Receive OCRP, none wait-connect acceptable
待機応答OCRPを受信し、待機接続は受け入れられない
wait-reply Receive OCRP, Send CDN, idle not acceptable clean up
待機応答OCRPの受信、CDNの送信、アイドルは受け入れられないクリーンアップ
wait-reply Receive OCCN Send CDN, idle clean up
待機応答OCCNの受信CDNの送信、アイドルクリーンアップ
wait-reply Receive OCRQ, Process as idle lose tie breaker OCRQ Recipient (Section 7.4.2)
待機応答OCRQの受信、アイドルとしてのタイブレーカーOCRQ受信者の喪失（セクション7.4.2）
wait-reply Receive OCRQ, Send CDN wait-reply win tie breaker for losing session
セッションを失った場合のOCRQの受信、CDNの送信の待機応答の勝利タイブレーカーの待機応答
wait-connect Receive OCCN none established
待機接続受信OCCNなし確立
wait-connect Receive OCRQ, Send CDN, idle OCRP clean up
待機接続OCRQ受信、CDN送信、アイドルOCRPクリーンアップ
idle, Receive CDN Clean up idle wait-reply, wait-connect, established
アイドル、受信CDNクリーンアップアイドル待機応答、待機接続、確立
established Receive OCRQ, Send CDN, idle OCRP, OCCN clean up
確立された受信OCRQ、送信CDN、アイドルOCRP、OCCNクリーンアップ
wait-reply, Local close Send CDN, idle wait-connect, request clean up established wait-control- Local close Clean up idle conn request
待機応答、ローカルクローズCDNの送信、アイドル待機接続、要求のクリーンアップの確立待機制御-ローカルクローズアイドル接続のクリーンアップ要求
The states associated with the OCRQ sender are as follows:
OCRQ送信者に関連付けられている状態は次のとおりです。
idle, wait-control-conn When an outgoing call request is initiated, a control connection is created as described above, if not already present. Once the control connection is established, an OCRQ is sent to the LAC, and the session moves into the wait-reply state.
idle、wait-control-conn発信呼び出し要求が開始されると、まだ存在しない場合は、上記のように制御接続が作成されます。制御接続が確立されると、OCRQがLACに送信され、セッションは応答待ち状態に移行します。
wait-reply If a CDN is received, the session is cleaned up and returns to idle state. If an OCRP is received, the call is in progress, and the session moves to the wait-connect state.
待機応答CDNを受信すると、セッションがクリーンアップされ、アイドル状態に戻ります。 OCRPを受信した場合、コールは進行中で、セッションは接続待機状態に移行します。
wait-connect If a CDN is received, the session is cleaned up and returns to idle state. If an OCCN is received, the call has succeeded, and the session may now exchange data.
wait-connect CDNを受信すると、セッションはクリーンアップされ、アイドル状態に戻ります。 OCCNが受信された場合、呼び出しは成功しており、セッションはデータを交換できます。
established If a CDN is received, the session is cleaned up and returns to idle state. Alternatively, if the LCCE chooses to terminate the session, it sends a CDN to the LAC, cleans up the session, and moves the session to idle state.
確立済みCDNを受信した場合、セッションはクリーンアップされ、アイドル状態に戻ります。または、LCCEがセッションを終了することを選択した場合、CDNをLACに送信し、セッションをクリーンアップして、セッションをアイドル状態に移行します。
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
idle Receive OCRQ, Send CDN, idle not acceptable clean up
アイドルOCRQの受信、CDNの送信、アイドルは受け入れられないクリーンアップ
idle Receive OCRP Send CDN, idle clean up
アイドル受信OCRP送信CDN、アイドルクリーンアップ
idle Receive OCCN, Clean up idle CDN
アイドルOCCNの受信、アイドルCDNのクリーンアップ
wait-cs-answer Call placement Send OCCN established successful
wait-cs-answer呼び出しの配置送信OCCNが正常に確立されました
wait-cs-answer Call placement Send CDN, idle failed clean up
wait-cs-answer呼び出しの配置CDNの送信、アイドルのクリーンアップの失敗
wait-cs-answer Receive OCRQ, Send CDN, idle OCRP, OCCN clean up
wait-cs-answer OCRQの受信、CDNの送信、アイドルOCRP、OCCNクリーンアップ
established Receive OCRQ, Send CDN, idle OCRP, OCCN clean up
確立された受信OCRQ、送信CDN、アイドルOCRP、OCCNクリーンアップ
wait-cs-answer, Receive CDN Clean up idle established
wait-cs-answer、受信CDNクリーンアップアイドルの確立
wait-cs-answer, Local close Send CDN, idle established request clean up
wait-cs-answer、Local close Send CDN、アイドル状態の確立済みリクエストのクリーンアップ
The states associated with the LAC for outgoing calls are as follows:
発信コールのLACに関連付けられている状態は次のとおりです。
idle If the OCRQ is received in error, respond with a CDN. Otherwise, place the call, send an OCRP, and move to the wait-cs-answer state.
アイドルOCRQが誤って受信された場合は、CDNで応答します。それ以外の場合は、コールを発信し、OCRPを送信して、wait-cs-answer状態に移行します。
wait-cs-answer If the call is not completed or a timer expires while waiting for the call to complete, send a CDN with the appropriate error condition set, and go to idle state. If a circuit-switched connection is established, send an OCCN indicating success, and go to established state.
wait-cs-answerコールが完了しないか、コールの完了を待機中にタイマーが切れた場合は、適切なエラー条件を設定してCDNを送信し、アイドル状態に移行します。回線交換接続が確立されている場合は、成功を示すOCCNを送信し、確立状態に移行します。
established If the LAC receives a CDN from the peer, the call MUST be released via appropriate mechanisms, and the session cleaned up. If the call is disconnected because the circuit transitions to a "disconnected" or "down" state, the LAC MUST send a CDN to the peer and return to idle state.
確立されたLACがピアからCDNを受信した場合、適切なメカニズムを介してコールを解放し、セッションをクリーンアップする必要があります。回線が「切断」または「ダウン」状態に移行したために通話が切断された場合、LACはCDNをピアに送信し、アイドル状態に戻る必要があります。
The termination of a control connection consists of either peer issuing a StopCCN. The sender of this message SHOULD wait a full control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ... seconds) for the acknowledgment of this message before releasing the control information associated with the control connection. The recipient of this message should send an acknowledgment of the message to the peer, then release the associated control information.
制御接続の終了は、StopCCNを発行するいずれかのピアで構成されます。このメッセージの送信者は、制御接続に関連する制御情報を解放する前に、このメッセージの確認応答を完全な制御メッセージ再送信サイクル（たとえば、1 + 2 + 4 + 8 ...秒）待機する必要があります。このメッセージの受信者は、メッセージの確認応答をピアに送信してから、関連する制御情報を解放する必要があります。
When to release a control connection is an implementation issue and is not specified in this document. A particular implementation may use whatever policy is appropriate for determining when to release a control connection. Some implementations may leave a control connection open for a period of time or perhaps indefinitely after the last session for that control connection is cleared. Others may choose to disconnect the control connection immediately after the last call on the control connection disconnects.
制御接続を解放するタイミングは実装上の問題であり、このドキュメントでは指定されていません。特定の実装では、制御接続を解放するタイミングを決定するために適切なポリシーを使用できます。一部の実装では、制御接続を一定期間開いたままにするか、その制御接続の最後のセッションがクリアされた後、おそらく無期限に開いたままにする場合があります。他のユーザーは、制御接続の最後の呼び出しが切断された直後に制御接続を切断することを選択できます。
This section addresses some of the security issues that L2TP encounters in its operation.
このセクションでは、L2TPの操作中に発生するセキュリティの問題について説明します。
If a shared secret (password) exists between two LCCEs, it may be used to perform a mutual authentication between the two LCCEs, and construct an authentication and integrity check of arriving L2TP control messages. The mechanism provided by L2TPv3 is described in Section 4.3 and in the definition of the Message Digest and Control Message Authentication Nonce AVPs in Section 5.4.1.
2つのLCCEの間に共有秘密（パスワード）が存在する場合、それを使用して2つのLCCE間で相互認証を実行し、到着するL2TP制御メッセージの認証と整合性チェックを構築できます。 L2TPv3によって提供されるメカニズムについては、セクション4.3、およびセクション5.4.1のメッセージダイジェストおよび制御メッセージ認証ノンスAVPの定義で説明されています。
This control message security mechanism provides for (1) mutual endpoint authentication, and (2) individual control message integrity and authenticity checking. Mutual endpoint authentication ensures that an L2TPv3 control connection is only established between two endpoints that are configured with the proper password. The individual control message and integrity check guards against accidental or intentional packet corruption (i.e., those caused by a control message spoofing or man-in-the-middle attack).
この制御メッセージセキュリティメカニズムは、（1）相互エンドポイント認証、および（2）個々の制御メッセージの整合性と認証性チェックを提供します。相互エンドポイント認証により、L2TPv3制御接続は、適切なパスワードで構成された2つのエンドポイント間でのみ確立されます。個々の制御メッセージと整合性チェックは、偶発的または意図的なパケット破損（つまり、制御メッセージのなりすましまたは中間者攻撃によって引き起こされるもの）を防ぎます。
The shared secret that is used for all control connection, control message, and AVP security features defined in this document never needs to be sent in the clear between L2TP tunnel endpoints.
このドキュメントで定義されているすべての制御接続、制御メッセージ、およびAVPセキュリティ機能に使用される共有秘密は、L2TPトンネルエンドポイント間で平文で送信される必要はありません。
Packet spoofing for any type of Virtual Private Network (VPN) protocol is of particular concern as insertion of carefully constructed rogue packets into the VPN transit network could result in a violation of VPN traffic separation, leaking data into a customer VPN. This is complicated by the fact that it may be particularly difficult for the operator of the VPN to even be aware that it has become a point of transit into or between customer VPNs.
慎重に作成された不正なパケットをVPNトランジットネットワークに挿入すると、VPNトラフィックの分離違反が発生し、データが顧客のVPNに漏洩する可能性があるため、あらゆるタイプの仮想プライベートネットワーク（VPN）プロトコルのパケットスプーフィングは特に懸念されます。これは、VPNのオペレーターがカスタマーVPNへの、またはカスタマーVPN間のトランジットポイントになったことを認識することさえ特に難しい場合があるという事実によって複雑になります。
L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit.
L2TPv3は、L2TPv3データヘッダーの32ビットセッションIDを介して、VPNのトラフィックを分離します。存在する場合、L2TPv3 Cookie（セクション4.1で説明）は、到着したパケットが識別されたセッションを対象としていることを確認するための追加のチェックを提供します。したがって、セッションIDでCookieを使用すると、セッションIDルックアップが適切に実行され、セッションID自体が転送中に破損していないことがさらに保証されます。
In the presence of a blind packet spoofing attack, the Cookie may also provide security against inadvertent leaking of frames into a customer VPN. To illustrate the type of security that it is provided in this case, consider comparing the validation of a 64-bit Cookie in the L2TPv3 header to the admission of packets that match a given source and destination IP address pair. Both the source and destination IP address pair validation and Cookie validation consist of a fast check on cleartext header information on all arriving packets. However, since L2TPv3 uses its own value, it removes the requirement for one to maintain a list of (potentially several) permitted or denied IP addresses, and moreover, to guard knowledge of the permitted IP addresses from hackers who may obtain and spoof them. Further, it is far easier to change a compromised L2TPv3 Cookie than a compromised IP address," and a cryptographically random [RFC1750] value is far less likely to be discovered by brute-force attacks compared to an IP address.
ブラインドパケットスプーフィング攻撃が存在する場合、Cookieは、不注意によるフレームのカスタマーVPNへの漏洩に対するセキュリティも提供します。この場合に提供されるセキュリティの種類を説明するために、L2TPv3ヘッダーの64ビットCookieの検証を、特定の送信元と宛先のIPアドレスのペアに一致するパケットのアドミッションと比較することを検討してください。送信元IPアドレスと宛先IPアドレスのペアの検証とCookieの検証は、到着するすべてのパケットのクリアテキストヘッダー情報の高速チェックで構成されています。ただし、L2TPv3は独自の値を使用するため、許可または拒否された（場合によっては複数の）IPアドレスのリストを維持する必要がなくなり、さらに、許可されたIPアドレスの情報を取得してなりすましを行うハッカーから守ることができます。さらに、危険にさらされたIPアドレスよりも危険にさらされたL2TPv3 Cookieを変更する方がはるかに簡単です。」暗号的にランダムな[RFC1750]値は、IPアドレスに比べて総当たり攻撃によって発見される可能性がはるかに低くなります。
For protection against brute-force, blind, insertion attacks, a 64- bit Cookie MUST be used with all sessions. A 32-bit Cookie is vulnerable to brute-force guessing at high packet rates, and as such, should not be considered an effective barrier to blind insertion attacks (though it is still useful as an additional verification of a successful Session ID lookup). The Cookie provides no protection against a sophisticated man-in-the-middle attacker who can sniff and correlate captured data between nodes for use in a coordinated attack.
総当たり攻撃、ブラインド攻撃、挿入攻撃から保護するには、すべてのセッションで64ビットのCookieを使用する必要があります。 32ビットCookieは、高いパケットレートでのブルートフォース推測に対して脆弱であるため、ブラインド挿入攻撃に対する効果的なバリアと見なすべきではありません（ただし、成功したセッションIDルックアップの追加検証としては依然として有用です）。 Cookieは、調整された攻撃で使用するためにノード間でキャプチャされたデータを傍受して相関させることができる高度な中間者攻撃に対する保護を提供しません。
The Assigned Cookie AVP is used to signal the value and size of the Cookie that must be present in all data packets for a given session. Each Assigned Cookie MUST be selected in a cryptographically random manner [RFC1750] such that a series of Assigned Cookies does not provide any indication of what a future Cookie will be.
割り当てられたCookie AVPは、特定のセッションのすべてのデータパケットに存在する必要があるCookieの値とサイズを通知するために使用されます。各割り当てられたCookieは、一連の割り当てられたCookieが将来のCookieが何であるかを示すものを提供しないように、暗号的にランダムな方法[RFC1750]で選択する必要があります。
The L2TPv3 Cookie must not be regarded as a substitute for security such as that provided by IPsec when operating over an open or untrusted network where packets may be sniffed, decoded, and correlated for use in a coordinated attack. See Section 4.1.3 for more information on running L2TP over IPsec.
L2TPv3 Cookieは、調整された攻撃で使用するためにパケットが傍受、復号化、および関連付けられる可能性のあるオープンまたは信頼できないネットワーク上で動作する場合、IPsecによって提供されるセキュリティなどの代用と見なしてはなりません。 L2TP over IPsecの実行の詳細については、セクション4.1.3を参照してください。
The Host Name and Vendor Name AVPs are not internationalized. The Vendor Name AVP, although intended to be human-readable, would seem to fit in the category of "globally visible names" [RFC2277] and so is represented in US-ASCII.
ホスト名とベンダー名のAVPは国際化されていません。ベンダー名AVPは、人間が読めるようにすることを目的としていますが、「グローバルに表示される名前」[RFC2277]のカテゴリーに当てはまるようで、US-ASCIIで表されます。
If (1) an LCCE does not signify a language preference by the inclusion of a Preferred Language AVP (see Section 5.4.3) in the
（1）LCCEが優先言語AVP（セクション5.4.3を参照）を
SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or (3) the requested language is not supported by the peer LCCE, the default language [RFC2277] MUST be used for all internationalized strings sent by the peer.
SCCRQまたはSCCRP、（2）優先言語AVPが認識されない、または（3）要求された言語がピアLCCEでサポートされていない。デフォルト言語[RFC2277]は、ピアが送信するすべての国際化文字列に使用する必要があります。
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document.
このドキュメントは、IANAによって維持されるいくつかの「マジック」番号を定義しています。このセクションでは、IANAがこれらの各リストに追加の番号を割り当てるために使用する基準について説明します。次のサブセクションでは、このドキュメントの他の場所で定義されている名前空間の割り当てポリシーについて説明します。
Sections 10.1 through 10.3 are requests for new values already managed by IANA according to [RFC3438].
セクション10.1から10.3は、[RFC3438]に従ってIANAによってすでに管理されている新しい値の要求です。
The remaining sections are for new registries that have been added to the existing L2TP registry and are maintained by IANA accordingly.
残りのセクションは、既存のL2TPレジストリに追加され、IANAによって適宜維持される新しいレジストリ用です。
This number space is managed by IANA as per [RFC3438].
この番号スペースは、[RFC3438]に従ってIANAによって管理されます。
A summary of the new AVPs follows:
新しいAVPの概要は次のとおりです。
Control Message Attribute Value Pairs
制御メッセージ属性値ペア
Attribute
Type Description
--------- ------------------
58 Extended Vendor ID AVP 59 Message Digest 60 Router ID 61 Assigned Control Connection ID 62 Pseudowire Capabilities List 63 Local Session ID 64 Remote Session ID 65 Assigned Cookie 66 Remote End ID 68 Pseudowire Type 69 L2-Specific Sublayer 70 Data Sequencing 71 Circuit Status 72 Preferred Language 73 Control Message Authentication Nonce 74 Tx Connect Speed 75 Rx Connect Speed
58拡張ベンダーID AVP 59メッセージダイジェスト60ルーターID 61割り当てられた制御接続ID 62疑似配線機能リスト63ローカルセッションID 64リモートセッションID 65割り当てられたCookie 66リモートエンドID 68疑似配線タイプ69 L2固有のサブレイヤー70データシーケンス71回路ステータス72優先言語73制御メッセージ認証ノンス74 Tx接続速度75 Rx接続速度
This number space is managed by IANA as per [RFC3438]. There is one new message type, defined in Section 3.1, that was allocated for this specification:
この番号スペースは、[RFC3438]に従ってIANAによって管理されます。セクション3.1で定義された、この仕様に割り当てられた新しいメッセージタイプが1つあります。
Message Type AVP (Attribute Type 0) Values
------------------------------------------
Control Connection Management
接続管理の制御
20 (ACK) Explicit Acknowledgement
20（ACK）明示的な確認
This number space is managed by IANA as per [RFC3438].
この番号スペースは、[RFC3438]に従ってIANAによって管理されます。
New Result Code values for the CDN message are defined in Section 5.4. The following is a summary:
CDNメッセージの新しい結果コードの値は、セクション5.4で定義されています。以下は要約です。
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
General Error Codes
一般的なエラーコード
13 - Session not established due to losing tie breaker (L2TPv3). 14 - Session not established due to unsupported PW type (L2TPv3). 15 - Session not established, sequencing required without valid L2-Specific Sublayer (L2TPv3). 16 - Finite state machine error or timeout.
13-タイブレーカー（L2TPv3）が失われたため、セッションが確立されませんでした。 14-サポートされていないPWタイプ（L2TPv3）が原因でセッションが確立されていません。 15-セッションが確立されていません。有効なL2固有サブレイヤー（L2TPv3）なしでシーケンスが必要です。 16-有限状態マシンエラーまたはタイムアウト。
This is a new registry for IANA to maintain.
これは、IANAが維持する新しいレジストリです。
Leading Bits of the L2TP AVP Header
-----------------------------------
There six bits at the beginning of the L2TP AVP header. New bits are assigned via Standards Action [RFC2434].
L2TP AVPヘッダーの先頭には6ビットあります。新しいビットは、標準アクション[RFC2434]を介して割り当てられます。
Bit 0 - Mandatory (M bit) Bit 1 - Hidden (H bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved
ビット0-必須（Mビット）ビット1-非表示（Hビット）ビット2-予約済みビット3-予約済みビット4-予約済みビット5-予約済み
This is a new registry for IANA to maintain.
これは、IANAが維持する新しいレジストリです。
Leading Bits of the L2TP Control Message Header
-----------------------------------------------
There are 12 bits at the beginning of the L2TP Control Message Header. Reserved bits should only be defined by Standard Action [RFC2434].
L2TP制御メッセージヘッダーの先頭には12ビットがあります。予約ビットは、標準アクション[RFC2434]によってのみ定義されるべきです。
Bit 0 - Message Type (T bit) Bit 1 - Length Field is Present (L bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Sequence Numbers Present (S bit) Bit 5 - Reserved Bit 6 - Offset Field is Present [RFC2661] Bit 7 - Priority Bit (P bit) [RFC2661] Bit 8 - Reserved Bit 9 - Reserved Bit 10 - Reserved Bit 11 - Reserved
ビット0-メッセージタイプ（Tビット）ビット1-長さフィールドが存在する（Lビット）ビット2-予約済みビット3-予約済みビット4-シーケンス番号が存在する（Sビット）ビット5-予約済みビット6-オフセットフィールドが存在する[ RFC2661]ビット7-優先ビット（Pビット）[RFC2661]ビット8-予約済みビット9-予約済みビット10-予約済みビット11-予約済み
This is a new registry for IANA to maintain, there are no values assigned within this document to maintain.
これは、IANAが維持する新しいレジストリです。このドキュメント内で維持する値は割り当てられていません。
L2TPv3 Pseudowire Types
-----------------------
The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review [RFC2434], while 32768 to 65535 are assigned by a First Come First Served policy [RFC2434]. There are no specific pseudowire types assigned within this document. Each pseudowire-specific document must allocate its own PW types from IANA as necessary.
疑似配線タイプ（PWタイプ、セクション5.4を参照）は、セクション5.4.3で定義された疑似配線タイプAVPおよび疑似配線機能リストAVPで使用される2オクテットの値です。 0〜32767はExpert Review [RFC2434]によって割り当て可能ですが、32768〜65535は先着順ポリシー[RFC2434]によって割り当てられます。このドキュメントでは、特定の疑似配線タイプは割り当てられていません。疑似配線固有の各ドキュメントは、必要に応じてIANAから独自のPWタイプを割り当てる必要があります。
This is a new registry for IANA to maintain.
これは、IANAが維持する新しいレジストリです。
Circuit Status Bits
-------------------
The Circuit Status field is a 16-bit mask, with the two low order bits assigned. Additional bits may be assigned by IETF Consensus [RFC2434].
Circuit Statusフィールドは、下位2ビットが割り当てられた16ビットマスクです。 IETFコンセンサス[RFC2434]によって追加のビットが割り当てられる場合があります。
Bit 14 - New (N bit) Bit 15 - Active (A bit)
ビット14-新規（Nビット）ビット15-アクティブ（Aビット）
This is a new registry for IANA to maintain.
これは、IANAが維持する新しいレジストリです。
Default L2-Specific Sublayer Bits
---------------------------------
The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. Reserved bits may be assigned by IETF Consensus [RFC2434].
デフォルトのL2固有のサブレイヤーには、ヘッダーの下位部分に8ビットが含まれています。予約済みビットは、IETFコンセンサス[RFC2434]によって割り当てられる場合があります。
Bit 0 - Reserved Bit 1 - Sequence (S bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved Bit 6 - Reserved Bit 7 - Reserved
ビット0-予約済みビット1-シーケンス（Sビット）ビット2-予約済みビット3-予約済みビット4-予約済みビット5-予約済みビット6-予約済みビット7-予約済み
This is a new registry for IANA to maintain.
これは、IANAが維持する新しいレジストリです。
L2-Specific Sublayer Type
-------------------------
The L2-Specific Sublayer Type is a 2-octet unsigned integer. Additional values may be assigned by Expert Review [RFC2434].
L2固有のサブレイヤータイプは、2オクテットの符号なし整数です。追加の値はExpert Review [RFC2434]によって割り当てられる場合があります。
0 - No L2-Specific Sublayer 1 - Default L2-Specific Sublayer present
0-L2固有のサブレイヤーなし1-デフォルトのL2固有のサブレイヤーが存在する
This is a new registry for IANA to maintain.
これは、IANAが維持する新しいレジストリです。
Data Sequencing Level
---------------------
The Data Sequencing Level is a 2-octet unsigned integer Additional values may be assigned by Expert Review [RFC2434].
データシーケンスレベルは、2オクテットの符号なし整数です。追加の値は、Expert Review [RFC2434]によって割り当てられる場合があります。
0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
0-着信データパケットはシーケンス処理を必要としません。 1-シーケンスが必要なのは非IPデータパケットのみです。 2-すべての着信データパケットにはシーケンス処理が必要です。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「文字セットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCのIANAに関する考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、1998年12月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびパルター、B。、「レイヤー2トンネリングレイヤー2トンネリングプロトコル（L2TP）」、RFC 2661、 1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] Patel、B.、Aboba、B.、Dixon、W.、Zorn、G。、およびBoots、S。、「IPsecを使用したL2TPの保護」、RFC 3193、2001年11月。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[RFC3438]タウンズリー、W。、「レイヤー2トンネリングプロトコル（L2TP）インターネット割当番号局（IANA）に関する考慮事項の更新」、BCP 68、RFC 3438、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、Ed。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700] Reynolds、J.およびPostel、J。、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。、およびSchiller、J。、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、1996年6月。
[RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S.、およびMogul、J。、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072] Berkowitz、H。、「Router Renumbering Guide」、RFC 2072、1997年1月。
[RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびCanetti、R。、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2341]バレンシア、A。、リトルウッド、M。、およびコーラー、T。、「Cisco Layer Two Forwarding（Protocol）L2F」、RFC 2341、1998年5月。
[RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびAtkinson、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびStevens、W。、「TCP Congestion Control」、RFC 2581、1999年4月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、Pall、G.、Verthein、W.、Taarud、J.、Little、W.、and Zorn、G.、 "Point-to-Point Tunneling Protocol（PPTP）"、RFC 2637、 1999年7月。
[RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC2732] Hinden、R.、Carpenter、B。、およびMasinter、L。、「URL内のリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000.
[RFC2809] Aboba、B。およびZorn、G。、「RADIUSを介したL2TP強制トンネリングの実装」、RFC 2809、2000年4月。
[RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two Tunneling Protocol (L2TP) over Frame Relay", RFC 3070, February 2001.
[RFC3070] Rawat、V.、Tio、R.、Nanji、S。、およびVerma、R。、「Layer Two Tunneling Protocol（L2TP）over Frame Relay」、RFC 3070、2001年2月。
[RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)", RFC 3355, August 2002.
[RFC3355] Singh、A.、Turner、R.、Tio、R。、およびNanji、S。、「ATM Adaptation Layer 5（AAL5）上のLayer Two Tunneling Protocol（L2TP）」、RFC 3355、2002年8月。
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.
[KPS] Kaufman、C.、Perlman、R.、およびSpeciner、M。、「Network Security：Private Communications in a Public World」、Prentice Hall、1995年3月、ISBN 0-13-061466-1。
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9.
[スティーブンス]スティーブンス、Wリチャード、「TCP / IP Illustrated、Volume I：The Protocols」、Addison-Wesley Publishing Company、Inc.、1996年3月、ISBN 0-201-63346-9。
Many of the protocol constructs were originally defined in, and the text of this document began with, RFC 2661, "L2TPv2". RFC 2661 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and B. Palter.
プロトコルコンストラクトの多くは、最初にRFC 2661、「L2TPv2」で定義され、このドキュメントのテキストで始まりました。 RFC 2661の作成者は、W。タウンズリー、A。バレンシア、A。ルーベンス、G。ポール、G。ゾーン、およびB.パルターです。
The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn.
L2TPの基本概念とそのプロトコル構成の多くは、L2F [RFC2341]とPPTP [RFC2637]から採用されました。これらのバージョンの作成者は、A。バレンシア、M。リトルウッド、T。コラー、K。ハムゼ、G。ポール、W。ヴェルテイン、J。タールド、W。リトル、およびG.ゾーンです。
Danny Mcpherson and Suhail Nanji published the first "L2TP Service Type" version, which defined the use of L2TP for tunneling of various L2 payload types (initially, Ethernet and Frame Relay).
Danny McphersonとSuhail Nanjiは、さまざまなL2ペイロードタイプ（最初はイーサネットとフレームリレー）のトンネリングにL2TPを使用することを定義した最初の「L2TPサービスタイプ」バージョンを公開しました。
The team for splitting RFC 2661 into this base document and the companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided very helpful review and comment.
RFC 2661をこのベースドキュメントと関連するPPPドキュメントに分割するチームは、Ignacio Goyret、Jed Lau、Bill Palter、Mark Townsley、およびMadhvi Vermaで構成されていました。 Skip Boothも非常に役立つレビューとコメントを提供しました。
Some constructs of L2TPv3 were based in part on UTI (Universal Transport Interface), which was originally conceived by Peter Lothberg and Tony Bates.
L2TPv3の一部の構成要素は、一部はUTI（Universal Transport Interface）に基づいていました。これは、もともとはPeter LothbergとTony Batesによって考案されました。
Stewart Bryant and Simon Barber provided valuable input for the L2TPv3 over IP header.
Stewart BryantとSimon Barberは、L2TPv3 over IPヘッダーに貴重な入力を提供しました。
Juha Heinanen provided helpful review in the early stages of this effort.
Juha Heinanenは、この取り組みの初期段階で役立つレビューを提供しました。
Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth and Maria Dos Santos contributed to the Control Message Authentication Mechanism as well as general discussions of security.
Jan Vilhuber、Scott Fluhrer、David McGrew、Scott Wainner、Skip Booth、およびMaria Dos Santosは、セキュリティの一般的な議論だけでなく、制御メッセージ認証メカニズムにも貢献しました。
James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted Hardie, and Pekka Savola provided very helpful review of the final versions of text.
James Carlson、Thomas Narten、Maria Dos Santos、Steven Bellovin、Ted Hardie、およびPekka Savolaは、テキストの最終版について非常に役立つレビューを提供してくれました。
Russ Housley provided valuable review and comment on security, particularly with respect to the Control Message Authentication mechanism.
Russ Housleyは、特に制御メッセージ認証メカニズムに関して、セキュリティに関する貴重なレビューとコメントを提供しました。
Pekka Savola contributed to proper alignment with IPv6 and inspired much of Section 4.1.4 on fragmentation.
Pekka SavolaはIPv6との適切な連携に貢献し、断片化に関するセクション4.1.4の多くに影響を与えました。
Aside of his original influence and co-authorship of RFC 2661, Glen Zorn helped get all of the language and character references straight in this document.
RFC 2661の元々の影響力と共著の他に、グレンゾーンは、このドキュメントですべての言語と文字の参照を直接取得するのに役立ちました。
A number of people provided valuable input and effort for RFC 2661, on which this document was based:
このドキュメントのベースとなったRFC 2661には、多くの人々が貴重な情報と努力を提供してくれました。
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL, which led to improvement of the overall readability and clarity of RFC 2661.
John Bray、Greg Burns、Rich Garrett、Don Grosser、Matt Holdrege、Terry Johnson、Dory Leifer、Rich Sheaは、フロリダ州オーランドの第43回IETFで貴重な意見とレビューを提供し、全体的な可読性とRFCの明確性を改善しました。 2661。
Thomas Narten provided a great deal of critical review and formatting. He wrote the first version of the IANA Considerations section.
Thomas Nartenは、多くの重要なレビューとフォーマットを提供しました。彼はIANAの考慮事項セクションの最初のバージョンを書きました。
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of early versions leading to RFC 2661.
Dory Leiferは、L2TPのプロトコル定義に貴重な改良を加え、RFC 2661につながる初期バージョンの編集に貢献しました。
Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the original endpoint authentication mechanism.
Steve CobbとEvan Cavesは、ステートマシンテーブルを再設計しました。 Barney Wolffは、元のエンドポイント認証メカニズムに多くの設計入力を提供しました。
Appendix A: Control Slow Start and Congestion Avoidance
付録A：スロースタートと輻輳回避の制御
Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS] (this algorithm is also described in [RFC2581]).
それぞれの側で受信ウィンドウの最大サイズが示されていますが、制御パケットの送信にはスロースタートと輻輳回避の方法を使用することをお勧めします。ここで説明する方法は、TCP / IP Illustrated、Volume I、W。Richard Stevens [STEVENS]のセクション21.6で説明されているTCP輻輳回避アルゴリズムに基づいています（このアルゴリズムは[RFC2581]でも説明されています）。
Slow start and congestion avoidance make use of several variables. The congestion window (CWND) defines the number of packets a sender may send before waiting for an acknowledgment. The size of CWND expands and contracts as described below. Note, however, that CWND is never allowed to exceed the size of the advertised window obtained from the Receive Window AVP. (In the text below, it is assumed any increase will be limited by the Receive Window Size.) The variable SSTHRESH determines when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH.
スロースタートと輻輳回避は、いくつかの変数を利用します。輻輳ウィンドウ（CWND）は、確認応答を待機する前に送信者が送信できるパケットの数を定義します。 CWNDのサイズは、以下で説明するように拡大および縮小します。ただし、CWNDは、Receive Window AVPから取得したアドバタイズされたウィンドウのサイズを超えることはできません。 （下のテキストでは、増加は受信ウィンドウサイズによって制限されると想定されています。）変数SSTHRESHは、送信者がスロースタートから輻輳回避に切り替えるタイミングを決定します。 CWNDがSSHTRESH未満の場合、スロースタートが使用されます。
A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgment (either explicit or piggybacked). When the acknowledgment is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ACK message or piggybacked) is received. Increasing CWND by one on each ACK has the effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins.
送信者はスロースタートフェーズで開始します。 CWNDは1つのパケットに初期化され、SSHTRESHはアドバタイズされたウィンドウ（受信ウィンドウAVPから取得）に初期化されます。次に、送信側は1つのパケットを送信し、その確認応答（明示的またはピギーバック）を待ちます。確認応答を受信すると、輻輳ウィンドウが1から2に増加します。スロースタート中、CWNDは、ACK（明示的なACKメッセージまたはピギーバック）が受信されるたびに1パケットずつ増加します。各ACKでCWNDを1ずつ増やすと、ラウンドトリップごとにCWNDが2倍になり、指数関数的に増加します。 CWNDの値がSSHTRESHに達すると、スロースタートフェーズが終了し、輻輳回避フェーズが始まります。
During congestion avoidance, CWND expands more slowly. Specifically, it increases by 1/CWND for every new ACK received. That is, CWND is increased by one packet after CWND new ACKs have been received. Window expansion during the congestion avoidance phase is effectively linear, with CWND increasing by one packet each round trip.
輻輳回避中、CWNDはよりゆっくりと拡張します。具体的には、新しいACKを受信するたびに1 / CWNDずつ増加します。つまり、CWNDは、CWNDの新しいACKが受信された後に1パケット増加します。輻輳回避フェーズ中のウィンドウ拡張は実質的に線形であり、CWNDは往復ごとに1パケットずつ増加します。
When congestion occurs (indicated by the triggering of a retransmission) one-half of the CWND is saved in SSTHRESH, and CWND is set to one. The sender then reenters the slow start phase.
輻輳が発生すると（再送信のトリガーによって示されます）、CWNDの半分がSSTHRESHに保存され、CWNDが1に設定されます。その後、送信側はスロースタートフェーズに入ります。
Appendix B: Control Message Examples
付録B：コントロールメッセージの例
B.1: Lock-Step Control Connection Establishment
B.1：ロックステップ制御接続の確立
In this example, an LCCE establishes a control connection, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within an ACK message. An alternative would be to piggyback the acknowledgment within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the control connection.
この例では、LCCEは制御接続を確立します。交換には、メッセージの送信で両側が交互に行われます。この例は、ACKメッセージ内で明示的に送信される最後の確認応答を示しています。別の方法としては、ICRQまたはOCRQへの応答として送信されるメッセージ内で確認応答を便乗させることで、制御接続を開始した側から続く可能性があります。
LCCE A LCCE B
------ ------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ACK
Nr: 2, Ns: 1
B.2: Lost Packet with Retransmission
B.2：再送信で失われたパケット
An existing control connection has a new session requested by LCCE A. The ICRP is lost and must be retransmitted by LCCE B. Note that loss of the ICRP has two effects: It not only keeps the upper level state machine from progressing, but also keeps LCCE A from seeing a timely lower level acknowledgment of its ICRQ.
既存の制御接続には、LCCE Aによって要求された新しいセッションがあります。ICRPは失われ、LCCE Bによって再送信する必要があります。ICRPが失われると、次の2つの影響があることに注意してください。 LCCE Aは、そのICRQのタイムリーに低いレベルの確認を確認しません。
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LCCE A's timer started first, so fires first)
（一時停止。LCCEAのタイマーが最初に開始されるため、最初に起動します）
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet, LCCE B discards the packet and sends an ACK message)
（LCCE Bはこのパケットをすでに認識していることに気づき、パケットを破棄してACKメッセージを送信します）
<- ACK Nr: 3, Ns: 2
<-ACK No：3、Ns：2
(LCCE B's retransmit timer fires)
（LCCE Bの再送信タイマーが作動）
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ACK Nr: 4, Ns: 2
<-ACK No：4、Ns：2
Appendix C: Processing Sequence Numbers
付録C：シーケンス番号の処理
The Default L2-Specific Sublayer, defined in Section 4.6, provides a 24-bit field for sequencing of data packets within an L2TP session. L2TP data packets are never retransmitted, so this sequence is used only to detect packet order, duplicate packets, or lost packets.
セクション4.6で定義されているデフォルトのL2固有のサブレイヤーは、L2TPセッション内のデータパケットのシーケンス用に24ビットフィールドを提供します。 L2TPデータパケットは再送信されないため、このシーケンスは、パケットの順序、重複パケット、または失われたパケットを検出するためにのみ使用されます。
The 24-bit Sequence Number field of the Default L2-Specific Sublayer contains a packet sequence number for the associated session. Each sequenced data packet that is sent must contain the sequence number, incremented by one, of the previous sequenced packet sent on a given L2TP session. Upon receipt, any packet with a sequence number equal to or greater than the current expected packet (the last received in-order packet plus one) should be considered "new" and accepted. All other packets are considered "old" or "duplicate" and discarded. Note that the 24-bit sequence number space includes zero as a valid sequence number (as such, it may be implemented with a masked 32-bit counter if desired). All new sessions MUST begin sending sequence numbers at zero.
デフォルトのL2固有サブレイヤーの24ビットのシーケンス番号フィールドには、関連付けられたセッションのパケットシーケンス番号が含まれています。送信されるシーケンスされた各データパケットには、所定のL2TPセッションで送信された以前のシーケンスされたパケットのシーケンス番号が1ずつ増加したものが含まれている必要があります。受信時に、シーケンス番号が現在の予想パケット（最後に受信した順序付きパケットに1を加えたもの）以上のパケットは「新規」と見なされ、受け入れられます。他のすべてのパケットは「古い」または「重複」と見なされ、破棄されます。 24ビットのシーケンス番号スペースには、有効なシーケンス番号としてゼロが含まれていることに注意してください（したがって、必要に応じて、マスクされた32ビットカウンターを使用して実装できます）。新しいセッションはすべて、シーケンス番号の送信をゼロから開始する必要があります。
Larger or smaller sequence number fields are possible with L2TP if an alternative format to the Default L2-Specific Sublayer defined in this document is used. While 24 bits may be adequate in a number of circumstances, a larger sequence number space will be less susceptible to sequence number wrapping problems for very high session data rates across long dropout periods. The sequence number processing recommendations below should hold for any size sequence number field.
このドキュメントで定義されているデフォルトのL2固有のサブレイヤーの代替フォーマットが使用されている場合、L2TPではより大きいまたは小さいシーケンス番号フィールドが可能です。多くの状況では24ビットで十分ですが、シーケンス番号スペースが大きいほど、長いドロップアウト期間にわたって非常に高いセッションデータレートでシーケンス番号の折り返しの問題が発生しにくくなります。以下のシーケンス番号処理の推奨事項は、任意のサイズのシーケンス番号フィールドに適用できます。
When detecting whether a packet sequence number is "greater" or "less" than a given sequence number value, wrapping of the sequence number must be considered. This is typically accomplished by keeping a window of sequence numbers beyond the current expected sequence number for determination of whether a packet is "new" or not. The window may be sized based on the link speed and sequence number space and SHOULD be configurable with a default equal to one half the size of the available number space (e.g., 2^(n-1), where n is the number of bits available in the sequence number).
パケットのシーケンス番号が特定のシーケンス番号値よりも「大きい」か「小さい」かを検出する場合は、シーケンス番号の折り返しを考慮する必要があります。これは通常、パケットが「新しい」かどうかを判断するために、現在のシーケンス番号を超えるシーケンス番号のウィンドウを保持することによって実現されます。ウィンドウは、リンク速度とシーケンス番号スペースに基づいてサイズを設定できます。デフォルトでは、利用可能な番号スペースのサイズの半分に等しい値（例：2 ^（n-1）、nはビット数）で構成可能である必要があります。シーケンス番号で利用可能）。
Upon receipt, packets that exactly match the expected sequence number are processed immediately and the next expected sequence number incremented. Packets that fall within the window for new packets may either be processed immediately and the next expected sequence number updated to one plus that received in the new packet, or held for a very short period of time in hopes of receiving the missing packet(s). This "very short period" should be configurable, with a default corresponding to a time lapse that is at least an order of magnitude less than the retransmission timeout periods of higher layer protocols such as TCP.
受信すると、予想されるシーケンス番号と完全に一致するパケットがすぐに処理され、次に予想されるシーケンス番号が増分されます。新しいパケットのウィンドウ内にあるパケットは、すぐに処理され、次に予想されるシーケンス番号が新しいパケットで受信したものに1を加えたものに更新されるか、欠落したパケットを受信することを期待して非常に短い期間保持されます。 。この「非常に短い期間」は構成可能である必要があり、デフォルトは、TCPなどの上位層プロトコルの再送信タイムアウト期間よりも少なくとも1桁短い経過時間に対応しています。
For typical transient packet mis-orderings, dropping out-of-order packets alone should suffice and generally requires far less resources than actively reordering packets within L2TP. An exception is a case in which a pair of packet fragments are persistently retransmitted and sent out-of-order. For example, if an IP packet has been fragmented into a very small packet followed by a very large packet before being tunneled by L2TP, it is possible (though admittedly wrong) that the two resulting L2TP packets may be consistently mis-ordered by the PSN in transit between L2TP nodes. If sequence numbers were being enforced at the receiving node without any buffering of out-of-order packets, then the fragmented IP packet may never reach its destination. It may be worth noting here that this condition is true for any tunneling mechanism of IP packets that includes sequence number checking on receipt (i.e., GRE [RFC2890]).
典型的な一時的なパケットの誤った順序付けの場合、順序が正しくないパケットをドロップするだけで十分であり、一般に、L2TP内でパケットをアクティブに並べ替えるよりもはるかに少ないリソースが必要です。例外は、1組のパケットフラグメントが永続的に再送信され、順不同で送信される場合です。たとえば、L2TPによってトンネリングされる前に、IPパケットが非常に小さなパケットに断片化された後に非常に大きなパケットが続く場合、2つの結果のL2TPパケットがPSNによって一貫して誤った順序になる可能性があります（確かに間違っています） L2TPノード間で転送中。シーケンス番号が順不同のパケットをバッファリングせずに受信ノードで適用されていた場合、フラグメント化されたIPパケットが宛先に到達しない可能性があります。この条件は、受信時のシーケンス番号チェック（GRE [RFC2890]など）を含むIPパケットのトンネリングメカニズムすべてに当てはまることに注意してください。
Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only non-IP data packets require sequencing) allows IP data packets being tunneled by L2TP to not utilize sequence numbers, while utilizing sequence numbers and enforcing packet order for any remaining non-IP data packets. Depending on the requirements of the link layer being tunneled and the network data traversing the data link, this is sufficient in many cases to enforce packet order on frames that require it (such as end-to-end data link control messages), while not on IP packets that are known to be resilient to packet reordering.
データシーケンスレベル（セクション5.4.3を参照）を1にすると（非IPデータパケットのみがシーケンス処理を必要とする）、L2TPによってトンネリングされているIPデータパケットはシーケンス番号を利用せず、シーケンス番号を利用して残りのパケットの順序を強制できます。非IPデータパケット。トンネリングされるリンクレイヤーとデータリンクを通過するネットワークデータの要件に応じて、パケットオーダーを必要とするフレーム（エンドツーエンドのデータリンクコントロールメッセージなど）にパケットの順序を適用するには、多くの場合これで十分ですが、パケットの並べ替えに耐性があることがわかっているIPパケット。
If a large number of packets (i.e., more than one new packet window) are dropped due to an extended outage or loss of sequence number state on one side of the connection (perhaps as part of a forwarding plane reset or failover to a standby node), it is possible that a large number of packets will be sent in-order, but be wrongly detected by the peer as out-of-order. This can be generally characterized for a window size, w, sequence number space, s, and number of packets lost in transit between L2TP endpoints, p, as follows: If s > p > w, then an additional (s - p) packets that were otherwise received in-order, will be incorrectly classified as out-of-order and dropped. Thus, for a sequence number space, s = 128, window size, w = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional packets would be dropped after the outage until the sequence number wrapped back to the current expected next sequence number.
接続の一方の側で長時間の停止またはシーケンス番号の状態が失われたために多数のパケット（つまり、複数の新しいパケットウィンドウ）がドロップされた場合（おそらく転送プレーンのリセットまたはスタンバイノードへのフェイルオーバーの一部として） ）、大量のパケットが順番どおりに送信されても、ピアによって順番が間違っていると誤って検出される可能性があります。これは一般に、ウィンドウサイズw、シーケンス番号スペースs、およびL2TPエンドポイント間の転送中に失われたパケット数pについて次のように特徴付けることができます。s> p> wの場合、追加の（s-p）パケットそれ以外は順序どおりに受信されたものは、誤って順序外として分類され、削除されます。したがって、シーケンス番号スペースの場合、s = 128、ウィンドウサイズ、w = 64、および失われたパケットの数p = 70。 128-70 =停止後、シーケンス番号が現在予期されている次のシーケンス番号に戻るまで、58個の追加パケットがドロップされます。
To mitigate this additional packet loss, one MUST inspect the sequence numbers of packets dropped due to being classified as "old" and reset the expected sequence number accordingly. This may be accomplished by counting the number of "old" packets dropped that were in sequence among themselves and, upon reaching a threshold, resetting the next expected sequence number to that seen in the arriving data packets. Packet timestamps may also be used as an indicator to reset the expected sequence number by detecting a period of time over which "old" packets have been received in-sequence. The ideal thresholds will vary depending on link speed, sequence number space, and link tolerance to out-of-order packets, and MUST be configurable.
この追加のパケット損失を軽減するには、「古い」として分類されているためにドロップされたパケットのシーケンス番号を検査し、それに応じて予期されるシーケンス番号をリセットする必要があります。これは、ドロップされた「古い」パケットの数を数えることで達成でき、しきい値に達したときに、次の予期されるシーケンス番号を、到着するデータパケットで見られるものにリセットします。パケットのタイムスタンプは、「古い」パケットが順番に受信された期間を検出することにより、予想されるシーケンス番号をリセットするインジケータとして使用することもできます。理想的なしきい値は、リンク速度、シーケンス番号スペース、および異常パケットへのリンク許容度によって異なり、構成可能でなければなりません。
Editors' Addresses
編集者のアドレス
Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134
Jed Lau cisco Systems 170 W. Tasman Drive San Jose、CA 95134
EMail: jedlau@cisco.com
W. Mark Townsley cisco Systems
W.マークタウンズリーシスコシステムズ
EMail: mark@townsley.net
Ignacio Goyret Lucent Technologies
Ignacio Goyret Lucent Technologies
EMail: igoyret@lucent.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または組織（ある場合）、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に後援します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。