Skip to main content

Minutes IETF102: 6lo
minutes-102-6lo-01

Meeting Minutes IPv6 over Networks of Resource-constrained Nodes (6lo) WG
Title Minutes IETF102: 6lo
State Active
Other versions plain text
Last updated 2018-08-21

minutes-102-6lo-01
 IPv6 over Neworks of Resource Controlled nodes (6lo)
          IETF 102, Montreal, July 17, 2018
           Time: 1:30 - 3:30pm

Minute takers, Jabber scribe: Ryan Hu, Rahul Jadav

Chairs' slides (slides-102-6lo-chairs-slides-01)

    The chairs started with the agenda bashing and document status.

    New draft on IPv6 on PLC

    new proposal from Stanford U.

    RFC6775-update long IESG review, Pascal processed the comments, now ready
    for Suresh

    6lo AP work in progress and 6lo-backbone-router is prepared for WGLC

    6lo-nfc had a revision after more comments from the shepherd, getting ready
    for IESG submission

    6lo-blemesh has made progress in their implementation and draft updates and
    6lo-deadline-time
      has passed WGLC.

    Kerry: question on the Stanford proposal, would it more suitable to LWIG?

    Samita: will be presented here, not sure about LWIG

    Gabriel: Might have some protocol relevance, that's why it's also presented
    here

    Update also mentioned conclusion of fragmentation DT

[13:39]

RFC6775-update (Pascal)

    https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-21

    Discusssed the IESG reviews.

    Provision enough resources to the network

    better definition on ROVR. Split definition and operation texts to relevant
    parts of the document

    Pascal still to check with Ekr is happy with the outcome.

    normative ref to a terminology that is informational (down ref). How to
    handle that?

    Terry: Talk to Suresh (AD) and he can authorize.

    extensive editing by Charlie.

    ROVR field can be over 126bits. Variable size, inferred from DAR size.
    No longer possible to extend with options.

    now size of ROVR explicitely indicated in the ICMP code.

    Now use RPL device can be injected into networks

    New term routing registrar.

    The Opaque field , used for InstanceID for RPL or RIFT

    I field indicates what the Opaque filed is about.

    Kerry Lynn: if you have thought about using this registration into
    classical ND?

    Erik Nordmark: tried it for years and gave up. Thought 6LoWPAN is another
    universe other than Wi-Fi. DAD is expensive.

    Pascal: Lorenzo asked for changes, which we made.

    Pascal: Wifi spec mandates use of ND. There is no spec for it. Sometimes
    takes 10 years, so we'll see.

    Lorenzo: How the AP processes these messages?

    Pascal: let's look at that.

    Lorenzo: Not specificed as you like.

    Samita: Some questions should discuss again with ADs.

    Pascal: Let's create all these amendaments.

moving on to AP ND
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06

    Ekr is happy now that we have longer ROVR >64 bits

    There were left-to-right right-to-left problems we solved. We fixed so the
    truncation is the same.

    aligned options to SEND, reused codes and fields.

    There are discussions about how we use the key.

    Abdulassum (on Jabber): is this implemented?

    Pascal: Right now we should focus on backbone now. Then give us time to do
    security

    Added an ECC variation of the RSA Signature Option from SeND (rfc3971)

    Mohit: we need one more iteration before being ready

    Pascal: we should focus on BBR first and then come back to ap-nd

Move on to Backbone Router
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-06

    Recent changes: R flag, clarifications.

    Samita: How many of you have read the draft? 4 or 5. We'd like to request
    volunteers for review

[14:10]

