Minutes for 6LO at IETF-96
minutes-96-6lo-1

                         6lo WG Agenda - IETF 96, Berlin, Germany
                         10:00-12:30 Local Time  MONDAY, July 18, 2016
                         Potsdam III

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

Minute takers: Zach Shelby, Dominique Barthel
Jabber scribe: James woodyatt

Chairs: Note Well

Chairs: Update on WG draft status since IETF95
•       Two drafts in IESG processing
        Suresh: dect-ule awaiting AD review
•       Three drafts past LC
•       Three other WG drafts

Chairs: Liaison from IEC/JTC-1, IAB has recommended pursuing an informal
relationship

draft-gomez-6lo-bluemesh-01 (Carles Gomez)
        •       Objective is not to request new work from BT SIG.
        •       Restriction with the use of multicast in BTLE: actually n-way
        unicast. Problem mitigated by
                remembering subscribers to "multicast".
        •       Additional security considerations added, including routing
        protocol attacks using RFC7416 as a guide •       Tentatively asking
        for WG adoption

        •       Samita: who has read the draft? 3-4 hands. Is BT SIG aware of
        this work? yes.
                Do people in the room think this is intereting, please humm?
                significant humm.
        •       Don Sturek: How do you deal with prefix delegation, which
        requires multicast in RFC6775? o       Carles: We don't cover this
        feature in the draft yet •       Ari Keränen: relation beteen this and
        work at BT SIG? o       Carles: not a member of BT SIG. This extends
        RFC7668--They might be using other mechanisms,
                our position is that we can enable mesh by adding very little
                to the current RFC; won't harm anything the're doing.
        o       Ari: recommend to clarify this with BT-SIG.
        o       Dave Thaler: this WG should work on IP-over-foo
o       Suresh: Talked to BT SIG, said they don't work on IP. Can send mail to
BT SIG again to check. o       Gabriel: Do you think we can do WG adoption in
parallel to talking to BT SIG? o       Suresh: Yes and be ready to drop it. o  
    Dave: Doesn't see a reason to delay WG adoption while figuring out the BT
SIG angle •       Samita: More people to read the draft before we ask for
adoption.

draft-ietf-6lo-6lobac (Kerry Lynn)
•       Kerry provides background on this work.It is an wired alternative of
IEEE802.15.4 •       two implementations, Plugtest in Yokohama, Wireshark
dissector, 3 thorough draft reviews. •       Samita: will submit to IESG

draft-ietf-6lo-privacy-considerations (Dave Thaler)
•       Goal:  Guide for IP-over-foo specification writers
              o Whenever possible IP-over-foo should not limit what protocols
              run on top o •       Should be designed to not assume a firewall
              is in place
                         (sure a fw can be used to mitigate some privacy issues)
•       describes changes made following draft review, as well as proposed
changes not retained and why. •       Dave asks for contributions for better
phrasing of a particular sentence,
        explains motivating considerations.
o       Gabriel: could the text provide the motivating considerations as well?
o       Kerry: don't think this is an issue. If short addresses are assigned by
controller in a non-stable
        network, they won't be carried across networks by the node. And if
        network stable, tracking is not
         an issue eather.
        Kerry's review has been taken care of
                o Address scanning not relevant to link local addresses, only
                to routable addressses

                o Distinguish between on-link and off-link
                o Reduce emphasis on "46 bits" which was the example for links
                > 8 years

•But location tracking might be an issue-- need enough bits to mitigate this
LL addresses changing over time
        •       On-link: have to change link-layer address too
        •       Off-link: useful if LL addrs can leak in higher layer protocols
        •       known to happen from observation, by accident, a lot, with,
        e.g., smtp, sip, dns, etc •       Important to NOT assume they won't
        leak, but it may be less common

Kerry: Agree this might be a whole, but just like buffer overflow problems, it
is a matter of education



•       Dave: about the use of DHCPv6 for temporary addresses.
o       Ralph Droms: RFC3315bis is in progress, this potential application
would be interesting for
        the authors
o       Dave: This is to advise draft authors as to what issues to consider,
not provide technical solutions o       Suresh: xxx draft. Dave: checked this
one, does not pertain to this. o       Juan-Carlos Zuniga: consider work at
6man and IEEE802 about changing MAC-addresses for privacy o       Tim Winters:
RFC3315bis currently says it is not recommended to renew temporary addresses o
o       Samita: regarding IEEE recent changes, is there a document? Dave:
referred to it in -00 version

        Chairs: Document will go to WGLC after the meeting.

