[SOLVED]Assign dynamically provided IPv6 GUA & ULA via DHCPv6 to same LAN subnet

[_c_v_]

Hello everyone,

I am seeking your assistance in configuring IPv6 on OPNsense 23.1.7_3. Specifically, I would like to know how to assign IPv6 GUA addresses dynamically provided by the Internet provider and ULA addresses simultaneously on the LAN interface. Additionally, I would like to permanently assign the same ULA addresses to clients similar to DHCPv4.

Here is some more information on my setup: I have installed OPNsense in four private locations, each with at least one LAN interface (with an additional OPT interface in one location) and one WAN interface. Each WAN interface is connected to the Internet via PPPoE and receives a dynamic public IPv4 address. The Internet provider also provides a dynamic IPv6 address for each location via DHCPv6 and a dynamic /56 IPv6 network for use in the LAN.

In each LAN interface, I have assigned private IPv4 addresses (RFC 1918) and I use DHCPv4 to assign IP addresses to all devices in the LAN network. All devices can connect to the IPv4 Internet via IPv4 NAT. I have also configured SLAAC to assign public IPv6 addresses to every device in the LAN network so that they can access the IPv6 Internet.

The four locations are connected via wireguard VPN, and all LAN devices can communicate with each other via private IPv4 addresses. I have manually registred DNS names for all devices using A records.

Additionally, I would like all devices in the LAN network to communicate with each other via IPv6 ULA addresses since the GUA addresses are dynamic. I have set up virtual IPv6 ULA addresses on each LAN interface and assigned random IPv6 ULA addresses to all devices via SLAAC. However, I would like to assign specific IPv6 ULA addresses to each device manually and set the appropriate AAAA records for the names with the A records via DNS.

When I set up DHCPv6 on one of the LAN interfaces, only the GUA subnet is available, and not the ULA subnet. How can I configure DHCPv6 to make the ULA subnet available for selection, or even better, both the ULA and GUA subnets?

I would appreciate any help you can provide. Thank you very much!  :)

_c_v_

[Patrick M. Hausen]

ULA is broken.

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

If I needed some static IPv6 address space - within limits, like a handful of /64 - with the intention to use them for private networks and NAT66 or NPT them to the public Internet, I'd borrow them from either my own static allocation or someone elses who agrees to never publically route them.

For a "business" DSL line in Germany you regularly get one static IPv4 address plus a /56. That's 256 networks. I use part of my German Telekom assigned /56 for my VPS based VPN tunnels all over the world. Since I am NATing them outbound, nothing bad will happen. So of course there are a handful of /64 that are active and reachable - bit from those that are not, I can pick some at will for "private" LANs.

If you have no way of getting any small prefixes, you could register and account with Hurricane Electric who as far as I know still offer IPv6 via tunnel with fixed addresses for free. Then use some of those.

HTH,
Patrick

[_c_v_]

Hello pmhausen
and thank you for the helpful suggestion.

I was not aware of the issues with ULAs until now.

I will think about how I will implement IPv6 in my internal network in the future.

Thank you for the solution and your prompt response.

[bimbar]

I've read that article, but I'm not clear on why I should not use ULA in addition to GUA and possibly IPv4 to address a local server network or something of that sort.
Even if ULA are never used in source address selection, I should still be able to reach a server that has an ULA for local addressing?

EDIT: I see, it seems to be able to choose a ULA address as source to reach a GUA address on the internet, which will obviously not work. So, in conclusion, IPv6 to reach the internet, RFC1918 for local networking?

EDIT2: The above scenario seems to be impossible due to source address selection rules.
So, scenario: Both client and server have

- dynamic GUA
- static ULA
- RFC1918 IPv4

The DNS entry for the server references to the ULA only. SO in that case, the client should be able to contact the server ULA to ULA?

[Patrick M. Hausen]

@bimbar of course that last scenario will work. I am more concerned about people trying to implement a stable prefix for their LAN despite the provider changing prefixes regularly. Using ULA and NPT will not work in most cases because
in the "happy eyeballs" algorithm the priority is

GUA > IPv4 > ULA

