Minutes IETF97: 6lo
minutes-97-6lo-00

                        6lo WG Meeting IETF97, Seoul, S.Korea
                        TUESDAY, November 15, 2016
                        15:50-18:20 Local Time
                        Grand Ballroom 2

                 Chairs: Samita Chakrabarti, Gabriel Montenegro
                 Secretary: James Woodyatt
                 Responsible AD: Suresh Krishnan
                 Technical Advisor: Ralph Droms

                Etherpad  Minutes takers: Dominique Barthel, Thomas Watteyne
 -------------------------------------------------------------------------------------------------------------
 IETF97 meeting started by co-chair Gabriel Montenegro. The other co-chair
 Samita Chakrabarti was remote over Meetecho. 6lo WG secretary James Woodyatt
 was also present along with Gabriel on site. After the initial agenda bashing,
 Gabriel and Samita provided the draft status of the working group since the
 last meeting. 6lo WG had made very good progress since IETF97 with the help of
 AD and the INTAREA community reviewers.  draft-ietf-6lo-ethertype-request has
 become RFC7973 and draft-ietf-6lo-paging-dispatch was also on RFC editor
 queue. Draft-ietf-6lo-dect-ule, draft-ietf-6lo-6lobac,
 draft-ietf-6lo-dispatch-iana-registry and
 draft-ietf-6lo-privacy-considerations have been submitted to IESG and all of
 them are on IETF LC on the week of IETF97. 3 drafts have been adopted as WG
 documents. They are:
    • draft-gomez-6lo-blemesh-02
    • draft-hong-6lo-usecases-03
    • draft-sarikaya-6lo-ap-nd-04

 Gabriel provided updates on MLE-MESH documents that there is still hope that
 this document needs some update and hopefully the update will be made soon and
 go forward in the WG. Suresh Krishnan, responsible AD  provided status on
 ethertype document which was waiting for sometime to receive the IANA
 assignment before final publication. Dave Thaler discussed the comments on
 generalizing the privacy document – no changes have been made as it targets
 the constrained nodes. The privacy document addressed AD review comments.

 Samita provided update on 6lo-6lobac draft based on the slides provided by
 Kerry Lynn. The document addressed AD review and other reviews during the IESG
 review process. Most notable change is in section 3 where all multicast
 packets are now MUST be broadcast (instead of SHOULD).

IPv6 over NFC: draft-ietf-6lo-nfc-05  was presented by Younghwan Choi :
 He discussed some of the comments received from NFC forum. Main changes in the
 draft are in MTU extension plus examples of topology and application.
