One stateful static IPv6 /64-subnet and one stateless random IPv6 /64-subnet on LAN device?

Hi,

we have a manually assigned static /48 IPv6 prefix and for privacy reasons we need one stateful static /64 IPv6 subnet for incoming connections and one stateless random /64 IPv6 subnet for outgoing connections on the LAN device.

1st IPv6 prefix (incoming connections):

  • Static /64
  • DHCPv6 leases: :0:192:168:1:<last octet of IPv4 address>
  • Preferred lifetime: 0
  • Valid lifetime: forever

2nd IPv6 prefix: (outgoing connections)

  • Random /64
  • New subnet every 86400 seconds
  • Stateless
  • Preferred lifetime: 86700
  • Valid lifetime: 172800

How can we configure this in OpenWRT?

Thanx for any hint :slight_smile:

It's easy to assign a static prefix to a LAN in LuCI, but it's less easy to get DHCP to assign particular addresses to particular machines. Better to have each machine get whatever it gets and use DNS to map it to a meaningful name.

as for a second prefix, I think you'll have to set that up manually using the "ip-full" package. Assign an additional ip address with the given lifetimes to the br-lan bridge, and dnsmasq will start router-advertising it right away. After a certain time, use cron to assign a new random prefix, deprecate the old address, and once it expires remove it.

How can I get the hostnames and IP addresses into BIND nameserver?

http://www.zytrax.com/books/dns/ch8/aaaa.html

It sounds like you can statically assign the IP addresses on the servers, and then just plop them into the BIND database once and for all, rather than dealing with DHCPv6 in any way.

@trendy
I know BIND configuration files. The question is how to interface DNSMasq on OpenWRT with BIND.

@dlakelan
For a few servers it makes sense to configure the IPv6 addresses statically on the host. We'll have to deal with (temporary) clients.

My idea was to use the DNSMasq dhcp-script-hook and create a DynDNS update-script with nsupdate in /etc/hotplug.d/dhcp.

You need to deal with temporary devices that come onto your network and need to serve incoming connections? Because SLAAC or DHCPv6 without any DNS mapping is perfectly fine for client machines that just need outgoing connections, but it's kind of unusual to need a random temporary device to suddenly be able to act as a server with a proper DNS name.

1 Like

What name are you going to use? The random hostid they will advertise upon connecting? And what good will it be?
Too much fuss to create NS records for temporary clients (2nd group)

You might find kea a better option for DHCP service in a complex application than the defaults of OpenWrt. It should be available as a package, though likely requires “normal” config through hand-edited files. It will run without an external database for small-scale operation (likely the case if you’re not using enterprise-grade gear).

@dlakelan
The clients need to be reachable for e.g. client-to-client VPN-connections.

@trendy
The second group doesn't need NS records, only the first one. Every host in LAN should get an IPv6 address from the 1st and 2nd group.

@jeff
I didn't know there are KEA packages for OpenWRT and considered ISC DHCPd. Where can I find the KEA packages for OpenWRT?

OpenWRT will also act as hidden primary nameserver. I have no problem using a hand-edited BIND/KEA combo as long as firewall settings can be done in LUCI (opening closing ports, port forwarding, ...).
Do I need Dnsmasq for listing hosts in LUCI (especially firewall configuration)?

I am not sure how this is connected to incoming connections.

You are not explaining properly what you want to achieve, therefore you are not getting the correct answers.
For a server it's best to use the static IP option. If you want to use DHCPv6, it gets more troublesome especially with DUID in the equation.

The default config should work fine more or less for you. It will bind the names to IP addresses and the default NS advertised is the router itself, hence the hosts will be able to resolve internally. For external addresses you can configure dnsmasq to forward to your BIND.
And I don't think that you can use hostnames in firewall configuration of Luci, unless you configure IPsets.

  1. Location 1: (home router)
    1.1. Dual-Stack with dynamic IPv4 address and dynamic IPv6 prefix
    1.2. Host addresses assigned via DHCPv4/DHCPv6-PD and ULA
    1.3. Debian server as Wireguard gateway

  2. Road-Warriors
    2.1. Wireguard clients

  3. Location 2: (OpenWRT)
    3.1. Public static IP addresses: /29 IPv4 and /48 IPv6
    3.2. Bridges on OpenWRT
    3.2.1. br-dmz (servers)
    3.2.1.1. /29 IPv4 subnet
    3.2.1.2. /64 IPv6 subnet
    3.2.2. br-lan (LAN)
    3.2.2.1. Static /64 IPv6 subnet
    3.2.2.1.1. Incoming connections to hosts with AAAA records in <mydomain.tld>
    3.2.2.2. Dynamic random /64 IPv6 subnet out of /48 subnet
    3.2.2.2.1 no AAAA records
    3.2.2.3. Private IPv4 subnet (192.168.1.1/24)
    3.3 Hidden primary nameserver for <mydomain.tld>
    3.3.1 BIND
    3.3.2 DNSSEC + DANE
    3.4 Wireguard gateway

All road-warriors and locations have to connect with each other via Wireguard (IPv6 with IPv4 fallback for Road-Warriors) and route IPv4 and IPv6 between all road-warriors and all hosts. Public servers are in DMZ (web, mail, etc.).

In WG configuration you specify the IP addresses that you will use, so this is solved I presume.
Also routing among between the sites can be configured with static routes.

There is the random option for ip6ifaceid in interface configuration. Regarding the timers I am not sure, but you could have a look at the documentation.

Other than that I don't see anything extraordinary in your desires that cannot be accomplished.

In my understanding ip6ifaceid random creates a random host identifier, not a random sub-prefix?

True, you could assign a network subprefix with ip6hint, but not randomly. However with some scripting you could randomly change that in a cronjob.

What's the actual goal of randomly reassigning prefixes? Why do that? You've said because of privacy but what additional privacy do you think this gives you, as I can see no way in which this really enhances privacy.

2 Likes