Anand Thakur Ajay Jain Head, Telecom Software Delivery HCL Perot Systems october 2002 Internet Draft Document: draft-thakur-v6ops-3gpp-cases-00.txt Expires: April 2003 Transition cases and their implementations for 3GPP Networks 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 various transition cases in Third GenerationPartnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition.The cases considered here have already been described in [TRANS-SCENE]. 1. Introduction This document will describe the transition cases and methods of anand et al [page 1] Transition cases and their implementations for 3GPP Networks practical implementating these cases. These cases might come up in the deployment phase of IPv6. This document gives neither an overview, nor an explanation of 3GPP or the 3GPP packet data network, GPRS. A good overview of the 3GPP specified GPRS can be found from [1]. The GPRS architecture specification is defined in [2]. 2. GPRS scenarios and their implementations This section describes the various transition cases [TRANS-SCENE] that might come up during the deployment phase of IPV6 and methods to implement them.This section also explains why some transition mechanisms may not be practical solutions in the GPRS scenario inspite of the fact that they may be good solutions in "non-mobile" cases i.e where transition is not required between mobile IPV6 and mobile IPV4. 2.1 Transition scenarios The following transition scenarios are more likely to come up during the deployment phase of IPV6, especially mobile IPV6. 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 2.2) Choice of transition mechanism Most of the transition mechanisms available today can be divided broadly into 2 categories, namely: 1) Translation methods 2) Tunneling methods A detailed analysis of these methods is beyond the scope of this document. In brief,translation mechanisms involve those methods in which the original header(IPV4 or IPV6) is stripped off and is substituted by a new header(IPV4 or IPV6). On the other hand tunneling mechanisms involve those methods in which the original IP header is retained and the entire datagram(including the IP header) is encapsulated within another IP header. As long as extension headers are not used in IPV6 headers,translation mechanisms like NAPT-PT [3] or SOCKS based geateways [4] may appear to be good solutions because one to one correspondence may be formed between the fields of an IPV6 header and an IPV4 header and anand et al. [Page 2] Transition cases and their implementations for 3GPP Networks translation may be done without loss of information.But when extension headers,like the destination options header and the mobility header [MOB-IPV6], are used then exact translation between an IPV6 header and IPV4 header may not be possible. Since [MOB-IPV6] proposes the use of mobility headers in the implementation of mobile IPV6 it becomes essential that this mobility header is retained even when the packet is passing through a largely IPV4 network. All these considerations lead to the conclusion that a tunneling mechanism would be best suited for such a purpose so that the original extension headers my be retained inside the encapsulating IPV4 header. The only exception may be the case where both the source and the destination nodes are IPV4 nodes. In such a case translation techniques may be employed, since all the information contained in an IPV4 header can be transmitted using an IPV6 header. 2.3) Implementation This section describes methods to implement the various transition cases. IMP : It is assumed in all the cases that the border router in all the links is a dual stack router. 1)Dual Stack UE connecting to IPv4 and IPv6 nodes +-------------+ +-------------------+ | | |+---------+ | | UE | || IPv4 Net| +--+---+ | | |+---------+ | IPv4 | | | | | | |------|------+ | +------+ | IPv6 | IPv4 | +----+---+ +-------------+ IPv4 | | | |------------------------| | | | | | IPv6 | GGSN | |-------------------------------| | +-----------+ | | | GPRS Core | | | +------+ +-----------+ +----+---+ | IPv6 | | | | Figure 1: Dual-Stack Case | +--+---+ | +---------+ | | | IPv4 Net| | | +---------+ | +------------------+ anand et al. [Page 3] Transition cases and their implementations for 3GPP Networks In this case the UE should, under normal circumstances behave as an IPV6 node, because due to the IPV4 address crunch a globally unique IPV4 address may not be available for it. So, the UE's IPV4 PDP context should be activated only when required. Alternately it could be assigned an IPV4 address from a private address space. Since with a particular correspondent node the dual stack UE will either behave like an IPV6 terminal or an IPV4 terminal, so these individual cases will be covered by two of the cases discussed later on in this section. 2) IPv6 UE connecting to an IPv6 node through an IPv4 network +----+ |GPRS| +---------+ +------+ |Core|+------+ | | | 'C' | +----+| | | | | UE |-------| |----| | | | Home | GGSN | | | | IPv6 | Link | | | | +----+ +------+ +------+ | | |GPRS| |IPv4 Net | +------+|Core| +------+ | | | |+----+ | | | |--| |---------| 'B' | Foreign | | | GGSN | | | +------+ Link +------+ | | | | | IPv6 | | 'C' | | | | | +------+ +------+ | UE |-------| | | | Correspondent | |+----+ | GGSN |----| | node | IPv6 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ Figure 2: IPv6 nodes communicating over IPv4 This scenario will be prevalent in the early stages of mobile IPV6 deployment. UE 'C' has moved from it's home link to the foreign link as shown in the figure above. At this point of time if 'C' wants to initiate a session with peer IPV6 node 'B',then it does so in the following manner : anand et al. [Page 4] Transition cases and their implementations for 3GPP Networks 'C' generates a "AAAA" query for the IPV6 address of 'B'. This query is converted to a dual query, i.e. a "A" and a "AAAA" query at the border router of C's foreign link by a DNS_ALG. This query will eventually be passed on to the DNS server on B's home link. A DNS_ALG residing on the border router of this link will detect that in response to a dual query a single "AAAA" response has been generated (since 'B' is an IPV6 only node).Now,this border router, along with the "AAAA" response also forwards a "A" response that it itself creates . This "A" response consists of an IP address of the router itself and a port number that this router will use to identify 'B'(similar to NATting). These two responses are eventually forwarded to the border router on C's foreign link. This router, knowing that the destination of this DNS response packet is an IPV6 node, forwards only the "AAAA" response to 'C', and itself maintains a table which maps the address in the "A" response and the address in the "AAAA" response. Now, 'C' creates an IPV6 packet with it's care-of-address as the source address and the IPV6 address, that it just received, as the destination address. This packet is intercepted at the border router of this link.Here, a NAT like application picks up the IPV4 address from it's table that corresponds to the IPV6 destination address of this packet. Using standard tunneling procedure this IPV6 packet is encapsulated inside an IPV4 header with the destination address as the IPV4 address picked from the table, source address as the router's own IPV4 address along with a port number to identify the actual source and finally the protocol bit is set equal to 41. This IPV4 packet is then routed through the IPV4 internet and finally reaches the border router of B's home link. Here, it is noticed that the IPV4 header has it's protocol field set equal to 41. No further attempt is made to process the remaining IPV4 fields. The IPV4 header is simply stripped off and the packet inside it treated as a normal IPV6 packet. This router also maintains a table in which it maintains a mapping of the IPV4 source address(from the encapsulating IPV4 header) and the IPV6 source address. It should be noticed here that though this concept is very similar to that of NATting, here the processing is reduced to a minimal because the IPV4 header is stripped off as soon as the protocol field is detected to be 41. When 'B' responds to this packet sent by 'C' it uses it's own IPV6 address as the source address and C's IPV6 address as the destination address. This IPV6 packet is encapsulated in an IPV4 packet at the border router using the same mechanism as explained above. 3) IPv4 UE connecting to an IPv4 node through an IPv6 network anand et al. [Page 5] Transition cases and their implementations for 3GPP Networks +----+ |GPRS| +---------+ +------+ |Core|+------+ | | | 'C' | +----+| | | | | UE |-------| |---| | | | Home | GGSN | | | | IPv4 | Link | | | | +----+ +------+ +------+ | | |GPRS| |IPv6 Net | +------+ |Core| +------+ | | | | +----+ | | | |--| |----------| 'B' | Foreign | | | GGSN | | | +------+ Link +------+ | | | | | IPv4 | | 'C' | | | | | +------+ +------+ | UE |-------| | | | Correspondent | |+----+ | GGSN |--| | node | IPv4 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ Figure 3: IPv4 nodes communicating over IPv6 This scenario will be prevalent in the distant future when most of the internet will be IPV6 based and small patches of IPV4 islands will still exist. Since all the information contained within an IPV4 header can be conveyed using an IPV6 header, a translation mechanism will be employed here. UE 'C' has moved from it's home link to the foreign link as shown in the figure above. At this point of time if 'C' wants to initiate a session with peer IPV4 node 'B',then it does so in the following manner : 'C' generates a "A" query for the IPV4 address of 'B'. This query is converted to a dual query, i.e. a "A" and a "AAAA" query at the border router of C's foreign link by a DNS_ALG. This query will eventually be passed on to the DNS server on B's home link. A DNS_ALG residing on the border router of this link will detect that in response to a dual query a single "A" response has been generated (since 'B' is an IPV4 only node).Now,this border router, along with the "A" response also forwards a "AAAA" response that it itself creates. This "AAAA" response consists of an IPV6 address that a NAT like program assigns to 'B' from it's address pool. The border router here also maintains a table in which it maintains a mapping of B's actual IPV4 address and the IPV6 address assigned from the address pool. This response is received by the border router at C's home link. This router forwards the "A" response to 'C' and maintains a table with a mapping of B's actual IPV4 address and the IPV6 address assigned from the address pool. 'C' now creates an IPV4 packet which is intercepted at it's border router where using standard translation procedure the IPV4 anand et al. [Page 6] Transition cases and their implementations for 3GPP Networks header will be replaced by an IPV6 header. In this IPV6 header the source IPV6 address will be assigned from an address pool maintained by a NAT application running on the router and the destination IPV6 address will be picked up from the table that the NAT has been maintaining. When 'B' responds to this packet a similar procedure will be employed. 4) IPv6 UE connecting to an IPv4 node +----+ |GPRS| +---------+ +------+ |Core|+------+ | | | 'C' | +----+| | | | | UE |-------| |---| | | | Home | GGSN | | | | IPv6 | Link | | | | +----+ +------+ +------+ | | |GPRS| |IPv4 Net | +------+ |Core| +------+ | | | | +----+ | | | |--| |----------| 'B' | Foreign | | | GGSN | | | +------+ Link +------+ | | | | | IPv4 | | 'C' | | | | | +------+ +------+ | UE |-------| | | | Correspondent | |+----+ | GGSN |--| | node | IPv6 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ UE 'C' has moved from it's home link to the foreign link as shown in the figure above. At this point of time if 'C' wants to initiate a session with peer IPV4 node 'B',then it does so in the following manner : 'C' generates a "AAAA" query for the IPV6 address of 'B'. This query is converted to a dual query, i.e. a "A" and a "AAAA" query at the border router of C's foreign link by a DNS_ALG. This query will eventually be passed on to the DNS server on B's home link. A DNS_ALG residing on the border router of this link will detect that in response to a dual query a single "A" response has been generated (since 'B' is an IPV4 only node).Now,this border router, along with the "A" response also forwards a "AAAA" response that it itself creates. This "AAAA" response consists of an IPV6 address that a NAT like program assigns to 'B' from it's address pool. The border router here also maintains a table in which it maintains a mapping of B's actual IPV4 address and the IPV6 address assigned from the address pool. This response is received by the border router at C's home link. This router forwards the "AAAA" response to 'C' and maintains a table with a mapping of B's anand et al. [Page 7] Transition cases and their implementations for 3GPP Networks actual IPV4 address and the IPV6 address assigned from the address pool. At this point it must be understood that though 'C' has an IPV6 destination address, 'B' is actually an IPV4 node and is incapable of interpretting any mobile IPV6 information (home address destination option or binding updates) that 'C' may attempt to send. Also, since 'B' is mobile IPV4 enabled it must have a permanent address, namely C's home address to communicate with 'C'.So, the border router on C's foreign link must 'instruct' C to do the following : i) Not to send binding updates to 'B' ii) Not to use the home address destination option iii) To send packets to 'B' using reverse tunneling. The method employed to accomplish this is beyond the scope of this document. 5) IPv4 UE connecting to an IPv6 node +----+ |GPRS| +---------+ +------+ |Core|+------+ | | | 'C' | +----+| | | | | UE |-------| |---| | | | Home | GGSN | | | | IPv4 | Link | | | | +----+ +------+ +------+ | | |GPRS| |IPv4 Net | +------+ |Core|+------+ | | | | +----+| | | |--| |-------| 'B' | Foreign | | | GGSN | | | +------+ Link +------+ | | | | | IPv6 | | 'C' | | | | | +------+ +------+ | UE |-------| | | | Correspondent | |+----+ | GGSN |--| | node | IPv4 ||GPRS| | | | | +------+|Core| +------+ +---------+ +----+ UE 'C' has moved from it's home link to the foreign link as shown in the figure above. At this point of time if 'C' wants to initiate a session with peer IPV6 node 'B',then it does so in the following manner : 'C' generates a "A" query for the IPV6 address of 'B'. This query is converted to a dual query, i.e. a "A" and a "AAAA" query at the border router of C's foreign link by a DNS_ALG. This query will eventually be passed on to the DNS server on B's home link. A DNS_ALG residing on the border router of this link will detect that in response to a dual query a single "AAAA" response has been anand et al. [Page 8] Transition cases and their implementations for 3GPP Networks generated (since 'B' is an IPV6 only node).Now,this border router, along with the "AAAA" response also forwards a "A" response that it itself creates . This "A" response consists of an IP address of the router itself and a port number that this router will use to identify 'B'. These two responses are eventually forwarded to the border router on C's foreign link. This router, knowing that the destination of this DNS response packet is an IPV4 node forwards only the "A" response to 'C', and itself maintains a table which contains a mapping of the address in the "A" response and the address in the "AAAA" response. Now, 'C' generates an IPV4 packet using it's own address as the source address and the IPV4 address from the "A" response as the destination address. This packet is again intercepted at the border router of B's home link/foreign link where translation is done. In the resulting IPV6 header the source address is a temporary IPV6 address that a NAT like program picks from it's address pool(the NAT also maintains a table which maps this IPV6 address to the corresponding IPV4 address) and the destination address is picked from the table entry which was created when it originally let the DNS response through. When 'B' responds it creates a normal IPV6 packet and translation is done at the border router. 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. References [TRANS-SCENE]J. Soininen,"Transition Scenarios for 3GPP Networks", March 2003,draft-soininen-v6ops-3gpp-cases-00.txt [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. anand et al. [Page 9] Transition cases and their implementations for 3GPP Networks [3] G. Tsirtsis,P. Srisuresh,"Network Address Translation - Protocol Translation (NAT-PT)",February 2000,RfC: 2766 [4] H. Kitamura,"A SOCKS-based IPv6/IPv4 Gateway Mechanism", April 2001,Request for Comments: 3089ko et al. [MOB-IPV6] Charles E. Perkins et al,"Mobility Support in IPv6", 1 June 2002,draft-ietf-mobileip-ipv6-18.txt Author's address and contact number: Anand Thakur HCL Perot Systems B-26 Sector-57 Noida -201301 Uttar-Pradesh e-mail : anand.thakur@hpsglobal.com India Ajay Jain Head,Telecom Software Delivery HCL Perot Systems B-26 Sector-57 tel no. : +91 120 4588603 Noida -201301 e-mail : ajay.jain@hpsglobal.com Uttar-Pradesh India Document expires : April 2003 anand et al. [Page 10] Transition cases and their implementations for 3GPP Networks