Network Working Group                                          D. ProvanRequest for Comments: 1234                                  Novell, Inc.                                                               June 1991               Tunneling IPX Traffic through IP NetworksStatus 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.Introduction   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   protocol.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 andProvan                                                          [Page 2]RFC 1234                       IPX on IP                       June 1991   routers on the IP internet.  I will refer to this list as the "peer   list", to individual members as "peers", and to all the peers taken   together, including the local node, as the "peer group".  When IPX   requests a broadcast, the encapsulation implementation simulates the   broadcast by transmitting a separate unicast packet to each peer in   the peer list.   Because each peer list is constructed by hand, several groups of   peers can share the same IP internet without knowing about one   another.  This differs from a normal IPX network in which all peers   would find each other automatically by using the hardware's broadcast   facility.   The list of peers at each node should contain all other peers in the   peer group.  In most cases, connectivity will suffer if broadcasts   from one peer consistently fail to reach some other peer in the   group.   The peer list could be implemented using IP multicast [4], but since   multicast facilities are not widely available at this time, no well-   known multicast address has been assigned and no implementations   using multicast exist.  As IP multicast is deployed in IP   implementations, it can be used by simply including in the peer list   an IP multicast address for IPX servers and routers.  The IP   multicast address would replace the IP addresses of all peers which   will receive IP multicast packets sent from this peer.Broadcasts by Clients   Typically, NetWare client nodes do not need to receive broadcasts, so   normally NetWare client nodes on the IP internet would not need to be   included in the peer lists at the servers.   On the other hand, clients on an IPX network need to send broadcasts   in order to locate servers and to discover routes.  A client   implementation of UDP encapsulation can handle this by having a   configured list of the IP addresses of all servers and routers in the   peer group running on the IP internetwork.  As with the peer list on   a server, the client implementation would simulate the broadcast by   sending a copy of the packet to each IP address in its list of IPX   servers and routers.  One of the IP addresses in the list, perhaps   the only one, could be a broadcast address or, when available, a   multicast address.  This allows the client to communicate with   members of the peer group without knowing their specific IP   addresses.   It's important to realize that broadcast packets sent from an IPX   client must be able to reach all servers and routers in the serverProvan                                                          [Page 3]RFC 1234                       IPX on IP                       June 1991   peer group.  Unlike IP, which has a unicast redirect mechanism, IPX   end systems are responsible for discovering routing information by   broadcasting a packet requesting a router that can forward packets to   the desired destination.  If such packets do not tend to reach the   entire server peer group, resources in the IPX internet may be   visible to an end system, yet unreachable by it.Maximum Transmission Unit   Although larger IPX packets are possible, the standard maximum   transmission unit for IPX is 576 octets.  Consequently, 576 octets is   the recommended default maximum transmission unit for IPX packets   being sent with this encapsulation technique.  With the eight octet   UDP header and the 20 octet IP header, the resulting IP packets will   be 604 octets long.  Note that this is larger than the 576 octet   maximum size IP implementations are required to accept [3].  Any IP   implementation supporting this encapsulation technique must be   capable of receiving 604 octet IP packets.   As improvements in protocols and hardware allow for larger,   unfragmented IP transmission units, the 576 octet maximum IPX packet   size may become a liability.  For this reason, it is recommended that   the IPX maximum transmission unit size be configurable in   implementations of this memo.Security Issues   Using a wide-area, general purpose network such as an IP internet in   a position normally occupied by physical cabling introduces some   security problems not normally encountered in IPX internetworks.   Normal media are typically protected physically from outside access;   IP internets typically invite outside access.   The general effect is that the security of the entire IPX   internetwork is only as good as the security of the entire IP   internet through which it tunnels.  The following broad classes of   attacks are possible:   1)  Unauthorized IPX clients can gain access to resources through       normal access control attacks such as password cracking.   2)  Unauthorized IPX gateways can divert IPX traffic to unintended       routes.   3)  Unauthorized agents can monitor and manipulate IPX traffic       flowing over physical media used by the IP internet and under       control of the agent.Provan                                                          [Page 4]RFC 1234                       IPX on IP                       June 1991   To a large extent, these security risks are typical of the risks   facing any other application using an IP internet.  They are   mentioned here only because IPX is not normally suspicious of its   media.  IPX network administrators will need to be aware of these   additional security risks.Assigned Numbers   The Internet Assigned Numbers Authority assigns well-known UDP port   numbers.  It has assigned port number 213 decimal to the IPX   encapsulation technique described in this memo [5].Acknowledgements   This encapsulation technique was developed independently by Schneider   & Koch and by Novell.  I'd like to thank Thomas Ruf of Schneider &   Koch for reviewing this memo to confirm its agreement with the   Schneider & Koch implementation and also for his other valuable   suggestions.References   [1] Xerox, Corp., "Internet Transport Protocols", XSIS 028112, Xerox       Corporation, December 1981.   [2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information       Sciences Institute, August 1980.   [3] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.   [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,       Stanford University, August 1989.   [5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1060,       USC/Information Sciences Institute, March 1990.Security Considerations   See the "Security Issues" section above.Provan                                                          [Page 5]RFC 1234                       IPX on IP                       June 1991Author's Address   Don Provan   Novell, Inc.   2180 Fortune Drive   San Jose, California, 95131   Phone: (408)473-8440   EMail: donp@Novell.ComProvan                                                          [Page 6]