GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6115

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.

Li Informational [Page 1] RFC 6115 RRG Recommendation February 2011

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

Li Informational [Page 2] RFC 6115 RRG Recommendation February 2011

     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

Li Informational [Page 3] RFC 6115 RRG Recommendation February 2011

 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

Li Informational [Page 4] RFC 6115 RRG Recommendation February 2011

   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

Li Informational [Page 5] RFC 6115 RRG Recommendation February 2011

 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.

Li Informational [Page 6] RFC 6115 RRG Recommendation February 2011

      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

Li Informational [Page 7] RFC 6115 RRG Recommendation February 2011

        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).

Li Informational [Page 8] RFC 6115 RRG Recommendation February 2011

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.

Li Informational [Page 9] RFC 6115 RRG Recommendation February 2011

 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.

Li Informational [Page 10] RFC 6115 RRG Recommendation February 2011

 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

Li Informational [Page 11] RFC 6115 RRG Recommendation February 2011

 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.

Li Informational [Page 12] RFC 6115 RRG Recommendation February 2011

 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]

Li Informational [Page 13] RFC 6115 RRG Recommendation February 2011

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.

Li Informational [Page 14] RFC 6115 RRG Recommendation February 2011

 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.

Li Informational [Page 15] RFC 6115 RRG Recommendation February 2011

 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.

4. Internet Vastly Improved Plumbing (Ivip)

4.1. Summary

4.1.1. Key Ideas

 Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation
 scheme for IPv4 and IPv6.  It provides multihoming, portability of
 address space, and inbound traffic engineering for end-user networks
 of all sizes and types, including those of corporations, SOHO (Small
 Office, Home Office), and mobile devices.
 Ivip meets all the constraints imposed by the need for widespread
 voluntary adoption [Ivip_Constraints].
 Ivip's global fast-push mapping distribution network is structured
 like a cross-linked multicast tree.  This pushes all mapping changes
 to full-database query servers (QSDs) within ISPs and end-user
 networks that have ITRs.  Each mapping change is sent to all QSDs
 within a few seconds.  (Note: "QSD" is from Query Server with full
 Database.)
 ITRs gain mapping information from these local QSDs within a few tens
 of milliseconds.  QSDs notify ITRs of changed mappings with similarly
 low latency.  ITRs tunnel all traffic packets to the correct ETR
 without significant delay.
 Ivip's mapping consists of a single ETR address for each range of
 mapped address space.  Ivip ITRs do not need to test reachability to
 ETRs because the mapping is changed in real-time to that of the
 desired ETR.
 End-user networks control the mapping, typically by contracting a
 specialized company to monitor the reachability of their ETRs, and
 change the mapping to achieve multihoming and/or traffic engineering
 (TE).  So, the mechanisms that control ITR tunneling are controlled
 by the end-user networks in real-time and are completely separate
 from the Core-Edge Separation scheme itself.
 ITRs can be implemented in dedicated servers or hardware-based
 routers.  The ITR function can also be integrated into sending hosts.
 ETRs are relatively simple and only communicate with ITRs rarely --
 for Path MTU management with longer packets.

Li Informational [Page 16] RFC 6115 RRG Recommendation February 2011

 Ivip-mapped ranges of end-user address space need not be subnets.
 They can be of any length, in units of IPv4 addresses or IPv6 /64s.
 Compared to conventional unscalable BGP techniques, and to the use of
 Core-Edge Separation architectures with non-real-time mapping
 systems, end-user networks will be able to achieve more flexible and
 responsive inbound TE.  If inbound traffic is split into several
 streams, each to addresses in different mapped ranges, then real-time
 mapping changes can be used to steer the streams between multiple
 ETRs at multiple ISPs.
 Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel
 Routers) tunnel packets sent by hosts in networks that lack ITRs.  So
 multihoming, portability, and TE benefits apply to all traffic.
 ITRs request mappings either directly from a local QSD or via one or
 more layers of caching query servers (QSCs), which in turn request it
 from a local QSD.  QSCs are optional but generally desirable since
 they reduce the query load on QSDs.  (Note: "QSC" is from Query
 Server with Cache.)
 ETRs may be in ISP or end-user networks.  IP-in-IP encapsulation is
 used, so there is no UDP or any other header.  PMTUD (Path MTU
 Discovery) management with minimal complexity and overhead will
 handle the problems caused by encapsulation, and adapt smoothly to
 jumbo frame paths becoming available in the DFZ.  The outer header's
 source address is that of the sending host -- this enables existing
 ISP Border Router (BR) filtering of source addresses to be extended
 to encapsulated traffic packets by the simple mechanism of the ETR
 dropping packets whose inner and outer source address do not match.

4.1.2. Extensions

4.1.2.1. TTR Mobility

 The Translating Tunnel Router (TTR) approach to mobility
 [Ivip_Mobility] is applicable to all Core-Edge Separation techniques
 and provides scalable IPv4 and IPv6 mobility in which the MN keeps
 its own mapped IP address(es) no matter how or where it is physically
 connected, including behind one or more layers of NAT.
 Path lengths are typically optimal or close to optimal, and the MN
 communicates normally with all other non-mobile hosts (no stack or
 application changes), and of course other MNs.  Mapping changes are
 only needed when the MN uses a new TTR, which would typically occur
 if the MN moved more than 1000 km.  Mapping changes are not required
 when the MN changes its physical address(es).

Li Informational [Page 17] RFC 6115 RRG Recommendation February 2011

4.1.2.2. Modified Header Forwarding

 Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR
 without encapsulation.  This will remove the encapsulation overhead
 and PMTUD problems.  Both approaches involve modifying all routers
 between the ITR and ETR to accept a modified form of the IP header.
 These schemes require new FIB/RIB functionality in DFZ and some other
 routers but do not alter the BGP functions of DFZ routers.

4.1.3. Gains

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

4.1.4. Costs

 QSDs receive all mapping changes and store a complete copy of the
 mapping database.  However, a worst-case scenario is 10 billion IPv6
 mappings, each of 32 bytes, which fits on a consumer hard drive today
 and should fit in server DRAM by the time such adoption is reached.
 The maximum number of non-mobile networks requiring multihoming,
 etc., is likely to be ~10 million, so most of the 10 billion mappings
 would be for mobile devices.  However, TTR mobility does not involve
 frequent mapping changes since most MNs only rarely move more than
 1000 km.

Li Informational [Page 18] RFC 6115 RRG Recommendation February 2011

4.1.5. References

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

4.2. Critique

 Looked at from the thousand-foot level, Ivip shares the basic design
 approaches with LISP and a number of other map-and-encap designs
 based on the Core-Edge Separation.  However, the details differ
 substantially.  Ivip's design makes a bold assumption that, with
 technology advances, one could afford to maintain a real-time
 distributed global mapping database for all networks and hosts.  Ivip
 proposes that multiple parties collaborate to build a mapping
 distribution system that pushes all mapping information and updates
 to local, full-database query servers located in all ISPs within a
 few seconds.  The system has no single point of failure and uses end-
 to-end authentication.
 A "real time, globally synchronized mapping database" is a critical
 assumption in Ivip.  Using that as a foundation, Ivip design avoids
 several challenging design issues that others have studied
 extensively, that include
 1.  special considerations of mobility support that add additional
     complexity to the overall system;
 2.  prompt detection of ETR failures and notification to all relevant
     ITRs, which turns out to be a rather difficult problem; and
 3.  development of a partial-mapping lookup sub-system.  Ivip assumes
     the existence of local query servers with a full database with
     the latest mapping information changes.
 To be considered as a viable solution to the Internet routing
 scalability problem, Ivip faces two fundamental questions.  First,
 whether a global-scale system can achieve real-time synchronized
 operations as assumed by Ivip is an entirely open question.  Past
 experiences suggest otherwise.
 The second question concerns incremental rollout.  Ivip represents an
 ambitious approach, with real-time mapping and local full-database
 query servers -- which many people regard as impossible.  Developing
 and implementing Ivip may take a fair amount of resources, yet there
 is an open question regarding how to quantify the gains by first
 movers -- both those who will provide the Ivip infrastructure and

Li Informational [Page 19] RFC 6115 RRG Recommendation February 2011

 those that will use it.  Significant global routing table reduction
 only happens when a large enough number of parties have adopted Ivip.
 The same question arises for most other proposals as well.
 One belief is that Ivip's more ambitious mapping system makes a good
 design tradeoff for the greater benefits for end-user networks and
 for those that develop the infrastructure.  Another belief is that
 this ambitious design is not viable.

4.3. Rebuttal

 Since the Summary and Critique were written, Ivip's mapping system
 has been significantly redesigned: DRTM - Distributed Real Time
 Mapping [Ivip_DRTM].
 DRTM makes it easier for ISPs to install their own ITRs.  It also
 facilitates Mapped Address Block (MAB) operating companies -- which
 need not be ISPs -- leasing Scalable Provider-Independent (SPI)
 address space to end-user networks with almost no ISP involvement.
 ISPs need not install ITRs or ETRs.  For an ISP to support its
 customers using SPI space, they need only allow the forwarding of
 outgoing packets whose source addresses are from SPI space.  End-user
 networks can implement their own ETRs on their existing PA
 address(es) -- and MAB operating companies make all the initial
 investments.
 Once SPI adoption becomes widespread, ISPs will be motivated to
 install their own ITRs to locally tunnel packets that are sent from
 customer networks and that must be tunneled to SPI-using customers of
 the same ISP -- rather than letting these packets exit the ISP's
 network and return in tunnels to ETRs in the network.
 There is no need for full-database query servers in ISPs or for any
 device that stores the full mapping information for all Mapped
 Address Blocks (MABs).  ISPs that want ITRs will install two or more
 Map Resolver (MR) servers.  These are caching query servers which
 query multiple (typically nearby) query servers that are full-
 database for the subset of MABs they serve.  These "nearby" query
 servers will be at DITR sites, which will be run by, or for, MAB
 operating companies who lease MAB space to large numbers of end-user
 networks.  These DITR-site servers will usually be close enough to
 the MRs to generate replies with sufficiently low delay and risk of
 packet loss for ITRs to buffer initial packets for a few tens of
 milliseconds while the mapping arrives.
 DRTM will scale to billions of micronets, tens of thousands of MABs,
 and potentially hundreds of MAB operating companies, without single
 points of failure or central coordination.

Li Informational [Page 20] RFC 6115 RRG Recommendation February 2011

 The critique implies a threshold of adoption is required before
 significant routing scaling benefits occur.  This is untrue of any
 Core-Edge Separation proposal, including LISP and Ivip.  Both can
 achieve scalable routing benefits in direct proportion to their level
 of adoption by providing portability, multihoming, and inbound TE to
 large numbers of end-user networks.
 Core-Edge Elimination (CEE) architectures require all Internet
 communications to change to IPv6 with a new locator/identifier
 separation naming model.  This would impose burdens of extra
 management effort, packets, and session establishment delays on all
 hosts -- which is a particularly unacceptable burden on battery-
 operated mobile hosts that rely on wireless links.
 Core-Edge Separation architectures retain the current, efficient,
 naming model, require no changes to hosts, and support both IPv4 and
 IPv6.  Ivip is the most promising architecture for future development
 because its scalable, distributed, real-time mapping system best
 supports TTR mobility, enables ITRs to be simpler, and gives real-
 time control of ITR tunneling to the end-user network or to
 organizations they appoint to control the mapping of their micronets.

5. Hierarchical IPv4 Framework (hIPv4)

5.1. Summary

5.1.1. Key Idea

 The Hierarchical IPv4 Framework (hIPv4) adds scalability to the
 routing architecture by introducing additional hierarchy in the IPv4
 address space.  The IPv4 addressing scheme is divided into two parts,
 the Area Locator (ALOC) address space, which is globally unique, and
 the Endpoint Locator (ELOC) address space, which is only regionally
 unique.  The ALOC and ELOC prefixes are added as a shim header
 between the IP header and transport protocol header; the shim header
 is identified with a new protocol number in the IP header.  Instead
 of creating a tunneling (i.e., overlay) solution, a new routing
 element is needed in the service provider's routing domain (called
 ALOC realm) -- a Locator Swap Router.  The current IPv4 forwarding
 plane remains intact, and no new routing protocols, mapping systems,
 or caching solutions are required.  The control plane of the ALOC
 realm routers needs some modification in order for ICMP to be
 compatible with the hIPv4 framework.  When an area (one or several
 autonomous systems (ASes)) of an ISP has transformed into an ALOC
 realm, only ALOC prefixes are exchanged with other ALOC realms.
 Directly attached ELOC prefixes are only inserted to the RIB of the
 local ALOC realm; ELOC prefixes are not distributed to the DFZ.
 Multihoming can be achieved in two ways, either the enterprise

