Minutes for 6LO at IETF-91
minutes-91-6lo-4
Meeting Minutes | IPv6 over Networks of Resource-constrained Nodes (6lo) WG | |
---|---|---|
Date and time | 2014-11-11 19:00 | |
Title | Minutes for 6LO at IETF-91 | |
State | Active | |
Other versions | plain text | |
Last updated | 2015-01-22 |
minutes-91-6lo-4
IETF #91, 6LO WG Minutes, Nov 11, 2014 Co-chairs: Samita Chakrabarti, Ralph Droms Note taker: Markus Isomki and Ines Robles Summary of Agenda: 1.Introduction and NoteWell, trivia and document status by the co-chairs 2.A compression mechanism for the RPL option (Thubert/Bormann) 3.RFC6775 Update requirements for 6lowpan-ND(Thubert) 4.Transmission of IPv6 Packets over Near Field Communication(Hong) 5.IPv6 mapping to non-IP protocols (Rizzo) 6.Recommendation on Stable IPv6 Interface Identifiers(Gont) 7.Lightweight and Secure ND for Low-power and Lossy Networks(Sarikaya) 8.Observation about IPv6 Addressing (Constraiend nodes) (Struik) Ralph Droms opened the IETF91 6lo meeting announcing Ulrich's stepping down as a co-chair and Ralph being an acting co-chair while the IETF INTAREA was looking for a replacement co-chair for 6lo WG. Folks in 6loWG were invited to volunteer. It was noted that ÒIPv6 mapping to non-IP protocolsÓ draft being presented today, but the draft may move to 6man WG due to its scope. ÒInterface identifiersÓ draft on the other hand is a 6man document but since it has an impact on 6lowpan header compression, 6lowpan needed to review in 6lo so that there is no negative impact in 6lo deployment/standards. Samita went over the Document status: BT-LE document still waiting for BT SIG to progress. Brian Haberman: Do we need to poke BT SIG or do we just wait? Carsten Bormann: BT SIG has made changes to the channel assignment assumed in the current draft, so once we get the documents from BT SIG we have to review them. Markus Isomki: BT SIG documents are not yet published so we canÕt yet review them in the IETF. But there should not be anything special happening, things are just taking time. IPv6 over PLC draft currently expired. Fragments draft by Pascal Thubert: Pascal Thubert: Have gotten feedback that the draft provides a solution but the problem is not clear.He had prepared slides to address the feedback but no time to present today. Probably will submit a separate draft to cover this. dect-ule: Ralph made few comments last week. Draft will proceed to WGLC shortly after the new revision Dominique Barthel: are working this week on updates following your comments, expect to issue new version next week. Finally, the co-chairs reported publishing 2 RFC from last IETF (RFC 7388 and RFC 7400) and draft-ietf-6lo-lowpanz being on the RFC editor's queue. WG milestones will be updated soon and a draft milestone update was presented. ETSI Plugfest on 6lo: ---------------------- The chairs have been approached by ETSI plugfest for possible interoperability testing. The details will need to be figured out. Possible target dates are mid year 2015. Contact name: MiguelAngel.ReinaOrtega@etsi.org A compression mechanism for the RPL option Thubert/Bormann 30 minutes <draft-thubert-6lo-rpl-nhc-02> WG discussion and comparison of technologies RPL inserts a hop-by-hop header in every packet, size 8 bytes. Would like to be able to compress this with 6lowpan next header compression. A balance of engineering decisions, complexity vs. frame size etc., need feedback 6TiSCH uses also 127 byte packets so 8 bytes makes a difference. This work is thus high priority to 6TiSCH. There is also a flow label solution to do the compression, but 6lo approach has some advantages, presented on the slides. -02 version of the draft published, converges another draft (-bormann). Slides explaining how to compress RPLInstanceID and SenderRank. The draft presents three different approaches: ÒGreedyÓ, ÒConservativeÓ and ÒEfficientÓ. Greedy uses 64 codepoints from the RFC 6282 codepoint space. Conservative only uses one codepoint but requires another additional byte to include the information. Efficient is in the middle: Sometimes a new byte is needed which creates header expansion. On the other hand, implementers will have to deal with header expansion anyway, but in the worst case a router has to break a packet into two. The WG needs to decide which approach to pick. Around 6-8 had read the draft but not enough ready to make a decision right now. Need to get this on the mailing list. Michael Richardson, ROLL chair: People who have read the draft have hard time to decide. For ROLL ÒgreedyÓ is the best but how about the rest of you? You don't have to read the draft to have an opinion about it. Ralph, as individual: Expansion of header size on the fly. This is possible also with other headers. Has this been a problem so far? Carsten: The originating host needs to do a specific trick here to make things easy for the routers. Pascal: The big question is the one Michael asked. Greedy avoids the expansion problem, but uses codepoint space. Ralph: How many code points will be left after assigning 64? Pascal: Around 140+. Ralph: An exact number would be helpful. Samita, as individual: What other application or routing protocol could use the codepoint space in the future? Pascal: Routing protocols do not usually put data in traffic packets, RPL does. But it could be some new application. Samita: Concerned about codepoint preservation. Prefers not to go for the greedy option to save option space. Carsten: Currently 42 codepoints have been assigned assigned, 214 are available. 214 - 64 would be 150. Pascal: Anyone has an indication what else could use new options? Thomas: RFC 6554, source route header compression. How does this work with it? Carsten: The current request is half of the thing what we want for RPL. Need also to revisit the mesh header, would require really making changes. So, RFC 6554 may need additional codepoints too. Ralph: We did this conversation in the wrong order. Can't make a decision until discussing the source route compression which might require 64 codepoints more. Don't feel secure to make a decision before that discussion. Pascal: Is there any known usage of mesh header? What would the impact of changing mesh header be? Ralph: Is IEEE using it? Carsten: Mesh header contains a fixed set of information. Anyone who want to do a mesh protocol may not find that enough. ???: IEEE 802.15.10. They have not gotten to this extent yet. But it is supposed to be a layer 2 mesh under. Not specific to 802.15.4 but that is the most relevant MAC/PHY. Can put the information to different places. Pascal has the right approach with greedy, even an octet is important. Bob Moscowitz, chair of 802.15.9: Includes mechanism to carry some information without IP, .15.10 can use the same mechanism. Thomas: There are people using the mesh-under header, it should not be obsolited. Actual networks use it. Ralph: Need to take this conversation to mailing list. Carsten, Pascal, can you lay out the new possibilities you discussed today, including a possible compression for the Source Route header. That will help us to have the conversation on the mailing list. RFC6775 Update requirements for 6lowpan-ND Thubert 20 minutes <draft-thubert-6lo-rfc6775-update-reqs-05> WG discussion on RFC 6775 update requirement list Originally the use case of was broader what the RFC 6775 eventually covered. Also, a number of new requirements have come up, e.g. from 6TiSCH, security, Zigbee IP. All these known requirements have been collected to this draft. In the end there can be multiple documents to address them. Carsten: Be careful with the word requirement. These are potential objectives, some more potential than others. Samita: Please review this document. We should also find another co-author for it. -05 published, 23 requirements in total. No time to go through all the requirements one by one today. Went through some example requirements. Ralph: How many have read the draft? Not very many. Not enough people in the room to hum for the WG adoption. More discussion on the mailing list. Brian Haberman: If you do adopt this document, please don't just ask for just the requirements document to be published. Requirements can be included in the solutions documents. Carsten: Can still make it a WG document, even if it is not aimed to be published. Transmission of IPv6 Packets over Near Field Communication Hong 15 minutes <draft-hong-6lo-ipv6-over-nfc-02> Ready for acceptance as WG document? Second time to present this document, -02 published. NFC has different modes. Peer-to-peer mode relevant for IP. Comparison with Bluetooth LE. NFC is secure due to <20 cm range. Over 200 NFC capable phones available. Personal information can be transferred over NFC. Sections 4.7 and 4.8 related to address mapping are new. Five key issues: 1: Connectivity, two scenarios: NFC enabled device connected to Internet, and isolated NFC enabled device network. 2: Address configuration. 3: Header compression 4: Fragmentation and reassembly. Default MTU is 128 bytes. 5: Unicast/multicast address mapping. Prototype implementation of IPv6 over NFC in progress. Samita: How many interested in this document? Quite many. Any objections to make it as a WG document? No. People who have read it please post comment on the mailing lists. Based on comments update should be made and in a few weeks WG adoption can happen. Carsten: How stable are those LLCP addresses? Do they change? Need to pay attention about this issue. Multicast address, why did you choose it to be like that? LetÕs take it offline. Petrescu: One comment to interface id design. You could call it a 6 bit IID instead of a 64 bit IID. Ralph: 128 bit address is needed anyway, right, so even if there are zeros they are not ÒwastedÓ. IPv6 mapping to non-IP protocols Rizzo 15 minutes <draft-rizzo-6lo-6legacy-02> Update from previous revision The feedback from previous presentation was that not enough context was given, so now something more has been added to the draft. A lot of legacy technologies are not IP enabled. Example: Home appliances direct control. Zigbee, KNX, Wi-Fi. IPv6 would allow direct control without gateways. Would be good to have the same way to address both real IPv6 devices and non-IP devices. Make legacy devices appear as directly IPv6 addressable, by assigning their own ÒvirtualÓ IPv6 addresses. Coverage of the draft: Legacy protocols with node identifiers. Aiming at informational, not standards track. Adapted the mapping to accommodate large number of legacy protocols. Pascal: Why do we need to expose all this information to Internet? Is the gateway supposed to be stateless? Since if the gateway it stateful it can hide all this information instead of exposing it to an attacker, for instance. If the gateway has state per node it can avoid address conflicts. Only stateless gateways would need this kind of a mapping. Samita: This defines just one implementation option. Michael Richardson: Following PascalÕs question. Gateway has some security relationship with the devices. That makes some state necessary. Stateless only applies if there is no security. This could be even in a Òdon't ever do thisÓ type of proposal. Fernando Gont: No structure should be assumed for the 64 bit Interface ID. Ole Troan, 6man chair: Fine to do whatever interface ID structures, but why do you want to publish this? Gateway can just do it. Ralph: 6man and 6lo chairs need to discuss whether these discussions are better had in the 6man WG. This is in their territory. Ole: Happy to have that conversation in 6man. Recommendation on Stable IPv6 Interface Identifiers Gont 20 minutes <draft-ietf-6man-default-iids-01> Follow-up discussions with 6lo WG on default IID recommendations Ralph: This is a 6man document but it can have impact on 6lowpan header compression, so that is why it is presented here too. Actual discussion will be in 6man later in the week. Motivation of the document: Often the IID is generated based on HW addresses. Hardware addresses in IIDs expose hosts to reconnaissance, tracking and node specific attacks. Many current IP-over-foo specifications still mandate that SLAAC IIDs be generated by embedding hardware addresses. 6man-default-iids updates a number of them based on an alternative mechanism. Ralph has sent comments related to 6lo header compression. Pascal: HC is critical, intermediate node must still be able to compress somehow. 6lo should document what is relevant for it, for instance low-power devices often do not move between subnets. Fernando: The document says SHOULD, so if there are good reasons it does not need to be followed. Pascal: In RPL network special considerations. After defining what is relevant for 6lo, may want to define a compressible version of the new mechanism. Rene Struik: My presentation which will follow does some analysis about this. Bob Moscowiz: Some low-power devices just come up with a different address every time. Dave Thaler: To address Ralph's comments: Link layers MUST define a way to provide privacy. They MAY provide a more efficient mechanism without privacy. Which approach to use should be configurable. Need to continue this in 6man. Robert Craigie: Justification why hardware addresses used a lot in low power devices. Carsten: Confusion because hardware address does not have a well-defined meaning. For instance, how about NFC. Should talk about device encoded addresses. Current doc is too Ethernet minded for this WG. Ralph: Conversation needs to continue in 6man, send text. Lightweight and Secure ND for Low-power and Lossy Networks Sarikaya 15 minutes <draft-sarikaya-6lo-cga-nd-01> Initial WG discussion Presentation covers what is new in -01 draft. Rene: This technique is more generally applicable than just 6lo. Brian Haberman: What exactly is multihop neighbor discovery? Behcet: This is covered in 6775. Brian: This is not applicable to standard neighbor discovery then. Pascal: Suresh had a proposal about this. Don't need to put signature information in every registration. Samita: Is this interesting work for the group? Yes: Weak hum. Need more people who have read this and comment. Dave Thaler: It is not ready for adoption as not enough people have read it. Security implications are not yet clear to me to have an opinion if all security threats are addressed. Observation about IPv6 Addressing (Constrained nodes) Struik 15 minutes <draft-struik-6lo-on-ipv6-addressing-00> Initial WG discussion This draft is triggered by RFC 7217. Issues with fixed IIDs: correlation, tracking, leaking of device characteristics. Suggested remedy: Semantically opaque IIDs, RFC 7217. Analysis how this addresses the issues. You can also randomize the MAC address. Efforts to enable this going on in IEEE already. This could be better for compressibility. Fernando: Goal of 7217 is to produce stable addresses in the same network, so it is a feature rather than a bug. Alissa Cooper: More of the comments are related to privacy document in 6man. The 7217 mechanism was aimed just at a certain set of goals. Different mechanisms may fulfill other goals so they should be analysed together rather than separately. Randomly generating MAC addresess has benefits over randomizing just on layer 3, especially related to the first hop. The conclusions is that it is not clear how useful 7217 is, as it ignores L2 traceability. If IP address is tied to a random L2 address, the additional benefit is that IP header compression is easier based on the L2 address information. Ole Troan: Please bring this to 6man list, have worked on this for a while. Dave Thaler: 6man is the right place, not 6lo. One great new observation in this presentation that has not come up before is that if you do the random address generation on the MAC address level then the existing EUI-64 mechanisms will propagate the privacy properties to layer 3 as well. Will want to bring this up in 6man. Fernando: Also another draft exists that analyses privacy issues of IPv6 addresses.