6lo: IPv6 over networks of resource-constrained nodes WG Agenda Meeting: IETF 89 Wednesday March 5, 2014 Time: 1520-1730 Afternoon Session II + III Location: Balmoral Chairs: Samita Chakrabarti Ulrich Herberg Technical Advisor: Ralph Droms Minutes: Dominique Barthel and Anders Brandt Jabber: xmpp:6lo@jabber.ietf.org Audio archive: http://www.ietf.org/audio/ietf89/ietf89-balmoral-20140305-1520-pm2.mp3 and http://www.ietf.org/audio/ietf89/ietf89-balmoral-20140305-1630-pm3.mp3 URLs: https://www.ietf.org/mailman/listinfo/6lo http://datatracker.ietf.org/wg/6lo/ ========================================================= ====== agenda bashing + note well + draft status update: chairs This is 2nd meeting of 6lo WG Agenda change: Carsten's listed presentation is replaced by a talk on privacy concerns at link layer by his request. Draft Status: draft-ietf-6lo-btle-00: waiting for BT SIG to comment, nothing to do for us draft-ietf-6lo-lowpanz-03: 1st WGLC passed, changes after LC require new WGLC Since last meeting, adopted 3 WG drafts: draft-ietf-6lo-ghc-00, draft-ietf-6lo-lowpan-mib-00, draft-ietf-6man-6lobac (not yet submitted as 6lo WG draft) [addition to he minutes: draft-ietf-6lo-btle-00 has also been adopted, taken over from the 6lowpan WG] Samita Chakrabarti: Some new individual drafts have been brought to the attention of the WG: draft-rizzo-6lo-6legacy-00 draft-savolainen-6lo-optimal-transmission-window (3GPP environment) draft-mariager-6lo-v6over-dect-ule-00: not much change apart from republication as individual draft with 6lo in the moniker Milestones achieved the part intended for December as far as draft adoption ====== draft-ietf-6lo-btle update: Teemu Savolainen moved from 6Lowpan to 6lo, submitted to IESG, waiting for BT SIG to issue 4.1. main new features: LE L2CAP connection oriented channel support. Negotiation of app MTU, channel identifier, number of initial credits, during setup. Help constrained nodes throttle down data exchanges. Fragmentation at higher layers, and Segmentation and Reassembly at layer 2.5 In 4.1, new topologies possible: a node can be master for one slave and salve for another node. Also a node can be slave to multiple masters. Allows to build real mesh networking. However, in this draft, still only considering star topology. BT SIG has an "Internet" WG, Teemu part of it, but is not allowed to reveal what happens there. Documents will eventually align. ====== draft-ietf-6lo-lowpanz: Anders Brandt Some comments during WG LC, some further comments (mostly editorial) later in. Made into -02. Some more changes in -03, submitted yesterday. 01: no reference to routing protocol needed as this is an adaptation sublayer. 02: for mesh-under, unique link-layer addresses, no need for DAD. changed SHOULD NOT to MUST NOT 03: because of privacy issues raised by Samita and other sources, opened up possibility for these nodes to request address from DHCPv6. Flag in Router Advertisement. Carsten Bormann: is some of this text redundant with RFC6775? Anders: believe RFC6775 is only recommendation, strengthened here. Carsten: is it? Carsten: Next slide is important. 802.15.4 we can choose whether we get addresses from DHCP or something else. Proposal here is to simplify this for mesh-under case to only two cases: M-bit not set (always LL-derived addresses, or M-bit is set and we have to use DHCP). Samita: is it clear that DHCP-assigned addresses are temporary but does not cover privacy issues? Anders: short leases does provide good privacy. Samita: since more changes were made, will do one more round of reviews. Some assigned reviewers. Geoff Mulligan: didn't notice that this will prevent to do CGA on mesh-under. Anders: has been there since yesterday. Geoff agrees to review the doc. Alex Petrescu: at 6man, several drafts around the formation of IPv6 address, moving away from link layer address. I recommend to follow what's going on in 6man. Samita: We should follow what is in 6man, but we also have to consider the 6lo use cases. Anders: link layer address, but not to be confused with MAC address. Short address within the PAN. Node cannot be recognized after next inclusion in the network. Hannes: some time ago, thought IP... 6lowpan document, privacy addresses don't work anymore. Anders: in many cases, not worried about recognizing nodes by addresses. Carsten: short address is an 8 bit number. Identifying power not high. Brian: 8 bit is not enough entropy to identify a node that moves around. Don't over-engineer. Kerry Lynn: cost of this is carrying full IPv6 addresses, not able to compress them out. Anders, that's why it's an optional option. ====== draft-ietf-6lo-lowpan-mib: Juergen Schoenwalder counters to figure out what happens at 6lowpan sublayer, e.g., fragmentation. about 18 counters Should counters be interface specific? at this point in time, JS doesn't see it as being useful. Kerry: predominant case (one interface) doesn't make a difference, but already cases (Zigbee) with multiple interfaces, see this as very valuable. Samita: in 6lo, assumption is to support multiple link layer technologies. From day one, we should have this. Ulrich: could be useful to have. What is expected overhead, extra complexity? Juergen: could be described interface specific, but not mandatory to implement. Humm : no humm against this capability, significant humm for. Ulrich: will bring it to the mailing list to confirm. Ulrich: When do we need MIB doctor review? Juergen: After WGLC. ====== draft-ietf-6lo-ghc: Carsten Bormann Originally created in 2010, eighth version, stable, presented in Vancouver IETF88, adopted by 6lo. Issues: capability indication? 6CIO. Uses one bit, leaves 47 for something else. Proposed policy "RFC required". Do we want to use any of these bits for experimentation bits? Ulrich: How high is the bar for RFC publication for "RFC required. "? Hannes Tschofenig: not so high, independent submission. Brian Haberman: IESG's work to make sure independent RFC does not conflict with work done at IETF. Ulrich: so, which level should we use? Brian Haberman: would recommend "IETF consensus". Michael: suggest to mark 7-8 bits as "private use". Carsten: no, "experimentation". Editorial comments originally written so that spec fits on one page. Maybe slightly larger than that now. Static dictionary choice not "easy to explain". Was scientific process, but not quite explainable. Examples may not all be very understandable. Intention to do -01 and ship it. Ulrich,Carsten: agree to to WGLC after editorial comments. ====== draft-mariager-6lo-v6over-dect-ule: (no author present) Technical contents will not be presented again here, however slides are in the proceedings. Nobody from the current author list is on site to present. Few changes, will move again towards WG adoption. ====== draft-savolainen-6lo-optimal-transmission-window: Teemu Savolainen Time to tear down data channel: in 2G, two seconds, in 3G, half a second, 4G, ten seconds Teemu shows current measurements for sending CoAP packets at 10s interval on 2G, 3G, 4G. Lots of energy wasted listening to channel for nothing. Situation of multiple sensors using a cellular device as a gateway. Group transmissions at gateway to avoid having multiple active periods on cellular interface. This draft proposes nodes behind a gateway learn of optimal times to send their data so that grouping is performed. Teemu: other networks with same behavior/benefit? Thoughts on usefulness? Interest to this WG or go back to 6man? Zhen Cao: how about the gateway delays the CoAP request and send them together? Teemu: No, we have not considered that. How long would the router delay it? Carsten: synchronizing sleep schedule is beneficial. Problem: many patents. Any IPR? Teemu: Nokia has declared IPR on this technology. Look for declaration on equivalent draft submitted at 6man, the tools don't allow the IPR declaration to follow drafts morphing. Ulrich: please send pointers to IPR declaration on the mailing list. Dave Robin: old problem, we had this for dial-up. Application can tell how urgent packet is, but hard for networking layer to understand. Hannes: I had a similar reaction, reminds me of DTN work. Teemu: BT nodes can register by the gateway to be woken up at predetermined intervals, which notifies application to send data. Another solution. Samita: should this WG continue work on this ? Please humm... Brian (as AD): let people a chance to read IPR first. Then make the call on the mailing list. ====== draft-ietf-6lo-bac (currently: draft-ietf-6man-6lobac-01): Kerry Lynn draft depending on doc that sits at BACNet for second public review, then approval. this draft held off pending this to happen. ====== draft-rizzo-6lo-6legacy: Gianluca Rizzo Many devices not addressed directly via IP: RFID, building automation. Would like to extend IoT to these devices. Propose address mapping. Desired properties: consistency, local uniqueness, uniqueness across the whole Internet. Explains examples: EPC RFI (requires hash). Carsten: experience as 6lowpan co-chair. Why would we need to do this? If devices are not IPv6 capable, they don't need an IPv6 address. Why give a fixed IPv6 address to something you can't talk to? Hannes: desktop computer mouse is local device, does not need an IP address. What's the purpose? Samita: use case is e.g. sensor legacy devices. Connect them to the Internet with some level of service. Hannes: you can connect RFIDs to the Internet today, no need for IPv6 address. Kerry: header compression works fine with zero-padding. With this proposal, probably take away most ability to compress header. Michael: gateway will do translation between v6 and something else. IPv6 address would allow gateway to be relatively stateless. As Carsten mentions, this can be proprietary, does not need standardization. Except maybe privacy and ID tracking. We may want to carry on with this document to get review from privacy experts at IETF. Informational document at most. Bob: 6 bits of protocol identifier? we have hundreds of legacy protocols. Anyway, gateway needs to understand upper layers, can do what it wants with addresses. Hannes: this is not just a network protocol. You need application layer processing anyway. Take a running event with RFID as an example. Tie RFID to user. Bob Moskowitz: suggest recommended practice. In SCADA, we can't replace devices, serial bus. If gateway could connect to Internet, would be great. CAN bus example as well. Robert Cragie: does not see the need to have this. Part of IPv6-over-whatever specification. No need for generic address mapping for all legacy protocols. Erik Nordmark: use DHCP to assign address, stable address, does not rely on hashing, does not reveal identity. Samita: WG to read draft and comment about applicability. ====== L2 address privacy: Piers O'Hanlon [10] no draft, but paper: https://www.w3.org/2014/strint/papers/35.pdf Link layer MAC addresses globally unique. Facilitates unsolicited tracking (e.g. sniffers in waste bins in London). Suggest to use dynamic addresses at link layer. other approaches: IPv6 Crypto Addressing (CGA) inspired. Take it one layer down. Or share MAC addresses (chameleon addressing). Ulrich: is this destined to IETF? Piers: maybe more the IEEE. Bahmas (Verizon): 6man interested in privacy. Dont use MAC addresses in your IPv6 address. Robert Cragie: when did Zigbee IP, used global addressing without exposing MAC addresses. Also, link layer addresses also reveal IID, creep up the stack. Erik Nordmark: make sure IPv6 address also changes when MAC address changes, otherwise not much benefit. Do you know is 802.11 is already looking into this? Piers: at the STRAIN workshop, IEEE rep was there. Piers: some work on when is good time to change MAC address. Carsten: what we could do but haven't done at 6lowpan: 16 bit address reveals 64 bits address. Some work could be done at IETF. Bob: One place we can look for experience is vehicle-to-vehicle communication IEEE 802.16.9. Pascal: if interface is alive, changing addresses requires to be able to accept packets on old MAC address for a while. Hannes: wrote slides to data protection specialists. Tangled issues. Worthwhile to categorize issues and untangle some of them. http://eandt.theiet.org/news/2013/aug/bin-data.cfm ====== 6tisch Plugfest: Pascal Thubert and Thomas Watteyne informal meeting tomorrow morning 9-12 GMT, room 1-4. Plugfest. Will show equipment running code. Pascal: detect overlap, gaps. 6TiSCH encompasses multiple meshes, backbone router. Pascal explains the need of efficient-nd like TID bits in 6lowpan-nd for 6TiSCH stack and that their current demo implements efficient-nd bits on top of 6lowpan which runs on top of 6TiSCH. ====== 6lo deployment? Uses cases and reference architecture: Samita RFC6568 : use cases for 6lowPAN. Applicable to 6lo. But now, 6lo supports multiple L2 technologies. Need to document these use cases? architectures? several IETF WG tackling issues adjacent to 6lo. Do we need a reference architecture? assembling the puzzle, need for GW or proxying? Erik: simply using a different radio is not very useful. Other situations (like backbone router) are useful contributions.