RFC1132 日本語訳
1132 Standard for the transmission of 802.2 packets over IPX networks.L.J. McLaughlin. November 1989. (Format: TXT=7902 bytes) (Also STD0049) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. McLaughlin III Request for Comments: 1132 The Wollongong Group November 1989
コメントを求めるワーキンググループL.マクラフリンIII要求をネットワークでつないでください: 1132 ウォロンゴングループ1989年11月
A Standard for the Transmission of 802.2 Packets over IPX Networks
IPXネットワークの上の802.2のパケットのトランスミッションの規格
Status of this Memo
このMemoの状態
This document specifies a standard method of encapsulating 802.2 [1] packets on networks supporting Novell's Internet Packet Exchange Protocol [2] (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges. Distribution of this memo is unlimited.
このドキュメントはノベルのインターネットPacket Exchangeがプロトコル[2]である(IPX)とサポートしながらネットワークで802.2[1]パケットをカプセルに入れる標準方法を指定します。 それはIPXネットワークの上でインターネットパケットのトランスミッションを詳しく述べる以前のドキュメントを時代遅れにします。 それはIPXの上と、そして、IPXブリッジを通したパケットのトランスミッションに関して複数のネットワーク・プロトコルの送信を考慮するという点においてこれらの以前のドキュメントと異なっています。 このメモの分配は無制限です。
Introduction
序論
The goal of this specification is to allow compatible and interoperable implementations for transmitting Internet packets such as the Internet Protocol [3] (IP) and Address Resolution Protocol [4] (ARP) as well as the Connectionless-mode Network Protocol [5] (CLNP) over IPX networks.
この仕様の目標は、IPXネットワークの上にインターネットプロトコル[3](IP)やAddress Resolutionプロトコル[4](ARP)などのインターネットパケットを伝わるためのコンパチブル、そして、共同利用できる実装に許容して、Networkプロトコル[5](CLNP)をConnectionless-モードに許容することです。
IPX is a proprietary standard developed by Novell derived from Xerox's Internet Datagram Protocol [6] (IDP). Defining the encapsulation of the IEEE 802.2 Data Link Layer Standard over IPX in terms of yet another 802.X Physical Layer standard allows for the transmission of IP Datagrams as described in RFC 1042 [7]. This document will focus on the implementation of that RFC over IPX networks.
IPXはゼロックスのインターネットデータグラムプロトコル[6](IDP)から得られたノベルによって開発された独占規格です。 IPXの上でさらに別の802.X Physical Layer規格に関してIEEE802.2Data Link Layer Standardのカプセル化を定義すると、IPデータグラムの送信はRFC1042[7]で説明されるように考慮されます。 このドキュメントはIPXネットワークの上でそのRFCの実装に焦点を合わせるでしょう。
Description
記述
In general, this specification allows IPX networks to be used to support any network protocol which can use the IEEE 802.2 Data Link Layer specification.
一般に、この仕様は、IPXネットワークがIEEE802.2Data Link Layer仕様を使用できるどんなネットワーク・プロトコルもサポートするのに使用されるのを許容します。
More specifically, IPX networks may be used to support IP networks and subnetworks of any class. By encapsulating IP datagrams within IPX datagrams and assigning IP numbers to the hosts on a IPX network, IP-based applications are supported on these hosts. The addition of an IP Gateway capable of encapsulating IP packets within 802.IPX datagrams would allow those hosts on an IPX network to communicate with the Internet.
より明確に、IPXネットワークは、IPがどんなクラスのネットワークとサブネットワークであるともサポートするのに使用されるかもしれません。 IPXデータグラムの中にIPがデータグラムであるとカプセル化して、IPXネットワークでIP番号をホストに割り当てることによって、IPベースのアプリケーションはこれらのホストの上でサポートされます。 802.IPXデータグラムの中にIPがパケットであるとカプセル化することができるIPゲートウェイの参加で、IPXネットワークのそれらのホストはインターネットで交信できるでしょう。
McLaughlin [Page 1] RFC 1132 802.2 Packets over IPX Networks November 1989
IPXネットワーク1989年11月の上のマクラフリン[1ページ]RFC1132 802.2パケット
Maximum Transmission Unit
マキシマム・トランスミッション・ユニット
The maximum data size of a IPX datagram is 546 bytes. As the combined size of the 802.2 LLC and SNAP headers is 8 bytes, this results in a Maximum Transmission Unit (MTU) of 538 bytes.
IPXデータグラムの最大のデータサイズは546バイトです。 802.2LLCとSNAPヘッダーの結合したサイズが8バイトであるときに、これは538バイトのMaximum Transmission Unit(MTU)をもたらします。
Address Mappings
アドレス・マッピング
The mapping of Internet Protocol addresses to 802.IPX addresses is done using the Address Resolution Protocol in the same fashion as with other IEEE 802.X physical addresses. However, the length of an 802.IPX physical address is 10 bytes rather than 2 or 6. This 10 byte physical address consists of the 4 bytes of the IPX network address followed by the 6 bytes of the IPX node address.
802.IPXアドレスへのIPアドレスに関するマッピングは他のIEEE 802.X物理アドレスのように同じファッションでAddress Resolutionプロトコルを使用し終わっています。 しかしながら、802.IPX物理アドレスの長さは2か6よりむしろ10バイトです。 この10バイトの物理アドレスはIPXノードアドレスの6バイトがあとに続いたIPXネットワーク・アドレスの4バイトから成ります。
Byte Order
バイトオーダー
The byte transmission order is "big-endian" [8].
バイトトランスミッション命令は「ビッグエンディアン」[8]です。
Broadcast Addresses
放送演説
IPX packets may be broadcast by setting the IPX header Packet Type field to 0x14, the Destination Network field to the local network number, the the Destination Node field to 0xffffff, and the Immediate Address field of the IPX Event Control Block to 0xffffff.
IPXパケットは、0×14へのIPXヘッダーPacket Type分野、企業内情報通信網番号へのDestination Network分野、0xffffffへのDestination Node分野、および0xffffffへのIPX Event Control BlockのImmediate Address分野を設定することによって、放送されるかもしれません。
Unicast Addresses
ユニキャストアドレス
IPX packets may be unicast by setting the IPX header Packet Type field to 0x04, the Destination Network field and Destination Node field to those values found by address resolution, and the Immediate Address field of the IPX Event Control Block to the physical address of the destination node or the appropriate IPX bridge.
IPXヘッダーPacket Type分野を0×04に設定することによって、IPXパケットはユニキャストであるかもしれません、とそれらの値へのDestination Network分野とDestination Node分野によって、アドレス解決、およびIPX Event Control BlockのImmediate Address分野のそばで目的地ノードか適切なIPXブリッジの物理アドレスにわかりました。
Checksum
チェックサム
Like most IPX applications, this specification does not use IPX checksum.
ほとんどのIPXアプリケーションのように、この仕様はIPXチェックサムを使用しません。
Reserved values
予約された値
The IPX socket 0x8060 has been reserved by Novell for the implementation of this protocol.
IPXソケット0x8060はこのプロトコルの実装のためにノベルによって予約されました。
Implementation
実装
The encapsulation of Internet packets within IPX networks has proved to be quite useful. Because the IPX interface insulates knowledge of
IPXネットワークの中のインターネットパケットのカプセル化はかなり役に立つと判明しました。 IPXインタフェースは知識を絶縁します。
McLaughlin [Page 2] RFC 1132 802.2 Packets over IPX Networks November 1989
IPXネットワーク1989年11月の上のマクラフリン[2ページ]RFC1132 802.2パケット
the physical layer from an application, 802.2 over IPX networks work over any physical medium. A typical IP over IPX packet is shown below:
アプリケーションからの物理的な層であり、IPXネットワークの上の802.2はどんな物理的な媒体の上でも働いています。 IPXパケットの上の典型的なIPは以下で見せられます:
-------------------- N bytes | physical header | |------------------| 30 bytes | IPX header | |------------------| 8 bytes | 802.2 header | |------------------| usually 20 bytes | IP header | |------------------| usually 20 bytes | TCP header | |------------------| up to 498 bytes | TCP data | --------------------
-------------------- Nバイト| 物理的なヘッダー| |------------------| 30バイト| IPXヘッダー| |------------------| 8バイト| 802.2 ヘッダー| |------------------| 通常20バイト| IPヘッダー| |------------------| 通常20バイト| TCPヘッダー| |------------------| 最大498バイト| TCPデータ| --------------------
On workstations supporting an IPX programming interface, implementation of this specification has proved fairly straightforward. The only change which was done was to modify the existing address resolution protocol code to allow for cache entries larger than the hardware address length. This was done to allow room for the immediate address of a possible intervening IPX bridge in addition to the destination node and network addresses to be associated with a given IP address.
IPXがプログラミングインターフェースであるとサポートするワークステーションの上では、この仕様の実装はかなり簡単であると判明しました。 行われた唯一の変化が、ハードウェア・アドレスの長さより大きいキャッシュエントリーを考慮するように既存のアドレス解決プロトコルコードを変更することになっていました。 目的地ノードとネットワーク・アドレスに加えた可能な介入しているIPXブリッジの即値アドレスが与えられたIPアドレスに関連している余地を許容するためにこれをしました。
Thus far, no implementations have been attempted on systems which do not already support an IPX programming interface (e.g., a dedicated router) though a few implementation details can be noted. First, obviously any such implementation will have to distinguish IPX packets from other packets; this process will be media dependent. Second, note that no unicast packet is ever sent from host1 to host2 without a prior broadcast packet from host2 to host1. Thus, the immediate address of a possible intervening IPX bridge between host1 and host2 can be learned from the physical header of that prior broadcast packet. Third, any such implementation will need to discover the local IPX network number from a Novell bridge or file server. The mechanisms for doing this exist but documentation for their use is not commonly available.
これまでのところ、実装は全くいくつかの実装の詳細に注意できますが、IPXがプログラミングインターフェース(例えば、ひたむきなルータ)であると既にサポートしないシステムの上で試みられていません。 まず最初に、明らかにどんなそのような実装も他のパケットとIPXパケットを区別しなければならないでしょう。 このプロセスはメディア扶養家族になるでしょう。 2番目に、ユニキャストパケットが全く今までに先の放送パケットなしでhost1からhost2にhost2からhost1まで送られないことに注意してください。 したがって、その先の放送パケットの物理的なヘッダーからhost1とhost2の間の可能な介入しているIPXブリッジの即値アドレスについて学習できます。 3番目に、どんなそのような実装も、ノベルブリッジかファイルサーバーから地方のIPXネットワーク・ナンバーを発見する必要があるでしょう。これをするためのメカニズムは存在していますが、彼らの使用のためのドキュメンテーションは一般的に利用可能ではありません。
References
参照
[1] IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, 1985.
[1] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「論理的なリンク制御」、IEEE、ニューヨーク1985。
[2] Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange Protocol (IPX) with Asynchronous Event Scheduler (AES)", October
[2] ノベルInc.、「非同期的なイベントスケジューラ(AES)がある高度なNetWare V2.1インターネットワークパケット交換プロトコル(IPX)」10月
McLaughlin [Page 3] RFC 1132 802.2 Packets over IPX Networks November 1989
IPXネットワーク1989年11月の上のマクラフリン[3ページ]RFC1132 802.2パケット
1986.
1986.
[3] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981.
[3] ポステル、J.、「インターネットプロトコル」、RFC-791、科学が1981年9月に設けるUSC/情報。
[4] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
[4] プラマー、D.、「イーサネットアドレス解決プロトコル」、RFC-826、1982年11月。
[5] ISO DIS 8473: "Information Processing Systems - Data Communications - Protocol for Providing the Connectionless-mode Network Service".
[5] ISOは8473をけなします: 「情報処理システム(データ通信)はコネクションレスなモードネットワーク・サービスを提供するために議定書を作ります。」
[6] Xerox Corporation, "Xerox Network Systems Architecture", XNSG 068504, April 1985.
[6]ゼロックス社、「ゼロックスネットワーク・システムアーキテクチャ」、XNSG068504、1985年4月。
[7] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information Sciences Institute, February 1988.
[7] ポステル、J.、およびJ.レイノルズ、「IEEE802ネットワークの上のIPデータグラムの送信の規格」、RFC-1042(科学が1988年2月に設けるUSC/情報)。
[8] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, October 1981.
[8] D. コーエン、コンピュータ、IEEE、「平和のための聖戦と請願」の1981年10月。
Security Considerations
セキュリティ問題
Security issues are not addressed in this memo.
安全保障問題はこのメモで扱われません。
Author's Address:
作者のアドレス:
Leo J. McLaughlin III The Wollongong Group 1129 San Antonio Road Palo Alto, CA 94303
レオJ.マクラフリンIIIウォロンゴングループ1129サンアントニオRoadパロアルト、カリフォルニア 94303
Phone: (415) 962-7100
以下に電話をしてください。 (415) 962-7100
EMail: ljm@TWG.COM
メール: ljm@TWG.COM
McLaughlin [Page 4]
マクラフリン[4ページ]
一覧
スポンサーリンク