RFC - Unknown
(October 1984; Errata)
||RFC Editor Note
RFC 917 (Unknown)
||Send notices to
Network Working Group Jeffrey Mogul
Request for Comments: 917 Computer Science Department
Status Of This Memo
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
We discuss the utility of "subnets" of Internet networks, which are
logically visible sub-sections of a single Internet network. For
administrative or technical reasons, many organizations have chosen
to divide one Internet network into several subnets, instead of
acquiring a set of Internet network numbers.
We propose procedures for the use of subnets, and discuss approaches
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, provided
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 a
collection of "Internet Networks", each with its own Network Number.
(We do not mean that the Internet has a hierarchical topology, but
that the interpretation of addresses is hierarchical.)
While this view has proved simple and powerful, a number of
organizations have found it inadequate and have added a third level
to the interpretation of Internet addresses. In this view, a given
Internet Network might (or might not) be divided into a collection of
The original, two-level, view carries a strong presumption that, to a
host on an Internet network, that network may be viewed as a single
edge; to put it another way, the network may be treated as a "black
box" to which a set of hosts is connected. This is true of the
Mogul [Page 1]
RFC 917 October 1984
ARPANET, because the IMPs mask the use of specific links in that
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 in
moderately large organizations (e.g., Universities or companies with
more than one building) it is often necessary to use more than one
LAN cable to cover a "local area". For example, at this writing
there are eighteen such cables in use at Stanford University, with
There are several reasons why an organization might use more than one
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., an
organization may have some equipment that supports Ethernet, and
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 exceed
these limits, especially those on cable length.
- Network congestion: It is possible for a small subset of the
hosts on a LAN to monopolize most of the bandwidth. A common
solution to this problem is to divide the hosts into cliques of
high mutual communication, and put these cliques on separate
- Point-to-Point links: Sometimes a "local area", such as a
university campus, is split into two locations too far apart to
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 has
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, but
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 address
space by assigning subnet numbers to the LANs. ("Explicit
Mogul [Page 2]
RFC 917 October 1984
Each of these approaches has disadvantages. The first, although not
requiring any new or modified protocols, does result in an explosion
in the size of Internet routing tables. Information about the
internal details of local connectivity is propagated everywhere,
Show full document text