[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 9, 2009.


   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

   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

   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

        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


7.  References

7.1.  Normative References

              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

              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

   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

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

   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

Bormann                  Expires January 9, 2009                [Page 7]