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

[Simon Kelley]

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 at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss