RFC 1791 (rfc1791) - Page 2 of 12

TCP And UDP Over IPX Networks With Fixed Path MTU

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