6lowpan C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track July 8, 2008
Expires: January 9, 2009
Context-based Header Compression for 6lowpan
draft-bormann-6lowpan-cbhc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2009.
Abstract
6lowpan (RFC 4944) so far has only defined stateless forms of header
compression. This document specifies how a node and a router can
agree on state that will allow much better header compression of
global addresses.
$Id: draft-bormann-6lowpan-cbhc.xml,v 1.2 2008/07/07 22:19:28 cabo
Exp $
Bormann Expires January 9, 2009 [Page 1]
Internet-Draft 6lowpan context-based HC July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3
3. Address Compression . . . . . . . . . . . . . . . . . . . . . . 4
4. Intra-Lowpan Use . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Bormann Expires January 9, 2009 [Page 2]
Internet-Draft 6lowpan context-based HC July 2008
1. Introduction
The 6lowpan format specification [RFC4944] defines a format for
transporting IPv6 packets over IEEE 802.15.4 networks. An important
aspect of this is the limited size of packets provided by
IEEE 802.15.4, which leaves only rather limited space in a packet
beyond the size of an IPv6 header. While larger packets can be sent
using segmentation and reassembly, 6lowpan is most efficient when all
IPv6 packets can be made to fit into a single IEEE 802.15.4 packet.
The largest part of IPv6 headers are the two Pv6 addresses in the
header, which in certain cases together can consume 40 % of the
usable space in a 6lowpan packet. [RFC4944] defines how to compress
certain forms of link-local addresses, but still requires the
transmission of global addresses at their full size. Since the whole
point of running IPv6 in a 6lowpan is to enable communication beyond
the local link, this is unsatisfactory. [I-D.hui-6lowpan-hc]
specifies one way of compressing globally routable addresses, but
does not explain how the common state between compressor and
decompressor is established.
An interesting proposal for establishing state between 6lowpan nodes
and their routers is [I-D.nordmark-6lowpan-reg]. The present
document proposes to establish the common state needed for efficient
compression of global addresses by using the registration mechanism
proposed there.
2. Protocol Operation
In order to enable the compression of global addresses, this
specification provides a way for nodes to establish context with
routers. This context can then be referred to in 6lowpan packets
exchanged between the node and the router and used for address field
compression.
When registering as a node according to [I-D.nordmark-6lowpan-reg], a
node can indicate its interest in receiving context by setting a bit
in the ND registration message. A router can include context in the
ND registration option in its router advertisements.
A node sending a 6lowpan message to a router can make use of the
context most recently received in a router advertisement from the
router. A router sending a 6lowpan message to a node can make use of
the context if the node has indicated interest in its registration
message.
Obviously, the most important aspect about a header compression
Bormann Expires January 9, 2009 [Page 3]
Internet-Draft 6lowpan context-based HC July 2008
scheme is making sure the context stays synchronized. The router
therefore SHOULD only start using a context when a sufficient number
of router advertisements have been sent to establish it. To avoid
nodes sending packets making use of previous values of contexts and
the resulting ambiguity when receiving a packet that uses a recently
changed context, old values of a context SHOULD be taken out of use
for a while before new values are assigned to this specific context.
Nodes MUST stop using context information for a specific context when
a number of <TBD> router advertisements have been received that do
not assign a value to this context.
To further reduce the probability of damage, 6lowpan nodes SHOULD use
context-based header compression only when a higher-layer protocol is
in use that protects the IPv6 addresses using some form of pseudo-
header based checksum and/or authenticator.
3. Address Compression
The requirement for old context information to time out from the
6lowpan before it can be replaced with new information suggests the
ability to use multiple contexts. This also allows to employ more
and less aggressive forms of address compression. This specification
therefore proposes the use of a single bit to indicate the use of
context-based header compression, plus a byte with the following
structure:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| s s s s | d d d d |
+---+---+---+---+---+---+---+---+
s and d supply the context numbers for the source and destination
address, respectively. Context number 0 is reserved for the
uncompressed transmission of the respective address. (TBD: Align
with existing [RFC4944] forms of address field compression.)
The contexts number 1 to 15 can be used for various prefixes. To
keep the packets self-describing, this specification defines the
prefix lengths associated with each context:
Context Prefix
Number Length
0 0 (uncompressed)
1-3 TBD
4-7 /64
8-11 /112
12-15 /128
Bormann Expires January 9, 2009 [Page 4]
Internet-Draft 6lowpan context-based HC July 2008
This allows the router to not only establish context for one or more
/64 prefixes governing a specific link, but also for specific ranges
of addresses or even specific single global addresses of likely
correspondents of nodes in the 6lowpan. The latter addresses can be
compressed down to 16 or 0 bits, plus the overhead of context-based
header compression.
4. Intra-Lowpan Use
The mechanism, as described, is useful for packets exchanged between
routers and nodes. It could be extended to allow efficient intra-
6lowpan use of global addresses by indicating the "context interest"
bit in the ND information exchanged plus some conventions about
context use between routers. Details TBD.
5. Security considerations
The security considerations of [RFC4944] apply.
An attacker can trick nodes into sending packets to the wrong
destinations by sending fake router advertisements with carefully
crafted context information. However, any node that can craft router
advertisements that will be acted upon by nodes can already trick
nodes into various forms of undesirable behavior, so the same
mechanisms used for preventing against fake router advertisements
should be used for both cases.
6. IANA Considerations
TBD
7. References
7.1. Normative References
[I-D.nordmark-6lowpan-reg]
Nordmark, E., "Neighbor Discovery Registration Extension",
draft-nordmark-6lowpan-reg-00 (work in progress),
June 2008.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
Bormann Expires January 9, 2009 [Page 5]
Internet-Draft 6lowpan context-based HC July 2008
7.2. Informative References
[I-D.hui-6lowpan-hc]
Hui, J., "Compression Format for IPv6 Datagrams in 6LoWPAN
Networks", draft-hui-6lowpan-hc-00 (work in progress),
March 2008.
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Phone: +49 421 218 63921
Fax: +49 421 218 7000
Email: cabo@tzi.org
Bormann Expires January 9, 2009 [Page 6]
Internet-Draft 6lowpan context-based HC July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Bormann Expires January 9, 2009 [Page 7]