6lo WG Agenda - IETF 105, Montreal 13:30-15:30 @Sainte-Catherine Monday, July 22, 2019 Chairs: Shwetha Bhandari, Carles Gomez Responsible AD: Suresh Krishnan Minute takers: Dominique Barthel Jabber scribe: Shwetha Bhandari Meetecho for remote participants: https://www.meetecho.com/ietf105/6lo Etherpad for notes: https://etherpad.ietf.org/p/notes-ietf-105-6lo?useMonospaceFont=true -------------------------------------------------------------- Introduction and draft status Bhandari/Gomez 10 min Agenda bashing; blue sheets; scribe; Jabber scribe Revisions after IESG evaluation: IPv6 over NFC Younghwan Choi 10 min https://tools.ietf.org/html/draft-ietf-6lo-nfc-15 Status of Fragmentation drafts Pascal Thubert 10 min https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-02 https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-04 Status and next steps of Applicability and Use Cases draft Yong-Geun Hong 5 min https://tools.ietf.org/html/draft-ietf-6lo-use-cases-06 Presentation of proposed maintenance scheme for RFC 8505 Pascal Thubert 15 min https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-03 ND Unicast Lookup - Assess interest in 6lo Pascal Thubert 15 min https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup-00 Initial version of new HC (Asymmetric IPv6 for IoT Networks) Brian Carpenter 20 min https://tools.ietf.org/html/draft-jiang-asymmetric-ipv6-00 Revisions after IESG evaluation: deadline time Charlie Perkins 10 min https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-05 Total: 95 min -------------------------------------------------------------- Meeting notes [13:32] Introduction and draft status Bhandari/Gomez 10 min Note takers Jabber scribe: N/A Note Well Agenda bashing: some presentations re-ordered. Added 5 minutes to Pascal's ND presentations. No comment. blue sheets Status report * -deadline and -nfc in IESG processing * -ap-nd submitted but not evaluated by the IESG yet * -fragment-recovery and -minimal-fragment: shepherd review done, new draft versions issued today, which address shepherd comments * -ipv6-over-plc, no update since last IETF, news? Author, on the mic: will update after this meeting and come back to the mailing list [13:41] Revisions after IESG evaluation: IPv6 over NFC Younghwan Choi 10 min https://tools.ietf.org/html/draft-ietf-6lo-nfc-15 goes through history of the draft. as a response to IESG reviews * removed "marketing" language * MAY, MUST language * improved some figures. * Security section reshuffled, improved, some text removed [13:45] Status of Fragmentation drafts Pascal Thubert 10 min https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-02 https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-04 overview of fragmentation work done in the past and present at 6LoWPAN, 6lo. how to forward the fragments over multiple hops without reassembling them at each hop. -minimal does not change the fragmentation format, just the buffering in intermediary nodes drawback is if fragments are lost, the whole process stalls. with -fragment-recovery, retries. describes changes on -minimal after reviews. Clarified that routing is only done of first fragment, next fragments are labelled -fragment-recovery has bitmap, one bit per fragment. This draft extends -minimal. (used to stay "update", now "extends"). Added IANA section Suresh: "update tag" is an issue all over the IETF. Writing a draft right now to better define this. Suresh: draft will be out in the next days. Use it to explain your update. Pascal: -fragment-recovery is self sufficient, that's why we believe it extends. [13:57] Status and next steps of Applicability and Use Cases draft Yong-Geun Hong 5 min https://tools.ietf.org/html/draft-ietf-6lo-use-cases-06 Draft not updated since last meeting. However, still willing to do so. Goes through expected next steps. - scope, consistency - technologies considered: add 15.4e? - remove Section 5.1 Pascal: 15.4e is now fully merged into 15.4. No reason to mention 15.4e anymore Pascal: 15.4g Carles (as a co-author): question of 6lo technologies is tricky. 15.4e wrapped into 15.4, but we don't mean to address all 15.4 technologies. Shwetha: how do you want to progress from here? Yong-Geun: work with co-authors, then ask WG feedback, then LC. [14:04] Presentation of proposed maintenance scheme for RFC 8505 Pascal Thubert 15 min https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-03 Was elaborated based on work done here, but draft submitted at 6man. Gives overview. RFC6775 is about registering an address. 8505 describes association. Need for protecting against an attacker registering the same address, and claim the traffic. Backbone router does ND proxy for registration process. Analoguous to WiFi bridging in ESS (multiple APs) Address protection draft (-ap-nd) is homologuous to SeND (Secure ND). Protects the ownership of the address, at the router. Provides Source Address Validation, proving the ownership with the possession of a crypto token. This all basically rebuilds an ESS at layer 3. -unicast-lookup extends the DAD onto the backbone. Any node can query the Map resolver. This is on the wire. This draft could go to 6man. Will be presented at 6man tomorrow as well. -6man-ipv6-over-wireless is destined at 6man, to show them the whole story. Draft explains need for upgrading ND. Links are nore subnets. Subnets of thousands of devices. Need to avoid broadcast on those large fabrics. Explains the drawbacks of broadcast. PHY behaves differently when broadcasting. Fast Roaming (.11r): reports may arrive out of order, resulting in wrong location determination Fast Intial Link Setup (.11ai) prepopulates entry on DAD request. Link with radios? when node A is in broadcast domain of B and B is in braodcast domain of A. Even RFC8200 is not clear on wireless links. Hub&Spoke subnet model: central router does DAD and lookup and 1-hop forwarding. Mesh subnet: 6775 does DAD, routing with RPL. Heterogeneous multilink subnet: e.g. WiFi (hub&spoke on one side and 6TiSCH (mesh) on the other side. Shwetha: what do you need from this group? Pascal: general approval, then maintenance at 6man. Shwetha: implication on other drafts at 6lo? Pascal: generalisation to multiple interface Suresh (as contributor): hard to address is backward compatibilty. For those who use 6775 now. Suresh: maintenance of draft published in 6lo stays in 6lo. Will be taken into consideration before closing 6lo WG. Suresh: 6lo looks at the "constrained nodes cluster" aspects, and 6man will look at it with another perspective (operational, etc) Samita: agree with Suresh. You will have easier time in 6lo. Pascal: but if want to extend it to different links, will have to go to 6man. [14:40] ND Unicast Lookup - Assess interest in 6lo Pascal Thubert 15 min https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup-00 It's about scaling the backbone infrastructure. ND causes broadcast storms, which is a problem even on wired backbone. Key problem is to know where each IP address is. Time to do it right, with a registration protocol and centralised info. Map server talks LISP, hosts don't. The more nodes do registration and lookup, the less broadcasts on the network. Adding a 6LBR on the backbone to share address registration. 6lo method applied to wired network. Goes through message exchange diagram. First multicast goes to AP, which does not broadcast is back, goes straight to L3. In mixed environment (with registered nodes and no-registered nodes), still need to do DAD after lookup. Involves extendeing the DAR/DAC because now occurs between BBR and 6LBR. Shwetha: where do you want this work to happen? Pascal: anywhere as long as it moves forward. Will be presented at 6man, in much shorter form. [14:50] Initial version of new HC (Asymmetric IPv6 for IoT Networks) Brian Carpenter 20 min https://tools.ietf.org/html/draft-jiang-asymmetric-ipv6-00 Brian goes through rationale for this work: constrained links, and memory-constrained edge routers. Want ot avoid compression/decompression algorithms (because of CPU cyles and memory requirement). Suggests using shorter addresses. Compatibility with other mechanisms to be evaluated. "flexible header encoding" means headers have variable size. Address length could be preconfigured, or configured by router, of even negociated between peer node. RA-PIO modification proposal to tell address length. Language in the draft needs to be made more specific and accurate. Proposes to use a new dispatch value in 6LoWPAN, or new flexible header (starting with FHE octet) Laurent Toutain: SCHC compression mechanism at LPWAN, need to talk together. Suresh: mis-alignement. Isn't that a problem in C implementation? Come to side discussion at Notre-Dame room on Wedn 8:30 Guangpeng Li (co-author): use case with supermarket <>. SCHC and 6LoWPAN require compression/decompression. Brian: reckon use-cases need to be better defined in draft. Pascal: this is the right place for this work. Years of experience. Pascal: also look at RFC8138. Same kind of processing. Don't reject other people's work just because it's "compression". Pascal: source routing header also needs address compression. Pascal: don't see what you need that current work doesn't already do. Pascal: "adaptation layer" vs "compression" is fallacy. Carles (as a participant): evaluated benefit of avoiding compression/decompression? Sheng Jiang: 6LoWPAN does compression/decompression at every hop. Want to go through whole domain without decompression. Pascal: this is behavior, not format. So far, presentation has shown format. Pascal: with 8138, we can process the packets in the compressed format. What you require is already possible Sheng: could agree. But 6LoWPAN framework is complicated. This could be said to be a simplified 6LoWPAN. We care that nodes can do this in a simple way. Pascal: could have a simpler behavior, or subset of behavior, without changing the format. Look at 8138, as a starting point. Guangpeng: assume address length can be configured at deploment Shwetha: please provide a section in the draft that compares with what already exists Suresh (as AD): rationale, use-case, comparison. This need to be all in the draft. [15:16] Revisions after IESG evaluation: deadline time Charlie Perkins (remote) 10 min https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-05 Reminds of the purpose of the draft, history. Current status is 3 DISCUSS in IESG review, 1 YES, 8 NO_OBJECTIONS. Suresh: haven't seen your response to Alissa's DISCUSS. If you provided by mail or in draft change, indicate what/where are the changes related to her comments. Charlie: will check and provide info. Charlie goes through draft updates, describes format Carsten: this slides says OTL where it should say OTD. Charlie: will check that. Chairs: any comments? No comments in the room. Chairs: we expect to see your response to Alissa, and take it from there. [15:29] Meeting adjourns