doc: Add RFC documents

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