RFC 1234

Tunneling IPX Traffic through IP Networks 🎀

okay bestie, here's the header info first so you know what we're dealing with 💅

• RFC: 1234 📜
• Stream: Network Working Group 🌸
• Author: D. Provan, Novell, Inc. ✨
• Date: June 1991 🗓️
• Category: IAB standards track protocol for the Internet community (the Status section below explains it) 🦋
• Obsoletes / updates: the header doesn't list anything it obsoletes or updates 🙈

---

Status of this Memo 📣

okay so this memo is about encapsulating IPX datagrams inside UDP packets so IPX traffic can travel across an IP internet 🚀 It specifies an IAB standards track protocol for the Internet community and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📋 Distribution of this memo is unlimited 💖

Introduction 🧚

so IPX (Internet Packet eXchange protocol) is the internetwork protocol that Novell's NetWare protocol suite uses 💜 For this paper, IPX is functionally equivalent to the Internet Datagram Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite [1]. This memo describes how to encapsulate IPX datagrams within UDP packets [2] so IPX traffic can ride across an IP internet [3] ✨

This RFC lets an IPX implementation see an entire IP internet as one single IPX network 🌈 An implementation of this memo encapsulates IPX datagrams in UDP packets the same way any hardware implementation would wrap them in that hardware's frames. So IPX networks can be connected across internets that carry only IP traffic. it's giving seamless 🫶

Packet Format 📦

each IPX datagram lives 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 that the Internet Assigned Numbers Authority allocated for this encapsulation method 🔌

As with any UDP application, the transmitting party has the option of skipping the checksum overhead by setting the UDP checksum to zero. But 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 hold 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 are made 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 there, IPX uses the six octet host number as the hardware address on that network.

Host numbers also show up in the IPX headers of packets from IPX's Routing Information Protocol (RIP) 📮 This gives end nodes and routers alike the hardware address info they need for forwarding packets across intermediate networks on the way to 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: you just discard the first two octets of the host number and you're left with 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 needs broadcast facilities so NetWare servers and IPX routers on the same network can find each other 👯 But internet-wide IP broadcast is neither appropriate nor available, so 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'll call this list the "peer list", the individual members "peers", and all the peers together (including the local node) the "peer group" 🧃 When IPX requests a broadcast, the encapsulation implementation fakes it by sending a separate unicast packet to each peer in the peer list.

Because each peer list is built by hand, several groups of peers can share the same IP internet without knowing about each other 🙈 That's different from a normal IPX network, where all peers find each other automatically through 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. not ideal, bestie 💀

The peer list could be implemented with IP multicast [4]. But multicast facilities aren't widely available yet, so no well-known multicast address has been assigned and no implementations using multicast exist 🥲 Once IP multicast gets deployed in IP implementations, it can be used by simply putting an IP multicast address for IPX servers and routers in the peer list. That multicast address would replace the IP addresses of all peers that will receive IP multicast packets sent from this peer 🦋

Broadcasts by Clients 💻

Typically, NetWare client nodes don't need to receive broadcasts, so client nodes on the IP internet normally wouldn't need to be included in the peer lists at the servers 🙌

On the other hand, clients on an IPX network need to send broadcasts to locate servers and discover routes 📡 A client implementation of UDP encapsulation can handle this with a configured list of the IP addresses of all servers and routers in the peer group running on the IP internetwork. Just like the peer list on a server, the client simulates the broadcast by sending a copy of the packet to each IP address in its list of IPX servers and routers. One of those IP addresses (maybe the only one) could be a broadcast address or, when available, a multicast address. This lets the client talk to 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. IP has a unicast redirect mechanism, but IPX end systems are responsible for discovering routing info by broadcasting a packet that asks for a router able to forward packets to the desired destination. If those packets don't 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 📏

Larger IPX packets are possible, but the standard maximum transmission unit for IPX is 576 octets. Consequently, 576 octets is the RECOMMENDED default maximum transmission unit for IPX packets sent with this encapsulation technique 📐 Add the eight octet UDP header and the 20 octet IP header, and the resulting IP packets will be 604 octets long. Note that this is bigger than the 576 octet maximum size IP implementations are REQUIRED to accept [3]. So 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 like an IP internet in a spot normally occupied by physical cabling brings in security problems you don't usually see in IPX internetworks 😳 Normal media are typically protected physically from outside access, but IP internets typically invite outside access. Yikes.

The general effect? The security of the entire IPX internetwork is only as good as the security of the entire IP internet it tunnels through 💀 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 risks are typical of any other application using an IP internet 🙄 They're only mentioned here because IPX isn't 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 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. Go read it, it's all there and it's SERIOUS 💀🔥

Author's Address 💌

Don Provan

Novell, Inc.

2180 Fortune Drive

San Jose, California, 95131

Phone: (408)473-8440

EMail: donp@Novell.Com

fin! that's the whole spec, slay 👑✨