idnits 2.17.1 draft-jiang-asymmetric-ipv6-01.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 (June 21, 2019) is 1770 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-01 Summary: 1 error (**), 0 flaws (~~), 2 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: December 23, 2019 Huawei Technologies 6 B. Carpenter 7 Univ. of Auckland 8 June 21, 2019 10 Asymmetric IPv6 for IoT Networks 11 draft-jiang-asymmetric-ipv6-01 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 December 23, 2019. 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 . . . . . . . . . . . . . . . . 5 57 5. Address Configuration . . . . . . . . . . . . . . . . . . . . 6 58 6. Compatibility with Existing Protocols . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 The large address space of IPv6 is essential for the massive 68 expansion of the network edge that will be caused by "Internet of 69 Things (IoT)" technology over low-power or 5G links. However, the 70 size of a raw IPv6 packet header causes difficulty due to the small 71 maximum transmission units (MTU) allowed by typical low-power, low- 72 cost link layers. For 5G, this aspect is discussed in 73 [I-D.ietf-dmm-5g-uplane-analysis]. Thus header compression, 74 including address compression, is an important issue. This decreases 75 the size of raw packets, but compressed IP addresses are not 76 routeable except by decompressing them completely in every forwarding 77 node. There are two issues here. The first is the extra computation 78 resource needed for compressing or decompressing in constrained IoT 79 nodes. The second is that full-length IPv6 routing will consume more 80 memory to store routing tables and packet queues. Such resource 81 consumption is very undesirable in constrained nodes with limited 82 storage, CPU power, and battery capacity. 84 To mitigate these issues, here we propose a solution enabling the 85 shortening of IPv6 addresses inside packets, and the routing of 86 packets according to short addresses, without needing a decompression 87 step. Considering that the scale and size of edge networks may vary 88 widely, different lengths of short address can be used in different 89 domains. 91 This work is distinct from previous 6LoWPAN work on address 92 compression [RFC6282] [RFC7400]. Although those solutions tackle the 93 problem of small MTU size, they do not address the problem of 94 decompression overhead. 96 2. Proposed Solution 98 The use of IPv6 naturally implies 128-bit addresses for both source 99 and destination. However, this address size is huge by the standards 100 of IoT edge networks. We propose the use of a context parameter to 101 indicate the effective length of the IP address for every node in a 102 local domain. If the effective length is N bits, then all addresses 103 in the domain are assumed to be preceded by a common prefix of 128-N 104 bits, when a full size IPv6 address is needed. Any node in the 105 domain that needs the full address, such as a gateway node to the 106 Internet, can therefore easily synthesize it. 108 The address length parameter may be needed by every node in the 109 domain. It can be spread by various techniques: 111 o Configure the address length in every node. 113 o Obtain the address length from a gateway (next hop router) node. 115 o Negotiate the address length between neighbors. 117 The solution operates by shortening IP address fields to save 118 overhead. To enhance this, we propose a new field named Flexible 119 Header Encoding (FHE). It consists of 8 bits, each indicating 120 whether the corresponding IPv6 header field [RFC8200] exists. 122 Bit 0 indicates the Modified Version field 124 Bit 1 indicates the Traffic Class field 126 Bit 2 indicates the Flow Label field. 128 Bit 3 indicates the Payload Length field. 130 Bit 4 indicates the Next Header field. (Zero implies "No Next 131 Header", value 59) 133 Bit 5 indicates the Hop Limit field. 135 Bit 6 indicates the Source Address field. 137 Bit 7 indicates the Destination Address field. 139 The "Version" field is a special case. In the context of FHE, all 140 packets are presumed to be IPv6 so the normal version field has no 141 purpose. The Modified Version field, if present, has the following 142 encoded meanings: 144 0b0000: The source address (if exist) has pre-determined length 145 inside the domain and the destination address (if exist) uses 146 standard 128-bit IPv6 address. (Outward traffic) 148 0b0001: The source address (if exist) uses standard 128-bit IPv6 149 address and the destination address (if exist) has pre-determined 150 length inside the domain. (Inward traffic) 152 0b0010: The source address and destination address have the same 153 length inside the domain. The address length will be pre- 154 determined. 156 0b1100: Reserved for IPv6 compatible case. 158 0b0100: Reserved for IPv4 compatible case. 160 0b0011~0b1111(except 0b1100, 0b0100): Reserved. 162 All fields, including the Modified Version field, follow the FHE in 163 the same order as in [RFC8200], with no padding. There are no 164 alignment requirements, but when a packet is decompressed to a normal 165 IPv6 format, padding options as defined in RFC8200 must be inserted. 167 One implication of the above is that the source and destination 168 addresses may be elided completely if they are implicit. Sourceless 169 packets were originally suggested in [crowcroft]. 171 Figure 1 illustrates an example of the FHE format. In this example 172 the traffic class, flow label and source address are elided, and the 173 destination address is truncated to 16 bits. The modified version 174 field could be 0b0001 or 0b0010. 176 FHE octet 177 Modified +-+-+-+-+-+-+-+-+ 178 Version |1 0 0 1 1 1 0 1| 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |0 0 0 1| Payload Length | Next Header | Hop | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Limit | Truncated Destination Address | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 184 | | 185 + Transport payload | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+......... 189 Figure 1 191 3. Address Transformation at the Gateway 193 Truncated intra-domain addresses will be used to identify nodes 194 inside the domain. When a packet is sent from an IoT node to an 195 external IPv6 host , the node's intra-domain address, which is unique 196 in the domain, will be carried in the source address field. When the 197 packet is forwarded outside the domain by a gateway, the intra-domain 198 address will be transformed to a complete IPv6 address. To achieve 199 this, the gateway should will maintain a globally routeable prefix 200 for all the nodes in the domain. When a packet with an intra-domain 201 source address is received, the gateway extracts this address and 202 concatenates it to the prefix to form a standard, globally unique 203 IPv6 address. Vice versa, when IPv6 packets are received from the 204 Internet, the prefix will be removed to recover the intra-domain 205 short address. 207 There are two options for handling the addresses of external hosts 208 within the domain. One is to use their full IPv6 addresses via 209 Modified Version codes 0b0000 and 0b0001. The other is effectively a 210 specialized form of Network Address Translation. Here, the gateway 211 will maintain a dynamic mapping table between synthetic intra-domain 212 addresses and IPv6 addresses. As packets are received, the gateway 213 performs the appropriate mapping. The transformation must be 214 checksum-neutral for the transport layer, so the methods designed for 215 NAT46 should be adapted. 217 NOTE IN DRAFT: Details and references TBD. 219 It is an engineering choice whether this method is preferable to 220 carrying full 128-bit addresses on the IOT side. 222 4. Routing without Decompression 224 Routing mechanisms may readily be adapted to truncated address sizes. 225 If there is routing with an HFE domain, we assume that the truncated 226 address size will be split into a prefix and an interface identifier, 227 but this will not be at the traditional /64 boundary. If routing 228 between different length addresses is required, a suitably modified 229 Forwarding Information Base (FIB) structure is needed, as for any 230 variable length addressing scheme. A truncated address needs to be 231 virtually expanded to 128 bits at the router's inbound interface, 232 although this may not be the physical implementation. 234 A possible routing choice for IOT edge networks is RPL [RFC6550], 235 although a more complete survey can be found in [talwar]. 237 5. Address Configuration 239 The simplest approach to address configuration is simply to run 240 normal IPv6 procedures (SLAAC or DHCPv6), on the argument that this 241 is a rare process and the overhead does not matter. If the truncated 242 address size is less than 64 bits, it will be necessary to use 243 shorter interface identifiers than normal, but this is not a major 244 change. Once a node has acquired an IPv6 address and has learned the 245 local address length parameter as outlined in Section 2, it can 246 continue in HFE mode. 248 6. Compatibility with Existing Protocols 250 Although HFE nodes can only talk directly to each other, they are 251 essentially a special form of IPv6 node and they can communicate with 252 the whole IPv6 Internet via gateways. The complexity is not greater 253 than 6LoWPAN. If appropriate, the 6LoWPAN adaptation layer [RFC4944] 254 could be used, with a specific dispatch type. 256 7. Security Considerations 258 HFE is essentially only a non-cryptographic compression technique so 259 it neither adds to nor reduces the intrinsic security of an IPv6 260 packet. The address length parameter is not a secret, since all 261 nodes in the domain must know it. The mechanism for distributing 262 this parameter must be no less secure than any other configuration 263 mechanism in us. 265 Address-based privacy issues must be considered in deciding on the 266 address length. If the number of bits available for the interface 267 identifier is significantly less than the 64 currently in use, 268 address traceability and guessability will be affected. [RFC7721] 269 and [RFC7217] should be consulted prior to deciding the address 270 length. 272 8. IANA Considerations 274 This document makes no request of the IANA. 276 NOTE IN DRAFT: If the solution of a 6LoWPAN dispatch type is adopted, 277 a suitable assignment request will be added. 279 9. References 281 [crowcroft] 282 Crowcroft, J. and M. Bagnulo, "SNA: Sourceless Network 283 Architecture", University of Cambridge Computer Laboratory 284 Technical Report UCAM-CL-TR-849, 2014. 286 [I-D.ietf-dmm-5g-uplane-analysis] 287 Homma, S., Miyasaka, T., Matsushima, S., and d. 288 daniel.voyer@bell.ca, "User Plane Protocol and 289 Architectural Analysis on 3GPP 5G System", draft-ietf-dmm- 290 5g-uplane-analysis-01 (work in progress), March 2019. 292 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 293 "Transmission of IPv6 Packets over IEEE 802.15.4 294 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 295 . 297 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 298 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 299 DOI 10.17487/RFC6282, September 2011, 300 . 302 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 303 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 304 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 305 Low-Power and Lossy Networks", RFC 6550, 306 DOI 10.17487/RFC6550, March 2012, 307 . 309 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 310 Interface Identifiers with IPv6 Stateless Address 311 Autoconfiguration (SLAAC)", RFC 7217, 312 DOI 10.17487/RFC7217, April 2014, 313 . 315 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 316 IPv6 over Low-Power Wireless Personal Area Networks 317 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 318 2014, . 320 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 321 Considerations for IPv6 Address Generation Mechanisms", 322 RFC 7721, DOI 10.17487/RFC7721, March 2016, 323 . 325 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 326 (IPv6) Specification", STD 86, RFC 8200, 327 DOI 10.17487/RFC8200, July 2017, 328 . 330 [talwar] Talwar, M., "ROUTING TECHNIQUES AND PROTOCOLS FOR INTERNET 331 OF THINGS: A SURVEY", Indian J.Sci.Res. 12(1):417-423, 332 2015. 334 Appendix A. Change log [RFC Editor: Please remove] 336 draft-jiang-asymmetric-ipv6-00, 2019-06-03: 338 Initial version 340 draft-jiang-asymmetric-ipv6-01, 2019-06-21: 342 Fixed reference error 344 Authors' Addresses 346 Sheng Jiang 347 Huawei Technologies Co., Ltd 348 Q14, Huawei Campus, No.156 Beiqing Road 349 Hai-Dian District, Beijing, 100095 350 P.R. China 352 Email: jiangsheng@huawei.com 354 Guangpeng Li 355 Huawei Technologies 356 Q14, Huawei Campus 357 No.156 Beiqing Road 358 Hai-Dian District, Beijing 100095 359 P.R. China 361 Email: liguangpeng@huawei.com 363 Brian Carpenter 364 The University of Auckland 365 School of Computer Science 366 University of Auckland 367 PB 92019 368 Auckland 1142 369 New Zealand 371 Email: brian.e.carpenter@gmail.com