Guide: Achieving Full IPv6 on All VLANs with an ISP-Limited /64 Prefix

[aerandir]

TL;DR - The Short Version
My ISP only provides a single /64 IPv6 prefix, making it impossible to give different VLANs their own native IPv6 subnets. The solution is to use a private ULA (Unique Local Address) range for all internal VLANs and create a single IPv6 Outbound NAT rule in OPNsense. This translates the private ULA addresses to the WAN's public IPv6 address, giving every device on every VLAN full internet access.

Summary of Steps - The Long Version

• Plan Your Network: Choose a private ULA prefix for your network (e.g.,
  
  
  Code Select Expand
  fd00:dead:beef::/48) and assign a /64 subnet from it to each of your VLANs.
• Configure Interfaces: Set up your OPNsense interfaces. The WAN interface gets its public address via DHCPv6. Your LAN/VLAN interfaces are configured with static ULA gateway addresses from your plan (e.g.,
  
  
  Code Select Expand
  fd00:dead:beef:10::1/64).
• Enable Router Advertisements (RA): On each internal interface, enable Router Advertisements in "Assisted" mode so clients can auto-configure their IPv6 addresses. Clients will get DNS server info from your existing IPv4 DHCP setup.
• Create the NAT Rule: In Firewall > NAT > Outbound, switch to Hybrid mode and add one IPv6 rule. This rule should be on the WAN interface and translate the traffic from your entire ULA source (
  
  
  Code Select Expand
  fd00:dead:beef::/48) to the Interface Address.
• Verify Firewall Rules: Ensure your firewall rules for each VLAN allow IPv4+IPv6 traffic to pass from the local subnet to any.

The Problem: One /64 to Rule Them All

Many of us are enthusiastic about deploying IPv6 on our home networks. The dream is to have multiple, neatly segmented VLANs—for trusted devices, servers, IoT, guests—each with its own properly routed IPv6 subnet.
I want to preface this by saying that I am very new to the world of IPv6, and this entire project has been a massive learning experience. After migrating my home network from pfSense to OPNsense, I spent weeks trying to solve this exact problem. I scoured forums and documentation but couldn't find a clear guide for this specific scenario—or perhaps my inexperience meant I wasn't searching for the right terms. This guide is the product of that struggle, written to hopefully save others the time and frustration I went through.
The core of the issue is that many ISPs create a significant roadblock:

• They provide only a single /64 IPv6 prefix to residential customers.
• They often require you to use their provided router, which may or may not support features like Prefix Delegation (PD).

A single /64 prefix cannot be subnetted further for different VLANs. This leaves you with a frustrating choice: give one VLAN native IPv6 and leave the rest on IPv4-only, or dive into complex workarounds that are often unreliable.
After moving from pfSense to OPNsense and spending a great deal of time researching, I found a stable and effective solution. This guide documents how to use Unique Local Addresses (ULA) combined with Outbound NAT (NAT66) to provide robust IPv6 internet access to every device on every VLAN, even with a limited ISP setup.
The Solution: ULA for Internal, NAT for External
Instead of trying to split the unsplittable /64, we will sidestep the problem entirely.

• Internal Network: We will assign a private
  
  
  Code Select Expand
  fd00::/8 ULA prefix to our internal networks. This allows us to create as many /64 subnets as we need for our VLANs, giving us full control over our internal addressing scheme.
• External Access: We will create a single Outbound NAT rule. This rule will take all outgoing IPv6 traffic from our private ULA range and translate its source address to the single public IPv6 address on our OPNsense WAN interface.

This is conceptually identical to how IPv4 NAT has worked for decades and is a perfectly valid way to handle this common ISP limitation.

Step 1: Plan Your ULA Network
First, choose a ULA prefix for your network. You can use an online generator or create your own

Code Select Expand

fd00::/48 prefix. For this guide, we will use the example prefix

Code Select Expand

fd00:dead:beef::/48.
Next, plan the /64 subnets for your VLANs.

Network Name	VLAN ID	IPv4 Subnet	IPv6 ULA Subnet
LAN (Trusted)	10	Code Select Expand 10.10.10.0/24	Code Select Expand fd00:dead:beef:10::/64
SERVERS	20	Code Select Expand 10.10.20.0/24	Code Select Expand fd00:dead:beef:20::/64
DMZ	50	Code Select Expand 10.10.50.0/24	Code Select Expand fd00:dead:beef:50::/64
GUEST	99	Code Select Expand 10.10.99.0/24	Code Select Expand fd00:dead:beef:99::/64

