--- 1/draft-ietf-ipv6-3gpp-recommend-00.txt 2006-02-05 00:01:59.000000000 +0100 +++ 2/draft-ietf-ipv6-3gpp-recommend-01.txt 2006-02-05 00:01:59.000000000 +0100 @@ -1,14 +1,14 @@ Internet-Draft M. Wasserman, Editor - Document: draft-ietf-ipv6-3gpp-recommend-00.txt Wind River - Expires: July 2002 January 2002 + Document: draft-ietf-ipv6-3gpp-recommend-01.txt Wind River + Expires: October 2002 April 2002 Recommendations for IPv6 in 3GPP Standards 1 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,77 +24,96 @@ The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2 Abstract This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use - of IPv6 in the 3GPP standards. The IPv6 Working Group supports the - use of IPv6 within 3GPP and offers these recommendations in a - spirit of open cooperation between the IPv6 Working Group and the - 3GPP community. + of IPv6 in the 3GPP standards. Specifically, this document + recommends that the 3GPP: + + 1. Specify that multiple prefixes may be assigned to each + primary PDP context, + 2. Require that a given prefix must not be assigned to more + than one primary PDP context, and + 3. Allow 3GPP nodes to use multiple identifiers within those + prefixes, including randomly generated identifiers. + + The IPv6 Working Group supports the use of IPv6 within 3GPP and + offers these recommendations in a spirit of open cooperation + between the IPv6 Working Group and the 3GPP community. Since the + original publication of this document as an Internet-Draft, the + 3GPP has adopted the primary recommendations of this document. 3 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. + Wasserman, Editor Expires May 2002 1 + Recommendations for IPv6 in 3GPP Standards April 2002 + 4 Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORD]. - Wasserman, Editor Expires May 2002 1 - Recommendations for IPv6 in 3GPP Standards January 2002 - 5 Table of Contents 1 Status of this Memo.......................................1 2 Abstract..................................................1 3 Copyright Notice..........................................1 - 4 Conventions Used In This Document.........................1 + 4 Conventions Used In This Document.........................2 5 Table of Contents.........................................2 6 Introduction..............................................3 6.1 What is the 3GPP?.........................................3 6.2 What is the IETF?.........................................4 6.3 Terminology...............................................4 - 6.3.1 3GPP Terminology..........................................4 + 6.3.1 3GPP Terminology..........................................5 6.3.2 IETF Terminology..........................................5 - 6.4 Overview of the IPv6 Addressing Architecture..............5 - 6.5 An IP-Centric View of the 3GPP System.....................6 + 6.4 Overview of the IPv6 Addressing Architecture..............6 + 6.5 An IP-Centric View of the 3GPP System.....................7 6.5.1 Overview of the UMTS Architecture.........................7 6.5.2 The PDP Context...........................................9 - 6.5.3 IPv6 Address Autoconfiguration in GPRS...................10 - 7 Recommendations to the 3GPP..............................12 - 7.1 Limitations of 3GPP Address Assignment...................12 - 7.2 Advertising Multiple Prefixes............................13 - 7.3 Assigning a Prefix to Only One Primary PDP Context.......13 - 7.3.1 Is a /64 per PDP Context Too Much?.......................13 - 7.3.2 Prefix Information in the SGSN...........................14 - 7.4 Multiple Identifiers per PDP Context.....................14 - 8 Additional IPv6 Work Items...............................16 - 9 Security Considerations..................................16 - 10 Appendix A: Analysis of Findings........................17 - 10.1 Address Assignment Solutions.............................17 - 11 References...............................................19 - 12 Authors and Acknowledgements.............................21 - 13 Editor's Contact Information.............................21 + 6.5.3 IPv6 Address Autoconfiguration in GPRS...................11 + 7 Recommendations to the 3GPP..............................13 + 7.1 Limitations of 3GPP Address Assignment...................13 + 7.2 Advertising Multiple Prefixes............................14 + 7.3 Assigning a Prefix to Only One Primary PDP Context.......14 + 7.3.1 Is a /64 per PDP Context Too Much?.......................14 + 7.3.2 Prefix Information in the SGSN...........................15 + 7.4 Multiple Identifiers per PDP Context.....................15 + 8 Additional IPv6 Work Items...............................17 + 9 Security Considerations..................................17 + 10 Appendix A: Analysis of Findings........................18 + 10.1 Address Assignment Solutions.............................18 + 11 References...............................................20 + 12 Authors and Acknowledgements.............................22 + 13 Editor's Contact Information.............................22 Wasserman, Editor Expires May 2002 2 - Recommendations for IPv6 in 3GPP Standards January 2002 + Recommendations for IPv6 in 3GPP Standards April 2002 6 Introduction + In May 2001, the IPv6 Working Group (WG) held an interim meeting in + Redmond, WA to discuss the use of IPv6 within the 3GPP standards. + An architectural overview of 3GPP was presented, and there was much + discussion regarding the use of IPv6 within 3GPP. At that meeting, + a decision was made to form a design team to write a document + offering advice from the IPv6 WG to the 3GPP community regarding + their use of IPv6. This document is the result of that effort. + This document offers recommendations to the 3GPP community from the IETF IPv6 Working Group. It is organized into three main sections: 1. An introduction (this section) that provides background information regarding the IETF IPv6 WG and the 3GPP and includes a high-level overview of the technologies discussed in this document. 2. Recommendations from the IPv6 WG to the 3GPP community. These can be found in section 7. @@ -111,102 +130,113 @@ protocols (i.e. SIP, IPv4, etc.), as they are outside the scope of the IPv6 Working Group. The IPv6 Working Group fully supports the use of IPv6 within 3GPP, and we encourage 3GPP implementers and operators to participate in the IETF process. We are offering these suggestions in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community, and we hope that our ongoing cooperation will help to strengthen both sets of standards. + The 3GPP address allocation information in this document is based + on the 3GPP document TS 23.060 version 4.1.0 [OLD-TS23060]. At the + 3GPP plenary meeting TSG #15 in March 2002, the 3GPP adopted the + two primary recommendations contained in this document, allocating + a unique prefix to each primary PDP context when IPv6 stateless + address autoconfiguration is used, and to allow the terminals to + use multiple interface identifiers. These changes were + retroactively applied from 3GPP release 99 onwards, in TS23.060 + versions 3.11.0, 4.4.0 and 5.1.0 [NEW-TS23060]. + 6.1 What is the 3GPP? The Third Generation Partnership Project (3GPP) is a global standardization partnership founded in late 1998. Its + + Wasserman, Editor Expires May 2002 3 + Recommendations for IPv6 in 3GPP Standards April 2002 + Organizational Partners have agreed to co-operate in the production of technical specifications for a Third Generation Mobile System based on the evolved GSM core networks. The 3GPP Organizational Partners consist of several different standardization organizations: ETSI from Europe, Standards Committee T1 Telecommunications (T1) in the USA, China Wireless Telecommunication Standard Group (CWTS), Korean Telecommunications Technology Association (TTA), the Association of Radio Industries and Businesses (ARIB) and the Telecommunication Technology Committee(TTC) in Japan. The work is coordinated by a Project Co-ordination Group (PCG), and structured into Technical Specification Groups (TSGs). There are five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network (GERAN), and the Terminals (TSG T). The TSGs are further divided - - Wasserman, Editor Expires May 2002 3 - Recommendations for IPv6 in 3GPP Standards January 2002 - into Working Groups (WGs). The technical work is done in the working groups, and later approved in the TSGs. 3GPP working methods are different from IETF working methods. The major difference is where the major part of the work is done. In 3GPP, the work is done in face-to-face meetings, and the mailing list is used mainly for distributing contributions, and for handling documents that were not handled in the meeting due to lack of time. Decisions are usually made by consensus, though voting does exist. However, it is rather rare to vote. 3GPP documents are - public and can be accessed at http://www.3gpp.org/. + public and can be accessed via the 3GPP web site [3GPP-URL]. 6.2 What is the IETF? The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. The IETF is also the primary standards body developing Internet protocols and standards. It is open to any interested individual. More - information about the IETF can be found at http://www.ietf.org. + information about the IETF can be found at the IETF web site [IETF- + URL]. The actual technical work of the IETF is done in working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). The IPv6 Working Group is chartered within the Internet area of the IETF. Much of the work is handled via mailing lists, and the IETF holds meetings three times per year. 6.3 Terminology This section defines the 3GPP and IETF terminology used in this document. The 3GPP terms and their meanings have been taken from [TR21905]. + Wasserman, Editor Expires May 2002 4 + Recommendations for IPv6 in 3GPP Standards April 2002 + 6.3.1 3GPP Terminology APN Access Point Name. The APN is a logical name referring to a GGSN and an external network. CS Circuit Switched GERAN GSM/EDGE Radio Access Network GGSN Gateway GPRS Support Node. A router between the GPRS network and an external network (i.e. the Internet). GPRS General Packet Radio Services GTP-U General Tunneling Protocol - User Plane MT Mobile Termination. For example, a mobile phone handset. - Wasserman, Editor Expires May 2002 4 - Recommendations for IPv6 in 3GPP Standards January 2002 - PDP Packet Data Protocol PDP Context A PDP connection between the UE and the GGSN. PS Packet Switched SGSN Serving GPRS Support Node TE Terminal Equipment. For example, a laptop attached through a 3GPP handset. @@ -217,51 +247,51 @@ UMTS Universal Mobile Telecommunications System USIM Universal Subscriber Identity Module. Typically, a card that is inserted into a mobile phone handset. UTRAN Universal Terrestrial Radio Access Network 6.3.2 IETF Terminology - IPv6 Internet Protocol version 6 + IPv6 Internet Protocol version 6 [RFC 2460] NAS Network Access Server NAT Network Address Translator NAT-PT Network Address Translation with Protocol Translation. - An IPv6 transition mechanism. + An IPv6 transition mechanism. [NAT-PT] - PPP Point-to-Point Protocol + PPP Point-to-Point Protocol [PPP] - SIIT Stateless IP/ICMP Transition Mechanism + Wasserman, Editor Expires May 2002 5 + Recommendations for IPv6 in 3GPP Standards April 2002 + + SIIT Stateless IP/ICMP Transition Mechanism [SIIT] 6.4 Overview of the IPv6 Addressing Architecture The recommendations in this document are primarily related to IPv6 address assignment. To fully understand the recommended changes, it is necessary to understand the IPv6 addressing architecture, and current IPv6 address assignment mechanisms. The IPv6 addressing architecture represents a significant evolution from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes be able to assemble their own addresses from interface identifiers and prefix information. This mechanism is called IPv6 Host Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure themselves without the need for stateful configuration servers (i.e. DHCPv6) or statically configured addresses. - Wasserman, Editor Expires May 2002 5 - Recommendations for IPv6 in 3GPP Standards January 2002 - Interface identifiers can be globally unique, such as modified EUI- 64 addresses [ADDRARCH], or non-unique, such as randomly generated identifiers. Hosts that have a globally unique identifier available may also choose to use randomly generated addresses for privacy [PRIVADDR] or for other reasons. IPv6 hosts are free to generate new identifiers at any time, and Duplicate Address Detection (DAD) is used to protect against the use of duplicate identifiers on a single link [IPV6ND]. A constant link-local prefix can be combined with any interface @@ -284,42 +314,42 @@ IPv6 explicitly associates each address with an interface. Multiple-interface hosts may have interfaces on more than one link or in more than one site. Links and sites are internally identified using zone identifiers. Proper routing of non-global traffic and proper address selection are ensured by the IPv6 scoped addressing architecture [SCOPARCH]. IPv6 introduces the concept of privacy addresses [PRIVADDR]. These addresses are generated from an advertised global prefix and a + + Wasserman, Editor Expires May 2002 6 + Recommendations for IPv6 in 3GPP Standards April 2002 + randomly generated identifier, and are used for anonymous access to Internet services. Applications control the generation of privacy addresses, and new addresses can be generated at any time. The IPv6 site renumbering specification [SITEREN] relies upon the fact that IPv6 nodes will generate new addresses when new prefixes are advertised on the link, and that they will deprecate addresses that use deprecated prefixes. In the future, additional IPv6 specifications may rely upon the ability of IPv6 nodes to use multiple prefixes and/or multiple identifiers to dynamically create new addresses. 6.5 An IP-Centric View of the 3GPP System The 3GPP specifications define a Third Generation Mobile System. An overview of the packet switched (PS) domain of the 3GPP Release 99 system is described in the following sections. The authors hope - - Wasserman, Editor Expires May 2002 6 - Recommendations for IPv6 in 3GPP Standards January 2002 - that this description is sufficient for the reader who is unfamiliar with the UMTS packet switched service to understand how the UMTS system works, and how IPv6 is currently defined to be used within it. 6.5.1 Overview of the UMTS Architecture The UMTS architecture can be divided into two main domains -- the packet switched (PS) domain, and the circuit switched (CS) domain. In this document, we will concentrate on the PS domain, or General @@ -331,20 +361,23 @@ | +R | ------ Uu ----------- Iu ----------- Gn ----------- Gi | MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+-- ------ ----------- ----------- ----------- (UE) Figure 1: Simplified GPRS Architecture + Wasserman, Editor Expires May 2002 7 + Recommendations for IPv6 in 3GPP Standards April 2002 + ------ | | | App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer) | | |------| ------------- | IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |-> | v4/6 | | v4/6 | |------| ------------- ------------- |------ | | | | \ Relay / | | \ Relay / | | | | | | | \ / | | \ / | | | | @@ -357,26 +390,22 @@ | RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | | | | | | v4/6 | | v4/6 | v4/6 | |v4/6 | | |------| |------|------| |------|------| |------|------| | MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 | |------| |------|------| |------|------| |------|------| | L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 | ------ ------------- ------------- ------------- UE UTRAN SGSN GGSN (handset) - Figure 2: GPRS Protocol Stacks - Wasserman, Editor Expires May 2002 7 - Recommendations for IPv6 in 3GPP Standards January 2002 - ------ | | | App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer) | | |------| | | | IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN) | v4/6 | | | | | |------| |-------------| @@ -385,27 +414,29 @@ | | | \ / | | | | \ / PDCP|- - - (to UTRAN) | | | | | | PPP |- - -| PPP |------| | | | | RLC |- - - (to UTRAN) | | | |------| | | | | MAC | |------| |------|------| | L1a |- - -| L1a | L1b |- - - (to UTRAN) ------ ------------- - TE MT (laptop) (handset) Figure 3: Laptop Attached to 3GPP Handset - The GRPS core network elements shown in Figures 1 and 2 are the + Wasserman, Editor Expires May 2002 8 + Recommendations for IPv6 in 3GPP Standards April 2002 + + The GPRS core network elements shown in Figures 1 and 2 are the User Equipment (UE), Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN). The UTRAN comprises Radio Access Network Controllers (RNC) and the UTRAN base stations. GGSN A specialized router that functions as the gateway between the GPRS network and the external networks, e.g. Internet. It also gathers charging information about the connections. In many ways the GGSN is similar to a Network Access Server (NAS). SGSN The SGSN's main functions include authentication, @@ -413,26 +444,23 @@ information. The SGSN is connected to the SS7 network and through that to the Home Location Register (HLR), so that it can perform user profile handling, authentication, and authorization. GTP-U is a simple tunnelling protocol running over UDP/IP and used to route packets between RNC, SGSN and GGSN within the same, or between different, UMTS backbone(s). A GTP-U tunnel is identified at each end by a Tunnel Endpoint Identifier (TEID). - Wasserman, Editor Expires May 2002 8 - Recommendations for IPv6 in 3GPP Standards January 2002 - Only the most significant elements of the GPRS system are discussed in this document. More information about the GPRS system can be - found in [TS23060]. + found in [OLD-TS23060]. 6.5.2 The PDP Context The most important 3GPP concept in this context is a PDP Context. A PDP Context is a connection between the UE and the GGSN, over which the packets are transferred. There are two kinds of PDP Contexts -- primary, and secondary. The primary PDP Context initially defines the link to the GGSN. For instance, an IP address is assigned to each primary PDP Context. In @@ -448,20 +476,23 @@ between the UE and the GGSN, as long as there are other (secondary) PDP contexts active for the same IP address. There are currently three PDP Types supported in GPRS -- IPv4, IPv6, and PPP. This document will only discuss the IPv6 PDP Type. There are three basic actions that can be performed on a PDP Context: PDP Context Activation, Modification, and Deactivation. These actions are described in the following. + Wasserman, Editor Expires May 2002 9 + Recommendations for IPv6 in 3GPP Standards April 2002 + Activate PDP Context Opens a new PDP Context to a GGSN. If a new primary PDP Context is activated, there is a new link created between a UE and a GGSN. A UE can open multiple primary PDP Contexts to one or more GGSNs. Modify PDP Context Changes the characteristics of a PDP Context, for @@ -470,78 +501,73 @@ Deactivate PDP Context Deactivates a PDP Context. If a primary PDP Context and all secondary PDP contexts associated with it are deactivated, a link between the UE and the GGSN is removed. The APN is a name which is logically linked to a GGSN. The APN may identify a service or an external network. The syntax of the APN corresponds to a fully qualified domain name. At PDP context - - Wasserman, Editor Expires May 2002 9 - Recommendations for IPv6 in 3GPP Standards January 2002 - activation, the SGSN performs a DNS query to find out the GGSN(s) serving the APN requested by the terminal. The DNS response contains a list of GGSN addresses from which the SGSN selects one (in a round-robin fashion). --------- -------- | | | GGSN | | | LINK 1 | | | -======== PDP Context A ========- - - -> ISP X | | | | | | | | | | | | | /======= PDP Context B =======\ | | - | LINK 2 | - - - -> ISP Y | \======= PDP Context C =======/ | | | | | - | | | | | MT | -------- |(handset)| | | -------- -------- | | | GGSN | | | | | LINK 3 | | | | | -======== PDP Context D ========- | | TE | | | | | |(laptop)| | | | - - -> ISP Z | | | | LINK 4 | | | -====PPP====-----======== PDP Context E ========- | | | | | | | | | | | | | -------- --------- -------- Figure 3: Correspondence of PDP Contexts to IPv6 Links + Wasserman, Editor Expires May 2002 10 + Recommendations for IPv6 in 3GPP Standards April 2002 + 6.5.3 IPv6 Address Autoconfiguration in GPRS GPRS supports static and dynamic address allocation. Two types of dynamic address allocation are supported -- stateless, and stateful. Stateful address configuration uses an external protocol to connect to a server that gives the IP address, e.g. DHCP. The stateless IPv6 autoconfiguration works differently in GPRS than in Ethernet networks. GPRS nodes have no unique identifier, whereas Ethernet nodes can create an identifier from their EUI-48 address. Because GPRS networks are similar to dialup networks, the stateless address autoconfiguration in GPRS was based on PPPv6 [PPPV6]. 3GPP address autoconfiguration has the following steps: 1. The Activate PDP Context message is sent to the SGSN (PDP Type=IPv6, PDP Address = 0, etc.). - Wasserman, Editor Expires May 2002 10 - Recommendations for IPv6 in 3GPP Standards January 2002 - 2. The SGSN sends a Create PDP Context message to the GGSN with the above parameters. 3. GGSN chooses an interface identifier for the PDP Context and creates the link-local address. It answers the SGSN with a Create PDP Context response (PDP Address = link-local address). 4. The SGSN sends an Activate PDP Context accept message to the UE (PDP Address = link-local address). @@ -563,29 +589,33 @@ for communication on the Internet. A handset may create many primary and/or secondary PDP contexts throughout the life of its connection with a GGSN. Within 3GPP, the GGSN assigns a single 64-bit identifier to each primary PDP context. The GGSN also advertises a single /64 prefix to the handset, and these two items are assembled into a single IPv6 address. Later, the GGSN modifies the PDP context entry in the SGSN to include the whole IPv6 address, so that the SGSN can know the single address of each 3GPP node (e.g. for billing + + Wasserman, Editor Expires May 2002 11 + Recommendations for IPv6 in 3GPP Standards April 2002 + purposes). This address is also used in the GGSN to identify the PDP context associated with each packet. It is assumed that 3GPP nodes will not generate any addresses, except for the single identifier/prefix combination assigned by the GGSN. DAD is not performed, as the GGSN will not assign the same address to multiple nodes. - Wasserman, Editor Expires May 2002 11 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 12 + Recommendations for IPv6 in 3GPP Standards April 2002 7 Recommendations to the 3GPP In the spirit of productive cooperation, the IPv6 Working Group recommends that the 3GPP consider three changes regarding the use of IPv6 within GPRS. Specifically, we recommend that the 3GPP 1. Specify that multiple prefixes may be assigned to each primary PDP context, @@ -625,22 +655,22 @@ The current 3GPP address assignment mechanism has the following limitations: The GGSN only advertises a single /64 prefix, rather than a set of prefixes. This will prevent the participation of 3GPP nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site renumbering, or in other mechanisms that expect IPv6 hosts to create addresses based on multiple advertised prefixes. - Wasserman, Editor Expires May 2002 12 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 13 + Recommendations for IPv6 in 3GPP Standards April 2002 A 3GPP node is assigned a single identifier and is not allowed to generate additional identifiers. This will prevent the use of privacy addresses by 3GPP nodes. This also makes 3GPP mechanisms not fully compliant with the expected behavior of IPv6 nodes, which will result in incompatibility with popular laptop IPv6 stacks. For example, a laptop that uses privacy addresses for web browser connections could not currently not currently establish a web browser connection over a 3GPP link. @@ -683,22 +713,22 @@ to each primary PDP context. This will allow sufficient address space for a 3GPP-attached node to allocate privacy addresses and/or route to a multi-link subnet [MULTLINK], and will discourage the use of NAT within 3GPP-attached devices. 7.3.1 Is a /64 per PDP Context Too Much? If an operator assigns a /64 per PDP context, can we be assured that there is enough address space for millions of mobile devices? - Wasserman, Editor Expires May 2002 13 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 14 + Recommendations for IPv6 in 3GPP Standards April 2002 This question can be answered in the positive using the Host Density (HD) Ratio for address assignment efficiency [HD]. This is a measure of the number of addresses that can practically and easily be assigned to hosts, taking into consideration the inefficiencies in usage resulting from the various address assignment processes. The HD ratio was empirically derived from actual telephone number and data network address assignment cases. @@ -718,90 +748,87 @@ majority of these IPv6 /64 prefixes will be used by non-3GPP networks, there is still clearly a sufficient number of /64 prefixes. Given this, it can be safely concluded that the IPv6 address space will not be exhausted if /64 prefixes are allocated to primary PDP contexts. For more information regarding policies for IPv6 address assignment, refer to the IAB/IESG recommendations regarding address - assignment [IABAA], the APNIC, ARIN and RIPE address allocation - policy [AAPOL] and the ARIN minutes located at - http://www.arin.net/minutes/bot/bot08152001.html. + assignment [IABAA], and the APNIC, ARIN and RIPE address allocation + policy [AAPOL]. 7.3.2 Prefix Information in the SGSN Currently, the 3GPP standards allow only one prefix and one identifier for each PDP context. So, the GGSN can send a single IPv6 address to the SGSN, to be used for billing purposes, etc. Instead of using the full IPv6 address to identify a PDP context, the IPv6 WG recommends that the SGSN be informed of each prefix that is currently assigned to a PDP context. By assigning a prefix to only one primary PDP context, the SGSN can associate a prefix list with each PDP context. 7.4 Multiple Identifiers per PDP Context The IPv6 WG also recommends that the 3GPP standards be modified to allow multiple identifiers, including randomly generated identifiers, to be used within each assigned prefix. This would allow 3GPP nodes to generate and use privacy addresses, and would + be compatible with future IPv6 standards that may depend on the - Wasserman, Editor Expires May 2002 14 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 15 + Recommendations for IPv6 in 3GPP Standards April 2002 - be compatible with future IPv6 standards that may depend on the ability of IPv6 nodes to generate new interface identifiers for communication. This is a vital change, necessary to allow standards-compliant IPv6 nodes to connect to the Internet through 3GPP handsets, without modification. It is expected that most IPv6 nodes, including the most popular laptop stacks, will generate privacy addresses. The current 3GPP specifications will not be compatible with those implementations. - Wasserman, Editor Expires May 2002 15 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 16 + Recommendations for IPv6 in 3GPP Standards April 2002 8 Additional IPv6 Work Items During our work on this document, we have discovered several areas that could benefit from further informational or standards-track work within the IPv6 Working Group. The IPv6 WG should work to define a point-to-point architecture and specify how the standard IPv6 address assignment mechanisms are applicable to IPv6 over point-to-point links. We should also - review and clarify the IPv6 over PPP specification to match the - current IPv6 addressing architecture. + review and clarify the IPv6 over PPP specification [PPP] to match + the current IPv6 addressing architecture [ADDRARCH]. The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" - document. This document would be useful for developers writing - drivers for IPv6 stacks to work over 3GPP PDP Contexts. + (or similar) document. This document would be useful for + developers writing drivers for IPv6 stacks to work over 3GPP PDP + Contexts. - There is an ongoing effort to define a set of requirements for - cellular hosts [CELLREQ]. This work has been presented to the IPv6 - WG, but has not been adopted as an IPv6 WG work item. This work - should be continued within the working group, and may feed into a - broader effort to define the requirements for all IPv6 nodes. + The IPv6 working group should undertake an effort to define the + minimal requirements for all IPv6 nodes. 9 Security Considerations This document contains recommendations on the use of the IPv6 protocol in 3GPP standards. It does not specify a protocol, and it introduces no new security considerations. - Wasserman, Editor Expires May 2002 16 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 17 + Recommendations for IPv6 in 3GPP Standards April 2002 10 Appendix A: Analysis of Findings This section includes some analysis that may be useful to understanding why the IPv6 working group is making the above recommendations. It also includes some other options that were explored, and the reasons why those options were less suitable than the recommendations outlined above. 10.1 Address Assignment Solutions @@ -843,22 +870,22 @@ 2. Share the same prefix between multiple PDP Contexts connected to the same GGSN (and APN). Given that mobile devices may generate multiple addresses using more than one interface identifier, this would require DAD for the newly generated addresses over the air interface, and a proxy DAD function which would increase the complexity and the amount of state to be kept in the GGSN. Also, the GGSN would need to determine when the temporary addresses are no longer in use which would be difficult. One possible solution could be - Wasserman, Editor Expires May 2002 17 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 18 + Recommendations for IPv6 in 3GPP Standards April 2002 using periodic unicast neighbor solicitations for the temporary addresses [IPV6ND]. Considering all the factors when evaluating the solutions, the recommendation is to use Solution 1a. This solution requires the least modification to the current 3GPP standards and maintains all the advantages of the other solutions. Effectively this would mean that each APN in a GGSN would have a @@ -874,52 +901,81 @@ Note that the recommended solution does not imply or assume that the mobile device is a router. The MT is expected to use the /64 for itself and may also use this prefix for devices attached to it. However this is not necessary if each device behind the MT is connected to a separate primary PDP Context and therefore can use a /64 which is not shared with other devices. The MT is also expected to handle DAD locally for devices attached to it (e.g. laptops) without forwarding Neighbor Solicitations over the air to the GGSN. - Wasserman, Editor Expires May 2002 18 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 19 + Recommendations for IPv6 in 3GPP Standards April 2002 11 References + [OLD-TS23060] + TS 23.060, "General Packet Radio Service (GPRS); Service + description; Stage 2", V4.1.0 + + [NEW-TS23060] + TS 23.060 version 3.11.0 (release 99), 4.4.0 (release 4) + and 5.1.0 (release 5). + + [3GPP-URL] + http://www.3gpp.org + + [IETF-URL] + http://www.ietf.org + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, BCP9, October 1996 [KEYWORD] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1999. [TR21905] 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0 + [IPV6] + S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [NAT-PT] + G. Tsirtsis, P. Shrisuresh, "Network Address Translation - + Protocol Translation (NAT-PT)", RFC2766, February 2000. + + [PPP] + Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [SIIT] + E. Nordmark, "Stateless IP/ICMP Translation Algorithm", RFC + 2765, February 2000. + [ADDRARCH] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998 [IPV6ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998 + Wasserman, Editor Expires May 2002 20 + Recommendations for IPv6 in 3GPP Standards April 2002 + [AUTOCONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998 - [TS23060] - TS 23.060, "General Packet Radio Service (GPRS); Service - description; Stage 2", V4.1.0 - [PRIVADDR] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001 [IPV6ETH] M. Crawford, "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998 [PPPv6] D. Haskin, E. Allen, "IP Version 6 over PPP", RFC2472, @@ -931,23 +987,20 @@ [SITEREN] C. Huitema, "IPv6 Site Renumbering", draft-huitema-ipv6- renumber-00.txt, July 2001 [HD] C. Huitema, A. Durand, "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio", draft- durand-huitema-h-density-ratio-02.txt, August 2001 - Wasserman, Editor Expires May 2002 19 - Recommendations for IPv6 in 3GPP Standards January 2002 - [IABAA] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC3177, September 2001. [AAPOL] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment Global Policy". Draft of December, 22 2001, Version 2001-12- 22 [ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001- 12-22.txt] @@ -958,22 +1011,22 @@ [CELLREQ] J. Arkko, et. al, "Minimum IPv6 Functionality for a Cellular Host", draft-manyfolks-ipv6-cellular-host-01.txt, September 2001 [PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", draft-haberman- ipngwg-auto-prefix-01.txt, July 2001 - Wasserman, Editor Expires May 2002 20 - Recommendations for IPv6 in 3GPP Standards January 2002 + Wasserman, Editor Expires May 2002 21 + Recommendations for IPv6 in 3GPP Standards April 2002 12 Authors and Acknowledgements This document was written by the IPv6 3GPP design team: Steve Deering, Cisco Systems Karim El-Malki, Ericsson Radio Systems @@ -1005,11 +1058,11 @@ 13 Editor's Contact Information Comments or questions regarding this document should be sent to: Margaret Wasserman Wind River 10 Tara Blvd., Suite 330 Phone: (603) 897-2067 Nashua, NH 03062 USA Email: mrw@windriver.com - Wasserman, Editor Expires May 2002 21 + Wasserman, Editor Expires May 2002 22