Recommendation for a Routing Architecture
draft-irtf-rrg-recommendation-06

Abstract

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multi-homing, and inter-domain traffic engineering. This document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 8, 2010.

Copyright Notice

Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
    1.1.  Structure of This Document
    1.2.  Abbreviations
2.  Locator Identifier Separation Protocol (LISP)
    2.1.  Summary
        2.1.1.  Key Idea
        2.1.2.  Gains
        2.1.3.  Costs
    2.2.  Critique
    2.3.  Rebuttal
    2.4.  Counterpoint
3.  Routing Architecture for the Next Generation Internet (RANGI)
    3.1.  Summary
        3.1.1.  Key Idea
        3.1.2.  Gains
        3.1.3.  Costs
    3.2.  Critique
    3.3.  Rebuttal
    3.4.  Counterpoint
4.  Internet Vastly Improved Plumbing (Ivip)
    4.1.  Summary
        4.1.1.  Key Ideas
        4.1.2.  Extensions
            4.1.2.1.  TTR Mobility
            4.1.2.2.  Modified Header Forwarding
        4.1.3.  Gains
        4.1.4.  Costs
    4.2.  Critique
    4.3.  Rebuttal
    4.4.  Counterpoint
5.  hIPv4
    5.1.  Summary
        5.1.1.  Key Idea
        5.1.2.  Gains
        5.1.3.  Costs And Issues
    5.2.  Critique
    5.3.  Rebuttal
    5.4.  Counterpoint
6.  Name overlay (NOL) service for scalable Internet routing
    6.1.  Summary
        6.1.1.  Key Idea
        6.1.2.  Gains
        6.1.3.  Costs
    6.2.  Critique
    6.3.  Rebuttal
    6.4.  Counterpoint
7.  Compact routing in locator identifier mapping system
    7.1.  Summary
        7.1.1.  Key Idea
        7.1.2.  Gains
        7.1.3.  Costs
    7.2.  Critique
    7.3.  Rebuttal
    7.4.  Counterpoint
8.  Layered mapping system (LMS)
    8.1.  Summary
        8.1.1.  Key Ideas
        8.1.2.  Gains
        8.1.3.  Costs
    8.2.  Critique
    8.3.  Rebuttal
    8.4.  Counterpoint
9.  2-phased mapping
    9.1.  Summary
        9.1.1.  Considerations
        9.1.2.  My contribution: a 2-phased mapping
        9.1.3.  Gains
        9.1.4.  Summary
    9.2.  Critique
    9.3.  Rebuttal
    9.4.  Counterpoint
10.  Global Locator, Local Locator, and Identifier Split (GLI-Split)
    10.1.  Summary
        10.1.1.  Key Idea
        10.1.2.  Gains
        10.1.3.  Costs
    10.2.  Critique
    10.3.  Rebuttal
    10.4.  Counterpoint
11.  Tunneled Inter-domain Routing (TIDR)
    11.1.  Summary
        11.1.1.  Key Idea
        11.1.2.  Gains
        11.1.3.  Costs
    11.2.  Critique
    11.3.  Rebuttal
    11.4.  Counterpoint
12.  Identifier-Locator Network Protocol (ILNP)
    12.1.  Summary
        12.1.1.  Key Ideas
        12.1.2.  Benefits
        12.1.3.  Costs
    12.2.  Critique
    12.3.  Rebuttal
    12.4.  Counterpoint
13.  Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes
    13.1.  Summary
        13.1.1.  Introduction
        13.1.2.  Management of Mapping Distribution of Subprefixes Spread Across Multiple ETRs
        13.1.3.  Management of Mapping Distribution for Scenarios with Hierarchy of ETRs and Multi-Homing
    13.2.  Critique
    13.3.  Rebuttal
    13.4.  Counterpoint
14.  Evolution
    14.1.  Summary
        14.1.1.  Need for Evolution
        14.1.2.  Relation to Other RRG Proposals
        14.1.3.  Aggregation with Increasing Scopes
    14.2.  Critique
    14.3.  Rebuttal
    14.4.  Counterpoint
15.  Name-Based Sockets
    15.1.  Summary
    15.2.  Critique
        15.2.1.  Deployment
        15.2.2.  Edge-networks
    15.3.  Rebuttal
    15.4.  Counterpoint
16.  Routing and Addressing in Networks with Global Enterprise Recursion (IRON-RANGER)
    16.1.  Summary
        16.1.1.  Gains
        16.1.2.  Costs
    16.2.  Critique
    16.3.  Rebuttal
    16.4.  Counterpoint
17.  Recommendation
18.  Acknowledgments
19.  IANA Considerations
20.  Security Considerations
21.  References
    21.1.  Normative References
    21.2.  Informative References
    21.3.  LISP References
    21.4.  RANGI References
    21.5.  Ivip References
    21.6.  hIPv4 References
    21.7.  Layered Mapping System References
    21.8.  GLI References
    21.9.  TIDR References
    21.10.  ILNP References
    21.11.  EEMDP References
    21.12.  Evolution References
    21.13.  Name Based Sockets References
    21.14.  RANGER References
