summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1791.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1791.txt')
-rw-r--r--doc/rfc/rfc1791.txt675
1 files changed, 675 insertions, 0 deletions
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]
+