[6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-blemesh-09: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 25 February 2021 00:55 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE003A0990; Wed, 24 Feb 2021 16:55:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-blemesh@ietf.org, 6lo-chairs@ietf.org, 6lo@ietf.org, JADHAV Rahul <rahul.ietf@gmail.com>, rahul.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.26.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161421455243.10769.8266309895985939749@ietfa.amsl.com>
Date: Wed, 24 Feb 2021 16:55:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/pD-IbykBEM0PwKEKAMFEgktpxKU>
Subject: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-blemesh-09: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 00:55:53 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-6lo-blemesh-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-blemesh/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I may well just be confused about this, but let's discuss and find out. Section 3.3.2 says "[a]s per RFC 8505, a 6LN MUST NOT register its link-local address." Which part of RFC 8505 says this? Section 5.6 thereof seems to enumerate some cases where link-local addresses MUST (not MUST NOT) be registered, and there's not much other discussion of link-local addresses that I saw. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Martin (D)'s Discuss (though I think maybe the use-case that is in question is the non-homogeneous-MTU case). At a minimum the security considerations should be discussing this scenario as a risk, but ideally it could be avoided altogether. (I also agree with Martin (V)'s comment.) Section 3.1 Similarly to RFC 7668, fragmentation functionality from 6LoWPAN standards is not used for IPv6 mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided by L2CAP is used when necessary. I don't really understand why it's necessary to say "when necessary". If IPv6 requires an MTU of 1280 octets but the BLE link is doing 247 or less, doesn't the L2CAP fragmentation always need to be enabled for the IPv6 mesh? Section 3.2 Is it worth reiterating that with the multi-link subnet model, the routers have to take on responsibility for tracking multicast state and forwarding multicast/broadcast in a loop-free manner? I think we do talk about most of that elsewhere, but it could be useful to tie that in with the tradeoffs that went into this decision. (Does the "loop-free" part place any constraints on the IPv6 routing protocol(s) that can be used with IPv6 mesh over BLE?) Section 3.3.2 1. A Bluetooth LE 6LN SHOULD register its non-link-local addresses with its routers by sending a Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) and process the Neighbor Advertisement (NA) accordingly. Note that in some cases (e.g., very short-lived connections) it may not be worthwhile for a 6LN to send an NS with EARO for registering its address. However, the consequences of not registering the address (including non- reachability of the 6LN, and absence of DAD) need to be carefully considered. [...] Where can an exhaustive list of the consequences of not registering be found? It might also be helpful to give an example of something that a 6LN might do on such a very-short-lived connection where the non-link-local address is not registered (since, obviously, only link-local traffic would be possible). Section 3.3.3 To enable efficient header compression, when the 6LBR sends a Router Advertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775] matching each address prefix advertised via a Prefix Information Option (PIO) [RFC4861] for use in stateless address autoconfiguration. Note that 6CO is not needed for context-based compression when context is pre-provisioned or provided by out-of- band means. I see that in RFC 7668 sending 6CO in this situation was MUST-level required. Is the reasoning behind the weakening of the requirement just the stated scenarios where pre-provisioned context renders the in-band context indication superfluous? If so, it might be possible to reword to be more clear about expectations. If not, some additional discussion of the reasoning might be helpful. Section 8 connection with each 6LR (Step 3). After establishment of those link layer connections (and after reception of Router Advertisements from the 6LBR), Step 4, the 6LRs start operating as routers, and also initiate the IPSP Router role (note: whether the IPSP Node role is kept running simultaneously is an implementation decision). Then, (nit/editorial) The theme seems to be that "step N" is in parentheses after the description of the step, done everywhere except for step 4. So maybe " the 6LRs start operating as routers, and also initiate the IPSP Router role (Step 4) (note: whether the IPSP Node role is kept running simultaneously is an implementation decision)"?
- [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-… Benjamin Kaduk via Datatracker
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Carles Gomez Montenegro
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-… Carles Gomez Montenegro