Requirements for IP Version 4 Routers

Routers : The devices that perform the network layer forwarding function of the Internet protocol suite.

The major distinction between Internet hosts and routers is that routers implement forwarding algorithms, while Internet hosts do not require forwarding capabilities.

A router connects to two or more logical interfaces, represented by IP subnets or unnumbered point to point lines.Thus, it has at least one physical interface. Forwarding an IP datagram generally requires the router to choose the address and relevant interface of the next-hop router or (for the final hop) the destination host. This choice, called relaying or forwarding depends upon a route database within the router. The route database is also called a routing table or forwarding table.
Routers provide datagram transport only, and they seek to minimize the state information necessary to sustain this service in the interest of routing flexibility and robustness.
An Autonomous System (AS) is a connected segment of a network topology that consists of a collection of subnetworks (with hosts attached) interconnected by a set of routes. The subnetworks and the routers are expected to be under the control of a single operations and maintenance (O&M) organization. An AS is identified by an Autonomous System number.
An IP datagram carries 32-bit source and destination addresses, each of which is partitioned into two parts - a constituent network prefix and a host number on that network.

IP-address ::= { <Network-prefix>, <Host-number> }

To finally deliver the datagram, the last router in its path must map the Host-number (or rest) part of an IP address to the host’s Link Layer address.
The simplest classical network prefix is the Class A, B, C, D, or E network prefix. These address ranges are discriminated by observing the values of the most significant bits of the address, and break the address into simple prefix and host number fields.

1. 0xxx - Class A - general purpose unicast addresses with standard 8 bit prefix
2. 10xx - Class B - general purpose unicast addresses with standard 16 bit prefix
3. 110x - Class C - general purpose unicast addresses with standard 24 bit prefix
4. 1110 - Class D - IP Multicast Addresses - 28 bit prefix, nonaggregatable
5. 1111 - Class E - reserved for experimental use
   

This simple notion has been extended by the concept of subnets. Subnets provide a multi-level hierarchical routing structure for the Internet system. The basic idea is to partition the <Host-number> field into two parts: a subnet number, and a true host number on that subnet:

IP-address ::= { <Network-number>, <Subnet-number>, <Host-number> }

The distinction between the subnets of such a subnetted network is not normally visible outside of that network. Routers outside the network treat <Network-prefix> and <Host-number> together as an uninterpreted rest part of the 32-bit IP address. Within the subnetted network, the routers use the extended network prefix:

{ <Network-number>, <Subnet-number> }

The bit positions containing this extended network number have historically been indicated by a 32-bit mask called the subnet mask.

IP multicasting is an extension of Link Layer multicast to IP internets.This collection of hosts is called a multicast group. Each multicast group is represented as a Class D IP address. An IP datagram sent to the group is to be delivered to each group member with the same besteffort delivery as that provided for unicast IP traffic. The sender of the datagram does not itself need to be a member of the destination group.

Router Characteristics

An Internet router performs the following functions:

1. Conforms to specific Internet protocols including the Internet Protocol (IP), Internet Control Message Protocol (ICMP), and others as necessary.
2. Interfaces to two or more packet networks. For each connected network the router must implement the functions required by that network. These functions typically include:
   
   1. Encapsulating and decapsulating the IP datagrams with the connected network framing (e.g., an Ethernet header and checksum),
   2. Sending and receiving IP datagrams up to the maximum size supported by that network, this size is the network’s Maximum Transmission Unit or MTU,
   3. Translating the IP destination address into an appropriate network-level address for the connected network (e.g., an Ethernet hardware address), if needed, and
   4. Responding to network flow control and error indications, if any.
3. Receives and forwards Internet datagrams. Important issues in this process are buffer management, congestion control, and fairness.
   
   1. Recognizes error conditions and generates ICMP error and information messages as required.
   2. Drops datagrams whose time-to-live fields have reached zero.
   3. Fragments datagrams when necessary to fit into the MTU of the next network.
4. Chooses a next-hop destination for each IP datagram, based on the information in its routing database.
5. (Usually) supports an interior gateway protocol (IGP) to carry out distributed routing and reachability algorithms with the other routers in the same autonomous system. In addition, some routers will need to support an exterior gateway protocol (EGP) to exchange topological information with other autonomous systems.
6. Provides network management and system support facilities, including loading, debugging, status reporting, exception reporting and control.
   

Routers in the global interconnect system generally require:

1. Advanced Routing and Forwarding Algorithms
   These routers need routing algorithms that are highly dynamic, impose minimal processing and communication burdens, and offer type-of-service routing. Congestion is still not a completely resolved issue.
2. High Availability
   These routers need to be highly reliable, providing 24 hours a day, 7 days a week service.
3. Advanced O&M Features
   Internet routers normally operate in an unattended mode. They will typically be operated remotely from a centralized monitoring center. They need to provide sophisticated means for monitoring and measuring traffic and other events and for diagnosing faults.
4. High Performance
   

Architectural Assumptions
The current Internet architecture is based on a set of assumptions about the communication system. The assumptions most relevant to routers are as follows:

1. The Internet is a network of networks.
   Each host is directly connected to some particular network(s); its connection to the Internet is only conceptual. Two hosts on the same network communicate with each other using the same set of protocols that they would use to communicate with hosts on distant networks.
2. Routers do not keep connection state information.
   All state information required for end-to-end flow control and reliability is implemented in the hosts, in the transport layer or in application programs. All connection control information is thus co-located with the end points of the communication, so it will be lost only if an end point fails. Routers control message flow only indirectly, by dropping packets or increasing network delay.
   Note that future protocol developments may well end up putting some more state into routers. This is especially likely for multicast routing, resource reservation, and flow based forwarding.
3. Routing complexity should be in the routers.
   Routing is a complex and difficult problem, and ought to be performed by the routers, not the hosts.
4. The system must tolerate wide network variation.
   A basic objective of the Internet design is to tolerate a wide range of network characteristics - e.g., bandwidth, delay, packet loss, packet reordering, and maximum packet size.
   Another objective is robustness against failure of individual networks, routers, and hosts, using whatever bandwidth is still available.
   Finally, the goal is full open system interconnection: an Internet router must be able to interoperate robustly and effectively with any other router or Internet host, across diverse Internet paths.
   

LINK/INTERNET LAYER INTERFACE
The information that must pass from the Link Layer to the Internetwork Layer for each received packet is:

1. The IP packet
2. The length of the data portion (i.e., not including the Link-Layer framing) of the Link Layer frame
3. The identity of the physical interface from which the IP packet was received
4. The classification of the packet’s destination physical address as a Link Layer unicast, broadcast, or multicast
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
2. The length of the IP packet
3. The destination physical interface
4. The next hop IP address
5. The Link Layer priority value
   

Here are the requirements for specific IP options:

1. Security Option
2. Stream Identifier Option
   This option is obsolete;
   