So as soon as you have dual stack - RFC1918 or not, the algorithm does not further subdivide "IPv4" - ULA is never used to reach out to the Internet.

That's why I pick unused GUA /64s from here or there if I need a setup like this.

[bimbar]

Ok, so you should not do local static ULA + IPv4 and then NAT to GUA, that makes sense.

But Opnsense supports this, you should always do GUA + IPv4 locally, and if you need servers or other statically addressed hosts, use ULA in addition to that, no NAT.

[_c_v_]

I apologize for the repeated inquiry, but I still feel that I haven't fully understood it to 100%.

Example client has:

Dynamic Global Unicast Address (GUA) assigned by the Internet service provider (for client's communication with the IPv6 Internet).
Unique Local Address (ULA) for exclusive internal communication of the client, such as from Location A to the server at Location B (the server also has a ULA).
RFC1918 IPv4.
Now, if a DNS name points to an internal server (ULA + RFC1918 IPv4), and the clients have all three addresses as described above, which address is typically used for communication: IPv6 ULA or RFC1918 IPv4?

[Patrick M. Hausen]

Now, if a DNS name points to an internal server (ULA + RFC1918 IPv4), and the clients have all three addresses as described above, which address is typically used for communication: IPv6 ULA or RFC1918 IPv4?

IPv4.

As I wrote: GUA > IPv4 > ULA

The algorithm will always pick IPv4 over ULA. Always. That's why ULA is mostly useless, now.

See https://blog.ipspace.net/2022/05/ipv6-ula-made-useless.html for reference. He links to an RFC draft that goes deeper into the technical aspects of the matter.

[_c_v_]

Thank you for the prompt and clear clarification!

So, in other words, as long as IPv4 addresses are available, ULA is completely useless unless it is explicitly / exclusively specified as the destination address, without an IPv4 alternative. Once IPv4 is also a possible destination, ULA is not used.

[Patrick M. Hausen]

Correct. Brilliant design, innit?  ;)

Nota bene: this all applies to clients that use DNS and receive an IPv4 address and an IPv6 ULA for the same FQDN. It does not matter what addresses are actually assigned to a system/vm/container/... but which addresses a client trying to access this system receives from DNS.

HTH,
Patrick

[copec]

I don't think people understand the design or the decisions that were made.

IPv6 should be setup as if IPv4 doesn't exist. In that case in order to have a local network that has more than basic link-local and MDNS it needs to have a ULA subnet in order to allow consistent static numbering for servers and communication across different interconnected networks. In the past RFC1918 filled this roll for most organizations since they don't have static public IPv4 delegations. The large majority of IPv6 GUA delegations now happen via DHCPv6 PD, and that's subject to arbitrarily change and so can't be relied upon for statically numbering a local network, thus you need a ULA subnet if you don't have a static IPv6 delegation in order to accomplish a stable local network.

If deciding between using IPv4 and IPv6 local addresses as the source:
- For any endpoint IPv4 address (RFC1918 or public), assume that is the currently working system for any local IPv4 address (RFC1918 or public).
- For endpoint IPv6 address that are GUA assume local ULA has no connectivity. From their view nobody should be using NAT66 for general connectivity, and most ULA configuration in the past has not actually used it.
- For endpoint IPv6 address that are ULA outside of local subnet, you are safer assuming no connectivity, because inter-organization routing of private ULA addresses remains uncommon unlike inter-organization routing of RFC1918 in the past.
- For endpoint IPV6 address that are GUA, if you have a local GUA address you can safely assume connectivity to that IP.

The problem is that the majority of ULA use in the past was without, or problematic public IPv6 Internet connectivity. So it makes perfect sense to choose a local IPv4 to connect to a IPv4 over a local ULA to a GUA IPv6, because we can assume in almost all cases that the existing legacy local connectivity is working.

It shouldn't really be a problem, because if dual stack, then the hostnames should map to the same service endpoints, and the highest probability of connectivity by far is to pick IPv4 under those circumstances.

However, I think most people will continue to use IPv4 RFC1918 as the stable numbered local connectivity forever in the future. The only use case left if IPv4 never goes away is stable inter-organizational routing becoming more problematic with conflicting RFC1918 space.