Static IPv6 internally while using ISP PD assigned range externally

[thedaveCA]

My ISP only offers a IPv6 prefix and no IPv6 address for the WAN interface itself, but I've been able to get up and running using "Track Interface" with "Request only an IPv6 prefix" enabled on the WAN. Great.

Unfortunately I switched ISPs and my new ISP's PD range changes pretty regularly which causes various issues inside my network every time it happens.

It looks like NPTv6 to statically assigned IPs would be my solution, but it doesn't look like it can pull a /64 from a PD range. With a previous ISP I was able to get an IPv6 on the WAN and could at least use NAT to make the IPv6 internet reachable (yeah yeah, I wasn't happy with it either, but some access was better than no access), but with only PD I think I'm stuck.

There is an open feature request to support PD for NPTv6, which will be great when it happens, but I'm wondering if anyone has discovered any other tricks/hacks around this in the meantime?

[meyergru]

You do not need NAT with IPv6 and you should not. For internal connections, you probably can use IPv4.

For outgoing IPv6 connections, IPv6 with "track interface" and short-lived RA on your LAN should be fine. After all, any IPv6 interface can have several addresses so a prefix change is no problem.

The problem arises only when you want to let IPv6 connections in. First off, if these are HTTP(S) connections, you could use HAproxy - there is a nice tutorial on the site. You can address the internal devices via IPv4.

Second, there is a firewall alias type of "Dynamic IPv6 Host" which combines an interface prefix with the EUI-64 of your internal devices, so you can specify firewall rules without knowing their "fixed" IPv6. Even if they use IPv6 privacy extensions for outbound traffic, they will respond to their management IPv6.

All that is left is to use a DynDNS provider like "https://dynv6.com/" who can also combine the IPv6 prefix from the incoming request with a configurable EUI-64 plus LAN prefix bits. This way, OpnSense can do DynDNS updates. For that to work, you have to set your OpnSense WAN to request IPv6 prefixes only. If it has its own IPv6 from a different range than the LAN prefixes, DynDNS will obviously not work.

This was all discussed in german here.

[thedaveCA]

The initial problem I'm running into internally is the various "things" that notice they have an IPv6 address and remember/register/cache it somewhere, and then that address becomes invalid.

A simple example is every Windows machine registers its IP addresses with Active Directory's DNS, which itself must then replicate changes across AD, plus DNS TTLs. NoMachine (remote control for macOS machines) is similar, each client discovers IPs (great!) and then caches them (less great). A few mobile apps that do their own discovery and then stick with the answer for a while, and at least one IoT product needs a hardware reboot to recover. Oh and one IoT device I had actually rebooted itself whenever it couldn't renew an existing IPv4 or IPv6 IP (it seems to only know how to get a new IP on bootup). Ugh.

Down the road I'd like to be able to use IPv6 on my site-to-site and road-warrior VPN configurations and get away from the mess of NAT, port mappings, and other tweaks to get things talking to each other. Going IPv6-first/only internally with IPv4being relegated to external connectivity just seems like a dream.

My current situation is a mess of my own making, I fully admit, but having stable IPv6 numbering (even if only internally) greatly simplifies this process.

If I'm stuck with internal IPs changing randomly forever then a combination of Dynamic IPv6 Host and/or dynv6.com look like partial solutions. I already started down the road of a script to hit my DNS provider's API and swap prefix-X for prefix-Y, if dynv6.com is stable then it might be just the thing. Thanks!

As much as I'd love to see NAT go away completely, I don't see it happening even if we all got together and threw out IPv4 tomorrow. NPTv6 is a literal purpose-made solution that removes so much of the NAT related issues (the big one being internal ports match external ports across the board) without requiring permanent IP space. I just wish I could use it.

[bimbar]

You should use IPv4 internally if you have a dynamic IPv6 prefix.

[meyergru]

Exactly. As I wrote: "For internal connections, you probably can use IPv4."

You can avoid these problems by not enabling DHCPv6 internally, just "unmanaged" RA, like described here. Thereby, you do not poison your internal DNS.

Also, you should configure RA to use a minimum/maximum interval of 200/600.

I do not know NoMachine, but I bet you can disable IPv6 there.

[thedaveCA]

You can avoid these problems by not enabling DHCPv6 internally, just "unmanaged" RA, like described here. Thereby, you do not poison your internal DNS.

That does not change the fact that machines still discover and use their IPv6 addresses internally. Clients register to Active Directory, and client-initiated discovery happens automatically. It doesn't matter how the IPs are assigned, only that they change resulting in intermittent connectivity.

Being able to point external requests to a specific IPv6 IP will be great, but I'm not there yet. Right now I'm at this point that if I run IPv6 internally and for all the traffic through NAT everything works, or if I use statically assigned ranges everything works. But as soon as I switch to ISP assigned dynamic addresses things break and that's all my ISP can manage to come up with at the moment.

The fix is not to email every app developer and ask for a "hey, could you rewrite your discovery mechanism to not use half my network even though it looks like it should work?", the fix is to use stable IPs, which leads me back to NPTv6, except that it doesn't seem to work either with PD assigned addresses.

[zan]

Ok I'm sharing my findings, but this probably only work for my ISP.

Like yours, my ISP only gives a /64 dynamic prefix 2222:3333:4444:xxxx via DHCPv6, with xxxx being randomized each renewal time.

So I found a trick to make a PD reservation:

Locate the PD request line in /var/etc/dhcp6c.conf. in my case:

Code Select Expand

prefix ::/64 infinity

Picked a number of my likings (yyyy) as the 64 part of the prefix, changed it into:

Code Select Expand

prefix 2222:3333:4444:yyyy::/64 infinity
Overrode the DHCPv6 client config of my WAN and pointed it to my edited config (Config File Override tab).

It works and my ISP always grants me 2222:3333:4444:yyyy PD ever since, basically turned it a pseudo static PD.

Worth to try but YMMV.