idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7620 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) == Unused Reference: 'RFC2663' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC2283' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 810, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** 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) ** Obsolete normative reference: RFC 3266 (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-cases (ref. '3GPP-SCEN') -- Obsolete informational reference (is this intentional?): RFC 2283 (Obsoleted by RFC 2858) == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-00 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-ipv6-dns-issues-02 -- Unexpected draft version: The latest known version of draft-many-ngtrans-connect-ipv6-igp is -01, but you're referring to -02. == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-13 == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-00 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 4 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-04.txt Nokia 4 Expires: December 2003 6 June 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......................................... 4 48 2.1 Dual Stack................................................ 5 49 2.2 Tunneling................................................. 5 50 2.3 Protocol Translators...................................... 5 51 3. GPRS Transition Scenarios..................................... 5 52 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes........... 6 53 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 7 54 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 55 ............................................................ 10 56 3.4 IPv6 UE Connecting to an IPv4 Node....................... 10 57 3.5 IPv4 UE Connecting to an IPv6 Node....................... 12 58 4. IMS Transition Scenarios..................................... 13 59 4.1 DNS Interworking in IMS.................................. 13 60 4.2 UE Connecting to a Node in an IPv4 Network through IMS... 13 61 4.3 Two IMS Islands Connected over IPv4 Network.............. 15 62 5. Security Considerations...................................... 16 63 6. Changes from draft-ietf-v6ops-3gpp-analysis-03.txt........... 16 64 7. Copyright.................................................... 16 65 8. References................................................... 17 66 8.1 Normative................................................ 17 67 8.2 Informative.............................................. 18 68 9. Authors and Acknowledgements................................. 19 69 10. Editor's Contact Information................................ 20 71 1. Introduction 73 This document describes and analyzes the process of transition to 74 IPv6 in Third Generation Partnership Project (3GPP) General Packet 75 Radio Service (GPRS) packet networks. The authors can be found in 76 Authors and Acknowledgements section. 78 This document analyzes the transition scenarios in 3GPP packet 79 data networks that might come up in the deployment phase of IPv6. 80 The transition scenarios are documented in [3GPP-SCEN] and this 81 document will further analyze them. The scenarios are divided into 82 two categories: GPRS scenarios and IMS scenarios. 84 GPRS scenarios are the following: 85 - Dual Stack UE connecting to IPv4 and IPv6 nodes 86 - IPv6 UE connecting to an IPv6 node through an IPv4 network 87 - IPv4 UE connecting to an IPv4 node through an IPv6 network 88 - IPv6 UE connecting to an IPv4 node 89 - IPv4 UE connecting to an IPv6 node 91 IMS scenarios are the following: 92 - UE connecting to a node in an IPv4 network through IMS 93 - Two IMS islands connected via IPv4 network 95 The focus is on analyzing different transition scenarios, 96 applicable transition mechanisms and finding solutions for those 97 transition scenarios. In the scenarios, the User Equipment (UE) 98 connects to nodes in other networks, e.g. in the Internet and 99 IPv6/IPv4 transition mechanisms are needed. 101 1.1 Scope of this Document 103 The scope of this informational document is to analyze and solve 104 the possible transition scenarios in the 3GPP defined GPRS network 105 where a UE connects to, or is contacted from the Internet, or 106 another UE. The document covers scenarios with and without the use 107 of the SIP based IP Multimedia Core Network Subsystem (IMS). This 108 document is not focused on radio interface issues; both 3GPP Second 109 (GSM) and Third Generation (UMTS) radio network architectures will 110 be covered by these scenarios. 112 The transition mechanisms specified by the IETF Ngtrans and v6ops 113 Working Groups shall be used. This document shall not specify any 114 new transition mechanisms, but if a need for a new mechanism is 115 found, that will be reported to the v6ops Working Group. 117 1.2 Abbreviations 119 2G Second Generation Mobile Telecommunications, for 120 example GSM and GPRS technologies. 121 3G Third Generation Mobile Telecommunications, for example 122 UMTS technology. 123 3GPP Third Generation Partnership Project 124 ALG Application Level Gateway 125 APN Access Point Name. The APN is a logical name referring 126 to a GGSN and an external network. 127 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 128 GGSN Gateway GPRS Support Node (a default router for 3GPP 129 User Equipment) 130 GPRS General Packet Radio Service 131 GSM Global System for Mobile Communications 132 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 133 IPv6-only part of the network 134 ISP Internet Service Provider 135 NAT Network Address Translator 136 NAPT-PT Network Address Port Translation - Protocol Translation 137 NAT-PT Network Address Translation - Protocol Translation 138 PDP Packet Data Protocol 139 PPP Point-to-Point Protocol 140 SIIT Stateless IP/ICMP Translation Algorithm 141 SIP Session Initiation Protocol 142 UE User Equipment, for example a UMTS mobile handset 143 UMTS Universal Mobile Telecommunications System 145 1.3 Terminology 147 Some terms used in 3GPP transition scenarios and analysis documents 148 are briefly defined here. 150 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual 151 stack implemented. It is capable of activating 152 both IPv4 and IPv6 PDP contexts. Dual stack UE may 153 be capable of tunneling. 155 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 156 only capable of activating IPv6 PDP contexts. 158 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 159 only capable of activating IPv4 PDP contexts. 161 IPv4 node IPv4 node is here defined to be IPv4 capable node 162 the UE is communicating with. The IPv4 node can 163 be, for example, an application server or another 164 UE. 166 IPv6 node IPv6 node is here defined to be IPv6 capable node 167 the UE is communicating with. The IPv6 node can 168 be, for example, an application server or another 169 UE. 171 2. Transition Mechanisms 173 This chapter briefly introduces some transition mechanisms 174 specified by the IETF. Applicability of different transition 175 mechanisms to 3GPP networks is discussed in chapters 3 and 4. 177 The IPv4/IPv6 transition methods can be divided to: 179 - dual IPv4/IPv6 stack 180 - tunneling 181 - protocol translators 183 2.1 Dual Stack 185 The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider 186 the 3GPP GPRS core network, dual stack implementation in the GGSN 187 enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack 188 and public (global) IP addresses can often access both IPv4 and 189 IPv6 services without additional translators in the network. 191 2.2 Tunneling 193 Tunneling is a transition mechanism that requires dual IPv4/IPv6 194 stack functionality in the encapsulating and decapsulating nodes. 195 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 197 Tunneling can be static or dynamic. Static (configured) tunnels are 198 fixed IPv6 links over IPv4, and they are specified in [RFC2893]. 199 Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where 200 the tunnel endpoints are not configured, i.e. the links are created 201 dynamically. 203 2.3 Protocol Translators 205 A translator can be defined as an intermediate component between a 206 native IPv4 node and a native IPv6 node to enable direct 207 communication between them without requiring any modifications to 208 the end nodes. 210 Header conversion is a translation mechanism. In header conversion, 211 IPv6 packet headers are converted to IPv4 packet headers, or vice 212 versa, and checksums are adjusted or recalculated if necessary. 213 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 214 using SIIT [RFC2765] is an example of such a mechanism. 216 Translators are typically needed when the two communicating nodes 217 do not share the same IP version. Translation can actually happen 218 at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP 219 proxy) or Layer 7 (using application relays). 221 3. GPRS Transition Scenarios 223 This section discusses the scenarios that might occur when a GPRS 224 UE contacts services or other nodes, e.g. a web server in the 225 Internet. 227 The following scenarios described by [3GPP-SCEN] are analyzed here. 228 In all of the scenarios, the UE is part of a network where there is 229 at least one router of the same IP version, i.e. GGSN, and it is 230 connecting to a node in a different network. 232 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 233 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 234 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 235 4) IPv6 UE connecting to an IPv4 node 236 5) IPv4 UE connecting to an IPv6 node 238 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 240 In this scenario, the dual stack UE is capable of communicating 241 with both IPv4 and IPv6 nodes. It is recommended to activate an 242 IPv6 PDP context when communicating with an IPv6 peer node and an 243 IPv4 PDP context when communicating with an IPv4 peer node. If the 244 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE 245 activates the appropriate PDP context depending on the type of 246 application it has started or depending on the address of the peer 247 host it needs to communicate with. If IPv6 PDP contexts are 248 available and "IPv6 in IPv4" tunneling is needed, it is recommended 249 to activate an IPv6 PDP context and perform tunneling in the 250 network. This case is described in more detail in section 3.2. 252 However, the UE may attach to a 3GPP network, in which the SGSN 253 (Serving GPRS Support Node), the GGSN and the HLR (Home Location 254 Register) support IPv4 PDP contexts by default, but may not support 255 IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP 256 contexts, and an application on the UE needs to communicate with an 257 IPv6(-only) node, the UE may activate an IPv4 PDP context and 258 encapsulate IPv6 packets in IPv4 packets using a tunneling 259 mechanism. This might happen in very early phases of IPv6 260 deployment, or in IPv6 demonstrations and trials. 262 The UE may be assigned a private or public IPv4 address when the 263 IPv4 PDP context has been activated, although it is more likely 264 that it will receive a private address (due to the lack of public 265 IPv4 addresses). The use of private IPv4 addresses in the UE 266 depends on the support of these addresses by the tunneling 267 mechanism and the deployment scenario. In some cases, public IPv4 268 addresses are required (one example is 6to4 [RFC3056]), but if the 269 tunnel endpoints are in the same private domain or the tunneling 270 mechanism works through IPv4 NAT (Network Address Translator), 271 private IPv4 addresses can be used (examples are [ISATAP] and 272 [TEREDO]). In general, if tunneling from the host is needed, ISATAP 273 and 6to4 are preferred and TEREDO is a mechanism of last resort 274 when neither of these are applicable. 276 One deployment scenario example is using laptop computer and a UMTS 277 UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the 278 laptop computer and an IPv4 PDP context is activated. Although 279 "IPv6 in IPv4" tunneling can be either automatic or configured (by 280 the user), the first alternative is favored, because it is expected 281 that most UE users just want to use an application in their UE; 282 they might not even care, whether the network connection is IPv4 or 283 IPv6. 285 As a general guideline, IPv6 communication (native or tunneled from 286 the UE) is preferred to IPv4 communication going through IPv4 NATs 287 to the same dual stack peer node. In this scenario, the UE talks to 288 the DNS resolver using the IP version that is available via the 289 activated PDP context. 291 When analyzing a dual stack UE behavior, an application running on 292 a UE can identify whether the endpoint required is an IPv4 or IPv6 293 capable node by examining the address to discover what address 294 family category it falls into. Alternatively, if a user supplies a 295 name to be resolved, the DNS may contain records sufficient to 296 identify which protocol should be used to initiate the connection 297 with the endpoint. Since the UE is capable of native communication 298 with both protocols, one of the main concerns of an operator is 299 correct address space and routing management. The operator must 300 maintain address spaces for both protocols. Public IPv4 addresses 301 are often a scarce resource for the operator and typically it is 302 not possible for a UE to have a globally unique IPv4 address 303 continuously allocated for its use. Use of private IPv4 addresses 304 means use of NATs when communicating with a peer node outside the 305 operator's network. In large networks, NAT systems can become very 306 complex, expensive and difficult to maintain. 308 Keeping the Internet name space unfragmented is another important 309 issue for both IPv4 and IPv6. It means that any record in the 310 public Internet should be available unmodified to any nodes, IPv4 311 or IPv6, regardless of the transport being used. The recommended 312 approach is the following: every recursive DNS server should be 313 either IPv4-only or dual stack and every single DNS zone should be 314 served by at least an IPv4 reachable DNS server. This 315 recommendation rules out IPv6-only recursive DNS servers and DNS 316 zones served by IPv6-only DNS servers, and this approach could be 317 revisited if translation techniques between IPv4 and IPv6 were to 318 be widely deployed [DNStrans]. 320 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 322 The best solution for this scenario is obtained with tunneling, 323 i.e. "IPv6 in IPv4" tunneling is a requirement. An IPv6 PDP context 324 is activated between the UE and the GGSN. Tunneling is handled in 325 the network, because IPv6 UE is not capable of tunneling (it does 326 not have the dual stack functionality needed for tunneling). The 327 encapsulating node can be the GGSN, the edge router between the 328 border of the operator's IPv6 network and the public Internet, or 329 any other dual stack node within the operator's IP network. The 330 encapsulation (uplink) and decapsulation (downlink) can be handled 331 by the same network element. Typically the tunneling handled by the 332 network elements is transparent to the UEs and IP traffic looks 333 like native IPv6 traffic to them. For the applications, tunneling 334 enables end-to-end IPv6 connectivity. Note that this scenario is 335 comparable to 6bone [6BONE] network operation. 337 "IPv6 in IPv4" tunnels between IPv6 islands can be either static or 338 dynamic. The selection of the type of tunneling mechanism is up to 339 the operator / ISP deployment scenario and only generic 340 recommendations can be given in this document. 342 The following subsections are focused on the usage of different 343 tunneling mechanisms when the peer node is in the operator's 344 network or outside the operator's network. The authors note that 345 where the actual 3GPP network ends and which parts of the network 346 belong to the ISP(s) also depends on the deployment scenario. The 347 authors are not commenting how many ISP functions the 3GPP operator 348 should perform. However, many 3GPP operators are ISPs of some sort 349 themselves. ISP transition scenarios are documented and analyzed in 350 [ISP-scen], [ISP-analysis] and their future updates. 352 3.2.1 Tunneling inside the 3GPP Operator's Network 354 Many GPRS operators already have IPv4 backbone networks deployed 355 and they are gradually migrating them while introducing IPv6 356 islands. IPv6 backbones can be considered quite rare in the first 357 phases of the transition. If the 3GPP operator already has IPv6 358 widely deployed in its network, this subsection is not so relevant. 360 In initial, smaller scale IPv6 deployment, where a small number of 361 IPv6 in IPv4 tunnels are required to connect the IPv6 islands over 362 the 3GPP operator's IPv4 network, manually configured tunnels can 363 be used. In a 3GPP network, one IPv6 island could contain the GGSN 364 while another island contains the operator's IPv6 application 365 servers. However, manually configured tunnels can be an 366 administrative burden when the number of islands and therefore 367 tunnels rises. In that case, upgrading parts of the backbone to 368 dual stack may be the simplest choice. The administrative burden 369 could also be mitigated by using automated management tools which 370 are typically necessary to manage large networks anyway. 372 Even a dynamic tunneling mechanism, such as "6to4" [RFC3056] or an 373 IGP/EGP routing protocol based tunneling mechanism [BGP][IGP], 374 could be used if other methods are not suitable. Routing protocol 375 based mechanisms such as [BGP] consist of running BGP between the 376 neighboring router tunnel endpoints and using multi-protocol BGP 377 extensions to exchange reachability information of IPv6 prefixes. 379 The routers use this information to create IPv6 in IPv4 tunnel 380 interfaces and route IPv6 packets over the IPv4 network. It is 381 possible to combine this with different types of tunnels. 383 Connection redundancy should also be noted as an important 384 requirement in 3GPP networks. Static tunnels on their own don't 385 provide a routing recovery solution for all scenarios where an IPv6 386 route goes down. However, they may provide an adequate solution 387 depending on the design of the network and in presence of other 388 router redundancy mechanisms. On the other hand, IGP/EGP based 389 mechanisms can provide redundancy. 391 "6to4" nodes use special IPv6 addresses with a "6to4" prefix 392 containing the IPv4 address of the corresponding "IPv6 in IPv4" 393 tunnel endpoint ("6to4" router) which performs encapsulation / 394 decapsulation. When connecting two nodes with "6to4" addresses, the 395 corresponding "6to4" routers use the IPv4 addresses specified in 396 the "6to4" prefixes to tunnel IPv6 packets through the IPv4 397 network. But if only one of them has a "6to4" address, a "6to4" 398 relay must be present to perform the missing "6to4" router 399 functionality for the native-IPv6 node. If we consider the "6to4" 400 tunneling mechanism and the 3GPP addressing model (a unique /64 401 prefix allocated for each primary PDP context), a /48 "6to4" prefix 402 would only be enough for approximately 65000 UEs. Thus, a few 403 public IPv4 addresses would be needed depending on the size of the 404 operator. 406 3.2.2 Tunneling outside the 3GPP Operator's Network 408 This subsection includes the case when the peer node is outside the 409 operator's network. In that case the "IPv6 in IPv4" tunnel starting 410 point can be in the operator's network - encapsulating node can be 411 e.g. the GGSN or the edge router. 413 The case is pretty straightforward if the upstream ISP provides 414 native IPv6 connectivity to the Internet. If there is no native 415 IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" 416 tunnel should be configured from e.g. the GGSN to the dual stack 417 border gateway in order to access the upstream ISP. 419 If the ISP only provides IPv4 connectivity, then the IPv6 traffic 420 initiated from the 3GPP network should be transported tunneled in 421 IPv4 to the ISP. Defining the tunnel endpoint depends on the 422 deployment scenario. The authors want to avoid duplicating work and 423 note here that the ISP transition scenarios are analyzed in [ISP- 424 scen] and [ISP-analysis]. 426 Usage of manually configured "IPv6 in IPv4" tunneling is sensible 427 if the number of the tunnels can be kept limited. It is assumed 428 that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the 429 3GPP network towards the ISP / Internet should be sufficient. 431 On the other hand, usage of dynamic tunneling, such as "6to4", can 432 also be considered, but scalability problems arise when thinking 433 about the great number of UEs in the 3GPP networks. The specific 434 limitation when applying "6to4" in 3GPP networks should also be 435 taken into account, as commented in 3.2.1. Other issues to keep in 436 mind with respect to the "6to4" mechanism are that reverse DNS is 437 not yet completely solved and there are some security 438 considerations associated with the use of "6to4" relay routers (see 439 [6to4SEC]). Moreover, in a later phase of the transition period, 440 there will be a need for assigning new, native IPv6 addresses to 441 all "6to4" nodes in order to enable native IPv6 connectivity. 443 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 445 3GPP networks are expected to support both IPv4 and IPv6 for a long 446 time, on the UE-GGSN link and between the GGSN and external 447 networks. For this scenario it is useful to split the end-to-end 448 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 449 v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and 450 IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 451 link (PDP context) to connect to the GGSN without the need to 452 communicate over an IPv6 network. Regarding the GGSN-to-v4NODE 453 communication, typically the transport network between the GGSN and 454 external networks will support only IPv4 in the early stages and 455 migrate to dual stack, since these networks are already deployed. 456 Therefore it is not envisaged that tunneling of IPv4 in IPv6 will 457 be required from the GGSN to external IPv4 networks either. In the 458 longer run, 3GPP operators may need to phase out IPv4 UEs and the 459 IPv4 transport network. This would leave only IPv6 UEs. Therefore, 460 overall, the transition scenario involving an IPv4 UE communicating 461 with an IPv4 peer through an IPv6 network is not considered very 462 likely in 3GPP networks. 464 3.4 IPv6 UE Connecting to an IPv4 Node 466 IPv6 nodes can communicate with IPv4 hosts by making use of a 467 translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local 468 network. For some applications, application proxies can be 469 appropriate (e.g. HTTP, email relays, etc.). Such applications will 470 not be transparent to the UE. Hence, a flexible mechanism with 471 minimal manual intervention should be used to configure these 472 proxies on IPv6 UEs. Within the 3GPP architecture, application 473 proxies can be placed on the GGSN external interface (Gi), or 474 inside the service network. 476 However, since it is difficult to anticipate all possible 477 applications, there is a need for translators that can translate 478 headers independent of the type of application being used. 480 Due to the significant lack of IPv4 addresses in some domains, port 481 multiplexing is likely to be a necessary feature for translators 482 (i.e. NAPT-PT). 484 When NA(P)T-PT is used, it needs to be placed on the GGSN external 485 (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be 486 installed, for example, on the edge of the operator's network and 487 the public Internet. NA(P)T-PT will intercept DNS requests and 488 other applications that include IP addresses in their payloads, 489 translate the IP header (and payload for some applications if 490 necessary) and forward packets through its IPv4 interface. 492 NA(P)T-PT introduces limitations that are expected to be magnified 493 within the 3GPP architecture. Some of these limitations are listed 494 below (notice that some of them are also relevant for IPv4 NAT). We 495 note here that [v4v6trans] analyzes the issues when translating 496 between IPv4 and IPv6. However, the NAT-PT issues should be clearly 497 documented in an RFC in the v6ops Working Group and a decision 498 should be made, whether revisiting the NAT-PT RFC is necessary / 499 what kind of update is needed. 501 1. NA(P)T-PT is a single point of failure for all ongoing 502 connections. 504 2. Additional forwarding delays due to further processing, when 505 compared to normal IP forwarding. 507 3. Problems with source address selection due to the inclusion of 508 a DNS ALG on the same node [NATPT-DNS]. 510 4. NA(P)T-PT does not work (without application level gateways) 511 for applications that embed IP addresses in their payload. 513 5. NA(P)T-PT breaks DNSSEC. 515 6. NA(P)T-PT does not scale very well in large networks. 517 3GPP networks are expected to handle a very large number of 518 subscribers on a single GGSN (default router). Each GGSN is 519 expected to handle hundreds of thousands of connections. 520 Furthermore, high reliability is expected for 3GPP networks. 521 Consequently, a single point of failure on the GGSN external 522 interface, would raise concerns on the overall network reliability. 523 In addition, IPv6 users are expected to use delay-sensitive 524 applications provided by IMS. Hence, there is a need to minimize 525 forwarding delays within the IP backbone. Furthermore, due to the 526 unprecedented number of connections handled by the default routers 527 (GGSN) in 3GPP networks, a network design that forces traffic to go 528 through a single node at the edge of the network (typical NA(P)T-PT 529 configuration) is not likely to scale. Translation mechanisms 530 should allow for multiple translators, for load sharing and 531 redundancy purposes. 533 To minimize the problems associated with NA(P)T-PT, the following 534 actions can be recommended: 536 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 537 to IPv4" case). 539 2. Ensure (if possible) that NA(P)T-PT does not become a 540 single point of failure. 542 3. Allow for load sharing between different translators. That 543 is, it should be possible for different connections to go 544 through different translators. Note that load sharing alone 545 does not prevent NA(P)T-PT from becoming a single point of 546 failure. 548 There are some ways to fix the problems with NA(P)T-PT, one 549 suggestion is [NAT64]. 551 When thinking the DNS issues, the IPv6 UE needs to find the IPv4 552 address in the DNS [DNStrans]. Note that DNSSEC is broken if 553 NA(P)T-PT is used. 555 3.5 IPv4 UE Connecting to an IPv6 Node 557 The legacy IPv4 nodes are mostly nodes that support the 558 applications that are popular today in the IPv4 Internet: mostly e- 559 mail, and web-browsing. These applications will, of course, be 560 supported in the IPv6 Internet of the future. However, the legacy 561 IPv4 UEs are not going to be updated to support the future 562 applications. As these application are designed for IPv6, and to 563 use the advantages of newer platforms, the legacy IPv4 nodes will 564 not be able to profit from them. Thus, they will continue to 565 support the legacy services. 567 Taking the above into account, the traffic to and from the legacy 568 IPv4 UE is restricted to a few applications. These applications 569 already today mostly rely on proxies or local servers to 570 communicate between private address space networks and the 571 Internet. The same methods and technology can be used for IPv4 to 572 IPv6 transition. 574 An alternative solution could be a general network address 575 translation mechanisms such as NAT46 [NAT64]. 577 When thinking the DNS issues, the DNS zones containing AAAA records 578 for the IPv6 nodes need to be served by at least one IPv4 579 accessible DNS server [DNStrans]. 581 4. IMS Transition Scenarios 583 As the IMS is exclusively IPv6, the number of possible transition 584 scenarios is reduced dramatically. In the following, the possible 585 transition scenarios are listed. Those scenarios are analyzed in 586 sections 4.2 and 4.3. 588 1) UE connecting to a node in an IPv4 network through IMS 589 2) Two IMS islands connected over IPv4 network 591 4.1 DNS Interworking in IMS 593 The recommended approach (as documented in [DNStrans]) currently is 594 that every recursive DNS server should be either IPv4-only or dual 595 stack and every single DNS zone should be served by at least an 596 IPv4 reachable DNS server. The recommendation rules out IPv6-only 597 recursive DNS servers and DNS zones served by IPv6-only DNS 598 servers. 600 To perform DNS resolution in the IMS, the UE can be configured as a 601 stub resolver pointing to a recursive DNS resolver. This 602 communication can happen over IPv6. However, in the process to find 603 the IPv6 address of a SIP server, the recursive DNS resolver may 604 need to access data that is available only on some IPv4 DNS 605 servers, see [DNStrans]. One way to achieve this is to make the DNS 606 resolver be dual stack. As DNS traffic is not directly related to 607 the IMS functionality, this is not in contradiction with the IPv6- 608 only nature of the IMS. 610 4.2 UE Connecting to a Node in an IPv4 Network through IMS 612 This scenario occurs when an IMS UE (IPv6) connects to a node in 613 the IPv4 Internet through the IMS, or vice versa. This happens when 614 the other node is a part of a different system than 3GPP, e.g. a 615 fixed PC, with only IPv4 capabilities. 617 There will probably be few legacy IPv4 nodes in the Internet that 618 will communicate with the IMS UEs. It is assumed that the solution 619 described here is used for limited cases, in which communications 620 with a small number of legacy IPv4 SIP equipment are needed. As the 621 IMS is exclusively IPv6 [3GPP 23.221], translators have to be used 622 in the communication between the IPv6 IMS and legacy IPv4 hosts, 623 i.e. making a dual stack based solution is not feasible. This 624 section aims to give a brief overview on how that interworking can 625 be handled. 627 As control (or signaling) and user (or data) traffic are separated 628 in SIP, and thus, the IMS, the translation of the IMS traffic has 629 to be done on two levels - Session Initiation Protocol (SIP) 630 [RFC3261], and Session Description Protocol (SDP) [RFC2327] 631 [RFC3266] on the one hand (Mm-interface), and on the actual user 632 data traffic level on the other (Mb-interface). 634 SIP and SDP transition has to be made in an SIP/SDP Application 635 Level Gateway. The ALG has to change the IP addresses transported 636 in the SIP messages and the SDP payload of those messages to the 637 appropriate version. In addition, there has to be interoperability 638 for DNS queries; see section 4.1 for details. 640 On the user data transport level, the translation is IPv4-IPv6 641 protocol translation, where the user data traffic transported is 642 translated from IPv6 to IPv4, and vice versa. 644 The legacy IPv4 host's address can be mapped to an IPv6 address for 645 the IMS, and this address is then used within the IMS to route the 646 traffic to the appropriate user traffic translator. This mapping 647 can be done by the SIP/SDP ALG for the SIP traffic. The user 648 traffic translator would do the similar mapping for the user 649 traffic. However, in order to have an IPv4 address for the IMS UE, 650 and to be able to route the user traffic within the legacy IPv4 651 network to the correct translator, there has to be an IPv4 address 652 allocated for the duration of the session from the user traffic 653 translator. The allocation of this address from the user traffic 654 translator has to be done by the SIP/SDP ALG in order for the 655 SIP/SDP ALG to know the correct IPv4 address. This can be achieved 656 by using a protocol for the ALG to do the allocation. 658 +-------------------------------+ +------------+ 659 | +------+ | | +--------+ | 660 | |S-CSCF|---| |SIP ALG | |\ 661 | | +------+ | | +--------+ | \ -------- 662 +-|+ | / | | | | | | 663 | | | +------+ +------+ | | + | -| |- 664 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 665 | | +------+ +------+ | |+----------+| / ------ 666 | |-----------------------------------||Translator||/ 667 +--+ | IPv6 | |+----------+| IPv4 668 UE | | |Interworking| 669 | IP Multimedia CN Subsystem | |Unit | 670 +-------------------------------+ +------------+ 672 Figure 1: UE using IMS to contact a legacy phone 674 Figure 1 shows a possible configuration scenario where the SIP ALG 675 is separate to the CSCFs. The translator can either be set up in a 676 single device with both SIP translation and media translation, or 677 those functionalities can be divided to two different entities with 678 an interface in between. We call the combined network element on 679 the edge of the IPv6-only IMS an "Interworking Unit" in this 680 document. One alternative is to use a suitable subset of NAT-PT 681 [RFC2766] in this network element to take care of the media (user 682 data) IPv4/IPv6 translation. The problems related to NAT-PT are 683 documented in section 3.4. 685 The authors notify that work is being done on analyzing 3GPP 686 IPv4/IPv6 translators related to IMS scenario 1, and a personal 687 draft is expected shortly. 689 4.3 Two IMS Islands Connected over IPv4 Network 691 At the early stages of IMS deployment, there may be cases where two 692 IMS islands are separated by an IPv4 network such as the legacy 693 Internet. Here both the UEs and the IMS islands are IPv6-only. 694 However, the IPv6 islands are not native IPv6 connected. 696 In this scenario, the end-to-end SIP connections are based on IPv6. 697 The only issue is to make connection between two IPv6-only IMS 698 islands over IPv4 network. This scenario is closely related to GPRS 699 scenario represented in section 3.2. and similar tunneling 700 solutions are applicable also in this scenario. 702 5. Security Considerations 704 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and 705 [v4v6trans]. 707 2. The 3GPP specifications do not currently define the usage 708 of DNS Security. They neither disallow the usage of DNSSEC, 709 nor do they mandate it. 711 3. NAT-PT breaks DNSSEC. 713 6. Changes from draft-ietf-v6ops-3gpp-analysis-03.txt 715 - Tunneling text in 2.2 shortened 716 - Text changes in 3.1 717 - Text changes in 3.2 718 - Text changes in 4.2 719 - Editorial changes in some sections 721 7. Copyright 723 The following copyright notice is copied from [RFC2026], Section 724 10.4. It describes the applicable copyright for this document. 726 Copyright (C) The Internet Society June 13, 2003. All Rights 727 Reserved. 729 This document and translations of it may be copied and furnished to 730 others, and derivative works that comment on or otherwise explain 731 it or assist in its implementation may be prepared, copied, 732 published and distributed, in whole or in part, without restriction 733 of any kind, provided that the above copyright notice and this 734 paragraph are included on all such copies and derivative works. 735 However, this document itself may not be modified in any way, such 736 as by removing the copyright notice or references to the Internet 737 Society or other Internet organizations, except as needed for the 738 purpose of developing Internet standards in which case the 739 procedures for copyrights defined in the Internet Standards process 740 must be followed, or as required to translate it into languages 741 other than English. 743 The limited permissions granted above are perpetual and will not be 744 revoked by the Internet Society or its successors or assignees. 746 This document and the information contained herein is provided on 747 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 748 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 749 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 750 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 751 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 753 8. References 755 8.1 Normative 757 [RFC2026] Bradner, S.: The Internet Standards Process -- Revision 758 3, RFC 2026, October 1996. 760 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 761 Protocol, RFC 2327, April 1998. 763 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 764 Translator (NAT) Terminology and Considerations, RFC 2663, August 765 1999. 767 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 768 (SIIT), RFC 2765, February 2000. 770 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 771 - Protocol Translation (NAT-PT), RFC 2766, February 2000. 773 [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for 774 IPv6 Hosts and Routers, RFC 2893, August 2000. 776 [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via 777 IPv4 Clouds, RFC 3056, February 2001. 779 [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, 780 June 2002. 782 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 783 in Session Description Protocol (SDP), June 2002. 785 [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP 786 Networks", March 2003, draft-ietf-v6ops-3gpp-cases-03.txt, work in 787 progress. 789 [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service 790 (GPRS); Service description; Stage 2 (Release 5)", December 2002. 792 [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements 793 (Release 5)", December 2002. 795 [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem 796 (IMS); Stage 2 (Release 5)", December 2002. 798 [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP 799 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 800 December 2002. 802 [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control 803 Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 805 8.2 Informative 807 [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: 808 Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. 810 [RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP 811 Standards", September 2002. 813 [6to4SEC] Savola, P.: "Security Considerations for 6to4", January 814 2003, draft-savola-v6ops-6to4-security-02.txt, work in progress. 816 [BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le 817 Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with 818 BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in 819 progress, the draft has expired. 821 [DNStrans] Durand, A. and Ihren, J.: "IPv6 DNS transition issues", 822 February 2003, draft-ietf-dnsop-ipv6-dns-issues-02.txt, work in 823 progress. 825 [IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica, 826 C., Baudot, A., Diribarne, G.: "Connecting IPv6 islands within an 827 IPv4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp- 828 02.txt, work in progress, the draft has expired. 830 [ISATAP] Templin, F., et al.: "Intra-Site Automatic Tunnel 831 Addressing Protocol (ISATAP)", March 2003, draft-ietf-ngtrans- 832 isatap-13.txt, work in progress. 834 [ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP 835 Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work 836 in progress. 838 [ISP-analysis] Mickles, C. (Editor): "Transition Analysis for ISP 839 Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.txt, 840 work in progress. 842 [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- 843 ngtrans-nat64-nat46-00.txt, work in progress, the draft has 844 expired. 846 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", 847 January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work 848 in progress. 850 [TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP through 851 NATs", June 2003, draft-huitema-v6ops-teredo-00.txt, work in 852 progress. 854 [v4v6trans] van der Pol, R., Satapati, S., Sivakumar, S.: 855 "Issues when translating between IPv4 and IPv6", January 2003, 856 draft-vanderpol-v6ops-translation-issues-00.txt, work in progress. 858 [6BONE] http://www.6bone.net 860 9. Authors and Acknowledgements 862 This document is written by: 864 Alain Durand, Sun Microsystems 865 867 Karim El-Malki, Ericsson Radio Systems 868 870 Niall Richard Murphy, Enigma Consulting Limited 871 873 Hugh Shieh, AT&T Wireless 874 876 Jonne Soininen, Nokia 877 879 Hesham Soliman, Flarion 880 882 Margaret Wasserman, Wind River 883 885 Juha Wiljakka, Nokia 886 888 The authors would like to thank Heikki Almay, Gabor Bajko, Ajay 889 Jain, Ivan Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand 890 Thakur and Rod Van Meter for their valuable input. 892 10. Editor's Contact Information 894 Comments or questions regarding this document should be sent to the 895 v6ops mailing list or directly to the document editor: 897 Juha Wiljakka 898 Nokia 899 Visiokatu 3 Phone: +358 7180 48372 900 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com