idnits 2.17.1 draft-thubert-6lo-inner-compression-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC6282, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC6282, updated by this document, for RFC5378 checks: 2008-10-08) -- 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 (February 10, 2016) is 2991 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) == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 286, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-6lo-routing-dispatch-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 6282 (if approved) X. Vilajosana 5 Intended status: Standards Track Universitat Oberta de Catalunya 6 Expires: August 13, 2016 S. Duquennoy 7 Inria 8 February 10, 2016 10 6LoWPAN Inner Compression 11 draft-thubert-6lo-inner-compression-00 13 Abstract 15 This specification modifies 6LoWPAN stateless address compression to 16 enable the compression by 6LOWPAN_IPHC of non Link-Local addresses in 17 an IP header when a reference address can be found in an 18 encapsulation. . 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 13, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Updating RFC 6282 . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Compression References . . . . . . . . . . . . . . . . . . . 3 58 4.1. For Source IP From Encapsulating IP Header . . . . . . . 4 59 4.2. For Destination IP From Encapsulating IP Header . . . . . 4 60 4.3. Preceding 6LoRH Header . . . . . . . . . . . . . . . . . 4 61 5. Stateless Compression of the Source Address . . . . . . . . . 5 62 6. Stateless Compression of the Destination Address . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 10.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 The design of Low Power and Lossy Networks (LLNs) is generally 74 focused on saving energy, a very constrained resource in most cases. 75 The other constraints, such as the memory capacity and the duty 76 cycling of the LLN devices, derive from that primary concern. Energy 77 is often available from primary batteries that are expected to last 78 for years, or is scavenged from the environment in very limited 79 quantities. Any protocol that is intended for use in LLNs must be 80 designed with the primary concern of saving energy as a strict 81 requirement. 83 Controlling the amount of data transmission is one possible venue to 84 save energy. In a number of LLN standards, the frame size is limited 85 to much smaller values than the IPv6 maximum transmission unit (MTU) 86 of 1280 bytes. In particular, an LLN that relies on the classical 87 Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is limited to 127 88 bytes per frame. The need to compress IPv6 packets over IEEE 89 802.15.4 led to the 6LoWPAN Header Compression [RFC6282] work 90 (6LoWPAN-HC). 92 6LoWPAN-HC is designed to support more than one IPv6 address per node 93 and per Interface Identifier (IID), an IID being typically derived 94 from a MAC address to optimize the compression. The stateless 95 address compression modes (SAC/DAC=0) enable the compression of Link 96 Local Addresses only. The suffix is found either in-line or in the 97 MAC header or an encapsulating IP header. The other addresses, 98 Global and Unique-Local Addresses, can be only compressed with 99 stateful address compression modes (SAC/DAC=1), whereby the prefix is 100 found in a context. 102 In the case of an IP-in-IP encapsulation in a LLN, either or both the 103 source or the destination address in the inner header is usually 104 derived from the same prefix as the encapsulating header and could be 105 compressed without a context. This specification updates [RFC6282] 106 stateless address compression to use the prefixes found in 107 encapsulating headers as compression reference as opposed to the link 108 local prefix. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [RFC2119]. 117 The Terminology used in this document is consistent with and 118 incorporates that described in `Terminology in Low power And Lossy 119 Networks' [RFC7102] and [RFC7228]. 121 3. Updating RFC 6282 123 This draft updates the LOWPAN-IPHC compression specified in 6LoWPAN- 124 HC [RFC6282] in the cases where SAC=0 and where M=0 and DAC=0. 126 The change is that the prefix that is used as compression reference 127 is not necessarily derived from the link local prefix but may be 128 obtained from a preceding header. 130 If no prefix is located in a preceding header then the stateless 131 compression based on the link local prefix and specified in [RFC6282] 132 still applies. 134 Locating a prefix for the compression of the source address (SAC=0) 135 is discussed in Section 4.1 and Section 4.3. Locating a prefix for 136 the compression of the destination address (M=0 and DAC=0) is 137 discussed in Section 4.2 and Section 4.3. 139 4. Compression References 141 The native origin for a compression reference is in an IP-in-IP 142 encapsulating header. This is discussed in Section 4.1 and 143 Section 4.2. Other headers such as the 6LoWPAN Routing Header 145 [I-D.ietf-6lo-routing-dispatch] (6LoRH) can be also serve as 146 reference; that particular case is discussed in Section 4.3. 148 4.1. For Source IP From Encapsulating IP Header 150 If the IP header that is compressed with LoWPAN_IPHC is encapsulated 151 in another IP header, the compression reference is the source of that 152 encapsulating header, that is the address of the node that performed 153 the encapsulation, whether that encapsulating header was itself 154 encapsulated again or not. 156 4.2. For Destination IP From Encapsulating IP Header 158 If the IP header that is compressed with LoWPAN_IPHC is encapsulated 159 in another IP header, the compression reference is the address of the 160 destination of the encapsulating IP packet, that is the node that 161 eventually performs the decapsulation of the IP header. 163 If a routing header is present in the encapsulating IP header chain, 164 this is the last address in the last routing header at the time the 165 encapsulation is generated. In the uncompressed form of a Routing 166 Header type 3 [RFC6554], it is swapped with the address of the 167 destination at the time the packet reaches it, and thus found in the 168 IP header as opposed to the routing header. 170 4.3. Preceding 6LoRH Header 172 The 6LoWPAN Routing Header [I-D.ietf-6lo-routing-dispatch] 173 specification documents a compression scheme for the RPL artifacts in 174 data packet. The compressed format places the artifacts in 6LoRH 175 Headers that are located before the LOWPAN_IPHC, even when there is 176 not IP-in-IP encapsulation. 178 If there is no IP-in-IP encapsulation but the IP header that is 179 compressed with LoWPAN_IPHC is preceded in the compressed form by an 180 RH3-6LoRH header, then the last address in the last RH3-6LoRH header 181 is the compression reference for the destination address. 183 If there is an IP-in-IP encapsulation compressed with IP-in-IP-6LoRH, 184 then the address of the destination of the encapsulating IP packet is 185 encoded in a RH3-6LoRH as well, so the last address in the last 186 RH3-6LoRH header is also the compression reference for the 187 destination address. 189 If there is no IP encapsulation but the IP header that is compressed 190 with LoWPAN_IPHC is preceded in the compressed form by an RPI-6LoRH 191 header that identifies a RPL DODAG [RFC6550], then the address of the 192 root of the DODAG is the compression reference for the source 193 address. It is also the compression reference for the destination 194 address in the absence of an RH3-6LoRH header. 196 5. Stateless Compression of the Source Address 198 This section covers the case of stateless address compression (SAC=0) 199 of the source address in a LOWPAN-IPHC. 201 If a compression reference Section 4.1 cannot be found, then 202 [RFC6282] applies. Else, the compression depends on the value of the 203 SAM bits as follows: 205 00: 128 bits. The full address is carried in-line 207 01: 64 bits. The first 64-bits of the address are elided and 208 obtained from the compression reference; the remaining 64 bits are 209 carried in-line 211 10: 16 bits. The first 112 bits of the address are elided and 212 obtained from the compression reference; the remaining 16 bits are 213 carried in-line 215 11: 0 bits. The address is fully elided, it is the same as the 216 compression reference. 218 6. Stateless Compression of the Destination Address 220 This section covers the case of stateless unicast address compression 221 (M=0, DAC=0) of the destination address in a LOWPAN-IPHC. 223 If a compression reference Section 4.2 cannot be found, then 224 [RFC6282] applies. Else, the compression depends on the value of the 225 DAM bits as follows: 227 00: 128 bits. The full address is carried in-line 229 01: 64 bits. The first 64-bits of the address are elided and 230 obtained from the compression reference; the remaining 64 bits are 231 carried in-line 233 10: 16 bits. The first 112 bits of the address are elided and 234 obtained from the compression reference; the remaining 16 bits are 235 carried in-line 237 11: 0 bits. The address is fully elided, it is the same as the 238 compression reference. 240 7. Security Considerations 242 The security considerations of [RFC4944] and [RFC6282] apply. 244 8. IANA Considerations 246 This document does not have requirements for IANA. 248 9. Acknowledgments 250 The authors wish to thank Thomas Watteyne, Maria-Rita Palatella, 251 Aurelie Sfez and Miguel Angel Reina Ortega for organizing the 6TiSCH 252 PlugTest with the ETSI. 254 10. References 256 10.1. Normative References 258 [I-D.ietf-6lo-routing-dispatch] 259 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 260 "6LoWPAN Routing Header", draft-ietf-6lo-routing- 261 dispatch-04 (work in progress), January 2016. 263 [IEEE802154] 264 IEEE standard for Information Technology, "IEEE std. 265 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 266 and Physical Layer (PHY) Specifications for Low-Rate 267 Wireless Personal Area Networks". 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 275 "Transmission of IPv6 Packets over IEEE 802.15.4 276 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 277 . 279 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 280 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 281 DOI 10.17487/RFC6282, September 2011, 282 . 284 10.2. Informative References 286 [I-D.ietf-6tisch-architecture] 287 Thubert, P., "An Architecture for IPv6 over the TSCH mode 288 of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work 289 in progress), November 2015. 291 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 292 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 293 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 294 Low-Power and Lossy Networks", RFC 6550, 295 DOI 10.17487/RFC6550, March 2012, 296 . 298 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 299 Routing Header for Source Routes with the Routing Protocol 300 for Low-Power and Lossy Networks (RPL)", RFC 6554, 301 DOI 10.17487/RFC6554, March 2012, 302 . 304 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 305 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 306 2014, . 308 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 309 Constrained-Node Networks", RFC 7228, 310 DOI 10.17487/RFC7228, May 2014, 311 . 313 Authors' Addresses 315 Pascal Thubert (editor) 316 Cisco Systems 317 Building D - Regus 318 45 Allee des Ormes 319 BP1200 320 MOUGINS - Sophia Antipolis 06254 321 FRANCE 323 Phone: +33 4 97 23 26 34 324 Email: pthubert@cisco.com 325 Xavier Vilajosana 326 Universitat Oberta de Catalunya 327 156 Rambla Poblenou 328 Barcelona, Catalonia 08018 329 Spain 331 Phone: +34 (646) 633 681 332 Email: xvilajosana@uoc.edu 334 Simon Duquennoy 335 Inria 336 40, avenue Halley 337 Villeneuve d'Ascq 59650 338 France 340 Phone: +33 768227731 341 Email: simon.duquennoy@inria.fr