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]