3. 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, the packet has reached its final destination. In such an option, the pointer points beyond the last field and the destination address in the IP header addresses the router. The option as received (the recorded route) MUST be passed up to the transport layer (or to ICMP message processing).
   When a source route option is created (which would happen when the router is originating a source routed datagram or is inserting a source route option as a result of a special filter), it MUST be correctly formed even if it is being created by reversing a recorded route that erroneously includes the source host
   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.
4. Record Route Option
5. Timestamp Option
   Routers MAY support the timestamp option in datagrams originated by the router. The following rules apply:
   
   1. 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
   2. If the router itself receives a datagram containing a Timestamp Option, the router MUST insert the current time 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. If space is not present, the router MUST increment the Overflow Count in the option.

   To maximize the utility of the timestamps contained in the timestamp option, the timestamp inserted should 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.
   The timestamp option permits the use of a non-standard time clock, but the use of a non-synchronized clock limits the utility of the time stamp. Therefore, routers are well advised to implement the Network Time Protocol for the purpose of synchronizing their clocks.
   

A router MUST verify the IP checksum of any packet that is received, and MUST discard messages containing invalid checksums. The router MUST NOT provide a means to disable this checksum verification.
When a router fragments an IP datagram, it SHOULD minimize the number of fragments. When a router fragments an IP datagram, it SHOULD send the fragments in order.
Note in particular that a router MUST NOT check the TTL of a packet except when forwarding it.
A router MUST NOT originate or forward a datagram with a Time-to-Live (TTL) value of zero.
A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it.
On messages the router originates, the IP layer MUST provide a means for the transport layer to set the TTL field of every datagram that is sent. When a fixed TTL value is used, it MUST be configurable.
The TTL field has two functions: limit the lifetime of TCP segments, and terminate Internet routing loops.

A higher-layer protocol may want to set the TTL in order to implement an "expanding scope" search for some Internet resource. This is used by some diagnostic tools, and is expected to be useful for locating the "nearest" server of a given class using IP multicasting, for example. A particular transport protocol may also want to specify its own TTL bound on maximum datagram lifetime.
A default TTL value in excess of 40, and 64 is a common value.
All-subnets broadcasts (called multi-subnet broadcasts) have been deprecated.
An IP multicast 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, while transient addresses may be allocated dynamically to transient groups. Group membership is determined dynamically using IGMP.
We now summarize the important special cases for general purpose unicast IP addresses, using the following notation for an IP address:

{ <Network-prefix>, <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.

1. { 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, 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 }.
   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.
2. { 0, <Host-number> }
   Specified host on this network. It MUST NOT be sent by routers except that the router MAY use this as a source address as part of an initialization procedure by which the it learns its own IP address.
3. { -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.
4. { <Network-prefix>, -1 }
   Directed Broadcast - a broadcast directed to the specified network prefix. 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.
5. { 127, <any> }
   Internal host loopback address. Addresses of this form MUST NOT appear outside a host.
   

IP addresses are not permitted to have the value 0 or -1 for the <Host-number> or <Network-prefix> fields except in the special cases listed above. This implies that each of these fields will be at least two bits long.
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:

1. A router MUST receive and process normally any packets with a broadcast destination address.
2. A router MUST receive and process normally any packets sent to a multicast destination address that the router has asked to receive.
   

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.
A router

1. MUST treat as IP broadcasts packets addressed to 255.255.255.255 or { <Network-prefix>, -1 }.
2. SHOULD silently discard on receipt (i.e., do not even deliver to applications in the router) any packet addressed to 0.0.0.0 or { <Network-prefix>, 0 }. If these packets are not silently discarded, they MUST be treated as IP broadcasts. 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 (sub)network (except when sending an ICMP Address Mask Reply). A router MUST receive limited broadcasts.
4. SHOULD NOT originate datagrams addressed to 0.0.0.0 or { <Network-prefix>, 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.
   

An IP router SHOULD satisfy the Host Requirements with respect to IP
multicasting. An IP router SHOULD support local IP multicasting on all connected networks. When a mapping from IP multicast addresses to link-layer addresses has been specified  it SHOULD use that mapping, and MAY be configurable to use the link layer broadcast instead.

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 including IGMP.
The path MTU is the minimum of the MTUs of each hop in the path.

ICMP is an auxiliary protocol, which provides routing, diagnostic and error functionality for IP.
ICMP messages are grouped in two classes that are discussed in the following sections:

1. ICMP error messages:
   Destination Unreachable
   Redirect
   Source Quench
   Time Exceeded
   Parameter Problem
2. ICMP query messages:
   Echo
   Information
   Timestamp
   Address Mask
   Router Discovery
   

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 does not have one).
When originating an ICMP message, the router MUST initialize the TTL. The TTL for ICMP responses must not be taken from the packet that triggered the response.
The ICMP datagram SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 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, or updating options).
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.
ICMP error messages SHOULD have their TOS bits set to the same value as the TOS bits in the packet that 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.

ICMP Source Quench error messages, if sent at all, MUST have their IP Precedence field set to the same value as the IP Precedence field in the packet that provoked the sending of the ICMP Source Quench message. All other ICMP error messages (Destination Unreachable, Redirect, Time Exceeded, and Parameter Problem) SHOULD have their precedence value set to 6 (INTERNETWORK CONTROL) or 7 (NETWORK CONTROL). 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.
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, or unless the router is aware of policy that would prevent the delivery of the ICMP error message.
An ICMP error message MUST NOT be sent as the result of receiving:

1. An ICMP error message, or
2. A packet which fails the IP header validation tests or
3. A packet destined to an IP broadcast or IP multicast address, or
4. A packet sent as a Link Layer broadcast or multicast, or
5. A packet whose source address has a network prefix of zero or is an invalid source address, or
6. 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.

These rules aim to prevent the broadcast storms that have resulted from routers or hosts returning ICMP error messages in response to broadcast packets.

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.
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.
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, if used, 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.
   

Destination Unreachable

1. If a router cannot forward a packet because it has no routes at all (including no default route) to the destination specified in the packet, then the router MUST generate a Destination Unreachable, Code 0 (Network Unreachable) ICMP message.
2. 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.
3. 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.
4. 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 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.
   

Redirect
The ICMP Redirect message is generated to inform a local host that it should use a different next hop router for certain traffic.
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.
Source Quench
A router SHOULD NOT originate ICMP Source Quench messages. A  router that does originate Source Quench messages MUST be able to limit the rate at which they are
generated.
A router MAY ignore any ICMP Source Quench messages it receives.

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.
A new variant of the Parameter Problem message was defined in: Code 1 = required option is missing.
This variant is currently in use in the military community for a missing security option.
Echo Request/Reply

1. A router MUST implement an ICMP Echo server function that receives Echo Requests sent to the router, and sends corresponding Echo Replies.
   
2. A router MUST be prepared to receive, reassemble and echo an ICMP Echo Request datagram at least as the maximum of 576 and the MTUs of all the connected networks.
3. The Echo server function MAY choose not to respond to ICMP echo requests addressed to IP broadcast or IP multicast addresses.
4. A router SHOULD have a configuration option that, if enabled, causes the router to silently ignore all ICMP echo requests; if provided, this option MUST default to allowing responses.
5. 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.
6. 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, unless the router is aware of policy that would prevent the delivery of the message.

Timestamp and Timestamp Reply
A router MAY implement Timestamp and Timestamp Reply. If they are implemented then:

1. 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.
2. An ICMP Timestamp Request message to an IP broadcast or IP multicast address MAY be silently discarded.
3. The IP source address in an ICMP Timestamp Reply MUST be the same as the specific-destination address of the corresponding Timestamp Request message.
4. 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, unless the router is aware of policy that would prevent the delivery of the message.I
5. f 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.
6. 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:

1. 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).
2. The accuracy of a standard value MUST approximate that of operator-set CPU clocks, i.e., correct within a few minutes.
   

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.
Address Mask Request/Reply

