IPv6 transition is not one migration switch.

Real networks often operate for years with a mixture of:

• IPv4-only systems
• dual-stack systems
• IPv6-capable clients
• IPv6-only segments
• services that still depend on IPv4

An IPv6 transition failure becomes easier to isolate when three questions are answered independently: did the host configure a usable IPv6 address, did it learn a reachable default router, and can it resolve and reach the required service? A host can have a valid address while its router advertisements, DNS configuration or NAT64 path remain wrong. In an N10-009 IPv6 practice scenario, identify which observation distinguishes those failures before prescribing SLAAC, DHCPv6 or a translation mechanism.

• How does the client get an IPv6 address?
• How does it receive other network configuration?
• How does an IPv6-only client reach an IPv4-only service?

SLAAC, DHCPv6, and NAT64 answer different parts of that problem.

SLAAC lets a host build its own IPv6 address

Stateless Address Autoconfiguration, or SLAAC, allows an IPv6 host to configure addresses using information advertised by routers.

The core process includes:

• creating a link-local address
• receiving Router Advertisements
• learning an IPv6 prefix
• generating a global or unique address
• performing Duplicate Address Detection

The current SLAAC foundation remains RFC 4862, with later updates.

SLAAC does not require a DHCP server to assign every client address.

That is why the mechanism is called stateless address autoconfiguration.

The router advertises the network information, and the host forms the address according to the IPv6 rules.

Router Advertisements are central to SLAAC

IPv6 routers send Router Advertisement messages.

These can provide information such as:

• network prefix
• prefix lifetime
• default-router information
• flags related to address and other configuration

A client that receives no useful Router Advertisement can have a valid link-local address and still fail to obtain normal routed IPv6 connectivity.

When SLAAC troubleshooting begins, check:

• is IPv6 enabled on the interface?
• is the router advertising the expected prefix?
• is the client receiving RAs?
• is Duplicate Address Detection succeeding?
• is a default route being learned?

Do not start with DNS when the client has not configured a usable IPv6 address.

DHCPv6 provides managed configuration

DHCPv6 can provide IPv6 configuration through a client/server model.

The current DHCPv6 standards-track specification is RFC 9915, published in January 2026, which obsoletes RFC 8415.

DHCPv6 can provide:

• IPv6 addresses
• delegated prefixes
• other configuration parameters

depending on deployment.

DHCPv6 can operate:

• instead of SLAAC for selected address assignment
• alongside SLAAC
• only for additional parameters

This is why “IPv6 uses SLAAC, not DHCP” is inaccurate.

The two can coexist.

Stateless and stateful DHCPv6 are different concepts

In a stateful DHCPv6 design, the DHCPv6 server participates in address assignment and maintains lease-related state.

In a stateless DHCPv6 design, the host may create its address through SLAAC and use DHCPv6 for additional configuration information.

The exact behavior depends on router advertisements, client support, and deployment design.

When troubleshooting, verify what the network intends to provide.

A client that is using SLAAC correctly is not “missing DHCP” merely because there is no DHCPv6-assigned address.

Dual stack is the simplest coexistence model

In a dual-stack network, a device runs both IPv4 and IPv6.

That allows the host to communicate with:

• IPv4 destinations over IPv4
• IPv6 destinations over IPv6

This is conceptually straightforward.

It is operationally expensive because the network team has to maintain two protocol stacks.

That can mean duplicate effort for:

• addressing
• routing
• ACLs
• monitoring
• firewall policy
• DNS
• troubleshooting

Dual stack is often a practical transition method, but it does not eliminate IPv4 dependence.

It extends the period during which both protocols must be managed.

IPv6-only client segments reduce dual-stack complexity but expose legacy dependencies

Some organizations eventually want IPv6-only client segments.

That removes the need to assign IPv4 addresses to every endpoint.

The challenge is legacy IPv4 services.

An IPv6-only device cannot directly open an ordinary IPv4 connection without a translation or proxy mechanism.

That is where NAT64 can help.

NAT64 translates between IPv6 and IPv4

Stateful NAT64 translates traffic between IPv6 clients and IPv4 servers.

RFC 6146 defines a stateful translation mechanism for supported traffic such as:

• TCP
• UDP
• ICMP

The NAT64 device maintains translation state between the IPv6-side and IPv4-side flow.

An IPv6-only client can therefore communicate with an IPv4-only service without itself having an IPv4 address.

NAT64 is a transition mechanism.

It is not a reason to stop deploying native IPv6 on services that can support it.

DNS64 commonly works with NAT64

NAT64 is often paired with DNS64.

If an IPv6-only client looks up a hostname that has only an IPv4 address record, DNS64 can synthesize an IPv6 answer using the NAT64 prefix.

The client sends IPv6 traffic toward that synthesized address.

