RFC1552 日本語訳
1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP).W. Simpson. December 1993. (Format: TXT=29173 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson Request for Comments: 1552 Daydreamer Category: Standards Track December 1993
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1552年の空想家カテゴリ: 標準化過程1993年12月
The PPP Internetwork Packet Exchange Control Protocol (IPXCP)
pppインターネットワークパケット交換制御プロトコル(IPXCP)
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 method for transmitting 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 IPX protocol was originally used in Novell's NetWare products [3], and is now supported by numerous other vendors. This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP.
IPXプロトコルは、元々ノベルのNetWare製品[3]の中に使用されて、現在、他の多数のベンダーによってサポートされます。 このドキュメントは、PPPの上でIPXプロトコルを設立して、構成するためにNetwork Controlプロトコルを定義します。
This memo is the product of the Point-to-Point Protocol Working Group of the IETF. Comments should be submitted to the ietf- ppp@ucdavis.edu mailing list.
このメモはPointからポイントへのIETFのプロトコル作業部会の製品です。 ietf ppp@ucdavis.edu メーリングリストにコメントを提出するべきです。
Simpson [Page 1] RFC 1552 PPP IPXCP December 1993
シンプソン[1ページ]RFC1552ppp IPXCP1993年12月
Table of Contents
目次
1. Introduction ...................................................2 1.1 Specification of Requirements ..................................3 1.2 Terminology ....................................................3 2. A PPP Network Control Protocol for IPX .........................4 2.1 Sending IPX Datagrams ..........................................5 2.2 IPX-WAN protocol ...............................................5 2.3 Desired Parameters .............................................5 2.4 Co-existence with IPX-WAN ......................................6 3. IPXCP Configuration Options ....................................6 3.1 IPX-Network-Number .............................................7 3.2 IPX-Node-Number ................................................8 3.3 IPX-Compression-Protocol .......................................9 3.4 IPX-Routing-Protocol ...........................................11 3.5 IPX-Router-Name ................................................12 3.6 IPX-Configuration-Complete .....................................13 APPENDIX A. Link Delay and Throughput ..............................14 SECURITY CONSIDERATIONS ............................................14 REFERENCES .........................................................15 ACKNOWLEDGEMENTS ...................................................15 CHAIR'S ADDRESS ....................................................15 AUTHOR'S ADDRESS ...................................................16
1. 序論…2 1.1 要件の仕様…3 1.2用語…3 2. pppネットワーク制御はIPXのために議定書を作ります…4 2.1 データグラムをIPXに送ります…5 2.2IPX-WANプロトコル…5 2.3 パラメタを望んでいます…5 IPX-WANがある2.4共存…6 3. IPXCP設定オプション…6 3.1IPX-ネットワーク・ナンバー…7 3.2IPX-ノード番号…8 3.3 IPX圧縮プロトコル…9 3.4IPX-ルーティング・プロトコル…11 3.5IPXルータ名…12、3.6、IPX構成完全である、…13付録A.は遅れとスループットをリンクします…14 セキュリティ問題…14の参照箇所…15の承認…15 議長のアドレス…15作者のアドレス…16
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 IPXCP packets to choose and configure the IPX network-layer protocol. Once IPXCP has reached the Opened state, IPX datagrams can be sent over the link.
ポイントツーポイント接続の上でコミュニケーションを確立するために、PPPリンクの各端は、最初に、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立されて、任意の施設が必要に応じてLCPによって交渉された後に、PPPは、IPXネットワーク層プロトコルを選んで、構成するためにパケットをIPXCPに送らなければなりません。 IPXCPがいったんOpened状態に達すると、IPXデータグラムをリンクの上に送ることができます。
The link will remain configured for communications until explicit LCP or IPXCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention).
リンクは明白なLCPかIPXCPパケットがリンクを閉鎖するか、または何らかの外部のイベントが起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
Simpson [Page 2] RFC 1552 PPP IPXCP December 1993
シンプソン[2ページ]RFC1552ppp IPXCP1993年12月
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.
「必要である」というこの単語、または形容詞が、定義が仕様に関する絶対条件であることを意味します。
MUST NOT
必須NOT
This phrase means that the definition is an absolute prohibition
of the specification.
この句は、定義が仕様の絶対禁止であることを意味します。
SHOULD
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.
「推薦される」というこの単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意は、理解されて、異なったコースを選ぶ前に、慎重に熟慮されるべきです。
MAY
5月
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.
「任意である」というこの単語、または形容詞が、この項目が許容セットの代替手段の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.
これは、実装がさらなる処理なしでパケットを捨てることを意味します。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
Simpson [Page 3] RFC 1552 PPP IPXCP December 1993
シンプソン[3ページ]RFC1552ppp IPXCP1993年12月
end-system
エンドシステム
A user's machine. It only sends packets to servers and other
end-systems. It doesn't pass any packets through itself.
ユーザのマシン。 それはサーバと他のエンドシステムにパケットを送るだけです。それ自体にどんなパケットも通しません。
router
ルータ
Allows packets to pass through, usually from one ethernet segment
to another. Sometimes these are called "intermediate-systems".
パケットが通常、1つのイーサネットセグメントから別のセグメントまで通り抜けるのを許容します。 時々これらは「中間システム」と呼ばれます。
half-router
半分ルータ
Two normal routers, with an unnumbered link between them. Each
looks like a router to the local users, but Netware doesn't
understand unnumbered links, so each router is made to look like
they both are a single machine.
それらの間には、無数のリンクがある2つの正常なルータ。 それぞれが地元のユーザにルータに似ていますが、Netwareが無数のリンクを理解していないので、各ルータは、それらの両方が単一マシンであるように見えさせられます。
2. A PPP Network Control Protocol for IPX
2. IPXのためのpppネットワーク制御プロトコル
The IPX Control Protocol (IPXCP) is responsible for configuring, enabling, and disabling the IPX protocol modules on both ends of the point-to-point link. IPXCP uses the same packet exchange mechanism as the Link Control Protocol. IPXCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPXCP packets received before this phase is reached should be silently discarded.
ポイントツーポイント接続の両端でIPXプロトコルがモジュールであると構成して、可能にして、無効にするのにIPX Controlプロトコル(IPXCP)は原因となります。 IPXCPはLink Controlプロトコルと同じパケット交換メカニズムを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、IPXCPパケットは交換されないかもしれません。 このフェーズに達する前に受け取られたIPXCPパケットは静かに捨てられるべきです。
The IPX Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
IPX 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 IPXCP packet is encapsulated in the Information field
of a PPP Data Link Layer frame where the Protocol field indicates
type hex 802B (IPX Control Protocol).
ちょうど1つのIPXCPパケットがプロトコル分野がタイプ十六進法802B(IPX 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-廃棄物をもたらすはずです。
Simpson [Page 4] RFC 1552 PPP IPXCP December 1993
シンプソン[4ページ]RFC1552ppp IPXCP1993年12月
Timeouts
タイムアウト
IPXCP packets may 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.
PPPがNetwork-層のプロトコルフェーズに達するまで、IPXCPパケットは交換されないかもしれません。 実装はAuthenticationとLink Quality Determinationが、以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのを待つように準備されるべきです。 実装がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。
Configuration Option Types
設定オプションタイプ
IPXCP has a distinct set of Configuration Options.
IPXCPには、Configuration Optionsの異なったセットがあります。
2.1 Sending IPX Datagrams
2.1 送付IPXデータグラム
Before any IPX packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IPX Control Protocol must reach the Opened state.
どんなIPXパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、IPX ControlプロトコルはOpened状態に達しなければなりません。
Exactly one IPX packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 002B (IPX datagram).
ちょうど1つのIPXパケットがプロトコル分野がタイプ十六進法002B(IPXデータグラム)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
The maximum length of an IPX 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 IPX datagrams, PPP links supporting IPX MUST allow at least 576 octets in the information field of a data link layer frame.
PPPリンクの上に送られたIPXデータグラムの最大の長さはPPPデータ・リンク層フレームの情報分野の最大の長さと同じです。 IPXデータグラムを断片化して、組み立て直すための標準方法が全くないので、IPX MUSTをサポートするPPPリンクがデータ・リンク層フレームの情報フィールドでの少なくとも576の八重奏を許容します。
2.2 IPX-WAN protocol
2.2 IPX-WANプロトコル
A Novell specification called IPX-WAN [4] is intended to provide mechanisms similar to IPXCP negotiation over wide area links. As viewed by PPP, IPX-WAN is a part of IPX, and IPX-WAN packets are indistinguishable from other IPX packets.
IPX-WAN[4]と呼ばれるノベル仕様が広い領域のリンクの上のIPXCP交渉と同様のメカニズムを提供することを意図します。 PPPによって見られるように、IPX-WANはIPXの一部です、そして、IPX-WANパケットは他のIPXパケットから区別がつきません。
Currently, Novell has implemented IPXCP without any Configuration Options, and requires successful IPX-WAN completion, even when all required parameters have been hand configured. This makes it impossible for the current Novell products to interoperate with other IPXCP implementations which do not already include support for IPX- WAN.
現在、ノベルは、少しもConfiguration OptionsなしでIPXCPを実装して、うまくいっているIPX-WAN完成を必要とします、すべての必要なパラメタが手で構成さえされたとき。 これで、現在のノベル製品が既にIPX WANのサポートを含んでいない他のIPXCP実装で共同利用するのが不可能になります。
2.3 Desired Parameters
2.3 必要なパラメタ
To resolve the possible conflict between the two configuration methods, this specification defines the concept of "Desired
2つの構成メソッドの間の可能な闘争を解決するために、この仕様は「望まれた」概念を定義します。
Simpson [Page 5] RFC 1552 PPP IPXCP December 1993
シンプソン[5ページ]RFC1552ppp IPXCP1993年12月
Parameters". Where applicable, each Configuration Option indicates the environment where the parameter which is negotiated MAY be required by the implementation for proper operation.
「パラメタ。」 適切であるところで、各Configuration Optionは交渉されるパラメタが適切な操作のために実装によって必要とされるかもしれない環境を示します。
This determination is highly implementation dependent. For example, a particular implementation might require that all links have addresses, while another implementation might not need such addresses. The configuration negotiation is intended to discover that this pair of implementations will never converge.
この決断は実装に非常に依存しています。 例えば、特定の実装は、すべてのリンクにはアドレスがあるのを必要とするかもしれませんが、別の実装はそのようなアドレスを必要としないかもしれません。 構成交渉が、実装のこの組が決して一点に集まらないと発見することを意図します。
2.4 Co-existence with IPX-WAN
2.4 IPX-WANがある共存
An IPXCP implementation which includes support for IPX-WAN SHOULD always reach Opened state, even when unable to negotiate some "Desired Parameter", and when no Configuration Options are successfully negotiated. This allows IPX-WAN the opportunity to finish the negotiation.
いくつかの「必要なパラメタ」を交渉さえできないとき、IPX-WAN SHOULDがいつもOpened状態に達して、Configuration Optionsが全く首尾よく交渉されないときサポートを含んでいるIPXCP実装。 これはIPX-WANに交渉を終える機会を許容します。
If an implementation does not include support for IPX-WAN, it SHOULD NOT reach Opened state when unable to negotiate some "Desired Parameter".
実装がそうしないなら、IPX-WANのサポートを含めてください、それ。いくつかの「必要なパラメタ」を交渉できないとき、SHOULD NOTはOpened状態に達します。
IPX-WAN uses a "Timer Request" packet to set up the link. These MUST NOT be sent until IPXCP has Opened the link.
IPX-WANは、リンクをセットアップするのに「タイマ要求」パケットを使用します。 IPXCPにはOpenedがあるまで、これらを送ってはいけません。リンク。
An implementation which provides both IPX-WAN and IPXCP Configuration Options capability SHOULD only send a Timer Request packet when a Timer Request packet is received, or upon failure to successfully negotiate a "Desired Parameter".
Timer Requestパケットが受け取るか、または首尾よく「必要なパラメタ」を交渉しないことにあるときIPX-WANとSHOULDが送るだけであるIPXCP Configuration Options能力の両方にTimer Requestパケットを提供する実装。
If unable to complete IPX-WAN setup when a "Desired Parameter" is unknown, by default IPXCP SHOULD terminate the link.
「必要なパラメタ」が未知であるときに、IPX-WANセットアップを終了できないなら、デフォルトで、IPXCP SHOULDはリンクを終えます。
However, some implementations might be capable of operating without all indicated "Desired Parameters", in which case the termination MUST be configurable.
しかしながら、いくつかの実装がすべての示された「必要なパラメタ」なしで作動できるかもしれない、その場合、終了は構成可能であるに違いありません。
3. IPXCP Configuration Options
3. IPXCP設定オプション
IPXCP 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.
IPXCP Configuration Optionsは、ネットワーク層プロトコルの標準の特性への変更が交渉されるのを許容します。 Configuration OptionがConfigure-リクエスト・パケットに含まれていないなら、そのConfiguration Optionのためのデフォルト値は想定されます。
IPXCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options.
IPXCPはLCP[1]のためにOptionsの別々のセットで定義された同じConfiguration Option書式を使用します。
Up-to-date values of the IPXCP Option Type field are specified in the
IPXCP Option Type分野の最新の値は指定されます。
Simpson [Page 6] RFC 1552 PPP IPXCP December 1993
シンプソン[6ページ]RFC1552ppp IPXCP1993年12月
most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows:
最新の「規定番号」RFC[2]。 現行価値は以下の通り割り当てられます:
1 IPX-Network-Number
2 IPX-Node-Number
3 IPX-Compression-Protocol
4 IPX-Routing-Protocol
5 IPX-Router-Name
6 IPX-Configuration-Complete
1IPX-ネットワーク・ナンバー2IPX-ノード番号3IPX圧縮プロトコル4IPX-ルーティング・プロトコル5IPXルータ名の6、IPX構成完全
3.1 IPX-Network-Number
3.1 IPX-ネットワーク・ナンバー
Description
記述
This Configuration Option provides a way to negotiate the IPX
network number to be used for the link. This allows an
implementation to learn the network number, or to ensure agreement
on the network number.
このConfiguration Optionはリンクに使用されるためにIPXネットワーク・ナンバーを交渉する方法を提供します。 これで、実装は、ネットワーク・ナンバーを学ぶか、またはネットワーク・ナンバーの協定を確実にします。
The network number MUST be unique within the routing domain, or
zero to indicate that it is not used for routing.
ネットワーク・ナンバーは経路ドメイン、またはそれがルーティングに使用されないのを示すゼロの中でユニークであるに違いありません。
The sender of the Configure-Request states which network number is
desired. A network number specified as zero in a Configure-
Request shall be interpreted as requesting the peer to specify
another value in a Configure-Nak. A network number specified as
zero in a Configure-Ack shall be interpreted as agreement that no
value exists.
Configure-要求の送付者は、どのネットワーク・ナンバーが望まれているかを述べます。 Configure-Nakで別の値を指定するよう同輩に要求しながら、Configureのゼロが要求するように指定されたネットワーク・ナンバーは解釈されるものとします。 Configure-Ackのゼロが値が全く存在していないという協定として解釈されるものとするので、ネットワーク・ナンバーは指定しました。
Both ends of the link MUST have the same network number. When a
Configure-Request is received which has a lower network number
than locally configured, a Configure-Nak MUST be returned with the
highest network number.
リンクの両端に、同じネットワーク・ナンバーがなければなりません。 Configure-要求が受信されているとき、最も高いネットワーク・ナンバーと共に局所的に構成されるより低ネットワーク・ナンバー、Configure-Nakをどれに返したに違いありませんか?
When the peer did not provide the option in its Configure-Request,
the option SHOULD NOT be appended to a Configure-Nak.
同輩がConfigure-要求におけるオプション、オプションにSHOULD NOTを提供しなかったとき、Configure-Nakに追加してください。
By default, no network number is assigned to the link (the network
number is zero). There is no need for a network number if the
interface is not used by a routing protocol.
デフォルトで、ネットワーク・ナンバーは全くリンクに割り当てられません(ネットワーク・ナンバーはゼロです)。 インタフェースがルーティング・プロトコルによって使用されないなら、ネットワーク・ナンバーの必要は全くありません。
This is a Desired Parameter when the implementation is operating
as a router. It MUST be negotiated if the network number is non-
zero, and has been derived from another interface.
実装がルータとして作動しているとき、これはDesired Parameterです。 それをネットワーク・ナンバーが非ゼロであるなら交渉しなければならなくて、別のインタフェースから得ました。
Any IPX-WAN packets received MUST supercede information negotiated
in this option.
パケットが受けたどんなIPX-WANもこのオプションで交渉されたsupercede情報がそうしなければなりません。
Simpson [Page 7] RFC 1552 PPP IPXCP December 1993
シンプソン[7ページ]RFC1552ppp IPXCP1993年12月
A summary of the IPX-Network-Number Configuration Option format is
shown below. The fields are transmitted from left to right.
IPXネットワーク番号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 | IPX-Network-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPX-Network-Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| IPX-ネットワーク・ナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX-ネットワーク・ナンバー(cont。) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
6
6
IPX-Network-Number
IPX-ネットワーク・ナンバー
The four octet IPX-Network-Number is the desired local IPX network
number of the sender of the Configure-Request. This number may be
zero, which is interpreted as being a local network of unknown
number that is not used by the routing protocol.
4八重奏IPXネットワーク番号はConfigure-要求の送付者の必要な地方のIPXネットワーク・ナンバーです。 この数はゼロであるかもしれません。(そのゼロは、ルーティング・プロトコルによって使用されない未知の数の企業内情報通信網であるので解釈されます)。
3.2 IPX-Node-Number
3.2 IPX-ノード番号
Description
記述
This Configuration Option provides a way to negotiate the IPX node
number to be used for the local end of the link. This allows an
implementation to learn its node number, or to inform the peer of
its node number.
このConfiguration Optionはリンクの地方の端に使用されるためにIPXノード番号を交渉する方法を提供します。 これで、実装をノード番号を学ぶか、またはノード番号について同輩に知らせます。
The node number MUST be unique for the network number.
ネットワーク・ナンバーに、ノード番号はユニークであるに違いありません。
The sender of the Configure-Request states which node number is
desired. A node number specified as zero in a Configure-Request
shall be interpreted as requesting the peer to specify another
value in a Configure-Nak. A node number specified as zero in a
Configure-Ack shall be interpreted as agreement that no value
exists.
Configure-要求の送付者は、どのノード番号が望まれているかを述べます。 Configure-Nakで別の値を指定するよう同輩に要求しながら、ゼロとしてConfigure-要求で指定されたノード番号は解釈されるものとします。 Configure-Ackのゼロが値が全く存在していないという協定として解釈されるものとするので、ノード番号は指定しました。
If negotiation about the peer node number is required, and the
peer did not provide the option in its Configure-Request, the
option can be appended to a Configure-Nak. The value of the node
number given MUST be acceptable as the peer IPX-Node-Number, or
同輩ノード番号に関する交渉が必要であり、同輩がConfigure-要求におけるオプションを提供しなかったなら、オプションをConfigure-Nakに追加できます。 または与えられたノード番号の値が同輩IPXノード番号として許容できるに違いない。
Simpson [Page 8] RFC 1552 PPP IPXCP December 1993
シンプソン[8ページ]RFC1552ppp IPXCP1993年12月
indicate with a zero value that the peer provide the information.
ゼロで、同輩が情報を提供するのを評価するように示してください。
By default, no node number is assigned to the link (the node
number is zero). There is no need for a node number if the
interface is not used by a routing protocol.
デフォルトで、ノード番号は全くリンクに割り当てられません(ノード番号はゼロです)。 インタフェースがルーティング・プロトコルによって使用されないなら、ノード番号の必要は全くありません。
This is a Desired Parameter when the implementation is operating
as an end-system. However, when the node number has been
statically configured, this option SHOULD NOT be negotiated unless
requested by the peer.
実装がエンドシステムとして作動しているとき、これはDesired Parameterです。 ノード番号が静的に構成されたときのこれがどのようにSHOULD NOTにゆだねても、同輩によって要求されない場合、交渉されてください。
Any IPX-WAN packets received MUST supercede information negotiated
in this option.
パケットが受けたどんなIPX-WANもこのオプションで交渉されたsupercede情報がそうしなければなりません。
A summary of the IPX-Node-Number Configuration Option format is
shown below. The fields are transmitted from left to right.
IPXノード番号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 | IPX-Node-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPX-Node-Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| IPX-ノード番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX-ノード番号(cont。) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2
2
Length
長さ
8
8
IPX-Node-Number
IPX-ノード番号
The six octet IPX-Node-Number is the desired local IPX node number
of the sender of the Configure-Request.
6八重奏IPXノード番号はConfigure-要求の送付者の必要な地方のIPXノード番号です。
3.3 IPX-Compression-Protocol
3.3 IPX圧縮プロトコル
Description
記述
This Configuration Option provides a way to negotiate the use of a
specific compression protocol. By default, compression is not
enabled.
このConfiguration Optionは特定の圧縮プロトコルの使用を交渉する方法を提供します。 デフォルトで、圧縮は可能にされません。
The sender of this Configuration Option indicates that it can
receive packets with the specified compression technique. A
このConfiguration Optionの送付者は、指定された圧縮のテクニックでパケットを受けることができるのを示します。 A
Simpson [Page 9] RFC 1552 PPP IPXCP December 1993
シンプソン[9ページ]RFC1552ppp IPXCP1993年12月
Configure-Ack MAY obligate the peer to send such packets,
depending on the protocol negotiated.
Ackを構成している5月は、交渉されたプロトコルによって、同輩がそのようなパケットを送るのを義務付けます。
Information negotiated in this option MUST supercede any IPX-WAN
packets received, since IPX-WAN packets could be affected by the
compression technique.
このオプションで交渉された情報はIPX-WANパケットが圧縮のテクニックで影響を受けることができるでしょう、したがって、どんなIPX-WANパケットも受けたsupercedeがそうしなければなりません。
A summary of the IPX-Compression-Protocol Configuration Option
format is shown below. The fields are transmitted from left to
right.
IPX圧縮プロトコル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 | IPX-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| IPX圧縮プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
3
3
Length
長さ
>= 4
>= 4
IPX-Compression-Protocol
IPX圧縮プロトコル
The IPX-Compression-Protocol field is two octets and indicates the compression protocol desired. Odd values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. Even values are used when the compression protocol is interleaved with IPX packets.
IPX圧縮プロトコル分野は、2つの八重奏であり、圧縮プロトコルが望んでいたのを示します。 この分野への変な値はその同じ圧縮のためのPPP Data Link Layerプロトコル分野値が議定書を作るのといつも同じです。 圧縮プロトコルがIPXパケットではさみ込まれるとき、値さえ使用されています。
Up-to-date values of the IPX-Compression-Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows:
IPX圧縮プロトコル分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
0002 Telebit Compressed IPX
0235 Shiva Compressed NCP/IPX
0002テレビットはIPX0235シバ神のために圧縮されたNCP/IPXを圧縮しました。
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the particular compression protocol.
Data分野は、ゼロか、より多くの八重奏であり、特定の圧縮プロトコルで決定するように追加データを含んでいます。
Simpson [Page 10] RFC 1552 PPP IPXCP December 1993
シンプソン[10ページ]RFC1552ppp IPXCP1993年12月
3.4 IPX-Routing-Protocol
3.4 IPX-ルーティング・プロトコル
Description
記述
This Configuration Option provides a way to negotiate the use of a
specific routing protocol (or no routing protocol, if desired).
The sender of this option is specifying that it wishes to receive
information of the specified routing protocol. Multiple protocols
MAY be requested by sending multiple IPX-Routing-Protocol
Configuration Options. The "no routing protocol required" value
is mutually exclusive with other values.
このConfiguration Optionは特定のルーティング・プロトコル(または、望まれているなら、プロトコルを発送しない)の使用を交渉する方法を提供します。 このオプションの送付者は、指定されたルーティング・プロトコルの情報を受け取りたがっていると指定しています。 複数のプロトコルが、複数のIPXルート設定プロトコルConfiguration Optionsを送ることによって、要求されているかもしれません。 「どんなルーティング・プロトコルも必要でない」という値が互いに他の値の唯一です。
By default, Novell's combination of Routing Information Protocol
(RIP) and Server Advertising Protocol (SAP) is expected.
デフォルトで、ノベルのルーティング情報プロトコル(RIP)とServer Advertisingプロトコル(SAP)の組み合わせは予想されます。
This is a Desired Parameter when the implementation is operating
as an end-system, to indicate that no routing protocol is
necessary.
実装がどんなルーティング・プロトコルも必要でないことを示すためにエンドシステムとして作動しているとき、これがDesired Parameterです。
Any IPX-WAN packets received MAY add to information negotiated in
this option.
パケットが受けたどんなIPX-WANもこのオプションで交渉された情報に加えるかもしれません。
A summary of the IPX-Routing-Protocol Configuration Option format is
shown below. The fields are transmitted from left to right.
IPXルート設定プロトコル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 | IPX-Routing-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| IPX-ルーティング・プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
4
4
Length
長さ
>= 4
>= 4
IPX-Routing-Protocol
IPX-ルーティング・プロトコル
The IPX-Routing-Protocol field is two octets and indicates the
type of Routing-Protocol desired. This two octet quantity is sent
most significant octet first.
IPXルート設定プロトコル分野は、2つの八重奏であり、ルート設定プロトコルのタイプが望んでいたのを示します。 最初に、この2八重奏量に最も重要な八重奏を送ります。
Up-to-date values of the IPX-Routing-Protocol field are specified
IPXルート設定プロトコル分野の最新の値は指定されます。
Simpson [Page 11] RFC 1552 PPP IPXCP December 1993
シンプソン[11ページ]RFC1552ppp IPXCP1993年12月
in the most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows:
最新の「規定番号」RFC[2]で。 現行価値は以下の通り割り当てられます:
Value Protocol
値のプロトコル
0 No routing protocol required
1 RESERVED
2 Novell RIP/SAP required
4 Novell NLSP required
0 どんなルーティング・プロトコルもRIP/SAPの必要な4ノベルNLSPが必要とした1RESERVED2のノベルを必要としませんでした。
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the routing protocol indicated in the Routing-
Protocol field.
Data分野は、ルート設定プロトコル分野で示されたルーティング・プロトコルで決定するようにゼロか、より多くの八重奏であり、追加データを含んでいます。
3.5 IPX-Router-Name
3.5 IPXルータ名
Description
記述
This Configuration Option provides a way to convey information
about the IPX server name.
このConfiguration OptionはIPXサーバー名に関して情報を伝達する方法を提供します。
The nature of this option is advisory only. It is provided as a
means of improving the end system's ability to provide a simple
user interface. This option MUST NOT be included in a Configure-
Nak.
このオプションの本質は状況報告専用です。 簡単なユーザーインタフェースを提供するエンドシステムの性能を改良する手段としてそれを提供します。 Configure- Nakにこのオプションを含んではいけません。
A summary of the IPX-Router-Name Option format is shown below. The
fields are transmitted from left to right.
IPXルータ名の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 | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 命名します。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5
5
Length
長さ
>= 3
>= 3
Simpson [Page 12] RFC 1552 PPP IPXCP December 1993
シンプソン[12ページ]RFC1552ppp IPXCP1993年12月
Name
名前
This field contains the name of the IPX entity on this end of the
link. The symbolic name should be between 1 and 47 ASCII
characters in length, containing the characters 'A' through 'Z',
underscore (_), hyphen (-) and "at" sign (@). The length of the
name is bounded by the option length.
この分野はリンクのこの端にIPX実体の名前を含んでいます。 英字名は長さが1〜47人のASCII文字であるべきです、キャラクタ''から'Z'、強調(_)、ハイフン(-)、および“at"サイン(@)を含んでいて。 オプションの長さに従って、存在という名前の長さはバウンドしました。
On reception, the name SHOULD be padded to 48 characters using the
NUL character. Those readers familiar with NetWare 3.x servers
will realize that this is equivalent to the file server name.
レセプション、存在というNULキャラクタを使用することで48のキャラクタに水増しされた名前SHOULDに関して。 NetWare3.xサーバに詳しいそれらの読者は、これがファイルサーバー名に同等であるとわかるでしょう。
3.6 IPX-Configuration-Complete
3.6、IPX構成完全
Description
記述
This Configuration Option provides a way to indicate that all
implementation-dependent Desired Parameters are satisfied. It is
provided as a means of detecting when convergence will occur in a
heterogeneous environment.
このConfiguration Optionはすべての実装依存するDesired Parametersが満足しているのを示す方法を提供します。 集合がいつ異機種混在環境で起こるかを検出する手段としてそれを提供します。
This option SHOULD be included in a Configure-Request when the
combination of statically configured parameters and offered
Configuration Options will result in successful configuration.
静的に構成されたパラメタの組み合わせであるときに、Configure-要求で含められていて、Configuration Optionsが提供されたこのオプションSHOULDはうまくいっている構成をもたらすでしょう。
The nature of this option is advisory only. This option MUST NOT
be included in a Configure-Nak.
このオプションの本質は状況報告専用です。 Configure-Nakにこのオプションを含んではいけません。
Implementation Note: An implementation which does not support
IPX-WAN can immediately detect that link setup will not be
successful when a Desired Parameter is unknown, if this option is
not present in the peer's Configure-Request or is Rejected by the
peer. This avoids timeout delays.
実現注意: Desired Parameterが未知であるときに、IPX-WANがすぐに検出できないどんなサポートにもそのリンクセットアップをする実現はうまくいかないでしょう、このオプションが同輩のConfigure-要求に存在していないか、同輩によるRejectedであるなら。 これはタイムアウト遅れを避けます。
An implementation which supports IPX-WAN may improve link setup
time by skipping IPX-WAN entirely when this option has been Ack'd
in both directions.
IPX-WANを支持する実現はこのオプションがAckであるIPX-WANを完全にスキップするのによる準備時間が改良するリンクを両方の方向に改良するかもしれません。
However, it is perfectly acceptable to complete configuration
without including this option. An implementation which includes
the entire panoply of configuration options and IPX- WAN SHOULD
interoperate with an implementation which does not support IPX-WAN
nor any configuration options (including this one), as long as the
Desired Parameters are satisfied by default or hand configuration.
しかしながら、このオプションを含んでいなくて構成を完成するのは完全に許容できます。 設定オプションの全体のよろいかぶとを含んでいる実現とIPX WAN SHOULDはサポートIPX-WANかどんな設定オプションでないもする実現で共同利用します(これを含んでいて)、Desired Parametersがデフォルトで満たされているか、または構成を手渡す限り。
A summary of the IPX-Configuration-Complete Option format is shown
below. The fields are transmitted from left to right.
要約、IPX構成完全である、Option書式は以下に示されます。 野原は左から右まで伝えられます。
Simpson [Page 13] RFC 1552 PPP IPXCP December 1993
シンプソン[13ページ]RFC1552ppp IPXCP1993年12月
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6
6
Length
長さ
2
2
APPENDIX A. Link Delay and Throughput
付録A.リンク遅れとスループット
There has been some concern over correctly estimating the link delay (in 55 millisecond ticks) used by Novell routing protocols.
正しくノベルルーティング・プロトコルによって使用されるリンク遅れ(55ミリセカンドのカチカチする音における)を見積もることに関する何らかの心配がありました。
IPX-WAN uses its Timer Request and Reply for this purpose. The measured delay is multiplied by a factor of 6, because the measurement is done during initialization of the link, and does not reflect actual loading.
IPX-WANはこのためにそのTimer RequestとReplyを使用します。 6の要素は測定遅れに掛けられます、測定がリンクの初期化の間、して、実際のローディングを反映しないので。
The delay is better measured using the PPP LCP Echo facility, by inserting a timestamp in the data part of the Request, and comparing it with the same timer when the reply returns. This method could be used to periodically re-evaluate the actual round trip delay as link and system loads change. The echo packet size SHOULD be 576, to match the default IPX packet size.
回答が戻るとき、遅れは、Requestのデータ部分でタイムスタンプを挿入することによってPPP LCP Echo施設を使用することで測定されて、同じタイマとそれを比べながら、より良いです。 リンクとシステム・ロードが変化するとき定期的に実際の周遊旅行遅れを再評価するのにこの方法を使用できました。 パケットサイズSHOULDを反響してください。デフォルトIPXパケットサイズを合わせるためには576になってください。
In the absence of such dynamic measurements, empirical evidence has shown the following to be sufficient:
そのような動的測定がないとき、実証的証拠は、以下が十分であることを示しました:
2,400 bps 134 ticks
14,400 bps 21 ticks
57,600 bps 5 ticks
> 1 Mbps 1 tick
2,400 ビーピーエス134カチカチする音14,400ビーピーエス21はビーピーエス5ダニ>1Mbps1がカチカチと音を立てる5万7600のカチカチと音を立てます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Simpson [Page 14] RFC 1552 PPP IPXCP December 1993
シンプソン[14ページ]RFC1552ppp IPXCP1993年12月
References
参照
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548,
Daydreamer, December 1993.
[1] シンプソン、W.、「二地点間プロトコル(ppp)」、RFC1548、空想家、1993年12月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[3] Novell Inc., "NetWare System Interface Technical Overview",
Novell Part Number 883-001143-001.
[3] ノベル株式会社、「NetWareのシステム・インタフェースの技術的な概観」、ノベル部品番号883-001143-001。
[4] Allen, M., "Novell IPX Over Various WAN Media", RFC 1551,
Novell Inc., December 1993.
[4] アレン、M.、「様々な青白いメディアの上のノベルIPX」、RFC1551、ノベル株式会社、1993年12月。
[5] Mathu, S., and M. Lewis, "Compressing IPX Headers Over WAN
Media (CIPX)", RFC 1553, Telebit Corporation, December 1993.
[5]Mathu、S.、およびM.ルイス、「青白いメディア(CIPX)の上にIPXヘッダーを圧縮します」、RFC1553、テレビット社、1993年12月。
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)によって製作された前のドキュメントから本書では抜粋されます。
This document is derivative of drafts written by the following people. Many thanks for their work, and for taking an initial stab at the protocol:
このドキュメントは以下の人々によって書かれた草稿で派生しています。 彼らの仕事と、プロトコルで初期の一刺しをかけてくださってありがとうございます:
Michael Allen (mallen@novell.com)
Dave McCool (dave@shiva.com)
Robert D Vincent (bert@shiva.com)
Marty Del Vecchio (marty@shiva.com)
マイケル・アレン( mallen@novell.com )デーヴMcCool( dave@shiva.com )ロバート・Dヴィンセント( bert@shiva.com )・マーティ・デル・ヴェッキョ( marty@shiva.com )
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California, 93111
Driveサンタバーバラ、フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollayカリフォルニア 93111
EMail: fbaker@acc.com
メール: fbaker@acc.com
Simpson [Page 15] RFC 1552 PPP IPXCP December 1993
シンプソン[15ページ]RFC1552ppp IPXCP1993年12月
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6205
P O Box6205イーストランシング、Services MI48826-6205に相談するウィリアムアレンシンプソン空想家コンピュータシステムズ
EMail: Bill.Simpson@um.cc.umich.edu
メール: Bill.Simpson@um.cc.umich.edu
Simpson [Page 16]
シンプソン[16ページ]
一覧
スポンサーリンク
