idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-03.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: ---------------------------------------------------------------------------- == Line 336 has weird spacing: '... can be handl...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7713 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 795, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 845, 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 3015 (Obsoleted by RFC 3525) ** Obsolete normative reference: RFC 3266 (Obsoleted by RFC 4566) == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-3gpp-cases-02 ** 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-00 -- 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-12 Summary: 10 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-03.txt Nokia 4 Expires: September 2003 6 March 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 making the transition to IPv6 in Third 34 Generation Partnership Project (3GPP) General Packet Radio Service 35 (GPRS) packet networks. The focus is on analyzing different 36 transition scenarios, applicable transition mechanisms and finding 37 solutions for those transition scenarios. In these scenarios, the 38 User Equipment (UE) connects to other nodes, e.g. in the Internet, 39 and 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.....................................6 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 54 .............................................................8 55 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 56 ............................................................10 57 3.4 IPv6 UE Connecting to an IPv4 Node.......................11 58 3.5 IPv4 UE Connecting to an IPv6 Node.......................12 59 4. IMS Transition Scenarios.....................................13 60 4.1 DNS Interworking in IMS..................................13 61 4.2 UE Connecting to a Node in an IPv4 Network through IMS...14 62 4.3 Two IMS Islands Connected over IPv4 Network..............16 63 5. Security Considerations......................................16 64 6. Changes from draft-ietf-v6ops-3gpp-analysis-02.txt...........16 65 7. Copyright....................................................16 66 8. References...................................................17 67 8.1 Normative................................................17 68 8.2 Informative..............................................18 69 9. Authors and Acknowledgements.................................20 70 10. Editor's Contact Information................................20 72 1. Introduction 74 This document describes and analyzes the process of transition to 75 IPv6 in Third Generation Partnership Project (3GPP) General Packet 76 Radio Service (GPRS) packet networks. The authors can be found in 77 Authors and Acknowledgements section. Comments, input and feedback 78 from the people in the IETF v6ops Working Group are appreciated. 80 This document analyzes the transition scenarios in 3GPP packet 81 data networks that might come up in the deployment phase of IPv6. 82 The transition scenarios are documented in [3GPP-SCEN] and this 83 document will further analyze them. The scenarios are divided into 84 two categories: GPRS scenarios and IMS scenarios. 86 GPRS scenarios are the following: 87 - Dual Stack UE connecting to IPv4 and IPv6 nodes 88 - IPv6 UE connecting to an IPv6 node through an IPv4 network 89 - IPv4 UE connecting to an IPv4 node through an IPv6 network 90 - IPv6 UE connecting to an IPv4 node 91 - IPv4 UE connecting to an IPv6 node 93 IMS scenarios are the following: 94 - UE connecting to a node in an IPv4 network through IMS 95 - Two IMS islands connected via IPv4 network 97 The focus is on analyzing different transition scenarios, 98 applicable transition mechanisms and finding solutions for those 99 transition scenarios. In the scenarios, the User Equipment (UE) 100 connects to nodes in other networks, e.g. in the Internet and 101 IPv6/IPv4 transition mechanisms are needed. 103 1.1 Scope of this Document 105 The scope of this informational document is to analyze and solve 106 the possible transition scenarios in the 3GPP defined GPRS network 107 where a UE connects to, or is contacted from the Internet, or 108 another UE. The document covers scenarios with and without the use 109 of the SIP based IP Multimedia Core Network Subsystem (IMS). This 110 document is not focused on radio interface issues; both 3GPP Second 111 (GSM) and Third Generation (UMTS) radio network architectures will 112 be covered by these scenarios. 114 The transition mechanisms specified by the IETF Ngtrans and v6ops 115 Working Groups shall be used. This document shall not specify any 116 new transition mechanisms, but if a need for a new mechanism is 117 found, that will be reported to the v6ops Working Group. 119 1.2 Abbreviations 121 2G Second Generation Mobile Telecommunications, for 122 example GSM and GPRS technologies. 123 3G Third Generation Mobile Telecommunications, for example 124 UMTS technology. 125 3GPP Third Generation Partnership Project 126 ALG Application Level Gateway 127 APN Access Point Name. The APN is a logical name referring 128 to a GGSN and an external network. 129 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 130 GGSN Gateway GPRS Support Node (a default router for 3GPP 131 User Equipment) 132 GPRS General Packet Radio Service 133 GSM Global System for Mobile Communications 134 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 135 IPv6-only part of the network 136 ISP Internet Service Provider 137 NAT Network Address Translator 138 NAPT-PT Network Address Port Translation - Protocol Translation 139 NAT-PT Network Address Translation - Protocol Translation 140 PDP Packet Data Protocol 141 PPP Point-to-Point Protocol 142 SIIT Stateless IP/ICMP Translation Algorithm 143 SIP Session Initiation Protocol 144 UE User Equipment, for example a UMTS mobile handset 145 UMTS Universal Mobile Telecommunications System 147 1.3 Terminology 149 Some terms used in 3GPP transition scenarios and analysis documents 150 are briefly defined here. 152 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual 153 stack implemented. It is capable of activating 154 both IPv4 and IPv6 PDP contexts. Dual stack UE may 155 be capable of tunneling. 157 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 158 only capable of activating IPv6 PDP contexts. 160 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 161 only capable of activating IPv4 PDP contexts. 163 IPv4 node IPv4 node is here defined to be IPv4 capable node 164 the UE is communicating with. The IPv4 node can 165 be, for example, an application server or another 166 UE. 168 IPv6 node IPv6 node is here defined to be IPv6 capable node 169 the UE is communicating with. The IPv6 node can 170 be, for example, an application server or another 171 UE. 173 2. Transition Mechanisms 175 This chapter briefly introduces some transition mechanisms 176 specified by the IETF. Applicability of different transition 177 mechanisms to 3GPP networks is discussed in chapters 3 and 4. 179 The IPv4/IPv6 transition methods can be divided to: 181 - dual IPv4/IPv6 stack 182 - tunneling 183 - protocol translators 185 2.1 Dual Stack 187 The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider 188 the 3GPP GPRS core network, dual stack implementation in the GGSN 189 enables support for both IPv4 and IPv6 and it is also needed to 190 perform IPv6 in IPv4 tunneling. UEs with dual stack and public / 191 global IP addresses can often access both IPv4 and IPv6 services 192 without additional translators in the network. 194 2.2 Tunneling 196 Tunneling is a transition mechanism that requires dual IPv4/IPv6 197 stack functionality in the encapsulating and decapsulating nodes. 198 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 199 IPv6-in-IPv4 tunneling mechanisms perform as virtual IPv6 links 200 over IPv4, and they are implemented by virtual IPv6 interfaces that 201 are configured over one or more physical IPv4 interfaces. Sending 202 nodes encapsulate IPv6 packets in IPv4 packets when the IPv6 203 routing table determines that the next hop toward the IPv6 204 destination address is via a tunnel interface. Receiving nodes 205 decapsulate IPv6 packets from IPv4 packets that arrive on tunnel 206 interfaces. Tunneling can be static or dynamic. 208 Static (configured) tunnels are fixed IPv6 links over IPv4. They 209 require static configuration of the IPv6 source, IPv6 next-hop and 210 IPv4 destination addresses for IPv6-in-IPv4 encapsulation. The IPv6 211 destination address is specified by the application and is used to 212 determine the IPv6 next-hop address via longest-prefix-match in the 213 IPv6 routing table. Configured tunnels are specified in [RFC2893]. 215 Dynamic (automatic) tunnels enable stateless encapsulation of IPv6- 216 in-IPv4. They are virtual IPv6 links over IPv4 where the tunnel 217 endpoints are not configured, i.e. the links are created 218 dynamically, and they only require static configuration of the IPv6 219 source address. Like in static tunneling, the IPv6 destination 220 address is specified by the application and it is used to determine 221 the IPv6 next-hop address via a longest-prefix-match lookup in the 222 IPv6 routing table. But unlike static tunnels, the IPv4 destination 223 address is not configured (fixed); it is derived from the IPv6 224 next-hop address in some way. For example, the IPv4 destination 225 address can be embedded in the IPv6 next-hop address. Examples of 226 dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], [DSTM] 227 and [TEREDO]. 229 2.3 Protocol Translators 231 A translator can be defined as an intermediate component between a 232 native IPv4 node and a native IPv6 node to enable direct 233 communication between them without requiring any modifications to 234 the end nodes. 236 Header conversion is a translation mechanism. In header conversion, 237 IPv6 packet headers are converted to IPv4 packet headers, and vice 238 versa, and checksums are adjusted or recalculated if necessary. 239 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 240 using SIIT [RFC2765] is an example of such a mechanism. 242 Translators are typically needed when the two communicating nodes 243 do not share the same IP version. Translation can actually happen 244 at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP 245 proxy) or Layer 7 (using application relays) 247 3. GPRS Transition Scenarios 249 This section discusses the scenarios that might occur when a GPRS 250 UE contacts services or other nodes, e.g. a web server in the 251 Internet. 253 The following scenarios described by [3GPP-SCEN] are analyzed here. 254 In all of the scenarios, the UE is part of a network where there is 255 at least one router of the same IP version, i.e. GGSN, and it is 256 connecting to a node in a different network. 258 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 259 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 260 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 261 4) IPv6 UE connecting to an IPv4 node 262 5) IPv4 UE connecting to an IPv6 node 264 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes 266 In this scenario, the UE is capable of communicating with both IPv4 267 and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also 268 requires that the GGSN is supporting both IPv4 and IPv6. The dual 269 stack UE may have both stacks or only one of them active 270 simultaneously. If "IPv6 in IPv4" tunneling is needed, it is 271 recommended to activate an IPv6 PDP context and make encapsulation 272 / decapsulation in the network (like described in section 3.2). 274 However, if the GGSN does not support IPv6, and an application on 275 the UE needs to communicate with an IPv6 node, the UE may activate 276 an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a 277 tunneling mechanism. Tunneling in the UE requires dual stack 278 capability in the UE. The use of private IPv4 addresses in the UE 279 depends on the support of these addresses by the tunneling 280 mechanism and the deployment scenario. In some cases public IPv4 281 addresses are required, but if the tunnel endpoints are in the same 282 private domain or the tunneling mechanism works through IPv4 NAT, 283 private IPv4 addresses can be used. One deployment scenario example 284 is using laptop computer and a UMTS UE as a modem. IPv6 packets are 285 encapsulated in IPv4 packets in the laptop computer and IPv4 PDP 286 context is activated. Although "IPv6 in IPv4" tunneling in the UE 287 can be either automatic or configured (by the user), the first 288 alternative is more probable, because it is expected that most UE 289 users just want to use an application in their UE; they might not 290 even care, whether the network connection is IPv4 or IPv6. 292 When analyzing a dual stack UE behavior, an application running on 293 a UE can identify whether the endpoint required is an IPv4 or IPv6 294 capable node by examining the address to discover what address 295 family category it falls into. Alternatively if a user supplies a 296 name to be resolved, the DNS may contain records sufficient to 297 identify which protocol should be used to initiate connection with 298 the endpoint. Since the UE is capable of native communication with 299 both protocols, one of the main concerns of an operator is correct 300 address space and routing management. The operator must maintain 301 address spaces for both protocols. Public IPv4 addresses often are 302 a scarce resource for the operator and typically it is not possible 303 for a UE to have a globally unique IPv4 address continually 304 allocated for its use. Use of private IPv4 addresses means use of 305 NATs (Network Address Translators) when communicating with a peer 306 node outside the operator's network. In large networks, NAT systems 307 can become very complex, expensive and difficult to maintain. 309 As a general guideline, IPv6 communication (native or tunneled from 310 the UE) is preferred to IPv4 communication going through IPv4 NATs 311 to the same dual stack peer node. In this scenario, the UE talks to 312 the DNS resolver using the IP version that is available via the 313 activated PDP context. 315 Keeping the Internet name space unfragmented is an important thing. 316 This covers IPv4 and IPv6. It means that any record in the public 317 Internet should be available unmodified to any nodes, IPv4 or IPv6, 318 regardless of the transport being used. The recommended approach 319 is: every recursive DNS server should be either IPv4-only or dual 320 stack and every single DNS zone should be served by at least an 321 IPv4 reachable DNS server. This recommendation rules out IPv6-only 322 recursive DNS servers and DNS zones served by IPv6-only DNS servers 323 and this approach could be revisited if translation techniques 324 between IPv4 and IPv6 were to be widely deployed [DNStrans]. 326 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network 328 The best solution for this scenario is obtained with tunneling, 329 i.e. "IPv6 in IPv4" tunneling is a requirement. An IPv6 PDP context 330 is activated between the UE and the GGSN. Tunneling is handled in 331 the network, because IPv6 UE is not capable of tunneling (it does 332 not have the dual stack functionality needed for tunneling). 333 Encapsulating node can be the GGSN, the edge router between the 334 border of the operator's IPv6 network and the public Internet, or 335 any other dual stack node within the operator's IP network. The 336 encapsulation (uplink) and decapsulation (downlink) can be handled 337 by the same network element. Typically the tunneling handled by the 338 network elements is transparent to the UEs and the IP traffic looks 339 like native IPv6 traffic to them. For the applications, tunneling 340 enables end-to-end IPv6 connectivity. Note that this scenario is 341 comparable to 6bone [6BONE] network operation. 343 "IPv6 in IPv4" tunnels between the IPv6 islands can be static or 344 dynamic. The selection of the type of tunneling mechanism is up to 345 the operator / ISP deployment scenario and only generic 346 recommendations can be given in this document. 348 The following subsections are focused on the usage of different 349 tunneling mechanisms when the peer node is in the operator's 350 network or outside the operator's network. The authors note that 351 where the actual 3GPP network ends and which parts of the network 352 belong to the ISP(s) also depends on the deployment scenario. The 353 authors are also not commenting how many ISP functions the 3GPP 354 operator should perform. However, many 3GPP operators are ISPs of 355 some sort themselves. 357 3.2.1 Tunneling inside the 3GPP Operator's Network 359 Many GPRS operators already have IPv4 backbone networks deployed 360 and they are gradually migrating them while introducing IPv6 361 islands. IPv6 backbones can be considered quite rare in the first 362 phases of the transition. If the 3GPP operator already has IPv6 363 widely deployed in its network, this subsection is not so relevant. 365 In initial, smaller scale IPv6 deployment, where a small number of 366 IPv6 in IPv4 tunnels are required to connect the IPv6 islands over 367 the 3GPP operator's IPv4 network, manually configured tunnels can 368 be used. In a 3GPP network, one IPv6 island could contain the GGSN 369 while another island contains the operator's IPv6 application 370 servers. However, manually configured tunnels can be an 371 administrative burden when the number of islands and therefore 372 tunnels rises. 374 It is also possible to use dynamic tunneling mechanisms such as 375 "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling 376 mechanisms [BGP][IGP]. Routing protocol based mechanisms such as 377 [BGP] consist of running BGP between the neighboring router tunnel 378 endpoints and using multi-protocol BGP extensions to exchange 379 reachability information of IPv6 prefixes. The routers use this 380 information to create IPv6 in IPv4 tunnel interfaces and route IPv6 381 packets over the IPv4 network. It is possible to combine this with 382 different types of tunnels. 384 "6to4" nodes use special IPv6 addresses with a "6to4" prefix 385 containing the IPv4 address of the corresponding "IPv6 in IPv4" 386 tunnel endpoint ("6to4" router) which performs encapsulation / 387 decapsulation. When connecting two nodes with "6to4" addresses, the 388 corresponding "6to4" routers use the IPv4 addresses specified in 389 the "6to4" prefixes to tunnel IPv6 packets through the IPv4 390 network. But if only one of them has a "6to4" address, a "6to4" 391 relay must be present to perform the missing "6to4" router 392 functionality for the native-IPv6 node. In this case there are two 393 deployment options for "IPv6 in IPv4" tunneling between the "6to4" 394 router and the relay. The first option assumes that "6to4" routers 395 using a given relay each have a default IPv6 route (configured 396 tunnel) pointing to that relay. The other one consists of using an 397 IPv6 exterior routing protocol; this way the set of "6to4" routers 398 using a given relay obtain native IPv6 routes from it using a 399 routing protocol such as BGP4+ [RFC2283]. Although this solution is 400 more complex, it provides effective policy control, i.e. BGP4+ 401 policy determines which "6to4" routers are able to use which relay. 403 The conclusion is that in most "internal" 3GPP scenarios it is 404 preferred to use manually configured tunnels or EGP/IGP based 405 tunneling mechanisms, if it is not feasible to enable IPv6 in the 406 network infrastructure yet. 408 3.2.2 Tunneling outside the 3GPP Operator's Network 410 This subsection includes the case when the peer node is outside the 411 operator's network. In that case the "IPv6 in IPv4" tunnel starting 412 point can be in the operator's network - encapsulating node can be 413 e.g. the GGSN or the edge router. 415 The case is pretty straightforward if the upstream ISP provides 416 native IPv6 connectivity to the Internet. If there is no native 417 IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" 418 tunnel should be configured from e.g. the GGSN to the dual stack 419 border gateway in order to access the upstream ISP. 421 If the ISP only provides IPv4 connectivity, then the IPv6 traffic 422 initiated from the 3GPP network should be transported tunneled in 423 IPv4 to the ISP. Defining the tunnel endpoint depends on the 424 deployment scenario. 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 Usage of dynamic tunneling, such as "6to4", can also be considered, 432 but the scalability problems arise when thinking about the great 433 number of UEs in the 3GPP networks. If we consider the "6to4" 434 tunneling mechanism and the 3GPP addressing model (a unique /64 435 prefix allocated for each primary PDP context), a /48 "6to4" prefix 436 would only be enough for approximately 65000 UEs. Thus, a few 437 public IPv4 addresses would be needed depending on the size of the 438 operator. Other issues to keep in mind with respect to the "6to4" 439 mechanism are that reverse DNS is not yet completely solved and 440 there are some security considerations associated with the use of 441 "6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of 442 the transition period, there will be a need for assigning new 443 (native IPv6) addresses to all "6to4" nodes in order to enable 444 native IPv6 connectivity. 446 The conclusion is that in most "external" 3GPP scenarios it is 447 preferred to use a few manually configured tunnels. 449 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 451 3GPP networks are expected to support both IPv4 and IPv6 for a long 452 time, on the UE-GGSN link and between the GGSN and external 453 networks. For this scenario it is useful to split the end-to-end 454 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 455 v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and 456 IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 457 link (PDP context) to connect to the GGSN without the need to 458 communicate over an IPv6 network. Regarding the GGSN-to-v4NODE 459 communication, typically the transport network between the GGSN and 460 external networks will support only IPv4 in the early stages and 461 migrate to dual stack, since these networks are already deployed. 462 Therefore it is not envisaged that tunneling of IPv4 in IPv6 will 463 be required from the GGSN to external IPv4 networks either. In the 464 longer run, 3GPP operators may need to phase out IPv4 UEs and the 465 IPv4 transport network. This would leave only IPv6 UEs. Therefore, 466 overall, the transition scenario involving an IPv4 UE communicating 467 with an IPv4 peer through an IPv6 network is not considered very 468 likely in 3GPP networks. 470 3.4 IPv6 UE Connecting to an IPv4 Node 472 IPv6 nodes can communicate with IPv4 hosts by making use of a 473 translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local 474 network. For some applications, application proxies can be 475 appropriate (e.g. HTTP, email relays, etc.). Such applications will 476 not be transparent to the UE. Hence, a flexible mechanism with 477 minimal manual intervention should be used to configure these 478 proxies on IPv6 UEs. Within the 3GPP architecture, application 479 proxies can be placed on the GGSN external interface (Gi), or 480 inside the service network. 482 However, since it is difficult to anticipate all possible 483 applications, there is a need for translators that can translate 484 headers independent of the type of application being used. 486 Due to the significant lack of IPv4 addresses in some domains, port 487 multiplexing is likely to be a necessary feature for translators 488 (i.e. NAPT-PT). 490 When NA(P)T-PT is used, it needs to be placed on the GGSN external 491 (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be 492 installed, for example, on the edge of the operator's network and 493 the public Internet. NA(P)T-PT will intercept DNS requests and 494 other applications that include IP addresses in their payloads, 495 translate the IP header (and payload for some applications if 496 necessary) and forward packets through its IPv4 interface. 498 NA(P)T-PT introduces limitations that are expected to be magnified 499 within the 3GPP architecture. Some of these limitations are listed 500 below (notice that some of them are also relevant for IPv4 NAT). We 501 note here that [Unmaneval] section 3.2 analyzes the problem with 502 address translation. However, the NAT-PT issues should be clearly 503 documented in an RFC in the v6ops Working Group and a decision 504 should be made, whether revisiting the NAT-PT RFC is necessary / 505 what kind of update is needed. 507 1. NA(P)T-PT is a single point of failure for all ongoing 508 connections. 510 2. Additional forwarding delays due to further processing, when 511 compared to normal IP forwarding. 513 3. Problems with source address selection due to the inclusion of 514 a DNS ALG on the same node [NATPT-DNS]. 516 4. NA(P)T-PT does not work (without application level gateways) 517 for applications that embed IP addresses in their payload. 519 5. NA(P)T-PT breaks DNSSEC. 521 6. NA(P)T-PT does not scale very well in large networks. 523 3GPP networks are expected to handle a very large number of 524 subscribers on a single GGSN (default router). Each GGSN is 525 expected to handle hundreds of thousands of connections. 526 Furthermore, high reliability is expected for 3GPP networks. 527 Consequently, a single point of failure on the GGSN external 528 interface, would raise concerns on the overall network reliability. 529 In addition, IPv6 users are expected to use delay-sensitive 530 applications provided by IMS. Hence, there is a need to minimize 531 forwarding delays within the IP backbone. Furthermore, due to the 532 unprecedented number of connections handled by the default routers 533 (GGSN) in 3GPP networks, a network design that forces traffic to go 534 through a single node at the edge of the network (typical NA(P)T-PT 535 configuration) is not likely to scale. Translation mechanisms 536 should allow for multiple translators, for load sharing and 537 redundancy purposes. 539 To minimize the problems associated with NA(P)T-PT, the following 540 actions can be recommended: 542 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 543 to IPv4" case). 545 2. Ensure (if possible) that NA(P)T-PT does not become a 546 single point of failure. 548 3. Allow for load sharing between different translators. That 549 is, it should be possible for different connections to go 550 through different translators. Note that load sharing alone 551 does not prevent NA(P)T-PT from becoming a single point of 552 failure. 554 There are some ways to fix the problems with NA(P)T-PT, one 555 suggestion is [NAT64]. 557 When thinking the DNS issues, the IPv6 UE needs to find the IPv4 558 address in the DNS [DNStrans]. Note that DNSSEC is broken if 559 NA(P)T-PT is used. 561 3.5 IPv4 UE Connecting to an IPv6 Node 563 The legacy IPv4 nodes are mostly nodes that support the 564 applications that are popular today in the IPv4 Internet: mostly e- 565 mail, and web-browsing. These applications will, of course, be 566 supported in the IPv6 Internet of the future. However, the legacy 567 IPv4 UEs are not going to be updated to support the future 568 applications. As these application are designed for IPv6, and to 569 use the advantages of newer platforms, the legacy IPv4 nodes will 570 not be able to profit from them. Thus, they will continue to 571 support the legacy services. 573 Taking the above into account, the traffic to and from the legacy 574 IPv4 UE is restricted to a few applications. These applications 575 already today mostly rely on proxies or local servers to 576 communicate between private address space networks and the 577 Internet. The same methods and technology can be used for IPv4 to 578 IPv6 transition. 580 An alternative solution could be a general network address 581 translation mechanisms such as NAT46 [NAT64]. 583 When thinking the DNS issues, the DNS zones containing AAAA records 584 for the IPv6 nodes need to be served by at least one IPv4 585 accessible DNS server [DNStrans]. 587 4. IMS Transition Scenarios 589 As the IMS is exclusively IPv6, the number of possible transition 590 scenarios is reduced dramatically. In the following, the possible 591 transition scenarios are listed. Those scenarios are analyzed in 592 sections 4.2 and 4.3. 594 1) UE connecting to a node in an IPv4 network through IMS 595 2) Two IMS islands connected over IPv4 network 597 4.1 DNS Interworking in IMS 599 The recommended approach (as documented in [DNStrans]) currently is 600 that every recursive DNS server should be either IPv4-only or dual 601 stack and every single DNS zone should be served by at least an 602 IPv4 reachable DNS server. The recommendation rules out IPv6-only 603 recursive DNS servers and DNS zones served by IPv6-only DNS 604 servers. 606 To perform DNS resolution in the IMS, the UE can be configured as a 607 stub resolver pointing to a recursive DNS resolver. This 608 communication can happen over IPv6. However, in the process to find 609 the IPv6 address of a SIP server, the recursive DNS resolver may 610 need to access data that is available only on some IPv4 DNS 611 servers, see [DNStrans]. One way to achieve this is to make the DNS 612 resolver be dual stack. As DNS traffic is not directly related to 613 the IMS functionality, this is not in contradiction with the IPv6- 614 only nature of the IMS. 616 4.2 UE Connecting to a Node in an IPv4 Network through IMS 618 This scenario occurs when an IMS UE (IPv6) connects to a node in 619 the IPv4 Internet through the IMS, or vice versa. This happens when 620 the other node is a part of a different system than 3GPP, e.g. a 621 fixed PC, with only IPv4 capabilities. 623 There will probably be few legacy IPv4 nodes in the Internet that 624 will communicate with the IMS UEs. It is assumed that the solution 625 described here is used for limited cases, in which communications 626 with a small number of legacy IPv4 SIP equipment are needed. As the 627 IMS is exclusively IPv6 [3GPP 23.221], translators have to be used 628 in the communication between the IPv6 IMS and legacy IPv4 hosts, 629 i.e. making a dual stack based solution is not feasible. This 630 section aims to give a brief overview on how that interworking can 631 be handled. 633 As control (or signaling) and user (or data) traffic are separated 634 in SIP, and thus, the IMS, the translation of the IMS traffic has 635 to be done on two levels - Session Initiation Protocol (SIP) 636 [RFC3261], and Session Description Protocol (SDP) [RFC2327] 637 [RFC3266] on the one hand (Mm-interface), and on the actual user 638 data traffic level on the other (Mb-interface). 640 SIP and SDP transition has to be made in an SIP/SDP Application 641 Level Gateway. The ALG has to change the IP addresses transported 642 in the SIP messages and the SDP payload of those messages to the 643 appropriate version. In addition, there has to be interoperability 644 for DNS queries; see section 4.1 for details. 646 On the user data transport level, the translation is IPv4-IPv6 647 protocol translation, where the user data traffic transported is 648 translated from IPv6 to IPv4, and vice versa. 650 The legacy IPv4 host's address can be mapped to an IPv6 address for 651 the IMS, and this address is then used within the IMS to route the 652 traffic to the appropriate user traffic translator. This mapping 653 can be done by the SIP/SDP ALG for the SIP traffic. The user 654 traffic translator would do the similar mapping for the user 655 traffic. However, in order to have an IPv4 address for the IMS UE, 656 and to be able to route the user traffic within the legacy IPv4 657 network to the correct translator, there has to be an IPv4 address 658 allocated for the duration of the session from the user traffic 659 translator. The allocation of this address from the user traffic 660 translator has to be done by the SIP/SDP ALG in order for the 661 SIP/SDP ALG to know the correct IPv4 address. This can be achieved 662 by using a protocol for the ALG to do the allocation such as MEGACO 663 [RFC3015]. 665 +-------------------------------+ +------------+ 666 | +------+ | | +--------+ | 667 | |S-CSCF|---| |SIP ALG | |\ 668 | | +------+ | | +--------+ | \ -------- 669 +-|+ | / | | | | | | 670 | | | +------+ +------+ | | + | -| |- 671 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 672 | | +------+ +------+ | |+----------+| / ------ 673 | |-----------------------------------||Translator||/ 674 +--+ | IPv6 | |+----------+| IPv4 675 UE | | |Interworking| 676 | IP Multimedia CN Subsystem | |Unit | 677 +-------------------------------+ +------------+ 679 Figure 1: UE using IMS to contact a legacy phone 681 Figure 1 shows a possible configuration scenario where the SIP ALG 682 is separate to the CSCFs. The translator can either be set up in a 683 single device with both SIP translation and media translation, or 684 those functionalities can be divided to two different entities with 685 an interface in between. We call the combined network element on 686 the edge of the IPv6-only IMS an "Interworking Unit" in this 687 document. One alternative is to use a suitable subset of NAT-PT 688 [RFC2766] in this network element to take care of the media (user 689 data) IPv4/IPv6 translation. The problems related to NAT-PT are 690 documented in subsection 3.4. 692 A special case is when the IPv4-only destination node is registered 693 to a SIP proxy that happens to be dual stack. In such a case, the 694 connection from the edge of the IMS to the destination network 695 could be either IPv4 or IPv6, as the SIP INVITE message sent by the 696 IMS UE involves DNS address resolution only for the destination SIP 697 proxy (and not for the destination node). If IPv4 is used (from the 698 edge of the IMS to the destination SIP proxy), then no further 699 IPv4-IPv6 interworking is needed outside the IMS domain, as IPv4- 700 IPv6 translation will be performed on the edge of the IMS. 702 On the other hand, when IPv6 is used to connect both SIP proxies 703 (that is more likely), translation is not taken care of in the IMS 704 because there is no way of detecting that the destination node is 705 IPv4-only (i.e., only the IP version of the destination SIP proxy 706 can be detected from the DNS reply). Thus, IPv6 to IPv4 translation 707 should be performed in the destination SIP domain (for example, 708 implemented in the dual stack SIP proxy). In addition, it could 709 also happen (especially in the initial stages of IPv6 deployment) 710 that end-to-end IPv6 connectivity between the IMS and the 711 destination domain is not yet available. Thus, this would be 712 equivalent to the scenario described in 4.3 (two IPv6 islands 713 connecting through an IPv4 network) and an IPv6 in IPv4 tunneling 714 mechanism should be used (in addition to IPv4-IPv6 translation in 715 the destination domain). 717 4.3 Two IMS Islands Connected over IPv4 Network 719 At the early stages of IMS deployment, there may be cases where two 720 IMS islands are separated by an IPv4 network such as the legacy 721 Internet. Here both the UEs and the IMS islands are IPv6-only. 722 However, the IPv6 islands are not native IPv6 connected. 724 In this scenario, the end-to-end SIP connections would be based on 725 IPv6. The only issue is to make connection between two IPv6-only 726 IMS islands over IPv4 network. So, in practice, this scenario is 727 very closely related to GPRS scenario represented in section 3.2. 729 IPv4 / IPv6 interworking can be taken care of in the network; the 730 basic options are static and dynamic tunneling. The tunnel starting 731 point or endpoint should be located on the edge of the IMS domain. 732 Static "IPv6 in IPv4" tunnels configured between different IMS 733 domains would be a good solution. Note that this scenario is 734 comparable to 6bone [6BONE] network operation. 736 5. Security Considerations 738 1. Problems have been identified in the case of the 739 reachability of IPv4 and IPv6 nodes (use of DNS through 740 NAT-PT). NAT-PT DNS ALG problems are described in [NATPT- 741 DNS] and [Unmaneval]. 743 2. The 3GPP specifications do not currently define the usage 744 of DNS Security. They neither disallow the usage of DNSSEC, 745 nor do they mandate it. 747 3. NAT-PT breaks DNSSEC. 749 6. Changes from draft-ietf-v6ops-3gpp-analysis-02.txt 751 - Editorial changes in some sections 753 7. Copyright 755 The following copyright notice is copied from [RFC2026], Section 756 10.4. It describes the applicable copyright for this document. 758 Copyright (C) The Internet Society March 30, 2003. All Rights 759 Reserved. 761 This document and translations of it may be copied and furnished to 762 others, and derivative works that comment on or otherwise explain 763 it or assist in its implementation may be prepared, copied, 764 published and distributed, in whole or in part, without restriction 765 of any kind, provided that the above copyright notice and this 766 paragraph are included on all such copies and derivative works. 767 However, this document itself may not be modified in any way, such 768 as by removing the copyright notice or references to the Internet 769 Society or other Internet organizations, except as needed for the 770 purpose of developing Internet standards in which case the 771 procedures for copyrights defined in the Internet Standards process 772 must be followed, or as required to translate it into languages 773 other than English. 775 The limited permissions granted above are perpetual and will not be 776 revoked by the Internet Society or its successors or assignees. 778 This document and the information contained herein is provided on 779 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 780 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 781 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 782 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 783 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 785 8. References 787 8.1 Normative 789 [RFC2026] Bradner, S.: The Internet Standards Process -- Revision 790 3, RFC 2026, October 1996. 792 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 793 Protocol, RFC 2327, April 1998. 795 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 796 Translator (NAT) Terminology and Considerations, RFC 2663, August 797 1999. 799 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 800 (SIIT), RFC 2765, February 2000. 802 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 803 - Protocol Translation (NAT-PT), RFC 2766, February 2000. 805 [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for 806 IPv6 Hosts and Routers, RFC 2893, August 2000. 808 [RFC3015] Cuervo, F., et al: Megaco Protocol Version 1.0, RFC 3015, 809 November 2000. 811 [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via 812 IPv4 Clouds, RFC 3056, February 2001. 814 [RFC3261] Rosenberg, J., et al.: SIP: Session Initiation Protocol, 815 June 2002. 817 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 818 in Session Description Protocol (SDP), June 2002. 820 [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP 821 Networks", January 2003, draft-ietf-v6ops-3gpp-cases-02.txt, work 822 in progress. 824 [3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service 825 (GPRS); Service description; Stage 2 (Release 5)", December 2002. 827 [3GPP 23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements 828 (Release 5)", December 2002. 830 [3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem 831 (IMS); Stage 2 (Release 5)", December 2002. 833 [3GPP 24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP 834 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 835 December 2002. 837 [3GPP 24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control 838 Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002. 840 8.2 Informative 842 [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: 843 Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. 845 [RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP 846 Standards", September 2002. 848 [6to4SEC] Savola, P.: "Security Considerations for 6to4", January 849 2003, draft-savola-v6ops-6to4-security-02.txt, work in progress. 851 [BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le 852 Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with 853 BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in 854 progress. 856 [DNStrans] Durand, A.: "IPv6 DNS transition issues", October 2002, 857 draft-ietf-dnsop-ipv6-dns-issues-00.txt, work in progress. 859 [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", 860 July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress, the 861 draft has expired. 863 [IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica, 864 C., Baudot, A., Diribarne, G.: "Connecting IPv6 islands within an 865 IPv4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp- 866 02.txt, work in progress, the draft has expired. 868 [ISATAP] Templin, F., et al.: "Intra-Site Automatic Tunnel 869 Addressing Protocol (ISATAP)", January 2003, draft-ietf-ngtrans- 870 isatap-12.txt, work in progress. 872 [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- 873 ngtrans-nat64-nat46-00.txt, work in progress, the draft has 874 expired. 876 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", 877 January 2003, draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work 878 in progress. 880 [TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through 881 NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in 882 progress. 884 [Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S., 885 van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged 886 Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt, 887 work in progress. 889 [6BONE] http://www.6bone.net 891 9. Authors and Acknowledgements 893 This document is written by: 895 Alain Durand, Sun Microsystems 896 898 Karim El-Malki, Ericsson Radio Systems 899 901 Niall Richard Murphy, Enigma Consulting Limited 902 904 Hugh Shieh, AT&T Wireless 905 907 Jonne Soininen, Nokia 908 910 Hesham Soliman, Ericsson Radio Systems 911 913 Margaret Wasserman, Wind River 914 916 Juha Wiljakka, Nokia 917 919 The authors would like to thank Gabor Bajko, Ajay Jain, Ivan 920 Laloux, Pekka Savola, Pedro Serna, Fred Templin, Anand Thakur and 921 Rod Van Meter for their valuable input. 923 10. Editor's Contact Information 925 Comments or questions regarding this document should be sent to the 926 v6ops mailing list or directly to the document editor: 928 Juha Wiljakka 929 Nokia 930 Visiokatu 3 Phone: +358 7180 48372 931 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com