Articles
IPv6 Interview Questions: Neighbor Discovery, SLAAC, and Broken Connectivity
Practice IPv6 interview questions with Neighbor Discovery, SLAAC, router advertisements, and packet-based diagnosis of broken routes and MTU paths.
A host has a global IPv6 address but cannot reach another network. Small requests succeed while a larger response stalls. Someone suggests disabling IPv6. A stronger interview answer first separates address formation, route selection, next-hop resolution, and packet-size behavior.
IPv6 interview questions reward that separation. An address is not proof of connectivity: SLAAC can create an address from one Router Advertisement option while the same advertisement contributes no default router. Neighbor Discovery can resolve a local next hop without validating an end-to-end application path.
Evidence boundary: This article uses RFC-defined protocol behavior reviewed October 1, 2026 and original synthetic incidents. The address ranges, lifetimes, and packet observations are teaching fixtures, not live captures. Assume a conventional Ethernet-like host link and IPv6 forwarding unless stated otherwise; operating-system policy can add constraints.
Use Prepare for an SRE Systems Fundamentals Round for broader practice, then make the packet boundary explicit in each IPv6 answer.
What replaces ARP in an IPv6 explanation?
IPv6 Neighbor Discovery uses ICMPv6 messages for several jobs: discovering routers, learning link information, resolving neighboring link-layer addresses, and checking neighbor reachability. Calling it only “IPv6 ARP” misses those additional responsibilities. RFC 4861
Know four message types and their purpose: Router Solicitation, 133; Router Advertisement, 134; Neighbor Solicitation, 135; Neighbor Advertisement, 136. A host can solicit router information rather than merely waiting for a periodic announcement. A solicitation for a neighbor and a router advertisement are not interchangeable configuration messages.
For an off-link destination, the host resolves the selected next hop, not the destination's Ethernet address. Draw the route decision before the address-resolution exchange. Otherwise, an answer may correctly name NS and NA while sending them for the wrong target.
Valid Neighbor Discovery messages have specific checks, including a received Hop Limit of 255 for the relevant messages. That helps distinguish locally originated ND from traffic forwarded through a router. It is not a rule that every IPv6 packet or every ICMPv6 message must have that value.
How do link-local addresses differ from global addresses?
A link-local address is scoped to a link. The same textual address can require an interface identifier to select the correct link on a multi-interface host. A command using fe80::1 without the relevant zone or interface may therefore be ambiguous.
For an authorized Linux lab, an illustrative observation command is:
ping -6 -I eth0 fe80::1
The interface name is an example, not a claim about the interview machine. An operating system can also support textual zone notation such as %eth0. Do not infer routability beyond the link from a successful link-local exchange.
Global addressing and link-local router communication can coexist. A default route may name a link-local next hop even when the source used for an external connection is global. This is expected, not proof of malformed routing.
Address creation also involves Duplicate Address Detection under the assumptions described in RFC 4862. A tentative address displayed by a tool is not necessarily ready for ordinary traffic. Read address state rather than treating every printed address as usable.
Which Router Advertisement fields control SLAAC and routing?
SLAAC means Stateless Address Autoconfiguration: the host can form an address from advertised information without a server maintaining the same kind of address lease as DHCPv4. Prefix Information Options and their flags govern relevant prefix behavior. RFC 4862 address autoconfiguration
For the conventional interface model here, an eligible /64 prefix with the Autonomous flag permits address formation when the other validity conditions hold. The On-link flag concerns whether that prefix is treated as on-link. They are separate decisions. An unset On-link flag is not a general declaration that every address in the prefix is definitely off-link.
Router Lifetime concerns use of the advertising router as a default router. A zero value means this advertisement does not add or retain that router as a default candidate under the relevant rules. It does not automatically revoke an independently valid SLAAC address from its prefix option. RFC 4861 Router Advertisements
Keep the scope narrow: “no default router from this RA” is different from “the host has no default route.” Another router, a static route, or another routing mechanism may already provide a path. Inspect actual host state before making the stronger conclusion.
Original incident: valid prefix, missing default router
Assume this synthetic host has no pre-existing default route and receives one valid Router Advertisement:
| Observation | Synthetic value | What it can establish |
|---|---|---|
| Prefix | 2001:db8:10::/64 | Candidate address prefix under the stated link model |
| Autonomous flag | 1 | Address formation is permitted if remaining checks pass |
| On-link flag | 1 | Prefix is advertised for on-link determination |
| Preferred / valid lifetime | 1,800 / 3,600 seconds | Address lifetime information |
| Router Lifetime | 0 seconds | No default router from this advertisement |
After successful address formation and DAD, the host displays 2001:db8:10::23/64. A peer on the advertised local prefix is reachable, but an external destination has no route. Those observations are consistent: local addressing and off-link forwarding depend on different state.
The next step is to inspect routes and the intended router configuration. Do not delete the address or restart DNS because an external request failed. A resolver change cannot create a missing default route.
Use read-only Linux inspection examples:
ip -6 addr show dev eth0
ip -6 route show
ip -6 route get 2001:db8:20::80
ip -6 neigh show dev eth0
The 2001:db8 addresses are documentation examples, not public targets to probe. These commands were not run against a customer network for this article. Their purpose is to describe which evidence would distinguish unusable address state, missing route, and unresolved next hop.
How do address lifetimes change the diagnosis?
Preferred and valid lifetimes are not synonyms. An address can become deprecated after its preferred lifetime while remaining valid for existing use under the protocol and host-selection rules. When its valid lifetime expires, it is no longer a valid assigned address. RFC 4862 lifetimes
For the synthetic 1,800/3,600-second fixture with no refresh, inspect the state after the preferred boundary and again after the valid boundary. Do not assume the host immediately drops every established connection at the earlier time; the distinction exists precisely because new selection and continuing validity differ.
Router information has its own expiration. A once-successful request does not prove a default router remains available now. Conversely, an expired router entry need not imply the host lost every address. Correlate the failure time with the relevant state transition.
When advertisements refresh lifetimes, actual rules and protections matter; avoid inventing a universal “replace every timer immediately” algorithm. State the simplified no-refresh assumption in an interview trace and consult the protocol or implementation for recovery behavior.
What does a failed neighbor entry prove?
It means the host's neighbor-resolution or reachability process did not establish the required local delivery state at that observation point. It does not identify one universal root cause. The target might be absent, the VLAN wrong, multicast filtered, the solicitation unanswered, or the response lost.
First verify the selected route and next-hop address. Then inspect whether NS leaves the correct interface and whether the corresponding NA returns. A capture on the wrong interface can make a working exchange look absent.
A STALE entry is not the same as a failed neighbor. The cache state machine distinguishes older reachability information from an established failure. Do not flush every entry merely because it is not labeled REACHABLE. RFC 4861 neighbor states
Any capture requires authorization and careful handling of network identifiers and payloads. In an interview, explain the expected packet sequence and the observations that would choose the next branch; do not pretend the synthetic fixture is a real tcpdump session.
Original incident: small traffic works, large packets stall
Assume route selection and next-hop delivery work. A TCP connection opens and small exchanges succeed, but a larger transfer repeatedly stalls along a path whose actual MTU is 1,280 bytes. The sender initially attempts larger packets, and the needed Packet Too Big information does not arrive.
IPv6 routers do not fragment forwarded packets to make them fit a smaller downstream link. Path MTU Discovery uses ICMPv6 Packet Too Big information so the source can adjust packet size; source fragmentation is a separate capability. See RFC 8200 and RFC 8201.
For a simple echo packet with no extension headers, a 1,280-byte packet budget minus the 40-byte IPv6 header and 8-byte ICMPv6 echo header leaves 1,232 payload bytes. This arithmetic was checked independently; it is not a measured path discovery result.
Blocked Packet Too Big traffic is a plausible hypothesis for the stated symptoms, not proof from “large request hangs” alone. A proxy limit, application timeout, loss, or another transport issue could also distinguish large and small requests. Compare packet sizes, retransmissions, and feedback at appropriate points.
The safe repair discussion concerns the specific missing feedback or path configuration. “Allow all traffic” and “disable IPv6” are not evidence-based conclusions. Verify the intended ICMPv6 policy and repeat a controlled size comparison after an authorized change.
Where do DNS and DHCPv6 fit?
Resolving an AAAA record proves the resolver returned an IPv6 address, not that a usable IPv6 path exists. Compare the actual destination, selected source, route, and transport outcome. IPv4 fallback can make a browser look healthy while the IPv6 path remains broken.
Do not transfer DHCPv4 assumptions wholesale. Address assignment, default-router discovery, and DNS configuration have distinct IPv6 mechanisms. A host receiving address information does not thereby prove default routing. The earlier RA lifetime case remains possible even when other configuration looks correct.
Router Advertisements can also carry recursive DNS server information with its own lifetime under RFC 8106. Receiving that option is not proof the advertised resolver responds or provides the intended answer.
A useful three-way comparison is: direct destination-address connection, hostname resolution, and hostname-based application request. Explain what each result isolates. Keep SNI, certificates, and HTTP behavior separate when an address-only test differs from a hostname-based one.
What should a strong troubleshooting answer conclude?
State the last proven boundary and the first unproven one. In the missing-route fixture, address formation and local delivery succeed while off-link routing is absent. In the packet-size fixture, ordinary connectivity exists but path-size feedback is suspect and needs packet evidence.
Then propose one authorized, bounded change and an independent verification. Preserve before-and-after address, route, neighbor, and request evidence. A newly successful request is useful, but continuing lifetimes, other clients, and the previously failing packet size still matter.
The answer is not “IPv6 is complicated.” It is a sequence of distinct contracts that you can test without changing everything at once.