Transmitting IP traffic over ARCNET networks
obsoletes
- rfc-1051 — Standard for the transmission of IP datagrams and ARP packets over ARCNET networks
also
- std-46
Extracted elements (23)
An optimum IP packet size of 504 octets is recommended to avoid ARCNET datalink fragmentation overhead. Implementations may signal this preference via the TCP MSS option (464-octet segments) or an MTU discovery mechanism announcing a 504-octet IP MTU.
ARP-based address resolution is preferred over static IP-to-ARCNET address mapping (e.g., using the low 8 bits of the IP address). Although hard-wired mapping is initially appealing, ARP provides much greater flexibility at negligible cost.
Reassembly implementations are recommended to allocate buffer space for the entire reassembled packet when the first fragment arrives, to avoid buffer allocation problems mid-reassembly. Since fragments are sent in order, reassembly may abort on an out-of-order fragment, but must silently ignore retransmitted duplicate fragments.
An older version of the ARCNET datalink protocol definition allowed only two fragments per packet (legal split flags: 0, 1, 2). Compatibility with that older standard can be maintained by configuring the maximum client data length to 1008 octets.
This specification obsoletes RFC 1051. The two encapsulations use different ARCNET protocol IDs and thus cannot communicate with each other, but they can coexist on the same physical ARCNET network.
All IP broadcast addresses MUST be mapped to the ARCNET broadcast address of 0. ARCNET does not guarantee delivery of broadcast packets, but this is acceptable since neither IP nor ARP require reliable broadcast delivery.
All IP multicast addresses MUST be mapped to the ARCNET broadcast address of 0, since ARCNET provides no native multicast support.
Broadcast ARCNET packets are never acknowledged by hardware and therefore MUST NOT be retransmitted by datalink implementations. Unicast packets and fragments that go unacknowledged are encouraged to be retransmitted.
Implementations must be able to send and receive IP datagrams up to 576 octets in length, and are strongly encouraged to handle datagrams up to 1500 octets. Implementations may accept arriving datagrams larger than their configured MTU and are not required to discard them.
The maximum ARCNET packet size MUST be configurable in all implementations of this specification, because the theoretical maximum of 60,480 octets is impractical and all nodes on an ARCNET must agree on a common MTU.
All fragments of a single ARCNET datalink packet carry the same 2-byte sequence number, allowing the receiver to associate fragments with their parent packet.
ARCNET datalink fragmentation supports up to 120 fragments per packet, allowing a maximum of 60,480 octets of client data per logical packet. Each frame carries at most 504 octets of client data.
ARP packets sent over ARCNET use a hardware address length of 1 octet (reflecting the 8-bit ARCNET address space), an ARP hardware type of 7, and a broadcast destination of ARCNET address 0.
IP and ARP datagrams are carried directly in the client data area of ARCNET frames. IP datagrams larger than 504 octets are fragmented across multiple ARCNET frames at the datalink layer.
RARP packets are transmitted over ARCNET identically to ARP at the datalink level. Notable differences from Ethernet: only 255 distinct hardware addresses exist, ARCNET addresses are switch-set (not ROM-fixed) and may be duplicated across networks.
Unicast IP addresses are mapped to 8-bit ARCNET hardware addresses using ARP. Direct static mapping based on the low 8 bits of the IP address is explicitly discouraged in favor of ARP.
Datapoint Corporation assigned ARCNET protocol IDs for this specification: 212 (decimal) for IP, 213 for ARP, and 214 for RARP. These differ from the protocol IDs used by RFC 1051, enabling coexistence of both encapsulations on the same ARCNET medium without interoperability.
IANA assigned ARP hardware type 7 to ARCNET, used in ARP and RARP packets to identify the ARCNET hardware address format (1 octet).
Security issues are not addressed in this memo.
ARCNET long frames are always 512 octets long and hold 253 to 504 octets of client data. They differ from short frames by adding a zero byte before the offset field in the software header.
ARCNET short frames are always 256 octets long and hold 0 to 249 octets of client data. They contain a source byte, destination byte, offset byte, unused padding, a protocol ID byte, a 1-byte split flag, a 2-byte sequence number, and client data.
Exception frames handle the gap of 250–252 octets of client data that cannot fit in short or long frames. They are structured like long frames but include a flag byte of 0xFF and two 0xFF padding bytes before repeating the protocol ID, split flag, and sequence number fields.
The split flag field encodes datalink fragmentation state: 0 for unfragmented packets; ((T-2)*2)+1 for the first fragment where T is total fragment count; ((N-1)*2) for subsequent fragments where N is the fragment index. The last fragment is identified because its split flag is one greater than the first fragment's value. Maximum legal split flag is 0xEE; 0xFF is reserved for exception frame detection.