IPv6 Neighbor Discovery Protocol on Cisco Router

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

2 Likes

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

you state this twice. Once here and once above. The first time you stated it I was not sure as I just thought on it briefly. Not liking the answer but then you state it again here so I thought on it a few moments more.

It then started to make sense I understood why the question was asked however but the answer was so basic it was hard to accept.

Basically, anytime you go somewhere there is normally a method a destination and its the same here with the answer. This entire teaching component is about how to find the Layer 2 as this has replaced ARP.

Everyone that asked the question including myself over complicated it because the reality is the answer is so simple.

You have a destination in this format the destination is described by IP addresses. So if you know the destination then you know the IP address which then you know the multicast node and you also know it uses the last 5 hex of the IP address so you know what the specific multicast node is to basically request the layer two.

Once you have the layer two just like ipv4 you still have an adjancey table with all the MACs associated with the IPs.

The question is then not what is the destination because now we know that but why do you want that destination now that is something to think deeper on.

You may not really want the destination of the connected router but perhaps only be traveling through it to another router to another destination.

I think it would be nice to have illustration setup for IPV6 like those old ipv4 summaries where it tells you how to travel from Point A to Point E and it progresses through switching and a couple of subnets there would be less questions and it would be much more clear as I always turned to those on ipv4 when I forgot something or became confused and needed to resettle my mind.

those obviously took you through a few technologies as you followed the packet but it was really nice to have and kept the world right side up. I would love to have one of those for ipv6 :slight_smile:

2 Likes

Hi Rene,

Why not send the neighbor discovery to directly to the FE80 instead of using multicast group address FF02::1:FF /104

Hello Thierno

At this point, R1 knows the IP address of R2, so it makes sense to ask the question, why not send it directly to that IPv6 address and not use the multicast? The reason is because the purpose of the Neighbour Solicitation is to find out what the MAC address is. If R1 sends an IPv6 packet to R2, it will use its IPv6 address and then as it encapsulates the packet into a frame, it needs the MAC address, but it doesn’t know it. This is why the FE80 IPv6 address cannot be used for the NS message.

Now in IPv4, an ARP would be sent out. However, the NS procedure replaces ARP. So, instead of using the ARP procedure where all nodes on the subnet are queried for the particular MAC address, the solicited node multicast address is used instead. This doesn’t require a specific MAC address to reach R2 as described in the lesson. Once the NS reaches R2 using the multicast address, R2 will respond with an NA with its MAC address.

From there on all communication can take place using the specific IPv6 address of each node.

I hope this has been helpful!

Laz

1 Like

Hi Rene
In you example NS is looking for layer 2 address of R2 iPV6 link local address, so R1 use its link local address as the source IP in the message. How about if R1 send NS looking for layer 2 address of Unique Global IPV6 address of R2, which IP will it use as the source IP to send NS ?

Hello Heng

Regardless of what IPv6 address it is looking for (Global Unicast or Link Local), the source IP address of an NS will typically be the Link Local address. A general rule of thumb is that control protocols such as NS, RS, DAD and others associated with IPv6 use the link local addresses because the mechanisms of these protocols apply to the local segment of a network. Since Global Unicast addresses are not necessarily configured on devices, and indeed are not always necessary, they cannot be relied upon for such features.

I hope this has been helpful!

Laz

Hello Laz,
I have two questions

  1. you said that "NS, RS, DAD and others associated with IPv6 use the link local addresses "
    then DAD can’t discover a duuplicate global unicast ip in the same subnet !? nor a duplicat loopback ipv6 ? nor a duplicate unique local ip v6 ?
    and as each interfaces and devices could have a very lot of ipv6 address (except link local, which be unique for each subnet), a couple of ipv6 duplicate address in some ipv6 devices could nerver be discover (except when on of them is suddenly use by an application) ?
    Am I right ?

  2. do you know if devices never send multicast DAD request and only answer to them (with theyre lin-local address), and if only interfaces send multicast DAD request ?

Hello Hugues

To clarify, link-local addresses are used in the neighbor discovery protocol (NDP) which includes RS, RA, NS, and NA packet types. What this means is that the communication taking place for such packets has source and destination IPv6 link-local addresses.

Now DAD is a special case, because it too uses NS packets, however, it uses them a bit differently. When an interface is assigned a global unicast address, initially known as a tentative address, it will join the solicited-node multicast address for that tentative address. It will also join the all-hosts multicast address of ff0::1 so it will be able to receive NAs as well.

