IPv6 on a UniFi Gateway: Prefix Delegation, SLAAC, and Firewall Rules Per Network

Are your devices already reaching the internet over IPv6 without your knowledge? If your ISP turned it on recently, there is a good chance they are — and an equally good chance your UniFi gateway is either ignoring the offer or accepting it with defaults you never reviewed.

Many residential and business ISPs now provision IPv6 alongside IPv4 by default, and a UniFi gateway can take full advantage of it. That said, IPv6 reaches your VLANs in a different way from the IPv4 model you already know, and the security assumptions change with it.

This guide walks through the moving parts in order: how the gateway requests a delegated prefix, how it splits that prefix across networks, and how hosts configure themselves with SLAAC. Finally, it covers the firewall rules that IPv4 NAT used to handle implicitly — the part most setups get wrong.

With IPv4, your ISP hands the gateway one public address, and the gateway hides every internal device behind it with NAT. IPv6 works the other way around: the ISP routes an entire block of addresses, called a delegated prefix, to your gateway, and every device behind it receives a globally routable address of its own.

The mechanism is DHCPv6 Prefix Delegation, now specified in RFC 8415. Here is how the exchange unfolds on the WAN port:

• Solicit. The gateway sends a DHCPv6 Solicit carrying an IA_PD option, usually with a prefix-length hint such as /56 or /60. The hint tells the ISP how large a block you would like, not how large a block you will get.
• Advertise and Request. The ISP's DHCPv6 server advertises an available prefix, and the gateway formally requests it. On most residential networks this completes in a fraction of a second after the WAN link comes up.
• Reply. The ISP confirms the prefix along with preferred and valid lifetimes. The gateway then renews the delegation before those lifetimes expire, the same way an IPv4 DHCP lease renews.
• WAN address. Separately, the WAN interface may receive its own global address through IA_NA or SLAAC, or it may run on a link-local address alone. All three are normal, and a missing WAN global address does not mean delegation failed.

All of this happens before a single LAN device sees an IPv6 address. If the delegation step fails, nothing downstream can work, which is why troubleshooting always starts at the WAN.

In the UniFi Network application, the relevant controls live in the Internet (WAN) settings under IPv6, where you select DHCPv6 as the connection type and set a prefix delegation size. Labels and placement shift between Network application releases, so match the concepts rather than memorizing a menu path.

Keep in mind that the prefix size you request should match what your ISP actually offers. Some ISPs quietly return a smaller prefix than you hinted, while others decline a request they cannot fill — so check your ISP's published IPv6 documentation and request that size first.

One common blocker sits in front of the gateway entirely. If an ISP-supplied router is still routing ahead of your UniFi gateway, it must delegate a prefix downstream, and many ISP routers either cannot or pass along only a single /64 — our guide to fixing double NAT on a UniFi gateway covers bridge-mode and passthrough options.

Fortunately, DHCPv6-PD support is standard across current UniFi gateways, so it rarely decides how to choose a UniFi gateway. What matters more is whether your ISP and any equipment upstream will hand the gateway a prefix large enough for your network plan.

Once the gateway holds a delegated prefix, it carves that block into /64 subnets, one per network. The /64 boundary is fixed in practice: SLAAC depends on a 64-bit interface identifier, so a network with anything smaller than a /64 will leave most clients without addresses.

This is why the delegated size matters so much. The math is straightforward, and here is how each common size plays out:

• /64 delegated. One network only. Your default LAN gets IPv6, and every other VLAN stays IPv4-only no matter how you configure it.
• /60 delegated. Sixteen /64 subnets, using prefix IDs 0 through f. That is enough for most homes running separate trusted, IoT, guest, and camera networks.
• /56 delegated. 256 /64 subnets, using prefix IDs 00 through ff. There is room for every VLAN you have today plus a lab and whatever you add next year.
• /48 delegated. 65,536 /64 subnets, more typical of business plans. At this size, address planning becomes a documentation exercise rather than a scarcity problem.

