the distances to each of the gateway's neighbors, making them
much smaller than GGP updates. The algorithm used to
distribute SPF routing updates involves reliable flooding.
2.6.3. Routing Information (RIP)
RIP is the name often used for a class of routing protocols
based upon the Xerox PUP and XNS routing protocols. These are
relatively simple, and are widely available because they are
incorporated in the embedded gateway code of Berkeley BSD
systems. Because of this simplicity, RIP protocols have come
the closest of any to being an "Open IGP", i.e., a protocol
which can be used between different vendors' gateways.
Unfortunately, there is no standard, and in fact not even a
good document, for RIP.
As in GGP, gateways using RIP periodically broadcast their
routing data-base to their neighbor gateways, and use a
hop-count as the metric.
A fixed value of the hop-count (normally 16) is defined to be
"infinity", i.e., network unreachable. A RIP implementation
must include measures to avoid both the slow-convergence
phenomen called "counting to infinity" and the formation of
routing loops. One such measure is a "hold-down" rule. This
rule establishes a period of time (typically 60 seconds) during
which a gateway will ignore new routing information about a
given network, once the gateway has learned that network is
RFC1009 - Requirements for Internet Gateways June 1987
unreachable (has hop-count "infinity"). The hold-down period
must be settable in the gateway configuration; if gateways with
different hold-down periods are using RIP in the same
Autonomous System, routing loops are a distinct possibility.
In general, the hold-down period is chosen large enough to
allow time for unreachable status to propagate to all gateways
in the AS.
2.6.4. Hello
The "Fuzzball" software for an LSI/11 developed by Dave Mills
incorporated an IGP called the "Hello" protocol [39]. This IGP
is mentioned here because the Fuzzballs have been widely used
in Internet experimentation, and because they have served as a
testbed for many new routing ideas.
2.7. Monitoring Protocols
See Section 5 of this document.
2.8. Internet Group Management Protocol (IGMP)
An extension to the IP protocol has been defined to provide
Internet-wide multicasting, i.e., delivery of copies of the same
IP datagram to a set of Internet hosts [47, 48]. This delivery is
to be performed by processes known as "multicasting agents", which
reside either in a host on each net or (preferably) in the
gateways.
The set of hosts to which a datagram is delivered is called a
"host group", and there is a host-agent protocol called IGMP,
which a host uses to join, leave, or create a group. Each host
group is distinguished by a Class D IP address.
This multicasting mechanism and its IGMP protocol are currently
experimental; implementation in vendor gateways would be premature
at this time. A datagram containing a Class D IP address must be
dropped, with no ICMP error message.
RFC1009 - Requirements for Internet Gateways June 1987
3. Constituent Network Interface
This section discusses the rules used for transmission of IP
datagrams on the most common types of constituent networks. A
gateway must be able to send and receive IP datagrams of any size up
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 over
standard level-3 virtual circuits as complete packet sequences.
Virtual circuits are usually established dynamically as required
and time-out after a period of no traffic. Link-level
retransmission, resequencing and flow control are performed by the
network for each virtual circuit and by the LAPB link-level
protocol. Note that a single X.25 virtual circuit may be used to
multiplex all IP traffic between a pair of hosts. However,
multiple parallel virtual circuits may be used in order to improve
the utilization of the subscriber access line, in spite of small
X.25 window sizes; this can result in random resequencing.
The correspondence between Internet and X.121 addresses is usually
established by table-lookup. It is expected that this will be
replaced by some sort of directory procedure in the future. The
table of the hosts on the Public Data Network is in the Assigned
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 HDH
The formats specified for ARPANET networks using 1822 access are
described in BBN Report 1822 [3], which includes the procedures
for several subscriber access methods. The Distant Host (DH)
method is used when the host and IMP (the Defense Communication
Agency calls it a Packet Switch Node or PSN) are separated by not
more than about 2000 feet of cable, while the HDLC Distant Host
(HDH) is used for greater distances where a modem is required.
Under HDH, retransmission, resequencing and flow control are
performed by the network and by the HDLC link-level protocol.
The IP encapsulation format is simply to include the IP datagram
as the data portion of an 1822 message. In addition, the
high-order 8 bits of the Message Id field (also known as the
"link" field") should be set to 155 [23]. The MTU is 1007 octets.
RFC1009 - Requirements for Internet Gateways June 1987
While the ARPANET 1822 protocols are widely used at present, they
are expected to be eventually overtaken by the DDN Standard X.25
protocol (see Section 3.3). The original IP address mapping
(RFC-796 [38]) is in the process of being replaced by a new
interface specification called AHIP-E; see RFC-1005 [61] for the
proposal.
Gateways connected to ARPANET or MILNET IMPs using 1822 access
must incorporate features to avoid host-port blocking (i.e., RFNM
counting) and to detect and report as ICMP Unreachable messages
the failure of destination hosts or gateways (i.e., convert the
1822 error messages to the appropriate ICMP messages).
In the development of a network interface it will be useful to
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 described
in the Defense Data Network X.25 Host Interface Specification [6],
which describes two sets of procedures: the DDN Basic X.25, and
the DDN Standard X.25. Only DDN Standard X.25 provides the
functionality required for interoperability assumptions of the
Internet protocol.
The DDN Standard X.25 procedures are similar to the public data
network X.25 procedures, except in the address mappings.
Retransmission, resequencing and flow control are performed by the
network and by the LAPB link-level protocol. Multiple parallel
virtual circuits may be used in order to improve the utilization
of the subscriber access line; this can result in random
resequencing.
Gateways connected to ARPANET or MILNET using Standard X.25 access
must detect and report as ICMP Unreachable messages the failure of
destination hosts or gateways (i.e., convert the X.25 diagnostic
codes to the appropriate ICMP messages).
To achieve compatibility with 1822 interfaces, the effective MTU
for a Standard X.25 interface is 1007 octets.
RFC1009 - Requirements for Internet Gateways June 1987
3.4. Ethernet and IEEE 802
The formats specified for Ethernet networks are described in
RFC-894 [10]. Datagrams are encapsulated as Ethernet packets with
48-bit source and destination address fields and a 16-bit type
field (the type field values are listed in the Assigned
Numbers [23]). Address translation between Ethernet addresses and
Internet addresses is managed by the Address Resolution Protocol,
which is required in all Ethernet implementations. There is no
explicit link-level retransmission, resequencing or flow control,
although most hardware interfaces will retransmit automatically in
case of collisions on the cable.
The IEEE 802 networks use a Link Service Access Point (LSAP) field
in much the same way the ARPANET uses the "link" field. Further,
there is an extension of the LSAP header called the Sub-Network
Access Protocol (SNAP).
The 802.2 encapsulation is used on 802.3, 802.4, and 802.5 network
by using the SNAP with an organization code indicating that the
following 16 bits specify the Ether-Type code [23].
Headers:
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
+--------+--------+--------+
| DSAP=K1| SSAP=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+--------+--------+--------+
|protocol id or org code=K2| Ether-Type | 802.2 SNAP
+--------+--------+--------+--------+--------+
The total length of the SAP Header and the SNAP header is
8-octets, making the 802.2 protocol overhead come out on a 64-bit
boundary.
K1 is 170. The IEEE likes to talk about things in bit
transmission order and specifies this value as 01010101. In
big-endian order, as used in the Internet specifications, this
becomes 10101010 binary, or AA hex, or 170 decimal. K2 is 0
(zero).
The use of the IP LSAP (K1 = 6) is reserved for future
development.
RFC1009 - Requirements for Internet Gateways June 1987
The assigned values for the Ether-Type field are the same for
either this IEEE 802 encapsulation or the basic Ethernet
encapsulation [10].
In either Ethernets or IEEE 802 nets, the IP datagram is the data
portion of the packet immediately following the Ether-Type.
The MTU for an Ethernet or its IEEE-standard equivalent (802.3) is
1500 octets.
3.5. Serial-Line Protocols
In some configurations, gateways may be interconnected with each
other by means of serial asynchronous or synchronous lines, with
or without modems. When justified by the expected error rate and
other factors, a link-level protocol may be required on the serial
line. While there is no single Internet standard for this
protocol, it is suggested that one of the following protocols be
used.
* X.25 LAPB (Synchronous Lines)
This is the link-level protocol used for X.25 network
access. It includes HDLC "bit-stuffing" as well as
rotating-window flow control and reliable delivery.
A gateway must be configurable to play the role of either
the DCE or the DTE.
* HDLC Framing (Synchronous Lines)
This is just the bit-stuffing and framing rules of LAPB. It
is the simplest choice, although it provides no flow control
or reliable delivery; however, it does provide error
detection.
* Xerox Synchronous Point-to-Point (Synchronous Lines)
This Xerox protocol is an elaboration upon HDLC framing that
includes negotiation of maximum packet sizes, dial-up or
dedicated circuits, and half- or full-duplex operation [12].
* Serial Line Framing Protocol (Asynchronous Lines)
This protocol is included in the MIT PC/IP package for an
IBM PC and is defined in Appendix I to the manual for that
system [20].
RFC1009 - Requirements for Internet Gateways June 1987
It will be important to make efficient use of the bandwidth
available on a serial line between gateways. For example, it is
desirable to provide some form of data compression. One possible
standard compression algorithm, "Thinwire II", is described in
RFC-914 [42]. This and similar algorithms are tuned to the
particular types of redundancy which occur in IP and TCP headers;
however, more work is necessary to define a standard serial-line
compression protocol for Internet gateways. Until a standard has
been adopted, each vendor is free to choose a compression
algorithm; of course, the result will only be useful on a serial
line between two gateways using the same compression algorithm.
Another way to ensure maximum use of the bandwidth is to avoid
unnecessary retransmissions at the link level. For some kinds of
IP traffic, low delay is more important than reliable delivery.
The serial line driver could distinguish such datagrams by their
IP TOS field, and place them on a special high-priority,
no-retransmission queue.
A serial point-to-point line between two gateways may be
considered to be a (particularly simple) network, a "null net".
Considered in this way, a serial line requires no special
considerations in the routing algorithms of the connected
gateways, but does need an IP network number. To avoid the
wholesale consumption of Internet routing data-base space by null
nets, we strongly recommend that subnetting be used for null net
numbering, whenever possible.
For example, assume that network 128.203 is to be constructed
of gateways joined by null nets; these nets are given (sub-)net
numbers 128.203.1, 128.203.2, etc., and the two interfaces on
each end of null net 128.203.s might have IP addresses
128.203.s.1 and 128.203.s.2.
An alternative model of a serial line is that it is not a network,
but rather an internal communication path joining two "half
gateways". It is possible to design an IGP and routing algorithm
that treats a serial line in this manner [39, 52].
RFC1009 - Requirements for Internet Gateways June 1987
4. Gateway Algorithms
Gateways are general packet-switches that forward packets according
to the IP address, i.e., they are IP routers. While it is beyond
the scope of this document to specify the details of the mechanisms
used in any particular, perhaps proprietary, gateway architecture,
there are a number of basic algorithms which must be provided by any
acceptable design.
4.1. Routing Algorithm
The routing mechanism is fundamental to Internet operation. In
all but trivial network topologies, robust Internet service
requires some degree of routing dynamics, whether it be effected
by manual or automatic means or by some combination of both. In
particular, if routing changes are made manually, it must be
possible to make these routing changes from a remote Network
Operation Center (NOC) without taking down the gateway for
reconfiguration. If static routes are used, there must be
automatic fallback or rerouting features.
Handling unpredictable changes in Internet connectivity must be
considered the normal case, so that systems of gateways will
normally be expected to have a routing algorithm with the
capability of reacting to link and other gateway failures and
changing the routing automatically.
This document places no restriction on the type of routing
algorithm, e.g., node-based, link-based or any other algorithm, or
on the routing distance metric, e.g., delay or hop-count.
However, the following features are considered necessary for a
successful gateway routing algorithm:
1. The algorithm must sense the failure or restoration of a
link or other gateway and switch to appropriate paths. A
design objective is to switch paths within an interval less
than the typical TCP user time-out (one minute is a safe
assumption).
2. The algorithm must suppress routing loops between neighbor
gateways and must contain provisions to avoid or suppress
routing loops that may form between non-neighbor gateways.
A design objective is for no loop to persist for longer
than an interval greater than the typical TCP user
time-out.
3. The control traffic necessary to operate the routing
algorithm must not significantly degrade or disrupt normal
RFC1009 - Requirements for Internet Gateways June 1987
network operation. Changes in state which might
momentarily disrupt normal operation in a local-area must
not cause disruption in remote areas of the network.
4. As the size of the network increases, the demand on
resources must be controlled in an efficient way. Table
lookups should be hashed, for example, and data-base
updates handled piecemeal, with only incremental changes
broadcast over a wide-area.
5. The size of the routing data-base must not be allowed to
exceed a constant, independent of network topology, times
the number of nodes times the mean connectivity (average
number of incident links). An advanced design might not
require that the entire routing data-base be kept in any
particular gateway, so that discovery and caching
techniques would be necessary.
6. Reachability and delay metrics, if used, must not depend on
direct connectivity to all other gateways or on the use of
network-specific broadcast mechanisms. Polling procedures
(e.g., for consistency checking) must be used only
sparingly and in no case introduce an overhead exceeding a
constant, independent of network topology, times the
longest non-looping path.
7. Default routes (generally intended as a means to reduce the
size of the routing data-base) must be used with care,
because of the many problems with multiple paths, loops,
and mis-configurations which routing defaults have caused.
The most common application of defaults is for routing
within an Internet region which is connected in a strictly
hierarchical fashion and is a stub from the rest of the
Internet system. In this case, the default is used for
routing "up" the tree. Unfortunately, such restricted
topology seldom lasts very long, and defaults cease to
work.
More generally, defaults could be used for initial routing
guesses, with final routes to be discovered and cached from
external or internal data-bases via the routing algorithm
or EGP.
RFC1009 - Requirements for Internet Gateways June 1987
4.2. Subnets and Routing
We will call a gateway "subnetted" if at least one of its
interfaces is connected to a subnet; the set of gateways directly
connected to subnets of the same network will be referred to as a
"subnet cluster". For example, in the following diagram, network
2 is subnetted, with subnets 2.1 and 2.2, but network 1 is not;
gateways 1, 2, and 3 are subnetted and are members of the same
subnet cluster.
(Net 1) === [Gwy 1] === (Net 2.1) === [Gwy 2] === (Net 2.2)
| |
| |
=================== [Gwy 3] =======================
Subnets have the following effects on gateway routing:
A. Non-subnetted gateways are not affected at all.
B. The routing data-base in a subnetted gateway must consider
the address mask for subnet entries.
C. Routing updates among the gateways in the same subnet
cluster must include entries for the various subnets. The
corresponding address mask(s) may be implicit, but for full
generality the mask needs to be given explicitly for each
entry. Note that if the routing data-base included a full
32-bit mask for every IP network, the gateway could deal
with networks and subnets in a natural way. This would
also handle the case of multiple subnet masks for the same
subnetted network.
D. Routing updates from a subnetted gateway to a gateway
outside the cluster can contain nets, never subnets.
E. If a subnetted gateway (e.g., gateway 2 above) is unable to
forward a datagram from one subnet to another subnet of the
same network, then it must return a Host Unreachable, not a
Net Unreachable, as discussed in Section 2.2.1.
When considering the choice of routing protocol, a gateway builder
must consider how that protocol generalizes for subnets. For some
routing protocols it will be possible to use the same procedures
in a regular gateway and a subnetted gateway, with only a change
of parameters (e.g., address masks).
A different subnet address mask must be configurable for each
RFC1009 - Requirements for Internet Gateways June 1987
interface of a given gateway. This will allow a subnetted gateway
to connect to two different subnetted networks, or to connect two
subnets of the same network with different masks.
4.3 Resource Allocation
In order to perform its basic datagram-forwarding functions, a
gateway must allocate resources; its packet buffers and CPU time
must be allocated to packets it receives from connected networks,
while the bandwidth to each of the networks must also be allocated
for sending packets. The choice of allocation strategies will be
critical when a particular resource is scarce. The most obvious
allocation strategy, first-come-first-served (FCFS), may not be
appropriate under overload conditions, for reasons which we will
now explore.
A first example is buffer allocation. It is important for a
gateway to allocate buffers fairly among all of its connected
networks, even if these networks have widely varying bandwidths.
A high-speed interface must not be allowed to starve slower
interfaces of buffers. For example, consider a gateway with a
10 Mbps Ethernet connection and two 56 Kbps serial lines. A buggy
host on the Ethernet may spray that gateway interface with packets
at high speed. Without careful algorithm design in the gateway,
this could tie up all the gateway buffers in such a way that
transit traffic between the serial lines would be completely
stopped.
Allocation of output bandwidth may also require non-FCFS
strategies. In an advanced gateway design, allocation of output
bandwidth may depend upon Type-of-Service bits in the IP headers.
A gateway may also want to give priority to datagrams for its own
up/down and routing protocols.
Finally, Nagle [24] has suggested that gateways implement "fair
queueing", i.e., sharing output bandwidth equitably among the
current traffic sources. In his scheme, for each network
interface there would be a dynamically-built set of output queues,
one per IP source address; these queues would be serviced in a
round-robin fashion to share the bandwidth. If subsequent
research shows fair queueing to be desirable, it will be added to
a future version of this document as a universal requirement.
RFC1009 - Requirements for Internet Gateways June 1987
4.4. Special Addresses and Filters
Section 2.1 contained a list of the 32-bit IP addresses which have
special meanings. They do not in general represent unique IP
addresses of Internet hosts, and there are restrictions on their
use in IP headers.
We can distinguish two classes of these special cases. The first
class (specifically, cases (a), (b), (c), (g), (h), and (i) in
section 2.1) contains addresses which should never appear in the
destination address field of any IP datagram, so a gateway should
never be asked to route to one of these addresses. However, in
the real world of imperfect implementations and configuration
errors, such bad destination addresses do occur. It is the
responsibility of a gateway to avoid propagating such erroneous
addresses; this is especially important for gateways included in
the global interconnect system. In particular, a gateway which
receives a datagram with one of these forbidden addresses should:
1. Avoid inserting that address into its routing database, and
avoid including it in routing updates to any other gateway.
2. Avoid forwarding a datagram containing that address as a
destination.
To enforce these restrictions, it is suggested that a gateway
include a configurable filter for datagrams and routing updates.
A typical filter entry might consist of a 32-bit mask and value
pair. If the logical AND of the given address with the mask
equals the value, a match has been found. Since filtering will
consume gateway resources, it is vital that the gateway
configuration be able to control the degree of filtering in use.
There is a second class of special case addresses (cases (d), (e),
and (f) in section 2.1), the so-called "directed broadcasts". A
directed broadcast is a datagram to be forwarded normally to the
specified destination (sub-)net and then broadcast on the final
hop. An Internet gateway is permitted, but not required, to
filter out directed broadcasts destined for any of its
locally-connected networks. Hence, it should be possible to
configure the filter to block the delivery of directed broadcasts.
Finally, it will also be useful for Internet O&M to have a
configurable filter on the IP source address. This will allow a
network manager to temporarily block traffic from a particular
misbehaving host, for example.
RFC1009 - Requirements for Internet Gateways June 1987
4.5. Redirects
The ICMP Redirect message is specified only for use by a gateway
to update the routing table of a host on the same connected net.
However, the Redirect message is sometimes used between gateways,
due to the following considerations:
The routing function in a host is very much like that in a
"dumb gateway" (i.e., a gateway having only static routes). It
is desirable to allow the routing tables of a dumb gateway to
be changed under the control of a dynamic gateway (i.e., a
gateway with full dynamic routing) on the same network. By
analogy, it is natural to let the dynamic gateway send ICMP
Redirect messages to dumb gateway.
The use of ICMP Redirect between gateways in this fashion may be
considered to be part of the IGP (in fact, the totality of the
IGP, as far as the dumb gateway is concerned!) in the particular
Autonomous System. Specification of an IGP is outside the scope
of this document, so we only note the possibility of using
Redirect in this fashion. Gateways are not required to receive
and act upon redirects, and in fact dynamic gateways must ignore
them. We also note that considerable experience shows that dumb
gateways often create problems resulting in "black holes"; a full
routing gateway is always preferable.
Routing table entries established by redirect messages must be
removed automatically, either by a time-out or when a use count
goes to zero.
4.6. Broadcast and Multicast
A host which is connected to a network (generally a LAN) with an
intrinsic broadcast capability may want to use this capability to
effect multidestination delivery of IP datagrams. The basic
Internet model assumes point-to-point messages, and we must take
some care when we incorporate broadcasting. It is important to
note that broadcast addresses may occur at two protocol levels:
the local network header and the IP header.
Incorrect handling of broadcasting has often been the cause of
packet avalanches (sometimes dubbed "meltdown") in LANs. These
avalanches are generally caused by gratuitous datagram-forwarding
by hosts, or by hosts sending ICMP error messages when they
discard broadcast datagrams.
Gateways have a responsibility to prevent avalanches, or datagrams
which can trigger avalanches, from escaping into another network.
RFC1009 - Requirements for Internet Gateways June 1987
In general, a gateway must not forward a datagram which arrives
via local network broadcast, and must not send an ICMP error
message when dropping the datagram. A discussion of the rules
will be found in Appendix A; see also [50].
As noted in Section 4.4, a gateway is permitted to filter out
directed broadcasts. Hence, directed broadcasts will only be
useful in limited Internet regions (e.g., the within the subnets
of a particular campus) in which delivery is supported by the
gateway administrators. Host group multicasting (see Sections 2.8
and 4.6) will soon provide a much more efficient mechanism than
directed broadcasting. Gateway algorithms for host group
multicasting will be specified in future RFC's.
4.7. Reachability Procedures
The architecture must provide a robust mechanism to establish the
operational status of each link and node in the network, including
the gateways, the links connecting them and, where appropriate,
the hosts as well. Ordinarily, this requires at least a
link-level reachability protocol involving a periodic exchange of
messages across each link. This function might be intrinsic to
the link-level protocols used (e.g., LAPB). However, it is in
general ill-advised to assume a host or gateway is operating
correctly even if its link-level reachability protocol is
operating correctly. Additional confirmation is required in the
form of an operating routing algorithm or peer-level reachability
protocol (such as used in EGP).
Failure and restoration of a link and/or gateway are considered
network events and must be reported to the control center. It is
desirable, although not required, that reporting paths not require
correct functioning of the routing algorithm itself.
4.8. Time-To-Live
The Time-to-Live (TTL) field of the IP header is defined to be a
timer limiting the lifetime of a datagram in the Internet. It is
an 8-bit field and the units are seconds. This would imply that
for a maximum TTL of 255 a datagram would time-out after about 4
and a quarter minutes. Another aspect of the definition requires
each gateway (or other module) that handles a datagram to
decrement the TTL by at least one, even if the elapsed time was
much less than a second. Since this is very often the case, the
TTL effectively becomes a hop count limit on how far a datagram
can propagate through the Internet.
RFC1009 - Requirements for Internet Gateways June 1987
As the Internet grows, the number of hops needed to get from one
edge to the opposite edge increases, i.e., the Internet diameter
grows.
If a gateway holds a datagram for more than one second, it must
decrement the TTL by one for each second.
If the TTL is reduced to zero, the datagram must be discarded, and
the gateway may send an ICMP Time Exceeded message to the source.
A datagram should never be received with a TTL of zero.
When it originates a datagram, a gateway is acting in the role of
a host and must supply a realistic initial value for the TTL.
RFC1009 - Requirements for Internet Gateways June 1987
5. Operation and Maintenance
5.1. Introduction
Facilities to support operation and maintenance (O&M) activities
form an essential part of any gateway implementation. The
following kinds of activity are included under gateway O&M:
* Diagnosing hardware problems in the gateway processor, in
its network interfaces, or in the connected networks,
modems, or communication lines.
* Installing a new version of the gateway software.
* Restarting or rebooting a gateway after a crash.
* Configuring (or reconfiguring) the gateway.
* Detecting and diagnosing Internet problems such as
congestion, routing loops, bad IP addresses, black holes,
packet avalanches, and misbehaved hosts.
* Changing network topology, either temporarily (e.g., to
diagnose a communication line problem) or permanently.
* Monitoring the status and performance of the gateways and
the connected networks.
* Collecting traffic statistics for use in (Inter-)network
planning.
Gateways, packet-switches, and their connected communication lines
are often operated as a system by a centralized O&M organization.
This organization will maintain a (Inter-)network operation
center, or NOC, to carry out its O&M functions. It is essential
that gateways support remote control and monitoring from such a
NOC, through an Internet path (since gateways might not be
connected to the same network as their NOC). Furthermore, an IP
datagram traversing the Internet will often use gateways under the
control of more than one NOC; therefore, Internet problem
diagnosis will often involve cooperation of personnel of more than
one NOC. In some cases, the same gateway may need to be monitored
by more than one NOC.
The tools available for monitoring at a NOC may cover a wide range
of sophistication. Proposals have included multi-window, dynamic
displays of the entire gateway system, and the use of AI
techniques for automatic problem diagnosis.
RFC1009 - Requirements for Internet Gateways June 1987
Gateway O&M facilities discussed here are only a part of the large
and difficult problem of Internet management. These problems
encompass not only multiple management organizations, but also
multiple protocol layers. For example, at the current stage of
evolution of the Internet architecture, there is a strong coupling
between host TCP implementations and eventual IP-level congestion
in the gateway system [9]. Therefore, diagnosis of congestion
problems will sometimes require the monitoring of TCP statistics
in hosts. Gateway algorithms also interact with local network
performance, especially through handling of broadcast packets and
ARP, and again diagnosis will require access to hosts (e.g.,
examining ARP caches). However, consideration of host monitoring
is beyond the scope of this RFC.
There are currently a number of R&D efforts in progress in the
area of Internet management and more specifically gateway O&M. It
is hoped that these will lead quickly to Internet standards for
the gateway protocols and facilities required in this area. This
is also an area in which vendor creativity can make a significant
contribution.
5.2. Gateway O&M Models
There is a range of possible models for performing O&M functions
on a gateway. At one extreme is the local-only model, under which
the O&M functions can only be executed locally, e.g., from a
terminal plugged into the gateway machine. At the other extreme,
the fully-remote model allows only an absolute minimum of
functions to be performed locally (e.g., forcing a boot), with
most O&M being done remotely from the NOC. There intermediate
models, e.g., one in which NOC personnel can log into the gateway
as a host, using the Telnet protocol, to perform functions which
can also be invoked locally. The local-only model may be adequate
in a few gateway installations, but in general remote operation
from a NOC will be required, and therefore remote O&M provisions
are required for most gateways.
Remote O&M functions may be exercised through a control agent
(program). In the direct approach, the gateway would support
remote O&M functions directly from the NOC using standard Internet
protocols (e.g., UDP or TCP); in the indirect approach, the
control agent would support these protocols and control the
gateway itself using proprietary protocols. The direct approach
is preferred, although either approach is acceptable. The use of
specialized host hardware and/or software requiring significant
additional investment is discouraged; nevertheless, some vendors
may elect to provide the control agent as an integrated part of
the network in which the gateways are a part. If this is the
RFC1009 - Requirements for Internet Gateways June 1987
case, it is required that a means be available to operate the
control agent from a remote site using Internet protocols and
paths and with equivalent functionality with respect to a local
agent terminal.
It is desirable that a control agent and any other NOC software
tools which a vendor provides operate as user programs in a
standard operating system. The use of the standard Internet
protocols UDP and TCP for communicating with the gateways should
facilitate this.
Remote gateway monitoring and (especially) remote gateway control
present important access control problems which must be addressed.
Care must also be taken to ensure control of the use of gateway
resources for these functions. It is not desirable to let gateway
monitoring take more than some limited fraction of the gateway CPU
time, for example. On the other hand, O&M functions must receive
priority so they can be exercised when the gateway is congested,
i.e., when O&M is most needed.
There are no current Internet standards for the control and
monitoring protocols, although work is in progress in this area.
The Host Monitoring Protocol (HMP) [7] could be used as a model
until a standard is developed; however, it is strongly recommended
that gateway O&M protocol be built on top of one of the standard
Internet end-to-end protocols UDP or TCP. An example of a very
simple but effective approach to gateway monitoring is contained
in RFC-996 [43].
5.3. Gateway O&M Functions
The following O&M functions need to be performed in a gateway:
A. Maintenance -- Hardware Diagnosis
Each gateway must operate as a stand-alone device for the
purposes of local hardware maintenance. Means must be
available to run diagnostic programs at the gateway site
using only on-site tools, which might be only a diskette or
tape and local terminal. It is desirable, although not
required, to be able to run diagnostics or dump the gateway
via the network in case of fault. Means should be provided
to allow remote control from the NOC of of modems attached
to the gateway. The most important modem control capability
is entering and leaving loopback mode, to diagnose line
problems.
RFC1009 - Requirements for Internet Gateways June 1987
B. Control -- Dumping and Rebooting
It must be possible to dump and reboot a stand-alone gateway
upon command from the NOC. In addition, a stand-alone
gateway must include a watchdog timer that either initiates
a reboot automatically or signals a remote control site if
not reset periodically by the software. It is desirable
that the boot data involved reside at an Internet host
(e.g., the NOC host) and be transmitted via the net;
however, the use of local devices at the gateway site is
acceptable.
C. Control -- Configuring the Gateway
Every gateway will have a number of configuration parameters
which must be set (see the next section for examples). It
must be possible to update the parameters without rebooting
the gateway; at worst, a restart may be required.
D. Monitoring -- Status and Performance
A mechanism must be provided for retrieving status and
statistical information from a gateway. A gateway must
supply such information in response to a polling message
from the NOC. In addition, it may be desirable to configure
a gateway to transmit status spontaneously and periodically
to a NOC (or set of NOCs), for recording and display.
Examples of interesting status information include: link
status, queue lengths, buffer availability, CPU and memory
utilization, the routing data-base, error counts, and packet
counts. Counts should be kept for dropped datagrams,
separated by reason. Counts of ICMP datagrams should be
kept by type and categorized into those originating at the
gateway, and those destined for the gateway. It would be
useful to maintain many of these statistics by network
interface, by source/destination network pair, and/or by
source/destination host pair.
Note that a great deal of useful monitoring data is often to
be found in the routing data-base. It is therefore useful
to be able to tap into this data-base from the NOC.
E. Monitoring -- Error Logging
A gateway should be capable of asynchronously sending
exception ("trap") reports to one or more specified Internet
addresses, one of which will presumably be the NOC host.
RFC1009 - Requirements for Internet Gateways June 1987
There must also be a mechanism to limit the frequency of
such trap reports, and the parameters controlling this
frequency must be settable in the gateway configuration.
Examples of conditions which should result in traps include:
datagrams discarded because of TTL expiration (an indicator
of possible routing loops); resource shortages; or an
interface changing its up/down status.
5.4. Gateway Configuration Parameters
Every gateway will have a set of configuration parameters
controlling its operation. It must be possible to set these
parameters remotely from the NOC or locally at any time, without
taking the gateway down.
The following is a partial but representative list of possible
configuration parameters for a full-function gateway. The items
marked with "(i)" should be settable independently for each
network interface.
* (i) IP (sub-) network address
* (i) Subnet address mask
* (i) MTU of local network
* (i) Hardware interface address
* (i) Broadcast compatibility option (0s or 1s)
* EGP parameters -- neighbors, Autonomous System number,
and polling parameters
* Static and/or default routes, if any
* Enable/Disable Proxy ARP
* Source Quench parameters
* Address filter configuration
* Boot-host address
* IP address of time server host
* IP address(es) of logging host(s)
RFC1009 - Requirements for Internet Gateways June 1987
* IP address(es) of hosts to receive traps
* IP address(es) of hosts authorized to issue control
commands
* Error level for logging
* Maximum trap frequency
* Hold-down period (if any)
RFC1009 - Requirements for Internet Gateways June 1987
Appendix A. Technical Details
This Appendix collects a number of technical details and rules
concerning datagram forwarding by gateways and datagram handling by
hosts, especially in the presence of broadcasting and subnets.
A.1. Rules for Broadcasting
The following rules define how to handle broadcasts of packets and
datagrams [50]:
a. Hosts (which do not contain embedded gateways) must NEVER
forward any datagrams received from a connected network,
broadcast or not.
When a host receives an IP datagram, if the destination
address identifies the host or is an IP broadcast address,
the host passes the datagram to its appropriate
higher-level protocol module (possibly sending ICMP
protocol unreachable, but not if the IP address was a
broadcast address). Any other IP datagram must simply be
discarded, without an ICMP error message. Hosts never send
redirects.
b. All packets containing IP datagrams which are sent to the
local-network packet broadcast address must contain an IP
broadcast address as the destination address in their IP
header. Expressed in another way, a gateway (or host) must
not send in a local-network broadcast packet an IP datagram
that has a specific IP host address as its destination
field.
c. A gateway must never forward an IP datagram that arrives
addressed to the IP limited broadcast address {-1,-1}.
Furthermore, it must must not send an ICMP error message
about discarding such a datagram.
d. A gateway must not forward an IP datagram addressed to
network zero, i.e., {0, *}.
e. A gateway may forward a directed broadcast datagram, i.e.,
a datagram with the IP destination address:
{ <Network-number>, -1}.
However, it must not send such a directed broadcast out the
same interface it came in, if this interface has
<Network-number> as its network number. If the code in the
RFC1009 - Requirements for Internet Gateways June 1987
gateway making this decision does not know what interface
the directed-broadcast datagram arrived on, the gateway
cannot support directed broadcast to this connected network
at all.
f. A gateway is permitted to protect its connected networks by
discarding directed broadcast datagrams.
A gateway will broadcast an IP datagram on a connected network if
it is a directed broadcast destined for that network. Some
gateway-gateway routing protocols (e.g., RIP) also require
broadcasting routing updates on the connected networks. In either
case, the datagram must have an IP broadcast address as its
destination.
Note: as observed earlier, some host implementations (those
based on Berkeley 4.2BSD) use zero rather than -1 in the host
field. To provide compatibility during the period until these
systems are fixed or retired, it may be useful for a gateway to
be configurable to send either choice of IP broadcast address
and accept both if received.
A.2. ICMP Redirects
A gateway will generate an ICMP Redirect if and only if the
destination IP address is reachable from the gateway (as
determined by the routing algorithm) and the next-hop gateway is
on the same (sub-)network as the source host. Redirects must not
be sent in response to an IP network or subnet broadcast address
or in response to a Class D or Class E IP address.
A host must discard an ICMP Redirect if the destination IP address
is not its own IP address, or the new target address is not on the
same (sub-)network. An accepted Redirect updates the routing
data-base for the old target address. If there is no route
associated with the old target address, the Redirect is ignored.
If the old route is associated with a default gateway, a new route
associated with the new target address is inserted in the
data-base.
RFC1009 - Requirements for Internet Gateways June 1987
Appendix B. NSFNET Specific Requirements
The following sections discuss certain issues of special concern to
the NSF scientific networking community. These issues have primary
relevance in the policy area, but also have ramifications in the
technical area.
B.1. Proprietary and Extensibility Issues
Although hosts, gateways and networks supporting Internet
technology have been in continuous operation for several years,
vendors users and operators must understand that not all
networking issues are fully resolved. As a result, when new needs
or better solutions are developed for use in the NSF networking
community, it may be necessary to field new protocols or augment
existing ones. Normally, these new protocols will be designed to
interoperate in all practical respects with existing protocols;
however, occasionally it may happen that existing systems must be
upgraded to support these new or augmented protocols.
NSF systems procurements may favor those vendors who undertake a
commitment to remain aware of current Internet technology and be
prepared to upgrade their products from time to time as
appropriate. As a result, vendors are strongly urged to consider
extensibility and periodic upgrades as fundamental characteristics