idnits 2.17.1 draft-jia-intarea-scenarios-problems-addressing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8799]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-bier-multicast-http-response-05 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-mn-09 == Outdated reference: A later version (-52) exists of draft-ietf-lisp-nexagon-07 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 Summary: 1 error (**), 0 flaws (~~), 6 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: January 13, 2022 Huawei 6 N. Shenoy 7 RIT 8 P. Mendes 9 Airbus 10 D. Eastlake 3rd 11 Futurewei 12 P. Liu 13 China Mobile 14 July 12, 2021 16 Challenging Scenarios and Problems in Internet Addressing 17 draft-jia-intarea-scenarios-problems-addressing-01 19 Abstract 21 The Internet Protocol (IP) has been the major technological success 22 in information technology of the last half century. As the Internet 23 becomes pervasive, IP has been replacing communication technology for 24 many domain-specific solutions. However, domains with specific 25 requirements as well as communication behaviors and semantics still 26 exist and represent what [RFC8799] recognizes as "limited domains". 28 This document describes well-recognized scenarios that showcase 29 possibly different addressing requirements, which are challenging to 30 be accommodated in the IP addressing model. These scenarios 31 highlight issues related to the Internet addressing model and call 32 for starting a discussion on a way to re-think/evolve the addressing 33 model so to better accommodate different domain-specific 34 requirements. 36 The issues identified in this document are complemented and deepened 37 by a detailed gap analysis in a separate companion document 38 [GAP_ANALYSIS]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 13, 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Communication Scenarios in Limited Domains . . . . . . . . . 4 76 2.1. Communication in Constrained Environments . . . . . . . . 4 77 2.2. Communication within Dynamically Changing Topologies . . 7 78 2.3. Communication among Moving Endpoints . . . . . . . . . . 9 79 2.4. Communication Across Services . . . . . . . . . . . . . . 12 80 2.5. Steering Communication Traffic . . . . . . . . . . . . . 13 81 2.6. Communication with built-in security . . . . . . . . . . 15 82 2.7. Communication in Alternative Forwarding Architectures . . 15 83 3. Issues in Addressing . . . . . . . . . . . . . . . . . . . . 17 84 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 7. Informative References . . . . . . . . . . . . . . . . . . . 20 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 89 A.1. Since draft-jia-intarea-scenarios-problems-addressing-00 26 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 The Internet Protocol (IP), positioned as the unified protocol at the 96 (Internet) network layer, is seen by many as key to the innovation 97 stemming from Internet-based applications and services. Even more 98 so, with the success of TCP/IP protocol stack, IP has been gradually 99 replacing existing domain-specific protocols, evolving into the core 100 protocol of the entire communication system. At its inception 101 roughly 40 years ago [RFC0791], the Internet addressing system, 102 represented in the form of the IP address and its locator-based 103 semantics, has brought the notion of a 'common addressing for all 104 communication'. Compared to proprietary technology-specific 105 solutions, such 'common addressing for all communication' advance 106 ensures end-to-end communication from any device connected to the 107 Internet to another. 109 However, scenarios, associated services, node behaviors, and 110 requirements on packet delivery have since been significantly 111 extended, with Internet technologies being developed to accommodate 112 them in the framework of addressing that stood at the beginning of 113 the Internet's development. This evolution is reflected in the 114 concept of the "Limited Domain", first introduced in [RFC8799]. It 115 refers to a single physical network, attached to or running in 116 parallel with the Internet, or is defined by a set of users and nodes 117 distributed over a much wider area, but drawn together by a single 118 virtual network over the Internet. Key to a limited domain is that 119 requirements, behaviors, and semantics could be noticeable local and, 120 more importantly, specific to the limited domain. Very often, the 121 realization of a limited domain is defined by specific communication 122 scenario(s) that exhibit the domain-specific behaviors and pose the 123 requirements that lead to the establishment of the limited domain. 125 One key architectural aspect, when communicating within limited 126 domains, is that of addressing and, therefore, the address structure, 127 as well as the semantic that is being used for the routing of 128 packets. The topological location centrality of IP is fundamental 129 when reconciling the often differing semantics for 'addressing' that 130 can be found in those limited domains. The result of this 131 fundamental role of the single IP addressing is that limited domains 132 have to adopt specific solutions, e.g., translating/mapping/ 133 converting concepts, semantics, and ultimately, domain-specific 134 addressing, into the common IP addressing used across limited 135 domains. 137 This document advocates flexibility in addressing in order to 138 accommodate limited domain specific semantics, while, if possible, 139 ensuring a single holistic addressing scheme able to reduce, or even 140 entirely remove, the need for aligning the address semantics of 141 different limited domains, such as the current topological location 142 semantic of the Internet. Ultimately, such holistic addressing could 143 be beneficial to those communication scenarios realized within 144 limited domains by improving efficiency, removing of constraints 145 imposed by needing to utilize the limited semantics of IP addressing, 146 and/or in other ways. 148 In other words, this document revolves around the following question: 150 "Should limited domains purely rely on IP addresses and therefore 151 deal with the complexity of translating any semantic mismatch 152 themselves, or should flexibility for supporting those limited 153 domains be a key focus for an evolved Internet addressing?" 155 To that end, this document describes well-recognized scenarios in 156 limited domains that could benefit from greater flexibility in 157 addressing and analyses problems encountered throughout these 158 scenarios due to the lack of that flexibility. The purpose of this 159 memo is thus to stimulate discussion on the emerging needs for 160 addressing at large with the possibility to fundamentally re-think 161 the addressing in the Internet beyond the current objectives of IPv6 162 [RFC8200]. 164 It is important to remark that any change in the addressing, hence at 165 the data plane level, leads to changes and challenges at the control 166 plane level, i.e., routing. The latter is an even harder problem 167 than just addressing and might need more research efforts that are 168 beyond the objective of this document, which focuses solely on the 169 data plane. 171 The content in this document is complemented by a detailed gap 172 analysis, which can be found in [GAP_ANALYSIS], that elaborates on 173 the issues identified in this memo in reference to extensions to 174 Internet addressing that have attempted to address those issues. 176 2. Communication Scenarios in Limited Domains 178 The following sub-sections outline a number of scenarios, all of 179 which belong to the concept of "limited domains" [RFC8799]. While 180 the list of scenarios may look long, this document focuses on 181 scenarios with a number of aspects that we observe in those limited 182 domains, captured in the sub-section titles. For each scenario, we 183 point at possible challenges, which we will pick upon in Section 3, 184 when describing more formally the existing shortcomings in current 185 Internet addressing. 187 2.1. Communication in Constrained Environments 189 In a number of communication scenarios, such as those encountered in 190 the Internet of Things (IoT), a simple, low-cost communication 191 network is required, and there are limitations for network devices in 192 computational power, memory, and energy availability. In addition to 193 IEEE 802.15.4, i.e., Low-Rate Wireless Personal Area Network 194 [LR-WPAN], several limited domains exist through utilizing link layer 195 technologies such as Bluetooth Low Energy (BLE) [BLE], Digital 196 European Cordless Telecommunications (DECT) - Ultra Low Energy (ULE) 197 [DECT-ULE], Master-Slave/Token-Passing (MS/TP) [BACnet], Near-Field- 198 Communication (NFC) [ECMA-340], and Power Line Communication (PLC) 199 [IEEE_1901.1]. 201 Generally, a group of IoT network devices form a constrained nodes 202 network at the edge, and IoT terminals connect to these network 203 devices for data transmission. This type of networks and IoT devices 204 in the network require as little computational power as possible, 205 small memory requirements, good energy availability to reduce the 206 total cost of ownership of the network. Furthermore, in the context 207 of industrial IoT, real-time requirements and scalability make IP 208 technology not naturally suitable as communication technology 209 ([OCADO]). 211 The end-to-end principle (detailed in [RFC2775]) requires Internet 212 protocols (e.g., IPv6 [RFC8200]) to run on such constrained node 213 networks, allowing IoT devices using multiple communication 214 technologies to talk on the Internet. Often, devices located at the 215 edge of constrained networks act as gateway devices, usually 216 performing header compression ([RFC4919]). To ensure security and 217 reliability, multiple gateways must be deployed. IoT devices on the 218 network can select one of those gateways for traffic passthrough by 219 the devices on the (limited domain) network. 221 Given the constraints imposed on the computational and possibly also 222 communication technology, the usage of a single addressing semantic 223 in the form of a 128-bit endpoint identifier, i.e., IPv6 address, may 224 pose a challenge when operating such networks. 226 Another example of a constrained environment is an aircraft, which 227 encompasses not only passenger communication but also the integration 228 of real-time data exchange to ensure that processes and functions in 229 the cabin are automatically monitored or actuated. Two possible 230 examples are large scale passenger aircraft and military aircraft. 232 Large scale passenger aircraft (and their networks) have high 233 requirements placed on them for performance, efficiency, and high 234 dispatch reliability. Additionally, due to their size and commercial 235 operation, they often have multiple network domains, including high 236 criticality Aircraft Control Domain networks, Aircraft Information 237 Services Domain, as well as Passenger Information Entertainment 238 System Domains. The onboard presence of multiple domains, especially 239 when interconnected, as well as design assurance levels drives a wide 240 variety of traffic requirements and additional security requirements 241 on network implementations. 243 In what concerns avionics networks, the goal for any aircraft network 244 is to be able to send and receive information reliably and 245 seamlessly. From this perspective, the medium with which these 246 packets of information are sent is of little consequence so long as 247 there is a level of determinism to it. However, there is currently 248 no effective method in implementing wireless inter- and intra- 249 communications between all subsystems. The emerging wireless sensor 250 network technology in commercial applications such as smart 251 thermostat systems, and smart washer/dryer units could be transposed 252 onto aircraft and fleet operations. The proposal for having an 253 Wireless Avionics Intra-Communications (WAIC) system promises 254 reduction in the complexity of electrical wiring harness design and 255 fabrication, reduction in wiring weight, increased configuration, and 256 potential monitoring of otherwise inaccessible moving or rotating 257 aircraft parts. Similar to the IoT concept, WAIC systems consist of 258 short-range communications and are a potential candidate for 259 passenger entertainment systems, smoke detectors, engine health 260 monitors, tire pressure monitoring systems, and other kinds of 261 aircraft maintenance systems. 263 While there are still many obstacles in terms of network security, 264 traffic control, and technical challenges, future WAIC can enable 265 real-time seamless communications between aircraft and between ground 266 teams and aircraft as opposed to the discrete points of data 267 leveraged today in aircraft communications. For that, WAIC 268 infrastructure should also be connected to outside IP based networks 269 in order to access edge/cloud facilities for data storage and mining. 270 However, the restricted capacity (energy, communication) of most 271 aircraft devices (e.g. sensors) and the nature of the transmitted 272 data - periodic transmission of small packets - may pose some 273 challenges for the usage of a single addressing semantic in the form 274 of a 128-bit endpoint identifier, i.e., an IPv6 address. Moreover, 275 most of the aircraft applications and services are focused on the 276 data (e.g. temperature of gas tank on left wing) and not on the 277 topological location of the data source. This means that the current 278 topological location semantic of IP addresses is not beneficial for 279 aircraft applications and services. 281 Greater flexibility in Internet addressing may avoid complex and 282 energy hungry operations, like header compression and fragmentation, 283 necessary to translate protocol headers from one limited domain to 284 another, while enabling semantics different from locator-based 285 addressing may better support the communication that occurs in those 286 environments. 288 2.2. Communication within Dynamically Changing Topologies 290 Communication may occur over networks that exhibit dynamically 291 changing topologies. One such example is that of satellite networks, 292 providing global Internet connections through a combination of inter- 293 satellite and ground station communication. With the convergence of 294 space-based and terrestrial networks, users can experience seamless 295 broadband access, e.g., on cruise ships, flights, and within cars, 296 often complemented by and seamlessly switching between Wi-Fi, 297 cellular, or satellite based networks at any time. 299 The satellite network service provider will plan the transmission 300 path of user traffic based on the network coverage, satellite orbit, 301 route, and link load, providing potentially high-quality Internet 302 connections for users in areas that are not, or hard to be, covered 303 by terrestrial networks. The involved topologies of the satellite 304 network will be changing constantly while observing a regular flight 305 pattern in relation to other satellite and predictable overflight 306 patterns to ground users. 308 Although satellite bearer services are capable of transporting IPv4 309 and IPv6, as well as associated protocols such as IP Multicast, DNS 310 services and routing information, no IP functionality is implemented 311 on-board the spacecraft limiting the capability of leveraging for 312 instance large scale satellite constellations. 314 One of the major constraints of deploying routing capability on board 315 a satellite is power consumption. Due to this, space routers may end 316 up being intermittently powered up during a daytime sunlit pass. 317 Another limitation of the first generation of IP routers in space was 318 the lack of capability to remotely manage and upgrade software while 319 in operation. This will lead to an intermittent operation of the 320 space router. 322 The limitations faced in early development of IP based satellite 323 communication payloads, showed the need to develop a flexible 324 networking solution that would only allow delay tolerant 325 communications in the present of intermittent connectivity as well as 326 a networking solution able to perform in a scenario encompassing 327 mobile devices with the capability of storing data, leading to a 328 significant reduction of latency, which is the major impairment of 329 satellite networks. However, the inefficiencies of the current 330 Internet architecture with regard to different aspects such as 331 mobility, traffic management, or content delivery have progressively 332 led to the ossification of the Internet. The root of these 333 inefficiencies is the fact that the current Internet host centric 334 model does not match the Internet dominant usage, which involves end- 335 users exchanging information or accessing services, independently of 336 the device where the information is located or which provides the 337 service. Moreover the current IP addressing schemes, with focus on 338 IP unicast addressing with extended deployment of IP multicast and 339 some IP anycast do not take advantage of the broadcast nature of 340 satellite networks. Moreover networking platforms based on a name 341 (data or service) based addressing scheme would bring several 342 potential benefits to satellite networks aiming to tackle their major 343 challenges, including high propagation delay and changing network 344 topology in the case of LEO constellations. 346 Another example is that of vehicular communication, where services 347 may be accessed across vehicles, such as self-driving cars, for the 348 purpose of collaborative objection recognition (e.g., for collision 349 avoidance), road status conveyance (e.g., for pre-warning of road- 350 ahead conditions), and other purposes. Communication may include 351 Road Side Units (RSU) with the possibility to create ephemeral 352 connections to those RSUs for the purpose of workload offloading, 353 joint computation over multiple (vehicular) inputs, and other 354 purposes [I-D.ietf-lisp-nexagon]. Communication here may exhibit a 355 multi-hop nature, not just involving the vehicle and the RSU over a 356 direct link. Those topologies are naturally changing constantly due 357 to the dynamic nature of the involved communication nodes. 359 The advent of Flying Ad-hoc NETworks (FANETs) has opened up an 360 opportunity to create new added-value services. Although these 361 networks share common features with vehicular ad hoc networks, they 362 present several unique characteristics such as energy efficiency, 363 mobility degree, the capability of swarming, and the potential large 364 scale of swarm networks. Due to high mobility of FANET nodes, the 365 network topology changes more frequently than in a typical vehicular 366 ad hoc network. From a routing point of view, although ad-hoc 367 reactive and proactive routing approaches can be used, there are 368 other type of routing protocols that have been developed for FANETS, 369 such as hybrid routing protocols and position based routing 370 protocols, aiming to increase efficiency in large scale networks with 371 dynamic topologies. 373 Both type of protocols challenge the current Internet addressing 374 semantic: in the case of hybrid protocols, two different routing 375 strategies are used inside and outside a network zone. While inside 376 a zone packets are routed to a specific destination IP address, 377 between zones, query packets are routed to a subset of neighbors as 378 determined by a bordercast algorithm. In the case of position based 379 routing protocol, the IP addressing scheme is not used at all, since 380 packets are routing to a different identifier, corresponding to the 381 geographic location of the destination and not its topological 382 location. 384 Moreover most of the application/services deployed in FANETs tend to 385 be agnostic of the topological location of nodes, being instead focus 386 on the location of data or services. This distinction is even more 387 important because is dynamic network such as FANET robust networking 388 solutions may rely on the redundancy of data and services, meaning 389 that they may be found in more than one device in the network. 391 In the aforementioned network technologies, there is a significant 392 difference between the high dynamics of the underlying network 393 topologies, compared to the relative static nature of terrestrial 394 network topology, as reported in [HANDLEY]. As a consequence, the 395 notion of a topological network location becomes restrictive in the 396 sense that not only the relation between network nodes and user 397 endpoint may change, but also the relation between the nodes that 398 form the network itself. This may lead to the challenge of 399 maintaining and updating the topological addresses in this constantly 400 changing network topology. 402 In attempts to utilize entirely different semantics for the 403 addressing itself, geographic-based routing, such as in [CARTISEAN], 404 has been proposed for MANETs (Mobile Ad-hoc NETworks) through 405 providing geographic coordinates based addresses to achieve better 406 routing performance, lower overhead, and lower latency [MANET1]. 408 Flexibility in Internet addressing here would allow for accommodating 409 such geographic address semantics into the overall Internet 410 addressing, while also enabling name/content-based addressing, 411 utilizing the redundancy of many network locations providing the 412 possible data. 414 2.3. Communication among Moving Endpoints 416 When packet switching was first introduced, back in the 60s/70s, it 417 was intended to replace the rigid circuit switching with a 418 communication infrastructure that was more resilient to failures. As 419 such, the design never really considered communication endpoints as 420 mobile. Even in the pioneering ALOHA [ALOHA] system, despite 421 considering wireless and satellite links, the network was considered 422 static (with the exception of failures and satellites, which fall in 423 what is discussed in Section 2.2). Ever since, a lot of efforts have 424 been devoted to overcome such limitations once it became clear that 425 endpoint mobility will become a main (if not THE main) characteristic 426 of ubiquitous communication systems. 428 The IETF has for a long time worked on solutions that would allow 429 extending the IP layer with mobility support. Because of the 430 topological semantic of IP addresses, endpoints need to change 431 addresses each time they visit a different network. However, because 432 routing and endpoint identification is also IP address based, this 433 leads to a communication disruption. 435 To cope with such a situation, anchor-based Mobile IP mechanisms have 436 been introduced ([RFC5177], [RFC6626] [RFC5944], [RFC5275]). Mobile 437 IP is based on a relatively complex and heavy mechanism that makes it 438 hard to deploy and it is not very efficient. Furthermore, it is even 439 less suitable than native IP in constrained environments like the 440 ones discussed in Section 2.1. 442 Alternative approaches to Mobile IP often leverage the introduction 443 of some form of overlay. LISP [I-D.ietf-lisp-introduction], by 444 separating the topological semantic from the identification semantic 445 of IP addresses, is able to cope with endpoint mobility by 446 dynamically mapping endpoint identifiers with routing locators 447 [I-D.ietf-lisp-mn]. This comes at the price of an overlay that needs 448 its own additional control plane [I-D.ietf-lisp-rfc6833bis]. 450 Similarly, the NVO3 (Network Virtualization Overlays) Working Group, 451 while focusing on Data Center environments, also explored an overlay- 452 based solution for multi-tenancy purposes, but also resilient to 453 mobility since relocating Virtual Machines (VMs) is common practice. 454 NVO3 considered for a long time several data planes that implement 455 slightly different flavors of overlays ([RFC8926], [RFC7348], 456 [I-D.ietf-intarea-gue]), but lacks an efficient control plane 457 specifically tailored for DCs. 459 Alternative mobility architectures have also been proposed in order 460 to cope with endpoint mobility outside the IP layer itself. The Host 461 Identity Protocol (HIP) [RFC7401] introduced a new namespace in order 462 to identify endpoints, namely the Host Identity (HI), while 463 leveraging the IP layer for topological location. On the one hand, 464 such an approach needs to revise the way applications interact with 465 the network layer, by modifying the DNS (now returning an HI instead 466 of an IP address) and applications to use the HIP socket extension. 467 On the other hand, early adopters do not necessarily gain any benefit 468 unless all communicating endpoints upgrade to use HIP. In spite of 469 this, such a solution may work in the context of a limited domain. 471 Another alternative approach is adopted by Information-Centric 472 Networking (ICN) [RFC7476]. By making content a first class citizen 473 of the communication architecture, the "what" rather than the "where" 474 becomes the real focus of the communication. However, as explained 475 in the next sub-section, ICN can run either over the IP layer or 476 completely replace it, which in turn can be seen as running the 477 Internet and ICN as logically completely separated limited domains. 479 Sometimes, the transport layer gets involved in mobility solutions, 480 either by introducing explicit in-band signaling to allow for 481 communicating IP address changes (e.g., in SCTP [RFC5061] and MPTCP 482 [RFC6182]), or by introducing some form of connection ID that allows 483 for identifying a communication independently from IP addresses 484 (e.g., the connection ID used in QUIC [QUIC]). 486 Unmanned Aircraft Systems (UAS) are examples of moving devices that 487 require a stable mobility management scheme since they consist of a 488 number of Unmanned Aerial Vehicles (UAV) subordinated to a Ground 489 Control Station (GCS). The information produced by the different 490 sensors and electronic devices available at each UAV is collected and 491 processed by a software or hardware data acquisition unit, being 492 transmitted towards the GCS, where it is inspected and/or analyzed. 493 Analogously, control information transmitted from the GCS to the UAV 494 enables the execution of control operations over the aircraft, such 495 as changing the route planning or the direction pointed by a camera. 497 Although UAVs may have redundant links to maintain communications in 498 long-range missions (e.g., satellite), most of the communications 499 between the GCS and the UAVs take place over wireless data links, 500 e.g., based on a radio line-of-sight technology, Wi-Fi or 3G/4G. 501 While in some scenarios, UAVs will operate always under the range of 502 the same cellular base station, in missions with large range, UAVs 503 will move between different cellular or wireless ground 504 infrastructure, meaning that the UAV needs to upload its topological 505 locator and re-start the ongoing communication sessions. In such 506 cases, most of existing Mobile IP approaches may play a role, as well 507 as approaches to split the UAV identifier and the topological 508 locator, such as HIP. 510 However, while the industry is given the first steps towards evolved 511 UAS architectures and communication models, the data-centric 512 communication plays an increasing role, where information is named 513 and decoupled from its location, and applications/services operate 514 over these named data rather than on host-to-host communications. 516 In this context, the Data Distribution Service (DDS) has emerged as 517 an industry-oriented open standard that follows this approach. The 518 space and time decoupling allowed by DDS is very relevant in any 519 dynamic and distributed system, since interacting entities are not 520 forced to know each other and are not forced to be simultaneously 521 present to exchange data. Time decoupling can significantly simplify 522 the management of intermittent data-links, in particular for wireless 523 connectivity between UAS, as well as facilitate seamless UAV mobility 524 between GCSs. 526 In the case of using TCP/IP, mobility of UAVs introduces a 527 significant challenge. Consider the case where a GCS is receiving 528 telemetry information from a specific UAV. Assuming that the UAV 529 moves and changes its point of attachment to the network, it will 530 have to configure a new IP address on its wireless interface. 531 However, this is problematic, as the telemetry information is still 532 being sent by to the previous IP address of the UAV. This simple 533 example illustrates the necessity to deploy mobility management 534 solutions to handle this type of situations. 536 However, mobility management solutions increase the complexity of the 537 deployment and may impact the performance of data distribution, both 538 in terms of signaling/data overhead and communication path delay. 539 Considering the specific case of multicast data streams, mobility of 540 content producers and consumers is inherently handled by multicast 541 routing protocols, which are able to react to changes of location of 542 mobile nodes by reconstructing the corresponding multicast delivery 543 trees. Nevertheless, this comes with a cost in terms of signaling 544 and data overhead (data may still flow through branches of a 545 multicast delivery tree where there are no receivers while the 546 routing protocol does not converge). 548 Another alternative it to perform the mobility management of 549 producers and consumers not at the application layer based on IP 550 multicast trees, but on the network layer based on an Information 551 Centric Network approach, which was already mentioned in this 552 section. 554 Greater flexibility in addressing may help in dealing with mobility 555 more efficiently, e.g., through an augmented semantic that may fulfil 556 the mobility requirements [RFC7429]. 558 2.4. Communication Across Services 560 As a communication infrastructure spanning many facets of life, the 561 Internet integrates services and resources from various aspects such 562 as remote collaboration, shopping, content production as well as 563 delivery, education, and many more. Accessing those services and 564 resources directly through URIs has been proposed by methods such as 565 those defined in ICN [RFC7476], where providers of services and 566 resources can advertise those through unified identifiers without 567 additional planning of identifiers and locations for underlying data 568 and their replicas. Users can access required services and resources 569 by virtue of using the URI-based identification, with an ephemeral 570 relationship built between user and provider, while the building of 571 such relationship may be constrained with user- as well as service- 572 specific requirements, such as proximity (finding nearest provider), 573 load (finding fastest provider), and others. 575 While systems like ICN [CCN] provide an alternative to the locator- 576 based addressing of IP, its deployment requires an overlay (over IP) 577 or native deployment (alongside IP), the latter with dedicated 578 gateways needed for translation. Underlay deployments are also 579 envisioned in [RFC8763], where ICN solutions are being used to 580 facilitate communication between IP addressed network endpoints or 581 URI-based service endpoints, still requiring gateway solutions for 582 interconnection with ICN-based networks as well as IP routing based 583 networks (cf., [ICN5G][ICNIP]). 585 Although various approaches combining service and location-based 586 addressing have been devised, the key challenge here is to facilitate 587 a "natural", i.e., direct communication, without the need for 588 gateways above the network layer. 590 Another aspect of communication across services is that of chaining 591 individual services to a larger service. Here, an identifier would 592 be used that serves as a link to next hop destination within the 593 chain of single services, as done in the work on Service Function 594 Chaining (SFC). With this, services are identified at the level of 595 Layer 2/3 ([RFC7665], [RFC8754], [RFC8595]) or at the level of name- 596 based service identifiers like URLs [RFC8677] although the service 597 chain identification is carried as an NSH header ([RFC7665], separate 598 to the packet identifiers. The forwarding with the chain of services 599 utilizes individual locator-based IP addressing (for L3 chaining) to 600 communicate the chained operations from one Service Function 601 Forwarder [RFC7665] to another, leading to concerns regarding 602 overhead incurred through the stacking of those chained identifiers 603 in terms of packet overhead and therefore efficiency in handling in 604 the intermediary nodes. 606 Greater flexibility in addressing may allow for incorporating 607 different information, e.g., service as well as chaining semantics, 608 into the overall Internet addressing. 610 2.5. Steering Communication Traffic 612 Steering traffic within a communication scenario may involve at least 613 two aspects, namely (i) limiting certain traffic towards a certain 614 set of communication nodes and (ii) constraining the sending of 615 packets towards a given destination (or a chain of destinations) with 616 metrics that would allow the selection among one or more possible 617 destinations. 619 One possibility for limiting traffic inside limited domains, towards 620 specific objects, e.g., devices, users, or group of them, is subnet 621 partition with techniques such as VLAN [RFC5517], VxLAN [RFC7348], or 622 more evolved solution like TeraStream [TERASTREAM] realizing such 623 partitioning. Such mechanisms usually involve significant 624 configuration, and even small changes in network and user nodes could 625 result in a repartition and possibly additional configuration 626 efforts. Another key aspect is the complete lack of correlation of 627 the topological address and any likely more semantic-rich 628 identification that could be used to make policy decisions regarding 629 traffic steering. Suitably enriching the semantics of the packet 630 address, either that of the sender or receiver, so that such decision 631 could be made while minimizing the involvement of higher layer 632 mechanisms, is a crucial challenge for improving on network 633 operations and speed of such limited domain traffic. 635 When making decisions to select one out of a set of possible 636 destinations for a packet, IP anycast semantics can be applied albeit 637 being limited to the locator semantic of the IP address itself. 638 Recent work in [SFCANYCAST] suggests utilizing the notion of IP 639 anycast address to encode a "service identifier", which is 640 dynamically mapped onto network locations where service instances 641 fulfilling the service request may be located. Scenarios where this 642 capability may be utilized are provided in [SFCANYCAST] and include, 643 but are not limited to, scenarios such as edge-assisted VR/AR, 644 transportation, and digital twins. 646 The challenge here lies in the possible encoding of not only the 647 service information itself but the constraint information that helps 648 the selection of the "best" service instance and which is likely a 649 service-specific constraint in relation to the particular scenario. 650 The notion of an address here is a conditional (on those constraints) 651 one where this conditional part is an essential aspect of the 652 forwarding action to be taken. It needs therefore consideration in 653 the definition of what an address is, what is its semantic, and how 654 the address structure ought to look like. 656 As outlined in the previous sub-section, chaining services are 657 another aspect of steering traffic along a chain of constituent 658 services, where the chain is identified through either a stack of 659 individual identifiers, such as in Segment Routing [RFC8402], or as 660 an identifier that serves as a link to next hop destination within 661 the chain, such as in Service Function Chaining (SFC). The latter 662 can be applied to services identified at the level of Layer 2/3 663 ([RFC7665], [RFC8754], [RFC8595]) or at the level of name-based 664 service identifiers like URLs [RFC8677]. However, the overhead 665 incurred through the stacking of those chained identifiers is a 666 concern in terms of packet overhead and therefore efficiency in 667 handling in the intermediary nodes. 669 Flexibility in addressing may enable more semantic rich encoding 670 schemes that may help in steering traffic at hardware level and 671 speed, without complex mechanisms usually resulting in handling 672 packets in the slow path of routers. 674 2.6. Communication with built-in security 676 Today, strong security and privacy in the Internet is usually 677 implemented as an overlay based on the concept of Mix Networks 678 ([TOR], [SPHINX]). Among the various reasons for such approach is 679 the limited semantic of current IP addresses, which do not allow to 680 natively express security features or trust relationships. Efforts 681 like Cryptographically Generated Addresses (CGA) [RFC3972], provide 682 some security features by embedding a truncated public key in the 683 last 57-bit of IPv6 address, thereby greatly enhancing authentication 684 and security within an IP network via asymmetric cryptography and 685 IPsec [RFC4301]. The development of the Host Identity Protocol (HIP) 686 [RFC7401] saw the introduction of cryptographic identifiers for the 687 newly introduced Host Identity (HI) to allow for enhanced 688 accountability, and therefore trust. The use of those HIs, however, 689 is limited by the size of IPv6 128bit addresses. 691 Through a greater flexibility in addressing, any security-related 692 key, certificate, or identifier could instead be included in a 693 suitable address structure without any information loss (i.e., as-is, 694 without any truncation or operation as such), avoiding therefore 695 compromises such as those in HIP. Instead, CGAs could be created 696 using full length certificates, or being able to support larger HIP 697 addresses in a limited domain that uses it. This could significantly 698 help in constructing a trusted and secure communication at the 699 network layer, leading to connections that could be considered as 700 absolute secure (assuming the cryptography involved is secure). Even 701 more, anti-abuse mechanisms and/or DDoS protection mechanisms like 702 the one under discussion in PEARG ([PEARG]) Research Group may 703 leverage a greater flexibility of the overall Internet addressing, if 704 provided, in order to be more effective. 706 2.7. Communication in Alternative Forwarding Architectures 708 The performance of communication networks has long been a focus for 709 optimization due to the immediate impact on cost of ownership for 710 communication service providers. Technologies like MPLS [RFC3031] 711 have been introduced to optimize lower layer communication, e.g., by 712 mapping L3 traffic into aggregated labels of forwarding traffic for 713 the purposes of, e.g., traffic engineering. 715 Even further, other works have emerged in recent years that have 716 replaced the notion of packets with other concepts for the same 717 purpose of improved traffic engineering and therefore efficiency 718 gains. One such area is that of Software Defined Networks (SDN) 720 [RFC7426], which has highlighted how a majority of Internet traffic 721 is better identified by flows, rather than packets. Based on such 722 observation, alternate forwarding architectures have been devised 723 that are flow-based or path-based. With this approach, all data 724 belonging to the same traffic stream is delivered over the same path, 725 and traffic flows are identified by some connection or path 726 identifier rather than by complete routing information, possibly 727 enabling fast hardware based switching. 729 On the one hand, such a communication model may be more suitable for 730 real-time traffic like in the context of Deterministic Networks 731 ([DETNET]), where indeed a lot of work has focused on how to 732 "identify" packets belonging to the same DETNET flow in order to 733 jointly manage the forwarding within the desired deterministic 734 boundaries. 736 On the other hand, it may improve the communication efficiency in 737 constrained wireless environments (cf., Section 2.1), by reducing the 738 overhead, hence increasing the number of useful bits per second per 739 Hz. 741 Also, the delivery of information across similar flows may be 742 combined into a multipoint delivery of a single return flow, e.g., 743 for scenarios of requests for a video chunk from many clients being 744 responded to with a single (multi-destination) flow, as outlined in 745 [BIER-MC] as an example. Another opportunity to improve 746 communication efficiency is being pursued in ongoing IETF/IRTF work 747 to deliver IP- or HTTP-level packets directly over path-based or 748 flow-based transport network solutions, such as in 749 [TROSSEN][BIER-MC][ICNIP][ICN5G] with the capability to bundle 750 unicast forward communication streams flexibly together in return 751 path multipoint relations. Such capability is particularly opportune 752 in scenarios such as chunk-based video retrieval or distributed data 753 storage. However, those solutions currently require gateways to 754 "translate" the flow communication into the packet-level addressing 755 semantic in the peering IP networks. Furthermore, the use of those 756 alternative forwarding mechanisms often require the encapsulation of 757 Internet addressing information, leading to wastage of bandwidth as 758 well as processing resources. 760 Providing an alternative way of forwarding data has also been the 761 motivation for the efforts created in the European Telecommunication 762 Standards Institute (ETSI), which formed a Industry Specification 763 Group (ISG) named Non-IP Networking (NIN) [ETSI-NIN]. This group 764 sets out to develop and standardize a set of protocols leveraging an 765 alternative forwarding architecture, such as provided by a flow-based 766 switching paradigm. The deployment of such protocols may be seen to 767 form limited domains, still leaving the need to interoperate with the 768 (packet-based forwarding) Internet; a situation possibly enabled 769 through a greater flexibility of the addressing used across Internet- 770 based and alternative limited domains alike. 772 As an alternative to IP routing, EIBP (Extended Internet Bypass 773 Protocol) [EIBP] offers a communications model that can work with IP 774 in parallel and entirely transparent and independent to any operation 775 at network layer. For this, EIBP proposes the use of physical and/or 776 virtual structures in networks and among networks to auto assign 777 routable addresses that capture the relative position of routers in a 778 network or networks in a connected set of networks, which can be used 779 to route the packets between end domains. EIBP operates at Layer 2.5 780 and provides encapsulation (at source domain), routing, and de- 781 encapsulation (at destination domain) for packets. EIBP can forward 782 any type of packets between domains. A resolver to map the domain ID 783 to EIBP's edge router addresses is required. When queried for a 784 specific domain, the resolver will return the corresponding edge 785 router structured addresses. 787 EIBP decouples routing operations from end domain operations, 788 offering to serve any domain, without point solutions to specific 789 domains. EIBP also decouples routing IDs or addresses from end 790 device/domain addresses. This allows for accommodation of new and 791 upcoming domains. A domain can extend EIBP's structured addresses 792 into the domain, by joining as a nested domain under one or more edge 793 routers, or by extending the edge router's structure addresses to its 794 devices. 796 A greater flexibility in addressing semantics may reduce the 797 aforementioned wastage by accommodating Internet addressing in the 798 light of such alternative forwarding architectures, instead enabling 799 the direct use of the alternative forwarding information. 801 3. Issues in Addressing 803 There are a number of issues that we can identify from the 804 communication scenarios in Section 2, not claiming to be exhaustive 805 in our list: 807 1. Limiting Alternative Address Semantics: Several communication 808 scenarios pursue the use of alternative semantics of what 809 constitute an 'address' of a packet traversing the Internet, 810 which may fall foul of the defined network interface semantic of 811 IP addresses. 813 2. Hampering Security: Aligning with the semantic and length 814 limitations of IP addressing may hamper the security objectives 815 of any new semantic, possibly leading to detrimental effects and 816 possible other workarounds (at the risk of introducing fragility 817 rather than security). 819 3. Complicating Traffic Engineering: Utilizing a plethora of non- 820 address inputs into the traffic steering decision in real 821 networks complicates traffic engineering in that it makes the 822 development of suitable policies more complex, while also leading 823 to possible contention between methods being used. 825 4. Hampering Efficiency: Extending IP addressing through point-wise 826 solutions also hampers efficiency, e.g., through needed re- 827 encapsulation (therefore increasing the header processing 828 overhead as well as header-to-payload ratio), through introducing 829 path stretch, or through requiring compression techniques to 830 reduce the header proportion of large addresses when operating in 831 constrained environments. 833 5. Fragility: The introduction of point solutions, each of which 834 comes with possibly own usages of address or packet fields, 835 together with extension-specific operations, increases the 836 overall fragility of the resulting system, caused, for instance, 837 through contention between feature extensions that were neither 838 foreseen in the design nor tested during the implementation 839 phase. 841 6. Extensibility: Accommodating new requirements through ever new 842 extensions as an extensibility approach to addressing compounds 843 aspects discussed before, i.e., fragility, efficiency etc. It 844 complicates engineering due to the clearly missing boundaries 845 against which contentions with other extensions could be managed. 846 It complicates standardization since extension-based 847 extensibility requires independent, and often lengthy, 848 standardization processes. And ultimately, deployments are 849 complicated due to backward compatibility testing required for 850 any new extension being integrated into the deployed system. 852 The table below shows how the above identified issues do arise 853 somehow in our outlined communication scenarios in Section 2. This 854 overview will be deepened in more detail in the gap analysis document 855 [GAP_ANALYSIS]. 857 +-------------------+-------+-------+-------+-------+-------+-------+ 858 | | Issue | Issue | Issue | Issue | Issue | Issue | 859 | | 1 | 2 | 3 | 4 | 5 | 6 | 860 +-------------------+-------+-------+-------+-------+-------+-------+ 861 | Constrained | | | | x | x | x | 862 | Environments | | | | | | | 863 | | | | | | | | 864 | Dynamically | x | | x | x | x | x | 865 | Changing | | | | | | | 866 | Topologies | | | | | | | 867 | | | | | | | | 868 | Moving Endpoints | x | | x | x | x | x | 869 | | | | | | | | 870 | Across Services | x | | x | x | x | x | 871 | | | | | | | | 872 | Traffic Steering | x | | x | x | x | x | 873 | | | | | | | | 874 | Built-in Security | x | x | | x | x | x | 875 | | | | | | | | 876 | Alternative | x | | | x | | x | 877 | Forwarding | | | | | | | 878 | Architectures | | | | | | | 879 +-------------------+-------+-------+-------+-------+-------+-------+ 881 Table 1: Issues Involved in Challenging Scenarios 883 4. Problem Statement 885 This document highlights that the conceptual framework of limited 886 domains positions the many extensions to IP addressing as approaches 887 to accommodate new requirements in emerging communication scenarios, 888 each of which are being often deployed within limited domains. 890 While this may be interpreted as a crucial point to the flexibility 891 of addressing in the Internet in order to accommodate those ever 892 increasing number of communication scenarios, we have identified a 893 number of issues (as described in this document) that position the 894 existing Internet addressing structure itself as a potential 895 hinderance in solving key problems for Internet service provisioning. 896 Such problems include supporting new, e.g., service-oriented, 897 scenarios more efficiently, with improved security and efficient 898 traffic engineering, as well as large scale mobility. 900 Referring back to our introductory question on flexibility in 901 addressing (or leaving the problem to limited domain solutions to 902 deal with), we offer at this stage no definite answer nor do we 903 propose or promote specific solutions to the problems here portrayed. 904 Instead, this document aims at stimulating discussion on the emerging 905 needs for addressing with the possibility to fundamentally re-think 906 the addressing in the Internet beyond the current objectives of IPv6. 908 To complement our problem statement in this document, the companion 909 gap analysis document [GAP_ANALYSIS] deepens the issues identified in 910 Section 3 along key properties of today's Internet addressing. 912 5. Security Considerations 914 The present memo does not introduce any new technology and/or 915 mechanism and as such does not introduce any security threat to the 916 TCP/IP protocol suite. 918 Nevertheless, it is worth to observe whether or not greater 919 flexibility of addressing (as suggested in previous sections) would 920 allow to introduce fully featured security in endpoint 921 identification, potentially able to eradicate the spoofing problem, 922 as one example. Furthermore, it may be used to include application 923 gateways' certificates in order to provide more efficiency, e.g., 924 using web certificates also in the addressing of web services. While 925 increasing security, privacy protection may also be improved. 927 6. IANA Considerations 929 This document does not include an IANA request. 931 7. Informative References 933 [ALOHA] Kuo, F., "The ALOHA System", ACM SIGCOMM Computer 934 Communication Review Vol. 25, pp. 41-44, 935 DOI 10.1145/205447.205451, January 1995. 937 [BACnet] "BACnet-A Data Communication Protocol for Building 938 Automation and Control Networks", ANSI/ASHRAE Standard 939 135-2016, January 2016, 940 . 943 [BIER-MC] Trossen, D., Rahman, A., Wang, C., and T. Eckert, 944 "Applicability of BIER Multicast Overlay for Adaptive 945 Streaming Services", draft-ietf-bier-multicast-http- 946 response-05 (work in progress), January 2021. 948 [BLE] "Bluetooth Specification", Bluetooth SIG Working Groups, 949 n.d., . 951 [CARTISEAN] 952 Hughes, L., Shumon, K., and Y. Zhang, "Cartesian Ad Hoc 953 Routing Protocols", Ad-Hoc, Mobile, and Wireless 954 Networks pp. 287-292, DOI 10.1007/978-3-540-39611-6_27, 955 2003. 957 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 958 Briggs, N., and R. Braynard, "Networking named content", 959 Proceedings of the 5th international conference on 960 Emerging networking experiments and technologies - 961 CoNEXT '09, DOI 10.1145/1658939.1658941, 2009. 963 [DECT-ULE] 964 "Digital Enhanced Cordless Telecommunications (DECT); 965 Common Interface (CI); Part 1: Overview", ETSI European 966 Standard, EN 300 175-1, V2.6.1, May 2009, 967 . 971 [DETNET] "Deterministic Networking (DetNet)", n.d., 972 . 974 [ECMA-340] 975 EECMA-340, "Near Field Communication - Interface and 976 Protocol (NFCIP-1) 3rd Ed.", June 2013. 978 [EIBP] Shenoy, N., Chandraiah, S., and P. Willis, "A Structured 979 Approach to Routing in the Internet", First Intl Workshop 980 on Semantic Addressing and Routing for Future Networks , 981 June 2021. 983 [ETSI-NIN] 984 ETSI - European Telecommunication Standards Institute, 985 "Non-IP Networking - NIN", n.d., 986 . 988 [GAP_ANALYSIS] 989 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., and P. 990 Mendes, "Gap Analysis in Internet Addressing", July 2021, 991 . 994 [HANDLEY] Handley, M., "Delay is Not an Option: Low Latency Routing 995 in Space", Proceedings of the 17th ACM Workshop on Hot 996 Topics in Networks, DOI 10.1145/3286062.3286075, November 997 2018. 999 [I-D.ietf-intarea-gue] 1000 Herbert, T., Yong, L., and O. Zia, "Generic UDP 1001 Encapsulation", draft-ietf-intarea-gue-09 (work in 1002 progress), October 2019. 1004 [I-D.ietf-lisp-introduction] 1005 Cabellos, A. and D. Saucez, "An Architectural Introduction 1006 to the Locator/ID Separation Protocol (LISP)", draft-ietf- 1007 lisp-introduction-13 (work in progress), April 2015. 1009 [I-D.ietf-lisp-mn] 1010 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1011 Mobile Node", draft-ietf-lisp-mn-09 (work in progress), 1012 February 2021. 1014 [I-D.ietf-lisp-nexagon] 1015 Barkai, S., Fernandez-Ruiz, B., ZionB, S., Tamir, R., 1016 Rodriguez-Natal, A., Maino, F., Cabellos-Aparicio, A., and 1017 D. Farinacci, "Network-Hexagons: H3-LISP GeoState & 1018 Mobility Network", draft-ietf-lisp-nexagon-07 (work in 1019 progress), February 2021. 1021 [I-D.ietf-lisp-rfc6833bis] 1022 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1023 "Locator/ID Separation Protocol (LISP) Control-Plane", 1024 draft-ietf-lisp-rfc6833bis-30 (work in progress), November 1025 2020. 1027 [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G. 1028 White, "Enabling ICN in 3GPP's 5G NextGen Core 1029 Architecture", draft-irtf-icnrg-5gc-icn-04 (work in 1030 progress), January 2021. 1032 [ICNIP] Trossen, D., Robitzsch, S., Reed, M., Al-Naday, M., and J. 1033 Riihijarvi, "Internet Services over ICN in 5G LAN 1034 Environments", draft-trossen-icnrg-internet-icn-5glan-04 1035 (work in progress), October 2020. 1037 [IEEE_1901.1] 1038 "Standard for Medium Frequency (less than 15 MHz) Power 1039 Line Communications for Smart Grid Applications", IEEE 1040 1901.1 IEEE-SA Standards Board, May 2018, 1041 . 1043 [LR-WPAN] "IEEE 802.15.4 - IEEE Standard for Low-Rate Wireless 1044 Networks", IEEE 802.15 WPAN Task Group 4, May 2020, 1045 . 1047 [MANET1] Abdallah, A., Abdallah, E., Bsoul, M., and A. Otoom, 1048 "Randomized geographic-based routing with nearly 1049 guaranteed delivery for three-dimensional ad hoc network", 1050 International Journal of Distributed Sensor Networks Vol. 1051 12, pp. 155014771667125, DOI 10.1177/1550147716671255, 1052 October 2016. 1054 [OCADO] "Ocado Technology's robot warehouse a Hive of IoT 1055 innovation", n.d., . 1058 [PEARG] "Privacy Enhancements and Assessments Research Group - 1059 PEARG", n.d., . 1061 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1062 and Secure Transport", draft-ietf-quic-transport-34 (work 1063 in progress), January 2021. 1065 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1066 DOI 10.17487/RFC0791, September 1981, 1067 . 1069 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1070 DOI 10.17487/RFC2775, February 2000, 1071 . 1073 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1074 Label Switching Architecture", RFC 3031, 1075 DOI 10.17487/RFC3031, January 2001, 1076 . 1078 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1079 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1080 . 1082 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1083 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1084 December 2005, . 1086 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1087 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1088 Overview, Assumptions, Problem Statement, and Goals", 1089 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1090 . 1092 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1093 Kozuka, "Stream Control Transmission Protocol (SCTP) 1094 Dynamic Address Reconfiguration", RFC 5061, 1095 DOI 10.17487/RFC5061, September 2007, 1096 . 1098 [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 1099 "Network Mobility (NEMO) Extensions for Mobile IPv4", 1100 RFC 5177, DOI 10.17487/RFC5177, April 2008, 1101 . 1103 [RFC5275] Turner, S., "CMS Symmetric Key Management and 1104 Distribution", RFC 5275, DOI 10.17487/RFC5275, June 2008, 1105 . 1107 [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private 1108 VLANs: Scalable Security in a Multi-Client Environment", 1109 RFC 5517, DOI 10.17487/RFC5517, February 2010, 1110 . 1112 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1113 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1114 . 1116 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1117 Iyengar, "Architectural Guidelines for Multipath TCP 1118 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 1119 . 1121 [RFC6626] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, 1122 "Dynamic Prefix Allocation for Network Mobility for Mobile 1123 IPv4 (NEMOv4)", RFC 6626, DOI 10.17487/RFC6626, May 2012, 1124 . 1126 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1127 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1128 eXtensible Local Area Network (VXLAN): A Framework for 1129 Overlaying Virtualized Layer 2 Networks over Layer 3 1130 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1131 . 1133 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1134 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1135 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1136 . 1138 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1139 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1140 Defined Networking (SDN): Layers and Architecture 1141 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1142 2015, . 1144 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1145 CJ. Bernardos, "Distributed Mobility Management: Current 1146 Practices and Gap Analysis", RFC 7429, 1147 DOI 10.17487/RFC7429, January 2015, 1148 . 1150 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1151 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1152 "Information-Centric Networking: Baseline Scenarios", 1153 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1154 . 1156 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1157 Chaining (SFC) Architecture", RFC 7665, 1158 DOI 10.17487/RFC7665, October 2015, 1159 . 1161 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1162 (IPv6) Specification", STD 86, RFC 8200, 1163 DOI 10.17487/RFC8200, July 2017, 1164 . 1166 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1167 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1168 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1169 July 2018, . 1171 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1172 Forwarding Plane for Service Function Chaining", RFC 8595, 1173 DOI 10.17487/RFC8595, June 2019, 1174 . 1176 [RFC8677] Trossen, D., Purkayastha, D., and A. Rahman, "Name-Based 1177 Service Function Forwarder (nSFF) Component within a 1178 Service Function Chaining (SFC) Framework", RFC 8677, 1179 DOI 10.17487/RFC8677, November 2019, 1180 . 1182 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1183 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1184 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1185 . 1187 [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1188 "Deployment Considerations for Information-Centric 1189 Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 1190 2020, . 1192 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1193 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1194 . 1196 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 1197 "Geneve: Generic Network Virtualization Encapsulation", 1198 RFC 8926, DOI 10.17487/RFC8926, November 2020, 1199 . 1201 [SFCANYCAST] 1202 Wion, A., Bouet, M., Iannone, L., and V. Conan, 1203 "Distributed Function Chaining with Anycast Routing", 1204 Proceedings of the 2019 ACM Symposium on SDN Research, 1205 DOI 10.1145/3314148.3314355, April 2019. 1207 [SPHINX] Danezis, G. and I. Goldberg, "Sphinx: A Compact and 1208 Provably Secure Mix Format", 2009 30th IEEE Symposium on 1209 Security and Privacy, DOI 10.1109/sp.2009.15, May 2009. 1211 [TERASTREAM] 1212 "Deutsche Telekom tests TeraStream, the network of the 1213 future, in Croatia", n.d., 1214 . 1218 [TOR] "The Tor Project", n.d., . 1220 [TROSSEN] Trossen, D., Sarela, M., and K. Sollins, "Arguments for an 1221 information-centric internetworking architecture", ACM 1222 SIGCOMM Computer Communication Review Vol. 40, pp. 26-33, 1223 DOI 10.1145/1764873.1764878, April 2010. 1225 Appendix A. Change Log 1227 *NOTES*: Please remove this section prior to publication of a final 1228 version of this document. 1230 A.1. Since draft-jia-intarea-scenarios-problems-addressing-00 1232 o Simplify the 'issues' section with simpler bullet list. 1234 o Several editorial changes to create a clear link with the gap 1235 analysis. 1237 o Added issues and scenarios mapping Table. 1239 Acknowledgments 1241 Thanks to Stewart Bryant for useful conversations. Ron Bonica, 1242 Toerless Eckert and Brian E. Carpenter made helpful suggestions. 1244 Authors' Addresses 1246 Yihao Jia 1247 Huawei Technologies Co., Ltd 1248 156 Beiqing Rd. 1249 Beijing 100095 1250 P.R. China 1252 Email: jiayihao@huawei.com 1254 Dirk Trossen 1255 Huawei Technologies Duesseldorf GmbH 1256 Riesstr. 25C 1257 Munich 80992 1258 Germany 1260 Email: dirk.trossen@huawei.com 1262 Luigi Iannone 1263 Huawei Technologies France S.A.S.U. 1264 18, Quai du Point du Jour 1265 Boulogne-Billancourt 92100 1266 France 1268 Email: luigi.iannone@huawei.com 1270 Nirmala Shenoy 1271 Rochester Institute of Technology 1272 New-York 14623 1273 USA 1275 Email: nxsvks@rit.edu 1276 Paulo Mendes 1277 Airbus 1278 Willy-Messerschmitt Strasse 1 1279 Munich 81663 1280 Germany 1282 Email: paulo.mendes@airbus.com 1284 Donald E. Eastlake 3rd 1285 Futurewei Technologies 1286 2386 Panoramic Circle 1287 Apopka, FL 32703 1288 United States of America 1290 Email: d3e3e3@gmail.com 1292 Peng Liu 1293 China Mobile 1294 32 Xuanwumen West Ave 1295 Xicheng, Beijing 100053 1296 P.R. China 1298 Email: liupengyjy@chinamobile.com