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

[Esko Dijk <[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.

It looks like the names did not end up in the slides – I would be interested to see the list of names.
One variant is “sub router” as you mentioned. Or, add a letter and we get “stubb router”, or “stup router” :)

> To my knowledge there are no 6lowpan border routers that do actual routing—they all use Proxy ND. Do you know of any?

There is an open-source 6LBR with RPL routing, where different modes can be selected, including a “Router mode” – this mode doesn’t use ND proxy. See https://github.com/cetic/6lbr/wiki/6LBR-Modes
As for actual products, commonly deployed 6LBRs are Wi-SUN standard border routers (for smart energy/smart city markets) and Thread Border Routers.  For Wi-SUN 6LBRs that include a cellular backhaul and integrate a DHCPv6 server typically, I’m not sure if having ND Proxy would be useful actually – there’s no AIL in that case, only a cellular uplink to the cloud/internet. But I haven’t used any such product so you could be right here.

Esko

From: Ted Lemon <[e-mail]>
Sent: Tuesday, March 19, 2024 01:37
To: Esko Dijk <[e-mail]>
Cc: [e-mail]; Jonathan Hui <[e-mail]>
Subject: Re: [Snac] Review of draft-hui-stub-router-ra-flag-02

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Monday, March 18, 2024 05:30
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jonathan Hui <[e-mail]<mailto:[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]<mailto:[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.