artturnip:

My apologies for the poor formatting and typos in this:

The last paragraph should read:

Therefore the M flag should be able to be set whilst the internal DHCPv6 server is enabled disabled.

dedeckeh:

This behavior is in place since an issue was logged no M/O flags must be set if the DHCPv6 server is not enabled; see https://bugs.openwrt.org/index.php?do=details&task_id=1457

artturnip:

Surely that previous example is just a misconfiguration? The user has deliberately told odhcpd to advertise DHCPv6 as available by setting
option ra_management '1'
Which is documented as setting the M flag in an RA. Then they have disabled the DHCPv6 server explicitly in the configuration too. If the user disables the OpenWrt DHCPv6 server and then also enables the M flag, the behaviour that the router advises that DHCPv6 is available but the server is disabled is exactly what they have asked for...

Note that this is exactly the functionality I am trying to replicate!

artturnip:

If the user did not want DHCPv6 to be advertised by the router then they should have set
option ra_management '0'
Which would only set the A flag and as such not indicate the presence of a DHCPv6 server on the network!

dedeckeh:

Experience has learned me very few devices respect the M/O flags in the RAs and still start DHCPv6 even if the M/O flags are not set. So using the M/O flags to disable DHCPv6 is not an option in the real world

artturnip:

Even so, should we not try to adhere to IETF standards wherever possible? The intent behind the O and M flags is to indicate to the client that a DHCPv6 server is available //somewhere// on the network -- it need not be on the router. A misconfiguration reported as an issue should not lead OpenWrt to disregard the IETF standards.

Even if other devices don't adhere to the standards, this should not be a reason as to why we should not.