idnits 2.17.1 draft-jiang-asymmetric-ipv6-02.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2019) is 1638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-02 == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-21 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational G. Li 5 Expires: May 1, 2020 Huawei Technologies 6 B. Carpenter 7 Univ. of Auckland 8 October 29, 2019 10 Asymmetric IPv6 for IoT Networks 11 draft-jiang-asymmetric-ipv6-02 13 Abstract 15 This document describes a new approach to IPv6 header compression for 16 use in scenarios where minimizing packet size is crucial but routing 17 performance must be maximised. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 1, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Address Transformation at the Gateway . . . . . . . . . . . . 5 56 4. Routing without Decompression . . . . . . . . . . . . . . . . 6 57 5. Address Configuration . . . . . . . . . . . . . . . . . . . . 6 58 6. Compatibility with Existing Protocols . . . . . . . . . . . . 7 59 7. Relationship to Static Context Header Compression . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 The large address space of IPv6 is essential for the massive 70 expansion of the network edge that will be caused by "Internet of 71 Things" (IoT) technology over low-power or 5G links. However, the 72 size of a raw IPv6 packet header causes difficulty due to the small 73 maximum transmission units (MTU) allowed by typical low-power, low- 74 cost link layers. For 5G, this aspect is discussed in 75 [I-D.ietf-dmm-5g-uplane-analysis]. Thus header compression, 76 including address compression, is an important issue. This decreases 77 the size of raw packets, but compressed IP addresses are not 78 routeable except by decompressing them completely in every forwarding 79 node. There are two issues here. The first is the extra computation 80 resource needed for compressing or decompressing in constrained IoT 81 nodes. The second is that full-length IPv6 routing will consume more 82 memory to store routing tables and packet queues. Such resource 83 consumption is very undesirable in constrained nodes with limited 84 storage, CPU power, and battery capacity. 86 To mitigate these issues, here we propose a solution enabling the 87 shortening of IPv6 addresses inside packets, and the routing of 88 packets according to short addresses, without needing the overhead of 89 a decompression step prior to route lookup. Considering that the 90 scale and size of edge networks may vary widely, different lengths of 91 short address can be used in different domains. 93 As an illustrative example, consider an edge network which is known 94 to never require more than a few hundred nodes, which in most cases 95 will communicate either with each other, or with application layer 96 gateways to the rest of the Internet. Rather than needing 128-bit 97 addresses, such a network could very well operate with 16-bit 98 addresses. Also, it could very likely operate without needing 99 enhancements such as differentiated services, ECN or flow labels. If 100 only IPv6 is supported, the version number field is pointless. There 101 is no reason for IPv6 packets within such a network to contain 102 40-byte headers as specified in [RFC8200]. Therefore, the useful 103 information could be carried in 8 bytes (see Figure 1). Furthermore, 104 routers within the edge network can route packets directly on 16-bit 105 addresses, reducing RIB and FIB sizes and the lookup time. 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Payload Length | Next Header | Hop Limit | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Source Address | Destination Address | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Figure 1 115 This work is distinct from previous work on address compression 116 [RFC6282] [RFC7400]. Although those solutions tackle the problem of 117 small MTU size, they do not address the problem of decompression 118 overhead. 120 This work is also distinct from ongoing work on static context header 121 compression [I-D.ietf-lpwan-ipv6-static-context-hc], as discussed in 122 more detail below. 124 Finally, this work is distinct from the 6LoWPAN Routing Header 125 [RFC8138], which can support truncated addresses in a different way. 127 2. Proposed Solution 129 The use of IPv6 naturally implies 128-bit addresses for both source 130 and destination. However, this address size is huge by the standards 131 of IoT edge networks. We propose the use of a context parameter to 132 indicate the effective length of the IP address for every node in a 133 local domain. If the effective length is N bits, then all addresses 134 in the domain are assumed to be preceded by a common prefix of 128-N 135 bits, when a full size IPv6 address is needed. Any node in the 136 domain that needs the full address, such as a gateway node to the 137 Internet, can therefore easily synthesize it. 139 The address length parameter may be needed by every node in the 140 domain. It can be spread by various techniques: 142 o Configure the address length in every node. 144 o Obtain the address length from a gateway (next hop router) node. 146 o Negotiate the address length between neighbors. 148 The solution operates by shortening IP address fields to save 149 overhead. To enhance this, we propose a new field named Flexible 150 Header Encoding (FHE). It consists of 8 bits, each indicating 151 whether the corresponding IPv6 header field [RFC8200] exists. 153 Bit 0 indicates the Modified Version field 155 Bit 1 indicates the Traffic Class field 157 Bit 2 indicates the Flow Label field. 159 Bit 3 indicates the Payload Length field. 161 Bit 4 indicates the Next Header field. (Zero implies "No Next 162 Header", value 59) 164 Bit 5 indicates the Hop Limit field. 166 Bit 6 indicates the Source Address field. 168 Bit 7 indicates the Destination Address field. 170 The "Version" field is a special case. In the context of FHE, all 171 packets are presumed to be IPv6 so the normal version field has no 172 purpose. The Modified Version field, if present, has the following 173 encoded meanings: 175 0b0000: The source address (if exist) has pre-determined length 176 inside the domain and the destination address (if exist) uses 177 standard 128-bit IPv6 address. (Outward traffic) 179 0b0001: The source address (if exist) uses standard 128-bit IPv6 180 address and the destination address (if exist) has pre-determined 181 length inside the domain. (Inward traffic) 183 0b0010: The source address and destination address have the same 184 length inside the domain. The address length will be pre- 185 determined. 187 0b0110: Reserved for IPv6 compatible case. 189 0b0100: Reserved for IPv4 compatible case. 191 0b0011~0b1111(except 0b0110, 0b0100): Reserved. 193 All fields, including the Modified Version field, follow the FHE in 194 the same order as in [RFC8200], with no padding. There are no 195 alignment requirements, but when a packet is decompressed to a normal 196 IPv6 format, padding options as defined in RFC8200 must be inserted. 198 Compared to the illustrative example in Figure 1, the actual packet 199 size would therefore be 10 bytes, a considerable improvement on the 200 standard 40 bytes. 202 One implication of the above is that the source and destination 203 addresses may be elided completely if they are implicit. Sourceless 204 packets were originally suggested in [crowcroft]. 206 Figure 2 illustrates an example of the FHE format. In this example 207 the traffic class, flow label and source address are elided, and the 208 destination address is truncated to 16 bits. The modified version 209 field could be 0b0001 or 0b0010. 211 FHE octet 212 Modified +-+-+-+-+-+-+-+-+ 213 Version |1 0 0 1 1 1 0 1| 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |0 0 0 1| Payload Length | Next Header | Hop | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Limit | Truncated Destination Address | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 219 | | 220 + Transport payload | 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+......... 224 Figure 2 226 Note that Asymmetric IPv6 does not contain any special handling for 227 IPv6 fragmentation, which will operate exactly as described in 228 [RFC8200], with Asymmetric IPv6 applied to each fragment packet. 229 However, we assume that in IoT deployment scenarios, packets whose 230 length exceeds the IPv6 minimum link MTU before applying Asymmetric 231 IPv6 will be rare. If the underlying link layer cannot carry 232 complete packets even after applying Asymmetric IPv6 compression, an 233 adaptation layer will be necessary exactly as for normal IPv6. 235 3. Address Transformation at the Gateway 237 Truncated intra-domain addresses will be used to identify nodes 238 inside the domain. When a packet is sent from an IoT node to an 239 external IPv6 host , the node's intra-domain address, which is unique 240 in the domain, will be carried in the source address field. When the 241 packet is forwarded outside the domain by a gateway, the intra-domain 242 address will be transformed to a complete IPv6 address. To achieve 243 this, the gateway should will maintain a globally routeable prefix 244 for all the nodes in the domain. When a packet with an intra-domain 245 source address is received, the gateway extracts this address and 246 concatenates it to the prefix to form a standard, globally unique 247 IPv6 address. Vice versa, when IPv6 packets are received from the 248 Internet, the prefix will be removed to recover the intra-domain 249 short address. 251 There are two options for handling the addresses of external hosts 252 within the domain. One is to use their full IPv6 addresses via 253 Modified Version codes 0b0000 and 0b0001. The other is effectively a 254 specialized form of Network Address Translation. Here, the gateway 255 will maintain a dynamic mapping table between synthetic intra-domain 256 addresses and IPv6 addresses. As packets are received, the gateway 257 performs the appropriate mapping. The transformation must be 258 checksum-neutral for the transport layer, so the methods designed for 259 NAT46 should be adapted. 261 NOTE IN DRAFT: Details and references TBD. 263 It is an engineering choice whether this method is preferable to 264 carrying full 128-bit addresses on the IOT side. 266 4. Routing without Decompression 268 Routing mechanisms may readily be adapted to truncated address sizes. 269 If there is routing with an HFE domain, we assume that the truncated 270 address size will be split into a prefix and an interface identifier, 271 but this will not be at the traditional /64 boundary. If routing 272 between different length addresses is required, a suitably modified 273 Forwarding Information Base (FIB) structure is needed, as for any 274 variable length addressing scheme. A truncated address needs to be 275 virtually expanded to 128 bits at the router's inbound interface, 276 although this may not be the physical implementation. 278 A possible routing choice for IOT edge networks is RPL [RFC6550], 279 although a more complete survey can be found in [talwar]. 281 5. Address Configuration 283 The simplest approach to address configuration is simply to run 284 normal IPv6 procedures (SLAAC or DHCPv6), on the argument that this 285 is a rare process and the overhead does not matter. If the truncated 286 address size is less than 64 bits, it will be necessary to use 287 shorter interface identifiers than normal, but this is not a major 288 change. Once a node has acquired an IPv6 address and has learned the 289 local address length parameter as outlined in Section 2, it can 290 continue in FHE mode. 292 6. Compatibility with Existing Protocols 294 Although HFE nodes can only talk directly to each other, they are 295 essentially a special form of IPv6 node and they can communicate with 296 the whole IPv6 Internet via gateways. The complexity is not greater 297 than 6LoWPAN. If appropriate, the 6LoWPAN adaptation layer [RFC4944] 298 could be used, with a specific dispatch type. 300 7. Relationship to Static Context Header Compression 302 Static Context Header Compression (SCHC) 303 [I-D.ietf-lpwan-ipv6-static-context-hc] is a powerful mechanism for 304 reducing IPv6 packet size in an IoT application environment. In 305 particular it includes a profile for UDP over IPv6, and a somewhat 306 modified version of this profile could achieve much of what 307 Asymmetric IPv6 proposes. In addition, SCHC provides support for 308 fragmentation in the case of very small link MTUs. However, SCHC is 309 by design static, and once a context is established the fields to be 310 compressed do not change. Asymmetric IPv6 transmits the FHE and 311 Modified Version bytes with every packet, so it provides dynamic 312 choice as to which header elements are compressed or elided. 314 In a context where the desirable compression is fixed, e.g. every 315 address is the same length, the flow label is never used, etc., SCHC 316 can used to the same effect as Asymmetric IPv6. However, if the 317 behavior needs to be dynamic, the signaling power of the FHE and 318 Modified Version bytes in Asymmetric IPv6 is needed. 320 Further study is needed whether the advantages of the two mechanisms 321 can be combined. 323 8. Security Considerations 325 HFE is essentially only a non-cryptographic compression technique so 326 it neither adds to nor reduces the intrinsic security of an IPv6 327 packet. The address length parameter is not a secret, since all 328 nodes in the domain must know it. The mechanism for distributing 329 this parameter must be no less secure than any other configuration 330 mechanism in us. 332 Address-based privacy issues must be considered in deciding on the 333 address length. If the number of bits available for the interface 334 identifier is significantly less than the 64 currently in use, 335 address traceability and guessability will be affected. However, if 336 the traffic with short addresses is confined to within the edge 337 network, the privacy issue will be minimized. [RFC7721] and 338 [RFC7217] should be consulted prior to deciding the address length. 340 9. IANA Considerations 342 This document makes no request of the IANA. 344 NOTE IN DRAFT: If the solution of a 6LoWPAN dispatch type is adopted, 345 a suitable assignment request will be added. 347 10. Acknowledgements 349 Useful comments were received from Cheng Li, Pascal Thubert, Laurent 350 Toutain and others. 352 11. References 354 [crowcroft] 355 Crowcroft, J. and M. Bagnulo, "SNA: Sourceless Network 356 Architecture", University of Cambridge Computer Laboratory 357 Technical Report UCAM-CL-TR-849, 2014. 359 [I-D.ietf-dmm-5g-uplane-analysis] 360 Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, 361 "User Plane Protocol and Architectural Analysis on 3GPP 5G 362 System", draft-ietf-dmm-5g-uplane-analysis-02 (work in 363 progress), July 2019. 365 [I-D.ietf-lpwan-ipv6-static-context-hc] 366 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 367 Zuniga, "Static Context Header Compression (SCHC) and 368 fragmentation for LPWAN, application to UDP/IPv6", draft- 369 ietf-lpwan-ipv6-static-context-hc-21 (work in progress), 370 July 2019. 372 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 373 "Transmission of IPv6 Packets over IEEE 802.15.4 374 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 375 . 377 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 378 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 379 DOI 10.17487/RFC6282, September 2011, 380 . 382 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 383 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 384 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 385 Low-Power and Lossy Networks", RFC 6550, 386 DOI 10.17487/RFC6550, March 2012, 387 . 389 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 390 Interface Identifiers with IPv6 Stateless Address 391 Autoconfiguration (SLAAC)", RFC 7217, 392 DOI 10.17487/RFC7217, April 2014, 393 . 395 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 396 IPv6 over Low-Power Wireless Personal Area Networks 397 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 398 2014, . 400 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 401 Considerations for IPv6 Address Generation Mechanisms", 402 RFC 7721, DOI 10.17487/RFC7721, March 2016, 403 . 405 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 406 "IPv6 over Low-Power Wireless Personal Area Network 407 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 408 April 2017, . 410 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 411 (IPv6) Specification", STD 86, RFC 8200, 412 DOI 10.17487/RFC8200, July 2017, 413 . 415 [talwar] Talwar, M., "ROUTING TECHNIQUES AND PROTOCOLS FOR INTERNET 416 OF THINGS: A SURVEY", Indian J.Sci.Res. 12(1):417-423, 417 2015. 419 Appendix A. Change log [RFC Editor: Please remove] 421 draft-jiang-asymmetric-ipv6-00, 2019-06-03: 423 Initial version 425 draft-jiang-asymmetric-ipv6-01, 2019-06-21: 427 Fixed reference error 429 draft-jiang-asymmetric-ipv6-02, 2019-10-29: 431 Added illustrative example 433 Discussed fragmentation 435 Discussed relationship to SCHC 437 Fixed bit pattern errors 439 Authors' Addresses 441 Sheng Jiang 442 Huawei Technologies Co., Ltd 443 Q14, Huawei Campus, No.156 Beiqing Road 444 Hai-Dian District, Beijing, 100095 445 P.R. China 447 Email: jiangsheng@huawei.com 449 Guangpeng Li 450 Huawei Technologies 451 Q14, Huawei Campus 452 No.156 Beiqing Road 453 Hai-Dian District, Beijing 100095 454 P.R. China 456 Email: liguangpeng@huawei.com 458 Brian Carpenter 459 The University of Auckland 460 School of Computer Science 461 University of Auckland 462 PB 92019 463 Auckland 1142 464 New Zealand 466 Email: brian.e.carpenter@gmail.com