idnits 2.17.00 (12 Aug 2021) /tmp/idnits60567/draft-li-native-short-addresses-01.txt: -(422): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (25 May 2021) is 354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Informational S. Jiang 5 Expires: 26 November 2021 Huawei Technologies Co., Ltd 6 D. Eastlake 3rd 7 Futurewei 8 25 May 2021 10 Native Short Addresses for the Internet Edge 11 draft-li-native-short-addresses-01 13 Abstract 15 This document describes a new approach to IP header compression 16 including native short addresses adoption for use in scenarios where 17 minimizing packet size is crucial but routing performance must be 18 maximised. 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 https://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 26 November 2021. 37 Copyright Notice 39 Copyright (c) 2021 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Address Transformation at the Gateway . . . . . . . . . . . . 6 56 4. Routing without Decompression . . . . . . . . . . . . . . . . 7 57 5. Address Configuration . . . . . . . . . . . . . . . . . . . . 7 58 6. Compatibility with Existing Protocols . . . . . . . . . . . . 8 59 7. Relationship to Static Context Header Compression . . . . . . 8 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 The large address space of IPv6 is essential for the massive 71 expansion of the network edge that will be caused by "Internet of 72 Things" (IoT) technology over low-power or 5G links. However, the 73 size of a raw IPv6 packet header causes difficulty due to the small 74 maximum transmission units (MTU) allowed by typical low-power, low- 75 cost link layers. For 5G, the importance of header overhead in small 76 packets is discussed in [NGMN-5G]. Thus header compression, 77 including address compression, is an important issue. This decreases 78 the size of raw packets, but compressed IP addresses are not 79 routeable except by decompressing them completely in every forwarding 80 node. There are two issues here. The first is the extra computation 81 resource needed for compressing or decompressing in constrained IoT 82 nodes. The second is that full-length IPv6 routing will consume more 83 memory to store routing tables and packet queues (assuming that 84 routing is not bypassed by tunnelling). Such resource consumption is 85 very undesirable in constrained nodes with limited storage, CPU 86 power, and battery capacity. 88 To mitigate these issues, here we propose a solution enabling the 89 shortening of IPv6 addresses inside packets, and the routing of 90 packets according to short addresses, without needing the overhead of 91 a decompression step prior to route lookup. Considering that the 92 scale and size of edge networks may vary widely, different lengths of 93 short address can be used in different domains. 95 As an illustrative example, consider an edge network which is known 96 to never require more than a few hundred nodes, which in most cases 97 will communicate either with each other, or with application layer 98 gateways to the rest of the Internet. Rather than needing 128-bit 99 addresses, such a network could very well operate with 16-bit 100 addresses. Also, it could very likely operate without needing 101 enhancements such as differentiated services, ECN or flow labels. If 102 only IPv6 is supported, the version number field is pointless. There 103 is no reason for IPv6 packets within such a network to contain 104 40-byte headers as specified in [RFC8200]. Therefore, the useful 105 information could be carried in 8 bytes (see Figure 1). Furthermore, 106 routers within the edge network can route packets directly on 16-bit 107 addresses, reducing RIB and FIB sizes and the lookup time. 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Payload Length | Next Header | Hop Limit | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Source Address | Destination Address | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Figure 1 117 This work is distinct from previous work on address compression 118 [RFC6282] [RFC7400]. Although those solutions tackle the problem of 119 small MTU size, they do not address the problem of decompression 120 overhead. 122 This work is also distinct from the work on static context header 123 compression [RFC8724], as discussed in more detail below. 125 Finally, this work is distinct from the 6LoWPAN Routing Header 126 [RFC8138], which can support truncated addresses in a different way. 128 2. Proposed Solution 130 The use of IPv6 naturally implies 128-bit addresses for both source 131 and destination. However, this address size is huge by the standards 132 of IoT edge networks. We propose the use of a context parameter to 133 indicate the effective length of the IP address for every node in a 134 local domain. If the effective length is N bits, then all addresses 135 in the domain are assumed to be preceded by a common prefix of 128-N 136 bits, when a full size IPv6 address is needed. Any node in the 137 domain that needs the full address, such as a gateway node to the 138 Internet, can therefore easily synthesize it. If a client 139 communicates with a server that is in the local domain, short 140 addresses will be used end-to-end. 142 The address length parameter may be needed by every node in the 143 domain. It can be spread by various techniques: 145 * Configure the address length in every node. 147 * Obtain the address length from a gateway (next hop router) node. 149 * Negotiate the address length between neighbors. 151 The solution operates by shortening IP address fields to save 152 overhead. To enhance this, we propose a new field named Flexible 153 Header Encoding (FHE). It consists of 8 bits, each indicating 154 whether the corresponding IPv6 header field [RFC8200] exists. 156 * Bit 0 indicates the Modified Version field 158 * Bit 1 indicates the Traffic Class field 160 * Bit 2 indicates the Flow Label field. 162 * Bit 3 indicates the Payload Length field. 164 * Bit 4 indicates the Next Header field. (Zero implies "No Next 165 Header", value 59) 167 * Bit 5 indicates the Hop Limit field. 169 * Bit 6 indicates the Source Address field. 171 * Bit 7 indicates the Destination Address field. 173 The "Version" field is a special case. In the context of FHE, all 174 packets are presumed to be IPv6 so the normal version field has no 175 purpose. The Modified Version field, if present, has the following 176 encoded meanings: 178 * 0b0000: The source address (if it exists) has pre-determined 179 length inside the domain and the destination address (if it 180 exists) uses standard 128-bit IPv6 address. (Outward traffic) 182 * 0b0001: The source address (if it exists) uses standard 128-bit 183 IPv6 address and the destination address (if it exists) has pre- 184 determined length inside the domain. (Inward traffic) 186 * 0b0010: The source address and destination address have the same 187 length inside the domain. The address length will be pre- 188 determined. 190 * 0b0110: Reserved for IPv6 compatible case. 192 * 0b0100: Reserved for IPv4 compatible case. 194 * 0b0011~0b1111(except 0b0110, 0b0100): Reserved. 196 All fields, including the Modified Version field, follow the FHE in 197 the same order as in [RFC8200], with no padding. There are no 198 alignment requirements, but when a packet is decompressed to a normal 199 IPv6 format, padding options as defined in RFC8200 must be inserted. 201 Compared to the illustrative example in Figure 1, the actual packet 202 size would therefore be 10 bytes, a considerable improvement on the 203 standard 40 bytes. This method of shortening packets by using the 204 FHE header is called Asymmetric IPv6. 206 One implication of the above is that the source and destination 207 addresses may be elided completely if they are implicit. Sourceless 208 packets were originally suggested in [Crowcroft]. 210 Figure 2 illustrates an example of the FHE format. In this example 211 the traffic class, flow label and source address are elided, and the 212 destination address is truncated to 16 bits. The modified version 213 field could be 0b0001 or 0b0010. 215 FHE octet 216 Modified +-+-+-+-+-+-+-+-+ 217 Version |1 0 0 1 1 1 0 1| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 |0 0 0 1| Payload Length | Next Header | Hop | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Limit | Truncated Destination Address | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 223 | | 224 + Transport payload | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+......... 228 Figure 2 230 Note that Asymmetric IPv6 does not contain any special handling for 231 IPv6 fragmentation, which will operate exactly as described in 232 [RFC8200], with Asymmetric IPv6 applied to each fragment packet. 233 However, we assume that in IoT deployment scenarios, packets whose 234 length exceeds the IPv6 minimum link MTU before applying Asymmetric 235 IPv6 will be rare. If the underlying link layer cannot carry 236 complete packets even after applying Asymmetric IPv6 compression, an 237 adaptation layer will be necessary exactly as for normal IPv6. 239 3. Address Transformation at the Gateway 241 Truncated intra-domain addresses will be used to identify nodes 242 inside the domain. When a packet is sent from an IoT node to an 243 external IPv6 host , the node's intra-domain address, which is unique 244 in the domain, will be carried in the source address field. When the 245 packet is forwarded outside the domain by a gateway, the intra-domain 246 address will be transformed to a complete IPv6 address. To achieve 247 this, the gateway should will maintain a globally routeable prefix 248 for all the nodes in the domain. When a packet with an intra-domain 249 source address is received, the gateway extracts this address and 250 concatenates it to the prefix to form a standard, globally unique 251 IPv6 address. Vice versa, when IPv6 packets are received from the 252 Internet, the prefix will be removed to recover the intra-domain 253 short address. 255 There are two options for handling the addresses of external hosts 256 within the domain. One is to use their full IPv6 addresses via 257 Modified Version codes 0b0000 and 0b0001. The other is effectively a 258 specialized form of Network Address Translation. Here, the gateway 259 will maintain a dynamic mapping table between synthetic intra-domain 260 addresses and IPv6 addresses. As packets are received, the gateway 261 performs the appropriate mapping. The transformation must be 262 checksum-neutral for the transport layer, so the methods designed for 263 NAT46 should be adapted [RFC6145]. 265 It is an engineering choice whether this method is preferable to 266 carrying full 128-bit addresses on the IOT side. Which type of 267 resource is more expensive should be seriously considered to choose 268 the appropriate ways, e.g. computing, memory, or transmiting in 269 various resource-constrained IoT networks. 271 4. Routing without Decompression 273 Routing mechanisms may readily be adapted to truncated address sizes. 274 If there is routing with an FHE domain, we assume that the truncated 275 address size will be split into a prefix and an interface identifier, 276 but this will not be at the traditional /64 boundary. If routing 277 between different length addresses is required, a suitably modified 278 Forwarding Information Base (FIB) structure is needed, as for any 279 variable length addressing scheme. A truncated address needs to be 280 virtually expanded to 128 bits at the router's inbound interface, 281 although this may not be the physical implementation. 283 A possible routing choice for IOT edge networks is RPL [RFC6550], 284 although a more complete survey can be found in [Talwar]. 286 5. Address Configuration 288 The simplest approach to address configuration is simply to run 289 normal IPv6 procedures (SLAAC or DHCPv6), on the argument that this 290 is a rare process and the overhead does not matter. If the truncated 291 address size is less than 64 bits, it will be necessary to use 292 shorter interface identifiers than normal, but this is not a major 293 change. Once a node has acquired an IPv6 address and has learned the 294 local address length parameter as outlined in Section 2, it can 295 continue in FHE mode. 297 6. Compatibility with Existing Protocols 299 Although FHE nodes can only talk directly to each other, they are 300 essentially a special form of IPv6 node and they can communicate with 301 the whole IPv6 Internet via gateways. The complexity is not greater 302 than 6LoWPAN. If appropriate, the 6LoWPAN adaptation layer [RFC4944] 303 could be used, with a specific dispatch type. 305 7. Relationship to Static Context Header Compression 307 Static Context Header Compression (SCHC) [RFC8724] is a powerful 308 mechanism for reducing IPv6 packet size in an IoT application 309 environment. In particular it includes a profile for UDP over IPv6, 310 and a somewhat modified version of this profile could achieve much of 311 what Asymmetric IPv6 proposes. In addition, SCHC provides support 312 for fragmentation in the case of very small link MTUs. However, SCHC 313 is by design static, and once a context is established the fields to 314 be compressed do not change. Asymmetric IPv6 transmits the FHE and 315 Modified Version bytes with every packet, so it provides dynamic 316 choice as to which header elements are compressed or elided. 318 In a context where the desirable compression is fixed, e.g. every 319 address is the same length, the flow label is never used, etc., SCHC 320 can used to the same effect as Asymmetric IPv6. However, if the 321 behavior needs to be dynamic, the signaling power of the FHE and 322 Modified Version bytes in Asymmetric IPv6 is needed. 324 Further study is needed whether the advantages of the two mechanisms 325 can be combined. 327 8. Security Considerations 329 FHE is essentially only a non-cryptographic compression technique so 330 it neither adds to nor reduces the intrinsic security of an IPv6 331 packet. The address length parameter is not a secret, since all 332 nodes in the domain must know it. The mechanism for distributing 333 this parameter must be no less secure than any other configuration 334 mechanism in use. 336 Address-based privacy issues must be considered in deciding on the 337 address length. If the number of bits available for the interface 338 identifier is significantly less than the 64 currently in use, 339 address traceability and guessability will be affected. However, if 340 the traffic with short addresses is confined to within the edge 341 network, the privacy issue will be minimized. [RFC7721] and 342 [RFC7217] should be consulted prior to deciding the address length. 344 9. IANA Considerations 346 This document makes no request of the IANA. 348 NOTE IN DRAFT: If the solution of a 6LoWPAN dispatch type is adopted, 349 a suitable assignment request will be added. 351 10. Contributors 353 Brian Carpenter as one of the authors of draft-jiang-asymmetric-ipv6 354 directly contributes to the former draft's all sections, especially 355 for polishing of introduction and solution's description. As his 356 will, this draft absorbs most of the results and will go further 357 regarding him as the most important contributor. 359 11. Acknowledgements 361 Useful comments were received from Uma Chunduri, Cheng Li, Pascal 362 Thubert, Laurent Toutain and others. 364 12. References 366 [Crowcroft] 367 Crowcroft, J. and M. Bagnulo, "SNA: Sourceless Network 368 Architecture", University of Cambridge Computer Laboratory 369 Technical Report UCAM-CL-TR-849, 2014. 371 [NGMN-5G] Thibault, I., "5G Extreme Requirements: Operators' views 372 on fundamental trade-offs", NGMN Alliance , 2017. 374 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 375 "Transmission of IPv6 Packets over IEEE 802.15.4 376 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 377 . 379 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 380 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 381 . 383 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 384 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 385 DOI 10.17487/RFC6282, September 2011, 386 . 388 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 389 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 390 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 391 Low-Power and Lossy Networks", RFC 6550, 392 DOI 10.17487/RFC6550, March 2012, 393 . 395 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 396 Interface Identifiers with IPv6 Stateless Address 397 Autoconfiguration (SLAAC)", RFC 7217, 398 DOI 10.17487/RFC7217, April 2014, 399 . 401 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 402 IPv6 over Low-Power Wireless Personal Area Networks 403 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 404 2014, . 406 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 407 Considerations for IPv6 Address Generation Mechanisms", 408 RFC 7721, DOI 10.17487/RFC7721, March 2016, 409 . 411 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 412 "IPv6 over Low-Power Wireless Personal Area Network 413 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 414 April 2017, . 416 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 417 (IPv6) Specification", STD 86, RFC 8200, 418 DOI 10.17487/RFC8200, July 2017, 419 . 421 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 422 Zúñiga, "SCHC: Generic Framework for Static Context Header 423 Compression and Fragmentation", RFC 8724, 424 DOI 10.17487/RFC8724, April 2020, 425 . 427 [Talwar] Talwar, M., "Routing Techniques and Protocols for Internet 428 of Things: a Survey", Indian J.Sci.Res. 12(1):417-423, 429 2015. 431 Appendix A. Change log [RFC Editor: Please remove] 433 * draft-jiang-asymmetric-ipv6-00, 2019-06-03: 435 - Initial version 437 * draft-jiang-asymmetric-ipv6-01, 2019-06-21: 439 - Fixed reference error 441 * draft-jiang-asymmetric-ipv6-02, 2019-10-29: 443 - Added illustrative example 445 - Discussed fragmentation 447 - Discussed relationship to SCHC 449 - Fixed bit pattern errors 451 * draft-jiang-asymmetric-ipv6-03, 2020-05-15: 453 - Minor technical and editorial fixes 455 - Converted to xml2rfc v3 457 * draft-jiang-asymmetric-ipv6-04, 2020-11-15: 459 - Explicitly limit the scope to resource-constrained domain 461 - Add engineering choice considerations accordingly 463 * draft-li-native-short-addresses-00, 2021-02-20: 465 - Change title to emphase the actual case of asymmetric IPv6 467 - Add new author and move one author to contributors section 469 * draft-li-native-short-addresses-00, 2021-05-25: 471 - Solve display issue 473 - Remove obslete field 475 Authors' Addresses 477 Guangpeng Li 478 Huawei Technologies 479 Q14, Huawei Campus 480 No.156 Beiqing Road 481 Hai-Dian District, Beijing 482 100095 483 P.R. China 485 Email: liguangpeng@huawei.com 486 Sheng Jiang 487 Huawei Technologies Co., Ltd 488 Q14, Huawei Campus, No.156 Beiqing Road 489 Hai-Dian District, Beijing, 100095 490 P.R. China 492 Email: jiangsheng@huawei.com 494 Donald Eastlake 3rd 495 Futurewei Technologies 496 2386 Panoramic Circle 497 Apopka 498 FL 32703, 32703 499 United States of America 501 Email: d3e3e3@gmail.com