Internet DRAFT - draft-xu-rangi-proxy

draft-xu-rangi-proxy



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]