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

[Ted Lemon <[e-mail]>]

The rogue router problem was really competing dhcp servers, so I don’t
think we have to worry about that.  The current design is very much
informed by that experience—you may recall that I was the author of one of
the more popular dhcp servers at that time…  :)

Op wo 17 apr 2024 om 07:43 schreef 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
>
> --
> Snac mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/snac
>