RFC 878
ARPANET 1822L Host Access Protocol
RFC 878: The ARPANET 1822L Host Access Protocol 💖
Part 1 of 6 🎀
Okay bestie, RFC 878 is giving a whole new protocol 🦋 and the header is serving main character energy. The author is Andrew G. Malis, who was at BBN Communications Corp., 50 Moulton St., Cambridge, MA 02238. You can reach him at ARPANET Mail: malis@bbn-unix 📬. It's dated December 1983 🍓.
The header says it obsoletes RFCs 851 and 802 🙈. In the body, it's clear that it updates and obsoletes RFC 851 specifically 🔥.
Here's the vibe: the RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L lets ARPANET hosts use logical names as well as 1822's physical port locations to address each other 🧚✨.
Here's the table of contents, shown as-is 📋:
1 INTRODUCTION.......................................... 1
2 THE ARPANET 1822L HOST ACCESS PROTOCOL................ 3
2.1 Addresses and Names................................. 5
2.2 Name Translations................................... 7
2.2.1 Authorization and Effectiveness................... 7
2.2.2 Translation Policies............................. 11
2.2.3 Reporting Destination Host Downs................. 13
2.2.4 1822L and 1822 Interoperability.................. 15
2.3 Uncontrolled Packets............................... 16
2.4 Establishing Host-IMP Communications............... 19
2.5 Counting RFNMs When Using 1822L.................... 20
2.6 1822L Name Server.................................. 23
3 1822L LEADER FORMATS................................. 25
3.1 Host-to-IMP 1822L Leader Format.................... 26
3.2 IMP-to-Host 1822L Leader Format.................... 34
4 REFERENCES........................................... 42
A 1822L-IP ADDRESS MAPPINGS............................ 43And here's the list of figures 🖼️:
2.1 1822 Address Format.................................. 5
2.2 1822L Name Format.................................... 6
2.3 1822L Address Format................................. 6
3.1 Host-to-IMP 1822L Leader Format..................... 27
3.2 NDM Message Format.................................. 30
3.3 IMP-to-Host 1822L Leader Format..................... 35
3.4 Name Server Reply Format............................ 38
A.1 1822 Class A Mapping................................ 44
A.2 1822L Class A Mapping............................... 44
A.3 1822L Class B Mapping............................... 45
A.4 1822L Class C Mapping............................... 461. INTRODUCTION ✨
Okay so this section is the setup 🎀.
This RFC specifies the ARPANET 1822L Host Access Protocol 💅, which lets hosts use logical addressing to talk to each other. Logical addressing means host names that don't care where a host physically sits on the ARPANET 📍. This new protocol is called the ARPANET 1822L (for Logical) Host Access Protocol 🧚. It's the successor to the current ARPANET 1822 Host Access Protocol, which is described in sections 3.3 and 3.4 of BBN Report 1822 [1].
Even though 1822L uses different Host-IMP leaders than 1822, the IMPs will keep supporting 1822. Hosts using either protocol can readily communicate with each other, because the IMPs handle the translation automatically 🤖💖.
The terminology here matches what's used in Report 1822, and any new terms get defined the first time they show up 📚. You're expected to already know Report 1822, especially section 3 🫶. This RFC references Report 1822 a lot, so it uses a handy shorthand: "see 1822(x)" stands in for "please refer to Report 1822, section x, for further details."
This RFC updates, and obsoletes, RFC 851 🔥. Here's what changed from that RFC:
- Section 2.2.4 was rewritten for clarity ✍️.
- Section 2.5 was expanded to further discuss the effects of using 1822L names on host-to-host virtual circuits.
- In section 3.2, the type 1 IMP-to-host message has two new subtypes, the type 9 message has one new subtype, and the type 15, subtype 4 message is no longer defined.
- An appendix describing the mapping between 1822L names and internet (IP) addresses has been added 🌈.
All of these changes to RFC 851 are marked by revision bars (as | shown here) in the right margin 🦋.
2. THE ARPANET 1822L HOST ACCESS PROTOCOL 👑
This is the main event, bestie 💜.
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). That name doesn't depend on a host's physical location in the network, which is so iconic 💅. IEN 183 (also published as BBN Report 4473) [2] gives logical addressing a lot of justification. Among the advantages it cites are:
- The ability to refer to each host on the network by a name 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 the 1822L protocol 💖. 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 the 1822L protocol will still be addressable by, and can communicate with, hosts that do, and vice-versa 🫶.
Another difference is that the 1822 leaders are symmetric, while the 1822L leaders are not 🪞. Symmetric means that in the 1822 protocol, the exact same leader format is used for messages going in both directions between the hosts and IMPs. For example, a leader sent from a host over a cable that was looped back onto itself (via a looping plug or faulty hardware) would arrive back at the host and look like a legal message from a real host, namely the destination host of the original message 😭. The 1822L headers, on the other hand, are not symmetric. A host can detect that the connection to its IMP is looped by receiving a message with the wrong leader format 🕵️♀️. That lets the host take appropriate action once it detects the loop 💅.
2.1. Addresses and Names
Let's talk about who's who 🪪.
The 1822 protocol defines one form of host specification, and the 1822L protocol defines two additional ways to identify network hosts. The three forms are 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 |
| | |
+----------------+---------------------------------+
1822 Address Format
Figure 2.1These fields are pretty huge, 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 |
| |
+--------------------------------+
1822L Name Format
Figure 2.2The 1822L names are just 16-bit unsigned numbers, except that bits 1 and 2 are not both zeros (see below). That allows over 49,000 hosts to be specified 🌍✨.
1822 addresses can't be used in 1822L leaders. There may be a requirement, though, for an 1822L host to address a specific physical host port or IMP fake host 🎯. That's what 1822L addresses are for. They form a subset of the 1822L name space and have both bits 1 and 2 off 🎀.
1 2 3 8 9 16
+---+---+------------+----------------+
| | | | |
| 0 | 0 | host # | IMP number |
| | | | |
+---+---+------------+----------------+
1822L Address Format
Figure 2.3This format lets 1822L hosts directly address hosts 0-63 at IMPs 1-255 (IMP 0 does not exist) 🧮. 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 change too 🔁.
2.2. Name Translations
Okay, this is where the IMP does its translation magic 🪄.
A number of factors determine how an 1822L name gets translated by the IMP into a physical address on the network 🔍. These factors include which translations are legal, the order in which different translations for the same name should be attempted, which legal translations shouldn't be attempted because a particular host port is down, and the interoperability between 1822 and 1822L hosts 💖. These issues are discussed in the following sections 📖.
2.2.1. Authorization and Effectiveness
Who gets to have a name, and does it actually work? 🤔
Every host on a C/30 IMP, whether it uses the 1822 or the 1822L protocol to access the network, can have one or more 1822L names (logical addresses) 🏷️. Hosts using 1822L can then use these names to address the hosts in the network, independent of their physical locations 💅. Because of the implementation constraints mentioned in the introduction, hosts on non-C/30 IMPs
Okay so, hosts that can't snag a 1822L name just use their 1822L address to reach everybody else. It's giving backup plan, and honestly it slaps 🫶
But now the big questions pop up 👀 How do the names get assigned? How do they become known to the IMPs so physical addresses can be figured out? And how do the IMPs know which host is using a shared port? Let's go one by one, bestie 💅
First, a central network administrator assigns the names. When a name gets created, it's assigned to a host (or a group of hosts) at one or more specific host ports. Those hosts are allowed to live at those ports and nowhere else 🚫 If a host moves, it keeps the same name, but the administrator has to update the central database to show the new host port. The Network Operations Center (NOC) then passes those database changes along to the IMPs 📬 For a little while, the host might be allowed to sit at the new port, the old one, or both 🦋 Once the administrator officially links a name to the host ports where it can be used, that name is called authorized ✨ And 1822L addresses, which point straight at physical host ports, are always authorized in this sense 💖
Next, once a host has names, it has to tell the IMPs where it is and what names it's using. There are two cases here, one for 1822L hosts and one for 1822 hosts. Heads up, this next bit only applies to hosts on C/30 IMPs 🙈
When an IMP sees an 1822L host come up on a host port, it has no clue which host just showed up. Several hosts might share that port, or one host might want to be known by different names at different times 🌀 So the host has to introduce itself to the IMP before it can send or receive anything. It does this with a brand new host-to-IMP message called the Name Declaration Message (NDM), which lists the names the host wants to be known by 🎀 The IMP checks its tables to see if each name is authorized, then sends back an NDM Reply telling the host which names were actually authorized and can now be used for sending and receiving. Those are the effective names 💜 A host can also send an NDM any time to change its effective list, adding and deleting names as it likes 🌸 The only rule is that a name can only become effective if it's authorized. No sneaking in unauthorized names, periodt 💅
Now the 1822 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 effective as soon as it gets the first 1822 NOP from the host ✨ So even though the host is speaking 1822, it can still receive messages from 1822L hosts through its 1822L name. It can also receive from an 1822L host through the 1822L address, obviously 🫶 (Remember, the difference is that addresses point to physical locations on the network, while names are strictly logical identifiers. Main character energy for names, lol 🧚) The IMPs translate between the different leaders and send the right leader in each case. See section 2.2.4 for the deets 🍓
So the third question? Already answered! When an 1822L host comes up, it uses the NDM to tell the IMP who it is and what names it goes by. Even on a shared port, the IMP knows exactly which host is connected right now 👑
Finally, whenever a host goes down, its names automatically become non-effective 😭 When it comes back up, it has to make them effective again. Don't forget, bestie 💖
2.2.2 Translation Policies
Several hosts can share the same 1822L name 👯 If more than one of them is up at once, any message sent to that name gets delivered to just ONE of the hosts sharing it, and a RFNM comes back like usual. The catch is that the sender won't find out which host got the message, and later messages to that name aren't guaranteed to go to the same host 🤷♀️ Typically, hosts offering exactly the same service could share a 1822L name like this 🌈
A host can also be multi-homed, which means the same 1822L name might point to more than one host port (all hooked up to the same host) 🦋 If the host is up on just one of those ports, that port gets used for every message addressed to the host. But if it's up on more than one port, the message gets delivered over just one of them, and the subnet decides which one. That choice can change from message to message 🎲 If a host wants certain messages to arrive 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 address selection policies are available for the name mapping process. When a name gets translated, it uses one of the three policies, and the policy is set ahead of time on a per-name basis 📋 Here they are:
- Attempt each translation in the order the physical addresses are listed in the IMP's translation tables, looking for the first reachable physical host address. This list always gets searched from the top whenever an uncontrolled packet needs to be sent or a new virtual circuit connection has to be created (see section 2.5). 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 whenever an uncontrolled packet is to be sent or a new virtual circuit connection has to be created 🚀
- Use load leveling. This is similar to the second policy, but it differs in that searching the address list for a valid translation starts at the address right after where the previous translation search ended, whenever an uncontrolled packet is to be sent or a new virtual circuit connection has to be created. This tries to spread the load from any one IMP's hosts out across the various host ports associated with a particular name ⚖️ Note that this is NOT network-wide load leveling, which would need a distributed algorithm and tables 🙅♀️
2.2.3 Reporting Destination Host Downs
As explained in report 1822, and as we'll cover in more detail in section 2.5, whenever a host sends regular messages, the IMP opens a virtual circuit connection from the source host to each destination host 🔌 A connection stays open at least as long as there are outstanding (un-RFNMed) messages using it and both the source and destination hosts stay up 💜
But the destination host might go down while a connection is alive 😬 If it goes down when there are no outstanding messages to it in the network, the connection gets closed and nothing else happens until the source host submits the next message for that destination. At that point, ONE of the following will happen:
A1. If 1822 or an 1822L address is being used to specify the destination host, the source host gets 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, a type 7 message gets sent to the source host too 📨
A3. If an 1822L name is being used to specify the destination host, and the name maps to more than one authorized host port, the IMP tries to open a connection to another authorized and effective host port for that name 🔁 If no such connection can be made, the host gets a type 15 (1822L Name or Address Error), subtype 5 (no effective translations) message (see section 3.2). Note that a type 7 message can't be returned to the source host here, 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 gets closed, and one of the following happens:
B1. If 1822 or an 1822L address is being used to specify the destination host, the source host gets a type 7 message for each outstanding message 📬
B2. If an 1822L name is being used to specify the destination host, the source host gets a type 9 (Incomplete Transmission), subtype 6 (message lost due to logically addressed host going down) message for each outstanding message 💔 The next time the source host submits another message for that same destination name, the previous algorithm gets used (either step A2 or step A3) 🔄
The two algorithms above also apply when a host stays up but declares the destination name for an existing connection to no longer be effective. In this case, though, the type 7 messages above get replaced by type 15, subtype 3 (name not effective) messages 🌙
Section 2.3 talks about how destination host downs get handled for uncontrolled packets 🧃
2.2.4 1822L and 1822 Interoperability
As mentioned before, 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 gives full interoperability when it comes to using 1822L names, since 1822 hosts are restricted to using physical addresses 🥺
There are two possible situations where an incompatibility could come up:
- An 1822 host sending a message to an 1822L host: The 1822 host specifies the destination host by its 1822 address. The destination host receives the message with an 1822L leader containing the 1822L addresses of the source and destination hosts 🎀
- An 1822L host sending a message to an 1822 host: The 1822L host can use 1822L names or addresses to specify both the source and destination hosts. The destination host will receive the message with an 1822 leader containing the 1822 address of the source host.
2.3. Uncontrolled Packets ✨
Okay bestie, uncontrolled packets (see 1822(3.6)) are kind of the drama queen of the 1822L protocol 💅. They skip the normal ordering and error-control mechanisms in the IMP, and they don't use the usual virtual circuit connection facilities either. So they have to carry ALL of their overhead with them, source and destination names included 📦. If you use 1822L names on an uncontrolled packet, the subnetwork needs extra info when the packet gets handed off to the destination IMP. That means less host-to-host data fits inside, compared to plain 1822 hosts 🥲.
Uncontrolled packets sent between 1822 hosts may contain not more than 991 bits of data. Uncontrolled packets sent to and/or from 1822L hosts are limited to 32 bits less, so 959 bits max. If a packet is too long, the host gets an error indication and the packet is not sent 🚫. This is a glow-up from the old IMP behaviour, which would just quietly toss an overly long uncontrolled packet with zero notification. Rude 💀.
There are more upgrades for uncontrolled packet service too ✨. A host gets notified of any errors its IMP detects when it receives the packet. A host will be notified if an uncontrolled packet has an error in the 1822L name specification, like if the name is not authorized or effective. It also gets told if the remote host is unreachable (which is shown by none of its names being effective), if network congestion control throttled the packet before it left the source IMP, or for any other reason the source IMP couldn't send the packet on its way.
In most cases, the host will NOT be notified if the uncontrolled packet got lost after the source IMP transmitted it 👀. Still, the IMP will try to notify the source host if a logically-addressed uncontrolled packet was mistakenly sent to a host 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, 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 goes to the same destination name, and there are no available effective translations, things split up. If the destination name has more than one mapping, the source host gets a type 15, subtype 5 (no effective translations) message. If the destination name has a single translation, the source host gets either a type 7 (Destination Host Dead) message or a type 15, subtype 3 (name not effective) message 🫠.
Those enhancements to uncontrolled packet service that aren't specific to logical addressing are available to hosts using 1822 as well as 1822L 🫶. BUT, uncontrolled packets must be sent using 1822L leaders in order to get any indication that the packet was lost once it has left the source IMP. So if you want that info, you gotta use 1822L leaders, no exceptions 🔥.
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 pretty much any failure in the other or in their communications path, including a break in mid-message 🧚.
The first messages a host should send to its IMP are three NOP messages. Three messages are required to make sure at least one message gets 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 do a bunch of jobs at once: 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 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 sends SIX NOPs, alternating three 1822 NOPs with three 1822L NOPs. That way, the host sees three NOPs no matter which protocol it's using 🙌. The NOPs are followed by two Interface Reset messages, one of each style. If the IMP receives a NOP from the host while this sequence is happening, the IMP will only send the remainder of the NOPs and the Interface Reset in the proper style. The 1822 NOPs contain the 1822 address of the host interface, and the 1822L NOPs 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 about the ready line, host tardiness, and other issues.
2.5. Counting RFNMs When Using 1822L 🔢
When a host submits a regular message using an 1822 leader, the IMP checks for an existing simplex virtual circuit connection (see 1822(3.1)) from the source host to the destination host. If that connection already exists, it gets used. Otherwise, a new connection from the source host port to the destination host port is opened 🔌. Either way, there may be at most 8 messages outstanding on that connection at any one time. If a host submits a ninth message on that connection before it gets a reply for the first message, the host gets blocked until the reply is sent for the first message 🚧.
Connections can stay open for a while, but they time out after three minutes of no activity 🕒. They can also be closed if there's 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 how many replies it has received for messages to each destination host address, so it can avoid getting blocked by submitting a ninth outstanding message on any connection 🧮.
When a host submits a regular message using an 1822L leader, a similar process happens. The difference is that connections are distinguished by the source port/source name/destination name combination 🪪. When the message comes in from a host, the IMP first looks for an open connection for that same port and source name/destination name pair. If one is found, it gets used, and no further name translation happens. If no open connection is found, then the destination name gets translated, and a connection is opened to the physical host port 🗺️. As long as there are any outstanding messages on the connection, it stays open, and it has the same restriction that only 8 messages may be outstanding at any one time. So a source host can still count replies to avoid being blocked, but the counting has to happen per source port and source name/destination name pair, instead of just per source port and destination host address like 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 🤯. That would allow more than 8 outstanding messages at once from the first port to the second. BUT for this to happen, either the source names, the 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" 🪞💕.
As already stated, 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 keep getting used until it's closed 🔒. If, in the meantime, a "better" destination host port belonging to the same destination name became available, it would NOT be used until the next time a new connection is opened to that destination name. So no switching mid-connection, sorry not sorry 🙅♀️.
Also, making an 1822L name non-effective will NOT automatically cause any connections using that name to be closed. They will, however, be closed after at most three minutes of inactivity ⏳. A host can, if it wants, make all of its names at a port non-effective and close all of its connections to and from the port by flapping the host's ready line to that IMP port 🔄.
2.6. 1822L Name Server 📖
Sometimes a host wants to do its own translations, or it might need the full list of physical addresses a particular name maps to 🗂️. For example, a connection-based host-to-host protocol may require that the same physical host port on a multi-homed host be used for all messages using that host-to-host connection. In that case, the host doesn't want to trust the IMP to always deliver messages using a destination name to the same host port 🙃.
In these cases, the host can submit a type 11 (Name Server Request) message to the IMP. This asks the IMP to translate the destination 1822L name and return a list of the addresses it maps to. The IMP responds with a type 11 (Name Server Reply) message 📬. That reply contains 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. See section 3.2
for a complete description of the message's contents.
Check out Section 3.2 for the full scoop on what's inside 💅
Using this info, the source host can make an informed choice about which physical host port (the ones tied to a 1822L name) to use. Then it sends the message to that port instead of to the name. 🧚
The IMP also supports a different kind of name service ✨ A host needs to send a Name Declaration Message to the IMP to make its names effective, but it might not want to keep its names in some table or file on the host. In that case, it can just ask the IMP which names it's allowed to use. 🫶
Here's how that works. 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 request came in on and the reply went out on, the number of names that map to that port, the list of names, and whether each name is effective. The host can use this info to send its Name Declaration Message. Section 3.2 has the full details of the reply's contents.
3. 1822L LEADER FORMATS ✨
The following 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 the two leaders, and all of the existing functionality of the 1822 leaders has been kept. In the first word, the 1822 New Format Flag is now also used to tell apart 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, respectively. 💜
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 |
| |
+----------------------------------+
Host-to-IMP 1822L Leader Format
Figure 3.1Bits 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 of the connection the host wants. 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 this is equal to one, the message is marked for tracing as it goes 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:
- 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 happen. 💅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. 💀1-2,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 message 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 data portion of the NDM message, 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 hold either the integer zero or the integer 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) that shows which names are now effective and which aren't. Here's the NDM message layout, including the leader (printed in hexadecimal, and without any leader padding) 📝
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.
| | |
+----------------+----------------+
NDM Message Format
Figure 3.2An NDM with zero entries will make all current effective names for the host become 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 of the other remarks about the NOP message in 1822(3.3) still apply. The host should always send NOPs in groups of three so the IMP receives them properly. Also see section 2.4 for more on how NOP messages are 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 destination name in the 1822L leader gets translated, and the IMP 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 request came in on. The IMP replies with a Port List Reply message, which lists the names that map to that port. 👑
- Types 5-7,9-10,13-255: Unassigned.
Bits 33-48: Source Host: This field holds one of the source host's 1822L names (or, if the host prefers, the 1822L address of the host port the message is being sent over). Unlike 1822, the IMP does not fill this in automatically, because a host might be known by several names and may want to use a particular one as the source of a message. Messages from the same host don't all have to use the same name here. Each source name that gets used is checked for authorization, effectiveness, and for actually belonging to this host. Messages that don't pass all of these checks won't be delivered, and an error message gets sent back to the source host instead 😭 If the host puts its 1822L address in this field, the address is checked to make sure it really represents the host port where the message started. 🔍
Bits 49-64: Destination Host:
Okay so the destination host field is where the IMP checks your homework 🧐 It's the 1822L name or address of the destination host. If you send a name, the IMP checks whether it's effective, and if it isn't, the source host gets an error message back 💌
Bits 65-76: Message ID: This is a host-specified ID that shows up 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 hold values from Assigned Numbers [3] that fit the host-to-host protocol you're running 🔗
Bits 77-80: Sub-type: This one's a modifier for message types 0, 2, 4, and 8 ✨
Bits 81-96: Unused, must be zero. Nothing to see here, just keep it at zero 🌸
3.2. IMP-to-Host 1822L Leader Format ✨
Now let's look at the leader the IMP sends back to the host. Here's the whole layout, bit by bit 🦋
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 |
| |
+----------------------------------+
IMP-to-Host 1822L Leader Format
Figure 3.3Bits 1-4: Unused and set to zero. Zeros all the way 0️⃣
Bits 5-8: 1822L IMP-to-Host Flag: This field is set to decimal 14 (1110 in binary). That's the signature that says "this one's from the IMP" 💜
Bits 9-16: Handling Type: This carries the value the source host assigned (see section 3.1). It's only used in message types 0, 5-9, and 15 🎀
Bits 17-20: Unused and set to zero. Still zeros, bestie 🫶
Bit 21: Trace Bit: If this is equal to one, the source host marked the message for tracing as it moves 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: This is the big one, the main character of the leader 👑
- Type 0: Regular Message 💌 All host-to-host communication happens through regular messages, and they come in several sub-types. The sub-type field (bits 77-80) is the same as what was sent in the host-to-IMP leader (see section 3.1).
- Type 1: Error in Leader 🙈 See 1822(3.4). On top of its already defined sub-types, this message gets two new ones:
- 4: Illegal Leader Style The host sent a leader where bits 5-8 didn't hold 13, 14, or 15 in decimal.
- 5: Wrong Leader Style The host sent an 1822L leader when the IMP was expecting an 1822 leader, or the other way around.
- Type 2: IMP Going Down 📉 See 1822(3.4).
- Type 3: NDM Reply 📝 This is the reply to the NDM host-to-IMP message (see section 3.1). It has the same number of entries as the NDM message it's replying to, and each listed 1822L name comes with a zero or a one (see figure 3.2). A zero means the name is not effective, and a one means the name is now effective ✅❌
- Type 4: NOP 🫥 The host should discard this message. It's used during initialization of the IMP/host communication. The Destination Host field holds the 1822L Address of the host port the NOP is being sent over. Everything else is 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). On top of its already defined sub-types, this message gets one new one:
- 6: Logically Addressed Host Went Down A logically addressed message got lost in the network because the destination host it was being delivered to went down. The source host should resubmit the message, since there may be another effective host port it could be delivered to (see section 2.2.3) 🔁
- 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. After the leader and any leader padding, it carries one word with the selection policy and the number of physical addresses the destination name maps to. That's followed by two words per physical address. The first word holds an 1822L address, and the second word has a bit that says whether that translation is effective, plus the routing distance (expected network transmission delay, in 6.4 ms units) to the address's IMP. In figure 3.4, which shows the leader without any leader padding, EFF is 1 for effective and 0 for non-effective, and POL is a two-bit number for the selection policy of the name (see section 2.2.2):
- 0: First reachable.
- 1: Closest physical address.
- 2: Load leveling.
- 3: Unused.
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| routing dist | etc.
| |F| |
+----------------+-+--------------+
Name Server Reply Format
Figure 3.4- Type 12: Port List Reply 🗂️ This is the reply to the Port List Request host-to-IMP message. It holds the number of names that map to this physical host port, followed by two words per name. The first word has an 1822L name that maps to this port, and the second has either a zero or a one, saying whether that particular translation is effective. The format is identical to the type 3 NDM Reply message (see figure 3.2).
- Type 15: 1822L Name or Address Error 🚨 This message gets sent back in response to a type 0 message from a host whose Source Host or Destination Host field was wrong. 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 that this singly-homed Destination Host name translated to is authorized and up, but not effective. If the host was actually down, a type 7 message would come back instead of a type 15.
- 5: The multi-homed Destination Host name is authorized, but has no available effective translations.
- 6: A logically addressed uncontrolled packet got sent to a dead or non-effective host port. However, if it's resubmitted, there may be another effective host port the IMP can try to send the packet to.
- 7: Logical addressing is not in use in this network.
- 8-15: Unassigned.
Types 4,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, and every reply should go back to the host named here. ✨ For message types 5-9 and 15, this field holds the source host value from an earlier type 0 message that this host sent. 💌
Bits 49-64: Destination Host:
For type 0 messages, this field holds the 1822L name or address the message was sent to. That lets the destination host see exactly how the source host specified it. 🔍 For message types 5-9 and 15, this field holds the destination host value from an earlier type 0 message that this host sent. 🦋
Bits 65-76: Message ID:
For message types 0, 5, 7-9, and 15, this is the value the source host picks to identify the message (see section 3.1). 🎀 Message types 2 and 6 use this field too. 💅
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 shows up in type 0, 3, 11, and 12 messages. It's the actual length in bits of the message, computed by the IMP, and it doesn't count the leader, the leader padding, or the hardware padding. 📏 ngl, that's a very precise little number. 🤓
4. REFERENCES ✨
[1] "Specifications for the Interconnection of a Host and an IMP", BBN Report 1822, December 1981 Revision. 📚
[2] 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. 🧠
[3] J. Reynolds and J. Postel, "Assigned Numbers", Request For Comments 870, October 1983, p. 14. 🗂️
[4] J. Postel, ed., "Internet Protocol - DARPA Internet Program Protocol Specification", Request for Comments 791, September 1981. 🌐
[5] J. Postel, "Address Mappings", Request for Comments 796, September 1981. 🗺️
APPENDIX A
1822L-IP ADDRESS MAPPINGS
Okay so once logical addressing is in active (or universal) use on a network, and the "official" host tables for that network list hosts by their logical names instead of their physical network addresses, it would be super desirable for hosts on other networks to use those same logical names when they send traffic over the internet [4]. 🌸
Happily, there's a natural mapping between logical names and internet addresses that fits perfectly with the ARPANET-style address mapping that's already standard. It's specified in RFC 796, Address Mappings [5]. The current ARPANET-style class A mapping goes like this (from RFC 796): 💖
+--------+ +--------+--------+
| HOST | | ZERO | IMP | 1822 Address
+--------+ +--------+--------+
8 8 8
+--------+--------+--------+--------+
| net # | HOST | LH | IMP | IP Address
+--------+--------+--------+--------+
8 8 8 8
1822 Class A Mapping
Figure A.1For 1822L names and addresses, the mapping is:
+--------+--------+
| upper | lower | 1822L Name or Address
+--------+--------+
8 8
+--------+--------+--------+--------+
| net # | upper | LH | lower | IP Address
+--------+--------+--------+--------+
8 8 8 8
1822L Class A Mapping
Figure A.2For 1822L addresses, this mapping is identical to the 1822 mapping. 🫶 For 1822L names, the IP address would look like it's addressing a high-numbered (64-255) 1822 host. The LH (logical host) field is still defined, but its use is discouraged. Multiple logical names should now be used to multiplex multiple functions onto one physical host port instead. 🧚
This mapping also extends to class B networks: 🦋
+--------+--------+
| upper | lower | 1822L Name or Address
+--------+--------+
8 8
+----------------+--------+--------+
| network number | upper | lower | IP Address
+----------------+--------+--------+
16 8 8
1822L Class B Mapping
Figure A.3Finally, logical addressing lets IMP-based class C networks exist for the first time!! 😭 Before this, it was really hard to split the 8 bits of host specification into some host bits and some IMP bits. But if ALL of the internet-accessible hosts on the network have logical names, there's no reason networks with up to 256 of those logical names can't now use class C addresses, like this: 🎉
+--------+--------+
|01000000| lower | 1822L Name
+--------+--------+
8 8
+------------------------+--------+
| network number | lower | IP Address
+------------------------+--------+
24 8
1822L Class C Mapping
Figure A.4Hosts on the network that want internet access get logical names in the range 40000 to 40377 (octal), and the gateway(s) connected to that network do the translation from IP addresses to 1822L names, as specified above. 🌷 Note that the network could have many more than 256 hosts, or 256 defined names. The only restriction is that hosts that want internet support or access need a name in the range 40000 - 40377. ⭐ Traffic that stays strictly local to the network can use other names, or even 1822L addresses. 🍓
INDEX
1822...................................................... 3
1822 address.............................................. 5
1822 host................................................. 4
1822L..................................................... 3
1822L address............................................. 6
1822L and 1822 interoperability.......................... 15
1822L host................................................ 4
1822L name................................................ 5
address selection policy................................. 12
authorized................................................ 8
blocking................................................. 20
closest physical address................................. 12
connection............................................... 20
destination host..................................... 32, 40
effective............................................. 9, 23
first reachable.......................................... 12
handing type......................................... 27, 35
host downs............................................... 13
interoperability......................................... 15
leader flags......................................... 27, 35
link field............................................... 32
load leveling............................................ 12
logical addressing........................................ 3
message ID........................................... 32, 41
message length........................................... 41
message type......................................... 28, 35
multi-homing.............................................. 3
name server...................................... 23, 31, 37
NDM................................................... 9, 28
NDM reply............................................. 9, 36
NOC....................................................... 8
NOP........................................... 4, 19, 30, 36
priority bit............................................. 27
regular message...................................... 28, 35
RFNM................................................. 20, 36
source host.......................................... 31, 40
standard message......................................... 28
sub-type............................................. 33, 41
symmetric................................................. 4
trace bit............................................ 27, 35
uncontrolled packet.................................. 16, 28
virtual circuit connection............................... 20That's the end of RFC 878, bestie!! 🌈💜 We made it through the whole thing. ✨👑
📦 where this page comes from
- ietf: rfc878 1983-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms