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

[Neil Jerram]

I'm sorry, this is a really old thread that I'm only just now getting 
back to.

As a reminder, it's a set of patches that extend the semantics of 
--bridge-interface to DHCPv6 and router advertisements.  Our last 
exchange (as below) was about fixing a subtle difference in behaviour 
between the v4 and v6 cases, and this email provides the revised patch 
set that addresses that point, and also:

- is rebased to current master
- improves the documentation around --bridge-interface, specifically so 
that it doesn't appear to be for BSD platforms only.

My team has been running with this for a while - albeit on a base of 
2.72 - so we have some confidence that the patches are correct.

Please would you consider merging these patches into upstream dnsmasq?

Many thanks,
	Neil



On 13/10/14 17:45, Simon Kelley wrote:
> On 07/10/14 18:28, Neil Jerram wrote:
>>> 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?
>
> Yes, certainly.
>
>>
>> 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.
>
> Yes, that's well out-of-date.
>>
>> If that all sounds good to you, I'm happy to work on updating the
>> patches - please let me know what you think.
>
> Please do. Happy to have this.
>
>
> Cheers,
>
> Simon.
>
>>
>> Regards,
>>          Neil
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implement-aliasing-idea-per-bridge-interfaces-for-DH.patch
Type: text/x-patch
Size: 2036 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150608/17ce7c00/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Allow-configuration-of-on-link-L-bit-in-Router-Adver.patch
Type: text/x-patch
Size: 3228 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150608/17ce7c00/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Implement-aliasing-idea-per-bridge-interfaces-for-so.patch
Type: text/x-patch
Size: 4169 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150608/17ce7c00/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Implement-aliasing-for-unsolicited-router-advertisem.patch
Type: text/x-patch
Size: 5103 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150608/17ce7c00/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Documentation-for-IPv6-enhancements.patch
Type: text/x-patch
Size: 8528 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150608/17ce7c00/attachment-0009.bin>