Network Working Group V. Rawat
Request for Comments: 3070 ONI Systems, Inc.
Category: Standards Track R. Tio
S. Nanji
Redback Networks, Inc.
R. Verma
Deloitte Consulting
February 2001
Layer Two Tunneling Protocol (L2TP) over Frame Relay
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel Point-to-Point (PPP) sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over the User Datagram Protocol (UDP) and the Internet Protocol (IP). This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs).
レイヤ2トンネリングプロトコル（L2TP）はトンネルポイントツーポイント（PPP）セッションへのメカニズムを説明しています。プロトコルは、それが上で動作するメディアに依存しないように設計されています。基本仕様は、ユーザーデータグラムプロトコル（UDP）およびインターネット・プロトコル（IP）上で実行するように実装する方法について説明します。この文書では、L2TPは、フレームリレーPVCと相手先選択接続（SVC）の上に実装されている方法を説明します。
Applicability
適用性
This specification is intended for those implementations which desire to use facilities which are defined for L2TP and applies only to the use of Frame Relay pont-to-point circuits.
この仕様は、L2TPのために定義のみフレームリレーポン・ツー・ポイント回路の使用に適用されている機能を使用することを望むそれらの実装のために意図されています。
L2TP [1] defines a general purpose mechanism for tunneling PPP over various media. By design, it insulates L2TP operation from the details of the media over which it operates. The base protocol specification illustrates how L2TP may be used in IP environments. This document specifies the encapsulation of L2TP over native Frame Relay and addresses relevant issues.
L2TP [1]は、様々な媒体を介してPPPをトンネリングするための汎用メカニズムを定義します。設計することにより、それが動作する上でのメディアの詳細からL2TP操作を絶縁します。ベースプロトコル仕様では、L2TPはIP環境で使用することができる方法を示します。この文書では、ネイティブのフレームリレー上でL2TPのカプセル化を指定し、関連する問題に対処します。
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 RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
In this section we describe in high level terms the scope of the problem being addressed. Topology:
このセクションでは、ハイレベルの用語でアドレス指定されている問題の範囲を記述します。トポロジー：
+------+ +---------------+ |
| PSTN | | Frame Relay | |
User--| |----LAC ===| |=== LNS --+ LANs
| ISDN | | Cloud | |
+------+ +---------------+ |
An L2TP Access Concentrator (LAC) is a device attached to the switched network fabric (e.g., PSTN or ISDN) or co-located with a PPP end system capable of handling the L2TP protocol. The LAC need only implement the media over which L2TP is to operate to pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP.
L2TPアクセス・コンセントレータ（LAC）は、スイッチドネットワークファブリック（例えば、PSTN又はISDN）に接続されたデバイスであるか、またはL2TPプロトコルを扱うことができるPPPエンドシステムと同じ場所に配置します。 LACは、L2TPは、1つまたは複数のLNS年代にトラフィックを通過するように動作することで、その上のメディアを実装するだけです。これは、トンネルの任意のプロトコルは、PPP内で行ってもよいです。
L2TP Network Server (LNS) operates on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol. L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached to an LAC. A session is created when an end-to-end PPP connection is attempted between a user and the LNS. The datagrams related to a session are sent over the tunnel between the LAC and LNS. A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS.
L2TPネットワークサーバ（LNS）は、PPP終端することができる任意のプラットフォーム上で動作します。 LNSは、L2TPプロトコルのサーバー側を処理します。 L2TPは接続指向です。 LNSとLACはLACに取り付けられている各ユーザの状態を維持します。エンドツーエンドPPP接続はユーザとLNS間で試行されるときに、セッションが作成されます。セッションに関連するデータグラムはLACとLNS間のトンネルを介して送信されます。トンネルはLNS-LACペアによって定義されます。トンネルはLACとLNS間のPPPデータグラムを運びます。
L2TP protocol operates at a level above the particular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. L2TP over IP/UDP is described in the base L2TP specification [1]. Issues related to L2TP over Frame Relay are addressed in later sections of this document.
L2TPプロトコルは、それが実行され、その上、特定のメディア上のレベルで動作します。しかし、メディアへの接続のいくつかの詳細は、相互運用可能な実装を可能にするために必要とされています。 IP / UDP上L2TPベースL2TPの明細書に記載されている[1]。フレームリレー上でL2TPに関連する問題は、このドキュメントの後のセクションで対処されています。
L2TP MUST be able to share a Frame Relay virtual circuit (VC) with other protocols carried over the same VC. The Frame Relay header format for data packet needs to be defined to identify the protocol being carried in the packets. The Frame Relay network may not understand these formats.
L2TPは、同じVC上で搬送他のプロトコルとフレームリレー仮想回路（VC）を共有することができなければなりません。データパケットのフレーム・リレー・ヘッダ・フォーマットは、パケットで搬送されるプロトコルを識別するために定義される必要があります。フレームリレーネットワークでは、これらのフォーマットを理解しないかもしれません。
All protocols over this circuit MUST encapsulate their packets within a Q.922 frame. Additionally, frames must contain information necessary to identify the protocol carried within the frame relay Protocol Data Unit (PDU), thus allowing the receiver to properly process the incoming packet.
この回路の上にすべてのプロトコルはQ.922フレーム内でそのパケットをカプセル化しなければなりません。また、フレームは、このように受信機が正しく受信パケットを処理することができ、プロトコルデータユニット（PDU）を中継フレーム内で搬送プロトコルを識別するために必要な情報を含んでいなければなりません。
The frame format for L2TP MUST be SNAP encapsulation as defined in RFC 1490 [6] and FRF3.1 [3]. SNAP format uses NLPID followed by Organizationally Unique Identifier and a PID.
RFC 1490で定義されてL2TPのためのフレームフォーマットは、SNAPカプセル化していなければなりません[6]とFRF3.1 [3]。 SNAPフォーマットは、NLPIDは、組織固有識別子とPIDが続い使用しています。
NLPID
NLPID
The single octet identifier provides a mechanism to allow easy protocol identification. For L2TP NLPID value 0x80 is used which indicates the presence of SNAP header.
単一オクテット識別子は容易プロトコル識別を可能にするメカニズムを提供します。 L2TP NLPID値0x80のためのSNAPヘッダの存在を示すが使用されます。
OUI & PID
OUI＆PID
The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E identifies IANA who administers the meaning of the Protocol Identifier (PID) 0x0007. Together they identify a distinct protocol.
3オクテット組織固有識別子（OUI）0x00-00-5Eは、プロトコル識別子（PID）0x0007の意味を管理IANAを特定します。彼らは一緒に明確なプロトコルを識別します。
Format of L2TP frames encapsulated in Frame Relay is given in Figure 1.
フレームリレーにカプセル化されたL2TPフレームのフォーマットを図1に示されています。
Octet 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Q.922 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Control 0x03 | pad 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | NLPID 0x80 | OUI 0x00 |
+-+-+-+-+-+-+-+-+ +
7 | OUI 0x00-5E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | PID 0x0007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| L2TP packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Format for L2TP frames encapsulated in Frame Relay
フレームリレーでカプセル化L2TPフレームについては、図1フォーマット
FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement. If fragmentation is not supported, the two Frame Relay endpoints MUST support an MTU size of at least 1526 which is based on adding the PPP Max-Receive-Unit size with the PPP header size with the Max L2TP Header Size with the Frame Relay header size (PPP header size is the protocol field size plus HDLC framing bytes, which is required by L2TP). To avoid packet discards on the Frame Relay interface, the RECOMMENDED default Frame Relay MTU is 1564 based on a PPP default MRU of 1500. The means to ensure these MTU settings are left to implementation.
FRF.12は、[5]フレームリレーフラグメンテーションの実装合意書です。フラグメンテーションがサポートされていない場合、2つのフレームリレーエンドポイントは、フレームリレーヘッダサイズで最大L2TPヘッダサイズでPPPヘッダサイズでPPP最大受信単位サイズを追加することに基づいている、少なくとも1526のMTUサイズをサポートしなければなりません（PPPヘッダサイズは、L2TPによって必要とされるプロトコルフィールドのサイズを加えたHDLCフレーミングバイトです）。フレームリレーインターフェイス上のパケットの破棄を回避するために、推奨されるデフォルトのフレームリレーMTUは1564で1500のPPPのデフォルトMRUに基づいてこれらのMTUの設定を確保するための手段が実装に残されています。
In general, QoS mechanisms can be roughly provided for with proprietary mechanisms localized within the LAC or LNS. QoS considerations are beyond the scope of this document.
一般に、QoSメカニズムは、概ねLACまたはLNS内に局在独自機構を設けることができます。 QoSの考慮事項は、この文書の範囲を超えています。
In case of Frame Relay SVCs, connection setup will be triggered when L2TP tries to create a tunnel. Details of triggering mechanism are left to implementation. There SHALL NOT be any change in Frame Relay SVC signaling due to L2TP. The endpoints of the L2TP tunnel MUST be identified by X.121/E.164 addresses in case of Frame Relay SVC. These addresses MAY be obtained as tunnel endpoints for a user as defined in [4]. In case of PVCs, the Virtual Circuit to carry L2TP traffic MAY be configured administratively. The endpoints of the tunnel MUST be identified by DLCI, assigned to the PVC at configuration time. This DLCI MAY be obtained as tunnel endpoints for a user as defined in [4].
L2TPトンネルを作成しようとすると、フレームリレーのSVCの場合には、接続設定がトリガされます。トリガー機構の詳細は実装に任されています。 L2TPによるシグナルのフレームリレーSVCの変化があってはなりません。 L2TPトンネルのエンドポイントは、フレームリレーSVCの場合にX.121 / E.164アドレスによって識別されなければなりません。 [4]で定義されるようにこれらのアドレスは、ユーザのためのトンネルエンドポイントとして得ることができます。 PVCの場合には、L2TPトラフィックを伝送する仮想回線が管理上構成されるかもしれません。トンネルのエンドポイントは、構成時にPVCに割り当てられ、DLCIによって識別されなければなりません。 [4]で定義されるように、このDLCIは、ユーザーのトンネルエンドポイントとして得ることができます。
There SHALL be no framing issues between PPP and Frame Relay. PPP frames received by LAC from remote user are stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over Frame Relay tunnel.
PPPとフレームリレーの間には、フレーミングの問題があってはなりません。リモートユーザからLACによって受信されたPPPフレームは、CRC、リンクフレーミング、およびL2TPでカプセル化された透明バイトのストリッピング、およびフレーム・リレー・トンネルを介して転送されます。
Currently there is no standard specification for Frame Relay security although the Frame Relay Forum is working on a Frame Relay Privacy Agreement. In light of this work, the issue of security will be re-examined at a later date to see if L2TP over Frame Relay specific protection mechanisms are still required. In the interim, basic security issues are discussed in the base L2TP specification [1].
フレームリレーフォーラムは、フレームリレー個人情報保護協定に取り組んでいるが、現在、フレームリレー、セキュリティのための標準仕様ではありません。この作品の光では、セキュリティ上の問題はL2TPフレームリレー上の特定の保護メカニズムがまだ必要とされるかどうかを確認するために後日再検討します。その間に、基本的なセキュリティ問題は、ベースL2TP仕様に記載されている[1]。
Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com Corporation) contributed to the editing of this document.
ケン・ピアース（3Com社株式会社）及び（リックDynarskiの3Com社）は、この文書の編集に貢献しました。
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
[1] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter "レイヤ2トンネリングプロトコル 'L2TP'"、RFC 2661、1999年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 , Frame Relay Forum Technical Committee, June 1995.
[3]マルチプロトコルカプセル化実装合意書、FRF.3.1、フレームリレーフォーラム技術委員会、1995年6月。
[4] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[4]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.およびI. Goyretを、2000年6月、RFC 2868 "RADIUSは、トンネルプロトコルサポートのための属性"。
[5] Frame Relay Fragmentation Implementation Agreement, FRF.12, Frame Relay Forum Technical Committee, December 1997.
[5]フレームリレーフラグメンテーションの実装合意書を、FRF.12は、リレーフォーラム技術委員会、1997年12月フレーム。
[6] Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
[6]ブラッドリー、T.、ブラウン、C.とA. Malis、 "フレームリレー上のマルチインターコネクト"、RFC 1490、1993年7月。
Vipin Rawat ONI Systems, Inc. 166 Baypointe Parkway San Jose CA 95134
Vipin Rawat ONI Systems、Inc.の166 BaypointeパークウェイサンノゼCA 95134
EMail: vrawat@oni.com
メールアドレス：vrawat@oni.com
Rene Tio Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
ルネ・ティオレッドバックネットワークス株式会社300ホルガー・ウェイサンノゼ、CA 95134
EMail: tor@redback.com
メールアドレス：tor@redback.com
Rohit Verma Deloitte Consulting 180 N. Stetson Avenue Chicago Illinois 60601
Rohitバーマデロイトコンサルティング180 N.ステットソンアベニューシカゴイリノイ州60601
EMail: rverma@dc.com
メールアドレス：rverma@dc.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Suhail蘭芝レッドバックネットワークス株式会社300ホルガー・ウェイサンノゼ、CA 95134
EMail: suhail@redback.com
メールアドレス：suhail@redback.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。