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]