RFC3931 日本語訳
3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3). J. Lau, Ed.,M. Townsley, Ed., I. Goyret, Ed.. March 2005. (Format: TXT=214407 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lau, Ed.
Request for Comments: 3931 M. Townsley, Ed.
Category: Standards Track Cisco Systems
I. Goyret, Ed.
Lucent Technologies
March 2005
ワーキンググループのJ.ラウ、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド3931M.Townsley、カテゴリ: 2005年の標準化過程エドI.Goyret、シスコシステムズルーセントテクノロジーズの行進
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
層Twoのトンネリングプロトコル--バージョン3(L2TPv3)
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated.
このドキュメントは「Layer Two Tunnelingプロトコル(L2TPv3)のバージョン3インチ」について説明します。 L2TPv3は2つのIPノードの間のトンネリング複数のLayer2接続のためにベース制御プロトコルとカプセル化を定義します。 追加ドキュメントは見習われているそれぞれのデータリンク型のために詳細を詳しく述べます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4
1.2. Specification of Requirements. . . . . . . . . . . . . . 4
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10
3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
3.2.1. L2TP Control Message Header. . . . . . . . . . . 11
3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12
3.3. Control Connection Management. . . . . . . . . . . . . . 13
3.3.1. Control Connection Establishment . . . . . . . . 14
3.3.2. Control Connection Teardown. . . . . . . . . . . 14
3.4. Session Management . . . . . . . . . . . . . . . . . . . 15
3.4.1. Session Establishment for an Incoming Call . . . 15
3.4.2. Session Establishment for an Outgoing Call . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 RFC2661からの変化。 . . . . . . . . . . . . . . . . . 4 1.2. 要件の仕様。 . . . . . . . . . . . . . 4 1.3. 用語。 . . . . . . . . . . . . . . . . . . . . . . 5 2. トポロジー. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3。 概要について議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . . . . 9 3.1. メッセージタイプを監督してください。 . . . . . . . . . . . . . . . . . 10 3.2. L2TPヘッダー形式。 . . . . . . . . . . . . . . . . . . 11 3.2.1. L2TPはメッセージヘッダーを監督します。 . . . . . . . . . . 11 3.2.2. L2TPデータメッセージ。 . . . . . . . . . . . . . . . 12 3.3. 接続管理を制御してください。 . . . . . . . . . . . . . 13 3.3.1. コネクション確立. . . . . . . . 14 3.3.2を制御してください。 接続分解を制御してください。 . . . . . . . . . . 14 3.4. セッション管理. . . . . . . . . . . . . . . . . . . 15 3.4.1。 入って来る呼び出し. . . 15 3.4.2のためのセッション設立。 発信電話. . . 15のためのセッション設立
Lau, et al. Standards Track [Page 1] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[1ページ]RFC3931L2TPv3 March 2005
3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18
4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20
4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21
4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23
4.3. Control Message Authentication . . . . . . . . . . . . . 25
4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26
4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28
4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. General Control Message AVPs . . . . . . . . . . 36
5.4.2. Result and Error Codes . . . . . . . . . . . . . 40
5.4.3. Control Connection Management AVPs . . . . . . . 43
5.4.4. Session Management AVPs. . . . . . . . . . . . . 48
5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57
6. Control Connection Protocol Specification. . . . . . . . . . . 59
6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61
6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
7. Control Connection State Machines. . . . . . . . . . . . . . . 68
7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68
7.2. Control Connection States. . . . . . . . . . . . . . . . 69
7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72
3.4.3. セッション分解. . . . . . . . . . . . . . . . 16 4。 操作. . . . . . . . . . . . . . . . . . . . . . 16 4.1について議定書の中で述べてください。 特定のパケット交換網(PSNs). . . 16 4.1.1の上のL2TP。 IP. . . . . . . . . . . . . . . . . 17 4.1.2の上のL2TPv3 UDPの上のL2TP。 . . . . . . . . . . . . . . . . . 18 4.1.3. L2TPとIPsec. . . . . . . . . . . . . . . . . 20 4.1.4。 IP断片化問題。 . . . . . . . . . . . . 21 4.2. コントロールメッセージの信頼できる配信。 . . . . . . . . . 23 4.3. 通報認証. . . . . . . . . . . . . 25 4.4を制御してください。 Keepalive(こんにちは)。 . . . . . . . . . . . . . . . . . . . 26 4.5. セッションデータフレーム. . . . . . . . . . . . . 26 4.6を進めます。 デフォルトL2特有の副層. . . . . . . . . . . . . . 27 4.6.1。 データ・パケットを配列します。 . . . . . . . . . . . . 28 4.7. L2TPv2/v3相互運用性と移行. . . . . . . . 28 4.7.1。 IP. . . . . . . . . . . . . . . . . 29 4.7.2の上のL2TPv3 UDPの上のL2TPv3。 . . . . . . . . . . . . . . . . 29 4.7.3. 自動L2TPv2後退。 . . . . . . . . . . . 29 5. メッセージ属性値ペアを制御してください。 . . . . . . . . . . . . 30 5.1. AVPは.305.2をフォーマットします。 義務的なAVPsと.325.3に噛み付かれたMを設定すること。 AVP属性値. . . . . . . . . . . . . 33 5.4の隠れること。 AVP概要。 . . . . . . . . . . . . . . . . . . . . . . 36 5.4.1. コントロールメッセージAVPs. . . . . . . . . . 36 5.4司令官.2。 結果とエラーコード. . . . . . . . . . . . . 40 5.4.3。 接続管理AVPs. . . . . . . 43 5.4.4を制御してください。 セッション管理AVPs。 . . . . . . . . . . . . 48 5.4.5. 回路状態AVPs。 . . . . . . . . . . . . . . 57 6. 接続プロトコル仕様を制御してください。 . . . . . . . . . . 59 6.1. スタートコントロール接続要求(SCCRQ).606.2。 スタートコントロール接続回答(SCCRP。). . . . . . . . . 60 6.3 スタートコントロール接続が接続している(SCCCN。). . . . . . . 61 6.4 停止コントロール接続通知(StopCCN。). . . . . 61 6.5 こんにちは、(こんにちは。) . . . . . . . . . . . . . . . . . . . . . 61 6.6. 入って来る発呼要求(ICRQ。). . . . . . . . . . . . . . 62 6.7 入って来る呼び出し回答(ICRP。). . . . . . . . . . . . . . . 63 6.8 入って来る接続完了(ICCN。). . . . . . . . . . . . . 63 6.9 送信する発呼要求(OCRQ。). . . . . . . . . . . . . . 64 6.10 外向的な呼び出し回答(OCRP。). . . . . . . . . . . . . . . 65 6.11 外向的な接続完了(OCCN。). . . . . . . . . . . . . 65 6.12 呼び出し分離に通知している(CDN。). . . . . . . . . . . . . . 66 6.13 青白い誤りに通知している(こぶ。). . . . . . . . . . . . . . . . . 66 6.14 リンクインフォメーションを設定してください(SLI)。 . . . . . . . . . . . . . . . . . . 67 6.15. 明白な承認(ACK。). . . . . . . . . . . . . 67 7 接続州のマシンを制御してください。 . . . . . . . . . . . . . . 68 7.1. 奇形のAVPsとコントロールメッセージ。 . . . . . . . . . . 68 7.2. 接続州を制御してください。 . . . . . . . . . . . . . . . 69 7.3. かかってきた電話. . . . . . . . . . . . . . . . . . . . . 71 7.3.1。 ICRQ送付者州. . . . . . . . . . . . . . . 72
Lau, et al. Standards Track [Page 2] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[2ページ]RFC3931L2TPv3 March 2005
7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73
7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75
7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76
7.5. Termination of a Control Connection. . . . . . . . . . . 77
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
8.1. Control Connection Endpoint and Message Security . . . . 78
8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
9. Internationalization Considerations. . . . . . . . . . . . . . 79
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 85
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94
7.3.2. ICRQ受取人州。 . . . . . . . . . . . . . 73 7.4. 発信電話. . . . . . . . . . . . . . . . . . . . . 74 7.4.1。 OCRQ送付者は.2に.757.4を述べます。 OCRQ受取人(ラック)州。 . . . . . . . . . . 76 7.5. コントロール接続の終了。 . . . . . . . . . . 77 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 78 8.1. 接続終点とメッセージセキュリティ. . . . 78 8.2を制御してください。 データ・パケットスプーフィング. . . . . . . . . . . . . . . . . . 78 9。 国際化問題。 . . . . . . . . . . . . . 79 10. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 80 10.1. メッセージ属性値ペア(AVPs). . . . . . 80 10.2を制御してください。 メッセージタイプAVP値。 . . . . . . . . . . . . . . . . 81 10.3. 結果コードAVPは.81 10.4を評価します。 AVPヘッダービット。 . . . . . . . . . . . . . . . . . . . . 82 10.5. L2TPはメッセージヘッダービット. . . . . . . . . . . . 82 10.6を制御します。 Pseudowireは.83 10.7をタイプします。 回路ステータスビット。 . . . . . . . . . . . . . . . . . . 83 10.8. デフォルトL2特有のSublayerビット。 . . . . . . . . . . . 84 10.9. L2特有の副層タイプ。 . . . . . . . . . . . . . . . 84 10.10 データ配列レベル。 . . . . . . . . . . . . . . . . . 84 11. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 85 11.1。 引用規格. . . . . . . . . . . . . . . . . . 85 11.2。 有益な参照. . . . . . . . . . . . . . . . . 85 12。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 87 付録A: 遅れた出発と輻輳回避を制御してください。 . . . . . 89 付録B: メッセージの例. . . . . . . . . . . . . . . 90の付録Cを制御してください: 一連番号を処理します。 . . . . . . . . . . . . . 91人のエディタのアドレス. . . . . . . . . . . . . . . . . . . . . . . . 93の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 94
1. Introduction
1. 序論
The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism for tunneling Layer 2 (L2) "circuits" across a packet-oriented data network (e.g., over IP). L2TP, as originally defined in RFC 2661, is a standard method for tunneling Point-to-Point Protocol (PPP) [RFC1661] sessions. L2TP has since been adopted for tunneling a number of other L2 protocols. In order to provide greater modularity, this document describes the base L2TP protocol, independent of the L2 payload that is being tunneled.
Layer Two Tunnelingプロトコル(L2TP)はパケット指向のデータ網(例えば、IPの上の)の向こう側にLayer2(L2)「回路」にトンネルを堀るのにダイナミックなメカニズムを提供します。 元々RFC2661で定義されるL2TPはトンネリングPointからポイントへのプロトコル(PPP)[RFC1661]セッションのための標準方法です。 L2TPは、以来、他の多くのL2プロトコルにトンネルを堀るために採用されています。 よりすばらしいモジュール方式を提供するために、このドキュメントはベースL2TPプロトコルについて説明します、トンネルを堀られているL2ペイロードの如何にかかわらず。
The base L2TP protocol defined in this document consists of (1) the control protocol for dynamic creation, maintenance, and teardown of L2TP sessions, and (2) the L2TP data encapsulation to multiplex and demultiplex L2 data streams between two L2TP nodes across an IP network. Additional documents are expected to be published for each L2 data link emulation type (a.k.a. pseudowire-type) supported by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will
本書では定義されたベースL2TPプロトコルは(1) L2TPセッションのダイナミックな作成、メインテナンス、および分解のための制御プロトコル、および(2) 多重送信するデータカプセル化とdemultiplex L2データがIPネットワークの向こう側に2つのL2TPノードの間に流すL2TPから成ります。 L2TP(すなわち、PPP、イーサネット、Frame Relayなど)によってサポートされたそれぞれのL2データ・リンクエミュレーションタイプ(通称pseudowire-タイプ)のために追加ドキュメントが発行されると予想されます。 これらのドキュメントはそうするでしょう。
Lau, et al. Standards Track [Page 3] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[3ページ]RFC3931L2TPv3 March 2005
contain any pseudowire-type specific details that are outside the scope of this base specification.
この基礎仕様の範囲の外にあるあらゆるpseudowire-タイプの特定の詳細を含んでください。
When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as defined in RFC 2661 will be referred to as "L2TPv2", corresponding to the value in the Version field of an L2TP header. (Layer 2 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, L2TP as defined in this document will be referred to as "L2TPv3". Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in general.
L2TPv2とL2TPv3の間の名称が必要であるときに、RFC2661で定義されるL2TPは「L2TPヘッダーのバージョン分野の値に対応するL2TPv2"」と呼ばれるでしょう。 (層2のForwarding(L2F)が定義された、[RFC2341]「バージョン1インチ)。」 時には、本書では定義されるL2TPは"L2TPv3""と呼ばれるでしょう。 さもなければ、頭文字語"L2TP"はL2TPv3か一般に、L2TPを示すでしょう。
1.1. Changes from RFC 2661
1.1. RFC2661からの変化
Many of the protocol constructs described in this document are carried over from RFC 2661. Changes include clarifications based on years of interoperability and deployment experience as well as modifications to either improve protocol operation or provide a clearer separation from PPP. The intent of these modifications is to achieve a healthy balance between code reuse, interoperability experience, and a directed evolution of L2TP as it is applied to new tasks.
本書では説明されたプロトコル構造物の多くがRFC2661から持ち越されます。 変化はプロトコル操作を改良するか、またはPPPから、より明確な分離を提供するために変更と同様に何年もの相互運用性と展開経験に基づく明確化を含んでいます。 これらの変更の意図はそれが新しいタスクに打ち込まれるときL2TPのコード再利用と、相互運用性経験と、指示された発展の間の健康なバランスを獲得することです。
Notable differences between L2TPv2 and L2TPv3 include the following:
L2TPv2とL2TPv3の注目に値する違いは以下を含んでいます:
Separation of all PPP-related AVPs, references, etc., including a
portion of the L2TP data header that was specific to the needs of
PPP. The PPP-specific constructs are described in a companion
document.
すべてのPPP関連のAVPsの分離、PPPの必要性に特定であったL2TPデータヘッダーの一部を含む参照など。 PPP特有の構造物は仲間ドキュメントで説明されます。
Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
Session ID and Control Connection ID, respectively.
それぞれ16ビットのSession IDとTunnel IDから32ビットのSession IDとControl Connection IDまでの変遷。
Extension of the Tunnel Authentication mechanism to cover the
entire control message rather than just a portion of certain
messages.
まさしくあるメッセージの部分よりむしろ全体のコントロールメッセージをカバーするTunnel Authenticationメカニズムの拡大。
Details of these changes and a recommendation for transitioning to L2TPv3 are discussed in Section 4.7.
セクション4.7でこれらの変化の細部とL2TPv3に移行するための推薦について議論します。
1.2. Specification of Requirements
1.2. 要件の仕様
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]で説明されるように本書では解釈されることであるべきですか?
Lau, et al. Standards Track [Page 4] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[4ページ]RFC3931L2TPv3 March 2005
1.3. Terminology
1.3. 用語
Attribute Value Pair (AVP)
属性値組(AVP)
The variable-length concatenation of a unique Attribute
(represented by an integer), a length field, and a Value
containing the actual value identified by the attribute. Zero or
more AVPs make up the body of control messages, which are used in
the establishment, maintenance, and teardown of control
connections. This basic construct is sometimes referred to as a
Type-Length-Value (TLV) in some specifications. (See also:
Control Connection, Control Message.)
属性によって特定された実価を含むユニークなAttribute(整数で、表される)の可変長の連結、長さの分野、およびValue。 AVPsがコントロール接続の設立、メインテナンス、および分解に使用されるコントロールメッセージのボディーにするゼロか以上。 この基本的な構造物はいくつかの仕様に時々Type長さの価値(TLV)と呼ばれます。 (参照: コントロールConnection、Control Message。)
Call (Circuit Up)
呼び出し(回路が上にある状態で)
The action of transitioning a circuit on an L2TP Access
Concentrator (LAC) to an "up" or "active" state. A call may be
dynamically established through signaling properties (e.g., an
incoming or outgoing call through the Public Switched Telephone
Network (PSTN)) or statically configured (e.g., provisioning a
Virtual Circuit on an interface). A call is defined by its
properties (e.g., type of call, called number, etc.) and its data
traffic. (See also: Circuit, Session, Incoming Call, Outgoing
Call, Outgoing Call Request.)
“up"か「アクティブ」へのL2TP Access Concentrator(LAC)の上の回路が述べる移行の動作。 呼び出しは、シグナル伝達特性(例えば、Public Switched Telephone Network(PSTN)を通した入って来るか外向的な呼び出し)を通してダイナミックに設立されるか、または静的に構成されるかもしれません(例えば、インタフェースのVirtual Circuitに食糧を供給します)。 呼び出しは特性(例えば、数などと呼ばれる呼び出しのタイプ)とそのデータ通信量で定義されます。 (参照: 回路、Session、Incoming Call、Outgoing Call、Outgoing Call Request。)
Circuit
回路
A general term identifying any one of a wide range of L2
connections. A circuit may be virtual in nature (e.g., an ATM
PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct
correlation to a physical layer (e.g., an RS-232 serial line).
Circuits may be statically configured with a relatively long-lived
uptime, or dynamically established with signaling to govern the
establishment, maintenance, and teardown of the circuit. For the
purposes of this document, a statically configured circuit is
considered to be essentially the same as a very simple, long-
lived, dynamic circuit. (See also: Call, Remote System.)
さまざまなL2接続のいずれも特定する一般項。 回路が仮想のコネが自然(例えば、ATM PVC、IEEE802VLAN、またはL2TPセッション)であったなら持っているかもしれませんか、またはそれは物理的な層(例えば、RS-232シリアル・ライン)にダイレクト相関関係を持っているかもしれません。 回路は、比較的長命の動作可能時間によって静的に構成されるか、または回路の設立、メインテナンス、および分解を治めると合図するのにダイナミックに確立されるかもしれません。 このドキュメントの目的のために、静的に構成された回路が非常に簡単で、長い間送られて、ダイナミックな回路と本質的には同じであると考えられます。 (参照: Remote System、電話をしてください。)
Client
クライアント
(See Remote System.)
(リモートシステムを見てください。)
Control Connection
コントロール接続
An L2TP control connection is a reliable control channel that is
used to establish, maintain, and release individual L2TP sessions
as well as the control connection itself. (See also: Control
Message, Data Channel.)
L2TPコントロール接続はコントロール接続自体と同様に個々のL2TPセッションを確立して、維持して、リリースするのに使用される高信頼の制御チャンネルです。 (参照: コントロールMessage、Data Channel。)
Lau, et al. Standards Track [Page 5] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[5ページ]RFC3931L2TPv3 March 2005
Control Message
コントロールメッセージ
An L2TP message used by the control connection. (See also:
Control Connection.)
コントロール接続によって使用されたL2TPメッセージ。 (参照: コントロールConnection。)
Data Message
データメッセージ
Message used by the data channel. (a.k.a. Data Packet, See also:
Data Channel.)
データ・チャンネルによって使用されたメッセージ。 (通称Data Packet、Seeも: データChannel。)
Data Channel
データ・チャンネル
The channel for L2TP-encapsulated data traffic that passes between
two LCCEs over a Packet-Switched Network (i.e., IP). (See also:
Control Connection, Data Message.)
Packetによって切り換えられたNetwork(すなわち、IP)の上の2LCCEsの間を通り過ぎるL2TPによってカプセル化されたデータ通信量のためのチャンネル。 (参照: コントロールConnection、Data Message。)
Incoming Call
かかってきた電話
The action of receiving a call (circuit up event) on an LAC. The
call may have been placed by a remote system (e.g., a phone call
over a PSTN), or it may have been triggered by a local event
(e.g., interesting traffic routed to a virtual interface). An
incoming call that needs to be tunneled (as determined by the LAC)
results in the generation of an L2TP ICRQ message. (See also:
Call, Outgoing Call, Outgoing Call Request.)
要求(イベントへの回路)を受けるLACへの動作。 リモートシステム(例えば、PSTNの上の電話)によって電話が出されたかもしれませんか、またはそれはローカルイベントによって引き起こされたかもしれません(例えばおもしろいトラフィックは仮想インターフェースに掘られました)。 トンネルを堀られる(LACによって決定されるように)必要があるかかってきた電話はL2TP ICRQメッセージの世代で結果として生じます。 (参照: 呼び出し、Outgoing Call、Outgoing Call Request。)
L2TP Access Concentrator (LAC)
L2TPアクセス集中装置(ラック)
If an L2TP Control Connection Endpoint (LCCE) is being used to
cross-connect an L2TP session directly to a data link, we refer to
it as an L2TP Access Concentrator (LAC). An LCCE may act as both
an L2TP Network Server (LNS) for some sessions and an LAC for
others, so these terms must only be used within the context of a
given set of sessions unless the LCCE is in fact single purpose
for a given topology. (See also: LCCE, LNS.)
L2TP Control Connection Endpoint(LCCE)が直接データへのL2TPセッションがリンクする十字接続に使用されているなら、私たちはL2TP Access Concentrator(LAC)とそれを呼びます。 LCCEがいくつかのセッションのためのL2TP Network Server(LNS)と他のもののためのLACの両方として機能するかもしれないので、事実上、LCCEが与えられたトポロジーへのただ一つの目的でないなら与えられたセットのセッションの文脈の中でこれらの用語を使用するだけでよいです。 (参照: LCCE、LNS。)
L2TP Control Connection Endpoint (LCCE)
L2TPコントロール接続終点(LCCE)
An L2TP node that exists at either end of an L2TP control
connection. May also be referred to as an LAC or LNS, depending
on whether tunneled frames are processed at the data link (LAC) or
network layer (LNS). (See also: LAC, LNS.)
L2TPコントロール接続のどちらの終わりにも存在するL2TPノード。 また、LACかLNSと呼ばれるかもしれません、トンネルを堀られたフレームがデータ・リンク(LAC)かネットワーク層(LNS)で処理されるかどうかによって。 (参照: LAC、LNS。)
L2TP Network Server (LNS)
L2TPネットワークサーバ(LNS)
If a given L2TP session is terminated at the L2TP node and the
encapsulated network layer (L3) packet processed on a virtual
interface, we refer to this L2TP node as an L2TP Network Server
与えられたL2TPセッションがL2TPノードと仮想インターフェースで処理されたカプセル化されたネットワーク層(L3)パケットで終えられるなら、私たちはこのL2TPノードをL2TP Network Serverと呼びます。
Lau, et al. Standards Track [Page 6] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[6ページ]RFC3931L2TPv3 March 2005
(LNS). A given LCCE may act as both an LNS for some sessions and
an LAC for others, so these terms must only be used within the
context of a given set of sessions unless the LCCE is in fact
single purpose for a given topology. (See also: LCCE, LAC.)
(LNS。) 与えられたLCCEがいくつかのセッションのためのLNSと他のもののためのLACの両方として機能するかもしれないので、事実上、LCCEが与えられたトポロジーへのただ一つの目的でないなら与えられたセットのセッションの文脈の中でこれらの用語を使用するだけでよいです。 (参照: LCCE、LAC。)
Outgoing Call
発信電話
The action of placing a call by an LAC, typically in response to
policy directed by the peer in an Outgoing Call Request. (See
also: Call, Incoming Call, Outgoing Call Request.)
LACと、通常Outgoing Call Requestで同輩によって指示された方針に対応して電話をする動作。 (参照: 呼び出し、Incoming Call、Outgoing Call Request。)
Outgoing Call Request
送信する発呼要求
A request sent to an LAC to place an outgoing call. The request
contains specific information not known a priori by the LAC (e.g.,
a number to dial). (See also: Call, Incoming Call, Outgoing
Call.)
要求は、発信電話を置くためにLACに発信しました。 要求はLAC(例えばダイヤルする番号)によって先験的に知られなかった特殊情報を含んでいます。 (参照: 呼び出し、Incoming Call、Outgoing Call。)
Packet-Switched Network (PSN)
パケット交換網(PSN)
A network that uses packet switching technology for data delivery.
For L2TPv3, this layer is principally IP. Other examples include
MPLS, Frame Relay, and ATM.
データ配送にパケット交換技術を使用するネットワーク。 L2TPv3に関しては、この層は主にIPです。 他の例はMPLS、Frame Relay、およびATMを含んでいます。
Peer
同輩
When used in context with L2TP, Peer refers to the far end of an
L2TP control connection (i.e., the remote LCCE). An LAC's peer
may be either an LNS or another LAC. Similarly, an LNS's peer may
be either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
状況内においてL2TPと共に使用されると、PeerはL2TPコントロール接続(すなわち、リモートLCCE)の遠端について言及します。 LACの同輩は、LNSかLACのどちらかであるかもしれません別。 同様に、LNSの同輩は、LACかLNSのどちらかであるかもしれません別。 (参照: LAC、LCCE、LNS。)
Pseudowire (PW)
Pseudowire(PW)
An emulated circuit as it traverses a PSN. There is one
Pseudowire per L2TP Session. (See also: Packet-Switched Network,
Session.)
PSNを横断するような見習われた回路。 1L2TP Sessionあたり1Pseudowireがあります。 (参照: パケットで切り換えられたNetwork、Session。)
Pseudowire Type
Pseudowireはタイプします。
The payload type being carried within an L2TP session. Examples
include PPP, Ethernet, and Frame Relay. (See also: Session.)
L2TPセッション以内に運ばれるペイロードタイプ。 例はPPP、イーサネット、およびFrame Relayを含んでいます。 (参照: セッション。)
Remote System
リモートシステム
An end system or router connected by a circuit to an LAC.
エンドシステムかルータが回路のそばでLACに接続しました。
Lau, et al. Standards Track [Page 7] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[7ページ]RFC3931L2TPv3 March 2005
Session
セッション
An L2TP session is the entity that is created between two LCCEs in
order to exchange parameters for and maintain an emulated L2
connection. Multiple sessions may be associated with a single
Control Connection.
そして、L2TPセッションがパラメタを交換するために2LCCEsの間で作成される実体である、見習われたL2接続を維持してください。 複数のセッションが独身のControl Connectionに関連しているかもしれません。
Zero-Length Body (ZLB) Message
ゼロ・レングス本体(ZLB)メッセージ
A control message with only an L2TP header. ZLB messages are used
only to acknowledge messages on the L2TP reliable control
connection. (See also: Control Message.)
L2TPヘッダーだけがあるコントロールメッセージ。 ZLBメッセージは使用されますが、L2TPの頼もしいコントロール接続に関するメッセージを承認します。 (参照: コントロールMessage。)
2. Topology
2. トポロジー
L2TP operates between two L2TP Control Connection Endpoints (LCCEs), tunneling traffic across a packet network. There are three predominant tunneling models in which L2TP operates: LAC-LNS (or vice versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. (Dotted lines designate network connections. Solid lines designate circuit connections.)
パケット網の向こう側にトラフィックにトンネルを堀って、L2TPは2L2TP Control Connection Endpoints(LCCEs)の間で作動します。 L2TPが作動する3つの支配的なトンネリングモデルがあります: LAC-LNS(逆もまた同様である)、LAC-LAC、およびLNS-LNS。 これらのモデルは以下に図解されます。 (点線はネットワーク接続を任命します。 実線は回路接続を任命します。)
Figure 2.0: L2TP Reference Models
図2.0: L2TP規範モデル
(a) LAC-LNS Reference Model: On one side, the LAC receives traffic from an L2 circuit, which it forwards via L2TP across an IP or other packet-based network. On the other side, an LNS logically terminates the L2 circuit locally and routes network traffic to the home network. The action of session establishment is driven by the LAC (as an incoming call) or the LNS (as an outgoing call).
(a) ラック-LNS規範モデル: 半面の上では、LACはL2回路からトラフィックを受けます。(それはIPか他のパケットを拠点とするネットワークの向こう側のL2TPを通してそれを進めます)。 反対側の上では、LNSは局所的にL2回路を論理的に終えて、ネットワークトラフィックをホームネットワークに発送します。 セッション設立の動作はLAC(かかってきた電話としての)かLNSによって追い立てられます(発信電話として)。
+-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+
remote
system
|<-- emulated service -->|
|<----------- L2 service ------------>|
+-----+ L2+-----+ +-----+ | |------| ラック|.........[IP]…| LNS|...[ホームネットワーク] +-----+ +-----+ +-----+ リモートシステム| <-- サービスを見習います-->| | <、-、-、-、-、-、-、-、-、-、-- L2サービス------------>|
(b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. Each LAC forwards circuit traffic from the remote system to the peer LAC using L2TP, and vice versa. In its simplest form, an LAC acts as a simple cross-connect between a circuit to a remote system and an L2TP session. This model typically involves symmetric establishment; that is, either side of the connection may initiate a session at any time (or simultaneously, in which a tie breaking mechanism is utilized).
(b) ラックラック規範モデル: このモデルでは、両方のLCCEsはLACsです。 各LACはL2TPを使用することでリモートシステムから同輩LACまで回路トラフィックを進めます、そして、逆もまた同様です。 最も簡単なフォームでは、LACは簡単な十字接続としてリモートシステムへの回路とL2TPセッションの間で機能します。 このモデルは左右対称の設立に通常かかわります。 接続のすなわちどちらの側面もいつでも(または、同時に繋がりがメカニズムを壊して、利用されたコネ)、セッションを開始するかもしれません。
Lau, et al. Standards Track [Page 8] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[8ページ]RFC3931L2TPv3 March 2005
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
+-----+ L2+-----+ +-----+ L2+-----+ | |------| ラック|........[IP]…| ラック|------| | +-----+ +-----+ +-----+ +-----+ リモートリモートシステムシステム| <、- サービスを見習う、->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- L2サービス----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A user-level, traffic-generated, or signaled event typically drives session establishment from one side of the tunnel. For example, a tunnel generated from a PC by a user, or automatically by customer premises equipment.
(c) LNS-LNS規範モデル: このモデルはLCCEsとして2LNSsを持っています。 ユーザ平らであるか、トラフィックで発生しているか、合図されたイベントはトンネルの半面でセッション設立を通常運転します。 例えば顧客端末によってユーザによってPCから自動的に生成されたトンネル。
+-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
+-----+ +-----+ [ホームネットワーク]…| LNS|........[IP]…| LNS|...[ホームネットワーク] +-----+ +-----+ | <、- サービスを見習う、->| | <、-、-、-- L2サービス---->|
Note: In L2TPv2, user-driven tunneling of this type is often referred to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part of a software package on a host is sometimes referred to as an "LAC Client" [RFC2661].
以下に注意してください。 L2TPv2では、このタイプのユーザ駆動のトンネリングはしばしば「自発的のトンネリング」[RFC2809]と呼ばれます。 さらに、ソフトウェアパッケージの一部としてホストに機能するLNSは「ラッククライアント」[RFC2661]と時々呼ばれます。
3. Protocol Overview
3. プロトコル概要
L2TP is comprised of two types of messages, control messages and data messages (sometimes referred to as "control packets" and "data packets", respectively). Control messages are used in the establishment, maintenance, and clearing of control connections and sessions. These messages utilize a reliable control channel within L2TP to guarantee delivery (see Section 4.2 for details). Data messages are used to encapsulate the L2 traffic being carried over the L2TP session. Unlike control messages, data messages are not retransmitted when packet loss occurs.
L2TPは2つのタイプに関するメッセージ、コントロールメッセージ、およびデータメッセージ(それぞれ「コントロールパケット」と「データ・パケット」と時々呼ばれる)から成ります。 コントロールメッセージはコントロール接続とセッションの設立、メインテナンス、および開拓地に使用されます。 これらのメッセージは、荷渡しを保証するのにL2TPの中で高信頼の制御チャンネルを利用します(詳細に関してセクション4.2を見てください)。 データメッセージは、L2がL2TPセッションの間に運ばれるトラフィックであるとカプセル化するのに使用されます。 パケット損失が起こるとき、コントロールメッセージと異なって、データメッセージは再送されません。
The L2TPv3 control message format defined in this document borrows largely from L2TPv2. These control messages are used in conjunction with the associated protocol state machines that govern the dynamic setup, maintenance, and teardown for L2TP sessions. The data message format for tunneling data packets may be utilized with or without the L2TP control channel, either via manual configuration or via other signaling methods to pre-configure or distribute L2TP session information. Utilization of the L2TP data message format with other signaling methods is outside the scope of this document.
本書では定義されたL2TPv3コントロールメッセージ・フォーマットは主にL2TPv2から借ります。 これらのコントロールメッセージはL2TPセッションのためにダイナミックなセットアップ、メインテナンス、および分解を支配する関連プロトコル州のマシンに関連して使用されます。 トンネリングデータ・パケットのためのデータメッセージ・フォーマットは手動の構成かL2TP制御チャンネルのあるなしにかかわらずL2TPセッション情報をあらかじめ設定するか、または分配する他のシグナリングメソッドで利用されるかもしれません。 このドキュメントの範囲の外に他のシグナリングメソッドがあるL2TPデータメッセージ・フォーマットの利用があります。
Lau, et al. Standards Track [Page 9] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[9ページ]RFC3931L2TPv3 March 2005
Figure 3.0: L2TPv3 Structure
図3.0: L2TPv3構造
+-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+
+-------------------+ +-----------------------+ | トンネルを堀られたフレーム| | L2TPコントロールメッセージ| +-------------------+ +-----------------------+ | L2TPデータヘッダー| | L2TPコントロールヘッダー| +-------------------+ +-----------------------+ | L2TPデータ・チャンネル| | L2TP制御チャンネル| | (頼り無い)です。 | | (信頼できる)です。 | +-------------------+----+-----------------------+ | パケットで切り換えられたNetwork(IP、フラン、MPLSなど) | +------------------------------------------------+
Figure 3.0 depicts the relationship of control messages and data messages over the L2TP control and data channels, respectively. Data messages are passed over an unreliable data channel, encapsulated by an L2TP header, and sent over a Packet-Switched Network (PSN) such as IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over a reliable L2TP control channel, which operates over the same PSN.
図3.0はコントロールとデータがそれぞれチャネルを開設するL2TPの上にコントロールメッセージとデータメッセージの関係について表現します。 データメッセージは、L2TPヘッダーによってカプセル化された頼り無いデータ・チャンネルの上に渡されて、IPなどのPacketによって切り換えられたNetwork(PSN)、UDP、Frame Relay、ATM、MPLSなどの上に送られます。 高信頼のL2TP制御チャンネルの上にコントロールメッセージを送ります。チャンネルは同じPSNの上で働いています。
The necessary setup for tunneling a session with L2TP consists of two steps: (1) Establishing the control connection, and (2) establishing a session as triggered by an incoming call or outgoing call. An L2TP session MUST be established before L2TP can begin to forward session frames. Multiple sessions may be bound to a single control connection, and multiple control connections may exist between the same two LCCEs.
トンネルを堀って、L2TPとのセッションが2から成るので、必要なセットアップは踏まれます: (1) かかってきた電話か発信電話で引き起こされるようにセッションを確立しながら、コントロール接続、および(2)を確立します。 L2TPがセッションフレームを進め始めることができる前にL2TPセッションを確立しなければなりません。 複数のセッションが単一管理接続に縛られるかもしれません、そして、複合管理接続は同じ2LCCEsの間に存在するかもしれません。
3.1. Control Message Types
3.1. コントロールメッセージタイプ
The Message Type AVP (see Section 5.4.1) defines the specific type of control message being sent.
Message Type AVP(セクション5.4.1を見る)は送られるコントロールメッセージの特定のタイプを定義します。
This document defines the following control message types (see Sections 6.1 through 6.15 for details on the construction and use of each message):
このドキュメントは以下のコントロールメッセージタイプを定義します(各メッセージの工事と使用に関する詳細に関してセクション6.1〜6.15を見てください):
Control Connection Management
コントロール接続管理
0 (reserved)
1 (SCCRQ) Start-Control-Connection-Request
2 (SCCRP) Start-Control-Connection-Reply
3 (SCCCN) Start-Control-Connection-Connected
4 (StopCCN) Stop-Control-Connection-Notification
5 (reserved)
6 (HELLO) Hello
20 (ACK) Explicit Acknowledgement
コントロール接続要求を始めている0(予約される)1(SCCRQ)2(SCCRP)スタートコントロール接続回答3(SCCCN)接続が接続したスタートコントロール4(StopCCN)停止コントロール接続通知5(予約される)6(こんにちは)、こんにちは、20(ACK)の明白な承認
Lau, et al. Standards Track [Page 10] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[10ページ]RFC3931L2TPv3 March 2005
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
Link Status Change Reporting
リンク状態変化報告
16 (SLI) Set-Link-Info
16 (SLI)セットリンクインフォメーション
3.2. L2TP Header Formats
3.2. L2TPヘッダー形式
This section defines header formats for L2TP control messages and L2TP data messages. All values are placed into their respective fields and sent in network order (high-order octets first).
このセクションはL2TPコントロールメッセージとL2TPデータメッセージのためにヘッダー形式を定義します。 すべての値をそれらのそれぞれの分野に置いて、ネットワークオーダーで送ります(八重奏に1番目を高値で命令してください)。
3.2.1. L2TP Control Message Header
3.2.1. L2TPコントロールメッセージヘッダー
The L2TP control message header provides information for the reliable transport of messages that govern the establishment, maintenance, and teardown of L2TP sessions. By default, control messages are sent over the underlying media in-band with L2TP data messages.
L2TPコントロールメッセージヘッダーはL2TPセッションの設立、メインテナンス、および分解を治めるメッセージの信頼できる輸送のための情報を提供します。 デフォルトで、L2TPデータメッセージによるバンドの基本的なメディアの上にコントロールメッセージを送ります。
The L2TP control message header is formatted as follows:
L2TPコントロールメッセージヘッダーは以下の通りフォーマットされます:
Figure 3.2.1: L2TP Control Message Header
図3.2.1: L2TPコントロールメッセージヘッダー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|x|x|x|x|x|x| Ver| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロール接続ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ナノ秒| Nr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 1, indicating that this is a control message.
これがコントロールメッセージであることを示して、Tビットを1に設定しなければなりません。
Lau, et al. Standards Track [Page 11] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[11ページ]RFC3931L2TPv3 March 2005
The L and S bits MUST be set to 1, indicating that the Length field and sequence numbers are present.
Length分野と一連番号が存在しているのを示して、LとSビットを1に設定しなければなりません。
The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages.
xビットは今後の拡大のために予約されます。 すべての予約されたビットを送信されるメッセージに0に設定されて、入力メッセージで無視しなければなりません。
The Ver field indicates the version of the L2TP control message header described in this document. On sending, this field MUST be set to 3 for all messages (unless operating in an environment that includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 4.1 for details).
Ver分野は本書では説明されたL2TPコントロールメッセージヘッダーのバージョンを示します。 発信のときに、すべてのメッセージのためにこの分野を3に設定しなければなりません(L2TPv2[RFC2661]、そして/または、また、L2F[RFC2341]を含んでいる環境で作動しない場合、詳細に関してセクション4.1を見てください)。
The Length field indicates the total length of the message in octets, always calculated from the start of the control message header itself (beginning with the T bit).
Length分野はコントロールメッセージヘッダー自体の始まりからいつも計算された八重奏における、メッセージの全長を示します(Tビットで始まって)。
The Control Connection ID field contains the identifier for the control connection. L2TP control connections are named by identifiers that have local significance only. That is, the same control connection will be given unique Control Connection IDs by each LCCE from within each endpoint's own Control Connection ID number space. As such, the Control Connection ID in each message is that of the intended recipient, not the sender. Non-zero Control Connection IDs are selected and exchanged as Assigned Control Connection ID AVPs during the creation of a control connection.
Control Connection ID分野はコントロール接続への識別子を含んでいます。 L2TPコントロール接続はローカルの意味しか持っていない識別子によって命名されます。 各終点の自己のControl Connection ID数のスペースからの各LCCEはすなわち、同じコントロール接続が与えられたユニークなControl Connection IDになるでしょう。 そういうものとして、各メッセージのControl Connection IDは送付者ではなく、意図している受取人のものです。 コントロール接続の作成の間、Assigned Control Connection ID AVPsとして非ゼロControl Connection IDを選択して、交換します。
Ns indicates the sequence number for this control message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See Section 4.2 for more information on using this field.
ゼロで始まって、ナノ秒はこのコントロールメッセージのために一連番号を示します、そして、各メッセージあたりの(法2**16)を1つ増加するのは発信しました。 この分野を使用する詳しい情報に関してセクション4.2を見てください。
Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-order message received plus one (modulo 2**16). See Section 4.2 for more information on using this field.
Nrは次の受け取られるべきコントロールメッセージで予想された一連番号を示します。 したがって、Nrはオーダーにおける受け取られた最後のメッセージと1(法2**16)のNsに用意ができています。 この分野を使用する詳しい情報に関してセクション4.2を見てください。
3.2.2. L2TP Data Message
3.2.2. L2TPデータメッセージ
In general, an L2TP data message consists of a (1) Session Header, (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as depicted below.
一般に、L2TPデータメッセージは(1)セッションHeader、(2) 任意のL2特有のSublayer、および(3) Tunnel有効搭載量から成ります、以下に表現されるように。
Lau, et al. Standards Track [Page 12] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[12ページ]RFC3931L2TPv3 March 2005
Figure 3.2.2: L2TP Data Message Header
図3.2.2: L2TPデータメッセージヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Session Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-Specific Sublayer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TPセッションヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2特有の副層| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量にトンネルを堀ってください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TP Session Header is specific to the encapsulating PSN over which the L2TP traffic is delivered. The Session Header MUST provide (1) a method of distinguishing traffic among multiple L2TP data sessions and (2) a method of distinguishing data messages from control messages.
L2TP Session HeaderはL2TPトラフィックが提供される要約のPSNに特定です。 Session Headerは(1) 複数のL2TPデータセッションのときにトラフィックを区別するメソッドと(2) コントロールメッセージとデータメッセージを区別するメソッドを提供しなければなりません。
Each type of encapsulating PSN MUST define its own session header, clearly identifying the format of the header and parameters necessary to setup the session. Section 4.1 defines two session headers, one for transport over UDP and one for transport over IP.
PSN MUSTをカプセル化する各タイプはそれ自身のセッションヘッダーを定義します、明確にセッションをセットアップするのに必要なヘッダーとパラメタの形式を特定して。 セクション4.1は2個のセッションヘッダー、輸送のためのUDPの上のもの、および輸送のためのIPの上の1つを定義します。
The L2-Specific Sublayer is an intermediary layer between the L2TP session header and the start of the tunneled frame. It contains control fields that are used to facilitate the tunneling of each frame (e.g., sequence numbers or flags). The Default L2-Specific Sublayer for L2TPv3 is defined in Section 4.6.
L2特有のSublayerはL2TPセッションヘッダーとトンネルを堀られたフレームの始まりの間の仲介者層です。 それはそれぞれのフレーム(例えば、一連番号か旗)のトンネリングを容易にするのに使用される制御フィールドを含んでいます。 L2TPv3のためのDefault L2特有のSublayerはセクション4.6で定義されます。
The Data Message Header is followed by the Tunnel Payload, including any necessary L2 framing as defined in the payload-specific companion documents.
Tunnel有効搭載量はData Message Headerのあとに続いています、ペイロード特有の仲間ドキュメントで定義されるどんな必要なL2縁どりも含んでいて。
3.3. Control Connection Management
3.3. コントロール接続管理
The L2TP control connection handles dynamic establishment, teardown, and maintenance of the L2TP sessions and of the control connection itself. The reliable delivery of control messages is described in Section 4.2.
L2TPコントロール接続はL2TPセッションとコントロール接続自体のダイナミックな設立、分解、およびメインテナンスを扱います。 コントロールメッセージの信頼できる配信はセクション4.2で説明されます。
This section describes typical control connection establishment and teardown exchanges. It is important to note that, in the diagrams that follow, the reliable control message delivery mechanism exists independently of the L2TP state machine. For instance, Explicit Acknowledgement (ACK) messages may be sent after any of the control messages indicated in the exchanges below if an acknowledgment is not piggybacked on a later control message.
このセクションは典型的なコントロールコネクション確立と分解交換について説明します。 信頼できる規制メッセージ排紙機構がL2TP州のマシンの如何にかかわらず従うダイヤグラムで存在することに注意するのは重要です。 例えば、コントロールメッセージのどれかが、以下での交換で承認が後のコントロールメッセージで背負われないかどうかを示した後にExplicit Acknowledgement(ACK)メッセージを送るかもしれません。
Lau, et al. Standards Track [Page 13] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[13ページ]RFC3931L2TPv3 March 2005
LCCEs are identified during control connection establishment either by the Host Name AVP, the Router ID AVP, or a combination of the two (see Section 5.4.3). The identity of a peer LCCE is central to selecting proper configuration parameters (i.e., Hello interval, window size, etc.) for a control connection, as well as for determining how to set up associated sessions within the control connection, password lookup for control connection authentication, control connection level tie breaking, etc.
LCCEsはコントロールコネクション確立の間、Host Name AVP、Router ID AVP、または2つのものの組み合わせで特定されます(セクション5.4.3を見てください)。 同輩LCCEのアイデンティティはコントロール接続と、コントロール接続、コントロール接続認証のためのパスワードルックアップ、コントロール接続レベル繋がりの壊す中で合同会議をセットアップする方法を決定するための適切な設定パラメータ(すなわち、Hello間隔、ウィンドウサイズなど)を選択するのに一番重要です。
3.3.1. Control Connection Establishment
3.3.1. コントロールコネクション確立
Establishment of the control connection involves an exchange of AVPs that identifies the peer and its capabilities.
コントロール接続の設立は同輩とその能力を特定するAVPsの交換にかかわります。
A three-message exchange is used to establish the control connection. The following is a typical message exchange:
3交換処理が、コントロール接続を証明するのに使用されます。 ↓これは典型的な交換処理です:
LCCE A LCCE B
------ ------
SCCRQ ->
<- SCCRP
SCCCN ->
LCCEはLCCE Bです。------ ------ SCCRQ-><SCCRP SCCCN->。
3.3.2. Control Connection Teardown
3.3.2. コントロール接続分解
Control connection teardown may be initiated by either LCCE and is accomplished by sending a single StopCCN control message. As part of the reliable control message delivery mechanism, the recipient of a StopCCN MUST send an ACK message to acknowledge receipt of the message and maintain enough control connection state to properly accept StopCCN retransmissions over at least a full retransmission cycle (in case the ACK message is lost). The recommended time for a full retransmission cycle is at least 31 seconds (see Section 4.2). The following is an example of a typical control message exchange:
コントロール接続分解は、LCCEによって起こされるかもしれなくて、ただ一つのStopCCNコントロールメッセージを送ることによって、達成されます。 信頼できる規制メッセージ排紙機構の一部として、StopCCNの受取人は少なくとも完全な「再-トランスミッション」サイクルにわたってメッセージの領収書を受け取ったことを知らせて、適切にStopCCN retransmissionsを受け入れることができるくらいのコントロール接続状態を維持するACKメッセージを送らなければなりません(ACKメッセージが無くなるといけないので)。 完全な「再-トランスミッション」サイクルの間のお勧めの時間は少なくとも31秒(セクション4.2を見る)です。 ↓これは典型的なコントロール交換処理に関する例です:
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
LCCEはLCCE Bです。------ ------ StopCCN->。(きれいにします)
(Wait)
(Clean up)
(待ち)(きれいにします)
An implementation may shut down an entire control connection and all sessions associated with the control connection by sending the StopCCN. Thus, it is not necessary to clear each session individually when tearing down the whole control connection.
実装は、StopCCNを送ることによって、全体のコントロール接続とコントロール接続に関連しているすべてのセッションを止めるかもしれません。 全体のコントロール接続を取りこわすとき、したがって、各セッションのときに個別にクリアするのは必要ではありません。
Lau, et al. Standards Track [Page 14] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[14ページ]RFC3931L2TPv3 March 2005
3.4. Session Management
3.4. セッション管理
After successful control connection establishment, individual sessions may be created. Each session corresponds to a single data stream between the two LCCEs. This section describes the typical call establishment and teardown exchanges.
うまくいっているコントロールコネクション確立の後に、個々のセッションは作成されるかもしれません。 各セッションは2LCCEsの間のただ一つのデータ・ストリームに対応しています。 このセクションは典型的な呼び出し設立と分解交換について説明します。
3.4.1. Session Establishment for an Incoming Call
3.4.1. かかってきた電話のためのセッション設立
A three-message exchange is used to establish the session. The following is a typical sequence of events:
3交換処理が、セッションを証明するのに使用されます。 ↓これはイベントの典型的な系列です:
LCCE A LCCE B
------ ------
(Call
Detected)
LCCEはLCCE Bです。------ ------ (検出された呼び出し)
ICRQ ->
<- ICRP
(Call
Accepted)
ICRQ-><ICRP(着呼受付)
ICCN ->
ICCN->。
3.4.2. Session Establishment for an Outgoing Call
3.4.2. 発信電話のためのセッション設立
A three-message exchange is used to set up the session. The following is a typical sequence of events:
3交換処理が、セッションをセットアップするのに使用されます。 ↓これはイベントの典型的な系列です:
LCCE A LCCE B
------ ------
<- OCRQ
OCRP ->
LCCEはLCCE Bです。------ ------ <。 OCRQ OCRP->。
(Perform
Call
Operation)
(呼び出し操作を実行します)
OCCN ->
OCCN->。
(Call Operation
Completed
Successfully)
(首尾よく完了する呼び出し操作)
Lau, et al. Standards Track [Page 15] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[15ページ]RFC3931L2TPv3 March 2005
3.4.3. Session Teardown
3.4.3. セッション分解
Session teardown may be initiated by either the LAC or LNS and is accomplished by sending a CDN control message. After the last session is cleared, the control connection MAY be torn down as well (and typically is). The following is an example of a typical control message exchange:
セッション分解は、LACかLNSのどちらかによって起こされるかもしれなくて、CDNコントロールメッセージを送ることによって、達成されます。 納会をクリアした後に、また(そして、通常ある)、コントロール接続を取りこわすかもしれません。 ↓これは典型的なコントロール交換処理に関する例です:
LCCE A LCCE B
------ ------
CDN ->
(Clean up)
LCCEはLCCE Bです。------ ------ CDN->。(きれいにします)
(Clean up)
(きれいにします)
4. Protocol Operation
4. プロトコル操作
4.1. L2TP Over Specific Packet-Switched Networks (PSNs)
4.1. 特定のパケット交換網の上のL2TP(PSNs)
L2TP may operate over a variety of PSNs. There are two modes described for operation over IP, L2TP directly over IP (see Section 4.1.1) and L2TP over UDP (see Section 4.1.2). L2TPv3 implementations MUST support L2TP over IP and SHOULD support L2TP over UDP for better NAT and firewall traversal, and for easier migration from L2TPv2.
L2TPはさまざまなPSNsの上で作動するかもしれません。 IPの上の操作、IPの直接上のL2TP(セクション4.1.1を見る)、およびL2TPのためにUDPの上で説明された2つのモードがあります(セクション4.1.2を見てください)。 L2TPv3実装はIPの上でL2TPをサポートしなければなりません、そして、SHOULDは、より良いNATとファイアウォール縦断、およびL2TPv2からの、より簡単な移行のためにUDPの上でL2TPをサポートします。
L2TP over other PSNs may be defined, but the specifics are outside the scope of this document. Examples of L2TPv2 over other PSNs include [RFC3070] and [RFC3355].
他のPSNsの上のL2TPは定義されるかもしれませんが、このドキュメントの範囲の外に詳細があります。 他のPSNsの上のL2TPv2に関する例は[RFC3070]と[RFC3355]を含んでいます。
The following field definitions are defined for use in all L2TP Session Header encapsulations.
以下のフィールド定義はすべてのL2TP Session Headerカプセル化における使用のために定義されます。
Session ID
セッションID
A 32-bit field containing a non-zero identifier for a session.
L2TP sessions are named by identifiers that have local
significance only. That is, the same logical session will be
given different Session IDs by each end of the control connection
for the life of the session. When the L2TP control connection is
used for session establishment, Session IDs are selected and
exchanged as Local Session ID AVPs during the creation of a
session. The Session ID alone provides the necessary context for
all further packet processing, including the presence, size, and
value of the Cookie, the type of L2-Specific Sublayer, and the
type of payload being tunneled.
セッションのための非ゼロ識別子を含む32ビットの分野。 L2TPセッションはローカルの意味しか持っていない識別子によって命名されます。 すなわち、同じ論理的なセッションはセッションの寿命のためのコントロール接続の各端までに与えられた異なったSession IDになるでしょう。 セッション設立にL2TPコントロール接続を使用するとき、セッションの作成の間、Local Session ID AVPsとしてSession IDを選択して、交換します。 Session IDだけがさらなるすべてのパケット処理のための必要な文脈を提供します、Cookie、L2特有のSublayerのタイプ、およびトンネルを堀られるペイロードのタイプの存在、サイズ、および値を含んでいて。
Lau, et al. Standards Track [Page 16] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[16ページ]RFC3931L2TPv3 March 2005
Cookie
クッキー
The optional Cookie field contains a variable-length value
(maximum 64 bits) used to check the association of a received data
message with the session identified by the Session ID. The Cookie
MUST be set to the configured or signaled random value for this
session. The Cookie provides an additional level of guarantee
that a data message has been directed to the proper session by the
Session ID. A well-chosen Cookie may prevent inadvertent
misdirection of stray packets with recently reused Session IDs,
Session IDs subject to packet corruption, etc. The Cookie may
also provide protection against some specific malicious packet
insertion attacks, as described in Section 8.2.
任意のCookie分野はSession IDによって特定されるセッションに受信データメッセージの協会について問い合わせるのに使用される可変長の値(最大の64ビット)を含んでいます。 Cookieはこのセッションのために構成されたか合図された無作為の値に用意ができなければなりません。 Cookieはデータメッセージが適切なセッションまでSession IDによって指示されたという追加レベルの保証を提供します。 適切なCookieは最近再利用されたSession ID、パケット不正を条件としたSession IDなどがある迷っているパケットの不注意な誤まった指示を防ぐかもしれません。 また、Cookieはセクション8.2で説明されるようにいくつかの特定の悪意があるパケット挿入攻撃に対する保護を提供するかもしれません。
When the L2TP control connection is used for session
establishment, random Cookie values are selected and exchanged as
Assigned Cookie AVPs during session creation.
セッション設立にL2TPコントロール接続を使用するとき、セッション作成の間、Assigned Cookie AVPsとして無作為のCookie値を選択して、交換します。
4.1.1. L2TPv3 over IP
4.1.1. IPの上のL2TPv3
L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol ID 115.
IP(両方のバージョン)の上のL2TPv3はIANAによって割り当てられたIPプロトコルID115を利用します。
4.1.1.1. L2TPv3 Session Header Over IP
4.1.1.1. IPの上のL2TPv3セッションヘッダー
Unlike L2TP over UDP, the L2TPv3 session header over IP is free of any restrictions imposed by coexistence with L2TPv2 and L2F. As such, the header format has been designed to optimize packet processing. The following session header format is utilized when operating L2TPv3 over IP:
UDPの上のL2TPと異なって、IPの上のL2TPv3セッションヘッダーには、L2TPv2とL2Fとの共存で課された少しの制限もありません。 そういうものとして、ヘッダー形式は、パケット処理を最適化するように設計されています。 IPの上でL2TPv3を操作するとき、以下のセッションヘッダー形式は利用されています:
Figure 4.1.1.1: L2TPv3 Session Header Over IP
図4.1 .1 .1、: IPの上のL2TPv3セッションヘッダー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クッキー(任意の、そして、最大の64ビット)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID and Cookie fields are as defined in Section 4.1. The Session ID of zero is reserved for use by L2TP control messages (see Section 4.1.1.2).
Session IDとCookie分野がセクション4.1で定義されるようにあります。 セクション4.1を見てください。ゼロのSession IDが使用のためにL2TPコントロールメッセージによって予約される、(.1 .2)。
Lau, et al. Standards Track [Page 17] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[17ページ]RFC3931L2TPv3 March 2005
4.1.1.2. L2TP Control and Data Traffic over IP
4.1.1.2. IPの上のL2TPコントロールとデータ通信量
Unlike L2TP over UDP, which uses the T bit to distinguish between L2TP control and data packets, L2TP over IP uses the reserved Session ID of zero (0) when sending control messages. It is presumed that checking for the zero Session ID is more efficient -- both in header size for data packets and in processing speed for distinguishing between control and data messages -- than checking a single bit.
(0) コントロールメッセージを送るとき、UDPの上のL2TPと異なって、IPの上のL2TPはゼロの予約されたSession IDを使用します。UDPは、L2TPコントロールとデータ・パケットを見分けるのにTビットを使用します。 それがその照合であると推定される、Session IDのゼロを合わせてください、シングルをチェックするより効率的な(データ・パケットのためのヘッダーサイズとコントロールとデータメッセージを見分けるための処理速度における両方)ビットはそうです。
The entire control message header over IP, including the zero session ID, appears as follows:
全体が、以下の通りIP、ゼロを含んでいる上のメッセージヘッダーのためにセッションIDを制御して、現れます:
Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
図4.1 .1 .2、: IPの上のL2TPv3コントロールメッセージヘッダー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (ゼロの32ビット) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|x|x|x|x|x|x| Ver| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロール接続ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ナノ秒| Nr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Named fields are as defined in Section 3.2.1. Note that the Length field is still calculated from the beginning of the control message header, beginning with the T bit. It does NOT include the "(32 bits of zeros)" depicted above.
命名された分野がセクション3.2.1で定義されるようにあります。 Length分野がコントロールメッセージヘッダーの始まりからまだ計算されていることに注意してください、Tビットで始まって。 それは上に表現された「(ゼロの32ビット)」を含んでいません。
When operating directly over IP, L2TP packets lose the ability to take advantage of the UDP checksum as a simple packet integrity check, which is of particular concern for L2TP control messages. Control Message Authentication (see Section 4.3), even with an empty password field, provides for a sufficient packet integrity check and SHOULD always be enabled.
IPの上で直営するとき、L2TPパケットはL2TPコントロールメッセージに関する特別の心配のものである簡単なパケット保全チェックとしてUDPチェックサムを利用する能力を失います。 コントロールMessage Authentication(セクション4.3を見る)は人影のないパスワード欄があっても提供します。保全がチェックする十分なパケットとSHOULDに関しては、いつも可能にされてください。
4.1.2. L2TP over UDP
4.1.2. UDPの上のL2TP
L2TPv3 over UDP must consider other L2 tunneling protocols that may be operating in the same environment, including L2TPv2 [RFC2661] and L2F [RFC2341].
UDPの上のL2TPv3は同じ環境で作動しているかもしれない他のL2トンネリングプロトコルを考えなければなりません、L2TPv2[RFC2661]とL2F[RFC2341]を含んでいて。
While there are efficiencies gained by running L2TP directly over IP, there are possible side effects as well. For instance, L2TP over IP is not as NAT-friendly as L2TP over UDP.
IPの直接上にL2TPを実行することによって獲得された効率がありますが、また、可能な副作用があります。 例えば、IPの上のL2TPはUDPの上でNAT L2TPほどに優しくはありません。
Lau, et al. Standards Track [Page 18] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[18ページ]RFC3931L2TPv3 March 2005
4.1.2.1. L2TP Session Header Over UDP
4.1.2.1. UDPの上のL2TPセッションヘッダー
The following session header format is utilized when operating L2TPv3 over UDP:
UDPの上でL2TPv3を操作するとき、以下のセッションヘッダー形式は利用されています:
Figure 4.1.2.1: L2TPv3 Session Header over UDP
図4.1 .2 .1、: UDPの上のL2TPv3セッションヘッダー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|x|x|x|x|x|x|x|x|x|x|x| Ver| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クッキー(任意の、そして、最大の64ビット)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 0, indicating that this is a data message.
これがデータメッセージであることを示して、Tビットを0に設定しなければなりません。
The x bits and Reserved field are reserved for future extensions. All reserved values MUST be set to 0 on outgoing messages and ignored on incoming messages.
xビットとReserved分野は今後の拡大のために予約されます。 すべての予約された値を送信されるメッセージに0に設定されて、入力メッセージで無視しなければなりません。
The Ver field MUST be set to 3, indicating an L2TPv3 message.
L2TPv3メッセージを示して、Ver分野を3に設定しなければなりません。
Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2 [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, for UDP mode on a system that supports both versions of L2TP, it is important that the Ver field be inspected first to determine the Version of the header before acting upon any of these bits.
L2TPv3で予約されるように初期のビット1、4、6、および7がL2TPv2[RFC2661]に意味を持って、推奨しなくて、著しいことに注意してください。 したがって、L2TPの両方のバージョンをサポートするシステムの上のUDPモードにおいて、Ver分野が最初に、これらのビットのどれかに作用する前にヘッダーのバージョンを決定するために点検されるのは、重要です。
The Session ID and Cookie fields are as defined in Section 4.1.
Session IDとCookie分野がセクション4.1で定義されるようにあります。
4.1.2.2. UDP Port Selection
4.1.2.2. UDPポート選択
The method for UDP Port Selection defined in this section is identical to that defined for L2TPv2 [RFC2661].
このセクションで定義されたUDP Port SelectionのためのメソッドはL2TPv2[RFC2661]のために定義されたそれと同じです。
When negotiating a control connection over UDP, control messages MUST be sent as UDP datagrams using the registered UDP port 1701 [RFC1700]. The initiator of an L2TP control connection picks an available source UDP port (which may or may not be 1701) and sends to the desired destination address at port 1701. The recipient picks a free port on its own system (which may or may not be 1701) and sends its reply to the initiator's UDP port and address, setting its own source port to the free port it found.
UDPの上のコントロール接続を交渉するとき、1701[RFC1700]の登録されたUDPポートを使用して、UDPデータグラムとしてコントロールメッセージを送らなければなりません。 L2TPコントロール接続の創始者は、ポート(1701であるかもしれない)を利用可能なソースUDPに選んで、ポート1701の必要な送付先アドレスに発信します。 受取人は、それ自身のシステム(1701であるかもしれない)の上で自由港を選んで、創始者のUDPポートとアドレスに回答を送ります、それが見つけた自由港にそれ自身のソースポートを設定して。
Lau, et al. Standards Track [Page 19] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[19ページ]RFC3931L2TPv3 March 2005
Any subsequent traffic associated with this control connection (either control traffic or data traffic from a session established through this control connection) must use these same UDP ports.
このコントロール接続(このコントロール接続で確立されたセッションからのコントロールトラフィックかデータ通信量のどちらか)に関連しているどんなその後のトラフィックもこれらの同じUDPポートを使用しなければなりません。
It has been suggested that having the recipient choose an arbitrary source port (as opposed to using the destination port in the packet initiating the control connection, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementations should consider the potential implication of this capability before choosing an arbitrary source port. A NAT device that can pass TFTP traffic with variant UDP ports should be able to pass L2TP UDP traffic since both protocols employ similar policies with regard to UDP port selection.
受取人に任意のソースポート(コントロール接続、すなわち、1701を開始しながらパケットで仕向港を使用することと対照的に)を選ばせるのにL2TPがいくつかのNATデバイスを横断するのが、より難しくなるかもしれないことが提案されました。 任意のソースポートを選ぶ前に、実装はこの能力の潜在的含意を考えるべきです。 異形UDPポートがあるトラフィックが渡すことができるべきであるTFTPに両方のプロトコル以来のL2TP UDPトラフィックを通過できるNATデバイスはUDPポート選択に関して同様の方針を使います。
4.1.2.3. UDP Checksum
4.1.2.3. UDPチェックサム
The tunneled frames that L2TP carry often have their own checksums or integrity checks, rendering the UDP checksum redundant for much of the L2TP data message contents. Thus, UDP checksums MAY be disabled in order to reduce the associated packet processing burden at the L2TP endpoints.
L2TPが運ぶトンネルを堀られたフレームがしばしばそれら自身のチェックサムを持っているか、または保全はチェックします、UDPチェックサムをL2TPデータメッセージ内容の多くに余分にして。 したがって、UDPチェックサムは、L2TP終点で関連パケット処理負担を減少させるために無効にされるかもしれません。
The L2TP header itself does not have its own checksum or integrity check. However, use of the L2TP Session ID and Cookie pair guards against accepting an L2TP data message if corruption of the Session ID or associated Cookie has occurred. When the L2-Specific Sublayer is present in the L2TP header, there is no built-in integrity check for the information contained therein if UDP checksums or some other integrity check is not employed. IPsec (see Section 4.1.3) may be used for strong integrity protection of the entire contents of L2TP data messages.
L2TPヘッダー自体はそれ自身のチェックサムか保全をチェックさせません。 しかしながら、L2TP Session IDとCookie組の使用は、Session IDか関連Cookieの不正が起こったならL2TPデータメッセージを受け入れないように警備されます。 L2特有のSublayerがL2TPヘッダーに存在しているとき、チェックサムかある他の保全がチェックするUDPが採用していないならそこに含まれた情報のためのどんな内蔵の保全チェックもありません。 IPsec(セクション4.1.3を見る)はL2TPデータメッセージの全体のコンテンツの強い保全保護に使用されるかもしれません。
UDP checksums MUST be enabled for L2TP control messages.
L2TPコントロールメッセージのためにUDPチェックサムを可能にしなければなりません。
4.1.3. L2TP and IPsec
4.1.3. L2TPとIPsec
The L2TP data channel does not provide cryptographic security of any kind. If the L2TP data channel operates over a public or untrusted IP network where privacy of the L2TP data is of concern or sophisticated attacks against L2TP are expected to occur, IPsec [RFC2401] MUST be made available to secure the L2TP traffic.
L2TPデータ・チャンネルはどんな種類の暗号のセキュリティも提供しません。 L2TPデータ・チャンネルがL2TPデータのプライバシーが重要である公共の、または、信頼されていないIPネットワークの上で働いているか、または起こるとL2TPに対する洗練された攻撃を予想するなら、IPsec[RFC2401]をL2TPトラフィックを保証するために利用可能にしなければなりません。
Either L2TP over UDP or L2TP over IP may be secured with IPsec. [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 possesses identical characteristics to IPsec as L2TPv2 when running over UDP and implementations MUST follow the same recommendation. When operating over IP directly, [RFC3193] still applies, though references to UDP source and destination ports (in particular, those
UDPの上のL2TPかIPの上のL2TPのどちらかがIPsecと共に固定されるかもしれません。 [RFC3193]はL2TPv2を固定するためのお勧めのメソッドを定義します。 UDPと実装をひくとき、L2TPv2が同じ推薦に続かなければならないのに従って、L2TPv3は同じ特性をIPsecに持っています。 UDPソースと仕向港が言及ですが、IPの上で直接作動するとき[RFC3193]がまだ適用している、(特にそれら
Lau, et al. Standards Track [Page 20] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[20ページ]RFC3931L2TPv3 March 2005
in Section 4, "IPsec Filtering details when protecting L2TP") may be ignored. Instead, the selectors used to identify L2TPv3 traffic are simply the source and destination IP addresses for the tunnel endpoints together with the L2TPv3 IP protocol type, 115.
中、セクション4、「IPsec FilteringはL2TPを保護しながら、いつかを詳しく述べる」) 無視されるかもしれません。 L2TPv3トラフィックを特定するのに使用されるセレクタは、代わりに、単にIPが115歳のL2TPv3IPプロトコルタイプと共にトンネル終点に演説するソースと目的地です。
In addition to IP transport security, IPsec defines a mode of operation that allows tunneling of IP packets. The packet-level encryption and authentication provided by IPsec tunnel mode and that provided by L2TP secured with IPsec provide an equivalent level of security for these requirements.
IP輸送セキュリティに加えて、IPsecはトンネルを堀るのを許容するIPパケットの運転モードを定義します。 パケット・レベル暗号化、IPsecトンネルモードで提供された認証、およびIPsecと共に固定されたL2TPによって提供されたそれは同等なレベルのセキュリティをこれらの要件に提供します。
IPsec also defines access control features that are required of a compliant IPsec implementation. These features allow filtering of packets based upon network and transport layer characteristics such as IP address, ports, etc. In the L2TP tunneling model, analogous filtering may be performed at the network layer above L2TP. These network layer access control features may be handled at an LCCE via vendor-specific authorization features, or at the network layer itself by using IPsec transport mode end-to-end between the communicating hosts. The requirements for access control mechanisms are not a part of the L2TP specification, and as such, are outside the scope of this document.
また、IPsecは対応するIPsec実装が要求されるアクセス制御機能を定義します。 これらの特徴はネットワークに基づくパケットのフィルタリングとIPアドレスなどのトランスポート層の特性、ポートなどを許容します。 L2TPトンネリングモデルでは、類似のフィルタリングはL2TPの上でネットワーク層で実行されるかもしれません。 これらのネットワーク層アクセス制御機能はベンダー特有の承認機能を通したLCCEにおいて、または、交信しているホストの間のIPsecの交通機関の終わりからエンドを使用するのによるネットワーク層自体において扱われるかもしれません。 このドキュメントの範囲の外にアクセス管理機構がL2TP仕様の一部でなく、およびそのようなものとしての要件があります。
Protecting the L2TP packet stream with IPsec does, in turn, also protect the data within the tunneled session packets while transported from one LCCE to the other. Such protection must not be considered a substitution for end-to-end security between communicating hosts or applications.
また、IPsecと共にL2TPパケットストリームを保護すると、データは1LCCEからもう片方まで輸送されている間、トンネルを堀られたセッションパケットの中に順番に保護されます。 ホストかアプリケーションを伝えることの間の終わりから終わりへのセキュリティへの代替であるとそのような保護を考えてはいけません。
4.1.4. IP Fragmentation Issues
4.1.4. IP断片化問題
Fragmentation and reassembly in network equipment generally require significantly greater resources than sending or receiving a packet as a single unit. As such, fragmentation and reassembly should be avoided whenever possible. Ideal solutions for avoiding fragmentation include proper configuration and management of MTU sizes among the Remote System, the LCCE, and the IP network, as well as adaptive measures that operate with the originating host (e.g., [RFC1191], [RFC1981]) to reduce the packet sizes at the source.
一般に、ネットワーク装置の断片化と再アセンブリは単一の単位としてパケットを送るか、または受けるよりかなりすばらしいリソースを必要とします。 そういうものとして、可能であるときはいつも、断片化と再アセンブリは避けられるべきです。 断片化を避ける理想的な解決はRemote System、LCCE、およびIPネットワークの中にMTUサイズの適切な構成と管理を含んでいます、ソースにおけるパケットサイズを減少させるために送信元ホスト(例えば、[RFC1191]、[RFC1981])と共に作動する適応型の測定と同様に。
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation. This creates two (or more) L2TP packets, each
L2TPでそれをカプセル化する前に、LCCE MAYはパケットを断片化します。 例えば、IPv4パケットが関連縁どり、L2TP、およびIPがあるカプセル化の後にLCCE同輩に向かって利用可能な経路MTUをうまくはめ込まないRemote SystemからLCCEに到着するなら、地方のLCCEはトンネルカプセル化の前にIPv4断片化をパケットに実行するかもしれません。 これはそれぞれ2つ(さらに)のL2TPパケットを作成します。
Lau, et al. Standards Track [Page 21] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[21ページ]RFC3931L2TPv3 March 2005
carrying an IPv4 fragment with its associated framing. This ultimately has the effect of placing the burden of fragmentation on the LCCE, while reassembly occurs on the IPv4 destination host.
関連縁どりでIPv4断片を運びます。 これには、結局、断片化の負担をLCCEにかけるという効果があります、再アセンブリはIPv4あて先ホストの上に現れますが。
If an IPv6 packet arrives at an LCCE from a Remote System that, after encapsulation with associated framing, L2TP and IP, does not fit in the available path MTU towards its L2TP peer, the Generic Packet Tunneling specification [RFC2473], Section 7.1 SHOULD be followed. In this case, the LCCE should either send an ICMP Packet Too Big message to the data source, or fragment the resultant L2TP/IP packet (for reassembly by the L2TP peer).
IPv6パケットがLCCEに到着するなら、関連縁どり、L2TP、およびIPがあるカプセル化の後にセクション7.1 L2TP同輩、Generic Packet Tunneling仕様[RFC2473]、SHOULDに向かって利用可能な経路MTUをうまくはめ込まないRemote Systemから、続かれてください。 この場合、LCCEはICMP Packet Too Bigメッセージをデータ送信端末に送るはずであるか、または結果のL2TP/IPパケットを断片化するはずです(L2TP同輩による再アセンブリのために)。
If the amount of traffic requiring fragmentation and reassembly is rather light, or there are sufficiently optimized mechanisms at the tunnel endpoints, fragmentation of the L2TP/IP packet may be sufficient for accommodating mismatched MTUs that cannot be managed by more efficient means. This method effectively emulates a larger MTU between tunnel endpoints and should work for any type of L2- encapsulated packet. Note that IPv6 does not support "in-flight" fragmentation of data packets. Thus, unlike IPv4, the MTU of the path towards an L2TP peer must be known in advance (or the last resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6 fragmentation may occur at the LCCE.
断片化と再アセンブリを必要とするトラフィックの量がかなり軽いか、または十分最適化されたメカニズムがトンネル終点にあれば、L2TP/IPパケットの断片化は、より効率的な手段で対処できないミスマッチしているMTUsを収容するのに十分であるかもしれません。 このメソッドは、事実上、トンネル終点の間で、より大きいMTUを見習って、パケットであるとカプセル化されたL2のどんなタイプのためにも利くべきです。 IPv6がデータ・パケットの「機内」の断片化をサポートしないことに注意してください。 したがって、IPv4と異なって、あらかじめ(または、最低1280バイトのIPv6MTUが利用した切り札)、IPv6断片化がLCCEに起こることができるように、L2TP同輩に向かった経路のMTUを知っていなければなりません。
In summary, attempting to control the source MTU by communicating with the originating host, forcing that an MTU be sufficiently large on the path between LCCE peers to tunnel a frame from any other interface without fragmentation, fragmenting IP packets before encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP packet between the tunnel endpoints, are all valid methods for managing MTU mismatches. Some are clearly better than others depending on the given deployment. For example, a passive monitoring application using L2TP would certainly not wish to have ICMP messages sent to a traffic source. Further, if the links connecting a set of LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that the MTU of all links being tunneled by L2TP have smaller MTUs (e.g., 1500 bytes), then any IP fragmentation and reassembly enabled on the participating LCCEs would never be utilized. An implementation MUST implement at least one of the methods described in this section for managing mismatched MTUs, based on careful consideration of how the final product will be deployed.
L2TP/IPがあるカプセル化、またはトンネル終点の間で結果のL2TP/IPパケットを断片化するのが、すべてMTUミスマッチを管理するための有効なメソッドである前でIPパケットを断片化して、いかなる他のインタフェースからも断片化なしでフレームにトンネルを堀るためにMTUがLCCE同輩の間の経路で十分大きいように強制して、送信元ホストとコミュニケートすることによってソースMTUを制御するのを試みる概要で。 或るものは与えられた展開を当てにする他のものより明確に良いです。 例えば、確かに、L2TPを使用する受け身の監視用途はICMPメッセージをトラフィックソースに送って頂きたくないでしょう。 さらに、LCCEsの1セットを接続するリンクが非常に大きいMTU(例えば、SDH/Sonet)を持っていて、L2TPによってトンネルを堀られるすべてのリンクのMTUには、より小さいMTUs(例えば、1500バイト)があるのが知られているなら、参加しているLCCEsで有効にされたどんなIP断片化と再アセンブリも決して利用されません。 実装は少なくともミスマッチしているMTUsを管理するためにこのセクションで説明されたメソッドの1つを実装しなければなりません、完成品がどう配布されるかに関する熟慮に基づいて。
L2TP-specific fragmentation and reassembly methods, which may or may not depend on the characteristics of the type of link being tunneled (e.g., judicious packing of ATM cells), may be defined as well, but these methods are outside the scope of this document.
L2TP特有の断片化と再アセンブリメソッド(トンネルを堀られるリンク(例えば、ATMセルの賢明なパッキング)のタイプの特性に依存するかもしれない)はまた、定義されるかもしれませんが、このドキュメントの範囲の外にこれらのメソッドがあります。
Lau, et al. Standards Track [Page 22] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[22ページ]RFC3931L2TPv3 March 2005
4.2. Reliable Delivery of Control Messages
4.2. コントロールメッセージの信頼できる配信
L2TP provides a lower level reliable delivery service for all control messages. The Nr and Ns fields of the control message header (see Section 3.2.1) belong to this delivery mechanism. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages. The reliable control messaging mechanism is a sliding window mechanism that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for each control connection.
L2TPはすべてのコントロールメッセージのための下のレベル信頼できる配信サービスを提供します。 コントロールメッセージヘッダー(セクション3.2.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 ACK message), receipt of duplicate messages MUST be acknowledged by the reliable delivery mechanism. This acknowledgment may either piggybacked on a message in queue or sent explicitly via an ACK message.
メッセージ通番(Ns)は0時に始まります。 一連番号の次の増分と共にそれぞれのその後のメッセージを送ります。 一連番号はその結果、自由な稼働カウンタが法65536を表したということです。 値が最後の容認された数と前の32767の値の範囲にあるなら、受信されたメッセージのヘッダーの一連番号は最後の容認されたより数であると考えられます、包括的です。 例えば0〜15、および32784〜65535の一連番号がある当時のメッセージは最後の容認された一連番号が15であったなら以下か等しいと考えられるでしょう。 そのようなメッセージは既に受け取られて、処理から無視されたメッセージの写しであると考えられるでしょう。 しかしながら、すべてのメッセージが適切(特に無くなっているACKメッセージの場合で)に承認されるのを確実にするために、信頼できる配信メカニズムで写しメッセージの領収書を受け取ったことを知らせなければなりません。 待ち行列におけるメッセージで便乗するか、またはACKメッセージで明らかに送って、この承認はそうするかもしれません。
All control messages take up one slot in the control message sequence number space, except the ACK message. Thus, Ns is not incremented after an ACK message is sent.
ACKメッセージを除いて、すべてのコントロールメッセージがコントロールメッセージ通番スペースの1つのスロットを取ります。 したがって、ACKメッセージを送った後にNsは増加していません。
The last received message number, Nr, is used to acknowledge messages received by an L2TP peer. It contains the sequence number of the message the peer expects to receive next (e.g., the last Ns of a non-ACK message received plus 1, modulo 65536). While the Nr in a received ACK message is used to flush messages from the local retransmit queue (see below), the Nr of the next message sent is not updated by the Ns of the ACK message. Nr SHOULD be sanity-checked before flushing the retransmit queue. For instance, if the Nr received in a control message is greater than the last Ns sent plus 1 modulo 65536, the control message is clearly invalid.
最後の容認されたメッセージ番号(Nr)は、L2TP同輩によって受け取られたメッセージを承認するのに使用されます。 それは同輩が次に受け取ると予想するメッセージの一連番号を含んでいます(例えば、非ACKメッセージの最後のNsはそのうえ、1を受け取りました、法65536)。 受信されたACKメッセージのNrは地方の再送キューからメッセージを洗い流すのに使用されますが(以下を見てください)、送られた次のメッセージのNrはACKメッセージのNsによってアップデートされません。 Nr SHOULD、正気で、再送キューを洗い流す前に、チェックになってください。 例えば、コントロールメッセージに受け取られたNrが最後のNsが法65536をプラス1に送ったより大きいなら、コントロールメッセージは明確に無効です。
The reliable delivery mechanism at a receiving peer is responsible for making sure that control messages are delivered in order and without duplication to the upper level. Messages arriving out-of- order may be queued for in-order delivery when the missing messages
受信同輩の信頼できる配信メカニズムはコントロールメッセージが整然とした状態で提供されるのを確実にして、複製なしで上側のレベルに原因となります。 外に到着するメッセージ、-、-なくなったメッセージであるときに、オーダーはオーダーにおける配送のために列に並ばせられるかもしれません。
Lau, et al. Standards Track [Page 23] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[23ページ]RFC3931L2TPv3 March 2005
are received. Alternatively, they may be discarded, thus requiring a retransmission by the peer. When dropping out-of-order control packets, Nr MAY be updated before the packet is discarded.
受け取ります。 あるいはまた、それらは捨てられて、その結果、同輩は「再-トランスミッション」を必要とするかもしれません。 故障していた状態で低下するときにはパケットを制御してください、そして、パケットが捨てる前にNrをアップデートしてもよいです。
Each control connection maintains a queue of control messages to be transmitted to its peer. The message at the front of the queue is sent with a given Ns value and is held until a control message arrives from the peer in which the Nr field indicates receipt of this message. After a period of time (a recommended default is 1 second but SHOULD be configurable) passes without acknowledgment, the message is retransmitted. The retransmitted message contains the same Ns value, but the Nr value MUST be updated with the sequence number of the next expected message.
それぞれのコントロール接続は同輩に伝えられるべきコントロールメッセージの待ち行列を維持します。 待ち行列の前部のメッセージは、与えられたNs値と共に送られて、コントロールメッセージがNr分野がこのメッセージの領収書を示す同輩から到着するまで、保持されます。 期間の後、(お勧めのデフォルトが1秒にもかかわらず、SHOULDである、構成可能であってください、)、承認のないパス、メッセージは再送されます。 再送されたメッセージは同じNs値を含んでいますが、次の予想されたメッセージの一連番号でNr値をアップデートしなければなりません。
Each subsequent retransmission of a message MUST employ an exponential backoff interval. Thus, if the first retransmission occurred after 1 second, the next retransmission should occur after 2 seconds has elapsed, then 4 seconds, etc. An implementation MAY place a cap upon the maximum interval between retransmissions. This cap SHOULD be no less than 8 seconds per retransmission. If no peer response is detected after several retransmissions (a recommended default is 10, but MUST be configurable), the control connection and all associated sessions MUST be cleared. As it is the first message to establish a control connection, the SCCRQ MAY employ a different retransmission maximum than other control messages in order to help facilitate failover to alternate LCCEs in a timely fashion.
メッセージのそれぞれのその後の「再-トランスミッション」は指数のbackoff間隔を使わなければなりません。 したがって、最初の「再-トランスミッション」が1秒後に現れるなら、次に、2秒が4秒経過したなど後に次の「再-トランスミッション」は現れるでしょうに。 実装は「再-トランスミッション」の最大の間隔に上限を設けるかもしれません。 この上限SHOULDは1「再-トランスミッション」あたり8秒のようにそうです。 同輩応答が全く数個の「再-トランスミッション」の後に検出されないなら(お勧めのデフォルトは、10ですが、構成可能であるに違いありません)、コントロール接続とすべての合同会議をきれいにしなければなりません。 それがコントロール接続を確立する最初のメッセージであるので、SCCRQ MAYはコントロールが直ちにLCCEsを交替するためにフェイルオーバーを容易にするのを助けるために通信させるもう一方と異なった「再-トランスミッション」最大を使います。
When a control connection is being shut down for reasons other than loss of connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8 + 8... seconds), or until the StopCCN message itself has been acknowledged.
コントロール接続が接続性の損失以外の理由で止められているとき、最終的なメッセージStopCCNメッセージを送った後に完全な再送信間隔(例えば、1+2+4+8+8…秒)、またはStopCCNメッセージ自体が承認されるまで、状態と信頼できる配信メカニズムを維持されて、運用しなければなりません。
A sliding window mechanism is used for control message transmission and retransmission. Consider two peers, A and B. Suppose A specifies a Receive Window Size AVP with a value of N in the SCCRQ or SCCRP message. B is now allowed to have a maximum of N outstanding (i.e., unacknowledged) control messages. Once N messages have been sent, B must wait for an acknowledgment from A that advances the window before sending new control messages. An implementation may advertise a non-zero receive window as small or as large as it wishes, depending on its own ability to process incoming messages before sending an acknowledgement. Each peer MUST limit the number of unacknowledged messages it will send before receiving an acknowledgement by this Receive Window Size. The actual internal
引窓メカニズムはコントロールのメッセージ送信と「再-トランスミッション」に使用されます。 2人の同輩、Aを考えてください。そうすれば、Nの値がSCCRQかSCCRPメッセージにある状態で、B.Suppose AはReceive Window Size AVPを指定します。 Bは現在、最大N傑出している(すなわち、不承認の)コントロールメッセージを持つことができます。 いったんNメッセージを送ると、Bは新しいコントロールメッセージを送る前に窓を進めるAから承認を待たなければなりません。 願っているのと同じくらい小さいか同じくらい大きいとして窓を受けて、承認を送る前に入力メッセージを処理するそれ自身の能力によって、実装は非ゼロの広告を出すかもしれません。 各同輩はこのReceive Window Sizeによる承認を受ける前にそれが送る不承認のメッセージの数を制限しなければなりません。 実際のインターナル
Lau, et al. Standards Track [Page 24] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[24ページ]RFC3931L2TPv3 March 2005
unacknowledged message send-queue depth may be further limited by local resource allocation or by dynamic slow-start and congestion- avoidance mechanisms.
不承認のメッセージ送信キューの深さはローカル資源配分かダイナミックな遅れた出発と混雑回避メカニズムによってさらに制限されるかもしれません。
When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized. A recommended procedure is described in Appendix A. A peer MAY drop messages, but MUST NOT actively delay acknowledgment of messages as a technique for flow control of control messages. Appendix B contains examples of control message transmission, acknowledgment, and retransmission.
再送するときには、利用されていて、メッセージ、遅れた出発、および輻輳回避窓の調整手順SHOULDを制御してください。 お勧めの手順は、Appendix A.A同輩5月の通信筒で説明されますが、コントロールメッセージのフロー制御のためのテクニックとして活発にメッセージの承認を遅らせてはいけません。 付録Bはコントロールのメッセージ送信、承認、および「再-トランスミッション」に関する例を含んでいます。
4.3. Control Message Authentication
4.3. コントロール通報認証
L2TP incorporates an optional authentication and integrity check for all control messages. This mechanism consists of a computed one-way hash over the header and body of the L2TP control message, a pre- configured shared secret, and a local and remote nonce (random value) exchanged via the Control Message Authentication Nonce AVP. This per-message authentication and integrity check is designed to perform a mutual authentication between L2TP nodes, perform integrity checking of all control messages, and guard against control message spoofing and replay attacks that would otherwise be trivial to mount.
L2TPはすべてのコントロールメッセージのための任意の認証と保全チェックを取り入れます。 このメカニズムはL2TPコントロールメッセージ、あらかじめ構成された共有秘密キー、およびControl Message Authentication Nonce AVPを通して交換されたローカルの、そして、リモートな一回だけ(無作為の値)のヘッダーとボディーの上で計算された一方向ハッシュから成ります。 この通報認証と保全チェックは、コントロールメッセージスプーフィングとそうでなければ上がるように些細な反射攻撃に対してL2TPノードの間の互いの認証を実行して、すべてのコントロールメッセージの保全の照合を実行して、警備するように設計されています。
At least one shared secret (password) MUST exist between communicating L2TP nodes to enable Control Message Authentication. See Section 5.4.3 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.
Control Message Authenticationを有効にするためにL2TPノードを伝えるとき、少なくとも1つの共有秘密キー(パスワード)が存在しなければなりません。 Message Digestの計算とControl Message Authentication NonceとMessage Digest AVPsの構造に関する詳細に関してセクション5.4.3を見てください。
L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a shared secret and one-way hash calculation. The principal difference is that, instead of computing the hash over selected contents of a received control message (e.g., the Challenge AVP and Message Type) as in L2TPv2, the entire message is used in the hash in L2TPv3. In addition, instead of including the hash digest in just the SCCRP and SCCCN messages, it is now included in all L2TP messages.
L2TPv3 Control Message AuthenticationはL2TPv2[RFC2661]トンネルAuthenticationと共有秘密キーと一方向ハッシュ計算を使用で同様です。 主要な違いはL2TPv2のように受信されたコントロールメッセージ(例えば、Challenge AVPとMessage Type)の選択されたコンテンツに関してハッシュを計算することの代わりに全体のメッセージがL2TPv3のハッシュに使用されるということです。 さらに、まさしくSCCRPとSCCCNメッセージにハッシュダイジェストを含んでいることの代わりにそれは現在、すべてのL2TPメッセージに含まれています。
The Control Message Authentication mechanism is optional, and may be disabled if both peers agree. For example, if IPsec is already being used for security and integrity checking between the LCCEs, the function of the L2TP mechanism becomes redundant and may be disabled.
Control Message Authenticationメカニズムは、任意であり、両方の同輩が同意するなら、障害があるかもしれません。 例えば、IPsecがLCCEsの間でチェックするセキュリティと保全に既に使用されているなら、L2TPメカニズムの機能は、余分になって、無効にされるかもしれません。
Presence of the Control Message Authentication Nonce AVP in an SCCRQ or SCCRP message serves as indication to a peer that Control Message Authentication is enabled. If an SCCRQ or SCCRP contains a Control Message Authentication Nonce AVP, the receiver of the message MUST
SCCRQかSCCRPメッセージでのControl Message Authentication Nonce AVPの存在はControl Message Authenticationが有効にされるという同輩への指示として機能します。 SCCRQかSCCRPがControl Message Authentication Nonce AVPを含んでいるなら、メッセージの受信機は含まなければなりません。
Lau, et al. Standards Track [Page 25] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[25ページ]RFC3931L2TPv3 March 2005
respond with a Message Digest AVP in all subsequent messages sent. Control Message Authentication is always bidirectional; either both sides participate in authentication, or neither does.
その後のメッセージが送ったすべてのMessage Digest AVPと共に応じてください。 コントロールMessage Authenticationはいつも双方向です。 両側は認証に参加するか、またはどちらも参加します。
If Control Message Authentication is disabled, the Message Digest AVP still MAY be sent as an integrity check of the message. The integrity check is calculated as in Section 5.4.3, with an empty zero-length shared secret, local nonce, and remote nonce. If an invalid Message Digest is received, it should be assumed that the message has been corrupted in transit and the message dropped accordingly.
Control Message Authenticationは障害があるなら、メッセージの保全チェックとしてまだMessage Digest AVPを送るかもしれません。 保全チェックは空のゼロ・レングス共有秘密キー、地方の一回だけ、およびリモート一回だけがあるセクション5.4.3のように計算されます。 無効のMessage Digestが受け取られているなら、メッセージがそれに従って、下げられたトランジットとメッセージで腐敗していると思われるべきです。
Implementations MAY rate-limit control messages, particularly SCCRQ messages, upon receipt for performance reasons or for protection against denial of service attacks.
実装はレートリミット制御メッセージ、特にサービス不能攻撃に対する性能理由か保護のための領収書に関するSCCRQメッセージがそうするかもしれません。
4.4. Keepalive (Hello)
4.4. Keepalive(こんにちは)
L2TP employs a keepalive mechanism to detect loss of connectivity between a pair of LCCEs. This is accomplished by injecting Hello control messages (see Section 6.5) after a period of time has elapsed since the last data message or control message was received on an L2TP session or control connection, respectively. As with any other control message, if the Hello message is not reliably delivered, the sending LCCE declares that the control connection is down and resets its state for the control connection. This behavior ensures that a connectivity failure between the LCCEs is detected independently by each end of a control connection.
L2TPは、1組のLCCEsの間の接続性の損失を検出するのにkeepaliveメカニズムを使います。 これは、最後のデータメッセージかコントロールメッセージをL2TPセッションかコントロール接続に受け取って以来期間が経過している後にそれぞれ、Helloコントロールメッセージ(セクション6.5を見る)を注入することによって、達成されます。 いかなる他のコントロールメッセージのようにも、Helloメッセージが確かに提供されないなら、発信しているLCCEはコントロール接続が下がっていると宣言して、コントロール接続のために状態をリセットします。 この振舞いは、LCCEsの間の接続性失敗がコントロール接続の各端までに独自に検出されるのを確実にします。
Since the control channel is operated in-band with data traffic over the PSN, this single mechanism can be used to infer basic data connectivity between a pair of LCCEs for all sessions associated with the control connection.
制御チャンネルがPSNの上にデータ通信量がある状態でバンドで手術されるので、コントロール接続に関連しているすべてのセッションのために1組のLCCEsの間の基礎データの接続性を推論するのにこのただ一つのメカニズムを使用できます。
Periodic keepalive for the control connection MUST be implemented by sending a Hello if a period of time (a recommended default is 60 seconds, but MUST be configurable) has passed without receiving any message (data or control) from the peer. An LCCE sending Hello messages across multiple control connections between the same LCCE endpoints MUST employ a jittered timer mechanism to prevent grouping of Hello messages.
期間(お勧めのデフォルトは、60秒ですが、構成可能であるに違いない)が同輩からどんなメッセージ(データかコントロール)も受け取らないで経過したならHelloを送ることによって、コントロール接続のための周期的なkeepaliveを実装しなければなりません。 同じLCCE終点の間の複合管理接続の向こう側のHelloメッセージが分類するのを防ぐのにjitteredタイマメカニズムを使わなければならないHelloメッセージのLCCE送付。
4.5. Forwarding Session Data Frames
4.5. 推進セッションデータフレーム
Once session establishment is complete, circuit frames are received at an LCCE, encapsulated in L2TP (with appropriate attention to framing, as described in documents for the particular pseudowire type), and forwarded over the appropriate session. For every
セッション設立がいったん完全になると、回路フレームをLCCEに受け取って、L2TP(特定のpseudowireタイプのためにドキュメントで説明されるように縁どることに関する適切な注意がある)でカプセル化して、適切なセッションの間、進めます。 あらゆる
Lau, et al. Standards Track [Page 26] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[26ページ]RFC3931L2TPv3 March 2005
outgoing data message, the sender places the identifier specified in the Local Session ID AVP (received from peer during session establishment) in the Session ID field of the L2TP data header. In this manner, session frames are multiplexed and demultiplexed between a given pair of LCCEs. Multiple control connections may exist between a given pair of LCCEs, and multiple sessions may be associated with a given control connection.
発信データメッセージ、送付者はLocal Session ID AVP(同輩から、セッション設立の間、受信する)で指定された識別子をL2TPデータヘッダーのSession ID分野に置きます。 この様に、セッションフレームは、与えられた組のLCCEsの間で多重送信されて、反多重送信されます。 複合管理接続は与えられた組のLCCEsの間に存在するかもしれません、そして、複数のセッションが与えられたコントロール接続に関連しているかもしれません。
The peer LCCE receiving the L2TP data packet identifies the session with which the packet is associated by the Session ID in the data packet's header. The LCCE then checks the Cookie field in the data packet against the Cookie value received in the Assigned Cookie AVP during session establishment. It is important for implementers to note that the Cookie field check occurs after looking up the session context by the Session ID, and as such, consists merely of a value match of the Cookie field and that stored in the retrieved context. There is no need to perform a lookup across the Session ID and Cookie as a single value. Any received data packets that contain invalid Session IDs or associated Cookie values MUST be dropped. Finally, the LCCE either forwards the network packet within the tunneled frame (e.g., as an LNS) or switches the frame to a circuit (e.g., as an LAC).
L2TPデータ・パケットを受ける同輩LCCEがパケットがデータ・パケットのヘッダーでSession IDで関連しているセッションを特定します。 そして、LCCEはAssigned Cookie AVPのCookie対価領収に対してセッション設立の間、データ・パケットのCookie分野をチェックします。 implementersが、Session IDと、そのようなものとしてセッション文脈を調べるのがCookie分野と検索された文脈に保存されたその値のマッチから単に成った後にCookie分野チェックが起こることに注意するのは、重要です。 ただ一つの値としてSession IDとCookieの向こう側にルックアップを実行する必要は全くありません。 無効のSession IDか関連Cookie値を含むどんな受信データパケットも下げなければなりません。 最終的に、LCCEはトンネルを堀られたフレーム(例えば、LNSとしての)の中にネットワークパケットを送るか、または回路(例えば、LACとしての)にフレームを切り換えます。
4.6. Default L2-Specific Sublayer
4.6. デフォルトのL2特有の副層
This document defines a Default L2-Specific Sublayer format (see Section 3.2.2) that a pseudowire may use for features such as sequencing support, L2 interworking, OAM, or other per-data-packet operations. The Default L2-Specific Sublayer SHOULD be used by a given PW type to support these features if it is adequate, and its presence is requested by a peer during session negotiation. Alternative sublayers MAY be defined (e.g., an encapsulation with a larger Sequence Number field or timing information) and identified for use via the L2-Specific Sublayer Type AVP.
このドキュメントがサポート、L2の織り込むことを配列などなどのOAM、または他でpseudowireが特徴に使用するかもしれないDefault L2特有のSublayer書式(セクション3.2.2を見る)を定義する、-、データ・パケット、操作。 Default L2特有のSublayer SHOULD、それが適切であり、存在がセッション交渉の間、同輩によって要求されるなら与えられたPWタイプによって使用されて、これらの特徴をサポートしてください。 代替の副層は、定義されて(例えば、より大きいSequence Number分野かタイミング情報があるカプセル化)、使用のためにL2特有のSublayer Type AVPを通して特定されるかもしれません。
Figure 4.6: Default L2-Specific Sublayer Format
図4.6: デフォルトのL2特有の副層形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x|x|x|x|x| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S (Sequence) bit is set to 1 when the Sequence Number contains a valid number for this sequenced frame. If the S bit is set to zero, the Sequence Number contents are undefined and MUST be ignored by the receiver.
Sequence Numberがこの配列されたフレームの有効な数を含むとき、S(系列)ビットは1に設定されます。 Sビットがゼロに設定されるなら、Sequence Number内容を未定義であり、受信機で無視しなければなりません。
Lau, et al. Standards Track [Page 27] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[27ページ]RFC3931L2TPv3 March 2005
The Sequence Number field contains a free-running counter of 2^24 sequence numbers. If the number in this field is valid, the S bit MUST be set to 1. The Sequence Number begins at zero, which is a valid sequence number. (In this way, implementations inserting sequence numbers do not have to "skip" zero when incrementing.) The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding (2^23-1) values, inclusive.
Sequence Number分野は2^24の一連番号の自由な稼働カウンタを含んでいます。 この分野の数が有効であるなら、Sビットを1に設定しなければなりません。 Sequence Numberはゼロで始まります。(それは、有効な一連番号です)。 (増加しているとき、このように、一連番号を挿入する実装はゼロを「スキップする必要はありません」。) 値が最後の容認された数と(2^23-1)前の値の範囲にあるなら、受信されたメッセージのヘッダーの一連番号は最後の容認されたより数であると考えられます、包括的です。
4.6.1. Sequencing Data Packets
4.6.1. 配列データ・パケット
The Sequence Number field may be used to detect lost, duplicate, or out-of-order packets within a given session.
Sequence Number分野は、与えられたセッション以内に無くなっているか、写しの、または、故障しているパケットを検出するのに使用されるかもしれません。
When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP data channel, this part of the link has the characteristic of being able to reorder, duplicate, or silently drop packets. Reordering may break some non-IP protocols or L2 control traffic being carried by the link. Silent dropping or duplication of packets may break protocols that assume per-packet indications of error, such as TCP header compression. While a common mechanism for packet sequence detection is provided, the sequence dependency characteristics of individual protocols are outside the scope of this document.
L2フレームがL2TP過剰IPかL2TP過剰UDP/IPデータ・チャンネルの上まで運ばれます、リンクのこの部分には、追加注文にできることの特性があります、写しということである、または静かにパケットを下げると。 Reorderingはリンクによって運ばれるいくつかの非IPプロトコルかL2コントロールトラフィックを破るかもしれません。 パケットの静かな低下か複製がTCPヘッダー圧縮などの誤りの1パケットあたりのしるしを仮定するプロトコルを破るかもしれません。 パケット系列検出のための一般的なメカニズムを提供しますが、このドキュメントの範囲の外に個々のプロトコルの系列依存の特性があります。
If any protocol being transported by over L2TP data channels cannot tolerate misordering of data packets, packet duplication, or silent packet loss, sequencing may be enabled on some or all packets by using the S bit and Sequence Number field defined in the Default L2- Specific Sublayer (see Section 4.6). For a given L2TP session, each LCCE is responsible for communicating to its peer the level of sequencing support that it requires of data packets that it receives. Mechanisms to advertise this information during session negotiation are provided (see Data Sequencing AVP in Section 5.4.4).
L2TPデータ・チャンネルの上で輸送される何かプロトコルが、データ・パケット、パケット重複、または静かなパケット損失をmisorderingするのを許容できないなら、配列は、いくつかかすべてのパケットでDefault L2の特定のSublayerで定義されたSビットとSequence Number分野を使用することによって、可能にされるかもしれません(セクション4.6を見てください)。 与えられたL2TPセッションのために、それぞれのLCCEはそれが必要とするそれが受けるデータ・パケットの配列サポートのレベルを同輩に伝えるのに責任があります。 セッション交渉の間にこの情報の広告を出すメカニズムを提供します(セクション5.4.4でData Sequencing AVPを見てください)。
When determining whether a packet is in or out of sequence, an implementation SHOULD utilize a method that is resilient to temporary dropouts in connectivity coupled with high per-session packet rates. The recommended method is outlined in Appendix C.
パケットが実装か系列、実装から脱しているかを決定するとき、SHOULDは1セッションあたりの高いパケットレートに結びつけられた接続性で一時的な落第生にとって、弾力があるメソッドを利用します。 お勧めのメソッドはAppendix Cに概説されています。
4.7. L2TPv2/v3 Interoperability and Migration
4.7. L2TPv2/v3相互運用性と移行
L2TPv2 and L2TPv3 environments should be able to coexist while a migration to L2TPv3 is made. Migration issues are discussed for each media type in this section. Most issues apply only to implementations that require both L2TPv2 and L2TPv3 operation.
L2TPv3への移行が作られている間、L2TPv2とL2TPv3環境は共存できるべきです。 このセクションのそれぞれのメディアタイプのために移行問題について議論します。 ほとんどの問題がL2TPv2とL2TPv3操作の両方を必要とする実装だけに適用されます。
Lau, et al. Standards Track [Page 28] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[28ページ]RFC3931L2TPv3 March 2005
However, even L2TPv3-only implementations must at least be mindful of these issues in order to interoperate with implementations that support both versions.
しかしながら、L2TPv3だけ実装さえ、両方のバージョンをサポートする実装で共同利用するために心にこれらの問題を少なくともとどめていなければなりません。
4.7.1. L2TPv3 over IP
4.7.1. IPの上のL2TPv3
L2TPv3 implementations running strictly over IP with no desire to interoperate with L2TPv2 implementations may safely disregard most migration issues from L2TPv2. All control messages and data messages are sent as described in this document, without normative reference to RFC 2661.
L2TPv2実装で共同利用する願望なしでIPを厳密にひくL2TPv3実装は安全にL2TPv2からのほとんどの移行問題を無視するかもしれません。 RFC2661の引用規格なしで本書では説明されるようにすべてのコントロールメッセージとデータメッセージを送ります。
If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only if it is not available, then L2TPv3 over UDP with automatic fallback (see Section 4.7.3) MUST be used. There is no deterministic method for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over IP is supported by sending an SCCRQ and waiting for a response, but this could be problematic during periods of packet loss between L2TP nodes.
人がL2TPv3の上でPPPにトンネルを堀って、それが利用可能でない場合にだけL2TPv2に後退にトンネルを堀りたいと思うなら、自動後退(セクション4.7.3を見る)があるUDPの上のL2TPv3を使用しなければなりません。 UDPの上にL2TPv2かIPの上のL2TPv3からL2TPv3のどちらかまで自動後退のための確定論的手法が全くありません。 1つはIPの上のL2TPv3がSCCRQを送ることによってサポートされるか、そして、応答の待ちを推論するかもしれませんが、これはL2TPノードの間のパケット損失の期間問題が多いかもしれません。
4.7.2. L2TPv3 over UDP
4.7.2. UDPの上のL2TPv3
The format of the L2TPv3 over UDP header is defined in Section 4.1.2.1.
UDPヘッダーの上のL2TPv3の書式はセクション4.1.2で.1に定義されます。
When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 and shares the first two octets of header format with L2TPv2. The Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets. If an implementation is capable of operating in L2TPv2 or L2TPv3 modes, it is possible to automatically detect whether a peer can support L2TPv2 or L2TPv3 and operate accordingly. The details of this fallback capability is defined in the following section.
UDPの上で作動するとき、L2TPv3はL2TPv2として同じポートを使用して(1701)、ヘッダー形式の最初の2つの八重奏をL2TPv2と共有します。 Ver分野は、L2TPv3パケットとL2TPv2パケットを区別するのに使用されます。 実装がL2TPv2かL2TPv3モードで作動できるなら、同輩がL2TPv2かL2TPv3をサポートして、それに従って、働くことができるかどうか自動的に検出するのは可能です。 この後退能力の詳細は以下のセクションで定義されます。
4.7.3. Automatic L2TPv2 Fallback
4.7.3. 自動L2TPv2後退
When running over UDP, an implementation may detect whether a peer is L2TPv3-capable by sending a special SCCRQ that is properly formatted for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ with its Ver field set to 2 (for L2TPv2), and ensuring that any L2TPv3-specific AVPs (i.e., AVPs present within this document and not defined within RFC 2661) in the message are sent with each M bit set to 0, and that all L2TPv2 AVPs are present as they would be for L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3, the value contained in the space of the control message header utilized by the 32-bit Control Connection ID in L2TPv3, and the 16- bit Tunnel ID and
UDPをひくとき、実装は、同輩がL2TPv2とL2TPv3の両方のために適切にフォーマットされる特別なSCCRQを送ることによってL2TPv3できるかどうか検出するかもしれません。 Ver分野が2(L2TPv2のための)に設定されて、したがって、彼らはL2TPv2のためのものでしょう、メッセージの(すなわち、このドキュメントの中に現在の、そして、RFC2661の中で定義されなかったAVPs)が各Mと共に送られるどんなL2TPv3特有のAVPsもセットに0まで噛み付いて、すべてのL2TPv2 AVPsが存在しているのを確実にしていて、これは、SCCRQを送ることによって、達成されます。 L2TPv3 AVPsがL2TPv2だけ実装によって無視されるように、これをします。 そしてL2TPv3で32ビットのControl Connection IDによって利用されたコントロールメッセージヘッダーのスペースに保管されていた値、および16がL2TPv2とL2TPv3の両方でTunnel IDに噛み付いたことに注意してください。
Lau, et al. Standards Track [Page 29] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[29ページ]RFC3931L2TPv3 March 2005
16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This effectively hides the fact that there are a pair of 16-bit fields in L2TPv2, and a single 32-bit field in L2TPv3.
いつもL2TPv2の16ビットのSession IDはSCCRQのための0です。 事実上、これは、L2TPv2に1組の16ビットの分野があるという事実を隠して、L2TPv3にただ一つの32ビットの分野を隠します。
If the peer implementation is L2TPv3-capable, a control message with the Ver field set to 3 and an L2TPv3 header and message format will be sent in response to the SCCRQ. Operation may then continue as L2TPv3. If a message is received with the Ver field set to 2, it must be assumed that the peer implementation is L2TPv2-only, thus enabling fallback to L2TPv2 mode to safely occur.
同輩実装がL2TPv3できるなら、Ver分野があるコントロールメッセージは3にセットしました、そして、SCCRQに対応してL2TPv3ヘッダーとメッセージ・フォーマットを送るでしょう。 そして、操作はL2TPv3として続くかもしれません。 Ver分野セットでメッセージを2に受け取るなら、同輩実装がL2TPv2専用であると思わなければなりません、その結果、L2TPv2モードへの後退が安全に起こるのを可能にします。
Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 implementations over UDP be liberal in accepting an SCCRQ control message with the Ver field set to 2 or 3 and the presence of L2TPv2- specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 AVPs (e.g., those defined in RFC 2661 and not in this document) within an SCCRQ with the Ver field set to 2 (even if the M bit is set on the L2TPv2-specific AVPs).
以下によく注意してください。 L2TPv2/v3自動検出モードは、UDPの上のすべてのL2TPv3実装が2か3に設定されたVer分野とL2TPv2の特定のAVPsの存在と共にSCCRQコントロールメッセージを受け入れるのにおいて寛容であることを必要とします。 L2TPv3だけ実装はVer分野セットがあるSCCRQの中のすべてのL2TPv2 AVPs(例えば本書ではで定義されるのではなく、RFC2661で定義されたもの)を2まで無視しなければなりません(MビットがL2TPv2特有のAVPsに設定されても)。
5. Control Message Attribute Value Pairs
5. コントロールメッセージ属性値ペア
To maximize extensibility while permitting interoperability, a uniform method for encoding message types is used throughout L2TP. This encoding will be termed AVP (Attribute Value Pair) for the remainder of this document.
相互運用性を可能にしている間、伸展性を最大にするために、メッセージタイプをコード化するための一定のメソッドはL2TP中で使用されます。 このコード化はこのドキュメントの残りのためにAVP(属性Value Pair)と呼ばれるでしょう。
5.1. AVP Format
5.1. AVP形式
Each AVP is encoded as follows:
各AVPは以下の通りコード化されます:
Figure 5.1: AVP Format
図5.1: AVP形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 comprise a bit mask that describes the general attributes of the AVP. Two bits are defined in this document; the remaining bits are reserved for future extensions. Reserved bits MUST be set to 0 when sent and ignored upon receipt.
最初の6ビットはAVPの一般属性について説明するマスクを少し含みます。 2ビットは本書では定義されます。 残っているビットは今後の拡大のために予約されます。 領収書で送られて、無視されると、予約されたビットを0に設定しなければなりません。
Lau, et al. Standards Track [Page 30] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[30ページ]RFC3931L2TPv3 March 2005
Mandatory (M) bit: Controls the behavior required of an implementation that receives an unrecognized AVP. The M bit of a given AVP MUST only be inspected and acted upon if the AVP is unrecognized (see Section 5.2).
義務的な(M)ビット: 振舞いが必要とした認識されていないAVPを受ける実装のコントロール。 AVPが認識されていないなら(セクション5.2を見てください)、点検されるだけであり、作用された与えられたAVP MUSTについて噛み付かれたM。
Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP. Section 5.3 describes the procedure for performing AVP hiding.
隠された(H)ビット: AVPのAttribute Value分野でデータの隠れることを特定します。 極秘データの通過を避けるのにこの能力を使用できます、ユーザパスワードなどのように、AVPのcleartextとして。 セクション5.3はAVP隠れることを実行するための手順について説明します。
Length: Contains the number of octets (including the Overall Length and bit mask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets.
長さ: このAVPに含まれた八重奏(Overall Lengthと噛み付いているマスク分野を含んでいる)の数を含んでいます。 Lengthは+ Attribute Valueの長さが八重奏でさばく6として計算されるかもしれません。
The field itself is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. The minimum Length of an AVP is 6. If the Length is 6, then the Attribute Value field is absent.
独身のAVPのデータの最大1023の八重奏を可能にして、分野自体は10ビットです。 AVPの最小のLengthは6歳です。 Lengthが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 its own L2TP extensions can use its own Vendor ID along with private Attribute values, guaranteeing that they will not collide with any other vendor's extensions or future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this feature to the first 65,535 enterprises.
ベンダーID: [RFC1700]が評価するIANAによって割り当てられた「SMIネットワークマネージメント私企業コード。」 IETFによって採用された属性値に対応する値0はこのドキュメントの中に定義されたすべてのAVPsに使用されます。 それ自身のL2TP拡張子を実装したがっているどんなベンダーも個人的なAttribute値に伴うそれ自身のVendor IDを使用できます、いかなる他のベンダーの拡大か将来の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.
タイプを結果と考えてください: ユニークな解釈が与えられたVendor IDの下で定義されたすべてのAVPsのむこうにある2八重奏の値。
Attribute Value: This is the actual value as indicated by the Vendor ID and Attribute Type. It follows immediately after the Attribute Type field and runs for the remaining octets indicated in the Length (i.e., Length minus 6 octets of header). This field is absent if the Length is 6.
値を結果と考えてください: Vendor IDとAttribute Typeによって示されるようにこれは実価です。 それは、Attribute Type分野直後続いて、Length(すなわち、ヘッダーの6つの八重奏を引いたLength)で示された残っている八重奏に立候補します。 この分野はLengthが6歳であるなら欠けています。
In the event that the 16-bit Vendor ID space is exhausted, vendor- specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the following manner:
16ビットのVendor IDスペースが疲れ果てている場合、以下の方法で32ビットのVendor IDがあるベンダーの特定のAVPsをカプセル化しなければなりません:
Lau, et al. Standards Track [Page 31] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[31ページ]RFC3931L2TPv3 March 2005
Figure 5.2: Extended Vendor ID AVP Format
図5.2: 拡張ベンダーID AVP形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 58 | 32-bit Vendor ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 58 | 32ビットのベンダーID… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値を結果と考えてください… +++++++++++++++++++++++++++++++++(Lengthに達するまで)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space within the Attribute Value field. Multiple AVPs of this type may exist in any message. The 16-bit Vendor ID MUST be 0, indicating that this is an IETF-defined AVP, and the Attribute Type MUST be 58, indicating that what follows is a vendor-specific AVP with a 32-bit Vendor ID code. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP MUST be set to 0. The Length of the AVP is 12 plus the length of the Attribute Value.
Attribute Value分野の中に32ビットのVendor IDスペースがある状態で、このAVPはベンダー特有のAVPをコード化します。 このタイプの複数のAVPsがどんなメッセージにも存在するかもしれません。 16ビットのVendor IDは0であるに違いありません、これがIETFによって定義されたAVPであり、Attribute Typeが58歳であるに違いないことを示して、続くことが32ビットのVendor IDコードがあるベンダー特有のAVPであることを示して。 このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 MはこのAVP MUSTのために噛み付きました。0に設定されます。 AVPのLengthはAttribute Valueの12と長さです。
5.2. Mandatory AVPs and Setting the M Bit
5.2. 義務的なAVPsと噛み付かれて、Mを設定すること。
If the M bit is set on an AVP that is unrecognized by its recipient, the session or control connection associated with the control message containing the AVP MUST be shut down. If the control message containing the unrecognized AVP is associated with a session (e.g., an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a CDN with a Result Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut down. If the control message containing the unrecognized AVP is associated with establishment or maintenance of a Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the associated Control Connection MUST be issued a StopCCN with Result Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut down. If the M bit is not set on an unrecognized AVP, the AVP MUST be ignored when received, processing the control message as if the AVP were not present.
Mビットが設定されるなら、接続がAVP MUSTを含んでいるコントロールメッセージに関連づけた受取人で認識されていないAVP、セッションまたはコントロールのときに、止められてください。 認識されていないAVPを含むコントロールメッセージがセッション(例えば、ICRQ、ICRP、ICCN、SLIなど)に関連しているなら、セッションは、CDNが2のResult Codeと8のError Code(セクション5.4.2で定義されるように)と共に発行されて、停止しなければなりません。 認識されていないAVPを含むコントロールメッセージがControl Connection(例えば、SCCRQ、SCCRP、SCCCN、Hello)の設立かメインテナンスに関連しているなら、関連Control ConnectionはStopCCNが2のResult Codeと8のError Code(セクション5.4.2で定義されるように)と共に発行されて、停止しなければなりません。 Mが噛み付いたなら、まるでAVPが存在していないかのように、認識されていないAVP、AVP MUSTのセットは、受け取ると無視して、コントロールメッセージを処理していませんか?
Receipt of an unrecognized AVP that has the M bit set is catastrophic to the session or control connection with which it is associated. Thus, the M bit should only be set for AVPs that are deemed crucial to proper operation of the session or control connection by the sender. AVPs that are considered crucial by the sender may vary by application and configured options. In no case shall a receiver of
それが関連しているセッションかコントロール接続に、設定されて、Mを噛み付かせる認識されていないAVPの領収書は壊滅的です。 したがって、Mビットはセッションかコントロール接続の適切な操作に重要であると送付者によって考えられるAVPsに設定されるだけであるべきです。 重要であると送付者によって考えられるAVPsはアプリケーションと構成されたオプションで異なるかもしれません。 中では、どんなケースもそうしない、受信機
Lau, et al. Standards Track [Page 32] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[32ページ]RFC3931L2TPv3 March 2005
an AVP "validate" if the M bit is set on a recognized AVP. If the AVP is recognized (as all AVPs defined in this document MUST be for a compliant L2TPv3 specification), then by definition, the M bit is of no consequence.
Mが噛み付いたなら、AVP「有効にすること」は認識されたAVPに設定されます。 AVPが認識されるなら(本書では定義されたすべてのAVPsが対応するL2TPv3仕様のためのものであるに違いないときに)、定義上、Mビットは結果の全くものではありません。
The sender of an AVP is free to set its M bit to 1 or 0 based on whether the configured application strictly requires the value contained in the AVP to be recognized or not. For example, "Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and desired, and 1 if not.
AVPの送付者は自由に構成されたアプリケーションが、AVPに含まれた値が認識されるのを厳密に必要とするかどうかに基づいて1か0まで噛み付かれたMを設定できます。 例えば、そうでなければ、セクション4.7.3における「自動L2TPv2後退」はL2TPv2への後退がサポートされて、望まれているならすべての新しいL2TPv3 AVPsでゼロまで噛み付かれたM、および1の設定を必要とします。
The M bit is useful as extra assurance for support of critical AVP extensions. However, more explicit methods may be available to determine support for a given feature rather than using the M bit alone. For example, if a new AVP is defined in a message for which there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP message), rather than simply sending an AVP in the message with the M bit set, availability of the extension may be identified by sending an AVP in the request message and expecting a corresponding AVP in a reply message. This more explicit method, when possible, is preferred.
Mビットは重要なAVP拡張子のサポートのための付加的な保証として役に立ちます。 しかしながら、より明白なメソッドは、単独で噛み付かれたMを使用するよりむしろ与えられた特徴のサポートを決定するために利用可能であるかもしれません。 例えば、新しいAVPがメッセージで定義されるなら、どれが単に発信するよりいつもむしろメッセージ回答(すなわち、ICRQ、ICRP、SCCRQ、またはSCCRPメッセージ)があるようにMがあるメッセージのAVPが噛み付いたかはセットして、拡大の有用性は、要求メッセージでAVPを送って、応答メッセージで対応するAVPを予想することによって、特定されるかもしれません。 可能であるときに、このより明白なメソッドは好まれます。
The M bit also plays a role in determining whether or not a malformed or out-of-range value within an AVP should be ignored or should result in termination of a session or control connection (see Section 7.1 for more details).
また、MビットはAVPの中の奇形の、または、範囲で出ている値が無視されるべきであるか、またはセッションかコントロール接続の終了をもたらすべきであるかどうか(その他の詳細に関してセクション7.1を見てください)決定することにおける役割を果たします。
5.3. Hiding of AVP Attribute Values
5.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, IDs, or other vital information.
それぞれのAVPのヘッダーのHビットは、cleartextでAVPの内容が隠されるか、または存在しているかを受信同輩に示すためにメカニズムを提供します。 ユーザパスワード、ID、または他の極めて重要な情報などの機密のコントロールメッセージデータを隠すのにこの特徴を使用できます。
The H bit MUST only be set if (1) a shared secret exists between the LCCEs and (2) Control Message Authentication is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a given control message, at least one Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1.
(2) (1) 共有秘密キーがLCCEsの間に存在しているなら、Hビットを設定するだけでよいです、そして、コントロールMessage Authenticationは有効にされます(セクション4.3を見てください)。 Hビットが与えられたコントロールメッセージのどんなAVP(s)にも設定されるなら、少なくとも1Random Vector AVPがまた、メッセージに存在していなければならなくて、1のHビットを持っている最初のAVPに先行しなければなりません。
Lau, et al. Standards Track [Page 33] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[33ページ]RFC3931L2TPv3 March 2005
The shared secret between LCCEs is used to derive a unique shared key for hiding and unhiding calculations. The derived shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with the key consisting of the shared secret, and with the data being hashed consisting of a single octet containing the value 1.
LCCEsの間の共有秘密キーは、計算を隠して、「非-隠」すためのユニークな共有されたキーを引き出すのに使用されます。 共有秘密キー、およびデータが値1を含むただ一つの八重奏から成りながら論じ尽くされている合わせられたハッシュ[RFC2104]であって、キーで成っているHMAC-MD5を通して派生している共有されたキーを入手します。
shared_key = HMAC_MD5 (shared_secret, 1)
共有された_キー=HMAC_MD5(共有された_秘密、1)
Hiding an AVP value is done in several steps. The first step is to take the length and value fields of the original (cleartext) AVP and encode them into the Hidden AVP Subformat, which appears as follows:
AVP値は数ステップに隠されます。 第一歩は、オリジナルの(cleartext)AVPの長さと値のグラウンドに出て、それらをHidden AVP Subformatにコード化することです:(Hidden AVP Subformatは以下の通りに見えます)。
Figure 5.3: Hidden AVP Subformat
図5.3: 隠された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 that 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 would become 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. Thus, if Padding is 12 octets, the AVP length would be 6 + 4 + 2 + 12 = 24 octets.
隠されるデータのサイズにマスクをかけるために、結果として起こる「副-形式」は上に示されるようにそっと歩いているかもしれません。 詰め物は、Original Attribute Value分野のLengthに置かれた値を変更しませんが、作成されている結果のAVPの長さを変更します。 例えば、隠されるべきAttribute Valueが長さが4つの八重奏であるなら、unhidden AVPの長さは10の八重奏(6+属性Valueの長さ)でしょう。 隠れることの後に、AVPの長さはOriginal Attribute Value分野+詰め物のLengthの6+属性Value長さ+サイズになるでしょう。 したがって、Paddingが12の八重奏であるなら、AVPの長さは6+4+2+12 = 24の八重奏でしょう。
Lau, et al. Standards Track [Page 34] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[34ページ]RFC3931L2TPv3 March 2005
Next, an MD5 [RFC1321] hash is performed (in network byte order) on the concatenation of the following:
次に、MD5[RFC1321]ハッシュは以下の連結に実行されます(ネットワークバイトオーダーで):
+ the 2-octet Attribute number of the AVP
+ the shared key
+ an arbitrary length random vector
+ + 共有が+ 任意の長さの無作為のベクトルに合わせるAVPの2八重奏の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 message, but not for hiding two or more instances of an AVP with the same Attribute Type unless the Attribute Values in the two AVPs are also identical. When a different random vector is used for the hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in the control message before the first AVP to which it applies.
このハッシュに使用される無作為のベクトルの値はRandom Vector AVPの値の分野で通過されます。 送付者はどんな隠されたAVPsの前にもこのRandom Vector AVPをメッセージに置かなければなりません。 同じ無作為のベクトルは、同じメッセージの1隠されたAVPに使用されますが、また、2AVPsのAttribute Valuesも同じでない場合同じAttribute Typeと共にAVPの2つ以上のインスタンスを隠すのに使用されるかもしれないというわけではありません。 異なった無作為のベクトルがその後の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. 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は変成しています。 Subformatの現在の実際の八重奏だけが変更されています、そして、AVPの長さは変えられません。
If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared key followed by the result of the first XOR. That hash is XORed with the second 16-octet (or less) segment of the Subformat and placed in the corresponding octets of the Value field of the Hidden AVP.
Subformatが16の八重奏より長いなら、2番目の一方向MD5ハッシュは最初のXORの結果があとに続いた共有されたキーから成る八重奏のストリームに関して計算されます。 そのハッシュはSubformatであってHidden AVPのValue分野の対応する八重奏に置かれることの2番目の16八重奏(それほど)のセグメントがあるXORedです。
If necessary, this operation is repeated, with the shared key used along with each XOR result to generate the next hash to XOR the next segment of the value with.
必要なら、この操作は繰り返されます、共有されたキーがXORへの価値の次のセグメントを次のハッシュに生成するそれぞれのXOR結果と共に使用されている状態で。
The hiding method was adapted from [RFC2865], which was taken from the "Mixing in the Plaintext" section in the book "Network Security" by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of the method follows:
隠れることメソッドは[RFC2865]から適合させられました。(それは、コーフマン、パールマン、およびSpeciner[KPS]によって「平文では混合する」セクションから本の「ネットワークセキュリティ」で取られました)。 メソッドの詳説は続きます:
Call the shared key S, the Random Vector RV, and the Attribute Type A. Break the value field into 16-octet chunks p_1, p_2, etc., with the last one padded at the end with random data to a 16-octet boundary. Call the ciphertext blocks c_1, c_2, etc. We will also define intermediate values b_1, b_2, etc.
最後のものが終わりに無作為のデータで16八重奏の境界に水増しされている状態で、16八重奏の塊p_1、p_2などに共有されたキーS、Random Vector RV、およびAttribute Type A.Breakを値の分野と呼んでください。 暗号文ブロックをc_1、c_2などと呼んでください。 また、私たちは中間的値b_1、b_2などを定義するつもりです。
Lau, et al. Standards Track [Page 35] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[35ページ]RFC3931L2TPv3 March 2005
b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1
b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2
. .
. .
. .
b_i = MD5 (S + c_i-1) c_i = p_i xor b_i
等しい
The String will contain c_1 + c_2 +...+ c_i, where "+" denotes concatenation.
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から無作為のベクトルを取ります。 そして、上のプロセスは、元の値をもたらすために逆にされます。
5.4. AVP Summary
5.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の適切な使用に必要であるどんな追加情報にも従います。
5.4.1. General Control Message AVPs
5.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.2.1). See Section 3.1 for the list of defined control
message types and their identifiers.
Message Type AVPはメッセージで最初のAVPであるに違いありません、すぐにコントロールメッセージヘッダー(セクション3.2.1では、定義される)に続いて。 定義されたコントロールメッセージタイプと彼らの識別子のリストに関してセクション3.1を見てください。
Lau, et al. Standards Track [Page 36] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[36ページ]RFC3931L2TPv3 March 2005
The Mandatory (M) bit within the Message Type AVP has special
meaning. Rather than an indication as to whether the AVP itself
should be ignored if not recognized, it is an indication as to
whether the control message itself should be ignored. If the M
bit is set within the Message Type AVP and the Message Type is
unknown to the implementation, the control connection MUST be
cleared. If the M bit is not set, then the implementation may
ignore an unknown message type. The M bit MUST be set to 1 for
all message types defined in this document. This AVP MUST NOT be
hidden (the H bit MUST be 0). The Length of this AVP is 8.
Message Type AVPの中のMandatory(M)ビットには、特別な意味があります。 指示よりむしろ、AVP自身が無視されるべきであるか、または認識されるべきであるかに関して、コントロールメッセージ自体が無視されるべきであるかどうかに関してそれは指示です。 Mが噛み付いたなら、Message Type AVPの中にセットがあります、そして、実装において、Message Typeが未知である、コントロール接続をきれいにしなければなりません。 Mであるなら、ビットは設定されないで、次に、実装は未知のメッセージタイプを無視するかもしれません。 すべてのメッセージのための1へのセットが本書では定義されたタイプであったに違いないなら噛み付かれたM。 このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVPのLengthは8歳です。
A vendor-specific control message may be defined by setting the
Vendor ID of the Message Type AVP to a value other than the IETF
Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still
be the first AVP in the control message.
ベンダー特有のコントロールメッセージは、0のIETF Vendor ID以外の値にMessage Type AVPのVendor IDを設定することによって、定義されるかもしれません(セクション5.1を見てください)。 Message Type AVPはコントロールメッセージでまだ最初のAVPであるに違いありません。
Message Digest (All Messages)
メッセージダイジェスト(すべてのメッセージ)
The Message Digest AVP, Attribute Type 59 is used as an integrity
and authentication check of the L2TP Control Message header and
body.
Message Digest AVP、Attribute Type59はL2TP Control Messageヘッダーとボディーの保全と認証チェックとして使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 or 20 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (16か20の八重奏) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Digest Type is a one-octet integer indicating the Digest
calculation algorithm:
ダイジェストTypeはDigest計算アルゴリズムを示す1八重奏の整数です:
0 HMAC-MD5 [RFC2104]
1 HMAC-SHA-1 [RFC2104]
0 HMAC-MD5[RFC2104]1HMAC-SHA-1[RFC2104]
Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1
(HMAC-SHA-1) SHOULD be supported.
(HMAC-MD5)をサポートしなければならないType0を読みこなしてください、そして、Digest Type1(HMAC-SHA-1)SHOULDである間、サポートされてください。
The Message Digest is of variable length and contains the result
of the control message authentication and integrity calculation.
For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16
Message Digestは可変長があって、コントロール通報認証と保全計算の結果を含んでいます。 Digest Type0(HMAC-MD5)に関しては、ダイジェストの長さは16であるに違いありません。
Lau, et al. Standards Track [Page 37] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[37ページ]RFC3931L2TPv3 March 2005
bytes. For Digest Type 1 (HMAC-SHA-1) the length of the digest
MUST be 20 bytes.
バイト。 Digest Type1(HMAC-SHA-1)に関しては、ダイジェストの長さは20バイトでなければなりません。
If Control Message Authentication is enabled, at least one Message
Digest AVP MUST be present in all messages and MUST be placed
immediately after the Message Type AVP. This forces the Message
Digest AVP to begin at a well-known and fixed offset. A second
Message Digest AVP MAY be present in a message and MUST be placed
directly after the first Message Digest AVP.
Control Message Authenticationが有効にされるなら、少なくとも1Message Digest AVPをすべてのメッセージに存在していなければならなくて、Message Type AVP直後置かなければなりません。 これによって、Message Digest AVPはよく知られて固定されたオフセットのときにやむを得ず始まります。 第2のMessage Digest AVPをメッセージに存在しているかもしれなくて、最初のMessage Digest AVP直後置かなければなりません。
The shared secret between LCCEs is used to derive a unique shared
key for Control Message Authentication calculations. The derived
shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with
the key consisting of the shared secret, and with the data being
hashed consisting of a single octet containing the value 2.
LCCEsの間の共有秘密キーは、Control Message Authentication計算のためのユニークな共有されたキーを引き出すのに使用されます。 共有秘密キー、およびデータが値2を含むただ一つの八重奏から成りながら論じ尽くされている合わせられたハッシュ[RFC2104]であって、キーで成っているHMAC-MD5を通して派生している共有されたキーを入手します。
shared_key = HMAC_MD5 (shared_secret, 2)
共有された_キー=HMAC_MD5(共有された_秘密、2)
Calculation of the Message Digest is as follows for all messages
other than the SCCRQ (where "+" refers to concatenation):
SCCRQ(「+」が連結を呼ぶところ)以外のすべてのメッセージにおいて、Message Digestの計算は以下の通りです:
Message Digest = HMAC_Hash (shared_key, local_nonce +
remote_nonce + control_message)
メッセージダイジェスト=HMAC_ハッシュ(共有された_主要で、地方の_一回だけの、または、リモートな_一回だけ+コントロール_メッセージ)
HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type
(MD5 or SHA1)
HMAC_ハッシュ: Digest Typeによって特定されたHMAC Hashingアルゴリズム(MD5かSHA1)
local_nonce: Nonce chosen locally and advertised to the remote
LCCE.
地方の_一回だけ: リモートLCCEに局所的に選ばれていて、広告に掲載された一回だけ。
remote_nonce: Nonce received from the remote LCCE
リモート_一回だけ: リモートLCCEから受け取られた一回だけ
(The local_nonce and remote_nonce are advertised via the
Control Message Authentication Nonce AVP, also defined in this
section.)
(地方の_一回だけの、そして、リモートな_一回だけは、Control Message Authentication Nonce AVPを通して広告を出して、また、このセクションで定義されます。)
shared_key: Derived shared key for this control connection
共有された_キー: このコントロール接続のための派生している共有されたキー
control_message: The entire contents of the L2TP control
message, including the control message header and all AVPs.
Note that the control message header in this case begins after
the all-zero Session ID when running over IP (see Section
4.1.1.2), and after the UDP header when running over UDP (see
Section 4.1.2.1).
_メッセージを制御してください: L2TPの全体の内容はコントロールメッセージヘッダーとすべてのAVPsを含むメッセージを制御します。 セクション4.1を見てください。この場合IPをひくとき、コントロールメッセージヘッダーがオールゼロSession IDの後に始まることに注意してください、(セクション4.1.1を見てください、.2)、UDPヘッダーの後、UDPをひく、(.2 .1)。
When calculating the Message Digest, the Message Digest AVP MUST
be present within the control message with the Digest Type set to
its proper value, but the Message Digest itself set to zeros.
Message Digestについて計算するとき、Message Digest AVPはコントロールメッセージの中にDigest Typeセットについて固有値に存在していなければなりませんが、Message Digest自身はゼロにセットしました。
Lau, et al. Standards Track [Page 38] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[38ページ]RFC3931L2TPv3 March 2005
When receiving a control message, the contents of the Message
Digest AVP MUST be compared against the expected digest value
based on local calculation. This is done by performing the same
digest calculation above, with the local_nonce and remote_nonce
reversed. This message authenticity and integrity checking MUST
be performed before utilizing any information contained within the
control message. If the calculation fails, the message MUST be
dropped.
コントロールメッセージを受け取るとき、ローカルな計算に基づく予想されたダイジェスト値に対してMessage Digest AVPのコンテンツをたとえなければなりません。 地方の_一回だけの、そして、リモートな_一回だけが逆にされている状態で、上で同じダイジェスト計算を実行することによって、これをします。 コントロールメッセージの中に含まれたどんな情報も利用する前に、このメッセージの信憑性と保全の照合を実行しなければなりません。 計算が失敗するなら、メッセージを下げなければなりません。
The SCCRQ has special treatment as it is the initial message
commencing a new control connection. As such, there is only one
nonce available. Since the nonce is present within the message
itself as part of the Control Message Authentication Nonce AVP,
there is no need to use it in the calculation explicitly.
Calculation of the SCCRQ Message Digest is performed as follows:
それが新しいコントロール接続を始める初期のメッセージであるので、SCCRQには、特別な処理があります。 そういうものとして、利用可能な1つの一回だけしかありません。 一回だけがControl Message Authentication Nonce AVPの一部としてメッセージ自体の中に存在しているので、計算に明らかにそれを使用する必要は全くありません。 SCCRQ Message Digestの計算は以下の通り実行されます:
Message Digest = HMAC_Hash (shared_key, control_message)
メッセージダイジェスト=HMAC_ハッシュ(主要な共有された_コントロール_メッセージ)
To allow for graceful switchover to a new shared secret or hash
algorithm, two Message Digest AVPs MAY be present in a control
message, and two shared secrets MAY be configured for a given
LCCE. If two Message Digest AVPs are received in a control
message, the message MUST be accepted if either Message Digest is
valid. If two shared secrets are configured, each (separately)
MUST be used for calculating a digest to be compared to the
Message Digest(s) received. When calculating a digest for a
control message, the Value field for both of the Message Digest
AVPs MUST be set to zero.
新しい共有秘密キーかハッシュアルゴリズムに優雅な転換を考慮するために、2Message Digest AVPsがコントロールメッセージに存在しているかもしれません、そして、2つの共有秘密キーが与えられたLCCEのために構成されるかもしれません。 コントロールメッセージに2Message Digest AVPsを受け取るなら、Message Digestが有効であるなら、メッセージを受け入れなければなりません。 2つの共有秘密キーが構成されるなら、Message Digest(s)と比較されるべきダイジェストが受信されたと見込むのに(別々に)それぞれを使用しなければなりません。 コントロールメッセージのためにダイジェストについて計算するとき、Message Digest AVPsの両方のためのValue分野をゼロに設定しなければなりません。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type
2 (HMAC-SHA-1).
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 LengthはDigest Type1のための23(HMAC-MD5)と、Digest Type2のための27歳(HMAC-SHA-1)です。
Control Message Authentication Nonce (SCCRQ, SCCRP)
コントロール通報認証一回だけ(SCCRQ、SCCRP)
The Control Message Authentication Nonce AVP, Attribute Type 73,
MUST contain a cryptographically random value [RFC1750]. This
value is used for Control Message Authentication.
Control Message Authentication Nonce AVP(Attribute Type73)は暗号でaを含まなければなりません。無作為の値[RFC1750]。 この値はControl Message Authenticationに使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ... (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一回だけ… (八重奏の特殊活字の数字) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lau, et al. Standards Track [Page 39] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[39ページ]RFC3931L2TPv3 March 2005
The Nonce is of arbitrary length, though at least 16 octets is
recommended. The Nonce contains the random value for use in the
Control Message Authentication hash calculation (see Message
Digest AVP definition in this section).
少なくとも16の八重奏がお勧めですが、Nonceは任意の長さのものです。 NonceはControl Message Authenticationハッシュ計算における使用のための無作為の値を含んでいます(このセクションとのMessage Digest AVP定義を見てください)。
If Control Message Authentication is enabled, this AVP MUST be
present in the SCCRQ and SCCRP messages.
Control Message Authenticationは有効にされて、これはAVP MUSTです。SCCRQとSCCRPメッセージに存在してください。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Nonce.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLengthはNonceの6と長さです。
Random Vector (All Messages)
無作為のベクトル(すべてのメッセージ)
The Random Vector AVP, Attribute Type 36, MUST contain a
cryptographically random value [RFC1750]. This value is used for
AVP Hiding.
Random Vector AVP(Attribute Type36)は暗号でaを含まなければなりません。無作為の値[RFC1750]。 この値はAVP Hidingに使用されます。
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 ... (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 Random Octet String is of arbitrary length, though at least 16
octets is recommended. The string contains the random vector for
use in computing the MD5 hash to retrieve or hide the Attribute
Value of a hidden AVP (see Section 5.3).
少なくとも16の八重奏がお勧めですが、Random Octet Stringは任意の長さのものです。 ストリングは隠されたAVPのAttribute Valueを検索するか、または隠すためにMD5ハッシュを計算することにおける使用のための無作為のベクトルを含んでいます(セクション5.3を見てください)。
More than one Random Vector AVP may appear in a message, in which
case a hidden AVP uses the Random Vector AVP most closely
preceding it. As such, at least one Random Vector AVP MUST
precede the first AVP with the H bit set.
1Random Vector AVPがメッセージに現れるかもしれません、その場合、隠されたAVPは密接にそれに先行しながら、Random Vector AVPを最も使用します。 そういうものとして、Hビットがセットした状態で、少なくとも1Random Vector AVPが最初のAVPに先行しなければなりません。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Random Octet
String.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLengthはRandom Octet Stringの6と長さです。
5.4.2. Result and Error Codes
5.4.2. 結果とエラーコード
Result Code (StopCCN, CDN)
結果コード(StopCCN、CDN)
The Result Code AVP, Attribute Type 1, indicates the reason for
terminating the control connection or session.
Result Code AVP(Attribute Type1)はコントロール接続かセッションを終える理由を示します。
Lau, et al. Standards Track [Page 40] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[40ページ]RFC3931L2TPv3 March 2005
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 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message ... (optional, 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 Result Code is a 2-octet unsigned integer. The optional Error
Code is a 2-octet unsigned integer. An optional Error Message can
follow the Error Code field. Presence of the Error Code and
Message is indicated by the AVP Length field. The Error Message
contains an arbitrary string providing further (human-readable)
text associated with the condition. Human-readable text in all
error messages MUST be provided in the UTF-8 charset [RFC3629]
using the Default Language [RFC2277].
Result Codeは2八重奏の符号のない整数です。 任意のError Codeは2八重奏の符号のない整数です。 任意のError MessageはError Code野原に続くことができます。 Error CodeとMessageの存在はAVP Length分野によって示されます。 Error Messageはさらに(人間読み込み可能な)状態に関連しているテキストを提供する任意のストリングを含んでいます。 Default Language[RFC2277]を使用して、すべてのエラーメッセージの人間読み込み可能なテキストをUTF-8 charset[RFC3629]に提供しなければなりません。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length is 8 if there is no Error Code or Message, 10 if there is
an Error Code and no Error Message, or 10 plus the length of the
Error Message if there is an Error Code and Message.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 そこであるなら、Error Messageの長さは、どんなError CodeもMessageもなければ、Lengthが8歳であり、そこであるなら、10は、Error Messageでなくて、Error Codeではなく、10でもあり、Error CodeとMessageです。
Defined Result Code values for the StopCCN message are as follows:
StopCCNメッセージのための定義されたResult Code値は以下の通りです:
0 - Reserved.
1 - General request to clear control connection.
2 - General error, Error Code indicates the problem.
3 - Control connection already exists.
4 - Requester is not authorized to establish a control
connection.
5 - The protocol version of the requester is not supported,
Error Code indicates highest version supported.
6 - Requester is being shut down.
7 - Finite state machine error or timeout
0--予約されています。 1--コントロール接続をきれいにするという一般要求。 2--一般誤り、Error Codeは問題を示します。 3--コントロール接続は既に存在しています。 4--リクエスタがコントロール接続を確立するのが認可されません。 5--リクエスタのプロトコルバージョンはサポートされないで、Error Codeは、最も高いバージョンがサポートしたのを示します。 6--リクエスタは止められています。 7--有限状態機械誤りかタイムアウト
General Result Code values for the CDN message are as follows:
CDNメッセージのための一般Result Code値は以下の通りです:
0 - Reserved.
1 - Session disconnected due to loss of carrier or
circuit disconnect.
2 - Session disconnected for the reason indicated in Error
Code.
3 - Session disconnected for administrative reasons.
4 - Session establishment failed due to lack of appropriate
facilities being available (temporary condition).
0--予約されています。 1--セッションはキャリヤーの損失か回路分離のため切断しました。 2--セッションはError Codeで示された理由で切断しました。 3--セッションは管理理由で切断しました。 4--セッション設立は利用可能な適切な施設(一時的な病態)の不足のため行き詰まりました。
Lau, et al. Standards Track [Page 41] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[41ページ]RFC3931L2TPv3 March 2005
5 - Session establishment failed due to lack of appropriate
facilities being available (permanent condition).
13 - Session not established due to losing tie breaker.
14 - Session not established due to unsupported PW type.
15 - Session not established, sequencing required without
valid L2-Specific Sublayer.
16 - Finite state machine error or timeout.
5--セッション設立は利用可能な適切な施設(永久的な状態)の不足のため行き詰まりました。 13--セッションは損をしているタイブレークに支払われるべきものを設立しませんでした。 14--セッションはサポートされないPWタイプに支払われるべきものを設立しませんでした。 15--確立されなかったセッション、配列が有効なL2特有のSublayerなしで必要です。 16--有限状態機械誤りかタイムアウト。
Additional service-specific Result Codes are defined outside this
document.
追加サービス特有のResult Codesはこのドキュメントの外で定義されます。
The Error Codes defined below pertain to types of errors that are
not specific to any particular L2TP request, but rather to
protocol or message format errors. If an L2TP reply indicates in
its Result Code that a General Error occurred, the General Error
value should be examined to determine what the error was. The
currently defined General Error codes and their meanings are as
follows:
以下で定義されたError Codesはどんな特定のL2TP要求にも特定であるのではなく、むしろプロトコルに特定の誤りかメッセージ・フォーマット誤りのタイプに関係します。 L2TP回答が、Result CodeでError司令官が起こったのを示すなら、一般Error値は、誤りが何であったかを決定するために調べられるべきです。 現在定義された一般Errorコードとそれらの意味は以下の通りです:
0 - No General Error.
1 - No control connection exists yet for this pair of LCCEs.
2 - Length is wrong.
3 - One of the field values was out of range.
4 - Insufficient resources to handle this operation now.
5 - Invalid Session ID.
6 - A generic vendor-specific error occurred.
7 - Try another. If initiator is aware of other possible
responder destinations, it should try one of them. This can
be used to guide an LAC or LNS based on policy.
8 - The session or control connection was shut down due to receipt
of an unknown AVP with the M bit set (see Section 5.2). The
Error Message SHOULD contain the attribute of the offending
AVP in (human-readable) text form.
9 - Try another directed. If an LAC or LNS is aware of other
possible destinations, it should inform the initiator of the
control connection or session. The Error Message MUST contain
a comma-separated list of addresses from which the initiator
may choose. If the L2TP data channel runs over IPv4, then
this would be a comma-separated list of IP addresses in the
canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2,
192.0.2.3") in the UTF-8 charset [RFC3629] using the Default
Language [RFC2277]. If there are no servers for the LAC or
LNS to suggest, then Error Code 7 should be used. For IPv4,
the delimiter between addresses MUST be precisely a single
comma and a single space. For IPv6, each literal address MUST
be enclosed in "[" and "]" characters, following the encoding
described in [RFC2732].
0--一般的なエラーがありません。 1--どんなコントロール接続もLCCEsのこの組のためにまだ存在していません。 2--長さは間違っています。 分野値の3--1つは範囲から脱していました。 4--現在この操作を扱う不十分なリソース。 5--無効のSession ID。 6--ジェネリックのベンダー特有の誤りは発生しました。 7--別のものを試みてください。 創始者が他の可能な応答者の目的地を意識しているなら、それはそれらの1つを試みるべきです。 方針に基づくLACかLNSを誘導するのにこれを使用できます。 8--接続が閉鎖領収書を出させることになっていたMで噛み付かれた未知のAVPのセッションかコントロールがセットしました(セクション5.2を見てください)。 Error Message SHOULDは(人間読み込み可能)のテキストフォームにおける、怒っているAVPの属性を含んでいます。 9--指示された別のものを試みてください。 LACかLNSが他の可能な目的地を意識しているなら、それはコントロール接続かセッションについて創始者に知らせるべきです。 Error Messageは創始者が選ぶかもしれないコンマで切り離された住所録を含まなければなりません。 L2TPデータ・チャンネルがIPv4をひくならこれが正準なドット付き10進法形式のIPアドレスのコンマで切り離されたリストであるだろう、(例えば、「192.0 .2 .1 192.0 .2 .2、192.0、.2、0.3インチ) UTF-8 charset[RFC3629]使用におけるデフォルト言語[RFC2277]、」 LACかLNSが示すようにサーバが全くなければ、Error Code7は使用されるべきです。 IPv4に関しては、アドレスの間のデリミタは、正確にただ一つのコンマとシングルスペースであるに違いありません。 そして、IPv6に関して、中にそれぞれの文字通りのアドレスを同封しなければならない、「[「」、]、」 [RFC2732]で説明されたコード化の後をつけるキャラクタ。
Lau, et al. Standards Track [Page 42] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[42ページ]RFC3931L2TPv3 March 2005
When a General Error Code of 6 is used, additional information
about the error SHOULD be included in the Error Message field. A
vendor-specific AVP MAY be sent to more precisely detail a
vendor-specific problem.
含まれていて、6のError Code司令官がError Message分野の誤りSHOULDに関する中古の追加情報であるときに。 ベンダー特有のAVP MAY、送って、より正確にベンダー特有の問題を詳しく述べてください。
5.4.3. Control Connection Management AVPs
5.4.3. コントロール接続管理AVPs
Control Connection Tie Breaker (SCCRQ)
コントロール接続タイブレーク(SCCRQ)
The Control Connection Tie Breaker AVP, Attribute Type 5,
indicates that the sender desires a single control connection to
exist between a given pair of LCCEs.
Control Connection Tie Breaker AVP(Attribute Type5)は、送付者が、単一管理接続が与えられた組のLCCEsの間に存在することを望んでいるのを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Tie Breaker 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 Control Connection Tie Breaker Value is an 8-octet random
value that is used to choose a single control connection when two
LCCEs request a control connection concurrently. The recipient of
a SCCRQ must check to see if a SCCRQ has been sent to the peer; if
so, a tie has been detected. In this case, the LCCE must compare
its Control Connection Tie Breaker value with the one received in
the SCCRQ. The lower value "wins", and the "loser" MUST discard
its control connection. A StopCCN SHOULD be sent by the winner as
an explicit rejection for the losing SCCRQ. In the case in which
a tie breaker is present on both sides and the value is equal,
both sides MUST discard their control connections and restart
control connection negotiation with a new, random tie breaker
value.
Control Connection Tie Breaker Valueは2LCCEsが同時にコントロール接続を要求するとき、単一管理接続を選ぶのに使用される8八重奏の無作為の値です。 SCCRQの受取人はSCCRQが同輩に送られたかどうかを見るためにチェックしなければなりません。 そうだとすれば、繋がりは検出されました。 この場合、LCCEはSCCRQに受け取られたものとControl Connection Tie Breaker値を比べなければなりません。 下側の値は「勝ちます」、そして、「敗者」はコントロール接続を捨てなければなりません。 StopCCN SHOULD、損をしているSCCRQのための明白な拒絶として勝者によって送られてください。 タイブレークが両側に存在していて、値が等しい場合では、両側は、新しくて、無作為のタイブレーク値で彼らのコントロール接続を捨てて、コントロール接続交渉を再開しなければなりません。
If a tie breaker is received and an outstanding SCCRQ has no tie
breaker value, the initiator that included the Control Connection
Tie Breaker AVP "wins". If neither side issues a tie breaker,
then two separate control connections are opened.
タイブレークが受け取られていて、傑出しているSCCRQにタイブレーク値が全くないなら、Control Connection Tie Breaker AVP「勝利」を含んでいた創始者です。 どちらの副次的な問題であるなら、タイブレーク、2つの当時の別々のコントロール接続が開かれます。
Applications that employ a distinct and well-known initiator have
no need for tie breaking, and MAY omit this AVP or disable tie
breaking functionality. Applications that require tie breaking
also require that an LCCE be uniquely identifiable upon receipt of
an SCCRQ. For L2TP over IP, this MUST be accomplished via the
Router ID AVP.
異なってよく知られる創始者を雇うアプリケーションは、繋がりの壊すことの必要性を全く持たないで、このAVPを省略するか、または繋がりが壊れている機能性であることを無効にするかもしれません。 また、繋がりの壊すことを必要とするアプリケーションは、LCCEがSCCRQを受け取り次第唯一身元保証可能であることを必要とします。 IPの上のL2TPに関しては、Router ID AVPを通してこれを達成しなければなりません。
Lau, et al. Standards Track [Page 43] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[43ページ]RFC3931L2TPv3 March 2005
Note that in [RFC2661], this AVP is referred to as the "Tie
Breaker AVP" and is applicable only to a control connection. In
L2TPv3, the AVP serves the same purpose of tie breaking, but is
applicable to a control connection or a session. The Control
Connection Tie Breaker AVP (present only in Control Connection
messages) and Session Tie Breaker AVP (present only in Session
messages), are described separately in this document, but share
the same Attribute type of 5.
このAVPが[RFC2661]では「タイブレークAVP」と呼ばれて、コントロール接続だけに適切であることに注意してください。 L2TPv3では、AVPは繋がりが壊れる同じ目的に役立ちますが、コントロール接続かセッションに適切です。 Control Connection Tie Breaker AVP(Control Connectionメッセージだけで現在の)とSession Tie Breaker AVP(Sessionメッセージだけで現在の)による別々に中で説明されて、しかし、このドキュメント、同じシェアAttributeがタイプするということです。5について。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
length of this AVP is 14.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPの長さは14です。
Host Name (SCCRQ, SCCRP)
ホスト名(SCCRQ、SCCRP)
The Host Name AVP, Attribute Type 7, indicates the name of the
issuing LAC or LNS, encoded in the US-ASCII charset.
Host Name AVP(Attribute Type7)は発行LACかLNSという米国-ASCII charsetでコード化された名前を示します。
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つの八重奏であるに違いありません。
This name should be as broadly unique as possible; for hosts
participating in DNS [RFC1034], a host name with fully qualified
domain would be appropriate. The Host Name AVP and/or Router ID
AVP MUST be used to identify an LCCE as described in Section 3.3.
この名前はできるだけ広くユニークであるべきです。 DNS[RFC1034]に参加するホストにとって、完全に適切なドメインのホスト名は適切でしょう。 Host Name AVP、そして/または、Router ID AVP MUST、使用されて、セクション3.3で説明されるようにLCCEを特定してください。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 6 plus the length of the Host Name.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLengthはHost Nameの6と長さです。
Router ID (SCCRQ, SCCRP)
ルータID(SCCRQ、SCCRP)
The Router ID AVP, Attribute Type 60, is an identifier used to
identify an LCCE for control connection setup, tie breaking,
and/or tunnel authentication.
Router ID AVP(Attribute Type60)はコントロール接続設定のためにLCCEを特定するのに使用される識別子、繋がりの壊す、そして/または、トンネル認証です。
Lau, et al. Standards Track [Page 44] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[44ページ]RFC3931L2TPv3 March 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Router Identifier is a 4-octet unsigned integer. Its value is
unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host
Name AVP and/or Router ID AVP MUST be used to identify an LCCE as
described in Section 3.3.
Router Identifierは4八重奏の符号のない整数です。 [RFC2072]のセクション8.1あたり1与えられたLCCEに、値はユニークです。 Host Name AVP、そして/または、Router ID AVP MUST、使用されて、セクション3.3で説明されるようにLCCEを特定してください。
Implementations MUST NOT assume that Router Identifier is a valid
IP address. The Router Identifier for L2TP over IPv6 can be
obtained from an IPv4 address (if available) or via unspecified
implementation-specific means.
実装は、Router Identifierが有効なIPアドレスであると仮定してはいけません。 IPv4アドレス(利用可能であるなら)か不特定の実装特有の手段でIPv6の上のL2TPのためのRouter Identifierを入手できます。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 10.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLengthは10歳です。
Vendor Name (SCCRQ, SCCRP)
ベンダー名(SCCRQ、SCCRP)
The Vendor Name AVP, Attribute Type 8, contains a vendor-specific
(possibly human-readable) string describing the type of LAC or LNS
being used.
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 US-ASCII charset [RFC1958, RFC2277].
Vendor Nameはベンダーストリングを表す八重奏の示された数です。 人間読み込み可能なテキスト、このAVP MUSTには、米国-ASCII charset[RFC1958、RFC2277]に供給してください。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 6 plus the length of the
Vendor Name.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)はVendor Nameの6と長さです。
Lau, et al. Standards Track [Page 45] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[45ページ]RFC3931L2TPv3 March 2005
Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
割り当てられたコントロール接続ID(SCCRQ、SCCRP、StopCCN)
The Assigned Control Connection ID AVP, Attribute Type 61,
contains the ID being assigned to this control connection by the
sender.
Assigned Control Connection ID AVP(Attribute Type61)は送付者によってこのコントロール接続に割り当てられるIDを含んでいます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Control Connection 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Control Connection ID is a 4-octet non-zero unsigned
integer.
Assigned Control Connection IDは4八重奏の非ゼロです。符号のない整数。
The Assigned Control Connection ID AVP establishes the identifier
used to multiplex and demultiplex multiple control connections
between a pair of LCCEs. Once the Assigned Control Connection ID
AVP has been received by an LCCE, the Control Connection ID
specified in the AVP MUST be included in the Control Connection ID
field of all control packets sent to the peer for the lifetime of
the control connection. Before the Assigned Control Connection ID
AVP is received from a peer, all control messages MUST be sent to
that peer with a Control Connection ID value of 0 in the header.
Because a Control Connection ID value of 0 is used in this special
manner, the zero value MUST NOT be sent as an Assigned Control
Connection ID value.
Assigned Control Connection ID AVPは1組のLCCEsの間の多重送信するのにおいて中古の識別子と「反-マルチプレックス」複合管理接続を確立します。 いったんAssigned Control Connection ID AVPを受け取った後、LCCE、IDがAVP MUSTで指定したControl Connectionがコントロール接続の生涯のための同輩に送られたすべてのコントロールパケットのControl Connection ID分野で含めてください。 同輩からAssigned Control Connection ID AVPを受け取る前に、0のControl Connection ID価値がヘッダーにある状態で、すべてのコントロールメッセージをその同輩に送らなければなりません。 0のControl Connection ID価値がこの特別な方法で使用されるので、Assigned Control Connection ID価値として送られてはいけませんゼロが、評価する。
Under certain circumstances, an LCCE may need to send a StopCCN to
a peer without having yet received an Assigned Control Connection
ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet).
In this case, the Assigned Control Connection ID AVP that had been
sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the
Assigned Control Connection ID AVP in the StopCCN. This policy
allows the peer to try to identify the appropriate control
connection via a reverse lookup.
ある状況で、LCCEは、同輩からAssigned Control Connection ID AVPをまだ受けていなくてStopCCNを同輩に送る必要があるかもしれません(すなわち、SCCRQが発信しました、まだ受け取られていなかったSCCRP全く)。 この場合、Assigned Control Connection ID AVPとしてStopCCNでより多くの早さに(すなわち、SCCRQで)同輩に送られたAssigned Control Connection ID AVPを送らなければなりません。 この方針で、同輩は逆のルックアップで適切なコントロール接続を特定しようとすることができます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 10.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は10歳です。
Receive Window Size (SCCRQ, SCCRP)
レシーブ・ウィンドウ・サイズ(SCCRQ、SCCRP)
The Receive Window Size AVP, Attribute Type 10, specifies the
receive window size being offered to the remote peer.
Receive Window Size AVP(Attribute Type10)はリモート同輩に提供されるレシーブ・ウィンドウ・サイズを指定します。
Lau, et al. Standards Track [Page 46] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[46ページ]RFC3931L2TPv3 March 2005
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.
休んで、同輩が4のWindow Sizeを仮定しなければならないかどうか、それ、窓を伝えてください。
The remote peer may send the specified number of control messages
before it must wait for an acknowledgment. See Section 4.2 for
more information on reliable control message delivery.
承認を待たなければならない前にリモート同輩はコントロールメッセージの指定された数を送るかもしれません。 信頼できるコントロールメッセージ配送の詳しい情報に関してセクション4.2を見てください。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 8.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLengthは8歳です。
Pseudowire Capabilities List (SCCRQ, SCCRP)
Pseudowire能力リスト(SCCRQ、SCCRP)
The Pseudowire Capabilities List (PW Capabilities List) AVP,
Attribute Type 62, indicates the L2 payload types the sender can
support. The specific payload type of a given session is
identified by the Pseudowire Type AVP.
Pseudowire Capabilities List(PW Capabilities List)AVP(Attribute Type62)は送付者がサポートすることができるL2ペイロードタイプを示します。 与えられたセッションの特定のペイロードタイプはPseudowire Type AVPによって特定されます。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWは0をタイプします。| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | PWはNをタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined PW types that may appear in this list are managed by IANA
and will appear in associated pseudowire-specific documents for
each PW type.
このリストに現れるかもしれない定義されたPWタイプが、IANAによって管理されて、関連pseudowire特有のドキュメントにそれぞれのPWタイプに関して現れるでしょう。
If a sender includes a given PW type in the PW Capabilities List
AVP, the sender assumes full responsibility for supporting that
particular payload, such as any payload-specific AVPs, L2-Specific
Sublayer, or control messages that may be defined in the
appropriate companion document.
送付者がPW Capabilities List AVPの与えられたPWタイプを入れるなら、送付者はその特定のペイロードを支えることへの完全な責任を負います、ペイロード特有のいずれもAVPs、L2特有のSublayer、または適切な仲間ドキュメントで定義されるかもしれないコントロールメッセージなどのように。
Lau, et al. Standards Track [Page 47] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[47ページ]RFC3931L2TPv3 March 2005
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 8 octets with one PW type
specified, plus 2 octets for each additional PW type.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は1つのPWタイプが指定されている8つの八重奏と、それぞれの追加PWタイプあたり2つの八重奏です。
Preferred Language (SCCRQ, SCCRP)
都合のよい言語(SCCRQ、SCCRP)
The Preferred Language AVP, Attribute Type 72, provides a method
for an LCCE to indicate to the peer the language in which human-
readable messages it sends SHOULD be composed. This AVP contains
a single language tag or language range [RFC3066].
Preferred Language AVP(Attribute Type72)はLCCEが、それがどの人間の読み込み可能なメッセージにSHOULDを送るかで言語が構成されるのを同輩に示すメソッドを提供します。 このAVPは単一の言語タグか言語範囲[RFC3066]を含んでいます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Language... (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 Preferred Language is the indicated number of octets
representing the language tag or language range, encoded in the
US-ASCII charset.
Preferred Languageは米国-ASCII charsetでコード化された言語タグか言語範囲を表す八重奏の示された数です。
It is not required to send a Preferred Language AVP. If (1) an
LCCE does not signify a language preference by the inclusion of
this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP is
unrecognized, or (3) the requested language is not supported by
the peer LCCE, the default language [RFC2277] MUST be used for all
internationalized strings sent by the peer.
それは、Preferred Language AVPを送るのに必要ではありません。 要求された言語は同輩LCCEによってサポートされません、そして、(2) (1) LCCEがSCCRQかSCCRPでのこのAVPの包含で言語優先を意味しないなら、Preferred Language AVPが認識されていないか、または(3) 同輩によって送られたすべての国際化しているストリングに、デフォルト言語[RFC2277]を使用しなければなりません。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 6 plus the length of the
Preferred Language.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)はPreferred Languageの6と長さです。
5.4.4. Session Management AVPs
5.4.4. セッション管理AVPs
Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
地方のSession ID(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、CDN、こぶ、SLI)
The Local Session ID AVP (analogous to the Assigned Session ID in
L2TPv2), Attribute Type 63, contains the identifier being assigned
to this session by the sender.
Local Session ID AVP(L2TPv2のAssigned Session IDに類似の)(Attribute Type63)はこのセッションまで送付者によって割り当てられる識別子を含んでいます。
Lau, et al. Standards Track [Page 48] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[48ページ]RFC3931L2TPv3 March 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Session 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地方のSession ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Local Session ID is a 4-octet non-zero unsigned integer.
Local Session IDは4八重奏の非ゼロです。符号のない整数。
The Local Session ID AVP establishes the two identifiers used to
multiplex and demultiplex sessions between two LCCEs. Each LCCE
chooses any free value it desires, and sends it to the remote LCCE
using this AVP. The remote LCCE MUST then send all data packets
associated with this session using this value. Additionally, for
all session-oriented control messages sent after this AVP is
received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST
echo this value in the Remote Session ID AVP.
Local Session ID AVPは2LCCEsの間の多重送信するのにおいて中古の2つの識別子と「反-マルチプレックス」セッションを確立します。 各LCCEは、それが望んでいるどんな自由な値も選んで、このAVPを使用することでリモートLCCEにそれを送ります。 そしてリモートLCCE MUSTはこの値を使用するこのセッションに関連しているすべてのデータ・パケットを送ります。 さらに、このAVPが受け取られていた後に送られたすべてのセッション指向のコントロールメッセージ(例えば、ICRP、ICCN、CDN、SLIなど)に関して、リモートLCCE MUSTはRemote Session ID AVPでこの値を反響します。
Note that a Session ID value is unidirectional. Because each LCCE
chooses its Session ID independent of its peer LCCE, the value
does not have to match in each direction for a given session.
Session ID価値が単方向であることに注意してください。 各LCCEが同輩LCCEの如何にかかわらずSession IDを選ぶので、値は与えられたセッションのための各方向に合う必要はありません。
See Section 4.1 for additional information about the Session ID.
Session IDに関する追加情報に関してセクション4.1を見てください。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2).
The Length (before hiding) of this AVP is 10.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1セット対1セットですが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は10歳です。
Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
遠く離れたSession ID(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、CDN、こぶ、SLI)
The Remote Session ID AVP, Attribute Type 64, contains the
identifier that was assigned to this session by the peer.
Remote Session ID AVP(Attribute Type64)はこのセッションまで同輩によって割り当てられた識別子を含んでいます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたSession ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote Session ID is a 4-octet non-zero unsigned integer.
Remote Session IDは4八重奏の非ゼロです。符号のない整数。
The Remote Session ID AVP MUST be present in all session-level
control messages. The AVP's value echoes the session identifier
advertised by the peer via the Local Session ID AVP. It is the
same value that will be used in all transmitted data messages by
Remote Session ID AVP MUST、すべてのセッションレベルコントロールメッセージに存在してください。 AVPの値はLocal Session ID AVPを通しての同輩によって広告に掲載されたセッション識別子を反映します。 それは中にすべて伝えられた中古のデータメッセージになる同じ値です。
Lau, et al. Standards Track [Page 49] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[49ページ]RFC3931L2TPv3 March 2005
this side of the session. In most cases, this identifier is
sufficient for the peer to look up session-level context for this
control message.
セッションの手前。 多くの場合、同輩がこのコントロールメッセージのためにセッションレベル文脈を調べるように、この識別子は十分です。
When a session-level control message must be sent to the peer
before the Local Session ID AVP has been received, the value of
the Remote Session ID AVP MUST be set to zero. Additionally, the
Local Session ID AVP (sent in a previous control message for this
session) MUST be included in the control message. The peer must
then use the Local Session ID AVP to perform a reverse lookup to
find its session context. Session-level control messages defined
in this document that might be subject to a reverse lookup by a
receiving peer include the CDN, WEN, and SLI.
以前セッションレベルコントロールメッセージを同輩に送らなければならないとき、Local Session ID AVPを受け取りました、Remote Session ID AVP MUSTの値。ゼロに設定されます。 さらに、コントロールメッセージにLocal Session ID AVP(このセッションへの前のコントロールメッセージを送る)を含まなければなりません。 そして、同輩は、セッション文脈を見つけるために逆のルックアップを実行するのにLocal Session ID AVPを使用しなければなりません。 本書では定義された受信同輩で逆のルックアップを受けることがあるかもしれないセッションレベルコントロールメッセージはCDN、WEN、およびSLIを含んでいます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 10.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は10歳です。
Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)
割り当てられたクッキー(ICRQ、ICRP、OCRQ、OCRP)
The Assigned Cookie AVP, Attribute Type 65, contains the Cookie
value being assigned to this session by the sender.
Assigned Cookie AVP(Attribute Type65)はこのセッションまで送付者によって割り当てられるCookie値を含んでいます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Cookie (32 or 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie(32ビットか64ビット)を割り当てます… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Cookie is a 4-octet or 8-octet random value.
Assigned Cookieは4八重奏か8八重奏の無作為の値です。
The Assigned Cookie AVP contains the value used to check the
association of a received data message with the session identified
by the Session ID. All data messages sent to a peer MUST use the
Assigned Cookie sent by the peer in this AVP. The value's length
(0, 32, or 64 bits) is obtained by the length of the AVP.
Assigned Cookie AVPはSession IDによって特定されるセッションに受信データメッセージの協会について問い合わせるのに使用される値を含んでいます。 同輩に送られたすべてのデータメッセージがこのAVPで同輩によって送られたAssigned Cookieを使用しなければなりません。 AVPの長さで、値の長さ(0ビットか32ビットか64ビット)を得ます。
A missing Assigned Cookie AVP or Assigned Cookie Value of zero
length indicates that the Cookie field should not be present in
any data packets sent to the LCCE sending this AVP.
ゼロ・レングスのなくなったAssigned Cookie AVPかAssigned Cookie Valueが、Cookie分野がこのAVPを送るLCCEに送られたどんなデータ・パケットにも存在しているべきでないのを示します。
See Section 4.1 for additional information about the Assigned
Cookie.
Assigned Cookieに関する追加情報に関してセクション4.1を見てください。
Lau, et al. Standards Track [Page 50] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[50ページ]RFC3931L2TPv3 March 2005
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP may be 6, 10, or 14 octets.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は6、10、または14の八重奏であるかもしれません。
Serial Number (ICRQ, OCRQ)
通し番号(ICRQ、OCRQ)
The Serial Number AVP, Attribute Type 15, contains an identifier
assigned by the LAC or LNS to this session.
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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Serial Number is a 32-bit value.
Serial Numberは32ビットの値です。
The Serial Number is intended to be an easy reference for
administrators on both ends of a control connection to use when
investigating session failure problems. Serial Numbers should be
set to progressively increasing values, which are likely to be
unique for a significant period of time across all interconnected
LNSs and LACs.
Serial Numberはセッション失敗問題を調査するときコントロール接続の両端の管理者が使用する簡単な参照であることを意図します。すべての向こう側の重要な期間がLNSsとLACsとインタコネクトしたので、連続の民数記は次第に、値を増強するのに設定されるべきです。(値は特有である傾向があります)。
Note that in RFC 2661, this value was referred to as the "Call
Serial Number AVP". It serves the same purpose and has the same
attribute value and composition.
RFC2661では、この値が「呼び出し通し番号AVP」と呼ばれたことに注意してください。 それは、同じ目的に役立って、同じ属性値と構成を持っています。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 10.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は10歳です。
Remote End ID (ICRQ, OCRQ)
リモートエンドID(ICRQ、OCRQ)
The Remote End ID AVP, Attribute Type 66, contains an identifier
used to bind L2TP sessions to a given circuit, interface, or
bridging instance. It also may be used to detect session-level
ties.
Remote End ID AVP(Attribute Type66)は与えられた回路、インタフェース、またはブリッジするインスタンスにL2TPセッションを縛るのに使用される識別子を含んでいます。 また、それは、セッションレベル結びつきを検出するのに使用されるかもしれません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote End Identifier ... (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リモートエンド識別子… (八重奏の特殊活字の数字) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lau, et al. Standards Track [Page 51] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[51ページ]RFC3931L2TPv3 March 2005
The Remote End Identifier field is a variable-length field whose
value is unique for a given LCCE peer, as described in Section
3.3.
Remote End Identifier分野は与えられたLCCE同輩にとって、値がユニークである可変長の分野です、セクション3.3で説明されるように。
A session-level tie is detected if an LCCE receives an ICRQ or
OCRQ with an End ID AVP whose value matches that which was just
sent in an outgoing ICRQ or OCRQ to the same peer. If the two
values match, an LCCE recognizes that a tie exists (i.e., both
LCCEs are attempting to establish sessions for the same circuit).
The tie is broken by the Session Tie Breaker AVP.
LCCEが値が出発しているICRQかOCRQでただ同じ同輩に送られたそれに合っているEnd ID AVPと共にICRQかOCRQを受けるなら、セッションレベル繋がりは検出されます。 2つの値が合っているなら、LCCEは、繋がりが存在すると認めます(すなわち両方のLCCEsは、同じ回路のためのセッションを確立するのを試みています)。 繋がりはSession Tie Breaker AVPによって壊されます。
By default, the LAC-LAC cross-connect application (see Section
2(b)) of L2TP over an IP network MUST utilize the Router ID AVP
and Remote End ID AVP to associate a circuit to an L2TP session.
Other AVPs MAY be used for LCCE or circuit identification as
specified in companion documents.
デフォルトで、LAC-LAC十字接続アプリケーション、(IPネットワークの上のL2TPのセクション2(b))がL2TPセッションまで回路を関連づけるのにRouter ID AVPとRemote End ID AVPを利用しなければならないのを確実にしてください。 他のAVPsは仲間ドキュメントにおける指定されるとしてのLCCEか回路識別に使用されるかもしれません。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 6 plus the length of the
Remote End Identifier value.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)はRemote End Identifier価値の6と長さです。
Session Tie Breaker (ICRQ, OCRQ)
セッションタイブレーク(ICRQ、OCRQ)
The Session Tie Breaker AVP, Attribute Type 5, is used to break
ties when two peers concurrently attempt to establish a session
for the same circuit.
Session Tie Breaker AVP(Attribute Type5)は、2人の同輩が、同時に同じ回路のためのセッションを確立するのを試みるとき、結びつきを壊すのに使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Tie Breaker 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 Session Tie Breaker Value is an 8-octet random value that is
used to choose a session when two LCCEs concurrently request a
session for the same circuit. A tie is detected by examining the
peer's identity (described in Section 3.3) plus the per-session
shared value communicated via the End ID AVP. In the case of a
tie, the recipient of an ICRQ or OCRQ must compare the received
tie breaker value with the one that it sent earlier. The LCCE
with the lower value "wins" and MUST send a CDN with result code
set to 13 (as defined in Section 5.4.2) in response to the losing
ICRQ or OCRQ. In the case in which a tie is detected, tie
Session Tie Breaker Valueは2LCCEsが同時に同じ回路のためのセッションを要求するセッション、選ぶのに使用される8八重奏の無作為の値です。 繋がりは、同輩のアイデンティティ(セクション3.3では、説明される)とEnd ID AVPを通して伝えられた1セッションあたりの共有された値を調べることによって、検出されます。 繋がりの場合では、ICRQかOCRQの受取人はそれが、より早く送ったものと容認されたタイブレーク値を比べなければなりません。 下側の値があるLCCEは「勝っ」て、損をしているICRQかOCRQに対応して13(セクション5.4.2で定義されるように)に設定された結果コードがあるCDNを送らなければなりません。 場合では、繋がりがどれであるかに検出されて、つながってください。
Lau, et al. Standards Track [Page 52] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[52ページ]RFC3931L2TPv3 March 2005
breakers are sent by both sides, and the tie breaker values are
equal, both sides MUST discard their sessions and restart session
negotiation with new random tie breaker values.
両側でブレーカーを送ります、そして、タイブレーク値が等しい、両側は新しい無作為のタイブレーク値との彼らのセッションと再開セッション交渉を捨てなければなりません。
If a tie is detected but only one side sends a Session Tie Breaker
AVP, the session initiator that included the Session Tie Breaker
AVP "wins". If neither side issues a tie breaker, then both sides
MUST tear down the session.
繋がりが検出されるか、しかし、半面だけがSession Tie Breaker AVP(Session Tie Breaker AVP「勝利」を含んでいたセッション創始者)を送ります。 どちらの副次的な問題であるなら、タイブレーク、当時の両側はセッションを取りこわさなければなりません。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length of this AVP is 14.
このAVP MUST NOT、隠されてください(Hビットは0であるに違いありません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLengthは14歳です。
Pseudowire Type (ICRQ, OCRQ)
Pseudowireはタイプします。(ICRQ、OCRQ)
The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates
the L2 payload type of the packets that will be tunneled using
this L2TP session.
Pseudowire Type(PW Type)AVP(Attribute Type68)はこのL2TPセッションを使用することでトンネルを堀られるパケットのL2ペイロードタイプを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer MUST NOT request an incoming or outgoing call with a PW
Type AVP specifying a value not advertised in the PW Capabilities
List AVP it received during control connection establishment.
Attempts to do so MUST result in the call being rejected via a CDN
with the Result Code set to 14 (see Section 5.4.2).
同輩は、PW Type AVPが値を指定している入って来るか外向的な呼び出しがそれがコントロールコネクション確立の間に受けたPW Capabilities List AVPに広告を出さなかったよう要求してはいけません。 そうする試みはResult CodeセットがあるCDNを通して14に拒絶される呼び出しをもたらさなければなりません(セクション5.4.2を見てください)。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 8.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は8歳です。
L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
L2特有の副層(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN)
The L2-Specific Sublayer AVP, Attribute Type 69, indicates the
presence and format of the L2-Specific Sublayer the sender of this
AVP requires on all incoming data packets for this L2TP session.
L2特有のSublayer AVP(Attribute Type69)はこのAVPの送付者がこのL2TPセッションのためにすべての受信データパケットの上で必要とするL2特有のSublayerの存在と書式を示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2特有の副層タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lau, et al. Standards Track [Page 53] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[53ページ]RFC3931L2TPv3 March 2005
The L2-Specific Sublayer Type is a 2-octet unsigned integer with
the following values defined in this document:
L2特有のSublayer Typeは以下の値が本書では定義されている2八重奏の符号のない整数です:
0 - There is no L2-Specific Sublayer present.
1 - The Default L2-Specific Sublayer (defined in Section 4.6)
is used.
0--どんなL2特有の存在しているSublayerもありません。 1--Default L2特有のSublayer(セクション4.6では、定義される)は使用されています。
If this AVP is received and has a value other than zero, the
receiving LCCE MUST include the identified L2-Specific Sublayer in
its outgoing data messages. If the AVP is not received, it is
assumed that there is no sublayer present.
このAVPが受け取られていて、ゼロ以外の値を持っているなら、受信LCCE MUSTは発信データメッセージに特定されたL2特有のSublayerを含んでいます。 AVPが受け取られていないなら、どんな存在している副層もないと思われます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 8.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は8歳です。
Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
データ配列(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN)
The Data Sequencing AVP, Attribute Type 70, indicates that the
sender requires some or all of the data packets that it receives
to be sequenced.
Data Sequencing AVP(Attribute Type70)は、送付者が、それが受けるデータ・パケットのいくつかかすべてが配列されるのを必要とするのを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequencing Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ配列レベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data Sequencing Level is a 2-octet unsigned integer indicating
the degree of incoming data traffic that the sender of this AVP
wishes to be marked with sequence numbers.
Data Sequencing LevelはこのAVPの送付者が一連番号でマークされて欲しい受信データトラフィックの度合いを示す2八重奏の符号のない整数です。
Defined Data Sequencing Levels are as follows:
定義されたData Sequencing Levelsは以下の通りです:
0 - No incoming data packets require sequencing.
1 - Only non-IP data packets require sequencing.
2 - All incoming data packets require sequencing.
0--どんな受信データパケットも、配列するのを必要としません。 1--非IPデータ・パケットだけが、配列するのを必要とします。 2--すべての受信データパケットが、配列するのを必要とします。
If a Data Sequencing Level of 0 is specified, there is no need to
send packets with sequence numbers. If sequence numbers are sent,
they will be ignored upon receipt. If no Data Sequencing AVP is
received, a Data Sequencing Level of 0 is assumed.
0のData Sequencing Levelが指定されるなら、一連番号と共にパケットを送る必要は全くありません。 一連番号を送ると、領収書でそれらを無視するでしょう。 どんなData Sequencing AVPも受け取られていないなら、0のData Sequencing Levelは想定されます。
If a Data Sequencing Level of 1 is specified, only non-IP traffic
carried within the tunneled L2 frame should have sequence numbers
applied. Non-IP traffic here refers to any packets that cannot be
1のData Sequencing Levelが指定されるなら、トンネルを堀られたL2フレームの中に運ばれた非IPトラフィックだけで、一連番号を適用するべきです。 ここの非IPトラフィックはそれがどんなパケットであることができるのについても言及します。
Lau, et al. Standards Track [Page 54] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[54ページ]RFC3931L2TPv3 March 2005
classified as an IP packet within their respective L2 framing
(e.g., a PPP control packet or NETBIOS frame encapsulated by Frame
Relay before being tunneled). All traffic that can be classified
as IP MUST be sent with no sequencing (i.e., the S bit in the L2-
Specific Sublayer is set to zero). If a packet is unable to be
classified at all (e.g., because it has been compressed or
encrypted at layer 2) or if an implementation is unable to perform
such classification within L2 frames, all packets MUST be provided
with sequence numbers (essentially falling back to a Data
Sequencing Level of 2).
IPパケットとして、彼らのそれぞれのL2縁どり(例えばトンネルを堀られる前にFrame Relayによってカプセルに入れられたPPPコントロールパケットかNETBIOSフレーム)の中で分類されています。 配列なしでIPとして分類できるすべてのトラフィックを送らなければなりません(すなわち、L2の特定のSublayerのSビットはゼロに設定されます)。 パケットが全く分類できないか(例えば、層2にそれを圧縮されるか、または暗号化してあるので)、または実装がL2フレームの中にそのような分類を実行できないなら、すべてのパケットに一連番号を提供しなければなりません(本質的には2のData Sequencing Levelへ後ろへ下がって)。
If a Data Sequencing Level of 2 is specified, all traffic MUST be
sequenced.
2のData Sequencing Levelが指定されるなら、すべてのトラフィックを配列しなければなりません。
Data sequencing may only be requested when there is an L2-Specific
Sublayer present that can provide sequence numbers. If sequencing
is requested without requesting a L2-Specific Sublayer AVP, the
session MUST be disconnected with a Result Code of 15 (see Section
5.4.2).
一連番号を提供できるL2特有のSublayerプレゼントがあるときだけ、データ配列は要求されるかもしれません。 配列がL2特有のSublayer AVPを要求しないで要求されるなら、15のResult Codeと共にセッションから切断しなければなりません(セクション5.4.2を見てください)。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 8.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は8歳です。
Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
Txは速度を接続します。(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN)
The Tx Connect Speed BPS AVP, Attribute Type 74, contains the
speed of the facility chosen for the connection attempt.
Tx Connect Speed BPS AVP(Attribute Type74)は接続試みに選ばれた施設の速度を含んでいます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ビーピーエスでSpeedを接続してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...ビーピーエス(64ビット)でSpeedを接続してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tx Connect Speed BPS is an 8-octet value indicating the speed
in bits per second. A value of zero indicates that the speed is
indeterminable or that there is no physical point-to-point link.
Tx Connect Speed BPSはbpsにおける速度を示す8八重奏の値です。 ゼロの値は、速度が確定できないか、またはどんな物理的なポイントツーポイント接続もないのを示します。
When the optional Rx Connect Speed AVP is present, the value in
this AVP represents the transmit connect speed from the
perspective of the LAC (i.e., data flowing from the LAC to the
remote system). When the optional Rx Connect Speed AVP is NOT
present, the connection speed between the remote system and LAC is
伝えてください。このAVPの値が、いつ任意のRx Connect Speed AVPが存在していると表すか、LAC(すなわち、LACからリモートシステムまで流れるデータ)の見解から速度を接続してください。 任意のRx Connect Speed AVPが存在していないとき、リモートシステムとLACの間の接続速度は存在しています。
Lau, et al. Standards Track [Page 55] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[55ページ]RFC3931L2TPv3 March 2005
assumed to be symmetric and is represented by the single value in
this AVP.
左右対称であると仮定して、このAVPにただ一つの値によって表されます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 14.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は14歳です。
Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
Rxは速度を接続します。(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN)
The Rx Connect Speed AVP, Attribute Type 75, represents the speed
of the connection from the perspective of the LAC (i.e., data
flowing from the remote system to the LAC).
Rx Connect Speed AVP(Attribute Type75)は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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ビーピーエスでSpeedを接続してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...ビーピーエス(64ビット)でSpeedを接続してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connect Speed BPS is an 8-octet value indicating the speed in bits
per second. A value of zero indicates that the speed is
indeterminable or that there is no physical point-to-point link.
接続してください。Speed BPSはbpsにおける速度を示す8八重奏の値です。 ゼロの値は、速度が確定できないか、またはどんな物理的なポイントツーポイント接続もないのを示します。
Presence of this AVP implies that the connection speed may be
asymmetric with respect to the transmit connect speed given in the
Tx Connect Speed AVP.
伝えてください。このAVPの存在が、接続速度が非対称であるかもしれないことを含意する、Tx Connect Speed AVPで考えて、速度を接続してください。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 14.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は14歳です。
Physical Channel ID (ICRQ, ICRP, OCRP)
物理的なチャンネルID(ICRQ、ICRP、OCRP)
The Physical Channel ID AVP, Attribute Type 25, contains the
vendor-specific physical channel number used for a call.
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lau, et al. Standards Track [Page 56] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[56ページ]RFC3931L2TPv3 March 2005
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 SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 10.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は10歳です。
5.4.5. Circuit Status AVPs
5.4.5. 回路状態AVPs
Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)
回路状態(ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、SLI)
The Circuit Status AVP, Attribute Type 71, indicates the initial
status of or a status change in the circuit to which the session
is bound.
Circuit Status AVP、Attribute Type71が初期の状態を示すか、またはa状態が変える、セッションが制限されている回路で。
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 |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|N|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The A (Active) bit indicates whether the circuit is
up/active/ready (1) or down/inactive/not-ready (0).
A(アクティブ)のビットは、回路が上がるかアクティブであるか持ち合わせの(1)かそれとも下がるか不活発であるか持ち合わせでない(0)であるかを示します。
The N (New) bit indicates whether the circuit status indication is
for a new circuit (1) or an existing circuit (0). Links that have
a similar mechanism available (e.g., Frame Relay) MUST map the
setting of this bit to the associated signaling for that link.
Otherwise, the New bit SHOULD still be set the first time the L2TP
session is established after provisioning.
(新しい)のNビットは、新しい回路(1)か既存の回路(0)には回路状態指示があるかを示します。 利用可能な同様のメカニズム(例えば、Frame Relay)を持っているリンクはそのリンクのためにこのビットの設定を関連シグナリングに写像しなければなりません。 さもなければ、NewはSHOULDに噛み付きました、それでも、食糧を供給したL2TPセッションが確立している後1回目に用意ができてください。
The remaining bits are reserved for future use. Reserved bits
MUST be set to 0 when sending and ignored upon receipt.
残っているビットは今後の使用のために予約されます。 予約されたビットを発信するとき、0に設定されて、領収書で無視しなければなりません。
The Circuit Status AVP is used to advertise whether a circuit or
interface bound to an L2TP session is up and ready to send and/or
receive traffic. Different circuit types have different names for
status types. For example, HDLC primary and secondary stations
refer to a circuit as being "Receive Ready" or "Receive Not
Ready", while Frame Relay refers to a circuit as "Active" or
"Inactive". This AVP adopts the latter terminology, though the
concept remains the same regardless of the PW type for the L2TP
session.
Circuit Status AVPは、L2TPセッションまで縛られた回路かインタフェースがトラフィックを上がって送る、そして/または、受ける準備ができているか否かに関係なく、広告を出すのに使用されます。 異なった回路タイプには、状態タイプのための異なった名前があります。 例えば、HDLC予備選挙と二次局は「準備ができていた状態で、受信してください」であるか「準備ができていなかった状態で、受信してください」と回路を呼びます、Frame Relayは「アクティブである」か「不活発である」と回路を呼びますが。 このAVPは後者の用語を採用します、概念がL2TPセッションのためのPWタイプにかかわらず同じままで残っていますが。
Lau, et al. Standards Track [Page 57] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[57ページ]RFC3931L2TPv3 March 2005
In the simplest case, the circuit to which this AVP refers is a
single physical interface, port, or circuit, depending on the
application and the session setup. The status indication in this
AVP may then be used to provide simple ILMI interworking for a
variety of circuit types. For virtual or multipoint interfaces,
the Circuit Status AVP is still utilized, but in this case, it
refers to the state of an internal structure or a logical set of
circuits. Each PW-specific companion document MUST specify
precisely how this AVP is translated for each circuit type.
このAVPが参照する回路は、最も簡単な場合では、単一の物理インターフェース、ポート、または回路です、アプリケーションとセッションセットアップによって。 そして、このAVPの状態指示は、さまざまな回路にタイプを織り込む簡単なILMIを提供するのに使用されるかもしれません。 仮想か多点インタフェースにおいて、Circuit Status AVPはまだ利用されていますが、この場合、それは内部の構造か論理的な回路の状態について言及します。 それぞれのPW特有の仲間ドキュメントはこのAVPがそれぞれの回路タイプのために正確にどう翻訳されるかを指定しなければなりません。
If this AVP is received with a Not Active notification for a given
L2TP session, all data traffic for that session MUST cease (or not
begin) in the direction of the sender of the Circuit Status AVP
until the circuit is advertised as Active.
与えられたL2TPセッションのためのNot Active通知でこのAVPを受け取るなら、回路がActiveとして広告に掲載されるまで、そのセッションのためのすべてのデータ通信量がCircuit Status AVPの送付者の向きにやまなければなりません(または、始まりません)。
The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP,
OCRQ, and OCRP messages. Often, the circuit type will be marked
Active when initiated, but subsequently MAY be advertised as
Inactive. This indicates that an L2TP session is to be created,
but that the interface or circuit is still not ready to pass
traffic. The ICCN, OCCN, and SLI control messages all MAY contain
this AVP to update the status of the circuit after establishment
of the L2TP session is requested.
このAVPはICRQ、ICRP、OCRQ、およびOCRPメッセージにCircuit Statusの広告を出さなければなりません。 しばしば、回路タイプの開始するとActiveであるとマークしますが、次に、Inactiveとして広告を出すかもしれません。 これは、L2TPセッションが作成されることですが、インタフェースか回路をまだトラフィックを通過している準備ができていないのを示します。 ICCN、OCCN、およびすべての5月のSLIコントロールメッセージはL2TPセッションの設立が要求された後に回路の状態をアップデートするこのAVPを含んでいます。
If additional circuit status information is needed for a given PW
type, any new PW-specific AVPs MUST be defined in a separate
document. This AVP is only for general circuit status information
generally applicable to all circuit/interface types.
追加回路状態情報が与えられたPWタイプに必要であるなら、別々のドキュメントでどんな新しいPW特有のAVPsも定義しなければなりません。 このAVPは一般に、すべての回路/インターフェース型に適切な一般的な回路状態情報のためだけのものです。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 8.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、1に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は8歳です。
Circuit Errors (WEN)
回路誤り(こぶ)
The Circuit Errors AVP, Attribute Type 34, conveys circuit error
information to the peer.
Circuit Errors AVP(Attribute Type34)は回路エラー情報を同輩に伝えます。
Lau, et al. Standards Track [Page 58] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[58ページ]RFC3931L2TPv3 March 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 following fields are defined:
以下の分野は定義されます:
Reserved: 2 octets of Reserved data is present (providing longword
alignment within the AVP of the following values). Reserved
data MUST be zero on sending and ignored upon receipt.
Hardware Overruns: Number of receive buffer overruns since call
was established.
Buffer Overruns: Number of buffer overruns detected since call was
established.
Timeout Errors: Number of timeouts since call was established.
Alignment Errors: Number of alignment errors since call was
established.
予約される: Reservedデータの2つの八重奏が存在しています(以下の値のAVPの中でロングワード整列を提供して)。 領収書で発信して、無視されて、予約されたデータはオンであるはずがありません。 ハードウェアは氾濫します: 呼び出しが確立されたので、受信バッファの数は氾濫します。 超過をバッファリングしてください: 呼び出し以来検出されたバッファ超過の数は確立されました。 タイムアウト誤り: 呼び出し以来のタイムアウトの数は確立されました。 整列誤り: 呼び出し以来の整列誤りの数は確立されました。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 32.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 このAVP SHOULDのために噛み付かれたMは、0に設定されますが、異なるかもしれません(セクション5.2を見てください)。 このAVPのLength(隠れることの前の)は32歳です。
6. Control Connection Protocol Specification
6. コントロール接続プロトコル仕様
The following control messages are used to establish, maintain, and tear down L2TP control connections. All data packets are sent in network order (high-order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility.
以下のコントロールメッセージは、L2TPコントロール接続を確立して、維持して、取りこわすのに使用されます。 ネットワークオーダーですべてのデータ・パケットを送ります(八重奏に1番目を高値で命令してください)。 プロトコル伸展性を考慮するために0つの値としてどんな「予約された」か「空」の野原も送らなければなりません。
The exchanges in which these messages are involved are outlined in Section 3.3.
これらのメッセージがかかわる交換はセクション3.3に概説されています。
Lau, et al. Standards Track [Page 59] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[59ページ]RFC3931L2TPv3 March 2005
6.1. Start-Control-Connection-Request (SCCRQ)
6.1. コントロール接続要求を始めてください。(SCCRQ)
Start-Control-Connection-Request (SCCRQ) is a control message used to initiate a control connection between two LCCEs. It is sent by either the LAC or the LNS to begin the control connection establishment process.
スタートコントロール接続要求(SCCRQ)は2LCCEsの間のコントロール接続を開始するのに使用されるコントロールメッセージです。 それは、コントロールコネクション確立プロセスを開始するためにLACかLNSのどちらかによって送られます。
The following AVPs MUST be present in the SCCRQ:
以下のAVPsはSCCRQに存在していなければなりません:
Message Type
Host Name
Router ID
Assigned Control Connection ID
Pseudowire Capabilities List
コントロール接続ID Pseudowire能力リストが割り当てられたメッセージタイプホスト名前Router ID
The following AVPs MAY be present in the SCCRQ:
以下のAVPsはSCCRQに存在しているかもしれません:
Random Vector
Control Message Authentication Nonce
Message Digest
Control Connection Tie Breaker
Vendor Name
Receive Window Size
Preferred Language
無作為のベクトル制御のタイブレークベンダー名前レシーブ・ウィンドウ・サイズ都合のよい通報認証一回だけメッセージダイジェスト規制接続言語
6.2. Start-Control-Connection-Reply (SCCRP)
6.2. スタートコントロール接続回答(SCCRP)
Start-Control-Connection-Reply (SCCRP) is the control message sent in reply to a received SCCRQ message. The SCCRP is used to indicate that the SCCRQ was accepted and that establishment of the control connection should continue.
スタートコントロール接続回答(SCCRP)は受信されたSCCRQメッセージに対して送られたコントロールメッセージです。 SCCRPは、SCCRQを受け入れて、コントロール接続の設立が続くべきであるのを示すのに使用されます。
The following AVPs MUST be present in the SCCRP:
以下のAVPsはSCCRPに存在していなければなりません:
Message Type
Host Name
Router ID
Assigned Control Connection ID
Pseudowire Capabilities List
コントロール接続ID Pseudowire能力リストが割り当てられたメッセージタイプホスト名前Router ID
The following AVPs MAY be present in the SCCRP:
以下のAVPsはSCCRPに存在しているかもしれません:
Random Vector
Control Message Authentication Nonce
Message Digest
Vendor Name
Receive Window Size
Preferred Language
無作為のベクトル制御のメッセージダイジェストベンダー名前レシーブ・ウィンドウ・サイズ都合のよい通報認証一回だけ言語
Lau, et al. Standards Track [Page 60] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[60ページ]RFC3931L2TPv3 March 2005
6.3. Start-Control-Connection-Connected (SCCCN)
6.3. スタートコントロール接続は接続しました。(SCCCN)
Start-Control-Connection-Connected (SCCCN) is the control message sent in reply to an SCCRP. The SCCCN completes the control connection 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に存在してください:
Random Vector
Message Digest
無作為のベクトルメッセージダイジェスト
6.4. Stop-Control-Connection-Notification (StopCCN)
6.4. コントロール接続通知を止めてください。(StopCCN)
Stop-Control-Connection-Notification (StopCCN) is the control message sent by either LCCE to inform its peer that the control connection is being shut down and that the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit session control messages). The reason for issuing this request is indicated in the Result Code AVP. There is no explicit reply to the message, only the implicit ACK that is received by the reliable control message delivery layer.
停止コントロール接続通知(StopCCN)はコントロール接続が止められていて、コントロール接続が閉店するべきであることを同輩に知らせるためにLCCEによって送られたコントロールメッセージです。 さらに、すべての活発なセッションがそれとなくクリアされます(どんな明白なセッション制御メッセージも送らないで)。 この要求を出す理由はResult Code AVPで示されます。 メッセージ(信頼できるコントロールメッセージ配送層に受け取られる内在しているACKだけ)に関するどんな明白な回答もありません。
The following AVPs MUST be present in the StopCCN:
以下のAVPsはStopCCNに存在していなければなりません:
Message Type
Result Code
メッセージタイプ結果コード
The following AVPs MAY be present in the StopCCN:
以下のAVPsはStopCCNに存在しているかもしれません:
Random Vector
Message Digest
Assigned Control Connection ID
無作為のVectorメッセージダイジェスト割り当てられたコントロール接続ID
Note that the Assigned Control Connection ID MUST be present if the StopCCN is sent after an SCCRQ or SCCRP message has been sent.
SCCRQかSCCRPメッセージを送った後にStopCCNを送るならAssigned Control Connection IDが存在していなければならないことに注意してください。
6.5. Hello (HELLO)
6.5. こんにちは(こんにちは)
The Hello (HELLO) message is an L2TP control message sent by either peer of a control connection. This control message is used as a "keepalive" for the control connection. See Section 4.2 for a description of the keepalive mechanism.
Hello(HELLO)メッセージはコントロール接続のどちらの同輩によっても送られたL2TPコントロールメッセージです。 このコントロールメッセージはコントロール接続に"keepalive"として使用されます。 keepaliveメカニズムの記述に関してセクション4.2を見てください。
Lau, et al. Standards Track [Page 61] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[61ページ]RFC3931L2TPv3 March 2005
HELLO messages are global to the control connection. The Session ID in a HELLO message MUST be 0.
コントロール接続に、HELLOメッセージはグローバルです。 HELLOメッセージのSession IDは0であるに違いありません。
The following AVP MUST be present in the HELLO:
以下のAVP MUST、HELLOに存在してください:
Message Type
メッセージタイプ
The following AVP MAY be present in the HELLO:
以下のAVP MAY、HELLOに存在してください:
Random Vector
Message Digest
無作為のベクトルメッセージダイジェスト
6.6. Incoming-Call-Request (ICRQ)
6.6. 入って来る発呼要求(ICRQ)
Incoming-Call-Request (ICRQ) is the control message sent by an LCCE to a peer when an incoming call is detected (although the ICRQ may also be sent as a result of a local event). It is the first in a three-message exchange used for establishing a session via an L2TP control connection.
かかってきた電話が検出されるとき(また、ローカルイベントの結果、ICRQを送るかもしれませんが)、入って来る呼び出し要求(ICRQ)はLCCEによって同輩に送られたコントロールメッセージです。 それはL2TPコントロール接続でセッションを確立するのに使用される3交換処理で1番目です。
The ICRQ is used to indicate that a session is to be established between an LCCE and a peer. The sender of an ICRQ provides the peer with parameter information for the session. However, the sender makes no demands about how the session is terminated at the peer (i.e., whether the L2 traffic is processed locally, forwarded, etc.).
ICRQは、セッションがLCCEと同輩の間に設立されることであることを示すのに使用されます。 ICRQの送付者はセッションのためのパラメタ情報を同輩に提供します。 しかしながら、送付者はセッションが同輩でどう終えられるかに関して(すなわち、L2交通を局所的に処理されて、進めなどか否かに関係なく)要求を全くしません。
The following AVPs MUST be present in the ICRQ:
以下のAVPsはICRQに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
Serial Number
Pseudowire Type
Remote End ID
Circuit Status
地方のメッセージタイプのIDリモートセッションID通し番号セッションPseudowireはリモートエンドIDサーキット状態をタイプします。
The following AVPs MAY be present in the ICRQ:
以下のAVPsはICRQに存在しているかもしれません:
Random Vector
Message Digest
Assigned Cookie
Session Tie Breaker
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Physical Channel ID
無作為のベクトルメッセージダイジェストはタイブレークのL2特有の副層データ配列TxがRxが接続する速度を接続するクッキーセッションに速度の物理的なチャンネルIDを割り当てました。
Lau, et al. Standards Track [Page 62] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[62ページ]RFC3931L2TPv3 March 2005
6.7. Incoming-Call-Reply (ICRP)
6.7. 入って来る呼び出し回答(ICRP)
Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in response to a received ICRQ. It is the second in the three-message exchange used for establishing sessions within an L2TP control connection.
入って来る呼び出し回答(ICRP)は容認されたICRQに対応してLCCEによって送られたコントロールメッセージです。 L2TPコントロール接続の中でセッションを確立するのに使用される3交換処理でそれは2番目です。
The ICRP is used to indicate that the ICRQ was successful and that the peer should establish (i.e., answer) the incoming call if it has not already done so. It also allows the sender to indicate specific parameters about the L2TP session.
ICRPは、ICRQがうまくいって、既にそうしていないなら同輩がかかってきた電話を確立するべきであるのを(すなわち、答えます)示すのに使用されます。 また、それで、送付者はL2TPセッション頃に特定のパラメタを示すことができます。
The following AVPs MUST be present in the ICRP:
以下のAVPsはICRPに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
Circuit Status
ローカルのメッセージのIDリモートセッションIDサーキットタイプセッション状態
The following AVPs MAY be present in the ICRP:
以下のAVPsはICRPに存在しているかもしれません:
Random Vector
Message Digest
Assigned Cookie
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Physical Channel ID
無作為のベクトルのメッセージダイジェスト割り当てられたクッキーL2特有の副層データ配列Txが速度物理的にRxが接続する速度を接続する、チャンネルID
6.8. Incoming-Call-Connected (ICCN)
6.8. 入って来る接続完了(ICCN)
Incoming-Call-Connected (ICCN) is the control message sent by the LCCE that originally sent an ICRQ upon receiving an ICRP from its peer. It is the final message in the three-message exchange used for establishing L2TP sessions.
接続された入って来る要求(ICCN)は同輩からICRPを受けるとき元々ICRQを送ったLCCEによって送られたコントロールメッセージです。 L2TPセッションを確立するのに使用される3交換処理でそれは最終的なメッセージです。
The ICCN is used to indicate that the ICRP was accepted, that the call has been established, and that the L2TP session should move to the established state. It also allows the sender to indicate specific parameters about the established call (parameters that may not have been available at the time the ICRQ was issued).
ICCNは、ICRPを受け入れて、呼び出しが確立されて、L2TPセッションが設立された状態に動くべきであるのを示すのに使用されます。 また、それで、送付者は確立した要求(ICRQが発行されたとき利用可能でなかったかもしれないパラメタ)に関する特定のパラメタを示すことができます。
The following AVPs MUST be present in the ICCN:
以下のAVPsはICCNに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
メッセージのローカルのセッションIDリモートセッションタイプID
Lau, et al. Standards Track [Page 63] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[63ページ]RFC3931L2TPv3 March 2005
The following AVPs MAY be present in the ICCN:
以下のAVPsはICCNに存在しているかもしれません:
Random Vector
Message Digest
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Circuit Status
無作為のベクトルメッセージダイジェストL2特有の副層データ配列TxがRxが接続する速度を接続する、サーキット状態を促進してください。
6.9. Outgoing-Call-Request (OCRQ)
6.9. 送信する発呼要求(OCRQ)
Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE to an LAC to indicate that an outbound call at the LAC is to be established based on specific destination information sent in this message. It is the first in a three-message exchange used for establishing a session and placing a call on behalf of the initiating LCCE.
送信する呼び出し要求(OCRQ)はLACでの外国行きの呼び出しがこのメッセージで送られた特定の目的地情報に基づいて設立されることであることを示すためにLCCEによってLACに送られたコントロールメッセージです。 それは開始しているLCCEを代表してセッションを確立して、電話をするのに使用される3交換処理で1番目です。
Note that a call may be any L2 connection requiring well-known destination information to be sent from an LCCE to an LAC. This call could be a dialup connection to the PSTN, an SVC connection, the IP address of another LCCE, or any other destination dictated by the sender of this message.
呼び出しが周知の目的地情報がLCCEからLACに送られるのを必要とするあらゆるL2接続であるかもしれないことに注意してください。 この呼び出しはPSTNへの電話での接続であるかもしれません、とSVC接続、別のLCCEのIPアドレス、またはいかなる他の目的地もこのメッセージの送付者で決めました。
The following AVPs MUST be present in the OCRQ:
以下のAVPsはOCRQに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
Serial Number
Pseudowire Type
Remote End ID
Circuit Status
地方のメッセージタイプのIDリモートセッションID通し番号セッションPseudowireはリモートエンドIDサーキット状態をタイプします。
The following AVPs MAY be present in the OCRQ:
以下のAVPsはOCRQに存在しているかもしれません:
Random Vector
Message Digest
Assigned Cookie
Tx Connect Speed
Rx Connect Speed
Session Tie Breaker
L2-Specific Sublayer
Data Sequencing
無作為のベクトルメッセージダイジェスト、Txが接続するクッキーが割り当てられて、速度Rxは速度のセッションのタイブレークのL2特有の副層データ配列を接続します。
Lau, et al. Standards Track [Page 64] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[64ページ]RFC3931L2TPv3 March 2005
6.10. Outgoing-Call-Reply (OCRP)
6.10. 外向的な呼び出し回答(OCRP)
Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to an LCCE in response to a received OCRQ. It is the second in a three-message exchange used for establishing a session within an L2TP control connection.
外向的な呼び出し回答(OCRP)はLACによって容認されたOCRQに対応してLCCEに送られたコントロールメッセージです。 L2TPコントロール接続の中でセッションを確立するのに使用される3交換処理でそれは2番目です。
OCRP is used to indicate that the LAC has been able to attempt the outbound call. The message returns any relevant parameters regarding the call attempt. Data MUST NOT be forwarded until the OCCN is received, which indicates that the call has been placed.
OCRPは、LACが外国行きの呼び出しを試みることができたのを示すのに使用されます。 メッセージは呼び出し試みに関するどんな関連パラメタも返します。 OCCNが受け取られているまで、データを転送してはいけません(電話が出されたのを示します)。
The following AVPs MUST be present in the OCRP:
以下のAVPsはOCRPに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
Circuit Status
ローカルのメッセージのIDリモートセッションIDサーキットタイプセッション状態
The following AVPs MAY be present in the OCRP:
以下のAVPsはOCRPに存在しているかもしれません:
Random Vector
Message Digest
Assigned Cookie
L2-Specific Sublayer
Tx Connect Speed
Rx Connect Speed
Data Sequencing
Physical Channel ID
無作為のベクトルのメッセージダイジェスト割り当てられたクッキーL2特有の副層Txが速度データ配列物理的にRxが接続する速度を接続する、チャンネルID
6.11. Outgoing-Call-Connected (OCCN)
6.11. 外向的な接続完了(OCCN)
Outgoing-Call-Connected (OCCN) is the control message sent by an LAC to another LCCE after the OCRP and after the outgoing call has been completed. It is the final message in a three-message exchange used for establishing a session.
接続された外向的な要求(OCCN)はOCRP、発信電話が終了した後にLACによって別のLCCEに送られたコントロールメッセージです。 セッションを確立するのに使用される3交換処理でそれは最終的なメッセージです。
OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LCCE who requested the call about the particular parameters obtained after the call was established.
OCCNは、要求された発信電話の結果がうまくいったのを示すのに使用されます。 また、それは呼び出しが確立された後に得られた特定のパラメタに関して呼び出しを要求したLCCEに情報を供給します。
The following AVPs MUST be present in the OCCN:
以下のAVPsはOCCNに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
メッセージのローカルのセッションIDリモートセッションタイプID
Lau, et al. Standards Track [Page 65] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[65ページ]RFC3931L2TPv3 March 2005
The following AVPs MAY be present in the OCCN:
以下のAVPsはOCCNに存在しているかもしれません:
Random Vector
Message Digest
L2-Specific Sublayer
Tx Connect Speed
Rx Connect Speed
Data Sequencing
Circuit Status
無作為のベクトルメッセージダイジェストL2特有の副層TxがRxが接続する速度を接続する、データ配列サーキット状態を促進してください。
6.12. Call-Disconnect-Notify (CDN)
6.12. 呼び出し分離に通知します。(CDN)
The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE to request disconnection of a specific session. Its purpose is to inform the peer of the disconnection and the reason for the disconnection. The peer MUST clean up any resources, and does not send back any indication of success or failure for such cleanup.
Call分離に通知している(CDN)は特定のセッションの断線を要求するためにLCCEによって送られたコントロールメッセージです。 目的は断線の断線と理由について同輩に知らせることです。 同輩は、どんなリソースもきれいにしなければならなくて、そのようなクリーンアップのために成否のどんなしるしも返送しません。
The following AVPs MUST be present in the CDN:
以下のAVPsはCDNに存在していなければなりません:
Message Type
Result Code
Local Session ID
Remote Session ID
メッセージのローカルのセッションIDリモートセッションタイプ結果コードID
The following AVP MAY be present in the CDN:
以下のAVP MAY、CDNに存在してください:
Random Vector
Message Digest
無作為のベクトルメッセージダイジェスト
6.13. WAN-Error-Notify (WEN)
6.13. 青白い誤りに通知します。(こぶ)
The WAN-Error-Notify (WEN) is a control message sent from an LAC to an LNS to indicate WAN error conditions. The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established.
WAN誤りに通知している(WEN)はWANエラー条件を示すためにLACからLNSに送られたコントロールメッセージです。 このメッセージのカウンタは累積しています。 それほどこのメッセージに60秒に一度送るだけでないべきです。 新しい呼び出しが確立されるとき、カウンタはリセットされます。
The following AVPs MUST be present in the WEN:
以下のAVPsはWENに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
Circuit Errors
地方のメッセージのIDリモートセッションIDサーキットタイプセッション誤り
Lau, et al. Standards Track [Page 66] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[66ページ]RFC3931L2TPv3 March 2005
The following AVP MAY be present in the WEN:
以下のAVP MAY、WENに存在してください:
Random Vector
Message Digest
無作為のベクトルメッセージダイジェスト
6.14. Set-Link-Info (SLI)
6.14. リンクインフォメーションを設定してください。(SLI)
The Set-Link-Info control message is sent by an LCCE to convey link or circuit status change information regarding the circuit associated with this L2TP session. For example, if PPP renegotiates LCP at an LNS or between an LAC and a Remote System, or if a forwarded Frame Relay VC transitions to Active or Inactive at an LAC, an SLI message SHOULD be sent to indicate this event. Precise details of when the SLI is sent, what PW type-specific AVPs must be present, and how those AVPs should be interpreted by the receiving peer are outside the scope of this document. These details should be described in the associated pseudowire-specific documents that require use of this message.
Setリンクインフォメーションコントロールメッセージは、このL2TPセッションに関連しているサーキットに関してリンクかサーキット状態変化情報を伝えるためにLCCEによって送られます。 例えば、PPPがLCPを再交渉するならLNSにおいて、または、LACとRemote Systemか進められたFrame Relay VCがActiveに移行するか、そして、LACのInactive、SLIメッセージSHOULDの間に、送って、この出来事を示してください。 SLIが送られる時に関する正確な詳細、このドキュメントの範囲の外にプレゼントと、それらのAVPsがどうあるはずであるかが、受信同輩によって解釈されていたならPWのタイプ特有のAVPsがそうしなければならないものがあります。 これらの詳細はこのメッセージの使用を必要とする関連pseudowire特有のドキュメントで説明されるべきです。
The following AVPs MUST be present in the SLI:
以下のAVPsはSLIに存在していなければなりません:
Message Type
Local Session ID
Remote Session ID
メッセージのローカルのセッションIDリモートセッションタイプID
The following AVPs MAY be present in the SLI:
以下のAVPsはSLIに存在しているかもしれません:
Random Vector
Message Digest
Circuit Status
無作為のベクトルメッセージダイジェストサーキット状態
6.15. Explicit-Acknowledgement (ACK)
6.15. 明白な承認(ACK)
The Explicit Acknowledgement (ACK) message is used only to acknowledge receipt of a message or messages on the control connection (e.g., for purposes of updating Ns and Nr values). Receipt of this message does not trigger an event for the L2TP protocol state machine.
Explicit Acknowledgement(ACK)メッセージは使用されますが(例えば、NsとNr値をアップデートする目的のために)、コントロール接続に関するメッセージかメッセージの領収書を受け取ったことを知らせます。 このメッセージの領収書はL2TPプロトコル州のマシンのための出来事の引き金となりません。
A message received without any AVPs (including the Message Type AVP), is referred to as a Zero Length Body (ZLB) message, and serves the same function as the Explicit Acknowledgement. ZLB messages are only permitted when Control Message Authentication defined in Section 4.3 is not enabled.
メッセージは、少しもAVPs(Message Type AVPを含んでいる)なしで受信して、Zero Length Body(ZLB)メッセージと呼ばれて、Explicit Acknowledgementと同じ機能を果たします。 セクション4.3で定義されたControl Message Authenticationが有効にされないときだけ、ZLBメッセージは受入れられます。
Lau, et al. Standards Track [Page 67] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[67ページ]RFC3931L2TPv3 March 2005
The following AVPs MAY be present in the ACK message:
以下のAVPsはACKメッセージに存在しているかもしれません:
Message Type
Message Digest
メッセージタイプメッセージダイジェスト
7. Control Connection State Machines
7. 制御接続州のマシン
The state tables defined in this section govern the exchange of control messages defined in Section 6. Tables are defined for incoming call placement and outgoing call placement, as well as for initiation of the control connection itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying reliable control message delivery mechanism (see Section 4.2).
このセクションで定義されたステートテーブルはセクション6で定義されたコントロールメッセージの交換を治めます。 テーブルはかかってきた電話プレースメントと発信電話プレースメントのために定義されます、よくコントロール接続自体の開始のように。 ステートテーブルはタイムアウトと「再-トランスミッション」の振舞いをコード化しません、これが基本的な信頼できる規制メッセージ排紙機構で扱われるとき(セクション4.2を見てください)。
7.1. Malformed AVPs and Control Messages
7.1. 奇形のAVPsとコントロールメッセージ
Receipt of an invalid or unrecoverable malformed control message SHOULD be logged appropriately and the control connection cleared to ensure recovery to a known state. The control connection may then be restarted by the initiator.
適切に登録されて、無効の、または、復しない奇形のコントロールの領収書はSHOULDを通信させます。コントロール接続は、知られている状態に回復を確実にするためにクリアしました。 そして、コントロール接続は創始者によって再出発されるかもしれません。
An invalid control message is defined as (1) a message that contains a Message Type marked as mandatory (see Section 5.4.1) but that is unknown to the implementation, or (2) a control message that is received in the wrong state.
無効のコントロールメッセージは(1) 含んでいますが、実現において、義務的(セクション5.4.1を見る)としてマークされたMessage Typeを知らずにおいているメッセージ、または(2) 間違った状態に受け取られるコントロールメッセージと定義されます。
Examples of malformed control messages include (1) a message that has an invalid value in its header, (2) a message that contains an AVP that is formatted incorrectly or whose value is out of range, and (3) a message that is missing a required AVP. A control message with a malformed header MUST be discarded.
奇形のコントロールメッセージに関する例は(1) ヘッダーに無効の値を持っているメッセージ、(2) 不当にフォーマットされるAVPを含むか、または値が範囲から脱しているメッセージ、および(3) 必要なAVPがいなくて寂しいメッセージを含んでいます。 奇形のヘッダーがあるコントロールメッセージを捨てなければなりません。
When possible, a malformed AVP should be treated as an unrecognized AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD be made to determine the importance of the malformed AVP, and thus, the severity of the malformation to the entire control message. If the M bit can be reasonably inspected within the malformed AVP and is determined to be set, then as with an unrecognized AVP, the associated session or control connection MUST be shut down. If the M bit is inspected and is found to be 0, the AVP MUST be ignored (assuming recovery from the AVP malformation is indeed possible).
可能であるときに、奇形のAVPは認識されていないAVPとして扱われるべきです(セクション5.2を見てください)。 その結果、Mを点検する試みはSHOULDに噛み付きました。奇形のAVPの重要性、およびその結果不具の厳しさを全体のコントロールメッセージに決定させてください。 Mビットが奇形のAVPの中で合理的に点検できて、そして、認識されていないAVPのように設定されることを決定しているなら、合同会議かコントロール接続を止めなければなりません。 Mビットが点検されて、見つけられるなら、0、AVP MUSTに、なるように、無視されてください(本当に、AVP不具からの回復を仮定するのは可能です)。
This policy must not be considered as a license to send malformed AVPs, but rather, as a guide towards how to handle an improperly formatted message if one is received. It is impossible to list all potential malformations of a given message and give advice for each. One example of a malformed AVP situation that should be recoverable
奇形のAVPsを送るライセンスと考えられるのではなく、この方針はむしろ考えられなければなりません、どう不適切にフォーマットされたメッセージを扱うかに向かったガイドが1であるなら受け取られているとき。 与えられたメッセージのすべての潜在的不具を記載して、それぞれのためにアドバイスするのは不可能です。 回復可能であるべき奇形のAVP状況に関する1つの例
Lau, et al. Standards Track [Page 68] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[68ページ]RFC3931L2TPv3 March 2005
is if the Rx Connect Speed AVP is received with a length of 10 rather than 14, implying that the connect speed bits-per-second is being formatted in 4 octets rather than 8. If the AVP does not have its M bit set (as would typically be the case), this condition is not considered catastrophic. As such, the control message should be accepted as though the AVP were not present (though a local error message may be logged).
速度bpsを接続してください。それを含意して、14よりむしろ10の長さでRx Connect Speed AVPを受け取るかどうかということである、8よりむしろ4つの八重奏では、フォーマットされています。 AVPがMを噛み付かせないならセットしてください、(通常、ケースであるだろう、)、この状態は壊滅的であると考えられません。 そういうものとして、まるでAVPが存在していないかのように(ローカルのエラーメッセージは登録されるかもしれませんが)コントロールメッセージを受け入れるべきです。
In several cases in the following tables, a protocol message is sent, and then a "clean up" occurs. Note that, regardless of the initiator of the control connection destruction, the reliable delivery mechanism must be allowed to run (see Section 4.2) before destroying the control connection. This permits the control connection management messages to be reliably delivered to the peer.
いろいろな場合に以下のテーブルでは、プロトコルメッセージを送ります、そして、次に、「浄化」は起こります。 コントロール接続を滅ぼす前に信頼できる配信メカニズムをコントロール接続破壊の創始者にかかわらず走らせなければならないことに(セクション4.2を見ます)注意してください。 これは同輩に確かに渡されるべきコントロール接続管理メッセージを可能にします。
Appendix B.1 contains an example of lock-step control connection establishment.
付録B.1は堅苦しいコントロールコネクション確立に関する例を含んでいます。
7.2. Control Connection States
7.2. コントロール接続州
The L2TP control connection protocol is not distinguishable between the two LCCEs but is distinguishable between the originator and receiver. The originating peer is the one that first initiates establishment of the control connection. (In a tie breaker situation, this is the winner of the tie.) Since either the LAC or the LNS can be the originator, a collision can occur. See the Control Connection Tie Breaker AVP in Section 5.4.3 for a description of this and its resolution.
L2TPコントロール接続プロトコルは、2LCCEsの間で区別可能ではありませんが、創始者と受信機の間で区別可能です。由来している同輩は最初にコントロール接続の設立を開始するものです。 (タイブレーク状況で、これは繋がりの勝者です。) LACかLNSのどちらかが創始者であるかもしれないので、衝突は起こることができます。 これとその解決の記述に関してセクション5.4.3でControl Connection Tie Breaker AVPを見てください。
State Event Action New State
----- ----- ------ ---------
idle Local open Send SCCRQ wait-ctl-reply
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、活動していない許容できない清潔な上
idle Receive SCCRP Send StopCCN, idle
clean up
Receive SCCRP Send StopCCNを空費してください、そして、上にすっかり怠けてください。
idle Receive SCCCN Send StopCCN, idle
clean up
Receive SCCCN Send StopCCNを空費してください、そして、上にすっかり怠けてください。
Lau, et al. Standards Track [Page 69] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[69ページ]RFC3931L2TPv3 March 2005
wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable send control-conn
open event to
waiting sessions
待ちctl回答Receive SCCRP、設立された許容できるSend SCCCN、コンを監督しているオープン・ゲームを待ちセッションに送ってください。
wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable clean up
許容できる清潔な上ではなく、Receive SCCRP(Send StopCCN)が空費する待ちctl回答
wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn
lose tie breaker, Clean up losing
SCCRQ acceptable connection
待ちctl回答Receive SCCRQ、Send SCCRP、待ちctlコンはタイブレークを失って、損をしているSCCRQへのCleanは許容できる接続です。
wait-ctl-reply Receive SCCRQ, Send StopCCN, idle
lose tie breaker, Clean up losing
SCCRQ unacceptable connection
Receive SCCRQ(Send StopCCN)が空費する待ちctl回答は負けているSCCRQ容認できない接続にタイブレーク、Cleanに負けます。
wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply
win tie breaker losing connection
待ちctl回答Receive SCCRQ、待ちctl回答勝利タイブレーク喪失接続のためのSend StopCCN
wait-ctl-reply Receive SCCCN Send StopCCN, idle
clean up
待ちctl回答Receive SCCCN Send StopCCN、活動していない清潔な上
wait-ctl-conn Receive SCCCN, Send control-conn established
acceptable open 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、活動していない許容できない清潔な上
wait-ctl-conn Receive SCCRQ, Send StopCCN, idle
SCCRP clean up
待ちctlコンReceive SCCRQ、Send StopCCN、使用されていないSCCRPは掃除します。
established Local open Send control-conn established
request open event to
(new call) waiting sessions
(新しい呼び出し)待ちセッションへのコンを監督している確立したLocalの開いているSend確立した要求オープン・ゲーム
established Administrative Send StopCCN, idle
control-conn clean up
close event
確立したAdministrative Send StopCCN、活動していないコンを監督している清潔な近いイベント
established Receive SCCRQ, Send StopCCN, idle
SCCRP, SCCCN clean up
確立したReceive SCCRQ(Send StopCCN)はSCCRPを空費して、SCCCNは掃除します。
idle, Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established
怠けてください、そして、Receive StopCCN Cleanは無駄な待ちctl回答、設立された待ちctlコンを上げます。
Lau, et al. Standards Track [Page 70] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[70ページ]RFC3931L2TPv3 March 2005
The states associated with an LCCE for control connection establishment are as follows:
コントロールコネクション確立のためのLCCEに関連している州は以下の通りです:
idle
Both initiator and recipient start from this state. An initiator
transmits an SCCRQ, while a recipient remains in the idle state
until receiving an SCCRQ.
この状態から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.4.3.
そして、創始者が別の接続が同じ同輩から要求されるかどうか確認するためにチェックする待ちctl回答、そうだとすれば、衝突状況がセクション5.4.3で説明したハンドル。
wait-ctl-conn
Awaiting an SCCCN. If the SCCCN is valid, the control connection
is established; otherwise, it is torn down (sending a StopCCN with
the proper result and/or error code).
待ちのctlコンAwaiting、SCCCN。 SCCCNが有効であるなら、コントロール接続は確立されます。 さもなければ、それを取りこわします(適切な結果、そして/または、エラーコードがあるStopCCNを送ります)。
established
An established connection may be terminated by either a local
condition or the receipt of a StopCCN. In the event of a local
termination, the originator MUST send a StopCCN and clean up the
control connection. If the originator receives a StopCCN, it MUST
also clean up the control connection.
確立したAn確立した接続はStopCCNの現地の状況か領収書のどちらかで終えられるかもしれません。 地方の終了の場合、創始者は、StopCCNを送って、コントロール接続をきれいにしなければなりません。 また、創始者がStopCCNを受け取るなら、それはコントロール接続をきれいにしなければなりません。
7.3. Incoming Calls
7.3. かかってきた電話
An ICRQ is generated by an LCCE, typically in response to an incoming call or a local event. Once the LCCE sends the ICRQ, it waits for a response from the peer. However, it may choose to postpone establishment of the call (e.g., answering the call, bringing up the circuit) until the peer has indicated with an ICRP that it will accept the call. The peer may choose not to accept the call if, for instance, there are insufficient resources to handle an additional session.
ICRQはLCCEによって通常かかってきた電話かローカルイベントに対応して発生します。 LCCEがいったんICRQを送ると、それは同輩から応答を待っています。 しかしながら、それは、同輩が、ICRPと共に呼び出しを受け入れるのを示すまで要求(例えば、サーキットを持って来て、電話口に出る)の設立を延期するのを選ぶかもしれません。 同輩は、例えば、追加セッションを扱うために不十分なリソースがあれば呼び出しを受け入れないのを選ぶかもしれません。
If the peer chooses to accept the call, it responds with an ICRP. When the local LCCE receives the ICRP, it attempts to establish the call. A final call connected message, the ICCN, is sent from the local LCCE to the peer to indicate that the call states for both LCCEs should enter the established state. If the call is terminated before the peer can accept it, a CDN is sent by the local LCCE to indicate this condition.
同輩が、呼び出しを受け入れるのを選ぶなら、それはICRPと共に応じます。 地方のLCCEがICRPを受けるとき、それは、呼び出しを確立するのを試みます。 両方のLCCEsのための呼び出し状態が設立された状態に入るべきであるのを示すために、最終的な接続完了メッセージ(ICCN)を地方のLCCEから同輩に送ります。 同輩がそれを受け入れることができる前に呼び出しが終えられるなら、CDNは、この状態を示すために地方のLCCEによって送られます。
When a call transitions to a "disconnected" or "down" state, the call is cleared normally, and the local LCCE sends a CDN. Similarly, if the peer wishes to clear a call, it sends a CDN and cleans up its session.
呼び出しが「外す」か“down"状態に移行するとき、通常、呼び出しはクリアされます、そして、地方のLCCEはCDNを送ります。 同様に、同輩が呼び出しをクリアしたいなら、それは、CDNを送って、セッションをきれいにします。
Lau, et al. Standards Track [Page 71] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[71ページ]RFC3931L2TPv3 March 2005
7.3.1. ICRQ Sender States
7.3.1. ICRQ送付者州
State Event Action New State ----- ----- ------ ---------
イベントの動作の新しい状態を述べてください。----- ----- ------ ---------
idle Call signal or Initiate local wait-control-conn
ready to receive control-conn
incoming conn open
使用されていないCall信号かコンを監督している入って来るコン戸外を受ける準備ができているInitiate地元の待ちコントロールコン
idle Receive ICCN, Clean up idle
ICRP, CDN
使用されていないReceive ICCN、使用されていないICRP、CDNへのClean
wait-control- Bearer line drop Clean up idle
conn or local close
request
活動していないコンかローカルの厳密な要求への待ちコントロール運搬人線低下Clean
wait-control- control-conn-open Send ICRQ wait-reply conn
待ちコントロールコン戸外の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は掃除します。
wait-reply Receive ICRQ, Process as idle
lose tie breaker ICRQ Recipient
(Section 7.3.2)
待ち回答Receive ICRQ、使用されていない同じくらいProcessはタイブレークICRQ Recipientをなくします。(セクション7.3.2)
wait-reply Receive ICRQ, Send CDN wait-reply
win tie breaker for losing
session
待ち回答Receive ICRQ、損をしているセッションのためのSend CDN待ち回答勝利タイブレーク
wait-reply Receive CDN, Clean up idle
ICCN
待ち回答Receive CDN、使用されていないICCNへのClean
wait-reply Local close Send CDN, idle
request clean up
待ち回答のLocalの近いSend CDN、無駄な要求は掃除します。
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は掃除します。
established Local close Send CDN, idle
request clean up
確立したLocal近いSend CDN、無駄な要求は掃除します。
Lau, et al. Standards Track [Page 72] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[72ページ]RFC3931L2TPv3 March 2005
The states associated with the ICRQ sender are as follows:
ICRQ送付者に関連している州は以下の通りです:
idle
The LCCE detects an incoming call on one of its interfaces (e.g.,
an analog PSTN line rings, or an ATM PVC is provisioned), or a
local event occurs. The LCCE initiates its control connection
establishment state machine and moves to a state waiting for
confirmation of the existence of a control connection.
怠けてください。LCCEがインタフェースの1つにかかってきた電話を検出するか(例えばアナログPSTN線が鳴るか、またはATM PVCは食糧を供給されます)、またはローカルイベントは起こります。 LCCEは制御コネクション確立州のマシンを開始して、コントロール接続の存在の確認を待つ州に動きます。
wait-control-conn
In this state, the session is waiting for either the control
connection to be opened or for verification that the control
connection is already open. Once an indication that the control
connection has been opened is received, session control messages
may be exchanged. The first of these messages is the ICRQ.
待ちがコンを監督しているIn、この状態、セッションはコントロール接続が開かれるか、コントロール接続が既にそうである検証に賛成するのを開いている待つことです。 コントロール接続が開かれたという指示がいったん受け取られているようになると、セッション制御メッセージを交換するかもしれません。 これらのメッセージの1番目はICRQです。
wait-reply
The ICRQ sender receives either (1) a CDN indicating the peer is
not willing to accept the call (general error or do not accept)
and moves back into the idle state, or (2) an ICRP indicating the
call is accepted. In the latter case, the LCCE sends an ICCN and
enters the established state.
同輩を示すICRQ送付者が受け取る待ち回答(1)a CDNが、呼び出しを受け入れることを望んでいない、(一般的なエラー、受け入れないでください、)、そして、(2) 活動していない状態、または呼び出しが受け入れられるのを示すICRPへの移動。 後者の場合では、LCCEはICCNを送って、設立された状態に入れます。
established
Data is exchanged over the session. The call may be cleared by
any of the following:
+ An event on the connected interface: The LCCE sends a CDN.
+ Receipt of a CDN: The LCCE cleans up, disconnecting the call.
+ A local reason: The LCCE sends a CDN.
セッションの間、確立したDataを交換します。 呼び出しは以下のどれかによってクリアされるかもしれません: + 接続インタフェースにおける出来事: LCCEはCDNを送ります。 + CDNの領収書: 呼び出しを外して、LCCEは掃除します。 + ローカルの理由: LCCEはCDNを送ります。
7.3.2. ICRQ Recipient States
7.3.2. ICRQ受取人州
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、活動していない許容できない清潔な上
idle Receive ICRP Send CDN idle
clean up
使用されていないReceive ICRP Send CDNは上にすっかり怠けます。
idle Receive ICCN Clean up idle
使用されていないReceive ICCN Cleanは活動していない状態で上昇します。
wait-connect Receive ICCN, Prepare for established
acceptable data
Receive ICCN、確立した許容できるデータのためのPrepareを待つ接続してください。
Lau, et al. Standards Track [Page 73] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[73ページ]RFC3931L2TPv3 March 2005
wait-connect Receive ICCN, Send CDN, idle
not acceptable clean up
待つ接続しているReceive ICCN、Send CDN、活動していない許容できない清潔な上
wait-connect Receive ICRQ, Send CDN, idle
ICRP clean up
Receive ICRQ、Send CDNを待つ接続してください、そして、使用されていないICRPは掃除します。
idle, Receive CDN Clean up idle wait-connect, established
Receive CDN Clean、怠けてください。上が待つ接続していた状態で怠ける、確立
wait-connect Local close Send CDN, idle established request clean up
待つ接続しているLocal近いSend CDN、無駄な確立した要求は掃除します。
established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up
確立したReceive ICRQ(Send CDN)はICRPを空費して、ICCNは掃除します。
The states associated with the ICRQ recipient are as follows:
ICRQ受取人に関連している州は以下の通りです:
idle
An ICRQ is received. If the request is not acceptable, a CDN is
sent back to the peer LCCE, and the local LCCE remains in the idle
state. If the ICRQ is acceptable, an ICRP is sent. The session
moves to the wait-connect state.
使用されていないAn ICRQは受け取られています。 要求が許容できないなら、CDNは同輩LCCEに送り返されます、そして、地方のLCCEは活動していない州に残っています。 ICRQが許容できるなら、ICRPを送ります。 セッションは待つ接続している状態に動きます。
wait-connect
The local LCCE is waiting for an ICCN from the peer. Upon receipt
of the ICCN, the local LCCE moves to established state.
地方を待つ接続してください。LCCEは同輩からICCNを待っています。 ICCNを受け取り次第、地方のLCCEは設立された状態に動きます。
established
The session is terminated either by sending a CDN or by receiving
a CDN from the peer. Clean up follows on both sides regardless of
the initiator.
設立されて、セッションは、CDNを送るか、または同輩からCDNを受けることによって、終えられます。 創始者にかかわらず両側で尾行をきれいにしてください。
7.4. Outgoing Calls
7.4. 発信電話
Outgoing calls instruct an LAC to place a call. There are three messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first sends an OCRQ to an LAC to request an outgoing call. The LAC MUST respond to the OCRQ with an OCRP once it determines that the proper facilities exist to place the call and that the call is administratively authorized. Once the outbound call is connected, the LAC sends an OCCN to the peer indicating the final result of the call attempt.
発信電話は、電話をするようLACに命令します。 発信電話への3つのメッセージがあります: OCRQ、OCRP、およびOCCN。 LCCEは、最初に、発信電話を要求するためにOCRQをLACに送ります。 適切な施設が電話をするために存在していて、呼び出しが行政上認可されることをいったん決定すると、LAC MUSTはOCRPと共にOCRQに応じます。 外国行きの呼び出しがいったん接続されるようになると、LACは呼び出し試みの最終的な結果を示す同輩にOCCNを送ります。
Lau, et al. Standards Track [Page 74] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[74ページ]RFC3931L2TPv3 March 2005
7.4.1. OCRQ Sender States
7.4.1. OCRQ送付者州
State Event Action New State
----- ----- ------ ---------
idle Local open Initiate local wait-control-conn
request control-conn-open
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- 待ちがコンを監督している活動していない開いているLocalの地方の要求コントロールコンInitiate戸外
idle Receive OCCN, Clean up idle
OCRP
使用されていないReceive OCCN、使用されていないOCRPへのClean
wait-control- control-conn-open Send OCRQ wait-reply conn
待ちコントロールコン戸外の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)が空費する待ち回答
wait-reply Receive OCCN Send CDN, idle
clean up
待ち回答Receive OCCN Send CDN、活動していない清潔な上
wait-reply Receive OCRQ, Process as idle
lose tie breaker OCRQ Recipient
(Section 7.4.2)
待ち回答Receive OCRQ、使用されていない同じくらいProcessはタイブレークOCRQ Recipientをなくします。(セクション7.4.2)
wait-reply Receive OCRQ, Send CDN wait-reply
win tie breaker for losing
session
待ち回答Receive OCRQ、損をしているセッションのための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は掃除します。
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は掃除します。
wait-reply, Local close Send CDN, idle wait-connect, request clean up established
待ち回答、Localの近いSend CDN、待つ接続していた状態で怠けてください、そして、確立していた状態で掃除するよう要求してください。
Lau, et al. Standards Track [Page 75] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[75ページ]RFC3931L2TPv3 March 2005
wait-control- Local close Clean up idle conn request
無駄なコンの要求への待ちコントロール地方の近いClean
The states associated with the OCRQ sender are as follows:
OCRQ送付者に関連している州は以下の通りです:
idle, wait-control-conn
When an outgoing call request is initiated, a control connection
is created as described above, if not already present. Once the
control connection is established, an OCRQ is sent to the LAC, and
the session moves into the wait-reply state.
活動していません、待ちがコンを監督しているWhenは開始されて、発信電話が、要求するコントロール接続は上で説明される、または既に現在として創造されます。 いったんコントロール接続を確立すると、OCRQをLACに送ります、そして、セッションは待ち回答状態に移行します。
wait-reply
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCRP is received, the call is in progress, and
the session moves to the wait-connect state.
待ち回答If a CDNが受け取られていて、セッションは掃除されて、戻って、状態を空費します。 OCRPが受け取られているなら、呼び出しは進行しています、そして、セッションは待つ接続している状態に移行します。
wait-connect
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCCN is received, the call has succeeded, and
the session may now exchange data.
待つ接続しているIf a CDNが受け取られていて、セッションは掃除されて、戻って、状態を空費します。 OCCNが受け取られているなら、呼び出しは成功しました、そして、セッションは現在、データを交換するかもしれません。
established
If a CDN is received, the session is cleaned up and returns to
idle state. Alternatively, if the LCCE chooses to terminate the
session, it sends a CDN to the LAC, cleans up the session, and
moves the session to idle state.
確立したIf a CDNが受け取られていて、セッションは掃除されて、戻って、状態を空費します。 あるいはまた、LCCEが、セッションを終えるのを選ぶなら、それは、CDNをLACに送って、セッションを掃除して、状態を空費するためにセッションを動かします。
7.4.2. OCRQ Recipient (LAC) States
7.4.2. OCRQ受取人(ラック)州
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
イベントの動作の新しい状態を述べてください。----- ----- ------ --------- Receive OCRQ、Send OCRPを空費してください、そして、待ちCs答えの許容できるPlaceは呼びます。
idle Receive OCRQ, Send CDN, idle
not acceptable clean up
使用されていないReceive OCRQ、Send CDN、活動していない許容できない清潔な上
idle Receive OCRP Send CDN, idle
clean up
Receive OCRP Send CDNを空費してください、そして、上にすっかり怠けてください。
idle Receive OCCN, Clean up idle
CDN
使用されていないReceive OCCN、使用されていないCDNへのClean
wait-cs-answer Call placement Send OCCN established
successful
うまくいった状態で設立された待ちCs答えCallプレースメントSend OCCN
wait-cs-answer Call placement Send CDN, idle
failed clean up
待ちCs答えCallプレースメントSend CDN、失敗されていた状態で、上にすっかり怠けてください。
Lau, et al. Standards Track [Page 76] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[76ページ]RFC3931L2TPv3 March 2005
wait-cs-answer Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
待ちCs答えReceive OCRQ(Send CDN)はOCRPを空費して、OCCNは掃除します。
established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
確立したReceive OCRQ(Send CDN)はOCRPを空費して、OCCNは掃除します。
wait-cs-answer, Receive CDN Clean up idle established
Cs答えを待ちなさいといって、Receive CDN Cleanが活動していない状態で上昇する、確立
wait-cs-answer, Local close Send CDN, idle established request clean up
Cs答えを待ってください、そして、Localの近いSend CDN、無駄な確立した要求は掃除します。
The states associated with the LAC for outgoing calls are as follows:
発信電話のためのLACに関連している州は以下の通りです:
idle
If the OCRQ is received in error, respond with a CDN. Otherwise,
place the call, send an OCRP, and move to the wait-cs-answer
state.
使用されていないIf OCRQを間違って受け取って、CDNと共に応じてください。 さもなければ、電話をしてください、そして、OCRPを送ってください、そして、待ちCs答え状態に移行してください。
wait-cs-answer
If the call is not completed or a timer expires while waiting for
the call to complete, send a CDN with the appropriate error
condition set, and go to idle state. If a circuit-switched
connection is established, send an OCCN indicating success, and go
to established state.
待ちCs答えIf、呼び出しが終了していないか、タイマは終了する電話を待っている間、期限が切れて、適切なエラー条件セットがあるCDNを送ってください、そして、または状態を空費しに行ってください。 回線交換接続が確立されるなら、OCCNに成功を示させてください、そして、設立された状態に行ってください。
established
If the LAC receives a CDN from the peer, the call MUST be released
via appropriate mechanisms, and the session cleaned up. If the
call is disconnected because the circuit transitions to a
"disconnected" or "down" state, the LAC MUST send a CDN to the
peer and return to idle state.
確立したIf LACは同輩からCDNを受けます、そして、適切な手段で呼び出しをリリースしなければなりませんでした、そして、セッションは掃除しました。 回路が「切断する」か“down"状態に移行するので呼び出し切断されるなら、LAC MUSTはCDNを同輩に送って、戻って、状態を空費します。
7.5. Termination of a Control Connection
7.5. コントロール接続の終了
The termination of a control connection consists of either peer issuing a StopCCN. The sender of this message SHOULD wait a full control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ... seconds) for the acknowledgment of this message before releasing the control information associated with the control connection. The recipient of this message should send an acknowledgment of the message to the peer, then release the associated control information.
コントロール接続の終了はStopCCNを発行するどちらの同輩からも成ります。 制御情報を発表する前にSHOULDがこのメッセージの承認のために、完全なコントロールメッセージの再送サイクル(例えば、1+2+4+8…秒)を待つというこのメッセージの送付者はコントロール接続と交際しました。 このメッセージの受取人は、メッセージの承認を同輩に送って、次に、関連制御情報を発表するべきです。
When to release a control connection is an implementation issue and is not specified in this document. A particular implementation may use whatever policy is appropriate for determining when to release a control connection. Some implementations may leave a control connection open for a period of time or perhaps indefinitely after
いつコントロール接続を釈放するかは、導入問題であり、本書では指定されません。 特定の実装はどんないつコントロール接続を釈放するかを決定するのに、適切な方針も使用するかもしれません。 いくつかの実装が接続がしばらくか恐らく無期限に開くコントロールを残すかもしれません。
Lau, et al. Standards Track [Page 77] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[77ページ]RFC3931L2TPv3 March 2005
the last session for that control connection is cleared. Others may choose to disconnect the control connection immediately after the last call on the control connection disconnects.
そのコントロール接続のための納会はクリアされます。 他のものは、コントロール接続分離のときに最後の呼び出し直後コントロール接続から切断するのを選ぶかもしれません。
8. Security Considerations
8. セキュリティ問題
This section addresses some of the security issues that L2TP encounters in its operation.
このセクションはL2TPが稼働中であり遭遇する安全保障問題のいくつかを扱います。
8.1. Control Connection Endpoint and Message Security
8.1. コントロール接続終点とメッセージセキュリティ
If a shared secret (password) exists between two LCCEs, it may be used to perform a mutual authentication between the two LCCEs, and construct an authentication and integrity check of arriving L2TP control messages. The mechanism provided by L2TPv3 is described in Section 4.3 and in the definition of the Message Digest and Control Message Authentication Nonce AVPs in Section 5.4.1.
共有秘密キー(パスワード)が2LCCEsの間に存在しているなら、それは、2LCCEsの間の互いの認証を実行して、到着しているL2TPコントロールメッセージの認証と保全チェックを構成するのに使用されるかもしれません。 L2TPv3によって提供されたメカニズムはセクション4.3とセクション5.4.1とのMessage DigestとControl Message Authentication Nonce AVPsの定義で説明されます。
This control message security mechanism provides for (1) mutual endpoint authentication, and (2) individual control message integrity and authenticity checking. Mutual endpoint authentication ensures that an L2TPv3 control connection is only established between two endpoints that are configured with the proper password. The individual control message and integrity check guards against accidental or intentional packet corruption (i.e., those caused by a control message spoofing or man-in-the-middle attack).
この制御メッセージセキュリティー対策は(2) (1) 互いの終点認証、個々のコントロールメッセージの保全、および信憑性の照合に備えます。 互いの終点認証は、L2TPv3コントロール接続が適切なパスワードによって構成される2つの終点の間で確立されるだけであるのを確実にします。 個々のコントロールメッセージと保全は偶然的、または、意図的なパケット不正(すなわち、コントロールメッセージスプーフィングか介入者攻撃で引き起こされたもの)に対して番人をチェックします。
The shared secret that is used for all control connection, control message, and AVP security features defined in this document never needs to be sent in the clear between L2TP tunnel endpoints.
本書では定義されたすべてのコントロール接続、コントロールメッセージ、およびAVPセキュリティ機能に使用される共有秘密キーは、決してL2TPトンネル終点の間の明確で送られる必要がありません。
8.2. Data Packet Spoofing
8.2. データ・パケットスプーフィング
Packet spoofing for any type of Virtual Private Network (VPN) protocol is of particular concern as insertion of carefully constructed rogue packets into the VPN transit network could result in a violation of VPN traffic separation, leaking data into a customer VPN. This is complicated by the fact that it may be particularly difficult for the operator of the VPN to even be aware that it has become a point of transit into or between customer VPNs.
Virtual兵士のNetwork(VPN)のどんなタイプも議定書を作るので、パケットスプーフィングはVPNトランジットネットワークへの慎重に組み立てられた凶暴なパケットの挿入がVPNトラフィック分離の違反をもたらすかもしれないように特別の関心のものです、顧客VPNにデータを漏らして。 VPNのオペレータがそれがVPNsか顧客VPNsの間のトランジットのポイントになったのを意識しているのさえ、特に難しいかもしれないという事実によってこれは複雑にされます。
L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit.
L2TPv3はL2TPv3データヘッダーの32ビットのSession ID経由でトラフィック分離をVPNsに供給します。 プレゼント(L2TPv3 Cookie(セクション4.1では、説明される))が追加チェックを提供するとき、それを確実にするために、到着パケットは特定されたセッションのために意図します。 したがって、Session IDとのCookieの使用はSession IDルックアップが適切に実行されて、Session ID自体がトランジットで崩壊しなかったという付加的な保証を提供します。
Lau, et al. Standards Track [Page 78] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[78ページ]RFC3931L2TPv3 March 2005
In the presence of a blind packet spoofing attack, the Cookie may also provide security against inadvertent leaking of frames into a customer VPN. To illustrate the type of security that it is provided in this case, consider comparing the validation of a 64-bit Cookie in the L2TPv3 header to the admission of packets that match a given source and destination IP address pair. Both the source and destination IP address pair validation and Cookie validation consist of a fast check on cleartext header information on all arriving packets. However, since L2TPv3 uses its own value, it removes the requirement for one to maintain a list of (potentially several) permitted or denied IP addresses, and moreover, to guard knowledge of the permitted IP addresses from hackers who may obtain and spoof them. Further, it is far easier to change a compromised L2TPv3 Cookie than a compromised IP address," and a cryptographically random [RFC1750] value is far less likely to be discovered by brute-force attacks compared to an IP address.
また、盲目のパケットスプーフィング攻撃があるとき、Cookieは顧客VPNへのフレームの不注意な漏出に対してセキュリティを提供するかもしれません。 それがこの場合提供されるセキュリティのタイプを例証するには、与えられたソースと目的地IPアドレス組に合っているパケットの入場にL2TPv3ヘッダーでの64ビットのCookieの合法化をたとえると考えてください。 ソースと目的地IPアドレス組合法化とCookie合法化の両方がすべて到着しているパケットに関するcleartextヘッダー情報の速いチェックから成ります。 しかしながら、L2TPv3がそれ自身の値を使用するので、それは彼らを得て、偽造するかもしれないハッカーから人がIPアドレスが受入れられるか、または否定された(潜在的に数個)のリストを維持して、そのうえ、受入れられたIPアドレスに関する知識を警備するという要件を取り除きます。 「さらに、L2TPv3 Cookieであると感染されるaを変えるのはaがIPアドレスに感染したよりはるかに簡単であり」、IPアドレスと比べて、aは全数探索法によって暗号ではるかにより発見されそうにはありません無作為の[RFC1750]が、評価する。
For protection against brute-force, blind, insertion attacks, a 64- bit Cookie MUST be used with all sessions. A 32-bit Cookie is vulnerable to brute-force guessing at high packet rates, and as such, should not be considered an effective barrier to blind insertion attacks (though it is still useful as an additional verification of a successful Session ID lookup). The Cookie provides no protection against a sophisticated man-in-the-middle attacker who can sniff and correlate captured data between nodes for use in a coordinated attack.
ブルートフォースに対する保護のために、盲目の挿入攻撃、64ビット、すべてのセッションと共にCookieを使用しなければなりません。 32ビットのCookieは高いパケットレートを推測するブルートフォースに被害を受け易いです、そして、そういうものとして、盲目の挿入攻撃への有効なバリアであると考えるべきではありません(それはうまくいっているSession IDルックアップの追加検証としてまだ役に立っていますが)。 Cookieは組織的攻撃における使用のためのノードの間の捕らわれているデータをかいで、関連させることができる洗練された中央の男性攻撃者に対してノー・プロテクションを提供します。
The Assigned Cookie AVP is used to signal the value and size of the Cookie that must be present in all data packets for a given session. Each Assigned Cookie MUST be selected in a cryptographically random manner [RFC1750] such that a series of Assigned Cookies does not provide any indication of what a future Cookie will be.
Assigned Cookie AVPは、与えられたセッションのためにすべてのデータ・パケットで存在しなければならないCookieの値とサイズに合図するのに使用されます。 各Assigned Cookieによるaで暗号で選択されて、そのaシリーズのそのような無作為の方法[RFC1750]Assigned Cookiesが将来のCookieがものになるどんなしるしも供給しないということでなければなりません。
The L2TPv3 Cookie must not be regarded as a substitute for security such as that provided by IPsec when operating over an open or untrusted network where packets may be sniffed, decoded, and correlated for use in a coordinated attack. See Section 4.1.3 for more information on running L2TP over IPsec.
それなどのセキュリティの代用品が使用のためにパケットがかがれるかもしれない開いているか信頼されていないネットワークの上で作動するとき、IPsecで提供して、解読して、関連したので、組織的攻撃でL2TPv3 Cookieを見なしてはいけません。 IPsecの上で実行しているL2TPの詳しい情報に関してセクション4.1.3を見てください。
9. Internationalization Considerations
9. 国際化問題
The Host Name and Vendor Name AVPs are not internationalized. The Vendor Name AVP, although intended to be human-readable, would seem to fit in the category of "globally visible names" [RFC2277] and so is represented in US-ASCII.
Host NameとVendor Name AVPsは国際的にされません。 「グローバルに目に見える名前」[RFC2277]のカテゴリをうまくはめ込むように思えるでしょう、Vendor Name AVPは人間読み込み可能であることを意図しますが、したがって、米国-ASCIIで表されます。
If (1) an LCCE does not signify a language preference by the inclusion of a Preferred Language AVP (see Section 5.4.3) in the
(1) LCCEは中でPreferred Language AVP(セクション5.4.3を見る)の包含で言語優先を意味しません。
Lau, et al. Standards Track [Page 79] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[79ページ]RFC3931L2TPv3 March 2005
SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or (3) the requested language is not supported by the peer LCCE, the default language [RFC2277] MUST be used for all internationalized strings sent by the peer.
要求された言語は同輩LCCEによってサポートされません、そして、(2) SCCRQかSCCRP、Preferred Language AVPが認識されていないか、または(3) 同輩によって送られたすべての国際化しているストリングに、デフォルト言語[RFC2277]を使用しなければなりません。
10. IANA Considerations
10. IANA問題
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document.
このドキュメントはIANAによって維持される多くの「魔法」の数を定義します。 このセクションはそれぞれのこれらのリストの追加数を割り当てるのにIANAによって使用された評価基準について説明します。 以下の小区分はほかの場所で本書では定義された名前空間のために課題方針を説明します。
Sections 10.1 through 10.3 are requests for new values already managed by IANA according to [RFC3438].
セクション10.1〜10.3は[RFC3438]に従ってIANAによって既に管理された新しい値を求めて要求です。
The remaining sections are for new registries that have been added to the existing L2TP registry and are maintained by IANA accordingly.
既存のL2TP登録に加えられて、IANAによってそれに従って、維持される新しい登録には残っているセクションがあります。
10.1. Control Message Attribute Value Pairs (AVPs)
10.1. コントロールメッセージ属性値ペア(AVPs)
This number space is managed by IANA as per [RFC3438].
この数のスペースは[RFC3438]に従ってIANAによって管理されます。
A summary of the new AVPs follows:
新しいAVPsの概要は従います:
Control Message Attribute Value Pairs
コントロールメッセージ属性値ペア
Attribute
Type Description
--------- ------------------
属性タイプ記述--------- ------------------
58 Extended Vendor ID AVP
59 Message Digest
60 Router ID
61 Assigned Control Connection ID
62 Pseudowire Capabilities List
63 Local Session ID
64 Remote Session ID
65 Assigned Cookie
66 Remote End ID
68 Pseudowire Type
69 L2-Specific Sublayer
70 Data Sequencing
71 Circuit Status
72 Preferred Language
73 Control Message Authentication Nonce
74 Tx Connect Speed
75 Rx Connect Speed
58 拡張ベンダーID AVP59メッセージダイジェスト60ルータID61は認証一回だけ74Txが速度75Rxを接続するというクッキー66リモートエンドID68のPseudowireのタイプの69のL2特有の副層70データ配列71回路状態72都合のよい言語73コントロールメッセージが割り当てられたID65が速度を接続する64のリモートセッションをコントロール接続ID62Pseudowire能力のリスト63の地方のSession IDに割り当てました。
Lau, et al. Standards Track [Page 80] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[80ページ]RFC3931L2TPv3 March 2005
10.2. Message Type AVP Values
10.2. メッセージタイプAVP値
This number space is managed by IANA as per [RFC3438]. There is one new message type, defined in Section 3.1, that was allocated for this specification:
この数のスペースは[RFC3438]に従ってIANAによって管理されます。 この仕様のために割り当てられたセクション3.1で定義された1つの新しいメッセージタイプがあります:
Message Type AVP (Attribute Type 0) Values ------------------------------------------
メッセージタイプAVP(属性タイプ0)値------------------------------------------
Control Connection Management
コントロール接続管理
20 (ACK) Explicit Acknowledgement
20 (ACK)明白な承認
10.3. Result Code AVP Values
10.3. 結果コードAVP値
This number space is managed by IANA as per [RFC3438].
この数のスペースは[RFC3438]に従ってIANAによって管理されます。
New Result Code values for the CDN message are defined in Section 5.4. The following is a summary:
CDNメッセージのための新しいResult Code値はセクション5.4で定義されます。 ↓これは概要です:
Result Code AVP (Attribute Type 1) Values -----------------------------------------
結果コードAVP(属性タイプ1)値-----------------------------------------
General Error Codes
一般的なエラーコード
13 - Session not established due to losing
tie breaker (L2TPv3).
14 - Session not established due to unsupported
PW type (L2TPv3).
15 - Session not established, sequencing required
without valid L2-Specific Sublayer (L2TPv3).
16 - Finite state machine error or timeout.
13--セッションは損をしているタイブレークのため(L2TPv3)を設立しませんでした。 14--セッションはサポートされないPWのためタイプ(L2TPv3)を設立しませんでした。 15--確立されなかったセッション、配列が有効なL2特有のSublayer(L2TPv3)なしで必要です。 16--有限状態機械誤りかタイムアウト。
Lau, et al. Standards Track [Page 81] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[81ページ]RFC3931L2TPv3 March 2005
10.4. AVP Header Bits
10.4. AVPヘッダービット
This is a new registry for IANA to maintain.
これはIANAが維持する新しい登録です。
Leading Bits of the L2TP AVP Header -----------------------------------
L2TP AVPヘッダーの主なビット-----------------------------------
There six bits at the beginning of the L2TP AVP header. New bits are assigned via Standards Action [RFC2434].
そこ、L2TP AVPヘッダーの始めにおける6ビット。 新しいビットはStandards Action[RFC2434]を通して割り当てられます。
Bit 0 - Mandatory (M bit) Bit 1 - Hidden (H bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved
(Mは噛み付きました)義務的なビット1--ビット2--予約されたBit3--予約されたBit4を隠すという(Hに噛み付きました)ビット0はBit5を予約しました--予約されます。
10.5. L2TP Control Message Header Bits
10.5. L2TPコントロールメッセージヘッダービット
This is a new registry for IANA to maintain.
これはIANAが維持する新しい登録です。
Leading Bits of the L2TP Control Message Header -----------------------------------------------
L2TPコントロールメッセージヘッダーの主なビット-----------------------------------------------
There are 12 bits at the beginning of the L2TP Control Message Header. Reserved bits should only be defined by Standard Action [RFC2434].
L2TP Control Message Headerの始めにおける12ビットがあります。 予約されたビットはStandard Action[RFC2434]によって定義されるだけであるはずです。
Bit 0 - Message Type (T bit) Bit 1 - Length Field is Present (L bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Sequence Numbers Present (S bit) Bit 5 - Reserved Bit 6 - Offset Field is Present [RFC2661] Bit 7 - Priority Bit (P bit) [RFC2661] Bit 8 - Reserved Bit 9 - Reserved Bit 10 - Reserved Bit 11 - Reserved
長さのFieldがPresent(Lに噛み付いた)ビット2であるというメッセージType(Tに噛み付いた)ビット1はBit3を予約しました--予約されたBit4(系列民数記Present(Sに噛み付いた)ビット5)はBit6を予約しました--オフセットFieldがPresent[RFC2661]ビット7であるという予約されたBit9(予約されたBit10)がBit11を予約したという優先権Bit(Pに噛み付きました)[RFC2661]ビット8が予約したビット0
Lau, et al. Standards Track [Page 82] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[82ページ]RFC3931L2TPv3 March 2005
10.6. Pseudowire Types
10.6. Pseudowireはタイプします。
This is a new registry for IANA to maintain, there are no values assigned within this document to maintain.
これがIANAが維持する新しい登録である、維持するこのドキュメントの中に割り当てられた値が全くありません。
L2TPv3 Pseudowire Types -----------------------
L2TPv3 Pseudowireはタイプします。-----------------------
The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review [RFC2434], while 32768 to 65535 are assigned by a First Come First Served policy [RFC2434]. There are no specific pseudowire types assigned within this document. Each pseudowire-specific document must allocate its own PW types from IANA as necessary.
Pseudowire Type(PW Type、セクション5.4を見る)は値がセクション5.4.3で定義されたPseudowire Type AVPとPseudowire Capabilities List AVPで使用した2八重奏です。 0〜32767はExpert Review[RFC2434]で「割り当て-可能」です、First Come First Served方針[RFC2434]で32768〜65535が割り当てられますが。 このドキュメントの中に選任されたどんな特定のpseudowireタイプもありません。 それぞれのpseudowire特有のドキュメントは必要に応じてIANAからそれ自身のPWタイプを割り当てなければなりません。
10.7. Circuit Status Bits
10.7. 回路ステータスビット
This is a new registry for IANA to maintain.
これはIANAが維持する新しい登録です。
Circuit Status Bits -------------------
回路ステータスビット-------------------
The Circuit Status field is a 16-bit mask, with the two low order bits assigned. Additional bits may be assigned by IETF Consensus [RFC2434].
Circuit Status分野は2下位のビットが割り当てられている16ビットのマスクです。 追加ビットはIETF Consensus[RFC2434]によって割り当てられるかもしれません。
Bit 14 - New (N bit) Bit 15 - Active (A bit)
ビット14(新しい(Nビット)ビット15)アクティブです。(少し)
Lau, et al. Standards Track [Page 83] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[83ページ]RFC3931L2TPv3 March 2005
10.8. Default L2-Specific Sublayer bits
10.8. デフォルトL2特有のSublayerビット
This is a new registry for IANA to maintain.
これはIANAが維持する新しい登録です。
Default L2-Specific Sublayer Bits ---------------------------------
デフォルトL2特有の副層ビット---------------------------------
The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. Reserved bits may be assigned by IETF Consensus [RFC2434].
Default L2特有のSublayerはヘッダーの下位の一部に8ビットを含んでいます。 予約されたビットはIETF Consensus[RFC2434]によって割り当てられるかもしれません。
Bit 0 - Reserved Bit 1 - Sequence (S bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved Bit 6 - Reserved Bit 7 - Reserved
予約されたBit1(系列(Sに噛み付いた)ビット2)はBit3を予約しました--予約されたBit4(予約されたBit5)がBit6を予約したというビット0はBit7を予約しました--予約されます。
10.9. L2-Specific Sublayer Type
10.9. L2特有の副層タイプ
This is a new registry for IANA to maintain.
これはIANAが維持する新しい登録です。
L2-Specific Sublayer Type -------------------------
L2特有の副層タイプ-------------------------
The L2-Specific Sublayer Type is a 2-octet unsigned integer. Additional values may be assigned by Expert Review [RFC2434].
L2特有のSublayer Typeは2八重奏の符号のない整数です。 加算値はExpert Review[RFC2434]によって割り当てられるかもしれません。
0 - No L2-Specific Sublayer 1 - Default L2-Specific Sublayer present
デフォルトのL2特有のSublayerが提示する0(L2特有のSublayerがありません1)
10.10. Data Sequencing Level
10.10. データ配列レベル
This is a new registry for IANA to maintain.
これはIANAが維持する新しい登録です。
Data Sequencing Level ---------------------
データ配列レベル---------------------
The Data Sequencing Level is a 2-octet unsigned integer Additional values may be assigned by Expert Review [RFC2434].
Data Sequencing Levelは割り当てられるかもしれないAdditionalがExpert Review[RFC2434]が評価する2八重奏の符号のない整数です。
0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
0--どんな受信データパケットも、配列するのを必要としません。 1--非IPデータ・パケットだけが、配列するのを必要とします。 2--すべての受信データパケットが、配列するのを必要とします。
Lau, et al. Standards Track [Page 84] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[84ページ]RFC3931L2TPv3 March 2005
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434] Narten、T.、およびH.Alvestrand、「ガイドライン、Writingに関して、IANA Considerationsが中でRFCsを区分する、」、BCP26、RFC2434(1998年10月)
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[RFC2473] コンタとA.とS.デアリング、「IPv6仕様によるジェネリックパケットトンネリング」、RFC2473、1998年12月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
and Palter, B., "Layer Two Tunneling Layer Two Tunneling
Protocol (L2TP)", RFC 2661, August 1999.
w.[RFC2661]Townsley、バレンシア、A.、ルーベンス(A.)は気がぬけます、G.、ゾルン、G.、あしらってください、B.、「層Twoはプロトコル(L2TP)にトンネルを堀りながら、層Twoにトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S.,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] パテルとB.とAbobaとB.とディクソンとW.とゾルン、G.とブース、S.、「IPsecを使用することでL2TPを固定します」、RFC3193、2001年11月。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
Assigned Numbers Authority (IANA) Considerations Update",
BCP 68, RFC 3438, December 2002.
w.[RFC3438]Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
11.2. Informative References
11.2. 有益な参照
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
Lau, et al. Standards Track [Page 85] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[85ページ]RFC3931L2TPv3 March 2005
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
[RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1700] レイノルズとJ.とポステル、J.、「規定番号」、STD2、RFC1700、1994年10月。
[RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness
Recommendations for Security", RFC 1750, December 1994.
1994年12月の[RFC1750]イーストレークとD.とクロッカー、S.とシラー、J.、「セキュリティのための偶発性推薦」RFC1750。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 大工、B.、エド、「インターネットの建築プリンシプルズ」、RFC1958、6月1996日
[RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャンとJ.とデアリング、S.とムガール人、J.、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
January 1997.
[RFC2072] バーコウィッツ、H.、「ガイドに番号を付け替えさせるルータ」、RFC2072、1997年1月。
[RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104]KrawczykとH.とBellare、M.とカネッティ、R.、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer
Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2341]バレンシア(A.とリトルウッド、M.とコラール、T.、「コクチマス層Twoの推進(プロトコル)L2F」RFC2341)は1998がそうするかもしれません。
[RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とアトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とスティーブンス、W.、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.,
and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)",
RFC 2637, July 1999.
[RFC2637]Hamzeh(K.)は気がぬけます、G.、Verthein、W.、Taarud、J.、少し、w.とゾルン、G.、「プロトコル(PPTP)にトンネルを堀るポイントツーポイント」RFC2637、1999年7月。
[RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
1999年12月の[RFC2732]HindenとR.と大工、B.とMasinter、L.、「URLの文字通りのIPv6アドレスのための形式」RFC2732。
[RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory
Tunneling via RADIUS", RFC 2809, April 2000.
[RFC2809] AbobaとB.とゾルン、G.、「RADIUSを通したL2TPコンパルソリーTunnelingの実装」、RFC2809、2000年4月。
[RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two
Tunneling Protocol (L2TP) over Frame Relay", RFC 3070,
February 2001.
[RFC3070] Rawat、V.、Tio、R.、Nanji、S.、およびVerma、R.は「フレームリレーの上で2トンネリングプロトコル(L2TP)を層にします」、RFC3070、2001年2月。
Lau, et al. Standards Track [Page 86] RFC 3931 L2TPv3 March 2005
ラウ、他 標準化過程[86ページ]RFC3931L2TPv3 March 2005
[RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two
Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5
(AAL5)", RFC 3355, August 2002.
[RFC3355] シン、A.、ターナー、R.、Tio、R.、およびNanji、S.は「気圧適合層5(AAL5)の上で2トンネルプロトコル(L2TP)を層にします」、RFC3355、2002年8月。
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network
Security: Private Communications in a Public World",
Prentice Hall, March 1995, ISBN 0-13-061466-1.
[KPS]コーフマンとC.とパールマン、R.とSpeciner、M.、「セキュリティをネットワークでつないでください」 「公立の世界の私信」、新米のホール、1995年3月、ISBN0-13-061466-1。
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The
Protocols", Addison-Wesley Publishing Company, Inc., March
1996, ISBN 0-201-63346-9.
[スティーブンス]スティーブンス、W.リチャード、「TCP/IPは例証して、ボリュームは私です」。 「プロトコル」、アディソン-ウエスリー出版社Inc.、1996年3月、ISBN0-201-63346-9。
12. Acknowledgments
12. 承認
Many of the protocol constructs were originally defined in, and the text of this document began with, RFC 2661, "L2TPv2". RFC 2661 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and B. Palter.
RFC、プロトコル構造物の多くが、ドキュメントが始まった元々定義されたコネと、このテキストでした。2661、"L2TPv2""。 RFC2661人の作者が、W.Townsley、A.バレンシアと、A.ルーベンスと、G.Pallと、G.ゾルンとB.Palterです。
The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn.
L2TPのための基本概念とプロトコル構造物の多くがL2F[RFC2341]とPPTP[RFC2637]から採用されました。 これらのバージョンの作者は、A.バレンシアと、M.リトルウッドと、T.コラールと、K.Hamzehと、G.Pallと、W.Vertheinと、J.Taarudと、W.リトルと、G.ゾルンです。
Danny Mcpherson and Suhail Nanji published the first "L2TP Service Type" version, which defined the use of L2TP for tunneling of various L2 payload types (initially, Ethernet and Frame Relay).
Danny Mcpherson and Suhail Nanji published the first "L2TP Service Type" version, which defined the use of L2TP for tunneling of various L2 payload types (initially, Ethernet and Frame Relay).
The team for splitting RFC 2661 into this base document and the companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided very helpful review and comment.
The team for splitting RFC 2661 into this base document and the companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided very helpful review and comment.
Some constructs of L2TPv3 were based in part on UTI (Universal Transport Interface), which was originally conceived by Peter Lothberg and Tony Bates.
Some constructs of L2TPv3 were based in part on UTI (Universal Transport Interface), which was originally conceived by Peter Lothberg and Tony Bates.
Stewart Bryant and Simon Barber provided valuable input for the L2TPv3 over IP header.
Stewart Bryant and Simon Barber provided valuable input for the L2TPv3 over IP header.
Juha Heinanen provided helpful review in the early stages of this effort.
Juha Heinanen provided helpful review in the early stages of this effort.
Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth and Maria Dos Santos contributed to the Control Message Authentication Mechanism as well as general discussions of security.
Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth and Maria Dos Santos contributed to the Control Message Authentication Mechanism as well as general discussions of security.
Lau, et al. Standards Track [Page 87] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 87] RFC 3931 L2TPv3 March 2005
James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted Hardie, and Pekka Savola provided very helpful review of the final versions of text.
James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted Hardie, and Pekka Savola provided very helpful review of the final versions of text.
Russ Housley provided valuable review and comment on security, particularly with respect to the Control Message Authentication mechanism.
Russ Housley provided valuable review and comment on security, particularly with respect to the Control Message Authentication mechanism.
Pekka Savola contributed to proper alignment with IPv6 and inspired much of Section 4.1.4 on fragmentation.
Pekka Savola contributed to proper alignment with IPv6 and inspired much of Section 4.1.4 on fragmentation.
Aside of his original influence and co-authorship of RFC 2661, Glen Zorn helped get all of the language and character references straight in this document.
Aside of his original influence and co-authorship of RFC 2661, Glen Zorn helped get all of the language and character references straight in this document.
A number of people provided valuable input and effort for RFC 2661, on which this document was based:
A number of people provided valuable input and effort for RFC 2661, on which this document was based:
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL, which led to improvement of the overall readability and clarity of RFC 2661.
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL, which led to improvement of the overall readability and clarity of RFC 2661.
Thomas Narten provided a great deal of critical review and formatting. He wrote the first version of the IANA Considerations section.
Thomas Narten provided a great deal of critical review and formatting. He wrote the first version of the IANA Considerations section.
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of early versions leading to RFC 2661.
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of early versions leading to RFC 2661.
Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the original endpoint authentication mechanism.
Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the original endpoint authentication mechanism.
Lau, et al. Standards Track [Page 88] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 88] RFC 3931 L2TPv3 March 2005
Appendix A: Control Slow Start and Congestion Avoidance
Appendix A: Control Slow Start and Congestion Avoidance
Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS] (this algorithm is also described in [RFC2581]).
Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS] (this algorithm is also described in [RFC2581]).
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.
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.
A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgment (either explicit or piggybacked). When the acknowledgment is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ACK message or piggybacked) is received. Increasing CWND by one on each ACK has the effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins.
A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgment (either explicit or piggybacked). When the acknowledgment is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ACK message or piggybacked) is received. Increasing CWND by one on each ACK has the effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins.
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.
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.
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.
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.
Lau, et al. Standards Track [Page 89] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 89] RFC 3931 L2TPv3 March 2005
Appendix B: Control Message Examples
Appendix B: Control Message Examples
B.1: Lock-Step Control Connection Establishment
B.1: Lock-Step Control Connection Establishment
In this example, an LCCE establishes a control connection, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within an ACK message. An alternative would be to piggyback the acknowledgment within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the control connection.
In this example, an LCCE establishes a control connection, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within an ACK message. An alternative would be to piggyback the acknowledgment within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the control connection.
LCCE A LCCE B
------ ------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ACK
Nr: 2, Ns: 1
LCCE A LCCE B ------ ------ SCCRQ -> Nr: 0, Ns: 0 <- SCCRP Nr: 1, Ns: 0 SCCCN -> Nr: 1, Ns: 1 <- ACK Nr: 2, Ns: 1
B.2: Lost Packet with Retransmission
B.2: Lost Packet with Retransmission
An existing control connection has a new session requested by LCCE A. The ICRP is lost and must be retransmitted by LCCE B. Note that loss of the ICRP has two effects: It not only keeps the upper level state machine from progressing, but also keeps LCCE A from seeing a timely lower level acknowledgment of its ICRQ.
An existing control connection has a new session requested by LCCE A. The ICRP is lost and must be retransmitted by LCCE B. Note that loss of the ICRP has two effects: It not only keeps the upper level state machine from progressing, but also keeps LCCE A from seeing a timely lower level acknowledgment of its ICRQ.
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
LCCE A LCCE B ------ ------ ICRQ -> Nr: 1, Ns: 2 (packet lost) <- ICRP Nr: 3, Ns: 1
(pause; LCCE A's timer started first, so fires first)
(pause; LCCE A's timer started first, so fires first)
ICRQ ->
Nr: 1, Ns: 2
ICRQ -> Nr: 1, Ns: 2
(Realizing that it has already seen this packet,
LCCE B discards the packet and sends an ACK message)
(Realizing that it has already seen this packet, LCCE B discards the packet and sends an ACK message)
<- ACK
Nr: 3, Ns: 2
<- ACK Nr: 3, Ns: 2
Lau, et al. Standards Track [Page 90] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 90] RFC 3931 L2TPv3 March 2005
(LCCE B's retransmit timer fires)
(LCCE B's retransmit timer fires)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ICRP Nr: 3, Ns: 1 ICCN -> Nr: 2, Ns: 3
<- ACK
Nr: 4, Ns: 2
<- ACK Nr: 4, Ns: 2
Appendix C: Processing Sequence Numbers
Appendix C: Processing Sequence Numbers
The Default L2-Specific Sublayer, defined in Section 4.6, provides a 24-bit field for sequencing of data packets within an L2TP session. L2TP data packets are never retransmitted, so this sequence is used only to detect packet order, duplicate packets, or lost packets.
The Default L2-Specific Sublayer, defined in Section 4.6, provides a 24-bit field for sequencing of data packets within an L2TP session. L2TP data packets are never retransmitted, so this sequence is used only to detect packet order, duplicate packets, or lost packets.
The 24-bit Sequence Number field of the Default L2-Specific Sublayer contains a packet sequence number for the associated session. Each sequenced data packet that is sent must contain the sequence number, incremented by one, of the previous sequenced packet sent on a given L2TP session. Upon receipt, any packet with a sequence number equal to or greater than the current expected packet (the last received in-order packet plus one) should be considered "new" and accepted. All other packets are considered "old" or "duplicate" and discarded. Note that the 24-bit sequence number space includes zero as a valid sequence number (as such, it may be implemented with a masked 32-bit counter if desired). All new sessions MUST begin sending sequence numbers at zero.
The 24-bit Sequence Number field of the Default L2-Specific Sublayer contains a packet sequence number for the associated session. Each sequenced data packet that is sent must contain the sequence number, incremented by one, of the previous sequenced packet sent on a given L2TP session. Upon receipt, any packet with a sequence number equal to or greater than the current expected packet (the last received in-order packet plus one) should be considered "new" and accepted. All other packets are considered "old" or "duplicate" and discarded. Note that the 24-bit sequence number space includes zero as a valid sequence number (as such, it may be implemented with a masked 32-bit counter if desired). All new sessions MUST begin sending sequence numbers at zero.
Larger or smaller sequence number fields are possible with L2TP if an alternative format to the Default L2-Specific Sublayer defined in this document is used. While 24 bits may be adequate in a number of circumstances, a larger sequence number space will be less susceptible to sequence number wrapping problems for very high session data rates across long dropout periods. The sequence number processing recommendations below should hold for any size sequence number field.
Larger or smaller sequence number fields are possible with L2TP if an alternative format to the Default L2-Specific Sublayer defined in this document is used. While 24 bits may be adequate in a number of circumstances, a larger sequence number space will be less susceptible to sequence number wrapping problems for very high session data rates across long dropout periods. The sequence number processing recommendations below should hold for any size sequence number field.
When detecting whether a packet sequence number is "greater" or "less" than a given sequence number value, wrapping of the sequence number must be considered. This is typically accomplished by keeping a window of sequence numbers beyond the current expected sequence number for determination of whether a packet is "new" or not. The window may be sized based on the link speed and sequence number space and SHOULD be configurable with a default equal to one half the size of the available number space (e.g., 2^(n-1), where n is the number of bits available in the sequence number).
When detecting whether a packet sequence number is "greater" or "less" than a given sequence number value, wrapping of the sequence number must be considered. This is typically accomplished by keeping a window of sequence numbers beyond the current expected sequence number for determination of whether a packet is "new" or not. The window may be sized based on the link speed and sequence number space and SHOULD be configurable with a default equal to one half the size of the available number space (e.g., 2^(n-1), where n is the number of bits available in the sequence number).
Lau, et al. Standards Track [Page 91] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 91] RFC 3931 L2TPv3 March 2005
Upon receipt, packets that exactly match the expected sequence number are processed immediately and the next expected sequence number incremented. Packets that fall within the window for new packets may either be processed immediately and the next expected sequence number updated to one plus that received in the new packet, or held for a very short period of time in hopes of receiving the missing packet(s). This "very short period" should be configurable, with a default corresponding to a time lapse that is at least an order of magnitude less than the retransmission timeout periods of higher layer protocols such as TCP.
Upon receipt, packets that exactly match the expected sequence number are processed immediately and the next expected sequence number incremented. Packets that fall within the window for new packets may either be processed immediately and the next expected sequence number updated to one plus that received in the new packet, or held for a very short period of time in hopes of receiving the missing packet(s). This "very short period" should be configurable, with a default corresponding to a time lapse that is at least an order of magnitude less than the retransmission timeout periods of higher layer protocols such as TCP.
For typical transient packet mis-orderings, dropping out-of-order packets alone should suffice and generally requires far less resources than actively reordering packets within L2TP. An exception is a case in which a pair of packet fragments are persistently retransmitted and sent out-of-order. For example, if an IP packet has been fragmented into a very small packet followed by a very large packet before being tunneled by L2TP, it is possible (though admittedly wrong) that the two resulting L2TP packets may be consistently mis-ordered by the PSN in transit between L2TP nodes. If sequence numbers were being enforced at the receiving node without any buffering of out-of-order packets, then the fragmented IP packet may never reach its destination. It may be worth noting here that this condition is true for any tunneling mechanism of IP packets that includes sequence number checking on receipt (i.e., GRE [RFC2890]).
For typical transient packet mis-orderings, dropping out-of-order packets alone should suffice and generally requires far less resources than actively reordering packets within L2TP. An exception is a case in which a pair of packet fragments are persistently retransmitted and sent out-of-order. For example, if an IP packet has been fragmented into a very small packet followed by a very large packet before being tunneled by L2TP, it is possible (though admittedly wrong) that the two resulting L2TP packets may be consistently mis-ordered by the PSN in transit between L2TP nodes. If sequence numbers were being enforced at the receiving node without any buffering of out-of-order packets, then the fragmented IP packet may never reach its destination. It may be worth noting here that this condition is true for any tunneling mechanism of IP packets that includes sequence number checking on receipt (i.e., GRE [RFC2890]).
Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only non-IP data packets require sequencing) allows IP data packets being tunneled by L2TP to not utilize sequence numbers, while utilizing sequence numbers and enforcing packet order for any remaining non-IP data packets. Depending on the requirements of the link layer being tunneled and the network data traversing the data link, this is sufficient in many cases to enforce packet order on frames that require it (such as end-to-end data link control messages), while not on IP packets that are known to be resilient to packet reordering.
Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only non-IP data packets require sequencing) allows IP data packets being tunneled by L2TP to not utilize sequence numbers, while utilizing sequence numbers and enforcing packet order for any remaining non-IP data packets. Depending on the requirements of the link layer being tunneled and the network data traversing the data link, this is sufficient in many cases to enforce packet order on frames that require it (such as end-to-end data link control messages), while not on IP packets that are known to be resilient to packet reordering.
If a large number of packets (i.e., more than one new packet window) are dropped due to an extended outage or loss of sequence number state on one side of the connection (perhaps as part of a forwarding plane reset or failover to a standby node), it is possible that a large number of packets will be sent in-order, but be wrongly detected by the peer as out-of-order. This can be generally characterized for a window size, w, sequence number space, s, and number of packets lost in transit between L2TP endpoints, p, as follows:
If a large number of packets (i.e., more than one new packet window) are dropped due to an extended outage or loss of sequence number state on one side of the connection (perhaps as part of a forwarding plane reset or failover to a standby node), it is possible that a large number of packets will be sent in-order, but be wrongly detected by the peer as out-of-order. This can be generally characterized for a window size, w, sequence number space, s, and number of packets lost in transit between L2TP endpoints, p, as follows:
Lau, et al. Standards Track [Page 92] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 92] RFC 3931 L2TPv3 March 2005
If s > p > w, then an additional (s - p) packets that were otherwise received in-order, will be incorrectly classified as out-of-order and dropped. Thus, for a sequence number space, s = 128, window size, w = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional packets would be dropped after the outage until the sequence number wrapped back to the current expected next sequence number.
If s > p > w, then an additional (s - p) packets that were otherwise received in-order, will be incorrectly classified as out-of-order and dropped. Thus, for a sequence number space, s = 128, window size, w = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional packets would be dropped after the outage until the sequence number wrapped back to the current expected next sequence number.
To mitigate this additional packet loss, one MUST inspect the sequence numbers of packets dropped due to being classified as "old" and reset the expected sequence number accordingly. This may be accomplished by counting the number of "old" packets dropped that were in sequence among themselves and, upon reaching a threshold, resetting the next expected sequence number to that seen in the arriving data packets. Packet timestamps may also be used as an indicator to reset the expected sequence number by detecting a period of time over which "old" packets have been received in-sequence. The ideal thresholds will vary depending on link speed, sequence number space, and link tolerance to out-of-order packets, and MUST be configurable.
To mitigate this additional packet loss, one MUST inspect the sequence numbers of packets dropped due to being classified as "old" and reset the expected sequence number accordingly. This may be accomplished by counting the number of "old" packets dropped that were in sequence among themselves and, upon reaching a threshold, resetting the next expected sequence number to that seen in the arriving data packets. Packet timestamps may also be used as an indicator to reset the expected sequence number by detecting a period of time over which "old" packets have been received in-sequence. The ideal thresholds will vary depending on link speed, sequence number space, and link tolerance to out-of-order packets, and MUST be configurable.
Editors' Addresses
Editors' Addresses
Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134
Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134
EMail: jedlau@cisco.com
EMail: jedlau@cisco.com
W. Mark Townsley cisco Systems
W. Mark Townsley cisco Systems
EMail: mark@townsley.net
EMail: mark@townsley.net
Ignacio Goyret Lucent Technologies
Ignacio Goyret Lucent Technologies
EMail: igoyret@lucent.com
EMail: igoyret@lucent.com
Lau, et al. Standards Track [Page 93] RFC 3931 L2TPv3 March 2005
Lau, et al. Standards Track [Page 93] RFC 3931 L2TPv3 March 2005
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Lau, et al. Standards Track [Page 94]
Lau, et al. Standards Track [Page 94]
一覧
スポンサーリンク
