Anand Thakur Ajay Jain Head, Telecom Software Delivery HCL Perot Systems February 2003 Internet Draft Document: draft-thakur-integrated-transition-toolbox-00.txt Expires: August 2003 Integrated transition toolbox for 3gpp cases Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes the implementation of a transition 'toolbox' which intelligently choses between usage of application proxies, translation and tunneling depending on the deployment scenario. This document does not attempt to solve NA(P)T-PT related issues, though it does deal with certain issues. 1. Introduction This document describes the implementation of a transition 'toolbox' which intelligently choses between usage of application proxies, translation and tunneling depending on the deployment scenario. This transition 'toolbox' will be referred to as Integrated Transition Toolbox or ITT in short. Various deployment scenarios have been discussed and explained in [3gpp-analysis]. For the benefit of the reader, the scenarios are mentioned below: anand et al [page 1] Integrated transition toolbox for 3gpp cases 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 4) IPv6 UE connecting to an IPv4 node 5) IPv4 UE connecting to an IPv6 node This document does not deal with scenario 3 i.e IPv4 UE connecting to an IPv4 node through an IPv6 network because this scenario is not expected to become prominent at any point of time. Apart from these scenarios, this document also handles some additional scenarios which will be mentioned later on. Though this document does not introduce any new transition mechanism, it does modify the way NA(P)T-PT works (only in some areas). In this toolbox a conscios effort has been made to avoid the usage of DNS-ALG. In addition some ideas from NAT46 have also been taken like the colocation of NA(P)T-PT and name resolver. Conceptual Data Structures: The integrated toolbox(ITT) maintains the following conceptual data structures: i)'R' table : Usage of this table ensures that only those packets that require translation or tunneling use the NA(P)T-PT router as the default router. This table maps a normal IP address to an IP address that has 'NA(P)T prefix'. Such addresses will be reffered to as 'pre-fixed' addresses throughout this document.Packets having this 'pre-fixed' address will automatically use the ITT as the default gateway. ii)Tunnel Flag : Sometimes abbreviated as 'Tf', once this flag is set for a particular IP address, it indicates that packets must be tunneled to that particular address. iii)'M' table : This table maps IPV4 addresses to IPV6 addresses for translation or tunneling as required. The usage of these tables will become clear once the cases are discussed individualy. 2. Assumptions This document makes the folowing assumptions: i) All IPV6 networks are connected to the IPV4 internet via this integrated transition (ITT) mechanism only. ii)All dual-stack nodes who want to maintain connectivity have the following added functionality. Whenever an IPV4 packet is received with its protocol bit set to 41 , it will be stripped off without any further processing and the IP header inside will be further processed. anand et al [page 2] Integrated transition toolbox for 3gpp cases iii) All networks containing IPV6 nodes will have, at their edge a router with two globally unique IPV4 addresses. One of these addresses will be used by the router for itself (referred to as address1 in the remaining portion of this document) and the other for tunneling and translation purposes (referred to as address2 throughout the remainder of this document) , as will become clear later on in this document. iV) All name servers/DNSs in the 6BONE/IPV6/IPV4 internet MUST have 2 entries for an IPV6 node. One will be the "AAAA" address of the node and the other will be a "A" address (address2)belonging to the edge router of the corresponding network. This IPV4 address will be reserved by the router to handle tunnels / translations. A detailed description will be given in one of the subsequent sections. v) A Dual stack node will under normal circumstances attach itself to the corresponding GGSN using an IPv6 PDP context, partly to make sure that a minimum number of IPv4 addresses are used and partly, to make maximum use of the benefits that IPv6 transmission provides. 3. Working of the itt. Though the scenarios mentioned above cover most of the possible cases, combinations of different scenarios may lead to complications. This document in general will deal with the scenarios mentioned above and a simple extension to the proposed solution may be used to cover all possible scenarios. 3.1) IPv6 UE connecting to an IPv6 node through an IPv4 network This scenario is expected to be prevalent in the near future as IPV6 is deployed. In this scenario basically small localised IPV6 islands will start to come into existence which will be largely surrounded by an IPV4 'ocean'. Though the solution proposed here may sound like the introduction of a new transition mechanism, it is actually a means to implement configured tunneling, without the administrator having to manually configure all the destination addresses. In conventional configured tunneling one has to manually configure the router with requisite IP addresses so that the outgoing packets can be encapsulated inside another IP header using information from the configuration tables. In this method, as will be seen, an exactly similar configuration table will be used( reffered to as the 'M' table). But using a unique mechanism, this table will be configured automatically by the ITT, consequently removing the main disadvantage of configured tunneling. To understand the proposed solution to this problem, consider the following scenario: anand et al [page 3] Integrated transition toolbox for 3gpp cases +----+ |GPRS| +---------+ +------+ |Core|+------+ +-------+ | | | 'C' | +----+| | |name | | | | UE |-------| | |resolv.| | | | | | GGSN |-|------ | | | | IPv6 | | | |edge |--| | +----+ +------+ +------+ |router | | | |GPRS| +-------+ |IPv4 Net | +------+ |Core| +------+ | | | | +----+ | | | |--| |--------| 'B' | | | | GGSN | | | +------+ +------+ | | | | | IPv6 | | 'C' | | | | | +------+ +------+ | UE |-------| |-----------| | | |+----+ | GGSN | | | | IPv6 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ Figure 1: IPv6 nodes communicating over IPv4 UE 'C' (an IPV6 user equipment) wants to connect to 'B' (another IPV6 terminal). As mentioned in section 2, point (iv), 'B' will have two IP addresses registered in the DNS. One will be its own IPV6 address and the other will be address2 (IPV4) of the edge router of B's network. Now, 'C' being an IPV6 node generates a "AAAA" query for the IP address of B. Assuming that no name resolver/DNS server inside C's network is able to resolve this query, it is finally forwarded to a name resolver co-residing with the edge router of this network(similar to [NAT64], but this is where the similarity ends). This name resolver converts this "AAAA" query into a dual query ("A" + "AAAA")and forwards it into the IPV4 internet. Since a DNS server in the IPV4 net will have 2 entries for 'B', both the queries will be successfully resolved. In response to the "AAAA" query, the name resolver receives a "AAAA" response which it stores and waits for time 't' (which can be configured) for a "A" respose to arrive. On the arrival of the "A" response, the name resolver creates an entry in the 'M' table (see section 1), and sets the 'Tf'(Tunnel flag) to one (indicating that whenever a packet is to be sent to this destination, it will have to be tunneled). In order to make sure that only packets requiring tunneling or translation are handled by this router (to avoid excessive burden), this IPV6 address received as response will be mapped to another IPV6 address and this mapping will be maintained in the 'R' table. This new IPv6 address will have a anand et al [page 4] Integrated transition toolbox for 3gpp cases prefix ensuring that all packets destined to this particular IPV6 address are routed to this edge router only. After all these manipulations, the 'pre-fixed' IPV6 address will be sent to UE 'C' by the name resolver. Now, 'C' generates an IPV6 packet, with the source address as it's own IPV6 address and the destination address as the 'pre-fixed' IPV6 address that it just received. Now, due to the 'pre-fixed' IPV6 address as the destination address, this packet will be automatically routed to the ITT edge router. Here, the IPV6 destination address will be first replaced by the actual IPV6 address from the 'R' table. Since, the Tunnel Flag for this address is set, ITT understands that this packet must be tunneled to the actual destination. In order to do this, the 'M' table is scanned for an entry. Once the corresponding IPV4 address has been found, this IPV6 packet will be encapsulated inside an IPV4 packet, using the IPV4 address found as the destination address. The source address will be the address2 of this edge router and the protocol bit will be set to one. This packet is finally received by the edge router on B's network. Once the protocol bit is detected to be 41, the ITT understands that tunneling has been done. Now, the ITT maps the IPV4 source address in the outer packet to the IPV6 source address in the encapsulated packet and creates this entry in it's 'M' table and also sets the corresponding Tunnel Flag to one. Now, the IPV4 header is stripped off and discarded. In the IPV6 header the source address is replaced by a 'pre-fixed' IPV6 address as explained before. Now, this packet is finally forwarded to 'B'. 'B' can respond to this packet using the same mechanism. This mechanism intends to do the following without actually introducing any new transition mechanism: 1)Automatically configure edge routers to implement configured tunneling. 2)Make sure that load is shared and specific routers handle tunneling. 3)Eliminate unnecessary translation/tunneling. 3.2) Dual Stack UE connecting to IPv4 and IPv6 nodes As discussed in [3gpp-analysis], this scenario is likely to arise in the near future as more and more IPV6-only as well as dual stack nodes are deployed. Though this scenario sounds very simple, some exceptionally complicated cases may arise, which will lead to unnecessary translation/tunneling. These scenarios or rather sub-scenarios can be: i) IPV4 application on dual stack node wants to contact IPV6 node ii) IPV4 application on dual stack node wants to contact IPV4 node anand et al [page 5] Integrated transition toolbox for 3gpp cases iii) IPV4 application on dual stack node wants to contact IPV4 application on another dual stack node iv) IPV6 application on dual stack node wants to contact IPV4 node v) IPV6 application on dual stack node wants to contact IPV6 node etc. For e.g consider the following scenario: +-------------+ +-------------------+ | | |+---------+ | | UE 'C' | || IPv4 Net| +--+---+ | | |+---------+ | IPv4 | | | | | | |------|------+ | +------+ | IPv6 | IPv4 | +----+---+ +--------+ +-------------+ IPv4 | | |IPv4 Net| +------+ | |------------------------| | +--------+ | | | | |------------|Dual | | IPv6 | GGSN | |Stack | |-------------------------------| | +------+ +-----------+ | | | GPRS Core | | | +------+ +-----------+ +----+---+ | IPv6 | | | | Figure 2: Dual-Stack Case | +--+---+ | +---------+ | | | IPv4 Net| | | +---------+ | +------------------+ If an IPV4 application residing on UE 'C' wants to communicate with another IPV4 application residing on 'B'(which is an IPV4 only node), it generates a "A" query asking for the IPV4 address. As explained before, this query is converted into a dual query by the name resolver coresiding with the edge router. Since 'B' is IPV4, only the "A" query will be resolved.Upon receiving this response, the name server will buffer it and wait for time 't' for a "AAAA" response to arrive. Since the "AAAA" response never arrives, the Tunnel Flag is not set to one, neither is the response translated to a 'pre-fixed' IP address. Consequently the response is forwarded as such to 'C'. 'C' can now activate an IPV4 PDP context and generate an IP packet with the destination address that it just received. Since the destination address of this packet does not have a 'pre-fixed' address, this packet will not be handled by the ITT edge router. Normal communication between 'C' and 'B' will now ensue. anand et al [page 6] Integrated transition toolbox for 3gpp cases The most complicated scenario that may occur under this case is when an IPV4 application on a dual stack node wants to contact an IPV4 application on another dual stack node. Though this case can be handled easily by the ITT mechanism described so far. But in that case this case will be treated as if the destination were an IPV6 node, leading to unnecessary translation. Whereas ITT should not be used at all here since the source, intermediate infrastructure(the internet) and the destination, all are IPV4 based. But, as specified in assumption (v) in section 2, it can be safely assumed that a dual stack node under normal circumstances, will be attached to its GGSN using an IPv6 PDP conext. So, this case reduces to - An IPv4 node connecting to an IPv6 node over the IPv4 internet and this scenario is discussed later on in this section. 3.3) IPv6 UE connecting to an IPv4 node Since any operator who migrates to IPv6 will definitely want to maintain connectivity with the IPv4 internet,this is a scenario of primary concern. 'Itt' helps to seamlessly integrate an IPv6 island into the IPv4 ocean. Consider the following scenario: +----+ |GPRS| +---------+ +------+ |Core|+------+ +-------+ | | | 'C' | +----+| | |name | | | | UE |-------| | |resolv.| | | | | | GGSN |-|------ | | | | IPv6 | | | |edge |--| | +----+ +------+ +------+ |router | | | |GPRS| +-------+ |IPv4 Net | +------+ |Core| +------+ | | | | +----+ | | | |--| |--------| 'B' | | | | GGSN | | | +------+ +------+ | | | | | IPv4 | | 'C' | | | | | +------+ +------+ | UE |-------| |-----------| | | |+----+ | GGSN | | | | IPv6 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ Figure 3: IPv6 UE connecting to an IPv4 node UE 'C' (an IPV6 user equipment) wants to connect to 'B' (an IPV4 terminal). Now, 'C' being an IPV6 node generates a "AAAA" query for the IP address of B. Assuming that no name resolver/DNS server anand et al [page 7] Integrated transition toolbox for 3gpp cases inside C's network is able to resolve this query, it is finally forwarded to a name resolver co-residing with the edge router of this network.This name resolver converts this "AAAA" query into a dual query ("A" + "AAAA")and forwards it into the IPV4 internet. Being an IPv4 only node, 'B' will have only an "A" entry registered with the DNS. Consequently, the name resolver (at the edge of C's network) receives only an "A" reply. Now, since the original query was of type "AAAA", the name resolver maps the received "A" response to a 'pre-fixed' "AAAA" address in it's 'M' table and forwards the "AAAA" response to 'C'. Now, 'C' generates a normal IPv6 packet with the destination address as the 'pre-fixed' IPv6 address that it received from the name resolver as a response to it's query. Since the destination address is 'pre-fixed', this packet is automatically picked up by the edge router colocated with the ITT. As per standard procedure, ITT scans the 'R' table for an entry corresponding to the destination address of the packet. Since no entry is found (unlike scenario 2, where an entry was found), it deduces the packet requires translation (tunneling would have been required if an entry would have been found in the 'R' table or if Tunnel flag would have been set to one). Now, using standard NAT-PT/NAPT-PT procedure the source address is translated to an IPv4 address and the destination address is translated to an IPv4 address using the 'M' table. On the other end edge router of B's network does not have to manipulate this packet in any way and this packet can be forwarded as such to 'B'. Translation of incoming packets for C's network will be done in a way that can be deduced easily and will not be discussed here. 3.4) IPv4 UE connecting to an IPv6 node Since operators and vendors who chose to stick to IPv4 for any reason, should also be able to initiate communication with IPv6 networks, this scenario becomes just as important. Consider the following scenario: +----+ |GPRS| +---------+ +------+ |Core|+------+ +-------+ | | | 'C' | +----+| | |name | | | | UE |-------| | |resolv.| | | | | | GGSN |-|------ | | | | IPv4 | | | |edge |--| | +----+ +------+ +------+ |router | | | |GPRS| +-------+ |IPv4 Net | +------+ |Core| +------+ | | | | +----+ | | | |--| |--------| 'B' | | | | GGSN | | | +------+ +------+ | | | | | IPv6 | | 'C' | | | | | +------+ +------+ | UE |-------| |-----------| | | |+----+ | GGSN | | | | IPv4 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ Figure 4: IPv4 UE connecting to an IPv6 node anand et al [page 8] Integrated transition toolbox for 3gpp cases UE 'C' (an IPV4 user equipment) wants to connect to 'B' (an IPv6 terminal). Now, 'C' being an IPV4 node generates a "A" query for the IP address of B. Assuming that no name resolver/DNS server inside C's network is able to resolve this query, it is finally forwarded to a name resolver co-residing with the edge router of this network.This name resolver converts this "A" query into a dual query ("A" + "AAAA")and forwards it into the IPV4 internet.'B' being an IPv6 node will have two entries in the DNS (address1 and address2). Consequently, both queries ("AAAA"and "A") will be successfully resolved. The name resolver gets one of the replies ahead of the other(say the "A" reply). It waits a for time-period 't' for another reply to arrive. In this case a "AAAA" reply also arrives. The ITT immediately understands that the destination is either a Dual-stack node or an IPv6 node. Though it has no way of being sure about the exact nature of the destination (unless ofcourse IANA assigns a special prefix for address2 type of addresses, which in fact is highly recommended). The ITT can safely assume that even if the destination is dual-stack, it has its IPv6 PDP context enabled (refer assumption (V), SECTION 2). In either case the name resolver maps the IPv4 address to the IPv6 address in its 'M' table and a 'pre-fixed' address is forwarded to 'C' after updating the 'R' table. Now, 'C' can create normal IPv4 packets using this IPv4 address. The packets that 'C' creates for 'B' are automatically routed to the ITT because of the 'pre-fixed' destination address. Since the Tunnel Flag was not set to one, the ITT will not resort to tunneling, instead, the destination address will be rectified using the 'R' table and the IPv4 header will then be translated to IPv6 header. The destination IPv6 address can be obtained from the 'M' table and source address can be obtained by standard NA(P)-PT[3] procedure. When this packet is received at the edge router of B's network, it will be forwarded as such to the actual destination ('B') if it has its IPv6 PDP context activated or translated to IPv4 if it has its IPv4 PDP context enabled. Incidentally, this is the only case where the edge router (ITT) at the receiving end may have to do a little bit of translation. Authors Anand Thakur,HCL Perot Systems Ajay Jain,HCL Perot Systems Acknowledgements The authors would like to thank Mr. Pranshu Gupta and Mr.Pratap S. Ratra for good input, and comments that helped writing this document. anand et al [page 9] Integrated transition toolbox for 3gpp cases References [TRANS-SCENE]J. Soininen,"Transition Scenarios for 3GPP Networks", January 2003,draft-ietf-v6ops-3gpp-cases-02.txt [3gpp analysis] J.Wiljakka," [1] Wasserman, M. et al, "Recommendations for IPv6 in 3GPP Standards", January 2002, draft-ietf-ipv6-3gpp-recommend-00.txt. [2] 3GPP TS 23.060 v 5.2.0, "General Packet Radio Service (GPRS); Service description; Stage 2(Release 5)", June 2002. [3] G. Tsirtsis,P. Srisuresh,"Network Address Translation - Protocol Translation (NAT-PT)",February 2000,RfC: 2766 [NAT64]Alain Durand,"NAT64 - NAT46",June, 3, 2002 draft-durand-ngtrans-nat64-nat46-00.txt Author's address and contact number: Anand Thakur HCL Perot Systems Plot no.3 Sector-125 Noida -201301 Uttar-Pradesh e-mail : anand.thakur@hpsglobal.com India Please CC to: champ_anand@yahoo.com Ajay Jain Head,Telecom Software Delivery HCL Perot Systems Plot no.3 Sector-125 tel no. : +91 120 4588603 Noida -201301 e-mail : ajay.jain@hpsglobal.com Uttar-Pradesh India Document expires : August 2003 anand et al [page 10] Integrated transition toolbox for 3gpp cases