[要約] RFC 3070は、フレームリレー上でのレイヤー2トンネリングプロトコル（L2TP）の実装に関する仕様です。このRFCの目的は、フレームリレーネットワーク上でL2TPを使用するためのガイドラインを提供することです。
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
フレームリレー上の2つのトンネルプロトコル（L2TP）を層
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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操作を絶縁します。ベースプロトコル仕様は、IP環境でL2TPを使用する方法を示しています。このドキュメントは、ネイティブフレームリレーを介した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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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に接続されている各ユーザーの状態を維持します。セッションは、ユーザーとLNSの間でエンドツーエンドのPPP接続が試行されるときに作成されます。セッションに関連するデータグラムは、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]で説明されています。Frame Relay上の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.
L2TPのフレーム形式は、RFC 1490 [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の場合、SNAPヘッダーの存在を示すL2TP NLPID値0x80が使用されます。
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
図1フレームリレーにカプセル化されたL2TPフレームの形式
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つのフレームリレーエンドポイントは、PPP Max-Receive-UnitサイズをPPP L2TPヘッダーサイズにフレームリレーヘッダーサイズのPPPヘッダーサイズに追加することに基づいた、少なくとも1526のMTUサイズをサポートする必要があります。（PPPヘッダーサイズは、プロトコルフィールドサイズとHDLCフレーミングバイトで、L2TPで必要です）。フレームリレーインターフェイスでのパケットの破棄を回避するために、推奨されるデフォルトのフレームリレーMTUは、1500のPPPデフォルトMRUに基づいて1564です。これらの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].
フレームリレーSVCSの場合、L2TPがトンネルの作成を試みたときに接続セットアップがトリガーされます。トリガーメカニズムの詳細は、実装に残されています。L2TPによるフレームリレーSVCシグナル伝達に変化はありません。L2TPトンネルのエンドポイントは、フレームリレーSVCの場合のX.121/E.164アドレスで識別する必要があります。これらのアドレスは、[4]で定義されているユーザーのトンネルエンドポイントとして取得できます。PVCの場合、L2TPトラフィックを運ぶための仮想回路を管理的に構成することができます。トンネルのエンドポイントは、構成時間にPVCに割り当てられたDLCIによって識別される必要があります。このDLCIは、[4]で定義されているユーザーのトンネルエンドポイントとして取得できます。
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とフレームリレーの間にフレーミングの問題はありません。リモートユーザーからRACが受信した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.
Ken Pierce（3Com Corporation）と（Rick Dynarski 3com Corporation）は、このドキュメントの編集に貢献しました。
[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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。and B. Palter "Layer Two Tunneling Protocol '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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 , Frame Relay Forum Technical Committee, June 1995.
[3] Multiprotocol Encapsulation実装契約、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] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートの半径属性」、RFC 2868、2000年6月。
[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] Bradley、T.、Brown、C。and A. Malis、「Multiprotocol Interconnect Over Frame Relay」、RFC 1490、1993年7月。
Vipin Rawat ONI Systems, Inc. 166 Baypointe Parkway San Jose CA 95134
Vipin Rawat Oni Systems、Inc。166 Baypointe Parkway San Jose CA 95134
EMail: vrawat@oni.com
Rene Tio Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Rene Tio Redback Networks、Inc。300 Holger Way San Jose、CA 95134
EMail: tor@redback.com
Rohit Verma Deloitte Consulting 180 N. Stetson Avenue Chicago Illinois 60601
Rohit Verma Deloitte Consulting 180 N. Stetson Avenue Chicago Illinois 60601
EMail: rverma@dc.com
Suhail Nanji Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Suhail Nanji Redback Networks、Inc。300 Holger Way San Jose、CA 95134
EMail: suhail@redback.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。