idnits 2.17.1 draft-ietf-v6ops-3gpp-analysis-00.txt: -(301): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (December 2002) is 7803 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 660, but no explicit reference was found in the text == Unused Reference: 'RFC3314' is defined on line 685, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2283 (Obsoleted by RFC 2858) ** 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) ** Downref: Normative reference to an Informational RFC: RFC 3314 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-3gpp-cases-00 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-cases (ref. '3GPP-SCEN') == Outdated reference: A later version (-02) exists of draft-savola-v6ops-6to4-security-01 -- Possible downref: Normative reference to a draft: ref. '6to4SEC' == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-00 -- Possible downref: Normative reference to a draft: ref. 'DNSreq' -- Possible downref: Normative reference to a draft: ref. 'DSTM' -- Possible downref: Normative reference to a draft: ref. 'IGP' == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. 'ISATAP') -- Possible downref: Normative reference to a draft: ref. 'NAT64' -- Possible downref: Normative reference to a draft: ref. 'NATPT-DNS' -- Possible downref: Normative reference to a draft: ref. 'TEREDO' -- Possible downref: Normative reference to a draft: ref. 'Unmaneval' -- Possible downref: Non-RFC (?) normative reference: ref. '6BONE' Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Wiljakka, 3 Document: draft-ietf-v6ops-3gpp-analysis-00.txt Editor 4 Expires: June 2003 Nokia 6 December 2002 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 nodes in other networks, e.g. in 39 the Internet, 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 7 54 3.3 IPv4 UE connecting to an IPv4 node through an IPv6 network 9 55 3.4 IPv6 UE connecting to an IPv4 node........................9 56 3.5 IPv4 UE connecting to an IPv6 node.......................11 57 4. Transition Scenarios with IMS................................12 58 4.1 DNS interworking in IMS..................................12 59 4.2 UE connecting to a node in an IPv4 network through IMS...12 60 4.3 Two IMS islands connected over IPv4 network..............14 61 5. Security Considerations......................................14 62 6. Changes from draft-wiljakka-3gpp-ipv6-transition-02.txt......14 63 7. References...................................................14 64 8. Authors and Acknowledgements.................................16 65 9. Editor's Contact Information.................................17 67 1. Introduction 69 This document describes and analyzes the process of transition to 70 IPv6 in Third Generation Partnership Project (3GPP) General Packet 71 Radio Service (GPRS) packet networks. The authors can be found in 72 Authors and Acknowledgements section. Comments, input and feedback 73 from the people in the IETF v6ops Working Group are appreciated. 75 This document analyzes the transition scenarios in 3GPP packet 76 data networks that might come up in the deployment phase of IPv6. 77 The transition scenarios are documented in [3GPP-SCEN] and this 78 document will further analyze them. The scenarios are divided into 79 two categories: GPRS scenarios and IMS scenarios. 81 GPRS scenarios are the following: 82 - Dual Stack UE connecting to IPv4 and IPv6 nodes 83 - IPv6 UE connecting to an IPv6 node through an IPv4 network 84 - IPv4 UE connecting to an IPv4 node through an IPv6 network 85 - IPv6 UE connecting to an IPv4 node 86 - IPv4 UE connecting to an IPv6 node 88 Two IMS scenarios are: 89 - UE connecting to a node in an IPv4 network through IMS 90 - Two IMS islands connected via IPv4 network 92 The focus is on analyzing different transition scenarios, 93 applicable transition mechanisms and finding solutions for those 94 transition scenarios. In the scenarios, the User Equipment (UE) 95 connects to nodes in other networks, e.g. in the Internet and 96 IPv6/IPv4 transition mechanisms are needed. 98 1.1 Scope of this Document 100 The scope of this informational document is to analyze and solve 101 the possible transition scenarios in the 3GPP defined GPRS network 102 where a UE connects to, or is contacted from the Internet, or 103 another UE. The document covers scenarios with and without the use 104 of the SIP based IP Multimedia Core Network Subsystem (IMS). This 105 document is not focused on radio interface issues; both 3GPP Second 106 (GSM) and Third Generation (UMTS) radio network architectures will 107 be covered by these scenarios. 109 The transition mechanisms specified by the IETF Ngtrans / v6ops 110 Working Group shall be used. This document shall not specify any 111 new transition mechanisms, but if a need for a new mechanism is 112 found, this will be reported to the v6ops Working Group. 114 1.2 Abbreviations 116 2G Second Generation Mobile Telecommunications, for 117 example GSM and GPRS technologies. 118 3G Third Generation Mobile Telecommunications, for example 119 UMTS technology. 120 3GPP Third Generation Partnership Project 121 ALG Application Level Gateway 122 APN Access Point Name. The APN is a logical name referring 123 to a GGSN and an external network. 124 CSCF Call Session Control Function (in 3GPP Release 5 IMS) 125 GGSN Gateway GPRS Support Node (a default router for 3GPP 126 User Equipment) 127 GPRS General Packet Radio Service 128 GSM Global System for Mobile Communications 129 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 130 IPv6-only part of the network 131 NAT Network Address Translator 132 NAPT-PT Network Address Port Translation - Protocol Translation 133 NAT-PT Network Address Translation - Protocol Translation 134 PDP Packet Data Protocol 135 PPP Point-to-Point Protocol 136 SIIT Stateless IP/ICMP Translation Algorithm 137 SIP Session Initiation Protocol 138 UE User Equipment, for example a UMTS mobile handset 139 UMTS Universal Mobile Telecommunications System 141 1.3 Terminology 143 Some terms used in 3GPP transition scenarios and analysis documents 144 are briefly defined here. 146 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual 147 stack implemented. It is capable of activating 148 both IPv4 and IPv6 PDP contexts. Dual stack UE may 149 be capable of tunneling. 151 IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is 152 only capable of activating IPv6 PDP contexts. 154 IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is 155 only capable of activating IPv4 PDP contexts. 157 IPv4 node IPv4 node is here defined to be IPv4 capable node 158 the UE is communicating with. The IPv4 node can 159 be, for example, an application server or another 160 UE. 162 IPv6 node IPv6 node is here defined to be IPv6 capable node 163 the UE is communicating with. The IPv6 node can 164 be, for example, an application server or another 165 UE. 167 2. Transition mechanisms 169 This chapter briefly introduces some transition mechanisms 170 specified by the IETF. Applicability of different transition 171 mechanisms to 3GPP networks is discussed in chapters 3 and 4. 173 The IPv4/IPv6 transition methods can be divided to: 175 - dual IPv4/IPv6 stack 176 - tunneling 177 - protocol translators 179 2.1 Dual Stack 181 The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider 182 the 3GPP GPRS core network, dual stack implementation in the GGSN 183 enables support for both IPv4 and IPv6 and it is also needed to 184 perform IPv6 in IPv4 tunneling. UEs with dual stack and public / 185 global IP addresses can often access both IPv4 and IPv6 services 186 without additional translators in the network. 188 2.2 Tunneling 190 Tunneling is a transition mechanism that requires dual IPv4/IPv6 191 stack functionality in the encapsulating and decapsulating nodes. 192 Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. 193 IPv6-in-IPv4 tunneling mechanisms are implemented by virtual 194 interfaces that are configured over one or more physical IPv4 195 interfaces. Sending nodes encapsulate IPv6 packets in IPv4 packets 196 when the IPv6 routing table determines that the next hop toward the 197 IPv6 destination address is via a tunnel interface. Receiving nodes 198 decapsulate IPv6 packets from IPv4 packets that arrive on tunnel 199 interfaces. Tunneling can be static or dynamic. 201 Static (configured) tunnel interfaces are virtual IPv6 point-to- 202 point links over IPv4. They require static configuration of the 203 IPv6 source, IPv6 next-hop and IPv4 destination addresses for IPv6- 204 in-IPv4 encapsulation. The IPv6 destination address is specified by 205 the application and is used to determine the IPv6 next-hop address 206 via longest-prefix-match in the IPv6 routing table. Configured 207 tunnels are specified in [RFC2893]. 209 Dynamic (automatic) tunnel interfaces are virtual IPv6 point-to- 210 multipoint links over IPv4. They require static configuration of 211 the IPv6 source address only. Like in static tunneling, the IPv6 212 destination address is specified by the application and is used to 213 determine the IPv6 next-hop address via a longest-prefix-match 214 lookup in the IPv6 routing table. But unlike static tunnels, the 215 IPv4 destination address is derived from the IPv6 next-hop address 216 in some way, for example, via direct encoding in the IPv6 next-hop 217 address. This enables stateless encapsulation of IPv6-in-IPv4. 218 This means that the IPv4 source address is taken from an IPv4 219 interface over which the automatic tunnel is configured. Examples 220 of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], 221 [DSTM] and [TEREDO]. 223 2.3 Protocol translators 225 A translator can be defined as an intermediate component between a 226 native IPv4 node and a native IPv6 node to enable direct 227 communication between them without requiring any modifications to 228 the end nodes. 230 Header conversion is a translation mechanism. In header conversion, 231 IPv6 packet headers are converted to IPv4 packet headers, and vice 232 versa, and checksums are adjusted or recalculated if necessary. 233 NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] 234 using SIIT [RFC2765] is an example of such a mechanism. 236 Translators are typically needed when the two communicating nodes 237 do not share the same IP version. Translation can actually happen 238 at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP 239 proxy) or Layer 7 (using application relays) 241 3. GPRS Transition scenarios 243 This section discusses the scenarios that might occur when a GPRS 244 UE contacts services, or nodes outside the GPRS network, e.g. a web 245 server in the Internet. Transition scenarios of the GPRS internal 246 interfaces are outside of the scope of this document. 248 The following scenarios are analyzed here. In all of the scenarios, 249 the UE is part of a network where there is at least one router of 250 the same IP version, i.e. GGSN, and it is connecting to a node in a 251 different network. 253 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 254 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 255 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 256 4) IPv6 UE connecting to an IPv4 node 257 5) IPv4 UE connecting to an IPv6 node 259 3.1 Dual Stack UE connecting to IPv4 and IPv6 nodes 261 In this scenario, the UE is capable of communicating with both IPv4 262 and IPv6 nodes by activating IPv4 or IPv6 PDP context. This also 263 requires that the GGSN is supporting both IPv4 and IPv6. The dual 264 stack UE may have both stacks or only one of them active 265 simultaneously. If "IPv6 in IPv4" tunneling is needed, it is often 266 beneficial to activate IPv6 PDP context and make encapsulation / 267 decapsulation in the network (like described in section 3.2). 269 However, if the GGSN does not support IPv6, and an application on 270 the UE needs to communicate with an IPv6 node, the UE may activate 271 an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a 272 tunneling mechanism. Tunneling in the UE requires dual stack 273 capability in the UE. The use of private IPv4 addresses in the UE 274 depends on the support of these addresses by the tunneling 275 mechanism and the deployment scenario. In some cases public IPv4 276 addresses are required, but if the tunnel endpoints are in the same 277 private domain or the tunneling mechanism works through IPv4 NAT, 278 private IPv4 addresses can be used. One deployment scenario example 279 is using laptop computer and a UMTS UE as a modem. IPv6 packets are 280 encapsulated in IPv4 packets in the laptop computer and IPv4 PDP 281 context is activated. Although "IPv6 in IPv4" tunneling in the UE 282 can be either automatic or configured (by the user), the first 283 alternative is more probable, because it is expected that most UE 284 users just want to use an application in their UE; they might not 285 even care, whether the network connection is IPv4 or IPv6. 287 When analyzing a dual stack UE behavior, an application running on 288 a UE may obviously identify whether the endpoint required is an 289 IPv4 or IPv6 capable node by examining the address to discover what 290 address family category it falls into. Alternatively if a user 291 supplies a name to be resolved, the DNS may contain records 292 sufficient to identify which protocol should be used to initiate 293 connection with the endpoint. Since the UE is capable of native 294 communication with both protocols, one of the main concerns of an 295 operator is correct address and routing management. The operator 296 must maintain address spaces for both protocols. Public IPv4 297 addresses may be a scarce resource for the operator. Typically it 298 is not possible for a UE to have a globally unique IPv4 address 299 continually allocated for its use. Use of private IPv4 addresses 300 means use of NATs (Network Address Translators) when communicating 301 with a peer node outside the operator�s network. In large networks, 302 NAT systems can become very complex, expensive and difficult to 303 maintain. 305 As a general guideline, IPv6 communication (native or tunneled from 306 the UE) is preferred to IPv4 communication going through IPv4 NATs 307 to the same dual stack peer node. In this scenario, the UE talks to 308 the DNS resolver using the IP version that is available via the 309 activated PDP context. The DNS resolver in the network should be 310 dual stack. 312 3.2 IPv6 UE connecting to an IPv6 node through an IPv4 network 314 The best solution for this scenario is obtained with tunneling, 315 i.e. "IPv6 in IPv4" tunneling is a requirement. An IPv6 PDP context 316 is activated between the UE and the GGSN. Tunneling is handled in 317 the network, because IPv6 UE is not capable of tunneling (it does 318 not have the dual stack functionality needed for tunneling). 319 Encapsulating node can be e.g. the GGSN or the edge router between 320 the border of the operator's IPv6 network and the public Internet. 321 The encapsulation (uplink) and decapsulation (downlink) can be 322 handled by the same network element. Typically the tunneling 323 handled by the network elements is transparent to the UEs and the 324 IP traffic looks like native IPv6 traffic to them. For the 325 applications, tunneling enables end-to-end IPv6 connections. Note 326 that this scenario is comparable to 6bone [6BONE] network 327 operation. 329 "IPv6 in IPv4" tunnels between the IPv6 islands can be static or 330 dynamic. The selection of the type of tunneling mechanism is up to 331 the operator/ISP deployment scenario and only generic 332 recommendations can be given. 334 In initial, smaller scale IPv6 deployment, where a small number of 335 IPv6 in IPv4 tunnels are required to connect the IPv6 islands over 336 an IPv4 network, manually configured tunnels can be used. In a 3GPP 337 network, one IPv6 island could contain the GGSN while another 338 island contains the operator's IPv6 application servers or the 339 dual-stack border gateway to the upstream ISP. However, manually 340 configured tunnels can be an administrative burden when the number 341 of islands and therefore tunnels rises. Therefore it is also 342 possible to use dynamic tunneling mechanisms such as "6to4" 343 [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms 344 [BGP][IGP]. Routing protocol based mechanisms such as [BGP] consist 345 in running BGP between the neighboring router tunnel endpoints and 346 using multi-protocol BGP extensions to exchange reachability 347 information of IPv6 prefixes. The routers use this information to 348 create IPv6 in IPv4 tunnel interfaces and route IPv6 packets over 349 the IPv4 network. It is possible to combine this with different 350 types of tunnels. On the other hand, "6to4" [RFC3056] nodes use 351 special IPv6 addresses with a "6to4" prefix containing the IPv4 352 address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4" 353 router) which performs encapsulation / decapsulation. When 354 connecting two nodes with "6to4" addresses, the corresponding 355 "6to4" routers use the IPv4 addresses specified in the "6to4" 356 prefixes to tunnel IPv6 packets through the IPv4 network. But if 357 only one of them has a "6to4" address, a "6to4" relay must be 358 present to perform the missing "6to4" router functionality for the 359 native-IPv6 node. In this case there are two deployment options for 360 "IPv6 in IPv4" tunneling between the "6to4" router and the relay. 361 The first option assumes that "6to4" routers using a given relay 362 each have a default IPv6 route (configured tunnel) pointing to that 363 relay. The other one consists in using an IPv6 exterior routing 364 protocol; this way the set of "6to4" routers using a given relay 365 obtain native IPv6 routes from it using a routing protocol such as 366 BGP4+ [RFC2283]. Although this solution is more complex, it 367 provides effective policy control, i.e. BGP4+ policy determines 368 which "6to4" routers are able to use which relay. 370 If we consider the "6to4" tunneling mechanism and the 3GPP 371 addressing model (a unique /64 prefix allocated for each primary 372 PDP context), a /48 "6to4" prefix would only be enough for 373 approximately 65000 UEs. Thus, a few public IPv4 addresses would be 374 needed depending on the size of the operator. Other issues to keep 375 in mind with respect to the "6to4" mechanism are that reverse DNS 376 is not yet completely solved and there are some security 377 considerations associated with the use of "6to4" relay routers (see 378 [6to4SEC]). In a later phase of the transition period, there will 379 be a need for assigning new (native IPv6) addresses to "6to4" nodes 380 in order to enable native IPv6 connectivity in the future. In most 381 3GPP scenarios it is preferred to use manually configured tunnels 382 or EGP/IGP based tunneling mechanisms. 384 3.3 IPv4 UE connecting to an IPv4 node through an IPv6 network 386 3GPP networks are expected to support both IPv4 and IPv6 for a long 387 time, on the UE-GGSN link and between the GGSN and external 388 networks. For this scenario it is useful to split the end-to-end 389 IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- 390 v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and 391 IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 392 link (PDP context) to connect to the GGSN without the need to 393 communicate over an IPv6 network. Regarding the GGSN-to-v4NODE 394 communication, typically the transport network between the GGSN and 395 external networks will support only IPv4 in the early stages and 396 migrate to dual stack, since these networks are already deployed. 397 Therefore it is not envisaged that tunneling of IPv4 in IPv6 will 398 be required from the GGSN to external IPv4 networks either. In the 399 longer run, 3GPP operators may need to phase out IPv4 UEs and the 400 IPv4 transport network. This would leave only IPv6 UEs. Therefore, 401 overall, the transition scenario involving an IPv4 UE communicating 402 with an IPv4 peer through an IPv6 network is not considered very 403 likely in 3GPP networks. 405 3.4 IPv6 UE connecting to an IPv4 node 407 IPv6 nodes can communicate with IPv4 hosts by making use of a 408 translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local 409 network. For some applications, application proxies can be 410 appropriate (e.g. HTTP, email relays, etc.). Such applications will 411 not be transparent to the UE. Hence, a flexible mechanism with 412 minimal manual intervention should be used to configure these 413 proxies on IPv6 UEs. Within the 3GPP architecture, application 414 proxies can be placed on the GGSN external interface (Gi), or 415 inside the service network. 417 However, since it is difficult to anticipate all possible 418 applications, there is a need for translators that can translate 419 headers independent of the type of application being used. 421 Due to the significant lack of IPv4 addresses in some domains, port 422 multiplexing is likely to be a necessary feature for translators 423 (i.e. NAPT-PT). 425 When NA(P)T-PT is used, it needs to be placed on the GGSN external 426 (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be 427 installed, for example, on the edge of the operator's network and 428 the public Internet. NA(P)T-PT will intercept DNS requests and 429 other applications that include IP addresses in their payloads, 430 translate the IP header (and payload for some applications if 431 necessary) and forward packets through its IPv4 interface. 433 NA(P)T-PT introduces limitations that are expected to be magnified 434 within the 3GPP architecture. Some of these limitations are listed 435 below (notice that some of them are also relevant for IPv4 NAT). We 436 note here that [Unmaneval] section 3.2 analyzes the problem with 437 address translation. However, the NAT-PT issues should be clearly 438 documented in an RFC in the v6ops Working Group and a decision 439 should be made, whether revisiting the NAT-PT RFC is necessary / 440 what kind of update is needed. 442 1. NA(P)T-PT is a single point of failure for all ongoing 443 connections. 445 2. Additional forwarding delays due to further processing, when 446 compared to normal IP forwarding. 448 3. Problems with source address selection due to the inclusion of 449 a DNS ALG on the same node [NATPT-DNS]. 451 4. NA(P)T-PT does not work (without application level gateways) 452 for applications that embed IP addresses in their payload. 454 5. NA(P)T-PT breaks DNSSEC. 456 6. NA(P)T-PT does not scale very well in large networks. 458 3GPP networks are expected to handle a very large number of 459 subscribers on a single GGSN (default router). Each GGSN is 460 expected to handle hundreds of thousands of connections. 461 Furthermore, high reliability is expected for 3GPP networks. 462 Consequently, a single point of failure on the GGSN external 463 interface, would raise concerns on the overall network reliability. 464 In addition, IPv6 users are expected to use delay-sensitive 465 applications provided by IMS. Hence, there is a need to minimize 466 forwarding delays within the IP backbone. Furthermore, due to the 467 unprecedented number of connections handled by the default routers 468 (GGSN) in 3GPP networks, a network design that forces traffic to go 469 through a single node at the edge of the network (typical NA(P)T-PT 470 configuration) is not likely to scale. Translation mechanisms 471 should allow for multiple translators, for load sharing and 472 redundancy purposes. 474 To minimize the problems associated with NA(P)T-PT, the following 475 actions can be recommended: 477 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 478 to IPv4" case). 480 2. Ensure (if possible) that NA(P)T-PT does not become a 481 single point of failure. 483 3. Allow for load sharing between different translators. That 484 is, it should be possible for different connections to go 485 through different translators. Note that load sharing alone 486 does not prevent NA(P)T-PT from becoming a single point of 487 failure. 489 There are some ways to fix the problems with NA(P)T-PT, one 490 suggestion is [NAT64]. 492 When thinking the DNS issues, the IPv6 UE needs to find the IPv4 493 address in the DNS, thus the DNS resolver in the network must be 494 dual stack. Note that DNSSEC is broken if NA(P)T-PT is used. 496 3.5 IPv4 UE connecting to an IPv6 node 498 The legacy IPv4 nodes are mostly nodes that support the 499 applications that are popular today in the IPv4 Internet: mostly e- 500 mail, and web-browsing. These applications will, of course, be 501 supported in the IPv6 Internet of the future. However, the legacy 502 IPv4 UEs are not going to be updated to support the future 503 applications. As these application are designed for IPv6, and to 504 use the advantages of newer platforms, the legacy IPv4 nodes will 505 not be able to profit from them. Thus, they will continue to 506 support the legacy services. 508 Taking the above into account, the traffic to and from the legacy 509 IPv4 UE is restricted to a few applications. These applications 510 already today mostly rely on proxies or local servers to 511 communicate between private address space networks and the 512 Internet. The same methods and technology can be used for IPv4 to 513 IPv6 transition. 515 An alternative solution could be a general network address 516 translation mechanisms such as NAT46 [NAT64]. 518 When thinking the DNS issues, the DNS zones containing AAAA records 519 for the IPv6 nodes need to be served by at least one IPv4 520 accessible DNS server. 522 4. Transition Scenarios with IMS 524 As the IMS is exclusively IPv6, the number of possible transition 525 scenarios is reduced dramatically. In the following, the possible 526 transition scenarios are listed. Those scenarios are analyzed in 527 sections 4.2 and 4.3. 529 1) UE connecting to a node in an IPv4 network through IMS 530 2) Two IMS islands connected over IPv4 network 532 4.1 DNS interworking in IMS 534 Currently, there is a consensus in the IETF that even in the IPv6 535 Internet the DNS resolvers have to be dual stack. 537 To perform DNS resolution in the IMS, the UE can be configured as a 538 stub resolver pointing to a recursive DNS resolver. This 539 communication can happen over IPv6. However, in the process to find 540 the IPv6 address of a SIP server, the recursive DNS resolver may 541 need to access data that is available only on some IPv4 DNS 542 servers, see [v6namespace] and [DNSreq]. One way to achieve this is 543 to make the DNS resolver be dual stack. As DNS traffic is not 544 directly related to the IMS functionality, this is not in 545 contradiction with the IPv6-only nature of the IMS. 547 4.2 UE connecting to a node in an IPv4 network through IMS 549 This scenario occurs when an IMS UE (IPv6) connects to a node in 550 the IPv4 Internet through the IMS, or vice versa. This happens when 551 the other node is a part of a different system than 3GPP, e.g. a 552 fixed PC, with only IPv4 capabilities. 554 Apparently there will be a number of legacy IPv4 nodes in the 555 Internet that will communicate with the IMS UEs. As the IMS is 556 exclusively IPv6, translators have to be used in the communication 557 between the IPv6 IMS and legacy IPv4 hosts. This section aims to 558 give an overview on how that interworking can be handled. 560 As control (or signaling) and user (or data) traffic are separated 561 in SIP, and thus, the IMS, the translation of the IMS traffic has 562 to be done on two levels - Session Initiation Protocol (SIP) 563 [RFC3261], and Session Description Protocol (SDP) [RFC2327] 564 [RFC3266] on the one hand (Mm-interface), and on the actual user 565 data traffic level on the other (Mb-interface). 567 SIP and SDP transition has to be made in an SIP/SDP Application 568 Level Gateway. The ALG has to change the IP addresses transported 569 in the SIP messages and the SDP payload of those messages to the 570 appropriate version. In addition, there has to be interoperability 571 for DNS queries; see section 4.1 for details. 573 On the user data transport level, the translation is IPv4-IPv6 574 protocol translation, where the user data traffic transported is 575 translated from IPv6 to IPv4, and vice versa. 577 The legacy IPv4 host's address can be mapped to an IPv6 address for 578 the IMS, and this address is then used within the IMS to route the 579 traffic to the appropriate user traffic translator. This mapping 580 can be done by the SIP/SDP ALG for the SIP traffic. The user 581 traffic translator would do the similar mapping for the user 582 traffic. However, in order to have an IPv4 address for the IMS UE, 583 and to be able to route the user traffic within the legacy IPv4 584 network to the correct translator, there has to be an IPv4 address 585 allocated for the duration of the session from the user traffic 586 translator. The allocation of this address from the user traffic 587 translator has to be done by the SIP/SDP ALG in order for the 588 SIP/SDP ALG to know the correct IPv4 address. This can be achieved 589 by using a protocol for the ALG to do the allocation such as MEGACO 590 [RFC3015]. 592 +-------------------------------+ +----------+ 593 | +------+ | |+--------+| 594 | |S-CSCF|---||SIP ALG ||\ 595 | | +------+ | |+--------+| \ -------- 596 +-|+ | / | | | | | | 597 | | | +------+ +------+ | | + | -| |- 598 | |-|-|P-CSCF|--------|I-CSCF| | | | | | () | 599 | | +------+ +------+ | |+--------+| / ------ 600 | |-----------------------------------|| NAT-PT ||/ 601 +--+ | IPv6 | |+--------+| IPv4 602 UE | | | | 603 | IP Multimedia CN Subsystem | |Translator| 604 +-------------------------------+ +----------+ 605 Figure 1: UE using IMS to contact a legacy phone 607 Figure 1 shows a possible configuration scenario where the SIP ALG 608 is separate to the CSCFs. The translator can either be set up in a 609 single device with both SIP translation and media translation, or 610 those functionalities can be divided to two different entities with 611 an interface in between. 613 4.3 Two IMS islands connected over IPv4 network 615 At the early stages of IMS deployment, there may be cases where two 616 IMS islands are separated by an IPv4 network such as the legacy 617 Internet. Here both the UEs and the IMS islands are IPv6-only. 618 However, the IPv6 islands are not native IPv6 connected. 620 In this scenario, the end-to-end SIP connections would be based on 621 IPv6. The only issue is to make connection between two IPv6-only 622 IMS islands over IPv4 network. So, in practice, this scenario is 623 very closely related to GPRS scenario represented in section 4.2. 625 IPv4 / IPv6 interworking can be taken care of in the network; the 626 basic options are static and dynamic tunneling. The tunnel starting 627 point or endpoint should be located on the edge of the IMS domain. 628 Static "IPv6 in IPv4" tunnels configured between different IMS 629 domains would be a good solution. Note that this scenario is 630 comparable to 6bone [6BONE] network operation. 632 5. Security Considerations 634 1. Problems have been identified in the case of the 635 reachability of IPv4 and IPv6 nodes (use of DNS through 636 NAT-PT). NAT-PT DNS ALG problems are described in [NATPT- 637 DNS] and [Unmaneval]. 639 2. The 3GPP specifications do not currently define the usage 640 of DNS Security. They neither disallow the usage of DNSSEC, 641 nor do they mandate it. 643 3. NAT-PT breaks DNSSEC. 645 6. Changes from draft-wiljakka-3gpp-ipv6-transition-02.txt 647 - Name changed from Solutions document to Analysis document 648 - Tunneling text changes especially in section 3.2 649 - Changes in NA(P)T-PT text in section 3.4 650 - Editorial changes in some sections 652 7. References 654 [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: 655 Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. 657 [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description 658 Protocol, RFC 2327, April 1998. 660 [RFC2663] Srisuresh, P., Holdrege, M.: IP Network Address 661 Translator (NAT) Terminology and Considerations, RFC 2663, August 662 1999. 664 [RFC2765] Nordmark, E.: Stateless IP/ICMP Translation Algorithm 665 (SIIT), RFC 2765, February 2000. 667 [RFC2766] Tsirtsis, G., Srisuresh, P.: Network Address Translation 668 - Protocol Translation (NAT-PT), RFC 2766, February 2000. 670 [RFC2893] Gilligan, R., Nordmark, E.: Transition Mechanisms for 671 IPv6 Hosts and Routers, RFC 2893, August 2000. 673 [RFC3015] Cuervo, F., et al: Megaco Protocol Version 1.0, RFC 3015, 674 November 2000. 676 [RFC3056] Carpenter, B., Moore, K.: Connection of IPv6 Domains via 677 IPv4 Clouds, RFC 3056, February 2001. 679 [RFC3261] J. Rosenberg, et al: SIP: Session Initiation Protocol, 680 June 2002. 682 [RFC3266] S. Olson, G. Camarillo, A. B. Roach: Support for IPv6 in 683 Session Description Protocol (SDP), June 2002. 685 [RFC3314] Wasserman, M. (editor): "Recommendations for IPv6 in 3GPP 686 Standards", September 2002. 688 [3GPP-SCEN] Soininen, J. (editor): "Transition Scenarios for 3GPP 689 Networks", October 2002, draft-ietf-v6ops-3gpp-cases-00.txt, work 690 in progress. 692 [6to4SEC] Savola, P.: "Security Considerations for 6to4", December 693 2002, draft-savola-v6ops-6to4-security-01.txt, work in progress. 695 [BGP] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le 696 Faucheur, F.: "Connecting IPv6 Islands across IPv4 Clouds with 697 BGP", October 2002, draft-ooms-v6ops-bgp-tunnel-00.txt, work in 698 progress. 700 [DNSreq] Durand, A., Ihren, J.: "NGtrans IPv6 DNS operational 701 requirements and roadmap", March 2002, draft-ietf-ngtrans-dns-ops- 702 req-04.txt, work in progress, the draft has expired. 704 [DSTM] Bound, J., et al: "Dual Stack Transition Mechanism (DSTM)", 705 July 2002, draft-ietf-ngtrans-dstm-08.txt, work in progress. 707 [IGP] Cristallo, G., Gastaud, G., Ooms, D., Galand, D., Preguica, 708 C., Baudot, A., Diribarne, G.: "Connecting IPV6 islands within an 709 IPV4 AS", February 2002, draft-many-ngtrans-connect-ipv6-igp- 710 01.txt, work in progress, the draft has expired. 712 [ISATAP] Templin, F., et al: "Intra-Site Automatic Tunnel 713 Addressing Protocol (ISATAP)", October 2002, draft-ietf-ngtrans- 714 isatap-05.txt, work in progress. 716 [NAT64] Durand, A.: "NAT64 - NAT46", June 2002, draft-durand- 717 ngtrans-nat64-nat46-00.txt, work in progress. 719 [NATPT-DNS] Durand, A.: "Issues with NAT-PT DNS ALG in RFC2766", 720 January 2002, draft-durand-natpt-dns-alg-issues-00.txt, work in 721 progress, the draft has expired. 723 [TEREDO] Huitema, C.: "Teredo: Tunneling IPv6 over UDP Through 724 NATs", September 2002, draft-ietf-ngtrans-shipworm-08.txt, work in 725 progress. 727 [Unmaneval] Huitema, C., Austein, R., Dilettante, B., Satapati, S., 728 van der Pol, R.: "Evaluation of Transition Mechanisms for Unmanaged 729 Networks", November 2002, draft-huitema-ngtrans-unmaneval-01.txt, 730 work in progress. 732 [v6namespace] Ihren, J.: "IPv4-to-IPv6 migration and DNS namespace 733 fragmentation", March 2002, draft-ietf-dnsop-v6-name-space- 734 fragmentation-01.txt, work in progress, the draft has expired. 736 [3GPP-23.060] 3GPP TS 23.060 V5.2.0, "General Packet Radio Service 737 (GPRS); Service description; Stage 2 (Release 5)", June 2002. 739 [3GPP-23.228] 3GPP TS 23.228 V5.5.0, "IP Multimedia Subsystem 740 (IMS); Stage 2 (Release 5)", June 2002. 742 [3GPP 24.228] 3GPP TS 24.228 V5.0.0, "Signalling flows for the IP 743 multimedia call control based on SIP and SDP; Stage 3 (Release 5)", 744 March 2002. 746 [3GPP 24.229] 3GPP TS 24.229 V5.0.0, "IP Multimedia Call Control 747 Protocol based on SIP and SDP; Stage 3 (Release 5)", March 2002. 749 [6BONE] http://www.6bone.net 751 8. Authors and Acknowledgements 753 This document is written by: 755 Alain Durand, Sun Microsystems 756 757 Karim El-Malki, Ericsson Radio Systems 758 760 Paul Francis, Tahoe Networks 761 763 Niall Richard Murphy, Enigma Consulting Limited 764 766 Hugh Shieh, AT&T Wireless 767 769 Jonne Soininen, Nokia 770 772 Hesham Soliman, Ericsson Radio Systems 773 775 Margaret Wasserman, Wind River 776 778 Juha Wiljakka, Nokia 779 781 The authors would like to thank Gabor Bajko, Ajay Jain, Ivan 782 Laloux, Pedro Serna, Fred Templin, Anand Thakur and Rod Van Meter 783 for their valuable input. 785 9. Editor's Contact Information 787 Comments or questions regarding this document should be sent to the 788 v6ops mailing list or directly to the document editor: 790 Juha Wiljakka 791 Nokia 792 Sinitaival 5 Phone: +358 7180 47562 793 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com