IPv6 changes more than the length of an IP address. It changes how hosts discover routers, resolve neighboring Layer 2 destinations, configure addresses, and use multicast on a local link. Neighbor Discovery (ND), carried through ICMPv6, replaces several IPv4-era mechanisms and makes router advertisements central to host behavior. Engineers who memorize address notation without understanding these local-link exchanges miss the part of IPv6 that most often explains real connectivity problems.
Within IPv6 Addressing and Neighbor Discovery, the current 200-301 CCNA v1.1 exam includes IPv6 addressing, prefix configuration, and address types. The practical objective is broader: recognize which parts of a working IPv6 host come from the interface itself, which come from router advertisements, which may come from DHCPv6, and how Neighbor Discovery creates the neighbor and default-router information needed to send traffic.
Begin with the IPv6 addresses a node uses on the local link
An IPv6 interface commonly has a link-local address in FE80::/10 and may also have one or more global or unique-local addresses. Link-local addresses are not routed across normal IPv6 hops, but they are essential to local control-plane behavior. Routers can use link-local addresses as next hops, and Neighbor Discovery messages rely heavily on local-link communication.
Global unicast addresses are the normal routable addresses used across IPv6 networks. Unique local addresses provide privately scoped addressing semantics but are not a direct IPv6 replacement for the operational assumptions of IPv4 NAT. Multicast replaces broadcast for many discovery functions, and IPv6 has no ordinary broadcast address.
The IPv4 and IPv6 comparison is most useful when it focuses on behavior rather than just notation. IPv6 still needs routing, prefixes, DNS, and security policy, but its local discovery process is fundamentally different.
Link-local scope means the interface identifier matters when a router has several links. A next hop of fe80::1 is ambiguous without knowing which interface reaches that neighbor, and operating systems may display a zone or interface index for that reason. Engineers should become comfortable seeing link-local next hops in routing tables because they are normal in IPv6. Trying to replace every link-local next hop with a global address can complicate a design that already works as intended.
Use Router Solicitation and Router Advertisement to learn the link
Routers periodically send Router Advertisement (RA) messages, and a host can send a Router Solicitation (RS) when it wants information sooner. RAs can announce on-link prefixes, prefix lifetimes, default-router information, and flags that influence how hosts obtain address configuration. For normal Stateless Address Autoconfiguration (SLAAC), a /64 prefix is the standard expectation.
A host does not learn its IPv6 default gateway from DHCPv6 in the same way an IPv4 client commonly learns a gateway from DHCP. The default-router relationship comes from Router Advertisements. This is one reason an IPv6 endpoint can receive DNS or other DHCPv6 information yet still lack useful off-link connectivity if RAs are filtered or misconfigured.
Troubleshooting should therefore include capturing or inspecting RAs on the affected VLAN. If one segment works and another does not, compare advertised prefixes, router lifetime, flags, and source link-local addresses before assuming the problem is a routed-core failure.
Router Advertisements also carry lifetimes, which makes stale or conflicting information possible during migrations. If an old router continues advertising a prefix or default-router lifetime after the new gateway is introduced, hosts may hold multiple routers and select behavior that differs across operating systems. Planned changes should withdraw obsolete prefixes and router roles cleanly rather than assuming clients will forget them immediately when a cable is moved.
Understand SLAAC and Duplicate Address Detection as separate steps
SLAAC allows a host to construct an IPv6 address from an advertised prefix plus an interface identifier generated by the host. Modern operating systems may use privacy or stable-randomized interface identifiers rather than exposing a MAC-derived identifier. The important network fact is that the prefix and host portion combine locally without a stateful server assigning each address.
Before using a newly formed address, a node performs Duplicate Address Detection (DAD) using Neighbor Discovery. It checks whether another node is already using the tentative address. If a duplicate is detected, the address should not become a normal usable interface address.
SLAAC, DHCPv6, and static addressing can coexist in different combinations. The DHCPv6 relay model should be studied separately from IPv4 ip helper-address behavior because the message transport and gateway-learning roles are different.
Privacy extensions and stable randomized interface identifiers mean the same host can present multiple IPv6 addresses over time or simultaneously. Monitoring and access policy should not assume the lower 64 bits permanently identify one device. Where durable identity is required, use authenticated device identity, DHCPv6 information where appropriate, endpoint management, or other inventory signals instead of treating an observed IPv6 address as a permanent asset identifier.
Replace ARP thinking with Neighbor Solicitation and Advertisement
IPv4 uses ARP to resolve an IP address to a local Layer 2 address. IPv6 Neighbor Discovery uses Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages for a similar neighbor-resolution purpose. A node that wants to reach an on-link IPv6 neighbor sends a solicitation, and the neighbor responds with an advertisement containing the information needed to populate the neighbor cache.
IPv6 does not flood every host with a broadcast ARP request. Neighbor solicitation commonly targets a solicited-node multicast address derived from the destination IPv6 address. This narrows the group of nodes that must process the request. The solicited-node multicast group is therefore a practical part of how IPv6 avoids broadcast-style address resolution.
When a neighbor cache entry becomes stale or unreachable, Neighbor Unreachability Detection helps the stack determine whether the path to the neighbor still works. Local IPv6 failures can therefore involve state in the neighbor cache even when routes are correct.
Neighbor Discovery also supports reachability confirmation after address resolution. A neighbor cache entry can move through states as the node decides whether the peer is still reachable. This matters when a Layer 2 path changes without the address changing. Clearing the entire neighbor table may temporarily hide the symptom; inspecting the state and understanding why reachability failed can reveal an underlying switch, wireless, or first-hop redundancy problem.
Learn the main IPv6 address types by forwarding meaning
Global unicast addresses are routable across IPv6 networks according to routing policy. Link-local addresses are valid only on the local link and require an interface context when the same link-local value could appear on multiple interfaces. Multicast addresses represent groups. The loopback address ::1 identifies the local host, and the unspecified address :: is used when a node does not yet have a usable source address in specific initialization contexts.
Anycast is a delivery model in which the same unicast address is assigned to multiple nodes and routing delivers traffic toward an appropriate instance. It is not identified by a special address prefix. Understanding that prevents confusion between address format and routing behavior.
IPv4-mapped or transition-related representations may appear in systems, but exam and operational reasoning should start with the native IPv6 categories used for endpoint configuration and routing.
Multicast scope is part of IPv6 operational literacy. Link-local multicast groups are intended for the local segment and are not simply routed like global unicast. Solicited-node groups are derived from address bits so only a subset of interfaces processes neighbor solicitations. When multicast filtering or switch features are involved, packet captures should confirm that required ICMPv6 multicast reaches the target rather than assuming IPv6 uses the same broadcast behavior as IPv4 ARP.
Keep ICMPv6 working because IPv6 depends on it
ICMPv6 is not merely a diagnostic protocol for ping. Neighbor Discovery uses ICMPv6, Router Advertisements are ICMPv6, and Path MTU Discovery depends on ICMPv6 messages. Security policies that block ICMPv6 broadly can break essential network functions while leaving the configuration looking otherwise correct.
Firewalls and ACLs should permit the specific ICMPv6 traffic required by the architecture while still enforcing legitimate security boundaries. “Block all ICMP” habits inherited from oversimplified IPv4 guidance are especially dangerous in IPv6 because the control plane uses ICMPv6 for normal operation.
When troubleshooting, confirm that NS, NA, RS, RA, and Packet Too Big messages can traverse the places where they are expected. A host that can reach same-link peers but not off-link destinations may be missing a usable RA rather than a static route on the core.
Path MTU Discovery is another reason broad ICMPv6 blocking creates failures that look mysterious. IPv6 routers do not fragment transit packets in the same way an IPv4 router historically might. If a packet is too large for a downstream link, the sender needs the appropriate ICMPv6 feedback to reduce packet size. Applications that work for small packets but stall on larger transfers can therefore point to broken ICMPv6 handling rather than to DNS or routing.
Protect the local IPv6 control plane from rogue advertisements
Because hosts can learn default-router and prefix information from RAs, an unauthorized device sending advertisements can disrupt traffic or redirect it. Enterprise access networks may use controls such as RA Guard and first-hop security features to restrict which switch ports are allowed to originate router advertisements.
Security controls must be tested with the actual endpoint and infrastructure behavior. Incorrect RA Guard policy can block the legitimate gateway just as effectively as it blocks a rogue one. Extension headers and platform-specific capabilities also matter, so use current switch guidance rather than relying on a generic configuration copied from a different model.
IPv6 security is not a separate project from IPv4 security. Dual-stack networks need equivalent segmentation, logging, ACL/firewall policy, and monitoring for both families. Otherwise IPv6 can become an unintended path around controls designed only for IPv4.
First-hop IPv6 security should include a trust map for which ports may send router advertisements or DHCPv6 server messages. Access switches can enforce controls, but virtualization, wireless tunneling, and extension-header behavior may alter where the enforcement point belongs. Validate with real captures from an authorized router and a test unauthorized host. Security is strongest when the team proves both that the rogue message is blocked and that legitimate control traffic remains functional.
Troubleshoot IPv6 in local-link order before blaming routing
Start with the interface: verify a link-local address, expected global or unique-local prefix, and correct prefix length. Then inspect Router Advertisements and the default-router entry. Next check the neighbor cache and attempt to reach the gateway’s link-local address. Only after the local control plane works should the investigation move deeper into routed prefixes and remote return paths.
DNS can create confusing symptoms because an AAAA record may cause an application to prefer IPv6 even when the IPv6 path is broken. The AAAA record should resolve to a reachable IPv6 service, and dual-stack troubleshooting should test A and AAAA paths independently.
The enterprise-routing context in 350-401 ENCOR becomes relevant when local IPv6 works but remote prefixes, summarization, first-hop redundancy, or policy do not. Separate host discovery from routed reachability so one layer does not hide the other.
When an IPv6 path fails only to some destinations, compare prefix length and route selection before changing RA settings. A host can have a healthy local gateway yet use a more-specific remote route that points into a broken tunnel or firewall. Traceroute, routing tables, neighbor entries, and packet-too-big messages form a layered evidence set. Treating every IPv6 issue as ‘Neighbor Discovery’ is as misleading as treating every IPv4 issue as ARP.
Plan IPv6 migration around coexistence and observability
IP address management should track IPv6 prefixes and ownership even when SLAAC assigns host addresses dynamically. The network team still needs to know which /64 belongs to each VLAN, which router advertises it, which DNS zones reference it, and which security policy applies. Prefix-level inventory replaces the IPv4 habit of tracking every client lease as the primary source of network structure.
Most enterprises move through a dual-stack period rather than replacing IPv4 in one event. Address plans, DNS, security rules, monitoring, and application tests must therefore describe both families. The IPv6 migration strategy should state which systems are native dual stack, which depend on translation, and which remain IPv4-only.
Monitoring should collect IPv6 interface state, neighbor-table changes, route reachability, RA behavior, and application success instead of declaring migration complete because addresses appear on interfaces. A device can have a valid global IPv6 address and still fail because the default router, DNS, ACLs, or remote return route is wrong.
Neighbor Discovery makes IPv6 local connectivity systematic: routers announce the link, hosts form and validate addresses, nodes resolve neighbors with multicast-based solicitation, and ICMPv6 carries the control information that keeps the relationship working. Once those roles are clear, IPv6 troubleshooting becomes structured rather than mysterious.
During packet analysis, filter specifically for ICMPv6 types associated with RS, RA, NS, and NA so the local-link conversation is visible. Seeing an RS with no RA points toward gateway or filtering behavior; seeing an NS with no NA points toward neighbor reachability. The packet sequence can turn a vague ‘IPv6 is broken’ report into a precise missing control-plane exchange.
Migration plans should also define how applications choose between address families. Happy Eyeballs behavior, DNS ordering, proxies, and security appliances can make a dual-stack application succeed even when one family is degraded, masking the defect until a client uses a different algorithm. Synthetic tests should force IPv4-only and IPv6-only connections separately so the team knows both paths are genuinely operational before declaring the dual-stack service healthy.