RFC2661 日本語訳
2661 Layer Two Tunneling Protocol "L2TP". W. Townsley, A. Valencia, A.Rubens, G. Pall, G. Zorn, B. Palter. August 1999. (Format: TXT=168150 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Townsleyがコメントのために要求するワーキンググループW.をネットワークでつないでください: 2661年のA.バレンシアカテゴリ: 規格TrackコクチマスSystems A.ルーベンスAscend Communications G.Pall G.ゾルンマイクロソフト社B.Palter Redback Networks1999年8月
Layer Two Tunneling Protocol "L2TP"
層Twoのトンネリングプロトコル"L2TP"
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
このドキュメントはLayer Two Tunnelingプロトコル(L2TP)について説明します。 STD51、RFC1661は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
1.0序論… 3 1.1 要件の仕様… 4 1.2用語… 4 2.0トポロジー… 8 3.0 概要について議定書の中で述べてください… 9 3.1 L2TPヘッダー形式… 9 3.2 メッセージタイプを監督してください… 11 4.0 メッセージ属性値ペアを制御してください… 12 4.1 AVP形式… 13 4.2 義務的なAVPs… 14 4.3 AVP属性値の隠れること… 14
Townsley, et al. Standards Track [Page 1] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[1ページ]。
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
4.4AVP概要… 17 4.4 すべてに適切な.1AVPsがメッセージを制御します… 17 4.4 .2 結果と誤りコード… 18 4.4 .3 接続管理AVPsを制御してください… 20 4.4 .4 管理をAVPsと呼んでください… 27 4.4 .5 プロキシLCPと認証AVPs… 34 4.4 .6 AVPsに状態に電話をしてください… 39 5.0 操作について議定書の中で述べてください… 41 5.1 コネクション確立を制御してください… 41 5.1 .1 認証にトンネルを堀ってください… 42 5.2 セッション設立… 42 5.2 .1 かかってきた電話設立… 42 5.2 .2 発信電話設立… 43 5.3 推進pppフレーム… 43 データの一連番号を使用する5.4が向けられます… 44 5.5Keepalive(こんにちは)… 44 5.6セッション分解… 45 5.7 接続分解を制御してください… 45 5.8 コントロールメッセージの信頼できる配信… 46 6.0 接続プロトコル仕様を制御してください… 48 6.1 スタートコントロール接続要求(SCCRQ)… 48 6.2 スタートコントロール接続回答(SCCRP)… 48 6.3 スタートコントロール接続は接続しました(SCCCN)… 49 6.4 停止コントロール接続通知(StopCCN)… 49、6.5、こんにちは、(こんにちは)… 49 6.6 入って来る発呼要求(ICRQ)… 50 6.7 入って来る呼び出し回答(ICRP)… 51 6.8 入って来る接続完了(ICCN)… 51 6.9 送信する発呼要求(OCRQ)… 52 6.10 外向的な呼び出し回答(OCRP)… 53 6.11 外向的な接続完了(OCCN)… 53 6.12 呼び出し分離に通知します(CDN)… 53 6.13 青白い誤りに通知します(こぶ)… 54 6.14 セットリンクインフォメーション(SLI)… 54 7.0 接続州のマシンを制御してください… 54 7.1 接続プロトコル操作を制御してください… 55 7.2 接続州を制御してください… 56 7.2 .1 コネクション確立を制御してください… 56 7.3 タイミング問題… 58 7.4 入来は呼びます… 58 7.4 .1 ラックかかってきた電話州… 60 7.4 .2のLNSかかってきた電話州… 62 7.5 外向的な呼び出し… 63 7.5 .1 ラック発信電話州… 64 7.5 .2のLNS発信電話州… 66 7.6 断線にトンネルを堀ってください… 67 特定のメディアの上の8.0L2TP… 67 UDP/IPの上の8.1L2TP… 68
Townsley, et al. Standards Track [Page 2] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[2ページ]。
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
8.2IP… 69 9.0 セキュリティ問題… 69 9.1 終点セキュリティにトンネルを堀ってください… 70 9.2 パケット・レベルセキュリティ… 70 9.3 終わって、セキュリティを終わらせてください… 70 9.4のL2TPとIPsec… 71 9.5 プロキシppp認証… 71 10.0 IANA問題… 71 10.1 AVP属性… 71 10.2 メッセージタイプAVP値… 72 10.3 結果コードAVP値… 72 10.3.1 結果コード分野値… 72 10.3.2 エラーコード分野値… 72 10.4 縁どり能力と運搬人能力… 72 10.5 プロキシAuthenはAVP値をタイプします… 72 10.6 AVPヘッダービット… 73 11.0の参照箇所… 73 12.0の承認… 74 13.0人の作者のアドレス… 75 付録A: チャンネル遅れた出発と輻輳回避を制御してください… 76 付録B: メッセージの例を制御してください… 77 付録C: 知的所有権通知… 79 完全な著作権宣言文… 80
1.0 Introduction
1.0 序論
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など)の1つを使用することでNetwork Access Server(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.
L2とPPP終点がパケット交換網でインタコネクトされた異なったデバイスで住んでいるのを許容することによって、L2TPはPPPモデルを広げています。 L2TPがあるので、アクセス集中装置(例えば、モデム銀行、ADSL DSLAMなど)にはユーザはL2接続がいます、そして、次に、集中装置は個々のPPPフレームにNASにトンネルを堀ります。 これは、PPPパケットの実際の処理がL2回路の終了と離婚するのを許容します。
One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require a long-distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over
そのような分離の恩恵が必要さの代わりにL2接続がNAS(長距離の料金を必要とするかもしれない)で終わるということであることが明白な1つ、接続は次に論理的なPPPセッションに及ぶ(地方)の回路集中装置で終わるかもしれません。
Townsley, et al. Standards Track [Page 3] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[3ページ]。
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.
フレームリレーサーキットかインターネットなどの共有されたインフラストラクチャ。 ユーザの見解から、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]は、マルチリンクバンドルを構成するオール・チャンネルが独身のNetwork Access Server(NAS)で分類されるのを必要とします。 それが物理的に受け取られたポイント以外の位置にPPPセッションを映し出す性能のため、オール・チャンネルに独身のNASで終わらせるのにL2TPを使用できます。 呼び出しが異なった物理的なNASsの向こう側に広げられるときさえ、これはマルチリンク操作を許します。
This document defines the necessary control protocol for on-demand creation of tunnels between two nodes and the accompanying encapsulation for multiplexing multiple, tunneled PPP sessions.
このドキュメントは2つのノードの間のトンネルの要求次第の作成のための必要な制御プロトコルと複数の、そして、トンネルを堀られたPPPセッションを多重送信するための付随のカプセル化を定義します。
1.1 Specification of Requirements
1.1 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2 Terminology
1.2 用語
Analog Channel
アナログ・チャンネル
A circuit-switched communication path which is intended to carry
3.1 kHz audio in each direction.
3.1kHzのオーディオを各方向に運ぶことを意図する回路で切り換えられた通信路。
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.
ユニークなAttribute(整数で、表される)と属性によって特定された実価を含むValueの可変長連結。 複数のAVPsがトンネルの設立、メインテナンス、および分解に使用されるControl Messagesを作ります。
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).
Remote SystemとLACとの接続(または、試みられた接続)。 例えば、PSTNを通した通話。 Remote SystemとLACの間に首尾よく設立されるCall(入来かOutgoing)はLACとLNSの間の以前に確立したTunnelの中で対応するL2TP Sessionをもたらします。 (参照: セッション、Incoming Call、Outgoing Call。)
Townsley, et al. Standards Track [Page 4] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[4ページ]。
Called Number
数と呼ばれます。
An indication to the receiver of a call as to what telephone
number the caller used to reach it.
それに達するという訪問者がどんな電話番号を使用したかに関する要求の受信機への指示。
Calling Number
数と呼びます。
An indication to the receiver of a call as to the telephone number
of the caller.
訪問者の電話番号に関する呼び出しの受信機への指示。
CHAP
やつ
Challenge Handshake Authentication Protocol [RFC1994], a PPP
cryptographic challenge/response authentication protocol in which
the cleartext password is not passed over the line.
Handshake Authenticationプロトコル[RFC1994](cleartextパスワードが系列の上に通過されないPPPの暗号の挑戦/応答認証プロトコル)に挑戦してください。
Control Connection
コントロール接続
A control connection operates in-band over a tunnel to control the
establishment, release, and maintenance of sessions and of the
tunnel itself.
コントロール接続はセッションとトンネルの設立、リリース、およびメインテナンス自体を制御するトンネルの上でバンドで働いています。
Control Messages
コントロールメッセージ
Control messages are exchanged between LAC and LNS pairs,
operating in-band within the tunnel protocol. Control messages
govern aspects of the tunnel and sessions within the tunnel.
トンネルの中のバンドのプロトコルを操作して、LACとLNS組の間でコントロールメッセージを交換します。 コントロールメッセージはトンネルの中のトンネルとセッションの局面を決定します。
Digital Channel
デジタル・チャンネル
A circuit-switched communication path which is intended to carry
digital information in each direction.
各方向によるデジタル情報を運ぶことを意図する回路で切り換えられた通信路。
DSLAM
DSLAM
Digital Subscriber Line (DSL) Access Module. A network device used
in the deployment of DSL service. This is typically a concentrator
of individual DSL lines located in a central office (CO) or local
exchange.
デジタル加入者線(DSL)はモジュールにアクセスします。 DSLサービスの展開に使用されるネットワークデバイス。 通常、これは電話局(CO)か市内交換で位置する個々のDSL系列の集中装置です。
Incoming Call
かかってきた電話
A Call received at an LAC to be tunneled to an LNS (see Call,
Outgoing Call).
Callは、LNSにトンネルを堀られるためにLACで受信しました(Call、Outgoing Callを見てください)。
Townsley, et al. Standards Track [Page 5] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[5ページ]。
L2TP Access Concentrator (LAC)
L2TPアクセス集中装置(ラック)
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 Network Server(LNS)への同輩であるノード。 LACはLNSとリモートシステムの間に座っていて、それぞれとそれぞれからパケットを進めます。 LACからLNSに送られたパケットは、本書では定義されるようにL2TPプロトコルでトンネルを堀るのを必要とします。 LACからリモートシステムまでの接続が地元です(: クライアントのためにLACを見てください)、またはPPPはリンクします。
L2TP Network Server (LNS)
L2TPネットワークサーバ(LNS)
A node that acts as one side of an L2TP tunnel endpoint and is a
peer to the L2TP Access Concentrator (LAC). The LNS is the
logical termination point of a PPP session that is being tunneled
from the remote system by the LAC.
L2TPトンネル終点の半面として機能して、L2TP Access Concentrator(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のManagement Domainはそれが役立つ企業ネットワークであるかもしれません。 LACのManagement Domainはそれを所有して、管理するインターネットサービスプロバイダであるかもしれません。
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).
CallはLACでLNSを代表して入賞しました(Call、Incoming Callを見てください)。
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のPeerは逆もまた同様にLNSです。 状況内においてPPPと共に使用されると、同輩はPPP接続のどちらかの側面です。
POTS
ポット
Plain Old Telephone Service.
明瞭な古い電話サービス。
Townsley, et al. Standards Track [Page 6] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[6ページ]。
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によって開始されるか、または答えられる各Callのために状態を維持します。 終わりから終わりとのPPP接続がRemote SystemとLNSの間で確立されるとき、L2TP SessionはLACとLNSの間で作成されます。 LACとLNSの間のTunnelの上にPPP接続に関連するデータグラムを送ります。 確立したL2TPセッションズとそれらの関連Callsとの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.
TunnelはLAC-LNS組の間に存在しています。 TunnelはControl Connectionとゼロか、より多くのL2TPセッションズから成ります。 Tunnelはカプセル化されたPPPデータグラムとControl MessagesをLACとLNSの間まで運びます。
Zero-Length Body (ZLB) Message
ゼロ・レングス本体(ZLB)メッセージ
A control packet with only an L2TP header. ZLB messages are used
for explicitly acknowledging packets on the reliable control
channel.
L2TPヘッダーだけがあるコントロールパケット。 ZLBメッセージは、高信頼の制御チャンネルの上に明らかにパケットを承認するのに使用されます。
Townsley, et al. Standards Track [Page 7] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[7ページ]。
2.0 Topology
2.0 トポロジー
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シナリオについて表現します。 ホームLANで位置するRemote SystemかLAC ClientとLNSの間には、トンネルPPPフレームには目標があります。
[Home LAN]
[LAC Client]----------+ |
____|_____ +--[Host]
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| PSTN |
[Remote]--| Cloud |
[System] | | [Home LAN]
|___________| |
| ______________ +---[Host]
| | | |
[LAC]-------| Frame Relay |---[LNS]-----+
| or ATM Cloud | |
|______________| :
[ホームLAN] [ラッククライアント]----------+ | ____|_____ +--[ホスト]| | | [ラック]---------| インターネット|-----[LNS]-----+ | |__________| | _____|_____ : | | | PSTN| [リモート]--| 雲| [システム]| | [ホームLAN]|___________| | | ______________ +---[ホスト]| | | | [ラック]-------| フレームリレー|---[LNS]-----+ | または、気圧雲| | |______________| :
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
Remote SystemはPSTN Cloudの向こう側にPPP接続をLACに開始します。 そしてLACはインターネット、Frame Relay、またはATM Cloudの向こう側にホームLANへのアクセスが得られるLNSにPPP接続にトンネルを堀ります。 アドレスをホームLANからRemote Systemに提供します。
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交渉で。 まるでユーザが直接Network Access Serverに接続されるかのように認証、Authorization、およびAccountingはホームLANのManagement Domainによって提供されるかもしれません。
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 Client(L2TP nativelyを実行するHost)は別々のLACの使用なしでホームLANにトンネリングに参加するかもしれません。 この場合、公共のインターネットにはLAC Clientソフトウェアを含むHostが既に接続がいます。 次に、「仮想」のPPP接続は創造されます、そして、ローカルのL2TP LAC ClientソフトウェアはトンネルをLNSに作成します。 上のケースのように、Addressing、Authentication、Authorization、およびAccountingはホームLANのManagement Domainによって提供されるでしょう。
Townsley, et al. Standards Track [Page 8] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[8ページ]。
3.0 Protocol Overview
3.0 プロトコル概要
L2TP utilizes two types of messages, control messages and data messages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used to encapsulate PPP frames being carried over the tunnel. Control messages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are not retransmitted when packet loss occurs.
L2TPは2つのタイプに関するメッセージ、コントロールメッセージ、およびデータメッセージを利用します。 コントロールメッセージはトンネルと呼び出しの設立、メインテナンス、および開拓地に使用されます。 データメッセージは、トンネルの上まで運ばれるフレームをPPPにカプセル化するのに使用されます。 コントロールメッセージは、荷渡しを保証するのにL2TPの中で信頼できるControl Channelを利用します(詳細に関してセクション5.1を見てください)。 パケット損失が起こるとき、データメッセージは再送されません。
+-------------------+ | PPP Frames | +-------------------+ +-----------------------+ | L2TP Data Messages| | L2TP Control Messages | +-------------------+ +-----------------------+ | L2TP Data Channel | | L2TP Control Channel | | (unreliable) | | (reliable) | +------------------------------------------------+ | Packet Transport (UDP, FR, ATM, etc.) | +------------------------------------------------+
+-------------------+ | pppフレーム| +-------------------+ +-----------------------+ | L2TPデータメッセージ| | L2TPコントロールメッセージ| +-------------------+ +-----------------------+ | L2TPデータ・チャンネル| | L2TP制御チャンネル| | (頼り無い)です。 | | (信頼できる)です。 | +------------------------------------------------+ | パケットTransport(UDP、FR、ATMなど) | +------------------------------------------------+
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 ControlとData Channelsの上にPPPフレームとControl Messagesの関係について表現します。 PPP Framesは最初に、L2TPヘッダーによってカプセル化された頼り無いData Channelが通り過ぎられていて、次に、UDP、Frame Relay、ATMなどのPacket Transportを通り過ぎられています。 同じPacket Transportの上のバンドのパケットを伝える信頼できるL2TP Control Channelの上にコントロールメッセージを送ります。
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.
一連番号は、すべてのコントロールメッセージに存在しているのが必要であり、Control Channelで信頼できる配信を提供するのに使用されます。 データMessagesは追加注文パケットに一連番号を使用して、無くなっているパケットを検出するかもしれません。
All values are placed into their respective fields and sent in network order (high order octets first).
すべての値をそれらのそれぞれの分野に置いて、ネットワークオーダーで送ります(高値は最初に、八重奏を命令します)。
3.1 L2TP Header Format
3.1 L2TPヘッダー形式
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パケットは一般的なヘッダー形式を共有します。 分野が任意である各場合では、分野が存在していないのが示されるなら、スペースはメッセージに存在していません。 Length(分野が任意であるとして以下にマークしたNs、およびNr)がデータメッセージで任意である間すべてのコントロールメッセージに存在しているのが必要であることに注意してください。
Townsley, et al. Standards Track [Page 9] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[9ページ]。
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ(選びます)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トンネルID| セッションID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ナノ秒(選びます)| Nr(選びます)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サイズを相殺してください(選んでください)。| パッドを相殺してください… (選びます) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Type(T)ビットはメッセージのタイプを示します。 それはデータメッセージのための0とコントロールメッセージのための1へのセットです。
If the Length (L) bit is 1, the Length field is present. This bit MUST be set to 1 for control messages.
Length(L)ビットが1であるなら、Length分野は存在しています。 コントロールメッセージのためにこのビットを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.
Sequence(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.
Offset(O)ビットが1であるなら、Offset Size分野は存在しています。 コントロールメッセージのために0(ゼロ)にOビットを設定しなければなりません。
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.
Priority(P)ビットが1であるなら、このデータメッセージはその地方の列を作りとトランスミッションにおける優遇を受けるべきです。 このビットで一般に例えば、リンクへのkeepaliveを送るべきであるので使用されるLCPエコー要求は1にセットしました。 それがなければ、地方の混雑の一時的な間隔はリンクのkeepaliveメッセージと不要な損失の干渉をもたらすかもしれません。 データメッセージと共にこの特徴は使用のためだけのものです。 すべてのコントロールメッセージのために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データメッセージヘッダーのバージョンを示して、Verは2歳であるに違いありません。 L2TPパケットと共に混ぜた状態で到着するなら、値1は、L2F[RFC2341]パケットの検出を可能にするために予約されます。 未知のVer分野で受け取られたパケットを捨てなければなりません。
The Length field indicates the total length of the message in octets.
Length分野は八重奏における、メッセージの全長を示します。
Townsley, et al. Standards Track [Page 10] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[10ページ]。
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トンネルはローカルの意味しか持っていない識別子によって命名されます。 トンネルの各端までに異なったTunnel IDをすなわち、同じトンネルに与えるでしょう。 各メッセージのトンネルIDは送付者ではなく、意図している受取人のものです。 トンネルの作成の間、Assigned Tunnel ID AVPsとしてトンネルIDを選択して、交換します。
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セッションはローカルの意味しか持っていない識別子によって命名されます。 セッションの各端までに異なったSession IDをすなわち、同じセッションに与えるでしょう。 各メッセージのセッションIDは送付者ではなく、意図している受取人のものです。 セッションの作成の間、Assigned Session ID AVPsとしてセッションIDを選択して、交換します。
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.
ゼロで始まって、ナノ秒はこのデータかコントロールメッセージのために一連番号を示します、そして、各メッセージあたりの(法2**16)を1つ増加するのは発信しました。 この分野を使用する詳しい情報に関してセクション5.8と5.4を見てください。
Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-order message received plus one (modulo 2**16). In data messages, Nr is reserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See section 5.8 for more information on using this field in control messages.
Nrは次の受け取られるべきコントロールメッセージで予想された一連番号を示します。 したがって、Nrはオーダーにおける受け取られた最後のメッセージと1(法2**16)のNsに用意ができています。 データメッセージでは、Nrを予約されていて、存在しているなら(S-ビットによって示されるように)、領収書で無視しなければなりません。 コントロールメッセージでこの分野を使用する詳しい情報に関してセクション5.8を見てください。
The Offset Size field, if present, specifies the number of octets past the L2TP header at which the payload data is expected to start. Actual data within the offset padding is undefined. If the offset field is present, the L2TP header ends after the last octet of the offset padding.
存在しているなら、Offset Size分野はペイロードデータが出発すると予想されるL2TPヘッダーの先で八重奏の数を指定します。 オフセット詰め物の中の実際のデータは未定義です。 オフセット分野が存在しているなら、L2TPヘッダーはオフセット詰め物の最後の八重奏の後に終わります。
3.2 Control Message Types
3.2 コントロールメッセージタイプ
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.
Message Type AVP(セクション4.4.1を見る)は送られるコントロールメッセージの特定のタイプを定義します。 セクション3.1からこれがコントロールメッセージのためだけのものであると思い出してください、そして、すなわち、T-ビットがあるメッセージは1にセットします。
Townsley, et al. Standards Track [Page 11] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[11ページ]。
This document defines the following control message types (see Section 6.1 through 6.14 for details on the construction and use of each message):
このドキュメントは以下のコントロールメッセージタイプを定義します(各メッセージの工事と使用に関する詳細に関してセクション6.1〜6.14を見てください):
Control Connection Management
コントロール接続管理
0 (reserved)
0 (予約される)です。
1 (SCCRQ) Start-Control-Connection-Request
2 (SCCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification
5 (reserved)
6 (HELLO) Hello
1(SCCRQ)コントロール接続要求を始めている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)入って来る接続完了13(予約される)14(CDN)呼び出し
Error Reporting
誤り報告
15 (WEN) WAN-Error-Notify
誤りが通知する15(こぶ)WAN
PPP Session Control
pppセッション制御
16 (SLI) Set-Link-Info
16 (SLI)セットリンクインフォメーション
4.0 Control Message Attribute Value Pairs
4.0 コントロールメッセージ属性値ペア
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(属性価値のPair)と呼ばれるでしょう。
Townsley, et al. Standards Track [Page 12] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[12ページ]。
4.1 AVP Format
4.1 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]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| ベンダーID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| 値を結果と考えてください… +++++++++++++++++++++++++++++++++[Lengthに達するまで]… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits are a bit mask, describing the general attributes of the AVP.
AVPの一般属性について説明して、最初の6ビットはしばらくマスクです。
Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
2ビットはこれで定義されて、ドキュメント、残りが今後の拡大のために予約されるということです。 予約されたビットを0に設定しなければなりません。 1に設定された予約されたビットで受け取られたAVPを認識されていないAVPとして扱わなければなりません。
Mandatory (M) bit: Controls the behavior required of an implementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associated with a particular session, the session associated with this message MUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must then continue to be processed as if the AVP had not been present.
義務的な(M)ビット: 振舞いが必要としたそれが認識しないAVPを受ける実装のコントロール。 Mが噛み付いたなら、特定のセッション、このメッセージに関連しているセッションに関連しているメッセージの中の認識されていないAVPのセットは終えなければなりませんか? Mに噛み付いたならセットが総合的なトンネル、全体のトンネルに関連しているメッセージの中の認識されていないAVPにある、(すべてのセッション、中)、終えなければならなくなってください。 Mビットはセット、認識されていないAVP MUSTではありません。無視されます。 そして、コントロールメッセージは、まるで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のAttribute Value分野でデータの隠れることを特定します。 極秘データの通過を避けるのにこの能力を使用できます、ユーザパスワードなどのように、AVPのcleartextとして。 セクション4.3はAVP隠れることを実行するための手順について説明します。
Length: Encodes the number of octets (including the Overall Length and bitmask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. The minimum Length of an AVP is 6. If the length is 6, then the Attribute Value field is absent.
長さ: 八重奏(Overall Lengthとビットマスク分野を含んでいる)の数がこのAVPに含んだエンコード。 Lengthは+ Attribute Valueの長さが八重奏でさばく6として計算されるかもしれません。 独身のAVPのデータの最大1023の八重奏を可能にして、分野自体は10ビットです。 AVPの最小のLengthは6歳です。 長さが6であるなら、Attribute Value分野は欠けています。
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
ベンダーID: IANAは「SMIネットワークマネージメント私企業コード」[RFC1700]に値を割り当てました。 値0であり、IETFに対応するのは、属性値を採用して、このドキュメントの中に定義されたすべてのAVPsに使用されます。 それら自身のL2TP拡張子を実装したがっているどんなベンダーも個人的なAttributeに伴うそれら自身のVendor IDを使用できます。
Townsley, et al. Standards Track [Page 13] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[13ページ]。
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.
いかなる他のベンダーの拡大、および将来のIETF拡張子にも衝突しないのを保証して、評価します。 Vendor IDに割り当てられた、その結果、この特徴を最初の6万5535の企業に制限した16ビットがあることに注意してください。
Attribute Type: A 2 octet value with a unique interpretation across all AVPs defined under a given Vendor ID.
タイプを結果と考えてください: ユニークな解釈がすべてのAVPsのむこうにある2八重奏価値は与えられたVendorの下でIDを定義しました。
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.
値を結果と考えてください: Vendor IDとAttribute Typeによって示されるようにこれは実価です。 それは、Attribute Type分野直後続いて、Length(すなわち、ヘッダーの6つの八重奏を引いたLength)で示された残っている八重奏に立候補します。 この分野はLengthが6歳であるなら欠けています。
4.2 Mandatory AVPs
4.2 義務的なAVPs
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ビットはセッションかトンネルの適切な操作に絶対に重要なAVPsのために定義されるだけであるべきです。 さらに、LACかLNSがM-ビットセットで未知のAVPを受けて、それに従って、セッションかトンネルを止める場合では、非共同利用できる状況を引き起こすために欠点を受け入れるのは、同輩がMandatory 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.
新しいAVPs(本書では定義されなかったもの)とのM-ビットの使用は離れて随伴所見を構成する能力を提供しなければなりません、AVPを送りもしませんし、M-ビットがセットしていなく送りもしないように。
4.3 Hiding of AVP Attribute Values
4.3 AVP属性値の隠れること
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ビットは、cleartextで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ビットがいずれかに設定されるなら
Townsley, et al. Standards Track [Page 14] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[14ページ]。
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)、Random Vector 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値は数ステップに隠されます。 第一歩は、オリジナルの(cleartext)AVPの長さと値のグラウンドに出て、以下のHidden AVP Subformatにそれらをコード化することです:
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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の長さです。 これが、追加Paddingが加えられるとき無くなっているAttribute Valueの原長を測定するのに必要です。
Original Attribute Value: Attribute Value that is to be obscured.
元の属性値: 見えなくされることになっているValueを結果と考えてください。
Padding: Random additional octets used to obscure length of the Attribute Value that is being hidden.
詰め物: 無作為の追加八重奏は以前はよく隠されているAttribute Valueの長さをあいまいにしていました。
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.
隠されるデータのサイズにマスクをかけるために、結果として起こる「副-形式」は上に示されるようにそっと歩いているかもしれません。 詰め物は、Original Attribute Value分野のLengthに置かれた値を変更しませんが、作成されている結果のAVPの長さを変更します。 例えば、If、隠されるべきAttribute Valueが長さが4つの八重奏である、unhidden AVPの長さは10の八重奏(6+属性Valueの長さ)でしょう。 隠れることの後に、AVPの長さはOriginal Attribute Value分野+詰め物のLengthの6+属性Value長さ+サイズになるでしょう。 したがって、Paddingが12の八重奏であるなら、AVPの長さは6+4+2+12 = 24の八重奏になるでしょう。
Next, An MD5 hash is performed on the concatenation of:
次に、An MD5ハッシュは以下の連結に実行されます。
+ the 2 octet Attribute number of the AVP + the shared secret + an arbitrary length random vector
+ + 分配のAVP秘密の+の2八重奏Attribute番号は任意の長さの無作為のベクトルです。
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
このハッシュに使用される無作為のベクトルの値はRandom Vector AVPの値の分野で通過されます。 送付者はどんな隠されたAVPsの前にもこのRandom Vector AVPをメッセージに置かなければなりません。 同じ無作為のベクトルは同じくらいの1隠されたAVPに使用されるかもしれません。
Townsley, et al. Standards Track [Page 15] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[15ページ]。
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.
メッセージ。 異なった無作為のベクトルがその後のAVPsの隠れることに使用されるなら、それが適用される最初のAVPの前に新しいRandom Vector 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ハッシュ値はHidden AVP SubformatであってHidden AVPのAttribute Value分野に置かれることの最初の16八重奏(それほど)セグメントがあるXORedです。 Hidden AVP Subformatが16未満の八重奏であるなら、まるでAttribute Value分野がXORの前の16の八重奏に水増しされましたが、Subformatの現在の実際の八重奏だけが変更されていて、AVPの長さが変えられないかのようにSubformatは変成しています。
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の結果があとに続いた共有秘密キーから成る八重奏のストリームに関して計算されます。 そのハッシュはSubformatであってHidden AVPのValue分野の対応する八重奏に置かれることの2番目の16八重奏(それほど)セグメントがあるXORedです。
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:
隠れることメソッドはコーフマン、パールマン、およびSpeciner[KPS]によって「平文では混合する」セクションから本の「ネットワークセキュリティ」で取られたRFC2138[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、Random Vector RV、およびAttribute Value AVに共有秘密キーに電話をしてください。 値の野原を16八重奏の塊p1、最後のものが終わりに無作為のデータで16八重奏の境界に水増しされているp2などに細かく分けてください。 暗号文ブロックを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
b1=MD5(AV+S+RV)c(1)=p1 xor b1 b2がMD5と等しい、(c(1)) c(2)=p2 xor b2……2S+=MD5(S+c(i-1))c(i)=パイxor両性愛者
The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation.
Stringは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.
領収書で、unhiddenになるAVPの前のメッセージで遭遇する最後のRandom Vector AVPから無作為のベクトルを取ります。 そして、上のプロセスは、元の値をもたらすために逆にされます。
Townsley, et al. Standards Track [Page 16] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[16ページ]。
4.4 AVP Summary
4.4 AVP概要
The following sections contain a list of all L2TP AVPs defined in this document.
以下のセクションは本書では定義されたすべてのL2TP AVPsのリストを含みます。
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の目的の短い記述、Attribute Valueのための形式の詳細(グラフィックを含んでいる)、およびavpの適切な使用に必要であるどんな追加情報にも従います。
4.4.1 AVPs Applicable To All Control Messages
4.4.1 すべてのコントロールメッセージに適切なAVPs
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.
Message Type AVP(Attribute Type0)はここにコントロールメッセージを特定して、以下のAVPsの正確な意味が決定する文脈を定義します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type is a 2 octet unsigned integer.
Message Typeは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.
Message Type AVPはメッセージで最初のAVPであるに違いありません、すぐにコントロールメッセージヘッダー(セクション3.1で、定義される)に続いて。 定義されたコントロールメッセージタイプと彼らの識別子のリストに関してセクション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.
Message Type AVPの中のMandatory(M)ビットには、特別な意味があります。 指示よりむしろ、AVP自身が無視されるべきであるか、または認識されるべきであるかに関して、コントロールメッセージ自体が無視されるべきであるかどうかに関してそれは指示です。 したがって、M-ビットがMessage Type AVPの中に設定されて、実装において、Message Typeが未知であるなら、トンネルをきれいにしなければなりません。 M-ビットが設定されないなら、実装は未知のメッセージタイプを無視するかもしれません。 本書では定義されたすべてのメッセージタイプのためにM-ビットを1に設定しなければなりません。 このAVPは隠されないかもしれません(H-ビットは0であるに違いありません)。 このAVPのLengthは8歳です。
Townsley, et al. Standards Track [Page 17] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[17ページ]。
Random Vector (All Messages)
無作為のベクトル(すべてのメッセージ)
The Random Vector AVP, Attribute Type 36, is used to enable the
hiding of the Attribute Value of arbitrary AVPs.
Random Vector AVP(Attribute Type36)は、任意のAVPsのAttribute Valueの隠れることを可能にするのに使用されます。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 無作為の八重奏ストリング… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の八重奏の無作為のベクトルはお勧めですが、Random Octet Stringは任意の長さのものであるかもしれません。 ストリングは隠されたAVPのAttribute Valueを検索するか、または隠すためにMD5ハッシュを計算することにおける使用のための無作為のベクトルを含んでいます(セクション4.2を見てください)。
More than one Random Vector AVP may appear in a message, in which
case a hidden AVP uses the Random Vector AVP most closely
preceding it. This AVP MUST precede the first AVP with the H bit
set.
1Random Vector AVPがメッセージに現れるかもしれません、その場合、隠されたAVPは密接にそれに先行しながら、Random Vector AVPを最も使用します。 Hビットがセットした状態で、このAVP MUSTは最初の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 MUSTのためのM-ビット、1に設定されてください。 このAVP MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVPのLengthはRandom Octet Stringの6と長さです。
4.4.2 Result and Error Codes
4.4.2 結果とエラーコード
Result Code (CDN, StopCCN)
結果コード(CDN、StopCCN)
The Result Code AVP, Attribute Type 1, indicates the reason for
terminating the control channel or session.
Result Code AVP(Attribute Type1)は制御チャンネルかセッションを終える理由を示します。
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 結果コード| エラーコード(選びます)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーメッセージ(選びます)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Result Codeは2八重奏です。符号のない整数。 任意Error Codeは2八重奏です。符号のない整数。 任意のError MessageはError Code野原に続くことができます。 そしてエラーコードの存在。
Townsley, et al. Standards Track [Page 18] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[18ページ]。
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分野によって示されます。 Error Messageはさらに(人間読み込み可能な)状態に関連しているテキストを提供する任意のストリングを含んでいます。 Default Language[RFC2277]を使用して、すべてのエラーメッセージの人間の読み込み可能なテキストをUTF-8 charsetに提供しなければなりません。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
this AVP MUST be set to 1. The Length is 8 if there is no Error
Code or Message, 10 if there is an Error Code and no Error Message
or 10 + the length of the Error Message if there is an Error Code
and Message.
このAVP MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 Lengthは+ そこであるなら、Message、10がError Codeが全くないか、Error Codeにもかかわらず、Error Messageでない10がError Messageの長さであるならError CodeとMessageがあれば8歳です。
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--コントロール接続のために、誤りCodeが問題3を示すというコントロールが向ける2--一般的なエラーをクリアするために、4は既に、存在します--リクエスタが制御チャンネル5を確立するのが認可されません--リクエスタのプロトコルバージョンがサポートしているError Codeが、6--リクエスタであるとサポートされる中で最も高いバージョンが閉鎖7であることを示すということでないという一般要求--有限州Machine誤り
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--呼び出しはエラーコード3(管理理由4で切断された呼び出し)で理由で切断された呼び出しが、呼び出しが利用可能な(一時的な病態)5である適切な施設の不足のため失敗したのを示したというキャリヤー2の損失のため適切な施設の不足のため失敗された呼び出しから切断しました; 利用可能な(永久的な状態)6--無効の目的地7--キャリヤーがないことへの失敗した支払われるべきものが検出した呼び出しであり、8--話中音9の検出のため失敗された呼び出し--呼び出しはダイヤルトーン10の不足のため失敗しました--呼び出しはLAC11によって割り当てられた時中に確立されませんでした--呼び出しは接続されましたが、どんな適切な縁どりも検出されませんでした。
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
以下で定義されたError Codesはどんな特定のL2TP要求にも特定であるのではなく、むしろプロトコルに特定の誤りかメッセージ・フォーマット誤りのタイプに関係します。 L2TP回答がコネを示すなら
Townsley, et al. Standards Track [Page 19] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[19ページ]。
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:
Result Code、一般的なエラーは起こって、一般Error値は、誤りが何であったかを決定するために調べられるべきです。 現在定義された一般Errorコードとそれらの意味は以下の通りです。
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.
非ゼロは現在この操作を扱う4--不十分なリソースでした。0--一般的な誤りがありません1--どんなコントロール接続もこのLAC-LNS組2のためにまだ存在していません--長さが分野値の3--間違った1つが範囲から脱していたか、または分野を予約したということである、Session IDはこの文脈6で無効です--ジェネリックのベンダー特有の誤りがLAC7に発生したという5は別のものを試みます。 LACが他の可能なLNSの目的地を意識しているなら、それはそれらの1つを試みるべきです。 LNS方針に基づくLACを誘導するのにこれを使用できます、例えば、マルチリンクPPPの存在は荷物をまとめます。 8--M-ビットセットがある未知のAVPの領収書でセッションかトンネルが閉鎖(セクション4.2を見る)でした。 Error Message SHOULDは(人間読み込み可能)のテキストフォームにおける、怒っているAVPの属性を含んでいます。
When a General Error Code of 6 is used, additional information
about the error SHOULD be included in the Error Message field.
含まれていて、6のError Code司令官がError Message分野の誤りSHOULDに関する中古の追加情報であるときに。
4.4.3 Control Connection Management AVPs
4.4.3 コントロール接続管理AVPs
Protocol Version (SCCRP, SCCRQ)
プロトコルバージョン(SCCRP、SCCRQ)
The Protocol Version AVP, Attribute Type 2, indicates the L2TP
protocol version of the sender.
プロトコルバージョンAVP(Attribute Type2)は送付者の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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver| 回転| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver field is a 1 octet unsigned integer containing the value
1. Rev field is a 1 octet unsigned integer containing 0. This
pertains to L2TP protocol version 1, revision 0. Note this is not
the same version number that is included in the header of each
message.
Ver分野は1つの八重奏の符号のない整数含有です。値1。 回転分野は0に1つの八重奏の符号のない整数含有です。 これはL2TPプロトコルバージョン1、改正0に関係します。 これがそれぞれのメッセージのヘッダーに含まれているのと同じバージョン番号でないことに注意してください。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
this AVP MUST be set to 1. The Length of this AVP is 8.
このAVP MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLengthは8歳です。
Townsley, et al. Standards Track [Page 20] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[20ページ]。
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.
Framing Capabilities AVP(Attribute Type3)は送付者が受け入れるか、または要求する縁どりのタイプのしるしを同輩に提供します。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 今後の縁どり型定義のために、予約されます。|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.
Attribute Value分野は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.
同輩は、Framing Type AVPが値を指定している入って来るか外向的な呼び出しがそれがコントロールコネクション確立の間に受けたFraming Capabilities 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 MUSTのためのM-ビット、1に設定されてください。 Length(隠れることの前の)は10歳です。
Bearer Capabilities (SCCRP, SCCRQ)
運搬人能力(SCCRP、SCCRQ)
The Bearer Capabilities AVP, Attribute Type 4, provides the peer
with an indication of the bearer device types supported by the
hardware interfaces of the sender for outgoing calls.
Bearer Capabilities AVP(Attribute Type4)は発信電話のために送付者のハードウェア・インタフェースによってサポートされた運搬人の装置タイプのしるしを同輩に提供します。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 今後の運搬人型定義のために、予約されます。|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が設定されるなら、デジタルアクセスはサポートされます。
Townsley, et al. Standards Track [Page 21] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[21ページ]。
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は、Bearer Type AVPで装置タイプに値を指定する発信電話がそれがコントロールコネクション確立の間にLACから受けたBearer Capabilities AVPに広告を出さなかったよう要求するはずがありません。 そうする試みは拒絶される呼び出しをもたらすでしょう。
This AVP MUST be present if the sender can place outgoing calls
when requested.
このAVP MUST、要求されると送付者が発信電話を置くことができるなら、存在してください。
Note that an LNS that cannot act as an LAC as well will not
support hardware devices for handling incoming and outgoing calls
and should therefore set the A and D bits of this AVP to 0, or
should not send the AVP at all. An LNS that can also act as an LAC
and place outgoing calls should set A or D as appropriate.
Presence of this message is not a guarantee that a given outgoing
call will be placed by the sender if requested, just that the
physical capability exists.
また、LACが送受信していた状態で取り扱いのためのハードウェアデバイスを支えないとき行動できないLNSが呼んで、したがって、このAVPのAとDビットを0に設定するべきであるはずがありませんし、またAVPを全く送るはずがないことに注意してください。 また、LACと場所発信電話として機能できるLNSは適宜AかDを設定するはずです。 このメッセージの存在は要求されると与えられた発信電話が送付者によって置かれるという保証でなく、まさしくそれは物理的な能力です。存在しています。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) is 10.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 Length(隠れることの前の)は10歳です。
Tie Breaker (SCCRQ)
タイブレーク(SCCRQ)
The Tie Breaker AVP, Attribute Type 5, indicates that the sender
wishes a single tunnel to exist between the given LAC-LNS pair.
Tie Breaker AVP(Attribute Type5)は、送付者が、単一のトンネルが与えられた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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 中断値を結んでください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...(64ビット) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Tie Breaker ValueはLACとLNSの両方が同時にトンネルを要求する単一のトンネルを選ぶのに使用される8八重奏価値です。 SCCRQの受取人はSCCRQが同輩に送られたかどうかを見るためにチェックしなければなりません、そして、そうだとすれば、必須は容認されたものとTie Breaker値を比べます。 下側の値は「勝ちます」、そして、「敗者」は静かにトンネルを捨てなければなりません。 タイブレークが両側に存在していて、値が等しい場合では、両側はそれらのトンネルを捨てなければなりません。
Townsley, et al. Standards Track [Page 22] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[22ページ]。
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にタイブレーク値が全くなかったなら、Tie Breaker 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 MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 このAVPのLengthは14歳です。
Firmware Revision (SCCRP, SCCRQ)
ファームウェア改正(SCCRP、SCCRQ)
The Firmware Revision AVP, Attribute Type 6, indicates the
firmware revision of the issuing device.
Firmware Revision AVP(Attribute Type6)は発行デバイスのファームウェア改正を示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ファームウェア改正| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Firmware Revision is a 2 octet unsigned integer encoded in a
vendor specific format.
Firmware Revisionは符号のない整数がベンダーの特定の形式でコード化した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 MUSTのためのM-ビット、0に設定されてください。 Length(隠れることの前の)は8歳です。
Host Name (SCCRP, SCCRQ)
ホスト名(SCCRP、SCCRQ)
The Host Name AVP, Attribute Type 7, indicates the name of the
issuing LAC or LNS.
Host Name AVP(Attribute Type7)は発行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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 名前をホスティングしてください… (八重奏の特殊活字の数字) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name is of arbitrary length, but MUST be at least 1
octet.
Host Nameは任意の長さがありますが、少なくとも1つの八重奏であるに違いありません。
Townsley, et al. Standards Track [Page 23] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[23ページ]。
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 MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLengthはHost Nameの6と長さです。
Vendor Name (SCCRP, SCCRQ)
ベンダー名(SCCRP、SCCRQ)
The Vendor Name AVP, Attribute Type 8, contains a vendor specific
(possibly human readable) string describing the type of LAC or LNS
being used.
Vendor Name AVP(Attribute Type8)は使用される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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダー名…(八重奏の特殊活字の数字) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
Vendor Nameはベンダーストリングを表す八重奏の示された数です。 UTF-8 charset使用におけるDefault Languageであるなら、このAVP MUSTにおける人間の読み込み可能なテキストはこと[RFC2277]です。
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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)はVendor Nameの6と長さです。
Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
割り当てられたTunnel ID(SCCRP、SCCRQ、StopCCN)
The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being
assigned to this tunnel by the sender.
Assigned Tunnel ID AVP(Attribute Type9)は送付者によってこのトンネルに割り当てられる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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 割り当てられたTunnel ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.
Assigned Tunnel 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
Assigned Tunnel ID AVPは多重送信するのに使用される値を確立します、そして、「反-マルチプレックス」倍数はLNSとLACの間でトンネルを堀ります。 L2TP同輩はすべてのTunnel IDヘッダーフィールドにこの値を置かなければなりません。
Townsley, et al. Standards Track [Page 24] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[24ページ]。
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.
コントロールと次に関連トンネルの上で送るというデータメッセージ。 同輩からAssigned Tunnel ID AVPを受け取る前に、0のTunnel 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では、Assigned Tunnelと同じくらいが最初に受信同輩に送られたID AVPであったならメッセージ、Assigned Tunnel ID AVP MUSTを制御してください、Assigned Tunnel ID AVPが受け取られている前にStopCCNを送っても同輩が適切なトンネルを特定することを許可して。
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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は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.
Receive Window Size AVP(Attribute Type10)はリモート同輩に提供されるレシーブ・ウィンドウ・サイズを指定します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ウィンドウサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2 octet unsigned integer.
Window Sizeは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のWindow Sizeを仮定しなければならないかどうか、それ、窓を伝えてください。 承認を待たなければならない前にリモート同輩はコントロールメッセージの指定された数を送るかもしれません。
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 MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLengthは8歳です。
Challenge (SCCRP, SCCRQ)
挑戦(SCCRP、SCCRQ)
The Challenge AVP, Attribute Type 11, indicates that the issuing
peer wishes to authenticate the tunnel endpoints using a CHAP-
style authentication mechanism.
Challenge AVP(Attribute Type11)は、発行している同輩がCHAPスタイル認証機構を使用することでトンネル終点を認証したがっているのを示します。
Townsley, et al. Standards Track [Page 25] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 挑戦してください… (八重奏の特殊活字の数字) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data.
Challengeは無作為のデータの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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)はChallengeの6と長さです。
Challenge Response (SCCCN, SCCRP)
チャレンジレスポンス(SCCCN、SCCRP)
The Response AVP, Attribute Type 13, provides a response to a
challenge received.
Response AVP(Attribute Type13)は受けられた挑戦への応答を提供します。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 応答… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (16の八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16 octet value reflecting the CHAP-style
[RFC1994] response to the challenge.
Responseは挑戦への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).
このAVP MUST、前のSCCRQかSCCRPで挑戦を受けたなら、SCCRPかSCCCNに存在してください。 CHAP応答計算におけるID価値の目的のために、このメッセージのためのMessage Type AVPの値は使用されています(例えば、SCCRPのための2、およびSCCCNのための3)。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 22.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は22歳です。
Townsley, et al. Standards Track [Page 26] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[26ページ]。
4.4.4 Call Management AVPs
4.4.4 管理をAVPsと呼んでください。
Q.931 Cause Code (CDN)
Q.931原因コード(CDN)
The Q.931 Cause Code AVP, Attribute Type 12, is used to give
additional information in case of unsolicited call disconnection.
Q.931 Cause Code AVP(Attribute Type12)は、求められていない呼び出し断線の場合に追加情報を与えるのに使用されます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
原因Codeは返されたQ.931 Causeコードです、そして、CauseエムエスジーはCause Codeに関連している返されたQ.931メッセージコード(例えば、DISCONNECT)です。 それらのネイティブのITU encodings[DSS1]で両方の値を返します。 また、追加ASCIIテキストAdvisory Messageは、さらに切断する理由について説明するために含まれるかもしれません(AVP Lengthによって示された存在)。
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 MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLengthは9と、Advisory Messageのサイズです。
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
割り当てられたSession 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.
Assigned Session ID AVP(Attribute Type14)はこのセッションまで送付者によって割り当てられる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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 割り当てられたSession ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Session ID is a 2 octet non-zero unsigned integer.
Assigned Session IDは2八重奏非ゼロです。符号のない整数。
The Assigned Session ID AVP is establishes a value used to
multiplex and demultiplex data sent over a tunnel between the LNS
and LAC. The L2TP peer MUST place this value in the Session ID
header field of all control and data messages that it subsequently
transmits over the tunnel that belong to this session. Before the
Assigned Session ID AVPはそうです。LNSとLACの間で多重送信するのに使用される値とトンネルの上に送られた「反-マルチプレックス」データを確立します。 L2TP同輩はすべてのコントロールと次にこのセッションに属するトンネルの上で送るというデータメッセージのSession IDヘッダーフィールドにこの値を置かなければなりません。 以前
Townsley, et al. Standards Track [Page 27] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[27ページ]。
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.
同輩から割り当てられたSession ID AVPを受け取って、すべてのコントロールメッセージのヘッダーの0のSession 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コントロールメッセージでは、最初に受信同輩に送られた同じAssigned Session ID AVPは使用されています、Assigned Session IDが受け取られている前にCDNを送っても同輩が適切なトンネルを特定することを許可して。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 8.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は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.
Call Serial Number AVP(Attribute Type15)は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 通し番号に電話をしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Serial Number is a 32 bit value.
Call Serial Numberは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.
Call Serial Numberは呼び出し失敗問題を調査するときトンネルの両端の管理者が使用する簡単な参照であることを意図します。すべての向こう側の重要な期間がLNSsとLACsとインタコネクトしたので、呼び出しSerial民数記は次第に、値を増強するのに設定されるべきです。(値は特有である傾向があります)。
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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は10歳です。
Minimum BPS (OCRQ)
最小のビーピーエス(OCRQ)
The Minimum BPS AVP, Attribute Type 16, encodes the lowest
acceptable line speed for this call.
Minimum BPS AVP(Attribute Type16)はこの呼び出しのために最も低い許容できるライン・スピードをコード化します。
Townsley, et al. Standards Track [Page 28] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[28ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32 bit value indicates the speed in bits per
second.
Minimum BPSによる32ビットの値がbpsにおける速度を示すということです。
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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は10歳です。
Maximum BPS (OCRQ)
最大のビーピーエス(OCRQ)
The Maximum BPS AVP, Attribute Type 17, encodes the highest
acceptable line speed for this call.
Maximum BPS AVP(Attribute Type17)はこの呼び出しのために最も高い許容できるライン・スピードをコード化します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32 bit value indicates the speed in bits per
second.
Maximum BPSによる32ビットの値がbpsにおける速度を示すということです。
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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は10歳です。
Bearer Type (ICRQ, OCRQ)
運搬人タイプ(ICRQ、OCRQ)
The Bearer Type AVP, Attribute Type 18, encodes the bearer type
for the incoming or outgoing call.
Bearer Type AVP(Attribute Type18)は入って来るか外向的な呼び出しのための運搬人タイプをコード化します。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 将来のBearer Typesのために、予約されます。|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Townsley, et al. Standards Track [Page 29] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[29ページ]。
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.
Bearer Typeは32ビットの噛み付いているマスクです。(そのマスクは要求(OCRQ)のための要求(ICRQ)か必要の運搬人能力を示します)。 設定されるなら、ビット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 MUSTのValue分野だけでは、それがコントロールコネクション確立の間にLACから受け取られたBearer Capabilities AVPのセットであったならLNSによってOCRQに設定されてください。
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ビットです。 呼び出しをあった設定が示すかもしれないそのようなものが物理的なリンクの上に受信されませんでした(e.gは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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は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.
Framing Type AVP(Attribute Type19)は入って来るか外向的な呼び出しのための縁どりタイプをコード化します。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 将来の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].
Framing Typeは32ビットのマスクであるかPPP縁どりのタイプがOCCNかICCNを交渉しました。(それは、OCRQのために要求されたPPP縁どりのタイプを示します)。 縁どりタイプは指示としてLCP交渉[RFC1662]にどんなリンクオプションを使用したらよいかに関してLNSの上のPPPに慣れるかもしれません。
Bit A indicates asynchronous framing. Bit S indicates synchronous
framing. For an OCRQ, both may be set, indicating that either type
of framing may be used.
ビットAは非同期な縁どりを示します。 ビットSは同期縁どりを示します。 OCRQにおいて、どちらかのタイプの縁どりが使用されるかもしれないのを示して、両方が設定されるかもしれません。
Bits in the Value field of this AVP MUST only be set by the LNS
for an OCRQ if it was set in the Framing Capabilities AVP received
from the LAC during control connection establishment.
ビット、このAVP MUSTのValue分野だけでは、それがコントロールコネクション確立の間にLACから受け取られたFraming Capabilities AVPのセットであったならLNSによってOCRQに設定されてください。
Townsley, et al. Standards Track [Page 30] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[30ページ]。
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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は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.
Called Number AVP(Attribute Type21)はOCRQのために電話をされる電話番号をコード化して、ICRQのためにCalled番号をコード化します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 数と呼ばれます… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Called Numberは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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)はCalled Numberの6と長さです。
Calling Number (ICRQ)
数と呼びます。(ICRQ)
The Calling Number AVP, Attribute Type 22, encodes the originating
number for the incoming call.
Calling Number AVP(Attribute Type22)はかかってきた電話の起因する番号をコード化します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
Numberと呼ぶのは、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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)はCalling Numberの6と長さです。
Townsley, et al. Standards Track [Page 31] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[31ページ]。
Sub-Address (ICRQ, OCRQ)
サブアドレス(ICRQ、OCRQ)
The Sub-Address AVP, Attribute Type 23, encodes additional dialing
information.
Sub-アドレスAVP(Attribute Type23)は追加番号案内に電話をかけることをコード化します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブアドレス… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Sub-アドレスは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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)はSub-アドレスの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)はSpeed BPS AVP、Attribute Type24を接続して、エンコードは接続試みに選ばれた施設の速度です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
in bits per second.
(Tx)は接続します。Speed 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.
伝わってください。このAVPの値が、いつ任意のRx Connect Speed AVPが存在していると表すか、速度を接続してください、LAC(例えばLACからリモートシステムまで流れるデータ)の見解から。 任意のRx Connect Speed AVPが存在していないとき、リモートシステムとLACの間の接続速度は、左右対称であると思われて、このAVPにただ一つの値によって表されます。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は10歳です。
Townsley, et al. Standards Track [Page 32] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[32ページ]。
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 Connect Speed AVP(Attribute Type38)は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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)では、Speed 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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は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.
Physical Channel ID AVP(Attribute Type25)は呼び出しに使用されるベンダーの特定の物理的な論理機番をコード化します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 物理的なチャンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4 octet value intended to be used for
logging purposes only.
物理的なChannel 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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は10歳です。
Townsley, et al. Standards Track [Page 33] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[33ページ]。
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.
兵士のGroup ID AVP(Attribute Type37)は、この呼び出しがうるさい顧客グループに関連していることであることを示すのに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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 個人的なグループID… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length.
兵士のGroup 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 MAYは同輩で決定している特別な態度で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.
兵士のGroup IDは選択されたグループの特定の特性を定義するLNSのテーブルに対応するストリングです。 LAC MAYはRADIUS応答、地方の構成、またはある他のソースから兵士のGroup 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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は兵士のGroup 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.
Sequencing Required AVP(Attribute Type39)は、Sequence民数記がデータ・チャンネルにいつも存在していなければならないのをLNSに示します。
This AVP has no Attribute Value field.
このAVPには、Attribute Value分野が全くありません。
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 MUST NOT、隠されてください(H-ビットは0であるに違いありません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLengthは6歳です。
4.4.5 Proxy LCP and Authentication AVPs
4.4.5 プロキシLCPと認証AVPs
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
LACは、システムの見かけのアイデンティティを確立するために恐らく電話口に出て、リモートシステムとLCPを交渉したかもしれません。 この場合、これらのAVPsは、示すために含まれるかもしれません。
Townsley, et al. Standards Track [Page 34] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[34ページ]。
link properties the remote system initially requested, properties
the remote system and LAC ultimately negotiated, as well as PPP
authentication information sent and received by the LAC. This
information may be used to initiate the PPP LCP and authentication
systems on the LNS, allowing PPP to continue without renegotiation
of LCP. Note that the LNS policy may be to enter an additional
round of LCP negotiation and/or authentication if the LAC is not
trusted.
LACによって送られて、受け取られたPPP認証情報と同様に結局交渉された特性のリモートシステムが初めは要求した特性、リモートシステム、およびLACをリンクしてください。 この情報はLNSでPPP LCPと認証システムを開始するのに使用されるかもしれません、PPPがLCPの再交渉なしで続くのを許容して。 LNS方針がLACが信じられないならLCP交渉、そして/または、認証の追加ラウンドに入ることであるかもしれないことに注意してください。
Initial Received LCP CONFREQ (ICCN)
初期の容認されたLCP CONFREQ(ICCN)
In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
provides the LNS with the Initial CONFREQ received by the LAC from
the PPP Peer.
Initial Received LCP CONFREQ AVP、Attribute Type26に、Initial CONFREQがLACによってPPP Peerから受け取られている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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージのボディーの中の第1の選択から受け取られた初期の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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は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.
Last Sent LCP CONFREQ AVP、Attribute Type27に、Last CONFREQがLACによってPPP Peerに送られる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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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交渉を終了するためにクライアントに送られた最終的なCONFREQのボディーのコピーです、LCPメッセージのボディーの中の第1の選択から。
Townsley, et al. Standards Track [Page 35] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[35ページ]。
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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は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.
Last Received LCP CONFREQ AVP(Attribute Type28)はLACによってPPP Peerから受け取られたLast 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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交渉を終了するためにクライアントから受け取られた最終的なCONFREQのボディーのコピーです、LCPメッセージのボディーの中の第1の選択から。
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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)はCONFREQの6と長さです。
Proxy Authen Type (ICCN)
プロキシAuthenはタイプします。(ICCN)
The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
authentication should be used.
Proxy Authen Type AVP(Attribute Type29)は、プロキシ認証が使用されるべきであるかどうか決定します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Type is a 2 octet unsigned integer, holding:
Authen Type、以下を保持して、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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は8歳です。
Townsley, et al. Standards Track [Page 36] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[36ページ]。
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 Type値は以下の通りです。 0--予約された1--原文のユーザ名/パスワード交換2--PPP CHAP3--PPP PAP4--Authentication5がありません--マイクロソフト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 MUST、プロキシ認証が利用されていることであるなら、存在してください。 それが存在していないなら、この同輩がプロキシ認証を実行できないと思われます、クライアントが既にLAC(Proxy LCP AVPで断固としていますが、存在しているかもしれない)とのこのフェーズに入ったならLNSで認証フェーズの再開を必要として。
Associated AVPs for each type of authentication follow.
それぞれのタイプの認証のための関連AVPsは続きます。
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.
プロキシ認証を使用するとき、Proxy Authen Name AVP(Attribute Type30)は認証しているクライアントの名前を指定します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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名… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Name is a string of octets of arbitrary length. It
contains the name specified in the client's authentication
response.
Authen Nameは任意の長さの一連の八重奏です。 それはクライアントの認証応答で指定された名前を含んでいます。
This AVP MUST be present in messages containing a Proxy Authen
Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable
to employ AVP hiding for obscuring the cleartext name.
このAVP MUST、1、2、3または5のAuthen TypeとProxy Authen Type AVPを含んで、メッセージに存在してください。 cleartext名をあいまいにするために隠れるAVPを使うのは望ましいかもしれません。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) is 6 plus
the length of the cleartext name.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 Length(隠れることの前の)はcleartext名の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.
Proxy Authen Challenge AVP(Attribute Type31)はプロキシ認証を使用するときLACによってPPP Peerに送られた挑戦を指定します。
Townsley, et al. Standards Track [Page 37] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[37ページ]。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 挑戦してください… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is a string of one or more octets.
Challengeは一連の1つ以上の八重奏です。
This AVP MUST be present for Proxy Authen Types 2 and 5. The
Challenge field contains the CHAP challenge presented to the
client by the LAC.
このAVP MUST、Proxy Authen Types2と5のために、存在してください。 Challenge分野は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 MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)は6と、Challengeの長さです。
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.
Proxy Authen ID AVP(Attribute Type32)はLACとPPP Peerの間で始動されたPPP Authenticationの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 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.
Proxy Authen ID AVP MUST、Proxy authenタイプ2、3、および5のために、存在してください。 2と5のために、ID分野はChallengeにID値がLACでクライアントに提示したバイトを含んでいます。 3のために、それはAuthenticate-要求のIdentifier値です。
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 MUSTのための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.
Proxy Authen Response AVP(Attribute Type33)はLACによってPPP Peerから受けられたPPP Authentication応答を指定します、プロキシ認証が使用されているとき。
Townsley, et al. Standards Track [Page 38] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[38ページ]。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 応答… (八重奏の特殊活字の数字) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a string of octets.
Responseは一連の八重奏です。
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 MUST、Proxy authenタイプ1、2、3、および5のために、存在してください。 Response分野は挑戦へのクライアントの応答を含んでいます。 Proxy authenタイプ2と5のために、この分野はLACで応答対価領収を含みます。 タイプ1か3のために、それはLACによってクライアントから受け取られたクリアテキストパスワードを含んでいます。 cleartextパスワードの場合では、AVP隠れることはお勧めです。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the Response.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 このAVPのLength(隠れることの前の)はResponseの6と長さです。
4.4.6 Call Status AVPs
4.4.6 AVPsに状態に電話をしてください。
Call Errors (WEN)
誤りに電話をしてください。(こぶ)
The Call Errors AVP, Attribute Type 34, is used by the LAC to send
error information to the LNS.
Call Errors AVP(Attribute Type34)は、エラー情報を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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| CRC誤り(H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC誤り(L)| 縁どり誤り(H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 縁どり誤り(L)| ハードウェア超過(H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハードウェア超過(L)| バッファ超過(H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バッファ超過(L)| タイムアウト誤り(H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムアウト誤り(L)| 整列誤り(H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 整列誤り(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Townsley, et al. Standards Track [Page 39] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[39ページ]。
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
呼び出しが確立されて以来0CRC Errors(呼び出しが確立したAlignment Errorsであった時から呼び出しが確立したFraming Errorsであった時からCRC誤り--容認されたHardware Overruns(呼び出しが確立したBuffer Overrunsであった時から受信バッファ超過の数)番号のバッファ超過が呼び出しが確立した外のTime Errorsであったので検出した不適切に縁どられたPPPパケットの数--タイムアウトの数で受け取られたPPPフレームの数)が整列誤りの数であったに違いないなら使用されないで、予約されます。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 32.
このAVPは隠されるかもしれません(H-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、1に設定されてください。 このAVPのLength(隠れることの前の)は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(Attribute Type35)は、LNSによってPPP Peerと交渉された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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| ACCM(H)を送ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACCM(L)を送ってください。| ACCM(H)を受けてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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を送ってください。そうすれば、Receive 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 MUSTのためのM-ビット、1に設定されてください。 このAVPのLengthは16歳です。
Townsley, et al. Standards Track [Page 40] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[40ページ]。
5.0 Protocol Operation
5.0 プロトコル操作
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セッションにトンネルを堀るための必要なセットアップは入って来るか送信する発呼要求で引き起こされるようにSessionを設立する2ステップ、TunnelのためにControl Connectionを設立する(1)、および(2)から成ります。 入って来るか外向的な呼び出しが開始される前にTunnelと対応するControl Connectionを設立しなければなりません。 L2TPがPPPフレームにトンネルを堀り始めることができる前にL2TP Sessionを設立しなければなりません。 複数のセッションズが独身のTunnelの向こう側に存在するかもしれません、そして、複数のTunnelsが同じLACとLNSの間に存在するかもしれません。
+-----+ +-----+
| |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
| LAC | | LNS |
| #######Control Connection######## |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+
+-----+ +-----+ | |~~~~~~~~~~L2TPトンネル~~~~~~~~~~| | | ラック| | LNS| | #######コントロール接続########| [リモート]です。| | | | [システム]------呼び出し----------*============L2TPセッション=============* | ppp、++++++++++++++++++++++++++++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + +| | | | | [リモート]です。| | | | [システム]------呼び出し----------*============L2TPセッション=============* | ppp、++++++++++++++++++++++++++++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + +| | | | | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | +-----+ +-----+
Figure 5.1 Tunneling PPP
図5.1 トンネリングppp
5.1 Control Connection Establishment
5.1 コントロールコネクション確立
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.
Control Connectionはセッションが持って来られるかもしれない前に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
ラック、LNSラックまたは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を送ります。
Townsley, et al. Standards Track [Page 41] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[41ページ]。
5.1.1 Tunnel Authentication
5.1.1 トンネル認証
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願望であるなら、Challenge AVPはSCCRQかSCCRPメッセージに含まれています。 SCCRQかSCCRPにChallenge AVPを受け取るなら、以下のSCCRPかSCCCNでそれぞれChallenge Response AVPを送らなければなりません。 同輩から受けられた予想された応答と応答が合っていないなら、トンネルの設立を禁じなければなりません。
To participate in tunnel authentication, a single shared secret MUST exist between the LAC and LNS. This is the same shared secret used for AVP hiding (see Section 4.3). See Section 4.4.3 for details on construction of the Challenge and Response AVPs.
トンネル認証に参加するために、ただ一つの共有秘密キーはLACとLNSの間に存在しなければなりません。 これはAVP隠れることに使用される同じ共有秘密キー(セクション4.3を見る)です。 ChallengeとResponse AVPsの構造に関する詳細に関してセクション4.4.3を見てください。
5.2 Session Establishment
5.2 セッション設立
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に要求します。
5.2.1 Incoming Call Establishment
5.2.1 かかってきた電話設立
A three message exchange is employed to setup the session. Following is a typical sequence of events:
3交換処理は、セッションをセットアップするのに使われます。 以下に、イベントの典型的な系列があります:
LAC LNS
--- ---
(Call
Detected)
ラックLNS--- --- (検出された呼び出し)
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を送ります。
Townsley, et al. Standards Track [Page 42] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[42ページ]。
5.2.2 Outgoing Call Establishment
5.2.2 発信電話設立
A three message exchange is employed to setup the session. Following is a typical sequence of events:
3交換処理は、セッションをセットアップするのに使われます。 以下に、イベントの典型的な系列があります:
LAC LNS
--- ---
<- OCRQ
OCRP ->
ラック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を送ります。
5.3 Forwarding PPP Frames
5.3 推進pppフレーム
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.
メッセージの送付者はすべての送信されるメッセージのためにSession IDとTunnel IDヘッダーでSession IDとTunnel 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.
Session IDとTunnel IDへの0の値は、特別であり、Assigned Session IDかAssigned Tunnel IDとして使用されてはいけません。 Session IDが同輩(すなわち、新しいセッションかトンネルの設立の間の)によってまだ割り当てられていないケースにおいて、0としてSession ID野原を送らなければなりません、そして、セッションを特定するのにメッセージの中のAssigned Session ID AVPを使用しなければなりません。 同様に、Tunnel IDが同輩からまだ割り当てられていないケースにおいて、0としてTunnel IDを送らなければなりません、そして、Assigned Tunnel ID AVPは以前はよくトンネルを特定していました。
Townsley, et al. Standards Track [Page 43] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[43ページ]。
5.4 Using Sequence Numbers on the Data Channel
5.4 データ・チャンネルの一連番号を使用すること。
Sequence numbers are defined in the L2TP header for control messages and optionally for data messages (see Section 3.1). These are used to provide a reliable control message transport (see Section 5.8) and optional data message sequencing. Each peer maintains separate sequence numbers for the control connection and each individual data session within a tunnel.
一連番号はデータメッセージのためにコントロールメッセージのためのL2TPヘッダーに任意に定義されます(セクション3.1を見てください)。 これらは、信頼できるコントロールメッセージ転送(セクション5.8を見る)と任意のデータメッセージ配列を提供するのに使用されます。 各同輩は、コントロールのための別々の一連番号が接続とトンネルの中のそれぞれの個々のデータセッションであることを支持します。
Unlike the L2TP control channel, the L2TP data channel does not use sequence numbers to retransmit lost data messages. Rather, data messages may use sequence numbers to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. The LAC may request that sequence numbers be present in data messages via the Sequencing Required AVP (see Section 4.4.6). If this AVP is present during session setup, sequence numbers MUST be present at all times. If this AVP is not present, sequencing presence is under control of the LNS. The LNS controls enabling and disabling of sequence numbers by sending a data message with or without sequence numbers present at any time during the life of a session. Thus, if the LAC receives a data message without sequence numbers present, it MUST stop sending sequence numbers in future data messages. If the LAC receives a data message with sequence numbers present, it MUST begin sending sequence numbers in future outgoing data messages. If the LNS enables sequencing after disabling it earlier in the session, the sequence number state picks up where it left off before.
L2TP制御チャンネルと異なって、L2TPデータ・チャンネルは、ロストデータメッセージを再送するのに一連番号を使用しません。 むしろ、データメッセージは、無くなっているパケットを検出する、そして/または、輸送の間に再命令されているかもしれないパケットの元の系列を回復するのに一連番号を使用するかもしれません。 LACは、一連番号がSequencing Required AVPを通してデータメッセージに存在しているよう要求するかもしれません(セクション4.4.6を見てください)。 このAVPがセッションセットアップの間、存在しているなら、一連番号はいつも存在していなければなりません。 このAVPが存在していないなら、配列存在はLNSで制御されています。 LNSは、いつでもセッションの寿命の間の現在の一連番号のあるなしにかかわらずデータメッセージを送ることによって、一連番号を可能にするのと無効にすることを制御します。 したがって、LACが存在している一連番号なしでデータメッセージを受け取るなら、それは、将来のデータメッセージの一連番号を送るのを止めなければなりません。 一連番号が存在していた状態でLACがデータメッセージを受け取るなら、それは、将来の発信データメッセージの一連番号を送り始めなければなりません。 セッションのときに前にそれを無効にした後にLNSが配列を可能にするなら、一連番号状態はそれが以前やめられたところで回復します。
The LNS may initiate disabling of sequencing at any time during the session (including the first data message sent). It is recommended that for connections where reordering or packet loss may occur, sequence numbers always be enabled during the initial negotiation stages of PPP and disabled only when and if the risk is considered acceptable. For example, if the PPP session being tunneled is not utilizing any stateful compression or encryption protocols and is only carrying IP (as determined by the PPP NCPs that are established), then the LNS might decide to disable sequencing as IP is tolerant to datagram loss and reordering.
LNSはいつでも、セッションの間、配列を無効にすることを開始するかもしれません(最初のデータメッセージを含んでいるのは発信しました)。 PPPの初期の交渉台の間、いつも可能にされて、いつだけが無効にされるか、そして、危険が許容できると考えられるなら、再命令かパケット損失が起こるかもしれない接続、一連番号のためのそれはそれに推薦されます。 例えば、トンネルを堀られるPPPセッションが少しのstateful圧縮や暗号化プロトコルも利用していなくて、IPを運ぶだけであるなら(確立されるPPP NCPで決定するように)、LNSは、IPはデータグラムの損失と再命令に許容性があるので配列を無効にすると決めるかもしれません。
5.5 Keepalive (Hello)
5.5 Keepalive(こんにちは)
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
keepaliveメカニズムは、トンネルの上でコントロールでないデータ活動がない長期間とトンネル供給停止を区別するのにL2TPによって使われます。 これは、トンネルの上に最後のデータかコントロールメッセージを受け取って以来指定された期間が経過している後にHelloコントロールメッセージ(セクション6.5を見る)を注入することによって、達成されます。 いかなる他のコントロールメッセージに関しても、Helloメッセージが確かに送られないなら、トンネルは、下がっていると申告されて、リセットされます。 輸送リセット
Townsley, et al. Standards Track [Page 44] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[44ページ]。
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.
Helloメッセージの注射に伴うメカニズムは、LNSとLACの間の接続性失敗がトンネルの両端に検出されるのを確実にします。
5.6 Session Teardown
5.6 セッション分解
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
ラック、LNSラックまたはLNS
CDN ->
(Clean up)
CDN->。(きれいにします)
<- ZLB ACK
(Clean up)
<ZLB ACK(きれいにします)
5.7 Control Connection Teardown
5.7 コントロール接続分解
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の受信機は、少なくとも完全な「再-トランスミッション」サイクルにわたってメッセージの領収書を受け取ったことを知らせて、適切にStopCCN retransmissionsを受け入れることができるくらいのコントロール接続状態を維持するためにZLB ACKを送らなければなりません(ZLB ACKが無くなるといけないので)。 完全な「再-トランスミッション」サイクルの間のお勧めの時間は31秒(セクション5.8を見る)です。 以下に、典型的なコントロール交換処理に関する例があります:
LAC or LNS LAC or LNS
ラック、LNSラックまたはLNS
StopCCN ->
(Clean up)
StopCCN->。(きれいにします)
<- ZLB ACK
(Wait)
(Clean up)
<ZLB ACK(待っています)(きれいにします)
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を送ることによって、トンネルの全体のトンネルとセッションを止めるかもしれません。 全体のトンネルを取りこわすとき、したがって、各セッションのときに個別にクリアするのは必要ではありません。
Townsley, et al. Standards Track [Page 45] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[45ページ]。
5.8 Reliable Delivery of Control Messages
5.8 コントロールメッセージの信頼できる配信
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はすべてのコントロールメッセージのための下のレベルの信頼できる輸送サービスを提供します。 コントロールメッセージヘッダー(セクション3.1を見る)のNrとNs分野はこの輸送に属します。 L2TPの機能が「再-トランスミッション」に関係があるか、またはコントロールメッセージについて注文していないレベルは、より上側です。 信頼できるコントロールメッセージはコントロールメッセージの再送と輻輳制御を提供する引窓輸送です。 各同輩はコントロール接続のためにトンネルの中で別々の一連番号状態を維持します。
The message sequence number, Ns, begins at 0. Each subsequent message is sent with the next increment of the sequence number. The sequence number is thus a free running counter represented modulo 65536. The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32767 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered a duplicate of a message already received and ignored from processing. However, in order to ensure that all messages are acknowledged properly (particularly in the case of a lost ZLB ACK message), receipt of duplicate messages MUST be acknowledged by the reliable transport. This acknowledgement may either piggybacked on a message in queue, or explicitly via a ZLB ACK.
メッセージ通番(Ns)は0時に始まります。 一連番号の次の増分と共にそれぞれのその後のメッセージを送ります。 一連番号はその結果、自由な走行カウンタが法65536を表したということです。 値が最後の容認された数と前の32767の値の範囲にあるなら、受信されたメッセージのヘッダーの一連番号は最後の容認されたより数であると考えられます、包括的です。 例えば0〜15、および32784〜65535の一連番号がある当時のメッセージは最後の容認された一連番号が15であったなら以下か等しいと考えられるでしょう。 そのようなメッセージは既に受け取られて、処理から無視されたメッセージの写しであると考えられるでしょう。 しかしながら、すべてのメッセージが適切(特に無くなっているZLB ACKメッセージの場合で)に承認されるのを確実にするために、信頼できる輸送で写しメッセージの領収書を受け取ったことを知らせなければなりません。 ZLB ACKを通してメッセージで待ち行列、または明らかに背負われて、この承認はそうするかもしれません。
All control messages take up one slot in the control message sequence number space, except the ZLB acknowledgement. Thus, Ns is not incremented after a ZLB message is sent.
ZLB承認を除いて、すべてのコントロールメッセージがコントロールメッセージ通番スペースの1つのスロットを取ります。 したがって、ZLBメッセージを送った後にNsは増加していません。
The last received message number, Nr, is used to acknowledge messages received by an L2TP peer. It contains the sequence number of the message the peer expects to receive next (e.g. the last Ns of a non- ZLB message received plus 1, modulo 65536). While the Nr in a received ZLB is used to flush messages from the local retransmit queue (see below), Nr of the next message sent is not be updated by the Ns of the ZLB.
最後の容認されたメッセージ番号(Nr)は、L2TP同輩によって受け取られたメッセージを承認するのに使用されます。 それは同輩が次に受け取ると予想するメッセージの一連番号を含んでいます(例えば、非ZLBのメッセージの最後のNsはそのうえ、1を受け取りました、法65536)。 容認されたZLBのNrが使用されている間、地方の再送キュー(以下を見る)、次のNrからの送られたメッセージがあるというメッセージを洗い流すには、ZLBのNsによってアップデートされないでください。
The reliable transport at a receiving peer is responsible for making sure that control messages are delivered in order and without duplication to the upper level. Messages arriving out of order may be queued for in-order delivery when the missing messages are received, or they may be discarded requiring a retransmission by the peer.
受信同輩の信頼できる輸送はコントロールメッセージが整然とした状態で送られるのを確実にして、複製なしで上側のレベルに原因となります。 なくなったメッセージが受信されているとき、故障していた状態で到着するメッセージがオーダーにおける配送のために列に並ばせられるかもしれませんか、またはそれらは、同輩で「再-トランスミッション」を必要としながら、捨てられるかもしれません。
Townsley, et al. Standards Track [Page 46] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[46ページ]。
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.
メッセージのそれぞれのその後の「再-トランスミッション」は指数のbackoff間隔を使わなければなりません。 したがって、最初の「再-トランスミッション」が1秒後に現れるなら、次に、2秒が4秒経過したなど後に次の「再-トランスミッション」は現れるでしょうに。 実現は「再-トランスミッション」の最大の間隔に上限を設けるかもしれません。 このキャップは1「再-トランスミッション」あたり8秒未満ノーであるに違いありません。 同輩応答が全く数個の「再-トランスミッション」の後に検出されないなら(しかし、お勧めのデフォルトが5、SHOULDである、構成可能であってください、)、中でトンネルとすべてのセッションをきれいにしなければなりません。
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を考えてください。そうすれば、Nの値がSCCRQかSCCRPメッセージにある状態で、B.Suppose AはReceive Window Size AVPを指定します。 Bは現在、最大N傑出しているコントロールメッセージを持つことができます。 いったんNを送ると、それは新しいコントロールメッセージを送る前に窓を進める承認を待たなければなりません。 実現はaを支持するかもしれません。同輩から最大4の窓を受け入れなければならないのを除いて、1(すなわち、1の値があるReceive Window Size AVPを出すのによる)だけの窓を受けてください(例えば、引き返す前に4つのメッセージを送る能力を持ってください)。 Receive Window Size 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.
再送するときには、利用されていて、メッセージ、遅れた出発、および輻輳回避窓の調整手順SHOULDを制御してください。 これのためのお勧めの手順はAppendix 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はコントロールのメッセージ送信、承認、および「再-トランスミッション」に関する例を含んでいます。
Townsley, et al. Standards Track [Page 47] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[47ページ]。
6.0 Control Connection Protocol Specification
6.0 コントロール接続プロトコル仕様
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つの値としてどんな「予約された」か「空」の野原も送らなければなりません。
6.1 Start-Control-Connection-Request (SCCRQ)
6.1 スタートコントロール接続要求(SCCRQ)
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:
以下のAVPsはSCCRQに存在していなければなりません:
Message Type AVP
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
Tunnel IDが割り当てられたメッセージタイプAVPプロトコルバージョンホスト名縁どり能力
The Following AVPs MAY be present in the SCCRQ:
Following AVPsはSCCRQに存在しているかもしれません:
Bearer Capabilities
Receive Window Size
Challenge
Tie Breaker
Firmware Revision
Vendor Name
運搬人能力レシーブ・ウィンドウ・サイズ挑戦タイブレークファームウェア改正業者名
6.2 Start-Control-Connection-Reply (SCCRP)
6.2 スタートコントロール接続回答(SCCRP)
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:
以下のAVPsはSCCRPに存在していなければなりません:
Message Type
Protocol Version
Framing Capabilities
Host Name
Assigned Tunnel ID
Tunnel IDが割り当てられたメッセージタイププロトコルバージョン縁どり能力ホスト名
Townsley, et al. Standards Track [Page 48] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[48ページ]。
The following AVPs MAY be present in the SCCRP:
以下のAVPsはSCCRPに存在しているかもしれません:
Bearer Capabilities
Firmware Revision
Vendor Name
Receive Window Size
Challenge
Challenge Response
運搬人能力ファームウェア改正業者名前レシーブ・ウィンドウ・サイズ挑戦チャレンジレスポンス
6.3 Start-Control-Connection-Connected (SCCCN)
6.3 スタートコントロール接続は接続しました。(SCCCN)
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 MUST、SCCCNに存在してください:
Message Type
メッセージタイプ
The following AVP MAY be present in the SCCCN:
以下のAVP MAY、SCCCNに存在してください:
Challenge Response
チャレンジレスポンス
6.4 Stop-Control-Connection-Notification (StopCCN)
6.4 停止コントロール接続通知(StopCCN)
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のどちらかによって送られたコントロールメッセージです。 さらに、すべての活発なセッションがそれとなくクリアされます(どんな明白な呼び出しコントロールメッセージも送らないで)。 この要求を出す理由はResult Code AVPで示されます。 メッセージ(信頼できるコントロールメッセージトランスポート層に受け取られる内在しているACKだけ)に関するどんな明白な回答もありません。
The following AVPs MUST be present in the StopCCN:
以下のAVPsはStopCCNに存在していなければなりません:
Message Type
Assigned Tunnel ID
Result Code
トンネルID結果コードが割り当てられたメッセージタイプ
6.5 Hello (HELLO)
6.5 こんにちは(こんにちは)
The Hello (HELLO) message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a "keepalive" for the tunnel.
Hello(HELLO)メッセージはLAC-LNSコントロール接続のどちらの同輩によっても送られたL2TPコントロールメッセージです。 このコントロールメッセージはトンネルに"keepalive"として使用されます。
Townsley, et al. Standards Track [Page 49] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[49ページ]。
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がコントロールメッセージであり、下のレベル輸送でコントロールメッセージを確かに送るので、輸送レベルが確かに伝言をもたらすことを引き起こすことによって、このkeepalive機能は作動します。 メディア中断が発生したなら、信頼できる輸送は、横切ってHELLOを届けることができないで、トンネルを掃除するでしょう。
Keepalives for the tunnel MAY be implemented by sending a HELLO if a period of time (a recommended default is 60 seconds, but SHOULD be configurable) has passed without receiving any message (data or control) from the peer.
トンネルへのKeepalivesは、期間であるならHELLOを送ることによって、実行されるかもしれません。(お勧めのデフォルトが60秒である、SHOULD、構成可能であってください、)、同輩からどんなメッセージ(データかコントロール)も受け取らないで、通りました。
HELLO messages are global to the tunnel. The Session ID in a HELLO message MUST be 0.
HELLOメッセージはトンネルにグローバルです。 HELLOメッセージのSession IDは0であるに違いありません。
The Following AVP MUST be present in the HELLO message:
Following AVPはHELLOメッセージに存在していなければなりません:
Message Type
メッセージタイプ
6.6 Incoming-Call-Request (ICRQ)
6.6 入って来る発呼要求(ICRQ)
Incoming-Call-Request (ICRQ) is a control message sent by the LAC to the LNS when an incoming call is detected. It is the first in a three message exchange used for establishing a session within an L2TP tunnel.
入って来る呼び出し要求(ICRQ)はかかってきた電話が検出されるときLACによってLNSに送られたコントロールメッセージです。 それはL2TPトンネルの中でセッションを確立するのに使用される3交換処理で1番目です。
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に提供します。 セッションが確立されるべきであるのを示すLNSからICRPを受けるまで、LACは電話口に出ることを延期するかもしれません。 このメカニズムで、LNSはそれが答えられるべきであるかどうか決定する前に、呼び出しに関する十分な情報を得ることができます。 あるいはまた、LACは電話口に出て、LCPとPPP認証を交渉して、LNSを選ぶために獲得された情報を使用するかもしれません。 この場合、ICRPメッセージが受信されている時までに呼び出しは既に答えられました。 LACはこの場合単に「呼び出し指示」と「呼び出し答え」ステップをだまします。
Townsley, et al. Standards Track [Page 50] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[50ページ]。
The following AVPs MUST be present in the ICRQ:
以下のAVPsはICRQに存在していなければなりません:
Message Type
Assigned Session ID
Call Serial Number
Session IDが割り当てられたメッセージタイプは、通し番号と呼びます。
The following AVPs MAY be present in the ICRQ:
以下のAVPsはICRQに存在しているかもしれません:
Bearer Type
Physical Channel ID
Calling Number
Called Number
Sub-Address
数のサブアドレスと呼ばれる数と呼ぶ運搬人のタイプの物理的なチャンネルID
6.7 Incoming-Call-Reply (ICRP)
6.7 入って来る呼び出し回答(ICRP)
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)はLNSによって受信されたICRQメッセージに対応してLACに送られたコントロールメッセージです。 L2TPトンネルの中でセッションを確立するのに使用される3交換処理でそれは2番目です。
ICRP is used to indicate that the ICRQ was successful and for the LAC to answer the call if it has not already done so. It also allows the LNS to indicate necessary parameters for the L2TP session.
既にそうしていないなら、ICRQがうまくいったのを示して、LACが電話口に出るのにICRPは使用されます。 また、それで、LNSはL2TPセッションのための必要なパラメタを示すことができます。
The following AVPs MUST be present in the ICRP:
以下のAVPsはICRPに存在していなければなりません:
Message Type
Assigned Session ID
Session IDが割り当てられたメッセージタイプ
6.8 Incoming-Call-Connected (ICCN)
6.8 入って来る接続完了(ICCN)
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)はLACによって受信されたICRPメッセージに対応してLNSに送られたコントロールメッセージです。 それはL2TPトンネルの中でセッションを確立するのに使用される3交換処理で3番目のメッセージです。
ICCN is used to indicate that the ICRP was accepted, the call has been answered, and that the L2TP session should move to the established state. It also provides additional information to the LNS about parameters used for the answered call (parameters that may not always available at the time the ICRQ is issued).
ICCNは、ICRPを受け入れて、呼び出しに答えて、L2TPセッションが設立された状態に動くべきであるのを示すのに使用されます。 また、それは答えられた要求(ICRQが発行されるときいつも利用可能な状態でそうするかもしれないというわけではないパラメタ)に使用されるパラメタに関して追加情報をLNSに供給します。
The following AVPs MUST be present in the ICCN:
以下のAVPsはICCNに存在していなければなりません:
Message Type
(Tx) Connect Speed
Framing Type
メッセージタイプ(Tx)は速度縁どりタイプに接します。
Townsley, et al. Standards Track [Page 51] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[51ページ]。
The following AVPs MAY be present in the ICCN:
以下のAVPsはICCNに存在しているかもしれません:
Initial Received LCP CONFREQ
Last Sent LCP CONFREQ
Last Received LCP CONFREQ
Proxy Authen Type
Proxy Authen Name
Proxy Authen Challenge
Proxy Authen ID
Proxy Authen Response
Private Group ID
Rx Connect Speed
Sequencing Required
初期の容認されたLCP CONFREQは最後に最後の容認されたLCP CONFREQプロキシのAuthenの応答の個人的なグループID AuthenタイププロキシAuthen NameプロキシAuthen挑戦プロキシAuthen IDプロキシRxが接続するLCP CONFREQに配列が必要とした速度を送りました。
6.9 Outgoing-Call-Request (OCRQ)
6.9 送信する発呼要求(OCRQ)
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からの外国行きの呼び出しが設立されることであることを示すためにLNSによってLACに送られたコントロールメッセージです。 それはL2TPトンネルの中でセッションを確立するのに使用される3交換処理で1番目です。
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 MUSTは、そのLACに発信電話を要求するためにトンネル設立の間、LACからBearer Capabilities AVPを受けています。
The following AVPs MUST be present in the OCRQ:
以下のAVPsはOCRQに存在していなければなりません:
Message Type
Assigned Session ID
Call Serial Number
Minimum BPS
Maximum BPS
Bearer Type
Framing Type
Called Number
Session IDが割り当てられたメッセージタイプは、数と呼ばれる最大のビーピーエス運搬人タイプ縁どりタイプに通し番号の最小のビーピーエスに電話をします。
The following AVPs MAY be present in the OCRQ:
以下のAVPsはOCRQに存在しているかもしれません:
Sub-Address
サブアドレス
Townsley, et al. Standards Track [Page 52] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[52ページ]。
6.10 Outgoing-Call-Reply (OCRP)
6.10 外向的な呼び出し回答(OCRP)
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)はLACによって受信されたOCRQメッセージに対応してLNSに送られたコントロールメッセージです。 L2TPトンネルの中でセッションを確立するのに使用される3交換処理でそれは2番目です。
OCRP is used to indicate that the LAC is able to attempt the outbound call and returns certain parameters regarding the call attempt.
OCRPはLACが外国行きの呼び出しを試みることができるのを示すのに使用されて、呼び出し試みに関する、あるパラメタを返します。
The following AVPs MUST be present in the OCRP:
以下のAVPsはOCRPに存在していなければなりません:
Message Type
Assigned Session ID
Session IDが割り当てられたメッセージタイプ
The following AVPs MAY be present in the OCRP:
以下のAVPsはOCRPに存在しているかもしれません:
Physical Channel ID
物理的なチャンネルID
6.11 Outgoing-Call-Connected (OCCN)
6.11 外向的な接続完了(OCCN)
Outgoing-Call-Connected (OCCN) is a control message sent by the LAC to the LNS following the OCRP and after the outgoing call has been completed. It is the final message in a three message exchange used for establishing a session within an L2TP tunnel.
接続された外向的な要求(OCCN)は、OCRPに続いて、LACによってLNSに送られたコントロールメッセージであり、発信電話の後に終了しました。 L2TPトンネルの中でセッションを確立するのに使用される3交換処理でそれは最終的なメッセージです。
OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LNS about the particular parameters obtained after the call was established.
OCCNは、要求された発信電話の結果がうまくいったのを示すのに使用されます。 また、それは呼び出しが確立された後に得られた特定のパラメタに関して情報をLNSに供給します。
The following AVPs MUST be present in the OCCN:
以下のAVPsはOCCNに存在していなければなりません:
Message Type
(Tx) Connect Speed
Framing Type
メッセージタイプ(Tx)は速度縁どりタイプに接します。
The following AVPs MAY be present in the OCCN:
以下のAVPsはOCCNに存在しているかもしれません:
Rx Connect Speed
Sequencing Required
Rxは配列が必要とした速度を接続します。
6.12 Call-Disconnect-Notify (CDN)
6.12 呼び出し分離に通知します。(CDN)
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
Call分離に通知している(CDN)メッセージはトンネルの中で特定の呼び出しの断線を要求するためにLACかLNSのどちらかによって送られたL2TPコントロールメッセージです。 目的は同輩に知らせることになっています。
Townsley, et al. Standards Track [Page 53] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[53ページ]。
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.
断線が起こった断線と理由。 同輩は、どんなリソースもきれいにしなければならなくて、そのようなクリーンアップのために成否のどんなしるしも返送しません。
The following AVPs MUST be present in the CDN:
以下のAVPsはCDNに存在していなければなりません:
Message Type
Result Code
Assigned Session ID
Session IDが割り当てられたメッセージタイプ結果コード
The following AVPs MAY be present in the CDN:
以下のAVPsはCDNに存在しているかもしれません:
Q.931 Cause Code
Q.931原因コード
6.13 WAN-Error-Notify (WEN)
6.13 青白い誤りに通知します。(こぶ)
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誤りに通知しているメッセージはWANエラー条件(PPPを支持しながらインタフェースに現れる状態)を示すためにLACによってLNSに送られたL2TPコントロールメッセージです。 このメッセージのカウンタは累積しています。 それほどこのメッセージに60秒に一度送るだけでないべきです。 新しい呼び出しが確立されるとき、カウンタはリセットされます。
The following AVPs MUST be present in the WEN:
以下のAVPsはWENに存在していなければなりません:
Message Type
Call Errors
メッセージタイプは、誤りと呼びます。
6.14 Set-Link-Info (SLI)
6.14 セットリンクインフォメーション(SLI)
The Set-Link-Info message is an L2TP control message sent by the LNS to the LAC to set PPP-negotiated options. These options can change at any time during the life of the call, thus the LAC MUST be able to update its internal call information and behavior on an active PPP session.
SetリンクインフォメーションメッセージはPPPによって交渉されたオプションを設定するためにLNSによってLACに送られたL2TPコントロールメッセージです。 いつでも、その結果、呼び出しの人生、LAC MUSTの間、これらのオプションを変えることができます。活発なPPPセッションのときにその内部の呼び出し情報と振舞いをアップデートできてください。
The following AVPs MUST be present in the SLI:
以下のAVPsはSLIに存在していなければなりません:
Message Type
ACCM
メッセージタイプACCM
7.0 Control Connection State Machines
7.0 制御接続州のマシン
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
このセクションで定義されたステートテーブルを通してセクション6で定義されたコントロールメッセージを交換します。 テーブルはかかってきた電話プレースメント、発信電話プレースメントと開始のために定義されます。
Townsley, et al. Standards Track [Page 54] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[54ページ]。
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.
トンネル自体。 ステートテーブルはタイムアウトと「再-トランスミッション」の振舞いをコード化しません、これがセクション5.8で定義された基本的な意味論で扱われるとき。
7.1 Control Connection Protocol Operation
7.1 コントロール接続プロトコル操作
This section describes the operation of various L2TP control connection functions and the Control Connection messages which are used to support them.
このセクションは様々なL2TPコントロール接続機能とそれらを支持するのに使用されるControl Connectionメッセージの操作について説明します。
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を見ます)マークされた、実現において、未知であることのMessage Type、または不適当な系列で受け取られるコントロールメッセージを含むメッセージと定義されます(例えば、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があるコントロールメッセージは、それのためにMで噛み付いているAVPが、誤りが回復可能であるかどうか決定するのを当てにするべきです。
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として扱われるべきです。 したがって、M-ビットセットで奇形のAVPを受け取るなら、適切なResultかError Codeを送ってセッションかトンネルを終えるべきです。 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).
奇形のAVPsを送るライセンスであるとこれを考えてはいけませんが、単にどう不適切にフォーマットされたメッセージを扱うかに向かったガイドは1であるなら受け取られています。 与えられたメッセージのすべての潜在的不具を記載して、それぞれのためにアドバイスするのは不可能です。 それは言って、回復可能で、奇形のAVPに関する1つの例は4よりむしろ2つの八重奏で10よりむしろ8とBPSの長さを与えていてRx Connect Speed AVP(属性38)を受け取るかどうかということであるかもしれません。 Rx Connect Speedが非義務的であるので、壊滅的であるとこの状態を考えるべきではありません。 そういうものとして、まるでAVPが受け取られていないかのように(登録されるローカルのエラーメッセージを除いて)コントロールメッセージを受け入れるべきです。
Townsley, et al. Standards Track [Page 55] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[55ページ]。
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は堅苦しいトンネル設立に関する例を含んでいます。
7.2 Control Connection States
7.2 コントロール接続州
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でTie Breaker AVPを見てください。
7.2.1 Control Connection Establishment
7.2.1 コントロールコネクション確立
State Event Action New State
----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply
Open request
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- 無駄なLocal Send SCCRQ待ちctl回答オープン要求
idle Receive SCCRQ, Send SCCRP wait-ctl-conn
acceptable
使用されていないReceive SCCRQ、許容できるSend SCCRP待ちctlコン
idle Receive SCCRQ, Send StopCCN, idle
not acceptable Clean up
使用されていないReceive SCCRQ(Send StopCCN)は上にどんな許容できるCleanも空費しません。
idle Receive SCCRP Send StopCCN idle
Clean up
使用されていないReceive SCCRP Send StopCCN使用されていないCleanは上昇します。
idle Receive SCCCN Clean up idle
使用されていないReceive SCCCN Cleanは活動していない状態で上昇します。
wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable Send tunnel-open
event to waiting
sessions
待ちctl回答Receive SCCRP(Send SCCCN)は待ちセッションへの許容できるSendトンネル開いている出来事を設立しました。
wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable Clean up
Receive SCCRP(Send StopCCN)がどんな許容できるCleanも空費しない待ちctl回答
wait-ctl-reply Receive SCCRQ, Clean up, idle
lose tie-breaker Re-queue SCCRQ
for idle state
Cleanが上にあるReceive SCCRQが空費する待ちctl回答は活動していない状態へのタイブレークRe-待ち行列SCCRQをなくします。
Townsley, et al. Standards Track [Page 56] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[56ページ]。
wait-ctl-reply Receive SCCCN Send StopCCN idle
Clean up
Receive SCCCN Send StopCCNがCleanを空費する待ちctl回答
wait-ctl-conn Receive SCCCN, Send tunnel-open established
acceptable event to waiting
sessions
待ちctlコンReceive SCCCN、待ちセッションへのSendのトンネル開いている確立した許容できる出来事
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable Clean up
待ちctlコンReceive SCCCN(Send StopCCN)は上にどんな許容できるCleanも空費しません。
wait-ctl-conn Receive SCCRP, Send StopCCN, idle
SCCRQ Clean up
待ちctlコンReceive SCCRP(Send StopCCN)は上にSCCRQ Cleanを空費します。
established Local Send tunnel-open established
Open request event to waiting
(new call) sessions
待ち(新しい呼び出し)セッションへの確立したLocal Sendトンネル開いている確立したオープン要求イベント
established Admin Send StopCCN idle
Tunnel Close Clean up
確立したAdmin Send StopCCN使用されていないTunnel Close Cleanは上昇します。
established Receive SCCRQ, Send StopCCN idle
SCCRP, SCCCN Clean up
確立したReceive SCCRQ、Send StopCCNの使用されていないSCCRP、SCCCN Cleanは上昇します。
idle Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established
無駄な待ちctl回答、設立された待ちctlコンへの使用されていないReceive StopCCN Clean
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.
この状態からBoth創始者と受取人始めを遊ばせてください。 創始者は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
SCCRPが受け取られているとき、それはコンパチブルバージョンがないかどうか調べられます。 回答のバージョンがバージョンが要求を送ったより低いなら、それが支持されるなら、より古い(下側の)バージョンは使用されるべきです。 バージョンが回答で、より初期で支持されているなら、創始者は設立された状態に移ります。 if
Townsley, et al. Standards Track [Page 57] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[57ページ]。
the version is earlier and not supported, a StopCCN MUST be sent
to the peer and the originator cleans up and terminates the
tunnel.
バージョンが、より初期で支持されていなくて、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コンThisは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.
確立したAn確立した接続はStop-コントロール接続通知の現地の状況か領収書のどちらかで終えられるかもしれません。 地方の終了の場合、創始者は、Stopコントロール接続通知を送って、トンネルを掃除しなければなりません。
If the originator receives a Stop-Control-Connection-Notification
it MUST also clean up the tunnel.
また、創始者がStopコントロール接続通知を受け取るなら、それはトンネルを掃除しなければなりません。
7.3 Timing considerations
7.3 タイミング問題
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に記述されます。
7.4 Incoming calls
7.4 入って来る呼び出し
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によって、かかってきた電話が検出されるとき(例えば、関連電話回線は鳴ります)、Incoming呼び出し要求メッセージは発生します。 LACはSession IDと通し番号を選択して、呼び出し運搬人タイプを示します。 モデムはいつもアナログの呼び出しタイプを示すはずです。 ISDN呼び出しは、デジタル・モデムがかかわるなら、デジタルか無制限なデジタルサービスであるならレート適応が中古であって、アナログであることを示すべきです。 彼らが電話網から利用可能であるなら、Number、Called Number、およびSubaddressと呼ぶのがメッセージに含まれるかもしれません。
Once the LAC sends the Incoming-Call-Request, it waits for a response from the LNS but it does not necessarily answer the call from the telephone network yet. The LNS may choose not to accept the call if:
LACがいったんIncoming呼び出し要求を送ると、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
- どんなリソースもより多くのセッションを扱うために利用可能ではありません--ダイヤルすること、ダイヤルすること、または「副-アドレス」分野が認定ユーザに文通されません--運搬人サービスは、認可もされませんし、支持もされません。
Townsley, et al. Standards Track [Page 58] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[58ページ]。
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が、呼び出しを受け入れるのを選ぶなら、それはIncoming呼び出し回答で応じます。 LACがIncoming呼び出し回答を受け取るとき、それは、呼び出しを接続するのを試みます。 LACからLNSまでの最終的な接続完了メッセージは、LACとLNSの両方のための呼び出し状態が設立された状態に入るべきであるのを示します。 LNSがそれを受け入れることができる前に呼び出しが終わったなら、分離が通知するCallは、この状態を示すために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はCall分離に通知しているメッセージを送ります。 LNSが呼び出しをクリアしたいなら、それは、Call分離に通知しているメッセージを送って、セッションをきれいにします。
Townsley, et al. Standards Track [Page 59] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[59ページ]。
7.4.1 LAC Incoming Call States
7.4.1 ラックかかってきた電話州
State Event Action New State
----- ----- ------ ---------
idle Bearer Ring or Initiate local wait-tunnel
Ready to indicate tunnel open
incoming conn.
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- Bearer RingかInitiateの地方の待ちトンネルReadyを空費して、オープンな入って来るコンにトンネルを堀るように示してください。
idle Receive ICCN, Clean up idle
ICRP, CDN
使用されていないReceive ICCN、使用されていないICRP、CDNへのClean
wait-tunnel Bearer line drop Clean up idle
or local close
request
活動していないかローカルの厳密な要求への待ちトンネルBearer線低下Clean
wait-tunnel tunnel-open Send ICRQ wait-reply
待ちトンネル開いているトンネルSend ICRQ待ち回答
wait-reply Receive ICRP, Send ICCN established
acceptable
待ち回答Receive ICRP、設立されたSend ICCN、許容できる。
wait-reply Receive ICRP, Send CDN, idle
Not acceptable Clean up
Receive ICRP(Send CDN)がNotの許容できるCleanを空費する待ち回答
wait-reply Receive ICRQ Send CDN idle
Clean up
Receive ICRQ Send CDNがCleanを空費する待ち回答
wait-reply Receive CDN Clean up idle
ICCN
使用されていないICCNへの待ち回答Receive CDN Clean
wait-reply Local Send CDN, idle
close request or Clean up
Bearer line drop
Bearer線への待ち回答Local Send CDN、無駄な厳密な要求またはCleanが低下します。
established Receive CDN Clean up idle
確立したReceive CDN Cleanは活動していない状態で上昇します。
established Receive ICRQ, Send CDN, idle
ICRP, ICCN Clean up
確立したReceive ICRQ(Send CDN)は上にICRP、ICCN Cleanを空費します。
established Bearer line Send CDN, idle
drop or local Clean up
close request
使用されていない低下か近くで上がっている地方のCleanが、確立したBearerがSend CDNを裏打ちするよう要求します。
Townsley, et al. Standards Track [Page 60] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[60ページ]。
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を空費してください。インタフェースの1つにかかってきた電話を検出します。 通常、これが、アナログの線が鳴っていることを意味するか、または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.
開かれるか、検証のためにあるトンネルが既にそうであるコントロール接続が開くので、これが、セッションが待っていると述べるInに待つトンネルを堀ってください。 いったん、トンネルには/があるという指示を開くと、セッション制御メッセージを交換するかもしれません。 これらの1番目はIncoming呼び出し要求です。
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.
LNSを示すLACが受け取る待ち回答a CDNメッセージが、呼び出しを受け入れることを望んでいない、(一般的なエラー、受け入れないでください、)、そして、活動していない状態、または呼び出しが受け入れられるのを示して、LACがIncoming-呼び出しで接続されたメッセージを送って、設立された状態に入力するというIncoming呼び出し応答メッセージへの移動。
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.
確立したDataをトンネルの上と交換します。 呼び出しは続くのがクリアされるかもしれません: + 接続インタフェースにおける出来事: LACはCall分離に通知しているメッセージの分離して通知しているメッセージ+領収書をCallに送ります: 呼び出しを外して、LACは掃除します。 + ローカルの理由: LACはCall分離に通知しているメッセージを送ります。
Townsley, et al. Standards Track [Page 61] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[61ページ]。
7.4.2 LNS Incoming Call States
7.4.2 LNSかかってきた電話州
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- Receive ICRQを空費してください、Send ICRPが待つ接続する、許容できる。
idle Receive ICRQ, Send CDN, idle
not acceptable Clean up
使用されていないReceive ICRQ(Send CDN)は上にどんな許容できるCleanも空費しません。
idle Receive ICRP Send CDN idle
Clean up
使用されていないReceive ICRP Send CDN使用されていないCleanは上昇します。
idle Receive ICCN Clean up idle
使用されていないReceive ICCN Cleanは活動していない状態で上昇します。
wait-connect Receive ICCN Prepare for established
acceptable data
確立した許容できるデータのためのReceive ICCN Prepareを待つ接続してください。
wait-connect Receive ICCN Send CDN, idle
not acceptable Clean up
Receive ICCN Send CDNを待つ接続してください、そして、上にどんな許容できるCleanも空費しないでください。
wait-connect Receive ICRQ, Send CDN idle
ICRP Clean up
Receive ICRQを待つ接続してください、そして、Send CDNの使用されていないICRP Cleanは上昇します。
idle, Receive CDN Clean up idle wait-connect, established
Receive CDN Clean、怠けてください。上が待つ接続していた状態で怠ける、確立
wait-connect Local Send CDN, idle established Close request Clean up
Local Send CDNを待つ接続してください、そして、使用されていない確立したCloseは上にCleanを要求します。
established Receive ICRQ, Send CDN idle
ICRP, ICCN Clean up
確立したReceive ICRQ、Send CDNの使用されていないICRP、ICCN Cleanは上昇します。
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.
無駄なAn Incoming呼び出し要求メッセージは受信されています。 要求が許容できないなら、LACは分離が通知するCallに送り返されます、そして、LNSは活動していない州に残っています。 Incoming-呼び出し要求メッセージが許容できるなら、Incoming呼び出し回答を送ります。 セッションは待つ接続している状態に動きます。
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
Ifを待つ接続してください。セッションはまだLACに接続されていて、LACはその時設立された状態に動くLNSにIncoming呼び出しが接続しているメッセージを送ります。 LACは、電話をかけてきた人に接できなかったのを示すために、分離が通知するCallを送るかもしれません。 これ
Townsley, et al. Standards Track [Page 62] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[62ページ]。
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に標準の音声通話を置くなら、起こるかもしれません。
established
The session is terminated either by receipt of a Call-Disconnect-
Notify message from the LAC or by sending a Call-Disconnect-
Notify. Clean up follows on both sides regardless of the
initiator.
設立されて、セッションはCall-分離の領収書で終えられます。-LACからメッセージに通知するか、またはCall-分離を送って、-通知してください。 創始者にかかわらず両側で尾行をきれいにしてください。
7.5 Outgoing calls
7.5 外向的な呼び出し
Outgoing calls are initiated by an LNS and instruct an LAC to place a call. There are three messages for outgoing calls: Outgoing-Call- Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS sends an Outgoing-Call-Request specifying the dialed party phone number, subaddress and other parameters. The LAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the LAC determines that the proper facilities exist to place the call and the call is administratively authorized. For example, is this LNS allowed to dial an international call? Once the outbound call is connected, the LAC sends an Outgoing-Call-Connected message to the LNS indicating the final result of the call attempt:
発信電話は、LNSによって開始されて、電話をするようLACに命令します。 発信電話への3つのメッセージがあります: 送信する呼び出し要求と、外向的な呼び出し回答と、送信する接続完了です。 LNSはOutgoing呼び出し要求にダイヤルされたパーティー電話番号、「副-アドレス」、および他のパラメタを指定させます。 LACが、適切な施設が電話をするために存在していて、呼び出しが行政上認可されることをいったん決定すると、LAC MUSTはOutgoing呼び出し応答メッセージでOutgoing呼び出し要求メッセージに応じます。 例えば、このLNSは国際電話にダイヤルすることができますか? 外国行きの呼び出しがいったん接続されるようになると、LACは呼び出し試みの最終的な結果を示すLNSにOutgoing呼び出しが接続しているメッセージを送ります:
Townsley, et al. Standards Track [Page 63] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[63ページ]。
7.5.1 LAC Outgoing Call States
7.5.1 ラック発信電話州
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Open bearer
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- 使用されていないReceive OCRQ、Send OCRP、待ちCs答えの許容できるオープン運搬人
idle Receive OCRQ, Send CDN, idle
not acceptable Clean up
使用されていないReceive OCRQ(Send CDN)は上にどんな許容できるCleanも空費しません。
idle Receive OCRP Send CDN idle
Clean up
使用されていないReceive OCRP Send CDN使用されていないCleanは上昇します。
idle Receive OCCN, Clean up idle
CDN
使用されていないReceive OCCN、使用されていないCDNへのClean
wait-cs-answer Bearer answer, Send OCCN established
framing detected
待ちCs答えBearerは答えて、Send OCCNは検出された縁どりを確立しました。
wait-cs-answer Bearer failure Send CDN, idle
Clean up
待ちCs答えBearerの故障Send CDN、使用されていないCleanは上昇します。
wait-cs-answer Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
待ちCs答えReceive OCRQ、Send CDNの使用されていないOCRP、OCCN Cleanは上昇します。
established Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
確立したReceive OCRQ、Send CDNの使用されていないOCRP、OCCN Cleanは上昇します。
wait-cs-answer, Receive CDN Clean up idle established
Cs答えを待ちなさいといって、Receive CDN Cleanが活動していない状態で上昇する、確立
established Bearer line drop, Send CDN, idle
Local close Clean up
request
確立したBearer線低下、Send CDNはLocalの近いCleanを要求に空費します。
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.
無駄なIf Outgoing呼び出し要求を間違って受け取って、分離が通知するCallと共に応じてください。 さもなければ、物理的なチャンネルを割り当ててください、そして、Outgoing呼び出し回答を送ってください。 外国行きの電話をしてください、そして、待ち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
待ちCs答えIf、呼び出しが終了していないか、タイマは終了する電話を待ちながら、期限が切れて、Call分離に適切なエラー条件で通知しているセットを送ってください、そして、または状態を空費しに行ってください。 サーキットです。
Townsley, et al. Standards Track [Page 64] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[64ページ]。
switched connection is established and framing is detected, send
an Outgoing-Call-Connected indicating success and go to
established state.
切り換えられた接続は確立されます、そして、縁どりは検出されます、そして、接続されたOutgoing呼び出しに成功を示させてください、そして、設立された状態に行ってください。
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.
分離が通知する確立したIf a CallはLACによって受け取られます、そして、適切な手段で通信業者呼び出しをリリースしなければなりませんでした、そして、セッションは掃除しました。 クライアントか呼ばれたインタフェースで呼び出しを外すなら、Call分離に通知しているメッセージをLNSに送らなければなりません。 メッセージを発信させた後の活動していない状態へのCall分離に通知しているメッセージリターンの送付者は完全です。
Townsley, et al. Standards Track [Page 65] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[65ページ]。
7.5.2 LNS Outgoing Call States
7.5.2 LNS発信電話州
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- 活動していないLocal Initiateの地方の待ちトンネル開いている要求トンネル戸外
idle Receive OCCN, Clean up idle
OCRP, CDN
使用されていないReceive OCCN、使用されていないOCRP、CDNへのClean
wait-tunnel tunnel-open Send OCRQ wait-reply
待ちトンネル開いているトンネルSend OCRQ待ち回答
wait-reply Receive OCRP, none wait-connect
acceptable
Receive OCRP、待つ接続していない回答を待っているなにも許容できます。
wait-reply Receive OCRP, Send CDN idle
not acceptable Clean up
待ち回答Receive OCRP、Send CDNは上にどんな許容できるCleanも空費しません。
wait-reply Receive OCCN, Send CDN idle
OCRQ Clean up
待ち回答Receive OCCN、使用されていないOCRQ Cleanが上げるSend CDN
wait-connect Receive OCCN none established
Receive OCCNを待つ接続してください、なにも設立しませんでした。
wait-connect Receive OCRQ, Send CDN idle
OCRP Clean up
Receive OCRQを待つ接続してください、そして、Send CDNの使用されていないOCRP Cleanは上昇します。
idle, Receive CDN, Clean up idle wait-reply, wait-connect, established
怠けてください、そして、設立されて、Receive CDN(無駄な待ち回答へのClean)は待つ接続します。
established Receive OCRQ, Send CDN idle
OCRP, OCCN Clean up
確立したReceive OCRQ、Send CDNの使用されていないOCRP、OCCN Cleanは上昇します。
wait-reply, Local Send CDN idle wait-connect, Close request Clean up established
Closeは、待つ返答してください、Local Send CDNが待つ接続していた状態で怠けるよう確立していた状態でCleanを要求します。
wait-tunnel Local Clean up idle
Close request
無駄なClose要求への待ちトンネルLocal Clean
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.
怠けてください、トンネルを待っているWhen。発信電話は開始されます、そして、トンネルは最初に活動していなさとしてたくさん作成されます、そして、LAC入来のための待ちトンネル州は電話をします。 いったんトンネルを確立すると、Outgoing呼び出し要求メッセージをLACに送ります、そして、セッションは待ち回答状態に動きます。
Townsley, et al. Standards Track [Page 66] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[66ページ]。
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.
分離が通知する待ち回答If a Callが受け取られていて、誤りが発生して、セッションは掃除されて、戻って、怠けます。 Outgoing呼び出し回答が受け取られているなら、呼び出しは進行しています、そして、セッションは待つ接続している状態に動きます。
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.
分離が通知する待つ接続しているIf a Callが受け取られている、呼び出しは失敗しました。 セッションは掃除されて、戻って、怠けます。 -接続されているのが、受け取られていて、呼び出しが成功したということであり、セッションが現在データを交換するかもしれないというOutgoing-要求であるなら。
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.
分離が通知する確立したIf a Callが受け取られている、呼び出しはResultとCause Codesで示された理由で終えられました。 セッションは活動していない状態に延ばされます。 LNSが、セッションを終えるのを選ぶなら、それは、セッションを分離が通知するCallをLACに送って、きれいにして、空費します。
7.6 Tunnel Disconnection
7.6 トンネル断線
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.
トンネルの断線はStopコントロール接続通知を発行するどちらの同輩からも成ります。 トンネルに関連している制御情報を発表する前に、このNotificationの送付者はこのメッセージの承認のための有限期間を待つべきです。 このNotificationの受取人は、Notificationの承認を送って、次に、関連制御情報を発表するべきです。
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.
いつトンネルをリリースするかは、導入問題であり、本書では指定されません。 特定の実現はどんないつコントロール接続を釈放するかを決定するのに、適切な方針も使用するかもしれません。 そのトンネルのための納会がクリアされた後にいくつかの実現が戸外をトンネルにしばらくか恐らく無期限に出るかもしれません。 他のものは、トンネル分離のときに最後のユーザ接続直後トンネルを外すのを選ぶかもしれません。
8.0 L2TP Over Specific Media
8.0 特定のメディアの上のL2TP
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は自己に説明していて、上のレベルにおける作動はそれが運ばれるメディアです。 しかしながら、メディアとの接続のいくつかの細部が、共同利用できる実現を可能にするのに必要です。 以下のセクションは特定のメディアの上で相互運用性を可能にするのに必要である詳細について説明します。
Townsley, et al. Standards Track [Page 67] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[67ページ]。
8.1 L2TP over UDP/IP
8.1 UDP/IPの上の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は1701[RFC1700]の登録されたUDPポートを使用します。 UDPデータグラムの中にペイロードとL2TPヘッダーを含む全体のL2TPパケットを送ります。 L2TPトンネルの創始者は、ポート(1701であるかもしれない)を利用可能なソースUDPに選んで、ポート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はこれを最適化するためのどんな特別な努力もしません。 LCPはLAC実現で、特定のMRUを交渉するかもしれません。(MRUはMTUのL2TPパケットが旅行しそうである経路のものが一貫した値を持っているLAC環境のために最適化できました)。
The default for any L2TP implementation is that UDP checksums MUST be enabled for both control and data messages. An L2TP implementation MAY provide an option to disable UDP checksums for data messages. It is recommended that UDP checksums always be enabled on control packets.
どんなL2TP実現のためのデフォルトもコントロールとデータメッセージの両方のためにUDPチェックサムを可能にしなければならないということです。 L2TP実現は、データメッセージのためにUDPチェックサムを無効にするためにオプションを提供するかもしれません。 UDPチェックサムがコントロールパケットでいつも可能にされるのは、お勧めです。
Port 1701 is used for both L2F [RFC2341] and L2TP packets. The Version field in each header may be used to discriminate between the two packet types (L2F uses a value of 1, and the L2TP version described in this document uses a value of 2). An L2TP implementation running on a system which does not support L2F MUST silently discard all L2F packets.
ポート1701はL2F[RFC2341]とL2TPパケットの両方に使用されます。 各ヘッダーのバージョン分野は、2つのパケットタイプを区別するのに使用されるかもしれません(L2Fが1の値を使用します、そして、本書では説明されたL2TPバージョンは2の値を使用します)。 静かにL2F MUSTを支持しないシステムで動くL2TP実現はすべてのL2Fパケットを捨てます。
To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has the characteristic of being able to reorder or silently drop packets. The former may break non-IP protocols being carried by PPP, especially LAN-centric ones such as bridging. The latter may break protocols which assume per-packet indication of error, such as TCP header compression. Sequencing may be handled by using L2TP data message sequence numbers if any protocol being transported by the PPP
L2TP過剰UDP/IPトンネルを使用しているPPPクライアントに、PPPリンクは静かに追加注文にできることの特性によってパケットを落とされます。 前者はPPPによって運ばれる非IPプロトコル、橋を架けなどなどの特にLAN中心のものを壊すかもしれません。 後者はTCPヘッダー圧縮などの誤りの1パケットあたりのしるしを仮定するプロトコルを破るかもしれません。 PPPによって輸送されながら、配列はもしあればメッセージ通番が議定書の中で述べるL2TPデータを使用することによって、扱われるかもしれません。
Townsley, et al. Standards Track [Page 68] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[68ページ]。
tunnel cannot tolerate reordering. The sequence dependency characteristics of individual protocols are outside the scope of this document.
トンネルは、再命令するのを許容できません。 このドキュメントの範囲の外に個々のプロトコルの系列依存の特性があります。
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クライアントが物理的に異なっているところでは、類似のシグナリングは、CRC誤りと共にPPPクライアントにパケットを送ることによって、達成されるかもしれません。 これがデバッグクライアント線問題の複雑さを大いに増加させることに注意してください、クライアント統計が本当のメディア誤りと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信頼できる配信も一連番号も可能にされないなら、それぞれが不正確なコンテンツ[RFC1144]と共に進められるTCPセグメントの2**16機会における1におけるパケット結果を失いました。 パケット損失の組み合わせがどこでこの統計的な露出をみなすかは、容認できないTCPヘッダー圧縮SHOULD NOTです。使用されます。
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メディアならも、すなわち、損失を条件として注意するべきです。 そのようなプロトコルは歴史を使う圧縮と暗号化プロトコルを含んでいます。
8.2 IP
8.2 IP
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 MUSTはIP操作のために8.1でデフォルト設定と説明されたUDPカプセル化を提供します。 構成可能なオプションとして他の構成(恐らく圧縮されたヘッダー形式に対応する)を定義して、利用可能にするかもしれません。
9.0 Security Considerations
9.0 セキュリティ問題
L2TP encounters several security issues in its operation. The general approach of L2TP to these issues is documented here.
L2TPは稼働中であるいくつかの安全保障問題に遭遇します。 これらの問題へのL2TPの一般的方法はここに記録されます。
Townsley, et al. Standards Track [Page 69] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[69ページ]。
9.1 Tunnel Endpoint Security
9.1 トンネル終点セキュリティ
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 MUSTはただ一つの秘密を共有します。 固有識別文字と同様にauthenticateeとして機能するとき、それぞれの側はこの同じ秘密を使用します。 ただ一つの秘密が使用されているので、トンネル認証AVPsは、それぞれのメッセージダイジェスト計算が反射攻撃に用心するように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.
Assigned Tunnel IDとAssigned Session ID、(セクション4.4.3)SHOULDが予測できない方法でむしろ選択されるのを見てください、連続するかそうでなく。 そうするのは、LACとLNSの間のパケット跡に近づく手段を持っていない悪意あるユーザーによるセッションのハイジャックを思いとどまらせるのを助けるでしょう。
9.2 Packet Level Security
9.2 パケット・レベルセキュリティ
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)。
9.3 End to End Security
9.3は、セキュリティを終わらせるために終わります。
Protecting the L2TP packet stream via a secure transport does, in turn, also protect the data within the tunneled PPP packets while transported from the LAC to the LNS. Such protection should not be considered a substitution for end-to-end security between communicating hosts or applications.
また、安全な輸送でL2TPパケットストリームを保護すると、データはLACからLNSまで輸送されている間、トンネルを堀られたPPPパケットの中に順番に保護されます。 ホストかアプリケーションを伝えることの間の終わりから終わりへのセキュリティへの代替であるとそのような保護を考えるべきではありません。
Townsley, et al. Standards Track [Page 70] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[70ページ]。
9.4 L2TP and IPsec
9.4 L2TPとIPsec
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は超能力、そして/または、AHを通してパケット・レベルセキュリティを提供します。 特定のトンネルへのすべてのL2TPコントロールとデータ・パケットは均質のUDP/IPデータ・パケットとしてIPsecシステムに現れます。
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実装が要求されるアクセス制御機能を定義します。 これらの特徴はネットワークに基づくパケットのフィルタリングとIPアドレスなどのトランスポート層の特性、ポートなどを許容します。 L2TPトンネリングモデルでは、類似のフィルタリングはL2TPの上でPPP層かネットワーク層で論理的に実行されます。 これらのネットワーク層アクセス制御機能は認証されたPPPユーザに基づくベンダー特有の承認機能を通したLNSにおいて、または、交信しているホストの間のIPsecの交通機関の終わりからエンドを使用するのによるネットワーク層自体において扱われるかもしれません。 アクセス管理機構のための要件は、L2TP仕様の一部でなく、このドキュメントの範囲の外にそういうものとしてあります。
9.5 Proxy PPP Authentication
9.5 プロキシppp認証
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は合法化のためにLACでLNSに得られたPPP認証情報の推進を提供するためにセッション設立の間に交換されるかもしれないAVPsを定義します(セクション4.4.5を見てください)。 これはLNSを代表してLACのダイレクト信頼関係を含意します。 LNSが、プロキシに認証を実装するのを選ぶなら、下に構成できなければなりません、LNS(LCP交渉の新しいラウンドを含むかもしれない)でPPP認証が開始した新しいラウンドを必要として。
10.0 IANA Considerations
10.0 IANA問題
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によって使用されるように、このセクションは評価基準について説明します。 以下の小区分はほかの場所で本書では定義された名前空間のために課題方針を説明します。
10.1 AVP Attributes
10.1 AVP属性
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
セクション4.1で定義されるように、AVPsはベンダーID、Attribute、およびValue分野を含んでいます。 0のベンダーID価値のために、IANAは登録を維持するでしょう。
Townsley, et al. Standards Track [Page 71] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[71ページ]。
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].
また、Attributesといくつかで割り当てられることでは、値をケースに入れてください。 属性0-39はセクション4.4で定義されるように割り当てられます。 IETF Consensus[RFC2434]のを通した課題について、残余価値があります。
10.2 Message Type AVP Values
10.2 メッセージタイプAVP値
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で定義されるように、Message Type AVPs(属性Type0)はIANAに関連値を維持させます。 値0-16はセクション3.2で定義されて、残余価値はIETF Consensusを通して課題に利用可能です。[RFC2434]
10.3 Result Code AVP Values
10.3 結果コードAVP値
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で定義されるように、Result Code AVPs(属性Type1)は3つの分野を含んでいます。 これらの2つの分野(Result CodeとError Code分野)で、IANAは関連値を維持します。
10.3.1 Result Code Field Values
10.3.1 結果コード分野値
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].
Result Code AVPはCDNとStopCCNメッセージに含まれるかもしれません。 Message Type AVPの値によって、AVPのResult Code分野への許容量は異なります。 StopCCNメッセージに関しては、値0-7はセクション4.4.2で定義されます。 StopCCNメッセージに関しては、値0-11は同じセクションで定義されます。 両方のメッセージのためのResult Code分野の残余価値はIETF Consensus[RFC2434]を通して課題に利用可能です。
10.3.2 Error Code Field Values
10.3.2 エラーコード分野値
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 Consensus[RFC2434]を通して課題に利用可能です。 Error Code分野の残余価値はFirst Come First Served[RFC2434]を通して課題に利用可能です。
10.4 Framing Capabilities & Bearer Capabilities
10.4 縁どり能力と運搬人能力
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].
Framing Capabilities AVPとBearer Capabilities AVPs(セクション4.4.3では、定義される)はともに32ビットのビットマスクを含んでいます。 追加ビットはStandards Action[RFC2434]を通して定義されるだけであるべきです。
10.5 Proxy Authen Type AVP Values
10.5 プロキシAuthenはAVP値をタイプします。
The Proxy Authen Type AVP (Attribute Type 29) has an associated value maintained by IANA. Values 0-5 are defined in Section 4.4.5, the remaining values are available for assignment via First Come First Served [RFC 2434].
Proxy Authen Type AVP(属性Type29)はIANAに関連値を維持させます。 値0-5はセクション4.4.5で定義されて、残余価値はFirst Come First Served[RFC2434]を通して課題に利用可能です。
Townsley, et al. Standards Track [Page 72] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[72ページ]。
10.6 AVP Header Bits
10.6 AVPヘッダービット
There are four remaining reserved bits in the AVP header. Additional bits should only be assigned via a Standards Action [RFC 2434].
残っている予約された4ビットがAVPヘッダーにあります。 追加ビットはStandards Action[RFC2434]を通して割り当てられるだけであるべきです。
11.0 References
11.0の参照箇所
[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 Recommendation、「デジタル加入者Signaling System No.1(DSS1)--ISDNユーザネットワーク・インターフェースは基本的な呼び出しコントロールのための3仕様を層にします」、Rec。 Q.931(I.451)、1998年5月
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1
[KPS]コーフマンとC.とパールマン、R.とSpeciner、M.、「セキュリティをネットワークでつないでください」 「公立の世界の私信」、新米のホール、1995年3月、ISBN0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1662] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1663] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、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.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.[RFC1990]Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、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.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
Townsley, et al. Standards Track [Page 73] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[73ページ]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2341] バレンシア、A.、リトルウッド、M.、およびT.コラール(「コクチマス層Twoの推進(プロトコル)L2F」、RFC2341)は1998がそうするかもしれません。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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問題部に書くためのガイドライン」BCP26、RFC2434(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)」、RFC2637、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
ISBN0-201-63346-9、「TCP/IPは例証して、ボリュームIはプロトコル[スティーブンス]スティーブンス、W.リチャード(アディソン-ウエスリー出版社Inc.)であること」は1996を行進させます。
12.0 Acknowledgments
12.0 承認
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.Pallと、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.
ライファーがL2TPであってこのドキュメントの編集に寄付されることのプロトコル定義への貴重な気品をしたドーリー舟。
Steve Cobb and Evan Caves redesigned the state machine tables.
Steve Cobbとエヴァン・ケイブズは州の工作台を再設計しました。
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.
ジョンBray、グレッグ・バーンズ、リッシュ・ギャレット、ドン・グロセール、マットHoldrege、テリー・ジョンソン、Doryライファー、およびリッシュ・シーアがオーランド(フロリダ)における第43IETFで貴重な入力とレビューを提供した、総合的な読み易さの改良とこのドキュメントの明快に通じた。
Townsley, et al. Standards Track [Page 74] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[74ページ]。
13.0 Authors' Addresses
13.0 作者のアドレス
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
Gurdeepシン・祭服マイクロソフト社レッドモンド(ワシントン)
EMail: gurdeep@microsoft.com
メール: gurdeep@microsoft.com
Bill Palter RedBack Networks, Inc 1389 Moffett Park Drive Sunnyvale, CA 94089
ビルは20ドル紙幣ネットワーク、モフェット・公園Driveサニーベル、Inc1389カリフォルニア 94089をあしらいます。
EMail: palter@zev.net
メール: palter@zev.net
Allan Rubens Ascend Communications 1701 Harbor Bay Parkway Alameda, CA 94502
アラン・ルーベンはParkwayアラメダ、コミュニケーション1701港Bayカリフォルニア 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
リサーチトライアングルPark、W.マークTownsleyコクチマスSystems7025Kit Creek Road PO Box14987NC 27709
EMail: townsley@cisco.com
メール: townsley@cisco.com
Andrew J. Valencia cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
アンドリューJ.バレンシアコクチマスSystems170西洋タスマンDriveサンノゼカリフォルニア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
Townsley, et al. Standards Track [Page 75] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[75ページ]。
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].
側が最大サイズを示したそれぞれ、それ、窓を受けてください、そして、a遅れた出発と輻輳回避メソッドがコントロールパケットを伝えるのに使用されるのは、お勧めです。 ここで説明されたメソッドはTCP/IP Illustratedのセクション21.6で説明されるようにTCP輻輳回避アルゴリズムに基づいています、Volume I、W.リチャード・スティーブンス[スティーブンス]。
Slow start and congestion avoidance make use of several variables. The congestion window (CWND) defines the number of packets a sender may send before waiting for an acknowledgment. The size of CWND expands and contracts as described below. Note however, that CWND is never allowed to exceed the size of the advertised window obtained from the Receive Window AVP (in the text below, it is assumed any increase will be limited by the Receive Window Size). The variable SSTHRESH determines when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH.
遅れた出発と輻輳回避はいくつかの変数を利用します。 混雑ウィンドウ(CWND)は承認を待つ前に送付者が送るかもしれないパケットの数を定義します。 CWNDのサイズは以下で説明されるように伸び縮みします。 しかしながら、そのCWNDがReceive Window AVPから入手された広告を出している窓のサイズを決して超えることができないことに(以下のテキストでは、どんな増加もReceive Window Sizeによって制限されると思われます)注意してください。 可変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は広告を出している窓(Receive Window AVPから、得る)に初期化されます。 送付者は、次に、1つのパケットを伝えて、承認を待ちます(明白であるか便乗している)。 承認が受け取られているとき、混雑ウィンドウは1〜2まで増加されます。 遅れた出発の間、CWNDはACK(明白なZLBの、または、便乗している)が受け取られている各回1つのパケットによって増強されます。 各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の新しいACKsを受け取った後に1つのパケットはすなわち、CWNDを増強します。 事実上、CWNDが1つのパケットで各周遊旅行を増強している状態で、輻輳回避段階の間の窓の拡張は直線的です。
When congestion occurs (indicated by the triggering of a retransmission) one half of the CWND is saved in SSTHRESH, and CWND is set to one. The sender then reenters the slow start phase.
混雑が起こるとき(「再-トランスミッション」の引き金となることで、示されます)、CWNDの半分がSSTHRESHに取っておかれます、そして、CWNDは1つに用意ができています。 そして、送付者は遅れた出発フェーズに再入します。
Townsley, et al. Standards Track [Page 76] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[76ページ]。
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
---------- ----------
ラック、LNS LNSまたはラック---------- ----------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1
SCCRQ->Nr: 0、ナノ秒: 0 <SCCRP Nr: 1、ナノ秒: 0 SCCCN->Nr: 1、ナノ秒: 1 <ZLB Nr: 2、ナノ秒: 1
B.2: Lost packet with retransmission
B.2: 「再-トランスミッション」がある無くなっているパケット
An existing tunnel has a new session requested by the LAC. The ICRP is lost and must be retransmitted by the LNS. Note that loss of the ICRP has two impacts: not only does it keep the upper level state machine from progressing, but it also keeps the LAC from seeing a timely lower level acknowledgment of its ICRQ.
既存のトンネルで、LACは新しいセッションを要求します。 ICRPを無くなって、LNSは再送しなければなりません。 ICRPの損失には2回の影響力があることに注意してください: また、上側の平らな州のマシンが進歩をするのを妨げるだけではなく、それは、LACがICRQのタイムリーな下のレベル承認を見るのを妨げます。
LAC LNS
--- ---
ラックLNS--- ---
ICRQ ->
Nr: 1, Ns: 2
ICRQ->Nr: 1、ナノ秒: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(パケットは損をしました) <ICRP Nr: 3、ナノ秒: 1
(pause; LAC's timer started first, so fires first)
(止まってください; LACのタイマは、最初に始まるので、最初に、撃たれます)
ICRQ ->
Nr: 1, Ns: 2
ICRQ->Nr: 1、ナノ秒: 2
(Realizing that it has already seen this packet,
the LNS discards the packet and sends a ZLB)
(それが既にこのパケットを見て、LNSがパケットを捨てて、ZLBを送るとわかります)
Townsley, et al. Standards Track [Page 77] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[77ページ]。
<- ZLB
Nr: 3, Ns: 2
<ZLB Nr: 3、ナノ秒: 2
(LNS's retransmit timer fires)
(LNSの再送信タイマ炎)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<ICRP Nr: 3、ナノ秒: 1 ICCN->Nr: 2、ナノ秒: 3
<- ZLB
Nr: 4, Ns: 2
<ZLB Nr: 4、ナノ秒: 2
Townsley, et al. Standards Track [Page 78] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[78ページ]。
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 「権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
Townsley, et al. Standards Track [Page 79] RFC 2661 L2TP August 1999
Townsley、他 規格はL2TP1999年8月にRFC2661を追跡します[79ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Townsley, et al. Standards Track [Page 80]
Townsley、他 標準化過程[80ページ]
一覧
スポンサーリンク
