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, commonly assigned via SLAAC and EUI-64. The local signaling that makes SLAAC possible in the first place — discovering routers and resolving neighbors’ addresses — runs over Neighbor Discovery Protocol, operating entirely over link-local addresses regardless of which global address a device ends up with (the link-local range, along with other reserved IPv6 blocks, is formally defined in IANA’s IPv6 Special-Purpose Address Registry). 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. It also sidesteps a smaller IPv4 quirk entirely: reaching your own self-hosted device by its public address or domain name from inside the same network requires a router feature called NAT loopback, which isn’t universally supported — IPv6’s lack of NAT removes the need for it in the first place. 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. A device can also pick up a reachable IPv6 address through legacy tunneling mechanisms like Teredo or 6to4, which can leave it exposed despite a firewall that was only ever configured with native IPv6 (or IPv4) in mind.

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. NIST’s guidelines for secure IPv6 deployment (SP 800-119) make the same point independently: losing NAT’s incidental packet-filtering side effect means an explicit, correctly configured firewall policy becomes a required part of an IPv6 deployment, not an optional hardening step.

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 — running both at once is called dual stack — your ISP and router are handing out IPv6 addresses to your devices. Some ISPs skip dual stack entirely and run an IPv6-only network instead, reaching the IPv4 internet behind the scenes with NAT64 and DNS64 — your devices still only ever see IPv6 addresses either way.
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 — see how to read an open ports scan result for what each flagged port means. 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.
• Check a specific address against your firewall rule’s range with AdminKit’s IP in CIDR tool before trusting an inbound rule written against a prefix — it tests one address against any number of CIDR ranges at once, offline, so a typo in the prefix doesn’t silently widen or narrow what the rule actually allows.

IPv6 privacy addressing isn’t a firewall either

Most modern operating systems generate temporary IPv6 addresses for outbound connections (sometimes called IPv6 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, printing, or a local server discovered via mDNS), 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. A direct firewall check is the most reliable option for that. For per-device protection that works the same over IPv4 and IPv6, Netbase builds and runs Protective DNS for your network as a custom engagement — a filtering resolver that blocks known-malicious domains per device and logs every block; talk to our team about it.

Reference: IPv6.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.