9.5 ICMP Redirect Errors

The ICMP redirect error is sent by a router to the sender of an IP datagram when the datagram should have been sent to a different router. The concept is simple, as we show in the three steps in Figure 9.3. The only time we'll see an ICMP redirect is when the host has a choice of routers to send the packet to. (Recall the earlier example of this we saw in Figure 7.6.)

Figure 9.3. Example of an ICMP redirect.

We assume that the host sends an IP datagram to R1. This routing decision is often made because R1 is the default router for the host.
R1 receives the datagram and performs a lookup in its routing table and determines that R2 is the correct next -hop router to send the datagram to. When it sends the datagram to R2, R1 detects that it is sending it out the same interface on which the datagram arrived (the LAN to which the host and the two routers are attached). This is the clue to a router that a redirect can be sent to the original sender.
R1 sends an ICMP redirect to the host, telling it to send future datagrams to that destination to R2, instead of R1.

A common use for redirects is to let a host with minimal routing knowledge build up a better routing table over time. The host can start with only a default route (either R1 or R2 from our example in Figure 9.3) and anytime this default turns out to be wrong, it'll be informed by that default router with a redirect, allowing the host to update its routing table accordingly . ICMP redirects allow TCP/IP hosts to be dumb when it comes to routing, with all the intelligence in the routers. Obviously R1 and R2 in our example have to know more about the topology of the attached networks, but all the hosts attached to the LAN can start with a default route and learn more as they receive redirects.

An Example

We can see ICMP redirects in action on our network (inside front cover). Although we show only three hosts ( aix, solaris, and gemini ) and two routers ( gateway and netb ) on the top network, there are more than 150 hosts and 10 other routers on this network. Most of the hosts specify gateway as the default router, since it provides access to the Internet.

How is the author's subnet (the bottom four hosts in the figure) accessed from the hosts on the 140.252.1 subnet? First recall that if only a single host is at the end of the SLIP link, proxy ARP is used (Section 4.6). This means nothing special is required for hosts on the top network (140.252.1) to access the host sun (140.252.1.29). The proxy ARP software in netb handles this.

When a network is at the other end of the SLIP link, however, routing becomes involved. One solution is for every host and router to know that the router netb is the gateway for the network 140.252.13. This could be done by either a static route in each host's routing table, or by running a routing daemon in each host. A simpler way (and the method actually used) is to utilize ICMP redirects.

Let's run the ping program from the host solaris on the top network to the host bsdi (140.252.13.35) on the bottom network. Since the subnet IDs are different, proxy ARP can't be used. Assuming a static route has not been installed, the first packet sent will use the default route to the router gateway. Here is the routing table before we run ping:

 solaris %  netstat -rn  Routing Table:       Destination       Gateway         Flags Ref   Use    Interface     ----------------- ----------------- ----- ----- ------ ----------     127.0.0.1         127.0.0.1          UH       0    848  lo0     140.252.1.0       140.252.1.32       U        3  15042  le0     224.0.0.0         140.252.1.32       U        3      0  le0     default           140.252.1.4        UG       0   5747

(The entry for 224.0.0.0 is for IP multicasting. We describe it in Chapter 12.) If we specify the -v option to ping, we'll see any ICMP messages received by the host. We need to specify this to see the redirect message that's sent.

 solaris %  ping -sv bsdi  PING bsdi: 56 data bytes     ICMP Host redirect from gateway gateway (140.252.1.4)      to netb (140.252.1.183) for bsdi (140.252.13.35)     64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=383. ms     64 bytes from bsdi (140.252.13.35): icmp__seq=l. time=364. ms     64 bytes from bsdi (140.252.13.35): icmp__seq=2. time=353. ms  ^?   type interrupt key to stop  ----bsdi PING Statistics----     4 packets transmitted, 3 packets received, 25% packet loss      round-trip (ms) min/avg/max = 353/366/383

Before we receive the first ping response, the host receives an ICMP redirect from the default router gateway. If we then look at the routing table, we'll see that the new route to the host bsdi has been inserted. (This new entry is shown in a bolder font.)

 solaris %  netstat -rn  Routing Table:       Destination        Gateway        Flags  Ref   Use   Interface     ----------------- ----------------- ----- ----- ------ ----------     127.0.0.1         127.0.0.1          UH       0    848  lo0  140.252.13.35     140.252.1.183      UGHD     0      2  140.252.1.0       140.252.1.32       U        3  15045  le0     224.0.0.0         140.252.1.32       U        3      0  le0     default           140.252.1.4        UG       0   5749

This is the first time we've seen the D flag, which means the route was installed by an ICMP redirect. The G flag means it's an indirect route to a gateway ( netb ), and the H flag means it's a host route (as we expect), not a network route.

Since this is a host route, added by a host redirect, it handles only the host bsdi. If we then access the host svr4, another redirect is generated, creating another host route. Similarly, accessing the host slip creates another host route. The point here is that each redirect is for a single host, causing a host route to be added. All three hosts on the author's subnet ( bsdi, svr4, and slip ) could also be handled by a single networkroute pointing to the router sun. But ICMP redirects create host routes, not network routes, because the router generating the redirect in this example ( gateway ) has no knowledge of the subnet structure on the 140.252.13 network.

More Details

Figure 9.4 shows the format of the ICMP redirect message.

Figure 9.4. ICMP redirect message.

There are four different redirect messages, with different code values, as shown in Figure 9.5.

Figure 9.5. Different code values for IcMP redirect.

There are three IP addresses that the receiver of an ICMP redirect must look at: (1) the IP address that caused the redirect (which is in the IP header returned as the data portion of the ICMP redirect), (2) the IP address of the router that sent the redirect (which is the source IP address of the IP datagram containing the redirect), and (3) the IP address of the router that should be used (which is in bytes 4-7 of the ICMP message).

There are numerous rules about ICMP redirects. First, redirects are generated only by routers, not by hosts. Also, redirects are intended to be used by hosts, not routers. It is assumed that routers participate in a routing protocol with other routers, and the routing protocol should obviate the need for redirects. (This means that in Figure 9.1 the routing table should be updated by either a routing daemon or redirects, but not by both.)

4.4BSD, when acting as a router, performs the following checks, all of which must be true before an ICMP redirect is generated.

The outgoing interface must equal the incoming interface.
The route being used for the outgoing datagram must not have been created or modified by an ICMP redirect, and must not be the router's default route.
The datagram must not be source routed.
The kernel must be configured to send redirects.

The kernel variable is named ip_sendredirects, or something similar. (See Appendix E.) Most current systems (4.4BSD, SunOS 4.1.x, Solaris 2.x, and AIX 3.2.2, for example) enable this variable by default. Other systems such as SVR4 disable it by default.

Additionally, a 4.4BSD host that receives an ICMP redirect performs some checks before modifying its routing table. These are to prevent a misbehaving router or host, or a malicious user , from incorrectly modifying a system's routing table.

The new router must be on a directly connected network.
The redirect must be from the current router for that destination.
The redirect cannot tell the host to use itself as the router.
The route that's being modified must be an indirect route.

Our final point about redirects is that routers should send only host redirects ( code s 1 or 3 from Figure 9.5) and not network redirects. Subnetting makes it hard to specify exactly when a network redirect can be sent instead of a host redirect. Some hosts treat a received network redirect as a host redirect, in case a router sends the wrong type.