Dear Bernie and all: Please note that I posted the attached review per the int area assignment. Take care, Pascal -----Original Message----- From: Pascal Thubert (pthubert) Sent: mardi 27 septembre 2016 11:17 To: 'cjbc@it.uc3m.es' ; Carlos Pignataro (cpignata) Cc: Bernie Volz (volz) ; Terry Manderson ; Suresh Krishnan Subject: RE: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05 I posted my review to the 6lo list and the draft authors, Carlos. Please find it attached for your convenience; Take care; Pascal -----Original Message----- From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] Sent: vendredi 16 septembre 2016 12:48 To: Carlos Pignataro (cpignata) ; Pascal Thubert (pthubert) Cc: Bernie Volz (volz) ; Terry Manderson ; Suresh Krishnan Subject: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05 Hi Carlos and Pascal: You are next up on the Int Area Directorate review assignment queue and the Int ADs have requested a review of draft-ietf-6lo-dect-ule-05 (see https://tools.ietf.org/html/draft-ietf-6lo-dect-ule-05). Please note the request below, but again, you are only being asked to review ONE of these documents. Please response to this email as soon as possible (and within 72 hours) to indicate whether you CAN or CANNOT review this document. Please assume that the review needs to be completed within 2 weeks (by September 30th). For more details, see https://www.ietf.org/iesg/directorate/intarea.htm l. Thanks much in advance! - Carlos (& Bernie) Dear all : I am an assigned INT directorate reviewer for draft-ietf-6lo-dect-ule-05. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. Document: draft-ietf-6lo-dect-ule Transmission of IPv6 Packets over DECT Ultra Low Energy Reviewer: Pascal Thubert Review Date: Sept 27, 2016 IETF Last Call Date: TBD Summary: Issues concerning the subnet model that needs to be explicited. Major issues: - Reference to draft-ietf-6lo-privacy-considerations and privacy of addresses should be addressed (related to lifespan of IEEE EUI48 addresses, random but permanent is still not too good) - Subnet model (Section 3.3) should be described in more details, indicating NBMA Multi-Link SubNet (MLSN). Suggestion to review/emulate RFC 7668 (section 3.2.1 and last paragraph of 3.2.2) - Reference to draft-ietf-6lo-backbone-router could be made to address the L3 perspective of node mobility - Some IMPERATIVE is extraneous. (RFC2119: "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm") Minor issues: - inline on the right of the original text, with a "<<" prefix --- 6Lo Working Group P. Mariager Internet-Draft J. Petersen, Ed. Intended status: Standards Track RTX A/S Expires: November 17, 2016 Z. Shelby ARM M. Van de Logt Gigaset Communications GmbH D. Barthel Orange Labs May 16, 2016 Transmission of IPv6 Packets over DECT Ultra Low Energy < snip> 1. Introduction DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface <<< spell DECT on first use technology building on the key fundamentals of traditional DECT / CAT-iq but with specific changes to significantly reduce the power consumption at the expense of data throughput. DECT (Digital <<< DECT spelling Enhanced Cordless Telecommunications) is a standard series [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced Technology - internet and quality) is a set of product certication and interoperability profiles [CAT-iq] defined by DECT Forum. DECT < snip> In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single FP defining the network with a number of PP attached. The MAC layer supports both traditional DECT as this is << "both" is unclear, can you rephrase? used for services like discovery, pairing, security features etc. All these features have been reused from DECT. < snip> [DECT ULE PP]-----\ /-----[DECT ULE PP] \ / [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP] / \ [DECT ULE PP]-----/ \-----[DECT ULE PP] Figure 2: DECT ULE star topology << suggestion to place a forward reference to section 3.3 on how IP uses that (MLSN) A significant difference between IEEE 802.15.4 and DECT ULE is that the former supports both star and mesh topology (and requires a routing protocol), whereas DECT ULE in it's primary configuration does not support the formation of multihop networks at the link layer. In consequence, the mesh header defined in [RFC4944] for mesh < snip> When bound to a FP, a PP is assigned a 20 bit TPUI which is unique << in reference to draft-ietf-6lo-privacy-considerations it would be good to indicate whether this is short lived or long lived, so as to figure if an IPv6 address can be derived or not. within the FP. This TPUI is used for addressing (layer 2) in messages between FP and PP. < snip> Optionally each DECT PP and DECT FP can be assigned a unique (IEEE) MAC-48 address additionally to the DECT identities to be used by the << same as above, it would be good to indicate whether this is short lived or long lived, so as to figure if an IPv6 address can be derived or not. 6LoWPAN. During the address registration of non-link-local addresses as specified by this document, the FP and PP can use such MAC-48 to construct the IID. < snip> support complete IP packets, the DLC layer of DECT ULE SHALL per this << there is a MUST later in the document, no need to uppercase here; whether this setting is needed is debatable specification be configured with a MTU size that fits the requirements from IPv6 data packets, hence [RFC4944] fragmentation/ reassembly is not required. << unclear. .. since DLC supports fragmentation there is no need for 6LoWPAN fragmentation is there? The adaptation described here only provides value if the DLC fragmentation is armful. Is that the case ? It is expected that the LOWPAN_IPHC packet will fulfil all the requirements for header compression without spending unnecessary overhead for mesh addressing. It is important to realize that the usage of larger packets will be at the expense of battery life, as a large packet inside the DECT ULE stack will be fragmented into several or many MAC layer packets, each consuming power to transmit / receive. << proof? fragments increase reliability and reduce the size of retried pieces. is there a paper showing pros vs cons or is this the author intuition ? 2.5. Additional Considerations The DECT ULE standard allows PP to be registered (bind) to multiple FP and roaming between these FP. This draft does not consider the << Why ?? this is where the backbone router becomes handy. If the subnet model is clarified to NBMA / MLSN then it is possible to assign the same prefix to multiple 6LBRs and connect them through a 6lo backbone router scenarios of PP roaming between multiple FP. The use of repeater functionality is also not considered in this draft. < snip> 3.1. Protocol Stack In order to enable transmission of IPv6 packets over DECT ULE, a Permanent Virtual Circuit (PVC) has to be opened between FP and PP. This MUST be done by setting up a service call from PP to FP. The PP << is this MUST coming from this spec or from DECT? if the latter then just say "this is done by..." SHALL specify the <> in a service-change (other) message before sending a service-change (resume) message as defined in [TS102.939-1]. The <> SHALL define the ULE Application Protocol Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP MUST send a service-change-accept (resume) containing a valid paging descriptor. The PP MUST be pageable. < snip> 3.2. Link Model The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is layer 2. The DECT ULE implements already fragmentation and reassembly functionality, hence [RFC4944] fragmentation and << this is repeating and sight contradictory. suggestions to keep the text starting at RFC4944, dropping the beginning of the sentence reassembly function MUST NOT be used. The DECT ULE DLC link (PVC) MUST be configured with a minimum MTU size of at least 1280 octets in << Not sure this is needed order to meet the size requirements of IPv6. < snip> compression context if any, and from address registration information (see Section 3.2.2). Due to DECT ULE star topology, each branch of the star is considered to be an individual link and thus the PPs cannot directly hear one << indicate that this is NBMA, multilink subnet. See related text in 6LoWPAN BTLE RFC 7668 another and cannot talk to one another with link-local addresses. However, the FP acts as a 6LBR for communication between the PPs. After the FP and PPs have connected at the DECT ULE level, the link can be considered up and IPv6 address configuration and transmission can begin. The FP ensures address collisions do not occur. 3.2.1. Stateless Address Autoconfiguration At network interface initialization, both 6LN and 6LBR SHALL generate and assign to the DECT ULE network interface IPv6 link-local addresses [RFC4862] based on the DECT device addresses (see Section 2.3) that were used for establishing the underlying DECT ULE connection. The DECT device addresses IPEI and RFPI MUST be used to derive the << SHOULD vs. MUST: with a MUST, this means that the 6LoWPAN code does never expect a link local that is not fully elided (3.2.4.1.)? IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR, respectively. < snip> see [RFC7136]. For example from RFPI=11.22.33.44.55 the derived IID is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived IID is 00:01:23:ff:fe:45:67:89. << This seems to be setting permanent addresses (admittedly Link local), and the privacy properties of such addresses should be addressed, eg addresses do not (lust not) leak in app layer in any fashion As defined in [RFC4291], the IPv6 link-local address is formed by appending the IID, to the prefix FE80::/64, as shown in Figure 4. < snip> (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque << This seems to be setting permanent addresses; discussion on renewing addresses would be good, ref to draft-ietf-6lo-privacy-considerations would help, and the security section could just point here as opposed to use IMPERATIVE addresses [RFC7217] SHOULD be used by default. In situations where < snip> 2. A DECT ULE 6LN MUST NOT register its link-local address. A DECT << the registration has 2 roles, DAD (which can be avoided for globally unique addresses) and SLLA mapping. This seems to indicate that SLLA is deduced from the LL so there's special code to avoid using an ND cache? ULE 6LN MUST register its non-link-local addresses with the 6LBR by < snip> accordingly. The NS with the ARO option MUST be sent irrespective of the method used to generate the IID. The 6LN MUST register only one << why can't a device form more than one address? IPv6 address per available IPv6 prefix. < snip> the DAM field of the compressed IPv6 header as CID=1, DAC=1 and DAM=01 or DAM=11. Note that when a context is defined for the IPv6 << considering the rest of the optimizations, why don't you have a /128 context for the 6LBR? destination address, the 6LBR can infer the elided destination prefix by using the context. < snip> 3.3. Subnets and Internet Connectivity Scenarios << Missing scenario below, same /64, with backbone router 6LN 6LN \ / \ / 6LN --- 6LBR ------ 6LBR --- 6LN / \ / \ 6LN 6LN < snip> _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo