RA relay mode copies all RA flags as-is, regardless of DHCPv6 relay state

[Shine-]

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:

• For DHCP related flags like M and O, relay them as-is only when DHCPv6 is also in relay mode on the given I/F. For any other mode, honor ra_flags.
• For prefix-related flags, specifically A, relay it unconditionally if it's set to 0 at uplink, but honor ra_slaac if it's set to 1 at uplink.

[Shine-]

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.)

[Shine-]

Please find attached an updated patch that fully fixes the issue. The previous patches (up to v3) also had bugs related to more than one downlink interface. Due to having only one downlink interface, this slipped by me multiple times in a row. Sorry for that. If you're already using one of the earlier patches, please replace with this new one. Again, for 19.07 only.

The behavior is changed as follows compared to stock 19.07 (excerpt from the commit description):

The DHCPv6-related M and O flags are relayed as-is if DHCPv6 is also set to relay mode for the given downlink interface. In all other modes, the normal, supposed behavior of OpenWrt 19.07 is restored, ie. honoring the ra_management setting or the DHCPv6 server state, whichever is appropriate.

The prefix-related A flag is relayed as-is, as long as the given downlink interface does allow SLAAC (ie. ra_management set to 0 or 1). Otherwise, (ie. ra_management set to 2) A is cleared, honoring user choice.

Enjoy!

GH#172v4-for-1907-only.zip

[Shine-]

Since 21.02 has been released now, here's a patch for 21.02 as well. It should also be usable against the current Master - at least at the time of this post, there hasn't been a change in the relay code between the odhcpd revision used in 21.02 and Master.

This patch replicates the ra_flags and ra_slaac behavior of odhcpd introduced with the fix for FS#2019, so it works slightly different than the above patch for 19.07:

• only in case both, RA and DHCPv6 are in relay mode, RA flags are passed through as-is
• with RA in relay mode and DHCPv6 in any other mode, only the M and O flags are overwritten according to the downlink i/f's ra_flags setting
• each relayed prefix's A flag is cleared in case the downlink i/f disallows SLAAC (ie. ra_slaac=0), otherwise passed through as-is

GH#172.zip
Edit: Patch works with 22.03 and 23.05 as well.