Step 2: OPNsense Interface Configuration

Assign your IPv4 and the newly planned IPv6 addresses to your OPNsense interfaces.

WAN Interface

• Navigate to Interfaces > [WAN].
• IPv4 Configuration Type: Set to DHCP.
• IPv6 Configuration Type: Set to DHCPv6.
• Ensure Request only an IPv6 prefix is not checked. You need OPNsense to get a public IPv6 address on the WAN interface itself for the NAT to work.

LAN & VLAN Interfaces

• Navigate to Interfaces > [LAN] (and repeat for your other VLANs).
• IPv6 Configuration Type: Set to Static IPv6.
• In the Static IPv6 configuration section, enter the gateway address for that subnet (e.g.,
  
  
  Code Select Expand
  fd00:dead:beef:10::1 with a /64 prefix length).

Step 3: Configure Router Advertisements (RA)

Router Advertisements are essential for your clients to automatically configure their IPv6 settings.

• Navigate to Services > Router Advertisements > [LAN] (and repeat for other interfaces).
• Set the Router Advertisement mode to Assisted. This is a flexible option that allows clients to get their address via SLAAC while still getting DNS information from a DHCPv6 server.
• Set Router Priority to Normal.
• DNS Configuration: Since your clients will be dual-stack, the simplest method is to let them receive DNS server information via their IPv4 DHCP configuration. Leave the DNS servers field in the RA settings blank. As long as your internal DNS resolver (like Technitium or Pi-hole) can resolve AAAA records, everything will work seamlessly.

Step 4: Create the Outbound NAT Rule

This is the core of the solution.

• Navigate to Firewall > NAT > Outbound.
• Change the mode to Hybrid outbound NAT rule generation and click Save.
• Click Add to create a new rule.
• Configure the rule as follows:
  
  
  • Interface: WAN
  • TCP/IP Version: IPv6
  • Source address: Enter your entire ULA prefix,
    
    
    Code Select Expand
    fd00:dead:beef::/48. This single rule will cover all your VLANs.
  • Translation / target: Select Interface Address.
  • Description:
    
    
    Code Select Expand
    NAT66 for all ULA networks
• Click Save and then Apply changes.

Step 5: Verify Firewall Rules

Ensure your internal interfaces have a firewall rule that permits IPv6 traffic to the internet. A default rule allowing traffic from [Interface] net to any is usually sufficient. Just make sure the TCP/IP Version is set to IPv4+IPv6.

Conclusion

By implementing this ULA and NAT66 configuration, you can overcome the limitations of a single ISP-provided /64 prefix. This setup provides stable, firewalled IPv6 internet access to all your internal networks, allowing you to build a fully modern, dual-stack environment without relying on your ISP for proper network delegation.

[Maurice]

Nothing wrong with deploying ULAs, but treating IPv6 like IPv4 (private addresses NATed to a single public address) has a major caveat: When choosing a source address, clients always prefer IPv4 over a ULA (unless the destination is also a ULA). This means the IPv6 NAT will only get used for connecting to IPv6-only services. For dual-stack services, your clients will use IPv4. As a result, you'll see very little IPv6 Internet traffic with this setup.

So yes, better than nothing, but not a "fully modern dual-stack environment".
As a slight improvement, you can deploy your single delegated /64 in the "primary" LAN, while using NAT for the others.

Cheers
Maurice

[meyergru]

On a side note: If you really only have one /64 prefix, you can still use any subnet thereof via static and DHCPv6 assignments. It is only SLAAC that breaks with anything <> /64 (as of today).

Having said that, I never really tried that besides static assignments. Both static and DHCPv6 would only work wll if static prefixes are used - if they are dynamic, you probably need the fast change "push"-type mechanism that only SLAAC can provide, that is why I advocate for it here.

