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

[Erik Auerswald <[e-mail]>]

Hi,

back in the day, introducing rogue routers (i.e., Windows home systems
with their default behavior back then) into a managed WLAN using DHCPv6
resulted in client-side problems.  The clients would alternate between
DHCPv6 address assignment and SLAAC for the rogue prefix(es).

Today, RA Guard should help.  It might interfere with SNAC, though. ;-)

Br,
Erik


On Tue, Apr 16, 2024 at 10:22:52PM -0400, Ted Lemon wrote:
> 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