Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6115

Recommendation for a Routing Architecture

Pages: 73
Informational
Part 1 of 4 – Pages 1 to 16
None   None   Next

Top   ToC   RFC6115 - Page 1
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 Architecture

Abstract

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.
Top   ToC   RFC6115 - Page 2
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
Top   ToC   RFC6115 - Page 3
       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
Top   ToC   RFC6115 - Page 4
   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
Top   ToC   RFC6115 - Page 5
     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
Top   ToC   RFC6115 - Page 6
   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.
Top   ToC   RFC6115 - Page 7
        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
Top   ToC   RFC6115 - Page 8
          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).
Top   ToC   RFC6115 - Page 9

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 progress

2.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.
Top   ToC   RFC6115 - Page 10
   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.
Top   ToC   RFC6115 - Page 11
   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
Top   ToC   RFC6115 - Page 12
   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.
Top   ToC   RFC6115 - Page 13
   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]
Top   ToC   RFC6115 - Page 14

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.
Top   ToC   RFC6115 - Page 15
   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.
Top   ToC   RFC6115 - Page 16
   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)

Next Section