[Dnsmasq-discuss] ipv6 dhcp-range constructed from different interface

[Chloe Kudryavtsev]

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:

/etc/network/interfaces:
----
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):
----
listen=eth1
enable-ra
dhcp-authoritative
dhcp-range=::100,::400,constructor:eth0
# 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.