IPv6 over Neworks of Resource Controlled nodes (6lo) IETF 102, Montreal, July 17, 2018 Time: 1:30 - 3:30pm Minute takers, Jabber scribe: Ryan Hu, Rahul Jadav Chairs' slides (slides-102-6lo-chairs-slides-01) The chairs started with the agenda bashing and document status. New draft on IPv6 on PLC new proposal from Stanford U. RFC6775-update long IESG review, Pascal processed the comments, now ready for Suresh 6lo AP work in progress and 6lo-backbone-router is prepared for WGLC 6lo-nfc had a revision after more comments from the shepherd, getting ready for IESG submission 6lo-blemesh has made progress in their implementation and draft updates and 6lo-deadline-time has passed WGLC. Kerry: question on the Stanford proposal, would it more suitable to LWIG? Samita: will be presented here, not sure about LWIG Gabriel: Might have some protocol relevance, that's why it's also presented here Update also mentioned conclusion of fragmentation DT [13:39] RFC6775-update (Pascal) https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-21 Discusssed the IESG reviews. Provision enough resources to the network better definition on ROVR. Split definition and operation texts to relevant parts of the document Pascal still to check with Ekr is happy with the outcome. normative ref to a terminology that is informational (down ref). How to handle that? Terry: Talk to Suresh (AD) and he can authorize. extensive editing by Charlie. ROVR field can be over 126bits. Variable size, inferred from DAR size. No longer possible to extend with options. now size of ROVR explicitely indicated in the ICMP code. Now use RPL device can be injected into networks New term routing registrar. The Opaque field , used for InstanceID for RPL or RIFT I field indicates what the Opaque filed is about. Kerry Lynn: if you have thought about using this registration into classical ND? Erik Nordmark: tried it for years and gave up. Thought 6LoWPAN is another universe other than Wi-Fi. DAD is expensive. Pascal: Lorenzo asked for changes, which we made. Pascal: Wifi spec mandates use of ND. There is no spec for it. Sometimes takes 10 years, so we'll see. Lorenzo: How the AP processes these messages? Pascal: let's look at that. Lorenzo: Not specificed as you like. Samita: Some questions should discuss again with ADs. Pascal: Let's create all these amendaments. moving on to AP ND https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06 Ekr is happy now that we have longer ROVR >64 bits There were left-to-right right-to-left problems we solved. We fixed so the truncation is the same. aligned options to SEND, reused codes and fields. There are discussions about how we use the key. Abdulassum (on Jabber): is this implemented? Pascal: Right now we should focus on backbone now. Then give us time to do security Added an ECC variation of the RSA Signature Option from SeND (rfc3971) Mohit: we need one more iteration before being ready Pascal: we should focus on BBR first and then come back to ap-nd Move on to Backbone Router https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-06 Recent changes: R flag, clarifications. Samita: How many of you have read the draft? 4 or 5. We'd like to request volunteers for review [14:10] IPv6 Mesh over Bluetooth(R) Low Energy using IPSP (draft-ietf-6lo-blemesh-03) (Carles) https://tools.ietf.org/html/draft-ietf-6lo-blemesh-03 Take a look at the status of the doc. Previous version has been stable so it's not updated for a while First approach: using Raspberry Pis with BlueZ as its BLE stack (some issues on handling simultaneous connections. BlueZ did not work for one master (6LBR) and several slaves (6LNs) Second approach: BLEach in Contiki using CC2650 devices. made it work. Main authors of BLEach now co-author: Michael Spork and Carlos Alberto Boano As a result, a 6LoWPAN over BLE ND setup is tested. Setup starts with the 6LBR running as a IPSP router, and other 6LR/LN nodes are not initialized. At last, link layer connections are established. Pascal: is it layer 2 or layer 3 mesh? Carles: IP routing. Routing protocol not specified, left open in the draft. In the related Bluetooth SIG work, RFC7668 assumes link-layer connection over BLE. Samita: this is WG document. Do you think we eneed to revise it more? Carles: getting more feedback would be great. Also advance implementation to get experience with it. [14:23] 6lo Applicability (slides-102-6lo-6lo-applicability-00) (Yong-Geun Hong) this document is informational, intended at new adopters of 6lo. Two parts were deleted: LTE-MTC (as it supports IPv6 transmissions), 6lo-PLC ref (expired). Hope 6lo-PLC to be adopted as a WG. Updated HomePlug Powerline Alliance section. [14:28] IPv6-over-NFC (slides-102-6lo-ipv6-over-nfc-00) (Younghwan Choi) version -10 of the draft. no feedback from NFC Forum since Jan 2017! shepherd review (Samita) July 2018. Shepherd's comments were addressed: MTU, link description, Frag and Reassembly, Security considerations. Chairs decided to go for a one-week WGLC. Will start soon. Please provide comments. [14:34] IPv6-over-PLC (slides-102-6lo-ipv6-over-plc-00) (Remy Bing Liu) recently added IEEE 1901.1 (published May 2018) in scope of this draft Address auto-configuration and mapping mechanism addressed. IEEE 1901.1 has various new features. Kerry Lynn: is this for link-local or routable traffic? It can be used for multiple link traffic, routable is ok. Kerry: beware of exposing IID in routable traffic, might wish to follow 6lowbac for privacy considerations MAY use ODAD (RFC4429) Included RFC6775-update new features to PLC devices Believe draft is ready, Will call for WG adoption Samita: We need more people to read the draft for WG adoption. Please read the draft and send comments through the mailing list. [14:46] 6lo Fragment Recovery (slides-102-6lo-6lo-fragment-recovery-00) (Pascal) https://tools.ietf.org/html/draft-watteyne-6lo-minimal-fragment-01 https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-08 The "minimal" draft highlights limits of VRB (virt reassembly buffer) two parts: how to forward fragments, how to recover them Recovery: uses a bitmap indicating which fragments were received. Introduced windowing for congestion control. IP addresses compressed with knowledge of MAC address does not work at all hops. Creates change in fragment size. Need slack. Rahul: implementing this in ? (Contiki?) Pascal: You put slack in the first(?) fragment. Yes, I think we should mandate it. [14:52] 6lo fragmentation DT (Thomas presenting remotely) (slides-102-6lo-6lo-minimal-frag-00) 3 drafts, one at LWIG and two at 6lo. Design Team to be closed after adoption. The draft at lwig is adopted, the two at 6lo not adopted yet. will request adoption Gabriel: anybody objects to asking for adoption? none Gabriel: will be confirmed on the mailing list but want to get a sense in the room. Raise hand if in favor of adoption. Saw 15ish (good propostion of attendance in the room) I think we are gonna go ahead. Samita: for the record, no objection in the room. [14:56] Design Considerations for Low Power Internet Protocols (Hudson Ayers) (slides-102-6lo-design-considerations-for-low-power-internet-protocols-00) draft is available, see agenda Motivation: Interoperabililty is crucial for 6LoWPAN Contiki, ARM mbed, Riot, TinyOS, openthread An informational I-D is prepared for this. From the 6LoWPAN interoperability study, many(?) features are found mismatched. believes that device hw constraints are predominant cause for non-implemented features or incomplete implementations evidence found in source code comments Embedded OS's implementations vary a lot, in terms of power, code size, etc. Power consumption (on the radio devices) can be reduced at the PHY and MAC for example. The cost is the need for compute power, usage of RAM, etc. Guideline 1: no silent drop. Explicit mechanism to tell why packet was rejected. ICMPv6 or 6LoWPAN ND message. Guideline 2: advertise capability. Suggest a strucutre of 6LoWPAN features with six classes. Lower classes have more energy saving. Higher classes add more flexibility. Guideline 3: reasonnable bounds on assumptions for RAM/Code needed. Guideline 4: dont break layering disallow the UDP checksum elision in RFC6282(TinyOS is the only one that implemented UDP checksum elision). Pascal: regarding advertising capabilites, there are bits available in 6LoWPAN ND Pascal: more difficult is to provide interop info. Pascal: some other systems do UDP checksum elision. Hudson: There are classes of devices . Lower devices classes will implement lower classes of features. Only the more capable devices will take up the larger code sizes required to implement all the features. Gabriel: really interesting document, survey, design considerations. In the real world, they may take some hints from an RFC but won't adopt it all. No garantee that device manufacturers will comply with what we write. Phil Levis: is that what we want the 6LoWPAN to be? We could think about. Samita: (Chairs) thank you for doing this work from your team and coming up with the possible solution. Idea of having the capabilities is great. Maybe it could be used for some applications. Pascal: If the 6LoWPAN would be ended up with the open-source implementation, that's okay. Pascal (responding to Phil) a big of list of choices as silos, I don't believe the nodes would talk to each other just like this. Gabriel: is there anything simpler we could do to help people understand what to implement so that it works interoperably Thomas: it's much more than 6LoWPAN that makes things talk to each other. Terry: I really like the ICMP idea. Learn from IETF BGP efforts. Coming back with running code and solid docs will be good. IETF has lots of experience at protocols for advertising/discovering capabilities. Learn from that. Samita (responding to Pascal): charter of this WG not just header compression, but any improvment to IPv6 protocols for constrained environmenets. Thomas: F-interop platform for interop tests. Try 6TiSCH or 6LoWPAN interoperability test. [15:34] meeting adjourns