Each network in UniFi takes an IPv6 interface type — set it to Prefix Delegation, choose the WAN supplying the prefix, and assign a prefix ID. The prefix ID is a hexadecimal value that selects which /64 slice the network receives, so a delegated 2001:db8:abcd:1200::/56 with prefix ID 30 yields 2001:db8:abcd:1230::/64 for that network.

A useful habit is to mirror VLAN IDs in prefix IDs where the numbers allow it. For instance, VLAN 30 for IoT receives prefix ID 30, which makes packet captures and firewall logs readable at a glance — although this only works cleanly with a /56 or larger, since a /60 gives you a single hex digit.

If you are still planning the segmentation itself, start with how UniFi VLANs work and return once the network list is settled. After all, changing prefix IDs later means every client on that network renumbers.

Remember that IPv6 does not need to go live on every network at once. Leaving a network's interface type at None keeps it IPv4-only for global traffic, which is a reasonable staging step for a camera VLAN or a lab you have not reviewed yet.

Note that hosts still generate fe80:: link-local addresses on every network regardless of that setting. In other words, IPv6 inside a VLAN never fully disappears, and that has consequences for both smart-home protocols and firewall planning.

With a /64 assigned, the gateway announces it through Router Advertisements, which tell hosts the prefix, the default router, and — when the RDNSS option from RFC 8106 is included — the DNS servers to use. Hosts then build their own addresses with Stateless Address Autoconfiguration, or SLAAC, without the gateway tracking a lease table.

Most modern operating systems generate more than one address per prefix. A stable address, often derived per RFC 7217, stays consistent on that network, while temporary privacy addresses under RFC 8981 rotate on a schedule and are preferred for outbound connections.

UniFi gives you a choice of how clients obtain addresses and options on each network. The three practical modes are:

• SLAAC only. Clients self-assign from the Router Advertisement and learn DNS through RDNSS. This is the simplest option and the one every IPv6-capable client supports.
• SLAAC plus stateless DHCPv6. Addresses still come from SLAAC, while DHCPv6 supplies DNS servers and other options. This suits networks with older clients that ignore RDNSS.
• Stateful DHCPv6. The gateway assigns addresses from a defined range and records leases, much like IPv4 DHCP. It gives you a lease table to audit, but it does not reach every client.

Android does not implement stateful DHCPv6 address assignment, so a network configured for DHCPv6 addresses alone will leave Android phones, tablets, and many streaming boxes without a global IPv6 address. Accordingly, SLAAC should stay on for any network with consumer devices, and stateful DHCPv6 becomes an optional addition rather than a replacement.

DNS deserves particular attention at this step. If a network advertises your ISP's IPv6 resolvers while IPv4 DHCP points clients at a filtering resolver, dual-stack clients can quietly bypass the filter over IPv6 — align both address families as described in our UniFi DNS filtering guide.

IPv6 also matters on networks where the ISP never enters the picture. Matter and Thread devices communicate over link-local and unique local IPv6 addresses, and Thread border routers send Router Advertisements of their own to announce mesh routes, so keeping that traffic intact is part of running Matter and Thread on a UniFi network.

The practical takeaway is to leave Router Advertisements and multicast discovery working on your IoT VLAN even if you never enable a delegated prefix there. Disabling IPv6 at the host level on a Home Assistant server, for example, is a common cause of Matter commissioning failures.

On IPv4, NAT produces a side effect that many people treat as a security feature. Because inbound packets to your public address have no translation entry unless you create a port forward, unsolicited connections simply have nowhere to go.

IPv6 removes that side effect. Every device on a delegated /64 holds a globally routable address, so the stateful firewall on the gateway is the only thing deciding whether an inbound connection reaches it.

The good news is that UniFi's defaults account for this. Under the zone-based firewall, the default policy from the External zone to Internal blocks new inbound connections while allowing return traffic for sessions your devices started, and it applies to IPv6 as well as IPv4 — confirm it on your own controller version before relying on it.

Where setups go wrong is in the custom rules layered on top. The issues worth checking after you enable IPv6 include but are not limited to:

