On Thu, 2022-09-08 at 12:47 +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 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@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. > > They're there now.
Perfect and we've tested them, they are working as expected, thank you Simon. Luis > > > > > 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 > > > > _______________________________________________ > 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!QbtK3zxqBCxruq2xA8PTg4QA3LYeiK-g1_FPBkajDEJzTRRADQX_WuYzRDdQxvzk7wYmjyF4ndzrZOOQsddZUQ$ _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
