home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1234 < prev    next >
Text File  |  1991-06-21  |  12KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Provan
  8. Request for Comments: 1234                                  Novell, Inc.
  9.                                                                June 1991
  10.  
  11.  
  12.                Tunneling IPX Traffic through IP Networks
  13.  
  14. Status of this Memo
  15.  
  16.    This memo describes a method of encapsulating IPX datagrams within
  17.    UDP packets so that IPX traffic can travel across an IP internet.
  18.    This RFC specifies an IAB standards track protocol for the Internet
  19.    community, and requests discussion and suggestions for improvements.
  20.    Please refer to the current edition of the "IAB Official Protocol
  21.    Standards" for the standardization state and status of this protocol.
  22.    Distribution of this memo is unlimited.
  23.  
  24. Introduction
  25.  
  26.    Internet Packet eXchange protocol (IPX) is the internetwork protocol
  27.    used by Novell's NetWare protocol suite.  For the purposes of this
  28.    paper, IPX is functionally equivalent to the Internet Datagram
  29.    Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite
  30.    [1].  This memo describes a method of encapsulating IPX datagrams
  31.    within UDP packets [2] so that IPX traffic can travel across an IP
  32.    internet [3].
  33.  
  34.    This RFC allows an IPX implementation to view an IP internet as a
  35.    single IPX network.  An implementation of this memo will encapsulate
  36.    IPX datagrams in UDP packets in the same way any hardware
  37.    implementation might encapsulate IPX datagrams in that hardware's
  38.    frames.  IPX networks can be connected thusly across internets that
  39.    carry only IP traffic.
  40.  
  41. Packet Format
  42.  
  43.    Each IPX datagram is carried in the data portion of a UDP packet.
  44.    All IP and UDP fields are set normally.  Both the source and the
  45.    destination ports in the UDP packet should be set to the UDP port
  46.    value allocated by the Internet Assigned Numbers Authority for the
  47.    implementation of this encapsulation method.
  48.  
  49.    As with any UDP application, the transmitting party has the option of
  50.    avoiding the overhead of the checksum by setting the UDP checksum to
  51.    zero.  Since IPX implementations never use the IPX checksum to guard
  52.    IPX packets from damage, UDP checksumming is highly recommended for
  53.    IPX encapsulation.
  54.  
  55.  
  56.  
  57.  
  58. Provan                                                          [Page 1]
  59.  
  60. RFC 1234                       IPX on IP                       June 1991
  61.  
  62.  
  63.    +---------------------+------------+-------------------------------+
  64.    |                     |            |             |                 |
  65.    |     IP Header       | UDP Header | IPX Header  | IPX packet data |
  66.    | (20 or more octets) | (8 octets) | (30 octets) |                 |
  67.    |                     |            |             |                 |
  68.    +---------------------+------------+-------------------------------+
  69.  
  70.          Figure 1: An IPX packet carried as data in a UDP packet.
  71.  
  72. Reserved Packets
  73.  
  74.    The first two octets of the IPX header contain the IPX checksum.  IPX
  75.    packets are never sent with a checksum, so every IPX header begins
  76.    with two octets of FF hex.  Implementations of this encapsulation
  77.    scheme should ignore packets with any other value in the first two
  78.    octets immediately following the UDP header.  Other values are
  79.    reserved for possible future enhancements to this encapsulation
  80.    protocol.
  81.  
  82. Unicast Address Mappings
  83.  
  84.    IPX addresses consist of a four octet network number and a six octet
  85.    host number.  IPX uses the network number to route each packet
  86.    through the IPX internet to the destination network.  Once the packet
  87.    arrives at the destination network, IPX uses the six octet host
  88.    number as the hardware address on that network.
  89.  
  90.    Host numbers are also exchanged in the IPX headers of packets of
  91.    IPX's Routing Information Protocol (RIP).  This supplies end nodes
  92.    and routers alike with the hardware address information required for
  93.    forwarding packets across intermediate networks on the way towards
  94.    the destination networks.
  95.  
  96.    For implementations of this memo, the first two octets of the host
  97.    number will always be zero and the last four octets will be the
  98.    node's four octet IP address.  This makes address mapping trivial for
  99.    unicast transmissions: the first two octets of the host number are
  100.    discarded, leaving the normal four octet IP address.  The
  101.    encapsulation code should use this IP address as the destination
  102.    address of the UDP/IP tunnel packet.
  103.  
  104. Broadcasts between Peer Servers
  105.  
  106.    IPX requires broadcast facilities so that NetWare servers and IPX
  107.    routers sharing a network can find one another.  Since internet-wide
  108.    IP broadcast is neither appropriate nor available, some other
  109.    mechanism is required.  For this memo, each server and router should
  110.    maintain a list of the IP addresses of the other IPX servers and
  111.  
  112.  
  113.  
  114. Provan                                                          [Page 2]
  115.  
  116. RFC 1234                       IPX on IP                       June 1991
  117.  
  118.  
  119.    routers on the IP internet.  I will refer to this list as the "peer
  120.    list", to individual members as "peers", and to all the peers taken
  121.    together, including the local node, as the "peer group".  When IPX
  122.    requests a broadcast, the encapsulation implementation simulates the
  123.    broadcast by transmitting a separate unicast packet to each peer in
  124.    the peer list.
  125.  
  126.    Because each peer list is constructed by hand, several groups of
  127.    peers can share the same IP internet without knowing about one
  128.    another.  This differs from a normal IPX network in which all peers
  129.    would find each other automatically by using the hardware's broadcast
  130.    facility.
  131.  
  132.    The list of peers at each node should contain all other peers in the
  133.    peer group.  In most cases, connectivity will suffer if broadcasts
  134.    from one peer consistently fail to reach some other peer in the
  135.    group.
  136.  
  137.    The peer list could be implemented using IP multicast [4], but since
  138.    multicast facilities are not widely available at this time, no well-
  139.    known multicast address has been assigned and no implementations
  140.    using multicast exist.  As IP multicast is deployed in IP
  141.    implementations, it can be used by simply including in the peer list
  142.    an IP multicast address for IPX servers and routers.  The IP
  143.    multicast address would replace the IP addresses of all peers which
  144.    will receive IP multicast packets sent from this peer.
  145.  
  146. Broadcasts by Clients
  147.  
  148.    Typically, NetWare client nodes do not need to receive broadcasts, so
  149.    normally NetWare client nodes on the IP internet would not need to be
  150.    included in the peer lists at the servers.
  151.  
  152.    On the other hand, clients on an IPX network need to send broadcasts
  153.    in order to locate servers and to discover routes.  A client
  154.    implementation of UDP encapsulation can handle this by having a
  155.    configured list of the IP addresses of all servers and routers in the
  156.    peer group running on the IP internetwork.  As with the peer list on
  157.    a server, the client implementation would simulate the broadcast by
  158.    sending a copy of the packet to each IP address in its list of IPX
  159.    servers and routers.  One of the IP addresses in the list, perhaps
  160.    the only one, could be a broadcast address or, when available, a
  161.    multicast address.  This allows the client to communicate with
  162.    members of the peer group without knowing their specific IP
  163.    addresses.
  164.  
  165.    It's important to realize that broadcast packets sent from an IPX
  166.    client must be able to reach all servers and routers in the server
  167.  
  168.  
  169.  
  170. Provan                                                          [Page 3]
  171.  
  172. RFC 1234                       IPX on IP                       June 1991
  173.  
  174.  
  175.    peer group.  Unlike IP, which has a unicast redirect mechanism, IPX
  176.    end systems are responsible for discovering routing information by
  177.    broadcasting a packet requesting a router that can forward packets to
  178.    the desired destination.  If such packets do not tend to reach the
  179.    entire server peer group, resources in the IPX internet may be
  180.    visible to an end system, yet unreachable by it.
  181.  
  182. Maximum Transmission Unit
  183.  
  184.    Although larger IPX packets are possible, the standard maximum
  185.    transmission unit for IPX is 576 octets.  Consequently, 576 octets is
  186.    the recommended default maximum transmission unit for IPX packets
  187.    being sent with this encapsulation technique.  With the eight octet
  188.    UDP header and the 20 octet IP header, the resulting IP packets will
  189.    be 604 octets long.  Note that this is larger than the 576 octet
  190.    maximum size IP implementations are required to accept [3].  Any IP
  191.    implementation supporting this encapsulation technique must be
  192.    capable of receiving 604 octet IP packets.
  193.  
  194.    As improvements in protocols and hardware allow for larger,
  195.    unfragmented IP transmission units, the 576 octet maximum IPX packet
  196.    size may become a liability.  For this reason, it is recommended that
  197.    the IPX maximum transmission unit size be configurable in
  198.    implementations of this memo.
  199.  
  200. Security Issues
  201.  
  202.    Using a wide-area, general purpose network such as an IP internet in
  203.    a position normally occupied by physical cabling introduces some
  204.    security problems not normally encountered in IPX internetworks.
  205.    Normal media are typically protected physically from outside access;
  206.    IP internets typically invite outside access.
  207.  
  208.    The general effect is that the security of the entire IPX
  209.    internetwork is only as good as the security of the entire IP
  210.    internet through which it tunnels.  The following broad classes of
  211.    attacks are possible:
  212.  
  213.    1)  Unauthorized IPX clients can gain access to resources through
  214.        normal access control attacks such as password cracking.
  215.  
  216.    2)  Unauthorized IPX gateways can divert IPX traffic to unintended
  217.        routes.
  218.  
  219.    3)  Unauthorized agents can monitor and manipulate IPX traffic
  220.        flowing over physical media used by the IP internet and under
  221.        control of the agent.
  222.  
  223.  
  224.  
  225.  
  226. Provan                                                          [Page 4]
  227.  
  228. RFC 1234                       IPX on IP                       June 1991
  229.  
  230.  
  231.    To a large extent, these security risks are typical of the risks
  232.    facing any other application using an IP internet.  They are
  233.    mentioned here only because IPX is not normally suspicious of its
  234.    media.  IPX network administrators will need to be aware of these
  235.    additional security risks.
  236.  
  237. Assigned Numbers
  238.  
  239.    The Internet Assigned Numbers Authority assigns well-known UDP port
  240.    numbers.  It has assigned port number 213 decimal to the IPX
  241.    encapsulation technique described in this memo [5].
  242.  
  243. Acknowledgements
  244.  
  245.    This encapsulation technique was developed independently by Schneider
  246.    & Koch and by Novell.  I'd like to thank Thomas Ruf of Schneider &
  247.    Koch for reviewing this memo to confirm its agreement with the
  248.    Schneider & Koch implementation and also for his other valuable
  249.    suggestions.
  250.  
  251. References
  252.  
  253.    [1] Xerox, Corp., "Internet Transport Protocols", XSIS 028112, Xerox
  254.        Corporation, December 1981.
  255.  
  256.    [2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
  257.        Sciences Institute, August 1980.
  258.  
  259.    [3] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
  260.  
  261.    [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
  262.        Stanford University, August 1989.
  263.  
  264.    [5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1060,
  265.        USC/Information Sciences Institute, March 1990.
  266.  
  267. Security Considerations
  268.  
  269.    See the "Security Issues" section above.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Provan                                                          [Page 5]
  283.  
  284. RFC 1234                       IPX on IP                       June 1991
  285.  
  286.  
  287. Author's Address
  288.  
  289.    Don Provan
  290.    Novell, Inc.
  291.    2180 Fortune Drive
  292.    San Jose, California, 95131
  293.  
  294.    Phone: (408)473-8440
  295.  
  296.    EMail: donp@Novell.Com
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Provan                                                          [Page 6]
  339.