idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 936. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 93 has weird spacing: '... packet data ...' == Line 589 has weird spacing: '...opriate versi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2766' is mentioned on line 214, but not defined ** Obsolete undefined reference: RFC 2766 (Obsoleted by RFC 4966) == Missing Reference: 'NATPT-DNS' is mentioned on line 986, but not defined == Unused Reference: 'RFC2663' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 775, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 3574 ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-02 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3266 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-21 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-isp-scenarios-analysis-02 == Outdated reference: A later version (-07) exists of draft-ietf-rpsec-routing-threats-06 == Outdated reference: A later version (-03) exists of draft-savola-v6ops-security-overview-02 Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Wiljakka (ed.) 3 Document: draft-ietf-v6ops-3gpp-analysis-10.txt Nokia 4 Expires: November 2004 6 May 2004 8 Analysis on IPv6 Transition in 3GPP Networks 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance 15 with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document analyzes the transition to IPv6 in Third Generation 36 Partnership Project (3GPP) packet networks. These networks are 37 based on General Packet Radio Service (GPRS) technology, and the 38 radio network architecture is based on Global System for Mobile 39 Communications (GSM), or Universal Mobile Telecommunications System 40 (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology. 42 The focus is on analyzing different transition scenarios, 43 applicable transition mechanisms and finding solutions for those 44 transition scenarios. In these scenarios, the User Equipment (UE) 45 connects to other nodes, e.g. in the Internet, and IPv6/IPv4 46 transition mechanisms are needed. 48 Table of Contents 50 1. Introduction..................................................2 51 1.1 Scope of this Document....................................3 52 1.2 Abbreviations.............................................4 53 1.3 Terminology...............................................4 54 2. Transition Mechanisms and DNS Guidelines......................5 55 2.1 Dual Stack................................................5 56 2.2 Tunneling.................................................5 57 2.3 Protocol Translators......................................6 58 2.4 DNS Guidelines for IPv4/IPv6 Transition...................6 59 3. GPRS Transition Scenarios.....................................6 60 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........7 61 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 62 .............................................................8 63 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 64 ............................................................10 65 3.4 IPv6 UE Connecting to an IPv4 Node.......................10 66 3.5 IPv4 UE Connecting to an IPv6 Node.......................11 67 4. IMS Transition Scenarios.....................................12 68 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 69 4.2 Two IPv6 IMS Connected via an IPv4 Network...............14 70 5. About 3GPP UE IPv4/IPv6 Configuration........................14 71 6. Summary and Recommendations..................................15 72 7. Security Considerations......................................16 73 8. References...................................................16 74 8.1 Normative................................................16 75 8.2 Informative..............................................17 76 9. Contributors.................................................19 77 10. Authors and Acknowledgements................................19 78 11. Editor's Contact Information................................20 79 12. Intellectual Property Statement.............................20 80 13. Copyright...................................................20 81 Appendix A...................................................21 83 1. Introduction 85 This document describes and analyzes the process of transition to 86 IPv6 in Third Generation Partnership Project (3GPP) General Packet 87 Radio Service (GPRS) packet networks, in which the radio network 88 architecture is based on Global System for Mobile Communications 89 (GSM), or Universal Mobile Telecommunications System (UMTS) / 90 Wideband Code Division Multiple Access (WCDMA) technology. 92 This document analyzes the transition scenarios that may come up in 93 the deployment phase of IPv6 in 3GPP packet data networks. 95 The 3GPP network architecture is described in [RFC3314], and 96 relevant transition scenarios are documented in [RFC3574]. The 97 reader of this specification should be familiar with the material 98 presented in these documents. 100 The scenarios analyzed in this document are divided into two 101 categories: general-purpose packet service scenarios, referred to 102 as GPRS scenarios in this document, and IP Multimedia Subsystem 103 (IMS) scenarios, which include Session Initiation Protocol (SIP) 104 considerations. 106 GPRS scenarios are the following: 107 - Dual Stack UE connecting to IPv4 and IPv6 nodes 108 - IPv6 UE connecting to an IPv6 node through an IPv4 network 109 - IPv4 UE connecting to an IPv4 node through an IPv6 network 110 - IPv6 UE connecting to an IPv4 node 111 - IPv4 UE connecting to an IPv6 node 113 IMS scenarios are the following: 114 - UE connecting to a node in an IPv4 network through IMS 115 - Two IPv6 IMS connected via an IPv4 network 117 The focus is on analyzing different transition scenarios, 118 applicable transition mechanisms and finding solutions for those 119 transition scenarios. In the scenarios, the User Equipment (UE) 120 connects to nodes in other networks, e.g. in the Internet and 121 IPv6/IPv4 transition mechanisms are needed. 123 1.1 Scope of this Document 125 The scope of this document is to analyze the possible transition 126 scenarios in the 3GPP defined GPRS network where a UE connects to, 127 or is contacted from, another node on the Internet. The document 128 covers scenarios with and without the use of the SIP-based IP 129 Multimedia Core Network Subsystem (IMS). This document does not 130 focus on radio interface-specific issues; both 3GPP Second and 131 Third Generation radio network architectures (GSM, EDGE and 132 UMTS/WCDMA) will be covered by this analysis. 134 The 3GPP2 architecture is similar to 3GPP in many ways, but differs 135 in enough details that this document does not include these 136 variations in its analysis. 138 The transition mechanisms specified by the IETF Ngtrans and v6ops 139 Working Groups shall be used. This memo shall not specify any new 140 transition mechanisms, but only documents the need for new ones (if 141 appropriate). 143 1.2 Abbreviations 145 2G Second Generation Mobile Telecommunications, for 146 example GSM and GPRS technologies. 147 3G Third Generation Mobile Telecommunications, for example 148 UMTS technology. 149 3GPP Third Generation Partnership Project 150 ALG Application Level Gateway 151 APN Access Point Name. The APN is a logical name referring 152 to a GGSN and an external network. 153 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 154 DNS Domain Name System 155 GGSN Gateway GPRS Support Node (default router for 3GPP 156 User Equipment) 157 GPRS General Packet Radio Service 158 GSM Global System for Mobile Communications 159 HLR Home Location Register 160 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 161 IPv6-only part of the network 162 ISP Internet Service Provider 163 NAT Network Address Translator 164 NAPT-PT Network Address Port Translation - Protocol Translation 165 NAT-PT Network Address Translation - Protocol Translation 166 PCO-IE Protocol Configuration Options Information Element 167 PDP Packet Data Protocol 168 PPP Point-to-Point Protocol 169 SGSN Serving GPRS Support Node 170 SIIT Stateless IP/ICMP Translation Algorithm 171 SIP Session Initiation Protocol 172 UE User Equipment, for example a UMTS mobile handset 173 UMTS Universal Mobile Telecommunications System 174 WCDMA Wideband Code Division Multiple Access 176 1.3 Terminology 178 Some terms used in 3GPP transition scenarios and analysis documents 179 are briefly defined here. 181 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both 182 IPv4 and IPv6 stacks. It is capable of activating 183 both IPv4 and IPv6 Packet Data Protocol (PDP) 184 contexts. Dual stack UE may be capable of tunneling. 186 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 187 only capable of activating IPv6 PDP contexts. 189 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 190 only capable of activating IPv4 PDP contexts. 192 IPv4 node IPv4 node is here defined to be IPv4 capable node 193 the UE is communicating with. The IPv4 node can 194 be, for example, an application server or another 195 UE. 197 IPv6 node IPv6 node is here defined to be IPv6 capable node 198 the UE is communicating with. The IPv6 node can 199 be, for example, an application server or another 200 UE. 202 PDP Context Packet Data Protocol (PDP) Context is a connection 203 between the UE and the GGSN, over which the packets 204 are transferred. There are currently three PDP 205 Types: IPv4, IPv6 and PPP. 207 2. Transition Mechanisms and DNS Guidelines 209 This chapter briefly introduces these IETF IPv4/IPv6 transition 210 mechanisms: 212 - dual IPv4/IPv6 stack [RFC2893-bis] 213 - tunneling [RFC2893-bis] 214 - protocol translators [RFC 2766], [RFC2765] 216 In addition, DNS recommendations are given. The applicability of 217 different transition mechanisms to 3GPP networks is discussed in 218 chapters 3 and 4. 220 2.1 Dual Stack 222 The dual IPv4/IPv6 stack is specified in [RFC2893-bis]. If we 223 consider the 3GPP GPRS core network, dual stack implementation in 224 the Gateway GPRS Support Node (GGSN) enables support for IPv4 and 225 IPv6 PDP contexts. UEs with dual stack and public (global) IP 226 addresses can typically access both IPv4 and IPv6 services without 227 additional translators in the network. However, it is good to 228 remember that private IPv4 addresses and NATs have been used and 229 will be used in mobile networks. Public/global IP addresses are 230 also needed for peer-to-peer services: the node needs a 231 public/global IP address that is visible to other nodes. 233 2.2 Tunneling 235 Tunneling is a transition mechanism that requires dual IPv4/IPv6 236 stack functionality in the encapsulating and decapsulating nodes. 237 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 239 Tunneling can be static or dynamic. Static (configured) tunnels are 240 fixed IPv6 links over IPv4, and they are specified in [RFC2893- 241 bis]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 242 where the tunnel endpoints are not configured, i.e. the links are 243 created dynamically. 245 2.3 Protocol Translators 247 A translator can be defined as an intermediate component between a 248 native IPv4 node and a native IPv6 node to enable direct 249 communication between them without requiring any modifications to 250 the end nodes. 252 Header conversion is a translation mechanism. In header conversion, 253 IPv6 packet headers are converted to IPv4 packet headers, or vice 254 versa, and checksums are adjusted or recalculated if necessary. 255 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 256 using Stateless IP/ICMP Translation [RFC2765] is an example of such 257 a mechanism. 259 Translators may be needed in some cases when the communicating 260 nodes do not share the same IP version; in others, it may be 261 possible to avoid such communication altogether. Translation can 262 take place at the network layer (using NAT-like techniques), the 263 transport layer (using a TCP/UDP proxy) or the application layer 264 (using application relays). 266 2.4 DNS Guidelines for IPv4/IPv6 Transition 268 To avoid the DNS name space from fragmenting into parts where some 269 parts of DNS are only visible using IPv4 (or IPv6) transport, the 270 recommendation (as of this writing) is to always keep at least one 271 authoritative server IPv4-enabled, and to ensure that recursive DNS 272 servers support IPv4. See DNS IPv6 transport guidelines [DNStrans] 273 for more information. 275 3. GPRS Transition Scenarios 277 This section discusses the scenarios that might occur when a GPRS 278 UE contacts services or other nodes, e.g. a web server in the 279 Internet. 281 The following scenarios described by [RFC3574] are analyzed here. 282 In all of the scenarios, the UE is part of a network where there is 283 at least one router of the same IP version, i.e. the GGSN, and the 284 UE is connecting to a node in a different network. 286 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 287 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 288 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 289 4) IPv6 UE connecting to an IPv4 node 290 5) IPv4 UE connecting to an IPv6 node 292 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 294 In this scenario, the dual stack UE is capable of communicating 295 with both IPv4 and IPv6 nodes. 297 It is recommended to activate an IPv6 PDP context when 298 communicating with an IPv6 peer node and an IPv4 PDP context when 299 communicating with an IPv4 peer node. If the 3GPP network supports 300 both IPv4 and IPv6 PDP contexts, the UE activates the appropriate 301 PDP context depending on the type of application it has started or 302 depending on the address of the peer host it needs to communicate 303 with. The authors leave the PDP context activation policy to be 304 decided by UE implementers, application developers and operators. 305 One discussed possibility is to activate both IPv4 and IPv6 types 306 of PDP contexts in advance, because activation of a PDP context 307 usually takes some time. However, that probably isn't good usage of 308 network resources. Generally speaking, IPv6 PDP contexts should be 309 preferred even if that meant IPv6-in-IPv4 tunneling would be needed 310 in the network (see section 3.2 for more details). Note that this 311 is transparent to the UE. 313 Although the UE is dual-stack, the UE may find itself attached to a 314 3GPP network in which the Serving GPRS Support Node (SGSN), the 315 GGSN, and the Home Location Register (HLR) support IPv4 PDP 316 contexts, but do not support IPv6 PDP contexts. This may happen in 317 early phases of IPv6 deployment, or because the UE has "roamed" 318 from a 3GPP network that supports IPv6 to one that does not. If the 319 3GPP network does not support IPv6 PDP contexts, and an application 320 on the UE needs to communicate with an IPv6(-only) node, the UE may 321 activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 322 packets using a tunneling mechanism. 324 The tunneling mechanism may require public IPv4 addresses, but 325 there are tunneling mechanisms and deployment scenarios in which 326 private IPv4 addresses may be used; for instance, if the tunnel 327 endpoints are in the same private domain, or the tunneling 328 mechanism works through IPv4 NAT. 330 One deployment scenario uses a laptop computer and a 3GPP UE as a 331 modem. IPv6 packets are encapsulated in IPv4 packets in the laptop 332 computer and an IPv4 PDP context is activated. The tunneling 333 mechanism depends on the laptop computer�s support of tunneling 334 mechanisms. Another deployment scenario is performing IPv6-in-IPv4 335 tunneling in the UE itself and activating an IPv4 PDP context. 337 Closer details for an applicable tunneling mechanism are not 338 analyzed in this document. However, a simple host-to-router 339 (automatic) tunneling mechanism may be a good fit. There is not yet 340 consensus on the right approach, and proposed mechanisms so far 341 include [ISATAP] and [STEP]. Especially ISATAP has had some support 342 in the wg. However, further work is needed to find out the 343 requirements for the scenario and to specify the mechanism. 345 This document strongly recommends the 3GPP operators to deploy 346 basic IPv6 support in their GPRS networks. That makes it possible 347 to lessen the transition effects in the UEs. 349 As a general guideline, IPv6 communication is preferred to IPv4 350 communication going through IPv4 NATs to the same dual stack peer 351 node. 353 Public IPv4 addresses are often a scarce resource for the operator 354 and usually it is not possible for a UE to have a public IPv4 355 address (continuously) allocated for its use. Use of private IPv4 356 addresses means use of NATs when communicating with a peer node 357 outside the operator's network. In large networks, NAT systems can 358 become very complex, expensive and difficult to maintain. 360 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 362 The best solution for this scenario is obtained with tunneling, 363 i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context 364 is activated between the UE and the GGSN. Tunneling is handled in 365 the network, because IPv6 UE does not have the dual stack 366 functionality needed for tunneling. The encapsulating node can be 367 the GGSN, the edge router between the border of the operator's IPv6 368 network and the public Internet, or any other dual stack node 369 within the operator's IP network. The encapsulation (uplink) and 370 decapsulation (downlink) can be handled by the same network 371 element. Typically the tunneling handled by the network elements is 372 transparent to the UEs and IP traffic looks like native IPv6 373 traffic to them. For the applications and transport protocols, 374 tunneling enables end-to-end IPv6 connectivity. 376 IPv6-in-IPv4 tunnels between IPv6 islands can be either static or 377 dynamic. The selection of the type of tunneling mechanism is a 378 policy decision for the operator / ISP deployment scenario and only 379 generic recommendations can be given in this document. 381 The following subsections are focused on the usage of different 382 tunneling mechanisms when the peer node is in the operator's 383 network or outside the operator's network. The authors note that 384 where the actual 3GPP network ends and which parts of the network 385 belong to the ISP(s) also depends on the deployment scenario. The 386 authors are not commenting how many ISP functions the 3GPP operator 387 should perform. However, many 3GPP operators are ISPs of some sort 388 themselves. ISP networks' transition to IPv6 is analyzed in [ISP- 389 sa]. 391 3.2.1 Tunneling inside the 3GPP Operator's Network 393 GPRS operators today have typically deployed IPv4 backbone 394 networks. IPv6 backbones can be considered quite rare in the first 395 phases of the transition. 397 In initial IPv6 deployment, where a small number of IPv6-in-IPv4 398 tunnels are required to connect the IPv6 islands over the 3GPP 399 operator's IPv4 network, manually configured tunnels can be used. 400 In a 3GPP network, one IPv6 island can contain the GGSN while 401 another island can contain the operator's IPv6 application servers. 402 However, manually configured tunnels can be an administrative 403 burden when the number of islands and therefore tunnels rises. In 404 that case, upgrading parts of the backbone to dual stack may be the 405 simplest choice. The administrative burden could also be mitigated 406 by using automated management tools. 408 Connection redundancy should also be noted as an important 409 requirement in 3GPP networks. Static tunnels alone don't provide a 410 routing recovery solution for all scenarios where an IPv6 route 411 goes down. However, they can provide an adequate solution depending 412 on the design of the network and the presence of other router 413 redundancy mechanisms, such as the use of IPv6 routing protocols. 415 3.2.2 Tunneling outside the 3GPP Operator's Network 417 This subsection includes the case in which the peer node is outside 418 the operator's network. In that case, IPv6-in-IPv4 tunneling can be 419 necessary to obtain IPv6 connectivity and reach other IPv6 nodes. 420 In general, configured tunneling can be recommended. 422 Tunnel starting point can be in the operator's network depending on 423 how far the 3GPP operator has come in implementing IPv6. If the 424 3GPP operator has not deployed IPv6 in its backbone, the 425 encapsulating node can be the GGSN. If the 3GPP operator has 426 deployed IPv6 in its backbone but the upstream ISP does not provide 427 IPv6 connectivity, the encapsulating node could be the 3GPP 428 operator's border router. 430 The case is pretty straightforward if the upstream ISP provides 431 IPv6 connectivity to the Internet and the operator's backbone 432 network supports IPv6. Then the 3GPP operator does not have to 433 configure any tunnels, since the upstream ISP will take care of 434 routing IPv6 packets. If the upstream ISP does not provide IPv6 435 connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from 436 the border router to a dual stack border gateway operated by 437 another ISP which is offering IPv6 connectivity. 439 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 441 3GPP networks are expected to support both IPv4 and IPv6 for a long 442 time, on the UE-GGSN link and between the GGSN and external 443 networks. For this scenario, it is useful to split the end-to-end 444 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 445 v4NODE. This allows an IPv4-only UE to use an IPv4 link (an IPv4 446 PDP context) to connect to the GGSN without communicating over an 447 IPv6 network. 449 Regarding the GGSN-to-v4NODE communication, typically the transport 450 network between the GGSN and external networks will support only 451 IPv4 in the early stages and migrate to dual stack, since these 452 networks are already deployed. Therefore it is not envisaged that 453 tunneling of IPv4-in-IPv6 will be required from the GGSN to 454 external IPv4 networks either. In the longer run, 3GPP operators 455 may choose to phase out IPv4 UEs and the IPv4 transport network. 456 This would leave only IPv6 UEs. 458 Therefore, overall, the transition scenario involving an IPv4 UE 459 communicating with an IPv4 peer through an IPv6 network is not 460 considered very likely in 3GPP networks. 462 3.4 IPv6 UE Connecting to an IPv4 Node 464 Generally speaking, IPv6-only UEs may be easier to manage, but that 465 would require all services to be used over IPv6, and the universal 466 deployment of IPv6 probably isn�t realistic in the near future. 467 Dual stack implementation requires management of both IPv4 and IPv6 468 networks and one approach is that "legacy" applications keep using 469 IPv4 for the foreseeable future and new applications requiring end- 470 to-end connectivity (for example, peer-to-peer services) use IPv6. 471 As a general guideline, IPv6-only UEs are not recommended in the 472 early phases of transition until the IPv6 deployment has become so 473 prevalent that direct communication with IPv4(-only) nodes will be 474 the exception, and not the rule. It is assumed that IPv4 will 475 remain useful for quite a long time, so in general, dual-stack 476 implementation in the UE can be recommended. This recommendation 477 naturally includes manufacturing dual-stack UEs instead of IPv4- 478 only UEs. 480 However, if there is a need to connect to an IPv4(-only) node from 481 an IPv6-only UE, it is recommended to use specific translation and 482 proxying techniques; generic IP protocol translation is not 483 recommended. There are three main ways for IPv6(-only) nodes to 484 communicate with IPv4(-only) nodes (excluding avoiding such 485 communication in the first place): 487 1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766]) 488 in the local network (not recommended as a general solution), 490 2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 491 TCP relay configured for a couple of ports only [RFC3142]) or 492 application proxies (e.g., HTTP proxy, SMTP relay) in the 493 local network, or 495 3. the use of specific-purpose mechanisms (as described above in 496 2) in the foreign network; these are indistinguishable from 497 the IPv6-enabled services from the IPv6 UE's perspective, and 498 not discussed further here. 500 For many applications, application proxies can be appropriate (e.g. 501 HTTP proxies, SMTP relays, etc.). Such application proxies will not 502 be transparent to the UE. Hence, a flexible mechanism with minimal 503 manual intervention should be used to configure these proxies on 504 IPv6 UEs. Application proxies can be placed, for example, on the 505 GGSN external interface ("Gi"), or inside the service network. 507 The authors note that [NATPTappl] discusses the applicability of 508 NAT-PT. The problems related to NAT-PT usage in 3GPP networks are 509 documented in appendix A. 511 3.5 IPv4 UE Connecting to an IPv6 Node 513 The legacy IPv4 nodes are typically nodes that support the 514 applications that are popular today in the IPv4 Internet: mostly e- 515 mail and web-browsing. These applications will, of course, be 516 supported in the future IPv6 Internet. However, the legacy IPv4 UEs 517 are not going to be updated to support future applications. As 518 these applications are designed for IPv6, and to use the advantages 519 of newer platforms, the legacy IPv4 nodes will not be able to take 520 advantage of them. Thus, they will continue to support legacy 521 services. 523 Taking the above into account, the traffic to and from the legacy 524 IPv4 UE is restricted to a few applications. These applications 525 already mostly rely on proxies or local servers to communicate 526 between private address space networks and the Internet. The same 527 methods and technology can be used for IPv4 to IPv6 transition. 529 4. IMS Transition Scenarios 531 As IMS is exclusively IPv6, the number of possible transition 532 scenarios is reduced dramatically. The possible IMS scenarios are 533 listed below and analyzed in sections 4.1 and 4.2. 535 1) UE connecting to a node in an IPv4 network through IMS 536 2) Two IPv6 IMS connected via an IPv4 network 538 For DNS recommendations, we refer to section 2.4. As DNS traffic is 539 not directly related to the IMS functionality, the recommendations 540 are not in contradiction with the IPv6-only nature of the IMS. 542 4.1 UE Connecting to a Node in an IPv4 Network through IMS 544 This scenario occurs when an IMS UE (IPv6) connects to a node in 545 the IPv4 Internet through the IMS, or vice versa. This happens when 546 the other node is a part of a different system than 3GPP, e.g. a 547 fixed PC, with only IPv4 capabilities. 549 Over time, users will upgrade the legacy IPv4 nodes to dual-stack, 550 often by replacing the entire node, eliminating this particular 551 problem in that specific deployment. 553 Still, it is difficult to estimate how many non-upgradeable legacy 554 IPv4 nodes need to communicate with the IMS UEs. It is assumed that 555 the solution described here is used for limited cases, in which 556 communications with a small number of legacy IPv4 SIP equipment are 557 needed. 559 As the IMS is exclusively IPv6 [3GPP 23.221], for many of the 560 applications in the IMS, some kind of translators may need to 561 be used in the communication between the IPv6 IMS and the legacy 562 IPv4 hosts in cases where these legacy IPv4 hosts cannot be 563 upgraded to support IPv6. 565 This section gives a brief analysis of the IMS interworking issues, 566 and presents a high level view of SIP within the IMS. The authors 567 recommend that a detailed solution for the general SIP/SDP/media 568 IPv4/IPv6 transition problem will be specified as soon as possible 569 as a task within the SIP WGs in the IETF. 571 As control (or signaling) and user (or data) traffic are separated 572 in SIP calls, and thus, the IMS, the transition of IMS traffic from 573 IPv6 to IPv4 must be handled at two levels: 575 1. Session Initiation Protocol (SIP) [RFC3261], and Session 576 Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface) 578 2. the user data traffic (Mb-interface) 580 SIP carries an SDP body containing the addressing and other 581 parameters for establishing the user data traffic (the media). 583 Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP 584 proxy at the border between the 3GPP IPv6-only IMS and the IPv4 585 systems. 587 In a possible approach, this edge could contain a SIP ALG, which 588 would change the IP addresses transported in the SIP messages and 589 the SDP payload of those messages to the appropriate version. This 590 approach would have the drawback (like other SDP rewriting 591 solutions) of impacting authentication mechanisms that may be 592 needed for other purposes. Moreover, this approach would not take 593 advantage of SIP's ability to use proxy routing, nor of SDP's 594 ability to carry multiple alternative addresses. These intrinsic 595 features of SIP and SDP require a more detailed analysis, but they 596 could yield benefits. The SIP ALG approach requires NAT-PT (with 597 the issues described in Appendix A), because the IMS-side IPv6 598 addresses must be assigned IPv4 addresses for reachability from the 599 legacy IPv4 side shown in Figure 1. The approach based on intrinsic 600 SIP proxy routing would not require assignment of temporary IPv4 601 addresses to the IPv6 IMS endpoints; instead they would be reached 602 via an IPv4-side address of a SIP proxy acting for them. This SIP 603 proxy would be doing normal SIP processing. 605 On the user data transport level, the analysis raises other issues: 606 the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol 607 translation (with the scalability concerns raised in Appendix A) 608 may look simplest, but needs a skeptical look. Alternatives include 609 routing to a transcoder, whose task is to terminate an IPv6 stream 610 and start an IPv4 stream. Again, this requires a more detailed 611 analysis. 613 For each of the protocols, there has to be interoperability for DNS 614 queries; see section 2.4 for details. 616 +-------------------------------+ +------------+ 617 | +------+ | | +--------+ | 618 | |S-CSCF|---| |SIP edge| |\ 619 | | +------+ | | +--------+ | \ -------- 620 +-|+ | / | | | | | | 621 | | | +------+ +------+ | | + | -| |- 622 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 623 | | +------+ +------+ | |+----------+| / ------ 624 | |-----------------------------------|| [ALG?] ||/ 625 +--+ | IPv6 | |+----------+| IPv4 626 UE | | |Interworking| 627 | IP Multimedia CN Subsystem | |Unit | 628 +-------------------------------+ +------------+ 630 Figure 1: UE using IMS to contact a legacy phone 632 Figure 1 shows a generic SIP signaling edge - an ALG-like 633 replacement of the IPv6 addresses with IPv4 addresses using limited 634 subsets of NAT-PT [RFC2766]. This is a possible approach, but 635 exploiting SIP's proxy routing to allow the dual homed SIP edge to 636 make the address change without a translator could be a promising 637 alternative without the scaling problems of NAT-PT. 639 4.2 Two IPv6 IMS Connected via an IPv4 Network 641 At the early stages of IMS deployment, there may be cases where two 642 IMS islands are separated by an IPv4 network such as the legacy 643 Internet. Here both the UEs and the IMS islands are IPv6-only. 644 However, the IPv6 islands are not connected natively with IPv6. 646 In this scenario, the end-to-end SIP connections are based on IPv6. 647 The only issue is to make connection between two IPv6-only IMS 648 islands over IPv4 network. This scenario is closely related to GPRS 649 scenario represented in section 3.2. and similar tunneling 650 solutions are applicable also in this scenario. 652 5. About 3GPP UE IPv4/IPv6 Configuration 654 This informative section aims to give a brief overview on the 655 configuration needed in the UE in order to access IP based 656 services. There can also be other application specific settings in 657 the UE that are not described here. 659 UE configuration is required in order to access IPv6 or IPv4 based 660 services. The GGSN Access Point has to be defined when using, for 661 example, the web browsing application. One possibility is to use 662 over the air configuration [OMA-CP] to configure the GPRS settings. 663 The user can, for example, visit the operator WWW page and 664 subscribe the GPRS Access Point settings to his/her UE and receive 665 the settings via Short Message Service (SMS). After the user has 666 accepted the settings and a PDP context has been activated, he/she 667 can start browsing. The Access Point settings can also be typed in 668 manually or be pre-configured by the operator or the UE 669 manufacturer. 671 DNS server addresses typically also need to be configured in the 672 UE. In the case of IPv4 type PDP context, the (IPv4) DNS server 673 addresses can be received in the PDP context activation (a control 674 plane mechanism). A similar mechanism is also available for IPv6: 675 so-called Protocol Configuration Options Information Element (PCO- 676 IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use 677 [RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server 678 addresses. Active IETF work on DNS discovery mechanisms is ongoing 679 and might result in other mechanisms becoming available over time. 680 The DNS server addresses can also be received over the air (using 681 SMS) [OMA-CP], or typed in manually in the UE. 683 When accessing IMS services, the UE needs to know the Proxy-Call 684 Session Control Function (P-CSCF) IPv6 address. Either a 3GPP- 685 specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736] 686 and [RFC3319]) can be used. Manual configuration or configuration 687 over the air is also possible. IMS subscriber authentication and 688 registration to the IMS and SIP integrity protection are not 689 discussed here. 691 6. Summary and Recommendations 693 This document has analyzed five GPRS and two IMS IPv6 transition 694 scenarios. Numerous 3GPP networks are using private IPv4 addresses 695 today, and introducing IPv6 is an important thing. The two first 696 GPRS scenarios and both IMS scenarios are seen the most relevant. 697 The authors summarize some main recommendations here: 698 - Dual-stack UEs are recommended instead of IPv4-only or IPv6- 699 only UEs. It is important to take care that the applications 700 in the UEs support IPv6. IPv6-only UEs can become feasible 701 when IPv6 is widely deployed in the networks, and most 702 services work on IPv6. 703 - It is recommended to activate an IPv6 PDP context when 704 communicating with an IPv6 peer node and an IPv4 PDP context 705 when communicating with an IPv4 peer node. 706 - IPv6 communication is preferred to IPv4 communication going 707 through IPv4 NATs to the same dual stack peer node. 708 - This document strongly recommends the 3GPP operators to deploy 709 basic IPv6 support in their GPRS networks as soon as possible. 710 That makes it possible to lessen the transition effects in the 711 UEs. 712 - A tunneling mechanism in the UE may be needed during the early 713 phases of the IPv6 transition process. A lightweight, 714 automatic tunneling mechanism should be standardized in the 715 IETF. 716 - Tunneling mechanisms can be used in 3GPP networks, and only 717 generic recommendations are given in this document. More 718 details can be found, for example, in [ISP-sa]. 719 - We recommend that a detailed solution for the general 720 SIP/SDP/media IPv4/IPv6 transition problem will be specified 721 as soon as possible as a task within the SIP WGs in the IETF. 723 7. Security Considerations 725 Deploying IPv6 has some generic security considerations one should 726 be aware of [V6SEC]; however, these are not specific to 3GPP 727 transition, and are therefore out of the scope of this memo. 729 This memo recommends the use of a relatively small number of 730 techniques. Each technique has its own security considerations, 731 including: 733 - native upstream access or tunneling by the 3GPP network 734 operator, 735 - use of routing protocols to ensure redundancy, 736 - use of locally-deployed specific-purpose protocol relays and 737 application proxies to reach IPv4(-only) nodes from IPv6-only 738 UEs, or 739 - a specific mechanism for SIP signalling and media translation 741 The threats of configured tunneling are described in [RFC2893-bis]. 742 Attacks against routing protocols are described in the respective 743 documents and in general in [ROUTESEC]. Threats related to 744 protocol relays have been described in [RFC3142]. The security 745 properties of SIP internetworking are to be specified when the 746 mechanism is specified. 748 In particular, this memo does not recommend the following technique 749 which has security issues, not further analyzed here: 751 - NAT-PT or other translator as a general-purpose transition 752 mechanism 754 8. References 756 8.1 Normative 758 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 759 Translator (NAT) Terminology and Considerations, August 1999. 761 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 762 (SIIT), February 2000. 764 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 765 - Protocol Translation (NAT-PT), February 2000. 767 [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, 768 June 2002. 770 [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP 771 Networks, August 2003. 773 [RFC3667] Bradner, S.: IETF Rights in Contributions, February 2004. 775 [RFC3668] Bradner, S.: Intellectual Property Rights in IETF 776 Technology, February 2004. 778 [RFC2893-bis] Nordmark, E. and Gilligan, R. E.: "Basic Transition 779 Mechanisms for IPv6 Hosts and Routers", January 2004, draft-ietf- 780 v6ops-mech-v2-02.txt, work in progress. 782 [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service 783 (GPRS); Service description; Stage 2 (Release 5)", December 2002. 785 [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements 786 (Release 5)", December 2002. 788 [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem 789 (IMS); Stage 2 (Release 5)", December 2002. 791 [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP 792 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 793 December 2002. 795 [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control 796 Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 798 8.2 Informative 800 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 801 Protocol, April 1998. 803 [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay 804 Translator, June 2001. 806 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 807 in Session Description Protocol (SDP), June 2002. 809 [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP 810 Standards, September 2002. 812 [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for 813 IPv6 (DHCPv6), July 2003. 815 [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration 816 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) 817 Servers, July 2003. 819 [RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6, 820 December 2003. 822 [RFC3736] Droms, R.: Stateless Dynamic Host Configuration Protocol 823 (DHCP) Service for IPv6, April 2004. 825 [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport 826 operational guidelines", March 2004, draft-ietf-dnsop-ipv6- 827 transport-guidelines-02.txt, work in progress. 829 [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.: 830 "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", April 831 2004, draft-ietf-ngtrans-isatap-21.txt, work in progress. 833 [ISP-sa] Lind, M., Ksinant, V., Park, D. and Baudot, A.: "Scenarios 834 and Analysis for Introducing IPv6 into ISP Networks", April 2004, 835 draft-ietf-v6ops-isp-scenarios-analysis-02.txt, work in progress. 837 [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S. 838 and Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati- 839 v6ops-natpt-applicability-00.txt, work in progress. 841 [ROUTESEC] Barbir, A., Murphy, S. and Yang, Y.: "Generic Threats to 842 Routing Protocols", April 2004, draft-ietf-rpsec-routing-threats- 843 06.txt, work in progress. 845 [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment 846 Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup- 847 02.txt, work in progress. 849 [V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security 850 Considerations", February 2004, draft-savola-v6ops-security- 851 overview-02.txt, work in progress. 853 [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 854 3 specification; Core network protocols; Stage 3 (Release 5)", June 855 2003. 857 [OMA-CP] OMA Client Provisioning: Provisioning Architecture 858 Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile 859 Alliance, 12-Nov-2002. 861 9. Contributors 863 Pekka Savola has contributed both text and his IPv6 experience to 864 this document. He has provided a large number of helpful comments 865 on the v6ops mailing list. Allison Mankin has contributed text for 866 IMS Scenario 1 (section 4.1). 868 10. Authors and Acknowledgements 870 This document is written by: 872 Alain Durand, Sun Microsystems 873 875 Karim El-Malki, Ericsson Radio Systems 876 878 Niall Richard Murphy, Enigma Consulting Limited 879 881 Hugh Shieh, AT&T Wireless 882 884 Jonne Soininen, Nokia 885 887 Hesham Soliman, Flarion 888 890 Margaret Wasserman, ThingMagic 891 893 Juha Wiljakka, Nokia 894 896 The authors would like to give special thanks to Spencer Dawkins 897 for proofreading. 899 The authors would like to thank Heikki Almay, Gabor Bajko, Ajay 900 Jain, Jarkko Jouppi, David Kessens, Ivan Laloux, Allison Mankin, 901 Jasminko Mulahusic, Janne Rinne, Andreas Schmid, Pedro Serna, Fred 902 Templin, Anand Thakur and Rod Van Meter for their valuable input. 904 11. Editor's Contact Information 906 Comments or questions regarding this document should be sent to the 907 v6ops mailing list or directly to the document editor: 909 Juha Wiljakka 910 Nokia 911 Visiokatu 3 Phone: +358 7180 48372 912 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com 914 12. Intellectual Property Statement 916 The IETF takes no position regarding the validity or scope of any 917 Intellectual Property Rights or other rights that might be claimed 918 to pertain to the implementation or use of the technology described 919 in this document or the extent to which any license under such 920 rights might or might not be available; nor does it represent that 921 it has made any independent effort to identify any such rights. 922 Information on the procedures with respect to rights in RFC 923 documents can be found in BCP 78 and BCP 79. 925 Copies of IPR disclosures made to the IETF Secretariat and any 926 assurances of licenses to be made available, or the result of an 927 attempt made to obtain a general license or permission for the use 928 of such proprietary rights by implementers or users of this 929 specification can be obtained from the IETF on-line IPR repository 930 at http://www.ietf.org/ipr. 932 The IETF invites any interested party to bring to its attention any 933 copyrights, patents or patent applications, or other proprietary 934 rights that may cover technology that may be required to implement 935 this standard. Please address the information to the IETF at ietf- 936 ipr@ietf.org. 938 13. Copyright 940 The following copyright notice is copied from [RFC3667], Section 941 5.4. It describes the applicable copyright for this document. 943 Copyright (C) The Internet Society (2004). This document is subject 944 to the rights, licenses and restrictions contained in BCP 78, and 945 except as set forth therein, the authors retain all their rights. 947 This document and the information contained herein are provided on 948 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 949 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 950 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 951 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 952 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 953 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 954 PARTICULAR PURPOSE. 956 Appendix A - On the Use of Generic Translators in the 3GPP Networks 958 This appendix lists mainly 3GPP-specific arguments about generic 959 translators, even though the use of generic translators is 960 discouraged. The section may be removed in future versions of the 961 memo. 963 Due to the significant lack of IPv4 addresses in some domains, port 964 multiplexing is likely to be a necessary feature for translators 965 (i.e. NAPT-PT). If NAPT-PT is used, it needs to be placed on the 966 GGSN external (Gi) interface, typically separate from the GGSN. 967 NAPT-PT can be installed, for example, on the edge of the 968 operator's network and the public Internet. NAPT-PT will intercept 969 DNS requests and other applications that include IP addresses in 970 their payloads, translate the IP header (and payload for some 971 applications if necessary) and forward packets through its IPv4 972 interface. 974 NAPT-PT introduces limitations that are expected to be magnified 975 within the 3GPP architecture. Some of these limitations are listed 976 below (notice that most of them are also relevant for IPv4 NAT). 977 [NATPTappl] discusses the applicability of NAT-PT in more detail. 979 1. NAPT-PT is a single point of failure for all ongoing 980 connections. 982 2. There are additional forwarding delays due to further 983 processing, when compared to normal IP forwarding. 985 3. There are problems with source address selection due to the 986 inclusion of a DNS ALG on the same node [NATPT-DNS]. 988 4. NAPT-PT does not work (without application level gateways) for 989 applications that embed IP addresses in their payload. 991 5. NAPT-PT breaks DNSSEC. 993 6. NAPT-PT does not scale very well in large networks. 995 3GPP networks are expected to handle a very large number of 996 subscribers on a single GGSN (default router). Each GGSN is 997 expected to handle hundreds of thousands of connections. 998 Furthermore, high reliability is expected for 3GPP networks. 999 Consequently, a single point of failure on the GGSN external 1000 interface would raise concerns on the overall network reliability. 1002 In addition, IPv6 users are expected to use delay-sensitive 1003 applications provided by IMS. Hence, there is a need to minimize 1004 forwarding delays within the IP backbone. Furthermore, due to the 1005 unprecedented number of connections handled by the default routers 1006 (GGSN) in 3GPP networks, a network design that forces traffic to go 1007 through a single node at the edge of the network (typical NAPT-PT 1008 configuration) is not likely to scale. Translation mechanisms 1009 should allow for multiple translators, for load sharing and 1010 redundancy purposes. 1012 To minimize the problems associated with NAPT-PT, the following 1013 actions can be recommended: 1015 1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to 1016 IPv4" case). 1018 2. Ensure (if possible) that NAPT-PT does not become a single 1019 point of failure. 1021 3. Allow for load sharing between different translators. That is, 1022 it should be possible for different connections to go through 1023 different translators. Note that load sharing alone does not 1024 prevent NAPT-PT from becoming a single point of failure.