idnits 2.17.00 (12 Aug 2021) /tmp/idnits32515/draft-jia-flex-ip-address-structure-00.txt: -(572): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8799]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (31 October 2020) is 560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Length' is mentioned on line 403, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Jia 3 Internet-Draft Z. Chen 4 Intended status: Standards Track S. Jiang 5 Expires: 4 May 2021 Huawei 6 31 October 2020 8 Flexible IP: An Adaptable IP Address Structure 9 draft-jia-flex-ip-address-structure-00 11 Abstract 13 Along as the popularization and adoption of IP in emerging scenarios, 14 challenges emerge as well due to the ossified address structure. To 15 enable TCP/IP in networks that previously using exclusive protocol, a 16 flexible address structure would be far more preferred for their 17 particular properties 18 [draft-jia-scenarios-flexible-address-structure]. 20 This document describes a flexible address structure -- Flexible IP 21 (FlexIP) acting on limited domains [RFC8799]. FlexIP is expected to 22 proactively adapt scenarios under flexible address structure. 23 Meanwhile, FlexIP still benefit from global reachability based on the 24 IPv6 interoperability. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 4 May 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Targeted Scenario . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Multi-Semantics . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Elastic Address Space . . . . . . . . . . . . . . . . . . 6 65 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.4. Interoperability . . . . . . . . . . . . . . . . . . . . 7 67 5. FlexIP Address structure . . . . . . . . . . . . . . . . . . 7 68 5.1. Restrained Space Format . . . . . . . . . . . . . . . . . 8 69 5.2. Extendable Space Format . . . . . . . . . . . . . . . . . 8 70 5.3. Hierarchical Segments Format . . . . . . . . . . . . . . 9 71 5.4. Multi-Semantics Format . . . . . . . . . . . . . . . . . 9 72 6. FlexIP Address Text Representation . . . . . . . . . . . . . 10 73 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 10. Informative References . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 As Internet Protocol (IP) gradually turned into the "waist" of the 82 "TCP/IP" protocol stack, it is considered to be the core pillar of 83 the entire Internet [waist]. Although numerous technologies in this 84 "TCP/IP" protocol stack have emerged, evolved, or obsoleted by 85 others, the IPv6 technology [RFC8200] is the only forward in network 86 layer along with the Internet upgrades. IPv6, as the unique 87 successor of IPv4 [RFC0791] defined by IETF, fixes defects for most 88 of its parts. Most notably, the address space is enormously expanded 89 from 32-bit to 128-bit in IPv6 reformation. Despite that IPv6 is 90 expected to serve almost infinite devices in the foreseeable future, 91 several scenarios are found in trouble when IPv6 is in use. 93 For instance, due to the market and cost requirements, numerous 94 Internet-of-things (IoTs) are devised to be tiny and resource 95 constrained. However, such rigorous requirement induce manufactures 96 to adopt lightweight protocols like bluetooth, other than TCP/IP, for 97 inter communications [iot]. Energy consumption, which is sound in 98 most terminal cases, becomes the greatest challenge when introducing 99 IPv6 to IoTs. Document 100 [draft-jia-scenarios-flexible-address-structure] details the 101 challenges for more cases of IPv6. 103 To conquer these challenges, several improvements are promoted by the 104 corporation of related standard organizations. Document [RFC4944] 105 depict the transmission of IPv6 over IEEE 802.15.4 network, and such 106 a method enables indirectly support of IPv6 in IoTs, e.g., Thead 107 Protocol [thread]. Besides, document [RFC7668] describe the fusion 108 of IPv6 and Bluetooth Low Energy, and such a method also enable the 109 communications among nodes with Bluetooth and IPv6. Although none of 110 these proposal is superior on the basis of market sharing, all 111 endeavour orientate to the comprehensive adoption of TCP/IP protocol 112 stack in new communication cases. 114 This document proposes an adaptive IP address format -- Flexible IP 115 (abbr. FlexIP) orienting emerging scenarios 116 [draft-jia-scenarios-flexible-address-structure] within limited 117 domains [RFC8799], and maintain global reachability with IPv6. In 118 general, FlexIP is composed through a hierarchical, self-explanatory 119 address structure. Compared to the patch-like solutions (e.g., 120 [RFC4944], [RFC8724]) that passively tune IP to be compatible with 121 different scenarios, FlexIP proactively makes address structure 122 flexible enough to adapt to various network cases. This variation, 123 opposite to the fixed form of IPv4/IPv6 address, is expected to make 124 Internet Protocol agilely cover futuristic and unknown scenarios. 126 //TODO: more citations needed. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Targeted Scenario 138 As a architectural solution for scenarios detailed in 139 [draft-jia-scenarios-flexible-address-structure], FlexIP is expected 140 to be adopted in limited domains [RFC8799]. According to the 141 definition in [RFC8799], limited domain refers to a single physical 142 network attached to or running in parallel with the Internet, or a 143 defined set of users and nodes distributed over a much wider area, 144 but drawn together by a single virtual network over the Internet. 145 Within the limited domains, requirements, behaviors, and semantics 146 could be noticeable local and network specific. 148 Figure 1 depicts the orientation of FlexIP in IPv6 and Internet. 149 Generally, Internet with its backbone is principally composed by 150 IPv6, and networks with IPv4 are recognized as legacy and attached at 151 the edge of the Internet with transition mechanisms. The position of 152 networks with FlexIP structure is quite similar as IPv4. For 153 networks within limited domains, FlexIP can be marginally adopted at 154 the edge of the Internet. Such network use FlexIP to fulfill 155 proprietary capabilities, while retain global reachability through 156 IPv6 via transition. 158 ......... 159 ......... ->Attaching Point 160 ||||||||| / 161 ||||||+--+ +----------------+ 162 ||<----------------------+ Google Network | 163 ||||||+--+ | IPv6 | 164 ||||||||| +----------------+ 165 ||||||||| ->Translator 166 ||||||||| / 167 ||||||+--+ /-\ +----------------+ 168 ||||||<------------------+ Legacy Network | 169 ||||||+--+ \-/ | IPv4 | 170 ||||||||| +----------------+ 171 ||||||||| 172 ||||||||| 173 ||||||+--+ +-------------------+ 174 |<--------------------+ Microsoft Network | 175 ||||||+--+ | IPv6 | 176 ||||||||| +-------------------+ 177 ||||||||| 178 ||||||||| 179 ||||||+--+ +----------------+ 180 |||<---------------------+ Amazon Network | 181 ||||||+--+ | IPv6 | 182 ||||||||| +----------------+ 183 ||||||||| 184 ||||||||| ... ... 185 ||||||||| ->Translator 186 ||||||||| / 187 ||||||+--+ /-\ +------------------------+ 188 ||||<-------------+ Limited Domain Network | 189 ||||||+--+ \-/ | FlexIP | 190 ||||||||| +------------------------+ 191 ||||||||| e.g., factory network 192 ||||||||| 193 ||||||||| 194 |||||||........IPv6 Internet Backbone 195 ||||||||| 196 ......... 198 Figure 1: Position for FlexIP in IPv6 Internet 200 4. Design Considerations 202 As described in document 203 [draft-jia-scenarios-flexible-address-structure], various address 204 semantics and variable address length are main characteristics for a 205 flexible IP. However, several principles must be considered from the 206 top if such featured address structure become truly practicable. 207 Points below details overall considerations and plannings behind 208 FlexIP. 210 4.1. Multi-Semantics 212 For networks with advanced routing, non-topological identifiers could 213 be necessary for reachability [RFC7476]. To enrich routing abilities 214 in complex network, address structure should be flexible enough to 215 accommodate multiple semantics and related identifiers, thus 216 forwarding nodes within the network can dealing with these complex 217 address according based on the routing system built. 219 Ideally, devices that resided in advanced networks construct special 220 address format for customized routing, while devices that resided in 221 conventional scenario can adopt IPv6 as routine (topology semantic) 222 address. 224 4.2. Elastic Address Space 226 The primary orientation of FlexIP is to adapt different network 227 scale, and each network uses different address length that best fit 228 the presumptive scale. The alterable address length refers to a 229 flexible address space, and such resilience makes IP highly adaptable 230 to theoretically infinite space as well as tailored space 231 specifically for low power scenarios. 233 Ideally, Autonomous System (AS) that composing the Internet is 234 constituted by numerous networks. Each of the network hold the 235 flexible address space that best fit their scenarios. 237 4.3. Scalability 239 A constrained space is impossible to accommodate communications among 240 volume devices, while boundless space is unsustainable due to the 241 explosion of global routing table. To makes the flexibility truly 242 values, FlexIP must reach a balance between rigorous requirements of 243 expansive address space and efficient routing performance. 245 Ideally, the address should be expanded to boundless space, while the 246 structure guarantees the performance of fast forwarding. 248 4.4. Interoperability 250 FlexIP network is designed to be an attached network at edges of the 251 Internet, thus interoperability is needed between IPv6 and FlexIP. 252 Based on the interoperability, FlexIP, on the one hand, can benefit 253 from the advanced network abilities and adapt to new scenarios. On 254 the other hand, global reachability from IPv6 Internet makes the 255 network truly values and convenient for realistic use. 257 Ideally, a translator module is needed wherever a boundary across 258 FlexIP networks and IPv6 networks. The translator depicted in 259 Figure 1 gives a brief architectural instance for interoperability. 261 5. FlexIP Address structure 263 In general, FlexIP is composed through a hierarchical, self- 264 explanatory address structure. Such hierarchical, self-explanatory 265 address structure brings FlexIP elastic address space and multi- 266 semantics without sacrificing scalability. Table 1 details the 267 structure of the FlexIP address structure. 269 +========+=================+================================+ 270 | Index | Type | Structure (default by topology | 271 | | | semantic and 1 segment) | 272 +========+=================+================================+ 273 | 0x01 | Restrained | topology address - address 1 | 274 | | Space | | 275 +--------+-----------------+--------------------------------+ 276 | 0x02 | Restrained | topology address - address 2 | 277 | | Space | | 278 +--------+-----------------+--------------------------------+ 279 | ... | ... | ... | 280 +--------+-----------------+--------------------------------+ 281 | 0xEF | Restrained | topology address - address 239 | 282 | | Space | | 283 +--------+-----------------+--------------------------------+ 284 | 0xF0 | Extendable | followed by address with | 285 | | Space | 16-bit length | 286 +--------+-----------------+--------------------------------+ 287 | 0xF1 | Extendable | followed by address with | 288 | | Space | 32-bit length | 289 +--------+-----------------+--------------------------------+ 290 | 0xF2 | Extendable | followed by address with | 291 | | Space | 64-bit length | 292 +--------+-----------------+--------------------------------+ 293 | 0xF3 | Extendable | followed by address with | 294 | | Space | 128-bit length | 295 +--------+-----------------+--------------------------------+ 296 | 0xF4 | Extendable | followed by address with | 297 | | Space | 256-bit length | 298 +--------+-----------------+--------------------------------+ 299 | 0xF5 | Extendable | followed by address with X-bit | 300 | | Space | length | 301 +--------+-----------------+--------------------------------+ 302 | 0xF6 | Hierarchical | followed by address with 2 | 303 | | Segments | segments | 304 +--------+-----------------+--------------------------------+ 305 | 0xF7 | Hierarchical | followed by address with 3 | 306 | | Segments | segments | 307 +--------+-----------------+--------------------------------+ 308 | 0xF8 | Hierarchical | followed by address with Y | 309 | | Segments | segments | 310 +--------+-----------------+--------------------------------+ 311 | 0xF9 | Multi-Semantics | followed by Non-topological | 312 | | | semantic address | 313 +--------+-----------------+--------------------------------+ 314 | 0xFA - | None | reserved | 315 | 0xFF | | | 316 +--------+-----------------+--------------------------------+ 318 Table 1: Flexible IP Address Structure 320 Shapes in Table 1 describes the formal representation of FlexIP and 321 should be used in programing. Text representation of FlexIP is 322 described in Section 6. Particularly, formal representation of 323 FlexIP in this document introduces "/" for readability only. Such 324 "/" MUST be omitted in practical use. 326 5.1. Restrained Space Format 328 The first address format is called restrained space format and 329 specific for small address space. Such format includes a 1-byte 330 space customized for constrained resource devices. Structure in such 331 format guarantees that within FlexIP structure, devices can reach the 332 shortest address length under variable length structure and pursuit 333 the maximal routing efficiency. 335 5.2. Extendable Space Format 337 The second address format is called extendable space format. By 338 adopting such format, administrator can choose address length that 339 best fit the network. 341 Specifically, for networks larger than 239 address space, a 16-bit, 342 32-bit, 64-bit, 128-bit, and 256-bit can be used by the network with 343 Index F0-F4, respectively, and then followed by address itself. 344 Particular, a IPv6 (128-bit) address is regarded as a special indexed 345 by Index F3. 347 For networks prefer a customized space, a 1-byte LenIndex is emerged 348 between Index and the address. Structure in such format ensures that 349 address space becomes theoretically elastic and boundless. For 350 example, a 56-bit address is presented by F5/07/3B3A297F50C24F under 351 FlexIP structure. Sequence value 07 refers to the 7-byte (56-bit) 352 address length. 354 5.3. Hierarchical Segments Format 356 The third address format is called hierarchical segments format. By 357 adopting such format, an FlexIP address is composed by multiple 358 segments. Logically, a segment inside the address could be 359 considered as an individual routing identifier. Thus within 360 different routing areas, routers on the path should forward packets 361 based on the exclusive segment. The partitioning of the address 362 logically splits the large address into several routing segment, and 363 segments are regarded small enough that packets flowing in separate 364 networks could be forwarded efficiently according to the segments. 365 For this reason, structure in such hierarchy format ensures the 366 practicability with boundless space. 368 Taking an 2-segment address as an example, FlexIP F6/C8/F1/20C12AF2 369 present a 8-bit segment C8 and a 32-bit segment 220C12AF2, where 370 index F6 indicates the 2 segments behind. 372 5.4. Multi-Semantics Format 374 The forth address format is called multi-semantics format. For 375 address adopting such format, networks can forward packets based on 376 the specific semantics. 378 Under such format, a 1 byte SemIndex is used as the indication of 379 semantic when Index equal to F9. Taking the satellite network 380 [space-routing] as an example, FlexIP F9/01/F2/A32F84C981002E9B can 381 refer to a geographic position embedded address, where 01 refers to 382 the geographic semantic, and F2 refers to a 64-bit address length. 383 Similarly, such pattern can be used for name based routing [ndn], 384 user based routing, or service based routing. 386 Given that non-topological semantics and addressing are still under 387 open study, specifications for non-topological semantics will be 388 depicted in independent documents when technics become mature. 390 6. FlexIP Address Text Representation 392 Literally, text representation of FlexIP should be human friendly 393 compared to the formal representation in Section 5. Considering text 394 representation would be used in extensive written places, FlexIP is 395 such representation should be eminently readable. 397 This document RECOMMENDED text representation of FlexIP through 398 following structure: 399 [Length]_Value_[Length]_Value_...[Length]_Value_. 400 Generally, FlexIP address is concatenated directly by multiple 401 segments. For each of the segment, the text representation is 402 composed by [Length]_Value_. Specifically, i.e., for components 403 inside an segment, [Length] refers to the length of current segment 404 with the Byte unit; 405 Then followed by , refers to the semantic the segment use. 406 Within a segment, is the only field can be omitted if segment 407 points to the default topology semantic -- . Last, _Value_ 408 refers to the address itself. Particularly, _Value_ inherits the 409 same text representation as IPv6 that recommended in [RFC5952]. 411 Table 2 depicts examples for FlexIP representation in text shape. 412 Noted that "/" in the formal representation is for readability only 413 and MUST be removed in practice. 415 +================================+==============================+ 416 | Formal Representation | Text Representation | 417 +================================+==============================+ 418 | C8 | [1]C8 | 419 +--------------------------------+------------------------------+ 420 | F1/2A00012F | [4]2A::12F | 421 +--------------------------------+------------------------------+ 422 | F5/07/3B3A297F50C24F | [7]3B:3A29:7F50:C24F | 423 +--------------------------------+------------------------------+ 424 | F6/C8/F2/2001000000012F | [1]C8[8]2001::12F | 425 +--------------------------------+------------------------------+ 426 | F8/04/F0/2F5B/F0/6A3C/F0/9C2B/ | [2]2F5B[2]6A3C[2]9C2B[2]735D | 427 | F0/735D | | 428 +--------------------------------+------------------------------+ 429 | F9/01/F2/A32F84C981002E9B | [8]A32F84C981002E9B | 430 +--------------------------------+------------------------------+ 432 Table 2: Examples of Flexible IP Address Text Representation 434 For example, [1]C8[8]2001::12F indicates two segments concatenation: 435 segment C8 with semantic and 1 byte length, and segment 436 200100000000012F with semantic and 8 byte length. Particular, 437 given that non-topological semantics and addressing are still under 438 open study, identification should be officially maintained in 439 IANA. 441 7. Interoperability 443 To enable global reachability and inter connectivity between FlexIP 444 network and IPv6 network, an translator is needed wherever packets 445 across the periphery. Figure 2 depicts the core component of the 446 translator, i.e., address mapper, and a sketch for packet traversing 447 from a FlexIP network to a IPv6 network. For any packet leave FlexIP 448 network and enter IPv6 network, the IP addresses of the packet should 449 be converted by rules configured in the mapper, and vice versa. 451 ......... ->Translator 452 |.|.|.|.| / 453 |.|.|.+---+ /-\ +------------------------+ 454 |.|.<-------------+ Limited Domain Network | 455 |.|.|.+---+ \-/ | FlexIP | 456 |.|.|.|.| | +------------------------+ 457 |.|.|.|.| | 458 |.|.|.|.| | 459 |.|.|.|.| | +-------------+ Rules 460 |.|.|.|.| | / | | Distribution 461 |.|.|.|.| +---------| | +---------+ | + 462 ......... \ | | Mapping | | | 463 | | Rules <--------+ 464 Internet | +----+----+ | 465 Backbone | | | 466 Packet | +----v----+ | Packet 467 +--------+ | | Mapping | | +--------+ 468 | IPv6 <----+ Engine <----+ FlexIP | 469 +--------+ | +---------+ | +--------+ 470 | Data | | | | Data | 471 | | | Address | | | 472 +--------+ | Mapper | +--------+ 473 +-------------+ 475 Figure 2: Network Address Mapping between FlexIP network and IPv6 476 network. 478 Specifically, there are two kind of mapping policy: stateful 479 recording and stateless transforming. Although both two policy is 480 effective for address mapping, stateless transforming is RECOMMENDED 481 for system efficiency and operation complexity. Concrete processes 482 of rules generation, distribution and mapping mechanisms are outside 483 the scope of this specification and should be documented 484 individually. 486 For FlexIP network with restrained space format Table 1, for 487 instance, a FlexIP C3 should be mapped into IPv6 2001::C3 when 488 affiliated packet flow across the periphery. Conversely, address 489 mapper can simply peel of the prefix 2001:: of when packets flow back 490 to FlexIP network. 492 8. Security Considerations 494 As a address format of IP, FlexIP address itself do not involve 495 security issues. While from the viewpoint of the transmission of 496 packets, FlexIP has security properties that are similar to IPv6. 497 These security issues include: 499 * Eavesdropping, where on-path elements can observe the whole packet 500 (including both contents and metadata) of each datagram. 502 * Replay, where the attacker records a sequence of packets off of 503 the wire and plays them back to the party that originally received 504 them. 506 * Packet insertion, where the attacker forges a packet with some 507 chosen set of properties and injects it into the network. 509 * Packet deletion, where the attacker removes a packet from the 510 wire. 512 * Packet modification, where the attacker removes a packet from the 513 wire, modifies it, and reinjects it into the network. 515 * Man-in-the-middle (MITM) attacks, where the attacker subverts the 516 communication stream in order to pose as the sender to receiver 517 and the receiver to the sender. 519 * Denial-of-service (DoS) attacks, where the attacker sends large 520 amounts of legitimate traffic to a destination to overwhelm it.ss 522 Specifically, there is not any mechanism for FlexIP to protect 523 against IP spoofing. Defending against these type of attacks is 524 outside the scope of this specification. 526 9. IANA Considerations 528 This document does not include an IANA request. 530 10. Informative References 532 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 533 DOI 10.17487/RFC0791, September 1981, 534 . 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 542 "Transmission of IPv6 Packets over IEEE 802.15.4 543 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 544 . 546 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 547 Address Text Representation", RFC 5952, 548 DOI 10.17487/RFC5952, August 2010, 549 . 551 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 552 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 553 "Information-Centric Networking: Baseline Scenarios", 554 RFC 7476, DOI 10.17487/RFC7476, March 2015, 555 . 557 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 558 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 559 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 560 . 562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 564 May 2017, . 566 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 567 (IPv6) Specification", STD 86, RFC 8200, 568 DOI 10.17487/RFC8200, July 2017, 569 . 571 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 572 Zúñiga, "SCHC: Generic Framework for Static Context Header 573 Compression and Fragmentation", RFC 8724, 574 DOI 10.17487/RFC8724, April 2020, 575 . 577 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 578 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 579 . 581 [draft-jia-scenarios-flexible-address-structure] 582 Jia, Y., Li, G., and S. Jiang, "Scenarios and Requirements 583 for Flexible Address structure", October 2020, 584 . 588 [iot] Jara, AJ., Ladid, L., and AF. Gomez-Skarmeta, "The 589 Internet of Everything through IPv6: An Analysis of 590 Challenges, Solutions and Opportunities", Networks 591 Ubiquitous Comput. Dependable Appl. 4(3): 97-118, 2013. 593 [ndn] Zhang, L., Afanasyev, A., and J. Burke, "Named data 594 networking", ACM SIGCOMM Computer Communication 595 Review 44(3): 66-73, 2014. 597 [space-routing] 598 Yang, Z., Li, H., Wu, Q., and J. Wu, "Analyzing and 599 optimizing BGP stability in future space-based internet", 600 International Performance Computing and Communications 601 Conference (IPCCC) , December 2017. 603 [thread] Thread Group, "Thread Specification", 604 . 606 [waist] Akhshabi, S. and C. Dovrolis, "The Evolution of Layered 607 Protocol Stacks Leads to an Hourglass-shaped 608 Architecture", Proceedings of the ACM SIGCOMM 2011 609 Conference 206-217, October 2011, 610 . 612 Authors' Addresses 614 Yihao Jia 615 Huawei Technologies Co., Ltd 616 156 Beiqing Rd. 617 Haidian, Beijing 618 100095 619 P.R. China 621 Email: jiayihao@huawei.com 622 Zhe Chen 623 Huawei Technologies Co., Ltd 624 156 Beiqing Rd. 625 Haidian, Beijing 626 100095 627 P.R. China 629 Email: chenzhe17@huawei.com 631 Sheng Jiang 632 Huawei Technologies Co., Ltd 633 156 Beiqing Rd. 634 Haidian, Beijing 635 100095 636 P.R. China 638 Email: jiangsheng@huawei.com