In short: if you have both dynamic prefixes and a /64 assignment only, you are limited to one /64 LAN and for the other VLANs, you need NATv6 like depicted here (Maurice's caveat is applicable). If the your prefix is fixed, you can use either DHCPv6 or static assignments, because then, you can use arbitary prefix lengths for all VLANs.

You might get away with a dirty hack, however: Because of the vastness of the IPv6 address space, you could use an unused IPv6 prefix instead of an ULA prefix. That way, this prefix would not be prioritized lower than IPv4. You can refer to this to find something useful - I would probably choose 3fff::/48 or 4000::/48. Also, it should be fairly easy to change that range, should it be used later on (3fff::/48 won't).

[Patrick M. Hausen]

Or as I suggested in the past you borrow a handful of /64 GUAs from a friend, colleague, employer, ... with a larger fixed assignment. Still need to NAT, of course, but your clients will think they have GUA IPv6.

[millerwissen]

Nothing wrong with deploying ULAs, but treating IPv6 like IPv4 (private addresses NATed to a single public address) has a major caveat: When choosing a source address, clients always prefer IPv4 over a ULA (unless the destination is also a ULA). This means the IPv6 NAT will only get used for connecting to IPv6-only services. For dual-stack services, your clients will use IPv4. As a result, you'll see very little IPv6 Internet traffic with this setup.

So yes, better than nothing, but not a "fully modern dual-stack environment".
As a slight improvement, you can deploy your single delegated /64 in the "primary" LAN, while using NAT for the others.

Cheers
Maurice

So I actually have quite a bit of experience with NAT66 myself even made this tutorial to help people that aren't familiar with it:

https://forum.opnsense.org/index.php?topic=47644.0

But what you just said I haven't really noticed on any of my deployments over the years both official ULAs and the rest of the f000::/4 range which are technically not official "ULAS" and might be why they bypass this behaviour altogether.

I have seen the behaviour you're mentioning on only some specific use cases and very very rarely:

- Linux i almost never ever see it preferring IPv4 over IPv6
- Windows Server 2016-2025 almost never IPv4 over IPv6
- MacOS Mojave-Tahoe same as Linux
- Windows 10/11 occasionally I have indeed noticed this behaviour on specifically Desktop versions of Windows for some odd reason i ping eg google.com and it goes to ipv4 instead of ipv6 but ping -6 google.com will immediately just ping with ipv6 but it's not consistent some domains will prefer ipv4 some ipv6.

 I'm not able to replicate this consistently nor explain why but I'm curious if you've tested many other OSes and if you only use strictly ULAs or any of the other f000::/4 subnets.

[Patrick M. Hausen]

Only strictly ULAs.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

[millerwissen]

Only strictly ULAs.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

I didn't know about that at all thanks for sharing this, I will add this information to my tutorials it's quite useful to know my "illegal" f000::/4 addresses are immune to this nasty RFC :)

[Patrick M. Hausen]

Hence my recommendation to "borrow" GUAs from somebody with a large allocation (/56 or /48). I you insist on doing NAT66 that is ;-)

[lilsense]

I highly recommend testing strict IPv6 case once deployed. Meaning remove all existence of IPv4 and test to make sure ALL is working as expected which if correctly performed all sites regardless of IPv4 only should work flawlessly. Otherwise, it's not properly set, period.

This would make Patrick's link moot point since there should not be a case where dual stack would be needed. 

Dual Stack is a like speaking Tunisian, half French, half Arabic. Who know which half is what... </joking>

If you really are trying to learn the "ula made useless" is not really important. :) Since the ultimate goal is Site wide IPv6 only.

otherwise, there's no point in deploying IPv6 other than after midnight stress of why google link sends me to my fav pR0n site troubleshooting. :D

[Patrick M. Hausen]

I beg to differ. Dual stack is the standard and preferred mode of operation today.

[millerwissen]

Patrick is right on this one, Dual stack has been the standard for a while we're technically "mid transition" still. Here's my timeline (nothing official just my personal opinion):

1990s - Prototyping and testing of IPv6 stacks on Windows NT4/Linux etc
2000s - The very early transition/adoption dual stack a must
2010s - Early transition - lots of mass adoption more ISPs start to offer ipv6 to home customers but many IPv4 systems still around, cloudflare helps significantly with the shift to IPv6.
2020s - Mid transition - Most people have IPv6 but many legacy systems and slow to adopt companies and systems still on IPv4 eg some banks and government systems.
2030s - Post Transition - Most will be on dual stack by now and ready to move on, most new deployments can pretty much be IPv6 only no need to support IPv4 anymore but will be on dual stack until the end, NAT44 and NAT64 heavily used to minimise IPv4 costs, IPv4 begins to be phased out and removed to simplify things.
2040s - Obsolescence Phase - This is past year 2038 problem and IPv4 use is highly unlikely to still exist by then except for legacy systems which will also have to be 64bit due to the year 2038 problem, most if not all 32 bit systems completely obsolete and so are IPv4 deployments.

NAT66 and separate local networks can help people looking for private networks similar to RFC1918 so there is no reason to have IPv4 unless people simply don't know how to set things up via IPv6 or are using old software/legacy/retro hardware.