yup that’s it 
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
1 Like
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 millisecondsHello 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.
- The administrator specifies the link-local address to be used
- 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 
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
-
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 ? -
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