Should a stub router learn RA header parameters from other routers?

[superwhd]

Say that here's a WiFi network.

• The WiFi AP is a DHCPv6 server advertising RAs with 'M' flag set to 1 in the header.
• There's a Thread Border Router (a stub router) in the WiFi network using the WiFi as the AIL.

Question: Should the stub router learn the RA headers from the WiFi AP and set the 'M' flag to 1 in its own RA header? If so, are there any other header parameters that it should learn from the WiFi AP's RA?

I wonder if it will cause any problems if the stub router just send RAs with 'M' and 'O' flags set to 0. In RFC4861 it says:

        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.

This makes the RA (M=0, O=0) sent by the stub router contradicts with the RA (M=1,O=0) sent by WiFi AP.

In RFC4861 it talked about how a host should handle RAs from different sources.

   When multiple routers are present, the information advertised
   collectively by all routers may be a superset of the information
   contained in a single Router Advertisement.  Moreover, information
   may also be obtained through other dynamic means like DHCPv6.  Hosts
   accept the union of all received information; the receipt of a Router
   Advertisement MUST NOT invalidate all information received in a
   previous advertisement or from another source.  However, when
   received information for a specific parameter (e.g., Link MTU) or
   option (e.g., Lifetime on a specific Prefix) differs from information
   received earlier, and the parameter/option can only have one value,
   the most recently received information is considered authoritative.

However, it's not very clear to me how the host should handle the M flag from different sources:

1. Use the union of the M flags. That probably means the host thinks there's a DHCPv6 server on the Wi-FI network. or
2. Respect the M flag from the most recently received RA header.

[superwhd]

Closing this GitHub issue. The discussion will be in the WG mailing list.

[EskoDijk]

@superwhd You could reopen this issue; it's always good to keep an issue open for an ongoing discussion. We also do this for other (non-trivial) issues. It can be closed as soon as the discussion is done.

[EskoDijk]

Discussion was held at IETF 118; notes are under item 5. in the notes document here: https://notes.ietf.org/R-tkJFdYSCCWqeBDXMReLQ?view

So the consensus is that the last advertised RA flags M/O are specified as the "valid" / "true" values that a host should use. Therefore these bit flags would need to be copied from the last RA seen that was sent by a non-stub-router.

For any other RA header parameters, the stub router should use a value of zero (0) meaning "unspecified by this router". That's also needed to resolve issue #36 .

Note that the "last seen" non-stub-router needs to be monitored as described in the SNAC-simple state machine section to verify that it is still reachable. If not reachable anymore, the copied M/O flags from this router also stop being used. In such case the stub router needs to revert back to the default M/O values 0/0 until (maybe later on) a new non-stub-router appears again.

[EskoDijk]

Making a PR for this issue: now self-assigned to @EskoDijk