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 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]