Li Informational [Page 21] RFC 6115 RRG Recommendation February 2011

 requests an ALOC prefix from the RIR (this is not recommended) or the
 enterprise receives the ALOC prefixes from their upstream ISPs.  ELOC
 prefixes are PI addresses and remain intact when an upstream ISP is
 changed; only the ALOC prefix is replaced.  When the RIB of the DFZ
 is compressed (containing only ALOC prefixes), ingress routers will
 no longer know the availability of the destination prefix; thus, the
 endpoints must take more responsibility for their sessions.  This can
 be achieved by using multipath enabled transport protocols, such as
 SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the
 endpoints.  The multipath transport protocols also provide a session
 identifier, i.e., verification tag or token; thus, the location and
 identifier split is carried out -- site mobility, endpoint mobility,
 and mobile site mobility are achieved.  DNS needs to be upgraded: in
 order to resolve the location of an endpoint, the endpoint must have
 one ELOC value (current A-record) and at least one ALOC value in DNS
 (in multihoming solutions there will be several ALOC values for an
 endpoint).

5.1.2. Gains

 1.  Improved routing scalability: Adding additional hierarchy to the
     address space enables more hierarchy in the routing architecture.
     Early adapters of an ALOC realm will no longer carry the current
     RIB of the DFZ -- only ELOC prefixes of their directly attached
     networks and ALOC prefixes from other service providers that have
     migrated are installed in the ALOC realm's RIB.
 2.  Scalable support for traffic engineering: Multipath enabled
     transport protocols are recommended to achieve dynamic load-
     balancing of a session.  Support for Valiant Load-balancing (VLB)
     [Valiant] schemes has been added to the framework; more research
     work is required around VLB switching.
 3.  Scalable support for multihoming: Only attachment points of a
     multihomed site are advertised (using the ALOC prefix) in the
     DFZ.  DNS will inform the requester on how many attachment points
     the destination endpoint has.  It is the initiating endpoint's
     choice/responsibility to choose which attachment point is used
     for the session; endpoints using multipath-enabled transport
     protocols can make use of several attachment points for a
     session.
 4.  Simplified Renumbering: When changing provider, the local ELOC
     prefixes remains intact; only the ALOC prefix is changed at the
     endpoints.  The ALOC prefix is not used for routing or forwarding
     decisions in the local network.

Li Informational [Page 22] RFC 6115 RRG Recommendation February 2011

 5.  Decoupling Location and Identifier: The verification tag (SCTP)
     and token (MPTCP) can be considered to have the characteristics
     of a session identifier, and thus a session layer is created
     between the transport and application layers in the TCP/IP model.
 6.  Routing quality: The hIPv4 framework introduces no tunneling or
     caching mechanisms.  Only a swap of the content in the IPv4
     header and locator header at the destination ALOC realm is
     required; thus, current routing and forwarding algorithms are
     preserved as such.  Valiant Load-balancing might be used as a new
     forwarding mechanism.
 7.  Routing Security: Similar as with today's DFZ, except that ELOC
     prefixes cannot be hijacked (by injecting a longest match prefix)
     outside an ALOC realm.
 8.  Deployability: The hIPv4 framework is an evolution of the current
     IPv4 framework and is backwards compatible with the current IPv4
     framework.  Sessions in a local network and inside an ALOC realm
     might in the future still use the current IPv4 framework.

5.1.3. Costs and Issues

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

5.1.4. References

 [hIPv4] [Valiant]

Li Informational [Page 23] RFC 6115 RRG Recommendation February 2011

5.2. Critique

 hIPv4 is an innovative approach to expanding the IPv4 addressing
 system in order to resolve the scalable routing problem.  This
 critique does not attempt a full assessment of hIPv4's architecture
 and mechanisms.  The only question addressed here is whether hIPv4
 should be chosen for IETF development in preference to, or together
 with, the only two proposals which appear to be practical solutions
 for IPv4: Ivip and LISP.
 Ivip and LISP appear to have a major advantage over hIPv4 in terms of
 support for packets sent from non-upgraded hosts/networks.  Ivip's
 DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel
 Routers) both accept packets sent by any non-upgraded host/network
 and tunnel them to the correct ETR -- thus providing the full
 benefits of portability, multihoming, and inbound TE for these
 packets as well as those sent by hosts in networks with ITRs. hIPv4
 appears to have no such mechanism, so these benefits are only
 available for communications between two upgraded hosts in upgraded
 networks.
 This means that significant benefits for adopters -- the ability to
 rely on the new system to provide the portability, multihoming, and
 inbound TE benefits for all, or almost all, their communications --
 will only arise after all, or almost all, networks upgrade their
 networks, hosts, and addressing arrangements. hIPv4's relationship
 between adoption levels and benefits to any adopter therefore are far
 less favorable to widespread adoption than those of Core-Edge
 Separation (CES) architectures such as Ivip and LISP.
 This results in hIPv4 also being at a disadvantage regarding the
 achievement of significant routing scaling benefits, which likewise
 will only result once adoption is close to ubiquitous.  Ivip and LISP
 can provide routing scaling benefits in direct proportion to their
 level of adoption, since all adopters gain full benefits for all
 their communications, in a highly scalable manner.
 hIPv4 requires stack upgrades, which are not required by any CES
 architecture.  Furthermore, a large number of existing IPv4
 application protocols convey IP addresses between hosts in a manner
 that will not work with hIPv4: "There are several applications that
 are inserting IP address information in the payload of a packet.
 Some applications use the IP address information to create new
 sessions or for identification purposes.  This section is trying to
 list the applications that need to be enhanced; however, this is by
 no means a comprehensive list" [hIPv4].

Li Informational [Page 24] RFC 6115 RRG Recommendation February 2011

 If even a few widely used applications would need to be rewritten to
 operate successfully with hIPv4, then this would be such a
 disincentive to adoption to rule out hIPv4 ever being adopted widely
 enough to solve the routing scaling problem, especially since CES
 architectures fully support all existing protocols, without the need
 for altering host stacks.
 It appears that hIPv4 involves major practical difficulties, which
 mean that in its current form it is not suitable for IETF
 development.

5.3. Rebuttal

 No rebuttal was submitted for this proposal.

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

6.1. Summary

6.1.1. Key Idea

 The basic idea is to add a name overlay (NOL) onto the existing
 TCP/IP stack.
 Its functions include:
 1.  Managing host name configuration, registration, and
     authentication;
 2.  Initiating and managing transport connection channels (i.e.,
     TCP/IP connections) by name;
 3.  Keeping application data transport continuity for mobility.
 At the edge network, we introduce a new type of gateway, a Name
 Transfer Relay (NTR), which blocks the PI addresses of edge networks
 into upstream transit networks.  NTRs perform address and/or port
 translation between blocked PI addresses and globally routable
 addresses, which seem like today's widely used NAT / Network Address
 Port Translation (NAPT) devices.  Both legacy and NOL applications
 behind a NTR can access the outside as usual.  To access the hosts
 behind a NTR from outside, we need to use NOL to traverse the NTR by
 name and initiate connections to the hosts behind it.

Li Informational [Page 25] RFC 6115 RRG Recommendation February 2011

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

6.1.2. Gains

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

Li Informational [Page 26] RFC 6115 RRG Recommendation February 2011

6.1.3. Costs

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

6.1.4. References

 No references were submitted.

6.2. Critique

 1.  Applications on hosts need to be rebuilt based on a name overlay
     library to be NOL-enabled.  The legacy software that is not
     maintained will not be able to benefit from NOL in the Core-Edge
     Elimination situation.  In the Core-Edge Separation scheme, a new
     gateway NTR is deployed to prevent edge-specific PI prefixes from
     leaking into the transit core.  NOL doesn't impede the legacy
     endpoints behind the NTR from accessing the outside Internet, but
     the legacy endpoints cannot access or will have difficultly
     accessing the endpoints behind a NTR without the help of NOL.
 2.  In the case of Core-Edge Elimination, the end site will be
     assigned multiple PA address spaces, which leads to renumbering
     troubles when switching to other upstream providers.  Upgrading
     endpoints to support NOL doesn't give any benefits to edge
     networks.  Endpoints have little incentive to use NOL in a Core-
     Edge Elimination scenario, and the same is true with other host-
     based ID/locator split proposals.  Whether they are IPv4 or IPv6
     networks, edge networks prefer PI address space to PA address
     space.

Li Informational [Page 27] RFC 6115 RRG Recommendation February 2011

 3.  In the Core-Edge Separation scenario, the additional gateway NTR
     is to prevent the specific prefixes from the edge networks, just
     like a NAT or the ITR/ETR of LISP.  A NTR gateway can be seen as
     an extension of NAT (Network Address Translation).  Although NATs
     are deployed widely, upgrading them to support NOL extension or
     deploying additional new gateway NTRs at the edge networks is on
     a voluntary basis and has few economic incentives.
 4.  The stateful or stateless translation for each packet traversing
     a NTR will require the cost of the CPU and memory of NTRs, and
     increase forwarding delay.  Thus, it is not appropriate to deploy
     NTRs at the high-level transit networks where aggregated traffic
     may cause congestion at the NTRs.
 5.  In the Core-Edge Separation scenario, the requirement for
     multihoming and inter-domain traffic engineering will make end
     sites accessible via multiple different NTRs.  For reliability,
     all of the associations between multiple NTRs and the end site
     name will be kept in DNS, which may increase the load on DNS.
 6.  To support mobility, it is necessary for DNS to update the
     corresponding name-NTR mapping records when an end system moves
     from behind one NTR to another NTR.  The NOL-enabled end relies
     on the NOL layer to preserve the continuity of the transport
     layer, since the underlying TCP/UDP transport session would be
     broken when the IP address changed.

6.3. Rebuttal

 NOL resembles neither CEE nor CES as a solution.  By supporting
 application-level sessions through the name overlay layer, NOL can
 support some solutions in the CEE style.  However, NOL is in general
 closer to CES solutions, i.e., preventing PI prefixes of edge
 networks from entering into the upstream transit networks.  This is
 done by the NTR, like the ITRs/ETRs in CES solutions, but NOL has no
 need to define the clear boundary between core and edge networks.
 NOL is designed to try to provide end users or networks a service
 that facilitates the adoption of multihoming, multipath routing, and
 traffic engineering by the indirect routing through NTRs, and that,
 in the mean time, doesn't accelerate or decelerate the growth of
 global routing table size.
 Some problems are described in the NOL critique.  In the original NOL
 proposal document, the DNS query for a host that is behind a NTR will
 induce the return of the actual IP addresses of the host and the
 address of the NTR.  This arrangement might cause some difficulties
 for legacy applications due to the non-standard response from DNS.
 To resolve this problem, we instead have the NOL service use a new

Li Informational [Page 28] RFC 6115 RRG Recommendation February 2011

 namespace, and have DNS not return NTR IP addresses for the legacy
 hosts.  The names used for NOL are formatted like email addresses,
 such as "des@example.net".  The mapping between "example.net" and the
 IP address of the corresponding NTR will be registered in DNS.  The
 NOL layer will understand the meaning of the name "des@example.net" ,
 and it will send a query to DNS only for "example.net".  DNS will
 then return IP addresses of the corresponding NTRs.  Legacy
 applications will still use the traditional FQDN name, and DNS will
 return the actual IP address of the host.  However, if the host is
 behind a NTR, the legacy applications may be unable to access the
 host.
 The stateless address translation or stateful address and port
 translation may cause a scaling problem with the number of table
 entries NTR must maintain, and legacy applications cannot initiate
 sessions with hosts inside the NOL-adopting End User Network (EUN).
 However, these problems may not be a big barrier for the deployment
 of NOL or other similar approaches.  Many NAT-like boxes, proxy, and
 firewall devices are widely used at the ingress/egress points of
 enterprise networks, campus networks, or other stub EUNs.  The hosts
 running as servers can be deployed outside NTRs or can be assigned PA
 addresses in an NTR-adopting EUN.

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

7.1. Summary

7.1.1. Key Idea

 This proposal (referred to here as "CRM") is to build a highly
 scalable locator identity mapping system using compact routing
 principles.  This provides the means for dynamic topology adaption to
 facilitate efficient aggregation [CRM].  Map servers are assigned as
 cluster heads or landmarks based on their capability to aggregate EID
 announcements.

7.1.2. Gains

 o  Minimizes the routing table sizes at the system level (i.e., map
    servers).  Provides clear upper bounds for routing stretch that
    define the packet delivery delay of the map request / first
    packet.
 o  Organizes the mapping system based on the EID numbering space,
    minimizes the administrative overhead of managing the EID space.
    No need for administratively planned hierarchical address
    allocation as the system will find convergence into a set of EID
    allocations.

