Network Working Group X. Xu Internet Draft Huawei Intended status: Informational Expires: January 2010 July 13, 2009 Transition Mechanisms for Routing Architecture for the Next Generation Internet (RANGI) draft-xu-rangi-proxy-01.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 January 13, 2010. 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. Xu Expires January 13, 2010 [Page 1] Internet-Draft Transition Mechanisms for RANGI July 2009 Abstract The Routing Architecture for the Next Generation Internet (RANGI) described in [RANGI] is a proposal for solving routing scalability, mobility, multihoming, traffic engineering and other issues facing the current Internet. This document describes some transition mechanisms for the RANGI. With these mechanisms, legacy IPv4 and IPv6 hosts can communicate with RANGI hosts, and vice versa. Table of Contents 1. Introduction..................................................3 2. Transition Mechanisms.........................................3 2.1. Communication between IPv6 and RANGI with Site Proxy.....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 IPv6 and RANGI without Site Proxy..6 2.3. Communication between IPv4 and RANGI with Site Proxy.....6 2.3.1. IPv4 Hosts Communicate with RANGI Hosts.............7 2.3.2. RANGI Hosts Communicate with IPv4 Hosts.............8 2.4. Communication between IPv4 and RANGI without Site Proxy..9 3. Security Considerations.......................................9 4. Acknowledgments...............................................9 5. References....................................................9 5.1. Normative References.....................................9 5.2. Informative References...................................9 Author's Addresses...............................................9 Xu Expires January 13, 2010 [Page 2] Internet-Draft Transition Mechanisms for RANGI July 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 kind of id/locator split proposal which inserts an ID layer in the middle of the network layer and the transport layer. It introduces 128-bit long host identifiers which consist 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 the public key of the host. The locators in RANGI are provider-assigned IPv6 addresses with local IPv4 addresses embedded in the last four octets. In order to distinguish identifiers from IPv6 addresses, identifiers are associated with a specific prefix, which is to be allocated by IANA. The mappings from FQDN to identifier are stored in the Domain Name Service (DNS) system, whereas the mappings from identifier to locator are stored in other distributed mapping system (e.g., hierarchical Distributed Hash Table (DHT) system, reverse DNS system etc.). Since the identifiers are as long as IPv6 addresses, they can be stored directly in DNS servers as AAAA resource records (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 several transition mechanisms for the RANGI with which legacy IPv4 and IPv6 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. 2. Transition Mechanisms 2.1. Communication between IPv6 and RANGI with Site Proxy As mentioned previously, RANGI hosts can store their identifiers as AAAA resource records in the DNS system. Thus, when legacy IPv6 hosts make DNS query for RANGI hosts, identifiers are returned as AAAA resource records in the DNS responses and are treated by legacy hosts as IPv6 addresses. As illustrated in Figure 1, host A is a legacy IPv6 host, host B is a RANGI host, and a proxy is located at the edge of the IPv6 site network for host A. This so-called site proxy maintains an Identifier (ID)/Locator mapping table which is used to transform IPv6 packets to RANGI packets and vice versa. In the remainder of this document, the Xu Expires January 13, 2010 [Page 3] Internet-Draft Transition Mechanisms for RANGI July 2009 mapping table refers to the ID/Locator mapping table, and the proxy refers to the site proxy unless mentioned otherwise. +-------------------------+ +-------------------------+ | +--------+ +-+-----+ | +--------+ | | | A +--------- --+ Proxy +-----+----------+ B | | | +--------+ +-+-----+ | +--------+ | | | | | | IPv6 Site Network | | Internet | +-------------------------+ +-------------------------+ Figure 1. Communication between IPv6 and RANGI hosts If the packets transported between the proxy and host B need to be secured in IPsec tunnels, the proxy needs to assign each legacy IPv6 host a globally unique secure identifier (associated with a public/private key pair). Otherwise, Provider-Independent (PI) IPv6 addresses of the legacy IPv6 hosts can be used as identifiers directly. 2.1.1. IPv6 Hosts Communicate with RANGI Hosts Assume host A attempts to initiate a communication with host B. Host A performs a DNS lookup for host B's IPv6 address, and the identifier of host B is returned as an AAAA resource record. Then host A constructs IPv6 packets with destination IPv6 addresses being host B's identifier. We assume here that the proxy has announced into the IPv6 site network an IPv6 route to the identifier-specific prefix. Hence the packets from the site with destination IPv6 addresses being identifiers can be forwarded towards the proxy. 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 host A and store the mapping from this identifier to host A's IP address in its mapping table (as illustrated in Figure 2). +------------+------------+------------+---------+ |IPv6 Address| Identifier | Locator | TTL(s) | +------------+------------+------------+---------+ | IPv6(A) | Temp ID(A) | | 20 | +------------+------------+------------+---------+ | ... | ... | ... | ... | +------------+------------+------------+---------+ Figure 2. ID/locator Mapping Table Xu Expires January 13, 2010 [Page 4] Internet-Draft Transition Mechanisms for RANGI July 2009 Meanwhile, the proxy also attempts to find host B's locator in its mapping table. If not found, it performs a lookup through the ID/locator mapping system. Once resolution succeeds, the proxy caches the ID/locator mapping information in its mapping table and transforms the IPv6 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 As depicted in Figure 3, the source identifier in RANGI packets is host A's temporary identifier, the destination identifier is host B's identifier, the source locator is one of the proxy's locators, and the destination locator is host B's locator. After receiving the packets, host B sends response packets back. Once the response packets arrive at the proxy, they are transformed into IPv6 packets according to the existing mapping entry in the mapping table. In the IPv6 packets, the source address is host B's identifier, and the destination address is host A's IPv6 address. 2.1.2. RANGI Hosts Communicate with IPv6 Hosts In order to make the legacy IPv6 hosts in the site network accessible to the RANGI hosts, the proxy should assign each of these IPv6 hosts a globally unique identifier and store the mappings of the identifier and the corresponding IPv6 address in its mapping table. The identifiers should also be stored in the DNS system as AAAA resource records of the corresponding DNS entries. Moreover, the mappings from identifiers to one of the proxy's locators should also be registered in the ID/locator mapping systems. Before initiating a communication with host A, host B needs to perform a DNS lookup and gets host A's identifier as an AAAA resource record. Then B obtains host A's locator (the proxy's locator in fact) from the ID/locator mapping system. After that, host B constructs RANGI packets and sends them out. Xu Expires January 13, 2010 [Page 5] Internet-Draft Transition Mechanisms for RANGI July 2009 Upon receiving the RANGI packets, the proxy finds the IPv6 address of host A in its mapping table according to the destination identifier (host A's identifier) of these packets, and caches the identifier and locator of host B in its mapping table. Then the proxy transforms these RANGI packets into IPv6 packets. In the IPv6 packets, the source IPv6 address is host B's identifier, while the destination IPv6 address is host A's IPv6 address. When A receives the packets, it sends response packets back. Upon receiving the response packets, the proxy transforms the IPv6 packets into RANGI packets according to the corresponding mapping entries. 2.2. Communication between IPv6 and RANGI without Site Proxy At the early stage of transition, it is un-reasonable to assume that all sites can deploy proxies for legacy IPv6 hosts at the same time. Hence, to facilitate the IPv6 hosts within non-proxy site networks to initiate communication with RANGI hosts, a candidate solution is to deploy a group of special proxies in the transit network. In order to distinguish these proxies located in transit networks from those site proxies deployed at the edge of the site networks, they are called transit proxies in the reminder of this document. Each of the transit proxies takes charge of a certain range of host IDs and needs to announce into the transit network a route to a specific prefix representing the host ID range which it takes charge of. Except of the above differences, the transit proxies have no other difference from the site proxies. For RANGI hosts to initiate communications with those hosts within the non-proxy site network, once the RANGI hosts determine the identifiers (e.g., AAAA records in DNS response) for destination hosts are IPv6 addresses, rather than real identifiers, they will initiate communications with these destination hosts in a traditional IPv6 fashion. 2.3. Communication between IPv4 and RANGI with Site Proxy The translation process between IPv4 packets and RANGI packets is a bit more complex than that between IPv6 packets and RANGI packets. As illustrated in Figure 4, Host A is a legacy IPv4 host, and host B is a RANGI host. A proxy is located as an exit border router at the edge of the IPv4 site network for host A. Xu Expires January 13, 2010 [Page 6] Internet-Draft Transition Mechanisms for RANGI July 2009 +-------------------+ +--------------------+ |+------+ +--+----+ | +------+ | || A +--------+ Proxy +---+-----------+ B | | |+------+ +--+----+ | +------+ | | | | | | IPv4 Site Network | | Internet | +-------------------+ +--------------------+ Figure 4. Communication between IPv4 and RANGI Hosts In order to establish security communication channel with RANGI hosts, the proxy needs to assign each legacy IPv4 host in its network a globally unique secure identifier (associated with a public/private key pair). Then the packets transported between the proxy and RANGI hosts can be secured using the IPsec protocol. Note that if there is no need of security, the proxy could use the synthesized IPv6 addresses of IPv4 hosts (e.g., combinations of a specific /96 IPv6 prefix and their IPv4 address) as their identifiers. 2.3.1. IPv4 Hosts Communicate with RANGI Hosts Before initiating a communication with host B, host A performs a DNS lookup for host B's IPv4 address. The DNS request would travel from IPv4 site network towards the DNS server S in the RANGI network. Upon receiving the DNS request, the proxy transforms the "A" record in the DNS message to an "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 The identifier of host B is transported as an AAAA resource record in the DNS response. Upon receiving the response message, the proxy obtain host B's identifier, allocates host B a temporary IPv4 address from its local IPv4 address pool, and caches the mapping of host B's identifier and IPv4 address in its mapping table. In addition, the proxy replaces the AAAA record in DNS response as an A record with the temporary IPv4 address filled in and sends this modified DNS response message to the DNS resolver. In addition, the proxy resolves Xu Expires January 13, 2010 [Page 7] Internet-Draft Transition Mechanisms for RANGI July 2009 host B's locator from the ID/locator mapping system. Once the resolution succeeds, the proxy caches the mapping in its mapping table. Optionally, the proxy could assign a temporary identifier for host A and cache the binding of this identifier, host 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 host A. Once the DNS resolution succeeds, host 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.3.2. RANGI Hosts Communicate with IPv4 Hosts In order to make IPv4 hosts in the site network accessible to RANGI hosts, the proxy should assign each of the IPv4 hosts in its site network a globally unique 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 host A, host B obtains host A's identifier and locator from the DNS system and the ID/locator mapping system respectively. With such information, host B constructs RANGI packets and sends them out. Upon receiving these packets, the proxy allocates host B a temporary IPv4 address from its local IPv4 address pool, and cache the binding of host 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 into RANGI packets according to the mapping entries. Xu Expires January 13, 2010 [Page 8] Internet-Draft Transition Mechanisms for RANGI July 2009 2.4. Communication between IPv4 and RANGI without Site Proxy For IPv4 hosts within non-proxy site networks to communicate with RANGI hosts, one can use the IPv4->IPv6 translation (e.g., NAT-PT [RFC2766]) and the transit proxy mechanism together to realize two- stage translation. For RANGI hosts to communicate with IPv4 hosts within non-proxy site networks, one can just use the IPv6->IPv4 translation scheme. 3. Security Considerations TBD. 4. Acknowledgments The author would like to thank Raj Jain and Dacheng Zhang for their valuable comments and reviews. 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. 5.2. Informative References [Goals] T. Li, "Design Goals for Scalable Internet Routing", draft- irtf-rrg-design-goals-01, July 2007. [RANGI] X. Xu, "Routing Architecture for the Next Generation Internet (RANGI), draft-xu-rangi-01, July 2009. [RFC2766] G. Tsirtsis, and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 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 Xu Expires January 13, 2010 [Page 9]