Consider the following configuration:
- eth0 is non-static WAN[1], eth1 is LAN[2]
- DHCP6 clients should be assigned public ipv6 addresses
- public ipv6 prefix is DEAD:BEEF:F00::/48
- Gateway should only have a single public ipv6 address (let's say DEAD:BEEF:F00::1/48)
- LAN can be restricted to a /64 (let's say DEAD:BEEF:F00::/64)
- (assumption) Local-Link addresses are fine[2]

In such a scenario, I would expect the following configuration to work:

auto eth0 eth1
iface eth0 inet6 manual # eth0 does dhcp6/slaac/whatever through ra
    pre-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
iface eth1 inet6 manual # eth1 only needs link-local, no upstream here
    pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra

dnsmasq conf (simplified):
# other options for ntp, dns, etc

After all, the prefix is only available on eth0's interface, but eth1 is what's meant to serve its addresses.

However, this does not work, after several RTR-SOLICIT(eth1), dnsmasq logs "no address range available for DHCPv6 request via eth1".

The only way I have managed to get the above scenario working is by assigning a static ip to eth1 in the address range defined in the dhcp-range and setting the constructor to eth1 - suddenly the gateway has two public IPs.

The ironic part is that the clients continue to use the link-local address as the gateway - the IP is not even used.

Is this me being a massive PBCAK, intentional behavior, or a bug?
From what I can tell, there is no reason for dnsmasq to act like this (in the context of ipv6), and there are some massive disadvantages (e.g setting a static ip for eth1 means the whole setup will break whenever eth0's ip changes - something that may be rare, but is definitely possible).

Please advise.

[1]: This is a slight simplification - my ISP does not currently provide native ipv6, so eth0 is actually sit0 (6to4) in all of these examples. This does mean that I have to enter the address manually into sit0 (as automatic ipv4-6to4 conversion is not done) and thus could change eth1's static ip at the same time, I'd rather not repeat myself (DRY is burned deep into my mind). Further, once native ipv6 *is* here for me, the problem will go back to the above state, with no obvious solutions (e.g it may be possible to use ifupdown hooks that inspect the situation and custom ordered ifupdown callers, but this seems like severe overkill for what should be quite simple). [2]: LAN is dual-stack. This (and all sides) is omitted since it (should) have no bearing on the scenario.

Dnsmasq-discuss mailing list

Reply via email to