§  Author's Address

1.  Introduction

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multi-homing, and inter-domain traffic engineering. The problem being addressed has been documented in [I‑D.narten‑radir‑problem‑statement] (Narten, T., “On the Scalability of Internet Routing,” February 2010.), and the design goals that we have discussed can be found in [I‑D.irtf‑rrg‑design‑goals] (Li, T., “Design Goals for Scalable Internet Routing,” July 2007.).

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 RRG from the presence of any proposals in this document, or the amount of analysis devoted to specific proposals.

1.1.  Structure of This Document

This document describes a number of the different possible approaches that could be taken in a new routing architecture, as well as a summary of the current thinking of the overall group regarding each approach.

1.2.  Abbreviations

This section lists some of the most common abbreviations used in the remainder of this document.

DFZ

Default-Free Zone

EID

Endpoint IDentifer: The precise definition varies depending on the proposal.

ETR

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

FIB

Forwarding Information Base: The forwarding table, used in the data plane of routers to select the next hop for each packet.

ITR

Ingress Tunnel Router: In a system which tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual original source which 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 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 with 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.

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 Identifier 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 routeable addresses (locators) while providing stable and portable numbering of end systems (identifiers).

2.1.2.  Gains

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

2.1.3.  Costs

• mapping system infrastructure (map servers, map resolvers, ALT routers) (new potential business opportunity)
• Interworking infrastructure (proxy ITRs) (new potential business opportunity)
• overhead for determining/maintaining locator/path liveness (common issue for all id/loc separation proposals)

2.2.  Critique

LISP-ALT distributes mapping to ITRs via (optional, local, potentially-caching) Map Resolvers and with globally distributed query servers: ETRs and optional Map Servers.

A fundamental problem with any global query server network is that the frequently long paths and greater risk of packet loss 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 resent packet and will tunnel that packet correctly. These "initial packet delays" reduce performance and so create a major barrier to voluntary adoption on 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 them determining 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 have no address of a device in that network. So ETRs must report network un-reachability to ITRs.

LISP involves complex communication between ITRs and ETRs, with UDP and 64-bit LISP headers in all traffic packets.

The advantage of LISP+ALT is that its ability to handle billions of EIDs is not constrained by the need to transmit or store the mapping to any one location. Such numbers, beyond a few tens of millions of EIDs, will only result if the system is used for Mobility. Yet the concerns just mentioned about ALT's structure arise from the millions of ETRs which would be needed just for non-mobile networks.

In LISP's mobility approach each MN needs an RLOC address to be its own ETR, meaning the MN cannot be behind NAT. Mapping changes must be sent instantly to all relevant ITRs every time the MN gets a new address - which LISP cannot achieve.

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 scheme itself. End-user networks must rely on the necessarily limited capabilities which 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

No rebuttal was submitted for this proposal.

2.4.  Counterpoint

No counterpoint was submitted for this proposal.

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

3.1.  Summary

3.1.1.  Key Idea

Similar to HIP [RFC4423] (Moskowitz, R. and P. Nikander, “Host Identity Protocol (HIP) Architecture,” May 2006.), 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 the HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier which has organizational structure. As a result, the corresponding ID->locator mapping system for such identifiers has reasonable business model and clear trust boundaries. In addition, RANGI uses IPv4-embedded IPv6 addresses as locators. The 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 is a local IPv4 address (either public or private). This special locator could be used to realize 6over4 automatic tunneling (borrowing ideas from ISATAP [RFC5214] (Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” March 2008.)), 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 goals set by RRG as follows:

1. Routing Scalability: Scalability is achieved by decoupling identifiers from locators.
2. Traffic Engineering: Hosts located in a multi-homed site can suggest the upstream ISP for outbound and inbound traffics, while the first-hop LDBR (i. e., site border router) has the final decision right on the upstream ISP selection.
3. Mobility and Multi-homing: Sessions will not be interrupted due to locator change in cases of mobility or multi-homing.
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 LD will not be disclosed outside, the routing stability could be improved greatly.
7. Routing Security: RANGI reuses the current routing system and does not introduce any new security risk into the routing system.
8. Incremental Deployability: RANGI allows easy transition from IPv4 network to IPv6 network. In addition, RANGI proxy allows RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice versa.

3.1.3.  Costs

1. Host change is required
2. 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. Proxy needs to be deployed for communication between RANGI-aware hosts and legacy hosts.

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 draft suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup which 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 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 multihome load balance). 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 neighbor aliveness and delayed first packet problems, and avoids statefull middleboxes. Unfortunately, the early-adopter incentive for host upgrade may not be adequate (HIP's lack of uptake being an example).

RANGI does not have an explicit solution for the mobility race condition (there is no mention of a home-agent like device). However, host-to-host notification combined with fallback on the ID->locators lookup (assuming adequate dynamic update of the lookup system) may be good enough for the vast majority of mobility situations.

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

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

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 not necessary 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), Distribute 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 its presidial mappings.

