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"
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.
著作権（C）インターネット協会（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）、ポイントツーポイントリンクを輸送するためのカプセル化メカニズムを定義します。典型的には、ユーザは、技術（例えば、ダイヤルアップPOTS、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、等）、及び濃縮器は、次にNASに個々のPPPフレームをトンネルにL2接続を有しています。これは、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はまた、マルチリンクハントグループの分割問題を解決することがあります。マルチリンクPPP [RFC1990]はマルチリンクバンドルを構成する全てのチャンネルが単一のネットワーク・アクセス・サーバ（NAS）にグループ化されることを要求します。それは物理的に受信されたポイント以外の場所にPPPセッションを投影するその能力に起因して、L2TPは、全てのチャンネルが単一のNASで終端するために使用することができます。これは、コールが異なる物理のNASにまたがっていてもマルチリンク操作ができます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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
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]、平文パスワードがライン上を通過されていない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とリモートシステムとの間に位置し、および各々のパケットを転送します。この文書で定義されてLNSにLACから送信されたパケットは、L2TPプロトコルトンネリングを必要とします。またはPPPリンク：リモートシステムへのLACからの接続は、ローカル（クライアントLACを参照）のいずれかです。
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
CAN
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によって開始または応答される各コールの状態を維持します。エンドツーエンドのPPP接続がリモートシステムとLNSの間で確立されたときにL2TPセッションがLACとLNSの間で作成されます。 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ペアの間に存在します。トンネルは制御接続と0個以上のL2TPセッションで構成されています。トンネルはLACとLNS間に封入PPPデータグラムと制御メッセージを運びます。
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
リモートシステムは、LACにPSTNクラウド間でPPP接続を開始します。 LACは、ホームLANへのアクセスが得られるLNSへのインターネット、フレームリレー、ATMクラウド間でPPP接続をトンネルします。リモートシステムは、家庭内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 Clientソフトウェアを含むホストは、すでに公共のインターネットへの接続を持っています。 「仮想」PPP接続は、その後に作成され、ローカルのL2TP LAC Clientソフトウェアは、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フレームをカプセル化するために使用されます。制御メッセージは、（詳細はセクション5.1を参照）の配信を保証するためにL2TP以内に信頼性の高い制御チャネルを利用しています。パケットロスが発生した場合、データメッセージが再送されていません。
+-------------------+
| 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ヘッダと、パケットトランスポートすることにより、第1カプセル化パケットトランスポート。
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）ビットは、メッセージのタイプを示します。これはデータメッセージと制御メッセージの1を0に設定されています。
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.
配列は、（S）ビットが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.
オフセット（OF）ビットが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.
版は、この文書に記載されたL2TPデータメッセージヘッダのバージョンを示す、2でなければなりません。それらはL2TPパケットと混在到着するべき値1はL2F [RFC2341]パケットの検出を可能にするために予約されています。不明Ver分野で受信したパケットを捨てなければなりません。
The Length field indicates the total length of the message in octets.
Lengthフィールドは、オクテットでメッセージの全長を示します。
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との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のAVPとして交換されています。
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は、ゼロで始まり、送信されたメッセージごとに1（モジュロ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は、受信される次の制御メッセージに期待シーケンス番号を示します。メッセージが受信さプラス1（モジュロ2 ** 16）に次したがって、Nrの最後のNs個に設定されています。 （Sビットによって示されるように）、本、受信時には無視されなければならない場合、データメッセージにおいて、Nrが、予約されています。制御メッセージには、このフィールドを使用しての詳細については、セクション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からのリコールは、それは、1に設定さTビットを有するメッセージです。
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.14を介して6.1節を参照）を定義します。
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）制御開始-接続要求2（SCCRP）スタートコントロール接続回答3（SCCCN）を起動コントロール接続接続4（StopCCN）を停止コントロール接続通知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）発信コールリクエスト8（OCRP）発信コールリプライ9（OCCN）発信呼接続10（ICRQ）着信リクエスト11（ICRP）着信リプライ12（ICCN）着信-Call接続13（予約）14（CDN）は、コール切断、通知します
Error Reporting
エラー報告
15 (WEN) WAN-Error-Notify
15（WEN）WAN誤り通知
PPP Session Control
PPPセッション制御
16 (SLI) Set-Link-Info
16（SLI）を設定し、リンク情報
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ビットは、この文書で定義され、残りは将来の拡張のために予約されています。予約ビットアンAVP 0に設定しなければなりません1に設定された予約ビットが認識されていない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を受信する実装に必要な動作を制御します。 Mビットは、特定のセッションに関連付けられたメッセージ内の認識されていないAVPに設定されている場合、このメッセージに関連付けられたセッションは終了されなければなりません。 Mビットは、全体的なトンネルに関連付けられたメッセージ内の認識されていないAVPに設定されている場合、全体のトンネル（および内のすべてのセッション）が終了しなければなりません。 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.
隠された（H）ビット：AVPの属性値フィールドのデータの隠蔽を識別します。この機能は、AVPでクリアテキストとして、そのようなユーザパスワードなどの機密データの受け渡しを回避するために使用することができます。 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 +としてオクテットの属性値フィールドの長さを計算することができます。フィールド自体は、単一のAVPデータ1023オクテットの最大を可能に、10ビットです。長さが6である場合にAVPの最小の長さは、次に、属性値フィールドが存在しない、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：「SMIネットワークマネージメント私企業コード」[RFC1700]の値割り当てられたIANA。採用された属性値をIETFに対応する値0は、このドキュメント内で定義されたすべてのAVPのために使用されます。自分のL2TP拡張子を実装したい任意のベンダーは、彼らが他のベンダーの拡張子を持つ、また将来のIETFの拡張と衝突しないことを保証し、民間の属性値と一緒に、独自のベンダーIDを使用することができます。こうして第65,535企業にこの機能を制限し、ベンダーIDのために割り当てられた16ビットがあることに留意されたいです。
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を送信ピアの完全な責任であります状況。 Mビットのセット、特にベンダー固有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ビットの使用は、AVPを送信、またはMビットが設定されていないと送信されないいずれかのように、関連する機能を無効に設定する能力を提供しなければなりません。
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の内容が隠された又は平文で存在しているかどうかを受信ピアに示すためのメカニズムを提供します。この機能は、ユーザのパスワードやユーザ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
共有秘密は、LACとLNSとの間に存在する場合、Hビットのみ設定しなければなりません。共有秘密は、トンネル認証（セクション5.1.1を参照）に使用される同一の秘密です。 Hビットがいずれかで設定されている場合
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.
与えられた制御メッセージ内のAVP（s）は、ランダムベクトルAVPは、メッセージ中に存在しなければならず、1のHビットを有する第一の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値を非表示にすることは、いくつかのステップで行われます。最初のステップは、次のように隠されたAVP Subformatでにそれらを元の（平文）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ハッシュ値は、最初の16オクテット（以下）隠されたAVP SubformatでのセグメントとXORし、隠しAVPの属性値フィールドに置かれます。隠されたAVP Subformatが16の未満の八重奏であるならば、Subformatでは、属性値フィールドはXOR前に16個のオクテットに水増しされたかのように変換されますが、Subformatで中に存在する唯一の実際のオクテットが変更され、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.
Subformatでは16オクテットより長い場合、第2の一方向MD5ハッシュは最初のXORの結果に続いて、共有秘密から成るオクテットのストリームを介して計算されます。そのハッシュは、第16オクテット（以下）SubformatでのセグメントとXORし、隠されたAVPのValueフィールドの対応するオクテットに配置されます。
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:
隠ぺい方法は、RFC 2138からカウフマン、パールマンとSpeciner [KPS]の著書「ネットワークセキュリティ」のセクション「平文でミキシング」から取られた[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.
共有シークレットSを呼び出し、ランダムベクトルRV、および属性値AV。最後の1でなど、16オクテット塊P1、P2に値フィールドを破るには、16オクテット境界にランダムデータで終わりで埋め。暗号文ブロック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のためのAttribute Value分野には、以下の形式になっています。
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.
メッセージタイプAVP内の必須（M）ビットは、特別な意味を持っています。むしろ、認識されない場合にAVP自体が無視されるべきか否かの指示よりも、制御メッセージ自体が無視されるべきかどうかの指標です。 Mビットは、メッセージタイプAVP内に設定され、メッセージタイプが実装にとって未知である場合したがって、トンネルはクリアされなければなりません。 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のためのAttribute Value分野には、以下の形式になっています。
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オクテットのランダムベクトルを推奨しているがランダムオクテットストリングは、任意の長さのものであってもよいです。文字列には、隠されたAVP（セクション4.2を参照）の属性値を取得したり、非表示にするにはMD5ハッシュを計算する際に使用するためにランダムなベクトルが含まれています。
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は、Hビットセットを有する第1の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ビットは、（Hビットは0でなければなりません）このAVPは隠されてはいけませんを1に設定しなければなりません。この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のためのAttribute Value分野には、以下の形式になっています。
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
結果コードは、2オクテットの符号なし整数です。オプションのエラーコードは、2オクテットの符号なし整数です。オプションのエラーメッセージは、エラーコード欄に従うことができます。エラーコードの存在と
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].
メッセージはAVP Lengthフィールドで示されています。エラーメッセージは、条件に関連付けられ、さらに（人間が読める）テキストを提供する任意の文字列が含まれています。すべてのエラーメッセージでは、人間が読めるテキストは、デフォルト言語[RFC2277]を使用してUTF-8文字セットに提供しなければなりません。
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でなければならない）隠されてはなりません。エラーコードやメッセージ、10が存在しない場合がある場合、エラーコードとエラー・メッセージまたはエラーメッセージの10 +長さがある場合、このAVPのためのMビットは、長さが8である1に設定しなければなりませんエラーコードとメッセージ。
Defined Result Code values for the StopCCN message are:
StopCCNメッセージのための定義されたResult Code値は以下のとおりです。
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を確立することが許可されていない - リクエスタのプロトコルバージョンはサポートされていません有限状態機械誤り - リクエスタ7をシャットダウンされている - エラー・コードは、最も高いバージョン6がサポートさを示しています
Defined Result Code values for the CDN message are:
CDNメッセージのための定義されたResult Code値は以下のとおりです。
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の損失に切断 - エラーコード3に示されている理由で切断コール - コール、利用可能な（一時的な状態）である適切な施設がないために失敗した5 - - 管理上の理由4のために切断電話コール失敗無効な宛先7 - - 、利用可能な（永久的な条件）6である適切な施設の不足に電話による無担体に失敗8を検出 - によるビジー信号9の検出に失敗したコール - コールによるダイヤルトーン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のためにまだ存在していない - 長さが間違って3ない - フィールド値の一範囲外であった、または予約済みフィールドが非ゼロ4であった - これで、この操作を処理するためにリソース不足を5 - セッションIDは、このコンテキスト6で無効である - 一般的なベンダー固有のエラーがLAC 7で発生した - 別のものを試してみてください。 LACは、他の可能なLNS先を認識している場合、それはそれらのいずれかを試してみてください。これは、例えば、マルチリンクPPPバンドルの存在をLNSポリシーに基づいてLACを案内するために使用することができます。 8 - セッションまたはトンネル（セクション4.2を参照）により、Mビットが設定された未知のAVPの受信にシャットダウンました。エラーメッセージは、（人間が読める）テキスト形式で問題の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のためのAttribute Value分野には、以下の形式になっています。
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.
版フィールドが値1改訂フィールドを含む1つのオクテットの符号なし整数これは、L2TPプロトコルバージョン1、リビジョン0メモこれはヘッダに含まれている同一のバージョン番号ではないに関係0を含む1つのオクテットの符号なし整数であります各メッセージの。
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ビットは、このAVPの長さが8である1に設定しなければなりません。
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のためのAttribute Value分野には、以下の形式になっています。
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.
属性値フィールドが定義された2つのビットを有する32ビット・マスクです。ビット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ビットのLength（隠れることの前の）は10である1に設定しなければなりません。
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.
ベアラ能力のAVP、属性タイプ4は、発信呼のために送信者のハードウェアインタフェースでサポートされているベアラデバイスタイプの表示ピアを提供します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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.
2つのビットが定義して、これは、32ビット・マスクです。ビット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から受信AVPベアラ能力でアドバタイズしない装置タイプのためのベアラタイプ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は、着信および発信コールを処理するためのハードウェアデバイスをサポートせず、したがって、0にこのAVPのAおよびDビットを設定する必要があり、または全く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ビットのLength（隠れることの前の）は10である1に設定しなければなりません。
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.
タイブレーカAVP、属性タイプ5は、送信者が与えられたLAC-LNSペアの間に存在する単一のトンネルを望むことを示します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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がピアに送信されたかどうかを確認する必要があり、そうであれば、受信した1つでそのタイブレーク値を比較しなければなりません。低い値「勝利」、および「敗者」は静かにそのトンネルを捨てなければなりません。タイ・ブレーカーは、両側に存在し、その値が等しい場合には、双方がそのトンネルを捨てなければなりません。
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ビットは、このAVPの長さは14であり、0に設定されなければなりません。
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のためのAttribute Value分野には、以下の形式になっています。
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ビットのLength（隠れることの前の）は8である0に設定しなければなりません。
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のためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの長さは6プラスホスト名の長さである1に設定しなければなりません。
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のためのAttribute Value分野には、以下の形式になっています。
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文字セットで提供されなければなりません。
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ビットは、このAVPの（隠れ前）0までの長さを設定しなければならないベンダー名の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のためのAttribute Value分野には、以下の形式になっています。
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がピアから受信された割り当てられたトンネル前に、メッセージは、すべての制御メッセージのヘッダに0のトンネルID値とそのピアに送信されなければなりません。
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を受信する前にStopCCNが送信された場合でも適切なトンネルを識別するためにピアを可能に、受信ピアに送信された割り当てられたトンネル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のためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの長さが8である1に設定しなければなりません。
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は、発行ピアはCHAPスタイルの認証メカニズムを使用して、トンネルエンドポイントを認証することを望むことを示しています。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠蔽前の）1までの長さを設定しなければならないチャレンジの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のためのAttribute Value分野には、以下の形式になっています。
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.
応答は、チャレンジにCHAPスタイル[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).
課題は先行SCCRQ、またはSCCRPで受信された場合には、このAVPはSCCRP又はSCCCN中に存在していなければなりません。 CHAP応答計算におけるID値の目的のために、このメッセージのメッセージタイプAVPの値（例えば2 SCCRP、および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.
コードAVP、属性タイプ12原因Q.931は、迷惑呼切断の場合には追加情報を提供するために使用されます。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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メッセージコード（例えば、DISCONNECT）が原因。両方の値は、ネイティブ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のためのAttribute Value分野には、以下の形式になっています。
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
割り当てられたセッションID AVPは、LNSとLACの間にトンネルを介して送信されたデータを多重化及び逆多重化するために使用する値を設定しています。 L2TPピアは、それが続いて、このセッションに属するトンネルを介して送信するすべての制御およびデータメッセージのセッションIDヘッダフィールドにこの値を置かなければなりません。の前に
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をピアから受信され、メッセージは、すべての制御メッセージのヘッダに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は、最初のCDNが割り当てられたセッションIDを受信する前に送信された場合でも適切なトンネルを識別するためにピアを可能に用いられる受信ピアに送信されます。
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のためのAttribute Value分野には、以下の形式になっています。
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のためのAttribute Value分野には、以下の形式になっています。
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ビット値は、ビット毎秒での速度を示しています。
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のためのAttribute Value分野には、以下の形式になっています。
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ビット値は、ビット毎秒での速度を示しています。
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のためのAttribute Value分野には、以下の形式になっています。
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.
ベアラタイプコール（ICRQ）または呼び出し（OCRQ）のために必要なのベアラ能力を示す32ビットのビットマスクです。設定した場合、ビットAは、呼がアナログ・チャネルを指すことを示しています。設定した場合、ビットDは、コールがディジタル・チャネルを指すことを示しています。両方は、コールがいずれか区別できなかった、またはチャネルのいずれかのタイプに配置することができることを示し、設定することができます。
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は、制御接続確立時LACから受信したベアラ能力に設定された場合、このAVPのValueフィールドのビットのみOCRQため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のためのAttribute Value分野には、以下の形式になっています。
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].
フレーミングタイプOCRQに要求PPPフレーミングのタイプ、またはOCCN又はICCNために交渉PPPフレーミングのタイプを示す32ビット・マスクです。フレーミングタイプは、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は、制御接続確立時LACから受信フレーミング機能に設定された場合、このAVPのValueフィールドのビットのみOCRQため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のためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠蔽前の）1までの長さを設定しなければならない着信番号の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のためのAttribute Value分野には、以下の形式になっています。
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文字列です。 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 Calling Number.
このAVPは、（Hビットは0または1であってもよい）に隠されてもよいです。このAVPのためのMビットは、このAVPの（隠蔽前の）1までの長さを設定しなければならない呼出番号の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のためのAttribute Value分野には、以下の形式になっています。
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文字列です。 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 Sub-Address.
このAVPは、（Hビットは0または1であってもよい）に隠されてもよいです。このAVPのためのMビットは、このAVPの（隠蔽前の）1までの長さを設定しなければならないサブアドレスの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のためのAttribute Value分野には、以下の形式になっています。
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はbps単位で速度を示す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接続スピードAVPが存在する場合、このAVPの値は、送信を表しはLAC（例えば、データが遠隔システムにLACから流れる）の観点から、速度を接続します。任意のRx接続スピード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の接続速度（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の接続スピードAVP、属性タイプ38は、LAC（例えばデータはLACへのリモートシステムから流れる）の観点からの接続の速度を表します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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はbps単位速度を示す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ビットは、このAVPの（隠れ前）0に長さを設定しなければならない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のためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠れ前）0に長さを設定しなければならない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のためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠れ前）0までの長さを設定しなければならない民間グループIDの6を加えた長さです。
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ビットは、このAVPの長さは6である1に設定しなければなりません。
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.
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.
初期のReceived LCP CONFREQ AVP、属性タイプ26では、PPPピアからLACで受信された初期CONFREQとLNSを提供します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠れ前）0までの長さを設定しなければならない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.
最後にPPPピアにLACによって送られた最終CONFREQとLNSを提供し、LCP CONFREQ AVP、属性タイプ27を送りました。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠れ前）0までの長さを設定しなければならない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で受信された最終CONFREQとLNSを提供します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの（隠れ前）0までの長さを設定しなければならないCONFREQの6を加えた長さです。
Proxy Authen Type (ICCN)
プロキシのAuthenタイプ（ICCN）
The Proxy Authen Type AVP, Attribute Type 29, determines if proxy authentication should be used.
プロキシ認証を使用する必要がある場合は、プロキシのAuthen Type AVPの、属性タイプ29は、決定します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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)
定義されたのAuthenタイプの値は次のとおりです。0 - リザーブ1 - テキストのユーザー名/パスワードの交換2 - PPP CHAP 3 - PPP PAP 4 - 認証なし5 - マイクロソフトCHAPバージョン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が存在しなければなりません。それが存在しない場合、クライアントは既にプロキシLCP AVP場合によって決定されてもよいLAC（この段階に入っている場合、このピアがLNSで認証フェーズの再起動を必要とする、プロキシ認証を実行できないことが想定されます存在）。
Associated AVPs for each type of authentication follow.
認証フォローの種類ごとに関連のAVP。
Proxy Authen Name (ICCN)
プロキシのAuthen名（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のためのAttribute Value分野には、以下の形式になっています。
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.
AUTHEN名は任意の長さのオクテット文字列です。これは、クライアントの認証応答で指定された名前が含まれています。
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は、クリアテキスト名を不明瞭にするための隠しAVPを採用することが望ましいかもしれない1、2、3または5ののAuthenタイプのプロキシのAuthenタイプ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)
プロキシのAuthenチャレンジ（ICCN）
The Proxy Authen Challenge AVP, Attribute Type 31, specifies the challenge sent by the LAC to the PPP Peer, when using proxy authentication.
プロキシのAuthenチャレンジAVP、属性タイプ31は、プロキシ認証を使用する場合、PPPピアにLACによって送られた挑戦を指定します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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.
チャレンジは、一つ以上のオクテットの文字列です。
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は、プロキシのAuthenタイプ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ビットはこのAVPの0（隠れることの前）の長さに設定されなければならない6であり、プラスチャレンジの長さ。
Proxy Authen ID (ICCN)
プロキシのAuthen 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のためのAttribute Value分野には、以下の形式になっています。
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.
プロキシのAuthen ID AVPプロキシAUTHENタイプ2、3、5 2および5のためのために存在しなければならない、IDフィールドは、そのチャレンジにLACによってクライアントに提示されるバイトのID値を含みます。 3の場合は、認証リクエストの識別子の値です。
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)
プロキシのAuthen応答（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.
プロキシのAuthen応答AVP、属性タイプ33は、プロキシ認証が使用されるPPPピアからLACによって受信されたPPP認証応答を指定します。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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は、プロキシAUTHENタイプ1、2、3と5レスポンスフィールドはチャレンジに対するクライアントの応答が含まれているために存在しなければなりません。プロキシAUTHENタイプ2および5のために、このフィールドはLACによって受信された応答値を含んでいます。タイプ1または3の場合は、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 0. The Length (before hiding) of this AVP is 6 plus the length of the Response.
このAVPは、（Hビットは0または1であってもよい）に隠されてもよいです。このAVPのためのMビットは、このAVPの（隠れ前）0までの長さを設定しなければならない処置の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は、LNSにエラー情報を送信するためにLACによって使用されます。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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エラー - 不適切フレームPPPパケットの数は、ハードウェアオーバーランを受信 - - オーバーランコールは、バッファオーバーランを設立された以来、受信バッファの番号に電話がフレーミングエラーを確立したので、CRCエラーで受信された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でPPPピアと交渉ACCMのLACを知らせるためにLNSによって使用されます。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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ビットは、このAVPの長さは16である1に設定しなければなりません。
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セッションをトンネリングするために必要なセットアップは、（1）トンネルの制御接続を確立し、着信または発信要求を契機に（2）セッションを確立する、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は、制御接続確立中に簡単、オプション、CHAPのような[RFC1994]トンネル認証システムを組み込んでいます。 LACまたはLNSは、それが接触しているか、によって接触されたピアのアイデンティティを認証することを望む場合、チャレンジAVPはSCCRQ、またはSCCRPメッセージに含まれています。チャレンジAVPはSCCRQ、またはSCCRPで受信された場合、チャレンジレスポンスAVPは、それぞれ、以下SCCRP又はSCCCNに送らなければなりません。ピアから受信した期待される応答と応答が一致しない場合、トンネルの確立が許可されなければなりません。
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)
ICRQ -> <- ICRP ICCN -> <- ZLB ACK
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 ->
(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として送らなければなりません、そしてメッセージ内の割り当てられたセッションID AVPを使用しなければなりませんセッションを識別します。同様に、トンネル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.
シーケンス番号は、データメッセージ（セクション3.1を参照）のための制御メッセージと任意選択のためのL2TPヘッダに定義されています。これらは、信頼性の高い制御メッセージ・トランスポート（セクション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は、（4.4.6項を参照）、シーケンス番号がシーケンス不要AVPを介してデータメッセージに存在して要求することができます。この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によって決定される）IPデータグラムの損失に耐えられるよう、例えば、その後、LNSは、シーケンシングを無効にするかもしれませんそして、並べ替え。
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.
キープアライブ機構は、トンネルには、制御またはデータ活動の長時間からトンネル停止を区別するためにL2TPによって使用されます。最後のデータまたは制御メッセージは、トンネル上で受信されてからの時間の指定された期間が経過した後にこれは（セクション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)
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)
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から始まります。その値が最後に受信した番号の範囲内にあると32767に先行する場合、シーケンス番号は、このようにフリーランニングカウンタは、受信したメッセージのヘッダ内のシーケンス番号が最後に受信した数以下であると考えられるモジュロ65536で表され値は、包括的。最後に受信したシーケンス番号が15である場合、例えば、そのシーケンス番号0〜15、ならびに〜65535 32784のメッセージは、以下であると考えられます。そのようなメッセージが既に処理から受信し、無視メッセージの重複であると考えられます。しかし、すべてのメッセージが（特に失われた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がモジュロ65536、受信されたプラス1）ピアが次受信することを期待するメッセージのシーケンス番号を含みます。受信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にはAがSCCRQかSCCRPメッセージにNの値を持つ受信ウィンドウサイズのAVPを指定したと考えてみましょう。 Bは現在、N、優れた制御メッセージまで持つことが許されます。 Nが送信されたら、それは新しい制御メッセージを送信する前に、ウィンドウを進め、確認応答を待たなければなりません。実装は、（例えば前に4つのメッセージを送信する能力を持っている（すなわち、1の値を持つウィンドウを受信サイズAVPを送信することによって）のみ1の受信ウィンドウをサポートするかもしれないが、そのピアから最大4の窓を受け入れなければなりません）バックオフ。受信ウィンドウ・サイズAVPのための0の値が無効です。
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.
起動コントロール接続要求（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
トンネルIDを割り当てられたメッセージタイプAVPプロトコルバージョンホスト名フレーミング機能
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.
起動コントロール接続応答（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.
起動コントロール接続接続（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.
停止コントロール接続通知（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.
ハロー（ハロー）メッセージが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メッセージの送信や、それらを送信するためのポリシーが実装に任されています。ピアは、任意の時刻または間隔で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を越え実現することができませんし、トンネルをクリーンアップします。
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.
トンネルのキープアライブは、ある期間（推奨デフォルトは60秒であるが、設定されます）ピアからのすべてのメッセージ（データまたは制御）を受信することなく経過した場合、HELLOを送信することによって実現されてもよいです。
HELLO messages are global to the tunnel. The Session ID in a HELLO message MUST be 0.
helloメッセージは、トンネルにグローバルです。 HELLOメッセージのセッション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）着信が検出されたLNSにLACによって送られる制御メッセージです。これは、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.
着信リプライ（ICRP）受信ICRQメッセージに応答して、LACにLNSによって送られた制御メッセージです。これは、L2TPトンネル内のセッションを確立するために使用される3つのメッセージ交換における第二あります。
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のためのコールに応答します。また、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メッセージに応答してLNSにLACによって送られる制御メッセージです。これは、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
初期のReceived LCP CONFREQ最終LCP CONFREQ最終LCP CONFREQプロキシのAuthen型プロキシのAuthen名プロキシのAuthenチャレンジプロキシのAuthen IDプロキシのAuthenレスポンスプライベートグループID Rxの接続スピードシーケンス不要を送受信します
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.
出射コール要求（OCRQ）LACからの発信呼が確立されることを示すためにLACにLNSによって送られる制御メッセージです。これは、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との間に確立されるべきであることを示すために使用され、L2TPセッションの両方のためのパラメータ情報を有するLACを提供し、ある呼が配置されます
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.
出射コール応答（OCRP）受信OCRQメッセージに応答してLNSにLACによって送られる制御メッセージです。これは、L2TPトンネル内のセッションを確立するために使用される3つのメッセージ交換における第二あります。
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以下と発信コールが完了した後にLNSにLACによって送られたコントロールメッセージです。これは、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.
コール切断、通知（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誤り通知メッセージは、（PPPをサポートするインタフェースで発生条件）WANエラー条件を示すためにLNSにLACによって送られたL2TP制御メッセージです。このメッセージのカウンタは累積されます。このメッセージは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.
セットリンク-Infoメッセージは、PPPネゴシエーションのオプションを設定するには、LACにLNSによって送られたL2TPコントロールメッセージです。これらのオプションは、コールの生活中にいつでも変更することができ、これ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を参照）と実装に知られていない場合、または不適切な配列（例えば応答として送信されるSCCCNで受信された制御メッセージ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のための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.
制御メッセージ内の不正な形式のまだ回復可能な非必須（Mビットが設定されていない）AVPは認識されない非必須AVPと同様に扱われるべきです。奇形のAVPは、Mビットのセットで受信された場合したがって、セッションまたはトンネルが送信適切な結果やエラーコードで終了しなければなりません。 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を送信するためにはライセンスが考えられるが、してはならない、単に1が受信された場合、不適切にフォーマットされたメッセージを処理する方法に向けたガイド。与えられたメッセージのすべての潜在的な奇形を一覧表示し、それぞれについての助言を与えることは不可能です。 Rxの接続速度であるためのRx接続スピードAVP、属性38は、8よりもむしろ10及び2つのオクテットで与えられたBPSはなく4の長さで受信された場合には、前記回収、奇形のAVPの一例であるかもしれません非必須、この条件は壊滅的とみなされるべきではありません。このように、制御メッセージは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
SCCRQを受信アイドル、SCCRP待ち-CTL-CONN許容を送ります
idle Receive SCCRQ, Send StopCCN, idle not acceptable Clean up
StopCCNを送信し、SCCRQを受信アイドル、アイドル受け入れられないクリーンアップ
idle Receive SCCRP Send StopCCN idle Clean up
SCCRPはStopCCNのアイドルがクリーンアップ送信、受信アイドル
idle Receive SCCCN Clean up idle
アイドルをSCCCNクリーンアップ受信アイドル
wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable Send tunnel-open event to waiting sessions
SCCRPを受信-CTL-返事を待って、SCCCNを送信し、セッションを待っているに許容可能な送信トンネルのオープンイベントを設立
wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable Clean up
SCCRPを受信-CTL-返事を待って、StopCCNを送信し、アイドル状態ではない許容可能なクリーンアップ
wait-ctl-reply Receive SCCRQ, Clean up, idle lose tie-breaker Re-queue SCCRQ for idle state
SCCRQを受信-CTL-返事を待って、クリーンアップ、アイドル状態のためアイドル失うタイブレーカーの再キューSCCRQ
wait-ctl-reply Receive SCCCN Send StopCCN idle Clean up
待つ-CTL-返信をSCCCNがStopCCNのアイドルは、クリーンアップの送受信
wait-ctl-conn Receive SCCCN, Send tunnel-open established acceptable event to waiting sessions
待つ-CTLが-CONN SCCCNを受信、待機中のセッションにトンネルオープン確立許容可能なイベントを送信
wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable Clean up
待つ-CTL-connが、SCCCNを受信StopCCNを送信し、アイドル状態ではない許容可能なクリーンアップ
wait-ctl-conn Receive SCCRP, Send StopCCN, idle SCCRQ Clean up
待つ-CTLが-CONN SCCRPを受信、StopCCNを送信し、アイドルSCCRQクリーンアップ
established Local Send tunnel-open established Open request event to waiting (new call) sessions
確立ローカル送信トンネル-openが待っている（新しいコール）セッションにオープン要求イベントを設立します
established Admin Send StopCCN idle Tunnel Close Clean up
設立管理者は、クリーンアップ閉じるStopCCNアイドルトンネルを送ります
established Receive SCCRQ, Send StopCCN idle SCCRP, SCCCN Clean up
SCCRQを受信確立、StopCCNアイドルSCCRPを送信し、SCCCNクリーンアップ
idle Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established
確立し、待つ-CTL-CONNを、アップアイドル待機-CTL-返信StopCCNクリーンを受信アイドル
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.
-CTL-待つ返信別の接続が同じピアから要求されたかどうかを確認するために、発信チェックをし、もしそうであれば、第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.
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.
確立し、確立された接続は、ローカル状態またはStopコントロール接続通知の受領のいずれかによって終了することができます。ローカル終了の場合には、発信元は停止コントロール接続通知を送信し、トンネルをクリーンアップする必要があります。
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コールは非制限デジタルサービスまたはレート適応を使用する場合、デジタル示し、デジタルモデムが関与する場合アナログべきです。彼らは電話網から利用されている場合に電話番号、被呼番号、およびサブアドレスは、メッセージに含まれることができます。
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は、着信-Requestを送信すると、それは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は、着信-返信を受信すると、通話を接続しようとします。 LNSにLACから最終的なコール接続メッセージがLACとLNSの両方のためのコール状態が確立された状態に入るべきであることを示します。コールは、LNSはそれを受け入れることができる前に、コールを切断-通知終了した場合は、この状態を示すために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は、コールをクリアしたい場合は、コールを切断 - 通知メッセージを送信し、そのセッションをクリーンアップします。
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
ICCNを受信アイドル、アイドル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
待って返信をクリーンアップアイドル受け入れられない、CDNを送り、ICRPを受信
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を送り、アイドル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.
LACは、そのインターフェイスのいずれかに着信を検出するアイドル。典型的には、これはアナログラインが鳴っているか、ISDN TE着信Q.931 SETUPメッセージを検出したことを意味します。 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.
待ち応答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-外し、通知メッセージ+領収書を送信します。LACは、通話を切断、クリーンアップします。コールは、次のようにクリアすることができます地元の理由+：LACは、コールの切断は、通知メッセージを送信します。
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle not acceptable Clean up
CDNを送り、ICRQを受信アイドル、アイドル受け入れられないクリーンアップ
idle Receive ICRP Send CDN idle Clean up
ICRPは、CDNのアイドルがクリーンアップ送信、受信アイドル
idle Receive ICCN Clean up idle
ICCNクリーンアップ受信アイドルアイドル
wait-connect Receive ICCN Prepare for established acceptable data
ICCNが確立許容できるデータの準備を受信待機し、接続
wait-connect Receive ICCN Send CDN, idle not acceptable Clean up
クリーンアップアイドル受け入れられない、ICCNはCDNを送信、受信待機し、接続
wait-connect Receive ICRQ, Send CDN idle ICRP Clean up
待つ-接続ICRQを受信、CDNのアイドルICRPのクリーンアップ送ります
idle, Receive CDN Clean up idle wait-connect, established
アイドル、CDNのクリーンアップ受信アイドル待機-接続、確立
wait-connect Local 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.
着信-Requestメッセージを受信したアイドル。要求が受け入れられない場合は、アイドル状態のままバックLACとLNSに送られるコールを切断-通知。着信-Requestメッセージが許容される場合は、着信-返信が送信されます。セッションが待機接続状態に移行します。
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は、コールの切断は、通知の着信、発信者が接続することができなかったことを示すために送ることができます。電話ユーザが誤って呼ばれるモデムのハンドシェイク障害の原因となる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.
セッションはどちらかLACからか、コールを切断-通知送信することで、メッセージをコール外し-通知の受信によって終了される確立。クリーンアップに関係なく、開始剤の両側に従います。
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を指示しています。発信・コール要求、発信-CALL-返信、および、コール接続の発信：発信通話のための3件のメッセージがあります。 LNSは、ダイヤルした相手の電話番号、サブアドレスおよびその他のパラメータを指定して発信-CALL-Requestを送信します。 LACは、LAC一度発信コール-ReplyメッセージでOutgoing-Call-Requestメッセージに応答しなければならない適切な施設が電話をかけるために存在し、通話が管理上許可されていることを決定します。たとえば、この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
CDNを送り、OCRQを受信アイドル、アイドル受け入れられないクリーンアップ
idle Receive OCRP Send CDN idle Clean up
OCRPは、CDNのアイドルがクリーンアップ送信、受信アイドル
idle Receive OCCN, Clean up idle CDN
、OCCNを受信アイドルアイドルCDNをクリーンアップ
wait-cs-answer Bearer answer, Send OCCN established framing detected
答えベアラ-CS-答えを待って、OCCNは、フレーミングが検出された設立送ります
wait-cs-answer Bearer failure Send CDN, idle Clean up
障害送信CDNベアラ-CS-答えを待って、アイドルクリーンアップ
wait-cs-answer Receive OCRQ, Send CDN idle OCRP, OCCN Clean up
OCRQを受信-CS-答えが待って、CDNのアイドルOCRP、OCCNクリーンアップ送ります
established Receive OCRQ, Send CDN idle OCRP, OCCN Clean up
OCRQを受信確立し、CDNアイドルOCRPを送信し、OCCNクリーンアップ
wait-cs-answer, Receive CDN Clean up idle established
待つ-CS-答え、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.
発信コールリクエストはエラーで受信された場合、コールの切断は、通知で応答アイドル。それ以外の場合は、物理チャネルを割り当て、発信コール-返信を送ります。アウトバウンドコールを発信し、待ち時間-CS-回答ステートに移行します。
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.
呼び出しが完了またはタイマーが満了していない場合は呼び出しが完了するのを待って-CS-答えを待って、適切なエラー条件を設定してコールを切断-通知およびアイドル状態に行く送ります。回路が接続を切り替える場合は確立され、フレーミングが検出され、発信コール接続成功を示すを送信し、確立状態になります。
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.
コールを切断-通知がLACによって受信された場合に確立、電話会社の通話が適切なメカニズムとクリーンアップセッションを介して解放する必要があります。コールは、クライアントまたはと呼ばれるインターフェースによって切断された場合、コールを切断-通知メッセージは、LNSに送らなければなりません。コールを外し、通知メッセージの送信者は、メッセージの送信が完了した後にアイドル状態に戻ります。
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
idle Receive OCCN, Clean up idle OCRP, CDN
OCCNを受信アイドル、アイドル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
待って返信をOCCNを受信、CDNのアイドルOCRQクリーンアップを送ります
wait-connect Receive OCCN none established
待つ-接続OCCNのどれも確立していない受信
wait-connect Receive OCRQ, Send CDN idle OCRP Clean up
待つ-接続CDNのアイドルOCRPクリーンアップを送信し、OCRQを受信
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
待って返信、ローカル送信CDNアイドル待機-接続、クローズ要求が確立クリーンアップ
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着信コールのために。トンネルが確立されると、発信コール-Requestメッセージは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.
待って返信をコール外し-通知した場合は受信され、エラーが発生し、セッションをクリーンアップし、アイドル状態に戻ります。発信コール、応答が受信された場合、呼び出しが進行し、待機接続状態へのセッション移動です。
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.
コールを切断-通知した場合に確立受信され、呼び出しが結果に示されている理由で終了とコードが原因となっていました。セッションがアイドル状態に戻ります。 LNSがセッションを終了することを選択した場合、それは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は、L2TPパケットが移動する可能性があり、その上、パスのMTUのは、一貫性の価値を持っているLAC環境用に最適化することができ、特定のMRU、のために交渉することがあります。
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は静かにすべてのL2Fパケットを捨てなければなりませんサポートしていないシステム上で実行されているL2TPの実装。
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によって運ばれている非IPプロトコルは、そのような橋渡しとして特にLAN中心のものを壊すことがあります。後者は、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エラーのあるパケットを送信することによって達成することができます。クライアント統計が真のメディアエラーとLAC-開始のものを区別できなかったので、これは非常に、クライアント回線の問題をデバッグの複雑さを増すことに注意してください。さらに、この技術は、すべてのハードウェアでは不可能です。
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信頼性の高い配信もシーケンス番号が有効になっている場合は、TCPセグメントの1 16 ** 2のチャンスの各失われたパケットの結果が正しくない内容[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は、単一の秘密を共有しなければなりません。被認証者だけでなく、オーセンティケータとして動作するときに、各側は、この同じ秘密を使用しています。単一の秘密を使用しているため、トンネル認証の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.
LNSにLACから輸送しながら、安全な輸送を経てL2TPパケットストリームを保護することは、今度は、また、トンネル化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トランスポート・セキュリティに加えて、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実装に必要とされているアクセス制御機能を定義します。これらの特徴は類似のフィルタリングが論理L2TP上記PPP層やネットワーク層で実行される、L2TPトンネリングモデルにおいて等IPアドレス、ポートなどのネットワークとトランスポート層の特性に基づいてパケットのフィルタリングを可能にします。これらのネットワーク層アクセス制御機能は、ネットワーク層自体でのIPsecトランスポート・モードのエンドツーエンド通信ホスト間を使用して認証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は、検証のためにLNSにLACで得られたPPP認証情報の転送を提供するために、セッション確立中に交換することができるAVPを定義する（セクション4.4.5を参照）。これは、LNSに代わってLACの直接的な信頼関係を意味します。 LNSは、プロキシ認証を実装することを選択した場合、新たなラウンド（またはLCPネゴシエーションの新しいラウンドを含んでも含まなくてもよい）LNSによって開始PPP認証を必要とする、オフに構成することができなければなりません。
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は、割り当てられた属性と、いくつかのケースでも、値のレジストリを維持します。セクション4.4で定義されている属性0-39が割り当てられます。残りの値は、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メッセージについては、セクション4.4.2で定義されている0-7値。 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]を通して課題に利用可能です。エラーコードフィールドの残りの値は、まず[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].
（4.4.3項で定義される）フレーミング機能のAVPとベアラ能力のAVPの両方は、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].
プロキシのAuthenタイプAVP（属性タイプ29）はIANAによって維持される関連値を有します。 0-5は、[RFC 2434]添えまず最初に来るを介して残りの値は、割り当てのために利用可能である、セクション4.4.5で定義された値。
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勧告、 "デジタル加入者シグナリングシステム1号（DSS 1） - 基本的な呼制御のためのISDNユーザネットワークインタフェースレイヤ3仕様"、撮影。 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]カウフマン、C.、パールマン、R.、およびSpeciner、M.、 "ネットワークセキュリティ：公共世界のプライベート・コミュニケーションズ"、プレンティス・ホール、1995年3月、ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、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]ジェーコブソン、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.
"HDLC様のフレーミングにおけるPPP" [RFC1662]シンプソン、W.、STD 51、RFC 1662、1994年7月。
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1663]ランド、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]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月を見る：http://www.iana.org/numbers.html [RFC1990] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.とT. Coradetti、 "PPPマルチリンクプロトコル（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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ルーベンス、A.、シンプソン、W.及びS. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[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]バレンシア、A.、リトルウッド、M.とT.コーラール、 "シスコレイヤ二フォワーディング（プロトコル）L2F"、RFC 2341、1998年5月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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.、ポール、G.、Verthein、W.、Taarud、J.、リトル、W.およびG.ゾルン、 "ポイントツーポイントトンネリングプロトコル（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
[STEVENS]スティーブンス、W.リチャード、 "TCP / IPイラスト、ボリュームIプロトコル"、アディソン・ウェズリー出版社、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. Hamzeh、G.ポール、W. Verthein、J. Taarud、W.リトル、およびG.ゾルンあります。
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of this document.
ドーリーLeiferは、L2TPのプロトコル定義に貴重な改良を行い、このドキュメントの編集に貢献しました。
Steve Cobb and Evan Caves redesigned the state machine tables.
スティーブ・コブとエヴァン洞窟は、ステートマシンテーブルを再設計しました。
Barney Wolff provided a great deal of design input on the endpoint authentication mechanism.
バーニーヴォルフは、エンドポイントの認証メカニズムに設計入力の多くを提供します。
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.
ジョン・ブレイ、グレッグ・バーンズ、リッチ・ギャレット、ドン・グローサー、マット・ホールドレッジ、テリー・ジョンソン、ドーリーLeifer、およびリッチシアバターは、オーランド、フロリダ州で第43回IETFでの貴重な入力とレビューを提供する。、全体の読みやすさと明確性の改善につながりましたこのドキュメント。
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
ガーディープ・シンポール、米国Microsoft Corporationレドモンド、WA
EMail: gurdeep@microsoft.com
メールアドレス：gurdeep@microsoft.com
Bill Palter RedBack Networks, Inc 1389 Moffett Park Drive Sunnyvale, CA 94089
ビルPalterレッドバックネットワークス株式会社1389年モフェットパークドライブサニーベール、CA 94089
EMail: palter@zev.net
メールアドレス：palter@zev.net
Allan Rubens Ascend Communications 1701 Harbor Bay Parkway Alameda, CA 94502
アランルーベンスアセンドコミュニケーションズ1701ハーバー・ベイ・パークウェイアラメダ、CA 94502
EMail: acr@del.com
メールアドレス：acr@del.com
W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークTownsleyシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709
EMail: townsley@cisco.com
メールアドレス：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
メールアドレス：vandys@cisco.com
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052
グレンツォルンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: gwz@acm.org
メールアドレス：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.リチャードスティーヴンス[STEVENS]で、TCP / IPイラスト、ボリューム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又はピギーバック）が受信されるたびに増加されます。各ACKに1によるCWNDを大きくすると、指数関数的に増加し、その結果、各ラウンドトリップでCWNDを倍にする効果があります。 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新しいACKが受信された後ということです、CWNDは1つのパケット増加しています。輻輳回避フェーズの間ウィンドウの拡張は、CWNDが一つのパケットにより各ラウンドトリップの増加に伴って、効果的に線形です。
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
SCCRQ - >いいえ：0、Nsとしない：0 < - SCCRP NO：1、Ns個：0 SCCCN - > NO：1、Ns個：1 < - ZLB NO：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つの影響があります。それが進行する上位レベルのステートマシンを維持するが、それはまた、そのICRQのタイムリーな低レベルの確認応答を見てからLACを保つだけではありません。
LAC LNS
--- ---
ICRQ -> Nr: 1, Ns: 2
ICRQ - > NO：1、Ns個：2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LAC's timer started first, so fires first)
（一時停止し、LACのタイマーが最初に起動するので、火災最初）
ICRQ -> Nr: 1, Ns: 2
ICRQ - > NO：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
< - ICRP NO：3、Ns個：1 ICCN - > NO：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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。