NAT66 and IPv6 masquerading

• This how-to describes the method for setting up NAT66 aka NAT6 with IPv6 masquerading on your OpenWrt router.
• Assuming default OpenWrt settings and a working IPv6 connection on the router.
• Avoid using NAT66 and better use relay mode if you are provided with a /64 prefix.
• It is also best to avoid using NAT66 unless you are facing the following problems:
  • IPv6 multihoming without BGP.
  • Performing stateless 1:1 NAT for migration purposes.
  • Your ISP uses a dynamic prefix and you need stable addressing.
  • Creating a subnet for when the network doesn't support subnetting.
  • Being provided a smaller prefix than a /64 or worse, none at all or a ULA address.
• Follow NAT64 to provide access to IPv4-only services from IPv6-only client networks.

Enable IPv6 masquerading on your upstream zone.

# Configure firewall
uci set firewall.@zone[1].masq6="1"
uci commit firewall
/etc/init.d/firewall restart

Enable IPv6 by default and announce IPv6 default route if necessary.

Make sure DHCPv6 uses the following settings (on an unmodified OpenWrt installation these should by the default):

• “Router Advertisement-Service” and “DHCPv6-Service” are set to server mode*
• “DHCPv6-Mode” is stateless + stateful
• “NDP-Proxy” is disabled

You can check this by running the following command:

# uci show dhcp.lan
...
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.lan.ra_management='1'

If the output is different, you are not using the defaults and you should set these options to the ones shown above. If there is an additional line starting with dhcp.lan.ndp, the NDP-Proxy is enabled and should be disabled. Setups with “DHCPv6-Service” disabled have been reported working as well by some users. However, if “DHCPv6-Service” is disabled, some clients (e.g. Android devices) will prefer IPv4 over IPv6. Therefore, enabling the “DHCPv6-Service” server mode is recommended.

Typically relevant when you do not have a real global prefix assigned by your ISP (in which case your ULA should be a real ULA), AND you want to run local IPv6 (e.g. for NAT66), AND you have applications that preference IPv4 over IPv6 ULA addresses.

A trick to get around this is set your ULA prefix to a non-ULA value.

The default ULA prefix represents an address that is not globally routed on the internet by design (only between provider networks).

A lot of clients will prefer IPv4 over a ULA IPv6 address if there is no global IPv6 address assigned, so you may need to change your existing ULA prefix to indicate a global address (i.e. trick it with a non-ULA prefix) to ensure traffic goes over IPv6 by default when possible.

When changing the ULA prefix, it doesn't necessarily have to start with d, but to avoid conflicts, you should use a prefix that is not being used yet. The prefix fd is generally an actual ULA, other f address have specific meanings, and existing allocated public addresses start with 2. The letters a through e are unassigned for the time being and therefore safe choices.

Setting ula_prefix to auto will auto-generate a new valid ULA prefix.

Using your ISP assigned prefix as ULA should also work.

However, unless you have a static IPv6 prefix assigned by your ISP, this is not recommended, since it can cause address conflicts once the prefix changes.

But normally if you have a static prefix that you can delegate across your LAN (i.e. real global addresses), then you won't need to change your ULA prefix.