Go IPv6‑First at Home: NAT64 and DNS64 Without Breaking Your Devices

Why Go IPv6‑First Now

Most homes still run on IPv4, even while the internet has quietly shifted. Major services are fully reachable over IPv6, mobile networks already prefer it, and many ISPs hand out generous IPv6 prefixes. Making your home network IPv6‑first can reduce NAT pain, improve connectivity in CGNAT situations, and simplify hosting services from home. With NAT64 and DNS64, you can keep the last few IPv4‑only apps working without noticing the change.

This article is a practical, step‑by‑step build. We’ll walk through the components (prefix delegation, router advertisements, DNS64, NAT64, and optional CLAT), map common device behavior, and share safe rollout patterns. The goal is a setup you can adopt in an afternoon and trust for years.

What IPv6‑First Actually Means

IPv6‑first doesn’t require you to delete IPv4 on day one. It means your home network prefers IPv6 when it’s available and uses translation only when needed. You can do this in three ways:

Dual‑stack: Run IPv4 and IPv6 side by side. Easiest migration path. No translation needed, but you still live with IPv4 limitations.
IPv6‑only with NAT64/DNS64: Devices get only IPv6. If an app tries to reach an IPv4‑only site, DNS64 synthesizes an AAAA record, and NAT64 translates to IPv4 behind the scenes.
Hybrid: Offer two SSIDs/VLANs—one dual‑stack for legacy gear and one IPv6‑only with NAT64/DNS64 for everything else. This is a clean way to move modern devices forward without stranding old printers or TVs.

We’ll design for the hybrid model because it’s flexible and safe. You can later switch the main SSID fully to IPv6‑only if everything works well.

What You Need From Your ISP and Router

Your ISP

To go IPv6‑first, your ISP should provide an IPv6 prefix via DHCPv6‑PD (Prefix Delegation). Common sizes are /56 or /60 for home subscribers. Ask support for details or look in your router’s WAN status page for a “Delegated prefix.” If your ISP does not offer IPv6 at all, you can still build an IPv6‑only LAN that exits via a tunnel or a VPS, but that adds complexity. If your ISP offers IPv6 but has CGNAT for IPv4, moving to IPv6‑first is especially helpful.

Your Router

Pick a router that supports IPv6 well and can run NAT64/DNS64 locally or connect to a translator upstream. Three common paths:

OpenWrt on consumer hardware: Good IPv6 support, packages for dnsmasq-full, unbound, and NAT64 translators like tayga or jool.
pfSense/OPNsense on x86 mini‑PCs: Mature IPv6 tooling, flexible DNS, and package support for translators.
Vendor routers with IPv6: Many now offer decent IPv6 and prefix delegation. Some also expose DNS64 toggles. NAT64 may require a separate translator on your network or upstream.

You can also host the NAT64 translator on a low‑power Linux box or a home server and point your router to it.

The Building Blocks

Prefix Delegation and LAN Prefixing

On the WAN, enable DHCPv6‑PD. Your router should request a prefix and advertise subnets—one per LAN/VLAN—downstream using Router Advertisements (RA). For example, with a /56 you have 256 /64s. Give each LAN a unique /64. IPv6 wants that /64 boundary to support SLAAC and neighbor discovery cleanly.

Address Assignment on the LAN

Most homes should enable both:

SLAAC for baseline autoconfiguration via RA.
DHCPv6 for extra options (like DNS servers) and for clients that prefer managed addressing.

Clients will still generate local addresses. Watch for privacy extensions (RFC 4941) and stable addresses (RFC 7217). Privacy addresses rotate to reduce long‑term tracking; stable addresses are consistent per network but not tied to your MAC address. Both are fine at home. If you run local servers, assign them static IPv6 addresses or reservations.

DNS64: The IPv4 Safety Net

DNS64 is a DNS server feature that creates IPv6 (AAAA) answers for domains that only have IPv4 (A) records. When a device on your IPv6‑only SSID resolves a hostname, DNS64 checks if there’s an IPv6 address. If not, it synthesizes one using a known NAT64 prefix. This way, the app connects over IPv6 to a “fake” IPv6 address representing the IPv4 server.

Where to run DNS64:

On your router’s DNS resolver (e.g., unbound or dnsmasq‑full) with DNS64 enabled.
On a separate DNS box on your LAN.
Via an upstream provider that supports DNS64. This is convenient, but you’ll still need a NAT64 translator somewhere reachable.

Use the well‑known prefix 64:ff9b::/96 unless you have a reason to use a different one. Modern clients can discover the NAT64 prefix using RA options (RFC 8781) or DNS‑based methods (RFC 7050), but it’s fine to start with the default.

NAT64: Translating IPv6 to IPv4

NAT64 is the engine that forwards IPv6 packets to IPv4 destinations. It reads the IPv6 destination from DNS64 (which encodes an IPv4 address) and translates the traffic at the packet level.

Where to run NAT64:

Local translator on your router or Linux box with tayga or jool. This is the most independent option.
Upstream translator (for example, on a VPS you control). Route your NAT64 prefix to that server over a VPN like WireGuard. This path can be useful if your router is underpowered.

A key point: ICMPv6 must not be blocked. Translation depends on Path MTU Discovery to avoid fragmentation issues. Do not filter PMTU messages, or you will see stalls and mysterious timeouts.

CLAT and 464XLAT: When Devices Need an IPv4 Facade

Some legacy apps still expect a literal IPv4 socket. On IPv6‑only Wi‑Fi, those apps can work through a CLAT (Customer‑side translator) on the device, which creates a virtual IPv4 interface and forwards it over IPv6 to NAT64. This whole pattern is called 464XLAT. Mobile operating systems widely support it. Support on desktops varies by OS and version. For home use, you can usually rely on DNS64/NAT64 plus the built‑in behavior of modern phones and tablets. If a specific desktop app breaks on an IPv6‑only SSID, put that device on your dual‑stack SSID or consider running a local CLAT.

Designing Your Home Layout

Two SSIDs, Clear Intents

Main SSID (IPv6‑only + DNS64/NAT64): Phones, tablets, laptops, and modern consoles go here. You get faster, cleaner routing with fewer NAT layers.
Legacy SSID (Dual‑stack IPv4/IPv6): Printers, cameras, old TVs, and odd IoT gear that struggle without IPv4. Keep this on a separate VLAN to limit blast radius.

This layout lets you test safely and move devices at your own pace. Over time, the legacy SSID goes quiet.

Firewalling That Makes Sense

IPv6 does not require NAT for protection. Replace the “NAT = security” habit with a default‑deny inbound firewall and a normal stateful outbound policy:

Inbound: Deny unsolicited traffic by default. Allow SSH or HTTP(S) only to the hosts you intend to expose, and log these rules.
Outbound: Permit established/related flows, allow DHCPv6, ICMPv6 (especially Packet Too Big), and DNS to your resolver. Avoid blocking ICMPv6.
Inter‑VLAN: Deny by default. Allow selective service flows (e.g., casting, printing) as needed, or use application‑level bridges.

Because each device has a global IPv6 address, visibility improves. You can see which device is talking to what, without guessing through NAT tables.

Hosting From Home Is Easier on IPv6

If your ISP gives you a stable prefix, you can expose a home lab service with a simple firewall allow rule. No port forwarding gymnastics. To make it usable:

Use a dynamic DNS provider that supports AAAA records.
Get a certificate with Let’s Encrypt using HTTP‑01 or DNS‑01 validation.
Create a reserved IPv6 address for your host and apply a targeted inbound allow rule.

This is one of the most satisfying parts of moving to IPv6‑first. You cut right through layers of CGNAT and avoid awkward tunnels.

Step‑by‑Step: One Afternoon Rollout

1) Confirm IPv6 from Your ISP

Check your router’s WAN status for a delegated IPv6 prefix (PD). If none, ask your ISP. If unavailable, skip to the “No Native IPv6?” note below.

