idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-05.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.) ** 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 240: '...rsive DNS server SHOULD be either IPv4...' RFC 2119 keyword, line 242: '... single DNS zone SHOULD be served by a...' 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 (September 2003) is 7523 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 675, but not defined == Unused Reference: 'RFC2663' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'RFC2283' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'DHCP-SL' is defined on line 836, 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 2283 (Obsoleted by RFC 2858) -- 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-00 == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-ipv6-transport-guidelines-00 == Outdated reference: A later version (-01) exists of draft-lind-v6ops-isp-scenarios-00 Summary: 8 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-05.txt Nokia 4 Expires: March 2004 6 September 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 55 ..............................................................7 56 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 57 ..............................................................9 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. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt...........15 66 8. Intellectual Property Statement..............................15 67 9. Copyright....................................................16 68 10. References..................................................17 69 10.1 Normative...............................................17 70 10.2 Informative.............................................17 71 11. Authors and Acknowledgements................................19 72 12. Editor's Contact Information................................19 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. 83 The transition scenarios are documented in [RFC3574] and this 84 document will further analyze them. The scenarios are divided into 85 two categories: GPRS scenarios and IP Multimedia Subsystem (IMS) 86 scenarios. 88 GPRS scenarios are the following: 89 - Dual Stack UE connecting to IPv4 and IPv6 nodes 90 - IPv6 UE connecting to an IPv6 node through an IPv4 network 91 - IPv4 UE connecting to an IPv4 node through an IPv6 network 92 - IPv6 UE connecting to an IPv4 node 93 - IPv4 UE connecting to an IPv6 node 95 IMS scenarios are the following: 96 - UE connecting to a node in an IPv4 network through IMS 97 - Two IMS islands connected via IPv4 network 99 The focus is on analyzing different transition scenarios, 100 applicable transition mechanisms and finding solutions for those 101 transition scenarios. In the scenarios, the User Equipment (UE) 102 connects to nodes in other networks, e.g. in the Internet and 103 IPv6/IPv4 transition mechanisms are needed. 105 1.1 Scope of this Document 107 The scope of this Best Current Practices document is to analyze and 108 solve the possible transition scenarios in the 3GPP defined GPRS 109 network where a UE connects to, or is contacted from, the Internet 110 or another UE. The document covers scenarios with and without the 111 use of the SIP based IP Multimedia Core Network Subsystem (IMS). 112 This document does not focus on radio interface issues; both 3GPP 113 Second (GSM) and Third Generation (UMTS) radio network 114 architectures will be covered by these scenarios. 116 The transition mechanisms specified by the IETF Ngtrans and v6ops 117 Working Groups shall be used. This document shall not specify any 118 new transition mechanisms, but if a need for a new mechanism is 119 found, that will be reported to the IETF v6ops Working Group. 121 1.2 Abbreviations 123 2G Second Generation Mobile Telecommunications, for 124 example GSM and GPRS technologies. 125 3G Third Generation Mobile Telecommunications, for example 126 UMTS technology. 127 3GPP Third Generation Partnership Project 128 ALG Application Level Gateway 129 APN Access Point Name. The APN is a logical name referring 130 to a GGSN and an external network. 131 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 132 DNS Domain Name System 133 EGP Exterior Gateway Protocol 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 IGP Interior Gateway Protocol 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 OTA Over The Air 147 PCO-IE Protocol Configuration Options Information Element 148 PDP Packet Data Protocol 149 PPP Point-to-Point Protocol 150 SGSN Serving GPRS Support Node 151 SIIT Stateless IP/ICMP Translation Algorithm 152 SIP Session Initiation Protocol 153 UE User Equipment, for example a UMTS mobile handset 154 UMTS Universal Mobile Telecommunications System 156 1.3 Terminology 158 Some terms used in 3GPP transition scenarios and analysis documents 159 are briefly defined here. 161 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both 162 IPv4 and IPv6 stacks. It is capable of activating 163 both IPv4 and IPv6 Packet Data Protocol (PDP) 164 contexts. Dual stack UE may be capable of tunneling. 166 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 167 only capable of activating IPv6 PDP contexts. 169 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 170 only capable of activating IPv4 PDP contexts. 172 IPv4 node IPv4 node is here defined to be IPv4 capable node 173 the UE is communicating with. The IPv4 node can 174 be, for example, an application server or another 175 UE. 177 IPv6 node IPv6 node is here defined to be IPv6 capable node 178 the UE is communicating with. The IPv6 node can 179 be, for example, an application server or another 180 UE. 182 2. Transition Mechanisms and DNS Guidelines 184 This chapter briefly introduces some transition mechanisms 185 specified by the IETF. The applicability of different transition 186 mechanisms to 3GPP networks is discussed in chapters 3 and 4. DNS 187 recommendations related to IPv4/IPv6 transition are briefly 188 summarized in section 2.4. 190 The IPv4/IPv6 transition methods can be divided to: 192 - dual IPv4/IPv6 stack 193 - tunneling 194 - protocol translators 196 2.1 Dual Stack 198 The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider 199 the 3GPP GPRS core network, dual stack implementation in the GGSN 200 enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack 201 and public (global) IP addresses can often access both IPv4 and 202 IPv6 services without additional translators in the network. 204 2.2 Tunneling 206 Tunneling is a transition mechanism that requires dual IPv4/IPv6 207 stack functionality in the encapsulating and decapsulating nodes. 208 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 210 Tunneling can be static or dynamic. Static (configured) tunnels are 211 fixed IPv6 links over IPv4, and they are specified in [RFC2893]. 212 Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where 213 the tunnel endpoints are not configured, i.e. the links are created 214 dynamically. 216 2.3 Protocol Translators 218 A translator can be defined as an intermediate component between a 219 native IPv4 node and a native IPv6 node to enable direct 220 communication between them without requiring any modifications to 221 the end nodes. 223 Header conversion is a translation mechanism. In header conversion, 224 IPv6 packet headers are converted to IPv4 packet headers, or vice 225 versa, and checksums are adjusted or recalculated if necessary. 226 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 227 using SIIT [RFC2765] is an example of such a mechanism. 229 Translators may be needed in some cases when the communicating 230 nodes do not share the same IP version; in others, it may be 231 possible to avoid such communication altogether. Translation can 232 actually happen at Layer 3 (using NAT-like techniques), Layer 4 233 (using a TCP/UDP proxy) or Layer 7 (using application relays). 235 2.4 DNS Guidelines for IPv4/IPv6 Transition 237 [DNStrans] provides guidelines to operate DNS in a mixed world of 238 IPv4 and IPv6 transport. The recommended administrative policies 239 are the following: 240 - every recursive DNS server SHOULD be either IPv4-only or dual 241 stack, 242 - every single DNS zone SHOULD be served by at least one IPv4 243 reachable DNS server. 245 This rules out IPv6-only DNS servers performing full recursion and 246 DNS zones served only by IPv6-only DNS servers. This approach 247 could be revisited if/when translation techniques between IPv4 and 248 IPv6 were to be widely deployed. 250 3. GPRS Transition Scenarios 252 This section discusses the scenarios that might occur when a GPRS 253 UE contacts services or other nodes, e.g. a web server in the 254 Internet. 256 The following scenarios described by [RFC3574] are analyzed here. 257 In all of the scenarios, the UE is part of a network where there is 258 at least one router of the same IP version, i.e. the GGSN, and the 259 UE is connecting to a node in a different network. 261 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 262 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 263 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 264 4) IPv6 UE connecting to an IPv4 node 265 5) IPv4 UE connecting to an IPv6 node 267 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 269 In this scenario, the dual stack UE is capable of communicating 270 with both IPv4 and IPv6 nodes. It is recommended to activate an 271 IPv6 PDP context when communicating with an IPv6 peer node and an 272 IPv4 PDP context when communicating with an IPv4 peer node. If the 273 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE 274 activates the appropriate PDP context depending on the type of 275 application it has started or depending on the address of the peer 276 host it needs to communicate with. If IPv6 PDP contexts are 277 available and "IPv6 in IPv4" tunneling is needed, it is recommended 278 to activate an IPv6 PDP context and perform tunneling in the 279 network. This case is described in more detail in section 3.2. 281 However, the UE may attach to a 3GPP network, in which the Serving 282 GPRS Support Node (SGSN), the GGSN and the Home Location Register 283 (HLR) support IPv4 PDP contexts, but may not support IPv6 PDP 284 contexts. If the 3GPP network does not support IPv6 PDP contexts, 285 and an application on the UE needs to communicate with an IPv6(- 286 only) node, the UE may activate an IPv4 PDP context and encapsulate 287 IPv6 packets in IPv4 packets using a tunneling mechanism. This 288 might happen in very early phases of IPv6 deployment. To generally 289 solve this problem (IPv6 not available in the 3GPP network), this 290 document strongly recommends the 3GPP operators to deploy basic 291 IPv6 support in their GPRS networks, which can in most cases be 292 handled by making software upgrades in the network elements. 294 As a general guideline, IPv6 communication (native or tunneled from 295 the UE) is preferred to IPv4 communication going through IPv4 NATs 296 to the same dual stack peer node. 298 When analyzing a dual stack UE behavior, an application running on 299 a UE can identify whether the endpoint required is an IPv4 or IPv6 300 capable node by examining the address to discover what address 301 family it falls into. Alternatively, if a user supplies a name to 302 be resolved, the DNS may contain records sufficient to identify 303 which protocol should be used to initiate the connection with the 304 endpoint. Since the UE is capable of native communication with both 305 protocols, one of the main concerns of an operator is the correct 306 address space and routing management. The operator must maintain 307 address spaces for both protocols. Public IPv4 addresses are often 308 a scarce resource for the operator and typically it is not possible 309 for a UE to have a globally unique IPv4 address continuously 310 allocated for its use. Use of private IPv4 addresses means use of 311 NATs when communicating with a peer node outside the operator's 312 network. In large networks, NAT systems can become very complex, 313 expensive and difficult to maintain. 315 For DNS recommendations, we refer to section 2.4. 317 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 319 The best solution for this scenario is obtained with tunneling, 320 i.e. "IPv6 in IPv4" tunneling is a requirement. An IPv6 PDP context 321 is activated between the UE and the GGSN. Tunneling is handled in 322 the network, because IPv6 UE is not capable of tunneling (it does 323 not have the dual stack functionality needed for tunneling). The 324 encapsulating node can be the GGSN, the edge router between the 325 border of the operator's IPv6 network and the public Internet, or 326 any other dual stack node within the operator's IP network. The 327 encapsulation (uplink) and decapsulation (downlink) can be handled 328 by the same network element. Typically the tunneling handled by the 329 network elements is transparent to the UEs and IP traffic looks 330 like native IPv6 traffic to them. For the applications, tunneling 331 enables end-to-end IPv6 connectivity. Note that this scenario is 332 comparable to 6bone [6BONE] network operation. 334 "IPv6 in IPv4" tunnels between IPv6 islands can be either static or 335 dynamic. The selection of the type of tunneling mechanism is up to 336 the operator / ISP deployment scenario and only generic 337 recommendations can be given in this document. 339 The following subsections are focused on the usage of different 340 tunneling mechanisms when the peer node is in the operator's 341 network or outside the operator's network. The authors note that 342 where the actual 3GPP network ends and which parts of the network 343 belong to the ISP(s) also depends on the deployment scenario. The 344 authors are not commenting how many ISP functions the 3GPP operator 345 should perform. However, many 3GPP operators are ISPs of some sort 346 themselves. ISP transition scenarios are documented in [ISP-scen]. 348 3.2.1 Tunneling inside the 3GPP Operator's Network 350 Many GPRS operators already have IPv4 backbone networks deployed 351 and they are gradually migrating them while introducing IPv6 352 islands. IPv6 backbones can be considered quite rare in the first 353 phases of the transition. If the 3GPP operator already has IPv6 354 widely deployed in its network, this subsection is not so relevant. 356 In initial IPv6 deployment, where a small number of IPv6 in IPv4 357 tunnels are required to connect the IPv6 islands over the 3GPP 358 operator's IPv4 network, manually configured tunnels can be used. 359 In a 3GPP network, one IPv6 island can contain the GGSN while 360 another island can contain the operator's IPv6 application servers. 361 However, manually configured tunnels can be an administrative 362 burden when the number of islands and therefore tunnels rises. In 363 that case, upgrading parts of the backbone to dual stack may be the 364 simplest choice. The administrative burden could also be mitigated 365 by using automated management tools which are typically necessary 366 to manage large networks anyway. 368 Even a dynamic tunneling mechanism or an IGP/EGP routing protocol 369 based tunneling mechanism can be considered if other methods are 370 not suitable. 372 Connection redundancy should also be noted as an important 373 requirement in 3GPP networks. Static tunnels on their own don't 374 provide a routing recovery solution for all scenarios where an IPv6 375 route goes down. However, they may provide an adequate solution 376 depending on the design of the network and in presence of other 377 router redundancy mechanisms. On the other hand, IGP/EGP based 378 mechanisms can provide redundancy. 380 3.2.2 Tunneling outside the 3GPP Operator's Network 382 This subsection includes the case when the peer node is outside the 383 operator's network. In that case the "IPv6 in IPv4" tunnel starting 384 point can be in the operator's network - encapsulating node can be 385 e.g. the GGSN or the edge router. 387 The case is pretty straightforward if the upstream ISP provides 388 native IPv6 connectivity to the Internet. If there is no native 389 IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" 390 tunnel should be configured from e.g. the GGSN to the dual stack 391 border gateway in order to access the upstream ISP. 393 If the ISP only provides IPv4 connectivity, then the IPv6 traffic 394 initiated from the 3GPP network should be transported tunneled in 395 IPv4 to the ISP. 397 Usage of configured "IPv6 in IPv4" tunneling is recommended. As the 398 number of the tunnels outside of the 3GPP network is limited, no 399 more than a couple of tunnels should be needed. 401 ISP transition scenarios are described in [ISP-scen]. 403 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 405 3GPP networks are expected to support both IPv4 and IPv6 for a long 406 time, on the UE-GGSN link and between the GGSN and external 407 networks. For this scenario, it is useful to split the end-to-end 408 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 409 v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and 410 IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 411 link (PDP context) to connect to the GGSN without the need to 412 communicate over an IPv6 network. 414 Regarding the GGSN-to-v4NODE communication, typically the transport 415 network between the GGSN and external networks will support only 416 IPv4 in the early stages and migrate to dual stack, since these 417 networks are already deployed. Therefore it is not envisaged that 418 tunneling of IPv4 in IPv6 will be required from the GGSN to 419 external IPv4 networks either. In the longer run, 3GPP operators 420 may need to phase out IPv4 UEs and the IPv4 transport network. This 421 would leave only IPv6 UEs. Therefore, overall, the transition 422 scenario involving an IPv4 UE communicating with an IPv4 peer 423 through an IPv6 network is not considered very likely in 3GPP 424 networks. 426 3.4 IPv6 UE Connecting to an IPv4 Node 428 IPv6(-only) nodes can communicate with IPv4(-only) nodes by making 429 use of a translator (e.g. SIIT [RFC2765], NAT-PT [RFC2766]) within 430 the local network. For many applications, application proxies can 431 be appropriate (e.g. HTTP, email relays, etc.). Such applications 432 will not be transparent to the UE. Hence, a flexible mechanism with 433 minimal manual intervention should be used to configure these 434 proxies on IPv6 UEs. Within the 3GPP architecture, application 435 proxies can be placed on the GGSN external interface (Gi), or 436 inside the service network. 438 However, since it is difficult to anticipate all the possible 439 applications, there can be a need for translators that can 440 translate headers independent of the type of application being 441 used. This section describes a solution based on the use of 442 translators, but does not strongly recommend using translators as a 443 general solution. The authors note that NAT-PT applicability 444 statement work is being done in the v6ops wg and that document will 445 be used as a reference in this document. 447 Due to the significant lack of IPv4 addresses in some domains, port 448 multiplexing is likely to be a necessary feature for translators 449 (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the 450 GGSN external (Gi) interface, typically separate from the GGSN. 451 NA(P)T-PT can be installed, for example, on the edge of the 452 operator's network and the public Internet. NA(P)T-PT will 453 intercept DNS requests and other applications that include IP 454 addresses in their payloads, translate the IP header (and payload 455 for some applications if necessary) and forward packets through its 456 IPv4 interface. 458 NA(P)T-PT introduces limitations that are expected to be magnified 459 within the 3GPP architecture. Some of these limitations are listed 460 below (notice that some of them are also relevant for IPv4 NAT). We 461 note here that [v4v6trans] analyzes the issues when translating 462 between IPv4 and IPv6. NAT-PT applicability statement document 463 (currently being written in v6ops wg) will also be used as a 464 reference in this document. 466 1. NA(P)T-PT is a single point of failure for all ongoing 467 connections. 469 2. There are additional forwarding delays due to further 470 processing, when compared to normal IP forwarding. 472 3. There are problems with source address selection due to the 473 inclusion of a DNS ALG on the same node [NATPT-DNS]. 475 4. NA(P)T-PT does not work (without application level gateways) 476 for applications that embed IP addresses in their payload. 478 5. NA(P)T-PT breaks DNSSEC. 480 6. NA(P)T-PT does not scale very well in large networks. 482 3GPP networks are expected to handle a very large number of 483 subscribers on a single GGSN (default router). Each GGSN is 484 expected to handle hundreds of thousands of connections. 485 Furthermore, high reliability is expected for 3GPP networks. 486 Consequently, a single point of failure on the GGSN external 487 interface would raise concerns on the overall network reliability. 488 In addition, IPv6 users are expected to use delay-sensitive 489 applications provided by IMS. Hence, there is a need to minimize 490 forwarding delays within the IP backbone. Furthermore, due to the 491 unprecedented number of connections handled by the default routers 492 (GGSN) in 3GPP networks, a network design that forces traffic to go 493 through a single node at the edge of the network (typical NA(P)T-PT 494 configuration) is not likely to scale. Translation mechanisms 495 should allow for multiple translators, for load sharing and 496 redundancy purposes. 498 To minimize the problems associated with NA(P)T-PT, the following 499 actions can be recommended: 501 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 502 to IPv4" case). 504 2. Ensure (if possible) that NA(P)T-PT does not become a 505 single point of failure. 507 3. Allow for load sharing between different translators. That 508 is, it should be possible for different connections to go 509 through different translators. Note that load sharing alone 510 does not prevent NA(P)T-PT from becoming a single point of 511 failure. 513 3.5 IPv4 UE Connecting to an IPv6 Node 515 The legacy IPv4 nodes are mostly nodes that support the 516 applications that are popular today in the IPv4 Internet: mostly e- 517 mail and web-browsing. These applications will, of course, be 518 supported in the IPv6 Internet of the future. However, the legacy 519 IPv4 UEs are not going to be updated to support the future 520 applications. As these applications are designed for IPv6, and to 521 use the advantages of newer platforms, the legacy IPv4 nodes will 522 not be able to profit from them. Thus, they will continue to 523 support the legacy services. 525 Taking the above into account, the traffic to and from the legacy 526 IPv4 UE is restricted to a few applications. These applications 527 already mostly rely on proxies or local servers to communicate 528 between private address space networks and the Internet. The same 529 methods and technology can be used for IPv4 to IPv6 transition. 531 For DNS recommendations, we refer to section 2.4. 533 4. IMS Transition Scenarios 535 As the IMS is exclusively IPv6, the number of possible transition 536 scenarios is reduced dramatically. The possible IMS scenarios are 537 listed below and analyzed in sections 4.1 and 4.2. 539 1) UE connecting to a node in an IPv4 network through IMS 540 2) Two IMS islands connected over IPv4 network 542 For DNS recommendations, we refer to section 2.4. As DNS traffic is 543 not directly related to the IMS functionality, the recommendations 544 are not in contradiction with the IPv6-only nature of the IMS. 546 4.1 UE Connecting to a Node in an IPv4 Network through IMS 548 This scenario occurs when an IMS UE (IPv6) connects to a node in 549 the IPv4 Internet through the IMS, or vice versa. This happens when 550 the other node is a part of a different system than 3GPP, e.g. a 551 fixed PC, with only IPv4 capabilities. 553 There will probably be few legacy IPv4 nodes in the Internet that 554 will communicate with the IMS UEs. It is assumed that the solution 555 described here is used for limited cases, in which communications 556 with a small number of legacy IPv4 SIP equipment are needed. As the 557 IMS is exclusively IPv6 [3GPP 23.221], translators have to be used 558 in the communication between the IPv6 IMS and legacy IPv4 hosts, 559 i.e. making a dual stack based solution is not feasible. This 560 section aims to give a brief overview on how that interworking can 561 be handled. 563 This section presents higher level details of a solution based on 564 the use of a translator and SIP ALG. [3GPPtr] provides additional 565 information and presents a bit different solution proposal based on 566 SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to 567 solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF 568 SIP wg(s). 570 As control (or signaling) and user (or data) traffic are separated 571 in SIP, and thus, the IMS, the translation of the IMS traffic has 572 to be done on two levels - Session Initiation Protocol (SIP) 574 [RFC3261], and Session Description Protocol (SDP) [RFC2327] 575 [RFC3266] on the one hand (Mm-interface), and on the actual user 576 data traffic level on the other (Mb-interface). 578 SIP and SDP transition has to be made in an SIP/SDP Application 579 Level Gateway. The ALG has to change the IP addresses transported 580 in the SIP messages and the SDP payload of those messages to the 581 appropriate version. In addition, there has to be interoperability 582 for DNS queries; see section 2.4 for details. 584 On the user data transport level, the translation is IPv4-IPv6 585 protocol translation, where the user data traffic transported is 586 translated from IPv6 to IPv4, and vice versa. 588 The legacy IPv4 host's address can be mapped to an IPv6 address for 589 the IMS, and this address is then used within the IMS to route the 590 traffic to the appropriate user traffic translator. This mapping 591 can be done by the SIP/SDP ALG for the SIP traffic. The user 592 traffic translator would do the similar mapping for the user 593 traffic. However, in order to have an IPv4 address for the IMS UE, 594 and to be able to route the user traffic within the legacy IPv4 595 network to the correct translator, there has to be an IPv4 address 596 allocated for the duration of the session from the user traffic 597 translator. The allocation of this address from the user traffic 598 translator has to be done by the SIP/SDP ALG in order for the 599 SIP/SDP ALG to know the correct IPv4 address. This can be achieved 600 by using a protocol for the ALG to do the allocation. 602 +-------------------------------+ +------------+ 603 | +------+ | | +--------+ | 604 | |S-CSCF|---| |SIP ALG | |\ 605 | | +------+ | | +--------+ | \ -------- 606 +-|+ | / | | | | | | 607 | | | +------+ +------+ | | + | -| |- 608 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 609 | | +------+ +------+ | |+----------+| / ------ 610 | |-----------------------------------||Translator||/ 611 +--+ | IPv6 | |+----------+| IPv4 612 UE | | |Interworking| 613 | IP Multimedia CN Subsystem | |Unit | 614 +-------------------------------+ +------------+ 616 Figure 1: UE using IMS to contact a legacy phone 618 Figure 1 shows a possible configuration scenario where the SIP ALG 619 is separated from the CSCFs. The translator can either be set up in 620 a single device with both SIP translation and media translation, or 621 those functionalities can be divided to two different entities with 622 an interface in between. We call the combined network element on 623 the edge of the IPv6-only IMS an "Interworking Unit" in this 624 document. One alternative is to use a suitable subset of NAT-PT 625 [RFC2766] in this network element to take care of the media (user 626 data) IPv4/IPv6 translation. The problems related to NAT-PT are 627 documented in section 3.4. 629 4.2 Two IMS Islands Connected over IPv4 Network 631 At the early stages of IMS deployment, there may be cases where two 632 IMS islands are separated by an IPv4 network such as the legacy 633 Internet. Here both the UEs and the IMS islands are IPv6-only. 634 However, the IPv6 islands are not native IPv6 connected. 636 In this scenario, the end-to-end SIP connections are based on IPv6. 637 The only issue is to make connection between two IPv6-only IMS 638 islands over IPv4 network. This scenario is closely related to GPRS 639 scenario represented in section 3.2. and similar tunneling 640 solutions are applicable also in this scenario. 642 5. About 3GPP UE IPv4/IPv6 Configuration 644 This informative section aims to give a brief overview on the 645 configuration needed in the UE in order to access IP based 646 services. There can also be other application specific settings in 647 the UE that are not described here. 649 To be able to access IPv6 or IPv4 based services, settings need to 650 be done in the UE. The GGSN Access Point has to be defined when 651 using, for example, the web browsing application. One possibility 652 is to use Over The Air (OTA) configuration to configure the GPRS 653 settings. The user can visit the operator WWW page and subscribe 654 the GPRS Access Point settings to his/her UE and receive the 655 settings via Short Message Service (SMS). After the user has 656 accepted the settings and a PDP context has been activated, the 657 user can start browsing. The Access Point settings can also be 658 typed in manually or be pre-configured by the operator or the UE 659 manufacturer. 661 DNS server addresses typically also need to be configured in the 662 UE. In the case of IPv4 type PDP context, the (IPv4) DNS server 663 addresses can be received in the PDP context activation (a control 664 plane mechanism). Same kind of mechanism is also available for 665 IPv6: so-called Protocol Configuration Options Information Element 666 (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible 667 to use [DHCPv6-SL] or [RFC3315] and [DHCP-DNS] for receiving DNS 668 server addresses. The authors note that the general IPv6 DNS 669 discovery problem is being solved by the IETF dnsop Working Group. 670 The DNS server addresses can also be received using OTA 671 configuration, or typed in manually in the UE. 673 When accessing IMS services, the UE needs to know the P-CSCF IPv6 674 address. 3GPP-specific PCO-IE mechanism, or DHCPv6-based mechanism 675 ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. OTA or manual 676 configuration can also be possible. IMS subscriber authentication 677 and registration to the IMS and SIP integrity protection are not 678 discussed here. 680 6. Security Considerations 682 Editor's note: This section may need updating. 684 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and 685 [v4v6trans]. 687 2. The 3GPP specifications do not currently define the usage 688 of DNS Security. They neither disallow the usage of DNSSEC, 689 nor do they mandate it. 691 3. NAT-PT breaks DNSSEC. 693 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt 695 - (Major part of) The issues handled: 696 http://danforsberg.info:8080/draft-ietf-v6ops-3gpp- 697 analysis/index 698 - The only DNS reference now is draft-ietf-dnsop-ipv6-transport- 699 guidelines-00.txt, all DNS discussion is now in section 2.4 700 - Section 5 "About 3GPP UE IPv4/IPv6 Configuration" added 701 - draft-elmalki-v6ops-3gpp-translator put as an informational 702 reference in section 4.1; a recommendation has been added to 703 solve the general SIP/SDP transition problem in SIP wg(s) 704 - NAT64 reference removed 705 - 6to4 references removed 706 - IGP and BGP references removed (expired drafts) 707 - Some abbreviations added 708 - Intellectual Property Statement added 709 - Editorial changes in many sections 711 8. Intellectual Property Statement 713 The IETF takes no position regarding the validity or scope of any 714 intellectual property or other rights that might be claimed to 715 pertain to the implementation or use of the technology described in 716 this document or the extent to which any license under such rights 717 might or might not be available; neither does it represent that it 718 has made any effort to identify any such rights. Information on the 719 IETF's procedures with respect to rights in standards-track and 720 standards-related documentation can be found in BCP-11. Copies of 721 claims of rights made available for publication and any assurances 722 of licenses to be made available, or the result of an attempt made 723 to obtain a general license or permission for the use of such 724 proprietary rights by implementers or users of this specification 725 can be obtained from the IETF Secretariat. 727 The IETF invites any interested party to bring to its attention any 728 copyrights, patents or patent applications, or other proprietary 729 rights which may cover technology that may be required to practice 730 this standard. Please address the information to the IETF Executive 731 Director. 733 9. Copyright 735 The following copyright notice is copied from [RFC2026], Section 736 10.4. It describes the applicable copyright for this document. 738 Copyright (C) The Internet Society September 10, 2003. All Rights 739 Reserved. 741 This document and translations of it may be copied and furnished to 742 others, and derivative works that comment on or otherwise explain 743 it or assist in its implementation may be prepared, copied, 744 published and distributed, in whole or in part, without restriction 745 of any kind, provided that the above copyright notice and this 746 paragraph are included on all such copies and derivative works. 747 However, this document itself may not be modified in any way, such 748 as by removing the copyright notice or references to the Internet 749 Society or other Internet organizations, except as needed for the 750 purpose of developing Internet standards in which case the 751 procedures for copyrights defined in the Internet Standards process 752 must be followed, or as required to translate it into languages 753 other than English. 755 The limited permissions granted above are perpetual and will not be 756 revoked by the Internet Society or its successors or assignees. 758 This document and the information contained herein is provided on 759 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 760 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 761 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 762 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 763 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 765 10. References 767 10.1 Normative 769 [RFC2026] Bradner, S.: The Internet Standards Process -- Revision 770 3, RFC 2026, October 1996. 772 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 773 Translator (NAT) Terminology and Considerations, RFC 2663, August 774 1999. 776 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 777 (SIIT), RFC 2765, February 2000. 779 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 780 - Protocol Translation (NAT-PT), RFC 2766, February 2000. 782 [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for 783 IPv6 Hosts and Routers, RFC 2893, August 2000. 785 [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, 786 RFC 3261, June 2002. 788 [RFC3574] Soininen, J. (editor): Transition Scenarios for 3GPP 789 Networks, RFC 3574, August 2003. 791 [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service 792 (GPRS); Service description; Stage 2 (Release 5)", December 2002. 794 [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements 795 (Release 5)", December 2002. 797 [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem 798 (IMS); Stage 2 (Release 5)", December 2002. 800 [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP 801 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 802 December 2002. 804 [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control 805 Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 807 10.2 Informative 809 [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: 810 Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. 812 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 813 Protocol, RFC 2327, April 1998. 815 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 816 in Session Description Protocol (SDP), June 2002. 818 [RFC3314] Wasserman, M. (editor): Recommendations for IPv6 in 3GPP 819 Standards, September 2002. 821 [RFC3315] Droms, R. et al.: Dynamic Host Configuration Protocol for 822 IPv6 (DHCPv6), July 2003. 824 [RFC3319] Schulzrinne, H., Volz, B.: Dynamic Host Configuration 825 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) 826 Servers, July 2003. 828 [3GPPtr] El Malki K., et al.: "IPv6-IPv4 Translators in 3GPP 829 Networks", June 2003, draft-elmalki-v6ops-3gpp-translator-00.txt, 830 work in progress. 832 [DHCP-DNS] Droms, R. (ed.): "DNS Configuration options for DHCPv6", 833 August 2003, draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, work in 834 progress. 836 [DHCP-SL] Droms, R.: "A Guide to Implementing Stateless DHCPv6 837 Service", April 2003, draft-ietf-dhc-dhcpv6-stateless-00.txt, work 838 in progress. 840 [DNStrans] Durand, A. and Ihren, J.: "DNS IPv6 transport 841 operational guidelines", June 2003, draft-ietf-dnsop-ipv6- 842 transport-guidelines-00.txt, work in progress. 844 [ISP-scen] Lind, M. (Editor): "Scenarios for Introducing IPv6 into 845 ISP Networks", June 2003, draft-lind-v6ops-isp-scenarios-00.txt, 846 work in progress. 848 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", 849 January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work 850 in progress, the draft has expired. 852 [v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.: 853 "Issues when translating between IPv4 and IPv6", January 2003, 854 draft-vanderpol-v6ops-translation-issues-00.txt, work in progress, 855 the draft has expired. 857 [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 858 3 specification; Core network protocols; Stage 3 (Release 5)", June 859 2003. 861 [6BONE] http://www.6bone.net 863 11. Authors and Acknowledgements 865 This document is written by: 867 Alain Durand, Sun Microsystems 868 870 Karim El-Malki, Ericsson Radio Systems 871 873 Niall Richard Murphy, Enigma Consulting Limited 874 876 Hugh Shieh, AT&T Wireless 877 879 Jonne Soininen, Nokia 880 882 Hesham Soliman, Flarion 883 885 Margaret Wasserman, Wind River 886 888 Juha Wiljakka, Nokia 889 891 The authors would like to thank Heikki Almay, Gabor Bajko, Ajay 892 Jain, Jarkko Jouppi, Ivan Laloux, Janne Rinne, Pekka Savola, Pedro 893 Serna, Fred Templin, Anand Thakur and Rod Van Meter for their 894 valuable input. 896 12. Editor's Contact Information 898 Comments or questions regarding this document should be sent to the 899 v6ops mailing list or directly to the document editor: 901 Juha Wiljakka 902 Nokia 903 Visiokatu 3 Phone: +358 7180 48372 904 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com