Now DAD then begins to function by sending NS packets using its own (newly assigned) IPv6 global unicast address as a destination address, and uses ::/128 (meaning unspecified) as the source address. So in simple terms, it is trying to ping it’s own address. If it gets a response from elsewhere, then the address is not unique. The same is true if the node receives an NA with the same address as its tentative address. If no response and no NA from the same address is received, the address is considered unique and is no longer considered tentative, but permanent.

Remember that DAD only checks to make sure that there are no duplicate addresses on the same LAN segment. It is possible to have duplicate IPv6 addresses on different LAN segments, and when used as Anycast addresses, and is configured correctly, this is a valid configuration.

I hope this has been helpful!

Laz

Hi Lazaros,
What is the difference between EUI configured IPV6 address and Link-local?
As in the example R1 and R2’s solicited node multicast addresses made up of R1 and R2’s MAC addresses, and this rule is also applied in EUI using 48 bits from MAC addresses and 16 bits FFFE.

Hello Muhammad

The EUI 64 method is one of several ways in which an interface can obtain an IPv6 address. Now EUI-64 process can be used to configure either a link-local IPv6 address OR a global unicast IPv6 address. The EUI-64 is the process used to determine those addresses. The specific process is further described in this lesson:

If applied to obtaining a link-local address, the address begins with fe80:0:0:0 as the first 64 bits, and the rest of the address is determined by the EUI-64 process.

If applied to obtaining a global unicast address, then it uses the desired network prefix, and adds the last 64 bits obtained via the EUI-64 process. This is further described in the SLAAC lesson below:

Now for the specific example, the reason that you see the EUI process in action is the fact that the solicited node multicast address was obtained using it’s IPv6 address as described in the lesson:

Every IPV6 device will compute a solicited node multicast address by taking the multicast group address (FF02::1:FF /104) and adding the last 6 hexadecimal characters from its IPv6 address. It will then join this multicast group address and “listens” to it.

But it’s IPv6 address was obtained using the EUI-64 process, and that is why you see the MAC address represented within the multicast address.

I hope this has been helpful!

Laz

1 Like

I have a question regarding the following statement. I’m not quite understand about the remote host.

The result will be that only the remote host will receive the neighbor solicitation. That’s far more efficient than a broadcast that is received by everyone…

Since all the devices with ipv6 enabled will automatically generated a solicited node multicast address, how does it different from the broadcast since all the devices will receive the packets.

Hello Po

Even though multicast is being used for this mechanism, a Neighbor Solicitation will not be broadcasted or multicasted to multiple hosts. The NS will go only to the single host that requested it. This is because the solicited note multicast address defines a multicast group which contains a single host. The multicast address is computed by taking the multicast group address of FF02::1:FF /104 and adding the last 6 hex characters from the IPv6 address of the specific host. This creates a unique multicast address that corresponds to a single device, making an NS much more efficient than the counterpart IPv4 process which uses broadcast.

I hope this has been helpful!

Laz

Hi Lagapides,

Why both router perform NS, NA to each other. let’s say R1 router send NS to R2 then R2 router send NA to R1 . In this communication both Router should know their L2 address right ?? So why R2 will send NS to R1 and R1 will send NA to R2 ??Thx

BR//ZAMAN

Hello Zaman

You are absolutely correct in that a single NS sent with an NA reply will allow both sender and target to obtain each other’s MAC addresses and to resolve them to IPv6 addresses. RFC 4861 which describes Neighbor Discovery in IPv6 states the following:

A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other’s link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation.

However, because NS and NA messages are used for more than just resolving the MAC address to the IPv6 address, this process is performed in both directions. Specifically, NS is used to verify that a neighbor is still reachable, and this is achieved by periodically sending out NS and expecting back NAs. This is performed in both directions. NS and NAs are also used to perform Duplicate Address Detection (DAD) which requires the exchange in both directions.

I hope this has been helpful!

Laz

Hi Rene and staff,

may we dive deeper with IPV6 redirect messages ?
I want to interpret the fields Target address and Destination Address in the capture below

We know that the host fe80:260:x send a ping to the host 3000::1 via the option which contains the IPV6 initial packet
So, the router fe80:2b0:y send a reply to the host fe80:260:x, that is a redirect message with target address and Destination address

I read this (not in a RFC)

This is a bit confusing…(for me)
In the example, Target address has not the same value as Dest address
Target address is the router link-local and Dest address is 2001:db8::1

Could you help me to interpret these fields and the redirect message ?

Regards

Hi Rene and staff,
still studying ipv6 and testing ND cache, ipv6 states, NUD, etc …
and relative cisco commands
So i do a basic lab with 2 CiscoIOSv15.6(1)T-1
Image16
I set a static entry in the ND cache and i cannot delete it. Please look the above pic


I google the error message “Failed to delete ND entry”, but found nothing
Could you help me to understand ?
Regards