6lo WG Meeting IETF97, Seoul, S.Korea TUESDAY, November 15, 2016 15:50-18:20 Local Time Grand Ballroom 2 Chairs: Samita Chakrabarti, Gabriel Montenegro Secretary: James Woodyatt Responsible AD: Suresh Krishnan Technical Advisor: Ralph Droms Etherpad Minutes takers: Dominique Barthel, Thomas Watteyne ------------------------------------------------------------------------------------------------------------- IETF97 meeting started by co-chair Gabriel Montenegro. The other co-chair Samita Chakrabarti was remote over Meetecho. 6lo WG secretary James Woodyatt was also present along with Gabriel on site. After the initial agenda bashing, Gabriel and Samita provided the draft status of the working group since the last meeting. 6lo WG had made very good progress since IETF97 with the help of AD and the INTAREA community reviewers. draft-ietf-6lo-ethertype-request has become RFC7973 and draft-ietf-6lo-paging-dispatch was also on RFC editor queue. Draft-ietf-6lo-dect-ule, draft-ietf-6lo-6lobac, draft-ietf-6lo-dispatch-iana-registry and draft-ietf-6lo-privacy-considerations have been submitted to IESG and all of them are on IETF LC on the week of IETF97. 3 drafts have been adopted as WG documents. They are: • draft-gomez-6lo-blemesh-02 • draft-hong-6lo-usecases-03 • draft-sarikaya-6lo-ap-nd-04 Gabriel provided updates on MLE-MESH documents that there is still hope that this document needs some update and hopefully the update will be made soon and go forward in the WG. Suresh Krishnan, responsible AD provided status on ethertype document which was waiting for sometime to receive the IANA assignment before final publication. Dave Thaler discussed the comments on generalizing the privacy document – no changes have been made as it targets the constrained nodes. The privacy document addressed AD review comments. Samita provided update on 6lo-6lobac draft based on the slides provided by Kerry Lynn. The document addressed AD review and other reviews during the IESG review process. Most notable change is in section 3 where all multicast packets are now MUST be broadcast (instead of SHOULD). IPv6 over NFC: draft-ietf-6lo-nfc-05 was presented by Younghwan Choi : He discussed some of the comments received from NFC forum. Main changes in the draft are in MTU extension plus examples of topology and application. * IID generation. Thanks to Dave for feedback. Comments taken into account. Added discussion on link lifetime and IID lifetime. * [Dave Thaler] still potential issue around word "random" * if endpoint specifies the hash function, we can recover the IID. * suggestion: pick a specific hash function and inputs, you can get full compression * you should be able to use every bit excetp "u", don't keep all these 0's as in the current figure. * [Suresh] question for Dave: how do you expect the shared "secret" * [Dave] NFC already does something, we shouldn't invent something different but reuse * no more comments from NFC forum so far. * [Pascal] no comments, does it mean NFC forum will now reference this doc? [Younghawn]: will ask comments for the last version of this doc. * [Younghwan] they deal with lower layer, we deal with upper layer. They don't have to reference our work. * [Gabriel] how many round-trips of info with NFC Forum? * [Younghwan]Feedback received only once. * [Gabriel] beware that more may come. Let's wait for a new revision which incorporates the privacy proposal from Dave Thaler, and go to WG LC after. * [Samita] asks Suresh for advice on going forward with NFC forum * [Suresh] we don't have a formal way of talking to NFC Forum, a common participant might go present it. Don't want anything too heavy but can look into it. * [Gabriel] they are aware of the work, already provided feedback, so ... IPv6 over Bluetooth Low Energy Mesh Networks : Carles Gomez presented draft-gomez-6lo-blemesh and provided status on the comments from BT SIG. * status: * -01 in individual was presented in Berlin. Comment was that should contain BT SIG * -02 submitted after feedback from BT * The document is now adopted by WG, this is now -00 of WG doc * Mark Powell Exec director of BT SIG. Thanks to chairs for establishing contact with BT SIG. * several people including Mark Powell provided comments on this document * one request was to avoid confusion with BT Smart Mesh activity taking place at BT SIG, therefore request name change. * The document title was changed as a consequence, also explicit mention of IPSP in abstract, and more detailed explanation in Section 2. * terminology updates throughout document using phrasing alternative to "BT mesh" * reference to RFC 7416. Enumerate threats and countermeasures. * asking audience to read doc and provide feedback, and to implement and provide experimental feedback. * [Rahul] BT mesh vs. BLE mesh, wich doesn't support multicast. Explain the consequences. 6lo Applicability and Use Cases : dreaft-hong-6lo-use-cases status update by Yong-Geun Hong : * history of doc: since IETF89. Presents comments received during adoption call. Reproduced on slides, in extenso. * doc currently describes 7 technologies, with inputs from each technology experts. * characterizes them along 12 axes. * one practical market use case described for each technology. * since IETF96, updated introm updated MS/TP, increased design space dimensions * work coming up: update of MS/TP, 6tisch, LTE-MTC. Refer to detnet. Should we consider LPWAN as a use case? Security considerations in general or for each use case? Add a comparison table. * next steps: will submit as WG -00 doc * [Samita] LTE-MTC: don't know of any 6lo implementation or project of LTE-MTC. * [Yong-Geun] at South Korea Telecom, IPv6 over LTE-MTC implementation, but not a commercial product so far. * [Samita] will ask the WG if we want include LTE-MTC in this work. * [Yong-Geun to the audience] if your company has expertise or development, let us know. An Update to 6LoWPAN ND : draft-thubert-6lo-rfc6775-update was presented by Pascal Thubert : * The work was extracted from backbone router document. decided to split the update to RFC6775 out of backbone router doc. Personal submission but text is quite mature. * backbone router draft will be cleaned up as soon as this is adopted. * ARO is extended. TID is seq num. Was already presented in efficient-nd draft preseted at 6man. * Registering the target address is now supported. Allows doing proxy registration. * After last IETF, discussion. Decided not to change the link model. * No more DAR/DAC exchange between 6LR and 6BBR, removes need to store address pending validation in separate neighbor cache. * there was discussion about link model, decision not to change it has been made. Rest is stable text from backbone-router draft. So, the authors are asking for adoption. * [Carsten] what process for getting 16 bit address? [Pascal] done before ... * [Carsten] we can talk about this offline. Need to understand * [James ] had criticsm about 6775. Large deviation from regular IPv6 ND. Now this draft is an update to 6775. Time to describe this as a protocol totally independant from IPv6 ND? Should say somewhere that this is ND for 6lo, not to be used for regular IPv6. * [James] get more contribution from 6man. [Pascal] or work at 6man to have it adopted alongside IPv6 ND. [ James] would object. Don't want address registration in the whole IPv6 world. Still discussion at 6man? Not lately. * [Lorenzo] answer that efficient-ND got from 6man was "not on my network". I don't want to see this on networks that are not constrained. Constraining addressing is giving a lot of IPv6. We should scope this work so that each WG ... * [Carsten] will repeat some of the history. 6lowpan-nd was developed because there are networks on which multicast is not cheap, which IPv6 ND assumes. Can imagine that people that have networks on which multicast is cheap don't want to redo work. No intention to conquer the rest of the world with this. We just need a way to build ND without multicast. * [Samita] if this doc is used for 6lo network, don't need to generalize its use in 6man. I don't see a conflict. * [Pascal] no constraint is placed on the IPv6 address that is registered. * [Erik] not a big facn of non-technical discussion at the IETF. Doesn't make much sense. AD's decide what WG work on what. * [Lorenzo] was technical. Concern raised in 6man was that ... ? * [Erik] philosophical concern, not technical argument. * [Lorenzo] we do have a BCP that says it's a bad idea to limit the number of addresses you have. If it's a L2 characteristic, fine. Increasing trend to giving prefixes to hosts, at 6man and 6ops. * [Pascal] a prefix per host is depriving network of resources. * [Suresh] for general purpose hosts, allocate prefixes. But not for small IoT device. * [James] my concern has technical consideration. Add a bunch of IANA codes in registry, they are specific to 6LoWPAN ND. What happens if you see them in ND tha this not 6LoWPAN? Pick your own tables, not the general IPv6 ND tables. So don't have to ask for 6man to review it. Don't call it ND, it's doing something else. * [Suresh] do I understand you want to subtype what we already have? * [James] make new ones * [Suresh repeating James] fork the space nbetween 6LoWPAN ND and IPv6 ND. * [Erik] where to you want the fork? * [James] make different registries. With same numbers. * [Erik] is it not sufficient to have comment in common table saying it comes from RFCxxxx so that it's for 6LoWPAN ND? [James] yes [Erik] well, we already did it. * [Carsten] * [Lorenzo] possible to havw a container for 6lo options. Better than entirely forking space.] * [Suresh] opposed to forking without having a space to * [Erik] increasing divergence. Reason is interesting. Attempt at folding some ne stuff back into 6man to make it more common failed for philosophical reason. * [Gabriel] hears questions about scoping, when does this apply? when multicast is expensive. Don't oversell. We could have 6man review, with AD support. Some concerns about scoping? * [Pascal] don't think so. We know where this applies. * [James] language in the draft says that intended for constrained network; but no text that says "not for non-constraint" * [Pascal] don't agree, why not? * [Carsten] other specs (e.g. IP over Ethernet) don't mandate the use of this * [Lorenzo] making engineering trade-off between paying the cast of multicast and functionality you get. Trade-off may not be beneficial on constrained devices. * [Gabriel] can we clarify those points before we call for adoption * [Lorenzo] if we said where this does not apply * [Gabriel] its the IP-over-foo argument. It's up to foo to decide what to adopt. * [Bob Hinden] righ now on classical networks, we have 2 ways for "registering", if we announce this, will hurt the adoption of IPv6 * [Gabriel] could 6man state that for non-constrained don't use that one * [Bob] need to think, but would not be useful for the general objective of deploying IPv6 * [Carsten] there is no third kind * [Erik] this is for DAD and address registration while you're asleep. Not address allocation. Can use SLAC. * [Suresh] AR already exists. ARO is in there. This is adding transport for it. No more time for philosophical opposition to ARO. * [Gabriel] humm to support adoption? humms heard. * [Gabriel] "Humm if you do not think this should be adopted". No humm heard. * [Gabriel] Will bring it to the mailing list. Designating 6LBR for IID Assignment : draft-rashid-6lo-iid-assignment-02 (Charlie Perkins): * Idea: have the LBR suggest an IID is the DAD fails, helps the node, reduces traffic and energy * new version contains a solution to forward that compressed * "Cycle" to count number of DAD failures, on 4 bits * version -02 posted recently, doesn't mandate use of RFC7217 but if you do, recommendations * comments received was "why do we need this, collisions are rare anyway". Added text to show why it matters. several reasons, listed on slide. * goes through advantages of this proposal over current ND. * [Michael Richardson] DHCP. Multicast from address that nobody knows. Ethernet solves this by L2. * [Dave Thaler] where does the 6LBR get the Interface .. ? * [Charlie] * [Dave Thaler] did you say 6LBR runs 7217? I thought 6LN doesn;t ahve to generate IID. * [Charlie] it does and tries to register this address. Only if 6LBR sees collision, suggest another address. * [Dave Thaler] rephrases. How does the 6LBR get .. info .. from 6LN? * [Dave Thaler] need to say mechanism only work if one interface only, or ... * [Dave Thaler] 7217 has provision for several network interfaces. This mechanism, 6LBR doesn't known how to * [Dave Thaler] * [Pascal] you need to "book" * [Erik] 62 bits of randomness, what the motivation? danger is that we are inventing a new allocation policy, not duplicate. * motivation: networks can become very large * see slides for discussion why you have less randomness than you would think. * [Erik] not using MAC address as the main key. Devices have hardware random generators, for key generation e.g. * [Michael] difficult is to have a stable identifier. * [Erik] unless billinos of deices in the same network, collisino prob extremely small. * [Lorenzo] this is device saying "I want ot use ID A" and network responding "no, you'll have ID B". Network has better resources and storage, so let's make it that the device asks for an address. * [Carsten] lloking for a reasono to do this? Origianlly because trying to get a 16 bit address by regsitregin ... Random 16 bit address only fine up to about 2^15 devices. That's wy this work got started. * [Charlie] * [Carsten] doesn't make sense in MS/TP, nor 15.4 * [Lorenzo] why an XOR in slide 4? * [Carsten] original problem was most nodes are sleeping, can't find out who's there with address equal to tentative address. Registering at a router solves this. * [Gabriel] short on time. Follow up on the mailing list Packet Expiration Time in 6lo Routing Header: draft-lijo-6lo-expiration (Charlie Perkins): * New draft, for delay sensitive applications * There is some history in other WGs, e.g. 6TiSCH * Charlie presents idea on slide 3 * [Thomas] dropping a packet on expiration is one thing. Knowing how late it is of interest in a control loop. * [Pascal] on slide 4, elective header needs a size header, one bit is not enough. At this point, only a few minutes were left and Carles Gomez presented Optimized 6LoWPAN Fragment header in a nutshell. 6LoWPAN Fragment Header: * Originally motivated by some LPWAN technologies with very small paylod and no L2 fragmentation. The work was presented at LPWAN, suggested for this to be considered at 6lo * 6LoWPAN fragmentation characteristics are defined in(RFC4944) * proposed format has 2 bytes header for both first fragment and subsequent fragment. First fragment header contains datagram size, subsequent ones contain offset instead * Reodreing was considered likely in 6LoWPAN, hence the datagram size in each fragment to help decoder. Yet still possible without it. * Alllocate dispatch values for first fragment and subsequent fragments, amounting to 16 codes in the 6LoWPAN table. * Discussion of possible attacks on the receiver by exploiting the fragmentation/reassembly mechanism. Mitigation suggested * asks WG if interest? * [Carsten] great work. But is this worth 16 dispatch codes? Also problem with title "optimized ...". The first one was also optimized, only for a different set of assumptions. Less interoperability. * [Pascal Thubert] Happy to revisit the fragment work. Big picture questions need to be addressed. What do you do when you lose a fragment? What about route over mesh A stream of fragments may be creating congestion. Not just about saving a bit here and there. * [Carles] agreed. Goal was to have light weight approach. And support small L2 MTU's. Agreed for considering the big picture.