[Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements

Simon Kelley simon at thekelleys.org.uk
Mon Oct 6 11:40:44 BST 2014


On 03/10/14 16:54, Neil Jerram wrote:
> Hi all,
> 
> I'd like to propose the attached patches, which extend the aliasing
> concept of the --bridge-interface option to DHCPv6 and Router
> Advertisement processing.  Prior to these patches, the effect of the
> --bridge-interface option is limited to DHCPv4.  I think it's a
> natural extension for it to apply to DHCPv6 and RAs as well.
> 
> I should give a little background about the scenario motivating this.
> As with my previous patch [1, 2], the scenario is that of a compute
> host providing connectivity and DHCP for a number of VMs or
> containers, where the data into and out of the TAP (or veth)
> interfaces to those VMs/containers is routed rather than being
> bridged.  In this scenario, the desire is to provide DHCPv4, DHCPv6
> and Router Advertisements to all the TAP/veth interfaces, from a DHCP/RA
> context specification on some other interface.
> 
> [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008600.html
> [2] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=70772c909199ad6701dc25593bc185938fa4cd23
> 
> I hope that makes sense.  Please can you let me know what you think,
> including whether these patches are suitable for dnsmasq?
> 
> Many thanks,
> 	Neil
> 

A query: the semantics you've provided for DHCPv6 are subtly different
than those that exist for DHCPv4.

In DHCPv4, the alias is absolute, eg

bridge-interface=eth0,tap0

when a packet arrives at tap0, then it is processed as if it arrived at
eth0, any addresses associated with tap0 are ignored.

With this patch, for DHCPv6, dnsmasq first attempts to find a
DHCP-context by using the addresses associated with tap0, and only if
that fails does it use the addresses associated with eth0.

If this is required behaviour, I guess we should document the difference
in the v4 and v6 cases. If it's like that by chance, we should think
about if providing the same behaviour in both cases might be preferable.

Cheers,

Simon.





More information about the Dnsmasq-discuss mailing list