IPv6 Prefix Length vs Subnet Mask on CCNA Exam

Both interfaces are up/up. Note the IPv6 addresses: R1 has /64, R2 has /32. This mismatch in prefix length is a red flag.

R1 shows a connected route for 2001:DB8:1::/64. Since R2's address is 2001:DB8:1::2/32, it falls within the /64 prefix, so R1 should have a directly connected route. If R2 had a different prefix (e.g., /32), R1 might not have a route. Here, the route exists, so the issue is likely at Layer 2 or neighbor discovery.

If the neighbor is not listed or state is not REACH, then neighbor discovery failed. Here, it is REACH, so Layer 2 is fine. The problem might be that R2's /32 prefix causes it to not consider R1's address as on-link, but neighbor cache shows it works. Actually, the issue is that R2's /32 prefix means it does not have a connected route for the /64 subnet, so it may not respond to pings from R1 if R1's source address is not within R2's configured prefix. Let's check R2's routing.

R2 has a connected route for 2001:DB8:1::/32. The source address 2001:DB8:1::1 is within this /32, so R2 should have a route. However, the problem is that R2's prefix length /32 is shorter than the actual subnet /64. When R2 receives a packet destined to 2001:DB8:1::2, it checks its routing table and finds the connected /32 route. But for neighbor discovery, R2 uses the prefix length from its interface configuration. With /32, R2 considers only itself as on-link; it will not perform neighbor discovery for other addresses within the /64. So R2 cannot reply to pings because it does not have a neighbor entry for R1. Actually, the neighbor cache on R2 might show R1 as INCOMPLETE. Let's verify.

The neighbor state is INCOMPLETE, meaning R2 cannot resolve R1's MAC address. This is because R2's /32 prefix causes it to not consider R1 as on the same link. R2 does not send Neighbor Solicitations for addresses outside its on-link prefix. Thus, the ping fails.