idnits 2.17.1 draft-bormann-6lowpan-cbhc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 255. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... therefore SHOULD only start using a...' RFC 2119 keyword, line 111: '...ues of a context SHOULD be taken out o...' RFC 2119 keyword, line 113: '... Nodes MUST stop using context infor...' RFC 2119 keyword, line 117: '...ty of damage, 6lowpan nodes SHOULD use...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2008) is 5761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.nordmark-6lowpan-reg' == Outdated reference: A later version (-01) exists of draft-hui-6lowpan-hc-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lowpan C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track July 8, 2008 5 Expires: January 9, 2009 7 Context-based Header Compression for 6lowpan 8 draft-bormann-6lowpan-cbhc-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 9, 2009. 35 Abstract 37 6lowpan (RFC 4944) so far has only defined stateless forms of header 38 compression. This document specifies how a node and a router can 39 agree on state that will allow much better header compression of 40 global addresses. 42 $Id: draft-bormann-6lowpan-cbhc.xml,v 1.2 2008/07/07 22:19:28 cabo 43 Exp $ 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Address Compression . . . . . . . . . . . . . . . . . . . . . . 4 50 4. Intra-Lowpan Use . . . . . . . . . . . . . . . . . . . . . . . 5 51 5. Security considerations . . . . . . . . . . . . . . . . . . . . 5 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 53 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 55 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Intellectual Property and Copyright Statements . . . . . . . . . . 7 59 1. Introduction 61 The 6lowpan format specification [RFC4944] defines a format for 62 transporting IPv6 packets over IEEE 802.15.4 networks. An important 63 aspect of this is the limited size of packets provided by 64 IEEE 802.15.4, which leaves only rather limited space in a packet 65 beyond the size of an IPv6 header. While larger packets can be sent 66 using segmentation and reassembly, 6lowpan is most efficient when all 67 IPv6 packets can be made to fit into a single IEEE 802.15.4 packet. 69 The largest part of IPv6 headers are the two Pv6 addresses in the 70 header, which in certain cases together can consume 40 % of the 71 usable space in a 6lowpan packet. [RFC4944] defines how to compress 72 certain forms of link-local addresses, but still requires the 73 transmission of global addresses at their full size. Since the whole 74 point of running IPv6 in a 6lowpan is to enable communication beyond 75 the local link, this is unsatisfactory. [I-D.hui-6lowpan-hc] 76 specifies one way of compressing globally routable addresses, but 77 does not explain how the common state between compressor and 78 decompressor is established. 80 An interesting proposal for establishing state between 6lowpan nodes 81 and their routers is [I-D.nordmark-6lowpan-reg]. The present 82 document proposes to establish the common state needed for efficient 83 compression of global addresses by using the registration mechanism 84 proposed there. 86 2. Protocol Operation 88 In order to enable the compression of global addresses, this 89 specification provides a way for nodes to establish context with 90 routers. This context can then be referred to in 6lowpan packets 91 exchanged between the node and the router and used for address field 92 compression. 94 When registering as a node according to [I-D.nordmark-6lowpan-reg], a 95 node can indicate its interest in receiving context by setting a bit 96 in the ND registration message. A router can include context in the 97 ND registration option in its router advertisements. 99 A node sending a 6lowpan message to a router can make use of the 100 context most recently received in a router advertisement from the 101 router. A router sending a 6lowpan message to a node can make use of 102 the context if the node has indicated interest in its registration 103 message. 105 Obviously, the most important aspect about a header compression 106 scheme is making sure the context stays synchronized. The router 107 therefore SHOULD only start using a context when a sufficient number 108 of router advertisements have been sent to establish it. To avoid 109 nodes sending packets making use of previous values of contexts and 110 the resulting ambiguity when receiving a packet that uses a recently 111 changed context, old values of a context SHOULD be taken out of use 112 for a while before new values are assigned to this specific context. 113 Nodes MUST stop using context information for a specific context when 114 a number of router advertisements have been received that do 115 not assign a value to this context. 117 To further reduce the probability of damage, 6lowpan nodes SHOULD use 118 context-based header compression only when a higher-layer protocol is 119 in use that protects the IPv6 addresses using some form of pseudo- 120 header based checksum and/or authenticator. 122 3. Address Compression 124 The requirement for old context information to time out from the 125 6lowpan before it can be replaced with new information suggests the 126 ability to use multiple contexts. This also allows to employ more 127 and less aggressive forms of address compression. This specification 128 therefore proposes the use of a single bit to indicate the use of 129 context-based header compression, plus a byte with the following 130 structure: 132 0 1 2 3 4 5 6 7 133 +---+---+---+---+---+---+---+---+ 134 | s s s s | d d d d | 135 +---+---+---+---+---+---+---+---+ 137 s and d supply the context numbers for the source and destination 138 address, respectively. Context number 0 is reserved for the 139 uncompressed transmission of the respective address. (TBD: Align 140 with existing [RFC4944] forms of address field compression.) 142 The contexts number 1 to 15 can be used for various prefixes. To 143 keep the packets self-describing, this specification defines the 144 prefix lengths associated with each context: 146 Context Prefix 147 Number Length 148 0 0 (uncompressed) 149 1-3 TBD 150 4-7 /64 151 8-11 /112 152 12-15 /128 154 This allows the router to not only establish context for one or more 155 /64 prefixes governing a specific link, but also for specific ranges 156 of addresses or even specific single global addresses of likely 157 correspondents of nodes in the 6lowpan. The latter addresses can be 158 compressed down to 16 or 0 bits, plus the overhead of context-based 159 header compression. 161 4. Intra-Lowpan Use 163 The mechanism, as described, is useful for packets exchanged between 164 routers and nodes. It could be extended to allow efficient intra- 165 6lowpan use of global addresses by indicating the "context interest" 166 bit in the ND information exchanged plus some conventions about 167 context use between routers. Details TBD. 169 5. Security considerations 171 The security considerations of [RFC4944] apply. 173 An attacker can trick nodes into sending packets to the wrong 174 destinations by sending fake router advertisements with carefully 175 crafted context information. However, any node that can craft router 176 advertisements that will be acted upon by nodes can already trick 177 nodes into various forms of undesirable behavior, so the same 178 mechanisms used for preventing against fake router advertisements 179 should be used for both cases. 181 6. IANA Considerations 183 TBD 185 7. References 187 7.1. Normative References 189 [I-D.nordmark-6lowpan-reg] 190 Nordmark, E., "Neighbor Discovery Registration Extension", 191 draft-nordmark-6lowpan-reg-00 (work in progress), 192 June 2008. 194 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 195 "Transmission of IPv6 Packets over IEEE 802.15.4 196 Networks", RFC 4944, September 2007. 198 7.2. Informative References 200 [I-D.hui-6lowpan-hc] 201 Hui, J., "Compression Format for IPv6 Datagrams in 6LoWPAN 202 Networks", draft-hui-6lowpan-hc-00 (work in progress), 203 March 2008. 205 Author's Address 207 Carsten Bormann 208 Universitaet Bremen TZI 209 Postfach 330440 210 Bremen D-28334 211 Germany 213 Phone: +49 421 218 63921 214 Fax: +49 421 218 7000 215 Email: cabo@tzi.org 217 Full Copyright Statement 219 Copyright (C) The IETF Trust (2008). 221 This document is subject to the rights, licenses and restrictions 222 contained in BCP 78, and except as set forth therein, the authors 223 retain all their rights. 225 This document and the information contained herein are provided on an 226 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 227 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 228 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 229 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 230 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 231 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 233 Intellectual Property 235 The IETF takes no position regarding the validity or scope of any 236 Intellectual Property Rights or other rights that might be claimed to 237 pertain to the implementation or use of the technology described in 238 this document or the extent to which any license under such rights 239 might or might not be available; nor does it represent that it has 240 made any independent effort to identify any such rights. Information 241 on the procedures with respect to rights in RFC documents can be 242 found in BCP 78 and BCP 79. 244 Copies of IPR disclosures made to the IETF Secretariat and any 245 assurances of licenses to be made available, or the result of an 246 attempt made to obtain a general license or permission for the use of 247 such proprietary rights by implementers or users of this 248 specification can be obtained from the IETF on-line IPR repository at 249 http://www.ietf.org/ipr. 251 The IETF invites any interested party to bring to its attention any 252 copyrights, patents or patent applications, or other proprietary 253 rights that may cover technology that may be required to implement 254 this standard. Please address the information to the IETF at 255 ietf-ipr@ietf.org.