• IPv4-only address matching. A rule that blocks IoT from reaching your trusted network by matching 192.168.30.0/24 does nothing for IPv6 traffic between the same two devices. Build inter-VLAN policies on zones or networks and set the IP version to both, so the policy follows the network regardless of address family.
• Allow rules with a broad destination. An allow rule from External intended for one service exposes every host it matches once those hosts have public addresses. Scope each one to a single destination address and a single port.
• Blocking ICMPv6 wholesale. Neighbor discovery, Router Advertisements, and Packet Too Big messages all travel as ICMPv6, and RFC 4890 documents which types a firewall should pass. Dropping them breaks address resolution and path MTU discovery, often in ways that look like random stalls on large transfers.
• Guest isolation that only covers IPv4. Verify that the guest zone's block-to-internal policies and client isolation apply to IPv6 traffic too. Our guide to UniFi guest networks walks through the policies to test.

If you segmented smart-home gear following our Home Assistant IoT VLAN setup, re-check every rule there after enabling IPv6 on that network. Rules written by subnet in that guide's IPv4 examples need a zone-based or dual-stack equivalent before IPv6 goes live.

Exposing a service works differently as well. There is no port forward on IPv6; instead, you create an allow policy from the External zone to the host's address on the specific port the service uses.

Keep in mind that privacy addresses rotate, so point that policy at the host's stable address, a DHCPv6 reservation, or a static interface identifier you configured yourself. Then test from outside your network, because a rule that works from a LAN client proves nothing about inbound reachability.

For dashboards and admin panels, an open inbound rule is rarely the right answer on either address family. Our guide to Home Assistant remote access on UniFi compares VPN-based options that keep those services off the public internet entirely.

Once everything is configured, verify from the outside in. Here is a sequence that isolates each layer so a failure points at one cause:

1. Check the WAN. The Internet view in the UniFi Network application should show a delegated prefix and its length. If no prefix appears, stop here, because nothing on the LAN side will work.
2. Check each network. A client on every IPv6-enabled VLAN should hold a global address inside that network's /64, visible with ip -6 addr on Linux, ipconfig on Windows, or the network details pane on macOS. An address outside the expected /64 usually means a prefix ID mismatch.
3. Check routing. A ping -6 to a known IPv6 host, or a visit to a dual-stack test site such as test-ipv6.com, confirms traffic actually leaves the network. Addresses without connectivity typically point to blocked ICMPv6 or disabled Router Advertisements.
4. Check the firewall. From an outside IPv6 connection, such as a phone on cellular data, confirm that an unexposed device does not answer and that any intentionally exposed service does. This is the only test that proves your inbound policy works.

When something fails, the cause usually falls into one of a handful of buckets. Some examples of what to look for include:

• No prefix at all. An ISP router is still routing upstream, IPv6 is not provisioned on the account, or the WAN is set to the wrong IPv6 connection type. Confirm with your ISP before changing anything else.
• A prefix that is too small. You requested a /56 and received a /64, which covers one network only. Adjust the requested size to what the ISP supports, then renew the delegation.
• IPv6 that works and then stops. The delegated prefix changed and something was pinned to the old one. This is the most disruptive failure, and it deserves its own plan.

Many residential plans tie the delegation to the gateway's DHCP Unique Identifier, or DUID, and may issue a new prefix after a reboot, an extended outage, or a hardware replacement. Accordingly, build policies on zones and networks rather than literal prefixes, and treat any rule pinned to a full IPv6 address as something to re-check after a prefix change.

Dual-WAN setups add one more wrinkle. A backup connection — particularly a cellular one — may not deliver a delegated prefix at all, so IPv6 clients can lose global connectivity during a failover and fall back to IPv4 through Happy Eyeballs; account for that in your gateway WAN failover design.

IPv6 on UniFi rewards a little upfront planning: a prefix size that covers every VLAN, SLAAC on every network with consumer devices, and firewall policies built on zones instead of IPv4 subnets. After all, getting addresses is the easy part, and controlling what reaches them is where the real work lives.

If you are still deciding which hardware should sit at your demarc, compare the current UniFi gateways and confirm each model's WAN options against your ISP's IPv6 offering before you buy. Then work through the sequence above one network at a time, and IPv6 will behave as predictably as the IPv4 setup you already trust.