IPv6’s 128-bit address space — roughly 340 undecillion addresses — removes the core reason IPv4 needed NAT in the first place. But NAT hasn’t disappeared entirely from the picture; it’s just doing a different job now. Instead of conserving scarce addresses, IPv6-era NAT exists almost entirely to bridge the gap during the transition period — letting IPv6-only and IPv4-only networks actually talk to each other while that transition is still genuinely in progress.
This guide covers Unique Local Addresses (IPv6’s answer to private addressing), NAT64 with a fully verified, corrected configuration, and where NAT genuinely still fits in an IPv6 world.
IPv6 Unique Local Addresses (ULA)
ULAs are IPv6’s rough equivalent to RFC 1918 private addresses, but the resemblance is more structural than functional — a ULA provides address space for communication within a local site, and critically, it doesn’t provide any security benefit on its own, unlike the incidental obscurity effect NAT has in IPv4.
Structure: the ULA prefix is FC00::/7 — the first 7 bits. The 8th bit is the L flag: set to 1 for locally-assigned ULAs (the only kind actually used in practice; L=0 is reserved for a future use case that was never defined). This means every real-world ULA you’ll encounter starts with FD, not FC — FC00::/7 with L=1 evaluates to FD00::/8. The next 40 bits are a randomly generated global ID, followed by a 16-bit subnet ID — together, prefix + L flag + global ID + subnet ID make up the first 64 bits. The remaining 64 bits are the interface ID, defined in RFC 4193.
A correct example: FD00:1:1::/64 — note the FD, not FC, reflecting L=1. Generate one for lab testing with:
Router(config-if)# ipv6 address fd00:1:1::/64 eui-64Key properties: ULAs aren’t routable across the public internet, in much the same way RFC 1918 addresses aren’t — but if one happens to leak via misconfigured routing or DNS, it won’t conflict with anyone else’s address space, thanks entirely to the randomly generated global ID built into its structure. ULAs aren’t intended to be translated to global unicast addresses via NAT at all; IPv6 generally favors real end-to-end connectivity over translation, using routing rather than address translation between ULA and global scope wherever that’s genuinely possible.
Why NAT Isn’t a Security Feature (In IPv4 or IPv6)
This point applies to both protocols equally, but it’s worth stating clearly here since IPv6 tends to raise the question directly: does removing NAT actually reduce security in any meaningful way? The IETF has addressed this explicitly — RFC 5902 notes that a NAT device blocking unsolicited inbound connections is often mistaken for a genuine security feature, when it’s really just an incidental side effect of how translation happens to work. RFC 4864 makes the same point even more directly: stateful filtering (what a real firewall actually does) provides equivalent protection without needing any translation at all in the process.
The practical takeaway: removing NAT in an IPv6 deployment doesn’t remove security — it just removes an illusion of security that was never doing the real work. A properly configured firewall with stateful inspection provides the actual protection, in either protocol.
IPv6 Transition Mechanisms
The IETF developed several approaches for the IPv4-to-IPv6 transition period, since IPv6 devices are meant to talk to each other over IPv6 natively:
- Dual-stack: both IPv4 and IPv6 run in parallel on the same device — the most straightforward approach where supported, but it doesn’t solve the case of a pure IPv6-only client needing to reach a pure IPv4-only resource.
- Tunneling: encapsulates IPv6 packets inside IPv4 packets, letting IPv6 traffic cross an IPv4-only network.
- Translation (NAT64 and related): actually converts between the two protocols, rather than just carrying one inside the other.
NAT for IPv6 — meaning translation-based mechanisms like NAT64 — is explicitly a transition tool, not a long-term architecture. As IPv6 adoption completes, the need for translation between the two protocols diminishes; it exists specifically to smooth over the period where both protocols coexist.
IPv4 NAT vs. IPv6-Era Mechanisms
| Feature | IPv4 NAT (RFC 1918) | IPv6 ULA (RFC 4193) | NAT64 (Transition) | NPTv6 (Prefix Translation) |
|---|---|---|---|---|
| Purpose | Address conservation | Local addressing, no internet routing | IPv6-to-IPv4 access | Prefix remapping, no port overload |
| Address space | 10.0.0.0/8, etc. | FD00::/8 (L=1) | 64:ff9b::/96 (well-known) or a custom /96 | Stateless prefix swap |
| Security role | Incidental obscurity, not real protection | Non-routable, no security function | Requires separate stateful filtering | Preserves end-to-end addressing |
NAT64: Letting IPv6-Only Clients Reach IPv4-Only Resources
It is a stateful translation mechanism allowing IPv6 hosts to communicate with IPv4-only servers, without either side needing to run both protocols. It translates using a /96 prefix, with the lower 32 bits of the IPv6 address directly representing the IPv4 destination.
Worked example: an IPv6 client at 2001:db8::1 wants to reach an IPv4-only server at 192.0.2.1. Rather than contacting that address directly, the client’s traffic is directed toward the NAT64 gateway’s /96 prefix with the IPv4 address embedded in the last 32 bits — the gateway recognizes this, extracts the embedded IPv4 address, and forwards a native IPv4 packet to the real server. NAT64 requires DNS64 alongside it for this to work transparently — DNS64 synthesizes an AAAA (IPv6) record for IPv4-only domains, embedding the IPv4 address using the same NAT64 prefix, so the client never has to know it’s actually reaching an IPv4 host.
Configuring NAT64 on a Cisco Router — Verified Syntax
The IPv6-facing and IPv4-facing interfaces both need nat64 enable, and the stateful prefix, IPv4 pool, and binding ACL are each separate commands — not one combined command:
Router(config)# ipv6 unicast-routing
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ipv6 address 2001:db8:1::1/64
Router(config-if)# ipv6 enable
Router(config-if)# nat64 enable
Router(config-if)# exit
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip address 192.168.1.1 255.255.255.0
Router(config-if)# nat64 enable
Router(config-if)# exit
Router(config)# ipv6 access-list NAT64-ACL
Router(config-ipv6-acl)# permit ipv6 2001:db8:1::/64 any
Router(config-ipv6-acl)# exit
Router(config)# nat64 prefix stateful 2001:db8:64::/96
Router(config)# nat64 v4 pool NAT64-POOL 192.168.1.100 192.168.1.200
Router(config)# nat64 v6v4 list NAT64-ACL pool NAT64-POOL overload
One restriction worth knowing well: the well-known prefix (64:ff9b::/96) cannot be manually configured as a stateful prefix — Cisco IOS explicitly rejects it outright if you try. The well-known prefix is used automatically only when no custom stateful prefix has been configured at all. This example deliberately uses a custom prefix (2001:db8:64::/96) specifically because it needs to be explicitly configurable in the first place.
Verifying NAT64
Router# show nat64 translations
Router# show nat64 statistics
Router# show nat64 prefix stateful globalshow nat64 translations is the direct equivalent of show ip nat translations from IPv4 NAT — the fastest way to confirm actual translations are happening. show nat64 prefix stateful global confirms which prefix is active and which interfaces are using it.
Worked Example: Reading a NAT64 Synthesized Address
The address-embedding mechanic is easier to understand with real numbers worked through by hand. Say the NAT64 prefix is 2001:db8:64::/96, and the destination IPv4 address is 192.168.1.10.
Step 1 — convert the IPv4 address to hex: 192.168.1.10 in dotted-decimal becomes C0A8:010A in hex (192 = C0, 168 = A8, 1 = 01, 10 = 0A).
Step 2 — append it to the /96 prefix: since the prefix occupies the first 96 bits (6 hextets), the remaining 32 bits (2 hextets) carry the embedded IPv4 address:
2001:db8:64::C0A8:010AThis is functionally identical to writing 2001:db8:64::192.168.1.10 using the dotted-decimal shorthand IPv6 permits for embedded IPv4 addresses within the final 32 bits — both notations represent exactly the same address.
Step 3 — the gateway reverses this on receipt: when the NAT64 router sees a packet destined for this synthesized address, it strips the /96 prefix, reads the remaining 32 bits as an IPv4 address, and forwards a native IPv4 packet to 192.168.1.10 — the client never needed to know the real IPv4 address directly; DNS64 handled synthesizing this address from the domain lookup in the first place.
Troubleshooting NAT64
| Symptom | Check | Likely Cause |
|---|---|---|
| No translation occurring | show nat64 translations | nat64 enable missing on one of the two interfaces, or the ACL doesn’t match the IPv6 client’s actual prefix |
| Client can’t resolve IPv4-only domains | DNS configuration | DNS64 not deployed — the client needs a synthesized AAAA record to have anything to connect to in the first place |
| Intermittent failures on larger transfers | Interface MTU | IPv6’s minimum MTU is 1280 bytes; translation overhead can trigger fragmentation issues on constrained links |
| Configuration rejected for the well-known prefix | nat64 prefix stateful 64:ff9b::/96 | This specific prefix can’t be manually configured — use a custom prefix instead, or omit the command to let the well-known prefix apply automatically |
What This Means for CCNA and Beyond
For CCNA 200-301 specifically, the exam-relevant takeaways are narrower than the full technical depth above: know that ULA exists as IPv6’s private-addressing equivalent but provides no security function, know that NAT64 is a transition mechanism rather than a permanent architecture, and know that IPv6 generally favors real end-to-end connectivity over translation wherever possible.
The detailed NAT64 configuration syntax matters more for CCNP-level material and real-world deployment than for CCNA exam questions specifically — but understanding why the configuration needs separate pool, ACL, and binding steps (rather than one combined command) reflects a real architectural distinction worth internalizing regardless of exam level: NAT64 is genuinely translating between two different protocols, not just remapping addresses within one, which is why it needs more moving parts than IPv4-to-IPv4 NAT ever did.
FAQs
What is NAT for IPv6, and how is it different from IPv4 NAT?
It’s primarily transition tooling — NAT64 and similar mechanisms let IPv6-only and IPv4-only networks communicate during the migration period, rather than conserving address space the way IPv4 NAT does. IPv6 has enough addresses that conservation isn’t the point.
What are Unique Local Addresses (ULA) in IPv6?
Site-local IPv6 addresses (FD00::/8 for the locally-assigned type actually used in practice) that aren’t routable on the public internet, similar in spirit to RFC 1918 private addresses — but they provide no security function on their own, unlike NAT’s incidental obscurity effect in IPv4.
How do you configure NAT64 on a Cisco router?
Enable nat64 enable on both the IPv6-facing and IPv4-facing interfaces, define a stateful prefix with nat64 prefix stateful <prefix>/96, configure an IPv4 address pool with nat64 v4 pool, and bind them together with nat64 v6v4 list <acl> pool <name> overload. Verify with show nat64 translations.
Why isn’t NAT considered a real security solution?
Per RFC 5902 and RFC 4864, NAT’s apparent protection is a side effect of translation, not actual filtering — a stateful firewall provides the equivalent (and more thorough) protection without needing any address translation at all. This applies in IPv4 and IPv6 alike.
Can the well-known NAT64 prefix (64:ff9b::/96) be manually configured?
No — Cisco IOS explicitly rejects an attempt to configure it as a stateful prefix. It’s used automatically only when no custom stateful prefix has been configured; any manually specified prefix needs to be a different, custom /96.
Is NAT for IPv6 a permanent architecture?
No — it’s explicitly a transition tool. As IPv6 adoption continues and IPv4-only resources become less common, the practical need for NAT64 and similar translation mechanisms diminishes, since IPv6’s address abundance removes the underlying reason NAT existed in IPv4 in the first place.
Why does NAT64’s configuration need more separate steps than IPv4 NAT?
Because It is genuinely translating between two different protocols — IPv6 and IPv4 — not just remapping addresses within the same protocol the way IPv4-to-IPv4 NAT does. That’s why it needs nat64 enable on both interfaces, a separate IPv4 pool, and an explicit binding step, rather than the single combined command a simpler translation might suggest.
