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

Versions: 00                                                            
6lowpan                                                       C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                            July 2, 2008
Expires: January 3, 2009


                     Extension headers for 6lowpan
                  draft-bormann-6lowpan-ext-hdr-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 3, 2009.

Abstract

   6lowpan applications sometimes need to include application-specific
   information in layer 2 packets that are intended to be processed as
   6lowpan packets.  This document specifies a way to include this
   information in a 6lowpan packet in such a way that it can be ignored
   by implementations that don't care for it.

   $Id: draft-bormann-6lowpan-ext-hdr.xml,v 1.5 2008/07/02 06:23:58 cabo
   Exp $







Bormann                  Expires January 3, 2009                [Page 1]


Internet-Draft          6lowpan extension header               July 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Extension Header  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Security considerations . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7







































Bormann                  Expires January 3, 2009                [Page 2]


Internet-Draft          6lowpan extension header               July 2008


1.  Introduction

   The 6lowpan format specification [RFC4944] defines a format for
   transporting IPv6 packets over IEEE 802.15.4 networks. 6lowpan
   applications sometimes need to include application-specific
   information in these layer 2 packets, even though they are ultimately
   intended to be processed as 6lowpan packets.  This document specifies
   a way to include this information in a 6lowpan packet in such a way
   that it can be ignored by implementations that don't care for it.

   One motivation for this document is the emerging ISA100.11a
   specification [ISA-100-11a], which uses the 6lowpan mechanism to
   identify a layer 2 frame as "NALP" (Not a Lowpan frame) as it needs
   to transport non-6lowpan information at the start of the packet and
   is thus not compatible with the basic 6lowpan frame format.  The
   choice of NALP will make it impossible for standard-conforming
   6lowpan implementations to interpret any ISA100.11a packets, even if
   the ISA100.11a specific information in those headers is of no concern
   to the device processing the packet.

   The present specification defines an extension header in the spirit
   of RTP's extension header, which "is designed so that the header
   extension may be ignored by other interoperating implementations that
   have not been extended" [RFC3550].  The requirements for such an
   extension header in 6lowpan are modest, as the overall frame size of
   the IEEE 802.15.4 frame is rather limited: It is simply not very
   useful to define an elaborate option structure such as that provided
   by IPv6 hop-by-hop options [RFC2460].  Similar to RFC 3550, the
   present specification therefore limits itself to defining as much of
   the format as is needed by non-interested implementations to skip the
   extension header. 6lowpan applications are expected to define how
   extension headers used in the application, if any, are interpreted.

   Another consequence of the limited frame size of IEEE 802.15.4 is the
   limited size that is expected to be useful for extension headers.
   The present specification supports extension headers with any number
   between 1 to 16 bytes of payload.  However, due to the way 6lowpan
   headers are structured, multiple extension headers can be present in
   one IEEE 802.15.4 frame.  If an application should need more than 16
   bytes of extension header space in a single IEEE 802.15.4 frame, it
   needs to divide the information into multiple extension headers.


2.  Extension Header

   This section motivates and then defines the detailed structure of the
   extension header.




Bormann                  Expires January 3, 2009                [Page 3]


Internet-Draft          6lowpan extension header               July 2008


   Given the requirements set out above, we opt for a simple format for
   the extension header: the initial byte both indicates the presence of
   the extension header and the length of its payload, and the rest of
   the header are the payload bytes.  As we need to support 1 to 16
   bytes of payload (and assuming that all 16 numbers need to be
   supported), four bits of the initial byte are used for supplying the
   payload length.

   The remaining question is what space those 16 initial byte values
   should be taken from.  The NALP space is reserved for non-6lowpan
   frames.  The dispatch byte space is theoretically available, but
   quite limited; taking out 16 of the 64 values would be a significant
   reduction of that space.  Therefore, the present specification opts
   for allocating 16 values out of the unused values in the fragment
   header space, i.e., the values 1101nnnn (where nnnn is the binary
   length of the payload in bytes minus 1).  The resulting structure of
   the extension header is:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 1   1   0   1 | n   n   n   n |  initial byte
      +---+---+---+---+---+---+---+---+
      :                               :
      /    1-16 octets of payload     /  nnnn + 1 bytes
      :                               :
      +---+---+---+---+---+---+---+---+

   The extension header is followed by a valid 6lowpan packet, which may
   again start with an extension header to accommodate more than 16
   bytes of extension payload.  Where multiple extension headers are
   used in one packet, the application is free to assign semantics to
   the payload lengths actually used, i.e., an extension header with 10
   bytes and one with 12 bytes may be interpreted by the application in
   a different way than an extension header with 12 bytes (containing
   the 10 bytes of the first extension header in the previous form plus
   the first two bytes of the second extension header in the previous
   form) and an extension header with 10 bytes (containing the last 10
   bytes of the second extension header in the previous form) would be.
   This can be used to imply length information that may otherwise
   require length fields in the payload.


3.  Security considerations

   The security considerations of [RFC4944] apply.

   Application developers making use of this specification must keep in
   mind that security mechanisms that operate on layer 3 and above will



Bormann                  Expires January 3, 2009                [Page 4]


Internet-Draft          6lowpan extension header               July 2008


   not protect the layer 2 headers including the extension header.


4.  IANA Considerations

   The "6lowpan-parameters" registry needs to be updated by replacing

   11 001000 through 11 011111
                reserved for future use

   with

   11 001000 through 11 001111
                reserved for future use
   11 01xxxx    EXT -- Extension Header [RFCthis]


5.  Acknowledgements

   This document was prompted by Geoff Mulligan's observations on the
   ISA100.11a work.


6.  References

6.1.  Normative References

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

6.2.  Informative References

   [ISA-100-11a]
              ISA, "ISA100.11a Draft standard", May 2008.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.









Bormann                  Expires January 3, 2009                [Page 5]


Internet-Draft          6lowpan extension header               July 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 3, 2009                [Page 6]


Internet-Draft          6lowpan extension header               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 3, 2009                [Page 7]