tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6115

Informational
Pages: 73
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Recommendation for a Routing Architecture

Part 1 of 4, p. 1 to 16
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part