idnits 2.17.1 draft-li-6lo-native-short-address-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 : ---------------------------------------------------------------------------- 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 (14 December 2021) is 862 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 935, but no explicit reference was found in the text == Unused Reference: 'SIXLO' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'SIXLOWPAN' is defined on line 960, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-16) exists of draft-ietf-6lo-use-cases-11 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: 17 June 2022 Huawei 6 P. Liu 7 R. Long 8 China Mobile 9 14 December 2021 11 Native Short Addressing for Low power and Lossy Networks Expansion 12 draft-li-6lo-native-short-address-01 14 Abstract 16 This document specifies mechanisms of NSA (Native Short Address) that 17 enables IP packet transmission over links where the transmission of a 18 full length address may not be desirable. This document focuses on 19 carrying IP packets across a LLN (Low power and Lossy Network), in 20 which the topology is relatively static where nodes' location is 21 fixed and the connection between nodes is rather stable. The changes 22 in the logical topology are only caused by non-frequent disconnection 23 in the link due to some reasons. The specifications details NSA 24 address allocation, forwarding mechanism, header format design, 25 including length-variable fields, and IPv6 interconnection support. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 17 June 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. NSA Allocation . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. NSA Addresses and IPv6 Addresses . . . . . . . . . . . . 10 65 4.2. Limitation of Number of Children Node . . . . . . . . . . 11 66 5. Forwarding in a NSA Network . . . . . . . . . . . . . . . . . 11 67 5.1. Forwarding toward an NSA endpoint . . . . . . . . . . . . 11 68 5.2. Forwarding toward an external IPv6 node . . . . . . . . . 14 69 6. Benefits of Native Short Addressing . . . . . . . . . . . . . 14 70 7. NSA Header Format . . . . . . . . . . . . . . . . . . . . . . 16 71 8. NSA Control Message . . . . . . . . . . . . . . . . . . . . . 17 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 9.1. Dispatch Type Field . . . . . . . . . . . . . . . . . . . 18 74 9.2. Allocation Function Registry . . . . . . . . . . . . . . 18 75 9.3. ICMP NSA Control Message . . . . . . . . . . . . . . . . 19 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 79 11.2. Informative References . . . . . . . . . . . . . . . . . 20 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 82 1. Introduction 84 There is an ongoing massive expansion of the network edge that is 85 driven by the "Internet of Things" (IoT) technology, especially over 86 low-power links which often, in the past, did not support IP packet 87 transmission. 89 Particularly driven by the requirements stemming from Industry 4.0 90 and Smart City deployments, more and more devices/things are 91 connected to the Internet. Sensors in plants/parking bays/mines, 92 temperature/humidity/flash sensors in museums, normally are located 93 in a fixed position and are networked by low power and lossy links 94 even in hard wired networks. Comparing with traditional scenarios, 95 scalability of the (edge) network along with lower power consumption 96 are key technical requirements. Moreover, large-scale Low power 97 Lossy Networks (LLNs) are expected to be able to carry IPv6 packets 98 over their links, together with an efficient access to native IPv6 99 domains. 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 Although aforementioned technologies are suitable in general for all 117 IoT scenarios, there could be more simplified solutions for those 118 scenarios and applications with static network topology and stable 119 network connections leveraging on wired technologies 120 [I-D.ietf-6lo-use-cases] (e.g. smart building, smart parking, etc.). 121 In those kind of deployments, topologies are planned in advance and 122 well provisioned, with sensor nodes usually fixed in specific 123 locations. This draft presents a topology based addressing mechanism 124 with shorter packet header and simpler forwarding rules for those 125 static IoT networks. 127 The specifications in this document leverage on previous work, namely 128 using the dispatch type field ([RFC4944], [RFC8025]) that allows to 129 accommodate the proposed address format. This means that except the 130 addresses (source and destination) the other fields of the header 131 will be compressed mostly according to LPWAN_IPHC. The proposed 132 addressing is independent of Unique Local Addresses [RFC4193], which 133 has a dependency on specific link-layer conventions [RFC6282]. It is 134 also different from stateful address allocation that requires all 135 nodes to obtain addresses from a centralized DHCP server, which leads 136 to long network startup time and consumption of extra bandwidth. 137 Compared to RPL-based routing [RFC6550], NSA avoids the extra 138 overhead of address assignment by integrating address assignment and 139 tree forming together. Furthermore, NSA provides shorter packet 140 header than non-storing mode RPL and much smaller routing table size 141 than storing mode RPL. 143 2. Requirements Notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. Overview 153 Native Short Address (NSA) is an efficient topology-based network 154 layer address assignment mechanism that is performed in a 155 decentralized fashion. The NSA nodes are aware of its own IPv6 156 address constructed by IPv6 prefix (by configuration) and NSA (see 157 Section 5.2). Inside the NSA domain, nodes communicate with each 158 other using only NSA addresses. It is a smaller address space 159 compared to the huge IPv6 addressing space. The NSA enables 160 stateless forwarding. When IPv6 communication occurs between nodes 161 inside the NSA domain and external IPv6 nodes, the border router, 162 which plays as well the role of "root" in the addressing tree, 163 performs network layer translation (as per Section 5.2 and 164 [RFC6282]). The architecture of NSA network is showed in Figure 1. 166 /|\ Internet (IPv6) 167 | --------+-------- 168 IPv6 Domain | | 169 | | 170 | +-------+-------+ 171 ---------------------------- | Border Router | 172 | +---------------+ 173 | 174 | O 175 | 176 | O O O 177 | O O 178 | O O 179 NSA Domain | O 180 | O O O O O O 181 | O 182 | O O 183 | O 184 | O 185 | 186 | Up to several thousands of nodes 187 | 188 \|/ 189 LLN 191 Figure 1: The architecture of general NSA networks. 193 The overall design objective is centered on how to minimize the 194 packet overhead and reduce the size (or completely avoid the usage) 195 of routing/forwarding table to save communication energy in an IoT 196 LLN network. NSA eliminates compression/decompression of the address 197 and also reduces the amount of information synchronization messages, 198 so it actually reduces computation complexity during packets parsing 199 and forwarding. To this end, NSA uses a context-independent address 200 encoding mechanism. It does not carry any field about address 201 context in the packet. It carries source and destination addresses 202 by variable length fields whose size can be reduced to one octet each 203 in the best case. This allows the NSA packet header to be smaller 204 than LOWPAN_IPHC's 7 octets (see Figure 2), down to 4 octets, 205 representing around 40% reduction in the header size. Considering 206 that devices in the target limited domain are strongly constrained in 207 resources, while still requiring to use a global unicast IPv6 address 208 to identify them, 7 octets is the smallest size that LOWPAN_IPHC can 209 achieve in a multi-hop environment, higher than the 2-3 octets 210 necessary in a link-local communication [RFC6282]. 212 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 213 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 214 | 0 | 1 | 0 | 1 | TF |NH |HLM| | 0 | 1 | 1 | TF |NH | HLIM | 215 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 216 |Payload Length(variable length)| |CID|SAC| SAM | M |DAC| DAM | 217 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 218 |I/O|AM | Src(var len) | | SCI | DCI | 219 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 220 | Dst (var len) | | | 221 +---+---+---+---+---+---+---+---+ + Source Address + 222 | | 223 +---+---+---+---+---+---+---+---+ 224 | | 225 + Destination Address + 226 | | 227 +---+---+---+---+---+---+---+---+ 229 b. IPHC best case header 230 a. NSA best case header with context-based encoding 231 and global unicast address 233 Figure 2: Best case of NSA and LOWPAN_IPHC packet header. 235 There are three distinct NSA features that allow NSA to be efficient, 236 namely: 238 1. Native Short Address allocation (see Section 4), 239 2. Stateless forwarding (see Section 5), 241 3. Compact header format design (see Section 7) that avoids context 242 and compression. 244 4. NSA Allocation 246 In an NSA network, there are 3 types of roles, namely: 248 * Root, 250 * Forwarder, 252 * Leaf. 254 The basic rules of allocation include: 256 * Each node's address is prefixed by their parent's address. 258 * The forwarder runs an AF (Allocation Function) to generate its 259 children's addresses. 261 * All nodes run the same AF in the same network instance. 263 Normally, the root role is assigned to the border router when the LLN 264 bootstraps. An example of a possible result of an NSA deployment is 265 shown in Figure 3. 267 root +--------------------------+ 268 1 | append more bits to form | 269 O ----+ | brother's address | 270 / | \ \ +--------------------------+ 271 / | \ \ 272 / | \ \ 273 +---------+ / | \ \ 274 |forwarder| 10 / 11 110\ \ 111 275 |node | O - O O O 276 +---------+/ |\ \ | \ 277 / | \ \ | \ 278 / | \ \ O O 279 / | \ \ 280 100/ 101| 1010 1011 +--------------+ 281 O O O O |Prefix is '10'| 282 /| /| +--------------+ 283 / | / | 284 O O O O 286 Figure 3: An example of NSA addresses allocation. 288 Each node acquiring a native short address needs to send an Address 289 Request (AR) message to its link layer neighbors and wait for the 290 response. In the AR message, the node needs to designate a 'role' 291 value (forwarder or leaf) and the 'nodeid'. Forwarder and Leaf roles 292 can be assigned similarly to IEEE 802.15.4, which distinguishes 293 between Full-Function Devices (FFD) and reduced function devices 294 (RFD) (cf., [ZigBee]). If a neighbor is neither a forwarder nor the 295 root, it will drop the message silently. Otherwise, the neighbor 296 should calculate an address based on parameters in the AR message. 297 After the neighbor node assigns an address to the node, using the 298 Allocation function (AF), it stores the suffix of that address as the 299 interface ID towards the node. Then, it generates and sends Address 300 Assignment (AA) message back. Once a node receives a valid AA 301 response, it uses that assigned address as its own network layer 302 address, thus becomes a child of the address assigner. It will then 303 ignore replies from other neighbors. If a node does not receive any 304 response after an pre-defined interval, it will send the AR message 305 again. It is RECOMMENDED that nodes re-send the AR message up to 3 306 times, if no answer is received they SHOULD stop. 308 The allocation function AF(role,i) used in this document is defined 309 in Figure 4. Where every forwarder node should store and maintain 310 two indexes, one for the children that are forwarders and one for the 311 children that are leaves (starting at 0 for the first child in each 312 role). Let's call the first index 'f', as of forwarder, and the 313 second 'l' as for leaves. The '+' symbol indicates a concatenation 314 operation. The b() operation indicates the binary string of '1' with 315 length equal to its argument, for instance b(3) returns '111'. 317 AF(role, f, l) = 'address of the node performing the function' 318 + (role == leaf? b(l++):b(f++)) 319 + (role == leaf?'1':'0'), 320 in which, f and l are the indexes of respectively the forwarders 321 and the leaves at this layer (starting at 0). 323 Figure 4: Definition of the Allocation Function (AF) of 324 forwarder/root nodes. 326 Taking the example of the topology in Figure 3, the proposed AF works 327 as follows. 329 At the top level, there are 4 children of root, two are forwarders 330 and the other two are leaves. Starting from the left most node and 331 moving to the right, the root node applies the AF as follows: 333 * For the first child, which is a forwarder: 335 - A('forwarder', 0, 0) = '1'(root address) + b(0) + '0' = '1' + 336 '' + '0' = 10 338 - Index f is increased by one and is now equal 1 (f=1) 340 * For the second child, which is a leaf: 342 - A('leaf', 1, 0) = '1'(root address) + b(0) + '1' = '1' + '' + 343 '1' = 11 345 - Index l is increased by one and is now equal 1 (l=1) 347 * For the third child, which is a forwarder: 349 - A('forwarder', 1, 1) = '1'(root address) + b(1) + '0' = '1' + 350 '1' + '0' = 110 352 - Index f is increased by one and is now equal 2 (f=2) 354 * For the fourth child, which is a leaf: 356 - A('leaf', 2, 1) = '1'(root address) + b(1) + '1' = '1' + '1' + 357 '1' = 111 359 - Index l is increased by one and is now equal 2 (l=2) 361 The first level addresses have now been assigned. Let's now have a 362 look how the node 10 (the first forwarder child of the root) applies 363 the same Allocation Function. Note that node 10 will use its own 'f' 364 and 'l' indexes initialized to 0. Starting again from the left most 365 node, node 10 applies the AF as follows: 367 * For the first child, which is a forwarder: 369 - A('forwarder', 0, 0) = '10'(node address) + b(0) + '0' = '10' + 370 '' + '0' = 100 372 - Index f is increased by one and is now equal 1 (f=1) 374 * For the second child, which is a leaf: 376 - A('leaf', 1, 0) = '10'(node address) + b(0) + '1' = '10' + '' + 377 '1' = 101 379 - Index l is increased by one and is now equal 1 (l=1) 381 * For the third child, which is a forwarder: 383 - A('forwarder', 1, 1) = '10'(node address) + b(1) + '0' = '10' + 384 '1' + '0' = 1010 386 - Index f is increased by one and is now equal 2 (f=2) 388 * For the fourth child, which is a leaf: 390 - A('leaf', 2, 1) = '10'(node address) + b(1) + '1' = '10' + '1' 391 + '1' = 1011 393 - Index l is increased by one and is now equal 2 (l=2) 395 Note how the children of the same parent all have the same prefix (10 396 in this example). The proposed AF algorithmically assigns addresses 397 to the different nodes without the need to know the topology in 398 advance. However, the largest address of the network will depend on 399 the actual topology. Indeed, the maximum length of an address with 400 the proposed AF grows linearly at each level of the tree with the 401 number of siblings from the same parent. Let's take again the 402 example in Figure 3 and let's assume that the children of node 10 are 403 all leaves, for the largest address we need 2 bits to encode the 404 parent node prefix (10 in this case) to which we need to add a number 405 of '1' equal to the value of the l index which is the number of 406 leaves minus one (because the first leaf has index 0), in this case 407 since there are 4 leaves, the index value is 3 and we add the '111' 408 string, hence the address length would be 6 (2 for the prefix, 3 to 409 encode the 4th leaf address, and one for the final 1 the ends all 410 leaves addresses). In a more formal way the maximum address length 411 at each level can be calculated as (where Ceiling just returns the 412 least integer greater or equal its argument): 414 Max_Length = length(Parent address) 415 length(b(max(f,l))) 416 + 1 418 Where f and l are the indexes counting respectively the forwarders 419 and the leaves at this level. 421 The Allocation Function can be different from the one defined in 422 Figure 4, but all nodes know which one to use by configuration. The 423 use of one and only one AF is allowed in an NSA domain. It is 424 RECOMMENDED that implementations support at least the AF proposed in 425 this document (cf. Section 9). 427 Different allocation function may, for example, leverage on a priori 428 knowledge of the topology in order to optimize the maximum address 429 size and make it smaller. For instance, because the order of address 430 allocation has an impact on the size, the address of children with 431 the largest sub-tree should be allocated in the first place so to 432 reduce the average address length of the whole sub-tree. Also, 433 knowing the traffic in advance, or being able to have an estimate, 434 can help to minimize the size of addresses that have a lot of 435 traffic. This kind of optimization can be an option, the 436 specification of optimizations is out of the scope of this document 437 and may be defined in new Allocation Functions to be added to the 438 "Allocation Function Registry" (see Section 9). 440 4.1. NSA Addresses and IPv6 Addresses 442 Obtaining a full IPv6 address from a NSA address is pretty 443 straightforward. First the NSA address is concatenated to the 444 configured IPv6 prefix. Since the length of the NSA address is very 445 likely smaller than 64 bits (the interface ID length in IPv6), the 446 node needs to pad it with zeros ('0') used as most significative 447 bits. The full IPv6 address will look like: IPv6 prefix + 448 "000...000" + NSA (or in IPv6 notation ::). The 449 NSA is assigned by the root/forwarder as previously described. 451 In an IPv6 communication, the node will derive the NSA address as the 452 short source address from its own IPv6 address by simply removing the 453 IPv6 prefix and all leading zeros before the NSA part. The node will 454 compare the destination IPv6 address with its own IPv6 address. If 455 they have the same prefix, it means that the destination is in the 456 local NSA domain and its corresponding NSA address will be extracted 457 as the short destination address (and the I/O Flag can be set 458 accordingly). Otherwise, it will be a communication towards the 459 Internet. In that case, a mapping mechanism implemented on the root 460 node will generate a short address to be mapped to the full IPv6 461 destination address. As previously stated, the mapping mechanism is 462 out of the scope of this document. 464 Since the short mapped address is generated on the root, when the 465 node first open the connection toward the external site, with a first 466 packet, the destination address is set to the full, uncompressed, 467 IPv6 address. Once the packet arrives to the root node, performing 468 the destination address lookup the root will notice that a full IPv6 469 address is being used and will trigger the short address generation 470 mechanism and create a new mapping. Such, mapping is communicated to 471 the source node via a new dedicated ICMP message (see Section 8). 472 Once the node originating the communication receives such a message 473 it MUST use the mapped short address for any further communication. 475 4.2. Limitation of Number of Children Node 477 The maximum number of child nodes is determined by the specific AF 478 used. IEEE 802.15.5 has explored the use of a per-branch setup, 479 which, however, incurs scalability problems [LEE10]. NSA allocation 480 design is more flexible and extensible than the one proposed in IEEE 481 802.15.5. The AF used as example in this document does not need any 482 specific setup network by network, though it is still limited by the 483 maximum length of addresses. For the special case of the parent 484 connecting to huge amount of children, a variant of the proposed AF 485 can be designed to fulfill the requirement and optimize the address 486 allocation (as previously described). 488 5. Forwarding in a NSA Network 490 Internal and external communications in an NSA network work slightly 491 different. For internal communications, among NSA endpoints, packets 492 carry native short addresses and no special operation is needed. For 493 external communications, the root is responsible to perform the 494 translation between native short addresses and IPv6 addresses. For 495 instance, for a packet entering into the NSA domain, the root will 496 extract the native short address of the destination from the suffix 497 of the IPv6 address, by removing all leading '0's. It will also map 498 the source IPv6 address to a mapped native short address, in order to 499 make it more efficient for communication inside the NSA domain. 501 The root has to store the mapping between external IPv6 addresses and 502 their assigned mapped Native Short Addresses. The method of 503 generating those mapping is out of scope of this document, however, 504 the addressing space for the external NSA has to be maintained 505 separate from the internal NSA address space. Overlap are allowed 506 since the two addressing space are distinguishable in the packets by 507 the use of the I/O field, as explained later on. 509 The following paragraphs will detail the forwarding operations for 510 both internal and external communication. The intra-network 511 forwarding procedure depends on the specific AF used. Here we will 512 use the AF previously introduced (see Figure 4) to illustrate the 513 forwarding procedure. 515 5.1. Forwarding toward an NSA endpoint 517 To perform forwarding operations, NSA nodes access the I/O field in 518 the NSA header (see Section 7). When its value is 1, the packet is 519 destined to an internal NSA node, so it is an inner-domain packet. 520 Otherwise, the packet is destined to an external IPv6 node, so it is 521 called an outer-domain packet. Intra-domain packets carry a native 522 short addresses in the source and the destination address fields. 524 More specifically the destination address field is the address of 525 another node in the same NSA domain. As such an NSA node performs 526 the following sequence of actions (also see Figure 5): 528 1. Get destination address from packet (abbreviated to DA) and the 529 current node's address (abbreviated to CA). Go to step 2. 531 2. If length of DA is smaller than length of CA, send the packet to 532 parent node, exit. Otherwise, go to step 3. 534 3. If length of DA equals to length of CA, go to step 4. Otherwise, 535 go to step 5. 537 4. If DA and CA are the same, the packet arrived at destination, 538 exit. Otherwise, send the packet to parent node, exit. 540 5. Check whether CA is equal to the prefix of DA. If yes, go to 541 step 6. Otherwise, send the packet to parent node, exit. 543 6. Calculate which child is the next hop address and forward packet 544 to it. With the AF propose in this document such operation 545 reduces to reading the DA's bits starting from the position 546 equals to the length of CA, then skip all '1' until the first '0' 547 or the last bit of DA. The sub-string obtained in such a way is 548 the address of direct child of current node. 550 7. If any exception happens in the above steps, drop the packet and 551 send error notification. 553 /*\ DA:Destination Address 554 |***| CA:Current Node's Address 555 \*/ 556 | 557 +--------+--------+ 558 |Parse DA from pkt| 559 +--------+--------+ 560 | 561 \|/ 562 +-------+------+ 563 / \ yes 564 | Len(DA)| CA == DA ? |--->+ 572 \ / \ / | 573 +-------+------+ +-------+------+ | 574 | no | yes | 575 \|/ /*\ | 576 +-------+------+ |***| | 577 / \ no \*/ | 578 | CA==PrefixOf(DA)?|------------------------------>+ 579 \ / | 580 +-------+------+ | 581 | yes | 582 \|/ \|/ 583 +---------+---------+ +---------+---------+ 584 | Calculate next-hop| | Forward to Parent | 585 | & | +---------+---------+ 586 | Forward | | 587 +---------+---------+ | 588 |<---------------------------------------+ 589 \|/ 590 /*\ 591 |***| 592 \*/ 594 Figure 5: Flow Chart of Internal Forwarding Procedure 596 In the case of packet arriving from the Internet (external IPv6 597 domain toward the local NSA domain) header adaptation operation is 598 performed by the root node. Concerning the destination address, the 599 root builds the native short address of the destination by removing 600 the prefix and the leading '0's of the suffix of the destination 601 address. Meanwhile, it checks whether it exists already a mapping 602 between the source address and a mapped NSA address to be used as 603 source address in the NSA packet. If not it creates one. Then the 604 root creates the inner-domain packet. It uses the NSA address as 605 destination setting the I/O field to 1 so to route the packet to as 606 described above to the destination node. The mapped NSA address is 607 used as source address and the fact that is a Mapped Address is 608 signaled by setting to 1 the MA field. 610 5.2. Forwarding toward an external IPv6 node 612 In the case that the I/O field (cf. Section 7) is set to 0, the 613 packet is destined to an external IPv6 node, it is an outer-domain 614 packet. As such the destination address is either a full IPv6 615 address (for the first packet of a communication) or a mapped short 616 address generated by the root node and not belonging to any node 617 inside the NSA domain. 619 All NSA nodes (except root) just send packets that are destined 620 outside the local domain (I/O field equal 0) to their parent, not 621 even looking at the actual destination address. Eventually all 622 packets will reach the root node, which acts as gateway. The root 623 node is able to map the destination NSA address to the corresponding 624 full IPv6 address. Also, the root node is able to rebuild the full 625 source IPv6 address by concatenating the IPv6 prefix and the NSA 626 address as explained in Section 5.2. Other fields of the header are 627 also decompressed as described in Section 7. A full IPv6 header 628 replaces the original NSA header in the packet, which is then 629 forwarded according to traditional IPv6 protocol. 631 6. Benefits of Native Short Addressing 633 The NSA use a single set of messages for address assignment and tree 634 forming. It is not more complex than RPL tree forming. So, NSA 635 saves the overhead of address assignment of RPL. 637 Comparing to RPL with storing mode (see [RFC6550]), there is no need 638 for a NSA node to generate and store routing table entries in the 639 normal case. One of the potential issues is the risk of renumbering 640 of addresses in case of topology changes. Because of the 641 applicability domain of NSA, the common case of topology change is 642 known in advance and can be planned, so to reduce disruption due to 643 renumbering. Another case is temporary link failures where the 644 underlying technology is still able to provide connectivity through 645 alternative links. 647 In this scenario a node can temporarily "move" along with its whole 648 sub-tree. Instead of performing a renumbering of the whole sub-tree, 649 which may cause disruption, the sub-tree rooted on the "moving" node, 650 its address and the addresses of all its children and grand-children 651 can be kept unchanged, by creating a temporary entry in the 652 forwarding tables of the original and new parent nodes, in order to 653 make the sub-tree still reachable. 655 Herewith one example, also depicted in Figure 6, node A with the 656 address of 1000 somehow moves from node B (original parent) to node C 657 (new parent). In this case, the forwarding tables in B, C and their 658 parents' nodes should be updated by adding a new entry to "1000", the 659 address of node A. Meanwhile, the original parent (node B) should 660 keep its original address assignment. Comparing with renumbering the 661 addresses of node A and its children, the cost of adding one new 662 route to their parent nodes is much lower, although in this case, the 663 NSA does not implement complete stateless forwarding. However, this 664 solution SHOULD be used only in case of temporary topology changes, 665 where the entries will be deleted once the original topology is re- 666 established. For permanent topology changes it is RECOMMENDED to re- 667 run the NSA Allocation Function. 669 +------------------+ 670 | Add route: | 671 |to 1000, ia 1010 | 1 672 +------------------+ O 673 * / 674 +-----------------+ * / 675 | Add route: | * / 676 | to 1000, via 10 | O 10 677 +-----------------+ / \ 678 * / \ 679 * / \ 1010 (node C) 680 (node B)100 O O 681 . / * 682 . / *-----------------+ 683 . / | Add route: | 684 O / | to 1000, direct | 685 1000(node A) +-----------------+ 687 Figure 6: Add extra routes for "logic topology change 689 7. NSA Header Format 691 As explained in Section 4, the addresses in NSA are of variable 692 length, in this section, we outline the design of the header format 693 partially based on the format of 6lowPAN, accommodating the variable 694 length property in the packet. The header format is shown in 695 Figure 7. 697 0 1 698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 699 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 700 | 0 | 1 | 0 | 1 | TF |NH |HL | Payload Length(Variable Len) | 701 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 702 |I/O|MA | SA(Variable Len) | DA(Variable Len) | 703 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 704 | In-line fields ... | 705 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 707 Figure 7: Header format of NSA packets 709 The first 4 bits are new dispatch types that will be introduced in 710 Section 9. 712 * TF: The same definition as in [RFC6282] Section 3.1.1. 714 * NH: The same definition as in [RFC6282] Section 3.1.1. 716 * HL: This field indicates the hop limit. When HL is 1, a hop limit 717 field defined in [RFC2460] locates in in-line fields, while HL is 718 0 means no hop limit header in packet. 720 * Payload length is a variable length field. It normally occupies 721 an octet assuming most packets are smaller than 252 octets. For 722 larger packets, payload length may expand to 2 to 3 octets. The 723 encoding method is defined as follows. When the first octet has 724 value of: 726 - 0~252: Indicates how many octets the payload consist of. 728 - 253: Indicates that there is an extra octet for payload length, 729 with the actual length value equal to the last octet value plus 730 252. 732 - 254: Indicates that there is an extra two octets for payload 733 length, with the actual length value obtained from the second 734 and third octets interpreted as a 16 bits unsigned integer plus 735 252 (from the first octet). 737 - 255: Reserved. 739 * I/O: Indicates whether this packet is destined to a inner-domain 740 node (value '1') or an outer-domain node (value '0'), where the 741 former means from an NSA or IPv6 node to a NSA destination, while 742 the latter means to an external IPv6 node. 744 * MA: Indicates the source address is actually a Mapped Address 745 generated by the root. When it is '1', the source address of the 746 packet is a mapped address of an external IPv6 address, while if 747 it is '0', the source address of the packet is an NSA address. 749 For length variable native short address encoding, for both Source 750 Address (SA) and Destination Address (DA), the definition is: 752 * 0~252: if the address value locates in this interval, one octet is 753 used to encode the value 755 * 253: indicates that the following 2 octets encode the address. 757 * 254: indicates that the following 4 octets encode the address. 759 * 255: indicates that the following octet defines the length of 760 address in octets, followed by the address octets. 762 The sequence of in-line fields is as per [RFC8200] section 3. 764 8. NSA Control Message 766 This documents specifies only one NSA Control Message, namely the NSA 767 Mapped Address Advertisement described in Section 4. The purpose of 768 such a message is advertise the mapping of an IPv6 address into a NSA 769 address. The map is performed by the root node and sent to the node 770 originating the communication. The root keeps a copy of the mapping 771 to be used for future packets. The format is as follows: 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Type | Code = 0x00 | Reserved | NSA Length | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | 779 | Target IPv6 Address (Fixed length 128 bist) | 780 | | 781 | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Target NSA Address (Variable length) .... | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 * Type: Type value identifying NSA Control Message. Value to be 787 assigned by IANA (cf. Section 9) 789 * Code: This field identifies the specific control message. In this 790 case it is set to the value 0x00 "NSA Mapped Address for External 791 IPv6 Address". 793 * Reserved: Set as 0 on transmission and ignored on reception. 795 * NSA Length: This field indicates the length of the Target NSA 796 Address at the end of the message, expressed in octets. 798 The "NSA Mapped Address for External IPv6 Address" is a variable 799 length message, however, the first five fields of the message, namely 800 Type, Code Reserved, NSA Length, and Target IPv6 address, have a 801 fixed length of 160 bits (20 octets), hence the length of the NSA 802 address is sufficient to calculate the length of the entire packet: 803 20 octets + "NSA length". 805 9. IANA Considerations 807 9.1. Dispatch Type Field 809 This document requires IANA to assign the range 01010000 to 01011111 810 in page 10 of the "Dispatch Type Field" registry as follows: 812 +-------------+----+-----------------------------+---------------+ 813 | Bit Pattern |Page| Header Type | Reference | 814 +-------------+----+-----------------------------+---------------+ 815 | 0101TTNH | 10 | LOWPAN NSA IP(LOWPAN_NIP) |[This Document]| 816 +-------------+----+-----------------------------+---------------+ 818 Figure 8: LOWPAN Dispatch Type Field requested allocation 820 9.2. Allocation Function Registry 822 This section provides guidance to the Internet Assigned Numbers 823 Authority (IANA) regarding registration of values related to the NSA 824 specification, in accordance with BCP 26 [RFC8126]. 826 IANA is asked to create a registry named "Native Short Addresses 827 (NSA) Parameters". 829 Such registry should be populated with a one octet sub registry named 830 "Allocation Function" and used to identify the AF used in a NSA 831 deployment. The sub registry is populated as follows: 833 +---------+----------------------------+-----------------+ 834 | Value | AF Name | Reference | 835 +---------+----------------------------+-----------------+ 836 | 0x00 | Native Allocation Function | [This Document] | 837 +---------+----------------------------+-----------------+ 838 |0x01-0xFF| Un-assigned | | 839 +---------+----------------------------+-----------------+ 841 Values can be assigned by IANA on a "First Come, First Served" basis 842 according to [RFC8126]. 844 9.3. ICMP NSA Control Message 846 IANA is requested to allocate an ICMPv6 type value from the "ICMPv6 847 Parameters" registry to be used by "NSA Control Message". 849 Also IANA is requested to create an "NSA Control Codes" sub registry, 850 for the Code field of the ICMPv6 NSA Control Message. 852 New codes may be allocated through the "Specification Required" 853 procedure as defined in [RFC8126]. The following code is currently 854 defined (the others are to be marked as un-assigned): 856 +------+--------------------------------------------+---------------+ 857 | Code | Description | Reference | 858 +------+--------------------------------------------+---------------+ 859 | 0x00 |NSA Mapped Address for External IPv6 Address|[This Document]| 860 +------+--------------------------------------------+---------------+ 862 10. Security Considerations 864 An extended security analysis will be provided in future revision of 865 this document. As of this point we consider that the security 866 considerations of [RFC4944], [RFC6282] apply. 868 11. References 870 11.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 878 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 879 December 1998, . 881 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 882 "Transmission of IPv6 Packets over IEEE 802.15.4 883 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 884 . 886 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 887 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 888 DOI 10.17487/RFC6282, September 2011, 889 . 891 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 892 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 893 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 894 Low-Power and Lossy Networks", RFC 6550, 895 DOI 10.17487/RFC6550, March 2012, 896 . 898 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 899 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 900 RFC 8025, DOI 10.17487/RFC8025, November 2016, 901 . 903 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 904 Writing an IANA Considerations Section in RFCs", BCP 26, 905 RFC 8126, DOI 10.17487/RFC8126, June 2017, 906 . 908 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 909 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 910 May 2017, . 912 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 913 (IPv6) Specification", STD 86, RFC 8200, 914 DOI 10.17487/RFC8200, July 2017, 915 . 917 11.2. Informative References 919 [I-D.ietf-6lo-use-cases] 920 Hong, Y., Gomez, C., Sangi, A. R., and S. Chakrabarti, 921 "IPv6 over Constrained Node Networks (6lo) Applicability & 922 Use cases", Work in Progress, Internet-Draft, draft-ietf- 923 6lo-use-cases-11, 12 July 2021, 924 . 927 [LEE10] Lee, M., Zhang, R., Zheng, J., Ahn, G., Zhu, C., Park, T., 928 Cho, S., Shin, C., and J. Ryu, "IEEE 802.15.5 WPAN mesh 929 standard-low rate part: Meshing the wireless sensor 930 networks", IEEE Journal on Selected Areas in 931 Communications Vol. 28, pp. 973-983, 932 DOI 10.1109/jsac.2010.100902, September 2010, 933 . 935 [LPWAN] "IPv6 over Low Power Wide-Area Networks (lpwan) WG", n.d., 936 . 938 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 939 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 940 . 942 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 943 "IPv6 over Low-Power Wireless Personal Area Network 944 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 945 April 2017, . 947 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 948 Zuniga, "SCHC: Generic Framework for Static Context Header 949 Compression and Fragmentation", RFC 8724, 950 DOI 10.17487/RFC8724, April 2020, 951 . 953 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 954 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 955 . 957 [SIXLO] "IPv6 over Networks of Resource-constrained Nodes (6lo) 958 WG", n.d., . 960 [SIXLOWPAN] 961 "IPv6 over Low power WPAN (6lowpan) - Concluded WG", n.d., 962 . 964 [ZigBee] "ZigBee Wireless Networks and Transceivers", 965 Elsevier book, DOI 10.1016/b978-0-7506-8393-7.x0001-5, 966 2008, 967 . 969 Authors' Addresses 971 Guangpeng Li 972 Huawei Technologies 973 Beiqing Road, Haidian District 974 Beijing 975 100095 976 China 978 Email: liguangpeng@huawei.com 980 David Lou 981 Huawei Technologies Duesseldorf GmbH 982 Riesstrasse 25 983 80992 Munich 984 Germany 986 Email: zhe.lou@huawei.com 988 Luigi Iannone 989 Huawei Technologies France S.A.S.U. 990 18, Quai du Point du Jour 991 92100 Boulogne-Billancourt 992 France 994 Email: luigi.iannone@huawei.com 996 Peng Liu 997 China Mobile 998 No. 53, Xibianmen Inner Street, Xicheng District 999 Beijing 1000 100053 1001 China 1003 Email: liupengyjy@chinamobile.com 1005 Rong Long 1006 China Mobile 1007 No. 53, Xibianmen Inner Street, Xicheng District 1008 Beijing 1009 100053 1010 China 1012 Email: longrong@chinamobile.com