Skip to main content

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

Meeting Minutes IPv6 over Networks of Resource-constrained Nodes (6lo) WG
Date and time 2014-11-11 19:00
Title Minutes for 6LO at IETF-91
State Active
Other versions plain text
Last updated 2015-01-22

minutes-91-6lo-4
IETF #91, 6LO WG Minutes, Nov 11, 2014
Co-chairs: Samita Chakrabarti, Ralph Droms

Note taker: Markus IsomŠki and Ines Robles

Summary of Agenda:

1.Introduction and NoteWell, trivia and document status  by the co-chairs
2.A compression mechanism for the RPL option (Thubert/Bormann)
3.RFC6775 Update requirements for 6lowpan-ND(Thubert)
4.Transmission of IPv6 Packets over Near Field Communication(Hong)
5.IPv6 mapping to non-IP protocols  (Rizzo)
6.Recommendation on Stable IPv6 Interface Identifiers(Gont)
7.Lightweight and Secure ND for Low-power and Lossy Networks(Sarikaya)
8.Observation about IPv6 Addressing (Constraiend nodes) (Struik)

Ralph Droms opened the IETF91 6lo meeting announcing Ulrich's stepping down as
a co-chair and Ralph being an acting co-chair while the IETF INTAREA was
looking for a replacement co-chair for 6lo WG. Folks in 6loWG were invited to
volunteer.

It was noted that ÒIPv6 mapping to non-IP protocolsÓ draft being presented
today, but the draft may move to 6man WG due to its scope. ÒInterface
identifiersÓ draft on the other hand is a 6man document but since it has an
impact on 6lowpan header compression, 6lowpan needed to review in 6lo so that
there is no negative impact in 6lo deployment/standards.

Samita went over the Document status:

BT-LE document still waiting for BT SIG to progress.
Brian Haberman: Do we need to poke BT SIG or do we just wait?
Carsten Bormann: BT SIG has made changes to the channel assignment assumed in
the current draft,
 so once we get the documents from BT SIG we have to review them.
Markus IsomŠki: BT SIG documents are not yet published so we canÕt yet review
them in the IETF.
 But there should not be anything special happening, things are just taking
 time.

IPv6 over PLC draft currently expired.

Fragments draft by Pascal Thubert:
Pascal Thubert: Have gotten feedback that the draft provides a solution but the
problem is not clear.He had prepared slides to address the feedback but no time
to present today. Probably will submit a separate draft to cover this.

dect-ule: Ralph made few comments last week. Draft will proceed to WGLC shortly
after the new revision Dominique Barthel: are working this week on updates
following your comments, expect to issue new version next week.

Finally, the co-chairs reported publishing 2 RFC from last IETF (RFC 7388 and
RFC 7400) and draft-ietf-6lo-lowpanz being on the RFC editor's queue.

WG milestones will be updated soon and a draft milestone update was presented.

ETSI Plugfest on 6lo:
----------------------
The chairs have been approached by ETSI plugfest for possible interoperability
testing. The details will need to be figured out. Possible target dates are mid
year 2015. Contact name: MiguelAngel.ReinaOrtega@etsi.org

A compression mechanism for the RPL option                    Thubert/Bormann  
 30 minutes
  <draft-thubert-6lo-rpl-nhc-02>
  WG discussion and comparison of technologies

