Re: [Snac] Review of draft-hui-stub-router-ra-flag-02
Ted Lemon <mellon@fugue.com> Wed, 20 March 2024 06:57 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: snac@ietfa.amsl.com
Delivered-To: snac@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8CC14F691 for <snac@ietfa.amsl.com>; Tue, 19 Mar 2024 23:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3lVDdgaNyvr for <snac@ietfa.amsl.com>; Tue, 19 Mar 2024 23:57:22 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3106C14F6AB for <snac@ietf.org>; Tue, 19 Mar 2024 23:56:57 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-7dec16fc4b2so1722266241.3 for <snac@ietf.org>; Tue, 19 Mar 2024 23:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1710917816; x=1711522616; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=F49c5oijdfDzYKq7EJyrcZwPr1kSPV5VBaos0wAx5Pg=; b=SyK3MwGB467gLj7A91g4k4Xx4JkRP57N2fuMTog720hjTmzniLSag3VcQajMxLMOZd dA54+7hoOHdOs72NEXbjUHOD6vWpd1QaeP4cb0QZWB+5b4C+WAnucBoVWYlRV5EOGY3h n2b7fFq5HUn6tvwl2kJ9Rg6aKhAY8at7g0wOY/SXx4A+lS43nQojIWsildMlOAfwHo9n wqz+WymPCpj/1Md7fFBtiZMPpec1Aw2tvwAT/nr76Wda7Pl2bwGpIWWcE28r+0KTnYQX SeXmJ7WElC0CtUibtKd9CxXl10eGZLu7NoDe3CN0vt1Qg/KPYgzav2lqMZErklgDZakI Gwrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710917816; x=1711522616; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F49c5oijdfDzYKq7EJyrcZwPr1kSPV5VBaos0wAx5Pg=; b=jaenpN7t9C94/Px62vmmtmHgJ+95du7FM42e/vvd6ZMwB/EfkPJDPsMB40jOSV6jgk GtAH3oVS/Wqkra69gVPwNY2LcJYdX273ITUWURYcT+kU3gXdNf/W8eitns1EpNopmHwN j//0c7x2ONf7LxZNW+fIVgoWVCx0mkPnIFkb1n+smeH0SWDmmcofAkpBgk7WIMDbY11D Qyb3EAqri4qBBCS1MXpJ/YfFkrvtNRqWE5fMFuFfZ7c4ZLy50N388zBgIIf2+gf5SLEb C3MaS1qLutQkDH+/n4ZGdq11FYG4zo8EQS6Hn4NMAz2wJM2Oy5vGu1hhzZnOqckJf3hq Y97g==
X-Forwarded-Encrypted: i=1; AJvYcCWDBttUZTGLvvZYMhhVxWOTnoEfJUZBQVQ88MjPhBOCCEQ4OTnC5JRarxCYayjLVcL+BDpSSyWfCpd5AoJa
X-Gm-Message-State: AOJu0Yzcc2zHth/R+xPGlKRcetFF1v1Mtkilbt9fi4Oh2qEvIWGC48OF 2Ji2kXUWB3ah0c4+lYUecNK/tvlgXKZ9IR2Xco+9mFUWAjjiM5j4bkdMZKSXzrGHyNDCA7UMeQ/ P8TSjOm9k1/xxNpJB/PgRm0u3WEjLnDQbPOevffGE+KnS1EJB0lyPwg==
X-Google-Smtp-Source: AGHT+IFk4S2wv6j6If/k1i4sEfzYpAZXiww1fzXlnRFe2hVQgLECs89fEqJHHUUAJ8CHzppLe3BKQmg8533LzDE7FrE=
X-Received: by 2002:a05:6122:a24:b0:4d4:17c5:8605 with SMTP id 36-20020a0561220a2400b004d417c58605mr15087249vkn.7.1710917815779; Tue, 19 Mar 2024 23:56:55 -0700 (PDT)
MIME-Version: 1.0
References: <DU0P190MB1978D43765330931DCAF197FFD222@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1mUDGa6ueTQtDw7Np8ONoup-nxBjBzD-w_XiccE6OVqPw@mail.gmail.com> <DU0P190MB1978AECBC56E3D789297E066FD2D2@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1ng5YthXSs3idWj4344BPC=W2aLcs_1iVZz8qN=1tkjsw@mail.gmail.com> <DU0P190MB1978CA8EF722E345C7248DDFFD2C2@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1mAp5UxZGUG-xJRUa3ja19p0AWn_Qvw+9JNzwjkt+Gwfg@mail.gmail.com> <D6E443E1-5C3E-4F45-A80B-D6508E9BA392@employees.org>
In-Reply-To: <D6E443E1-5C3E-4F45-A80B-D6508E9BA392@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 20 Mar 2024 16:56:19 +1000
Message-ID: <CAPt1N1k33wEhbyafDZbW-m6jgabnrmx9Qd5H2xRsD3ASVj12Sg@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>, "snac@ietf.org" <snac@ietf.org>, Jonathan Hui <jonhui@google.com>
Content-Type: multipart/alternative; boundary="000000000000a6636606141218b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/_yBi9EftwcREOK9lPJaEFEHDCNc>
Subject: Re: [Snac] Review of draft-hui-stub-router-ra-flag-02
X-BeenThere: snac@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for discussing problems relating to the automatic connection of stub networks to existing infrastructure networks. " <snac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/snac>, <mailto:snac-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/snac/>
List-Post: <mailto:snac@ietf.org>
List-Help: <mailto:snac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/snac>, <mailto:snac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 06:57:26 -0000
Hah! Yeah, maybe that's the right answer. :) On Wed, Mar 20, 2024 at 4:23 PM Ole Troan <otroan@employees.org> wrote: > Just: "SNAC router” and “SNAC link” or “SNAC network” is what to attach to > downstream. > Which includes “auto” and “stub” in the acronym. And makes it clear that > this is not a generic stub router, that would typically run a routing > protocol. > > One of the hardest things in computing is naming... > > O. > > > On 20 Mar 2024, at 06:40, Ted Lemon <mellon@fugue.com> wrote: > > > > FYI we've updated the document (see summary under a separate subject), > and I think it sort of avoids the second issue you raised. As to the first > issue, we do need to figure out whether or not we can continue to use the > term "stub router" to refer exclusively to the type of router described in > snac-simple, or whether we need a new name. > > > > Here's what it said in the missing slide: > > > > Esko pointed out that “stub router” already means something > > I think distinguishing our special meaning of “stub” is hard > > How about one of: > > * sub router > > * dependent router > > * subsidiary router > > * ??? > > > > On Wed, Mar 20, 2024 at 2:14 AM Esko Dijk <esko.dijk@iotconsultancy.nl> > wrote: > > > 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 <mellon@fugue.com> > > Sent: Tuesday, March 19, 2024 01:37 > > To: Esko Dijk <esko.dijk@iotconsultancy.nl> > > Cc: snac@ietf.org; Jonathan Hui <jonhui@google.com> > > 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 <esko.dijk@iotconsultancy.nl> > 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 <mellon@fugue.com> > > Sent: Monday, March 18, 2024 05:30 > > To: Esko Dijk <esko.dijk@iotconsultancy.nl> > > Cc: snac@ietf.org; Jonathan Hui <jonhui@google.com> > > Subject: Re: [Snac] Review of draft-hui-stub-router-ra-flag-02 > > On Tue, Mar 5, 2024 at 7:16 PM Esko Dijk <esko.dijk@iotconsultancy.nl> > 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 of [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. > > -- > > Snac mailing list > > Snac@ietf.org > > https://www.ietf.org/mailman/listinfo/snac > > >
- [Snac] Review of draft-hui-stub-router-ra-flag-02 Esko Dijk
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ted Lemon
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Esko Dijk
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ted Lemon
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Esko Dijk
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ted Lemon
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ole Troan
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ted Lemon
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Esko Dijk
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ted Lemon
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Esko Dijk
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Michael Richardson
- Re: [Snac] Review of draft-hui-stub-router-ra-fla… Ted Lemon