RFC1812 - Requirements for IP Version 4 Routers(4)
For example, if a packet's IP Destination Address is
10.144.2.5 and there are network prefixes 10.144.1.0/24,
10.144.2.0/24, and 10.144.3.0/24, this rule would keep only
10.144.2.0/24; it is the only route whose prefix has the same
value as the corresponding bits in the IP Destination Address
of the packet.
(2) Longest Match
Longest Match is a refinement of Basic Match, described
above. After performing Basic Match pruning, the algorithm
examines the remaining routes to determine which among them
have the largest route.length values. All except these are
discarded.
For example, if a packet's IP Destination Address is
10.144.2.5 and there are network prefixes 10.144.2.0/24,
10.144.0.0/16, and 10.0.0.0/8, then this rule would keep only
the first (10.144.2.0/24) because its prefix length is
longest.
(3) Weak TOS
Each route has a type of service attribute, called route.tos,
whose possible values are assumed to be identical to those
used in the TOS field of the IP header. Routing protocols
that distribute TOS information fill in route.tos
appropriately in routes they add to the FIB; routes from
other routing protocols are treated as if they have the
default TOS (0000). The TOS field in the IP header of the
packet being routed is called ip.tos.
The set of candidate routes is examined to determine if it
contains any routes for which route.tos = ip.tos. If so, all
routes except those for which route.tos = ip.tos are
discarded. If not, all routes except those for which
route.tos = 0000 are discarded from the set of candidate
routes.
Additional discussion of routing based on Weak TOS may be
found in [ROUTE:11].
DISCUSSION
The effect of this rule is to select only those routes that have a
TOS that matches the TOS requested in the packet. If no such
routes exist then routes with the default TOS are considered.
Routes with a non-default TOS that is not the TOS requested in the
packet are never used, even if such routes are the only available
routes that go to the packet's destination.
(4) Best Metric
Each route has a metric attribute, called route.metric, and a
routing domain identifier, called route.domain. Each member
of the set of candidate routes is compared with each other
member of the set. If route.domain is equal for the two
routes and route.metric is strictly inferior for one when
compared with the other, then the one with the inferior metric
is discarded from the set. The determination of inferior is
usually by a simple arithmetic comparison, though some
protocols may have structured metrics requiring more complex
comparisons.
(5) Vendor Policy
Vendor Policy is sort of a catch-all to make up for the fact
that the previously listed rules are often inadequate to
choose from the possible routes. Vendor Policy pruning rules
are extremely vendor-specific. See section [5.2.4.4].
This algorithm has two distinct disadvantages. Presumably, a
router implementor might develop techniques to deal with these
disadvantages and make them a part of the Vendor Policy pruning
rule.
(1) IS-IS and OSPF route classes are not directly handled.
(2) Path properties other than type of service (e.g., MTU) are
ignored.
It is also worth noting a deficiency in the way that TOS is
supported: routing protocols that support TOS are implicitly
preferred when forwarding packets that have non-zero TOS values.
The Basic Match and Longest Match pruning rules generalize the
treatment of a number of particular types of routes. These routes
are selected in the following, decreasing, order of preference:
(1) Host Route: This is a route to a specific end system.
(2) Hierarchical Network Prefix Routes: This is a route to a
particular network prefix. Note that the FIB may contain
several routes to network prefixes that subsume each other
(one prefix is the other prefix with additional bits). These
are selected in order of decreasing prefix length.
(5) Default Route: This is a route to all networks for which there
are no explicit routes. It is by definition the route whose
prefix length is zero.
If, after application of the pruning rules, the set of routes is
empty (i.e., no routes were found), the packet MUST be discarded
and an appropriate ICMP error generated (ICMP Bad Source Route if
the IP Destination Address came from a source route option;
otherwise, whichever of ICMP Destination Host Unreachable or
Destination Network Unreachable is appropriate, as described in
Section [4.3.3.1]).
5.2.4.4 Administrative Preference
One suggested mechanism for the Vendor Policy Pruning Rule is to
use administrative preference, which is a simple prioritization
algorithm. The idea is to manually prioritize the routes that one
might need to select among.
Each route has associated with it a preference value, based on
various attributes of the route (specific mechanisms for assignment
of preference values are suggested below). This preference value
is an integer in the range [0..255], with zero being the most
preferred and 254 being the least preferred. 255 is a special
value that means that the route should never be used. The first
step in the Vendor Policy pruning rule discards all but the most
preferable routes (and always discards routes whose preference
value is 255).
This policy is not safe in that it can easily be misused to create
routing loops. Since no protocol ensures that the preferences
configured for a router is consistent with the preferences
configured in its neighbors, network managers must exercise care in
configuring preferences.
o Address Match
It is useful to be able to assign a single preference value to
all routes (learned from the same routing domain) to any of a
specified set of destinations, where the set of destinations is
all destinations that match a specified network prefix.
o Route Class
For routing protocols which maintain the distinction, it is
useful to be able to assign a single preference value to all
routes (learned from the same routing domain) which have a
particular route class (intra-area, inter-area, external with
internal metrics, or external with external metrics).
o Interface
It is useful to be able to assign a single preference value to
all routes (learned from a particular routing domain) that would
cause packets to be routed out a particular logical interface on
the router (logical interfaces generally map one-to-one onto the
router's network interfaces, except that any network interface
that has multiple IP addresses will have multiple logical
interfaces associated with it).
o Source router
It is useful to be able to assign a single preference value to
all routes (learned from the same routing domain) that were
learned from any of a set of routers, where the set of routers
are those whose updates have a source address that match a
specified network prefix.
o Originating AS
For routing protocols which provide the information, it is
useful to be able to assign a single preference value to all
routes (learned from a particular routing domain) which
originated in another particular routing domain. For BGP
routes, the originating AS is the first AS listed in the route's
AS_PATH attribute. For OSPF external routes, the originating AS
may be considered to be the low order 16 bits of the route's
external route tag if the tag's Automatic bit is set and the
tag's Path Length is not equal to 3.
o External route tag
It is useful to be able to assign a single preference value to
all OSPF external routes (learned from the same routing domain)
whose external route tags match any of a list of specified
values. Because the external route tag may contain a structured
value, it may be useful to provide the ability to match
particular subfields of the tag.
o AS path
It may be useful to be able to assign a single preference value
to all BGP routes (learned from the same routing domain) whose
AS path "matches" any of a set of specified values. It is not
yet clear exactly what kinds of matches are most useful. A
simple option would be to allow matching of all routes for which
a particular AS number appears (or alternatively, does not
appear) anywhere in the route's AS_PATH attribute. A more
general but somewhat more difficult alternative would be to
allow matching all routes for which the AS path matches a
specified regular expression.
5.2.4.5 Load Splitting
At the end of the Next-hop selection process, multiple routes may
still remain. A router has several options when this occurs. It
may arbitrarily discard some of the routes. It may reduce the
number of candidate routes by comparing metrics of routes from
routing domains that are not considered equivalent. It may retain
more than one route and employ a load-splitting mechanism to divide
traffic among them. Perhaps the only thing that can be said about
the relative merits of the options is that load-splitting is useful
in some situations but not in others, so a wise implementor who
implements load-splitting will also provide a way for the network
manager to disable it.
5.2.5 Unused IP Header Bits: RFC-791 Section 3.1
The IP header contains several reserved bits, in the Type of
Service field and in the Flags field. Routers MUST NOT drop
packets merely because one or more of these reserved bits has a
non-zero value.
Routers MUST ignore and MUST pass through unchanged the values of
these reserved bits. If a router fragments a packet, it MUST copy
these bits into each fragment.
DISCUSSION
Future revisions to the IP protocol may make use of these unused
bits. These rules are intended to ensure that these revisions can
be deployed without having to simultaneously upgrade all routers
in the Internet.
5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2
As was discussed in Section [4.2.2.7], a router MUST support IP
fragmentation.
A router MUST NOT reassemble any datagram before forwarding it.
DISCUSSION
A few people have suggested that there might be some topologies
where reassembly of transit datagrams by routers might improve
performance. The fact that fragments may take different paths to
the destination precludes safe use of such a feature.
Nothing in this section should be construed to control or limit
fragmentation or reassembly performed as a link layer function by
the router.
Similarly, if an IP datagram is encapsulated in another IP
datagram (e.g., it is tunnelled), that datagram is in turn
fragmented, the fragments must be reassembled in order to forward
the original datagram. This section does not preclude this.
5.2.7 Internet Control Message Protocol - ICMP
General requirements for ICMP were discussed in Section [4.3]. This
section discusses ICMP messages that are sent only by routers.
5.2.7.1 Destination Unreachable
The ICMP Destination Unreachable message is sent by a router in
response to a packet which it cannot forward because the destination
(or next hop) is unreachable or a service is unavailable. Examples
of such cases include a message addressed to a host which is not
there and therefore does not respond to ARP requests, and messages
addressed to network prefixes for which the router has no valid
route.
A router MUST be able to generate ICMP Destination Unreachable
messages and SHOULD choose a response code that most closely matches
the reason the message is being generated.
The following codes are defined in [INTERNET:8] and [INTRO:2]:
0 = Network Unreachable - generated by a router if a forwarding path
(route) to the destination network is not available;
1 = Host Unreachable - generated by a router if a forwarding path
(route) to the destination host on a directly connected network
is not available (does not respond to ARP);
2 = Protocol Unreachable - generated if the transport protocol
designated in a datagram is not supported in the transport layer
of the final destination;
3 = Port Unreachable - generated if the designated transport protocol
(e.g., UDP) is unable to demultiplex the datagram in the
transport layer of the final destination but has no protocol
mechanism to inform the sender;
4 = Fragmentation Needed and DF Set - generated if a router needs to
fragment a datagram but cannot since the DF flag is set;
5 = Source Route Failed - generated if a router cannot forward a
packet to the next hop in a source route option;
6 = Destination Network Unknown - This code SHOULD NOT be generated
since it would imply on the part of the router that the
destination network does not exist (net unreachable code 0
SHOULD be used in place of code 6);
7 = Destination Host Unknown - generated only when a router can
determine (from link layer advice) that the destination host
does not exist;
11 = Network Unreachable For Type Of Service - generated by a router
if a forwarding path (route) to the destination network with the
requested or default TOS is not available;
12 = Host Unreachable For Type Of Service - generated if a router
cannot forward a packet because its route(s) to the destination
do not match either the TOS requested in the datagram or the
default TOS (0).
The following additional codes are hereby defined:
13 = Communication Administratively Prohibited - generated if a
router cannot forward a packet due to administrative filtering;
14 = Host Precedence Violation. Sent by the first hop router to a
host to indicate that a requested precedence is not permitted
for the particular combination of source/destination host or
network, upper layer protocol, and source/destination port;
15 = Precedence cutoff in effect. The network operators have imposed
a minimum level of precedence required for operation, the
datagram was sent with a precedence below this level;
NOTE: [INTRO:2] defined Code 8 for source host isolated. Routers
SHOULD NOT generate Code 8; whichever of Codes 0 (Network
Unreachable) and 1 (Host Unreachable) is appropriate SHOULD be used
instead. [INTRO:2] also defined Code 9 for communication with
destination network administratively prohibited and Code 10 for
communication with destination host administratively prohibited.
These codes were intended for use by end-to-end encryption devices
used by U.S military agencies. Routers SHOULD use the newly defined
Code 13 (Communication Administratively Prohibited) if they
administratively filter packets.
Routers MAY have a configuration option that causes Code 13
(Communication Administratively Prohibited) messages not to be
generated. When this option is enabled, no ICMP error message is
sent in response to a packet that is dropped because its forwarding
is administratively prohibited.
Similarly, routers MAY have a configuration option that causes Code
14 (Host Precedence Violation) and Code 15 (Precedence Cutoff in
Effect) messages not to be generated. When this option is enabled,
no ICMP error message is sent in response to a packet that is dropped
because of a precedence violation.
Routers MUST use Host Unreachable or Destination Host Unknown codes
whenever other hosts on the same destination network might be
reachable; otherwise, the source host may erroneously conclude that
all hosts on the network are unreachable, and that may not be the
case.
[INTERNET:14] describes a slight modification the form of Destination
Unreachable messages containing Code 4 (Fragmentation needed and DF
set). A router MUST use this modified form when originating Code 4
Destination Unreachable messages.
5.2.7.2 Redirect
The ICMP Redirect message is generated to inform a local host the it
should use a different next hop router for a certain class of
traffic.
Routers MUST NOT generate the Redirect for Network or Redirect for
Network and Type of Service messages (Codes 0 and 2) specified in
[INTERNET:8]. Routers MUST be able to generate the Redirect for Host
message (Code 1) and SHOULD be able to generate the Redirect for Type
of Service and Host message (Code 3) specified in [INTERNET:8].
DISCUSSION
If the directly connected network is not subnetted (in the
classical sense), a router can normally generate a network
Redirect that applies to all hosts on a specified remote network.
Using a network rather than a host Redirect may economize slightly
on network traffic and on host routing table storage. However,
the savings are not significant, and subnets create an ambiguity
about the subnet mask to be used to interpret a network Redirect.
In a CIDR environment, it is difficult to specify precisely the
cases in which network Redirects can be used. Therefore, routers
must send only host (or host and type of service) Redirects.
A Code 3 (Redirect for Host and Type of Service) message is generated
when the packet provoking the redirect has a destination for which
the path chosen by the router would depend (in part) on the TOS
requested.
Routers that can generate Code 3 redirects (Host and Type of Service)
MUST have a configuration option (which defaults to on) to enable
Code 1 (Host) redirects to be substituted for Code 3 redirects. A
router MUST send a Code 1 Redirect in place of a Code 3 Redirect if
it has been configured to do so.
If a router is not able to generate Code 3 Redirects then it MUST
generate Code 1 Redirects in situations where a Code 3 Redirect is
called for.
Routers MUST NOT generate a Redirect Message unless all the following
conditions are met:
o The packet is being forwarded out the same physical interface that
it was received from,
o The IP source address in the packet is on the same Logical IP
(sub)network as the next-hop IP address, and
o The packet does not contain an IP source route option.
The source address used in the ICMP Redirect MUST belong to the same
logical (sub)net as the destination address.
A router using a routing protocol (other than static routes) MUST NOT
consider paths learned from ICMP Redirects when forwarding a packet.
If a router is not using a routing protocol, a router MAY have a
configuration that, if set, allows the router to consider routes
learned through ICMP Redirects when forwarding packets.
DISCUSSION
ICMP Redirect is a mechanism for routers to convey routing
information to hosts. Routers use other mechanisms to learn
routing information, and therefore have no reason to obey
redirects. Believing a redirect which contradicted the router's
other information would likely create routing loops.
On the other hand, when a router is not acting as a router, it
MUST comply with the behavior required of a host.
5.2.7.3 Time Exceeded
A router MUST generate a Time Exceeded message Code 0 (In Transit)
when it discards a packet due to an expired TTL field. A router MAY
have a per-interface option to disable origination of these messages
on that interface, but that option MUST default to allowing the
messages to be originated.
5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP
IGMP [INTERNET:4] is a protocol used between hosts and multicast
routers on a single physical network to establish hosts' membership
in particular multicast groups. Multicast routers use this
information, in conjunction with a multicast routing protocol, to
support IP multicast forwarding across the Internet.
A router SHOULD implement the multicast router part of IGMP.
5.3 SPECIFIC ISSUES
5.3.1 Time to Live (TTL)
The Time-to-Live (TTL) field of the IP header is defined to be a
timer limiting the lifetime of a datagram. It is an 8-bit field and
the units are seconds. Each router (or other module) that handles a
packet MUST 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 is effectively a hop count limit on how far a datagram can
propagate through the Internet.
When a router forwards a packet, it MUST reduce the TTL by at least
one. If it holds a packet for more than one second, it MAY decrement
the TTL by one for each second.
If the TTL is reduced to zero (or less), the packet MUST be
discarded, and if the destination is not a multicast address the
router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded
in Transit) message to the source. Note that a router MUST NOT
discard an IP unicast or broadcast packet with a non-zero TTL merely
because it can predict that another router on the path to the
packet's final destination will decrement the TTL to zero. However,
a router MAY do so for IP multicasts, in order to more efficiently
implement IP multicast's expanding ring search algorithm (see
[INTERNET:4]).
DISCUSSION
The IP TTL is used, somewhat schizophrenically, as both a hop
count limit and a time limit. Its hop count function is critical
to ensuring that routing problems can't melt down the network by
causing packets to loop infinitely in the network. The time limit
function is used by transport protocols such as TCP to ensure
reliable data transfer. Many current implementations treat TTL as
a pure hop count, and in parts of the Internet community there is
a strong sentiment that the time limit function should instead be
performed by the transport protocols that need it.
In this specification, we have reluctantly decided to follow the
strong belief among the router vendors that the time limit
function should be optional. They argued that implementation of
the time limit function is difficult enough that it is currently
not generally done. They further pointed to the lack of
documented cases where this shortcut has caused TCP to corrupt
data (of course, we would expect the problems created to be rare
and difficult to reproduce, so the lack of documented cases
provides little reassurance that there haven't been a number of
undocumented cases).
IP multicast notions such as the expanding ring search may not
work as expected unless the TTL is treated as a pure hop count.
The same thing is somewhat true of traceroute.
ICMP Time Exceeded messages are required because the traceroute
diagnostic tool depends on them.
Thus, the tradeoff is between severely crippling, if not
eliminating, two very useful tools and avoiding a very rare and
transient data transport problem that may not occur at all. We
have chosen to preserve the tools.
5.3.2 Type of Service (TOS)
The Type-of-Service byte in the IP header is divided into three
sections: the Precedence field (high-order 3 bits), a field that
is customarily called Type of Service or "TOS (next 4 bits), and a
reserved bit (the low order bit). Rules governing the reserved
bit were described in Section [4.2.2.3]. The Precedence field
will be discussed in Section [5.3.3]. A more extensive discussion
of the TOS field and its use can be found in [ROUTE:11].
A router SHOULD consider the TOS field in a packet's IP header
when deciding how to forward it. The remainder of this section
describes the rules that apply to routers that conform to this
requirement.
A router MUST maintain a TOS value for each route in its routing
table. Routes learned through a routing protocol that does not
support TOS MUST be assigned a TOS of zero (the default TOS).
To choose a route to a destination, a router MUST use an algorithm
equivalent to the following:
(1) The router locates in its routing table all available routes
to the destination (see Section [5.2.4]).
(2) If there are none, the router drops the packet because the
destination is unreachable. See section [5.2.4].
(3) If one or more of those routes have a TOS that exactly matches
the TOS specified in the packet, the router chooses the route
with the best metric.
(4) Otherwise, the router repeats the above step, except looking
at routes whose TOS is zero.
(5) If no route was chosen above, the router drops the packet
because the destination is unreachable. The router returns
an ICMP Destination Unreachable error specifying the
appropriate code: either Network Unreachable with Type of
Service (code 11) or Host Unreachable with Type of Service
(code 12).
DISCUSSION
Although TOS has been little used in the past, its use by hosts is
now mandated by the Requirements for Internet Hosts RFCs
([INTRO:2] and [INTRO:3]). Support for TOS in routers may become
a MUST in the future, but is a SHOULD for now until we get more
experience with it and can better judge both its benefits and its
costs.
Various people have proposed that TOS should affect other aspects
of the forwarding function. For example:
(1) A router could place packets that have the Low Delay bit set
ahead of other packets in its output queues.
(2) a router is forced to discard packets, it could try to avoid
discarding those which have the High Reliability bit set.
These ideas have been explored in more detail in [INTERNET:17] but
we don't yet have enough experience with such schemes to make
requirements in this area.
5.3.3 IP Precedence
This section specifies requirements and guidelines for appropriate
processing of the IP Precedence field in routers. Precedence is a
scheme for allocating resources in the network based on the
relative importance of different traffic flows. The IP
specification defines specific values to be used in this field for
various types of traffic.
The basic mechanisms for precedence processing in a router are
preferential resource allocation, including both precedence-
ordered queue service and precedence-based congestion control, and
selection of Link Layer priority features. The router also
selects the IP precedence for routing, management and control
traffic it originates. For a more extensive discussion of IP
Precedence and its implementation see [FORWARD:6].
Precedence-ordered queue service, as discussed in this section,
includes but is not limited to the queue for the forwarding
process and queues for outgoing links. It is intended that a
router supporting precedence should also use the precedence
indication at whatever points in its processing are concerned with
allocation of finite resources, such as packet buffers or Link
Layer connections. The set of such points is implementation-
dependent.
DISCUSSION
Although the Precedence field was originally provided for use in
DOD systems where large traffic surges or major damage to the
network are viewed as inherent threats, it has useful applications
for many non-military IP networks. Although the traffic handling
capacity of networks has grown greatly in recent years, the
traffic generating ability of the users has also grown, and
network overload conditions still occur at times. Since IP-based
routing and management protocols have become more critical to the
successful operation of the Internet, overloads present two
additional risks to the network:
(1) High delays may result in routing protocol packets being lost.
This may cause the routing protocol to falsely deduce a
topology change and propagate this false information to other
routers. Not only can this cause routes to oscillate, but an
extra processing burden may be placed on other routers.
(2) High delays may interfere with the use of network management
tools to analyze and perhaps correct or relieve the problem
in the network that caused the overload condition to occur.
Implementation and appropriate use of the Precedence mechanism
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.