1. A router MUST implement support for receiving ICMP Address Mask Request messages and responding with ICMP Address Mask Reply messages.
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.
3. A router MUST NOT respond to an Address Mask Request before the router knows the correct address mask.
4. A router MUST NOT respond to an Address Mask Request that has a source address of 0.0.0.0 and which arrives on a physical interface that has associated with it multiple logical interfaces and the address masks for those interfaces are not all the same.
5. A router SHOULD examine all ICMP Address Mask Replies that it receives to determine whether the information it contains matches the router’s knowledge of the address mask. If the ICMP Address Mask Reply appears to be in error, the router SHOULD log the address mask and the sender’s IP address.
6. A router MUST NOT use the contents of an ICMP Address Mask Reply to determine the correct address mask.
   Because hosts may not be able to learn the address 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 address masks.

However, this feature can be dangerous in environments that use variable length address masks.
Therefore, if this feature is implemented, gratuitous Address Mask Replies MUST NOT be broadcast over any logical interface(s) which either:

1. 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.
2. Share subsuming (but not identical) network prefixes and physical interface. The { <Network-prefix>, -1 } form of the IP broadcast address MUST be used for broadcast Address Mask Replies.
   

FORWARDING WALK-THROUGH
we merely point out the order dependencies among the steps:

1. A router MUST verify the IP header 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. 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
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.
   

This forwarding 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) from the Link Layer.
2. The router validates the IP header. 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.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 to determine how it should continue to process the IP datagram. There are three possibilities:
   
   1. The IP datagram is destined for the router, and should be queued for local delivery, doing reassembly if needed.
   2. The IP datagram is not destined for the router, and should be queued for forwarding.
   3. The IP datagram should be queued for forwarding, but (a copy) must also be queued for local delivery.
5. If the destination is an IP unicast address:
   
   1. 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 also decides which network interface should be used to send the packet.
   2. The forwarder verifies that forwarding the packet is permitted.
      The source and destination addresses should be valid, If the router supports administrative constraints on forwarding those constraints must be satisfied.
   3. The forwarder decrements (by at least one) and checks the packet’s TTL
   4. The forwarder performs any IP option processing that could not be completed in step 3.
   5. The forwarder performs any necessary IP fragmentation. Since this step occurs after outbound interface selection (step 5.1), all fragments of the same datagram will be transmitted out the same interface.
   6. The forwarder determines the Link Layer address of the packet’s next hop. The mechanisms for doing this are Link Layerdependent
   7. 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.1.
   8. The forwarder sends an ICMP redirect if necessary
6. 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
   
   • IP multicasts are usually forwarded based on both the datagram’s source and destination IP addresses,
   • IP multicast uses an expanding ring search,
   • IP multicasts are forwarded as Link Level multicasts, and
   • 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.
   

   1. 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.
   2. Based on the IP source and destination addresses found in the datagram header, the router determines the datagram’s outgoing interfaces. To implement IP multicast’s expanding ring search  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.
   3. The router decrements the packet’s TTL by one.
   4. The forwarder performs any IP option processing that could not be completed in step (3).
   5. The forwarder performs any necessary IP fragmentation
   6. 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’ IP multicast address. See the various IP-over-xxx specifications for more details.
   7. 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.
      

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 be another version of IP, such as IPng or ST-II.
4. The IP header length field must be large enough to hold the minimum length legal IP datagram (20 bytes = 5 words).
5. The IP total length field must be large enough to hold the IP datagram header, whose length is specified in the IP header length field.
   

A router MUST NOT have a configuration option that allows disabling any of these tests.
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.
to determine why a header was invalid. There are four possible reasons:

1. The Link Layer truncated the IP header
2. The datagram is using a version of IP other than the standard one (version 4).
3. The IP header has been corrupted in transit.
4. The sender generated an illegal IP header.
   

It is probably desirable to perform the checks in the order listed, since we believe that this ordering is most likely to correctly categorize the cause of the error. For purposes of error reporting, it may also be desirable to check if a packet that fails these tests has an IP version number indicating IPng or ST-II; these should be handled according to their respective specifications.
Additionally, the router SHOULD verify that the packet length reported by the Link Layer is at least as large as the IP total length recorded in the packet’s IP header. If it appears that the packet has been truncated, the packet MUST be discarded, the error SHOULD be logged, and the router SHOULD respond with an ICMP Parameter Problem message whose pointer points at the IP total length field.
When a router receives an IP packet, it must decide whether the packet is addressed to the router (and should be delivered locally) or the packet is addressed to another system (and should be handled by the forwarder). There is also a hybrid case, where certain IP broadcasts and IP multicasts are both delivered locally and forwarded. A router MUST determine which of the these three cases applies using the following rules.

1. An unexpired source route option is one whose pointer value does not point past the last entry in the source route. If the packet contains an unexpired source route option, the pointer in the option is advanced until either the pointer does point past the last address in the option or else the next address is not one of the router’s own addresses. In the latter (normal) case, the packet is forwarded (and not delivered locally) regardless of the rules below.
2. The packet is delivered locally and not considered for forwarding in the following cases:
   
   • The packet’s destination address exactly matches one of the router’s IP addresses,
   • The packet’s destination address is a limited broadcast address ({-1, -1}), or
   • The packet’s destination is an IP multicast address which is never forwarded (such as 224.0.0.1 or 224.0.0.2) and (at least) one of the logical interfaces associated with the physical interface on which the packet arrived is a member of the destination multicast group.
3. The packet is passed to the forwarder AND delivered locally in the following cases:
   
   • The packet’s destination address is an IP broadcast address that addresses at least one of the router’s logical interfaces but does not address any of the logical interfaces associated with the physical interface on which the packet arrived
   • The packet’s destination is an IP multicast address which is permitted to be forwarded (unlike 224.0.0.1 and 224.0.0.2) and (at least) one of the logical interfaces associated with the physical interface on which the packet arrived is a member of the destination multicast group.
