home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1132.txt < prev    next >
Text File  |  1989-11-26  |  8KB  |  227 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  L. McLaughlin III
  8. Request for Comments: 1132                          The Wollongong Group
  9.                                                            November 1989
  10.  
  11.  
  12.    A Standard for the Transmission of 802.2 Packets over IPX Networks
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies a standard method of encapsulating 802.2 [1]
  18.    packets on networks supporting Novell's Internet Packet Exchange
  19.    Protocol [2] (IPX).  It obsoletes earlier documents detailing the
  20.    transmission of Internet packets over IPX networks.  It differs from
  21.    these earlier documents in that it allows for the transmission of
  22.    multiple network protocols over IPX and for the transmission of
  23.    packets through IPX bridges.  Distribution of this memo is unlimited.
  24.  
  25. Introduction
  26.  
  27.    The goal of this specification is to allow compatible and
  28.    interoperable implementations for transmitting Internet packets such
  29.    as the Internet Protocol [3] (IP) and Address Resolution Protocol [4]
  30.    (ARP) as well as the Connectionless-mode Network Protocol [5] (CLNP)
  31.    over IPX networks.
  32.  
  33.    IPX is a proprietary standard developed by Novell derived from
  34.    Xerox's Internet Datagram Protocol [6] (IDP). Defining the
  35.    encapsulation of the IEEE 802.2 Data Link Layer Standard over IPX in
  36.    terms of yet another 802.X Physical Layer standard allows for the
  37.    transmission of IP Datagrams as described in RFC 1042 [7].  This
  38.    document will focus on the implementation of that RFC over IPX
  39.    networks.
  40.  
  41. Description
  42.  
  43.    In general, this specification allows IPX networks to be used to
  44.    support any network protocol which can use the IEEE 802.2 Data Link
  45.    Layer specification.
  46.  
  47.    More specifically, IPX networks may be used to support IP networks
  48.    and subnetworks of any class.  By encapsulating IP datagrams within
  49.    IPX datagrams and assigning IP numbers to the hosts on a IPX network,
  50.    IP-based applications are supported on these hosts.  The addition of
  51.    an IP Gateway capable of encapsulating IP packets within 802.IPX
  52.    datagrams would allow those hosts on an IPX network to communicate
  53.    with the Internet.
  54.  
  55.  
  56.  
  57.  
  58. McLaughlin                                                      [Page 1]
  59.  
  60. RFC 1132            802.2 Packets over IPX Networks        November 1989
  61.  
  62.  
  63. Maximum Transmission Unit
  64.  
  65.    The maximum data size of a IPX datagram is 546 bytes.  As the
  66.    combined size of the 802.2 LLC and SNAP headers is 8 bytes, this
  67.    results in a Maximum Transmission Unit (MTU) of 538 bytes.
  68.  
  69. Address Mappings
  70.  
  71.    The mapping of Internet Protocol addresses to 802.IPX addresses is
  72.    done using the Address Resolution Protocol in the same fashion as
  73.    with other IEEE 802.X physical addresses.  However, the length of an
  74.    802.IPX physical address is 10 bytes rather than 2 or 6.  This 10
  75.    byte physical address consists of the 4 bytes of the IPX network
  76.    address followed by the 6 bytes of the IPX node address.
  77.  
  78. Byte Order
  79.  
  80.    The byte transmission order is "big-endian" [8].
  81.  
  82. Broadcast Addresses
  83.  
  84.    IPX packets may be broadcast by setting the IPX header Packet Type
  85.    field to 0x14, the Destination Network field to the local network
  86.    number, the the Destination Node field to 0xffffff, and the Immediate
  87.    Address field of the IPX Event Control Block to 0xffffff.
  88.  
  89. Unicast Addresses
  90.  
  91.    IPX packets may be unicast by setting the IPX header Packet Type
  92.    field to 0x04, the Destination Network field and Destination Node
  93.    field to those values found by address resolution, and the Immediate
  94.    Address field of the IPX Event Control Block to the physical address
  95.    of the destination node or the appropriate IPX bridge.
  96.  
  97. Checksum
  98.  
  99.    Like most IPX applications, this specification does not use IPX
  100.    checksum.
  101.  
  102. Reserved values
  103.  
  104.    The IPX socket 0x8060 has been reserved by Novell for the
  105.    implementation of this protocol.
  106.  
  107. Implementation
  108.  
  109.    The encapsulation of Internet packets within IPX networks has proved
  110.    to be quite useful.  Because the IPX interface insulates knowledge of
  111.  
  112.  
  113.  
  114. McLaughlin                                                      [Page 2]
  115.  
  116. RFC 1132            802.2 Packets over IPX Networks        November 1989
  117.  
  118.  
  119.    the physical layer from an application, 802.2 over IPX networks work
  120.    over any physical medium.  A typical IP over IPX packet is shown
  121.    below:
  122.  
  123.                               --------------------
  124.                     N bytes   |  physical header |
  125.                               |------------------|
  126.                    30 bytes   |    IPX header    |
  127.                               |------------------|
  128.                     8 bytes   |   802.2 header   |
  129.                               |------------------|
  130.            usually 20 bytes   |     IP header    |
  131.                               |------------------|
  132.            usually 20 bytes   |    TCP header    |
  133.                               |------------------|
  134.             up to 498 bytes   |    TCP data      |
  135.                               --------------------
  136.  
  137.    On workstations supporting an IPX programming interface,
  138.    implementation of this specification has proved fairly
  139.    straightforward.  The only change which was done was to modify the
  140.    existing address resolution protocol code to allow for cache entries
  141.    larger than the hardware address length.  This was done to allow room
  142.    for the immediate address of a possible intervening IPX bridge in
  143.    addition to the destination node and network addresses to be
  144.    associated with a given IP address.
  145.  
  146.    Thus far, no implementations have been attempted on systems which do
  147.    not already support an IPX programming interface (e.g., a dedicated
  148.    router) though a few implementation details can be noted.  First,
  149.    obviously any such implementation will have to distinguish IPX
  150.    packets from other packets; this process will be media dependent.
  151.    Second, note that no unicast packet is ever sent from host1 to host2
  152.    without a prior broadcast packet from host2 to host1.  Thus, the
  153.    immediate address of a possible intervening IPX bridge between host1
  154.    and host2 can be learned from the physical header of that prior
  155.    broadcast packet.  Third, any such implementation will need to
  156.    discover the local IPX network number from a Novell bridge or file
  157.    server.  The mechanisms for doing this exist but documentation for
  158.    their use is not commonly available.
  159.  
  160. References
  161.  
  162.   [1]  IEEE, "IEEE Standards for Local Area Networks: Logical Link
  163.        Control", IEEE, New York, 1985.
  164.  
  165.   [2]  Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange
  166.        Protocol (IPX) with Asynchronous Event Scheduler (AES)", October
  167.  
  168.  
  169.  
  170. McLaughlin                                                      [Page 3]
  171.  
  172. RFC 1132            802.2 Packets over IPX Networks        November 1989
  173.  
  174.  
  175.        1986.
  176.  
  177.   [3]  Postel, J., "Internet Protocol", RFC-791, USC/Information
  178.        Sciences Institute, September 1981.
  179.  
  180.   [4]  Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826,
  181.        November 1982.
  182.  
  183.   [5]  ISO DIS 8473: "Information Processing Systems - Data
  184.        Communications - Protocol for Providing the Connectionless-mode
  185.        Network Service".
  186.  
  187.   [6]  Xerox Corporation, "Xerox Network Systems Architecture", XNSG
  188.        068504, April 1985.
  189.  
  190.   [7]  Postel, J., and J. Reynolds, "A Standard for the Transmission of
  191.        IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information
  192.        Sciences Institute, February 1988.
  193.  
  194.   [8]  Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,
  195.        October 1981.
  196.  
  197. Security Considerations
  198.  
  199.    Security issues are not addressed in this memo.
  200.  
  201.  
  202. Author's Address:
  203.  
  204.    Leo J. McLaughlin III
  205.    The Wollongong Group
  206.    1129 San Antonio Road
  207.    Palo Alto, CA 94303
  208.  
  209.    Phone: (415) 962-7100
  210.  
  211.    EMail: ljm@TWG.COM
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. McLaughlin                                                      [Page 4]
  227.