[Dnsmasq-discuss] [PATCH] fix the source address of dhcpv6 relay-forward packets

[Simon Kelley]

On 07/09/2022 10:10, Luis Thomas wrote:
> On Tue, 2022-09-06 at 13:24 +0100, Simon Kelley wrote:
>>> CAUTION: This email originated from outside of the organization. Do
>>>> not click links or open attachments unless you recognize the
>>> sender > and know the content is safe.
>>>
>>>
>>> On 02/09/2022 14:03, Luis Thomas wrote:
>>>>> Hi everyone,
>>>>>
>>>>> We are using both dnsmasq and isc dhcrelay as dhcp-relays for >
>>>>>> dhcpv6
>>>>> only.
>>>>>
>>>>> we launch dnsmasq like this:
>>>>>
>>>>>        dnsmasq -d \
>>>>>        --conf-file=/dev/null \
>>>>>        --dhcp-relay fd12:3456::b6e3:f9ff:fea5:fa5b,2020:abcd::1
>>>>> \
>>>>>        --except-interface=lo \
>>>>>        --interface=tun0,eno2 \
>>>>>        --port 0
>>>>>
>>>>> and isc dhcrelay like this:
>>>>>
>>>>>        dhcrelay -d -6 -l tun0 -u 2020:abcd::1%eno2 --no-pid
>>>>>
>>>>> tun0 address is fd12:3456::b6e3:f9ff:fea5:fa5b.
>>>>> eno2 address is 2020:abcd::2.
>>>>>
>>>>> With dnsmasq the source address of the relay-forward packets is
>>>>> the
>>>>> address of tun0.
>>>>> With dhcrelay the source address of the relay-forward packets
>>>>> is > > the
>>>>> address of eno2.
>>>>>
>>>>> We don't really understand why it so on dnsmasq (or dhcrelay
>>>>> for > > that
>>>>> matter), could someone explain it to us ? RFC 3315 section 20.
>>>>>>> Relay
>>>>> Agent Behavior says nothing about the source address.
>>>>>
>>>>> In our use case it makes more sense that the source address of
>>>>> the
>>>>> relay-forward packet is the address of eno2 since it's the
>>>>> outbound
>>>>> interface (and the one that will receive the replies).
>>>>>
>>>>> Nevertheless the attached patch fixes this issue as it sets the
>>>>>>> source
>>>>> address of relay-forward packets to be the address of the
>>>>> "upper"
>>>>> interface.
>>>>>
>>>>> We've also attached two filtered pcap files of a wireshark
>>>>> capture
>>>>> showing the difference before and after the patch on the
>>>>> machine
>>>>> hosting the dhcp server and the machine hosting the dhcp_relay.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>
>>> Hmm,
>>>
>>> Looking at the code, I obviously intended the current behaviour: >
>>> there's
>>> a comment to that effect /* source address == relay address */ and
>>>> the
>>> code goes to the effort of setting up the source address and
>>> calling
>>> send_from() which supplies that to the kernel.
>>>
>>> The question, therefore, is why? I think this probably a carry-over
>>>> from
>>> DHCPv4, where the "giaddr" field is overloaded to specify the
>>> subnet > on
>>> which the client resides, and the global address of the relay. It's
>>>> also
>>> the case that a configured V4 client communicates directly with the
>>> server, bypassing the relay , so the server has to have a route to
>>>> the
>>> client-side subnet of the relay in all cases.
>>>
>>> DHCPv6 is not the same: the relay is always involved in client-
>>> server
>>> communication; it's actually a proxy, not a relay, so the need for
>>>> the
>>> server to have a route to the client-side is no longer there and it
>>> makes more sense for the server to use the server-side address to >
>>> return
>>> messages to the client.
>>>
>>> You're right that RFC3315 is silent on this, and so is RFC8415, as
>>>> far
>>> as I can see. Googling did find
>>> https://urldefense.com/v3/__https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-8/configuration_guide/sec/b_168_sec_9500_cg/b_168_sec_9500_cg_chapter_0101000.pdf__;!!N30Cs7Jr!Q421ImOmP1QY1W0cGWn4UubtRyenNYwk6XaKoLPqef5zUZZiyFVzXHQzLE8-W4aNa410kA0i5iyv98b0mTv_hA$
>>> and
>>> https://urldefense.com/v3/__https://techhub.hpe.com/eginfolib/networking/docs/switches/5710/5200-4993_l3-ip-svcs_cr/content/517706420.htm__;!!N30Cs7Jr!Q421ImOmP1QY1W0cGWn4UubtRyenNYwk6XaKoLPqef5zUZZiyFVzXHQzLE8-W4aNa410kA0i5iyv98YVw3DtJQ$
>>> both of which state that the default is the server-side interface
>>> address. Of course, the behaviour of ISC code is a strong push in
>>> the
>>> same direction.
>>>
>>>
>>> TLDR; I think the behaviour change you want is correct. I
>>> understand > why
>>> the patch you submitted went for minimal-change, but I'd like to go
>>>> for
>>> maximum-simplification instead, removing the calculation of the >
>>> address
>>> on "from" and the call to send_from(). I will push that in the next
>>>> day
>>> or two.
>>>
>>>
>>> Cheers.
>>>
>>> Simon.
>>>
>>>
>>>>> _______________________________________________
>>>>> Dnsmasq-discuss mailing list
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>>> https://urldefense.com/v3/__https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss__;!!N30Cs7Jr!Q421ImOmP1QY1W0cGWn4UubtRyenNYwk6XaKoLPqef5zUZZiyFVzXHQzLE8-W4aNa410kA0i5iyv98aWSitojA$
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> https://urldefense.com/v3/__https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss__;!!N30Cs7Jr!Q421ImOmP1QY1W0cGWn4UubtRyenNYwk6XaKoLPqef5zUZZiyFVzXHQzLE8-W4aNa410kA0i5iyv98aWSitojA$
> 
> 
> Hi Simon,
> 
> Thank you for your explanations, we'll gladly test your changes once
> they're pushed.

They're there now.

> 
> On a completely different note, do you have an idea on when 2.87 will
> be released ?

I just started the release-candidate process, so pretty soon.


Simon.

> 
> Cheers,
> 
> Luis
>