RFC3772 日本語訳
3772 Point-to-Point Protocol (PPP) Vendor Protocol. J. Carlson, R.Winslow. May 2004. (Format: TXT=19846 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Carlson
Request for Comments: 3772 Sun Microsystems
Category: Standards Track R. Winslow
L-3 Communications
May 2004
コメントを求めるワーキンググループJ.カールソン要求をネットワークでつないでください: 3772年のサン・マイクロシステムズカテゴリ: 標準化過程R.ウィンスローL-3コミュニケーション2004年5月
Point-to-Point Protocol (PPP) Vendor Protocol
二地点間プロトコル(ppp)ベンダープロトコル
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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
Pointからポイントへのプロトコル(PPP)はポイントツーポイント接続の上でLink Controlプロトコル(LCP)とマルチプロトコルトラフィックの使用を交渉するためのメソッドを定義します。 PPP Vendor Extensionsドキュメントはベンダー特有の汎用Configuration OptionとCode番号を加えます。 このドキュメントはベンダーの特定のNetwork、Authentication、およびControlプロトコルを含むこれらの特徴を広げています。
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]のベンダーExtensions[3]は様々なベンダー独占であるオプションと拡大の交渉のためにCode分野を通して送られるかもしれないコントロールメッセージの種類と汎用メカニズムを定義します。
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 Vendor特有のOptionを使用するのが、可能でしょうが、この上演された交渉(LCPを通して可能にして、次に、何らかの局所的に割り当てられたプロトコル番号で交渉する)は少なくとも3つの問題に苦しみます:
Carlson & Winslow Standards Track [Page 1] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[1ページ]。
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.
2番目に、強制的なトンネリングが使用中であるところで初期のLCP交渉を実行するシステムは固有のプロトコルを使用するシステムに関係ないかもしれません。 そのようなシナリオでは、LCP時にプロトコルを可能にするのは初期の交渉者での固有のプロトコルのLCP renegotiationかサポートのどちらかを必要として、どの昇給の両方が展開問題であるか。
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.
3番目に、そのようなメカニズムで交渉されたどんなプロトコルも必ずIANAによって割り当てられないプロトコル番号を使用するだろうという事実はdatastreamをモニターするのに使用される診断用道具のために件を複雑にします。 定数を持っているのに、これらのツールは妥当で、それにしても、限られた形式でそのようなプロトコルを表示できます。
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)
プロトコルのName 005b Vendor特有のNetworkプロトコル(VSNP)の405b Vendor特有のプロトコル(VSP)の805b Vendor特有のNetwork Controlプロトコル(VSNCP)のc05b Vendor特有のAuthenticationプロトコルを評価してください(十六進法で)。(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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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.
Vendor特有のNetwork Controlプロトコル(VSNCP)はVendor特有のNetworkプロトコル(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がNetwork-層のプロトコルフェーズに達するまで、VSNCPパケットを交換してはいけません。 静かにどんなそのフェーズにもないとき受け取られたどんなVSNCPパケットも無視しなければなりません。 認識されていないOUIがあるVSNCPパケットが受け取られているなら、LCPは送られたコネが応答であったならSHOULDをプロトコルで拒絶します。
Carlson & Winslow Standards Track [Page 2] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[2ページ]。
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がOpened状態にない場合、VSNPパケットで運ばれたネットワーク層データを送ってはいけません。 VSNCPがOpened状態にないとき、VSNPパケットが受け取られていて、LCPがOpenedであるなら、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.
ちょうど1つのVSNCPパケットがPPP情報分野で運ばれます、805b(VSNCP)に魔法をかけるように設定された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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Codeだけが1を評価する、7 (要求を構成する、Configure- Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 使用されます。 VSNCP Code-廃棄物の他のすべてのコードSHOULD結果が返答します。
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八重奏の分野はベンダーのOrganizationally Unique Identifierを含んでいます。 八重奏の中のビットが正準なオーダーにあります、そして、最も重要な八重奏は最初に、伝えられます。 OUI値の詳しい情報に関して以下のセクション5を見てください。
Data
データ
This field contains data in the same format as for the
corresponding LCP Code numbers.
この分野は対応するLCP Code番号のように同じ形式におけるデータを含んでいます。
Carlson & Winslow Standards Track [Page 3] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[3ページ]。
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がOpened状態にあるとき、PPPプロトコル分野に005b(VSNP)に魔法をかけるように設定して、ベンダーの特定のデータをPPP情報分野に置くことによって、VSNPパケットを送るかもしれません。 制限は全くこのデータに関して課されません。
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).
Vendor特有のプロトコル(VSP)は完全なNetwork Layerプロトコルの実装が不要であるか、または1リンクあたりのシグナリングが必要である(以下のセクション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がNetwork層のプロトコルかAuthenticationフェーズのどちらかに達するまで、VSPパケットを送ってはいけません。 静かにそれらのフェーズを無視しなければならない前にVSPパケットは受信されました。 適切なフェーズにいったん達すると、返された使用がLCPプロトコル廃棄物であったなら認識されていないOUI値のSHOULDを含む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.
ちょうど1つのVSPパケットがPPPプロトコル分野セットと共にPPP情報分野で405b(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 ...
+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+
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八重奏のマジックナンバーフィールドは、輪にされて逆リンクを検出するのに使用されます。 マジック数のOptionがLCPによって交渉されなかったなら、この分野を0に設定しなければなりません。 LCPのマジック数のOptionの実装はRECOMMENDEDです。
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八重奏の分野はベンダーのOrganizationally Unique Identifierを含んでいます。 八重奏の中のビットが正準なオーダーにあります、そして、最も重要な八重奏は最初に、伝えられます。 OUI値の詳しい情報に関して以下のセクション5を見てください。
Carlson & Winslow Standards Track [Page 4] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[4ページ]。
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.
Vendor特有のAuthenticationプロトコル(VSAP)は2つの方法で使用されます。 まず最初に、それは、PPP Authentication段階の間、使用されるためにベンダー特有の認証プロトコルの使用を交渉するのにLCP Authentication Optionと共に使用されます。 2番目に、それは、PPP Authentication段階の間、それらの独占認証メッセージを伝えるのにPPPプロトコル分野で使用されます。
4.1. VSAP Authentication Option Format
4.1. VSAP認証オプション形式
This option is used in LCP Configure-Request, -Ack, -Nak, and -Reject messages.
このオプションはLCP Configure-要求、-Ack、-Nak、および廃棄物メッセージで使用されます。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
>=7
>=7
Authentication-Protocol
認証プロトコル
The hex value c05b, in Network Byte Order.
Network Byte Orderの十六進法価値のc05b。
Carlson & Winslow Standards Track [Page 5] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[5ページ]。
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八重奏の分野はベンダーのOrganizationally Unique Identifierを含んでいます。 八重奏の中のビットが正準なオーダーにあります、そして、最も重要な八重奏は最初に、伝えられます。 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 ...
+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
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.
IdentifierとLength分野はLCPに似ています。 メッセージのCode、Data分野、および処理はベンダーの特定のプロトコルによって定義されます。
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.
しかしながら、ベンダー独自のプロトコルが「成功」のためのCode3と「失敗」のためのCode4を使用するのは、RECOMMENDEDです、[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.
Organizationally Unique Identifier(OUI)が本書では説明されたメッセージで使用した3八重奏がメッセージの意味を定義する組織(「ベンダー」)を特定します。 このOUIはIEEE802ベンダー課題に基づいています。
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 VendorプロトコルSHOULDにそれらのIEEE802OUIを使用することを望んでいるベンダーは共同体の利益のために割り当てられたOUIをIANAに登録します。
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課題を使用できないベンダーのために定義されます。
Carlson & Winslow Standards Track [Page 6] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[6ページ]。
6. Multiple Vendor-Specific Protocols
6. 複数のベンダー独自のプロトコル
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に適切なConfiguration Optionsを含んでいるのは適切であるかもしれません。 そのようなセレクタの要件がそのようなプロトコルを定義するベンダーだけにおいて知られているので、それらはさらに本書では説明されません。
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によって区別された1つ以上のベンダー独自のプロトコルをサポートするかもしれません。 特に、この場合、また、実装は、拒絶されたメッセージとそれが参照されるプロトコルだけを無効にする際にベンダー独自のプロトコル番号のすべての使用よりむしろOUI分野を調べることによって、LCPプロトコル廃棄物を扱わなければなりません。 そのような実装は1OUIだけをサポートする簡単な実装と互換性があることに注意してください: LCPプロトコル廃棄物で、認識されていないOUIsのために応じます。そうでなければ、その実装は、交渉状態を変更されていないままにするでしょう。
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が顕著なメカニズムが使用されると予想されます。 ベンダーは、すべてのプロトコルのためのまさしく独身の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.
Multilink PPP[6]がCompressionプロトコル[7]と、そして、使用中である使用中のどんなEncryptionプロトコル[8]を超えてもいるなら、Vendor特有のNetworkプロトコル(VSNP)は、バンドルレベルで作動するために定義されます。
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.
Vendor特有のプロトコル(VSP)が作動するために定義される、-、Multilink PPPが使用中であり、データ圧縮にかけられてはいけないなら、レベルをリンクしてください。 1リンク暗号化あたり1つのプロトコルが使用中であるなら、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.
どんなベンダー特有の認証プロトコルのセキュリティもその独占メカニズムに関する条項を受けることがあります。 そのようなプロトコルSHOULDに関連している警備上の問題を避けたがっている実装は、VSAPを指定するLCP Configure-要求に対応してLCP Configure-Nakを送るか、または操作を終えるかもしれません。
Carlson & Winslow Standards Track [Page 7] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[7ページ]。
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暗号化にもかかわらず、Multilink 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.
ベンダー特有のネットワーク・プロトコルのセキュリティは同様にそれらのプロトコルによって定義されたセキュリティー対策を受けることがあります。 どんなそのようなプロトコルのセキュリティの独立している分析も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.
IANAは4の同様に番号付のPPPプロトコルの分野値、005b、405b、805b、およびc05bを割り当てました、このドキュメントのセクション1で説明されるように。
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.
また、[3]の上と、そして、[3]でセクション5で説明されるように、IANAはそうでなければIEEEによって割り当てられたOUIを必要としないベンダーのために割り当てられるかもしれない非IEEE OUIsの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)」、STD51、RFC1661、7月1994日
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[3] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
w.[3] シンプソン、「pppベンダー拡大」(RFC2153)は1997がそうするかもしれません。
[4] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[4] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[5]BlunkとL.と1998年のJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[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)について議定書の中で述べます」、RFC1990、1996年8月。
[7] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[7]底ならし革。
[8] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
1968, June 1996.
[8] マイヤー、G.、「ppp暗号化制御プロトコル(ECP)」、RFC1968 1996年6月。
Carlson & Winslow Standards Track [Page 8] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[8ページ]。
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.
グレン・マクレガーによって書かれたRFC1332、およびウィリアム・アレン・シンプソンによって書かれたRFC2153から言語と言い回しのいくつかを借りました。
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
ジェームスカールソンサン・マイクロシステムズ1ネットワークDriveさんのUBUR02-212Burlington MA01803-2757
Phone: +1 781 442 2084 Fax: +1 781 442 1677 EMail: james.d.carlson@sun.com
以下に電話をしてください。 +1 781 442、2084Fax: +1 1677年の781 442メール: james.d.carlson@sun.com
Richard Winslow L-3 Communications Systems - East 1 Federal Street A&E-2NE Camden, NJ 08102
リチャードウィンスローL-3通信網--1つのEast Federal通りAとE-2NEカムデン、ニュージャージー 08102
EMail: richard.winslow@l-3com.com
メール: richard.winslow@l-3com.com
Carlson & Winslow Standards Track [Page 9] RFC 3772 PPP Vendor Protocol May 2004
カールソンとウィンスローStandardsはpppベンダープロトコル2004年5月にRFC3772を追跡します[9ページ]。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Carlson & Winslow Standards Track [Page 10]
カールソンとウィンスロー標準化過程[10ページ]
一覧
スポンサーリンク
