As per Relevance of the word destination, we have this rfc below:
Network Working Group Jeffrey
Request for Comments: 917 Computer Science
Stanford
October 1984
INTERNET
Status Of This
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
We discuss the utility of "subnets" of Internet networks, which
logically visible sub-sections of a single Internet network.
administrative or technical reasons, many organizations have
to divide one Internet network into several subnets, instead
acquiring a set of Internet network numbers
We propose procedures for the use of subnets, and discuss
to solving the problems that arise, particularly that of routing
This proposal is the result of discussion with several other people
J. Noel Chiappa, Chris Kent, and Tim Mann, in particular,
important suggestions
1.
The original view of the Internet universe was a two-level hierarchy
the top level the catenet as a whole, and the level below it
collection of "Internet Networks", each with its own Network Number
(We do not mean that the Internet has a hierarchical topology,
that the interpretation of addresses is hierarchical.)
While this view has proved simple and powerful, a number
organizations have found it inadequate and have added a third
to the interpretation of Internet addresses. In this view, a
Internet Network might (or might not) be divided into a collection
subnets
The original, two-level, view carries a strong presumption that, to
host on an Internet network, that network may be viewed as a
edge; to put it another way, the network may be treated as a "
box" to which a set of hosts is connected. This is true of
Mogul [Page 1]
RFC 917 October 1984
Internet
ARPANET, because the IMPs mask the use of specific links in
network. It is also true of most local area network (LAN
technologies, such as Ethernet or ring networks
However, this presumption fails in many practical cases, because
moderately large organizations (e.g., Universities or companies
more than one building) it is often necessary to use more than
LAN cable to cover a "local area". For example, at this
there are eighteen such cables in use at Stanford University,
more planned
There are several reasons why an organization might use more than
cable to cover a campus
- Different technologies: Especially in a research environment
there may be more than one kind of LAN in use; e.g.,
organization may have some equipment that supports Ethernet,
some that supports a ring network
- Limits of technologies: Most LAN technologies impose limits
based electrical parameters, on the number of hosts connected
and on the total length of the cable. It is easy to
these limits, especially those on cable length
- Network congestion: It is possible for a small subset of
hosts on a LAN to monopolize most of the bandwidth. A
solution to this problem is to divide the hosts into cliques
high mutual communication, and put these cliques on
cables
- Point-to-Point links: Sometimes a "local area", such as
university campus, is split into two locations too far apart
connect using the preferred LAN technology. In this case
high-speed point-to-point links might connect several LANs
An organization that has been forced to use more than one LAN
three choices for assigning Internet addresses
1. Acquire a distinct Internet network number for each cable
2. Use a single network number for the entire organization,
assign host numbers without regard to which LAN a host is on
(We will call this choice "transparent subnets".)
3. Use a single network number, and partition the host
space by assigning subnet numbers to the LANs. ("
subnets".)
Mogul [Page 2]
RFC 917 October 1984
Internet
Each of these approaches has disadvantages. The first, although
requiring any new or modified protocols, does result in an
in the size of Internet routing tables. Information about
internal details of local connectivity is propagated everywhere
although it is of little or no use outside the local organization
Especially as some current gateway implementations do not have
space for routing tables, it would be nice to avoid this problem
The second approach requires some convention or protocol that
the collection of LANs appear to be a single Internet network.
example, this can be done on LANs where each Internet address
translated to a hardware address using an Address Resolution
(ARP), by having the bridges between the LANs intercept ARP
for non-local targets. However, it is not possible to do this
all LAN technologies, especially those where ARP protocols are
currently used, or if the LAN does not support broadcasts. A
fundamental problem is that bridges must discover which LAN a host
on, perhaps by using a broadcast algorithm. As the number of
grows, the cost of broadcasting grows as well; also, the size
translation caches required in the bridges grows with the
number of hosts in the network
The third approach addresses the key problem: existing
assume that all hosts on an Internet local network are on a
cable. The solution is to explicitly support subnets. This
have a disadvantage, in that it is a modification of the
Protocol, and thus requires changes to IP implementations already
use (if these implementations are to be used on a subnetted network.)
However, we believe that these changes are relatively minor, and
made, yield a simple and efficient solution to the problem. Also
the approach we take in this document is to avoid any changes
would be incompatible with existing hosts on non-subnetted networks
Further, when appropriate design choices are made, it is possible
hosts which believe they are on a non-subnetted network to be used
a subnetted one, as will be explained later. This is useful when
is not possible to modify some of the hosts to support
explicitly, or when a gradual transition is preferred. Because
this, there seems little reason to use the second approach
above
The rest of this document describes approaches to subnets of
Networks
Mogul [Page 3]
RFC 917 October 1984
Internet
1.1.
To avoid either ambiguity or prolixity, we will define a
terms, which will be used in the following sections
The collection of connected Internet
A single Internet network (that may or may not be divided
subnets.)
A subnet of an Internet network
Network
As in [8].
Local
The bits in an Internet address not used for the
number; also known as "rest field".
Subnet
A number identifying a subnet within a network
Subnet
The bit field in an Internet address used for the
number
Host
The bit field in an Internet address used for denoting
specific host
A node connected to two or more administratively
networks and/or subnets, to which hosts send datagrams to
forwarded
Mogul [Page 4]
RFC 917 October 1984
Internet
A node connected to two or more
indistinguishable but physically distinct subnets,
automatically forwards datagrams when necessary, but
existence is not know to other hosts. Also called a "
repeater".
2. Standards for Subnet
Following the division presented in [2], we observe that subnets
fundamentally an issue of addressing. In this section, we
describe a proposal for interpretation of Internet Addressing
support subnets. We then discuss the interaction between
address format and broadcasting; finally, we present a protocol
discovering what address interpretation is in use on a given network
2.1. Interpretation of Internet
Suppose that an organization has been assigned an Internet
number, has further divided that network into a set of subnets
and wants to assign host addresses: how should this be done
Since there are minimal restrictions on the assignment of
"local address" part of the Internet address, several
have been proposed for representing the subnet number
1. Variable-width field: Any number of the bits of the
address part are used for the subnet number; the size
this field, although constant for a given network,
from network to network. If the field width is zero,
subnets are not in use
2. Fixed-width field: A specific number of bits (e.g., eight
is used for the subnet number, if subnets are in use
3. Self-encoding variable-width field: Just as the width (i.e.,
class) of the network number field is encoded by
high-order bits, the width of the subnet field is
encoded
4. Self-encoding fixed-width field: A specific number of
is is used for the subnet number. Subnets are in use if
high-order bit of this field is one; otherwise, the
local address part is used for host number
Since there seems to be no advantage in doing otherwise, all
schemes place the subnet field as the most significant field
Mogul [Page 5]
RFC 917 October 1984
Internet
the local address part. Also, since the local address part of
Class C address is so small, there is little reason to
subnets of other than Class A and Class B networks
What criteria can we use to choose one of these four schemes
First, do we want to use a self-encoding scheme; that is,
it be possible to tell from examining an Internet address if
refers to a subnetted network, without reference to any
information
One advantage to self-encoding is that it allows one to
if a non-local network has been divided into subnets. It is
clear that this would be of any use. The principle advantage
however, is that no additional information is needed for
implementation to determine if two addresses are on the
subnet. However, this can also be viewed as a disadvantage:
may cause problems for non-subnetted networks which have
host numbers that use arbitrary bits in the local address
<1>. In other words, it is useful to be able control whether
network is subnetted independently from the assignment of
addresses. Another disadvantage of any self-encoding scheme
that it reduces the local address space by at least a factor
two
If a self-encoding scheme is not used, it is clear that
variable-width subnet field is appropriate. Since there must
any case be some per-network "flag" to indicate if subnets are
use, the additional cost of using an integer (the subnet
width) instead of a boolean is negligible. The advantage of
a variable-width subnet field is that it allows each
to choose the best way to allocate relatively scarce bits of
address to subnet and host numbers
Our proposal, therefore, is that the Internet address
interpreted as
where the field is as in [8], the
field is at least one bit wide, and the width of
field is constant for a given network. No
structure is required for the or
fields. If the width of the field is zero,
the network is not subnetted (i.e., the interpretation of [8]
used.)
Mogul [Page 6]
RFC 917 October 1984
Internet
For example, on a Class A network with an eight bit wide
field, an address is broken down like this
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| NETWORK | SUBNET | Host number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We expect that, for reasons of simplicity and
implementation, that most organizations will choose a subnet
width that is a multiple of eight bits. However,
implementation must be prepared to handle other possible widths
We reject the use of "recursive subnets", the division of the
field into "sub-subnet" and host parts, because
- There is no obvious need for a four-level hierarchy
- The number of bits available in an IP address is not
enough to make this useful in general
- The extra mechanism required is complex
2.2. Changes to Host Software to Support
In most implementations of IP, there is code in the module
handles outgoing packet that does something like
IF ip_net_number(packet.ip_dest) = ip_net_number(my_ip_addr
send_packet_locally(packet, packet.ip_dest
send_packet_locally(packet
gateway_to(ip_net_number(packet.ip_dest)))
(If the code supports multiple connected networks, it will be
complicated, but this is irrelevant to the current discussion.)
To support subnets, it is necessary to store one more 32-
quantity, called my_ip_mask. This is a bit-mask with bits set
the fields corresponding to the IP network number, and
bits set corresponding to the subnet number field. For example
on a Class A network using an eight-bit wide subnet field,
mask would be 255.255.0.0.
The code then becomes
Mogul [Page 7]
RFC 917 October 1984
Internet
IF bitwise_and(packet.ip_dest, my_ip_mask
= bitwise_and(my_ip_addr, my_ip_mask
send_packet_locally(packet, packet.ip_dest
send_packet_locally(packet
gateway_to(bitwise_and(packet.ip_dest, my_ip_mask)))
Of course, part of the expression in the conditionally can
pre-computed
It may or may not be necessary to modify the "gateway_to
function, so that it performs comparisons in the same way
To support multiply-connected hosts, the code can be changed
keep the "my_ip_addr" and "my_ip_mask" quantities on
per-interface basis; the expression in the conditional must
be evaluated for each interface
2.3. Subnets and
In the absence of subnets, there are only two kinds of
possible within the Internet Protocol <2>: broadcast to all
on a specific network, or broadcast to all hosts on "
network"; the latter is useful when a host does not know
network it is on
When subnets are used, the situation becomes slightly
complicated. First, the possibility now exists of broadcasting
a specific subnet. Second, broadcasting to all the hosts on
subnetted network requires additional mechanism; in [6] the use
"Reverse Path Forwarding" [3] is proposed. Finally,
interpretation of a broadcast to "this network" is that it
not be forwarded outside of the original subnet
Implementations must therefore recognize three kinds of
addresses, in addition to their own host addresses
This physical
A destination address of all ones (255.255.255.255) causes
a datagram to be sent as a broadcast on the local
network; it must not be forwarded by any gateway
Mogul [Page 8]
RFC 917 October 1984
Internet
Specific
The destination address contains a valid network number;
local address part is all ones (e.g., 36.255.255.255).
Specific
The destination address contains a valid network number and
valid subnet number; the host field is all ones (e.g.,
36.40.255.255).
For further discussion of Internet broadcasting, see [6].
One factor that may aid in deciding whether to use subnets is
it is possible to broadcast to all hosts of a subnetted
with a single operation at the originating host. It is
possible to broadcast, in one step, to the same set of hosts
they are on distinct networks
2.4. Determining the Width of the Subnet
How can a host (or gateway) determine what subnet field width
in use on a network to which it is connected? The problem
analogous to several other "bootstrapping" problems for
hosts: how a host determines its own address, and how it locates
gateway on its local network. In all three cases, there are
basic solutions: "hardwired" information, and broadcast-
protocols
"Hardwired" information is that available to a host in
from a network. It may be compiled-in, or (preferably) stored
a disk file. However, for the increasingly common case of
diskless workstation that is bootloaded over a LAN,
hard-wired solution is satisfactory. Instead, since most
technology supports broadcasting, a better method is for
newly-booted host to broadcast a request for the
information. For example, for the purpose of determining
Internet address, a host may use the "Reverse Address
Protocol" [4].
We propose to extend the ICMP protocol [9] by adding a new pair
ICMP message types, "Address Format Request" and "Address
Reply", analogous to the "Information Request" and "
Reply" ICMP messages. These are described in detail
Appendix I
The intended use of these new ICMPs is that a host, when booting
Mogul [Page 9]
RFC 917 October 1984
Internet
broadcast an "Address Format Request" message <3>. A gateway (
a host acting in lieu of a gateway) that receives this
responds with an "Address Format Reply". If there is
indication in the request which host sent it (i.e., the IP
Address is zero), the reply is broadcast as well. The
host will hear the response, and from it determine the width
the subnet field
Since there is only one possible value that can be sent in
"Address Format Reply" on any given LAN, there is no need for
requesting host to match the responses it hears against
request it sent; similarly, there is no problem if more than
gateway responds. We assume that hosts reboot infrequently,
the broadcast load on a network from use of this protocol
be small
If a host is connected to more than one LAN, it must use
protocol on each, unless it can determine (from a response on
of the LANs) that several of the LANs are part of the
network, and thus must have the same subnet field width
One potential problem is what a host should do if it receives
response to its "Address Format Request", even after a
number of tries. Three interpretations can be placed on
situation
1. The local net exists in (permanent) isolation from all
nets
2. Subnets are not in use, and no host supports this
request
3. All gateways on the local net are (temporarily) down
The first and second situations imply that the subnet field
is zero. In the third situation, there is no way to
what the proper value is; the safest choice is thus zero
Although this might later turn out to be wrong, it will
prevent transmissions that would otherwise succeed. It
possible for a host to recover from a wrong choice: when a
comes up, it should broadcast an "Address Format Reply"; when
host receives such a message that disagrees with its guess,
should adjust its data structures to conform to the
value. No host or gateway should send an "Address Format Reply
based on a "guessed" value
Mogul [Page 10]
RFC 917 October 1984
Internet
Finally, note that no host is required to use this ICMP
to discover the subnet field width; it is perfectly reasonable
a host with non-volatile storage to use stored information
3. Subnet Routing
One problem that faces all Internet hosts is how to determine a
to another host. In the presence of subnets, this problem is
slightly modified
The use of subnets means that there are two levels to the
process, instead of one. If the destination host is on the
network as the source host, the routing decision involves only
subnet gateways between the hosts. If the destination is on
different network, then the routing decision requires the choice
of a gateway out of the source host's network, and of a route
the network to that gateway
Fortunately, many hosts can ignore this distinction (and, in fact
ignore all routing choices) by using a "default" gateway as
initial route to all destinations, and relying on ICMP Host
messages to define more appropriate routes. However, this is not
efficient method for a gateway or for a multi-homed host, since
redirect may not make up for a poor initial choice of route.
hosts should use a routing information exchange protocol, but that
beyond the scope of this document; in any case, the problem
even when subnets are not used
The problem for a singly-connected host is thus to find at least
neighbor gateway. Again, there are basic two solutions to this:
hard-wired information, or use broadcasts. We believe that
neighbor-gateway acquisition problem is the same with or
subnets, and thus the choice of solution is not affected by the
of subnets
However, one problem remains: a source host must determine
datagram to a given destination address must be sent via a gateway
or sent directly to the destination host. In other words, is
destination host on the same physical network as the source?
particular phase of the routing process is the only one that
an implementation to be explicitly aware of subnets; in fact,
broadcasts are not used, it is the only place where an
implementation must be modified to support subnets
Because of this, it is possible to use some existing
without modification in the presence of subnets <4>. For this
work, such implementations must
Mogul [Page 11]
RFC 917 October 1984
Internet
- Be used only on singly-homed hosts, and not as a gateway
- Be used on a broadcast LAN
- Use an Address Resolution Protocol (ARP), such [7].
- Not be required to maintain connections in the case of
crashes
In this case, one can modify the ARP server module in a
gateway so that when it receives an ARP request, it checks the
Internet address to see if it is along the best route to the target
If it is, it sends to the requesting host an ARP response
its own hardware address. The requesting host thus believes that
knows the hardware address of the destination host, and sends
to that address. In fact, the packets are received by the gateway
and forwarded to the destination host by the usual means
This method requires some blurring of the layers in the gateways
since the ARP server and the Internet routing table would
not have any contact. In this respect, it is
unsatisfactory. Still, it is fairly easy to implement, and does
have significant performance costs. One problem is that if
original gateway crashes, there is no way for the source host
choose an alternate route even if one exists; thus, a connection
might otherwise have been maintained will be broken
One should not confuse this method of "ARP-based subnetting" with
superficially similar use of ARP-based bridges. ARP-based
is based on the ability of a gateway to examine an IP address
deduce a route to the destination, based on explicit subnet topology
In other words, a small part of the routing decision has been
from the source host into the gateway. An ARP-based bridge,
contrast, must somehow locate each host without any assistance from
mapping between host address and topology. Systems built out
ARP-based bridges should not be referred to as "subnetted".
N.B.: the use of ARP-based subnetting is complicated by the use
broadcasts. An ARP server [7] should never respond to a
whose target is a broadcast address. Such a request can only
from a host that does not recognize the broadcast address as such
and so honoring it would almost certainly lead to a forwarding loop
If there are N such hosts on the physical network that do
recognize this address as a broadcast, then a packet sent with
Time-To-Live of T could potentially give rise to T**N
re-broadcasts
Mogul [Page 12]
RFC 917 October 1984
Internet
4. Case
In this section, we briefly sketch how subnets have been used
several organizations
4.1. Stanford
At Stanford, subnets were introduced initially for
reasons. Stanford had been using the Pup protocols [1] on
collection of several Experimental Ethernets [5] since 1979,
several years before Internet protocols came into use. There
a number of Pup gateways in service, and all hosts and
acquired and exchanged routing table information using a
broadcast protocol
When the Internet Protocol was introduced, the decision was
to use an eight-bit wide subnet number; Internet subnet
were chosen to match the Pup network number of a given Ethernet
and the Pup host numbers (also eight bits) were used as the
field of the Internet address
The Pup-only gateways were then modified to forward
datagrams according to their Pup routing tables; they
had no understanding of Internet packets and in fact did
adjust the Time-to-live field in the Internet header. This
to be acceptable, since bugs that caused forwarding loops have
appeared. The Internet hosts that are multi-homed and thus
serve as gateways do adjust the Time-to-live field; since all
the currently also serve as Pup gateways, no additional
information exchange protocol was needed
Internet host implementations were modified to understand
(in several different ways, but with identical effects).
all already had Pup implementations, the Internet routing
were maintained by the same process that maintained the
routing tables, simply translating the Pup network numbers
Internet subnet numbers
When 10Mbit Ethernets were added, the gateways were modified
use the ARP-based scheme described in an earlier section;
allowed unmodified hosts to be used on the 10Mbit Ethernets
IP subnets have been in use since early 1982; currently, there
about 330 hosts, 18 subnets, and a similar number of
gateways in service. Once the Pup-only gateways are converted
be true Internet gateways, an Internet-based routing
protocol will be introduced, and Pup will be phased out
Mogul [Page 13]
RFC 917 October 1984
Internet
4.2.
MIT was the first IP site to accumulate a large collection
local network links. Since this happened before network
were divided into classes, to have assigned each link at MIT
own IP network number would have used up a good portion of
available address space. MIT decided to use one IP
number, and to manage the 24-bit "rest" field itself, by
it into three 8-bit fields; "subnet", "reserved, must be zero",
and "host". Since the CHAOS protocol already in use at MIT
an 8-bit subnet number field, it was possible to assign each
the same subnet number in both protocols. The IP host field
set to 8 bits since most available local net hardware at
point used 8 bit addresses, as did the CHAOS protocol; it was
that reserving some bits for the future was wise
The initial plan was to use a dynamic routing protocol between
IP subnet gateways; several such protocols have been mooted
nobody has bothered to implement one; static routing tables
still used. It is likely that this change will finally be
soon
To solve the problem that imported IP software always
modification to work in the subnetted environment, MIT
for a model of operation that led to the least change in host
software. This led to a model where IP gateways send ICMP
Redirects rather than Network Redirects. All internal MIT
gateways now do so. With hosts that can maintain IP
tables for non-local communication on a per host basis, this
most of the subnet structure. The "minimum adjustment" for
software to work correctly in both subnetted and non-
environments is the bit-mask algorithm mentioned earlier
MIT has no immediate plans to move toward a single "approved
protocol; this is due partly to the degree of local autonomy
the amount of installed software, and partly to the lack of
single prominent industry standard. Rather, the approach
has been to provide a single set of physical links and
switches, and to layer several "virtual" protocol nets atop
single set of links. MIT has had some bad experiences with
to exchange routing information between protocols and wrap
protocol in another; the general approach is to keep the
strictly separated except for sharing the basic hardware.
ARP to hide the subnet structure is not much in favor; it is
that this overloads the address resolution operation. In
complicated system (i.e. one with loops, and variant link speeds),
Mogul [Page 14]
RFC 917 October 1984
Internet
a more sophisticated information interchange will be
between gateways; making this an explicit mechanism (but
insulated from the hosts) was felt to be best
4.3. Carnegie-Mellon
CMU uses a Class B network currently divided into 11
subnets (two 3Mbit Experimental Ethernets, seven 10Mbit Ethernets
and two ProNet rings.) Although host numbers are assigned so
all addresses with a given third octet will be on the same
(but not necessarily vice versa), this is essentially
administrative convenience. No software currently knows
specifics of this allocation mechanism or depends on it to
between cables
Instead, an ARP-based bridge scheme is used. When a
broadcasts an ARP request, all bridges which receive it cache
original protocol address mapping and then forward the
(after the appropriate adjustments) as an ARP broadcast
onto each of their other connected cables. When a bridge
a non-broadcast ARP reply with a target protocol address not
own, it consults its ARP cache to determine the cable onto
the reply should be forwarded. The bridges thus attempt
transparently extend the ARP protocol into a
multi-cable environment. They are therefore required to turn
broadcasts on a single cable into ARP broadcasts on all
connected cables even when they "know better". This
works only in the absence of cycles in the network
graph (which is currently the case). Work is underway to
this simple-minded algorithm with a protocol implemented among
bridges, in support of redundant paths and to reduce
collective broadcast load. The intent is to retain the ARP
and host transparency, if possible
Implementations supporting the 3Mbit Ethernet and 10Mb proNET
at CMU use RFC-826 ARP (instead of some wired-in mapping such
simply using the 8-bit hardware address as the the fourth octet
the IP address).
Since there are currently no redundant paths between cables,
issue of maintaining connections across bridge crashes is moot
With about 150 IP-capable hosts on the net, the bridge caches
still of reasonable size, and little bandwidth is devoted to
broadcast forwarding
CMU's network is likely to grow from its relatively small
singly-connected configuration centered within their CS/
Mogul [Page 15]
RFC 917 October 1984
Internet
facility to a campus-wide intra-departmental configuration
5000-10000 hosts and redundant connections between cables. It
possible that the ARP-based bridge scheme will not scale to
size, and a system of explicit subnets may be required.
medium-term goal, however, is an environment into which
extant (especially 10Mb ethernet based) IP implementations can
imported; the intent is to stay with a host-transparent (
ARP-based) routing mechanism as long as possible. CMU
concerned that even if subnets become part of the IP standard
will not be widely implemented; this is the major obstacle
their use at CMU
Mogul [Page 16]
RFC 917 October 1984
Internet
I. Address Format
Address Format Request or Address Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields
The address of the source in an address format
message will be the destination of the address format
message. To form an address format reply message,
source address of the request becomes the
address of the reply, the source address of the reply is
to the replier's address, the type code changed to A2,
subnet field width inserted into the Code field, and
checksum recomputed. However, if the source address in
request message is zero, then the destination address
the reply message should denote a broadcast
ICMP Fields
A1 for address format request
A2 for address format reply
0 for address format request
Width of subnet field, in bits, for address format
The checksum is the 16-bit one's complement of the one'
Mogul [Page 17]
RFC 917 October 1984
Internet
complement sum of the ICMP message starting with the
Type. For computing the checksum, the checksum field
be zero. This checksum may be replaced in the future
An identifier to aid in matching request and replies, may
zero
Sequence
A sequence number to aid in matching request and replies
may be zero
A gateway receiving an address format request should return
with the Code field set to the number of bits of Subnet
in IP addresses for the network to which the datagram
addressed. If the request was broadcast, the
network is "this network". The Subnet field width may be
0 to (31 - N), where N is the width in bits of the IP
number field (i.e., 8, 16, or 24).
If the requesting host does not know its own IP address, it
leave the source field zero; the reply should then
broadcast. Since there is only one possible address format
a network, there is no need to match requests with replies
However, this approach should be avoided if at all possible
since it increases the superfluous broadcast load on
network
Type A1 may be received from a gateway or a host
Type A2 may be received from a gateway, or a host acting
lieu of a gateway
Mogul [Page 18]
RFC 917 October 1984
Internet
II.
For these examples, we assume that the requesting host has
36.40.0.123, that there is a gateway at 36.40.0.62, and that
network 36.0.0.0, an 8-bit wide subnet field is in use
First, suppose that broadcasting is allowed, and that 36.40.0.123
knows its own address. It sends the following datagram
Source address: 36.40.0.123
Destination address: 36.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A
Code: 0
36.40.0.62 will hear the datagram, and should respond with
datagram
Source address: 36.40.0.62
Destination address: 36.40.0.123
Protocol: ICMP = 1
Type: Address Format Reply = A
Code: 8
For the following examples, assume that address 255.255.255.255
denotes "broadcast to this physical network", as described in [6].
The previous example is inefficient, because it
broadcasts the request on many subnets. The most efficient method
and the one we recommend, is for a host to first discover its
address (perhaps using the "Reverse ARP" protocol described in [4]),
and then to send the ICMP request to 255.255.255.255:
Source address: 36.40.0.123
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A
Code: 0
The gateway can then respond directly to the requesting host
Suppose that 36.40.0.123 is a diskless workstation, and does not
even its own host number. It could send the following datagram
Mogul [Page 19]
RFC 917 October 1984
Internet
Source address: 0.0.0.0
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A
Code: 0
36.40.0.62 will hear the datagram, and should respond with
datagram
Source address: 36.40.0.62
Destination address: 36.40.255.255
Protocol: ICMP = 1
Type: Address Format Reply = A
Code: 8
Note that the gateway uses the narrowest possible broadcast to
(i.e., sending the reply to 36.255.255.255 would mean that it
transmitted on many subnets, not just the one on which it is needed.)
Even so, the overuse of broadcasts presents an unnecessary load
all hosts on the subnet, and so we recommend that use of
"anonymous" (0.0.0.0) source address be kept to a minimum
If broadcasting is not allowed, we assume that hosts have wired-
information about neighbor gateways; thus, 36.40.0.123 might
this datagram
Source address: 36.40.0.123
Destination address: 36.40.0.62
Protocol: ICMP = 1
Type: Address Format Request = A
Code: 0
36.40.0.62 should respond exactly as in the previous case
Mogul [Page 20]
RFC 917 October 1984
Internet
<1> For example, some host have addresses assigned by
their Class A network number with the low-order 24 bits of
48-bit Ethernet hardware address
<2> Our discussion of Internet broadcasting is based on [6].
<3> If broadcasting is not supported, them presumably a host "knows
the address of a neighbor gateway, and should send the ICMP
that gateway
<4> This is what was referred to earlier as the coexistence
transparent and explicit subnets on a single network
Mogul [Page 21]
RFC 917 October 1984
Internet
1. D.R. Boggs, J.F. Shoch, E.A. Taft, and R.M. Metcalfe. "Pup:
Internetwork Architecture." IEEE Transactions on
COM-28, 4, pp612-624, April 1980.
2. David D. Clark. Names, Addresses, Ports, and Routes. RFC-814,
MIT-LCS, July 1982.
3. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path
of Broadcast Packets." Comm. ACM 21, 12, pp1040-1048,
1978.
4. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.
Reverse Address Resolution Protocol. RFC-903,
University, June 1984.
5. R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed
Switching for Local Computer Networks." Comm. ACM 19, 7,
pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto
Center, reprinted in CSL-80-2.
6. Jeffrey Mogul. Broadcasting Internet Datagrams. RFC-919,
University, October 1984.
7. David Plummer. An Ethernet Address Resolution Protocol. RFC-826,
Symbolics, September 1982.
8. Jon Postel. Internet Protocol. RFC-791, USC-ISI, September 1981.
9. Jon Postel. Internet Control Message Protocol. RFC-792, USC-ISI
September 1981.
Mogul [Page 22]
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
