Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
I found this paragraph in Section 3.1 to be hand-wavy: "Note that this specification allows using different MTUs in different links. If an implementation requires use of the same MTU on every one of its links, and a new node with a smaller MTU is added to the network, a renegotiation of one or more links can occur. In the worst case, the renegotiations could cascade network-wide. In that case, implementers need to assess the impact of such phenomenon." What are the consequences of link "renegotiation"? If every MTU downgrade results in a storm of messages, that's a bad property. Is the use case where the MTU must be the same on all links an important one? If not, simply requiring hosts to handle this case seems way cleaner.
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 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)"?
Thank you Catherine Meadows for the SECDIR review.
Hi, thank you for this document, just a minor comment: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 RFC 2119 [RFC2119], RFC 8174 [RFC8174], when, and only when, they appear in all capitals, as shown here. Strictly, this is not the text from 8174. "NOT RECOMMENDED" is missing.
Hi, Thank you for this document. A couple of minor comments relating to the diagram in 3.2 (figure 2): (1) It wasn't clear to me why the top left node was a 6LR rather than a 6LN. If this is deliberate, it might be worth a sentence to explain the purpose here. (2) I initially found the bubble around the v6 Mesh to be confusing - I thought that it means that all the nodes are interconnected. I'm not sure whether the bubble really helps the diagram, and probably could be removed, of if it is kept, I would suggest adding more space between the bubble line and the mesh network inside so that the bubble line isn't confused as representing links between the nodes. Regards, Rob