RFC 6115

Recommendation for a Routing Architecture

📅 published February 2011, from ietf

RFC 6115: Recommendation for a Routing Architecture ✨

Okay bestie, let's get the vitals first 💅 This is RFC 6115, called Recommendation for a Routing Architecture. It came out of the Internet Research Task Force (IRTF) and was written by T. Li, Ed. at Cisco Systems 🎀 It's dated February 2011, and its category is Informational 📄 (not a standard, just research energy). Its ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, since the title block doesn't list any 🦋

Abstract 🌸

Okay so everyone kinda agrees the Internet's routing and addressing setup is struggling with scalability, multihoming, and inter-domain traffic engineering 😭 This doc is the IETF's recommendation for future directions, with solutions that could help the Internet keep scaling ✨ It surveys a bunch of the proposals that got brought up for discussion, plus some of the follow-up analysis and the chairs' architectural recommendation. It's a product of the Routing Research Group 🧚

Status of This Memo 🎀

This isn't an Internet Standards Track spec, it's published for informational purposes only 💅 The IRTF shares results of Internet-related research and development, and those results might not be suitable for deployment 🙈 This RFC is the individual opinion of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF), so it's not a group-approved thing. Documents the IRSG approves are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🔥

Info on the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6115 💖

Copyright Notice 💜

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved ✨ This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read those carefully, bestie, because they describe your rights and restrictions with respect to this document 🫶

Part 1 of 17 is done, and more parts are coming, so stay tuned 🦋

Table of Contents 📚

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Background to This Document  . . . . . . . . . . . . . . .  5
     1.2.  Areas of Group Consensus . . . . . . . . . . . . . . . . .  6
     1.3.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Locator/ID Separation Protocol (LISP)  . . . . . . . . . . . .  8
     2.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.1.1.  Key Idea . . . . . . . . . . . . . . . . . . . . . . .  8
       2.1.2.  Gains  . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.1.3.  Costs  . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.1.4.  References . . . . . . . . . . . . . . . . . . . . . . 10
     2.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.  Routing Architecture for the Next Generation Internet
       (RANGI)  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.1.1.  Key Idea . . . . . . . . . . . . . . . . . . . . . . . 12
       3.1.2.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.1.3.  Costs  . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.1.4.  References . . . . . . . . . . . . . . . . . . . . . . 13
     3.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 16
     4.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.1.  Key Ideas  . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.2.  Extensions . . . . . . . . . . . . . . . . . . . . . . 17
         4.1.2.1.  TTR Mobility . . . . . . . . . . . . . . . . . . . 17
         4.1.2.2.  Modified Header Forwarding . . . . . . . . . . . . 18
       4.1.3.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 18
       4.1.4.  Costs  . . . . . . . . . . . . . . . . . . . . . . . . 18
       4.1.5.  References . . . . . . . . . . . . . . . . . . . . . . 19
     4.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 19
     4.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 20
   5.  Hierarchical IPv4 Framework (hIPv4)  . . . . . . . . . . . . . 21
     5.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 21

       5.1.1.  Key Idea . . . . . . . . . . . . . . . . . . . . . . . 21
       5.1.2.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 22
       5.1.3.  Costs and Issues . . . . . . . . . . . . . . . . . . . 23
       5.1.4.  References . . . . . . . . . . . . . . . . . . . . . . 23
     5.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 24
     5.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 25
   6.  Name Overlay (NOL) Service for Scalable Internet Routing . . . 25
     6.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 25
       6.1.1.  Key Idea . . . . . . . . . . . . . . . . . . . . . . . 25
       6.1.2.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 26
       6.1.3.  Costs  . . . . . . . . . . . . . . . . . . . . . . . . 27
       6.1.4.  References . . . . . . . . . . . . . . . . . . . . . . 27
     6.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 27
     6.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 28
   7.  Compact Routing in a Locator Identifier Mapping System (CRM) . 29
     7.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 29
       7.1.1.  Key Idea . . . . . . . . . . . . . . . . . . . . . . . 29
       7.1.2.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 29
       7.1.3.  Costs  . . . . . . . . . . . . . . . . . . . . . . . . 30
       7.1.4.  References . . . . . . . . . . . . . . . . . . . . . . 30
     7.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 30
     7.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 31
   8.  Layered Mapping System (LMS) . . . . . . . . . . . . . . . . . 32
     8.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 32
       8.1.1.  Key Ideas  . . . . . . . . . . . . . . . . . . . . . . 32
       8.1.2.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 32
       8.1.3.  Costs  . . . . . . . . . . . . . . . . . . . . . . . . 33
       8.1.4.  References . . . . . . . . . . . . . . . . . . . . . . 33
     8.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 33
     8.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 34
   9.  Two-Phased Mapping . . . . . . . . . . . . . . . . . . . . . . 34
     9.1.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 34
       9.1.1.  Considerations . . . . . . . . . . . . . . . . . . . . 34
       9.1.2.  Basics of a Two-Phased Mapping . . . . . . . . . . . . 35
       9.1.3.  Gains  . . . . . . . . . . . . . . . . . . . . . . . . 35
       9.1.4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . 36
       9.1.5.  References . . . . . . . . . . . . . . . . . . . . . . 36
     9.2.  Critique . . . . . . . . . . . . . . . . . . . . . . . . . 36
     9.3.  Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 36
   10. Global Locator, Local Locator, and Identifier Split
       (GLI-Split)  . . . . . . . . . . . . . . . . . . . . . . . . . 36
     10.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 36
       10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 36
       10.1.2. Gains  . . . . . . . . . . . . . . . . . . . . . . . . 37
       10.1.3. Costs  . . . . . . . . . . . . . . . . . . . . . . . . 38
       10.1.4. References . . . . . . . . . . . . . . . . . . . . . . 38
     10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 38
     10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 39

   11. Tunneled Inter-Domain Routing (TIDR) . . . . . . . . . . . . . 40
     11.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 40
       11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 40
       11.1.2. Gains  . . . . . . . . . . . . . . . . . . . . . . . . 40
       11.1.3. Costs  . . . . . . . . . . . . . . . . . . . . . . . . 41
       11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 41
     11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 41
     11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 42
   12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 42
     12.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 42
       12.1.1. Key Ideas  . . . . . . . . . . . . . . . . . . . . . . 42
       12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 43
       12.1.3. Costs  . . . . . . . . . . . . . . . . . . . . . . . . 44
       12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 45
     12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 45
     12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 46
   13. Enhanced Efficiency of Mapping Distribution Protocols in
       Map-and-Encap Schemes (EEMDP)  . . . . . . . . . . . . . . . . 48
     13.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 48
       13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 48
       13.1.2. Management of Mapping Distribution of Subprefixes
               Spread across Multiple ETRs  . . . . . . . . . . . . . 48
       13.1.3. Management of Mapping Distribution for Scenarios
               with Hierarchy of ETRs and Multihoming . . . . . . . . 49
       13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 50
     13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 50
     13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 51
   14. Evolution  . . . . . . . . . . . . . . . . . . . . . . . . . . 52
     14.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 52
       14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 52
       14.1.2. Relation to Other RRG Proposals  . . . . . . . . . . . 53
       14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 53
       14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 55
     14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 55
     14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 56
   15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 56
     15.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 56
       15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 58
     15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 58
       15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 59
       15.2.2. Edge-networks  . . . . . . . . . . . . . . . . . . . . 59
     15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 59
   16. Routing and Addressing in Networks with Global Enterprise
       Recursion (IRON-RANGER)  . . . . . . . . . . . . . . . . . . . 59
     16.1. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 59
       16.1.1. Gains  . . . . . . . . . . . . . . . . . . . . . . . . 60
       16.1.2. Costs  . . . . . . . . . . . . . . . . . . . . . . . . 61
       16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 61

     16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 61
     16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 62
   17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 63
     17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 64
     17.2. Recommendation to the IETF . . . . . . . . . . . . . . . . 65
     17.3. Rationale  . . . . . . . . . . . . . . . . . . . . . . . . 65
   18. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 66
   19. Security Considerations  . . . . . . . . . . . . . . . . . . . 66
   20. Informative References . . . . . . . . . . . . . . . . . . . . 66

1. Introduction 🌸

okay so the Internet's routing and addressing setup is literally facing some real challenges 😭 we're talking scalability, multihoming, and inter-domain traffic engineering (the big-brain stuff). the problem itself is written up in [Scalability_PS], and the design goals we've been talking about are in [RRG_Design_Goals] 🫶

this document is basically a roundup of the many proposals that got brought forward for discussion in this activity 💅 for some of them, we also dig into the analysis, like the concerns with certain proposals and how some of those concerns might be handled ✨

but here's the thing, bestie 🙈 just because a proposal shows up in this document, or gets a ton of analysis, does NOT mean the Routing Research Group (RRG) is into it or endorses it. readers are cautioned not to draw any conclusions about the group's interest or endorsement from any of that 🧚

1.1. Background to This Document ✨

okay so the RRG (Routing Research Group) was chartered to research and recommend a brand new routing architecture for the Internet 🌐 the goal was to explore LOTS of alternatives and build consensus around ONE proposal 💅 the only real rule for the group was that the process had to be open, and they'd go through the usual discussing of proposals and trying to agree on them. there was no plan for what happens if the group just... never agrees 💀

the group met at every IETF meeting from March 2007 to March 2010 and talked through a bunch of proposals, both in person and on its mailing list 🫶 unfortunately, they did not reach consensus 😭 so instead of throwing away all the good stuff and progress, the chairs (Lixia Zhang and Tony Li) decided to collect the proposals and some of the debate about them and make a recommendation from that. which means the recommendation reflects the opinions of the chairs, and not necessarily the consensus of the group 🧚

the group DID agree on a number of items that are included below ✨ the proposals were collected in an open call amongst the group. once they were collected, the group was asked to send in critiques of each proposal. the group was asked to self-organize to produce a single critique for each proposal. if several critiques came in, the editor picked one 🎀 then the proponents of each proposal got to write a rebuttal of the critique. and finally, the group had another chance to write a counterpoint to the rebuttal. nobody submitted any counterpoints 🙈 also, for pragmatic reasons, every submission was severely constrained in length.

all of the proposals were given the chance to progress their documents to RFC status, but not all of them chose to go that route 🦋 which means some of the references in this document may become inaccessible. this is unfortunately unavoidable 😔

the group did reach consensus that the overall document should be published 🎉 and the document has been reviewed by many of the active members of the Research Group 👑

1.2. Areas of Group Consensus

the group also managed to reach broad and clear consensus on some terminology and several important technical points 🌸 for the sake of posterity, these are recorded here:

A "node" is either a host or a router.
A "router" is any device that forwards packets at the network layer (e.g., IPv4, IPv6) of the Internet architecture.
A "host" is a device that can send/receive packets to/from the network, but does not forward packets.
A "bridge" is a device that forwards packets at the link layer (e.g., Ethernet) of the Internet architecture. An Ethernet switch or Ethernet hub are examples of bridges.
An "address" is an object that combines aspects of identity with topological location. IPv4 and IPv6 addresses are current examples.
A "locator" is a structured topology-dependent name that is not used for node identification and is not a path. Two related meanings are current, depending on the class of things being named:
1. The topology-dependent name of a node's interface.
2. The topology-dependent name of a single subnetwork OR topology-dependent name of a group of related subnetworks that share a single aggregate. An IP routing prefix is a current example of the latter.
An "identifier" is a topology-independent name for a logical node. Depending upon instantiation, a "logical node" might be a single physical device, a cluster of devices acting as a single node, or a single virtual partition of a single physical device. An OSI End System Identifier (ESID) is an example of an identifier. A Fully Qualified Domain Name (FQDN) that precisely names one logical node is another example. (Note well that not all FQDNs meet this definition.)
Various other names (i.e., other than addresses, locators, or identifiers), each of which has the sole purpose of identifying a component of a logical system or physical device, might exist at various protocol layers in the Internet architecture.
The Research Group has rough consensus that separating identity from location is desirable and technically feasible. However, the Research Group does NOT have consensus on the best engineering approach to such an identity/location split. 🤔
The Research Group has consensus that the Internet needs to support multihoming in a manner that scales well and does not have prohibitive costs. 📈
Any IETF solution to Internet scaling has to not only support multihoming, but address the real-world constraints of the end customers (large and small). 💖

1.3. Abbreviations

this section lists some of the most common abbreviations used in the rest of this document 📚

DFZ    Default-Free Zone

EID    Endpoint IDentifier or Endpoint Interface iDentifier: The
       precise definition varies depending on the proposal.

ETR    Egress Tunnel Router: In a system that tunnels traffic across
       the existing infrastructure by encapsulating it, the device
       close to the actual ultimate destination that decapsulates the
       traffic before forwarding it to the ultimate destination.

FIB    Forwarding Information Base: The forwarding table, used in the

       data plane of routers to select the next hop for each packet.

ITR    Ingress Tunnel Router: In a system that tunnels traffic across
       the existing infrastructure by encapsulating it, the device
       close to the actual original source that encapsulates the
       traffic before using the tunnel to send it to the appropriate
       ETR.

PA     Provider-Aggregatable: Address space that can be aggregated as
       part of a service provider's routing advertisements.

PI     Provider-Independent: Address space assigned by an Internet
       registry independent of any service provider.

PMTUD  Path Maximum Transmission Unit Discovery: The process or
       mechanism that determines the largest packet that can be sent
       between a given source and destination without being either i)
       fragmented (IPv4 only), or ii) discarded (if not fragmentable)
       because it is too large to be sent down one link in the path
       from the source to the destination.

RIB    Routing Information Base.  The routing table, used in the
       control plane of routers to exchange routing information and
       construct the FIB.

RIR    Regional Internet Registry.

RLOC   Routing LOCator: The precise definition varies depending on
       the proposal.

xTR    Tunnel Router: In some systems, the term used to describe a
       device which can function as both an ITR and an ETR.

2. Locator/ID Separation Protocol (LISP) 🧚‍♀️

2.1. Summary

2.1.1. Key Idea

okay this is the core vibe 🦋 it implements a locator/identifier separation mechanism using encapsulation between routers at the "edge" of the Internet. and that separation is what lets you aggregate the routable addresses (locators) while still giving end systems stable, portable numbering (identifiers). it's giving clean architecture 💅

2.1.2. Gains

the perks are literally iconic ✨

topological aggregation of locator space (RLOCs) used for routing, which greatly reduces both the overall size and the "churn rate" of the information needed to operate the Internet global routing system
separate identifier space (EIDs) for end systems, effectively allowing "PI for all" (no renumbering cost for connectivity changes) without adding state to the global routing system
improved traffic engineering capabilities that explicitly do not add state to the global routing system and whose deployment will allow active removal of the more-specific state that is currently used
no changes required to end systems
no changes to Internet "core" routers
minimal and straightforward changes to "edge" routers
day-one advantages for early adopters
defined router-to-router protocol
defined database mapping system
defined deployment plan
defined interoperability/interworking mechanisms
defined scalable end-host mobility mechanisms
prototype implementation already exists and is undergoing testing
production implementations in progress

2.1.3. Costs

ngl there are a few downsides too, but we're being honest here 🫶

mapping system infrastructure (map servers, map resolvers, Alternative Logical Topology (ALT) routers). This is considered a new potential business opportunity.
interworking infrastructure (proxy ITRs). This is considered a new potential business opportunity.
overhead for determining/maintaining locator/path liveness. This is a common issue for all identifier/locator separation proposals.

2.1.4. References

[LISP] [LISP+ALT] [LISP-MS] [LISP-Interworking] [LISP-MN] [LIG]
[LOC_ID_Implications]

2.2. Critique 💅

okay so LISP+ALT spreads mapping info out to ITRs through (optional, local, maybe caching) Map Resolvers, plus globally distributed query servers: ETRs and optional Map Servers (MSes). 🗺️