* IID generation. Thanks to Dave for feedback. Comments taken into account.
Added discussion on link lifetime and IID lifetime.
    * [Dave Thaler] still potential issue around word "random"
        * if endpoint specifies the hash function, we can recover the IID.
        * suggestion: pick a specific hash function and inputs, you can get
        full compression * you should be able to use every bit excetp "u",
        don't keep all these 0's as in the current figure.
    * [Suresh] question for Dave: how do you expect the shared "secret"
    * [Dave] NFC already does something, we shouldn't invent something
    different but reuse * no more comments from NFC forum so far. * [Pascal] no
    comments, does it mean NFC forum will now reference this doc?
       [Younghawn]: will ask comments for the last version of this doc.
    * [Younghwan] they deal with lower layer, we deal with upper layer. They
    don't have to reference our work. * [Gabriel] how many round-trips of info
    with NFC Forum? * [Younghwan]Feedback received only once. * [Gabriel]
    beware that more may come. Let's wait for a new revision which incorporates
    the privacy proposal from Dave Thaler,
       and go to WG LC after.
    * [Samita] asks Suresh for advice on going forward with NFC forum
    * [Suresh] we don't have a formal way of talking to NFC Forum, a common
    participant might go present it. Don't want anything
      too heavy but can look into it.
    * [Gabriel] they are aware of the work, already provided feedback, so ...
       IPv6 over Bluetooth Low Energy Mesh Networks : Carles Gomez presented
       draft-gomez-6lo-blemesh and provided status on the comments
      from BT SIG.
  * status:
        * -01 in individual was presented in Berlin. Comment was that should
        contain BT SIG * -02 submitted after feedback from BT * The document is
        now adopted by WG, this is now -00 of WG doc * Mark Powell Exec
        director of BT SIG. Thanks to chairs for establishing contact with BT
        SIG. * several people including Mark Powell provided comments on this
        document * one request was to avoid confusion with BT Smart Mesh
        activity taking place at BT SIG, therefore request name change.
    * The document  title  was changed as a consequence, also explicit mention
    of IPSP in abstract, and more detailed explanation
      in Section 2.
    * terminology updates throughout document using phrasing alternative to "BT
    mesh" * reference to RFC 7416. Enumerate threats and countermeasures. *
    asking audience to read doc and provide feedback, and to implement and
    provide experimental feedback. * [Rahul] BT mesh vs. BLE mesh, wich doesn't
    support multicast. Explain the consequences.

 6lo Applicability and Use Cases : dreaft-hong-6lo-use-cases status update by
 Yong-Geun Hong :
  * history of doc: since IETF89. Presents comments received during adoption
  call. Reproduced on slides, in extenso.
    * doc currently describes 7 technologies, with inputs from each technology
    experts. * characterizes them along 12 axes. * one practical market use
    case described for each technology. * since IETF96, updated introm updated
    MS/TP, increased design space dimensions * work coming up: update of MS/TP,
    6tisch, LTE-MTC. Refer to detnet. Should we consider LPWAN as a use case?
      Security considerations in general or for each use case? Add a comparison
      table.
    * next steps: will submit as WG -00 doc
    * [Samita] LTE-MTC: don't know of any 6lo implementation or project of
    LTE-MTC. * [Yong-Geun] at South Korea Telecom, IPv6 over LTE-MTC
    implementation, but not a commercial product so far. * [Samita] will ask
    the WG if we want include LTE-MTC in this work. * [Yong-Geun to the
    audience] if your company has expertise or development, let us know.

  An Update to 6LoWPAN ND : draft-thubert-6lo-rfc6775-update was presented by 
  Pascal Thubert :

    * The work was extracted from backbone router document. decided to split
    the update to RFC6775 out of backbone router
      doc. Personal submission but text  is quite mature.
    * backbone router draft will be cleaned up as soon as this is adopted.
    * ARO is extended. TID is seq num. Was already presented in efficient-nd
    draft preseted at 6man. * Registering the target address is now supported.
    Allows doing proxy registration. * After last IETF, discussion. Decided not
    to change the link model. * No more DAR/DAC exchange between 6LR and 6BBR,
    removes need to store address pending validation in separate neighbor
    cache. * there was discussion about link model, decision not to change it
    has been made. Rest is stable text from backbone-router draft. So, the
    authors are asking for adoption.

    * [Carsten] what process for getting 16 bit address? [Pascal] done before
    ... * [Carsten] we can talk about this offline. Need to understand * [James
    ] had criticsm about 6775. Large deviation from regular IPv6 ND. Now this
    draft is an update to 6775.
      Time to describe this as a protocol totally independant from IPv6 ND?
      Should say somewhere that this is ND for 6lo, not to be used for regular
      IPv6.
    * [James] get more contribution from 6man. [Pascal] or work at 6man to have
    it adopted alongside IPv6 ND.
      [ James] would object. Don't want address registration in the whole IPv6
      world. Still discussion at 6man? Not lately.
    * [Lorenzo] answer that efficient-ND got from 6man was "not on my network".
    I don't want to see this on networks that are
       not constrained. Constraining addressing is giving a lot of IPv6. We
       should scope this work so that each WG ...
    * [Carsten] will repeat some of the history. 6lowpan-nd was developed
    because there are networks on which multicast is not cheap, which IPv6 ND
    assumes. Can imagine that people that have networks on which multicast is
    cheap don't want to redo work. No intention to conquer the rest of the
    world with this. We just need a way to build ND without multicast. *
    [Samita] if this doc is used for 6lo network, don't need to generalize its
    use in 6man. I don't see a conflict. * [Pascal] no constraint is placed on
    the IPv6 address that is registered. * [Erik] not a big facn of
    non-technical discussion at the IETF.  Doesn't make much sense. AD's decide
    what WG work on what. * [Lorenzo] was technical. Concern raised in 6man was
    that ... ? * [Erik] philosophical concern, not technical argument. *
    [Lorenzo] we do have a BCP that says it's a bad idea to limit the number of
    addresses you have. If it's a L2 characteristic,
      fine. Increasing trend to giving prefixes to hosts, at 6man and 6ops.
    * [Pascal] a prefix per host is depriving network of resources.
    * [Suresh] for general purpose hosts, allocate prefixes. But not for small
    IoT device. * [James] my concern has technical consideration. Add a bunch
    of IANA codes in registry, they are specific to 6LoWPAN ND.
       What happens if you see them in ND tha this not 6LoWPAN? Pick your own
       tables, not the general IPv6 ND tables. So don't have to ask for 6man to
       review it. Don't call it ND, it's doing something else.
    * [Suresh] do I understand you want to subtype what we already have?
    * [James] make new ones
    * [Suresh repeating James] fork the space nbetween 6LoWPAN ND and IPv6 ND.
    * [Erik] where to you want the fork?
    * [James] make different registries. With same numbers.
    * [Erik] is it not sufficient to have comment in common table saying it
    comes from RFCxxxx so that it's for 6LoWPAN ND?
      [James] yes
      [Erik] well, we already did it.
    * [Carsten]
    * [Lorenzo] possible to havw a container for 6lo options. Better than
    entirely forking space.] * [Suresh] opposed to forking without having a
    space to * [Erik] increasing divergence. Reason is interesting. Attempt at
    folding some ne stuff back into 6man to make it more
      common failed for philosophical reason.
    * [Gabriel] hears questions about scoping, when does this apply? when
    multicast is expensive. Don't oversell. We could
       have 6man review, with AD support. Some concerns about scoping?
    * [Pascal] don't think so. We know where this applies.
    * [James] language in the draft says that intended for constrained network;
    but no text that says "not for non-constraint" * [Pascal] don't agree, why
    not? * [Carsten] other specs (e.g. IP over Ethernet) don't mandate the use
    of this * [Lorenzo] making engineering trade-off between paying the cast of
    multicast and functionality you get. Trade-off may
        not be beneficial on constrained devices.
    * [Gabriel] can we clarify those points before we call for adoption
    * [Lorenzo] if we said where this does not apply
    * [Gabriel] its the IP-over-foo argument. It's up to foo to decide what to
    adopt. * [Bob Hinden] righ now on classical networks, we have 2 ways for
    "registering", if we announce this, will hurt the
       adoption of IPv6
    * [Gabriel] could 6man state that for non-constrained don't use that one
    * [Bob] need to think, but would not be useful for the general objective of
    deploying IPv6 * [Carsten] there is no third kind * [Erik] this is for DAD
    and address registration while you're asleep. Not address allocation. Can
    use SLAC. * [Suresh] AR already exists. ARO is in there. This is adding
    transport for it. No more time for philosophical opposition to ARO. *
    [Gabriel] humm to support adoption? humms heard. * [Gabriel] "Humm if you
    do not think this should be adopted". No humm heard. * [Gabriel] Will bring
    it to the mailing list.

  Designating 6LBR for IID Assignment  : draft-rashid-6lo-iid-assignment-02
  (Charlie Perkins):

    * Idea: have the LBR suggest an IID is the DAD fails, helps the node,
    reduces traffic and energy * new version contains a solution to forward
    that compressed * "Cycle" to count number of DAD failures, on 4 bits *
    version -02 posted recently, doesn't mandate use of RFC7217 but if you do,
    recommendations * comments received was "why do we need this, collisions
    are rare anyway". Added text to show why it matters.
      several reasons, listed on slide.
    * goes through advantages of this proposal over current ND.
    * [Michael Richardson] DHCP. Multicast from address that nobody knows.
    Ethernet solves this by L2. * [Dave Thaler] where does the 6LBR get the
    Interface .. ? * [Charlie] * [Dave Thaler] did you say 6LBR runs 7217? I
    thought 6LN doesn;t ahve to generate IID. * [Charlie] it does and tries to
    register this address. Only if 6LBR sees collision, suggest another
    address. * [Dave Thaler] rephrases. How does the 6LBR get .. info .. from
    6LN? * [Dave Thaler] need to say mechanism only work if one interface only,
    or ... * [Dave Thaler] 7217 has provision for several network interfaces.
    This mechanism, 6LBR doesn't known how to * [Dave Thaler] * [Pascal] you
    need to "book" <???> * [Erik] 62 bits of randomness, what the motivation?
    danger is that we are inventing a new allocation policy, not duplicate. *
    motivation: networks can become very large * see slides for discussion why
    you have less randomness than you would think. * [Erik] not using MAC
    address as the main key. Devices have hardware random generators, for key
    generation e.g. * [Michael] difficult is to have a stable identifier. *
    [Erik] unless billinos of deices in the same network, collisino prob
    extremely small. * [Lorenzo] this is device saying "I want ot use ID A" and
    network responding "no, you'll have ID B". Network has better
       resources and storage, so let's make it that the device asks for an
       address.
    * [Carsten] lloking for a reasono to do this? Origianlly because trying to
    get a 16 bit address by regsitregin ... Random
      16 bit address only fine up to about 2^15 devices. That's wy this work
      got started.
    * [Charlie]
    * [Carsten] doesn't make sense in MS/TP, nor 15.4
    * [Lorenzo] why an XOR in slide 4?
    * [Carsten] original problem was most nodes are sleeping, can't find out
    who's there with address equal to tentative address.
      Registering at a router solves this.
    * [Gabriel] short on time. Follow up on the mailing list

