idnits 2.17.1 draft-li-6lo-native-short-address-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (4 March 2022) is 785 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 1073, but no explicit reference was found in the text == Unused Reference: 'SIXLO' is defined on line 1112, but no explicit reference was found in the text == Unused Reference: 'SIXLOWPAN' is defined on line 1115, 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-12 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: 5 September 2022 Huawei 6 P. Liu 7 R. Long 8 China Mobile 9 4 March 2022 11 Native Short Addressing for Low power and Lossy Networks Expansion 12 draft-li-6lo-native-short-address-02 14 Abstract 16 This document specifies a topological addressing scheme, Native Short 17 Address (NSA) that enables IP packet transmission over links where 18 the transmission of a full length address may not be desirable. This 19 document focuses on carrying IP packets across an LLN (Low power and 20 Lossy Network), in which the topology is relatively static where 21 nodes' location is fixed and the connection between nodes is rather 22 stable. The changes in the logical topology are only caused by non- 23 frequent disconnection in the link. The specifications details the 24 NSA architecture, address allocation, forwarding mechanism, header 25 format design, including length-variable fields, and IPv6 26 interconnection support. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 5 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 63 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 64 4. NSA Allocation . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. NSA Addresses and IPv6 Addresses . . . . . . . . . . . . 11 66 4.2. Limitation of Number of Children Nodes . . . . . . . . . 12 67 5. Forwarding in a NSA Network . . . . . . . . . . . . . . . . . 12 68 5.1. Forwarding toward an NSA endpoint . . . . . . . . . . . . 13 69 5.2. Forwarding toward an external IPv6 node . . . . . . . . . 15 70 6. Benefits of Native Short Addressing . . . . . . . . . . . . . 15 71 7. NSA Header Format . . . . . . . . . . . . . . . . . . . . . . 17 72 8. NSA Control Message . . . . . . . . . . . . . . . . . . . . . 18 73 8.1. New Control Message . . . . . . . . . . . . . . . . . . . 18 74 8.2. Address Configuration based on 6LOWPAN-ND . . . . . . . . 19 75 8.2.1. NSA Request Address Option (NRAO) Format . . . . . . 20 76 8.2.2. NSA Assign Address Option (NAAO) Format . . . . . . . 20 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 9.1. Dispatch Type Field . . . . . . . . . . . . . . . . . . . 21 79 9.2. Allocation Function Registry . . . . . . . . . . . . . . 21 80 9.3. ICMP NSA Control Message . . . . . . . . . . . . . . . . 22 81 9.4. NSA Neighbor Discovery Options . . . . . . . . . . . . . 22 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 85 11.2. Informative References . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 There is an ongoing massive expansion of the network edge that is 91 driven by the "Internet of Things" (IoT), especially over low-power 92 links which often, in the past, did not support IP packet 93 transmission. 95 Particularly driven by the requirements stemming from Industry 4.0 96 and Smart City deployments, more and more devices/things are 97 connected to the Internet. Sensors in plants/parking bays/mines, 98 temperature/humidity/flash sensors in museums, normally are located 99 in a fixed position and are networked by low power and lossy links 100 even in hardwired networks. Comparing with traditional scenarios, 101 scalability of the (edge) network along with lower power consumption 102 are key technical requirements. Moreover, large-scale Low power 103 Lossy Networks (LLNs) are expected to be able to carry IPv6 packets 104 over their links, together with an efficient access to native IPv6 105 domains. 107 The work in [SIXLOWPAN]/[SIXLO]/[LPWAN] Working Groups addresses many 108 fundamental issues for those type of deployments. Those deployments 109 can be considered an instantiation of what [RFC8799] defines as 110 "limited domains". For instance, the 6lowpan compression technology 111 ([RFC4944] and [RFC6282]) addresses the problem of IPv6 transmission 112 over LLNs, making it possible to interconnect IPv6-based IoT networks 113 and the Internet. [RFC8138] introduces a framework for implementing 114 multi-hop routing on an LLN using a compressed routing header, which 115 works also with RPL (Routing Protocol for LLNs [RFC6550]). This 116 technique enables the ability to forward IPv6 packets within the 117 domain without the need of decompression. In addition, SCHC (Generic 118 Framework for Static Context Header Compression and Fragmentation 119 [RFC8724]) enables even more compression by using a common static 120 context. 122 Although aforementioned technologies are suitable in general for all 123 IoT scenarios, there could be more simplified solutions for those 124 scenarios and applications with static network topology and stable 125 network connections leveraging on wired technologies 126 [I-D.ietf-6lo-use-cases] (e.g. smart building, smart parking, etc.). 127 In those kinds of deployments, topologies are planned in advance and 128 well provisioned, with sensor nodes usually fixed in specific 129 locations. This draft presents a topology based addressing mechanism 130 with shorter packet header and simpler forwarding rules for those 131 static IoT networks. 133 The specifications in this document leverage on previous work, namely 134 using the dispatch type field ([RFC4944], [RFC8025]) that allows to 135 accommodate the proposed address format. This means that except the 136 addresses (source and destination) the other fields of the header 137 will be compressed mostly according to LOWPAN_IPHC. The proposed 138 addressing is independent of Unique Local Addresses [RFC4193], which 139 has a dependency on specific link-layer conventions [RFC6282]. It is 140 also different from stateful address allocation that requires all 141 nodes to obtain addresses from a centralized DHCP server, which leads 142 to long network startup time and consumption of extra bandwidth. 143 Compared to RPL-based routing [RFC6550], NSA avoids the extra 144 overhead of address assignment by integrating address assignment and 145 tree forming together. Furthermore, NSA provides much smaller 146 forwarding table size than storing mode RPL. 148 2. Requirements Notation 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Architectural Overview 158 Native Short Address (NSA) is an efficient topology-based network 159 layer address assignment and packet forwarding mechanism that is 160 performed in a decentralized fashion. The NSA nodes are aware of 161 their own IPv6 address, constructed by IPv6 prefix and the NSA (see 162 Section 4.1 and Section 5.2). Inside the NSA domain, nodes 163 communicate with each other using only NSA addresses. It is a 164 smaller address space compared to the huge IPv6 addressing space. 165 The NSA enables stateless forwarding. When IPv6 communication occurs 166 between nodes inside the NSA domain and external IPv6 nodes, the 167 border router, which plays as well the role of "root" in the 168 addressing tree, performs network address translation (as per 169 Section 5.2 and [RFC6282]). The architecture of NSA network is 170 showed in Figure 1. 172 /|\ Internet (IPv6) 173 | --------+-------- 174 IPv6 Domain | | 175 | | 176 | +-------+-------+ 177 ---------------------------- | Border Router | 178 | +---------------+ 179 | 180 | O 181 | 182 | O O O 183 | O O 184 | O O 185 NSA Domain | O 186 | O O O O O O 187 | O 188 | O O 189 | O 190 | O 191 | 192 | Up to several thousands of nodes 193 | 194 \|/ 195 LLN 197 Figure 1: The architecture of general NSA networks. 199 In the NSA network, there are 3 types of nodes, the root node, the 200 forwarder node and the leaf node. There is typically one root node 201 in the NSA network. The root node is responsible for the management 202 of the whole NSA network and routing/forwarding both internal and 203 external traffic. It stores the IPv6 prefix of the domain in order 204 to perform the network address translation for external 205 communications. It also stores the address Allocation Function (AF) 206 and performs the address assignment for its children. After 207 successful address assignment, the root will keep the state of its 208 children and refresh them when changed. The root node functions as 209 gateway between the NSA domain and the Internet. As such it also 210 operates the translation between NSA header and IPv6 header (cf. 211 Section 5). 213 A forwarder node is a node, different from the root node, containing 214 at least one child. The forwarder node is basically the root of a 215 sub-tree and its role is to forward traffic between its parent and 216 its children according to addressing. When handling a packet, if the 217 destination is in its sub-tree, it forwards the packet to the right 218 child, otherwise it simple sends it to its parent. 220 A leaf node is a node with no children. Its operation is simple 221 since it is either a destination or source of every packet it 222 handles. If it is the source of packets, it simply sends the packets 223 to its parent. 225 Each node acquiring a native short address needs to send an Address 226 Request (AR) message to its link layer neighbors and wait for the 227 response. In the AR message, the node needs to designate a 'role' 228 value (forwarder or leaf) and the 'node-id'. The latter is a unique 229 identifier of each NSA node, including root, forwarders, and leaves. 230 This document assumes the use of the link-layer address of the node 231 as 'node-id'. 233 Forwarder and Leaf roles can be assigned similarly to IEEE 802.15.4, 234 which distinguishes between Full-Function Devices (FFD) and reduced 235 function devices (RFD) (cf., [ZigBee]). If a neighbor is neither a 236 forwarder nor the root, it will drop the AR message silently. 237 Otherwise, the neighbor will calculate an address based on parameters 238 in the AR message. After the neighbor node assigns an address to the 239 node, using a Allocation function (AF), it stores the suffix of that 240 address as the interface ID towards the node. Then, it generates and 241 sends Address Assignment (AA) message back and becomes the parent 242 node. 244 This address assignment relies on the base mechanism described in 245 6lowpan-ND ([RFC6775]), but defines two new options of ND message, 246 whose format is defined in Section 8.2.1 and Section 8.2.2. 248 The acceptance of the address assignment follows "first come first 249 serve" principle. Once a node receives a valid AA response, it uses 250 that assigned address as its own network layer address, thus becomes 251 a child of the address assigner. It will then ignore replies from 252 other neighbors. 254 If a node does not receive any response after an pre-defined 255 interval, it will send the AR message again. It is RECOMMENDED that 256 nodes re-send the AR message up to 3 times, if no answer is received, 257 they SHOULD stop. 259 The overall design objective is centered on reducing the size (or 260 completely avoid the usage) of routing/forwarding table with a 261 topological addressing scheme to save communication energy in an IoT 262 LLN network. NSA eliminates compression/decompression of the address 263 and also reduces the amount of information synchronization messages, 264 so it actually reduces computation complexity during packets parsing 265 and forwarding. 267 To this end, NSA uses a context-independent address encoding 268 mechanism. It does not carry any field about address context in the 269 packet. It carries source and destination addresses by variable 270 length fields whose size can be reduced to one byte each in the best 271 case. This allows the NSA packet header to be smaller than 272 LOWPAN_IPHC's 7 bytes (see Figure 2), down to 4 bytes, representing 273 around 40% reduction in the header size. 275 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 276 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 277 | 0 | 1 | 0 | 1 | TF |NH |HLM| | 0 | 1 | 1 | TF |NH | HLIM | 278 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 279 |Payload Length(variable length)| |CID|SAC| SAM | M |DAC| DAM | 280 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 281 |I/O|AM | Src(var len) | | SCI | DCI | 282 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ 283 | Dst (var len) | | | 284 +---+---+---+---+---+---+---+---+ + Source Address + 285 | | 286 +---+---+---+---+---+---+---+---+ 287 | | 288 + Destination Address + 289 | | 290 +---+---+---+---+---+---+---+---+ 292 b. IPHC best case header 293 a. NSA best case header with context-based encoding 294 and global unicast address 296 Figure 2: Best case of NSA and LOWPAN_IPHC packet header. 298 There are three distinct NSA features that allow NSA to be efficient, 299 namely: 301 1. Native Short Address allocation (see Section 4), 303 2. Stateless forwarding (see Section 5), 305 3. Compact header format design (see Section 7) that avoids context 306 and compression. 308 4. NSA Allocation 310 The basic rules of allocation include: 312 * Each node's address is prefixed by their parent's address. 314 * The root/forwarder runs an AF (Allocation Function) to generate 315 its children's addresses. 317 * All nodes run the same AF in the same network instance. 319 * The maximum length of the NSA address should not exceed 64-bit. 321 Normally, the root role is assigned to the border router when the LLN 322 bootstraps. An example of a possible result of an NSA deployment is 323 shown in Figure 3. 325 root +--------------------------+ 326 1 | append more bits to form | 327 O ----+ | brother's address | 328 / | \ \ +--------------------------+ 329 / | \ \ 330 / | \ \ 331 +---------+ / | \ \ 332 |forwarder| 10 / 11 110\ \ 111 333 |node | O - O O O 334 +---------+/ |\ \ | \ 335 / | \ \ | \ 336 / | \ \ O O 337 / | \ \ 338 100/ 1010| 101 1011 +--------------+ 339 O O O O |Prefix is '10'| 340 /| /| +--------------+ 341 / | / | 342 O O O O 343 1001 10011 10101 101011 345 Figure 3: An example of NSA addresses allocation. 347 The allocation function AF(role,i) used in this document is defined 348 in Figure 4. Where every forwarder node should store and maintain 349 two indexes, one for the children that are forwarders and one for the 350 children that are leaves (starting at 0 for the first child in each 351 role). Let's call the first index 'f', as of forwarder, and the 352 second 'l' as for leaves. The '+' symbol indicates a concatenation 353 operation. The b() operation indicates the binary string of '1' with 354 length equal to its argument, for instance b(3) returns '111'. 356 AF(role, f, l) = 'address of the node performing the function' 357 + (role == leaf? b(l++):b(f++)) 358 + (role == leaf?'1':'0'), 359 in which, f and l are the indexes of respectively the forwarders 360 and the leaves at this layer (starting at 0). 362 Figure 4: Definition of the Allocation Function (AF) of 363 forwarder/root nodes. 365 Taking the example of the topology in Figure 3, the proposed AF works 366 as follows. 368 At the top level, there are 4 children of root, two are forwarders 369 and the other two are leaves. Starting from the left most node and 370 moving to the right, the root node applies the AF as follows: 372 * For the first child, which is a forwarder: 374 - A('forwarder', 0, 0) = '1'(root address) + b(0) + '0' = '1' + 375 '' + '0' = 10 377 - Index f is increased by one and is now equal 1 (f=1) 379 * For the second child, which is a leaf: 381 - A('leaf', 1, 0) = '1'(root address) + b(0) + '1' = '1' + '' + 382 '1' = 11 384 - Index l is increased by one and is now equal 1 (l=1) 386 * For the third child, which is a forwarder: 388 - A('forwarder', 1, 1) = '1'(root address) + b(1) + '0' = '1' + 389 '1' + '0' = 110 391 - Index f is increased by one and is now equal 2 (f=2) 393 * For the fourth child, which is a leaf: 395 - A('leaf', 2, 1) = '1'(root address) + b(1) + '1' = '1' + '1' + 396 '1' = 111 398 - Index l is increased by one and is now equal 2 (l=2) 400 The first level addresses have now been assigned. Let's now have a 401 look how the node 10 (the first forwarder child of the root) applies 402 the same Allocation Function. Note that node 10 will use its own 'f' 403 and 'l' indexes initialized to 0. Starting again from the left most 404 node, node 10 applies the AF as follows: 406 * For the first child, which is a forwarder: 408 - A('forwarder', 0, 0) = '10'(node address) + b(0) + '0' = '10' + 409 '' + '0' = 100 411 - Index f is increased by one and is now equal 1 (f=1) 413 * For the second child, which is a leaf: 415 - A('leaf', 1, 0) = '10'(node address) + b(0) + '1' = '10' + '' + 416 '1' = 101 418 - Index l is increased by one and is now equal 1 (l=1) 420 * For the third child, which is a forwarder: 422 - A('forwarder', 1, 1) = '10'(node address) + b(1) + '0' = '10' + 423 '1' + '0' = 1010 425 - Index f is increased by one and is now equal 2 (f=2) 427 * For the fourth child, which is a leaf: 429 - A('leaf', 2, 1) = '10'(node address) + b(1) + '1' = '10' + '1' 430 + '1' = 1011 432 - Index l is increased by one and is now equal 2 (l=2) 434 Note how the children of the same parent all have the same prefix (10 435 in this example). The proposed AF algorithmically assigns addresses 436 to the different nodes without the need to know the topology in 437 advance. However, the largest address of the network will depend on 438 the actual topology. Indeed, the maximum length of an address with 439 the proposed AF grows linearly at each level of the tree with the 440 number of siblings from the same parent. Let's take again the 441 example in Figure 3 and let's assume that the children of node 10 are 442 all leaves, for the largest address we need 2 bits to encode the 443 parent node prefix (10 in this case) to which we need to add a number 444 of '1' equal to the value of the l index which is the number of 445 leaves minus one (because the first leaf has index 0), in this case 446 since there are 4 leaves, the index value is 3 and we add the '111' 447 string, hence the address length would be 6 (2 for the prefix, 3 to 448 encode the 4th leaf address, and one for the final 1 the ends all 449 leaves addresses). In a more formal way the maximum address length 450 at each level can be calculated as (where Ceiling just returns the 451 least integer greater or equal its argument): 453 Max_Length = length(Parent address) 454 length(b(max(f,l))) 455 + 1 457 Where f and l are the indexes counting respectively the forwarders 458 and the leaves at this level. 460 The Allocation Function can be different from the one defined in 461 Figure 4, but all nodes know which one to use by configuration. The 462 use of one and only one AF is allowed in an NSA domain. It is 463 RECOMMENDED that implementations support at least the AF proposed in 464 this document (cf. Section 9). 466 Different allocation function may, for example, leverage on a priori 467 knowledge of the topology in order to optimize the maximum address 468 size and make it smaller. For instance, because the order of address 469 allocation has an impact on the size, the address of children with 470 the largest subtree should be allocated in the first place so to 471 reduce the average address length of the whole subtree. Also, 472 knowing the traffic in advance, or being able to have an estimation, 473 can help to minimize the size of addresses that have a lot of 474 traffic. This kind of optimization can be an option, the 475 specification of optimizations is out of the scope of this document 476 and may be defined in new Allocation Functions to be added to the 477 "Allocation Function Registry" (see Section 9). 479 4.1. NSA Addresses and IPv6 Addresses 481 Obtaining a full IPv6 address from a NSA address is pretty 482 straightforward. First the NSA address is concatenated to the 483 configured IPv6 prefix. Since the length of the NSA address is 484 smaller than or equal to 64 bits (the interface ID length in IPv6), 485 the node needs to pad it with zeros ('0') used as most significant 486 bits. The full IPv6 address will look like: IPv6 prefix + 487 "000...000" + NSA (or in IPv6 notation ::). The 488 NSA is assigned by the root/forwarder as previously described. 490 In an IPv6 communication, the node will derive the NSA address as the 491 short source address from its own IPv6 address by simply removing the 492 IPv6 prefix and all leading zeros before the NSA part. The node will 493 compare the destination IPv6 address with its own IPv6 address. If 494 they have the same prefix, it means that the destination is in the 495 local NSA domain and its corresponding NSA address will be extracted 496 as the short destination address (and the I/O Flag can be set 497 accordingly). Otherwise, it will be a communication towards the 498 Internet. In that case, a mapping mechanism implemented on the root 499 node will generate a short address to be mapped to the full IPv6 500 destination address. For instance, the mapped short address can be 501 generated using the least significative bits of the original IPv6 502 address. As previously stated, the mapping mechanism is out of the 503 scope of this document. 505 Since the short mapped address is generated on the root, when the 506 node first open the connection toward the external site, with a first 507 packet, the destination address is set to the full, uncompressed, 508 IPv6 address. Once the packet arrives to the root node, performing 509 the destination address lookup the root will notice that a full IPv6 510 address is being used and will trigger the short address generation 511 mechanism and create a new mapping. Such, mapping is communicated to 512 the source node via a new dedicated ICMP message (see Section 8). 513 Once the node originating the communication receives such a message 514 it SHOULD use the mapped short address for any further communication. 516 4.2. Limitation of Number of Children Nodes 518 The maximum number of child nodes is determined by the specific AF 519 used. IEEE 802.15.5 has explored the use of a per-branch setup, 520 which, however, incurs scalability problems [LEE10]. NSA allocation 521 design is more flexible and extensible than the one proposed in IEEE 522 802.15.5. The AF used as example in this document does not need any 523 specific setup network by network, though it is still limited by the 524 maximum length of addresses. For the special case of the parent 525 connecting to huge amount of children, a variant of the proposed AF 526 can be designed to fulfill the requirement and optimize the address 527 allocation (as previously described). 529 5. Forwarding in a NSA Network 531 Internal and external communications in an NSA network work slightly 532 different. For internal communications, among NSA endpoints, packets 533 carry native short addresses and no special operation is needed. For 534 external communications, the root is responsible to perform the 535 translation between native short addresses and IPv6 addresses. For 536 instance, for a packet entering into the NSA domain, the root will 537 extract the native short address of the destination from the suffix 538 of the IPv6 address, by removing all leading '0's. It will also map 539 the source IPv6 address to a mapped native short address, in order to 540 make it more efficient for communication inside the NSA domain. 542 The root has to store the mapping between external IPv6 addresses and 543 their assigned mapped Native Short Addresses. The method of 544 generating those mapping is out of scope of this document, however, 545 the addressing space for the external NSA has to be maintained 546 separate from the internal NSA address space. Overlap are allowed 547 since the two addressing space are distinguishable in the packets by 548 the use of the I/O field, as explained later on. 550 The following paragraphs will detail the forwarding operations for 551 both internal and external communication. The intra-network 552 forwarding procedure depends on the specific AF used. Here we will 553 use the AF previously introduced (see Figure 4) to illustrate the 554 forwarding procedure. 556 5.1. Forwarding toward an NSA endpoint 558 To perform forwarding operations, NSA nodes access the I/O field in 559 the NSA header (see Section 7). When its value is 1, the packet is 560 destined to an internal NSA node, so it is an inner-domain packet. 561 Otherwise, the packet is destined to an external IPv6 node. It is 562 called an outer-domain packet. Intra-domain packets carry a native 563 short addresses in the source and the destination address fields. 564 More specifically the destination address field is the address of 565 another node in the same NSA domain. As such an NSA node performs 566 the following sequence of actions (also see Figure 5): 568 1. Get destination address from packet (abbreviated to DA) and the 569 current node's address (abbreviated to CA). Go to step 2. 571 2. If length of DA is smaller than length of CA, send the packet to 572 parent node, exit. Otherwise, go to step 3. 574 3. If length of DA equals to length of CA, go to step 4. Otherwise, 575 go to step 5. 577 4. If DA and CA are the same, the packet arrived at destination, 578 exit. Otherwise, send the packet to parent node, exit. 580 5. Check whether CA is equal to the prefix of DA. If yes, go to 581 step 6. Otherwise, send the packet to parent node, exit. 583 6. Calculate which child is the next hop address and forward packet 584 to it. With the AF propose in this document such operation 585 reduces to reading the DA's bits starting from the position 586 equals to the length of CA, then skip all '1' until the first '0' 587 or the last bit of DA. The sub-string obtained in such a way is 588 the address of direct child of current node. 590 7. If any exception happens in the above steps, drop the packet and 591 send error notification. 593 /*\ DA:Destination Address 594 |***| CA:Current Node's Address 595 \*/ 596 | 597 +--------+--------+ 598 |Parse DA from pkt| 599 +--------+--------+ 600 | 601 \|/ 602 +-------+------+ 603 / \ yes 604 | Len(DA)| CA == DA ? |--->+ 612 \ / \ / | 613 +-------+------+ +-------+------+ | 614 | no | yes | 615 \|/ /*\ | 616 +-------+------+ |***| | 617 / \ no \*/ | 618 | CA==PrefixOf(DA)?|------------------------------>+ 619 \ / | 620 +-------+------+ | 621 | yes | 622 \|/ \|/ 623 +---------+---------+ +---------+---------+ 624 | Calculate next-hop| | Forward to Parent | 625 | & | +---------+---------+ 626 | Forward | | 627 +---------+---------+ | 628 |<---------------------------------------+ 629 \|/ 630 /*\ 631 |***| 632 \*/ 634 Figure 5: Flow Chart of Internal Forwarding Procedure 636 In the case of packet arriving from the Internet (external IPv6 637 domain toward the local NSA domain) header adaptation operation is 638 performed by the root node. Concerning the destination address, the 639 root builds the native short address of the destination by removing 640 the prefix and the leading '0's of the suffix of the destination 641 address. Meanwhile, it checks whether it exists already a mapping 642 between the source address and a mapped NSA address to be used as 643 source address in the NSA packet. If not it creates one. Then the 644 root creates the inner-domain packet. It uses the NSA address as 645 destination setting the I/O field to 1 so to route the packet to as 646 described above to the destination node. The mapped NSA address is 647 used as source address and the fact that is a Mapped Address is 648 signaled by setting to 1 the MA field. 650 5.2. Forwarding toward an external IPv6 node 652 In the case that the I/O field (cf. Section 7) is set to 0, the 653 packet is destined to an external IPv6 node, it is an outer-domain 654 packet. As such the destination address is either a full IPv6 655 address (for the first packet of a communication) or a mapped short 656 address generated by the root node and not belonging to any node 657 inside the NSA domain. 659 All NSA nodes (except root) just send packets that are destined 660 outside the local domain (I/O field equal 0) to their parent, not 661 even looking at the actual destination address. Eventually all 662 packets will reach the root node, which acts as gateway. The root 663 node is able to map the destination NSA address to the corresponding 664 full IPv6 address. Also, the root node is able to rebuild the full 665 source IPv6 address by concatenating the IPv6 prefix and the NSA 666 address as explained in Section 5.2. Other fields of the header are 667 also decompressed as described in Section 7. A full IPv6 header 668 replaces the original NSA header in the packet, which is then 669 forwarded according to traditional IPv6 protocol. 671 6. Benefits of Native Short Addressing 673 The NSA use a single set of messages for address assignment and tree 674 forming. It is not more complex than RPL tree forming. So, NSA 675 saves the overhead of address assignment of RPL. 677 Comparing to RPL with storing mode (see [RFC6550]), there is no need 678 for a NSA node to generate and store forwarding table entries in the 679 normal case. One of the potential issues is the risk of renumbering 680 of addresses in case of topology changes. Because of the 681 applicability domain of NSA, the common case of topology change is 682 known in advance and can be planned, so to reduce disruption due to 683 renumbering. Another case is temporary link failures where the 684 underlying technology is still able to provide connectivity through 685 alternative links. 687 In this scenario a node can temporarily "move" along with its whole 688 subtree. Instead of performing a renumbering of the whole subtree, 689 which may cause disruption, the subtree rooted on the "moving" node, 690 its address and the addresses of all its children and grand-children 691 can be kept unchanged, by creating a temporary entry in the 692 forwarding tables of the original and new parent nodes, in order to 693 make the subtree still reachable. 695 Herewith one example, also depicted in Figure 6, node A with the 696 address of 1000 somehow moves from node B (original parent) to node C 697 (new parent). In this case, the forwarding tables in B, C and their 698 parents' nodes should be updated by adding a new entry to "1000", the 699 address of node A. Meanwhile, the original parent (node B) should 700 keep its original address assignment. Comparing with renumbering the 701 addresses of node A and its children, the cost of adding one new 702 route to their parent nodes is much lower, although in this case, the 703 NSA does not implement complete stateless forwarding. However, this 704 solution SHOULD be used only in case of temporary topology changes, 705 where the entries will be deleted once the original topology is re- 706 established. On top of that, it is RECOMMENDED to perform the re- 707 numbering by running the NSA Allocation Function periodically. 709 +------------------+ 710 | Add route: | 711 |to 1000, ia 1010 | 1 712 +------------------+ O 713 * / 714 +-----------------+ * / 715 | Add route: | * / 716 | to 1000, via 10 | O 10 717 +-----------------+ / \ 718 * / \ 719 * / \ 1010 (node C) 720 (node B)100 O O 721 . / * 722 . / *-----------------+ 723 . / | Add route: | 724 O / | to 1000, direct | 725 1000(node A) +-----------------+ 727 Figure 6: Add extra routes for "logic topology change 729 7. NSA Header Format 731 As explained in Section 4, the addresses in NSA are of variable 732 length, in this section, we outline the design of the header format 733 partially based on the format of 6lowPAN, accommodating the variable 734 length property in the packet. The header format is shown in 735 Figure 7. 737 0 1 738 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 739 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 740 | 0 | 1 | 0 | 1 | TF |NH |HL | Payload Length(Variable Len) | 741 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 742 |I/O|MA | SA(Variable Len) | DA(Variable Len) | 743 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 744 | In-line fields ... | 745 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 747 Figure 7: Header format of NSA packets 749 The first 4 bits are new dispatch types that will be introduced in 750 Section 9. 752 * TF: The same definition as in [RFC6282] Section 3.1.1. 754 * NH: The same definition as in [RFC6282] Section 3.1.1. 756 * HL: This field indicates the hop limit. When HL is 1, a hop limit 757 field defined in [RFC2460] locates in in-line fields, while HL is 758 0 means no hop limit header in packet. 760 * Payload length is a variable length field. It normally occupies 761 an byte assuming most packets are smaller than 252 bytes. For 762 larger packets, payload length may expand to 2 to 3 bytes. The 763 encoding method is defined as follows. When the first byte has 764 value of: 766 - 0~252: Indicates how many bytes the payload consist of. 768 - 253: Indicates that there is an extra byte for payload length, 769 with the actual length value equal to the last byte value plus 770 252. 772 - 254: Indicates that there is an extra two bytes for payload 773 length, with the actual length value obtained from the second 774 and third bytes interpreted as a 16 bits unsigned integer plus 775 252 (from the first byte). 777 - 255: Reserved. 779 * I/O: Indicates whether this packet is destined to a inner-domain 780 node (value '1') or an outer-domain node (value '0'), where the 781 former means from an NSA or IPv6 node to a NSA destination, while 782 the latter means to an external IPv6 node. 784 * MA: Indicates the source address is actually a Mapped Address 785 generated by the root. When it is '1', the source address of the 786 packet is a mapped address of an external IPv6 address, while if 787 it is '0', the source address of the packet is an NSA address. 789 For length variable native short address encoding, for both Source 790 Address (SA) and Destination Address (DA), the definition is: 792 * 0~252: if the address value locates in this interval, one byte is 793 used to encode the value 795 * 253: indicates that the following 2 bytes encode the address. 797 * 254: indicates that the following 4 bytes encode the address. 799 * 255: indicates that the following byte defines the length of 800 address in bytes, followed by the address bytes. 802 The sequence of in-line fields is as per [RFC8200] section 3. 804 8. NSA Control Message 806 8.1. New Control Message 808 This documents specifies only one new NSA Control Message, namely the 809 NSA Mapped Address Advertisement described in Section 4. The purpose 810 of such a message is advertise the mapping of an IPv6 address into a 811 NSA address. The map is performed by the root node and sent to the 812 node originating the communication. The root keeps a copy of the 813 mapping to be used for future packets. The format is as follows: 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type | Code = 0x00 | Reserved | NSA Length | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | | 821 | Target IPv6 Address (Fixed length 128 bist) | 822 | | 823 | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Target NSA Address (Variable length) .... | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 * Type: Type value identifying NSA Control Message. Value to be 829 assigned by IANA (cf. Section 9) 831 * Code: This field identifies the specific control message. In this 832 case it is set to the value 0x00 "NSA Mapped Address for External 833 IPv6 Address". 835 * Reserved: Set as 0 on transmission and ignored on reception. 837 * NSA Length: This field indicates the length of the Target NSA 838 Address at the end of the message, expressed in bytes. 840 The "NSA Mapped Address for External IPv6 Address" is a variable 841 length message, however, the first five fields of the message, namely 842 Type, Code Reserved, NSA Length, and Target IPv6 address, have a 843 fixed length of 160 bits (20 bytes), hence the length of the NSA 844 address is sufficient to calculate the length of the entire packet: 845 20 bytes + "NSA length". 847 8.2. Address Configuration based on 6LOWPAN-ND 849 According to [rfc6775], neighbor discovery is available in 6LoWPANs. 850 This document specifies NSA address configuration mechanism based on 851 RS (Router Solicitation) and solicited RA (Router Advertisement) 852 defined in [RFC4861]. In order for an NSA node to request an 853 address, it uses a newly defined 'Request Address Option (NRAO)' in 854 RS messages. The corresponding solicited RA will contain the 'NSA 855 Assign Address Option (NAAO)' with the assigned address. 857 8.2.1. NSA Request Address Option (NRAO) Format 859 This option will be carried in RS messages [RFC4861] when node 860 initializes. The same RS messages MUST carry the Source Link-Layer 861 Address Option (SLLAO) ([RFC4861], [RFC6775]) as well. The link- 862 layer address in SLLAO (Source Link-Layer Address Option will be used 863 to identify unique NSA node. The NRAO format is defined as follows: 865 +---------------+--------------+-------------------------------+ 866 | Type | Length | Expected Address Lifetime | 867 +---------------+--------------+-------------------------------+ 868 | Reserved | 869 +--------------------------------------------------------------+ 871 * Type: 136 873 * Length: 8-bit unsigned integer. The length of the option 874 (including the Type and Length fields) in units of 8 bytes. Be 875 always 1. 877 * Expected Address Lifetime: The sender of RS notify the node that 878 assigns the address for how long is expected to be valid. The 879 receiver may ignore this field. The unit is 1 second. This field 880 should be set to zero by sender if there is no requirement on the 881 lifetime. 883 * Reserved: These fields are unused. They MUST be initialized to 884 zero by the sender and MUST be ignored by the receiver. 886 8.2.2. NSA Assign Address Option (NAAO) Format 888 This option will be carried in RA message solicited by the an RS 889 message as for the usual Neighbor Discovery workflow. The NAAO 890 format is defined as follows: 892 +---------------+--------------+-------------------------------+ 893 | Type | Length | Address Lifetime | 894 +---------------+--------------+-------------------------------+ 895 | Prefix Length | Reserved | 896 +---------------+----------------------------------------------+ 897 | | 898 | | 899 | | 900 | NSA with IPv6 Prefix | 901 | | 902 | | 903 | | 904 +--------------------------------------------------------------+ 906 * Type: 137 908 * Length: 8-bit unsigned integer. The length of the option 909 (including the Type and Length fields) in units of 8 bytes. Be 910 always 3. 912 * Address Lifetime: The maximum seconds for the NSA being valid. 913 The node with this address MUST stop using this address for packet 914 transmission when the life time expires. When the Address 915 Lifetime is zero, the node must drop the address immediately. 916 When the lifetime field is 0xFFFF, the address will be valid 917 forever until the node sends another NAAO to update the lifetime. 919 * Prefix Length: This field will notify the receiver the length of 920 the the IPv6 prefix. 922 * Reserved: These fields are unused. They MUST be initialized to 923 zero by the sender and MUST be ignored by the receiver. 925 * NSA with IPv6 Prefix:This field is filled by the node with the 926 IPv6 prefix (according with the length field), the NSA address as 927 the least significant bit of the IPv6 address, and filling the 928 remaining bits in the middle with zeros. 930 9. IANA Considerations 932 9.1. Dispatch Type Field 934 This document requires IANA to assign the range 01010000 to 01011111 935 in page 10 of the "Dispatch Type Field" registry as follows: 937 +-------------+----+-----------------------------+---------------+ 938 | Bit Pattern |Page| Header Type | Reference | 939 +-------------+----+-----------------------------+---------------+ 940 | 0101TTNH | 10 | LOWPAN NSA IP(LOWPAN_NIP) |[This Document]| 941 +-------------+----+-----------------------------+---------------+ 943 Figure 8: LOWPAN Dispatch Type Field requested allocation 945 9.2. Allocation Function Registry 947 This section provides guidance to the Internet Assigned Numbers 948 Authority (IANA) regarding registration of values related to the NSA 949 specification, in accordance with BCP 26 [RFC8126]. 951 IANA is asked to create a registry named "Native Short Addresses 952 (NSA) Parameters". 954 Such registry should be populated with a one byte sub registry named 955 "Allocation Function" and used to identify the AF used in a NSA 956 deployment. The sub registry is populated as follows: 958 +---------+----------------------------+-----------------+ 959 | Value | AF Name | Reference | 960 +---------+----------------------------+-----------------+ 961 | 0x00 | Native Allocation Function | [This Document] | 962 +---------+----------------------------+-----------------+ 963 |0x01-0xFF| Un-assigned | | 964 +---------+----------------------------+-----------------+ 966 Values can be assigned by IANA on a "First Come, First Served" basis 967 according to [RFC8126]. 969 9.3. ICMP NSA Control Message 971 IANA is requested to allocate an ICMPv6 type value from the "ICMPv6 972 Parameters" registry to be used by "NSA Control Message". 974 Also IANA is requested to create an "NSA Control Codes" sub registry, 975 for the Code field of the ICMPv6 NSA Control Message. 977 New codes may be allocated through the "Specification Required" 978 procedure as defined in [RFC8126]. The following code is currently 979 defined (the others are to be marked as un-assigned): 981 +------+--------------------------------------------+---------------+ 982 | Code | Description | Reference | 983 +------+--------------------------------------------+---------------+ 984 | 0x00 |NSA Mapped Address for External IPv6 Address|[This Document]| 985 +------+--------------------------------------------+---------------+ 987 9.4. NSA Neighbor Discovery Options 989 IANA is requested to allocate two values from the "IPv6 Neighbor 990 Discovery Option Formats" registry to be used by NRAO and NAAO. 992 +------+--------------------------------------------+---------------+ 993 | Code | Description | Reference | 994 +------+--------------------------------------------+---------------+ 995 | 136 | NSA Request Address Option |[This Document]| 996 +------+--------------------------------------------+---------------+ 997 | 137 | NSA Assign Address Option |[This Document]| 998 +------+--------------------------------------------+---------------+ 1000 10. Security Considerations 1002 An extended security analysis will be provided in future revision of 1003 this document. As of this point we consider that the security 1004 considerations of [RFC4944], [RFC6282] apply. 1006 11. References 1008 11.1. Normative References 1010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1011 Requirement Levels", BCP 14, RFC 2119, 1012 DOI 10.17487/RFC2119, March 1997, 1013 . 1015 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1016 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1017 December 1998, . 1019 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1020 "Transmission of IPv6 Packets over IEEE 802.15.4 1021 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1022 . 1024 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1025 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1026 DOI 10.17487/RFC6282, September 2011, 1027 . 1029 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1030 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1031 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1032 Low-Power and Lossy Networks", RFC 6550, 1033 DOI 10.17487/RFC6550, March 2012, 1034 . 1036 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1037 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1038 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1039 . 1041 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1042 Writing an IANA Considerations Section in RFCs", BCP 26, 1043 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1044 . 1046 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1047 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1048 May 2017, . 1050 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1051 (IPv6) Specification", STD 86, RFC 8200, 1052 DOI 10.17487/RFC8200, July 2017, 1053 . 1055 11.2. Informative References 1057 [I-D.ietf-6lo-use-cases] 1058 Hong, Y., Gomez, C., Choi, Y., Sangi, A. R., and S. 1059 Chakrabarti, "IPv6 over Constrained Node Networks (6lo) 1060 Applicability & Use cases", Work in Progress, Internet- 1061 Draft, draft-ietf-6lo-use-cases-12, 25 January 2022, 1062 . 1065 [LEE10] Lee, M., Zhang, R., Zheng, J., Ahn, G., Zhu, C., Park, T., 1066 Cho, S., Shin, C., and J. Ryu, "IEEE 802.15.5 WPAN mesh 1067 standard-low rate part: Meshing the wireless sensor 1068 networks", IEEE Journal on Selected Areas in 1069 Communications Vol. 28, pp. 973-983, 1070 DOI 10.1109/jsac.2010.100902, September 2010, 1071 . 1073 [LPWAN] "IPv6 over Low Power Wide-Area Networks (lpwan) WG", n.d., 1074 . 1076 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1077 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1078 . 1080 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1081 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1082 DOI 10.17487/RFC4861, September 2007, 1083 . 1085 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1086 Bormann, "Neighbor Discovery Optimization for IPv6 over 1087 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1088 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1089 . 1091 [rfc6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1092 Bormann, "Neighbor Discovery Optimization for IPv6 over 1093 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1094 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1095 . 1097 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1098 "IPv6 over Low-Power Wireless Personal Area Network 1099 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1100 April 2017, . 1102 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1103 Zuniga, "SCHC: Generic Framework for Static Context Header 1104 Compression and Fragmentation", RFC 8724, 1105 DOI 10.17487/RFC8724, April 2020, 1106 . 1108 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1109 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1110 . 1112 [SIXLO] "IPv6 over Networks of Resource-constrained Nodes (6lo) 1113 WG", n.d., . 1115 [SIXLOWPAN] 1116 "IPv6 over Low power WPAN (6lowpan) - Concluded WG", n.d., 1117 . 1119 [ZigBee] "ZigBee Wireless Networks and Transceivers", 1120 Elsevier book, DOI 10.1016/b978-0-7506-8393-7.x0001-5, 1121 2008, 1122 . 1124 Authors' Addresses 1126 Guangpeng Li 1127 Huawei Technologies 1128 Beiqing Road, Haidian District 1129 Beijing 1130 100095 1131 China 1132 Email: liguangpeng@huawei.com 1133 David Lou 1134 Huawei Technologies Duesseldorf GmbH 1135 Riesstrasse 25 1136 80992 Munich 1137 Germany 1138 Email: zhe.lou@huawei.com 1140 Luigi Iannone 1141 Huawei Technologies France S.A.S.U. 1142 18, Quai du Point du Jour 1143 92100 Boulogne-Billancourt 1144 France 1145 Email: luigi.iannone@huawei.com 1147 Peng Liu 1148 China Mobile 1149 No. 53, Xibianmen Inner Street, Xicheng District 1150 Beijing 1151 100053 1152 China 1153 Email: liupengyjy@chinamobile.com 1155 Rong Long 1156 China Mobile 1157 No. 53, Xibianmen Inner Street, Xicheng District 1158 Beijing 1159 100053 1160 China 1161 Email: longrong@chinamobile.com