6.3 ICMP Address Mask Request and Reply

The ICMP address mask request is intended for a diskless system to obtain its subnet mask (Section 3.5) at bootstrap time. The requesting system broadcasts its ICMP request. (This is similar to a diskless system using RARP to obtain its IP address at bootstrap time.) An alternative method for a diskless system to obtain its subnet mask is the BOOTP protocol, which we describe in Chapter 16. Figure 6.4 shows the format of the ICMP address mask request and reply messages.

Figure 6.4. ICMP address mask request and reply messages.

The identifier and sequence number fields in the ICMP message can be set to anything the sender chooses, and these values are returned in the reply. This allows the sender to match replies with requests .

We can write a simple program (named icmpaddrmask ) that issues an ICMP address mask request and prints all replies. Since normal usage is to send the request to the broadcast address, that's what we'll do. The destination address (140.252.13.63) is the broadcast address for the subnet 140.252.13.32 (Figure 3.12).

 sun %  icmpaddrmask 140.252.13.63  received mask = ffffffe0, from 140.252.13.33  from ourself  received mask = ffffffe0, from 140.252.13.35  from  bsdi     received mask = ffff0000, from 140.252.13.34  from  svr4

The first thing we note in this output is that the returned value from svr4 is wrong. It appears that SVR4 is returning the general class B address mask, assuming no subnets, even though the interface on svr4 has been configured with the correct subnet mask:

 svr4 %  ifconfig emd0  emd0: flags=23<UP,BROADCAST,NOTRAILERS>            inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63

There is a bug in the SVR4 handling of the ICMP address mask request.

We'll watch this exchange on the host bsdi using tcpdump. The output is shown in Figure 6.5. We specify the -e option to see the hardware addresses.

Figure 6.5. ICMP address mask request sent to broadcast address.

Note that the sending host, sun, receives an ICMP reply (the output line with the comment from ourself shown earlier), even though nothing is seen on the wire. This is a general characteristic of broadcasting: the sending host receives a copy of the broadcast packet through some internal loopback mechanism. Since by definition the term "broadcast" means all the hosts on the local network, it should include the sending host. (Referring to Figure 2.4 what is happening is that when the Ethernet driver recognizes that the destination address is the broadcast address, the packet is sent onto the network and a copy is made and passed to the loopback interface.)

Next, bsdi broadcasts the reply, while svr4 sends the reply only to the requestor . Normally the reply should be unicast unless the source IP address of the request is 0.0.0.0, which it isn't in this example. Therefore, sending the reply to the broadcast address is a BSD/386 bug.

The Host Requirements RFC says that a system must not send an address mask reply unless it is an authoritative agent for address masks. (To be an authoritative agent it must be specifically configured to send these replies. See Appendix E.) As we can see from this example, however, most host implementations send a reply if they get a request. Some hosts even send the wrong reply!

The final point is shown by the following example. We send an address mask request to our own IP address and to the loopback address:

 sun %  icmpaddrmask sun  received mask = ff000000, from 140.252.13.33     sun %  icmpaddrmask localhost  received mask = ff000000, from 127.0.0.1

In both cases the returned address mask corresponds to the loopback address, the class A address 127.0.0.1. Again, referring to Figure 2.4 we see that IP datagrams sent to the host's own IP address (140.252.13.33 in this example) are actually sent to the loop-back interface. The ICMP address mask reply must correspond to the subnet mask of the interface on which the request was received (since a multihomed host can have different subnet masks for each interface), and in both cases the request is received from the loopback interface.