4. The packet is delivered locally if the packet’s destination address is an IP broadcast address (other than a limited broadcast address) that addresses at least one of the logical interfaces associated with the physical interface on which the packet arrived. The packet is ALSO passed to the forwarder unless the link on which the packet arrived uses an IP encapsulation that does not encapsulate broadcasts differently than unicasts (e.g., by using different Link Layer destination addresses).
   The purpose of the requirement in the last sentence is to deal with a directed broadcast to another network prefix on the same physical cable. Normally, this works as expected: the sender sends the broadcast to the router as a Link Layer unicast. The router notes that it arrived as a unicast, and therefore must be destined for a different network prefix than the sender sent it on. Therefore, the router can safely send it as a Link Layer broadcast out the same (physical) interface over which it arrived. However, if the router can’t tell whether the packet was received as a Link Layer unicast, the sentence ensures that the router does the safe but wrong thing rather than the unsafe but right thing.
   
   
5. The packet is passed to the forwarder in all other cases.
   

Determining the Next Hop Address
When a router is going to forward a packet, it must determine whether it can send it directly to its destination, or whether it needs to pass it through another router. If the latter, it needs to determine which router to use.

1. LSRR - IP Loose Source and Record Route option
2. SSRR - IP Strict Source and Record Route option
3. Source Route Option - an LSRR or an SSRR
4. Ultimate Destination Address - where the packet is being sent to:
   the last address in the source route of a source-routed packet, or the destination address in the IP header of a non-source-routed packet
5. Adjacent - reachable without going through any IP routers
6. Next Hop Address - the IP address of the adjacent host or router to which the packet should be sent next
7. IP Destination Address - the ultimate destination address, except in source routed packets, where it is the next address specified in the source route
8. Immediate Destination - the node, System, router, end-system, or whatever that is addressed by the IP Destination Address.
   

IP Destination Address
If:

1. the destination address in the IP header is one of the addresses of the router,
2. the packet contains a Source Route Option, and
3. the pointer in the Source Route Option does not point past the end of the option,
   

then the next IP Destination Address is the address pointed at by the pointer in that option.

If:

1. the destination address in the IP header is one of the addresses of the router,
2. the packet contains a Source Route Option, and
3. the pointer in the Source Route Option points past the end of the option,
   

then the message is addressed to the system analyzing the message.
A router MUST use the IP Destination Address, not the Ultimate Destination Address (the last address in the source route option), when determining how to handle a packet.
It is an error for more than one source route option to appear in a datagram. If it receives such a datagram, it SHOULD discard the packet and reply with an ICMP Parameter Problem message whose pointer points at the beginning of the second source route option.
Local/Remote Decision
the following algorithm MUST be used to determine if the Immediate Destination is directly accessible

1. For each network interface that has not been assigned any IP address (the unnumbered lines), compare the router-id of the other end of the line to the IP Destination Address. If they are exactly equal, the packet can be transmitted through this interface.
   In other words, the router or host at the remote end of the line is the destination of the packet or is the next step in the source route of a source routed packet.
2. If no network interface has been selected in the first step, for each IP address assigned to the router:
   
   1. isolate the network prefix used by the interface.
      The result of this operation will usually have been computed and saved during initialization.
   2. Isolate the corresponding set of bits from the IP Destination Address of the packet.
   3. Compare the resulting network prefixes. If they are equal to each other, the packet can be transmitted through the corresponding network interface.
3. If the destination was neither the router-id of a neighbor on an unnumbered interface nor a member of a directly connected network prefix, the IP Destination is accessible only through some other router.
   In the case of a host that is not also a router, this may be the configured default router.Barring policy restrictions, hosts and routers using a common link layer network can directly communicate even if they are not in the same IP (sub)network, if there is adequate information present. The Next Hop Routing Protocol (NHRP) enables IP entities to determine the "optimal" link layer address to be used to traverse such a link layer network towards a remote destination.
4. If the selected "next hop" is reachable through an interface configured to use NHRP, then the following additional steps apply:
   
   1. Compare the IP Destination Address to the destination addresses in the NHRP cache. If the address is in the cache, then send the datagram to the corresponding cached link layer address.
   2. If the address is not in the cache, then construct an NHRP request packet containing the IP Destination Address. This message is sent to the NHRP server configured for that interface. This may be a logically separate process or entity in the router itself.
   3. The NHRP server will respond with the proper link layer address to use to transmit the datagram and subsequent datagrams to the same destination. The system MAY transmit the datagram(s) to the traditional "next hop" router while awaiting the NHRP reply.
      

Next Hop Address
EDITORS+COMMENTS
If the packet contains an SSRR, the router MUST discard the packet and reply with an ICMP Bad Source Route error. Otherwise, the router looks up the IP Destination Address in its routing table to determine an appropriate next hop address.
Per the IP specification, a Strict Source Route must specify a sequence of nodes through which the packet must traverse; the packet must go from one node of the source route to the next, traversing intermediate networks only. Thus, if the router is not adjacent to the next step of the source route, the source route can not be fulfilled. Therefore, the router rejects such with an ICMP Bad Source Route error.
The goal of the next-hop selection process is to examine the entries in the router’s Forwarding Information Base (FIB) and select the best route (if there is one) for the packet from those available in the FIB.

1. Basic Match
   This rule discards any routes to destinations other than the IP Destination Address of the packet.
   For example, if a packet’s IP Destination Address is 10.144.2.5, this step would discard a route to net 128.12.0.0/16 but would retain any routes to the network prefixes 10.0.0.0/8 and 10.144.0.0/16, and any default routes.
   More precisely, we assume that each route has a destination attribute, called route.dest and a corresponding prefix length, called route.length, to specify which bits of route.dest are significant. The IP Destination Address of the packet being forwarded is ip.dest. This rule discards all routes from the set of candidates except those for which the most significant route.length bits of route.dest and ip.dest are equal.
   For example, if a packet’s IP Destination Address is 10.144.2.5 and there are network prefixes 10.144.1.0/24, 10.144.2.0/24, and 10.144.3.0/24, this rule would keep only 10.144.2.0/24; it is the only route whose prefix has the same value as the corresponding bits in the IP Destination Address of the packet.
2. Longest Match
   Longest Match is a refinement of Basic Match, described above. After performing Basic Match pruning, the algorithm examines the remaining routes to determine which among them have the largest route.length values. All except these are discarded.
   For example, if a packet’s IP Destination Address is 10.144.2.5 and there are network prefixes 10.144.2.0/24, 10.144.0.0/16, and 10.0.0.0/8, then this rule would keep only the first (10.144.2.0/24) because its prefix length is longest.
3. Weak TOS
   Each route has a type of service attribute, called route.tos, whose possible values are assumed to be identical to those used in the TOS field of the IP header. Routing protocols that distribute TOS information fill in route.tos appropriately in routes they add to the FIB; routes from other routing protocols are treated as if they have the default TOS (0000). The TOS field in the IP header of the packet being routed is called ip.tos.
   The set of candidate routes is examined to determine if it contains any routes for which route.tos = ip.tos. If so, all routes except those for which route.tos = ip.tos are discarded. If not, all routes except those for which route.tos = 0000 are discarded from the set of candidate routes.
