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

[Ted Lemon <[e-mail]>]

[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
>
>