[Dnsmasq-discuss] Additional feature requested for stateful DHCHv6 together with a 6RD-tunnel to the ISP

[Simon Kelley]

On 10/01/13 23:41, Joakim Langlet wrote:
> I have configured a Raspberry Pi as a dual-stack (IPv4/IPv6) internet
> router. dnsmasq plays an important role in the configuration and it
> works great. All computers have dual stack access (including Andriod
> phones over WLAN!).
> 
> There is just one thing that I don't know how to solve in a good, neat
> way.
> 
> Since I am using a 6RD-tunnel the ISP (Telia), the IPv6 address
> delegation will change when the IPv4 address changes as a result of
> expired DHCP lease from the ISP (it will not change often but it will
> happen...).
> 
> In 6RD, the ISP 6RD-prefix is concatenated with the ISP-customers IPv4
> adress resulting in a address chunk available to the customer (typically
> 64-bits).
> 
> The "dnsmasq.conf" file allows me to specify a range of IPv6-addresses
> which are used for stateful DHCPv6. This works great!
> 
> However, if the IPv4 address (public) changes, I would have to edit the
> range (manually or by script) and restart dnsmasq. This is of course a
> working solution. But I don't really fancy the idea of stopping a
> service, editing the config file and starting again while the clients
> are requesting service from the router... maybe I am missing something
> here.
> 
> Proposal:
> 
> I think it would be great if the 6RD-prefix could be read from a file by
> dnsmasq (and using 'inotify' so that updates are tracked).
> 
> The syntax in the dnsmasq.conf file would need a "symbol" for the
> PREFIX. I took $(6RD) as an example below:
> 
> :
> :
> #                                                                                                  
> dhcp-range=$(6RD):1000::a, $(6RD):1000::100, 96, 10m
> enable-ra
> dhcp-host=id:00:01:00:01:15:c8:32:d6:f0:4d:a2:c7:b9:cc, laptop1,
> [$(6RD):1000::4]
> :
> :
> 
> The value read from the prefix file would then be concatenated the
> values from the .conf-file (on the fly).
>  
> This would totally solve the update needs associated with the dynamic
> nature of 6RD-type IPv6 addresses.
> 
> BTW: I am also trying to convince Telia to add option 212 to their DHCP
> servers. The requested dnsmasq feature above and the option 212 would
> make the use of 6RD-tunnels automagic.
> 
> Please, let me know what you think about this idea.
> 

This problem has been noticed before, and I've been working with the
OpenWRT people on a different solution available in the current 2.66test
series of releases.

It works like this: instead if specifying complete IPv6 addresses in a
DHCP range, the start and end addresses are just the host-identifier
part. There's an additional keyword which specifies an interface name.
An example makes this clearer.

dhcp-range=::1,::400,constructor:eth0,.......

This tells dnsmasq to watch eth0 for addresses with host-identifier part
::1, and when it sees one, to create a dhcp-range using the prefix from
that address.

So, in your case, when the DHCPv4 address is assigned, the machinery
attached to the the DHCPv4 client creates the 6RD prefix (say,
2001:db8:c000:0264) and adds the address
2001:db8:c000:0264::1 to eth0. Dnsmasq notices this automatically, and
creates a live dhcp-range=2001:db8:c000:0264::1,2001:db8:c000:0264::400

The system will cope with multiple addresses, also old addresses
disappearing and it uses the preferred lifetime of the address in the
interface to deprecate addresses before they disappear. This all works
for both stateful DHCPv6 and router-advertisements, and even the
ra-names RA naming mode. (It's quite fun to add a new address to the
interface and see a new IPv6 address instantly appear in the DNS for
existing hosts.)


I'm happy to hear comments on my solution, and argue about which of
these methods is better: I think the interface-watching system is easier
and neater to configure, but it's less flexible than the
macro-replacement method and specifically doesn't handle dhcp-host. I
confess I hadn't considered the need to do that, but I can see it would
be useful. Something similar could be incorporated into the
interface-watching system. The exact semantics are tricky: what happens
to existing leases when a dhcp-host which depends on a 6RD prefix
disappears?

You can try the new code in 2.66test. The last few releases have
unrelated  show-stopping bugs, so it's probably best to try 2.66test5
until we get those ironed out.

Cheers,

Simon.