6lo WG,IETF 98 Meeting Minutes Chairs: Samita Chakrabarti, Gabriel Montenegro Secretary: James Woodyatt Responsible AD: Suresh Krishnan Technical Advisor: Ralph Droms Minute takers: Dominique Barthel Jabber scribe: Ines Robles March 29, 2017 Chicago, USA 6lo Chairs like to thank Dominique Barthel for note taking and Ines Robles for being jabber scribe. ------------------------------- meeting notes ------------------------------------------- 1. Introduction and draft status are provided by the chairs. Gabriel Montenegro went through the drafts one by one: 4 new RFCs since the last IETF.They are, RFC 7973 (draft-ietf-6lo-ethertype-request) RFC 8025 (draft-ietf-6lo-paging-dispatch) RFC 8065 (draft-ietf-6lo-privacy-considerations) RFC 8066 (draft-ietf-6lo-dispatch-iana-registry) The documents that are in IESG processing are: draft-ietf-6lo-dect-ule (AUTH 48) draft-ietf-6lo-6lobac-06 (RFC Editor's Queue) draft-kivinen-802-15-ie (RFC editor's queue) Suresh (AD) mentions IE(information element) has been allocated by IEEE. There will be a minor update of the draft before publishing. Newly adopted drafts are: draft-ietf-6lo-rfc6775-update draft-ietf-6lo-use-cases * draft-ietf-6lo-mesh-link-establishment: No more interest from originating group, ZigBee NAN/Jupiter Mesh. The chairs are going to drop the document from the 6lo WG after confirming it on the mailing list and verifying with the co-authors. 2 IPv6 over NFC Younghwan Choi https://tools.ietf.org/wg/6lo/draft-ietf-6lo-nfc-06 was presented by Younghawn Choi on updates and discussed comments from WG and NFC forum. The draft was reviewed by NFC forum, no more comments from NFC forum. The author likes to move to WGLC. Dave Thaler:IID generation changed as a result of previous meeting Pascal: Replacing 6 bit address with hashing function with fixed parameters. Scanning is still easy. How is it different? YC: offset. Dave: offset should be random to add entropy, not predictable. Gabriel: offset may not be a right name. Nonce would be better. Samita: need reviewers before WGLC. Pascal, Dave, would you volunteer? Pascal will do the reivew and Dave agreeed to review the final update. 3 IPv6 over Bluetooth Low Energy Mesh Networks Carles Gomez https://tools.ietf.org/html/draft-ietf-6lo-blemesh-02 Main updates: 6LN replaced by host. Clarification in header compression section. Implementation started. Compared to RFC7668 (IPv6 over BTLE), ND and HC need to be extended. Suresh: follow-up from BT SIG? Gabriel: yes. "mesh" name overload. Confirmed we don't need anything else from them to support this. Samita: clarify "host" and "6LN" distinction in the slide deck Hannes: draft refers to 4.1. But BT also works on a mesh. Gabriel: Absolutely, another mesh. Hannes: better to run IPv6 over their mesh? Gbriel: This is route-over. They're doing mesh-under. Kerry: Need supporting work from BT SIG? Gabriel: Nothingn new needed, this was confirmed by BT SIG. 4 6lo Applicability and Use Cases Yong-Geun Hong https://tools.ietf.org/html/draft-ietf-6lo-use-cases Update since IETF97: added one technology, 3 use cases, 2 authors. Now 8 link layer technologies. Possible LTE-MTC will be added. Gabriel: nobody working on LTE-MTC in this Group. We should limit ourselves, otherwise this dcument can grow indefinitely. YGH: Will be discussed tomorrow morning with LPWAN chairs. Alex Pelov: Explain the LTE-MTC for LoRa. YGH: backhaul for LoRa (nano?) gateway. The Yong-Geun continues with his questions, comments on the documents. Reviews comments were received from Samita. It restates goals for this document. next steps: work on comments. Discussion on whether LPWAN technologies belong to this draft. Security considerations, for each case or global? Suresh: repeat on question at previous meeting. IESG statement against this document. What is the archival value at this? Will be outdated quickly. This could go to the IESG and not get published. Could go to a Wiki, etc. Gabriel: Share that concern. One way to move forward would be to write security consideration to reduce the scope. Point at existing security considerations in other RFCs. Samita: Also had similar feeling that it would not pass IESG in its current form. Though it is good to have guidelines to pass on to non-IETF people. We also requested WiSun and Jupiter mesh to provide material. Document should be concise and to the point. She can help Yong-Geun to edit the document to reduce the content and define the scope. 5 An Update to 6LoWPAN ND Pascal Thubert https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-01 https://tools.ietf.org/html/draft-ietf-6lo-ap-nd/ https://tools.ietf.org/html/draft-ietf-6lo-backbone-router/ Summary update: A set of 3 documents that work together on improving 6LoWPAN ND. 6lo-ap-nd registers address on first-come first-served basis, avoiding identity stealing. Splits two functionalities into two documents (extended ARO and proxy registration) Behcet: ??? Authors think the work is stable, implemented, tested at ETSI interop. Suggest in-depth review and WGLC. [ Pascal might be referring to rfc-6775-update and backbone-router drafts] Suresh: Not much in the way of comparison with other mechanisms. "better that SeND". Suggest to write a generic update document. Roadmap in this space is already very confusing. Difficult for people to figure out what to do. Suresh: want ot have the WG to have a discussion Erik N: Down the road, 6775-bis would be greater. In the meantime, better to have independant documents on each tweek for people to consider and express interest in. If put together too early, wil be more difficult to gauge what people agree on. Suresh: fine. But at some point, want to have clarity. Pascal: ok. But split documents makes it easier for other groups (securiy, ..) to review what they are interested in. Samita (asking Suresh): should the 3 docs be folded in one? Seems backbone should stay separate. Suresh: This is going to update 6775. Meaning of update is unclear (see also, replaces, ...). Need some clarity. Lorenzo: Applicability of 6lowpan-nd: specific to some link types, not general about 6lowpan. RFC7934 says ... "Some link types may have requirements that override general recommendations". Unless explicitly stated, this document may violate RFC 7934 recommendations. Pascal: Will reference the RFC and general recommendations, and leave decision open to particular link technology. Device registers and then moves. ARO is not a request. Suresh: PIO + Administrative stuff, Can we agree? Erik: Registration and DAD parts. We should figure out some clarifying text and make the intent clear * Lorenzo: * Pascal: If remove text about administrative stuff, will that solve the problem? * Lorenzo: defining way for network to say no, could cause a denial attack. * Pascal: if node moves, requests DAD from new place. We need to be able to remove state from first LBR. * Lorenzo: Problem is lots of codes (for negative answers). * Suresh: Loreenzo, don't take things too litterally. It is not like a request to get an address * Lorenzo: This would cover 802.11, if you read it. * Erik: should figure out some text to make clear that this should net be used to admistratively deny nodes to form an address. * Christian Huitema: privacy issue with addresses. Randomness in the address should not be prevented by AR mechanism. Compression for private addresses ? * Pascal: It can register anything. * Christian: Anything that reduces the space of allowed IIDs creates privacy issues. * Lorenzo: Doing ARO requests the network to provide service for you. If DAD fails because of, e.g. neighbor cache full, is the address still valid? Draws the line about what is a request and what is not. * Suresh: If node has 6lowpan ND and classic ND, node can still carry on with classic ND if ARO fails. Otherwise, cannot continue. * Lorezo: Do we know that 6lowpan ND and classic ND work together? * Suresh: No. Today, this is considered separate. IPv6 discussed efficient-nd some time ago, in order to address the interoperability between 6lowpan-nd style network and Classic ND. * Dave: support Erik's comment.It (ARO) is treated similar to DAD. Add a text to say that should not be used to deny service. * Erik: This solution should help host to go to sleep, not prevent privacy. * Suresh: regarding mixed stuff, will discuss it at 6man. Not in scope for 6lo. * Gabriel (chair): we already had this discussion in Seoul. Make concerted effort to have text in place by Prague. Maybe a small design team. * Samita: we need reviewers for the 3 drafts, but after the authors and Lorenzo, Suresh, ... haved worked on the new text. 6 Packet Expiration Time in 6lo Routing Header Charlie Perkins https://www.ietf.org/id/draft-lijo-6lo-expiration-time-01.txt The goal is to be able to remove fragments from buffer if there are no longer useful. It is a delay-aware operation. Decided to have elective header with origination time and expiration time. Potentially in different time units. The discussion goes through frame format. Gabriel: user-defined field value. How do you ensure interop? Charlie: don't have an answer.Systems may have different time systems. It needs a few editorial changes. Compressed time, should be care for ASN to better work with 6TiSCH? Kerry: time units. Hours? Charlie: The way it is, able to express pretty large values. Pascal: intent to use this mechanism to e.g. influence routing? This is a routing header. Charlie: could be, e.g. for voice traffic. Chairs: Who's read the draft? about 6. Samita: Please, read and provide comments. 7 Transmission of IPv6 Packets over PLC Networks Jiangquiang Huo https://tools.ietf.org/html/draft-huo-6lo-plc-00 First presentation of this draft. The presenter goes through brief intro to PLC. Several standards, some with MTU>1280, some with MTU<1280 The draft distinguishes cases, provides specification for fragmentation, header compression, L2 mesh header Future work: include more PLC standards? Received comments from Samita and will update based on comments. Daniel Popa pointed at his expired draft on G3. Samita: Mesh connectivity diagram. Does PLC also support extended mesh? JH: this is an example. More topologies are possible. Like interconnected diamonds. Gabriel: two SDOs specifiying the link technology: one is ITU, one is IEEE. Do you work with tehm? Are they aware of this work? JH: indirect relations. Gabriel: we can help you establishing official relationship. Samita: We will help in connecting 8 Fragmentation in 6lo networks Samita: There are several contributions related to fragmentation in 6lo WG. Within the next 20-30 min, will have two presentations in order to discuss 6lo fragmentation issues and we seek WG opinions on whether the WG needs to work on the fragmentation issues and solutions. Updates to the FRAG draft Pascal Thubert Long history. Experiment in 6LoWPAN. 6TiSCH has fragments. Need for this work. Juergen developped MIB to investigate slow 6LoWPAN network and discovered related to fragmentation/ressaembly. Julius xxx: have you considered ... ? Pascal: In mesh, fragments can follow different routes. An intermediate node may not receive all fragments even if everything is right. He goes through various issues with fragment forwarding. * proposes to remember some state from first fragment so that following fragments follow the same route. * explains forwarding strategies, optmisation. Label switching. * needs to clean-up state at intermediate nodes. Timeout or protocol. Julius: why do you need state? why not just blindly forward them? Pascal: First fragment has IP address. Need state so that next fragment follows the same route. L2 switching doesn't have this issue. we need a protocol, this cannot be solve by smart implementation Gabriel: Spell out which problems occur in route-over vs. mesh-under, with large packets vs. small, with fragments vs. packets. Pascal: This is a solution document for fragments in route-over mesh network. Not a requirement document. Not attempting to say why.That would be another document. Thomas W (remote): Without fragmentation, 6lowpan is almost unusable. Problems appear as soon as ou start fragmenting, even with small packets. Most implementation just drops fragments as their buffers fill up. Small memory. Buffer for one packet is over a Kbyte.Implementation will drop fragments of one packet as soon it receives a fragment belonging to another packet. Gabriel: I was asking about scoping the problem, not against the solution. Michael R: This work changes behaviour in all nodes of networks. What if some devices are slightly more capable than others? Thomas: confirm that netwrok can run with nodes that do and nodes that don't implement this? Pascal: yes. Confirmed. Ralph Droms: Transport area review is needed in order to make sure there is no transport layer issues due to many fragments of the same packet Pascal: this presentation not about my draft. Ralph: have you done fragment retransmission work? Pascal: yes Samita: we're going to ask Suresh for recommendation for Transport area experts' review Carsten: Been discussing this for 8 years. Allocate time to do this. However, already solutions out there. Thomas says they are bad implementations out there. Can we fix the problems in the code or in the protocol? * Pascal: Protocol * Carsten: different views on the subject. * Suresh: if WG interested in this work, will get somebody from Transport to do a review. But more, define a cluster of problem, at next meeting will meet in a room to work on the problem. * chairs: How many people willing to work on fragmentation issues and solutions? count: 18 people 9 Optimized 6LoWPAN Fragmentation Header Carles Gomez https://www.ietf.org/id/draft-gomez-6lo-optimized-fragmentation-header-00 Reminds 4944 state of the art, L2 technology constraints. Describes proposal: fragment format. Requires allocating 16 dispatch values. This addresses compression of Fragmentation header Interest in WG? Suresh: how does the recipient know how much buffer it needs on receiving the first fragment? Carles: Not thought through yet. Suresh: Not just heuristic. Need to fail gracefully. Gabriel: Discussed this before. Carles: Maybe these points not so much an issue in some scenarios. Need feedback. Gabriel: who has read the draft? 5-6. Gabriel: not sure this belongs in this WG. Will open it to the mailing list. 10 IEEE 802.15.4 and related standards update Pat Kinney A repeat of presentation done at 6TiSCH meeting yesterday. How IEEE works: amendments, revisions, corrigenda. 15.4q: not interopoerable with other modulation modes. Most standards are coming out of 15.4 now have 2047 bytes MTUs, not just 127. Corrigendum on 64-bit MAC address transmission order: was changed in 15.4-2015 to match Ethernet etc but broke 15.4. Changing it back. Next revision (incorporating corrigenda and amendments), approval anticipated May 2019 . If you see corrections needed, send them now. 15.9 Key Management Protocol. Includes general purpose multiplex mechanism. Adds another fragmentation mechanism. 15.10: Layer 2 routing. See link to tutorial in the slides. 15.12: upper layer interface for 15.4. 28 parameters to request a dataframe be sent with 15.4 (ethernet 4, 802.11 6). Simplfying this to maybe 6. also adds object management. Configuration: will define profiles. Makes it easier to switch configurations for different applications. Yand data models and Netconf. Netwrok management: Netconf. Pat calls for participation and reviews. Conference call, phycical meetings and conference. 11 6lo Plugfest interest and discussion Due to time constraints this discussion was skipped. Samita requested WG to contact 6lo-chairs, Carsten and Kerry for Prague 6lo Plugtest participation. end of meeting