idnits 2.17.1 draft-li-6lo-native-short-address-00.txt: -(902): 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 are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (18 October 2021) is 920 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'LPWAN' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'SIXLO' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'SIXLOWPAN' is defined on line 914, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group G. Li 3 Internet-Draft D. Lou 4 Intended status: Experimental L. Iannone 5 Expires: 21 April 2022 Huawei 6 P. Liu 7 China Mobile 8 18 October 2021 10 Native Short Addressing for Low power and Lossy Networks Expansion 11 draft-li-6lo-native-short-address-00 13 Abstract 15 This document specifies mechanisms of NSA (Native Short Address) that 16 enables IP packet transmission over links where the transmission of a 17 full length address may not be desirable. This document focuses on 18 carrying IP packets across a LLN (Low power and Lossy Network), in 19 which the nodes' location is fixed and changes in the logical 20 topology are caused only by unstable radio connectivity (not physical 21 mobility). The specifications include NSA allocation, routing 22 mechanisms, header format design including length-variable fields, 23 and IPv6 interconnection support. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 21 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. NSA Allocation . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. NSA Addresses and IPv6 Addresses . . . . . . . . . . . . 9 63 4.2. Limitation of Number of Children Node . . . . . . . . . . 10 64 5. Routing for a NSA Network . . . . . . . . . . . . . . . . . . 10 65 5.1. Routing toward an NSA endpoint . . . . . . . . . . . . . 11 66 5.2. Routing toward an external IPv6 node . . . . . . . . . . 13 67 6. Benefits of Native Short Addressing . . . . . . . . . . . . . 13 68 7. NSA Header Format . . . . . . . . . . . . . . . . . . . . . . 14 69 8. NSA Control Message . . . . . . . . . . . . . . . . . . . . . 16 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 71 9.1. Dispatch Type Field . . . . . . . . . . . . . . . . . . . 17 72 9.2. Allocation Function Registry . . . . . . . . . . . . . . 17 73 9.3. ICMP NSA Control Message . . . . . . . . . . . . . . . . 18 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 11.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 There is an ongoing massive expansion of the network edge that is 83 driven by the "Internet of Things" (IoT) technology, especially over 84 low-power links which often, in the past, did not support IP packet 85 transmission. 87 Particularly driven by the requirements stemming from Industry 4.0 88 and Smart City deployments, more and more devices/things are 89 connected to the Internet. Sensors in plants/parking bays/mines, 90 temperature/humidity/flash sensors in museums, normally are located 91 in a fixed position and are networked by low power and lossy links. 92 Comparing with traditional scenarios, scalability of the (edge) 93 network along with lower power consumption are key technical 94 requirements. Moreover, large-scale Low power Lossy Networks (LLNs) 95 are expected to be able to carry IPv6 packets over their links, 96 together with an efficient access to native IPv6 domains. These kind 97 of networks, do not necessarily imply nodes mobility [RFC5673], 98 whilst some topology changes may still happen because of fluctuating 99 radio link quality. 101 The work in [SIXLOWPAN]/[SIXLO]/[LPWAN] Working Groups address many 102 fundamental issues for those type of deployments. Those deployments 103 can be considered an instantiation of what [RFC8799] defines as 104 "limited domains". For instance, the 6lowpan compression technology 105 ([RFC4944] and [RFC6282]) addresses the problem of IPv6 transmission 106 over LLNs, making it possible to interconnect IPv6-based IoT networks 107 and the Internet. [RFC8138] introduces a framework for implementing 108 multi-hop routing on an LLN using a compressed routing header, which 109 works also with RPL (Routing Protocol for LLNs [RFC6550]). This 110 technique enables the ability to forward IPv6 packets within the 111 domain without the need of decompression. In addition, SCHC (Generic 112 Framework for Static Context Header Compression and Fragmentation 113 [RFC8724]) enables even more compression by using a common static 114 context. 116 The specifications in this document leverage on previous work, namely 117 using the dispatch type field ([RFC4944], [RFC8025]) that allows to 118 accommodate the proposed address format. This means that except the 119 addresses (source and destination) the other fields of the header 120 will be compressed mostly according to LPWAN_IPHC. The proposed 121 addressing is independent of Unique Local Addresses [RFC4193], which 122 has a dependency on specific link-layer conventions [RFC6282]. It is 123 also different from stateful address allocation that requires all 124 nodes to obtain addresses from a centralized DHCP server, which leads 125 to long network startup time and consumption of extra bandwidth. 126 Compared to RPL-based routing [RFC6550], NSA avoids the extra 127 overhead of address assignment by integrating address assignment and 128 tree forming together. Furthermore, NSA provides shorter packet 129 header than unstoring-mode RPL and much smaller routing table size 130 than storing-mode RPL. 132 2. Requirements Notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. Overview 142 Native Short Address (NSA) is an efficient topology-based network 143 layer address assignment mechanism that is performed in a 144 decentralized fashion. The NSA nodes are aware of its own IPv6 145 address constructed by IPv6 prefix (by configuration) and NSA (see 146 Section 5.2). Inside the NSA domain, nodes communicate with each 147 other using only NSA addresses. It is a smaller address space 148 compared to the huge IPv6 addressing space. The NSA enables 149 stateless forwarding in most cases. When IPv6 communication occurs 150 between nodes inside the NSA domain and external IPv6 nodes, the 151 border router, which plays as well the role of "root" in the 152 addressing tree, performs network layer translation (as per 153 Section 5.2 and [RFC6282]). The architecture of NSA network is 154 showed in Figure 1. 156 /|\ Internet (IPv6) 157 | --------+-------- 158 IPv6 Domain | | 159 | | 160 | +-------+-------+ 161 ---------------------------- | Border Router | 162 | +---------------+ 163 | 164 | O 165 | 166 | O O O 167 | O O 168 | O O 169 NSA Domain | O 170 | O O O O O O 171 | O 172 | O O 173 | O 174 | O 175 | 176 | Up to several thousands of nodes 177 | 178 \|/ 179 LLN 181 Figure 1: The architecture of general NSA networks. 183 The overall design objective is centered on how to minimize the 184 packet overhead and reduce the size of routing table to save 185 communication energy in a large-scale IoT LLN network. NSA 186 eliminates compression/decompression of address and also reduces the 187 amount of information synchronization messages, so it actually 188 reduces computation complexity during packets parsing and forwarding. 189 To this end, NSA uses a context-independent address encoding 190 mechanism. It does not carry any field about address context in the 191 packet. It carries source and destination addresses by variable 192 length fields whose size can be reduced to one octet each in the best 193 case. This allows the NSA packet header to be smaller than 194 LOWPAN_IPHC's 7 octets (see Figure 2), down to 4 octets, representing 195 around 40% reduction in the header size. Considering that devices in 196 the target limited domain are strongly constrained in resources, 197 while still requiring to use a global unicast IPv6 address to 198 identify them, 7 octets is the smallest size that LOWPAN_IPHC can 199 achieve in a multi-hop environment, higher than the 2-3 octets 200 necessary in a link-local communication [RFC6282]. 202 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 203 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 204 | 0 | 1 | 0 | 1 | TF |NH |HLM| | 0 | 1 | 1 | TF |NH | HLIM | 205 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 206 |Payload Length(variable length)| |CID|SAC| SAM | M |DAC| DAM | 207 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 208 |I/O|AM | Src(var len) | | SCI | DCI | 209 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 210 | Dst (var len) | | | 211 +---+---+---+---+---+---+---+---+ + Source Address + 212 | | 213 +---+---+---+---+---+---+---+---+ 214 | | 215 + Destination Address + 216 | | 217 +---+---+---+---+---+---+---+---+ 219 b. IPHC best case header 220 a. NSA best case header with context-based encoding 221 and global unicast address 223 Figure 2: Best case of NSA and LOWPAN_IPHC packet header. 225 There are three distinct NSA features that allow NSA to be efficient, 226 namely: 228 1. Native hort address allocation (see Section 4), 230 2. Stateless routing (see Section 5), 232 3. Compact header format design (see Section 7) that avoids context 233 and compression. 235 4. NSA Allocation 237 In an NSA network, there are 3 types of roles, namely: 239 * Root, 241 * Forwarder, 243 * Leaf. 245 The basic rules of allocation include: 247 * Each node's address is prefixed by their parent's address. 249 * The forwarder runs an AF (Allocation Function) to generate its 250 children's addresses. 252 * All nodes run the same AF in the same network instance. 254 Normally, the root role is assigned to the border router when the LLN 255 bootstraps. An example of a possible result of an NSA deployment is 256 shown in Figure 3. 258 root +--------------------------+ 259 1 | append more bits to form | 260 O -- | brother's address | 261 / | \ +--------------------------+ 262 / | \ \ 263 / | \ \-\ 264 +---------+ 10 / 11| \ \ 265 |forwarder| / 110\ \ 111 266 |node | O - O O O 267 +---------+/ \ | \ 268 / | \ \ | \ 269 / | \ \ O O 270 / | \ \ 271 100/ 101 | 1010 1011 +--------------+ 272 |Prefix is '10'| 273 O O O O +--------------+ 274 /| /| 275 / | / | 276 O O O O 278 Figure 3: An example of NSA addresses allocation. 280 Each node acquiring a native short address needs to send an Address 281 Request (AR) message to its link layer neighbors and wait for the 282 response. In the AR message, the node needs to designate a 'role' 283 value (forwarder or leaf) and the 'nodeid'. Forwarder and Leaf roles 284 can be assigned similarly to IEEE 802.15.4, which distinguishes 285 between Full-Function Devices (FFD) and reduced function devices 286 (RFD) (cf., [ZigBee]). If a neighbor is neither a forwarder nor the 287 root, it will drop the message silently. Otherwise, the neighbor 288 should calculate an address based on parameters in the AR message. 289 After the neighbor node assigned an address for node, it stores the 290 suffix of that address as the interface ID towards the node. Then, 291 it generates and sends Address Assignment (AA) message back. Once a 292 node receives a valid AA response, it uses that assigned address as 293 its own network layer address, thus becomes a child of the address 294 assigner. It will then ignore replies from other neighbors. If a 295 node does not receive any response after an pre-defined interval, it 296 will send the AR message again. It is RECOMMENDED that nodes re-send 297 the AR message up to 3 times, if no answer is received they SHOULD 298 stop. 300 The allocation function AF(role,i) used in this document is defined 301 in Figure 4. Where every forwarder node should store and maintain 302 two indexes, one for the children that are forwarders and one for the 303 children that are leaves (starting at 0 for the first child in each 304 role). Let's call the first index 'f', as of forwarder, and the 305 second 'l' as for leaves. The '+' symbol indicates a concatenation 306 operation; the b() operation indicates the binary string conversion 307 operation with leading zeros trimmed (note that in this case b(0) is 308 an empty string). 310 AF(role, f, l) = 'address of the node performing the function' 311 + (role == leaf? b(l++):b(f++)) 312 + (role == leaf?'1':'0'), 313 in which, f and l are the indexes of respectively the forwarders 314 and the leaves at this layer (starting at 0). 316 Figure 4: Definition of the Allocation Function (AF) of 317 forwarder/root nodes. 319 Taking the example of the topology in Figure 3, the proposed AF works 320 as follows. 322 At the top level, there are 4 children of root, two are forwarders 323 and the other two are leaves. Starting from the left most node and 324 moving to the right, the root node applies the AF as follows: 326 * For the first child, which is a forwarder: 328 - A('forwarder', 0, 0) = '1'(root address) + b(0) + '0' = '1' + 329 '' + '0' = 10 331 - Index f is increased by one and is now equal 1 (f=1) 333 * For the second child, which is a leaf: 335 - A('leaf', 1, 0) = '1'(root address) + b(0) + '1' = '1' + '' + 336 '1' = 11 338 - Index l is increased by one and is now equal 1 (l=1) 340 * For the third child, which is a forwarder: 342 - A('forwarder', 1, 1) = '1'(root address) + b(1) + '0' = '1' + 343 '1' + '0' = 110 345 - Index f is increased by one and is now equal 2 (f=2) 347 * For the forth child, which is a leaf: 349 - A('leaf', 2, 1) = '1'(root address) + b(1) + '1' = '1' + '1' + 350 '1' = 111 352 - Index l is increased by one and is now equal 2 (l=2) 354 The first level addresses have now been assigned. Let's now have a 355 look how the node 10 (the first forwarder child of the root) applies 356 the same Allocation function. Note that node 10 will use its own 'f' 357 and 'l' indexes initialized to 0. Strarting again from the left most 358 node, node 10 applies the AF as follows: 360 * For the first child, which is a forwarder: 362 - A('forwarder', 0, 0) = '10'(node address) + b(0) + '0' = '10' + 363 '' + '0' = 100 365 - Index f is increased by one and is now equal 1 (f=1) 367 * For the second child, which is a leaf: 369 - A('leaf', 1, 0) = '10'(node address) + b(0) + '1' = '10' + '' + 370 '1' = 101 372 - Index l is increased by one and is now equal 1 (l=1) 374 * For the third child, which is a forwarder: 376 - A('forwarder', 1, 1) = '10'(node address) + b(1) + '0' = '10' + 377 '1' + '0' = 1010 379 - Index f is increased by one and is now equal 2 (f=2) 381 * For the forth child, which is a leaf: 383 - A('leaf', 2, 1) = '10'(root address) + b(1) + '1' = '10' + '1' 384 + '1' = 1011 386 - Index l is increased by one and is now equal 2 (l=2) 388 Note how the children of the same parent all have the same prefix (10 389 in this example). 391 The Allocation Function can be different from the one defined in 392 Figure 4, but all nodes know which one to use by configuration. The 393 use of one and only one AF is allowed in an NSA domain. It is 394 RECOMMENDED that implementations support at least the AF proposed in 395 this document (cf. Section 9). 397 4.1. NSA Addresses and IPv6 Addresses 399 Obtaining a full IPv6 address from a NSA address is pretty 400 straightforward. First the NSA address is concatenated to the 401 configured IPv6 prefix. Since the length of the NSA address is very 402 likely smaller than 64 bits (the interface ID length in IPv6), the 403 node needs to pad it with zeros ('0') used as most significative 404 bits. The full IPv6 address will look like: IPv6 prefix + 405 "000...000" + NSA (or in IPv6 notation ::). The 406 NSA is assigned by the root/forwarder as previously described. 408 In an IPv6 communication, the node will derive the NSA address as the 409 short source address from its own IPv6 address by simply removing the 410 IPv6 prefix and all leading zeros before the NSA part. The node will 411 compare the destination IPv6 address with its own IPv6 address. If 412 they have the same prefix, it means that the destination is in the 413 local NSA domain and its corresponding NSA address will be extracted 414 as the short destination address (and the I/O Flag can be set 415 accordingly). Otherwise, it will be a communication towards the 416 Internet. In that case, a mapping mechanism implemented on the root 417 node will generate a short address to be mapped to the full IPv6 418 destination address. As previously stated, the mapping mechanism is 419 out of the scope of this document. 421 Since the short mapped address is generated on the root, when the 422 node first open the connection toward the external site, with a first 423 packet, the destination address is set to the full, uncompressed, 424 IPv6 address. Once the packet arrives to the root node, performing 425 the destination address lookup the root will notice that a full IPv6 426 address is being used and will trigger the short address generation 427 mechanism and create a new mapping. Such, mapping is communicated to 428 the source node via a new dedicated ICMP message (see Section 8). 429 Once the node originating the communication receives such a message 430 it MUST use the mapped short address for any further communication. 432 4.2. Limitation of Number of Children Node 434 The maximum number of child nodes is determined by the specific AF 435 used. IEEE 802.15.5 has explored the use of a per-branch setup, 436 which, however, incurs scalability problems [LEE10]. NSA allocation 437 design is more flexible and extensible than the one proposed in IEEE 438 802.15.5. The AF used as example in this document does not need any 439 specific setup network by network, though it is still limited by the 440 maximum length of addresses. For the special case of the parent 441 connecting to huge amount of children, a variant of the proposed AF 442 can be designed to fulfill the requirement. 444 5. Routing for a NSA Network 446 Internal and external communication in an NSA network works slightly 447 different. For internal communications, among NSA endpoints, packets 448 carry native short addresses and no special operation is needed. For 449 external communications, the root is responsible to perform the 450 translation between native short addresses and IPv6 addresses. For 451 instance, for a packet entering into the NSA domain, the root will 452 extract the native short address of the destination from the suffix 453 of the IPv6 address, by removing all leading '0's. It will also map 454 the source IPv6 address to a mapped native short address, in order to 455 make it more efficient for communication inside the NSA domain. 457 The root has to store the mapping between external IPv6 addresses and 458 their assigned mapped Native Short Addresses. The method of 459 generating those mapping is out of scope of this document, however, 460 the addressing space for the external NSA has to be maintained 461 separate from the internal NSA address space. Overlap are allowed 462 since the two addressing space are distiguishable in the packets by 463 the use of the I/O field, as explained later on. 465 The following paragraphs will detail the routing operations for both 466 internal and external communication. The intra-network routing 467 procedure depends on the specific AF used. Here we will use the AF 468 previously introduced (see Figure 4) to illustrate the routing 469 procedure. 471 5.1. Routing toward an NSA endpoint 473 To perform forwarding operations, NSA nodes access the I/O field in 474 the NSA header (see Section 7). When its value is 1, the packet is 475 destined to a internal NSA node, so it is an inner-domain packet. 476 Otherwise, the packet is destined to an external IPv6 node, so it is 477 called an outer-domain packet. Intra-domain packets carry a native 478 short addresses in the source and the destination address fields. 479 More specifically the destination address field is the address of 480 another node in the same NSA domain. As such an NSA node performs 481 the following sequence of actions, also see Figure 5: 483 1. Get destination address from packet (abbreviated to DA) and the 484 current node's address (abbreviated to CA). Go to step 2. 486 2. If length of DA is smaller than length of CA, send the packet to 487 parent node, exit. Otherwise, go to step 3. 489 3. If length of DA equals to length of CA, go to step 4. Otherwise, 490 go to step 5. 492 4. If DA and CA are the same, the packet arrived at destination, 493 exit. Otherwise, send the packet to parent node, exit. 495 5. Check whether CA is equal to the prefix of DA. If yes, go to 496 step 6. Otherwise, send the packet to parent node, exit. 498 6. Calculate which child is the next hop address and forward packet 499 to it. With the AF propose in this document such operation 500 reduces to reading the DA's bits starting from the position 501 equals to the length of CA, then skip all '1' until the first '0' 502 or the last bit of DA. The sub-string obtained in such a way is 503 the address of direct child of current node. 505 7. If any exception happens in the above steps, drop the packet and 506 send error notification. 508 /*\ DA:Destination Address 509 |***| CA:Current Node's Address 510 \*/ 511 | 512 +--------+--------+ 513 |Parse DA from pkt| 514 +--------+--------+ 515 | 516 \|/ 517 +-------+------+ 518 / \ yes 519 | Len(DA)| CA == DA ? |--->+ 527 \ / \ / | 528 +-------+------+ +-------+------+ | 529 | no | yes | 530 \|/ /*\ | 531 +-------+------+ |***| | 532 / \ no \*/ | 533 | CA==PrefixOf(DA)?|------------------------------>+ 534 \ / | 535 +-------+------+ | 536 | yes | 537 \|/ \|/ 538 +---------+---------+ +---------+---------+ 539 | Calculate next-hop| | Forward to Parent | 540 | & | +---------+---------+ 541 | Forward | | 542 +---------+---------+ | 543 |<---------------------------------------+ 544 \|/ 545 /*\ 546 |***| 547 \*/ 549 Figure 5: Flow Chart of Internal Routing Procedure 551 In the case of packet arriving from the Internet (external IPv6 552 domain toward the local NSA domain) header adaptation operation is 553 performed by the root node. Concerning the destination address, the 554 root builds the native short address of the destination by removing 555 the prefix and the leading '0's of the suffix of the destination 556 address. Meanwhile, it checks whether it exists already a mapping 557 between the source address and a mapped NSA address to be used as 558 source address in the NSA packet. If not it creates one. Then the 559 root creates the inner-domain packet. It uses the NSA address as 560 destination setting the I/O field to 1 so to route the packet to as 561 described above to the destination node. The mapped NSA address is 562 used as source address and the fact that is a Mapped Address is 563 signaled by setting to 1 the MA field. 565 5.2. Routing toward an external IPv6 node 567 In the case that the I/O field (cf. Section 7) is set to 0, the 568 packet is destined to an external IPv6 node, it is an outer-domain 569 packet. As such the destination address is either a full IPv6 570 address (for the first packet of a communication) or a mapped short 571 address generated by the root node and not belonging to any node 572 inside the NSA domain. 574 All NSA nodes (except root) just send packets that are destined 575 outside the local domain (I/O field equal 0) to their parent, not 576 even looking at the actual destination address. Eventually all 577 packets will reach the root node, which acts as gateway. The Root 578 node is able to map the destination NSA address to the corresponding 579 full IPv6 address. Also, the root node is able to rebuild the full 580 source IPv6 address by concatenating the IPv6 prefix and the NSA 581 address as explained in Section 5.2. Other fields of the header are 582 also decompressed as described in Section 7. A full IPv6 header 583 replaces the original NSA header in the packet, which is then 584 forwarded according to traditional IPv6 protocol. 586 6. Benefits of Native Short Addressing 588 The NSA use a single set of messages for address assignment and tree 589 forming. It is not more complex than RPL tree forming. So, NSA 590 saves the overhead of address assignment of RPL. 592 Comparing to RPL with storing mode (see [RFC6550]), there is no need 593 for a NSA node to generate and store routing table entries in the 594 normal case. One of the potential issues is the risk of renumbering 595 of addresses when the topology changes. The topology change could 596 happen in two different scenarios, the high mobility scenario where 597 nodes are moving quite often or even all the time (e.g. UAV) and the 598 unstable link connection scenario where the locations of nodes are 599 fixed, but the connections are broken from time to time. The later 600 is usually called "logic topology change", which covers most of IoT 601 scenarios, see [IoTSurvey]. 603 A "moving" node may possibly be the root of a whole sub-tree, with 604 many children and grand-children, hence, renumbering would introduce 605 a non-negligible cost. Instead of "renumbering", the sub-tree rooted 606 on the "moving" node, its address and the addresses of all its 607 children and grand-children will be kept unchanged. A specific entry 608 in the routing tables of the original and new parent nodes will be 609 created, in order to make the sub-tree still reachable. 611 Herewith one example, also depicted in Figure Figure 6, node A with 612 the address of 1000 somehow moves from node B (original parent) to 613 node C (new parent). In this case, the routing tables in B, C and 614 their parents' nodes should be updated by adding a new route to 615 "1000", the address of node A. Meanwhile, the original parent (node 616 B) should keep its original address assignment. Comparing with 617 renumbering the addresses of node A and its children, the cost of 618 adding one new route to their parent nodes is much lower, although in 619 this case, the NSA does not implement complete stateless routing. 621 +-------------------+ 622 | Add route: | 623 | to 1000, via 1010 | 1 624 +-------------------+ O 625 * / 626 +-----------------+ * / 627 | Add route: | * / 628 | to 1000, via 10 | O 10 629 +-----------------+ / \ 630 * / \ 631 * / \ 1010 (node C) 632 (node B) 100 O O 633 . / * 634 . / *-----------------+ 635 . / | Add route: | 636 O / | to 1000, direct | 637 1000 (node A) +-----------------+ 639 Figure 6: Add extra routes for "logic topology change 641 7. NSA Header Format 643 As explained in Section 4, the addresses in NSA are of variable 644 length, in this section, we outline the design of the header format 645 partially based on the format of 6lowpan, accommodating the variable 646 length property in the packet. The header format is shown in 647 Figure 7. 649 0 1 650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 651 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 652 | 0 | 1 | 0 | 1 | TF |NH |HL | Payload Length(Variable Len) | 653 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 654 |I/O|MA | SA(Variable Len) | DA(Variable Len) | 655 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 656 | In-line fields ... | 657 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 659 Figure 7: Header format of NSA packets 661 The first 4 bits are new dispatch types that will be introduced in 662 Section 9. 664 * TF: The same definition as in [RFC6282] Section 3.1.1. 666 * NH: The same definition as in [RFC6282] Section 3.1.1. 668 * HL: This field indicates the hop limit. When HL is 0, a hop limit 669 field defined in [RFC2460] locates in in-line fields, while HL is 670 1 means no hop limit header in packet. 672 * Payload length is a variable length field. It normally occupies 673 an octet assuming most packets are smaller than 252 bytes. For 674 larger packets, payload length may expand to 2 to 3 octets. The 675 encoding method is defined as follows. When the first octet has 676 value of: 678 - 0~252: Indicates how many octets the payload consist of. 680 - 253: Indicates that there is an extra octet for payload length, 681 with the actual length value equal to the last byte value plus 682 252. 684 - 254: Indicates that there is an extra two octets for payload 685 length, with the actual length value equal to the value of the 686 second byte multiple 256 plus value of the last byte plus 252. 688 - 255: Reserved. 690 * I/O: Indicates whether this packet is destined to a inner-domain 691 node (value '1') or an outer-domain node (value '0'), where the 692 former means from an NSA or IPv6 node to a NSA destination, while 693 the latter means to an external IPv6 node. 695 * MA: Indicates the source address is actually a Mapped Address 696 generated by the root. When it is '1', the source address of the 697 packet is a mapped address of an external IPv6 address, while if 698 it is '0', the source address of the packet is an NSA address. 700 For length variable native short address encoding, for both Source 701 Address (SA) and Destination Address (DA), the definition is: 703 * 0~252: if the address value locates in this interval, one octet is 704 used to encode the value 706 * 253: indicates that the address is encoded in 2 octets. 708 * 254: indicates that the following 4 octets encode the address. 710 * 255: indicates that the following octet defines the length of 711 address in octets, followed by the address value octets. 713 The sequence of in-line fields is as per [RFC8200] section 3. 715 8. NSA Control Message 717 This documents specifies only one NSA Control Message, namely the NSA 718 Mapped Address Advertisement described in Section 4. The purpose of 719 such a message is advertise the mapping of an IPv6 address into a NSA 720 address. The map is performed by the root node and sent to the node 721 originating the communication. The root keeps a copy of the mapping 722 to be used for future packets. The format is as follows: 724 0 1 2 3 725 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Code = 0x00 | Reserved | NSA Length | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | | 730 | Target IPv6 Address (Fixed length 128 bist) | 731 | | 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Target NSA Address (Variable length) .... | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 * Type: Type value identifying NSA Control Message. Value to be 738 assigned by IANA (cf. Section 9) 740 * Code: This field identifies the specific control message. In this 741 case it is set to the value 0x00 "NSA Mapped Address for External 742 IPv6 Address". 744 * Reserved: Set as 0 on transmission and ignore on reception. 746 * NSA Length: This field indicates the length of the Target NSA 747 Address at the end of the message, expressed in octets. 749 The "NSA Mapped Address for External IPv6 Address" is a variable 750 length message, however, the first five fields of the message, namely 751 Type, Codem Reserved, NSA Length, and Target IPv6 address, have a 752 fixed length of 160 bits (20 octets), hence the length of the NSA 753 address is sufficient to calculate the length of the entire packet: 754 20 octets + "NSA length". 756 9. IANA Considerations 758 9.1. Dispatch Type Field 760 This document requires IANA to assign the range 01010000 to 01011111 761 in page 10 of the "Dispatch Type Field" registry as follows: 763 +-------------+----+-----------------------------+---------------+ 764 | Bit Pattern |Page| Header Type | Reference | 765 +-------------+----+-----------------------------+---------------+ 766 | 0101TTNH | 10 | LOWPAN NSA IP(LOWPAN_NIP) |[This Document]| 767 +-------------+----+-----------------------------+---------------+ 769 Figure 8: LOWPAN Dispatch Type Field requested allocation 771 9.2. Allocation Function Registry 773 This section provides guidance to the Internet Assigned Numbers 774 Authority (IANA) regarding registration of values related to the NSA 775 specification, in accordance with BCP 26 [RFC8126]. 777 IANA is asked to create a registry named "Native Short Addresses 778 (NSA) Parameters". 780 Such registry should be populated with a one octet sub registry named 781 "Allocation Function" and used to identify the AF used in a NSA 782 deployment. The sub registry is populated as follows: 784 +---------+----------------------------+-----------------+ 785 | Value | AF Name | Reference | 786 +---------+----------------------------+-----------------+ 787 | 0x00 | Native Allocation Function | [This Document] | 788 +---------+----------------------------+-----------------+ 789 |0x01-0xFF| Un-assigned | | 790 +---------+----------------------------+-----------------+ 792 Values can be assigned by IANA on a "First Come, First Served" basis 793 according to [RFC8126]. 795 9.3. ICMP NSA Control Message 797 IANA is requested to allocate an ICMPv6 type value from the "ICMPv6 798 Parameters" registry to be used by "NSA Control Message". 800 Also IANA is requested to create an "NSA Control Codes" sub registry, 801 for the Code field of the ICMPv6 NSA Control Message. 803 New codes may be allocated through the "Specification Required" 804 procedure as defined in [RFC8126]. The following code is currently 805 defined (the others are to be marked as un-assigned): 807 +------+--------------------------------------------+---------------+ 808 | Code | Description | Reference | 809 +------+--------------------------------------------+---------------+ 810 | 0x00 |NSA Mapped Address for External IPv6 Address|[This Document]| 811 +------+--------------------------------------------+---------------+ 813 10. Security Considerations 815 An extended security analysis will be provided in future revision of 816 this document. As of this point we consider that the security 817 considerations of [RFC4944], [RFC6282] apply. 819 11. References 821 11.1. Normative References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, 825 DOI 10.17487/RFC2119, March 1997, 826 . 828 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 829 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 830 December 1998, . 832 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 833 "Transmission of IPv6 Packets over IEEE 802.15.4 834 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 835 . 837 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 838 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 839 DOI 10.17487/RFC6282, September 2011, 840 . 842 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 843 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 844 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 845 Low-Power and Lossy Networks", RFC 6550, 846 DOI 10.17487/RFC6550, March 2012, 847 . 849 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 850 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 851 RFC 8025, DOI 10.17487/RFC8025, November 2016, 852 . 854 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 855 Writing an IANA Considerations Section in RFCs", BCP 26, 856 RFC 8126, DOI 10.17487/RFC8126, June 2017, 857 . 859 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 860 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 861 May 2017, . 863 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 864 (IPv6) Specification", STD 86, RFC 8200, 865 DOI 10.17487/RFC8200, July 2017, 866 . 868 11.2. Informative References 870 [IoTSurvey] 871 Oliveira, A. and T. Vazão, "Low-power and lossy networks 872 under mobility: A survey", Computer Networks Vol. 107, pp. 873 339-352, DOI 10.1016/j.comnet.2016.03.018, October 2016, 874 . 876 [LEE10] Lee, M., Zhang, R., Zheng, J., Ahn, G., Zhu, C., Park, T., 877 Cho, S., Shin, C., and J. Ryu, "IEEE 802.15.5 WPAN mesh 878 standard-low rate part: Meshing the wireless sensor 879 networks", IEEE Journal on Selected Areas in 880 Communications Vol. 28, pp. 973-983, 881 DOI 10.1109/jsac.2010.100902, September 2010, 882 . 884 [LPWAN] "IPv6 over Low Power Wide-Area Networks (lpwan) WG", n.d., 885 . 887 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 888 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 889 . 891 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 892 Phinney, "Industrial Routing Requirements in Low-Power and 893 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 894 2009, . 896 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 897 "IPv6 over Low-Power Wireless Personal Area Network 898 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 899 April 2017, . 901 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 902 Zúñiga, "SCHC: Generic Framework for Static Context Header 903 Compression and Fragmentation", RFC 8724, 904 DOI 10.17487/RFC8724, April 2020, 905 . 907 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 908 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 909 . 911 [SIXLO] "IPv6 over Networks of Resource-constrained Nodes (6lo) 912 WG", n.d., . 914 [SIXLOWPAN] 915 "IPv6 over Low power WPAN (6lowpan) - Concluded WG", n.d., 916 . 918 [ZigBee] "ZigBee Wireless Networks and Transceivers", 919 Elsevier book, DOI 10.1016/b978-0-7506-8393-7.x0001-5, 920 2008, 921 . 923 Authors' Addresses 925 Guangpeng Li 926 Huawei Technologies 927 Beiqing Road, Haidian District 928 Beijing 929 100095 930 China 931 Email: liguangpeng@huawei.com 933 David Lou 934 Huawei Technologies Duesseldorf GmbH 935 Riesstrasse 25 936 80992 Munich 937 Germany 939 Email: zhe.lou@huawei.com 941 Luigi Iannone 942 Huawei Technologies France S.A.S.U. 943 18, Quai du Point du Jour 944 92100 Boulogne-Billancourt 945 France 947 Email: luigi.iannone@huawei.com 949 Peng Liu 950 China Mobile 951 No. 53, Xibianmen Inner Street, Xicheng District 952 Beijing 953 100053 954 China 956 Email: liupengyjy@chinamobile.com