IP over ARCNET: Transmitting IP traffic over ARCNET networks
How IP and ARP datagrams are wrapped, split into fragments and addressed on ARCNET local networks.
Provan, D., "Transmitting IP traffic over ARCNET networks", STD 46, RFC 1201, DOI 10.17487/RFC1201, February 1991, <https://www.rfc-editor.org/info/rfc1201>.
@misc{rfc1201,
series = {Request for Comments},
number = 1201,
howpublished = {RFC 1201},
publisher = {RFC Editor},
doi = {10.17487/RFC1201},
url = {https://www.rfc-editor.org/info/rfc1201},
author = {D. Provan},
title = {{Transmitting IP traffic over ARCNET networks}},
pagetotal = 7,
year = 1991,
month = feb,
} RFC text
Contents
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 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 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 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]. 2.2. Datalink Layer Fragmentation 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. 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. Unfragmented packets always have a split flag of zero. 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. 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 ). 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. 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. 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.) All fragments of a single packet carry the same sequence number. 2.3. Datalink Layer Reassembly The previous section provides enough information to implement datalink reassembly. To avoid buffer allocation problems during reassembly, we recommend allocating enough space for the entire reassembled packet when the first fragment arrives. 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. 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. 2.4. Datalink Layer Retransmission 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. 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. 3. Transmitting IP and ARP Datagrams 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. 4. IP Address Mappings This section explains how each of the three basic 32-bit internet address types are mapped to 8-bit ARCNET addresses. 4.1. Unicast Addresses 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. 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. 4.2. Broadcast Addresses All IP broadcast addresses must be mapped to the ARCNET broadcast address of 0. 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. 4.3. Multicast Addresses Since ARCNET provides no support for multicasts, all IP multicast addresses must be mapped to the ARCNET broadcast address of 0. 5. ARP 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. 6. RARP 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. 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. 7. Maximum Transmission Unit 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. 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. Implementations may accept arriving IP datagrams which are larger than their configured maximum transmission unit. They are not required to discard such datagrams. 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. 8. Assigned Numbers 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. The Internet Assigned Numbers Authority (IANA) assigns ARP hardware type values. It has assigned ARCNET the ARP hardware type of 7 [9]. Acknowledgements 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 smoothed out. The pioneering work in transmitting IP traffic on ARCNET networks was done by Philippe Prindeville. References [1] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981. [2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT, November 1982. [3] Datapoint, Corp., "ARCNET Designer's Handbook", Document Number 61610, 2nd Edition, Datapoint Corporation, 1988. [4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell, Inc., November 1989. [5] Prindeville, P., "A Standard for the Transmission of IP Datagrams and ARP Packets over ARCNET Networks", RFC 1051, McGill University, March 1988. [6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984. [7] Postel, J., "Transmission Control Protocol", RFC 793, DARPA, September 1981. [8] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU Discovery Options", RFC 1063, DEC, BBN, TWG, July 1988. [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. Security Considerations Security issues are not discussed in this memo. Author's Address Don Provan Novell, Inc. 2180 Fortune Drive San Jose, California, 95131 Phone: (408) 473-8440 EMail: donp@Novell.Com
AI ELI5
On this page
§1Introduction
This memo specifies a method of encapsulating Internet Protocol (RFC 791) and Address Resolution Protocol (RFC 826) datagrams for transmission across ARCNET, using the ARCNET Packet Header Definition Standard. It offers a replacement for RFC 1051, whose ARCNET framing protocol limits unfragmented IP packets to 508 octets.
The standard was agreed in 1989 by Apple Computers, Novell, ACTINET Systems, Standard Microsystems and Pure Data Research.
ARCNET is an older kind of office network. This document says how to put Internet messages into its envelopes, in a better way than the first attempt.
§2ARCNET Frames
ARCNET hardware supports two frame types: short frames, always 256 octets long, and long frames, always 512 octets long. Every frame starts with a hardware header and ends with the client's data preceded by a software header. Software puts padding in the middle to reach the fixed length, and the hardware removes it during transmission.
Short frames hold 0 to 249 octets of client data and long frames hold 253 to 504 octets. A third type, the exception frame, handles data of 250, 251 or 252 octets. The software header holds a protocol ID, a split flag and a two-octet sequence number.
There are small envelopes and big envelopes. For sizes that fit neither well, there is a special third envelope.
§3Fragmentation, Reassembly and Retransmission
ARCNET hardware limits a frame to 512 octets, or 504 octets of client data. The datalink protocol can break a packet into as many as 120 fragments, allowing up to 60,480 octets per packet. The split flag marks them. Unfragmented packets have a split flag of zero. The first fragment has ((T-2)*2)+1, where T is the total number of fragments. Later fragments have ((N-1)*2), where N is the fragment number, so the fourth fragment has six. The highest legal split flag value is EE hex, and FF hex marks exception packets. All fragments of one packet share a sequence number.
For reassembly, the RFC recommends allocating space for the whole packet when the first fragment arrives. Fragments are sent in order, so reassembly can give up if one arrives out of order, but it should ignore repeated fragments. It can also give up if no more fragments arrive within a few seconds.
The hardware tells the sender whether a unicast packet was acknowledged, so implementations are encouraged to retransmit unacknowledged packets or fragments. Broadcast packets are never acknowledged and should never be retransmitted. Retransmission can cause duplicates, which are not a problem for IP or ARP.
A big letter is cut into numbered pieces and sent in order. The receiver ignores doubles and gives up if the pieces stop coming.
§4Address Mapping, ARP and RARP
ARCNET addresses are 8 bits, so IP addresses must be mapped down. A unicast address is mapped using ARP. The RFC mentions that IP addresses could be assigned so the last eight bits equal the ARCNET address, but says this is not recommended because ARP is more flexible at very small cost. All IP broadcast addresses must map to the ARCNET broadcast address 0. ARCNET has no multicast support, so all IP multicast addresses must also map to address 0. Broadcasts may be lost, which does not greatly affect IP or ARP.
For ARP over ARCNET the hardware address length is 1 octet, the ARP hardware type is 7, and requests are broadcast to address 0.
RARP packets (RFC 903) can also be carried and are handled like ARP. The RFC notes three differences from Ethernet. There are only 255 hardware addresses on an ARCNET. They are more likely to be duplicated across ARCNET networks. And they are set by switches rather than fixed in ROM.
Each computer has a small number as its address. A computer shouts a question to everyone, address 0, to find who owns a number. Shouting to everyone is also how group messages work.
§5Maximum Transmission Unit
The maximum IP packet length with this method is 60,480 octets, which is impractical, so implementations on a network must agree on a smaller value and the maximum MUST be configurable. Implementations must be able to send and receive IP datagrams up to 576 octets and are strongly encouraged to handle 1500 octets. They may accept larger arriving datagrams.
To avoid datalink fragmentation, an implementation may aim at an IP packet size of 504 octets, at the cost of more packets for each node on the path. It might signal this with a TCP maximum segment size of 464 octets or announce an MTU of 504 octets through a mechanism such as RFC 1063.
Everyone on the network agrees how big a parcel can be. Smaller parcels avoid cutting, but then there are more of them.
§6Assigned Numbers and Security
Datapoint Corporation assigns ARCNET protocol IDs. For this specification it assigned 212 decimal to IP, 213 to ARP and 214 to RARP. These differ from the numbers used by RFC 1051, so both can exist on one ARCNET but cannot talk to each other. IANA assigned ARCNET the ARP hardware type 7.
The memo says that security issues are not discussed.
Each kind of message gets its own label number so the receiver knows what is inside. The old and new methods use different labels, so they ignore each other.
- 212IP — Internet Protocol datagrams.
- 213ARP — Address Resolution Protocol.
- 214RARP — Reverse Address Resolution Protocol.