idnits 2.17.1 draft-bormann-6lowpan-ext-hdr-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 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. 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 : ---------------------------------------------------------------------------- No issues found here. 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 2, 2008) is 5769 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) == Missing Reference: 'RFCthis' is mentioned on line 166, but not defined -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 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 2, 2008 5 Expires: January 3, 2009 7 Extension headers for 6lowpan 8 draft-bormann-6lowpan-ext-hdr-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 3, 2009. 35 Abstract 37 6lowpan applications sometimes need to include application-specific 38 information in layer 2 packets that are intended to be processed as 39 6lowpan packets. This document specifies a way to include this 40 information in a 6lowpan packet in such a way that it can be ignored 41 by implementations that don't care for it. 43 $Id: draft-bormann-6lowpan-ext-hdr.xml,v 1.5 2008/07/02 06:23:58 cabo 44 Exp $ 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Extension Header . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Security considerations . . . . . . . . . . . . . . . . . . . . 4 51 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 52 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 53 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 55 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. 6lowpan 63 applications sometimes need to include application-specific 64 information in these layer 2 packets, even though they are ultimately 65 intended to be processed as 6lowpan packets. This document specifies 66 a way to include this information in a 6lowpan packet in such a way 67 that it can be ignored by implementations that don't care for it. 69 One motivation for this document is the emerging ISA100.11a 70 specification [ISA-100-11a], which uses the 6lowpan mechanism to 71 identify a layer 2 frame as "NALP" (Not a Lowpan frame) as it needs 72 to transport non-6lowpan information at the start of the packet and 73 is thus not compatible with the basic 6lowpan frame format. The 74 choice of NALP will make it impossible for standard-conforming 75 6lowpan implementations to interpret any ISA100.11a packets, even if 76 the ISA100.11a specific information in those headers is of no concern 77 to the device processing the packet. 79 The present specification defines an extension header in the spirit 80 of RTP's extension header, which "is designed so that the header 81 extension may be ignored by other interoperating implementations that 82 have not been extended" [RFC3550]. The requirements for such an 83 extension header in 6lowpan are modest, as the overall frame size of 84 the IEEE 802.15.4 frame is rather limited: It is simply not very 85 useful to define an elaborate option structure such as that provided 86 by IPv6 hop-by-hop options [RFC2460]. Similar to RFC 3550, the 87 present specification therefore limits itself to defining as much of 88 the format as is needed by non-interested implementations to skip the 89 extension header. 6lowpan applications are expected to define how 90 extension headers used in the application, if any, are interpreted. 92 Another consequence of the limited frame size of IEEE 802.15.4 is the 93 limited size that is expected to be useful for extension headers. 94 The present specification supports extension headers with any number 95 between 1 to 16 bytes of payload. However, due to the way 6lowpan 96 headers are structured, multiple extension headers can be present in 97 one IEEE 802.15.4 frame. If an application should need more than 16 98 bytes of extension header space in a single IEEE 802.15.4 frame, it 99 needs to divide the information into multiple extension headers. 101 2. Extension Header 103 This section motivates and then defines the detailed structure of the 104 extension header. 106 Given the requirements set out above, we opt for a simple format for 107 the extension header: the initial byte both indicates the presence of 108 the extension header and the length of its payload, and the rest of 109 the header are the payload bytes. As we need to support 1 to 16 110 bytes of payload (and assuming that all 16 numbers need to be 111 supported), four bits of the initial byte are used for supplying the 112 payload length. 114 The remaining question is what space those 16 initial byte values 115 should be taken from. The NALP space is reserved for non-6lowpan 116 frames. The dispatch byte space is theoretically available, but 117 quite limited; taking out 16 of the 64 values would be a significant 118 reduction of that space. Therefore, the present specification opts 119 for allocating 16 values out of the unused values in the fragment 120 header space, i.e., the values 1101nnnn (where nnnn is the binary 121 length of the payload in bytes minus 1). The resulting structure of 122 the extension header is: 124 0 1 2 3 4 5 6 7 125 +---+---+---+---+---+---+---+---+ 126 | 1 1 0 1 | n n n n | initial byte 127 +---+---+---+---+---+---+---+---+ 128 : : 129 / 1-16 octets of payload / nnnn + 1 bytes 130 : : 131 +---+---+---+---+---+---+---+---+ 133 The extension header is followed by a valid 6lowpan packet, which may 134 again start with an extension header to accommodate more than 16 135 bytes of extension payload. Where multiple extension headers are 136 used in one packet, the application is free to assign semantics to 137 the payload lengths actually used, i.e., an extension header with 10 138 bytes and one with 12 bytes may be interpreted by the application in 139 a different way than an extension header with 12 bytes (containing 140 the 10 bytes of the first extension header in the previous form plus 141 the first two bytes of the second extension header in the previous 142 form) and an extension header with 10 bytes (containing the last 10 143 bytes of the second extension header in the previous form) would be. 144 This can be used to imply length information that may otherwise 145 require length fields in the payload. 147 3. Security considerations 149 The security considerations of [RFC4944] apply. 151 Application developers making use of this specification must keep in 152 mind that security mechanisms that operate on layer 3 and above will 153 not protect the layer 2 headers including the extension header. 155 4. IANA Considerations 157 The "6lowpan-parameters" registry needs to be updated by replacing 159 11 001000 through 11 011111 160 reserved for future use 162 with 164 11 001000 through 11 001111 165 reserved for future use 166 11 01xxxx EXT -- Extension Header [RFCthis] 168 5. Acknowledgements 170 This document was prompted by Geoff Mulligan's observations on the 171 ISA100.11a work. 173 6. References 175 6.1. Normative References 177 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 178 "Transmission of IPv6 Packets over IEEE 802.15.4 179 Networks", RFC 4944, September 2007. 181 6.2. Informative References 183 [ISA-100-11a] 184 ISA, "ISA100.11a Draft standard", May 2008. 186 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 187 (IPv6) Specification", RFC 2460, December 1998. 189 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 190 Jacobson, "RTP: A Transport Protocol for Real-Time 191 Applications", STD 64, RFC 3550, July 2003. 193 Author's Address 195 Carsten Bormann 196 Universitaet Bremen TZI 197 Postfach 330440 198 Bremen D-28334 199 Germany 201 Phone: +49 421 218 63921 202 Fax: +49 421 218 7000 203 Email: cabo@tzi.org 205 Full Copyright Statement 207 Copyright (C) The IETF Trust (2008). 209 This document is subject to the rights, licenses and restrictions 210 contained in BCP 78, and except as set forth therein, the authors 211 retain all their rights. 213 This document and the information contained herein are provided on an 214 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 215 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 216 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 217 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 218 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 219 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 221 Intellectual Property 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed to 225 pertain to the implementation or use of the technology described in 226 this document or the extent to which any license under such rights 227 might or might not be available; nor does it represent that it has 228 made any independent effort to identify any such rights. Information 229 on the procedures with respect to rights in RFC documents can be 230 found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the use of 235 such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository at 237 http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at 243 ietf-ipr@ietf.org.