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

[Ted Lemon <[e-mail]>]

Hm. The consensus that seemed to arise in discussion in the room(s) is that
we can't really fix this, and it doesn't make sense to try. That is, we
shouldn't track the M&O bits sent by other routers. If they send
inconsistent bits, too bad, the host stack already has to deal with that
anyway.

On Tue, Apr 16, 2024 at 6:15 AM Esko Dijk <[e-mail]>
wrote:

> > 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]> wrote:
>
>
>
> > On Mar 20, 2024, at 11:03 AM, Esko Dijk <[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
>
>