[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:


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.


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

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
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)"?