Li Informational [Page 29] RFC 6115 RRG Recommendation February 2011

 o  Availability and robustness of the overall routing system
    (including xTRs and map servers) are improved because of the
    potential to use multiple map servers and direct routes without
    the involvement of map servers.

7.1.3. Costs

 The scalability gains will materialize only in large deployments.  If
 the stretch is bounded to those of compact routing (worst-case
 stretch less or equal to 3, on average, 1+epsilon), then each xTR
 needs to have memory/cache for the mappings of its cluster.

7.1.4. References

 [CRM]

7.2. Critique

 The CRM proposal is not a complete proposal and therefore cannot be
 considered for further development by the IETF as a scalable routing
 solution.
 While Compact Routing principles may be able to improve a mapping
 overlay structure such as LISP+ALT, there are several objections to
 this approach.
 Firstly, a CRM-modified ALT structure would still be a global query
 server system.  No matter how ALT's path lengths and delays are
 optimized, there is a problem with a querier -- which could be
 anywhere in the world -- relying on mapping information from one or
 ideally two or more authoritative query servers, which could also be
 anywhere in the world.  The delays and risks of packet loss that are
 inherent in such a system constitute a fundamental problem.  This is
 especially true when multiple, potentially long, traffic streams are
 received by ITRs and forwarded over the CRM networks for delivery to
 the destination network.  ITRs must use the CRM infrastructure while
 they are awaiting a map reply.  The traffic forwarded on the CRM
 infrastructure functions as map requests and can present a
 scalability and performance issue to the infrastructure.
 Secondly, the alterations contemplated in this proposal involve the
 roles of particular nodes in the network being dynamically assigned
 as part of the network's self-organizing nature.
 The discussion of clustering in the middle of page 4 of [CRM] also
 indicates that particular nodes are responsible for registering EIDs
 from typically far-distant ETRs, all of which are handling closely
 related EIDs that this node can aggregate.  Since MSes are apparently

Li Informational [Page 30] RFC 6115 RRG Recommendation February 2011

 nodes within the compact routing system, and the process of an MS
 deciding whether to accept EID registrations is determined as part of
 the self-organizing properties of the system, there are concerns
 about how EID registration can be performed securely, when no
 particular physical node is responsible for it.
 Thirdly, there are concerns about individually owned nodes performing
 work for other organizations.  Such problems of trust and of
 responsibilities and costs being placed on those who do not directly
 benefit already exist in the inter-domain routing system and are a
 challenge for any scalable routing solution.
 There are simpler solutions to the mapping problem than having an
 elaborate network of routers.  If a global-scale query system is
 still preferred, then it would be better to have ITRs use local MRs,
 each of which is dynamically configured to know the IP address of the
 million or so authoritative Map Server (MS) query servers -- or two
 million or so assuming they exist in pairs for redundancy.
 It appears that the inherently greater delays and risks of packet
 loss of global query server systems make them unsuitable mapping
 solutions for Core-Edge Elimination or Core-Edge Separation
 architectures.  The solution to these problems appears to involve a
 greater number of widely distributed authoritative query servers, one
 or more of which will therefore be close enough to each querier that
 delays and risk of packet loss are reduced to acceptable levels.
 Such a structure would be suitable for map requests, but perhaps not
 for handling traffic packets to be delivered to the destination
 networks.

7.3. Rebuttal

 CRM is most easily understood as an alteration to the routing
 structure of the LISP+ALT mapping overlay system, by altering or
 adding to the network's BGP control plane.
 CRM's aims include the delivery of initial traffic packets to their
 destination networks where they also function as map requests.  These
 packet streams may be long and numerous in the fractions of a second
 to perhaps several seconds that may elapse before the ITR receives
 the map reply.
 Compact Routing principles are used to optimize the path length taken
 by these query or traffic packets through a significantly modified
 version of the ALT (or similar) network, while also generally
 reducing typical or maximum paths taken by the query packets.

Li Informational [Page 31] RFC 6115 RRG Recommendation February 2011

 An overlay network is a diversion from the shortest path.  However,
 CMR limits this diversion and provides an upper bound.  Landmark
 routers/servers could deliver more than just the first traffic
 packet, subject to their CPU capabilities and their network
 connectivity bandwidths.
 The trust between the landmarks (mapping servers) can be built based
 on the current BGP relationships.  Registration to the landmark nodes
 needs to be authenticated mutually between the MS and the system that
 is registering.  This part is not documented in the proposal text.

8. Layered Mapping System (LMS)

8.1. Summary

8.1.1. Key Ideas

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

8.1.2. Gains

 1.  Scalability
     A.  Distributed storage of mapping data avoids central storage of
         massive amounts of data and restricts updates within local
         areas.
     B.  The cache mechanism in an ITR reasonably reduces the request
         loads on the mapping system.
 2.  Deployability
     A.  No change on edge systems, only tunneling in core routers,
         and new devices in core networks.
     B.  The mapping system can be constructed stepwise: a mapping
         node needn't be constructed if none of its responsible ELOCs
         is allocated.  This makes sense especially for IPv6.

Li Informational [Page 32] RFC 6115 RRG Recommendation February 2011

     C.  Conforms to a viable economic model: the mapping system
         operators can profit from their services; core routers and
         edge networks are willing to join the circle either to avoid
         router upgrades or realize traffic engineering.  Benefits
         from joining are independent of the scheme's implementation
         scale.
 3.  Low request delay: The low number of layers in the mapping
     structure and the two-stage cache help achieve low request delay.
 4.  Data consistency: The two-stage cache enables an ITR to update
     data in the map cache conveniently.
 5.  Traffic engineering support: Edge networks inform the mapping
     system of their prioritized mappings with all upstream routers,
     thus giving the edge networks control over their ingress flows.

8.1.3. Costs

 1.  Deployment of LMS needs to be further discussed.
 2.  The structure of the mapping system needs to be refined according
     to practical circumstances.

8.1.4. References

 [LMS_Summary] [LMS]

8.2. Critique

 LMS is a mapping mechanism based on Core-Edge Separation.  In fact,
 any proposal that needs a global mapping system with keys with
 similar properties to that of an "edge address" in a Core-Edge
 Separation scenario can use such a mechanism.  This means that those
 keys are globally unique (by authorization or just statistically), at
 the disposal of edge users, and may have several satisfied mappings
 (with possibly different weights).  A proposal to address routing
 scalability that needs mapping but doesn't specify the mapping
 mechanism can use LMS to strengthen its infrastructure.
 The key idea of LMS is similar to that of LISP+ALT: that the mapping
 system should be hierarchically organized to gain scalability for
 storage and updates and to achieve quick indexing for lookups.
 However, LMS advocates an ISP-independent mapping system, and ETRs
 are not the authorities of mapping data.  ETRs or edge-sites report
 their mapping data to related mapping servers.

Li Informational [Page 33] RFC 6115 RRG Recommendation February 2011

 LMS assumes that mapping servers can be incrementally deployed in
 that a server may not be constructed if none of its administered edge
 addresses are allocated, and that mapping servers can charge for
 their services, which provides the economic incentive for their
 existence.  How this brand-new system can be constructed is still not
 clear.  Explicit layering is only an ideal state, and the proposal
 analyzes the layering limits and feasibility, rather than provide a
 practical way for deployment.
 The drawbacks of LMS's feasibility analysis also include that it 1)
 is based on current PC power and may not represent future
 circumstances (especially for IPv6), and 2) does not consider the
 variability of address utilization.  Some IP address spaces may be
 effectively allocated and used while some may not, causing some
 mapping servers to be overloaded while others are poorly utilized.
 More thoughts are needed as to the flexibility of the layer design.
 LMS doesn't fit well for mobility.  It does not solve the problem
 when hosts move faster than the mapping updates and propagation
 between relative mapping servers.  On the other hand, mobile hosts'
 moving across ASes and changing their attachment points (core
 addresses) is less frequent than hosts' moving within an AS.
 Separation needs two planes: Core-Edge Separation (which is to gain
 routing table scalability) and identity/location separation (which is
 to achieve mobility).  The Global Locator, Local Locator, and
 Identifier (GLI) scheme does a good clarification of this, and in
 that case, LMS can be used to provide identity-to-core address
 mapping.  Of course, other schemes may be competent, and LMS can be
 incorporated with them if the scheme has global keys and needs to map
 them to other namespaces.

8.3. Rebuttal

 No rebuttal was submitted for this proposal.

9. Two-Phased Mapping

9.1. Summary

9.1.1. Considerations

 1.  A mapping from prefixes to ETRs is an M:M mapping.  Any change of
     a (prefix, ETR) pair should be updated in a timely manner, which
     can be a heavy burden to any mapping system if the relation
     changes frequently.

Li Informational [Page 34] RFC 6115 RRG Recommendation February 2011

 2.  A prefix<->ETR mapping system cannot be deployed efficiently if
     it is overwhelmed by worldwide dynamics.  Therefore, the mapping
     itself is not scalable with this direct mapping scheme.

9.1.2. Basics of a Two-Phased Mapping

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

9.1.3. Gains

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

Li Informational [Page 35] RFC 6115 RRG Recommendation February 2011

9.1.4. Summary

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

9.1.5. References

 No references were submitted.

