Re: [rrg] Summary of RANGI//re: belated msg: further description of the recommendation process

Tony Li <> Tue, 15 December 2009 09:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D75B3A69B6 for <>; Tue, 15 Dec 2009 01:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rrm+6eS6r4JM for <>; Tue, 15 Dec 2009 01:50:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F01FC3A67B3 for <>; Tue, 15 Dec 2009 01:50:01 -0800 (PST)
Received: from ([]) by with comcast id HMpp1d0031afHeLA9MppVZ; Tue, 15 Dec 2009 09:49:49 +0000
Received: from [] ([]) by with comcast id HMpo1d0023L8a8Q8dMppff; Tue, 15 Dec 2009 09:49:49 +0000
Message-ID: <>
Date: Tue, 15 Dec 2009 01:49:46 -0800
From: Tony Li <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Xu Xiaohu <>
References: <003101ca7d35$79779820$>
In-Reply-To: <003101ca7d35$79779820$>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
Cc:, 'Lixia Zhang' <lixia@CS.UCLA.EDU>
Subject: Re: [rrg] Summary of RANGI//re: belated msg: further description of the recommendation process
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Dec 2009 09:50:05 -0000



Xu Xiaohu wrote:
>> -----邮件原件-----
>> 发件人: [] 代表 Lixia
> Zhang
>> 发送时间: 2009年12月11日 13:54
>> 收件人:
>> 主题: [rrg] belated msg: further description of the recommendation process
>> sorry folks, day job crisis delayed this msg for a few days.
>> Tony and I have had some discussions on how to collect the
>> recommendation document.  One comment we have heard repeated from a
>> number of people is that our recommendation should document the pros
>> and cons of different approaches, which can be very valuable, even
>> independent from whichever specific recommendations we may end up with.
>> 1/ To steer efforts toward that goal, we would like each proposal to
>> make a concise summary, preferably no longer than ~1000 words (it may
>> contain pointer to more detailed document), that describes the key
>> ideas of the proposal of exactly how it addresses routing scalability
>> issue, where is its cost, and where is its gain.
> Hi Lixia and Tony,
> Summary of Routing Architecture for the Next Generation Internet (RANGI) is
> as follows:
> 1. Key idea:
> Similar to HIP [RFC4423], RANGI introduces a host identifier layer between
> the network layer and the transport layer, and the transport-layer
> associations (i.e., TCP connections) are no longer bound to IP addresses,
> but to host identifiers. The major difference from 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-embeded 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]), 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).
> 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. 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.
> 4. Documents:
> RANGI =>
> RANGI Proxy =>
> RANGI Presentation on IETF76 =>
> _______________________________________________
> rrg mailing list