Network Working Group Xiaohu Xu
Internet Draft Huawei
Intended status: Informational Raj Jain
Expires: September 2009 Washington Univ. in St. Louis
March 4, 2009
Routing Architecture for the Next Generation Internet (RANGI)
draft-xu-rangi-00.txt
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 4, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of publication of this document
(http://trustee.ietf.org/license-info). Please review these documents carefully,
as they describe your rights and restrictions with respect to this document.
Abstract
IRTF Routing Research Group (RRG) is exploring a new routing and addressing
architecture to meet the challenges that current Internet is facing, especially in
terms of routing scalability. This internet draft describes a new routing and
Xu and Jain Expires September 4, 2009 [Page 1]
Internet-Draft A Transition Mechanism for RANGI March 2009
addressing architecture, called Routing Architecture for the Next Generation
Internet (RANGI) as a solution to the problems of scalability, mobility,
multihoming, and traffic engineering. RANGI is a hybrid proposal that combines and
enhances the ideas from several proposals particularly those based on
identifier/locator split approach. It introduces a hierarchical and cryptographic
host identifier and adopts a hierarchical routing mechanism to support routing
across multiple independent address spaces. To allow smooth transition from IPv4
to IPv6, it adopts an IPv6 address with an IPv4 embedded in the last four bytes as
locator. This also simplifies renumbering in case of change of service providers.
RANGI allows traffic engineering by allowing border routers to overwrite the
source addresses. It allows policy control on ID to address translation by having
a hierarchical resolution mechanism.
Table of Contents
1. Introduction............................................ 3
2. RANGI: Concepts and Definitions......................... 3
2.1. Administrative Domains and Locator Domains......... 3
2.2. Identifiers and Locators........................... 4
2.3. PI and PA locators................................. 4
2.4. Host Identifiers................................... 4
2.5. Host Locators...................................... 5
2.6. ID Sublayer........................................ 6
2.7. Packet Format...................................... 6
3. RANGI: Assumptions...................................... 8
4. RANGI: Architecture Description......................... 9
4.1. ID/Locator Mapping Resolution...................... 9
4.2. Routing and Forwarding System...................... 9
4.2.1. Host Behavior................................. 9
4.2.2. LDBR Behavior................................ 10
4.2.3. Non-LDBR Router Behavior..................... 10
4.2.4. Forwarding Procedure......................... 10
4.3. Multi-homing and Traffic Engineering.............. 12
4.4. Mobility.......................................... 14
5. Summary................................................ 14
6. Acronyms............................................... 15
7. Security Considerations................................ 15
8. IANA Considerations.................................... 16
9. Informative References ................................ 16
10. Acknowledgments....................................... 18
Xu and Jain Expires September 4, 2009 [Page 2]
Internet-Draft A Transition Mechanism for RANGI March 2009
1. Introduction
The Internet routing table size is growing at a rate which exceeds the speed of
the hardware improvement. This issue has drawn significant attention from both
industry and academia. After much discussion following the IAB Routing and
Addressing workshop [1] in Amsterdam, a common conclusion was reached that the
explosive growth in Internet routing table is caused mainly by the wide adoption
of multi-homing, traffic engineering and provider-independent addressing. The
underlying reason for the routing scalability issue is the overlapping semantics
of IP address which is used both as locator and identifier in current Internet.
This contextual overloading of IP address makes it impossible to renumber the
addresses in a topologically aggregatable way. This is the so-called routing
scalability issue.
At present, the IRTF Routing Research Group (RRG) is chartered to explore a new
routing and addressing architecture to meet those challenges that the current
Internet is facing, especially in scalability, mobility, multi-homing, and inter-
domain traffic engineering.
This internet draft describes a hybrid solution called Routing Architecture for
the Next Generation Internet (RANGI) that significantly enhances id/locator split
approaches. It introduces a hierarchical and cryptographic host identifier and
adopts a hierarchical routing mechanism to support routing across multiple
independent address spaces. RANGI's use of 128-bit host IDs (which also look like
IPv6 addresses) allows current IPv6 applications to run over RANGI. Using IPv4
addresses embedded in the IPv6 locators ease the transition from IPv4 to IPv6.
Traffic engineering and policy control is provided by allowing border routers to
overwrite the addresses in the outgoing packets.
It has recently become clear that hosts IDs have to be separated from their point
of attachment (addresses). In other words, the network consists of two tiers - -
hosts and infrastructure. We have generalized this to a multi-tier virtualizable
architecture where users and data form higher tiers of the architecture over the
host and infrastructure. We are designing a general architecture for this multi-
tiered next generation Internet [20-24]. RANGI as described here is limited to
just the bottom two tiers and applies to the current Internet
2. RANGI: Concepts and Definitions
2.1. Administrative Domains and Locator Domains
In RANGI, we distinguish between the infrastructure and the hosts. Infrastructure
is organized as a set of locator domains while the hosts are organized as a set of
administrative domains. In the current Internet hosts ID is merged with the ID of
the point of attachment to the network. We separate these two. Administrative
domain is the set of all hosts belonging to a single organization. Locator domain
is the set of infrastructure point of attachments.
Xu and Jain Expires September 4, 2009 [Page 3]
Internet-Draft A Transition Mechanism for RANGI March 2009
2.2. Identifiers and Locators
In the ID/Locator split paradigm, it is a general tendency to refer to an
"identifier" as "host id", and "locator" as "host address". However both of these
need to be bound to a context."Identifier" in RANGI refers to the "host ID" in
the context of the administrative domain while "locators" in RANGI are defined in
the context of the locator domain.
2.3. PI and PA locators
Synonymous to provider independent (PI) and Provider aggregatable (PA) addresses,
RANGI too has the concept of PI and PA locators. The 96 bit LD ID of RANGI
locators is used as a prefix in RANGI routing similar to the prefix based routing
of IPv4 and IPv6. Providers may be assigned multiple /96 locator blocks and
reassign them in smaller chunks to subscribers. One of the key features of RANGI
is that it tries to eliminate the concept of PI locator assignments. RANGI tries
to package all the benefits of PI locators using PA locators. Also, with an added
layer of indirection of immutable host IDs, PI locator assignments may be
considerably reduced in RANGI, thus considerably reducing the scalability problems
of the current Internet routing.
2.4. Host Identifiers
Similar to HIP [5], RANGI uses a 128-bit hierarchical Host Identifier (HI),
composed of two parts as shown in Figure 1. The first part is an Administrative
Domain (AD) ID which has embedded organizational affiliation and global uniqueness,
and the second part is a hash value of the AD ID and the public key. The global
uniqueness of the HI should be guaranteed through some registration mechanism.
Since the AD ID is globally unique and controlled by the host ID registration and
administrative authorities from different countries, the second part of the HI,
the hash value just needs to be unique within the AD scope.
+--------------------------+-----------------+
| Administrative Domain ID | Local Host ID |
+--------------------------+-----------------+
| \
| \
| \
| \
| \
+-----------+-------------+-------------+
| Country ID| Authority ID| Region ID | <------Example
+-----------+-------------+-------------+
Figure 1. Host Identifier structure
Xu and Jain Expires September 4, 2009 [Page 4]
Internet-Draft A Transition Mechanism for RANGI March 2009
The purpose of the hierarchical host identifier in RANGI is to ease the management
of the global identifier namespace and hold the economic and trust model in the
id/locator mapping system. In the example shown in Figure 1, the purpose of the
Authority ID field in the AD ID is to benefit the market competition among
multiple ID registration and administrative authorities.
The business model of this ID registration and administration is similar to that
of the Domain Name Service (DNS). The owner of the ID should pay for the ID
administration and the corresponding ID/Locator mapping service.
Generation of the hierarchical host identifiers is similar to the generation of
Cryptographically Generated Addresses (CGA) [6]. In CGA, the process of generating
a new CGA takes three input values: a 64-bit subnet prefix, the public key of the
address owner as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo
and the security parameter Sec, which is an unsigned three-bit integer. In RANGI,
the process of generating a new HI also takes three input values: the n-bit AD ID
(the suitable value of "n" has not been determined), the public key and the
security parameter Sec.
2.5. Host Locators
A RANGI locator is a specific IPv6 address with an IPv4 address embedded in the
last 4 octets. As shown in Figure 2, the first 96 bits of the locator are "Locator
Domain Identifier" (LD ID). This part can be used to globally uniquely identify
each LD and it is a provider-assigned (PA) /96 IPv6 prefix. The LD ID has a
hierarchical structure for topological aggregation (e.g., in CIDR style). The
second part is an IPv4 address. This IPv4 address just needs to be unique within
the LD scope.
|<------- 96 bits -------->|<---- 32 bits--->|
+--------------------------+-----------------+
| LD ID | IPv4 |
+--------------------------+-----------------+
Figure 2. Host Locator Structure.
The proposed RANGI locator is designed to allow easy transition from IPv4 networks
to IPv6 networks. Today's networks are mostly IPv4 based and the transition to
IPv6 is slower than expected. However, IPv6 hosts exist in the current Internet.
It is important to accept the fact that the Internet cannot change from IPv4 to
IPv6 on a single day. The hierarchical RANGI locator structure depicted as in
Figure 2 can make this transition process easier.
Xu and Jain Expires September 4, 2009 [Page 5]
Internet-Draft A Transition Mechanism for RANGI March 2009
2.6. ID Sublayer
All host based services connect using host IDs. Hence, for performing these
services, RANGI introduces a new RANGI ID sublayer in the network layer of the
current host protocol stack. The introduction of this sublayer serves two primary
purposes:
1. It implements the end-host responsibilities of the distributed host
administrative domain functions.
2. It de-couples the concerns of a logical end-to-end connectivity over host
administrative domains from the concerns of physical end-to-end connectivity over
locator domains.
The separation of logical connectivity/physical connectivity concerns has huge
implications on the flexibility and functionality of the Internet. In the context
of RANGI, logical connections over immutable host IDs are shielded from locator
changes as a result of host mobility or multi-homing. Also, a logical link can
accrue attributes of security, trust and reliability through inter-administrative
domain negotiations during connection-setup.
2.7. Packet Format
RANGI-aware hosts reuse IPv6 protocol stack and packet format. The RANGI sublayer
information (host identifier) simply appears as a Next Header in the IPv6 packet
(as shown in Figure 3), whereas the locator is filled as the IPv6 address in the
IPv6 header (as shown in Figure 4). The routers process and forward these RANGI
packets as ordinary IPv6 packets.
Xu and Jain Expires September 4, 2009 [Page 6]
Internet-Draft A Transition Mechanism for RANGI March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Protocol Type | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Host ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Host ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Host Identifier Header Format
Xu and Jain Expires September 4, 2009 [Page 7]
Internet-Draft A Transition Mechanism for RANGI March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Source LD ID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Destination LD ID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Host Locator Header Format
3. RANGI: Assumptions
The following are the assumptions of the operational environment of RANGI.
1. Hosts: All hosts in RANGI domains are basically IPv6 hosts that are RANGI-aware.
Each host has an IPv4 local address and a set of IPv6 global addresses. The term
"local" means that this address is routable only within the precincts of the
legacy IPv4 routing domain. Each RANGI-aware host also has a 128 bit global ID and
IPv6 aware higher layer protocols. The RANGI-aware hosts are capable of supporting
IPv6 over IPv4 tunnels.
2. Border Routers: Border routers have similar requirements as that of RANGI hosts
and all border routers support IPv6. Additional border router specific
requirements include being able to setup IPv6 based BGP sessions with other border
routers. Border routers in RANGI are also called "Locator Domain Border Routers"
or LDBRs.
Xu and Jain Expires September 4, 2009 [Page 8]
Internet-Draft A Transition Mechanism for RANGI March 2009
3. Core (non-border) Routers: The core routers stand between RANGI hosts and their
LDBRs (or between LDBRs) and may be IPv4 or IPv6 routers. Generally in the first
phase of RANGI deployment, core routers need not change. As core routers upgrade
to IPv6 over time, RANGI becomes more efficient operationally. Till then RANGI
depends on IPv6 over IPv4 tunneling mechanisms to interoperate with IPv4 core
routers.
4. RANGI: Architecture Description
4.1. ID/Locator Mapping Resolution
ID/locator split implies a need for storing and distributing the mapping of
identifiers and locators.
Within RANGI, the mappings of host name and HI are stored in the DNS system, while
the mappings of HI and locator are stored in a distributed id/locator mapping
system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a reverse DNS
system.).
When we use hierarchical DHT as the mapping system, we need to use the AD ID
(first 96 bits of the Host ID) as a key in the top-level DHT ring to determine the
corresponding bottom-level DHT ring. Then we use the hash part (the last 32 bits
of the Host ID) as a key to determine the corresponding peer which stores the key
value pair. Of course, the top-level DHT ring can be split further into multiple
levels since the AD ID itself has hierarchical structure.
The resolution infrastructure for the flat host identifier has no "pay-for-your-
own" model, as the flat names are stored at essentially random nodes. On the
contrary, the resolution infrastructure for the hierarchical host identifier, as
used in RANGI, has reasonable business and trust model, since the hierarchical
host identifier has clear organization affiliation and so the identifier resource
can be managed with clear administrative boundaries.
4.2. Routing and Forwarding System
Within RANGI, LDs are connected via Locator Domain Border Routers (LDBRs). A LDBR
has at least one locally unique IPv4 address in each LD to which it is connected.
The adjacent LDBRs exchange LD ID or LD prefix (The LD ID can be aggregated into
LD prefix) reachability information with an inter-LD routing protocol. In fact,
the BGP for IPv6 address family can be used directly as the inter-LD routing
protocol with the prefix length being shorter than /96.
4.2.1. Host Behavior
Generally, a source host will obtain the locator of the destination host from the
ID/locator mapping system before initializing a communication with the destination
host. If the LD of the source host is the same as that of the destination host,
Xu and Jain Expires September 4, 2009 [Page 9]
Internet-Draft A Transition Mechanism for RANGI March 2009
the source host will send the packets directly to the destination host via an IPv6
over IPv4 tunnel. Otherwise, the source host will forward the packets towards the
local LDBR via an IPv6 over IPv4 tunnel.
Hosts can get their local LDBR information in some ways, for example, a new
Dynamic Host Configuration Protocol (DHCP) option can be used to convey this
information, or a well-known LD-scope anycast address can be allocated to the
local LDBRs.
4.2.2. LDBR Behavior
LDBRs establish MP-BGP session among them so as to exchange LD reachability
information. In fact, the LD reachability information is IPv6 routing information
and the IPv6 prefix mask length is less than /96. LDBR can forward IPv6 packets on
the basis of the LD ID part (first 96 bits) of the special IPv6 address over IPv4
tunnel.
4.2.3. Non-LDBR Router Behavior
There is hardly any additional requirement on the Non-LDBR routers. So there is no
need for these internal routers to be upgraded. These non-LDBR routers just need
to support IPv4 forwarding capability.
4.2.4. Forwarding Procedure
RANGI introduces a two-level routing structure which is composed of LD ID based
routing and IP address based routing. The former is used for inter-LD routing
while the latter is used for intra-LD routing.
A simple RANGI routing procedure is illustrated in Figure 5. Before host A sends
out the packet, it looks up the current locator of the remote host B through the
ID/Locator mapping system. After it gets the RANGI locator of the remote host, it
will tunnel the packets to its local LDBR. The LDBR shall find the next hop LDBR
based on the IPv6 global routable locator, and forward the packets to it. For the
intermediate transit networks, if the core routers are legacy IPv4 and if the
packet needs to traverse over them, the ingress LDBR (for that locator domain)
tunnels the packet to the egress LDBR of the same locator domain in IPv6 over IPv4
tunnels.
Xu and Jain Expires September 4, 2009 [Page 10]
Internet-Draft A Transition Mechanism for RANGI March 2009
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | | Payload | | Payload | | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) |
+-------------+ +-------------+ +-------------+ +-------------+
|IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 |
| (A) (B) | | (A) (B) | | (A) (B) | | (A) (B) |
+-------------+ +-------------+ +-------------+ +-------------+
|IPv4->IPv4 | | IPv4->IPv4 | |IPv4->IPv4 |
| (A) (BR1) | |(BR2) (BR3) | | (BR4) (B) |
+-------------+ +-------------+ +-------------+
|<- A to BR1 ->|<-BR1 to BR2 ->|<-BR2 to BR3 ->| |<-BR4 to B ->|
+--------- ------ ---------|
+---+ \ / \ / +---+
| | \ / \ / /| |
+---+\\ \ / \ / // +---+
host| \\ | | | | / | Host
A | \\ +---+ +---+ +---+ +---+// | B
| \| +----+ +------+ +---+ / |
| +---+- -+---+ +---+ +---+
| LD #1 BR1| |BR2 BR3| |BR4 |
\ / \ / \ /
\ / \ LD #2 / \LD #3 /
\ / \ / \ /
------ ------ ------
Figure 5. Routing Procedure
For the intra-LD routing, RANGI uses the IPv6-over-IPv4 tunneling between LDBRs
(or between LDBRs and hosts). This usage of IPv6-over-IPv4 tunneling looks more
like the usage of the MAC addresses between routers in current Internet (although
they are not exactly the same). That's to say, the IPv6-over-IPv4 tunnel plays the
role of the link-layer inside an LD (between two LDBRs or between LDBRs and hosts).
By doing so, RANGI can achieve a smooth IPv4/IPv6 transition. Once the internal
routers within LD are upgraded to IPv6, the requirement of IPv6 over IPv4 tunnel
between the LDBRs or between LDBRs and hosts will be eliminated and the packets
will be delivered by the LDBRs and the internal IPv6 routers hop by hop without
tunneling as shown in Figure 6.
Xu and Jain Expires September 4, 2009 [Page 11]
Internet-Draft A Transition Mechanism for RANGI March 2009
+-------------------+ +-------------------+ +-------------------+
| Payload | | Payload | | Payload |
+-------------------| +-------------------| +-------------------|
| HI(A)->HI(B) | | HI(A)->HI(B) | | HI(A)->HI(B) |
+-------------------| +-------------------| +-------------------|
| IPv6(A)->IPv6(B) | | IPv6(A)->IPv6(B) | | IPv6(A)->IPv6(B) |
+-------------------| ++------------------| +-------------------|
|IPv4(A)->IPv4(BR1) |
+-------------------+
|<--- A to BR1 --->|<----- BR1 to BR4 --->|<--- BR4 to B --->|
/------ ------ ------
+---+ \ | / \ / +---+
| | \ | / \ / /| |
+---+\\ \ | / \ / // +---+
Host A | \\ | | | | / |HostB
| \\ +---+ +---+ +---+ +---+// |
| \| +--- + +------+ +---- + / |
| +---+- +---+ +---+ +---+ |
| LD #1 BR1 | |BR2 BR3 | |BR4 |
\ / \ LD #2 / \ LD #3 /
\ IPv4 / \ IPv6 / \ IPv6 /
\ Only / \ Only / \ Only /
------ ------ ------
Figure 6. Smooth IPv4/IPv6 transition in RANGI.
4.3. Multi-homing and Traffic Engineering
RANGI proposes a site multi-homing solution using PA locators (shown in Figure 7).
Each multi-homed stub LD shall be given an LDID by each ISP. In fact, these LD IDs
are /96 IPv6 prefixes which are provider-aggregatable . The hosts within the site,
in turn, have multiple locators by concatenating the provider assigned LD ID with
the local IPv4 address. The hosts register their locators with the ID/Locator
mapping system. As shown in Figure 7, host A has two LDIDs, LDID_1 is allocated
from ISP1, while LDID_2 is allocated from ISP2, host A could choose either one as
the source LDID of the outgoing packet. Upon receiving the packet, the site exit
LDBR BR1 can implement source-based policy routing. For example, if the source LD
is LDID_1, the packet will be forwarded into the ISP1's network, otherwise, it
will be forwarded into ISP2's network.
Xu and Jain Expires September 4, 2009 [Page 12]
Internet-Draft A Transition Mechanism for RANGI March 2009
------
/ \
/ \
/ \
| |
+---+ |
+ +- |
*---+ |
/ |BR 2 |
/ \ /
/------ / \ ISP#1 /
+---* \ / \ /
| | \ / ------
+---+\\ \ /
Host A | \\ | /
| \\ +---+ /
| \| +/ -----\
| +---+-- / \
| BR 1 | -- / \
\ / -- / \
\ / -- | |
\ / -- +---+ |
------ --+ |
Site A +---+ |
|BR 3 |
\ /
\ ISP#2 /
\ /
------
Figure 7. Site multihoming
The site-controlled traffic-engineering works as follows:
I. The source host sends out a packet using the one of its LDIDs
(assuming LDID_1 being used) as the source LD ID.
II. The packet is intercepted by the LDBR BR1 and depending on the
traffic-engineering policy, the source LD ID of the packet may
be re-written from LDID_1 to LDID_2. Then BR1 forwards the
packet into ISP2's network due to source-based policy routing.
III. Once the packet arrives at the destination host, that host will
use the source LD ID in the received packet as the destination
LD ID in the response packets. So the response packet will also
enter the site A through the ISP2's network.
Xu and Jain Expires September 4, 2009 [Page 13]
Internet-Draft A Transition Mechanism for RANGI March 2009
IV. The source host could accept this change and use LD ID 2 as the
source LD ID in the subsequent packets.
In this way, the site-controlled traffic-engineering by rewriting the
source LD ID will have effect on the path (upstream ISP) selection
for both the outgoing packets and the incoming packets. In addition,
the multihoming and traffic-engineering usage in RANGI will not cause
the routing table growth.
4.4. Mobility
In RANGI, when a host physically moves from one attachment to another,
its host ID remains unchanged. The host needs to register the new
locator with the ID/locator mapping system. Meanwhile, it should
notify the corresponding entity of its new locator as soon as
possible.
5. Summary
RANGI achieves almost all of goals set by RRG as follows:
1. Routing Scalability: Scalability is achieved by separating the
identifier and locator. Global routing is done based on provider
assigned LD IDs (/96 IPv6 prefixes) of the locators.
2. Traffic Engineering: LDBRs can overwrite the prefix part of the
source locator and implement source-based policy routing
according to the source LD ID.
3. Mobility and Multihoming: Applications and transport layers are
bound to host IDs and so the sessions will not be interrupted due
to mobility or multihoming.
4. Simplified Renumbering: When changing providers, the local
locators (IPv4 part of the locators) do not change. The IPv4 core
routers don't need renumbering.
5. Decoupling Location and Identifier: Obvious.
6. Routing Quality: Since LDBRs only exchange LD reachability and
the topology change within LD will not be disclosed outside, the
routing stability could be improved greatly.
7. Routing Security: RANGI reuses current routing system and does
not introduce any security risk into the routing system.
Xu and Jain Expires September 4, 2009 [Page 14]
Internet-Draft A Transition Mechanism for RANGI March 2009
8. Incremental Deployability: Core routers within LD can still be
IPv4-only. RANGI allows easy transition from current IPv4
networks to future IPv6 networks.
It should be pointed out that many of the mechanisms used in RANGI
have been proposed earlier in isolated contexts to solve either
similar or different problems. RANGI provides a single cohesive
architecture that uses all these mechanisms together to provide
additional benefits. For example, the idea of embedding IPv4 address
in IPv6 address was proposed in ISATAP [19]. Address overwriting at
border routers was proposed in GSE [12] and Six/One [20].
Cryptographic addresses are described in CGA [6].
A separate internet draft [26] discusses the details of a new
function unit called RANGI proxy that allows RANGI hosts to coexist
with all the legacy IPv4 or IPv6 hosts.
6. Acronyms
RANGI: Routing Architecture for Next Generation Internet
RAWS: Routing and Addressing Workshop
PA: Provider Aggregatable
AS: Autonomous Systems
ID: Identifier
ADID: Administrative Domain ID
LDID: Locator Domain ID
BR: Border Router
LDBR: Locator Domain Border Router
7. Security Considerations
TBD.
Xu and Jain Expires September 4, 2009 [Page 15]
Internet-Draft A Transition Mechanism for RANGI March 2009
8. IANA Considerations
TBD.
9. Informative References
[1] D. Meyer, L. Zhang, and K. Fall. "Report from the IAB Workshop on
Routing and Addressing". Internet draft, draft-iab-raws-
report-01.txt, work in progress, February 2007.
[2] T. Li, "Design Goals for Scalable Internet Routing", draft-irtf-
rrg-design-goals-01, July 2007.
[3] N. Chiappa, "Endpoints and Endpoint Names: A Proposed Enhancement
to the Internet Architecture", URL
http://ana.lcs.mit.edu/~jnc//tech/endpoints.txt, 1999.
[4] B. Carpenter, "Architectural Principles of the Internet", RFC1958,
June 1996.
[5] R. Moskowitz and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[6] T. Aura, "Cryptographically Generated Addresses (CGA)", RFC3972,
Mar 2005.
[7] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert "Network
Mobility (NEMO) Basic Support Protocol", RFC 3963, January
2005.
[8] I. Castineyra, N. Chiappa and M. Steenstrup, "The Nimrod Routing
Architecture", RFC 1992, August 1996.
[9] R. Hinden, "New Scheme for Internet Routing and Addressing
(ENCAPS) for IPNG", RFC 1995, June 1996.
[10] L. Subramanian, M. Caesar, C.T. Ee, M. Handley, M. Mao, S.
Shenker and I. Stoica, "HLP: A Next Generation Inter-domain
Routing Protocol", SIGCOMM'05, August 2005, Philadelphia,
Pennsylvania, USA.
[11] L. Garces-Erice, E. Biersack, P. Felber, K. Ross, and G. Urvoy-
Keller, "Hierarchical Peer-to-peer Systems" In Proc. Euro-
Par 2003, Klagenfurt,Austria, 2003.
Xu and Jain Expires September 4, 2009 [Page 16]
Internet-Draft A Transition Mechanism for RANGI March 2009
[12] M. O'Dell, "GSE-An Alternative Addressing Architecture for IPv6",
Internet-Draft, Feb 1997.
[13] B. Ahlgren, J. Arkko, L. Eggert and J. Rajahalme,"A Node
Identity Internetworking Architecture", 9th IEEE Global
Internet Symposium, Barcelona, Spain, April 2006.
[14] Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker and
Sonesh Surana, "Internet Indirection Infrastructure", Proc.
ACM SIGCOMM, Pittsburgh, PA, USA, August 2002.
[15] Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia
Ratnasamy,Scott Shenker, Ion Stoica and Michael Walfish, "A
Layered Naming Architecture for the Internet", Proc. ACM
SIGCOMM, Portland, Oregon, USA, August 30 - September 3,
2004.
[16] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica
and S. Shenker, "ROFL: Routing on Flat Labels", SIGCOMM'06,
September 2006, Pisa, Italy.
[17] H. Soliman, C. Castelluccia, K. El Malki, L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6) ",
RFC4140, August 2005.
[18] Deering, S. and R. Hinden, "IPv6 Metro Addressings",
http://irl.cs.ucla.edu/references/Deering-metro.txt, March
1996.
[19] F. Templin, T. Gleeson, ''Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP),'' RFC 5214, March, 2008.
[20] C. Vogt, ''Six/One: A Solution for Routing and Addressing in
IPv6,'' draft-vogt-rrg-six-one-01.txt, November, 2007.
[21] R. Jain, ''Internet 3.0: Ten Problems with Current Internet
Architecture and Solutions for the Next Generation,'' in
Proceedings of Military Communications Conference (MILCOM
2006), Washington, DC, October 23-25, 2006,
http://www.cse.wustl.edu/~jain/papers/gina.htm
[22] S. Paul, J. Pan, and M. Bowman, ''A Vision of the Next Generation
Internet: A Policy Oriented View,'' British Computer Society
Conference on Visions of Computer Science, Sep 2008,
http://www.cse.wustl.edu/~jain/papers/pona.htm
Xu and Jain Expires September 4, 2009 [Page 17]
Internet-Draft A Transition Mechanism for RANGI March 2009
[23] J. Pan, S. Paul, R. Jain, and M. Bowman, ''MILSA: A Mobility and
Multihoming Supporting Identifier-Locator Split
Architecture for Naming in the Next Generation Internet,,''
Globecom 2008, Nov 2008,
http://www.cse.wustl.edu/~jain/papers/milsa.htm
[24] X. Xu and D. Guo, ''Hierarchical Routing Architecture,'' Proc. 4th
Euro-NGI Conference on Next Generation Internetworks,
Krakow, Poland, 28-30 April 2008, 7 pp.,
http://www.cse.wustl.edu/~jain/papers/hra.htm
[25] J. Pan, R. Jain, S. Paul, M. Bowman, X. Xu, and S. Chen,
"Enhanced MILSA Architecture for Naming, Addressing,
Routing and Security Issues in the Next Generation
Internet," Proc. IEEE International Conference in
Communications (ICC) 2009, Dresden, Germany, June 14-18,
2009, http://www.cse.wustl.edu/~jain/papers/emilsa.htm
[26] X. Xu and R. Jain, ''A Transition Mechanism for
Routing Architecture for the Next Generation Internet
(RANGI)'', draft-xu-rangi-proxy-00.txt, March 2009.
10. Acknowledgments
We would like to thank several experts who commented on the earlier
versions of this proposal including Dave Oran, Joel Halpern, and Tony
Li.
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Phone: +86 10 82836073
Email: xuxh@huawei.com
Raj Jain
Washington University in Saint Louis
One Brookings Drive, Campus Box 1045
Saint Louis, MO 63130 USA
Phone: +1 314 935 4963
Email: jain@cse.wustl.edu
Xu and Jain Expires September 4, 2009 [Page 18]