9.2. Critique

 This is a simple idea on how to scale mapping.  However, this design
 is too incomplete to be considered a serious input to RRG.  Take the
 following two issues as example:
 First, in this two-phase scheme, an AS is essentially the unit of
 destinations (i.e., sending ITRs find out destination AS D, then send
 data to one of D's ETRs).  This does not offer much choice for
 traffic engineering.
 Second, there is no consideration whatsoever on failure detection and
 handling.

9.3. Rebuttal

 No rebuttal was submitted for this proposal.

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

10.1. Summary

10.1.1. Key Idea

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

Li Informational [Page 36] RFC 6115 RRG Recommendation February 2011

 order bits contain the ID.  A local mapping system maps IDs to LLs,
 and a global mapping system maps IDs to GLs.  The full GLI-mode
 requires nodes with upgraded networking stacks and special GLI-
 gateways.  The GLI-gateways perform stateless locator rewriting in
 IPv6 addresses with the help of the local and global mapping system.
 Non-upgraded IPv6 nodes can also be accommodated in GLI-domains since
 an enhanced DHCP service and GLI-gateways compensate for their
 missing GLI-functionality.  This is an important feature for
 incremental deployability.

10.1.2. Gains

 The benefits of GLI-Split are:
 o  Hierarchical aggregation of routing information in the global
    Internet through separation of edge and core routing
 o  Provider changes not visible to nodes inside GLI-domains
    (renumbering not needed)
 o  Rearrangement of subnetworks within edge networks not visible to
    the outside world (better support of large edge networks)
 o  Transport connections survive both types of changes
 o  Multihoming
 o  Improved traffic engineering for incoming and outgoing traffic
 o  Multipath routing and load balancing for hosts
 o  Improved resilience
 o  Improved mobility support without home agents and triangle routing
 o  Interworking with the classic Internet
  • without triangle routing over proxy routers
  • without stateful NAT
 These benefits are available for upgraded GLI-nodes, but non-upgraded
 nodes in GLI-domains partially benefit from these advanced features,
 too.  This offers multiple incentives for early adopters, and they
 have the option to migrate their nodes gradually from non-GLI-stacks
 to GLI-stacks.

Li Informational [Page 37] RFC 6115 RRG Recommendation February 2011

10.1.3. Costs

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

10.1.4. References

 [GLI]

10.2. Critique

 GLI-Split makes a clear distinction between two separation planes:
 the separation between identifier and locator (which is to meet end-
 users' needs including mobility) and the separation between local and
 global locator (which makes the global routing table scalable).  The
 distinction is needed since ISPs and hosts have different
 requirements, with both needing to make the changes inside and
 outside GLI-domains invisible to their opposites.
 A main drawback of GLI-Split is that it puts a burden on hosts.
 Before routing a packet received from upper layers, network stacks in
 hosts first need to resolve the DNS name to an IP address; if the IP
 address is GLI-formed, it may look up the map from the identifier
 extracted from the IP address to the local locator.  If the
 communication is between different GLI-domains, hosts may further
 look up the mapping from the identifier to the global locator.
 Having the local mapping system forward requests to the global
 mapping system for hosts is just an option.  Though host lookup may
 ease the burden of intermediate nodes, which would otherwise to
 perform the mapping lookup, the three lookups by hosts in the worst
 case may lead to large delays unless a very efficient mapping
 mechanism is devised.  The work may also become impractical for low-
 powered hosts.  On one hand, GLI-Split can provide backward
 compatibility where classic and upgraded IPv6 hosts can communicate.
 This is its big virtue.  On the other hand, the need to upgrade may
 work against hosts' enthusiasm to change.  This is offset against the
 benefits they would gain.
 GLI-Split provides additional features to improve TE and to improve
 resilience, e.g., exerting multipath routing.  However, the cost is
 that more burdens are placed on hosts, e.g., they may need more
 lookup actions and route selections.  However, these kinds of
 tradeoffs between costs and gains exist in most proposals.

Li Informational [Page 38] RFC 6115 RRG Recommendation February 2011

 One improvement of GLI-Split is its support for mobility by updating
 DNS data as GLI-hosts move across GLI-domains.  Through this, the
 GLI-corresponding-node can query DNS to get a valid global locator of
 the GLI-mobile-node and need not query the global mapping system
 (unless it wants to do multipath routing), giving more incentives for
 nodes to become GLI-enabled.  The merits of GLI-Split, including
 simplified-mobility-handover provision, compensate for the costs of
 this improvement.
 GLI-Split claims to use rewriting instead of tunneling for
 conversions between local and global locators when packets span GLI-
 domains.  The major advantage is that this kind of rewriting needs no
 extra state, since local and global locators need not map to each
 other.  Many other rewriting mechanisms instead need to maintain
 extra state.  It also avoids the MTU problem faced by the tunneling
 methods.  However, GLI-Split achieves this only by compressing the
 namespace size of each attribute (identifier and local/global
 locator).  GLI-Split encodes two namespaces (identifier and local/
 global locator) into an IPv6 address (each has a size of 2^64 or
 less), while map-and-encap proposals assume that identifier and
 locator each occupy a 128-bit space.

10.3. Rebuttal

 The arguments in the GLI-Split critique are correct.  There are only
 two points that should be clarified here.  First, it is not a
 drawback that hosts perform the mapping lookups.  Second, the
 critique proposed an improvement to the mobility mechanism, which is
 of a general nature and not specific to GLI-Split.
 1.  The additional burden on the hosts is actually a benefit,
     compared to having the same burden on the gateways.  If the
     gateway would perform the lookups and packets addressed to
     uncached EIDs arrive, a lookup in the mapping system must be
     initiated.  Until the mapping reply returns, packets must be
     either dropped, cached, or sent over the mapping system to the
     destination.  All these options are not optimal and have their
     drawbacks.  To avoid these problems in GLI-Split, the hosts
     perform the lookup.  The short additional delay is not a big
     issue in the hosts because it happens before the first packets
     are sent.  So, no packets are lost or have to be cached.  GLI-
     Split could also easily be adapted to special GLI-hosts (e.g.,
     low-power sensor nodes) that do not have to do any lookup and
     simply let the gateway do all the work.  This functionality is
     included anyway for backward compatibility with regular IPv6
     hosts inside the GLI-domain.

Li Informational [Page 39] RFC 6115 RRG Recommendation February 2011

 2.  The critique proposes a DNS-based mobility mechanism as an
     improvement to GLI-Split.  However, this improvement is an
     alternative mobility approach that can be applied to any routing
     architecture (including GLI-Split) and also raises some concerns,
     e.g., the update speed of DNS.  Therefore, we prefer to keep this
     issue out of the discussion.

11. Tunneled Inter-Domain Routing (TIDR)

11.1. Summary

11.1.1. Key Idea

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

11.1.2. Gains

 o  Smooth deployment
 o  Size reduction of the global RIB
 o  Deterministic customer traffic engineering for incoming traffic
 o  Numerous forwarding decisions for a particular address prefix
 o  Stops AS number space depletion
 o  Improved BGP convergence
 o  Protection of the inter-domain routing infrastructure
 o  Easy separation of control traffic and transit traffic
 o  Different layer-2 protocol IDs for transit and non-transit traffic
 o  Multihoming resilience

Li Informational [Page 40] RFC 6115 RRG Recommendation February 2011

 o  New address families and tunneling techniques
 o  Support for IPv4 or IPv6, and migration to IPv6
 o  Scalability, stability, and reliability
 o  Faster inter-domain routing

11.1.3. Costs

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

11.1.4. References

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

11.2. Critique

 TIDR is a Core-Edge Separation architecture from late 2006 that
 distributes its mapping information via BGP messages that are passed
 between DFZ routers.
 This means that TIDR cannot solve the most important goal of scalable
 routing -- to accommodate much larger numbers of end-user network
 prefixes (millions or billions) without each such prefix directly
 burdening every DFZ router.  Messages advertising routes for TIDR-
 managed prefixes may be handled with lower priority, but this would
 only marginally reduce the workload for each DFZ router compared to
 handling an advertisement of a conventional PI prefix.
 Therefore, TIDR cannot be considered for RRG recommendation as a
 solution to the routing scaling problem.
 For a TIDR-using network to receive packets sent from any host, every
 BR of all ISPs must be upgraded to have the new ITR-like
 functionality.  Furthermore, all DFZ routers would need to be altered
 so they accepted and correctly propagated the routes for end-user
 network address space, with the new LOCATOR attribute, which contains
 the ETR address and a REMOTE-PREFERENCE value.  Firstly, if they
 received two such advertisements with different LOCATORs, they would
 advertise a single route to this prefix containing both.  Secondly,
 for end-user address space (for IPv4) to be more finely divided, the
 DFZ routers must propagate LOCATOR-containing advertisements for
 prefixes longer than /24.

Li Informational [Page 41] RFC 6115 RRG Recommendation February 2011

 TIDR's ITR-like routers store the full mapping database -- so there
 would be no delay in obtaining mapping, and therefore no significant
 delay in tunneling traffic packets.
 [TIDR] is written as if traffic packets are classified by reference
 to the RIB, but routers use the FIB for this purpose, and "FIB" does
 not appear in [TIDR].
 TIDR does not specify a tunneling technique, leaving this to be
 chosen by the ETR-like function of BRs and specified as part of a
 second kind of new BGP route advertised by that ETR-like BR.  There
 is no provision for solving the PMTUD problems inherent in
 encapsulation-based tunneling.
 ITR functions must be performed by already busy routers of ISPs,
 rather than being distributed to other routers or to sending hosts.
 There is no practical support for mobility.  The mapping in each end-
 user route advertisement includes a REMOTE-PREFERENCE for each ETR-
 like BR, but this is used by the ITR-like functions of BRs to always
 select the LOCATOR with the highest value.  As currently described,
 TIDR does not provide inbound load-splitting TE.
 Multihoming service restoration is achieved initially by the ETR-like
 function of the BR at the ISP (whose link to the end-user network has
 just failed).  It looks up the mapping to find the next preferred
 ETR-like BR's address.  The first ETR-like router tunnels the packets
 to the second ETR-like router in the other ISP.  However, if the
 failure was caused by the first ISP itself being unreachable, then
 connectivity would not be restored until a revised mapping (with
 higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the
 second ISP propagated across the DFZ to all ITR-like routers, or the
 withdrawn advertisement for the first one reaches the ITR-like
 router.

11.3. Rebuttal

 No rebuttal was submitted for this proposal.

12. Identifier-Locator Network Protocol (ILNP)

12.1. Summary

12.1.1. Key Ideas

 o  Provides crisp separation of Identifiers from Locators.
 o  Identifiers name nodes, not interfaces.

Li Informational [Page 42] RFC 6115 RRG Recommendation February 2011

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

12.1.2. Benefits

 o  The underlying protocol mechanisms support fully scalable site
    multihoming, node multihoming, site mobility, and node mobility.
 o  ILNP enables topological aggregation of location information while
    providing stable and topology-independent identities for nodes.
 o  In turn, this topological aggregation reduces both the routing
    prefix "churn" rate and the overall size of the Internet's global
    routing table, by eliminating the value and need for more-specific
    routing state currently carried throughout the global (default-
    free) zone of the routing system.
 o  ILNP enables improved traffic engineering capabilities without
    adding any state to the global routing system.  TE capabilities
    include both provider-driven TE and also end-site-controlled TE.
 o  ILNP's mobility approach:
  • eliminates the need for special-purpose routers (e.g., home

agent and/or foreign agent now required by Mobile IP and NEMO).

  • eliminates "triangle routing" in all cases.
  • supports both "make before break" and "break before make"

layer-3 handoffs.

 o  ILNP improves resilience and network availability while reducing
    the global routing state (as compared with the currently deployed
    Internet).
 o  ILNP is incrementally deployable:
  • No changes are required to existing IPv6 (or IPv4) routers.

Li Informational [Page 43] RFC 6115 RRG Recommendation February 2011

  • Upgraded nodes gain benefits immediately ("day one"); those

benefits gain in value as more nodes are upgraded (this follows

       Metcalfe's Law).
  • The incremental deployment approach is documented.
 o  ILNP is backwards compatible:
  • ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully

backwards compatible with IPv4).

  • Reuses existing known-to-scale DNS mechanisms to provide

identifier/locator mapping.

  • Existing DNS security mechanisms are reused without change.
  • Existing IP Security mechanisms are reused with one minor

change (IPsec Security Associations replace the current use of

       IP addresses with the use of Identifier values).  NB: IPsec is
       also backwards compatible.
  • The backwards compatibility approach is documented.
 o  No new or additional overhead is required to determine or to
    maintain locator/path liveness.
 o  ILNP does not require locator rewriting (NAT); ILNP permits and
    tolerates NAT, should that be desirable in some deployment(s).
 o  Changes to upstream network providers do not require node or
    subnetwork renumbering within end-sites.
 o  ILNP is compatible with and can facilitate the transition from
    current single-path TCP to multipath TCP.
 o  ILNP can be implemented such that existing applications (e.g.,
    applications using the BSD Sockets API) do NOT need any changes or
    modifications to use ILNP.

12.1.3. Costs

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

Li Informational [Page 44] RFC 6115 RRG Recommendation February 2011

12.1.4. References

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

12.2. Critique

 The primary issue for ILNP is how the deployment incentives and
 benefits line up with the RRG goal of reducing the rate of growth of
 entries and churn in the core routing table.  If a site is currently
 using PI space, it can only stop advertising that space when the
 entire site is ILNP capable.  This needs (at least) clear elucidation
 of the incentives for ILNP which are not related to routing scaling,
 in order for there to be a path for this to address the RRG needs.
 Similarly, the incentives for upgrading hosts need to align with the
 value for those hosts.
 A closely related question is whether this mechanism actually
 addresses the sites need for PI addresses.  Assuming ILNP is
 deployed, the site does achieve flexible, resilient, communication
 using all of its Internet connections.  While the proposal addresses
 the host updates when the host learns of provider changes, there are
 other aspects of provider change that are not addressed.  This
 includes renumbering routers, subnets, and certain servers.  (It is
 presumed that most servers, once the entire site has moved to ILNP,
 will not be concerned if their locator changes.  However, some
 servers must have known locators, such as the DNS server.)  The
 issues described in [RFC5887] will be ameliorated, but not resolved.
 To be able to adopt this proposal, and have sites use it, we need to
 address these issues.  When a site changes points of attachment, only
 a small amount of DNS provisioning should be required.  The LP
 resource record type is apparently intended to help with this.  It is
 also likely that the use of dynamic DNS will help this.
 The ILNP mechanism is described as being suitable for use in
 conjunction with mobility.  This raises the question of race
 conditions.  To the degree that mobility concerns are valid at this
 time, it is worth asking how communication can be established if a
 node is sufficiently mobile that it is moving faster than the DNS
 update and DNS fetch cycle can effectively propagate changes.
 This proposal does presume that all communication using this
 mechanism is tied to DNS names.  While it is true that most
 communication does start from a DNS name, it is not the case that all
 exchanges have this property.  Some communication initiation and
 referral can be done with an explicit identifier/locator pair.  This
 does appear to require some extensions to the existing mechanism (for

Li Informational [Page 45] RFC 6115 RRG Recommendation February 2011

 both sides to add locators).  In general, some additional clarity on
 the assumptions regarding DNS, particularly for low-end devices,
 would seem appropriate.
 One issue that this proposal shares with many others is the question
 of how to determine which locator pairs (local and remote) are
 actually functional.  This is an issue both for initial
 communications establishment and for robustly maintaining
 communication.  It is likely that a combination of monitoring of
 traffic (in the host, where this is tractable), coupled with other
 active measures, can address this.  ICMP is clearly insufficient.

12.3. Rebuttal

 ILNP eliminates the perceived need for PI addressing and encourages
 increased DFZ aggregation.  Many enterprise users view DFZ scaling
 issues as too abstruse, so ILNP creates more user-visible incentives
 to upgrade deployed systems.
 ILNP mobility eliminates Duplicate Address Detection (DAD), reducing
 the layer-3 handoff time significantly when compared to IETF standard
 Mobile IP, as shown in [MobiArch1] and [MobiArch2].  ICMP location
 updates separately reduce the layer-3 handoff latency.
 Also, ILNP enables both host multihoming and site multihoming.
 Current BGP approaches cannot support host multihoming.  Host
 multihoming is valuable in reducing the site's set of externally
 visible nodes.
 Improved mobility support is very important.  This is shown by the
 research literature and also appears in discussions with vendors of
 mobile devices (smartphones, MP3 players).  Several operating system
 vendors push "updates" with major networking software changes in
 maintenance releases today.  Security concerns mean most hosts
 receive vendor updates more quickly these days.
 ILNP enables a site to hide exterior connectivity changes from
 interior nodes, using various approaches.  One approach deploys
 unique local address (ULA) prefixes within the site, and has the site
 border router(s) rewrite the Locator values.  The usual NAT issues
 don't arise because the Locator value is not used above the network-
 layer.  [MILCOM1] [MILCOM2]
 [RFC5902] makes clear that many users desire IPv6 NAT, with site
 interior obfuscation as a major driver.  This makes global-scope PI
 addressing much less desirable for end sites than formerly.

Li Informational [Page 46] RFC 6115 RRG Recommendation February 2011

 ILNP-capable nodes can talk existing IP with legacy IP-only nodes,
 with no loss of current IP capability.  So, ILNP-capable nodes will
 never be worse off.
 Secure Dynamic DNS Update is standard and widely supported in
 deployed hosts and DNS servers.  [DNSnBIND] says many sites have
 deployed this technology without realizing it (e.g., by enabling both
 the DHCP server and Active Directory of the MS-Windows Server).
 If a node is as mobile as the critique says, then existing IETF
 Mobile IP standards also will fail.  They also use location updates
 (e.g., MN -> home agent, MN -> foreign agent).
 ILNP also enables new approaches to security that eliminate
 dependence upon location-dependent Access Control Lists (ACLs)
 without packet authentication.  Instead, security appliances track
 flows using Identifier values and validate the identifier/locator
 relationship cryptographically [RFC4033] [RFC4034] [RFC4035] or non-
 cryptographically by reading the nonce [ILNP_Nonce].
 The DNS LP record has a more detailed explanation now.  LP records
 enable a site to change its upstream connectivity by changing the L
 resource records of a single FQDN covering the whole site, thereby
 providing scalability.
 DNS-based server load balancing works well with ILNP by using DNS SRV
 records.  DNS SRV records are not new, are widely available in DNS
 clients and servers, and are widely used today in the IPv4 Internet
 for server load balancing.
 Recent ILNP documents discuss referrals in more detail.  A node with
 a binary referral can find the FQDN using DNS PTR records, which can
 be authenticated [RFC4033] [RFC4034] [RFC4035].  Approaches such as
 [Referral_Obj] improve user experience and user capability, so are
 likely to self-deploy.
 Selection from multiple Locators is identical to an IPv4 system
 selecting from multiple A records for its correspondent.  Deployed IP
 nodes can track reachability via existing host mechanisms or by using
 the SHIM6 method.  [RFC5534]

Li Informational [Page 47] RFC 6115 RRG Recommendation February 2011

13. Enhanced Efficiency of Mapping Distribution Protocols in

   Map-and-Encap Schemes (EEMDP)

13.1. Summary

13.1.1. Introduction

 We present some architectural principles pertaining to the mapping
 distribution protocols, especially applicable to the map-and-encap
 (e.g., LISP) type of protocols.  These principles enhance the
 efficiency of the map-and-encap protocols in terms of (1) better
 utilization of resources (e.g., processing and memory) at Ingress
 Tunnel Routers (ITRs) and mapping servers, and consequently, (2)
 reduction of response time (e.g., first-packet delay).  We consider
 how Egress Tunnel Routers (ETRs) can perform aggregation of endpoint
 ID (EID) address space belonging to their downstream delivery
 networks, in spite of migration/re-homing of some subprefixes to
 other ETRs.  This aggregation may be useful for reducing the
 processing load and memory consumption associated with map messages,
 especially at some resource-constrained ITRs and subsystems of the
 mapping distribution system.  We also consider another architectural
 concept where the ETRs are organized in a hierarchical manner for the
 potential benefit of aggregation of their EID address spaces.  The
 two key architectural ideas are discussed in some more detail below.
 A more complete description can be found in [EEMDP_Considerations]
 and [EEMDP_Presentation].
 It will be helpful to refer to Figures 1, 2, and 3 in
 [EEMDP_Considerations] for some of the discussions that follow here
 below.

13.1.2. Management of Mapping Distribution of Subprefixes Spread across

       Multiple ETRs
 To assist in this discussion, we start with the high level
 architecture of a map-and-encap approach (it would be helpful to see
 Figure 1 in [EEMDP_Considerations]).  In this architecture, we have
 the usual ITRs, ETRs, delivery networks, etc.  In addition, we have
 the ID-Locator Mapping (ILM) servers, which are repositories for
 complete mapping information, while the ILM-Regional (ILM-R) servers
 can contain partial and/or regionally relevant mapping information.
 While a large endpoint address space contained in a prefix may be
 mostly associated with the delivery networks served by one ETR, some
 fragments (subprefixes) of that address space may be located
 elsewhere at other ETRs.  Let a/20 denote a prefix that is
 conceptually viewed as composed of 16 subnets of /24 size that are
 denoted as a1/24, a2/24, ..., a16/24.  For example, a/20 is mostly at

Li Informational [Page 48] RFC 6115 RRG Recommendation February 2011

 ETR1, while only two of its subprefixes a8/24 and a15/24 are
 elsewhere at ETR3 and ETR2, respectively (see Figure 2
 [EEMDP_Considerations]).  From the point of view of efficiency of the
 mapping distribution protocol, it may be beneficial for ETR1 to
 announce a map for the entire space a/20 (rather than fragment it
 into a multitude of more-specific prefixes), and provide the
 necessary exceptions in the map information.  Thus, the map message
 could be in the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24).
 In addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24,
 respectively, and so the ILMs know where the exception EID addresses
 are located.  Now consider a host associated with ITR1 initiating a
 packet destined for an address a7(1), which is in a7/24 that is not
 in the exception portion of a/20.  Now a question arises as to which
 of the following approaches would be the best choice:
 1.  ILM-R provides the complete mapping information for a/20 to ITR1
     including all maps for relevant exception subprefixes.
 2.  ILM-R provides only the directly relevant map to ITR1, which in
     this case is (a/20, ETR1).
 In the first approach, the advantage is that ITR1 would have the
 complete mapping for a/20 (including exception subnets), and it would
 not have to generate queries for subsequent first packets that are
 destined to any address in a/20, including a8/24 and a15/24.
 However, the disadvantage is that if there is a significant number of
 exception subprefixes, then the very first packet destined for a/20
 will experience a long delay, and also the processors at ITR1 and
 ILM-R can experience overload.  In addition, the memory usage at ITR1
 can be very inefficient.  The advantage of the second approach above
 is that the ILM-R does not overload resources at ITR1, neither in
 terms of processing or memory usage, but it needs an enhanced map
 response in of the form Map:(a/20, ETR1, MS=1), where the MS (More
 Specific) indicator is set to 1 to indicate to ITR1 that not all
 subnets in a/20 map to ETR1.  The key idea is that aggregation is
 beneficial, and subnet exceptions must be handled with additional
 messages or indicators in the maps.

13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy

       of ETRs and Multihoming
 Now we highlight another architectural concept related to mapping
 management (please refer to Figure 3 in [EEMDP_Considerations]).
 Here we consider the possibility that ETRs may be organized in a
 hierarchical manner.  For instance, ETR7 is higher in the hierarchy
 relative to ETR1, ETR2, and ETR3, and like-wise ETR8 is higher
 relative to ETR4, ETR5, and ETR6.  For instance, ETRs 1 through 3 can
 relegate the locator role to ETR7 for their EID address space.  In

Li Informational [Page 49] RFC 6115 RRG Recommendation February 2011

 essence, they can allow ETR7 to act as the locator for the delivery
 networks in their purview.  ETR7 keeps a local mapping table for
 mapping the appropriate EID address space to specific ETRs that are
 hierarchically associated with it in the level below.  In this
 situation, ETR7 can perform EID address space aggregation across ETRs
 1 through 3 and can also include its own immediate EID address space
 for the purpose of that aggregation.  The many details related to
 this approach and special circumstances involving multihoming of
 subnets are discussed in detail in [EEMDP_Considerations].  The
 hierarchical organization of ETRs and delivery networks should help
 in the future growth and scalability of ETRs and mapping distribution
 networks.  This is essentially recursive map-and-encap, and some of
 the mapping distribution and management functionality will remain
 local to topologically neighboring delivery networks that are
 hierarchically underneath ETRs.

13.1.4. References

 [EEMDP_Considerations] [EEMDP_Presentation] [FIBAggregatability]

13.2. Critique

 The scheme described in [EEMDP_Considerations] represents one
 approach to mapping overhead reduction, and it is a general idea that
 is applicable to any proposal that includes prefix or EID
 aggregation.  A somewhat similar idea is also used in Level-3
 aggregation in the FIB aggregation proposal [FIBAggregatability].
 There can be cases where deaggregation of EID prefixes occur in such
 a way that the bulk of an EID prefix P would be attached to one
 locator (say, ETR1) while a few subprefixes under P would be attached
 to other locators elsewhere (say, ETR2, ETR3, etc.).  Ideally, such
 cases should not happen; however, in reality it can happen as the
 RIR's address allocations are imperfect.  In addition, as new IP
 address allocations become harder to get, an IPv4 prefix owner might
 split previously unused subprefixes of that prefix and allocate them
 to remote sites (homed to other ETRs).  Assuming these situations
 could arise in practice, the nature of the solution would be that the
 response from the mapping server for the coarser site would include
 information about the more specifics.  The solution as presented
 seems correct.
 The proposal mentions that in Approach 1, the ID-Locator Mapping
 (ILM) system provides the complete mapping information for an
 aggregate EID prefix to a querying ITR, including all the maps for
 the relevant exception subprefixes.  The sheer number of such more-
 specifics can be worrisome, for example, in LISP.  What if a
 company's mobile-node EIDs came out of their corporate EID prefix?
 Approach 2 is far better but still there may be too many entries for

Li Informational [Page 50] RFC 6115 RRG Recommendation February 2011

 a regional ILM to store.  In Approach 2, the ILM communicates that
 there are more specifics but does not communicate their mask-length.
 A suggested improvement would be that rather than saying that there
 are more specifics, indicate what their mask-lengths are.  There can
 be multiple mask lengths.  This number should be pretty small for
 IPv4 but can be large for IPv6.
 Later in the proposal, a different problem is addressed, involving a
 hierarchy of ETRs and how aggregation of EID prefixes from lower-
 level ETRs can be performed at a higher-level ETR.  The various
 scenarios here are well illustrated and described.  This seems like a
 good idea, and a solution like LISP can support this as specified.
 As any optimization scheme would inevitably add some complexity; the
 proposed scheme for enhancing mapping efficiency comes with some of
 its own overhead.  The gain depends on the details of specific EID
 blocks, i.e., how frequently the situations (such as an ETR that has
 a bigger EID block with a few holes) arise.

13.3. Rebuttal

 There are two main points in the critique that are addressed here:
 (1) The gain depends on the details of specific EID blocks, i.e., how
 frequently the situations arise such as an ETR having a bigger EID
 block with a few holes, and (2) Approach 2 is lacking an added
 feature of conveying just the mask-length of the more specifics that
 exist as part of the current map response.
 Regarding comment (1) above, there are multiple possibilities
 regarding how situations can arise, resulting in allocations having
 holes in them.  An example of one of these possibilities is as
 follows.  Org-A has historically received multiple /20s, /22s, and
 /24s over the course of time that are adjacent to each other.  At the
 present time, these prefixes would all aggregate to a /16 but for the
 fact that just a few of the underlying /24s have been allocated
 elsewhere historically to other organizations by an RIR or ISPs.  An
 example of a second possibility is that Org-A has an allocation of a
 /16.  It has suballocated a /22 to one of its subsidiaries, and
 subsequently sold the subsidiary to another Org-B.  For ease of
 keeping the /22 subnet up and running without service disruption, the
 /22 subprefix is allowed to be transferred in the acquisition
 process.  Now the /22 subprefix originates from a different AS and is
 serviced by a different ETR (as compared to the parent \16 prefix).
 We are in the process of performing an analysis of RIR allocation
 data and are aware of other studies (notably at UCLA) that are also
 performing similar analysis to quantify the frequency of occurrence
 of the holes.  We feel that the problem that has been addressed is a
 realistic one, and the proposed scheme would help reduce the
 overheads associated with the mapping distribution system.

Li Informational [Page 51] RFC 6115 RRG Recommendation February 2011

 Regarding comment (2) above, the suggested modification to Approach 2
 would be definitely beneficial.  In fact, we feel that it would be
 fairly straightforward to dynamically use Approach 1 or Approach 2
 (with the suggested modification), depending on whether there are
 only a few (e.g., <=5) or many (e.g., >5) more specifics,
 respectively.  The suggested modification of notifying the mask-
 length of the more specifics in the map response is indeed very
 helpful because then the ITR would not have to resend a map-query for
 EID addresses that match the EID address in the previous query up to
 at least mask-length bit positions.  There can be a two-bit field in
 the map response that would be interpreted as follows.
 (a)  value 00: there are no more specifics
 (b)  value 01: there are more specifics and their exact information
      follows in additional map-responses
 (c)  value 10: there are more-specifics and the mask-length of the
      next more-specific is indicated in the current map-response.
 An additional field will be included that will be used to specify the
 mask-length of the next more-specific in the case of value 10 (case
 (c) above).

14. Evolution

14.1. Summary

 As the Internet continues its rapid growth, router memory size and
 CPU cycle requirements are outpacing feasible hardware upgrade
 schedules.  We propose to solve this problem by applying aggregation
 with increasing scopes to gradually evolve the routing system towards
 a scalable structure.  At each evolutionary step, our solution is
 able to interoperate with the existing system and provide immediate
 benefits to adopters to enable deployment.  This document summarizes
 the need for an evolutionary design, the relationship between our
 proposal and other revolutionary proposals, and the steps of
 aggregation with increasing scopes.  Our detailed proposal can be
 found in [Evolution].

14.1.1. Need for Evolution

 Multiple different views exist regarding the routing scalability
 problem.  Networks differ vastly in goals, behavior, and resources,
 giving each a different view of the severity and imminence of the
 scalability problem.  Therefore, we believe that, for any solution to
 be adopted, it will start with one or a few early adopters and may
 not ever reach the entire Internet.  The evolutionary approach

Li Informational [Page 52] RFC 6115 RRG Recommendation February 2011

 recognizes that changes to the Internet can only be a gradual process
 with multiple stages.  At each stage, adopters are driven by and
 rewarded with solving an immediate problem.  Each solution must be
 deployable by individual networks who deem it necessary at a time
 they deem it necessary, without requiring coordination from other
 networks, and the solution has to bring immediate relief to a single
 first-mover.

14.1.2. Relation to Other RRG Proposals

 Most proposals take a revolutionary approach that expects the entire
 Internet to eventually move to some new design whose main benefits
 would not materialize until the vast majority of the system has been
 upgraded; their incremental deployment plan simply ensures
 interoperation between upgraded and legacy parts of the system.  In
 contrast, the evolutionary approach depicts a system where changes
 may happen here and there as needed, but there is no dependency on
 the system as a whole making a change.  Whoever takes a step forward
 gains the benefit by solving his own problem, without depending on
 others to take actions.  Thus, deployability includes not only
 interoperability, but also the alignment of costs and gains.
 The main differences between our approach and more revolutionary map-
 and-encap proposals are: (a) we do not start with a pre-defined
 boundary between edge and core; and (b) each step brings immediate
 benefits to individual first-movers.  Note that our proposal neither
 interferes nor prevents any revolutionary host-based solutions such
 as ILNP from being rolled out.  However, host-based solutions do not
 bring useful impact until a large portion of hosts have been
 upgraded.  Thus, even if a host-based solution is rolled out in the
 long run, an evolutionary solution is still needed for the near term.

14.1.3. Aggregation with Increasing Scopes

 Aggregating many routing entries to a fewer number is a basic
 approach to improving routing scalability.  Aggregation can take
 different forms and be done within different scopes.  In our design,
 the aggregation scope starts from a single router, then expands to a
 single network and neighbor networks.  The order of the following
 steps is not fixed but is merely a suggestion; it is under each
 individual network's discretion which steps they choose to take based
 on their evaluation of the severity of the problems and the
 affordability of the solutions.
 1.  FIB Aggregation (FA) in a single router.  A router
     algorithmically aggregates its FIB entries without changing its
     RIB or its routing announcements.  No coordination among routers

Li Informational [Page 53] RFC 6115 RRG Recommendation February 2011

     is needed, nor any change to existing protocols.  This brings
     scalability relief to individual routers with only a software
     upgrade.
 2.  Enabling 'best external' on Provider Edge routers (PEs),
     Autonomous System Border Routers (ASBRs), and Route Reflectors
     (RRs), and turning on next-hop-self on RRs.  For hierarchical
     networks, the RRs in each Point of Presence (PoP) can serve as a
     default gateway for nodes in the PoP, thus allowing the non-RR
     nodes in each PoP to maintain smaller routing tables that only
     include paths that egress that PoP.  This is known as 'topology-
     based mode' Virtual Aggregation, and can be done with existing
     hardware and configuration changes only.  Please see
     [Evolution_Grow_Presentation] for details.
 3.  Virtual Aggregation (VA) in a single network.  Within an AS, some
     fraction of existing routers are designated as Aggregation Point
     Routers (APRs).  These routers are either individually or
     collectively maintain the full FIB table.  Other routers may
     suppress entries from their FIBs, instead forwarding packets to
     APRs, which will then tunnel the packets to the correct egress
     routers.  VA can be viewed as an intra-domain map-and-encap
     system to provide the operators with a control mechanism for the
     FIB size in their routers.
 4.  VA across neighbor networks.  When adjacent networks have VA
     deployed, they can go one step further by piggybacking egress
     router information on existing BGP announcements, so that packets
     can be tunneled directly to a neighbor network's egress router.
     This improves packet delivery performance by performing the
     encapsulation/decapsulation only once across these neighbor
     networks, as well as reducing the stretch of the path.
 5.  Reducing RIB Size by separating the control plane from the data
     plane.  Although a router's FIB can be reduced by FA or VA, it
     usually still needs to maintain the full RIB to produce complete
     routing announcements to its neighbors.  To reduce the RIB size,
     a network can set up special boxes, which we call controllers, to
     take over the External BGP (eBGP) sessions from border routers.
     The controllers receive eBGP announcements, make routing
     decisions, and then inform other routers in the same network of
     how to forward packets, while the regular routers just focus on
     the job of forwarding packets.  The controllers, not being part
     of the data path, can be scaled using commodity hardware.
 6.  Insulating forwarding routers from routing churn.  For routers
     with a smaller RIB, the rate of routing churn is naturally
     reduced.  Further reduction can be achieved by not announcing

Li Informational [Page 54] RFC 6115 RRG Recommendation February 2011

     failures of customer prefixes into the core, but handling these
     failures in a data-driven fashion, e.g., a link failure to an
     edge network is not reported unless and until there are data
     packets that are heading towards the failed link.

14.1.4. References

 [Evolution] [Evolution_Grow_Presentation]

14.2. Critique

 All of the RRG proposals that scale the routing architecture share
 one fundamental approach, route aggregation, in different forms,
 e.g., LISP removes "edge prefixes" using encapsulation at ITRs, and
 ILNP achieves the goal by locator rewrite.  In this evolutionary path
 proposal, each stage of the evolution applies aggregation with
 increasing scopes to solve a specific scalability problem, and
 eventually the path leads towards global routing scalability.  For
 example, it uses FIB aggregation at the single router level, virtual
 aggregation at the network level, and then between neighboring
 networks at the inter-domain level.
 Compared to other proposals, this proposal has the lowest hurdle to
 deployment, because it does not require that all networks move to use
 a global mapping system or upgrade all hosts, and it is designed for
 each individual network to get immediate benefits after its own
 deployment.
 Criticisms of this proposal fall into two types.  The first type
 concerns several potential issues in the technical design as listed
 below:
 1.  FIB aggregation, at level-3 and level-4, may introduce extra
     routable space.  Concerns have been raised about the potential
     routing loops resulting from forwarding otherwise non-routable
     packets, and the potential impact on Reverse Path Forwarding
     (RPF) checking.  These concerns can be addressed by choosing a
     lower level of aggregation and by adding null routes to minimize
     the extra space, at the cost of reduced aggregation gain.
 2.  Virtual Aggregation changes the traffic paths in an ISP network,
     thereby introducing stretch.  Changing the traffic path may also
     impact the reverse path checking practice used to filter out
     packets from spoofed sources.  More analysis is need to identify
     the potential side-effects of VA and to address these issues.

Li Informational [Page 55] RFC 6115 RRG Recommendation February 2011

 3.  The current Virtual Aggregation description is difficult to
     understand, due to its multiple options for encapsulation and
     popular prefix configurations, which makes the mechanism look
     overly complicated.  More thought is needed to simplify the
     design and description.
 4.  FIB Aggregation and Virtual Aggregation may require additional
     operational cost.  There may be new design trade-offs that the
     operators need to understand in order to select the best option
     for their networks.  More analysis is needed to identify and
     quantify all potential operational costs.
 5.  In contrast to a number of other proposals, this solution does
     not provide mobility support.  It remains an open question as to
     whether the routing system should handle mobility.
 The second criticism is whether deploying quick fixes like FIB
 aggregation would alleviate scalability problems in the short term
 and reduce the incentives for deploying a new architecture; and
 whether an evolutionary approach would end up with adding more and
 more patches to the old architecture, and not lead to a fundamentally
 new architecture as the proposal had expected.  Though this solution
 may get rolled out more easily and quickly, a new architecture, if/
 once deployed, could solve more problems with cleaner solutions.

14.3. Rebuttal

 No rebuttal was submitted for this proposal.

15. Name-Based Sockets

15.1. Summary

 Name-based sockets are an evolution of the existing address-based
 sockets, enabling applications to initiate and receive communication
 sessions based on the use of domain names in lieu of IP addresses.
 Name-based sockets move the existing indirection from domain names to
 IP addresses from its current position in applications down to the IP
 layer.  As a result, applications communicate exclusively based on
 domain names, while the discovery, selection, and potentially in-
 session re-selection of IP addresses is centrally performed by the IP
 stack itself.
 Name-based sockets help mitigate the Internet routing scalability
 problem by separating naming and addressing more consistently than
 what is possible with the existing address-based sockets.  This
 supports IP address aggregation because it simplifies the use of IP

Li Informational [Page 56] RFC 6115 RRG Recommendation February 2011

 addresses with high topological significance, as well as the dynamic
 replacement of IP addresses during network-topological and host-
 attachment changes.
 A particularly positive effect of name-based sockets on Internet
 routing scalability is the new incentives for edge network operators
 to use provider-assigned IP addresses, which are more aggregatable
 than the typically preferred provider-independent IP addresses.  Even
 though provider-independent IP addresses are harder to get and more
 expensive than provider-assigned IP addresses, many operators desire
 provider-independent addresses due to the high indirect cost of
 provider-assigned IP addresses.  This indirect cost is comprised of
 both difficulties in multihoming, and tedious and largely manual
 renumbering upon provider changes.
 Name-based sockets reduce the indirect cost of provider-assigned IP
 addresses in three ways, and hence make the use of provider-assigned
 IP addresses more acceptable: (1) They enable fine-grained and
 responsive multihoming. (2) They simplify renumbering by offering an
 easy means to replace IP addresses in referrals with domain names.
 This helps avoiding updates to application and operating system
 configurations, scripts, and databases during renumbering. (3) They
 facilitate low-cost solutions that eliminate renumbering altogether.
 One such low-cost solution is IP address translation, which in
 combination with name-based sockets loses its adverse impact on
 applications.
 The prerequisite for a positive effect of name-based sockets on
 Internet routing scalability is their adoption in operating systems
 and applications.  Operating systems should be augmented to offer
 name-based sockets as a new alternative to the existing address-based
 sockets, and applications should use name-based sockets for their
 communications.  Neither an instantaneous, nor an eventually complete
 transition to name-based sockets is required, yet the positive effect
 on Internet routing scalability will grow with the extent of this
 transition.
 Name-based sockets were hence designed with a focus on deployment
 incentives, comprising both immediate deployment benefits as well as
 low deployment costs.  Name-based sockets provide a benefit to
 application developers because the alleviation of applications from
 IP address management responsibilities simplifies and expedites
 application development.  This benefit is immediate owing to the
 backwards compatibility of name-based sockets with legacy
 applications and legacy peers.  The appeal to application developers,
 in turn, is an immediate benefit for operating system vendors who
 adopt name-based sockets.

Li Informational [Page 57] RFC 6115 RRG Recommendation February 2011

 Name-based sockets furthermore minimize deployment costs: Alternative
 techniques to separate naming and addressing provide applications
 with "surrogate IP addresses" that dynamically map onto regular IP
 addresses.  A surrogate IP address is indistinguishable from a
 regular IP address for applications, but does not have the
 topological significance of a regular IP address.  Mobile IP and the
 Host Identity Protocol are examples of such separation techniques.
 Mobile IP uses "home IP addresses" as surrogate IP addresses with
 reduced topological significance.  The Host Identity Protocol uses
 "host identifiers" as surrogate IP addresses without topological
 significance.  A disadvantage of surrogate IP addresses is their
 incurred cost in terms of extra administrative overhead and, for some
 techniques, extra infrastructure.  Since surrogate IP addresses must
 be resolvable to the corresponding regular IP addresses, they must be
 provisioned in the DNS or similar infrastructure.  Mobile IP uses a
 new infrastructure of home agents for this purpose, while the Host
 Identity Protocol populates DNS servers with host identities.  Name-
 based sockets avoid this cost because they function without surrogate
 IP addresses, and hence without the provisioning and infrastructure
 requirements that accompany surrogate addresses.
 Certainly, some edge networks will continue to use provider-
 independent addresses despite name-based sockets, perhaps simply due
 to inertia.  But name-based sockets will help reduce the number of
 those networks, and thus have a positive impact on Internet routing
 scalability.
 A more comprehensive description of name-based sockets can be found
 in [Name_Based_Sockets].

15.1.1. References

 [Name_Based_Sockets]

15.2. Critique

 Name-based sockets contribution to the routing scalability problem is
 to decrease the reliance on PI addresses, allowing a greater use of
 PA addresses, and thus a less fragmented routing table.  It provides
 end hosts with an API which makes the applications address-agnostic.
 The name abstraction allows the hosts to use any type of locator,
 independent of format or provider.  This increases the motivation and
 usability of PA addresses.  Some applications, in particular
 bootstrapping applications, may still require hard coded IP
 addresses, and as such will still motivate the use of PI addresses.

Li Informational [Page 58] RFC 6115 RRG Recommendation February 2011

15.2.1. Deployment

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

15.2.2. Edge-networks

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

15.3. Rebuttal

 No rebuttal was submitted for this proposal.

16. Routing and Addressing in Networks with Global Enterprise Recursion

   (IRON-RANGER)

16.1. Summary

 RANGER is a locator/identifier separation approach that uses IP-in-IP
 encapsulation to connect edge networks across transit networks such
 as the global Internet.  End systems use endpoint interface
 identifier (EID) addresses that may be routable within edge networks
 but do not appear in transit network routing tables.  EID to Routing

Li Informational [Page 59] RFC 6115 RRG Recommendation February 2011

 Locator (RLOC) address bindings are instead maintained in mapping
 tables and also cached in default router FIBs (i.e., very much the
 same as for the global DNS and its associated caching resolvers).
 RANGER enterprise networks are organized in a recursive hierarchy
 with default mappers connecting lower layers to the next higher layer
 in the hierarchy.  Default mappers forward initial packets and push
 mapping information to lower-tier routers and end systems through
 secure redirection.
 RANGER is an architectural framework derived from the Intra-Site
 Automatic Tunnel Addressing Protocol (ISATAP).

16.1.1. Gains

 o  provides a scalable routing system alternative in instances where
    dynamic routing protocols are impractical
 o  naturally supports a recursively-nested "network-of-networks" (or,
    "enterprise-within-enterprise") hierarchy
 o  uses asymmetric security mechanisms (i.e., secure neighbor
    discovery) to secure router discovery and the redirection
    mechanism
 o  can quickly detect path failures and pick alternate routes
 o  naturally supports provider-independent addressing
 o  support for site multihoming and traffic engineering
 o  ingress filtering for multihomed sites
 o  mobility-agile through explicit cache invalidation (much more
    reactive than dynamic DNS)
 o  supports neighbor discovery and neighbor unreachability detection
    over tunnels
 o  no changes to end systems
 o  no changes to most routers
 o  supports IPv6 transition

Li Informational [Page 60] RFC 6115 RRG Recommendation February 2011

 o  compatible with true identity/locator split mechanisms such as HIP
    (i.e., packets contain a HIP Host Identity Tag (HIT) as an end
    system identifier, IPv6 address as endpoint interface identifier
    (EID) in the inner IP header and IPv4 address as Routing LOCator
    (RLOC) in the outer IP header)
 o  prototype code available

16.1.2. Costs

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

16.1.3. References

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

16.2. Critique

 The RANGER architectural framework is intended to be applicable for a
 Core-Edge Separation (CES) architecture for scalable routing, using
 either IPv4 or IPv6 -- or using both in an integrated system which
 may carry one protocol over the other.
 However, despite [IRON] being readied for publication as an
 experimental RFC, the framework falls well short of the level of
 detail required to envisage how it could be used to implement a
 practical scalable routing solution.  For instance, the document
 contains no specification for a mapping protocol, or how the mapping
 lookup system would work on a global scale.
 There is no provision for RANGER's ITR-like routers being able to
 probe the reachability of end-user networks via multiple ETR-like
 routers -- nor for any other approach to multihoming service
 restoration.
 Nor is there any provision for inbound TE or support of mobile
 devices which frequently change their point of attachment.
 Therefore, in its current form, RANGER cannot be contemplated as a
 superior scalable routing solution to some other proposals which are
 specified in sufficient detail and which appear to be feasible.

Li Informational [Page 61] RFC 6115 RRG Recommendation February 2011

 RANGER uses its own tunneling and PMTUD management protocol: SEAL.
 Adoption of SEAL in its current form would prevent the proper
 utilization of jumbo frame paths in the DFZ, which will become the
 norm in the future.  SEAL uses "Packet Too Big" [RFC4443] and
 "Fragmentation Needed" [RFC0792] messages to the sending host only to
 fix a preset maximum packet length.  To avoid the need for the SEAL
 layer to fragment packets of this length, this MTU value (for the
 input of the tunnel) needs to be set significantly below 1500 bytes,
 assuming the typically ~1500 byte MTU values for paths across the DFZ
 today.  In order to avoid this excessive fragmentation, this value
 could only be raised to a ~9k byte value at some time in the future
 where essentially all paths between ITRs and ETRs were jumbo frame
 capable.

16.3. Rebuttal

 The Internet Routing Overlay Network (IRON) [IRON] is a scalable
 Internet routing architecture that builds on the RANGER recursive
 enterprise network hierarchy [RFC5720].  IRON bonds together
 participating RANGER networks using VET [VET] and SEAL [SEAL] to
 enable secure and scalable routing through automatic tunneling within
 the Internet core.  The IRON-RANGER automatic tunneling abstraction
 views the entire global Internet DFZ as a virtual Non-Broadcast
 Multi-Access (NBMA) link similar to ISATAP [RFC5214].
 IRON-RANGER is an example of a Core-Edge Separation (CES) system.
 Instead of a classical mapping database, however, IRON-RANGER uses a
 hybrid combination of a proactive dynamic routing protocol for
 distributing highly aggregated Virtual Prefixes (VPs) and an on-
 demand data driven protocol for distributing more-specific Provider-
 Independent (PI) prefixes derived from the VPs.
 The IRON-RANGER hierarchy consists of recursively-nested RANGER
 enterprise networks joined together by IRON routers that participate
 in a global BGP instance.  The IRON BGP instance is maintained
 separately from the current Internet BGP Routing LOCator (RLOC)
 address space (i.e., the set of all public IPv4 prefixes in the
 Internet).  Instead, the IRON BGP instance maintains VPs taken from
 Endpoint Interface iDentifier (EID) address space, e.g., the IPv6
 global unicast address space.  To accommodate scaling, only O(10k) --
 O(100k) VPs are allocated e.g., using /20 or shorter IPv6 prefixes.
 IRON routers lease portions of their VPs as Provider-Independent (PI)
 prefixes for customer equipment (CEs), thereby creating a sustainable
 business model.  CEs that lease PI prefixes propagate address
 mapping(s) throughout their attached RANGER networks and up to VP-
 owning IRON router(s) through periodic transmission of "bubbles" with
 authentication and PI prefix information.  Routers in RANGER networks

Li Informational [Page 62] RFC 6115 RRG Recommendation February 2011

 and IRON routers that receive and forward the bubbles securely
 install PI prefixes in their FIBs, but do not inject them into the
 RIB.  IRON routers therefore keep track of only their customer base
 via the FIB entries and keep track of only the Internet-wide VP
 database in the RIB.
 IRON routers propagate more-specific prefixes using secure
 redirection to update router FIBs.  Prefix redirection is driven by
 the data plane and does not affect the control plane.  Redirected
 prefixes are not injected into the RIB, but rather are maintained as
 FIB soft state that is purged after expiration or route failure.
 Neighbor unreachability detection is used to detect failure.
 Secure prefix registrations and redirections are accommodated through
 the mechanisms of SEAL.  Tunnel endpoints using SEAL synchronize
 sequence numbers, and can therefore discard any packets they receive
 that are outside of the current sequence number window.  Hence, off-
 path attacks are defeated.  These synchronized tunnel endpoints can
 therefore exchange prefixes with signed certificates that prove
 prefix ownership in such a way that DoS vectors that attack crypto
 calculation overhead are eliminated due to the prevention of off-path
 attacks.
 CEs can move from old RANGER networks and re-inject their PI prefixes
 into new RANGER networks.  This would be accommodated by IRON-RANGER
 as a site multihoming event while host mobility and true locator-ID
 separation is accommodated via HIP [RFC5201].

17. Recommendation

 As can be seen from the extensive list of proposals above, the group
 explored a number of possible solutions.  Unfortunately, the group
 did not reach rough consensus on a single best approach.
 Accordingly, the recommendation has been left to the co-chairs.  The
 remainder of this section describes the rationale and decision of the
 co-chairs.
 As a reminder, the goal of the research group was to develop a
 recommendation for an approach to a routing and addressing
 architecture for the Internet.  The primary goal of the architecture
 is to provide improved scalability for the routing subsystem.
 Specifically, this implies that we should be able to continue to grow
 the routing subsystem to meet the needs of the Internet without
 requiring drastic and continuous increases in the amount of state or
 processing requirements for routers.

Li Informational [Page 63] RFC 6115 RRG Recommendation February 2011

17.1. Motivation

 There is a general concern that the cost and structure of the routing
 and addressing architecture as we know it today may become
 prohibitively expensive with continued growth, with repercussions to
 the health of the Internet.  As such, there is an urgent need to
 examine and evaluate potential scalability enhancements.
 For the long term future of the Internet, it has become apparent that
 IPv6 is going to play a significant role.  It has taken more than a
 decade, but IPv6 is starting to see some non-trivial amount of
 deployment.  This is in part due to the depletion of IPv4 addresses.
 It therefore seems apparent that the new architecture must be
 applicable to IPv6.  It may or may not be applicable to IPv4, but not
 addressing the IPv6 portion of the network would simply lead to
 recreating the routing scalability problem in the IPv6 domain,
 because the two share a common routing architecture.
 Whatever change we make, we should expect that this is a very long-
 lived change.  The routing architecture of the entire Internet is a
 loosely coordinated, complex, expensive subsystem, and permanent,
 pervasive changes to it will require difficult choices during
 deployment and integration.  These cannot be undertaken lightly.
 By extension, if we are going to the trouble, pain, and expense of
 making major architectural changes, it follows that we want to make
 the best changes possible.  We should regard any such changes as
 permanent and we should therefore aim for long term solutions that
 place the network in the best possible position for ongoing growth.
 These changes should be cleanly integrated, first-class citizens
 within the architecture.  That is to say that any new elements that
 are integrated into the architecture should be fundamental
 primitives, on par with the other existing legacy primitives in the
 architecture, that interact naturally and logically when in
 combination with other elements of the architecture.
 Over the history of the Internet, we have been very good about
 creating temporary, ad-hoc changes, both to the routing architecture
 and other aspects of the network layer.  However, many of these band-
 aid solutions have come with a significant overhead in terms of long-
 term maintenance and architectural complexity.  This is to be avoided
 and short-term improvements should eventually be replaced by long-
 term, permanent solutions.
 In the particular instance of the routing and addressing architecture
 today, we feel that the situation requires that we pursue both short-
 term improvements and long-term solutions.  These are not
 incompatible because we truly intend for the short-term improvements

Li Informational [Page 64] RFC 6115 RRG Recommendation February 2011

 to be completely localized and temporary.  The short-term
 improvements are necessary to give us the time necessary to develop,
 test, and deploy the long-term solution.  As the long-term solution
 is rolled out and gains traction, the short-term improvements should
 be of less benefit and can subsequently be withdrawn.

17.2. Recommendation to the IETF

 The group explored a number of proposed solutions but did not reach
 consensus on a single best approach.  Therefore, in fulfillment of
 the routing research group's charter, the co-chairs recommend that
 the IETF pursue work in the following areas:
    Evolution [Evolution]
    Identifier-Locator Network Protocol (ILNP) [ILNP_Site]
    Renumbering [RFC5887]

17.3. Rationale

 We selected Evolution because it is a short-term improvement.  It can
 be applied on a per-domain basis, under local administration and has
 immediate effect.  While there is some complexity involved, we feel
 that this option is constructive for service providers who find the
 additional complexity to be less painful than upgrading hardware.
 This improvement can be deployed by domains that feel it necessary,
 for as long as they feel it is necessary.  If this deployment lasts
 longer than expected, then the implications of that decision are
 wholly local to the domain.
 We recommended ILNP because we find it to be a clean solution for the
 architecture.  It separates location from identity in a clear,
 straightforward way that is consistent with the remainder of the
 Internet architecture and makes both first-class citizens.  Unlike
 the many map-and-encap proposals, there are no complications due to
 tunneling, indirection, or semantics that shift over the lifetime of
 a packet's delivery.
 We recommend further work on automating renumbering because even with
 ILNP, the ability of a domain to change its locators at minimal cost
 is fundamentally necessary.  No routing architecture will be able to
 scale without some form of abstraction, and domains that change their
 point of attachment must fundamentally be prepared to change their
 locators in line with this abstraction.  We recognize that [RFC5887]
 is not a solution so much as a problem statement, and we are simply
 recommending that the IETF create effective and convenient mechanisms
 for site renumbering.

Li Informational [Page 65] RFC 6115 RRG Recommendation February 2011

18. Acknowledgments

 This document presents a small portion of the overall work product of
 the Routing Research Group, who have developed all of these
 architectural approaches and many specific proposals within this
 solution space.

19. Security Considerations

 Space precludes a full treatment of security considerations for all
 proposals summarized herein.  [RFC3552] However, it was a requirement
 of the research group to provide security that is at least as strong
 as the existing Internet routing and addressing architecture.  Each
 technical proposal has slightly different security considerations,
 the details of which are in many of the references cited.

20. Informative References

 [CRM]      Flinck, H., "Compact routing in locator identifier mapping
            system", <http://www.tschofenig.priv.at/rrg/
            CR_mapping_system_0.1.pdf>.
 [DNSnBIND]
            Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th
            Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN
            0-596-10057-4.
 [EEMDP_Considerations]
            Sriram, K., Kim, Y., and D. Montgomery, "Enhanced
            Efficiency of Mapping Distribution Protocols in Scalable
            Routing and Addressing Architectures", Proceedings of the
            ICCCN, Zurich, Switzerland, August 2010,
            <http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>.
 [EEMDP_Presentation]
            Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery,
            "Enhanced Efficiency of Mapping Distribution Protocols in
            Scalable Routing and Addressing Architectures", Presented
            at the LISP WG meeting, IETF 78, July 2010. Originally
            presented at the RRG meeting at IETF 72,
            <http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.
 [Evolution]
            Zhang, B. and L. Zhang, "Evolution Towards Global Routing
            Scalability", Work in Progress, October 2009.

Li Informational [Page 66] RFC 6115 RRG Recommendation February 2011

 [Evolution_Grow_Presentation]
            Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
            L. Zhang, "Virtual Aggregation (VA)", November 2009,
            <http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.
 [FIBAggregatability]
            Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An
            Evaluation Study of Router FIB Aggregatability",
            November 2009,
            <http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.
 [GLI]      Menth, M., Hartmann, M., and D. Klein, "Global Locator,
            Local Locator, and Identifier Split (GLI-Split)",
            April 2010,
            <http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.
 [ILNP_DNS]
            Atkinson, R. and S. Rose, "DNS Resource Records for ILNP",
            Work in Progress, February 2011.
 [ILNP_ICMP]
            Atkinson, R., "ICMP Locator Update message", Work
            in Progress, February 2011.
 [ILNP_Intro]
            Atkinson, R., "ILNP Concept of Operations", Work
            in Progress, February 2011.
 [ILNP_Nonce]
            Atkinson, R., "ILNP Nonce Destination Option", Work
            in Progress, February 2011.
 [ILNP_Site]
            Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and
            M. Lad, "ILNP - Identifier-Locator Network Protocol",
            updated 06 January 2011,
            <http://ilnp.cs.st-andrews.ac.uk>.
 [IRON]     Templin, F., "The Internet Routing Overlay Network
            (IRON)", Work in Progress, January 2011.
 [Ivip_Constraints]
            Whittle, R., "List of constraints on a successful scalable
            routing solution which result from the need for widespread
            voluntary adoption", April 2009,
            <http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.

Li Informational [Page 67] RFC 6115 RRG Recommendation February 2011

 [Ivip_DRTM]
            Whittle, R., "DRTM - Distributed Real Time Mapping for
            Ivip and LISP", Work in Progress, March 2010.
 [Ivip_EAF]
            Whittle, R., "Ivip4 ETR Address Forwarding", Work
            in Progress, January 2010.
 [Ivip_Glossary]
            Whittle, R., "Glossary of some Ivip and scalable routing
            terms", Work in Progress, March 2010.
 [Ivip_Mobility]
            Whittle, R., "TTR Mobility Extensions for Core-Edge
            Separation Solutions to the Internet's Routing Scaling
            Problem", August 2008,
            <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
 [Ivip_PLF]
            Whittle, R., "Prefix Label Forwarding (PLF) - Modified
            Header Forwarding for IPv6",
            <http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.
 [Ivip_PMTUD]
            Whittle, R., "IPTM - Ivip's approach to solving the
            problems with encapsulation overhead, MTU, fragmentation
            and Path MTU Discovery", January 2010,
            <http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.
 [JSAC_Arch]
            Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the
            Internet Architecture Through Naming", IEEE Journal on
            Selected Areas in Communication (JSAC) 28(8),
            October 2010.
 [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
            Work in Progress, February 2010.
 [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
            "Locator/ID Separation Protocol (LISP)", Work in Progress,
            October 2010.
 [LISP+ALT]
            Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
            Alternative Topology (LISP+ALT)", Work in Progress,
            October 2010.

Li Informational [Page 68] RFC 6115 RRG Recommendation February 2011

 [LISP-Interworking]
            Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
            "Interworking LISP with IPv4 and IPv6", Work in Progress,
            August 2010.
 [LISP-MN]  Meyer, D., Lewis, D., and D. Farinacci, "LISP Mobile
            Node", Work in Progress, October 2010.
 [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server", Work
            in Progress, October 2010.
 [LISP-TREE]
            Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
            and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
            the LISP Mapping System", IEEE Journal on Selected Areas
            in Communications, Volume 28, Issue 8, October 2010, <http
            ://ieeexplore.ieee.org/stamp/
            stamp.jsp?tp=&arnumber=5586446>.
 [LMS]      Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A
            Layered Mapping System For Scalable Routing", <http://
            docs.google.com/
            fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN
            mFkYzBhNWJhMWEy&hl=en>.
 [LMS_Summary]
            Sun, C., "A Layered Mapping System (Summary)", <http://
            docs.google.com/
            Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.
 [LOC_ID_Implications]
            Meyer, D. and D. Lewis, "Architectural Implications of
            Locator/ID Separation", Work in Progress, January 2009.
 [MILCOM1]  Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi-
            homing and Traffic Engineering for IP", IEEE Military
            Communications Conference (MILCOM) 28, Boston, MA, USA,
            October 2009.
 [MILCOM2]  Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised
            Resilience, Multi-homing and Mobility Capability for IP",
            IEEE Military Communications Conference (MILCOM) 27, San
            Diego, CA, USA, November 2008.
 [MPTCP_Arch]
            Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford,
            "Architectural Guidelines for Multipath TCP Development",
            Work in Progress, February 2010.

Li Informational [Page 69] RFC 6115 RRG Recommendation February 2011

 [MobiArch1]
            Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an
            Integrated Service through the Use of Naming", ACM
            International Workshop on Mobility in the Evolving
            Internet (MobiArch) 2, Kyoto, Japan, August 2007.
 [MobiArch2]
            Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through
            Naming: Impact on DNS", ACM International Workshop on
            Mobility in the Evolving Internet (MobiArch) 3, Seattle,
            USA, August 2008.
 [Name_Based_Sockets]
            Vogt, C., "Simplifying Internet Applications Development
            With A Name-Based Sockets Interface", December 2009, <http
            ://christianvogt.mailup.net/pub/
            vogt-2009-name-based-sockets.pdf>.
 [RANGER_Scen]
            Russert, S., Fleischman, E., and F. Templin, "RANGER
            Scenarios", Work in Progress, July 2010.
 [RANGI]    Xu, X., "Routing Architecture for the Next Generation
            Internet (RANGI)", Work in Progress, August 2010.
 [RANGI-PROXY]
            Xu, X., "Transition Mechanisms for Routing Architecture
            for the Next Generation Internet (RANGI)", Work
            in Progress, July 2009.
 [RANGI-SLIDES]
            Xu, X., "Routing Architecture for the Next-Generation
            Internet (RANGI)", <http://www.ietf.org/proceedings/76/
            slides/RRG-1/RRG-1.htm>.
 [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
            RFC 792, September 1981.
 [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
            Update", RFC 3007, November 2000.
 [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
            Text on Security Considerations", BCP 72, RFC 3552,
            July 2003.
 [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "DNS Security Introduction and Requirements",
            RFC 4033, March 2005.

Li Informational [Page 70] RFC 6115 RRG Recommendation February 2011

 [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Resource Records for the DNS Security Extensions",
            RFC 4034, March 2005.
 [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Protocol Modifications for the DNS Security
            Extensions", RFC 4035, March 2005.
 [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
            (HIP) Architecture", RFC 4423, May 2006.
 [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
            Message Protocol (ICMPv6) for the Internet Protocol
            Version 6 (IPv6) Specification", RFC 4443, March 2006.
 [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
            "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
            September 2007.
 [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
            RFC 4960, September 2007.
 [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
            "Host Identity Protocol", RFC 5201, April 2008.
 [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
            Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
            March 2008.
 [RFC5534]  Arkko, J. and I. van Beijnum, "Failure Detection and
            Locator Pair Exploration Protocol for IPv6 Multihoming",
            RFC 5534, June 2009.
 [RFC5720]  Templin, F., "Routing and Addressing in Networks with
            Global Enterprise Recursion (RANGER)", RFC 5720,
            February 2010.
 [RFC5887]  Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
            Still Needs Work", RFC 5887, May 2010.
 [RFC5902]  Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
            IPv6 Network Address Translation", RFC 5902, July 2010.
 [RRG_Design_Goals]
            Li, T., "Design Goals for Scalable Internet Routing", Work
            in Progress, January 2011.

Li Informational [Page 71] RFC 6115 RRG Recommendation February 2011

 [Referral_Obj]
            Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and
            K. Moore, "A Generic Referral Object for Internet
            Entities", Work in Progress, October 2009.
 [SEAL]     Templin, F., "The Subnetwork Encapsulation and Adaptation
            Layer (SEAL)", Work in Progress, January 2011.
 [Scalability_PS]
            Narten, T., "On the Scalability of Internet Routing", Work
            in Progress, February 2010.
 [TIDR]     Adan, J., "Tunneled Inter-domain Routing (TIDR)", Work
            in Progress, December 2006.
 [TIDR_AS_forwarding]
            Adan, J., "yetAnotherProposal: AS-number forwarding",
            March 2008,
            <http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.
 [TIDR_and_LISP]
            Adan, J., "LISP etc architecture", December 2007,
            <http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.
 [TIDR_identifiers]
            Adan, J., "TIDR using the IDENTIFIERS attribute",
            April 2007, <http://www.ietf.org/mail-archive/web/ram/
            current/msg01308.html>.
 [VET]      Templin, F., "Virtual Enterprise Traversal (VET)", Work
            in Progress, January 2011.
 [Valiant]  Zhang-Shen, R. and N. McKeown, "Designing a Predictable
            Internet Backbone Network", November 2004, <http://
            conferences.sigcomm.org/hotnets/2004/
            HotNets-III%20Proceedings/zhang-shen.pdf>.
 [hIPv4]    Frejborg, P., "Hierarchical IPv4 Framework", Work
            in Progress, October 2010.

Li Informational [Page 72] RFC 6115 RRG Recommendation February 2011

Author's Address

 Tony Li (editor)
 Cisco Systems
 170 West Tasman Dr.
 San Jose, CA  95134
 USA
 Phone: +1 408 853 9317
 EMail: tony.li@tony.li

Li Informational [Page 73]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6115.txt · Last modified: 2011/02/22 18:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki