Minutes for 6LO at IETF-89
minutes-89-6lo-4

6lo: IPv6 over networks of resource-constrained nodes

WG Agenda
Meeting:             IETF 89 Wednesday March 5, 2014
Time:                1520-1730 Afternoon Session II + III
Location:            Balmoral
Chairs:              Samita Chakrabarti
                                <samita.chakrabarti@ericsson.com>
                     Ulrich Herberg
                                <ulrich@herberg.name>
Technical Advisor:   Ralph Droms <rdroms.ietf@gmail.com>
Minutes:             Dominique Barthel and Anders Brandt
Jabber:              xmpp:6lo@jabber.ietf.org
Audio archive:      
http://www.ietf.org/audio/ietf89/ietf89-balmoral-20140305-1520-pm2.mp3
                and 
                http://www.ietf.org/audio/ietf89/ietf89-balmoral-20140305-1630-pm3.mp3
URLs:                https://www.ietf.org/mailman/listinfo/6lo
                     http://datatracker.ietf.org/wg/6lo/
=========================================================

====== agenda bashing + note well + draft status update: chairs

This is 2nd meeting of 6lo WG
Agenda change:
Carsten's listed presentation is replaced by a talk on privacy concerns at link
layer by his request.

Draft Status:
draft-ietf-6lo-btle-00: waiting for BT SIG to comment, nothing to do for us
draft-ietf-6lo-lowpanz-03: 1st WGLC passed, changes after LC require new WGLC
Since last meeting, adopted 3 WG drafts: draft-ietf-6lo-ghc-00,
draft-ietf-6lo-lowpan-mib-00, draft-ietf-6man-6lobac (not yet submitted as 6lo
WG draft) [addition to he minutes: draft-ietf-6lo-btle-00 has also been
adopted, taken over from the 6lowpan WG]

Samita Chakrabarti: Some new individual drafts have been brought to the
attention of the WG:

draft-rizzo-6lo-6legacy-00
draft-savolainen-6lo-optimal-transmission-window (3GPP environment)
draft-mariager-6lo-v6over-dect-ule-00: not much change apart from republication
as individual draft with 6lo in the moniker

Milestones

achieved the part intended for December as far as draft adoption

====== draft-ietf-6lo-btle update: Teemu Savolainen

moved from 6Lowpan to 6lo, submitted to IESG, waiting for BT SIG to issue 4.1.

main new features: LE L2CAP connection oriented channel support. Negotiation of
app MTU, channel identifier, number of initial credits, during setup. Help
constrained nodes throttle down data exchanges.

Fragmentation at higher layers, and Segmentation and Reassembly at layer 2.5

In 4.1, new topologies possible: a node can be master for one slave and salve
for another node. Also a node can be slave to multiple masters. Allows to build
real mesh networking. However, in this draft, still only considering star
topology.

BT SIG has an "Internet" WG, Teemu part of it, but is not allowed to reveal
what happens there. Documents will eventually align.

====== draft-ietf-6lo-lowpanz: Anders Brandt

Some comments during WG LC, some further comments (mostly editorial) later in.
Made into -02. Some more changes in -03, submitted yesterday.

01: no reference to routing protocol needed as this is an adaptation sublayer.

02: for mesh-under, unique link-layer addresses, no need for DAD. changed
SHOULD NOT to MUST NOT

03: because of privacy issues raised by Samita and other sources, opened up
possibility for these nodes to request address from DHCPv6. Flag in Router
Advertisement.

Carsten Bormann: is some of this text redundant with RFC6775?

Anders: believe RFC6775 is only recommendation, strengthened here.

Carsten: is it?

Carsten: Next slide is important. 802.15.4 we can choose whether we get
addresses from DHCP or something else. Proposal here is to simplify this for
mesh-under case to only two cases: M-bit not set (always LL-derived addresses,
or M-bit is set and we have to use DHCP).

Samita: is it clear that DHCP-assigned addresses are temporary but does not
cover privacy issues?

Anders: short leases does provide good privacy.

Samita: since more changes were made, will do one more round of reviews. Some
assigned reviewers.

Geoff Mulligan: didn't notice  that this will prevent to do CGA on mesh-under.
Anders: has been there since yesterday.

Geoff agrees to review the doc.

Alex Petrescu: at 6man, several drafts around the formation of IPv6 address,
moving away from link layer address. I recommend to follow what's going on in
6man.

Samita: We should follow what is in 6man, but we also have to consider the 6lo
use cases.

