idnits 2.17.1 draft-jia-intarea-internet-addressing-gap-analysis-02.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 ([RFC0791], [I-D.jia-intarea-scenarios-problems-addressing], [RFC8200]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-gont-v6ops-ipv6-addressing-considerations-01 == Outdated reference: A later version (-14) exists of draft-chen-ati-adaptive-ipv4-address-space-10 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-17 == Outdated reference: A later version (-11) exists of draft-ietf-6lo-plc-10 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-mn-11 == 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 (-03) exists of draft-jia-intarea-scenarios-problems-addressing-02 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group Y. Jia 3 Internet-Draft D. Trossen 4 Intended status: Informational L. Iannone 5 Expires: 7 September 2022 Huawei 6 P. Mendes 7 Airbus 8 N. Shenoy 9 R.I.T. 10 L. Toutain 11 IMT-Atlantique 12 A. Y. Chen 13 Avinta 14 D. Farinacci 15 lispers.net 16 6 March 2022 18 Gap Analysis in Internet Addressing 19 draft-jia-intarea-internet-addressing-gap-analysis-02 21 Abstract 23 There exist many extensions to Internet addressing, as it is defined 24 in [RFC0791] for IPv4 and [RFC8200] for IPv6, respectively. Those 25 extensions have been developed to fill gaps in capabilities beyond 26 the basic properties of Internet addressing. This document outlines 27 those properties as a baseline against which the extensions are 28 categorized in terms of methodology used to fill the gap together 29 with examples of solutions doing so. 31 While introducing such extensions, we outline the issues we see with 32 those extensions. This ultimately leads to consider whether or not a 33 more consistent approach to tackling the identified gaps, beyond 34 point-wise extensions as done so far, would be beneficial. The 35 benefits are the ones detailed in the companion document 36 [I-D.jia-intarea-scenarios-problems-addressing], where, leveraging on 37 the gaps identified in this memo and scenarios provided in 38 [I-D.jia-intarea-scenarios-problems-addressing], a clear problem 39 statement is provided. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 7 September 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Properties of Internet Addressing . . . . . . . . . . . . . . 4 76 2.1. Property 1: Fixed Address Length . . . . . . . . . . . . 4 77 2.2. Property 2: Ambiguous Address Semantic . . . . . . . . . 4 78 2.3. Property 3: Limited Address Semantic Support . . . . . . 5 79 3. Filling Gaps through Extensions to Internet Addressing 80 Properties . . . . . . . . . . . . . . . . . . . . . . . 5 81 3.1. Length Extensions . . . . . . . . . . . . . . . . . . . . 5 82 3.1.1. Shorter Address Length . . . . . . . . . . . . . . . 6 83 3.1.2. Longer Address Length . . . . . . . . . . . . . . . . 8 84 3.1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 85 3.2. Identity Extensions . . . . . . . . . . . . . . . . . . . 10 86 3.2.1. Anonymous Address Identity . . . . . . . . . . . . . 11 87 3.2.2. Authenticated Address Identity . . . . . . . . . . . 14 88 3.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 89 3.3. Semantic Extensions . . . . . . . . . . . . . . . . . . . 16 90 3.3.1. Utilizing Extended Address Semantics . . . . . . . . 17 91 3.3.2. Utilizing Existing or Extended Header Semantics . . . 20 92 3.3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 23 93 4. Overview of Approaches to Extend Internet Addressing . . . . 24 94 5. A System View on Address . . . . . . . . . . . . . . . . . . 26 95 6. Issues in Extensions to Internet Addressing . . . . . . . . . 27 96 6.1. Limiting Address Semantics . . . . . . . . . . . . . . . 27 97 6.2. Complexity and Efficiency . . . . . . . . . . . . . . . . 27 98 6.2.1. Repetitive encapsulation . . . . . . . . . . . . . . 28 99 6.2.2. Compounding issues with header compression . . . . . 29 100 6.2.3. Introducing Path Stretch . . . . . . . . . . . . . . 29 101 6.2.4. Complicating Traffic Engineering . . . . . . . . . . 29 102 6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 30 103 6.4. Fragility . . . . . . . . . . . . . . . . . . . . . . . . 30 104 7. Summary of issues . . . . . . . . . . . . . . . . . . . . . . 31 105 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 108 11. Informative References . . . . . . . . . . . . . . . . . . . 34 109 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 112 1. Introduction 114 [I-D.jia-intarea-scenarios-problems-addressing] outlines scenarios 115 and problems in Internet addressing through presenting a number of 116 cases of communication that have emerged over the many years of 117 utilizing the Internet and for which various extensions to the 118 network interface-centric addressing of IPv6 have been developed. In 119 order to continue the discussion on the emerging needs for 120 addressing, initiated with 121 [I-D.jia-intarea-scenarios-problems-addressing], this memo aims at 122 identifying gaps between the Internet addressing model and desirable 123 features that have been added by various extensions, in various 124 contexts. 126 The approach to identifying the gaps is guided by key properties of 127 Internet addressing, outlined in Section 2, namely (i) the fixed 128 length of the IP addresses, (ii) the ambiguity of IP addresses 129 semantic, while still (iii) providing limited IP address semantic 130 support. Those properties are derived directly as a consequence of 131 the respective standards that provide the basis for Internet 132 addressing, most notably [RFC0791] for IPv4 and [RFC8200] for IPv6, 133 respectively. 135 Those basic properties, and the potential issues that arise from 136 those properties, give way to extensions that have been proposed over 137 the course of deploying new Internet technologies. Section 3 138 discusses those extensions, summarized as gaps against the basic 139 properties in Section 4. 141 Finally, this memo outlines issues that arise with the extension- 142 driven approach to the basic Internet addressing, discussed in 143 Section 6, arguing that any requirements for solutions that would 144 revise the basic Internet addressing would require to address those 145 issues. 147 2. Properties of Internet Addressing 149 As the Internet Protocol adoption has grown towards the global 150 communication system we know today, its characteristics have evolved 151 subtly, with [RFC6250] documenting various aspects of the IP service 152 model and its frequent misconceptions, including Internet addressing. 153 In this section, the three most acknowledged properties related to 154 _Internet addressing_ are detailed. Those are (i) fixed IP address 155 length, (ii) ambiguous IP address semantic, and (iii) limited IP 156 address semantic support. 158 Section 3 elaborates on various extensions that aim to expand 159 Internet addressing beyond those properties; those extensions are 160 positioned as intentions to close perceived gaps against those key 161 properties. 163 2.1. Property 1: Fixed Address Length 165 The fixed IP address length is specified as a key property of the 166 design of Internet addressing, with 32 bits for IPv4 ([RFC0791]), and 167 128 bits for IPv6 ([RFC8200]), respectively. Given the capability of 168 the hardware at the time of IPv4 design, a fixed length address was 169 considered as a more appropriate choice for efficient packet 170 forwarding. Although the address length was once considered to be 171 variable during the design of Internet Protocol Next Generation 172 ("IPng", cf., [RFC1752]) in the 1990s, it finally inherited the 173 design of IPv4 and adopted a fixed length address towards the current 174 IPv6. As a consequence, the 128-bit fixed address length of IPv6 is 175 regarded as a balance between fast forwarding (i.e., fixed length) 176 and practically boundless cyberspace (i.e., enabled by using 128-bit 177 addresses). 179 2.2. Property 2: Ambiguous Address Semantic 181 Initially, the meaning of an IP address has been to identify an 182 interface on a network device, although, when [RFC0791] was written, 183 there were no explicit definitions of the IP address semantic. 185 With the global expansion of the Internet protocol, the semantic of 186 the IP address is commonly believed to contain at least two notions, 187 i.e., the explicit 'locator', and the implicit 'identifier'. Because 188 of the increasing use of IP addresses to both identify a node and to 189 indicate the physical or virtual location of the node, the 190 intertwined address semantics of identifier and locator was then 191 gradually observed and first documented in [RFC2101] as 'locator/ 192 identifier overload' property. With this, the IP address is used as 193 an identification for host and server, very often directly used, 194 e.g., for remote access or maintenance. 196 2.3. Property 3: Limited Address Semantic Support 198 Although IPv4 [RFC0791] did not add any semantic to IP addresses 199 beyond interface identification (and location), time has proven that 200 additional semantics are desirable (c.f., the history of 127/8 201 [HISTORY127] or the introduction of private addresses [RFC1918]), 202 hence, IPv6 [RFC4291] introduced some form of additional semantics 203 based on specific prefix values, for instance link-local addresses or 204 a more structured multicast addressing. Nevertheless, systematic 205 support for rich address semantics remains limited and basically 206 prefix-based. 208 3. Filling Gaps through Extensions to Internet Addressing Properties 210 Over the years, a plethora of extensions has been proposed in order 211 to move beyond the native properties of IP addresses, outlined in the 212 previous section. The development of those extensions can be 213 interpreted as filling gaps between the original properties of 214 Internet addressing and desired new capabilities that those 215 developing the extensions identified as being missing and yet needed 216 and desirable. 218 3.1. Length Extensions 220 Extensions in this subsection aim at extending the property described 221 in Section 2.1, i.e., the fixed IP address length. 223 When IPv6 was designed, the main objective was to create an address 224 space that would not lead to the same situation as IPv4, namely to 225 address exhaustion. To this end, while keeping the same addressing 226 model like IPv4, IPv6 adopted a 128-bit address length with the aim 227 of providing a sufficient and future-proof address space. The choice 228 was also founded on the assumption that advances in hardware and 229 Moore's law would still allow to make routing and forwarding faster, 230 and the IPv6 routing table manageable. 232 We observe, however, that the rise of new use cases but also the 233 number of new, e.g., industrial/home or small footprint devices, was 234 possibly unforeseen. Sensor networks and more generally the Internet 235 of Things (IoT) emerged after the core body of work on IPv6, thus 236 different from IPv6 assumptions, 128-bit addresses were costly in 237 certain scenarios. On the other hand, given the huge investments 238 that IPv6 deployment involved, certain solutions are expected to 239 increase the addressing space of IPv4 in a compatible way, and thus 240 extend the lifespan of the sunk investment on IPv4. 242 At the same time, it may also be possible to use variable and longer 243 address lengths to address current networking demands. For example 244 in content delivery networks, longer addresses such as URLs are 245 required to fetch content, an approach that Information-Centric 246 Networking (ICN) applied for any data packet sent in the network, 247 using information-based addressing at the network layer. 248 Furthermore, as an approach to address the routing challenges faced 249 in the Internet, structured addresses may be used in order to avoid 250 the need for routing protocols. Using variable length addresses 251 allow as well to have shorter addresses. So for requirements for 252 smaller network layer headers, shorter addresses could be used, maybe 253 alleviating the need to compress other fields of the header. 254 Furthermore, transport layer port numbers can be considered short 255 addresses, where the high order bits of the extended address is the 256 public IP of a NAT. Hence, in IoT deployments, the addresses of the 257 devices can be really small and based on the port number, but they 258 all share the global address of the gateway to make each one have a 259 globally unique address. 261 3.1.1. Shorter Address Length 263 3.1.1.1. Description: 265 In the context of IoT [RFC7228], where bandwidth and energy are very 266 scarce resources, the static length of 128-bit for an IP address is 267 more a hindrance than a benefit since 128-bit for an IP address may 268 occupy a lot of space, even to the point of being the dominant part 269 of a packet. In order to use bandwidth more efficiently and use less 270 energy in end-to-end communication, solutions have been proposed that 271 allow for very small network layer headers instead. 273 3.1.1.2. Methodology: 275 * Header Compression/Translation: One of the main approaches to 276 reduce header size in the IoT context is by compressing it. Such 277 technique is based on a stateful approach, utilizing what is 278 usually called a 'context' on the IoT sensor and the gateway for 279 communications between an IoT device and a server placed somewhere 280 in the Internet - from the edge to the cloud. 282 The role of the 'context' is to provide a way to 'compress' the 283 original IP header into a smaller one, using shorter address 284 information and/or dropping some field(s); the context here serves 285 as a kind of dictionary. 287 * Separate device from locator identifier: Approaches that can offer 288 customized address length that is adequate for use in such 289 constrained domains are preferred. Using different namespaces for 290 the 'device identifier' and the 'routing' or 'locator identifier' 291 is one such approach. 293 3.1.1.3. Examples 295 * Header Compression/Translation: Considering one base station is 296 supposed to serve hundreds of user devices, maximizing the 297 effectiveness for specific spectrum directly improves user quality 298 of experience. To achieve the optimal utilization of the spectrum 299 resource in the wireless area, the RObust Header Compression 300 (ROHC) [RFC5795] mechanism, which has been widely adopted in 301 cellar network like WCDMA, LTE, and 5G, utilizes header 302 compression to shrink existing IPv6 headers onto shorter ones. 304 Similarly, header compression techniques for IPv6 over Low-Power 305 Wireless Personal Area Networks (6LoWPAN) have been around for 306 several years now, constituting a main example of using the notion 307 of a 'shared context' in order to reduce the size of the network 308 layer header ([RFC6282], [RFC7400], [ITU9959]). More recently, 309 other compression solutions have been proposed for Low Power Wide 310 Area Networks (LPWAN - [RFC8376]). Among them, the Static Context 311 Header Compression (SCHC - [RFC8724]) generalized the compression 312 mechanism developed by 6lo. Instead of a standard compression 313 behavior implemented in all 6lo nodes, SCHC introduces the notion 314 of rule shared by two nodes. The SCHC compression technique is 315 generic and can be applied to IPv6 and above layers. Regarding 316 the nature of the traffic, IPv6 addresses (source and destination) 317 can be elided, partially sent, or replaced by a small index. 318 Instead of the versatile IP packet, SCHC defines new packet 319 formats dedicated to specific applications. SCHC rules are 320 equivalence functions mapping this format to standard IP packets. 322 Also, constraints coming from either devices or carrier links 323 would lead to mixed scenarios and compound requirements for 324 extraordinary header compression. For native IPv6 communications 325 on DECT ULE and MS/TP Networks [RFC6282], dedicated compression 326 mechanisms are specified in [RFC8105] and [RFC8163], while the 327 transmission of IPv6 packets over NFC and PLC, specifications are 328 being developed in [I-D.ietf-6lo-nfc] and [I-D.ietf-6lo-plc]. 330 * Separate device from locator identifier: Solutions such as 331 proposed in [EIBP] and [I-D.ietf-lisp-rfc6830bis] can utilize a 332 separation of device from locator, where only the latter is used 333 for routing between the different domains using the same 334 technology, therefore enabling the use of shorter addresses in the 335 (possibly constrained) local environment. Device IDs used within 336 such domains are carried as part of the payload by EIBP and hence 337 can be of shorter size suited to the domain, while, for instance, 338 in LISP a flexible address encoding [RFC8060] allows shorter 339 addresses to be supported in the LISP control plane 340 [I-D.ietf-lisp-rfc6833bis]. 342 3.1.2. Longer Address Length 344 3.1.2.1. Description 346 Historically, obtaining adequate address space is considered as the 347 primary and raw motivation to invent IPv6. Longer address (more than 348 32-bit of IPv4 address), which can accommodate almost inexhaustible 349 devices, used to be considered as the surest direction in 1990s. 350 Nevertheless, to protect the sunk cost of IPv4 deployment, certain 351 efforts focus on IPv4 address space depletion question but engineer 352 IPv4 address length in a more practical way. Such effort, i.e., NAT 353 (Network Address Translation), unexpectedly and significantly slows 354 IPv6 deployment because of its high cost-effectiveness in practice. 356 Another crucial need for longer address lengths comes from "semantic 357 extensions" to IP addresses, where the extensions themselves do not 358 fit within the length limitation of the IP address. Section 3.3 359 discusses extensions which extend address semantics that are not 360 limited by the IP address length. 362 This sub-section focuses on address length extensions that aim at 363 reducing the IPv4 addresses depletion, while Section 3.3, i.e., 364 address sematic extensions, may still refer to extensions when longer 365 address length are suitable to accommodate different address 366 semantic. See Section 3.3 for details of sematic-driven address 367 lengthening. 369 3.1.2.2. Methodology 371 * Split address zone by network realm: This methodology first split 372 the network realm into two types: one public realm (i.e., the 373 Internet), and innumerable private realms (i.e., local networks, 374 which may be embedded and/or having different scope). Then, it 375 splits the IP address space into two type of zones: global address 376 zone (i.e., public address) and local address zone (e.g., private 377 address, reserved address). Based on this, it is assumed that in 378 public realm, all devices attached to it should be assigned an 379 address that belongs to the global address zone. While for 380 devices attached to private realms, only addresses belonging to 381 the local address zone will be assigned. Local realms may have 382 different scope or even be embedded one in another, like for 383 instance, light switches local network being part of the building 384 local network, which in turn connects to the Internet. In the 385 local realms address may have a pure identification purpose. For 386 instance in last example, addresses of the light switches identify 387 the switches themselves, while the building local network is used 388 to locate them. 390 Given that the local address zone is not globally unique, certain 391 mechanisms are designed to express the relationship between the 392 global address zone (in public realm) and the local address zone 393 (in any private realm). In this case, global addresses are used 394 for forwarding when a packet is in the public realm, and local 395 addresses are used for forwarding when a packet is in a private 396 realms. 398 3.1.2.3. Examples 400 * Split address zone by network realm: Network Address Translation 401 (NAT), which was first laid out in [RFC2663], using private 402 address and a stateful address binding to translate between the 403 realms. As outlined in [RFC2663], basic address translation is 404 usually extended to include port number information in the 405 translation process, supporting bidirectional or simple outbound 406 traffic only. Because the 16-bits port number is used in the 407 address translation, NAT theoretically increase IPv4 address 408 length from 32-bit to 48-bit, i.e., 281 trillion address space. 410 Similarly, EzIP [EzIP] expects to utilize a reserved address 411 block, i.e., 240/4, and an IPv4 header option to include it. 412 Based on this, it can be regarded as EzIP is carrying a 413 hierarchical address with two parts, where each part is a partial 414 32-bit IPv4 address. The first part is a public address residing 415 in the "address field" of the header from globally routable IPv4 416 pool [IPv4pool], i.e., ca. 3.84 billion address space. The second 417 part is the reserved address residing in "option field" and 418 belongs to the 240/4 prefix, i.e., ca. 2^28=268 million. Based on 419 that, each EzIP deployment is tethered on the existing Internet 420 via one single IPv4 address, and EzIP then have 3.84B * 268M 421 address, ca. 1,000,000 trillion. Collectively, the 240/4 can also 422 be used as end point identifier and form an overlay network 423 providing services parallel to the current Internet, yet 424 independent of the latter in other aspects. 426 Compared to NAT, EzIP is able to establish a communication session 427 from either side of it, hence being completely transparent, and 428 facilitating a full end-to-end networking configuration. 430 3.1.3. Summary 432 Table 1 summarizes methodologies and examples towards filling gaps on 433 IP address length extensions. 435 +========================+======================+=============+ 436 | | Methodology | Examples | 437 +========================+======================+=============+ 438 | Shorter Address Length | Header compression/ | 6LoWPAN, | 439 | | translation | ROHC, SCHC | 440 +------------------------+----------------------+-------------+ 441 | | Separate device from | EIBP, LISP, | 442 | | locator identifier | ILNP, HIP | 443 +------------------------+----------------------+-------------+ 444 | Longer Address Length | Split address zone | NAT, EzIP | 445 | | by network realm | | 446 +------------------------+----------------------+-------------+ 448 Table 1: Summary Length Extensions 450 3.2. Identity Extensions 452 Extensions in this subsection attempt extending the property 453 described in Section 2.2, i.e., 'locator/identifier overload' of the 454 ambiguous address semantic. 456 From the perspective of Internet users, on the one hand, the implicit 457 identifier semantic results in a privacy issue due to network 458 behavior tracking and association. Despite that IP address 459 assignments may be dynamic, they are nowadays considered as 'personal 460 data' and as such undergoes privacy protection regulations like 461 General Data Protection Regulation ("GDPR" [GDPR]). Hence, 462 additional mechanisms are necessary in order to protect end user 463 privacy. 465 For network regulation of sensitive information, on the other hand, 466 dynamically allocated IP addresses are not sufficient to guarantee 467 device or user identification. As such, different address allocation 468 systems, with stronger identification properties are necessary where 469 security and authentication are at highest priority. Hence, in order 470 to protect information security within a network, additional 471 mechanism are necessary to identify the users or the devices attached 472 to the network. 474 3.2.1. Anonymous Address Identity 476 3.2.1.1. Description 478 As discussed in Section 2.2, IP addresses reveal both 'network 479 locations' as well as implicit 'identifier' information to both 480 traversed network elements and destination nodes alike. This enables 481 recording, correlation, and profiling of user behaviors and 482 historical network traces, possibly down to individual real user 483 identity. The IETF, e.g., in [RFC7258], has taken a clear stand on 484 preventing any such pervasive monitoring means by classifying them as 485 an attack on end users' right to be left alone (i.e., privacy). 486 Regulations such as the EU's General Data Protection Regulation 487 (GDPR) classifies, for instance, the 'online identifier' as personal 488 data which must be carefully protected; this includes end users' IP 489 addresses [GDPR]. 491 Even before pervasive monitoring [RFC7258], IP addresses have been 492 seen as something that some organizational owners of networked system 493 may not want to reveal at the individual level towards any non-member 494 of the same organization. Beyond that, if forwarding is based on 495 semantic extensions, like other fields of the header, extension 496 headers, or any other possible extension, if not adequately protected 497 it may introduce privacy leakage and/or new attack vectors. 499 3.2.1.2. Methodology: 501 * Traffic Proxy: Detouring the traffic to a trusted proxy is a 502 heuristic solution. Since nodes between trusted proxy and 503 destination (including the destination per se) can only observe 504 the source address of the proxy, the 'identification' of the 505 origin source can thereby be hidden. To obfuscate the nodes 506 between origin and the proxy, the traffic on such route would be 507 encrypted via a key negotiated either in-band or off-band. 508 Considering that all applications' traffic in such route can be 509 seen as a unique flow directed to the same 'unknown' node, i.e., 510 the trusted proxy, eavesdroppers in such route have to make more 511 efforts to correlate user behavior through statistical analysis 512 even if they are capable of identifying the users via their source 513 addresses. The protection lays in the inability to isolate single 514 application specific flows. According to the methodology, such 515 approach is IP version independent and works for both IPv4 and 516 IPv6. 518 * Source Address Rollover: Privacy issues related to address 519 'identifier' semantic can be mitigated through regular change 520 (beyond the typical 24 hours lease of DHCP). Due to the semantics 521 of 'identifier' that an IP address carries, such approach promotes 522 to change the source IP address at a certain frequency. Under 523 such methodology, the refresh cycling window may reach to a 524 balance between privacy protection and address update cost. Due 525 to the limited space that IPv4 contains, such approach usually 526 works for IPv6 only. 528 * Private Address Spaces: Their introduction in [RFC1918] foresaw 529 private addresses (assigned to specific address spaces by the 530 IANA) as a means to communicate purely locally, e.g., within an 531 enterprise, by separating private from public IP addresses. 532 Considering that private addresses are never directly reachable 533 from the Internet, hosts adopting private addresses are invisible 534 and thus 'anonymous' for the Internet. Besides, hosts for purely 535 local communication used the latter while hosts requiring public 536 Internet service access would still use public IP addresses. 538 * Address Translation: The aforementioned original intention for 539 using private IP addresses, namely for purely local communication, 540 resulted in a lack of flexibility in changing from local to public 541 Internet access on the basis of what application would require 542 which type of service. 544 If eventually every end-system in an organization would require 545 some form of public Internet access in addition to local one, an 546 adequate number of public Internet addresses would be required for 547 providing to all end systems. Instead, address translation 548 enables to utilize many private IP addresses within an 549 organization, while only relying on one (or few) public IP 550 addresses for the overall organization. 552 In principle, address translation can be applied recursively. 553 This can be seen in modern broadband access where Internet 554 providers may rely on carrier-grade address translation for all 555 their broadband customers, who in turn employ address translation 556 of their internal home or office addresses to those (private 557 again) IP addresses assigned to them by their network provider. 559 Two benefits arise from the use of (private to public IP) address 560 translation, namely (i) the hiding of local end systems at the 561 level of the (address) assigned organization, and (ii) the 562 reduction of public IP addresses necessary for communication 563 across the Internet. While the latter has been seen for long as a 564 driver for address translation, we focus on the first issue in 565 this section, also since we see such privacy benefit as well as 566 objective as still being valid in addressing systems like IPv6 567 where address scarcity is all but gone [GNATCATCHER]. 569 * Separate device from locator identifier: Solutions that make a 570 clear separation between the routing locator and the identifier, 571 can allow for a device ID of any size, which in turn can be 572 encrypted by a network element deployed at the border of routing 573 domain (e.g., access/edge router). Both source and end-domain 574 addresses can be encrypted and transported, as in the routing 575 domain, only the routing locator is used. 577 3.2.1.3. Examples: 579 * Traffic Proxy: Although not initially designed as a traffic proxy 580 approach, a Virtual Private Network (VPN [VPN]) is widely utilized 581 for packets origin hiding as a traffic detouring methodology. As 582 it evolved, VPN derivatives like WireGuard [WireGuard] have become 583 a mainstream instance for user privacy and security enhancement. 585 With such methodology in mind, onion routing [ONION], instantiated 586 in the TOR Project [TOR], achieves high anonymity through traffic 587 hand over via intermediates, before reaching the destination. 588 Since the architecture of TOR requires at least three proxies, 589 none of them is aware of the entire route. Given that the proxies 590 themselves can be deployed all over cyberspace, trust is not the 591 prerequisite if proxies are randomly selected. 593 In addition, dedicated protocols are also expected to be 594 customized for privacy improvement via traffic proxy. For 595 example, Oblivious DNS over HTTPS (ODoH [ODoH]) use a third-party 596 proxy to obscure identifications of user source addresses during 597 DNS over HTTPS (DoH [RFC8484]) resolution. Similarly, Oblivious 598 HTTP [OHTTP] involve proxy alike in the HTTP environment. 600 * Source Address Rollover: As for source address rollover, it has 601 been standardized that IP addresses for Internet users should be 602 dynamic and temporary every time they are being generated 603 [RFC8981]. This benefits from the available address space in the 604 case of IPv6, through which address generation or assignment 605 should be unpredictable and stochastic for outside observers. 607 More radically, [EPHEMERALv6] advocates an 'ephemeral address', 608 changing over time, for each process. Through this, correlating 609 user behaviors conducted by different identifiers (i.e., source 610 address) becomes much harder, if not impossible, if based on the 611 IP packet header alone. 613 * Private Addresses: The use and assignment of private addresses for 614 IPv4 is laid out in [RFC1918], while unique local addresses (ULAs) 615 in IPv6 [RFC4193] take over the role of private address spaces in 616 IPv4. 618 * Network Address Translation: Given address translation can be 619 performed several times in cascade, NATs may exist as part of 620 existing customer premise equipment (CPE), such as a cable or an 621 Ethernet router, with private wired/wireless connectivity, or may 622 be provided in a carrier environment to further translate ISP- 623 internal private addresses to a pool of (assigned) public IP 624 addresses. The latter is often dynamically assigned to CPEs 625 during its bootstrapping. 627 * Separate device from locator identifier: EIBP [EIBP] utilizes a 628 structured approach to addressing. It separates the routing ID 629 from the device ID, where only the former is used for routing. As 630 such, the device IDs can be encrypted, protecting the end device 631 identity. Similarly, LISP uses separate namespaces for routing 632 and identification allowing to 'hide' identifiers in encrypted 633 LISP packets that expose only known routing information [RFC8061]. 635 3.2.2. Authenticated Address Identity 637 3.2.2.1. Description 639 In some scenarios (e.g., corporate networks) it is desirable to being 640 able authenticate IP addresses in order to prevent malicious 641 attackers spoofing IP addresses. This is usually achieved by using a 642 mechanism that allows to prove ownership of the IP address. 644 3.2.2.2. Methodology 646 * Self-certified addresses: This method is usually based on the use 647 of nodes' public/private keys. A node creates its own interface 648 ID (IID) by using a cryptographic hash of its public key (with 649 some additional parameters). Messages are then signed using the 650 nodes' private key. The destination of the message will verify 651 the signature through the information in the IP address. Self- 652 certification has the advantage that no third party or additional 653 security infrastructure is needed. Any node can generate its own 654 address locally and then only the address and the public key are 655 needed to verify the binding between the public key and the 656 address. 658 * Third party granted addresses: DHCP (Dynamic Host Configuration 659 Protocol) is widely used to provide IP addresses, however, in its 660 basic form, it does not perform any check and even an unauthorized 661 user without the right to use the network can obtain an IP 662 address. To solve this problem, a trusted third party has to 663 grant access to the network before generating an address (via DHCP 664 or other) that identifies the user. User authentication done 665 securely either based on physical parameters like MAC addresses or 666 based on an explicit login/password mechanism. 668 3.2.2.3. Examples 670 * Self-certified Addresses: As an example of this methodology serves 671 [RFC3972], defining IPv6 cryptographically Generated Addresses 672 (CGA). A Cryptographically Generated Address is formed by 673 replacing the least-significant 64 bits of an IPv6 address with 674 the cryptographic hash of the public key of the address owner. 675 Packets are then signed with the private key of the sender. 676 Packets can be authenticate by the receiver by using the public 677 key of the sender and the address of the sender. The original 678 specifications have been already amended (cf., [RFC4581] and 679 [RFC4982]) in order to support multiple (stronger) cryptographic 680 algorithms. 682 * Third party granted addresses: [RFC3118] defines a DHCP option 683 through which authorization tickets can be generated and newly 684 attached hosts with proper authorization can be automatically 685 configured from an authenticated DHCP server. Solutions exist 686 where separate servers are used for user authentication like 687 [UA-DHCP] and [RFC4014]. The former proposing to enhance the DHCP 688 system using registered user login and password before actually 689 providing an IP address lease and recording the MAC address of the 690 device the user used to sign-in. The latter, couples the RADIUS 691 authentication protocol ([RFC2865]) with DHCP, basically 692 piggybacking RADIUS attributes in a DHCP sub-option, with the DHCP 693 server contacting the RADIUS server to authenticate the user. 695 3.2.3. Summary 697 Table 2, summarize the methodologies and the examples towards filling 698 the gaps on identity extensions. 700 +============================+======================+=============+ 701 | | Methodology | Examples | 702 +============================+======================+=============+ 703 | Anonymous Address Identity | Traffic Proxy | VPN, TOR, | 704 | | | ODoH | 705 +----------------------------+----------------------+-------------+ 706 | | Source Address | SLAAC | 707 | | Rollover | | 708 +----------------------------+----------------------+-------------+ 709 | | Private Address | ULA | 710 | | Spaces | | 711 +----------------------------+----------------------+-------------+ 712 | | Address Translation | NAT | 713 +----------------------------+----------------------+-------------+ 714 | | Separate device from | EIBP, LISP | 715 | | locator identifier | | 716 +----------------------------+----------------------+-------------+ 717 | Authenticated Address | Self-certified | CGA | 718 | Identity | Addresses | | 719 +----------------------------+----------------------+-------------+ 720 | | Third party granted | DHCP-Option | 721 | | addresses | | 722 +----------------------------+----------------------+-------------+ 724 Table 2: Summary Identity Extensions 726 3.3. Semantic Extensions 728 Extensions in this subsection try extending the property described in 729 Section 2.3, i.e., limited address semantic support. 731 As explained in Section 2.2, IP addresses carry both locator and 732 identification semantic. Some efforts exist that try to separate 733 these semantics either in different address spaces or through 734 different address formats. Beyond just identification, location, and 735 the fixed address size, other efforts extended the semantic through 736 existing or additional header fields (or header options) outside the 737 Internet address. 739 How much unique and globally routable an address should be? With the 740 effect of centralization, edges communicate with (rather) local DCs, 741 hence a unique address globally routable is not a requirement 742 anymore. There is no need to use globally unique addresses all the 743 time for communication, however, there is the need of having a unique 744 address as a general way to communicate to any connected entity 745 without caring what transmission networks the packets traverse. 747 3.3.1. Utilizing Extended Address Semantics 749 3.3.1.1. Description 751 Several extensions have been developed to extend beyond the limited 752 IPv6 semantics. Those approaches may include to apply structure to 753 the address, utilize specific prefixes, or entirely utilize the IPv6 754 address for different semantics, while re-encapsulating the original 755 packet to restore the semantics in another part of the network. For 756 instance, structured addresses have the capability to introduce 757 delimiters to identify semantic information in the header, therefore 758 not constraining any semantic by size limitations of the address 759 fields. 761 We note here that extensions often start out as being proposed as an 762 extended header semantic, while standardization may drive the 763 solution to adopt an approach to accommodate their semantic within 764 the limitations of an IP address. This section does include examples 765 of this kind. 767 3.3.1.2. Methodology 769 *Semantic prefixes: Semantic prefixes are used to separate the IPv6 770 address space. Through this, new address families, such as for 771 information-centric networking [HICN], service routing or other 772 semantically rich addressing, can be defined, albeit limited by the 773 prefix length and structure as well as the overall length limitation 774 of the IPv6 address. 776 * Separate device/resource from locator identifier: The option to 777 use separate namespaces for the device address would offer more 778 freedom for the use of different semantics. For instance, the 779 static binding of IP addresses to servers creates a strong binding 780 between IP addresses and service/resources, which may be a 781 limitation for large Content Distribution networks (CDNs) 782 [FAYED21]. 784 As an extreme form of separating resource from locator identifier, 785 recent engineering approaches, described in [CLOUDFLARE_SIGCOMM], 786 decouple web service (semantics) from the routing address 787 assignments by using virtual hosting capabilities, thereby 788 effectively mapping possibly millions of services onto a single IP 789 address. 791 * Structured addressing: One approach to address the routing 792 challenges faced in the Internet is the use of structured 793 addresses, e.g., to void the need for routing protocols. Benefits 794 of this approach can be significant, with the structured addresses 795 capturing the relative physical or virtual position of routers in 796 the network as well as being variable in length. Key to the 797 approach, however, is that the structured addresses capturing the 798 relative physical or virtual position of routers in the network, 799 or networks in an internetwork may not fit within the fixed and 800 limited IP address length (cf., Section 3.1.2). Other structured 801 approaches may be the use of application-specific structured 802 binary components for identification, generalizing URL schema used 803 for HTTP-level communication but utilized at the network level for 804 traffic steering decisions. 806 * Localized forwarding semantics: Layer 2 hardware, such as SDN 807 switches, are limited to the use of specific header fields for 808 forwarding decisions. Hence, devising new localized forwarding 809 mechanisms may be based on re-using differently existing header 810 fields, such as the IPv6 source/destination fields, to achieve the 811 desired forwarding behavior, while encapsulating the original 812 packets in order to be restored at the local forwarding network 813 boundary. Networks in those solutions are limited by the size of 814 the utilized address field, e.g., 256 bits for IPv6, thereby 815 limiting the way such techniques could be used. 817 3.3.1.3. Examples 819 * Semantic prefixes: Newer approaches to IP anycast suggest the use 820 of service identification in combination with a binding IP address 821 model [SFCANYCAST] as a way to allow for metric-based traffic 822 steering decisions; approaches for Service Function Chaining (SFC) 823 [RFC7665] utilize the Network Service Header (NSH) information and 824 packet classification to determine the destination of the next 825 service. 827 Another example of the usage of different packet header extensions 828 based on IP addressing is Segment Routing. In this case, the 829 source chooses a path and encodes it in the packet header as an 830 ordered list of segments. Segments are encoded using new Routing 831 Extensions Header type, the Segment Routing Header (SRH), which 832 contains the Segment List, similar to what is already specified in 833 [RFC8200], i.e., a list of segment ID (SID) that dictate the path 834 to follow in the network. Such segment IDs are coded as 128 bit 835 IPv6 addresses [RFC8986]. 837 Approaches such as [HICN] utilize semantic prefixing to allow for 838 ICN forwarding behavior within an IPv6 network. In this case, an 839 HICN name is the hierarchical concatenation of a name prefix and a 840 name suffix, in which the name prefix is encoded as an IPv6 128 841 bits word and carried in IPv6 header fields, while the name suffix 842 is encoded in transport headers fields such as TCP. However, it 843 is a challenge to determine which IPv6 prefixes should be used as 844 name prefixes. In order to know which IPv6 packets should be 845 interpreted based on an ICN semantic, it is desirable to be able 846 to recognize that an IPv6 prefix is a name prefix, e.g. to define 847 a specific address family (AF_HICN, b0001::/16). This 848 establishment of a specific address family allows the management 849 and control plane to locally configure HICN prefixes and announce 850 them to neighbors for interconnection. 852 * Separate device from locator identifier: EIBP [EIBP] separates the 853 routing locator from the device identifier, relaxing therefore any 854 semantic constraints on the device identifier. Similarly, LISP 855 uses a flexible encoding named LISP Canonical Address Format (LCAF 856 [RFC8061]), which allows to associate to routing locators any 857 possible form (and length) of identifier. ILNP [RFC6740] 858 introduces as well a different semantic of IP addresses, while 859 aligning to the IPv6 address format (128 bits). Basically, ILNP 860 introduces a sharper logical separation between the 64 most 861 significant bits and the 64 least significant bits of an IPv6 862 address. The former being a global locator, while the latter 863 being an identifier that can have different semantics (rather than 864 just being an interface identifier). 866 * Structured addressing: Network topology captures the physical 867 connectivity among devices in the network. There is a structure 868 associated with the topology. Examples are the core-distribution- 869 access router structure commonly used in enterprise networks and 870 clos topologies that are used to provide multiple connections 871 between Top of Rack (ToR) devices and multiple layers of spine 872 devices. Internet service providers use a tier structure that 873 defines their business relationships. A clear structure of 874 connected networks can be noticed in the Internet. EIBP [EIBP] 875 proposes to leverage the physical structure (or a virtual 876 structure overlaid on the physical structure) to auto assign 877 addresses to routers in a network or networks in an internetwork 878 to capture their relative position in the physical/virtual 879 topology. EIBP proposes to administratively identify routers/ 880 networks with a tier value based on the structure. 882 * Localized forwarding semantics: Approaches such as those outlined 883 in [REED] suggest using a novel forwarding semantic based on path 884 information carried in the packet itself, said path information 885 consists in a fixed size bit-field (see [REED] for more 886 information on how to represent the path information in said bit- 887 field). In order to utilize existing, e.g., SDN-based, forwarding 888 switches, the direct use of the IPv6 source/destination address is 889 suggested for building appropriate match-action rules (over the 890 suitable binary information representing the local output ports), 891 while preserving the original IPv6 information in the encapsulated 892 packet. As mentioned above, such use of the existing IPv6 address 893 fields limits the size of the network to a maximum of 256 bits 894 (therefore paths in the network over which such packets can be 895 forwarded). [ICNIP], however, goes a step further by suggesting 896 to use the local forwarding as direct network layer mechanism, 897 removing the IP packet and only leaving the transport/application 898 layer, with the path identifier constituting the network-level 899 identifier albeit limited by using the existing IP header for 900 backward compatibility reasons (the next section outlines the 901 removal of this limitation). 903 3.3.2. Utilizing Existing or Extended Header Semantics 905 3.3.2.1. Description: 907 While the former sub-section explored extended address semantic, 908 thereby limiting any such extended semantic with that of the existing 909 IPv6 semantic and length, additional semantics may also be placed 910 into the header of the packet or the packet itself, utilized for the 911 forwarding decision to the appropriate endpoint according to the 912 extended semantic. 914 Reasons for embedding such new semantics may be related to traffic 915 engineering since it has long been shown that the IP address itself 916 is not enough to steer traffic properly since the IP address itself 917 is not semantically rich enough to adequately describe the forwarding 918 decision to be taken in the network, not only impacting WHERE the 919 packet will need to go but also HOW it will need to be sent. 921 3.3.2.2. Methodology: 923 * In-Header extensions: One way to add additional semantics besides 924 the address fields is to use other fields already present in the 925 header. 927 * Headers option extensions: Another mechanism to add additional 928 semantics is to actually add additional fields, e.g., through 929 Header Options in IPv4 or through Extension Headers in IPv6. 931 * Re-encapsulation extension: A more radical approach for additional 932 semantics is the use of a completely new header that is designed 933 so to carry the desired semantics in an efficient manner (often as 934 a shim header). 936 * Structured addressing: Similar to the methodology that structures 937 addresses within the limitations of the IPv6 address length, 938 outlined in the previous sub-sections, structured addressing can 939 also be applied within existing or extended header semantics, 940 e.g., utilizing a dedicated (extension) header to carry the 941 structured address information. 943 * Localized forwarding semantics: This set of solutions applies 944 capabilities of newer (programmable) forwarding technology, such 945 as [P4], to utilize any header information for a localized 946 forwarding decision. This removes any limitation to use existing 947 header or address information for embedding a new address semantic 948 into the transferred packet. 950 3.3.2.3. Examples: 952 * In-Header extensions: In order to allow additional semantic with 953 respect to the pure Internet addressing, the original design of 954 IPv4 included the field 'Type of Service' [RFC2474], while IPv6 955 introduced the 'Flow label' and the 'Traffic Class' [RFC8200]. In 956 a certain way, those fields can be considered 'semantic 957 extensions' of IP addresses, and they are 'in-header' because 958 natively present in the IP header (differently from options and 959 extension headers). However, they proved not to be sufficient. 960 Very often a variety of network operation are performed on the 961 well-known 5-tuple (source and destination addresses; source and 962 destination port number; and protocol number). In some contexts 963 all of the above mentioned fields are used in order to have a very 964 fine grained solution ([RFC8939]). 966 * Headers option extensions: Header options have been largely under- 967 exploited in IPv4. However, the introduction of the more 968 efficient extension header model in IPv6 along with technology 969 progress made the use of header extensions more widespread in 970 IPv6. Segment Routing re-introduced the possibility to add path 971 semantic to the packet by encoding a loosely defined source 972 routing ([RFC8402]). Similarly, in the aim to overcome the 973 inherent shortcoming of the multi-homing in the IP context, SHIM6 974 ([RFC5533]) also proposed the use of an extension header able to 975 carry multi-homing information which cannot be accommodated 976 natively in the IPv6 header. 978 To serve a moving endpoint, mechanisms like Mobile IPv6 [RFC6275] 979 are used for maintaining connection continuity by a dedicated IPv6 980 extension header. In such case, the IP address of the home agent 981 in Mobile IPv6 is basically an identification of the on-going 982 communication. In order to go beyond the interface identification 983 model of IP, the Host Identity Protocol (HIP) tries to introduce 984 an identification layer to provide (as the name says) host 985 identification. The architecture here relies on the use of 986 another type of extension header [RFC7401]. 988 * Re-encapsulation extension: Differently from the previous 989 approach, re-encapsulation prepends complete new IP headers to the 990 original packet introducing a completely custom shim header 991 between the outer and inner header. This is the case for LISP, 992 adding a LISP specific header right after an IP+UDP header 993 ([I-D.ietf-lisp-rfc6830bis]). A similar design is used by VxLAN 994 ([RFC7348]) and GENEVE ([RFC8926]), even if they are designed for 995 a data center context. IP packets can also be wrapped with 996 headers using more generic and semantically rich names, for 997 instance with ICN [ICNIP]. 999 * Structured addressing: Solutions such as those described in the 1000 previous sub-section, e.g., EIBP [EIBP], can provide structured 1001 addresses that are not limited to the IPv6 address length but 1002 instead carry the information in an extension header to remove 1003 such limitation. 1005 Also Information-Centric Networking (ICN) naming approaches 1006 usually introduce structures in the (information) names without 1007 limiting themselves to the IP address length; more so, ICN 1008 proposes its own header format and therefore radically breaks with 1009 not only IP addressing semantic but the format of the packet 1010 header overall. For this, approaches such as those described in 1011 [RFC8609] define a TLV-based binary application component 1012 structure that is carried as a 'name' part of the CCN messages. 1013 Such a name is a hierarchical structure for identifying and 1014 locating a data object, which contains a sequence of name 1015 components. Names are coded based on 2-level nested Type-Length- 1016 Value (TLV) encodings, where the name-type field in the outer TLV 1017 indicates this is a name, while the inner TLVs are name components 1018 including a generic name component, an implicit SHA-256 digest 1019 component and a SHA-256 digest of Interest parameters. For 1020 textual representation, URIs are normally used to represent names, 1021 as defined in [RFC3986]. 1023 In geographic addressing, position based routing protocols use the 1024 geographic location of nodes as their addresses, and packets are 1025 forwarded when possible in a greedy manner towards the 1026 destination. For this purpose, the packet header includes a field 1027 coding the geographic coordinates (x, y, z) of the destination 1028 node, as defined in [RFC2009]. Some proposals also rely on extra 1029 fields in the packet header to code the distance towards the 1030 destination, in which case only the geographic coordinates of 1031 neighbors are exchanged. This way the location of the destination 1032 is protected even if routing packets are eavesdropped. 1034 * Localized forwarding semantics: Unlike the original suggestion in 1035 [REED] to use existing SDN switches, the proliferation of P4 [P4] 1036 opens up the possibility to utilize a locally limited address 1037 semantic, e.g., expressed through the path identifier, as an 1038 entirely new header (including its new address) with an 1039 encapsulation of the IP packet for E2E delivery (including further 1040 delivery outside the localized forwarding network or positioning 1041 the limited address semantic directly as the network address 1042 semantic for the packet, i.e., removing any IP packet 1043 encapsulation from the forwarded packet, as done in [ICNIP]. 1044 Removing the IPv6 address size limitation by not utilizing the 1045 existing IP header for the forwarding decision also allows for 1046 extensible length approaches for building the path identifier with 1047 the potential for increasing the supported network size. On the 1048 downside, this approach requires to encapsulate the original IP 1049 packet header for communication beyond the local domain in which 1050 the new header is being used, such as discussed in the previous 1051 point above on 're-encapsulation extension'. 1053 3.3.3. Summary 1055 Table 3, summarize the methodologies and the examples towards filling 1056 the gaps on semantic extensions. 1058 +===========================+======================+=============+ 1059 | | Methodology | Examples | 1060 +===========================+======================+=============+ 1061 | Utilizing Extended | Semantic prefixes | HICN | 1062 | Address Semantics | | | 1063 +---------------------------+----------------------+-------------+ 1064 | | Separate device from | EIBP, ILNP, | 1065 | | locator identifier | LISP, HIP | 1066 +---------------------------+----------------------+-------------+ 1067 | | Structured | EIBP, ILNP | 1068 | | addressing | | 1069 +---------------------------+----------------------+-------------+ 1070 | | Localized forwarding | REED | 1071 | | semantics | | 1072 +---------------------------+----------------------+-------------+ 1073 | Utilizing Existing or | In-Header extensions | DetNet | 1074 | Extended Header Semantics | | | 1075 +---------------------------+----------------------+-------------+ 1076 | | Headers option | SHIM6, | 1077 | | extensions | SRv6, HIP | 1078 +---------------------------+----------------------+-------------+ 1079 | | Re-encapsulation | VxLAN, | 1080 | | extension | ICNIP | 1081 +---------------------------+----------------------+-------------+ 1082 | | Structured | EIBP | 1083 | | addressing | | 1084 +---------------------------+----------------------+-------------+ 1085 | | Localized forwarding | REED | 1086 | | semantics | | 1087 +---------------------------+----------------------+-------------+ 1089 Table 3: Summary Semantic Extensions 1091 4. Overview of Approaches to Extend Internet Addressing 1093 The following Table 4 describes the objectives of the extensions 1094 discussed in this memo with respect to the properties of Internet 1095 addressing (Section 2}. As summarized, extensions may aim to extend 1096 one property of the Internet addressing, or extend other properties 1097 at the same time. 1099 +============+==================+====================+===========+ 1100 | | Length Extension | Identity Extension | Semantic | 1101 | | | | Extension | 1102 +============+==================+====================+===========+ 1103 | 6LoWPAN | x | | | 1104 +------------+------------------+--------------------+-----------+ 1105 | ROHC | x | | | 1106 +------------+------------------+--------------------+-----------+ 1107 | EzIP | x | | | 1108 +------------+------------------+--------------------+-----------+ 1109 | TOR | | x | | 1110 +------------+------------------+--------------------+-----------+ 1111 | ODoH | | x | | 1112 +------------+------------------+--------------------+-----------+ 1113 | SLAAC | | x | | 1114 +------------+------------------+--------------------+-----------+ 1115 | CGA | | x | x | 1116 +------------+------------------+--------------------+-----------+ 1117 | NAT | x | x | | 1118 +------------+------------------+--------------------+-----------+ 1119 | HICN | | x | x | 1120 +------------+------------------+--------------------+-----------+ 1121 | ICNIP | x | x | x | 1122 +------------+------------------+--------------------+-----------+ 1123 | CCNx names | x | x | x | 1124 +------------+------------------+--------------------+-----------+ 1125 | EIBP | x | x | x | 1126 +------------+------------------+--------------------+-----------+ 1127 | Geo | x | | x | 1128 | addressing | | | | 1129 +------------+------------------+--------------------+-----------+ 1130 | REED | x (with P4) | | x | 1131 +------------+------------------+--------------------+-----------+ 1132 | DetNet | | x | | 1133 +------------+------------------+--------------------+-----------+ 1134 | Mobile IP | | | x | 1135 +------------+------------------+--------------------+-----------+ 1136 | SHIM6 | | | x | 1137 +------------+------------------+--------------------+-----------+ 1138 | SRv6 | | | x | 1139 +------------+------------------+--------------------+-----------+ 1140 | HIP | | x | x | 1141 +------------+------------------+--------------------+-----------+ 1142 | VxLAN | | x | x | 1143 +------------+------------------+--------------------+-----------+ 1144 | LISP | | x | x | 1145 +------------+------------------+--------------------+-----------+ 1146 | SFC | | x | x | 1147 +------------+------------------+--------------------+-----------+ 1149 Table 4: Relationship between Extensions and Internet Addressing 1151 5. A System View on Address 1153 In the following, we investigate in which parts of the overall 1154 Internet system extensions have been proposed and developed. For 1155 this, we divide the possible innovation across two dimensions: 1157 * Horizontal: Internet edge vs core. The criticality, scale, 1158 investment on the core of the Internet makes it more difficult to 1159 introduce innovation, while at the edges there is more 1160 flexibility. As general purpose processors have drastically 1161 improved in performance, data-plane features can be implemented in 1162 software. At the edge of the Internet, it easier to introduce 1163 innovation for several reasons: Economics, faster ROI because of 1164 faster deployment; No need of large scale deployment (and hence 1165 less standardization effort); less stakeholders involved 1166 (sometimes just one, see following point). Furthermore, the fact 1167 that the edge is a place where there is less coordination and 1168 cooperation from the core, is another factor that ease the 1169 innovation. 1171 * Vertical: at which layer of the protocol stack. The difficulty to 1172 innovate varies as well depending at which layer the innovation 1173 takes place. One thing is to innovate at application layer where 1174 the app developer has large degree of freedom, another is to 1175 innovate at network layer, which is more constrained because of 1176 its central point in the architecture. Innovation at higher layer 1177 sometimes leads to walled gardens (aka limited domains [RFC8799]). 1178 Indeed because of the centralization phenomena, an actor offering 1179 a certain service may very well develop and deploy a custom 1180 technology that does not need to be actually standardized because 1181 it is done for its own internal usage. 1183 * Horizontal vs Vertical Innovation: 1185 - In the public Internet, core innovation at lower layer is 1186 harder, often reduced to app-level innovation or building an 1187 overlay limited domain (aka a walled garden). 1189 - At the edges it is easier to innovate at lower layers (more 1190 vertical flexibility) but some form of adaptation is needed if 1191 global reachability is wanted. 1193 Despite these two orthogonal dimensions, innovation does not happen 1194 either horizontally or vertically, rather in both dimensions 1195 simultaneously at various degree. 1197 6. Issues in Extensions to Internet Addressing 1199 While the extensions to the original Internet properties, discussed 1200 in Section 3, demonstrate the benefits of more flexibility in 1201 addressing, they also bring with them a number of issues, which are 1202 discussed in the following section. To this end, the problems 1203 hereafter outlined link to the approaches to extensions summarized in 1204 Section 4. These issues may not be present all the time and 1205 everywhere, since as explained in Section 5, extensions are developed 1206 and deployed in different part of the Internet, which may worsen 1207 things. 1209 6.1. Limiting Address Semantics 1211 Many approaches changing the semantics of communication, e.g., 1212 through separating host identification from network node 1213 identification [RFC7401], separating the device identifier from the 1214 routing locator ([EIBP], [I-D.ietf-lisp-introduction]), or through 1215 identifying content and services directly [HICN], are limited by the 1216 existing packet size and semantic constraints of IPv6, e.g., in the 1217 form of its source and destination network addresses. 1219 While approaches such as [ICNIP] may override the addressing 1220 semantics, e.g., by replacing IPv6 source and destination information 1221 with path identification, a possible unawareness of endpoints still 1222 requires the carrying of other address information as part of the 1223 payload. 1225 Also, the expressible service or content semantic may be limited, as 1226 in [HICN] or the size of supported networks [REED] due to relying on 1227 the limited bit positions usable in IPv6 addresses. 1229 6.2. Complexity and Efficiency 1231 A crucial issue is the additional complexity introduced for realizing 1232 the additional addressing semantics. This is particularly an issue 1233 since we see those additional semantics particularly at the edge of 1234 the Internet, utilizing the existing addressing semantic of the 1235 Internet to interconnect the domains that require those additional 1236 semantics. 1238 Furthermore, any additional complexity often comes with an efficiency 1239 and cost penalty, particularly at the edge of the network, where 1240 resource constraints may play a significant role. Compression 1241 processes, taking [ROHC] as an example, require additional resources 1242 both for the sender generating the compressed header but also the 1243 gateway linking to the general Internet by re-establishing the full 1244 IP header. 1246 Conversely, the performance requirements of core networks, in terms 1247 of packet processing speed, makes the accommodation of extensions to 1248 addressing often prohibitive. This is not only due to the necessary 1249 extra processing that is specific to the extension, but also due to 1250 the complexity that will need to be managed in doing so at 1251 significantly higher speeds than at the edge of the network. The 1252 observations on the dropping of packets with IPv6 extension headers 1253 in the real world is (partially) due to such a implementation 1254 complexity [RFC7872]. 1256 Another example for lowering the efficiency of packet forwarding is 1257 the routing in systems like TOR [TOR]. As detailed before, traffic 1258 in TOR, for anonymity purposes, should be handed over by at least 1259 three intermediates before reaching the destination. Frequent 1260 relaying enhances the privacy, however, because such kind of 1261 solutions are implemented at application level, they come at the cost 1262 of lower communication efficiency. May be a different privacy 1263 enhanced address semantic would enable efficient implementation of 1264 TOR-like solutions at network layer. 1266 6.2.1. Repetitive encapsulation 1268 Repetitive encapsulation is an issue since it bloats the packets size 1269 due to additional encapsulation headers. Addressing proposals such 1270 as those in [ICNIP] utilize path identification within an alternative 1271 forwarding architecture that acts upon the provided path 1272 identification. However, due to the limitation of existing flow- 1273 based architectures with respect to the supported header structures 1274 (in the form of IPv4 or IPv6 headers), the new routing semantics are 1275 being inserted into the existing header structure, while repeating 1276 the original, sender-generated header structure, in the payload of 1277 the packet as it traverses the local domain, effectively doubling the 1278 per-packet header overhead. 1280 The problem is also present in a number of solutions tackling 1281 different issues, e.g., mobility [I-D.ietf-lisp-mn], DC networking 1282 ([RFC8926], [RFC7348], [I-D.ietf-intarea-gue]), traffic engineering 1283 [RFC8986], and privacy ([TOR], [SPHINX]). Certainly these solutions 1284 are able to avoid other issues, like path lengthening or privacy 1285 issues, as described before, but they come at the price of multiple 1286 encapsulations that reduce the effective payload. This, not only 1287 hampers efficiency in terms of header-to-payload ratio, but also 1288 introduces 'encapsulation points', which in turn add complexity to 1289 the (often edge) network as well as fragility due to the addition of 1290 possible failure points; this aspect is discussed in further details 1291 in Section 6.4. 1293 6.2.2. Compounding issues with header compression 1295 IP header overhead requires header compression in constrained 1296 environments, such as wireless sensor networks and IoT in general. 1297 Together with fragmentation, both tasks constitute significant energy 1298 consumption, as shown in [HEADER_COMP_ISSUES1], negatively impacting 1299 resource limited devices that often rely on battery for operation. 1300 Further, the reliance on the compression/decompression points creates 1301 a dependence on such gateways, which may be a problem for 1302 intermittent scenarios. 1304 According to the implementation of _contiki-ng_ [CONTIKI], an example 1305 of operating system for IoT devices, the source codes for 6LowPan 1306 requires at least 600Kb to include a header compression process. In 1307 certain use cases, such requirement can be an obstacle for extremely 1308 constrained devices, especially for the RAM and energy consumption. 1310 6.2.3. Introducing Path Stretch 1312 Mobile IP [RFC6275], which was designed for connection continuity in 1313 the face of moving endpoints, is a typical case for path stretch. 1314 Since traffic must follow a triangular route before arriving at the 1315 destination, such detour routing inevitably impacts transmission 1316 efficiency as well as latency. 1318 6.2.4. Complicating Traffic Engineering 1320 While many extensions to the original IP address semantic target to 1321 enrich the decisions that can be taken to steer traffic, according to 1322 requirements like QoS, mobility, chaining, compute/network metrics, 1323 flow treatment, path usage, etc., the realization of the mechanisms 1324 as individual solutions likely complicates the original goal of 1325 traffic engineering when individual solutions are being used in 1326 combination. Ultimately, this may even prevent the combined use of 1327 more than one mechanism and/or policy with a need to identify and 1328 prevent incompatibilities of mechanisms. Key here is not the issue 1329 arising from using conflicting traffic engineering policies, rather 1330 conflicting realizations of policies that may well generally work 1331 well alongside ([ROBUSTSDN], [TRANSACTIONSDN]). 1333 This not only increases fragility, as discussed separately in 1334 Section 6.4, but also requires careful planning of which mechanisms 1335 to use and in which combination, likely needing human-in-the-loop 1336 approaches alongside possible automation approaches for the 1337 individual solutions. 1339 6.3. Security 1341 The properties described in Section 2 have, obviously, also 1342 consequences in terms of security and privacy related issues, as 1343 already mentioned in other parts of this document. 1345 For instance, in the effort of being somehow backward compatible, HIP 1346 [RFC7401] uses a 128-bit Host Identity, which may be not sufficiently 1347 cryptographically strong in the future because of the limited size 1348 (future computational power may erode 128-bit security). Similarly, 1349 CGA [RFC3972] also aligns to the 128-bit limit, but may use only 59 1350 bits of them, hence, the packet signature may not be sufficiently 1351 robust to attacks [I-D.rafiee-6man-cga-attack]. 1353 IP addresses, even temporary ones meant to protect privacy, have been 1354 long recognized as a 'Personal Identification Information' that 1355 allows even to geolocate the communicating endpoints [RFC8280]. The 1356 use of temporary addresses provides sufficient privacy protection 1357 only if the renewal rate is high [EPHEMERALv6]. However, this causes 1358 additional issues, like the large overhead due to the Duplicate 1359 Address Detection, the impact on the Neighbor Discovery mechanism, in 1360 particular the cache, which can even lead to communication 1361 disruption. With such drawbacks, the extensions may even lead to 1362 defeat the target, actually lowering security rather than increasing 1363 it. 1365 The introduction of alternative addressing semantics has also been 1366 used to help in (D)DoS attacks mitigation. This leverages on 1367 changing the service identification model so to avoid topological 1368 information exposure, making the potential disruptions likely remain 1369 limited [ADDRLESS]. However, this increased robustness to DDoS comes 1370 at the price of important communication setup latency and fragility, 1371 as discussed next. 1373 6.4. Fragility 1375 From the extensions discussed in Section 3, it is evident that having 1376 alternative or additional address semantic and formats available for 1377 making routing as well as forwarding decisions dependent on these, is 1378 common place in the Internet. This, however, adds many extension- 1379 specific translation/adaptation points, mapping the semantic and 1380 format in one context into what is meaningful in another context, but 1381 also, more importantly, creating a dependency towards an additional 1382 component, often without explicit exposure to the endpoints that 1383 originally intended to communicate. 1385 For instance, the re-writing of IP addresses to facilitate the use of 1386 private address spaces throughout the public Internet, realized 1387 through network address translators (NATs), conflicts with the end- 1388 to-end nature of communication between two endpoints. Additional 1389 (flow) state is required at the NAT middle-box to smoothly allow 1390 communication, which in turn creates a dependency between the NAT and 1391 the end-to-end communication between those endpoints, thus increasing 1392 the fragility of the communication relation. 1394 A similar situation arises when supporting constrained environments 1395 through a header compression mechanism, adding the need for, e.g., a 1396 ROHC [RFC5795] element in the communication path, with communication- 1397 related compression state being held outside the communicating 1398 endpoints. Failure will introduce some inefficiencies due to context 1399 regeneration, which may affects the communicating endpoints, 1400 increasing fragility of the system overall. 1402 Such translation/adaptation between semantic extensions to the 1403 original 'semantic' of an IP address is generally not avoidable when 1404 accommodating more than a single universal semantic. However, the 1405 solution-specific nature of every single extension is likely to 1406 noticeably increase the fragility of the overall system, since 1407 individual extensions will need to interact with other extensions 1408 that may be deployed in parallel, but were not designed taking into 1409 account such deployment scenario (cf., [I-D.ietf-intarea-tunnels]). 1410 Considering that extensions to traditional per-hop-behavior (based on 1411 IP addresses) can essentially be realized over almost 'any' packet 1412 field, the possible number of conflicting behaviors or diverging 1413 interpretation of the semantic and/or content of such fields, among 1414 different extensions, may soon become an issue, requiring careful 1415 testing and delineation at the boundaries of the network within which 1416 the specific extension has been realized. 1418 7. Summary of issues 1420 Table 5, derived from Section 6, summarizes the issues related to 1421 each extension. While each extension involves at least one issue, 1422 some others, like ICNIP, may create several issues at the same time. 1424 +============+==================+============+==========+===========+ 1425 | | Limiting | Complexity | Security | Fragility | 1426 | | Address | and | | | 1427 | | Semantics | Efficiency | | | 1428 +============+==================+============+==========+===========+ 1429 | 6LoWPAN | | x | | x | 1430 +------------+------------------+------------+----------+-----------+ 1431 | ROHC | | x | | x | 1432 +------------+------------------+------------+----------+-----------+ 1433 | EzIP | | x | | | 1434 +------------+------------------+------------+----------+-----------+ 1435 | TOR | | x | | x | 1436 +------------+------------------+------------+----------+-----------+ 1437 | ODoH | | x | | | 1438 +------------+------------------+------------+----------+-----------+ 1439 | SLAAC | | x | | | 1440 +------------+------------------+------------+----------+-----------+ 1441 | CGA | x | | x | | 1442 +------------+------------------+------------+----------+-----------+ 1443 | NAT | | x | | x | 1444 +------------+------------------+------------+----------+-----------+ 1445 | HICN | x | | | | 1446 +------------+------------------+------------+----------+-----------+ 1447 | ICNIP | x | x | | | 1448 +------------+------------------+------------+----------+-----------+ 1449 | CCNx name | x | | | | 1450 +------------+------------------+------------+----------+-----------+ 1451 | EIBP | | | | x | 1452 +------------+------------------+------------+----------+-----------+ 1453 | Geo | x | | | x | 1454 | addressing | | | | | 1455 +------------+------------------+------------+----------+-----------+ 1456 | REED | x | | | | 1457 +------------+------------------+------------+----------+-----------+ 1458 | DetNet | | x | | | 1459 +------------+------------------+------------+----------+-----------+ 1460 | Mobile IP | | x | | x | 1461 +------------+------------------+------------+----------+-----------+ 1462 | SHIM6 | | | | x | 1463 +------------+------------------+------------+----------+-----------+ 1464 | SRv6 | | | | x | 1465 +------------+------------------+------------+----------+-----------+ 1466 | HIP | | | x | x | 1467 +------------+------------------+------------+----------+-----------+ 1468 | VxLAN | | x | | | 1469 +------------+------------------+------------+----------+-----------+ 1470 | LISP | | x | | x | 1471 +------------+------------------+------------+----------+-----------+ 1472 | SFC | | x | | x | 1473 +------------+------------------+------------+----------+-----------+ 1475 Table 5: Issues in Extensions to Internet Addressing 1477 8. Conclusions 1479 The examples of extensions discussed in Section 3 to the original 1480 Internet addressing scheme show that extensibility beyond the 1481 original model (and its underlying per-hop behavior) is a desired 1482 capability for networking technologies and has been so for a long 1483 time. Generally, we can observe that those extensions are driven by 1484 the requirements of stakeholders, expecting a desirable extended 1485 functionality from the introduction of the specific extension. If 1486 interoperability is required, those extensions require 1487 standardization of possibly new fields, new semantics as well as 1488 (network and/or end system) operations alike. 1490 The issues we identified in this document with the extension-specific 1491 solution approach, point to the need for a discussion on Internet 1492 addressing, as formulated in the companion document 1493 [I-D.jia-intarea-scenarios-problems-addressing] that formalizes the 1494 problem statement through scenarios that highlight the shortcomings 1495 of the Internet addressing model. 1497 It is our conclusion that the existence of the many extensions to the 1498 original Internet addressing is clear evidence for gaps that have 1499 been identified over time by the wider Internet community, each of 1500 which come with a raft of issues that we need to deal with daily: We 1501 believe that it is time to develop an architectural but more 1502 importantly a sustainable approach to make Internet addressing 1503 extensible in order to capture the many new use cases that will still 1504 be identified for the Internet to come. 1506 To jumpstart any such effort from an addressing perspective, it will 1507 be key to suitable define what an address is at which layer of the 1508 overall system, let alone the network layer. We argue that any 1509 answer to this question must be derived from what features we may 1510 want from the network instead of being guided by the answers that the 1511 Internet can give us today, e.g., being a mere ephemeral token for 1512 accessing PoP-based services (as indicated in related arch-d mailing 1513 list discussions). 1515 This is not to 'second guess' the market and its possible evolution, 1516 but to outline clear features from which to derive clear principles 1517 for a design. Any such design must not skew the technical 1518 capabilities of addressing to the current economic situation of the 1519 Internet since this bears the danger of locking down innovation 1520 capabilities as an outcome of those technical limitations introduced. 1521 Instead, addressing must be aligned with enabling the model of 1522 permissionless innovation that the IETF has been promoting, 1523 ultimately enabling the serendipity of new applications that has led 1524 to many of those applications we can see in the Internet today. Most 1525 importantly, any inaction on our side in that regard will only 1526 compound the issues identified, eventually hampering the future 1527 Internet's readiness for those new uses. 1529 9. Security Considerations 1531 The present memo does not introduce any new technology and/or 1532 mechanism and as such does not introduce any security threat to the 1533 TCP/IP protocol suite. 1535 As an additional note, and as discussed in this document, security 1536 and privacy aspects were not considered as part of the key properties 1537 for Internet addressing, which led to the introduction of a number of 1538 extensions intending to fix those gaps. The analysis presented in 1539 this memo (non-exhaustively) shows those issues are either solved in 1540 an ad-hoc manner at application level, or at transport layer, while 1541 at network level only few extensions tackling specific aspects exist, 1542 albeit often with limitations due to the adherence to the Internet 1543 addressing model and its properties. 1545 10. IANA Considerations 1547 This document does not include any IANA request. 1549 11. Informative References 1551 [ADDRLESS] Hao, S., Liu, R., Weng, Z., Chang, D., Bao, C., and X. Li, 1552 "Addressless: A new internet server model to prevent 1553 network scanning", PLOS ONE Vol. 16, pp. e0246293, 1554 DOI 10.1371/journal.pone.0246293, February 2021, 1555 . 1557 [CLOUDFLARE_SIGCOMM] 1558 Fayed, M., Bauer, L., Giotsas, V., Kerola, S., Majkowski, 1559 M., Odintsov, P., Sitnicki, J., Chung, T., Levin, D., 1560 Mislove, A., Wood, C., and N. Sullivan, "The ties that un- 1561 bind: decoupling IP from web services and sockets for 1562 robust addressing agility at CDN-scale", Proceedings of 1563 the 2021 ACM SIGCOMM 2021 Conference, 1564 DOI 10.1145/3452296.3472922, August 2021, 1565 . 1567 [CONTIKI] "Contiki-NG: The OS for Next Generation IoT Devices", 1568 n.d., . 1570 [EIBP] Shenoy, S Chandraiah, P Willis, N., "A Structured Approach 1571 to Routing in the Internet", June 2021, . 1575 [EPHEMERALv6] 1576 Gont, F. and G. Gont, "IPv6 Addressing Considerations", 1577 Work in Progress, Internet-Draft, draft-gont-v6ops-ipv6- 1578 addressing-considerations-01, 21 February 2021, 1579 . 1582 [EzIP] Chen, A. Y., Ati, R. R., Karandikar, A., and D. R. Crowe, 1583 "Adaptive IPv4 Address Space", Work in Progress, Internet- 1584 Draft, draft-chen-ati-adaptive-ipv4-address-space-10, 8 1585 December 2021, . 1588 [FAYED21] Fayed, M., Bauer, L., Giotsas, V., Kerola, S., Majkowski, 1589 M., Odintsov, P., Sitnicki, J., Chung, T., Levin, D., 1590 Mislove, A., Wood, C., and N. Sullivan, "The ties that un- 1591 bind: decoupling IP from web services and sockets for 1592 robust addressing agility at CDN-scale", Proceedings of 1593 the 2021 ACM SIGCOMM 2021 Conference, 1594 DOI 10.1145/3452296.3472922, August 2021, 1595 . 1597 [GDPR] Voigt, P. and A. von dem Bussche, "The EU General Data 1598 Protection Regulation (GDPR)", Springer International 1599 Publishing book, DOI 10.1007/978-3-319-57959-7, 2017, 1600 . 1602 [GNATCATCHER] 1603 "Global Network Address Translation Combined with Audited 1604 and Trusted CDN or HTTP-Proxy Eliminating 1605 Reidentification", n.d., 1606 . 1608 [HEADER_COMP_ISSUES1] 1609 Mesrinejad, F., Hashim, F., Noordin, N., Rasid, M., and R. 1610 Abdullah, "The effect of fragmentation and header 1611 compression on IP-based sensor networks (6LoWPAN)", The 1612 17th Asia Pacific Conference on Communications, 1613 DOI 10.1109/apcc.2011.6152926, October 2011, 1614 . 1616 [HICN] Muscariello, L., "Hybrid Information-Centric Networking: 1617 ICN inside the Internet Protocol", March 2018, 1618 . 1622 [HISTORY127] 1623 "History of 127/8 as localhost/loopback addresses", n.d., 1624 . 1627 [I-D.ietf-6lo-nfc] 1628 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 1629 "Transmission of IPv6 Packets over Near Field 1630 Communication", Work in Progress, Internet-Draft, draft- 1631 ietf-6lo-nfc-17, 23 August 2020, 1632 . 1635 [I-D.ietf-6lo-plc] 1636 Hou, J., Liu, B., Hong, Y., Tang, X., and C. E. Perkins, 1637 "Transmission of IPv6 Packets over PLC Networks", Work in 1638 Progress, Internet-Draft, draft-ietf-6lo-plc-10, 17 1639 February 2022, . 1642 [I-D.ietf-intarea-gue] 1643 Herbert, T., Yong, L., and O. Zia, "Generic UDP 1644 Encapsulation", Work in Progress, Internet-Draft, draft- 1645 ietf-intarea-gue-09, 26 October 2019, 1646 . 1649 [I-D.ietf-intarea-tunnels] 1650 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1651 Architecture", Work in Progress, Internet-Draft, draft- 1652 ietf-intarea-tunnels-10, 12 September 2019, 1653 . 1656 [I-D.ietf-lisp-introduction] 1657 Cabellos, A. and D. S. (Ed.), "An Architectural 1658 Introduction to the Locator/ID Separation Protocol 1659 (LISP)", Work in Progress, Internet-Draft, draft-ietf- 1660 lisp-introduction-15, 20 September 2021, 1661 . 1664 [I-D.ietf-lisp-mn] 1665 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1666 Mobile Node", Work in Progress, Internet-Draft, draft- 1667 ietf-lisp-mn-11, 30 January 2022, 1668 . 1671 [I-D.ietf-lisp-rfc6830bis] 1672 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1673 Cabellos, "The Locator/ID Separation Protocol (LISP)", 1674 Work in Progress, Internet-Draft, draft-ietf-lisp- 1675 rfc6830bis-36, 18 November 2020, 1676 . 1679 [I-D.ietf-lisp-rfc6833bis] 1680 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1681 "Locator/ID Separation Protocol (LISP) Control-Plane", 1682 Work in Progress, Internet-Draft, draft-ietf-lisp- 1683 rfc6833bis-30, 18 November 2020, 1684 . 1687 [I-D.jia-intarea-scenarios-problems-addressing] 1688 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., Mendes, P., 1689 3rd, D. E. E., and P. Liu, "Challenging Scenarios and 1690 Problems in Internet Addressing", Work in Progress, 1691 Internet-Draft, draft-jia-intarea-scenarios-problems- 1692 addressing-02, 23 October 2021, 1693 . 1696 [I-D.rafiee-6man-cga-attack] 1697 Rafiee, H. and C. Meinel, "Possible Attack on 1698 Cryptographically Generated Addresses (CGA)", Work in 1699 Progress, Internet-Draft, draft-rafiee-6man-cga-attack-03, 1700 8 May 2015, . 1703 [ICNIP] Trossen, D., Robitzsch, S., Reed, M., Al-Naday, M., and J. 1704 Riihijarvi, "Internet Services over ICN in 5G LAN 1705 Environments", Work in Progress, Internet-Draft, draft- 1706 trossen-icnrg-internet-icn-5glan-04, 1 October 2020, 1707 . 1710 [IPv4pool] "IANA IPv4 Address Space Registry", n.d., 1711 . 1714 [ITU9959] Badenhop, C., Fuller, J., Hall, J., Ramsey, B., and M. 1715 Rice, "Evaluating ITU-T G.9959 Based Wireless Systems Used 1716 in Critical Infrastructure Assets", IFIP Advances in 1717 Information and Communication Technology pp. 209-227, 1718 DOI 10.1007/978-3-319-26567-4_13, 2015, 1719 . 1721 [ODoH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 1722 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 1723 Internet-Draft, draft-pauly-dprive-oblivious-doh-11, 17 1724 February 2022, . 1727 [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 1728 Progress, Internet-Draft, draft-thomson-http-oblivious-02, 1729 24 August 2021, . 1732 [ONION] Goldschlag, D., Reed, M., and P. Syverson, "Onion 1733 routing", Communications of the ACM Vol. 42, pp. 39-41, 1734 DOI 10.1145/293411.293443, February 1999, 1735 . 1737 [P4] Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N., 1738 Rexford, J., Schlesinger, C., Talayco, D., Vahdat, A., 1739 Varghese, G., and D. Walker, "P4: programming protocol- 1740 independent packet processors", ACM SIGCOMM Computer 1741 Communication Review Vol. 44, pp. 87-95, 1742 DOI 10.1145/2656877.2656890, July 2014, 1743 . 1745 [REED] Reed, M., Al-Naday, M., Thomos, N., Trossen, D., 1746 Petropoulos, G., and S. Spirou, "Stateless multicast 1747 switching in software defined networks", 2016 IEEE 1748 International Conference on Communications (ICC), 1749 DOI 10.1109/icc.2016.7511036, May 2016, 1750 . 1752 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1753 DOI 10.17487/RFC0791, September 1981, 1754 . 1756 [RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP 1757 Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752, 1758 January 1995, . 1760 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 1761 J., and E. Lear, "Address Allocation for Private 1762 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 1763 February 1996, . 1765 [RFC2009] Imielinski, T. and J. Navas, "GPS-Based Addressing and 1766 Routing", RFC 2009, DOI 10.17487/RFC2009, November 1996, 1767 . 1769 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1770 Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101, 1771 February 1997, . 1773 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1774 "Definition of the Differentiated Services Field (DS 1775 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1776 DOI 10.17487/RFC2474, December 1998, 1777 . 1779 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1780 Translator (NAT) Terminology and Considerations", 1781 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1782 . 1784 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1785 "Remote Authentication Dial In User Service (RADIUS)", 1786 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1787 . 1789 [RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for 1790 DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, 1791 . 1793 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1794 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1795 . 1797 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1798 Resource Identifier (URI): Generic Syntax", STD 66, 1799 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1800 . 1802 [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication Dial- 1803 In User Service (RADIUS) Attributes Suboption for the 1804 Dynamic Host Configuration Protocol (DHCP) Relay Agent 1805 Information Option", RFC 4014, DOI 10.17487/RFC4014, 1806 February 2005, . 1808 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1809 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1810 . 1812 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1813 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1814 2006, . 1816 [RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated 1817 Addresses (CGA) Extension Field Format", RFC 4581, 1818 DOI 10.17487/RFC4581, October 2006, 1819 . 1821 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 1822 Algorithms in Cryptographically Generated Addresses 1823 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 1824 . 1826 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1827 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1828 June 2009, . 1830 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1831 Header Compression (ROHC) Framework", RFC 5795, 1832 DOI 10.17487/RFC5795, March 2010, 1833 . 1835 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 1836 DOI 10.17487/RFC6250, May 2011, 1837 . 1839 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1840 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1841 2011, . 1843 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1844 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1845 DOI 10.17487/RFC6282, September 2011, 1846 . 1848 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1849 Protocol (ILNP) Architectural Description", RFC 6740, 1850 DOI 10.17487/RFC6740, November 2012, 1851 . 1853 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1854 Constrained-Node Networks", RFC 7228, 1855 DOI 10.17487/RFC7228, May 2014, 1856 . 1858 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1859 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1860 2014, . 1862 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1863 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1864 eXtensible Local Area Network (VXLAN): A Framework for 1865 Overlaying Virtualized Layer 2 Networks over Layer 3 1866 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1867 . 1869 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1870 IPv6 over Low-Power Wireless Personal Area Networks 1871 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1872 2014, . 1874 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1875 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1876 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1877 . 1879 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1880 Chaining (SFC) Architecture", RFC 7665, 1881 DOI 10.17487/RFC7665, October 2015, 1882 . 1884 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1885 "Observations on the Dropping of Packets with IPv6 1886 Extension Headers in the Real World", RFC 7872, 1887 DOI 10.17487/RFC7872, June 2016, 1888 . 1890 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1891 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1892 February 2017, . 1894 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 1895 (LISP) Data-Plane Confidentiality", RFC 8061, 1896 DOI 10.17487/RFC8061, February 2017, 1897 . 1899 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1900 M., and D. Barthel, "Transmission of IPv6 Packets over 1901 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1902 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1903 2017, . 1905 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1906 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1907 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1908 May 2017, . 1910 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1911 (IPv6) Specification", STD 86, RFC 8200, 1912 DOI 10.17487/RFC8200, July 2017, 1913 . 1915 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1916 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1917 October 2017, . 1919 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1920 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1921 . 1923 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1924 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1925 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1926 July 2018, . 1928 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1929 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1930 . 1932 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 1933 Networking (CCNx) Messages in TLV Format", RFC 8609, 1934 DOI 10.17487/RFC8609, July 2019, 1935 . 1937 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 1938 Zuniga, "SCHC: Generic Framework for Static Context Header 1939 Compression and Fragmentation", RFC 8724, 1940 DOI 10.17487/RFC8724, April 2020, 1941 . 1943 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1944 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1945 . 1947 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 1948 "Geneve: Generic Network Virtualization Encapsulation", 1949 RFC 8926, DOI 10.17487/RFC8926, November 2020, 1950 . 1952 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 1953 Bryant, "Deterministic Networking (DetNet) Data Plane: 1954 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 1955 . 1957 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 1958 "Temporary Address Extensions for Stateless Address 1959 Autoconfiguration in IPv6", RFC 8981, 1960 DOI 10.17487/RFC8981, February 2021, 1961 . 1963 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1964 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1965 (SRv6) Network Programming", RFC 8986, 1966 DOI 10.17487/RFC8986, February 2021, 1967 . 1969 [ROBUSTSDN] 1970 Canini, M., Kuznetsov, P., Levin, D., and S. Schmid, "A 1971 distributed and robust SDN control plane for transactional 1972 network updates", 2015 IEEE Conference on Computer 1973 Communications (INFOCOM), 1974 DOI 10.1109/infocom.2015.7218382, April 2015, 1975 . 1977 [ROHC] Fitzek, F., Rein, S., Seeling, P., and M. Reisslein, 1978 "RObust Header Compression (ROHC) Performance for 1979 Multimedia Transmission over 3G/4G Wireless Networks", 1980 Wireless Personal Communications Vol. 32, pp. 23-41, 1981 DOI 10.1007/s11277-005-7733-2, January 2005, 1982 . 1984 [SFCANYCAST] 1985 Wion, A., Bouet, M., Iannone, L., and V. Conan, 1986 "Distributed Function Chaining with Anycast Routing", 1987 Proceedings of the 2019 ACM Symposium on SDN Research, 1988 DOI 10.1145/3314148.3314355, April 2019, 1989 . 1991 [SPHINX] Danezis, G. and I. Goldberg, "Sphinx: A Compact and 1992 Provably Secure Mix Format", 2009 30th IEEE Symposium on 1993 Security and Privacy, DOI 10.1109/sp.2009.15, May 2009, 1994 . 1996 [TOR] "The Tor Project", n.d., . 1998 [TRANSACTIONSDN] 1999 Curic, M., Despotovic, Z., Hecker, A., and G. Carle, 2000 "Transactional Network Updates in SDN", 2018 European 2001 Conference on Networks and Communications (EuCNC), 2002 DOI 10.1109/eucnc.2018.8442793, June 2018, 2003 . 2005 [UA-DHCP] Komori, T. and T. Saito, "The secure DHCP system with user 2006 authentication", 27th Annual IEEE Conference on Local 2007 Computer Networks, 2002. Proceedings. LCN 2002., 2008 DOI 10.1109/lcn.2002.1181774, n.d., 2009 . 2011 [VPN] Khanvilkar, S. and A. Khokhar, "Virtual private networks: 2012 an overview with performance evaluation", IEEE 2013 Communications Magazine Vol. 42, pp. 146-154, 2014 DOI 10.1109/mcom.2004.1341273, October 2004, 2015 . 2017 [WireGuard] 2018 Donenfeld, J., "WireGuard: Next Generation Kernel Network 2019 Tunnel", Proceedings 2017 Network and Distributed System 2020 Security Symposium, DOI 10.14722/ndss.2017.23160, 2017, 2021 . 2023 Acknowledgments 2025 Thanks to all the people that shared insightful comments both 2026 privately to the authors as well as on various mailing list, 2027 especially on the INTArea Mailing List. Also thanks for the 2028 interesting discussions to Carsten Borman, Brian E. Carpenter. 2030 Authors' Addresses 2032 Yihao Jia 2033 Huawei Technologies Co., Ltd 2034 156 Beiqing Rd. 2035 Beijing 2036 100095 2037 P.R. China 2038 Email: jiayihao@huawei.com 2039 Dirk Trossen 2040 Huawei Technologies Duesseldorf GmbH 2041 Riesstr. 25C 2042 80992 Munich 2043 Germany 2044 Email: dirk.trossen@huawei.com 2046 Luigi Iannone 2047 Huawei Technologies France S.A.S.U. 2048 18, Quai du Point du Jour 2049 92100 Boulogne-Billancourt 2050 France 2051 Email: luigi.iannone@huawei.com 2053 Paulo Mendes 2054 Airbus 2055 Willy-Messerschmitt Strasse 1 2056 81663 Munich 2057 Germany 2058 Email: paulo.mendes@airbus.com 2060 Nirmala Shenoy 2061 Rochester Institute of Technology 2062 New-York, 14623 2063 United States of America 2064 Email: nxsvks@rit.edu 2066 Laurent Toutain 2067 IMT-Atlantique 2068 2 rue de la Chataigneraie 2069 CS 17607 2070 35576 Cesson-Sevigne Cedex 2071 France 2072 Email: laurent.toutain@imt-atlantique.fr 2074 Abraham Y. Chen 2075 Avinta Communications, Inc. 2076 142 N. Milpitas Blvd. 2077 Milpitas, CA, 95035-4401 2078 United States of America 2079 Email: AYChen@Avinta.com 2080 Dino Farinacci 2081 lispers.net 2082 United States of America 2083 Email: farinacci@gmail.com