IPX over IP: Tunneling IPX traffic through IP networks
Carrying Novell IPX datagrams through IP networks using UDP.
Provan, D., "Tunneling IPX traffic through IP networks", RFC 1234, DOI 10.17487/RFC1234, June 1991, <https://www.rfc-editor.org/info/rfc1234>.
@misc{rfc1234,
series = {Request for Comments},
number = 1234,
howpublished = {RFC 1234},
publisher = {RFC Editor},
doi = {10.17487/RFC1234},
url = {https://www.rfc-editor.org/info/rfc1234},
author = {D. Provan},
title = {{Tunneling IPX traffic through IP networks}},
pagetotal = 6,
year = 1991,
month = jun,
} RFC text
Contents
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.
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.
+---------------------+------------+-------------------------------+
| | | | |
| 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 and
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 server
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.
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.
Author's Address
Don Provan
Novell, Inc.
2180 Fortune Drive
San Jose, California, 95131
Phone: (408)473-8440
EMail: donp@Novell.Com
AI ELI5
On this page
§1Introduction
IPX (Internet Packet eXchange) is the network protocol used by Novell's NetWare. Functionally, it is equivalent to the Internet Datagram Protocol from the Xerox Network Systems suite. However, IPX networks cannot natively cross IP internets. This RFC describes a way to encapsulate IPX datagrams within UDP packets so that IPX traffic can travel across IP networks. This allows an IPX implementation to view an IP internet as a single IPX network, enabling IPX networks to be connected across internets that carry only IP traffic.
NetWare computers speak IPX, which doesn't work on the Internet. This method wraps IPX messages in UDP so they can cross the Internet.
§2Packet Format and Checksum Handling
Each IPX datagram is carried in the data portion of a UDP packet with all IP and UDP fields set normally. Both the source and destination ports in the UDP packet are set to UDP port 213, allocated by the Internet Assigned Numbers Authority for IPX encapsulation. The transmitting party may avoid checksum overhead by setting the UDP checksum to zero, but UDP checksumming is highly recommended for IPX encapsulation since IPX implementations never use checksums themselves. The first two octets of every IPX header contain an IPX checksum field, but IPX packets are always sent with this set to all ones (FF hex), never zero. Implementations must ignore any UDP packets where the first two octets after the UDP header are not FF hex, as other values are reserved for future enhancements.
The IPX message goes inside a UDP message aimed at port 213. Because IPX itself doesn't check for damage, the UDP layer's checksum is important to catch corruption.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
IP-HEADER | IP Header | 20 bytes | 20 or more octets. | |
UDP-HEADER | UDP Header | 8 bytes | 8 octets. | |
IPX-HEADER | IPX Header | 30 bytes | 30 octets. | |
IPX-DATA | IPX Data | 1 byte | Variable length packet data (minimum 8 bits shown). |
§3Address Mapping
IPX addresses consist of a four-octet network number and a six-octet host number. The network number routes packets through the IPX internet to the destination network, while the six-octet host number identifies the specific host on that network. In this encapsulation scheme, the first two octets of the host number are always zero, and the last four octets are the node's four-octet IP address. This makes address mapping trivial: the encapsulation code extracts the last four octets of the IPX host number and uses that IP address as the destination address for the UDP/IP tunnel packet. This approach works because IPX routing information is exchanged in IPX headers, which means routers and end nodes learn the hardware addresses needed for forwarding packets.
An IPX address has a network part and a host part. The host part is actually an IP address in disguise, so the code just pulls out the IP address and uses it.
§4Broadcasting and Peer Networks
IPX requires broadcast facilities for servers and routers to find one another. Since internet-wide IP broadcast is not available, IPX encapsulation uses a different approach: each server and router maintains a peer list of the IP addresses of all other IPX servers and routers on the IP internet. When IPX requests a broadcast, the encapsulation implementation simulates it by transmitting separate unicast packets to each peer. The peer list is constructed by hand, so multiple peer groups can share the same IP internet without knowing about each other, unlike a normal IPX network where all peers would auto-discover using hardware broadcast. The peer list could use IP multicast, but since multicast was not widely available when this RFC was written, no well-known multicast address was assigned. NetWare client nodes typically do not need to receive broadcasts, so they are not usually included in server peer lists, but clients must send broadcasts to locate servers and discover routes. A client implementation can handle this by having a configured list of IP addresses of all servers and routers, optionally including a broadcast address or multicast address when available.
IPX normally broadcasts to find servers. On the Internet, that doesn't work, so administrators keep a list of server addresses and the client sends separate messages to each one.
§5Maximum Transmission Unit and Security
The standard maximum transmission unit for IPX is 576 octets. With the 8-octet UDP header and 20-octet IP header, the resulting IP packets are 604 octets long, which exceeds the minimum 576 octets that all IP implementations are required to accept. Any IP implementation supporting IPX encapsulation must be capable of receiving 604-octet IP packets, and implementations should make the IPX maximum transmission unit configurable as protocols and hardware improve. Using an IP internet instead of physical cabling introduces security risks not normally encountered in isolated IPX networks. Physical media are typically protected from outside access, while IP internets invite outside access. The security of the entire IPX internetwork depends on the security of the entire IP internet through which it tunnels. Possible attacks include unauthorized IPX clients gaining access through password cracking, unauthorized IPX gateways diverting traffic to unintended routes, and unauthorized agents monitoring or manipulating IPX traffic on physical media controlled by them. IPX network administrators must be aware of these additional security risks.
IPX packets are 576 bytes, but with IP and UDP headers they become 604 bytes. IPX tunneled through the Internet has the same security problems as any other Internet application, but Novell admins need to know about them.