idnits 2.17.1 draft-soininen-ngtrans-3gpp-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack 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 (April 2002) is 8045 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) == Outdated reference: A later version (-01) exists of draft-ietf-ipv6-3gpp-recommend-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-3gpp-recommend (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Soininen 3 Document: draft-soininen-ngtrans-3gpp-cases-00.txt J. Wiljakka 4 Expires: October 2002 Nokia 5 A.Durand 6 Sun Microsystems 7 P. Francis 8 Tahoe Networks 9 April 2002 11 Transition Scenarios for 3GPP Networks 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes different scenarios in Third Generation 36 Partnership Project (3GPP) defined packet network, i.e. General 37 Packet Radio Service (GPRS) that would need IP version 6 and IP 38 version 4 transition. The focus of this document is on the scenarios 39 where the User Equipment (UE) connects to nodes in other networks, 40 e.g. in the Internet. GPRS network internal transition scenarios, 41 i.e. between different GPRS elements in the network, are out of scope 42 of this document. 44 The purpose of the document is to list the scenarios for further 45 discussion and study. 47 Table of Contents 49 1. Introduction...................................................2 50 2. Scope of the document..........................................2 51 3. Transition scenarios...........................................2 52 3.1 GPRS Scenarios.............................................3 53 3.2 Transition scenarios with IMS..............................4 54 4. Security Considerations........................................5 55 Acknowledgements..................................................5 56 References........................................................5 57 Author's Addresses................................................5 59 Copyright 61 (C) The Internet Society (2002). All Rights Reserved. 63 1. Introduction 65 This document will describe the transition scenarios in 3GPP packet 66 data networks that might come up in the deployment phase of IPv6. 67 The main purpose of this document is to identify, and document those 68 scenarios for further discussion, and for study in the NGTRANS 69 working group. 71 This document does give neither an overview, nor an explanation of 72 3GPP or the 3GPP packet data network - the GPRS. A good overview of 73 the 3GPP specified GPRS can be found from [1]. The GPRS architecture 74 specification is defined in [2]. 76 2. Scope of the document 78 The scope of this document is to describe the possible transition 79 scenarios in the 3GPP defined GPRS network where a UE connects to, or 80 is contacted from the Internet, or another UE. The document describes 81 scenarios with and without the usage of the SIP based IP Multimedia 82 Core Network Subsystem (IMS). 84 The scope of this document does not include scenarios inside the GPRS 85 network, i.e. on the different interfaces of the GPRS network. In 86 addition, this document does not identify solutions - just possible 87 scenarios. 89 These scenarios may, or may not be found feasible, or even likely in 90 further study. 92 3. Transition scenarios 94 This section is divided into two main parts - GPRS scenarios, and 95 scenarios with the IP Multimedia Subsystem (IMS). The first part - 96 GPRS scenarios - concentrate on scenarios with a User Equipment (UE) 97 connecting to services in the Internet, e.g. mail, web. The second 98 part - IMS scenarios - then describes how an IMS capable UE can 99 connect to other SIP capable nodes in the Internet using the IMS 100 services. 102 3.1 GPRS Scenarios 104 This section describes the scenarios that might occur when a GPRS UE 105 contacts services, or nodes outside the GPRS network, e.g. web-server 106 in the Internet. 108 Transition scenarios of the GPRS internal interfaces are outside of 109 the scope of this document. 111 The following scenarios are described here. In all of the scenarios, 112 the UE is part of a network where there is at least one router of the 113 same IP version, i.e. GGSN, and it is connecting to a node in a 114 different network. 116 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 117 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 118 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 119 4) IPv6 UE connecting to an IPv4 node 120 5) IPv4 UE connecting to an IPv6 node 122 1) Dual Stack UE connecting to IPv4 and IPv6 nodes 124 The GPRS system has been designed in a manner that there is the 125 possibility to have simultaneous IPv4, and IPv6 PDP Contexts open. 126 Thus, in cases where the UE is dual stack capable, and in the network 127 there is a GGSN (or separate GGSNs) that supports both connection to 128 IPv4, and IPv6 networks, it is possible to connect to both at the 129 same time. 131 However, the IPv4 addresses might be a scarce resource for the mobile 132 operator or an ISP. In that case, it might not be possible for the UE 133 to have a globally unique IPv4 address allocated all the time. Hence, 134 either activating the IPv4 PDP Context only when needed, or having an 135 IPv4 address from a private address space. 137 2) IPv6 UE connecting to an IPv6 node through an IPv4 network 139 Especially in the first stages of IPv6 deployment, there are cases 140 where an IPv6 node would need to connect to the IPv6 Internet through 141 a network that is IPv4. For instance this can be seen in current 142 fixed networks, where the access is provided in IPv4 only, but there 143 is an IPv6 network deeper in the Internet. 145 In this case, in the GPRS system, the UE would be IPv6 capable, and 146 the GPRS network would be IPv6 capable of providing an IPv6 capable 147 GGSN in the network. However, the operator only has an IPv4 network 148 as such. 150 3) IPv4 UE connecting to an IPv4 node through an IPv6 network 152 Further in the future, there are cases where the legacy UEs are still 153 IPv4 only, capable of connecting to the legacy IPv4 Internet. 154 However, the GPRS operator network has already been upgraded to IPv6. 156 In this case, the operator would still provide the IPv4 capable GGSN, 157 and a connection through the IPv6 network to the IPv4 Internet. 159 4) IPv6 UE connecting to an IPv4 node 161 In this scenario an IPv6 UE connects to an IPv4 node in the IPv4 162 Internet. As an example, an IPv6 UE connects to an IPv4 web server in 163 the legacy Internet. 165 5) IPv4 UE connecting to an IPv6 node 167 This is similar to the case above, but to the opposite direction. 168 Here an IPv4 UE connects to an IPv6 node in the IPv6 Internet. As an 169 example, a legacy IPv4 UE is connected to an IPv6 server in the IPv6 170 Internet. 172 3.2 Transition scenarios with IMS 174 IP Multimedia Core Network Subsystem (IMS) is a SIP based multimedia 175 service architecture. It is specified in the Release 5 of 3GPP. It 176 comprises a set of SIP proxies, servers, and registrars. In addition, 177 there are Media Gateways (MGWs) that offer connections to non-IP 178 networks such as the Public Switched Telephony Network (PSTN). 180 IMS is exclusively IPv6. Hence, all the traffic for the IMS is IPv6, 181 even if the UE would be dual stack capable. More information on IMS 182 can be found in [3]. 184 As IMS is exclusively IPv6, the number of possible transition 185 scenarios is reduced dramatically. In the following, the possible 186 transition scenarios are listed. 188 1) UE connecting to a node in an IPv4 network through IMS 189 2) Two IPv6 IMS connected via an IPv4 191 1) UE connecting to a node in an IPv4 network through IMS 193 This scenario occurs when an IMS UE (IPv6) connects to a node in the 194 IPv4 Internet through the IMS, or vice versa. This happens when the 195 other node is a part of a different system than 3GPP, e.g. a fixed 196 PC, with only IPv4 capabilities. 198 2) Two IPv6 IMS connected via an IPv4 200 At the early stages of IMS deployment, there may be cases where two 201 IMS islands are separated on IPv4 network such as the legacy 202 Internet. Here both the UEs are IPv6 and the IMSes where the UEs are 203 IPv6. However, the IPv6 islands are not native IPv6 connected. 205 4. Security Considerations 207 This document does not generate any additional security 208 considerations. 210 Acknowledgements 212 The authors would like to thank Basavaraj Patil, Tuomo Sipila, and 213 Jens Staack for good input, and comments that helped writing this 214 document. 216 References 217 [1] Wasserman, M. et al, "Recommendations for IPv6 in 3GPP 218 Standards", January 2002, draft-ietf-ipv6-3gpp-recommend-00.txt. 220 [2] 3GPP TS 23.060 v 3.11.0, "General Packet Radio Service (GPRS); 221 Service description; Stage 2(Release 1999)", March 2002. 223 [3] 3GPP TS 23.228 v 5.3.0, " IP Multimedia Subsystem (IMS); Stage 224 2(Release 5)", January 2002. 226 Author's Addresses 228 Jonne Soininen 229 Nokia 230 313 Fair Child Dr. Phone: +1-650-864-6794 231 Mountain View, CA, USA Email: jonne.Soininen@nokia.com 233 Juha Wiljakka 234 Nokia 235 Visiokatu 3 Phone: +358 7180 47562 236 FIN-33720 TAMPERE, Finland Email: juha.wiljakka@nokia.com 237 Alain Durand 238 Sun Microsystems 239 901 San Antonio rd UMPK17-202 240 Palo Alto, CA, USA Email: Alain.Durand@sun.com 242 Paul Francis 243 Tahoe Networks 244 3052 Orchard Dr. Phone: +1-408-944-8632 245 San Jose CA, USA Email: francis@tahoenetworks.com