Debugging IPv6 Neighbor Discovery

R1 and R2 are on the same LAN segment via their f0/0 interfaces.

IPv6 addressing:

R1(config)#interface f0/0
R1(config-if)#ipv6 address 2001::1/64
R1(config-if)#ipv6 address FE80::1 link-local

R2(config)#interface f0/0
R2(config-if)#ipv6 address 2001::2/64
R2(config-if)#ipv6 address FE80::2 link-local

Let's also enable ipv6 icmp debugging since that what ipv6 uses instead of ARP tp discover neighbors:

R1#debug ipv6 icmp
ICMP packet debugging is on

R2#debug ipv6 icmp
ICMP packet debugging is on

Shut both interfaces down and bring them up at the same time. Here is what we see on R1:

R1#
*Mar 1 00:35:28.615: ICMPv6: Received ICMPv6 packet from FE80::2, type 136
*Mar 1 00:35:29.695: ICMPv6: Received ICMPv6 packet from 2001::2, type 136

R1 has received icmp type 136 messages from R2's ipv6 address and ipv6 link-local address. R2 will receive the same messages. However, each router still has not "discovered" the other router (in other words, the ipv6 to layer 2 mac address resolution has not taken place)

R1#show ipv6 neighbors
R1#

Let's ping from R1:

R1#ping ipv6 2001::2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 168/168/168 ms

on R1:

Jun 11 21:26:11.569: ICMPv6: Sending echo request to 2001::2
Jun 11 21:26:11.749: ICMPv6: Received ICMPv6 packet from 2001::2, type 136
Jun 11 21:26:11.813: ICMPv6: Received echo reply from 2001::2

on R2:

Jun 11 21:26:11.299: ICMPv6: Received ICMPv6 packet from 2001::1, type 135
Jun 11 21:26:11.343: ICMPv6: Received echo request from 2001::1
Jun 11 21:26:11.343: ICMPv6: Sending echo reply to 2001::1

Some of these things seem a bit out of sequence but let's analyze a little further. Specifically let's focus on icmpv6 message types 135 and 136. Looking up these codes at http://www.iana.org/assignments/icmpv6-parameters you will see that these are Neighbor Solicitation and Advertisement messages.

Here's the breakdown:

· When R1 sends a ping to 2001::2 it realizes it doesn't have the MAC address to put in that packet.
· It sends a icmpv6 type 135 message to FF02::1:FF00:2 which is the solicited-node multicast address for 2001::2
· R2 is listening to this address because for every ipv6 unicast address it owns, it listens for the corresponding solicited-node multicast address.

You can verify this as follows, look under the "Joined group address(es)" section to see the multicast addresses that this router is listening for:

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

· R2 will then see this message and reply because it's address, 2001::2 is in the "target" section of the packet.
· R2 responds with a type 136 neighbor advertisement message and put its MAC address in the portion of the icmpv6 packet designed for this purpose (of course the source of the packet also has the MAC address, but this is not used for resolution).
· Then R1 can send the icmpv6 echo, and R2 will reply (R2 already resolved R1's address via the very first packet it received from R1 which had both the IPv6 and L2 MAC addresses)

Let's check those neighbors now:

R1#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
2001::2 0 c201.0e8c.0000 REACH Fa0/0
FE80::2 10 c201.0e8c.0000 STALE Fa0/0