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
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.
著作権（C）インターネット協会（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は、パケット上のPPPフレームをトンネリングすることによってPPP接続の一部または全部を超える仮想接続は、IPなどのネットワークを切り替える挿入します。いくつかの条件の下で、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]はインターフェイスの種類をトンネル化PPPセッションへとLNSへの指導の非常に限られた量を提供LACに到着しました。そのような情報は、インターフェースが「デジタル」または、「同期」または「非同期」であったかどうかに制限される「アナログ」。 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を知らせるために、より堅牢な方法を定義し、LACはLCPネゴシエーション中に必要となる限度と値の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オプションは、このようにLNSは必ずしも適切ネイティブPPP接続のための物理メディアにアクセスせずに交渉する方法を知らないということACCM、代替FCS、および他のLCPオプションの問題を回避する、ネイティブPPPリンクが存在する場所に交渉することができます、インターフェイスタイプ、または構成。しかし、プロキシ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
LCPオプションはそれらのL2TPへの影響に関して、大きく3つの異なるカテゴリに分類することができます。 （1）の方法でフレーミングに影響するオプションLACが知っているか、具体的に処理する必要があるかもしれないこと（例えば、ALT-FCS、ACCM、MRU）、（2）LACのほとんどが透明なオプションを（例えば、AUTH-TYPE ）、及び（3）オプション
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).
LACは、彼らがメディアタイプ（ACFC、PFC）に依存しているため、影響することを望むかもしれません。私たちは、カテゴリ（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のAVPは、[RFC2661]にあるようにLCPオプション情報も同様に構成されています。これは本質的にPPP LCP設定要求またはL2TP AVP内の設定肯定応答パケットのカプセル化を必要とします。
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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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は、特異的にLCPを交渉するLNSに影響を与えるためにICCN又はOCCNメッセージ内の次のAVPを利用することができます。これらのAVPはLNSによってサポートされている場合は、ベアラ・タイプまたはフレーミングタイプの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の中に定義されたオプションの遵守を強制する必要がある場合は、それは、このように、それはこのAVPをサポートしていない場合、セッションを中止するピアを強制的に1にMビットを設定してもよいです。これらの拡張なく動作の結果は完全に受け入れられないことが知られていない限りこれは推奨されません。
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.
タイプ49属性、オプションAVPを許可するLCP、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ビットは、そうでなければ、それがなければならず、このAVPの送信者はこのL2TP拡張子を理解していないピアへの接続を確立することを望まない場合、それは1にMビットをセットすべきである0または1に設定することができます0に設定します。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
このAVPのLength（隠れることの前の）は6プラスLCP設定要求の長さです。
The AVP SHOULD be present in the following messages: ICCN, OCCN
ICCN、OCCN：AVPは以下のメッセージ中に存在すべきです
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値は（はるかに[RFC2661]でプロキシLCP AVP等）PPP LCP設定-REQパケットの情報フィールドと同一です。これは、LNSにLACから送信され、LNSでPPPのLCP交渉を導くことを意図しています。いくつかのケースでは、それぞれの個々のPPP LCPオプションが所望の値（例えば、MRU）このAVPマップで運ばれ、場合によっては、有効にすることが望まれる特定のオプション（例えば、ACFC）にマップ。その初期設定要求を構築する際に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.
MRU LACは、LNSは、この値でLCPネゴシエーションの最大値を開始する必要があります提供します。必要であればしかし、それはMRUを減らすことができます。
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)
PFC LACは、それが、この値は、リンクの種類と希望する場合PFC LNSは、リンクタイプのネゴシエーションにLCPを開始する必要があります提供します。 （例えばAHDLC）
ACFC LAC provides ACCOMP LNS SHOULD begin LCP if it is desired on negotiation with this the link type value. (e.g. AHDLC)
ACFC LACは、それがこのリンク型の値との交渉で要求される場合ACCOMP LNSは、LCPを開始する必要があります提供します。 （例えば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.
FCS-ALT LACは、必要なLNSは、このタイプの値とのリンクネゴシエーションの値を始める必要があることを示します。この値は、FCSがLACでストリッピングされたとして、しかし、いくつかのPPPのメディアタイプは、このオプションを必要とLNSに全く重要であることに注意してください。
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ビットは、そうでなければ、それがなければならず、このAVPの送信者はこのL2TP拡張子を理解していないピアへの接続を確立することを望まない場合、それは1にMビットをセットすべきである0または1に設定することができます0に設定します。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
このAVPのLength（隠れることの前の）は6プラスLCP設定要求の長さです。
The AVP MAY be present in the following messages: ICCN, OCCN
ICCN、OCCN：AVPは、以下のメッセージに存在しているかもしれませ
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設定肯定応答値（はるかに[RFC2661]でプロキシLCP AVP等）PPP LCP設定-REQパケットの情報フィールドと同一です。これは、LNSにLACから送信され、LNSでPPPのLCP交渉を導くことを意図しています。他では、LAC（例えば、ACFC）によって許可されたオプションにマッピングしながらいくつかのケースでは、それぞれの個々のPPP LCPオプションは、最大値（例えば、MRU）このAVPマップで行います。オプションはここに含まれていない場合は、LACは、リンク層で、その特定のオプションを実行する（したがって、そのオプションを設定して拒否します）どのように理解していないLNSによって仮定することができます。このAVPの情報は、PPP設定肯定応答を構築する場合は、[Configure-拒否し、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.
MRU LACは、要求されたようにLNS還元最大値MRUを受け入れることができる提供します。
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は、マスクLNSは、ここで定義されたビット（複数可）を受け入れることがあります。 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).
FCS-ALT LACは、リンクのため、このオプションの値は、FCSがLACでストリッピングされたとしてLNSを入力するために全く重要であり、有効な交渉を示しています。しかし、LNSは、（複数の値が存在していてもよい）ここに記載されたFCS-ALT型を受け入れる必要があります。
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:
LACにLNSからネゴシエートLCPパラメータを通信するために、[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は、プロキシLCPネゴシエーションをサポートするためのLNSにLACから送信されます。 LACにLNSから交渉さLCPパラメータを報告するためには、正確に同じ形式の二つのメッセージが定義されています。
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.
LCPのネゴシエーションがLNSによって完成された場合は、Set-リンク情報制御メッセージは、内に含まれるこれらのAVPを送らなければなりません。これらの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メッセージで古い属性値を使用するよりも、新しいAVP属性タイプは、何らかの既存のL2TPの実装は、既知の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最終LCP CONFREQ 52、セクション2.3、LNS最後に受信したLCP CONFREQを送信しました
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、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.マークTownsleyシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709
EMail: mark@townsley.net
メールアドレス：mark@townsley.net
Bill Palter EMail: palter.ietf@zev.net
ビルPalter Eメール：palter.ietf@zev.net
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。