idnits 2.17.1 draft-jia-scenarios-flexible-address-structure-00.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 date (31 October 2020) is 1266 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 G. Li 4 Intended status: Informational S. Jiang 5 Expires: 4 May 2021 Huawei 6 31 October 2020 8 Scenarios for Flexible Address Structure 9 draft-jia-scenarios-flexible-address-structure-00 11 Abstract 13 Along as the adoption of TCP/IP in increasingly emerging scenarios, 14 challenges emerge as well due to the ossified address structure. To 15 still enable TCP/IP for networks that previously using exclusive 16 protocols, a flexible address structure would be highly preferred for 17 their particular properties. This document describes well-recognized 18 scenarios that typically require a flexible address structure, and 19 states the requirements of such flexible address structure. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 4 May 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Flexibility: Potential Orientation . . . . . . . . . . . . . 3 56 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Internet of Things (IoTs) . . . . . . . . . . . . . . . . 3 58 3.2. Satellite Network . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Dynamic Service and Resource . . . . . . . . . . . . . . 4 60 3.4. Policy-based Traffic Control . . . . . . . . . . . . . . 5 61 3.5. Robust Trust and Security . . . . . . . . . . . . . . . . 5 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Informative References . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 As the unified protocol of the network layer, Internet Protocol (IP) 71 constantly promotes the prosperity of the entire Internet. With the 72 success of TCP/IP protocol stack, IP is gradually replacing exclusive 73 protocols and becomes the core protocol of the entire communication 74 system. 76 Along as the popularization of TCP/IP, increasingly scenarios long 77 for a flexible address structure. To fulfill the reachability, IP 78 address is designed to hold the topology semantic only [RFC0791]. 79 While within limited domains (ref. [RFC8799]), a multi-semantic 80 address could be increasingly preferred in implementing complex 81 actions and capabilities for particular scenarios. Under such 82 circumstances, a flexible address structure can unleash more 83 possibilities in serving new scenarios. 85 This document describes well-recognized scenarios that typically 86 require a flexible address structure, and states the requirements of 87 such flexible address structure. 89 2. Flexibility: Potential Orientation 91 Since a flexible address is expected be adaptive with different 92 scenarios and routing abilities, 93 potentially orientations of a flexible address structure should 94 include multiple semantics. According to the definition of IP 95 structure [RFC1180], cyberspace topology location serves as the only 96 semantic of IP address. While for emerging scenarios in reality, 97 several semantics are expected for reachability, e.g., contents 98 [CONTENT-NET] or names [ndn]. To accommodate growing requirements of 99 futuristic scenarios, address with multi-semantic embedding should 100 compose the core of the flexibility. With the dynamic semantic 101 embedding, the length of the address should accordingly adaptive. 103 3. Scenarios 105 Although new scenarios are ever changing, they principally belong to 106 a fixed scene, i.e., limited domain [RFC8799]. Limited domain, which 107 first defined in [RFC8799], refers to a single physical network 108 attached to or running in parallel with the Internet, or a defined 109 set of users and nodes distributed over a much wider area, but drawn 110 together by a single virtual network over the Internet. Within the 111 limited domains, requirements, behaviors, and semantics could be 112 noticeable local and network specific. 114 As the dominant status of IP in networking coverage, more networks 115 attempt to adopt TCP/IP in their local networks. Instead of building 116 proprietary network, a TCP/IP stack network facilitates convenient 117 reachability via global Internet and reduces operating expense for 118 exclusive protocols. According to the location that the retrofit of 119 address structure taking effect, targeted scenes perfectly match the 120 demarcation of limited domain, i.e., a edge network attaching to 121 Internet. Thus for networks that seeking for IP convenience but 122 enhanced capabilities, limited domains are scenarios that flexible 123 address structure taking effect. 125 3.1. Internet of Things (IoTs) 127 In many IoT scenarios, a simple, low-cost communication network is 128 required, and there are limitations for network devices in 129 computational power, memory, and energy availability. In addition to 130 [IEEE.802.15.4], it can be seen that networks using link layer 131 technologies such as Z-Wave, BLE [BLE], DECT_ULE, MS/TP, NFC, and PLC 132 require end-to-end IPv6 protocols [RFC8200] to run on constrained 133 node networks. The IP protocol allows IoT devices with multiple 134 connection types to connect to each other or to other nodes on the 135 Internet. Generally, a group of IoT network devices form a 136 constrained node network at the edge, and IoT terminals connect to 137 these network devices for data transmission. Devices located on the 138 edge of this network and the Internet can act as gateway devices. To 139 ensure security and reliability, multiple gateways must be deployed. 140 IoT devices on the network can easily select one of gateways for 141 traffic to pass through. This type of network and IoT devices in the 142 network require as little computational power as possible, smaller 143 memory requirements, and better energy availability to reduce the 144 total cost of ownership of the network. 146 3.2. Satellite Network 148 In the future, the space-based Internet will provide global Internet 149 connections through satellite and station on the ground 150 interconnection. The low cost of satellite launch and the reduction 151 of the cost of network equipment will promote the development of 152 high-density satellite networks. With the convergence of space-based 153 networks and terrestrial networks, users can experience seamless 154 broadband access. Whatever on cruise ships, flights, and cars, users 155 can switch data communication services over Wi-Fi, cellular, or 156 satellite networks at any time. The network service provider will 157 plan the transmission path of user traffic based on the network 158 coverage, satellite orbit, route, and link load. The advantage of 159 long-distance transmission but shorter delay of space-based networks 160 is fully used to provide high-quality Internet connections for users 161 in areas not covered by terrestrial networks. There is a significant 162 difference between the high dynamics of satellite network and the 163 statics of terrestrial network topology. The traditional satellite 164 network cannot meet the preceding requirements through the networking 165 of the dedicated station on the ground. 167 3.3. Dynamic Service and Resource 169 In the future, the network will integrate services and resources from 170 various aspects such as life, production, and learning. Digitalized 171 services and resources are divided into multiple data blocks on the 172 network and multiple copies of data blocks exist, which will become 173 the basic mode. Access to services and resources through URIs has 174 been discussed by many researches, such as NDN [ndn] and ICN 175 [RFC7476]. In practice, the dynamic services and resource management 176 and access mechanisms of integrating ID and address technologies will 177 be more suited to user needs. Providers of services and resources 178 can publish online services and resources through unified identifiers 179 without additional planning of identifiers and locations for data and 180 their replicas. Users can access required services and resources in 181 the nearest and on-demand mode. Further, users can make a request 182 based on the type of service and resource and get a response to the 183 service or a copy of the data. 185 3.4. Policy-based Traffic Control 187 Policy-based traffic control is constantly far from flexible. To 188 restrict traffics for specific objects, e.g., devices, users, or 189 group of them, a current solution is subnet partition. 190 Representative technique for subnet partition includes VLAN [RFC5517] 191 and VxLAN [RFC7348]. However, such mechanism usually involve 192 numerous manual configuration, and even small changes in reality 193 could also result in a repartition or manual efforts. 195 According to the semantic of IP address forwarding, any inconvenience 196 of traffic control stems from the decoupling of address semantic and 197 policy objects. Since address content only present topology location 198 in IPv6, extra out-of-band effort is needed to partition network or 199 recognize traffic from target objects. 201 For address with objects identifier encoded, policy-based traffic 202 control could be almost automatic. For every node forwarding 203 traffic, object identity could be first extracted from both source 204 and destination address once packets arrive. Then by matching 205 objects and policy-based rules, nodes on the path could trigger 206 particular actions that dynamically assigned by administrators. For 207 examples, action permit, action deny, and action permit but low 208 priority. Particular, such action could also be applied from 209 security restriction. 211 3.5. Robust Trust and Security 213 A flexible semantic could be significate in constructing a trust and 214 secure communication. For example, Cryptographically Generated 215 Addresses (CGA) [RFC3972] embeds a truncated public key in the last 216 57-bit of IPv6 address. Even with a truncated key, authentication 217 and security is greatly enhanced within a IP network via asymmetric 218 cryptography and IPsec [RFC4301]. Similarly, Host Identity Protocol 219 (HIP) [RFC7401] refers such methodology and constructs a enhanced 220 TCP/IP stack. 222 Within a flexible address structure, any secure-related keys could be 223 intactly included in address structure without any information loss. 224 Under such condition, connection provided by such address could be 225 considered as absolute secure only if the cryptography involved is 226 secure. 228 4. Requirements 230 According to the capabilities for scenarios above, this section 231 extracts basic requirements for a flexible address structure. Points 232 below details the basal requirements. 234 * Multi-Semantics: Since semantics are the core of network routing, 235 multi-semantics compose the main capability of the flexible 236 address. 238 * Variable Address Length: As for networks with constrained devices, 239 short address becomes necessary for protocol adoption. While on 240 other hand, address space should be adequate enough to accommodate 241 numerous devices. 243 * IPv6 Interoperability: Without global reachability, a flexible 244 address would be the same as an exclusive protocol. In other 245 words, a flexible address should be valuable only it is inter- 246 operable with IPv6. 248 5. Security Considerations 250 This document introduces no new security considerations. 252 6. IANA Considerations 254 This document does not include an IANA request. 256 7. Informative References 258 [BLE] Bluetooth SIG Working Groups, "Bluetooth Specification", 259 . 261 [CONTENT-NET] 262 Choi, J., Han, J., and E. Cho, "A survey on content- 263 oriented networking for efficient content delivery", IEEE 264 Communications Magazine 2011, 49(3): 121-127, May 2011. 266 [IEEE.802.15.4] 267 IEEE 802.15 WPAN Task Group 4, "IEEE 802.15.4 - IEEE 268 Standard for Low-Rate Wireless Networks", May 2020, 269 . 271 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 272 DOI 10.17487/RFC0791, September 1981, 273 . 275 [RFC1180] Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180, 276 DOI 10.17487/RFC1180, January 1991, 277 . 279 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 280 RFC 3972, DOI 10.17487/RFC3972, March 2005, 281 . 283 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 284 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 285 December 2005, . 287 [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private 288 VLANs: Scalable Security in a Multi-Client Environment", 289 RFC 5517, DOI 10.17487/RFC5517, February 2010, 290 . 292 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 293 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 294 eXtensible Local Area Network (VXLAN): A Framework for 295 Overlaying Virtualized Layer 2 Networks over Layer 3 296 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 297 . 299 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 300 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 301 RFC 7401, DOI 10.17487/RFC7401, April 2015, 302 . 304 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 305 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 306 "Information-Centric Networking: Baseline Scenarios", 307 RFC 7476, DOI 10.17487/RFC7476, March 2015, 308 . 310 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 311 (IPv6) Specification", STD 86, RFC 8200, 312 DOI 10.17487/RFC8200, July 2017, 313 . 315 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 316 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 317 . 319 [ndn] Zhang, L., Afanasyev, A., and J. Burke, "Named data 320 networking", ACM SIGCOMM Computer Communication 321 Review 44(3): 66-73, 2014. 323 Authors' Addresses 324 Yihao Jia 325 Huawei Technologies Co., Ltd 326 156 Beiqing Rd. 327 Haidian, Beijing 328 100095 329 P.R. China 331 Email: jiayihao@huawei.com 333 Guangpeng Li 334 Huawei Technologies Co., Ltd 335 156 Beiqing Rd. 336 Haidian, Beijing 337 100095 338 P.R. China 340 Email: liguangpeng@huawei.com 342 Sheng Jiang 343 Huawei Technologies Co., Ltd 344 156 Beiqing Rd. 345 Haidian, Beijing 346 100095 347 P.R. China 349 Email: jiangsheng@huawei.com