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
        

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)インターネット協会(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ベンダー拡張機能のドキュメントは、ベンダー固有の汎用構成オプションとコード番号を追加します。この文書では、ベンダー固有のネットワーク、認証、および制御プロトコルをカバーするために、これらの機能を拡張します。

1. Introduction
1. はじめに

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:

いくつかの実装は、既に説明した機能に加えて、独自のネットワークと制御プロトコルを定義することもできます。そのような実装は、独自のプロトコルの使用を可能にするために、既存のLCPベンダー固有のオプションを使用することが可能であろうが、これは交渉を(いくつかのローカルに割り当てられたプロトコル番号を介して交渉次いで、LCPを介してイネーブル)少なくとも三つを患っステージング問題:

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になりますので、ピアの識別認証が行われていた前に、まず、プロトコルの使用の交渉が始まるでしょう。これは、機能のセキュリティ分析を複雑にし、プロトコルが展開される可能性のある方法を制約します。

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)

プロトコル名005Bベンダー固有のネットワークプロトコル(VSNP)405Bベンダー固有のプロトコル(VSP)805Bベンダー特有ネットワークコントロールプロトコル(VSNCP)c05bベンダー固有の認証プロトコル(VSAP)(16進数)の値

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。

2. PPP Vendor-Specific Network Control Protocol (VSNCP)
2. PPPベンダー固有のネットワーク制御プロトコル(VSNCP)

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.

PPPはネットワーク層プロトコルフェーズに達するまでVSNCPパケットが交換されてはなりません。ないその段階で静かに無視されなければならないとき、どれ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.

VSNCPが開状態にある場合を除きVSNPパケットで運ばれたネットワーク層データは、送信されてはいけません。 VSNCPがオープン状態でない場合VSNPパケットが受信され、LCPが開いている場合、実装はLCPプロトコルを拒否使用して応答することができます。

2.1. VSNCP Packet Format
2.1. VSNCPパケットフォーマット

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.

正確に一つVSNCPパケットが六角805B(VSNCP)に設定PPP Protocolフィールドで、PPP情報フィールドで運ばれます。 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コード7を介して1値(設定要求、設定肯定応答、通信設定否定応答、構成拒否、終了要求を終了-ACKを、そしてコード拒否)が使用されます。他のすべてのコードはVSNCPコード拒否応答を生じるはずです。

Identifier and Length

識別子と長さ

These are as documented for LCP.

LCPのために文書化されているようにこれらは。

OUI

YES

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コード番号と同じ形式でデータが含まれています。

2.2. VSNP Packet Format
2.2. VSNPパケットフォーマット

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パケットは六角005B(VSNP)にPPPプロトコルフィールドを設定し、PPP情報フィールド内のベンダ固有のデータを配置することによって送信されても​​よいです。何の制限は、このデータに配置されていません。

3. PPP Vendor-Specific Protocol (VSP)
3. PPPベンダー固有プロトコル(VSP)

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.

PPPはネットワーク層プロトコルや認証フェーズのいずれかに達するまでVSPパケットを送ってはいけません。これらの相は黙って無視されなければならない前に、VSPパケットを受信しました。適切な位相に達すると、認識されていないOUI値を含むVSPパケットは、LCPプロトコル拒否を使用して返されるべきです。

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.

正確に一つのVSPパケットが405B(VSP)に設定PPP Protocolフィールドで、PPP情報フィールドで運ばれます。 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オクテットマジックナンバーフィールドは、ループバックリンクを検出するために使用されます。マジックナンバーオプションはLCPによって交渉されなかった場合、このフィールドはLCPマジックナンバーオプションの0実装に設定しなければならないことをお勧めします。

OUI

YES

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.

ベンダー固有のデータ。

4. PPP Vendor-Specific Authentication Protocol (VSAP)
4. PPPベンダー固有の認証プロトコル(VSAP)

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 Protocolフィールドで使用されています。

4.1. VSAP Authentication Option Format
4.1. VSAP認証オプションのフォーマット

This option is used in LCP Configure-Request, -Ack, -Nak, and -Reject messages.

このオプションは、LCP設定要求、-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

Length

長さ

>=7

>=7

Authentication-Protocol

認証プロトコル

The hex value c05b, in Network Byte Order.

ネットワークバイト順での16進値c05b、。

OUI

YES

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.

このオプションフィールドは、ベンダー固有の認証プロトコルの動作に固有のオプションまたは他の情報を含んでいます。

4.2. VSAP Authentication Data Format
4.2. VSAP認証データフォーマット
    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.

識別子とLengthフィールドは、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のコード3を使用することが推奨される[4]、[5]、ネットワーク監視装置の設計を単純化するためです。

5. Organizationally Unique Identifiers
5.組織固有識別子

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.

この文書に記載されたメッセージに使用される三オクテット組織固有識別子(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割り当てを、使用することができないベンダーのために定義されています。

6. Multiple Vendor-Specific Protocols
前記複数のベンダー固有のプロトコル

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.

ベンダーは、必要に応じて、将来の拡張を可能にするために彼らのプロトコルを定義することをお勧めします。例えば、これらのサブプロトコルを有効または無効にするには、このメカニズムを介して行う複数の独自プロトコル、およびVSNCPに適切な設定オプションを区別するために、ローカルに定義されたセレクタ・フィールドを含むようにVSNPに適切であり得ます。そのような選択の要件がそのようなプロトコルを定義するベンダーにのみ知られているので、それらは、本文書でさらに説明されていません。

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で区別、複数のベンダー固有のプロトコルをサポートすることができます。この場合、実装はまたLCP拒否メッセージでOUIフィールドを調べ、むしろベンダー固有のプロトコル番号のすべての使用よりも、それが意味する唯一のプロトコルを無効にすることによって、特別プロトコル拒否扱わなければなりません。このような実装は一つだけOUIをサポートする単純な実装と互換性があることに注意してください:実装はLCPの認識できないのOUIのためのプロトコル拒否し、そうでない場合はそのまま交渉状態のままにして応答すること。

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を使用することをお勧めします。

7. Multilink, Compression, and Encryption Considerations
7.マルチリンク、圧縮、および暗号化の考慮事項

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.

使用されているベンダー固有のマルチリンクPPP [6]使用において、また任意の圧縮プロトコルを超えている場合、ネットワークプロトコル(VSNP)はバンドルレベルで動作するように定義されている[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には影響しないことに注意してください。

8. Security Considerations
8.セキュリティの考慮事項

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.

任意のベンダー固有の認証プロトコルのセキュリティは、その独自の機構の規定の対象となります。そのようなプロトコルに関連するセキュリティ上の問題を避けたい実装はLCP設定要求指定VSAPに応じて、LCP設定否定応答を送るべきか、操作を終了することができます。

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.

ベンダー固有のネットワークプロトコルのセキュリティは、これらのプロトコルによって定義されたセキュリティ・メカニズムにも同様に受けます。どのようなプロトコルのセキュリティの独立した分析をお勧めします。

9. IANA Considerations
9. IANAの考慮事項

IANA has assigned four similarly-numbered PPP Protocol field values, 005b, 405b, 805b, and c05b, as described in Section 1 of this document.

このドキュメントのセクション1で説明したようにIANAは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シリーズブロックを維持します。

10. References
10.参考文献
10.1. Normative References
10.1. 引用規格

[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[1]シンプソン、W.、エド。、 "ポイントツーポイントプロトコル(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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

10.2. Informative References
10.2. 参考文献

[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]ブルンク、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.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル(MP)"、RFC 1990、1996年8月。

[7] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.

[7]ランド、D.、 "PPP圧縮制御プロトコル(CCP)"、RFC 1962、1996年6月。

[8] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.

[8]マイヤー、G.、 "PPP暗号化制御プロトコル(ECP)"、RFC 1968、1996年6月。

11. Acknowledgments
11.謝辞

The authors thank Karl Fox and Thomas Narten for their comments and help in preparing this document.

作者は彼らのコメントのためにカール・フォックスとトーマスNarten氏に感謝し、この文書を作成するには役立ちます。

Some of the language and phrasing has been borrowed from RFC 1332, written by Glenn McGregor, and RFC 2153, written by William Allen Simpson.

言語とフレージングのいくつかは、RFC 1332から借りグレン・マクレガーによって書かれ、RFC 2153、ウィリアムアレンシンプソンによって書かれました。

12. Authors
12.著者

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

ジェームズ・カールソンSun Microsystemsの1ネットワークドライブのMS UBUR02-212バーリントンMA 01803から2757

Phone: +1 781 442 2084 Fax: +1 781 442 1677 EMail: james.d.carlson@sun.com

電話:+1 781 442 2084ファックス:+1 781 442 1677 Eメール: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カムデン、NJ 08102

EMail: richard.winslow@l-3com.com

メールアドレス:richard.winslow@l-3com.com

13. Full Copyright Statement
13.完全な著作権声明

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)インターネット協会(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。