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://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
and
https://techhub.hpe.com/eginfolib/networking/docs/switches/5710/5200-4993_l3-ip-svcs_cr/content/517706420.htm
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://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