draft-ietf-6lo-dispatch-iana-registry (Samita)
•       Changes since IETF95 include new Shepherd (Brian Haberman) and the
draft addressed shepherd's comments o       New title to reflect the content
Not just define codepoints but also provide guidelines about the allocation of
dispatch bytes. o       Clarifies that the document updated RFC4944 and RFC6282
o       Updated draft ready this week, then going for IESG submission •      
comments? none

draft-ietf-6lo-paging-dispatch (Pascal)
status of doc
•       James Woodyatt: currently writing the shepherd writeup; not yet
completed •       Suresh: just get it done, doesn't need to be perfect.
questions? none

draft-ietf-6lo-backbone-router (Pascal)
3 parts in doc including update of 6775
Two implementations tested this week at ETSI plugtest.
Interop tested in Berlin (ETSI) on Fri-Sat
•One open source (openWRT)
•One Vendor (Cisco)
•Tested with openWSN as client

This draft is thick. Extract 6775 update and make it a separate draft?
Gabriel: question to Juan-Carlos? what is the status wrt to IEEE? Pascal:
regarding  the broadcast JCZ: will provide recommendations, and document in
interim. This is not blocking. Good idea to put
      out this document for other communities (such as IEEE) aware of this work
Questions?
Samita: another presentation later on proposed split.
Pascal: this doc is really 3 in 1. Suggestion to the group to split in 3
documents

•       Update to 6775, registration
•       Informational on BBR
•       Prescriptive stuff

Samita: Make your suggestion on the mailing list for discussion.

draft-ietf-6lo-nfc (Younghwan Choi)
Point to point comm at link layer.
Discusses updates following review.
•       Participated in two ETSI plugtest with two implementations
        Requested review by NFC forum, but not a member and no official
        IETF-NFCforum liaison,
         so still waiting for comments. If anything received, will consider for
         updating this draft.
Asking for WG LC anyway.
Gabriel: Better explain results of tests at ETSI plugtest?
Yong-Geun Hong: test setup issues more than protocol implementation issues. 10
out 12 test cases passed. Samita: Before WG LC, we need 1 or 2 reviewers for
this draft. Raise your hand? Dave Thaler volunteers. Gabriel: would like to
have NFC Forum feedback.

draft-hong-6lo-use-cases (Yong-Geun Hong)
•       Changed the title, added a use case and editorial changes in this
version •       This document describes 7 link layer technologies, 5 use cases.
•       Remaining issues include o       Adding new use cases for MS/TP,
6tisch, LPWAN etc. •       Comments? Ready for WG adoption? •       Samita: Any
objections to adopting this document? o       Quite a few people had read the
document o       Will take adoption call to the mailing list

draft-rashid-6lo-iid-assignment (Rashid Sangi)

    This draft discusses how to designate 6LBR to assign IIDs for failed DAD.
    Currently, DAD cycle is repeated until the conceived IID isn't declared
    unique. To remove the overhead of repeated DAD cycle, this document enables
    6LBR to suggest an IID (to 6LN) for failed DAD. It improves the overall
    network performance by avoiding repeated DAD cycle. To attain higher degree
    of privacy, IID can be periodical changed and designating 6LBR ensures the
    uniqueness of IID in a proactive manner.

•       Draft proposes the use of 6LBRs to assign unique IIDs, e.g. in case a
locally-generated address
        turns out ot be a duplicate
•       Questions/comments?
•       Kerry Lynn: How does this compare to e.g. DHCP?
o       Rashid: There are some reasons RFC7217 can't be used with DHCP
o       Lorenzo Colitti: I don't understand how this is supposed to work. So,
if the EUI-64 fails due to DAD,
        then someone else produces an RFC7217
o       Rashid: Yes
o       Lorenzo: Why is RFC7217 better at avoiding collisions? Who has the
secret key? o       Rashid: The 6LBR o       Lorenzo: Doesn't that mean the
same secret key would be used for all nodes, thus the same IID? o       Rashid:
But the DAD counter would be increased o       Lorenzo: Why not just have the
nodes create a random IID? o       Samita: Work with Lorenzo to improve the
draft. There is a problem space. Invite comments
                form 6775 co-authors.
o       Gabriel: depending on collision probability, this maybe more or less
important to have. Adds complexity. Document if problem is real •

