Network Working Group M. Wasserman, Ed.
Request for Comments: 3314 Wind River
Category: Informational September 2002
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
第三代合作伙伴计划（3GPP）标准中的IPv6建议
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.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文档包含互联网工程任务组（IETF）IPv6工作组向第三代合作伙伴项目（3GPP）社区提出的关于在3GPP标准中使用IPv6的建议。具体地说，本文档建议3GPP指定可将多个前缀分配给每个主PDP上下文，要求不得将给定前缀分配给多个主PDP上下文，并允许3GPP节点在这些前缀内使用多个标识符，包括随机生成的标识符。
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.
IPv6工作组支持在3GPP中使用IPv6，并本着IPv6工作组和3GPP社区之间开放合作的精神提供这些建议。自本文件最初作为互联网草案发布以来，3GPP采纳了本文件的主要建议。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[关键词]中的描述进行解释。
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............................................. 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
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.
2001年5月，IPv6工作组（WG）在华盛顿州雷德蒙举行了一次临时会议，讨论在3GPP标准中使用IPv6的问题。会议的第一天是与3GPP的联合讨论，会上介绍了3GPP使用IPv6的架构概述，并就3GPP中IPv6使用的特定方面进行了大量讨论。在那次会议上，决定成立一个设计团队，编写一份文件，就IPv6的使用向3GPP社区提供IPv6工作组的建议。本文件就是这一努力的结果。
This document offers recommendations to the 3GPP community from the IETF IPv6 Working Group. It is organized into three main sections:
本文档向3GPP社区提供IETF IPv6工作组的建议。它分为三个主要部分：
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.
1. 介绍（本节），提供有关IETF IPv6 WG和3GPP的背景信息，并包括本文档中讨论的技术的高级概述。
2. Recommendations from the IPv6 WG to the 3GPP community. These can be found in section 2.
2. IPv6工作组向3GPP社区提出的建议。这些可在第2节中找到。
3. Further work items that should be considered by the IPv6 WG. These items are discussed in section 3.
3. IPv6工作组应考虑的进一步工作项目。这些项目将在第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.
本文档旨在向3GPP社区提供IPv6工作组的建议。我们已将本文档的内容限制在与3GPP中IPv6的使用直接相关的项目上。本文档未定义任何标准，也不是有关IPv6或3GPP的最终信息来源。我们没有选择与其他IETF协议（即SIP、IPv4等）探讨3GPP相关的问题，因为它们不在IPv6工作组的范围内。
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.
IPv6工作组完全支持在3GPP中使用IPv6，我们鼓励3GPP实施者和运营商参与IETF过程。我们本着IPv6工作组和3GPP社区之间开放合作的精神提供这些建议，我们希望我们正在进行的合作将有助于加强这两套标准。
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].
本文档中的3GPP地址分配信息基于3GPP文档TS 23.060版本4.1.0[旧版TS23060]。在2002年3月的3GPP全体会议TSG#15上，3GPP采纳了本文件中包含的两项主要建议，即在使用IPv6无状态地址自动配置时为每个主要PDP上下文分配唯一前缀，并允许终端使用多个接口标识符。这些更改从3GPP release 99起追溯应用于TS23.060版本3.11.0、4.4.0和5.1.0[新TS23060]。
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.
第三代合作伙伴关系项目（3GPP）是1998年底成立的全球标准化合作伙伴关系。其组织合作伙伴已同意合作，为基于演进的GSM核心网络的第三代移动系统制定技术规范。
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.
3GPP组织合作伙伴包括几个不同的标准化组织：欧洲的ETSI、美国的T1电信标准委员会（T1）、中国无线电信标准集团（CWTS）、韩国电信技术协会（TTA）、无线电工业和商业协会（ARIB），以及日本电信技术委员会。
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.
工程由项目协调小组（PCG）协调，并分为技术规范小组（TSG）。共有五个TSG：核心网（TSG CN）、无线接入网（TSG RAN）、服务和系统方面（TSG SA）、GSM/EDGE无线接入网（GERAN）和终端（TSG T）。TSG进一步分为工作组（WG）。技术工作由工作组完成，随后在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].
3GPP工作方法不同于IETF工作方法。主要区别在于大部分工作是在哪里完成的。在3GPP中，工作是在面对面的会议上完成的，邮件列表主要用于分发稿件，以及处理会议上由于时间不足而未处理的文档。决策通常是以协商一致方式作出的，尽管投票是存在的。然而，投票是相当罕见的。3GPP文档是公开的，可以通过3GPP网站[3GPP-URL]访问。
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].
互联网工程任务组（IETF）是一个由网络设计师、运营商、供应商和研究人员组成的大型、开放的国际社区，关注互联网体系结构的演变和互联网的顺利运行。IETF也是制定互联网协议和标准的主要标准机构。它对任何感兴趣的个人开放。有关IETF的更多信息，请访问IETF网站[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.
IETF的实际技术工作是在工作组中完成的，按主题分为几个领域（如路由、运输、安全等）。IPv6工作组在IETF的互联网区域内成立。大部分工作通过邮件列表处理，IETF每年举行三次会议。
This section defines the 3GPP and IETF terminology used in this document. The 3GPP terms and their meanings have been taken from [TR21905].
本节定义了本文档中使用的3GPP和IETF术语。3GPP术语及其含义取自[TR21905]。
APN Access Point Name. The APN is a logical name referring to a GGSN and an external network.
APN接入点名称。APN是指GGSN和外部网络的逻辑名称。
CS Circuit Switched
电路交换
GERAN GSM/EDGE Radio Access Network
GERAN GSM/EDGE无线接入网
GGSN Gateway GPRS Support Node. A router between the GPRS network and an external network (i.e., the Internet).
GGSN网关GPRS支持节点。GPRS网络和外部网络（即Internet）之间的路由器。
GPRS General Packet Radio Services
通用分组无线业务
GTP-U General Tunneling Protocol - User Plane
GTP-U通用隧道协议-用户平面
MT Mobile Termination. For example, a mobile phone handset.
移动终端。例如，一部手机。
PDP Packet Data Protocol
分组数据协议
PDP Context A PDP connection between the UE and the GGSN.
PDP上下文UE和GGSN之间的PDP连接。
PS Packet Switched
分组交换
SGSN Serving GPRS Support Node
服务于GPRS支持节点的SGSN
TE Terminal Equipment. For example, a laptop attached through a 3GPP handset.
终端设备。例如，通过3GPP手机连接的笔记本电脑。
UE User Equipment (TE + MT + USIM). An example would be a mobile handset with a USIM card inserted and a laptop attached.
UE用户设备（TE+MT+USIM）。例如，插入USIM卡并连接笔记本电脑的手机。
UMTS Universal Mobile Telecommunications System
UMTS通用移动通信系统
USIM Universal Subscriber Identity Module. Typically, a card that is inserted into a mobile phone handset.
USIM通用用户识别模块。通常，插入移动电话的卡。
UTRAN Universal Terrestrial Radio Access Network
通用地面无线电接入网
IPv6 Internet Protocol version 6 [RFC 2460]
IPv6互联网协议第6版[RFC 2460]
NAS Network Access Server
NAS网络访问服务器
NAT Network Address Translator
NAT网络地址转换器
NAT-PT Network Address Translation with Protocol Translation. An IPv6 transition mechanism. [NAT-PT]
NAT-PT网络地址转换和协议转换。IPv6转换机制。[NAT-PT]
PPP Point-to-Point Protocol [PPP]
点对点协议
SIIT Stateless IP/ICMP Transition Mechanism [SIIT]
SIIT无状态IP/ICMP转换机制[SIIT]
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.
本文档中的建议主要与IPv6地址分配有关。要完全理解建议的更改，有必要了解IPv6寻址体系结构和当前的IPv6地址分配机制。
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.
IPv6寻址体系结构代表了IPv4寻址[ADDRARCH]的重大演变。要求所有IPv6节点能够根据接口标识符和前缀信息组合自己的地址。这种机制称为IPv6主机自动配置[AUTOCONF]，它允许IPv6节点在不需要有状态配置服务器（即DHCPv6）或静态配置地址的情况下自行配置。
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].
接口标识符可以是全局唯一的，如修改的EUI-64地址[ADDRARCH]，也可以是非唯一的，如随机生成的标识符。具有全局唯一标识符的主机也可以出于隐私[PRIVADDR]或其他原因选择使用随机生成的地址。IPv6主机可以随时生成新标识符，重复地址检测（DAD）用于防止在单个链路上使用重复标识符[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路由器可能会公布附加前缀（站点本地和/或全局前缀）[IPV6ND]。主机可以将播发的前缀与自己的接口标识符结合起来，为站点本地和全局通信创建地址。
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引入了对作用域单播寻址[SCOPARCH]的体系结构支持。单个接口通常具有多个地址，用于在不同范围内进行通信：链接本地、站点本地和/或全局[ADDRARCH]。链路本地地址允许本地通信，即使IPv6路由器不存在。某些IPv6协议（即路由协议）需要使用链路本地地址。站点本地寻址允许通信以管理方式包含在单个站点中。链接本地或站点本地连接也可能在更改全局前缀信息（例如，站点重新编号）后仍然有效。
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将每个地址与一个接口显式关联。多个接口主机可能在多个链路或多个站点上具有接口。链接和站点使用区域标识符进行内部标识。IPv6作用域寻址体系结构[SCOPARCH]确保了非全局通信的正确路由和正确的地址选择。
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.
IPv6引入了隐私地址的概念[PRIVADDR]。这些地址由公布的全局前缀和随机生成的标识符生成，用于匿名访问Internet服务。应用程序控制隐私地址的生成，并且可以随时生成新地址。
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.
IPv6站点重新编号规范[SITEREN]依赖于这样一个事实，即当在链路上播发新前缀时，IPv6节点将生成新地址，并且它们将拒绝使用不推荐的前缀的地址。
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.
将来，附加的IPv6规范可能依赖于IPv6节点使用多个前缀和/或多个标识符动态创建新地址的能力。
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.
3GPP规范定义了第三代移动系统。3GPP版本99系统的分组交换（PS）域的概述在以下部分中描述。作者希望，对于不熟悉UMTS分组交换服务的读者来说，这一描述足以理解UMTS系统是如何工作的，以及目前如何定义IPv6在其中使用。
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).
UMTS体系结构可分为两个主要领域——分组交换（PS）领域和电路交换（CS）领域。在本文档中，我们将重点介绍PS域或通用分组无线业务（GPRS）。
------
| TE |
------
|
+R
|
------ Uu ----------- Iu ----------- Gn ----------- Gi
| MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+--
------ ----------- ----------- -----------
(UE)
------
| TE |
------
|
+R
|
------ Uu ----------- Iu ----------- Gn ----------- Gi
| MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+--
------ ----------- ----------- -----------
(UE)
Figure 1: Simplified GPRS Architecture
图1：简化的GPRS架构
------
| |
| 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 |
------ ------------- ------------- -------------
------
| |
| 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)
UE UTRAN SGSN GGSN（手机）
Figure 2: GPRS Protocol Stacks
图2:GPRS协议栈
------
| |
| 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)
------
| |
| 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
图3：连接到3GPP手机的笔记本电脑
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.
如图1和图2所示，GPRS核心网络元素是用户设备（UE）、服务GPRS支持节点（SGSN）和网关GPRS支持节点（GGSN）。UTRAN包括无线接入网络控制器（RNC）和UTRAN基站。
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).
GGSN：一种专用路由器，用作GPRS网络和外部网络（如Internet）之间的网关。它还收集有关连接的收费信息。在许多方面，GGSN类似于网络访问服务器（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.
SGSN：SGSN的主要功能包括身份验证、授权、移动性管理和计费信息收集。SGSN连接到SS7网络，并通过该网络连接到归属位置寄存器（HLR），以便它可以执行用户配置文件处理、身份验证和授权。
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).
GTP-U：在UDP/IP上运行的简单隧道协议，用于在同一UMTS主干内或不同UMTS主干之间的RNC、SGSN和GGSN之间路由数据包。GTP-U隧道在每一端由隧道端点标识符（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].
本文档仅讨论GPRS系统最重要的部分。有关GPRS系统的更多信息，请参见[OLD-TS23060]。
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.
在此上下文中最重要的3GPP概念是PDP上下文。PDP上下文是UE和GGSN之间的连接，在其上传输分组。有两种PDP上下文——主上下文和辅助上下文。
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.
主PDP上下文最初定义到GGSN的链接。例如，为每个主PDP上下文分配一个IP地址。此外，可以将一个或多个辅助PDP上下文添加到主PDP上下文，共享相同的IP地址。这些次要PDP上下文可以具有与主要PDP上下文不同的服务质量特征。
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.
在IETF术语中，主PDP上下文和零个或多个辅助PDP上下文共同定义了链路。GPRS连接是点对点的。一旦激活，所有PDP上下文都具有相同的状态，这意味着可以删除主PDP上下文，同时保持UE和GGSN之间的链路，只要存在针对相同IP地址的其他（辅助）PDP上下文。
There are currently three PDP Types supported in GPRS -- IPv4, IPv6, and PPP. This document will only discuss the IPv6 PDP Type.
目前GPRS支持三种PDP类型：IPv4、IPv6和PPP。本文档仅讨论IPv6 PDP类型。
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.
可以在PDP上下文上执行三个基本操作：PDP上下文激活、修改和停用。下面将介绍这些操作。
Activate PDP Context
激活PDP上下文
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.
向GGSN打开新的PDP上下文。如果激活了新的主PDP上下文，则在UE和GGSN之间创建了新链路。UE可以向一个或多个ggsn打开多个主PDP上下文。
Modify PDP Context
修改PDP上下文
Changes the characteristics of a PDP Context, for example QoS attributes.
更改PDP上下文的特征，例如QoS属性。
Deactivate PDP Context
停用PDP上下文
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.
停用PDP上下文。如果主PDP上下文和与之相关联的所有辅助PDP上下文被停用，则UE和GGSN之间的链路被移除。
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).
APN是逻辑上链接到GGSN的名称。APN可以识别服务或外部网络。APN的语法对应于完全限定的域名。在PDP上下文激活时，SGSN执行DNS查询以找出为终端请求的APN服务的GGSN。DNS响应包含一个GGSN地址列表，SGSN从中选择一个（以循环方式）。
--------- --------
| | | 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 ========- |
| | | | | |
| | | | | |
-------- --------- --------
--------- --------
| | | 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
图3:PDP上下文与IPv6链路的对应关系
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.
GPRS支持静态和动态地址分配。支持两种类型的动态地址分配——无状态和有状态。有状态地址配置使用外部协议连接到提供IP地址的服务器，例如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].
无状态IPv6自动配置在GPRS中的工作方式与在以太网中的工作方式不同。GPRS节点没有唯一标识符，而以太网节点可以从其EUI-48地址创建标识符。由于GPRS网络类似于拨号网络，GPRS中的无状态地址自动配置基于PPPv6[PPPv6]。
3GPP address autoconfiguration has the following steps:
3GPP地址自动配置具有以下步骤：
1. The Activate PDP Context message is sent to the SGSN (PDP Type=IPv6, PDP Address = 0, etc.).
1. 激活PDP上下文消息被发送到SGSN（PDP类型=IPv6，PDP地址=0等）。
2. The SGSN sends a Create PDP Context message to the GGSN with the above parameters.
2. SGSN使用上述参数向GGSN发送创建PDP上下文消息。
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).
3. GGSN为PDP上下文选择接口标识符并创建链路本地地址。它通过创建PDP上下文响应（PDP地址=链路本地地址）回答SGSN。
4. The SGSN sends an Activate PDP Context accept message to the UE (PDP Address = link-local address).
4. SGSN向UE发送激活PDP上下文接受消息（PDP地址＝链路本地地址）。
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).
5. UE保留链路本地地址，并提取接口标识符以供以后使用。UE可以向GGSN（第一跳路由器）发送路由器请求消息。
6. After the PDP Context Activation, the GGSN sends a Router Advertisement to the UE.
6. 在PDP上下文激活之后，GGSN向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.
7. UE应被配置为不发送邻居请求消息。但是，如果发送了一个，GGSN将默默地丢弃它。
8. The GGSN updates the SGSN with the whole IPv6 address.
8. GGSN使用整个IPv6地址更新SGSN。
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.
每个连接的手持设备或笔记本电脑将为互联网上的通信创建一个主要PDP上下文。手持设备可在其与GGSN的连接的整个生命周期中创建许多主要和/或次要PDP上下文。
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
在3GPP内，GGSN向每个主PDP上下文分配单个64位标识符。GGSN还向手机播发一个/64前缀，这两个项目组合成一个IPv6地址。随后，GGSN修改SGSN中的PDP上下文条目以包括整个IPv6地址，以便SGSN可以知道每个3GPP节点的单个地址（例如，用于计费目的）。该地址还用于GGSN中，以标识与每个数据包相关联的PDP上下文。假设3GPP节点不会
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.
生成除GGSN分配的单个标识符/前缀组合之外的任何地址。不执行DAD，因为GGSN不会将同一地址分配给多个节点。
2 Recommendations to the 3GPP
2对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:
本着生产性合作的精神，IPv6工作组建议3GPP考虑在GPRS内使用IPv6的三个变化。具体而言，我们建议3GPP：
1. Specify that multiple prefixes may be assigned to each primary PDP context,
1. 指定可以为每个主PDP上下文分配多个前缀，
2. Require that a given prefix must not be assigned to more than one primary PDP context, and
2. 要求不得将给定前缀分配给多个主PDP上下文，以及
3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
3. 允许3GPP节点在这些前缀中使用多个标识符，包括随机生成的标识符。
Making these changes would provide several advantages for 3GPP implementers and users:
进行这些更改将为3GPP实施者和用户提供几个优势：
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.
连接到3GPP手机的笔记本电脑将在无需任何软件更改的情况下工作。他们对标准IPv6 over PPP、地址分配和自动配置机制的实现将不会进行任何修改。这将消除供应商和运营商构建和测试特殊3GPP驱动程序和相关软件的需要。正如目前所规定的，3GPP标准将与出于隐私或其他目的而生成自己的标识符的笔记本电脑实现不兼容。
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.
IPv6软件实现可以在3GPP手机中使用，而无需对IPv6协议机制进行任何修改。这将使3GPP手机的构建和测试更加容易。
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.)
3GPP手机中的应用程序将能够利用不同类型的IPv6地址（例如，静态地址、隐私临时地址、仅用于站点通信的站点范围地址等）
The GPRS system will be better positioned to take advantage of new IPv6 features that are built around the current addressing architecture.
GPRS系统将更好地利用围绕当前寻址体系结构构建的新IPv6功能。
The current 3GPP address assignment mechanism has the following limitations:
当前3GPP地址分配机制具有以下限制：
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.
GGSN仅播发单个/64前缀，而不是一组前缀。这将阻止3GPP节点（例如，手机或3GPP连接的笔记本电脑）参与IPv6站点重新编号，或参与期望IPv6主机基于多个播发前缀创建地址的其他机制。
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.
3GPP节点被分配了单个标识符，并且不允许生成附加标识符。这将防止3GPP节点使用隐私地址。这也使得3GPP机制与IPv6节点的预期行为不完全兼容，这将导致与流行的笔记本电脑IPv6协议栈不兼容。例如，使用隐私地址进行web浏览器连接的笔记本电脑当前无法通过3GPP链接建立web浏览器连接。
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.
通过在3GPP节点中启用标准IPv6地址分配机制，可以避免这些限制。GGSN可以在标准IPv6路由器广告中为本地链路发布一个或多个前缀，并且可以根据需要通过手持设备或笔记本电脑上的IPv6堆栈组装IPv6地址。接口标识符仍然可以由GGSN分配，如3GPP标准中当前规定的那样。然而，出于隐私或其他原因，手机或笔记本电脑可能会生成额外的标识符。
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:
为了符合当前和未来的IPv6标准，IPv6工作组建议3GPP允许为每个主PDP上下文播发多个前缀。这将有几个好处，包括：
3GPP nodes could participate in site renumbering and future IPv6 mechanisms that rely on the use of multiple global prefixes on a single link.
3GPP节点可以参与站点重新编号和未来的IPv6机制，这些机制依赖于在单个链路上使用多个全局前缀。
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).
如果需要，可以在3GPP链路上公布站点本地前缀，从而允许站点受限的通信，该通信可以在全局前缀信息更改（例如，站点重新编号）后继续存在。
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.
IPv6工作组建议3GPP将主PDP上下文及其辅助PDP上下文视为单个IPv6链路，并且GGSN将每个主PDP上下文视为单个子网。因此，给定的全局（或站点本地）前缀不应分配给多个PDP上下文。
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.
由于多个IPv6主机可以通过3GPP手持设备连接，IPv6工作组建议为每个主PDP上下文分配一个或多个/64前缀。这将允许3GPP连接的节点有足够的地址空间来分配隐私地址和/或路由到多链路子网[MULTLINK]，并将阻止在3GPP连接的设备中使用NAT。
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.
如果运营商为每个PDP上下文分配a/64，我们是否可以确保有足够的地址空间供数百万移动设备使用？这个问题可以通过使用主机密度（HD）比率来提高地址分配效率[HD]得到肯定的答案。考虑到各种地址分配过程导致的使用效率低下，这是一种实际且容易分配给主机的地址数量的度量。HD比率是根据实际电话号码和数据网络地址分配情况经验得出的。
We can calculate the number of easily assignable /64's making the following assumptions:
我们可以通过以下假设计算易于分配的/64的数量：
An HD ratio of 0.8 (representing the efficiency that can be achieved with no particular difficulty).
HD比率为0.8（表示无需特别困难即可实现的效率）。
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.
仅使用具有3位前缀001（RFC 2373定义的可聚合全局单播地址）的地址，从而产生61位的可分配地址空间。
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.
使用这些假设，总共可以分配490万亿（490x10^12）/64个前缀。这意味着今天地球上每人大约有80000个PDP上下文。即使假设这些IPv6/64前缀中的大多数将由非3GPP网络使用，显然仍然有足够数量的/64前缀。
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.
有鉴于此，可以安全地得出结论，如果将/64前缀分配给主PDP上下文，IPv6地址空间将不会耗尽。
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].
有关IPv6地址分配策略的更多信息，请参阅IAB/IESG关于地址分配[IABAA]的建议以及APNIC、ARIN和RIME地址分配策略[AAPOL]。
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.
目前，3GPP标准仅允许每个PDP上下文使用一个前缀和一个标识符。因此，GGSN可以向SGSN发送单个IPv6地址，用于计费等目的。
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.
IPv6工作组建议将当前分配给PDP上下文的每个前缀通知SGSN，而不是使用完整的IPv6地址来标识PDP上下文。通过仅将前缀分配给一个主PDP上下文，SGSN可以将前缀列表与每个PDP上下文相关联。
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.
IPv6工作组还建议修改3GPP标准，以允许在每个分配的前缀中使用多个标识符，包括随机生成的标识符。这将允许3GPP节点生成和使用隐私地址，并且将与未来的IPv6标准兼容，该标准可能取决于IPv6节点生成用于通信的新接口标识符的能力。
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.
这是一个至关重要的变化，需要允许符合标准的IPv6节点通过3GPP手机连接到互联网，而无需修改。预计大多数IPv6节点（包括最流行的笔记本电脑堆栈）将生成隐私地址。当前3GPP规范将与这些实现不兼容。
3 Additional IPv6 Work Items
3其他IPv6工作项
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.
在编写本文档的过程中，我们发现了几个可以从IPv6工作组的进一步信息或标准跟踪工作中获益的领域。
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].
IPv6工作组应致力于定义点到点体系结构，并指定标准IPv6地址分配机制如何适用于点到点链路上的IPv6。我们还应审查并澄清IPv6 over PPP规范[PPP]，以匹配当前的IPv6寻址体系结构[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.
IPv6 WG应该考虑发布一个“IPv6 over PDP上下文”（或类似的）文档。本文档将有助于开发人员编写IPv6堆栈的驱动程序，以便在3GPP PDP上下文中工作。
The IPv6 working group should undertake an effort to define the minimal requirements for all IPv6 nodes.
IPv6工作组应努力定义所有IPv6节点的最低要求。
4 Security Considerations
4安全考虑
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.
本文档包含关于在3GPP标准中使用IPv6协议的建议。它没有指定协议，也没有引入新的安全注意事项。
Appendix A: Analysis of Findings
附录A：调查结果分析
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.
本节包括一些分析，这些分析可能有助于理解IPv6工作组提出上述建议的原因。它还包括探讨的一些其他选择，以及为什么这些选择不如上述建议合适的原因。
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.
为了允许每个具有不同接口标识符的主PDP上下文配置和使用多个IPv6地址，需要对当前3GPP规范进行一些修改。
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
- 无线频谱的稀缺性和高成本-实施和状态维护的复杂性-相关IETF标准的稳定性-对当前3GPP标准的影响
Two solutions to allow autoconfiguration of multiple addresses on the same primary PDP Context were considered:
考虑了两种允许在同一主PDP上下文上自动配置多个地址的解决方案：
1. Assign one or more entire prefixes (/64s) to a PDP Context upon PDP Context activation and allow the autoconfiguration of multiple addresses.
1. 在PDP上下文激活时，将一个或多个完整前缀（/64s）分配给PDP上下文，并允许自动配置多个地址。
a) The assignment may be performed by having the GGSN advertise one or more /64 prefixes to the mobile device.
a) 可以通过让GGSN向移动设备通告一个或多个/64前缀来执行分配。
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.
b) 可通过将“前缀委派”功能构建到PDP上下文消息中或通过使用诸如[PREFDEL]的第3层机制来执行分配。这样，前缀没有分配给GGSN和移动设备之间的链路（如1a中所示），而是分配给移动设备本身。请注意，[PREFDEL]不能被认为是稳定的，在这个阶段，IPv6工作组还没有将其作为工作组文件采用。
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
2. 在连接到同一GGSN（和APN）的多个PDP上下文之间共享同一前缀。鉴于移动设备可以使用一个以上的接口标识符生成多个地址，这将需要通过空中接口为新生成的地址提供DAD，以及代理DAD功能，这将增加复杂性和状态量
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].
保存在GGSN中。此外，GGSN还需要确定临时地址何时不再使用，这将很困难。一种可能的解决方案是对临时地址[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.
考虑到评估解决方案时的所有因素，建议使用解决方案1a。此解决方案对当前3GPP标准的修改最少，并保持了其他解决方案的所有优点。
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.
实际上，这意味着GGSN中的每个APN将具有一定数量的/64前缀，这些前缀可以通过路由器广告在PDP上下文激活时分发。因此，IPv6 WG建议GGSN使用整个前缀（连同其他3GPP特定信息）并将分配给PDP上下文的前缀通知SGSN，而不是使用完整IPv6地址来识别主PDP上下文。通过仅将给定前缀分配给一个主PDP上下文，GGSN和SGSN可以根据需要将前缀列表与每个PDP上下文相关联。
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.
请注意，推荐的解决方案并不暗示或假设移动设备是路由器。MT预计将为自己使用/64，也可能为连接到它的设备使用此前缀。但是，如果MT后面的每个设备都连接到单独的主PDP上下文，因此可以使用不与其他设备共享的a/64，则这是不必要的。MT还应在本地处理连接到它的设备（如笔记本电脑）的DAD，而无需通过空中向GGSN转发邻居请求。
References
工具书类
[OLD-TS23060] TS 23.060, "General Packet Radio Service (GPRS); Service description; Stage 2", V4.1.0
[OLD-TS23060]TS 23.060，“通用分组无线业务（GPRS）；业务描述；第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).
[NEW-TS23060]TS 23.060版本3.11.0（99版）、4.4.0（4版）和5.1.0（5版）。
[3GPP-URL] http://www.3gpp.org
[3GPP-URL] http://www.3gpp.org
[IETF-URL] http://www.ietf.org
[IETF-URL] http://www.ietf.org
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 21192999年3月。
[TR21905] 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0
[TR21905]3GPP TR 21.905，“3GPP规范词汇”，V5.0.0
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[NAT-PT] Tsirtsis, G. and P. Shrisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NAT-PT]Tsirtsis，G.和P.Shrsuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[SIIT] Nordmark, N., "Stateless IP/ICMP Translation Algorithm", RFC 2765, February 2000.
[SIIT]Nordmark，N.，“无状态IP/ICMP转换算法”，RFC 27652000年2月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDRARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[IPV6ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPV6ND]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998
[AUTOCONF]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 24621998年12月
[PRIVADDR] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[PRIVADDR]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[IPV6ETH] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPV6ETH]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[PPPv6]Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
[MULTLINK] C. Huitema, D. Thaler, "Multi-link Subnet Support in IPv6", Work in Progress.
[MULTLINK]C.Huitema，D.Thaler，“IPv6中的多链路子网支持”，正在进行中。
[SITEREN] C. Huitema, "IPv6 Site Renumbering", Work in Progress.
[SITEREN]C.Huitema，“IPv6站点重新编号”，工作正在进行中。
[HD] Durand, A. and C. Huitema, "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio", RFC 3194, November 2001.
[HD]Durand，A.和C.Huitema，“地址分配效率的主机密度比：H比率的更新”，RFC3194，2001年11月。
[IABAA] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[IABAA]IAB，IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[AAPOL] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment Global Policy", Work in Progress.
[AAPOL]APNIC、ARIN、RIME-NCC，“IPv6地址分配和分配全球策略”，工作正在进行中。
[SCOPARCH] S. Deering, et. al., "IPv6 Scoped Address Architecture", Work in Progress.
[SCOPARCH]S.Deering等人，“IPv6作用域地址体系结构”，正在进行中。
[CELLREQ] J. Arkko, et. al., "Minimum IPv6 Functionality for a Cellular Host", Work in Progress.
[CELLREQ]J.Arkko等人，“蜂窝主机的最低IPv6功能”，正在进行中。
[PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", Work in Progress.
[PREFDEL]J.Martin，B.Haberman，“互联网协议版本6（IPv6）的自动前缀委派协议”，正在进行中。
Authors and Acknowledgements
作者和致谢
This document was written by the IPv6 3GPP design team:
本文档由IPv6 3GPP设计团队编写：
Steve Deering, Cisco Systems EMail: deering@cisco.com
Steve Deering，思科系统电子邮件：deering@cisco.com
Karim El-Malki, Ericsson Radio Systems EMail: Karim.El-Malki@era.ericsson.se
Karim El Malki，爱立信无线电系统电子邮件：Karim.El-Malki@era.ericsson.se
Paul Francis, Tahoe Networks EMail: francis@tahoenetworks.com
Paul Francis，Tahoe Networks电子邮件：francis@tahoenetworks.com
Bob Hinden, Nokia EMail: hinden@iprg.nokia.com
Bob Hinden，诺基亚电子邮件：hinden@iprg.nokia.com
Christian Huitema, Microsoft EMail: huitema@windows.microsoft.com
Christian Huitema，Microsoft电子邮件：huitema@windows.microsoft.com
Niall Richard Murphy, Hutchison 3G EMail: niallm@enigma.ie
尼尔·理查德·墨菲，和记黄埔3G电子邮件：niallm@enigma.ie
Markku Savela, Technical Research Centre of Finland Email: Markku.Savela@vtt.fi
Markku Savela，芬兰技术研究中心电子邮件：Markku。Savela@vtt.fi
Jonne Soininen, Nokia EMail: Jonne.Soininen@nokia.com
Jonne Soininen，诺基亚电子邮件：Jonne。Soininen@nokia.com
Margaret Wasserman, Wind River EMail: mrw@windriver.com
Margaret Wasserman，Wind River电子邮件：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
Margaret Wasserman Wind River美国新罕布什尔州纳舒亚塔拉大道10号330室，邮编03062
Phone: (603) 897-2067 EMail: mrw@windriver.com
电话：（603）897-2067电子邮件：mrw@windriver.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。