Consider the following configuration:
- eth0 is non-static WAN, eth1 is LAN
- 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
- LAN can be restricted to a /64 (let's say DEAD:BEEF:F00::/64)
- (assumption) Local-Link addresses are fine
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).
: 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
: LAN is dual-stack. This (and all sides) is omitted since it
(should) have no bearing on the scenario.
Dnsmasq-discuss mailing list