> 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 _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss