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]