TCP And UDP Over IPX Networks With Fixed Path MTU
RFC 1791

Document Type RFC - Experimental (April 1995; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1791 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text