summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1132.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1132.txt')
-rw-r--r--doc/rfc/rfc1132.txt227
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1132.txt b/doc/rfc/rfc1132.txt
new file mode 100644
index 0000000..3c56384
--- /dev/null
+++ b/doc/rfc/rfc1132.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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.
+
+
+
+
+McLaughlin [Page 1]
+
+RFC 1132 802.2 Packets over IPX Networks November 1989
+
+
+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
+
+
+
+McLaughlin [Page 2]
+
+RFC 1132 802.2 Packets over IPX Networks November 1989
+
+
+ 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
+
+
+
+McLaughlin [Page 3]
+
+RFC 1132 802.2 Packets over IPX Networks November 1989
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McLaughlin [Page 4]
+ \ No newline at end of file