6lo WG Agenda - IETF 94, Yokohama, Japan 09:00-11:30 Local Time Thursday, November 5, 2015 Room 501 Chairs: Samita Chakrabarti, Gabriel Montenegro Secretary: James Woodyatt Responsible AD: Brian Haberman Technical Advisor: Ralph Droms Minute taking: Robert Cragie and Dominique Barthel (Etherpad) ---------------------------------------------- [9:01] Introduction and draft status Montenegro/Chakrabarti 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Gabriel: since Prague, published RFC7668 (IPv6 over BTLE), adopted D Thaler's privacy considerations draft, IPR disclosure on -6lo-nfc, Dect-ule draft through WGLC, 3 drafts entering adoption call. ETSI plugtest after this IETF meeting Samita reminds of 6lo-use-case document, in progress. Requirements by Pascal on RFC6775 update, will have an un-official last call. Questions? Charlie Perkins: time for 802.15 on LLC? If no time, could presentation be made available online? Gabriel: won't there be a presentation at interea? Charlie: yes, also at 6TiSCH. https://www.ietf.org/proceedings/94/slides/slides-94-intarea-6.pdf [9:10] Transmission of IPv6 over MS/TP Networks Kerry Lynn 10 minutes draft-ietf-6lo-lobac-03 Kerry believes draft is fairly mature. Second implementation is now available. Goes through changes since -02. Still remains to finalize security considerations before going to WGLC. Posted to the mailing list yesterday on this topic. Background: RS485 widely used for building control applications in the US and worldwide. Dave Thaler: Should assess whether link-local address will be identical the next day; privacy document has guidelines on handling link-local addresses Kerry: MS/TP unique in that configuration done through dip switches, not changed later. Dave: should add text that these nodes are not expected to move at all. Samita: waiting for inputs from Bacnet? Kerry: no. Just go to the plugtest. Also make sure security section is satisfactory. Then go to WGLC. [9:23] Transmission of IPv6 Packets over Near Field Communication Yong-Geun Hong 10 minutes draft-ietf-6lo-nfc-02 Yong-Geun reminds this is peer-to-peer communication. The author goes through updates in the draft. NFC use negociation between both ends. next steps: plugtest tomorrow, between Intel Edison board and Laptop PC. MTU extension Dave Thaler: Global address construction is based on 6 bits. Section 4.3 says MAY, no SHOULD nor MUST anywhere. If put SHOULD, MUST, then it raises privacy issue. Only 6 bits in global address may be an issue, even though the connection lifetime may be short. Say how short. If a SHOULD or MUST, must be addressed in security considerations re. privacy considerations of such a short 6-bit IID base. The document needs to discuss why such low entropy (6 bits) is fine. Another way to say that the Global Addresses MUST NOT be used on this link. But if there are global addresses, then you'd have a potential privacy issue. Samita: what is the use case for privacy in NFC? Dave: If Global addresses are going outside the peer2peer connection, then privacy issue. Either preclude using global address or have privacy considerations section in document. [9:32] IANA Regitry Request for ESC Dispatch Bytes Samita Chakrabarti 10 minutes draft-chairs-6lo-dispatch-iana-registry-01 The document was published at last IETF is response to request by ITU-T on dispatch codes. WG decided to keep current format and comply with ITU-T use, and define further extension. Pascal will present another proposal on non-ESC dispatch. Samita presents propose Esc Extension type (EET) proposal. Considering legacy devices: assumes they will drop packet or drop extension in the presence of unknown extensoin byte. Future devices: drop extension in such case. There was proposal to assign escape byte per tehcnology or SDO: rejected because wanted to honor ESC bytes already used by ITU-T. Idea may be reused for second escape byte. Non LowPan packet (NALP) behavior? Pascal: in 4944, there's ambiguity. Can only happen in first octet ? Gabriel: at the time, done for Zigbee. Meant to be only in first octet. Robert Cragie: pretty clear in 4944, says it will drop the packet. Anything appear further (or before, but NALP should be first octet) will not be processed. Pascal: still begs the question if it's legal or not to appear in the middle. Samita resumes presentation: next steps is ask about WG adoption. Also, is WG interested in starting defining 2nd extension byte? Pascal: support adoption. Escape is very useful to welcome work from .. Brian (AD): call for adoption cannot be done by WG chairs since authors, will do myself and assign a doc shepherd. [9:46] A Routing Header Dispatch(6loRH) and a new Paging system Pascal Thubert 15 minutes draft-thubert-6lo-routing-dispatch-06 starting with the objective to compress routing data placed inside ROLL packets. - Instance ID used for multi-topolog routing. - Rank, measure of distance to root. Used for lazy repair. - application of encapsulation/decapsulation rules debated at 6man. IP-in-IP was costly, can be improved. Ended up with proposal for a new header in front of RFC6282. New dispatch space, into which header insertion is done. TLV format, with one bit to tell is header can be safely ignored if unknown. Is this still IPv6? believe yes, because IPv6 packet can be unambiguously reconstructed. Various proposals: use space left by 4944, reclaim some 4944 dispatch space, or paging system. Paging system: marginal cost 1 byte (past initial header cost of 2 bytes) compared to 2 bytes each time with escape system. "sur-compression"? proposal by Jonathan Hui to compress 6282 compression. 6loRH scheme is compatible. IP-in-IP is made much better with 6loRH. Problem when tunneling to destination outside the RPL domain. To be addressed. Will be discussed at 6man. Pascal requests the WG chairs to call for WG adoption. Samita: who has read this draft? 4 people in the room. Will ask the question on the mailing list. Need more people to read and comment. Q&A Subir Das: Where is this solution used? (paraphrased his question) Pascal: this is meant to be used within RPL routing domain. Header must be removed at the last router. But knowing which is last is the issue. Michael: at ROLL meeting, example to show what this problem is. If we know this is sub-IP compression, can givie it a slighlty different semantics, and make these headers skippable. Pascal: This is in reaction to existing ROLL standards (655x). Well-known case, in which even leaves understand RPL. Another case is last router is an anycast address. ???: concerned with co-existence with already-deployed nodes that don't know of this paging system. Pascal: no discovery service. At least for the future, clearly define what header can be skipped. Otherwise, packet is just dropped. Carsten: RFC7400 defines discovery mechanism, could be used here. Robert: will leave comment to Michael to ROLL meeting this afternoon. Samita (chair): we need more reviewers for this. Please come to see us at the end of the meeting or send a mail to 6lo-chairs@ietf.org. [10:10] 6lo ND backbone router Pascal Thubert 15 minutes draft-thubert-6lo-backbone-router-01 Registering mechanism, layer 3 association. ISA100.11a and WHART both have backbones that span the netwrk to reduce depth to 1 or 2. Work was split off . Now ready. 6BBR is support for multilink subnet. Ethernet is viewed as extension to LLN. BBR will break the broadcast domain, but devices cna still be pingned directly. Question is associating/de-associating with BBRs. BBR can decide what to do with registration. Applies to wide range of wireless technologies. Extends ARO option of efficeint ND. 6775 registers the source, we want to register the target deep down the tree. Got running code, this is stable. Lorenzo: in Wifi, general purpose hosts, you're changing ND, you should go to 6man. Disagrees with assertions made about real impact of this on .11. Pascal: still usefull to 6lo networks. If hindered by application to Wifi, let's drop application to Wifi. Keep LP-Wifi. Lorenzo: BCP going through ..., will conflict. Pascal: need to scope our work. Samita: will discuss if we keep LP-Wifi in scope. Some LP-Wifi work in 6lo. Lorenzo: your text says .11 [10:24] MLE Robert Cragie 15 minutes MLE: draft-kelsey-6lo-mesh-link-establishment protocol for link configuration, parameter dissemination, ... in 15.4 mesh entwork. Resurrected from past activity, mainly so that Zigbee can refer to an RFC. Various options going forward: keep document as is, split base set and Zigbee-specific part, incorporate recent changes, add thread to ZigBee IP stuff? Subir: what amout of effort needed to do option 3? Robert: soliciting comments, what does the WG think? Yoshihiro Ohba HIP-DEX over MLE: draft-ohba-6lo-mle-hip-dex Key exchange for constrained devices. Changes from version -00 Length field extended to be able to have size > 256 bytes, needed to carry certificates. Q&A Carsten: CRL on my computer 60MB, transport over UDP? Yoshihiro: discussing reducing size of CRL Robert Moskovitz: see 802.1ar , size is manageable. Can also go to delta-CRLs. Carsten: typical size? Borbert: in the 100's CRLs, ECC make them even smaller. Exercise to be done. Gabriel: to be mentioned in the draft. Need reviewers on these documents. [10:37] IPv6 over 802.11ah Maria Ines Robles 10 minutes draft-delcarpio-6lo-wlanah-01 Ines presents the draft and 802.11ah main characteristics. Two versions of MAC protocol Pv0 and Pv1. Pv1 is mandaoty for constrained devices. Prefered topology is star. New Ethertype to be able to use 6loWPAN compression. In this version, added .. 16 bits addresses Dave Thaler: Same privacy comments apply. Since this is Wifi, including for link-local addresses. Carsten: would expect Pv0 network to be bridged to .11 networks or even Internet. Means encapsulation ... Carsten: will discuss offline. Samita: discuss this on the mailing list. ..: Ines: Matlab simulation shows Pv1 overhead saving significant for .. Yong-Geun: Please add info on sizes of Pv0 and PV1 Conclusion: More work is needed on this document [10:47] Compression of IPsec AH and ESP Headers for 6lo Ludwig Seitz (standing in for Shahid Raza) 15 minutes draft-reza-6lo-ipsec-02 No modification to IPSec, only header compression within 6LoWPAN networks. Recently compared with Diet-ISP and ROHC. Wrt Diet-ISP: requires changes in the IPSec standard. wrt ROHC: ... Describes the compression mechanism. This proposal uses two reserved bits in 6LoWPAN headers to define IPv6 Auth Header and IPv6 Encapsulated Seurity Payload. Alex Petrescu: 8 bits extesnin e=headers at IANA, will need more bits to accomodate ... Samita: bring this comment to 6man Michael: proposal 1 is wasteful. AH hardly ever used. Even ESP doesn't justfy this space. Wait for Pascal's proposal that provides much more space Carsten: This is NHC space. There is space left. 256 elements. Michael: something else will come up that is more important than AH. AH is not worth the space, not even the thought of. ESP maybe. Cross AH off this. Carsten: AH is useful in IPv6. Pascal: we want to compress things that are present in those networks. Ludwig: By making it easier to use, won't it be used more? Michael: no, we failed. Robert M: don't blow your last reserved field. At least, use them for extension mechanism. Pascal: consider 6LoRH, that's what it's intended for. Ludwig: I suspect this is not about tunneling. Ludwig resumes presentation of compression mechanism. ESP is 10 bytes without compression vs 4 bytes with compression. Implementation on Contiki. Compression add 10kB ROM and 300B RAM. This proposal response time outpoerforms 15.4 link layer security if more than 2 hops, because link-layer security has to be done at each hop. Robert: why is AES-CCM not in the benchmark? Brian+David (relying Jabber); author will provide data on the mailing list. Samita (chair hat off): think IPSec is nice to have. (hat on) would like to hear on the mailing list of interest by the group. Conclusion: The authors should look into ESC dispatch header solutions to use the extra bit flags [11:08] IPv6 over BLE Mesh Networks draft-gomez-6lo-blemesh-00 Carles Gomez 10 minutes Bluetooth 4.1 allows topologies extending beyong star. RFC7668 specifies IPv6 over BTLE, but does not work on mesh topologies. Hence this new draft. Multilink subnet, route-over routing. Specifies IPv6 routing, the choice of which is out of scope. Header compression based on 6282. 6Cos in RAs. RFC7668 exploited star topology. Only part of them can be used. Source address fully elided on first hop only. Following hops may elide if context is present. Pascal Thubert: your picture looks like the Backbone routing. Device could move between subnets. Look at BBR draft and consider how it applies to your case. Carles: will do. Carsten: slide 8. How about using 16 bit format address for layer 3? Could be shorter than compress full addresses. [11:19] 6lo ETSI Plugfest@IETF94 Miguel Ortega 10 minutes Reminds of first 6lo plugtest happening from Friday noon to Sunday afternoon. Was open to all drafts being worked on at 6lo, got participation from 6lobac, nfc and 15.4 implementations. Carsten and Kerry technical experts. Will support the event as well as report to EC. [11:23] Address Protected Neighbor Discovery for Low-power and Pascal standing in for Behcet Sarikaya 10 minutes Lossy Networks draft-sarikaya-6lo-ap-nd-01 do we need secure neighbor discovery in LLNs? Reminds SeND is peer-to-peer, based on CGA address. This draft is about registration mode, first come first served at registration place. Only on node moving will it need to prove itself at new location. One technical solution proposed in the draft, others could work, too. Is this a real problem? A valid approach? Samita: who's read the draft? One. Alex Petrescu: should be solved. But comparison to SeND comes to mind. Pascal: there is text in the draft that explains that. [11:27] 6lo Use Cases Yong-Geun Hong 5 minutes draft-hong-6lo-use-cases-00 Yong-Geun lists the technologies this draft wants to describe the use cases for. Please contribute with description. [11:31 adjourned] =============================================================== Not part of 6lo discussion but it might be interesting to many folks: ( 802.11 and multicast presentation at INTAREA) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-1.pdf INTAREA 6lo WG summary -- http://trac.tools.ietf.org/area/int/trac/wiki/IETF94 Meeting outcome: •6lobac will be going for WG LC soon •Dect-ule draft will be ready for IESG submission after shephard's review •draft-chairs-6lo-iana went on for adoption call right after the session [ Brian H. ] •Working group is looking for a shephard for the iana document •Two reviewers received for 6lo-routing-dispatch and 6lo-backbone-router documents •The above two documents are targeting for adoption calls •6lo-usecase document and 6lowpan-update-requirement document will be discussed before the next IETF