7.3 IP Record Route Option

7.3 IP Record Route Option

The ping program gives us an opportunity to look at the IP record route (RR) option. Most versions of ping provide the -R option that enables the record route feature. It causes ping to set the IP RR option in the outgoing IP datagram (which contains the ICMP echo request message). This causes every router that handles the datagram to add its IP address to a list in the options field. When the datagram reaches the final destination, the list of IP addresses should be copied into the outgoing ICMP echo reply, and all the routers on the return path also add their IP addresses to the list. When ping receives the echo reply it prints the list of IP addresses.

As simple as this sounds, there are pitfalls. Generation of the RR option by the source host, processing of the RR option by the intermediate routers, and reflection of the incoming RR list in an ICMP echo request into the outgoing ICMP echo reply are all optional features. Fortunately, most systems today do support these optional features, but some systems don't reflect the IP list.

The biggest problem, however, is the limited room in the IP header for the list of IP addresses. We saw in Figure 3.1 that the header length in the IP header is a 4-bit field, limiting the entire IP header to 15 32-bit words (60 bytes). Since the fixed size of the IP header is 20 bytes, and the RR option uses 3 bytes for overhead (which we describe below), this leaves 37 bytes (60 - 20 - 3) for the list, allowing up to nine IP addresses. In the early days of the ARPANET, nine IP addresses seemed like a lot, but since this is a round-trip list (in the case of the -R option for ping ), it's of limited use today. (In Chapter 8 we'll look at the Traceroute tool for determining the route followed by a datagram.) Despite these shortcomings, the record route option works and provides an opportunity to look in detail at the handling of IP options.

Figure 7.3 shows the general format of the RR option in the IP datagram.

Figure 7.3. General format of record route option in IP header.

Code is a 1-byte field specifying the type of IP option. For the RR option its value is 7. Len is the total number of bytes of the RR option, which in this case is 39. (Although it's possible to specify an RR option with less than the maximum size, ping always provides a 39-byte option field, to record up to nine IP addresses. Given the limited room in the IP header for options, it doesn't make sense to specify a size less than the maximum.)

Ptr is called the pointer field. It is a 1-based index into the 39-byte option of where to store the next IP address. Its minimum value is 4, which is the pointer to the first IP address. As each IP address is recorded into the list, the value of ptr becomes 8, 12, 16, up to 36. After the ninth address is recorded ptr becomes 40, indicating the list is full.

When a router (which by definition is multihomed ) records its IP address in the list, which IP address is recorded? It could be the address of the incoming interface or the outgoing interface. RFC 791 [Postel 1981a] specifies that the router records the outgoing IP address. We'll see that when the originating host (the host running ping ) receives the ICMP echo reply with the RR option enabled, it also records its incoming IP address in the list.

Normal Example

Let's run an example of the RR option with the ping program. We'll run ping on the host svr4 to the host slip. One intermediate router ( bsdi ) will handle the datagram. The following output is from svr4:

 svr4 %  ping R slip  PING slip (140.252.13.65): 56 data bytes    64 bytes from 140.252.13.65: icmp_seq=0 ttl=254 time=280 ms    RR:     bsdi (140.252.13.66)            slip (140.252.13.65)            bsdi (140.252.13.35)            svr4 (140.252.13.34)    64 bytes from 140.252.13.65: icmp_seq=l ttl=254 time=280 ms (same route)    64 bytes from 140.252.13.65: icmp_seq=2 ttl=254 time=270 ms (same route)  ^?  --- slip ping statistics ---    3 packets transmitted, 3 packets received, 0% packet loss    round-trip min/avg/max = 270/276/280 ms 

Figure 7.4 shows the four hops that the packets take (two in each direction), and which hop adds which IP address to the RR list.

Figure 7.4. ping with record route option.

The router bsdi adds a different IP address to the list in each direction. It always adds the IP address of the outgoing interface. We can also see that when the ICMP echo reply reaches the originating system ( svr4 ) it adds the IP address of the incoming interface to the list.

We can also watch this exchange of packets from the host sun, running tcpdump with its -v option (to see the IP options). Figure 7.5 shows the output.

Figure 7.5. tcpdump output of record route option.

