|
|
Internet Control Message Protocol for IPv6ICMPv6 is an integral part of the IPv6 architecture and must be completely supported by all IPv6 implementations. It combines functionalities supported in IPv4 under different protocols: ICMP (Internet Control Message Protocol version 4), IGMP (Internet Group Membership Protocol), and ARP (Address Resolution Protocol). ICMPv6 runs over IPv6, unicast, and multicast. As such, it is nonreliable, and cannot be used for features that require reliability. ICMPv6 is described in RFC 2463. Table 2-9, lists the RFCs that define ICMPv6 functionalities and the codes identifying the ICMPv6 types used for these functionalities.
Similar to ICMPv4, ICMPv6 enables IPv6 nodes to report errors and performs various control-plane functions. Many of the existing ICMPv4 functionalities have been carried over to ICMPv6, although some were simplified and many more added. This reengineering of ICMP could have been driven independently of the protocol version. However, the IPv4 legacy made that approach unrealistic, so a new protocol type (Next Header) was defined specifically for ICMPv6 (protocol type 58 for ICMPv6, instead of 1 for ICMPv4). In this context, ICMPv6 ended up being a different protocol than ICMPv4. Some features are similar to their IPv4 counterpart (some of the error messages such as Destination Unreachable). Some features are not carried over, mostly because they never became popular (traceroute as defined in RFC 1393, for instance). New features (such as link-layer address resolution, or packet too big) were introduced, leading to some fundamental design differences from IPv4. Table 2-9 presents a comparison between ICMPv6 and ICMPv4. In the ICMPv6 column, the ICMPv4 messages that are not considered in IPv6 are marked NC. In the ICMPv4 column, the ICMPv6 messages that were not adopted are marked NA. The ICMPv6 types 1 to 127 are reserved for errors, and values starting at 128 are for control and information reporting. Regardless of message type, all ICMPv6 messages share the same message header format as shown in Figure 2-18. Figure 2-18. ICMPv6 Packet Format
The IPv6 header has a value of 58 in the Next Header field if the upper-layer protocol of the payload data is ICMPv6. If the message is a response to an ICMPv6 messages sent to one of the node's unicast addresses, the SA is the same address. Otherwise, the SA is calculated using the source address selection algorithm (see the "SAS Algorithm" section later in this chapter). The Type field, shown in Figure 2-18, can take one of the values enumerated in Table 2-9, and the code depends on each message. The Checksum, unlike ICMPv4, includes the pseudo-header, a set of important fields from the IPv6 header, in addition to the ICMPv6 entire message. The inclusion of the pseudo-header enables ICMPv6 to check the integrity of essential elements of the IPv6 header in the absence of a layer 3 header checksum (see the "IPv6 Packet Format" section earlier in the chapter). ICMPv6 Error MessagesOne of ICMP's functions is to deliver error messages that help the operation of a network. Currently, ICMPv6 uses four error messages:
The scope, use, and format of these messages are discussed in the following subsections. Destination UnreachableIPv6 is as unreliable as IPv4 is, in the sense that sometimes packets get dropped on the path to their destination. In many cases, this is a transient problem due to network congestion or transient connectivity loss and can be recovered by higher-level protocols, such as TCP. In some cases, however, a feedback mechanism is required. For example, the destination specified in the packet can be wrong, or the routing protocol may be failing to distribute routing information to it. ICMP Destination Unreachable provides such feedback mechanism, in the same way as in IPv4. The ICMP Unreachable message provides a reason code to help the source troubleshoot the problem and take appropriate action. Table 2-10 lists the ICMP code values.
Note that ICMPv6 has fewer codes than ICMPv4, mainly because some IPv4 messages are not applicable to IPv6. For instance, "Fragmentation Needed and DF Set" cannot apply to IPv6 because fragmentation does not occur on intermediate routers. In addition to the reason code, the message also includes the original datagram portion that fit into the 1280-byte packet. Time ExceededAs in IPv4, an IPv6 datagram might loop in the network (because of improper routing configuration, or transient routing states in large networks). The ICMPv6 Time Exceeded was carried over from ICMPv4, designed to prevent packets from looping indefinitely in the network. A Hop Count field in the IPv6 header is decremented by each hop until it eventually reaches 0, in which case the datagram is dropped and the ICMPv6 Time Exceeded is sent back to the source. Note As in ICMPv4, the Time Exceeded message was diverted from its original goal, to provide a fairly inefficient but useful way to trace paths in the network (namely, traceroute). A UDP packet is sent to destination many times, by increasing the Hop Count field from 1 to "whatever it takes to reach the destination." Each node on the path will successively send back an ICMPv6 Time Exceeded message, enabling the source to identify each router on the path. Packet Too BigOne of the numerous changes brought by IPv6 relates to the packet-fragmentation process. Unlike IPv4, in which any router on the path to the destination could fragment a packet, should it not fit the MTU of the outgoing link, IPv6 does not provision for this functionality. Although it was convenient for hosts to rely on fragmentation performed by routers, wherever needed, this was also concentrating a lot of processing burden on the routers. Routers have to keep state and use additional memory for the fragmentation process. This being said, it cannot be sufficient to not support the fragmentation feature in the middle of the network. Some feedback mechanism becomes required so that a router on the path to the destination can signal to the originating host that packets need to be fragmented. The Packet Too Big ICMPv6 message is used for that purpose. It contains the MTU for the failing link and the original datagram portion that fit into the 1280-byte packet. The ICMPv6 message is primarily an error message. However, it was slightly diverted from its original purpose, to enable hosts to discover the minimum MTU on a path to a particular destination. This is the PMTU Discovery functionality, described in RFC 1981. In short, the idea is that a host assumes the path MTU (PMTU) is the MTU of the first hop in the path. Upon receiving Packet Too Big ICMPv6 messages, it reduces the PMTU and fragments packets accordingly. It keeps going until it stops receiving the Packet Too Big messages. The PMTU process on a Cisco router is shown in Example 2-9 through the output of the IPv6 ICMP debug. Example 2-9. PMTU Discovery Performed by a Cisco Router
Parameter ProblemAs in ICPMv4, the Parameter Problem messages provide a way for routers to report more generic issues not covered by the first three messages described previously. The ICMPv6 message can point out (by signaling the offset of that field) any field anomaly in the IPv6 header that prevented the datagram from being processed further. The following code values enable the complaining node to provide additional indications.
ICMPv6 Informational MessagesThe Echo Request and Echo Reply found in ICMPv4 have been carried over to ICMPv6. As in ICMPv4, these two messages are widely used to perform simple connectivity diagnostics, via the ping command. The format of the messages is pretty much unchanged. Besides a type (1) and a code (1), the messages contain an identifier and a sequence number, plus some optional data, copied back from the Request into the Reply. Many more informational messages have been specified in various RFCs for the benefit of a large variety of protocols, such as Neighbor Discovery, MIPv6, and multicast. Those are covered in detail in the corresponding sections. Source Address Selection AlgorithmOne of the specificities of IPv6 is that a node can commonly have multiple addresses to choose from when selecting the source or destination of a packet. Multiple unicast addresses can be assigned to the same interface, and they may have different reachability scopes (link-local or global). Dual-stack nodes might even have a choice between IPv4 and IPv6 addresses, in particular if the DNS server has provided both of them for a given name. Multihoming is likely to enable multiple addresses per node, and MIPv6 introduces home address and care-of address in the same node. Two algorithms have been specified in RFC 3484, one for source address selection (SAS) and one for destination address selection (DAS). This section details the former (SAS), because it is commonly used by ICMPv6 to select the SA to use before generating an error or informational message. Many other aspects of IPv6 operation, besides ICMP, are required to deal with SAS, or have ramifications for SAS, and in some cases, encounter issues with SAS. MIPv6 and VPNv6 represent two examples, so the SAS topic will be brought up again in the respective sections. The algorithm presented here describes the current state of SAS. The SAS algorithm does not take precedence over the application or upper-layer choice. For instance, in the ICMP case, a response to a query just uses the SA that is the DA of the corresponding request. When used, the algorithm is provided with a list of candidate addresses, and applies to this list a set of rules to select the candidate that matches the maximum number of these rules. If a rule has no matching candidates, a candidate address from the list before the rule was applied is chosen. Figure 2-19 provides a logic diagram of the SAS algorithm. Figure 2-19. Source Address Selection Algorithm
As mentioned in the "IPv6 Addressing" section of this chapter, the addresses of site-local scope have been deprecated and replaced by unique-local addresses, with global scope. These addresses have not yet explicitly found their way into SAS, but they should be considered in the context of the scope rule. Conclusion on ICMPv6ICMPv6 has not fundamentally diverged from ICMPv4. It is still a messaging protocol, connectionless, and used for many different purposes (from error reporting to diagnostic and network operations). Messages are structured the same way as in ICMPv4, with a type, code, and body; some message types have been carried over from ICMPv4, and some new ones have been defined. However, the uses of ICMPv6, in particular by the Neighbor Discovery Protocol (NDP), are greater than ICMPv4 uses. Whether this is the right approach and the right protocol to perform things as diverse as address resolution, error reporting, autoconfiguration, MIPv6 tasks, and so forth remains to be seen on the deployment side.  |
|
|