For host mobility, if communicating entities are RANGI nodes, the mobile node will notice the correspondence 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 timely by using the Secure DNS Dynamic Update mechanism defined in [RFC3007] (Wellington, B., “Secure Domain Name System (DNS) Dynamic Update,” November 2000.). In case of simultaneous mobility, at least one of them has to resort to the ID->Locator mapping system for resolving the correspondence node's new locator so as to continue their communication. If the correspondence node is a legacy host, Transit Proxies, which play the 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 the latter version of RANGI-PROXY.

The intention that RANGI uses IPv4-embedded IPv6 addresses as locators is to reduce the total deployment cost of this new Internet architecture and to avoid renumbering the site internal routers when such a site changes ISPs.

3.4.  Counterpoint

No counterpoint was submitted for this proposal.

4.  Internet Vastly Improved Plumbing (Ivip)

4.1.  Summary

4.1.1.  Key Ideas

Ivip (pr. 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 and mobile devices.

Ivip meets all the constraints imposed by the need for widespread voluntary adoption [Ivip Constraints] (Whittle, R., “List of constraints on a successful scalable routing solution which result from the need for widespread voluntary adoption,” .).

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 which have ITRs. Each mapping change is sent to all QSDs within a few seconds.

ITRs gain mapping information from these local QSDs within a few tens of milliseconds. QSDs notify ITRs of changed mapping 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 TE. So the mechanisms which 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.

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 which lack ITRs. So multihoming, portability and TE benefits apply to all traffic.

ITRs request mapping 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.

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 - which enables existing ISP 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 TTR approach to mobility [Ivip Mobility] (Whittle, R., “TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem,” .) 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 app changes), and of course other MNs. Mapping changes are only needed when the MN uses a new TTR, which would typically be if the MN moved more than 1000km. Mapping changes are not required when the MN changes its physical address(es).

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

Amenable to widespread voluntary adoption due to no need for host changes, complete support for packets sent from non-upgraded networks and no significant degradation in performance.

Modular separation of the control of ITR tunneling behavior from the ITRs and the core-edge separation scheme itself: end-user networks control mapping in any way they like, in real-time.

A small fee per mapping change deters frivolous changes and helps pay for pushing the mapping data to all QSDs. End-user networks who 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.

End-user networks will typically pay the cost of OITRD forwarding to their networks. This provides a business model for OITRD deployment and avoids unfair distribution of costs.

Existing source address filtering arrangements at BRs of ISPs and end-user networks are prohibitively expensive to implement directly in ETRs, but with the outer header's source address being the same as the sending host's address, Ivip ETRs inexpensively enforce BR filtering on decapsulated packets.

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 ~10M, so most of the 10B mappings would be for mobile devices. However, TTR mobility does not involve frequent mapping changes since most MNs only rarely move more than 1000km.

4.2.  Critique

Looking at 1000 feet level, Ivip shares the basic design approaches with LISP and a number of other Map-n-Encap designs based on the core-edge separation. However the details differ substantially. Ivip design takes 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 which 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.

"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 LISP team has studied extensively, which include

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

However to be considered as a viable solution to Internet routing scalability problem, Ivip faces two fundamental questions. First, it is an entirely open question whether a global-scale system is able to achieve real time synchronized operations as assumed by Ivip. 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 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 those which 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 which 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 (draft-whittle-ivip-drtm-00).

DRTM makes it easier for ISPs to install their own ITRs. It also facilitates MAB (Mapped Address Block) operating companies - which need not be ISPs - leasing 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 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 sent from customer networks which 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 which stores the full mapping information for all Mapped Address Blocks (MABs). ISPs which want ITRs will install two or more Map Resolver (MR) servers. These are caching query servers which query multiple typically nearby query servers which are full-database for the subset of MABs they serve. These "nearby" query servers will be at DITR (Default ITR in the DFZ) 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.

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

4.4.  Counterpoint

No counterpoint was submitted for this proposal.

5.  hIPv4

5.1.  Summary

5.1.1.  Key Idea

The hierarchical IPv4 framework is adding scalability in the routing architecture by introducing 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, also 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 AS) 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. Multi-homing can be achieved in two ways, either the enterprise request an ALOC prefix from the RIR (this is not recommended) or the enterprise receive the ALOC prefixes from their upstream ISPs ELOC prefixes are PI addresses and remains intact when a upstream ISP is changed, only the ALOC prefix is replaced. When the RIB of DFZ is compressed (containing only ALOC prefixes) no longer an ingress router knows 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 (RFC 4960) and Multipath TCP (MPTCP), at the endpoints. The multipath transport protocols also provides 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 is 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 multi-homing solutions there will be several ALOC values for an endpoint).

5.1.2.  Gains