The output optlen=40 indicates there are 40 bytes of option space in the IP header. (Recall that the length of the IP header must be a multiple of 4 bytes.) RR{39} means the record route option is present, and its length field is 39. The list of nine IP addresses is then shown, with a pound sign ( # ) indicating which IP address is pointed to by the ptr field in the RR option header. Since we are watching these packets on the host sun (see Figure 7.4) we only see the ICMP echo request with the empty list, and the ICMP echo reply with three addresses in the list. We have deleted the remaining lines in the tcpdump output, since they are nearly identical to what we show in Figure 7.5.

The notation EOL at the end of the record route information indicates the IP option "end of list" value appeared. The EOL option has a value of 0. What's happening is that 39 bytes of RR data are in the 40 bytes of option space in the IP header. Since the option space is set to 0 before the datagram is sent, this final byte of 0 that follows the 39 bytes of RR data is interpreted as an EOL. That is what we want to have happen. If there are multiple options in the option field of the IP header, and pad bytes are needed before the next option starts, the other special character NOP ("no operation"), with a value of 1, can be used.

In Figure 7.5, SVR4 sets the TTL field of the echo request to 32, and BSD/386 sets it to 255. (It prints as 254 since the router bsdi has already decremented it by one.) Newer systems are setting the TTL of ICMP messages to the maximum (255).

It turns out that of the three TCP/IP implementations used by the author, both BSD/386 and SVR4 support the record route option. That is, they correctly update the RR list when forwarding a datagram, and they correctly reflect the RR list from an incoming ICMP echo request to the outgoing ICMP echo reply. SunOS 4.1.3, however, updates the RR list when forwarding a datagram, but does not reflect the RR list. Solaris 2.x corrects this problem.

Abnormal Output

The following example was seen by the author and provides a starting point for our description of the ICMP redirect message in Chapter 9. We ping the host aix on the 140.252.1 subnet (accessible through the dialup SLIP connection on the host sun ) with the record route option. We get the following output, when run on the host slip:

 slip %  ping -R aix  PING aix (140.252.1.92): 56 data bytes    64 bytes from 140.252.1.92: icmp_seq=0 ttl=251 time=650 ms    RR:     bsdi (140.252.13.35)            sun (140.252.1.29)            netb (140.252.1.183)            aix (140.252.1.92)            gateway (140.252.1.4)  why is this router used?  netb (140.252.1.183)            sun (140.252.13.33)            bsdi (140.252.13.66)            slip (140.252.13.65)    64 bytes from aix: icmp_seq=l ttl=251 time=610 ms (same route)    64 bytes from aix: icmp_seq=2 ttl=251 time=600 ms (same route)  ^?  --- aix ping statistics ---    4 packets transmitted, 3 packets received, 25% packet loss    round-trip min/avg/max = 600/620/650 ms 

We could have run this example from the host bsdi. We chose to run it from slip to see all nine IP addresses in the RR list used.

The puzzle in this output is why the outgoing datagram (the ICMP echo request) went directly from netb to aix, but the return (the ICMP echo reply) went from aix, through the router gateway, before going to netb. What we're seeing here is a feature of IP routing that we describe below. Figure 7.6 shows the path of the datagrams.

Figure 7.6. ping with record route, showing IP routing feature.

The problem is that aix does not know to send IP datagrams destined for the subnet 140.252.13 to netb. Instead, aix has a default entry in its routing table that tells it to send all datagrams to the router gateway if it doesn't have a particular route for the destination. The router gateway has more routing knowledge than any of the hosts on the 140.252.1 subnet. (There are more than 150 hosts on this Ethernet and instead of running a routing daemon on every one, each has a "default" entry that points to the router gateway. )

An unanswered question here is why doesn't gateway send an ICMP redirect (Section 9.5) to aix to update its routing table? For some reason (perhaps that the datagram generating the redirect is an ICMP echo request message) the redirect is not generated. But if we use Telnet and connect to the daytime server on aix, the ICMP redirect is generated, and the routing table on aix is updated. If we then execute ping with the record route option enabled, the route shows that the datagrams go from netb to aix and back to netb, without the extra hop to the router gateway. We'll look at these ICMP redirects in more detail in Section 9.5.