idnits 2.17.1 draft-ietf-ipv6-3gpp-recommend-00.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 == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 15) being 59 lines 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 (January 2002) is 8135 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: 'PPPV6' is mentioned on line 514, but not defined == Unused Reference: 'IPV6ETH' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'PPPv6' is defined on line 898, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TR21905' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23060' ** 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: 12 errors (**), 0 flaws (~~), 11 warnings (==), 10 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-00.txt Wind River 4 Expires: July 2002 January 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. The IPv6 Working Group supports the 35 use of IPv6 within 3GPP and offers these recommendations in a 36 spirit of open cooperation between the IPv6 Working Group and the 37 3GPP community. 39 3 Copyright Notice 41 Copyright (C) The Internet Society (2001). All Rights Reserved. 43 4 Conventions Used In This Document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 47 this document are to be interpreted as described in RFC 2119 48 [KEYWORD]. 50 Recommendations for IPv6 in 3GPP Standards January 2002 52 5 Table of Contents 54 1 Status of this Memo.......................................1 55 2 Abstract..................................................1 56 3 Copyright Notice..........................................1 57 4 Conventions Used In This Document.........................1 58 5 Table of Contents.........................................2 59 6 Introduction..............................................3 60 6.1 What is the 3GPP?.........................................3 61 6.2 What is the IETF?.........................................4 62 6.3 Terminology...............................................4 63 6.3.1 3GPP Terminology..........................................4 64 6.3.2 IETF Terminology..........................................5 65 6.4 Overview of the IPv6 Addressing Architecture..............5 66 6.5 An IP-Centric View of the 3GPP System.....................6 67 6.5.1 Overview of the UMTS Architecture.........................7 68 6.5.2 The PDP Context...........................................9 69 6.5.3 IPv6 Address Autoconfiguration in GPRS...................10 70 7 Recommendations to the 3GPP..............................12 71 7.1 Limitations of 3GPP Address Assignment...................12 72 7.2 Advertising Multiple Prefixes............................13 73 7.3 Assigning a Prefix to Only One Primary PDP Context.......13 74 7.3.1 Is a /64 per PDP Context Too Much?.......................13 75 7.3.2 Prefix Information in the SGSN...........................14 76 7.4 Multiple Identifiers per PDP Context.....................14 77 8 Additional IPv6 Work Items...............................16 78 9 Security Considerations..................................16 79 10 Appendix A: Analysis of Findings........................17 80 10.1 Address Assignment Solutions.............................17 81 11 References...............................................19 82 12 Authors and Acknowledgements.............................21 83 13 Editor's Contact Information.............................21 84 Recommendations for IPv6 in 3GPP Standards January 2002 86 6 Introduction 88 This document offers recommendations to the 3GPP community from the 89 IETF IPv6 Working Group. It is organized into three main sections: 91 1. An introduction (this section) that provides background 92 information regarding the IETF IPv6 WG and the 3GPP and 93 includes a high-level overview of the technologies discussed 94 in this document. 96 2. Recommendations from the IPv6 WG to the 3GPP community. 97 These can be found in section 7. 99 3. Further work items that should be considered by the IPv6 WG. 100 These items are discussed in section 8. 102 It is the purpose of this document to provide advice from the IPv6 103 Working Group to the 3GPP community. We have limited the contents 104 of this document to items that are directly related to the use of 105 IPv6 within 3GPP. This document defines no standards, and it is 106 not a definitive source of information regarding IPv6 or 3GPP. We 107 have not chosen to explore 3GPP-related issues with other IETF 108 protocols (i.e. SIP, IPv4, etc.), as they are outside the scope of 109 the IPv6 Working Group. 111 The IPv6 Working Group fully supports the use of IPv6 within 3GPP, 112 and we encourage 3GPP implementers and operators to participate in 113 the IETF process. We are offering these suggestions in a spirit of 114 open cooperation between the IPv6 Working Group and the 3GPP 115 community, and we hope that our ongoing cooperation will help to 116 strengthen both sets of standards. 118 6.1 What is the 3GPP? 120 The Third Generation Partnership Project (3GPP) is a global 121 standardization partnership founded in late 1998. Its 122 Organizational Partners have agreed to co-operate in the production 123 of technical specifications for a Third Generation Mobile System 124 based on the evolved GSM core networks. 126 The 3GPP Organizational Partners consist of several different 127 standardization organizations: ETSI from Europe, Standards 128 Committee T1 Telecommunications (T1) in the USA, China Wireless 129 Telecommunication Standard Group (CWTS), Korean Telecommunications 130 Technology Association (TTA), the Association of Radio Industries 131 and Businesses (ARIB) and the Telecommunication Technology 132 Committee(TTC) in Japan. 134 The work is coordinated by a Project Co-ordination Group (PCG), and 135 structured into Technical Specification Groups (TSGs). There are 136 five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), 137 Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network 138 (GERAN), and the Terminals (TSG T). The TSGs are further divided 139 Recommendations for IPv6 in 3GPP Standards January 2002 141 into Working Groups (WGs). The technical work is done in the 142 working groups, and later approved in the TSGs. 144 3GPP working methods are different from IETF working methods. The 145 major difference is where the major part of the work is done. In 146 3GPP, the work is done in face-to-face meetings, and the mailing 147 list is used mainly for distributing contributions, and for 148 handling documents that were not handled in the meeting due to lack 149 of time. Decisions are usually made by consensus, though voting 150 does exist. However, it is rather rare to vote. 3GPP documents are 151 public and can be accessed at http://www.3gpp.org/. 153 6.2 What is the IETF? 155 The Internet Engineering Task Force (IETF) is a large open 156 international community of network designers, operators, vendors, 157 and researchers concerned with the evolution of the Internet 158 architecture and the smooth operation of the Internet. The IETF is 159 also the primary standards body developing Internet protocols and 160 standards. It is open to any interested individual. More 161 information about the IETF can be found at http://www.ietf.org. 163 The actual technical work of the IETF is done in working groups, 164 which are organized by topic into several areas (e.g., routing, 165 transport, security, etc.). The IPv6 Working Group is chartered 166 within the Internet area of the IETF. Much of the work is handled 167 via mailing lists, and the IETF holds meetings three times per 168 year. 170 6.3 Terminology 172 This section defines the 3GPP and IETF terminology used in this 173 document. The 3GPP terms and their meanings have been taken from 174 [TR21905]. 176 6.3.1 3GPP Terminology 178 APN Access Point Name. The APN is a logical name referring 179 to a GGSN and an external network. 181 CS Circuit Switched 183 GERAN GSM/EDGE Radio Access Network 185 GGSN Gateway GPRS Support Node. A router between the GPRS 186 network and an external network (i.e. the Internet). 188 GPRS General Packet Radio Services 190 GTP-U General Tunneling Protocol - User Plane 192 MT Mobile Termination. For example, a mobile phone 193 handset. 195 Recommendations for IPv6 in 3GPP Standards January 2002 197 PDP Packet Data Protocol 199 PDP Context A PDP connection between the UE and the GGSN. 201 PS Packet Switched 203 SGSN Serving GPRS Support Node 205 TE Terminal Equipment. For example, a laptop attached 206 through a 3GPP handset. 208 UE User Equipment (TE + MT + USIM). An example would be 209 a mobile handset with a USIM card inserted and a 210 laptop attached. 212 UMTS Universal Mobile Telecommunications System 214 USIM Universal Subscriber Identity Module. Typically, a 215 card that is inserted into a mobile phone handset. 217 UTRAN Universal Terrestrial Radio Access Network 219 6.3.2 IETF Terminology 221 IPv6 Internet Protocol version 6 223 NAS Network Access Server 225 NAT Network Address Translator 227 NAT-PT Network Address Translation with Protocol Translation. 228 An IPv6 transition mechanism. 230 PPP Point-to-Point Protocol 232 SIIT Stateless IP/ICMP Transition Mechanism 234 6.4 Overview of the IPv6 Addressing Architecture 236 The recommendations in this document are primarily related to IPv6 237 address assignment. To fully understand the recommended changes, 238 it is necessary to understand the IPv6 addressing architecture, and 239 current IPv6 address assignment mechanisms. 241 The IPv6 addressing architecture represents a significant evolution 242 from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes 243 be able to assemble their own addresses from interface identifiers 244 and prefix information. This mechanism is called IPv6 Host 245 Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure 246 themselves without the need for stateful configuration servers 247 (i.e. DHCPv6) or statically configured addresses. 249 Recommendations for IPv6 in 3GPP Standards January 2002 251 Interface identifiers can be globally unique, such as modified EUI- 252 64 addresses [ADDRARCH], or non-unique, such as randomly generated 253 identifiers. Hosts that have a globally unique identifier 254 available may also choose to use randomly generated addresses for 255 privacy [PRIVADDR] or for other reasons. IPv6 hosts are free to 256 generate new identifiers at any time, and Duplicate Address 257 Detection (DAD) is used to protect against the use of duplicate 258 identifiers on a single link [IPV6ND]. 260 A constant link-local prefix can be combined with any interface 261 identifier to build an address for communication on a locally 262 attached link. IPv6 routers may advertise additional prefixes 263 (site-local and/or global prefixes)[IPV6ND]. Hosts can combine 264 advertised prefixes with their own interface identifiers to create 265 addresses for site-local and global communication. 267 IPv6 introduces architectural support for scoped unicast addressing 268 [SCOPARCH]. A single interface will typically have multiple 269 addresses for communication within different scopes: link-local, 270 site-local and/or global [ADDRARCH]. Link-local addresses allow 271 for local communication, even when an IPv6 router is not present. 272 Some IPv6 protocols (i.e. routing protocols) require the use of 273 link-local addresses. Site-local addressing allows communication 274 to be administratively contained within a single site. Link-local 275 or site-local connections may also survive changes to global prefix 276 information (e.g. site renumbering). 278 IPv6 explicitly associates each address with an interface. 279 Multiple-interface hosts may have interfaces on more than one link 280 or in more than one site. Links and sites are internally 281 identified using zone identifiers. Proper routing of non-global 282 traffic and proper address selection are ensured by the IPv6 scoped 283 addressing architecture [SCOPARCH]. 285 IPv6 introduces the concept of privacy addresses [PRIVADDR]. These 286 addresses are generated from an advertised global prefix and a 287 randomly generated identifier, and are used for anonymous access to 288 Internet services. Applications control the generation of privacy 289 addresses, and new addresses can be generated at any time. 291 The IPv6 site renumbering specification [SITEREN] relies upon the 292 fact that IPv6 nodes will generate new addresses when new prefixes 293 are advertised on the link, and that they will deprecate addresses 294 that use deprecated prefixes. 296 In the future, additional IPv6 specifications may rely upon the 297 ability of IPv6 nodes to use multiple prefixes and/or multiple 298 identifiers to dynamically create new addresses. 300 6.5 An IP-Centric View of the 3GPP System 302 The 3GPP specifications define a Third Generation Mobile System. 303 An overview of the packet switched (PS) domain of the 3GPP Release 304 99 system is described in the following sections. The authors hope 305 Recommendations for IPv6 in 3GPP Standards January 2002 307 that this description is sufficient for the reader who is 308 unfamiliar with the UMTS packet switched service to understand how 309 the UMTS system works, and how IPv6 is currently defined to be used 310 within it. 312 6.5.1 Overview of the UMTS Architecture 314 The UMTS architecture can be divided into two main domains -- the 315 packet switched (PS) domain, and the circuit switched (CS) domain. 316 In this document, we will concentrate on the PS domain, or General 317 Packet Radio Services (GPRS). 319 ------ 320 | TE | 321 ------ 322 | 323 +R 324 | 325 ------ Uu ----------- Iu ----------- Gn ----------- Gi 326 | MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+-- 327 ------ ----------- ----------- ----------- 328 (UE) 330 Figure 1: Simplified GPRS Architecture 332 ------ 333 | | 334 | App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer) 335 | | 336 |------| ------------- 337 | IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |-> 338 | v4/6 | | v4/6 | 339 |------| ------------- ------------- |------ | 340 | | | \ Relay / | | \ Relay / | | | | 341 | | | \ / | | \ / | | | | 342 | | | \ / | | \ / | | | | 343 | PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U | | 344 | | | | | | | | | | | 345 |------| |------|------| |------|------| |------| | 346 | | | | UDP |- - -| UDP | UDP |- - -| UDP | | 347 | | | |------| |------|------| |------| | 348 | RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | | 349 | | | | v4/6 | | v4/6 | v4/6 | |v4/6 | | 350 |------| |------|------| |------|------| |------|------| 351 | MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 | 352 |------| |------|------| |------|------| |------|------| 353 | L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 | 354 ------ ------------- ------------- ------------- 356 UE UTRAN SGSN GGSN 357 (handset) 359 Figure 2: GPRS Protocol Stacks 360 Recommendations for IPv6 in 3GPP Standards January 2002 362 ------ 363 | | 364 | App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer) 365 | | 366 |------| 367 | | 368 | IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN) 369 | v4/6 | 370 | | | | 371 |------| |-------------| 372 | | | \ Relay / | 373 | | | \ / | 374 | | | \ / | 375 | | | \ / PDCP|- - - (to UTRAN) 376 | | | | | 377 | PPP |- - -| PPP |------| 378 | | | | RLC |- - - (to UTRAN) 379 | | | |------| 380 | | | | MAC | 381 |------| |------|------| 382 | L1a |- - -| L1a | L1b |- - - (to UTRAN) 383 ------ ------------- 385 TE MT 386 (laptop) (handset) 388 Figure 3: Laptop Attached to 3GPP Handset 390 The GRPS core network elements shown in Figures 1 and 2 are the 391 User Equipment (UE), Serving GPRS Support Node (SGSN) and Gateway 392 GPRS Support Node (GGSN). The UTRAN comprises Radio Access Network 393 Controllers (RNC) and the UTRAN base stations. 395 GGSN A specialized router that functions as the gateway between the 396 GPRS network and the external networks, e.g. Internet. It also 397 gathers charging information about the connections. In many 398 ways the GGSN is similar to a Network Access Server (NAS). 400 SGSN The SGSN's main functions include authentication, 401 authorization, mobility management, and collection of billing 402 information. The SGSN is connected to the SS7 network and 403 through that to the Home Location Register (HLR), so that it 404 can perform user profile handling, authentication, and 405 authorization. 407 GTP-U is a simple tunnelling protocol running over UDP/IP 408 and used to route packets between RNC, SGSN and GGSN within the 409 same, or between different, UMTS backbone(s). A GTP-U tunnel is 410 identified at each end by a Tunnel Endpoint Identifier (TEID). 412 Recommendations for IPv6 in 3GPP Standards January 2002 414 Only the most significant elements of the GPRS system are discussed 415 in this document. More information about the GPRS system can be 416 found in [TS23060]. 418 6.5.2 The PDP Context 420 The most important 3GPP concept in this context is a PDP Context. A 421 PDP Context is a connection between the UE and the GGSN, over which 422 the packets are transferred. There are two kinds of PDP Contexts -- 423 primary, and secondary. 425 The primary PDP Context initially defines the link to the GGSN. For 426 instance, an IP address is assigned to each primary PDP Context. In 427 addition, one or more secondary PDP Contexts can be added to a 428 primary PDP Context, sharing the same IP address. These secondary 429 PDP Contexts can have different Quality of Service characteristics 430 than the primary PDP Context. 432 Together a primary PDP Context and zero or more secondary PDP 433 Contexts define, in IETF terms, a link. GPRS links are point-to- 434 point. Once activated, all PDP contexts have equal status, meaning 435 that a primary PDP context can be deleted while keeping the link 436 between the UE and the GGSN, as long as there are other (secondary) 437 PDP contexts active for the same IP address. 439 There are currently three PDP Types supported in GPRS -- IPv4, 440 IPv6, and PPP. This document will only discuss the IPv6 PDP Type. 442 There are three basic actions that can be performed on a PDP 443 Context: PDP Context Activation, Modification, and Deactivation. 444 These actions are described in the following. 446 Activate PDP Context 448 Opens a new PDP Context to a GGSN. If a new primary 449 PDP Context is activated, there is a new link created 450 between a UE and a GGSN. A UE can open multiple 451 primary PDP Contexts to one or more GGSNs. 453 Modify PDP Context 455 Changes the characteristics of a PDP Context, for 456 example QoS attributes. 458 Deactivate PDP Context 460 Deactivates a PDP Context. If a primary PDP Context 461 and all secondary PDP contexts associated with it are 462 deactivated, a link between the UE and the GGSN is 463 removed. 465 The APN is a name which is logically linked to a GGSN. The APN may 466 identify a service or an external network. The syntax of the APN 467 corresponds to a fully qualified domain name. At PDP context 468 Recommendations for IPv6 in 3GPP Standards January 2002 470 activation, the SGSN performs a DNS query to find out the GGSN(s) 471 serving the APN requested by the terminal. The DNS response 472 contains a list of GGSN addresses from which the SGSN selects one 473 (in a round-robin fashion). 475 --------- -------- 476 | | | GGSN | 477 | | LINK 1 | | 478 | -======== PDP Context A ========- - - -> ISP X 479 | | | | 480 | | | | 481 | | | | 482 | /======= PDP Context B =======\ | 483 | - | LINK 2 | - - - -> ISP Y 484 | \======= PDP Context C =======/ | 485 | | | | 486 | | | | 487 | MT | -------- 488 |(handset)| 489 | | -------- 490 -------- | | | GGSN | 491 | | | | LINK 3 | | 492 | | | -======== PDP Context D ========- | 493 | TE | | | | | 494 |(laptop)| | | | - - -> ISP Z 495 | | | | LINK 4 | | 496 | -====PPP====-----======== PDP Context E ========- | 497 | | | | | | 498 | | | | | | 499 -------- --------- -------- 501 Figure 3: Correspondence of PDP Contexts to IPv6 Links 503 6.5.3 IPv6 Address Autoconfiguration in GPRS 505 GPRS supports static and dynamic address allocation. Two types of 506 dynamic address allocation are supported -- stateless, and 507 stateful. Stateful address configuration uses an external protocol 508 to connect to a server that gives the IP address, e.g. DHCP. 510 The stateless IPv6 autoconfiguration works differently in GPRS than 511 in Ethernet networks. GPRS nodes have no unique identifier, whereas 512 Ethernet nodes can create an identifier from their EUI-48 address. 513 Because GPRS networks are similar to dialup networks, the stateless 514 address autoconfiguration in GPRS was based on PPPv6 [PPPV6]. 516 3GPP address autoconfiguration has the following steps: 518 1. The Activate PDP Context message is sent to the SGSN (PDP 519 Type=IPv6, PDP Address = 0, etc.). 521 Recommendations for IPv6 in 3GPP Standards January 2002 523 2. The SGSN sends a Create PDP Context message to the GGSN with 524 the above parameters. 526 3. GGSN chooses an interface identifier for the PDP Context and 527 creates the link-local address. It answers the SGSN with a 528 Create PDP Context response (PDP Address = link-local 529 address). 531 4. The SGSN sends an Activate PDP Context accept message to the 532 UE (PDP Address = link-local address). 534 5. The UE keeps the link-local address, and extracts the 535 interface identifier for later use. The UE may send a Router 536 Solicitation message to the GGSN (first hop router). 538 6. After the PDP Context Activation the GGSN sends a Router 539 Advertisement to the UE. 541 7. The UE should be configured not to send Neighbor 542 Solicitation message. However, if one is sent the GGSN will 543 silently discard it. 545 8. The GGSN updates the SGSN with the whole IPv6 address. 547 Each connected handset or laptop will create a primary PDP context 548 for communication on the Internet. A handset may create many 549 primary and/or secondary PDP contexts throughout the life of its 550 connection with a GGSN. 552 Within 3GPP, the GGSN assigns a single 64-bit identifier to each 553 primary PDP context. The GGSN also advertises a single /64 prefix 554 to the handset, and these two items are assembled into a single 555 IPv6 address. Later, the GGSN modifies the PDP context entry in 556 the SGSN to include the whole IPv6 address, so that the SGSN can 557 know the single address of each 3GPP node (e.g. for billing 558 purposes). This address is also used in the GGSN to identify the 559 PDP context associated with each packet. It is assumed that 3GPP 560 nodes will not generate any addresses, except for the single 561 identifier/prefix combination assigned by the GGSN. DAD is not 562 performed, as the GGSN will not assign the same address to multiple 563 nodes. 565 Recommendations for IPv6 in 3GPP Standards January 2002 567 7 Recommendations to the 3GPP 569 In the spirit of productive cooperation, the IPv6 Working Group 570 recommends that the 3GPP consider three changes regarding the use 571 of IPv6 within GPRS. Specifically, we recommend that the 3GPP 573 1. Specify that multiple prefixes may be assigned to each 574 primary PDP context, 576 2. Require that a given prefix must not be assigned to more 577 than one primary PDP context, and 579 3. Allow 3GPP nodes to use multiple identifiers within those 580 prefixes, including randomly generated identifiers. 582 Making these changes would provide several advantages for 3GPP 583 implementers and users: 585 Laptops that connect to 3GPP handsets will work without any 586 software changes. Their implementation of standard IPv6 over 587 PPP, address assignment, and autoconfiguration mechanisms 588 will work without any modification. This will eliminate the 589 need for vendors and operators to build and test special 3GPP 590 drivers and related software. As currently specified, the 591 3GPP standards will be incompatible with laptop 592 implementations that generate their own identifiers for 593 privacy or other purposes. 595 IPv6 software implementations could be used in 3GPP handsets 596 without any modifications to the IPv6 protocol mechanisms. 597 This will make it easier to build and test 3GPP handsets. 599 Applications in 3GPP handsets will be able to take advantage 600 of different types of IPv6 addresses (e.g., static addresses, 601 temporary addresses for privacy, site-scoped addresses for 602 site only communication, etc.) 604 The GPRS system will be better positioned to take advantage of 605 new IPv6 features that are built around the current addressing 606 architecture. 608 7.1 Limitations of 3GPP Address Assignment 610 The current 3GPP address assignment mechanism has the following 611 limitations: 613 The GGSN only advertises a single /64 prefix, rather than a 614 set of prefixes. This will prevent the participation of 3GPP 615 nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site 616 renumbering, or in other mechanisms that expect IPv6 hosts to 617 create addresses based on multiple advertised prefixes. 619 Recommendations for IPv6 in 3GPP Standards January 2002 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 Recommendations for IPv6 in 3GPP Standards January 2002 677 This question can be answered in the positive using the Host 678 Density (HD) Ratio for address assignment efficiency [HD]. This is 679 a measure of the number of addresses that can practically and 680 easily be assigned to hosts, taking into consideration the 681 inefficiencies in usage resulting from the various address 682 assignment processes. The HD ratio was empirically derived 683 from actual telephone number and data network address assignment 684 cases. 686 We can calculate the number of easily assignable /64's making the 687 following assumptions: 689 An HD ratio of 0.8 (representing the efficiency that can be 690 achieved with no particular difficulty). 692 Only addresses with the 3-bit prefix 001 (the Aggregatable 693 Global Unicast Addresses defined by RFC 2373) are used, 694 resulting in 61 bits of assignable address space. 696 Using these assumptions, a total of 490 trillion (490x10^12) /64 697 prefixes can be assigned. This translates into around 80,000 PDP 698 Contexts per person on the earth today. Even assuming that a 699 majority of these IPv6 /64 prefixes will be used by non-3GPP 700 networks, there is still clearly a sufficient number of /64 701 prefixes. 703 Given this, it can be safely concluded that the IPv6 address space 704 will not be exhausted if /64 prefixes are allocated to primary PDP 705 contexts. 707 For more information regarding policies for IPv6 address 708 assignment, refer to the IAB/IESG recommendations regarding address 709 assignment [IABAA], the APNIC, ARIN and RIPE address allocation 710 policy [AAPOL] and the ARIN minutes located at 711 http://www.arin.net/minutes/bot/bot08152001.html. 713 7.3.2 Prefix Information in the SGSN 715 Currently, the 3GPP standards allow only one prefix and one 716 identifier for each PDP context. So, the GGSN can send a single 717 IPv6 address to the SGSN, to be used for billing purposes, etc. 719 Instead of using the full IPv6 address to identify a PDP context, 720 the IPv6 WG recommends that the SGSN be informed of each prefix 721 that is currently assigned to a PDP context. By assigning a prefix 722 to only one primary PDP context, the SGSN can associate a prefix 723 list with each PDP context. 725 7.4 Multiple Identifiers per PDP Context 727 The IPv6 WG also recommends that the 3GPP standards be modified to 728 allow multiple identifiers, including randomly generated 729 identifiers, to be used within each assigned prefix. This would 730 allow 3GPP nodes to generate and use privacy addresses, and would 731 Recommendations for IPv6 in 3GPP Standards January 2002 733 be compatible with future IPv6 standards that may depend on the 734 ability of IPv6 nodes to generate new interface identifiers for 735 communication. 737 This is a vital change, necessary to allow standards-compliant IPv6 738 nodes to connect to the Internet through 3GPP handsets, without 739 modification. It is expected that most IPv6 nodes, including the 740 most popular laptop stacks, will generate privacy addresses. The 741 current 3GPP specifications will not be compatible with those 742 implementations. 744 Recommendations for IPv6 in 3GPP Standards January 2002 746 8 Additional IPv6 Work Items 748 During our work on this document, we have discovered several areas 749 that could benefit from further informational or standards-track 750 work within the IPv6 Working Group. 752 The IPv6 WG should work to define a point-to-point architecture and 753 specify how the standard IPv6 address assignment mechanisms are 754 applicable to IPv6 over point-to-point links. We should also 755 review and clarify the IPv6 over PPP specification to match the 756 current IPv6 addressing architecture. 758 The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" 759 document. This document would be useful for developers writing 760 drivers for IPv6 stacks to work over 3GPP PDP Contexts. 762 There is an ongoing effort to define a set of requirements for 763 cellular hosts [CELLREQ]. This work has been presented to the IPv6 764 WG, but has not been adopted as an IPv6 WG work item. This work 765 should be continued within the working group, and may feed into a 766 broader effort to define the requirements for all IPv6 nodes. 768 9 Security Considerations 770 This document contains recommendations on the use of the IPv6 771 protocol in 3GPP standards. It does not specify a protocol, and it 772 introduces no new security considerations. 774 Recommendations for IPv6 in 3GPP Standards January 2002 776 10 Appendix A: Analysis of Findings 778 This section includes some analysis that may be useful to 779 understanding why the IPv6 working group is making the above 780 recommendations. It also includes some other options that were 781 explored, and the reasons why those options were less suitable than 782 the recommendations outlined above. 784 10.1 Address Assignment Solutions 786 In order to allow for the configuration and use of multiple IPv6 787 addresses per primary PDP Context having different interface 788 identifiers, some modifications to the current 3GPP specifications 789 would be required. 791 The solutions to achieve this were evaluated against the following 792 factors: 794 - Scarcity and high cost of wireless spectrum 795 - Complexity of implementation and state maintenance 796 - Stability of the relevant IETF standards 797 - Impact on current 3GPP standards 799 Two solutions to allow autoconfiguration of multiple addresses on 800 the same primary PDP Context were considered: 802 1. Assign one or more entire prefixes (/64s) to a PDP Context 803 upon PDP Context activation and allow the autoconfiguration 804 of multiple addresses. 806 a) The assignment may be performed by having the GGSN 807 advertise one or more /64 prefixes to the mobile 808 device. 810 b) The assignment may be performed by building "prefix 811 delegation" functionality into the PDP Context 812 messages or by using layer 3 mechanisms such as 813 [PREFDEL]. In this way the prefix is not assigned to 814 the link between the GGSN and the mobile device (as in 815 1a) but it is assigned to the mobile device itself. 816 Note that [PREFDEL] cannot be considered stable 817 and has not at this stage been adopted by the IPv6 WG 818 as a WG document. 820 2. Share the same prefix between multiple PDP Contexts 821 connected to the same GGSN (and APN). Given that mobile 822 devices may generate multiple addresses using more than one 823 interface identifier, this would require DAD for the newly 824 generated addresses over the air interface, and a proxy DAD 825 function which would increase the complexity and the amount 826 of state to be kept in the GGSN. Also, the GGSN would need 827 to determine when the temporary addresses are no longer in 828 use which would be difficult. One possible solution could be 829 Recommendations for IPv6 in 3GPP Standards January 2002 831 using periodic unicast neighbor solicitations for the 832 temporary addresses [IPV6ND]. 834 Considering all the factors when evaluating the solutions, the 835 recommendation is to use Solution 1a. This solution requires the 836 least modification to the current 3GPP standards and maintains all 837 the advantages of the other solutions. 839 Effectively this would mean that each APN in a GGSN would have a 840 certain number of /64 prefixes that can be handed out at PDP 841 context Activation, through Router Advertisements. Therefore, 842 instead of using the full IPv6 address to identify a primary PDP 843 context, the IPv6 WG recommends that the GGSN use the entire prefix 844 (together with other 3GPP specific information) and that the SGSN 845 be informed of the prefixes that are assigned to a PDP context. By 846 assigning a given prefix to only one primary PDP context, the GGSN 847 and SGSN can associate a prefix list with each PDP context, as 848 needed. 850 Note that the recommended solution does not imply or assume that 851 the mobile device is a router. The MT is expected to use the /64 852 for itself and may also use this prefix for devices attached to it. 853 However this is not necessary if each device behind the MT is 854 connected to a separate primary PDP Context and therefore can use a 855 /64 which is not shared with other devices. The MT is also expected 856 to handle DAD locally for devices attached to it (e.g. laptops) 857 without forwarding Neighbor Solicitations over the air to the GGSN. 859 Recommendations for IPv6 in 3GPP Standards January 2002 861 11 References 863 [RFC2026] 864 S. Bradner, "The Internet Standards Process -- Revision 3", 865 RFC 2026, BCP9, October 1996 867 [KEYWORD] 868 S. Bradner, "Key words for use in RFCs to Indicate Requirement 869 Levels", RFC 2119, BCP14, March 1999. 871 [TR21905] 872 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0 874 [ADDRARCH] 875 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 876 RFC 2373, July 1998 878 [IPV6ND] 879 T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP 880 Version 6 (IPv6)", RFC 2461, December 1998 882 [AUTOCONF] 883 S. Thomson, T. Narten, "IPv6 Stateless Address 884 Autoconfiguration", RFC 2462, December 1998 886 [TS23060] 887 TS 23.060, "General Packet Radio Service (GPRS); Service 888 description; Stage 2", V4.1.0 890 [PRIVADDR] 891 T. Narten, R. Draves, "Privacy Extensions for Stateless 892 Address Autoconfiguration in IPv6", RFC 3041, January 2001 894 [IPV6ETH] 895 M. Crawford, "Transmission of IPv6 Packets over Ethernet 896 Networks", RFC 2464, December 1998 898 [PPPv6] 899 D. Haskin, E. Allen, "IP Version 6 over PPP", RFC2472, 900 December 1998. 902 [MULTLINK] 903 C. Huitema, D. Thaler, "Multi-link Subnet Support in IPv6", 904 draft-thaler-ipngwg-multilink-subnets-01.txt, July 2001 906 [SITEREN] 907 C. Huitema, "IPv6 Site Renumbering", draft-huitema-ipv6- 908 renumber-00.txt, July 2001 910 [HD] 911 C. Huitema, A. Durand, "The Host-Density Ratio for Address 912 Assignment Efficiency: An update on the H ratio", draft- 913 durand-huitema-h-density-ratio-02.txt, August 2001 914 Recommendations for IPv6 in 3GPP Standards January 2002 916 [IABAA] 917 IAB, IESG, "IAB/IESG Recommendations on IPv6 Address 918 Allocations to Sites", RFC3177, September 2001. 920 [AAPOL] 921 APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment 922 Global Policy". Draft of December, 22 2001, Version 2001-12- 923 22 [ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001- 924 12-22.txt] 926 [SCOPARCH] 927 S. Deering, et. al, "IPv6 Scoped Address Architecture", draft- 928 ietf-ipngwg-scoping-arch-02.txt, March 2001 930 [CELLREQ] 931 J. Arkko, et. al, "Minimum IPv6 Functionality for a Cellular 932 Host", draft-manyfolks-ipv6-cellular-host-01.txt, September 933 2001 935 [PREFDEL] 936 J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol 937 for Internet Protocol Version 6 (IPv6)", draft-haberman- 938 ipngwg-auto-prefix-01.txt, July 2001 939 Recommendations for IPv6 in 3GPP Standards January 2002 941 12 Authors and Acknowledgements 943 This document was written by the IPv6 3GPP design team: 945 Steve Deering, Cisco Systems 946 948 Karim El-Malki, Ericsson Radio Systems 949 951 Paul Francis, Tahoe Networks 952 954 Bob Hinden, Nokia 955 957 Christian Huitema, Microsoft 958 960 Niall Richard Murphy, Hutchison 3G 961 963 Markku Savela, Technical Research Centre of Finland 964 966 Jonne Soininen, Nokia 967 969 Margaret Wasserman, Wind River 970 972 Information was incorporated from a presentation co-authored by: 974 Juan-Antonio Ibanez, Ericsson Eurolab 976 13 Editor's Contact Information 978 Comments or questions regarding this document should be sent to: 980 Margaret Wasserman 981 Wind River 982 10 Tara Blvd., Suite 330 Phone: (603) 897-2067 983 Nashua, NH 03062 USA Email: mrw@windriver.com