1. Improved routing scalability: Adding hierarchy in the address space enables a new 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 provider 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 schemes has been added to the framework; more research work is required around VLB switching.
3. Scalable support for multi-homing: Only attachment points (ALOC prefix) of a multi-homed site are advertised 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 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.
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 layer in the TCP/IP model.
6. Routing quality: The hIPv4 framework introduce 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 can not be high-jacked (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 multi-homing 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. 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.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 - so providing 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 favourable to widespread adoption than those of 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 which will not work with hIPv4: "There are several applications that are inserting IPv4 address information in the payload of a packet. Some applications use the IPv4 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."

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.

5.4.  Counterpoint

No counterpoint 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) on the existing TCP/IP stack.

Its functions include:

1. host names configuration, registration and authentication;
2. Initiate and manage transport connection channels (i.e., TCP/IP connections) by name;
3. keep application data transport continuity for mobility.

At the edge network, we introduce a new type of gateway NTR (Name Transfer Relay), which block the PI addresses of edge networks into upstream transit networks. NTRs performs address and/or port translation between blocked PI addresses and globally routable addresses, which seem like today's widely used NAT/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 traverse the NTR by name and initiate connections to the hosts behind it.

Different from proposed host-based ID/Locator split solutions, such as HIP, Shim6, and name-oriented stack, NOL doesn't need to change the existing TCP/IP stack, sockets and their packet formats. NOL can co-exist with the legacy infrastructure, the core-edges separation solutions (e.g., APT, LISP, Six/one, Ivip, etc.)

6.1.2.  Gains

1. Reduce routing table size: Prevent edge network PI address into transit network by deploying gateway NTR
2. Traffic Engineering: For legacy and NOL application initiating session, the incoming traffic can be directed to a specific NTR by DNS answer for names. In addition, for NOL application, its initial session can be redirected from one NTR to other appropriate NTRs. These mechanisms provide some support for traffic engineering.
3. Multi-homing: When a PI address network connects to Internet by multi-homing with several providers, it can deploy NTRs to block the PI addresses into provide networks.
4. And the 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 want to access the hosts behind the NTR can be delegated to a specific PA address in the NTR address pool.
5. Mobility: NOL layer manage the traditional TCP/IP transport connections, and keeps application data transport continue by setting breakpoints and sequence numbers in data stream.
6. No need to change TCP/IP stack, sockets and 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 multi-path indirect routing based on distributed NTRs. This will give benefits to the performance-aware applications, such as, MSN, Video streaming, etc.

6.1.3.  Costs

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

6.2.  Critique

1. Applications on hosts need to be rebuilt based on name overlay library to be NOL-enabled. The legacy software that are not maintained any more will not contribute benefits for routing scalability in the core-edge elimination situation. In the core-edge separation scheme, a new gateway NTR (Name Transfer Relay) is deployed to prevent edge specific PI prefixes into transit core. It doesn't impede the legacy ends behind the NTR to access the outside Internet, but the legacy ends cannot or is difficult to access the ends behind a NTR without the help of NOL.
2. In the scenario of core-edge elimination, the end site will assigned to multiple PA address space, which lead to renumbering troubles on switching to other upstream providers. Upgrading ends to support NOL doesn't give any benefits to edge networks. It has little incentives to use NOL in the core-edge elimination, and the same to other host-based ID/locator split proposals. I believe that the edge networks prefer PI address space to PA address space whether they are IPv4 or IPv6 networks.
3. In the scenario of core-edge separation, 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 is 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 are on a voluntary basis and have few economic incentives.
4. The statefull or stateless translating 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 appropriated to deploy NTRs at the high-level transit networks where aggregated traffic maybe cause the congestion at the NTRs.
5. In the scenario of core-edge separation, the requirement of multi-homing and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For the reliability, all of the association between multiple NTRs and the end site name will be kept in DNS, which may increase the load of DNS.
6. In the support for mobility, it is necessary for the DNS to update the corresponding name-NTR mapping records in time when an end system move from behind one NTR to other NTRs. The NOL-enabled end relies on NOL layer to keep the continuity of applications data transport, while the underlying TCP/UDP transport session would be broken when the IP address changed.

6.3.  Rebuttal

No rebuttal was submitted for this proposal.

6.4.  Counterpoint

No counterpoint was submitted for this proposal.

7.  Compact routing in locator identifier mapping system

7.1.  Summary

7.1.1.  Key Idea

Builds a highly scalable locator identity mapping system using compact routing principles. Provides means for dynamic topology adaption to facilitate efficient aggregation. Map servers are assigned as cluster heads or landmarks based on their capability to aggregate EID announcements.

7.1.2.  Gains

Minimizes the routing table sizes in at the system level (= map servers). Provides clear upper bounds for routing stretch that defines the packet delivery delay of the map request/first packet.

Organizes the mapping system based EID numbering space, minimizes the administrative of overhead of managing EID space. No need for administratively planned hierarchical address allocation as the system will find convergence into a sets of EID allocations.

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

