Network Working Group Xiaohu Xu Internet Draft Huawei Intended status: Informational Raj Jain Expires: September 2009 Washington Univ. in St. Louis March 4, 2009 A Transition Mechanism for Routing Architecture for the Next Generation Internet (RANGI) draft-xu-rangi-proxy-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 The Routing Architecture for the Next Generation Internet (RANGI) is a proposal for solving routing scalability, mobility, multihoming, Xu and Jain Expires September 4, 2009 [Page 1] Internet-Draft A Transition Mechanism for RANGI March 2009 traffic engineering and other issues facing the current Internet. RANGI is described in a separate document [RANGI]. This document describes a transition mechanism for RANGI. With this mechanism, legacy IPv4 or IPv6 hosts can communicate with RANGI hosts, and vice versa. This allows RANGI to be deployed incrementally in the current Internet. Table of Contents 1. Introduction.................................................3 2. Transition Mechanism.........................................3 2.1. Communication between IPv6 and RANGI Hosts..............3 2.1.1. IPv6 Hosts Communicate with RANGI Hosts............4 2.1.2. RANGI Hosts Communicate with IPv6 Hosts............5 2.2. Communication between IPv4 and RANGI Hosts..............6 2.2.1. IPv4 Hosts Communicate with RANGI Hosts............7 2.2.2. RANGI Hosts Communicate with IPv4 Hosts............7 3. Security Considerations......................................8 4. Conclusions..................................................8 5. References...................................................8 5.1. Normative References....................................8 5.2. Informative References..................................9 Author's Addresses..............................................9 Xu and Jain Expires September 4, 2009 [Page 2] Internet-Draft A Transition Mechanism for RANGI March 2009 1. Introduction The Routing Architecture for the Next Generation Internet (RANGI) described in [RANGI] is designed to address several issues that the current Internet is facing, e.g., routing scalability, mobility, multi-homing and traffic-engineering, etc. 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. RANGI uses a 128-bit host identifier, which consists of two parts, the first part is the Administrative Domain Identifier (AD ID) which has organizational structure and global uniqueness, and the second part is a cryptographic hash over the AD ID and its public key as in Cryptographically Generated Addresses (CGA)[CGA]. The locator is a provider-assigned IPv6 address with local IPv4 address embedded in the last four octets. The mapping from FQDN to identifier is stored in Domain Name Service (DNS) system, whereas the mapping from identifier to locator is stored in another mapping system (e.g., hierarchical Distributed Hash Table (DHT) system, reverse DNS system, etc.). Since the identifier is as long as IPv6 address, it can be stored directly in DNS servers as an AAAA resource record (RR). As specified in [Goals], incremental deployability is one of the design goals for a new routing and addressing architecture. Thus, in this document, we define a transition mechanism with which legacy hosts can communicate with RANGI hosts, and vice versa. Note that the Application Layer Gateway (ALG) used for transforming the address information in application layers is not specified in this document. In order to distinguish identifiers from ordinary IPv6 addresses and locators, identifiers use a specific prefix, which is to be allocated by IANA. 2. Transition Mechanism 2.1. Communication between IPv6 and RANGI Hosts As mentioned previously, RANGI hosts can store their identifiers as AAAA resource records in the DNS system. Thus, when a legacy IPv6 host makes a DNS query for a RANGI host, the identifier is returned Xu and Jain Expires September 4, 2009 [Page 3] Internet-Draft A Transition Mechanism for RANGI March 2009 as an AAAA resource record in the DNS response. This identifier is processed by the legacy host as an IPv6 address. As shown in Figure 1, A is a legacy IPv6 host, and B is a RANGI host. The proxy is located as the exit border router in the IPv6 site, and maintains an Identifier (ID)/Locator mapping table which is used during the process of transforming IPv6 packets to RANGI packets and vice versa. For the remainder of this document, the ID/Locator mapping table is called mapping table for short. +-------------------------+ +-------------------------+ | +--------+ +-+-----+ | +--------+ | | | A +--------- --+ Proxy +-----+----------+ B | | | +--------+ +-+-----+ | +--------+ | | | | | | IPv6 Site Network | | RANGI Site Network | +-------------------------+ +-------------------------+ Figure 1. Communication between IPv6 and RANGI Networks The basic idea is to make the proxy assign each legacy IPv6 host a secure identifier (associated with a public/private key pair). Then the packets between the proxy and the RANGI host can be secured in an IPsec tunnel. It should be noted that if security is not required, the Provider-Independent (PI) IPv6 address of the legacy IPv6 host could be used as an identifier directly. 2.1.1. IPv6 Hosts Communicate with RANGI Hosts Assume IPv6 Host A attempts to initiate a communication with RANGI host B. Host A performs a DNS lookup for B's IPv6 address, and the identifier of B is returned as an AAAA resource record. Then host A constructs IPv6 packets with B's identifier as the destination IPv6 address. We assume here that the proxy has advertised in the IPv6 site network an IPv6 route to the identifier-specific prefixes. So the packets with the identifier as the destination IPv6 address can reach the proxy along that route. Upon receiving the packets, the proxy attempts to determine the identifier corresponding to the source IPv6 address in its mapping table. If not found, the proxy should assign a temporary identifier for A and store the mapping between A's IP address and the identifier in its mapping table (as illustrated in Figure 2). Xu and Jain Expires September 4, 2009 [Page 4] Internet-Draft A Transition Mechanism for RANGI March 2009 +------------+------------+------------+---------+ |IPv6 Address| Identifier | Locator | TTL(s) | +------------+------------+------------+---------+ | IPv6(A) | Temp ID(A) | | 20 | +------------+------------+------------+---------+ | ... | ... | ... | ... | +------------+------------+------------+---------+ Figure 2. ID/locator Mapping Table Meanwhile, the proxy also attempts to find B's locator in its mapping table. If not found, it should perform a lookup through the ID/locator mapping system. Once resolution succeeds, the proxy should cache the ID/locator mapping information in its mapping table and transform the packets into RANGI packets (see Figure 3). Otherwise, the packets will be delayed or dropped. +--------------------------+ | Transport | +-----------------------------+ +-------------+------------+ | Transport | | Dest_ID | Src_ID | +--------------+--------------+ +-------------+------------+ | Dest_IP | Src_IP | <----> |Dest_Locator |Src_Locator | +--------------+--------------+ +-------------+------------+ | Data Link | | Data Link | +-----------------------------+ +--------------------------+ IPv6 Packet RANGI Packet Figure 3. Packet Header Translation In Figure 3, the source identifier in RANGI packets is A's temporary identifier, the destination identifier is B's identifier, the source locator is one of the proxy's locators, and the destination locator is B's locator. After receiving the packets, B sends response packets back. Once the response packets arrive at the proxy, the proxy transforms these packets into IPv6 packets according to the mapping entries in its mapping table. In the IPv6 packets, the source address is B's identifier, and the destination address is A's IPv6 address. 2.1.2. RANGI Hosts Communicate with IPv6 Hosts In order to make the legacy IPv6 hosts in a site accessible to RANGI hosts, the proxy should assign each of its IPv6 hosts a globally unique identifier and store the mapping of the identifier and the corresponding IPv6 address in its mapping table. The identifier Xu and Jain Expires September 4, 2009 [Page 5] Internet-Draft A Transition Mechanism for RANGI March 2009 should also be stored in the DNS system as an AAAA resource record. Moreover, the identifier, associated with one of the proxy's locators, should be stored in the ID/locator mapping systems. Before initiating a communication with IPv6 host A, RANGI host B needs to perform a DNS lookup and gets A's identifier as an AAAA resource record. Then B obtains A's locator (the proxy's locator in fact) from the ID/locator mapping system according to A's identifier. After that, B constructs RANGI packets and sends them out. Upon receiving the packets, the proxy finds the IPv6 address of A in its mapping table, and caches B's identifier and locator in its mapping table. The proxy then transforms the packets into IPv6 packets. In the IPv6 packets, B's identifier is used as the source IPv6 address, while A's IPv6 address is used as the destination IPv6 address. When A receives the packets, it sends response packets back. Upon receiving the response packets, the proxy transforms the packets into RANGI packets according to the corresponding mapping entries. 2.2. Communication between IPv4 and RANGI Hosts The process of translating between IPv4 and RANGI is a bit more complex than the translation between IPv6 and RANGI. As shown in Figure 4, again there is a proxy located as exit border router in legacy IPv4 site network. +-------------------+ +--------------------+ |+------+ +--+----+ | +------+ | || A +--------+ Proxy +---+-----------+ B | | |+------+ +--+----+ | +------+ | | | | | | IPv4 Site Network | | RANGI Site Network | +-------------------+ +--------------------+ Figure 4. Communication between IPv4 and RANGI Hosts The basic idea is to make the proxy assign each legacy IPv4 host a secure identifier (associated with a public/private key pair). Then the packets between proxy and RANGI host can be secured in an IPsec tunnel. Again, if there is no need for security, the proxy could use the combination of a specific /96 IPv6 prefix and A's IPv4 address as A's identifier. Xu and Jain Expires September 4, 2009 [Page 6] Internet-Draft A Transition Mechanism for RANGI March 2009 2.2.1. IPv4 Hosts Communicate with RANGI Hosts Before initiating a communication with RANGI host B, the IPv4 host A performs a DNS lookup for B's IPv4 address. The DNS request would travel from IPv4 network towards the DNS server S on the RANGI network. Upon receiving the DNS request, the proxy rewrites the "A" record in the DNS message as "AAAA" record, and then translates this IPv4 packet into a RANGI packet according to an already-configured mapping entry for the DNS server S. +------------+------------+------------+---------+ |IPv4 Address| Identifier | Locator | TTL(s) | +------------+------------+------------+---------+ | IPv4(S) | ID(S) | Loc(S) | -- | +------------+------------+------------+---------+ | ... | ... | ... | ... | +------------+------------+------------+---------+ Figure 5. ID/locator Mapping Table Upon receiving the corresponding DNS response, the proxy obtain B's identifier as an AAAA resource record, allocates B a temporary IPv4 address from its local IPv4 address pool, and caches the mapping of B's identifier and IPv4 address in its mapping table. Meanwhile, the proxy replaces the AAAA record in DNS response as an A record with the temporary IPv4 address filled in and sends this DNS response message to the DNS resolver. In addition, the proxy resolves B's locator according to the identifier from ID/locator mapping system. Once the resolution succeeds, the proxy caches the mapping in its mapping table. Optionally, the proxy could assign A a temporary identifier and cache the binding of this identifier, A's IPv4 address and one of the proxy's locator in its mapping table. Of course, this action can also be performed when data packets (other than DNS messages) are received from A. As the DNS resolution succeeds, A constructs IPv4 packets and sends them out. Upon receiving these packets, the proxy translates them to RANGI packets according to the existing mapping entries in its mapping table. When the response packets are received, the proxy transforms them into IPv4 packets accordingly. 2.2.2. RANGI Hosts Communicate with IPv4 Hosts In order to make IPv4 hosts in a site accessible to RANGI hosts, the site proxy should assign each IPv4 host in the site a globally unique Xu and Jain Expires September 4, 2009 [Page 7] Internet-Draft A Transition Mechanism for RANGI March 2009 identifier, and store the bindings of the identifiers and the corresponding IPv4 addresses in its mapping table. In addition, these identifiers should also be stored in the DNS system as AAAA resource records of the corresponding IPv4 hosts (of course, this can also be implemented by using DNS-ALG on the proxy to translate between the "A" and the "AAAA" records in the DNS messages). The proxy also stores these identifiers and one of the proxy's locators in the ID/locator mapping system. Before initiating a communication with IPv4 host A, RANGI host B obtains A's identifier and locator from its DNS system and ID/locator mapping system, respectively. With such information, B would construct RANGI packets and send them to A. Upon receiving these packets, the proxy would allocate B a temporary IPv4 address from its local IPv4 address pool, and cache the binding of B's identifier, locator and the temporary IPv4 address in its mapping table. After doing this, the proxy would transform the RANGI packets into IPv4 packets according to the existing mapping entries in its mapping table. Subsequently, the proxy can also translate the response IPv4 packets from A into RANGI packets going to B according to the mapping entries mentioned above. 3. Security Considerations The security details related to the proxy mechanism has not been explored. 4. Conclusions With the proxy mechanism defined in this document, legacy IPv6 and IPv4 hosts can communicate with RANGI hosts and vice versa. This allows RANGI to be deployed incrementally. This first draft is our initial attempt to develop a transition mechanism. We are still working on several details and would appreciate feedback and suggestions for improvement. 5. References 5.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xu and Jain Expires September 4, 2009 [Page 8] Internet-Draft A Transition Mechanism for RANGI March 2009 [RFC2234] D. Crocker and P. Overell (Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 5.2. Informative References [Goals] T. Li, "Design Goals for Scalable Internet Routing", draft- irtf-rrg-design-goals-01, July 2007. [RANGI] X. Xu and R. Jain, "Routing Architecture for the Next Generation Internet (RANGI), draft-xu-rangi-00, March 2009. [HRA] 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 [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", RFC3972, Mar 2005. Author's 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 9]