[要約] RFC 3437は、PPPリンク制御プロトコルの交渉のためのLayer-Two Tunneling Protocol（L2TP）の拡張に関するものです。このRFCの目的は、L2TPを使用してPPPセッションを確立するための新しい機能を提供することです。
Network Working Group W. Palter
Request for Comments: 3437 zev.net
Category: Standards Track W. Townsley
Cisco Systems
December 2002
Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
PPPリンク制御プロトコル交渉のためのレイヤーツートンネリングプロトコル拡張
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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides.
このドキュメントでは、リンク固有のポイントトゥポイントプロトコル（PPP）オプションのサポートを強化するために、レイヤー2トンネリングプロトコル（L2TP）レイヤーへの拡張機能を定義します。PPPエンドポイントは通常、それらを接続する共通の物理メディアに直接アクセスできるため、使用中のメディアに関する詳細な知識があります。L2TPを使用すると、2つのPPPピアが同じ物理メディアで直接接続されなくなります。代わりに、L2TPは、IPなどのパケットスイッチされたネットワーク上でPPPフレームをトンネリングすることにより、PPP接続の一部またはすべてに仮想接続を挿入します。いくつかの条件下では、L2TPエンドポイントは、LCP交渉への適切な参加に必要なすべてのメディア情報にアクセスできない可能性のある場所で、PPPリンク制御プロトコル（LCP）オプションをネゴシエートする必要がある場合があります。このドキュメントは、L2TPトンネルの遠端でのPPP LCP交渉に先立って、L2TPエンドポイント間で望ましいLCPオプションを通信するメカニズムと、ネイティブPPPリンクが存在する場所に交渉されたLCPオプションを伝達するメカニズムを提供します。
Table of Contents
目次
1. Introduction............................................... 2
1.1 Specification of Requirements........................... 3
2. LCP Options From LAC to LNS................................ 3
2.1 LCP Want Options (iccn, occn)........................... 4
2.2 LCP Allow Options (iccn, occn).......................... 6
2.3 LCP Options From LNS to LAC............................. 7
3. Security Considerations.................................... 8
4. IANA Considerations........................................ 8
5. Normative References....................................... 8
6. Author's Addresses......................................... 9
7. Full Copyright Statement................................... 10
L2TP [RFC2661] provides a very limited amount of guidance to the LNS as to what type of interface a tunneled PPP session arrived on at an LAC. Such information is limited to whether the interface was "synchronous" or "asynchronous", "digital" or "analog." These indications provide some guidance when negotiating PPP LCP at the LNS, but they are not as robust as they could be.
L2TP [RFC2661]は、Tunneled PPPセッションがラックに到着したインターフェイスの種類について、LNSに非常に限られた量のガイダンスを提供します。このような情報は、インターフェイスが「同期」または「非同期」、「デジタル」または「アナログ」であるかどうかに限定されます。これらの適応症は、LNSでPPP LCPを交渉する際のガイダンスを提供しますが、可能な限り堅牢ではありません。
This document defines a more robust way to inform the LAC of LCP negotiated options, and provides guidance to the LNS on the limits and values that the LAC requires during LCP negotiation. Deep knowledge of PPP [RFC1661] and L2TP [RFC2661] are expected for the remainder of this document.
このドキュメントは、LCP交渉オプションのLACに通知するためのより堅牢な方法を定義し、LCP交渉中にLACが必要とする制限と価値に関するLNSにガイダンスを提供します。PPP [RFC1661]およびL2TP [RFC2661]の深い知識は、このドキュメントの残りの部分で予想されます。
L2TP Proxy LCP allows options to be negotiated where the native PPP link resides, thus circumventing issues with ACCM, Alternate FCS, and other LCP Options that the LNS would not necessarily know how to properly negotiate without access to the physical media for the native PPP connection, interface type, or configuration. However, use of Proxy LCP introduces other problems as well as there are options within LCP PPP negotiation which should be set or adjusted by the LNS, such as the PPP Authentication Type and MRU. Finally, the PPP Client may reinitiate LCP negotiation at any time, and unless the LAC is sniffing every PPP data packet it forwards, it would not be aware that this is even occurring.
L2TPプロキシLCPを使用すると、ネイティブPPPリンクが存在する場所でオプションを交渉できます。したがって、ACCM、代替FCS、およびLNSがネイティブPPP接続の物理メディアにアクセスせずに適切に交渉する方法を必ずしも知るとは限らない他のLCPオプションを回避することができます。、インターフェイスタイプ、または構成。ただし、プロキシLCPを使用すると、PPP認証タイプやMRUなど、LNSが設定または調整する必要があるLCP PPP交渉内にオプションがあります。最後に、PPPクライアントはいつでもLCPの交渉を再開することができ、LACがすべてのPPPデータパケットを前方にスニッフィングしていない限り、これが発生していることも認識しません。
LCP options may be classified into roughly three different categories with respect to their affect on L2TP; (1) options which affect framing in a way that the LAC may need to know about or handle specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are mostly transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the LAC may wish to influence because they are dependent on the media type (ACFC, PFC). We are most concerned with options that fall into category (1) and (3).
LCPオプションは、L2TPへの影響に関して、約3つの異なるカテゴリに分類される場合があります。（1）Framingに影響を与えるオプションは、LACが具体的に知っているか、処理する必要がある方法で（例：Alt-FCS、ACCM、MRU）、（2）LACに対してほとんど透過的であるオプション（例：AUTH-TYPE）、および（3）LACがメディアタイプ（ACFC、PFC）に依存しているためにLACが影響を受けることを望む可能性のあるオプション。私たちは、カテゴリ（1）および（3）に分類されるオプションに最も関心を持っています。
This document defines new AVPs to allow the LAC and the LNS to communicate complete LCP information in order to react accordingly. LCP option information is structured in the same way as the Proxy LCP AVPs are in [RFC2661]. This essentially involves encapsulation of a PPP LCP Configure-Request or Configure-Ack packet within an L2TP AVP.
このドキュメントでは、それに応じて反応するために、LACとLNSが完全なLCP情報を通信できるようにする新しいAVPを定義しています。LCPオプション情報は、プロキシLCP AVPが[RFC2661]にあるのと同じように構成されています。これには、本質的に、L2TP AVP内のPPP LCP Configure-RequestまたはConfigure-cackパケットのカプセル化が含まれます。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The LAC may utilize the following AVPs within an ICCN or OCCN message in order to influence the LNS to negotiate LCP in a specific manner. If these AVPs are supported by the LNS, they should override any suggestions for LCP options implied by the Bearer Type or Framing Type AVPs.
LACは、LNSに影響を与えてLCPを特定の方法で交渉するために、ICCNまたはOCCNメッセージ内で次のAVPを利用する場合があります。これらのAVPがLNSによってサポートされている場合、BearerタイプまたはフレーミングタイプAVPによって暗示されるLCPオプションの提案をオーバーライドする必要があります。
These AVPs may coexist with the Proxy LCP and Proxy Authentication AVPs (Proxy AVPs) defined in the base L2TP specification. If Proxy AVPs are received, the LNS may choose to accept these parameters, or renegotiate LCP with the options suggested by the AVPs defined in this document. If the LAC wishes to force negotiation of LCP by the LNS, it should simply omit all Proxy AVPs during call initialization.
これらのAVPは、ベースL2TP仕様で定義されているプロキシLCPおよびプロキシ認証AVP（プロキシAVP）と共存する場合があります。プロキシAVPを受信した場合、LNSはこれらのパラメーターを受け入れるか、このドキュメントで定義されているAVPで提案されたオプションを使用してLCPを再交渉することを選択できます。LACがLNSによるLCPの交渉を強制したい場合、コール初期化中にすべてのプロキシAVPを省略するだけです。
By default, the AVPs defined in this document are not mandatory (M-bit is set to zero). However, if an implementation needs to strongly enforce adherence to the options defined within the AVPs, it MAY set the M-bit to 1, thus forcing the peer to discontinue the session if it does not support this AVP. This is NOT recommended unless it is known that the result of operating without these extensions is completely unacceptable.
デフォルトでは、このドキュメントで定義されているAVPは必須ではありません（Mビットはゼロに設定されています）。ただし、実装でAVP内で定義されているオプションへの順守を強く施行する必要がある場合、Mビットを1に設定する可能性があるため、このAVPをサポートしていない場合はピアにセッションを中止させます。これらの拡張機能なしで動作した結果が完全に受け入れられないことがわかっていない限り、これは推奨されません。
If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST be prepared to accept the AVPs as defined in section 2.3.
セクション2.1および2.2のAVPがLNSに送信される場合、LACはセクション2.3で定義されているようにAVPを受け入れるように準備する必要があります。
The LCP Allow Options AVP, Attribute Type 49, contains a list of options that the LAC wants to be negotiated by the LNS.
LCPは、AVP属性タイプ49のAVPを許可し、LACがLNSによって交渉したいオプションのリストが含まれています。
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 | LCP Configure-Req ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Req (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
ベンダーIDは0のIETFベンダーIDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVPは隠されている可能性があります（Hビットは0または1です）。
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
このAVPのMビットは0または1に設定される場合があります。このAVPの送信者が、このL2TP拡張を理解していないピアへの接続を確立したくない場合、Mビットを1に設定する必要があります。0に設定します。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
このAVPの長さ（隠す前）は、6とLCP構成要求の長さに加えています。
The AVP SHOULD be present in the following messages: ICCN, OCCN
AVPは次のメッセージに存在する必要があります：ICCN、OCCN
The LCP Configure-Req Value for this AVP is identical to the information field of a PPP LCP Configure-Req Packet (much like a Proxy LCP AVP in [RFC2661]). It is sent from the LAC to the LNS, and is intended to guide PPP LCP negotiations at an LNS. In some cases, each individual PPP LCP option carried in this AVP maps to a desired value (e.g., MRU) and in some cases it maps to a specific option that is desired to be enabled (e.g., ACFC). The LNS should use these suggestions when building its initial Configure-Request.
このAVPのLCP構成-REQ値は、PPP LCP configure-reqパケットの情報フィールドと同じです（[RFC2661]のプロキシLCP AVPによく似ています）。LACからLNSに送信され、LNSでPPP LCPの交渉を導くことを目的としています。場合によっては、このAVPマップに希望の値（MRUなど）に携帯されており、場合によっては有効にする必要がある特定のオプション（ACFCなど）にマップされた個々のPPP LCPオプションがあります。LNSは、最初の構成要求を構築するときにこれらの提案を使用する必要があります。
The following chart defines some of the more common LCP options that may be included in this AVP with guidance on how to handle them at the LAC and LNS. This table is provided for some of the more common or problematic LCP options. It is not intended to be an exhaustive representation of all LCP options available.
次のチャートは、LACおよびLNSでそれらを処理する方法に関するガイダンスを備えた、このAVPに含まれる可能性のあるより一般的なLCPオプションの一部を定義しています。このテーブルは、より一般的または問題のあるLCPオプションのいくつかについて提供されています。利用可能なすべてのLCPオプションを徹底的に表現することを意図したものではありません。
LCP Want Option LAC Action LNS Action
LCPは、オプションlacアクションLNSアクションを要求します
MRU LAC provides a LNS SHOULD begin LCP
negotiation maximum
value with this value.
However, it MAY reduce
MRU if necessary.
ACCM LAC Provides a mask LNS SHOULD begin LCP negotiation with this value. LNS may add bit(s) while negotiating.
ACCM LACは、LNSがこの値でLCPの交渉を開始するマスクを提供します。LNSは交渉中にビットを追加する場合があります。
PFC LAC provides PFC LNS SHOULD begin LCP
on the link type negotiation if it is
desired with
the link type this value.
(e.g. AHDLC)
ACFC LAC provides ACCOMP LNS SHOULD begin LCP
if it is desired on negotiation with this
the link type value.
(e.g. AHDLC)
FCS-ALT LAC indicates required LNS SHOULD begin
values for the link negotiation with this
type value. Note that this
value is of no
consequence to the LNS
as FCS is stripped at
the LAC, however some
PPP media types require
this option.
The LCP Allow Options AVP, Attribute Type 50 contains a list of options that the LAC will allow to be negotiated by the LNS.
LCPはAVPを許可します。属性タイプ50には、LACがLNSによって交渉できるオプションのリストが含まれています。
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 | LCP Configure-Ack ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Ack (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
ベンダーIDは0のIETFベンダーIDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVPは隠されている可能性があります（Hビットは0または1です）。
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
このAVPのMビットは0または1に設定される場合があります。このAVPの送信者が、このL2TP拡張を理解していないピアへの接続を確立したくない場合、Mビットを1に設定する必要があります。0に設定します。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
このAVPの長さ（隠す前）は、6とLCP構成要求の長さに加えています。
The AVP MAY be present in the following messages: ICCN, OCCN
AVPは次のメッセージに存在する場合があります：ICCN、OCCN
The LCP Configure-Ack Value for this AVP is identical to the information field of a PPP LCP Configure-Req Packet (much like a Proxy LCP AVP in [RFC2661]). It is sent from the LAC to the LNS, and is intended to guide PPP LCP negotiations at an LNS. In some cases, each individual PPP LCP option carried in this AVP maps to a maximum value (e.g., MRU), while in others it maps to an option that is permitted by the LAC (e.g., ACFC). If the option is not included here, it can be assumed by the LNS that the LAC does not understand how to perform that particular option at the link layer (and would thus Configure-Reject that option). Information in this AVP should be utilized when building PPP Configure-Ack, Configure-Reject and Configure-Nak messages.
このAVPのLCP構成-ACK値は、PPP LCP Configure-Reqパケットの情報フィールドと同一です（[RFC2661]のプロキシLCP AVPによく似ています）。LACからLNSに送信され、LNSでPPP LCPの交渉を導くことを目的としています。場合によっては、このAVPマップに最大値（MRUなど）に携帯されている個々のPPP LCPオプションは、LAC（ACFCなど）で許可されているオプションにマップします。オプションがここに含まれていない場合、LNSによって、LACがリンクレイヤーでその特定のオプションを実行する方法を理解していないことを想定できます（したがって、そのオプションを削除します）。このAVPの情報は、PPP configure-ack、configure-reject、およびconfigure-nakメッセージを構築するときに使用する必要があります。
The following chart defines some of the more common LCP options that may be included in this AVP with guidance on how to handle them at the LAC and LNS. This table is provided for illustration purposes for some of the more common or problematic LCP options. It is not intended to be an exhaustive representation of all LCP options available.
次のチャートは、LACおよびLNSでそれらを処理する方法に関するガイダンスを備えた、このAVPに含まれる可能性のあるより一般的なLCPオプションの一部を定義しています。この表は、より一般的または問題のあるLCPオプションのいくつかのイラストを目的としています。利用可能なすべてのLCPオプションを徹底的に表現することを意図したものではありません。
LCP Allow Option LAC Action LNS Action
LCPは、オプションLACアクションLNSアクションを許可します
MRU LAC provides a LNS may accept reduction
maximum value MRU as requested.
ACCM LAC Provides a mask LNS may accept bit(s) defined here. Note that if ACCM is missing it is assumed that it is not applicable to the link type.
ACCM LACは、ここで定義されているビットを受け入れるマスクを提供します。ACCMが欠落している場合、リンクタイプに適用できないと想定されていることに注意してください。
PFC LAC provides PFC LNS may accept PFC. if it is allowed on the link type (e.g. AHDLC)
PFC LACは、PFC LNSがPFCを受け入れることができます。リンクタイプで許可されている場合（例：AHDLC）
ACFC LAC provides ACFC LNS may accept ACFC. if it is allowed on the link type (e.g. AHDLC)
ACFC LACはACFC LNSがACFCを受け入れることができます。リンクタイプで許可されている場合（例：AHDLC）
FCS-ALT LAC indicates valid Negotiation this option
values for the link is of no consequence to
type the LNS as the FCS is
stripped at the LAC.
However, the LNS SHOULD
only accept FCS-ALT types
listed here (more than
one
value may be present).
In order to communicate negotiated LCP parameters from the LNS to the LAC, the format of two existing messages in [RFC2661] are used. These are:
交渉されたLCPパラメーターをLNSからLACに伝えるために、[RFC2661]の2つの既存のメッセージの形式が使用されます。これらは：
Last Sent LCP Confreq (IETF L2TP Attribute 27) Last Received LCP Confreq (IETF L2TP Attribute 28)
最後に送信されたLCP confreq（IETF L2TP属性27）は、最後にLCP confreq（IETF L2TP属性28）を受け取りました。
These AVPs are sent from the LAC to the LNS to support Proxy LCP negotiation. In order to report negotiated LCP parameters from the LNS to the LAC, two messages of precisely the same format are defined:
これらのAVPは、Proxy LCPの交渉をサポートするためにLACからLNSに送信されます。交渉されたLCPパラメーターをLNSからLACに報告するために、まったく同じ形式の2つのメッセージが定義されています。
LNS Last Sent LCP Confreq (IETF L2TP Attribute 51) LNS Last Received LCP Confreq (IETF L2TP Attribute 52)
LNSは最後にlcp confreq（IETF L2TP属性51）を送信しましたLNSはLCP confreq（IETF L2TP属性52）を受信しました
When LCP negotiation is completed by the LNS, a Set-Link-Info control message MUST be sent with these AVPs contained within. These AVPs MUST contain the last sent and last received (with respect to the LNS) LCP packets.
LNSによってLCP交渉が完了する場合、これらのAVPを含むSET-LINK-INFO制御メッセージを送信する必要があります。これらのAVPには、最後に送信され、最後に受信された（LNSに関して）LCPパケットが含まれている必要があります。
Rather than simply using the old Attribute values in the SLI Message, new AVP Attribute types are defined for these messages due to the fact that some existing L2TP implementations might check for what could seem like misplacement of known AVP types and generate a false error condition.
SLIメッセージ内の古い属性値を単に使用するのではなく、既存のL2TP実装が既知のAVPタイプの誤った配置のように見えるものをチェックして誤ったエラー条件を生成する可能性があるため、これらのメッセージに対して新しいAVP属性タイプが定義されます。
There are no known additional significant threats incurred by the mechanisms described in this document.
このドキュメントで説明されているメカニズムによって発生する追加の重大な脅威は既知のものはありません。
This document defines additional L2TP AVPs that identify link characteristics and interface information of a tunneled PPP link. If these values were snooped, a rogue individual may have access to more information about a given network or topology. Given that these same values may be negotiated over the tunneled link in PPP LCP packets anyway, this is no more information than is potentially transmitted today, it is just in a different form.
このドキュメントでは、トンネルPPPリンクのリンク特性とインターフェイス情報を識別する追加のL2TP AVPを定義します。これらの値がスヌーピングされた場合、不正な個人は、特定のネットワークまたはトポロジに関するより多くの情報にアクセスできる場合があります。とにかく、これらの同じ値がPPP LCPパケットのトンネルリンクを介してネゴシエートされる可能性があることを考えると、これは今日の潜在的に送信されている以上の情報ではありません。
This document requires four new L2TP "AVP Attribute" numbers to be assigned by IANA.
このドキュメントでは、IANAによって割り当てられる4つの新しいL2TP「AVP属性」番号が必要です。
49, Section 2.1, LCP Want Options 50, Section 2.2, LCP Allow Options 51, Section 2.3, LNS Last Sent LCP Confreq 52, Section 2.3, LNS Last Received LCP Confreq
49、セクション2.1、LCPはオプション50、セクション2.2、LCPがオプション51、セクション2.3、LNSを最後に送信しました。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC 2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G.およびB. Palter、「レイヤー2トンネリングレイヤー2トンネリングプロトコル（L2TP）」、RFC 2661、8月1999年。
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークタウンズリーシスコシステム7025キットクリークロードPOボックス14987リサーチトライアングルパーク、ノースカロライナ州27709
EMail: mark@townsley.net
Bill Palter EMail: palter.ietf@zev.net
ビル・パーターの電子メール：palter.ietf@zev.net
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。