draft-mglt-6lo-diet-esp-requirements and draft-mglt-6lo-diet-esp (Daniel
Migault) •       DTLS does not address all problems. IPsec/ESP could fill some
IoT needs. •       DTLS allows observer to see IP addresses, ports, traffic
pattern. •       With IPsec, secure domains and secure communication between
domains. •       Owner can change destination within domain, balance/scale
traffic. •       ESP works for any key exchange protocol. •       Diet-ESP is
ESP and ROHC. •       one implementation on Contiki. Hopefully another one soon
on RIOT. •       IPSECME former chairs recommended to bring this work to 6lo. •
      asking for interest in 6lo for this work? •       Samita: who has read?
5-6 hands. Think interest for this group? 3. •       Gabriel: doubts about
interest, and even more about relevance to this group.
         There might be security issues that we nay not be able to detect or
         discuss here.
•       Daniel: would anyway be discussed in security area anyway.
•       Suresh: will figure out how the work gets done. Need to determine
motivation for the work first. •       Kerry Lynn: ? •       Juan-Carlos Z:
interesting problem. Related to compression and fitting in the constrained
world.
         Would like to host this work here and have it reviewed by security
         experts.
•       Brian Weis: Interested in the low-overhead, think it should go forward
regardless in which WG •       Samita: Thinks problem space is interesting.
Imagine thousands of iot gateways connecting to second
          level gateway. No network security solution with compression at this
          time.

ETSI/IETF 6lo Plugtest Report (Yeong-Geun Hong)

 The tests were performed by ETSI and held in conjunction with 6tisch plugfest.
 Unfortunately Miguel Ortega Reina, the ETSI test co-ordinator had to leave
 before the 6lo session, so Young-Geun has been requested to present on behalf
 of Miguel. Plugtests were held at IETF between 15-17 July.

 There were 10-12 participants in the 6tisch/6lo  joint plugfest, but only a
 few vendors tested 6lo only.

6lo tests per: http://rawgit.com/6lo/test-descriptions/master/6lo.html

6lo NFC: More 80% of interoporability as tested between two implementations.
Test setup issues. Need more reliable packet sniffing mechanism.

draft-thubert-6lo-rfc6775-update-00 (Pascal)

Extended ARO option moved in rfc6775_update
Add TID field to support registration mobility
Same as efficient ND
Proxy registration enabled by rfc6775_update
6LBR may register on behalf of 6LN in mesh environment
Registering the target as opposed to source address

New in 6lo ND: work on uniqueness

using link model so Link Local is point to point
• can be validated (DAD) by 6LR directly
• No need to go to 6LBR

Global addresses are unique
• Validated by 6LBR (DAR / DAC)
• 6LBR (s) maintain subnet wide DAD
• Multiple 6LBR coordination by backbone router

•       Zach: why this work? Pascal: solving chicken-egg problem with 6LR. Need
a readily-usable address to talk to the 6LR, on-link. Then go to 6LBR for
globally-unique address. •       Zach: had this discussion before. Link changes
all the time. Pascal: each node pair is a link, this proposes to be able to use
a different link-local address to talk to each neighbor. •       Don Sturek:
like 6BBR draft. Hope this ... Pascal: this link-local doesn't need DAD.
        we regularly see DAD being disallowed. I like BBR stuff,
        and hope it does not bring DAD into the solution as we don't want it
•       Eric Nordmark: does DAD mean 4861? This checks for uniqueness but does
not imply multicast. Don: ok, addresses my question. •       Carsten: <missed
it>. Pascal: at a given point in time, 6LN only talks to one 6LR. A second 6LR
may deny the first link-local address, node will use another one. •      
Carsten: in 6LoWPAN, 16-bit address obtained from LBR. Pascal: from PAN
coordinator. •       Pascal: a 6LN may be using different link-local addresses
to talk to different 6LR. May be unlikely to occur if link-local is built in a
way that is likely to be globally unique, but doesn't have to. •       Carsten:
this looks complex .. •       Emmanuel Baccelli: ... draft in WG LC in INT
area, this one would need to refer to it.
         Pascal: discuss it on the mailing list.
•       Samita: more discussion needed. Make sure backward compatibility, and
no major issue.

Low-Power Wide Area Networks (LPWAN)  BOF  Alex Pelov
BOF meeting this afternoon.
New radio technologies (Sigfox, LoRa, NB-IoT, ...)
Non-WG-forming BOF at Buenos-Aires. Unique constraints introduced by these
technologies. Lots of interest and discussions. Today reps of Sigfox, LoRa,
NB-IoT, IEEE will introduce their L2 technology and present the challenges that
need to be solved. Come and provide your inputs.

12:21 end of meeting.
Gabriel: your notes welcome to contribute to the minutes.

No comments offered on Jabber.