RFC2097 日本語訳
2097 The PPP NetBIOS Frames Control Protocol (NBFCP). G. Pall. January 1997. (Format: TXT=27104 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Pall Request for Comments: 2097 Microsoft Corp. Category: Standards Track January 1997
コメントを求めるワーキンググループG.祭服要求をネットワークでつないでください: 2097年のMicrosoft Corp.カテゴリ: 標準化過程1997年1月
The PPP NetBIOS Frames Control Protocol (NBFCP)
ppp NetBIOSフレームはプロトコルを制御します。(NBFCP)
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)の現行版を参照してください。 このメモの分配は無制限です。
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, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するために広げることができるLink Controlプロトコルを定義して、Network Controlプロトコルのファミリーを提案します。
The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP.
NBFプロトコル[3]は元々、NetBEUIプロトコルと呼ばれました。 このドキュメントは、PPPの上でNBFプロトコルを設立して、構成するためにNetwork Controlプロトコルを定義します。
The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms.
エンドシステムが同輩システムが接続される同輩システムかLANに単に関させるのにおいてNBFCPプロトコルは適切です。 2つのLANを一緒に接続するには、それはNetBIOS名前制限とNetBIOS名前防衛機構のために適切ではありません。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 3
2. A PPP Network Control Protocol for NBF ................ 3
2.1 Sending NBF Datagrams ........................... 4
2.2 Bridging NBF Datagrams........................... 5
2.3 NetBIOS Name Defense............................. 5
3. NBFCP Configuration Options ........................... 6
3.1 Name-Projection.................................. 6
3.2 Peer-Information................................. 8
3.3 Multicast-Filtering.............................. 10
3.4 IEEE-MAC-Address-Required........................ 11
SECURITY CONSIDERATIONS ...................................... 12
REFERENCES ................................................... 12
1. 序論… 2 1.1 要件の仕様… 2 1.2用語… 3 2. pppネットワーク制御はNBFのために議定書を作ります… 3 2.1 データグラムをNBFに送ります… 4 2.2 NBFにデータグラムをブリッジします… 5 2.3NetBIOSがディフェンスを命名します… 5 3. NBFCP設定オプション… 6 3.1名前予測… 6 3.2同輩情報… 8 3.3マルチキャストフィルタリング… 10 3.4 IEEE-MACアドレスが必要です… 11 セキュリティ問題… 12の参照箇所… 12
Pall Standards Track [Page 1] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[1ページ]。
ACKNOWLEDGEMENTS ............................................. 13 CHAIR'S ADDRESS .............................................. 13 AUTHOR'S ADDRESS ............................................. 13
承認… 13 議長のアドレス… 13作者のアドレス… 13
1. Introduction
1. 序論
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating multi-protocol datagrams.
1. マルチプロトコルデータグラムをカプセル化するためのメソッド。
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols for establishing and
configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコルのファミリー。
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NBFCP packets to choose and configure the NBF network-layer protocol. Once NBFCP has reached the Opened state, NBF datagrams can be sent over the link.
ポイントツーポイント接続の上でコミュニケーションを確立するために、PPPリンクの各端は、最初に、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立されて、任意の施設が必要に応じてLCPによって交渉された後に、PPPは、NBFネットワーク層プロトコルを選んで、構成するためにパケットをNBFCPに送らなければなりません。 NBFCPがいったんOpened状態に達すると、NBFデータグラムをリンクの上に送ることができます。
The link will remain configured for communications until explicit LCP or NBFCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention).
リンクは明白なLCPかNBFCPパケットがリンクを閉鎖するか、または何らかの外部のイベントが起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
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.
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
「必要である」というThis単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
Thisは定義がある手段を言葉で表してはいけません。仕様の絶対禁止。
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and carefully weighed before choosing a
different course.
「推薦される」というSHOULD This単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意は、理解されて、異なったコースを選ぶ前に、慎重に熟慮されるべきです。
Pall Standards Track [Page 2] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[2ページ]。
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
5月のThis単語、または「任意である」という形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
1.2. Terminology
1.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
peer The other end of the point-to-point link.
他が終わらせるポイントツーポイント接続の同輩。
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
さらに処理しながら、静かにThis手段を実装がパケットを捨てる捨ててください。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
end-system
A user's machine. It only sends packets to servers and
other end-systems. It doesn't pass any packets through
itself.
エンドシステムAユーザのマシン。 それはサーバと他のエンドシステムにパケットを送るだけです。それ自体にどんなパケットも通しません。
router Allows packets to pass through, usually from one ethernet
segment to another. Sometimes these are called
"intermediate-systems".
通常、1つのイーサネットセグメントから別のセグメントまで通り抜けるルータAllowsパケット。 時々これらは「中間システム」と呼ばれます。
bridge Allows packets to pass through with the data field
unmodified. Usually from one ethernet segment to another
or from one ethernet segment to a token-ring segment.
Allowsがデータ・フィールドが変更されていなく通り抜けるパケットであるとブリッジしてください。 通常、1つのイーサネットセグメントから別のものまで1つのイーサネットセグメントからトークンリングセグメントまで。
gateway Allows packets to be sent from one network protocol to
the same or different network protocol. For example,
NetBIOS packets from an NBF network to a TCP/IP network
which has implemented RFC 1001 and RFC 1002.
1つのネットワークから送られるゲートウェイAllowsパケットは同じであるか異なったネットワーク・プロトコルに議定書を作ります。 例えば、NBFネットワークからTCP/IPまでのNetBIOSパケットはどれが、RFCが1001であると実装するか、そして、RFC1002をネットワークでつなぎます。
local access only server A server which does not pass any packets
through itself to other servers.
ローカルはそれ自体に他のサーバにどんなパケットも通さないサーバAサーバだけにアクセスします。
2. A PPP Network Control Protocol for NBF
2. NBFのためのpppネットワーク制御プロトコル
The NBF Control Protocol (NBFCP) is responsible for configuring, enabling, and disabling the NBF protocol modules on both ends of the point-to-point link. NBFCP uses the same packet exchange mechanism as the Link Control Protocol. NBFCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. NBFCP packets received before this phase is reached should be silently
ポイントツーポイント接続の両端でNBFプロトコルがモジュールであると構成して、可能にして、無効にするのにNBF Controlプロトコル(NBFCP)は原因となります。 NBFCPはLink Controlプロトコルと同じパケット交換メカニズムを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、NBFCPパケットを交換してはいけません。 このフェーズに達する前に受け取られたNBFCPパケットは静かにそうであるべきです。
Pall Standards Track [Page 3] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[3ページ]。
discarded.
捨てられる。
The NBF Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
NBF Controlプロトコルはまさに以下の例外でLink Controlプロトコル[1]と同じです:
Frame Modifications
フレーム変更
The packet may utilize any modifications to the basic frame format
which have been negotiated during the Link Establishment phase.
パケットは基本枠形式へのLink特権階級段階の間に交渉されているどんな変更も利用するかもしれません。
Data Link Layer Protocol Field
データリンク層プロトコル分野
Exactly one NBFCP packet is encapsulated in the Information field
of a PPP Data Link Layer frame where the Protocol field indicates
type hex 803f (NBF Control Protocol).
ちょうど1つのNBFCPパケットがプロトコル分野がタイプ十六進法803f(NBF Controlプロトコル)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Code field
コード分野
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes should be treated as
unrecognized and should result in Code-Rejects.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
Timeouts
タイムアウト
NBFCP packets MUST NOT be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation should be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time. Also,
because NetBIOS name defense takes time (typically a minimum of
3 seconds if names are added in parallel), it is suggested that
if Name-Projection is negotiated, the timeouts are increased to 10
seconds.
PPPがNetwork-層のプロトコルフェーズに達するまで、NBFCPパケットを交換してはいけません。 実装はAuthenticationとLink Quality Determinationが、以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのを待つように準備されるべきです。 実装がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。 また、NetBIOS名前ディフェンスが時間がかかるので(通常最低3秒は名前であるなら平行で加えられます)、Name-映像が交渉されるなら、タイムアウトが10秒まで増強されることが提案されます。
Configuration Option Types
設定オプションタイプ
NBFCP has a distinct set of Configuration Options.
NBFCPには、Configuration Optionsの異なったセットがあります。
2.1. Sending NBF Datagrams
2.1. 送付NBFデータグラム
Before any NBF packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the NBF Control Protocol must reach the Opened state.
どんなNBFパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、NBF ControlプロトコルはOpened状態に達しなければなりません。
Unless otherwise negotiated, exactly one NBF packet is encapsulated in the Information field of a PPP Data Link Layer frame where the
別の方法で交渉されない場合、ちょうどパケットがPPP Data Link Layerの情報分野でカプセルに入れられるあるNBFがどこを縁どっているか。
Pall Standards Track [Page 4] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[4ページ]。
Protocol field indicates type hex 003f (NBF datagram).
プロトコル分野はタイプ十六進法003f(NBFデータグラム)を示します。
Since NBF datagrams for PPP do not contain a datagram length field, the encapsulated NBF packet MUST NOT contain any extra octet padding except when Self-Defining-Padding is negotiated.
PPPのためのNBFデータグラムがデータグラム長さの分野を含んでいないので、カプセル化されたNBFパケットは詰め物を定義するSelfが交渉される時以外に、そっと歩くどんな付加的な八重奏も含んではいけません。
The maximum length of an NBF datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Since there is no standard method for fragmenting and reassembling NBF datagrams, PPP links supporting NBF MUST allow at least 576 octets in the information field of a data link layer frame. It is recommended that an implementation allow 1500 octets in the information field unless the IEEE-MAC-Address-Required boolean option is negotiated (see below).
PPPリンクの上に送られたNBFデータグラムの最大の長さはPPPデータ・リンク層フレームの情報分野の最大の長さと同じです。 NBFデータグラムを断片化して、組み立て直すための標準方法が全くないので、NBF MUSTをサポートするPPPリンクがデータ・リンク層フレームの情報フィールドでの少なくとも576の八重奏を許容します。 IEEE-MACアドレスが必要な論理演算子オプションが交渉されない場合(以下を見てください)実装が情報フィールドでの1500の八重奏を許容するのは、お勧めです。
2.2 Bridging NBF Datagrams
2.2 NBFにデータグラムをブリッジすること。
There exist at least four different MAC header implementations for NBF packets: 802.3 Ethernet, 802.5 Token-Ring, DIX Ethernet, and FDDI. Because NBF is not a routable protocol, some PPP implementations may require IEEE MAC addresses to properly route or bridge NBF packets. Some PPP implementations may require the entire MAC media header in order to properly route or bridge NBF packets. Other smarter implementations may only require the IEEE MAC addreses, and still other implementations (such as NetBIOS gateways) may not require any MAC address fields. NBFCP implementations which require IEEE Addresses should negotiate the NBFCP IEEE-MAC-Address-Required boolean configuartion option so that the MAC header can be provided in the NBF packet.
NBFパケットのための少なくとも4つの異なったMACヘッダー実装が存在しています: 802.5 802.3のイーサネット、トークンリング、DIXイーサネット、およびFDDI。 NBFがルータブル・プロトコルでないので、いくつかのPPP実装が適切に発送するIEEE MACアドレスかブリッジNBFパケットを必要とするかもしれません。 いくつかのPPP実装が、NBFがパケットであると適切に発送するか、またはブリッジするために全体のMACメディアヘッダーを必要とするかもしれません。 他の、より賢い実装はIEEE MAC addresesを必要とするだけであるかもしれません、そして、まだ他の実装(NetBIOSゲートウェイなどの)は少しのMACアドレス・フィールドも必要としないかもしれません。 IEEE Addressesを必要とするNBFCP実装は、MACヘッダーをNBFパケットに提供できるようにNBFCP IEEE-MACアドレスが必要な論理演算子configuartionオプションを交渉するべきです。
If IEEE-MAC-Address-Required boolean configuration option is negotiated, all NBF datagrams MUST be sent with the specified 12 octet IEEE MAC address header. Since negotiation of this option occurs after the LCP phase, NBF packets MAY exceed the negotiated PPP MRU size. A PPP implementation which negotiates this option MUST allow reception of PPP NBF packets 12 octets larger than the negotiated MRU size.
IEEE-MACアドレスが必要な論理演算子設定オプションを交渉するなら、指定された12八重奏IEEE MACアドレスヘッダーと共にすべてのNBFデータグラムを送らなければなりません。 このオプションの交渉がLCPフェーズの後に起こるので、NBFパケットは交渉されたPPP MRUサイズを超えるかもしれません。 このオプションを交渉するPPP実装は交渉されたMRUサイズより大きいPPP NBFパケット12八重奏のレセプションを許容しなければなりません。
2.3 NetBIOS Name Defense
2.3NetBIOSがディフェンスを命名します。
In order to guarantee uniqueness of NetBIOS Names on the network, NBFCP requires that end-system implementations MUST negotiate the Name-Projection configuration option.
ネットワークでNetBIOS Namesのユニークさを保証するために、NBFCPは、終わりシステムの実現がName-映像設定オプションを交渉しなければならないのを必要とします。
Pall Standards Track [Page 5] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[5ページ]。
3. NBFCP Configuration Options
3. NBFCP設定オプション
NBFCP Configuration Options allow modifications to the standard characteristics of the network-layer protocol to be negotiated. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
NBFCP Configuration Optionsは、ネットワーク層プロトコルの標準の特性への変更が交渉されるのを許容します。 Configuration OptionがConfigure-リクエスト・パケットに含まれていないなら、そのConfiguration Optionのためのデフォルト値は想定されます。
NBFCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options.
NBFCPはLCP[1]のためにOptionsの別々のセットで定義された同じConfiguration Option書式を使用します。
Up-to-date values of the NBFCP Option Type field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows:
NBFCP Option Type分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
1 Name-Projection
2 Peer-Information
3 Multicast-Filtering
4 IEEE-MAC-Address-Required
1 必要である名前映像2同輩情報3マルチキャストフィルタリング4IEEE-MACアドレス
3.1. Name-Projection
3.1. 名前映像
Description
記述
This Configuration Option provides a method for the peer to
provide the NetBIOS names registered on its network. The sender
of the Configure-Request states which NetBIOS names should be
added by the remote peer. More than one Name-Projection option
MAY appear in a single Configure-Request.
このConfiguration Optionは同輩がネットワークに登録されたNetBIOS名を提供するメソッドを提供します。 Configure-要求の送付者は、どのNetBIOS名がリモート同輩によって加えられるべきであるかを述べます。 1つ以上のName-映像オプションがただ一つのConfigure-要求に現れるかもしれません。
Implementations which do not attempt to add any NetBIOS names MUST
Configure-Reject the Name-Projection Configuration Option.
どんなNetBIOS名も加えるのを試みない実装はName-映像Configuration OptionをConfigure拒絶しなければなりません。
If the Name-Projection Configuration Option is not offered by the
remote peer, but is required by the local peer, the local peer
should Configure-Nak the request and indicate that it wishes the
remote peer to add zero NetBIOS names because it is the only known
acceptable value. The remote peer may then terminate NBFCP,
attempt to add zero NetBIOS names, or attempt add one or more
NetBIOS names.
そして、Name-映像Configuration Optionがリモート同輩によって提供されませんが、地元の同輩によって必要とされるなら、地元の同輩が必要であるべきである、Configure-Nak、要求、唯一の知られている許容値であるのでリモート同輩にNetBIOS名を全く加えないで欲しいのを示してください。 そして、リモート同輩はNBFCP(NetBIOS名、または試みが、1NetBIOSが命名すると言い足すゼロを加える試み)を終えるかもしれません。
When the receiving peer cannot add all the requested names, it
MUST Configure-Nak with the complete list of names requested.
Those names which could be added should have the Added field set
to zero. Those names which could not be added should have the
Added field set to an appropriate non-zero return code. The
sender of this Configuration Option SHOULD then resend the
Configure-Request with the successfully added names.
受信同輩がすべての要求された名前を加えることができるというわけではないとき、それは名前に関する全リストが要求されているConfigure-Nakを加えなければなりません。 加えることができたそれらの名前で、Added分野をゼロに設定するべきです。 加えることができなかったそれらの名前で、適切な非原点復帰コードにAdded分野を設定するべきです。 そして、このConfiguration Option SHOULDの送付者は首尾よく加えられた名前によるConfigure-要求を再送します。
Pall Standards Track [Page 6] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[6ページ]。
The implementation may choose to fail configuration if the
complete list of NetBIOS names is not accepted. By failing, the
implementation should terminate NBFCP by sending a Terminate-
Request packet.
NetBIOS名に関する全リストが受け入れられないなら、実装は、構成に失敗するのを選ぶかもしれません。 失敗することによって、実装はTerminateリクエスト・パケットを送ることによって、NBFCPを終えるべきです。
Because adding NetBIOS names can take time (usually 3 seconds) and
because PPP may default the restart timer to 3 seconds, the
restart timer SHOULD default to 10 seconds when configuring
NetBIOS names.
NetBIOS名を構成するとき、(通常3秒)の時間、PPPがデフォルトとするかもしれないのでNetBIOS名が取ることができると言い足す3への再開タイマが後援する再開タイマSHOULDが10秒をデフォルトとするので。
A summary of the Name-Projection Configuration Option format is shown below. The fields are transmitted from left to right.
Name-映像Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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 | 1st NetBIOS-Name
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1st NetBIOS-Name (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1st NetBIOS-Name (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1st NetBIOS-Name (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1st NetBIOS-Name (cont.) | Added |2nd NetBIOS Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 最初のNetBIOS-名前+++++++++++++++++++++++++++++++++| 最初のNetBIOS-名前(cont。) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最初のNetBIOS-名前(cont。) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最初のNetBIOS-名前(cont。) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最初のNetBIOS-名前(cont。) | 加えられます。|2番目のNetBIOS名… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
2 + (Number of NetBIOS names * 17)
2 + (NetBIOS名前*17の数)
NetBIOS-Names
NetBIOS-名前
This group of zero or more sixteen octet NetBIOS-Name fields
contains a list of all the NetBIOS names the peer wishes to add to
the remote network if the packet is Configure-Request. If the
packet is Configure-Reject, the peer does not support this
configuration option and it can be assumed that no NetBIOS names
were added.
ゼロか、より多くの16の八重奏NetBIOS-名前欄のこのグループはパケットがConfigure-要求であるならNetBIOSがリモートネットワークに加えるという同輩願望を命名するすべてのリストを含みます。 パケットがConfigure-廃棄物であるなら、同輩は、この構成がオプションであるとサポートしません、そして、NetBIOS名が全く加えられなかったと思うことができます。
Because the length field is only one octet, only 14 NetBIOS names
can be added per Name-Projection option. If more than 14 NetBIOS
names should be added, then more than one Name-Projection option
packet will have to be sent in the Configure-Request packet.
長さの分野が1つの八重奏にすぎないので、Name-映像オプション単位で14のNetBIOS名しか加えることができません。 14以上のNetBIOS名を加えると、Configure-リクエスト・パケットで1つ以上のName-映像オプションパケットを送らなければならないでしょう。
Pall Standards Track [Page 7] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[7ページ]。
Added
加えられます。
This is a one octet field which plays a dual role. The Added
field in the Name-Projection Request packet contains the type of
NetBIOS name added. A summary of name types is listed below.
これは二役を演じる1つの八重奏分野です。 Name-映像RequestパケットのAdded分野は名前が加えたNetBIOSのタイプを含んでいます。 名前タイプの概要は以下にリストアップされています。
01 Unique Name.
02 Group Name.
01のユニークな名。 02グループ名。
If the packet is a Configure-Reject the Added field should contain
the NetBIOS return code for the NetBIOS Add Name or NetBIOS Add
Group Name command as defined in the NetBIOS 3.0 specification =
[3].
パケットがConfigure-廃棄物であるなら、Added分野はNetBIOS3.0仕様=[3]で定義されるようにNetBIOS Add NameかNetBIOS Add Group NameコマンドのためのNetBIOS復帰コードを含むべきです。
A summary of common result codes is listed below in type hex.
一般的な結果コードの概要は以下にタイプ十六進法でリストアップされています。
00 Name successfully added.
0D Duplicate name in local name table.
0E Name table full.
15 Name not found or cannot specify "*" or null.
16 Name in use on remote NetBIOS.
19 Name conflict detected.
30 Name defined by another environment.
35 Required system resources exhausted.
00名は首尾よく加えました。 0Dは地方のネームテーブルの名前をコピーします。 0Eがテーブルをいっぱいに命名します。 15名は、「*」かヌルを見つけるか、または指定できます。 16 リモートNetBIOSで使用中に命名します。 19は検出された闘争を命名します。 別の環境によって定義された30名。 35は疲れ果てた状態でシステム資源を必要としました。
3.2. Peer-Information
3.2. 同輩情報
Description
記述
This Configuration Option provides a way for the peer to
communicate NetBIOS pertinent configuration information. Although
negotiation of this option is not mandatory, it is suggested.
このConfiguration Optionは同輩がNetBIOSの適切な設定情報を伝える方法を提供します。 このオプションの交渉は義務的ではありませんが、それは示されます。
A summary of the Peer-Information Option format is shown below. The fields are transmitted from left to right.
Peer-情報Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Peer-class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-version (major) | Peer-version(minor) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-name ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 同輩クラス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩バージョン(少佐)| 同輩バージョン(小さい方の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩名… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pall Standards Track [Page 8] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[8ページ]。
Type
タイプ
2
2
Length
長さ
>=3D8
>=3D8
If the length is 8, there is no Peer-name. If the length is
greater than 8, the Peer-name's length is Length - 8.
長さが8であるなら、Peer-名前が全くありません。 長さが8以上であるなら、Peer-名前の長さはLengthです--8。
Peer-class
同輩クラス
The Peer-class field is one octet. It identifies the sender's
implementation type.
Peer-類体は1つの八重奏です。 それは送付者の実装タイプを特定します。
Initial values are assigned as follows:
初期の値は以下の通り割り当てられます:
Value Class
値のクラス
1 Reserved for legacy implementations.
2 PPP NetBIOS Gateway Server.
3 Reserved for legacy implementations.
4 PPP Local Access Only Server.
5 Reserved for legacy implementations.
6 PPP NBF Bridge.
7 Reserved for legacy implementations.
8 PPP End-System.
1 レガシー実装のために、予約されます。 2 PPP NetBIOSゲートウェイServer3 レガシー実装のためのReserved。 4 PPP Local Access Only Server5 レガシー実装のためのReserved。 6 ppp NBFはブリッジします。 7 レガシー実装のために、予約されます。 8pppエンドシステム。
Peer-version
同輩バージョン
The Peer-version field is four octets and indicates the version of
the communication peer providing one side of the PPP connection.
The first two octets are the major version number and the last two
octets are the minor version number. The major and minor version
represent a 16 bit unsigned number sent with the most significant
octet first.
Peer-バージョン分野は、4つの八重奏であり、PPP接続の半面を提供するコミュニケーション同輩のバージョンを示します。 最初の2つの八重奏がメジャーバージョン番号です、そして、最後の2つの八重奏がマイナーバージョン番号です。 主要で小さい方のバージョンは最初に最も重要な八重奏と共に送られた16の噛み付いている符号のない数を表します。
Peer-name
同輩名
The name of the peer. A suggested name is the NetBIOS workstation
name of the peer. If the length field is 8, no peer name is
provided. The peer-name may not be greater than 32 octets in
length.
同輩の名前。 提案された名前は同輩のNetBIOSワークステーション名です。 長さの分野が8であるなら、同輩名を全く提供しません。 同輩名は長さが32以上の八重奏でないかもしれません。
Pall Standards Track [Page 9] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[9ページ]。
3.3. Multicast-Filtering
3.3. マルチキャストをフィルターにかけます。
Description
記述
This Configuration Option provides a way to negotiate the use of
the Multicast-Forward-Period and the Multicast-Priority. This
Configuration Option provides a way to negotiate how to handle
mulicast packets. It allows the sender of the Configure-Request
to state the current handling of multicast packets. The peer can
request parameters by NAKing the option, and returning valid
Multicast-Filtering parameters.
このConfiguration OptionはMulticastの前進の期間とMulticast-優先権の使用を交渉する方法を提供します。 このConfiguration Optionはどうmulicastパケットを扱うかを交渉する方法を提供します。 それで、Configure-要求の送付者はマルチキャストパケットの現在の取り扱いを述べることができます。 同輩はMulticastをフィルターにかけるのであるNAKingオプションの、そして、戻っている有効なパラメタからパラメタを要求できます。
If negotiation about the remote Multicast-Filtering is required,
and the peer did not provide the option in its Configure-Request,
the option SHOULD be appended to a Configure-Nak.
Multicast-フィルタリングがリモートに関する交渉であるなら必要でした、そして、同輩はConfigure-要求におけるオプションを提供しませんでした、オプションSHOULD。Configure-Nakに追加します。
Controlling the multicast rate is important because some NetBIOS
applications use multicasts to communicate and withholding
multicasts may prevent these applications from working. It is
also true that other NetBIOS applications do not need to receive
any multicast packets and therefore it is best to quench the rate
at which the peer will send multicast packets.
いくつかのNetBIOSアプリケーションが交信するのにマルチキャストを使用するので、マルチキャストレートを制御するのは重要です、そして、源泉徴収マルチキャストはこれらのアプリケーションが働くのを防ぐかもしれません。 また、他のNetBIOSアプリケーションがどんなマルチキャストパケットも受ける必要はないのも、本当であり、したがって、同輩がマルチキャストパケットを送るレートを冷却するのは最も良いです。
By default, the peer is pre-configured to an administrator
assigned Multicast-Forward-Period and Priority. A Multicast-
Forward-Period specified as hex type FFFF in a Configure-Request
is interpreted as requesting the receiving peer to specify a value
in its Configure-Nak. A Multicast-Forward-Period value specified
as hex type FFFF in a Configure-Nak is interpreted as agreement
that no value exists. A Multicast-Forward-Period of zero indicates
that all multicast packets SHOULD be forwarded.
デフォルトで、同輩はMulticastの前進の期間が割り当てられた管理者とPriorityにあらかじめ設定されます。 Configure-Nakで値を指定するよう受信同輩に要求しながらConfigure-要求における十六進法タイプFFFFが解釈されるので、Multicastの前進の期間は指定しました。 Configure-Nakの十六進法タイプFFFFが値が全く存在していないという協定として解釈されるので、Multicastの前進の期間の値は指定しました。 Multicastの前進の期間のゼロは、すべてのマルチキャストパケットSHOULDが進められるのを示します。
Peers that rely on all multicast packets being forwarded SHOULD
request a Multicast-Forward-Period of zero and a Multicast-
Priority of one by NAKing the Configure-Request option and
appending the proper parameters to a Configure-Nak.
SHOULDが送られるすべてのマルチキャストパケットを当てにする同輩がMulticastの前進の期間のゼロと1つのNAKingによるConfigure-要求オプションと適切なパラメタをConfigure-Nakに追加するMulticast優先を要求します。
A summary of the Multicast-Filtering Configuration Option format is shown below. The fields are transmitted from left to right.
MulticastをフィルターにかけるのであるConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Multicast-Forward-Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| マルチキャストの前進の期間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 優先権| +-+-+-+-+-+-+-+-+
Pall Standards Track [Page 10] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[10ページ]。
Type
タイプ
3
3
Length
長さ
5
5
Multicast-Forward-Period
マルチキャストの前進の期間
The Multicast-Forward-Period field is two octets and indicates
the maximum period in seconds at which multicast packets can
be sent. The maximum value for this field is 60 (one minute).
A value of zero indicates that there is no maximum period at
which multicast packets can be sent. A value of hex type FFFF
indicates that the Multicast-Forward-Period is unknown. A value
of five indicates that multicast packets will not be sent at a
rate more frequent than once every five seconds. This two
octet value represents a 16 bit unsigned number sent with
the most significant octet first.
Multicastの前進の期間の分野は、2つの八重奏であり、秒の最大の期間にどのマルチキャストにパケットを送ることができるかを示します。 この分野への最大値は60(1分)です。 ゼロの値は、マルチキャストパケットを送ることができるどんな最大の期間もないのを示します。 十六進法タイプFFFFの値は、Multicastの前進の期間が未知であることを示します。 5の値は、マルチキャストパケットが5秒あたりの一度より頻繁なレートで送られないのを示します。 この2八重奏価値は最初に最も重要な八重奏と共に送られた16の噛み付いている符号のない数を表します。
Priority
優先権
The Priority field is one octet long and indicates if multicast
packets have priority over other packets when being sent. A value
of 0 indicates that directed packets have priority. A value of 1
indicates that multicast packets have priority.
Priority分野は、長い間の1つの八重奏であり、送ると、マルチキャストパケットで他のパケットより優先権があるかどうかを示します。 0の値は、指示されたパケットには優先権があるのを示します。 1の値は、マルチキャストパケットには優先権があるのを示します。
3.4. IEEE-MAC-Address-Required
3.4. IEEE-MACアドレスが必要です。
Description
記述
This boolean Configuration Option provides a method for the peer
to require that all NBF datagrams be sent with a 12 octet IEEE MAC
Address header. By default, it is assumed that no MAC header is
required.
この論理演算子Configuration Optionは同輩が、すべてのNBFデータグラムが12八重奏IEEEマックーアドレスヘッダーと共に送られるのを必要とするメソッドを提供します。 デフォルトで、MACヘッダーは全く必要でないと思われます。
A summary of the IEEE-MAC-Address-Required Boolean Configuration Option format is shown below. The fields are transmitted from left to right.
IEEE-MACアドレスが必要なブールConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pall Standards Track [Page 11] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[11ページ]。
Type
タイプ
4
4
Length
長さ
2
2
Requirements
要件
By default the NBF datagram is sent without any MAC header
information. The NBF datagram information field is equivalent to
the data field in 802.3, 802.5, and FDDI frames.
デフォルトで、少しもMACヘッダー情報なしでNBFデータグラムを送ります。 NBFデータグラム情報フィールドは802.3、802.5、およびFDDIフレームのデータ・フィールドに同等です。
If this option is negotiated successfully, each NBF datagram is
sent with a 12 octet IEEE MAC Address header prepended to the
information field. A summary of the information field when using
12 octet IEEE MAC Headers is shown below. The fields are
transmitted from left to right. The MAC Address is in non-
canonical form. This means that the first bit to be transmitted in
every byte is the most significant bit.
首尾よくこのオプションを交渉するなら、12八重奏IEEEマックーアドレスヘッダーが情報フィールドにprependedされている状態で、それぞれのNBFデータグラムを送ります。 12八重奏IEEE MAC Headersを使用するとき、情報フィールドの概要は以下に示されます。 野原は左から右まで伝えられます。 マックーアドレスが非標準形にあります。 これは、あらゆるバイトで伝えられるべき最初のビットが最も重要なビットであることを意味します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.3/802.5/FDDI data field...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地マックーアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地マックーアドレス| ソースマックーアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースマックーアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.3/802.5/FDDIデータ・フィールド… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[2] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[3] IBM Corp., "IBM Local Area Network Technical Reference",
Third Edition, Document Number SC30-3383-2, November 4, 1988.
[3] IBM社、「IBMのローカル・エリア・ネットワークの技術的な参照」、第3版は数のSC30-3383-2、1988年11月4日を記録します。
Pall Standards Track [Page 12] RFC 2097 NBFCP January 1997
祭服規格はNBFCP1997年1月にRFC2097を追跡します[12ページ]。
[4] Baker, F., and R. Bowen "PPP Bridging Control Protocol (BCP)",
Work in Progress.
[4] 「pppブリッジするコントロールは議定書の中で述べ(BCP)」ベイカー、F.、およびR.ボーエンは進行中で働いています。
Acknowledgments
承認
Some of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).
テキストのいくつかがPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって製作された前のドキュメントから本書では抜粋されます。
Thomas J. Dimitri (previously at Microsoft Corporation) authored the original draft.
トーマスJ.ディミトリ、(以前に、マイクロソフト社) オリジナルの草稿を書きました。
Special thanks go to coworkers at Microsoft, Bill Simpson (Daydreamer), Tom Coradetti (DigiBoard), Marty Del Vecchio (Shiva), Russ Gocht (Shiva) and several members of the IETF PPP Working Group.
特別な感謝はマイクロソフトの同僚、ビル・シンプソン(空想家)、トムCoradetti(DigiBoard)、マーティ・デル・ヴェッキョ(シバ神)、ラスGocht(シバ神)、およびIETF PPP作業部会の数人のメンバーのものになります。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
karl@MorningStar.com
karl@Ascend.com
karl@MorningStar.com karl@Ascend.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Gurdeep Singh Pall
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052-6399
Gurdeepシン祭服マイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: gurdeep@microsoft.com
メール: gurdeep@microsoft.com
Pall Standards Track [Page 13]
祭服標準化過程[13ページ]
一覧
スポンサーリンク
