IETF 101 6lo Working Group meeting, London, UK Chairs: Gabriel Montenegro and Samita Chakrabarti Date: March 22, 2018 Minute taker: Dominique Barthel Agenda * Introduction and draft status Montenegro/Chakrabarti 10 min Agenda bashing; blue sheets; scribe; Jabber scribe * An Update on 6LoWPAN ND IESG review Pascal Thubert https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-14 15 min Discuss updates on RUID size and security length https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06 10 min WGLC Preparation and update: https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-06 05 min * 6lo NFC draft WG LC status update https://tools.ietf.org/wg/6lo/draft-ietf-6lo-nfc-09 Younghwan Choi 10 min * Update on 6lowPAN Routing header lifetime Charlie Perkins https://tools.ietf.org/html/draft-ietf-6lo-deadline-time 10 min * 6lo Applicability and Use Cases Updates Yong-Geun Hong 10 min https://tools.ietf.org/html/draft-ietf-6lo-use-cases-04 * Fragmentation Design team formation Update (DT Lead: Thomas Watteyne): Goal, overview and Status of the progress Thomas Watteyne 10 min draft-watteyne-6lo-minimal-fragment Carsten Bormann 10 min draft-thubert-6lo-fragment-recovery Pascal Thubert 10 min Q&A 10 min * Information sharing to 6lo WG: draft-thubert-roll-unaware-leaves-03 Pascal Thubert 05 min * IETF Hackathon Alain Rebault 05 min Total: 115 min [13:30] * status of the drafts * Fragmentation Design Team. lead by Thomas. Good progress * 6lo information page. looking for volunteers. * Carsten: came out in class, looking for something like cbor.io. Low effort to run. It's on GitHub, people contribute through Pull Requests. * Samita: volunteers, please contact the chairs * T2TRG side meeting, protocol interaction issues on the wire * 6lo plugtest on F-interop platform. [13:44] Drafts revolving ND improvements (Pascal) * Factory sensor networks. Devices move beween DODAGs, without renumbering nor redoing association. * group of 3 documents: 6775 update, protection of address against theft, federation of 6lo meshes over a backbone that runs classical ND * draft-ietf-6lo-rfc6775-update-14: changes since IESG review: * length other than 2 because of cryptographic token (Registration Ownership Verifier). * R flag: tells this node is a host, not a router. * Transaction ID: counter that allows for roaming. When several messages are received from different DODAGs, which one is the new one. * Registration Lifetime * Registration Ownership Verifier: this is no longer a EUI-64 (privacy issue). The real need is just to associate a device to a claimed address. * message flow diagam shows bootstrap of network. * now "Extended ARO" option * IESG review feedback: * use of EUI64 discouraged, should it be deprecated? * what happens when registry is full? (could be an attack) * what is the minimum number of addresses? * Dave Thaler: Eviction not possbile for addresses entrered through ARO. Is it a 6lo or 6man problem * Erik: only occurs with 6lo. * Dave: Therefore needs to be addressed in this WG. * Dave: min number of addresses? 2 or higher. * Pascal: need link local address, global based on EUI64 (used for registratino), global based on non-revealing IID. So at least 3. * Dave: about 10. If multiple subnets, a few 10s. * Pascal: 3 is good enough for constrained network. * Suresh: Support for MUST 3, Support for SHOULD 10 * Suresh: Transaction ID: unconfortable with the text. It says compatible with RPL and copies the RPL text. Pick one, either a reference or a copy. * Pascal: was initially a pointer to 6550, changed it to a copy. * Suresh: fine, keep the text but dont say it's from 6550. * Gabriel (from the floor): hoping we do this independant of RPL. Should be self-contained, ie. copy-paste without reference to RPL. * Erik: agree with self-contained, but suggest to say " at the time of this writing, this algorithm was identical to RPL". * Erik: state the origin, and let know what happens if RPL changes. * Pascal concludes: will copy text and not say its identical to 6550. * draft-ietf-6lo-ap-nd-06: C flag to say it contains crypto-ID. * reused second NS but with other options (CIPO and NPSO, derived from existing options) * algorithm was higly compute-intendive on the device. Iterate SHA until reached predertimend value of a few bits. * Spec no longer mandates that. For more security, use longer key. * Mohit: would make sense to make it longer, how much: 128 and leave it there? not a lot of deployment experience * Pascal length limited to 256 by length filed. Is it enough? * remember that DAR doesn' t have options, therefore no option length. Only way to infer size of key is length of DAR. Will not be able to add anything else. * * Pascal: is there opposition to document xxx ? * Samita: premature to ask for feedback at this time. Bring it to the list. * Pascal: for AP-ND, we need more work. * Samita: agreed, needs more discussion. * Pascal moves on to unaware-leaf draft. * Carsten: use internet technology. Host. * Pascal: leaf Defined in 6550. * Carsten: this is not ROLL meeting. * Pascal: look at the slide or come to the meeting tomorrow morning draft-ietf-6lo-backbone-router-06: There was no real changes on this draft since last IETF - so it was skipped due to time crunch. * 6lo NFC draft WG LC status update (Younghwan Choi , ETRI) * got 3 reviews. Now in WGLC. * Gabriel: please provide comment, including simply positive acks. This is useful. * Update on 6lowPAN Routing header lifetime Charlie Perkins * Header informs about deadline time for delivery. If not reached, can drop the packet. Maybe also rush delivery if approaching deadline * doc has been around for a year. Improved to include ASN, header compression * Implementation is OpenWSN. * Drop flag changed from SHOULD to MUST. * Think doc is ready, would appreciate more review. Approaching WGLC [14:45] * 6lo Applicability and Use Cases Updates Yong-Geun Hong * reiterates goal of document: help newcomer understand, help adaptation for L2 technnologies. * added G3-PLC scenario, updated MSTP. * now 7 technologies + 1 potential new one (LTE-M, will be removed from next revision since no IPv6 adaptation layer is needed). * goes through technologies and use cases. * believes draft is stable. Add more use cases? * Gabriel (from the floor): like the idea of removing stuff that does not belong at 6lo, such as LTE-M. What about Netricity? * Yong-Geun: this is PLC. * Bob: Netricity is now part of WiSUN. [14:54] * 6lo fragmentation design team (Thomas Watteyne) * Created at last IETF meeting - Team members are: Thomas Watteney, Carsten Bormann, Rahul Jadav, Pascal Thubert, Gorry Fairhurst, Gabriel Montenegro Problem statement * Original RFC 4944 proposed per-hop reassembly has problems (latency, reliability). * There are a few proposals to do fragment forwarding (Carsten, Pascal) * The goal of DT is to produce 2 documents: * informatinoal document to summarize state of the art, dicuss the limitations * proposed solution, normative draft-watteyne-6lo-minimal-fragment Carsten * Virtual Reassembly Buffer: not store data longer than you absolutely have to. Forward early. * still need buffer space for a few fragment, for Medium Access. * may have to wait for first few fragments if routing header is big * header increasing over route: put slack in first header, to accomdate for expansion. * Yasuyuki shows simulation results, comparing 4944 and minimal-fragment * contact him for more details * Samita (chair hat off): Which situation justifies one algorithm over the other? * Thomas: With infinite memory, doesn't make a difference. But with memory limitation, 4944 quickly looses packets. * Plan is to have 2 fragmentation 6lo documents and 1 lwig document for the implementation part. [15:12] draft-thubert-6lo-fragment-recovery Pascal Thubert * Main update is change in title : over the 10 years, things have evolved. Forwarding no longer in. Now only about Fragment Recovery * Forming forward and return pathes. Needs two of the VRBs described in Carsten's draft. * Bitmap in ACK, each bit acknowledges an individual fragment. * End to end signalling allows to sned abort condition and clean state along the path. [15:18] * Gabriel: Thanks to the Design Team, providing good answers. * Gabriel: Does the DT want to address other issues? * Carsten: the regular WG work now starts based on these 3 drafts, they are not final. * Thomas: Some work to be done on the first 6lo doc. Let's not close the DT now. * Thomas: should we call for WG adoption or is this too early? * Suresh: regular process. Deliver the 3 docs, then ask for WG adoption [15:22] 6lo interop F-interop project Benjamin T/Alain Rebault * KEREVAL lab 6lo interop plugtest is involved with European project F-interop which aims to develop and interoperability testing platform with WPAN * Benjamin and Alain participated in IETF hackathon with interop tests for RFC4944, RFC6282 and RFC6775 * F-interop provide secure channel between two remote devices, and provides conformance analysis tool. * Aims at reducing cost of interop * Thomas: Phy layers? * Ben: 15.4 24. GHz * Rasbian, card plugged on Raspberry. * Samita: next time, please announce early so that peaple can make plans to attend the event AOB ? none [15:25] meeting ends