IPv6 and home devices: why no NAT means you need a firewall rule

The core difference from IPv4

Under IPv4, most home networks share a single public address across every device through NAT (Network Address Translation) at the router. That sharing is really meant to stretch a scarce resource — there aren’t enough IPv4 addresses for every device to have its own — but it has a well-known side effect: an unsolicited inbound connection from the internet generally has nowhere to go, because NAT has no existing mapping to route it to any specific device. Many people have come to rely on that side effect as if it were a firewall, even on networks with no explicit firewall rules at all.

RFC 8200 defines IPv6 with a vastly larger address space specifically so NAT isn’t necessary — every device on an IPv6 network can have its own globally unique, directly routable address. That solves real IPv4 problems (the CGNAT sharing and inbound-connectivity issues covered in our CGNAT guide), but it also removes the accidental protection NAT provided. On IPv6, whether an unsolicited inbound connection reaches your smart camera depends entirely on whether a real firewall is blocking it — not on an address-translation side effect.

Why this isn’t automatically a disaster

To be clear: a correctly configured IPv6 firewall should behave the same way IPv4 NAT does in practice — blocking unsolicited inbound connections by default while allowing outbound-initiated traffic back in. RFC 6092, “Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service,” exists specifically to describe what a home router’s IPv6 firewall should do by default, precisely because the IETF recognized that losing NAT’s incidental protection needed to be replaced with an explicit requirement, not left to chance. Separately, RFC 4864, “Local Network Protection for IPv6,” discusses the broader set of techniques (including simple stateful filtering) that can replicate NAT’s protective side effects without needing NAT itself.

Most mainstream router vendors shipping IPv6-capable hardware today do implement a default-deny stateful firewall for IPv6, mirroring IPv4 behavior. The risk is concentrated in older routers, firmware that added IPv6 support as an afterthought, or custom/DIY router setups where IPv6 firewalling wasn’t configured as carefully as the IPv4 side.

How to check your own setup

1. Confirm whether you have IPv6 at all. Run AdminKit’s what is my IP tool — if it reports an IPv6 address alongside your IPv4 one, your ISP and router are handing out IPv6 addresses to your devices.
2. Check your router’s firewall settings specifically for IPv6. Look for a setting labeled something like “IPv6 firewall,” “IPv6 filtering,” or “stateful IPv6 inspection” in your router’s admin interface, separate from the general IPv4 firewall settings — some routers genuinely do configure these independently, and it’s worth confirming both are enabled rather than assuming one covers the other.
3. Test from outside. Port check run against your own IP, with your own consent, checks commonly-exposed device ports — if your router supports it, check whether this reflects your IPv6 address’s exposure as well as IPv4’s, since some consumer tools only ever test the IPv4 side.
4. Identify which devices actually have global IPv6 addresses. Not every device needs to be reachable from the internet; devices that only ever initiate outbound connections (most smart-home gadgets) don’t need an open inbound path at all, regardless of protocol.

What to actually do

• Confirm your router’s IPv6 firewall is enabled and set to deny unsolicited inbound connections by default — this should be the out-of-the-box behavior on modern routers, but don’t assume; check the setting directly.
• Update router firmware. IPv6 firewall implementations have matured significantly over the years; an old firmware version may have gaps that a current one has closed.
• Avoid manually opening IPv6 inbound rules you don’t specifically need, the same discipline you’d apply to IPv4 port forwarding — the difference with IPv6 is that each device has its own address to target, so a careless “allow all inbound to this device” rule exposes that device specifically, not a shared address.
• Keep devices that don’t need inbound reachability on the default-deny path — smart plugs, sensors, and most IoT devices only need outbound connectivity to their cloud service or local hub, and should never need an inbound rule opened for them.
• Use the subnet calculator (subnet-calculator) if you’re working with IPv6 prefixes directly and need to understand how your ISP’s allocation breaks down across your network segments.

IPv6 privacy addressing isn’t a firewall either

Most modern operating systems generate temporary IPv6 addresses for outbound connections (sometimes called privacy extensions), rotating them periodically so a device isn’t easily tracked across sessions by address alone. It’s easy to assume this incidentally protects against inbound scanning too, since an attacker scanning an old address might find nothing there later. In practice, a device typically still holds a stable address alongside its temporary ones for any service that needs to be found consistently (like file sharing or a local server), and an attacker scanning a live, recently active address range has a reasonable chance of finding the stable one regardless of how many temporary addresses have rotated past. Privacy addressing is a genuinely useful tracking mitigation; it isn’t a substitute for firewall rules that actually decide whether an inbound connection gets through.

The bigger picture

IPv6’s removal of NAT is a genuine improvement for connectivity — it’s a large part of why CGNAT exists as a stopgap on the IPv4 side at all, and native IPv6 avoids that problem entirely where both ends support it. The tradeoff is that the firewall, not an address-sharing side effect, is now doing the actual protective work, so it’s worth the few minutes to confirm yours is doing its job rather than assuming it is. AdminKit’s planned Protective DNS is designed to give ongoing, per-device visibility into what’s happening on your network regardless of which IP version is in use — it is in early access and not available yet, so a direct firewall check today remains the most reliable option.