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

Neil Jerram Neil.Jerram at metaswitch.com
Tue Oct 7 18:28:03 BST 2014


> On 03/10/14 16:54, Neil Jerram wrote:

> > I'd like to propose the attached patches, which extend the aliasing
> > concept of the --bridge-interface option to DHCPv6 and Router
> > Advertisement processing.  [...]
> 
> 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.

Indeed, good catch - I had missed that.

> 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.

It isn’t required behaviour.  At least, for the compute host scenario
that I am interested in, the alias interfaces will never have any IP
addressing or contexts of their own, and also the aliased interface -
i.e. the one that _does_ have the DHCP context - will never receive a
packet directly itself.  Therefore, for my purposes, it would be fine
to align the DHCPv6 behaviour precisely with the v4 behaviour.

Logically I think the same should also apply to solicited RA
processing, i.e. in the ND_ROUTER_SOLICIT block of icmp6_packet.
Would you agree?

Finally, I guess I should also update the "One form of bridging ..."
comment in dhcp_packet, and the man page text on --bridge-interfaces,
to mention my scenario in addition to the BSD one.

If that all sounds good to you, I'm happy to work on updating the
patches - please let me know what you think.

Regards,
        Neil




More information about the Dnsmasq-discuss mailing list