idnits 2.17.00 (12 Aug 2021) /tmp/idnits17206/draft-trossen-rtgwg-routing-beyond-reachability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 98 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 540: '... Internet's routing system MUST take a...' RFC 2119 keyword, line 547: '... these works MUST be brought into ...' RFC 2119 keyword, line 553: '... 3. The RTG WG SHOULD play a role in...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (8 February 2022) is 95 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CLNPref' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'CONTENTref' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-ext-hdr-update' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'I-D.bryant-arch-fwd-layer-ps' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'I-D.chunduri-lsr-isis-preferred-path-routing' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'I-D.farrel-irtf-introduction-to-semantic-routing' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ipv6-ehs-packet-drops' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-panrg-path-properties' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-dyncast-ps-usecases' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'I-D.muscariello-intarea-hicn' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'ISISref' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC1069' is defined on line 837, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RFC2992' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC7872' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC8684' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC8736' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 1042, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-bonica-6man-ext-hdr-update-06 == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-03 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-16) exists of draft-ietf-teas-rfc3272bis-13 == Outdated reference: draft-ietf-v6ops-ipv6-ehs-packet-drops has been published as RFC 9098 == Outdated reference: A later version (-05) exists of draft-irtf-panrg-path-properties-04 == Outdated reference: draft-irtf-panrg-what-not-to-do has been published as RFC 9049 == Outdated reference: A later version (-02) exists of draft-jia-intarea-internet-addressing-gap-analysis-01 == Outdated reference: A later version (-05) exists of draft-li-apn-framework-04 == Outdated reference: A later version (-03) exists of draft-li-dyncast-architecture-01 == Outdated reference: A later version (-03) exists of draft-liu-dyncast-ps-usecases-02 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 31 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Trossen 3 Internet-Draft D. Lou 4 Intended status: Informational S. Jiang 5 Expires: 12 August 2022 Huawei Technologies 6 8 February 2022 8 Continuing to Evolve Internet Routing Beyond 'Mere' Reachability 9 draft-trossen-rtgwg-routing-beyond-reachability-00 11 Abstract 13 This document discusses the evolution of the Internet routing system 14 beyond mere reachability. We observe, through examples of past 15 development, that such evolution has been taking place to improve on 16 capabilities of the Internet, deal with more complicated network 17 deployments and cater to changing requirements by end users as well 18 as novel and emerging applications. 20 For achieving a routing system that serves more than a singular 21 reachability purpose, more information is taken into account when 22 performing the purpose-specific functions. Such extra information 23 can be obtained by extending current routing protocols to exchange 24 more information or by carrying that information within packets. 26 This document is intended to seed discussions of how the observed 27 evolution of the Internet's routing system can continue, what issues 28 may occur when simply continuing the current approach for achieving 29 routing beyond 'mere' reachability and what may be needed to address 30 those issues. Ultimately, however, this document recognizes the 31 positive impact that moving beyond reachability has brought to the 32 Internet and will continue to do so. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 12 August 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Reachability - Original Purpose of the Routing System . . . . 4 68 3. Extension of the Routing System Beyond 'Mere' Reachability . 5 69 4. Issues with Current Approaches . . . . . . . . . . . . . . . 8 70 4.1. Limiting Routing Semantics . . . . . . . . . . . . . . . 8 71 4.2. Complexity and Efficiency . . . . . . . . . . . . . . . . 9 72 4.2.1. Repetitive encapsulation . . . . . . . . . . . . . . 9 73 4.2.2. Introducing Path Stretch . . . . . . . . . . . . . . 10 74 4.2.3. Complicating Traffic Engineering . . . . . . . . . . 10 75 4.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.4. Fragility . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.5. Interoperability . . . . . . . . . . . . . . . . . . . . 11 78 5. Where to Go From Here? . . . . . . . . . . . . . . . . . . . 12 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11. Informative References . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 87 1. Introduction 89 The current routing system was initially designed for a single 90 purpose - reachability. That is, it was built to find paths through 91 the network so as to forward packets to their destinations. The 92 routing system has successfully supported the Internet as it grew 93 from a very small scale network to a giant system that covers the 94 whole world with billions attached devices and users. This routing 95 system has done a good job for global reachability, however, through 96 the years, many other needs or purposes have arisen in the Internet, 97 such as hostname/address mapping, destination selection, security, 98 privacy, group isolation, various QoS requirements etc. Many of 99 these additional needs or purposes have resulted in the development 100 of extended and distinct systems, such as DNS, patched firewall, DPI, 101 and CDN, etc. These systems have worked well but with costs in terms 102 of quality of experience for the user, particularly with respect to 103 time delay, but also with respect to costs of development, deployment 104 and management throughout (parts of) the Internet. 106 An alternative approach is the integration of extra capabilities and 107 purposes into the routing system directly. By exchanging necessary 108 additional information or including such information in the packet 109 header, purposes beyond just reachability have found entry into the 110 routing system over the many years of the Internet's development. 112 This document presents a brief survey of solutions that, when 113 combined, represent a routing system beyond reachability that 114 effectively forms today's Internet. While this survey somewhat 115 relates to that presented in [I-D.king-irtf-semantic-routing-survey], 116 our focus here is on the identification of the underlying purpose for 117 developing extensions, not on the body of work that represents an 118 approach for doing so (named 'semantic routing' in the above draft). 119 However, [I-D.king-irtf-semantic-routing-survey] may be useful for 120 more information on the specific extensions. 122 Some of these extensions are intended to be deployed in limited 123 domains [RFC8799], while others are intended for use across the 124 Internet. The boundary of limited domains may also be the boundary 125 of purposes and semantics of information defining those purposes. 126 This survey is used to demonstrate the recognized need by those 127 having developed existing solutions for the Internet's routing system 128 to have multiple purposes beyond mere reachability. 130 Building on the survey and our summary, we recognize that, in many 131 parts, the Internet has already evolved into a 'multi-purpose 132 routing' system. However, we identify issues with the approach that 133 has been taken so far, namely that of purpose-specific extensions. 134 We assert that these issues will increasingly impede the Internet's 135 ability to accommodate future purposes (represented in the form of 136 new use cases), if we simply continue with a 'business as usual' 137 attitude towards developing purpose-specific solutions for them. 139 Instead, we position this document as the starting point for a 140 discussion on how to evolve the Internet routing system in a coherent 141 manner that will help us avoid the identified issues, while still 142 allowing for integrating new purposes for Internet routing as they 143 will emerge in the future. 145 Note: This document does not discuss how routers may use policies, 146 that are coded in, configured at, or signaled to it, to make routing 147 decisions. It does neither pass comment on the advisability or 148 practicality of any of the proposals nor does it define any technical 149 solutions. 151 2. Reachability - Original Purpose of the Routing System 153 Network routing protocols were initially designed to enable 154 forwarding of IP packets through the network toward destination 155 addresses. Fundamental to this is the locator semantic of IP 156 addresses, which has been assigned in the context of network 157 topologies. The original routing system was designed on a 158 distributed basis. Each router makes its own decision about the 159 interface/link onto which it forwards a packet. Each decision takes 160 the packet one hop closer to the destination. However, the choices 161 made by distributed devices may not always work well if they are 162 poorly coordinated between the routers, resulting in issues, such as 163 forwarding loops, which may be transitory or permanent. So it is 164 normal to require the use of the same algorithm to decide the 165 forwarding actions at each hop. 167 A way to avoid routing issues is to select an end-to-end path a 168 priori and consistently execute forwarding on the intermediate 169 routers accordingly. This element of traffic engineering is known as 170 "path steering" [I-D.ietf-teas-rfc3272bis] and relies on the routing 171 to protocols collect and exchange the reachability within a domain, 172 so that any routers can select an end-to-end path . However, the 173 amount of information needed to support these decisions can become 174 very large (e.g., in large networks, with many possible paths and 175 route metrics), which might impede the scalability both in terms of 176 the storage and the distribution of the information. Although 177 network topology filters are often applied to reduce the storage of 178 the network data and the complexity of the computation algorithm, the 179 path computation accuracy and optimality may be negatively impacted. 181 The Internet is a very complicated system that is made up of many 182 independently built networks with two types of routing protocols: an 183 interior gateway protocol (IGP) that routes inside a network and an 184 exterior gateway protocol (such as BGP) that routes between networks. 185 For a communication that crosses more than one domain, there could be 186 many possible paths for the given destination. In principle, the 187 more information that decision-making devices have, the better 188 choices they can make. However, it is often infeasible to have all 189 information of all potential end-to-end paths, particularly for 190 communications through several networks with different ownership. 191 Consequently, the best choices made within each domain may not reach 192 the best overall result. A key challenge here is the tussle between 193 abstraction, needed for scalability, and optimality, which 194 abstraction may impede. 196 When choosing the best paths or topology structures, the following 197 may need to be considered: 199 * The method by which a path, or set of paths, is to be calculated. 200 For example, a path may be selected automatically by the routing 201 protocol or may be imposed (perhaps for traffic engineering 202 reasons) by a central controller or management entity. 204 * The criteria used for selecting the best path. For example, 205 classic route preference, or administrative policies such as 206 economic costs, resilience, security, and (if requested) applying 207 geopolitical considerations. 209 3. Extension of the Routing System Beyond 'Mere' Reachability 211 In the following, we provide a brief overview of routing extensions 212 with purposes beyond 'mere' reachability. We align our overview with 213 many of the solutions described in 214 [I-D.king-irtf-semantic-routing-survey] and refer to this draft for 215 more detail, in addition to the example references themselves. 217 The following Table 1 focusses on three key aspects when considering 218 routing extensions for our discussion in this draft: 220 * Purpose: What is the intended purpose of the proposed extension? 221 This aspect may lead to a taxonomy for looking at the capabilities 222 of a multi-purpose routing system. 224 * Approach: What is the underlying technical approach to achieve the 225 intended purpose? This aspect may lead to a taxonomy of 226 approaches for achieving desired routing purposes. 228 * Examples: What are known examples that have employed the given 229 approach to achieve the given routing purpose? This aspect 230 provides a possibly growing catalogue of explicit examples to 231 study in more detail. 233 +==============+===============+======================================+ 234 | Purpose | Approach | Examples | 235 +==============+===============+======================================+ 236 |Path Selection| Preferential | IS-IS Extensions [RFC5305] | 237 | for Traffic | Routing | | 238 | Engineering | | | 239 +--------------+---------------+--------------------------------------+ 240 | | Policy-based | PBR models [RFC1104] Inter-domain | 241 | | Routing | policy routing [RFC1479] | 242 +--------------+---------------+--------------------------------------+ 243 | | Flow Steering | TBD | 244 +--------------+---------------+--------------------------------------+ 245 | | Path | PCE [RFC4655] PCEP [RFC5440] PCEP | 246 | | Computation | Extension [RFC8231] | 247 +--------------+---------------+--------------------------------------+ 248 | | IRTF | Path-aware Networking RG [PANRGref] | 249 | | | Path properties | 250 | | |[I-D.irtf-panrg-path-properties] Past | 251 | | | efforts evaluation | 252 | | | [I-D.irtf-panrg-what-not-to-do] | 253 +--------------+---------------+--------------------------------------+ 254 |Path Selection| Multicast |IP multicast [RFC1112] IPv6 addressing| 255 |for Multicast | | [RFC4291] MBone [MBONEref] MADCAP | 256 | | | [RFC2730] MALLOC [RFC6308] MASC | 257 | | | [RFC2909] MZAP [RFC2776] MSDP | 258 | | | [RFC3618] SSM [RFC4607] | 259 +--------------+---------------+--------------------------------------+ 260 | | Automatic | AMT [RFC7450] | 261 | | Multicast | | 262 | | Tunneling | | 263 +--------------+---------------+--------------------------------------+ 264 | | Path-based | BIER [RFC8279] BIER encapsulation | 265 | | Forwarding | [RFC8296] IP-over-ICN | 266 | | |[I-D.trossen-icnrg-internet-icn-5glan]| 267 +--------------+---------------+--------------------------------------+ 268 | Routing | Future | [RESEARCHFIAref] [ITUNET2030ref] | 269 |Architectures | architectures | [SCIONref] [RINAref] | 270 +--------------+---------------+--------------------------------------+ 271 | Service | L2/L3 Explicit| SFC [RFC7665] NSH [RFC8300] MPLS | 272 | Function |Header Chaining| encapsulation [RFC8596] | 273 | Chaining | | | 274 +--------------+---------------+--------------------------------------+ 275 | | Name-based | Name-based SFF [RFC8677] | 276 | | Chaining | | 277 +--------------+---------------+--------------------------------------+ 278 | | Source Routing| Segment Routing [RFC8402] | 279 +--------------+---------------+--------------------------------------+ 280 | Application/ | Application- | Aalto [RFC7285] APN | 281 |service-aware | server based | [I-D.li-apn-framework] | 282 | Routing | | | 283 +--------------+---------------+--------------------------------------+ 284 | | L3 based | Dyncast use cases | 285 | | |[I-D.liu-dyncast-ps-usecases] Dyncast | 286 | | | use architecture | 287 | | | [I-D.li-dyncast-architecture] | 288 +--------------+---------------+--------------------------------------+ 289 | | Network | Segment routing [RFC8986] | 290 | | programming | | 291 +--------------+---------------+--------------------------------------+ 292 | Anycast | IP Anycast | Architcture considerations[RFC7094] | 293 | Routing | | Operation of Anycast [RFC4786] | 294 +--------------+---------------+--------------------------------------+ 295 | | Metric-based | Dyncast use cases | 296 | | |[I-D.liu-dyncast-ps-usecases] Dyncast | 297 | | | architecture | 298 | | | [I-D.li-dyncast-architecture] Load- | 299 | | | balanced anycast [weightedRef] | 300 +--------------+---------------+--------------------------------------+ 301 |Privacy-aware | Crypto routing| CGA [RFC3972] CGA Extension Field | 302 | Routing | | [RFC4581] | 303 +--------------+---------------+--------------------------------------+ 304 | | Obfuscation | ILNP-based [ILNP_PRIVACY] | 305 +--------------+---------------+--------------------------------------+ 306 | Security- | Routing | SCION [SCIONref] | 307 | enhanced | Architecture | | 308 | Routing | | | 309 +--------------+---------------+--------------------------------------+ 310 |Identity Split| Identity/ | LISP [RFC6830] LISPbis | 311 | Routing | Locator Split | [I-D.ietf-lisp-rfc6830bis] LISPbis | 312 | | | [I-D.ietf-lisp-rfc6833bis] | 313 | | | HIP[RFC4423] ILNP [RFC6740] | 314 +--------------+---------------+--------------------------------------+ 315 | Content | Routing over | ICN [ICNref] NDN [NDNref] ICN | 316 | Routing | content names | deployment [RFC8763] HICN [HICNref] | 317 +--------------+---------------+--------------------------------------+ 318 | | Routing via | DNS DONA [DONAref] | 319 | | indirection | | 320 | | points | | 321 +--------------+---------------+--------------------------------------+ 322 |Differentiated| QoS | DiffServ [RFC2474] IntServ [RFC2210] | 323 | Routing |Differentiation| | 324 +--------------+---------------+--------------------------------------+ 325 | | Path | Segment Routing [RFC8402] SFC | 326 | |differentiation| [RFC7665] | 327 +--------------+---------------+--------------------------------------+ 328 | Extended | EH-based | IPv6 EH [RFC8200] | 329 | Routing | | | 330 +--------------+---------------+--------------------------------------+ 332 Table 1: Summary of Routing Extensions 334 4. Issues with Current Approaches 336 Developing routing purposes beyond the original 'mere' reachability 337 does come with issues when considering their deployment and use in 338 the Internet; we outline those issues in the following. 340 We note that those issues are intrisincely linked to the ones 341 stemming from the extension of addressing semantics that may be used 342 to realize the various routing extensions, identified in 343 [I-D.jia-intarea-internet-addressing-gap-analysis]. We therefore 344 structure our presentation along the same lines. 346 4.1. Limiting Routing Semantics 348 Approaches that intend to change the purpose of communication, e.g., 349 by separating host from network node identification [RFC7401] or 350 through identification of content directly [HICNref], are limited by 351 the reachability purpose of IPv6, as defined by its source and 352 destination address. 354 This leads to approaches such as 355 [I-D.trossen-icnrg-internet-icn-5glan] to override addressing 356 semantics, namely replacing the IPv6 source and destination addresses 357 with path information instead, in order to achieve the desired 358 purpose of its routing solution. This, in turn, requires to still 359 carry address information as part of the payload in order to support 360 clients unaware of the routing extension. Furthermore, such approach 361 may lead to 'information leakage'outside the boundaries of the system 362 in which its changed purpose is being realized. Introduction of 363 dedicated gateways to 'translate' from one purpose (new routing) to 364 another (IPv6 routing) is the consequence of this. 366 But even such approach of 're-writing' packet information towards a 367 new purpose limits the expressible (new) semantic information to the 368 size of the original field, thereby limiting the support of content 369 information in approaches such as [HICNref] or the size of supported 370 networks in [I-D.trossen-icnrg-internet-icn-5glan] to the bit size 371 afforded by IPv6 addresses. 373 4.2. Complexity and Efficiency 375 Introducing new routing purposes also bring additional complexity. 376 This becomes an issue when new purposes are being introduced in 377 particular parts of the overall Internet, such as the edge of the 378 network, while relying on the existing reachability purpose of the 379 Internet to interconnect those islands over the existing Internet. 381 This additional complexity therefore often comes with a penalty in 382 the form of efficiency and costs for realizing the novel routing 383 purpose, which in turn may specifically pose an even bigger problem 384 when the solution is introduced at the edge of the network, which is 385 often constrained in resources and therefore costs that can be 386 expensed. 388 For instance, if the specific new purpose requires compression of 389 packet fields, such as for header compression, additional processing 390 as well as potentially required gateways that restore information 391 towards the Internet may be prohibitive for introducing the desired 392 new routing purpose in this part of the Internet. 394 Conversely, performance requirements of core networks, in terms of 395 packet processing speed, pose a problem when wanting to accommodate 396 novel routing purposes. Here, not only the possibly additional 397 processing but also the required changes of often HW-based platforms 398 makes adoption of novel routing purposes prohibitive. 400 4.2.1. Repetitive encapsulation 402 A routing solution targetting a different purposes often requires 403 encapsulating the relevant information, thereby bloating packet sizes 404 and lowering overall efficiency. This can be seen in routing 405 solutions such as [I-D.trossen-icnrg-internet-icn-5glan] (introducing 406 an alternative forwarding solution), [I-D.ietf-lisp-mn] (handling 407 mobility in LISP), [RFC8926] and [RFC7348] (DC networking), [RFC8986] 408 (traffic engineering) as well as [TOR] (routing privacy), all of 409 which introduce multiple encapsulations that in turn reduce the 410 forwarding effiency. 412 The introduction of dedicated points of encapsulation also introduce 413 complexity and costs at the points of the network where they are 414 required, which may often be at the network edge, while also 415 establishing failure points and therefore increasing the overall 416 fragility of the system; a point we discuss in more detail in 417 Section 4.4. 419 4.2.2. Introducing Path Stretch 421 Path stretch is an issue when moving from direct reachability 422 purposes to additional ones, such as dealing with mobility of 423 endpoints, as done in MobileIP [RFC6275]. In this case, following 424 the typical triangular route affects transmission effiency as well as 425 overall latency of the communication, instead of communicating 426 directly towards the (new) network location. 428 Additionally, the realization of novel purposes, such as privacy- 429 compliant routing in systems like TOR [TOR], often introduce path 430 stretch due to the additional relays being introduced for fulfilling 431 the intended purpose, here the obfuscation of traffic for privacy 432 reasons. 434 4.2.3. Complicating Traffic Engineering 436 As outlined in Section 3, many solutions to extend the original 437 reachability purpose of Internet routing aim to introduce or improve 438 on traffic engineering capabilities, e.g., by enabling decisions 439 based on QoS metrics, mobility, chaining and others aspects. 441 However, realizing each novel purpose as a separate solution in 442 itself likely hampers the goal for which they are developed, namely 443 to improve on traffic engineering, whenever individual solutions are 444 being used in combination. This 'feature interaction' aspect may 445 even prevent combined uses, while at a minimum requiring an 446 understanding if combined uses are possible in the first place or 447 instead incompatible with each other. This is not just an issue that 448 routing purposes may be incompatible at a functional level, e.g., 449 through conflicting policies, but may also utilize conflicting 450 realizations for their purposes. 452 4.3. Security 454 Security issues, outside the security considerations of the specific 455 design, often arise from the integration of the specific solution 456 into the existing routing system. For instance, HIP [RFC7401] limits 457 its host identity to 128bit in an effort to be backward compatible, 458 but possibly resulting in weak cryptographical strength. A similar 459 issue can be observed in CGA [RFC3972], where only 59bits of the 460 128bit limit may be used for what could be packet signatures not 461 sufficiently robust enough against attacks. 463 Attempts to introduce privacy purposes into the routing system, e.g., 464 by utilizing ephemeral addresses 465 [I-D.gont-v6ops-ipv6-addressing-considerations], may in turn pose 466 significant challenges on the routing system through its required 467 renewal rate of addresses. 469 4.4. Fragility 471 From the overview of novel routing purposes in Section 3, we can 472 observe that the existence of those additional routing purpose adds 473 many purpose-specific translation/adaptation points, responsible for 474 mapping formats from one meaningful context into another. This is in 475 turn creates dependency on this additional functionality to exist for 476 endpoints to communicate with the context of the intended purpose. 478 While translation/adaptation between purposes and their defining 479 contexts is often not avoidable when going beyond 'mere' 480 reachabiulity, it is the solution-specific nature of those components 481 (required for many if not each extended purpose) that is likely to 482 increase the fragility of the resulting system. 484 The key problem here is the interaction with other extended purposes 485 that may exist in specific deployments. While needing to operate in 486 the presence of those other purpose-specific components, their design 487 has often not taken into account the specific interaction in 488 question. Given the diversity of extension realizations, utilizing 489 many, almost any packet field, even beyond and entirely different to 490 its intentded purpose, conflicting behaviour as well as diverging 491 interpretatin of the utilized packet information is clearly an issue. 492 Only careful testing of combinations with possible delineation (of 493 purposes) as well as networks may be required, all of which further 494 increases the costs for utilizing the extended purposes. 496 4.5. Interoperability 498 Although routing extensions are developed with their specific 499 purposes in mind, reflected in requirements and behaviours, they are 500 often realized in conjunction with other extensions when it comes to 501 real-world deployments. 503 This poses an Interoperability challenge, both in terms of backward 504 as well as forward compability. Feature interactions need 505 investigations, often left to operational deployment. 507 Building extensions on the basis of agreed packet field semantics is 508 one way to achieve the desired interoperability, unless approaches 509 use extensions to packet fields beyond their original intention. As 510 a consequence, translation/adaptation points may be needed to ensure 511 interoperability with other parts of the network, increasing the 512 fragility of the system, as discussed in Section 4.4. 514 Forward compability aims at ensuring that future extensions will 515 continue to be possible, aiming at an overall extensibility of the 516 system beyond its purpose at the time of developing a specific 517 solution. IPv6 extension headers are one example of enabling future 518 extensions, although not without their own problems in real-world 519 deployments [SHIMv6ref]. 521 5. Where to Go From Here? 523 This document outlined the original starting point of the Internet's 524 routing system, namely providing 'mere' reachability, and showed 525 through its survey of existing solutions that have since been 526 developed that Internet routing has, in fact, evolved into a system 527 that serves many purposes beyond its original 'mere' reachability 528 goal. 530 However, the issues we outlined in Section 4 pose the question on how 531 to move forward in the (future) evolution of Internet routing. We 532 assert that continuing with a 'business as usual' attitude will 533 ultimately compound the identified issues, thereby hampering 534 innovation in novel routing purposes and solutions, and therefore the 535 Internet overall. 537 As a way forward, we ask the wider RTG WG community to recognize the 538 following cornerstones for an evolution path for Internet routing: 540 1. Further evolution of the Internet's routing system MUST take a 541 wider architectural approach in order to break with the point 542 solution approach that has led to the identified issues in 543 Section 4. 545 2. With research and development on routing solutions continuing, as 546 also illustrated in [I-D.king-irtf-semantic-routing-survey], 547 these works MUST be brought into the process of IETF engagement 548 and standardization to increase the understanding of what novel 549 trends, works, and possible developments may be just around the 550 corner but also to inform ongoing research and development on 551 paths taken in the IETF. 553 3. The RTG WG SHOULD play a role in the engagement with research and 554 development since the 'Future of Internet Routing' (FIR) is at 555 the heart of its charter ("The Routing Area working group (RTGWG) 556 is chartered to provide a venue to discuss, evaluate, support and 557 develop proposals for new work in the Routing Area" [RTGWGref]), 558 a role that goes beyond the "specific small topics that do not 559 fit with an existing working group" [RTGWGref]. 561 Following on the cornerstones outlined above, we specifically suggest 562 to the RTG WG, aligned with its charter to consider the following 563 actions: 565 1. Establish suitable efforts within the RTG WG (e.g., as a sub- 566 group) OR 568 2. Support the establishment of suitable efforts as a standalone FIR 569 WG OR 571 3. Support the establishment of suitable efforts within the IRTF, 572 where those efforts directly liaise with the RTG WG through 573 regular updates in its meetings. 575 6. Security Considerations 577 Section 4.3 outlines a number of security issues that may occur 578 outside the solution-specific security considerations, such as 579 interactions between protocol behaviours that were previously 580 untested as a combination. With that in mind, security 581 considerations for a wider architectural approach to routing must 582 have the security of the overall routing system as the main goal, not 583 merely the security of a single solution. 585 7. Privacy Considerations 587 Protecting user privacy is very important. This extends beyond 588 ensuring that user data cannot be examined in transit, and also 589 requires that a process that inspects the network traffic should not 590 be able to determine which applications or what types of application 591 a user is running. 593 This makes it critically important to minimize or entirely avoid user 594 and/or application information to be directly used for routing 595 purposes. Instead, applications (or users) should express 596 requirements for traffic delivery in a manner that does not reveal 597 information about the user. 599 Encryption of user data, which is a common technique to protect user 600 privacy, may obscure information that has previously been used to 601 perform enhanced routing (such as by inspecting or hashing on payload 602 fields), demonstrating that new requirements (here on privacy) may 603 negatively impact previously accepted solutions. 605 8. IANA Considerations 607 This draft does not request any IANA action. 609 9. Acknowledgements 611 TBD. 613 10. Contributors 615 Adrian Farrel 616 Email: adrian@olddog.co.uk 618 11. Informative References 620 [CLNPref] "Protocol for providing the connectionless-mode network 621 service: Protocol specification - Part 1", 622 standard ISO/IEC 8473-1:1998, 1998, 623 . 625 [CONTENTref] 626 Choi, J., Han, J., and E. Cho, "A survey on content- 627 oriented networking for efficient content delivery", 628 Paper IEEE Communications Magazine, 49(3): 121-127, May 629 2011., 2011, . 632 [DONAref] Koponen, T., Chawla, M., Chun, B.-G., Ermolinskiy, A., 633 Kim, K. H., Shenker, S., and I. Stoica, "A data-oriented 634 (and beyond) network architecture", Paper Proceedings of 635 the 2007 conference on Applications, technologies, 636 architectures, and protocols for computer communications, 637 August 2007, 2007, 638 . 640 [HICNref] Carofiglio, G., Muscariello, L., Auge, J., Papalini, M., 641 Sardara, M., and A. Compagno, "Enabling ICN in the 642 Internet Protocol: Analysis and Evaluation of the Hybrid- 643 ICN Architecture", Paper Proceedings of the 6th ACM 644 Conference on Information-Centric Networking, 2019., 2019, 645 . 649 [I-D.bonica-6man-ext-hdr-update] 650 Bonica, R. and T. Jinmei, "Inserting, Processing And 651 Deleting IPv6 Extension Headers", Work in Progress, 652 Internet-Draft, draft-bonica-6man-ext-hdr-update-06, 30 653 August 2021, . 656 [I-D.bryant-arch-fwd-layer-ps] 657 Bryant, S., Chunduri, U., Eckert, T., and A. Clemm, 658 "Forwarding Layer Problem Statement", Work in Progress, 659 Internet-Draft, draft-bryant-arch-fwd-layer-ps-04, 24 660 January 2022, . 663 [I-D.chunduri-lsr-isis-preferred-path-routing] 664 Chunduri, U., Li, R., White, R., Contreras, L. M., 665 Tantsura, J., and Y. Qu, "Preferred Path Routing (PPR) in 666 IS-IS", Work in Progress, Internet-Draft, draft-chunduri- 667 lsr-isis-preferred-path-routing-07, 12 November 2021, 668 . 671 [I-D.farrel-irtf-introduction-to-semantic-routing] 672 Farrel, A. and D. King, "An Introduction to Semantic 673 Routing", Work in Progress, Internet-Draft, draft-farrel- 674 irtf-introduction-to-semantic-routing-03, 22 January 2022, 675 . 678 [I-D.gont-v6ops-ipv6-addressing-considerations] 679 Gont, F. and G. Gont, "IPv6 Addressing Considerations", 680 Work in Progress, Internet-Draft, draft-gont-v6ops-ipv6- 681 addressing-considerations-01, 21 February 2021, 682 . 685 [I-D.ietf-lisp-mn] 686 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 687 Mobile Node", Work in Progress, Internet-Draft, draft- 688 ietf-lisp-mn-11, 30 January 2022, 689 . 692 [I-D.ietf-lisp-rfc6830bis] 693 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 694 Cabellos, "The Locator/ID Separation Protocol (LISP)", 695 Work in Progress, Internet-Draft, draft-ietf-lisp- 696 rfc6830bis-36, 18 November 2020, 697 . 700 [I-D.ietf-lisp-rfc6833bis] 701 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 702 "Locator/ID Separation Protocol (LISP) Control-Plane", 703 Work in Progress, Internet-Draft, draft-ietf-lisp- 704 rfc6833bis-30, 18 November 2020, 705 . 708 [I-D.ietf-teas-rfc3272bis] 709 Farrel, A., "Overview and Principles of Internet Traffic 710 Engineering", Work in Progress, Internet-Draft, draft- 711 ietf-teas-rfc3272bis-13, 8 November 2021, 712 . 715 [I-D.ietf-v6ops-ipv6-ehs-packet-drops] 716 Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, 717 G., and W. (. Liu, "Operational Implications of IPv6 718 Packets with Extension Headers", Work in Progress, 719 Internet-Draft, draft-ietf-v6ops-ipv6-ehs-packet-drops-08, 720 11 June 2021, . 723 [I-D.irtf-panrg-path-properties] 724 Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path 725 Properties", Work in Progress, Internet-Draft, draft-irtf- 726 panrg-path-properties-04, 25 October 2021, 727 . 730 [I-D.irtf-panrg-what-not-to-do] 731 Dawkins, S., "Path Aware Networking: Obstacles to 732 Deployment (A Bestiary of Roads Not Taken)", Work in 733 Progress, Internet-Draft, draft-irtf-panrg-what-not-to-do- 734 19, 26 March 2021, . 737 [I-D.jia-intarea-internet-addressing-gap-analysis] 738 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., and P. 739 Mendes, "Gap Analysis in Internet Addressing", Work in 740 Progress, Internet-Draft, draft-jia-intarea-internet- 741 addressing-gap-analysis-01, 23 October 2021, 742 . 745 [I-D.king-irtf-semantic-routing-survey] 746 King, D. and A. Farrel, "A Survey of Semantic Internet 747 Routing Techniques", Work in Progress, Internet-Draft, 748 draft-king-irtf-semantic-routing-survey-03, 26 November 749 2021, . 752 [I-D.li-apn-framework] 753 Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., 754 Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard, 755 "Application-aware Networking (APN) Framework", Work in 756 Progress, Internet-Draft, draft-li-apn-framework-04, 25 757 October 2021, . 760 [I-D.li-dyncast-architecture] 761 Li, Y., Iannone, L., Trossen, D., Liu, P., and C. Li, 762 "Dynamic-Anycast Architecture", Work in Progress, 763 Internet-Draft, draft-li-dyncast-architecture-01, 20 764 January 2022, . 767 [I-D.liu-dyncast-ps-usecases] 768 Liu, P., Willis, P., Trossen, D., and C. Li, "Dynamic- 769 Anycast (Dyncast) Use Cases & Problem Statement", Work in 770 Progress, Internet-Draft, draft-liu-dyncast-ps-usecases- 771 02, 17 January 2022, . 774 [I-D.muscariello-intarea-hicn] 775 Muscariello, L., Carofiglio, G., Augé, J., Papalini, M., 776 and M. Sardara, "Hybrid Information-Centric Networking", 777 Work in Progress, Internet-Draft, draft-muscariello- 778 intarea-hicn-04, 20 May 2020, 779 . 782 [I-D.trossen-icnrg-internet-icn-5glan] 783 Trossen, D., Robitzsch, S., Reed, M., Al-Naday, M., and J. 784 Riihijarvi, "Internet Services over ICN in 5G LAN 785 Environments", Work in Progress, Internet-Draft, draft- 786 trossen-icnrg-internet-icn-5glan-04, 1 October 2020, 787 . 790 [ICNref] Barbera, D., Xylomenos, G., Ververidis, C., Siris, V., and 791 N. Fotiou, "A Survey of information-centric networking 792 research", Paper IEEE Communications Surveys and 793 Tutorials, vol. 16, Iss. 2, Q2 2014, 2014, 794 . 797 [ILNP_PRIVACY] 798 Bhatti, S., Haywood, G., and R. Yanagida, "End-to-end 799 privacy for identity and location with IP", Paper 2nd 800 Workshop on New Internetworking Protocols, Architecture 801 and Algorithms, 29th IEEE International Conference on 802 Network Protocols, 2021. 804 [ISISref] "Intermediate System to Intermediate System intra-domain 805 routeing information exchange protocol for use in 806 conjunction with the protocol for providing the 807 connectionless-mode network service", standard ISO/IEC 808 10589, 2002, . 812 [ITUNET2030ref] 813 "Network 2030 Architecture Framework", Technical 814 Specification ITU-T Focus Group on Technologies for 815 Network 2030, 2020, . 819 [MBONEref] Savetz, K., Randall, N., and Y. Lepage, "MBONE: 820 Multicasting Tomorrow's Internet", Book IDG, 1996, 821 . 823 [NDNref] Zhang, L., Afanasyev, A., and J. Burke, "Named Data 824 Networking", Paper ACM SIGCOMM Computer Communication, 825 Review 44(3): 66-73, 2014, 2014. 827 [PANRGref] "Path Aware Networking Research Group", RG Path Aware 828 Networking Research Group, 829 . 831 [RESEARCHFIAref] 832 Pan, J., Paul, S., and R. Jain, "A Survey of the Research 833 on Future Internet Architectures", Paper IEEE 834 Communications Magazine, vol. 49, no. 7, July 2011, 2014, 835 . 837 [RFC1069] Callon, R. and H. Braun, "Guidelines for the use of 838 Internet-IP addresses in the ISO Connectionless-Mode 839 Network Protocol", RFC 1069, DOI 10.17487/RFC1069, 840 February 1989, . 842 [RFC1104] Braun, H., "Models of policy based routing", RFC 1104, 843 DOI 10.17487/RFC1104, June 1989, 844 . 846 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 847 RFC 1112, DOI 10.17487/RFC1112, August 1989, 848 . 850 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 851 dual environments", RFC 1195, DOI 10.17487/RFC1195, 852 December 1990, . 854 [RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol 855 Specification: Version 1", RFC 1479, DOI 10.17487/RFC1479, 856 July 1993, . 858 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 859 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, 860 . 862 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 863 "Definition of the Differentiated Services Field (DS 864 Field) in the IPv4 and IPv6 Headers", RFC 2474, 865 DOI 10.17487/RFC2474, December 1998, 866 . 868 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 869 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 870 DOI 10.17487/RFC2730, December 1999, 871 . 873 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 874 Zone Announcement Protocol (MZAP)", RFC 2776, 875 DOI 10.17487/RFC2776, February 2000, 876 . 878 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 879 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 880 (MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909, 881 September 2000, . 883 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 884 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 885 . 887 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 888 Discovery Protocol (MSDP)", RFC 3618, 889 DOI 10.17487/RFC3618, October 2003, 890 . 892 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 893 RFC 3972, DOI 10.17487/RFC3972, March 2005, 894 . 896 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 897 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 898 2006, . 900 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 901 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 902 2006, . 904 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 905 Addresses (CGA) Extension Field Format", RFC 4581, 906 DOI 10.17487/RFC4581, October 2006, 907 . 909 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 910 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 911 . 913 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 914 Computation Element (PCE)-Based Architecture", RFC 4655, 915 DOI 10.17487/RFC4655, August 2006, 916 . 918 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 919 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 920 December 2006, . 922 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 923 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 924 2008, . 926 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 927 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 928 DOI 10.17487/RFC5440, March 2009, 929 . 931 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 932 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 933 2011, . 935 [RFC6308] Savola, P., "Overview of the Internet Multicast Addressing 936 Architecture", RFC 6308, DOI 10.17487/RFC6308, June 2011, 937 . 939 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 940 Protocol (ILNP) Architectural Description", RFC 6740, 941 DOI 10.17487/RFC6740, November 2012, 942 . 944 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 945 Locator/ID Separation Protocol (LISP)", RFC 6830, 946 DOI 10.17487/RFC6830, January 2013, 947 . 949 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 950 "Architectural Considerations of IP Anycast", RFC 7094, 951 DOI 10.17487/RFC7094, January 2014, 952 . 954 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 955 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 956 "Application-Layer Traffic Optimization (ALTO) Protocol", 957 RFC 7285, DOI 10.17487/RFC7285, September 2014, 958 . 960 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 961 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 962 eXtensible Local Area Network (VXLAN): A Framework for 963 Overlaying Virtualized Layer 2 Networks over Layer 3 964 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 965 . 967 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 968 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 969 RFC 7401, DOI 10.17487/RFC7401, April 2015, 970 . 972 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 973 DOI 10.17487/RFC7450, February 2015, 974 . 976 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 977 Chaining (SFC) Architecture", RFC 7665, 978 DOI 10.17487/RFC7665, October 2015, 979 . 981 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 982 "Observations on the Dropping of Packets with IPv6 983 Extension Headers in the Real World", RFC 7872, 984 DOI 10.17487/RFC7872, June 2016, 985 . 987 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 988 (IPv6) Specification", STD 86, RFC 8200, 989 DOI 10.17487/RFC8200, July 2017, 990 . 992 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 993 Computation Element Communication Protocol (PCEP) 994 Extensions for Stateful PCE", RFC 8231, 995 DOI 10.17487/RFC8231, September 2017, 996 . 998 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 999 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1000 Explicit Replication (BIER)", RFC 8279, 1001 DOI 10.17487/RFC8279, November 2017, 1002 . 1004 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1005 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1006 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1007 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1008 2018, . 1010 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1011 "Network Service Header (NSH)", RFC 8300, 1012 DOI 10.17487/RFC8300, January 2018, 1013 . 1015 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1016 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1017 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1018 July 2018, . 1020 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 1021 "MPLS Transport Encapsulation for the Service Function 1022 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 1023 DOI 10.17487/RFC8596, June 2019, 1024 . 1026 [RFC8677] Trossen, D., Purkayastha, D., and A. Rahman, "Name-Based 1027 Service Function Forwarder (nSFF) Component within a 1028 Service Function Chaining (SFC) Framework", RFC 8677, 1029 DOI 10.17487/RFC8677, November 2019, 1030 . 1032 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1033 Paasch, "TCP Extensions for Multipath Operation with 1034 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1035 2020, . 1037 [RFC8736] Venaas, S. and A. Retana, "PIM Message Type Space 1038 Extension and Reserved Bits", RFC 8736, 1039 DOI 10.17487/RFC8736, February 2020, 1040 . 1042 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1043 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1044 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1045 . 1047 [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, 1048 "Deployment Considerations for Information-Centric 1049 Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 1050 2020, . 1052 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1053 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1054 . 1056 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 1057 "Geneve: Generic Network Virtualization Encapsulation", 1058 RFC 8926, DOI 10.17487/RFC8926, November 2020, 1059 . 1061 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1062 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1063 (SRv6) Network Programming", RFC 8986, 1064 DOI 10.17487/RFC8986, February 2021, 1065 . 1067 [RINAref] Day, J., "Patterns in Network Architecture: A Return to 1068 Fundamentals", Book Prentice Hall, 2008. 1070 [RTGWGref] "Routing Working Group Charter", WG Routing Working Group, 1071 . 1073 [SCIONref] Barbera, D., Chaut, L., Perrig, A., Reischuk, R., and P. 1074 Szalachowski, "Patterns in Network Architecture: A Return 1075 to Fundamentals", Paper The ACM, vol. 60, no. 6, June 1076 2017, 2017, 1077 . 1079 [SHIMv6ref] 1080 Naderi, H. and B. E. Carpenter, "Putting SHIM6 into 1081 practice", Paper 2014 Australasian Telecommunication 1082 Networks and Applications Conference (ATNAC), 2014, 1083 . 1085 [TOR] "The Tor Project", Website Tor Project, 2022, 1086 . 1088 [weightedRef] 1089 Lin, C-Y., Lo, J-H., and S-Y. Kuo, "Load-balanced anycast 1090 routing", Paper Proceedings of the Tenth International 1091 Conference on Parallel and Distributed Systems, 2004., 1092 2004, . 1095 Authors' Addresses 1097 Dirk Trossen 1098 Huawei Technologies 1099 Munich 1100 Germany 1102 Email: dirk.trossen@huawei.com 1104 David Lou 1105 Huawei Technologies 1106 Munich 1107 Germany 1109 Email: zhe.lou@huawei.com 1110 Sheng Jiang 1111 Huawei Technologies 1112 China 1114 Email: jiangsheng@huawei.com