[要約] RFC 2661は、L2TP（Layer Two Tunneling Protocol）の仕様を定義しており、異なるネットワーク間で仮想的なトンネルを作成するためのプロトコルです。L2TPは、セキュアな通信やリモートアクセスなどの目的で使用されます。
Network Working Group W. Townsley
Request for Comments: 2661 A. Valencia
Category: Standards Track cisco Systems
A. Rubens
Ascend Communications
G. Pall
G. Zorn
Microsoft Corporation
B. Palter
Redback Networks
August 1999
Layer Two Tunneling Protocol "L2TP"
レイヤー2つのトンネルプロトコル「L2TP」
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This document describes the Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.
このドキュメントでは、レイヤー2トンネリングプロトコル（L2TP）について説明します。STD 51、RFC 1661は、PPP [RFC1661]を介してマルチプロトコルアクセスを指定します。L2TPは、エンドユーザーとアプリケーションの両方に可能な限り透明な方法で、介在するネットワーク全体でPPPパケットのトンネルを促進します。
Table of Contents
目次
1.0 Introduction.......................................... 3
1.1 Specification of Requirements......................... 4
1.2 Terminology........................................... 4
2.0 Topology.............................................. 8
3.0 Protocol Overview..................................... 9
3.1 L2TP Header Format.................................... 9
3.2 Control Message Types................................. 11
4.0 Control Message Attribute Value Pairs................. 12
4.1 AVP Format............................................ 13
4.2 Mandatory AVPs........................................ 14
4.3 Hiding of AVP Attribute Values........................ 14
4.4 AVP Summary........................................... 17
4.4.1 AVPs Applicable To All Control Messages.......... 17
4.4.2 Result and Error Codes........................... 18
4.4.3 Control Connection Management AVPs............... 20
4.4.4 Call Management AVPs............................. 27
4.4.5 Proxy LCP and Authentication AVPs................ 34
4.4.6 Call Status AVPs................................. 39
5.0 Protocol Operation.................................... 41
5.1 Control Connection Establishment...................... 41
5.1.1 Tunnel Authentication............................ 42
5.2 Session Establishment................................. 42
5.2.1 Incoming Call Establishment...................... 42
5.2.2 Outgoing Call Establishment...................... 43
5.3 Forwarding PPP Frames................................. 43
5.4 Using Sequence Numbers on the Data Channel............ 44
5.5 Keepalive (Hello)..................................... 44
5.6 Session Teardown...................................... 45
5.7 Control Connection Teardown........................... 45
5.8 Reliable Delivery of Control Messages................. 46
6.0 Control Connection Protocol Specification............. 48
6.1 Start-Control-Connection-Request (SCCRQ).............. 48
6.2 Start-Control-Connection-Reply (SCCRP)................ 48
6.3 Start-Control-Connection-Connected (SCCCN)............ 49
6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
6.5 Hello (HELLO)......................................... 49
6.6 Incoming-Call-Request (ICRQ).......................... 50
6.7 Incoming-Call-Reply (ICRP)............................ 51
6.8 Incoming-Call-Connected (ICCN)........................ 51
6.9 Outgoing-Call-Request (OCRQ).......................... 52
6.10 Outgoing-Call-Reply (OCRP)........................... 53
6.11 Outgoing-Call-Connected (OCCN)....................... 53
6.12 Call-Disconnect-Notify (CDN)......................... 53
6.13 WAN-Error-Notify (WEN)............................... 54
6.14 Set-Link-Info (SLI).................................. 54
7.0 Control Connection State Machines..................... 54
7.1 Control Connection Protocol Operation................. 55
7.2 Control Connection States............................. 56
7.2.1 Control Connection Establishment................. 56
7.3 Timing considerations................................. 58
7.4 Incoming calls........................................ 58
7.4.1 LAC Incoming Call States......................... 60
7.4.2 LNS Incoming Call States......................... 62
7.5 Outgoing calls........................................ 63
7.5.1 LAC Outgoing Call States......................... 64
7.5.2 LNS Outgoing Call States......................... 66
7.6 Tunnel Disconnection.................................. 67
8.0 L2TP Over Specific Media.............................. 67
8.1 L2TP over UDP/IP...................................... 68
8.2 IP.................................................... 69
9.0 Security Considerations............................... 69
9.1 Tunnel Endpoint Security.............................. 70
9.2 Packet Level Security................................. 70
9.3 End to End Security................................... 70
9.4 L2TP and IPsec........................................ 71
9.5 Proxy PPP Authentication.............................. 71
10.0 IANA Considerations.................................. 71
10.1 AVP Attributes....................................... 71
10.2 Message Type AVP Values.............................. 72
10.3 Result Code AVP Values............................... 72
10.3.1 Result Code Field Values........................ 72
10.3.2 Error Code Field Values......................... 72
10.4 Framing Capabilities & Bearer Capabilities........... 72
10.5 Proxy Authen Type AVP Values......................... 72
10.6 AVP Header Bits...................................... 73
11.0 References........................................... 73
12.0 Acknowledgments...................................... 74
13.0 Authors' Addresses................................... 75
Appendix A: Control Channel Slow Start and Congestion
Avoidance..................................... 76
Appendix B: Control Message Examples...................... 77
Appendix C: Intellectual Property Notice.................. 79
Full Copyright Statement.................................. 80
PPP [RFC1661] defines an encapsulation mechanism for transporting multiprotocol packets across layer 2 (L2) point-to-point links. Typically, a user obtains a L2 connection to a Network Access Server (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, ADSL, etc.) and then runs PPP over that connection. In such a configuration, the L2 termination point and PPP session endpoint reside on the same physical device (i.e., the NAS).
PPP [RFC1661]は、レイヤー2（L2）ポイントツーポイントリンクを横切ってマルチプロトコルパケットを輸送するためのカプセル化メカニズムを定義します。通常、ユーザーは、多くの手法（ダイヤルアップポット、ISDN、ADSLなど）のいずれかを使用してネットワークアクセスサーバー（NAS）へのL2接続を取得し、その接続でPPPを実行します。このような構成では、L2終端ポイントとPPPセッションのエンドポイントは、同じ物理デバイス（つまり、NAS）に存在します。
L2TP extends the PPP model by allowing the L2 and PPP endpoints to reside on different devices interconnected by a packet-switched network. With L2TP, a user has an L2 connection to an access concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the concentrator then tunnels individual PPP frames to the NAS. This allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit.
L2TPは、L2およびPPPエンドポイントをパケットスイッチネットワークによって相互接続されたさまざまなデバイスに存在できるようにすることにより、PPPモデルを拡張します。L2TPを使用すると、ユーザーはアクセスコンセントレーター（モデム銀行、ADSL DSLAMなど）へのL2接続を持ち、その後、個々のPPPフレームがNASにトンネルになります。これにより、PPPパケットの実際の処理をL2回路の終了から離婚させることができます。
One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require a long-distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over a shared infrastructure such as frame relay circuit or the Internet. From the user's perspective, there is no functional difference between having the L2 circuit terminate in a NAS directly or using L2TP.
このような分離の明らかな利点の1つは、L2接続がNASで終了する必要がある代わりに（長距離ストトル料金が必要になる場合がある場合がある場合）、接続が（ローカル）回路濃縮器で終了し、論理PPPセッションを拡張する可能性があることです。フレームリレー回路やインターネットなどの共有インフラストラクチャを介して。ユーザーの観点からは、L2回路を直接NASで終了させるか、L2TPを使用することとの間に機能的な違いはありません。
L2TP may also solve the multilink hunt-group splitting problem. Multilink PPP [RFC1990] requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Due to its ability to project a PPP session to a location other than the point at which it was physically received, L2TP can be used to make all channels terminate at a single NAS. This allows multilink operation even when the calls are spread across distinct physical NASs.
L2TPは、マルチリンクハントグループの分割問題を解決する場合があります。MultiLink PPP [RFC1990]では、Multilink Bundleを構成するすべてのチャネルを単一のネットワークアクセスサーバー（NAS）にグループ化する必要があります。PPPセッションを物理的に受信したポイント以外の場所に投影する機能により、L2TPを使用してすべてのチャネルを単一のNASで終了させることができます。これにより、呼び出しが異なる物理NASSに広がっている場合でも、マルチリンク操作が可能になります。
This document defines the necessary control protocol for on-demand creation of tunnels between two nodes and the accompanying encapsulation for multiplexing multiple, tunneled PPP sessions.
このドキュメントでは、2つのノード間のトンネルのオンデマンド作成に必要な制御プロトコルと、複数のトンネルPPPセッションを多重化するための添付のカプセル化が定義されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Analog Channel
アナログチャネル
A circuit-switched communication path which is intended to carry 3.1 kHz audio in each direction.
各方向に3.1 kHzのオーディオを携帯することを目的としたサーキットスイッチ通信パス。
Attribute Value Pair (AVP)
属性値ペア（AVP）
The variable length concatenation of a unique Attribute (represented by an integer) and a Value containing the actual value identified by the attribute. Multiple AVPs make up Control Messages which are used in the establishment, maintenance, and teardown of tunnels.
一意の属性（整数で表される）の変数長の連結と、属性によって識別される実際の値を含む値。複数のAVPは、トンネルの確立、メンテナンス、および分解で使用される制御メッセージを構成します。
Call
電話
A connection (or attempted connection) between a Remote System and LAC. For example, a telephone call through the PSTN. A Call (Incoming or Outgoing) which is successfully established between a Remote System and LAC results in a corresponding L2TP Session within a previously established Tunnel between the LAC and LNS. (See also: Session, Incoming Call, Outgoing Call).
リモートシステムとLACの間の接続（または試行された接続）。たとえば、PSTNを介した電話。リモートシステムとLACの間に正常に確立されるコール（着信または発信）により、以前に確立されたトンネル内でLACとLNSの間のトンネル内で対応するL2TPセッションが行われます。（参照：セッション、着信、発信コール）。
Called Number
番号と呼ばれます
An indication to the receiver of a call as to what telephone number the caller used to reach it.
発信者がそれに到達するために使用した電話番号についての通話の受信者への兆候。
Calling Number
通話番号
An indication to the receiver of a call as to the telephone number of the caller.
発信者の電話番号に関する通話の受信者への兆候。
CHAP
チャップ
Challenge Handshake Authentication Protocol [RFC1994], a PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line.
チャレンジハンドシェイク認証プロトコル[RFC1994]、ClearTextパスワードが行上に渡されないPPP暗号化チャレンジ/応答認証プロトコル。
Control Connection
制御接続
A control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of the tunnel itself.
セッションとトンネル自体の施設、リリース、およびメンテナンスを制御するために、トンネル上で帯域内で動作します。
Control Messages
コントロールメッセージ
Control messages are exchanged between LAC and LNS pairs, operating in-band within the tunnel protocol. Control messages govern aspects of the tunnel and sessions within the tunnel.
コントロールメッセージは、トンネルプロトコル内で帯域内の帯域を操作し、LACとLNSペアの間で交換されます。コントロールメッセージは、トンネル内のトンネルとセッションの側面を管理します。
Digital Channel
デジタルチャネル
A circuit-switched communication path which is intended to carry digital information in each direction.
各方向にデジタル情報を運ぶことを目的としたサーキットスイッチの通信パス。
DSLAM
dslam
Digital Subscriber Line (DSL) Access Module. A network device used in the deployment of DSL service. This is typically a concentrator of individual DSL lines located in a central office (CO) or local exchange.
デジタルサブスクライバーライン（DSL）アクセスモジュール。DSLサービスの展開に使用されるネットワークデバイス。これは通常、中央のオフィス（CO）またはローカル交換にある個々のDSLラインの濃縮器です。
Incoming Call
電話の着信
A Call received at an LAC to be tunneled to an LNS (see Call, Outgoing Call).
LNSにトンネリングされるために、LACで受け取ったコール（コール、発信コールを参照）。
L2TP Access Concentrator (LAC)
L2TPアクセス濃縮器（LAC）
A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Network Server (LNS). The LAC sits between an LNS and a remote system and forwards packets to and from each. Packets sent from the LAC to the LNS requires tunneling with the L2TP protocol as defined in this document. The connection from the LAC to the remote system is either local (see: Client LAC) or a PPP link.
L2TPトンネルエンドポイントの片側として機能し、L2TPネットワークサーバー（LNS）のピアであるノード。LACはLNSとリモートシステムの間にあり、それぞれからパケットを転送します。LACからLNSに送信されたパケットには、このドキュメントで定義されているように、L2TPプロトコルを使用したトンネリングが必要です。LACからリモートシステムへの接続は、ローカル（クライアントLACを参照）またはPPPリンクのいずれかです。
L2TP Network Server (LNS)
L2TPネットワークサーバー（LNS）
A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Access Concentrator (LAC). The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC.
L2TPトンネルエンドポイントの片側として機能し、L2TPアクセス濃縮器（LAC）のピアであるノード。LNSは、LACによってリモートシステムからトンネル化されているPPPセッションの論理終了点です。
Management Domain (MD)
管理ドメイン（MD）
A network or networks under the control of a single administration, policy or system. For example, an LNS's Management Domain might be the corporate network it serves. An LAC's Management Domain might be the Internet Service Provider that owns and manages it.
単一の管理、ポリシー、またはシステムの管理下にあるネットワークまたはネットワーク。たとえば、LNSの管理ドメインは、それが提供するコーポレートネットワークである可能性があります。LACの管理ドメインは、それを所有および管理するインターネットサービスプロバイダーかもしれません。
Network Access Server (NAS)
ネットワークアクセスサーバー（NAS）
A device providing local network access to users across a remote access network such as the PSTN. An NAS may also serve as an LAC, LNS or both.
PSTNなどのリモートアクセスネットワークを介してユーザーへのローカルネットワークアクセスを提供するデバイス。NASは、LAC、LNS、またはその両方としても機能する場合があります。
Outgoing Call
発信コール
A Call placed by an LAC on behalf of an LNS (see Call, Incoming Call).
LNSに代わってLACによって配置されたコール（コール、着信コールを参照）。
Peer
ピア
When used in context with L2TP, peer refers to either the LAC or LNS. An LAC's Peer is an LNS and vice versa. When used in context with PPP, a peer is either side of the PPP connection.
L2TPでコンテキストで使用する場合、ピアはLACまたはLNSのいずれかを参照します。LACのピアはLNSであり、その逆も同様です。PPPを使用してコンテキストで使用する場合、ピアはPPP接続の両側です。
POTS
ポット
Plain Old Telephone Service.
普通の古い電話サービス。
Remote System
リモートシステム
An end-system or router attached to a remote access network (i.e. a PSTN), which is either the initiator or recipient of a call. Also referred to as a dial-up or virtual dial-up client.
リモートアクセスネットワーク（つまり、PSTN）に接続されたエンドシステムまたはルーター。これは、コールのイニシエーターまたは受信者です。ダイヤルアップまたは仮想ダイヤルアップクライアントとも呼ばれます。
Session
セッション
L2TP is connection-oriented. The LNS and LAC maintain state for each Call that is initiated or answered by an LAC. An L2TP Session is created between the LAC and LNS when an end-to-end PPP connection is established between a Remote System and the LNS. Datagrams related to the PPP connection are sent over the Tunnel between the LAC and LNS. There is a one to one relationship between established L2TP Sessions and their associated Calls. (See also: Call).
L2TPは接続指向です。LNSとLACは、LACによって開始または回答される各コールの状態を維持します。リモートシステムとLNSの間にエンドツーエンドのPPP接続が確立されると、LACとLNSの間にL2TPセッションが作成されます。PPP接続に関連するデータグラムは、LACとLNSの間のトンネル上に送信されます。確立されたL2TPセッションと関連する呼び出しの間には、1対1の関係があります。（参照：電話）。
Tunnel
トンネル
A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a Control Connection and zero or more L2TP Sessions. The Tunnel carries encapsulated PPP datagrams and Control Messages between the LAC and the LNS.
LAC-LNSペアの間にトンネルが存在します。トンネルは、制御接続とゼロ以上のL2TPセッションで構成されています。トンネルには、カプセル化されたPPPデータグラムとLACとLNSの間のコントロールメッセージが含まれています。
Zero-Length Body (ZLB) Message
ゼロレングスボディ（ZLB）メッセージ
A control packet with only an L2TP header. ZLB messages are used for explicitly acknowledging packets on the reliable control channel.
L2TPヘッダーのみを備えたコントロールパケット。ZLBメッセージは、信頼できる制御チャネル上のパケットを明示的に確認するために使用されます。
The following diagram depicts a typical L2TP scenario. The goal is to tunnel PPP frames between the Remote System or LAC Client and an LNS located at a Home LAN.
次の図は、典型的なL2TPシナリオを示しています。目標は、リモートシステムまたはLACクライアントとホームLANにあるLNSの間のPPPフレームをトンネルすることです。
[Home LAN]
[LAC Client]----------+ |
____|_____ +--[Host]
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| PSTN |
[Remote]--| Cloud |
[System] | | [Home LAN]
|___________| |
| ______________ +---[Host]
| | | |
[LAC]-------| Frame Relay |---[LNS]-----+
| or ATM Cloud | |
|______________| :
The Remote System initiates a PPP connection across the PSTN Cloud to an LAC. The LAC then tunnels the PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is obtained. The Remote System is provided addresses from the HOME LAN
リモートシステムは、PSTNクラウドを介してLACにPPP接続を開始します。LACは、インターネット、フレームリレー、またはATMクラウドを介したPPP接続をLNSにトンネルし、ホームLANへのアクセスが取得されます。リモートシステムには、ホームLANからアドレスが提供されます
via PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN's Management Domain as if the user were connected to a Network Access Server directly.
PPP NCP交渉を介して。ユーザーがネットワークアクセスサーバーに直接接続されているかのように、認証、承認、および会計がホームLANの管理ドメインによって提供される場合があります。
A LAC Client (a Host which runs L2TP natively) may also participate in tunneling to the Home LAN without use of a separate LAC. In this case, the Host containing the LAC Client software already has a connection to the public Internet. A "virtual" PPP connection is then created and the local L2TP LAC Client software creates a tunnel to the LNS. As in the above case, Addressing, Authentication, Authorization and Accounting will be provided by the Home LAN's Management Domain.
LACクライアント（L2TPをネイティブに実行するホスト）は、別のLACを使用せずにホームLANへのトンネリングにも参加できます。この場合、LACクライアントソフトウェアを含むホストはすでにパブリックインターネットに接続しています。その後、「仮想」PPP接続が作成され、ローカルL2TP LACクライアントソフトウェアがLNSへのトンネルを作成します。上記の場合と同様に、住所、認証、承認、会計がホームLANの管理ドメインによって提供されます。
L2TP utilizes two types of messages, control messages and data messages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used to encapsulate PPP frames being carried over the tunnel. Control messages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are not retransmitted when packet loss occurs.
L2TPは、コントロールメッセージとデータメッセージの2種類のメッセージを使用します。コントロールメッセージは、トンネルとコールの施設、メンテナンス、クリアに使用されます。データメッセージは、トンネルの上に運ばれているPPPフレームのカプセル化に使用されます。コントロールメッセージは、L2TP内の信頼できる制御チャネルを使用して配信を保証します（詳細については、セクション5.1を参照）。パケットの損失が発生した場合、データメッセージは再送信されません。
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
Figure 3.0 L2TP Protocol Structure
図3.0 L2TPプロトコル構造
Figure 3.0 depicts the relationship of PPP frames and Control Messages over the L2TP Control and Data Channels. PPP Frames are passed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, ATM, etc. Control messages are sent over a reliable L2TP Control Channel which transmits packets in-band over the same Packet Transport.
図3.0は、L2TP制御およびデータチャネルに対するPPPフレームとコントロールメッセージの関係を示しています。PPPフレームは、最初にL2TPヘッダー、次にUDP、フレームリレー、ATMなどのパケットトランスポートによってカプセル化された信頼性の低いデータチャネルに渡されます。コントロールメッセージは、同じものにパケットを送信する信頼性の高いL2TP制御チャネルを介して送信されます。パケットトランスポート。
Sequence numbers are required to be present in all control messages and are used to provide reliable delivery on the Control Channel. Data Messages may use sequence numbers to reorder packets and detect lost packets.
シーケンス番号は、すべての制御メッセージに存在する必要があり、制御チャネルで信頼できる配信を提供するために使用されます。データメッセージは、シーケンス番号を使用してパケットを並べ替えて失われたパケットを検出する場合があります。
All values are placed into their respective fields and sent in network order (high order octets first).
すべての値はそれぞれのフィールドに配置され、ネットワークの順序で送信されます（最初に高次オクテット）。
L2TP packets for the control channel and data channel share a common header format. In each case where a field is optional, its space does not exist in the message if the field is marked not present. Note that while optional on data messages, the Length, Ns, and Nr fields marked as optional below, are required to be present on all control messages.
制御チャネルとデータチャネルのL2TPパケットは、共通のヘッダー形式を共有します。フィールドがオプションである場合のいずれの場合も、フィールドが存在しないとマークされている場合、そのスペースはメッセージに存在しません。データメッセージではオプションであるが、以下のオプションとしてマークされた長さ、NS、およびNRフィールドは、すべての制御メッセージに存在する必要があることに注意してください。
This header is formatted:
このヘッダーはフォーマットされています。
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|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.1 L2TP Message Header
図3.1 L2TPメッセージヘッダー
The Type (T) bit indicates the type of message. It is set to 0 for a data message and 1 for a control message.
タイプ（t）ビットはメッセージのタイプを示します。データメッセージの場合は0に設定されており、コントロールメッセージは1に設定されています。
If the Length (L) bit is 1, the Length field is present. This bit MUST be set to 1 for control messages.
長さ（l）ビットが1の場合、長さフィールドが存在します。このビットは、コントロールメッセージに対して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に設定し、着信メッセージで無視する必要があります。
If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. The S bit MUST be set to 1 for control messages.
シーケンスビットが1に設定されている場合、NSおよびNRフィールドが存在します。制御メッセージの場合は、Sビットを1に設定する必要があります。
If the Offset (O) bit is 1, the Offset Size field is present. The O bit MUST be set to 0 (zero) for control messages.
オフセット（o）ビットが1の場合、オフセットサイズフィールドが存在します。制御メッセージの場合、Oビットを0（ゼロ）に設定する必要があります。
If the Priority (P) bit is 1, this data message should receive preferential treatment in its local queuing and transmission. LCP echo requests used as a keepalive for the link, for instance, should generally be sent with this bit set to 1. Without it, a temporary interval of local congestion could result in interference with keepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit MUST be set to 0 for all control messages.
優先度（p）ビットが1の場合、このデータメッセージは、ローカルキューイングと送信で優先的な処理を受ける必要があります。たとえば、リンクのキープライブとして使用されるLCPエコーリクエストは、通常、このビットセットを1に送信する必要があります。それがなければ、局所輻輳の一時的な間隔は、キープライブメッセージへの干渉とリンクの不必要な損失をもたらす可能性があります。この機能は、データメッセージでのみ使用するためです。すべての制御メッセージに対してPビットを0に設定する必要があります。
Ver MUST be 2, indicating the version of the L2TP data message header described in this document. The value 1 is reserved to permit detection of L2F [RFC2341] packets should they arrive intermixed with L2TP packets. Packets received with an unknown Ver field MUST be discarded.
Verは2でなければなりません。このドキュメントで説明されているL2TPデータメッセージヘッダーのバージョンを示します。値1は、L2TPパケットと混合された場合に到着した場合にL2F [RFC2341]パケットの検出を許可するために予約されています。未知のVERフィールドで受信したパケットは破棄する必要があります。
The Length field indicates the total length of the message in octets.
長さフィールドは、オクテットのメッセージの全長を示します。
Tunnel ID indicates the identifier for the control connection. L2TP tunnels are named by identifiers that have local significance only. That is, the same tunnel will be given different Tunnel IDs by each end of the tunnel. Tunnel ID in each message is that of the intended recipient, not the sender. Tunnel IDs are selected and exchanged as Assigned Tunnel ID AVPs during the creation of a tunnel.
トンネルIDは、制御接続の識別子を示します。L2TPトンネルは、局所的な重要性のみを持つ識別子によって名前が付けられています。つまり、同じトンネルには、トンネルの各端から異なるトンネルIDが与えられます。各メッセージのトンネルIDは、送信者ではなく、意図した受信者のIDです。トンネルIDが選択され、トンネルの作成中に割り当てられたトンネルID AVPとして交換されます。
Session ID indicates the identifier for a session within a tunnel. L2TP sessions are named by identifiers that have local significance only. That is, the same session will be given different Session IDs by each end of the session. Session ID in each message is that of the intended recipient, not the sender. Session IDs are selected and exchanged as Assigned Session ID AVPs during the creation of a session.
セッションIDは、トンネル内のセッションの識別子を示します。L2TPセッションは、局所的な重要性のみを持つ識別子によって命名されます。つまり、同じセッションには、セッションの各端までに異なるセッションIDが与えられます。各メッセージのセッションIDは、送信者ではなく、意図した受信者のセッションIDです。セッションIDが選択され、セッションの作成中に割り当てられたセッションID AVPSとして交換されます。
Ns indicates the sequence number for this data or control message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See Section 5.8 and 5.4 for more information on using this field.
NSは、送信される各メッセージに対してゼロから始まり（Modulo 2 ** 16）ゼロから始まり、このデータまたはコントロールメッセージのシーケンス番号を示します。このフィールドの使用の詳細については、セクション5.8および5.4を参照してください。
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). In data messages, Nr is reserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See section 5.8 for more information on using this field in control messages.
NRは、受信する次のコントロールメッセージで予想されるシーケンス番号を示します。したがって、NRは、受信した最後のインターフメッセージのNSに設定されます（Modulo 2 ** 16）。データメッセージでは、NRは予約されており、存在する場合（Sビットで示されているように）、受領時に無視する必要があります。コントロールメッセージでこのフィールドを使用する詳細については、セクション5.8を参照してください。
The Offset Size field, if present, specifies the number of octets past the L2TP header at which the payload data is expected to start. Actual data within the offset padding is undefined. If the offset field is present, the L2TP header ends after the last octet of the offset padding.
オフセットサイズのフィールドは、存在する場合、ペイロードデータが開始されると予想されるL2TPヘッダーを越えてオクテットの数を指定します。オフセットパディング内の実際のデータは未定義です。オフセットフィールドが存在する場合、L2TPヘッダーはオフセットパディングの最後のオクテットの後に終了します。
The Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, that is, messages with the T-bit set to 1.
メッセージタイプAVP（セクション4.4.1を参照）は、送信される特定のタイプのコントロールメッセージを定義します。セクション3.1から、これはコントロールメッセージのみ、つまりTビットが1に設定されているメッセージ用であることを思い出してください。
This document defines the following control message types (see Section 6.1 through 6.14 for details on the construction and use of each message):
このドキュメントでは、次のコントロールメッセージタイプを定義します（各メッセージの構築と使用の詳細については、セクション6.1〜6.14を参照してください）：
Control Connection Management
制御接続管理
0 (reserved)
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 (reserved) 6 (HELLO) Hello
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（やあやあ
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）発信-Call-Request 8（OCRP）Outingover-Call-Reply 9（OCCN）発信コール接続10（ICRQ）受信コールリクエスト11（ICRP）受信コール応答12（ICCN）着信-call-connected13（予約済み）14（cdn）call-disconnect-notify
Error Reporting
エラー報告
15 (WEN) WAN-Error-Notify
15（wen）wan-error-notify
PPP Session Control
PPPセッションコントロール
16 (SLI) Set-Link-Info
16（sli）set-link-info
To maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is used throughout L2TP. This encoding will be termed AVP (Attribute-Value Pair) in the remainder of this document.
相互運用性を可能にしながら拡張性を最大化するために、メッセージタイプとボディをエンコードするための均一な方法がL2TP全体で使用されます。このエンコードは、このドキュメントの残りの部分でAVP（属性値ペア）と呼ばれます。
Each AVP is encoded as:
各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 are a bit mask, describing the general attributes of the AVP.
最初の6ビットは少しマスクで、AVPの一般的な属性を説明しています。
Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
このドキュメントでは2つのビットが定義されており、残りは将来の拡張機能のために予約されています。予約ビットは0に設定する必要があります。1に設定された予約ビットで受信されたAVPは、認識されていないAVPとして扱わなければなりません。
Mandatory (M) bit: Controls the behavior required of an implementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associated with a particular session, the session associated with this message MUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must then continue to be processed as if the AVP had not been present.
必須（m）ビット：認識されていないAVPを受信する実装に必要な動作を制御します。特定のセッションに関連付けられたメッセージ内のMITが認識されていないAVPに設定されている場合、このメッセージに関連付けられたセッションは終了する必要があります。トンネル全体に関連付けられたメッセージ内の認識されていないAVPにMビットが設定されている場合、トンネル全体（および内部のすべてのセッション）を終了する必要があります。Mビットが設定されていない場合、認識されていないAVPを無視する必要があります。その後、AVPが存在していないかのように、制御メッセージを処理し続ける必要があります。
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 4.3 describes the procedure for performing AVP hiding.
Hidden（h）ビット：AVPの属性値フィールドにデータが隠れていることを識別します。この機能は、AVPのClearTextなど、ユーザーパスワードなどの機密データの渡されを回避するために使用できます。セクション4.3では、AVP隠蔽を実行する手順について説明します。
Length: Encodes the number of octets (including the Overall Length and bitmask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets. 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.
長さ：このAVPに含まれるオクテット数（全長およびビットマスクフィールドを含む）の数をエンコードします。長さは、オクテットの属性値フィールドの長さ6として計算できます。フィールド自体は10ビットで、単一の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 their own L2TP extensions can use their own Vendor ID along with private Attribute values, guaranteeing that they will not collide with any other vendor's extensions, nor with 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と属性タイプで示される実際の値です。属性タイプフィールドの直後に続き、長さで示された残りのオクテット（つまり、長さ6オクテットのヘッダー）に対して実行されます。長さが6の場合、このフィールドは存在しません。
Receipt of an unknown AVP that has the M-bit set is catastrophic to the session or tunnel it is associated with. Thus, the M bit should only be defined for AVPs which are absolutely crucial to proper operation of the session or tunnel. Further, in the case where the LAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility of the peer sending the Mandatory AVP to accept fault for causing an non-interoperable situation. Before defining an AVP with the M-bit set, particularly a vendor-specific AVP, be sure that this is the intended consequence.
Mビットセットを持つ未知のAVPの受信は、関連するセッションまたはトンネルに対して壊滅的です。したがって、Mビットは、セッションまたはトンネルの適切な操作に非常に重要なAVPに対してのみ定義する必要があります。さらに、LACまたはLNSがMビットセットで未知のAVPを受け取り、それに応じてセッションまたはトンネルをシャットダウンする場合、それは、非侵入不能を引き起こすための障害を受け入れるために必須のAVPを送信するピアの全責任です状況。MBITセット、特にベンダー固有のAVPでAVPを定義する前に、これが意図した結果であることを確認してください。
When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M-bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message.
Mビットの使用に適切な代替品が存在する場合、それを利用する必要があります。たとえば、特定の拡張子が存在するかどうかを判断するためにMビットセットでAVPを単に送信するだけでなく、リクエストメッセージにAVPを送信し、応答するAVPを返信メッセージに期待することで可用性を識別できます。
Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, such that the AVP is either not sent, or sent with the M-bit not set.
新しいAVP（このドキュメントで定義されていないもの）を使用してM-BITを使用すると、AVPが送信されないか、MBITが設定されていない場合に送信されるように、関連する機能を設定する機能を提供する必要があります。
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 or user IDs.
各AVPのヘッダーのHビットは、AVPの内容がcleartextに隠されているか存在するかを受信ピアに示すメカニズムを提供します。この機能は、ユーザーパスワードやユーザーIDなどの機密制御メッセージデータを非表示にするために使用できます。
The H bit MUST only be set if a shared secret exists between the LAC and LNS. The shared secret is the same secret that is used for tunnel authentication (see Section 5.1.1). If the H bit is set in any AVP(s) in a given control message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1.
Hビットは、LACとLNSの間に共有秘密が存在する場合にのみ設定する必要があります。共有された秘密は、トンネル認証に使用されるのと同じ秘密です（セクション5.1.1を参照）。特定のコントロールメッセージのAVPでHビットが設定されている場合、ランダムベクトルAVPもメッセージに存在する必要があり、Hビット1を持つ最初のAVPの前に存在する必要があります。
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 a Hidden AVP Subformat as follows:
AVP値を隠すことは、いくつかのステップで行われます。最初のステップは、元の（ClearText）AVPの長さと値フィールドを取得し、次のように隠されたAVPサブフォームにエンコードすることです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 which 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 will become 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. Thus, if Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24 octets.
非表示になっているデータのサイズをマスクするために、上記のように、結果のサブフォーモットをパッドで埋めることができます。パディングは、元の属性値フィールドの長さに配置された値を変更しませんが、作成されている結果のAVPの長さを変更します。たとえば、非表示の属性値の長さが4オクテットの場合、非表示のAVPの長さは10オクテット（6属性値の長さ）になります。隠れた後、AVPの長さは、元の属性値フィールドパディングの長さの6属性値の長さサイズになります。したがって、パディングが12オクテットの場合、AVPの長さは6 4 2 12 = 24オクテットになります。
Next, An MD5 hash is performed on the concatenation of:
次に、以下の連結時にMD5ハッシュが実行されます。
+ the 2 octet Attribute number of the AVP + the shared secret + 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. If a different random vector is used for the hiding of subsequent AVPs then a new Random Vector AVP must be placed in the command message before the first AVP to which it applies.
このハッシュで使用されるランダムベクトルの値は、ランダムベクトルAVPの値フィールドに渡されます。このランダムベクトルAVPは、隠された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, but only the actual octets present in the Subformat are modified, and the length of the AVP is not altered.
MD5ハッシュ値は、非表示のAVPサブフォーモットの最初の16オクテット（またはそれ以下）セグメントでXoredされ、非表示の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 secret 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オクテット（またはそれ以下）セグメントでXAREDされ、非表示のAVPの値フィールドの対応するオクテットに配置されます。
If necessary, this operation is repeated, with the shared secret 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 RFC 2138 [RFC2138] 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]による「ネットワークセキュリティ」の本「ネットワークセキュリティ」の「ミキシング」セクションから取られたRFC 2138 [RFC2138]から採用されました。メソッドの詳細な説明は次のとおりです。
Call the shared secret S, the Random Vector RV, and the Attribute Value AV. Break the value field into 16-octet chunks p1, p2, 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 b1, b2, etc.
共有Secret S、ランダムベクトルRV、および属性値AVを呼び出します。値フィールドを16オクセットのチャンクP1、P2などに分割し、最後の1つを16オクテットの境界にランダムなデータでパッドでパッドします。CiphertextブロックC（1）、C（2）などを呼び出します。また、中間値B1、B2などを定義します。
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
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.1). See Section 3.2 for the list of defined control message types and their identifiers.
メッセージタイプAVPは、コントロールメッセージヘッダー（セクション3.1で定義）の直後のメッセージの最初のAVPでなければなりません。定義されたコントロールメッセージタイプとその識別子のリストについては、セクション3.2を参照してください。
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. Thus, if the M-bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the tunnel 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 may not be hidden (the H-bit MUST be 0). The Length of this AVP is 8.
メッセージタイプ内の必須（m）ビットAVPには特別な意味があります。AVP自体が認識されない場合に無視されるべきかどうかを示すのではなく、コントロールメッセージ自体を無視する必要があるかどうかの兆候です。したがって、メッセージタイプAVP内でMビットが設定され、メッセージタイプが実装に不明な場合は、トンネルをクリアする必要があります。Mビットが設定されていない場合、実装は未知のメッセージタイプを無視する場合があります。このドキュメントで定義されているすべてのメッセージタイプについて、Mビットを1に設定する必要があります。このAVPは隠されていない場合があります（Hビットは0でなければなりません）。このAVPの長さは8です。
Random Vector (All Messages)
ランダムベクトル（すべてのメッセージ）
The Random Vector AVP, Attribute Type 36, is used to enable the hiding of the Attribute Value of arbitrary AVPs.
ランダムベクトルAVP、属性タイプ36は、任意の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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String may be of arbitrary length, although a random vector of 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 4.2).
ランダムなオクテット文字列は任意の長さである可能性がありますが、少なくとも16個のオクテットのランダムベクトルが推奨されます。文字列には、MD5ハッシュの計算に使用するランダムベクトルが含まれており、非表示のAVPの属性値を取得または非表示にします（セクション4.2を参照）。
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. This AVP MUST precede the first AVP with the H bit set.
複数のランダムベクトルAVPがメッセージに表示される場合があります。この場合、非表示のAVPは、ランダムベクトルAVPを最も密接に先行するランダムベクトルAVPを使用します。このAVPは、Hビットセットを使用して最初のAVPに先行する必要があります。
The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the length of the Random Octet String.
このAVPのMビットは1に設定する必要があります。このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPの長さは、ランダムオクテット文字列の長さ6と長さです。
Result Code (CDN, StopCCN)
結果コード（cdn、stopccn）
The Result Code AVP, Attribute Type 1, indicates the reason for terminating the control channel 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 (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 are 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 using the Default Language [RFC2277].
結果コードは、2オクテットの符号なし整数です。オプションのエラーコードは、2 Octet Unsigned Integerです。オプションのエラーメッセージは、エラーコードフィールドに従うことができます。エラーコードとメッセージの存在は、AVP長さフィールドによって示されます。エラーメッセージには、条件に関連付けられた（人間の読み取り可能な）テキストを提供する任意の文字列が含まれています。すべてのエラーメッセージの人間の読み取り可能なテキストは、デフォルト言語[RFC2277]を使用してUTF-8 charsetで提供する必要があります。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. 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 + the length of the Error Message if there is an Error Code and Message.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります。エラーコードまたはメッセージがない場合は長さ8です。コードとメッセージ。
Defined Result Code values for the StopCCN message are:
STOPCCNメッセージの定義された結果コード値は次のとおりです。
0 - Reserved 1 - General request to clear control connection 2 - General error--Error Code indicates the problem 3 - Control channel already exists 4 - Requester is not authorized to establish a control channel 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
0-予約1-コントロール接続をクリアするための一般的な要求2-一般的なエラー - エラーコードは問題を示します3-コントロールチャネルはすでに存在します4-リクエスタチャネル5を確立する権限はありません - リクエスターのプロトコルバージョンはサポートされていませんエラーコードは、サポートされている最高バージョンを示す6-リクエスターがシャットダウンされています7-有限状態マシンエラー
Defined Result Code values for the CDN message are:
CDNメッセージの定義された結果コード値は次のとおりです。
0 - Reserved 1 - Call disconnected due to loss of carrier 2 - Call disconnected for the reason indicated in error code 3 - Call disconnected for administrative reasons 4 - Call failed due to lack of appropriate facilities being available (temporary condition) 5 - Call failed due to lack of appropriate facilities being available (permanent condition) 6 - Invalid destination 7 - Call failed due to no carrier detected 8 - Call failed due to detection of a busy signal 9 - Call failed due to lack of a dial tone 10 - Call was not established within time allotted by LAC 11 - Call was connected but no appropriate framing was detected
0-予約1-キャリア2の損失のために切断されたコール2-エラーコード3に示されている理由で切断されたコール - 管理上の理由で切断されたコール4-適切な施設が不足しているために失敗しました（一時的な条件）適切な施設が不足しているため利用可能（永久状態）6-無効な宛先7-キャリアが検出されなかったためにコールが失敗しました8-ビジー信号の検出によりコールが失敗します - ダイヤルトーンの欠如のためにコールが失敗しました10-コールLAC 11によって割り当てられた時間内に確立されていませんでした - コールが接続されましたが、適切なフレーミングは検出されませんでした
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:
以下に定義されているエラーコードは、特定のL2TP要求に固有のエラーの種類ではなく、プロトコルまたはメッセージ形式のエラーに関連しています。L2TP応答が結果コードで一般的なエラーが発生したことを示した場合、一般的なエラー値を調べてエラーが何であるかを判断する必要があります。現在定義されている一般的なエラーコードとその意味は次のとおりです。
0 - No general error 1 - No control connection exists yet for this LAC-LNS pair 2 - Length is wrong 3 - One of the field values was out of range or reserved field was non-zero 4 - Insufficient resources to handle this operation now 5 - The Session ID is invalid in this context 6 - A generic vendor-specific error occurred in the LAC 7 - Try another. If LAC is aware of other possible LNS destinations, it should try one of them. This can be used to guide an LAC based on LNS policy, for instance, the existence of multilink PPP bundles. 8 - Session or tunnel was shutdown due to receipt of an unknown AVP with the M-bit set (see section 4.2). The Error Message SHOULD contain the attribute of the offending AVP in (human readable) text form.
0-一般的なエラーなし1-このlac -lnsペア2にはまだ制御接続が存在しません2-長さは間違っています3-フィールド値の1つは範囲外または予約済みフィールドがゼロではありませんでした - この操作を処理するのに不十分なリソース5-このコンテキストではセッションIDが無効です。LACが他の可能なLNSの目的地を認識している場合、そのうちの1つを試す必要があります。これを使用して、LNSポリシー、たとえばマルチリンクPPPバンドルの存在に基づいてLACをガイドすることができます。8- MBITセットを備えた未知のAVPの受領により、セッションまたはトンネルはシャットダウンしました（セクション4.2を参照）。エラーメッセージには、（人間の読み取り可能な）テキスト形式の問題のAVPの属性を含める必要があります。
When a General Error Code of 6 is used, additional information about the error SHOULD be included in the Error Message field.
6の一般的なエラーコードが使用される場合、エラーに関する追加情報をエラーメッセージフィールドに含める必要があります。
Protocol Version (SCCRP, SCCRQ)
プロトコルバージョン（SCCRP、SCCRQ）
The Protocol Version AVP, Attribute Type 2, indicates the L2TP protocol version of the sender.
プロトコルバージョンAVP属性タイプ2は、送信者のL2TPプロトコルバージョンを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver field is a 1 octet unsigned integer containing the value 1. Rev field is a 1 octet unsigned integer containing 0. This pertains to L2TP protocol version 1, revision 0. Note this is not the same version number that is included in the header of each message.
Verフィールドは、値1を含む1オクテットの非署名整数です。Revフィールドは0を含む1オクテットの符号なし整数です。これは、L2TPプロトコルバージョン1、リビジョン0に関係しています。各メッセージの。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります。このAVPの長さは8です。
Framing Capabilities (SCCRP, SCCRQ)
フレーミング機能（SCCRP、SCCRQ）
The Framing Capabilities AVP, Attribute Type 3, provides the peer with an indication of the types of framing that will be accepted or requested by the sender.
フレーミング機能AVP、属性タイプ3は、送信者が受け入れまたは要求するフレーミングの種類をピアに示します。
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 for future framing type definitions |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute Value field is a 32-bit mask, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported.
属性値フィールドは32ビットマスクで、2つのビットが定義されています。ビットAが設定されている場合、非同期フレーミングがサポートされています。ビットSが設定されている場合、同期フレーミングがサポートされています。
A peer MUST NOT request an incoming or outgoing call with a Framing Type AVP specifying a value not advertised in the Framing Capabilities AVP it received during control connection establishment. Attempts to do so will result in the call being rejected.
ピアは、制御接続の確立中に受け取ったフレーミング機能AVPで宣伝されていない値を指定するフレーミングタイプAVPで着信または発信コールを要求してはなりません。そうしようとすると、呼び出しが拒否されます。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは1に設定する必要があります。長さ（隠す前）は10です。
Bearer Capabilities (SCCRP, SCCRQ)
ベアラー機能（SCCRP、SCCRQ）
The Bearer Capabilities AVP, Attribute Type 4, provides the peer with an indication of the bearer device types supported by the hardware interfaces of the sender for outgoing calls.
BEARER機能AVP、属性タイプ4は、発信コールのために送信者のハードウェアインターフェイスによってサポートされるベアラーデバイスタイプの指標をピアに提供します。
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 for future bearer type definitions |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is a 32-bit mask, with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported.
これは32ビットマスクで、2つのビットが定義されています。ビットAが設定されている場合、アナログアクセスがサポートされています。ビットDが設定されている場合、デジタルアクセスがサポートされています。
An LNS should not request an outgoing call specifying a value in the Bearer Type AVP for a device type not advertised in the Bearer Capabilities AVP it received from the LAC during control connection establishment. Attempts to do so will result in the call being rejected.
LNSは、コントロール接続の確立中にLACから受け取ったBearer機能AVPで宣伝されていないデバイスタイプのBearer Type AVPの値を指定する発信コールを要求してはなりません。そうしようとすると、呼び出しが拒否されます。
This AVP MUST be present if the sender can place outgoing calls when requested.
送信者がリクエストされたときに発信コールを出すことができる場合、このAVPは存在する必要があります。
Note that an LNS that cannot act as an LAC as well will not support hardware devices for handling incoming and outgoing calls and should therefore set the A and D bits of this AVP to 0, or should not send the AVP at all. An LNS that can also act as an LAC and place outgoing calls should set A or D as appropriate. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists.
LACとしても機能できないLNSは、着信および発信コールを処理するためのハードウェアデバイスをサポートしないため、このAVPのAとDビットを0に設定するか、AVPをまったく送信しないでください。また、LACとして機能し、発信コールを配置できるLNSは、必要に応じてAまたはDを設定する必要があります。このメッセージの存在は、要求された場合、特定の発信コールが送信者によって配置されることを保証するものではありません。ただ、物理的能力が存在することです。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは1に設定する必要があります。長さ（隠す前）は10です。
Tie Breaker (SCCRQ)
ネクタイブレーカー（SCCRQ）
The Tie Breaker AVP, Attribute Type 5, indicates that the sender wishes a single tunnel to exist between the given LAC-LNS pair.
Tie Breaker AVP属性タイプ5は、送信者が指定されたLAC-LNペアの間に単一のトンネルが存在することを望んでいることを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Break Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tie Breaker Value is an 8 octet value that is used to choose a single tunnel where both LAC and LNS request a tunnel concurrently. The recipient of a SCCRQ must check to see if a SCCRQ has been sent to the peer, and if so, must compare its Tie Breaker value with the received one. The lower value "wins", and the "loser" MUST silently discard its tunnel. In the case where a tie breaker is present on both sides, and the value is equal, both sides MUST discard their tunnels.
タイブレーカー値は、LACとLNSの両方が同時にトンネルを要求する単一のトンネルを選択するために使用される8オクテット値です。SCCRQの受信者は、SCCRQがピアに送信されたかどうかを確認する必要があります。もしそうなら、そのタイブレーカー値を受信した値と比較する必要があります。低い値は「勝ち」、「敗者」は静かにトンネルを捨てなければなりません。タイブレーカーが両側に存在し、値が等しい場合、両側はトンネルを捨てなければなりません。
If a tie breaker is received, and an outstanding SCCRQ had no tie breaker value, the initiator which included the Tie Breaker AVP "wins". If neither side issues a tie breaker, then two separate tunnels are opened.
タイブレーカーが受信され、優れたSCCRQにタイブレーカー値がない場合、タイブレーカーAVPを含むイニシエーターが「勝ち」。どちらの側もタイブレーカーを発行しない場合、2つの別々のトンネルが開かれます。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 0. The Length of this AVP is 14.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは0に設定する必要があります。このAVPの長さは14です。
Firmware Revision (SCCRP, SCCRQ)
ファームウェアリビジョン（SCCRP、SCCRQ）
The Firmware Revision AVP, Attribute Type 6, indicates the firmware revision of the issuing device.
ファームウェアリビジョンAVP、属性タイプ6は、発行デバイスのファームウェアリビジョンを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Firmware Revision is a 2 octet unsigned integer encoded in a vendor specific format.
ファームウェアリビジョンは、ベンダー固有の形式でエンコードされた2オクテットの符号なし整数です。
For devices which do not have a firmware revision (general purpose computers running L2TP software modules, for instance), the revision of the L2TP software module may be reported instead.
ファームウェアリビジョンがないデバイス（たとえば、L2TPソフトウェアモジュールを実行している汎用コンピューター）の場合、L2TPソフトウェアモジュールのリビジョンが代わりに報告される場合があります。
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 (before hiding) is 8.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは0に設定する必要があります。長さ（隠す前）は8です。
Host Name (SCCRP, SCCRQ)
ホスト名（SCCRP、SCCRQ）
The Host Name AVP, Attribute Type 7, indicates the name of the issuing LAC or LNS.
ホスト名AVP属性タイプ7は、発行中の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 hostname with fully qualified domain would be appropriate.
この名前は、可能な限り広くユニークでなければなりません。DNS [RFC1034]に参加するホストの場合、完全に認定されたドメインを持つホスト名が適切です。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6 plus the length of the Host Name.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは、1に設定する必要があります。このAVPの長さは、ホスト名の長さ6と長さです。
Vendor Name (SCCRP, SCCRQ)
ベンダー名（SCCRP、SCCRQ）
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 UTF-8 charset using the Default Language [RFC2277].
ベンダー名は、ベンダー文字列を表すオクテットの指定数です。このAVPの人間の読み取り可能なテキストは、デフォルト言語[RFC2277]を使用してUTF-8 charsetで提供する必要があります。
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 (before hiding) of this AVP is 6 plus the length of the Vendor Name.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは0に設定する必要があります。このAVPの長さ（隠す前）は、ベンダー名の長さ6と長さです。
Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
割り当てられたトンネルID（SCCRP、SCCRQ、STOPCCN）
The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being assigned to this tunnel by the sender.
割り当てられたトンネルID AVP属性タイプ9は、送信者によってこのトンネルに割り当てられているIDをエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.
割り当てられたトンネルIDは、2オクテットの非ゼロ符号なし整数です。
The Assigned Tunnel ID AVP establishes a value used to multiplex and demultiplex multiple tunnels between the LNS and LAC. The L2TP peer MUST place this value in the Tunnel ID header field of all control and data messages that it subsequently transmits over the associated tunnel. Before the Assigned Tunnel ID AVP is received from a peer, messages MUST be sent to that peer with a Tunnel ID value of 0 in the header of all control messages.
割り当てられたトンネルID AVPは、LNSとLACの間の複数のトンネルのマルチプレックスとデマルチプレックスに使用される値を確立します。L2TPピアは、この値をすべてのコントロールメッセージとデータメッセージのトンネルIDヘッダーフィールドに配置する必要があります。割り当てられたトンネルID AVPがピアから受信される前に、すべてのコントロールメッセージのヘッダーにトンネルID値が0でメッセージをそのピアに送信する必要があります。
In the StopCCN control message, the Assigned Tunnel ID AVP MUST be the same as the Assigned Tunnel ID AVP first sent to the receiving peer, permitting the peer to identify the appropriate tunnel even if a StopCCN is sent before an Assigned Tunnel ID AVP is received.
STOPCCNコントロールメッセージでは、割り当てられたトンネルID AVPは、割り当てられたトンネルID AVPが最初に受信ピアに送信されたものと同じでなければなりません。。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は8です。
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. The remote peer may send the specified number of control messages before it must wait for an acknowledgment.
不在の場合、ピアは送信ウィンドウのウィンドウサイズ4を想定する必要があります。リモートピアは、謝辞を待つ前に、指定された数の制御メッセージを送信する場合があります。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります。このAVPの長さは8です。
Challenge (SCCRP, SCCRQ)
チャレンジ（SCCRP、SCCRQ）
The Challenge AVP, Attribute Type 11, indicates that the issuing peer wishes to authenticate the tunnel endpoints using a CHAP-style authentication mechanism.
チャレンジAVP、属性タイプ11は、発行ピアが、チャップスタイルの認証メカニズムを使用してトンネルエンドポイントを認証したいことを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data.
課題は、ランダムデータの1つ以上のオクテットです。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Challenge.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は、チャレンジの長さ6に加えています。
Challenge Response (SCCCN, SCCRP)
チャレンジ応答（SCCCN、SCCRP）
The Response AVP, Attribute Type 13, provides a response to a challenge received.
AVP属性タイプ13の応答は、受信した課題に対する応答を提供します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16 octet value reflecting the CHAP-style [RFC1994] response to the challenge.
応答は、チャレンジに対するチャップスタイル[RFC1994]の応答を反映した16オクテットの値です。
This AVP MUST be present in an SCCRP or SCCCN if a challenge was received in the preceding SCCRQ or SCCRP. For purposes of the ID value in the CHAP response calculation, the value of the Message Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for an SCCCN).
このAVPは、前のSCCRQまたはSCCRPでチャレンジが受信された場合、SCCRPまたはSCCCNに存在する必要があります。CHAP応答計算のID値の目的のために、このメッセージのメッセージタイプAVPの値が使用されます（例：SCCRPの場合は2、SCCCNの場合は3）。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 22.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は22です。
Q.931 Cause Code (CDN)
Q.931原因コード（CDN）
The Q.931 Cause Code AVP, Attribute Type 12, is used to give additional information in case of unsolicited call disconnection.
Q.931原因コードAVP属性タイプ12は、未承諾の通話切断の場合に追加情報を提供するために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code is the returned Q.931 Cause code, and Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) associated with the Cause Code. Both values are returned in their native ITU encodings [DSS1]. An additional ASCII text Advisory Message may also be included (presence indicated by the AVP Length) to further explain the reason for disconnecting.
原因コードは返されたq.931原因コードであり、原因の原因は、原因コードに関連付けられた返されたq.931メッセージコード（切断）です。両方の値は、ネイティブのITUエンコーディング[DSS1]で返されます。追加のASCIIテキストアドバイザリーメッセージも含めることができます（AVPの長さで示されている存在）。切断の理由をさらに説明します。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 9, plus the size of the Advisory Message.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは、1に設定する必要があります。このAVPの長さは9、およびアドバイザリーメッセージのサイズです。
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
割り当てられたセッションID（CDN、ICRP、ICRQ、OCRP、OCRQ）
The Assigned Session ID AVP, Attribute Type 14, encodes the ID being assigned to this session by the sender.
割り当てられたセッションID AVP属性タイプ14は、送信者によってこのセッションに割り当てられているIDをエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Session ID is a 2 octet non-zero unsigned integer.
割り当てられたセッションIDは、2オクテットの非ゼロ符号なし整数です。
The Assigned Session ID AVP is establishes a value used to multiplex and demultiplex data sent over a tunnel between the LNS and LAC. The L2TP peer MUST place this value in the Session ID header field of all control and data messages that it subsequently transmits over the tunnel that belong to this session. Before the Assigned Session ID AVP is received from a peer, messages MUST be sent to that peer with a Session ID of 0 in the header of all control messages.
割り当てられたセッションID AVPは、LNSとLACの間のトンネルを介して送信された多重データとDemultiplexデータに使用される値を確立します。L2TPピアは、このセッションに属するトンネル上に送信するすべてのコントロールメッセージとデータメッセージのセッションIDヘッダーフィールドにこの値を配置する必要があります。割り当てられたセッションID AVPがピアから受信される前に、すべての制御メッセージのヘッダーにセッションIDが0のセッションIDでそのピアにメッセージを送信する必要があります。
In the CDN control message, the same Assigned Session ID AVP first sent to the receiving peer is used, permitting the peer to identify the appropriate tunnel even if CDN is sent before an Assigned Session ID is received.
CDNコントロールメッセージでは、最初に受信ピアに送信された同じ割り当てられたセッションID AVPが使用され、割り当てられたセッションIDが受信される前にCDNが送信された場合でも、ピアが適切なトンネルを特定できます。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は8です。
Call Serial Number (ICRQ, OCRQ)
シリアル番号（ICRQ、OCRQ）に電話する
The Call Serial Number AVP, Attribute Type 15, encodes an identifier assigned by the LAC or LNS to this call.
コールシリアル番号AVP属性タイプ15は、この呼び出しに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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Serial Number is a 32 bit value.
通話シリアル番号は32ビット値です。
The Call Serial Number is intended to be an easy reference for administrators on both ends of a tunnel to use when investigating call failure problems. Call 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でかなりの期間一意である可能性が高い値を徐々に増やすように設定する必要があります。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は10です。
Minimum BPS (OCRQ)
最小BPS（OCRQ）
The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable line speed for this call.
最小BPS AVP属性タイプ16は、この呼び出しの最も低い許容ライン速度をエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32 bit value indicates the speed in bits per second.
最小BPSは32ビット値で、1秒あたりビットの速度を示します。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は10です。
Maximum BPS (OCRQ)
最大BPS（OCRQ）
The Maximum BPS AVP, Attribute Type 17, encodes the highest acceptable line speed for this call.
最大BPS AVP属性タイプ17は、この呼び出しで最も許容可能なライン速度を最も高くエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32 bit value indicates the speed in bits per second.
最大BPSは32ビット値で、1秒あたりのビットの速度を示します。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は10です。
Bearer Type (ICRQ, OCRQ)
ベアラータイプ（ICRQ、OCRQ）
The Bearer Type AVP, Attribute Type 18, encodes the bearer type for the incoming or outgoing call.
ベアラータイプAVP、属性タイプ18は、着信または発信コールのベアラータイプをエンコードします。
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 for future Bearer Types |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bearer Type is a 32-bit bit mask, which indicates the bearer
capability of the call (ICRQ) or required for the call (OCRQ). If
set, bit A indicates that the call refers to an analog channel. If
set, bit D indicates that the call refers to a digital channel.
Both may be set, indicating that the call was either
indistinguishable, or can be placed on either type of channel.
Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if it was set in the Bearer Capabilities AVP received from the LAC during control connection establishment.
このAVPの値フィールドのビットは、コントロール接続の確立中にAVPがRACから受け取ったベアラー機能に設定された場合にのみ、LNSによって設定する必要があります。
It is valid to set neither the A nor D bits in an ICRQ. Such a setting may indicate that the call was not received over a physical link (e.g if the LAC and PPP are located in the same subsystem).
ICRQにAまたはDビットを設定しないことは有効です。このような設定は、呼び出しが物理的なリンクに対して受信されなかったことを示している可能性があります（例：LACとPPPが同じサブシステムにある場合）。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は10です。
Framing Type (ICCN, OCCN, OCRQ)
フレーミングタイプ（ICCN、OCCN、OCRQ）
The Framing Type AVP, Attribute Type 19, encodes the framing type for the incoming or outgoing call.
フレーミングタイプAVP属性タイプ19は、着信または発信コールのフレーミングタイプをエンコードします。
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 for future Framing Types |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Framing Type is a 32-bit mask, which indicates the type of PPP framing requested for an OCRQ, or the type of PPP framing negotiated for an OCCN or ICCN. The framing type MAY be used as an indication to PPP on the LNS as to what link options to use for LCP negotiation [RFC1662].
フレーミングタイプは32ビットマスクで、OCRQに要求されたPPPフレーミングのタイプ、またはOCCNまたはICCNと交渉されたPPPフレーミングのタイプを示します。フレーミングタイプは、LCP交渉に使用するリンクオプション[RFC1662]について、LNSのPPPの兆候として使用できます。
Bit A indicates asynchronous framing. Bit S indicates synchronous framing. For an OCRQ, both may be set, indicating that either type of framing may be used.
ビットAは非同期フレーミングを示します。ビットSは、同期フレーミングを示します。OCRQの場合、どちらも設定される場合があり、どちらのタイプのフレーミングが使用されるかを示しています。
Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if it was set in the Framing Capabilities AVP received from the LAC during control connection establishment.
このAVPの値フィールドのビットは、コントロール接続の確立中にAVPがRACから受け取ったフレーミング機能に設定された場合にのみ、LNSによって設定する必要があります。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は10です。
Called Number (ICRQ, OCRQ)
番号（ICRQ、OCRQ）と呼ばれる
The Called Number AVP, Attribute Type 21, encodes the telephone number to be called for an OCRQ, and the Called number for an ICRQ.
呼び出された番号AVP属性タイプ21は、OCRQの場合は電話番号をエンコードし、ICRQの呼び出された番号をエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Called Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value needed in this AVP.
呼び出された番号はASCII文字列です。LACの管理者とLNS間の接触は、このAVPで必要な値の解釈を調整するために必要な場合があります。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Called Number.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は、呼び出された数値の長さ6と長さです。
Calling Number (ICRQ)
通話番号（ICRQ）
The Calling Number AVP, Attribute Type 22, encodes the originating number for the incoming call.
呼び出し番号AVP属性タイプ22は、着信コールの発信元番号をエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calling Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP.
呼び出し番号はASCII文字列です。このAVPの値の解釈を調整するには、LACの管理者とLNSの接触が必要になる場合があります。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Calling Number.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は、6と呼び出し番号の長さです。
Sub-Address (ICRQ, OCRQ)
サブアドレス（ICRQ、OCRQ）
The Sub-Address AVP, Attribute Type 23, encodes additional dialing information.
サブアドレスAVP属性タイプ23は、追加のダイヤル情報をエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP.
サブアドレスはASCII文字列です。このAVPの値の解釈を調整するには、LACの管理者とLNSの接触が必要になる場合があります。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Sub-Address.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は、サブアドレスの長さ6に加えています。
(Tx) Connect Speed (ICCN, OCCN)
（TX）接続速度（ICCN、OCCN）
The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the speed of the facility chosen for the connection attempt.
（TX）接続速度BPS AVP、属性タイプ24は、接続試行のために選択された施設の速度をエンコードします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The (Tx) Connect Speed BPS is a 4 octet value indicating the speed in bits per second.
（TX）接続速度BPSは、1秒あたりビットの速度を示す4オクテット値です。
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 (e.g. 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 Connect Speed 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 MUST be set to 1. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は10です。
Rx Connect Speed (ICCN, OCCN)
RX Connect Speed（ICCN、OCCN）
The Rx Connect Speed AVP, Attribute Type 38, represents the speed of the connection from the perspective of the LAC (e.g. data flowing from the remote system to the LAC).
RX Connect速度AVP、属性タイプ38は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS is a 4 octet value indicating the speed in bits per second.
BPSは、1秒あたりのビットの速度を示す4オクテット値です。
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）接続速度AVPに与えられた送信接続速度に関して非対称である可能性があることを意味します。
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは1または0です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は10です。
Physical Channel ID (ICRQ, OCRP)
物理チャネルID（ICRQ、OCRP）
The Physical Channel ID AVP, Attribute Type 25, encodes 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.
物理チャネルIDは、ロギング目的でのみ使用することを目的とした4オクテット値です。
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 (before hiding) of this AVP is 10.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は10です。
Private Group ID (ICCN)
プライベートグループID（ICCN）
The Private Group ID AVP, Attribute Type 37, is used by the LAC to indicate that this call is to be associated with a particular customer group.
プライベートグループID AVP、属性タイプ37は、この呼び出しが特定の顧客グループに関連付けられることを示すために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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length.
プライベートグループIDは、任意の長さのオクテットの文字列です。
The LNS MAY treat the PPP session as well as network traffic through this session in a special manner determined by the peer. For example, if the LNS is individually connected to several private networks using unregistered addresses, this AVP may be included by the LAC to indicate that a given call should be associated with one of the private networks.
LNSは、ピアによって決定された特別な方法で、このセッションを通じてPPPセッションとネットワークトラフィックを扱うことができます。たとえば、LNSが未登録のアドレスを使用していくつかのプライベートネットワークに個別に接続されている場合、このAVPは、特定の呼び出しがプライベートネットワークの1つに関連付けられるべきであることを示すためにLACに含まれる場合があります。
The Private Group ID is a string corresponding to a table in the LNS that defines the particular characteristics of the selected group. A LAC MAY determine the Private Group ID from a RADIUS response, local configuration, or some other source.
プライベートグループIDは、選択したグループの特定の特性を定義するLNSのテーブルに対応する文字列です。LACは、RADIUS応答、ローカル構成、またはその他のソースからプライベートグループIDを決定する場合があります。
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Private Group ID.
このAVPは隠されている可能性があります（Hビットは1または0です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は、6つのプライベートグループIDの長さです。
Sequencing Required (ICCN, OCCN)
シーケンスが必要（ICCN、OCCN）
The Sequencing Required AVP, Attribute Type 39, indicates to the LNS that Sequence Numbers MUST always be present on the data channel.
AVPのシーケンスが必要な属性タイプ39は、LNSに、シーケンス番号が常にデータチャネルに存在する必要があることを示します。
This AVP has no Attribute Value field.
このAVPには、属性値フィールドがありません。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6.
このAVPを非表示にしてはなりません（Hビットは0でなければなりません）。このAVPのMビットは1に設定する必要があります。このAVPの長さは6です。
The LAC may have answered the call and negotiated LCP with the remote system, perhaps in order to establish the system's apparent identity. In this case, these AVPs may be included to indicate the link properties the remote system initially requested, properties the remote system and LAC ultimately negotiated, as well as PPP authentication information sent and received by the LAC. This information may be used to initiate the PPP LCP and authentication systems on the LNS, allowing PPP to continue without renegotiation of LCP. Note that the LNS policy may be to enter an additional round of LCP negotiation and/or authentication if the LAC is not trusted.
LACは、おそらくシステムの見かけのアイデンティティを確立するために、コールに応答し、リモートシステムとLCPを交渉した可能性があります。この場合、これらのAVPは、リモートシステムが最初に要求したリンクプロパティ、リモートシステムとLACが最終的にネゴシエートし、LACが送信および受信したPPP認証情報を示すために含まれる場合があります。この情報は、LNS上のPPP LCPおよび認証システムを開始するために使用される場合があり、LCPの再交渉なしにPPPが継続できるようにします。LNSポリシーは、LACが信頼されていない場合は、LCP交渉および/または認証の追加ラウンドを入力することであることに注意してください。
Initial Received LCP CONFREQ (ICCN)
初期受信lcp confreq（ICCN）
In the Initial Received LCP CONFREQ AVP, Attribute Type 26, provides the LNS with the Initial CONFREQ received by the LAC from the PPP Peer.
最初の受信したLCP confreq AVP、属性タイプ26では、LNSにPPPピアからRACが受信した最初のconpreqを提供します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCP CONFREQ is a copy of the body of the initial CONFREQ received, starting at the first option within the body of the LCP message.
LCP confreqは、LCPメッセージの本体内の最初のオプションから始まる最初のconfreqの本文のコピーです。
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 (before hiding) of this AVP is 6 plus the length of the CONFREQ.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は、confreqの長さ6と長さです。
Last Sent LCP CONFREQ (ICCN)
最後に送られたLCP confreq（ICCN）
In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS with the Last CONFREQ sent by the LAC to the PPP Peer.
最後に送信されたLCP confreq AVP、属性タイプ27では、LNSにLACがPPPピアに送信した最後のconpreqを提供します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ sent to the client to complete LCP negotiation, starting at the first option within the body of the LCP message.
LCP confreqは、LCPメッセージの本文内の最初のオプションから始まるLCP交渉を完了するためにクライアントに送信された最終的なconfreqの本文のコピーです。
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 (before hiding) of this AVP is 6 plus the length of the CONFREQ.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は、confreqの長さ6と長さです。
Last Received LCP CONFREQ (ICCN)
最後にlcp confreq（ICCN）を受け取りました
The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the LNS with the Last CONFREQ received by the LAC from the PPP Peer.
最後に受け取ったLCP confreq AVP、属性タイプ28は、PPPピアからLACが受信した最後のconpreqを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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ received from the client to complete LCP negotiation, starting at the first option within the body of the LCP message.
LCP confreqは、LCPメッセージの本文内の最初のオプションから始まるLCP交渉を完了するために、クライアントから受け取った最終的なconfreqの本文のコピーです。
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 (before hiding) of this AVP is 6 plus the length of the CONFREQ.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は、confreqの長さ6と長さです。
Proxy Authen Type (ICCN)
プロキシ認証タイプ（ICCN）
The Proxy Authen Type AVP, Attribute Type 29, determines if proxy authentication should be used.
プロキシAuthenタイプAVP、属性タイプ29は、プロキシ認証を使用するかどうかを決定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Type is a 2 octet unsigned integer, holding:
AUTHENタイプは、2オクテットの符号なし整数です。
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 (before hiding) of this AVP is 8.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは0に設定する必要があります。このAVPの長さ（隠す前）は8です。
Defined Authen Type values are: 0 - Reserved 1 - Textual username/password exchange 2 - PPP CHAP 3 - PPP PAP 4 - No Authentication 5 - Microsoft CHAP Version 1 (MSCHAPv1)
定義された認証タイプ値は次のとおりです。0-予約1-テキストユーザー名/パスワード交換2 -PPPチャップ3 -PPP PAP 4-認証なし5-マイクロソフトチャップバージョン1（MSCHAPV1）
This AVP MUST be present if proxy authentication is to be utilized. If it is not present, then it is assumed that this peer cannot perform proxy authentication, requiring a restart of the authentication phase at the LNS if the client has already entered this phase with the LAC (which may be determined by the Proxy LCP AVP if present).
代理認証を利用する場合は、このAVPが存在する必要があります。存在しない場合は、このピアがプロキシ認証を実行できないと想定されており、クライアントがすでにこのフェーズをLACで入力している場合、LNSで認証フェーズの再起動を必要とします（これはプロキシLCP AVPによって決定される場合があります。現在）。
Associated AVPs for each type of authentication follow.
認証のタイプごとに関連するAVPが続きます。
Proxy Authen Name (ICCN)
プロキシ認証名（ICCN）
The Proxy Authen Name AVP, Attribute Type 30, specifies the name of the authenticating client when using proxy authentication.
プロキシAuthen名AVP、属性タイプ30は、プロキシ認証を使用するときに認証クライアントの名前を指定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Name... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Name is a string of octets of arbitrary length. It contains the name specified in the client's authentication response.
auth nameは、任意の長さのオクテットの文字列です。クライアントの認証応答で指定された名前が含まれています。
This AVP MUST be present in messages containing a Proxy Authen Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to employ AVP hiding for obscuring the cleartext name.
このAVPは、1、2、3、または5の認証タイプを持つプロキシAUTHENタイプAVPを含むメッセージに存在する必要があります。ClearText名を不明瞭にするためにAVPの隠しを使用することが望ましい場合があります。
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 (before hiding) is 6 plus the length of the cleartext name.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。長さ（隠す前）は6とクリアテキスト名の長さです。
Proxy Authen Challenge (ICCN)
プロキシ認証チャレンジ（ICCN）
The Proxy Authen Challenge AVP, Attribute Type 31, specifies the challenge sent by the LAC to the PPP Peer, when using proxy authentication.
プロキシAuth Challenge AVP、属性タイプ31は、プロキシ認証を使用するときに、LACからPPPピアに送信される課題を指定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is a string of one or more octets.
課題は、1つ以上のオクテットの文字列です。
This AVP MUST be present for Proxy Authen Types 2 and 5. The Challenge field contains the CHAP challenge presented to the client by the LAC.
このAVPは、Proxy Autheen Types 2および5に存在する必要があります。チャレンジフィールドには、LACによってクライアントに提示されたCHAPチャレンジが含まれています。
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 (before hiding) of this AVP is 6, plus the length of the Challenge.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は6、さらにチャレンジの長さです。
Proxy Authen ID (ICCN)
プロキシ認証ID（ICCN）
The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of the PPP Authentication that was started between the LAC and the PPP Peer, when proxy authentication is being used.
プロキシAuthen ID AVP、属性タイプ32は、プロキシ認証が使用されているときに、LACとPPPピアの間で開始されたPPP認証のID値を指定します。
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 | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID is a 2 octet unsigned integer, the most significant octet MUST be 0.
IDは2オクテットの符号なし整数で、最も重要なオクテットは0でなければなりません。
The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 3 and 5. For 2 and 5, the ID field contains the byte ID value presented to the client by the LAC in its Challenge. For 3, it is the Identifier value of the Authenticate-Request.
プロキシAuth ID AVPは、Proxy Auth Types 2、3、および5に存在する必要があります。2、5、および5の場合、IDフィールドには、ChallengeのLACによってクライアントに提示されたバイトID値が含まれています。3の場合、それはAuthenticate-Requestの識別子値です。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは0に設定する必要があります。
Proxy Authen Response (ICCN)
プロキシ認証応答（ICCN）
The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP Authentication response received by the LAC from the PPP Peer, when proxy authentication is used.
プロキシ認証AVP属性タイプ33は、プロキシ認証が使用されるときに、PPPピアからRACが受信したPPP認証応答を指定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a string of octets.
応答はオクテットの文字列です。
This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The Response field contains the client's response to the challenge. For Proxy authen types 2 and 5, this field contains the response value received by the LAC. For types 1 or 3, it contains the clear text password received from the client by the LAC. In the case of cleartext passwords, AVP hiding is recommended.
このAVPは、Proxy Auth Types 1、2、3、および5に存在する必要があります。応答フィールドには、チャレンジに対するクライアントの応答が含まれています。Proxy Auth Types 2および5の場合、このフィールドにはLACが受信した応答値が含まれています。タイプ1または3の場合、LACでクライアントから受信したクリアテキストパスワードが含まれています。ClearTextパスワードの場合、AVP隠蔽をお勧めします。
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 (before hiding) of this AVP is 6 plus the length of the Response.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、0に設定する必要があります。このAVPの長さ（隠す前）は、6と応答の長さです。
Call Errors (WEN)
コールエラー（WEN）
The Call Errors AVP, Attribute Type 34, is used by the LAC to send error information to the LNS.
コールエラーAVP、属性タイプ34は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CRC Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors (L) | Framing Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors (L) | Hardware Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns (L) | Buffer Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns (L) | Time-out Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors (L) | Alignment Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
Reserved - Not used, MUST be 0 CRC Errors - Number of PPP frames received with CRC errors since call was established Framing Errors - Number of improperly framed PPP packets received Hardware Overruns - Number of receive buffer over-runs since call was established Buffer Overruns - Number of buffer over-runs detected since call was established Time-out Errors - Number of time-outs since call was established Alignment Errors - Number of alignment errors since call was established
予約 - 使用されていない、0 CRCエラーである必要があります - コールが確立されてからCRCエラーで受信したPPPフレームの数 - フレーミングエラー - 不適切にフレーム化されたPPPパケットの数は、ハードウェアオーバーランを受け取っています - 通話が確立されてからの受信バッファのオーバーランの数 - 通話が確立されてからのバッファオーバーランの数は、タイムアウトエラーを確立してから検出されます - コールが確立されてからのタイムアウト数アライメントエラー - コールが確立されてからのアライメントエラー数
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 32.
このAVPは隠されている可能性があります（Hビットは0または1です）。このAVPのMビットは、1に設定する必要があります。このAVPの長さ（隠す前）は32です。
ACCM (SLI)
ACCM（SLI）
The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC of the ACCM negotiated with the PPP Peer by the LNS.
ACCM AVP属性タイプ35は、LNSによって使用され、LACがLNSによってPPPピアと交渉されたACCMを通知します。
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 | Send ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM (L) | Receive ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Send ACCM and Receive ACCM are each 4 octet values preceded by a 2 octet reserved quantity. The send ACCM value should be used by the LAC to process packets it sends on the connection. The receive ACCM value should be used by the LAC to process incoming packets on the connection. The default values used by the LAC for both these fields are 0xFFFFFFFF. The LAC should honor these fields unless it has specific configuration information to indicate that the requested mask must be modified to permit operation.
ACCMを送信し、ACCMを受信することは、2オクテットの予約数量が続く4つのオクテット値のそれぞれです。送信ACCM値は、接続で送信するパケットを処理するためにLACで使用する必要があります。受信ACCM値は、接続上の着信パケットを処理するためにLACによって使用する必要があります。これらの両方のフィールドでLACが使用するデフォルト値は0xffffffffです。LACは、操作を許可するために要求されたマスクを変更する必要があることを示す特定の構成情報がない限り、これらのフィールドを尊重する必要があります。
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 16.
このAVPは隠されている可能性があります（Hビットは1または0です）。このAVPのMビットは1に設定する必要があります。このAVPの長さは16です。
The necessary setup for tunneling a PPP session with L2TP consists of two steps, (1) establishing the Control Connection for a Tunnel, and (2) establishing a Session as triggered by an incoming or outgoing call request. The Tunnel and corresponding Control Connection MUST be established before an incoming or outgoing call is initiated. An L2TP Session MUST be established before L2TP can begin to tunnel PPP frames. Multiple Sessions may exist across a single Tunnel and multiple Tunnels may exist between the same LAC and LNS.
L2TPを使用したPPPセッションをトンネリングするために必要なセットアップは、2つのステップで構成されています。トンネルと対応する制御接続は、着信または発信コールが開始される前に確立する必要があります。L2TPがPPPフレームのトンネルを開始する前に、L2TPセッションを確立する必要があります。単一のトンネル全体に複数のセッションが存在する場合があり、同じLACとLNSの間に複数のトンネルが存在する場合があります。
+-----+ +-----+
| |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
| LAC | | LNS |
| #######Control Connection######## |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+
Figure 5.1 Tunneling PPP
図5.1トンネルPPP
The Control Connection is the initial connection that must be achieved between an LAC and LNS before sessions may be brought up. Establishment of the control connection includes securing the identity of the peer, as well as identifying the peer's L2TP version, framing, and bearer capabilities, etc.
コントロール接続は、セッションが発生する前にLACとLNSの間で達成する必要がある最初の接続です。制御接続の確立には、ピアの身元の確保、ピアのL2TPバージョン、フレーミング、ベアラー機能などの識別が含まれます。
A three message exchange is utilized to setup the control connection. Following is a typical message exchange:
3つのメッセージ交換が使用され、制御接続をセットアップします。以下は典型的なメッセージ交換です。
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
ZLB ACKは、そのピアのキューでそれ以上のメッセージが待機していない場合に送信されます。
L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel authentication system during control connection establishment. If an LAC or LNS wishes to authenticate the identity of the peer it is contacting or being contacted by, a Challenge AVP is included in the SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP or SCCCN, respectively. If the expected response and response received from a peer does not match, establishment of the tunnel MUST be disallowed.
L2TPには、制御接続の確立中に、シンプルでオプションのチャップのような[RFC1994]トンネル認証システムが組み込まれています。LACまたはLNSが、接触しているピアのアイデンティティを認証したい場合、または接触している、または連絡を受けている場合、AVPはSCCRQまたはSCCRPメッセージに含まれています。課題AVPがSCCRQまたはSCCRPで受信される場合、それぞれ次のSCCRPまたはSCCCNでAVPを送信する必要があります。ピアから受け取った予想される応答と応答が一致しない場合、トンネルの確立は許可されなければなりません。
To participate in tunnel authentication, a single shared secret MUST exist between the LAC and LNS. This is the same shared secret used for AVP hiding (see Section 4.3). See Section 4.4.3 for details on construction of the Challenge and Response AVPs.
トンネル認証に参加するには、LACとLNSの間に単一の共有秘密が存在する必要があります。これは、AVP隠蔽に使用される同じ共有秘密です（セクション4.3を参照）。チャレンジと応答のAVPの構築の詳細については、セクション4.4.3を参照してください。
After successful control connection establishment, individual sessions may be created. Each session corresponds to single PPP stream between the LAC and LNS. Unlike control connection establishment, session establishment is directional with respect to the LAC and LNS. The LAC requests the LNS to accept a session for an incoming call, and the LNS requests the LAC to accept a session for placing an outgoing call.
制御接続の確立が成功した後、個々のセッションが作成される場合があります。各セッションは、LACとLNSの間の単一のPPPストリームに対応しています。制御接続の確立とは異なり、セッションの確立は、LACおよびLNSに関して方向性があります。LACは、LNSに着信コールのセッションを受け入れるように要求し、LNSは発信コールを配置するためのセッションを受け入れるようにLACを要求します。
A three message exchange is employed to setup the session. Following is a typical sequence of events:
セッションをセットアップするために3つのメッセージ交換が使用されます。以下は、典型的な一連のイベントです。
LAC LNS --- --- (Call Detected)
lac lns --- ---（通話検出）
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
ZLB ACKは、そのピアのキューでそれ以上のメッセージが待機していない場合に送信されます。
A three message exchange is employed to setup the session. Following is a typical sequence of events:
セッションをセットアップするために3つのメッセージ交換が使用されます。以下は、典型的な一連のイベントです。
LAC LNS --- --- <- OCRQ OCRP ->
lac lns --- --- < - ocrq ocrp->
(Perform Call Operation)
（コール操作を実行）
OCCN -> <- ZLB ACK
OCCN-> <-ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
ZLB ACKは、そのピアのキューでそれ以上のメッセージが待機していない場合に送信されます。
Once tunnel establishment is complete, PPP frames from the remote system are received at the LAC, stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The LNS receives the L2TP packet, and processes the encapsulated PPP frame as if it were received on a local PPP interface.
トンネルの確立が完了すると、リモートシステムからのPPPフレームがLACで受信され、CRC、リンクフレーミング、および透明性バイトが剥がれ、L2TPにカプセル化され、適切なトンネルに転送されます。LNSはL2TPパケットを受信し、カプセル化されたPPPフレームをローカルPPPインターフェイスで受信したかのように処理します。
The sender of a message associated with a particular session and tunnel places the Session ID and Tunnel ID (specified by its peer) in the Session ID and Tunnel ID header for all outgoing messages. In this manner, PPP frames are multiplexed and demultiplexed over a single tunnel between a given LNS-LAC pair. Multiple tunnels may exist between a given LNS-LAC pair, and multiple sessions may exist within a tunnel.
特定のセッションとトンネルに関連付けられたメッセージの送信者は、すべての発信メッセージのセッションIDとトンネルIDヘッダーにセッションIDとトンネルID（ピアで指定）を配置します。このように、PPPフレームは、特定のLNS-LACペア間の単一のトンネルで多重化され、非複数の屈折されます。特定のLNS-LACペアの間に複数のトンネルが存在する場合があり、トンネル内に複数のセッションが存在する場合があります。
The value of 0 for Session ID and Tunnel ID is special and MUST NOT be used as an Assigned Session ID or Assigned Tunnel ID. For the cases where a Session ID has not yet been assigned by the peer (i.e., during establishment of a new session or tunnel), the Session ID field MUST be sent as 0, and the Assigned Session ID AVP within the message MUST be used to identify the session. Similarly, for cases where the Tunnel ID has not yet been assigned from the peer, the Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to identify the tunnel.
セッションIDおよびトンネルIDの0の値は特別であり、割り当てられたセッションIDまたは割り当てられたトンネルIDとして使用してはなりません。セッションIDがピアによってまだ割り当てられていない場合（つまり、新しいセッションまたはトンネルの確立中）、セッションIDフィールドを0として送信する必要があり、メッセージ内の割り当てられたセッションIDAVPを使用する必要があります。セッションを特定します。同様に、トンネルIDがまだピアから割り当てられていない場合、トンネルIDを0として送信し、トンネルの識別に使用されるトンネルID AVPを割り当てなければなりません。
Sequence numbers are defined in the L2TP header for control messages and optionally for data messages (see Section 3.1). These are used to provide a reliable control message transport (see Section 5.8) and optional data message sequencing. Each peer maintains separate sequence numbers for the control connection and each individual data session within a tunnel.
シーケンス番号は、制御メッセージのL2TPヘッダーで定義され、オプションではデータメッセージの場合は定義されています（セクション3.1を参照）。これらは、信頼できる制御メッセージトランスポート（セクション5.8を参照）およびオプションのデータメッセージシーケンスを提供するために使用されます。各ピアは、コントロール接続の個別のシーケンス番号とトンネル内の個々のデータセッションを維持します。
Unlike the L2TP control channel, the L2TP data channel does not use sequence numbers to retransmit lost data messages. Rather, data messages may use sequence numbers to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. The LAC may request that sequence numbers be present in data messages via the Sequencing Required AVP (see Section 4.4.6). If this AVP is present during session setup, sequence numbers MUST be present at all times. If this AVP is not present, sequencing presence is under control of the LNS. The LNS controls enabling and disabling of sequence numbers by sending a data message with or without sequence numbers present at any time during the life of a session. Thus, if the LAC receives a data message without sequence numbers present, it MUST stop sending sequence numbers in future data messages. If the LAC receives a data message with sequence numbers present, it MUST begin sending sequence numbers in future outgoing data messages. If the LNS enables sequencing after disabling it earlier in the session, the sequence number state picks up where it left off before.
L2TP制御チャネルとは異なり、L2TPデータチャネルはシーケンス番号を使用して失われたデータメッセージを再送信しません。むしろ、データメッセージはシーケンス番号を使用して失われたパケットを検出したり、輸送中に並べ替えられた可能性のあるパケットの元のシーケンスを復元したりする場合があります。LACは、AVPが必要とするシーケンスを介してデータメッセージにシーケンス番号が存在することを要求する場合があります（セクション4.4.6を参照）。セッションのセットアップ中にこのAVPが存在する場合、シーケンス番号は常に存在する必要があります。このAVPが存在しない場合、シーケンスの存在はLNSの制御下にあります。LNSは、セッションの期間中にいつでも存在するシーケンス番号の有無にかかわらずデータメッセージを送信することにより、シーケンス番号の有効化と無効化を制御します。したがって、LACがシーケンス番号が存在しないデータメッセージを受信した場合、将来のデータメッセージでシーケンス番号の送信を停止する必要があります。LACがシーケンス番号が存在するデータメッセージを受信した場合、将来の発信データメッセージでシーケンス番号の送信を開始する必要があります。セッションの早期にLNSが無効になった後にシーケンスを有効にすると、シーケンス番号状態が前に中断したところからピックアップします。
The LNS may initiate disabling of sequencing at any time during the session (including the first data message sent). It is recommended that for connections where reordering or packet loss may occur, sequence numbers always be enabled during the initial negotiation stages of PPP and disabled only when and if the risk is considered acceptable. For example, if the PPP session being tunneled is not utilizing any stateful compression or encryption protocols and is only carrying IP (as determined by the PPP NCPs that are established), then the LNS might decide to disable sequencing as IP is tolerant to datagram loss and reordering.
LNSは、セッション中にいつでもシーケンスの無効化を開始する場合があります（最初のデータメッセージを含む）。並べ替えやパケットの損失が発生する可能性のある接続については、PPPの初期交渉段階で常にシーケンス番号を有効にし、リスクが許容される場合と無効にすることをお勧めします。たとえば、トンネルに登録されているPPPセッションがステートフルな圧縮または暗号化プロトコルを使用しておらず、IPのみを携帯している場合（確立されたPPP NCPによって決定されます）、LNSはIPがデータグラムの損失に耐性があるため、シーケンスを無効にすることを決定する場合があります。そして並べ替え。
A keepalive mechanism is employed by L2TP in order to differentiate tunnel outages from extended periods of no control or data activity on a tunnel. This is accomplished by injecting Hello control messages (see Section 6.5) after a specified period of time has elapsed since the last data or control message was received on a tunnel. As for any other control message, if the Hello message is not reliably delivered then the tunnel is declared down and is reset. The transport reset mechanism along with the injection of Hello messages ensures that a connectivity failure between the LNS and the LAC will be detected at both ends of a tunnel.
トンネル上の制御なしまたはデータアクティビティの長期間とトンネルの停止を区別するために、KeepaliveメカニズムがL2TPによって採用されています。これは、トンネルで最後のデータまたはコントロールメッセージが受信されて以来、指定された期間が経過した後にHello Controlメッセージを注入することで実現されます（セクション6.5を参照）。他のコントロールメッセージについては、Helloメッセージが確実に配信されない場合、トンネルは宣言され、リセットされます。輸送リセットメカニズムとHelloメッセージの注入とともに、LNSとLACの間の接続障害がトンネルの両端で検出されることが保証されます。
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). Following is an example of a typical control message exchange:
セッションの分解は、LACまたはLNSによって開始される場合があり、CDNコントロールメッセージを送信することで達成されます。最後のセッションがクリアされた後、制御接続も取り壊される可能性があります（通常はそうです）。以下は、典型的なコントロールメッセージ交換の例です。
LAC or LNS LAC or LNS
LACまたはLNS LACまたはLNS
CDN -> (Clean up)
CDN->（クリーンアップ）
<- ZLB ACK (Clean up)
<-ZLBACK（クリーンアップ）
Control connection teardown may be initiated by either the LAC or LNS and is accomplished by sending a single StopCCN control message. The receiver of a StopCCN MUST send a ZLB ACK 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 ZLB ACK is lost). The recommended time for a full retransmission cycle is 31 seconds (see section 5.8). Following is an example of a typical control message exchange:
コントロール接続の分解は、LACまたはLNSのいずれかによって開始される場合があり、単一のSTOPCCNコントロールメッセージを送信することで達成されます。STOPCCNの受信機は、メッセージの受信を確認するためにZLB ACKを送信し、少なくとも完全な再送信サイクルでSTOPCCNの再送信を適切に受け入れるのに十分な制御接続状態を維持する必要があります（ZLB ACKが失われた場合）。完全な再送信サイクルの推奨時間は31秒です（セクション5.8を参照）。以下は、典型的なコントロールメッセージ交換の例です。
LAC or LNS LAC or LNS
LACまたはLNS LACまたはLNS
StopCCN -> (Clean up)
stopccn->（クリーンアップ）
<- ZLB ACK (Wait) (Clean up)
<-ZLBACK（待機）（クリーンアップ）
An implementation may shut down an entire tunnel and all sessions on the tunnel by sending the StopCCN. Thus, it is not necessary to clear each session individually when tearing down the whole tunnel.
実装により、トンネル全体とトンネル上のすべてのセッションがSTOPCCNを送信することができます。したがって、トンネル全体を破壊するときに各セッションを個別にクリアする必要はありません。
L2TP provides a lower level reliable transport service for all control messages. The Nr and Ns fields of the control message header (see section 3.1) belong to this transport. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages. The reliable control message is a sliding window transport that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for the control connection within a tunnel.
L2TPは、すべての制御メッセージに対して低レベルの信頼できる輸送サービスを提供します。コントロールメッセージヘッダーのNRおよびNSフィールド（セクション3.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 ZLB ACK message), receipt of duplicate messages MUST be acknowledged by the reliable transport. This acknowledgement may either piggybacked on a message in queue, or explicitly via a ZLB ACK.
メッセージシーケンス番号nsは0から始まります。各後続のメッセージは、シーケンス番号の次の増分で送信されます。したがって、シーケンス番号は、モジュロ65536を表すフリーランニングカウンターです。受信メッセージのヘッダーのシーケンス番号は、その値が最後の受信数と前の32767の範囲にある場合、最後に受信した数値以下と見なされます。値、包括的。たとえば、最後に受信したシーケンス番号が15の場合、シーケンス番号0〜15のメッセージ、および32784〜65535は等しくないと見なされます。このようなメッセージは、処理から既に受信され、無視されているメッセージの複製と見なされます。ただし、すべてのメッセージが適切に認められるようにするために（特にZLB ACKメッセージの紛失の場合）、重複したメッセージの受信は信頼できる輸送によって確認される必要があります。この承認は、キューのメッセージにピギーバックされるか、ZLB ACKを介して明示的にバックされる場合があります。
All control messages take up one slot in the control message sequence number space, except the ZLB acknowledgement. Thus, Ns is not incremented after a ZLB message is sent.
すべての制御メッセージは、ZLBの確認を除き、コントロールメッセージシーケンス番号スペースに1つのスロットを取ります。したがって、ZLBメッセージが送信された後、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-ZLB message received plus 1, modulo 65536). While the Nr in a received ZLB is used to flush messages from the local retransmit queue (see below), Nr of the next message sent is not be updated by the Ns of the ZLB.
最後に受信したメッセージ番号NRは、L2TPピアが受信したメッセージを確認するために使用されます。ピアが次に受信すると予想されるメッセージのシーケンス番号（たとえば、受信したZLB以外のメッセージの最後のns、1、Modulo 65536）。受信したZLBのNRは、ローカル再送信キューからメッセージをフラッシュするために使用されますが（以下を参照）、送信された次のメッセージのNRはZLBのNSによって更新されません。
The reliable transport 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, or they may be discarded requiring a retransmission by the peer.
受信ピアでの信頼できる輸送は、コントロールメッセージが上位レベルに複製されずに配信されることを確認する責任があります。失われたメッセージが受信されたときに、順序付けられていないメッセージが並べられる場合があります。または、ピアによる再送信を必要とする廃棄される場合があります。
Each tunnel 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) passes without acknowledgement, 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 MUST be no less than 8 seconds per retransmission. If no peer response is detected after several retransmissions, (a recommended default is 5, but SHOULD be configurable), the tunnel and all sessions within MUST be cleared.
メッセージのその後の各再送信は、指数関数的なバックオフ間隔を使用する必要があります。したがって、最初の再送信が1秒後に発生した場合、2秒後に次の再送信が発生し、その後4秒などが発生するはずです。このキャップは、再送信ごとに8秒以上でなければなりません。いくつかの再送信後にピア応答が検出されない場合（推奨されるデフォルトは5ですが、構成可能である必要があります）、トンネルと内部のすべてのセッションをクリアする必要があります。
When a tunnel 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 exchange has occurred.
接続の喪失以外の理由でトンネルが閉鎖されている場合、最終メッセージ交換が発生した後、完全な再送信間隔のために状態および信頼できる送達メカニズムを維持および操作する必要があります。
A sliding window mechanism is used for control message transmission. Consider two peers A & B. Suppose A specifies a Receive Window Size AVP with a value of N in the SCCRQ or SCCRP messages. B is now allowed to have up to N outstanding control messages. Once N have been sent, it must wait for an acknowledgment that advances the window before sending new control messages. An implementation may support a receive window of only 1 (i.e., by sending out a Receive Window Size AVP with a value of 1), but MUST accept a window of up to 4 from its peer (e.g. have the ability to send 4 messages before backing off). A value of 0 for the Receive Window Size AVP is invalid.
スライディングウィンドウメカニズムは、コントロールメッセージの送信に使用されます。2人のピアA＆Bを検討してください。AaがSCCRQまたはSCCRPメッセージにnの値を持つ受信ウィンドウサイズAVPを指定するとします。Bは、最大n未払いの制御メッセージを持つことが許可されています。nが送信されたら、新しいコントロールメッセージを送信する前にウィンドウを進めるという確認を待つ必要があります。実装では、1の受信ウィンドウをサポートできます（つまり、1の値で受信ウィンドウサイズのAVPを送信することで）が、ピアから最大4のウィンドウのウィンドウを受け入れる必要があります（たとえば、4つのメッセージを前に送信する機能があります。バックオフ）。受信ウィンドウサイズAVPの値は無効です。
When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized. The recommended procedure for this is described in Appendix A.
コントロールメッセージを再送信する場合、ゆっくりとした開始および輻輳回避ウィンドウの調整手順を利用する必要があります。これに推奨される手順は、付録Aで説明されています。
A peer MUST NOT withhold acknowledgment of messages as a technique for flow controlling control messages. An L2TP implementation is expected to be able to keep up with incoming control messages, possibly responding to some with errors reflecting an inability to honor the requested action.
ピアは、フロー制御制御メッセージの手法としてメッセージの承認を差し控えてはなりません。L2TPの実装は、入ってくる制御メッセージに追いつくことができると予想されます。おそらく、要求されたアクションを尊重できないことを反映したエラーのある人に応答する可能性があります。
Appendix B contains examples of control message transmission, acknowledgement, and retransmission.
付録Bには、コントロールメッセージ送信、謝辞、および再送信の例が含まれています。
The following control connection messages are used to establish, clear and maintain L2TP tunnels. All data is 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値として送信する必要があります。
Start-Control-Connection-Request (SCCRQ) is a control message used to initialize a tunnel between an LNS and an LAC. It is sent by either the LAC or the LNS to being the tunnel establishment process.
Start-Control-Connection-Request（SCCRQ）は、LNSとLACの間のトンネルの初期化に使用されるコントロールメッセージです。これは、LACまたはLNSのいずれかによって、トンネル設立プロセスに送られます。
The following AVPs MUST be present in the SCCRQ:
次のAVPはSCCRQに存在する必要があります。
Message Type AVP Protocol Version Host Name Framing Capabilities Assigned Tunnel ID
メッセージタイプAVPプロトコルバージョンホスト名フレーミング機能割り当てトンネルID
The Following AVPs MAY be present in the SCCRQ:
次のAVPはSCCRQに存在する場合があります。
Bearer Capabilities Receive Window Size Challenge Tie Breaker Firmware Revision Vendor Name
ベアラーの機能は、ウィンドウサイズの課題タイブレーカーファームウェアリビジョンベンダー名を受信する
Start-Control-Connection-Reply (SCCRP) is a control message sent in reply to a received SCCRQ message. SCCRP is used to indicate that the SCCRQ was accepted and establishment of the tunnel should continue.
Start-Control-Connection-Reply（SCCRP）は、受信したSCCRQメッセージに返信されたコントロールメッセージです。SCCRPは、SCCRQが受け入れられ、トンネルの確立が継続することを示すために使用されます。
The following AVPs MUST be present in the SCCRP:
次のAVPはSCCRPに存在する必要があります。
Message Type Protocol Version Framing Capabilities Host Name Assigned Tunnel ID
メッセージタイププロトコルバージョンフレーミング機能ホスト名が割り当てられたトンネルID
The following AVPs MAY be present in the SCCRP:
次のAVPはSCCRPに存在する場合があります。
Bearer Capabilities Firmware Revision Vendor Name Receive Window Size Challenge Challenge Response
ベアラー機能ファームウェア改訂ベンダー名ウィンドウサイズの受信チャレンジチャレンジ応答
Start-Control-Connection-Connected (SCCCN) is a control message sent in reply to an SCCRP. SCCCN completes the tunnel 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に存在する場合があります。
Challenge Response
チャレンジ応答
Stop-Control-Connection-Notification (StopCCN) is a control message sent by either the LAC or LNS to inform its peer that the tunnel is being shutdown and the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit call 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 transport layer.
Stop-Control-Connection-Notification（STOPCCN）は、トンネルがシャットダウンしており、制御接続を閉じる必要があることをピアに通知するために、LACまたはLNSによって送信されたコントロールメッセージです。さらに、すべてのアクティブセッションは暗黙的にクリアされています（明示的なコールコントロールメッセージを送信することなく）。このリクエストを発行する理由は、結果コードAVPに示されています。メッセージへの明示的な返信はありません。信頼できる制御メッセージ輸送層によって受信される暗黙のACKのみです。
The following AVPs MUST be present in the StopCCN:
次のAVPはstopccnに存在する必要があります。
Message Type Assigned Tunnel ID Result Code
メッセージタイプ割り当てられたトンネルID結果コード
The Hello (HELLO) message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a "keepalive" for the tunnel.
Hello（Hello）メッセージは、LAC-LNSコントロール接続のピアによって送信されるL2TPコントロールメッセージです。このコントロールメッセージは、トンネルの「キープライブ」として使用されます。
The sending of HELLO messages and the policy for sending them are left up to the implementation. A peer MUST NOT expect HELLO messages at any time or interval. As with all messages sent on the control connection, the receiver will return either a ZLB ACK or an (unrelated) message piggybacking the necessary acknowledgement information.
Helloメッセージの送信とそれらを送信するためのポリシーは、実装に任されています。ピアは、いつでもハローメッセージを期待してはなりません。コントロール接続で送信されるすべてのメッセージと同様に、受信者はZLB ACKまたは必要な承認情報を豚バックする（無関係な）メッセージのいずれかを返します。
Since a HELLO is a control message, and control messages are reliably sent by the lower level transport, this keepalive function operates by causing the transport level to reliably deliver a message. If a media interruption has occurred, the reliable transport will be unable to deliver the HELLO across, and will clean up the tunnel.
Helloはコントロールメッセージであり、コントロールメッセージは低レベルのトランスポートによって確実に送信されるため、このKeepAlive関数は、トランスポートレベルにメッセージを確実に配信することで動作します。メディアの中断が発生した場合、信頼できる輸送はHelloを届けることができず、トンネルをクリーンアップします。
Keepalives for the tunnel MAY be implemented by sending a HELLO if a period of time (a recommended default is 60 seconds, but SHOULD be configurable) has passed without receiving any message (data or control) from the peer.
トンネルのKeepALivesは、ピアからメッセージ（データまたはコントロール）を受け取らずに渡された期間（推奨デフォルトが60秒であるが、設定可能である必要がある）の場合、Helloを送信することで実装できます。
HELLO messages are global to the tunnel. The Session ID in a HELLO message MUST be 0.
こんにちはメッセージはトンネルにとってグローバルです。ハローメッセージのセッションIDは0でなければなりません。
The Following AVP MUST be present in the HELLO message:
次のAVPは、Helloメッセージに存在する必要があります。
Message Type
メッセージタイプ
Incoming-Call-Request (ICRQ) is a control message sent by the LAC to the LNS when an incoming call is detected. It is the first in a three message exchange used for establishing a session within an L2TP tunnel.
受信コールレクエスト（ICRQ）は、着信コールが検出されたときにLACからLNSに送信されるコントロールメッセージです。これは、L2TPトンネル内でセッションを確立するために使用される3つのメッセージ交換で最初です。
ICRQ is used to indicate that a session is to be established between the LAC and LNS for this call and provides the LNS with parameter information for the session. The LAC may defer answering the call until it has received an ICRP from the LNS indicating that the session should be established. This mechanism allows the LNS to obtain sufficient information about the call before determining whether it should be answered or not. Alternatively, the LAC may answer the call, negotiate LCP and PPP authentication, and use the information gained to choose the LNS. In this case, the call has already been answered by the time the ICRP message is received; the LAC simply spoofs the "call indication" and "call answer" steps in this case.
ICRQは、この呼び出しのためにセッションがLACとLNSの間に確立され、セッションのパラメーター情報をLNSに提供することを示すために使用されます。LACは、セッションを確立する必要があることを示すLNSからICRPを受信するまで、コールに応答することを延期する場合があります。このメカニズムにより、LNSは、回答すべきかどうかを判断する前に、電話に関する十分な情報を取得できます。あるいは、LACはコールに応答し、LCPとPPP認証を交渉し、得た情報を使用してLNSを選択する場合があります。この場合、ICRPメッセージが受信されるまでに呼び出しがすでに回答されています。LACは、この場合の「コール表示」と「通話回答」の手順を単純に押し上げます。
The following AVPs MUST be present in the ICRQ:
次のAVPはICRQに存在する必要があります。
Message Type Assigned Session ID Call Serial Number
メッセージタイプ割り当てセッションIDコールシリアル番号
The following AVPs MAY be present in the ICRQ:
次のAVPはICRQに存在する場合があります。
Bearer Type Physical Channel ID Calling Number Called Number Sub-Address
ベアラータイプ物理チャネルIDコール番号サブアドレスと呼ばれる番号
Incoming-Call-Reply (ICRP) is a control message sent by the LNS to the LAC in response to a received ICRQ message. It is the second in the three message exchange used for establishing sessions within an L2TP tunnel.
受信コールReply（ICRP）は、受信したICRQメッセージに応じて、LNSからLACに送信されたコントロールメッセージです。これは、L2TPトンネル内でのセッションの確立に使用される3つのメッセージ交換の2番目です。
ICRP is used to indicate that the ICRQ was successful and for the LAC to answer the call if it has not already done so. It also allows the LNS to indicate necessary parameters for the L2TP session.
ICRPは、ICRQが成功したことを示すために使用され、LACがまだ行っていない場合はCallに応答することが使用されます。また、LNSはL2TPセッションに必要なパラメーターを示すことができます。
The following AVPs MUST be present in the ICRP:
次のAVPはICRPに存在する必要があります。
Message Type Assigned Session ID
メッセージタイプ割り当てられたセッションID
Incoming-Call-Connected (ICCN) is a control message sent by the LAC to the LNS in response to a received ICRP message. It is the third message in the three message exchange used for establishing sessions within an L2TP tunnel.
受信コール接続（ICCN）は、受信したICRPメッセージに応じてLACからLNSに送信されるコントロールメッセージです。これは、L2TPトンネル内でセッションを確立するために使用される3つのメッセージ交換の3番目のメッセージです。
ICCN is used to indicate that the ICRP was accepted, the call has been answered, and that the L2TP session should move to the established state. It also provides additional information to the LNS about parameters used for the answered call (parameters that may not always available at the time the ICRQ is issued).
ICCNは、ICRPが受け入れられ、電話に応答し、L2TPセッションが確立された状態に移動することを示すために使用されます。また、回答コールに使用されるパラメーター（ICRQが発行された時点で常に利用可能ではないパラメーター）に関するパラメーターに関する追加情報をLNSに提供します。
The following AVPs MUST be present in the ICCN:
次のAVPはICCNに存在する必要があります。
Message Type (Tx) Connect Speed Framing Type
メッセージタイプ（TX）接続速度フレーミングタイプ
The following AVPs MAY be present in the ICCN:
次のAVPはICCNに存在する場合があります。
Initial Received LCP CONFREQ Last Sent LCP CONFREQ Last Received LCP CONFREQ Proxy Authen Type Proxy Authen Name Proxy Authen Challenge Proxy Authen ID Proxy Authen Response Private Group ID Rx Connect Speed Sequencing Required
初期受信lcp confreqが最後に送られたlcp confreqは最後にlcp confreq proxy auth auth auth auth proxy auth auth porxy auth euthen id proxy auth auth privateグループID rx rx connect速度シーケンスが必要です
Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to the LAC to indicate that an outbound call from the LAC is to be established. It is the first in a three message exchange used for establishing a session within an L2TP tunnel.
発信-Call-Request（OCRQ）は、LNSからLACに送信されたコントロールメッセージであり、LACからのアウトバウンドコールが確立されることを示します。これは、L2TPトンネル内でセッションを確立するために使用される3つのメッセージ交換で最初です。
OCRQ is used to indicate that a session is to be established between the LNS and LAC for this call and provides the LAC with parameter information for both the L2TP session, and the call that is to be placed
OCRQは、この呼び出しのためにセッションがLNSとLACの間に確立されることを示すために使用され、LACにL2TPセッションのパラメーター情報と配置されるコールの両方のパラメーター情報を提供する
An LNS MUST have received a Bearer Capabilities AVP during tunnel establishment from an LAC in order to request an outgoing call to that LAC.
LNSは、そのLACへの発信コールを要求するために、トンネルの確立中にLACからのベアラー機能AVPを受け取っている必要があります。
The following AVPs MUST be present in the OCRQ:
次のAVPはOCRQに存在する必要があります。
Message Type Assigned Session ID Call Serial Number Minimum BPS Maximum BPS Bearer Type Framing Type Called Number
メッセージタイプ割り当てセッションIDコールシリアル番号最小BPS最大BPSベアラータイプフレーミング番号
The following AVPs MAY be present in the OCRQ:
次のAVPはOCRQに存在する場合があります。
Sub-Address
サブアドレス
Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to the LNS in response to a received OCRQ message. It is the second in a three message exchange used for establishing a session within an L2TP tunnel.
発信-Call-Reply（OCRP）は、受信したOCRQメッセージに応じて、LACからLNSに送信されるコントロールメッセージです。L2TPトンネル内でセッションを確立するために使用される3つのメッセージ交換の2番目です。
OCRP is used to indicate that the LAC is able to attempt the outbound call and returns certain parameters regarding the call attempt.
OCRPは、LACがアウトバウンドコールを試みることができることを示すために使用され、コールの試行に関する特定のパラメーターを返すことができます。
The following AVPs MUST be present in the OCRP:
次のAVPはOCRPに存在する必要があります。
Message Type Assigned Session ID
メッセージタイプ割り当てられたセッションID
The following AVPs MAY be present in the OCRP:
次のAVPはOCRPに存在する場合があります。
Physical Channel ID
物理チャネルID
Outgoing-Call-Connected (OCCN) is a control message sent by the LAC to the LNS following 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 within an L2TP tunnel.
発信コール接続（OCCN）は、OCRP後および発信コールが完了した後、LACからLNSに送信されたコントロールメッセージです。これは、L2TPトンネル内でセッションを確立するために使用される3つのメッセージ交換の最終メッセージです。
OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LNS about the particular parameters obtained after the call was established.
OCCNは、要求された発信コールの結果が成功したことを示すために使用されます。また、コールが確立された後に得られた特定のパラメーターに関する情報をLNSに提供します。
The following AVPs MUST be present in the OCCN:
次のAVPはOCCNに存在する必要があります。
Message Type (Tx) Connect Speed Framing Type
メッセージタイプ（TX）接続速度フレーミングタイプ
The following AVPs MAY be present in the OCCN:
次のAVPはOCCNに存在する場合があります。
Rx Connect Speed Sequencing Required
RX接続速度シーケンスが必要です
The Call-Disconnect-Notify (CDN) message is an L2TP control message sent by either the LAC or LNS to request disconnection of a specific call within the tunnel. Its purpose is to inform the peer of the disconnection and the reason why the disconnection occurred. 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）メッセージは、トンネル内の特定の呼び出しの切断を要求するために、LACまたはLNSによって送信されたL2TPコントロールメッセージです。その目的は、ピアに切断と切断が発生した理由を知らせることです。ピアはリソースをクリーンアップする必要があり、そのようなクリーンアップの成功または失敗の兆候を返送しません。
The following AVPs MUST be present in the CDN:
次のAVPはCDNに存在する必要があります。
Message Type Result Code Assigned Session ID
メッセージタイプ結果コード割り当てセッションID
The following AVPs MAY be present in the CDN:
次のAVPはCDNに存在する場合があります。
Q.931 Cause Code
Q.931原因コード
The WAN-Error-Notify message is an L2TP control message sent by the LAC to the LNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). 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メッセージは、LACによってLNSに送信されたL2TP制御メッセージであり、WANエラー条件（PPPをサポートするインターフェイスで発生する条件）を示します。このメッセージのカウンターは累積的です。このメッセージは、エラーが発生したときにのみ送信され、60秒ごとに1回以上送信する必要があります。新しい呼び出しが確立されると、カウンターはリセットされます。
The following AVPs MUST be present in the WEN:
次のAVPはWENに存在する必要があります。
Message Type Call Errors
メッセージタイプコールエラー
The Set-Link-Info message is an L2TP control message sent by the LNS to the LAC to set PPP-negotiated options. These options can change at any time during the life of the call, thus the LAC MUST be able to update its internal call information and behavior on an active PPP session.
Set-Link-INFOメッセージは、LNSからLACに送信されたL2TPコントロールメッセージで、PPP関連オプションを設定します。これらのオプションは、コールの存続期間中はいつでも変更される可能性があるため、LACはアクティブなPPPセッションで内部通話情報と動作を更新できる必要があります。
The following AVPs MUST be present in the SLI:
次のAVPはSLIに存在する必要があります。
Message Type ACCM
メッセージタイプACCM
The control messages defined in section 6 are exchanged by way of state tables defined in this section. Tables are defined for incoming call placement, outgoing call placement, as well as for initiation of the tunnel itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying semantics defined in Section 5.8.
セクション6で定義されているコントロールメッセージは、このセクションで定義されている状態表によって交換されます。テーブルは、着信コール配置、発信コール配置、およびトンネル自体の開始のために定義されています。状態テーブルは、セクション5.8で定義されている基礎となるセマンティクスで処理されるため、タイムアウトと再送信の動作をエンコードしません。
This section describes the operation of various L2TP control connection functions and the Control Connection messages which are used to support them.
このセクションでは、さまざまなL2TP制御接続関数の操作と、それらをサポートするために使用される制御接続メッセージについて説明します。
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.
無効または不整合可能な不正な制御メッセージの受信を適切に記録し、既知の状態への回復を確保するために制御接続をクリアする必要があります。その後、制御接続はイニシエーターによって再起動される場合があります。
An invalid control message is defined as a message which contains a Message Type that is marked mandatory (see Section 4.4.1) and is unknown to the implementation, or a control message that is received in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ).
無効なコントロールメッセージは、必須とマークされたメッセージタイプ（セクション4.4.1を参照）を含むメッセージタイプを含むメッセージとして定義され、実装には不明です。sccrqに）。
Examples of a malformed control message include one that has an invalid value in its header, contains an AVP that is formatted incorrectly or whose value is out of range, or a message that is missing a required AVP. A control message with a malformed header should be discarded. A control message with an invalid AVP should look to the M-bit for that AVP to determine whether the error is recoverable or not.
不正なコントロールメッセージの例には、ヘッダーに無効な値があるもの、誤ってフォーマットされているAVP、またはその値が範囲外のAVP、または必要なAVPが欠落しているメッセージが含まれます。奇形ヘッダーを使用したコントロールメッセージを破棄する必要があります。無効なAVPを使用したコントロールメッセージは、エラーが回復可能かどうかを判断するために、そのAVPのMビットに目を向ける必要があります。
A malformed yet recoverable non-mandatory (M-bit is not set) AVP within a control message should be treated in a similar manner as an unrecognized non-mandatory AVP. Thus, if a malformed AVP is received with the M-bit set, the session or tunnel should be terminated with a proper Result or Error Code sent. If the M-bit is not set, the AVP should be ignored (with the exception of logging a local error message) and the message accepted.
コントロールメッセージ内のAVPの奇形で回復可能な非監視（Mビットは設定されていません）は、認識されていない非監視AVPと同様の方法で扱う必要があります。したがって、Mビットセットで奇形のAVPが受信された場合、セッションまたはトンネルを適切な結果またはエラーコードを送信して終了する必要があります。Mビットが設定されていない場合、AVPは（ローカルエラーメッセージのログを除く）無視する必要があり、メッセージが受け入れられます。
This MUST NOT be considered a license to send malformed AVPs, but simply 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. That said, one example of a recoverable, malformed AVP might be if the Rx Connect Speed AVP, attribute 38, is received with a length of 8 rather than 10 and the BPS given in 2 octets rather than 4. Since the Rx Connect Speed is non-mandatory, this condition should not be considered catastrophic. As such, the control message should be accepted as if the AVP had not been received (with the exception of a local error message being logged).
これは、奇形のAVPを送信するライセンスとは考慮されてはなりませんが、受け取った場合、不適切にフォーマットされたメッセージを処理する方法に関するガイドです。特定のメッセージのすべての潜在的な奇形をリストし、それぞれにアドバイスを与えることは不可能です。とはいえ、RX接続速度AVP属性38が10ではなく8の長さで、BPSが4ではなく2オクテットで与えられたBPSが受信される場合、回復可能な不正なAVPの1つの例があるかもしれません。非依存、この状態は壊滅的であると見なされるべきではありません。そのため、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 tunnel destruction, the reliable delivery mechanism must be allowed to run (see Section 5.8) before destroying the tunnel. This permits the tunnel management messages to be reliably delivered to the peer.
次の表のいくつかのケースでは、プロトコルメッセージが送信され、「クリーンアップ」が発生します。トンネル破壊の開始者に関係なく、トンネルを破壊する前に、信頼できる送達メカニズムを実行する必要があることに注意してください（セクション5.8を参照）。これにより、トンネル管理メッセージをピアに確実に配信できます。
Appendix B.1 contains an example of lock-step tunnel establishment.
付録B.1には、ロックステップトンネルの確立の例が含まれています。
The L2TP control connection protocol is not distinguishable between the LNS and LAC, but is distinguishable between the originator and receiver. The originating peer is the one which first initiates establishment of the tunnel (in a tie breaker situation, this is the winner of the tie). Since either LAC or LNS can be the originator, a collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a description of this and its resolution.
L2TP制御接続プロトコルは、LNSとLACを区別できませんが、オリジネーターと受信機を区別できます。生まれたピアは、最初にトンネルの確立を開始するピアです（ネクタイブレーカーの状況では、これがネクタイの勝者です）。LACまたはLNSのいずれかが発信者になる可能性があるため、衝突が発生する可能性があります。この解像度の説明については、セクション4.4.3のタイブレーカーAVPを参照してください。
State Event Action New State
----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply
Open request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable
idle Receive SCCRQ, Send StopCCN, idle not acceptable Clean up
アイドルsccrqを受け取り、stopccnを送信し、アイドルが受け入れられないクリーンアップ
idle Receive SCCRP Send StopCCN idle Clean up
アイドルsccrpを受信しますspotccnアイドルクリーンアップを送信します
idle Receive SCCCN Clean up idle
wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable Send tunnel-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, Clean up, idle lose tie-breaker Re-queue SCCRQ for idle state
wait-ctl-reply sccrqを受け取り、クリーンアップし、アイドル状態のためにsccrqをリクエートするためにアイドルを失います
wait-ctl-reply Receive SCCCN Send StopCCN idle Clean up
wait-ctl-reply scccn send stopccnアイドルクリーンアップを受信します
wait-ctl-conn Receive SCCCN, Send tunnel-open established acceptable event to waiting sessions
wait-ctl-connはscccnを受信し、トンネルオープン確立された許容可能なイベントを待機セッションに送信します
wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable Clean up
wait-ctl-connはscccnを受信し、stopccnを送信し、アイドルが受け入れられないクリーンアップ
wait-ctl-conn Receive SCCRP, Send StopCCN, idle SCCRQ Clean up
wait-ctl-connはsccrpを受信し、stopccnを送信し、アイドルSCCRQクリーンアップ
established Local Send tunnel-open established Open request event to waiting (new call) sessions
確立されたローカル送信トンネルオープン確立されたオープンリクエストイベント（新しいコール）セッション
established Admin Send StopCCN idle Tunnel Close Clean up
確立された管理者は、クリーンアップをクローズアップします
established Receive SCCRQ, Send StopCCN idle SCCRP, SCCCN Clean up
確立された受信sccrq、spotccnアイドルsccrpを送信、scccnクリーンアップ
idle Receive StopCCN Clean up idle
wait-ctl-reply,
wait-ctl-conn,
established
The states associated with the LNS or LAC for control connection establishment are:
制御接続の確立のためにLNSまたはLACに関連する州は次のとおりです。
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.
イニシエーターと受信者の両方がこの状態から開始します。イニシエーターは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.8.
wait-ctl-replyオリジネーターは、同じピアから別の接続が要求されているかどうかを確認し、もしそうなら、セクション5.8で説明した衝突状況を処理します。
When an SCCRP is received, it is examined for a compatible version. If the version of the reply is lower than the version sent in the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, the originator moves to the established state. If the version is earlier and not supported, a StopCCN MUST be sent to the peer and the originator cleans up and terminates the tunnel.
SCCRPを受信すると、互換性のあるバージョンについて調べられます。返信のバージョンがリクエストで送信されたバージョンよりも低い場合、サポートされている場合、古い（低い）バージョンを使用する必要があります。返信のバージョンが早くてサポートされている場合、オリジネーターは確立された状態に移動します。バージョンが以前にサポートされていない場合は、STOPCCNをピアに送信する必要があり、オリジネーターがクリーンアップしてトンネルを終了する必要があります。
wait-ctl-conn This is where an SCCCN is awaited; upon receipt, the challenge response is checked. The tunnel either is established, or is torn down if an authorization failure is detected.
wait-ctl-connこれはSCCCNが待っている場所です。受領すると、チャレンジ応答がチェックされます。トンネルは確立されるか、承認の失敗が検出された場合に取り壊されます。
established An established connection may be terminated by either a local condition or the receipt of a Stop-Control-Connection-Notification. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Notification and clean up the tunnel.
確立された確立された接続は、ローカルな状態またはストップコントロール接続と解釈の受領のいずれかによって終了する場合があります。ローカル終了が発生した場合、オリジネーターはストップコントロール接続と解釈を送信し、トンネルをクリーンアップする必要があります。
If the originator receives a Stop-Control-Connection-Notification it MUST also clean up the tunnel.
オリジネーターがストップコントロール接続 - ノット化を受信した場合、トンネルもクリーンアップする必要があります。
Due to the real-time nature of telephone signaling, both the LNS and LAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The call and connection state figures do not specify exceptions caused by timers. These are addressed in Section 5.8.
電話信号のリアルタイム性により、複数の呼び出しに関連するメッセージがシリアル化されてブロックされていないように、LNSとLACの両方をマルチスレッドアーキテクチャで実装する必要があります。コールと接続の状態の数字は、タイマーによって引き起こされる例外を指定していません。これらはセクション5.8で説明されています。
An Incoming-Call-Request message is generated by the LAC when an incoming call is detected (for example, an associated telephone line rings). The LAC selects a Session ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used and analog if digital modems are involved. Calling Number, Called Number, and Subaddress may be included in the message if they are available from the telephone network.
着信コールリクエストメッセージは、着信コールが検出されたときにLACによって生成されます（たとえば、関連する電話回線など）。LACはセッションIDとシリアル番号を選択し、コールベアラータイプを示します。モデムは常にアナログコールタイプを示す必要があります。ISDNコールは、無制限のデジタルサービスまたはレートの適応を使用する場合、デジタルモデムが関与する場合はアナログの場合、デジタルを示す必要があります。電話網から入手可能な場合は、通話番号と呼ばれる番号、およびSubAddressがメッセージに含まれる場合があります。
Once the LAC sends the Incoming-Call-Request, it waits for a response from the LNS but it does not necessarily answer the call from the telephone network yet. The LNS may choose not to accept the call if:
LACが着信コールレクエストを送信すると、LNSからの応答を待ちますが、必ずしも電話ネットワークからの電話に応答するわけではありません。LNSは、次の場合に呼び出しを受け入れないことを選択できます。
- No resources are available to handle more sessions - The dialed, dialing, or subaddress fields do not correspond to an authorized user - The bearer service is not authorized or supported
- より多くのセッションを処理するためのリソースはありません - ダイヤル、ダイヤル、またはサブアドレスフィールドは、認可されたユーザーに対応していません - ベアラーサービスは承認またはサポートされていません
If the LNS chooses to accept the call, it responds with an Incoming-Call-Reply. When the LAC receives the Incoming-Call-Reply, it attempts to connect the call. A final call connected message from the LAC to the LNS indicates that the call states for both the LAC and the LNS should enter the established state. If the call terminated before the LNS could accept it, a Call-Disconnect-Notify is sent by the LAC to indicate this condition.
LNSがコールを受け入れることを選択した場合、それは着信コールの繰り返しで応答します。LACが着信コールの繰り返しを受け取ると、コールを接続しようとします。LACからLNSへの最終的なコール接続メッセージは、LACとLNSの両方のコール状態が確立された状態に入る必要があることを示しています。LNSがそれを受け入れる前にコールが終了した場合、この状態を示すためにCall-Disconnect-NotifyがLACによって送信されます。
When the dialed-in client hangs up, the call is cleared normally and the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to clear a call, it sends a Call-Disconnect-Notify message and cleans up its session.
ダイヤルインクライアントが電話を切ると、コールが正常にクリアされ、LACはコールディスコネクトノティイメッセージを送信します。LNSが通話のクリアを希望する場合、Call-Disconnect-Notifyメッセージを送信し、セッションをクリーンアップします。
State Event Action New State
----- ----- ------ ---------
idle Bearer Ring or Initiate local wait-tunnel
Ready to indicate tunnel open
incoming conn.
idle Receive ICCN, Clean up idle
ICRP, CDN
wait-tunnel Bearer line drop Clean up idle or local close request
待機タンネルベアラーラインドロップクリーンアップアイドルまたはローカルクローズリクエスト
wait-tunnel tunnel-open Send ICRQ wait-reply
待機トンネルトンネルオープンは、icrqを送信します
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 Send CDN idle Clean up
icrqを受け取るのを待ってくださいCDNアイドルクリーンアップを送信します
wait-reply Receive CDN Clean up idle ICCN
待機中からCDNクリーンアップアイドルICCNを受信します
wait-reply Local Send CDN, idle close request or Clean up Bearer line drop
待機中心のローカル送信CDN、アイドルクローズリクエスト、またはクリーンアップベアラーラインドロップ
established Receive CDN Clean up idle
確立されたCDNクリーンアップアイドルを受信します
established Receive ICRQ, Send CDN, idle ICRP, ICCN Clean up
確立されたICRQを受信し、CDNを送信し、IDLE ICRPを送信し、ICCNクリーンアップ
established Bearer line Send CDN, idle drop or local Clean up close request
確立されたベアラーラインはCDN、アイドルドロップ、またはローカルクリーンアップの近いリクエストを送信します
The states associated with the LAC for incoming calls are:
着信のためにLACに関連する州は次のとおりです。
idle The LAC detects an incoming call on one of its interfaces. Typically this means an analog line is ringing or an ISDN TE has detected an incoming Q.931 SETUP message. The LAC initiates its tunnel establishment state machine, and moves to a state waiting for confirmation of the existence of a tunnel.
IDLE The LACは、そのインターフェイスの1つで着信コールを検出します。通常、これはアナログラインが鳴っているか、ISDN TEが着信Q.931セットアップメッセージを検出したことを意味します。LACは、トンネル設立状態マシンを開始し、トンネルの存在の確認を待っている状態に移動します。
wait-tunnel In this state the session is waiting for either the control connection to be opened or for verification that the tunnel is already open. Once an indication that the tunnel has/was opened, session control messages may be exchanged. The first of these is the Incoming-Call-Request.
この状態の待機トンネルセッションは、制御接続が開かれるか、トンネルがすでに開いていることを確認するのを待っています。トンネルが開かれた/開かれたことを示すと、セッション制御メッセージが交換される可能性があります。これらの最初のものは、着信後のリクエストです。
wait-reply The LAC receives either a CDN message indicating the LNS is not willing to accept the call (general error or don't accept) and moves back into the idle state, or an Incoming-Call-Reply message indicating the call is accepted, the LAC sends an Incoming-Call-Connected message and enters the established state.
WAT-REPLY LACは、LNSがコールを受け入れないことを示すCDNメッセージ（一般的なエラーまたは受け入れない）のいずれかを受け取り、アイドル状態に戻るか、コールが受け入れられたことを示す受信コールのメッセージ、LACは、着信コールに接続されたメッセージを送信し、確立された状態に入ります。
established Data is exchanged over the tunnel. The call may be cleared following: + An event on the connected interface: The LAC sends a Call-Disconnect-Notify message + Receipt of a Call-Disconnect-Notify message: The LAC cleans up, disconnecting the call. + A local reason: The LAC sends a Call-Disconnect-Notify message.
確立されたデータはトンネルを介して交換されます。コールは次のとおりにクリアされる場合があります。接続されたインターフェイスのイベント：lacは、call-disconnect-notifyメッセージのcall-disconnect-notifyメッセージの受信を送信します。ローカルな理由：LACは、call-disconnect-notifyメッセージを送信します。
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
idle Receive ICCN Clean up idle
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
idle, Receive CDN Clean up idle wait-connect, established
アイドル、CDNクリーンアップアイドル待機接続を受け取る、確立された
wait-connect Local Send CDN, idle established Close request Clean up
待機接続ローカル送信cdn、アイドル確立したクローズリクエストクリーンアップ
established Receive ICRQ, Send CDN idle ICRP, ICCN Clean up
確立されたICRQを受信し、CDNアイドルICRPを送信し、ICCNクリーンアップ
The states associated with the LNS for incoming calls are:
着信のためにLNSに関連する州は次のとおりです。
idle An Incoming-Call-Request message is received. If the request is not acceptable, a Call-Disconnect-Notify is sent back to the LAC and the LNS remains in the idle state. If the Incoming-Call-Request message is acceptable, an Incoming-Call-Reply is sent. The session moves to the wait-connect state.
IDLE入ってくるコールリクエストメッセージが受信されます。リクエストが受け入れられない場合、Call-Disconnect-NotifyがLACに送信され、LNSはアイドル状態に残ります。着信コールリクエストメッセージが受け入れられる場合、受信コールの返金が送信されます。セッションは待機接続状態に移動します。
wait-connect If the session is still connected on the LAC, the LAC sends an Incoming-Call-Connected message to the LNS which then moves into established state. The LAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This could happen, for example, if a telephone user accidentally places a standard voice call to an LAC resulting in a handshake failure on the called modem.
待機接続セッションがまだLACに接続されている場合、LACは着信コール接続のメッセージをLNSに送信し、それが確立された状態に移動します。LACは、Call-Disconnect-Notifyを送信して、着信コールを接続できないことを示します。これは、たとえば、電話ユーザーが誤って標準的な音声コールをLACに配置し、呼び出されたモデムで握手障害をもたらす場合に発生する可能性があります。
established The session is terminated either by receipt of a Call-Disconnect-Notify message from the LAC or by sending a Call-Disconnect-Notify. Clean up follows on both sides regardless of the initiator.
確立されたセッションは、Call-Disconnect-NotifyメッセージをLACから受信するか、Call-Disconnect-Notifyを送信することにより終了します。イニシエーターに関係なく、両側にクリーンアップが続きます。
Outgoing calls are initiated by an LNS and instruct an LAC to place a call. There are three messages for outgoing calls: Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS sends an Outgoing-Call-Request specifying the dialed party phone number, subaddress and other parameters. The LAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the LAC determines that the proper facilities exist to place the call and the call is administratively authorized. For example, is this LNS allowed to dial an international call? Once the outbound call is connected, the LAC sends an Outgoing-Call-Connected message to the LNS indicating the final result of the call attempt:
発信コールはLNSによって開始され、LACに電話をかけるよう指示します。発信コールには3つのメッセージがあります。発信-Call-Request、発信コールリプリー、および発信コール接続です。LNSは、ダイヤルされたパーティーの電話番号、サブアドレス、その他のパラメーターを指定する発信コールリケストを送信します。LACは、Callを配置するために適切な施設が存在し、コールが管理上承認されていると判断した場合、発信コールリクエストメッセージを使用して発信コールリクエストメッセージに応答する必要があります。たとえば、このLNSは国際的な呼び出しをダイヤルすることを許可されていますか？アウトバウンドコールが接続されると、LACはコール試行の最終結果を示す発信コール接続メッセージをLNSに送信します。
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Open bearer
idle Receive OCRQ, Send CDN, idle not acceptable Clean up
アイドルOCRQを受け取り、CDNを送信し、アイドルが受け入れられないクリーンアップ
idle Receive OCRP Send CDN idle
Clean up
idle Receive OCCN, Clean up idle
CDN
wait-cs-answer Bearer answer, Send OCCN established framing detected
Wait-CS-Answer Bearerの回答、OCCN確立されたフレーミングを検出された送信します
wait-cs-answer Bearer failure Send CDN, idle Clean up
wait-cs-annwer bearer故障CDNを送信し、アイドルクリーンアップ
wait-cs-answer Receive OCRQ, Send CDN idle OCRP, OCCN Clean up
wait-cs-annswer ocrqを受け取り、cdnアイドルocrpを送信し、occn cleanup
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クリーンアップのアイドルを確立します
established Bearer line drop, Send CDN, idle Local close Clean up request
確立されたベアラーラインドロップ、CDNの送信、アイドルローカルクローズアップリクエスト
The states associated with the LAC for outgoing calls are:
発信コールのLACに関連する州は次のとおりです。
idle If Outgoing-Call-Request is received in error, respond with a Call-Disconnect-Notify. Otherwise, allocate a physical channel and send an Outgoing-Call-Reply. Place the outbound call and move to the wait-cs-answer state.
IDLE Outing-Call-Requestが誤って受信された場合、Call-Disconnect-Notifyで応答します。それ以外の場合は、物理チャネルを割り当てて、発信コールの繰り返しを送信します。アウトバウンドコールを配置し、Wait-CS-Answer状態に移動します。
wait-cs-answer If the call is not completed or a timer expires waiting for the call to complete, send a Call-Disconnect-Notify with the appropriate error condition set and go to idle state. If a circuit switched connection is established and framing is detected, send an Outgoing-Call-Connected indicating success and go to established state.
Callが完了していない場合、またはCallが完了するのを待っているタイマーが期限切れになった場合は、適切なエラー条件セットでCall-Disconnect-Notifyを送信してアイドル状態に移動します。回路スイッチの接続が確立され、フレーミングが検出された場合は、成功を示す発信コール接続を送信し、確立された状態に移動します。
established If a Call-Disconnect-Notify is received by the LAC, the telco call MUST be released via appropriate mechanisms and the session cleaned up. If the call is disconnected by the client or the called interface, a Call-Disconnect-Notify message MUST be sent to the LNS. The sender of the Call-Disconnect-Notify message returns to the idle state after sending of the message is complete.
Call-Disconnect-NotifyがLACによって受信された場合に確立され、適切なメカニズムを介してTelcoの呼び出しをリリースし、セッションをクリーンアップする必要があります。通話がクライアントまたは呼び出されたインターフェイスによって切断されている場合、call-disconnect-notifyメッセージをLNSに送信する必要があります。メッセージの送信が完了した後、コールディスコネクトノティイメッセージメッセージの送信者がアイドル状態に戻ります。
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
idle Receive OCCN, Clean up idle
OCRP, CDN
wait-tunnel tunnel-open Send OCRQ wait-reply
待機トンネルトンネルオープンは、OCRQを送信します
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
OCRQ Clean up
wait-connect Receive OCCN none established
待機接続は、occnを確立しません
wait-connect Receive OCRQ, Send CDN idle
OCRP Clean up
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 Send CDN idle
wait-connect, Close request Clean up
established
wait-tunnel Local Clean up idle
Close request
The states associated with the LNS for outgoing calls are:
発信コールのLNSに関連する州は次のとおりです。
idle, wait-tunnel When an outgoing call is initiated, a tunnel is first created, much as the idle and wait-tunnel states for an LAC incoming call. Once a tunnel is established, an Outgoing-Call-Request message is sent to the LAC and the session moves into the wait-reply state.
アイドル、待機トンネル発信コールが開始されると、アイドルと待機トンネルがLACのコールのために述べているように、トンネルが最初に作成されます。トンネルが確立されると、発信コールリクエストメッセージがLACに送信され、セッションが待機状態に移動します。
wait-reply If a Call-Disconnect-Notify is received, an error occurred, and the session is cleaned up and returns to idle. If an Outgoing-Call-Reply is received, the call is in progress and the session moves to the wait-connect state.
call-disconnect-notifyが受信された場合、エラーが発生し、セッションがクリーンアップされ、アイドル状態に戻ります。発信コール返済を受け取った場合、通話が進行中で、セッションは待機接続状態に移動します。
wait-connect If a Call-Disconnect-Notify is received, the call failed; the session is cleaned up and returns to idle. If an Outgoing-Call-Connected is received, the call has succeeded and the session may now exchange data.
待機接続コールディスコンコネクトノティイムが受信された場合、コールが失敗しました。セッションはクリーンアップされ、アイドル状態に戻ります。発信コール接続が受信された場合、通話が成功し、セッションがデータを交換できるようになりました。
established If a Call-Disconnect-Notify is received, the call has been terminated for the reason indicated in the Result and Cause Codes; the session moves back to the idle state. If the LNS chooses to terminate the session, it sends a Call-Disconnect-Notify to the LAC and then cleans up and idles its session.
Call-Disconnect-Notifyが受信された場合、結果に示された理由と原因コードで呼び出しが終了しました。セッションはアイドル状態に戻ります。LNSがセッションを終了することを選択した場合、Call-Disconnect-NotifyをLACに送信し、クリーンアップしてセッションをアイドリングします。
The disconnection of a tunnel consists of either peer issuing a Stop-Control-Connection-Notification. The sender of this Notification should wait a finite period of time for the acknowledgment of this message before releasing the control information associated with the tunnel. The recipient of this Notification should send an acknowledgment of the Notification and then release the associated control information.
トンネルの切断は、いずれかのピアがストップコントロール接続と接続の発行を発行することで構成されています。この通知の送信者は、トンネルに関連する制御情報をリリースする前に、このメッセージの承認のために有限の期間を待つ必要があります。この通知の受信者は、通知の承認を送信し、関連する制御情報をリリースする必要があります。
When to release a tunnel 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 tunnel open for a period of time or perhaps indefinitely after the last session for that tunnel is cleared. Others may choose to disconnect the tunnel immediately after the last user connection on the tunnel disconnects.
トンネルをリリースする時期は実装の問題であり、このドキュメントでは指定されていません。特定の実装は、制御接続をいつリリースするかを決定するのに適したポリシーを使用する場合があります。いくつかの実装は、そのトンネルの最後のセッションがクリアされた後、一定期間、またはおそらく無期限にトンネルを開いたままにする場合があります。他の人は、トンネルの切断の最後のユーザー接続の直後にトンネルを切断することを選択する場合があります。
L2TP is self-describing, operating at a level above the media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. The following sections describe details needed to permit interoperability over specific media.
L2TPは自己記述的であり、運ばれているメディアの上のレベルで動作します。ただし、相互運用可能な実装を許可するには、メディアとの接続の詳細が必要です。次のセクションでは、特定のメディアに対する相互運用性を許可するために必要な詳細について説明します。
L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The initiator of an L2TP tunnel 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. Once the source and destination ports and addresses are established, they MUST remain static for the life of the tunnel.
L2TPは、登録されているUDPポート1701 [RFC1700]を使用します。ペイロードとL2TPヘッダーを含むL2TPパケット全体がUDPデータグラム内で送信されます。L2TPトンネルのイニシエーターは、利用可能なソースUDPポート（1701である可能性がある場合とそうでない場合があります）を選択し、ポート1701の目的の宛先アドレスに送信します。受信者は、独自のシステムで無料のポートを選択します（1701）、およびその返信をイニシエーターの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 tunnel, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementors should consider the potential implication of this before before choosing an arbitrary source port.
受信者に任意のソースポートを選択させることが示唆されています（トンネルを開始するパケットで宛先ポートを使用するのではなく、つまり1701）により、L2TPがいくつかのNATデバイスを通過することがより困難になる可能性があります。実装者は、任意のソースポートを選択する前に、これの潜在的な意味を考慮する必要があります。
IP fragmentation may occur as the L2TP packet travels over the IP substrate. L2TP makes no special efforts to optimize this. A LAC implementation MAY cause its LCP to negotiate for a specific MRU, which could optimize for LAC environments in which the MTU's of the path over which the L2TP packets are likely to travel have a consistent value.
L2TPパケットがIP基板上を移動すると、IP断片化が発生する可能性があります。L2TPは、これを最適化するための特別な努力をしません。LACの実装により、LCPは特定のMRUと交渉する可能性があります。これは、L2TPパケットが移動する可能性のあるパスのMTUが一貫した値を持っているLAC環境に最適化できます。
The default for any L2TP implementation is that UDP checksums MUST be enabled for both control and data messages. An L2TP implementation MAY provide an option to disable UDP checksums for data messages. It is recommended that UDP checksums always be enabled on control packets.
L2TP実装のデフォルトは、制御メッセージとデータメッセージの両方でUDPチェックサムを有効にする必要があることです。L2TP実装は、データメッセージのUDPチェックサムを無効にするオプションを提供する場合があります。UDPチェックサムは、制御パケットで常に有効にすることをお勧めします。
Port 1701 is used for both L2F [RFC2341] and L2TP packets. The Version field in each header may be used to discriminate between the two packet types (L2F uses a value of 1, and the L2TP version described in this document uses a value of 2). An L2TP implementation running on a system which does not support L2F MUST silently discard all L2F packets.
ポート1701は、L2F [RFC2341]とL2TPパケットの両方に使用されます。各ヘッダーのバージョンフィールドを使用して2つのパケットタイプを区別できます（L2Fは1の値を使用し、このドキュメントで説明するL2TPバージョンは2の値を使用します）。L2Fをサポートしないシステムで実行されているL2TP実装は、すべてのL2Fパケットを静かに破棄する必要があります。
To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has the characteristic of being able to reorder or silently drop packets. The former may break non-IP protocols being carried by PPP, especially LAN-centric ones such as bridging. The latter may break protocols which assume per-packet indication of error, such as TCP header compression. Sequencing may be handled by using L2TP data message sequence numbers if any protocol being transported by the PPP tunnel cannot tolerate reordering. The sequence dependency characteristics of individual protocols are outside the scope of this document.
L2TPオーバー-UDP/IPトンネルを使用してPPPクライアントに、PPPリンクはパケットを再注文または静かにドロップできるという特徴を持っています。前者は、PPP、特にブリッジングなどのLAN中心のプロトコルによって運ばれている非IPプロトコルを壊す可能性があります。後者は、TCPヘッダー圧縮など、エラーのパケットごとの表示を想定するプロトコルを破壊する可能性があります。PPPトンネルによって輸送されているプロトコルが並べ替えに耐えられない場合、L2TPデータメッセージシーケンス番号を使用してシーケンスを処理できます。個々のプロトコルのシーケンス依存性特性は、このドキュメントの範囲外です。
Allowing packets to be dropped silently is perhaps more problematic with some protocols. If PPP reliable delivery [RFC1663] is enabled, no upper PPP protocol will encounter lost packets. If L2TP sequence numbers are enabled, L2TP can detect the packet loss. In the case of an LNS, the PPP and L2TP stacks are both present within the LNS, and packet loss signaling may occur precisely as if a packet was received with a CRC error. Where the LAC and PPP stack are co-resident, this technique also applies. Where the LAC and PPP client are physically distinct, the analogous signaling MAY be accomplished by sending a packet with a CRC error to the PPP client. Note that this would greatly increase the complexity of debugging client line problems, since the client statistics could not distinguish between true media errors and LAC-initiated ones. Further, this technique is not possible on all hardware.
一部のプロトコルでは、パケットを静かにドロップできるようにすることは、おそらくより問題があります。PPP信頼できる配信[RFC1663]が有効になっている場合、上部PPPプロトコルは失われたパケットに遭遇しません。L2TPシーケンス番号が有効になっている場合、L2TPはパケット損失を検出できます。LNSの場合、PPPおよびL2TPスタックは両方ともLNS内に存在し、パケット損失シグナル伝達はCRCエラーでパケットが受信されたかのように正確に発生する可能性があります。LACおよびPPPスタックが共同住宅である場合、この手法も適用されます。LACおよびPPPクライアントが物理的に異なる場合、PPPクライアントにCRCエラーを備えたパケットを送信することにより、類似のシグナル伝達が実現できます。クライアントの統計は真のメディアエラーとLacInitiatedのエラーを区別できなかったため、これによりクライアントラインの問題をデバッグする複雑さが大幅に向上することに注意してください。さらに、この手法はすべてのハードウェアでは不可能です。
If VJ compression is used, and neither PPP reliable delivery nor sequence numbers are enabled, each lost packet results in a 1 in 2**16 chance of a TCP segment being forwarded with incorrect contents [RFC1144]. Where the combination of the packet loss rate with this statistical exposure is unacceptable, TCP header compression SHOULD NOT be used.
VJ圧縮が使用され、PPPの信頼性の高い配信もシーケンス番号も有効になっていない場合、失われたパケットは2 ** 16分の1 16に、TCPセグメントが間違った内容で転送される可能性があります[RFC1144]。パケット損失率とこの統計的曝露の組み合わせが受け入れられない場合、TCPヘッダー圧縮は使用しないでください。
In general, it is wise to remember that the L2TP/UDP/IP transport is an unreliable transport. As with any PPP media that is subject to loss, care should be taken when using protocols that are particularly loss-sensitive. Such protocols include compression and encryption protocols that employ history.
一般に、L2TP/UDP/IPトランスポートは信頼できない輸送であることを覚えておくのが賢明です。損失の影響を受けるPPPメディアと同様に、特に損失に敏感なプロトコルを使用する場合は、注意が必要です。このようなプロトコルには、履歴を使用する圧縮および暗号化プロトコルが含まれます。
When operating in IP environments, L2TP MUST offer the UDP encapsulation described in 8.1 as its default configuration for IP operation. Other configurations (perhaps corresponding to a compressed header format) MAY be defined and made available as a configurable option.
IP環境で動作する場合、L2TPは、IP操作のデフォルト構成として8.1で説明されているUDPカプセル化を提供する必要があります。他の構成（おそらく圧縮ヘッダー形式に対応）を定義し、構成可能なオプションとして利用できるようにすることができます。
L2TP encounters several security issues in its operation. The general approach of L2TP to these issues is documented here.
L2TPは、その運用にいくつかのセキュリティ問題に遭遇します。これらの問題に対するL2TPの一般的なアプローチは、ここに文書化されています。
The tunnel endpoints may optionally perform an authentication procedure of one another during tunnel establishment. This authentication has the same security attributes as CHAP, and has reasonable protection against replay and snooping during the tunnel establishment process. This mechanism is not designed to provide any authentication beyond tunnel establishment; it is fairly simple for a malicious user who can snoop the tunnel stream to inject packets once an authenticated tunnel establishment has been completed successfully.
トンネルのエンドポイントは、トンネルの確立中に互いに認証手順を実行する場合があります。この認証は、CHAPと同じセキュリティ属性を持ち、トンネルの確立プロセス中にリプレイとスヌーピングに対して合理的な保護を持っています。このメカニズムは、トンネルの確立を超えた認証を提供するようには設計されていません。認証されたトンネルの確立が正常に完了したら、トンネルストリームをスヌープしてパケットを注入できる悪意のあるユーザーにとっては、かなり簡単です。
For authentication to occur, the LAC and LNS MUST share a single secret. Each side uses this same secret when acting as authenticatee as well as authenticator. Since a single secret is used, the tunnel authentication AVPs include differentiating values in the CHAP ID fields for each message digest calculation to guard against replay attacks.
認証が発生するには、LACとLNSが単一の秘密を共有する必要があります。それぞれの側は、AuthenticateeおよびAuthenticatorとして行動するときにこの同じ秘密を使用します。単一の秘密が使用されているため、トンネル認証AVPには、リプレイ攻撃を防ぐために、各メッセージダイジェスト計算のchap IDフィールドの区別値が含まれます。
The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3) SHOULD be selected in an unpredictable manner rather than sequentially or otherwise. Doing so will help deter hijacking of a session by a malicious user who does not have access to packet traces between the LAC and LNS.
割り当てられたトンネルIDと割り当てられたセッションID（セクション4.4.3を参照）は、順次またはその他ではなく、予測不可能な方法で選択する必要があります。そうすることで、LACとLNSの間のパケットトレースにアクセスできない悪意のあるユーザーによるセッションのハイジャックを阻止できます。
Securing L2TP requires that the underlying transport make available encryption, integrity and authentication services for all L2TP traffic. This secure transport operates on the entire L2TP packet and is functionally independent of PPP and the protocol being carried by PPP. As such, L2TP is only concerned with confidentiality, authenticity, and integrity of the L2TP packets between its tunnel
L2TPを保護するには、基礎となる輸送がすべてのL2TPトラフィックで利用可能な暗号化、整合性、および認証サービスを提供する必要があります。この安全なトランスポートは、L2TPパケット全体で動作し、PPPとPPPによって運ばれるプロトコルと機能的に独立しています。そのため、L2TPは、トンネル間のL2TPパケットの機密性、信頼性、および完全性のみに関係しています
endpoints (the LAC and LNS), not unlike link-layer encryption being concerned only about protecting the confidentiality of traffic between its physical endpoints.
エンドポイント（LACおよびLNS）。リンク層暗号化は、物理エンドポイント間のトラフィックの機密性を保護することだけに関係しているのとは異なります。
Protecting the L2TP packet stream via a secure transport does, in turn, also protect the data within the tunneled PPP packets while transported from the LAC to the LNS. Such protection should not be considered a substitution for end-to-end security between communicating hosts or applications.
安全なトランスポートを介してL2TPパケットストリームを保護すると、LACからLNSに輸送されている間、トンネル付きPPPパケット内のデータも保護します。このような保護は、ホストまたはアプリケーションの通信の間のエンドツーエンドのセキュリティの代替と見なされるべきではありません。
When running over IP, IPsec provides packet-level security via ESP and/or AH. All L2TP control and data packets for a particular tunnel appear as homogeneous UDP/IP data packets to the IPsec system.
IPを実行するとき、IPSECはESPおよび/またはAHを介してパケットレベルのセキュリティを提供します。特定のトンネルのすべてのL2TP制御とデータパケットは、IPSECシステムに均一なUDP/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 Transport Securityに加えて、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 is logically performed at the PPP layer or network layer above L2TP. These network layer access control features may be handled at the LNS via vendor-specific authorization features based upon the authenticated PPP user, 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の上のPPP層またはネットワーク層で類似のフィルタリングが論理的に実行されます。これらのネットワークレイヤーアクセス制御機能は、認証されたPPPユーザーに基づくベンダー固有の認証機能を介してLNSで処理される場合があります。アクセス制御メカニズムの要件はL2TP仕様の一部ではなく、このドキュメントの範囲外です。
L2TP defines AVPs that MAY be exchanged during session establishment to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation (see Section 4.4.5). This implies a direct trust relationship of the LAC on behalf of the LNS. If the LNS chooses to implement proxy authentication, it MUST be able to be configured off, requiring a new round a PPP authentication initiated by the LNS (which may or may not include a new round of LCP negotiation).
L2TPは、セッションの確立中に交換される可能性のあるAVPを定義し、検証のためにLACで得られたPPP認証情報の転送をLNSに提供します（セクション4.4.5を参照）。これは、LNSに代わってLACの直接的な信頼関係を意味します。LNSがプロキシ認証を実装することを選択した場合、LNSによって開始された新しいラウンドA PPP認証（LCP交渉の新しいラウンドが含まれる場合と含まれない場合があります）を設定できる必要があります。
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria to be 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が使用する基準について説明します。次のサブセクションでは、このドキュメントの他の場所で定義されている名前空間の割り当てポリシーについて説明します。
As defined in Section 4.1, AVPs contain vendor ID, Attribute and Value fields. For vendor ID value of 0, IANA will maintain a registry of assigned Attributes and in some case also values. Attributes 0-39 are assigned as defined in Section 4.4. The remaining values are available for assignment through IETF Consensus [RFC 2434].
セクション4.1で定義されているように、AVPにはベンダーID、属性、および値フィールドが含まれています。0のベンダーID値の場合、IANAは割り当てられた属性のレジストリを維持し、場合によっては値も維持します。属性0-39は、セクション4.4で定義されているように割り当てられます。残りの値は、IETFコンセンサス[RFC 2434]を通じて割り当てに利用できます。
As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0) have an associated value maintained by IANA. Values 0-16 are defined in Section 3.2, the remaining values are available for assignment via IETF Consensus [RFC 2434]
セクション4.4.1で定義されているように、メッセージタイプAVP（属性タイプ0）には、IANAが維持する関連値があります。値0-16はセクション3.2で定義され、残りの値はIETFコンセンサス[RFC 2434]を介して割り当てに利用できます
As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1) contain three fields. Two of these fields (the Result Code and Error Code fields) have associated values maintained by IANA.
セクション4.4.2で定義されているように、結果コードAVP（属性タイプ1）には3つのフィールドが含まれています。これらのフィールドのうち2つ（結果コードとエラーコードフィールド）には、IANAによって維持されている関連する値があります。
The Result Code AVP may be included in CDN and StopCCN messages. The allowable values for the Result Code field of the AVP differ depending upon the value of the Message Type AVP. For the StopCCN message, values 0-7 are defined in Section 4.4.2; for the StopCCN message, values 0-11 are defined in the same section. The remaining values of the Result Code field for both messages are available for assignment via IETF Consensus [RFC 2434].
結果コードAVPは、CDNおよびSTOPCCNメッセージに含まれる場合があります。AVPの結果コードフィールドの許容値は、メッセージタイプAVPの値によって異なります。STOPCCNメッセージの場合、値0-7はセクション4.4.2で定義されています。STOPCCNメッセージの場合、同じセクションで値0〜11が定義されています。両方のメッセージの結果コードフィールドの残りの値は、IETFコンセンサス[RFC 2434]を介して割り当てに使用できます。
Values 0-7 are defined in Section 4.4.2. Values 8-32767 are available for assignment via IETF Consensus [RFC 2434]. The remaining values of the Error Code field are available for assignment via First Come First Served [RFC 2434].
値0-7は、セクション4.4.2で定義されています。値8-32767は、IETFコンセンサス[RFC 2434]を介して割り当てに利用できます。エラーコードフィールドの残りの値は、First Come First Server [RFC 2434]を介して割り当てに使用できます。
The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in Section 4.4.3) both contain 32-bit bitmasks. Additional bits should only be defined via a Standards Action [RFC 2434].
フレーミング機能AVPおよびベアラー機能AVP（セクション4.4.3で定義）には、両方とも32ビットビットマスクが含まれています。追加のビットは、標準アクション[RFC 2434]を介してのみ定義する必要があります。
The Proxy Authen Type AVP (Attribute Type 29) has an associated value maintained by IANA. Values 0-5 are defined in Section 4.4.5, the remaining values are available for assignment via First Come First Served [RFC 2434].
Proxy AuthenタイプAVP（属性タイプ29）は、IANAによって維持される関連値を持っています。値0-5はセクション4.4.5で定義されており、残りの値はFirst Come First Server [RFC 2434]を介して割り当て可能です。
There are four remaining reserved bits in the AVP header. Additional bits should only be assigned via a Standards Action [RFC 2434].
AVPヘッダーには4つの残りのビットがあります。追加のビットは、標準アクション[RFC 2434]を介してのみ割り当てられる必要があります。
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998
[DSS1] ITU-Tの推奨、「デジタルサブスクライバーシグナリングシステムNo. 1（DSS 1）-ISDNユーザーネットワークインターフェイスレイヤー3基本コールコントロールの仕様」、Rec。Q.931（I.451）、1998年5月
[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。、「ネットワークセキュリティ：公共界のプライベートコミュニケーション」、1995年3月、ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1663] Rand、D。、「PPP信頼できる伝送」、RFC 1663、1994年7月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[RFC1700] Reynolds、J。and J. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。http：//www.iana.org/numbers.html [rfc1990] Sklower、K。Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（MP）」、RFC 1990、1996年8月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年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月。
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RFC2138] Rigney、C.、Rubens、A.、Simpson、W。およびS. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[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月。
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2341] Valencia、A.、Littlewood、M。、およびT. Kolar、「Cisco Layer Two Forwarding（Protocol）L2F」、RFC 2341、1998年5月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[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、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、Pall、G.、Verthein、W.、Taarud、J.、Little、W。and G. Zorn、「ポイントツーポイントトンネルプロトコル（PPTP）」、RFC 2637、1999年7月。
[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
The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn.
L2TPおよびそのプロトコルコンストラクトの多くの基本概念は、L2F [RFC2341]およびPPTP [PPTP]から採用されました。これらの著者は、A。バレンシア、M。リトルウッド、T。コラー、K。ハムゼ、G。ポール、W。ヴェルテイン、J。タアルド、W。リトル、およびG.ゾーンです。
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of this document.
Dory Leiferは、L2TPのプロトコル定義に貴重な改良を加え、このドキュメントの編集に貢献しました。
Steve Cobb and Evan Caves redesigned the state machine tables.
Steve CobbとEvan Cavesが州の機械のテーブルを再設計しました。
Barney Wolff provided a great deal of design input on the endpoint authentication mechanism.
Barney Wolffは、エンドポイント認証メカニズムに関する多くの設計入力を提供しました。
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 this document.
ジョン・ブレイ、グレッグ・バーンズ、リッチ・ギャレット、ドン・グロッサー、マット・ホールデージ、テリー・ジョンソン、ドリー・ライファー、リッチ・シアは、フロリダ州オーランドの第43 IETFで貴重なインプットとレビューを提供しました。このドキュメント。
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
Gurdeep Singh Pall Microsoft Corporation Redmond、WA
EMail: gurdeep@microsoft.com
Bill Palter RedBack Networks, Inc 1389 Moffett Park Drive Sunnyvale, CA 94089
Bill Palter Redback Networks、Inc 1389 Moffett Park Drive Sunnyvale、CA 94089
EMail: palter@zev.net
Allan Rubens Ascend Communications 1701 Harbor Bay Parkway Alameda, CA 94502
アラン・ルーベンスアセンドコミュニケーション1701ハーバーベイパークウェイアラメダ、カリフォルニア94502
EMail: acr@del.com
W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークタウンズリーシスコシステム7025キットクリークロードPOボックス14987リサーチトライアングルパーク、ノースカロライナ州27709
EMail: townsley@cisco.com
Andrew J. Valencia cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
アンドリューJ.バレンシアシスコシステム170ウェストタスマンドライブサンノゼCA 95134-1706
EMail: vandys@cisco.com
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052
Glen Zorn Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: gwz@acm.org
Appendix A: Control Channel 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].
各側は受信ウィンドウの最大サイズを示していますが、制御パケットを送信するために、ゆっくりとした開始と輻輳回避方法を使用することをお勧めします。ここで説明する方法は、W。リチャードスティーブンス[スティーブンス]によるTCP/IPイラストのセクション21.6、ボリュームIのセクション21.6で説明されているように、TCP輻輳回避アルゴリズムに基づいています。
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は、受信ウィンドウ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 acknowledgement (either explicit or piggybacked). When the acknowledgement 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 ZLB 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（明示的なZLBまたはピギーバック）を受信するたびに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の新しいAcksを受信した後、CWNDは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 tunnel establishment
B.1：ロックステップトンネルの確立
In this example, an LAC establishes a tunnel, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within a ZLB ACK message. An alternative would be to piggyback the acknowledgement within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the tunnel.
この例では、LACがトンネルを確立し、メッセージの送信に交互に交換する交換が行われます。この例は、ZLB ACKメッセージ内で明示的に送信された最終的な承認を示しています。別の方法は、トンネルを開始した側から続く可能性が高いICRQまたはOCRQへの返信として送信されたメッセージ内の承認を貯金詰めすることです。
LAC or LNS LNS or LAC
---------- ----------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1
B.2: Lost packet with retransmission
B.2：再送信によるパケットの紛失
An existing tunnel has a new session requested by the LAC. The ICRP is lost and must be retransmitted by the LNS. Note that loss of the ICRP has two impacts: not only does it keep the upper level state machine from progressing, but it also keeps the LAC from seeing a timely lower level acknowledgment of its ICRQ.
既存のトンネルには、LACが要求した新しいセッションがあります。ICRPは失われ、LNSによって再送信される必要があります。ICRPの損失には2つの影響があることに注意してください。上位レベルの状態マシンが進行しないようにするだけでなく、LACがICRQのタイムリーな低レベルの認識を把握することも妨げないことに注意してください。
LAC LNS --- ---
lac lns --- ---
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LAC's timer started first, so fires first)
（一時停止;ラックのタイマーが最初に始まったので、最初に火が発生します）
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet, the LNS discards the packet and sends a ZLB)
（このパケットをすでに見ていることに気付いて、LNSはパケットを破棄し、ZLBを送信します）
<- ZLB
Nr: 3, Ns: 2
(LNS's retransmit timer fires)
（LNSの再送信タイマー火災）
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ZLB
Nr: 4, Ns: 2
Appendix C: Intellectual Property Notice
付録C：知的財産通知
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat."
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。」
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。