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

[Ted Lemon <[e-mail]>]

I think that that is an unfortunate way to characterize what we are
discussing.

The behavior of the M and O bits isn’t defined anywhere.  Modern hosts have
had to adapt to this.  During the discussions we had in Brisbane the
consensus was that they do now handle inconsistent M&O bits correctly.

If you are aware of current implementation behaviors that are contrary to
this, we need to know about that, so please do share that information.
However, experiences from the early 2000s probably aren’t cause for
concern—the fact that you had that experience then suggests that
implementers did too, and updated their code accordingly.

Op wo 17 apr 2024 om 10:16 schreef Erik Auerswald <
[e-mail]>

> Hi Ted,
>
> the problem I mentioned introduced rogue IPv6 routers ("Internet
> Connection Sharing") that sent RAs without M or O flags, but the network
> actually required DHCPv6, with correct RAs sent by the legitimate subnet
> router with set M and O flags.  There was only one (redundant) DHCPv6
> server involved.
>
> The clients received a legitimate RA and configured themselves via DHCPv6.
> Then they received a rogue RA, forgot the DHCPv6 address, and created
> a new address via SLAAC in a different subnet.  This then repeated.
> Hilarity ensued.
>
> The unusually large amount of DHCPv6 requests was the first thing to come
> to attention when troubleshooting the WLAN problems.
>
> This is from quite a few years back, the network in question uses IPv6
> since 2003 (mostly dual-stack with IPv4).
>
> It does not matter how hosts are supposed to cope with inconsistent RAs.
> It only matters how they do cope.  Back in the day, they did not cope
> well.
>
> I'd think the question is whether SNAC wants to play nice, or wants to
> play rough ("if you manage your network, you must use RA Guard or suffer
> the consequences").
>
> Br,
> Erik
>
> P.S. IMHO some protection against IPv6 attacks is required for every
>      managed network, be it RA Guard and friends, or dropping all frames
>      with an Ethertype of 0x86DD.  Not every managed network is properly
>      protected, though.
>
>
> On Wed, Apr 17, 2024 at 08:37:04AM -0400, Ted Lemon wrote:
> > 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
>