Share via

IPv6 Neighbor Discovery

  • Article

Applies To: Windows Server 2008

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. For more information, see “Router Discovery” later in this section.

Parameter discovery

The process by which hosts discover additional operating parameters, including the link MTU and the default hop limit for outgoing packets. For more information, see “Router Discovery” later in this section.

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. For more information, see “Address Resolution” later in this section.

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.

Windows Sockets has been extended to support IPv6 either directly, using IPv6-specific Windows Sockets functions and structures, or indirectly, using IP version-independent functions. The following figure shows the Windows Sockets architecture for Windows Server® 2008.

Windows Sockets for Both IPv4 and IPv6