IPv6 Neighbor Discovery Protocol on Cisco Router

Hi Diana,

Glad to hear you like it!

There’s not really a short answer to your question. Technically, ND doesn’t require MLD to work.

IPv6 ND uses multicast and the solicited node multicast addresses.

Using multicast instead of broadcast sounds effective but in reality, your ND traffic is probably still broadcasted since your L2 switches don’t know where to forward the multicast traffic to.

To improve this, you could enable MLD snooping on the switches. Your hosts will have to report what they want to receive through MLD and then the switch will be able to deliver multicast traffic only on the required interfaces.

This sounds great but in reality, it doesn’t work. Each host will have a unique solicited multicast address so if you have 1000 hosts then your switch has to keep track of 1000 multicast groups. Depending on the switch, it might be unable to do this.

It’s best to keep MLD snooping disabled, your NICs will drop multicast traffic that they are not interested in.

Rene

Hi Rene,

Thanks for your great support in our studies.

When you know the destination unicast address, you can calculate the solicited node multicast address, it´s clear for me.

But let s guess a different scenario:

We have a Router sending a ping to multicast group FF02::1, meaning to all the devices in the network.

Could you please briefly describe, if possible, how the Neighbor Discovery protocol works in this case ?NS and NA.

Why when FF02::1 is marked as destination the process shows it as echo request and not as NS.

Thanks!

Hi Jose,

When the router (or host) receives a packet with destination FF02::1 then it will respond to the source address. This will initiate the Neighbor Solicitation, the router that sent the original packet to FF02::1 will reply with a Neighbor Advertisement.

Here’s a wireshark capture of this process:

https://www.cloudshark.org/captures/42ff6640a123

Rene

Rene In Neighbor Solicitation: the destination address will be the solicited node multicast address of the remote host. How does the sending node know the destination multicast address in 1st place? Shouldn’t this unknown for either node at the beginning?

Rene, what pieces of information does a local router need to know in order to learn the MAC address of a remote router? This could help understand :slight_smile: Is IPv6 one of the biggest topics on the new CCNA? Not easy :slight_smile:

Itai,
The solicited node multicast address is known because the IPv6 RFC standards have established a “rule” in how to form the solicited node multicast address based on the IPv6 addresses that is needing to be queried. The rule states that solicited node multicast address is: FF02::1:FFXX:XXXX where X is the last 24 bits of the IPv6 target address. This means you take the last “half” of the next to last hextet, and the entire last hextet and append it to FF01::1:FF. See example below.

The last thing you would need to know is that there is also an IPv6 RFC rule for creating the layer 2 address for any IPv6 multicast address. That rule states the address is 3333:FFXX:XXXX where X is the last 24 bits of the multicast address

Example: Let’s say Host A has just booted up, and wants to use the local IPv6 address of FE80::0200:0BFF:FE0A:2D51. Host A needs to determine whether another host is using this address before it is allowed to start using it. In this case, a Neighbor Solicitation called DAD (duplicate address detection) is used. Here are the layer 3 and layer 2 addresses this DAD would use:

Layer 3
Source Address: :: <--------- Host A isn’t allowed to use a layer 3 address yet
Destination Address: FF02::1:FF0A:2D51 <--------- This is the result of the IPv6 RFC rule for crafting a solicited node multicast address

Layer 2
Source Address: <Host A’s MAC address> <--------- Normal Ethernet operation here
Destination Address: 3333:FF0A:2D51 <--------- This is the result of the IPv6 RFC rule for crafting layer 2 addresses from an IPv6 multicast

--Andrew

2 Likes

Cleared… Nice post

But Rene, is it possible to do show arp like we do in IPV4. I know there is no “ARP” in ipv6, But i want to know the Bindings and optionally the directly connected ip addresses

Found it ?! :slight_smile:

Router#show ipv6 neighbors 
IPv6 Address                              Age Link-layer Addr State Interface
FC80::A8BB:CCFF:FE00:200                   37 aabb.cc00.0200  STALE Et0/0

yup that’s it :slight_smile:

Hi Jose,

When the router (or host) receives a packet with destination FF02::1 then it will respond to the source address. This will initiate the Neighbor Solicitation, the router that sent the original packet to FF02::1 will reply with a Neighbor Advertisement.

Here’s a Wireshark capture of this process:

