RFC3437 日本語訳
3437 Layer-Two Tunneling Protocol Extensions for PPP Link ControlProtocol Negotiation. W. Palter, W. Townsley. December 2002. (Format: TXT=20820 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Palter Request for Comments: 3437 zev.net Category: Standards Track W. Townsley Cisco Systems December 2002
作業部会W.をネットワークでつないでください。コメントを求める要求をあしらってください: 3437zev.net Category: 標準化過程W.Townsleyシスコシステムズ2002年12月
Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
pppリンク制御議定書交渉のための層-2つのトンネリングプロトコル拡大
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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはPointプロトコル(PPP)オプションへのリンク特有のPointの高められたサポートのためにLayer Two Tunnelingプロトコル(L2TP)と拡大を定義します。 PPP終点は、通常、それらを接続する一般的な物理的なメディアにダイレクトに近づく手段を持って、その結果、メディアに関する使用中の知識を詳しく述べました。 L2TPが使用されているとき、2人のPPP同輩はもう直接同じ物理的なメディアの上に接続されません。 代わりに、L2TPはIPなどのパケット交換網の上でトンネリングPPPフレームのそばでPPP接続のいくつかかすべて上に仮想接続を挿入します。 いくつかの条件のもとでは、L2TP終点は、LCP交渉への適切な参加のためにメディア必要情報のすべてに近づく手段を持っていないかもしれない位置でPPP Link Controlプロトコル(LCP)オプションを交渉する必要があるかもしれません。 このドキュメントはPPP LCP交渉の前にL2TP終点の間でL2TPトンネルの遠端で必要なLCPオプションを伝えるのにメカニズムを提供します、交渉されたLCPオプションに伝え返すためのネイティブのPPPリンクが住んでいるメカニズムと同様に。
Palter & Townsley Standards Track [Page 1] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[1ページ]。
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
1. 序論… 2 1.1 要件の仕様… 3 2. ラックからLNSまでのLCPオプション… 3 2.1LCP Want Options(iccn、occn)… 4 2.2LCP Allow Options(iccn、occn)… 6 2.3 LNSからラックまでのLCPオプション… 7 3. セキュリティ問題… 8 4. IANA問題… 8 5. 標準の参照… 8 6. 作者のアドレス… 9 7. 完全な著作権宣言文… 10
1. Introduction
1. 序論
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セッションがLACに到着したどんなタイプのインタフェースに関して非常に限られた量の指導を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に知らせるのが限界のときにLNSにオプションを交渉して、指導を供給するより強健な方法とLACがLCP交渉の間に必要とする値を定義します。 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 Proxy LCPはネイティブのPPPリンクが住んでいるところで交渉されるために選択を許します、その結果、回避がACCM、Alternate FCS、および他のLCP Optionsと共にLNSが必ずネイティブのPPP接続、インターフェース型、または構成のために物理的なメディアへのアクセスなしで適切に交渉する方法を知っているというわけではないのを発行します。 しかしながら、Proxy LCPの使用はまた、LNSによって設定されるはずであるか、または調整されるはずであるLCP PPP交渉の中にオプションがあるPPP Authentication TypeやMRUなどの他の問題を紹介します。 最終的にPPP Clientは意識するかもしれません。いずれでのreinitiate 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)を知っているか、または明確に扱う必要があるかもしれない方法、LAC(例えば、AUTH-TYPE)にほとんどわかりやすい(2)オプション、および(3)オプションでそれを縁どるどの感情をゆだねるか。
Palter & Townsley Standards Track [Page 2] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[2ページ]。
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情報を伝えるのを許容するために新しいAVPsを定義します。 Proxy LCP AVPsが[RFC2661]にあるとき、同様に、LCPオプション情報は構造化されます。 これはL2TP AVPの中で本質的にはPPP LCP Configure-要求かConfigure-Ackパケットのカプセル化にかかわります。
1.1 Specification of Requirements
1.1 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. LCP Options From LAC to LNS
2. ラックからLNSまでのLCPオプション
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メッセージの中で以下のAVPsを利用するかもしれません。 これらのAVPsがLNSによって支持されるなら、彼らはBearer Typeによって含意されたLCPオプションかFraming Type AVPsのためにどんな提案もくつがえすべきです。
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.
これらのAVPsはベースL2TP仕様に基づき定義されるProxy LCPとProxy Authentication AVPs(プロキシAVPs)に共存するかもしれません。 Proxy AVPsが受け取られているなら、LNSは、本書では定義されたAVPsによって勧められるオプションにこれらのパラメタを受け入れるか、またはLCPを再交渉するのを選ぶかもしれません。 LACがLNSによるLCPの交渉を強制したいなら、それは呼び出し初期化の間、単にすべてのProxy AVPsを省略するべきです。
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.
デフォルトで、本書では定義されたAVPsは義務的ではありません(Mビットはゼロに設定されます)。 しかしながら、実現が、強くAVPsの中で定義されたオプションに支持を強要する必要があるなら、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.
セクションのAVPsであるなら2.1と2.2をLNSに送ります、LAC MUST。セクション2.3で定義されるようにAVPsを受け入れるように用意してください。
Palter & Townsley Standards Track [Page 3] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[3ページ]。
2.1 LCP Want Options (iccn, occn)
2.1 LCPはオプションが欲しいです。(iccn、occn)
The LCP Allow Options AVP, Attribute Type 49, contains a list of options that the LAC wants to be negotiated by the LNS.
LCP Allow Options AVP(Attribute Type49)は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) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| LCP、Reqを構成します… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... LCP、Reqを構成します(継続的な)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
Vendor IDは0のIETF Vendor IDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVP MAY、隠されてください(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拡張子を理解していない同輩に取引関係を築きたがっていません、それ。SHOULDは1まで噛み付かれたMを設定します。さもなければ、0にそれを設定しなければなりません。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
このAVPのLength(隠れることの前の)はLCP Configure Requestの6と長さです。
The AVP SHOULD be present in the following messages: ICCN, OCCN
AVP SHOULD、以下のメッセージに存在してください: 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 Configure-Req ValueはPPP LCP Configure-Req Packet([RFC2661]のProxy LCP AVPのような)の情報フィールドと同じです。 それは、LACからLNSに送られて、LNSでPPP LCP交渉を案内することを意図します。 いくつかの場合、このAVPで運ばれたそれぞれの個々のPPP LCPオプションは可能にされることが望まれている特定のオプション(例えば、ACFC)への地図を目標値(例えば、MRU)といくつかの場合それに写像します。 初期のConfigure-要求を組み込むとき、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オプションの徹底的な表現であることを意図しません。
Palter & Townsley Standards Track [Page 4] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[4ページ]。
LCP Want Option LAC Action LNS Action
LCPはオプションラック動作LNS動作が欲しいです。
MRU LAC provides a LNS SHOULD begin LCP negotiation maximum value with this value. However, it MAY reduce MRU if necessary.
MRU LACはこの値と共にLCP交渉最大値をLNS SHOULDを始まらせるaに提供します。 しかしながら、必要なら、それはMRUを減少させるかもしれません。
ACCM LAC Provides a mask LNS SHOULD begin LCP negotiation with this value. LNS may add bit(s) while negotiating.
ACCM LAC Provides aマスクLNS SHOULDはこの値との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 SHOULDはリンク型交渉のときに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 SHOULDは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 SHOULDがこのタイプ値とのリンク交渉のために値を始めるのを示します。 しかしながら、この値がLACでFCSを剥取るようにLNSへの結果の全くものでなく、何人かのPPPメディアタイプがこのオプションを必要とすることに注意してください。
Palter & Townsley Standards Track [Page 5] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[5ページ]。
2.2 LCP Allow Options (iccn, occn)
2.2 LCPは選択を許します。(iccn、occn)
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 Allow Options AVP、Attribute Type50は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) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| LCP、Ackを構成します… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... LCP、Ackを構成します(継続的な)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
Vendor IDは0のIETF Vendor IDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVP MAY、隠されてください(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拡張子を理解していない同輩に取引関係を築きたがっていません、それ。SHOULDは1まで噛み付かれたMを設定します。さもなければ、0にそれを設定しなければなりません。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
このAVPのLength(隠れることの前の)はLCP Configure Requestの6と長さです。
The AVP MAY be present in the following messages: ICCN, OCCN
AVP MAY、以下のメッセージに存在してください: 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 Configure-Ack ValueはPPP LCP Configure-Req Packet([RFC2661]のProxy LCP AVPのような)の情報フィールドと同じです。 それは、LACからLNSに送られて、LNSでPPP LCP交渉を案内することを意図します。 いくつかの場合、このAVPで運ばれたそれぞれの個々のPPP LCPオプションは(例えば、MRU)を最大値に写像します、それはそれがオプションに写像する他のものでLAC(例えば、ACFC)によって可能にされますが。 オプションがここに含まれていないなら、LNSは、LACがリンクレイヤ(そして、その結果、そのオプションをConfigure拒絶する)でその特定のオプションを実行する方法を理解していないと思うことができます。 PPP Configure-Ack、Configure-廃棄物、およびConfigure-Nakにメッセージを築き上げるとき、このAVPの情報は利用されるべきです。
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オプションの徹底的な表現であることを意図しません。
Palter & Townsley Standards Track [Page 6] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[6ページ]。
LCP Allow Option LAC Action LNS Action
LCPはオプションラック動作LNS動作を許容します。
MRU LAC provides a LNS may accept reduction maximum value MRU as requested.
MRU LACは要求された通りLNSが受け入れるかもしれないaに減少最大値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.
マスクLNSが受け入れるかもしれないACCM LAC Providesはここで定義された(s)に噛み付きました。 ACCMがなくなるならそれがリンク型に適切でないと思われることに注意してください。
PFC LAC provides PFC LNS may accept PFC. if it is allowed on the link type (e.g. AHDLC)
PFC LNSはPFCを受け入れるかもしれません。PFC LACが提供する、それがリンクの上に許容されているなら、タイプしてください。(例えば、AHDLC)
ACFC LAC provides ACFC LNS may accept ACFC. if it is allowed on the link type (e.g. AHDLC)
ACFC LNSはACFCを受け入れるかもしれません。ACFC LACが提供する、それがリンクの上に許容されているなら、タイプしてください。(例えば、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は、これがリンクへの値をゆだねる有効なNegotiationがLACでFCSを剥取るときLNSをタイプするためには結果の全くものでないことを示します。 しかしながら、LNS SHOULDはここに記載されたFCS-ALTタイプを受け入れるだけです(1つ以上の値が存在しているかもしれません)。
2.3 LCP Options From LNS to LAC
2.3 LNSからラックまでのLCPオプション
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:
交信するために、LNSからLACまでの交渉された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:
Proxy LCP交渉を支持するためにこれらのAVPsを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)
Palter & Townsley Standards Track [Page 7] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[7ページ]。
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交渉を終了するとき、これらのAVPsと共に中に含まれた状態でSetリンクインフォメーションコントロールメッセージを送らなければなりません。 これらのAVPsは最後に送って最後の容認された(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 Messageで単に古いAttribute値を使用するよりむしろ、新しいAVP Attributeタイプはいくつかの既存のL2TP実現が知られているAVPの置き間違いのようにタイプを思えて、誤ったエラー条件を発生させることができたことがないかどうかチェックするかもしれないという事実のためこれらのメッセージのために定義されます。
3. Security Considerations
3. セキュリティ問題
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 AVPsを定義します。 これらの値が詮索されたなら、凶暴な個人は与えられたネットワークかトポロジーに関する詳しい情報に近づく手段を持っているかもしれません。 これらの同じ値がPPP LCPパケットのトンネルを堀られたリンクの上にとにかく交渉されるかもしれなくて、これが今日潜在的に伝えられるよりそれ以上の情報でないなら、それはまさしく異なったフォームにあります。
4. IANA Considerations
4. IANA問題
This document requires four new L2TP "AVP Attribute" numbers to be assigned by IANA.
このドキュメントは、4つの新しいL2TP「AVP属性」番号がIANAによって割り当てられるのを必要とします。
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 Confreq52、セクション2.3に送って、LNS最終容認されたLCP Confreq
5. Normative References
5. 引用規格
[RFC 2119] 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月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、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.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらわれます、「層Twoはプロトコル(L2TP)にトンネルを堀りながら、層Twoにトンネルを堀っ」て、RFC2661、1999年8月。
Palter & Townsley Standards Track [Page 8] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[8ページ]。
6. Author's Addresses
6. 作者のアドレス
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
7025年のW.マークTownsleyシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC 27709
EMail: mark@townsley.net
メール: mark@townsley.net
Bill Palter EMail: palter.ietf@zev.net
ビルはメールをあしらいます: palter.ietf@zev.net
Palter & Townsley Standards Track [Page 9] RFC 3437 L2TP Extensions for PPP LCP Negotiation December 2002
あしらってください。そうすれば、Townsley規格は交渉2002年12月にppp LCPのためにRFC3437L2TP拡張子を追跡します[9ページ]。
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Palter & Townsley Standards Track [Page 10]
あしらってください。そうすれば、Townsley規格は追跡されます。[10ページ]
一覧
スポンサーリンク