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

[Erik Auerswald <[e-mail]>]

Hi Ted,

On Wed, Apr 17, 2024 at 06:03:56PM -0400, Ted Lemon wrote:
>
> If we want to document the correct behavior of the M&O bits, that
> would definitely be a 6man thing, not a SNAC thing. I don't oppose
> that—I'm just reporting that that has been tried before and we did
> not succeed due to a lack of any clear consensus.
> 
> SNAC definitely can't solve this problem.

SNAC can describe an example host behavior that would work for SNAC.

> The problem with tracking M&O bits is that they don't have
> lifetimes. SNAC devices never want to turn them on, but if we are
> required to track them, it's actually technically difficult to
> understand how we would track them.

(This tracking seems to be part of the I-D even after merging the
below PR.  I would assume that you intend to remove those parts.)

> For professionally managed networks, SNAC isn't really necessary or
> appropriate. You could build a solution grounded in SNAC that could
> live in this environment, but it would have to be manageable, just
> like any other router.

I'd expect that a managed network can provide an environment where
a SNAC router could work, given appropriate network configuration.
SNAC seems to already envision DHCP-PD as a possible building block
for such a situation.  Having optional configurability in a SNAC-based
product might make this even simpler.

> We do actually have an appendix that talks about this issue. It's
> currently not in a published version of the draft, but you can find
> it here:
> 
> https://github.com/ietf-wg-snac/draft-ietf-snac-simple/pull/53/files
> 
> Can you take a look at that and see what you think?

The section "Use on an unmanaged (non-home) IPv6 network" seems to
describe the situation where hosts would see RAs with differing M and O
bits on the same link, but this detail is not mentioned.  Perhaps you
could add a short sentence containing something like the following at
the end of the first paragraph?

    We expect hosts to use DHCPv6 for infrastructure and SLAAC for stub
    network connectivity on the same interface.

At least I think that this captures the idea of how this scenario could
work.

Br,
Erik