idnits 2.17.1 draft-ietf-ipv6-3gpp-recommend-01.txt: ** The Abstract section seems to be numbered 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 Introduction section. ** 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 8048 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2460' is mentioned on line 243, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'PPPV6' is mentioned on line 520, but not defined == Unused Reference: 'IPV6' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'IPV6ETH' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'PPPv6' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'CELLREQ' is defined on line 940, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OLD-TS23060' -- Possible downref: Non-RFC (?) normative reference: ref. 'NEW-TS23060' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-URL' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-URL' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR21905' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2461 (ref. 'IPV6ND') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. 'AUTOCONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (ref. 'PRIVADDR') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2472 (ref. 'PPPv6') (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-02) exists of draft-thaler-ipngwg-multilink-subnets-01 -- Possible downref: Normative reference to a draft: ref. 'MULTLINK' -- Possible downref: Normative reference to a draft: ref. 'SITEREN' ** Downref: Normative reference to an Informational draft: draft-durand-huitema-h-density-ratio (ref. 'HD') ** Obsolete normative reference: RFC 3177 (ref. 'IABAA') (Obsoleted by RFC 6177) -- Possible downref: Non-RFC (?) normative reference: ref. 'AAPOL' == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-scoping-arch-02 -- Possible downref: Normative reference to a draft: ref. 'SCOPARCH' == Outdated reference: A later version (-02) exists of draft-manyfolks-ipv6-cellular-host-01 -- Possible downref: Normative reference to a draft: ref. 'CELLREQ' == Outdated reference: A later version (-02) exists of draft-haberman-ipngwg-auto-prefix-01 -- Possible downref: Normative reference to a draft: ref. 'PREFDEL' Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Wasserman, Editor 3 Document: draft-ietf-ipv6-3gpp-recommend-01.txt Wind River 4 Expires: October 2002 April 2002 6 Recommendations for IPv6 in 3GPP Standards 8 1 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [RFC2026]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 2 Abstract 31 This document contains recommendations from the Internet 32 Engineering Task Force (IETF) IPv6 Working Group to the Third 33 Generation Partnership Project (3GPP) community regarding the use 34 of IPv6 in the 3GPP standards. Specifically, this document 35 recommends that the 3GPP: 37 1. Specify that multiple prefixes may be assigned to each 38 primary PDP context, 39 2. Require that a given prefix must not be assigned to more 40 than one primary PDP context, and 41 3. Allow 3GPP nodes to use multiple identifiers within those 42 prefixes, including randomly generated identifiers. 44 The IPv6 Working Group supports the use of IPv6 within 3GPP and 45 offers these recommendations in a spirit of open cooperation 46 between the IPv6 Working Group and the 3GPP community. Since the 47 original publication of this document as an Internet-Draft, the 48 3GPP has adopted the primary recommendations of this document. 50 3 Copyright Notice 52 Copyright (C) The Internet Society (2001). All Rights Reserved. 54 4 Conventions Used In This Document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC 2119 59 [KEYWORD]. 61 5 Table of Contents 63 1 Status of this Memo.......................................1 64 2 Abstract..................................................1 65 3 Copyright Notice..........................................1 66 4 Conventions Used In This Document.........................2 67 5 Table of Contents.........................................2 68 6 Introduction..............................................3 69 6.1 What is the 3GPP?.........................................3 70 6.2 What is the IETF?.........................................4 71 6.3 Terminology...............................................4 72 6.3.1 3GPP Terminology..........................................5 73 6.3.2 IETF Terminology..........................................5 74 6.4 Overview of the IPv6 Addressing Architecture..............6 75 6.5 An IP-Centric View of the 3GPP System.....................7 76 6.5.1 Overview of the UMTS Architecture.........................7 77 6.5.2 The PDP Context...........................................9 78 6.5.3 IPv6 Address Autoconfiguration in GPRS...................11 79 7 Recommendations to the 3GPP..............................13 80 7.1 Limitations of 3GPP Address Assignment...................13 81 7.2 Advertising Multiple Prefixes............................14 82 7.3 Assigning a Prefix to Only One Primary PDP Context.......14 83 7.3.1 Is a /64 per PDP Context Too Much?.......................14 84 7.3.2 Prefix Information in the SGSN...........................15 85 7.4 Multiple Identifiers per PDP Context.....................15 86 8 Additional IPv6 Work Items...............................17 87 9 Security Considerations..................................17 88 10 Appendix A: Analysis of Findings........................18 89 10.1 Address Assignment Solutions.............................18 90 11 References...............................................20 91 12 Authors and Acknowledgements.............................22 92 13 Editor's Contact Information.............................22 93 6 Introduction 95 In May 2001, the IPv6 Working Group (WG) held an interim meeting in 96 Redmond, WA to discuss the use of IPv6 within the 3GPP standards. 97 An architectural overview of 3GPP was presented, and there was much 98 discussion regarding the use of IPv6 within 3GPP. At that meeting, 99 a decision was made to form a design team to write a document 100 offering advice from the IPv6 WG to the 3GPP community regarding 101 their use of IPv6. This document is the result of that effort. 103 This document offers recommendations to the 3GPP community from the 104 IETF IPv6 Working Group. It is organized into three main sections: 106 1. An introduction (this section) that provides background 107 information regarding the IETF IPv6 WG and the 3GPP and 108 includes a high-level overview of the technologies discussed 109 in this document. 111 2. Recommendations from the IPv6 WG to the 3GPP community. 112 These can be found in section 7. 114 3. Further work items that should be considered by the IPv6 WG. 115 These items are discussed in section 8. 117 It is the purpose of this document to provide advice from the IPv6 118 Working Group to the 3GPP community. We have limited the contents 119 of this document to items that are directly related to the use of 120 IPv6 within 3GPP. This document defines no standards, and it is 121 not a definitive source of information regarding IPv6 or 3GPP. We 122 have not chosen to explore 3GPP-related issues with other IETF 123 protocols (i.e. SIP, IPv4, etc.), as they are outside the scope of 124 the IPv6 Working Group. 126 The IPv6 Working Group fully supports the use of IPv6 within 3GPP, 127 and we encourage 3GPP implementers and operators to participate in 128 the IETF process. We are offering these suggestions in a spirit of 129 open cooperation between the IPv6 Working Group and the 3GPP 130 community, and we hope that our ongoing cooperation will help to 131 strengthen both sets of standards. 133 The 3GPP address allocation information in this document is based 134 on the 3GPP document TS 23.060 version 4.1.0 [OLD-TS23060]. At the 135 3GPP plenary meeting TSG #15 in March 2002, the 3GPP adopted the 136 two primary recommendations contained in this document, allocating 137 a unique prefix to each primary PDP context when IPv6 stateless 138 address autoconfiguration is used, and to allow the terminals to 139 use multiple interface identifiers. These changes were 140 retroactively applied from 3GPP release 99 onwards, in TS23.060 141 versions 3.11.0, 4.4.0 and 5.1.0 [NEW-TS23060]. 143 6.1 What is the 3GPP? 145 The Third Generation Partnership Project (3GPP) is a global 146 standardization partnership founded in late 1998. Its 147 Organizational Partners have agreed to co-operate in the production 148 of technical specifications for a Third Generation Mobile System 149 based on the evolved GSM core networks. 151 The 3GPP Organizational Partners consist of several different 152 standardization organizations: ETSI from Europe, Standards 153 Committee T1 Telecommunications (T1) in the USA, China Wireless 154 Telecommunication Standard Group (CWTS), Korean Telecommunications 155 Technology Association (TTA), the Association of Radio Industries 156 and Businesses (ARIB) and the Telecommunication Technology 157 Committee(TTC) in Japan. 159 The work is coordinated by a Project Co-ordination Group (PCG), and 160 structured into Technical Specification Groups (TSGs). There are 161 five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), 162 Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network 163 (GERAN), and the Terminals (TSG T). The TSGs are further divided 164 into Working Groups (WGs). The technical work is done in the 165 working groups, and later approved in the TSGs. 167 3GPP working methods are different from IETF working methods. The 168 major difference is where the major part of the work is done. In 169 3GPP, the work is done in face-to-face meetings, and the mailing 170 list is used mainly for distributing contributions, and for 171 handling documents that were not handled in the meeting due to lack 172 of time. Decisions are usually made by consensus, though voting 173 does exist. However, it is rather rare to vote. 3GPP documents are 174 public and can be accessed via the 3GPP web site [3GPP-URL]. 176 6.2 What is the IETF? 178 The Internet Engineering Task Force (IETF) is a large open 179 international community of network designers, operators, vendors, 180 and researchers concerned with the evolution of the Internet 181 architecture and the smooth operation of the Internet. The IETF is 182 also the primary standards body developing Internet protocols and 183 standards. It is open to any interested individual. More 184 information about the IETF can be found at the IETF web site [IETF- 185 URL]. 187 The actual technical work of the IETF is done in working groups, 188 which are organized by topic into several areas (e.g., routing, 189 transport, security, etc.). The IPv6 Working Group is chartered 190 within the Internet area of the IETF. Much of the work is handled 191 via mailing lists, and the IETF holds meetings three times per 192 year. 194 6.3 Terminology 196 This section defines the 3GPP and IETF terminology used in this 197 document. The 3GPP terms and their meanings have been taken from 198 [TR21905]. 200 6.3.1 3GPP Terminology 202 APN Access Point Name. The APN is a logical name referring 203 to a GGSN and an external network. 205 CS Circuit Switched 207 GERAN GSM/EDGE Radio Access Network 209 GGSN Gateway GPRS Support Node. A router between the GPRS 210 network and an external network (i.e. the Internet). 212 GPRS General Packet Radio Services 214 GTP-U General Tunneling Protocol - User Plane 216 MT Mobile Termination. For example, a mobile phone 217 handset. 219 PDP Packet Data Protocol 221 PDP Context A PDP connection between the UE and the GGSN. 223 PS Packet Switched 225 SGSN Serving GPRS Support Node 227 TE Terminal Equipment. For example, a laptop attached 228 through a 3GPP handset. 230 UE User Equipment (TE + MT + USIM). An example would be 231 a mobile handset with a USIM card inserted and a 232 laptop attached. 234 UMTS Universal Mobile Telecommunications System 236 USIM Universal Subscriber Identity Module. Typically, a 237 card that is inserted into a mobile phone handset. 239 UTRAN Universal Terrestrial Radio Access Network 241 6.3.2 IETF Terminology 243 IPv6 Internet Protocol version 6 [RFC 2460] 245 NAS Network Access Server 247 NAT Network Address Translator 249 NAT-PT Network Address Translation with Protocol Translation. 250 An IPv6 transition mechanism. [NAT-PT] 252 PPP Point-to-Point Protocol [PPP] 253 SIIT Stateless IP/ICMP Transition Mechanism [SIIT] 255 6.4 Overview of the IPv6 Addressing Architecture 257 The recommendations in this document are primarily related to IPv6 258 address assignment. To fully understand the recommended changes, 259 it is necessary to understand the IPv6 addressing architecture, and 260 current IPv6 address assignment mechanisms. 262 The IPv6 addressing architecture represents a significant evolution 263 from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes 264 be able to assemble their own addresses from interface identifiers 265 and prefix information. This mechanism is called IPv6 Host 266 Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure 267 themselves without the need for stateful configuration servers 268 (i.e. DHCPv6) or statically configured addresses. 270 Interface identifiers can be globally unique, such as modified EUI- 271 64 addresses [ADDRARCH], or non-unique, such as randomly generated 272 identifiers. Hosts that have a globally unique identifier 273 available may also choose to use randomly generated addresses for 274 privacy [PRIVADDR] or for other reasons. IPv6 hosts are free to 275 generate new identifiers at any time, and Duplicate Address 276 Detection (DAD) is used to protect against the use of duplicate 277 identifiers on a single link [IPV6ND]. 279 A constant link-local prefix can be combined with any interface 280 identifier to build an address for communication on a locally 281 attached link. IPv6 routers may advertise additional prefixes 282 (site-local and/or global prefixes)[IPV6ND]. Hosts can combine 283 advertised prefixes with their own interface identifiers to create 284 addresses for site-local and global communication. 286 IPv6 introduces architectural support for scoped unicast addressing 287 [SCOPARCH]. A single interface will typically have multiple 288 addresses for communication within different scopes: link-local, 289 site-local and/or global [ADDRARCH]. Link-local addresses allow 290 for local communication, even when an IPv6 router is not present. 291 Some IPv6 protocols (i.e. routing protocols) require the use of 292 link-local addresses. Site-local addressing allows communication 293 to be administratively contained within a single site. Link-local 294 or site-local connections may also survive changes to global prefix 295 information (e.g. site renumbering). 297 IPv6 explicitly associates each address with an interface. 298 Multiple-interface hosts may have interfaces on more than one link 299 or in more than one site. Links and sites are internally 300 identified using zone identifiers. Proper routing of non-global 301 traffic and proper address selection are ensured by the IPv6 scoped 302 addressing architecture [SCOPARCH]. 304 IPv6 introduces the concept of privacy addresses [PRIVADDR]. These 305 addresses are generated from an advertised global prefix and a 306 randomly generated identifier, and are used for anonymous access to 307 Internet services. Applications control the generation of privacy 308 addresses, and new addresses can be generated at any time. 310 The IPv6 site renumbering specification [SITEREN] relies upon the 311 fact that IPv6 nodes will generate new addresses when new prefixes 312 are advertised on the link, and that they will deprecate addresses 313 that use deprecated prefixes. 315 In the future, additional IPv6 specifications may rely upon the 316 ability of IPv6 nodes to use multiple prefixes and/or multiple 317 identifiers to dynamically create new addresses. 319 6.5 An IP-Centric View of the 3GPP System 321 The 3GPP specifications define a Third Generation Mobile System. 322 An overview of the packet switched (PS) domain of the 3GPP Release 323 99 system is described in the following sections. The authors hope 324 that this description is sufficient for the reader who is 325 unfamiliar with the UMTS packet switched service to understand how 326 the UMTS system works, and how IPv6 is currently defined to be used 327 within it. 329 6.5.1 Overview of the UMTS Architecture 331 The UMTS architecture can be divided into two main domains -- the 332 packet switched (PS) domain, and the circuit switched (CS) domain. 333 In this document, we will concentrate on the PS domain, or General 334 Packet Radio Services (GPRS). 336 ------ 337 | TE | 338 ------ 339 | 340 +R 341 | 342 ------ Uu ----------- Iu ----------- Gn ----------- Gi 343 | MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+-- 344 ------ ----------- ----------- ----------- 345 (UE) 347 Figure 1: Simplified GPRS Architecture 348 ------ 349 | | 350 | App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 351 | | 352 |------| ------------- 353 | IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |-> 354 | v4/6 | | v4/6 | 355 |------| ------------- ------------- |------ | 356 | | | \ Relay / | | \ Relay / | | | | 357 | | | \ / | | \ / | | | | 358 | | | \ / | | \ / | | | | 359 | PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U | | 360 | | | | | | | | | | | 361 |------| |------|------| |------|------| |------| | 362 | | | | UDP |- - -| UDP | UDP |- - -| UDP | | 363 | | | |------| |------|------| |------| | 364 | RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | | 365 | | | | v4/6 | | v4/6 | v4/6 | |v4/6 | | 366 |------| |------|------| |------|------| |------|------| 367 | MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 | 368 |------| |------|------| |------|------| |------|------| 369 | L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 | 370 ------ ------------- ------------- ------------- 372 UE UTRAN SGSN GGSN 373 (handset) 374 Figure 2: GPRS Protocol Stacks 376 ------ 377 | | 378 | App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer) 379 | | 380 |------| 381 | | 382 | IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN) 383 | v4/6 | 384 | | | | 385 |------| |-------------| 386 | | | \ Relay / | 387 | | | \ / | 388 | | | \ / | 389 | | | \ / PDCP|- - - (to UTRAN) 390 | | | | | 391 | PPP |- - -| PPP |------| 392 | | | | RLC |- - - (to UTRAN) 393 | | | |------| 394 | | | | MAC | 395 |------| |------|------| 396 | L1a |- - -| L1a | L1b |- - - (to UTRAN) 397 ------ ------------- 398 TE MT 399 (laptop) (handset) 401 Figure 3: Laptop Attached to 3GPP Handset 402 The GPRS core network elements shown in Figures 1 and 2 are the 403 User Equipment (UE), Serving GPRS Support Node (SGSN) and Gateway 404 GPRS Support Node (GGSN). The UTRAN comprises Radio Access Network 405 Controllers (RNC) and the UTRAN base stations. 407 GGSN A specialized router that functions as the gateway between the 408 GPRS network and the external networks, e.g. Internet. It also 409 gathers charging information about the connections. In many 410 ways the GGSN is similar to a Network Access Server (NAS). 412 SGSN The SGSN's main functions include authentication, 413 authorization, mobility management, and collection of billing 414 information. The SGSN is connected to the SS7 network and 415 through that to the Home Location Register (HLR), so that it 416 can perform user profile handling, authentication, and 417 authorization. 419 GTP-U is a simple tunnelling protocol running over UDP/IP 420 and used to route packets between RNC, SGSN and GGSN within the 421 same, or between different, UMTS backbone(s). A GTP-U tunnel is 422 identified at each end by a Tunnel Endpoint Identifier (TEID). 424 Only the most significant elements of the GPRS system are discussed 425 in this document. More information about the GPRS system can be 426 found in [OLD-TS23060]. 428 6.5.2 The PDP Context 430 The most important 3GPP concept in this context is a PDP Context. A 431 PDP Context is a connection between the UE and the GGSN, over which 432 the packets are transferred. There are two kinds of PDP Contexts -- 433 primary, and secondary. 435 The primary PDP Context initially defines the link to the GGSN. For 436 instance, an IP address is assigned to each primary PDP Context. In 437 addition, one or more secondary PDP Contexts can be added to a 438 primary PDP Context, sharing the same IP address. These secondary 439 PDP Contexts can have different Quality of Service characteristics 440 than the primary PDP Context. 442 Together a primary PDP Context and zero or more secondary PDP 443 Contexts define, in IETF terms, a link. GPRS links are point-to- 444 point. Once activated, all PDP contexts have equal status, meaning 445 that a primary PDP context can be deleted while keeping the link 446 between the UE and the GGSN, as long as there are other (secondary) 447 PDP contexts active for the same IP address. 449 There are currently three PDP Types supported in GPRS -- IPv4, 450 IPv6, and PPP. This document will only discuss the IPv6 PDP Type. 452 There are three basic actions that can be performed on a PDP 453 Context: PDP Context Activation, Modification, and Deactivation. 454 These actions are described in the following. 456 Activate PDP Context 458 Opens a new PDP Context to a GGSN. If a new primary 459 PDP Context is activated, there is a new link created 460 between a UE and a GGSN. A UE can open multiple 461 primary PDP Contexts to one or more GGSNs. 463 Modify PDP Context 465 Changes the characteristics of a PDP Context, for 466 example QoS attributes. 468 Deactivate PDP Context 470 Deactivates a PDP Context. If a primary PDP Context 471 and all secondary PDP contexts associated with it are 472 deactivated, a link between the UE and the GGSN is 473 removed. 475 The APN is a name which is logically linked to a GGSN. The APN may 476 identify a service or an external network. The syntax of the APN 477 corresponds to a fully qualified domain name. At PDP context 478 activation, the SGSN performs a DNS query to find out the GGSN(s) 479 serving the APN requested by the terminal. The DNS response 480 contains a list of GGSN addresses from which the SGSN selects one 481 (in a round-robin fashion). 483 --------- -------- 484 | | | GGSN | 485 | | LINK 1 | | 486 | -======== PDP Context A ========- - - -> ISP X 487 | | | | 488 | | | | 489 | | | | 490 | /======= PDP Context B =======\ | 491 | - | LINK 2 | - - - -> ISP Y 492 | \======= PDP Context C =======/ | 493 | | | | 494 | MT | -------- 495 |(handset)| 496 | | -------- 497 -------- | | | GGSN | 498 | | | | LINK 3 | | 499 | | | -======== PDP Context D ========- | 500 | TE | | | | | 501 |(laptop)| | | | - - -> ISP Z 502 | | | | LINK 4 | | 503 | -====PPP====-----======== PDP Context E ========- | 504 | | | | | | 505 | | | | | | 506 -------- --------- -------- 508 Figure 3: Correspondence of PDP Contexts to IPv6 Links 509 6.5.3 IPv6 Address Autoconfiguration in GPRS 511 GPRS supports static and dynamic address allocation. Two types of 512 dynamic address allocation are supported -- stateless, and 513 stateful. Stateful address configuration uses an external protocol 514 to connect to a server that gives the IP address, e.g. DHCP. 516 The stateless IPv6 autoconfiguration works differently in GPRS than 517 in Ethernet networks. GPRS nodes have no unique identifier, whereas 518 Ethernet nodes can create an identifier from their EUI-48 address. 519 Because GPRS networks are similar to dialup networks, the stateless 520 address autoconfiguration in GPRS was based on PPPv6 [PPPV6]. 522 3GPP address autoconfiguration has the following steps: 524 1. The Activate PDP Context message is sent to the SGSN (PDP 525 Type=IPv6, PDP Address = 0, etc.). 527 2. The SGSN sends a Create PDP Context message to the GGSN with 528 the above parameters. 530 3. GGSN chooses an interface identifier for the PDP Context and 531 creates the link-local address. It answers the SGSN with a 532 Create PDP Context response (PDP Address = link-local 533 address). 535 4. The SGSN sends an Activate PDP Context accept message to the 536 UE (PDP Address = link-local address). 538 5. The UE keeps the link-local address, and extracts the 539 interface identifier for later use. The UE may send a Router 540 Solicitation message to the GGSN (first hop router). 542 6. After the PDP Context Activation the GGSN sends a Router 543 Advertisement to the UE. 545 7. The UE should be configured not to send Neighbor 546 Solicitation message. However, if one is sent the GGSN will 547 silently discard it. 549 8. The GGSN updates the SGSN with the whole IPv6 address. 551 Each connected handset or laptop will create a primary PDP context 552 for communication on the Internet. A handset may create many 553 primary and/or secondary PDP contexts throughout the life of its 554 connection with a GGSN. 556 Within 3GPP, the GGSN assigns a single 64-bit identifier to each 557 primary PDP context. The GGSN also advertises a single /64 prefix 558 to the handset, and these two items are assembled into a single 559 IPv6 address. Later, the GGSN modifies the PDP context entry in 560 the SGSN to include the whole IPv6 address, so that the SGSN can 561 know the single address of each 3GPP node (e.g. for billing 562 purposes). This address is also used in the GGSN to identify the 563 PDP context associated with each packet. It is assumed that 3GPP 564 nodes will not generate any addresses, except for the single 565 identifier/prefix combination assigned by the GGSN. DAD is not 566 performed, as the GGSN will not assign the same address to multiple 567 nodes. 569 7 Recommendations to the 3GPP 571 In the spirit of productive cooperation, the IPv6 Working Group 572 recommends that the 3GPP consider three changes regarding the use 573 of IPv6 within GPRS. Specifically, we recommend that the 3GPP 575 1. Specify that multiple prefixes may be assigned to each 576 primary PDP context, 578 2. Require that a given prefix must not be assigned to more 579 than one primary PDP context, and 581 3. Allow 3GPP nodes to use multiple identifiers within those 582 prefixes, including randomly generated identifiers. 584 Making these changes would provide several advantages for 3GPP 585 implementers and users: 587 Laptops that connect to 3GPP handsets will work without any 588 software changes. Their implementation of standard IPv6 over 589 PPP, address assignment, and autoconfiguration mechanisms 590 will work without any modification. This will eliminate the 591 need for vendors and operators to build and test special 3GPP 592 drivers and related software. As currently specified, the 593 3GPP standards will be incompatible with laptop 594 implementations that generate their own identifiers for 595 privacy or other purposes. 597 IPv6 software implementations could be used in 3GPP handsets 598 without any modifications to the IPv6 protocol mechanisms. 599 This will make it easier to build and test 3GPP handsets. 601 Applications in 3GPP handsets will be able to take advantage 602 of different types of IPv6 addresses (e.g., static addresses, 603 temporary addresses for privacy, site-scoped addresses for 604 site only communication, etc.) 606 The GPRS system will be better positioned to take advantage of 607 new IPv6 features that are built around the current addressing 608 architecture. 610 7.1 Limitations of 3GPP Address Assignment 612 The current 3GPP address assignment mechanism has the following 613 limitations: 615 The GGSN only advertises a single /64 prefix, rather than a 616 set of prefixes. This will prevent the participation of 3GPP 617 nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site 618 renumbering, or in other mechanisms that expect IPv6 hosts to 619 create addresses based on multiple advertised prefixes. 621 A 3GPP node is assigned a single identifier and is not allowed 622 to generate additional identifiers. This will prevent the use 623 of privacy addresses by 3GPP nodes. This also makes 3GPP 624 mechanisms not fully compliant with the expected behavior of 625 IPv6 nodes, which will result in incompatibility with popular 626 laptop IPv6 stacks. For example, a laptop that uses privacy 627 addresses for web browser connections could not currently not 628 currently establish a web browser connection over a 3GPP link. 630 These limitations could be avoided by enabling the standard IPv6 631 address allocation mechanisms in 3GPP nodes. The GGSN could 632 advertise one or more prefixes for the local link in standard IPv6 633 Router Advertisements, and IPv6 addresses could be assembled, as 634 needed, by the IPv6 stack on the handset or laptop. An interface 635 identifier could still be assigned by the GGSN, as is currently 636 specified in the 3GPP standards. However, the handset or laptop 637 could generate additional identifiers, as needed for privacy or 638 other reasons. 640 7.2 Advertising Multiple Prefixes 642 For compliance with current and future IPv6 standards, the IPv6 WG 643 recommends that the 3GPP allow multiple prefixes to be advertised 644 for each primary PDP context. This would have several advantages, 645 including: 647 3GPP nodes could participate in site renumbering and future 648 IPv6 mechanisms that rely on the use of multiple global 649 prefixes on a single link. 651 Site-local prefixes could be advertised on 3GPP links, if 652 desired, allowing for site-constrained communication that 653 could survive changes to global prefix information (e.g. site 654 renumbering). 656 7.3 Assigning a Prefix to Only One Primary PDP Context 658 The IPv6 WG recommends that the 3GPP treat a primary PDP context, 659 along with its secondary PDP contexts, as a single IPv6 link, and 660 that the GGSN view each primary PDP context as a single subnet. 661 Accordingly, a given global (or site-local) prefix should not be 662 assigned to more than one PDP context. 664 Because multiple IPv6 hosts may attach through a 3GPP handset, the 665 IPv6 WG recommends that one or more /64 prefixes should be assigned 666 to each primary PDP context. This will allow sufficient address 667 space for a 3GPP-attached node to allocate privacy addresses and/or 668 route to a multi-link subnet [MULTLINK], and will discourage the 669 use of NAT within 3GPP-attached devices. 671 7.3.1 Is a /64 per PDP Context Too Much? 673 If an operator assigns a /64 per PDP context, can we be assured 674 that there is enough address space for millions of mobile devices? 675 This question can be answered in the positive using the Host 676 Density (HD) Ratio for address assignment efficiency [HD]. This is 677 a measure of the number of addresses that can practically and 678 easily be assigned to hosts, taking into consideration the 679 inefficiencies in usage resulting from the various address 680 assignment processes. The HD ratio was empirically derived 681 from actual telephone number and data network address assignment 682 cases. 684 We can calculate the number of easily assignable /64's making the 685 following assumptions: 687 An HD ratio of 0.8 (representing the efficiency that can be 688 achieved with no particular difficulty). 690 Only addresses with the 3-bit prefix 001 (the Aggregatable 691 Global Unicast Addresses defined by RFC 2373) are used, 692 resulting in 61 bits of assignable address space. 694 Using these assumptions, a total of 490 trillion (490x10^12) /64 695 prefixes can be assigned. This translates into around 80,000 PDP 696 Contexts per person on the earth today. Even assuming that a 697 majority of these IPv6 /64 prefixes will be used by non-3GPP 698 networks, there is still clearly a sufficient number of /64 699 prefixes. 701 Given this, it can be safely concluded that the IPv6 address space 702 will not be exhausted if /64 prefixes are allocated to primary PDP 703 contexts. 705 For more information regarding policies for IPv6 address 706 assignment, refer to the IAB/IESG recommendations regarding address 707 assignment [IABAA], and the APNIC, ARIN and RIPE address allocation 708 policy [AAPOL]. 710 7.3.2 Prefix Information in the SGSN 712 Currently, the 3GPP standards allow only one prefix and one 713 identifier for each PDP context. So, the GGSN can send a single 714 IPv6 address to the SGSN, to be used for billing purposes, etc. 716 Instead of using the full IPv6 address to identify a PDP context, 717 the IPv6 WG recommends that the SGSN be informed of each prefix 718 that is currently assigned to a PDP context. By assigning a prefix 719 to only one primary PDP context, the SGSN can associate a prefix 720 list with each PDP context. 722 7.4 Multiple Identifiers per PDP Context 724 The IPv6 WG also recommends that the 3GPP standards be modified to 725 allow multiple identifiers, including randomly generated 726 identifiers, to be used within each assigned prefix. This would 727 allow 3GPP nodes to generate and use privacy addresses, and would 728 be compatible with future IPv6 standards that may depend on the 729 ability of IPv6 nodes to generate new interface identifiers for 730 communication. 732 This is a vital change, necessary to allow standards-compliant IPv6 733 nodes to connect to the Internet through 3GPP handsets, without 734 modification. It is expected that most IPv6 nodes, including the 735 most popular laptop stacks, will generate privacy addresses. The 736 current 3GPP specifications will not be compatible with those 737 implementations. 739 8 Additional IPv6 Work Items 741 During our work on this document, we have discovered several areas 742 that could benefit from further informational or standards-track 743 work within the IPv6 Working Group. 745 The IPv6 WG should work to define a point-to-point architecture and 746 specify how the standard IPv6 address assignment mechanisms are 747 applicable to IPv6 over point-to-point links. We should also 748 review and clarify the IPv6 over PPP specification [PPP] to match 749 the current IPv6 addressing architecture [ADDRARCH]. 751 The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" 752 (or similar) document. This document would be useful for 753 developers writing drivers for IPv6 stacks to work over 3GPP PDP 754 Contexts. 756 The IPv6 working group should undertake an effort to define the 757 minimal requirements for all IPv6 nodes. 759 9 Security Considerations 761 This document contains recommendations on the use of the IPv6 762 protocol in 3GPP standards. It does not specify a protocol, and it 763 introduces no new security considerations. 765 10 Appendix A: Analysis of Findings 767 This section includes some analysis that may be useful to 768 understanding why the IPv6 working group is making the above 769 recommendations. It also includes some other options that were 770 explored, and the reasons why those options were less suitable than 771 the recommendations outlined above. 773 10.1 Address Assignment Solutions 775 In order to allow for the configuration and use of multiple IPv6 776 addresses per primary PDP Context having different interface 777 identifiers, some modifications to the current 3GPP specifications 778 would be required. 780 The solutions to achieve this were evaluated against the following 781 factors: 783 - Scarcity and high cost of wireless spectrum 784 - Complexity of implementation and state maintenance 785 - Stability of the relevant IETF standards 786 - Impact on current 3GPP standards 788 Two solutions to allow autoconfiguration of multiple addresses on 789 the same primary PDP Context were considered: 791 1. Assign one or more entire prefixes (/64s) to a PDP Context 792 upon PDP Context activation and allow the autoconfiguration 793 of multiple addresses. 795 a) The assignment may be performed by having the GGSN 796 advertise one or more /64 prefixes to the mobile 797 device. 799 b) The assignment may be performed by building "prefix 800 delegation" functionality into the PDP Context 801 messages or by using layer 3 mechanisms such as 802 [PREFDEL]. In this way the prefix is not assigned to 803 the link between the GGSN and the mobile device (as in 804 1a) but it is assigned to the mobile device itself. 805 Note that [PREFDEL] cannot be considered stable 806 and has not at this stage been adopted by the IPv6 WG 807 as a WG document. 809 2. Share the same prefix between multiple PDP Contexts 810 connected to the same GGSN (and APN). Given that mobile 811 devices may generate multiple addresses using more than one 812 interface identifier, this would require DAD for the newly 813 generated addresses over the air interface, and a proxy DAD 814 function which would increase the complexity and the amount 815 of state to be kept in the GGSN. Also, the GGSN would need 816 to determine when the temporary addresses are no longer in 817 use which would be difficult. One possible solution could be 818 using periodic unicast neighbor solicitations for the 819 temporary addresses [IPV6ND]. 821 Considering all the factors when evaluating the solutions, the 822 recommendation is to use Solution 1a. This solution requires the 823 least modification to the current 3GPP standards and maintains all 824 the advantages of the other solutions. 826 Effectively this would mean that each APN in a GGSN would have a 827 certain number of /64 prefixes that can be handed out at PDP 828 context Activation, through Router Advertisements. Therefore, 829 instead of using the full IPv6 address to identify a primary PDP 830 context, the IPv6 WG recommends that the GGSN use the entire prefix 831 (together with other 3GPP specific information) and that the SGSN 832 be informed of the prefixes that are assigned to a PDP context. By 833 assigning a given prefix to only one primary PDP context, the GGSN 834 and SGSN can associate a prefix list with each PDP context, as 835 needed. 837 Note that the recommended solution does not imply or assume that 838 the mobile device is a router. The MT is expected to use the /64 839 for itself and may also use this prefix for devices attached to it. 840 However this is not necessary if each device behind the MT is 841 connected to a separate primary PDP Context and therefore can use a 842 /64 which is not shared with other devices. The MT is also expected 843 to handle DAD locally for devices attached to it (e.g. laptops) 844 without forwarding Neighbor Solicitations over the air to the GGSN. 846 11 References 848 [OLD-TS23060] 849 TS 23.060, "General Packet Radio Service (GPRS); Service 850 description; Stage 2", V4.1.0 852 [NEW-TS23060] 853 TS 23.060 version 3.11.0 (release 99), 4.4.0 (release 4) 854 and 5.1.0 (release 5). 856 [3GPP-URL] 857 http://www.3gpp.org 859 [IETF-URL] 860 http://www.ietf.org 862 [RFC2026] 863 S. Bradner, "The Internet Standards Process -- Revision 3", 864 RFC 2026, BCP9, October 1996 866 [KEYWORD] 867 S. Bradner, "Key words for use in RFCs to Indicate Requirement 868 Levels", RFC 2119, BCP14, March 1999. 870 [TR21905] 871 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0 873 [IPV6] 874 S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 875 Specification", RFC 2460, December 1998. 877 [NAT-PT] 878 G. Tsirtsis, P. Shrisuresh, "Network Address Translation - 879 Protocol Translation (NAT-PT)", RFC2766, February 2000. 881 [PPP] 882 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 883 1661, July 1994. 885 [SIIT] 886 E. Nordmark, "Stateless IP/ICMP Translation Algorithm", RFC 887 2765, February 2000. 889 [ADDRARCH] 890 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 891 RFC 2373, July 1998 893 [IPV6ND] 894 T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP 895 Version 6 (IPv6)", RFC 2461, December 1998 897 [AUTOCONF] 898 S. Thomson, T. Narten, "IPv6 Stateless Address 899 Autoconfiguration", RFC 2462, December 1998 901 [PRIVADDR] 902 T. Narten, R. Draves, "Privacy Extensions for Stateless 903 Address Autoconfiguration in IPv6", RFC 3041, January 2001 905 [IPV6ETH] 906 M. Crawford, "Transmission of IPv6 Packets over Ethernet 907 Networks", RFC 2464, December 1998 909 [PPPv6] 910 D. Haskin, E. Allen, "IP Version 6 over PPP", RFC2472, 911 December 1998. 913 [MULTLINK] 914 C. Huitema, D. Thaler, "Multi-link Subnet Support in IPv6", 915 draft-thaler-ipngwg-multilink-subnets-01.txt, July 2001 917 [SITEREN] 918 C. Huitema, "IPv6 Site Renumbering", draft-huitema-ipv6- 919 renumber-00.txt, July 2001 921 [HD] 922 C. Huitema, A. Durand, "The Host-Density Ratio for Address 923 Assignment Efficiency: An update on the H ratio", draft- 924 durand-huitema-h-density-ratio-02.txt, August 2001 926 [IABAA] 927 IAB, IESG, "IAB/IESG Recommendations on IPv6 Address 928 Allocations to Sites", RFC3177, September 2001. 930 [AAPOL] 931 APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment 932 Global Policy". Draft of December, 22 2001, Version 2001-12- 933 22 [ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001- 934 12-22.txt] 936 [SCOPARCH] 937 S. Deering, et. al, "IPv6 Scoped Address Architecture", draft- 938 ietf-ipngwg-scoping-arch-02.txt, March 2001 940 [CELLREQ] 941 J. Arkko, et. al, "Minimum IPv6 Functionality for a Cellular 942 Host", draft-manyfolks-ipv6-cellular-host-01.txt, September 943 2001 945 [PREFDEL] 946 J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol 947 for Internet Protocol Version 6 (IPv6)", draft-haberman- 948 ipngwg-auto-prefix-01.txt, July 2001 949 12 Authors and Acknowledgements 951 This document was written by the IPv6 3GPP design team: 953 Steve Deering, Cisco Systems 954 956 Karim El-Malki, Ericsson Radio Systems 957 959 Paul Francis, Tahoe Networks 960 962 Bob Hinden, Nokia 963 965 Christian Huitema, Microsoft 966 968 Niall Richard Murphy, Hutchison 3G 969 971 Markku Savela, Technical Research Centre of Finland 972 974 Jonne Soininen, Nokia 975 977 Margaret Wasserman, Wind River 978 980 Information was incorporated from a presentation co-authored by: 982 Juan-Antonio Ibanez, Ericsson Eurolab 984 13 Editor's Contact Information 986 Comments or questions regarding this document should be sent to: 988 Margaret Wasserman 989 Wind River 990 10 Tara Blvd., Suite 330 Phone: (603) 897-2067 991 Nashua, NH 03062 USA Email: mrw@windriver.com