idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-07.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.) ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 245: '...rsive DNS server SHOULD be either IPv4...' RFC 2119 keyword, line 247: '... single DNS zone SHOULD be served by a...' RFC 2119 keyword, line 256: '... SHOULD ensure that there is at lea...' 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 (October 2003) is 7496 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 669, but not defined == Unused Reference: 'RFC2663' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'DHCP-SL' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'ISP-scen' is defined on line 795, 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 (-04) exists of draft-ietf-dhc-dhcpv6-stateless-01 == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-ipv6-transport-guidelines-00 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 5 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-07.txt Nokia 4 Expires: April 2004 6 October 2003 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......................4 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 8 55 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 10 56 3.4 IPv6 UE Connecting to an IPv4 Node.......................10 57 3.5 IPv4 UE Connecting to an IPv6 Node.......................11 58 4. IMS Transition Scenarios.....................................12 59 4.1 UE Connecting to a Node in an IPv4 Network through IMS...12 60 4.2 Two IMS Islands Connected over IPv4 Network..............14 61 5. About 3GPP UE IPv4/IPv6 Configuration........................14 62 6. Security Considerations......................................15 63 7. References...................................................15 64 7.1 Normative................................................15 65 7.2 Informative..............................................16 66 8. Contributors.................................................18 67 9. Authors and Acknowledgements.................................18 68 10. Editor's Contact Information................................19 69 11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt..........19 70 12. Intellectual Property Statement.............................19 71 13. Copyright...................................................19 72 Appendix A...................................................20 74 1. Introduction 76 This document describes and analyzes the process of transition to 77 IPv6 in Third Generation Partnership Project (3GPP) General Packet 78 Radio Service (GPRS) packet networks. The authors can be found in 79 Authors and Acknowledgements section. 81 This document analyzes the transition scenarios in 3GPP packet 82 data networks that might come up in the deployment phase of IPv6. 84 The transition scenarios are documented in [RFC3574] and this 85 document will further analyze them. The scenarios are divided into 86 two categories: GPRS scenarios and IP Multimedia Subsystem (IMS) 87 scenarios. 89 GPRS scenarios are the following: 90 - Dual Stack UE connecting to IPv4 and IPv6 nodes 91 - IPv6 UE connecting to an IPv6 node through an IPv4 network 92 - IPv4 UE connecting to an IPv4 node through an IPv6 network 93 - IPv6 UE connecting to an IPv4 node 94 - IPv4 UE connecting to an IPv6 node 96 IMS scenarios are the following: 97 - UE connecting to a node in an IPv4 network through IMS 98 - Two IMS islands connected via IPv4 network 100 The focus is on analyzing different transition scenarios, 101 applicable transition mechanisms and finding solutions for those 102 transition scenarios. In the scenarios, the User Equipment (UE) 103 connects to nodes in other networks, e.g. in the Internet and 104 IPv6/IPv4 transition mechanisms are needed. 106 1.1 Scope of this Document 108 The scope of this Best Current Practices document is to analyze and 109 solve the possible transition scenarios in the 3GPP defined GPRS 110 network where a UE connects to, or is contacted from, the Internet 111 or another UE. The document covers scenarios with and without the 112 use of the SIP based IP Multimedia Core Network Subsystem (IMS). 113 This document does not focus on radio interface issues; both 3GPP 114 Second (GSM) and Third Generation (UMTS) radio network 115 architectures will be covered by these scenarios. 117 The transition mechanisms specified by the IETF Ngtrans and v6ops 118 Working Groups shall be used. This document shall not specify any 119 new transition mechanisms, but if a need for a new mechanism is 120 found, that will be reported to the IETF v6ops Working Group. 122 1.2 Abbreviations 124 2G Second Generation Mobile Telecommunications, for 125 example GSM and GPRS technologies. 126 3G Third Generation Mobile Telecommunications, for example 127 UMTS technology. 128 3GPP Third Generation Partnership Project 129 ALG Application Level Gateway 130 APN Access Point Name. The APN is a logical name referring 131 to a GGSN and an external network. 132 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 133 DNS Domain Name System 134 GGSN Gateway GPRS Support Node (a default router for 3GPP 135 User Equipment) 136 GPRS General Packet Radio Service 137 GSM Global System for Mobile Communications 138 HLR Home Location Register 139 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 140 IPv6-only part of the network 141 ISP Internet Service Provider 142 NAT Network Address Translator 143 NAPT-PT Network Address Port Translation - Protocol Translation 144 NAT-PT Network Address Translation - Protocol Translation 145 PCO-IE Protocol Configuration Options Information Element 146 PDP Packet Data Protocol 147 PPP Point-to-Point Protocol 148 SGSN Serving GPRS Support Node 149 SIIT Stateless IP/ICMP Translation Algorithm 150 SIP Session Initiation Protocol 151 UE User Equipment, for example a UMTS mobile handset 152 UMTS Universal Mobile Telecommunications System 154 1.3 Terminology 156 Some terms used in 3GPP transition scenarios and analysis documents 157 are briefly defined here. 159 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both 160 IPv4 and IPv6 stacks. It is capable of activating 161 both IPv4 and IPv6 Packet Data Protocol (PDP) 162 contexts. Dual stack UE may be capable of tunneling. 164 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 165 only capable of activating IPv6 PDP contexts. 167 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 168 only capable of activating IPv4 PDP contexts. 170 IPv4 node IPv4 node is here defined to be IPv4 capable node 171 the UE is communicating with. The IPv4 node can 172 be, for example, an application server or another 173 UE. 175 IPv6 node IPv6 node is here defined to be IPv6 capable node 176 the UE is communicating with. The IPv6 node can 177 be, for example, an application server or another 178 UE. 180 2. Transition Mechanisms and DNS Guidelines 182 This chapter briefly introduces some transition mechanisms 183 specified by the IETF. In addition to that, DNS recommendations are 184 given. The applicability of different transition mechanisms to 3GPP 185 networks is discussed in chapters 3 and 4. 187 The IPv4/IPv6 transition methods can be divided to: 189 - dual IPv4/IPv6 stack 190 - tunneling 191 - protocol translators 193 2.1 Dual Stack 195 The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider 196 the 3GPP GPRS core network, dual stack implementation in the 197 Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 198 PDP contexts. UEs with dual stack and public (global) IP addresses 199 can typically access both IPv4 and IPv6 services without additional 200 translators in the network. However, it is good to remember that 201 public IPv4 addresses are a scarce resource and in many cases IPv4 202 NATs are deployed. Public/global IP addresses are also needed for 203 peer-to-peer services: the node needs a public/global IP address 204 that is visible to other nodes. 206 2.2 Tunneling 208 Tunneling is a transition mechanism that requires dual IPv4/IPv6 209 stack functionality in the encapsulating and decapsulating nodes. 210 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 212 Tunneling can be static or dynamic. Static (configured) tunnels are 213 fixed IPv6 links over IPv4, and they are specified in [RFC2893]. 214 Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where 215 the tunnel endpoints are not configured, i.e. the links are created 216 dynamically. 218 2.3 Protocol Translators 220 A translator can be defined as an intermediate component between a 221 native IPv4 node and a native IPv6 node to enable direct 222 communication between them without requiring any modifications to 223 the end nodes. 225 Header conversion is a translation mechanism. In header conversion, 226 IPv6 packet headers are converted to IPv4 packet headers, or vice 227 versa, and checksums are adjusted or recalculated if necessary. 228 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 229 using SIIT [RFC2765] is an example of such a mechanism. 231 Translators may be needed in some cases when the communicating 232 nodes do not share the same IP version; in others, it may be 233 possible to avoid such communication altogether. Translation can 234 actually happen at Layer 3 (using NAT-like techniques), Layer 4 235 (using a TCP/UDP proxy) or Layer 7 (using application relays). 237 2.4 DNS Guidelines for IPv4/IPv6 Transition 239 [DNStrans] provides guidelines to operate DNS in a mixed world of 240 IPv4 and IPv6 transport. The recommendations (including the 241 keywords) are copied verbatim from [DNStrans]: 243 "In order to preserve name space continuity, the following 244 administrative policies are RECOMMENDED: 245 - every recursive DNS server SHOULD be either IPv4-only or dual 246 stack, 247 - every single DNS zone SHOULD be served by at least one IPv4 248 reachable DNS server. 250 This rules out IPv6-only DNS server performing full recursion and 251 DNS zones served only by IPv6-only DNS servers. This approach 252 could be revisited if/when translation techniques between IPv4 and 253 IPv6 were to be widely deployed. 255 In order to enforce the second point, the zone validation process 256 SHOULD ensure that there is at least one IPv4 address record 257 available for the name servers of any child delegations within the 258 zone." 260 3. GPRS Transition Scenarios 262 This section discusses the scenarios that might occur when a GPRS 263 UE contacts services or other nodes, e.g. a web server in the 264 Internet. 266 The following scenarios described by [RFC3574] are analyzed here. 267 In all of the scenarios, the UE is part of a network where there is 268 at least one router of the same IP version, i.e. the GGSN, and the 269 UE is connecting to a node in a different network. 271 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 272 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 273 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 274 4) IPv6 UE connecting to an IPv4 node 275 5) IPv4 UE connecting to an IPv6 node 277 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 279 In this scenario, the dual stack UE is capable of communicating 280 with both IPv4 and IPv6 nodes. It is recommended to activate an 281 IPv6 PDP context when communicating with an IPv6 peer node and an 282 IPv4 PDP context when communicating with an IPv4 peer node. If the 283 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE 284 activates the appropriate PDP context depending on the type of 285 application it has started or depending on the address of the peer 286 host it needs to communicate with. If IPv6 PDP contexts are 287 available and IPv6-in-IPv4 tunneling is needed, it is recommended 288 to activate an IPv6 PDP context and perform tunneling in the 289 network. This case is described in more detail in section 3.2. 291 However, the UE may attach to a 3GPP network, in which the Serving 292 GPRS Support Node (SGSN), the GGSN, and the Home Location Register 293 (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP 294 contexts. This may happen in early phases of IPv6 deployment. If 295 the 3GPP network does not support IPv6 PDP contexts, and an 296 application on the UE needs to communicate with an IPv6(-only) 297 node, the UE may activate an IPv4 PDP context and encapsulate IPv6 298 packets in IPv4 packets using a tunneling mechanism. 300 The use of private IPv4 addresses in the UE depends on the support 301 of these addresses by the tunneling mechanism and the deployment 302 scenario. In some cases public IPv4 addresses are required, but if 303 the tunnel endpoints are in the same private domain, or the 304 tunneling mechanism works through IPv4 NAT, private IPv4 addresses 305 can be used. One deployment scenario example is using a laptop 306 computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in 307 IPv4 packets in the laptop computer and IPv4 PDP context is 308 activated. The used tunneling mechanism (automatic or configured) 309 in that case depends on the support of tunneling mechanisms in the 310 laptop computer. 312 To generally solve this problem (IPv6 not available in the 3GPP 313 network), this document strongly recommends the 3GPP operators to 314 deploy basic IPv6 support in their GPRS networks. That also makes 315 it possible to burden the transition effects in the network and 316 make the 3GPP UEs simpler. 318 As a general guideline, IPv6 communication is preferred to IPv4 319 communication going through IPv4 NATs to the same dual stack peer 320 node. 322 An application running on a UE can identify whether the endpoint is 323 an IPv4 or IPv6 capable node by examining the destination address. 324 Alternatively, if a user supplies a name to be resolved, the DNS 325 may contain records sufficient to identify which protocol should be 326 used to initiate the connection with the endpoint. In dual stack 327 networks, one of the main concerns of an operator is the correct 328 address space and routing management. The operator must maintain 329 address spaces for both protocols. Public IPv4 addresses are often 330 a scarce resource for the operator and typically it is not possible 331 for a UE to have a globally unique IPv4 address (continuously) 332 allocated for its use. Use of private IPv4 addresses means use of 333 NATs when communicating with a peer node outside the operator's 334 network. In large networks, NAT systems can become very complex, 335 expensive and difficult to maintain. 337 For DNS recommendations, we refer to section 2.4. 339 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 341 The best solution for this scenario is obtained with tunneling, 342 i.e. IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context 343 is activated between the UE and the GGSN. Tunneling is handled in 344 the network, because IPv6 UE is not capable of tunneling (it does 345 not have the dual stack functionality needed for tunneling). The 346 encapsulating node can be the GGSN, the edge router between the 347 border of the operator's IPv6 network and the public Internet, or 348 any other dual stack node within the operator's IP network. The 349 encapsulation (uplink) and decapsulation (downlink) can be handled 350 by the same network element. Typically the tunneling handled by the 351 network elements is transparent to the UEs and IP traffic looks 352 like native IPv6 traffic to them. For the applications, tunneling 353 enables end-to-end IPv6 connectivity. Note that this scenario is 354 comparable to 6bone [6BONE] network operation. 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 scen] and [ISP-an]. 371 3.2.1 Tunneling inside the 3GPP Operator's Network 373 Many GPRS operators already have IPv4 backbone networks deployed 374 and they are gradually migrating them while introducing IPv6 375 islands. IPv6 backbones can be considered quite rare in the first 376 phases of the transition. If the 3GPP operator already has IPv6 377 widely deployed in its network, this subsection is not so relevant. 379 In initial IPv6 deployment, where a small number of IPv6-in-IPv4 380 tunnels are required to connect the IPv6 islands over the 3GPP 381 operator's IPv4 network, manually configured tunnels can be used. 383 In a 3GPP network, one IPv6 island can contain the GGSN while 384 another island can contain the operator's IPv6 application servers. 385 However, manually configured tunnels can be an administrative 386 burden when the number of islands and therefore tunnels rises. In 387 that case, upgrading parts of the backbone to dual stack may be the 388 simplest choice. The administrative burden could also be mitigated 389 by using automated management tools which are typically necessary 390 to manage large networks anyway. 392 Connection redundancy should also be noted as an important 393 requirement in 3GPP networks. Static tunnels on their own don't 394 provide a routing recovery solution for all scenarios where an IPv6 395 route goes down. However, they may provide an adequate solution 396 depending on the design of the network and in presence of other 397 router redundancy mechanisms. On the other hand, routing protocol 398 based mechanisms can provide redundancy. 400 3.2.2 Tunneling outside the 3GPP Operator's Network 402 This subsection includes the case in which the peer node is outside 403 the operator's network. In that case IPv6-in-IPv4 tunneling can be 404 necessary to obtain IPv6 connectivity and reach other IPv6 nodes. 406 Tunnel starting point can be in the operator's network depending on 407 how far the 3GPP operator has come in implementing IPv6. If the 408 3GPP operator does not have an IP backbone, or has not implemented 409 IPv6 in it, the encapsulating node can be the GGSN. If the 3GPP 410 operator has an IP backbone, and has implemented IPv6 in it, but 411 the upstream ISP does not provide IPv6 connectivity to the 412 Internet, the encapsulating node can be the edge router. 414 The case is pretty straightforward if the upstream ISP provides 415 IPv6 connectivity to the Internet and the operator's backbone 416 network supports IPv6. Then the 3GPP operator does not have to 417 configure any tunnels, since the upstream ISP will take care of 418 routing IPv6 packets. If the upstream ISP does not provide IPv6 419 connectivity, an IPv6-in-IPv4 tunnel should be configured e.g. from 420 the edge router to a dual stack border gateway operated by another 421 ISP which is offering IPv6 connectivity. 423 In the tunneling scenarios above, usage of configured IPv6-in-IPv4 424 tunneling is recommended. As the number of the tunnels outside of 425 the 3GPP network is limited, no more than a couple of tunnels 426 should be needed. 428 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 430 3GPP networks are expected to support both IPv4 and IPv6 for a long 431 time, on the UE-GGSN link and between the GGSN and external 432 networks. For this scenario, it is useful to split the end-to-end 433 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 434 v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and 435 IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 436 link (PDP context) to connect to the GGSN without the need to 437 communicate over an IPv6 network. 439 Regarding the GGSN-to-v4NODE communication, typically the transport 440 network between the GGSN and external networks will support only 441 IPv4 in the early stages and migrate to dual stack, since these 442 networks are already deployed. Therefore it is not envisaged that 443 tunneling of IPv4-in-IPv6 will be required from the GGSN to 444 external IPv4 networks either. In the longer run, 3GPP operators 445 may need to phase out IPv4 UEs and the IPv4 transport network. This 446 would leave only IPv6 UEs. 448 Therefore, overall, the transition scenario involving an IPv4 UE 449 communicating with an IPv4 peer through an IPv6 network is not 450 considered very likely in 3GPP networks. 452 3.4 IPv6 UE Connecting to an IPv4 Node 454 Generally speaking, IPv6-only UEs may be easier to manage, but that 455 would require all services to be used over IPv6, and that may not 456 be realistic in the near future. Dual stack implementation requires 457 management of both IPv4 and IPv6 networks and one approach is that 458 "legacy" applications keep using IPv4 for the foreseeable future 459 and new applications requiring end-to-end connectivity (for 460 example, peer-to-peer services) use IPv6. As a general guideline, 461 IPv6-only UEs are not recommended in the early phases of transition 462 until the IPv6 deployment has become so prevalent that direct 463 communication with IPv4(-only) nodes will no longer be necessary. 464 It is assumed that IPv4 will remain useful for quite a long time, 465 so in general, dual-stack implementation in the UE can be 466 recommended. This recommendation naturally includes manufacturing 467 dual-stack UEs instead of IPv4-only UEs. 469 However, if there is a need to connect to an IPv4(-only) node from 470 an IPv6-only UE, it is possible to use specific translation and 471 proxying techniques; generic IP protocol translation is not 472 recommended. There are three main ways for IPv6(-only) nodes to 473 communicate with IPv4(-only) nodes (excluding avoiding such 474 communication in the first place): 476 1. the use of generic-purpose translator (e.g. NAT-PT [RFC2766]) 477 in the local network (not recommended as a general solution), 479 2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 480 TCP relay configured for a couple of ports only [RFC3142]) or 481 application proxies (e.g., HTTP proxy, SMTP relay) in the 482 local network, or 484 3. the use of specific-purpose mechanisms (as described above in 485 2) in the foreign network; these are indistinguishable from 486 the IPv6-enabled services from the IPv6 UE's perspective, and 487 not discussed further here. 489 For many applications, application proxies can be appropriate (e.g. 490 HTTP proxies, SMTP relays, etc.). Such application proxies will not 491 be transparent to the UE. Hence, a flexible mechanism with minimal 492 manual intervention should be used to configure these proxies on 493 IPv6 UEs. Within the 3GPP architecture, application proxies can be 494 placed on the GGSN external interface (Gi), or inside the service 495 network. 497 The authors note that [NATPTappl] discusses the applicability of 498 NAT-PT. The problems related to NAT-PT usage in 3GPP networks are 499 documented in appendix A. 501 3.5 IPv4 UE Connecting to an IPv6 Node 503 The legacy IPv4 nodes are mostly nodes that support the 504 applications that are popular today in the IPv4 Internet: mostly e- 505 mail and web-browsing. These applications will, of course, be 506 supported in the future IPv6 Internet. However, the legacy IPv4 UEs 507 are not going to be updated to support the future applications. As 508 these applications are designed for IPv6, and to use the advantages 509 of newer platforms, the legacy IPv4 nodes will not be able to 510 profit from them. Thus, they will continue to support the legacy 511 services. 513 Taking the above into account, the traffic to and from the legacy 514 IPv4 UE is restricted to a few applications. These applications 515 already mostly rely on proxies or local servers to communicate 516 between private address space networks and the Internet. The same 517 methods and technology can be used for IPv4 to IPv6 transition. 519 For DNS recommendations, we refer to section 2.4. 521 4. IMS Transition Scenarios 523 As the IMS is exclusively IPv6, the number of possible transition 524 scenarios is reduced dramatically. The possible IMS scenarios are 525 listed below and analyzed in sections 4.1 and 4.2. 527 1) UE connecting to a node in an IPv4 network through IMS 528 2) Two IMS islands connected over IPv4 network 530 For DNS recommendations, we refer to section 2.4. As DNS traffic is 531 not directly related to the IMS functionality, the recommendations 532 are not in contradiction with the IPv6-only nature of the IMS. 534 4.1 UE Connecting to a Node in an IPv4 Network through IMS 536 This scenario occurs when an IMS UE (IPv6) connects to a node in 537 the IPv4 Internet through the IMS, or vice versa. This happens when 538 the other node is a part of a different system than 3GPP, e.g. a 539 fixed PC, with only IPv4 capabilities. 541 The first priority is to upgrade the legacy IPv4 nodes to dual- 542 stack, eliminating this particular problem in that specific 543 deployment. 545 Still, it is difficult to estimate how many non-upgradeable legacy 546 IPv4 nodes need to communicate with the IMS UEs. It is assumed that 547 the solution described here is used for limited cases, in which 548 communications with a small number of legacy IPv4 SIP equipment are 549 needed. 551 As the IMS is exclusively IPv6 [3GPP 23.221], translators have to 552 be used in the communication between the IPv6 IMS and legacy IPv4 553 hosts, i.e. making a dual stack based solution is not feasible. 554 This section aims to give a brief overview on how that interworking 555 can be handled. 557 This section presents higher level details of a solution based on 558 the use of a translator and SIP ALG. [3GPPtr] provides additional 559 information and presents a bit different solution proposal based on 560 SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to 561 solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF 562 SIP wg(s). 564 As control (or signaling) and user (or data) traffic are separated 565 in SIP, and thus, the IMS, the translation of the IMS traffic has 566 to be done at two levels: 567 1)Session Initiation Protocol (SIP) [RFC3261], and 568 Session Description Protocol (SDP) [RFC2327] [RFC3266] 569 (Mm-interface) 571 2)the user data traffic (Mb-interface) 573 SIP and SDP transition has to be made in an SIP/SDP Application 574 Level Gateway. The ALG has to change the IP addresses transported 575 in the SIP messages and the SDP payload of those messages to the 576 appropriate version. In addition, there has to be interoperability 577 for DNS queries; see section 2.4 for details. 578 On the user data transport level, the translation is IPv4-IPv6 579 protocol translation, where the user data traffic transported is 580 translated from IPv6 to IPv4, and vice versa. 582 The legacy IPv4 host's address can be mapped to an IPv6 address for 583 the IMS, and this address is then used within the IMS to route the 584 traffic to the appropriate user traffic translator. This mapping 585 can be done by the SIP/SDP ALG for the SIP traffic. The user 586 traffic translator would do the similar mapping for the user 587 traffic. However, in order to have an IPv4 address for the IMS UE, 588 and to be able to route the user traffic within the legacy IPv4 589 network to the correct translator, there has to be an IPv4 address 590 allocated for the duration of the session from the user traffic 591 translator. The allocation of this address from the user traffic 592 translator has to be done by the SIP/SDP ALG in order for the 593 SIP/SDP ALG to know the correct IPv4 address. This can be achieved 594 by using a protocol for the ALG to do the allocation. 596 +-------------------------------+ +------------+ 597 | +------+ | | +--------+ | 598 | |S-CSCF|---| |SIP ALG | |\ 599 | | +------+ | | +--------+ | \ -------- 600 +-|+ | / | | | | | | 601 | | | +------+ +------+ | | + | -| |- 602 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 603 | | +------+ +------+ | |+----------+| / ------ 604 | |-----------------------------------||Translator||/ 605 +--+ | IPv6 | |+----------+| IPv4 606 UE | | |Interworking| 607 | IP Multimedia CN Subsystem | |Unit | 608 +-------------------------------+ +------------+ 610 Figure 1: UE using IMS to contact a legacy phone 612 Figure 1 shows a possible configuration scenario where the SIP ALG 613 is separated from the CSCFs. The translator can either be set up in 614 a single device with both SIP translation and media translation, or 615 those functionalities can be divided to two different entities with 616 an interface in between. We call the combined network element on 617 the edge of the IPv6-only IMS an "Interworking Unit" in this 618 document. A SIP-specific translation mechanism, which could e.g. 620 re-use limited subsets of NAT-PT [RFC2766], needs to be specified. 621 The problems related to NAT-PT are discussed in appendix A. 623 4.2 Two IMS Islands Connected over IPv4 Network 625 At the early stages of IMS deployment, there may be cases where two 626 IMS islands are separated by an IPv4 network such as the legacy 627 Internet. Here both the UEs and the IMS islands are IPv6-only. 628 However, the IPv6 islands are not connected natively with IPv6. 630 In this scenario, the end-to-end SIP connections are based on IPv6. 631 The only issue is to make connection between two IPv6-only IMS 632 islands over IPv4 network. This scenario is closely related to GPRS 633 scenario represented in section 3.2. and similar tunneling 634 solutions are applicable also in this scenario. 636 5. About 3GPP UE IPv4/IPv6 Configuration 638 This informative section aims to give a brief overview on the 639 configuration needed in the UE in order to access IP based 640 services. There can also be other application specific settings in 641 the UE that are not described here. 643 To be able to access IPv6 or IPv4 based services, settings need to 644 be done in the UE. The GGSN Access Point has to be defined when 645 using, for example, the web browsing application. One possibility 646 is to use over the air configuration to configure the GPRS 647 settings. The user can visit the operator WWW page and subscribe 648 the GPRS Access Point settings to his/her UE and receive the 649 settings via Short Message Service (SMS). After the user has 650 accepted the settings and a PDP context has been activated, the 651 user can start browsing. The Access Point settings can also be 652 typed in manually or be pre-configured by the operator or the UE 653 manufacturer. 655 DNS server addresses typically also need to be configured in the 656 UE. In the case of IPv4 type PDP context, the (IPv4) DNS server 657 addresses can be received in the PDP context activation (a control 658 plane mechanism). Same kind of mechanism is also available for 659 IPv6: so-called Protocol Configuration Options Information Element 660 (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible 661 to use [DHCPv6-SL] or [RFC3315] and [DHCP-DNS] for receiving DNS 662 server addresses. The authors note that the general IPv6 DNS 663 discovery problem is being solved by the IETF dnsop Working Group. 664 The DNS server addresses can also be received over the air (using 665 SMS), or typed in manually in the UE. 667 When accessing IMS services, the UE needs to know the P-CSCF IPv6 668 address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism 669 ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. Manual 670 configuration or configuration over the air is also possible. IMS 671 subscriber authentication and registration to the IMS and SIP 672 integrity protection are not discussed here. 674 6. Security Considerations 676 There are some generic security considerations when moving to dual- 677 stack IPv4/IPv6 deployment which are not analyzed at length here. 678 Two examples of these are ensuring that the access controls and 679 firewalls have similar (or known) security properties with both 680 IPv4 and IPv6, and that enabling IPv6 does not jeopardize the 681 access to the IPv4 services (e.g., in the form of misbehavior 682 towards DNS AAAA record lookups or operationally worse quality IP 683 transit services). 685 This memo recommends the use of a relatively small number of 686 techniques, which all of them have their own security 687 considerations, including: 689 - native upstream access or tunneling by the 3GPP network 690 operator, 691 - use of routing protocols to ensure redundancy, 692 - use of locally-deployed specific-purpose protocol relays and 693 application proxies to reach IPv4(-only) nodes from IPv6-only 694 UEs, or 695 - a specific mechanism for SIP signalling and media translation 697 These (except for the last one, naturally) have relatively well- 698 known security considerations, which are also discussed in the 699 specific documents. However, in particular one should note that a 700 proper configuration of locally-deployed relays and proxies is very 701 important, so that the outsiders will not have access to them, to 702 be used for abuse, laundering attacks, or circumventing access 703 controls. 705 In particular, this memo does not recommend the following technique 706 which has security issues, not further analyzed here: 708 - NAT-PT or other translator as a generic-purpose transition 709 mechanism, 711 7. References 713 7.1 Normative 715 [RFC2026] Bradner, S.: The Internet Standards Process -- Revision 716 3, RFC 2026, October 1996. 718 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 719 Translator (NAT) Terminology and Considerations, RFC 2663, August 720 1999. 722 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 723 (SIIT), RFC 2765, February 2000. 725 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 726 - Protocol Translation (NAT-PT), RFC 2766, February 2000. 728 [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for 729 IPv6 Hosts and Routers, RFC 2893, August 2000. 731 [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, 732 RFC 3261, June 2002. 734 [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP 735 Networks, RFC 3574, August 2003. 737 [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service 738 (GPRS); Service description; Stage 2 (Release 5)", December 2002. 740 [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements 741 (Release 5)", December 2002. 743 [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem 744 (IMS); Stage 2 (Release 5)", December 2002. 746 [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP 747 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 748 December 2002. 750 [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control 751 Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 753 7.2 Informative 755 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 756 Protocol, RFC 2327, April 1998. 758 [RFC3142] Hagino, J., Yamamoto, K.: An IPv6-to-IPv4 Transport Relay 759 Translator, RFC 3142, June 2001. 761 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 762 in Session Description Protocol (SDP), June 2002. 764 [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP 765 Standards, September 2002. 767 [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for 768 IPv6 (DHCPv6), July 2003. 770 [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration 771 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) 772 Servers, July 2003. 774 [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translation mechanism for 775 SIP-based services in Third Generation Partnership Project (3GPP) 776 Networks", October 2003, draft-elmalki-sipping-3gpp-translator- 777 00.txt, work in progress. 779 [DHCP-DNS] Droms, R. (ed.): "DNS Configuration options for DHCPv6", 780 August 2003, draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, work in 781 progress. 783 [DHCP-SL] Droms, R.: "A Guide to Implementing Stateless DHCPv6 784 Service", October 2003, draft-ietf-dhc-dhcpv6-stateless-01.txt, 785 work in progress. 787 [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport 788 operational guidelines", June 2003, draft-ietf-dnsop-ipv6- 789 transport-guidelines-00.txt, work in progress. 791 [ISP-an] Ksinant, V. (ed.): " Analysis of Transition Mechanisms for 792 Introducing IPv6 into ISP Networks", October 2003, draft-ksinant- 793 v6ops-isp-analysis-00.txt, work in progress. 795 [ISP-scen] Lind, M. (Editor): "Scenarios for Introducing IPv6 into 796 ISP Networks", October 2003, draft-lind-v6ops-isp-scenarios-01.txt, 797 work in progress. 799 [NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S., 800 Wang, H.: " NAT-PT Applicability ", October 2003, draft-satapati- 801 v6ops-natpt-applicability-00.txt, work in progress. 803 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", 804 January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work 805 in progress, the draft has expired. 807 [v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.: 808 "Issues when translating between IPv4 and IPv6", January 2003, 809 draft-vanderpol-v6ops-translation-issues-00.txt, work in progress, 810 the draft has expired. 812 [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 813 3 specification; Core network protocols; Stage 3 (Release 5)", June 814 2003. 816 [6BONE] http://www.6bone.net 818 8. Contributors 820 Pekka Savola has contributed both text and his IPv6 experience to 821 this document. He has provided a large number of helpful comments 822 on the v6ops mailing list. 824 9. Authors and Acknowledgements 826 This document is written by: 828 Alain Durand, Sun Microsystems 829 831 Karim El-Malki, Ericsson Radio Systems 832 834 Niall Richard Murphy, Enigma Consulting Limited 835 837 Hugh Shieh, AT&T Wireless 838 840 Jonne Soininen, Nokia 841 843 Hesham Soliman, Flarion 844 846 Margaret Wasserman, Nokia 847 849 Juha Wiljakka, Nokia 850 852 The authors would like to thank Heikki Almay, Gabor Bajko, Ajay 853 Jain, Jarkko Jouppi, Ivan Laloux, Jasminko Mulahusic, Janne Rinne, 854 Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur and Rod Van 855 Meter for their valuable input. 857 10. Editor's Contact Information 859 Comments or questions regarding this document should be sent to the 860 v6ops mailing list or directly to the document editor: 862 Juha Wiljakka 863 Nokia 864 Visiokatu 3 Phone: +358 7180 48372 865 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com 867 11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt 869 - 3.2.2 edited based on wg last call comments 870 - Editorial / textual changes in many sections 872 12. Intellectual Property Statement 874 The IETF takes no position regarding the validity or scope of any 875 intellectual property or other rights that might be claimed to 876 pertain to the implementation or use of the technology described in 877 this document or the extent to which any license under such rights 878 might or might not be available; neither does it represent that it 879 has made any effort to identify any such rights. Information on the 880 IETF's procedures with respect to rights in standards-track and 881 standards-related documentation can be found in BCP-11. Copies of 882 claims of rights made available for publication and any assurances 883 of licenses to be made available, or the result of an attempt made 884 to obtain a general license or permission for the use of such 885 proprietary rights by implementers or users of this specification 886 can be obtained from the IETF Secretariat. 888 The IETF invites any interested party to bring to its attention any 889 copyrights, patents or patent applications, or other proprietary 890 rights which may cover technology that may be required to practice 891 this standard. Please address the information to the IETF Executive 892 Director. 894 13. Copyright 896 The following copyright notice is copied from [RFC2026], Section 897 10.4. It describes the applicable copyright for this document. 899 Copyright (C) The Internet Society October 26, 2003. All Rights 900 Reserved. 902 This document and translations of it may be copied and furnished to 903 others, and derivative works that comment on or otherwise explain 904 it or assist in its implementation may be prepared, copied, 905 published and distributed, in whole or in part, without restriction 906 of any kind, provided that the above copyright notice and this 907 paragraph are included on all such copies and derivative works. 908 However, this document itself may not be modified in any way, such 909 as by removing the copyright notice or references to the Internet 910 Society or other Internet organizations, except as needed for the 911 purpose of developing Internet standards in which case the 912 procedures for copyrights defined in the Internet Standards process 913 must be followed, or as required to translate it into languages 914 other than English. 916 The limited permissions granted above are perpetual and will not be 917 revoked by the Internet Society or its successors or assignees. 919 This document and the information contained herein is provided on 920 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 921 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 922 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 923 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 924 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 926 Appendix A - On the Use of Generic Translators in the 3GPP Networks 928 This appendix lists mainly 3GPP-specific arguments about generic 929 translators, even though the use of generic translators is 930 discouraged. The section may be removed in future versions of the 931 memo. 933 Due to the significant lack of IPv4 addresses in some domains, port 934 multiplexing is likely to be a necessary feature for translators 935 (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the 936 GGSN external (Gi) interface, typically separate from the GGSN. 937 NA(P)T-PT can be installed, for example, on the edge of the 938 operator's network and the public Internet. NA(P)T-PT will 939 intercept DNS requests and other applications that include IP 940 addresses in their payloads, translate the IP header (and payload 941 for some applications if necessary) and forward packets through its 942 IPv4 interface. 944 NA(P)T-PT introduces limitations that are expected to be magnified 945 within the 3GPP architecture. Some of these limitations are listed 946 below (notice that some of them are also relevant for IPv4 NAT). 947 [NATPTappl] discusses the applicability of NAT-PT in more detail. 949 1. NA(P)T-PT is a single point of failure for all ongoing 950 connections. 952 2. There are additional forwarding delays due to further 953 processing, when compared to normal IP forwarding. 955 3. There are problems with source address selection due to the 956 inclusion of a DNS ALG on the same node [NATPT-DNS]. 958 4. NA(P)T-PT does not work (without application level gateways) 959 for applications that embed IP addresses in their payload. 961 5. NA(P)T-PT breaks DNSSEC. 963 6. NA(P)T-PT does not scale very well in large networks. 965 3GPP networks are expected to handle a very large number of 966 subscribers on a single GGSN (default router). Each GGSN is 967 expected to handle hundreds of thousands of connections. 968 Furthermore, high reliability is expected for 3GPP networks. 969 Consequently, a single point of failure on the GGSN external 970 interface would raise concerns on the overall network reliability. 971 In addition, IPv6 users are expected to use delay-sensitive 972 applications provided by IMS. Hence, there is a need to minimize 973 forwarding delays within the IP backbone. Furthermore, due to the 974 unprecedented number of connections handled by the default routers 975 (GGSN) in 3GPP networks, a network design that forces traffic to go 976 through a single node at the edge of the network (typical NA(P)T-PT 977 configuration) is not likely to scale. Translation mechanisms 978 should allow for multiple translators, for load sharing and 979 redundancy purposes. 981 To minimize the problems associated with NA(P)T-PT, the following 982 actions can be recommended: 984 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to 985 IPv4" case). 987 2. Ensure (if possible) that NA(P)T-PT does not become a single 988 point of failure. 990 3. Allow for load sharing between different translators. That is, 991 it should be possible for different connections to go through 992 different translators. Note that load sharing alone does not 993 prevent NA(P)T-PT from becoming a single point of failure.