home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1201.txt < prev    next >
Text File  |  1996-05-07  |  17KB  |  199 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Provan Request for Comments: 1201                                  Novell, Inc. Obsoletes:  RFC 1051                                       February 1991 
  8.  
  9.                Transmitting IP Traffic over ARCNET Networks 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo defines a protocol for the transmission of IP and ARP    packets over the ARCnet Local Area Network.  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. 
  14.  
  15. 1.  Introduction 
  16.  
  17.    This memo specifies a method of encapsulating Internet Protocol (IP)    [1] and Address Resolution Protocol (ARP) [2] datagrams for    transmission across ARCNET [3] using the "ARCNET Packet Header    Definition Standard" [4].  This memo offers a replacement for RFC    1051.  RFC 1051 uses an ARCNET framing protocol which limits    unfragmented IP packets to 508 octets [5]. 
  18.  
  19. 2.  ARCNET Packet Format 
  20.  
  21.    In 1989, Apple Computers, Novell, ACTINET Systems, Standard    Microsystems, and Pure Data Research agreed to use the ARCNET    datalink protocol defined in "ARCNET Packet Header Definition    Standard" [4].  We'll begin with a brief description of that    protocol. 
  22.  
  23. 2.1.  ARCNET Framing 
  24.  
  25.    ARCNET hardware supports two types of frames: short frames, which are    always 256 octets long, and long frames, which are always 512 octets    long.  All frames begin with a hardware header and end with the    client's data preceded by a software header.  Software places padding    in the middle of the packet between the hardware header and the    software header to make the frame the appropriate fixed length.    Unbeknown to the software, the hardware removes this padding during    transmission. 
  26.  
  27.    Short frames can hold from 0 to 249 octets of client data.  Long    frames can hold from 253 to 504 octets of client data.  To handle    frames with 250, 251, or 252 octets of data, the datalink protocol 
  28.  
  29.  
  30.  
  31. Provan                                                          [Page 1] 
  32.  RFC 1201                      IP on ARCNET                 February 1991 
  33.  
  34.     introduces a third frame type: the exception frame. 
  35.  
  36.    These three frame formats are shown here.  Except as noted, each    block represents one octet. 
  37.  
  38.         Short Frame             Long Frame          Exception Frame 
  39.  
  40.     +---------------+      +---------------+      +---------------+     |     source    |      |     source    |      |     source    |     +---------------+      +---------------+      +---------------+     |  destination  |      |  destination  |      |  destination  |     +---------------+      +---------------+      +---------------+     |     offset    |      |       0       |      |       0       |     +---------------+      +---------------+      +---------------+     .     unused    .      |     offset    |      |     offset    |     .  (offset - 3  .      +---------------+      +---------------+     .     octets)   .      .     unused    .      .     unused    .     +---------------+      .  (offset - 4  .      .  (offset - 4  .     |  protocol ID  |      .     octets)   .      .     octets)   .     +---------------+      +---------------+      +---------------+     |  split flag   |      |  protocol ID  |      |  protocol ID  |     +---------------+      +---------------+      +---------------+     |   sequence    |      |  split flag   |      | flag: FF hex  |     +    number     +      +---------------+      +---------------+     |  (2 octets)   |      |   sequence    |      | padding: 0xFF |     +---------------+      +    number     +      +---------------+     .               .      |  (2 octets)   |      | padding: 0xFF |     .  client data  .      +---------------+      +---------------+     . (256 - offset .      .               .      | (protocol ID) |     .   - 4 octets) .      .               .      +---------------+     .               .      .               .      |  split flag   |     +---------------+      .               .      +---------------+                            .               .      |   sequence    |                            .  client data  .      +    number     +                            . (512 - offset .      |  (2 octets)   |                            .   - 4 octets) .      +---------------+                            .               .      .               .                            .               .      .  client data  .                            .               .      . (512 - offset .                            .               .      .   - 8 octets) .                            .               .      .               .                            +---------------+      +---------------+ 
  41.  
  42.       These packet formats are presented as software would see them       through ARCNET hardware.  [3] refers to this as the "buffer       format".  The actual format of packets on the wire is a little       different: the destination ID is duplicated, the padding between 
  43.  
  44.  
  45.  
  46. Provan                                                          [Page 2] 
  47.  RFC 1201                      IP on ARCNET                 February 1991 
  48.  
  49.        the offset field and the protocol ID field is not transmitted, and       there's some hardware framing information.  In addition, the       hardware transmits special packets for buffer allocation and       reception acknowledgement which are not described here [3]. 
  50.  
  51. 2.2.  Datalink Layer Fragmentation 
  52.  
  53.    ARCNET hardware limits individual frames to 512 octets, which allows    504 octets of client data.  This ARCNET datalink protocol allows the    datalink layer to break packets into as many as 120 fragments for    transmission.  This allows ARCNET clients to transmit up to 60,480    octets in each packet. 
  54.  
  55.    The "split flag" describes datalink layer packet fragments.  There    are three cases: an unfragmented packet, the first fragment of a    fragmented packet, and any other fragment of a fragmented packet. 
  56.  
  57.    Unfragmented packets always have a split flag of zero. 
  58.  
  59.    The first fragment of a fragmented packet has a split flag equal to    ((T-2)*2)+1, where T is the total number of fragments to expect for    the packet. 
  60.  
  61.    Subsequent fragments of a fragmented packet have a split flag equal    to ((N-1)*2), where N is the number of this fragment.  For example,    the fourth fragment of a packet will always have the split flag value    of six ( (4-1)*2 ). 
  62.  
  63.    The receiving station can identify the last fragment of a packet    because the value of its 8-bit split flag will be one greater than    the split flag of the first fragment of the packet. 
  64.  
  65.       A previous version of this ARCNET datalink protocol definition       only allowed packets which could be contained in two fragments.       In this older standard, the only legal split flags were 0, 1, and       2.  Compatibility with this older standard can be maintained by       configuring the maximum client data length to 1008 octets. 
  66.  
  67.    No more that 120 fragments are allowed.  The highest legal split flag    value is EE hex.  (Notice that the split flag value FF hex is used to    flag exception packets in what would otherwise be a long packet's    split flag field.) 
  68.  
  69.    All fragments of a single packet carry the same sequence number. 
  70.  
  71. 2.3.  Datalink Layer Reassembly 
  72.  
  73.    The previous section provides enough information to implement 
  74.  
  75.  
  76.  
  77. Provan                                                          [Page 3] 
  78.  RFC 1201                      IP on ARCNET                 February 1991 
  79.  
  80.     datalink reassembly.  To avoid buffer allocation problems during    reassembly, we recommend allocating enough space for the entire    reassembled packet when the first fragment arrives. 
  81.  
  82.    Since fragments are sent in order, the reassembly procedure can give    up on a packet if it receives a fragment out of order.  There is one    exception, however.  It is possible for successfully received    fragments to be retransmitted.  Reassembly software should ignore    repetitious fragments without giving up on the packet. 
  83.  
  84.    Since fragments will be sent briskly, the reassembly procedure can    give up on a partially reassembled packet if no additional fragments    for it arrive within a few seconds. 
  85.  
  86. 2.4.  Datalink Layer Retransmission 
  87.  
  88.    For each unicast ARCNET packet, the hardware indicates to the sender    whether or not the receiver acknowledged the packet.  To improve    reliability, datalink implementations are encouraged to retransmit    unacknowledged packets or packet fragments.  Several retransmissions    may be necessary.  Broadcast packets, however, are never acknowledged    and, therefore, they should never be retransmitted. 
  89.  
  90.    Packets which are successfully received may not be successfully    acknowledged.  Consequently, retransmission by the datalink    implementation can cause duplicate packets or duplicate fragments.    Duplicate packets are not a problem for IP or ARP.  As mentioned in    the previous section, ARCNET reassembly support should ignore any    redundant fragments. 
  91.  
  92. 3.  Transmitting IP and ARP Datagrams 
  93.  
  94.    IP and ARP datagrams are carried in the client data area of ARCNET    packets.  Datalink support places each datagram in an appropriate    size ARCNET frame, fragmenting IP datagrams larger than 504 octets    into multiple frames as described in the previous section. 
  95.  
  96. 4.  IP Address Mappings 
  97.  
  98.    This section explains how each of the three basic 32-bit internet    address types are mapped to 8-bit ARCNET addresses. 
  99.  
  100. 4.1.  Unicast Addresses 
  101.  
  102.    A unicast IP address is mapped to an 8-bit ARCNET address using ARP    as specified in [2].  A later section covers the specific values    which should be used in ARP packets sent on ARCNET networks. 
  103.  
  104.  
  105.  
  106.  Provan                                                          [Page 4] 
  107.  RFC 1201                      IP on ARCNET                 February 1991 
  108.  
  109.        It is possible to assign IP addresses such that the last eight       bits are the same as the 8-bit ARCNET address.  This would allow       direct mapping of IP address to ARCNET address without using a       discovery protocol.  Some implementations might provide this as an       option, but it is not recommended practice.  Although such hard-       wired mapping is initially appealing, experience shows that ARP is       a much more flexible and convenient approach which has a very       small cost. 
  110.  
  111. 4.2.  Broadcast Addresses 
  112.  
  113.    All IP broadcast addresses must be mapped to the ARCNET broadcast    address of 0. 
  114.  
  115.       Unlike unicast packets, ARCNET does not attempt to insure delivery       of broadcast packets, so they may be lost.  This will not have a       major impact on IP since neither IP nor ARP expect all packets to       be delivered. 
  116.  
  117. 4.3.  Multicast Addresses 
  118.  
  119.    Since ARCNET provides no support for multicasts, all IP multicast    addresses must be mapped to the ARCNET broadcast address of 0. 
  120.  
  121. 5.  ARP 
  122.  
  123.    The hardware address length is 1 octet for ARP packets sent over    ARCNET networks.  The ARP hardware type for ARCNET is 7.  ARP request    packets are broadcast by directing them to ARCNET broadcast address,    which is 0. 
  124.  
  125. 6.  RARP 
  126.  
  127.    Reverse Address Resolution Protocol [6] packets can also be    transmitted over ARCNET.  For the purposes of datalink transmission    and reception, RARP is identical to ARP and can be handled the same    way.  There are a few differences to notice, however, between RARP    when running over ARCNET, which has a one octet hardware address, and    Ethernet, which has a six octet hardware address. 
  128.  
  129.    First, there are only 255 different hardware addresses for any given    ARCNET while there's an very large number of possible Ethernet    addresses.  Second, ARCNET hardware addresses are more likely to be    duplicated on different ARCNET networks; Ethernet hardware addresses    will normally be globally unique.  Third, an ARCNET hardware address    is not as constant as an Ethernet address:  ARCNET hardware addresses    are set by switches, not fixed in ROM as they are on Ethernet. 
  130.  
  131.  
  132.  
  133.  Provan                                                          [Page 5] 
  134.  RFC 1201                      IP on ARCNET                 February 1991 
  135.  
  136.  7.  Maximum Transmission Unit 
  137.  
  138.    The maximum IP packet length possible using this encapsulation method    is 60,480 octets.  Since this length is impractical, all ARCNET    implementations on a given ARCNET network will need to agree on a    smaller value.  Therefore, the maximum packet size MUST be    configurable in implementations of this specification. 
  139.  
  140.    In any case, implementations must be able to send and receive IP    datagrams up to 576 octets in length, and are strongly encouraged to    handle IP datagrams up to 1500 octets in length. 
  141.  
  142.    Implementations may accept arriving IP datagrams which are larger    than their configured maximum transmission unit.  They are not    required to discard such datagrams. 
  143.  
  144.    To minimize the amount of ARCNET fragmentation, implementations may    want to aim at an optimum IP packet size of 504 bytes.  This avoids    the overhead of datalink fragmentation, but at the expense of    increasing the number of IP packets which must be handled by each    node in the path.  In addition to encouraging local applications to    generate smaller packets, an implementation might also use the TCP    maximum segment size option to indicate a desire for 464 octet TCP    segments [7], or it might  announce an IP MTU of 504 octets through    an MTU discovery mechanism such as [8].  These would inform non-    ARCNET nodes of the smaller optimum packet size. 
  145.  
  146. 8.  Assigned Numbers 
  147.  
  148.    Datapoint Corporation assigns ARCNET protocol IDs to identify    different protocols running on the same ARCNET medium.  For    implementations of this specification, Datapoint has assigned 212    decimal to IP, 213 decimal to ARP, and 214 decimal to RARP.  These    are not the numbers assigned to the IP encapsulation defined by RFC    1051 [5].  Implementations of RFC 1051 can exist on the same ARCNET    as implementations of this specification, although the two would not    be able to communicate with each other. 
  149.  
  150.    The Internet Assigned Numbers Authority (IANA) assigns ARP hardware    type values.  It has assigned ARCNET the ARP hardware type of 7 [9]. 
  151.  
  152. Acknowledgements 
  153.  
  154.    Several people have reviewed this specification and provided useful    input.  I'd like to thank Wesley Hardell at Datapoint and Troy Thomas    at Novell's Provo office for helping me figure out ARCNET.  In    addition, I particularly appreciate the effort by James VanBokkelen    at FTP Software who picked on me until all the fuzzy edges were 
  155.  
  156.  
  157.  
  158. Provan                                                          [Page 6] 
  159.  RFC 1201                      IP on ARCNET                 February 1991 
  160.  
  161.     smoothed out. 
  162.  
  163.    The pioneering work in transmitting IP traffic on ARCNET networks was    done by Philippe Prindeville. 
  164.  
  165. References 
  166.  
  167.    [1] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981. 
  168.  
  169.    [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826,        MIT, November 1982. 
  170.  
  171.    [3] Datapoint, Corp., "ARCNET Designer's Handbook", Document Number        61610, 2nd Edition, Datapoint Corporation, 1988. 
  172.  
  173.    [4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell,        Inc., November 1989. 
  174.  
  175.    [5] Prindeville, P., "A Standard for the Transmission of IP Datagrams        and ARP Packets over ARCNET Networks", RFC 1051, McGill        University, March 1988. 
  176.  
  177.    [6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse        Address Resolution Protocol", RFC 903, Stanford, June 1984. 
  178.  
  179.    [7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA,        September 1981. 
  180.  
  181.    [8] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU        Discovery Options", RFC 1063, DEC, BBN, TWG, July 1988. 
  182.  
  183.    [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,        USC/Information Sciences Institute, March 1990. 
  184.  
  185. Security Considerations 
  186.  
  187.    Security issues are not discussed in this memo. 
  188.  
  189. Author's Address 
  190.  
  191.    Don Provan    Novell, Inc.    2180 Fortune Drive    San Jose, California, 95131 
  192.  
  193.    Phone: (408) 473-8440    EMail: donp@Novell.Com 
  194.  
  195.  
  196.  
  197.  Provan                                                          [Page 7] 
  198.  
  199.