Packet Expiration Time in 6lo Routing Header: draft-lijo-6lo-expiration
(Charlie Perkins):
    * New draft, for delay sensitive applications
    * There is some history in other WGs, e.g. 6TiSCH
    * Charlie presents idea on slide 3
    * [Thomas] dropping a packet on expiration is one thing. Knowing how late
    it  is of interest
       in a control loop.
    * [Pascal] on slide 4, elective header needs a size header, one bit is not
    enough.

At this point, only a few minutes were left and Carles Gomez presented
Optimized 6LoWPAN Fragment header in  a nutshell. 6LoWPAN Fragment Header: *
Originally motivated by some LPWAN technologies with very small paylod and no
L2 fragmentation.
    The work was presented at LPWAN, suggested for this to be considered at 6lo
    *  6LoWPAN fragmentation characteristics  are defined in(RFC4944)
    * proposed format has 2 bytes header for both first fragment and subsequent
    fragment. First fragment header contains datagram
     size, subsequent ones contain offset instead
    * Reodreing was considered likely in 6LoWPAN, hence the datagram size in
    each fragment to help decoder. Yet still possible without
      it.
    * Alllocate dispatch values for first fragment and subsequent fragments,
    amounting to 16 codes in the 6LoWPAN table. * Discussion of possible
    attacks on the receiver by exploiting the fragmentation/reassembly
    mechanism. Mitigation suggested * asks WG if interest? * [Carsten] great
    work. But is this worth 16 dispatch codes? Also problem with title
    "optimized ...". The first one was also
      optimized, only for a different set of assumptions. Less interoperability.
    * [Pascal Thubert] Happy to revisit the fragment work. Big picture
    questions need to be addressed. What do you do when you lose
      a fragment? What about route over mesh A stream of fragments may be
      creating congestion. Not just about saving a bit here and there.
    * [Carles] agreed. Goal was to have light weight approach. And support
    small L2 MTU's. Agreed for considering the big picture.