Dynamic IPv6 prefixes / dynamic DNS / VPN: Handling via NPTv6?

[iam]

I have two sites, each with their own VLANs, which are connected via Wireguard. Both are only assigned a dynamic /56 IPv6 prefix by the Internet service provider. This is known to cause some complications in the area of DNS and VPN firewall: e.g. devices could enter the changing IPs in the internal DNS, but these would not be routed via the VPN.

I think the easiest way would be to use a private IPv6 prefix and make it accessible to the outside world via NPTv6. As of OPNsense 24.1.x there is the new option “Track interface”. However, you can only create a rule with this if the IPv6 interface is not configured statically but via track interface. Unfortunately, this is unsuitable for this use case, as I then have all kinds of problems with the dynamic IPs in the network.

How should I deal with this problem? I would like to be able to safely activate IPv6 in the internal network at some point.

[iam]

As a workaround, I am tracking the guest WiFi interface in the NTPv6 rule as it has a global IPv6 address. This seems to work so far.

[iam]

Has anyone tested NPTv6 with OpenVPN? It is currently not working for me, although the OpenVPN network has the same /57 prefix as the other /64 subnets. The rule should work accordingly, but I also created an explicit rule as a test.

[iam]

Unfortunately, the same problem seems to exist with Wireguard.

Otherwise, NTPv6 is working for now and I finally have IPv6. Unfortunately, IPv4 is preferred over ULA to GUA, which is why I will probably roll out dynamic GUAs in addition to the ULAs sooner or later. Unless there is a way to change this preference centrally via OPNsense.

[bimbar]

GUA > IPv4 > ULA is what the RFC specificies, so this is unlikely to change.

Which is why the consensus here is to not use ULA if at all possible.

[Patrick M. Hausen]

Use an arbitrary GUA /64 for your internal networks which you borrow from someone with a fixed prefix. I get a fixed /56 with my Telekom business lines so that's 256 /64s free to use from each.

You just need to somehow arrange for that /64 to never be used for public connectivity.

[iam]

I don't really have any major problems with the ULAs. Internally, many things now run via IPv6 instead of IPv4. If IPv4 were to be switched off on the Internet tomorrow, I would still have Internet access. In this respect, I have gained a lot and still have an independent local network.


I therefore see it as a good decision to introduce IPv6 on the basis of ULAs and NPTv6. As a private user, it is difficult to get a fixed GUA prefix, which incidentally also has disadvantages for privacy (I know that there are also other tracking options). In this respect, you actually want to have two prefixes: A fixed one for internal use and a dynamic one for internet traffic. The former is the intended use case of the ULAs and the standard allows for ULAs and GUAs to be used in parallel.

NPTv6 has its limitations when using ULAs, which is why it may make sense to roll out both prefixes directly to the internal networks. Does anyone know whether this can already be implemented in a stable manner? Or do the problems sketched in this thread still apply?

[Patrick M. Hausen]

I am suggesting using a GUA prefix with NPT6. For example register with Hurricane Electric for a tunnel and you will get a /48. Use a single /64 from that with NPT.

For a e.g. small business with a handful of people working from home, get a fixed /56 for the main office. Pick a /64 from that for each home location. Use NPT for Internet access in the smaller locations while routing the GUA addresses through your VPN tunnels.

This is a "hack" to make the "happy eyeballs" algorithm prefer IPv6 over IPv4 while still working with dynamic prefixes and NPT.

[iam]

This would indeed be a possibility. The disadvantage would be that there would again be a dependency on a service provider. I don't think anyone can guarantee that the service will last forever.

In this respect, I would prefer to stay with the ULAs. The only question is whether ULA to ULA is always preferred over GUA to GUA. I hope so, because otherwise ULAs would be really broken and I would get the problems again that I originally wanted to avoid with ULAs.

[bimbar]

If the target is ULA, ULA should be used as source.
However if the target is GUA and IPv4, IPv4 will be used.

Meaning, if you use ULA, it will most likely go unused for internet connectivity.

[iam]

That's not what I meant. The question is, if I have GUA and ULA in the DNS of my network (which is unavoidable due to dynamic DNS updates), is ULA preferred over GUA?

[bimbar]

If the target is a ULA, the source selected should also be ULA.
If the target has GUA and ULA, GUA will be selected. If the source only has ULA, then ULA will be used.
However if the target has GUA, IPv4 and ULA, and the source ULA and IPv4, IPv4 will be used.
If the target has GUA and IPv4, and you have ULA and IPv4, I think still IPv4 will be used.

That means, that in usual networks that do dual stack and have ULA configured, the probability is that the ULA will never be used.

If you want to do a deep dive, the relevant RFC is https://datatracker.ietf.org/doc/html/rfc6724 .

[iam]

Thanks for the info. The RFC demands that the preferences must be changeable, but unfortunately the local ULA prefix is not automatically preferred. Windows, Linux and Freebsd already behave differently by default: Linux prefers ULAs over IPv4, Windows and Freebsd do not. With additional GUAs in the DNS, the chaos would unfortunately be complete.

So unfortunately I only see two possibilities:
1) I get my own GUA prefix and use it with NPTv6 if necessary. The advantage would be that more runs via IPv6. However, apart from a good feeling, I haven't gained much from this either.
2) Continue to use ULAs and wait and see. This leaves a lot of traffic on IPv4 for the time being, but IPv6-only destinations can still be reached.

I will stick with the second option for the time being and wait and see. Normally I'm not a fan of this, but in this case I'm really not surprised that after 25 years of IPv6 many sites are still IPv4-only. Many things are still not thought through.

[iam]

https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-update-06.html

[Monstieur]

I use 64:ff9b::/96 instead of a ULA. It's meant for NAT64 so there will be no conflict on the Internet. Most operating systems treat it as a GUA and prefer it over IPv4, unlike a ULA.