RFC 851
ARPANET 1822L Host Access Protocol
RFC 851 🎀
The ARPANET 1822L Host Access Protocol ✨
Request for Comments: 851
Obsoletes: RFC 802 (it also updates RFC 802, which the intro spells out)
Author: Andrew G. Malis 💅
ARPANET Mail: malis@bbn-unix
Organisation: Bolt Beranek and Newman Inc., 50 Moulton St., Cambridge, MA 02238
Date: April 1983 🌸
Abstract 💖
Okay, so this RFC specifies the ARPANET 1822L Host Access Protocol, which is the successor to the existing 1822 Host Access Protocol 🦋. The big upgrade is that 1822L lets ARPANET hosts use logical names as well as 1822's physical port locations to find each other. It's also being put out there as a solicitation of comments on 1822L, especially from host network software implementers and maintainers, so if you build this stuff, your opinion literally matters 🫶.
Table of Contents 🧚
1 INTRODUCTION.......................................... 1
2 THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4
2.1 Addresses and Names................................. 6
2.2 Name Translations................................... 8
2.2.1 Authorization and Effectiveness................... 8
2.2.2 Translation Policies............................. 11
2.2.3 Reporting Destination Host Downs................. 13
2.2.4 1822L and 1822 Interoperability.................. 16
2.3 Uncontrolled Packets............................... 18
2.4 Establishing Host-IMP Communications............... 20
2.5 Counting RFMS When Using 1822L..................... 22
2.6 1822L Name Server.................................. 24
3 1822L LEADER FORMATS................................. 27
3.1 Host-to-IMP 1822L Leader Format.................... 28
3.2 IMP-to-Host 1822L Leader Format.................... 35
4 REFERENCES........................................... 43Figures 🌈
1822 Address Format....................................... 6
1822L Name Format......................................... 7
1822L Address Format...................................... 7
Communications between different host types.............. 17
Host-to-IMP 1822L Leader Format.......................... 28
NDM Message Format....................................... 31
IMP-to-Host 1822L Leader Format.......................... 35
Name Server Reply Format................................. 391. INTRODUCTION 🌸
Okay bestie, so this RFC specifies the ARPANET 1822L Host Access Protocol, and the whole point is that it lets hosts use logical addressing 🧠. That means host names that don't care where the host physically sits on the ARPANET, and then they can talk to each other using those names. This new host access protocol is called the ARPANET 1822L (for Logical) Host Access Protocol, and it's the successor to the current ARPANET 1822 Host Access Protocol. The 1822 one is described in sections 3.3 and 3.4 of BBN Report 1822 [1] 📖.
Here's the tea ☕. 1822L uses different Host-IMP leaders than 1822 does, but the IMPs will keep supporting 1822 🙌. So hosts using either protocol can totally talk to each other, and the IMPs handle the translation automatically. No drama 💅.
There is one major restriction though, and I need you to clock it 👀. 1822L is only going to be implemented in C/30 IMPs, which means it's only usable by hosts connected to C/30 IMPs. Honeywell and Pluribus IMPs don't have enough memory to hold the new programs and tables, so they're out 😭. This also means logical addressing can't be used to identify a host on a non-C/30 IMP. On the ARPANET this is no problem because it only has C/30 IMPs. But if logical addressing gets used on any network that mixes C/30 and non-C/30 IMPs, this restriction is going to bite 💀.
The RFC's terminology is consistent with what's used in Report 1822, and any new terms get defined the first time they show up 📝. Familiarity with Report 1822 (section 3 in particular) is assumed, so go read it first, babe 🍓. As you'd expect, this RFC references Report 1822 a lot, so it uses a handy shorthand: "see 1822(x)" instead of "please refer to Report 1822, section x, for further details". Iconic efficiency ✨.
This RFC updates, and obsoletes, RFC 802. Here's what changed from that one 🦋:
- The Short Blocking Feature, which was also described in RFC 802, now gets its own RFC, RFC 852 [2]. It got moved out because it's completely independent of logical addressing 🎀.
- In section 2.2, descriptions of the three address selection policies and of host error handling have been added 🔥.
- In section 2.3, the IMP's uncontrolled packet service has been further improved. This applies to hosts using 1822 as well as 1822L 💜.
- Pointers on using RFNM counting with 1822L have been added as section 2.5 🌈.
- Section 2.6 describes the new "1822L name server" in the IMP. It uses two new Host-to-IMP messages so hosts can do their own name-to-address mapping, which is so main character energy 👑.
- In section 3.2, the subtypes for the type 15 (1822L Name or Address Error) IMP-to-Host message have been changed ⭐.
2. THE ARPANET 1822L HOST ACCESS PROTOCOL 👑
Okay so the ARPANET 1822L Host Access Protocol lets a host use logical addressing to communicate with other hosts on the ARPANET 💖. Basically, logical addressing lets hosts refer to each other by an 1822L name (see section 2.1), and that name doesn't depend on where a host physically is in the network 🧚. IEN 183 (also published as BBN Report 4473) [3] gives logical addressing a lot of justification, and honestly it's giving convincing 🙌. Among the advantages it cites are:
- The ability to refer to each host on the network by a name that's independent of its location on the network 🍓.
- Allowing different hosts to share the same host port on a time-division basis ⏰.
- Allowing a host to use multi-homing, where a single host uses more than one port to communicate with the network 🌸.
- Allowing several hosts that provide the same service to share the same name 🫶.
The main differences between the 1822 and 1822L protocols are the format of the leaders used to introduce messages between a host and an IMP, and the specification in those leaders of the source and/or destination host(s) 🦋. Hosts get to choose between the 1822 and 1822L protocols 💅. When a host comes up on an IMP, it declares itself to be an 1822 host or an 1822L host by the type of NOP message (see section 3.1) it uses 📣. Once it's up, a host can switch from one protocol to the other by issuing an appropriate NOP 🔄. Hosts that don't use 1822L are still addressable by hosts that do, and they can still communicate with them, and vice versa 🤝.
Another difference is that 1822 leaders are symmetric, while 1822L leaders are not 🪞. "Symmetric" means that in 1822, the exact same leader format is used for messages going in both directions between hosts and IMPs. So say a leader gets sent from a host over a cable that's looped back onto itself, either by a looping plug or faulty hardware. It would arrive right back at the host and look like a legal message from a real host, specifically the destination host of the original message 😱. In contrast, 1822L headers are not symmetric, and a host can detect that its connection to its IMP is looped by receiving a message with the wrong leader format. That lets the host take appropriate action once it spots the loop 🔍.
2.1. Addresses and Names 🏡
Alright, this section is where we figure out how hosts get identified. The 1822 protocol defines one form of host specification, and the 1822L protocol adds two more ways to identify network hosts. So there are three forms total: 1822 addresses, 1822L names, and 1822L addresses 🎀.
1822 addresses are the 24-bit host addresses found in 1822 leaders. They look like this:
1 8 9 24
+----------------+---------------------------------+
| | |
| Host number | IMP number |
| | |
+----------------+---------------------------------+
Figure 1. 1822 Address FormatThese fields are quite large, and the ARPANET will never use more than a fraction of the available address space 🌌. 1822 addresses are used in 1822 leaders only 📌.
1822L names are 16-bit unsigned numbers that serve as a logical identifier for one or more hosts 🧩. They have a much simpler format:
1 16
+--------------------------------+
| |
| 1822L name |
| |
+--------------------------------+
Figure 2. 1822L Name FormatThe 1822L names are just 16-bit unsigned numbers, except that bits 1 and 2 are not both zeros (see below) 👀. This allows over 49,000 hosts to be specified, which is a lot of hosts bestie 🤯.
1822 addresses can't be used in 1822L leaders. But there might be a need for an 1822L host to address a specific physical host port or an IMP fake host, and that's what 1822L addresses are for 🎯. 1822L addresses form a subset of the 1822L name space, and they have both bits 1 and 2 off. They look like this:
1 2 3 8 9 16
+---+---+------------+----------------+
| | | | |
| 0 | 0 | host # | IMP number |
| | | | |
+---+---+------------+----------------+
Figure 3. 1822L Address FormatThis format lets 1822L hosts directly address hosts 0-63 at IMPs 1-255 (IMP 0 does not exist, so don't even try 🙅). Note that the highest host numbers are reserved for addressing the IMP's internal fake hosts 🧪. At the time of writing, the IMP has seven fake hosts, so host numbers 57-63 address the IMP fake hosts, while host numbers 0-56 address real hosts external to the IMP. As the number of IMP fake hosts changes, this boundary point will also change, so keep that in mind 📍.
2.2. Name Translations ✨
Okay, last one for this part! There are a number of factors that determine how an 1822L name gets translated by the IMP into a physical address on the network 🔁. These factors include which translations are legal, and in what order
...so yeah, different translations for the same name should be attempted, which legal translations shouldn't be attempted because a particular host port is down, and how 1822 and 1822L hosts vibe together 🦋 These issues get covered in the following sections, so let's go 💖
2.2.1. Authorization and Effectiveness ✨
Every host on a C/30 IMP can have one or more 1822L names (logical addresses), whether it's using the 1822 or 1822L protocol to get on the network 🌸 Hosts using 1822L can then use these names to address the other hosts in the network, no matter where they physically are. Because of the implementation constraints I mentioned in the intro, hosts on non-C/30 IMPs can't be given 1822L names. To get around that, though, 1822L hosts can also use 1822L addresses to reach all of the other hosts 💅
Okay, so several questions pop up here: how are these names assigned, how do they become known to the IMPs (so translations to physical addresses can happen), and how do the IMPs know which host is currently using a shared port? 🤔 Let's answer them in order.
Names are assigned by a central network administrator. When each name is created, it gets assigned to a host (or a group of hosts) at one or more specific host ports. The host(s) are allowed to reside at those specific host ports, and nowhere else 🎀 If a host moves, it keeps the same name, but the administrator has to update the central database to reflect the new host port. Changes to this database get distributed to the IMPs by the Network Operations Center (NOC). For a while, the host may be allowed to reside at either (or both) the new and old ports. Once the correspondence between a name and one or more host ports where it may be used has been made official by the administrator, that name is said to be authorized. 1822L addresses, which actually refer to physical host ports, are always authorized in this sense 🧚
Once a host has been assigned one or more names, it has to let the IMPs know where it is and what name(s) it's using. There are two cases to consider, one for 1822L hosts and another for 1822 hosts. The following discussion only pertains to hosts on C/30 IMPs 🍓
When an IMP sees an 1822L host come up on a host port, the IMP has no way of knowing which host just popped up (several hosts may share the same port, or one host may prefer to be known by different names at different times) 🙈 So the host has to declare itself to the IMP before it can actually send and receive messages. This is handled by a new host-to-IMP message, the Name Declaration Message (NDM), which lists the names the host would like to be known by. The IMP checks its tables to see if each name is authorized, and sends an NDM Reply to the host saying which names were actually authorized and can now be used for sending and receiving messages (i.e., which names are effective). A host can also use an NDM message to change its list of effective names (it can add to and delete from the list) at any time. The only constraint on the host is that any names it wants to use can become effective only if they're authorized 🔥
In the second case, if a host comes up on a C/30 IMP using the 1822 protocol, the IMP automatically makes the first name it finds in its tables for that host become effective 👑 So even though the host is using the 1822 protocol, it can still receive messages from 1822L hosts via its 1822L name. Of course, it can also receive messages from an 1822L host via its 1822L address too. (Remember, the difference between 1822L names and addresses is that addresses correspond to physical locations on the network, while names are strictly logical identifiers.) The IMPs translate between the different leaders and send the proper leader in each case (see section 2.2.4) 💜
The third question has by now already been answered 🌈 When an 1822L host comes up, it uses the NDM message to tell the IMP which host it is (which names it's known by). So even if this is a shared port, the IMP knows which host is currently connected. Iconic ✨
Whenever a host goes down, its names automatically become non-effective. When it comes back up, it has to make them effective again 💀
2.2.2. Translation Policies 🌷
Several hosts can share the same 1822L name. If more than one of these hosts is up at the same time, any messages sent to that 1822L name will be delivered to just one of the hosts sharing that name, and a RFNM will be returned as usual. However, the sending host won't receive any indication of which host received the message, and subsequent messages to that name aren't guaranteed to go to the same host. Typically, hosts providing exactly the same service could share the same 1822L name this way 🫶
Similarly, when a host is multi-homed, the same 1822L name may refer to more than one host port (all connected to the same host). If the host is up on only one of those ports, that port will be used for all messages addressed to the host. However, if the host is up on more than one port, the message gets delivered over just one of those ports, and the subnet chooses which port to use. This port selection could change from message to message. If a host wants to make sure certain messages are delivered to it on specific ports, those messages can use either the port's 1822L address or a specific 1822L name that refers to that port alone 🦋
Three different address selection policies are available for the name mapping process. When translated, each name uses one of the three policies (the policy is pre-determined on a per-name basis). The three policies are:
- Attempt each translation in the order in which the physical addresses are listed in the IMP's translation tables, to find the first reachable physical host address. This list is always searched from the top whenever an uncontrolled packet is to be sent or an end-to-end connection has to be created. This is the most commonly used policy. 💖
- Selection of the closest physical address, which uses the IMP's routing tables to find the translation to the destination IMP with the least delay path. 🛣️
- Use load leveling. This is similar to the second policy, but differs in that searching the address list for a valid translation starts at the address following where the previous translation search ended. This attempts to spread out the load from any one IMP's hosts to the various host ports associated with a particular name. Note that this is NOT network-wide load leveling, which would require a distributed algorithm and tables. 🌸
2.2.3. Reporting Destination Host Downs 🚨
As was explained in report 1822, and as will be discussed in greater detail in section 2.5, whenever regular messages are sent by a host, the IMP opens a subnetwork connection to each destination host from the source host. A connection will stay open at least as long as there are any outstanding (un-RFNMed) messages using it and both the source and destination hosts stay up 🧸
However, the destination host may go down for some reason during the lifetime of a connection. If the host goes down while there are no outstanding messages to it in the network, then the connection is closed and no other action is taken until the source host submits the next message for that destination. At that time, ONE of the following events will occur:
A1. If 1822 or an 1822L address is being used to specify the destination host, then the source host will receive a type 7 (Destination Host Dead) message from the IMP. 💀 A2. If an 1822L name is being used to specify the destination host, and the name maps to only one authorized host port, then a type 7 message will also be sent to the source host. 🥺 A3. If an 1822L name is being used to specify the destination host, and the name maps to more than one authorized host port, then the IMP attempts to open a connection to another authorized and effective host port for that name. If no such connection can be made, the host will receive a type 15 (1822L Name or Address Error), subtype 5 (no effective translations) message (see section 3.2). Note that a type 7 message cannot be returned to the source host, since type 7 messages refer to a particular destination host port, and the name maps to more than one destination port. 🤯
Things get a bit more complicated if there are any outstanding messages on the connection when the destination host goes down. The connection will be closed, and one of the following will occur:
B1. If 1822 or an 1822L address is being used to specify the destination host, then the source host will receive a type 7 message for each outstanding message. 📭 B2. If an 1822L name is being used to specify the destination host, then the source host will receive a type 9 (Incomplete Transmission), subtype 3 (message lost due to network failure) message for each outstanding message. The next time the source host submits another message for that same destination name, the previous algorithm will be used (either step A2 or step A3). 🔁
The above two algorithms also apply when a host stays up, but declares the destination name for an existing connection to no longer be effective. In this case, however, the type 7 messages above will be replaced by type 15, subtype 3 (name not effective) messages 🙃
Section 2.3 discusses how destination host downs are handled for uncontrolled packets. 📦
2.2.4. 1822L and 1822 Interoperability 🌈
As has been previously stated, 1822 and 1822L hosts can intercommunicate, and the IMPs will automatically handle any necessary leader and address format conversions. However, not every combination of 1822 and 1822L hosts allows full interoperability with regard to the use of 1822L names. 🎀
The following figure illustrates how these addressing combinations are handled, showing how each type of host can
Okay so the big question is which hosts can talk to which, bestie 🧚 There are three types of hosts:
"1822 on C/30"signifies an 1822 host that is on a C/30 IMP,"1822L"signifies an 1822L host (on a C/30 IMP), and"1822 on non-C/30"signifies a host on an non-C/30 IMP (which cannot support the 1822L protocol).
The table entry shows the protocol and host address format(s) that the source host can use to reach the destination host. It's giving chart energy 📊✨
Destination Host
Source
Host | 1822 on C/30 | 1822L | 1822 on non-C/30
--------+----------------+----------------+-----------------
| | |
1822 on | 1822 | 1822 | 1822
C/30 | | (note 1) |
| | |
--------+----------------+----------------+-----------------
| | |
| 1822L, using | 1822L, using | 1822L, using
1822L | 1822L name or | 1822L name or | 1822L address
|address (note 2)| address | only (note 2)
| | |
--------+----------------+----------------+-----------------
| | |
1822 on | 1822 | 1822 | 1822
non-C/30| | (note 1) |
| | |
--------+----------------+----------------+-----------------Note 1: The message is presented to the destination host with an 1822L leader containing the 1822L addresses of the source and destination hosts. If either address cannot be encoded as an 1822L address, then the message is not delivered and an error message is sent to the source host. 🙈
Note 2: The message is presented to the destination host with an 1822 leader containing the 1822 address of the source host. 💜
Figure 4. Communications between different host types 🦋
2.3. Uncontrolled Packets ✨
Uncontrolled packets (see 1822(3.6)) are giving main character problem for the 1822L protocol 😭 They use none of the normal ordering and error-control mechanisms in the IMP, and they don't use the normal subnetwork connection facilities either. So uncontrolled packets have to carry all of their overhead with them, including source and destination names. If 1822L names are used when sending an uncontrolled packet, the subnetwork needs extra information when the packet is transferred to the destination IMP. The result is that less host-to-host data fits in the packet than is possible between 1822 hosts.
Uncontrolled packets sent between 1822 hosts may contain not more than 991 bits of data. Uncontrolled packets that are sent to and/or from 1822L hosts are limited to 32 bits less, or not more than 959 bits. Packets that exceed this length will result in an error indication to the host, and the packet will not be sent. This error indication is an upgrade to the old level of service, where the IMP would simply discard an overly long uncontrolled packet without telling anyone 🫶
Other upgrades for uncontrolled packet service include notifying the host about errors the host's IMP detects when it receives the packet. A host will be notified if:
- an uncontrolled packet contains an error in the 1822L name specification, such as if the name is not authorized or effective,
- the remote host is unreachable (which is indicated by none of its names being effective),
- network congestion control throttled the packet before it left the source IMP, or
- for any other reason the source IMP was not able to send the packet on its way.
In most cases, the host will not be notified if the uncontrolled packet was lost once it was transmitted by the source IMP. However, the IMP will attempt to notify the source host if a logically-addressed uncontrolled packet was mistakenly sent to a host that the source IMP thought was effective, but which turned out to be dead or non-effective at the destination IMP. This non-delivery notice is sent back to the source IMP as an uncontrolled packet from the destination IMP, so the source host is not guaranteed to receive this indication. 😬
If the source IMP successfully receives the non-delivery notice, then the source host will receive a type 15 (1822L Name or Address Error), subtype 6 (down or non-effective port) message. 🚨
If the packet is resubmitted or another packet is sent to the same destination name, and there are no available effective translations, then the source host will get one of these, depending on the destination name:
- a type 15, subtype 5 (no effective translations) message, if the destination name has more than one mapping, or
- either a type 7 (Destination Host Dead) or a type 15, subtype 3 (name not effective) message, if the destination name has a single translation.
Those enhancements to the uncontrolled packet service that are not specific to logical addressing will be available to hosts using 1822 as well as 1822L. However, logically-addressed uncontrolled packets must be used in order to receive any indication that the packet was lost once it has left the source IMP. So if you want the full tea ☕💅
2.4. Establishing Host-IMP Communications 🌸
When a host comes up on an IMP, or after there has been a break in the communications between the host and its IMP (see 1822(3.2)), the orderly flow of messages between the host and the IMP needs to be properly (re)established. This lets the IMP and host recover from most any failure in the other or in their communications path, including a break in mid-message. Literally the comeback arc 🦋
The first messages that a host should send to its IMP are three NOP messages. Three messages are required to insure that at least one message will be properly read by the IMP (the first NOP could be concatenated to a previous message if communications had been broken in mid-stream, and the third provides redundancy for the second). These NOPs serve several functions:
- they synchronize the IMP with the host,
- they tell the IMP how much padding the host requires between the message leader and its body, and
- they also tell the IMP whether the host will be using 1822 or 1822L leaders.
Similarly, the IMP will send three NOPs to the host when it detects that the host has come up. Actually, the IMP will send six NOPs, alternating three 1822 NOPs with three 1822L NOPs. Thus, the host will see three NOPs no matter which protocol it is using. 🧠 The NOPs will be followed by two Interface Reset messages, one of each style. If the IMP receives a NOP from the host while the above sequence is occurring, the IMP will only send the remainder of the NOPs and the Interface Reset in the proper style. The 1822 NOPs will contain the 1822 address of the host interface, and the 1822L NOPs will contain the corresponding 1822L address.
Once the IMP and the host have sent each other the above messages, regular communications can commence. See 1822(3.2) for further details concerning the ready line, host tardiness, and other issues. 🎀
2.5. Counting RFMS When Using 1822L 🧮
When a host submits a regular message using an 1822 leader, the IMP checks for an existing simplex virtual circuit connection from the source host to the destination host. If such a connection already exists, it is used. Otherwise, a new connection from the source host port to the destination host port is opened. In either case, there may be at most eight messages outstanding on that connection at any one time. If a host submits a ninth message on that connection before it receives a reply for the first message, then the host will be blocked until the reply is sent for the first message. 🛑
Such connections can stay open for some time, but they time out after three minutes of no activity, or they can be closed if there is contention for the connection blocks in either the source or destination IMP. However, a connection will never be closed as long as there are any outstanding messages on it. This lets a source host count the number of replies it has received for messages to each destination host address, so it can avoid being blocked by submitting a ninth outstanding message on any connection. 🧁
When a host submits a regular message using an 1822L leader, a similar process occurs, except that in this case, connections are distinguished by the source name/destination name combination. When the message is received from a host, the IMP first looks for an open connection for that same source name/destination name pair. If such a connection is found, then it is used, and no further name translation is performed. If, however, no open connection was found, then the destination name is translated, and a connection is opened to the physical host port. As long as there are any outstanding messages on the connection, it will stay open, and it will have the same restriction that only eight messages may be outstanding at any one time. Thus, a source host can still count replies to avoid being blocked, but they must be counted on a source name/destination name pair basis, instead of just by destination host address as before. 🧩
Since connections are based on the source name as well as the destination name, there may be more than one open connection from physical host port A to physical host port B. This would allow more than 8 outstanding messages simultaneously from the first to the second port. However, for this to occur, either the source or destination names, or both, must differ from one connection to the next. For example, if the names "543" and "677" both translate to physical port 3 on IMP 51, then the host on that port could open four connections to itself by sending messages from "543" to "543", from "543" to "677", from "677" to "543", and from "677" to "677". Four separate lanes, no cap 🛣️✨
As has already been stated, the destination names in regular messages are only translated when connections are first opened. Once a connection is open, that connection, and its destination physical host port, will continue to be used until it is closed. 💖
the leftover bit of 2.5 is basically "if a better destination shows up, you don't switch until you open a new connection to that name" 🌸 the old route stays put, bestie, no mid-connection surprises 🫶
2.6. 1822L Name Server
Sometimes a host wants to do its own translations 💅 or needs the full list of physical addresses a name maps to. Picture a connection-based host-to-host protocol that may require the same physical host port on a multi-homed host to be used for every message in that connection. If the host doesn't want to trust the IMP to always deliver messages for a destination name to the same host port, it needs another option 👑
That option is a type 11 (Name Server Request) message. The host sends it to the IMP and asks the IMP to translate the destination 1822L name and send back a list of the addresses it maps to. The IMP answers with a type 11 (Name Server Reply) message 🎀 That reply carries the selection policy in use for that name, the number of addresses the name maps to, the addresses themselves, and, for each address, whether it is effective and its routing distance from the IMP. Section 3.2 has the full breakdown of what's inside 🦋
Once the host has that info, it can make an informed choice about which of the physical host ports behind an 1822L name to use. It can then send messages straight to that port instead of to the name 🧚
The IMP also offers a different kind of name service 🌈 A host has to send a Name Declaration Message to the IMP to make its names effective, but it might not want to keep its names in a table or file on the host. For that case, the host can ask the IMP which names it is authorized to use 💖
So the host sends a type 12 (Port List Request) message to the IMP, and the IMP replies with a type 12 (Port List Reply) message. The reply includes, for the host port the IMP received the request on and sent the reply over, the number of names that map to that port, the list of those names, and whether each name is effective or not ✨ The host can then use that info to send the Name Declaration Message. Section 3.2 has the full scoop on the reply's contents 🫶
3. 1822L LEADER FORMATS
The next sections describe the formats of the leaders that come before messages between an 1822L host and its IMP 💜 They were designed to be as compatible with the 1822 leaders as possible. The second, fifth, and sixth words are identical in both leaders, and all of the existing 1822 leader functionality has been kept 😭 In the first word, the 1822 New Format Flag now also identifies the two types of 1822L leaders, and the Handling Type has moved to the second byte. The third and fourth words hold the Source and Destination 1822L Name, in that order 🌸
3.1. Host-to-IMP 1822L Leader Format
1 4 5 8 9 16
+--------+--------+----------------+
| | 1822L | |
| Unused | H2I | Handling Type |
| | Flag | |
+--------+--------+----------------+
17 20 21 22 24 25 32
+--------+-+------+----------------+
| |T|Leader| |
| Unused |R|Flags | Message Type |
| |C| | |
+--------+-+------+----------------+
33 48
+----------------------------------+
| |
| Source Host |
| |
+----------------------------------+
49 64
+----------------------------------+
| |
| Destination Host |
| |
+----------------------------------+
65 76 77 80
+-------------------------+--------+
| | |
| Message ID |Sub-type|
| | |
+-------------------------+--------+
81 96
+----------------------------------+
| |
| Unused |
| |
+----------------------------------+Figure 5. Host-to-IMP 1822L Leader Format
Bits 1-4: Unused, must be set to zero.
Bits 5-8: 1822L Host-to-IMP Flag 🦋 This field is set to decimal 13 (1101 in binary).
Bits 9-16: Handling Type 💅 This field is bit-coded to show the transmission characteristics the host wants for the connection. See 1822(3.3).
- Bit 9: Priority Bit. Messages with this bit on get treated as priority messages ✨
- Bits 10-16: Unused, must be zero.
Bits 17-20: Unused, must be zero.
Bit 21: Trace Bit 🔍 If it's equal to one, the message is marked for tracing as it moves through the network. See 1822(5.5).
Bits 22-24: Leader Flags 🎀
- Bit 22: A flag the destination host can use. See 1822(3.3) for how the IMP's TTY Fake Host uses it.
- Bits 23-24: Reserved for future use, must be zero.
Bits 25-32: Message Type 👑 This is the big one, so let's go:
- Type 0: Regular Message. All host-to-host communication happens through regular messages, which have several sub-types found in bits 77-80. Those sub-types are:
- 0: Standard. The IMP uses its full message and error control facilities, and host blocking may occur.
- 3: Uncontrolled Packet. The IMP does no message-control functions for this type of message, and network flow and congestion control may cause the packet to be lost. Also see 1822(3.6) and section 2.3.
- 4-15: Unassigned.
- Type 1: Error Without Message ID. See 1822(3.3).
- Type 2: Host Going Down. See 1822(3.3).
- Type 3: Name Declaration Message (NDM) 💌 The host uses this to declare which of its 1822L names are or aren't effective (see section 2.2.1), or to make all of its names non-effective. The first 16 bits of the NDM's data portion, after the leader and any leader padding, hold the number of 1822L names in the message. Next come the 1822L name entries, each 32 bits long. The first 16 bits of each entry are a 1822L name, and the second 16 bits are either the integer zero or one. Zero means the name should not be effective, and one means it should be effective. The IMP replies with an NDM Reply message (see section 3.2) showing which names are now effective and which aren't. Here's the NDM layout, leader included, with the leader in hexadecimal 🧁
1 16 17 32 33 48
+----------------+----------------+----------------+
| | | |
| 0D00 | 0003 | 0000 |
| | | |
+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+
| | | |
| 0000 | 0000 | 0000 |
| | | |
+----------------+----------------+----------------+
97 112 113 128 129 144
+----------------+----------------+----------------+
| | | |
| # of entries | 1822L name #1 | 0 or 1 |
| | | |
+----------------+----------------+----------------+
145 160 161 176
+----------------+----------------+
| | |
| 1822L name #2 | 0 or 1 | etc.
| | |
+----------------+----------------+Figure 6. NDM Message Format
An NDM with zero entries will make every currently effective name for the host non-effective 😭
- Type 4: NOP 🌷 This lets the IMP know which style of leader the host wants to use. A 1822L NOP means the host wants 1822L leaders, and an 1822 NOP means the host wants 1822 leaders. All the other remarks about the NOP message in 1822(3.3) still apply. The host should always send NOPs in groups of three to make sure the IMP receives them properly. Also see section 2.4 for more on how NOP is used.
- Type 8: Error with Message ID. See 1822(3.3).
- Type 11: Name Server Request 🔮 This lets the host use the IMP's logical addressing tables as a name server. The IMP translates the destination name in the 1822L leader and replies with a Name Server Reply message, which lists the physical host addresses that the destination name maps to.
- Type 12: Port List Request 🧚 This lets the physical host ask for the list of names that map to the host port the IMP received this request on. The
Okay so the IMP answers with a Port List Reply message 💌, which lists the names that map to the port. Everything else is unassigned: Types 5-7,9-10,13-255 🫶
- 32 -
Bits 33-48: Source Host:
Okay so this field holds one of the source host's 1822L names (or, if she'd rather, the 1822L address of the host port the message is sent over) 💖 The IMP doesn't auto-fill it like the 1822 protocol does, because a host can be known by several names and might want one specific name as the source. Messages from the same host don't all have to use the same name here. Each source name gets checked for authorization, effectiveness, and actually belonging to this host. Messages that fail any of those checks won't be delivered, and an error message gets sent back into the source host instead 😭 If the host puts its 1822L address here, that address gets checked to insure it really represents the host port where the message came from. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the source host's 1822L address (see figure 4 in section 2.2.4) ✨
Bits 49-64: Destination Host:
This field has the 1822L name or address of the destination host 🦋 If it's a name, the name gets checked for effectiveness, and if it isn't effective, an error message goes back to the source host.
- 33 -
If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the destination host's 1822L address (see figure 4 in section 2.2.4) 🎀
Bits 65-76: Message ID:
This is a host-specified identification used in all type 0 and type 8 messages, and it's also used in type 2 messages 🌸 In type 0 messages, bits 65-72 are also called the Link Field, and they should contain values from Assigned Numbers [4] that fit the host-to-host protocol being used.
Bits 77-80: Sub-type:
This field works as a modifier for message types 0, 2, 4, and 8 🧚
Bits 81-96: Unused, must be zero.
- 34 -
3.2. IMP-to-Host 1822L Leader Format
1 4 5 8 9 16
+--------+--------+----------------+
| | 1822L | |
| Unused | I2H | Handling Type |
| | Flag | |
+--------+--------+----------------+
17 20 21 22 24 25 32
+--------+-+------+----------------+
| |T|Leader| |
| Unused |R|Flags | Message Type |
| |C| | |
+--------+-+------+----------------+
33 48
+----------------------------------+
| |
| Source Host |
| |
+----------------------------------+
49 64
+----------------------------------+
| |
| Destination Host |
| |
+----------------------------------+
65 76 77 80
+-------------------------+--------+
| | |
| Message ID |Sub-type|
| | |
+-------------------------+--------+
81 96
+----------------------------------+
| |
| Message Length |
| |
+----------------------------------+Figure 7. IMP-to-Host 1822L Leader Format 📐
- 35 -
Bits 1-4: Unused and set to zero. 🫧
Bits 5-8: 1822L IMP-to-Host Flag:
This field is set to decimal 14 (1110 in binary) 🔥
Bits 9-16: Handling Type:
This has the value the source host assigned (see section 3.1). This field is only used in message types 0, 5-9, and 15 💅
Bits 17-20: Unused and set to zero.
Bit 21: Trace Bit:
If it's equal to one, the source host designated this message for tracing as it goes through the network 🕵️♀️ See 1822(5.5).
Bits 22-24: Leader Flags:
- Bit 22: Available as a destination host flag.
- Bits 23-24: Reserved for future use, set to zero.
Bits 25-32: Message Type:
- Type 0: Regular Message - All host-to-host communication happens via regular messages, which have several sub-types. The sub-type field (bits 77-80) is the same as sent in the host-to-IMP leader (see section 3.1).
- Type 1: Error in Leader - See 1822(3.4).
- Type 2: IMP Going Down - See 1822(3.4).
- 36 -
- Type 3: NDM Reply - This is a reply to the NDM host-to-IMP message (see section 3.1). It will have the same number of entries as the NDM message that is being replied to, and each listed 1822L name will be accompanied by a zero or a one (see figure 6). A zero signifies that the name is not effective, and a one means that the name is now effective.
- Type 4: NOP - The host should discard this message. It is used during initialization of the IMP/host communication. The Destination Host field will contain the 1822L Address of the host port over which the NOP is being sent. All other fields are unused.
- Type 5: Ready for Next Message (RFNM) - See 1822(3.4).
- Type 6: Dead Host Status - See 1822(3.4).
- Type 7: Destination Host or IMP Dead (or unknown) - See 1822(3.4).
- Type 8: Error in Data - See 1822(3.4).
- Type 9: Incomplete Transmission - See 1822(3.4).
- Type 10: Interface Reset - See 1822(3.4).
- Type 11: Name Server Reply - This is the reply to the Name Server Request host-to-IMP message 🔍 It contains a word with the selection policy and the number of physical addresses that the destination name maps to, followed by two words per physical address: the first word contains an 1822L address, and the second word contains a bit saying whether or not that particular translation is effective, plus the routing distance (in 6.4 ms units) to the address's IMP. In figure 8, EFF is 1 for effective and 0 for non-effective, and POL is a two-bit number indicating the selection policy for the name (see section 2.2.2):
- 0: First reachable.
- 1: Closest physical address.
- 2: Load leveling.
- 3: Unused.
- 37 -
- 38 -
1 16 17 32 33 48
+----------------+----------------+----------------+
| | | |
| 0E00 | 000B | 0000 |
| | | |
+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+
| | | |
| dest. name | 0000 | 0000 |
| | | |
+----------------+----------------+----------------+
97 112 113 128 129 144
+-+--------------+----------------+-+--------------+
|P| | |E| |
|O| # of addrs | 1822L addr #1 |F| routing dist |
|L| | |F| |
+-+--------------+----------------+-+--------------+
145 160 161 176
+----------------+-+--------------+
| |E| |
| 1822L addr #2 |F| routine dist | etc.
| |F| |
+----------------+-+--------------+Figure 8. Name Server Reply Format 🌈
- Type 12: Port List Reply - This is the reply to the Port List Request host-to-IMP message. It contains the number of names that map to this physical host port, followed by two words per name: the first word contains an 1822L name that maps to this port, and the second contains either a zero or a one, saying whether or not that particular translation is effective. The format is identical to the type 3 NDM Reply message (see figure 6).
- 39 -
- Type 15: 1822L Name or Address Error - This message is sent in response to a type 0 message from a host that had an erroneous Source Host or Destination Host field 🙈 Its sub-types are:
- 0: The Source Host 1822L name is not authorized or not effective.
- 1: The Source Host 1822L address does not match the host port used to send the message.
- 2: The Destination Host 1822L name is not authorized.
- 3: The physical host to which this singly-homed Destination Host name translated is authorized and up, but not effective. If the host was actually down, a type 7 message would be returned, not a type 15.
- 4: The Source or Destination Host field contains a 1822L name, but the host being addressed is on a non-C/30 IMP (see figure 4 in section 2.2.4).
- 5: The multi-homed Destination Host name is authorized, but has no available effective translations.
- 6: A logically-addressed uncontrolled packet was sent to a dead or non-effective host port. However, if
okay so if it gets resubmitted, there may be another effective host port that the IMP might be able to try sending the packet to 🦋
- 7: Logical addressing is not in use in this network. 🌸
- 8-15: Unassigned. 💅
- Types 13-14,16-255: Unassigned. 🫶
Bits 33-48: Source Host 🎀
For type 0 messages, this field holds the 1822L name or address of the host that started the message. All replies to the message should be sent to the host specified here 💌 For message types 5-9 and 15, this field holds the source host field from a previous type 0 message sent by this host ✨
Bits 49-64: Destination Host 🌈
For type 0 messages, this field holds the 1822L name or address that the message was sent to. This lets the destination host see how the source host specified it 👀 For message types 5-9 and 15, this field holds the destination host field from a previous type 0 message sent by this host 🧚
Bits 65-76: Message ID 🦋
For message types 0, 5, 7-9, and 15, this is the value the source host assigns to identify the message (see section 3.1). This field is also used by message types 2 and 6 💜
Bits 77-80: Sub-type 🍓
This field works as a modifier for message types 0-2, 5-7, 9, and 15 ✨
Bits 81-96: Message Length 💖
This field only appears in type 0, 3, 11, and 12 messages. It's the actual length in bits of the message (not counting the leader, leader padding, or hardware padding), as computed by the IMP 🔥
4. References 📚
- [1] Specifications for the Interconnection of a Host and an IMP, BBN Report 1822, December 1981 Revision.
- [2] A. Malis, The ARPANET Short Blocking Feature, Request For Comments 852, April 1983.
- [3] E. C. Rosen et. al., ARPANET Routing Algorithm Improvements, Internet Experimenter's Note 183 (also published as BBN Report 4473, Vol. 1), August 1980, pp. 55-107.
- [4] J. Postel, Assigned Numbers, Request For Comments 820, January 1983, p. 11.
Index 🎀
1822...................................................... 4
1822 address.............................................. 6
1822 host................................................. 5
1822L..................................................... 4
1822L address............................................. 7
1822L host................................................ 5
1822L name................................................ 6
address selection policy................................. 12
authorized................................................ 9
blocking................................................. 22
closest physical address................................. 13
connection............................................... 22
destination host..................................... 33, 41
effective................................................ 10
first reachable.......................................... 12
handing type......................................... 29, 36
host downs............................................... 13
leader flags......................................... 29, 36
link field............................................... 34
load leveling............................................ 13
logical addressing........................................ 4
message ID........................................... 34, 41
message length........................................... 42
message type......................................... 30, 36
multi-homing.............................................. 4
name server...................................... 24, 32, 37
NDM.................................................. 10, 30
NDM reply............................................ 10, 37
NOC....................................................... 9
NOP........................................... 5, 20, 32, 37
priority bit............................................. 29
regular message...................................... 30, 36
RFNM................................................. 22, 37
source host.......................................... 33, 41
standard message......................................... 30
sub-type............................................. 34, 42
symmetric................................................. 5
trace bit............................................ 29, 36
uncontrolled packet.................................. 18, 30That's the whole RFC, bestie! 🌈✨💅
📦 where this page comes from
- ietf: rfc851 1983-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms