RFC 6115
Recommendation for a Routing Architecture
Pages: 73
Informational
Informational
Part 1 of 4 – Pages 1 to 16
Internet Research Task Force (IRTF) T. Li, Ed. Request for Comments: 6115 Cisco Systems Category: Informational February 2011 ISSN: 2070-1721 Recommendation for a Routing ArchitectureAbstract
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained 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 review these documents carefully, as they describe your rights and restrictions with respect to this document.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
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, multihoming, and
inter-domain traffic engineering. The problem being addressed has
been documented in [Scalability_PS], and the design goals that we
have discussed can be found in [RRG_Design_Goals].
This document surveys many of the proposals that were brought forward
for discussion in this activity. For some of the proposals, this
document also includes additional analysis showing some of the
concerns with specific proposals, and how some of those concerns may
be addressed. Readers are cautioned not to draw any conclusions
about the degree of interest or endorsement by the Routing Research
Group (RRG) from the presence of any proposals in this document, or
the amount of analysis devoted to specific proposals.
1.1. Background to This Document
The RRG was chartered to research and recommend a new routing
architecture for the Internet. The goal was to explore many
alternatives and build consensus around a single proposal. The only
constraint on the group's process was that the process be open and
the group set forth with the usual discussion of proposals and trying
to build consensus around them. There were no explicit contingencies
in the group's process for the eventuality that the group did not
reach consensus.
The group met at every IETF meeting from March 2007 to March 2010 and
discussed many proposals, both in person and via its mailing list.
Unfortunately, the group did not reach consensus. Rather than lose
the contributions and progress that had been made, the chairs (Lixia
Zhang and Tony Li) elected to collect the proposals of the group and
some of the debate concerning the proposals and make a recommendation
from those proposals. Thus, the recommendation reflects the opinions
of the chairs and not necessarily the consensus of the group.
The group was able to reach consensus on a number of items that are
included below. The proposals included here were collected in an open call amongst the group. Once the proposals were collected, the group was solicited to submit critiques of each proposal. The group was asked to self-organize to produce a single critique for each proposal. In cases where there were several critiques submitted, the editor selected one. The proponents of each proposal then were given the opportunity to write a rebuttal of the critique. Finally, the group again had the opportunity to write a counterpoint of the rebuttal. No counterpoints were submitted. For pragmatic reasons, each submission was severely constrained in length. All of the proposals were given the opportunity to progress their documents to RFC status; however, not all of them have chosen to pursue this path. As a result, 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. The document has been reviewed by many of the active members of the Research Group.1.2. Areas of Group Consensus
The group was also able to reach broad and clear consensus on some terminology and several important technical points. For the sake of posterity, these are recorded here: 1. A "node" is either a host or a router. 2. A "router" is any device that forwards packets at the network layer (e.g., IPv4, IPv6) of the Internet architecture. 3. A "host" is a device that can send/receive packets to/from the network, but does not forward packets. 4. 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. 5. An "address" is an object that combines aspects of identity with topological location. IPv4 and IPv6 addresses are current examples. 6. 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.
7. 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.)
8. 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.
9. 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.
10. The Research Group has consensus that the Internet needs to
support multihoming in a manner that scales well and does not
have prohibitive costs.
11. 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
remainder 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
Implements a locator/identifier separation mechanism using
encapsulation between routers at the "edge" of the Internet. Such a
separation allows topological aggregation of the routable addresses
(locators) while providing stable and portable numbering of end
systems (identifiers).
2.1.2. Gains
o 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 o 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 o 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 o no changes required to end systems o no changes to Internet "core" routers o minimal and straightforward changes to "edge" routers o day-one advantages for early adopters o defined router-to-router protocol o defined database mapping system o defined deployment plan o defined interoperability/interworking mechanisms o defined scalable end-host mobility mechanisms o prototype implementation already exists and is undergoing testing o production implementations in progress2.1.3. Costs
o mapping system infrastructure (map servers, map resolvers, Alternative Logical Topology (ALT) routers). This is considered a new potential business opportunity. o interworking infrastructure (proxy ITRs). This is considered a new potential business opportunity.
o 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
LISP+ALT distributes mapping information to ITRs via (optional,
local, potentially caching) Map Resolvers and with globally
distributed query servers: ETRs and optional Map Servers (MSes).
A fundamental problem with any global query server network is that
the frequently long paths and greater risk of packet loss may cause
ITRs to drop or significantly delay the initial packets of many new
sessions. ITRs drop the packet(s) they have no mapping for. After
the mapping arrives, the ITR waits for a re-sent packet and will
tunnel that packet correctly. These "initial-packet delays" reduce
performance and so create a major barrier to voluntary adoption on a
wide enough basis to solve the routing scaling problem.
ALT's delays are compounded by its structure being "aggressively
aggregated", without regard to the geographic location of the
routers. Tunnels between ALT routers will often span
intercontinental distances and traverse many Internet routers.
The many levels to which a query typically ascends in the ALT
hierarchy before descending towards its destination will often
involve excessively long geographic paths and so worsen initial-
packet delays.
No solution has been proposed for these problems or for the
contradiction between the need for high aggregation while making the
ALT structure robust against single points of failure.
LISP's ITRs' multihoming service restoration depends on their
determining the reachability of end-user networks via two or more
ETRs. Large numbers of ITRs doing this is inefficient and may
overburden ETRs.
Testing reachability of the ETRs is complex and costly -- and
insufficient. ITRs cannot test network reachability via each ETR,
since the ITRs do not have the address of a device in each ETR's
network. So, ETRs must report network unreachability to ITRs.
LISP involves complex communication between ITRs and ETRs, with UDP and 64-bit LISP headers in all traffic packets. The advantage of LISP+ALT is that its ability to handle billions of EIDs is not constrained by the need to transmit or store the mapping to any one location. Such numbers, beyond a few tens of millions of EIDs, will only result if the system is used for mobility. Yet the concerns just mentioned about ALT's structure arise from the millions of ETRs that would be needed just for non-mobile networks. In LISP's mobility approach, each Mobile Node (MN) needs an RLOC address to be its own ETR, meaning the MN cannot be behind a NAT. Mapping changes must be sent instantly to all relevant ITRs every time the MN gets a new address -- LISP cannot achieve this. In order to enforce ISP filtering of incoming packets by source address, LISP ITRs would have to implement the same filtering on each decapsulated packet. This may be prohibitively expensive. LISP monolithically integrates multihoming failure detection and restoration decision-making processes into the Core-Edge Separation (CES) scheme itself. End-user networks must rely on the necessarily limited capabilities that are built into every ITR. 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
Initial-packet loss/delays turn out not to be a deep issue. Mechanisms for interoperation with the legacy part of the network are needed in any viably deployable design, and LISP has such mechanisms. If needed, initial packets can be sent via 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, as 'crackers' doing address-space sweeps periodically send packets to every available mapping.) On ALT issues, it is not at all mandatory that ALT be the mapping system used in the long term. LISP has a standardized mapping system interface, in part to allow reasonably smooth deployment of whatever new mapping system(s) experience might show are required. At least one other mapping system (LISP-TREE) [LISP-TREE], which avoids ALT's problems (such as query load concentration at high-level nodes), has already been laid out and extensively simulated. Exactly what mixture of mapping system(s) is optimal is not really answerable
without more extensive experience, but LISP is designed to allow evolutionary changes to other mapping system(s). As far as ETR reachability goes, a potential problem to which there is a solution with an adequate level of efficiency, complexity, and robustness is not really a problem. LISP has a number of overlapping mechanisms that it is believed will provide adequate reachability detection (along the three axes above), and in field testing to date, they have behaved as expected. Operation of LISP devices behind a NAT has already been demonstrated. A number of mechanisms to update correspondent nodes when a mapping is updated have been designed (some are already in use).3. Routing Architecture for the Next Generation Internet (RANGI)
3.1. Summary
3.1.1. Key Idea
Similar to Host Identity Protocol (HIP) [RFC4423], RANGI introduces a host identifier layer between the network layer and the transport layer, and the transport-layer associations (i.e., TCP connections) are no longer bound to IP addresses, but to host identifiers. The major difference from HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier that has organizational structure. As a result, the corresponding ID->locator mapping system for such identifiers has a reasonable business model and clear trust boundaries. In addition, RANGI 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 of this locator 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 will reduce the deployment cost of this new routing architecture. Within RANGI, the mappings from FQDN to host identifiers are stored in the DNS system, while the 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 achieves almost all of the goals set forth by RRG as follows: 1. Routing Scalability: Scalability is achieved by decoupling identifiers from locators.
2. 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.
3. Mobility and Multihoming: Sessions will not be interrupted due to
locator change in cases of mobility or multihoming.
4. 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.
5. Decoupling Location and Identifier: Obvious.
6. 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.
7. Routing Security: RANGI reuses the current routing system and
does not introduce any new security risks into the routing
system.
8. 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
1. A host change is required.
2. The first-hop LDBR change is required to support site-controlled
traffic-engineering capability.
3. The ID->locator mapping system is a new infrastructure to be
deployed.
4. 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
RANGI is an ID/locator split protocol that, like HIP, places a cryptographically signed ID between the network layer (IPv6) and transport. Unlike the HIP ID, the RANGI ID has a hierarchical structure that allows it to support ID->locator lookups. This hierarchical structure addresses two weaknesses of the flat HIP ID: the difficulty of doing the ID->locator lookup, and the administrative scalability of doing firewall filtering on flat IDs. The usage of this hierarchy is overloaded: it serves to make the ID unique, to drive the lookup process, and possibly other things like firewall filtering. More thought is needed as to what constitutes these levels with respect to these various roles. The RANGI document [RANGI] suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup that may be DNS or may be something else (a hierarchy of DHTs). It would be more efficient if the FQDN lookup produces both ID and locators (as does the Identifier-Locator Network Protocol (ILNP)). Probably DNS alone is sufficient 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. Many hosts (public web servers) may prefer to forgo the crypto at the expense of losing some functionality (receiver mobility or dynamic multihoming load balancing). While RANGI doesn't require that the receiver validate the sender, it may be good to have a mechanism whereby the receiver can signal to the sender that it is not validating, so that the sender can avoid locator changes. Architecturally, there are many advantages to putting the mapping function at the end host (versus 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 does not have an explicit solution for the mobility race condition (there is no mention of a home-agent-like device). However, host-to-host notification combined with fallback 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. The edge-to-edge proxy approach dirties up an otherwise clean end-to-end model. RANGI exploits existing IPv6 transition technologies (ISATAP and softwire). These transition technologies are in any event being pursued outside of RRG and do not 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
The reason why the ID->locator lookup is separated from the FQDN->ID lookup is: 1) not all applications are tied to FQDNs, and 2) it seems unnecessary to require all devices to possess a FQDN of their own. Basically, RANGI uses DNS to realize the ID->locator mapping system. If there are too many entries to be maintained by the authoritative servers of a given Administrative Domain (AD), Distributed Hash Table (DHT) technology can be used to make these authoritative servers scale better, e.g., the mappings maintained by a given AD will be distributed among a group of authoritative servers in a DHT fashion. As a result, the robustness feature of DHT is inherited naturally into the ID->locator mapping system. Meanwhile, there is no trust issue since each AD authority runs its own DHT ring, which maintains only the mappings for those identifiers that are administrated by that AD authority. For host mobility, if communicating entities are RANGI nodes, the mobile node will notify the correspondent node of its new locator once its locator changes due to a mobility or re-homing event. Meanwhile, it should also update its locator information in the ID->locator mapping system in a timely fashion by using the Secure DNS Dynamic Update mechanism defined in [RFC3007]. In case of simultaneous mobility, at least one of the nodes has to resort to the ID->locator mapping system for resolving the correspondent node's new locator so as to continue their communication. If the correspondent node is a legacy host, Transit Proxies, which fulfill a similar function as 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. Hence, there is no edge-to-edge aliveness problem. 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 such a site changes ISPs.
(page 16 continued on part 2)