7.1.3.  Costs

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

7.2.  Critique

No critique for this proposal was submitted.

7.3.  Rebuttal

No rebuttal was submitted for this proposal.

7.4.  Counterpoint

No counterpoint was submitted for this proposal.

8.  Layered mapping system (LMS)

8.1.  Summary

8.1.1.  Key Ideas

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

8.1.2.  Gains

1. Scalability
   1. Distributed storage of mapping data avoids central storage of massive data; restrict updates within local areas;
   2. Cache mechanism in ITR reduces request loads on mapping system reasonably.
2. Deployability
   1. No change on edge works; only tunneling in core routers; new devices in core networks;
   2. 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.
   3. Conform to economic model: mapping system 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: Low layer number of the mapping structure and two-stage cache can well achieve low request delay.
4. Data consistency: Two-stage cache enables ITR to update data in the map cache conveniently.
5. Traffic engineering support: Edge networks inform mapping system their mappings with all upstream routers with different priority, thus to control their ingress flows.

8.1.3.  Costs

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

8.2.  Critique

LMS is a mapping mechanism and based on edge-core separations. In fact, any proposal that needs a global mapping system with keys of similar properties of that "edge address" in the edge-core separation 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 different weights, maybe). Once a proposal that needs mapping but doesn't specify the mapping mechanism, is used to solve the scalability problem, LMS can be used to strengthen its function.

The key idea of LMS is similar to LISP+ALT that the mapping system should be hierarchically organized, to gain scalability in the storage and update sense and to achieve quick index for mapping lookup. 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.

Though 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 reason for their existence, how this brand-new system can be constructed is still not clear. Explicit layering is only an ideal state, and it rather analyzes the layering limits and feasibility, than provide a practical way for deployment.

The drawbacks of LMS's feasibility analysis also include 1) based on current PC power and may not represent future circumstances (especially for IPv6); 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 overloaded while others 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 that the mapping updates and propagations between relative mapping servers. On the other hand, mobile hosts moving across ASes and changing their attach points (core addresses) is less frequent than hosts moving within an AS.

I personally advocate that separation needs two planes: edge-core separation, which is to gain routing table scalability; identity-location separation, which is to achieve mobility. GLI does a good clarification 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 incorporate with it if it has globally seen keys and needs to map them to other namespaces.

8.3.  Rebuttal

No rebuttal was submitted for this proposal.

8.4.  Counterpoint

No counterpoint was submitted for this proposal.

9.  2-phased mapping

9.1.  Summary

9.1.1.  Considerations

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

9.1.2.  My contribution: a 2-phased mapping

1. Introduce AS number in the middle of the mapping, phase I mapping is prefix<->AS#, phase II mapping is AS#<->ETRs. We have a M:1:M mapping model now.
2. My assumption is that all ASes know better their local prefixes (in the IGP) than others. and most likely local prefixes can be aggregated when map them to the AS#, which will make the mapping entry reduction possible, ASes also know clearly their ETRs on its 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 register agent to notify the local range of IP address space to the registry. 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. A basic forwarding procedure is that ITR firstly get the destination AS# from phase I mapper (or from cache) when the packet is entering the "core". Then it will check the closest ETR of destination AS#, since phase 2 mapping information has been "pushed" to it through BGP updates. At last the ITR encap the packet and tunnel it to a corresponding ETR.

9.1.3.  Gains

1. Any prefixes reconfiguration (aggregation/ deaggregation) within an AS will not be notified to mapping system.
2. Possible highly efficient aggregation of the local prefixes (in the form of an IP space range).
3. Both phase I and phase II mapping can be stable.
4. A stable mapping system will reduce the update overhead introduced by topology change/routing policy dynamics.ETR.

9.1.4.  Summary

1. The 2-phased mapping scheme introduces AS# 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 2-phased mapping scheme is adaptable to any core/edge split based proposals.

9.2.  Critique

This is a simple idea on how to scale mapping. However personally I feel the design is too incomplete to be considered a serious input to RRG. Take the following 2 issues as example:

First, in this 2-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 of D's ETR). 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.

9.4.  Counterpoint

