summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1234.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1234.txt')
-rw-r--r--doc/rfc/rfc1234.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1234.txt b/doc/rfc/rfc1234.txt
new file mode 100644
index 0000000..1c5e81e
--- /dev/null
+++ b/doc/rfc/rfc1234.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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.
+
+
+
+
+Provan [Page 1]
+
+RFC 1234 IPX on IP June 1991
+
+
+ +---------------------+------------+-------------------------------+
+ | | | | |
+ | 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
+
+
+
+Provan [Page 2]
+
+RFC 1234 IPX on IP June 1991
+
+
+ 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
+
+
+
+Provan [Page 3]
+
+RFC 1234 IPX on IP June 1991
+
+
+ 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.
+
+
+
+
+Provan [Page 4]
+
+RFC 1234 IPX on IP June 1991
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Provan [Page 5]
+
+RFC 1234 IPX on IP June 1991
+
+
+Author's Address
+
+ Don Provan
+ Novell, Inc.
+ 2180 Fortune Drive
+ San Jose, California, 95131
+
+ Phone: (408)473-8440
+
+ EMail: donp@Novell.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Provan [Page 6]
+ \ No newline at end of file