From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1791.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc1791.txt (limited to 'doc/rfc/rfc1791.txt') diff --git a/doc/rfc/rfc1791.txt b/doc/rfc/rfc1791.txt new file mode 100644 index 0000000..39e2a75 --- /dev/null +++ b/doc/rfc/rfc1791.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group T. Sung +Request for Comments: 1791 Novell, Inc. +Category: Experimental April 1995 + + + TCP And UDP Over IPX Networks With Fixed Path MTU + +Status of this 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. + +IESG Note: + + 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. + +1. Introduction + + 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. + + 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. + + 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. + + + + + + + +Sung [Page 1] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +2. Running UDP Over IPX + + 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. + + 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. + + 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 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. + + See Appendix B.1 and B.2 for UDP over IPX packet format. + + 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. + + See Appendix B.3 for the UDP/IPX pseudo header format. + +3. Running TCP Over IPX + + 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 + + + +Sung [Page 2] + +RFC 1791 TCP And UDP Over IPX April 1995 + + + 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. + + 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. + + 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.) + + 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. + + See appendix A.1 for TCP/IPX packet format. + + 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. + + See Appendix A.2 for the TCP/IPX pseudo header format. + +4. IPXF Layer + + 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. + + 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.) + + Datagrams passed to IPXF can be upto 64K octets long. + + + + +Sung [Page 3] + +RFC 1791 TCP And UDP Over IPX April 1995 + + + 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. + + 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. + + 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. + + 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 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. + + 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. + + 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. + + 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. + + + +Sung [Page 4] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +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. + +6. Multiplexing + + 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. + + 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. + + 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. + + 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. + + 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. + +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. + + + + +Sung [Page 5] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Tae Sung + Novell, Inc. + 2180 Fortune Drive + San Jose, California, 95131 + + Phone: (408)577-8439 + EMail: tae@novell.Com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sung [Page 6] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +Appendix A.1 - TCP/IPX Packet Format + + A TCP/IPX Packet has following format: + + +-------+-------+-------+-------+ + | 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 PT field contains the IPX packet type. It is set to 4 for + TCP/IPX packet. + + 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.) + + + + + + + + + + + + + + + + + + + + +Sung [Page 7] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +Appendix A.2 - TCP/IPX Pseudo Header Format + + TCP/IPX uses following pseudo header to compute checksum: + + +-------+-------+-------+-------+ + | IPX Src Network | + +-------+-------+-------+-------+ + | IPX Src Node + +-------+-------+-------+-------+ + | IPX Src Skt | + +-------+-------+-------+-------+ + | IPX Dest Network | + +-------+-------+-------+-------+ + | IPX Dest Node + +-------+-------+-------+-------+ + | IPX Dest Skt | + +-------+-------+-------+-------+ + | Zero | TCP Length | + +---------------+---------------+ + + 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. + + 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. + + + + + + + + + + + + + + + + + + + + +Sung [Page 8] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +Appendix B.1 - UDP/IPX Packet Format without Fragmentation + + IPXF transmits UDP packets over IPX in this format if the UDP + datagram does not have to be fragmented: + + +-------+-------+-------+-------+ + | 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... + +----... + + The IPX PT field contains IPX packet type. It should be set to 4 for + all UDP/IPX packets. + + 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.) + + + + + + + + + + + + + + + + + + + +Sung [Page 9] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +Appendix B.2 - UDP/IPX Packet Format With Fragmentation + + IPXF transmits fragmented datagrams over IPX in the following format: + + +-------+-------+-------+-------+ + | 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 ... + +--------... + + 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 Dest Skt field must be set to 0x9093 for all IPXF Packets. + + 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.) + + 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 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. + + + + + +Sung [Page 10] + +RFC 1791 TCP And UDP Over IPX April 1995 + + + 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 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sung [Page 11] + +RFC 1791 TCP And UDP Over IPX April 1995 + + +Appendix B.3 - UDP/IPX Pseudo Header Format + + UDP/IPX uses following pseudo header for computing the checksum: + + +-------+-------+-------+-------+ + | IPX Src Network | + +-------+-------+-------+-------+ + | IPX Src Node + +-------+-------+-------+-------+ + | IPX Src Skt | + +-------+-------+-------+-------+ + | IPX Dest Network | + +-------+-------+-------+-------+ + | IPX Dest Node + +-------+-------+-------+-------+ + | IPX Dest Skt | + +-------+-------+-------+-------+ + | Zero | UDP Length | + +---------------+---------------+ + + 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. + + UDP Length is from UDP header. + + 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 + + + + + + + + + + + + + + +Sung [Page 12] + -- cgit v1.2.3