So let’s assume that I have to connect two router interfaces R1 and R2. I am already on R1 but I don’t know link local IPv6 address of R2 interface. I can just open wireshark, ping FF02::1 and listen to NA and get R2 link local address? Can I only get link local address? What about global unicast? Are they only reachable by routing protocols which advertise certain network?

<<You can also see that R1 receives a neighbor solicitation from R2 and replies with the neighbor advertisement. Here’s what it looks like on R2:>>
Hi,
Rene ,why R1 needs to receive a neighbor solicitation from R2 when the two parts already they now mac-address and ipv6 address of each other?

thanks

Hello Dionisis.

I was unable to find the quote you are referring to so I do not know the context of your question. Can you be more specific as to the quote you mentioned?

Thanks!

Laz

19 posts were merged into an existing topic: IPv6 Neighbor Discovery Protocol on Cisco Router

Hi,
My topo:
[R1]----[R2]
When both router booted up, I first configured R1 interface as 2001::1/64 IPv6, and hasn’t configured R2 yet. But I can see from packet capture that R1 is sending NS and NA both. Without configuring R2, why R1 sent NA? And after that, if I configure R2 with 2001::2/64 interface, I notice the same behaviour. Please find the pcap and interface show o/p. Please let me know the correct behaviour?
==============================
PCAP: https://www.cloudshark.org/captures/623abeaa7dc5
==============================

R1:
ESW1#sh ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C001:8FFF:FEEF:0
  No Virtual link-local address(es):
  Global unicast address(es):
    2001::1, subnet is 2001::/64
  Joined group address(es):
    FF02::1
    FF02::1:FF00:1
    FF02::1:FFEF:0
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds

=================================================

R2:
ESW2#show ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C002:8FFF:FEF7:0
  No Virtual link-local address(es):
  Global unicast address(es):
    2001::2, subnet is 2001::/64
  Joined group address(es):
    FF02::1
    FF02::1:FF00:2
    FF02::1:FFF7:0
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds

Hello Rahul

Whenever you configure an interface to function as an IPv6 interface, it automatically sends out NS messages.
This will occur even BEFORE any IPv6 addresses have been configured. You can see from your capture and from your CLI that you have posted, that both R1 and R2 have link-local addresses of FE80::C001:8FFF:FEEF:0 and FE80::C001:8FFF:FEF7:0 respectively.

As for the NA message, those are sent under two conditions: The first is as a response to an NS and the second when there is a change in the link-layer address of a node on a local link. When this occurs, the destination address for the neighbor advertisement is the all-nodes multicast address.

Let’s take a look at the NAs from your output. Looking at packet number 2 you have:
Source fe80::c001:8fff:feef:0
Destination ff02::1
The destination is the all-nodes multicast address. So this NA was a result of a change on the link, specifically, the automatic configuration of the link-local address.

Similarly, packet number 8 is an NA with the following characteristics:
Source 2001::1
Destination ff02::1
Notice again, the destination is an all-nodes multicast address, therefore this NA has also been sent because of a change on the link-layer address. We can see the change that was made from the Source which is now 2001::1 which is the address you configured on the interface.

Network advertisements 16 and 22 can also be analysed in the same way, and you can see that those are the corresponding NAs from R2.

So you can see that an IPv6 interface will always send NS messages, will send NA messages as a response to NS messages OR will send NA messages whenever there is a change to the link address.

I hope this has been helpful!

Laz

1 Like

if you also have a global unicast address configured on an interface, this ipv6 NS/NA process should it be done again by the router, for every type of ipv6 addr (unique local, global unicast, , link-local)?

1 Like

This is a very good question, I actually would like to know this as well. If I have time tonight I will lab this and watch the results in wireshark and report back. I might not be able to lab this until tomorrow.

Regards,
Scott

@castrojuanj
Hello Juan,
I hope you are doing well,
I have labed your question and took a packet capture to see if I can help you understand NDP better.

First off a link-local address is configured in two ways.

  1. The administrator specifies the link-local address to be used
  2. The local router uses eui-64 to generate the proper IP address for link-local use

Now if you have a unique local and global unicast IP address assigned to the same interface and it receives an RS, it will the respond with an address for both unique local and global unicast addresses. So no the router only needs to go through the RS/RA process once to get IP addresses, and the auto config command only needs to run on the remote router once.

Also I have included a pcap file that will let you see what I did in wireshark.

NDP example.pcapng (5.2 KB)

I hope this helps!
Scott

1 Like

Yes, off course it helps !

Thank you so much for your time and reply. Have a nice weekend.

2 Likes