[要約] RFC 3772は、PPPベンダープロトコルに関する仕様であり、PPPの拡張機能を提供するために作成されました。このRFCの目的は、PPPの機能を拡張し、ベンダー固有のプロトコルをサポートすることです。
Network Working Group J. Carlson
Request for Comments: 3772 Sun Microsystems
Category: Standards Track R. Winslow
L-3 Communications
May 2004
Point-to-Point Protocol (PPP) Vendor Protocol
ポイントツーポイントプロトコル（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 (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols.
ポイントツーポイントプロトコル（PPP）は、リンク制御プロトコル（LCP）と、ポイントツーポイントリンク上のマルチプロトコルトラフィックの使用を交渉する方法を定義します。PPPベンダー拡張ドキュメントには、ベンダー固有の汎用構成オプションとコード番号が追加されます。このドキュメントは、これらの機能を拡張して、ベンダー固有のネットワーク、認証、および制御プロトコルをカバーしています。
PPP's [1] Vendor Extensions [3] defines a general-purpose mechanism for the negotiation of various vendor-proprietary options and extensions to the kinds of control messages that may be sent via the Code field.
PPPの[1]ベンダー拡張[3]は、コードフィールドを介して送信される可能性のある種類の制御メッセージに対するさまざまなベンダーと専門的オプションと拡張の交渉のための汎用メカニズムを定義します。
Some implementors may want to define proprietary network and control protocols in addition to the already-described features. While it would be possible for such an implementor to use the existing LCP Vendor-Specific Option to enable the use of the proprietary protocol, this staged negotiation (enable via LCP, then negotiate via some locally-assigned protocol number) suffers from at least three problems: First, because it would be in LCP, the negotiation of the use of the protocol would begin before identification and authentication of the peer had been done. This complicates the security analysis of the feature and constrains the way in which the protocol might be deployed.
一部の実装者は、すでに説明されている機能に加えて、独自のネットワークおよび制御プロトコルを定義したい場合があります。このような実装者が既存のLCPベンダー固有のオプションを使用して独自のプロトコルの使用を有効にすることは可能ですが、この段階的な交渉（LCPを介して有効になり、地元で割り当てられたプロトコル番号を介して交渉する）は少なくとも3つの苦しみです。問題：まず、LCPであるため、プロトコルの使用の交渉は、ピアの識別と認証が行われる前に開始されます。これにより、機能のセキュリティ分析が複雑になり、プロトコルの展開方法が制約されます。
Second, where compulsory tunneling is in use, the system performing the initial LCP negotiation may be unrelated to the system that uses the proprietary protocol. In such a scenario, enabling the protocol at LCP time would require either LCP renegotiation or support of the proprietary protocol in the initial negotiator, both of which raise deployment problems.
第二に、強制トンネリングが使用されている場合、最初のLCPネゴシエーションを実行するシステムは、独自のプロトコルを使用するシステムとは無関係である可能性があります。このようなシナリオでは、LCP時間にプロトコルを有効にするには、LCP再交渉または初期交渉者の独自プロトコルのサポートのいずれかが必要であり、どちらも展開の問題を引き起こします。
Third, the fact that any protocol negotiated via such a mechanism would necessarily use a protocol number that is not assigned by IANA complicates matters for diagnostic tools used to monitor the datastream. Having a fixed number allows these tools to display such protocols in a reasonable, albeit limited, format.
第三に、このようなメカニズムを介してプロトコルが交渉されたという事実は、IANAによって割り当てられないプロトコル番号を必然的に使用するという事実は、データストリームの監視に使用される診断ツールの問題を複雑にします。固定番号を持つことにより、これらのツールは、制限されていますが、形式の合理的なプロトコルを表示できます。
A cleaner solution is thus to define a set of vendor-specific protocols, one in each of the four protocol number ranges defined by [1]. This specification reserves the following values:
したがって、よりクリーンなソリューションは、[1]で定義された4つのプロトコル番号範囲のそれぞれの1つであるベンダー固有のプロトコルのセットを定義することです。この仕様は、次の値を留保します。
Value (in hex) Protocol Name
005b Vendor-Specific Network Protocol (VSNP)
405b Vendor-Specific Protocol (VSP)
805b Vendor-Specific Network Control Protocol (VSNCP)
c05b Vendor-Specific Authentication Protocol (VSAP)
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 BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
The Vendor-Specific Network Control Protocol (VSNCP) is responsible for negotiating the use of the Vendor-Specific Network Protocol (VSNP). VSNCP uses the same packet exchange and option negotiation mechanism as LCP, but with a different set of options.
ベンダー固有のネットワーク制御プロトコル（VSNCP）は、ベンダー固有のネットワークプロトコル（VSNP）の使用を交渉する責任があります。VSNCPは、LCPと同じパケット交換とオプションネゴシエーションメカニズムを使用しますが、オプションのセットが異なります。
VSNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. Any VSNCP packets received when not in that phase MUST be silently ignored. If a VSNCP packet with an unrecognized OUI is received, an LCP Protocol-Reject SHOULD be sent in response.
VSNCPパケットは、PPPがネットワーク層プロトコルフェーズに達するまで交換してはなりません。そのフェーズにない場合に受信したVSNCPパケットは、静かに無視する必要があります。認識されていないOUIを備えたVSNCPパケットが受信される場合、それに応じてLCPプロトコルリジェクトを送信する必要があります。
The network layer data, carried in VSNP packets, MUST NOT be sent unless VSNCP is in Opened state. If a VSNP packet is received when VSNCP is not in Opened state and LCP is Opened, the implementation MAY respond using LCP Protocol-Reject.
VSNPパケットに携帯されるネットワークレイヤーデータは、VSNCPが開いた状態でない限り、送信しないでください。VSNCPが開かれた状態ではなく、LCPが開かれている場合にVSNPパケットが受信された場合、LCPプロトコル - リジェクトを使用して実装が応答する場合があります。
Exactly one VSNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805b (VSNCP). A summary of the VSNCP packet format is shown below. The fields are transmitted from left to right.
PPPプロトコルフィールドがHEX 805B（VSNCP）に設定されているPPP情報フィールドには、正確に1つのVSNCPパケットが配信されます。VSNCPパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
Only LCP Code values 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. All other codes SHOULD result in a VSNCP Code-Reject reply.
LCPコード値1〜7（configure-request、configure-c、configure-nak、configure-reject、terminate-request、terminate-cack、code-reject）のみが使用されます。他のすべてのコードは、VSNCPコードリジェクト応答をもたらす必要があります。
Identifier and Length
識別子と長さ
These are as documented for LCP.
これらはLCPの文書化とされています。
OUI
oui
This three-octet field contains the vendor's Organizationally Unique Identifier. The bits within the octet are in canonical order, and the most significant octet is transmitted first. See Section 5 below for more information on OUI values.
この3オクセットフィールドには、ベンダーの組織的にユニークな識別子が含まれています。オクテット内のビットは標準的な順序であり、最も重要なオクテットが最初に送信されます。OUI値の詳細については、以下のセクション5を参照してください。
Data
データ
This field contains data in the same format as for the corresponding LCP Code numbers.
このフィールドには、対応するLCPコード番号と同じ形式のデータが含まれています。
When VSNCP is in Opened state, VSNP packets may be sent by setting the PPP Protocol field to hex 005b (VSNP) and placing the vendor-specific data in the PPP Information field. No restrictions are placed on this data.
VSNCPがオープン状態にある場合、VSNPパケットは、PPPプロトコルフィールドをHEX 005B（VSNP）に設定し、ベンダー固有のデータをPPP情報フィールドに配置することにより送信できます。このデータに制限はありません。
The Vendor-Specific Protocol (VSP) is intended for use in situations where the implementation of a complete Network Layer Protocol is unnecessary, or where per-link signaling is required (see Section 7 below).
ベンダー固有のプロトコル（VSP）は、完全なネットワークレイヤープロトコルの実装が不要な状況、またはリンクごとのシグナリングが必要な状況で使用することを目的としています（以下のセクション7を参照）。
VSP packets MUST NOT be sent until PPP has reached either Network-Layer Protocol or Authentication phase. VSP packets received before those phases MUST be silently ignored. Once the proper phase has been reached, a VSP packet containing an unrecognized OUI value SHOULD be returned using LCP Protocol-Reject.
VSPパケットは、PPPがネットワーク層プロトコルまたは認証フェーズのいずれかに達するまで送信してはなりません。これらのフェーズの前に受け取ったVSPパケットは、静かに無視する必要があります。適切な位相に達したら、LCPプロトコルrejectを使用して、認識されていないOUI値を含むVSPパケットを返す必要があります。
Exactly one VSP packet is carried in the PPP Information field, with the PPP Protocol field set to 405b (VSP). A summary of the VSP packet format is shown below. The fields are transmitted from left to right.
PPPプロトコルフィールドが405B（VSP）に設定されたPPP情報フィールドには、正確に1つのVSPパケットが配信されます。VSPパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+
Magic-Number
マジック番号
The four-octet Magic-Number field is used to detect looped-back links. If the Magic-Number Option was not negotiated by LCP, then this field MUST be set to 0. Implementation of the LCP Magic-Number Option is RECOMMENDED.
4オクテットのマジック番号フィールドは、ループバックリンクを検出するために使用されます。Magic-NumberオプションがLCPによって交渉されなかった場合、このフィールドは0に設定する必要があります。LCPマジック番号オプションの実装が推奨されます。
OUI
oui
This three-octet field contains the vendor's Organizationally Unique Identifier. The bits within the octet are in canonical order, and the most significant octet is transmitted first. See Section 5 below for more information on OUI values.
この3オクセットフィールドには、ベンダーの組織的にユニークな識別子が含まれています。オクテット内のビットは標準的な順序であり、最も重要なオクテットが最初に送信されます。OUI値の詳細については、以下のセクション5を参照してください。
Reserved
予約済み
Reserved for future definition. Must be zero on transmit and ignored on reception.
将来の定義のために予約されています。送信中はゼロである必要があり、レセプションで無視する必要があります。
Data
データ
Vendor-specific data.
ベンダー固有のデータ。
The Vendor-Specific Authentication Protocol (VSAP) is used in two ways. First, it is used with the LCP Authentication Option in order to negotiate the use of a vendor-specific authentication protocol to be used during the PPP Authentication phase. Second, it is used in the PPP Protocol field to carry those proprietary authentication messages during the PPP Authentication phase.
ベンダー固有の認証プロトコル（VSAP）は、2つの方法で使用されます。まず、PPP認証フェーズで使用されるベンダー固有の認証プロトコルの使用を交渉するために、LCP認証オプションで使用されます。第二に、PPP認証フェーズ中にこれらの独自の認証メッセージを伝達するためにPPPプロトコルフィールドで使用されます。
This option is used in LCP Configure-Request, -Ack, -Nak, and -Reject messages.
このオプションは、LCP configure -request、-ack、-nak、および-Rejectメッセージで使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
>=7
> = 7
Authentication-Protocol
Authentication-Protocol
The hex value c05b, in Network Byte Order.
ネットワークバイトの順序で、hex値c05b。
OUI
oui
This three-octet field contains the vendor's Organizationally Unique Identifier. The bits within the octet are in canonical order, and the most significant octet is transmitted first. See Section 5 below for more information on OUI values.
この3オクセットフィールドには、ベンダーの組織的にユニークな識別子が含まれています。オクテット内のビットは標準的な順序であり、最も重要なオクテットが最初に送信されます。OUI値の詳細については、以下のセクション5を参照してください。
Data
データ
This optional field contains options or other information specific to the operation of the vendor-specific authentication protocol.
このオプションのフィールドには、ベンダー固有の認証プロトコルの操作に固有のオプションまたはその他の情報が含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
The Identifier and Length fields are as for LCP. The Code and Data fields and the processing of the messages are defined by the vendor-specific protocol.
識別子と長さのフィールドはLCPと同様です。コードフィールドとデータフィールド、およびメッセージの処理は、ベンダー固有のプロトコルによって定義されます。
However, it is RECOMMENDED that vendor-specific protocols use Code 3 for "Success" and Code 4 for "Failure," as with [4] and [5], in order to simplify the design of network monitoring equipment.
ただし、ベンダー固有のプロトコルは、ネットワーク監視装置の設計を簡素化するために、[4]および[5]と同様に、[4]および[5]と同様に「成功」にコード3を使用し、「障害」にコード4を使用することをお勧めします。
The three-octet Organizationally Unique Identifier (OUI) used in the messages described in this document identifies an organization ("vendor") that defines the meaning of the message. This OUI is based on IEEE 802 vendor assignments.
このドキュメントで説明されているメッセージで使用されている3オクテットの組織的に一意の識別子（OUI）は、メッセージの意味を定義する組織（「ベンダー」）を識別します。このOUIは、IEEE 802ベンダーの割り当てに基づいています。
Vendors that desire to use their IEEE 802 OUI for a PPP Vendor Protocol SHOULD also register the assigned OUI with IANA for the benefit of the community.
PPPベンダープロトコルにIEEE 802 OUIを使用したいベンダーは、コミュニティの利益のためにIANAに割り当てられたOUIを登録する必要があります。
A vendor that does not otherwise need an IEEE-assigned OUI can request a PPP-specific OUI from the IANA. This OUI shall be assigned from the CF0000 series. This procedure is defined for vendors that are not able to use IEEE assignments, such as software-only vendors.
それ以外の場合はIEEEが割り当てられたOUIを必要としないベンダーは、IANAからPPP固有のOUIを要求できます。このOUIは、CF0000シリーズから割り当てられます。この手順は、ソフトウェアのみのベンダーなど、IEEE割り当てを使用できないベンダーに対して定義されています。
Vendors are encouraged to define their protocols to allow for future expansion, where necessary. For example, it may be appropriate for a VSNP to include a locally-defined selector field to distinguish among multiple proprietary protocols carried via this mechanism, and appropriate Configuration Options in VSNCP to enable and disable these sub-protocols. Because the requirements of such a selector are known only to the vendor defining such protocols, they are not described further in this document.
ベンダーは、必要に応じて将来の拡張を可能にするために、プロトコルを定義することをお勧めします。たとえば、VSNPがこのメカニズムを介して運ばれる複数の独自のプロトコルを区別するためのローカル定義のセレクターフィールドを含めることが適切な場合があり、VSNCPの適切な構成オプションを有効にしてこれらのサブプロトコルを有効にします。このようなセレクターの要件は、そのようなプロトコルを定義するベンダーにのみ既知であるため、このドキュメントではこれ以上説明されていません。
An implementation MAY also support more than one vendor-specific protocol, distinguished by OUI. In this case, the implementation MUST also treat LCP Protocol-Reject specially by examining the OUI field in the rejected message and disabling only the protocol to which it refers, rather than all use of the vendor-specific protocol number. Note that such an implementation is compatible with a simple implementation that supports only one OUI: that implementation will respond with LCP Protocol-Reject for unrecognized OUIs and otherwise leave the negotiation state unmodified.
実装は、OUIによって区別される複数のベンダー固有のプロトコルをサポートする場合があります。この場合、実装は、拒否されたメッセージのOUIフィールドを調べ、ベンダー固有のプロトコル番号をすべて使用するのではなく、それが参照するプロトコルのみを無効にすることにより、LCPプロトコルrejectを特別に処理する必要があります。このような実装は、1つのOUIのみをサポートする単純な実装と互換性があることに注意してください。実装は、認識されていないOUIのLCPプロトコル除去で応答し、それ以外の場合はネゴシエーション状態を変更しておきます。
An OUI-distinguished mechanism is expected to be used only in the case of cooperating vendors. Vendors are encouraged to use just a single OUI for all protocols defined by that vendor, if possible.
OUIが存在するメカニズムは、協力ベンダーの場合にのみ使用されると予想されます。ベンダーは、可能であれば、そのベンダーによって定義されたすべてのプロトコルに1つのOUIのみを使用することをお勧めします。
The Vendor-Specific Network Protocol (VSNP) is defined to operate at the bundle level if Multilink PPP [6] is in use, and also above any Compression Protocols [7] and Encryption Protocols [8] in use.
ベンダー固有のネットワークプロトコル（VSNP）は、マルチリンクPPP [6]が使用されている場合、および使用中の圧縮プロトコル[7]および暗号化プロトコル[8]を上回る場合、バンドルレベルで動作するように定義されます。
The Vendor-Specific Protocol (VSP) is defined to operate at the per-link level if Multilink PPP is in use, and MUST NOT be subjected to data compression. If a per-link encryption protocol is in use, then VSP packets MUST be encrypted.
ベンダー固有のプロトコル（VSP）は、マルチリンクPPPが使用されている場合、リンクごとのレベルで動作するように定義されており、データ圧縮を受けないでください。リンクごとの暗号化プロトコルが使用されている場合、VSPパケットを暗号化する必要があります。
Note that because VSP is defined at the per-link level, bundle level encryption does not affect VSP.
VSPはリンクごとのレベルで定義されているため、バンドルレベルの暗号化はVSPに影響しないことに注意してください。
The security of any vendor-specific authentication protocol is subject to the provisions of that proprietary mechanism. Implementations that wish to avoid security problems associated with such protocols SHOULD send LCP Configure-Nak in response to an LCP Configure-Request specifying VSAP, or MAY terminate operation.
ベンダー固有の認証プロトコルのセキュリティは、その独自のメカニズムの規定の対象となります。このようなプロトコルに関連するセキュリティの問題を回避したい実装は、VSAPを指定するLCP構成要求に応じてLCP Configure-Nakを送信するか、操作を終了する場合があります。
When operating with PPP encryption, but without Multilink PPP, VSP packets are sent in the clear. Implementations that require PPP encryption as part of a security mechanism should consider whether to employ per-link encryption or forego use of VSP in favor of VSNP.
PPP暗号化で操作する場合、しかしマルチリンクPPPがない場合、VSPパケットはクリアで送信されます。セキュリティメカニズムの一部としてPPP暗号化を必要とする実装では、リンクごとの暗号化を使用するか、VSNPを支持してVSPを使用するかを検討する必要があります。
The security of vendor-specific networking protocols is likewise subject to the security mechanisms defined by those protocols. Independent analysis of the security of any such protocol is RECOMMENDED.
ベンダー固有のネットワークプロトコルのセキュリティは、同様に、これらのプロトコルによって定義されたセキュリティメカニズムの対象となります。このようなプロトコルのセキュリティに関する独立した分析が推奨されます。
IANA has assigned four similarly-numbered PPP Protocol field values, 005b, 405b, 805b, and c05b, as described in Section 1 of this document.
IANAは、このドキュメントのセクション1で説明されているように、4つの同様の番号PPPプロトコルフィールド値005B、405B、805B、およびC05Bを割り当てました。
As described in Section 5 above and in [3], the IANA also maintains a CF0000 series block of non-IEEE OUIs that may be allocated for vendors that do not otherwise need an IEEE-assigned OUI.
上記のセクション5および[3]で説明されているように、IANAは、IEEEが割り当てられたOUIを必要としないベンダーに割り当てられる可能性のある非IEEE OUIのCF0000シリーズブロックも維持しています。
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[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] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[3] シンプソン、W。、「PPPベンダー拡張機能」、RFC 2153、1997年5月。
[4] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[4] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5] Blunk、L。およびJ. Vollbrecht、「PPP拡張可能な認証プロトコル（EAP）」、RFC 2284、1998年3月。
[6] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[6] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（MP）」、RFC 1990、1996年8月。
[7] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[7] Rand、D。、「PPP圧縮制御プロトコル（CCP）」、RFC 1962、1996年6月。
[8] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[8] Meyer、G。、「PPP暗号化制御プロトコル（ECP）」、RFC 1968、1996年6月。
The authors thank Karl Fox and Thomas Narten for their comments and help in preparing this document.
著者は、カール・フォックスとトーマス・ナルテンのコメントとこの文書の準備を手伝ってくれたことに感謝します。
Some of the language and phrasing has been borrowed from RFC 1332, written by Glenn McGregor, and RFC 2153, written by William Allen Simpson.
言語と言い回しの一部は、Glenn McGregorによって書かれたRFC 1332とWilliam Allen Simpsonによって書かれたRFC 2153から借用されています。
Questions about this document should be addressed to the IETF pppext working group or the authors listed below.
このドキュメントに関する質問は、IETF PPPEXTワーキンググループまたは以下にリストされている著者に宛ててください。
James Carlson Sun Microsystems 1 Network Drive MS UBUR02-212 Burlington MA 01803-2757
James Carlson Sun Systems 1ネットワークドライブMS UBUR02-212バーリントンMA 01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Richard Winslow L-3 Communications Systems - East 1 Federal Street A&E-2NE Camden, NJ 08102
リチャードウィンスローL-3通信システム - イースト1フェデラルストリートA＆E-2NEカムデン、ニュージャージー08102
EMail: richard.winslow@l-3com.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。