Re: [IPv6] [Snac] M/O Bit reflection behavior of draft-hui-stub-router-ra-flag-02

[Esko Dijk <[e-mail]>]

> is the current requirement that the M&O bits be consistent between RAs actually a good idea? And separately, is it necessary?

To get it 100% consistent all the time seems to make a solution complex (as our past discussions about reboot corner cases show). It would need a distributed consensus algorithm.

One simpler solution is
1 - copy/mirror the latest values advertised by a non-stub-router, if any
2 - when a stub router boots/reboots, first send an RS to get non-stub-routers on the link to respond to see their M/O flags, if any  (this RS is anyway needed after startup, to know whether existing on-link prefixes are “suitable” in the SNAC sense).
3 - if no regular routers are found (only SNAC stub routers) – then advertise M&O flags with value ‘0’ . This may conflict with other stub routers that advertise ‘1’ – but only for a limited time.
  (Eventually these stub routers will switch back to ‘0’ or to the RA-advertised value, if such a non-stub-router RA ever shows up again in the future)

Agree with your 3 questions but I don’t know answers. Btw what does “DHCPv6 is wanted” mean here – that the client or the higher layer controlling this client gets a sudden instruction or preference for obtaining a DHCPv6 based address/prefix/information ?

Esko

From: Ted Lemon <[e-mail]>
Sent: Wednesday, March 20, 2024 08:07
To: Suresh Krishnan <[e-mail]>
Cc: Esko Dijk <[e-mail]>; [e-mail]; 6MAN <[e-mail]>
Subject: Re: [Snac] M/O Bit reflection behavior of draft-hui-stub-router-ra-flag-02

[Adding 6man to this discussion for reasons that will shortly become apparent]

Suresh and I had a conversation offline about persisting the M&O bits advertised by other routers. Suresh accumulated quite a few battle scars over this back in the day. I think we could solve this problem, but just the stub router bit isn't going to be enough to solve it. And then the question came up: is the current requirement that the M&O bits be consistent between RAs actually a good idea? And separately, is it necessary?

I don't think we can answer that here, but it might be worth trying to get an answer to that before proceeding with a complicated solution. At present at least Apple BRs do not in fact reflect the M&O bits received from infrastructure routers, and we haven't had any bug reports as a result. That's not a particularly good indication, but I think it's worth investigating what DHCPv6 IA_NA and IA_PD and Information-Request clients actually do when the M&O bits go away.

There are three questions I would ask:
1. What happens if the M&O bits are advertised, and a DHCPv6 client of any of the three types starts, and then a new RA is seen with the relevant bit(s) clear?
2. What happens if the M&O bits are not advertised, but DHCPv6 is wanted, and then an RA shows up with the M&O bits set. Does DHCPv6 start?
3. What happens if the we get an RA with the M&O bits set, and then an RA with them clear, and /then/ an indication that DHCPv6 is wanted?

Some of these questions may not make sense in all situations, but I think this is the complete set of questions. Suresh's and my belief is that once a client has started doing DHCPv6, it's going to continue to do so even if it sees an RA with the relevant bit(s) clear. But it would be good to test that theory.


On Wed, Mar 20, 2024 at 12:12 PM Suresh Krishnan <[e-mail]<mailto:[e-mail]>> wrote:


> On Mar 20, 2024, at 11:03 AM, Esko Dijk <[e-mail]<mailto:[e-mail]>> wrote:
>
> PS:
>
>> What the draft-hui-stub-router-ra-flag could do is just refer to this one, perhaps?
>
> My remark may not be fully clear. What I meant here is that the sentence stating that the values of M and O are mirrored, could refer to this behavior with a sentence like "as defined in [draft-ietf-snac-simple]."
> This avoids explaining the mirroring in much detail within draft-hui-stub-router-ra-flag. And it directly answers the question the reader may have on how this works in detail.

Thanks for that clarification Esko. That will certainly clarify the intended behavior for this draft. I do have further concerns regarding race conditions copying bits between stub routers, but that is not a concern for this draft.

Regards
Suresh