No counterpoint 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) and using global and local locators (GLs, 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 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 their missing GLI-functionality. This is an important feature for incremental deployability.

10.1.2.  Gains

The benefits of GLI-Split are

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

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

10.1.3.  Costs

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

10.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; the separation between local and global locator, to make the global routing table scalable. The distinction is needed since ISPs and hosts have different requirements, also make the changes inside and outside GLI-domains invisible to their opposites.

A main drawback of GLI-Split is that it puts much burden on hosts. Before routing a packet received from upper layers, network stacks in hosts firstly need 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 map from the identifier to the global locator the local mapping system forwarding 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, which is its big virtue; while the upgrades may be costly to against hosts enthusiasm to change, compared to 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, the kind of tradeoffs between costs and gains exists in most proposals.

I think one improvement of GLI-Split on its support for mobility is to update DNS data as GLI-hosts move across GLI-domains. Through this GLI-corresponding-node can query DNS to get valid global locator of the GLI-mobile-node and need not to query the global mapping system (unless it wants to do multipath routing), giving more incentives for nodes to become GLI-kind. The merit of GLI-Split, simplified-mobility-handover provision, well supports 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 states to maintain, since local and global locators need not to map to each other. Many other rewriting mechanisms instead need to maintain extra states. 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, local and global locator). GLI-Split codes two terms (identifier and local/global locator) into an IPv6 address, each has space size of 2^64 or less, while map-and-encaps proposals assume that identifier and locator each occupies 128 bits space, in the IPv6 scene.

10.3.  Rebuttal

The arguments in the GLI-Split critique are correct. There are only two points that should be clarified here. (1) First, it is not a drawback that hosts perform the mapping lookups. (2) Second, the critique proposed an improvement to the mobility mechanism, which is of 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 not yet cached EIDs arrive, a lookup in the mapping system must be initiated. Until the mapping reply returns, packets must be either dropped, cached, or the packets must be 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. (2) The critique proposes a DNS-based mobility mechanism as an improvement to GLI-Split. However, this improvement is an alternative mobility approach which can be applied to any routing architecture including GLI-Split and raises also some concerns, e.g., the update speed of DNS. Therefore, we prefer to keep this issue out of the discussion.

10.4.  Counterpoint

No counterpoint was submitted for this proposal.

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 of the edge of the Internet transit infrastructure. It enriches 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 Tunnel Information Base (TIB). Afterwards, when routing a packet to the "identifier prefix", the TIB will be searched first to perform tunnel imposition, and secondly the RIB for actual routing. After the edge router performs tunnel imposition, all routers in the middle will route this packet until the router being the tail-end of the tunnel.

11.1.2.  Gains

• Smooth deployment
• Size Reduction of the Global RIB Table
• Deterministic Customer Traffic Engineering for Incoming Traffic
• Numerous Forwarding Decisions for a Particular Address Prefix
• TIDR Stops AS Number Space Depletion
• Improved BGP Convergence
• Protection of the Inter-domain Routing Infrastructure
• Easy Separation of Control Traffic and Transit Traffic
• Different Layer-2 Protocol-IDs for Transit and Non-Transit Traffic
• Multihoming Resilience
• New Address Families and Tunneling Techniques
• TIDR for IPv4 or IPv6, and Migration to IPv6
• Scalability, Stability and Reliability
• Faster Inter-domain Routing

11.1.3.  Costs

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

11.2.  Critique

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

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

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

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

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

The TIDR ID 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 the ID.

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 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 BR at the ISP whose link to the end-user network has just failed, looking 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 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.

11.4.  Counterpoint

No counterpoint was submitted for this proposal.

12.  Identifier-Locator Network Protocol (ILNP)

12.1.  Summary

12.1.1.  Key Ideas

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

12.1.2.  Benefits

• The underlying protocol mechanisms support fully scalable site multi-homing, node multi-homing, site mobility, and node mobility.
• ILNP enables topological aggregation of location information while providing stable and topology-independent identities for nodes.
• 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.
• 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.
• ILNP's mobility approach:
  • eliminates the need for special-purpose routers (e.g. Home Agent and/or Foreign Agent now required by Mobile IP & NEMO).
  • eliminates "triangle routing" in all cases.
  • supports both "make before break" and "break before make" layer-3 handoffs.
• ILNP improves resilience and network availability while reducing the global routing state (as compared with the currently deployed Internet).
• ILNP is Incrementally Deployable:
  • No changes are required to existing IPv6 (or IPv4) routers.
  • Upgraded nodes gain benefits immediately ("day one"); those benefits gain in value as more nodes are upgraded (this follows Metcalfe's Law).
  • Incremental Deployment approach is documented.
• ILNP is Backwards Compatible:
  • ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully backwards compatible with IPv4).
  • Reuses existing known-to-scale DNS mechanisms to provide identifier/locator mapping.
  • Existing DNS Security mechanisms are reused without change.
  • Existing IP Security mechanisms are reused with one minor change (IPsec Security Associations replace current use of IP Addresses with new use of Locator values). NB: IPsec is also backwards compatible.
  • Backwards Compatibility approach is documented.
• No new or additional overhead is required to determine or to maintain locator/path liveness.
• ILNP does not require locator rewriting (NAT); ILNP permits and tolerates NAT should that be desirable in some deployment(s).
• Changes to upstream network providers do not require node or subnetwork renumbering within end-sites.
• Compatible with and can facilitate transition from current single-path TCP to multi-path TCP.
• ILNP can be implemented such that existing applications (e.g. applications using the BSD Sockets API) do NOT need any changes or modifications to use ILNP.

