ip6tables: how to handle periodically changing prefix?

My ISP provides me with native IPv6 (unfortunately DS-Lite for v4) and I'm using SLAAC for the clients in my local network behind a broadband router.

As I don't trust the router (which is configured by my ISP over TR-691) I have set up ip6tables rules on every client, e.g. limiting SSH access to stations in the same subnet:

$ ip6tables -A services -s 2a02:8071:28c2:5400::/64 -p tcp --dport 22 -j ACCEPT

The problem now is that the prefix changes periodically, approx. once a month.

Is there an ip6tables statement that dynamically matches the current prefix(es) of a given interface?

Or how would you handle the changing prefix? I thought of writing an init script that first determines the current prefix through Router-Solicitation an then generates the appropreate ip6tables rules. But this sounds dirty somehow...

In theory, the right way to handle this is with DHCP Prefix Delegation and dynamic DNS.

So, it would work like this:

1) your router linux instance requests an IPv6 address as well as an IPv6 prefix delegation from the ISP on interface A

2) it assigns one /64 from the delegated prefix to interface B, which has all the other machines. It advertises this prefix via RA packets and/or via the DHCP server daemon of your choice

3) clients grab IPv6 addresses and register themselves in local DNS by hostname, or respond to mDNS requests for that name if they're running bonjour, Avahi, etc.

4) firewall rules and pretty much any other network-related configuration is based on host names, not IP addresses. This is the IPv6 way: DNS names good, literal addresses bad because they are hard to remember and type.

The major problem you'll find is that iptables and ip6tables only support hostname-based rules by resolving hostnames once during rule installation. So you'll probably have to write some script to re-install rules whenever the prefix changes. Worse, if a host is offline or not resolvable by mDNS or DDNS at rule install time, things will break silently.

In short, ip(6)tables is just plain broken for any case where IP addresses change, even on IPv4. This means it is broken for any network of reasonable size, at least on a system acting as a router.

Lots of commercial firewall products handle this use case much better (even though many are linux based, such as SonicWall). I suspect they simply re-resolve FQDNs periodically based on TTL and update IPtables or their custom networking kernel modules.