bestie, the big problem with any global query server network is that the long paths and higher risk of packet loss can make ITRs drop or seriously delay the first packets of lots of new sessions 😭. ITRs drop whatever packet(s) they have no mapping for. Once the mapping shows up, the ITR waits for a re-sent packet and then tunnels it correctly. These "initial-packet delays" hurt performance, so they're a major barrier to people voluntarily adopting this on a big enough scale to fix the routing scaling problem 💀.

ALT's delays get worse because its structure is "aggressively aggregated" with zero regard for where the routers actually are 🌍. Tunnels between ALT routers will often stretch across continents and go through a bunch of Internet routers. Literally wild.

A query usually climbs many levels of the ALT hierarchy before heading back down toward its destination. That often means excessively long geographic paths, which makes the initial-packet delays even worse 🙈.

No solution has been proposed for these problems, or for the contradiction between needing high aggregation and making the ALT structure robust against single points of failure. Not me noticing a plot hole 💔.

LISP's ITRs rely on their multihoming service restoration by figuring out whether end-user networks are reachable via two or more ETRs. If a huge number of ITRs do this, it's inefficient and can overburden the ETRs 😩.

Testing ETR reachability is complex, costly, and insufficient. ITRs can't test network reachability via each ETR, because they don't have the address of a device inside each ETR's network. So ETRs have to report network unreachability to ITRs 🫠.

LISP involves complicated communication between ITRs and ETRs, with UDP and 64-bit LISP headers on all traffic packets. The vibes are chaotic 🌀.

The upside of LISP+ALT is that its ability to handle billions of EIDs isn't limited by needing to transmit or store the mapping to any one location ✨. Numbers beyond a few tens of millions of EIDs will only happen if the system is used for mobility. But the ALT structure concerns we just talked about come from the millions of ETRs that would be needed even for non-mobile networks. So it's a lot 😤.

In LISP's mobility approach, each Mobile Node (MN) needs an RLOC address to act as its own ETR, which means the MN can't be behind a NAT 🚫. Mapping changes have to be sent instantly to all relevant ITRs every time the MN gets a new address, and LISP can't pull that off 💀.

To enforce ISP filtering of incoming packets by source address, LISP ITRs would have to apply the same filtering to every decapsulated packet. That may be prohibitively expensive 💸.

LISP monolithically bakes multihoming failure detection and restoration decision-making into the Core-Edge Separation (CES) scheme itself. End-user networks have to rely on the necessarily limited capabilities built into every ITR. Iconic for nobody 🙃.

LISP+ALT may be able to solve the routing scaling problem, but alternative approaches would be superior because they eliminate the initial-packet delay problem and give end-user networks real-time control over ITR tunneling 👑.

2.3. Rebuttal 🎀

bestie, initial-packet loss and delays turn out not to be a deep issue 🙌. Any design that's actually deployable needs mechanisms for interoperating with the legacy part of the network, and LISP has them. If needed, initial packets can be sent through those legacy mechanisms until the ITR has a mapping. (Field experience has shown that the caches on those interoperation devices are guaranteed to be populated, since 'crackers' doing address-space sweeps periodically send packets to every available mapping 👀.)

As for ALT issues, it's not at all mandatory that ALT be the mapping system used in the long term 🧚. LISP has a standardized mapping system interface, partly so that whatever new mapping system(s) experience shows are required can be deployed fairly smoothly. At least one other mapping system, LISP-TREE [LISP-TREE], avoids ALT's problems (like query load concentrating at high-level nodes) and has already been laid out and extensively simulated 🌸. Exactly what mix of mapping system(s) is optimal isn't really answerable without more extensive experience, but LISP is designed to allow evolutionary changes to other mapping system(s) 🦋.

When it comes to ETR reachability, a potential problem that has a solution with an adequate level of efficiency, complexity, and robustness isn't really a problem 💅. LISP has a number of overlapping mechanisms that are believed to provide adequate reachability detection (along the three axes above), and in field testing so far, they've behaved as expected ✨.

LISP devices operating behind a NAT has already been demonstrated 🔥. A number of mechanisms to update correspondent nodes when a mapping is updated have been designed, and some are already in use 💜.

3. Routing Architecture for the Next Generation Internet (RANGI) 👑

3.1. Summary 🌈

3.1.1. Key Idea

okay so, similar to Host Identity Protocol (HIP) [RFC4423], RANGI adds a host identifier layer between the network layer and the transport layer. The transport-layer associations (i.e., TCP connections) are no longer bound to IP addresses. They're bound to host identifiers instead 🫶. The big difference from HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier with organizational structure. Because of that, the corresponding ID->locator mapping system for these identifiers gets a reasonable business model and clear trust boundaries 💼. RANGI also uses IPv4-embedded IPv6 addresses as locators. The Locator Domain Identifier (LD ID) (i.e., the leftmost 96 bits) of this locator is a provider-assigned /96 IPv6 prefix, while the last four octets are a local IPv4 address (either public or private) 🧚. This special locator could be used to realize 6over4 automatic tunneling (borrowing ideas from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]), which would cut the deployment cost of this new routing architecture 🤑. Inside RANGI, mappings from FQDN to host identifiers are stored in the DNS system, while mappings from host identifiers to locators are stored in a distributed ID/locator mapping system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a reverse DNS system) 🗂️.

3.1.2. Gains

RANGI hits almost all of the goals RRG set out, like this 🎯:

Routing Scalability: Scalability is achieved by decoupling identifiers from locators. 📈
Traffic Engineering: Hosts located in a multihomed site can suggest the upstream ISP for outbound and inbound traffic, while the first-hop Locator Domain Border Router (LDBR; i.e., site border router) has the final decision on the upstream ISP selection. 🛣️
Mobility and Multihoming: Sessions will not be interrupted due to locator change in cases of mobility or multihoming. 🏃‍♀️
Simplified Renumbering: When changing providers, the local IPv4 addresses of the site do not need to change. Hence, the internal routers within the site don't need renumbering. 🙌
Decoupling Location and Identifier: Obvious. 🙄
Routing Stability: Since the locators are topologically aggregatable and the internal topology within the LD will not be disclosed outside, routing stability could be improved greatly. 🪨
Routing Security: RANGI reuses the current routing system and does not introduce any new security risks into the routing system. 🔐
Incremental Deployability: RANGI allows an easy transition from IPv4 networks to IPv6 networks. In addition, RANGI proxy allows RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice versa. 🦋

3.1.3. Costs

The not-so-cute part 🥲:

A host change is required.
The first-hop LDBR change is required to support site-controlled traffic-engineering capability.
The ID->locator mapping system is a new infrastructure to be deployed.
RANGI proxy needs to be deployed for communication between RANGI-aware hosts and legacy hosts.

3.1.4. References

[RFC3007] [RFC4423] [RANGI] [RANGI-PROXY] [RANGI-SLIDES] 📚

3.2. Critique 🔍

okay so RANGI is an ID/locator split protocol that, like HIP, puts a cryptographically signed ID between the network layer (IPv6) and transport 🔏. Unlike the HIP ID, the RANGI ID has a hierarchical structure that lets it support ID->locator lookups. That structure fixes two weak spots of the flat HIP ID: how hard the ID->locator lookup is, and the administrative scalability of doing firewall filtering on flat IDs 🧱. The hierarchy is kind of overloaded, though. It's used to make the ID unique, to drive the lookup process, and possibly for other things like firewall filtering. More thought is needed on what counts as these levels for each of those roles 🤔.

The RANGI document [RANGI] suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup that may be DNS or something else (a hierarchy of DHTs). It would be more efficient if the FQDN lookup produced both the ID and locators, like the Identifier-Locator Network Protocol (ILNP) does 🏎️. Probably DNS alone is enough for the ID->locator lookup, since individual DNS servers can hold very large numbers of mappings 🧠.

RANGI provides strong sender identification, but at the cost of computing crypto 🥴. Lots of hosts (like public web servers) might prefer to skip the crypto and give up some functionality (receiver mobility or dynamic multihoming load balancing) 🌐. RANGI doesn't require the receiver to validate the sender, but it may be good to have a mechanism where the receiver can signal to the sender that it isn't validating, so the sender can avoid locator changes 💌.

Architecturally, there are many advantages to putting the mapping function at the end host (instead of at the edge) 🖥️. This simplifies the problems of neighbor aliveness and delayed first packet, and avoids stateful middleboxes. Unfortunately, the early-adopter incentive for host upgrade may not be adequate (HIP's lack of uptake being an example) 😔.

RANGI doesn't have an explicit solution for the mobility race condition (there's no mention of a home-agent-like device) 🫣. Still, host-to-host notification combined with falling back on the ID->locators lookup (assuming adequate dynamic update of the lookup system) may be good enough for the vast majority of mobility situations 🌙.

RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites. RANGI proxies have no mechanisms to deal with the edge-to-edge aliveness problem, and the edge-to-edge proxy approach kind of dirties up an otherwise clean end-to-end model 🫠.

RANGI exploits existing IPv6 transition technologies (ISATAP and softwire). These transition technologies are being pursued outside of RRG anyway and don't need to be specified in RANGI drafts per se. RANGI only needs to address how it interoperates with IPv4 and legacy IPv6, which it appears to do adequately well through proxies ✨.

3.3. Rebuttal 🦋

okay so the reason the ID->locator lookup is split off from the FQDN->ID lookup is kind of two-fold 💅: 1) not all applications are tied to FQDNs, and 2) it seems unnecessary to make every single device have an FQDN of its own. ngl that's giving "only add what you actually need" energy ✨. Basically, RANGI uses DNS to realize the ID->locator mapping system. If the authoritative servers of a given Administrative Domain (AD) have way too many entries to maintain, Distributed Hash Table (DHT) tech can be used to help those servers scale better, e.g., the mappings a given AD maintains get spread across a group of authoritative servers in a DHT fashion. the robustness of DHT is inherited naturally into the ID->locator mapping system, so that's a whole win 🎀. And no trust issue either, because each AD authority runs its own DHT ring, which only holds the mappings for identifiers administered by that AD authority. iconic 👑

for host mobility, if the communicating entities are RANGI nodes, the mobile node will notify the correspondent node of its new locator once its locator changes because of a mobility or re-homing event 🧚. it should also update its locator information in the ID->locator mapping system in a timely fashion, using the Secure DNS Dynamic Update mechanism defined in [RFC3007]. with simultaneous mobility, at least one of the nodes has to go to the ID->locator mapping system to resolve the correspondent node's new locator so they can keep talking 🫶. and if the correspondent node is a legacy host, Transit Proxies (which do a similar job to the home agents in Mobile IP) will relay the packets between the communicating parties 💜.

RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with both legacy IPv6 and IPv4 sites 🌸. since proxies function as RANGI hosts, they can handle Locator Update Notification messages sent from remote RANGI hosts (or even from remote RANGI proxies) correctly. so there is no edge-to-edge aliveness problem, periodt 💅. the details will be specified in a later version of RANGI-PROXY 👀.

the intention behind RANGI using IPv4-embedded IPv6 addresses as locators is to reduce the total deployment cost of this new Internet architecture and to avoid renumbering the site's internal routers when that site changes ISPs 🍓. literally the cheapest, least-chaos move 😭.

4. Internet Vastly Improved Plumbing (Ivip) 🌈

4.1. Summary 💖

4.1.1. Key Ideas

okay so Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation scheme for IPv4 and IPv6 ✨. it gives you multihoming, portability of address space, and inbound traffic engineering for end-user networks of all sizes and types, including corporations, SOHO (Small Office, Home Office), and mobile devices 🏠.

Ivip meets all the constraints imposed by the need for widespread voluntary adoption [Ivip_Constraints] 🫶.

Ivip's global fast-push mapping distribution network is structured like a cross-linked multicast tree 🌳. it pushes all mapping changes to full-database query servers (QSDs) within ISPs and end-user networks that have ITRs, and each mapping change reaches all QSDs within a few seconds ⚡. (Note: "QSD" is from Query Server with full Database.)

ITRs get mapping information from these local QSDs within a few tens of milliseconds, and QSDs notify ITRs of changed mappings with similarly low latency 🦋. ITRs tunnel all traffic packets to the correct ETR without significant delay 🚀.

Ivip's mapping consists of a single ETR address for each range of mapped address space. Ivip ITRs don't need to test reachability to ETRs, because the mapping is changed in real-time to point at the desired ETR 🎯.

End-user networks control the mapping, typically by contracting a specialized company to monitor the reachability of their ETRs and change the mapping to achieve multihoming and/or traffic engineering (TE) 💅. so the mechanisms that control ITR tunneling are controlled by the end-user networks in real-time, and they're completely separate from the Core-Edge Separation scheme itself. main character energy 👑.

ITRs can be implemented in dedicated servers or hardware-based routers, and the ITR function can also be integrated into sending hosts 🖥️. ETRs are relatively simple and only talk to ITRs rarely, for Path MTU management with longer packets 🧸.

Ivip-mapped ranges of end-user address space don't need to be subnets 🍰. they can be of any length, in units of IPv4 addresses or IPv6 /64s.

compared to conventional unscalable BGP techniques, and to Core-Edge Separation architectures with non-real-time mapping systems, end-user networks will be able to achieve more flexible and responsive inbound TE 🔥. if inbound traffic is split into several streams, each going to addresses in different mapped ranges, then real-time mapping changes can be used to steer the streams between multiple ETRs at multiple ISPs. iykyk, it's so good 🤌.

Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel Routers) tunnel packets sent by hosts in networks that lack ITRs 🌈. so the multihoming, portability, and TE benefits apply to all traffic, not just some of it 🎀.

ITRs request mappings either directly from a local QSD or via one or more layers of caching query servers (QSCs), which in turn request it from a local QSD 📦. QSCs are optional but generally desirable, since they reduce the query load on QSDs. (Note: "QSC" is from Query Server with Cache.)

ETRs may be in ISP or end-user networks 🏘️. IP-in-IP encapsulation is used, so there's no UDP or any other header 🙈. PMTUD (Path MTU Discovery) management with minimal complexity and overhead handles the problems caused by encapsulation, and adapts smoothly to jumbo frame paths becoming available in the DFZ 🌊. the outer header's source address is that of the sending host, and this lets existing ISP Border Router (BR) filtering of source addresses be extended to encapsulated traffic packets, through the simple mechanism of the ETR dropping packets whose inner and outer source addresses don't match 🛡️. bestie, that's clever 😭🫶.

4.1.2. Extensions

4.1.2.1. TTR Mobility 🚗

the Translating Tunnel Router (TTR) approach to mobility [Ivip_Mobility] applies to all Core-Edge Separation techniques, and it provides scalable IPv4 and IPv6 mobility in which the MN keeps its own mapped IP address(es) no matter how or where it's physically connected, including behind one or more layers of NAT 🌍.

path lengths are typically optimal or close to optimal, and the MN communicates normally with all other non-mobile hosts (no stack or application changes), and of course with other MNs too 💜. mapping changes are only needed when the MN uses a new TTR, which would typically happen if the MN moved more than 1000 km 🗺️. mapping changes are not required when the MN changes its physical address(es). so chill 😌.

4.1.2.2. Modified Header Forwarding 🪄

separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR without encapsulation ✨. this removes the encapsulation overhead and the PMTUD problems 🙌. both approaches involve modifying all routers between the ITR and ETR so they accept a modified form of the IP header 🔧. these schemes require new FIB/RIB functionality in the DFZ and some other routers, but they don't alter the BGP functions of DFZ routers 🌸.

4.1.3. Gains 🎁

