Tunneling IPX traffic through IP networks
RFC 1234

Document Type RFC - Historic (June 1991; No errata)
Was draft-provan-ipxtunneling (individual)
Author Don Provan 
Last updated 2019-12-21
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1234 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          D. Provan
Request for Comments: 1234                                  Novell, Inc.
                                                               June 1991

               Tunneling IPX Traffic through IP Networks

Status of this Memo

   This memo describes a method of encapsulating IPX datagrams within
   UDP packets so that IPX traffic can travel across an IP internet.
   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.


   Internet Packet eXchange protocol (IPX) is the internetwork protocol
   used by Novell's NetWare protocol suite.  For the purposes of this
   paper, IPX is functionally equivalent to the Internet Datagram
   Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite
   [1].  This memo describes a method of encapsulating IPX datagrams
   within UDP packets [2] so that IPX traffic can travel across an IP
   internet [3].

   This RFC allows an IPX implementation to view an IP internet as a
   single IPX network.  An implementation of this memo will encapsulate
   IPX datagrams in UDP packets in the same way any hardware
   implementation might encapsulate IPX datagrams in that hardware's
   frames.  IPX networks can be connected thusly across internets that
   carry only IP traffic.

Packet Format

   Each IPX datagram is carried in the data portion of a UDP packet.
   All IP and UDP fields are set normally.  Both the source and the
   destination ports in the UDP packet should be set to the UDP port
   value allocated by the Internet Assigned Numbers Authority for the
   implementation of this encapsulation method.

   As with any UDP application, the transmitting party has the option of
   avoiding the overhead of the checksum by setting the UDP checksum to
   zero.  Since IPX implementations never use the IPX checksum to guard
   IPX packets from damage, UDP checksumming is highly recommended for
   IPX encapsulation.

Provan                                                          [Page 1]
RFC 1234                       IPX on IP                       June 1991

   |                     |            |             |                 |
   |     IP Header       | UDP Header | IPX Header  | IPX packet data |
   | (20 or more octets) | (8 octets) | (30 octets) |                 |
   |                     |            |             |                 |

         Figure 1: An IPX packet carried as data in a UDP packet.

Reserved Packets

   The first two octets of the IPX header contain the IPX checksum.  IPX
   packets are never sent with a checksum, so every IPX header begins
   with two octets of FF hex.  Implementations of this encapsulation
   scheme should ignore packets with any other value in the first two
   octets immediately following the UDP header.  Other values are
   reserved for possible future enhancements to this encapsulation

Unicast Address Mappings

   IPX addresses consist of a four octet network number and a six octet
   host number.  IPX uses the network number to route each packet
   through the IPX internet to the destination network.  Once the packet
   arrives at the destination network, IPX uses the six octet host
   number as the hardware address on that network.

   Host numbers are also exchanged in the IPX headers of packets of
   IPX's Routing Information Protocol (RIP).  This supplies end nodes
   and routers alike with the hardware address information required for
   forwarding packets across intermediate networks on the way towards
   the destination networks.

   For implementations of this memo, the first two octets of the host
   number will always be zero and the last four octets will be the
   node's four octet IP address.  This makes address mapping trivial for
   unicast transmissions: the first two octets of the host number are
   discarded, leaving the normal four octet IP address.  The
   encapsulation code should use this IP address as the destination
   address of the UDP/IP tunnel packet.

Broadcasts between Peer Servers

   IPX requires broadcast facilities so that NetWare servers and IPX
   routers sharing a network can find one another.  Since internet-wide
   IP broadcast is neither appropriate nor available, some other
   mechanism is required.  For this memo, each server and router should
   maintain a list of the IP addresses of the other IPX servers and

Provan                                                          [Page 2]
RFC 1234                       IPX on IP                       June 1991

   routers on the IP internet.  I will refer to this list as the "peer
Show full document text