IPv6 over Low power WPAN (6LOWPAN) Working Group Minutes

Reported by Bob Moskowitz and Carsten Bormann

The 6LOWPAN working group met once at the 62nd IETF meeting (Minneapolis, March 2005). The meeting was chaired by Geoff Mulligan.

WG Charter

Geoff Mulligan went through the charter of the new working group and asked if there were any comments. There were none.

Problem statement -- draft-kushalnagar-lowpan-goals-assumptions-00.txt

Nandakishore (Nandu) Kushalnagar presented the problem statement draft (see slides). This document is at the level of a personal contribution; there was no contention to use this draft as the basis for discussion in the working group.

Regarding the issue of routing, Nandu pointed to a separate presentation later on the agenda. While the intention was to use existing routing protocols, making them work at the subnetwork level requires some changes. This brought up the question how to handle the plethora of routing protocol proposals that can be expected. Geoff stated that the the working group scope does not include routing, it is IP over foo. There is an opportunity to look at other issues, maybe as an informational document; the charter nonetheless is limited to the two documents being discussed.

A 15.4 contributor (Pradeep? The note takers apologize for not catching names very well.) mentioned that in 15.4, there are two mechanisms: CSMA/CA and slotted; IP discovery will be different for the two. Gabriel Montenegro pointed to the subsequent agenda item, which goes into each of the modes we assume. Geoff proposed to include in the problem statement the assumption of CSMA/CA, instead of the superframe structure ("slotted").

Lixia Zhang noted that the WG will be constrained by its charter and asked whether there was a plan to address the inevitable issues of deployment: management and security. Nandu proposed to make use of existing security working groups in the IETF, without making specific proposals which of these might be of interest. Geoff proposed to complete the IPv6-over-15.4 document first. Lixia insisted that deployable security must be part of the initial result or there will be a deployment surprise. Gabriel said that while the charter has very specific goals; there is some language that allows future work -- the WG may be able to recharter when we have a better understanding; the issues might be the subject of individual submissions in the interim.

Simone Ruffino asked whether, for the mesh network that is built below IP, the intention is to adapt existing mechanisms of stateless autoconf or invent a new one. Nandu said the intention was to use the existing IPv6 mechanisms, but pointed out that for 15.4's 16-bit addresses we need a different method. Simone asked whether the whole LoWPAN was to be considered one link in the IPv6 architecture sense. Nandu affirmed. Bob Hinden asked for further clarification. Bob Moskowitz said that the LoWPAN looks like an 802 LAN to higher layers. Bob Hinden mentioned that the IPv6 autocongifuration/address architecture defines how to create interface tokens and asked that these not be reinvented. Nandu agreed. Gabriel later attempted to clarify the answer to Bob Hinden's question by pointing out that 15.4 has a PAN ID, which, in IPv6 architecture words, identifies a link -- multiple PAN IDs can overlap, but not interact.

The discussion returned to the question how to use IETF security working groups for developing the LoWPAN solution. Margaret Wasserman pointed out that there is a number of groups to look at. Geoff stated that none of them is actively looking at LoWPAN. Gabriel agreed that LoWPANs require security work but said we don't necessarily have to solve them in the 6LOWPAN WG, can do that in the security WGs. Bob Moskowitz noted that 802.15.4 has a security format to encrypt the payloads, but does not have a key management scheme or exchange methodology -- defining that would be one valuable thing to do, reminding everyone that this is a hop-by-hop security model and that for end-to-end security, a higher layer security mechanism is required.

Pekka Savola clarified that while there is an IETF security area; it would be too much to expect security area people to just come in and fix the WG's protocols; the WG has to do this and, if necessary, ask for help. He pointed out that, if this WG does not do the necessary security work; the result will be held up in the IESG for security. Geoff countered that the WG is not currently chartered to do security

Margaret asked why are there any specific security issues that aren't either a problem of IEEE or general IETF issues? Nandu answered that a LoWPAN has different characteristics, including its packet size, and the wireless multi-hop, related to MANET type of network

The WG chair closes the mike line and refers further security discussion to the final agenda item.

One last comment was that it was not easy to see how stateless autoconfiguration fits into the LoWPAN model -- it was hard to imagine routers giving out the appropriate advertisements...

IPv6 over 15.4 -- draft-montenegro-lowpan-ipv6-over-802.15.4-01.txt

Gabriel Montenegro presented the IPv6 over 15.4 draft (see slides), pointing out that, although this is already the -02 version (second revision) of the draft, this was going to be the first face to face discussion in this working group.

During the presentation, a poll indicated that about ten of those present in the room had read the draft. Gabriel pointed out that, for assigment of 16-bit addresses, 15.4 defines a prodecure with a central coordinator, which does all the necessary work, we can use that. The mapping between PAN ID and IPv6 prefixes is not currently defined.

During the presentation of the frame format and adaptation layer, Carsten Bormann asked how compatible this format was with transporting LLC packets as well. Gabriel answered that the more efficient 6LOWPAN format is not compatible with LLC, assuming that there is no need for LLC/SNAP compatibility.

Bob Hinden asked why RFC 2507 (IP Header Compression) wasn't being used as a header compression format. Carsten answered that the requirements for 6LOWPAN's header compression scheme are very different from the ones that RFC 2507 addresses (which addresses flow-based compression).