Amenable to widespread voluntary adoption 💖, due to no need for host changes, complete support for packets sent from non-upgraded networks, and no significant degradation in performance.
Modular separation of the control of ITR tunneling behavior from the ITRs and from the Core-Edge Separation scheme itself 🧩: end-user networks control mapping in any way they like, in real-time.
A small fee per mapping change deters frivolous changes and helps pay for pushing the mapping data to all QSDs 💸. End-user networks that make frequent mapping changes for inbound TE should find these fees attractive, considering how much they improve their ability to use the bandwidth of multiple ISP links 🔥.
End-user networks will typically pay the cost of Open ITR in the DFZ (OITRD) forwarding to their networks 🧾. this provides a business model for OITRD deployment and avoids unfair distribution of costs ⚖️.
Existing source address filtering arrangements at BRs of ISPs and end-user networks are prohibitively expensive to implement directly in ETRs 😩. but with the outer header's source address being the same as the sending host's address, Ivip ETRs inexpensively enforce BR filtering on decapsulated packets 🫧. genius, honestly 👑.

4.1.4. Costs 💸

QSDs receive all mapping changes and store a complete copy of the mapping database 🗄️. however, a worst-case scenario is 10 billion IPv6 mappings, each of 32 bytes, which fits on a consumer hard drive today and should fit in server DRAM by the time such adoption is reached 💾.

the maximum number of non-mobile networks requiring multihoming, etc., is likely to be ~10 million, so most of the 10 billion mappings would be for mobile devices 📱. however, TTR mobility doesn't involve frequent mapping changes, since most MNs only rarely move more than 1000 km 🐢.

4.1.5. References 📚

[Ivip_EAF] [Ivip_PMTUD] [Ivip_PLF] [Ivip_Constraints] [Ivip_Mobility] [Ivip_DRTM] [Ivip_Glossary] 🎀

4.2. Critique 🔍

Okay so zoom out to the thousand-foot view and Ivip shares basic design vibes with LISP and a bunch of other map-and-encap designs based on Core-Edge Separation 🦋. But the details are very different, bestie. Ivip makes a bold bet: that with tech advances, you could afford to maintain a real-time distributed global mapping database for all networks and hosts 💅. Multiple parties would team up to build a mapping distribution system that pushes all mapping info and updates to local, full-database query servers in every ISP within a few seconds ⚡. There's no single point of failure, and it uses end-to-end authentication 🔐. Iconic.

A "real time, globally synchronized mapping database" is a critical assumption in Ivip 🫶. Building on that, Ivip dodges several tricky design issues that other folks have studied extensively, including:

special considerations of mobility support that add additional complexity to the overall system;
prompt detection of ETR failures and notification to all relevant ITRs, which turns out to be a rather difficult problem; and
development of a partial-mapping lookup sub-system. Ivip assumes the existence of local query servers with a full database with the latest mapping information changes.

Now the hard questions 😬. To be considered a viable solution to the Internet routing scalability problem, Ivip has to face two fundamental questions. First, whether a global-scale system can achieve real-time synchronized operations, as Ivip assumes, is an entirely open question. Past experiences suggest otherwise 💀.

The second question is about incremental rollout 🌱. Ivip is an ambitious approach, with real-time mapping and local full-database query servers, which many people regard as impossible 🙈. Building and deploying it may take a fair amount of resources, and there's an open question about how to quantify the gains for first movers, both the folks who provide the Ivip infrastructure and the folks who use it. Significant global routing table reduction only happens once a large enough number of parties have adopted Ivip. Honestly, the same question comes up for most other proposals too.

One belief is that Ivip's more ambitious mapping system makes a good design tradeoff, with greater benefits for end-user networks and for those who build the infrastructure ✨. Another belief is that this ambitious design is not viable. Tea.

4.3. Rebuttal 🎀

Since the Summary and Critique were written, Ivip's mapping system has been significantly redesigned into DRTM, which stands for Distributed Real Time Mapping [Ivip_DRTM] 🧚.

DRTM makes it easier for ISPs to install their own ITRs 🛠️. It also helps Mapped Address Block (MAB) operating companies, which don't need to be ISPs, lease Scalable Provider-Independent (SPI) address space to end-user networks with almost no ISP involvement. ISPs don't need to install ITRs or ETRs at all 🙌. To support customers using SPI space, an ISP just has to allow forwarding of outgoing packets whose source addresses come from SPI space. End-user networks can run their own ETRs on their existing PA address(es), and the MAB operating companies cover all the initial investment 💸. Main character energy for the little guys.

Once SPI adoption gets widespread, ISPs will be motivated to install their own ITRs 📡. The point is to locally tunnel packets sent from customer networks that must be tunneled to SPI-using customers of the same ISP, instead of letting those packets leave the ISP's network and come back through tunnels to ETRs in the network.

There's no need for full-database query servers in ISPs, or for any device that stores the full mapping information for all Mapped Address Blocks (MABs) 🙅‍♀️. ISPs that want ITRs will install two or more Map Resolver (MR) servers. These are caching query servers that query multiple (typically nearby) query servers which are full-database for the subset of MABs they serve. Those "nearby" query servers sit at DITR sites, run by or for MAB operating companies who lease MAB space to large numbers of end-user networks. The DITR-site servers will usually be close enough to the MRs to send replies with sufficiently low delay and risk of packet loss, so ITRs can buffer initial packets for a few tens of milliseconds while the mapping arrives ⏱️.

DRTM will scale to billions of micronets, tens of thousands of MABs, and potentially hundreds of MAB operating companies, all without single points of failure or central coordination 👑.

The critique implies that a threshold of adoption is required before significant routing scaling benefits show up. That's untrue for any Core-Edge Separation proposal, LISP and Ivip included 🙅. Both can achieve scalable routing benefits in direct proportion to their level of adoption, by providing portability, multihoming, and inbound TE to large numbers of end-user networks 📈.

Core-Edge Elimination (CEE) architectures require all Internet communications to move to IPv6 with a new locator/identifier separation naming model. That would dump extra management effort, packets, and session establishment delays on all hosts 😩. It's an especially unacceptable burden on battery-operated mobile hosts that rely on wireless links 🔋.

Core-Edge Separation architectures keep the current, efficient naming model, require no changes to hosts, and support both IPv4 and IPv6 🌈. Ivip is the most promising architecture for future development, because its scalable, distributed, real-time mapping system best supports TTR mobility, lets ITRs be simpler, and gives real-time control of ITR tunneling to the end-user network, or to organizations they appoint to control the mapping of their micronets 💜. Periodt.

5. Hierarchical IPv4 Framework (hIPv4) 🌸

5.1. Summary 📝

5.1.1. Key Idea 💡

The Hierarchical IPv4 Framework (hIPv4) adds scalability to the routing architecture by introducing additional hierarchy into the IPv4 address space 🪜. The IPv4 addressing scheme is split into two parts: the Area Locator (ALOC) address space, which is globally unique, and the Endpoint Locator (ELOC) address space, which is only regionally unique. The ALOC and ELOC prefixes are added as a shim header between the IP header and the transport protocol header, and the shim header is identified with a new protocol number in the IP header 🧩. Instead of building a tunneling (i.e., overlay) solution, a new routing element is needed in the service provider's routing domain (called the ALOC realm), a Locator Swap Router 🔁. The current IPv4 forwarding plane stays intact, and no new routing protocols, mapping systems, or caching solutions are required 🙌.

The control plane of the ALOC realm routers needs some modification so that ICMP is compatible with the hIPv4 framework 🛠️. When an area (one or several autonomous systems (ASes)) of an ISP has transformed into an ALOC realm, only ALOC prefixes are exchanged with other ALOC realms. Directly attached ELOC prefixes are only inserted into the RIB of the local ALOC realm, so ELOC prefixes are not distributed to the DFZ 🤫.

Multihoming can be achieved in two ways: either the enterprise requests an ALOC prefix from the RIR (this is not recommended), or the enterprise receives the ALOC prefixes from its upstream ISPs. ELOC prefixes are PI addresses and remain intact when an upstream ISP is changed; only the ALOC prefix is replaced 🔄.

When the RIB of the DFZ is compressed (containing only ALOC prefixes), ingress routers no longer know whether the destination prefix is available 😵. So the endpoints must take on more responsibility for their sessions. This can be done with multipath enabled transport protocols, such as SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the endpoints 🛤️. These multipath transport protocols also provide a session identifier, i.e., a verification tag or token, so the location and identifier split is carried out. Site mobility, endpoint mobility, and mobile site mobility are all achieved 🚚.

DNS needs an upgrade too 📚. To resolve the location of an endpoint, the endpoint must have one ELOC value (the current A-record) and at least one ALOC value in DNS. In multihoming solutions there will be several ALOC values for an endpoint 🌐.

5.1.2. Gains 🏆

Improved routing scalability: Adding additional hierarchy to the address space enables more hierarchy in the routing architecture. Early adopters of an ALOC realm will no longer carry the current RIB of the DFZ. Only the ELOC prefixes of their directly attached networks, plus the ALOC prefixes from other service providers that have migrated, get installed in the ALOC realm's RIB 🌟.
Scalable support for traffic engineering: Multipath enabled transport protocols are recommended to achieve dynamic load-balancing of a session. Support for Valiant Load-balancing (VLB) [Valiant] schemes has been added to the framework, but more research work is required around VLB switching 🔬.
Scalable support for multihoming: Only attachment points of a multihomed site are advertised in the DFZ (using the ALOC prefix). DNS will tell the requester how many attachment points the destination endpoint has. It's the initiating endpoint's choice and responsibility to pick which attachment point is used for the session, and endpoints using multipath-enabled transport protocols can use several attachment points for a session 🎯.
Simplified Renumbering: When changing provider, the local ELOC prefixes remain intact, and only the ALOC prefix changes at the endpoints. The ALOC prefix is not used for routing or forwarding decisions in the local network 🪄.
Decoupling Location and Identifier: The verification tag (SCTP) and token (MPTCP) can be considered to have the characteristics of a session identifier. That means a session layer is created between the transport and application layers in the TCP/IP model 🦋.
Routing quality: The hIPv4 framework introduces no tunneling or caching mechanisms. Only a swap of the content in the IPv4 header and locator header at the destination ALOC realm is required, so current routing and forwarding algorithms are preserved as such. Valiant Load-balancing might be used as a new forwarding mechanism 💅.
Routing Security: Similar to today's DFZ, except that ELOC prefixes cannot be hijacked (by injecting a longest match prefix) outside an ALOC realm 🔒.
Deployability: The hIPv4 framework is an evolution of the current IPv4 framework and is backwards compatible with it. Sessions in a local network and inside an ALOC realm might, in the future, still use the current IPv4 framework 🧡.

5.1.3. Costs and Issues 🧾

Upgrade of the stack at an endpoint that is establishing sessions outside the local ALOC realm 🆙.
In a multihoming solution, the border routers should be able to apply policy-based routing upon the ALOC value in the locator header 🚦.
New IP allocation policies must be set by the RIRs 📋.
There is a short timeframe before the expected depletion of the IPv4 address space occurs ⏳.
Will enterprises give up the globally unique IPv4 address block allocations they have gained? 🤔
Coordination with MPTCP is highly desirable 🤝.

5.1.4. References 📚

[hIPv4] [Valiant]

5.2. Critique

okay bestie, this critique is NOT trying to grade all of hIPv4's architecture and mechanisms 💅 It only asks one question: should hIPv4 get IETF development instead of, or alongside, the only two proposals that look practical for IPv4, which are Ivip and LISP? 🦋

Ivip and LISP look like they have a major advantage over hIPv4 for packets sent from non-upgraded hosts/networks 👑 Ivip's DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel Routers) both accept packets sent by any non-upgraded host/network and tunnel them to the correct ETR. So the full portability, multihoming, and inbound TE benefits reach those packets too, not just the ones from hosts in networks with ITRs 🎀 hIPv4 doesn't seem to have anything like that, so those benefits only show up for communications between two upgraded hosts in upgraded networks 😭

So the significant benefits for adopters (being able to rely on the new system for portability, multihoming, and inbound TE for all, or almost all, of their communications) will only arise after all, or almost all, networks upgrade their networks, hosts, and addressing arrangements 🙈 hIPv4's relationship between adoption levels and benefits to any adopter is way less favorable to widespread adoption than Core-Edge Separation (CES) architectures like Ivip and LISP. 💔

This puts hIPv4 at a disadvantage for routing scaling benefits too, which likewise will only show up once adoption is close to ubiquitous 🌈 Ivip and LISP can provide routing scaling benefits in direct proportion to their level of adoption, since all adopters gain full benefits for all their communications, in a highly scalable manner ✨

hIPv4 requires stack upgrades, which no CES architecture requires 🫶 Plus, a large number of existing IPv4 application protocols convey IP addresses between hosts in a way that will not work with hIPv4. The draft itself says: "There are several applications that are inserting IP address information in the payload of a packet. Some applications use the IP address information to create new sessions or for identification purposes. This section is trying to list the applications that need to be enhanced; however, this is by no means a comprehensive list" [hIPv4].

If even a few widely used applications would need to be rewritten to operate successfully with hIPv4, that's such a huge disincentive to adoption that hIPv4 could be ruled out ever being adopted widely enough to solve the routing scaling problem 😱 especially since CES architectures fully support all existing protocols, without the need for altering host stacks.

It appears that hIPv4 involves major practical difficulties, which mean that in its current form it is not suitable for IETF development. 🥀

5.3. Rebuttal

No rebuttal was submitted for this proposal. 🤷‍♀️

6. Name Overlay (NOL) Service for Scalable Internet Routing ✨

6.1. Summary

6.1.1. Key Idea

The basic idea is to add a name overlay (NOL) onto the existing TCP/IP stack. 🧚

Its functions include:

Managing host name configuration, registration, and authentication;
Initiating and managing transport connection channels (i.e., TCP/IP connections) by name;
Keeping application data transport continuity for mobility.

At the edge network, we introduce a new type of gateway, a Name Transfer Relay (NTR), which blocks the PI addresses of edge networks into upstream transit networks. NTRs perform address and/or port translation between blocked PI addresses and globally routable addresses, which seem like today's widely used NAT / Network Address Port Translation (NAPT) devices. Both legacy and NOL applications behind a NTR can access the outside as usual. To access the hosts behind a NTR from outside, we need to use NOL to traverse the NTR by name and initiate connections to the hosts behind it. 🌸

Different from proposed host-based ID/locator split solutions, such as HIP, Shim6, and name-oriented stack, NOL doesn't need to change the existing TCP/IP stack, sockets, or their packet formats. NOL can coexist with the legacy infrastructure, and the Core-Edge Separation solutions (e.g., APT, LISP, Six/One, Ivip, etc.). 💜

6.1.2. Gains

Reduce routing table size: Prevent edge network PI address from leaking into the transit network by deploying gateway NTRs.
Traffic Engineering: For legacy and NOL application sessions, the incoming traffic can be directed to a specific NTR by DNS. In addition, for NOL applications, initial sessions can be redirected from one NTR to other appropriate NTRs. These mechanisms provide some support for traffic engineering. 🍓
Multihoming: When a PI addressed network connects to the Internet by multihoming with several providers, it can deploy NTRs to prevent the PI addresses from leaking into provider networks.
Transparency: NTRs can be allocated PA addresses from the upstream providers and store them in NTRs' address pool. By DNS query or NOL session, any session that wants to access the hosts behind the NTR can be delegated to a specific PA address in the NTR address pool. 🦋
Mobility: The NOL layer manages the traditional TCP/IP transport connections, and provides application data transport continuity by checkpointing the transport connection at sequence number boundaries.
No need to change TCP/IP stack, sockets, or DNS system. 🎀
No need for extra mapping system. 🙌
NTR can be deployed unilaterally, just like NATs.
NOL applications can communicate with legacy applications.
NOL can be compatible with existing solutions, such as APT, LISP, Ivip, etc.
End-user-controlled multipath indirect routing based on distributed NTRs. This will give benefits to the performance-aware applications, such as video streaming, applications on MSN.com, etc. 🔥

6.1.3. Costs

Legacy applications have trouble with initiating access to the servers behind NTR. Such trouble can be resolved by deploying the NOL proxy for legacy hosts, or delegating globally routable PA addresses in the NTR address pool for these servers, or deploying a proxy server outside the NTR. 🛠️
NOL may increase the number of entries in DNS, but it is not drastic because it only increases the number of DNS records at domain granularity not the number of hosts. The name used in NOL, for example, is similar to an email address hostname@example.net. The needed DNS entries and query are just for "example.net", and the NTR knows the "hostnames". Not only will the number of DNS records be increased, but the dynamics of DNS might be agitated as well. However, the scalability and performance of DNS are guaranteed by its naming hierarchy and caching mechanisms. 😤
Address translating/rewriting costs on NTRs.

6.1.4. References

No references were submitted. 📭

6.2. Critique

Applications on hosts need to be rebuilt based on a name overlay library to be NOL-enabled. The legacy software that is not maintained will not be able to benefit from NOL in the Core-Edge Elimination situation. In the Core-Edge Separation scheme, a new gateway NTR is deployed to prevent edge-specific PI prefixes from leaking into the transit core. NOL doesn't impede the legacy endpoints behind the NTR from accessing the outside Internet, but the legacy endpoints cannot access or will have difficultly accessing the endpoints behind a NTR without the help of NOL. 🥺
In the case of Core-Edge Elimination, the end site will be assigned multiple PA address spaces, which leads to renumbering troubles when switching to other upstream providers. Upgrading endpoints to support NOL doesn't give any benefits to edge networks. Endpoints have little incentive to use NOL in a Core-Edge Elimination scenario, and the same is true with other host-based ID/locator split proposals. Whether they are IPv4 or IPv6 networks, edge networks prefer PI address space to PA address space. 💅
In the Core-Edge Separation scenario, the additional gateway NTR is to prevent the specific prefixes from the edge networks, just like a NAT or the ITR/ETR of LISP. A NTR gateway can be seen as an extension of NAT (Network Address Translation). Although NATs are deployed widely, upgrading them to support NOL extension or deploying additional new gateway NTRs at the edge networks is on a voluntary basis and has few economic incentives. 📉
The stateful or stateless translation for each packet traversing a NTR will require the cost of the CPU and memory of NTRs, and increase forwarding delay. Thus, it is not appropriate to deploy NTRs at the high-level transit networks where aggregated traffic may cause congestion at the NTRs. 🐢
In the Core-Edge Separation scenario, the requirement for multihoming and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For reliability, all of the associations between multiple NTRs and the end site name will be kept in DNS, which may increase the load on DNS. 🫠
To support mobility, it is necessary for DNS to update the corresponding name-NTR mapping records when an end system moves from behind one NTR to another NTR. The NOL-enabled end relies on the NOL layer to preserve the continuity of the transport layer, since the underlying TCP/UDP transport session would be broken when the IP address changed. 🌙

6.3. Rebuttal 🎀

okay so NOL doesn't look like CEE or CES, bestie 💅 it's its own thing. By supporting application-level sessions through the name overlay layer, NOL can support some solutions in the CEE style 🦋. But honestly, NOL is mostly closer to CES solutions, aka keeping the PI prefixes of edge networks from leaking into the upstream transit networks 🙈. The NTR does that job, kinda like the ITRs/ETRs in CES solutions, but NOL doesn't need to draw that hard line between core and edge networks ✨. The whole goal is to give end users or networks a service that makes multihoming, multipath routing, and traffic engineering easier to adopt through indirect routing via NTRs, all while not speeding up or slowing down the growth of the global routing table size 💜. main character energy, fr.

Now, the NOL critique had some problems 😭. In the original NOL proposal, a DNS query for a host behind an NTR would return the host's actual IP addresses and the NTR's address. That can cause difficulties for legacy applications, since the DNS response is non-standard 💀. So to fix it, NOL uses a new namespace, and DNS doesn't return NTR IP addresses for legacy hosts 🌸. NOL names are formatted like email addresses, such as des@example.net. The mapping between example.net and the IP address of the matching NTR gets registered in DNS 🧚. The NOL layer knows what des@example.net means, so it only sends a query to DNS for example.net, and DNS hands back the IP addresses of the corresponding NTRs. Legacy applications still use the traditional FQDN, and DNS returns the host's actual IP address. but, if the host is behind an NTR, legacy applications may be unable to reach it 😬.

The stateless address translation or stateful address and port translation may cause a scaling problem with the number of table entries an NTR must maintain, and legacy applications cannot start sessions with hosts inside the NOL-adopting End User Network (EUN) 🥺. However, these problems may not be a big barrier for deploying NOL or other similar approaches 💖. NAT-like boxes, proxies, and firewall devices are already everywhere at the ingress/egress points of enterprise networks, campus networks, and other stub EUNs 🏢. Hosts running as servers can be deployed outside the NTRs, or they can be assigned PA addresses in an NTR-adopting EUN ✨.

7. Compact Routing in a Locator Identifier Mapping System (CRM) ✨

7.1. Summary 🌈

7.1.1. Key Idea

