RFC1791 日本語訳
1791 TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. April 1995. (Format: TXT=22347 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Sung Request for Comments: 1791 Novell, Inc. Category: Experimental April 1995
コメントを求める要求が歌われた作業部会T.をネットワークでつないでください: 1791年のノベルInc.カテゴリ: 実験的な1995年4月
TCP And UDP Over IPX Networks With Fixed Path MTU
固定経路MTUとのIPXネットワークの上のTCPとUDP
Status of this Memo
このMemoの状態
This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためにExperimentalプロトコルを定義します。 これはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
Internet Engineering Steering Group comment from the Area Director for Transport Services: Please note well that this memo is an individual product of the author. Implementation experience, particularly on the effectiveness of the protocols in dual-stack environments, is needed.
インターネットEngineering Steering GroupはTransport ServicesのためにAreaディレクターからコメントします: このメモはよく作者の個々の製品です。 特にデュアルスタック環境における、プロトコルの有効性では、実装経験が必要です。
1. Introduction
1. 序論
Most of network applications run on some sort of transports. And, if one is to let such applications to run over a foreign network protocol, the simplest way would be to allow the applications' transports to run over that network protocol. For TCP/IP applications, that transport is TCP or UDP. Hence, to let TCP/IP applications run over IPX, we would need to have TCP and UDP run over IPX. And, once TCP and UDP are allowed to run over IPX, all TCP and UDP based applications, such as HTTP for WWW, or NFS, can easily be made to work over IPX networks.
ネットワーク応用の大部分はある種の輸送で動きます。 そして、最も簡単な道は1つが外国ネットワーク・プロトコルをひくためにそのようなアプリケーションをさせるつもりであるなら、アプリケーションの輸送がそのネットワーク・プロトコルをひくのを許容するだろうことです。 TCP/IPアプリケーションのために、その輸送は、TCPかUDPです。 したがって、TCP/IPアプリケーションにIPXをひかせるように、私たちは、TCPとUDPにIPXをひかせる必要があるでしょう。 そして、TCPとUDPがいったんIPXをひくことができると、IPXネットワークの上で働くのを容易にWWW、またはNFSのためのHTTPなどのすべてのTCPとUDPのベースのアプリケーションをすることができます。
DLsw is another example of such applications. As it is a TCP application (and TCP requires IP), the administrator is forced to run IP on his network in order to support DLsw. If the site was an IPX shop, it means that he now must manage IP protocol/addresses in addition to IPX. If TCP could be made to run on IPX, then he would not have to add IP to his repertoire of network protocols to manage.
DLswはそのようなアプリケーションに関する別の例です。 それがTCPアプリケーション(TCPはIPを必要とする)であるので、管理者はDLswをサポートするためにやむを得ず彼のネットワークにIPを経営しています。 サイトがIPX店であったなら、それは、彼が現在IPXに加えたIPプロトコル/アドレスを管理しなければならないことを意味します。 TCPにIPXの上で作業させることができるなら、彼は管理するネットワーク・プロトコルのレパートリーにIPを追加する必要はないでしょうに。
TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX.
TCPとUDPにIPXをひかせることによって、TCP/IPXはTCP/IPアプリケーションにIPXネットワークをひかせます。 そして、このメモはIPXの上で実行しているTCPとUDPにパケット・フォーマットと操作手順を指定します。
Sung [Page 1] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[1ページ]RFC1791TCPとUDP
2. Running UDP Over IPX
2. IPXの上にUDPを実行します。
Since UDP datagrams can be up to 64K octets long, and the size of IPX packet is limited to that of the path MTU, large UDP datagrams must be fragmented. And, since IPX does not support fragmentation, large UDP datagrams must be fragmented before they are passed to IPX. For that purpose, a new protocol called IPXF (IPX Fragmentation layer), is invented. UDP must run on IPXF rather than directly on IPX. IPXF layer is described in section 4.
長い間UDPデータグラムが最大64Kの八重奏であるかもしれなく、IPXパケットのサイズが経路MTUのものに制限されるので、大きいUDPデータグラムを断片化しなければなりません。 そして、IPXが断片化をサポートしないので、それらがIPXに通過される前に大きいUDPデータグラムを断片化しなければなりません。 そのためにIPXF(IPX Fragmentationは層にする)と呼ばれる新しいプロトコルは発明されます。 UDPは直接IPXに関してというよりむしろIPXFで稼働しなければなりません。 IPXF層はセクション4で説明されます。
To IPXF service users, IPXF behaves just like IPX except that IPXF accepts datagram larger than the IPX path MTU. As such, we describe UDP in this section as if it is running on IPX.
IPXFサービス利用者に、そのIPXF以外のIPXが、まさしくデータグラムがIPX経路MTUより大きいと受け入れるようにIPXFは振る舞います。 そういうものとして、まるでそれがIPXの上で作業しているかのように私たちはこのセクションでUDPについて説明します。
UDP must send and receive the packets on IPX/IPXF socket 0x9092. Though it may be possible to send a packet from sockets other than 0x9092, such sockets cannot receive UDP datagram destined to a well known socket 0x9092. Hence, the bidirectional communcation may not be established if a socket other than 0x9092 is used to send UDP datagram. For that reason. UDP/IPX does not allow source sockets other than 0x9092. If a datagram with source socket number other than 0x9092 is received, UDP/IPX should discard the packet silently. (And increment udpInDatagramErr MIB counter if it is instrumented.)
UDPはIPX/IPXFソケット0x9092の上にパケットを送って、受けなければなりません。 0×9092以外のソケットからパケットを送るのが可能であるかもしれませんが、そのようなソケットはよく知られているソケット0x9092に運命づけられたUDPデータグラムを受けることができません。 したがって、0×9092以外のソケットがUDPデータグラムを送るのに使用されるなら、双方向のcommuncationは設立されないかもしれません。 それに関しては、推論してください。 UDP/IPXは0×9092以外のソケットをソースに許容しません。 0×9092以外のソースソケット番号があるデータグラムが受け取られているなら、UDP/IPXは静かにパケットを捨てるはずです。 (そして、それが器具を取り付けられるなら、増分のudpInDatagramErr MIBは反対します。)
UDP over IPX uses the IPX packet type 4, a normal IPX packet type. The IPX packet type has no meaning to TCP/IPX protocol. It simply is a number required by IPX for general IPX packets.
IPXの上のUDPはIPXパケットタイプ4、普通のIPXパケットタイプを使用します。 IPXパケットタイプは意味していないTCP/IPXを議定書を作らせます。 それは単に一般的なIPXパケットのためのIPXによる注文数です。
See Appendix B.1 and B.2 for UDP over IPX packet format.
IPXパケット・フォーマットでUDPに関してAppendix B.1とB.2を見てください。
The UDP/IPX checksum uses a pseudo header similar to UDP/IP pseudo header. The only difference is that IP addresses and protocol ID are replaced by IPX addresses and socket numbers.
UDP/IPXチェックサムはIP疑似UDP/ヘッダーと同様の疑似ヘッダーを使用します。 唯一の違いはIPアドレスとプロトコルIDをIPXアドレスとソケット番号に取り替えるということです。
See Appendix B.3 for the UDP/IPX pseudo header format.
UDP/IPX疑似ヘッダー形式に関してAppendix B.3を見てください。
3. Running TCP Over IPX
3. IPXの上にTCPを実行します。
Unlike UDP, TCP runs directly over IPX. Since IPX does not support fragmentation, no TCP segment sent over IPX can be larger than the path MTU for the connection. The discovery of the path MTU is outside of scope of this paper. If the implementation does not have a way to dynamically determine the path MTU for each connection, it should at least allow a way to statically configure a reasonable value for all connections. For example, if the internetwork made of ethernets only, the user may configure the segment size to be 1470 including the TCP header. If the configuration of the segment size is not possible, the implementation should assume that the IPX path
UDPと異なって、TCPは直接IPXをひきます。 IPXが断片化をサポートしないので、接続には、IPXの上に送られたどんなTCPセグメントも経路MTUより大きいはずがありません。 経路MTUの発見がこの紙の範囲の外にあります。 実装に各接続のためにダイナミックに経路MTUを決定する方法がないなら、それはすべての接続のために静的に適正価値を構成する方法を少なくとも許容するべきです。 イーサネットだけで作られたインターネットワーク、ユーザがそうするかもしれないなら、例えば、TCPヘッダーを含む1470年になるようにセグメントサイズを構成してください。 セグメントサイズの構成が可能でないなら、実装は、それがIPX経路であると仮定するべきです。
Sung [Page 2] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[2ページ]RFC1791TCPとUDP
MTU is 576 octects, and not send any TCP segment larger than 546 octets including TCP header. That will result in IPX packet of 576 octets which is the minimum path MTU for IPX. The implementation is then advised to comunicate the configured/default segment size to the peer TCP by exchanging MSS option.
MTUは576octectsであり、TCPヘッダーを含む546の八重奏より大きいどんなTCPセグメントも送りません。 それはIPXのための最小の経路MTUである576の八重奏のIPXパケットをもたらすでしょう。 そして、実装は、MSSオプションを交換することによって、同輩TCPへの構成された/デフォルトセグメントサイズのcomunicateに教えられます。
Note that this memo does not preclude the possibility of running TCP over IPXF instead of IPX. Running on IPXF can be done in the same manner as running UDP over IPXF. However, in general, TCP should refrain from sending large segments that may result in fragmentation. Hence, running TCP over IPXF is not recommended.
このメモがIPXの代わりにIPXFの上にTCPを実行する可能性を排除しないことに注意してください。 IPXFの上にUDPを実行するのと同じ方法でIPXFの上で作業できます。 しかしながら、一般に、TCPは、断片化をもたらすかもしれない大きいセグメントを送るのを控えるはずです。 したがって、IPXFの上の実行しているTCPは推薦されません。
The IPX socket number 0x9091 is reserved for the TCP. All TCP packets must be sent from and received on the socket 0x9091. If the received TCP/IPX packet has the source IPX socket number other than 0x9091, the packet should be discarded silently. (And increment tcpInErrs MIB counter if it is instrumented.)
IPXソケットNo.0x9091はTCPのために予約されます。 すべてのTCPパケットは、0×9091を送って、ソケットの上に受け取らなければなりません。 容認されたTCP/IPXパケットに0×9091以外のソースIPXソケット番号があるなら、パケットは静かに捨てられるべきです。 (そして、それが器具を取り付けられるなら、増分のtcpInErrs MIBは反対します。)
TCP, like UDP, uses IPX packet type 4. The IPX packet type has no meaning to TCP/IPX protocol. It is packet type required by IPX for general IPX packets.
UDPのように、TCPはIPXパケットタイプ4を使用します。 IPXパケットタイプは意味していないTCP/IPXを議定書を作らせます。 それは一般的なIPXパケットのためにIPXによって必要とされたパケットタイプです。
See appendix A.1 for TCP/IPX packet format.
TCP/IPXパケット・フォーマットに関して付録A.1を見てください。
The TCP pseudo header, used in checksuming for TCP over IPX, is similar to TCP pseudo header for TCP over IP. Again, the difference is that IPX addresses and IPX socket number are substituted in place of IP addresses and IP protocol number.
TCPに、TCPのためにIPXの上でchecksumingする際に使用されるTCP疑似ヘッダーはIPの上でTCP疑似ヘッダーと同様です。 一方、違いはIPアドレスとIPプロトコル番号に代わってIPXアドレスとIPXソケット番号を代入するということです。
See Appendix A.2 for the TCP/IPX pseudo header format.
TCP/IPX疑似ヘッダー形式に関してAppendix A.2を見てください。
4. IPXF Layer
4. IPXF層
A large UDP datagram cannot be sent directly over IPX as IPX does not support datagrams larger than the path MTU. Hence, large UDP datagrams must be fragmented before it can be sent over IPX. To have large UDP datagrams fragmented, UDP runs over IPXF layer instead of running directly IPX.
IPXが経路MTUより大きいデータグラムを支えないとき、大きいUDPデータグラムをIPXの直接上に送ることができません。 したがって、IPXの上にそれを送ることができる前に大きいUDPデータグラムを断片化しなければなりません。 大きいUDPデータグラムを断片化させるために、直接IPXを実行することの代わりにIPXFの上のUDP走行は層にされます。
IPXF users treats IPXF as if it is IPX layer. That is, they pass datagrams to IPXF specifying the destination IPX address/socket along with the packet. They also must set the source socket number of the datagram to its actual IPX socket number, as it would when sending packets to IPX layer. (For UDP, both source and destination sockets are 0x9092.)
IPXFユーザの御馳走のIPXFはまるでそれがIPXであるかのように層にします。 すなわち、彼らはパケットに伴う目的地IPXアドレス/ソケットを指定するIPXFにデータグラムを渡します。 また、彼らは実際のIPXソケット番号にデータグラムのソースソケット番号を設定しなければなりません、IPXへの送付パケットが層にされるとき、そうするように。 (UDPに関して、ソースと目的地ソケットの両方が0×9092です。)
Datagrams passed to IPXF can be upto 64K octets long.
長い間、IPXFに通過されたデータグラムはuptoの64Kの八重奏であるかもしれません。
Sung [Page 3] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[3ページ]RFC1791TCPとUDP
IPXF fragments a datagram as necessary, prepends each fragment with the IPXF header and send them to the IPX socket 0x9093 in the destination IPX address. The actual destination socket number (0x9092 for UDP) in the orignal IPX datagram is preserved in IPXF header. Refer to Appendix B.2 for UDP/IPXF/IPX packet format.
IPXFが必要に応じてデータグラムを断片化して、prependsはIPXFヘッダーと共にそれぞれ断片化して、送付先IPXアドレスのIPXソケット0x9093に彼らを送ります。 orignal IPXデータグラムの実際の目的地ソケット番号(UDPのための0×9092)はIPXFヘッダーに保存されます。 UDP/IPXF/IPXパケット・フォーマットについてAppendix B.2を参照してください。
The largest possible IPX datagram that can be sent over the IPX path is limited by the path MTU size. The mechanism to discover the path MTU is outside of the scope of the paper. If an IPXF implementation does not have a mean to determine the path MTU, it should assume that the largest IPX packet size is 576. In that case, any UDP datagram larger than 546 octects will have to be fragmented.
IPX経路の上に送ることができる可能な限り大きいIPXデータグラムは経路MTUサイズによって制限されます。 経路MTUを発見するメカニズムが紙の範囲の外にあります。 IPXF実装に経路MTUを決定する平均がないなら、それは、最も大きいIPXパケットサイズが576であると仮定するべきです。 その場合、546octectsより大きいどんなUDPデータグラムも断片化されなければならないでしょう。
If the datagram does not require fragmentation, IPXF acts as a null layer. That is, the whole packet is directly sent to the actual IPX destination socket without the IPXF fragmentation header. Refer to Appendix B.1 for UDP/IPX packet format without the IPXF header.
データグラムが断片化を必要としないなら、IPXFはヌル層として機能します。 IPXF断片化ヘッダーなしで実際のIPX目的地ソケットにすなわち、全体のパケットを直接送ります。 UDP/IPXパケット・フォーマットについてIPXFヘッダーなしでAppendix B.1を参照してください。
An IPXF user receives datagrams by opening a socket with IPXF just as it would with IPX. For example, UDP opens the socket 0x9092 with IPXF to receive UDP datagrams. IPXF, in turn, opens IPX socket of the same number with IPX, so that unfragmented packets directed to that socket will be delivered by IPX directly to the IPXF user.
IPXFユーザは、ちょうどIPXと共に受け取るようにIPXFと共にソケットを開けることによって、データグラムを受け取ります。 例えば、UDPは、UDPデータグラムを受け取るためにIPXFと共にソケット0x9092を開けます。IPXFはIPXと共に同じ数のIPXソケットを順番に開けます、そのソケットに向けられた非断片化しているパケットがIPXによって直接IPXFユーザに提供されるように。
IPXF fragments are received by IPXF on the IPX socket 0x9093. The receiving IPXF then reassembles the fragments into a complete IPX datagram, restores the actual detination IPX socket number from the IPXF header and delivers the reassembled IPX datagram to its actual recipient designated by the restored socket number.
IPXF断片はIPXソケット0x9093の上にIPXFによって受け取られます。 受信IPXFは次に、完全なIPXデータグラムに断片を組み立て直して、IPXFヘッダーから実際のdetination IPXソケット番号を回復して、回復しているソケット番号によって任命された実際の受取人に組み立て直されたIPXデータグラムを提供します。
Upon receiving a fragment, IPXF must ignore the source socket number in the IPX header of the fragment. The source IPX socket field in IPX header contains the actual source of the IPX datagram. As such, the source IPX socket number in IPX header usually is not 0x9093, and it is meaningful only to the actual recepient of the assembled datagram.
断片を受けると、IPXFは断片のIPXヘッダーでソースソケット番号を無視しなければなりません。 IPXヘッダーのソースIPXソケット分野はIPXデータグラムの実際の源を含んでいます。 そういうものとして、通常、IPXヘッダーのソースIPXソケット番号は0×9093ではありません、そして、それは組み立てられたデータグラムの実際のrecepientだけに重要です。
The fragmentation/reassembly algorithm used by IPXF is identical to that of IP, except for the following exceptions: 1) the offset of fragments are measured in units of octets rather than in units of 8 octets. 2) if the receiving IPXF does not have sufficient resource for the reassembly, it should discard fragments immediately. The receiving IPXF can determine if it has sufficient resources by looking at the length of the original datagram included in every fragment.
IPXFによって使用された断片化/再アセンブリアルゴリズムは以下の例外以外のIPのものと同じです: 1) 断片のオフセットは8つの八重奏のユニットでというよりむしろユニットの八重奏で測定されます。 2) 受信IPXFに再アセンブリに、十分なリソースがないなら、それはすぐに、断片を捨てるべきです。 受信IPXFは、それはあらゆる断片にオリジナルのデータグラムの長さを見るのによる十分なリソースを含んでいたかどうか決定できます。
Note that, though it is required only for UDP in this memo, IPXF can also be used by any protocol that requires IPX fragmentation support.
それがこのメモによるUDPにだけ必要ですが、また、IPX断片化サポートを必要とするどんなプロトコルでもIPXFを使用できることに注意してください。
Sung [Page 4] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[4ページ]RFC1791TCPとUDP
5. TCP/IPX Checksuming
5. TCP/IPX Checksuming
TCP/IPX is checksummed in exactly same manner as TCP/IP. It uses 16 bit 1's complement of 1's compliment sum of all 16 bit words in the pseudo header and text. See Appendix A.2 and B.3 for the pseudo header format for TCP and UDP.
TCP/IPXはまさにTCP/IPと同じ方法でchecksummedされます。 それは疑似ヘッダーとテキストでの1のすべての16ビットの単語の賛辞合計の16ビットの1の補数を使用します。 疑似ヘッダー形式に関してTCPとUDPに関してAppendix A.2とB.3を見てください。
6. Multiplexing
6. マルチプレクシング
TCP and UDP data over IPX are delivered to the application in the same manner as in TCP/IP. That is, they are delivered to the most specific matching endpoint, with the match made on local port, remote port, local IPX address and remote IPX address.
IPXの上のTCPとUDPデータはTCP/IPのように同じ方法でアプリケーションに提供されます。 すなわち、それらは最も特定の合っている終点に提供されます、マッチが地方のポート、遠く離れたポート、ローカルのIPXアドレス、およびリモートIPXアドレスで作られている状態で。
When TCP or UDP is running over both IPX and IP, the connection endpoint also identifies the network layer on which the endpoint is. Hence, the triplet of network address, network address family, and the port number forms the socket. And, the endpoint match must be made on the the network address familty as well.
また、TCPかUDPがIPXとIPの両方をひいているとき、接続終点は終点がそうであるネットワーク層を特定します。 したがって、ネットワーク・アドレスの三つ子、ネットワーク・アドレスファミリー、およびポートナンバーはソケットを形成します。 そして、また、ネットワーク・アドレスfamiltyで終点マッチを作らなければなりません。
For exmple, an endpoint bound to IPX network layer would be identified by AF_IPX, IPX address and TCP port number. On the other hand, endpoints bound to IP network layer would be identified by AF_IP, IP address, and TCP port. Finally, endpoints not bound to any network layer would be identified by AF_UNSPEC and TCP port.
exmpleに関しては、IPXネットワーク層に縛られた終点はAF_IPX、IPXアドレス、およびTCPポートナンバーによって特定されるでしょう。 他方では、IPネットワーク層に縛られた終点はAF_IP、IPアドレス、およびTCPポートによって特定されるでしょう。 最終的に、どんなネットワーク層にも縛られなかった終点はUNSPECとTCPが移植するAF_によって特定されるでしょう。
First, an attempt is made to deliver the data to the most specific endpoint that is bound to the network layer that the packet arrived from. If there is no such endpoint, then the packet is delivered to the best matching endpoint that is not bound to any network layer at all. For example, if the packet arrived over IPX network, then the packet is delivered to the most specific matching endpoint that is bound to IPX. If there is no matching endpoint over IPX, then it is delivered to an endpoint that did not specify any network layer.
まず最初に、パケットが到着したネットワーク層に縛られる中で最も特定の終点にデータを提供するのを試みをします。 どれかそのような終点がなければ、パケットは全くどんなネットワーク層にも縛られない中で最も良い合っている終点に提供されます。 例えば、パケットがIPXネットワークの上で到着したなら、パケットはIPXに縛られる中で最も特定の合っている終点に提供されます。 IPXの上に合っている終点が全くなければ、それはどんなネットワーク層も指定しなかった終点に提供されます。
The use of endpoints not bound to any network layer is similar to TCP/IP endpoints with no IP address bound to it. Such endpoints are usually used for listening for connection requests from any of the interfaces within the host. Similarly, endpoints with no network layer bound to it are used to field the connection requests from any of the network layers.
どんなネットワーク層にも縛られなかった終点の使用はそれに縛られたIPアドレスなしでTCP/IP終点と同様です。 通常、そのような終点は、ホストの中でインタフェースのどれかからの接続要求の聞こうとするのに使用されます。 同様に、それに縛られたネットワーク層のない終点は、ネットワーク層のどれかからの接続要求をさばくのに使用されます。
Acknowledgement
承認
The author wishes to thank following folks, in alphabetical order, and others for their helpful comments and contributions to the work: Lester Bird, Doug Kogan, Greg Minshall and Don Provan.
人々に続いて、作者は感謝したがっています、アルファベット順、彼らの役に立つコメントのための他のもの、および仕事への貢献で: レスターBird、ダグ・コーガン、グレッグMinshall、およびドンProvan。
Sung [Page 5] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[5ページ]RFC1791TCPとUDP
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Tae Sung Novell, Inc. 2180 Fortune Drive San Jose, California, 95131
Driveサンノゼ、多英歌われたノベルInc.2180Fortuneカリフォルニア 95131
Phone: (408)577-8439 EMail: tae@novell.Com
以下に電話をしてください。 (408)577-8439 メールしてください: tae@novell.Com
Sung [Page 6] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[6ページ]RFC1791TCPとUDP
Appendix A.1 - TCP/IPX Packet Format
付録A.1--TCP/IPXパケット・フォーマット
A TCP/IPX Packet has following format:
TCP/IPX Packetには、次の形式があります:
+-------+-------+-------+-------+
| IPX Checksum | IPX Pkt Len |
+-------+-------+-------+-------+
| Zero |IPX PT | IPX Dest -
+-------+-------+-------+-------+
Network | IPX Dest -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Dest Skt | IPX Src -
+-------+-------+-------+-------+
Network | IPX Src -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Src Skt | TCP Header and
+---------------+-------+-------+
Data...
+----...
+-------+-------+-------+-------+ | IPXチェックサム| IPX Pktレン| +-------+-------+-------+-------+ | ゼロ|太平洋標準時のIPX| IPX Dest--+-------+-------+-------+-------+ ネットワーク| IPX Dest--+-------+-------+-------+-------+ ノード| +-------+-------+-------+-------+ | IPX Dest Skt| IPX Src--+-------+-------+-------+-------+ ネットワーク| IPX Src--+-------+-------+-------+-------+ ノード| +-------+-------+-------+-------+ | IPX Src Skt| TCPヘッダーと+---------------+-------+-------+ データ… +----...
IPX PT field contains the IPX packet type. It is set to 4 for TCP/IPX packet.
IPX PT分野はIPXパケットタイプを含んでいます。 それはTCP/IPXパケットのために4に設定されます。
Both Src Skt and Dest Skt field in IPX header must be set to 0x9091 for TCP/IPX packet. If the Src Skt is not set to 0x9091, the receiving TCP/IPX should discard the packet silently. (And increment tcpInErrs mib object if it is instrumented.)
TCP/IPXパケットのためにSrc SktとDest SktがIPXヘッダーでさばく両方を0×9091に設定しなければなりません。 Src Sktが0×9091に用意ができていないなら、受信TCP/IPXは静かにパケットを捨てるはずです。 (そして、それが器具を取り付けられるなら、増分のtcpInErrs mibは反対します。)
Sung [Page 7] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[7ページ]RFC1791TCPとUDP
Appendix A.2 - TCP/IPX Pseudo Header Format
付録A.2--TCP/IPX疑似ヘッダー形式
TCP/IPX uses following pseudo header to compute checksum:
TCP/IPXはチェックサムを計算するのに次の疑似ヘッダーを使用します:
+-------+-------+-------+-------+
| IPX Src Network |
+-------+-------+-------+-------+
| IPX Src Node
+-------+-------+-------+-------+
| IPX Src Skt |
+-------+-------+-------+-------+
| IPX Dest Network |
+-------+-------+-------+-------+
| IPX Dest Node
+-------+-------+-------+-------+
| IPX Dest Skt |
+-------+-------+-------+-------+
| Zero | TCP Length |
+---------------+---------------+
+-------+-------+-------+-------+ | IPX Srcネットワーク| +-------+-------+-------+-------+ | IPX Srcノード+-------+-------+-------+-------+ | IPX Src Skt| +-------+-------+-------+-------+ | IPX Destネットワーク| +-------+-------+-------+-------+ | IPX Destノード+-------+-------+-------+-------+ | IPX Dest Skt| +-------+-------+-------+-------+ | ゼロ| TCPの長さ| +---------------+---------------+
IPX Src/Dest Network/Node/Skt are the fields from the IPX header. TCP Length is the IPX Pkt Len minus the IPX header length in octets.
IPX Src/Dest Network/ノード/SktはIPXヘッダーからの分野です。 TCP Lengthは八重奏におけるIPXヘッダ長を引いたIPX Pktレンです。
Note that IPX Src Skt is expected to be 0x9091 for TCP. As such, one may insert 0x9091 in IPX Src Skt field rather than getting the value from IPX header. Then the implementation will not have to check the IPX Src Skt field in the fast path since the checksum failure will also cover the unexpected value. In that case, the implementation may want to examine if the checksum failure was due to the IPX Src Skt value other than 0x9091, so that it can increment appropriate counter, if proprietary counters other than tcpInErrs are used.
IPX Src SktがTCPのための0×9091であると予想されることに注意してください。 そういうものとして、IPXヘッダーから値を得るよりむしろIPX Src Skt分野における0×9091を挿入するかもしれません。 そして、また、チェックサム失敗が予期していなかった値をカバーするので、実装は高速経路でIPX Src Skt分野をチェックする必要はないでしょう。 その場合、実装は、チェックサム失敗が0×9091以外のIPX Src Skt値のためであったかを調べたがっているかもしれません、適切なカウンタを増加できるように、tcpInErrs以外の独占カウンタが使用されているなら。
Sung [Page 8] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[8ページ]RFC1791TCPとUDP
Appendix B.1 - UDP/IPX Packet Format without Fragmentation
付録B.1--断片化のないUDP/IPXパケット・フォーマット
IPXF transmits UDP packets over IPX in this format if the UDP datagram does not have to be fragmented:
UDPデータグラムが断片化される必要はないなら、IPXFはこの形式でUDPパケットをIPXの上に伝えます:
+-------+-------+-------+-------+
| IPX Checksum | IPX Pkt Len |
+-------+-------+-------+-------+
| Zero |IPX PT | IPX Dest -
+-------+-------+-------+-------+
Network | IPX Dest -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Dest Skt | IPX Src -
+-------+-------+-------+-------+
Network | IPX Src -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Src Skt | UDP Header and
+---------------+-------+-------+
Data...
+----...
+-------+-------+-------+-------+ | IPXチェックサム| IPX Pktレン| +-------+-------+-------+-------+ | ゼロ|太平洋標準時のIPX| IPX Dest--+-------+-------+-------+-------+ ネットワーク| IPX Dest--+-------+-------+-------+-------+ ノード| +-------+-------+-------+-------+ | IPX Dest Skt| IPX Src--+-------+-------+-------+-------+ ネットワーク| IPX Src--+-------+-------+-------+-------+ ノード| +-------+-------+-------+-------+ | IPX Src Skt| UDPヘッダーと+---------------+-------+-------+ データ… +----...
The IPX PT field contains IPX packet type. It should be set to 4 for all UDP/IPX packets.
IPX PT分野はIPXパケットタイプを含んでいます。 それはすべてのUDP/IPXパケットのために4に設定されるべきです。
Both IPX Src Skt and IPX Dest Skt field must be set 0x9092. The receiving UDP/IPX should discard the packet silently if the IPX Src Skt field is not set to 0x9092. (And increment udpInErrors mib object if it is instrumented.)
IPX Src SktとIPX Dest Sktがさばく両方がセット0x9092であるに違いない。 IPX Src Skt分野が0×9092に設定されないなら、受信UDP/IPXは静かにパケットを捨てるはずです。 (そして、それが器具を取り付けられるなら、増分のudpInErrors mibは反対します。)
Sung [Page 9] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[9ページ]RFC1791TCPとUDP
Appendix B.2 - UDP/IPX Packet Format With Fragmentation
付録B.2--断片化があるUDP/IPXパケット・フォーマット
IPXF transmits fragmented datagrams over IPX in the following format:
IPXFは以下の形式で断片化しているデータグラムをIPXの上に送ります:
+-------+-------+-------+-------+
| IPX Checksum | IPX Pkt Len |
+-------+-------+-------+-------+
| Zero |IPX PT | IPX Dest -
+-------+-------+-------+-------+
Network | IPX Dest -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
IPX Dest Skt | IPX Src -
+-------+-------+-------+-------+
Network | IPX Src -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Src Skt | IPXF Offset |
+---------------+-------+-------+
| IPXF Frag Identification |
+-------------------------------+
| IPXF Dest Skt | IPXF DG Len |
+-------------------------------+
| UDP Header and Data ...
+--------...
+-------+-------+-------+-------+ | IPXチェックサム| IPX Pktレン| +-------+-------+-------+-------+ | ゼロ|太平洋標準時のIPX| IPX Dest--+-------+-------+-------+-------+ ネットワーク| IPX Dest--+-------+-------+-------+-------+ ノード| +-------+-------+-------+-------+ IPX Dest Skt| IPX Src--+-------+-------+-------+-------+ ネットワーク| IPX Src--+-------+-------+-------+-------+ ノード| +-------+-------+-------+-------+ | IPX Src Skt| IPXFは相殺します。| +---------------+-------+-------+ | IPXFは識別を破片手榴弾で殺傷します。| +-------------------------------+ | IPXF Dest Skt| IPXF DGレン| +-------------------------------+ | UDPヘッダーとデータ… +--------...
The IPX PT field contains IPX packet type. It is set to the value set by the IPXF user in the IPX packet passed to IPXF. (UDP sets it to 4.)
IPX PT分野はIPXパケットタイプを含んでいます。 それはIPXFに通過されたIPXパケットのIPXFユーザによって選択値群に設定されます。 (UDPは4にそれを設定します。)
IPX Dest Skt field must be set to 0x9093 for all IPXF Packets.
すべてのIPXF PacketsのためにIPX Dest Skt分野を0×9093に設定しなければなりません。
The value for IPX Src Skt field is variable, and must be set to the actual IPX socket number of the IPXF user. (For example, it must be set to 0x9092 for UDP.)
IPX Src Skt分野への値を可変であり、IPXFユーザの実際のIPXソケット番号に設定しなければなりません。 (例えば、UDPのために0×9092にそれを設定しなければなりません。)
IPXF Offset field indicates where the fragment belongs in the datagram. The offset is measured is octet from the begining of the UDP datagram. The first fragment has the offset of 0.
IPXF Offset分野は、データグラムには断片がどこにあるかを示します。 オフセットは測定されているのが、UDPデータグラムのbeginingからの八重奏であるということです。 最初の断片には、0のオフセットがあります。
IPXF Frag Identification field is assigned a same value by the sender for all fragements belonging to the same datagram. The receiver then uses this field to reassemble all fragments with same ID into a datagram.
同じ値は同じデータグラムに属すすべてのfragementsのために送付者によってIPXF Frag Identification分野に割り当てられます。 そして、受信機は、同じIDと共にすべての断片をデータグラムに組み立て直すのにこの分野を使用します。
Sung [Page 10] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[10ページ]RFC1791TCPとUDP
IPXF Dest Skt field contains the IPX socket number of the actual recipient that the reassembled datagram will be delivered to. (It is 0x9092 for UDP.) All fragments of a datagram must have the same value in this field.
IPXF Dest Skt分野は組み立て直されたデータグラムが提供される実際の受取人のIPXソケット番号を含んでいます。 (それはUDPのための0×9092です。) データグラムのすべての断片がこの分野に同じ値を持たなければなりません。
IPXF DG Len field is the total length of the IPX datagram before the fragmentation. The sender should set it to the value of IPX Pkt Len of the original IPX datagram. All fragments of a IPX datagram must have the same value in this field.
IPXF DGレン分野は断片化の前のIPXデータグラムの全長です。 送付者はオリジナルのIPXデータグラムのIPX Pktレンの値にそれを設定するべきです。 IPXデータグラムのすべての断片がこの分野に同じ値を持たなければなりません。
Sung [Page 11] RFC 1791 TCP And UDP Over IPX April 1995
IPX1995年4月の上の歌われた[11ページ]RFC1791TCPとUDP
Appendix B.3 - UDP/IPX Pseudo Header Format
付録B.3--UDP/IPX疑似ヘッダー形式
UDP/IPX uses following pseudo header for computing the checksum:
UDP/IPXはチェックサムを計算するのに次の疑似ヘッダーを使用します:
+-------+-------+-------+-------+
| IPX Src Network |
+-------+-------+-------+-------+
| IPX Src Node
+-------+-------+-------+-------+
| IPX Src Skt |
+-------+-------+-------+-------+
| IPX Dest Network |
+-------+-------+-------+-------+
| IPX Dest Node
+-------+-------+-------+-------+
| IPX Dest Skt |
+-------+-------+-------+-------+
| Zero | UDP Length |
+---------------+---------------+
+-------+-------+-------+-------+ | IPX Srcネットワーク| +-------+-------+-------+-------+ | IPX Srcノード+-------+-------+-------+-------+ | IPX Src Skt| +-------+-------+-------+-------+ | IPX Destネットワーク| +-------+-------+-------+-------+ | IPX Destノード+-------+-------+-------+-------+ | IPX Dest Skt| +-------+-------+-------+-------+ | ゼロ| UDPの長さ| +---------------+---------------+
IPX Src/Dest Network/Node/Skt fields are from the IPX packet. Note that, if UDP is running over IPXF, the IPX Dest Skt field in IPX packet header is copied over from IPXF header before the reassembled IPX packet is delivered to UDP, Hence, the pseudo header must be derived from the reassembled IPX header.
IPX Src/Dest Network/ノード/Skt分野がIPXパケットからあります。 UDPがIPXFをひいているなら、組み立て直されたIPXパケットがUDPに提供される前にIPXパケットのヘッダーのIPX Dest Skt分野はIPXFヘッダーからコピーされます、Henceというメモ、組み立て直されたIPXヘッダーから疑似ヘッダーを得なければなりません。
UDP Length is from UDP header.
UDP LengthはUDPヘッダーから来ています。
Note that IPX Src Skt is expected to be 0x9092 for UDP. As such, one may insert 0x9092 in IPX Src Skt field rather than getting the value from IPX header. Then the implementation will not have to check the IPX Src Skt field in the fast path since the checksum failure will also cover the unexpected value. In that case, the implementation may want to examine if the checksum failure was due to the IPX Src Skt value other than 0x9092, so that it can increment appropriate counter, if proprietary counters other than udpInDatagramErr are Datagr
IPX Src SktがUDPのための0×9092であると予想されることに注意してください。 そういうものとして、IPXヘッダーから値を得るよりむしろIPX Src Skt分野における0×9092を挿入するかもしれません。 そして、また、チェックサム失敗が予期していなかった値をカバーするので、実装は高速経路でIPX Src Skt分野をチェックする必要はないでしょう。 その場合、実装は、チェックサム失敗が0×9092以外のIPX Src Skt値のためであったかを調べたがっているかもしれません、適切なカウンタを増加できるように、udpInDatagramErr以外の独占カウンタがDatagrであるなら
Sung [Page 12]
歌われます。[12ページ]
一覧
スポンサーリンク
