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$