4. Best Metric
   Each route has a metric attribute, called route.metric, and a routing domain identifier, called route.domain. Each member of the set of candidate routes is compared with each other member of the set. If route.domain is equal for the two routes and route.metric is strictly inferior for one when compared with the other, then the one with the inferior metric is discarded from the set. The determination of inferior is usually by a simple arithmetic comparison, though some protocols may have structured metrics requiring more complex comparisons.
5. Vendor Policy
   Vendor Policy is sort of a catch-all to make up for the fact that the previously listed rules are often inadequate to choose from the possible routes. Vendor Policy pruning rules are extremely vendor-specific.
   

The Basic Match and Longest Match pruning rules generalize the treatment of a number of particular types of routes. These routes are selected in the following, decreasing, order of preference:

1. Host Route: This is a route to a specific end system.
2. Hierarchical Network Prefix Routes: This is a route to a particular network prefix. Note that the FIB may contain several routes to network prefixes that subsume each other (one prefix is the other prefix with additional bits). These are selected in order of decreasing prefix length.
3. Default Route: This is a route to all networks for which there are no explicit routes. It is by definition the route whose prefix length is zero.
   

If, after application of the pruning rules, the set of routes is empty (i.e., no routes were found), the packet MUST be discarded and an appropriate ICMP error generated (ICMP Bad Source Route if the IP Destination Address came from a source route option; otherwise, whichever of ICMP Destination Host Unreachable or Destination Network Unreachable is appropriate
Administrative Preference

1. Address Match
   It is useful to be able to assign a single preference value to all routes (learned from the same routing domain) to any of a specified set of destinations, where the set of destinations is all destinations that match a specified network prefix.
2. Route Class
   For routing protocols which maintain the distinction, it is useful to be able to assign a single preference value to all routes (learned from the same routing domain) which have a particular route class (intra-area, inter-area, external with internal metrics, or external with external metrics).
3. Interface
   It is useful to be able to assign a single preference value to all routes (learned from a particular routing domain) that would cause packets to be routed out a particular logical interface on the router (logical interfaces generally map one-to-one onto the router’s network interfaces, except that any network interface that has multiple IP addresses will have multiple logical interfaces associated with it).
4. Source router
   It is useful to be able to assign a single preference value to all routes (learned from the same routing domain) that were learned from any of a set of routers, where the set of routers are those whose updates have a source address that match a specified network prefix.
5. Originating AS
   For routing protocols which provide the information, it is useful to be able to assign a single preference value to all routes (learned from a particular routing domain) which originated in another particular routing domain. For BGP routes, the originating AS is the first AS listed in the route’s AS_PATH attribute. For OSPF external routes, the originating AS may be considered to be the low order 16 bits of the route’s external route tag if the tag’s Automatic bit is set and the tag’s Path Length is not equal to 3.
6. External route tag
   It is useful to be able to assign a single preference value to all OSPF external routes (learned from the same routing domain) whose external route tags match any of a list of specified values. Because the external route tag may contain a structured value, it may be useful to provide the ability to match particular subfields of the tag.
7. AS path
   It may be useful to be able to assign a single preference value to all BGP routes (learned from the same routing domain) whose AS path "matches" any of a set of specified values. It is not yet clear exactly what kinds of matches are most useful. A simple option would be to allow matching of all routes for which a particular AS number appears (or alternatively, does not appear) anywhere in the route’s AS_PATH attribute. A more general but somewhat more difficult alternative would be to allow matching all routes for which the AS path matches a specified regular expression.
   

A router MUST NOT reassemble any datagram before forwarding it.
Internet Control Message Protocol - ICMP
Destination Unreachable
The ICMP Destination Unreachable message is sent by a router in response to a packet which it cannot forward because the destination (or next hop) is unreachable or a service is unavailable. Examples of such cases include a message addressed to a host which is not there and therefore does not respond to ARP requests, and messages addressed to network prefixes for which the router has no valid route.
A router MUST be able to generate ICMP Destination Unreachable messages and SHOULD choose a response code that most closely matches the reason the message is being generated.
The following codes are defined:

• 0 = Network Unreachable - generated by a router if a forwarding path (route) to the destination network is not available;
• 1 = Host Unreachable - generated by a router if a forwarding path (route) to the destination host on a directly connected network is not available (does not respond to ARP);
• 2 = Protocol Unreachable - generated if the transport protocol designated in a datagram is not supported in the transport layer of the final destination;
• 3 = Port Unreachable - generated if the designated transport protocol (e.g., UDP) is unable to demultiplex the datagram in the transport layer of the final destination but has no protocol mechanism to inform the sender;
• 4 = Fragmentation Needed and DF Set - generated if a router needs to fragment a datagram but cannot since the DF flag is set;
• 5 = Source Route Failed - generated if a router cannot forward a packet to the next hop in a source route option;
• 6 = Destination Network Unknown - This code SHOULD NOT be generated since it would imply on the part of the router that the destination network does not exist (net unreachable code 0 SHOULD be used in place of code 6);
• 7 = Destination Host Unknown - generated only when a router can determine (from link layer advice) that the destination host does not exist;
• 11 = Network Unreachable For Type Of Service - generated by a router if a forwarding path (route) to the destination network with the requested or default TOS is not available;
• 12 = Host Unreachable For Type Of Service - generated if a router cannot forward a packet because its route(s) to the destination do not match either the TOS requested in the datagram or the default TOS (0).
  

The following additional codes are hereby defined:

• 13 = Communication Administratively Prohibited - generated if a router cannot forward a packet due to administrative filtering;
• 14 = Host Precedence Violation. Sent by the first hop router to a host to indicate that a requested precedence is not permitted for the particular combination of source/destination host or network, upper layer protocol, and source/destination port;
• 15 = Precedence cutoff in effect. The network operators have imposed a minimum level of precedence required for operation, the datagram was sent with a precedence below this level;
  

NOTE: Code 8 for source host isolated. Routers SHOULD NOT generate Code 8; whichever of Codes 0 (Network Unreachable) and 1 (Host Unreachable) is appropriate SHOULD be used instead.Code 9 for communication with destination network administratively prohibited and Code 10 for communication with destination host administratively prohibited.
These codes were intended for use by end-to-end encryption devices used by U.S military agencies. Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets.
Routers MAY have a configuration option that causes Code 13 (Communication Administratively Prohibited) messages not to be generated. When this option is enabled, no ICMP error message is sent in response to a packet that is dropped because its forwarding is administratively prohibited.
Similarly, routers MAY have a configuration option that causes Code 14 (Host Precedence Violation) and Code 15 (Precedence Cutoff in Effect) messages not to be generated. When this option is enabled, no ICMP error message is sent in response to a packet that is dropped because of a precedence violation.
Routers MUST use Host Unreachable or Destination Host Unknown codes whenever other hosts on the same destination network might be reachable; otherwise, the source host may erroneously conclude that all hosts on the network are unreachable, and that may not be the case.
a slight modification the form of Destination Unreachable messages containing Code 4 (Fragmentation needed and DF set). A router MUST use this modified form when originating Code 4 Destination Unreachable messages.
Redirect
The ICMP Redirect message is generated to inform a local host the it should use a different next hop router for a certain class of traffic.
Routers MUST NOT generate the Redirect for Network or Redirect for Network and Type of Service messages (Codes 0 and 2) specified in
Routers MUST be able to generate the Redirect for Host message (Code 1) and SHOULD be able to generate the Redirect for Type of Service and Host message (Code 3) specified in

If the directly connected network is not subnetted (in the classical sense), a router can normally generate a network Redirect that applies to all hosts on a specified remote network.
Using a network rather than a host Redirect may economize slightly on network traffic and on host routing table storage. However, the savings are not significant, and subnets create an ambiguity about the subnet mask to be used to interpret a network Redirect.
A Code 3 (Redirect for Host and Type of Service) message is generated when the packet provoking the redirect has a destination for which the path chosen by the router would depend (in part) on the TOS requested.
Routers that can generate Code 3 redirects (Host and Type of Service) MUST have a configuration option (which defaults to on) to enable Code 1 (Host) redirects to be substituted for Code 3 redirects. A router MUST send a Code 1 Redirect in place of a Code 3 Redirect if it has been configured to do so.
If a router is not able to generate Code 3 Redirects then it MUST generate Code 1 Redirects in situations where a Code 3 Redirect is called for.
Routers MUST NOT generate a Redirect Message unless all the following conditions are met:

• The packet is being forwarded out the same physical interface that it was received from,
• The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and
• The packet does not contain an IP source route option. The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address.
  

A router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. If a router is not using a routing protocol, a router MAY have a configuration that, if set, allows the router to consider routes learned through ICMP Redirects when forwarding packets.
Time Exceeded
A router MUST generate a Time Exceeded message Code 0 (In Transit) when it discards a packet due to an expired TTL field. A router MAY have a per-interface option to disable origination of these messages on that interface, but that option MUST default to allowing the messages to be originated.
Time to Live (TTL)
If the TTL is reduced to zero (or less), the packet MUST be discarded, and if the destination is not a multicast address the router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded in Transit) message to the source. Note that a router MUST NOT discard an IP unicast or broadcast packet with a non-zero TTL merely because it can predict that another router on the path to the packet’s final destination will decrement the TTL to zero. However, a router MAY do so for IP multicasts, in order to more efficiently
IP multicast notions such as the expanding ring search may not work as expected unless the TTL is treated as a pure hop count. The same thing is somewhat true of traceroute.
ICMP Time Exceeded messages are required because the traceroute diagnostic tool depends on them.
Type of Service (TOS)
A router MUST maintain a TOS value for each route in its routing table. Routes learned through a routing protocol that does not support TOS MUST be assigned a TOS of zero (the default TOS).
To choose a route to a destination, a router MUST use an algorithm equivalent to the following:

