6lo WG : Sessions : Monday @5:40pm (1 hr) and Thursday @3:20pm (2 hrs) Agenda: https://datatracker.ietf.org/meeting/93/agenda.html Chairs: Samita Chakrabarti and Gabriel Montenegro Area Director: Brian Habermann Tech Adviser: Ralph Droms Secretary: James Woodyatt Highlights of 6lo sessions at IETF93: -------------------------------------- IANA discussions: There were two full 6lo sessions on IETF 93 at Prague. The first session was on Monday late afternoon and it was attended by 80+ people and the second session took place on Thursday afternoon. In the first session the group discussed the ITU-T liaison response for IANA registry of 6lowpan (RFC 4944 and RFC 6282) ESC dispatch bytes of which 1-31 values in the first 8 bits following the ESC byte has been used and deployed by ITU-T G.9903 and G.9905 specifications for G3-PLC networks(without informing IANA). ITU-T Liaison co-ordinator, Scott Mansfield and IAB Liaison Manager And 6lo Technical adviser, Ralph Droms took the lead to work with 6lo and roll WG chairs in making the decision on the proposal that IETF would collaborate with ITU-T on this regard and will help register the ITU-T specified bits at IANA. The WG and chairs discussed draft-chairs-6lo-dispatch-iana-registry-00 draft in this context; the draft defines the ESC byte usage and possible allocation of values following the ESC byte. Hum was taken at the meeting about the following two decisions by the 6lo WG : [o] The IETF will not change the definitions of the code points specified in RFC 4944 and RFC 6282, as published in IANA registry "IPv6 Low Power Personal Area Network Parameters " , in such a way as to affect the ITU-T G.9903 and G.9905 specifications. [o] The IETF 6lo working group offers to collaborate with ITU-T SG15 in establishing a new registry for the code points following the ESC dispatch code. This new registry will be populated at the time of its establishment with the Command ID values as defined in G.9903 and G.9905. The ITU-T SG-15 Liaison was sent to both 6lo and Roll working group – the code-point space is owned by 6lo WG but the decision has an impact on Roll group as well. Thus the same decision was discussed in roll WG. The ITU-T liaison response was due on July 24, 2015. Upcoming ETSI Plugfest on 6lo: Miguel Reina Ortega(ETSI) announced plans for 6lo Interop activity at IETF94 in Yokohama; the event will focus on interoperability. The experts call for designing test specifications and testing requirements are completed. Carsten Bormann and Kerry Lynn were named as the two technical experts for the interop at IETF94. The interop will require at least 2 implementations of the same draft for useful test operations. The ETSI plug-fest presentation slides have the details information on the planning. Details: minutes from Session-1: [Minutes taker: James Woodyatt] -- Miguel Reina Ortega presents on ETSI Plugfest Planning event Robert: ...I think it would be good to limit the scope some... Carsten: Samita: I think we need at least two implementations. MCR: Weekend after the meeting is harder to get network support. -- SG15 Liaison Coordinator and Ralph Droms says, SG15: "We think we are following the rules properly." Ralph: I supervise the liaison coordinator program. Ralph: We have this liaison statement from ITU-T about the ESC and MESH dispatch codes and expressing concern about deprecation of those codes. Ralph: I propose to make a response to the effect that IETF will not make any changes to the protocol specifications, on which G.9903 depends, that will adversely affect G.9903. Gabriel: I wonder if we might call the question after we've seen more slides. Ralph: The second part would be an offer on the part of IETF to collaborate with SG15 to create IANA registry for the ESC code points used by G.9903. Pascal: What is the process we will use for this IANA registry? Thierry: There is also G.9905. It may be difficult to dedicate the ESC dispatch type to just the link type. Ralph: Does G.9905 use different code points than G.9903? Thierry: There are some differences. Ralph: The registry would not be just for G.9903 and G.9905. It would be initially populated with numbers for those. Carsten: http://www.ietf.org/mail-archive/web/6lo/current/msg01155.html Ines: The Liaison Statements: https://datatracker.ietf.org/liaison/1425/ and https://datatracker.ietf.org/liaison/1415/ -- Samita presents about ESC dispatch draft. MCR: We are reserving 255 for future use-- shouldn't we say more? Carsten: Maybe not. Brian Haberman: Advise on the IANA side-- instead of reserving 1-31 for G.9903, register each code for G.9903's specific use. You'll need process for reviewing specs. Jonathan Hui: each kind of link has its own semantics-- shouldn't we have multiple registries, one for each kind of link? For example, it could be safe for 6TISCH nodes to reuse the ESC codes that G.9903 uses because they'll never physically overlap. Carsten: The only thing we have to worry about now is how much dispatch code space to reserve for future use. It's less interesting to define the process for managing the registries. Ralph: We don't have to do what? Carsten: We don't have to reserve the 0 and 255 byte values for future use. Pascal: 6TISCH will be proposing to use a TLV format where some types can be skipped. Ralph: Are these defined so that a device can skip types that it doesn't recognize? Pascal: Yes, for things that it's safe to skip. Gabriel: We need to consider what to do right now, and what to defer until later. Now: define the registries, explicitly recognize that devices currently ignore all packets with ESC dispatch codes they don't recognize. Ralph: Questions-- how many of you are in support of collaborating with SG15? how many want to send the LS back to ITU-T. Hum results: clear support for affirmative on both questions. Minutes from Session-2: [ Minute taker: Sandra Céspedes ] 15:25 --------------------------------------------------------------------- --------------------------------------------------------------------- [Chairs] Welcome, Agenda Bashing, News Status on ITU-T dispatch byte allocation - Working with ROLL WG and AD - Essence of message: IETF won't affect the current ITU-T specifications. - Going forward: discuss 6lo working group. Leave current ESC byte and help ITU register their code points. The WG will work on new ESC bytes. [Gabriel]: to the working group, how many people think we should use another yet unassigned codes for extensions? [Carsten]: Wrong approach. We have a registry, we should only assign what we need. We are doing this not for giving away space, but for solving a problem. [Gabriel]: Should we take a humm? [Carsten]: Not a problem of using the space if it is for something useful. [Gabriel]: Lets postpone the question until after Pascal has presentated the proposals. [Pascal]: - ROLL and 6TISCH require a compression menchanims. - Presents 3 options for going forward: 1 Reuse the mesh space the way it's defined, it is an overcompression. 2 Once the mesh-header has passed, RFC 4944 is done so the space can be reused. Define one value of the dispatch (delineator), and from there the dispatch is open to new definitions 3 Try to fit everything in what is left Second option seems to be the best choice. [Gabriel]: for clarification this will be a new value, so legacy won't know what to do. The only thing we can expect is that those devices drop the packets. If this is defined, they will just ignore the packets if they do not know the type. They will scape a not understood type, because they know the lengh (TLV). [Carsten]: we are trying to solve specific mechanisms. We should make this decision in a very conscious way. How many other cases are we going to have? [Pascal]: RPL will need a compresion (6LOWPAN for RPL) [Carslon]: RFC 7400 does that [Chair(Gabriel)]: How should we call it: let say it is an extensible mechanism (no name at this point). [Chair(Gabriel)]: to the working group, should we define the extensibility mechanism? [WG]: Humm (strong) for defining the mechanims. Cero humm for not defining any mechanism. [Chair(Gabriel)]: Should we have at least one example? [Carsten]: Lets write the documents first. [Gabriel]: We will start developing document by document [Bryan]: We should define those values in the IANA document. [Chair(Gabriel)]: No, we should have the rules first. [Pascal]: And you need to mention in which RFC the type is being used [Robert c]: You can have dispatch pages [Chair(Samita)]: We go forward with the current draft. The working group will work on this, to have at leat one document (hopefully only one) with the requirements --------------------------------------------------------------------------------- 15:50 [Yong-Geun Hong ] Presentation of Transmission of IPv6 Packets over Near Field Communication [Carsten]: This uses interface identifiers, this is a case where we believe this may lead to a privacy problem. [Yong]: Ok,we will consider your coment [Gabriel]: Different modes are mentioned in the draft. All those modes are implemented in all phones? [Yong]: Some may not support all modes. Depends on the product. Until now it is only used for payment [Gabriel]: have you heard from the NFC forum? [Yong]: They have been contacted, no response so far [Erick]: Why do you need a 64-bit interface ID? [Yong]: We follow the generic IP compression in 6LoWPAN. There are pros and cons. We can continue disucssing how to handle the issue --------------------------------------------------------------------------------- 16:00 [Dominique Barthel] Presentation of Transmission of IPv6 Packets over DECT Ultra Low Energy (ETSI standard, technology was presented in IETF88, used in cordless phones) - it is almost same as 6lo-blte - Only intends to register one Interface ID per prefix - Updates have been made according to the comments - Following discussions about privacy - Authors think it's ready for LC [Chair (Samita)]: Any objection on going for LC? [WG]: No objections [Carsten]: No objection, but has this been through an interop test? We shouldn't finish the document before the interop [Chair (Samita)]: That is true, but we have passed other documents without any interop testing. [Dominique]: Agree it's better to have an interop test, but it will be better to have a stable version of the documents for the vendors to have interest to come to the interop test. [Pascal]: Held the document from the IESG while the interop is done. Do the last copy/paste from BLTE [Behcet]: What type of mac address you are using? [Dominique]: Some 48bits, some 20 or 22. We extend those, or use dinamic allocated from the base station. We don't mandate any of these --------------------------------------------------------------------------- 16:08 [Dave Thaler] Presentation of 6lo Privacy Considerations - Intention is to describe what should be covered about privacy in the documents. Not talking about solutions. [Bryan]: Will these recommendations change depending on the device? [Dave]: Yes, it depends on the type of device [Subir]: The assumption is that privacy is a requirement. Then this should be a requirement. [Dave]: You only have to explain how to mitigate the threats. [Subir]: In certain use cases making privacy a requirement can be difficult because whatever mechanism is used the threats cannot be mitigated. For that kind of cases, providing privacy can be very difficult. [Samita]: This is good because now it's clear how to write those sections in the documents. What happens if you have a link layer that is already secure? should you still provide privacy by changing addresses? [Dave]: Yes. because that only works on the link layer. If you go to another network, a device can be tracked, address scanned, etc. [Yong]: I don't belevie address scan can be useful in NFC. It must be case by case. [Dave]: That is why you go case by case. [Robert C]: This is for addresses you use to communicate with the Internet? [Dave]: Yes, the Internet or any untrusted network. Location tracking may happen even if you don't go to the Internet [?]: It may be a little less dangeours if it connects to a private network (not local but not the Internet either). You may have a definition for what to do in a global scope, but in internal networks you can optimize compression by using addresses that can compress better and you are not worried about privacy and location tracking. [Bob M.]: There are concerns even if you say you scope is only local. You are keeping some local log in a box, and that box which does have a global address is vulnerable. If there is any permanent seed for the device, we need to limit trackability. [Chair (Gabriel)]: Is the document going to be informational [Dave]: It currently covers two disjoint things. Let me do the split, and I will ask for feedback for the one that says how to include privacy recomendations in a document. ------------------ 16:36 [Subir] Presentation of An Extension to MLE for HIP DEX [Robert]: There are a couple of existent extensions, make sure there are no conflicts [Subir]: We have also identified some reviewers for this document [Michael R (Jabber)]: IETF94 question mark about interop test [Subir]: We can disucss another plugfest [Bob]: HIP DEX uses ECDH MAC instead of hash MAC. This is the first document that uses it (little cryptographic material). It is highly workable in highly constrained devices. IEEE 802.15.9 has been approved and will be published soon. [Subir]: There is IEEE and IETF coordination for getting the draft of 802.15.9 before it gets published [Chair (Samita)]: How many have read the document? [WG]: Several hands raised [Chair (Samita)]: Any objection in adopting the document as experimental RFC? [WG]: No hands raised [Chair (Samia): We identify no objections in the group. We will send email to mailing list. ------------------------------------------------------------------------------- 16:49 [Ines Robles] Presentation of Transmission of IPv6 over IEEE 802.11ah [Samita]: How will the mesh transmission happen? [Ines]: We need to look into that in more detail because we don't know yet, they only define star topology. There is only 6loBR and 6Lo nodes, we don't have 6lo mesh routers. [Pascal]: Do you have the concept of ESS in 802.11ah? [Ines]: I don't know if they have it [Gabriel]: it doesn't seem to different from 802.11 [Ines]: The standard is still work in progress. [Gabriel]: Will the devices get confused at all if there is also a traditional 802.11 network, or they are completly different? [Ines]: No, they have different physical layers [Gabriel]: Is good to have in the draft that they won't talk to other 802.11 devices. Will IEEE review the draft? [Ines]: yes and they already sent some comments [Stanley]: I'm the Liason for IEEE to IETF. This is an independent technology, the protocol version has changed. Link layer is different, devices won't get confused. Think about putting 6LoWPAN through 802.11? IEEE is willing to work with the authors of this document. [Gabriel]: This is the first time 802.11ah is presented at the IETF? Can you explain a bit more? [Ines]: In the IEEE they have defined some use-cases (e.g., smart meters). There are no implementations so we can only guess the application scenarios. [Chair (Samita)]: Update document in the applicability section. Keep updating the draft. --------------------------------------------------------------------------------------- 17:06 [Shahid Raza] Presentation of Compression of IPsec AH and ESP Headers for Constrained Environments - Justification for using IPSec in 6lo - Use extension headers for IPSec [Bob]: how this compression compares to rhc compression? whay using a different ASCCA? security at different layers is because different liabilities [Shahid]: IPsec is not better than link or transport layer security. This is a solution. Responses to the other question in the mailing list. .--------------------------------------------------------------------------------------- 17:15 [Randy Turner] Presentation of DHCP configuration of RFC 6282 compression contexts [Pascal]: DIOs are good to spread out things. [Randy]: I agree, DIOs shouldn't be overloaded, but it is good for things that are common to several nodes. But I can't guarantee that every node in the network needs the same configuration. [Carsten]: DIOs are options, the real protocol is ICMP. There is an ICMP option in 6lowpan to configure options. There is no reason why you couldn't use that [Randy]: The deal with DHCP is that we already need it. We decided it will be cheaper from implementation perspective. It's not just the configuration of compression context. [Chair (Samita)]: Looks like this is a particular deployment scenario. It is something that you want for your own deployment but 6LOWPAN is infrastructureless [Randy]: We wanted to present to know how the group feels about this [Carsten]: You are already sending the DIOs, why not doing the CCO options in those packets? [Robert]: You have an overlap anyway. It makes more sense to use DHCP. [Pascal]: RPL started as part of ND. RPL is sort of an ND for multihop, it transports RAs [Subir]: In large deployments DHCP is already there, then it can be used to have a simple option for the compression context [Pascal]: we have experience with DHCP and ND, it slows down the network. There is a tradeoff to be found [Randy]: We have a very large network, about 5000 nodes. We will aslo consider DIOs. 17:20 Wrap up.