alleviates both of these problems.
5.3.3.1 Precedence-Ordered Queue Service
Routers SHOULD implement precedence-ordered queue service.
Precedence-ordered queue service means that when a packet is selected
for output on a (logical) link, the packet of highest precedence that
has been queued for that link is sent. Routers that implement
precedence-ordered queue service MUST also have a configuration
option to suppress precedence-ordered queue service in the Internet
Layer.
Any router MAY implement other policy-based throughput management
procedures that result in other than strict precedence ordering, but
it MUST be configurable to suppress them (i.e., use strict ordering).
As detailed in Section [5.3.6], routers that implement precedence-
ordered queue service discard low precedence packets before
discarding high precedence packets for congestion control purposes.
Preemption (interruption of processing or transmission of a packet)
is not envisioned as a function of the Internet Layer. Some
protocols at other layers may provide preemption features.
5.3.3.2 Lower Layer Precedence Mappings
Routers that implement precedence-ordered queuing MUST IMPLEMENT, and
other routers SHOULD IMPLEMENT, Lower Layer Precedence Mapping.
A router that implements Lower Layer Precedence Mapping:
o MUST be able to map IP Precedence to Link Layer priority mechanisms
for link layers that have such a feature defined.
o MUST have a configuration option to select the Link Layer's default
priority treatment for all IP traffic
o SHOULD be able to configure specific nonstandard mappings of IP
precedence values to Link Layer priority values for each
interface.
DISCUSSION
Some research questions the workability of the priority features
of some Link Layer protocols, and some networks may have faulty
implementations of the link layer priority mechanism. It seems
prudent to provide an escape mechanism in case such problems show
up in a network.
On the other hand, there are proposals to use novel queuing
strategies to implement special services such as multimedia
bandwidth reservation or low-delay service. Special services and
queuing strategies to support them are current research subjects
and are in the process of standardization.
Implementors may wish to consider that correct link layer mapping
of IP precedence is required by DOD policy for TCP/IP systems used
on DOD networks. Since these requirements are intended to
encourage (but not force) the use of precedence features in the
hope of providing better Internet service to all users, routers
supporting precedence-ordered queue service should default to
maintaining strict precedence ordering regardless of the type of
service requested.
5.3.3.3 Precedence Handling For All Routers
A router (whether or not it employs precedence-ordered queue
service):
(1) MUST accept and process incoming traffic of all precedence levels
normally, unless it has been administratively configured to do
otherwise.
(2) MAY implement a validation filter to administratively restrict
the use of precedence levels by particular traffic sources. If
provided, this filter MUST NOT filter out or cut off the
following sorts of ICMP error messages: Destination Unreachable,
Redirect, Time Exceeded, and Parameter Problem. If this filter
is provided, the procedures required for packet filtering by
addresses are required for this filter also.
DISCUSSION
Precedence filtering should be applicable to specific
source/destination IP Address pairs, specific protocols, specific
ports, and so on.
An ICMP Destination Unreachable message with code 14 SHOULD be sent
when a packet is dropped by the validation filter, unless this has
been suppressed by configuration choice.
(3) MAY implement a cutoff function that allows the router to be set
to refuse or drop traffic with precedence below a specified
level. This function may be activated by management actions or
by some implementation dependent heuristics, but there MUST be a
configuration option to disable any heuristic mechanism that
operates without human intervention. An ICMP Destination
Unreachable message with code 15 SHOULD be sent when a packet is
dropped by the cutoff function, unless this has been suppressed
by configuration choice.
A router MUST NOT refuse to forward datagrams with IP precedence
of 6 (Internetwork Control) or 7 (Network Control) solely due to
precedence cutoff. However, other criteria may be used in
conjunction with precedence cutoff to filter high precedence
traffic.
DISCUSSION
Unrestricted precedence cutoff could result in an unintentional
cutoff of routing and control traffic. In the general case, host
traffic should be restricted to a value of 5 (CRITIC/ECP) or
below; this is not a requirement and may not be correct in certain
systems.
(4) MUST NOT change precedence settings on packets it did not
originate.
(5) SHOULD be able to configure distinct precedence values to be used
for each routing or management protocol supported (except for
those protocols, such as OSPF, which specify which precedence
value must be used).
(6) MAY be able to configure routing or management traffic precedence
values independently for each peer address.
(7) MUST respond appropriately to Link Layer precedence-related error
indications where provided. An ICMP Destination Unreachable
message with code 15 SHOULD be sent when a packet is dropped
because a link cannot accept it due to a precedence-related
condition, unless this has been suppressed by configuration
choice.
DISCUSSION
The precedence cutoff mechanism described in (3) is somewhat
controversial. Depending on the topological location of the area
affected by the cutoff, transit traffic may be directed by routing
protocols into the area of the cutoff, where it will be dropped.
This is only a problem if another path that is unaffected by the
cutoff exists between the communicating points. Proposed ways of
avoiding this problem include providing some minimum bandwidth to
all precedence levels even under overload conditions, or
propagating cutoff information in routing protocols. In the
absence of a widely accepted (and implemented) solution to this
problem, great caution is recommended in activating cutoff
mechanisms in transit networks.
A transport layer relay could legitimately provide the function
prohibited by (4) above. Changing precedence levels may cause
subtle interactions with TCP and perhaps other protocols; a
correct design is a non-trivial task.
The intent of (5) and (6) (and the discussion of IP Precedence in
ICMP messages in Section [4.3.2]) is that the IP precedence bits
should be appropriately set, whether or not this router acts upon
those bits in any other way. We expect that in the future
specifications for routing protocols and network management
protocols will specify how the IP Precedence should be set for
messages sent by those protocols.
The appropriate response for (7) depends on the link layer
protocol in use. Typically, the router should stop trying to send
offensive traffic to that destination for some period of time, and
should return an ICMP Destination Unreachable message with code 15
(service not available for precedence requested) to the traffic
source. It also should not try to reestablish a preempted Link
Layer connection for some time.
5.3.4 Forwarding of Link Layer Broadcasts
The encapsulation of IP packets in most Link Layer protocols (except
PPP) allows a receiver to distinguish broadcasts and multicasts from
unicasts simply by examining the Link Layer protocol headers (most
commonly, the Link Layer destination address). The rules in this
section that refer to Link Layer broadcasts apply only to Link Layer
protocols that allow broadcasts to be distinguished; likewise, the
rules that refer to Link Layer multicasts apply only to Link Layer
protocols that allow multicasts to be distinguished.
A router MUST NOT forward any packet that the router received as a
Link Layer broadcast, unless it is directed to an IP Multicast
address. In this latter case, one would presume that link layer
broadcast was used due to the lack of an effective multicast service.
A router MUST NOT forward any packet which the router received as a
Link Layer multicast unless the packet's destination address is an IP
multicast address.
A router SHOULD silently discard a packet that is received via a Link
Layer broadcast but does not specify an IP multicast or IP broadcast
destination address.
When a router sends a packet as a Link Layer broadcast, the IP
destination address MUST be a legal IP broadcast or IP multicast
address.
5.3.5 Forwarding of Internet Layer Broadcasts
There are two major types of IP broadcast addresses; limited
broadcast and directed broadcast. In addition, there are three
subtypes of directed broadcast: a broadcast directed to a specified
network prefix, a broadcast directed to a specified subnetwork, and a
broadcast directed to all subnets of a specified network.
Classification by a router of a broadcast into one of these
categories depends on the broadcast address and on the router's
understanding (if any) of the subnet structure of the destination
network. The same broadcast will be classified differently by
different routers.
A limited IP broadcast address is defined to be all-ones: { -1, -1 }
or 255.255.255.255.
A network-prefix-directed broadcast is composed of the network prefix
of the IP address with a local part of all-ones or { <Network-
prefix>, -1 }. For example, a Class A net broadcast address is
net.255.255.255, a Class B net broadcast address is net.net.255.255
and a Class C net broadcast address is net.net.net.255 where net is a
byte of the network address.
The all-subnets-directed-broadcast is not well defined in a CIDR
environment, and was deprecated in version 1 of this memo.
As was described in Section [4.2.3.1], a router may encounter certain
non-standard IP broadcast addresses:
o 0.0.0.0 is an obsolete form of the limited broadcast address
o { <Network-prefix>, 0 } is an obsolete form of a network-prefix-
directed broadcast address.
As was described in that section, packets addressed to any of these
addresses SHOULD be silently discarded, but if they are not, they
MUST be treated according to the same rules that apply to packets
addressed to the non-obsolete forms of the broadcast addresses
described above. These rules are described in the next few sections.
5.3.5.1 Limited Broadcasts
Limited broadcasts MUST NOT be forwarded. Limited broadcasts MUST
NOT be discarded. Limited broadcasts MAY be sent and SHOULD be sent
instead of directed broadcasts where limited broadcasts will suffice.
DISCUSSION
Some routers contain UDP servers which function by resending the
requests (as unicasts or directed broadcasts) to other servers.
This requirement should not be interpreted as prohibiting such
servers. Note, however, that such servers can easily cause packet
looping if misconfigured. Thus, providers of such servers would
probably be well advised to document their setup carefully and to
consider carefully the TTL on packets that are sent.
5.3.5.2 Directed Broadcasts
A router MUST classify as network-prefix-directed broadcasts all
valid, directed broadcasts destined for a remote network or an
attached nonsubnetted network. Note that in view of CIDR, such
appear to be host addresses within the network prefix; we preclude
inspection of the host part of such network prefixes. Given a route
and no overriding policy, then, a router MUST forward network-
prefix-directed broadcasts. Network-Prefix-Directed broadcasts MAY
be sent.
A router MAY have an option to disable receiving network-prefix-
directed broadcasts on an interface and MUST have an option to
disable forwarding network-prefix-directed broadcasts. These options
MUST default to permit receiving and forwarding network-prefix-
directed broadcasts.
DISCUSSION
There has been some debate about forwarding or not forwarding
directed broadcasts. In this memo we have made the forwarding
decision depend on the router's knowledge of the destination
network prefix. Routers cannot determine that a message is
unicast or directed broadcast apart from this knowledge. The
decision to forward or not forward the message is by definition
only possible in the last hop router.
5.3.5.3 All-subnets-directed Broadcasts
The first version of this memo described an algorithm for
distributing a directed broadcast to all the subnets of a classical
network number. This algorithm was stated to be "broken," and
certain failure cases were specified.
In a CIDR routing domain, wherein classical IP network numbers are
meaningless, the concept of an all-subnets-directed-broadcast is also
meaningless. To the knowledge of the working group, the facility was
never implemented or deployed, and is now relegated to the dustbin of
history.
5.3.5.4 Subnet-directed Broadcasts
The first version of this memo spelled out procedures for dealing
with subnet-directed-broadcasts. In a CIDR routing domain, these are
indistinguishable from net-drected-broadcasts. The two are therefore
treated together in section [5.3.5.2 Directed Broadcasts], and should
be viewed as network-prefix directed broadcasts.
5.3.6 Congestion Control
Congestion in a network is loosely defined as a condition where
demand for resources (usually bandwidth or CPU time) exceeds
capacity. Congestion avoidance tries to prevent demand from
exceeding capacity, while congestion recovery tries to restore an
operative state. It is possible for a router to contribute to both
of these mechanisms. A great deal of effort has been spent studying
the problem. The reader is encouraged to read [FORWARD:2] for a
survey of the work. Important papers on the subject include
[FORWARD:3], [FORWARD:4], [FORWARD:5], [FORWARD:10], [FORWARD:11],
[FORWARD:12], [FORWARD:13], [FORWARD:14], and [INTERNET:10], among
others.
The amount of storage that router should have available to handle
peak instantaneous demand when hosts use reasonable congestion
policies, such as described in [FORWARD:5], is a function of the
product of the bandwidth of the link times the path delay of the
flows using the link, and therefore storage should increase as this
Bandwidth*Delay product increases. The exact function relating
storage capacity to probability of discard is not known.
When a router receives a packet beyond its storage capacity it must
(by definition, not by decree) discard it or some other packet or
packets. Which packet to discard is the subject of much study but,
unfortunately, little agreement so far. The best wisdom to date
suggests discarding a packet from the data stream most heavily using
the link. However, a number of additional factors may be relevant,
including the precedence of the traffic, active bandwidth
reservation, and the complexity associated with selecting that
packet.
A router MAY discard the packet it has just received; this is the
simplest but not the best policy. Ideally, the router should select
a packet from one of the sessions most heavily abusing the link,
given that the applicable Quality of Service policy permits this. A
recommended policy in datagram environments using FIFO queues is to
discard a packet randomly selected from the queue (see [FORWARD:5]).
An equivalent algorithm in routers using fair queues is to discard
from the longest queue or that using the greatest virtual time (see
[FORWARD:13]). A router MAY use these algorithms to determine which
packet to discard.
If a router implements a discard policy (such as Random Drop) under
which it chooses a packet to discard from a pool of eligible packets:
o If precedence-ordered queue service (described in Section
[5.3.3.1]) is implemented and enabled, the router MUST NOT discard
a packet whose IP precedence is higher than that of a packet that
is not discarded.
o A router MAY protect packets whose IP headers request the maximize
reliability TOS, except where doing so would be in violation of
the previous rule.
o A router MAY protect fragmented IP packets, on the theory that
dropping a fragment of a datagram may increase congestion by
causing all fragments of the datagram to be retransmitted by the
source.
o To help prevent routing perturbations or disruption of management
functions, the router MAY protect packets used for routing
control, link control, or network management from being discarded.
Dedicated routers (i.e., routers that are not also general purpose
hosts, terminal servers, etc.) can achieve an approximation of
this rule by protecting packets whose source or destination is the
router itself.
Advanced methods of congestion control include a notion of fairness,
so that the 'user' that is penalized by losing a packet is the one
that contributed the most to the congestion. No matter what
mechanism is implemented to deal with bandwidth congestion control,
it is important that the CPU effort expended be sufficiently small
that the router is not driven into CPU congestion also.
As described in Section [4.3.3.3], this document recommends that a
router SHOULD NOT send a Source Quench to the sender of the packet
that it is discarding. ICMP Source Quench is a very weak mechanism,
so it is not necessary for a router to send it, and host software
should not use it exclusively as an indicator of congestion.
5.3.7 Martian Address Filtering
An IP source address is invalid if it is a special IP address, as
defined in 4.2.2.11 or 5.3.7, or is not a unicast address.
An IP destination address is invalid if it is among those defined as
illegal destinations in 4.2.3.1, or is a Class E address (except
255.255.255.255).
A router SHOULD NOT forward any packet that has an invalid IP source
address or a source address on network 0. A router SHOULD NOT
forward, except over a loopback interface, any packet that has a
source address on network 127. A router MAY have a switch that
allows the network manager to disable these checks. If such a switch
is provided, it MUST default to performing the checks.
A router SHOULD NOT forward any packet that has an invalid IP
destination address or a destination address on network 0. A router
SHOULD NOT forward, except over a loopback interface, any packet that
has a destination address on network 127. A router MAY have a switch
that allows the network manager to disable these checks. If such a
switch is provided, it MUST default to performing the checks.
If a router discards a packet because of these rules, it SHOULD log
at least the IP source address, the IP destination address, and, if
the problem was with the source address, the physical interface on
which the packet was received and the Link Layer address of the host
or router from which the packet was received.
5.3.8 Source Address Validation
A router SHOULD IMPLEMENT the ability to filter traffic based on a
comparison of the source address of a packet and the forwarding table
for a logical interface on which the packet was received. If this
filtering is enabled, the router MUST silently discard a packet if
the interface on which the packet was received is not the interface
on which a packet would be forwarded to reach the address contained
in the source address. In simpler terms, if a router wouldn't route
a packet containing this address through a particular interface, it
shouldn't believe the address if it appears as a source address in a
packet read from this interface.
If this feature is implemented, it MUST be disabled by default.
DISCUSSION
This feature can provide useful security improvements in some
situations, but can erroneously discard valid packets in
situations where paths are asymmetric.
5.3.9 Packet Filtering and Access Lists
As a means of providing security and/or limiting traffic through
portions of a network a router SHOULD provide the ability to
selectively forward (or filter) packets. If this capability is
provided, filtering of packets SHOULD be configurable either to
forward all packets or to selectively forward them based upon the
source and destination prefixes, and MAY filter on other message
attributes. Each source and destination address SHOULD allow
specification of an arbitrary prefix length.
DISCUSSION
This feature can provide a measure of privacy, where systems
outside a boundary are not permitted to exchange certain protocols
with systems inside the boundary, or are limited as to which
systems they may communicate with. It can also help prevent
certain classes of security breach, wherein a system outside a
boundary masquerades as a system inside the boundary and mimics a
session with it.
If supported, a router SHOULD be configurable to allow one of an
o Include list - specification of a list of message definitions to be
forwarded, or an
o Exclude list - specification of a list of message definitions NOT
to be forwarded.
A "message definition", in this context, specifies the source and
destination network prefix, and may include other identifying
information such as IP Protocol Type or TCP port number.
A router MAY provide a configuration switch that allows a choice
between specifying an include or an exclude list, or other equivalent
controls.
A value matching any address (e.g., a keyword any, an address with a
mask of all 0's, or a network prefix whose length is zero) MUST be
allowed as a source and/or destination address.
In addition to address pairs, the router MAY allow any combination of
transport and/or application protocol and source and destination
ports to be specified.
The router MUST allow packets to be silently discarded (i.e.,
discarded without an ICMP error message being sent).
The router SHOULD allow an appropriate ICMP unreachable message to be
sent when a packet is discarded. The ICMP message SHOULD specify
Communication Administratively Prohibited (code 13) as the reason for
the destination being unreachable.
The router SHOULD allow the sending of ICMP destination unreachable
messages (code 13) to be configured for each combination of address
pairs, protocol types, and ports it allows to be specified.
The router SHOULD count and SHOULD allow selective logging of packets
not forwarded.
5.3.10 Multicast Routing
An IP router SHOULD support forwarding of IP multicast packets, based
either on static multicast routes or on routes dynamically determined
by a multicast routing protocol (e.g., DVMRP [ROUTE:9]). A router
that forwards IP multicast packets is called a multicast router.
5.3.11 Controls on Forwarding
For each physical interface, a router SHOULD have a configuration
option that specifies whether forwarding is enabled on that
interface. When forwarding on an interface is disabled, the router:
o MUST silently discard any packets which are received on that
interface but are not addressed to the router
o MUST NOT send packets out that interface, except for datagrams
originated by the router
o MUST NOT announce via any routing protocols the availability of
paths through the interface
DISCUSSION
This feature allows the network manager to essentially turn off an
interface but leaves it accessible for network management.
Ideally, this control would apply to logical rather than physical
interfaces. It cannot, because there is no known way for a router
to determine which logical interface a packet arrived absent a
one-to-one correspondence between logical and physical interfaces.
5.3.12 State Changes
During router operation, interfaces may fail or be manually disabled,
or may become available for use by the router. Similarly, forwarding
may be disabled for a particular interface or for the entire router
or may be (re)enabled. While such transitions are (usually)
uncommon, it is important that routers handle them correctly.
5.3.12.1 When a Router Ceases Forwarding
When a router ceases forwarding it MUST stop advertising all routes,
except for third party routes. It MAY continue to receive and use
routes from other routers in its routing domains. If the forwarding
database is retained, the router MUST NOT cease timing the routes in
the forwarding database. If routes that have been received from
other routers are remembered, the router MUST NOT cease timing the
routes that it has remembered. It MUST discard any routes whose
timers expire while forwarding is disabled, just as it would do if
forwarding were enabled.
DISCUSSION
When a router ceases forwarding, it essentially ceases being a
router. It is still a host, and must follow all of the
requirements of Host Requirements [INTRO:2]. The router may still
be a passive member of one or more routing domains, however. As
such, it is allowed to maintain its forwarding database by
listening to other routers in its routing domain. It may not,
however, advertise any of the routes in its forwarding database,
since it itself is doing no forwarding. The only exception to
this rule is when the router is advertising a route that uses only
some other router, but which this router has been asked to
advertise.
A router MAY send ICMP destination unreachable (host unreachable)
messages to the senders of packets that it is unable to forward. It
SHOULD NOT send ICMP redirect messages.
DISCUSSION
Note that sending an ICMP destination unreachable (host
unreachable) is a router action. This message should not be sent
by hosts. This exception to the rules for hosts is allowed so
that packets may be rerouted in the shortest possible time, and so
that black holes are avoided.
5.3.12.2 When a Router Starts Forwarding
When a router begins forwarding, it SHOULD expedite the sending of
new routing information to all routers with which it normally
exchanges routing information.
5.3.12.3 When an Interface Fails or is Disabled
If an interface fails or is disabled a router MUST remove and stop
advertising all routes in its forwarding database that make use of
that interface. It MUST disable all static routes that make use of
that interface. If other routes to the same destination and TOS are
learned or remembered by the router, the router MUST choose the best
alternate, and add it to its forwarding database. The router SHOULD
send ICMP destination unreachable or ICMP redirect messages, as
appropriate, in reply to all packets that it is unable to forward due
to the interface being unavailable.
5.3.12.4 When an Interface is Enabled
If an interface that had not been available becomes available, a
router MUST reenable any static routes that use that interface. If
routes that would use that interface are learned by the router, then
these routes MUST be evaluated along with all the other learned
routes, and the router MUST make a decision as to which routes should
be placed in the forwarding database. The implementor is referred to
Chapter [7], Application Layer - Routing Protocols for further
information on how this decision is made.
A router SHOULD expedite the sending of new routing information to
all routers with which it normally exchanges routing information.
5.3.13 IP Options
Several options, such as Record Route and Timestamp, contain slots
into which a router inserts its address when forwarding the packet.
However, each such option has a finite number of slots, and therefore
a router may find that there is not free slot into which it can
insert its address. No requirement listed below should be construed
as requiring a router to insert its address into an option that has
no remaining slot to insert it into. Section [5.2.5] discusses how a
router must choose which of its addresses to insert into an option.
5.3.13.1 Unrecognized Options Unrecognized IP options in forwarded
packets MUST be passed through unchanged.
5.3.13.2 Security Option
Some environments require the Security option in every packet; such a
requirement is outside the scope of this document and the IP standard
specification. Note, however, that the security options described in
[INTERNET:1] and [INTERNET:16] are obsolete. Routers SHOULD
IMPLEMENT the revised security option described in [INTERNET:5].
DISCUSSION
Routers intended for use in networks with multiple security levels
should support packet filtering based on IPSO (RFC-1108) labels.
To implement this support, the router would need to permit the
router administrator to configure both a lower sensitivity limit
(e.g. Unclassified) and an upper sensitivity limit (e.g. Secret)
on each interface. It is commonly but not always the case that
the two limits are the same (e.g. a single-level interface).
Packets caught by an IPSO filter as being out of range should be
silently dropped and a counter should note the number of packets
dropped because of out of range IPSO labels.
5.3.13.3 Stream Identifier Option
This option is obsolete. If the Stream Identifier option is present
in a packet forwarded by the router, the option MUST be ignored and
passed through unchanged.
5.3.13.4 Source Route Options
A router MUST implement support for source route options in forwarded
packets. A router MAY implement a configuration option that, when
enabled, causes all source-routed packets to be discarded. However,
such an option MUST NOT be enabled by default.
DISCUSSION
The ability to source route datagrams through the Internet is
important to various network diagnostic tools. However, source
routing may be used to bypass administrative and security controls
within a network. Specifically, those cases where manipulation of
routing tables is used to provide administrative separation in
lieu of other methods such as packet filtering may be vulnerable
through source routed packets.
EDITORS+COMMENTS
Packet filtering can be defeated by source routing as well, if it
is applied in any router except one on the final leg of the source
routed path. Neither route nor packet filters constitute a
complete solution for security.
5.3.13.5 Record Route Option
Routers MUST support the Record Route option in forwarded packets.
A router MAY provide a configuration option that, if enabled, will
cause the router to ignore (i.e., pass through unchanged) Record
Route options in forwarded packets. If provided, such an option MUST
default to enabling the record-route. This option should not affect
the processing of Record Route options in datagrams received by the
router itself (in particular, Record Route options in ICMP echo
requests will still be processed according to Section [4.3.3.6]).
DISCUSSION
There are some people who believe that Record Route is a security
problem because it discloses information about the topology of the
network. Thus, this document allows it to be disabled.
5.3.13.6 Timestamp Option
Routers MUST support the timestamp option in forwarded packets. A
timestamp value MUST follow the rules given [INTRO:2].
If the flags field = 3 (timestamp and prespecified address), the
router MUST add its timestamp if the next prespecified address
matches any of the router's IP addresses. It is not necessary that
the prespecified address be either the address of the interface on
which the packet arrived or the address of the interface over which
it will be sent.
IMPLEMENTATION
To maximize the utility of the timestamps contained in the
timestamp option, it is suggested that the timestamp inserted be,
as nearly as practical, the time at which the packet arrived at
the router. For datagrams originated by the router, the timestamp
inserted should be, as nearly as practical, the time at which the
datagram was passed to the network layer for transmission.
A router MAY provide a configuration option which, if enabled, will
cause the router to ignore (i.e., pass through unchanged) Timestamp
options in forwarded datagrams when the flag word is set to zero
(timestamps only) or one (timestamp and registering IP address). If
provided, such an option MUST default to off (that is, the router
does not ignore the timestamp). This option should not affect the
processing of Timestamp options in datagrams received by the router
itself (in particular, a router will insert timestamps into Timestamp
options in datagrams received by the router, and Timestamp options in
ICMP echo requests will still be processed according to Section
[4.3.3.6]).
DISCUSSION
Like the Record Route option, the Timestamp option can reveal
information about a network's topology. Some people consider this
to be a security concern.
6. TRANSPORT LAYER
A router is not required to implement any Transport Layer protocols
except those required to support Application Layer protocols
supported by the router. In practice, this means that most routers
implement both the Transmission Control Protocol (TCP) and the User
Datagram Protocol (UDP).
6.1 USER DATAGRAM PROTOCOL - UDP
The User Datagram Protocol (UDP) is specified in [TRANS:1].
A router that implements UDP MUST be compliant, and SHOULD be
unconditionally compliant, with the requirements of [INTRO:2], except
that:
o This specification does not specify the interfaces between the
various protocol layers. Thus, a router's interfaces need not
comply with [INTRO:2], except where compliance is required for
proper functioning of Application Layer protocols supported by the
router.
o Contrary to [INTRO:2], an application SHOULD NOT disable generation
of UDP checksums.
DISCUSSION
Although a particular application protocol may require that UDP
datagrams it receives must contain a UDP checksum, there is no
general requirement that received UDP datagrams contain UDP
checksums. Of course, if a UDP checksum is present in a received
datagram, the checksum must be verified and the datagram discarded
if the checksum is incorrect.
6.2 TRANSMISSION CONTROL PROTOCOL - TCP
The Transmission Control Protocol (TCP) is specified in [TRANS:2].
A router that implements TCP MUST be compliant, and SHOULD be
unconditionally compliant, with the requirements of [INTRO:2], except
that:
o This specification does not specify the interfaces between the
various protocol layers. Thus, a router need not comply with the
following requirements of [INTRO:2] (except of course where
compliance is required for proper functioning of Application Layer
protocols supported by the router):
Use of Push: RFC-793 Section 2.8:
Passing a received PSH flag to the application layer is now
OPTIONAL.
Urgent Pointer: RFC-793 Section 3.1:
A TCP MUST inform the application layer asynchronously
whenever it receives an Urgent pointer and there was
previously no pending urgent data, or whenever the Urgent
pointer advances in the data stream. There MUST be a way for
the application to learn how much urgent data remains to be
read from the connection, or at least to determine whether or
not more urgent data remains to be read.
TCP Connection Failures:
An application MUST be able to set the value for R2 for a
particular connection. For example, an interactive
application might set R2 to ``infinity,'' giving the user
control over when to disconnect.
TCP Multihoming:
If an application on a multihomed host does not specify the
local IP address when actively opening a TCP connection, then
the TCP MUST ask the IP layer to select a local IP address
before sending the (first) SYN. See the function
GET_SRCADDR() in Section 3.4.
IP Options:
An application MUST be able to specify a source route when it
actively opens a TCP connection, and this MUST take
precedence over a source route received in a datagram.
o For similar reasons, a router need not comply with any of the
requirements of [INTRO:2].
o The requirements concerning the Maximum Segment Size Option in
[INTRO:2] are amended as follows: a router that implements the
host portion of MTU discovery (discussed in Section [4.2.3.3] of
this memo) uses 536 as the default value of SendMSS only if the
path MTU is unknown; if the path MTU is known, the default value
for SendMSS is the path MTU - 40.
o The requirements concerning the Maximum Segment Size Option in
[INTRO:2] are amended as follows: ICMP Destination Unreachable
codes 11 and 12 are additional soft error conditions. Therefore,
these message MUST NOT cause TCP to abort a connection.
DISCUSSION
It should particularly be noted that a TCP implementation in a
router must conform to the following requirements of [INTRO:2]:
o Providing a configurable TTL. [Time to Live: RFC-793 Section
3.9]
o Providing an interface to configure keep-alive behavior, if
keep-alives are used at all. [TCP Keep-Alives]
o Providing an error reporting mechanism, and the ability to
manage it. [Asynchronous Reports]
o Specifying type of service. [Type-of-Service]
The general paradigm applied is that if a particular interface is
visible outside the router, then all requirements for the
interface must be followed. For example, if a router provides a
telnet function, then it will be generating traffic, likely to be
routed in the external networks. Therefore, it must be able to
set the type of service correctly or else the telnet traffic may
not get through.
7. APPLICATION LAYER - ROUTING PROTOCOLS
7.1 INTRODUCTION
For technical, managerial, and sometimes political reasons, the
Internet routing system consists of two components - interior routing
and exterior routing. The concept of an Autonomous System (AS), as
define in Section 2.2.4 of this document, plays a key role in
separating interior from an exterior routing, as this concept allows
to deliniate the set of routers where a change from interior to
exterior routing occurs. An IP datagram may have to traverse the
routers of two or more Autonomous Systems to reach its destination,
and the Autonomous Systems must provide each other with topology
information to allow such forwarding. Interior gateway protocols
(IGPs) are used to distribute routing information within an AS (i.e.,
intra-AS routing). Exterior gateway protocols are used to exchange
routing information among ASs (i.e., inter-AS routing).
7.1.1 Routing Security Considerations
Routing is one of the few places where the Robustness Principle (be
liberal in what you accept) does not apply. Routers should be
relatively suspicious in accepting routing data from other routing
systems.
A router SHOULD provide the ability to rank routing information
sources from most trustworthy to least trustworthy and to accept
routing information about any particular destination from the most
trustworthy sources first. This was implicit in the original
core/stub autonomous system routing model using EGP and various
interior routing protocols. It is even more important with the
demise of a central, trusted core.
A router SHOULD provide a mechanism to filter out obviously invalid
routes (such as those for net 127).
Routers MUST NOT by default redistribute routing data they do not
themselves use, trust or otherwise consider valid. In rare cases, it
may be necessary to redistribute suspicious information, but this
should only happen under direct intercession by some human agency.
Routers must be at least a little paranoid about accepting routing
data from anyone, and must be especially careful when they distribute
routing information provided to them by another party. See below for
specific guidelines.
7.1.2 Precedence
Except where the specification for a particular routing protocol
specifies otherwise, a router SHOULD set the IP Precedence value for
IP datagrams carrying routing traffic it originates to 6
(INTERNETWORK CONTROL).
DISCUSSION
Routing traffic with VERY FEW exceptions should be the highest
precedence traffic on any network. If a system's routing traffic
can't get through, chances are nothing else will.
7.1.3 Message Validation
Peer-to-peer authentication involves several tests. The application
of message passwords and explicit acceptable neighbor lists has in
the past improved the robustness of the route database. Routers
SHOULD IMPLEMENT management controls that enable explicit listing of
valid routing neighbors. Routers SHOULD IMPLEMENT peer-to-peer
authentication for those routing protocols that support them.
Routers SHOULD validate routing neighbors based on their source
address and the interface a message is received on; neighbors in a
directly attached subnet SHOULD be restricted to communicate with the
router via the interface that subnet is posited on or via unnumbered
interfaces. Messages received on other interfaces SHOULD be silently
discarded.
DISCUSSION
Security breaches and numerous routing problems are avoided by
this basic testing.
7.2 INTERIOR GATEWAY PROTOCOLS
7.2.1 INTRODUCTION
An Interior Gateway Protocol (IGP) is used to distribute routing
information between the various routers in a particular AS.
Independent of the algorithm used to implement a particular IGP, it
should perform the following functions:
(1) Respond quickly to changes in the internal topology of an AS
(2) Provide a mechanism such that circuit flapping does not cause
continuous routing updates
(3) Provide quick convergence to loop-free routing
(4) Utilize minimal bandwidth
(5) Provide equal cost routes to enable load-splitting
(6) Provide a means for authentication of routing updates
Current IGPs used in the internet today are characterized as either
being based on a distance-vector or a link-state algorithm.
Several IGPs are detailed in this section, including those most
commonly used and some recently developed protocols that may be
widely used in the future. Numerous other protocols intended for use
in intra-AS routing exist in the Internet community.
A router that implements any routing protocol (other than static
routes) MUST IMPLEMENT OSPF (see Section [7.2.2]). A router MAY
implement additional IGPs.
7.2.2 OPEN SHORTEST PATH FIRST - OSPF
Shortest Path First (SPF) based routing protocols are a class of
link-state algorithms that are based on the shortest-path algorithm
of Dijkstra. Although SPF based algorithms have been around since
the inception of the ARPANET, it is only recently that they have
achieved popularity both inside both the IP and the OSI communities.
In an SPF based system, each router obtains the entire topology
database through a process known as flooding. Flooding insures a
reliable transfer of the information. Each router then runs the SPF
algorithm on its database to build the IP routing table. The OSPF
routing protocol is an implementation of an SPF algorithm. The
current version, OSPF version 2, is specified in [ROUTE:1]. Note
that RFC-1131, which describes OSPF version 1, is obsolete.
Note that to comply with Section [8.3] of this memo, a router that
implements OSPF MUST implement the OSPF MIB [MGT:14].
7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS-IS
The American National Standards Institute (ANSI) X3S3.3 committee has
defined an intra-domain routing protocol. This protocol is titled
Intermediate System to Intermediate System Routeing Exchange
Protocol.
Its application to an IP network has been defined in [ROUTE:2], and
is referred to as Dual IS-IS (or sometimes as Integrated IS-IS).
IS-IS is based on a link-state (SPF) routing algorithm and shares all
the advantages for this class of protocols.
7.3 EXTERIOR GATEWAY PROTOCOLS
7.3.1 INTRODUCTION
Exterior Gateway Protocols are utilized for inter-Autonomous System
routing to exchange reachability information for a set of networks
internal to a particular autonomous system to a neighboring
autonomous system.
The area of inter-AS routing is a current topic of research inside
the Internet Engineering Task Force. The Exterior Gateway Protocol
(EGP) described in Section [Appendix F.1] has traditionally been the
inter-AS protocol of choice, but is now historical. The Border
Gateway Protocol (BGP) eliminates many of the restrictions and
limitations of EGP, and is therefore growing rapidly in popularity.
A router is not required to implement any inter-AS routing protocol.
However, if a router does implement EGP it also MUST IMPLEMENT BGP.
Although it was not designed as an exterior gateway protocol, RIP
(described in Section [7.2.4]) is sometimes used for inter-AS
routing.
7.3.2 BORDER GATEWAY PROTOCOL - BGP
7.3.2.1 Introduction
The Border Gateway Protocol (BGP-4) is an inter-AS routing protocol
that exchanges network reachability information with other BGP
speakers. The information for a network includes the complete list
of ASs that traffic must transit to reach that network. This
information can then be used to insure loop-free paths. This
information is sufficient to construct a graph of AS connectivity
from which routing loops may be pruned and some policy decisions at
the AS level may be enforced.
BGP is defined by [ROUTE:4]. [ROUTE:5] specifies the proper usage of
BGP in the Internet, and provides some useful implementation hints
and guidelines. [ROUTE:12] and [ROUTE:13] provide additional useful
information.
To comply with Section [8.3] of this memo, a router that implements
BGP is required to implement the BGP MIB [MGT:15].
To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that an AS advertises to its
neighbor ASs only those routes that it itself uses. This rule
reflects the hop-by-hop routing paradigm generally used throughout
the current Internet. Note that some policies cannot be supported by
the hop-by-hop routing paradigm and thus require techniques such as
source routing to enforce. For example, BGP does not enable one AS
to send traffic to a neighbor AS intending that traffic take a
different route from that taken by traffic originating in the
neighbor AS. On the other hand, BGP can support any policy
conforming to the hop-by-hop routing paradigm.
Implementors of BGP are strongly encouraged to follow the
recommendations outlined in Section 6 of [ROUTE:5].
7.3.2.2 Protocol Walk-through
While BGP provides support for quite complex routing policies (as an
example see Section 4.2 in [ROUTE:5]), it is not required for all BGP
implementors to support such policies. At a minimum, however, a BGP
implementation:
(1) SHOULD allow an AS to control announcements of the BGP learned
routes to adjacent AS's. Implementations SHOULD support such
control with at least the granularity of a single network.
Implementations SHOULD also support such control with the
granularity of an autonomous system, where the autonomous system
may be either the autonomous system that originated the route,
or the autonomous system that advertised the route to the local
system (adjacent autonomous system).
(2) SHOULD allow an AS to prefer a particular path to a destination
(when more than one path is available). Such function SHOULD be
implemented by allowing system administrator to assign weights
to Autonomous Systems, and making route selection process to
select a route with the lowest weight (where weight of a route
is defined as a sum of weights of all AS's in the AS_PATH path
attribute associated with that route).
(3) SHOULD allow an AS to ignore routes with certain AS's in the