1. The router locates in its routing table all available routes to the destination
2. If there are none, the router drops the packet because the destination is unreachable.
3. If one or more of those routes have a TOS that exactly matches the TOS specified in the packet, the router chooses the route with the best metric.
4. Otherwise, the router repeats the above step, except looking at routes whose TOS is zero.
5. If no route was chosen above, the router drops the packet because the destination is unreachable. The router returns an ICMP Destination Unreachable error specifying the appropriate code: either Network Unreachable with Type of Service (code 11) or Host Unreachable with Type of Service (code 12).
   

Various people have proposed that TOS should affect other aspects of the forwarding function. For example:

1. A router could place packets that have the Low Delay bit set ahead of other packets in its output queues.
2. a router is forced to discard packets, it could try to avoid discarding those which have the High Reliability bit set.
   

Precedence-Ordered Queue Service
Routers SHOULD implement precedence-ordered queue service.
Precedence-ordered queue service means that when a packet is selected for output on a (logical) link, the packet of highest precedence that has been queued for that link is sent.

Routers that implement precedence-ordered queue service MUST also have a configuration option to suppress precedence-ordered queue service in the Internet Layer.
Lower Layer Precedence Mappings
Routers that implement precedence-ordered queuing MUST IMPLEMENT, and other routers SHOULD IMPLEMENT, Lower Layer Precedence Mapping.
A router that implements Lower Layer Precedence Mapping:

• MUST be able to map IP Precedence to Link Layer priority mechanisms for link layers that have such a feature defined.
• MUST have a configuration option to select the Link Layer’s default priority treatment for all IP traffic
• SHOULD be able to configure specific nonstandard mappings of IP precedence values to Link Layer priority values for each interface.
  

Precedence Handling For All Routers
A router (whether or not it employs precedence-ordered queue service):

1. MUST accept and process incoming traffic of all precedence levels normally, unless it has been administratively configured to do otherwise.
2. MAY implement a validation filter to administratively restrict the use of precedence levels by particular traffic sources. If provided, this filter MUST NOT filter out or cut off the following sorts of ICMP error messages: Destination Unreachable, Redirect, Time Exceeded, and Parameter Problem. If this filter is provided, the procedures required for packet filtering by addresses are required for this filter also.
   Precedence filtering should be applicable to specific source/destination IP Address pairs, specific protocols, specific ports, and so on.
   An ICMP Destination Unreachable message with code 14 SHOULD be sent when a packet is dropped by the validation filter, unless this has been suppressed by configuration choice.
3. MAY implement a cutoff function that allows the router to be set to refuse or drop traffic with precedence below a specified level. This function may be activated by management actions or by some implementation dependent heuristics, but there MUST be a configuration option to disable any heuristic mechanism that operates without human intervention. An ICMP Destination Unreachable message with code 15 SHOULD be sent when a packet is dropped by the cutoff function, unless this has been suppressed by configuration choice.
   A router MUST NOT refuse to forward datagrams with IP precedence of 6 (Internetwork Control) or 7 (Network Control) solely due to precedence cutoff. However, other criteria may be used in conjunction with precedence cutoff to filter high precedence traffic.
   Unrestricted precedence cutoff could result in an unintentional cutoff of routing and control traffic. In the general case, host traffic should be restricted to a value of 5 (CRITIC/ECP) or below; this is not a requirement and may not be correct in certain systems.
4. MUST NOT change precedence settings on packets it did not originate.
5. SHOULD be able to configure distinct precedence values to be used for each routing or management protocol supported (except for those protocols, such as OSPF, which specify which precedence value must be used).
6. MAY be able to configure routing or management traffic precedence values independently for each peer address.
7. MUST respond appropriately to Link Layer precedence-related error indications where provided. An ICMP Destination Unreachable message with code 15 SHOULD be sent when a packet is dropped because a link cannot accept it due to a precedence-related condition, unless this has been suppressed by configuration choice.
   

