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].
A more extensive discussion of the TOS field and its use can be
found in [ROUTE:11].
The description of the IP Precedence field is superseded by
Section [5.3.3]. RFC-795, Service Mappings, is obsolete and
SHOULD NOT be implemented.
4.2.2.5 Header Checksum: RFC-791 Section 3.1
As stated in Section [5.2.2], a router MUST verify the IP
checksum of any packet which is received. The router MUST NOT
provide a means to disable this checksum verification.
IMPLEMENTATION:
A more extensive description of the IP checksum, including
extensive implementation hints, can be found in [INTERNET:6]
and [INTERNET:7].
4.2.2.6 Unrecognized Header Options: RFC-791 Section 3.1
A router MUST ignore IP options which it does not recognize. A
corollary of this requirement is that a router MUST implement
the End of Option List option and the No Operation option,
since neither contains an explicit length.
DISCUSSION:
All future IP options will include an explicit length.
4.2.2.7 Fragmentation: RFC-791 Section 3.2
Fragmentation, as described in [INTERNET:1], MUST be supported
by a router.
When a router fragments an IP datagram, it SHOULD minimize the
number of fragments. When a router fragments an IP datagram,
it MUST send the fragments in order. A fragmentation method
which may generate one IP fragment which is significantly
smaller than the other MAY cause the first IP fragment to be
the smaller one.
DISCUSSION:
There are several fragmentation techniques in common use in
the Internet. One involves splitting the IP datagram into
IP fragments with the first being MTU sized, and the others
being approximately the same size, smaller than the MTU.
The reason for this is twofold. The first IP fragment in
the sequence will be the effective MTU of the current path
between the hosts, and the following IP fragments are sized
to hopefully minimize the further fragmentation of the IP
datagram. Another technique is to split the IP datagram
into MTU sized IP fragments, with the last fragment being
the only one smaller, as per page 26 of [INTERNET:1].
A common trick used by some implementations of TCP/IP is to
fragment an IP datagram into IP fragments that are no larger
than 576 bytes when the IP datagram is to travel through a
router. In general, this allows the resulting IP fragments
to pass the rest of the path without further fragmentation.
This would, though, create more of a load on the destination
host, since it would have a larger number of IP fragments to
reassemble into one IP datagram. It would also not be
efficient on networks where the MTU only changes once, and
stays much larger than 576 bytes (such as an 802.5 network
with a MTU of 2048 or an Ethernet network with an MTU of
1536).
One other fragmentation technique discussed was splitting
the IP datagram into approximately equal sized IP fragments,
with the size being smaller than the next hop network's MTU.
This is intended to minimize the number of fragments that
would result from additional fragmentation further down the
path.
In most cases, routers should try and create situations that
will generate the lowest number of IP fragments possible.
Work with slow machines leads us to believe that if it is
necessary to send small packets in a fragmentation scheme,
sending the small IP fragment first maximizes the chance of
a host with a slow interface of receiving all the fragments.
4.2.2.8 Reassembly: RFC-791 Section 3.2
As specified in Section 3.3.2 of [INTRO:2], a router MUST
support reassembly of datagrams which it delivers to itself.
4.2.2.9 Time to Live: RFC-791 Section 3.2
Time to Live (TTL) handling for packets originated or received
by the router is governed by [INTRO:2]. Note in particular
that a router MUST NOT check the TTL of a packet except when
forwarding it.
4.2.2.10 Multi-subnet Broadcasts: RFC-922
All-subnets broadcasts (called multi-subnet broadcasts in
[INTERNET:3]) have been deprecated. See Section [5.3.5.3].
4.2.2.11 Addressing: RFC-791 Section 3.2
There are now five classes of IP addresses: Class A through
Class E. Class D addresses are used for IP multicasting
[INTERNET:4], while Class E addresses are reserved for
experimental use.
A multicast (Class D) address is a 28-bit logical address that
stands for a group of hosts, and may be either permanent or
transient. Permanent multicast addresses are allocated by the
Internet Assigned Number Authority [INTRO:7], while transient
addresses may be allocated dynamically to transient groups.
Group membership is determined dynamically using IGMP
[INTERNET:4].
We now summarize the important special cases for Unicast (that
is class A, B, and C) IP addresses, using the following
notation for an IP address:
{ <Network-number>, <Host-number> }
or
{ <Network-number>, <Subnet-number>, <Host-number> }
and the notation -1 for a field that contains all 1 bits and
the notation 0 for a field that contains all 0 bits. This
notation is not intended to imply that the 1-bits in a subnet
mask need be contiguous.
(a) { 0, 0 }
This host on this network. It MUST NOT be used as a
source address by routers, except the router MAY use this
as a source address as part of an initialization procedure
(e.g., if the router is using BOOTP to load its
configuration information).
Incoming datagrams with a source address of { 0, 0 } which
are received for local delivery (see Section [5.2.3]),
MUST be accepted if the router implements the associated
protocol and that protocol clearly defines appropriate
action to be taken. Otherwise, a router MUST silently
discard any locally-delivered datagram whose source
address is { 0, 0 }.
DISCUSSION:
Some protocols define specific actions to take in
response to a received datagram whose source address is
{ 0, 0 }. Two examples are BOOTP and ICMP Mask
Request. The proper operation of these protocols often
depends on the ability to receive datagrams whose
source address is { 0, 0 }. For most protocols,
however, it is best to ignore datagrams having a source
address of { 0, 0 } since they were probably generated
by a misconfigured host or router. Thus, if a router
knows how to deal with a given datagram having a { 0, 0
} source address, the router MUST accept it.
Otherwise, the router MUST discard it.
See also Section [4.2.3.1] for a non-standard use of { 0,
0 }.
(b) { 0, <Host-number> }
Specified host on this network. It MUST NOT be sent by
routers except that the router MAY uses this as a source
address as part of an initialization procedure by which
the it learns its own IP address.
(c) { -1, -1 }
Limited broadcast. It MUST NOT be used as a source
address.
A datagram with this destination address will be received
by every host and router on the connected physical
network, but will not be forwarded outside that network.
(d) { <Network-number>, -1 }
Network Directed Broadcast - a broadcast directed to the
specified network. It MUST NOT be used as a source
address. A router MAY originate Network Directed
Broadcast packets. A router MUST receive Network Directed
Broadcast packets; however a router MAY have a
configuration option to prevent reception of these
packets. Such an option MUST default to allowing
reception.
(e) { <Network-number>, <Subnet-number>, -1 }
Subnetwork Directed Broadcast - a broadcast sent to the
specified subnet. It MUST NOT be used as a source
address. A router MAY originate Network Directed
Broadcast packets. A router MUST receive Network Directed
Broadcast packets; however a router MAY have a
configuration option to prevent reception of these
packets. Such an option MUST default to allowing
reception.
(f) { <Network-number>, -1, -1 }
All Subnets Directed Broadcast - a broadcast sent to all
subnets of the specified subnetted network. It MUST NOT
be used as a source address. A router MAY originate
Network Directed Broadcast packets. A router MUST receive
Network Directed Broadcast packets; however a router MAY
have a configuration option to prevent reception of these
packets. Such an option MUST default to allowing
reception.
(g) { 127, <any> }
Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.
The <Network-number> is administratively assigned so that its
value will be unique in the entire world.
IP addresses are not permitted to have the value 0 or -1 for
any of the <Host-number>, <Network-number>, or <Subnet-number>
fields (except in the special cases listed above). This
implies that each of these fields will be at least two bits
long.
For further discussion of broadcast addresses, see Section
[4.2.3.1].
Since (as described in Section [4.2.1]) a router must support
the subnet extensions to IP, there will be a subnet mask of the
form: { -1, -1, 0 } associated with each of the host's local IP
addresses; see Sections [4.3.3.9], [5.2.4.2], and [10.2.2].
When a router originates any datagram, the IP source address
MUST be one of its own IP addresses (but not a broadcast or
multicast address). The only exception is during
initialization.
For most purposes, a datagram addressed to a broadcast or
multicast destination is processed as if it had been addressed
to one of the router's IP addresses; that is to say:
o A router MUST receive and process normally any packets with
a broadcast destination address.
o A router MUST receive and process normally any packets sent
to a multicast destination address which the router is
interested in.
The term specific-destination address means the equivalent
local IP address of the host. The specific-destination address
is defined to be the destination address in the IP header
unless the header contains a broadcast or multicast address, in
which case the specific-destination is an IP address assigned
to the physical interface on which the datagram arrived.
A router MUST silently discard any received datagram containing
an IP source address that is invalid by the rules of this
section. This validation could be done either by the IP layer
or by each protocol in the transport layer.
DISCUSSION:
A misaddressed datagram might be caused by a Link Layer
broadcast of a unicast datagram or by another router or host
that is confused or misconfigured.
4.2.3 SPECIFIC ISSUES
4.2.3.1 IP Broadcast Addresses
For historical reasons, there are a number of IP addresses
(some standard and some not) which are used to indicate that an
IP packet is an IP broadcast. A router
(1) MUST treat as IP broadcasts packets addressed to
255.255.255.255, { <Network-number>, -1 }, { <Network-
number>, <Subnet-number>, -1 }, and { <Network-number>,
-1, -1 }.
(2) SHOULD silently discard on receipt (i.e., don't even
deliver to applications in the router) any packet
addressed to 0.0.0.0, { <Network-number>, 0 }, {
<Network-number>, <Subnet-number>, 0 }, or { <Network-
number>, 0, 0 }; if these packets are not silently
discarded, they MUST be treated as IP broadcasts (see
Section [5.3.5]). There MAY be a configuration option to
allow receipt of these packets. This option SHOULD
default to discarding them.
(3) SHOULD (by default) use the limited broadcast address
(255.255.255.255) when originating an IP broadcast
destined for a connected network or subnet (except when
sending an ICMP Address Mask Reply, as discussed in
Section [4.3.3.9]). A router MUST receive limited
broadcasts.
(4) SHOULD NOT originate datagrams addressed to 0.0.0.0, {
<Network-number>, 0 }, { <Network-number>, <Subnet-
number>, 0 }, or { <Network-number>, 0, 0 }. There MAY be
a configuration option to allow generation of these
packets (instead of using the relevant 1s format
broadcast). This option SHOULD default to not generating
them.
DISCUSSION:
In the second bullet, the router obviously cannot recognize
addresses of the form { <Network-number>, <Subnet-number>, 0
} if the router does not know how the particular network is
subnetted. In that case, the rules of the second bullet do
not apply because, from the point of view of the router, the
packet is not an IP broadcast packet.
4.2.3.2 IP Multicasting
An IP router SHOULD satisfy the Host Requirements with respect
to IP multicasting, as specified in Section 3.3.7 of [INTRO:2].
An IP router SHOULD support local IP multicasting on all
connected networks for which a mapping from Class D IP
addresses to link-layer addresses has been specified (see the
various IP-over-xxx specifications), and on all connected
point-to-point links. Support for local IP multicasting
includes originating multicast datagrams, joining multicast
groups and receiving multicast datagrams, and leaving multicast
groups. This implies support for all of [INTERNET:4] including
IGMP (see Section [4.4]).
DISCUSSION:
Although [INTERNET:4] is entitled Host Extensions for IP
Multicasting, it applies to all IP systems, both hosts and
routers. In particular, since routers may join multicast
groups, it is correct for them to perform the host part of
IGMP, reporting their group memberships to any multicast
routers that may be present on their attached networks
(whether or not they themselves are multicast routers).
Some router protocols may specifically require support for
IP multicasting (e.g., OSPF [ROUTE:1]), or may recommend it
(e.g., ICMP Router Discovery [INTERNET:13]).
4.2.3.3 Path MTU Discovery
In order to eliminate fragmentation or minimize it, it is
desirable to know what is the path MTU along the path from the
source to destination. The path MTU is the minimum of the MTUs
of each hop in the path. [INTERNET:14] describes a technique
for dynamically discovering the maximum transmission unit (MTU)
of an arbitrary internet path. For a path that passes through
a router that does not support [INTERNET:14], this technique
might not discover the correct Path MTU, but it will always
choose a Path MTU as accurate as, and in many cases more
accurate than, the Path MTU that would be chosen by older
techniques or the current practice.
When a router is originating an IP datagram, it SHOULD use the
scheme described in [INTERNET:14] to limit the datagram's size.
If the router's route to the datagram's destination was learned
from a routing protocol that provides Path MTU information, the
scheme described in [INTERNET:14] is still used, but the Path
MTU information from the routing protocol SHOULD be used as the
initial guess as to the Path MTU and also as an upper bound on
the Path MTU.
4.2.3.4 Subnetting
Under certain circumstances, it may be desirable to support
subnets of a particular network being interconnected only via a
path which is not part of the subnetted network. This is known
as discontiguous subnetwork support.
Routers MUST support discontiguous subnetworks.
IMPLEMENTATION:
In general, a router should not make assumptions about what
are subnets and what are not, but simply ignore the concept
of Class in networks, and treat each route as a { network,
mask }-tuple.
DISCUSSION:
The Internet has been growing at a tremendous rate of late.
This has been placing severe strains on the IP addressing
technology. A major factor in this strain is the strict IP
Address class boundaries. These make it difficult to
efficiently size network numbers to their networks and
aggregate several network numbers into a single route
advertisement. By eliminating the strict class boundaries
of the IP address and treating each route as a {network
number, mask}-tuple these strains may be greatly reduced.
The technology for currently doing this is Classless
Interdomain Routing (CIDR) [INTERNET:15].
Furthermore, for similar reasons, a subnetted network need not
have a consistent subnet mask through all parts of the network.
For example, one subnet may use an 8 bit subnet mask, another
10 bit, and another 6 bit. This is known as variable subnet-
masks.
Routers MUST support variable subnet-masks.
4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP
4.3.1 INTRODUCTION
ICMP is an auxiliary protocol, which provides routing, diagnostic
and and error functionality for IP. It is described in
[INTERNET:8]. A router MUST support ICMP.
ICMP messages are grouped in two classes which are discussed in
the following sections:
ICMP error messages:
Destination Unreachable Section 4.3.3.1
Redirect Section 4.3.3.2
Source Quench Section 4.3.3.3
Time Exceeded Section 4.3.3.4
Parameter Problem Section 4.3.3.5
ICMP query messages:
Echo Section 4.3.3.6
Information Section 4.3.3.7
Timestamp Section 4.3.3.8
Address Mask Section 4.3.3.9
Router Discovery Section 4.3.3.10
General ICMP requirements and discussion are in the next section.
4.3.2 GENERAL ISSUES
4.3.2.1 Unknown Message Types
If an ICMP message of unknown type is received, it MUST be
passed to the ICMP user interface (if the router has one) or
silently discarded (if the router doesn't have one).
4.3.2.2 ICMP Message TTL
When originating an ICMP message, the router MUST initialize
the TTL. The TTL for ICMP responses must not be taken from the
packet which triggered the response.
4.3.2.3 Original Message Header
Every ICMP error message includes the Internet header and at
least the first 8 data bytes of the datagram that triggered the
error. More than 8 bytes MAY be sent, but the resulting ICMP
datagram SHOULD have a length of less than or equal to 576
bytes. The returned IP header (and user data) MUST be
identical to that which was received, except that the router is
not required to undo any modifications to the IP header that
are normally performed in forwarding that were performed before
the error was detected (e.g., decrementing the TTL, updating
options). Note that the requirements of Section [4.3.3.5]
supersede this requirement in some cases (i.e., for a Parameter
Problem message, if the problem is in a modified field, the
router must undo the modification). See Section [4.3.3.5])
4.3.2.4 ICMP Message Source Address
Except where this document specifies otherwise, the IP source
address in an ICMP message originated by the router MUST be one
of the IP addresses associated with the physical interface over
which the ICMP message is transmitted. If the interface has no
IP addresses associated with it, the router's router-id (see
Section [5.2.5]) is used instead.
4.3.2.5 TOS and Precedence
ICMP error messages SHOULD have their TOS bits set to the same
value as the TOS bits in the packet which provoked the sending
of the ICMP error message, unless setting them to that value
would cause the ICMP error message to be immediately discarded
because it could not be routed to its destination. Otherwise,
ICMP error messages MUST be sent with a normal (i.e. zero) TOS.
An ICMP reply message SHOULD have its TOS bits set to the same
value as the TOS bits in the ICMP request that provoked the
reply.
EDITOR'S COMMENTS:
The following paragraph originally read:
ICMP error messages MUST have their IP Precedence field
set to the same value as the IP Precedence field in the
packet which provoked the sending of the ICMP error
message, except that the precedence value MUST be 6
(INTERNETWORK CONTROL) or 7 (NETWORK CONTROL), SHOULD be
7, and MAY be settable for the following types of ICMP
error messages: Unreachable, Redirect, Time Exceeded, and
Parameter Problem.
I believe that the following paragraph is equivalent and
easier for humans to parse (Source Quench is the only other
ICMP Error message). Other interpretations of the original
are sought.
ICMP Source Quench error messages MUST have their IP Precedence
field set to the same value as the IP Precedence field in the
packet which provoked the sending of the ICMP Source Quench
message. All other ICMP error messages (Destination
Unreachable, Redirect, Time Exceeded, and Parameter Problem)
MUST have their precedence value set to 6 (INTERNETWORK
CONTROL) or 7 (NETWORK CONTROL), SHOULD be 7. The IP
Precedence value for these error messages MAY be settable.
An ICMP reply message MUST have its IP Precedence field set to
the same value as the IP Precedence field in the ICMP request
that provoked the reply.
4.3.2.6 Source Route
If the packet which provokes the sending of an ICMP error
message contains a source route option, the ICMP error message
SHOULD also contain a source route option of the same type
(strict or loose), created by reversing the portion before the
pointer of the route recorded in the source route option of the
original packet UNLESS the ICMP error message is an ICMP
Parameter Problem complaining about a source route option in
the original packet.
DISCUSSION:
In environments which use the U.S. Department of Defense
security option (defined in [INTERNET:5]), ICMP messages may
need to include a security option. Detailed information on
this topic should be available from the Defense
Communications Agency.
4.3.2.7 When Not to Send ICMP Errors
An ICMP error message MUST NOT be sent as the result of
receiving:
o An ICMP error message, or
o A packet which fails the IP header validation tests
described in Section [5.2.2] (except where that section
specifically permits the sending of an ICMP error message),
or
o A packet destined to an IP broadcast or IP multicast
address, or
o A packet sent as a Link Layer broadcast or multicast, or
o A packet whose source address has a network number of zero
or is an invalid source address (as defined in Section
[5.3.7]), or
o Any fragment of a datagram other then the first fragment
(i.e., a packet for which the fragment offset in the IP
header is nonzero).
Furthermore, an ICMP error message MUST NOT be sent in any case
where this memo states that a packet is to be silently
discarded.
NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
DISCUSSION:
These rules aim to prevent the broadcast storms that have
resulted from routers or hosts returning ICMP error messages
in response to broadcast packets. For example, a broadcast
UDP packet to a non-existent port could trigger a flood of
ICMP Destination Unreachable datagrams from all devices that
do not have a client for that destination port. On a large
Ethernet, the resulting collisions can render the network
useless for a second or more.
Every packet that is broadcast on the connected network
should have a valid IP broadcast address as its IP
destination (see Section [5.3.4] and [INTRO:2]). However,
some devices violate this rule. To be certain to detect
broadcast packets, therefore, routers are required to check
for a link-layer broadcast as well as an IP-layer address.
IMPLEMENTATION:
This requires that the link layer inform the IP layer when a
link-layer broadcast packet has been received; see Section
[3.1].
4.3.2.8 Rate Limiting
A router which sends ICMP Source Quench messages MUST be able
to limit the rate at which the messages can be generated. A
router SHOULD also be able to limit the rate at which it sends
other sorts of ICMP error messages (Destination Unreachable,
Redirect, Time Exceeded, Parameter Problem). The rate limit
parameters SHOULD be settable as part of the configuration of
the router. How the limits are applied (e.g., per router or
per interface) is left to the implementor's discretion.
DISCUSSION:
Two problems for a router sending ICMP error message are:
(1) The consumption of bandwidth on the reverse path, and
(2) The use of router resources (e.g., memory, CPU time)
To help solve these problems a router can limit the
frequency with which it generates ICMP error messages. For
similar reasons, a router may limit the frequency at which
some other sorts of messages, such as ICMP Echo Replies, are
generated.
IMPLEMENTATION:
Various mechanisms have been used or proposed for limiting
the rate at which ICMP messages are sent:
(1) Count-based - for example, send an ICMP error message
for every N dropped packets overall or per given source
host. This mechanism might be appropriate for ICMP
Source Quench, but probably not for other types of ICMP
messages.
(2) Timer-based - for example, send an ICMP error message
to a given source host or overall at most once per T
milliseconds.
(3) Bandwidth-based - for example, limit the rate at which
ICMP messages are sent over a particular interface to
some fraction of the attached network's bandwidth.
4.3.3 SPECIFIC ISSUES
4.3.3.1 Destination Unreachable
If a route can not forward a packet because it has no routes at
all to the destination network specified in the packet then the
router MUST generate a Destination Unreachable, Code 0 (Network
Unreachable) ICMP message. If the router does have routes to
the destination network specified in the packet but the TOS
specified for the routes is neither the default TOS (0000) nor
the TOS of the packet that the router is attempting to route,
then the router MUST generate a Destination Unreachable, Code
11 (Network Unreachable for TOS) ICMP message.
If a packet is to be forwarded to a host on a network that is
directly connected to the router (i.e., the router is the
last-hop router) and the router has ascertained that there is
no path to the destination host then the router MUST generate a
Destination Unreachable, Code 1 (Host Unreachable) ICMP
message. If a packet is to be forwarded to a host that is on a
network that is directly connected to the router and the router
cannot forward the packet because because no route to the
destination has a TOS that is either equal to the TOS requested
in the packet or is the default TOS (0000) then the router MUST
generate a Destination Unreachable, Code 12 (Host Unreachable
for TOS) ICMP message.
DISCUSSION:
The intent is that a router generates the "generic"
host/network unreachable if it has no path at all (including
default routes) to the destination. If the router has one
or more paths to the destination, but none of those paths
have an acceptable TOS, then the router generates the
"unreachable for TOS" message.
4.3.3.2 Redirect
The ICMP Redirect message is generated to inform a host on the
same subnet that the router used by the host to route certain
packets should be changed.
Contrary to section 3.2.2.2 of [INTRO:2], a router MAY ignore
ICMP Redirects when choosing a path for a packet originated by
the router if the router is running a routing protocol or if
forwarding is enabled on the router and on the interface over
which the packet is being sent.
4.3.3.3 Source Quench
A router SHOULD NOT originate ICMP Source Quench messages. As
specified in Section [4.3.2], a router which does originate
Source Quench messages MUST be able to limit the rate at which
they are generated.
DISCUSSION:
Research seems to suggest that Source Quench consumes
network bandwidth but is an ineffective (and unfair)
antidote to congestion. See, for example, [INTERNET:9] and
[INTERNET:10]. Section [5.3.6] discusses the current
thinking on how routers ought to deal with overload and
network congestion.
A router MAY ignore any ICMP Source Quench messages it
receives.
DISCUSSION:
A router itself may receive a Source Quench as the result of
originating a packet sent to another router or host. Such
datagrams might be, e.g., an EGP update sent to another
router, or a telnet stream sent to a host. A mechanism has
been proposed ([INTERNET:11], [INTERNET:12]) to make the IP
layer respond directly to Source Quench by controlling the
rate at which packets are sent, however, this proposal is
currently experimental and not currently recommended.
4.3.3.4 Time Exceeded
When a router is forwarding a packet and the TTL field of the
packet is reduced to 0, the requirements of section [5.2.3.8]
apply.
When the router is reassembling a packet that is destined for
the router, it MUST fulfill requirements of [INTRO:2], section
[3.3.2] apply.
When the router receives (i.e., is destined for the router) a
Time Exceeded message, it MUST comply with section 3.2.2.4 of
[INTRO:2].
4.3.3.5 Parameter Problem
A router MUST generate a Parameter Problem message for any
error not specifically covered by another ICMP message. The IP
header field or IP option including the byte indicated by the
pointer field MUST be included unchanged in the IP header
returned with this ICMP message. Section [4.3.2] defines an
exception to this requirement.
A new variant of the Parameter Problem message was defined in
[INTRO:2]:
Code 1 = required option is missing.
DISCUSSION:
This variant is currently in use in the military community
for a missing security option.
4.3.3.6 Echo Request/Reply
A router MUST implement an ICMP Echo server function that
receives Echo Requests and sends corresponding Echo Replies. A
router MUST be prepared to receive, reassemble and echo an ICMP
Echo Request datagram at least as large as the maximum of 576
and the MTUs of all the connected networks.
The Echo server function MAY choose not to respond to ICMP echo
requests addressed to IP broadcast or IP multicast addresses.
A router SHOULD have a configuration option which, if enabled,
causes the router to silently ignore all ICMP echo requests; if
provided, this option MUST default to allowing responses.
DISCUSSION:
The neutral provision about responding to broadcast and
multicast Echo Requests results from the conclusions reached
in section [3.2.2.6] of [INTRO:2].
As stated in Section [10.3.3], a router MUST also implement an
user/application-layer interface for sending an Echo Request
and receiving an Echo Reply, for diagnostic purposes. All ICMP
Echo Reply messages MUST be passed to this interface.
The IP source address in an ICMP Echo Reply MUST be the same as
the specific-destination address of the corresponding ICMP Echo
Request message.
Data received in an ICMP Echo Request MUST be entirely included
in the resulting Echo Reply.
If a Record Route and/or Timestamp option is received in an
ICMP Echo Request, this option (these options) SHOULD be
updated to include the current router and included in the IP
header of the Echo Reply message, without truncation. Thus,
the recorded route will be for the entire round trip.
If a Source Route option is received in an ICMP Echo Request,
the return route MUST be reversed and used as a Source Route
option for the Echo Reply message.
4.3.3.7 Information Request/Reply
A router SHOULD NOT originate or respond to these messages.
DISCUSSION:
The Information Request/Reply pair was intended to support
self-configuring systems such as diskless workstations, to
allow them to discover their IP network numbers at boot
time. However, these messages are now obsolete. The RARP
and BOOTP protocols provide better mechanisms for a host to
discover its own IP address.
4.3.3.8 Timestamp and Timestamp Reply
A router MAY implement Timestamp and Timestamp Reply. If they
are implemented then:
o The ICMP Timestamp server function MUST return a Timestamp
Reply to every Timestamp message that is received. It
SHOULD be designed for minimum variability in delay.
o An ICMP Timestamp Request message to an IP broadcast or IP
multicast address MAY be silently discarded.
o The IP source address in an ICMP Timestamp Reply MUST be the
same as the specific-destination address of the
corresponding Timestamp Request message.
o If a Source Route option is received in an ICMP Timestamp
Request, the return route MUST be reversed and used as a
Source Route option for the Timestamp Reply message.
o If a Record Route and/or Timestamp option is received in a
Timestamp Request, this (these) option(s) SHOULD be updated
to include the current router and included in the IP header
of the Timestamp Reply message.
o If the router provides an application-layer interface for
sending Timestamp Request messages then incoming Timestamp
Reply messages MUST be passed up to the ICMP user interface.
The preferred form for a timestamp value (the standard value)
is milliseconds since midnight, Universal Time. However, it
may be difficult to provide this value with millisecond
resolution. For example, many systems use clocks that update
only at line frequency, 50 or 60 times per second. Therefore,
some latitude is allowed in a standard value:
(a) A standard value MUST be updated at least 16 times per
second (i.e., at most the six low-order bits of the value
may be undefined).
(b) The accuracy of a standard value MUST approximate that of
operator-set CPU clocks, i.e., correct within a few
minutes.
IMPLEMENTATION:
To meet the second condition, a router may need to query
some time server when the router is booted or restarted. It
is recommended that the UDP Time Server Protocol be used for
this purpose. A more advanced implementation would use the
Network Time Protocol (NTP) to achieve nearly millisecond
clock synchronization; however, this is not required.
4.3.3.9 Address Mask Request/Reply
A router MUST implement support for receiving ICMP Address Mask
Request messages and responding with ICMP Address Mask Reply
messages. These messages are defined in [INTERNET:2].
A router SHOULD have a configuration option for each logical
interface specifying whether the router is allowed to answer
Address Mask Requests for that interface; this option MUST
default to allowing responses. A router MUST NOT respond to an
Address Mask Request before the router knows the correct subnet
mask.
A router MUST NOT respond to an Address Mask Request which has
a source address of 0.0.0.0 and which arrives on a physical
interface which has associated with it multiple logical
interfaces and the subnet masks for those interfaces are not
all the same.
A router SHOULD examine all ICMP Address Mask Replies which it
receives to determine whether the information it contains
matches the router's knowledge of the subnet mask. If the ICMP
Address Mask Reply appears to be in error, the router SHOULD
log the subnet mask and the sender's IP address. A router MUST
NOT use the contents of an ICMP Address Mask Reply to determine
the correct subnet mask.
Because hosts may not be able to learn the subnet mask if a
router is down when the host boots up, a router MAY broadcast a
gratuitous ICMP Address Mask Reply on each of its logical
interfaces after it has configured its own subnet masks.
However, this feature can be dangerous in environments which
use variable length subnet masks. Therefore, if this feature
is implemented, gratuitous Address Mask Replies MUST NOT be
broadcast over any logical interface(s) which either:
o Are not configured to send gratuitous Address Mask Replies.
Each logical interface MUST have a configuration parameter
controlling this, and that parameter MUST default to not
sending the gratuitous Address Mask Replies.
o Share the same IP network number and physical interface but
have different subnet masks.
The { <Network-number>, -1, -1 } form (on subnetted networks)
or the { <Network-number>, -1 } form (on non-subnetted
networks) of the IP broadcast address MUST be used for
broadcast Address Mask Replies.
DISCUSSION:
The ability to disable sending Address Mask Replies by
routers is required at a few sites which intentionally lie
to their hosts about the subnet mask. The need for this is
expected to go away as more and more hosts become compliant
with the Host Requirements standards.
The reason for both the second bullet above and the
requirement about which IP broadcast address to use is to
prevent problems when multiple IP networks or subnets are in
use on the same physical network.
4.3.3.10 Router Advertisement and Solicitations
An IP router MUST support the router part of the ICMP Router
Discovery Protocol [INTERNET:13] on all connected networks on
which the router supports either IP multicast or IP broadcast
addressing. The implementation MUST include all of the
configuration variables specified for routers, with the
specified defaults.
DISCUSSION:
Routers are not required to implement the host part of the
ICMP Router Discovery Protocol, but might find it useful for
operation while IP forwarding is disabled (i.e., when
operating as a host).
DISCUSSION:
We note that it is quite common for hosts to use RIP as the
router discovery protocol. Such hosts listen to RIP traffic
and use and use information extracted from that traffic to
discover routers and to make decisions as to which router to
use as a first-hop router for a given destination. While
this behavior is discouraged, it is still common and
implementors should be aware of it.
4.4 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 host part of IGMP.
5. INTERNET LAYER - FORWARDING
5.1 INTRODUCTION
This section describes the process of forwarding packets.
5.2 FORWARDING WALK-THROUGH
There is no separate specification of the forwarding function in IP.
Instead, forwarding is covered by the protocol specifications for the
internet layer protocols ([INTERNET:1], [INTERNET:2], [INTERNET:3],
[INTERNET:8], and [ROUTE:11]).
5.2.1 Forwarding Algorithm
Since none of the primary protocol documents describe the
forwarding algorithm in any detail, we present it here. This is
just a general outline, and omits important details, such as
handling of congestion, that are dealt with in later sections.
It is not required that an implementation follow exactly the
algorithms given in sections [5.2.1.1], [5.2.1.2], and [5.2.1.3].
Much of the challenge of writing router software is to maximize
the rate at which the router can forward packets while still
achieving the same effect of the algorithm. Details of how to do
that are beyond the scope of this document, in part because they
are heavily dependent on the architecture of the router. Instead,
we merely point out the order dependencies among the steps:
(1) A router MUST verify the IP header, as described in section
[5.2.2], before performing any actions based on the contents
of the header. This allows the router to detect and discard
bad packets before the expenditure of other resources.
(2) Processing of certain IP options requires that the router
insert its IP address into the option. As noted in Section
[5.2.4], the address inserted MUST be the address of the
logical interface on which the packet is sent or the router's
router-id if the packet is sent over an unnumbered interface.
Thus, processing of these options cannot be completed until
after the output interface is chosen.
(3) The router cannot check and decrement the TTL before checking
whether the packet should be delivered to the router itself,
for reasons mentioned in Section [4.2.2.9].
(4) More generally, when a packet is delivered locally to the
router, its IP header MUST NOT be modified in any way (except
that a router may be required to insert a timestamp into any
Timestamp options in the IP header). Thus, before the router
determines whether the packet is to be delivered locally to
the router, it cannot update the IP header in any way that it
is not prepared to undo.
5.2.1.1 General
This section covers the general forwarding algorithm. This
algorithm applies to all forms of packets to be forwarded:
unicast, multicast, and broadcast.
(1) The router receives the IP packet (plus additional
information about it, as described in Section [3.1]) from
the Link Layer.
(2) The router validates the IP header, as described in
Section [5.2.2]. Note that IP reassembly is not done,
except on IP fragments to be queued for local delivery in
step (4).
(3) The router performs most of the processing of any IP
options. As described in Section [5.2.4], some IP options
require additional processing after the routing decision
has been made.
(4) The router examines the destination IP address of the IP
datagram, as described in Section [5.2.3], to determine
how it should continue to process the IP datagram. There
are three possibilities:
o The IP datagram is destined for the router, and should
be queued for local delivery, doing reassembly if
needed.
o The IP datagram is not destined for the router, and
should be queued for forwarding.
o The IP datagram should be queued for forwarding, but (a
copy) must also be queued for local delivery.
5.2.1.2 Unicast
Since the local delivery case is well-covered by [INTRO:2], the
following assumes that the IP datagram was queued for
forwarding. If the destination is an IP unicast address:
(5) The forwarder determines the next hop IP address for the
packet, usually by looking up the packet's destination in
the router's routing table. This procedure is described
in more detail in Section [5.2.4]. This procedure also
decides which network interface should be used to send the
packet.
(6) The forwarder verifies that forwarding the packet is
permitted. The source and destination addresses should be
valid, as described in Section [5.3.7] and Section [5.3.4]
If the router supports administrative constraints on
forwarding, such as those described in Section [5.3.9],
those constraints must be satisfied.
(7) The forwarder decrements (by at least one) and checks the
packet's TTL, as described in Section [5.3.1].
(8) The forwarder performs any IP option processing that could
not be completed in step 3.
(9) The forwarder performs any necessary IP fragmentation, as
described in Section [4.2.2.7]. Since this step occurs
after outbound interface selection (step 5), all fragments
of the same datagram will be transmitted out the same
interface.
(10) The forwarder determines the Link Layer address of the
packet's next hop. The mechanisms for doing this are Link
Layer-dependent (see chapter 3).
(11) The forwarder encapsulates the IP datagram (or each of the
fragments thereof) in an appropriate Link Layer frame and
queues it for output on the interface selected in step 5.
(12) The forwarder sends an ICMP redirect if necessary, as
described in Section [4.3.3.2].
5.2.1.3 Multicast
If the destination is an IP multicast, the following steps are
taken.
Note that the main differences between the forwarding of IP
unicasts and the forwarding of IP multicasts are
o IP multicasts are usually forwarded based on both the
datagram's source and destination IP addresses,
o IP multicast uses an expanding ring search,
o IP multicasts are forwarded as Link Level multicasts, and
o ICMP errors are never sent in response to IP multicast
datagrams.
Note that the forwarding of IP multicasts is still somewhat
experimental. As a result, the algorithm presented below is not
mandatory, and is provided as an example only.
(5a) Based on the IP source and destination addresses found in
the datagram header, the router determines whether the
datagram has been received on the proper interface for
forwarding. If not, the datagram is dropped silently. The
method for determining the proper receiving interface
depends on the multicast routing algorithm(s) in use. In
one of the simplest algorithms, reverse path forwarding
(RPF), the proper interface is the one that would be used
to forward unicasts back to the datagram source.
(6a) Based on the IP source and destination addresses found in
the datagram header, the router determines the datagram's
outgoing interfaces. In order to implement IP multicast's
expanding ring search (see [INTERNET:4]) a minimum TTL
value is specified for each outgoing interface. A copy of
the multicast datagram is forwarded out each outgoing
interface whose minimum TTL value is less than or equal to
the TTL value in the datagram header, by separately
applying the remaining steps on each such interface.
(7a) The router decrements the packet's TTL by one.
(8a) The forwarder performs any IP option processing that could
not be completed in step (3).
(9a) The forwarder performs any necessary IP fragmentation, as
described in Section [4.2.2.7].
(10a) The forwarder determines the Link Layer address to use in
the Link Level encapsulation. The mechanisms for doing
this are Link Layer-dependent. On LANs a Link Level
multicast or broadcast is selected, as an algorithmic
translation of the datagrams' class D destination address.
See the various IP-over-xxx specifications for more
details.
(11a) The forwarder encapsulates the packet (or each of the
fragments thereof) in an appropriate Link Layer frame and
queues it for output on the appropriate interface.
5.2.2 IP Header Validation
Before a router can process any IP packet, it MUST perform a the
following basic validity checks on the packet's IP header to
ensure that the header is meaningful. If the packet fails any of
the following tests, it MUST be silently discarded, and the error
SHOULD be logged.
(1) The packet length reported by the Link Layer must be large
enough to hold the minimum length legal IP datagram (20
bytes).
(2) The IP checksum must be correct.
(3) The IP version number must be 4. If the version number is
not 4 then the packet may well be another version of IP, such
as ST-II.
(4) The IP header length field must be at least 5.
(5) The IP total length field must be at least 4 * IP header
length field.
A router MUST NOT have a configuration option which allows
disabling any of these tests.
If the packet passes the second and third tests, the IP header
length field is at least 4, and both the IP total length field and
the packet length reported by the Link Layer are at least 16 then,
despite the above rule, the router MAY respond with an ICMP
Parameter Problem message, whose pointer points at the IP header
length field (if it failed the fourth test) or the IP total length
field (if it failed the fifth test). However, it still MUST
discard the packet and still SHOULD log the error.
These rules (and this entire document) apply only to version 4 of