RFC 730

RFC 730 💖 Extensible Field Addressing Written by Jon Postel of USC-ISI, dated 20 May 1977 🎀 Category: this one has no formal standards track status, it's a memo 🌸 It doesn't obsolete or update any other RFC ✨

---

1. Introduction 🦋

okay so bestie, this memo is all about why we should write network addresses as a set of fields instead of one big lump 💅 The big idea is that as the network grows, you can make the address bigger in three ways: stick new fields on the left, stick new fields on the right, or make the individual fields wider 🔥 Carl Sunshine came up with this style of addressing in his source routing paper [1], and honestly it's giving main character energy 👑

2. Motivation 🌈

2.1. Change in the Host-IMP Interface 🍓

the revised Host-IMP interface gives hosts and IMPs a much bigger address space [2] 😭 The old one had a 2 bit host field and a 6 bit IMP field, and the new one has an 8 bit host field and a 16 bit IMP field ✨ Back in the old days people just treated the two fields as one 8 bit number, and when they needed to name a host they'd often use a decimal number. So host 1 on IMP 1 became host 65 🙈 Doug Wells pointed out that continuing that habit with the new interface causes problems [3], ngl, and if they had used a per field notation from the start, none of this would have happened 💀

Here's a table of old and new host numbers:

  Host Name       Host IMP old #   new #
  --------------------------------------
  SRI-ARC            0   2     2       2
  UCLA-CCN           1   1    65   65537
  ISIA               1  22    86   65558
  ARPA-TIP           2  28   156  131100
  BBNA               3   5   197  196613

2.2. Multinetwork Systems 🧚

Connecting networks together to make a big complicated multinetwork system creates even more addressing problems 🫶 The new Host-IMP interface spec reserved some leader fields for carrying network addresses [2], and there's experimental work on interconnecting networks going on right now [4, 5, 6]. So we should totally be ready for these extensions to the address space ✨

The addressing scheme should be expandable so it can grow in scope when complex systems get interconnected 🦋

2.3. Multiprocessor Hosts 💜

Sometimes a bunch of processors gets hooked up to the network and shows up as a single host 🌸 Tasks can be tied to specific processors, so it might be useful to send network messages for certain sockets or message-ids to certain processors. For example, you might want all Telnet traffic handled by one processor and all FTP traffic by another 🔥

The addressing scheme should be expandable so it can explicitly address the fine structure inside a host when that's useful 👑

Here are some ARPANET examples where that fine structure addressing would've been a lifesaver:

At ISI, we have the capability of emulating computers using the PRIM system [7]. For many applications it is desirable to add the emulated host to the network. Since the emulation is carried out under control of a program operating under Tenex, we have a host within a host. Extensible addressing of hosts would provide the necessary handle.

SCRL once had a PDP-11 connected by VDH to an IMP at UCSB. It became necessary to add a second PDP-11 to the network. The two PDP-11s were already physically connected and it would have been a simple matter to have the first serve as a multiplexor for both. However, because of the limitations in the network addressing structure, there was no way to identify the two hosts to other sites on the network. A new IMP had to be installed!

In many other cases, it is desirable to have two hosts share the same front end to the network. With the current limitation, one IMP port must be consumed for each host.

(Yes, that last PDP-11 story is a whole mood 😭 they needed a second box and had to buy a whole new IMP just to name it 💀)

3. Proposal 🎀

The real fix for the Host-IMP interface change is to always represent addresses by fields 💅 This gives a natural path into an internetwork environment, and it lets you explicitly address the fine structure inside a host when you want to ✨

The fields should be written in a natural way. I believe the most general field should come first, with more and more specific fields after it 🌈 For the current case, that looks like this:

Network / IMP / Host / Message-Identifier

The catch with plain field addressing is that you might only write the fields you need for your local context. Then a program reading the address has no idea what the first field is supposed to mean 🙈 So the address needs some clues to be parsed correctly. Dave Crocker described a syntax for a similar problem in network data access [8] 🫶

3.1. Specific Suggestion 💖

Specifically, I suggest we adopt a field based extensible address scheme. Each field is separated from its neighbors by a delimiter character, and each field has a name. When you specify an address, you also have to indicate the name of the most general field ✨

  Definitions:

    <address> ::= <field-name> ":" <fields>

    <field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID"

    <fields> ::= <field> | <field> "/" <fields>

    <field> ::= a decimal number

  Examples:

    NET:1/3/5/7  names message-id 7 at host 5 on imp 3 in network 1.

    HOST:6  names host 6 on whatever imp this message originates on.

You might be thinking "what's all the fuss about, isn't this a non-problem?" 🙈 The honest answer is: almost. There are very few places where real difficulties show up, but we do have to change how we think about host addresses 💅 The places with problems are mostly little used, except for one. The big one humans will actually notice is the TIP "open" command [9], and to a lesser extent the user Telnet and user FTP "connect" commands. Other spots include the MAIL netaddress field, the FTP "sock" command [10], the Telnet reconnection option [11], and the NIC maintained list of official host names [12] 😭

4. Conclusion 🌸

The suggestion is that we adopt field based extensible addressing so it can grow in three ways 👑

(1) Growth in the number of hosts and IMPs, by letting these fields grow in size independently of each other 💜

(2) Growth in scope, by adding fields on the left to support multinetwork systems 🦋

(3) Growth in fine structure, by adding fields on the right so hosts can be implemented as mininetworks 🔥

References 📚

[1] Sunshine, C. "Source Routing and Computer Networks," Computer Communication Review, Vol. 7, Number 1, ACM Special Interest Group on Communications (SIGCOMM), January 1977. Also circulated as INWG General Note number 133.

[2] BBN, "The Interconnection of a Host and an IMP," Report 1822, Bolt Beranek and Newman, Revised January 1976.

[3] Wells, D., "Impact of New IMP Leaders on Higher-level Protocols," ARPA Network Message [MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 May 1977.

[4] Beeler, et.al. "Gateway Design for a Computer Network Interconnection," PRTN 156, February 1976.

[5] Cerf, V., Y. Dalal, and C. Sunshine. "Specification of an Internet Transmission Control Program," INWG General 72, RFC 675, Revised December 1974.

[6] Cerf, V. "Specification of TCP version 2," March 1977.

[7] Britt, B. et.al. "PRIM System: Overview," ISI/RR-77-58, Information Sciences Institute, University of Southern California, March 1977.

[8] Crocker, D., "Network Standard Data Specification Syntax," RFC 645, Network Information Center Catalog Number 30899, 27 June 1974.

[9] Malman, J., "User's Guide to the Terminal IMP," Report 2138, Bolt Beranek and Newman, Network Information Center Catalog Number 10916, Revised March 1976.

[10] Neigus, N., "File Transfer Protocol," RFC 542, Network Information Center Catalog Number 17759, 12 August 1973. Contained in "ARPANET Protocol Handbook," Network Information Center Catalog Number 7104, Revised 1 April 1976.

[11] Thomas, R., "Telnet Reconnection Option," Network Information Center Catalog Number 15391, August 1973. Contained in "ARPANET Protocol Handbook," Network Information Center Catalog Number 7104, Revised 1 April 1976.

[12] [Offfice-1]<NETINFO>HOSTS.TXT