[Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
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
> 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.
More information about the Dnsmasq-discuss