this proposal (we're calling it "CRM" here) is all about building a super scalable locator identity mapping system using compact routing principles 🧠. It gives the system a way to adapt its topology dynamically so aggregation is efficient [CRM] 🦋. Map servers get picked as cluster heads or landmarks based on how well they can aggregate EID announcements 👑.

7.1.2. Gains

Minimizes the routing table sizes at the system level (i.e., map servers) 📉. It also gives clear upper bounds for routing stretch, which set the packet delivery delay for the map request and first packet ⏱️.
The mapping system is organized around the EID numbering space, which cuts down the admin overhead of managing that space 🗂️. There's no need for administratively planned hierarchical address allocation, because the system finds its own convergence into a set of EID allocations 🪄.
Availability and robustness of the overall routing system (including xTRs and map servers) get a boost 🛡️. That's because there's potential to use multiple map servers, plus direct routes that don't involve the map servers at all 🫶.

7.1.3. Costs

the scalability gains only show up in big deployments 🐘. If the stretch is bounded to what compact routing gives (worst-case stretch less or equal to 3, on average, 1+epsilon), then each xTR needs memory/cache for the mappings of its cluster 💭.

7.1.4. References

[CRM] 📚

7.2. Critique 💅

okay the CRM proposal isn't a complete proposal yet, so the IETF can't really consider it for further development as a scalable routing solution 😭.

Compact Routing principles might be able to improve a mapping overlay structure like LISP+ALT, but there are still a few objections 🙅‍♀️.

Firstly, a CRM-modified ALT structure would still be a global query server system 🌍. No matter how much ALT's path lengths and delays get optimized, there's a real problem with a querier (who could be literally anywhere in the world) relying on mapping information from one or, ideally, two or more authoritative query servers (also potentially anywhere in the world) 😬. The delays and packet-loss risks baked into that setup are a fundamental problem 💀. It's even worse when multiple, potentially long, traffic streams come in to ITRs and get forwarded over the CRM networks to the destination network 📦. ITRs have to use the CRM infrastructure while they wait for a map reply, and the traffic forwarded on that infrastructure acts as map requests, which can cause a scalability and performance issue for the infrastructure itself 🔥.

Secondly, the changes proposed here involve the roles of particular nodes being dynamically assigned as part of the network's self-organizing nature 🔄.

The discussion of clustering in the middle of page 4 of [CRM] also says that particular nodes are responsible for registering EIDs from ETRs that are typically far away, all handling closely related EIDs that this node can aggregate 🗺️. Since MSes are apparently nodes within the compact routing system, and an MS deciding whether to accept EID registrations gets determined by the system's self-organizing properties, there are concerns about how EID registration can be done securely when no particular physical node is responsible for it 🔐.

Thirdly, there are concerns about individually owned nodes doing work for other organizations 🤔. Problems of trust, and of responsibilities and costs landing on people who don't directly benefit, already exist in the inter-domain routing system, and they're a challenge for any scalable routing solution 🧩.

There are simpler solutions to the mapping problem than building an elaborate network of routers 🛠️. If a global-scale query system is still preferred, it would be better to have ITRs use local MRs, each dynamically configured to know the IP address of the million or so authoritative Map Server (MS) query servers, or two million or so if they exist in pairs for redundancy 🤓.

It looks like the inherently greater delays and packet-loss risks of global query server systems make them unsuitable mapping solutions for Core-Edge Elimination or Core-Edge Separation architectures 🚫. The fix seems to be a greater number of widely distributed authoritative query servers, so at least one of them will be close enough to each querier that delays and risk of packet loss drop to acceptable levels 📍. A structure like that would suit map requests, but maybe not handling the traffic packets headed to the destination networks 📬.

7.3. Rebuttal 🦋

CRM is easiest to understand as a change to the routing structure of the LISP+ALT mapping overlay system, done by altering or adding to the network's BGP control plane 🧩.

CRM's goals include delivering the initial traffic packets to their destination networks, where those packets also work as map requests 📨. These packet streams can be long and numerous, lasting a fraction of a second up to maybe several seconds before the ITR gets the map reply ⏳.

Compact Routing principles optimize the path length these query or traffic packets take through a significantly modified version of the ALT (or similar) network 🛤️. They also generally reduce the typical or maximum paths the query packets take ✨.

An overlay network is a diversion from the shortest path, but CMR limits that diversion and provides an upper bound 📏. Landmark routers and servers could deliver more than just the first traffic packet, depending on their CPU capabilities and their network connectivity bandwidth 💪.

Trust between the landmarks (mapping servers) can be built on the current BGP relationships 🤝. Registration to the landmark nodes needs to be authenticated mutually between the MS and the system doing the registering 🔑. This part isn't documented in the proposal text 📝.

8. Layered Mapping System (LMS) 🌸

8.1. Summary 🍓

8.1.1. Key Ideas

the layered mapping system proposal builds a hierarchical mapping system for scalability 🪜. It analyzes the design constraints, presents an explicit system structure, and designs a two-cache mechanism on the ingress tunneling router (ITR) to get low request delay 🚀. It also facilitates data validation ✅. Tunneling and mapping happen at the core, and no change is needed on edge networks 🙌. The mapping system is run by interest groups that are independent of any ISP, which fits an economical model and can be voluntarily adopted by various networks 💜. Mapping systems can also be built stepwise, especially in the IPv6 scenario 🧚.

8.1.2. Gains

Scalability 📈
- A. Distributed storage of mapping data avoids central storage of massive amounts of data, and it restricts updates to local areas 🗺️.
- B. The cache mechanism in an ITR reasonably reduces the request loads on the mapping system 🧊.
Deployability 🛠️
- A. No change on edge systems. Only tunneling in core routers, plus new devices in core networks 🏗️.
- B. The mapping system can be built stepwise. A mapping node doesn't need to be built if none of its responsible ELOCs is allocated, which makes especially good sense for IPv6 🌈.
- C. It conforms to a viable economic model. Mapping system operators can profit from their services, and core routers and edge networks are willing to join either to avoid router upgrades or to get traffic engineering 💸. The benefits of joining don't depend on the scheme's implementation scale 🎯.
Low request delay: The low number of layers in the mapping structure, together with the two-stage cache, helps achieve low request delay ⚡.
Data consistency: The two-stage cache lets an ITR update data in the map cache conveniently 🔄.
Traffic engineering support: Edge networks tell the mapping system about their prioritized mappings with all upstream routers, which gives edge networks control over their ingress flows 🎛️.

8.1.3. Costs

Deployment of LMS still needs to be discussed further 🤔.
The structure of the mapping system needs to be refined according to practical circumstances 🔧.

8.1.4. References

[LMS_Summary] [LMS] 📚

8.2. Critique 💅

okay so LMS is a mapping mechanism built on Core-Edge Separation 🦋. Any proposal that needs a global mapping system with keys that act like an "edge address" in a Core-Edge Separation setup can use it. Those keys have to be globally unique (by authorization, or just statistically), they're available to edge users, and they may have several satisfied mappings, possibly with different weights 💜. So if a routing scalability proposal needs mapping but doesn't say how to do it, it can borrow LMS to strengthen its infrastructure ✨.

The key idea of LMS is basically the same as LISP+ALT: the mapping system should be organized hierarchically so storage and updates scale, and lookups are quick 🔍. BUT LMS wants an ISP-independent mapping system, and ETRs are not the authorities for mapping data. Instead, ETRs or edge-sites report their mapping data to related mapping servers 🫶.

LMS assumes mapping servers can be deployed incrementally. A server doesn't have to be built if none of its administered edge addresses are allocated. Mapping servers can also charge for their services, which gives them an economic reason to exist 💸. How this brand-new system actually gets constructed is still not clear 🙈. Explicit layering is only an ideal state. The proposal analyzes the layering limits and feasibility, but it doesn't give a practical way to deploy any of it 💀.

The drawbacks of LMS's feasibility analysis are that it 1) is based on current PC power and may not represent future circumstances (especially for IPv6), and 2) does not consider the variability of address utilization. Some IP address spaces may be effectively allocated and used while others aren't, so some mapping servers could get overloaded while others sit basically empty 😬. More thoughts are needed on how flexible the layer design is 🧚.

LMS doesn't fit well for mobility 😭. It does not solve the problem when hosts move faster than the mapping updates and propagation between relative mapping servers. On the other hand, mobile hosts moving across ASes and changing their attachment points (core addresses) happens less often than hosts moving within an AS 🌸.

Separation needs two planes: Core-Edge Separation (which gains routing table scalability) and identity/location separation (which achieves mobility) 👑. The Global Locator, Local Locator, and Identifier (GLI) scheme clarifies this really well, and in that case LMS can be used to provide identity-to-core address mapping. Of course, other schemes may be competent too, and LMS can be incorporated with them if the scheme has global keys and needs to map them to other namespaces 🎀.

8.3. Rebuttal 🫠

No rebuttal was submitted for this proposal.

9. Two-Phased Mapping 🌈

9.1. Summary ✨

9.1.1. Considerations 🤔

A mapping from prefixes to ETRs is an M:M mapping. Any change of a (prefix, ETR) pair should be updated in a timely manner, which can be a heavy burden on any mapping system if the relation changes frequently 😩.
A prefix<->ETR mapping system cannot be deployed efficiently if it is overwhelmed by worldwide dynamics. Therefore, the mapping itself is not scalable with this direct mapping scheme 💔.

9.1.2. Basics of a Two-Phased Mapping 🦋

Introduce an AS number in the middle of the mapping. The phase I mapping is prefix<->AS#, and the phase II mapping is AS#<->ETRs. This creates a M:1:M mapping model 🧩.
It is fair to assume that all ASes know their local prefixes (in the IGP) better than other ASes do, and it is most likely that local prefixes can be aggregated when they can be mapped to the AS number. That will reduce the number of mapping entries. Also, ASes know their ETRs on the border between core and edge clearly. So, all mapping information can be collected locally 🏠.
A registry system will take care of the phase I mapping information. Each AS should have a registration agent to notify the registry of the local range of IP address space. This system can be organized as a hierarchical infrastructure like DNS, or alternatively, as a centralized registry like "whois" in each RIR. Phase II mapping information can be distributed between xTRs as a BGP extension 📮.
The basic forwarding procedure goes like this. The ITR first gets the destination AS number from the phase I mapper (or from cache) when the packet is entering the "core". Then it extracts the closest ETR for the destination AS number. This step is local, since phase II mapping information has already been "pushed" to the ITR through BGP updates. Finally, the ITR tunnels the packet to the corresponding ETR 🚀.

9.1.3. Gains 💖

Any prefix reconfiguration (aggregation/deaggregation) within an AS will not be reflected in the mapping system 🙌.
Local prefixes can be aggregated with a high degree of efficiency 📦.
Both phase I and phase II mappings can be stable 🧘‍♀️.
A stable mapping system will reduce the update overhead introduced by topology changes and/or routing policy dynamics 📉.

9.1.4. Summary 🎀

The two-phased mapping scheme introduces an AS number between the mapping prefixes and ETRs.
The decoupling of direct mapping makes highly dynamic updates stable. Therefore, it can be more scalable than any direct mapping designs 👑.
The two-phased mapping scheme is adaptable to any proposals based on the core/edge split 🌸.

9.1.5. References 📚

No references were submitted.

9.2. Critique 🙈

This is a simple idea for how to scale mapping. However, this design is too incomplete to be considered a serious input to RRG. Take the following two issues as examples:

First, in this two-phase scheme, an AS is essentially the unit of destinations. In other words, sending ITRs find out destination AS D, then send data to one of D's ETRs. This does not offer much choice for traffic engineering 🚦.

Second, there is no consideration whatsoever on failure detection and handling 💀.

9.3. Rebuttal 🫠

No rebuttal was submitted for this proposal.

10. Global Locator, Local Locator, and Identifier Split (GLI-Split) 🦄

10.1. Summary 🌟

10.1.1. Key Idea 🔑

GLI-Split implements a separation between global routing (in the global Internet outside edge networks) and local routing (inside edge networks), using global and local locators (GLs and LLs). On top of that, a separate static identifier (ID) is used to identify communication endpoints (e.g., nodes or services) independently of any routing information 🪪. Locators and IDs are encoded in IPv6 addresses to enable backwards-compatibility with the IPv6 Internet 🌐. The higher-order bits store either a GL or a LL, while the lower-order bits contain the ID. A local mapping system maps IDs to LLs, and a global mapping system maps IDs to GLs 🗺️.

The full GLI-mode requires nodes with upgraded networking stacks and special GLI-gateways. The GLI-gateways perform stateless locator rewriting in IPv6 addresses with the help of the local and global mapping systems 🛠️. Non-upgraded IPv6 nodes can also be accommodated in GLI-domains, since an enhanced DHCP service and GLI-gateways compensate for their missing GLI-functionality. This is an important feature for incremental deployability 🥹.

10.1.2. Gains 🎉

The benefits of GLI-Split are:

Hierarchical aggregation of routing information in the global Internet through separation of edge and core routing
Provider changes not visible to nodes inside GLI-domains (renumbering not needed)
Rearrangement of subnetworks within edge networks not visible to the outside world (better support of large edge networks)
Transport connections survive both types of changes
Multihoming
Improved traffic engineering for incoming and outgoing traffic
Multipath routing and load balancing for hosts
Improved resilience
Improved mobility support without home agents and triangle routing
Interworking with the classic Internet
- without triangle routing over proxy routers
- without stateful NAT

These benefits are available for upgraded GLI-nodes, but non-upgraded nodes in GLI-domains partially benefit from these advanced features, too. This offers multiple incentives for early adopters, and they have the option to migrate their nodes gradually from non-GLI-stacks to GLI-stacks 🦋✨.

10.1.3. Costs 💸

Local and global mapping system
Modified DHCP or similar mechanism
GLI-gateways with stateless locator rewriting in IPv6 addresses
Upgraded stacks (only for full GLI-mode)

10.1.4. References 📖

[GLI]

10.2. Critique 🫶

okay so GLI-Split makes a super clear split between two separation planes ✨. The first is between identifier and locator, which is there to meet end-users' needs, mobility included. The second is between local and global locator, which keeps the global routing table scalable 🌸. The distinction is needed because ISPs and hosts have different requirements, and both need the changes inside and outside GLI-domains to stay invisible to their opposites 💅.

A main drawback is that GLI-Split puts a burden on hosts 😭. Before a host routes a packet received from upper layers, its network stack first has to resolve the DNS name to an IP address. If that IP address is GLI-formed, the host may look up the map from the identifier extracted from the IP address to the local locator. If the communication is between different GLI-domains, hosts may further look up the mapping from the identifier to the global locator. Having the local mapping system forward requests to the global mapping system for hosts is just an option 🧚. Host lookup may ease the burden on intermediate nodes, which would otherwise have to perform the mapping lookup 🙈. Still, the three lookups by hosts in the worst case may lead to large delays unless a very efficient mapping mechanism is devised. The work may also become impractical for low-powered hosts 💀.

On one hand, GLI-Split can provide backward compatibility, where classic and upgraded IPv6 hosts can communicate. This is its big virtue 👑. On the other hand, the need to upgrade may work against hosts' enthusiasm to change. That is offset against the benefits they would gain.

GLI-Split provides additional features to improve TE and resilience, e.g., exerting multipath routing 🦋. However, the cost is that more burdens land on hosts, e.g., they may need more lookup actions and route selections. Honestly though, these kinds of tradeoffs between costs and gains exist in most proposals 🤷‍♀️.

One improvement GLI-Split offers is support for mobility, by updating DNS data as GLI-hosts move across GLI-domains 🧳. Through this, the GLI-corresponding-node can query DNS to get a valid global locator of the GLI-mobile-node, and it need not query the global mapping system (unless it wants to do multipath routing). This gives nodes more incentive to become GLI-enabled 🍓. The merits of GLI-Split, including simplified-mobility-handover provision, compensate for the costs of this improvement ✨.

GLI-Split claims to use rewriting instead of tunneling for conversions between local and global locators when packets span GLI-domains 🎀. The major advantage is that this kind of rewriting needs no extra state, since local and global locators need not map to each other. Many other rewriting mechanisms do need to maintain extra state. It also avoids the MTU problem faced by tunneling methods. BUT, GLI-Split achieves this only by compressing the namespace size of each attribute (identifier and local/global locator) 😬. It encodes two namespaces (identifier and local/global locator) into an IPv6 address, where each has a size of 2^64 or less. Map-and-encap proposals instead assume that identifier and locator each occupy a 128-bit space.

10.3. Rebuttal 💅

The arguments in the GLI-Split critique are correct 🙌. There are only two points that should be clarified here. First, it is not a drawback that hosts perform the mapping lookups. Second, the critique proposed an improvement to the mobility mechanism, which is of a general nature and not specific to GLI-Split.

The additional burden on the hosts is actually a benefit, compared to having the same burden on the gateways. If the gateway performed the lookups, and packets addressed to uncached EIDs arrived, a lookup in the mapping system would have to be initiated. Until the mapping reply returns, packets must be either dropped, cached, or sent over the mapping system to the destination. All of these options are not optimal and have their drawbacks. To avoid these problems in GLI-Split, the hosts perform the lookup. The short additional delay is not a big issue in the hosts, because it happens before the first packets are sent. So no packets are lost or have to be cached 🧠. GLI-Split could also easily be adapted to special GLI-hosts (e.g., low-power sensor nodes) that do not have to do any lookup and simply let the gateway do all the work. This functionality is included anyway for backward compatibility with regular IPv6 hosts inside the GLI-domain 🌈.
The critique proposes a DNS-based mobility mechanism as an improvement to GLI-Split. However, this improvement is an alternative mobility approach that can be applied to any routing architecture (including GLI-Split), and it also raises some concerns, e.g., the update speed of DNS. Therefore, we prefer to keep this issue out of the discussion 🙈.

11. Tunneled Inter-Domain Routing (TIDR) 🚇

11.1. Summary ✨

11.1.1. Key Idea

Provides a method for locator/identifier separation using tunnels between routers on the edge of the Internet transit infrastructure 🛣️. It enriches the BGP protocol for distributing the identifier-to-locator mapping. Using new BGP attributes, "identifier prefixes" are assigned inter-domain routing locators, so that they will not be installed in the RIB. Instead they get moved to a new table called the Tunnel Information Base (TIB). Afterwards, when routing a packet to an "identifier prefix", the TIB is searched first to perform tunneling, and secondly the RIB is searched for actual routing. After the edge router performs tunneling, all routers in the middle route this packet until it reaches the router at the tail-end of the tunnel 🧚.

11.1.2. Gains

Smooth deployment
Size reduction of the global RIB
Deterministic customer traffic engineering for incoming traffic
Numerous forwarding decisions for a particular address prefix
Stops AS number space depletion
Improved BGP convergence
Protection of the inter-domain routing infrastructure
Easy separation of control traffic and transit traffic
Different layer-2 protocol IDs for transit and non-transit traffic
Multihoming resilience
New address families and tunneling techniques
Support for IPv4 or IPv6, and migration to IPv6
Scalability, stability, and reliability
Faster inter-domain routing

11.1.3. Costs

Routers on the edge of the inter-domain infrastructure will need to be upgraded to hold the mapping database (i.e., the TIB).
"Mapping updates" will need to be treated differently from usual BGP "routing updates".

11.1.4. References

[TIDR] [TIDR_identifiers] [TIDR_and_LISP] [TIDR_AS_forwarding]

11.2. Critique 🔍

TIDR is a Core-Edge Separation architecture from late 2006 that distributes its mapping information via BGP messages passed between DFZ routers 🕰️.

This means TIDR cannot solve the most important goal of scalable routing, which is to accommodate much larger numbers of end-user network prefixes (millions or billions) without each such prefix directly burdening every DFZ router 😩. Messages advertising routes for TIDR-managed prefixes may be handled with lower priority, but this would only marginally reduce the workload for each DFZ router compared to handling an advertisement of a conventional PI prefix.

Therefore, TIDR cannot be considered for RRG recommendation as a solution to the routing scaling problem 🚫.

For a TIDR-using network to receive packets sent from any host, every BR of all ISPs must be upgraded to have the new ITR-like functionality 🔧. Furthermore, all DFZ routers would need to be altered so they accepted and correctly propagated the routes for end-user network address space, with the new LOCATOR attribute, which contains the ETR address and a REMOTE-PREFERENCE value. Firstly, if they received two such advertisements with different LOCATORs, they would advertise a single route to this prefix containing both. Secondly, for end-user address space (for IPv4) to be more finely divided, the DFZ routers must propagate LOCATOR-containing advertisements for prefixes longer than /24.

TIDR's ITR-like routers store the full mapping database, so there would be no delay in obtaining mapping, and therefore no significant delay in tunneling traffic packets ⚡.

[TIDR] is written as if traffic packets are classified by reference to the RIB, but routers use the FIB for this purpose, and "FIB" does not appear in [TIDR] 🤔.

TIDR does not specify a tunneling technique. It leaves this to be chosen by the ETR-like function of BRs, and it is specified as part of a second kind of new BGP route advertised by that ETR-like BR. There is no provision for solving the PMTUD problems inherent in encapsulation-based tunneling 💀.

ITR functions must be performed by already busy routers of ISPs, rather than being distributed to other routers or to sending hosts 😮‍💨. There is no practical support for mobility. The mapping in each end-user route advertisement includes a REMOTE-PREFERENCE for each ETR-like BR, but this is used by the ITR-like functions of BRs to always select the LOCATOR with the highest value. As currently described, TIDR does not provide inbound load-splitting TE.

Multihoming service restoration is achieved initially by the ETR-like function of the BR at the ISP whose link to the end-user network has just failed. It looks up the mapping to find the next preferred ETR-like BR's address. The first ETR-like router tunnels the packets to the second ETR-like router in the other ISP. However, if the failure was caused by the first ISP itself being unreachable, then connectivity would not be restored until a revised mapping (with higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the second ISP propagated across the DFZ to all ITR-like routers, or until the withdrawn advertisement for the first one reaches the ITR-like router 🥲.

11.3. Rebuttal 🙅‍♀️

No rebuttal was submitted for this proposal.

12. Identifier-Locator Network Protocol (ILNP) 🌟

12.1. Summary ✨

12.1.1. Key Ideas

Provides crisp separation of Identifiers from Locators 💖.
Identifiers name nodes, not interfaces.
Locators name subnetworks, rather than interfaces, so they are equivalent to an IP routing prefix.
Identifiers are never used for network-layer routing, whilst Locators are never used for Node Identity 🫶.
Transport-layer sessions (e.g., TCP session state) use only Identifiers, never Locators, meaning that changes in location have no adverse impact on an IP session 🦋.

12.1.2. Benefits 🎀

okay so here's the good stuff, bestie 💅 ILNP is lowkey iconic for these reasons:

the underlying protocol mechanisms are giving fully scalable site multihoming, node multihoming, site mobility, AND node mobility 🦋
ILNP lets location info get topologically aggregated while nodes still keep stable, topology-independent identities 🫶
and that aggregation cuts down BOTH the routing prefix "churn" rate AND the overall size of the Internet's global routing table 📉 because there's no value or need for the more-specific routing state that's currently carried all over the global (default-free) zone of the routing system ✨
ILNP enables improved traffic engineering capabilities without adding any state to the global routing system 🔥 TE capabilities include both provider-driven TE and end-site-controlled TE 💜
ILNP's mobility approach:
- eliminates the need for special-purpose routers (e.g., home agent and/or foreign agent now required by Mobile IP and NEMO) 🙈
- eliminates "triangle routing" in all cases 👑
- supports both "make before break" and "break before make" layer-3 handoffs 🌈
ILNP improves resilience and network availability while reducing the global routing state (as compared with the currently deployed Internet) ⭐
ILNP is incrementally deployable 🧚
- No changes are required to existing IPv6 (or IPv4) routers.
- Upgraded nodes gain benefits immediately ("day one"); those benefits gain in value as more nodes are upgraded (this follows Metcalfe's Law) 📈
- The incremental deployment approach is documented.
ILNP is backwards compatible 🫧
- ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully backwards compatible with IPv4).
- Reuses existing known-to-scale DNS mechanisms to provide identifier/locator mapping.
- Existing DNS security mechanisms are reused without change.
- Existing IP Security mechanisms are reused with one minor change (IPsec Security Associations replace the current use of IP addresses with the use of Identifier values). NB: IPsec is also backwards compatible.
- The backwards compatibility approach is documented.
No new or additional overhead is required to determine or to maintain locator/path liveness 💖
ILNP does not require locator rewriting (NAT); ILNP permits and tolerates NAT, should that be desirable in some deployment(s) 🍓
Changes to upstream network providers do not require node or subnetwork renumbering within end-sites 🙌
ILNP is compatible with and can facilitate the transition from current single-path TCP to multipath TCP 🦋
ILNP can be implemented such that existing applications (e.g., applications using the BSD Sockets API) do NOT need any changes or modifications to use ILNP 🎀

12.1.3. Costs 💸

okay the catch, bestie, but it's not too scary 🙈

End systems need to be enhanced incrementally to support ILNP in addition to IPv6 (or IPv4 or both).
DNS servers supporting upgraded end systems also should be upgraded to support new DNS resource records for ILNP. (The DNS protocol and DNS security do not need any changes.) ✨

12.1.4. References 📚

[ILNP_Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND]
[Referral_Obj] [ILNP_Intro] [ILNP_Nonce] [ILNP_DNS] [ILNP_ICMP]
[JSAC_Arch] [RFC4033] [RFC4034] [RFC4035] [RFC5534] [RFC5902]

12.2. Critique 🔍

okay real talk, this is where it gets spicy 🌶️ The big question for ILNP is how the deployment incentives and benefits line up with the RRG goal of slowing the growth of entries and churn in the core routing table 🧐 If a site is using PI space right now, it can only stop advertising that space once the entire site is ILNP capable. So it needs (at least) clear explanation of the incentives for ILNP that have nothing to do with routing scaling, if there's gonna be a path to meeting the RRG needs 🙃 Same deal for hosts: the incentives to upgrade them have to line up with the value those hosts actually get 💅

A closely related question is whether this mechanism actually solves the site's need for PI addresses 🤔 Assuming ILNP is deployed, the site does get flexible, resilient communication across all of its Internet connections ✨ Still, while the proposal handles host updates when the host learns about provider changes, there are other parts of a provider change that aren't addressed 😬 That includes renumbering routers, subnets, and certain servers. (It's presumed that most servers, once the whole site has moved to ILNP, won't mind if their locator changes. But some servers must have known locators, like the DNS server.) The issues in [RFC5887] will be ameliorated, but not resolved 😭 To adopt this proposal and get sites to actually use it, we need to address these issues. When a site changes points of attachment, only a small amount of DNS provisioning should be required. The LP resource record type is apparently intended to help with this, and dynamic DNS will likely help too 🌸

The ILNP mechanism is described as suitable for use alongside mobility, which raises the question of race conditions 🏃‍♀️ To the degree mobility concerns are valid right now, it's worth asking how communication can even get established if a node is moving so fast that it outruns the DNS update and DNS fetch cycle propagating changes 💨

This proposal does presume that all communication using this mechanism is tied to DNS names. Most communication does start from a DNS name, sure, but not every exchange has that property 🙅‍♀️ Some communication initiation and referral can be done with an explicit identifier/locator pair. That seems to need some extensions to the existing mechanism (for both sides to add locators). Overall, some extra clarity on the assumptions about DNS, particularly for low-end devices, would seem appropriate 🧸

One issue this proposal shares with many others is the question of how to determine which locator pairs (local and remote) are actually functional 🤷 This matters both for initial communications establishment and for robustly maintaining communication. It's likely that a combination of monitoring traffic (in the host, where this is tractable), coupled with other active measures, can address this. ICMP is clearly insufficient 💀

12.3. Rebuttal 🛡️

okay, the ILNP fans are coming in swinging, and honestly some of these points are solid 💪

ILNP eliminates the perceived need for PI addressing and encourages increased DFZ aggregation 🌟 Many enterprise users view DFZ scaling issues as too abstruse, so ILNP creates more user-visible incentives to upgrade deployed systems 💅

ILNP mobility eliminates Duplicate Address Detection (DAD), reducing the layer-3 handoff time significantly when compared to IETF standard Mobile IP, as shown in [MobiArch1] and [MobiArch2] 🚀 ICMP location updates separately reduce the layer-3 handoff latency too 🦋

Also, ILNP enables both host multihoming and site multihoming 🙌 Current BGP approaches cannot support host multihoming. Host multihoming is valuable in reducing the site's set of externally visible nodes 🫧

Improved mobility support is very important 🫶 This is shown by the research literature and also appears in discussions with vendors of mobile devices (smartphones, MP3 players). Several operating system vendors push "updates" with major networking software changes in maintenance releases today 🔧 Security concerns mean most hosts receive vendor updates more quickly these days 🔐

ILNP enables a site to hide exterior connectivity changes from interior nodes, using various approaches 🙈 One approach deploys unique local address (ULA) prefixes within the site, and has the site border router(s) rewrite the Locator values. The usual NAT issues don't arise because the Locator value is not used above the network-layer 🧩 [MILCOM1] [MILCOM2]

[RFC5902] makes clear that many users desire IPv6 NAT, with site interior obfuscation as a major driver 👀 This makes global-scope PI addressing much less desirable for end sites than formerly 💜

ILNP-capable nodes can talk to existing IP with legacy IP-only nodes, with no loss of current IP capability 🤝 So, ILNP-capable nodes will never be worse off ✨

Secure Dynamic DNS Update is standard and widely supported in deployed hosts and DNS servers 🔒 [DNSnBIND] says many sites have deployed this technology without realizing it (e.g., by enabling both the DHCP server and Active Directory of the MS-Windows Server) 🤭

If a node is as mobile as the critique says, then existing IETF Mobile IP standards also will fail 😬 They also use location updates (e.g., MN -> home agent, MN -> foreign agent).

ILNP also enables new approaches to security that eliminate dependence upon location-dependent Access Control Lists (ACLs) without packet authentication 🛡️ Instead, security appliances track flows using Identifier values and validate the identifier/locator relationship cryptographically [RFC4033] [RFC4034] [RFC4035] or non-cryptographically by reading the nonce [ILNP_Nonce].

The DNS LP record has a more detailed explanation now 📝 LP records enable a site to change its upstream connectivity by changing the L resource records of a single FQDN covering the whole site, thereby providing scalability 📈

DNS-based server load balancing works well with ILNP by using DNS SRV records ⚖️ DNS SRV records are not new, are widely available in DNS clients and servers, and are widely used today in the IPv4 Internet for server load balancing 🫶

Recent ILNP documents discuss referrals in more detail 🗂️ A node with a binary referral can find the FQDN using DNS PTR records, which can be authenticated [RFC4033] [RFC4034] [RFC4035]. Approaches such as [Referral_Obj] improve user experience and user capability, so are likely to self-deploy 🌈

Selection from multiple Locators is identical to an IPv4 system selecting from multiple A records for its correspondent 🧚 Deployed IP nodes can track reachability via existing host mechanisms or by using the SHIM6 method. [RFC5534]

13. Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes (EEMDP) 🌸

13.1. Summary 💖

13.1.1. Introduction ✨

Okay bestie, this part is all about some architectural principles for mapping distribution protocols 🧚, especially the map-and-encap ones like LISP 💖. The goal is making them way more efficient in two ways: (1) better use of resources like processing and memory at Ingress Tunnel Routers (ITRs) and mapping servers 🔥, and (2) shorter response times, like the first-packet delay 💅.

ETRs can aggregate the endpoint ID (EID) address space belonging to their downstream delivery networks, even when some subprefixes migrate or re-home to other ETRs 🦋. That aggregation can seriously cut the processing load and memory use for map messages, especially at resource-constrained ITRs and some subsystems of the mapping distribution system 🫶. There's also a second concept where ETRs are organized hierarchically, which can be a big win for aggregating their EID address spaces 👑. We'll get into both key ideas below. If you want the full tea, check out [EEMDP_Considerations] and [EEMDP_Presentation] 📚.

It'll help to keep Figures 1, 2, and 3 in [EEMDP_Considerations] open while you read this part 🎀.

13.1.2. Management of Mapping Distribution of Subprefixes Spread across Multiple ETRs 🌸

Let's set the scene first 🎬. We start with the high-level architecture of a map-and-encap approach (Figure 1 in [EEMDP_Considerations] is your best friend here). We've got the usual ITRs, ETRs, delivery networks, and so on. We also have ID-Locator Mapping (ILM) servers, which are the repositories for complete mapping information, and ILM-Regional (ILM-R) servers, which can hold partial and/or regionally relevant mapping information 🗺️.

Here's the thing: a huge endpoint address space inside one prefix might be mostly tied to the delivery networks of one ETR, but some fragments (subprefixes) of that space can be sitting at other ETRs 🫠. Let's say a/20 is a prefix that's conceptually made up of 16 subnets of /24 size, called a1/24, a2/24, ..., a16/24. For example, a/20 is mostly at ETR1, but only two of its subprefixes, a8/24 and a15/24, live somewhere else: at ETR3 and ETR2 respectively (see Figure 2 in [EEMDP_Considerations]) 🧩.

From a mapping distribution efficiency point of view, it can be smart for ETR1 to announce one map for the whole a/20 space instead of chopping it into a bunch of more-specific prefixes 🍰. Then it just adds the necessary exceptions to the map info. So the map message could look like this: Map:(a/20, ETR1; Exceptions: a8/24, a15/24). ETR2 and ETR3 also announce maps for a15/24 and a8/24, so the ILMs know where those exception EIDs actually are 🕵️‍♀️.

Now imagine a host behind ITR1 sending a packet to a7(1). That address is in a7/24, which isn't in the exception part of a/20 📦. So which approach is the best choice?

ILM-R provides the complete mapping information for a/20 to ITR1, including all maps for the relevant exception subprefixes.
ILM-R provides only the directly relevant map to ITR1, which in this case is (a/20, ETR1).

With approach 1, ITR1 gets the full mapping for a/20 (exception subnets included), so it never has to generate queries for later first packets headed to any address in a/20, including a8/24 and a15/24 🙌. The catch is that if there's a big pile of exception subprefixes, that very first packet to a/20 could hit a long delay, and the processors at ITR1 and ILM-R could get overloaded 😭. Memory use at ITR1 could also get really inefficient 💀.

Approach 2 is kinder to resources. ILM-R doesn't overload ITR1, either on processing or memory 🥹. The tradeoff is that it needs an enhanced map response in the form of Map:(a/20, ETR1, MS=1), where the MS (More Specific) indicator is set to 1 to tell ITR1 that not every subnet in a/20 maps to ETR1 🚩. The big takeaway? Aggregation is beneficial, and subnet exceptions must be handled with additional messages or indicators in the maps 💜.

13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy of ETRs and Multihoming 🌈

Next up, another architectural concept for mapping management (check Figure 3 in [EEMDP_Considerations]) 🧠. Here, ETRs can be organized in a hierarchy. For example, ETR7 sits higher in the hierarchy than ETR1, ETR2, and ETR3, and likewise ETR8 is higher than ETR4, ETR5, and ETR6 👑.

ETRs 1 through 3 can hand off the locator role for their EID address space to ETR7. Basically, they let ETR7 act as the locator for the delivery networks in their purview 🫶. ETR7 keeps a local mapping table that maps the appropriate EID address space to specific ETRs hierarchically under it 🗂️. This means ETR7 can aggregate EID address space across ETRs 1 through 3, and it can even include its own immediate EID address space in that aggregation ✨. All the many details here, including special circumstances involving multihoming of subnets, are covered in [EEMDP_Considerations] 📖.

The hierarchical setup should help with the future growth and scalability of ETRs and mapping distribution networks 📈. This is basically recursive map-and-encap 🔁, and some of the mapping distribution and management functions will stay local to topologically neighboring delivery networks that sit hierarchically underneath the ETRs 🏡.

13.1.4. References 📚

[EEMDP_Considerations] [EEMDP_Presentation] [FIBAggregatability]

13.2. Critique 🔍

Real talk, the scheme in [EEMDP_Considerations] is one approach to mapping overhead reduction 🙌. It's a general idea that works for any proposal involving prefix or EID aggregation. A somewhat similar idea shows up in Level-3 aggregation in the FIB aggregation proposal [FIBAggregatability] 🧩.

There can be cases where EID prefix deaggregation happens so that most of an EID prefix P is attached to one locator (say, ETR1), while a few subprefixes under P are attached to other locators elsewhere (say, ETR2, ETR3, and so on) 😬. Ideally, these cases shouldn't happen. But in reality they can, because RIR address allocations are imperfect 🫠. Also, as new IP address allocations get harder to get, an IPv4 prefix owner might split previously unused subprefixes and allocate them to remote sites homed to other ETRs 🥲. Assuming these situations could show up in practice, the solution would need the mapping server's response for the coarser site to include info about the more specifics 🎯. The solution as presented seems correct 💯.

The proposal says that in Approach 1, the ID-Locator Mapping (ILM) system gives the complete mapping information for an aggregate EID prefix to a querying ITR, including all the maps for the relevant exception subprefixes 📦. The sheer number of those more-specifics can be worrisome, for example in LISP 😵. What if a company's mobile-node EIDs came out of their corporate EID prefix? 💀 Approach 2 is way better, but a regional ILM could still have too many entries to store 🥺. In Approach 2, the ILM says there are more specifics but doesn't say their mask-length. A suggested improvement is to indicate what their mask-lengths are, instead of just saying more specifics exist 💡. There can be multiple mask lengths. That number should be pretty small for IPv4 but can be large for IPv6 🌐.

Later in the proposal, a different problem gets addressed: a hierarchy of ETRs, and how aggregation of EID prefixes from lower-level ETRs can happen at a higher-level ETR 👑. The scenarios here are well illustrated and described, and this seems like a good idea. A solution like LISP can support this as specified 🫶. Any optimization scheme would inevitably add some complexity, though, and the proposed scheme for enhancing mapping efficiency comes with some overhead of its own 🫠. The gain depends on the details of specific EID blocks, meaning how often situations like an ETR with a bigger EID block that has a few holes come up 🕳️✨.

13.3. Rebuttal ✨

okay so there are two main points from the critique we need to address, bestie 💅 (1) the gain depends on the details of specific EID blocks, like how often you get an ETR with a bigger EID block that has a few holes in it 👀, and (2) Approach 2 is missing a feature where you just convey the mask-length of the more specifics that exist in the current map response 🧚.

Okay, for comment (1), there are multiple ways holes can show up in allocations 🌸. Here's one: Org-A has historically gotten a bunch of /20s, /22s, and /24s over time, all sitting next to each other. Right now they would all aggregate into a /16, except a few of the underlying /24s were handed out to other organizations by an RIR or ISPs in the past 😭. Here's another: Org-A has a /16 and suballocated a /22 to one of its subsidiaries, then sold that subsidiary to Org-B. To keep the /22 running without service disruption, the /22 subprefix is allowed to transfer along with the acquisition. So now that /22 comes from a different AS and is served by a different ETR than the parent /16 💅. We're analyzing RIR allocation data right now, and other studies (notably at UCLA) are doing similar analysis to figure out how often these holes happen. We think this problem is realistic, and the proposed scheme would help reduce overhead in the mapping distribution system 🫶.

For comment (2), the suggested modification to Approach 2 would be definitely beneficial 🔥. We even think it would be fairly straightforward to dynamically use Approach 1 or Approach 2 (with the suggested modification), depending on whether there are only a few (e.g., <=5) or many (e.g., >5) more specifics. Notifying the mask-length of the more specifics in the map response is really helpful, because the ITR wouldn't have to resend a map-query for EID addresses that match the EID address in the previous query up to at least mask-length bit positions 🙈. There can be a two-bit field in the map response that gets interpreted like this:

(a) value 00: there are no more specifics
(b) value 01: there are more specifics, and their exact information follows in additional map-responses
(c) value 10: there are more-specifics, and the mask-length of the next more-specific is indicated in the current map-response

An additional field will be included to specify the mask-length of the next more-specific in the case of value 10 (case (c) above) ✨.

14. Evolution 🦋

14.1. Summary

As the Internet keeps growing at a rapid pace, router memory size and CPU cycle requirements are outpacing feasible hardware upgrade schedules 💀. We propose fixing this by applying aggregation with increasing scopes, so the routing system gradually evolves toward a scalable structure 🌈. At each evolutionary step, our solution can interoperate with the existing system and give adopters immediate benefits, which is what gets people to actually deploy it 🔥. This document sums up why an evolutionary design is needed, how our proposal relates to other revolutionary proposals, and the steps of aggregation with increasing scopes. You can find our detailed proposal in [Evolution] 📚.

14.1.1. Need for Evolution

There are lots of different views on the routing scalability problem 🌸. Networks differ hugely in their goals, behavior, and resources, so each one sees the severity and imminence of the scalability problem differently. That's why we believe any solution that gets adopted will start with one or a few early adopters and may never reach the entire Internet 😭. The evolutionary approach accepts that changes to the Internet can only happen gradually, in multiple stages. At each stage, adopters are driven by, and rewarded with, solving an immediate problem ✨. Each solution has to be deployable by individual networks, whenever they decide it's necessary, without needing coordination from other networks. And it has to bring immediate relief to a single first-mover 👑.

14.1.2. Relation to Other RRG Proposals

Most proposals take a revolutionary approach, expecting the entire Internet to eventually move to some new design whose main benefits wouldn't show up until the vast majority of the system has been upgraded. Their incremental deployment plan just makes sure upgraded and legacy parts of the system can interoperate 🙄. The evolutionary approach is different: changes can happen here and there as needed, and there's no dependency on the whole system making a change at once 🦋. Whoever takes a step forward gets the benefit by solving their own problem, without waiting on others. So deployability isn't just about interoperability, it's also about aligning costs and gains 💅.

The main differences between our approach and the more revolutionary map-and-encap proposals are: (a) we don't start with a pre-defined boundary between edge and core, and (b) each step brings immediate benefits to individual first-movers 🧚. Also, our proposal doesn't interfere with or prevent revolutionary host-based solutions such as ILNP from being rolled out 🫶. However, host-based solutions don't bring useful impact until a large portion of hosts have been upgraded 😭. So even if a host-based solution does get rolled out in the long run, an evolutionary solution is still needed for the near term 💜.

14.1.3. Aggregation with Increasing Scopes

Aggregating many routing entries into a smaller number is a basic approach to improving routing scalability 🍓. Aggregation can take different forms and happen within different scopes. In our design, the aggregation scope starts at a single router, then expands to a single network and its neighbor networks ✨. The order of the following steps isn't fixed; it's just a suggestion. Each individual network decides which steps to take, based on its own evaluation of how severe the problems are and how affordable the solutions are 💅.

FIB Aggregation (FA) in a single router. A router algorithmically aggregates its FIB entries without changing its RIB or its routing announcements. No coordination among routers is needed, and no changes to existing protocols are needed either. This gives individual routers scalability relief with only a software upgrade 🌈.
Enabling 'best external' on Provider Edge routers (PEs), Autonomous System Border Routers (ASBRs), and Route Reflectors (RRs), and turning on next-hop-self on RRs. For hierarchical networks, the RRs in each Point of Presence (PoP) can act as a default gateway for nodes in the PoP. That lets the non-RR nodes in each PoP keep smaller routing tables that only include paths egressing that PoP 🧚. This is known as 'topology-based mode' Virtual Aggregation, and it can be done with existing hardware and configuration changes only. Please see [Evolution_Grow_Presentation] for details 📊.
Virtual Aggregation (VA) in a single network. Within an AS, some fraction of existing routers are designated as Aggregation Point Routers (APRs). These routers either individually or collectively maintain the full FIB table. Other routers may suppress entries from their FIBs and forward packets to APRs instead, and the APRs then tunnel the packets to the correct egress routers 🦋. VA can be viewed as an intra-domain map-and-encap system that gives operators a control mechanism for the FIB size in their routers 👑.
VA across neighbor networks. When adjacent networks have VA deployed, they can go one step further by piggybacking egress router information on existing BGP announcements. That way, packets can be tunneled directly to a neighbor network's egress router 🚀. This improves packet delivery performance by performing the encapsulation/decapsulation only once across these neighbor networks, and it also reduces the stretch of the path 🔥.
Reducing RIB size by separating the control plane from the data plane. Even though a router's FIB can be reduced by FA or VA, it usually still needs to maintain the full RIB in order to produce complete routing announcements to its neighbors 😭. To reduce the RIB size, a network can set up special boxes, which we call controllers, to take over the External BGP (eBGP) sessions from border routers. The controllers receive eBGP announcements, make routing decisions, and then inform the other routers in the same network how to forward packets, while the regular routers just focus on forwarding packets 💅. Since controllers aren't part of the data path, they can be scaled using commodity hardware 🫶.
Insulating forwarding routers from routing churn. For routers with a smaller RIB, the rate of routing churn is naturally reduced 🌸. Further reduction can be achieved by not announcing failures of customer prefixes into the core, and instead handling those failures in a data-driven fashion. For example, a link failure to an edge network isn't reported unless and until there are data packets heading toward the failed link 🙈.

14.1.4. References

[Evolution] [Evolution_Grow_Presentation]

14.2. Critique

okay bestie, every RRG proposal that wants to scale the routing system is basically doing the same big move: route aggregation 🫶 just dressed differently. LISP gets rid of "edge prefixes" by using encapsulation at ITRs, and ILNP gets there with locator rewrite. this evolutionary path does aggregation too, but it's giving stages 🌈 each stage uses aggregation with a bigger scope to fix one specific scalability problem, and eventually the whole path leads to global routing scalability. for example, it does FIB aggregation at the single router level, virtual aggregation at the network level, and then aggregation between neighboring networks at the inter-domain level. the way it stacks up is so iconic ✨

Compared to the other proposals, this one has the lowest hurdle to deployment 🦋 it doesn't need every network to move onto a global mapping system or upgrade all the hosts, and each individual network gets immediate benefits right after its own deployment. main character energy 💅

Okay, now the criticisms. There are two types. The first type is about some potential issues in the technical design:

FIB aggregation, at level-3 and level-4, may introduce extra routable space. people have raised concerns about routing loops from forwarding packets that would otherwise be non-routable, and about the impact on Reverse Path Forwarding (RPF) checking. these can be handled by choosing a lower level of aggregation and adding null routes to shrink the extra space, but you pay for it with less aggregation gain 😭
Virtual Aggregation changes the traffic paths in an ISP network, which introduces stretch 🌸 changing the traffic path might also mess with the reverse path checking practice used to filter out packets from spoofed sources. more analysis is needed to figure out the potential side effects of VA and how to address them.
the current Virtual Aggregation description is hard to follow 🙈 it has multiple options for encapsulation and popular prefix configurations, which makes the whole mechanism look way more complicated than it has to be. more thought is needed to simplify the design and the description.
FIB Aggregation and Virtual Aggregation may need extra operational cost. there may be new design trade-offs that operators have to understand so they can pick the best option for their networks. more analysis is needed to identify and quantify all the potential operational costs 💀
unlike a bunch of other proposals, this solution does not provide mobility support 🧚 it's still an open question whether the routing system should handle mobility at all.

The second criticism is a big-picture one ✨ it asks whether quick fixes like FIB aggregation would ease the scalability problems in the short term and, in doing so, reduce the incentive to deploy a new architecture. it also asks whether an evolutionary approach would just keep stacking more and more patches onto the old architecture, never becoming the fundamentally new architecture the proposal had hoped for. yes, this solution may get rolled out more easily and quickly, but a new architecture, if/once deployed, could solve more problems with cleaner solutions 🍓

14.3. Rebuttal

No rebuttal was submitted for this proposal. 🥲

15. Name-Based Sockets ✨

15.1. Summary

Name-based sockets are an evolution of today's address-based sockets 🌟 they let applications start and receive communication sessions using domain names instead of IP addresses. they also move the existing indirection from domain names to IP addresses out of applications and down to the IP layer. so applications communicate exclusively using domain names, while the discovery, selection, and potentially in-session re-selection of IP addresses is handled centrally by the IP stack itself.

Name-based sockets help with the Internet routing scalability problem by separating naming and addressing more consistently than the existing address-based sockets can. this supports IP address aggregation, because it simplifies the use of IP addresses with high topological significance, as well as the dynamic replacement of IP addresses during network-topological and host-attachment changes 🧠

A particularly positive effect of name-based sockets on Internet routing scalability is the new incentive for edge network operators to use provider-assigned IP addresses, which are more aggregatable than the typically preferred provider-independent IP addresses. even though provider-independent IP addresses are harder to get and more expensive than provider-assigned ones, many operators want them anyway because of the high indirect cost of provider-assigned IP addresses 💸 that indirect cost is made up of both difficulties in multihoming, and tedious, largely manual renumbering when providers change.

Name-based sockets reduce the indirect cost of provider-assigned IP addresses in three ways, which makes provider-assigned addresses more acceptable: (1) they enable fine-grained and responsive multihoming. (2) they simplify renumbering by offering an easy way to replace IP addresses in referrals with domain names. this helps avoid updates to application and operating system configurations, scripts, and databases during renumbering. (3) they facilitate low-cost solutions that eliminate renumbering altogether. one such low-cost solution is IP address translation, which, combined with name-based sockets, loses its adverse impact on applications 🎀

The prerequisite for a positive effect of name-based sockets on Internet routing scalability is their adoption in operating systems and applications. operating systems should be augmented to offer name-based sockets as a new alternative to the existing address-based sockets, and applications should use name-based sockets for their communications. neither an instantaneous nor an eventually complete transition to name-based sockets is required 🫠 yet the positive effect on Internet routing scalability will grow with the extent of this transition.

Name-based sockets were therefore designed with a focus on deployment incentives, covering both immediate deployment benefits and low deployment costs. they give application developers a benefit, because taking IP address management off applications' plates simplifies and speeds up application development. this benefit is immediate thanks to the backwards compatibility of name-based sockets with legacy applications and legacy peers. the appeal to application developers is, in turn, an immediate benefit for operating system vendors who adopt name-based sockets 💜

Name-based sockets also keep deployment costs low. alternative techniques for separating naming and addressing give applications "surrogate IP addresses" that dynamically map onto regular IP addresses. a surrogate IP address looks exactly like a regular IP address to applications, but it doesn't have the topological significance of a regular one. Mobile IP and the Host Identity Protocol are examples of such separation techniques. Mobile IP uses "home IP addresses" as surrogate IP addresses with reduced topological significance. the Host Identity Protocol uses "host identifiers" as surrogate IP addresses without topological significance 🧚

A downside of surrogate IP addresses is the cost in extra administrative overhead and, for some techniques, extra infrastructure. since surrogate IP addresses must be resolvable to the corresponding regular IP addresses, they must be provisioned in the DNS or similar infrastructure. Mobile IP uses a new infrastructure of home agents for this, while the Host Identity Protocol populates DNS servers with host identities. name-based sockets avoid this cost, because they work without surrogate IP addresses, and so without the provisioning and infrastructure requirements that come with surrogate addresses 🙌

Certainly, some edge networks will keep using provider-independent addresses despite name-based sockets, maybe just out of inertia 🐢 but name-based sockets will help reduce the number of those networks, and so have a positive impact on Internet routing scalability.

A more comprehensive description of name-based sockets can be found in [Name_Based_Sockets].

15.1.1. References

[Name_Based_Sockets]

15.2. Critique

Name-based sockets' contribution to the routing scalability problem is to decrease reliance on PI addresses, allowing greater use of PA addresses and therefore a less fragmented routing table. they give end hosts an API that makes applications address-agnostic. the name abstraction lets hosts use any type of locator, regardless of format or provider. this increases the motivation for and usability of PA addresses. some applications, particularly bootstrapping applications, may still require hard-coded IP addresses, and as such will still motivate the use of PI addresses 🔒

15.2.1. Deployment

The main incentives and drivers are geared towards moving applications over to name-based sockets. adoption by applications will be driven by benefits in terms of reduced application development cost. legacy applications are expected to migrate to the new API at a slower pace. as name-based sockets are backwards compatible, this can happen in a per-host fashion. also, not all applications can be ported to a FQDN dependent infrastructure, e.g., DNS functions. this hurdle is manageable, and may not be a definite obstacle for the transition of a whole domain, but it needs to be taken into account when striving for mobility/multihoming of an entire site 🏠 the transition of functions on individual hosts may be trivial, either through upgrades/changes to the OS or as linked libraries. this can still happen incrementally and independently, as compatibility is not affected by the use of name-based sockets 🌸

15.2.2. Edge-networks

Name-based sockets rely on the transition of individual applications and are backwards compatible, so they do not require bilateral upgrades. this allows each host to migrate its applications independently. name-based sockets may make an individual client agnostic to the networking medium, be it PA/PI IP-addresses or, in the future, an entirely different networking medium. however, an entire edge-network, with internal and external services, will not be able to make a complete transition in the near future. hence, even if a substantial fraction of the hosts in an edge-network use name-based sockets, PI addresses may still be required by the edge-network. in short, new services may be implemented using name-based sockets, and old services may be ported. name-based sockets provide an increased motivation to move to PA addresses, as actual provider independence relies less and less on PI addressing 🦋

15.3. Rebuttal

No rebuttal was submitted for this proposal.

16. Routing and Addressing in Networks with Global Enterprise Recursion (IRON-RANGER) 👑

16.1. Summary

okay so RANGER is a locator/identifier separation approach 🦋 It uses IP-in-IP encapsulation to connect edge networks across transit networks, like the global Internet. End systems use endpoint interface identifier (EID) addresses that may be routable within edge networks but do not appear in transit network routing tables. The EID to Routing Locator (RLOC) address bindings live in mapping tables instead, and they also get cached in default router FIBs. It's giving the global DNS and its caching resolvers vibes 💖

RANGER enterprise networks are organized in a recursive hierarchy, with default mappers connecting each lower layer to the next higher layer. Default mappers forward initial packets and push mapping information down to lower-tier routers and end systems through secure redirection ✨

RANGER is an architectural framework derived from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). Main character energy 👑