RPL inserts a hop-by-hop header in every packet, size 8 bytes. Would like to be
able to compress this with 6lowpan next header compression. A balance of
engineering decisions, complexity vs. frame size etc., need feedback 6TiSCH
uses also 127 byte packets so 8 bytes makes a difference. This work is thus
high priority to 6TiSCH. There is also a flow label solution to do the
compression, but 6lo approach has some advantages, presented on the slides. -02
version of the draft published, converges another draft (-bormann). Slides
explaining how to compress RPLInstanceID and SenderRank. The draft presents
three different approaches: ÒGreedyÓ, ÒConservativeÓ and ÒEfficientÓ. Greedy
uses 64 codepoints from the RFC 6282 codepoint space. Conservative only uses
one codepoint but requires another additional byte to include the information.
Efficient is in the middle: Sometimes a new byte is needed which creates header
expansion. On the other hand, implementers will have to deal with header
expansion anyway, but in the worst case a router has to break a packet into
two. The WG needs to decide which approach to pick. Around 6-8 had read the
draft but not enough ready to make a decision right now. Need to get this on
the mailing list. Michael Richardson, ROLL chair: People who have read the
draft have hard time to decide. For ROLL ÒgreedyÓ is the best but how about the
rest of you? You don't have to read the draft to have an opinion about it.
Ralph, as individual: Expansion of header size on the fly. This is possible
also with other headers.  Has this been a problem so far? Carsten: The
originating host needs to do a specific trick here to make things easy for the
routers. Pascal: The big question is the one Michael asked. Greedy avoids the
expansion problem, but uses codepoint space. Ralph: How many code points will
be left after assigning 64? Pascal: Around 140+. Ralph: An exact number would
be helpful. Samita, as individual: What other application or routing protocol
could use the codepoint space in the future? Pascal: Routing protocols do not
usually put data in traffic packets, RPL does. But it could be some new
application. Samita: Concerned about codepoint preservation. Prefers not to go
for the greedy option to save option space. Carsten: Currently 42 codepoints
have been assigned assigned, 214 are available. 214 - 64 would be 150. Pascal:
Anyone has an indication what else could use new options? Thomas: RFC 6554,
source route header compression. How does this work with it? Carsten: The
current request is half of the thing what we want for RPL. Need also to revisit
the mesh header, would require really making changes. So, RFC 6554 may need
additional codepoints too. Ralph: We did this conversation in the wrong order.
Can't make a decision until discussing the source route compression which might
require 64 codepoints more. Don't feel secure to make a decision before that
discussion. Pascal: Is there any known usage of mesh header? What would the
impact of changing mesh header be? Ralph: Is IEEE using it? Carsten: Mesh
header contains a fixed set of information. Anyone who want to do a mesh
protocol may not find that enough. ???: IEEE 802.15.10. They have not gotten to
this extent yet. But it is supposed to be a layer 2 mesh under. Not specific to
802.15.4 but that is the most relevant MAC/PHY. Can put the information to
different places. Pascal has the right approach with greedy, even an octet is
important. Bob Moscowitz, chair of 802.15.9: Includes mechanism to carry some
information without IP, .15.10 can use the same mechanism. Thomas: There are
people using the mesh-under header, it should not be obsolited. Actual networks
use it. Ralph: Need to take this conversation to mailing list. Carsten, Pascal,
can you lay out the new possibilities you discussed today, including a possible
compression for the Source Route header. That will help us to have the
conversation on the mailing list.

RFC6775 Update requirements for 6lowpan-ND                    Thubert          
 20 minutes
  <draft-thubert-6lo-rfc6775-update-reqs-05>
  WG discussion on RFC 6775 update requirement list

Originally the use case of was broader what the RFC 6775 eventually covered.
Also, a number of new requirements have come up, e.g. from 6TiSCH, security,
Zigbee IP. All these known requirements have been collected to this draft. In
the end there can be multiple documents to address them. Carsten: Be careful
with the word requirement. These are potential objectives, some more potential
than others. Samita: Please review this document. We should also find another
co-author for it. -05 published, 23 requirements in total. No time to go
through all the requirements one by one today. Went through some example
requirements. Ralph: How many have read the draft? Not very many. Not enough
people in the room to hum for the WG adoption.
 More discussion on the mailing list.
Brian Haberman: If you do adopt this document, please don't just ask for just
the requirements document to be published. Requirements can be included in the
solutions documents. Carsten: Can still make it a WG document, even if it is
not aimed to be published.

Transmission of IPv6 Packets over Near Field Communication    Hong             
 15 minutes
  <draft-hong-6lo-ipv6-over-nfc-02>
  Ready for acceptance as WG document?

Second time to present this document, -02 published.
NFC has different modes. Peer-to-peer mode relevant for IP. Comparison with
Bluetooth LE. NFC is secure due
 to <20 cm range. Over 200 NFC capable phones available. Personal information
 can be transferred over NFC.
Sections 4.7 and 4.8 related to address mapping are new.
Five key issues:
1: Connectivity, two scenarios: NFC enabled device connected to Internet, and
isolated NFC enabled device network. 2: Address configuration. 3: Header
compression 4: Fragmentation and reassembly. Default MTU is 128 bytes. 5:
Unicast/multicast address mapping. Prototype implementation of IPv6 over NFC in
progress. Samita: How many interested in this document? Quite many. Any
objections to make it as a WG document? No. People who
 have read it please post comment on the mailing lists. Based on comments
 update should be made and in a few weeks WG adoption can happen.
Carsten: How stable are those LLCP addresses? Do they change? Need to pay
attention about this issue.
 Multicast address, why did you choose it to be like that? LetÕs take it
 offline.
Petrescu: One comment to interface id design. You could call it a 6 bit IID
instead of a 64 bit IID. Ralph: 128 bit address is needed anyway, right, so
even if there are zeros they are not ÒwastedÓ.

IPv6 mapping to non-IP protocols                              Rizzo            
 15 minutes
  <draft-rizzo-6lo-6legacy-02>
  Update from previous revision

The feedback from previous presentation was that not enough context was given,
so now something more has been added to the draft. A lot of legacy technologies
are not IP enabled. Example: Home appliances direct control. Zigbee, KNX,
Wi-Fi. IPv6 would allow direct control without gateways. Would be good to have
the same way to address both real IPv6 devices and non-IP devices. Make legacy
devices appear as directly IPv6 addressable, by assigning their own ÒvirtualÓ
IPv6 addresses. Coverage of the draft: Legacy protocols with node identifiers.
Aiming at informational, not standards track. Adapted the mapping to
accommodate large number of legacy protocols. Pascal: Why do we need to expose
all this information to Internet? Is the gateway supposed to be stateless?
Since if the gateway it stateful it can hide all this information instead of
exposing it to an attacker, for instance. If the gateway has state per node it
can avoid address conflicts. Only stateless gateways would need this kind of a
mapping. Samita: This defines just one implementation option. Michael
Richardson: Following PascalÕs question. Gateway has some security relationship
with the devices. That makes some state necessary. Stateless only applies if
there is no security. This could be even in a Òdon't ever do thisÓ type of
proposal. Fernando Gont: No structure should be assumed for the 64 bit
Interface ID. Ole Troan, 6man chair: Fine to do whatever interface ID
structures, but why do you want to publish this? Gateway can just do it. Ralph:
6man and 6lo chairs need to discuss whether these discussions are better had in
the 6man WG. This is in their territory. Ole: Happy to have that conversation
in 6man.

Recommendation on Stable IPv6 Interface Identifiers           Gont             
 20 minutes
  <draft-ietf-6man-default-iids-01>
  Follow-up discussions with 6lo WG on default IID recommendations

Ralph: This is a 6man document but it can have impact on 6lowpan header
compression, so that is why it is presented here too. Actual discussion will be
in 6man later in the week. Motivation of the document: Often the IID is
generated based on HW addresses. Hardware addresses in IIDs expose hosts to
reconnaissance, tracking and node specific attacks. Many current IP-over-foo
specifications still mandate that SLAAC IIDs be generated by embedding hardware
addresses. 6man-default-iids updates a number of them based on an alternative
mechanism. Ralph has sent comments related to 6lo header compression. Pascal:
HC is critical, intermediate node must still be able to compress somehow. 6lo
should document what is relevant for it, for instance low-power devices often
do not move between subnets. Fernando: The document says SHOULD, so if there
are good reasons it does not need to be followed. Pascal: In RPL network
special considerations. After defining what is relevant for 6lo, may want to
define a compressible version of the new mechanism. Rene Struik: My
presentation which will follow does some analysis about this. Bob Moscowiz:
Some low-power devices just come up with a different address every time. Dave
Thaler: To address Ralph's comments: Link layers MUST define a way to provide
privacy. They MAY provide a more efficient mechanism without privacy. Which
approach to use should be configurable. Need to continue this in 6man.

Robert Craigie: Justification why hardware addresses used a lot in low power
devices. Carsten: Confusion because hardware address does not have a
well-defined meaning. For instance, how about NFC. Should talk about device
encoded addresses. Current doc is too Ethernet minded for this WG. Ralph:
Conversation needs to continue in 6man, send text.

Lightweight and Secure ND for Low-power and Lossy Networks    Sarikaya         
 15 minutes
  <draft-sarikaya-6lo-cga-nd-01>
  Initial WG discussion

Presentation covers what is new in -01 draft.
Rene: This technique is more generally applicable than just 6lo.
Brian Haberman: What exactly is multihop neighbor discovery?
Behcet: This is covered in 6775.
Brian: This is not applicable to standard neighbor discovery then.
Pascal: Suresh had a proposal about this. Don't need to put signature
information in every registration. Samita: Is this interesting work for the
group? Yes: Weak hum. Need more people who have read this and comment. Dave
Thaler: It is not ready for adoption as not enough people have read it.
Security implications are not yet clear to me to have an opinion if all
security threats are addressed.

Observation about IPv6 Addressing (Constrained nodes)         Struik           
 15 minutes
  <draft-struik-6lo-on-ipv6-addressing-00>
  Initial WG discussion

This draft is triggered by RFC 7217.
Issues with fixed IIDs: correlation, tracking, leaking of device
characteristics. Suggested remedy: Semantically opaque IIDs, RFC 7217. Analysis
how this addresses the issues. You can also randomize the MAC address. Efforts
to enable this going on in IEEE already. This could be better for
compressibility. Fernando: Goal of 7217 is to produce stable addresses in the
same network, so it is a feature rather than a bug. Alissa Cooper: More of the
comments are related to privacy document in 6man. The 7217 mechanism was aimed
just at a certain set of goals. Different mechanisms may fulfill other goals so
they should be analysed together rather than separately.

Randomly generating MAC addresess has benefits over randomizing just on layer
3, especially related to the first hop. The conclusions is that it is not clear
how useful 7217 is, as it ignores L2 traceability. If IP address is tied to a
random L2 address, the additional benefit is that IP header compression is
easier based on the L2 address information. Ole Troan: Please bring this to
6man list, have worked on this for a while. Dave Thaler: 6man is the right
place, not 6lo. One great new observation in this presentation that has not
come up before is that if you do the random address generation on the MAC
address level then the existing EUI-64 mechanisms will propagate the privacy
properties to layer 3 as well. Will want to bring this up in 6man.

Fernando: Also another draft exists that analyses privacy issues of IPv6
addresses.