IPv6 deployment:maintenance protocols
IPv6 and IPv4 maintenance protocols compared
With IPv4, we were introduced to a number of maintenance protocols. These protocols gave us the ability to detect errors in our network, receive alerts when our endpoints became unreachable, and to detect the layout of our network.
In IPv4, the major protocol used for network maintenance is called ICMP (Internet Message Control Protocol) and is defined in RFC 792. The most important types are described below [Computer Networks 4th Ed, p. 449, ISBN 0130661023]:
Message Type Description ------------ --------------- Destination Unreachable Datagram could not be delivered Time Exceeded Time to Live reached 0 Parameter Problem Invalid Header Field Echo Ping Request Echo Reply Ping Reply |
In IPv6, the common ICMP messages are retained, but there are a few additions:
Message Type Description ------------ ---------------- Destination Unreachable Datagram could not be delivered, i.e. no route to destination Packet Too Big Since fragmentation cannot be done, MTU size was too large for some link in transmission path. Time Exceeded Hop Limit reached 0 Parameter Problem Invalid Header Field Echo Ping Request Echo Reply Ping Reply Multicast Listener Query What multicast addresses are on a link? Multicast Listener Report Node is joining a multicast group Multicast Listener Done Node is resigning multicast group Router Solicitation Node needs to know routes Router Advertisement Router sends routing table Neighbor Solicitation Node wants to build ARP table Neighbor Advertisement Node responds to solicitation |
Assuming a familiarity with IPv4, we will discuss only the new ICMP messages. The first (and probably most used) error message is the "Packet Too Big" message type. This can occur when a packet is transmitted along different links of differing MTU (Maximum Transmission Unit) sizes. When the datagram is initially constructed, the node will assume that its link MTU size is safe for transmission to all destination nodes. However, if a router along the path to the destination has a smaller link size, the packet will be discarded and a "Packet Too Big" ICMP message will be directed towards the source. The data payload of the ICMP message gives the MTU size of the link that caused the problem. The source node then has the responsibility of encapsulating the data into the proper size for the bottleneck link and then retransmitting. This mechanism may be repeated by other routers that may have increasingly smaller MTU sizes. This mechanism is called Path MTU Discovery and is defined in RFC 1981.
The next set of ICMP messages are informational in nature and are used to coordinate information between nodes and routers. The simplest information exchange mechanism is called Neighbor Solicitation and Advertisement. This pair of messages has two functions. The first is the resolution of link layer addresses (similar to ARP in IPv4) and the second is detecting when a neighbor is unreachable. When a node attempts to resolve a hardware level address, the destination for the Neighbor Solicitation message will be a multicast address. When a node attempts to determine the reachability of a neighbor, the destination is the unicast address of that neighbor. When Neighbor Solicitation messages are sent by hosts that are determining the reachability of their neighbors, Neighbor Advertisements will be sent as replies to the solicitations. Neighbor Advertisements are also sent unsolicited when a new node joins a link. In this way, the overhead of the ARP protocol is bypassed since hosts will have local address caches for all machines on their network.
The next pair of informational ICMP messages are the Router Solicitation and Advertisement types. Routers regularly send out Router Advertisements, which contain routing information to be used on their link. However, nodes can request routing information outside of this normal interval by sending a Router Solicitation to the Link-local All-routers multicast address (ff02::2). This mechanism ensures that routing tables for all nodes are consistent.
The final informational messages in our list are the multicast management messages. These messages comply with the Multicast Listener Discovery protocol as defined in RFC 2710, which is a descendant of the Internet Group Management Protocol used in IPv4. The idea is that routers are responsible for keeping track of multicast group membership in their subnets, based on information that they obtain from their nodes. Whenever a node joins a multicast group, it must send a "Multicast Listener Report" packet to its router. When it leaves a multicast group, it sends a "Multicast Listener Done" packet to its router. In turn, the affected router must subscribe/unsubscribe to the multicast group with its parent router, and so on. At certain intervals (and under certain circumstances), the router can send a "Multicast Listener Query" to determine which multicast groups exist on a specific link, or to determine which hosts subscribe to a particular multicast group. The answers to these requests are also "Multicast Listener Report" messages.
Why use IPv6 - conclusions
Simply put, IPv6 has significant improvements over IPv4. Using IPv6 extends the life of the Internet, whose address space is doomed to become saturated within a few years. It also simplifies router processing of the network datagrams because of its simplified header design. Finally, IPv6 offers "plug and play" network management because of its stateless autoconfiguration, router discovery, neighbor discovery, multicast discovery, and management protocols.
Internal links
Next section: SOHO network
Main article: IPv6 deployment