The NAT64 device translates the traffic to IPv4.

This works well for applications that use DNS names.

Applications that use hard-coded IPv4 literals can be more difficult.

That is one reason IPv6 transition can uncover old application assumptions.

IPv6 configuration is easier to reason about when the roles of Router Advertisements and DHCPv6 are kept separate. SLAAC depends on Router Advertisements for prefix and default-router information. DHCPv6 can assign addresses and other parameters, but it does not replace the basic IPv6 router-discovery function that tells a host where the default router is. That difference is a common troubleshooting trap: a DHCPv6 lease can exist while routed connectivity is still broken because the host is not learning or accepting the expected Router Advertisement.

Current DHCPv6 standards are also worth noting. RFC 9915, published in January 2026, is now the Internet Standard for DHCPv6 and obsoletes RFC 8415. The operational lesson is unchanged for Network+: DHCPv6 can be used statefully or alongside SLAAC, and the actual host behavior depends on the network design, Router Advertisement flags, and client implementation. Do not infer the intended configuration from one packet or one host.

DNS is another boundary. Native IPv6 services should publish AAAA records that point to real IPv6 addresses. DNS64 is different: it synthesizes an IPv6 answer for an IPv4-only destination so that the IPv6-only client can send traffic toward a NAT64 translator. If the application uses a hard-coded IPv4 address instead of DNS, DNS64 cannot synthesize anything. Some protocols that embed literal addresses or depend on unsupported translation behavior may also need application-specific handling.

For operations, compare native IPv6, dual-stack, and translated paths as separate test cases. A service that works over IPv4 but not native IPv6 suggests a routing, firewall, DNS AAAA, or service-listener problem. A service that works over native IPv6 but not through NAT64 suggests translation, DNS64, prefix routing, or application compatibility. That test matrix localizes the transition layer instead of producing a vague “IPv6 is broken” diagnosis.

Tunneling solves a different transition problem

IPv6 tunneling carries one protocol across an infrastructure that does not natively support it end to end.

Examples can include carrying IPv6 through an IPv4 path.

Tunneling does not perform the same job as NAT64.

Tunnel

• carries IPv6 traffic across another transport

NAT64

• translates between IPv6 and IPv4 communication

Tunneling carries an inner packet through another transport, as in IPsec over GRE; it does not, by itself, translate traffic between an IPv6-only client and an IPv4-only service. When the client has no IPv4 stack or route, troubleshoot the NAT64/DNS64 design rather than treating encapsulation as a substitute for translation.

Default-gateway troubleshooting deserves special attention because IPv6 does not learn its default route from DHCPv6. Router Discovery and Router Advertisements provide that information. If a host has a DHCPv6-assigned address but no valid default route, verify RA filtering, first-hop router configuration, VLAN placement, and local firewall behavior. Conversely, a host can have a perfectly usable SLAAC address and default route even when no stateful DHCPv6 server is assigning addresses.

When NAT64 is present, confirm that the NAT64 prefix is actually routed to the translator and that the translator has usable IPv4 reachability on the other side. If DNS64 synthesizes an address but the prefix is routed elsewhere, the DNS answer can look correct while every translated connection fails. Logs and counters on the translator can distinguish “the client never reached me” from “translation occurred but the IPv4 server did not respond.”

Security policy must cover both native and translated traffic. Firewalls, ACLs, and monitoring systems should understand whether they are evaluating the IPv6 client identity, the translated IPv4 flow, or both. During migration, inconsistent policy between IPv4 and IPv6 is a common source of surprises because an application may succeed on one stack and be blocked on the other.

Trace addressing, routing, name resolution, and translation separately

For a client that cannot reach a destination:

1. Check for a link-local IPv6 address.
2. Check the expected global/unique address.
3. Verify SLAAC or DHCPv6 behavior.
4. Check the IPv6 default route.
5. Test local gateway reachability.
6. Verify native IPv6 DNS records where expected.
7. Determine whether the destination is IPv6 or IPv4 only.
8. If using NAT64, verify the NAT64 route and translator.
9. If using DNS64, verify synthesized records.
10. Compare native IPv6, dual-stack, and translated behavior.

Once an IPv6 address and default router are present, test the real forwarding and return paths. An incorrectly aggregated IPv6 summary route can send traffic toward a missing path, including the prefix used by a NAT64 translator. A synthesized DNS64 AAAA answer is not proof that the route to that translator exists.

SLAAC, DHCPv6, NAT64, and DNS64 belong to different layers of the transition design. Troubleshooting is fastest when you first prove address formation, then default routing, then DNS behavior, and finally any translation path. Capture the Router Advertisement and DHCPv6 exchange when possible; packet evidence quickly shows whether the host is failing to receive configuration or receiving configuration it cannot use. Keep native and translated tests clearly labeled.