Although ICMP defines a number of query messages such as Address Mask Request/Reply (types 17/18), Timestamp Request/Reply (types 13/14), and Infor- mation Request/Reply (types 15/16), these functions have been replaced by other, more purpose-specific protocols (including DHCP; see Chapter 6). The only remaining popular ICMP query/informational messages are the Echo Request/
Response messages, more commonly called ping, and the Router Discovery mes- sages. Even the Router Discovery mechanism is not in wide use with IPv4, but its analog (part of Neighbor Discovery) in IPv6 is fundamental. In addition, ICMPv6 has been extended to support Mobile IPv6 and the discovery of multicast-capable routers. In this section, we investigate the Echo Request/Reply functions and the messages used for basic router and Multicast Listener Discovery (also see Chap- ters 6 and 9). In the subsequent section, we explore the operation of Neighbor Discovery in IPv6.
8.4.1 Echo Request/Reply (ping) (ICMPv4 Types 0/8, ICMPv6 Types 129/128) One of the most commonly used ICMP message pairs is Echo Request and Echo Response (or Reply). In ICMPv4 these are types 8 and 0, respectively, and in ICMPv6 they are types 128 and 129, respectively. ICMP Echo Request messages may be of nearly arbitrary size (limited by the ultimate size of the encapsulating
7\SH
&RGH
RU &KHFNVXP
$VPXFKRIRIIHQGLQJGDWDJUDPDVSRVVLEOHVRWKDW WKHUHVXOWLQJ,3Y,&03YGDWDJUDPGRHVQRW
H[FHHGWKHPLQLPXP078 3RLQWHU
E\WHV
Figure 8-15 The ICMPv6 Parameter Problem message. The Pointer field gives the byte offset into the original datagram where an error was encountered. Code 0 indicates a bad header field. Code 1 indicates an unrecognized Next Header type, and Code 2 indicates that an unknown IPv6 option was encountered.
ptg999 Section 8.4 ICMP Query/Informational Messages 381
IP datagram). With ICMP Echo Reply messages, the ICMP implementation is required to return any data received back to the sender, even if multiple IP frag- ments are involved. The ICMP Echo Request/Response message format is shown in Figure 8-16.
As with other ICMP query/informational messages, the server must echo the Identifier and Sequence Number fields back in the reply.
7\SH
,3Y ,3Y
&RGH &KHFNVXP
'DWD2SWLRQDO ,GHQWLILHU
E\WHV 6HTXHQFH1XPEHU
Figure 8-16 Format of the ICMPv4 and ICMPv6 Echo Request and Echo Reply messages. Any optional data included in a request must be returned in a reply. NATs use the Identifier field to match requests with replies, as discussed in Chapter 7.
These messages are sent by the ping program, which is commonly used to quickly determine if a computer is reachable on the Internet. At one time, if you could “ping” a host, you could almost certainly reach it by other means (remote login, other services, etc.). With firewalls in common use, however, this is now far from certain.
Note
The name ping is taken from the sonar operation to locate objects. The ping pro- gram was written by Mike Muuss, who maintained an amusing Web page describ- ing its history [PING].
Implementations of ping set the Identifier field in the ICMP message to some number that the sending host can use to demultiplex returned responses. In UNIX-based systems, for example, the process ID of the sending process is typi- cally placed in the Identifier field. This allows the ping application to identify the returned responses if there are multiple instances of ping running at the same time on the same host, because the ICMP protocol does not have the benefit of transport-layer port numbers. This field is often known as the Query Identifier field when referring to firewall behavior (see Chapter 7).
When a new instance of the ping program is run, the Sequence Number field starts with the value 0 and is increased by 1 every time a new Echo Request
ptg999 message is sent. ping prints the sequence number of each returned packet, allow-
ing the user to see if packets are missing, reordered, or duplicated. Recall that IP (and consequently ICMP) is a best-effort datagram delivery service, so any of these three conditions can occur. ICMP does, however, include a data checksum not provided by IP.
The ping program also typically includes a copy of the local time in the optional data area of outgoing echo requests. This time, along with the rest of the contents of the data area, is returned in an Echo Response message. The ping pro- gram notes the current time when a response is received and subtracts the time in the reply from the current time, giving an estimate of the RTT to reach the host that was “pinged.” Because only the original sender’s notion of the current time is used, this feature does not require any synchronization between the clocks at the sender and receiver. A similar approach is used by the traceroute tool for its RTT measurements.
Early versions of the ping program operated by sending an Echo Request message once per second, printing each returning echo reply. Newer implementa- tions, however, have increased the variability in output formats and behaviors.
On Windows, the default is to send four echo requests, one per second, print some statistics, and exit; the -t option is required to allow the Windows ping applica- tion to continue until stopped by the user. On Linux, the behavior is the traditional one—the default is to run until interrupted by the user, sending an echo request each second and printing any responses. Many other variants of ping have been developed over the years, and there are several other standard options. With some versions of the application, a large packet can be constructed to contain special data patterns. This has been used to look for data-dependent errors in network communications equipment.
In the following example, we send an ICMPv4 Echo Request to the subnet broadcast address. This particular version of the ping application (Linux) requires us to specify the -b flag to indicate that it is indeed our intention (and it gives us a warning regarding this, because it can generate a substantial volume of network traffic) to use the broadcast address:
Linux% ping -b 10.0.0.127
WARNING: pinging broadcast address
PING 10.0.0.127 (10.0.0.127) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=1.290 msec 64 bytes from 10.0.0.6: icmp_seq=0 ttl=64 time=1.853 msec (DUP!) 64 bytes from 10.0.0.47: icmp_seq=0 ttl=64 time=2.311 msec (DUP!) 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=382 usec
64 bytes from 10.0.0.6: icmp_seq=1 ttl=64 time=1.587 msec (DUP!) 64 bytes from 10.0.0.47: icmp_seq=1 ttl=64 time=2.406 msec (DUP!) 64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=380 usec
64 bytes from 10.0.0.6: icmp_seq=2 ttl=64 time=1.573 msec (DUP!) 64 bytes from 10.0.0.47: icmp_seq=2 ttl=64 time=2.394 msec (DUP!) 64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=389 usec
64 bytes from 10.0.0.6: icmp_seq=3 ttl=64 time=1.583 msec (DUP!) 64 bytes from 10.0.0.47: icmp_seq=3 ttl=64 time=2.403 msec (DUP!)
ptg999 Section 8.4 ICMP Query/Informational Messages 383
--- 10.0.0.127 ping statistics ---
4 packets transmitted, 4 packets received, +8 duplicates, 0% packet loss
round-trip min/avg/max/mdev = 0.380/1.545/2.406/0.765 ms
Here, 4 outgoing Echo Request messages are sent and we see 12 responses.
This behavior is typical of using the broadcast address: all receiving nodes are compelled to respond. We therefore see the sequence numbers 0, 1, 2, and 3, but for each one we see 3 responses. The (DUP!) notation indicates that an Echo Reply has been received containing a Sequence Number field identical to a previously received one. Observe that the TTL values are different (255 and 64), suggesting that different kinds of computers are responding.
Note that this procedure (sending echo requests to the IPv4 broadcast address) can be used to quickly populate the local system’s ARP table (see Chapter 4).
Those systems responding to the Echo Request message form an Echo Reply mes- sage directed at the sender of the request. When the reply is destined for a system on the same subnet, an ARP request is issued looking for the link-layer address of the originator of the request. In so doing, ARP is exchanged between every responder and the request sender. This causes the sender of the Echo Request message to learn the link-layer addresses of all the responders. In this example, even if the local system had no link-layer address mappings for the addresses 10.0.0.1, 10.0.0.6, and 10.0.0.47, they would all be present in the ARP table after the broadcast. Note that returning Echo Reply messages to requests sent to the broadcast address is optional. By default, Linux systems return such replies and Windows XP systems do not.
8.4.2 Router Discovery: Router Solicitation and Advertisement (ICMPv4 Types 9, 10) In Chapter 6, we looked at how DHCP can be used for a host to acquire an IP address and learn about the existence of nearby routers. An alternative option we mentioned for learning about routers is called Router Discovery (RD). Although specified for configuring both IPv4 and IPv6 hosts, it is not widely used with IPv4 because of widespread preference for DHCP. However, it is now specified for use in conjunction with Mobile IP, so we provide a brief description. The IPv6 version forms part of the IPv6 SLAAC function (see Chapter 6) and is logically part of IPv6 ND. Therefore, we shall return to discussing it in the broader context of ND in Section 8.5.
Router Discovery for IPv4 is accomplished using a pair of ICMPv4 informa- tional messages [RFC1256]: Router Solicitation (RS, type 10) and Router Advertise- ment (RA, type 9). The advertisements are sent by routers in two ways. First, they are periodically multicast on the local network (using TTL = 1) to the All Hosts multicast address (224.0.0.1), and they are also provided to hosts on demand that ask for them using RS messages. RS messages are sent using multicast to the All Routers multicast address (224.0.0.2). The primary purpose of Router Discovery is for a host to learn about all the routers on its local subnetwork, so that it can
ptg999 choose a default route among them. It is also used to discover the presence of rout-
ers that are willing to act as Mobile IP home agents. See Chapter 9 for details on local network multicast. Figure 8-17 shows the ICMPv4 RA message format, which includes a list of the IPv4 addresses that can be used by a host as a default router.
7\SH &KHFNVXP
%DVLF 5RXWHU 'LVFRYHU\
0HVVDJH
&RGH
/LIHWLPHVHFRQGV 5RXWHU$GGUHVV>@
2SWLRQDO([WHQVLRQV 1XPEHURI
$GGUHVVHV
$GGUHVV(QWU\
6L]H
3UHIHUHQFH/HYHO>@
5RXWHU$GGUHVV>@
3UHIHUHQFH/HYHO>@
5RXWHU$GGUHVV>1@
3UHIHUHQFH/HYHO>1@
7\SH /HQJWK 6HTXHQFH1XPEHU
5HJLVWUDWLRQ/LIHWLPH 5 % + ) 0 * U 7 8 ; , 5HVYELWV
&DUHRI$GGUHVV>@
&DUHRI$GGUHVV>@
5RXWHU 'LVFRYHU\ZLWK
0RELOH,3 6XSSRUWDQG
([WHQVLRQV
>5)&@
Figure 8-17 The ICMPv4 Router Advertisement message includes a list of IPv4 addresses of routers that can be used as default next hops. The preference level lets network operators arrange for some order- ing of preferences to be applied with respect to the list (higher is more preferred). Mobile IPv4 [RFC5944] augments RA messages with extensions in order to advertise MIPv4 mobility agents and the prefix lengths of the advertised router addresses.
In Figure 8-17, the Number of Addresses field gives the number of router address blocks in the message. Each block contains an IPv4 address and accompanying preference level. The Address Entry Size field gives the number of 32-bit words per block (two in this case). The Lifetime field gives the number of seconds for which
ptg999 Section 8.4 ICMP Query/Informational Messages 385
the list of addresses should be considered valid. The preference level is a 32-bit signed two’s-complement integer for which higher values indicate greater prefer- ence. The default preference level is 0; the special value 0x80000000 indicates an address that should not be used as a valid default router.
RA messages are also used by Mobile IP [RFC5944] for a node to locate a mobility (i.e., home and/or foreign) agent. Figure 8-17 depicts a Router Advertise- ment message including a Mobility Agent Advertisement extension. This exten- sion follows the conventional RA information and includes a Type field with value 16 and a Length field giving the number of bytes in the extension area (not includ- ing the Type and Length fields). Its value is equal to (6 + 4K), assuming that K care- of addresses are included. The Sequence Number field gives the number of such extensions produced by the agent since initialization. The registration gives the maximum number of seconds during which the sending agent is willing to accept MIPv4 registrations (0xFFFF indicates infinity). There are a number of Flags bit fields with the following meanings: R (registration required for MIP services), B (agent is too busy to accept new registrations), H (agent is willing to act as home agent), F (agent is willing to act as foreign agent), M (the minimum encapsulation format [RFC2004] is supported), G (the agent supports GRE tunnels for encapsu- lated datagrams), r (reserved zero), T (reverse tunneling [RFC3024] is supported), U (UDP tunneling [RFC3519] is supported), X (registration revocation [RFC3543]
is supported), and I (foreign agent supports regional registration [RFC4857]).
In addition to the Mobility Agent Advertisement extension, one other exten- sion has been designed to help mobile nodes. The Prefix-Lengths extension may follow a Mobility Agent Advertisement extension and indicates the prefix length of each corresponding router address provided in the base router advertisement.
The format is shown in Figure 8-18.
7\SH
)ROORZV0RELOLW\
$JHQW
$GYHUWLVHPHQW ([WHQVLRQ /HQJWK
3UHIL[/HQJWK>@
3UHIL[/HQJWK>@ 3UHIL[/HQJWK>@
3UHIL[/HQJWK>1@
Figure 8-18 The ICMPv4 optional RA Prefix-Lengths extension gives the number of significant prefix bits for each of the N router addresses present in the basic Router Advertisement portion of the message.
This extension follows the Mobility Agent Advertisement extension, if present.
In Figure 8-18, the Length field is set equal to N, the Number of Addresses field from the basic RA message. Each 8-bit Prefix Length field gives the number of bits in the corresponding Router Address field (see Figure 8-17) in use on the local sub- network. This extension can be used by a mobile node to help determine whether it has moved from one network to another. Using algorithm 2 of [RFC5944], a mobile node may cache the set of prefixes available on a particular link. A move can be detected if the set of network prefixes has changed.
ptg999 8.4.3 Home Agent Address Discovery Request/Reply (ICMPv6 Types 144/145)
[RFC6275] defines four ICMPv6 messages used in support of MIPv6. Two of the ICMPv6 messages are used for dynamic home agent address discovery, and the other two are used for renumbering and mobile configuration. The Home Agent Address Discovery Request message is used by an MIPv6 node when visiting a new network to dynamically discover a home agent (see Figure 8-19).
7\SH
&RGH &KHFNVXP ,GHQWLILHU
E\WHV 5HVHUYHG
Figure 8-19 The MIPv6 Home Agent Address Discovery Request message contains an identifier that is returned in the response. It is sent to the Home Agents anycast address for the mobile node’s home prefix.
The message is sent to the MIPv6 Home Agents anycast address for its home prefix. The IPv6 source address is typically the care-of address—the address a mobile node has acquired on the network it is currently visiting (see Chapter 5). A Home Agent Address Discovery Response message (see Figure 8-20) is sent by a node willing to act as a home agent for the given node and its home prefix.
7\SH
&RGH &KHFNVXP
+RPH$JHQW$GGUHVV ,GHQWLILHU
E\WHV 5HVHUYHG
Figure 8-20 The MIPv6 Home Agent Address Discovery Reply message contains the identifier from the corresponding request and one or more addresses of a home agent willing to for- ward packets for the mobile node.
The home agent address is provided directly to the mobile node’s unicast address, which is most likely a care-of address. These messages are intended to handle cases where a mobile node’s HA has changed while transitioning between networks. After reestablishing an appropriate HA, the mobile may initiate MIPv6 binding updates (see Chapter 5).
ptg999 Section 8.4 ICMP Query/Informational Messages 387
8.4.4 Mobile Prefix Solicitation/Advertisement (ICMPv6 Types 146/147)
The Mobile Prefix Solicitation message (see Figure 8-21) is used to solicit a routing prefix update from an HA when a node’s home address is about to become invalid.
The mobile includes a Home Address option (IPv6 Destination Options; see Chap- ter 5) and protects the solicitation using IPsec (see Chapter 18).
7\SH
&RGH &KHFNVXP ,GHQWLILHU
E\WHV 5HVHUYHG
Figure 8-21 The MIPv6 Mobile Prefix Solicitation message is sent by a mobile node when away to request a home agent to provide a mobile prefix advertisement.
The solicitation message includes a random value in the Identifier field, used to match requests with replies. It is similar to a Router Solicitation message but is sent to a mobile node’s HA instead of to the local subnetwork. In the advertise- ment form of this message (see Figure 8-22), the encapsulating IPv6 datagram must include a type 2 routing header (see Chapter 5). The Identifier field contains a copy of the identifier provided in the solicitation message. The M (Managed Address) field indicates that hosts should use stateful address configuration and avoid autoconfiguration. The O (Other) field indicates that information other than the address is provided by a stateful configuration method. The advertisement then contains one or more Prefix Information options.
7\SH
&RGH &KHFNVXP ,GHQWLILHU
E\WHV 5HVHUYHG
02
2SWLRQV,I$Q\
Figure 8-22 The MIPv6 Mobile Prefix Advertisement message. The Identifier field matches the cor- responding field in the solicitation. The M (Managed) flag indicates that the address is provided by a stateful configuration mechanism. The O (Other) flag indicates that other information beyond the address is supplied by stateful mechanisms.
The Mobile Prefix Advertisement message is designed to inform a traveling mobile node that its home prefix has changed. This message is normally secured using IPsec (see Chapter 18) in order to help a mobile node protect itself from spoofed prefix advertisements. The Prefix Information option, which uses the
ptg999 format described in [RFC4861], contains the prefix(es) the mobile node should use
for configuring its home address(es).
8.4.5 Mobile IPv6 Fast Handover Messages (ICMPv6 Type 154)
A variant of MIPv6 defines fast handovers [RFC5568] for MIPv6 (called FMIPv6). It specifies methods for improving the IP-layer handoff latency when a mobile node moves from one network access point (AP) to another. This is accomplished by predicting the routers and addressing information that will be used prior to the handoff taking place. The protocol involves the discovery of so-called proxy rout- ers, which behave like routers a mobile is likely to encounter after it is handed off to a new network. There are corresponding ICMPv6 Proxy Router Solicitation and Advertisement messages (called RtSolPr and PrRtAdv, respectively). The basic for- mat of the RtSolPr and PrRtAdv messages is given in Figure 8-23.
7\SH
&RGH 6XEW\SH
&KHFNVXP
5HVHUYHG ,GHQWLILHU
2SWLRQV
Figure 8-23 The common ICMPv6 message type used for FMIPv6 messages. The Code and Subtype fields give further information. Solicitation messages use code 0 and subtype 2 and may include the sender’s link-layer address and the link-layer address of its preferred next access point (if known) as options. Advertisements use codes 0–5 and subtype 3. The dif- ferent code values indicate the presence of various options, whether the advertisement was solicited, if the prefix or router information has changed, and the handling of DHCP.
A mobile node may have some information available regarding the addresses or identifiers of APs it will use in the future (e.g., by “scanning” for 802.11 net- works). A RtSolPr message uses code 0 and subtype 2 and must contain at least one option, the New Access Point Link-Layer Address option. This is used to indi- cate which AP the mobile is requesting information about. The RtSolPr message may also contain a Link-Layer Address option identifying the source, if known.
These options use the IPv6 ND option format, so we shall defer discussion of them until we look at ND in detail.
8.4.6 Multicast Listener Query/Report/Done (ICMPv6 Types 130/131/132)
Multicast Listener Discovery (MLD) [RFC2710][RFC3590] provides management of multicast addresses on links using IPv6. It is similar to the IGMP protocol used by IPv4, described in Chapter 9. That chapter deals with the operation of IGMP and the use of this ICMPv6 message in detail; here we describe the message formats that