Request for Comments: 878 Obsoletes RFCs: 851, 802 The ARPANET 1822L Host Access Protocol RFC 878 Andrew G. Malis ARPANET Mail: malis@bbn-unix BBN Communications Corp. 50 Moulton St. Cambridge, MA 02238 December 1983 This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. 1822L Host Access Protocol December 1983 RFC 878 Table of Contents 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............................ 43 - i - 1822L Host Access Protocol December 1983 RFC 878 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............................... 46 - ii - 1822L Host Access Protocol December 1983 RFC 878 1 INTRODUCTION This RFC specifies the ARPANET 1822L Host Access Protocol, which will allow hosts to use logical addressing (i.e., host names that are independent of their physical location on the ARPANET) to communicate with each other. This new host access protocol is known as the ARPANET 1822L (for Logical) Host Access Protocol, and is a successor to the current ARPANET 1822 Host Access Protocol, which is described in sections 3.3 and 3.4 of BBN Report 1822 [1]. Although the 1822L protocol uses different Host-IMP leaders than the 1822 protocol, the IMPs will continue to support the 1822 protocol, and hosts using either protocol can readily communicate with each other (the IMPs will handle the translation automatically). The RFC's terminology is consistent with that used in Report 1822, and any new terms will be defined when they are first used. Familiarity with Report 1822 (section 3 in particular) is assumed. As could be expected, the RFC makes many references to Report 1822. As a result, it uses, as a convenient abbreviation, "see 1822(x)" instead of "please refer to Report 1822, section x, for further details". This RFC updates, and obsoletes, RFC 851. The changes from that RFC are: - 1 - 1822L Host Access Protocol December 1983 RFC 878 o Section 2.2.4 was rewritten for clarity. o Section 2.5 was expanded to further discuss the effects of using 1822L names on host-to-host virtual circuits. o 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. o 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 - 1822L Host Access Protocol December 1983 RFC 878 2 THE ARPANET 1822L HOST ACCESS PROTOCOL The ARPANET 1822L Host Access Protocol allows a host to use logical addressing to communicate with other hosts on the ARPANET. Basically, logical addressing allows hosts to refer to each other using an 1822L name (see section 2.1) which is independent of a host's physical location in the network. IEN 183 (also published as BBN Report 4473) [2] gives the use of logical addressing considerable justification. Among the advantages it cites are: o The ability to refer to each host on the network by a name independent of its location on the network. o Allowing different hosts to share the same host port on a time-division basis. o Allowing a host to use multi-homing (where a single host uses more than one port to communicate with the network). o 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 that are 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 have the choice of - 3 - 1822L Host Access Protocol December 1983 RFC 878 using the 1822 or 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 up, hosts can switch from one protocol to the other by issuing an appropriate NOP. Hosts that do not use the 1822L protocol will still be addressable by and can communicate with hosts that do, and vice-versa. Another difference between the two protocols is that the 1822 leaders are symmetric, while the 1822L leaders are not. The term symmetric means that in the 1822 protocol, the exact same leader format is used for messages 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 appear to be a legal message from a real host (the destination host of the original message). In contrast, the 1822L headers are not symmetric, and a host can detect if the connection to its IMP is looped by receiving a message with the wrong leader format. This allows the host to take appropriate action upon detection of the loop. - 4 - 1822L Host Access Protocol December 1983 RFC 878 2.1 Addresses and Names The 1822 protocol defines one form of host specification, and the 1822L protocol defines two additional ways to identify network hosts. These three forms are 1822 addresses, 1822L names, and 1822L addresses. 1822 addresses are the 24-bit host addresses found in 1822 leaders. They have the following format: 1 8 9 24 +----------------+---------------------------------+ | | | | Host number | IMP number | | | | +----------------+---------------------------------+ 1822 Address Format Figure 2.1 These 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. 1822L names have a much simpler format: - 5 - 1822L Host Access Protocol December 1983 RFC 878 1 16 +--------------------------------+ | | | 1822L name | | | +--------------------------------+ 1822L Name Format Figure 2.2 The 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. 1822 addresses cannot be used in 1822L leaders, but there may be a requirement for an 1822L host to be able to address a specific physical host port or IMP fake host. 1822L addresses are used for this function. 1822L addresses 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.3 - 6 - 1822L Host Access Protocol December 1983 RFC 878 This format allows 1822L hosts to directly address hosts 0-63 at IMPs 1-255 (IMP 0 does not exist). Note that the highest host numbers are reserved for addressing the IMP's internal fake hosts. At this 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. 2.2 Name Translations There are a number of factors that determine how an 1822L name is translated by the IMP into a physical address on the network. These factors include which translations are legal; in what order 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 Every host on a C/30 IMP, regardless of whether it is using the 1822 or 1822L protocol to access the network, can have one or more 1822L names (logical addresses). Hosts using 1822L can then - 7 - 1822L Host Access Protocol December 1983 RFC 878 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 cannot be assigned 1822L names. To circumvent this restriction, however, 1822L hosts can also use 1822L addresses to access all of the other hosts. At this point, several questions arise: How are these names assigned, how do they become known to the IMPs (so that translations to physical addresses can be made), and how do the IMPs know which host is currently using a shared port? To answer each question in order: Names are assigned by a central network administrator. When each name is created, it is 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 will keep the same name, but the administrator has to update the central database to reflect the new host port. Changes to this database are distributed to the IMPs by the Network Operations Center (NOC). For a while, the host may be allowed to reside at either of (or both) the new and old ports. Once the correspondence between a name and one or more hosts ports where it may be used has been made official by the administrator, that name is said to be authorized. 1822L - 8 - 1822L Host Access Protocol December 1983 RFC 878 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 is 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 has just come up (several hosts may share the same port, or one host may prefer to be known by different names at different times). This requires the host to declare itself to the IMP before it can actually send and receive messages. This function is performed by a new host-to-IMP message, the Name Declaration Message (NDM), which lists the names that the host would like to be known by. The IMP checks its tables to see if each of the names 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 wishes to use can become effective only if they are authorized. - 9 - 1822L Host Access Protocol December 1983 RFC 878 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 the IMP finds in its tables for that host become effective when it receives the first 1822 NOP from the host. Thus, even though the