Carsten asked about the relationship of the reassembly scheme proposed and the reordering assumed from the link (e.g., the MSL issue). Bob Moskowitz clarified that Meshes are being discussed in 802.11, .15, .16, and none of them addresses reordering.

Gabriel noted that there is a mistake in the current draft -- there is a need for multiple M bits. Rajeev Koodli asked whether the IPv6 routing header could not be used to solve the problem. Gabriel clarified that routing headers carry IP addresses, while the "Final destination" field is about MAC addresses. Bob Moskowitz added that all 802 meshes need special multi-MAC formats for meshes and pointed out the 4-address format used in .11.

When Gabriel presented the header compression mechanism proposed, Alain asked about same-subnet vs. link-local source and destination addresses -- does this mean the assumption is that LoWPAN devices never listen to a router? Gabriel stated this as the most common case; however, global addresses are possible -- and even expected to be compressible. Alain wondered whether this has a bearing on the address selection policy to be used by endpoints. Gabriel asked whether, based on the current address selection policy, we have to modify anything. Alain answered that, if only link-local addresses are used, the current address selection policy is fine.

Greg Daly pointed out that, while link-local addressing is the most common case, at the moment, it is quite possible there will be off-link traffic. Gabriel answered that this remaind possible, just will be less compressible. Gabriel then speculated about possible integration of the compression state and the routing information.

Krishnan asked why there was no attempt to compress out the hop limit as well. Gabriel answered that this was worthwhile to examine. Rajeev pointed to a paper about stateless header compression he had at IEEE ICC 2005. Gabriel also stated a need to expand the work to also examine TCP header compression.

Sub-IP Mesh for LoWPAN

Nandu started the discussion pointing out that work on the Sub-IP Mesh is not currently part of charter. Discussion ensued about other standards alliances working on standards in the same space. (See slides for Nandu's presentation.) A draft for reactive routing at the Sub-IP level is in the works; replacing AODV hello by 15.4 specific messages. The suggestion is that this be separate from the basic IPv6 over 15.4 specification. In the future, other protocols like OLSR, DYMO, DSR should be considered, but care must be taken that the work is actually applicable to LoWPANs.

Charlie Perkins, in the context of work in MANET on DYMO and other protocols, asked for input to the discussion about the tradoff between using power for sending bits vs. using it for processing. Bob Moskowitz pointed to work in 802.11s about Mesh routing, an NRL proposal, and work on sub-second maintenance of the routing table information.

Charlie Perkins indicated that this wasn't the complete answer he had hoped for and proposed to take the issue offline for further discussion. Geoff added that he'd rather do less computing than send less bits.

Implementation considerations

(The slides covered the issues of Embedded Systems, Code Size, Energy Use, Just enough security (what layer), What services (security, service discovery, ...), a Transport layer, and Compatibility.)

Geoff noted overlap between the work of this working group and work done in ZigBee Alliance; ZigBee Alliance has announced to make their specification available for academic review but not for commercial use; anything about non-encumbrance has yet to be stated by the alliance. This situation was a reason for not attempting to use the ZigBee format. With respect to routing, Zigbee Alliance have what could be called "AODV junior", so we could try to interoperate, but we also could be ships in the night. A ZigBee study group is just now looking at he feasibility of IPv6 over 15.4, not doing the work yet.

Gabriel: back to Charlie's question: typically, a LoWPAN is partitioned into Full Function Devices (FFD) with sufficient power and Reduced Function Devices (RFD) on battery power; RFD won't participate in the control messages (instead they'll send everything to a prefferred neighbor); in one scenario, FFD are always mains-powered; if FFD are battery powered, you want to compute, not transmit.

Pekka Savola asked to focus some implementation considerations on AODV sub-ip; there is no security in AODV; there can't be a normative reference it as it is experimental.

Geoff: One implementation consideration is that 15.4 defines radios for the whole range of 20-250 kbit/s, which is a big difference. We might have the opportunity to say we only do 2.4 GHz. 15.4b will have differences both in modulation and in security and is about to become an IEEE specification. Gabriel noted that the current drafts don't have much text on 15.4 security -- using that might improve security. Bob Moskowitz stated that doing the 15.4 security cannot be avoided; the risk in a PAN to have non-authorized systems interfering is too great; L3 protection can do some of that, but is not as good a fit; so there is a need for an L2 keying solution. Geoff pointed out that Sub-IP issues are generally not IETF work. Bob Moskowitz agreed and suggested to look where that work is done. IEEE 802 seems to be trying to get all future security work done in 802.1, whether that work fits here remains to be seen.

Pekka stated that there needs to be at least some analysis, if not solutions for AODV security, Man in the Middle attacks. Gabriel pointed out that every draft needs a security considerations section

Nandu proposed writing an informational document that describes what kind of threats are relevant to 6LOWPAN. The security of any adaptation layer needs to be addressed as well.

It was pointed out that link-local addresses provide some form of isolation from link-external threads. Gabriel pointed to work on group keys.

Charlie Perkins asked about the scale of the network we are envisioning -- is this about PANs or larger? Geoff said that his company was looking at home networks, with maybe 100s of nodes, as well as building networks with 1000s, but that additional input was required. One solution might be a network of meshes (30-50 node LowPANs, IP routing between them). It was pointed out that there are a lot more factors than just number of nodes; e.g., traffic characteristics. There is a need to come up with some common use cases.

Geoff asked about strict vs. loose source routing (carrying the MAC layer address for the next hop vs. the final destination), but then proposed to take this offline.