The precedence cutoff mechanism described in (3) is somewhat controversial. Depending on the topological location of the area affected by the cutoff, transit traffic may be directed by routing protocols into the area of the cutoff, where it will be dropped.
This is only a problem if another path that is unaffected by the cutoff exists between the communicating points. Proposed ways of avoiding this problem include providing some minimum bandwidth to all precedence levels even under overload conditions, or propagating cutoff information in routing protocols. In the absence of a widely accepted (and implemented) solution to this problem, great caution is recommended in activating cutoff mechanisms in transit networks.
A transport layer relay could legitimately provide the function prohibited by (4) above. Changing precedence levels may cause subtle interactions with TCP and perhaps other protocols; a correct design is a non-trivial task.
The intent of (5) and (6) (and the discussion of IP Precedence in ICMP messages in Section [4.3.2]) is that the IP precedence bits should be appropriately set, whether or not this router acts upon those bits in any other way. We expect that in the future specifications for routing protocols and network management protocols will specify how the IP Precedence should be set for messages sent by those protocols.
The appropriate response for (7) depends on the link layer protocol in use. Typically, the router should stop trying to send offensive traffic to that destination for some period of time, and should return an ICMP Destination Unreachable message with code 15 (service not available for precedence requested) to the traffic source. It also should not try to reestablish a preempted Link Layer connection for some time.

Forwarding of Link Layer Broadcasts

1. A router MUST NOT forward any packet that the router received as a Link Layer broadcast, unless it is directed to an IP Multicast address.
2. A router MUST NOT forward any packet which the router received as a Link Layer multicast unless the packet’s destination address is an IP multicast address.
3. A router SHOULD silently discard a packet that is received via a Link Layer broadcast but does not specify an IP multicast or IP broadcast destination address.
4. When a router sends a packet as a Link Layer broadcast, the IP destination address MUST be a legal IP broadcast or IP multicast address.
   

Forwarding of Internet Layer Broadcasts
There are two major types of IP broadcast addresses; limited broadcast and directed broadcast. In addition, there are three subtypes of directed broadcast: a broadcast directed to a specified network prefix, a broadcast directed to a specified subnetwork, and a broadcast directed to all subnets of a specified network.
Classification by a router of a broadcast into one of these categories depends on the broadcast address and on the router’s understanding (if any) of the subnet structure of the destination network. The same broadcast will be classified differently by different routers.
A limited IP broadcast address is defined to be all-ones: { -1, -1 } or 255.255.255.255.
A network-prefix-directed broadcast is composed of the network prefix of the IP address with a local part of all-ones or { <Networkprefix>, -1 }. For example, a Class A net broadcast address is net.255.255.255, a Class B net broadcast address is net.net.255.255 and a Class C net broadcast address is net.net.net.255 where net is a byte of the network address.
A router may encounter certain non-standard IP broadcast addresses:

• 0.0.0.0 is an obsolete form of the limited broadcast address
• { <Network-prefix>, 0 } is an obsolete form of a network-prefixdirected broadcast address.
  

packets addressed to any of these addresses SHOULD be silently discarded, but if they are not, they MUST be treated according to the same rules that apply to packets addressed to the non-obsolete forms of the broadcast addresses described above.
Limited Broadcasts
Limited broadcasts MUST NOT be forwarded. Limited broadcasts MUST NOT be discarded. Limited broadcasts MAY be sent and SHOULD be sent instead of directed broadcasts where limited broadcasts will suffice.
Directed Broadcasts
a router MUST forward networkprefix-directed broadcasts. Network-Prefix-Directed broadcasts MAY be sent.
A router MAY have an option to disable receiving network-prefixdirected broadcasts on an interface and MUST have an option to disable forwarding network-prefix-directed broadcasts. These options MUST default to permit receiving and forwarding network-prefixdirected broadcasts.

Martian Address Filtering

1. An IP source address is invalid if it is a special IP address, as defined in 4.2.2.11 or 5.3.7, or is not a unicast address.
2. An IP destination address is invalid if it is among those defined as illegal destinations in 4.2.3.1, or is a Class E address (except 255.255.255.255).
3. A router SHOULD NOT forward any packet that has an invalid IP source address or a source address on network 0.
4. A router SHOULD NOT forward, except over a loopback interface, any packet that has a source address on network 127.
5. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.
6. A router SHOULD NOT forward any packet that has an invalid IP destination address or a destination address on network 0.
   

If a router discards a packet because of these rules, it SHOULD log at least the IP source address, the IP destination address, and, if the problem was with the source address, the physical interface on which the packet was received and the Link Layer address of the host or router from which the packet was received.

Source Address Validation
A router SHOULD IMPLEMENT the ability to filter traffic based on a comparison of the source address of a packet and the forwarding table for a logical interface on which the packet was received.

If this filtering is enabled, the router MUST silently discard a packet if the interface on which the packet was received is not the interface on which a packet would be forwarded to reach the address contained in the source address.

In simpler terms, if a router wouldn’t route a packet containing this address through a particular interface, it shouldn’t believe the address if it appears as a source address in a packet read from this interface.
If this feature is implemented, it MUST be disabled by default.
If supported, a router SHOULD be configurable to allow one of an

• Include list - specification of a list of message definitions to be forwarded, or an
• Exclude list - specification of a list of message definitions NOT to be forwarded.
  

A "message definition", in this context, specifies the source and destination network prefix, and may include other identifying information such as IP Protocol Type or TCP port number.
A value matching any address (e.g., a keyword any, an address with a mask of all 0’s, or a network prefix whose length is zero) MUST be allowed as a source and/or destination address.
In addition to address pairs, the router MAY allow any combination of transport and/or application protocol and source and destination ports to be specified.
The router MUST allow packets to be silently discarded (i.e., discarded without an ICMP error message being sent).
The router SHOULD allow an appropriate ICMP unreachable message to be sent when a packet is discarded. The ICMP message SHOULD specify Communication Administratively Prohibited (code 13) as the reason for the destination being unreachable.
The router SHOULD allow the sending of ICMP destination unreachable messages (code 13) to be configured for each combination of address pairs, protocol types, and ports it allows to be specified.
The router SHOULD count and SHOULD allow selective logging of packets not forwarded.
For each physical interface, a router SHOULD have a configuration option that specifies whether forwarding is enabled on that interface. When forwarding on an interface is disabled, the router:

• MUST silently discard any packets which are received on that interface but are not addressed to the router
• MUST NOT send packets out that interface, except for datagrams originated by the router
• MUST NOT announce via any routing protocols the availability of paths through the interface
  

State Changes

1. When a Router Ceases Forwarding
   When a router ceases forwarding it MUST stop advertising all routes, except for third party routes. It MAY continue to receive and use routes from other routers in its routing domains. If the forwarding database is retained, the router MUST NOT cease timing the routes in the forwarding database. If routes that have been received from other routers are remembered, the router MUST NOT cease timing the routes that it has remembered. It MUST discard any routes whose timers expire while forwarding is disabled, just as it would do if forwarding were enabled.
   When a router ceases forwarding, it essentially ceases being a router. The router may still be a passive member of one or more routing domains, however. As such, it is allowed to maintain its forwarding database by listening to other routers in its routing domain. It may not, however, advertise any of the routes in its forwarding database, since it itself is doing no forwarding. The only exception to this rule is when the router is advertising a route that uses only some other router, but which this router has been asked to advertise.
   A router MAY send ICMP destination unreachable (host unreachable) messages to the senders of packets that it is unable to forward. It SHOULD NOT send ICMP redirect messages.
   Note that sending an ICMP destination unreachable (host unreachable) is a router action. This message should not be sent by hosts. This exception to the rules for hosts is allowed so that packets may be rerouted in the shortest possible time, and so that black holes are avoided.