12.1.3.  Costs

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

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 address the host updates when the host learns of provider changes, there are other aspects of provider change that are not addressed. This includes renumbering router, 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 [I‑D.carpenter‑renum‑needs‑work] (Carpenter, B., Atkinson, R., and H. Flinck, “Renumbering still needs work,” January 2010.) 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 record 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 I/L pair. This does appear to require some extensions to the existing mechanism (for both sides adding 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. While 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 encourage 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, compared IETF standard Mobile IP. [MobiArch1] (Atkinson, R., Bhatti, S., and S. Hailes, “Mobility as an Integrated Service through the Use of Naming,” August 2007.) [MobiArch2] (Atkinson, R., Bhatti, S., and S. Hailes, “Mobility Through Naming: Impact on DNS,” August 2008.) ICMP Location updates separately reduce the layer-3 handoff latency.

Also, ILNP enables both host multi-homing and site multi-homing. Current BGP approaches cannot support host multi-homing. Host multi-homing 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 ULA prefixes within the site and has the site border router(s) rewrite the Locator values. Usual NAT issues don't arise because the Locator value is not used above the network-layer. [MILCOM1] (Atkinson, R. and S. Bhatti, “Site-Controlled Secure Multi-homing and Traffic Engineering for IP,” October 2009.) [MILCOM2] (Atkinson, R., Bhatti, S., and S. Hailes, “Harmonised Resilience, Multi-homing and Mobility Capability for IP,” November 2008.)

[I‑D.iab‑ipv6‑nat] (Thaler, D., Zhang, L., and G. Lebovitz, “IAB Thoughts on IPv6 Network Address Translation,” March 2010.) makes clear that many users desire IPv6 NAT, with site interior obfuscation as a major driver. This makes global-scope PI addressing much less desirable for end sites than formerly.

ILNP-capable nodes can talk 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] (Liu, C. and P. Albitz, “DNS & BIND,” 2006.) says many sites have deployed this technology without realizing it (e.g. by enabling both the DHCP server and Active Directory of 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->HA, MN->FA).

ILNP also enables new approaches to security that eliminate dependence upon location-dependent ACLs without packet authentication. Instead, security appliances track flows using Identifier values, and validate the I/L relationship cryptographically [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) or non-cryptographically by reading the [I‑D.rja‑ilnp‑nonce] (Atkinson, R., “Nonce Destination Option,” February 2010.).

The DNS LP record has a more detailed explanation now. LP records enable a site to change its upstream connectivity by changing the L records of a single FQDN covering the whole site, 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 & servers, and are widely used today in the IPv4 Internet for SLB.

Recent ILNP I-Ds discuss referrals in more detail. A node with a binary-referral can find the FQDN using DNS PTR records, which can be authenticated [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.). Approaches such as [I‑D.carpenter‑behave‑referral‑object] (Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, “A Generic Referral Object for Internet Entities,” October 2009.) 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] (Arkko, J. and I. van Beijnum, “Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming,” June 2009.)

12.4.  Counterpoint

No counterpoint was submitted for this proposal.

13.  Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes

13.1.  Summary

13.1.1.  Introduction

We present some architectural principles pertaining to the mapping distribution protocols, especially applicable to 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 end-point 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 a document [EEMDP Considerations] (Sriram, K., Kim, Y., and D. Montgomery, “Architectural Considerations for Mapping Distribution Protocols,” .) that was presented at the RRG meeting in Dublin [EEMDP Presentation] (Sriram, K., Kim, Y., and D. Montgomery, “Architectural Considerations for Mapping Distribution Protocols,” .).

It will be helpful to refer to Figures 1, 2, and 3 in the document noted above 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 Fig. 1 in the document mentioned above). 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 ETR1, while only two of its subprefixes a8/24 and a15/24 are elsewhere at ETR3 and ETR2, respectively (see Fig. 2 in the document). 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 as well. The advantage of the second approach above is that the ILM-R does not overload resources at ITR1 both in terms of processing and memory usage but it needs an enhanced map response in of the form Map:(a/20, ETR1, MS=1), where 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 Multi-Homing

Now we highlight another architectural concept related to mapping management (helpful here to refer to Fig. 3 in the document). Here we consider the possibility that ETRs may be organized in a hierarchical manner. For instance ETR7 is higher in 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 locator role to ETR7 for their EID address space. In 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 multi-homing of subnets are discussed in detail in the detailed document noted earlier. 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 which are hierarchically underneath ETRs.

13.2.  Critique

This scheme [EEMDP Considerations] (Sriram, K., Kim, Y., and D. Montgomery, “Architectural Considerations for Mapping Distribution Protocols,” .) 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] (Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, “An Evaluation Study of Router FIB Aggregatability,” .) There can be cases where deaggregation of EID prefixes occur in such a way that 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 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 solution would be that the response from 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 a regional ILM to store. In Approach 2, 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 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 arise such as an ETR having a bigger EID block with a few holes.

13.3.  Rebuttal