Anders: link layer address, but not to be confused with MAC address. Short
address within the PAN. Node cannot be recognized after next inclusion in the
network.

Hannes: some time ago, thought IP... 6lowpan document, privacy addresses don't
work anymore.

Anders: in many cases, not worried about recognizing nodes by addresses.

Carsten: short address is an 8 bit number. Identifying power not high.

Brian: 8 bit is not enough entropy to identify a node that moves around. Don't
over-engineer.

Kerry Lynn: cost of this is carrying full IPv6 addresses, not able to compress
them out. Anders, that's why it's an optional option.

====== draft-ietf-6lo-lowpan-mib: Juergen Schoenwalder

counters to figure out what happens at 6lowpan sublayer, e.g., fragmentation.

about 18 counters

Should counters be interface specific? at this point in time, JS doesn't see it
as being useful.

Kerry: predominant case (one interface) doesn't make a difference, but already
cases (Zigbee) with multiple interfaces, see this as very valuable.

Samita: in 6lo, assumption is to support multiple link layer technologies. From
day one, we should have this.

Ulrich: could be useful to have. What is expected overhead, extra complexity?

Juergen: could be described interface specific, but not mandatory to implement.

Humm : no humm against this capability, significant humm for.

Ulrich: will bring it to the mailing list to confirm.

Ulrich: When do we need MIB doctor review?

Juergen: After WGLC.

====== draft-ietf-6lo-ghc: Carsten Bormann

Originally created in 2010, eighth version, stable, presented in Vancouver
IETF88, adopted by 6lo.

Issues:

capability indication? 6CIO. Uses one bit, leaves 47 for something else.
Proposed policy "RFC required".

Do we want to use any of these bits for experimentation bits?

Ulrich: How high is the bar for RFC publication for "RFC required. "?

Hannes Tschofenig: not so high, independent submission.

Brian Haberman: IESG's work to make sure independent RFC does not conflict with
work done at IETF.

Ulrich: so, which level should we use?

Brian Haberman: would recommend "IETF consensus".

Michael: suggest to mark 7-8 bits as "private use".

Carsten: no, "experimentation".

Editorial comments

originally written so that spec fits on one page. Maybe slightly larger than
that now.

Static dictionary choice not "easy to explain". Was scientific process, but not
quite explainable.

Examples may not all be very understandable.

Intention to do -01 and ship it.

Ulrich,Carsten: agree to to WGLC after editorial comments.

====== draft-mariager-6lo-v6over-dect-ule: (no author present)

Technical contents will not be presented again here, however slides are in the
proceedings.

Nobody from the current author list is on site to present.

Few changes, will move again towards WG adoption.

====== draft-savolainen-6lo-optimal-transmission-window: Teemu Savolainen

Time to tear down data channel: in 2G, two seconds, in 3G, half a second, 4G,
ten seconds

Teemu shows current measurements for sending CoAP packets at 10s interval on
2G, 3G, 4G. Lots of energy wasted listening to channel for nothing.

Situation of multiple sensors using a cellular device as a gateway. Group
transmissions at gateway to avoid having multiple active periods on cellular
interface.

This draft proposes nodes behind a gateway learn of optimal times to send their
data so that grouping is performed.

Teemu: other networks with same behavior/benefit? Thoughts on usefulness?
Interest to this WG or go back to 6man?

Zhen Cao: how about the gateway delays the CoAP request and send them together?

Teemu: No, we have not considered that. How long would the router delay it?

Carsten: synchronizing sleep schedule is beneficial. Problem: many patents. Any
IPR?

Teemu: Nokia has declared IPR on this technology. Look for declaration on
equivalent draft submitted at 6man, the tools don't allow the IPR declaration
to follow drafts morphing.

Ulrich: please send pointers to IPR declaration on the mailing list.

Dave Robin: old problem, we had this for dial-up. Application can tell how
urgent packet is, but hard for networking layer to understand.

Hannes: I had a similar reaction, reminds me of DTN work.

Teemu: BT nodes can register by the gateway to be woken up at predetermined
intervals, which notifies application to send data. Another solution.

Samita: should this WG continue work on this ? Please humm...

Brian (as AD): let people a chance to read IPR first. Then make the call on the
mailing list.

====== draft-ietf-6lo-bac (currently: draft-ietf-6man-6lobac-01): Kerry Lynn

draft depending on doc that sits at BACNet for second public review, then
approval.

