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

[Mark Smith <[e-mail]>]

Hi,

On Thu, 18 Apr 2024 at 08:04, Ted Lemon <[e-mail]> 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.
>

I'm not sure I understand the comments that M&O aren't defined. RFC
4861 defines what the bits mean, and also says that routers should
validate other routers' RAs for consistency, and specifically mentions
a consistency check on the M & O bits, and should then log any
inconsistencies.

I don't think two different routers on a link announcing different M &
O bit values is invalid though, even though it may be inconsistent. A
link could support both SLAAC and stateful DHCPv6 for addressing, for
example during a graceful transition period between using SLAAC to
stateful DHCPv6 for addressing or vice-versa.

OpenWRT enables M & O by default, so both SLAAC and stateful DHCPv6
are enabled by default. It's been this way for quite a number of
years, so common IPv6 hosts that support both SLAAC and stateful
DHCPv6 would seem to be coping with doing both.

> SNAC definitely can't solve this problem.
>
> The problem with tracking M&O bits is that they don't have lifetimes.

That's an interesting point, and it seems there are other parameters
and options with the same issue that don't have their own lifetime
fields, such as 'Cur Hop Limit' value, Default Router Preference bits
and 'MTU' options.

I would guess those parameter and option values' lifetimes are as long
as the advertising router continues to be reachable via Neighbor
Discovery (and changed via subsequent RAs from the same router) and
perhaps if the interface goes down (I can't seem to find anything in
RFC 4861 about that situation right now.)

Regards,
Mark.


>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.
>
> 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.
>
> 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?
>
> On Wed, Apr 17, 2024 at 5:42 PM Erik Auerswald <[e-mail]> wrote:
>>
>> Hi Ted,
>>
>> all I do is provide another point of view, based on experience, and make
>> suggestions how to possibly improve this point of the SNAC description.
>> I don't demand anything.
>>
>> But how hard is it to describe that SNAC imagines a host to follow the
>> infrastructure router's RA with M&O bits with DHCPv6 for default route
>> communications, and the SNAC router's RA for stub network communications?
>> Since anything goes, this goes.  This does not prescribe host behavior,
>> changes nothing, just states an assumption.  There must be some idea of
>> how hosts might behave since you state that they work correctly, even
>> if this is not standardized.  The wording could be quite vague, saying
>> that host behavior is not standardized, but, e.g., the above would work,
>> and hosts are assumed to work in some SNAC-compatible way.
>>
>> To put this differently, you want a SNAC router to also do its thing
>> on a (perhaps partially) managed network, not only on an unmanaged one.
>> A short description of how this is supposed to work seems not that big
>> a burden.
>>
>> The person troubleshooting could then read how the SNAC stuff is intended
>> to work, and compare that to actual behavior.  IMHO this would be much
>> better than nothing.
>>
>> The SNAC WG tried to find a comprehensive solution by reflecting M&O
>> bits from infrastructure routers, but not SNAC routers, but this did not
>> pan out.  That is OK for me.  But I do not like the idea of ignoring this
>> detail with a silent assumption of "correct" host behavior, without any
>> description of what "correct" even is.
>>
>> So perhaps if the SNAC WG describes how they assume hosts would work in
>> a SNAC environment, this would be shot down by the IETF as out of scope?
>> I would describe that as "process failure".  Still, you could just say so,
>> and a poor soul digging into how SNAC was supposed to work might be able
>> to find this.  This would not provide a solution, but perhaps closure.
>>
>> Just not mentioning possible rough edges might seem like an easier way
>> to an RFC.  Most reviewers are more likely to notice things written down
>> than things not even mentioned.  Again, I'd call this "process failure".
>>
>> I only care about the result.  I still do not demand anything.
>>
>> ¯\_(ツ)_/¯
>>
>> Br,
>> Erik
>>
>>
>> On Wed, Apr 17, 2024 at 03:46:32PM -0400, Ted Lemon wrote:
>> > We've tried to update the documentation on the M&O bits before in the IETF.
>> > It's failed because we can't get consensus.
>> >
>> > Anyway, you're making a bunch of assertions here about what we have to do,
>> > but not backing them with anything but your gut feeling based on
>> > 20-year-old experiences. I don't think this is helpful. I'm not trying to
>> > minimize the importance of getting this right, and I appreciate your wish
>> > to make sure that we do. But it's not clear to me that you are actually
>> > talking about a real problem we need to solve. There was a lot of expertise
>> > on this in the room when we discussed it, and the general consensus is that
>> > the stuff you're describing is old news, and we don't need to worry about
>> > it anymore.
>> >
>> > It is true that the behavior of hosts is not consistent, because there is
>> > no standard that tells them how to behave. But it is not true that there is
>> > a problem, as far as we are able to tell. If you have data that suggests
>> > otherwise, please share it. But please do not demand that we do very
>> > difficult work to solve a problem that you haven't documented.
>> >
>> > Also, on a more practical note, making changes to host behavior and the
>> > treatment of M&O bits is very much not in charter for SNAC... :)
>> >
>> > On Wed, Apr 17, 2024 at 3:18 PM Erik Auerswald <[e-mail]>
>> > wrote:
>> >
>> > > Hi Ted,
>> > >
>> > > On Wed, Apr 17, 2024 at 11:25:42AM -0400, Ted Lemon wrote:
>> > > >
>> > > > 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 the handling is not defined, no handling is incorrect.  But SNAC could
>> > > describe how exactly hosts need to handle it to be compatible with SNAC.
>> > > This would at least allow to troubleshoot the breakage.
>> > >
>> > > Alternatively, SNAC could refrain from sending RAs onto a managed link
>> > > to prevent incompatibilities leading to problems.
>> > >
>> > > Alternatively, SNAC could make an honest effort to adapt to managed links,
>> > > even if this does not work in all possible cases, and document the known
>> > > problems in a section on operational considerations.
>> > >
>> > > Br,
>> > > Erik
>
> --
> Snac mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/snac