RFC 1716
Towards Requirements for IP Routers
3. LINK LAYER
Although [INTRO:1] covers Link Layer standards (IP over foo, ARP,
etc.), this document anticipates that Link-Layer material will be
covered in a separate Link Layer Requirements document. A Link-Layer
requirements document would be applicable to both hosts and routers.
Thus, this document will not obsolete the parts of [INTRO:1] that deal
with link-layer issues.
3.1 INTRODUCTION
Routers have essentially the same Link Layer protocol requirements as
other sorts of Internet systems. These requirements are given in
chapter 3 of Requirements for Internet Gateways [INTRO:1]. A router
MUST comply with its requirements and SHOULD comply with its
recommendations. Since some of the material in that document has
become somewhat dated, some additional requirements and explanations
are included below.
DISCUSSION:
It is expected that the Internet community will produce a
Requirements for Internet Link Layer standard which will supersede
both this chapter and chapter 3 of [INTRO:1].
3.2 LINK/INTERNET LAYER INTERFACE
Although this document does not attempt to specify the interface
between the Link Layer and the upper layers, it is worth noting here
that other parts of this document, particularly chapter 5, require
various sorts of information to be passed across this layer boundary.
This section uses the following definitions:
o Source physical address
The source physical address is the Link Layer address of the host
or router from which the packet was received.
o Destination physical address
The destination physical address is the Link Layer address to
which the packet was sent.
The information that must pass from the Link Layer to the
Internetwork Layer for each received packet is:
(1) The IP packet [5.2.2],
(2) The length of the data portion (i.e., not including the Link-
Layer framing) of the Link Layer frame [5.2.2],
(3) The identity of the physical interface from which the IP packet
was received [5.2.3], and
(4) The classification of the packet's destination physical address
as a Link Layer unicast, broadcast, or multicast [4.3.2],
[5.3.4].
In addition, the Link Layer also should provide:
(5) The source physical address.
The information that must pass from the Internetwork Layer to the
Link Layer for each transmitted packet is:
(1) The IP packet [5.2.1]
(2) The length of the IP packet [5.2.1]
(3) The destination physical interface [5.2.1]
(4) The next hop IP address [5.2.1]
In addition, the Internetwork Layer also should provide:
(5) The Link Layer priority value [5.3.3.2]
The Link Layer must also notify the Internetwork Layer if the packet
to be transmitted causes a Link Layer precedence-related error
[5.3.3.3].
3.3 SPECIFIC ISSUES
3.3.1 Trailer Encapsulation
Routers which can connect to 10Mb Ethernets MAY be able to receive
and forward Ethernet packets encapsulated using the trailer
encapsulation described in [LINK:1]. However, a router SHOULD NOT
originate trailer encapsulated packets. A router MUST NOT
originate trailer encapsulated packets without first verifying,
using the mechanism described in section 2.3.1 of [INTRO:2], that
the immediate destination of the packet is willing and able to
accept trailer-encapsulated packets. A router SHOULD NOT agree
(using these same mechanisms) to accept trailer-encapsulated
packets.
3.3.2 Address Resolution Protocol - ARP
Routers which implement ARP MUST be compliant and SHOULD be
unconditionally compliant with the requirements in section 2.3.2
of [INTRO:2].
The link layer MUST NOT report a Destination Unreachable error to
IP solely because there is no ARP cache entry for a destination.
A router MUST not believe any ARP reply which claims that the Link
Layer address of another host or router is a broadcast or
multicast address.
3.3.3 Ethernet and 802.3 Coexistence
Routers which can connect to 10Mb Ethernets MUST be compliant and
SHOULD be unconditionally compliant with the requirements of
Section [2.3.3] of [INTRO:2].
3.3.4 Maximum Transmission Unit - MTU
The MTU of each logical interface MUST be configurable.
Many Link Layer protocols define a maximum frame size that may be
sent. In such cases, a router MUST NOT allow an MTU to be set
which would allow sending of frames larger than those allowed by
the Link Layer protocol. However, a router SHOULD be willing to
receive a packet as large as the maximum frame size even if that
is larger than the MTU.
DISCUSSION:
Note that this is a stricter requirement than imposed on hosts
by [INTRO:2], which requires that the MTU of each physical
interface be configurable.
If a network is using an MTU smaller than the maximum frame
size for the Link Layer, a router may receive packets larger
than the MTU from hosts which are in the process of
initializing themselves, or which have been misconfigured.
In general, the Robustness Principle indicates that these
packets should be successfully received, if at all possible.
3.3.5 Point-to-Point Protocol - PPP
Contrary to [INTRO:1], the Internet does have a standard serial
line protocol: the Point-to-Point Protocol (PPP), defined in
[LINK:2], [LINK:3], [LINK:4], and [LINK:5].
A serial line interface is any interface which is designed to send
data over a telephone, leased, dedicated or direct line (either 2
or 4 wire) using a standardized modem or bit serial interface
(such as RS-232, RS-449 or V.35), using either synchronous or
asynchronous clocking.
A general purpose serial interface is a serial line interface
which is not solely for use as an access line to a network for
which an alternative IP link layer specification exists (such as
X.25 or Frame Relay).
Routers which contain such general purpose serial interfaces MUST
implement PPP.
PPP MUST be supported on all general purpose serial interfaces on
a router. The router MAY allow the line to be configured to use
serial line protocols other than PPP, all general purpose serial
interfaces MUST default to using PPP.
3.3.5.1 Introduction
This section provides guidelines to router implementors so that
they can ensure interoperability with other routers using PPP
over either synchronous or asynchronous links.
It is critical that an implementor understand the semantics of
the option negotiation mechanism. Options are a means for a
local device to indicate to a remote peer what the local device
will *accept* from the remote peer, not what it wishes to send.
It is up to the remote peer to decide what is most convenient
to send within the confines of the set of options that the
local device has stated that it can accept. Therefore it is
perfectly acceptable and normal for a remote peer to ACK all
the options indicated in an LCP Configuration Request (CR) even
if the remote peer does not support any of those options.
Again, the options are simply a mechanism for either device to
indicate to its peer what it will accept, not necessarily what
it will send.
3.3.5.2 Link Control Protocol (LCP) Options
The PPP Link Control Protocol (LCP) offers a number of options
that may be negotiated. These options include (among others)
address and control field compression, protocol field
compression, asynchronous character map, Maximum Receive Unit
(MRU), Link Quality Monitoring (LQM), magic number (for
loopback detection), Password Authentication Protocol (PAP),
Challenge Handshake Authentication Protocol (CHAP), and the
32-bit Frame Check Sequence (FCS).
A router MAY do address/control field compression on either
synchronous or asynchronous links. A router MAY do protocol
field compression on either synchronous or asynchronous links.
A router MAY indicate that it can accept these compressions,
but MUST be able to accept uncompressed PPP header information
even if it has indicated a willingness to receive compressed
PPP headers.
DISCUSSION:
These options control the appearance of the PPP header.
Normally the PPP header consists of the address field (one
byte containing the value 0xff), the control field (one byte
containing the value 0x03), and the two-byte protocol field
that identifies the contents of the data area of the frame.
If a system negotiates address and control field compression
it indicates to its peer that it will accept PPP frames that
have or do not have these fields at the front of the header.
It does not indicate that it will be sending frames with
these fields removed. The protocol field may also be
compressed from two to one byte in most cases.
IMPLEMENTATION:
Some hardware does not deal well with variable length header
information. In those cases it makes most sense for the
remote peer to send the full PPP header. Implementations
may ensure this by not sending the address/control field and
protocol field compression options to the remote peer. Even
if the remote peer has indicated an ability to receive
compressed headers there is no requirement for the local
router to send compressed headers.
A router MUST negotiate the Async Control Character Map (ACCM)
for asynchronous PPP links, but SHOULD NOT negotiate the ACCM
for synchronous links. If a router receives an attempt to
negotiate the ACCM over a synchronous link, it MUST ACKnowledge
the option and then ignore it.
DISCUSSION:
There are implementations that offer both sync and async
modes of operation and may use the same code to implement
the option negotiation. In this situation it is possible
that one end or the other may send the ACCM option on a
synchronous link.
A router SHOULD properly negotiate the maximum receive unit
(MRU). Even if a system negotiates an MRU smaller than 1,500
bytes, it MUST be able to receive a 1,500 byte frame.
A router SHOULD negotiate and enable the link quality
monitoring (LQM) option.
DISCUSSION:
This memo does not specify a policy for deciding whether the
link's quality is adequate. However, it is important (see
Section [3.3.6]) that a router disable failed links.
A router SHOULD implement and negotiate the magic number option
for loopback detection.
A router MAY support the authentication options (PAP - password
authentication protocol, and/or CHAP - challenge handshake
authentication protocol).
A router MUST support 16-bit CRC frame check sequence (FCS) and
MAY support the 32-bit CRC.
3.3.5.3 IP Control Protocol (ICP) Options
A router MAY offer to perform IP address negotiation. A router
MUST accept a refusal (REJect) to perform IP address
negotiation from the peer.
A router SHOULD NOT perform Van Jacobson header compression of
TCP/IP packets if the link speed is in excess of 64 Kbps.
Below that speed the router MAY perform Van Jacobson (VJ)
header compression. At link speeds of 19,200 bps or less the
router SHOULD perform VJ header compression.
3.3.6 Interface Testing
A router MUST have a mechanism to allow routing software to
determine whether a physical interface is available to send
packets or not. A router SHOULD have a mechanism to allow routing
software to judge the quality of a physical interface. A router
MUST have a mechanism for informing the routing software when a
physical interface becomes available or unavailable to send
packets because of administrative action. A router MUST have a
mechanism for informing the routing software when it detects a
Link level interface has become available or unavailable, for any
reason.
DISCUSSION:
It is crucial that routers have workable mechanisms for
determining that their network connections are functioning
properly, since failure to do so (or failure to take the proper
actions when a problem is detected) can lead to black holes.
The mechanisms available for detecting problems with network
connections vary considerably, depending on the Link Layer
protocols in use and also in some cases on the interface
hardware chosen by the router manufacturer. The intent is to
maximize the capability to detect failures within the Link-
Layer constraints.
4. INTERNET LAYER - PROTOCOLS
4.1 INTRODUCTION
This chapter and chapter 5 discuss the protocols used at the Internet
Layer: IP, ICMP, and IGMP. Since forwarding is obviously a crucial
topic in a document discussing routers, chapter 5 limits itself to
the aspects of the protocols which directly relate to forwarding.
The current chapter contains the remainder of the discussion of the
Internet Layer protocols.
4.2 INTERNET PROTOCOL - IP
4.2.1 INTRODUCTION
Routers MUST implement the IP protocol, as defined by
[INTERNET:1]. They MUST also implement its mandatory extensions:
subnets (defined in [INTERNET:2]), and IP broadcast (defined in
[INTERNET:3]).
A router MUST be compliant, and SHOULD be unconditionally
compliant, with the requirements of sections 3.2.1 and 3.3 of
[INTRO:2], except that:
o Section 3.2.1.1 may be ignored, since it duplicates
requirements found in this memo.
o Section 3.2.1.2 may be ignored, since it duplicates
requirements found in this memo.
o Section 3.2.1.3 should be ignored, since it is superseded by
Section [4.2.2.11] of this memo.
o Section 3.2.1.4 may be ignored, since it duplicates
requirements found in this memo.
o Section 3.2.1.6 should be ignored, since it is superseded by
Section [4.2.2.4] of this memo.
o Section 3.2.1.8 should be ignored, since it is superseded by
Section [4.2.2.1] of this memo.
In the following, the action specified in certain cases is to
silently discard a received datagram. This means that the
datagram will be discarded without further processing and that the
router will not send any ICMP error message (see Section [4.3]) as
a result. However, for diagnosis of problems a router SHOULD
provide the capability of logging the error (see Section [1.3.3]),
including the contents of the silently-discarded datagram, and
SHOULD record the event in a statistics counter.
4.2.2 PROTOCOL WALK-THROUGH
RFC 791 is [INTERNET:1], the specification for the Internet
Protocol.
4.2.2.1 Options: RFC-791 Section 3.2
In datagrams received by the router itself, the IP layer MUST
interpret those IP options that it understands and preserve the
rest unchanged for use by higher layer protocols.
Higher layer protocols may require the ability to set IP
options in datagrams they send or examine IP options in
datagrams they receive. Later sections of this document
discuss specific IP option support required by higher layer
protocols.
DISCUSSION:
Neither this memo nor [INTRO:2] define the order in which a
receiver must process multiple options in the same IP
header. Hosts and routers originating datagrams containing
multiple options must be aware that this introduces an
ambiguity in the meaning of certain options when combined
with a source-route option.
Here are the requirements for specific IP options:
(a) Security Option
Some environments require the Security option in every
packet originated or received. Routers SHOULD IMPLEMENT
the revised security option described in [INTERNET:5].
DISCUSSION:
Note that the security options described in
[INTERNET:1] and RFC 1038 ([INTERNET:16]) are obsolete.
(b) Stream Identifier Option
This option is obsolete; routers SHOULD NOT place this
option in a datagram that the router originates. This
option MUST be ignored in datagrams received by the
router.
(c) Source Route Options
A router MUST be able to act as the final destination of a
source route. If a router receives a packet containing a
completed source route (i.e., the pointer points beyond
the last field and the destination address in the IP
header addresses the router), the packet has reached its
final destination; the option as received (the recorded
route) MUST be passed up to the transport layer (or to
ICMP message processing).
In order to respond correctly to source-routed datagrams
it receives, a router MUST provide a means whereby
transport protocols and applications can reverse the
source route in a received datagram and insert the
reversed source route into datagrams they originate (see
Section 4 of [INTRO:2] for details).
Some applications in the router MAY require that the user
be able to enter a source route.
A router MUST NOT originate a datagram containing multiple
source route options. What a router should do if asked to
forward a packet containing multiple source route options
is described in Section [5.2.4.1].
When a source route option is created, it MUST be
correctly formed even if it is being created by reversing
a recorded route that erroneously includes the source host
(see case (B) in the discussion below).
DISCUSSION:
Suppose a source routed datagram is to be routed from
source S to destination D via routers G1, G2, ... Gn.
Source S constructs a datagram with G1's IP address as
its destination address, and a source route option to
get the datagram the rest of the way to its
destination. However, there is an ambiguity in the
specification over whether the source route option in a
datagram sent out by S should be (A) or (B):
(A): {>>G2, G3, ... Gn, D} <--- CORRECT
(B): {S, >>G2, G3, ... Gn, D} <---- WRONG
(where >> represents the pointer). If (A) is sent, the
datagram received at D will contain the option: {G1,
G2, ... Gn >>}, with S and D as the IP source and
destination addresses. If (B) were sent, the datagram
received at D would again contain S and D as the same
IP source and destination addresses, but the option
would be: {S, G1, ...Gn >>}; i.e., the originating host
would be the first hop in the route.
(d) Record Route Option
Routers MAY support the Record Route option in datagrams
originated by the router.
(e) Timestamp Option
Routers MAY support the timestamp option in datagrams
originated by the router. The following rules apply:
o When originating a datagram containing a Timestamp
Option, a router MUST record a timestamp in the option
if
- Its Internet address fields are not pre-specified or
- Its first pre-specified address is the IP address of
the logical interface over which the datagram is
being sent (or the router's router-id if the
datagram is being sent over an unnumbered
interface).
o If the router itself receives a datagram containing a
Timestamp Option, the router MUST insert the current
timestamp into the Timestamp Option (if there is space
in the option to do so) before passing the option to
the transport layer or to ICMP for processing.
o A timestamp value MUST follow the rules given in
Section [3.2.2.8] of [INTRO:2].
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 Link Layer for
transmission.
4.2.2.2 Addresses in Options: RFC-791 Section 3.1
When a router inserts its address into a Record Route, Strict
Source and Record Route, Loose Source and Record Route, or
Timestamp, it MUST use the IP address of the logical interface
on which the packet is being sent. Where this rule cannot be
obeyed because the output interface has no IP address (i.e., is
an unnumbered interface), the router MUST instead insert its
router-id. The router's router-id is one of the router's IP
addresses. Which of the router's addresses is used as the
router-id MUST NOT change (even across reboots) unless changed
by the network manager or unless the configuration of the
router is changed such that the IP address used as the router-
id ceases to be one of the router's IP addresses. Routers with
multiple unnumbered interfaces MAY have multiple router-id's.
Each unnumbered interface MUST be associated with a particular
router-id. This association MUST NOT change (even across
reboots) without reconfiguration of the router.
DISCUSSION:
This specification does not allow for routers which do not
have at least one IP address. We do not view this as a
serious limitation, since a router needs an IP address to
meet the manageability requirements of Chapter [8] even if
the router is connected only to point-to-point links.
IMPLEMENTATION:
One possible method of choosing the router-id that fulfills
this requirement is to use the numerically smallest (or
greatest) IP address (treating the address as a 32-bit
integer) that is assigned to the router.
4.2.2.3 Unused IP Header Bits: RFC-791 Section 3.1
The IP header contains two reserved bits: one in the Type of
Service byte and the other in the Flags field. A router MUST
NOT set either of these bits to one in datagrams originated by
the router. A router MUST NOT drop (refuse to receive or
forward) a packet merely because one or more of these reserved
bits has a non-zero value.
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.
4.2.2.4 Type of Service: RFC-791 Section 3.1
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.
(next page on part 3)
