Neighbor Discovery Protocol on Cisco Router

Routing & Switching IPv6
1

I am using Packet tracer and enabled IPv6 as described in the lesson. When I attempt to ping the neighbor using the auto-generated address I get error message below:

Router#ping FE80::201:42FF:FE0D:7101
**% Unrecognized host or address or protocol not running.**
After playing around with the router config, I realized I wasn’t getting anywhere. So I decided to just configure a global address and attempted pinging again and it worked

Is this unique only to Packet Tracer or is that how it should be configured? I noticed you didn’t have to do that when you demonstrated. I had to do the same on the neighboring router for ping to work.

I enabled debug but I don’t see all the messaged that you demonstrated. I only see the below messages and that’s it. I see the same on the neighbor. Is this also unique to Packet Tracer that I only see few messages?

Router(config-if)#do ping FE80::201:42FF:FE0D:7101
Output Interface: gigabitethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::201:42FF:FE0D:7101, timeout is 2 seconds:
***Mar 1 11:05:48.537: ICMPv6-ND: Sending NS for FE80::201:42FF:FE0D:7101 on GigabitEthernet0/0**
***Mar 1 11:05:48.539: ICMPv6-ND: Received NA for FE80::201:42FF:FE0D:7101 on GigabitEthernet0/0 from FE80::201:42FF:FE0D:7101**
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/7 ms

Your demonstration shows all the back and forth below messages:

R1#
ICMPv6-ND: DELETE -> INCMP: FE80::C002:3FF:FEE4:0
ICMPv6-ND: Sending NS for FE80::C002:3FF:FEE4:0 on FastEthernet0/0
ICMPv6-ND: Received NA for FE80::C002:3FF:FEE4:0 on FastEthernet0/0 from FE80::C002:3FF:FEE4:0
ICMPv6-ND: Neighbour FE80::C002:3FF:FEE4:0 on FastEthernet0/0 : LLA c202.03e4.0000
ICMPv6-ND: INCMP -> REACH: FE80::C002:3FF:FEE4:0
ICMPv6-ND: Received NS for FE80::C001:2FF:FE40:0 on FastEthernet0/0 from FE80::C002:3FF:FEE4:0
ICMPv6-ND: Sending NA for FE80::C001:2FF:FE40:0 on FastEthernet0/0

Question 2

During Neighbor solicitation, you mentioned that the destination address is the Neighbor’s Solicited Multicast Address. And that the sender knows about the neighbor address because it was given to it. How was the sender notified of the solicited multicast address? You also mention that the sender computes the neighbor solicited multicast address. Why would it need to compute it if it was already supplied/given to it already?

2

Hello Ibmufa!

I just tried what you suggested on Packet Tracer and everything seems to work fine. I was trying to recreate what you decribe by removing the global ipv6 unicast-routing or the ipv6 enable interface commands, however I was unable to reproduce your results. I am using Packet Tracer version 7.X. To troubleshoot your issue more thouroughly, can you share some more of your configuration?

Concerning your other questions:

During Neighbor solicitation, you mentioned that the destination address is the Neighbor’s Solicited Multicast Address. And that the sender knows about the neighbor address because it was given to it. How was the sender notified of the solicited multicast address?

When IPv6 is enabled on an interface, several things begin to happen. It obtains a link-local address and it also computes and joins the solicited node multicast group address. How is this determined? Well, here’s an example:

Assume a host needs to make a local delivery to another host on the local network, and the target host has an IPv6 address of fe80::2aa:ff:fe28:9c5a. In order to make a Layer-2 (e.g. Ethernet) delivery, it needs to know the target host’s hardware address (e.g. “Ethernet MAC address”). But in order to do this, it must first determine which hardware address to send it to. To do this, an IPv6 host will construct the Solicited-node Multicast Address related to the target address.

We can see this clearly if we look at an example using the equivalent uncompressed IPv6 address.