this draft held off pending this to happen.

====== draft-rizzo-6lo-6legacy: Gianluca Rizzo

Many devices not addressed directly via IP: RFID, building automation. Would
like to extend IoT to these devices.

Propose address mapping.

Desired properties: consistency, local uniqueness, uniqueness across the whole
Internet.

Explains examples: EPC RFI (requires hash).

Carsten: experience as 6lowpan co-chair. Why would we need to do this? If
devices are not IPv6 capable, they don't need an IPv6 address. Why give a fixed
IPv6 address to something you can't talk to?

Hannes: desktop computer mouse is local device, does not need an IP address.
What's the purpose?

Samita: use case is e.g. sensor legacy devices. Connect them to the Internet
with some level of service.

Hannes: you can connect RFIDs to the Internet today, no need for IPv6 address.

Kerry: header compression works fine with zero-padding. With this proposal,
probably take away most ability to compress header.

Michael: gateway will do translation between v6 and something else. IPv6
address would allow gateway to be relatively stateless. As Carsten mentions,
this can be proprietary, does not need standardization.

Except maybe privacy and ID tracking. We may want to carry on with this
document to get review from privacy experts at IETF. Informational document at
most.

Bob: 6 bits of protocol identifier? we have hundreds of legacy protocols.
Anyway, gateway needs to understand upper layers, can do what it wants with
addresses.

Hannes: this is not just a network protocol. You need application layer
processing anyway. Take a running event with RFID as an example. Tie RFID to
user.

Bob Moskowitz: suggest recommended practice. In SCADA, we can't replace
devices, serial bus. If gateway could connect to Internet, would be great. CAN
bus example as well.

Robert Cragie: does not see the need to have this. Part of IPv6-over-whatever
specification. No need for generic address mapping for all legacy protocols.

Erik Nordmark: use DHCP to assign address, stable address, does not rely on
hashing, does not reveal identity.

Samita: WG to read draft and comment about applicability.

====== L2 address privacy: Piers O'Hanlon [10]

no draft, but paper: https://www.w3.org/2014/strint/papers/35.pdf

Link layer MAC addresses globally unique. Facilitates unsolicited tracking
(e.g. sniffers in waste bins in London).

Suggest to use dynamic addresses at link layer.

other approaches: IPv6 Crypto Addressing (CGA) inspired. Take it one layer
down. Or share MAC addresses (chameleon addressing).

Ulrich: is this destined to IETF? Piers: maybe more the IEEE.

Bahmas (Verizon): 6man interested in privacy. Dont use MAC addresses in your
IPv6 address.

Robert Cragie: when did Zigbee IP, used global addressing without exposing MAC
addresses. Also, link layer addresses also reveal IID, creep up the stack.

Erik Nordmark: make sure IPv6 address also changes when MAC address changes,
otherwise not much benefit. Do you know is 802.11 is already looking into this?

Piers: at the STRAIN workshop, IEEE rep was there.

Piers: some work on when is good time to change MAC address.

Carsten: what we could do but haven't done at 6lowpan: 16 bit address reveals
64 bits address. Some work could be done at IETF.

Bob: One place we can look for experience is vehicle-to-vehicle communication
IEEE 802.16.9.

Pascal: if interface is alive, changing addresses requires to be able to accept
packets on old MAC address for a while.

Hannes: wrote slides to data protection specialists. Tangled issues. Worthwhile
to categorize issues and untangle some of them.

http://eandt.theiet.org/news/2013/aug/bin-data.cfm

====== 6tisch Plugfest: Pascal Thubert and Thomas Watteyne

informal meeting tomorrow morning 9-12 GMT, room 1-4. Plugfest. Will show
equipment running code.

Pascal: detect overlap, gaps. 6TiSCH encompasses multiple meshes, backbone
router.

Pascal explains the need of efficient-nd like TID bits in 6lowpan-nd for 6TiSCH
stack and that their current demo implements efficient-nd bits on top of
6lowpan which runs on top of 6TiSCH.

======  6lo deployment? Uses cases and reference architecture: Samita

RFC6568 : use cases for 6lowPAN. Applicable to 6lo. But now, 6lo supports
multiple L2 technologies. Need to document these use cases? architectures?

several IETF WG tackling issues adjacent to 6lo. Do we need a reference
architecture? assembling the puzzle, need for GW or proxying?

Erik: simply using a different radio is not very useful. Other situations (like
backbone router) are useful contributions.