IPv6 Neighbor Discovery
Neighbor discovery is a protocol used for IPv6 traffic that allows different nodes on the same link to advertise their existence to their neighbors, and to learn about the existence of their neighbors.
IPv6 Neighbor Discovery Overview
Neighbor discovery is a protocol that allows different nodes on the same link to advertise their existence to their neighbors, and to learn about the existence of their neighbors.
Routers and hosts (nodes) use Neighbor Discovery (ND) messages to determine the link-layer addresses of neighbors that reside on attached links and to overwrite invalid cache entries. Hosts also use ND to find neighboring routers that can forward packets on their behalf.
In addition, nodes use ND to actively track the ability to reach neighbors. When a router (or the path to a router) fails, nodes actively search for alternatives to reach the destination.
This section discusses the following topics:
Improvements Over Ipv4 Protocols
IPv6 Neighbor Discovery corresponds to a number of the IPv4 protocols — ARP, ICMP Router Discovery, and ICMP Redirect. However, Neighbor Discovery provides many improvements over the IPv4 set of protocols. These improvements address the following:
Router discovery—How a host locates routers residing on an attached link.
Prefix discovery—How a host discovers address prefixes for destinations residing on an attached link. Nodes use prefixes to distinguish between destinations that reside on an attached link and those destinations that it can reach only through a router.
Parameter discovery—How a node learns various parameters (link parameters or Internet parameters) that it places in outgoing packets.
Address resolution—How a node uses only a destination IPv6 address to determine a link-layer address for destinations on an attached link.
Next-hop determination—The algorithm that a node uses for mapping an IPv6 destination address into a neighbor IPv6 address (either the next router hop or the destination itself) to which it plans to send traffic for the destination.
Neighbor unreachability detection—How a node determines that it can no longer reach a neighbor.
Duplicate address detection—How a node determines whether an address is already in use by another node.
A router periodically multicasts a router advertisement from each of its multicast interfaces, announcing its availability. Hosts listen for these advertisements for address autoconfiguration and discovery of link-local addresses of the neighboring routers. When a host starts, it multicasts a router solicitation to ask for immediate advertisements.
The router discovery messages do not constitute a routing protocol. They enable hosts to discover the existence of neighboring routers, but are not used to determine which router is best to reach a particular destination.
Neighbor discovery uses the following Internet Control Message Protocol version 6 (ICMPv6) messages: router solicitation, router advertisement, neighbor solicitation, neighbor advertisement, and redirect.
Neighbor discovery for IPv6 replaces the following IPv4 protocols: router discovery (RDISC), Address Resolution Protocol (ARP), and ICMPv4 redirect.
Junos OS Release 9.3 and later supports Secure Neighbor Discovery (SEND). SEND enables you to secure Neighbor Discovery protocol (NDP) messages. It is applicable in environments where physical security on a link is not assured and attacks on NDP messages are a concern. The Junos OS secures NDP messages through cryptographically generated addresses (CGAs).
Router advertisements can contain a list of prefixes. These prefixes are used for address autoconfiguration, to maintain a database of onlink (on the same data link) prefixes, and for duplication address detection. If a node is onlink, the router forwards packets to that node. If the node is not onlink, the packets are sent to the next router for consideration. For IPv6, each prefix in the prefix list can contain a prefix length, a valid lifetime for the prefix, a preferred lifetime for the prefix, an onlink flag, and an autoconfiguration flag. This information enables address autoconfiguration and the setting of link parameters such as maximum transmission unit (MTU) size and hop limit.
For IPv6, ICMPv6 neighbor discovery replaces Address Resolution Protocol (ARP) for resolving network addresses to link-level addresses. Neighbor discovery also handles changes in link-layer addresses, inbound load balancing, anycast addresses, and proxy advertisements.
Nodes requesting the link-layer address of a target node multicast a neighbor solicitation message with the target address. The target sends back a neighbor advertisement message containing its link-layer address.
Neighbor solicitation and advertisement messages are used for detecting duplicate unicast addresses on the same link. Autoconfiguration of an IP address depends on whether there is a duplicate address on that link. Duplicate address detection is a requirement for autoconfiguration.
Neighbor solicitation and advertisement messages are also used for neighbor unreachability detection. Neighbor unreachability detection involves detecting the presence of a target node on a given link.
Redirect messages are sent to inform a host of a better next-hop router to a particular destination or an onlink neighbor. This is similar to ICMPv4 redirect. Very similar to the ICMPv4 Redirect feature, the ICMPv6 redirect message is used by routers to inform on-link hosts of a better next-hop for a given destination. The intent is to allow the routers to help hosts make the most efficient local routing decisions possible.
In addition to all the other improvements it brings to the networking world, Neighbor Discovery also enables address autoconfiguration, namely Stateless Address Autoconfiguration (SLAAC). IPv6 maintains the capability for stateful address assignment through DHCPv6 (and static assignment), but SLAAC provides a lightweight address configuration method that might be desirable in many circumstances.
SLAAC provides plug-and-play IP connectivity in two phases: Phase 1: Link-local address assignment; and then, in Phase 2: Global address assignment.
Phase 1—Steps for local connectivity:
Link-Local Address Generation: Any time that a multicast-capable IPv6-enabled interface is turned up, the node generates a link-local address for that interface. This is done by appending an interface identifier to the link-local prefix (FE80::/10). The auto generated link-local address cannot be deleted. However, a new link-local address can also be manually entered, which overwrites the auto generated link-local address.
Duplicate Detection: Before assigning the new link-local address to its interface, the node verifies that the address is unique. This is accomplished by sending a Neighbor Solicitation message destined to the new address. If there is a reply, then the address is a duplicate and the process stops, requiring operator intervention.
Link-Local Address Assignment: If the address is unique, the node assigns it to the interface for which it was generated.
At this point, the node has IPv6 connectivity to all other nodes on the same link. Phase 2 can only be completed by hosts. The router’s interface addresses must be configured by other means.
Phase 2—Steps for global connectivity:
Router Advertisement: The node sends a Router Solicitation to prompt all on-link routers to send it router advertisements. When the router is enabled to provide stateless autoconfiguration support, the router advertisement contains a subnet prefix for use by neighboring hosts.
Global Address Generation: Once it receives a subnet prefix from a router, the host generates a global address by appending the interface id to the supplied prefix.
Duplicate Address Detection: The host again performsDuplicate Address Detection (DAD), this time for the new global address. 4. Global Address Assignment: Assuming that the address is not a duplicate, the host assigns it to the interface.
This process ensures full IPv6 global connectivity with no manual host configuration and very little router configuration.
Supported ICMP Router Discovery and IPv6 Neighbor Discovery Standards
Junos OS substantially supports the following RFCs, which define standards for the Internet Control Message Protocol (ICMP for IP version 4 [IPv4]) and neighbor discovery (for IP version 6 [IPv6]).
RFC 1256, ICMP Router Discovery Messages
RFC 4861, Neighbor Discovery for IP version 6 (IPv6)
RFC 2462, IPv6 Stateless Address Autoconfiguration
RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
RFC 4861, Neighbor Discovery for IP version 6 (IPv6)
RFC 4862, IPv6 Stateless Address Autoconfiguration
RFC 8335, PROBE: A Utility for Probing Interfaces
Example: Configuring IPv6 Interfaces and Enabling Neighbor Discovery
This example shows how to configure the router or switch to send IPv6 neighbor discovery messages.
In this example, no special configuration beyond device initialization is required.
In this example, all of the interfaces in the sample topology are configured with IPv6 addresses. If you plan to extend IPv6 functionality into your LAN, datacenter, or customer networks, you might want to use Stateless Address Auto-Configuration (SLAAC) and that means configuring router advertisements. SLAAC is an IPv6 protocol that provides some similar functionality to DHCP in IPv4. Using SLAAC, network hosts can autoconfigure a globally unique IPv6 address based on the prefix provided by a nearby router in a router advertisement. This removes the need to explicitly configure every interface in a given section of the network. Router advertisement messages are disabled by default, and you must enable them to take advantage of SLAAC.
To configure the router to send router advertisement messages, you must include at least the following statements in the configuration. All other router advertisement configuration statements are optional.
To configure neighbor discovery, include the following statements. You configure router advertisement on a per-interface basis.
Figure 1 shows a simplified sample topology.
This example shows how to make sure that all of the IPv6 hosts attached to the subnets in the sample topology can auto-configure a local EUI-64 address.
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the  hierarchy level.
To configure a IPv6 neighbor discovery:
- Configure the network interfaces.
This example shows multiple loopback interface addresses to simulate attached networks.[edit interfaces]user@R1# set fe-1/2/0 unit 1 description to-P2user@R1# set fe-1/2/0 unit 1 family inet6 address 2001:db8:0:1::/64 eui-64user@R1# set fe-1/2/1 unit 5 description to-P4user@R1# set fe-1/2/1 unit 5 family inet6 address 2001:db8:0:5::/64 eui-64user@R1# set fe-1/2/2 unit 9 description to-P3user@R1# set fe-1/2/2 unit 9 family inet6 address 2001:db8:0:9::/64 eui-64user@R1# set lo0 unit 1 family inet6 address 2001:db8::1/128
- Enable neighbor discovery.[edit protocols router-advertisement]user@R1# set interface fe-1/2/0.1 prefix 2001:db8:0:1::/64user@R1# set interface fe-1/2/1.5 prefix 2001:db8:0:5::/64user@R1# set interface fe-1/2/2.9 prefix 2001:db8:0:9::/64
From configuration mode, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
If you are done configuring the device, enter commit from configuration mode.
To confirm that the configuration is working properly, perform this task:
Checking the Interfaces
Verify that the interfaces are up, and view the assigned EUI-64 addresses.
From operational mode, enter the show interfaces terse command.
user@R1> show interfaces terse
Interface Admin Link Proto Local Remote fe-1/2/0 fe-1/2/0.1 up up inet6 2001:db8:0:1:2a0:a514:0:14c/64 fe80::2a0:a514:0:14c/64 fe-1/2/1.5 up up inet6 2001:db8:0:5:2a0:a514:0:54c/64 fe80::2a0:a514:0:54c/64 fe-1/2/2.9 up up inet6 2001:db8:0:9:2a0:a514:0:94c/64 fe80::2a0:a514:0:94c/64 lo0 lo0.1 up up inet6 2001:db8::1 fe80::2a0:a50f:fc56:14c
The output shows that all interfaces are configured with the IPv6 (inet6) address family. Each IPv6-enabled interface has two IPv6 addresses; one link-local address, and one global address. The global addresses match those shown in Figure 1. Junos OS automatically creates a link-local address for any interface that is enabled for IPv6 operation. All link-local addresses begin with the fe80::/64 prefix. The host portion of the address is a full 64 bits long and matches the link-local interface identifier. When an interface address is configured using the eui-64 statement, its interface identifier matches the interface identifier of the link-local address. This is because link-local addresses are coded according to the EUI-64 specification.
Pinging the Interfaces
Verify connectivity between the directly connected interfaces.
Determine the remote router’s IPv6 interface address.
On Device R2, run the show interfaces terse command for the interface that is directly connected to Device R1, and copy the global address into the capture buffer of your terminal emulator.
user@R2> show interfaces fe-1/2/0.2 terse
Interface Admin Link Proto Local Remote fe-1/2/0.2 up up inet6 2001:db8:0:1:2a0:a514:0:24c/64 fe80::2a0:a514:0:24c/64
On Device R1, run the ping command, using the global address that you copied.
user@R1> ping 2001:db8:0:1:2a0:a514:0:24c
PING6(56=40+8+8 bytes) 2001:db8:0:1:2a0:a514:0:14c --> 2001:db8:0:1:2a0:a514:0:24c 16 bytes from 2001:db8:0:1:2a0:a514:0:24c, icmp_seq=0 hlim=64 time=20.412 ms 16 bytes from 2001:db8:0:1:2a0:a514:0:24c, icmp_seq=1 hlim=64 time=18.897 ms 16 bytes from 2001:db8:0:1:2a0:a514:0:24c, icmp_seq=2 hlim=64 time=1.389 ms
Junos OS uses the same ping command for both IPv4 and IPv6 testing. The lack of any interior gateway protocol (IGP) in the network limits the ping testing to directly-connected neighbors. Repeat the ping test for other directly connected neighbors.
Checking the IPv6 Neighbor Cache
Display information about the IPv6 neighbors.
After conducting ping testing, you can find an entries for interface addresses in the IPv6 neighbor cache.
From operational mode, enter the show ipv6 neighbors command.
user@R1> show ipv6 neighbors
IPv6 Address Linklayer Address State Exp Rtr Secure Interface 2001:db8:0:1:2a0:a514:0:24c 00:05:85:8f:c8:bd stale 546 yes no fe-1/2/0.1 fe80::2a0:a514:0:24c 00:05:85:8f:c8:bd stale 258 yes no fe-1/2/0.1 fe80::2a0:a514:0:64c 00:05:85:8f:c8:bd stale 111 yes no fe-1/2/1.5 fe80::2a0:a514:0:a4c 00:05:85:8f:c8:bd stale 327 yes no fe-1/2/2.9
In IPv6, the Address Resolution Protocol (ARP) has been replaced by the Neighbor Discovery Protocol (NDP). The IPv4 command show arp is replaced by the IPv6 command show ipv6 neighbors. The key pieces of information displayed by this command are the IP address, the MAC (Link Layer) address, and the interface.
Verifying IPv6 Router Advertisements
Confirm that devices can be added to the network using SLAAC by ensuring that router advertisements are working properly.
From operational mode, enter the show ipv6 router-advertisement command.
user@R1> show ipv6 router-advertisement
Interface: fe-1/2/0.1 Advertisements sent: 37, last sent 00:01:41 ago Solicits received: 0 Advertisements received: 38 Advertisement from fe80::2a0:a514:0:24c, heard 00:05:46 ago Managed: 0 Other configuration: 0 Reachable time: 0 ms Default lifetime: 1800 sec Retransmit timer: 0 ms Current hop limit: 64 Prefix: 2001:db8:0:1::/64 Valid lifetime: 2592000 sec Preferred lifetime: 604800 sec On link: 1 Autonomous: 1 Interface: fe-1/2/1.5 Advertisements sent: 36, last sent 00:05:49 ago Solicits received: 0 Advertisements received: 37 Advertisement from fe80::2a0:a514:0:64c, heard 00:00:54 ago Managed: 0 Other configuration: 0 Reachable time: 0 ms Default lifetime: 1800 sec Retransmit timer: 0 ms Current hop limit: 64 Prefix: 2001:db8:0:5::/64 Valid lifetime: 2592000 sec Preferred lifetime: 604800 sec On link: 1 Autonomous: 1 Interface: fe-1/2/2.9 Advertisements sent: 36, last sent 00:01:37 ago Solicits received: 0 Advertisements received: 38 Advertisement from fe80::2a0:a514:0:a4c, heard 00:01:00 ago Managed: 0 Other configuration: 0 Reachable time: 0 ms Default lifetime: 1800 sec Retransmit timer: 0 ms Current hop limit: 64 Prefix: 2001:db8:0:9::/64 Valid lifetime: 2592000 sec Preferred lifetime: 604800 sec On link: 1 Autonomous: 1
The output shows that router advertisements are being sent and received on Device R1’s interfaces, indicating that both Device R1 and its directly connected neighbors are configured to generate router-advertisements.
Tracing Neighbor Discovery Events
Perform additional validation by tracing router advertisements.
Configure trace operations.[edit protocols router-advertisement traceoptions]user@R1# set file ipv6-nd-traceuser@R1# set traceoptions flag alluser@R1# commit
Run the show log command.
user@R1> show log ipv6-nd-trace
Mar 29 14:07:16 trace_on: Tracing to "/var/log/P1/ipv6-nd-trace" started Mar 29 14:07:16.287229 background dispatch running job ipv6_ra_delete_interface_config_job for task Router-Advertisement Mar 29 14:07:16.287452 task_job_delete: delete background job ipv6_ra_delete_interface_config_job for task Router-Advertisement Mar 29 14:07:16.287505 background dispatch completed job ipv6_ra_delete_interface_config_job for task Router-Advertisement Mar 29 14:07:16.288288 ipv6_ra_iflchange(Router-Advertisement): ifl 0xb904378 ifl fe-1/2/2.9 104 change 0, intf 0xba140d8 Mar 29 14:07:16.288450 ipv6_ra_iflchange(Router-Advertisement): ifl 0xb904250 ifl fe-1/2/0.1 85 change 0, intf 0xba14000 Mar 29 14:07:16.288656 ipv6_ra_iflchange(Router-Advertisement): ifl 0xb9044a0 ifl fe-1/2/1.5 80 change 0, intf 0xba1406c Mar 29 14:07:16.289293 ipv6_ra_ifachange(Router-Advertisement): ifa 0xba002bc fe80::2a0:a514:0:54c ifl fe-1/2/1.5 80 change 0, intf 0xba1406c Mar 29 14:07:16.289358 -- nochange/add Mar 29 14:07:16.289624 ipv6_ra_ifachange(Router-Advertisement): ifa 0xba00230 2001:db8:0:5:2a0:a514:0:54c ifl fe-1/2/1.5 80 change 0, intf 0xba1406c Mar 29 14:07:16.289682 -- nochange/add Mar 29 14:07:16.289950 ipv6_ra_ifachange(Router-Advertisement): ifa 0xba001a4 fe80::2a0:a514:0:14c ifl fe-1/2/0.1 85 change 0, intf 0xba14000 Mar 29 14:07:16.290009 -- nochange/add Mar 29 14:07:16.290302 ipv6_ra_ifachange(Router-Advertisement): ifa 0xba00118 2001:db8:0:1:2a0:a514:0:14c ifl fe-1/2/0.1 85 change 0, intf 0xba14000 Mar 29 14:07:16.290365 -- nochange/add Mar 29 14:07:16.290634 ipv6_ra_ifachange(Router-Advertisement): ifa 0xba003d4 fe80::2a0:a514:0:94c ifl fe-1/2/2.9 104 change 0, intf 0xba140d8 Mar 29 14:07:16.290694 -- nochange/add Mar 29 14:07:16.290958 ipv6_ra_ifachange(Router-Advertisement): ifa 0xba00348 2001:db8:0:9:2a0:a514:0:94c ifl fe-1/2/2.9 104 change 0, intf 0xba140d8 Mar 29 14:07:16.291017 -- nochange/add Mar 29 14:07:20.808516 task_job_create_foreground: create job ipv6 ra for task Router-Advertisement Mar 29 14:07:20.808921 foreground dispatch running job ipv6 ra for task Router-Advertisement Mar 29 14:07:20.809027 ipv6_ra_send_advertisement: sending advertisement for ifl 104 to ff02::1 Mar 29 14:07:20.809087 (4810916) sending advertisement for ifl 104 Mar 29 14:07:20.809170 ifa 0xba00348 2001:db8:0:9:2a0:a514:0:94c/64 Mar 29 14:07:20.809539 --> sent 56 bytes Mar 29 14:07:20.809660 task_timer_reset: reset Router-Advertisement_ipv6ra Mar 29 14:07:20.809725 task_timer_set_oneshot_latest: timer Router-Advertisement_ipv6ra interval set to 7:07 Mar 29 14:07:20.809772 foreground dispatch completed job ipv6 ra for task Router-Advertisement