idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 (March 2004) is 7345 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: 'DHCPv6-SL' is mentioned on line 658, but not defined == Unused Reference: 'RFC2663' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'DHCP-SL' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'ISP-sa' is defined on line 782, 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) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 3574 -- 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) == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-ipv6-transport-guidelines-01 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-20 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-isp-scenarios-analysis-01 -- Unexpected draft version: The latest known version of draft-durand-v6ops-natpt-dns-alg-issues is -00, but you're referring to -01. Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 6 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-09.txt Nokia 4 Expires: September 2004 6 March 2004 8 Analysis on IPv6 Transition in 3GPP Networks 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document analyzes the transition to IPv6 in Third Generation 34 Partnership Project (3GPP) General Packet Radio Service (GPRS) 35 packet networks. The focus is on analyzing different transition 36 scenarios, applicable transition mechanisms and finding solutions 37 for those transition scenarios. In these scenarios, the User 38 Equipment (UE) connects to other nodes, e.g. in the Internet, and 39 IPv6/IPv4 transition mechanisms are needed. 41 Table of Contents 43 1. Introduction..................................................2 44 1.1 Scope of this Document....................................3 45 1.2 Abbreviations.............................................3 46 1.3 Terminology...............................................4 47 2. Transition Mechanisms and DNS Guidelines......................5 48 2.1 Dual Stack................................................5 49 2.2 Tunneling.................................................5 50 2.3 Protocol Translators......................................5 51 2.4 DNS Guidelines for IPv4/IPv6 Transition...................6 52 3. GPRS Transition Scenarios.....................................6 53 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes...........6 54 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 55 ..............................................................8 56 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 57 .............................................................10 58 3.4 IPv6 UE Connecting to an IPv4 Node.......................10 59 3.5 IPv4 UE Connecting to an IPv6 Node.......................11 60 4. IMS Transition Scenarios.....................................12 61 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 62 4.2 Two IMS Islands Connected over IPv4 Network..............14 63 5. About 3GPP UE IPv4/IPv6 Configuration........................14 64 6. Security Considerations......................................15 65 7. References...................................................16 66 7.1 Normative................................................16 67 7.2 Informative..............................................16 68 8. Contributors.................................................18 69 9. Authors and Acknowledgements.................................18 70 10. Editor's Contact Information................................19 71 11. Intellectual Property Statement.............................19 72 12. Copyright...................................................19 73 Appendix A...................................................20 75 1. Introduction 77 This document describes and analyzes the process of transition to 78 IPv6 in Third Generation Partnership Project (3GPP) General Packet 79 Radio Service (GPRS) packet networks. The authors can be found in 80 Authors and Acknowledgements section. 82 This document analyzes the transition scenarios in 3GPP packet 83 data networks that might come up in the deployment phase of IPv6. 85 The transition scenarios are documented in [RFC3574] and this 86 document will further analyze them. The scenarios are divided into 87 two categories: GPRS scenarios and IP Multimedia Subsystem (IMS) 88 scenarios. 90 GPRS scenarios are the following: 91 - Dual Stack UE connecting to IPv4 and IPv6 nodes 92 - IPv6 UE connecting to an IPv6 node through an IPv4 network 93 - IPv4 UE connecting to an IPv4 node through an IPv6 network 94 - IPv6 UE connecting to an IPv4 node 95 - IPv4 UE connecting to an IPv6 node 97 IMS scenarios are the following: 98 - UE connecting to a node in an IPv4 network through IMS 99 - Two IMS islands connected via IPv4 network 101 The focus is on analyzing different transition scenarios, 102 applicable transition mechanisms and finding solutions for those 103 transition scenarios. In the scenarios, the User Equipment (UE) 104 connects to nodes in other networks, e.g. in the Internet and 105 IPv6/IPv4 transition mechanisms are needed. 107 1.1 Scope of this Document 109 The scope of this Best Current Practices document is to analyze and 110 solve the possible transition scenarios in the 3GPP defined GPRS 111 network where a UE connects to, or is contacted from, the Internet 112 or another UE. The document covers scenarios with and without the 113 use of the SIP based IP Multimedia Core Network Subsystem (IMS). 114 This document does not focus on radio interface issues; both 3GPP 115 Second (GSM) and Third Generation (UMTS) radio network 116 architectures will be covered by these scenarios. 118 The transition mechanisms specified by the IETF Ngtrans and v6ops 119 Working Groups shall be used. This document shall not specify any 120 new transition mechanisms, but if a need for a new mechanism is 121 found, that will be reported to the IETF v6ops Working Group. 123 1.2 Abbreviations 125 2G Second Generation Mobile Telecommunications, for 126 example GSM and GPRS technologies. 127 3G Third Generation Mobile Telecommunications, for example 128 UMTS technology. 129 3GPP Third Generation Partnership Project 130 ALG Application Level Gateway 131 APN Access Point Name. The APN is a logical name referring 132 to a GGSN and an external network. 133 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 134 DNS Domain Name System 135 GGSN Gateway GPRS Support Node (a default router for 3GPP 136 User Equipment) 137 GPRS General Packet Radio Service 138 GSM Global System for Mobile Communications 139 HLR Home Location Register 140 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 141 IPv6-only part of the network 142 ISP Internet Service Provider 143 NAT Network Address Translator 144 NAPT-PT Network Address Port Translation - Protocol Translation 145 NAT-PT Network Address Translation - Protocol Translation 146 PCO-IE Protocol Configuration Options Information Element 147 PDP Packet Data Protocol 148 PPP Point-to-Point Protocol 149 SGSN Serving GPRS Support Node 150 SIIT Stateless IP/ICMP Translation Algorithm 151 SIP Session Initiation Protocol 152 UE User Equipment, for example a UMTS mobile handset 153 UMTS Universal Mobile Telecommunications System 155 1.3 Terminology 157 Some terms used in 3GPP transition scenarios and analysis documents 158 are briefly defined here. 160 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both 161 IPv4 and IPv6 stacks. It is capable of activating 162 both IPv4 and IPv6 Packet Data Protocol (PDP) 163 contexts. Dual stack UE may be capable of tunneling. 165 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 166 only capable of activating IPv6 PDP contexts. 168 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 169 only capable of activating IPv4 PDP contexts. 171 IPv4 node IPv4 node is here defined to be IPv4 capable node 172 the UE is communicating with. The IPv4 node can 173 be, for example, an application server or another 174 UE. 176 IPv6 node IPv6 node is here defined to be IPv6 capable node 177 the UE is communicating with. The IPv6 node can 178 be, for example, an application server or another 179 UE. 181 2. Transition Mechanisms and DNS Guidelines 183 This chapter briefly introduces some transition mechanisms 184 specified by the IETF. In addition to that, DNS recommendations are 185 given. The applicability of different transition mechanisms to 3GPP 186 networks is discussed in chapters 3 and 4. 188 The IPv4/IPv6 transition methods can be divided to: 190 - dual IPv4/IPv6 stack 191 - tunneling 192 - protocol translators 194 2.1 Dual Stack 196 The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider 197 the 3GPP GPRS core network, dual stack implementation in the 198 Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 199 PDP contexts. UEs with dual stack and public (global) IP addresses 200 can typically access both IPv4 and IPv6 services without additional 201 translators in the network. However, it is good to remember that 202 private IPv4 addresses and NATs have been used and will be used in 203 mobile networks. Public/global IP addresses are also needed for 204 peer-to-peer services: the node needs a public/global IP address 205 that is visible to other nodes. 207 2.2 Tunneling 209 Tunneling is a transition mechanism that requires dual IPv4/IPv6 210 stack functionality in the encapsulating and decapsulating nodes. 211 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 213 Tunneling can be static or dynamic. Static (configured) tunnels are 214 fixed IPv6 links over IPv4, and they are specified in [RFC2893]. 215 Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where 216 the tunnel endpoints are not configured, i.e. the links are created 217 dynamically. 219 2.3 Protocol Translators 221 A translator can be defined as an intermediate component between a 222 native IPv4 node and a native IPv6 node to enable direct 223 communication between them without requiring any modifications to 224 the end nodes. 226 Header conversion is a translation mechanism. In header conversion, 227 IPv6 packet headers are converted to IPv4 packet headers, or vice 228 versa, and checksums are adjusted or recalculated if necessary. 230 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 231 using SIIT [RFC2765] is an example of such a mechanism. 233 Translators may be needed in some cases when the communicating 234 nodes do not share the same IP version; in others, it may be 235 possible to avoid such communication altogether. Translation can 236 actually happen at Layer 3 (using NAT-like techniques), Layer 4 237 (using a TCP/UDP proxy) or Layer 7 (using application relays). 239 2.4 DNS Guidelines for IPv4/IPv6 Transition 241 To avoid the DNS name space from fragmenting into parts where some 242 parts of DNS are only visible using IPv4 (or IPv6) transport, the 243 recommendation (as of this writing) is to always keep at least one 244 authoritative server IPv4-enabled, and to ensure that recursive DNS 245 servers support IPv4. See DNS IPv6 transport guidelines [DNStrans] 246 for more information. 248 3. GPRS Transition Scenarios 250 This section discusses the scenarios that might occur when a GPRS 251 UE contacts services or other nodes, e.g. a web server in the 252 Internet. 254 The following scenarios described by [RFC3574] are analyzed here. 255 In all of the scenarios, the UE is part of a network where there is 256 at least one router of the same IP version, i.e. the GGSN, and the 257 UE is connecting to a node in a different network. 259 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 260 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 261 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 262 4) IPv6 UE connecting to an IPv4 node 263 5) IPv4 UE connecting to an IPv6 node 265 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 267 In this scenario, the dual stack UE is capable of communicating 268 with both IPv4 and IPv6 nodes. It is recommended to activate an 269 IPv6 PDP context when communicating with an IPv6 peer node and an 270 IPv4 PDP context when communicating with an IPv4 peer node. If the 271 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE 272 activates the appropriate PDP context depending on the type of 273 application it has started or depending on the address of the peer 274 host it needs to communicate with. The authors leave the PDP 275 context activation policy to be decided by UE implementers, 276 application developers and operators. One discussed possibility is 277 to activate both IPv4 and IPv6 types of PDP contexts in advance, 278 because activation of a PDP context usually takes some time. 280 However, that probably isn't good usage of network resources. 281 Generally speaking, IPv6 PDP contexts should be preferred even if 282 that meant IPv6-in-IPv4 tunneling would be needed in the network 283 (see section 3.2 for more details). Note that this is transparent 284 to the UE. 286 However, the UE may attach to a 3GPP network, in which the Serving 287 GPRS Support Node (SGSN), the GGSN, and the Home Location Register 288 (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP 289 contexts. This may happen in early phases of IPv6 deployment. If 290 the 3GPP network does not support IPv6 PDP contexts, and an 291 application on the UE needs to communicate with an IPv6(-only) 292 node, the UE may activate an IPv4 PDP context and encapsulate IPv6 293 packets in IPv4 packets using a tunneling mechanism. 295 The used tunneling mechanism may require public IPv4 addresses, but 296 there are tunneling mechanisms and deployment scenarios in which 297 the usage of private IPv4 addresses is possible. If the tunnel 298 endpoints are in the same private domain, or the tunneling 299 mechanism works through IPv4 NAT, private IPv4 addresses can be 300 used. One deployment scenario example is using a laptop computer 301 and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 302 packets in the laptop computer and an IPv4 PDP context is 303 activated. The used tunneling mechanism in that case depends on the 304 support of tunneling mechanisms in the laptop computer. Another 305 deployment scenario is making IPv6-in-IPv4 tunneling in the UE 306 itself and activating an IPv4 PDP context. 308 Closer details for an applicable tunneling mechanism are not 309 analyzed in this document. However, a simple host-to-router 310 (automatic) tunneling mechanism may be a good fit. There is not yet 311 consensus on the right approach. Primarily, ISATAP [ISATAP] has 312 been proposed, but some issues have been raised about it, such as 313 its unnecessary features and relative complexity for a simple task 314 like this, and its inadequacy in providing security when crossing 315 administrative domains. Proposed solution alternatives have been 316 (at least) a simplified, but probably non-interoperable, version of 317 ISATAP, and STEP [STEP]. In any case, further work is needed to 318 find out the requirements for the scenario and to specify the 319 mechanism. 321 To generally solve this problem (IPv6 not available in the 3GPP 322 network), this document strongly recommends the 3GPP operators to 323 deploy basic IPv6 support in their GPRS networks. That also makes 324 it possible to burden the transition effects in the network and 325 make the 3GPP UEs simpler. 327 As a general guideline, IPv6 communication is preferred to IPv4 328 communication going through IPv4 NATs to the same dual stack peer 329 node. 331 Public IPv4 addresses are often a scarce resource for the operator 332 and typically it is not possible for a UE to have a public IPv4 333 address (continuously) allocated for its use. Use of private IPv4 334 addresses means use of NATs when communicating with a peer node 335 outside the operator's network. In large networks, NAT systems can 336 become very complex, expensive and difficult to maintain. 338 For DNS recommendations, we refer to section 2.4. 340 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 342 The best solution for this scenario is obtained with tunneling, 343 i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context 344 is activated between the UE and the GGSN. Tunneling is handled in 345 the network, because IPv6 UE is not capable of tunneling (it does 346 not have the dual stack functionality needed for tunneling). The 347 encapsulating node can be the GGSN, the edge router between the 348 border of the operator's IPv6 network and the public Internet, or 349 any other dual stack node within the operator's IP network. The 350 encapsulation (uplink) and decapsulation (downlink) can be handled 351 by the same network element. Typically the tunneling handled by the 352 network elements is transparent to the UEs and IP traffic looks 353 like native IPv6 traffic to them. For the applications, tunneling 354 enables end-to-end IPv6 connectivity. 356 IPv6-in-IPv4 tunnels between IPv6 islands can be either static or 357 dynamic. The selection of the type of tunneling mechanism is up to 358 the operator / ISP deployment scenario and only generic 359 recommendations can be given in this document. 361 The following subsections are focused on the usage of different 362 tunneling mechanisms when the peer node is in the operator's 363 network or outside the operator's network. The authors note that 364 where the actual 3GPP network ends and which parts of the network 365 belong to the ISP(s) also depends on the deployment scenario. The 366 authors are not commenting how many ISP functions the 3GPP operator 367 should perform. However, many 3GPP operators are ISPs of some sort 368 themselves. ISP networks' transition to IPv6 is analyzed in [ISP- 369 sa]. 371 3.2.1 Tunneling inside the 3GPP Operator's Network 373 GPRS operators today have typically deployed IPv4 backbone 374 networks. IPv6 backbones can be considered quite rare in the first 375 phases of the transition. 377 In initial IPv6 deployment, where a small number of IPv6-in-IPv4 378 tunnels are required to connect the IPv6 islands over the 3GPP 379 operator's IPv4 network, manually configured tunnels can be used. 380 In a 3GPP network, one IPv6 island can contain the GGSN while 381 another island can contain the operator's IPv6 application servers. 382 However, manually configured tunnels can be an administrative 383 burden when the number of islands and therefore tunnels rises. In 384 that case, upgrading parts of the backbone to dual stack may be the 385 simplest choice. The administrative burden could also be mitigated 386 by using automated management tools. 388 Connection redundancy should also be noted as an important 389 requirement in 3GPP networks. Static tunnels on their own don't 390 provide a routing recovery solution for all scenarios where an IPv6 391 route goes down. However, they can provide an adequate solution 392 depending on the design of the network and in presence of other 393 router redundancy mechanisms, such as the use of IPv6 routing 394 protocols. 396 3.2.2 Tunneling outside the 3GPP Operator's Network 398 This subsection includes the case in which the peer node is outside 399 the operator's network. In that case, IPv6-in-IPv4 tunneling can be 400 necessary to obtain IPv6 connectivity and reach other IPv6 nodes. 401 In general, configured tunneling can be recommended. 403 Tunnel starting point can be in the operator's network depending on 404 how far the 3GPP operator has come in implementing IPv6. If the 405 3GPP operator has not deployed IPv6 in its backbone, the 406 encapsulating node can be the GGSN. If the 3GPP operator has 407 deployed IPv6 in its backbone, but the upstream ISP does not 408 provide IPv6 connectivity to the Internet, the encapsulating node 409 can be the edge router. 411 The case is pretty straightforward if the upstream ISP provides 412 IPv6 connectivity to the Internet and the operator's backbone 413 network supports IPv6. Then the 3GPP operator does not have to 414 configure any tunnels, since the upstream ISP will take care of 415 routing IPv6 packets. If the upstream ISP does not provide IPv6 416 connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from 417 the edge router to a dual stack border gateway operated by another 418 ISP which is offering IPv6 connectivity. 420 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 422 3GPP networks are expected to support both IPv4 and IPv6 for a long 423 time, on the UE-GGSN link and between the GGSN and external 424 networks. For this scenario, it is useful to split the end-to-end 425 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 426 v4NODE. Therefore an IPv4-only UE will be able to use an IPv4 link 427 (PDP context) to connect to the GGSN without the need to 428 communicate over an IPv6 network. 430 Regarding the GGSN-to-v4NODE communication, typically the transport 431 network between the GGSN and external networks will support only 432 IPv4 in the early stages and migrate to dual stack, since these 433 networks are already deployed. Therefore it is not envisaged that 434 tunneling of IPv4-in-IPv6 will be required from the GGSN to 435 external IPv4 networks either. In the longer run, 3GPP operators 436 may need to phase out IPv4 UEs and the IPv4 transport network. This 437 would leave only IPv6 UEs. 439 Therefore, overall, the transition scenario involving an IPv4 UE 440 communicating with an IPv4 peer through an IPv6 network is not 441 considered very likely in 3GPP networks. 443 3.4 IPv6 UE Connecting to an IPv4 Node 445 Generally speaking, IPv6-only UEs may be easier to manage, but that 446 would require all services to be used over IPv6, and that may not 447 be realistic in the near future. Dual stack implementation requires 448 management of both IPv4 and IPv6 networks and one approach is that 449 "legacy" applications keep using IPv4 for the foreseeable future 450 and new applications requiring end-to-end connectivity (for 451 example, peer-to-peer services) use IPv6. As a general guideline, 452 IPv6-only UEs are not recommended in the early phases of transition 453 until the IPv6 deployment has become so prevalent that direct 454 communication with IPv4(-only) nodes will no longer be necessary. 455 It is assumed that IPv4 will remain useful for quite a long time, 456 so in general, dual-stack implementation in the UE can be 457 recommended. This recommendation naturally includes manufacturing 458 dual-stack UEs instead of IPv4-only UEs. 460 However, if there is a need to connect to an IPv4(-only) node from 461 an IPv6-only UE, it is possible to use specific translation and 462 proxying techniques; generic IP protocol translation is not 463 recommended. There are three main ways for IPv6(-only) nodes to 464 communicate with IPv4(-only) nodes (excluding avoiding such 465 communication in the first place): 467 1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766]) 468 in the local network (not recommended as a general solution), 470 2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 471 TCP relay configured for a couple of ports only [RFC3142]) or 472 application proxies (e.g., HTTP proxy, SMTP relay) in the 473 local network, or 475 3. the use of specific-purpose mechanisms (as described above in 476 2) in the foreign network; these are indistinguishable from 477 the IPv6-enabled services from the IPv6 UE's perspective, and 478 not discussed further here. 480 For many applications, application proxies can be appropriate (e.g. 481 HTTP proxies, SMTP relays, etc.). Such application proxies will not 482 be transparent to the UE. Hence, a flexible mechanism with minimal 483 manual intervention should be used to configure these proxies on 484 IPv6 UEs. Application proxies can be placed, for example, on the 485 GGSN external interface (Gi), or inside the service network. 487 The authors note that [NATPTappl] discusses the applicability of 488 NAT-PT. The problems related to NAT-PT usage in 3GPP networks are 489 documented in appendix A. 491 3.5 IPv4 UE Connecting to an IPv6 Node 493 The legacy IPv4 nodes are mostly nodes that support the 494 applications that are popular today in the IPv4 Internet: mostly e- 495 mail and web-browsing. These applications will, of course, be 496 supported in the future IPv6 Internet. However, the legacy IPv4 UEs 497 are not going to be updated to support the future applications. As 498 these applications are designed for IPv6, and to use the advantages 499 of newer platforms, the legacy IPv4 nodes will not be able to 500 profit from them. Thus, they will continue to support the legacy 501 services. 503 Taking the above into account, the traffic to and from the legacy 504 IPv4 UE is restricted to a few applications. These applications 505 already mostly rely on proxies or local servers to communicate 506 between private address space networks and the Internet. The same 507 methods and technology can be used for IPv4 to IPv6 transition. 509 For DNS recommendations, we refer to section 2.4. 511 4. IMS Transition Scenarios 513 As the IMS is exclusively IPv6, the number of possible transition 514 scenarios is reduced dramatically. The possible IMS scenarios are 515 listed below and analyzed in sections 4.1 and 4.2. 517 1) UE connecting to a node in an IPv4 network through IMS 518 2) Two IMS islands connected over IPv4 network 520 For DNS recommendations, we refer to section 2.4. As DNS traffic is 521 not directly related to the IMS functionality, the recommendations 522 are not in contradiction with the IPv6-only nature of the IMS. 524 4.1 UE Connecting to a Node in an IPv4 Network through IMS 526 This scenario occurs when an IMS UE (IPv6) connects to a node in 527 the IPv4 Internet through the IMS, or vice versa. This happens when 528 the other node is a part of a different system than 3GPP, e.g. a 529 fixed PC, with only IPv4 capabilities. 531 The first priority is to upgrade the legacy IPv4 nodes to dual- 532 stack, eliminating this particular problem in that specific 533 deployment. 535 Still, it is difficult to estimate how many non-upgradeable legacy 536 IPv4 nodes need to communicate with the IMS UEs. It is assumed that 537 the solution described here is used for limited cases, in which 538 communications with a small number of legacy IPv4 SIP equipment are 539 needed. 541 As the IMS is exclusively IPv6 [3GPP 23.221], translators have to 542 be used in the communication between the IPv6 IMS and legacy IPv4 543 hosts, i.e. making a dual stack based solution is not feasible. 544 This section aims to give a brief overview on how that interworking 545 can be handled. 547 This section presents higher level details of a solution based on 548 the use of a translator and SIP ALG. [3GPPtr] provides additional 549 information and presents a bit different solution proposal based on 550 SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to 551 solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF 552 SIP wg(s). 554 As control (or signaling) and user (or data) traffic are separated 555 in SIP, and thus, the IMS, the translation of the IMS traffic has 556 to be done at two levels: 557 1)Session Initiation Protocol (SIP) [RFC3261], and 558 Session Description Protocol (SDP) [RFC2327] [RFC3266] 559 (Mm-interface) 560 2)the user data traffic (Mb-interface) 562 SIP and SDP transition has to be made in an SIP/SDP Application 563 Level Gateway. The ALG has to change the IP addresses transported 564 in the SIP messages and the SDP payload of those messages to the 565 appropriate version. In addition, there has to be interoperability 566 for DNS queries; see section 2.4 for details. 568 On the user data transport level, the translation is IPv4-IPv6 569 protocol translation, where the user data traffic transported is 570 translated from IPv6 to IPv4, and vice versa. 572 The legacy IPv4 host's address can be mapped to an IPv6 address for 573 the IMS, and this address is then used within the IMS to route the 574 traffic to the appropriate user traffic translator. This mapping 575 can be done by the SIP/SDP ALG for the SIP traffic. The user 576 traffic translator would do the similar mapping for the user 577 traffic. However, in order to have an IPv4 address for the IMS UE, 578 and to be able to route the user traffic within the legacy IPv4 579 network to the correct translator, there has to be an IPv4 address 580 allocated for the duration of the session from the user traffic 581 translator. The allocation of this address from the user traffic 582 translator has to be done by the SIP/SDP ALG in order for the 583 SIP/SDP ALG to know the correct IPv4 address. This can be achieved 584 by using a protocol for the ALG to do the allocation. 586 +-------------------------------+ +------------+ 587 | +------+ | | +--------+ | 588 | |S-CSCF|---| |SIP ALG | |\ 589 | | +------+ | | +--------+ | \ -------- 590 +-|+ | / | | | | | | 591 | | | +------+ +------+ | | + | -| |- 592 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 593 | | +------+ +------+ | |+----------+| / ------ 594 | |-----------------------------------||Translator||/ 595 +--+ | IPv6 | |+----------+| IPv4 596 UE | | |Interworking| 597 | IP Multimedia CN Subsystem | |Unit | 598 +-------------------------------+ +------------+ 600 Figure 1: UE using IMS to contact a legacy phone 602 Figure 1 shows a possible configuration scenario where the SIP ALG 603 is separated from the CSCFs. The translator can either be set up in 604 a single device with both SIP translation and media translation, or 605 those functionalities can be divided to two different entities with 606 an interface in between. We call the combined network element on 607 the edge of the IPv6-only IMS an "Interworking Unit" in this 608 document. A SIP-specific translation mechanism, which could e.g. 609 re-use limited subsets of NAT-PT [RFC2766], needs to be specified. 610 The problems related to NAT-PT are discussed in appendix A. 612 4.2 Two IMS Islands Connected over IPv4 Network 614 At the early stages of IMS deployment, there may be cases where two 615 IMS islands are separated by an IPv4 network such as the legacy 616 Internet. Here both the UEs and the IMS islands are IPv6-only. 617 However, the IPv6 islands are not connected natively with IPv6. 619 In this scenario, the end-to-end SIP connections are based on IPv6. 620 The only issue is to make connection between two IPv6-only IMS 621 islands over IPv4 network. This scenario is closely related to GPRS 622 scenario represented in section 3.2. and similar tunneling 623 solutions are applicable also in this scenario. 625 5. About 3GPP UE IPv4/IPv6 Configuration 627 This informative section aims to give a brief overview on the 628 configuration needed in the UE in order to access IP based 629 services. There can also be other application specific settings in 630 the UE that are not described here. 632 To be able to access IPv6 or IPv4 based services, settings need to 633 be done in the UE. The GGSN Access Point has to be defined when 634 using, for example, the web browsing application. One possibility 635 is to use over the air configuration to configure the GPRS 636 settings. The user can visit the operator WWW page and subscribe 637 the GPRS Access Point settings to his/her UE and receive the 638 settings via Short Message Service (SMS). After the user has 639 accepted the settings and a PDP context has been activated, the 640 user can start browsing. The Access Point settings can also be 641 typed in manually or be pre-configured by the operator or the UE 642 manufacturer. 644 DNS server addresses typically also need to be configured in the 645 UE. In the case of IPv4 type PDP context, the (IPv4) DNS server 646 addresses can be received in the PDP context activation (a control 647 plane mechanism). Same kind of mechanism is also available for 648 IPv6: so-called Protocol Configuration Options Information Element 649 (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible 650 to use [DHCPv6-SL] or [RFC3315] and [RFC3646] for receiving DNS 651 server addresses. Active IETF work on DNS discovery mechanisms is 652 ongoing and might result in other mechanisms becoming available 653 over time. The DNS server addresses can also be received over the 654 air (using SMS), or typed in manually in the UE. 656 When accessing IMS services, the UE needs to know the P-CSCF IPv6 657 address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism 658 ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. Manual 659 configuration or configuration over the air is also possible. IMS 660 subscriber authentication and registration to the IMS and SIP 661 integrity protection are not discussed here. 663 6. Security Considerations 665 There are some generic security considerations when moving to dual- 666 stack IPv4/IPv6 deployment which are not analyzed at length here. 667 Two examples of these are ensuring that the access controls and 668 firewalls have similar (or known) security properties with both 669 IPv4 and IPv6, and that enabling IPv6 does not jeopardize the 670 access to the IPv4 services (e.g., in the form of misbehavior 671 towards DNS AAAA record lookups or operationally worse quality IP 672 transit services). 674 This memo recommends the use of a relatively small number of 675 techniques, which all of them have their own security 676 considerations, including: 678 - native upstream access or tunneling by the 3GPP network 679 operator, 680 - use of routing protocols to ensure redundancy, 681 - use of locally-deployed specific-purpose protocol relays and 682 application proxies to reach IPv4(-only) nodes from IPv6-only 683 UEs, or 684 - a specific mechanism for SIP signalling and media translation 686 These (except for the last one, naturally) have relatively well- 687 known security considerations, which are also discussed in the 688 specific documents. However, in particular one should note that a 689 proper configuration of locally-deployed relays and proxies is very 690 important, so that the outsiders will not have access to them, to 691 be used for abuse, laundering attacks, or circumventing access 692 controls. 694 In particular, this memo does not recommend the following technique 695 which has security issues, not further analyzed here: 697 - NAT-PT or other translator as a generic-purpose transition 698 mechanism 700 7. References 702 7.1 Normative 704 [RFC2026] Bradner, S.: The Internet Standards Process -- Revision 705 3, RFC 2026, October 1996. 707 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 708 Translator (NAT) Terminology and Considerations, RFC 2663, August 709 1999. 711 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 712 (SIIT), RFC 2765, February 2000. 714 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 715 - Protocol Translation (NAT-PT), RFC 2766, February 2000. 717 [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for 718 IPv6 Hosts and Routers, RFC 2893, August 2000. 720 [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, 721 RFC 3261, June 2002. 723 [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP 724 Networks, RFC 3574, August 2003. 726 [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service 727 (GPRS); Service description; Stage 2 (Release 5)", December 2002. 729 [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements 730 (Release 5)", December 2002. 732 [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem 733 (IMS); Stage 2 (Release 5)", December 2002. 735 [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP 736 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 737 December 2002. 739 [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control 740 Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 742 7.2 Informative 744 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 745 Protocol, RFC 2327, April 1998. 747 [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay 748 Translator, RFC 3142, June 2001. 750 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 751 in Session Description Protocol (SDP), June 2002. 753 [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP 754 Standards, September 2002. 756 [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for 757 IPv6 (DHCPv6), July 2003. 759 [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration 760 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) 761 Servers, July 2003. 763 [RFC3646] Droms, R. (ed.): DNS Configuration options for DHCPv6, 764 December 2003. 766 [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for 767 SIP-based services in Third Generation Partnership Project (3GPP) 768 Networks", December 2003, draft-elmalki-sipping-3gpp-translator- 769 00.txt, work in progress. 771 [DHCP-SL] Droms, R.: "Stateless DHCP Service for IPv6", January 772 2004, draft-ietf-dhc-dhcpv6-stateless-04.txt, work in progress. 774 [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport 775 operational guidelines", November 2003, draft-ietf-dnsop-ipv6- 776 transport-guidelines-01.txt, work in progress. 778 [ISATAP] Templin, F., Gleeson, T., Talwar, M. and Thaler, D.: 779 "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", 780 February 2004, draft-ietf-ngtrans-isatap-20.txt, work in progress. 782 [ISP-sa] Lind, M., Ksinant, V., Park, D., Baudot, A.: "Scenarios 783 and Analysis for Introducing IPv6 into ISP Networks", February 784 2004, draft-ietf-v6ops-isp-scenarios-analysis-01.txt, work in 785 progress. 787 [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S., 788 Wang, H.: "NAT-PT Applicability", October 2003, draft-satapati- 789 v6ops-natpt-applicability-00.txt, work in progress. 791 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", 792 January 2003, draft-durand-v6ops-natpt-dns-alg-issues-01.txt, work 793 in progress, the draft has expired. 795 [STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment 796 Procedure (STEP)", January 2004, draft-savola-v6ops-conftun-setup- 797 02.txt, work in progress. 799 [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 800 3 specification; Core network protocols; Stage 3 (Release 5)", June 801 2003. 803 8. Contributors 805 Pekka Savola has contributed both text and his IPv6 experience to 806 this document. He has provided a large number of helpful comments 807 on the v6ops mailing list. 809 9. Authors and Acknowledgements 811 This document is written by: 813 Alain Durand, Sun Microsystems 814 816 Karim El-Malki, Ericsson Radio Systems 817 819 Niall Richard Murphy, Enigma Consulting Limited 820 822 Hugh Shieh, AT&T Wireless 823 825 Jonne Soininen, Nokia 826 828 Hesham Soliman, Flarion 829 831 Margaret Wasserman, ThingMagic 832 834 Juha Wiljakka, Nokia 835 837 The authors would like to thank Heikki Almay, Gabor Bajko, Ajay 838 Jain, Jarkko Jouppi, Ivan Laloux, Jasminko Mulahusic, Janne Rinne, 839 Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van 840 Meter for their valuable input. 842 10. Editor's Contact Information 844 Comments or questions regarding this document should be sent to the 845 v6ops mailing list or directly to the document editor: 847 Juha Wiljakka 848 Nokia 849 Visiokatu 3 Phone: +358 7180 48372 850 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com 852 11. Intellectual Property Statement 854 The IETF takes no position regarding the validity or scope of any 855 intellectual property or other rights that might be claimed to 856 pertain to the implementation or use of the technology described in 857 this document or the extent to which any license under such rights 858 might or might not be available; neither does it represent that it 859 has made any effort to identify any such rights. Information on the 860 IETF's procedures with respect to rights in standards-track and 861 standards-related documentation can be found in BCP-11. Copies of 862 claims of rights made available for publication and any assurances 863 of licenses to be made available, or the result of an attempt made 864 to obtain a general license or permission for the use of such 865 proprietary rights by implementers or users of this specification 866 can be obtained from the IETF Secretariat. 868 The IETF invites any interested party to bring to its attention any 869 copyrights, patents or patent applications, or other proprietary 870 rights which may cover technology that may be required to practice 871 this standard. Please address the information to the IETF Executive 872 Director. 874 12. Copyright 876 The following copyright notice is copied from [RFC2026], Section 877 10.4. It describes the applicable copyright for this document. 879 Copyright (C) The Internet Society March 24, 2004. All Rights 880 Reserved. 882 This document and translations of it may be copied and furnished to 883 others, and derivative works that comment on or otherwise explain 884 it or assist in its implementation may be prepared, copied, 885 published and distributed, in whole or in part, without restriction 886 of any kind, provided that the above copyright notice and this 887 paragraph are included on all such copies and derivative works. 888 However, this document itself may not be modified in any way, such 889 as by removing the copyright notice or references to the Internet 890 Society or other Internet organizations, except as needed for the 891 purpose of developing Internet standards in which case the 892 procedures for copyrights defined in the Internet Standards process 893 must be followed, or as required to translate it into languages 894 other than English. 896 The limited permissions granted above are perpetual and will not be 897 revoked by the Internet Society or its successors or assignees. 899 This document and the information contained herein is provided on 900 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 901 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 902 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 903 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 904 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 906 Appendix A - On the Use of Generic Translators in the 3GPP Networks 908 This appendix lists mainly 3GPP-specific arguments about generic 909 translators, even though the use of generic translators is 910 discouraged. The section may be removed in future versions of the 911 memo. 913 Due to the significant lack of IPv4 addresses in some domains, port 914 multiplexing is likely to be a necessary feature for translators 915 (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the 916 GGSN external (Gi) interface, typically separate from the GGSN. 917 NA(P)T-PT can be installed, for example, on the edge of the 918 operator's network and the public Internet. NA(P)T-PT will 919 intercept DNS requests and other applications that include IP 920 addresses in their payloads, translate the IP header (and payload 921 for some applications if necessary) and forward packets through its 922 IPv4 interface. 924 NA(P)T-PT introduces limitations that are expected to be magnified 925 within the 3GPP architecture. Some of these limitations are listed 926 below (notice that most of them are also relevant for IPv4 NAT). 927 [NATPTappl] discusses the applicability of NAT-PT in more detail. 929 1. NA(P)T-PT is a single point of failure for all ongoing 930 connections. 932 2. There are additional forwarding delays due to further 933 processing, when compared to normal IP forwarding. 935 3. There are problems with source address selection due to the 936 inclusion of a DNS ALG on the same node [NATPT-DNS]. 938 4. NA(P)T-PT does not work (without application level gateways) 939 for applications that embed IP addresses in their payload. 941 5. NA(P)T-PT breaks DNSSEC. 943 6. NA(P)T-PT does not scale very well in large networks. 945 3GPP networks are expected to handle a very large number of 946 subscribers on a single GGSN (default router). Each GGSN is 947 expected to handle hundreds of thousands of connections. 948 Furthermore, high reliability is expected for 3GPP networks. 949 Consequently, a single point of failure on the GGSN external 950 interface would raise concerns on the overall network reliability. 951 In addition, IPv6 users are expected to use delay-sensitive 952 applications provided by IMS. Hence, there is a need to minimize 953 forwarding delays within the IP backbone. Furthermore, due to the 954 unprecedented number of connections handled by the default routers 955 (GGSN) in 3GPP networks, a network design that forces traffic to go 956 through a single node at the edge of the network (typical NA(P)T-PT 957 configuration) is not likely to scale. Translation mechanisms 958 should allow for multiple translators, for load sharing and 959 redundancy purposes. 961 To minimize the problems associated with NA(P)T-PT, the following 962 actions can be recommended: 964 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to 965 IPv4" case). 967 2. Ensure (if possible) that NA(P)T-PT does not become a single 968 point of failure. 970 3. Allow for load sharing between different translators. That is, 971 it should be possible for different connections to go through 972 different translators. Note that load sharing alone does not 973 prevent NA(P)T-PT from becoming a single point of failure.