IPv6 Neighbor Discovery Protocol on Cisco Router

(Andrew P) #17

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

(Jie C) #18

Cleared… Nice post

(Jie C) #19

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

(Jie C) #20

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
(Rene Molenaar) #21

yup that’s it :slight_smile:

(Patryk T) #22

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?

(DIONISIS) #23

<<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

(Lazaros Agapides) #24

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

(Networklessons Admin) split this topic #25

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

(Rahul A) #27

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
(Lazaros Agapides) #28

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

(Juan C) #29

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)?

(Kevin W) #30

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

(Kevin W) #31

@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

(Juan C) #32

Yes, off course it helps !

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

(Brian C) #33

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:

(thierno b) #34

Hi Rene,

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

(Lazaros Agapides) #35

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

(Heng S) #36

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 ?

(Lazaros Agapides) #37

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