[Dnsmasq-discuss] DHCPv6 doesn't work on Linux interfaces enslaved to a VRF

[Simon Kelley]

On 10/10/2023 11:25, Luci Stanescu wrote:
> Hi Simon,
> 
>> On 10 Oct 2023, at 00:17, Simon Kelley <simon at thekelleys.org.uk> wrote:
>>
>> I've implemented option 1 here and it's currently running and dogfood 
>> on my home network. There are no VRF interfaces there: this is a test 
>> mainly to check that nothing breaks. So far, so good.
>>
>> The patch I used is attached. It would be interesting to see if it 
>> solves the problem for you.
> 
> Many thanks for this! I can confirm that it works as expected with 
> VRF-enslaved interfaces now.

Excellent. I've elaborated the patch slightly so that it logs when doing 
the fixup. If it turns out that there are cases where it's doing that 
inappropriately, the log will make it easier to see what's going on.

The patch is in the git public repo master branch now, so if anyone on 
the lists starts seeing "Working around kernel bug....." messages, 
please reply here ASAP.

> 
>>> 2. Finding authoritative information that the interface index from 
>>> IPV6_PKTINFO is always set to the L3 interface on which a datagram 
>>> was received. The kernel mailing list might be start? I'd certainly 
>>> be happy to help think about and test various scenarios.
>>
>> Please enquire about 2.
> 
> I've tested chains of bond- and bridge-enslaved interfaces (e.g. veth in 
> bond in bridge in bond) and ipi6_ifindex seems to be set to the 
> highest-up master, excluding VRF devices, so that seems promising and 
> should cover the empirical bit. Joining a multicast group on an enslaved 
> interface (if the master isn't a VRF) doesn't seem to work anyway.
> 
> I'll ask on the netdev kernel mailing list and see if I can get any 
> assurances, but I'll have to wait for my DMARC record to expire first.
> 

Thanks for that.


Simon.

> Cheers,
> Luci
> 
> -- 
> Luci Stanescu
> Information Security Consultant