diff options
Diffstat (limited to 'doc/rfc/rfc3314.txt')
| -rw-r--r-- | doc/rfc/rfc3314.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc3314.txt b/doc/rfc/rfc3314.txt new file mode 100644 index 0000000..b966f33 --- /dev/null +++ b/doc/rfc/rfc3314.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group M. Wasserman, Ed. +Request for Comments: 3314 Wind River +Category: Informational September 2002 + + + Recommendations for IPv6 in + Third Generation Partnership Project (3GPP) Standards + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +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. Specifically, this document recommends that the 3GPP + specify that multiple prefixes may be assigned to each primary PDP + context, require that a given prefix must not be assigned to more + than one primary PDP context, and 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. + +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 BCP 14, RFC 2119 + [KEYWORD]. + + + + + + + + + +Wasserman Informational [Page 1] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +Table of Contents + + 1 Introduction............................................. 2 + 1.1 What is the 3GPP?........................................ 3 + 1.2 What is the IETF?........................................ 4 + 1.3 Terminology.............................................. 4 + 1.3.1 3GPP Terminology......................................... 4 + 1.3.2 IETF Terminology......................................... 5 + 1.4 Overview of the IPv6 Addressing Architecture............. 6 + 1.5 An IP-Centric View of the 3GPP System.................... 7 + 1.5.1 Overview of the UMTS Architecture........................ 7 + 1.5.2 The PDP Context.......................................... 10 + 1.5.3 IPv6 Address Autoconfiguration in GPRS................... 11 + 2 Recommendations to the 3GPP.............................. 13 + 2.1 Limitations of 3GPP Address Assignment................... 13 + 2.2 Advertising Multiple Prefixes............................ 14 + 2.3 Assigning a Prefix to Only One Primary PDP Context....... 14 + 2.3.1 Is a /64 per PDP Context Too Much?....................... 15 + 2.3.2 Prefix Information in the SGSN........................... 16 + 2.4 Multiple Identifiers per PDP Context..................... 16 + 3 Additional IPv6 Work Items............................... 16 + 4 Security Considerations.................................. 17 + Appendix A: Analysis of Findings................................ 18 + Address Assignment Solutions..................................... 18 + References....................................................... 19 + Authors and Acknowledgements..................................... 22 + Editor's Address................................................. 22 + Full Copyright Statement......................................... 23 + +1. 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. + The first day of the meeting was a joint discussion with 3GPP, during + which an architectural overview of 3GPP's usage of IPv6 was + presented, and there was much discussion regarding particular aspects + of IPv6 usage 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. + + + +Wasserman Informational [Page 2] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 2. Recommendations from the IPv6 WG to the 3GPP community. These + can be found in section 2. + + 3. Further work items that should be considered by the IPv6 WG. + These items are discussed in section 3. + + It is the purpose of this document to provide advice from the IPv6 + Working Group to the 3GPP community. We have limited the contents of + this document to items that are directly related to the use of IPv6 + within 3GPP. This document defines no standards, and it is not a + definitive source of information regarding IPv6 or 3GPP. We have not + chosen to explore 3GPP-related issues with other IETF 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 allowing 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]. + +1.1 What is the 3GPP? + + The Third Generation Partnership Project (3GPP) is a global + standardization partnership founded in late 1998. Its 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. + + + + +Wasserman Informational [Page 3] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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 + 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 majority 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 via the 3GPP web site [3GPP-URL]. + +1.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 the IETF web site [IETF- + URL]. + + The actual technical work of the IETF is done in working groups, + 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. + +1.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]. + +1.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 + + + +Wasserman Informational [Page 4] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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. + + 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. + + UE User Equipment (TE + MT + USIM). An example would be + a mobile handset with a USIM card inserted and a + laptop attached. + + 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 + +1.3.2 IETF Terminology + + 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. [NAT-PT] + + PPP Point-to-Point Protocol [PPP] + + SIIT Stateless IP/ICMP Transition Mechanism [SIIT] + + + + + +Wasserman Informational [Page 5] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +1.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. + + 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 + identifier to build an address for communication on a locally + attached link. IPv6 routers may advertise additional prefixes + (site-local and/or global prefixes)[IPV6ND]. Hosts can combine + advertised prefixes with their own interface identifiers to create + addresses for site-local and global communication. + + IPv6 introduces architectural support for scoped unicast addressing + [SCOPARCH]. A single interface will typically have multiple + addresses for communication within different scopes: link-local, + site-local and/or global [ADDRARCH]. Link-local addresses allow for + local communication, even when an IPv6 router is not present. Some + IPv6 protocols (i.e., routing protocols) require the use of link- + local addresses. Site-local addressing allows communication to be + administratively contained within a single site. Link-local or + site-local connections may also survive changes to global prefix + information (e.g., site renumbering). + + 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]. + + + +Wasserman Informational [Page 6] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + IPv6 introduces the concept of privacy addresses [PRIVADDR]. These + addresses are generated from an advertised global prefix and a + 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. + +1.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 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. + +1.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 + Packet Radio Services (GPRS). + + ------ + | TE | + ------ + | + +R + | + ------ Uu ----------- Iu ----------- Gn ----------- Gi + | MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+-- + ------ ----------- ----------- ----------- + (UE) + + Figure 1: Simplified GPRS Architecture + + + + + + + + +Wasserman Informational [Page 7] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + ------ + | | + | App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer) + | | + |------| ------------- + | IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |-> + | v4/6 | | v4/6 | + |------| ------------- ------------- |------ | + | | | \ Relay / | | \ Relay / | | | | + | | | \ / | | \ / | | | | + | | | \ / | | \ / | | | | + | PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U | | + | | | | | | | | | | | + |------| |------|------| |------|------| |------| | + | | | | UDP |- - -| UDP | UDP |- - -| UDP | | + | | | |------| |------|------| |------| | + | 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 Informational [Page 8] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + ------ + | | + | App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer) + | | + |------| + | | + | IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN) + | v4/6 | + | | | | + |------| |-------------| + | | | \ Relay / | + | | | \ / | + | | | \ / | + | | | \ / 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 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, + authorization, mobility management, and collection of billing + 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. + + + + + + + +Wasserman Informational [Page 9] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + GTP-U: 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). + + Only the most significant elements of the GPRS system are discussed + in this document. More information about the GPRS system can be + found in [OLD-TS23060]. + +1.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 + addition, one or more secondary PDP Contexts can be added to a + primary PDP Context, sharing the same IP address. These secondary + PDP Contexts can have different Quality of Service characteristics + than the primary PDP Context. + + Together, a primary PDP Context and zero or more secondary PDP + Contexts define, in IETF terms, a link. GPRS links are point-to- + point. Once activated, all PDP contexts have equal status, meaning + that a primary PDP context can be deleted while keeping the link + 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. + + 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 example QoS + attributes. + + + +Wasserman Informational [Page 10] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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 + 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 + +1.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. + + + + +Wasserman Informational [Page 11] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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.). + + 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). + + 5. The UE keeps the link-local address, and extracts the interface + identifier for later use. The UE may send a Router + Solicitation message to the GGSN (first hop router). + + 6. After the PDP Context Activation, the GGSN sends a Router + Advertisement to the UE. + + 7. The UE should be configured not to send a Neighbor Solicitation + message. However, if one is sent, the GGSN will silently + discard it. + + 8. The GGSN updates the SGSN with the whole IPv6 address. + + Each connected handset or laptop will create a primary PDP context + 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 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 + + + + +Wasserman Informational [Page 12] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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. + +2 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, + + 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. + + Making these changes would provide several advantages for 3GPP + implementers and users: + + Laptops that connect to 3GPP handsets will work without any + software changes. Their implementation of the standard IPv6 over + PPP, address assignment, and autoconfiguration mechanisms will + work without any modification. This will eliminate the need for + vendors and operators to build and test special 3GPP drivers and + related software. As currently specified, the 3GPP standards will + be incompatible with laptop implementations that generate their + own identifiers for privacy or other purposes. + + IPv6 software implementations could be used in 3GPP handsets + without any modifications to the IPv6 protocol mechanisms. This + will make it easier to build and test 3GPP handsets. + + Applications in 3GPP handsets will be able to take advantage of + different types of IPv6 addresses (e.g., static addresses, + temporary addresses for privacy, site-scoped addresses for site + only communication, etc.) + + The GPRS system will be better positioned to take advantage of new + IPv6 features that are built around the current addressing + architecture. + +2.1 Limitations of 3GPP Address Assignment + + The current 3GPP address assignment mechanism has the following + limitations: + + + +Wasserman Informational [Page 13] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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. + + 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 establish a web browser + connection over a 3GPP link. + + These limitations could be avoided by enabling the standard IPv6 + address allocation mechanisms in 3GPP nodes. The GGSN could + advertise one or more prefixes for the local link in standard IPv6 + Router Advertisements, and IPv6 addresses could be assembled, as + needed, by the IPv6 stack on the handset or laptop. An interface + identifier could still be assigned by the GGSN, as is currently + specified in the 3GPP standards. However, the handset or laptop + could generate additional identifiers, as needed for privacy or other + reasons. + +2.2 Advertising Multiple Prefixes + + For compliance with current and future IPv6 standards, the IPv6 WG + recommends that the 3GPP allow multiple prefixes to be advertised for + each primary PDP context. This would have several advantages, + including: + + 3GPP nodes could participate in site renumbering and future IPv6 + mechanisms that rely on the use of multiple global prefixes on a + single link. + + Site-local prefixes could be advertised on 3GPP links, if desired, + allowing for site-constrained communication that could survive + changes to global prefix information (e.g., site renumbering). + +2.3 Assigning a Prefix to Only One Primary PDP Context + + The IPv6 WG recommends that the 3GPP treat a primary PDP context, + along with its secondary PDP contexts, as a single IPv6 link, and + that the GGSN view each primary PDP context as a single subnet. + Accordingly, a given global (or site-local) prefix should not be + assigned to more than one PDP context. + + + + +Wasserman Informational [Page 14] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + Because multiple IPv6 hosts may attach through a 3GPP handset, the + IPv6 WG recommends that one or more /64 prefixes should be assigned + 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. + +2.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? 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. + + We can calculate the number of easily assignable /64's making the + following assumptions: + + An HD ratio of 0.8 (representing the efficiency that can be + achieved with no particular difficulty). + + Only addresses with the 3-bit prefix 001 (the Aggregatable Global + Unicast Addresses defined by RFC 2373) are used, resulting in 61 + bits of assignable address space. + + Using these assumptions, a total of 490 trillion (490x10^12) /64 + prefixes can be assigned. This translates into around 80,000 PDP + Contexts per person on the earth today. Even assuming that a + 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], and the APNIC, ARIN and RIPE address allocation policy + [AAPOL]. + + + + + + + + +Wasserman Informational [Page 15] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +2.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. + +2.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 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. + +3 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 [PPP] to match the + current IPv6 addressing architecture [ADDRARCH]. + + The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" + (or similar) document. This document would be useful for developers + writing drivers for IPv6 stacks to work over 3GPP PDP Contexts. + + The IPv6 working group should undertake an effort to define the + minimal requirements for all IPv6 nodes. + + + + + +Wasserman Informational [Page 16] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +4 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 Informational [Page 17] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +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. + +A.1 Address Assignment Solutions + + In order to allow for the configuration and use of multiple IPv6 + addresses per primary PDP Context having different interface + identifiers, some modifications to the current 3GPP specifications + would be required. + + The solutions to achieve this were evaluated against the following + factors: + + - Scarcity and high cost of wireless spectrum + - Complexity of implementation and state maintenance + - Stability of the relevant IETF standards + - Impact on current 3GPP standards + + Two solutions to allow autoconfiguration of multiple addresses on the + same primary PDP Context were considered: + + 1. Assign one or more entire prefixes (/64s) to a PDP Context upon + PDP Context activation and allow the autoconfiguration of + multiple addresses. + + a) The assignment may be performed by having the GGSN advertise + one or more /64 prefixes to the mobile device. + + b) The assignment may be performed by building "prefix + delegation" functionality into the PDP Context messages or + by using layer 3 mechanisms such as [PREFDEL]. In this way, + the prefix is not assigned to the link between the GGSN and + the mobile device (as in 1a), but it is assigned to the + mobile device itself. Note that [PREFDEL] cannot be + considered stable and has not, at this stage, been adopted + by the IPv6 WG as a WG document. + + 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 + + + +Wasserman Informational [Page 18] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + 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 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 + certain number of /64 prefixes that can be handed out at PDP context + Activation, through Router Advertisements. Therefore, instead of + using the full IPv6 address to identify a primary PDP context, the + IPv6 WG recommends that the GGSN use the entire prefix (together with + other 3GPP specific information) and that the SGSN be informed of the + prefixes that are assigned to a PDP context. By assigning a given + prefix to only one primary PDP context, the GGSN and SGSN can + associate a prefix list with each PDP context, as needed. + + 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. + +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] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996 + + [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1999. + + + + +Wasserman Informational [Page 19] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + [TR21905] 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", + V5.0.0 + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [NAT-PT] Tsirtsis, G. and P. Shrisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [SIIT] Nordmark, N., "Stateless IP/ICMP Translation + Algorithm", RFC 2765, February 2000. + + [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [IPV6ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998 + + [PRIVADDR] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [IPV6ETH] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC + 2472, December 1998. + + [MULTLINK] C. Huitema, D. Thaler, "Multi-link Subnet Support in + IPv6", Work in Progress. + + [SITEREN] C. Huitema, "IPv6 Site Renumbering", Work in Progress. + + [HD] Durand, A. and C. Huitema, "The Host-Density Ratio for + Address Assignment Efficiency: An update on the H + ratio", RFC 3194, November 2001. + + [IABAA] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address + Allocations to Sites", RFC 3177, September 2001. + + + + +Wasserman Informational [Page 20] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + + [AAPOL] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and + Assignment Global Policy", Work in Progress. + + [SCOPARCH] S. Deering, et. al., "IPv6 Scoped Address + Architecture", Work in Progress. + + [CELLREQ] J. Arkko, et. al., "Minimum IPv6 Functionality for a + Cellular Host", Work in Progress. + + [PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation + Protocol for Internet Protocol Version 6 (IPv6)", Work + in Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wasserman Informational [Page 21] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +Authors and Acknowledgements + + This document was written by the IPv6 3GPP design team: + + Steve Deering, Cisco Systems + EMail: deering@cisco.com + + Karim El-Malki, Ericsson Radio Systems + EMail: Karim.El-Malki@era.ericsson.se + + Paul Francis, Tahoe Networks + EMail: francis@tahoenetworks.com + + Bob Hinden, Nokia + EMail: hinden@iprg.nokia.com + + Christian Huitema, Microsoft + EMail: huitema@windows.microsoft.com + + Niall Richard Murphy, Hutchison 3G + EMail: niallm@enigma.ie + + Markku Savela, Technical Research Centre of Finland + Email: Markku.Savela@vtt.fi + + Jonne Soininen, Nokia + EMail: Jonne.Soininen@nokia.com + + Margaret Wasserman, Wind River + EMail: mrw@windriver.com + + Information was incorporated from a presentation co-authored by: + + Juan-Antonio Ibanez, Ericsson Eurolab + +Editor's Address + + Comments or questions regarding this document should be sent to: + + Margaret Wasserman + Wind River + 10 Tara Blvd., Suite 330 + Nashua, NH 03062 USA + + Phone: (603) 897-2067 + EMail: mrw@windriver.com + + + + + +Wasserman Informational [Page 22] + +RFC 3314 Recommendations for IPv6 in 3GPP Standards September 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Wasserman Informational [Page 23] + |