IPv6 Transition Solutions for 3GPP Networks

Transcription

1 v6 Transition Solutions for 3GPP Networks draft-wiljakka-3gpp-ipv6-transition-00.txt Juha Wiljakka, Nokia on behalf of the 3GPP ngtrans design team 54 th IETF Meeting, Yokohama, Japan gpp_trans/ / juha.wiljakka@nokia.com

2 GPRS scenarios 1 and 2 1. Dual stack connecting to and v6 nodes PDP context v6 PDP context Operator mobile v6 The most extensive scenario. Dual stack : both stacks can be simultaneously active. Managing the address pool is a challenge. Use of private addresses means use of NATs that should be avoided. 2. v6 connecting to v6 node through an v6 PDP context Operator mobile 2 3gpp_trans/ / juha.wiljakka@nokia.com v6 in tunnel v6 Making the v6 in tunneling in the. Tunneling can be static or dynamic. Compare with 6bone.

3 GPRS scenarios 3 and 4 3. connecting to node through an v6 4. v6 connecting to an node v6 PDP context Operator PDP context mobile Operator mobile Translator v6 / Internet in v6 tunnel in v6 (static or dynamic) tunneling in the The scenario is not considered very likely in 3GPP s. Translation is needed, because the and the peer node do not share the same version. NAT-PT has certain problems, use of NAT64 will be analyzed. 3 3gpp_trans/ / juha.wiljakka@nokia.com

4 GPRS scenario 5 5. connecting to an v6 node Operator PDP context mobile Translator v6 Translation is needed, because the and the peer node do not share the same version. NAT-PT has certain problems, use of NAT46 will be analyzed. 4 3gpp_trans/ / juha.wiljakka@nokia.com

5 5 3gpp_trans/ / juha.wiljakka@nokia.com IMS scenarios 1 and 2 1. connecting to a node in an through IMS 2. Two IMS islands connected via an mobile Operator Operator mobile P-CSCF S-CSCF IMS (v6-only) IMS (v6-only) ALG Translator (Static) v6 in tunnel IMS (v6- only) has v6 connection to the IMS and from IMS to an node. Translation needed in two levels: S and SDP in an ALG User data traffic at level. This is a challenging case. Closely related to GPRS scenario 2. Connection of two v6-only IMS islands has to be made over. Compare with 6bone.

6 NA(P)T-PT issues NAT-PT has its limitations. Those include: NAT-PT is a single point of failure for all ongoing connections. Additional forwarding delays due to further processing, when compared to normal forwarding. Problems with source address selection due to the inclusion of a DNS ALG on the same node. Recommended actions: The separation of the DNS ALG from the NAT-PT node. Ensuring that NAT-PT does not become a single point of failure. Load sharing between different translators. A recent NAT64 - NAT46 (draft-durand-ngtrans-nat64-nat46-00.txt) might provide a solution. 6 3gpp_trans/ / juha.wiljakka@nokia.com

7 /v6 issues related to S IMS scenario 1 is challenging due to two levels of translation: S / SDP signalling User traffic In proposed solution, S ALG translates S traffic, and also coordinates user traffic translation. E.g. setting up the addresses in the user traffic translator. Solution to this scenario still needs some work. 7 3gpp_trans/ / juha.wiljakka@nokia.com

8 Initial recommendations Tunneling over the air interface should be avoided, i.e. "v6 in " tunneling should mainly be handled in the, not in the s. The / v6 interworking should be mainly handled in the, not in the s. Implementation of dual stack for the s is recommended, at least during the early phases of v6 transition. 8 3gpp_trans/ / juha.wiljakka@nokia.com

9 We are asking for your participation We appreciate comments and input from the people in the Ngtrans wg a lot. Please read the two documents and give comments on the ngtrans mailing list. Comments can also be sent directly to the document editor juha.wiljakka@nokia.com Can this draft become a WG draft? 9 3gpp_trans/ / juha.wiljakka@nokia.com