idnits 2.17.1 draft-jia-intarea-scenarios-problems-addressing-03.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: ---------------------------------------------------------------------------- == 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 ([I-D.jia-intarea-internet-addressing-gap-analysis], [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 (6 March 2022) is 779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-trossen-rtgwg-impact-of-dlts-01 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-13 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-mn-11 == Outdated reference: A later version (-52) exists of draft-ietf-lisp-nexagon-19 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-02) exists of draft-jia-intarea-internet-addressing-gap-analysis-01 == Outdated reference: A later version (-63) exists of draft-templin-6man-aero-39 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group Y. Jia 3 Internet-Draft D. Trossen 4 Intended status: Informational L. Iannone 5 Expires: 7 September 2022 Huawei 6 N. Shenoy 7 R.I.T. 8 P. Mendes 9 Airbus 10 D. Eastlake 3rd 11 Futurewei 12 P. Liu 13 China Mobile 14 D. Farinacci 15 lispers.net 16 6 March 2022 18 Challenging Scenarios and Problems in Internet Addressing 19 draft-jia-intarea-scenarios-problems-addressing-03 21 Abstract 23 The Internet Protocol (IP) has been the major technological success 24 in information technology of the last half century. As the Internet 25 becomes pervasive, IP has been replacing communication technology for 26 many domain-specific solutions. However, domains with specific 27 requirements as well as communication behaviors and semantics still 28 exist and represent what [RFC8799] recognizes as "limited domains". 30 This document describes well-recognized scenarios that showcase 31 possibly different addressing requirements, which are challenging to 32 be accommodated in the IP addressing model. These scenarios 33 highlight issues related to the Internet addressing model and call 34 for starting a discussion on a way to re-think/evolve the addressing 35 model so to better accommodate different domain-specific 36 requirements. 38 The issues identified in this document are complemented and deepened 39 by a detailed gap analysis in a separate companion document 40 [I-D.jia-intarea-internet-addressing-gap-analysis]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 7 September 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Communication Scenarios in Limited Domains . . . . . . . . . 5 77 2.1. Communication in Constrained Environments . . . . . . . . 5 78 2.2. Communication within Dynamically Changing Topologies . . 7 79 2.3. Communication among Moving Endpoints . . . . . . . . . . 10 80 2.4. Communication Across Services . . . . . . . . . . . . . . 13 81 2.5. Communication Traffic Steering . . . . . . . . . . . . . 14 82 2.6. Communication with built-in security . . . . . . . . . . 15 83 2.7. Communication protecting user privacy . . . . . . . . . . 16 84 2.8. Communication in Alternative Forwarding Architectures . . 16 85 3. Desired Network Features . . . . . . . . . . . . . . . . . . 18 86 4. Issues in Addressing . . . . . . . . . . . . . . . . . . . . 21 87 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 23 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 92 8.2. Informative References . . . . . . . . . . . . . . . . . 25 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 96 1. Introduction 98 The Internet Protocol (IP), positioned as the unified protocol at the 99 (Internet) network layer, is seen by many as key to the innovation 100 stemming from Internet-based applications and services. Even more 101 so, with the success of TCP/IP protocol stack, IP has been gradually 102 replacing existing domain-specific protocols, evolving into the core 103 protocol of the entire communication eco-system. At its inception, 104 roughly 40 years ago [RFC0791], the Internet addressing system, 105 represented in the form of the IP address and its locator-based 106 (topological) semantics, has brought the notion of a 'common 107 namespace for all communication'. Compared to proprietary 108 technology-specific solutions, such 'common namespace for all 109 communication' advance ensures end-to-end communication from any 110 device connected to the Internet to another. 112 However, use cases, associated services, node behaviors, and 113 requirements on packet delivery have since been significantly 114 extended, with the Internet technology being developed to accommodate 115 them in the framework of addressing that stood at the beginning of 116 the Internet's development. This evolution is reflected in the 117 concept of "Limited Domains", first introduced in [RFC8799]. It 118 refers to a single physical network, attached to or running in 119 parallel with the Internet, or is defined by a set of users and nodes 120 distributed over a much wider area, but drawn together by a single 121 virtual network over the Internet. Key to a limited domain is that 122 requirements, behaviors, and semantics could be noticeable local and, 123 more importantly, specific to the limited domain. Very often, the 124 realization of a limited domain is defined by specific communication 125 scenario(s) and/or use case(s) that exhibit the domain-specific 126 behaviors and pose the requirements that lead to the establishment of 127 the limited domain. Identifying limited domains may sometime be not 128 obvious because of blurry boundaries depending on the point of view. 129 For instance, from an end user perspective there is no vision at all 130 on limited domains, hence for end users the dichotomy Internet vs 131 limited domains more transparent. In such cases, it is harder to 132 ensure (and detect) that no limited domain specific semantics leak in 133 the Internet or other limited domains. 135 One key architectural aspect, when communicating within limited 136 domains, is that of addressing and, therefore, the address structure, 137 as well as the semantic that is being used for packet forwarding 138 (e.g., service identification, content location, device type). The 139 topological location centrality of IP is fundamental when reconciling 140 the often differing semantics for 'addressing' that can be found in 141 those limited domains. The result of this fundamental role of the 142 single IP addressing is that limited domains have to adopt specific 143 solutions, e.g., translating/mapping/converting concepts, semantics, 144 and ultimately, domain-specific addressing, into the common IP 145 addressing used across limited domains. 147 This document advocates flexibility in addressing in order to 148 accommodate limited domain specific semantics, while, if possible, 149 ensuring a single holistic addressing scheme able to reduce, or even 150 entirely remove, the need for aligning the address semantics of 151 different limited domains, such as the current topological location 152 semantic of the Internet. Ultimately, such holistic addressing could 153 be beneficial to those communication scenarios realized within 154 limited domains by improving efficiency, removing of constraints 155 imposed by needing to utilize the limited semantics of IP addressing, 156 and/or in other ways. 158 In other words, this document revolves around the following question: 160 "Should interconnected limited domains purely rely on IP addresses 161 and therefore deal with the complexity of translating any semantic 162 mismatch themselves, or should flexibility for supporting those 163 limited domains be a key focus for an evolved Internet 164 addressing?" 166 To that end, this document describes well-recognized scenarios in 167 limited domains that could benefit from greater flexibility in 168 addressing and overviews the problems encountered throughout these 169 scenarios due to the lack of that flexibility. A detailed gap 170 analysis can be found in {I-D.jia-intarea-internet-addressing-gap- 171 analysis}}, which elaborates on the issues identified in this memo in 172 reference to extensions to Internet addressing that have attempted to 173 address those issues. The purpose of this memo is rather to 174 stimulate discussion on the emerging needs for addressing at large 175 with the possibility to fundamentally re-think the addressing in the 176 Internet beyond the current objectives of IPv6 [RFC8200]. 178 It is important to remark that any change in the addressing, hence at 179 the data plane level, leads to changes and challenges at the control 180 plane level, i.e., routing. The latter is an even harder problem 181 than just addressing and might need more research efforts that are 182 beyond the objective of this document, which focuses solely on the 183 data plane. 185 2. Communication Scenarios in Limited Domains 187 The following sub-sections outline a number of scenarios, all of 188 which belong to the concept of "limited domains" [RFC8799]. While 189 the list of scenarios may look long, this document focuses on 190 scenarios with a number of aspects that can be observed in those 191 limited domains, captured in the sub-section titles. For each 192 scenario, possible challenges are highlighted, which are then picked 193 upon in Section 4, when describing more formally the existing 194 shortcomings in current Internet addressing. 196 2.1. Communication in Constrained Environments 198 In a number of communication scenarios, such as those encountered in 199 the Internet of Things (IoT), a simple, communication network 200 demanding minimal resources is required, allowing for a group of IoT 201 network devices to form a network of constrained nodes, with the 202 participating network and end nodes requiring as little computational 203 power as possible and having small memory requirements in order to 204 reduce the total cost of ownership of the network. Furthermore, in 205 the context of industrial IoT, real-time requirements and scalability 206 make IP technology not naturally suitable as communication technology 207 ([OCADO]). 209 In addition to IEEE 802.15.4, i.e., Low-Rate Wireless Personal Area 210 Network [LR-WPAN], several limited domains exist through utilizing 211 link layer technologies such as Bluetooth Low Energy (BLE) [BLE], 212 Digital European Cordless Telecommunications (DECT) - Ultra Low 213 Energy (ULE) [DECT-ULE], Master-Slave/Token-Passing (MS/TP) [BACnet], 214 Near-Field-Communication (NFC) [ECMA-340], and Power Line 215 Communication (PLC) [IEEE_1901.1]. 217 The end-to-end principle (detailed in [RFC2775]) requires IP 218 addresses (e.g., IPv6 [RFC8200]) to be used on such constrained nodes 219 networks, allowing IoT devices using multiple communication 220 technologies to talk on the Internet. Often, devices located at the 221 edge of constrained networks act as gateway devices, usually 222 performing header compression ([RFC4919]). To ensure security and 223 reliability, multiple gateways must be deployed. IoT devices on the 224 network must select one of those gateways for traffic passthrough by 225 the devices on the (limited domain) network. 227 Given the constraints imposed on the computational and possibly also 228 communication technology, the usage of a single addressing semantic 229 in the form of a 128-bit endpoint identifier, i.e., IPv6 address, may 230 pose a challenge when operating such networks. 232 Another type of (differently) constrained environment is an aircraft, 233 which encompasses not only passenger communication but also the 234 integration of real-time data exchange to ensure that processes and 235 functions in the cabin are automatically monitored or actuated. The 236 goal for any aircraft network is to be able to send and receive 237 information reliably and seamlessly. From this perspective, the 238 medium with which these packets of information are sent is of little 239 consequence so long as there is a level of determinism to it. 240 However, there is currently no effective method in implementing 241 wireless inter- and intra-communications between all subsystems. The 242 emerging wireless sensor network technology in commercial 243 applications such as smart thermostat systems, and smart washer/dryer 244 units could be transposed onto aircraft and fleet operations. The 245 proposal for having an Wireless Avionics Intra-Communications (WAIC) 246 system promises reduction in the complexity of electrical wiring 247 harness design and fabrication, reduction in wiring weight, increased 248 configuration, and potential monitoring of otherwise inaccessible 249 moving or rotating aircraft parts. Similar to the IoT concept, WAIC 250 systems consist of short-range communications and are a potential 251 candidate for passenger entertainment systems, smoke detectors, 252 engine health monitors, tire pressure monitoring systems, and other 253 kinds of aircraft maintenance systems. 255 While there are still many obstacles in terms of network security, 256 traffic control, and technical challenges, future WAIC can enable 257 real-time seamless communications between aircraft and between ground 258 teams and aircraft as opposed to the discrete points of data 259 leveraged today in aircraft communications. For that, WAIC 260 infrastructure should also be connected to outside IP based networks 261 in order to access edge/cloud facilities for data storage and mining. 262 However, the restricted capacity (energy, communication) of most 263 aircraft devices (e.g. sensors) and the nature of the transmitted 264 data - periodic transmission of small packets - may pose some 265 challenges for the usage of a single addressing semantic in the form 266 of a 128-bit endpoint identifier, i.e., an IPv6 address. Moreover, 267 most of the aircraft applications and services are focused on the 268 data (e.g. temperature of gas tank on left wing) and not on the 269 topological location of the data source. This means that the current 270 topological location semantic of IP addresses is not beneficial for 271 aircraft applications and services. 273 Greater flexibility in Internet addressing may avoid complex and 274 energy hungry operations, like header compression and fragmentation, 275 necessary to translate protocol headers from one limited domain to 276 another, while enabling semantics different from locator-based 277 addressing may better support the communication that occurs in those 278 environments. 280 2.2. Communication within Dynamically Changing Topologies 282 Communication may occur over networks that exhibit dynamically 283 changing topologies. One such example is that of satellite networks, 284 providing global Internet connections through a combination of inter- 285 satellite and ground station communication. With the convergence of 286 space-based and terrestrial networks, users can experience seamless 287 broadband access, e.g., on cruise ships, flights, and within cars, 288 often complemented by and seamlessly switching between Wi-Fi, 289 cellular, or satellite based networks at any time [WANG19]. 291 The satellite network service provider will plan the transmission 292 path of user traffic based on the network coverage, satellite orbit, 293 route, and link load, providing potentially high-quality Internet 294 connections for users in areas that are not, or hard to be, covered 295 by terrestrial networks. With large scale LEO (Low Earth Orbit) 296 satellites, the involved topologies of the satellite network will be 297 changing constantly while observing a regular flight pattern in 298 relation to other satellites and predictable overflight patterns to 299 ground users [CHEN21]. 301 Although satellite bearer services are capable of transporting IPv4 302 and IPv6, as well as associated protocols such as IP Multicast, DNS 303 services and routing information, no IP functionality is implemented 304 on-board the spacecraft limiting the capability of leveraging for 305 instance large scale satellite constellations. 307 One of the major constraints of deploying routing capability on board 308 of a satellite is power consumption. Due to this, space routers may 309 end up being intermittently powered up during a daytime sunlit pass. 310 Another limitation of the first generation of IP routers in space was 311 the lack of capability to remotely manage and upgrade software while 312 in operation. 314 The limitations faced in early development of IP based satellite 315 communication payloads, showed the need to develop a flexible 316 networking solution that would enable delay tolerant communications 317 in the presence of intermittent connectivity. Further, in order to 318 reduce latency, which is the major impairment of satellite networks, 319 there was a need of a networking solution able to perform in a 320 scenario encompassing mobile devices with the capability of storing 321 data, leading to a significant reduction of latency, which is the 322 major impairment of satellite networks. 324 Moreover, due to the current IP addressing scheme and its focus on IP 325 unicast addressing with extended deployment of IP multicast and some 326 IP anycast, current deployments do not take advantage of the 327 broadcast nature of satellite networks. 329 Moreover networking platforms based on a name (data or service) based 330 addressing scheme would bring several potential benefits to satellite 331 networks aiming to tackle their major challenges, including high 332 propagation delay and changing network topology in the case of LEO 333 constellations. 335 Another example is that of vehicular communication, where services 336 may be accessed across vehicles, such as self-driving cars, for the 337 purpose of collaborative objection recognition (e.g., for collision 338 avoidance), road status conveyance (e.g., for pre-warning of road- 339 ahead conditions), and other purposes. Communication may include 340 Road Side Units (RSU) with the possibility to create ephemeral 341 connections to those RSUs for the purpose of workload offloading, 342 joint computation over multiple (vehicular) inputs, and other 343 purposes [I-D.ietf-lisp-nexagon]. Communication here may exhibit a 344 multi-hop nature, not just involving the vehicle and the RSU over a 345 direct link. Those topologies are naturally changing constantly due 346 to the dynamic nature of the involved communication nodes. 348 The advent of Flying Ad-hoc NETworks (FANETs) has opened up an 349 opportunity to create new added-value services [CHRIKI19]. Although 350 these networks share common features with vehicular ad hoc networks, 351 they present several unique characteristics such as energy 352 efficiency, mobility degree, the capability of swarming, and the 353 potential large scale of swarm networks. Due to high mobility of 354 FANET nodes, the network topology changes more frequently than in a 355 typical vehicular ad hoc network. From a routing point of view, 356 although ad-hoc reactive and proactive routing approaches can be 357 used, there are other type of routing protocols that have been 358 developed for FANETS, such as hybrid routing protocols and position 359 based routing protocols, aiming to increase efficiency in large scale 360 networks with dynamic topologies. 362 Both type of protocols challenge the current Internet addressing 363 semantic: in the case of hybrid protocols, two different routing 364 strategies are used inside and outside a network zone. While inside 365 a zone packets are routed to a specific destination IP address, 366 between zones, query packets are routed to a subset of neighbors as 367 determined by a broadcast algorithm. In the case of position based 368 routing protocol, the IP addressing scheme is not used at all, since 369 packets are routed to a different identifier, corresponding to the 370 geographic location of the destination and not its topological 371 location. Hence, what is needed is to consolidate the geo-spatial 372 addressing with that of a locator-based addressing in order to 373 optimize routing policies across the zones. 375 Moreover most of the application/services deployed in FANETs tend to 376 be agnostic of the topological location of nodes, rather focusing on 377 the location of data or services. This distinction is even more 378 important because is dynamic network such as FANET robust networking 379 solutions may rely on the redundancy of data and services, meaning 380 that they may be found in more than one device in the network. This 381 in turn may bring into play a possible service-centric semantic for 382 addressing the packets that need routing in the dynamic network 383 towards a node providing said service (or content). 385 In the aforementioned network technologies, there is a significant 386 difference between the high dynamics of the underlying network 387 topologies, compared to the relative static nature of terrestrial 388 network topology, as reported in [HANDLEY]. As a consequence, the 389 notion of a topological network location becomes restrictive in the 390 sense that not only the relation between network nodes and user 391 endpoint may change, but also the relation between the nodes that 392 form the network itself. This may lead to the challenge of 393 maintaining and updating the topological addresses in this constantly 394 changing network topology. 396 In attempts to utilize entirely different semantics for the 397 addressing itself, geographic-based routing, such as in [CARTISEAN], 398 has been proposed for MANETs (Mobile Ad-hoc NETworks) through 399 providing geographic coordinates based addresses to achieve better 400 routing performance, lower overhead, and lower latency [MANET1]. 402 Flexibility in Internet addressing here would allow for accommodating 403 such geographic address semantics into the overall Internet 404 addressing, while also enabling name/content-based addressing, 405 utilizing the redundancy of many network locations providing the 406 possible data. 408 2.3. Communication among Moving Endpoints 410 When packet switching was first introduced, back in the 60s/70s, it 411 was intended to replace the rigid circuit switching with a 412 communication infrastructure that was more resilient to failures. As 413 such, the design never really considered communication endpoints as 414 mobile. Even in the pioneering ALOHA [ALOHA] system, despite 415 considering wireless and satellite links, the network was considered 416 static (with the exception of failures and satellites, which fall in 417 what is discussed in Section 2.2). Ever since, a lot of efforts have 418 been devoted to overcome such limitations once it became clear that 419 endpoint mobility will become a main (if not THE main) characteristic 420 of ubiquitous communication systems. 422 The IETF has for a long time worked on solutions that would allow 423 extending the IP layer with mobility support. Because of the 424 topological semantic of IP addresses, endpoints need to change 425 addresses each time they visit a different network. However, because 426 routing and endpoint identification is also IP address based, this 427 leads to a communication disruption. 429 To cope with such a situation, sometimes, the transport layer gets 430 involved in mobility solutions, either by introducing explicit in- 431 band signaling to allow for communicating IP address changes (e.g., 432 in SCTP [RFC5061] and MPTCP [RFC6182]), or by introducing some form 433 of connection ID that allows for identifying a communication 434 independently from IP addresses (e.g., the connection ID used in QUIC 435 [RFC9000]). 437 Concerning network layer only solutions, anchor-based Mobile IP 438 mechanisms have been introduced ([RFC5177], [RFC6626] [RFC5944], 439 [RFC5275]). Mobile IP is based on a relatively complex and heavy 440 mechanism that makes it hard to deploy and it is not very efficient. 441 Furthermore, it is even less suitable than native IP in constrained 442 environments like the ones discussed in Section 2.1. 444 Alternative approaches to Mobile IP often leverage the introduction 445 of some form of overlay. LISP [I-D.ietf-lisp-introduction], by 446 separating the topological semantic from the identification semantic 447 of IP addresses, is able to cope with endpoint mobility by 448 dynamically mapping endpoint identifiers with routing locators 449 [I-D.ietf-lisp-mn]. This comes at the price of an overlay that needs 450 its own additional control plane [I-D.ietf-lisp-rfc6833bis]. 452 Similarly, the NVO3 (Network Virtualization Overlays) Working Group, 453 while focusing on Data Center environments, also explored an overlay- 454 based solution for multi-tenancy purposes, but also resilient to 455 mobility since relocating Virtual Machines (VMs) is common practice. 457 NVO3 considered for a long time several data planes that implement 458 slightly different flavors of overlays ([RFC8926], [RFC7348], 459 [I-D.ietf-intarea-gue]), but lacks an efficient control plane 460 specifically tailored for DCs. 462 Alternative mobility architectures have also been proposed in order 463 to cope with endpoint mobility outside the IP layer itself. The Host 464 Identity Protocol (HIP) [RFC7401] introduced a new namespace in order 465 to identify endpoints, namely the Host Identity (HI), while 466 leveraging the IP layer for topological location. On the one hand, 467 such an approach needs to revise the way applications interact with 468 the network layer, by modifying the DNS (now returning an HI instead 469 of an IP address) and applications to use the HIP socket extension. 470 On the other hand, early adopters do not necessarily gain any benefit 471 unless all communicating endpoints upgrade to use HIP. In spite of 472 this, such a solution may work in the context of a limited domain. 474 Another alternative approach is adopted by Information-Centric 475 Networking (ICN) [RFC7476]. By making content a first class citizen 476 of the communication architecture, the "what" rather than the "where" 477 becomes the real focus of the communication. However, as explained 478 in the next sub-section, ICN can run either over the IP layer or 479 completely replace it, which in turn can be seen as running the 480 Internet and ICN as logically completely separated limited domains. 482 Unmanned Aircraft Systems (UAS) are examples of moving devices that 483 require a stable mobility management scheme since they consist of a 484 number of Unmanned Aerial Vehicles (UAV) subordinated to a Ground 485 Control Station (GCS) [MAROJEVIC20]. The information produced by the 486 different sensors and electronic devices available at each UAV is 487 collected and processed by a software or hardware data acquisition 488 unit, being transmitted towards the GCS, where it is inspected and/or 489 analyzed. Analogously, control information transmitted from the GCS 490 to the UAV enables the execution of control operations over the 491 aircraft, such as changing the route planning or the direction 492 pointed by a camera. 494 Although UAVs may have redundant links to maintain communications in 495 long-range missions (e.g., satellite), most of the communications 496 between the GCS and the UAVs take place over wireless data links, 497 e.g., based on a radio line-of-sight technology, Wi-Fi or 3G/4G/5G. 498 While in some scenarios, UAVs will operate always under the range of 499 the same cellular base station, in missions with large range, UAVs 500 will move between different cellular or wireless ground 501 infrastructure, meaning that the UAV needs to upload its topological 502 locator and re-start the ongoing communication sessions. In such 503 cases, most of existing Mobile IP approaches may play a role, as well 504 as approaches to split the UAV identifier and the topological 505 locator, such as HIP. 507 However, while the industry is given the first steps towards evolved 508 UAS architectures and communication models, the data-centric 509 communication plays an increasing role, where information is named 510 and decoupled from its location, and applications/services operate 511 over these named data rather than on host-to-host communications. 513 In this context, the Data Distribution Service ([DDS]) has emerged as 514 an industry-oriented open standard that follows this approach. The 515 space and time decoupling allowed by DDS is very relevant in any 516 dynamic and distributed system, since interacting entities are not 517 forced to know each other and are not forced to be simultaneously 518 present to exchange data. Time decoupling can significantly simplify 519 the management of intermittent data-links, in particular for wireless 520 connectivity between UAS, as well as facilitate seamless UAV mobility 521 between GCSs. This model of communication, in turn, questions the 522 locator-based addressing used in IP and instead utilizes a data- 523 centric naming. 525 In the case of using TCP/IP, mobility of UAVs introduces a 526 significant challenge. Consider the case where a GCS is receiving 527 telemetry information from a specific UAV. Assuming that the UAV 528 moves and changes its point of attachment to the network, it will 529 have to configure a new IP address on its wireless interface. 530 However, this is problematic, as the telemetry information is still 531 being sent by to the previous IP address of the UAV. This simple 532 example illustrates the necessity to deploy mobility management 533 solutions to handle this type of situations. 535 However, mobility management solutions increase the complexity of the 536 deployment and may impact the performance of data distribution, both 537 in terms of signaling/data overhead and communication path delay. 538 Considering the specific case of multicast data streams, mobility of 539 content producers and consumers is inherently handled by multicast 540 routing protocols, which are able to react to changes of location of 541 mobile nodes by reconstructing the corresponding multicast delivery 542 trees. Nevertheless, this comes with a cost in terms of signaling 543 and data overhead (data may still flow through branches of a 544 multicast delivery tree where there are no receivers while the 545 routing protocol is still converging). 547 Another alternative is to perform the mobility management of 548 producers and consumers not at the application layer based on IP 549 multicast trees, but on the network layer based on an Information 550 Centric Network approach, which was already mentioned in this 551 section. 553 Greater flexibility in addressing may help in dealing with mobility 554 more efficiently, e.g., through an augmented semantic that may fulfil 555 the mobility requirements [RFC7429] in a more efficient way or 556 through moving from a locator- to a content or service-centric 557 semantic for addressing. 559 2.4. Communication Across Services 561 As a communication infrastructure spanning many facets of life, the 562 Internet integrates services and resources from various aspects such 563 as remote collaboration, shopping, content production as well as 564 delivery, education, and many more. Accessing those services and 565 resources directly through URIs has been proposed by methods such as 566 those defined in ICN [RFC7476], where providers of services and 567 resources can advertise those through unified identifiers without 568 additional planning of identifiers and locations for underlying data 569 and their replicas. Users can access required services and resources 570 by virtue of using the URI-based identification, with an ephemeral 571 relationship built between user and provider, while the building of 572 such relationship may be constrained with user- as well as service- 573 specific requirements, such as proximity (finding nearest provider), 574 load (finding fastest provider), and others. 576 While systems like ICN [CCN] provide an alternative to the 577 topological addressing of IP, its deployment requires an overlay 578 (over IP) or native deployment (alongside IP), the latter with 579 dedicated gateways needed for translation. Underlay deployments are 580 also envisioned in [RFC8763], where ICN solutions are being used to 581 facilitate communication between IP addressed network endpoints or 582 URI-based service endpoints, still requiring gateway solutions for 583 interconnection with ICN-based networks as well as IP routing based 584 networks (cf., [ICN5G][ICNIP]). 586 Although various approaches combining service and location-based 587 addressing have been devised, the key challenge here is to facilitate 588 a "natural", i.e., direct communication, without the need for 589 gateways above the network layer. 591 Another aspect of communication across services is that of chaining 592 individual services to a larger service. Here, an identifier would 593 be used that serves as a link to next hop destination within the 594 chain of single services, as done in the work on Service Function 595 Chaining (SFC). With this, services are identified at the level of 596 Layer 2/3 ([RFC7665], [RFC8754], [RFC8595]) or at the level of name- 597 based service identifiers like URLs [RFC8677] although the service 598 chain identification is carried as a Network Service header (NSH) 599 [RFC7665], separate to the packet identifiers. The forwarding with 600 the chain of services utilizes individual locator-based IP addressing 601 (for L3 chaining) to communicate the chained operations from one 602 Service Function Forwarder [RFC7665] to another, leading to concerns 603 regarding overhead incurred through the stacking of those chained 604 identifiers in terms of packet overhead and therefore efficiency in 605 handling in the intermediary nodes. 607 Greater flexibility in addressing may allow for incorporating 608 different information, e.g., service as well as chaining semantics, 609 into the overall Internet addressing. 611 2.5. Communication Traffic Steering 613 Steering traffic within a communication scenario may involve at least 614 two aspects, namely (i) limiting certain traffic towards a certain 615 set of communication nodes and (ii) restraining the sending of 616 packets towards a given destination (or a chain of destinations) with 617 metrics that would allow the selection among one or more possible 618 destinations. 620 One possibility for limiting traffic inside limited domains, towards 621 specific objects, e.g., devices, users, or group of them, is subnet 622 partition with techniques such as VLAN [RFC5517], VxLAN [RFC7348], or 623 more evolved solution like TeraStream [TERASTREAM] realizing such 624 partitioning. Such mechanisms usually involve significant 625 configuration, and even small changes in network and user nodes could 626 result in a repartition and possibly additional configuration 627 efforts. Another key aspect is the complete lack of correlation of 628 the topological address and any likely more semantic-rich 629 identification that could be used to make policy decisions regarding 630 traffic steering. Suitably enriching the semantics of the packet 631 address, either that of the sender or receiver, so that such decision 632 could be made while minimizing the involvement of higher layer 633 mechanisms, is a crucial challenge for improving on network 634 operations and speed of such limited domain traffic. 636 When making decisions to select one out of a set of possible 637 destinations for a packet, IP anycast semantics can be applied albeit 638 being limited to the locator semantic of the IP address itself. 640 Recent work in [SFCANYCAST] suggests utilizing the notion of IP 641 anycast address to encode a "service identifier", which is 642 dynamically mapped onto network locations where service instances 643 fulfilling the service request may be located. Scenarios where this 644 capability may be utilized are provided in [SFCANYCAST] and include, 645 but are not limited to, scenarios such as edge-assisted VR/AR, 646 transportation, smart cities, smart homes, smart wearables, and 647 digital twins. 649 The challenge here lies in the possible encoding of not only the 650 service information itself but the constraint information that helps 651 the selection of the "best" service instance and which is likely a 652 service-specific constraint in relation to the particular scenario. 653 The notion of an address here is a conditional (on those constraints) 654 one where this conditional part is an essential aspect of the 655 forwarding action to be taken. It needs therefore consideration in 656 the definition of what an address is, what is its semantic, and how 657 the address structure ought to look like. 659 As outlined in the previous sub-section, chaining services are 660 another aspect of steering traffic along a chain of constituent 661 services, where the chain is identified through either a stack of 662 individual identifiers, such as in Segment Routing [RFC8402], or as 663 an identifier that serves as a link to next hop destination within 664 the chain, such as in Service Function Chaining (SFC). The latter 665 can be applied to services identified at the level of Layer 2/3 666 ([RFC7665], [RFC8754], [RFC8595]) or at the level of name-based 667 service identifiers like URLs [RFC8677]. However, the overhead 668 incurred through the stacking of those chained identifiers is a 669 concern in terms of packet overhead and therefore efficiency in 670 handling in the intermediary nodes. 672 Flexibility in addressing may enable more semantic rich encoding 673 schemes that may help in steering traffic at hardware level and 674 speed, without complex mechanisms usually resulting in handling 675 packets in the slow path of routers. 677 2.6. Communication with built-in security 679 Today, strong security in the Internet is usually implemented as a 680 general network service ([PILA], [RFC6158]). Among the various 681 reasons for such approach is the limited semantic of current IP 682 addresses, which do not allow to natively express security features 683 or trust relationships. Efforts like Cryptographically Generated 684 Addresses (CGA) [RFC3972], provide some security features by 685 embedding a truncated public key in the last 57-bit of IPv6 address, 686 thereby greatly enhancing authentication and security within an IP 687 network via asymmetric cryptography and IPsec [RFC4301]. The 688 development of the Host Identity Protocol (HIP) [RFC7401] saw the 689 introduction of cryptographic identifiers for the newly introduced 690 Host Identity (HI) to allow for enhanced accountability, and 691 therefore trust. The use of those HIs, however, is limited by the 692 size of IPv6 128bit addresses. 694 Through a greater flexibility in addressing, any security-related 695 key, certificate, or identifier could instead be included in a 696 suitable address structure without any information loss (i.e., as-is, 697 without any truncation or operation as such), avoiding therefore 698 compromises such as those in HIP. Instead, CGAs could be created 699 using full length certificates, or being able to support larger HIP 700 addresses in a limited domain that uses it. This could significantly 701 help in constructing a trusted and secure communication at the 702 network layer, leading to connections that could be considered as 703 absolute secure (assuming the cryptography involved is secure). Even 704 more, anti-abuse mechanisms and/or DDoS protection mechanisms like 705 the one under discussion in PEARG ([PEARG]) Research Group may 706 leverage a greater flexibility of the overall Internet addressing, if 707 provided, in order to be more effective. 709 2.7. Communication protecting user privacy 711 See Comments in Section "Issues". 713 2.8. Communication in Alternative Forwarding Architectures 715 The performance of communication networks has long been a focus for 716 optimization due to the immediate impact on cost of ownership for 717 communication service providers. Technologies like MPLS [RFC3031] 718 have been introduced to optimize lower layer communication, e.g., by 719 mapping L3 traffic into aggregated labels of forwarding traffic for 720 the purposes of, e.g., traffic engineering. 722 Even further, other works have emerged in recent years that have 723 replaced the notion of packets with other concepts for the same 724 purpose of improved traffic engineering and therefore efficiency 725 gains. One such area is that of Software Defined Networks (SDN) 726 [RFC7426], which has highlighted how a majority of Internet traffic 727 is better identified by flows, rather than packets. Based on such 728 observation, alternate forwarding architectures have been devised 729 that are flow-based or path-based. With this approach, all data 730 belonging to the same traffic stream is delivered over the same path, 731 and traffic flows are identified by some connection or path 732 identifier rather than by complete routing information, possibly 733 enabling fast hardware based switching (e.g. [DETNET], [PANRG]). 735 On the one hand, such a communication model may be more suitable for 736 real-time traffic like in the context of Deterministic Networks 737 ([DETNET]), where indeed a lot of work has focused on how to 738 "identify" packets belonging to the same DETNET flow in order to 739 jointly manage the forwarding within the desired deterministic 740 boundaries. 742 On the other hand, it may improve the communication efficiency in 743 constrained wireless environments (cf., Section 2.1), by reducing the 744 overhead, hence increasing the number of useful bits per second per 745 Hz. 747 Also, the delivery of information across similar flows may be 748 combined into a multipoint delivery of a single return flow, e.g., 749 for scenarios of requests for a video chunk from many clients being 750 responded to with a single (multi-destination) flow, as outlined in 751 [BIER-MC] as an example. Another opportunity to improve 752 communication efficiency is being pursued in ongoing IETF/IRTF work 753 to deliver IP- or HTTP-level packets directly over path-based or 754 flow-based transport network solutions, such as in 755 [TROSSEN][BIER-MC][ICNIP][ICN5G] with the capability to bundle 756 unicast forward communication streams flexibly together in return 757 path multipoint relations. Such capability is particularly opportune 758 in scenarios such as chunk-based video retrieval or distributed data 759 storage. However, those solutions currently require gateways to 760 "translate" the flow communication into the packet-level addressing 761 semantic in the peering IP networks. Furthermore, the use of those 762 alternative forwarding mechanisms often require the encapsulation of 763 Internet addressing information, leading to wastage of bandwidth as 764 well as processing resources. 766 Providing an alternative way of forwarding data has also been the 767 motivation for the efforts created in the European Telecommunication 768 Standards Institute (ETSI), which formed an Industry Specification 769 Group (ISG) named Non-IP Networking (NIN) [ETSI-NIN]. This group 770 sets out to develop and standardize a set of protocols leveraging an 771 alternative forwarding architecture, such as provided by a flow-based 772 switching paradigm. The deployment of such protocols may be seen to 773 form limited domains, still leaving the need to interoperate with the 774 (packet-based forwarding) Internet; a situation possibly enabled 775 through a greater flexibility of the addressing used across Internet- 776 based and alternative limited domains alike. 778 As an alternative to IP routing, EIBP (Extended Internet Bypass 779 Protocol) [EIBP] offers a communications model that can work with IP 780 in parallel and entirely transparent and independent to any operation 781 at network layer. For this, EIBP proposes the use of physical and/or 782 virtual structures in networks and among networks to auto assign 783 routable addresses that capture the relative position of routers in a 784 network or networks in a connected set of networks, which can be used 785 to route the packets between end domains. EIBP operates at Layer 2.5 786 and provides encapsulation (at source domain), routing, and de- 787 encapsulation (at destination domain) for packets. EIBP can forward 788 any type of packets between domains. A resolver to map the domain ID 789 to EIBP's edge router addresses is required. When queried for a 790 specific domain, the resolver will return the corresponding edge 791 router structured addresses. 793 EIBP decouples routing operations from end domain operations, 794 offering to serve any domain, without point solutions to specific 795 domains. EIBP also decouples routing IDs or addresses from end 796 device/domain addresses. This allows for accommodation of new and 797 upcoming domains. A domain can extend EIBP's structured addresses 798 into the domain, by joining as a nested domain under one or more edge 799 routers, or by extending the edge router's structure addresses to its 800 devices. 802 A greater flexibility in addressing semantics may reduce the 803 aforementioned wastage by accommodating Internet addressing in the 804 light of such alternative forwarding architectures, instead enabling 805 the direct use of the alternative forwarding information. 807 3. Desired Network Features 809 From the previous subsection, we recognize that Internet technologies 810 are used across a number of scenarios, each of which brings their own 811 (vertical) view on needed capabilities in order to work in a 812 satisfactory manner to those involved. 814 In the following, we complement those vertical-specific insights with 815 answers to the question of network features that end users (in the 816 form of individuals or organizations alike) desire from the networked 817 system at large. Answers to this question look at the network more 818 from a horizontal perspective, i.e. not with a specific usage in mind 819 beyond communication within and across networks. The text here 820 summarizes the discussion that took place on the INT Area mailing 821 list after IETF112 on this issue. For some of those identified 822 features, we can already identify how innovations on addressing may 823 impact the realization of a particular feature. 825 We then combine the insights from both scenario-specific and wider 826 horizontal views for the identification of issues when realizing the 827 specific capability of addressing, presented in Section 4. 829 1. Always-On: The world is getting more and more connected, leading 830 to being connected to the Internet, anywhere, by any technology 831 (e.g., cable, fiber, or radio), even simultaneously, "all the 832 time", and, most importantly, automatically (without any switch 833 turning). However, when defining "all the time" there is a clear 834 and important difference to be made between availability and 835 reliability vs "desired usage". In other words, "always on" can 836 be seen as a desirable perception at the end user level or as a 837 characteristic of the underlying system. From an end user 838 perspective, clearly the former is of importance, not necessarily 839 leading to an "always on" system notion but instead "always-app- 840 available", merely requiring the needed availability and 841 reliability to realize the perception of being "always on" (e.g., 842 for earthquake alerts), possibly complemented by app-specific 843 methods to realize the "always on" perception (e.g., using local 844 caching rather than communication over the network). 846 2. Transparency: Being agnostic with respect to local domains 847 network protocols (Bluetooth, ZigBee, Thread, Airdrop, Airplay, 848 or any others) is key to provide an easy and straightforward 849 method for contacting people and devices without any knowledge of 850 network issues, particularly those specific to network-specific 851 solutions. While having a flexible addressing model that 852 accommodates a wide range of use cases is important, the 853 centrality of the IP protocol remains key as a mean to provide 854 global connectivity. 856 3. Multi-homing: Seamless multi-homing capability for the host is 857 key to best use the connectivity options that may be available to 858 an end user, e.g., for increasing resilience in cases of failures 859 of one available option. Protocols like LISP, SHIM6, QUIC, 860 MPTCP, SCTP (to cite a few) have been successful at providing 861 this capability in an incremental way, but too much of that 862 capability is realized within the application, making it hard to 863 leverage across all applications. While today each transport 864 protocol has its own way to perform multi-address discovery, the 865 network layer should provide the multi-homing feature (e.g., 866 SHIM6 can be used to discover all addresses on both ends), and 867 then leave the address selection to the transport. With that, 868 multi-address discovery remains a network feature exposed to the 869 upper layers. This may also mean to update the Socket API (which 870 may be actually the first thing to do), which does not 871 necessarily mean to expose more network details to the 872 applications but instead be more address agnostic yet more 873 expressive. 875 4. Mobility: A lot of work has been put in MobileIP 876 ([RFC5944],[RFC6275]) to provide seamless and lossless 877 communications for moving nodes (vehicle, satellites). However, 878 it has never been widely deployed for several reasons, like 879 complexity of the protocol and the fact that the problem has 880 often been tackled at higher layers, with applications resilient 881 to address changes. However, similar to multi-homing, solving 882 the problem at higher layers means that each and every transport 883 protocol and application have their own way to deal with 884 mobility, leading to similar observations as those for the 885 previous multi-homing aspect. 887 5. Security and Privacy: The COVID-19 pandemic has boosted end 888 users' desire to be protected and protect their privacy. The 889 balance among privacy, security, and accountability is not simple 890 to achieve. There exist different views on what those properties 891 should be, however the network should provide the means to 892 provide what is felt as the best trade-off for the specific use 893 case. 895 6. Performance: While certainly desirable, "performance" is a 896 complex issue that depends on the objectives of those building 897 for but also paying for performance. Examples are (i) speed 898 (shorter paths/direct communications), (ii) bandwidth (10petabit/ 899 s for a link), (iii) efficiency (less overlays/encapsulations), 900 (iv) high efficacy or sustainability (avoid waste). From an 901 addressing perspective, length/format/semantics that may adapt to 902 the specific use case (e.g. use short addresses for low power 903 IoT, or, where needed, longer for addresses embedding 904 certificates for strong authentication, authorization and 905 accountability) may contribute to the performance aspects that 906 end users desire, such as reducing waste through not needed 907 encapsulation or needed conversion at network boundaries. 909 7. Availability, Reliability, Predictability: These three properties 910 are important to enable wide-range of services and applications 911 according to the desired usage (cf. point 1). 913 8. Do not do harm: Access to the Internet is considered a human 914 right [RFC8280]. Access to and expression through it should 915 align with this core principle. This issue transcends through a 916 variety of previously discussed 'features' that are desired, such 917 as privacy, security but also availability and reliability. 918 However, lifting the feature of network access onto a basic 919 rights level also brings in the aspect of "do not do harm" 920 through the use of the Internet with respect to wider societal 921 objectives. Similar to other industries, such as electricity or 922 cars, preventing harm usually requires an interplay of 923 commercial, technological, and regulatory efforts, such as the 924 enforcement of seat belt wearing to reduce accident death. As a 925 first step, the potential harmfulness of a novel method must be 926 recognized and weighted against the benefits of its introduction 927 and use. One increasingly important consideration in the 928 technology domain is "sustainability" of resource usage for an 929 end user's consumption of and participation in Internet services. 930 As an example, Distributed Ledger Technologies (DLT) are seen as 931 an important tool for a variety of applications, including 932 Internet decentralization ([DINRG]). However, the non-linear 933 increase in energy consumption means that extending proof-of-work 934 systems to the entire population of the planet would not only be 935 impractical but also possibly highly wasteful, not just at the 936 level of computational but also communication resource usage 937 [DLT-draft]. This poses the question on how novel methods for 938 addressing may improve on sustainability of such technologies, 939 particularly if adopted more widely. 941 9. Maximum Transmission Unit (MTU): One long standing issue in the 942 Internet is related to the MTU and how to discover the path MTU 943 in order to avoid fragmentation ([I-D.ietf-6man-mtu-option], 944 [I-D.templin-6man-aero]). While it makes sense to always 945 leverage as much performance from local systems as possible, this 946 should come without sacrificing the ability to communicate with 947 all systems. Having a solid solution to solve the issue would 948 make the overall interconnection of systems more robust. 950 4. Issues in Addressing 952 The desired properties outlined in the previous section have 953 implications that go beyond addressing and need to be tackled from a 954 larger architectural point of view. Such a discussion is left as 955 future action, limiting the present document at discussing only the 956 addressing viewpoint and identifying shortcomings perceived from this 957 perspective. 958 There are a number of issues that we can identify from the 959 communication scenarios in Section 2 and the network features 960 generally desire from the network, presented in Section 3. We do not 961 claim to be exhaustive in our list: 963 1. Limiting Alternative Address Semantics: Several communication 964 scenarios pursue the use of alternative semantics of what 965 constitute an 'address' of a packet traversing the Internet, 966 which may fall foul of the defined network interface semantic of 967 IP addresses. 969 2. Hampering Security: Aligning with the semantic and length 970 limitations of IP addressing may hamper the security objectives 971 of any new semantic, possibly leading to detrimental effects and 972 possible other workarounds (at the risk of introducing fragility 973 rather than security). 975 1. Hampering Privacy: 977 * Easy individual identification 979 * Flow linkability 981 * App/Activity profiling 983 2. Complicating Traffic Engineering: Utilizing a plethora of non- 984 address inputs into the traffic steering decision in real 985 networks complicates traffic engineering in that it makes the 986 development of suitable policies more complex, while also leading 987 to possible contention between methods being used. 989 3. Hampering Efficiency: Extending IP addressing through point-wise 990 solutions also hampers efficiency, e.g., through needed re- 991 encapsulation (therefore increasing the header processing 992 overhead as well as header-to-payload ratio), through introducing 993 path stretch, or through requiring compression techniques to 994 reduce the header proportion of large addresses when operating in 995 constrained environments. 997 4. Fragility: The introduction of point solutions, each of which 998 comes with possibly own usages of address or packet fields, 999 together with extension-specific operations, increases the 1000 overall fragility of the resulting system, caused, for instance, 1001 through contention between feature extensions that were neither 1002 foreseen in the design nor tested during the implementation 1003 phase. 1005 5. Extensibility: Accommodating new requirements through ever new 1006 extensions as an extensibility approach to addressing compounds 1007 aspects discussed before, i.e., fragility, efficiency etc. It 1008 complicates engineering due to the clearly missing boundaries 1009 against which contentions with other extensions could be managed. 1010 It complicates standardization since extension-based 1011 extensibility requires independent, and often lengthy, 1012 standardization processes. And ultimately, deployments are 1013 complicated due to backward compatibility testing required for 1014 any new extension being integrated into the deployed system. 1016 The table below shows how the above identified issues do arise 1017 somehow in our outlined communication scenarios in Section 2. This 1018 overview will be deepened in more details in the gap analysis 1019 document [I-D.jia-intarea-internet-addressing-gap-analysis]. 1021 +===============+=======+=======+=======+=======+=======+=======+ 1022 | | Issue | Issue | Issue | Issue | Issue | Issue | 1023 | | 1 | 2 | 3 | 4 | 5 | 6 | 1024 +===============+=======+=======+=======+=======+=======+=======+ 1025 | Constrained | | | | x | x | x | 1026 | Environments | | | | | | | 1027 +---------------+-------+-------+-------+-------+-------+-------+ 1028 | Dynamically | x | | x | x | x | x | 1029 | Changing | | | | | | | 1030 | Topologies | | | | | | | 1031 +---------------+-------+-------+-------+-------+-------+-------+ 1032 | Moving | x | | x | x | x | x | 1033 | Endpoints | | | | | | | 1034 +---------------+-------+-------+-------+-------+-------+-------+ 1035 | Across | x | | x | x | x | x | 1036 | Services | | | | | | | 1037 +---------------+-------+-------+-------+-------+-------+-------+ 1038 | Traffic | x | | x | x | x | x | 1039 | Steering | | | | | | | 1040 +---------------+-------+-------+-------+-------+-------+-------+ 1041 | Built-in | x | x | | x | x | x | 1042 | Security | | | | | | | 1043 +---------------+-------+-------+-------+-------+-------+-------+ 1044 | Alternative | x | | | x | | x | 1045 | Forwarding | | | | | | | 1046 | Architectures | | | | | | | 1047 +---------------+-------+-------+-------+-------+-------+-------+ 1049 Table 1: Issues Involved in Challenging Scenarios 1051 5. Problem Statement 1053 This document identifies a number of scenarios as well as general 1054 features end users would want from the network, positioning the 1055 existing Internet addressing structure itself as a potential 1056 hindrance in solving key problems for Internet service provisioning. 1057 Such problems include supporting new, e.g., service-oriented, 1058 scenarios more efficiently, with improved security and efficient 1059 traffic engineering, as well as large scale mobility. We can observe 1060 that those new forms of communication are particularly driven by the 1061 conceptual framework of limited domains, realizing the requirements 1062 of stakeholders for an optimized communication in those limited 1063 domains, while still utilizing the Internet for interconnection as 1064 well as for access to the wealth of existing Internet services. 1066 This co-existence of optimized LD-level as well as Internet 1067 communication creates a tussle between those requirements on 1068 addressing stemming from those limited domains and those coming from 1069 the Internet in the form of agreed IPv6 semantics. This tussle 1070 directly refers back to our introductory question on flexibility in 1071 addressing (or leaving the problem to limited domain solutions to 1072 deal with). It is also captured in the discussion on where new 1073 features are being introduced, i.e. at the edge or core of the 1074 Internet. 1076 But more importantly, the question on 'what is an address anyway' 1077 (derived from what features we may want from the network) should not 1078 be guided by the answers that the Internet can give us today, e.g., 1079 being a mere ephemeral token for accessing PoP-based services (as 1080 indicated in related arch-d mailing list discussions), but instead 1081 what features could be enabled by a particular view of what an 1082 address is. However, that is not to 'second guess' the market and 1083 its possible evolution, but to outline clear features from which to 1084 derive clear principles for a design. 1086 For this, it is important to recognize that skewing the technical 1087 capabilities of any feature, let alone addressing, to the current 1088 economic situation of the Internet bears the danger of locking down 1089 innovation capabilities as an outcome of those technical limitations 1090 being introduced. Instead, addressing must align with enabling the 1091 model of permissionless but compatible innovation that the IETF has 1092 been promoting, ultimately enabling the serendipity of new 1093 applications that has led to many of those applications we can see in 1094 the Internet today. 1096 At this stage, this document does not provide a definite answer nor 1097 does it propose or promote specific solutions to the problems here 1098 portrayed. Instead, this document aims at stimulating discussion on 1099 the emerging needs for addressing, with the possibility to 1100 fundamentally re-think the addressing in the Internet beyond the 1101 current objectives of IPv6, in order to provide the flexibility to 1102 suitably support the many new forms of communication that will 1103 emerge. Addressing can be rather flexible and can be of any form 1104 that applications may need. There is no limitation on the address to 1105 preclude any future applications. 1107 To complement the problem statement in this document, the companion 1108 gap analysis document 1109 [I-D.jia-intarea-internet-addressing-gap-analysis] deepens the issues 1110 identified in Section 4 along key properties of today's Internet 1111 addressing. 1113 6. Security Considerations 1115 The present memo does not introduce any new technology and/or 1116 mechanism and as such does not introduce any security threat to the 1117 TCP/IP protocol suite. 1119 Nevertheless, it is worth to observe whether or not greater 1120 flexibility of addressing (as suggested in previous sections) would 1121 allow to introduce fully featured security in endpoint 1122 identification, potentially able to eradicate the spoofing problem, 1123 as one example. Furthermore, it may be used to include application 1124 gateways' certificates in order to provide more efficiency, e.g., 1125 using web certificates also in the addressing of web services. While 1126 increasing security, privacy protection may also be improved. 1128 7. IANA Considerations 1130 This document does not include an IANA request. 1132 8. References 1134 8.1. Normative References 1136 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1137 DOI 10.17487/RFC0791, September 1981, 1138 . 1140 8.2. Informative References 1142 [ALOHA] Kuo, F., "The ALOHA System", ACM SIGCOMM Computer 1143 Communication Review Vol. 25, pp. 41-44, 1144 DOI 10.1145/205447.205451, January 1995, 1145 . 1147 [BACnet] "BACnet-A Data Communication Protocol for Building 1148 Automation and Control Networks", ANSI/ASHRAE Standard 1149 135-2016, January 2016, 1150 . 1153 [BIER-MC] Trossen, D., Rahman, A., Wang, C., and T. Eckert, 1154 "Applicability of BIER Multicast Overlay for Adaptive 1155 Streaming Services", Work in Progress, Internet-Draft, 1156 draft-ietf-bier-multicast-http-response-06, 10 July 2021, 1157 . 1160 [BLE] "Bluetooth Specification", Bluetooth SIG Working Groups, 1161 n.d., . 1163 [CARTISEAN] 1164 Hughes, L., Shumon, K., and Y. Zhang, "Cartesian Ad Hoc 1165 Routing Protocols", Ad-Hoc, Mobile, and Wireless 1166 Networks pp. 287-292, DOI 10.1007/978-3-540-39611-6_27, 1167 2003, . 1169 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 1170 Briggs, N., and R. Braynard, "Networking named content", 1171 Proceedings of the 5th international conference on 1172 Emerging networking experiments and technologies - 1173 CoNEXT '09, DOI 10.1145/1658939.1658941, 2009, 1174 . 1176 [CHEN21] Chen, Y., Li, H., Liu, J., Wu, Q., and Z. Lai, "GAMS: An 1177 IP Address Management Mechanism in Satellite Mega- 1178 constellation Networks", 2021 International Wireless 1179 Communications and Mobile Computing (IWCMC), 1180 DOI 10.1109/iwcmc51323.2021.9498722, June 2021, 1181 . 1183 [CHRIKI19] Chriki, A., Touati, H., Snoussi, H., and F. Kamoun, 1184 "FANET: Communication, mobility models and security 1185 issues", Computer Networks Vol. 163, pp. 106877, 1186 DOI 10.1016/j.comnet.2019.106877, November 2019, 1187 . 1189 [DDS] AL-Madani, B., Elkhider, S., and S. El-Ferik, "DDS-Based 1190 Containment Control of Multiple UAV Systems", Applied 1191 Sciences Vol. 10, pp. 4572, DOI 10.3390/app10134572, July 1192 2020, . 1194 [DECT-ULE] "Digital Enhanced Cordless Telecommunications (DECT); 1195 Common Interface (CI); Part 1: Overview", ETSI European 1196 Standard, EN 300 175-1, V2.6.1, May 2009, 1197 . 1201 [DETNET] "Deterministic Networking (DetNet)", n.d., 1202 . 1204 [DINRG] "Decentralized Internet Infrastructure - DINRG", n.d., 1205 . 1207 [DLT-draft] 1208 Trossen, D., Guzman, D., Bride, M. M., and X. Fan, "Impact 1209 of DLTs on Provider Networks", Work in Progress, Internet- 1210 Draft, draft-trossen-rtgwg-impact-of-dlts-01, 2 March 1211 2022, . 1214 [ECMA-340] EECMA-340, "Near Field Communication - Interface and 1215 Protocol (NFCIP-1) 3rd Ed.", June 2013. 1217 [EIBP] Shenoy, S Chandraiah, P Willis, N., "A Structured Approach 1218 to Routing in the Internet", June 2021, . 1222 [ETSI-NIN] ETSI - European Telecommunication Standards Institute, 1223 "Non-IP Networking - NIN", n.d., 1224 . 1226 [HANDLEY] Handley, M., "Delay is Not an Option: Low Latency Routing 1227 in Space", Proceedings of the 17th ACM Workshop on Hot 1228 Topics in Networks, DOI 10.1145/3286062.3286075, November 1229 2018, . 1231 [I-D.ietf-6man-mtu-option] 1232 Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU 1233 Hop-by-Hop Option", Work in Progress, Internet-Draft, 1234 draft-ietf-6man-mtu-option-13, 28 February 2022, 1235 . 1238 [I-D.ietf-intarea-gue] 1239 Herbert, T., Yong, L., and O. Zia, "Generic UDP 1240 Encapsulation", Work in Progress, Internet-Draft, draft- 1241 ietf-intarea-gue-09, 26 October 2019, 1242 . 1245 [I-D.ietf-lisp-introduction] 1246 Cabellos, A. and D. S. (Ed.), "An Architectural 1247 Introduction to the Locator/ID Separation Protocol 1248 (LISP)", Work in Progress, Internet-Draft, draft-ietf- 1249 lisp-introduction-15, 20 September 2021, 1250 . 1253 [I-D.ietf-lisp-mn] 1254 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1255 Mobile Node", Work in Progress, Internet-Draft, draft- 1256 ietf-lisp-mn-11, 30 January 2022, 1257 . 1260 [I-D.ietf-lisp-nexagon] 1261 Barkai, S., Fernandez-Ruiz, B., Tamir, R., Rodriguez- 1262 Natal, A., Maino, F., Cabellos-Aparicio, A., and D. 1263 Farinacci, "Network-Hexagons: H3-LISP GeoState & Mobility 1264 Network", Work in Progress, Internet-Draft, draft-ietf- 1265 lisp-nexagon-19, 14 September 2021, 1266 . 1269 [I-D.ietf-lisp-rfc6833bis] 1270 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1271 "Locator/ID Separation Protocol (LISP) Control-Plane", 1272 Work in Progress, Internet-Draft, draft-ietf-lisp- 1273 rfc6833bis-30, 18 November 2020, 1274 . 1277 [I-D.jia-intarea-internet-addressing-gap-analysis] 1278 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., and P. 1279 Mendes, "Gap Analysis in Internet Addressing", Work in 1280 Progress, Internet-Draft, draft-jia-intarea-internet- 1281 addressing-gap-analysis-01, 23 October 2021, 1282 . 1285 [I-D.templin-6man-aero] 1286 Templin, F. L., "Automatic Extended Route Optimization 1287 (AERO)", Work in Progress, Internet-Draft, draft-templin- 1288 6man-aero-39, 22 February 2022, 1289 . 1292 [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G. 1293 White, "Enabling ICN in 3GPP's 5G NextGen Core 1294 Architecture", Work in Progress, Internet-Draft, draft- 1295 irtf-icnrg-5gc-icn-04, 10 January 2021, 1296 . 1299 [ICNIP] Trossen, D., Robitzsch, S., Reed, M., Al-Naday, M., and J. 1300 Riihijarvi, "Internet Services over ICN in 5G LAN 1301 Environments", Work in Progress, Internet-Draft, draft- 1302 trossen-icnrg-internet-icn-5glan-04, 1 October 2020, 1303 . 1306 [IEEE_1901.1] 1307 "Standard for Medium Frequency (less than 15 MHz) Power 1308 Line Communications for Smart Grid Applications", IEEE 1309 1901.1 IEEE-SA Standards Board, May 2018, 1310 . 1312 [LR-WPAN] "IEEE 802.15.4 - IEEE Standard for Low-Rate Wireless 1313 Networks", IEEE 802.15 WPAN Task Group 4, May 2020, 1314 . 1316 [MANET1] Abdallah, A., Abdallah, E., Bsoul, M., and A. Otoom, 1317 "Randomized geographic-based routing with nearly 1318 guaranteed delivery for three-dimensional ad hoc network", 1319 International Journal of Distributed Sensor Networks Vol. 1320 12, pp. 155014771667125, DOI 10.1177/1550147716671255, 1321 October 2016, . 1323 [MAROJEVIC20] 1324 Marojevic, V., Guvenc, I., Dutta, R., Sichitiu, M., and B. 1325 Floyd, "Advanced Wireless for Unmanned Aerial Systems: 5G 1326 Standardization, Research Challenges, and AERPAW 1327 Architecture", IEEE Vehicular Technology Magazine Vol. 15, 1328 pp. 22-30, DOI 10.1109/mvt.2020.2979494, June 2020, 1329 . 1331 [OCADO] "Ocado Technology’s robot warehouse a Hive of IoT 1332 innovation", n.d., . 1335 [PANRG] "Path Aware Networking Research Group - PANRG", n.d., 1336 . 1338 [PEARG] "Privacy Enhancements and Assessments Research Group - 1339 PEARG", n.d., . 1341 [PILA] Krahenbuhl, C., Legner, M., Bitterli, S., and A. Perrig, 1342 "Pervasive Internet-Wide Low-Latency Authentication", 2021 1343 International Conference on Computer Communications and 1344 Networks (ICCCN), DOI 10.1109/icccn52240.2021.9522235, 1345 July 2021, 1346 . 1348 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1349 DOI 10.17487/RFC2775, February 2000, 1350 . 1352 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1353 Label Switching Architecture", RFC 3031, 1354 DOI 10.17487/RFC3031, January 2001, 1355 . 1357 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1358 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1359 . 1361 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1362 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1363 December 2005, . 1365 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1366 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1367 Overview, Assumptions, Problem Statement, and Goals", 1368 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1369 . 1371 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1372 Kozuka, "Stream Control Transmission Protocol (SCTP) 1373 Dynamic Address Reconfiguration", RFC 5061, 1374 DOI 10.17487/RFC5061, September 2007, 1375 . 1377 [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 1378 "Network Mobility (NEMO) Extensions for Mobile IPv4", 1379 RFC 5177, DOI 10.17487/RFC5177, April 2008, 1380 . 1382 [RFC5275] Turner, S., "CMS Symmetric Key Management and 1383 Distribution", RFC 5275, DOI 10.17487/RFC5275, June 2008, 1384 . 1386 [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private 1387 VLANs: Scalable Security in a Multi-Client Environment", 1388 RFC 5517, DOI 10.17487/RFC5517, February 2010, 1389 . 1391 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1392 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1393 . 1395 [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", 1396 BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, 1397 . 1399 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1400 Iyengar, "Architectural Guidelines for Multipath TCP 1401 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 1402 . 1404 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1405 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1406 2011, . 1408 [RFC6626] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, 1409 "Dynamic Prefix Allocation for Network Mobility for Mobile 1410 IPv4 (NEMOv4)", RFC 6626, DOI 10.17487/RFC6626, May 2012, 1411 . 1413 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1414 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1415 eXtensible Local Area Network (VXLAN): A Framework for 1416 Overlaying Virtualized Layer 2 Networks over Layer 3 1417 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1418 . 1420 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1421 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1422 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1423 . 1425 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1426 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1427 Defined Networking (SDN): Layers and Architecture 1428 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1429 2015, . 1431 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1432 CJ. Bernardos, "Distributed Mobility Management: Current 1433 Practices and Gap Analysis", RFC 7429, 1434 DOI 10.17487/RFC7429, January 2015, 1435 . 1437 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1438 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1439 "Information-Centric Networking: Baseline Scenarios", 1440 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1441 . 1443 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1444 Chaining (SFC) Architecture", RFC 7665, 1445 DOI 10.17487/RFC7665, October 2015, 1446 . 1448 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1449 (IPv6) Specification", STD 86, RFC 8200, 1450 DOI 10.17487/RFC8200, July 2017, 1451 . 1453 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1454 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1455 October 2017, . 1457 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1458 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1459 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1460 July 2018, . 1462 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1463 Forwarding Plane for Service Function Chaining", RFC 8595, 1464 DOI 10.17487/RFC8595, June 2019, 1465 . 1467 [RFC8677] Trossen, D., Purkayastha, D., and A. Rahman, "Name-Based 1468 Service Function Forwarder (nSFF) Component within a 1469 Service Function Chaining (SFC) Framework", RFC 8677, 1470 DOI 10.17487/RFC8677, November 2019, 1471 . 1473 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1474 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1475 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1476 . 1478 [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1479 "Deployment Considerations for Information-Centric 1480 Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 1481 2020, . 1483 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1484 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1485 . 1487 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 1488 "Geneve: Generic Network Virtualization Encapsulation", 1489 RFC 8926, DOI 10.17487/RFC8926, November 2020, 1490 . 1492 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1493 Multiplexed and Secure Transport", RFC 9000, 1494 DOI 10.17487/RFC9000, May 2021, 1495 . 1497 [SFCANYCAST] 1498 Wion, A., Bouet, M., Iannone, L., and V. Conan, 1499 "Distributed Function Chaining with Anycast Routing", 1500 Proceedings of the 2019 ACM Symposium on SDN Research, 1501 DOI 10.1145/3314148.3314355, April 2019, 1502 . 1504 [TERASTREAM] 1505 "Deutsche Telekom tests TeraStream, the network of the 1506 future, in Croatia", n.d., 1507 . 1511 [TROSSEN] Trossen, D., Sarela, M., and K. Sollins, "Arguments for an 1512 information-centric internetworking architecture", ACM 1513 SIGCOMM Computer Communication Review Vol. 40, pp. 26-33, 1514 DOI 10.1145/1764873.1764878, April 2010, 1515 . 1517 [WANG19] Wang, P., Zhang, J., Zhang, X., Yan, Z., Evans, B., and W. 1518 Wang, "Convergence of Satellite and Terrestrial Networks: 1519 A Comprehensive Survey", IEEE Access Vol. 8, pp. 1520 5550-5588, DOI 10.1109/access.2019.2963223, 2020, 1521 . 1523 Acknowledgments 1525 Thanks to all the people that shared insightful comments both 1526 privately to the authors as well as on various mailing list, 1527 especially on the INTArea Mailing List. Also thanks for the 1528 interesting discussions to Stewart Bryant, Ron Bonica, Toerless 1529 Eckert, Brian E. Carpenter, Kiran Makhijani, Fred Templin. 1531 Authors' Addresses 1533 Yihao Jia 1534 Huawei Technologies Co., Ltd 1535 156 Beiqing Rd. 1536 Beijing 1537 100095 1538 P.R. China 1539 Email: jiayihao@huawei.com 1540 Dirk Trossen 1541 Huawei Technologies Duesseldorf GmbH 1542 Riesstr. 25C 1543 80992 Munich 1544 Germany 1545 Email: dirk.trossen@huawei.com 1547 Luigi Iannone 1548 Huawei Technologies France S.A.S.U. 1549 18, Quai du Point du Jour 1550 92100 Boulogne-Billancourt 1551 France 1552 Email: luigi.iannone@huawei.com 1554 Nirmala Shenoy 1555 Rochester Institute of Technology 1556 New-York, 14623 1557 United States of America 1558 Email: nxsvks@rit.edu 1560 Paulo Mendes 1561 Airbus 1562 Willy-Messerschmitt Strasse 1 1563 81663 Munich 1564 Germany 1565 Email: paulo.mendes@airbus.com 1567 Donald E. Eastlake 3rd 1568 Futurewei Technologies 1569 2386 Panoramic Circle 1570 Apopka, FL, 32703 1571 United States of America 1572 Email: d3e3e3@gmail.com 1574 Peng Liu 1575 China Mobile 1576 32 Xuanwumen West Ave 1577 Xicheng, Beijing 1578 100053 1579 P.R. China 1580 Email: liupengyjy@chinamobile.com 1581 Dino Farinacci 1582 lispers.net 1583 United States of America 1584 Email: farinacci@gmail.com