RFC 1132

RFC 1132: A Standard for the Transmission of 802.2 Packets over IPX Networks ✨

okay bestie, let's start with the title block 🎀

• RFC number: 1132
• Title: A Standard for the Transmission of 802.2 Packets over IPX Networks
• Author: L. McLaughlin III, The Wollongong Group (the Author's Address lists this as Leo J. McLaughlin III)
• Date: November 1989
• Category: not labelled in the title block, but the Status of this Memo calls it a standard method 🦋
• Obsoletes: earlier documents detailing the transmission of Internet packets over IPX networks 🧹
• Updates: not stated in this document

---

Status of this Memo 📜

so this doc specifies a standard method for encapsulating 802.2 [1] packets on networks that support Novell's Internet Packet Exchange Protocol [2] (IPX) 💜

It obsoletes earlier documents about sending Internet packets over IPX networks. It's different from those older docs because it allows multiple network protocols to travel over IPX, and it allows packets to go through IPX bridges. Distribution of this memo is unlimited 🌸

Introduction 🧚

The goal here is simple: compatible and interoperable implementations for sending Internet packets over IPX networks. That includes the Internet Protocol [3] (IP), the Address Resolution Protocol [4] (ARP), and the Connectionless-mode Network Protocol [5] (CLNP) 🍓

IPX is a proprietary standard made by Novell, and it's derived from Xerox's Internet Datagram Protocol [6] (IDP). Defining the encapsulation of the IEEE 802.2 Data Link Layer over IPX, as if IPX were yet another 802.X Physical Layer standard, lets you send IP Datagrams the way RFC 1042 [7] describes. This document focuses on implementing that RFC over IPX networks ✨

Description 💅

in general, this spec lets IPX networks support any network protocol that can use the IEEE 802.2 Data Link Layer specification 🔥

More specifically, IPX networks may be used to support IP networks and subnetworks of any class. You encapsulate IP datagrams inside IPX datagrams and assign IP numbers to the hosts on an IPX network, and then IP-based applications work on those hosts. Add an IP Gateway that can encapsulate IP packets within 802.IPX datagrams, and the hosts on an IPX network can talk to the Internet 🌈

Maximum Transmission Unit 📦

The maximum data size of an IPX datagram is 546 bytes. The combined size of the 802.2 LLC and SNAP headers is 8 bytes, so the Maximum Transmission Unit (MTU) ends up being 538 bytes 💖

Address Mappings 🗺️

IP addresses map to 802.IPX addresses using the Address Resolution Protocol, the same way it works with other IEEE 802.X physical addresses. The twist is that an 802.IPX physical address is 10 bytes long, not 2 or 6. That 10-byte address is the 4 bytes of the IPX network address followed by the 6 bytes of the IPX node address 🦄

Byte Order 🔢

The byte transmission order is "big-endian" [8] 🎀

Broadcast Addresses 📣

IPX packets may be broadcast by setting the IPX header Packet Type field to 0x14, the Destination Network field to the local network number, the Destination Node field to 0xffffff, and the Immediate Address field of the IPX Event Control Block to 0xffffff 📢

Unicast Addresses 🎯

IPX packets may be unicast by setting the IPX header Packet Type field to 0x04. The Destination Network and Destination Node fields get whatever values address resolution finds. The Immediate Address field of the IPX Event Control Block gets the physical address of the destination node or the appropriate IPX bridge 🫶

Checksum ✅

Like most IPX applications, this specification does not use an IPX checksum. No checksum for us, bestie 💀

Reserved values 🔒

The IPX socket 0x8060 has been reserved by Novell for implementing this protocol 🌈

Implementation 🛠️

Encapsulating Internet packets inside IPX networks has proved to be super useful. The IPX interface hides the physical layer from an application, so 802.2 over IPX networks work over any physical medium 👑

Here's what a typical IP over IPX packet looks like:

                              --------------------
                    N bytes   |  physical header |
                              |------------------|
                   30 bytes   |    IPX header    |
                              |------------------|
                    8 bytes   |   802.2 header   |
                              |------------------|
           usually 20 bytes   |     IP header    |
                              |------------------|
           usually 20 bytes   |    TCP header    |
                              |------------------|
            up to 498 bytes   |    TCP data      |
                              --------------------

On workstations that support an IPX programming interface, implementing this spec has proved fairly straightforward 🥰 The only change that was made was to modify the existing address resolution protocol code so it can handle cache entries larger than the hardware address length. That extra room holds the immediate address of a possible intervening IPX bridge, along with the destination node and network addresses associated with a given IP address.

So far, nobody has tried implementing this on systems that don't already support an IPX programming interface (for example, a dedicated router). Still, a few implementation details are worth noting 🧐

1. Obviously, any such implementation will have to tell IPX packets apart from other packets. How it does that is media dependent.
2. No unicast packet is ever sent from host1 to host2 without a prior broadcast packet from host2 to host1. So the immediate address of a possible intervening IPX bridge between host1 and host2 can be learned from the physical header of that prior broadcast packet 👀
3. Any such implementation will need to discover the local IPX network number from a Novell bridge or file server. The mechanisms for doing this exist, but documentation for using them isn't commonly available 📚

References 📖

• [1] IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, 1985.
• [2] Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange Protocol (IPX) with Asynchronous Event Scheduler (AES)", October 1986.
• [3] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981.
• [4] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
• [5] ISO DIS 8473: "Information Processing Systems - Data Communications - Protocol for Providing the Connectionless-mode Network Service".
• [6] Xerox Corporation, "Xerox Network Systems Architecture", XNSG 068504, April 1985.
• [7] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information Sciences Institute, February 1988.
• [8] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, October 1981.

Security Considerations 🚨

Security issues are not addressed in this memo. 😱 Please keep this in mind before you rely on this spec for anything sensitive, because this memo doesn't cover security at all. 🙈

Author's Address 💌

Leo J. McLaughlin III
The Wollongong Group
1129 San Antonio Road
Palo Alto, CA 94303

Phone: (415) 962-7100

EMail: ljm@TWG.COM