Correct locations of flags in RA/PIO and add M/O flag copy requirement

[EskoDijk]

• close #32
• also corrected ULA -> ULA prefix ('A' stands for address so can't be a prefix itself)

[EskoDijk]

We discussed in the call that STALE_RA_TIME = 10 minutes may be too low as a limit for considering the most recent RA with M/O flags as "not applicable anymore". An alternative could be to use the "Router Lifetime" in the RA header, which indicates the lifetime of the router in its role as a default-router. This has a maximum value at 18.2 hours. However, there can be cases where a router is sending RA (with M and O flag values) and the Router Lifetime has a value 0 (indicating it's not a default router). So this solution can't work in general.

Another solution that was discussed is using the valid or preferred lifetime from the PIO option, which has a disadvantage that it can be set very large (e.g. some implementations may use 1 month, or even infinity) and also the disadvantage that a PIO may not even be present in the RA which has the M/O flags set.

Something like 30 minutes may be appropriate e.g. 3 * STALE_RA_TIME. This fits roughly with the proposals made in https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum#section-4 : it defines ND_DEFAULT_PREFERRED_LIFETIME which can be 30 minutes (using defaults from RFC 4861), or 45-90 minutes (using BCP202 ) to put a "cap" on overly long advertised lifetimes.

[Abhayakara]

BTW, the document I was referring to is this one: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-07.html

It looks like it's expired—not sure what happened.

[jwhui]

RFC 4861 specifies:

      MaxRtrAdvInterval
                     The maximum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 4
                     seconds and no greater than 1800 seconds.

So I don't think it can be less than 1800 seconds for timing out the received M/O state. Unless we consider sending a Router Solicitation to trigger RA transmissions.

[Abhayakara]

Oh, that's a good observation, Jonathan. Let's use that number. :)

(That's the number I wanted anyway—I just didn't have a good justification for it!)

[EskoDijk]

RFC 8319 has meanwhile updated 4861, and allows MaxRtrAdvInterval to be up to 65535. (18.2 hours) https://www.rfc-editor.org/rfc/rfc8319#section-4

[EskoDijk]

PR now updated and rebased. Because 18.2 hours due to RFC 8319 may be a little long, I've added a new constant MAX_FLAGS_COPY_TIME for this set to 150 minutes. (We may discuss and shorten to 60, 50 or 30 mins also)

Also I've added another max cap on the "copy time", which is given by the Router Lifetime that the non-stub-router advertises, if it's non-zero. Reason for this is that MaxRtrAdvInterval is by RFC 4861/8319 always lower than the set Router Lifetime value (if >0). So the Router Lifetime value provides a max cap on MaxRtrAdvInterval. Given this information, it would be incorrect I think not to use it. This can still be up to 18.2 hours, which is very long, so then the MAX_FLAGS_COPY_TIME is then activated to stop the copying earlier. In "typical router" cases the Router Lifetime would be set to at most 9000 s (2.5 hours) following the original unamended RFC 4861, perhaps? The 150 minutes == 9000 s of MAX_FLAGS_COPY_TIME now coincides with this.

[Abhayakara]

I'm actually okay with using 18.2 hours as the baseline. I think it's a bad idea to use this interval as the router advertisement interval, but it's not really our problem. If the network is configured this way, I think it's okay to use that number.

[EskoDijk]

@Abhayakara The rationale for the up to 18.2 hours for MaxRtrAdvInterval / AdvDefaultLifetime in RFC 8319 was to allow for exotic cases like perfect lossless link layers and to leave restrictions up to link-technology-specific recommendation documents. I'm guessing for regular Wi-Fi / Ethernet cases, values like 600 (default) and most often <= 1800 (requried by 4861) can be expected for MaxRtrAdvInterval . Still, the Router Lifetime field can be up to 9000 sec in a 4861-strictly compliant device. This is what I've now used for MAX_FLAGS_COPY_TIME .

We can also set MAX_FLAGS_COPY_TIME to 18.2 hours - which would be reached in practice only when a non-stub-router first advertises M=1 and/or O=1 , with a Router Lifetime of 0 (the latter being typically a signature of a leaving router per 4861), and then stops sending further RAs. Then 18.2 hours after this last RA, the stub router will stop copying the M/O flags and revert back to M=O=0.

[EskoDijk]

Unless we consider sending a Router Solicitation to trigger RA transmissions.

@jwhui This is also a good point to consider: in current wording there's no requirement to send RS for this purpose, but a stub router could do it still (if nothing comes back then the status quo is maintained). Current text also captures cases of any unicast (/multicast) RAs are processed that the stub router receives as a result of it sending RSs for another reason (e.g. maybe it's trying to route packets from the stub to a next hop). So I don't see a need to say more here about sending RS only for this purpose.