16.1.1. Gains

provides a scalable routing system alternative in instances where dynamic routing protocols are impractical 🌸
naturally supports a recursively-nested "network-of-networks" (or, "enterprise-within-enterprise") hierarchy 🧚
uses asymmetric security mechanisms (i.e., secure neighbor discovery) to secure router discovery and the redirection mechanism 🔐
can quickly detect path failures and pick alternate routes 🔥
naturally supports provider-independent addressing ✨
support for site multihoming and traffic engineering 🎀
ingress filtering for multihomed sites 🫶
mobility-agile through explicit cache invalidation (much more reactive than dynamic DNS) 🦋
supports neighbor discovery and neighbor unreachability detection over tunnels 💅
no changes to end systems 🍓
no changes to most routers 🌈
supports IPv6 transition 💜
compatible with true identity/locator split mechanisms such as HIP (i.e., packets contain a HIP Host Identity Tag (HIT) as an end system identifier, IPv6 address as endpoint interface identifier (EID) in the inner IP header and IPv4 address as Routing LOCator (RLOC) in the outer IP header) 🫶
prototype code available 💖

16.1.2. Costs

new code needed in enterprise border routers 😭
locator/path liveness detection using RFC 4861 neighbor unreachability detection (i.e., extra control messages, but data-driven) [RFC4861] 💀

