Re: [Snac] Review of draft-hui-stub-router-ra-flag-02

[Ted Lemon <[e-mail]>]

You raise a good point about the term "stub router," unfortunately. I've
proposed some alternatives in today's presentation in SNAC/DNSSD.

And you are right, I meant "proxy ND," not "proxy ARP." To my knowledge
there are no 6lowpan border routers that do actual routing—they all use
Proxy ND. Do you know of any?

On Mon, Mar 18, 2024 at 9:00 PM Esko Dijk <[e-mail]>
wrote:

> Agree it would be nice if we can just use “stub router” as a term for the
> unmanaged plug-and-play router that we’re defining in SNAC-simple.
>
> But, I do see potential confusion there because “stub router” is an
> existing term: just do an internet search on the term or ask the AIs.  In
> particular there are flavors like “OSPF stub router” and “EIGRP stub
> router” commonly used. And there’s the existing use of “stub network” (e.g.
> see Wikipedia article).
>
>
>
> Then we might need to say “SNAC stub router”, or “auto-stub router” or so,
> to be distinguishing enough.
>
> In any case, whatever term it will be, defining that properly as
> unmanaged/autoconfigured will solve most of the issues raised.
>
>
>
> > I think a 6lowpan BR is not a stub router and doesn't send RAs--it uses
> proxy ARP.
>
> Actually the 6LBR can be made in multiple ways, while the basic IETF
> definition was in RFC 6775, it was already in literature since 2009 I
> believe in the book “6Lowpan - The Wireless Embedded Internet”. When the
> term was coined it was quite generic (see the definition in the RFC 6775
> terminology list): a router interfacing between a 6LoWPAN network and some
> other network (which may be Ethernet, Wi-Fi, 6LoWPAN, or other). The 6LBR
> provides the IPv6 prefix for the 6LoWPAN network and routes packets to/from
> that network.  In this interpretation, a Thread Border Router is by
> definition a 6LBR because Thread uses 6LoWPAN.
>
>
>
> So there are particular flavors of 6LBR possible, such as a 6LBR for
> 6TiSCH networks, which is applicable to a very specific interoperable set
> of devices that use 802.15.4 TSCH and follow the IETF RFCs for these
> devices. However, there are many more 6LoWPAN based standards in existence
> and all of these could use the term “6LBR” for their border router if they
> want. There’s also extensions like the “6BBR” ND proxying operation defined
> in RFC 8929, which is maybe what you meant with proxy ARP? The 6BBR would
> not send RAs indeed but acts like a “set of hosts”.
>
>
>
> But since 6LBR is not a very common term today, we can just not mention it
> to avoid this confusion.
>
>
>
> For the rest, agree with your new text proposals!
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Monday, March 18, 2024 05:30
> *To:* Esko Dijk <[e-mail]>
> *Cc:* [e-mail]; Jonathan Hui <[e-mail]>
> *Subject:* Re: [Snac] Review of draft-hui-stub-router-ra-flag-02
>
>
>
> On Tue, Mar 5, 2024 at 7:16 PM Esko Dijk <[e-mail]>
> wrote:
>
> Overall, there's a bit of confusion on what the flag expresses. Its name
> is "stub router flag" but the flag is only set, I believe, for
> unconfigured/unmanaged stub routers.  As soon as a stub router becomes
> managed, it is part of "infrastructure routers". Even though it is still is
> a stub router per the definition - because it provides connectivity to a
> stub network. I would be okay to keep the name as is, or to rename it to
> something like "Unmanaged Stub Router Flag", but it needs to be clarified
> when the flag is set, and when it is cleared (especially for a stub
> router!). In the list below are some suggestions that go into this
> direction.
>
>
>
> I think that a device that's managed is not a stub router, and so this
> doesn't apply. The introduction doesn't make this point clear—it suggests
> that any router connecting a stub network and an infrastructure network is
> a stub router, but that's not really the case. The idea of a stub network
> is just that there's no routing through it, and this is a normal
> operational thing that happens all the time. A home network is ordinarily a
> stub network for example, although it's not required to be.
>
>
>
> So I think the fix for this is to update the introduction to make this
> distinction clear: a stub router is an unmanaged device that automatically
> connects a stub network to an infrastructure network.
>
>
>
> So I would change this:
>
>
>
> A stub router provides IP connectivity between a stub network and an
> infrastructure network. A common stub router example is a device that
> attaches a 6LoWPAN-based network to a home network.
>
> to this:
>
> A stub router is an unmanaged router that automatically connects a stub
> network [draft-ietf-snac-simple] to an infrastructure network.  A common
> example of a stub router is a router that attaches a 6lowpan network to a
> home network without requiring explicit configuration by an operator.
>
>
>
> And: do we foresee a case where a managed stub router sends out PIO with a
> managed ULA prefix (so stub router flag=0); but unfortunately the prefix is
> not "suitable" so the stub router adds its own self-generated ULA PIO
> prefix in an unmanaged way - so it also wants to set stub-router-flag=1 ?
>  Probably not? (sounds like the admin either made a mistake or doesn't want
> the stub-network & AIL communication to be enabled on purpose). My working
> assumption is that we don't need per-PIO-prefix granularity for advertising
> "this is a non-managed prefix", for our current use cases.  Still, it can
> be considered as a solution alternative because it allows future use cases
> easier. This would use 1 flag bit in the PIO where flag space is more
> scarce. So it's not super attractive to go change this now but I'd like to
> know what others think.
>
>
>
> I think the document should make clear that in a situation where the
> infrastructure router connects a stub network to the infrastructure
> network, and where that infrastructure router is providing IPv6 addressing
> and (optionally) routing on the infrastructure network, that device is not
> a stub router and should not be setting the stub router flag in router
> advertisements.
>
>
>
> It's worth noting that there are devices in the field that do both
> functions independently, and so wind up sending some infrastructure RAs and
> some stub network RAs. This is technically allowed by RFC4861, but RFC4861
> doesn't explain how to do it, and it doesn't really work. So we should
> probably exclude this use case: a device that behaves in this way simply
> isn't likely to work, and we shouldn't encourage it.
>
>
>
>
> Abstract
> "information sent by stub routers from information sent by infrastructure
> routers."
> --> "information sent by unmanaged stub routers from information sent by
> infrastructure routers."
>
> We could add the sentence to the abstract, to make it complete and
> summarize the entire document:
> "This flag, if set, indicates that the message is sent by an unmanaged
> stub router."
>
>
>
> There is no such thing as a managed stub router, so no need for this
> update.
>
>
>
> 1. Introduction
> --> Section should reference the [I-D.ietf-snac-simple] document earlier;
> and point the reader there for details on the whole described functionality
> of ULA prefix and tracking infrastructure-provided IPv6 service.
>
>
>
> Agree, see above.
>
>
>
> "A common stub router example is a device that attaches a 6LoWPAN-based
> network to a home network."
> --> Can mention here the name of such a device: a 6LoWPAN Border Router
> (6LBR).
>
>
>
> I think a 6lowpan BR is not a stub router and doesn't send RAs--it uses
> proxy ARP. I think it would be cool if that document were updated to advise
> implementing a stub router instead, but that's out of scope.
>
>
>
> "In the second case, the two stub routers could wind up in a cycle of
> publishing and deprecating their prefixes as they see prefixes from the
> other stub router show up.
> The stub router document [I-D.ietf-snac-simple] explains how two stub
> routers decide which one has precedence in the event of a conflict."
>
> --> This part is somewhat confusing. Maybe emphasize that we need to
> distinguish between unconfigured stub routers and all "other" routers here,
> pointing to snac-simple, instead of focusing on the problem / conflict here.
>    The first sentence could be replaced by:
>    "The stub router needs a method to distinguish between these two
> sources."
>
>
>
> One way to fix this would be to say:
>
>
>
> "In the second case, stub routers need to be able to tell whether an RA is
> from another stub router or an infrastructure router. Without the stub
> router RA flag,  two stub routers would not be able to make this
> distinction. In situations where both stub routers publish their initial
> RAs relatively simultaneously, this could then result in an endless cycle
> of deprecations."
>
>
>
> "However, the infrastructure prefix always has precedence over a prefix
> provided by any stub router."
> --> "However, a suitable infrastructure-provided prefix always has
> precedence over a self-generated prefix provided by any stub router."
> (Note here that stub routers could be either unconfigured, or configured
> (managed). The lower precedence is only for the unconfigured ones.)
>
>
>
> Not needed, no such thing as a managed stub router.
>
>
>
> 2. Terminology
> --> Include here by reference all the terms of [I-D.ietf-snac-simple]
>
>
>
> Sure.
>
>
>
> 4. Router Advertisement Transmission
> --> see my comments on top - to add here the explicit requirement that a
> stub router that is configured/managed (i.e. part of infrastructure
> routers) MUST NOT set the stub router flag ?
>
>
>
> Again, no such thing.
>
>
>
> "How and when a stub router sets the M and O flags in outgoing RAs is
> specified in [I-D.ietf-snac-simple]."
> --> "How a stub router sets the other flags in outgoing RAs, and when
> these RAs are sent, is specified in [I-D.ietf-snac-simple]. "
> (Seems best to generically refer to all other flags. This then requires
> pulling out the "when" part.)
>
>
>
> I tihink this text could be clearer:
>
>
>
> Additionally, the RA header includes M and O flags that indicate whether
> DHCPv6 is available on the link. Section 6.3.4
> <https://rfc-editor.org/rfc/rfc4861#section-6.3.4> of [RFC4861
> <https://www.ietf.org/archive/id/draft-hui-stub-router-ra-flag-02.html#RFC4861>
> ] specifies that hosts consider the most recently received information as
> authoritative. In order to avoid overriding whatever the infrastructure
> router is advertising, [draft-ietf-snac-simple] requires stub routers to
> mirror the M and O values in RAs received from infrastructure routers. The
> Stub Router flag provides a way for stub routers to correctly make this
> distinction.
>
>
> "A stub router"
> --> should we constrain this specifically to "A stub router implementing
> [I-D.ietf-snac-simple]" ?
>
>
>
> There are no other stub routers yet. Bear in mind that the
> "infrastructure-supported stub router" draft that we're planning to do
> after snac-simple is still a case where stub routers are unmanaged; the
> difference is that stub routers in the second draft will be able to
> discover and use services on infrastructure.
>
>
> 5. IANA Considerations
> --> Table 1 add caption
>
> 6. Security Considerations
> --> best to expand "NDP" here - I don't see that acronym used in 4861, nor
> in the draft elsewhere.
>
> We could add that there are no known security issues of setting the new
> flag, or spoofing it.
>
>
>
> Yup. Thanks for the review! Looks like we need another spin of the
> document before we present it to 6man.
>