IPv6 Mesh over Bluetooth(R) Low Energy using IPSP (draft-ietf-6lo-blemesh-03)
(Carles) https://tools.ietf.org/html/draft-ietf-6lo-blemesh-03

    Take a look at the status of the doc. Previous version has been stable so
    it's not updated for a while

    First approach: using Raspberry Pis with BlueZ as its BLE stack (some
    issues on handling simultaneous connections. BlueZ did not work for one
    master (6LBR) and several slaves (6LNs)

    Second approach: BLEach in Contiki using CC2650 devices. made it work.

    Main authors of BLEach now co-author: Michael Spork and Carlos Alberto Boano

    As a result, a 6LoWPAN over BLE ND setup is tested. Setup starts with the
    6LBR running as a IPSP router, and other 6LR/LN nodes are not initialized.
    At last, link layer connections are established.

    Pascal: is it layer 2 or layer 3 mesh?

    Carles: IP routing. Routing protocol not specified, left open in the draft.

    In the related Bluetooth SIG work, RFC7668 assumes link-layer connection
    over BLE.

    Samita: this is WG document. Do you think we eneed to revise it more?

    Carles: getting more feedback would be great. Also advance implementation
    to get experience with it.

[14:23]

6lo Applicability (slides-102-6lo-6lo-applicability-00) (Yong-Geun Hong)

    this document is informational, intended at new adopters of 6lo.

    Two parts were deleted: LTE-MTC (as it supports IPv6 transmissions),
    6lo-PLC ref (expired). Hope 6lo-PLC to be adopted as a WG.

    Updated HomePlug Powerline Alliance section.

[14:28]

IPv6-over-NFC (slides-102-6lo-ipv6-over-nfc-00) (Younghwan Choi)

    version -10 of the draft.

    no feedback from NFC Forum since Jan 2017!

    shepherd review (Samita) July 2018.

    Shepherd's comments were addressed: MTU, link description, Frag and
    Reassembly, Security     considerations.

    Chairs decided to go for a one-week WGLC. Will start soon. Please provide
    comments.

[14:34]

IPv6-over-PLC (slides-102-6lo-ipv6-over-plc-00) (Remy Bing Liu)

    recently added IEEE 1901.1 (published May 2018) in scope of this draft

    Address auto-configuration and mapping mechanism addressed.

    IEEE 1901.1 has various new features.

    Kerry Lynn: is this for link-local or routable traffic?

    It can be used for multiple link traffic, routable is ok.

    Kerry: beware of exposing IID in routable traffic, might wish to follow
    6lowbac for privacy considerations

    MAY use ODAD (RFC4429)

    Included RFC6775-update new features to PLC devices

    Believe draft is ready, Will call for WG adoption

    Samita: We need more people to read the draft for WG adoption.
    Please read the draft and send comments through the mailing list.

[14:46]

6lo Fragment Recovery (slides-102-6lo-6lo-fragment-recovery-00) (Pascal)
https://tools.ietf.org/html/draft-watteyne-6lo-minimal-fragment-01             
  https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-08

    The "minimal" draft highlights limits of VRB (virt reassembly buffer)

    two parts: how to forward fragments, how to recover them

    Recovery: uses a bitmap indicating which fragments were received.

    Introduced windowing for congestion control.

    IP addresses compressed with knowledge of MAC address does not work at all
    hops. Creates change in fragment size. Need slack.

    Rahul: implementing this in ? (Contiki?)

    Pascal: You put slack in the first(?) fragment. Yes, I think we should
    mandate it.

[14:52] 6lo fragmentation DT (Thomas presenting remotely)

(slides-102-6lo-6lo-minimal-frag-00)

    3 drafts, one at LWIG and two at 6lo.

    Design Team to be closed after adoption. The draft at lwig is adopted,
    the two at 6lo not adopted yet.

    will request adoption

    Gabriel: anybody objects to asking for adoption? none

    Gabriel: will be confirmed on the mailing list but want to get a sense in
    the room. Raise hand if in favor of adoption. Saw 15ish (good propostion of
    attendance in the room) I think we are gonna go ahead.

    Samita: for the record, no objection in the room.

[14:56]

Design Considerations for Low Power Internet Protocols (Hudson Ayers)
(slides-102-6lo-design-considerations-for-low-power-internet-protocols-00)
draft is available, see agenda

    Motivation: Interoperabililty is crucial for 6LoWPAN

    Contiki, ARM mbed, Riot, TinyOS, openthread

    An informational I-D is prepared for this.

    From the 6LoWPAN interoperability study, many(?) features are found
    mismatched.

    believes that device hw constraints are predominant cause for
    non-implemented features or incomplete implementations

    evidence found in source code comments

    Embedded OS's implementations vary a lot, in terms of power, code size, etc.

    Power consumption (on the radio devices) can be reduced at the PHY and MAC
    for example. The cost is the need for compute power, usage of RAM, etc.

    Guideline 1: no silent drop. Explicit mechanism to tell why packet was
    rejected. ICMPv6 or 6LoWPAN ND message.

    Guideline 2: advertise capability. Suggest a strucutre of 6LoWPAN features
    with six classes.

    Lower classes have more energy saving. Higher classes add more flexibility.

    Guideline 3: reasonnable bounds on assumptions for RAM/Code needed.

    Guideline 4: dont break layering

    disallow the UDP checksum elision in RFC6282(TinyOS is the only one that
    implemented UDP checksum elision).

    Pascal: regarding advertising capabilites, there are bits available in
    6LoWPAN ND

    Pascal: more difficult is to provide interop info.

    Pascal: some other systems do UDP checksum elision.

    Hudson: There are classes of devices . Lower devices classes will implement
    lower classes of features. Only the more capable devices will take up the
    larger code sizes required to implement all the features.

    Gabriel: really interesting document, survey, design considerations. In the
    real world, they may take some hints from an RFC but won't adopt it all. No
    garantee that device manufacturers will comply with what we write.

    Phil Levis: is that what we want the 6LoWPAN to be? We could think about.

    Samita: (Chairs) thank you for doing this work from your team and coming up
    with the possible solution. Idea of having the capabilities is great. Maybe
    it could be used for some applications.

    Pascal: If the 6LoWPAN would be ended up with the open-source
    implementation, that's okay.

    Pascal (responding to Phil) a big of list of choices as silos, I don't
    believe the nodes would talk to each other just like this.

    Gabriel: is there anything simpler we could do to help people understand
    what to implement so that it works interoperably

    Thomas: it's much more than 6LoWPAN that makes things talk to each other.

    Terry: I really like the ICMP idea. Learn from IETF BGP efforts. Coming
    back with running code and solid docs will be good. IETF has lots of
    experience at protocols for advertising/discovering capabilities. Learn
    from that.

    Samita (responding to Pascal): charter of this WG not just  header
    compression, but any improvment to IPv6 protocols for constrained
    environmenets.

    Thomas: F-interop platform for interop tests. Try 6TiSCH or 6LoWPAN
    interoperability test.

[15:34] meeting adjourns