RFC 696

Comments on IMP/HOST and HOST/IMP Protocol Changes ✨

Title block, bestie 🎀

• RFC: 696
• NIC: 32962
• Date: July 1975
• Author: V. Cerf, Stanford University
• Series: Network Working Group
• Obsoletes / Updates: Neither is listed in this header 💅

---

Okay so, this RFC is Vint Cerf (Stanford, obviously 🧚) responding to RFCs 687, 690, and 692 (NIC's 32564, 32699, and 32734, respectively). Those were written by D.C. Walden, J. Postel, and S. Wolfe, in that order. 💜

He wants to share some thoughts on current international standards recommendations from working group 6.1 of the International Federation of Information Processing. At a meeting last May at the NCC, that working group voted to send CCITT (International Consultative Committee on Telephony and Telegraphy of the International Telegraphics Union) a recommendation for a standard packet (or DATAGRAM) header. Iconic behaviour from WG 6.1 🙌

What This Header Is (And Isn't) 🦋

The proposed packet header is meant to connect hosts to packet networks. It is not a header for Host-to-Host protocol, and it is not an IMP-to-IMP header. Let's be clear about that 💖

The bulk of the header is addressing space, and it's giving 96 bits! 😭 That's because it's meant to be compatible with the current maximum address space of the telephone system, which is 14 digits.

The Fields 🌸

LOCAL NETWORK FIELD - 4 bits

This field lets local networks operate easily on multiple formats. The 4 bits can be used in any fashion the local network wants, so it's giving freedom 🍓

DATAGRAM FORMAT - 4 bits

ARPANET could put 1001 binary here, which keeps backward compatibility with the existing message leader format. Main character energy for the existing setup 👑

PACKET TYPE CODE - 8 bits

This could be used for the HOST/IMP and IMP/HOST code. Simple, cute, done ✨

FACILITIES - 16 bits

These bits haven't been specifically allocated yet. Some will definitely go to international services, like tracing at gateways between networks, accounting, and class of service. WG 6.1 members also felt some of these bits (for example, 8) might be allocated to the originating network (or destination network) for its own use. Honestly, this part is so thoughtful 🥹

TEXT LENGTH - 16 bits

These bits count the number of octets in the text of the packet. The header isn't counted, since it's fixed in length for any particular format. Clean and simple 💅

DESTINATION ADDRESS - 48 bits [1]

These bits could be split up like this: Destination Network Identifier - 8 bits; Destination Host Identifier - 8 bits; Destination IMP identifier - 16 bits; Reserved - 16 bits. The reserved part is giving "future me" energy 🔮

SOURCE ADDRESS - 48 bits

These bits would work similarly to the destination address bits. Twins 👯‍♀️

The Math Is Not Mathing 😬

The resulting packet is 144 bits long. Add the present 40-bit Host-to-Host header and you get 184 bits total. Not very pleasant, ngl 💀

Here's a temporary fix, until a new NCP design shows up: squeeze out the reserved 16-bit fields in the source and destination address fields. That gives 32 bits to carry the byte size and byte count information for the present Host/Host protocol.

Another option: use the length field of the packet header and one of the facilities flags (or a whole field) to indicate byte size and byte count. Both ideas would need some pretty big changes to existing NCP programs, so it's probably not very palatable. Lowkey a tough sell 🙈

A third idea is to add a dummy byte after the 144th bit of the header, followed by the 40 bits of NCP header. That makes the total length of message leader and NCP header 192 bits, which is divisible by 12, 16, 24, 32, and 48. Okay, that's actually kind of iconic 🌈

Bits vs. Bytes, Obviously 🧚

Bit lengths are the most flexible, but it's fair to admit that nearly all data transmission happens in 8-bit quantities. So bit lengths are, in fact, an unnecessary luxury. ngl that's a weak argument once 36-bit and 32-bit machines have to talk to each other, and the RFC says exactly that 🫠

---

That's the whole thing, bestie. Thanks for hanging with me through the bits 🦋💜

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Alex McKenzie with    ]
         [ support from GTE, formerly BBN Corp.            11/99 ]