N10-009 Question 136
Single answerIPv6 addressing: Mitigating address exhaustion, Compatibility requirements (Tunneling, Dual stack, NAT64)A company has exhausted its public IPv4 address space and is rolling out IPv6 across its internal network. Most employee laptops and servers support both IPv4 and IPv6, but several business-critical cloud services are still reachable only over IPv4. The network team wants to enable IPv6 for internal clients now, maintain access to the IPv4-only services during the transition, and avoid introducing unnecessary protocol encapsulation overhead where native support exists. Which solution best meets these requirements?
- A
Deploy dual stack on internal hosts and network devices so systems can use IPv6 where available and IPv4 for legacy destinations
- B
Deploy NAT64 only, because it allows all IPv6 and IPv4 hosts to communicate directly without requiring any IPv4 on client devices or special DNS handling
- C
Deploy tunneling for all internal traffic, because tunneling is the preferred long-term method for production IPv6 migration even when native IPv6 is available
- D
Replace all private IPv4 addressing with link-local IPv6 addresses, because link-local addressing provides Internet reachability without consuming public IPv4 space
Show answer and explanation
Correct answer: A
Explanation
The best answer is dual stack. In real-world IPv6 transition planning, dual stack is commonly used when hosts, applications, and network devices can support both IPv4 and IPv6. It allows organizations to begin using IPv6 immediately while preserving compatibility with IPv4-only services. This directly addresses IPv4 address exhaustion mitigation by enabling growth over IPv6 without breaking access to legacy resources. NAT64 is valuable in a different scenario: when clients are IPv6-only and still need to reach IPv4-only services, usually in conjunction with DNS64 as described in RFC 6146 and RFC 6147. Tunneling mechanisms such as 6to4, ISATAP, or manually configured tunnels are transition tools for crossing IPv4-only infrastructure, but they are generally less desirable than native dual stack because of added complexity and overhead. These distinctions align with common IPv6 deployment guidance from standards bodies such as the IETF and operational best practices reflected in enterprise migration strategies.
- A. Correct.
Correct. Dual stack is the most appropriate choice in this scenario because the organization has hosts and infrastructure that support both protocols, and it needs to maintain access to IPv4-only cloud services during transition. With dual stack, devices can communicate over IPv6 when available while still using IPv4 for destinations that do not yet support IPv6. This avoids unnecessary tunneling overhead where native IPv6 is available and is a common best-practice transition approach.
- B. Incorrect.
Incorrect. NAT64 is designed primarily to allow IPv6-only clients to access IPv4-only resources, typically with DNS64 support to synthesize AAAA records from A records. It is not a universal replacement for dual stack in an environment where most hosts already support both protocols and still need straightforward access to IPv4 services. The statement that it allows all IPv6 and IPv4 hosts to communicate directly without special DNS handling is inaccurate.
- C. Incorrect.
Incorrect. Tunneling can be useful when IPv6 traffic must traverse an IPv4-only segment, but it introduces encapsulation overhead and additional operational complexity. In this scenario, the company wants to avoid unnecessary encapsulation where native support exists. Tunneling is a transition mechanism, not the preferred default when native dual stack can be deployed.
- D. Incorrect.
Incorrect. IPv6 link-local addresses are only valid on the local network segment and are not routable across the Internet. They cannot replace private IPv4 addressing for general enterprise communication or provide reachability to cloud services. This option reflects a misunderstanding of IPv6 address scope.