2) Update Router Firmware and Back Up

Upgrade to a recent release (OpenWrt, pfSense/OPNsense, or vendor firmware).
Export a backup config. If something goes sideways, you can roll back in minutes.

3) Enable DHCPv6‑PD and RA per VLAN

Let the router request a /56 or /60, then assign a /64 to each LAN/VLAN.
Advertise using RA. Enable SLAAC and DHCPv6 on the LAN.

4) Stand Up DNS64

Enable DNS64 on your LAN resolver (unbound or dnsmasq‑full are common). Configure it to synthesize AAAA using 64:ff9b::/96.
Point your IPv6‑only SSID/VLAN to this resolver (hand out its address through RA and/or DHCPv6).

5) Stand Up NAT64

Install jool or tayga on the router or a nearby Linux host. Bind it to your WAN and your IPv6‑only LAN.
Verify the NAT64 prefix matches your DNS64 configuration.
Ensure ICMPv6 and PMTU messages are allowed in firewall rules.

6) Create Two SSIDs

SSID‑A (IPv6‑only): No IPv4 DHCP. Advertise IPv6 DNS64 resolver via RA/DHCPv6.
SSID‑B (Dual‑stack): Keep the existing dual‑stack DHCP for legacy devices.

7) Test From a Modern Phone

Connect to SSID‑A. Visit an IPv6 test site. Try several apps including streaming, maps, and banking.
Try a known IPv4‑only site by domain name. It should load via DNS64/NAT64. If literal IPv4 addresses fail in a specific app, that’s expected.

8) Move Your Daily Devices

Shift laptops, tablets, and consoles that behave well to SSID‑A.
Leave printers and ancient IoT on SSID‑B for now.

9) Expose a Test Service (Optional)

Pick a lab host. Reserve an IPv6 address, open TCP/443 inbound on the firewall, and publish an AAAA record in DNS.
Fetch a Let’s Encrypt cert and test from mobile data. It should work cleanly without port forwarding.

10) Observe for a Week

Watch logs, latency, and battery life on mobile devices (IPv6 often helps, but confirm).
Move more devices as you gain confidence. You can eventually retire SSID‑B.

No Native IPv6? Two Options

Tunnel broker: Use a service that gives you an IPv6 /64 or /56 by tunnel. Feeds into your NAT64 and DNS64 stack. Adds a dependency, but it works.
VPS translator: Run NAT64 on a public VPS and route your 64:ff9b::/96 there via WireGuard. Advertise that prefix internally.

Both are solid until your ISP offers IPv6. Keep the tunnel link stable and monitored.

Performance and Reliability Tips

Happy Eyeballs and Address Selection

Modern clients use Happy Eyeballs (RFC 8305) to try IPv6 and IPv4 in parallel, picking the faster path. On IPv6‑only SSIDs this mostly means fewer timeouts and better roaming behavior. If you see odd DNS latency, check that your DNS64 resolver is local and fast.

MTU and Fragmentation

Respect ICMPv6: Don’t block “Packet Too Big.” NAT64 relies on PMTU discovery.
WAN MTU: If you use PPPoE, account for overhead. A WAN MTU of 1492 is common; ensure LAN MTUs are aligned to avoid fragmentation surprises.

Privacy and Logs

With unique global IPv6 addresses, logs are more precise. That’s great for troubleshooting but can reveal patterns. Use privacy extensions on clients, and if your resolver keeps logs, consider short retention. For home labs, set stable addresses only for servers and infrastructure.

Device Quirks You Might See

Literal IPv4 addresses: An app that connects to 93.184.216.34 directly won’t work on IPv6‑only unless the OS supports CLAT for that app. Use the dual‑stack SSID for that device or app.
Old printers: Some only speak IPv4 mDNS/Bonjour or SMBv1. Keep them on dual‑stack (or isolate and print via a modern host that bridges for them).
Smart TV apps: Most recent models handle IPv6 fine. If a specific app fails on IPv6‑only, park the TV on dual‑stack and send feedback to the vendor.