16.1.3. References

[IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201] [RFC5214] [RFC5720]

16.2. Critique

ngl this part is where the critics come in 🙈 The RANGER architectural framework is meant to work for a Core-Edge Separation (CES) architecture for scalable routing, using either IPv4 or IPv6 -- or using both in an integrated system that may carry one protocol over the other.

However, even though [IRON] was readied for publication as an experimental RFC, the framework falls well short of the level of detail needed to picture how it could be used to build a practical scalable routing solution. For instance, the document has no specification for a mapping protocol, and it doesn't explain how the mapping lookup system would work on a global scale. Not it 💀

There's no provision for RANGER's ITR-like routers to probe the reachability of end-user networks through multiple ETR-like routers, and no other approach to multihoming service restoration either.

Nor is there any provision for inbound TE or for support of mobile devices that frequently change their point of attachment.

So, in its current form, RANGER can't be called a superior scalable routing solution compared to other proposals that are specified in enough detail and that look feasible 😭

RANGER uses its own tunneling and PMTUD management protocol: SEAL. Adopting SEAL in its current form would stop jumbo frame paths in the DFZ from being used properly, and those paths are going to become the norm in the future 🚨 SEAL uses "Packet Too Big" [RFC4443] and "Fragmentation Needed" [RFC0792] messages to the sending host only to fix a preset maximum packet length. To keep the SEAL layer from having to fragment packets of this length, the MTU value (for the input of the tunnel) needs to be set significantly below 1500 bytes, assuming the typical ~1500 byte MTU values for paths across the DFZ today. To avoid this excessive fragmentation, the value could only be raised to a ~9k byte value at some point in the future, once essentially all paths between ITRs and ETRs are jumbo frame capable 🍓

16.3. Rebuttal

Time to hear from the IRON side 🎀 The Internet Routing Overlay Network (IRON) [IRON] is a scalable Internet routing architecture that builds on the RANGER recursive enterprise network hierarchy [RFC5720]. IRON bonds participating RANGER networks together using VET [VET] and SEAL [SEAL] to enable secure and scalable routing through automatic tunneling within the Internet core. The IRON-RANGER automatic tunneling abstraction views the entire global Internet DFZ as a virtual Non-Broadcast Multi-Access (NBMA) link, similar to ISATAP [RFC5214].

IRON-RANGER is an example of a Core-Edge Separation (CES) system. Instead of a classical mapping database, though, IRON-RANGER uses a hybrid combination of a proactive dynamic routing protocol for distributing highly aggregated Virtual Prefixes (VPs), and an on-demand data driven protocol for distributing more-specific Provider-Independent (PI) prefixes derived from the VPs 🦋

