IPv6 Protocols
Applies To: Windows Server 2008
IPv6 Protocols
The IPv6 protocol component that is installed in Windows operating systems is a series of interconnected protocols that include Internet Control Message Protocol version 6 (ICMPv6), Multicast Listener Discovery (MLD), and Neighbor Discovery. These core protocols replace the Internet layer protocols in the Defense Advanced Research Projects Agency (DARPA) model. All protocols above the Internet layer rely on the basic services that IPv6 provides. Protocols at the Host-to-Host Transport and Application layers are largely unchanged, except when addresses are part of the payload or part of the data structures that the protocol maintains. For example, both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) must be updated to perform new checksum calculations that include IPv6 addresses. TCP must be updated to store IPv6 addresses in its internal Transmission Control Block (TCB). Routing Information Protocol (RIP) must be updated to send and receive IPv6 route prefixes.
The following table explains each of the IPv6 core protocols in more detail.
IPv6 Core Protocols
| Protocol | Function |
|---|---|
IPv6 |
IPv6 is a routable protocol that is responsible for the addressing, routing, and fragmenting of packets by the sending host. IPv6 replaces Internet Protocol version 4 (IPv4). |
ICMPv6 |
ICMPv6 is responsible for providing diagnostic functions and reporting errors due to the unsuccessful delivery of IPv6 packets. ICMPv6 replaces ICMPv4. |
Neighbor Discovery |
Neighbor Discovery is responsible for the interaction of neighboring nodes and includes message exchanges for address resolution, duplicate address detection, router discovery, and router redirects. Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and the ICMPv4 Redirect message. |
Multicast Listener Discovery |
Multicast Listener Discovery is a series of three ICMPv6 messages that replace version 2 of the Internet Group Management Protocol (IGMP) for IPv4 to manage subnet multicast membership. |
IPv6
Like IPv4, IPv6 is a connectionless, unreliable datagram protocol that is primarily responsible for addressing and routing packets between hosts. Connectionless means that a session is not established before data is exchanged. Unreliable means that delivery is not guaranteed. IPv6 always makes a best effort attempt to deliver a packet. An IPv6 packet might be lost, delivered out of sequence, duplicated, or delayed. IPv6 does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets is the responsibility of an upper layer protocol, such as TCP.
An IPv6 packet consists of an IPv6 header and an IPv6 payload. The IPv6 payload consists of zero or more IPv6 extension headers and an upper layer protocol data unit, such as an ICMPv6 message, a TCP segment, or a UDP message. The following figure shows the structure of an IPv6 packet.
Structure of an IPv6 Packet
.gif)
The following table describes the key fields in the IPv6 header.
Key Fields in the IPv6 Header
| IP Header Field | Function |
|---|---|
Source Address |
Identifies the IPv6 address of the original source of the packet. |
Destination Address |
Identifies the IPv6 address of the intermediate or final destination of the packet. |
Next Header |
Identifies either the extension header immediately following the IPv6 header or an upper layer protocol, such as ICMPv6, TCP, or UDP. |
Hop Limit |
Designates the number of subnets, or network segments, on which the packet is allowed to travel before being discarded by a router. The sending host sets the Hop Limit, which prevents packets from endlessly circulating on an IPv6 internetwork. When forwarding an IPv6 packet, routers decrement the Hop Limit by one. |
IPv6 Extension Headers
Zero or more extension headers of varying lengths can be present. If any extension headers are present, a Next Header field in the IPv6 header indicates the first extension header. In a typical IPv6 packet, no extension headers are present. The sending host adds one or more extension headers only if either an intermediate router or the destination requires special handling.
Within each extension header is another Next Header field that indicates the next extension header. The last extension header indicates the upper layer protocol (such as TCP, UDP, or ICMPv6) contained within the upper layer protocol data unit.
The IPv6 header and extension headers replace the existing IPv4 header with options. The new extension header format allows IPv6 to be augmented to support future needs and capabilities. Unlike options in the IPv4 header, IPv6 extension headers have no maximum size and can expand to accommodate all the extension data needed for IPv6 communication.
RFC 2460 defines the following extension headers, which all IPv6 nodes must support:
Hop-by-Hop Options header
Destination Options header
Routing header
Fragment header
Authentication header
Encapsulating Security Payload header
Fragmentation in IPv6
If an IPv4 router receives a packet that is too large for the network segment to which the packet is being forwarded and fragmentation of the packet is allowed, IPv4 fragments the original packet into smaller packets that fit on the downstream network segment. In IPv6, only the sending host performs fragmentation. If an IPv6 router cannot forward a packet because it is too large, the router sends an ICMPv6 Packet Too Big message to the sending host and discards the packet.
Use of the Fragment extension header facilitates sending host fragmentation and destination host reassembly.
ICMPv6
Like IPv4, IPv6 does not provide facilities for reporting errors. Instead, IPv6 uses an updated version of the Internet Control Message Protocol (ICMP) named ICMPv6. ICMPv6 has the common ICMPv4 functions of reporting delivery or forwarding errors and providing a simple echo service for troubleshooting.
The ICMPv6 protocol also provides a framework for the following:
Neighbor Discovery
Neighbor Discovery is a series of five ICMPv6 messages that manage node-to-node communication on a link. Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and the ICMPv4 Redirect message. For more information about Neighbor Discovery, see IPv6 Neighbor Discovery.
Multicast Listener Discovery (MLD)
Multicast Listener Discovery is a series of three ICMP messages that manage subnet multicast membership. Multicast Listener Discovery replaces version 2 of the Internet Group Management Protocol (IGMP) for IPv4. For more information about Multicast Listener Discovery, see “Multicast Listener Discovery” later in this section.
ICMPv6 is required for an IPv6 implementation. The following table lists and describes the ICMPv6 messages that are defined in RFC 2463.
Common ICMPv6 Messages
| ICMPv6 Message | Function |
|---|---|
Echo Request |
Sent to check IPv6 connectivity to a particular host. |
Echo Reply |
Sent in response to an ICMPv6 Echo Request. |
Destination Unreachable |
Sent by a router or the destination host to inform the sending host that the packet or payload cannot be delivered. |
Packet Too Big |
Sent by a router to inform a sending host that a packet is too large to forward. |
Time Exceeded |
Sent by a router to inform a sending host that the Hop Limit of an IPv6 packet has expired. |
Parameter Problem |
Sent by a router to inform a sending host that an error was encountered in processing the IPv6 header or an IPv6 extension header. |
A series of defined Destination Unreachable messages has been defined. The following table lists and describes the most common of these messages.
Common Destination Unreachable Messages
| Destination Unreachable Message | Description |
|---|---|
No Route Found |
Sent by an IPv6 router when a route to the destination IPv6 address cannot be found. |
Communication Prohibited by Administrative Policy |
Sent when administrative policy prohibits communication with the destination host. This message is typically sent when a firewall discards a packet. |
Destination Address Unreachable |
Sent when the destination address is unreachable. This message is typically sent when the destination’s link layer address cannot be resolved. |
Destination Port Unreachable |
Sent when the destination port is unreachable. This message is typically sent when an IPv6 packet containing a UDP message arrived at the destination but no applications were listening on the destination UDP port. |
ICMPv6 does not make IPv6 a reliable protocol. ICMPv6 attempts to report errors and to provide feedback on specific conditions. ICMPv6 messages are carried as unacknowledged IPv6 datagrams and are themselves unreliable.
Path MTU Discovery
The maximum transmission unit (MTU) for a path is the minimum link MTU of all links on a path between a source and a destination. IPv6 packets that are smaller than the path MTU do not require fragmentation by the host and are successfully forwarded by all routers on the path. To discover the path MTU, the sending host uses the receipt of ICMPv6 Packet Too Big messages.
Sending hosts discover the path MTU through the following process:
The sending host assumes that the path MTU is the link MTU of the interface on which the traffic is being forwarded.
The sending host sends IPv6 datagrams at the path MTU size.
If a router on the path is unable to forward the packet over a link because the packet is larger than the link MTU, the router sends an ICMPv6 Packet Too Big message back to the sending host and discards the packet. The Packet Too Big message contains the MTU of the link on which the forwarding failed.
The sending host sets the path MTU for packets being sent to the destination to the value of the MTU field in the Packet Too Big message.
The sending host starts again at step 2 and repeats steps 2 through 4 as many times as necessary to discover the path MTU. The sending host determines the path MTU when the node receives either an acknowledgement from the destination or no more Packet Too Big messages.
RFC 1981 recommends that IPv6 nodes support path MTU discovery. Nodes that do not provide this support must use the minimum link MTU of 1280 bytes as the path MTU.
Changes in Path MTU
Changes in routing topology can change the path between source and destination. If a path MTU becomes smaller, sending hosts receive Packet Too Big messages, and the nodes must repeat steps 2 through 4 to discover the new path MTU. If a path MTU becomes larger, sending hosts can detect this change (as described in RFC 1981) by attempting to send a larger IPv6 packet after a minimum of 5 minutes (10 minutes are recommended) upon receiving a Packet Too Big message.
Neighbor Discovery
Neighbor Discovery is a set of ICMPv6 messages and processes that determine relationships between neighboring nodes. Neighbor Discovery replaces ARP, ICMP Router Discovery, and ICMP Redirect used in IPv4, and Neighbor Discovery provides additional functionality.
Hosts use Neighbor Discovery to:
Discover neighboring routers.
Discover addresses, address prefixes, and other configuration parameters.
Routers use Neighbor Discovery to:
Advertise their presence, host configuration parameters, and on-link prefixes.
Inform hosts of a better next-hop address to forward packets for a specific destination.
Nodes use Neighbor Discovery to:
Resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded.
Determine when the link-layer address of a neighboring node has changed.
Determine whether a neighbor is still reachable.
The following table lists and describes the Neighbor Discovery processes that RFC 2461 describes.
IPv6 Neighbor Discovery Processes
| Neighbor Discovery Process | Description |
|---|---|
Router discovery |
The process by which hosts discover the local routers on attached links. Equivalent to ICMPv4 Router Discovery. For more information, see “Router Discovery” later in this section. |
Prefix discovery |
The process by which hosts discover the network prefixes for local link destinations. Similar to the ICMPv4 Address Mask Request/Reply. |
Parameter discovery |
The process by which hosts discover additional operating parameters, including the link MTU and the default hop limit for outgoing packets. |
Address autoconfiguration |
The process for configuring IP addresses for interfaces in either the presence or absence of a server that provides stateful address configuration using a protocol such as Dynamic Host Configuration Protocol version 6 (DHCPv6). |
Address resolution |
The process by which nodes resolve a neighbor’s IPv6 address to its link-layer address. Equivalent to ARP in IPv4. |
Next-hop determination |
The process by which nodes determine the IPv6 address of the neighbor to which a packet is being forwarded based on the destination address. The forwarding or next-hop address is either the destination address or the address of an on-link default router. |
Neighbor unreachability detection |
The process by which nodes determine that a neighbor is no longer receiving packets. |
Duplicate address detection |
The process by which nodes determine whether an address considered for use is already in use by a neighboring node. Equivalent to using gratuitous ARP frames in IPv4. |
Redirect function |
The process of informing a host of a better first-hop IPv6 address to reach a destination. Equivalent to the use of the IPv4 ICMP Redirect message. |
Multicast Listener Discovery
Multicast Listener Discovery (MLD) is the IPv6 equivalent of Internet Group Management Protocol version 2 (IGMPv2) for IPv4. MLD is a set of ICMPv6 messages that routers and nodes exchange to enable routers to discover which multicast addresses have listening nodes for each attached interface. As with IGMPv2, MLD discovers only those multicast addresses for which at least one listener exists, not the list of individual multicast listeners for each multicast address. MLD is described in RFC 2710.
In contrast to IGMPv2, MLD uses ICMPv6 messages instead of defining its own message structure. The three types of MLD messages are:
Multicast Listener Query
Routers send Multicast Listener Query messages to query a link for multicast listeners. Multicast Listener Query messages are either General Query messages or Multicast-Address-Specific Query messages. Routers send General Query messages to query for multicast listeners of all multicast addresses. Routers send Multicast-Address-Specific Query messages to query for multicast listeners of a specific multicast address. The two message types are distinguished by the multicast destination address in the IPv6 header and a multicast address within the Multicast Listener Query message.
Multicast Listener Report
Multicast listeners send Multicast Listener Report messages to either report interest in receiving multicast traffic for a specific multicast address or to respond to a Multicast Listener Query message.
Multicast Listener Done
Multicast listeners send Multicast Listener Done messages to report that they are no longer interested in receiving multicast traffic for a specific multicast address.
An MLD message packet consists of an IPv6 header, a Hop-by-Hop Options extension header, and the MLD message. The Hop-by-Hop Options extension header contains the IPv6 Router Alert Option that RFC 2711 describes. This option ensures that routers process MLD messages sent to multicast addresses on which the routers are not listening.
IPv6 Application Interfaces
As in IPv4, applications can use the services of IPv6 by using the Windows Sockets application programming interface (API). A socket is defined by a protocol and an address on the host. The format of the address is specific to each protocol. For TCP and UDP traffic over IPv6, the address is the combination of the IPv6 address and port. Two sockets, one for each end of the connection, form a bi-directional communications path.
To communicate with IPv6, an application can use Windows Sockets to specify the protocol (IPv6), the IPv6 address of the destination host, and the port of the destination application. After the application is connected, information can be sent and received.
Until IPv6 is broadly adopted, most hosts will be IPv6/IPv4 hosts, using implementations of both the IPv6 and IPv4 protocols. Developers could modify current applications to test for and then selectively use either IPv4 or IPv6 as their transport for data. However, it makes more sense to modify the applications to use a single Windows Sockets function to perform network operations regardless of whether IPv4, IPv6, or both are installed.
A good example of making applications IP version-independent is to replace all instances of the Windows Sockets function gethostbyname( ) with the Windows Sockets function getaddrinfo( ). The gethostbyname( ) function is commonly used to resolve a specified name to an IPv4 address and never returns an IPv6 address. The function getaddrinfo( ) resolves names to both IPv4 and IPv6 addresses, depending on whether IPv4 and IPv6 is installed and which types of addresses the Domain Name System (DNS) name query returns. The application need not test for the existence of both protocols or both types of addresses in the response. By replacing gethostbyname( ) with getaddrinfo( ), the developer makes the application IP version-independent for name resolution.