fe80::2aa:ff:fe28:9c5a                      Target address (compressed notation)
fe80:0000:0000:0000:02aa:00ff:fe28:9c5a     Target address (uncompressed notation)
                                -- ----     the last 24-bits
ff02::1:ff00:0/104                          Solicited-node Multicast Address prefix
ff02:0000:0000:0000:0000:0001:ff00:0000/104 (uncompressed)
---- ---- ---- ---- ---- ---- --            The first 104 bits
ff02:0000:0000:0000:0000:0001:ff28:9c5a     Result
ff02::1:ff28:9c5a                           Result (compressed notation)

The result of this process is the IPv6 link-local solicited node multicast address that the Neighbor Solicitation packet is sent to.

You also mention that the sender computes the neighbor solicited multicast address. Why would it need to compute it if it was already supplied/given to it already?

To clarify once again, the Solicited Multicast Address is not “given” to it, but it is obtained by computing it.

I hope this has been helpful.

Laz

3

Thank you Laz!!! for the clarification on Solicited Node Multicast Address. On the other question with error, perhaps it’s because of the version of packet Tracer - I am using 6.3.0.0008.

4

Hello Ibmufa

It may be the version of packet tracer I don’t know. However, it still sounds like a very strange error. Have you tried redoing the lab on packet tracer again since then? Give us an update when you can…

Thanks!

Laz

5

Hi Rene and Laz,

In a paragraph, you mentioned
“It can calculate the solicited node multicast address of the remote host since it knows about the multicast group address and it knows the IPv6 address that it wants to reach.”

  1. Is the IPv6 destination address provided by the Application? Is this the IPv6 address by EUI-64?
  2. Also, how does the sending host know about the solicited node multicast group address of the destination host?
  3. Which solicited node multicast group address of the destination host does the sending host get to know? Is it the link-local multicast address or the Unique local multicast address or the Global unique multicast address?
  4. Which multicast groups become common for hosts on a local LAN network so that they can communicate?

Sorry about these many questions but I really want to get a clear light on this.

Thanks
Ajeet

6

Hello Ajeet

First of all, no need to apologise for the many questions. That’s what we’re here for!

I’ll address your questions individually below:

First let’s clarify that the purpose of an NS message is to find the Layer 2 address, or MAC address of the connected node. This means we already know the IPv6 address. How do we know this address? In the example in the lesson, we have two routers. So this is most likely one hop in a series of many hops to get the actual payload to the destination. In this case, it may be that R1, using a routing protocol, determines that the next hop router is R2. It knows the next hope IP address either because it is statically configured or because it has learned it from a routing protocol. If it doesn’t know the MAC address, it will then go into the process of sending the NS.

The sending host knows the next hop IP address it wants to reach, most likely because it is statically or dynamically placed in the routing table as a next hop IP. It als knows that all multicast group addresses begin with FF02::1:FF /104. So it will take this multicast group address and add the last 6 hex characters from its already known IPv6 address. So it has all the information it needs to compute this solicited-node multicast address.

According to RFC2373, a solicited-node multicast address is calculated by each router for itself for every unicast address it has. This includes both link local and the global unicast addresses. So both multicast addresses would work in this case. However, when routers are communicating with each other over IPv6, they usually prefer to use the link-local addresses. These will always take precedence in such transactions. Only if there is no link-local address (explicitly configured) would it use the global unicast solicited-node multicast address.

Multicast ranges for IPv6 have been reserved much like they have for IPv4. There are various ranges, however, the ffx3::/16 scope is the equivalent of the 239.255.0.0/16 mutlicast range for IPv4. There are also ranges such as ffxe::/16 which are eligible to be used as multicast over the public Internet. You can find out more information about multicast for IPv6 at this lesson:

I hope this has been helpful!

Laz

7

Hi Laz,
Thanks a lot for such a detailed explanation. The process of NDP is very clear to me. :smile:

1 Like