This chapter covers the three primary IPv6 transition technologies: dual stack, tunneling, and NAT64. Understanding these mechanisms is critical for the CompTIA Network+ N10-009 exam because IPv6 adoption is growing, and you must know how networks continue to communicate during the transition. Approximately 10-15% of exam questions touch on IPv6 addressing and transition methods, making this a high-yield topic area.
Jump to a section
Imagine a company with two separate phone systems: one for IPv4 calls (old landlines) and one for IPv6 calls (new VoIP). Employees in the IPv4-only wing can only call other IPv4 numbers; IPv6-only employees can only call IPv6 numbers. The company wants everyone to communicate seamlessly. First, they implement dual stack: every employee gets both a landline and a VoIP phone. An employee can choose which phone to use based on who they're calling. If the person they're calling has both phones, they can use either; if only one, they must match. This is like a host configured with both IPv4 and IPv6 addresses. Second, for employees who only have a landline and need to call an IPv6-only office, they use a translator (like NAT64) at the company's gateway. The translator picks up the landline call, converts it to a VoIP call by assigning a temporary IPv6 address, and places the call. When the reply comes back, the translator converts it back to the landline format. Third, for connecting entire IPv4-only branch offices to the IPv6 headquarters, they use tunneling: the IPv4 call is wrapped inside a VoIP call envelope (like a courier delivering a letter inside a package), sent over the IPv6 network, and unwrapped at the destination. The mailroom adds a special header with the destination IPv6 address and the original IPv4 packet as payload. The analogy is mechanistic: each technology corresponds to a physical process with clear steps and components.
Why IPv6 Transition Technologies Exist
IPv4 addresses are exhausted at the IANA and regional registry levels. However, the vast majority of the Internet still runs on IPv4. A flood cutover is impossible because IPv4 and IPv6 are incompatible protocols – they have different packet headers, addressing schemes, and even different address lengths (32-bit vs. 128-bit). An IPv4-only host cannot directly communicate with an IPv6-only host. Transition technologies bridge this gap during the long coexistence period.
Dual Stack: The Preferred Approach
Dual stack is the most straightforward transition method. A dual-stack host or router runs both IPv4 and IPv6 protocol stacks simultaneously. Each interface is configured with both an IPv4 address and an IPv6 address. The host's DNS resolver queries for both A (IPv4) and AAAA (IPv6) records. When a destination returns both, the host typically prefers IPv6 (as per RFC 6724 – default address selection). If only one is available, the host uses that one.
How it works: - At the network layer, the host maintains separate routing tables for IPv4 and IPv6. - Applications use getaddrinfo() to obtain both address types; the OS selects the appropriate stack based on destination and policy. - For outbound traffic, the host creates either an IPv4 or IPv6 packet and sends it to the corresponding next-hop router. - Inbound traffic arrives on whichever protocol the source used; the host processes it accordingly.
Key components and defaults: - IPv4 address: typically assigned via DHCP or static configuration. - IPv6 address: typically assigned via SLAAC (Stateless Address Autoconfiguration) or DHCPv6. - Default gateway: separate for IPv4 and IPv6. - DNS servers: must be reachable via both protocols (or a single dual-stack DNS server).
Configuration example on a Cisco router interface:
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
ipv6 address 2001:db8:1::1/64
ipv6 enableVerification commands:
show ip interface brief
show ipv6 interface briefThe output shows both IPv4 and IPv6 addresses on the same interface.
Dual stack is the recommended strategy by the IETF (RFC 4038) because it avoids translation overhead and maintains end-to-end connectivity for both protocols. The main drawback is increased administrative overhead and resource usage (CPU, memory, bandwidth) due to running two stacks.
Tunneling: IPv6 over IPv4
Tunneling encapsulates IPv6 packets inside IPv4 packets for transport across IPv4-only networks. The IPv6 packet becomes the payload of an IPv4 packet. This is used when two IPv6 islands need to communicate over an IPv4 core.
How it works: 1. The source IPv6 host sends an IPv6 packet to its default gateway (the tunnel endpoint). 2. The tunnel router (ingress) takes the entire IPv6 packet, adds an IPv4 header with its own IPv4 address as source and the remote tunnel endpoint's IPv4 address as destination, and sends the composite packet out. 3. The IPv4 network routes the packet normally based on the outer IPv4 header. 4. The tunnel router (egress) receives the packet, strips the IPv4 header, and forwards the original IPv6 packet to the destination IPv6 host.
Common tunneling types tested on N10-009: - Manual (6in4): Explicit configuration of tunnel endpoints. Protocol 41 in the IPv4 header indicates IPv6 payload. - Generic Routing Encapsulation (GRE): Cisco proprietary but widely used; can carry multiple protocol types. Adds a GRE header between the IPv4 and IPv6 headers. - Teredo: Provides IPv6 connectivity to IPv4-only hosts behind NAT. Uses UDP encapsulation over port 3544. - ISATAP: Intra-Site Automatic Tunnel Addressing Protocol; treats the IPv4 network as a virtual IPv6 link layer. - 6to4: Automatic tunneling using public IPv4 addresses to form a /48 IPv6 prefix (2002::/16). Requires a 6to4 relay router.
Key values and defaults: - Teredo UDP port: 3544. - 6to4 prefix: 2002:IPv4-address::/48 (e.g., 2002:c0a8:0101::/48 for 192.168.1.1). - ISATAP address format: ::0:5EFE:IPv4-address or ::200:5EFE:IPv4-address. - Protocol 41 in IPv4 header for 6in4.
Configuration example (Cisco manual 6in4 tunnel):
interface Tunnel0
ipv6 address 2001:db8:2::1/64
tunnel source 192.168.1.1
tunnel destination 10.0.0.2
tunnel mode ipv6ipVerification:
show ipv6 route
show interface tunnel0Tunneling adds overhead (at least 20 bytes for IPv4 header) and can fragment packets. It also introduces security concerns because firewalls may not inspect encapsulated traffic.
NAT64: IPv6-Only Clients Accessing IPv4 Servers
NAT64 is a translation mechanism that allows IPv6-only clients to communicate with IPv4-only servers. It combines DNS64 (which synthesizes AAAA records from A records) and stateful NAT64 translation.
How it works: 1. The IPv6 client sends a DNS query for a hostname. The DNS64 server, seeing no AAAA record, queries for the A record (IPv4 address). It then synthesizes a AAAA record by appending the IPv4 address to a well-known prefix (e.g., 64:ff9b::/96). 2. The client sends an IPv6 packet to the synthesized IPv6 address. 3. The packet arrives at the NAT64 router, which maintains a translation table. It translates the IPv6 header to an IPv4 header: the source IPv6 address is mapped to an IPv4 address from a pool, and the destination IPv6 address (64:ff9b::c0a8:0101) is converted to the embedded IPv4 address (192.168.1.1). 4. The NAT64 router forwards the IPv4 packet to the IPv4 server. 5. Return traffic is reverse-translated.
Key components: - Well-known prefix (WKP): 64:ff9b::/96 (RFC 6052). Also allowed: network-specific prefix. - Stateful NAT64: The router maintains per-session state (like traditional NAT). - DNS64: A DNS proxy that synthesizes AAAA records.
Configuration example (Linux with TAYGA – userspace NAT64):
# Add NAT64 prefix route
ip route add 64:ff9b::/96 dev nat64
# Start TAYGA with pool of IPv4 addresses
tayga --mapped 192.168.100.0/24 --prefix 64:ff9b::/96Verification:
show nat64 translations
show nat64 statisticsNAT64 breaks end-to-end transparency and cannot handle applications that embed IP addresses in payload (e.g., FTP active mode) without an ALG. It is commonly used in mobile networks where devices are IPv6-only and need to access legacy IPv4 content.
How They Interact
In a real network, these technologies often coexist:
Internal hosts use dual stack if possible.
For external connectivity, dual-stack hosts use native IPv6 when available; otherwise fall back to IPv4.
Tunneling is used to connect isolated IPv6 sites over an IPv4 WAN.
NAT64 is used at the edge to allow IPv6-only clients to reach IPv4-only servers.
The exam expects you to know when to use each method and their limitations.
DNS64 Synthesizes AAAA Record
An IPv6-only client (e.g., a smartphone on an LTE network) wants to reach a web server at www.example.com. It sends a DNS query for an AAAA record. The DNS64 server (configured with a NAT64 prefix, typically 64:ff9b::/96) receives the query. If no AAAA record exists, it queries for the A record instead. The A record returns 192.0.2.10. The DNS64 server then synthesizes a AAAA record: it prepends the NAT64 prefix (64:ff9b::) to the 32-bit IPv4 address, resulting in 64:ff9b::c000:020a. This synthesized address is returned to the client. The client believes it can reach the server natively over IPv6.
Client Sends IPv6 Packet to Synthesized Address
The IPv6 client now sends an IPv6 packet with destination 64:ff9b::c000:020a. The source address is the client's global IPv6 address (e.g., 2001:db8:1::100). The packet is routed through the IPv6 network toward the NAT64 gateway. The NAT64 gateway advertises a route for the 64:ff9b::/96 prefix, so the packet reaches it. At this point, the packet is a normal IPv6 packet; no translation has occurred yet.
NAT64 Gateway Translates IPv6 to IPv4
The NAT64 gateway receives the IPv6 packet. It checks its translation table for an existing session matching the source IPv6 address and destination IPv6 address. If no entry exists, it creates one. It selects an IPv4 address from its pool (e.g., 198.51.100.1) and assigns a port number (e.g., 50000) to map the client's IPv6 address and port. It then constructs a new IPv4 packet: source = 198.51.100.1:50000, destination = 192.0.2.10:80 (the embedded IPv4 address and well-known port). The payload (TCP segment or UDP datagram) is copied unchanged. The translation is stateful; the gateway records the mapping for the duration of the session.
IPv4 Server Responds
The IPv4 server at 192.0.2.10 receives the IPv4 packet and processes it. It sends a response packet with source = 192.0.2.10:80 and destination = 198.51.100.1:50000. This packet is routed normally over the IPv4 network back to the NAT64 gateway. The gateway checks its translation table using the destination IPv4 address and port (198.51.100.1:50000) to find the corresponding IPv6 client (2001:db8:1::100). It then constructs a new IPv6 packet: source = 64:ff9b::c000:020a (the synthesized address), destination = 2001:db8:1::100. The payload is again copied unchanged. The IPv6 client receives the response as if it came from the synthesized IPv6 address.
Session Termination and Cleanup
When the TCP session ends (FIN/RST exchange) or a UDP idle timeout expires (typically 5 minutes), the NAT64 gateway removes the translation entry from its table. This frees the IPv4 address/port mapping for reuse. If the client sends more traffic after the entry is removed, the gateway creates a new mapping, potentially with a different IPv4 address/port. This can cause issues for applications that expect a stable source address. The gateway also maintains a keepalive timer for UDP sessions to prevent premature cleanup.
Enterprise Scenario 1: Dual-Stack Migration in a Corporate Network
A large enterprise with 10,000 employees is migrating from IPv4-only to IPv6. They deploy dual stack on all access switches and routers. Each end-user device receives both an IPv4 address via DHCP and an IPv6 address via SLAAC. The DNS servers are configured to return both A and AAAA records. The challenge is ensuring all applications work over both protocols. Some legacy applications hardcode IPv4 addresses; the network team uses application-layer gateways (ALGs) or NAT64 for those. Performance monitoring shows that IPv6 traffic has slightly higher CPU usage on routers due to larger headers, but overall throughput is similar. The biggest issue is troubleshooting: when a user has connectivity problems, the help desk must check both stacks. The team uses show commands like 'show ip interface brief' and 'show ipv6 interface brief' to verify both are up. They also implement DHCPv6 option 23 to provide DNS server addresses. After 18 months, 80% of traffic uses IPv6, but the IPv4 stack remains enabled for backward compatibility.
Enterprise Scenario 2: Tunneling for Branch Office Connectivity
A company with 50 branch offices uses an MPLS IPv4-only WAN. They want to deploy IPv6 internally at each branch but cannot upgrade the WAN immediately. They configure manual 6in4 tunnels between each branch router and the head office router. Each tunnel uses a /64 IPv6 subnet. The head office acts as a hub; branch routers have tunnel source set to their IPv4 WAN address and tunnel destination set to the head office's IPv4 address. The tunnel mode is ipv6ip. Inside each branch, hosts use SLAAC to get IPv6 addresses from the tunnel subnet. The main issue is MTU: the IPv6 packet plus IPv4 header (20 bytes) can exceed the path MTU. They set the tunnel MTU to 1480 bytes to leave room for the outer header. They also implement IPsec over the tunnel for security. The help desk monitors tunnels with 'show interface tunnel' and checks for packet drops. When a tunnel goes down, the branch loses IPv6 connectivity; they rely on IPv4 as fallback.
Enterprise Scenario 3: NAT64 for Mobile Users
A mobile carrier deploys an IPv6-only core network. User devices get only IPv6 addresses. To access IPv4-only Internet content (e.g., legacy websites), the carrier deploys a NAT64 gateway (e.g., using Linux with Jool or TAYGA). They also run DNS64 to synthesize AAAA records. The NAT64 gateway uses a pool of public IPv4 addresses (e.g., 203.0.113.0/24) for translation. Performance is a concern: the gateway must handle millions of concurrent sessions. They use load balancers to distribute traffic across multiple NAT64 instances. A common problem is application compatibility: some apps embed IPv4 addresses in SIP or FTP control channels. They deploy ALGs for those protocols. The carrier also monitors translation table size and sets session timeouts appropriately (e.g., 300 seconds for UDP, 3600 seconds for TCP). If the gateway fails, all IPv6-only users lose access to IPv4 content, so they implement failover with state synchronization between NAT64 instances.
What N10-009 Tests on This Topic
The CompTIA Network+ N10-009 exam objectives (Domain 1.4) specifically list: "Explain the purpose and functions of various network services" and under that, "IPv6 transition technologies: dual stack, tunneling, NAT64." Expect 2-3 questions on this area. The exam focuses on:
Identifying the correct transition technology for a given scenario. For example: "A company has IPv6-only hosts that need to access an IPv4-only web server. Which technology should be used?" Answer: NAT64 (with DNS64). The distractor is often "tunneling" because candidates confuse translation with encapsulation.
Understanding the differences between tunneling and translation. Tunneling encapsulates one protocol inside another; translation changes the packet header. The exam may ask: "Which technology allows two IPv6 networks to communicate over an IPv4 WAN?" Answer: tunneling (e.g., 6in4 or GRE). The distractor is "NAT64" because candidates think of translating between protocols, but tunneling does not translate.
Knowing the well-known prefix for NAT64: 64:ff9b::/96. This appears verbatim. A question might ask: "What is the well-known prefix used by NAT64?" The wrong answer choices include other prefixes like 2002::/16 (6to4) or fe80::/10 (link-local).
Recognizing dual stack as the recommended approach. The exam often asks: "Which transition technology is preferred for most networks?" Answer: dual stack. The distractors include "6to4" or "Teredo" because they are also transition methods but not preferred.
Common Wrong Answers and Why Candidates Choose Them
Choosing tunneling instead of NAT64: Candidates see "IPv6 to IPv4" and think of encapsulation. But tunneling carries IPv6 over IPv4, not translation. NAT64 actually translates IPv6 to IPv4. The key differentiator: tunneling requires both endpoints to have IPv6; NAT64 allows IPv6-only to reach IPv4-only.
Choosing 6to4 for a scenario requiring manual configuration: 6to4 is automatic; manual tunnels require explicit configuration. The exam may ask for an automatic method; candidates pick manual.
Confusing Teredo and 6to4: Teredo uses UDP encapsulation for NAT traversal; 6to4 uses protocol 41. The exam might ask: "Which tunneling method works through IPv4 NAT?" Answer: Teredo. Wrong: 6to4 (it doesn't traverse NAT well).
Thinking dual stack requires translation: Dual stack runs both protocols independently; no translation occurs. Candidates might think dual stack converts packets, but it simply sends packets natively on the appropriate stack.
Specific Numbers and Terms to Memorize
NAT64 well-known prefix: 64:ff9b::/96
6to4 prefix: 2002::/16
Teredo UDP port: 3544
Protocol number for IPv6 in IPv4: 41
ISATAP address format: ::0:5EFE:IPv4-address
Edge Cases the Exam Loves
NAT64 and applications that embed IP addresses: The exam may ask why FTP active mode fails with NAT64. Answer: The IPv4 address is embedded in the FTP control channel; NAT64 cannot translate it without an ALG.
Tunneling and MTU: The outer header reduces effective MTU. A question might ask: "What is a common issue with IPv6 tunneling?" Answer: fragmentation or MTU problems.
Dual stack and DNS: If a dual-stack host receives both A and AAAA records, it prefers IPv6. But if IPv6 connectivity fails, the host may time out before falling back to IPv4. This is called "happy eyeballs" (RFC 8305).
How to Eliminate Wrong Answers
Read the scenario carefully: Are both endpoints running the same protocol or different? If different, translation (NAT64) is needed. If same but separated by an incompatible network, tunneling is needed.
Look for keywords: "IPv6-only hosts" + "IPv4 server" = NAT64. "Two IPv6 networks" + "IPv4 WAN" = tunneling. "Both protocols on each host" = dual stack.
Eliminate options that don't fit the mechanism: If the scenario involves NAT, translation is involved; tunneling does not change the packet's original protocol.
Remember the default preference: dual stack is always the best answer if the question asks for the recommended approach.
Dual stack is the recommended transition technology; it runs both IPv4 and IPv6 simultaneously without translation.
NAT64 uses the well-known prefix 64:ff9b::/96 to embed IPv4 addresses in IPv6 addresses, and requires DNS64.
6to4 tunneling uses prefix 2002::/16 and protocol 41; it does not work through NAT without additional configuration.
Teredo uses UDP encapsulation on port 3544 to traverse IPv4 NAT devices.
Manual 6in4 tunnels require explicit configuration of source and destination IPv4 addresses.
NAT64 is stateful; the translation table maps IPv6 addresses/ports to IPv4 addresses/ports.
Dual-stack hosts prefer IPv6 over IPv4 when both A and AAAA records are returned (RFC 6724).
Tunneling adds overhead and can cause MTU issues; set tunnel MTU to 1480 bytes or less.
These come up on the exam all the time. Here's how to tell them apart.
Dual Stack
Both protocols run simultaneously on same interface.
No encapsulation or translation; native packets for each protocol.
Preferred by IETF; maintains end-to-end transparency.
Requires dual-stack support on all devices along path.
Higher resource usage (CPU, memory) due to two stacks.
Tunneling
One protocol is encapsulated inside another (e.g., IPv6 in IPv4).
Adds overhead (20+ bytes per packet).
Used to connect isolated IPv6 islands over IPv4 core.
Only tunnel endpoints need to support both protocols; core is IPv4-only.
May have MTU/fragmentation issues.
NAT64
Translates IPv6 packets to IPv4 packets (stateful).
Allows IPv6-only clients to reach IPv4-only servers.
Requires DNS64 to synthesize AAAA records.
Breaks end-to-end transparency; applications may need ALGs.
Uses well-known prefix 64:ff9b::/96.
Tunneling (6in4)
Encapsulates IPv6 packets inside IPv4 packets (no translation).
Connects two IPv6 networks over an IPv4 network.
No DNS modification needed; endpoints must have IPv6.
Preserves end-to-end IPv6 transparency.
Uses protocol 41 or GRE; adds IPv4 header overhead.
Mistake
Dual stack translates between IPv4 and IPv6.
Correct
Dual stack runs both protocol stacks independently; no translation occurs. A dual-stack host sends IPv4 packets to IPv4 destinations and IPv6 packets to IPv6 destinations. The host does not convert one protocol to the other.
Mistake
NAT64 is the same as NAT-PT (deprecated).
Correct
NAT-PT (Network Address Translation - Protocol Translation) was deprecated by RFC 4966 due to issues with application layer gateways and lack of DNS integration. NAT64 (RFC 6146) is the replacement and works with DNS64 to synthesize AAAA records. NAT64 is stateful and uses a well-known prefix.
Mistake
6to4 works behind a NAT without any issues.
Correct
6to4 uses protocol 41 in the IPv4 header, which many NAT devices do not support or forward. This breaks 6to4 connectivity. Teredo was designed specifically to work through NATs by using UDP encapsulation.
Mistake
Tunneling adds no overhead compared to native IPv6.
Correct
Tunneling adds at least 20 bytes of IPv4 header (or more with GRE) to each packet. This increases overhead and can cause fragmentation if the combined size exceeds the path MTU. Native IPv6 has a 40-byte header, but tunneling adds an additional IPv4 header.
Mistake
NAT64 allows IPv4-only clients to reach IPv6-only servers.
Correct
NAT64 is designed for IPv6-only clients to reach IPv4-only servers. The reverse (IPv4 to IPv6) requires a different technology, such as NAT46 (which is not covered in N10-009) or an application-layer proxy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Dual stack runs both IPv4 and IPv6 protocol stacks on the same device, so the device can communicate natively using either protocol. Tunneling encapsulates one protocol inside another (e.g., IPv6 inside IPv4) to traverse a network that doesn't support the inner protocol. Dual stack is preferred because it avoids encapsulation overhead and maintains end-to-end transparency.
No. NAT64 is designed for IPv6-only clients to reach IPv4-only servers. The reverse direction (IPv4 client to IPv6 server) requires a different mechanism, such as NAT46 or an application-layer proxy. The CompTIA Network+ exam only tests NAT64 for IPv6-to-IPv4 translation.
The well-known prefix is 64:ff9b::/96 (RFC 6052). When an IPv6 address is synthesized from an IPv4 address, the IPv4 address is appended to this prefix. For example, IPv4 192.0.2.1 becomes 64:ff9b::c000:0201. This prefix is used by default, but a network-specific prefix can also be configured.
6to4 uses IP protocol 41 in the IPv4 header to indicate that the payload is an IPv6 packet. Most NAT devices only forward TCP/UDP traffic (protocols 6 and 17) and drop or mishandle protocol 41. Teredo solves this by encapsulating IPv6 in UDP, which NATs can handle. The exam expects you to know that 6to4 has issues with NAT.
DNS64 is a DNS proxy that synthesizes AAAA records from A records when no AAAA record exists. When an IPv6-only client queries a hostname, DNS64 first checks for a AAAA record; if absent, it queries for the A record, then creates a synthetic AAAA record by appending the IPv4 address to the NAT64 prefix (e.g., 64:ff9b::). This allows the client to send an IPv6 packet to the NAT64 gateway for translation.
There is no standard default; it depends on the configuration. Typically, the tunnel MTU is set to 1480 bytes to account for the 20-byte IPv4 outer header (if the path MTU is 1500). Some implementations automatically subtract the header size. The exam may ask about MTU issues with tunneling; you should know that the outer header reduces the available MTU for the inner packet.
Yes. If a dual-stack host receives both A and AAAA records, it prefers IPv6. If the IPv6 path is broken but the IPv4 path works, the host may experience connection timeouts before falling back to IPv4 (a problem mitigated by Happy Eyeballs, RFC 8305). Additionally, asymmetric routing can occur if IPv4 and IPv6 paths are different.
You've just covered IPv6 Transition: Dual Stack, Tunneling, NAT64 — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?