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@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@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. On a completely different note, do you have an idea on when 2.87 will be released ? Cheers, Luis -- Luis Thomas _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
