As per Relevance of the word destination, we have this rfc below:
Request for Comments: 851
Obsoletes RFC: 802
The ARPANET 1822L Host Access
RFC 851
Andrew G.
ARPANET Mail: malis@bbn-
Bolt Beranek and Newman Inc
50 Moulton St
Cambridge, MA 02238
April 1983
This RFC specifies the ARPANET 1822L Host Access Protocol,
is a successor to the existing 1822 Host Access Protocol. 1822
allows ARPANET hosts to use logical names as well as 1822'
physical port locations to address each other. The RFC is
being presented as a solicitation of comments on 1822L
especially from host network software implementers
maintainers
1822L Host Access Protocol April 1983
RFC 851
Table of
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........................................... 43
- i -
1822L Host Access Protocol April 1983
RFC 851
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................................. 39
- ii -
1822L Host Access Protocol April 1983
RFC 851
1
This RFC specifies the ARPANET 1822L Host Access Protocol,
will allow hosts to use logical addressing (i.e., host names
are independent of their physical location on the ARPANET)
communicate with each other. This new host access protocol
known as the ARPANET 1822L (for Logical) Host Access Protocol
and is a successor to the current ARPANET 1822 Host
Protocol, which is described in sections 3.3 and 3.4 of
Report 1822 [1]. Although the 1822L protocol uses
Host-IMP leaders than the 1822 protocol, the IMPs will
to support the 1822 protocol, and hosts using either protocol
readily communicate with each other (the IMPs will handle
translation automatically).
There is one major restriction to the new 1822L protocol:
will be implemented in C/30 IMPs only, and will therefore only
usable by hosts connected to C/30 IMPs, as Honeywell and
IMPs do not have sufficient memory to hold the new programs
tables. This restriction also means that logical
cannot be used to identify a host on a non-C/30 IMP. While
is not a problem on the ARPANET, which only has C/30 IMPs,
restriction will apply if logical addressing is used on
network that mixes C/30 and non-C/30 IMPs
- 1 -
1822L Host Access Protocol April 1983
RFC 851
The RFC's terminology is consistent with that used in
1822, and any new terms will be defined when they are first used
Familiarity with Report 1822 (section 3 in particular)
assumed. As could be expected, the RFC makes many references
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 802. The changes from
RFC include
o The Short Blocking Feature, which had also been described
RFC 802, now has its own RFC, RFC 852 [2]. It was moved to
own RFC, since it is completely independent of
addressing
o In section 2.2, descriptions of the three address
policies and of host error handling have been added
o In section 2.3, the IMP's uncontrolled packet service has
further improved. This applies to hosts using 1822 as well
1822L
o Pointers on using RFNM counting with 1822L have been added
section 2.5.
- 2 -
1822L Host Access Protocol April 1983
RFC 851
o Section 2.6 describes the new "1822L name server" in the IMP
which makes use of two new Host-to-IMP messages to allow
to do their own name-to-address mapping
o In section 3.2, the subtypes for the type 15 (1822L Name
Address Error) IMP-to-Host message have been changed
- 3 -
1822L Host Access Protocol April 1983
RFC 851
2 THE ARPANET 1822L HOST ACCESS
The ARPANET 1822L Host Access Protocol allows a host to
logical addressing to communicate with other hosts on
ARPANET. Basically, logical addressing allows hosts to refer
each other using an 1822L name (see section 2.1) which
independent of a host's physical location in the network.
183 (also published as BBN Report 4473) [3] gives the use
logical addressing considerable justification. Among
advantages it cites are
o The ability to refer to each host on the network by a
independent of its location on the network
o Allowing different hosts to share the same host port on
time-division basis
o Allowing a host to use multi-homing (where a single host
more than one port to communicate with the network).
o Allowing several hosts that provide the same service to
the same name
The main differences between the 1822 and 1822L protocols are
format of the leaders that are used to introduce messages
a host and an IMP, and the specification in those leaders of
source and/or destination host(s). Hosts have the choice
- 4 -
1822L Host Access Protocol April 1983
RFC 851
using the 1822 or the 1822L protocol. When a host comes up on
IMP, it declares itself to be an 1822 host or an 1822L host
the type of NOP message (see section 3.1) it uses. Once up
hosts can switch from one protocol to the other by issuing
appropriate NOP. Hosts that do not use the 1822L protocol
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
symmetric means that in the 1822 protocol, the exact same
format is used for messages in both directions between the
and IMPs. For example, a leader sent from a host over a
that was looped back onto itself (via a looping plug or
hardware) would arrive back at the host and appear to be a
message from a real host (the destination host of the
message). In contrast, the 1822L headers are not symmetric,
a host can detect if the connection to its IMP is looped
receiving a message with the wrong leader format. This
the host to take appropriate action upon detection of the loop
- 5 -
1822L Host Access Protocol April 1983
RFC 851
2.1 Addresses and
The 1822 protocol defines one form of host specification, and
1822L protocol defines two additional ways to identify
hosts. These three forms are 1822 addresses, 1822L names,
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 |
| | |
+----------------+---------------------------------+
Figure 1. 1822 Address
These fields are quite large, and the ARPANET will never use
than a fraction of the available address space. 1822
are used in 1822 leaders only
1822L names are 16-bit unsigned numbers that serve as a
identifier for one or more hosts. 1822L names have a
simpler format
- 6 -
1822L Host Access Protocol April 1983
RFC 851
1 16
+--------------------------------+
| |
| 1822L name |
| |
+--------------------------------+
Figure 2. 1822L Name
The 1822L names are just 16-bit unsigned numbers, except
bits 1 and 2 are not both zeros (see below). This allows
49,000 hosts to be specified
1822 addresses cannot be used in 1822L leaders, but there may
a requirement for an 1822L host to be able to address a
physical host port or IMP fake host. 1822L addresses are
for this function. 1822L addresses form a subset of the 1822
name space, and have both bits 1 and 2 off
1 2 3 8 9 16
+---+---+------------+----------------+
| | | | |
| 0 | 0 | host # | IMP number |
| | | | |
+---+---+------------+----------------+
Figure 3. 1822L Address
This format allows 1822L hosts to directly address hosts 0-63
IMPs 1-255 (IMP 0 does not exist). Note that the highest
- 7 -
1822L Host Access Protocol April 1983
RFC 851
numbers are reserved for addressing the IMP's internal
hosts. At this writing, the IMP has seven fake hosts, so
numbers 57-63 address the IMP fake hosts, while host numbers 0-56
address real hosts external to the IMP. As the number of
fake hosts changes, this boundary point will also change
2.2 Name
There are a number of factors that determine how an 1822L name
translated by the IMP into a physical address on the network
These factors include which translations are legal; in what
different translations for the same name should be attempted
which legal translations shouldn't be attempted because
particular host port is down; and the interoperability
1822 and 1822L hosts. These issues are discussed in
following sections
2.2.1 Authorization and
Every host on a C/30 IMP, regardless of whether it is using
1822 or 1822L protocol to access the network, can have one
more 1822L names (logical addresses). Hosts using 1822L can
use these names to address the hosts in the network
of their physical locations. Because of the
- 8 -
1822L Host Access Protocol April 1983
RFC 851
constraints mentioned in the introduction, hosts on non-C/30
cannot be assigned 1822L names. To circumvent this restriction
however, 1822L hosts can also use 1822L addresses to access
of the other hosts
At this point, several questions arise: How are these
assigned, how do they become known to the IMPs (so
translations to physical addresses can be made), and how do
IMPs know which host is currently using a shared port? To
each question in order
Names are assigned by a central network administrator. When
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
reside at those specific host ports, and nowhere else. If a
moves, it will keep the same name, but the administrator has
update the central database to reflect the new host port
Changes to this database are distributed to the IMPs by
Network Operations Center (NOC). For a while, the host may
allowed to reside at either of (or both) the new and old ports
Once the correspondence between a name and one or more
ports where it may be used has been made official by
administrator, that name is said to be authorized. 1822
addresses, which actually refer to physical host ports,
always authorized in this sense
- 9 -
1822L Host Access Protocol April 1983
RFC 851
Once a host has been assigned one or more names, it has to
the IMPs know where it is and what name(s) it is using.
are two cases to consider, one for 1822L hosts and another
1822 hosts. The following discussion only pertains to hosts
C/30 IMPs
When an IMP sees an 1822L host come up on a host port, the
has no way of knowing which host has just come up (several
may share the same port, or one host may prefer to be known
different names at different times). This requires the host
declare itself to the IMP before it can actually send and
messages. This function is performed by a new host-to-
message, the Name Declaration Message (NDM), which lists
names that the host would like to be known by. The IMP
its tables to see if each of the names is authorized, and
an NDM Reply to the host saying which names were
authorized and can now be used for sending and receiving
(i.e., which names are effective). A host can also use an
message to change its list of effective names (it can add to
delete from the list) at any time. The only constraint on
host is that any names it wishes to use can become effective
if they are authorized
In the second case, if a host comes up on a C/30 IMP using
1822 protocol, the IMP automatically makes the first name the
- 10 -
1822L Host Access Protocol April 1983
RFC 851
finds in its tables for that host become effective. Thus,
though the host is using the 1822 protocol, it can still
messages from 1822L hosts via its 1822L name. Of course, it
also receive messages from an 1822L host via its 1822L address
well. (Remember, the distinction between 1822L names
addresses is that the addresses correspond to physical
on the network, while the names are strictly
identifiers). The IMPs translate between the different
and send the proper leader in each case (see section 2.2.4).
The third question above has by now already been answered.
an 1822L host comes up, it uses the NDM message to tell the
which host it is (which names it is known by). Even if this is
shared port, the IMP knows which host is currently connected
Whenever a host goes down, its names automatically become non
effective. When it comes back up, it has to make them
again
2.2.2 Translation
Several hosts can share the same 1822L name. If more than one
these hosts is up at the same time, any messages sent to
1822L name will be delivered to just one of the hosts
that name, and a RFNM will be returned as usual. However,
- 11 -
1822L Host Access Protocol April 1983
RFC 851
sending host will not receive any indication of which
received the message, and subsequent messages to that name
not guaranteed to be sent to the same host. Typically,
providing exactly the same service could share the same 1822
name in this manner
Similarly, when a host is multi-homed, the same 1822L name
refer to more than one host port (all connected to the
host). If the host is up on only one of those ports, that
will be used for all messages addressed to the host. However,
the host were up on more than one port, the message would
delivered over just one of those ports, and the subnet
choose which port to use. This port selection could change
message to message. If a host wanted to insure that
messages were delivered to it on specific ports, these
could use either the port's 1822L address or a specific 1822
name that referred to that port alone
Three different address selection policies are available for
name mapping process. When translated, each name uses one of
three policies (the policy is pre-determined on a per-
basis). The three policies are
o Attempt each translation in the order in which the
addresses are listed in the IMP's translation tables, to
- 12 -
1822L Host Access Protocol April 1983
RFC 851
the first reachable physical host address. This list
always searched from the top whenever an uncontrolled
is to be sent or an end-to-end connection has to be created
This is the most commonly used policy
o Selection of the closest physical address, which uses
IMP's routing tables to find the translation to
destination IMP with the least delay path
o Use load leveling. This is similar to the second policy,
differs in that searching the address list for a
translation starts at the address following where the
translation search ended. This attempts to spread out
load from any one IMP's hosts to the various host
associated with a particular name. Note that this is
network-wide load leveling, which would require a
algorithm and tables
2.2.3 Reporting Destination Host
As was explained in report 1822, and as will be discussed
greater detail in section 2.5, whenever regular messages are
by a host, the IMP opens a subnetwork connection to
destination host from the source host. A connection will
open at least as long as there are any outstanding (un-RFNMed
- 13 -
1822L Host Access Protocol April 1983
RFC 851
messages using it and both the source and destination hosts
up
However, the destination host may go down for some reason
the lifetime of a connection. If the host goes down while
are no outstanding messages to it in the network, then
connection is closed and no other action is taken until
source host submits the next message for that destination.
that time, ONE of the following events will occur
A1. If 1822 or an 1822L address is being used to specify
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
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
host, and the name maps to more than one authorized
port, then the IMP attempts to open a connection to
authorized and effective host port for that name. If
such connection can be made, the host will receive a type 15
(1822L Name or Address Error), subtype 5 (no
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,
- 14 -
1822L Host Access Protocol April 1983
RFC 851
the name maps to more than one destination port
Things get a bit more complicated if there are any
messages on the connection when the destination host goes down
The connection will be closed, and one of the following
occur
B1. If 1822 or an 1822L address is being used to specify
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
host, then the source host will receive a type 9 (
Transmission), subtype 3 (message lost due to
failure) message for each outstanding message. The
time the source host submits another message for that
destination name, the previous algorithm will be
(either step A2 or step A3).
The above two algorithms also apply when a host stays up,
declares the destination name for an existing connection to
longer be effective. In this case, however, the type 7
above will be replaced by type 15, subtype 3 (name not effective
messages
Section 2.3 discusses how destination host downs are handled
uncontrolled packets
- 15 -
1822L Host Access Protocol April 1983
RFC 851
2.2.4 1822L and 1822
As has been previously stated, 1822 and 1822L hosts
intercommunicate, and the IMPs will automatically handle
necessary leader and address format conversions. However,
every combination of 1822 and 1822L hosts allows
interoperability with regard to the use of 1822L names
The following figure illustrates how these
combinations are handled, showing how each type of host
access every other type of host. 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
non-C/30" signifies a host on an non-C/30 IMP (which
support the 1822L protocol). The table entry shows the
and host address format(s) that the source host can use to
the destination host
- 16 -
1822L Host Access Protocol April 1983
RFC 851
Destination
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,
1822L | 1822L name or | 1822L name or | 1822L
|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
with an 1822L leader containing the 1822L
of the source and destination hosts. If
address cannot be encoded as an 1822L address,
the message is not delivered and an error message
sent to the source host
Note 2: The message is presented to the destination
with an 1822 leader containing the 1822 address
the source host
Figure 4. Communications between different host
- 17 -
1822L Host Access Protocol April 1983
RFC 851
2.3 Uncontrolled
Uncontrolled packets (see 1822(3.6)) present a unique problem
the 1822L protocol. Uncontrolled packets use none of the
ordering and error-control mechanisms in the IMP, and do not
the normal subnetwork connection facilities. As a result
uncontrolled packets need to carry all of their overhead
them, including source and destination names. If 1822L names
used when sending an uncontrolled packet, additional
is now required by the subnetwork when the packet is
to the destination IMP. This means that less host-to-host
can be contained in the packet than is possible between 1822
hosts
Uncontrolled packets that are sent between 1822 hosts may
not more than 991 bits of data. Uncontrolled packets that
sent to and/or from 1822L hosts are limited to 32 bits less,
not more than 959 bits. Packets that exceed this length
result in an error indication to the host, and the packet
not be sent. This error indication represents an enhancement
the previous level of service provided by the IMP, which
simply discard an overly long uncontrolled packet
notification
- 18 -
1822L Host Access Protocol April 1983
RFC 851
Other enhancements that are provided for uncontrolled
service are a notification to the host of any errors that
detected by the host's IMP when it receives the packet. A
will be notified if an uncontrolled packet contains an error
the 1822L name specification, such as if the name is
authorized or effective, if the remote host is unreachable (
is indicated by none of its names being effective), if
congestion control throttled the packet before it left the
IMP, or for any other reason the source IMP was not able to
the packet on its way
In most cases, the host will not be notified if the
packet was lost once it was transmitted by the source IMP
However, the IMP will attempt to notify the source host if
logically-addressed uncontrolled packet was mistakenly sent to
host that the source IMP thought was effective, but which
out to be dead or non-effective at the destination IMP.
non-delivery notice is sent back to the source IMP as
uncontrolled packet from the destination IMP, so the source
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
Address Error), subtype 6 (down or non-effective port) message
If the packet is resubmitted or another packet is sent to
- 19 -
1822L Host Access Protocol April 1983
RFC 851
same destination name, and there are no available
translations, then the source host will receive a type 15,
subtype 5 (no effective translations) message if the
name has more than one mapping; or will receive either a type 7
(Destination Host Dead) or a type 15, subtype 3 (name
effective) message if the destination name has a
translation
Those enhancements to the uncontrolled packet service that
not specific to logical addressing will be available to
using 1822 as well as 1822L. However, logically-
uncontrolled packets must be used in order to receive
indication that the packet was lost once it has left the
IMP
2.4 Establishing Host-IMP
When a host comes up on an IMP, or after there has been a
in the communications between the host and its IMP (
1822(3.2)), the orderly flow of messages between the host and
IMP needs to be properly (re)established. This allows the
and host to recover from most any failure in the other or
their communications path, including a break in mid-message
- 20 -
1822L Host Access Protocol April 1983
RFC 851
The first messages that a host should send to its IMP are
NOP messages. Three messages are required to insure that
least one message will be properly read by the IMP (the first
could be concatenated to a previous message if communications
been broken in mid-stream, and the third provides redundancy
the second). These NOPs serve several functions:
synchronize the IMP with the host, they tell the IMP how
padding the host requires between the message leader and
body, and they also tell the IMP whether the host will be
1822 or 1822L leaders
Similarly, the IMP will send three NOPs to the host when
detects that the host has come up. Actually, the IMP will
six NOPs, alternating three 1822 NOPs with three 1822L NOPs
Thus, the host will see three NOPs no matter which protocol it
using. The NOPs will be followed by two Interface
messages, one of each style. If the IMP receives a NOP from
host while the above sequence is occurring, the IMP will
send the remainder of the NOPs and the Interface Reset in
proper style. The 1822 NOPs will contain the 1822 address of
host interface, and the 1822L NOPs will contain the
1822L address
Once the IMP and the host have sent each other the
messages, regular communications can commence. See 1822(3.2)
- 21 -
1822L Host Access Protocol April 1983
RFC 851
further details concerning the ready line, host tardiness,
other issues
2.5 Counting RFMS When Using 1822
When a host submits a regular message using an 1822 leader,
IMP checks for an existing simplex virtual circuit
from the source host to the destination host. If such
connection already exists, it is used. Otherwise, a
connection from the source host port to the destination host
is opened. In either case, there may be at most eight
outstanding on that connection at any one time. If a
submits a ninth message on that connection before it receives
reply for the first message, then the host will be blocked
the reply is sent for the first message
Such connections can stay open for some time, but are timed
after three minutes of no activity, or can be closed if there
contention for the connection blocks in either the source
destination IMP. However, a connection will never be closed
long as there are any outstanding messages on it. This allows
source host to count the number of replies it has received
messages to each destination host address in order to avoid
blocked by submitting a ninth outstanding message on
- 22 -
1822L Host Access Protocol April 1983
RFC 851
connection
When a host submits a regular message using an 1822L leader,
similar process occurs, except that in this case, connections
distinguished by the source name/destination name combination
When the message is received from a host, the IMP first looks
an open connection for that same source name/destination
pair. If such a connection is found, then it is used, and
further name translation is performed. If, however, no
connection was found, then the destination name is translated
and a connection opened to the physical host port. As long
there are any outstanding messages on the connection it will
open, and it will have the same restriction that only
messages may be outstanding at any one time. Thus, a source
can still count replies to avoid being blocked, but they must
counted on a source name/destination name pair basis, instead
just by destination host address as before
Since connections are based on the source name as well as
destination name, this implies that there may be more than
open connection from physical host port A to physical host
B, which would allow more than 8 outstanding
simultaneously from the first to the second port. However,
this to occur, either the source or destination names, or both
must differ from one connection to the next. For example, if
- 23 -
1822L Host Access Protocol April 1983
RFC 851
names "543" and "677" both translate to physical port 3 on
51, then the host on that port could open four connections
itself by sending messages from "543" to "543", from "543"
"677", from "677" to "543", and from "677" to "677".
As has already been stated, the destination names in
messages are only translated when connections are first opened
Once a connection is open, that connection, and its
physical host port, will continue to be used until it is closed
If, in the meantime, a "better" destination host port
to the same destination name became available, it would not
used until the next time a new connection is opened to
destination name
2.6 1822L Name
There may be times when a host wants to perform its
translations, or might need the full list of physical
to which a particular name maps. For example, a connection-
host-to-host protocol may require that the same physical
port on a multi-homed host be used for all messages using
host-to-host connection, and the host does not wish to trust
IMP to always deliver messages using a destination name to
same host port
- 24 -
1822L Host Access Protocol April 1983
RFC 851
In these cases, the host can submit a type 11 (Name
Request) message to the IMP, which requests the IMP to
the destination 1822L name and return a list of the addresses
which it maps. The IMP will respond with a type 11 (Name
Reply) message, which contains the selection policy in use
that name, the number of addresses to which the name maps,
addresses themselves, and for each address, whether it
effective and its routing distance from the IMP. See section 3.2
for a complete description of the message's contents
Using this information, the source host can make an
decision on which of the physical host ports corresponding to
1822L name to use, and can subsequently send the messages to
port, rather than to the name
The IMP also supports a different type of name service. A
needs to issue a Name Declaration Message to the IMP in order
make its names effective, but it may not wish to keep its
in some table or file in the host. In this case, it can ask
IMP to tell it which names it is authorized to use
In this case, the host submits a type 12 (Port List Request
message to the IMP, and the IMP replies with a type 12 (Port
Reply) message. It contains, for the host port over which
IMP received the request and sent the reply, the number of
- 25 -
1822L Host Access Protocol April 1983
RFC 851
that map to the port, the list of names, and whether or not
name is effective. The host can then use this information
order to issue the Name Declaration Message. Section 3.2
contains a complete description of the reply's contents
- 26 -
1822L Host Access Protocol April 1983
RFC 851
3 1822L LEADER
The following sections describe the formats of the leaders
precede messages between an 1822L host and its IMP. They
designed to be as compatible with the 1822 leaders as possible
The second, fifth, and sixth words are identical in the
leaders, and all of the existing functionality of the 1822
leaders has been retained. In the first word, the 1822
Format Flag is now also used to identify the two types of 1822
leaders, and the Handling Type has been moved to the second byte
The third and fourth words contain the Source and
1822L Name, respectively
- 27 -
1822L Host Access Protocol April 1983
RFC 851
3.1 Host-to-IMP 1822L Leader
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
- 28 -
1822L Host Access Protocol April 1983
RFC 851
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 indicate the
characteristics of the connection desired by the host.
1822(3.3).
Bit 9: Priority Bit
Messages with this bit on will be treated as
messages
Bits 10-16: Unused, must be zero
Bits 17-20: Unused, must be zero
Bit 21: Trace Bit
If equal to one, this message is designated for tracing
it proceeds through the network. See 1822(5.5).
Bits 22-24: Leader Flags
Bit 22: A flag available for use by the destination host
See 1822(3.3) for a description of its use by the IMP'
TTY Fake Host
Bits 23-24: Reserved for future use, must be zero
- 29 -
1822L Host Access Protocol April 1983
RFC 851
Bits 25-32: Message Type
Type 0: Regular Message - All host-to-host
occurs via regular messages, which have several sub
types, found in bits 77-80. These sub-types are
0: Standard - The IMP uses its full message and
control facilities, and host blocking may occur
3: Uncontrolled Packet - The IMP will perform
message-control functions for this type
message, and network flow and congestion
may cause loss of the packet. 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) - This message
used by the host to declare which of its 1822L names
or is not effective (see section 2.2.1), or to make
of its names non-effective. The first 16 bits of
data portion of the NDM message, following the
and any leader padding, contains the number of 1822
names contained in the message. This is followed
the 1822L name entries, each 32 bits long, of which
first 16 bits is a 1822L name and the second 16
contains either of the integers zero or one.
- 30 -
1822L Host Access Protocol April 1983
RFC 851
indicates that the name should not be effective,
one indicates that the name should be effective.
IMP will reply with a NDM Reply message (see
3.2) indicating which of the names are now
and which are not. Pictorially, a NDM message has
following format (including the leader, which
printed 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
- 31 -
1822L Host Access Protocol April 1983
RFC 851
An NDM with zero entries will cause all
effective names for the host to become non-effective
Type 4: NOP - This allows the IMP to know which style
leader the host wishes to use. A 1822L NOP
that the host wishes to use 1822L leaders, and an 1822
NOP signifies that the host wishes to use 1822 leaders
All of the other remarks concerning the NOP message
1822(3.3) still hold. The host should always
NOPs in groups of three to insure proper reception
the IMP. Also see section 2.4 for a further
on the use of the NOP message
Type 8: Error with Message ID - see 1822(3.3).
Type 11: Name Server Request - This allows the host to
the IMP's logical addressing tables as a name server
The destination name in the 1822L leader is translated
and the IMP replies with a Name Server Reply message
which lists the physical host addresses to which
destination name maps
Type 12: Port List Request - This allows the physical
to request the list of names that map to the host
over which this request was received by the IMP.
IMP replies with a Port List Reply message, which
the names that map to the port
Types 5-7,9-10,13-255: Unassigned
- 32 -
1822L Host Access Protocol April 1983
RFC 851
Bits 33-48: Source Host
This field contains one of the source host's 1822L
(or, alternatively, the 1822L address of the host port
message is being sent over). This field is
automatically filled in by the IMP, as in the 1822 protocol
because the host may be known by several names and may
to use a particular name as the source of this message.
messages from the same host need not use the same name
this field. Each source name, when used, is checked
authorization, effectiveness, and actually belonging to
host. Messages using names that do not satisfy all of
requirements will not be delivered, and will instead
in an error message being sent back into the source host
If the host places its 1822L address in this field,
address is checked to insure that it actually represents
host port where the message originated. If the message
destined for an 1822 host on a non-C/30 IMP, this field
contain the source host's 1822L address (see figure 4
section 2.2.4).
Bits 49-64: Destination Host
This field contains the 1822L name or address of
destination host. If it contains a name, the name will
checked for effectiveness, with an error message returned
- 33 -
1822L Host Access Protocol April 1983
RFC 851
the source host if the name is not effective. If
message is destined for an 1822 host on a non-C/30 IMP,
field MUST contain the destination host's 1822L address (
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 is also used in type 2 messages
When used in type 0 messages, bits 65-72 are also known
the Link Field, and should contain values specified
Assigned Numbers [4] appropriate for the host-to-
protocol being used
Bits 77-80: Sub-type
This field is used as a modifier by message types 0, 2, 4,
and 8.
Bits 81-96: Unused, must be zero
- 34 -
1822L Host Access Protocol April 1983
RFC 851
3.2 IMP-to-Host 1822L Leader
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
- 35 -
1822L Host Access Protocol April 1983
RFC 851
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 assigned by the source host (see
3.1). This field is only used in message types 0, 5-9,
15.
Bits 17-20: Unused and set to zero
Bit 21: Trace Bit
If equal to one, the source host designated this message
tracing as it proceeds 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
occurs via regular messages, which have several sub
types. The sub-type field (bits 77-80) is the same
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 -
1822L Host Access Protocol April 1983
RFC 851
Type 3: NDM Reply - This is a reply to the NDM host-to-
message (see section 3.1). It will have the
number of entries as the NDM message that is
replying to, and each listed 1822L name will
accompanied by a zero or a one (see figure 6). A
signifies that the name is not effective, and a
means that the name is now effective
Type 4: NOP - The host should discard this message. It
used during initialization of the IMP/
communication. The Destination Host field will
the 1822L Address of the host port over which the
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) -
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 reply to the Name
Request host-to-IMP message contains a word with
selection policy and the number of physical
to which the destination name maps, followed by
words per physical address: the first word contains
- 37 -
1822L Host Access Protocol April 1983
RFC 851
1822L address, and the second word contains a
signifying whether or not that particular
is effective and the routing distance (in 6.4 ms units
to the address's IMP. In figure 8, EFF is 1
effective and 0 for non-effective, and POL is a two-
number indicating the selection policy for the
(see section 2.2.2):
0: First reachable
1: Closest physical address
2: Load leveling
3: Unused
- 38 -
1822L Host Access Protocol April 1983
RFC 851
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
Type 12: Port List Reply - This is the reply to the
List Request host-to-IMP message. It contains
number of names that map to this physical host port
followed by two words per name: the first word
an 1822L name that maps to this port, and the
contains either a zero or a one, signifying whether
not that particular translation is effective.
format is identical to the type 3 NDM Reply
- 39 -
1822L Host Access Protocol April 1983
RFC 851
(see figure 6).
Type 15: 1822L Name or Address Error - This message is
in response to a type 0 message from a host
contained an erroneous Source Host or Destination
field. Its sub-types are
0: The Source Host 1822L name is not authorized or
effective
1: The Source Host 1822L address does not match
host port used to send the message
2: The Destination Host 1822L name is not authorized
3: The physical host to which this singly-
Destination Host name translated is authorized
up, but not effective. If the host was
down, a type 7 message would be returned, not
type 15.
4: The Source or Destination Host field contains
1822L name, but the host being addressed is on
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
to a dead or non-effective host port. However,
it is resubmitted, there may be another
host port to which the IMP may be able to
- 40 -
1822L Host Access Protocol April 1983
RFC 851
to send the packet
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 contains the 1822L name
address of the host that originated the message.
replies to the message should be sent to the host
herein. For message types 5-9 and 15, this field
the source host field used in a previous type 0 message
by this host
Bits 49-64: Destination Host
For type 0 messages, this field contains the 1822L name
address that the message was sent to. This allows
destination host to detect how it was specified by
source host. For message types 5-9 and 15, this
contains the destination host field used in a previous
0 message sent by this host
Bits 65-76: Message ID
For message types 0, 5, 7-9, and 15, this is the
assigned by the source host to identify the message (
section 3.1). This field is also used by message types 2
- 41 -
1822L Host Access Protocol April 1983
RFC 851
and 6.
Bits 77-80: Sub-type
This field is used as a modifier by message types 0-2, 5-7,
9, and 15.
Bits 81-96: Message Length
This field is contained in type 0, 3, 11, and 12
only, and is the actual length in bits of the
(exclusive of leader, leader padding, and hardware padding
as computed by the IMP
- 42 -
1822L Host Access Protocol April 1983
RFC 851
4
[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
Comments 852, April 1983.
[3] E. C. Rosen et. al., ARPANET Routing Algorithm Improvements
Internet Experimenter's Note 183 (also published as
Report 4473, Vol. 1), August 1980, pp. 55-107.
[4] J. Postel, Assigned Numbers, Request For Comments 820,
January 1983, p. 11.
- 43 -
1822L Host Access Protocol April 1983
RFC 851
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, 30
- 44 -
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
