802.2 over IPX: Standard for the transmission of 802.2 packets over IPX networks
How to carry IP, ARP and other 802.2 traffic inside Novell IPX datagrams, including across IPX bridges.
McLaughlin, L.J., "Standard for the transmission of 802.2 packets over IPX networks", STD 49, RFC 1132, DOI 10.17487/RFC1132, November 1989, <https://www.rfc-editor.org/info/rfc1132>.
@misc{rfc1132,
series = {Request for Comments},
number = 1132,
howpublished = {RFC 1132},
publisher = {RFC Editor},
doi = {10.17487/RFC1132},
url = {https://www.rfc-editor.org/info/rfc1132},
author = {L.J. McLaughlin},
title = {{Standard for the transmission of 802.2 packets over IPX networks}},
pagetotal = 4,
year = 1989,
month = nov,
} RFC text
Contents
Network Working Group L. McLaughlin III
Request for Comments: 1132 The Wollongong Group
November 1989
A Standard for the Transmission of 802.2 Packets over IPX Networks
Status of this Memo
This document specifies a standard method of encapsulating 802.2 [1]
packets on networks supporting Novell's Internet Packet Exchange
Protocol [2] (IPX). It obsoletes earlier documents detailing the
transmission of Internet packets over IPX networks. It differs from
these earlier documents in that it allows for the transmission of
multiple network protocols over IPX and for the transmission of
packets through IPX bridges. Distribution of this memo is unlimited.
Introduction
The goal of this specification is to allow compatible and
interoperable implementations for transmitting Internet packets such
as the Internet Protocol [3] (IP) and Address Resolution Protocol [4]
(ARP) as well as the Connectionless-mode Network Protocol [5] (CLNP)
over IPX networks.
IPX is a proprietary standard developed by Novell derived from
Xerox's Internet Datagram Protocol [6] (IDP). Defining the
encapsulation of the IEEE 802.2 Data Link Layer Standard over IPX in
terms of yet another 802.X Physical Layer standard allows for the
transmission of IP Datagrams as described in RFC 1042 [7]. This
document will focus on the implementation of that RFC over IPX
networks.
Description
In general, this specification allows IPX networks to be used to
support any network protocol which 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. By encapsulating IP datagrams within
IPX datagrams and assigning IP numbers to the hosts on a IPX network,
IP-based applications are supported on these hosts. The addition of
an IP Gateway capable of encapsulating IP packets within 802.IPX
datagrams would allow those hosts on an IPX network to communicate
with the Internet.
Maximum Transmission Unit
The maximum data size of a IPX datagram is 546 bytes. As the
combined size of the 802.2 LLC and SNAP headers is 8 bytes, this
results in a Maximum Transmission Unit (MTU) of 538 bytes.
Address Mappings
The mapping of Internet Protocol addresses to 802.IPX addresses is
done using the Address Resolution Protocol in the same fashion as
with other IEEE 802.X physical addresses. However, the length of an
802.IPX physical address is 10 bytes rather than 2 or 6. This 10
byte physical address consists of 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 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 field and Destination Node
field to those values found by address resolution, and the Immediate
Address field of the IPX Event Control Block to the physical address
of the destination node or the appropriate IPX bridge.
Checksum
Like most IPX applications, this specification does not use IPX
checksum.
Reserved values
The IPX socket 0x8060 has been reserved by Novell for the
implementation of this protocol.
Implementation
The encapsulation of Internet packets within IPX networks has proved
to be quite useful. Because the IPX interface insulates knowledge of
the physical layer from an application, 802.2 over IPX networks work
over any physical medium. A typical IP over IPX packet is shown
below:
--------------------
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 supporting an IPX programming interface,
implementation of this specification has proved fairly
straightforward. The only change which was done was to modify the
existing address resolution protocol code to allow for cache entries
larger than the hardware address length. This was done to allow room
for the immediate address of a possible intervening IPX bridge in
addition to the destination node and network addresses to be
associated with a given IP address.
Thus far, no implementations have been attempted on systems which do
not already support an IPX programming interface (e.g., a dedicated
router) though a few implementation details can be noted. First,
obviously any such implementation will have to distinguish IPX
packets from other packets; this process will be media dependent.
Second, note that no unicast packet is ever sent from host1 to host2
without a prior broadcast packet from host2 to host1. Thus, 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. Third, 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
their use is not 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.
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
ISO Plain Language
On this page
§1Purpose and Approach
The goal of RFC 1132 is compatible, interoperable transmission of Internet packets such as the Internet Protocol (IP), the Address Resolution Protocol (ARP) and the Connectionless-mode Network Protocol (CLNP) over networks supporting Novell's Internet Packet Exchange Protocol (IPX). IPX is a proprietary standard developed by Novell and derived from Xerox's Internet Datagram Protocol.
The document defines the encapsulation of the IEEE 802.2 data link layer standard over IPX in terms of yet another 802.X physical layer standard, which allows IP datagrams to be transmitted as described in RFC 1042. It obsoletes earlier documents on the transmission of Internet packets over IPX and differs from them by allowing multiple network protocols over IPX and by allowing packets to go through IPX bridges.
It is one rule for putting any 802.2 traffic into IPX packets, so several kinds of protocol can share the same IPX network.
§2Addresses and Byte Order
Internet Protocol addresses are mapped to 802.IPX addresses with the Address Resolution Protocol, in the same fashion as with other IEEE 802.X physical addresses. An 802.IPX physical address is 10 bytes rather than 2 or 6: the 4 bytes of the IPX network address followed by the 6 bytes of the IPX node address.
The byte transmission order is "big-endian". The IPX socket 0x8060 has been reserved by Novell for this protocol, and, like most IPX applications, this specification does not use the IPX checksum.
An address here is 10 bytes: the network number first, then the machine number. Bytes go on the wire largest first, and the IPX checksum is not used.
§3Broadcast, Unicast and MTU
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. For a unicast, Packet Type is set to 0x04, the Destination Network and Destination Node fields take the values found by address resolution, and the Immediate Address field is the physical address of the destination node or the appropriate IPX bridge.
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, which gives a Maximum Transmission Unit (MTU) of 538 bytes.
Sending to one computer and sending to everyone use different settings on the envelope, and the envelope holds at most 538 bytes of payload.
§4Implementation Notes
A typical IP over IPX packet is a physical header of N bytes, a 30-byte IPX header, an 8-byte 802.2 header, usually a 20-byte IP header, usually a 20-byte TCP header and up to 498 bytes of TCP data. Because the IPX interface insulates an application from the physical layer, 802.2 over IPX works over any physical medium. On workstations with an IPX programming interface, the only change needed was to allow address resolution cache entries larger than the hardware address length, so there is room for the immediate address of a possible intervening IPX bridge.
No implementations had been attempted on systems without an IPX interface, such as a dedicated router, but the RFC notes that no unicast packet is ever sent from one host to another without a prior broadcast packet from the other host, so the bridge's immediate address can be learned from the physical header of that broadcast. The memo does not address security.
A packet is a stack of labelled layers. A host can learn a bridge's address from the first broadcast it receives from the other side.