RFC2153 日本語訳
2153 PPP Vendor Extensions. W. Simpson. May 1997. (Format: TXT=10780 bytes) (Updates RFC1661, RFC1962) (Updated by RFC5342) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Simpson Request for Comments: 2153 DayDreamer Updates: RFCs 1661, 1962 May 1997 Category: Informational
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 2153の空想家アップデート: RFCs1661、1962 1997年5月のカテゴリ: 情報
PPP Vendor Extensions
pppベンダー拡大
Status of this Memo
このMemoの状態
This document provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPはデータリンク接続を設立して、構成して、テストするために、広げることができるLink Controlプロトコル(LCP)を定義します。 そして、異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
This document defines a general mechanism for proprietary vendor extensions.
このドキュメントは独占ベンダー拡大のために一般的機構を定義します。
Simpson Informational [Page i]
シンプソンInformationalです。[ページi]
RFC 2153 PPP vendor extensions May 1997
RFC2153PPPベンダー拡大1997年5月
Table of Contents
目次
1. Control Packets ....................................... 1
1.1 Vendor Specific Packet .......................... 1
1. パケットを制御してください… 1 1.1のベンダーの特定のパケット… 1
2. Configuration Options ................................. 3
2.1 Vendor-Specific Option .......................... 3
2. 構成オプション… 3 2.1 ベンダー特有のオプション… 3
3. Organizationally Unique Identifiers ................... 4
3. 組織的でユニークな識別子… 4
SECURITY CONSIDERATIONS ...................................... 5
セキュリティ問題… 5
REFERENCES ................................................... 5
参照… 5
CONTACTS ..................................................... 6
連絡します。 6
Simpson Informational [Page ii]
シンプソンInformationalです。[ページii]
RFC 2153 PPP vendor extensions May 1997
RFC2153PPPベンダー拡大1997年5月
1. Control Packets
1. コントロールパケット
The Packet format and basic facilities are already defined for LCP [1] and related NCPs.
Packet形式と基本施設はLCP[1]と関連するNCPのために既に定義されます。
Up-to-date values of the LCP Code field are specified in the most recent "Assigned Numbers" [2]. This document concerns the following values:
LCP Code分野の最新の値は最新の「規定番号」[2]で指定されます。 このドキュメントは以下の値に関係があります:
0 Vendor Specific
0ベンダー特有です。
1.1. Vendor Specific Packet
1.1. ベンダーの特定のパケット
Description
記述
Some implementors might not need nor want to publish their
proprietary algorithms and attributes. This mechanism is
available to specify these without encumbering the IANA with
proprietary number requests.
何人かの作成者は、必要があって、彼らの独占アルゴリズムと属性を発行したがっていないかもしれません。 このメカニズムは、独占数の要求でIANAを苦しめないでこれらを指定するために利用可能です。
Vendor Specific packets MAY be sent at any time, including before
LCP has reached the Opened state.
何時でも、LCPがOpened状態に達する前の包含でベンダーSpecificパケットを送るかもしれません。
The sender transmits a LCP or NCP packet with the Code field set
to 0 (Vendor Specific), the Identifier field set, the local
Magic-Number (if any) inserted, the OUI and Kind fields set, and
the Value(s) field filled with any desired data, but not exceeding
the default MRU minus twelve.
送付者はどんな必要なデータでも満たされますが、12を引いてデフォルトMRUを超えていない分野が設定して、Value(s)がさばく0(ベンダーSpecific)に設定されたCode分野、Identifier分野セット、挿入された地方のマジック数(もしあれば)、OUI、およびKindと共にLCPかNCPパケットを伝えます。
Receipt of a Vendor Specific packet causes the RXR or RUC event.
The response to the Vendor Specific packet is vender specific.
Vendor Specificパケットの領収書はRXRかRUCイベントを引き起こします。 Vendor Specificパケットへの応答はベンダー特有です。
Receipt of a Code-Reject for the packet SHOULD generate the RXJ+
(permitted) event.
SHOULDがRXJ+(受入れられる)のイベントを生成するパケットのためのCode-廃棄物の領収書。
Rationale:
原理:
This is defined as general feature of all PPP Control Protocols,
to avoid future conflicts in vendor secretly self-assigned Code
numbers.
これは、Code番号が秘かに自己に割り当てられたベンダーでの今後の闘争を避けるためにすべてのPPP Controlプロトコルの一般的な特徴と定義されます。
A summary of the Vendor Specific packet format is shown below. The fields are transmitted from left to right.
Vendor Specificパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
Simpson Informational [Page 1] RFC 2153 PPP vendor extensions May 1997
シンプソンInformational[1ページ]RFC2153PPPベンダー拡大1997年5月
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI | Kind | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value(s) ... +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI| 種類| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… +-+-+-+-+-+-+-+-+
Code
コード
0 for Vendor Specific
0 ベンダー詳細のために
Identifier
識別子
The Identifier field MUST be changed for each Vendor Specific
packet sent.
Vendor Specificパケットが送ったそれぞれのためにIdentifier分野を変えなければなりません。
Length
長さ
>= 12
>= 12
When the Length is twelve, no Value(s) field is present.
Lengthが12歳であるときに、どんなValue(s)分野も存在していません。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
that are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number
Configuration Option for further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 マジック数のConfiguration Optionが首尾よく交渉されるまで、ゼロとしてマジック数を伝えなければなりません。 詳細な説明のマジック数のConfiguration Optionを見てください。
OUI
OUI
three octets. The vendor's Organizationally Unique Identifier.
The bits within the octet are in canonical order, and the most
significant octet is transmitted first.
3つの八重奏。 ベンダーのOrganizationally Unique Identifier。 八重奏の中のビットが正準なオーダーにあります、そして、最も重要な八重奏は最初に、伝えられます。
Kind
種類
one octet. Indicates a sub-type for the OUI. There is no
standardization for this field. Each OUI implements its own
values.
1つの八重奏。 OUIのためにサブタイプを示します。 この分野のための標準化が全くありません。 各OUIはそれ自身の値を実装します。
The Kind field may be extended by the vendor to include zero or
more octets of the Value(s) field.
Kind分野は、Value(s)分野のゼロか、より多くの八重奏を含むようにベンダーによって広げられるかもしれません。
Simpson Informational [Page 2] RFC 2153 PPP vendor extensions May 1997
シンプソンInformational[2ページ]RFC2153PPPベンダー拡大1997年5月
Value(s)
値(s)
Zero or more octets. The details are implementation specific.
ゼロか、より多くの八重奏。 詳細は実装特有です。
2. Configuration Options
2. 設定オプション
The Configuration Option format and basic options are already defined for LCP [1].
Configuration Option書式と基本的なオプションはLCP[1]のために既に定義されます。
Up-to-date values of the LCP Option Type field are specified in the most recent "Assigned Numbers" [2]. This document concerns the following values:
LCP Option Type分野の最新の値は最新の「規定番号」[2]で指定されます。 このドキュメントは以下の値に関係があります:
0 Vendor-Specific
0ベンダー詳細
2.1. Vendor-Specific Option
2.1. ベンダー特有のオプション
Description
記述
Some implementors might not need nor want to publish their
proprietary algorithms and attributes. This mechanism is
available to specify these without encumbering the IANA with
proprietary number requests.
何人かの作成者は、必要があって、彼らの独占アルゴリズムと属性を発行したがっていないかもしれません。 このメカニズムは、独占数の要求でIANAを苦しめないでこれらを指定するために利用可能です。
Before accepting this option, the implementation must verify that
the Organizationally Unique Identifier and Kind specify a known
mechanism, and that any vendor specific negotiation values are
fully understood.
このオプションを受け入れる前に、実装は、Organizationally Unique IdentifierとKindが知られているメカニズムを指定して、どんなベンダーの特定の交渉値も完全に理解されていることを確かめなければなりません。
Rationale:
原理:
This is defined as general feature of all PPP Control Protocols,
to avoid future conflicts in vendor secretly self-assigned Type
numbers.
これは、Type番号が秘かに自己に割り当てられたベンダーでの今後の闘争を避けるためにすべてのPPP Controlプロトコルの一般的な特徴と定義されます。
A summary of the Vendor-Specific Configuration Option format is shown below. The fields are transmitted from left to right.
Vendor特有のConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| OUI+++++++++++++++++++++++++++++++++… | 種類| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Simpson Informational [Page 3] RFC 2153 PPP vendor extensions May 1997
シンプソンInformational[3ページ]RFC2153PPPベンダー拡大1997年5月
Type
タイプ
0
0
Length
長さ
>= 6
>= 6
When the Length is six, no Value(s) field is present.
Lengthが6歳であるときに、どんなValue(s)分野も存在していません。
OUI
OUI
three octets. The vendor's Organizationally Unique Identifier.
The bits within the octet are in canonical order, and the most
significant octet is transmitted first.
3つの八重奏。 ベンダーのOrganizationally Unique Identifier。 八重奏の中のビットが正準なオーダーにあります、そして、最も重要な八重奏は最初に、伝えられます。
Kind
種類
one octet. Indicates a sub-type for the OUI. There is no
standardization for this field. Each OUI implements its own
values.
1つの八重奏。 OUIのためにサブタイプを示します。 この分野のための標準化が全くありません。 各OUIはそれ自身の値を実装します。
The Kind field may be extended by the vendor to include zero or
more octets of the Value(s) field.
Kind分野は、Value(s)分野のゼロか、より多くの八重奏を含むようにベンダーによって広げられるかもしれません。
Value(s)
値(s)
Zero or more octets. The details are implementation specific.
ゼロか、より多くの八重奏。 詳細は実装特有です。
3. Organizationally Unique Identifiers
3. 組織的でユニークな識別子
The three-octet Organizationally Unique Identifier (OUI) identifies an organization that administers the meaning of the message. This OUI is based on IEEE 802 vendor assignments.
3八重奏のOrganizationally Unique Identifier(OUI)はメッセージの意味を管理する組織を特定します。 このOUIはIEEE802ベンダー課題に基づいています。
IEEE contact details for assignment of an OUI are given in [RFC- 1700]. Vendors that desire to use their IEEE 802 OUI for PPP Vendor Extensions should also register the OUI with IANA.
OUIの課題のための詳細な連絡先が[RFC1700]で与えられているIEEE。 また、PPP Vendor ExtensionsにそれらのIEEE802OUIを使用することを望んでいるベンダーはIANAにOUIを登録するべきです。
In the alternative, a vendor that does not otherwise need an IEEE assigned OUI can request a PPP specific OUI from IANA. This OUI shall be assigned from the 'CF0000' series. This has both the "locally-assigned" and "broadcast/multicast" bits set to 1; that is, the least significant two bits of the most significant octet are both set to 1.
代替手段で、そうでなければOUIをIEEEに割り当てる必要はないベンダーはIANAからPPPの特定のOUIを要求できます。 このOUIは'CF0000'シリーズから割り当てられるものとします。 これで、両方の「局所的に割り当てられる」と「放送/マルチキャスト」ビットを1に設定します。 すなわち、最も重要な八重奏の最も重要でない2ビットはともに1に設定されます。
Appearance in memory, bits transmitted right-to-left within octets,
メモリにおける外観、ビットは八重奏の中で左への右を伝えました。
Simpson Informational [Page 4] RFC 2153 PPP vendor extensions May 1997
シンプソンInformational[4ページ]RFC2153PPPベンダー拡大1997年5月
octets transmitted left-to-right:
八重奏は左から右を伝えました:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Multicast
Local
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | マルチキャスト地方です。
Rationale:
原理:
This is defined for vendors that are not able to use IEEE
assignments, such as software-only vendors.
これはソフトウェアだけベンダーなどのIEEE課題を使用できないベンダーのために定義されます。
It is not clear how the IEEE assigns blocks. In some instances,
the "locally-assigned" bit is known to have been used.
IEEEがどのようにブロックを割り当てるかは、明確ではありません。 ある場合に、「局所的に割り当てられた」ビットが使用されたのが知られています。
However, multicast has no meaning in PPP. Therefore, an IEEE
assigned OUI would have the multicast bit cleared to 0.
しかしながら、マルチキャストはPPPに意味を持っていません。 したがって、OUIが割り当てられたIEEEはマルチキャストビットを0まできれいにさせるでしょう。
The 'CF0000' series was arbitrarily chosen to match the PPP NLPID
'CF', as a matter of mnemonic convenience.
簡略記憶便利の問題としてPPP NLPID'CF'を合わせるために選ばれて、'CF0000'シリーズは任意にそうでした。
Security Considerations
セキュリティ問題
Security issues are not discussed in this document.
本書では安全保障問題について議論しません。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, DayDreamer, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
[2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,
July 1992.
[2] レイノルズ、J.K.、ポステル、J.B.、「規定番号」、RFC-1700、1992年7月。
Simpson Informational [Page 5] RFC 2153 PPP vendor extensions May 1997
シンプソンInformational[5ページ]RFC2153PPPベンダー拡大1997年5月
Contacts
接触
Comments about this document should be discussed on the ietf- ppp@merit.edu mailing list.
ietf ppp@merit.edu メーリングリストでこのドキュメントの周りのコメントについて議論するべきです。
This document was reviewed by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the current chair:
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって再検討されました。 現在のいすを通してワーキンググループに連絡できます:
Karl Fox
Ascend Communications
655 Metro Place South, Suite 379
Dublin, Ohio 43017
カールフォックスは南部のコミュニケーション655地下鉄場所、ダブリン、Suite379オハイオ 43017を昇ります。
karl@Ascend.com
karl@Ascend.com
Questions about this document can also be directed to:
また、このドキュメントに関する質問による以下のことよう指示できます。
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
wsimpson@UMich.edu wsimpson@GreenDragon.com(都合のよい)です。
Simpson Informational [Page 6]
シンプソンInformationalです。[6ページ]
一覧
スポンサーリンク
