idnits 2.17.1 draft-eckert-intarea-functional-addr-internets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-farrel-soon-07 == Outdated reference: A later version (-03) exists of draft-jia-intarea-scenarios-problems-addressing-01 == Outdated reference: A later version (-08) exists of draft-king-irtf-challenges-in-routing-03 == Outdated reference: A later version (-04) exists of draft-king-irtf-semantic-routing-survey-02 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA T. Eckert 3 Internet-Draft Futurewei Technologies USA 4 Intended status: Informational July 12, 2021 5 Expires: January 13, 2022 7 Functional Addressing (FA) for internets with Independent Network 8 Address Spaces (IINAS) 9 draft-eckert-intarea-functional-addr-internets-00 11 Abstract 13 Recent work has raised interest in exploring network layer addressing 14 that is more flexible than fixed-length addressing as used in IPv4 15 (32 bit) and IPv6 (128 bit). 17 The reasons for the interest include both support for multiple and 18 potentially novel address semantics, but also optimizations of 19 addressing for existing semantics such as unicast tailored not for 20 the global Internet but to better support private networks / limited 21 domains. 23 This memo explores in the view of the author yet little explored 24 reasons for more flexible addresses namely the problems and 25 opportunities for Internetworking with Independent Network Address 26 Spaces (IINAS). 28 To better enable such internetworks, this memo proposes a framework 29 for a Functional Addressing model. This model also intends to 30 support several other addressing goals including programmability and 31 multiple semantics. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 13, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. High level observations . . . . . . . . . . . . . . . . . 4 72 2.2. Internetworking limited domain networks with IP 73 addressing . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Shorter addresses . . . . . . . . . . . . . . . . . . . . 8 75 2.4. Additional semantics . . . . . . . . . . . . . . . . . . 9 76 2.5. Programmability . . . . . . . . . . . . . . . . . . . . . 10 77 3. FA-IINAS: Functional Addressing (FA) for Internetworking with 78 Independent Network Address Spaces (IINAS) . . . . . . . . . 10 79 3.1. Addressing for unicast . . . . . . . . . . . . . . . . . 11 80 3.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.2.1. Dispose Function . . . . . . . . . . . . . . . . . . 11 82 3.2.2. Steering Function . . . . . . . . . . . . . . . . . . 12 83 3.2.3. Multiple semantics . . . . . . . . . . . . . . . . . 12 84 3.2.4. Internetworking Function . . . . . . . . . . . . . . 13 85 3.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 16 86 3.3.1. Unicast routing . . . . . . . . . . . . . . . . . . . 16 87 3.3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . 17 88 3.3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 18 89 3.3.4. Routing policies . . . . . . . . . . . . . . . . . . 19 90 3.4. Hardware considerations . . . . . . . . . . . . . . . . . 19 91 3.4.1. Forwarding plane simplicity . . . . . . . . . . . . . 19 92 3.4.2. Optimizing for smaller networks . . . . . . . . . . . 20 93 3.4.3. Maximum address sizes . . . . . . . . . . . . . . . . 21 94 3.5. Example packet header encoding . . . . . . . . . . . . . 21 95 4. Inspirations . . . . . . . . . . . . . . . . . . . . . . . . 22 96 4.1. E.164 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 4.3. Segment Routing SR-MPLS / SRv6 . . . . . . . . . . . . . 25 99 4.4. Research . . . . . . . . . . . . . . . . . . . . . . . . 26 100 5. Summary and conclusions . . . . . . . . . . . . . . . . . . . 26 101 6. Informative References . . . . . . . . . . . . . . . . . . . 27 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 104 1. Introduction 106 1.1. Overview 108 Recent work has examined the value of more flexible than fixed-length 109 addressing used in IPv4 (32 bit) and IPv6 (128 bit), see for example 110 [I-D.jia-intarea-scenarios-problems-addressing], and 111 [I-D.jia-flex-ip-address-structure]. 113 The reasons for this interest include both support for multiple and 114 potentially novel address semantics, see for example 115 [I-D.king-irtf-semantic-routing-survey] and 116 [I-D.king-irtf-challenges-in-routing], but also optimizations of 117 addressing for existing semantics, such as unicast, that are tailored 118 not for the global Internet but to better support private networks 119 and limited domains ([RFC8799]). 121 This memo describes one, in the view of the author yet little 122 explored reason, for more flexible addresses namely the problems and 123 opportunities for Internetworking with Independent Network Address 124 Spaces (IINAS). 126 To better enable such internetworks, this memo proposes a framework 127 for a Functional Addressing model. This model also intends to 128 support several other addressing model goals including 129 programmability and multiple semantics. 131 This memo calls the addressing model functional, because addresses 132 are constructed as a structure of 133 func1{parameter(s),func2{parameter(s),..i.funcN{parameter(s)}}}. 135 1.2. Disclaimer 137 Any proposals made by this document are explicitly for the purpose of 138 presenting example options of realizing concepts introduced in the 139 memo. There is no intent for any proposals in this document to 140 directly become anything more than just experimental implementations 141 for proof of concept purposes. Equally so or even more so, readers 142 are welcome to pick up any subset of ideas from this memo that they 143 are interested in and reuse it in other designs. 145 2. Challenges 147 This section discusses challenges that gave rise to the proposal in 148 this document. It explores in more detail the core challenge not 149 well explored elsewhere and already detailled elsewhere. 151 2.1. High level observations 153 There are three core challenges we can observe that limit the ability 154 to build more varied internetworking solutions for non-solely 155 Internet use-cases with especially IPv6: 157 o Fixed size address space: IPv4/IPv6 address space is fixed length, 158 not allowing to adopt address length to shorter or longer demands. 159 While it is possible to add more addressing via extension headers, 160 there is no option to not send, or shorten the IPv4/IPv6 base 161 header addresses, when they are not required. While the reasons 162 for fixed size addressing in IPv4/IPv6 can be understood for the 163 feasible high-speed, low-cost forwarders of the 1900th, when IPv6 164 was conceived, these reasons are today (in the opinion of the 165 author) as obsolete as ATM cells where by the end of the 1990th 166 when both hardware forwarding and mathematical models allowed to 167 provide all ATM type QoS with variable sized packets. 169 o The Internet as the primary, if not only use-case driving the 170 design: The address space semantics provided especially by IPv6 is 171 very much focused on the one use-case that drove the development 172 of IPv6: The Internet. While it was and will continue to be th 173 core and sufficient reason for maintaining IPv6, it is not 174 sufficient in the opinion of the author for the much broader use 175 of IPv6. As of today, a likely overwhelming number of hosts using 176 TCP/IP(v6) protocol stacks are not "on the Internet" and the 177 majority likely is not even "connected to the Internet", but 178 instead, they are part of limited domains. This even includes 179 many routers in large service providers that are used to service 180 Internet traffic. Routers in these networks are only in networks 181 that may be called an "underlay" limited domain networks using 182 MPLS, SR-MPLS or SRv6 and Internet traffic is tunneled across 183 them. When the network design is secure, those routers are 184 neither "on" the internet nor "connect to" the Internet. 186 o Transparent end-to-end addressing at the core of the IP/IPv6 187 protocol design, but an ever more diverse reality breaking that 188 design for good reasons: The current core principle of IPv4 and 189 IP6 is that forwarders have to be passing network layer (IPv4/ 190 IPv6) addresses transparently and are not allowed to touch/ 191 modifying them. This is the core behavior to support primarily 192 the Internet use case. Yet, the IPv4 Internet today would not 193 work without NAT, and arguably, the same may also happen to the 194 IPv6 Internet, especially when networks attaching to inexpensive 195 Internet offerings want to avoid complex src/dst forwarding for 196 IPv6 multihoming, and/or avoid renumbering upon change of provider 197 addresses. Even more so, interconnecting IPv4 and IPv6 networks 198 has resulted in no fewer than 24 IPv4/IPv6 NAT solutions (see 199 https://en.wikipedia.org/wiki/IPv6_transition_mechanism), giving 200 rise to the question if and how on-path processing of addressing 201 can be proactively become part of future addressing designs to 202 support more flexible internetworking - translating the best of 203 past NAT experience into better future designs. This is a core 204 option of what FA-IINAS can do. 206 2.2. Internetworking limited domain networks with IP addressing 208 One of the core challenges of the existing IP(v4) and IPv6 addressing 209 model are the addressing they provide for private networks with or 210 without connectivity to the Internet, which are also called limited 211 domain networks [RFC8799]. 213 One reference example is that of networking inside a particular 214 product/solution/installation, and then compositing this product with 215 other products, probably even multiple times, hierarchical, as show 216 in picture Figure 1. These type of designs are traditional in 217 industrial networks. Similar issues and solutions can be found in 218 networks with multiple layers of NAT such as Home Networks that are 219 dorm rooms connected via NAT to a dorm network, connected via another 220 NAT to a campus network, connected via yet another NAT to maybe 221 finally, the Internet. Similarly designs can happen with more 222 complex topologies in federated private networks. 224 In pre-IP industrial networks, individual products were hiding their 225 interior elements by some (combination) of elements that controlled 226 the interior behavior completely and provided only an abstracted view 227 of the machinery to the outside. 229 With the introduction of IP networking into these type of solutions, 230 the ability for gateways to become IP routers and providing 231 connectivity into the machinery throughout the larger internetwork 232 opened up many important improvements, but of course also challenges, 233 especially for security. 235 Benefits of network layer internetwork connectivity includes options 236 such as control loops that can more easily be built across multiple 237 components/levels of the hierarchy and controllers that can be pulled 238 out of machinery and positioned elsewhere in the network, enabling 239 virtualization and resource multiplexing. Multiple independently 240 running control systems can be implemented in parallel, including 241 solutions like device vendor preventive maintenance telemetry, 242 operator managed firmware update or third-party orchestrated security 243 audits or intrusion detection/prevention, just to name a few. 245 With IP connectivity, all this can be built without the need of 246 understanding how to get through various layers of fixed- 247 functionality higher-than-network layer gateways that can not be 248 extended by third parties. Instead, new designs are based on end-to- 249 end IP connectivity - plus appropriate set of security mesures at 250 gateway routers, of course an appropriate set of security/filtering 251 measures, for example MUD, [RFC8520]. 253 +-------------------------------------------------------------------+ 254 | Controller / Gateway->Router | 255 | ... | | 256 | --+-----+----------++..++---+---- | 257 | | | | 258 |+---------------------------------+----------------+ +---+-----+| 259 || | | .. | System 5|| 260 || Controller / Gateway->Router | +---------+| 261 || | | | 262 || -----+---------------+-+..+----+----- | | 263 || | | | | 264 ||+----------------+--------------+ +-----+-----+| | 265 ||| | | .. | Machine 6 || | 266 ||| Gateway->Router | +-----------+| | 267 ||| controller | | | 268 ||| | | | | 269 ||| --+--------+---+--+------+--- | | | 270 ||| | | | | | | | 271 ||| actor1 sensor1 actor2 sensor2 | | | 272 ||| | | | 273 ||| Machine 1 | | | 274 ||+-------------------------------+ | | 275 || System1 | | 276 |+--------------------------------------------------+ | 277 | Installation 1 | 278 +-------------------------------------------------------------------+ 280 Figure 1: Example hierarchical composed internetwork 282 In the opinion of the author, the most easily adopted addressing 283 architecture in these type of solutions today is also the one widely 284 used: IPv4 with [RFC1918] addresses. These addresses are actually 285 owned permanently for each deployment case - as long as the scope of 286 addressing is well defined. 288 In result, a common scheme of addressing in machinery such as the one 289 shown in Figure 1 is to reuse the same 10.0.0.0/8 or 192.168.0.0/16 290 addresses for every instance of a product/machinery manufactured. In 291 the example, actor1 could use 10.0.0.1, sensor1 10.0.0.2 and so on. 292 But equally, if Machine 3 was the same or similar, its internal 293 components would share the same machinery. And when hundreds of 294 these products are produced, hey would all have the same addresses. 296 To allow deployment and composing those type of machineries, the 297 router/switch connecting to the outside/next-level in a hierarchy 298 will need simple NATing function for example statically mapping the 299 10.0.0.x on the inside to 10.0.1.x on the outside for Machine 1, 300 where the same router/switch for Machine 3 would be configured to NAT 301 from 10.0.0.x to 10.0.3.x. And likewise at the next layer of 302 hierarchy, 10.0.y.x could be mapped to 10.z.y.x with a different y 303 for every instance. 305 In support of solutions like this, many if not most industrial 306 ethernet switches deployable as machinery gateways do therefore 307 support this type of static NAT mappings. Likewise, common practices 308 in industries rely on this addressing with composition via NAT 309 approaches, including machineries as large as production lines or in 310 transportation networks train cars and all their included 311 machineries/equipment. 313 The desire to avoid NAT in IPv6 and availability of sufficient 314 addressing space lead to replacing the concept of [RFC1918] in IPv4 315 with the concept of Unique Local Addresses (ULA) in IPv6, 316 standardized in [RFC4193]. Instead of the few scoped prefixes of 317 [RFC1918], ULA provide for 2^40 different prefixes, and the design 318 guidelines are theoretically simple: pick a random prefix and then 319 you can interconnect your networks later on with a very low 320 probability of address prefix collision/reuse. 322 Unfortunately, low probabilities of address collision is not a good 323 design principle for most of these type of environments because there 324 is really no good operational solution what do if such collision 325 occurs, and rare errors are also very hard to build resilient 326 solutions for. Also the probabilities begin to become much higher 327 when not looking at a connection of just two or few of such ULA 328 networks, but when there can be thousands of such networks, such as 329 in the transportation networks use case. 331 In result, ULA is not very persuasive for many such deployments, 332 especially when the alternative with IPv4 is address prefix mapping 333 as required for NAT, when NAT an an almost free provisioning side 334 effect of setting up the required connectivity via permit lists via 335 network/transport filters. The need to automate such in-network 336 filtering to secure such deployments can also be seen in the advent 337 of MUD, [RFC8520]. 339 If one considers that most of these subnet networks will have fewer 340 than 253 hosts connected to it, then the IPv6 ULA solution does also 341 not provide for any more bits for subnets than the 16 bits of z.y in 342 the above example using IPv4 10.z.y.x with x being the host part: The 343 lower 64 bits of the IPv6 address is hard to use for anything than 344 the host parts with non-router hosts. The whole ULA prefix is 48 345 bits, leaving just 16 bit (128 - 64 -48). Add to that the non 346 insignificant IPv6 packet header overhead plus fewer availability of 347 NAT in IPv6 products because it is assumed to be less required, plus 348 the insufficiency of "low likelihood of collisions" when attempting 349 to utilize only ULA. 351 Vendors of equipment that have assigned Provider Independent IPv6 352 address space could of course allocate addressing from that space for 353 equipment they manufacture or integrate, whether it is globally 354 unique or "generic", e.g.: reused across every instance of a product 355 and hence requiring NAT. Unfortunately, and unlike ethernet, where 356 one actually does own addresses after buying an OUI, assigned IPv6 357 addressing is not permanent, and even though revocation of address 358 allocation is not standard practice, standardized solutions for 359 global IPv6 address space (like IPv4 global address space) really 360 need to allow the ability for those addresses to be returnable 361 instead of being handed off in products to customers. 363 Even though in hindsight, the hierarchical address allocation from 364 the available 16 bits in 10.x.y.z for two layers of interconnections 365 in the above example looks obvious and simple, in many cases the 366 creation of multiple hierarchies is only an afterthought and the 367 fixed address length and prior suboptimal assignment of addressing in 368 a deployment will cause the need for a lot of re-addressing. This is 369 a recurring problem in larger enterprise/commercial networks under 370 unplanned growth or mergers & acquisitions, especially of course in 371 IPv4. Likewise, once the 16 available bits in the above described 372 NAT approach are used up, whether it is IPv4 or IPv6 with ULA, no 373 further extensions of the design are possible. 375 2.3. Shorter addresses 377 As has been noted in prior memos, shorter addresses than IPv6 128 bit 378 are highly desirable in private networks / limited domains whenever 379 it is clear that the total required addressing space is much smaller 380 and connectivity to e.g.: the Internet is not required. Evidence of 381 such requirements can be found for example in header compression for 382 IoT networks such as [RFC6282]. Such compression introduces yet 383 another layer of complexity - the whole ecosystem of devices and 384 diagnostic options has to support it to be equally acceptable as 385 uncompressed packets. 387 2.4. Additional semantics 389 New semantics can only be introduced into existing IPv4/IPv6 when 390 their required address size fits nicely into the 32 or 128 bit 391 address space. 393 This section does not aim to be complete, see 394 [I-D.king-irtf-semantic-routing-survey] for a broader survey. 395 Instead it will provide additional levels of details for the benefits 396 of fittingly sized addresses for few examples, that the author is 397 familiar with. 399 When ignorin Anycast, IP Multicast is likely the most widely adopted 400 additional semantic added to IPv4. With IPv6, IP Multicast became 401 even more flexible and easy to deploy, because the additional bits of 402 IPv6 addresses allowed to encode additional IP multicast parameters 403 through additional fields in IPv6 addresses: Scope address field 404 [RFC4291], SSM addresses [RFC4607], Unicast prefix multicast 405 addresses [RFC3306] and embedded-RP [RFC3956]. Nevertheless, 406 especially embedded-RP could have benefitted from even longer 407 addresses because with the 128 bits available the solution had to 408 take a hit in the complexity of deployment. It requires to engineer 409 that RP address such that its non-0 host port is very short (4 bits). 411 In contrast, Bit Indexed Explicit Replication (BIER) which started in 412 the IETF in 2014 and resulted in the architecture [RFC8279], did not 413 choose the option to integrate into IP/IPv6 because it desired 414 addresses sizes of at least per-network configurable from 64 to 4096 415 bit plus additional qualifiers of at least 16 bits (so-called SD, SI 416 address qualifiers). This made it necessary for BIER to (re-!)invent 417 its own network layer packet header, [RFC8296] which duplicates 418 pretty much all packet header fields of MPLS plus IP packets plus 419 additional BIER header fields, so that it can be used in both MPLS 420 and non-MPLS networks. 422 Similar arguments about the limited size of IPv6 address could likely 423 be made for ICN/CCN networks because the semantic of their addresses 424 is that of data items such as time slices of specific spatial and 425 temporal resolutions of some media such as an audio/video recording - 426 and those name spaces would ideally have addresses as long as URLs. 428 2.5. Programmability 430 Segment Routing via IPv6 (SRv6) introduced with [RFC8986] and 431 [RFC8754] (SRH) and architecture in which source routing with an IPv6 432 extension header is combined with encoding of additional processing 433 semantics into the destination and source routing hops IPv6 434 addresses. SRv6 calls this programmability. 436 SRv6 is a very flexible and theoretically extensible concept but 437 challenged by the fixed address length design of IPv6. For most 438 steering hop addresses, the bits reserved for this additional packet 439 processing are not required, but when they are required there may 440 even be too few bits available. Variable length addresses allowing 441 for variable long programming field in the address would in the 442 opinion of the author be highly beneficial. 444 One evidence for the programmability bits seen as wasteful in many 445 cases is a variety of currently proposed drafts to provide more 446 compressed source routing options for SRv6 (as of mid 2021). 448 3. FA-IINAS: Functional Addressing (FA) for Internetworking with 449 Independent Network Address Spaces (IINAS) 451 This section outlines an addressing design that attempts to solve the 452 above described challenges and calls it tentatively FA-IINAS. 453 Functional Addressing refers to the design aspect that addresses in 454 this design can be interpreted as functions with parameters. 456 Notwithstanding other granularities or options, this document assumes 457 that addresses are textually represented in hexadecimal and that the 458 minimum structure element of an address is 4 bit so that the 459 different structural elements of an address can simply be shown as 460 concatenation of hex digits. The "." character is inserted 461 optionally to show where in an address one semantic part ends and 462 another starts. 464 Like in IPv6 IoT networks, such as those using RPL ([RFC6550]) as 465 their routing protocol, this memo starts by assuming all nodes are 466 routers and that addresses are predominantly node addresses as 467 opposed to IP/IPv6, which defines unicast addresses to be interface 468 addresses. This is but an academic differentiation, because node 469 addresses can also be represented as interface addresses of so-called 470 "loopback" interfaces. 472 A network in this design is an independent address space, not shared 473 with other networks. A nework has theoretically unlimited long 474 addresses whose prefixes are mapped onto the nodes of the network, 475 which are expected to form a graph of transitively connected nodes. 477 Practical limits to address length are subject to acceptable 478 packetization. 480 3.1. Addressing for unicast 482 Each node is assigned one or more node prefixes from the networks 483 address space and none of these node prefixes can be overlapping. In 484 other words, no assigned nodeprefix can be a prefix of another 485 assigned nodeprefix. This rule ensures that every node "owns" any 486 address equal or longer to its assigned nodeprefix. Allocation of 487 node prefixes is currently out of scope for this memo but could rely 488 on any well-known methods including manual operator assigned, SDN 489 controll managed, or as initially described in this document assigned 490 by manufacturer/vendor. 492 Routing in a network is assumed to enable forwarding across the graph 493 of the network to the node owning the nodeprefix of the address. 495 Given variable long addresses, the first observation of this 496 addressing scheme is that it allows to combine short addresses with 497 extensibility. 499 In a simple example the first 200 nodes are assigned addresses 01 ... 500 c8, at which point in time the network operator gets worried about 501 growth exceeding the 256 mark and starts to assign longer addresses: 502 c90 ... f000, at which point in time ever increasing success might 503 cause assignment of even longer prefixes. 505 Addresses longer than the assigned "nodeprefix" are used to 506 instantiate a specific function on the node itself. A generic 507 representation of an address could be 508 nodeprefix.function.{parameter}. 510 3.2. Forwarding 512 3.2.1. Dispose Function 514 When using a single digit function field, function = 0 could for 515 example be "dispose" to decapsulate the packets payload and deliver 516 it to the host stack. Parameter could for example be the next- 517 protocol value, eliminating the need to have a separate packet header 518 field for this parameter. 520 While not being the same crucial issue as for the node prefixes 521 themselves, putting the next-protocol into the address makes it 522 extensible too, so one would not run out of a 256 space as IPv4/IPv6 523 might do at some point. 525 3.2.2. Steering Function 527 Command = 1 could be a "steer" command and the parameter is another 528 address. To act on the command, the node would strip the nodeprefix 529 and command part of the address and forward it based on the address 530 parameter. For example node 73 (e.g.: node with nodeprefix 73) 531 receives a packet with destination address 73.1.55.1.33.0. It 532 forwards the same packet with the stripped destination address 533 55.1.33.0 to node 55, which likewise forwards the packet with 534 stripped destination address 33.0 to node 33, which ultimately 535 receives it. 537 3.2.3. Multiple semantics 539 To introduce additional semantics into a network, such as for example 540 multicasting, we need to generalize how to interpret the first part 541 of the address, which so far was only interpreted to be a nodeprefix 542 for unicast forwarding. 544 address = prefix{.nodefunction{.nodefunction-parameters}} 545 prefix = semantic{.semantic-parameters} 547 semantic / = unicast-forward 549 unicast-forward = <set of prefixes> 550 unicast-forward-parameters = node-prefix 552 semantic /= multicast-forward 553 multicast-forward = <set of prefixes> 554 multicast-forward-parameters = multicast-group 556 Figure 2 558 In other words, the prefix at the start of the address is composed of 559 a semantic and its parameter, and the case discussed so far is simply 560 the unicast-forward semantic followed by a node-prefix parameter. 562 Again, semantic can be an arbitrarily long or short prefix, but no 563 semantic can be a prefix of another semantic. 565 In a practical example, this scheme is easily applied to existing 566 IPv4 / IPv6 address spaces. For IPv4: 568 unicast-forward = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D 569 multicast-forward = E 571 Figure 3 573 In other words, because IP multicast uses addresses 224.0.0.0/4, its 574 non-overlapping semantic prefix is E, and IPv4 unicast addresses use 575 the non-overlapping prefixes 0...D. Assume further that a node in 576 the network had assigned prefix 10.0.0.0/24, then this would 577 translate in our scheme into: 579 0.A0000.XX 581 Figure 4 583 When a node processes this address, the 4-bit prefix 0 indicates that 584 the following prefix has to be looked up in unicast forwarding. This 585 prefix is A0000. Once the packet is delivered to the node, he 586 remaining 8 bit XX can accordingly be interpreted by the node as a 587 nodefunction with parameters. 589 Likewise, an address 239.1.2.3 would translate into E.F010203, so the 590 first 4-bit E value would indicate that multicast forwarding needs to 591 be applied to the rest of the address, and with IP Multicast 592 forwarding not having further structure (ignoring willfully for 593 simplicity of the example that it does, for example with SSM), all 594 the remainder of the IPv4 address is the multicast-group 596 In summary, the logic does really only generalize what routers today 597 already do when they do prefix lookups, except for the following core 598 differences: 600 o In IPv4/IPv6, the address semantic is hard-coded by IETF 601 standards. In FA-IINAS they are definable by every network. 603 o In IPv4/IPv6, there is no notion of nodefunction{.nodefunction- 604 parameters}, only SRv6 has this concept. 606 In actual IPv4/IPv6 hardware forwarding lookups, one would not do one 607 lookup for the semantic, followed by another lookup for the semantic- 608 parameters for the case of unicast-forward, instead this would be 609 flattened. The same type of flattening would of course be useable in 610 FA-IINAS. Whether or how flattening or other optimizations are 611 feasible for other semantics such as multicast is of course highly 612 semantic and node implementation specific. 614 3.2.4. Internetworking Function 615 ................................ 616 . Network1 . 617 . R1 . 618 . R2 21 R3 . 619 . 23 23 . 620 . R4 R5 . 621 . 24 25 . 622 . ||2.2 2.2//\\2.3 . 623 .....||............//..\\....... 624 || // \\ 625 .....||..........//. ...\\........ 626 . ||2.1 2.1// . .2.2\\2.1 . 627 . R4 R5==========R5 . 628 . 14 15 . . 15 . 629 . R6 R7 . . R10 . 630 . 26 27 . . 21 . 631 . . . . 632 . Network2 . . Network3 . 633 . . . . 634 . R9 . . R8 . 635 . 21 . . 23 . 636 . 2.4|| . . 2.4//\\2.5 . 637 .....||....... .....//..\\....... 638 || // \\ 639 || // \\ 640 .....||............//. ......\\.... 641 . ||2.1 2.3// . . 2.3\\ . 642 . R11 R8============R8 . 643 . 11 12 2.5. . 2.4 11 . 644 . R12 . . . 645 . 12 . . R13 . 646 . . . 13 . 647 . . . . 648 . Network4 . . Network5 . 649 ...................... ............ 651 Figure 5: Internetworking example 653 Figure 5 shows an example internetworking topology of 5 networks, 654 each with its own independent address space. Globally unique Rxx 655 numbers are used to refer to routers. 657 An edge node is a router that has prefixes from two or more networks 658 into which it connects. In the example, R4 connects into Network1 659 with prefix 24 and into Network2 with Prefix 14. Likewise, R8 660 connects into Network3 with prefix 23, into Network4 with prefix 12 661 and into Network5 with prefix 11. An edge node can be a router 662 simply with different interfaces into different networks, or it can 663 be decomposed into multiple devices, each in a separate network. In 664 this section we describe behavior as if it was a single device. 666 For an edge node to pass a network into a separate network, the 667 internetworking function on the node has to be called. In the 668 example, this function is codepoint 2 on all edge nodes, and the 669 first parameter is an identifier of local relevance for the network 670 into which to pass the packet. In actual deployment, this function 671 number can of course be locally significant to the Network and/or 672 even each edge router, assuming appropriate control plane to assign 673 the number to this function. 675 Assume R12 (12) in Network4 wants to send a packet to R1 (21) in 676 Network1. To send it R12->R8->R5->R1, R12 would have to use a 677 destination address of 12.2.3.15.2.1.21.0, or numerically without 678 separators 0x12231521210. 680 12 will route the packet in Network4 towards R8 because of the 681 destination address 12/8 prefix. .2 indicates to R8 that it should 682 invoke the interworking function and pass the packet into Network 3. 683 As part of the interworking function, R8 then strips all the address 684 prefix it has processed so far from the destination address, leaving 685 15.2.1.21.0. R8 then forwards the packet with this destination 686 address into Network 3, where it will be received by R5, which again 687 invokes the interworking function due to .2, forwarding the packet 688 into Network1, stripping 15.2.1.0 from the destination address and 689 forwarding the packet with destination address 21.0 into Network1, 690 where it will finally be received by R1 which passes the packet to 691 its host stack because of dispose function 0. 693 To (optionally) allow for a return path, each edge node could equally 694 but inversely process the source address: When R12 sends the packet, 695 it would indicate a source address of 12.0. When R8 passes the 696 packet via its interworking function into Network3, it would prepend 697 its return path interworking function address, making the source 698 address 23.2.4.12.0, where 23 is R8 address prefix in Network3 and 699 2.4 internetworking function to return the packet into Network4. 700 Likewise, when R5 processes the packet by its interworking function, 701 it would prepend its return path address element to the source 702 address, before sending the packet into Network1, making the source 703 address 25.2.3.23.2.4.12.0. This is then the address to which R1 704 could send return packets, and likewise, on its way towards R1, the 705 address, for example when travelling via Network3 always has a 706 returnable source address. 708 With this behavior of the interworking function, it is obvious, that 709 address management of networks would want to keep a sufficiently 710 large number of very short prefixes, such as those in this example or 711 even shorter to address the interworking function in a sufficiently 712 larger number of edge routers so that a complete internetwork path 713 address will not become too long to exceed the maximum address 714 lengths. 716 3.3. Control Plane 718 This section reviews a range of control plane considerations 719 necessary to build a working solution out of the functional 720 addressing. In short, what is required for functions to be flexibly 721 configurable and extensible in the network, it requires a control 722 plane that in its principles is very much based on what was learned 723 in MPLS. 725 3.3.1. Unicast routing 727 FA-IINAS expects a control plane that supports routing for unicast- 728 forward parameters (address prefixes) in the same way as it is done 729 today for IPv4/IP6. Except that it would be for address prefixes 730 (multicast-forward-parameter) of different length and not limited to 731 just 32/128 bits as in IPv4/IPv6. 733 In addition, FA-IINAS needs control-plane functions that allow 734 defining the semantics and their prefixes, like the above example of 735 0...D for IPv4 style unicast-forwarding semantic and D for IPv4 style 736 multicast-forwarding semantic. 738 One of the core challenges for this control plane function is that 739 inconsistency between nodes can have significant different negative 740 impacts than the today accepted "eventual consistency" in IPv4/IPv6 741 unicast routing that is achieved by the most widely deployed unicast 742 forwarding control planes: distributed routing protocols (IGP/BGP). 744 The degree of concerns will highly depend on the actual new issues 745 that could happen in the face of inconsistencies, and this can only 746 be vetted with a given set of semantics. 748 In a most simple example, semantics may simple be configurable via a 749 management plane, and such an approach can be pre-staged, pre- 750 configured, validated network devices, such as in industrial or 751 embedded environments. 753 In the case of a most flexible, agile type of network, control plane 754 mechanisms would have to be extended to support strong consistency 755 models, for example through node-to-node security associations 756 coupled with a strong consistency network-wide-core-config mechanism. 757 Such mechanisms could in the opinion of the author easily be built on 758 the framework provided by [RFC8994] which provides these hop-by-hop 759 security associations and inband control plane infrastructure, 760 coupled with [RFC8990] as the protocol to negotiate the configuration 761 with strong consistency. 763 3.3.2. Naming 765 3.3.2.1. Intra network naming 767 In FA-IINAS, nodes are acting as routers, and the addresses described 768 are assigned to them persistently. This eliminates in many cases, 769 especially when the network is primarily for m2m communications the 770 need for DNS names, because effectively the address of a node is its 771 persistent name. 773 In networks small enough, e.g.: maybe <= 20,000 nodes, the very same 774 argument can also apply to nodes that are hosts, e.g. without the 775 need to support full routing/FA-IINAS operations, but still having a 776 persistent address assigned that is routed in the networks routing 777 protocol. 779 If indeed there is a need to use DNS or other naming schemes, then 780 this is no different than applying naming with DNS to today's 781 [RFC1918] addresses. 783 3.3.2.2. Simple inter network naming 785 The need to support (DNS) names is equally lower in interconnected 786 FA-IINAS networks assuming the intra network naming arguments 787 outlined before apply to the interconnected networks. 789 Because an address in a different FA-IINAS network is dependent on 790 the path from/to its corresponding peer, it is of course not 791 sufficient to simply have a global internetwork name to address 792 mapping. 794 One of the likely oldest solutions is to align name resolution with 795 packet forwarding so that the very same edge nodes between two 796 networks that do translate addresses can accordingly also translate 797 their name resolution. This was productized and fairly widely 798 deployed as early as the late 1990th for IPv4 with rfc1918 addresses, 799 see for example [CiscoNAT]. 801 This type of solutions relies on well-known routing policies such as 802 simple hierarchical routing though and are not generic for arbitrary 803 topologies. 805 3.3.3. Routing 807 3.3.3.1. With internetwork topology knowledge 809 When FA-IINAS networks are connected in an arbitrary topology instead 810 of a simple hierarchy, the fundamental problem is that of 811 constructing the address of a target peer as a path through a set of 812 appropriate network edge nodes in the address, followed by the nodes 813 address within its network. 815 In many interconnected FA-IINAS networks, one can assume to have 816 systems that can do this, such as in an industrial setting where a 817 global view of the topology of networks exists and a PCE/SDN- 818 controller will choose the path and can accordingly calculate also 819 the addresses from the path. 821 3.3.3.2. With internetwork naming knowledge 823 A decentralized solution can be built by relying on a combination of 824 naming and internetwork routing. 826 Every network (name space) is assigned a globally unique identifier. 827 This identifier is only used in the control-plane, so it should be 828 reasonably easy to have a set of construction mechanisms allowing 829 everyone to easily create its own namespace, such as for example from 830 some owned location (street address) and/or other owned names/ 831 identifier. 833 When a global naming system like DNS then exists, an FA-IINAS address 834 is the combination of FA-IINAS network identifier and address within 835 that network. 837 Across the interconnected FA-IINAS networks, the edge-routers would 838 operate extended versions of a protocol like BGP through which any 839 party can calculate desired paths. The extensions would include the 840 FA-IINAS network identifiers and address prefix mapping rules of the 841 edge-nodes, thereby allowing to also calculate addresses from FA- 842 IINAS network identifiers and address. 844 When large number of small networks (such as users homes) connect to 845 larger networks (such as an ISP), those ISP would be concerned of 846 having to propagate millions of small FA-IINAS network mappings into 847 BGP. This is not done today with IPv4/IPv6, and it would not scale 848 any better with FA-IINAS. Instead, the fact that the home network 849 would be reachable with one or more ISP could be done by also 850 creating naming system mappings from the home networks identifier to 851 the identifier and address prefix mappings of the ISP to which the 852 home network is connected. 854 When a peer looks up a name and retrieves an FA-IINAS address but 855 cannot find the FA-IINAS network identifier in its internetwork 856 routing information, it can instead resolve it to the "next higher 857 up" ISP FA-IINAS network-identifier/prefix - and recurse this until 858 it has routing information. 860 Likewise, when a peer does not have any routing information (because 861 it does not participate in internet routing information), it has to 862 forward the appropriate resolution request hierarchically upward. 864 In summary, it would be architecturally "easy" to extend DNS and BGP 865 with the necessary extensions to resolve names to FA-IINAS addresses 866 and construct relative FA-IINAS addresses from this information. 868 3.3.4. Routing policies 870 Note that this "easy" part does not include the possible desire to be 871 more or less flexible in path selection. Whereas today, packets, 872 once they enter "the Internet" are not under steering control of the 873 sender but under "hop by hop hot-potato steering" control of the ISP, 874 with FA-IINAS this may be different - or the same. If a sender then 875 constructed an FA-IINAS address implying an internetwork path that 876 was not desirable for this traffic by the indicated transit networks, 877 this would cause an error. Therefore, the above outlined procedures 878 hinted at relying on the internetwork routing information whenever 879 available and only resort to using naming system to fill in the 880 additional (edge) information. 882 Today it is becoming more common to use alternative than "native 883 Internet" paths by steering traffic across virtual/container routers 884 in cloud DC, many of which have ample and underutilized international 885 connectivity. However, additional charges for compute and forwarding 886 will apply. These type of high-overhead solutions could be replaced 887 by FA-IINAS to steer traffic across such additional networks and 888 without the need to instantiate VM/containers. It would require 889 appropriate and lightweight identity and accounting forwarding plane 890 packet header information so that those additional charges could be 891 applied. 893 3.4. Hardware considerations 895 3.4.1. Forwarding plane simplicity 897 Forwarding of FA-IINAS packets based on destination address is the 898 same type of prefix lookup on the destination address as it is today 899 in IPv4/IPv6, except that the maximum lookup prefix can be shorter or 900 longer, this is detailed in the next section. 902 The steering function should have a lookup complexity whose 903 complexity is in the order of SR-MPLS or even simpler. It can 904 constitute of a prefix lookup in the same forwarding table as non- 905 steered forwarding, but the adjacency would then have to strip the 906 looked up prefix from the destination address (comparable to MPLS 907 label pop) and forward the packet again based on the remainder of the 908 destination address - unless additional on-node service functions 909 have to be invoked. 911 The interworking function is very much like the steering function, 912 but it also prepends a return prefix to the source address field, 913 making it the most expensive forwarding plane operation. 915 In general, the author assumes that packet processing that strips a 916 prefix from the destination address and optionally adds a prefix to 917 the source address is well feasible in next generation, highest- 918 speed, lowest-cost forwarding engines. 920 Optimizations beyond this are possible but would break the 921 independent address allocation across networks. For example, if it 922 is possible for an edge node to have the same prefix length across 923 the networks it connects to, and source address follows destination 924 address in the packet encoding, then stripping the destination 925 address could be achieved by shifting the destination address in a 926 contiguous packet buffer, making head for the source address prefix 927 to be prepended to the following source address field. 929 3.4.2. Optimizing for smaller networks 931 One of the benefits of FI-IINAS is that it allows to adopt the 932 address space size based on the requirements of networks and 933 therefore also allows to optimize hardware known to be built/sold 934 only into limited size networks, such as many industrial and almost 935 all embedded networks. 937 For example, low-cost, high-speed hardware forwarding might be 938 possible to design less expensive with just 16 bit lookups instead of 939 for up to 128 bit lookups, as may be required for IPv6. Equipment 940 could be sold with that profile parameters "for networks with up to 941 2^16 nodes". 943 Because of the way FA-IINAS is designed, a limit to 2^16 nodes does 944 not mean that FA-IINAS addresses are only 16 bits. Instead they can 945 still be "arbitrary" long (where arbitrary is subject to a discussion 946 point further below in this section). Just the length of the 947 unicast-forward part of the address is limited to 16 bits. 949 3.4.3. Maximum address sizes 951 The permissible maximum size of source and destination address are 952 primarily subject to the header size that inexpensive hardware 953 forwarding can examine and modify. For future generations, this 954 might likely be as much as 512 bytes, so to optimize hardware lookup 955 it might be interesting to consider the option of carrying the 956 addresses not consecutively, but carry them as 958 3.5. Example packet header encoding 960 The following encodings propose a couple of ideas that could be 961 interesting in addressing. 963 0 1 2 3 964 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 |Version|VE |ECN| DestAddrLen | SrcAddrLen | Hop Limit | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Destination Address ... 969 | 970 +-+-+-+-+-+-+-+-+ 971 | Source Address ... | 972 | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Figure 6: Example packet header encoding 977 Version: A version number for this packet header from the same 978 registry as the IPv4/IPv6 version number field. 980 VE: Version Extension. 00. Reserved for future variations of the 981 header, such as new extension header formats if desired, so as to not 982 use up any more than one Version code point. 984 DestAddrLen: The length of the Destination Address field in bytes. 985 Valid values are 1...255 bytes. One byte minimum length is mandatory 986 because of the need to indicate some semantic for processing the 987 packet. 989 SrcAddrLen: The length of the Source Address field in bytes. Valid 990 values are 0...255 bytes. The Source Address field is therefore 991 optional. 993 ECN: See [RFC3168] and the documents updating it. 995 Rsv: Reserved. 997 Hop Limit: As in IPv6 999 Beside the variable length of the Source and Destination address 1000 fields and hence their length indications, the difference to the IPv6 1001 header are as follows: 1003 Only the two ECN bits are maintained from the IPv4/IPv6 Traffic Class 1004 field. This is because in the majority of networks, the other 6 bits 1005 of Traffic Class, DSCP are not being used, and where QoS 1006 differentiation would be used, often additional or different QoS 1007 parameters may be required that are not supported by IPv4/IPv6. Such 1008 a new network header would thus be a great opportunity to improve on 1009 QoS header parameters through a better QoS extension header, where it 1010 is needed (outside scope of this document), and not proliferate not 1011 ubiquitously used elements in the base header. The same reason 1012 applies to removing the Flow Label field. 1014 ECN on the other hand is very fundamental for the majority of all 1015 traffic in Internet and limited domain networks. 1017 4. Inspirations 1019 This section reviews prior addressing and networking technologies 1020 that did inspire this memo and compares it with them. 1022 4.1. E.164 1024 E.164 telephone numbers traditionally worked (and may still work) 1025 similar to this mechanisms handling of addresses by adding and 1026 removing prefixes and allowing to grow networks hierarchically. 1028 In Germany for example a town/city might have had a subscriber 1029 numbering plan starting with 3 digit numbers and expanding over time 1030 into 5 digits. 0 was excluded as the first digit of any assigned 1031 number. Let our example subscriber have number 1234 1033 When the phone systems of towns/cities where connected, dialing a 1034 different town/city would use a concatenation of the inter-city 1035 traffic discrimination code "0" followed by the dial code for the 1036 town/city, followed by the subscriber number. Let our example town 1037 dial code be 4111, the subscriber number dialed from a different city 1038 would be 04111 1234. Again, "0" was excluded as the first digit of a 1039 trunk prefix. 1041 When finally the phone systems of countries where connected, dialing 1042 a different country would use a concatenation of the international 1043 traffic discrimination code "00" followed by the country dial code, 1044 which in our example is 49 for Germany followed by the dial code for 1045 the city, followed by the subscriber number - 0049 4111 1234 for our 1046 example subscriber. Note that this number would of course only work 1047 when calling from countries that also do use "00" as the 1048 international traffic discrimination code. When calling the number 1049 from the USA, one would have to dial 011 4111 1234, because the USA 1050 uses 011 as the internal traffic discrimination code. 1052 Of course, understanding foreign countries traffic discrimination 1053 code rules to reverse engineer a foreign telephone number so as to 1054 translate it to the according rules of the calling-from country is 1055 one of the problems that is leading more and more subscribers to 1056 prefer the absolute E.164 telephone numbers like +49 4111 1234. 1058 On the other hand, when the interplanetary telephone network will 1059 "soon" [I-D.draft-farrel-soon] arrive and there are not enough 1060 country codes available in Earth's existing numbering plan, one would 1061 have to find a way to attach prefixes in front of existing E.164 1062 numbers, something that E.164 likely cannot afford, but which would 1063 be possible with UPVLA. 1065 In our example the UPVLA address could be 0003 49 4111 1234 and a new 1066 solar system "absolute" address could be ++3 49 4111 1234. 1068 Obviously, Mercury has to get 1, Venus 2 and Earth 3 and so on, so 1069 that it would be easier to remember how to dial other planets than it 1070 is now to remember how to dial other countries. 1072 If one was to use the solution proposed in this memo to build the 1073 phone network addressing system with the example numbering plan, one 1074 could set up a multi-tiered internetwork as shown in Figure 7. 1076 Soon: 1077 . . 1078 . Solar System network . 1079 . . 1080 . prefix "3" . | 1081 . ..................... . v strip 3 from dst, prepend 0 to dst 1082 ...| Planet Edge Node .... forward into global network 1083 . ..................... . ^ strip 0 from dst, prepend 3 to src 1084 . prefix "0" . | forward into solar system network 1085 . . 1086 Today: 1087 . . 1088 . "global" network . 1089 . . 1090 . prefix "49" . | 1091 . +-------------------+ . v strip 49 from dst, prepend 0 to dst 1092 ...| Country Edge Node |... forward into country network 1093 . +-------------------+ . ^ strip 0 from dst, prepend 49 to src 1094 . prefix "0" . | forward into global network 1095 . . 1096 . "country" network . 1097 . . 1098 . prefix "4111" . | 1099 . +-------------------+ . v strip 4111 from dst, prepend 0 to dst 1100 ...| City Edge Node |... forward into city network 1101 . +-------------------+ . ^ strip 0 from dst, prepend 4111 to src 1102 . prefix "0" . forward into country network 1103 . . 1104 . city network . 1105 . . 1106 . subscriber 1234 . 1107 ........................... 1109 Figure 7: Example internetwork for E.164 style address structure with 1110 FA-INAAS 1112 Packets destined to an address starting with "0" would be routed to 1113 an edge node of the city network, which "owns" the "0" prefix, there 1114 that "0" prefix is stripped, but the cities own prefix of in the 1115 example "4111" is prepended to the source address, and then the 1116 packet is forwarded into the country network. 1118 When a packet is received from the country network on a city edge 1119 node, the opposite happens, the cities own prefix, e.g.: 4111 is 1120 stripped from the destination address and 0 is prepended to the 1121 source address, then the packet is forwarded into the city network 1122 and routed to the destination. Which can generate return packets by 1123 just swapping source and destination addresses. 1125 The same process will happen across 2 network tiers when a 00 prefix 1126 is used or even 3 network tiers, once we have (soon ;-) a Solar 1127 System Network. 1129 Of course, each tier and each instance of each tier can choose its 1130 own addressing scheme and prefixes for the edge routers. It is left 1131 as an exercise to the reader for example to amend the example with 1132 its own home countries traffic discrimination codes. 1134 4.2. MPLS 1136 Adding/Removing or swapping prefixes is the core forwarding process 1137 step in Multiprotocol Label Switching [RFC3031]. Due to the time 1138 MPLS was designed, it had to have a very fixed size and functionality 1139 stack architecture, but as claimed in before, the author thinks that 1140 today an MPLS stack could easily be built just with the proposed 1141 addressing scheme address. 1143 Compared to MPLS, the proposed scheme does not mandate that that 1144 every steering address needs to contain QoS (EXP) and TTL fields as 1145 are present in MPLS Label Stack entries, but of course they would be 1146 equally possible as parameters of appropriate functions. 1148 Likewise the proposal does not think it is appropriate to require 1149 complicated scanning ahead into the address in search of Special 1150 Label Stack entries. Therefore, FA-IINAS would require that any per- 1151 hop accessible information that is not included in the hops function/ 1152 parameters would have to be carried would have to be carried in a 1153 separated extensions header. 1155 4.3. Segment Routing SR-MPLS / SRv6 1157 FA-IINAS can support more compact packet steering than SR-MPLS when 1158 the prefixes are accordingly chosen to be shorter than the 32 bits 1159 for an LSE. 1161 While it would be possible to emulate MPLS LSE by using prefixes of 1162 20 bit and following them with 12 bit of functional parameters 1163 indicating EXP and TTL, the proposal in this memo does not assume 1164 that transit routers would be able to act on those EXP or TTL bits. 1165 While it would be easily possible to define such additional transit 1166 hop semantic through extensions to the control plane, the author 1167 believes that the per-path parameters of TTL in a base header and 1168 more flexible QoS in an extension header is the more likely most 1169 useful option for these two functions. 1171 In comparison to SRv6, FA-IINAS allows of course more compact 1172 representation of steering hops and also more easily few or many per- 1173 hop bits for programmability, as desired. 1175 What FA-IINAS does not provide for is to keep the sequence of 1176 steering addresses in the header up to the final receiver. This 1177 might be useful for diagnostics, but it is seemingly not so important 1178 that it did stop the adoption of SR-MPLS, where the steering hops are 1179 likewise removed from the packet header when steering happens. 1181 Other functions than steering and per-steering hop programmability 1182 provided by SRv6 via SRH (such as its TLV for the receiver) are 1183 unaffected by this proposal and could equally be provided for by an 1184 SRH style extension header without the source routing part. 1186 4.4. Research 1188 [Haoyu] proposes a hierarchical addressing scheme and provides 1189 reviews in a lot more detail a set of other reasons for such 1190 addressing scheme. That paper does not allow for arbitrary 1191 composition of networks without a clear hierarchy or root thereof, as 1192 FA-IINAS does. 1194 5. Summary and conclusions 1196 This memo introduces a simple but hopefully very attractive 1197 addressing scheme that leverages variable length address sizes with 1198 the potential for simple address prefix processing (push/pop/swap) on 1199 steering hops, service-function hops and especially network edge 1200 nodes. 1202 Push/pop/swap of network prefixes on network edge nodes allows to 1203 introduce a non-global internetworking address architecture that 1204 should make it a lot easier to build and manage many embedded, 1205 private or otherwise limited domain internetworks and optimize 1206 forwarding engines for a variety of different of these type of 1207 networks such as through known maximum network prefix lengths. 1209 When network addresses as in FA-IINAS become effectively internetwork 1210 path addresses, they also allow for a much wider range of possible 1211 routing policies. In a time where the classical Internet with its 1212 "sender just gets one path", this can be a highly beneficial 1213 enhancement to explore (not that this was already proposed, maybe way 1214 ahead of its time and with vastly different mechanisms in solutions 1215 as early as [RFC1621], [RFC1622]). 1217 In this version of the memo, these are only limited considerations 1218 about how to refine details of the proposal to find incremental, 1219 near-term deployment options, for example by using existing IPv6 1220 headers and using an unassigned prefix to define FA-IINAS addressing 1221 semantic into it (limited of course to 128 bit then). These type of 1222 considerations can be subject for future revisions of this memo. 1224 6. Informative References 1226 [CiscoNAT] 1227 Akkiraju, P., Delgadillo, K., and Y. Rekhter, "Enabling 1228 Enterprise Multihoming with Cisco IOS Network Address 1229 Translation (NAT)", 2000, 1230 . 1232 [Haoyu] Song, H., Zhang, Z., Qu, Y., and J. Guichard, "Adaptive 1233 Addresses for Next Generation IP Protocol in Hierarchical 1234 Networks", IEEE 2020 IEEE 28th International Conference on 1235 Network Protocols (ICNP), n.d.. 1237 [I-D.draft-farrel-soon] 1238 Farrel, A., "A Definition of the Term "Soon" for Use in 1239 Discussions with Working Group Chairs and Area Directors", 1240 draft-farrel-soon-07 (work in progress), March 2021. 1242 [I-D.jia-flex-ip-address-structure] 1243 Jia, Y., Chen, Z., and S. Jiang, "Flexible IP: An 1244 Adaptable IP Address Structure", draft-jia-flex-ip- 1245 address-structure-00 (work in progress), October 2020. 1247 [I-D.jia-intarea-scenarios-problems-addressing] 1248 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., Mendes, P., 1249 3rd, D. E. E., and P. Liu, "Challenging Scenarios and 1250 Problems in Internet Addressing", draft-jia-intarea- 1251 scenarios-problems-addressing-01 (work in progress), July 1252 2021. 1254 [I-D.king-irtf-challenges-in-routing] 1255 King, D. and A. Farrel, "Challenges for the Internet 1256 Routing Infrastructure Introduced by Changes in Address 1257 Semantics", draft-king-irtf-challenges-in-routing-03 (work 1258 in progress), June 2021. 1260 [I-D.king-irtf-semantic-routing-survey] 1261 King, D. and A. Farrel, "A Survey of Semantic Internet 1262 Routing Techniques", draft-king-irtf-semantic-routing- 1263 survey-02 (work in progress), June 2021. 1265 [RFC1621] Francis, P., "Pip Near-term Architecture", RFC 1621, 1266 DOI 10.17487/RFC1621, May 1994, 1267 . 1269 [RFC1622] Francis, P., "Pip Header Processing", RFC 1622, 1270 DOI 10.17487/RFC1622, May 1994, 1271 . 1273 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1274 and E. Lear, "Address Allocation for Private Internets", 1275 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1276 . 1278 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1279 Label Switching Architecture", RFC 3031, 1280 DOI 10.17487/RFC3031, January 2001, 1281 . 1283 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1284 of Explicit Congestion Notification (ECN) to IP", 1285 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1286 . 1288 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1289 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1290 August 2002, . 1292 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1293 Point (RP) Address in an IPv6 Multicast Address", 1294 RFC 3956, DOI 10.17487/RFC3956, November 2004, 1295 . 1297 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1298 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1299 . 1301 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1302 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1303 2006, . 1305 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1306 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1307 . 1309 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1310 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1311 DOI 10.17487/RFC6282, September 2011, 1312 . 1314 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1315 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1316 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1317 Low-Power and Lossy Networks", RFC 6550, 1318 DOI 10.17487/RFC6550, March 2012, 1319 . 1321 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1322 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1323 Explicit Replication (BIER)", RFC 8279, 1324 DOI 10.17487/RFC8279, November 2017, 1325 . 1327 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1328 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1329 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1330 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1331 2018, . 1333 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1334 Description Specification", RFC 8520, 1335 DOI 10.17487/RFC8520, March 2019, 1336 . 1338 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1339 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1340 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1341 . 1343 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1344 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1345 . 1347 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1348 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1349 (SRv6) Network Programming", RFC 8986, 1350 DOI 10.17487/RFC8986, February 2021, 1351 . 1353 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 1354 Autonomic Signaling Protocol (GRASP)", RFC 8990, 1355 DOI 10.17487/RFC8990, May 2021, 1356 . 1358 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 1359 Autonomic Control Plane (ACP)", RFC 8994, 1360 DOI 10.17487/RFC8994, May 2021, 1361 . 1363 Author's Address 1365 Toerless Eckert 1366 Futurewei Technologies USA 1368 Email: tte@cs.fau.de