As per Relevance of the word datagram, we have this rfc below:
Network Working Group R.
Request for Comments: 1009 J.
Obsoletes: 985
June 1987
Requirements for Internet
Status of this
This document is a formal statement of the requirements to be met
gateways used in the Internet system. As such, it is an
specification for the Internet community. Distribution of this
is unlimited
This RFC summarizes the requirements for gateways to be used
networks supporting the Internet protocols. While it was
specifically to support National Science Foundation
programs, the requirements are stated in a general context and
applicable throughout the Internet community
The purpose of this document is to present guidance for
offering gateway products that might be used or adapted for use in
Internet application. It enumerates the protocols required and
references to RFCs and other documents describing the
specifications. In a number of cases the specifications are
and may contain ambiguous or incomplete information. In these
further discussion giving specific guidance is included in
document. Specific policy issues relevant to the NSF
networking community are summarized in an Appendix. As
specifications are updated this document will be revised.
are encouraged to maintain contact with the Internet
community
1.
The following material is intended as an introduction and
for those unfamiliar with the Internet architecture and the
gateway model. General background and discussion on the
architecture and supporting protocol suite can be found in the
Protocol Handbook [25] and ARPANET Information Brochure [26],
also [19, 28, 30, 31].
The Internet protocol architecture was originally developed
DARPA sponsorship to meet both military and civilian
requirements [32]. The Internet system presently supports a
of government and government-sponsored operational and
activities. In particular, the National Science Foundation (NSF)
building a major extension to the Internet to provide user access
Braden & Postel [Page 1]
RFC 1009 - Requirements for Internet Gateways June 1987
national supercomputer centers and other national
resources, and to provide a computer networking capability to a
number of universities and colleges
In this document there are many terms that may be obscure to
unfamiliar with the Internet protocols. There is not much to be
about that but to learn, so dive in. There are a few terms that
much abused in general discussion but are carefully and
used in this document. These few terms are defined here
Packet A packet is the unit of transmission on a
network
Datagram A datagram is the unit of transmission in the
protocol. To cross a particular network a datagram
encapsulated inside a packet
Router A router is a switch that receives data
units from input interfaces and, depending on
addresses in those units, routes them to
appropriate output interfaces. There can be
at different levels of protocol. For example
Interface Message Processors (IMPs) are packet-
routers
Gateway In the Internet documentation generally, and in
document specifically, a gateway is an IP-
router. In the Internet community the term has a
history of this usage [32].
1.1. The DARPA Internet
1.1.1. Internet
The Internet system consists of a number of
packet networks supporting communication among host
using the Internet protocols. These protocols include
Internet Protocol (IP), the Internet Control Message
(ICMP), the Transmission Control Protocol (TCP),
application protocols depending upon them [22].
All Internet protocols use IP as the basic data
mechanism. IP [1,31] is a datagram, or connectionless
internetwork service and includes provision for addressing
type-of-service specification, fragmentation and reassembly
and security information. ICMP [2] is considered an
Braden & Postel [Page 2]
RFC 1009 - Requirements for Internet Gateways June 1987
part of IP, although it is architecturally layered upon IP
ICMP provides error reporting, flow control and first-
gateway redirection
Reliable data delivery is provided in the Internet
suite by transport-level protocols such as the
Control Protocol (TCP), which provides end-end retransmission
resequencing and connection control. Transport-
connectionless service is provided by the User
Protocol (UDP).
1.1.2. Networks and
The constituent networks of the Internet system are
only to provide packet (connectionless) transport.
requires only delivery of individual packets. According to
IP service specification, datagrams can be delivered out
order, be lost or duplicated and/or contain errors.
performance of the protocols that use IP (e.g., TCP)
an IP datagram loss rate of less than 5%. In those
providing connection-oriented service, the extra
provided by virtual circuits enhances the end-end robustness
the system, but is not necessary for Internet operation
Constituent networks may generally be divided into two classes
* Local-Area Networks (LANs
LANs may have a variety of designs, typically based
buss, ring, or star topologies. In general, a LAN
cover a small geographical area (e.g., a single building
plant site) and provide high bandwidth with low delays
* Wide-Area Networks (WANs
Geographically-dispersed hosts and LANs are
by wide-area networks, also called long-haul networks
These networks may have a complex internal structure
lines and packet-routers (typified by ARPANET), or they
be as simple as point-to-point lines
In the Internet model, constituent networks are
together by IP datagram forwarders which are called "gateways
or "IP routers". In this document, every use of the
"gateway" is equivalent to "IP router". In current practice
gateways are normally realized with packet-switching
Braden & Postel [Page 3]
RFC 1009 - Requirements for Internet Gateways June 1987
executing on a general-purpose CPU, but special-
hardware may also be used (and may be required for
higher-throughput gateways).
A gateway is connected to two or more networks, appearing
each of these networks as a connected host. Thus, it has
physical interface and an IP address on each of the
networks. Forwarding an IP datagram generally requires
gateway to choose the address of the next-hop gateway or (
the final hop) the destination host. This choice,
"routing", depends upon a routing data-base within the gateway
This routing data-base should be maintained dynamically
reflect the current topology of the Internet system; a
normally accomplishes this by participating in
routing and reachability algorithms with other gateways
Gateways provide datagram transport only, and they seek
minimize the state information necessary to sustain
service in the interest of routing flexibility and robustness
Routing devices may also operate at the network level; in
memo we will call such devices MAC routers (informally
"level-2 routers", and also called "bridges"). The
derives from the fact that MAC routers base their
decision on the addresses in the MAC headers; e.g., in
802.3 networks, a MAC router bases its decision on the 48-
addresses in the MAC header. Network segments which
connected by MAC routers share the same IP network number
i.e., they logically form a single IP network
Another variation on the simple model of networks
with gateways sometimes occurs: a set of gateways may
interconnected with only serial lines, to effectively form
network in which the routing is performed at the
(IP) level rather than the network level
1.1.3. Autonomous
For technical, managerial, and sometimes political reasons,
gateways of the Internet system are grouped into
called "autonomous systems" [35]. The gateways included in
single autonomous system (AS) are expected to
* Be under the control of a single operations
maintenance (O&M) organization
* Employ common routing protocols among themselves,
maintain their routing data-bases dynamically
Braden & Postel [Page 4]
RFC 1009 - Requirements for Internet Gateways June 1987
A number of different dynamic routing protocols have
developed (see Section 4.1); the particular choice of
protocol within a single AS is generically called an
gateway protocol or IGP
An IP datagram may have to traverse the gateways of two or
ASs to reach its destination, and the ASs must provide
other with topology information to allow such forwarding.
Exterior Gateway Protocol (EGP) is used for this purpose
between gateways of different autonomous systems
1.1.4. Addresses and
An IP datagram carries 32-bit source and destination addresses
each of which is partitioned into two parts -- a
network number and a host number on that network
Symbolically
IP-address ::= { , }
To finally deliver the datagram, the last gateway in its
must map the host-number (or "rest") part of an IP address
the physical address of a host connection to the
network
This simple notion has been extended by the concept
"subnets", which were introduced in order to allow
complexity of interconnected LAN structures within
organization, while insulating the Internet system
explosive growth in network numbers and routing complexity
Subnets essentially provide a two-level hierarchical
structure for the Internet system. The subnet extension
described in RFC-950 [21], is now a required part of
Internet architecture. The basic idea is to partition
field into two parts: a subnet number, and a
host number on that subnet
IP-address ::=
{ , , }
The interconnected LANs of an organization will be given
same network number but different subnet numbers.
distinction between the subnets of such a subnetted
must not be visible outside that network. Thus, wide-
routing in the rest of the Internet will be based only upon
part of the IP destination address;
outside the network will lump and
Braden & Postel [Page 5]
RFC 1009 - Requirements for Internet Gateways June 1987
together to form an uninterpreted "rest" part of the 32-bit
address. Within the subnetted network, the local gateways
route on the basis of an extended network number
{ , }.
The bit positions containing this extended network number
indicated by a 32-bit mask called the "subnet mask" [21]; it
recommended but not required that the bits
contiguous and fall between the and
fields. No subnet should be assigned the
zero or -1 (all one bits).
Flexible use of the available address space will
increasingly important in coping with the anticipated growth
the Internet. Thus, we allow a particular subnetted network
use more than one subnet mask. Several campuses with
large LAN configurations are also creating nested
of subnets, sub-subnets, etc
There are special considerations for the gateway when
connected network provides a broadcast or multicast capability
these will be discussed later
1.2. The Internet Gateway
There are two basic models for interconnecting local-area
and wide-area (or long-haul) networks in the Internet. In
first, the local-area network is assigned a network number and
gateways in the Internet must know how to route to that network
In the second, the local-area network shares (a small part of)
address space of the wide-area network. Gateways that
this second model are called "address sharing gateways"
"transparent gateways". The focus of this memo is on
that support the first model, but this is not intended to
the use of transparent gateways
1.2.1. Internet
An Internet gateway is an IP-level router that performs
following functions
1. Conforms to specific Internet protocols specified
this document, including the Internet Protocol (IP),
Internet Control Message Protocol (ICMP), and others
necessary. See Section 2 (Protocols Required).
2. Interfaces to two or more packet networks. For
Braden & Postel [Page 6]
RFC 1009 - Requirements for Internet Gateways June 1987
connected network the gateway must implement
functions required by that network. These
typically include
a. encapsulating and decapsulating the IP datagrams
the connected network framing (e.g., an
header and checksum);
b. sending and receiving IP datagrams up to the
size supported by that network, this size is
network's "Maximum Transmission Unit" or "MTU";
c. translating the IP destination address into
appropriate network-level address for the
network (e.g., an Ethernet hardware address);
d. responding to the network flow control and
indication, if any
See Section 3 (Constituent Network Interface),
details on particular constituent network interfaces
3. Receives and forwards Internet datagrams.
issues are buffer management, congestion control,
fairness. See Section 4 (Gateway Algorithms).
a. Recognizes various error conditions and
ICMP error and information messages as required
b. Drops datagrams whose time-to-live fields
reached zero
c. Fragments datagrams when necessary to fit into
MTU of the next network
4. Chooses a next-hop destination for each IP datagram
based on the information in its routing data-base.
Section 4 (Gateway Algorithms).
5. Supports an interior gateway protocol (IGP) to carry
distributed routing and reachability algorithms with
other gateways in the same autonomous system.
addition, some gateways will need to support
Exterior Gateway Protocol (EGP) to exchange
information with other autonomous systems.
Section 4 (Gateway Algorithms).
Braden & Postel [Page 7]
RFC 1009 - Requirements for Internet Gateways June 1987
6. Provides system support facilities, including loading
debugging, status reporting, exception reporting
control. See Section 5 (Operation and Maintenance).
1.2.2. Embedded
A gateway may be a stand-alone computer system, dedicated
its IP router functions. Alternatively, it is possible
embed gateway functionality within a host operating
which supports connections to two or more networks.
best-known example of an operating system with embedded
code is the Berkeley BSD system. The embedded gateway
seems to make internetting easy, but it has a number of
pitfalls
1. If a host has only a single constituent-
interface, it should not act as a gateway
For example, hosts with embedded gateway code
gratuitously forward broadcast packets or datagrams
the same net often cause packet avalanches
2. If a (multihomed) host acts as a gateway, it
implement ALL the relevant gateway
contained in this document
For example, the routing protocol issues (see
2.6 and 4.1) and the control and monitoring problems
as hard and important for embedded gateways as
stand-alone gateways
Since Internet gateway requirements
specifications may change independently of
system changes, an administration that operates
embedded gateway in the Internet is strongly
to have an ability to maintain and update the
code (e.g., this might require gateway code source).
3. Once a host runs embedded gateway code, it becomes
of the Internet system. Thus, errors in software
configuration of such a host can hinder
between other hosts. As a consequence, the
administrator must lose some autonomy
In many circumstances, a host administrator will need
disable gateway coded embedded in the operating system
and any embedded gateway code must be organized so
can be easily disabled
Braden & Postel [Page 8]
RFC 1009 - Requirements for Internet Gateways June 1987
4. If a host running embedded gateway code is
used for other services, the O&M (operation
maintenance) requirements for the two modes of use
be in serious conflict
For example, gateway O&M will in many cases be
remotely by an operations center; this may
privileged system access which the host
would not normally want to distribute
1.2.3. Transparent
The basic idea of a transparent gateway is that the hosts
the local-area network behind such a gateway share the
space of the wide-area network in front of the gateway.
certain situations this is a very useful approach and
limitations do not present significant drawbacks
The words "in front" and "behind" indicate one of
limitations of this approach: this model of interconnection
suitable only for a geographically (and topologically)
stub environment. It requires that there be some form
logical addressing in the network level addressing of
wide-area network (that is, all the IP addresses in the
environment map to a few (usually one) physical address in
wide-area network, in a way consistent with the { IP
<-> network address } mapping used throughout the wide-
network).
Multihoming is possible on one wide-area network, but
present routing problems if the interfaces are
or topologically separated. Multihoming on two (or more
wide-area networks is a problem due to the confusion
addresses
The behavior that hosts see from other hosts in what
apparently the same network may differ if the
gateway cannot fully emulate the normal wide-area
service. For example, if there were a transparent
between the ARPANET and an Ethernet, a remote host would
receive a Destination Dead message [3] if it sent a datagram
an Ethernet host that was powered off
Braden & Postel [Page 9]
RFC 1009 - Requirements for Internet Gateways June 1987
1.3. Gateway
Every Internet gateway must perform the functions listed above
However, a vendor will have many choices on power, complexity,
features for a particular gateway product. It may be helpful
observe that the Internet system is neither homogeneous
fully-connected. For reasons of technology and geography, it
growing into a global-interconnect system plus a "fringe" of
around the "edge".
* The global-interconnect system is comprised of a number
wide-area networks to which are attached gateways of
ASs; there are relatively few hosts connected directly
it. The global-interconnect system includes the ARPANET
the NSFNET "backbone", the various NSF regional
consortium networks, other ARPA sponsored networks such
the SATNET and the WBNET, and the DCA sponsored MILNET.
is anticipated that additional networks sponsored by
and other agencies (such as NASA and DOE) will join
global-interconnect system
* Most hosts are connected to LANs, and many
have clusters of LANs interconnected by local gateways
Each such cluster is connected by gateways at one or
points into the global-interconnect system. If it
connected at only one point, a LAN is known as a "stub
network
Gateways in the global-interconnect system generally require
* Advanced routing and forwarding
These gateways need routing algorithms which are
dynamic and also offer type-of-service routing.
is still not a completely resolved issue [24].
to the current situation will be implemented soon, as
research community is actively working on these issues
* High
These gateways need to be highly reliable, providing 24
a day, 7 days a week service. In case of failure, they
recover quickly
* Advanced O&M
These gateways will typically be operated remotely from
regional or national monitoring center. In
Braden & Postel [Page 10]
RFC 1009 - Requirements for Internet Gateways June 1987
interconnect role, they will need to provide
means for monitoring and measuring traffic and other
and for diagnosing faults
* High
Although long-haul lines in the Internet today are
frequently 56 Kbps, DS1 lines (1.5 Mbps) are of
importance, and even higher speeds are likely in the future
Full-duplex operation is provided at any of these speeds
The average size of Internet datagrams is rather small,
the order of 100 bytes. At DS1 line speeds,
per-datagram processing capability of the gateways,
than the line speed, is likely to be the bottleneck.
fill a DS1 line with average-sized Internet datagrams,
gateway would need to pass -- receive, route, and send --
2,000 datagrams per second per interface. That is,
gateway which supported 3 DS1 lines and and
interface would need to be able to pass a dazzling 2,000
datagrams per second in each direction on each of
interfaces, or a aggregate throughput of 8,000 datagrams
second, in order to fully utilize DS1 lines. This is
the capability of current gateways
Note: some vendors count input and output
separately in datagrams per second figures; for
vendors, the above example would imply 16,000
per second !
Gateways used in the "LAN fringe" (e.g., campus networks)
generally have to meet less stringent requirements
performance, availability, and maintenance. These may be high
medium-performance devices, probably competitively procured
several different vendors and operated by an internal
(e.g., a campus computing center). The design of these
should emphasize low average delay and good burst performance
together with delay and type-of-service sensitive
management. In this environment, there will be less formal O&M
more hand-crafted static configurations for special cases,
more need for inter-operation with gateways of other vendors.
routing mechanism will need to be very flexible, but need not
so highly dynamic as in the global-interconnect system
It is important to realize that Internet gateways normally
in an unattended mode, but that equipment and software faults
have a wide-spread (sometimes global) effect. In any environment
Braden & Postel [Page 11]
RFC 1009 - Requirements for Internet Gateways June 1987
a gateway must be highly robust and able to operate, possibly in
degraded state, under conditions of extreme congestion or
of network resources
Even though the Internet system is not fully-interconnected,
parts of the system do need to have redundant connectivity.
rich connectivity allows reliable service despite failures
communication lines and gateways, and it can also improve
by shortening Internet paths and by providing additional capacity
The engineering tradeoff between cost and reliability must be
for each component of the Internet system
Braden & Postel [Page 12]
RFC 1009 - Requirements for Internet Gateways June 1987
2. Protocols Required in
The Internet architecture uses datagram gateways to
constituent networks. This section describes the various
which a gateway needs to implement
2.1. Internet Protocol (IP
IP is the basic datagram protocol used in the Internet system [19,
31]. It is described in RFC-791 [1] and also in MIL-STD-1777 [5]
as clarified by RFC-963 [36] ([1] and [5] are intended to
the same standard, but in quite different words). The
extension is described in RFC-950 [21].
With respect to current gateway requirements the following
features can be ignored, although they may be required in
future: Type of Service field, Security option, and Stream
option. However, if recognized, the interpretation of
quantities must conform to the standard specification
It is important for gateways to implement both the Loose
Strict Source Route options. The Record Route and
options are useful diagnostic tools and must be supported in
gateways
The Internet model requires that a gateway be able to
datagrams as necessary to match the MTU of the network to
they are being forwarded, but reassembly of fragmented
is generally left to the destination hosts. Therefore, a
will not perform reassembly on datagrams it forwards
However, a gateway will generally receive some IP
addressed to itself; for example, these may be ICMP Request/
messages, routing update messages (see Sections 2.3 and 2.6),
for monitoring and control (see Section 5). For these datagrams
the gateway will be functioning as a destination host, so it
implement IP reassembly in case the datagrams have been
by some transit gateway. The destination gateway must have
reassembly buffer which is at least as large as the maximum of
MTU values for its network interfaces and 576. Note also that
is possible for a particular protocol implemented by a host
gateway to require a lower bound on reassembly buffer size
is larger than 576. Finally, a datagram which is addressed to
gateway may use any of that gateway's IP addresses as
address, regardless of which interface the datagram enters
There are five classes of IP addresses: Class A
Class E [23]. Of these, Class D and Class E addresses
Braden & Postel [Page 13]
RFC 1009 - Requirements for Internet Gateways June 1987
reserved for experimental use. A gateway which is
participating in these experiments must ignore all datagrams
a Class D or Class E destination IP address. ICMP
Unreachable or ICMP Redirect messages must not result
receiving such datagrams
There are certain special cases for IP addresses, defined in
latest Assigned Numbers document [23]. These special cases can
concisely summarized using the earlier notation for an IP address
IP-address ::= { , }
IP-address ::= { , ,
}
if we also use the notation "-1" to mean the field contains all 1
bits. Some common special cases are as follows
(a) {0, 0}
This host on this network. Can only be used as a
address (see note later).
(b) {0, }
Specified host on this network. Can only be used as
source address
(c) { -1, -1}
Limited broadcast. Can only be used as a
address, and a datagram with this address must never
forwarded outside the (sub-)net of the source
(d) {, -1}
Directed broadcast to specified network. Can only be
as a destination address
(e) {, , -1}
Directed broadcast to specified subnet. Can only be used
a destination address
(f) {, -1, -1}
Braden & Postel [Page 14]
RFC 1009 - Requirements for Internet Gateways June 1987
Directed broadcast to all subnets of specified
network. Can only be used as a destination address
(g) {127, }
Internal host loopback address. Should never appear
a host
The following two are conventional notation for network numbers
and do not really represent IP addresses. They can never be
in an IP datagram header as an IP source or destination address
(h) {, 0}
Specified network (no host).
(i) {, , 0}
Specified subnet (no host).
Note also that the IP broadcast address, which has
application to Ethernets and similar technologies that support
inherent broadcast function, has an all-ones value in the
field of the IP address. Some early implementations chose
all-zeros value for this purpose, which is not in conformance
the specification [23, 49, 50].
2.2. Internet Control Message Protocol (ICMP
ICMP is an auxiliary protocol used to convey advice and
messages and is described in RFC-792 [2].
We will discuss issues arising from gateway handling of
ICMP messages. The ICMP messages are grouped into two classes
error messages and information messages. ICMP error messages
never sent about ICMP error messages, nor about broadcast
multicast datagrams
The ICMP error messages are: Destination Unreachable, Redirect
Source Quench, Time Exceeded, and Parameter Problem
The ICMP information messages are: Echo, Information
Timestamp, and Address Mask
Braden & Postel [Page 15]
RFC 1009 - Requirements for Internet Gateways June 1987
2.2.1. Destination
The distinction between subnets of a subnetted network,
depends on the address mask described in RFC-950 [21], must
be visible outside that network. This distinction is
in the case of the ICMP Destination Unreachable message
The ICMP Destination Unreachable message is sent by a
in response to a datagram which it cannot forward because
destination is unreachable or down. The gateway chooses one
the following two types of Destination Unreachable messages
send
* Net
* Host
Net unreachable implies that an intermediate gateway was
to forward a datagram, as its routing data-base gave no
hop for the datagram, or all paths were down. Host
implies that the destination network was reachable, but that
gateway on that network was unable to reach the
host. This might occur if the particular destination
was able to determine that the desired host was unreachable
down. It might also occur when the destination host was on
subnetted network and no path was available through the
of this network to the destination. Gateways should send
Unreachable messages whenever other hosts on the
destination network might be reachable; otherwise, the
host may erroneously conclude that ALL hosts on the network
unreachable, and that may not be the case
2.2.2.
The ICMP Redirect message is sent by a gateway to a host on
same network, in order to change the gateway used by the
for routing certain datagrams. A choice of four types
Redirect messages is available to specify datagrams
for a particular host or network, and possibly with
particular type-of-service
If the directly-connected network is not subnetted, a
can normally send a network Redirect which applies to all
on a specified remote network. Using a network rather than
host Redirect may economize slightly on network traffic and
host routing table storage. However, the saving is
significant, and subnets create an ambiguity about the
Braden & Postel [Page 16]
RFC 1009 - Requirements for Internet Gateways June 1987
mask to be used to interpret a network Redirect. In a
subnet environment, it is difficult to specify precisely
cases in which network Redirects can be used
Therefore, it is recommended that a gateway send only host (
host and type-of-service) Redirects
2.2.3. Source
All gateways must contain code for sending ICMP Source
messages when they are forced to drop IP datagrams due
congestion. Although the Source Quench mechanism is known
be an imperfect means for Internet congestion control,
research towards more effective means is in progress,
Quench is considered to be too valuable to omit from
gateways
There is some argument that the Source Quench should be
before the gateway is forced to drop datagrams [62].
example, a parameter X could be established and set to
Source Quench sent when only X buffers remain. Or, a
Y could be established and set to have Source Quench sent
only Y per cent of the buffers remain
Two problems for a gateway sending Source Quench are: (1)
consumption of bandwidth on the reverse path, and (2) the
of gateway CPU time. To ameliorate these problems, a
must be prepared to limit the frequency with which it
Source Quench messages. This may be on the basis of a
(e.g., only send a Source Quench for every N dropped
overall or per given source host), or on the basis of a
(e.g., send a Source Quench to a given source host or
at most once per T millseconds). The parameters (e.g., N or T
must be settable as part of the configuration of the gateway
furthermore, there should be some configuration setting
disables sending Source Quenches. These
parameters, including disabling, should ideally be
separately for each network interface
Note that a gateway itself may receive a Source Quench as
result of sending a datagram targeted to another gateway.
datagrams might be an EGP update, for example
2.2.4. Time
The ICMP Time Exceeded message may be sent when a
discards a datagram due to the TTL being reduced to zero.
Braden & Postel [Page 17]
RFC 1009 - Requirements for Internet Gateways June 1987
may also be sent by a gateway if the fragments of a
addressed to the gateway itself cannot be reassembled
the time limit
2.2.5. Parameter
The ICMP Parameter Problem message may be sent to the
host for any problem not specifically covered by another
message
2.2.6. Address
Host and gateway implementations are expected to support
ICMP Address Mask messages described in RFC-950 [21].
2.2.7.
The ICMP Timestamp message has proven to be useful
diagnosing Internet problems. The preferred form for
timestamp value, the "standard value", is in milliseconds
midnight GMT. However, it may be difficult to provide
value with millisecond resolution. For example, many
use clocks which update only at line frequency, 50 or 60
per second. Therefore, some latitude is allowed in
"standard" value
* The value must be updated at a frequency of at least 30
times per second (i.e., at most five low-order bits
the value may be undefined).
* The origin of the value must be within a few minutes
midnight, i.e., the accuracy with which
customarily set CPU clocks
To meet the second condition for a stand-alone gateway, it
be necessary to query some time server host when the gateway
booted or restarted. It is recommended that the UDP
Server Protocol [44] be used for this purpose. A more
implementation would use NTP (Network Time Protocol) [45]
achieve nearly millisecond clock synchronization; however,
is not required
Even if a gateway is unable to establish its time origin,
ought to provide a "non-standard" timestamp value (i.e.,
the non-standard bit set), as a time in milliseconds
system startup
Braden & Postel [Page 18]
RFC 1009 - Requirements for Internet Gateways June 1987
New gateways, especially those expecting to operate at T1
higher speeds, are expected to have at least
clocks
2.2.8. Information Request/
The Information Request/Reply pair was intended to
self-configuring systems such as diskless workstations,
allow them to discover their IP network numbers at boot time
However, the Reverse ARP (RARP) protocol [15] provides a
mechanism for a host to use to discover its own IP address,
RARP is recommended for this purpose.
Request/Reply need not be implemented in a gateway
2.2.9. Echo Request/
A gateway must implement ICMP Echo, since it has proven to
an extremely useful diagnostic tool. A gateway must
prepared to receive, reassemble, and echo an ICMP Echo
datagram at least as large as the maximum of 576 and the MTU'
of all of the connected networks. See the discussion of
reassembly in gateways, Section 2.1.
The following rules resolve the question of the use of
source routes in Echo Request and Reply datagrams. Suppose
gateway D receives an ICMP Echo Request addressed to
from host S
1. If the Echo Request contained no source route, D
send an Echo Reply back to S using its normal
rules. As a result, the Echo Reply may take a
path than the Request; however, in any case, the
will sample the complete round-trip path which any
higher-level protocol (e.g., TCP) would use for its
and ACK segments between S and D
2. If the Echo Request did contain a source route, D
send an Echo Reply back to S using as a source route
return route built up in the source-routing option
the Echo Request
Braden & Postel [Page 19]
RFC 1009 - Requirements for Internet Gateways June 1987
2.3. Exterior Gateway Protocol (EGP
EGP is the protocol used to exchange reachability
between Autonomous Systems of gateways, and is defined
RFC-904 [11]. See also RFC-827 [51], RFC-888 [46],
RFC-975 [27] for background information. The most widely used
implementation is described in RFC-911 [13].
When a dynamic routing algorithm is operated in the gateways of
Autonomous System (AS), the routing data-base must be coupled
the EGP implementation. This coupling should ensure that, when
net is determined to be unreachable by the routing algorithm,
net will not be declared reachable to other ASs via EGP.
requirement is designed to minimize spurious traffic to "
holes" and to ensure fair utilization of the resources on
systems
The present EGP specification defines a model with
limitations, most importantly a restriction against
"third party" EGP information in order to prevent long-
routing loops [27]. This effectively limits EGP to a two-
hierarchy; the top level is formed by the "core" AS, while
lower level is composed of those ASs which are direct
gateways to the core AS. In practice, in the current Internet
nearly all of the "core gateways" are connected to the ARPANET
while the lower level is composed of those ASs which are
gatewayed to the ARPANET or MILNET
RFC-975 [27] suggested one way to generalize EGP to lessen
topology restrictions; it has not been adopted as an
specification, although its ideas are finding their way into
new EGP developments. There are efforts underway in the
community to develop an EGP generalization which will remove
restrictions
In EGP, there is no standard interpretation (i.e., metric) for
distance fields in the update messages, so distances
comparable only among gateways of the same AS. In using EGP data
a gateway should compare the distances among gateways of the
AS and prefer a route to that gateway which has the
distance value
The values to be announced in the distance fields for
networks within the local AS should be a gateway
parameter; by suitable choice of these values, it will be
to arrange primary and backup paths from other AS's. There
other EGP parameters, such as polling intervals, which also
to be set in the gateway configuration
Braden & Postel [Page 20]
RFC 1009 - Requirements for Internet Gateways June 1987
When routing updates become large they must be transmitted
parts. One strategy is to use IP fragmentation, another is
explicitly send the routing information in sections. The
Engineering Task Force is currently preparing a recommendation
this and other EGP engineering issues
2.4. Address Resolution Protocol (ARP
ARP is an auxiliary protocol used to perform dynamic
translation between LAN hardware addresses and Internet addresses
and is described in RFC-826 [4].
ARP depends upon local network broadcast. In normal ARP usage
the initiating host broadcasts an ARP Request carrying a target
address; the corresponding target host, recognizing its own
address, sends back an ARP Reply containing its own
interface address
A variation on this procedure, called "proxy ARP", has been
by gateways attached to broadcast LANs [14]. The gateway sends
ARP Reply specifying its interface address in response to an
Request for a target IP address which is not on
directly-connected network but for which the gateway offers
appropriate route. By observing ARP and proxy ARP traffic,
gateway may accumulate a routing data-base [14].
Proxy ARP (also known in some quarters as "promiscuous ARP"
"the ARP hack") is useful for routing datagrams from hosts
do not implement the standard Internet routing rules fully --
example, host implementations which predate the introduction
subnetting. Proxy ARP for subnetting is discussed in detail
RFC-925 [14].
Reverse ARP (RARP) allows a host to map an Ethernet
address into an IP address [15]. RARP is intended to allow
self-configuring host to learn its own IP address from a server
boot time
2.5. Constituent Network Access
See Section 3.
Braden & Postel [Page 21]
RFC 1009 - Requirements for Internet Gateways June 1987
2.6. Interior Gateway
Distributed routing algorithms continue to be the subject
research and engineering, and it is likely that advances will
made over the next several years. A good algorithm needs
respond rapidly to real changes in Internet connectivity, yet
stable and insensitive to transients. It needs to synchronize
distributed data-base across gateways of its Autonomous
rapidly (to avoid routing loops), while consuming only a
fraction of the available bandwidth
Distributed routing algorithms are commonly broken down into
following three components
A. An algorithm to assign a "length" to each Internet path
The "length" may be a simple count of hops (1, or
if the path is broken), or an administratively-
cost, or some dynamically-measured cost (usually an
delay).
In order to determine a path length, each gateway must
least test whether each of its neighbors is reachable;
this purpose, there must be a "reachability" or "
up/down" protocol
B. An algorithm to compute the shortest path(s) to a
destination
C. A gateway-gateway protocol used to exchange path length
routing information among gateways
The most commonly-used IGPs in Internet gateways are as follows
2.6.1. Gateway-to-Gateway Protocol (GGP
GGP was designed and implemented by BBN for the
experimental Internet gateways [41]. It is still in use in
BBN LSI/11 gateways, but is regarded as having
drawbacks [58]. GGP is based upon an algorithm used in
early ARPANET IMPs and later replaced by SPF (see below).
GGP is a "min-hop" algorithm, i.e., its length measure
simply the number of network hops between gateway pairs.
implements a distributed shortest-path algorithm,
requires global convergence of the routing tables after
change in topology or connectivity. Each gateway sends a
Braden & Postel [Page 22]
RFC 1009 - Requirements for Internet Gateways June 1987
routing update only to its neighbors, but each update
an entry for every known network, where each entry contains
hop count from the gateway sending the update
2.6.2. Shortest-Path-First (SPF)
SPF [40] is the name for a class of routing algorithms based
a shortest-path algorithm of Dijkstra. The current
routing algorithm is SPF, and the BBN Butterfly gateways
use SPF. Its characteristics are considered superior
GGP [58].
Under SPF, the routing data-base is replicated rather
distributed. Each gateway will have its own copy of the
data-base, containing the entire Internet topology and
lengths of every path. Since each gateway has all the
data and runs a shortest-path algorithm locally, there is
problem of global convergence of a distributed algorithm, as
GGP. To build this replicated data-base, a gateway sends
routing updates to ALL other gateways; these updates only
the distances to each of the gateway's neighbors, making
much smaller than GGP updates. The algorithm used
distribute SPF routing updates involves reliable flooding
2.6.3. Routing Information (RIP
RIP is the name often used for a class of routing
based upon the Xerox PUP and XNS routing protocols. These
relatively simple, and are widely available because they
incorporated in the embedded gateway code of Berkeley
systems. Because of this simplicity, RIP protocols have
the closest of any to being an "Open IGP", i.e., a
which can be used between different vendors' gateways
Unfortunately, there is no standard, and in fact not even
good document, for RIP
As in GGP, gateways using RIP periodically broadcast
routing data-base to their neighbor gateways, and use
hop-count as the metric
A fixed value of the hop-count (normally 16) is defined to
"infinity", i.e., network unreachable. A RIP
must include measures to avoid both the slow-
phenomen called "counting to infinity" and the formation
routing loops. One such measure is a "hold-down" rule.
rule establishes a period of time (typically 60 seconds)
which a gateway will ignore new routing information about
given network, once the gateway has learned that network
Braden & Postel [Page 23]
RFC 1009 - Requirements for Internet Gateways June 1987
unreachable (has hop-count "infinity"). The hold-down
must be settable in the gateway configuration; if gateways
different hold-down periods are using RIP in the
Autonomous System, routing loops are a distinct possibility
In general, the hold-down period is chosen large enough
allow time for unreachable status to propagate to all
in the AS
2.6.4.
The "Fuzzball" software for an LSI/11 developed by Dave
incorporated an IGP called the "Hello" protocol [39]. This
is mentioned here because the Fuzzballs have been widely
in Internet experimentation, and because they have served as
testbed for many new routing ideas
2.7. Monitoring
See Section 5 of this document
2.8. Internet Group Management Protocol (IGMP
An extension to the IP protocol has been defined to
Internet-wide multicasting, i.e., delivery of copies of the
IP datagram to a set of Internet hosts [47, 48]. This delivery
to be performed by processes known as "multicasting agents",
reside either in a host on each net or (preferably) in
gateways
The set of hosts to which a datagram is delivered is called
"host group", and there is a host-agent protocol called IGMP
which a host uses to join, leave, or create a group. Each
group is distinguished by a Class D IP address
This multicasting mechanism and its IGMP protocol are
experimental; implementation in vendor gateways would be
at this time. A datagram containing a Class D IP address must
dropped, with no ICMP error message
Braden & Postel [Page 24]
RFC 1009 - Requirements for Internet Gateways June 1987
3. Constituent Network
This section discusses the rules used for transmission of
datagrams on the most common types of constituent networks.
gateway must be able to send and receive IP datagrams of any size
to the MTU of any constituent network to which it is connected
3.1. Public data networks via X.25
The formats specified for public data networks accessed via X.25
are described in RFC-877 [8]. Datagrams are transmitted
standard level-3 virtual circuits as complete packet sequences
Virtual circuits are usually established dynamically as
and time-out after a period of no traffic. Link-
retransmission, resequencing and flow control are performed by
network for each virtual circuit and by the LAPB link-
protocol. Note that a single X.25 virtual circuit may be used
multiplex all IP traffic between a pair of hosts. However
multiple parallel virtual circuits may be used in order to
the utilization of the subscriber access line, in spite of
X.25 window sizes; this can result in random resequencing
The correspondence between Internet and X.121 addresses is
established by table-lookup. It is expected that this will
replaced by some sort of directory procedure in the future.
table of the hosts on the Public Data Network is in the
Numbers [23].
The normal MTU is 576; however, the two DTE's (hosts or gateways
can use X.25 packet size negotiation to increase this value [8].
3.2. ARPANET via 1822 LH, DH, or
The formats specified for ARPANET networks using 1822 access
described in BBN Report 1822 [3], which includes the
for several subscriber access methods. The Distant Host (DH
method is used when the host and IMP (the Defense
Agency calls it a Packet Switch Node or PSN) are separated by
more than about 2000 feet of cable, while the HDLC Distant
(HDH) is used for greater distances where a modem is required
Under HDH, retransmission, resequencing and flow control
performed by the network and by the HDLC link-level protocol
The IP encapsulation format is simply to include the IP
as the data portion of an 1822 message. In addition,
high-order 8 bits of the Message Id field (also known as
"link" field") should be set to 155 [23]. The MTU is 1007 octets
Braden & Postel [Page 25]
RFC 1009 - Requirements for Internet Gateways June 1987
While the ARPANET 1822 protocols are widely used at present,
are expected to be eventually overtaken by the DDN Standard X.25
protocol (see Section 3.3). The original IP address
(RFC-796 [38]) is in the process of being replaced by a
interface specification called AHIP-E; see RFC-1005 [61] for
proposal
Gateways connected to ARPANET or MILNET IMPs using 1822
must incorporate features to avoid host-port blocking (i.e.,
counting) and to detect and report as ICMP Unreachable
the failure of destination hosts or gateways (i.e., convert
1822 error messages to the appropriate ICMP messages).
In the development of a network interface it will be useful
review the IMP end-to-end protocol described in RFC-979 [29].
3.3. ARPANET via DDN Standard X.25
The formats specified for ARPANET networks via X.25 are
in the Defense Data Network X.25 Host Interface Specification [6],
which describes two sets of procedures: the DDN Basic X.25,
the DDN Standard X.25. Only DDN Standard X.25 provides
functionality required for interoperability assumptions of
Internet protocol
The DDN Standard X.25 procedures are similar to the public
network X.25 procedures, except in the address mappings
Retransmission, resequencing and flow control are performed by
network and by the LAPB link-level protocol. Multiple
virtual circuits may be used in order to improve the
of the subscriber access line; this can result in
resequencing
Gateways connected to ARPANET or MILNET using Standard X.25
must detect and report as ICMP Unreachable messages the failure
destination hosts or gateways (i.e., convert the X.25
codes to the appropriate ICMP messages).
To achieve compatibility with 1822 interfaces, the effective
for a Standard X.25 interface is 1007 octets
Braden & Postel [Page 26]
RFC 1009 - Requirements for Internet Gateways June 1987
3.4. Ethernet and IEEE 802
The formats specified for Ethernet networks are described
RFC-894 [10]. Datagrams are encapsulated as Ethernet packets
48-bit source and destination address fields and a 16-bit
field (the type field values are listed in the
Numbers [23]). Address translation between Ethernet addresses
Internet addresses is managed by the Address Resolution Protocol
which is required in all Ethernet implementations. There is
explicit link-level retransmission, resequencing or flow control
although most hardware interfaces will retransmit automatically
case of collisions on the cable
The IEEE 802 networks use a Link Service Access Point (LSAP)
in much the same way the ARPANET uses the "link" field. Further