2. When a Router Starts Forwarding
   When a router begins forwarding, it SHOULD expedite the sending of new routing information to all routers with which it normally exchanges routing information.
3. When an Interface Fails or is Disabled
   If an interface fails or is disabled a router MUST remove and stop advertising all routes in its forwarding database that make use of that interface. It MUST disable all static routes that make use of that interface. If other routes to the same destination and TOS are learned or remembered by the router, the router MUST choose the best alternate, and add it to its forwarding database. The router SHOULD send ICMP destination unreachable or ICMP redirect messages, as appropriate, in reply to all packets that it is unable to forward due to the interface being unavailable.
4. When an Interface is Enabled
   If an interface that had not been available becomes available, a router MUST reenable any static routes that use that interface. If routes that would use that interface are learned by the router, then these routes MUST be evaluated along with all the other learned routes, and the router MUST make a decision as to which routes should be placed in the forwarding database.
   A router SHOULD expedite the sending of new routing information to all routers with which it normally exchanges routing information.

STATIC ROUTING
Static routing provides a means of explicitly defining the next hop from a router for a particular destination. A router SHOULD provide a means for defining a static route to a destination, where the destination is defined by a network prefix. The mechanism SHOULD also allow for a metric to be specified for each static route.
A router that supports a dynamic routing protocol MUST allow static routes to be defined with any metric valid for the routing protocol used. The router MUST provide the ability for the user to specify a list of static routes that may or may not be propagated through the routing protocol. In addition, a router SHOULD support the following additional information if it supports a routing protocol that could make use of the information. They are:

1. TOS,
2. Subnet Mask, or
3. Prefix Length, or
4. A metric specific to a given routing protocol that can import the route.
   

A router MUST allow a metric to be assigned to a static route for each routing domain that it supports. Each such metric MUST be explicitly assigned to a specific routing domain. For example:

route 10.0.0.0/8 via 192.0.2.3 rip metric 3
route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27
route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99

For static routes not put into a specific routing domain, the route lookup algorithm is:

1. Basic match
2. Longest match
3. Weak TOS (if TOS supported)
4. Best metric (where metric are implementation-defined)
   

The last step may not be necessary, but it’s useful in the case where you want to have a primary static route over one interface and a secondary static route over an alternate interface, with failover to the alternate path if the interface for the primary route fails.

If the data flow through a network is to be as efficient as possible, it is necessary to provide a mechanism for controlling the propagation of the information a router uses to build its forwarding database. This control takes the form of choosing which sources of routing information should be trusted and selecting which pieces of the information to believe. The resulting forwarding database is a filtered version of the available routing information.
In addition to efficiency, controlling the propagation of routing information can reduce instability by preventing the spread of incorrect or bad routing information.
Route Validation
A router SHOULD log as an error any routing update advertising a route that violates the specifications of this memo, unless the routing protocol from which the update was received uses those values to encode special routes (such as default routes).
Basic Route Filtering
Filtering of routing information allows control of paths used by a router to forward packets it receives. A router should be selective in which sources of routing information it listens to and what routes it believes. Therefore, a router MUST provide the ability to specify:

• On which logical interfaces routing information will be accepted and which routes will be accepted from each logical interface.
• Whether all routes or only a default route is advertised on a logical interface.
  Some routing protocols do not recognize logical interfaces as a source of routing information. In such cases the router MUST provide the ability to specify
• from which other routers routing information will be accepted.
  

For example, assume a router connecting one or more leaf networks to the main portion or backbone of a larger network. Since each of the leaf networks has only one path in and out, the router can simply send a default route to them. It advertises the leaf networks to the main network.
Advanced Route Filtering
As the topology of a network grows more complex, the need for more complex route filtering arises. Therefore, a router SHOULD provide the ability to specify independently for each routing protocol:

• Which logical interfaces or routers routing information (routes) will be accepted from and which routes will be believed from each other router or logical interface,
• Which routes will be sent via which logical interface(s), and
• Which routers routing information will be sent to, if this is supported by the routing protocol in use.
  In many situations it is desirable to assign a reliability ordering to routing information received from another router instead of the simple believe or don’t believe choice listed in the first bullet above. A router MAY provide the ability to specify:
• A reliability or preference to be assigned to each route received. A route with higher reliability will be chosen over one with lower reliability regardless of the routing metric associated with each route.
  

If a router supports assignment of preferences, the router MUST NOT propagate any routes it does not prefer as first party information. If the routing protocol being used to propagate the routes does not support distinguishing between first and third party information, the router MUST NOT propagate any routes it does not prefer.
For example, assume a router receives a route to network C from router R and a route to the same network from router S. If router R is considered more reliable than router S traffic destined for network C will be forwarded to router R regardless of the route received from router S.
Routing information for routes which the router does not use (router S in the above example) MUST NOT be passed to any other router.
Router Initialization
Minimum Router Configuration
There exists a minimum set of conditions that must be satisfied before a router may forward packets. A router MUST NOT enable forwarding on any physical interface unless either:

1. The router knows the IP address and associated subnet mask or network prefix length of at least one logical interface associated with that physical interface, or
2. The router knows that the interface is an unnumbered interface and knows its router-id.
   These parameters MUST be explicitly configured:
   
   • A router MUST NOT use factory-configured default values for its IP addresses, prefix lengths, or router-id, and
   • A router MUST NOT assume that an unconfigured interface is an unnumbered interface.
     

Address and Prefix Initialization
A router MUST allow its IP addresses and their address masks or prefix lengths to be statically configured and saved in non-volatile storage.
A router MAY obtain its IP addresses and their corresponding address masks dynamically as a side effect of the system initialization process
If the dynamic method is provided, the choice of method to be used in a particular router MUST be configurable.
IP addresses are not permitted to have the value 0 or -1 in the <Host-number> or <Network-prefix> fields. Therefore, a router SHOULD NOT allow an IP address or address mask to be set to a value that would make any of the these fields above have the value zero or -1.
It is possible using arbitrary address masks to create situations in which routing is ambiguous (i.e., two routes with different but equally specific subnet masks match a particular destination address). This is one of the strongest arguments for the use of network prefixes, and the reason the use of discontiguous subnet masks is not permitted.
A router SHOULD make the following checks on any address mask it installs:

• The mask is neither all ones nor all zeroes (the prefix length is neither zero nor 32).
• The bits which correspond to the network prefix part of the address are all set to 1.
• The bits that correspond to the network prefix are contiguous.
  

The masks associated with routes are also sometimes called subnet masks, this test should not be applied to them.