Security Posture: Better by Design

Going IPv6‑first often improves security by removing accidental port forwards and simplifying traffic analysis. A few must‑dos:

Default‑deny inbound on IPv6. No open services you didn’t intend.
RA Guard on managed switches, if you have them, to prevent rogue router advertisements.
DNS hygiene: Run your own validating resolver or use a reputable upstream. Consider DNSSEC validation on your local resolver.
Separate IoT to its own VLAN/SSID. IPv6 makes lateral movement obvious; keep it limited by policy.

Troubleshooting Playbook

Symptoms and Quick Checks

Some sites hang or load slowly: Ping your DNS64 resolver. If slow, switch to a local resolver or fix upstream latency. Verify ICMPv6 is allowed for PMTU.
“No internet” on IPv6‑only SSID: Check RA advertisements are present (use a packet capture) and that DNS64 is reachable. Ensure NAT64 has a working path to the IPv4 internet.
Specific IPv4‑only app fails: Try the dual‑stack SSID. If it works there, the app likely relies on literal IPv4. Log a vendor ticket and keep it on dual‑stack for now.

Useful Tools

test-ipv6.com: Browser test for IPv6 stack health.
traceroute6 / ping6: Verify routing and reachability hop by hop.
dig +short AAAA example.com: Confirm DNS64 synthesis on IPv4‑only names (you should see a 64:ff9b:: address).

Scaling Up: Beyond a Single Router

If you run multiple access points or a mesh, ensure they bridge the same VLANs and pass IPv6 multicast cleanly. For multi‑site homes or outbuildings connected by point‑to‑point links, distribute your delegated /56 across sites and run a lightweight IGP (like OSPFv3) or static routes. Keep DNS64/NAT64 centralized unless you need local breakout at each site.

When You’re Ready to Go All‑In

Once daily devices hum along on the IPv6‑only SSID, you can consider moving the legacy SSID to a quarantine network or switching it off. Before you do:

Inventory anything still on dual‑stack and decide whether to replace, isolate, or keep dual‑stack running a little longer.
Publish AAAA records for home‑hosted services and tighten firewall rules to only known ports and hosts.
Document your NAT64/DNS64 configuration and make a small runbook for restarts and updates. Simplicity is resilience.

FAQ: Short Answers to Common Questions

Is IPv6 faster?

Often yes, due to fewer middleboxes and better path selection. It depends on the site and your ISP peering. The point isn’t raw speed; it’s reliability and reachability as the internet continues its shift.

Will my gaming setup break?

Modern consoles and PC launchers handle IPv6 well. If a specific game relies on IPv4 literal addresses or odd peer‑to‑peer tricks, use the dual‑stack SSID for that box. Many players see fewer NAT issues after leaning into IPv6.

What about parental controls and ad blocking?

Run them on your local resolver or router. Make sure your filtering stack supports IPv6 addresses and AAAA records. Most modern DNS‑based filters do.

Do I still need a VPN when I’m away?

If you expose nothing inbound, a VPN remains a safe way to reach your home network and lab. With IPv6, inbound access can be clean and explicit, but a VPN gives you defense in depth and avoids opening ports publicly.

Summary:

IPv6‑first improves reliability and avoids CGNAT pain; use DNS64/NAT64 to keep IPv4‑only sites working.
Ask your ISP for DHCPv6‑PD, assign a /64 per LAN, and advertise via RA with SLAAC and DHCPv6.
Run DNS64 locally and pair it with a NAT64 translator using the 64:ff9b::/96 prefix.
Use two SSIDs: IPv6‑only for modern devices, dual‑stack for legacy gear.
Keep ICMPv6 open for PMTU; default‑deny inbound on IPv6 and segment IoT.
Test with modern phones first, then migrate devices; host services with simple IPv6 firewall rules.
If native IPv6 is unavailable, use a tunnel or a VPS‑based translator until your ISP upgrades.