Shine-
commented
2 years ago Please find attached a patch that fixes the issue partially and only for 19.07.
Partially, because only M and O flags are my use case, so I'm touching M and O only. For 19.07 only, because the box affected, in my case, is currently running 19.07 (and being 4/32, likely for the rest of its remaining life).
I'll leave a proper patch for master to the maintainers :-)
Knowing that an eventual fix will likely never find its way into official 19.07, the attached patch might still be useful for some :-)
Have fun!
(Patch removed. Please see next post.)
Problem description:
odhcpd in RA relay mode always copies RA flags (e.g. M, O, A) to downlink as-is. It doesn't take into account that these flags relate to DHCPv6, not RA and should therefore be set according to downlink DHCPv6 configuration.
Note: tested in OpenWRT 19.07.x (with old ra_management syntax, same behavior), 21.02.0rc2, 21.02.0rc3 and several snapshots past 21.02.0rc3.
Current behavior, example 1:
Uplink provides RA with SLAAC only, but no DHCP service. Therefore, uplink's RA has M=0, O=0 and A=1 for the given prefix. Downlink is able to assign addresses via SLAAC from the uplink prefix, thanks to odhcp's RA relay mode. Downlink does have an own DHCPv6 service running, e.g. in order to assign DNS servers and/or ULA. However, since odhcpd copies M=0 and O=0 to downlink, any clients connected to downlink ignore the locally available DHCPv6 service, and won't get either DNS servers or ULA. This is not hypothetical, I'm facing exactly this issue! Note that clients sometimes receive their DHCPv6 info just fine, but drop it again shortly afterwards - depending on what comes first, the DHCP reply or the RA. Can be nicely viewed in Wireshark.
Current behavior, example 2:
Uplink provides both, SLAAC and DHCP. Therefore, uplink's RA has M=1, O=1 and A=1 for the given prefix. Downlink prefers SLAAC-only and chooses not to relay DHCPv6 from uplink, nor to run DHCPv6 locally. However, due to M=1 and O=1 being copied as-is from uplink to downlink, downlink's clients keep firing DHCPv6 requests and would gladly receive addresses/other configuration from any rogue DHCPv6 server -> security problem!
Expected behavior:
My first thought was, the downlink DHCPv6 state (disabled/server/relay) should be used to decide whether to copy, clear or set the M/O flags. However, that would lock-in the user to odhcpd as DHCPv6 service, with no option of using an external DHCPv6 server.
Better: At least in regards to M and O, odhcpd shouldn't simply copy the flags. Instead, it should either honor the ra_flags setting always, or there should be an override option that allows honoring ra_flags at the user's choice.Not sure what should happen with A, though. If uplink doesn't allow SLAAC, then downlink mustn't allow it either, so A=0 should always be relayed as-is, I guess. But with A=1 uplink, downlink should perhaps honor the ra_slaac setting?After some more thought and sleep, I guess the correct behavior would be: