Transmitting IP traffic over ARCNET networks
RFC 1201

Document Type RFC - Internet Standard (February 1991; No errata)
Obsoletes RFC 1051
Also known as STD 46
Was draft-provan-iparcnet (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1201 (Internet Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          D. Provan
Request for Comments: 1201                                  Novell, Inc.
Obsoletes:  RFC 1051                                       February 1991

              Transmitting IP Traffic over ARCNET Networks

Status of this Memo

   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.

1.  Introduction

   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].

2.  ARCNET Packet Format

   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.

2.1.  ARCNET Framing

   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.

   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

Provan                                                          [Page 1]
RFC 1201                      IP on ARCNET                 February 1991

   introduces a third frame type: the exception frame.

   These three frame formats are shown here.  Except as noted, each
   block represents one octet.

       Short Frame             Long Frame          Exception Frame

    +---------------+      +---------------+      +---------------+
    |     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) .
                           .               .      .               .
                           +---------------+      +---------------+

      These packet formats are presented as software would see them
Show full document text