RFC1234 日本語訳
1234 Tunneling IPX traffic through IP networks. D. Provan. June 1991. (Format: TXT=12333 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Provan
Request for Comments: 1234 Novell, Inc.
June 1991
Provanがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1234 ノベルInc.1991年6月
Tunneling IPX Traffic through IP Networks
IPネットワークを通してIPXトラフィックにトンネルを堀ります。
Status of this Memo
このMemoの状態
This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはIPXトラフィックがIPインターネットの向こう側に移動できるようにUDPパケットの中でIPXにデータグラムをカプセル化するメソッドを説明します。 このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Introduction
序論
Internet Packet eXchange protocol (IPX) is the internetwork protocol used by Novell's NetWare protocol suite. For the purposes of this paper, IPX is functionally equivalent to the Internet Datagram Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite [1]. This memo describes a method of encapsulating IPX datagrams within UDP packets [2] so that IPX traffic can travel across an IP internet [3].
インターネットPacket eXchangeプロトコル(IPX)はノベルのNetWareプロトコル群によって使用されるインターネットワークプロトコルです。 この紙の目的のために、IPXはゼロックスNetwork Systems(XNS)プロトコル群[1]からのインターネットデータグラムプロトコル(IDP)に機能上同等です。 このメモは[2] IPXトラフィックがIPインターネット[3]の向こう側に移動できるようにUDPパケットの中でIPXにデータグラムをカプセル化するメソッドを説明します。
This RFC allows an IPX implementation to view an IP internet as a single IPX network. An implementation of this memo will encapsulate IPX datagrams in UDP packets in the same way any hardware implementation might encapsulate IPX datagrams in that hardware's frames. IPX networks can be connected thusly across internets that carry only IP traffic.
このRFCはIPX実装にただ一つのIPXネットワークであるとIPインターネットをみなさせます。 このメモの実装はUDPパケットでどんなハードウェア実装もそのハードウェアのフレームでIPXにデータグラムをカプセル化するかもしれない同じようにIPXにデータグラムをカプセル化するでしょう。 IPトラフィックだけを運ぶインターネットの向こう側にこのようにしてIPXネットワークを接続できます。
Packet Format
パケット・フォーマット
Each IPX datagram is carried in the data portion of a UDP packet. All IP and UDP fields are set normally. Both the source and the destination ports in the UDP packet should be set to the UDP port value allocated by the Internet Assigned Numbers Authority for the implementation of this encapsulation method.
それぞれのIPXデータグラムはUDPパケットのデータ部で運ばれます。 通常、すべてのIPとUDP分野は設定されます。 UDPパケットのソースと仕向港の両方がこのカプセル化メソッドの実装のためにインターネットAssigned民数記Authorityによって割り当てられたUDPポート価値へのセットであるべきです。
As with any UDP application, the transmitting party has the option of avoiding the overhead of the checksum by setting the UDP checksum to zero. Since IPX implementations never use the IPX checksum to guard IPX packets from damage, UDP checksumming is highly recommended for IPX encapsulation.
どんなUDPアプリケーションのようにも、伝えるパーティーにはUDPチェックサムをゼロに設定することによってチェックサムのオーバーヘッドを避けるオプションがあります。 IPX実装が損害からIPXパケットを警備するのにIPXチェックサムを決して使用しないので、UDP checksummingはIPXカプセル化のために強く推薦されます。
Provan [Page 1] RFC 1234 IPX on IP June 1991
IP1991年6月のProvan[1ページ]RFC1234IPX
+---------------------+------------+-------------------------------+ | | | | | | IP Header | UDP Header | IPX Header | IPX packet data | | (20 or more octets) | (8 octets) | (30 octets) | | | | | | | +---------------------+------------+-------------------------------+
+---------------------+------------+-------------------------------+ | | | | | | IPヘッダー| UDPヘッダー| IPXヘッダー| IPXパケットデータ| | (20以上の八重奏) | (8つの八重奏) | (30の八重奏) | | | | | | | +---------------------+------------+-------------------------------+
Figure 1: An IPX packet carried as data in a UDP packet.
図1: IPXパケットはデータとしてUDPパケットで運ばれました。
Reserved Packets
予約されたパケット
The first two octets of the IPX header contain the IPX checksum. IPX packets are never sent with a checksum, so every IPX header begins with two octets of FF hex. Implementations of this encapsulation scheme should ignore packets with any other value in the first two octets immediately following the UDP header. Other values are reserved for possible future enhancements to this encapsulation protocol.
IPXヘッダーの最初の2つの八重奏がIPXチェックサムを含んでいます。 チェックサムと共にIPXパケットを決して送らないので、すべてのIPXヘッダーがFF十六進法の2つの八重奏で始まります。 このカプセル化体系の実装は最初の2つの八重奏におけるいかなる他の値もすぐにUDPヘッダーに続いているパケットを無視するべきです。 他の値は可能な今後の増進のためにこのカプセル化プロトコルに予約されます。
Unicast Address Mappings
ユニキャストアドレス・マッピング
IPX addresses consist of a four octet network number and a six octet host number. IPX uses the network number to route each packet through the IPX internet to the destination network. Once the packet arrives at the destination network, IPX uses the six octet host number as the hardware address on that network.
IPXアドレスは4八重奏ネットワーク・ナンバーと6八重奏ホスト番号から成ります。 IPXは、IPXインターネットを通して各パケットを送信先ネットワークに発送するのにネットワーク・ナンバーを使用します。 パケットがいったん送信先ネットワークに到着すると、IPXはそのネットワークに関するハードウェア・アドレスとして6八重奏ホスト番号を使用します。
Host numbers are also exchanged in the IPX headers of packets of IPX's Routing Information Protocol (RIP). This supplies end nodes and routers alike with the hardware address information required for forwarding packets across intermediate networks on the way towards the destination networks.
また、IPXのルーティング情報プロトコル(RIP)のパケットのIPXヘッダーでホスト番号を交換します。 これは同じく推進パケットに途中で中間ネットワークの向こう側に必要であったハードウェアアドレス情報をエンドノードとルータに送信先ネットワークに向かって供給します。
For implementations of this memo, the first two octets of the host number will always be zero and the last four octets will be the node's four octet IP address. This makes address mapping trivial for unicast transmissions: the first two octets of the host number are discarded, leaving the normal four octet IP address. The encapsulation code should use this IP address as the destination address of the UDP/IP tunnel packet.
このメモの実装のために、ホスト番号の最初の2つの八重奏がいつもゼロになるでしょう、そして、最後の4つの八重奏が4八重奏IPアドレスになるでしょうノードの。 これで、アドレス・マッピングはユニキャスト送信に些細になります: 正常な4八重奏IPアドレスを出て、ホスト番号の最初の2つの八重奏が捨てられます。 カプセル化コードはUDP/IPトンネルパケットの送付先アドレスとしてこのIPアドレスを使用するべきです。
Broadcasts between Peer Servers
同輩サーバの間の放送
IPX requires broadcast facilities so that NetWare servers and IPX routers sharing a network can find one another. Since internet-wide IP broadcast is neither appropriate nor available, some other mechanism is required. For this memo, each server and router should maintain a list of the IP addresses of the other IPX servers and
IPXは、ネットワークを共有するNetWareサーバとIPXルータがお互いを見つけることができるように、放送施設を必要とします。 インターネット全体のIP放送が適切でなくて、また利用可能でないので、ある他のメカニズムが必要です。 そしてこのメモに関しては、各サーバとルータが他のIPXサーバのIPアドレスのリストを維持するべきである。
Provan [Page 2] RFC 1234 IPX on IP June 1991
IP1991年6月のProvan[2ページ]RFC1234IPX
routers on the IP internet. I will refer to this list as the "peer list", to individual members as "peers", and to all the peers taken together, including the local node, as the "peer group". When IPX requests a broadcast, the encapsulation implementation simulates the broadcast by transmitting a separate unicast packet to each peer in the peer list.
IPインターネットに関するルータ。 私は「同輩リスト」とこのリストを呼ぶつもりです、「同輩」、および一緒に連れて行かれたすべての同輩の個人会員に、ローカルのノードを含んでいて、「ピアグループ」として。 IPXが放送を要求するとき、カプセル化実装は、同輩リストの各同輩に別々のユニキャストパケットを伝えることによって、放送をシミュレートします。
Because each peer list is constructed by hand, several groups of peers can share the same IP internet without knowing about one another. This differs from a normal IPX network in which all peers would find each other automatically by using the hardware's broadcast facility.
それぞれの同輩リストが手で構成されるので、お互いに関して知らないで、同輩のいくつかのグループが同じIPインターネットを共有できます。 これはすべての同輩が自動的にハードウェアの放送施設を使用することによって互いを見つける正常なIPXネットワークと異なっています。
The list of peers at each node should contain all other peers in the peer group. In most cases, connectivity will suffer if broadcasts from one peer consistently fail to reach some other peer in the group.
各ノードの同輩のリストはピアグループに他のすべての同輩を含むはずです。 多くの場合、1人の同輩からの放送がグループである他の同輩に一貫して届かないと、接続性に苦しむでしょう。
The peer list could be implemented using IP multicast [4], but since multicast facilities are not widely available at this time, no well- known multicast address has been assigned and no implementations using multicast exist. As IP multicast is deployed in IP implementations, it can be used by simply including in the peer list an IP multicast address for IPX servers and routers. The IP multicast address would replace the IP addresses of all peers which will receive IP multicast packets sent from this peer.
マルチキャスト施設がこのとき広く利用可能でないので、よく知られているマルチキャストアドレスは全く割り当てられていません、そして、IPマルチキャスト[4]を使用することで同輩リストを実装することができるでしょうが、マルチキャストを使用する実装が全く存在していません。 IPマルチキャストがIP実装で配布されるとき、IPXサーバとルータに同輩リストに単にIPマルチキャストアドレスを含んでいることによって、それを使用できます。 IPマルチキャストアドレスはこの同輩から送られたIPマルチキャストパケットを受けるすべての同輩のIPアドレスを置き換えるでしょう。
Broadcasts by Clients
クライアントによる放送
Typically, NetWare client nodes do not need to receive broadcasts, so normally NetWare client nodes on the IP internet would not need to be included in the peer lists at the servers.
通常、NetWareクライアントノードは放送、同輩にIPインターネットのNetWareクライアントノードが含まれる必要はないほど通常サーバにおけるリストを受け取る必要はありません。
On the other hand, clients on an IPX network need to send broadcasts in order to locate servers and to discover routes. A client implementation of UDP encapsulation can handle this by having a configured list of the IP addresses of all servers and routers in the peer group running on the IP internetwork. As with the peer list on a server, the client implementation would simulate the broadcast by sending a copy of the packet to each IP address in its list of IPX servers and routers. One of the IP addresses in the list, perhaps the only one, could be a broadcast address or, when available, a multicast address. This allows the client to communicate with members of the peer group without knowing their specific IP addresses.
他方では、IPXネットワークのクライアントは、サーバの場所を見つけるように放送を送って、ルートを発見する必要があります。 UDPカプセル化のクライアント実装は、IPインターネットワークで動きながら、ピアグループですべてのサーバとルータのIPアドレスの構成されたリストを持っていることによって、これを扱うことができます。 同輩リストがサーバにある場合、クライアント実装は、IPXサーバとルータのリストのそれぞれのIPアドレスにパケットのコピーを送ることによって、放送をシミュレートするでしょう。 リストのIPアドレスの1つ(恐らく唯一無二)は、放送演説か利用可能であり、マルチキャストアドレスであるかもしれません。 これで、彼らの特定のIPアドレスを知らないで、クライアントはピアグループのメンバーとコミュニケートできます。
It's important to realize that broadcast packets sent from an IPX client must be able to reach all servers and routers in the server
IPXクライアントから送られた放送パケットがサーバのすべてのサーバとルータに達することができなければならないとわかるのは重要です。
Provan [Page 3] RFC 1234 IPX on IP June 1991
IP1991年6月のProvan[3ページ]RFC1234IPX
peer group. Unlike IP, which has a unicast redirect mechanism, IPX end systems are responsible for discovering routing information by broadcasting a packet requesting a router that can forward packets to the desired destination. If such packets do not tend to reach the entire server peer group, resources in the IPX internet may be visible to an end system, yet unreachable by it.
ピアグループ。 IPと異なって、IPXエンドシステムは必要な目的地にパケットを送ることができるルータを要求するパケットを放送することによってルーティング情報を発見するのに原因となります。IPには、ユニキャストの再直接のメカニズムがあります。 そのようなパケットが、全体のサーバピアグループに達する傾向がないなら、IPXインターネットにおけるリソースはエンドシステムに目に見えるかもしれません、それはまだ手が届きません。
Maximum Transmission Unit
マキシマム・トランスミッション・ユニット
Although larger IPX packets are possible, the standard maximum transmission unit for IPX is 576 octets. Consequently, 576 octets is the recommended default maximum transmission unit for IPX packets being sent with this encapsulation technique. With the eight octet UDP header and the 20 octet IP header, the resulting IP packets will be 604 octets long. Note that this is larger than the 576 octet maximum size IP implementations are required to accept [3]. Any IP implementation supporting this encapsulation technique must be capable of receiving 604 octet IP packets.
より大きいIPXパケットは可能ですが、IPXのための標準のマキシマム・トランスミッション・ユニットは576の八重奏です。 その結果、576の八重奏がこのカプセル化技術で送られるIPXパケットのためのお勧めのデフォルトマキシマム・トランスミッション・ユニットです。 8八重奏UDPヘッダーと20八重奏IPヘッダーと共に、結果として起こるIPパケットは長い間、604の八重奏になるでしょう。 これが576の八重奏最大サイズIP実装が[3]を受け入れるのに必要であるというよりも大きいことに注意してください。 このカプセル化がテクニックであるとサポートするどんなIP実装も604の八重奏IPパケットを受けることができなければなりません。
As improvements in protocols and hardware allow for larger, unfragmented IP transmission units, the 576 octet maximum IPX packet size may become a liability. For this reason, it is recommended that the IPX maximum transmission unit size be configurable in implementations of this memo.
プロトコルとハードウェアにおける改良が、より大きくて、非断片化しているIPトランスミッション単位を考慮するとき、576の八重奏の最大のIPXパケットサイズは責任になるかもしれません。 この理由で、IPXマキシマム・トランスミッション・ユニットサイズがこのメモの実装で構成可能であることは、お勧めです。
Security Issues
安全保障問題
Using a wide-area, general purpose network such as an IP internet in a position normally occupied by physical cabling introduces some security problems not normally encountered in IPX internetworks. Normal media are typically protected physically from outside access; IP internets typically invite outside access.
通常、物理的なケーブリングによって占められた位置のIPインターネットなどの広い領域の、そして、汎用のネットワークを使用すると、通常、IPXインターネットワークで遭遇しないいくつかの警備上の問題が紹介されます。 正常なメディアはアクセスの外から通常物理的に保護されます。 IPインターネットは外のアクセサリーを通常招待します。
The general effect is that the security of the entire IPX internetwork is only as good as the security of the entire IP internet through which it tunnels. The following broad classes of attacks are possible:
一般的効果は全体のIPXインターネットワークのセキュリティが単にそれがトンネルを堀る全体のIPインターネットのセキュリティと同じくらい良いということです。 以下の広いクラスの攻撃は可能です:
1) Unauthorized IPX clients can gain access to resources through
normal access control attacks such as password cracking.
1) 権限のないIPXクライアントはパスワード解析などの通常のアクセス制御攻撃でリソースへのアクセスを得ることができます。
2) Unauthorized IPX gateways can divert IPX traffic to unintended
routes.
2) 権限のないIPXゲートウェイはIPXトラフィックを故意でないルートに紛らすことができます。
3) Unauthorized agents can monitor and manipulate IPX traffic
flowing over physical media used by the IP internet and under
control of the agent.
3) 権限のないエージェントは、IPインターネットによって使用される物理的なメディアの上と、そして、エージェントのコントロールの下で流れるIPXトラフィックを、モニターして、操ることができます。
Provan [Page 4] RFC 1234 IPX on IP June 1991
IP1991年6月のProvan[4ページ]RFC1234IPX
To a large extent, these security risks are typical of the risks facing any other application using an IP internet. They are mentioned here only because IPX is not normally suspicious of its media. IPX network administrators will need to be aware of these additional security risks.
大体において、IPインターネットを使用することでリスクがいかなる他のアプリケーションにも直面することのこれらのセキュリティリスクは典型です。 単にIPXがメディアで通常疑わしげでないので、それらはここに言及されます。 IPXネットワーク管理者は、これらの追加担保リスクを意識している必要があるでしょう。
Assigned Numbers
規定番号
The Internet Assigned Numbers Authority assigns well-known UDP port numbers. It has assigned port number 213 decimal to the IPX encapsulation technique described in this memo [5].
インターネットAssigned民数記Authorityはよく知られるUDPポートナンバーを割り当てます。 それはこのメモ[5]で説明されたIPXカプセル化技術にポートNo.213小数を割り当てました。
Acknowledgements
承認
This encapsulation technique was developed independently by Schneider & Koch and by Novell. I'd like to thank Thomas Ruf of Schneider & Koch for reviewing this memo to confirm its agreement with the Schneider & Koch implementation and also for his other valuable suggestions.
このカプセル化技術はシュナイダーとコッホとノベルによって独自に見いだされました。 このメモを再検討するためのシュナイダーとコッホのトーマスRufがシュナイダーとコッホ実装と彼の他の貴重な提案のためにも協定を確認するのを感謝申し上げます。
References
参照
[1] Xerox, Corp., "Internet Transport Protocols", XSIS 028112, Xerox
Corporation, December 1981.
[1] ゼロックス、社、「インターネットトランスポート・プロトコル」、XSIS028112、ゼロックス社、1981年12月。
[2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[2] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が1980年8月に設けるUSC/情報。
[3] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[3] ポステル、J.、「インターネットプロトコル」、RFC791、DARPA、1981年9月。
[4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[4] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、RFC1112、スタンフォード大学、1989年8月。
[5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1060,
USC/Information Sciences Institute, March 1990.
[5] USC/情報科学が1990年3月に設けるレイノルズ、J.とJ.ポステル、「規定番号」、RFC-1060。
Security Considerations
セキュリティ問題
See the "Security Issues" section above.
「安全保障問題」セクションが上であることを見てください。
Provan [Page 5] RFC 1234 IPX on IP June 1991
IP1991年6月のProvan[5ページ]RFC1234IPX
Author's Address
作者のアドレス
Don Provan Novell, Inc. 2180 Fortune Drive San Jose, California, 95131
Driveサンノゼ、ドンProvanノベルInc.2180Fortuneカリフォルニア 95131
Phone: (408)473-8440
以下に電話をしてください。 (408)473-8440
EMail: donp@Novell.Com
メール: donp@Novell.Com
Provan [Page 6]
Provan[6ページ]
一覧
スポンサーリンク