There are two main points in the critique that would be 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 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, /24s over the course of time which 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 prefix. 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) which 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.

Regarding comment (2) above, the suggested modification to Approach 2 would be definitely beneficial. In fact, we feel that it would be fairly straight forward 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 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 map-response that would indicate: (a) With value 00 for notifying that there are no more-specifics; (b) With value 01 for notifying that there are more-specifics and their exact information follows in additional map-responses, and (c) With value 10 for notifying that 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 which will be used to specify the mask-length of the next more-specific in the case of the "10" indication (case (c) above).

13.4.  Counterpoint

No counterpoint was submitted for this proposal.

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 [I‑D.zhang‑evolution] (Zhang, B. and L. Zhang, “Evolution Towards Global Routing Scalability,” October 2009.).

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 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 picture 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-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 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 coordinations among routers 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 PEs, ASBRs, and RRs, and turning on next-hop-self on RRs. For hierarchical networks, the RRs in each 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 out of 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] (Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, “Virtual Aggregation (VA),” .) 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-encap system to provide the operators 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 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 in order for 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 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 churns. For routers with a smaller RIB, the rate of routing churns is naturally reduced. Further reduction can be achieved by not announcing 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.2.  Critique

All the RRG proposals that scale the routing share one fundamental approach, route aggregation, in different forms, e.g., LISP removes "edge prefixes" using encapsulation at ITRs, 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. E.g., it uses FIB aggregation at single router level, virtual aggregation at network level, then between neighbor networks at inter-domain level.

Compared to others, this proposal has the lowest hurdle to deployment, because it does not require all networks move to use a global mapping system or to upgrade all hosts, and it is designed for each individual network to get immediate benefits after its own deployment.

Critiques to 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 are raised about the potential routing loops resulted from forwarding otherwise non-routable packets, and potential impact on 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, hence introduces path 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
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 over-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. Different from a number of other proposals, this solution does not provide mobility support. It remains an open question whether the routing system should handle mobility.

The second type of critique concerns 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 on 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 quicker, a new architecture, if/once deployed, could solve more problems with cleaner solutions.

14.3.  Rebuttal

No rebuttal was submitted for this proposal.

14.4.  Counterpoint

No counterpoint 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 by 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 operating system.

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 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 new incentives for edge network operators to use provider-assigned IP addresses, which are better 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 comprises both, difficulties to multi- home, 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-granular and responsive multi-homing. (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.

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

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

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] (Vogt, C., “Simplifying Internet Applications Development With A Name-Based Sockets Interface,” .).

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.

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 in a slower pace, as the name-based sockets are backwards compatible, this can happen in an 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/multi-homing 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 disjoint, as compatibility is not affected by the use of name-based sockets.

15.2.2.  Edge-networks

The name-based sockets rely on the transition of individual applications, the name-based sockets are backwards compatible, hence it does not require bilateral upgrades. This does allow 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.

15.4.  Counterpoint

No counterpoint 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 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

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

16.1.2.  Costs

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

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 the ID 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 ID contains no specification for a mapping protocol, 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, it 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.

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 RFC 1191 PTB 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.

A fuller version of this critique was posted to the RRG list on 2010-01-26.

16.3.  Rebuttal

The Internet Routing Overlay Network (IRON) [I‑D.templin‑iron] (Templin, F., “The Internet Routing Overlay Network (IRON),” April 2010.) is a scalable Internet routing architecture that builds on the RANGER recursive enterprise network hierarchy [RFC5720] (Templin, F., “Routing and Addressing in Networks with Global Enterprise Recursion (RANGER),” February 2010.). IRON bonds together participating RANGER networks using VET [I‑D.templin‑intarea‑vet] (Templin, F., “Virtual Enterprise Traversal (VET),” March 2010.) and SEAL [I‑D.templin‑intarea‑seal] (Templin, F., “The Subnetwork Encapsulation and Adaptation Layer (SEAL),” March 2010.) 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 NBMA link similar to ISATAP [RFC5214] (Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” March 2008.).

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 sustaining 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 authenticating and PI prefix information. Routers in RANGER networks and IRON routers that receive and forward the bubbles securely install PI prefixes in their FIBs, but do not inject them into the RIB. 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] (Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” April 2008.).

16.4.  Counterpoint

No counterpoint was submitted for this proposal.

17.  Recommendation

18.  Acknowledgments

This document represents 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.  IANA Considerations

This memo includes no requests to IANA.

20.  Security Considerations

All solutions are required to provide security that is at least as strong as the existing Internet routing and addressing architecture.

21.  References

21.1. Normative References

21.2. Informative References

21.3. LISP References

21.4. RANGI References

21.5. Ivip References

21.6. hIPv4 References

21.7. Layered Mapping System References

21.8. GLI References

21.9. TIDR References

21.10. ILNP References

21.11. EEMDP References

21.12. Evolution References

21.13. Name Based Sockets References

21.14. RANGER References

Author's Address