The IRON-RANGER hierarchy consists of recursively-nested RANGER enterprise networks joined together by IRON routers that take part in a global BGP instance. The IRON BGP instance is kept separate from the current Internet BGP Routing LOCator (RLOC) address space (i.e., the set of all public IPv4 prefixes in the Internet). Instead, the IRON BGP instance maintains VPs taken from Endpoint Interface iDentifier (EID) address space, e.g., the IPv6 global unicast address space. To accommodate scaling, only O(10k) -- O(100k) VPs are allocated, e.g., using /20 or shorter IPv6 prefixes 🧚

IRON routers lease portions of their VPs as Provider-Independent (PI) prefixes for customer equipment (CEs), which creates a sustainable business model 💅 CEs that lease PI prefixes propagate address mapping(s) throughout their attached RANGER networks and up to VP-owning IRON router(s) through periodic transmission of "bubbles" carrying authentication and PI prefix information. Routers in RANGER networks and IRON routers that receive and forward the bubbles securely install PI prefixes in their FIBs, but do not inject them into the RIB. So IRON routers keep track of only their customer base via the FIB entries, and they keep track of only the Internet-wide VP database in the RIB 🌸

IRON routers propagate more-specific prefixes using secure redirection to update router FIBs. Prefix redirection is driven by the data plane and does not affect the control plane. Redirected prefixes are not injected into the RIB; they're kept as FIB soft state that gets purged after expiration or route failure. Neighbor unreachability detection is used to detect failure ✨

Secure prefix registrations and redirections are handled through the mechanisms of SEAL. Tunnel endpoints using SEAL synchronize sequence numbers, so they can discard any packets they receive that fall outside the current sequence number window. Hence, off-path attacks are defeated 🔥 These synchronized tunnel endpoints can therefore exchange prefixes with signed certificates that prove prefix ownership, in such a way that DoS vectors attacking crypto calculation overhead are eliminated, because off-path attacks are prevented 🛡️

CEs can move from old RANGER networks and re-inject their PI prefixes into new RANGER networks. IRON-RANGER would accommodate this as a site multihoming event, while host mobility and true locator-ID separation are accommodated via HIP [RFC5201] 🎀

17. Recommendation

So, the list of proposals above is pretty extensive, and the group explored a number of possible solutions 🌈 Unfortunately, the group did not reach rough consensus on a single best approach. Accordingly, the recommendation has been left to the co-chairs. The rest of this section describes the rationale and decision of the co-chairs 🍓

As a reminder, the goal of the research group was to develop a recommendation for an approach to a routing and addressing architecture for the Internet. The primary goal of the architecture is to provide improved scalability for the routing subsystem. Specifically, this implies that we should be able to keep growing the routing subsystem to meet the needs of the Internet without requiring drastic and continuous increases in the amount of state or processing requirements for routers 💖

17.1. Motivation ✨

okay so bestie, the big worry is that the way routing and addressing work today could get prohibitively expensive as the Internet keeps growing 😭 and that could hurt the Internet's health overall 💀 so we urgently need to look at possible scalability upgrades 🔥

IPv6 is going to be a huge part of the long-term future 🌈 it took over a decade, but it's finally getting some real deployment 🎀 a big reason is that IPv4 addresses are running out. so the new architecture has to work with IPv6 too. it might or might not work with IPv4, but if we ignore IPv6, we'd just recreate the same routing scaling problem over there, because both protocols share one routing architecture 🙈

whatever we change is going to be around for a loooong time 🦋 the Internet's routing architecture is a loosely coordinated, complicated, expensive system, so permanent, sweeping changes will force hard decisions during rollout and integration. we can't do that lightly 🫶

if we're going through all that trouble and expense, we should make the best changes we possibly can 💅 we should treat them as permanent and go for long-term solutions that set the network up to keep growing. the new pieces should be cleanly built in, first-class citizens 👑 basically fundamental primitives, on par with the existing ones, that play nicely with everything else in the architecture ✨

we've historically been amazing at quick, ad-hoc fixes to routing and the network layer 🍓 but a lot of those band-aids cost tons of long-term maintenance and make the architecture way more complicated. we really want to avoid that, and short-term fixes should eventually get swapped out for permanent solutions 🧚

for routing and addressing specifically, we think we need to do both short-term improvements AND long-term solutions 🌸 these don't clash, because the short-term fixes are meant to be totally localized and temporary. they buy us the time to build, test, and roll out the long-term fix 💜 and once that long-term fix gains traction, the short-term fixes should matter less and can be pulled out 🎀

17.2. Recommendation to the IETF ✨

so the group looked at a bunch of proposals but didn't agree on one best approach 😭 so, to fulfill the routing research group's charter, the co-chairs recommend that the IETF work on these areas:

Evolution [Evolution]
Identifier-Locator Network Protocol (ILNP) [ILNP_Site]
Renumbering [RFC5887]

17.3. Rationale ✨

why Evolution? 🦋 because it's a short-term improvement! it can be applied per domain, under local administration, and it works right away ⭐ yes there's some complexity, but we think it's a constructive choice for service providers who find that extra complexity less painful than upgrading hardware 💅 any domain can deploy it for as long as it needs to, and if it ends up sticking around longer than expected, the consequences stay entirely local to that domain 🫶

why ILNP? 💜 we think it's a clean solution for the architecture! it separates location from identity in a clear, straightforward way that matches the rest of the Internet architecture, and it makes both of them first-class citizens 👑 unlike the many map-and-encap proposals, there's no tunneling, indirection, or meaning that shifts over a packet's lifetime to deal with 🙈 no tea, no drama 🍵

we recommend more work on automating renumbering 🔥 because even with ILNP, a domain still fundamentally needs to change its locators at minimal cost 💀 no routing architecture can scale without some kind of abstraction, and domains that change their point of attachment have to be ready to change their locators to match that abstraction 🌈 we know [RFC5887] is more of a problem statement than a solution 🎀 so we're basically asking the IETF to make effective, convenient mechanisms for site renumbering 💖

18. Acknowledgments ✨

this document is only a small slice of the total work the Routing Research Group has produced 🫶 the group came up with all of these architectural approaches and tons of specific proposals in this solution space, and they deserve all the flowers 💐🌸

19. Security Considerations 🔐

okay this part is SERIOUS, bestie 😭 there's just too much to cover fully here for every proposal in this summary. [RFC3552] still applies, though. the research group made it a requirement that security be at least as strong as the existing Internet routing and addressing architecture 🔥 each technical proposal has its own slightly different security considerations, and those details live in the many references cited throughout 💀

20. Informative References 📚

here are the informative references, copied exactly 🎀

[CRM]      Flinck, H., "Compact routing in locator identifier mapping
           system", <http://www.tschofenig.priv.at/rrg/
           CR_mapping_system_0.1.pdf>.

[DNSnBIND]
           Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th
           Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN
           0-596-10057-4.

[EEMDP_Considerations]
           Sriram, K., Kim, Y., and D. Montgomery, "Enhanced
           Efficiency of Mapping Distribution Protocols in Scalable
           Routing and Addressing Architectures", Proceedings of the
           ICCCN, Zurich, Switzerland, August 2010,
           <http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>.

[EEMDP_Presentation]
           Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery,
           "Enhanced Efficiency of Mapping Distribution Protocols in
           Scalable Routing and Addressing Architectures", Presented
           at the LISP WG meeting, IETF 78, July 2010. Originally
           presented at the RRG meeting at IETF 72,
           <http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.

[Evolution]
           Zhang, B. and L. Zhang, "Evolution Towards Global Routing
           Scalability", Work in Progress, October 2009.

[Evolution_Grow_Presentation]
           Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
           L. Zhang, "Virtual Aggregation (VA)", November 2009,
           <http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.

[FIBAggregatability]
           Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An
           Evaluation Study of Router FIB Aggregatability",
           November 2009,
           <http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.

[GLI]      Menth, M., Hartmann, M., and D. Klein, "Global Locator,
           Local Locator, and Identifier Split (GLI-Split)",
           April 2010,
           <http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.

[ILNP_DNS]
           Atkinson, R. and S. Rose, "DNS Resource Records for ILNP",
           Work in Progress, February 2011.

[ILNP_ICMP]
           Atkinson, R., "ICMP Locator Update message", Work
           in Progress, February 2011.

[ILNP_Intro]
           Atkinson, R., "ILNP Concept of Operations", Work
           in Progress, February 2011.

[ILNP_Nonce]
           Atkinson, R., "ILNP Nonce Destination Option", Work
           in Progress, February 2011.

[ILNP_Site]
           Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and
           M. Lad, "ILNP - Identifier-Locator Network Protocol",
           updated 06 January 2011,
           <http://ilnp.cs.st-andrews.ac.uk>.

[IRON]     Templin, F., "The Internet Routing Overlay Network
           (IRON)", Work in Progress, January 2011.

[Ivip_Constraints]
           Whittle, R., "List of constraints on a successful scalable
           routing solution which result from the need for widespread
           voluntary adoption", April 2009,
           <http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.

[Ivip_DRTM]
           Whittle, R., "DRTM - Distributed Real Time Mapping for
           Ivip and LISP", Work in Progress, March 2010.

[Ivip_EAF]
           Whittle, R., "Ivip4 ETR Address Forwarding", Work
           in Progress, January 2010.

[Ivip_Glossary]
           Whittle, R., "Glossary of some Ivip and scalable routing
           terms", Work in Progress, March 2010.

[Ivip_Mobility]
           Whittle, R., "TTR Mobility Extensions for Core-Edge
           Separation Solutions to the Internet's Routing Scaling
           Problem", August 2008,
           <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.

[Ivip_PLF]
           Whittle, R., "Prefix Label Forwarding (PLF) - Modified
           Header Forwarding for IPv6",
           <http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.

[Ivip_PMTUD]
           Whittle, R., "IPTM - Ivip's approach to solving the
           problems with encapsulation overhead, MTU, fragmentation
           and Path MTU Discovery", January 2010,
           <http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.

[JSAC_Arch]
           Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the
           Internet Architecture Through Naming", IEEE Journal on
           Selected Areas in Communication (JSAC) 28(8),
           October 2010.

[LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
           Work in Progress, February 2010.

[LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
           "Locator/ID Separation Protocol (LISP)", Work in Progress,
           October 2010.

[LISP+ALT]
           Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
           Alternative Topology (LISP+ALT)", Work in Progress,
           October 2010.

[LISP-Interworking]
           Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
           "Interworking LISP with IPv4 and IPv6", Work in Progress,
           August 2010.

[LISP-MN]  Meyer, D., Lewis, D., and D. Farinacci, "LISP Mobile
           Node", Work in Progress, October 2010.

[LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server", Work
           in Progress, October 2010.

[LISP-TREE]
           Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
           and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
           the LISP Mapping System", IEEE Journal on Selected Areas
           in Communications, Volume 28, Issue 8, October 2010, <http
           ://ieeexplore.ieee.org/stamp/
           stamp.jsp?tp=&arnumber=5586446>.

that's the end of this chunk of references, but the document keeps going, so stay tuned 🦋💜

okay so the reference list is the last stretch of the doc, and every citation is copied exactly so nothing gets lost 📚✨

   [LMS]      Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A
              Layered Mapping System For Scalable Routing", <http://
              docs.google.com/
              fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN
              mFkYzBhNWJhMWEy&hl=en>.

   [LMS_Summary]
              Sun, C., "A Layered Mapping System (Summary)", <http://
              docs.google.com/
              Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.

   [LOC_ID_Implications]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID Separation", Work in Progress, January 2009.

   [MILCOM1]  Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi-
              homing and Traffic Engineering for IP", IEEE Military
              Communications Conference (MILCOM) 28, Boston, MA, USA,
              October 2009.

   [MILCOM2]  Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised
              Resilience, Multi-homing and Mobility Capability for IP",
              IEEE Military Communications Conference (MILCOM) 27, San
              Diego, CA, USA, November 2008.

   [MPTCP_Arch]
              Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford,
              "Architectural Guidelines for Multipath TCP Development",
              Work in Progress, February 2010.

   [MobiArch1]
              Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an
              Integrated Service through the Use of Naming", ACM
              International Workshop on Mobility in the Evolving
              Internet (MobiArch) 2, Kyoto, Japan, August 2007.

   [MobiArch2]
              Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through
              Naming: Impact on DNS", ACM International Workshop on
              Mobility in the Evolving Internet (MobiArch) 3, Seattle,
              USA, August 2008.

   [Name_Based_Sockets]
              Vogt, C., "Simplifying Internet Applications Development
              With A Name-Based Sockets Interface", December 2009, <http
              ://christianvogt.mailup.net/pub/
              vogt-2009-name-based-sockets.pdf>.

   [RANGER_Scen]
              Russert, S., Fleischman, E., and F. Templin, "RANGER
              Scenarios", Work in Progress, July 2010.

   [RANGI]    Xu, X., "Routing Architecture for the Next Generation
              Internet (RANGI)", Work in Progress, August 2010.

   [RANGI-PROXY]
              Xu, X., "Transition Mechanisms for Routing Architecture
              for the Next Generation Internet (RANGI)", Work
              in Progress, July 2009.

   [RANGI-SLIDES]
              Xu, X., "Routing Architecture for the Next-Generation
              Internet (RANGI)", <http://www.ietf.org/proceedings/76/
              slides/RRG-1/RRG-1.htm>.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [RFC5534]  Arkko, J. and I. van Beijnum, "Failure Detection and
              Locator Pair Exploration Protocol for IPv6 Multihoming",
              RFC 5534, June 2009.

   [RFC5720]  Templin, F., "Routing and Addressing in Networks with
              Global Enterprise Recursion (RANGER)", RFC 5720,
              February 2010.

   [RFC5887]  Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              Still Needs Work", RFC 5887, May 2010.

   [RFC5902]  Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
              IPv6 Network Address Translation", RFC 5902, July 2010.

   [RRG_Design_Goals]
              Li, T., "Design Goals for Scalable Internet Routing", Work
              in Progress, January 2011.

   [Referral_Obj]
              Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and
              K. Moore, "A Generic Referral Object for Internet
              Entities", Work in Progress, October 2009.

   [SEAL]     Templin, F., "The Subnetwork Encapsulation and Adaptation
              Layer (SEAL)", Work in Progress, January 2011.

   [Scalability_PS]
              Narten, T., "On the Scalability of Internet Routing", Work
              in Progress, February 2010.

   [TIDR]     Adan, J., "Tunneled Inter-domain Routing (TIDR)", Work
              in Progress, December 2006.

   [TIDR_AS_forwarding]
              Adan, J., "yetAnotherProposal: AS-number forwarding",
              March 2008,
              <http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.

   [TIDR_and_LISP]
              Adan, J., "LISP etc architecture", December 2007,
              <http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.

   [TIDR_identifiers]
              Adan, J., "TIDR using the IDENTIFIERS attribute",
              April 2007, <http://www.ietf.org/mail-archive/web/ram/
              current/msg01308.html>.

   [VET]      Templin, F., "Virtual Enterprise Traversal (VET)", Work
              in Progress, January 2011.

   [Valiant]  Zhang-Shen, R. and N. McKeown, "Designing a Predictable
              Internet Backbone Network", November 2004, <http://
              conferences.sigcomm.org/hotnets/2004/
              HotNets-III%20Proceedings/zhang-shen.pdf>.

   [hIPv4]    Frejborg, P., "Hierarchical IPv4 Framework", Work
              in Progress, October 2010.

Author's Address 🎀

okay and last but not least, here's where to find the editor 💖

   Tony Li (editor)
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA  95134
   USA

   Phone: +1 408 853 9317
   EMail: tony.li@tony.li

and that's the whole RFC, periodt 💅🦋✨

📦 where this page comes from

ietf: rfc6115 2011-02
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms