Network Working Group J. Wiljakka, Ed.
Request for Comments: 4215 Nokia
Category: Informational October 2005
Network Working Group J. Wiljakka, Ed.
Request for Comments: 4215 Nokia
Category: Informational October 2005
Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
第三代合作伙伴计划（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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
本文分析了第三代合作伙伴计划（3GPP）分组网络向IPv6的过渡。这些网络基于通用分组无线业务（GPRS）技术，无线网络体系结构基于全球移动通信系统（GSM）或通用移动通信系统（UMTS）/宽带码分多址（WCDMA）技术。
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.
重点是分析不同的过渡场景和适用的过渡机制，并为这些过渡场景找到解决方案。在这些场景中，用户设备（UE）连接到其他节点，例如在因特网中，并且需要IPv6/IPv4转换机制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
1.2. Abbreviations ..............................................3
1.3. Terminology ................................................5
2. Transition Mechanisms and DNS Guidelines ........................5
2.1. Dual Stack .................................................5
2.2. Tunneling ..................................................6
2.3. Protocol Translators .......................................6
2.4. DNS Guidelines for IPv4/IPv6 Transition ....................6
3. GPRS Transition Scenarios .......................................7
3.1. Dual Stack UE Connecting to IPv4 and IPv6 Nodes ............7
3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4
Network ....................................................8
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
1.2. Abbreviations ..............................................3
1.3. Terminology ................................................5
2. Transition Mechanisms and DNS Guidelines ........................5
2.1. Dual Stack .................................................5
2.2. Tunneling ..................................................6
2.3. Protocol Translators .......................................6
2.4. DNS Guidelines for IPv4/IPv6 Transition ....................6
3. GPRS Transition Scenarios .......................................7
3.1. Dual Stack UE Connecting to IPv4 and IPv6 Nodes ............7
3.2. IPv6 UE Connecting to an IPv6 Node through an IPv4
Network ....................................................8
3.2.1. Tunneling Inside the 3GPP Operator's Network ........9
3.2.2. Tunneling Outside the 3GPP Operator's Network ......10
3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6
Network ...................................................10
3.4. IPv6 UE Connecting to an IPv4 Node ........................11
3.5. IPv4 UE Connecting to an IPv6 Node ........................12
4. IMS Transition Scenarios .......................................12
4.1. UE Connecting to a Node in an IPv4 Network through IMS ....12
4.2. Two IPv6 IMS Connected via an IPv4 Network ................15
5. About 3GPP UE IPv4/IPv6 Configuration ..........................15
6. Summary and Recommendations ....................................16
7. Security Considerations ........................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
9. Contributors ...................................................20
10. Authors and Acknowledgements ..................................20
3.2.1. Tunneling Inside the 3GPP Operator's Network ........9
3.2.2. Tunneling Outside the 3GPP Operator's Network ......10
3.3. IPv4 UE Connecting to an IPv4 Node through an IPv6
Network ...................................................10
3.4. IPv6 UE Connecting to an IPv4 Node ........................11
3.5. IPv4 UE Connecting to an IPv6 Node ........................12
4. IMS Transition Scenarios .......................................12
4.1. UE Connecting to a Node in an IPv4 Network through IMS ....12
4.2. Two IPv6 IMS Connected via an IPv4 Network ................15
5. About 3GPP UE IPv4/IPv6 Configuration ..........................15
6. Summary and Recommendations ....................................16
7. Security Considerations ........................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
9. Contributors ...................................................20
10. Authors and Acknowledgements ..................................20
This document describes and analyzes the process of transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks [3GPP-23.060], in which the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
本文件描述并分析了第三代合作伙伴项目（3GPP）通用分组无线业务（GPRS）分组网络[3GPP-23.060]向IPv6过渡的过程，其中无线网络架构基于全球移动通信系统（GSM）或通用移动通信系统（UMTS）/宽带码分多址（WCDMA）技术。
This document analyzes the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet data networks.
本文档分析了在3GPP分组数据网络中部署IPv6时可能出现的过渡场景。
The 3GPP network architecture is described in [RFC3314], and relevant transition scenarios are documented in [RFC3574]. The reader of this specification should be familiar with the material presented in these documents.
[RFC3314]中描述了3GPP网络架构，相关过渡场景记录在[RFC3574]中。本规范的读者应熟悉这些文件中提供的材料。
The scenarios analyzed in this document are divided into two categories: general-purpose packet service scenarios, referred to as GPRS scenarios in this document, and IP Multimedia Subsystem (IMS) scenarios, which include Session Initiation Protocol (SIP) considerations. For more information about IMS, see [3GPP-23.228], [3GPP-24.228], and [3GPP-24.229].
本文档中分析的场景分为两类：通用分组服务场景（在本文档中称为GPRS场景）和IP多媒体子系统（IMS）场景，其中包括会话启动协议（SIP）注意事项。有关IMS的更多信息，请参阅[3GPP-23.228]、[3GPP-24.228]和[3GPP-24.229]。
GPRS scenarios are the following:
GPRS场景如下：
- Dual Stack User Equipment (UE) connecting to IPv4 and IPv6 nodes - IPv6 UE connecting to an IPv6 node through an IPv4 network - IPv4 UE connecting to an IPv4 node through an IPv6 network - IPv6 UE connecting to an IPv4 node
- 连接到IPv4和IPv6节点的双堆栈用户设备（UE）-通过IPv4网络连接到IPv6节点的IPv6 UE-通过IPv6网络连接到IPv4节点的IPv4 UE-连接到IPv4节点的IPv6 UE
- IPv4 UE connecting to an IPv6 node
- 连接到IPv6节点的IPv4 UE
IMS scenarios are the following:
国际监测系统的情况如下：
- UE connecting to a node in an IPv4 network through IMS - Two IPv6 IMS connected via an IPv4 network
- UE通过IMS连接到IPv4网络中的节点-两个通过IPv4网络连接的IPv6 IMS
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In the scenarios, the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.
重点是分析不同的过渡场景和适用的过渡机制，并为这些过渡场景找到解决方案。在这些场景中，用户设备（UE）连接到其他网络（例如互联网）中的节点，并且需要IPv6/IPv4转换机制。
The scope of this document is to analyze the possible transition scenarios in the 3GPP-defined GPRS network in which a UE connects to, or is contacted from, another node on the Internet. This document covers scenarios with and without the use of the SIP-based IP Multimedia Core Network Subsystem (IMS). This document does not focus on radio-interface-specific issues; both 3GPP Second and Third Generation radio network architectures (GSM, Enhanced Data rates for GSM Evolution (EDGE) and UMTS/WCDMA) will be covered by this analysis.
本文档的范围是分析3GPP定义的GPRS网络中可能的过渡场景，其中UE连接到互联网上的另一个节点，或者从另一个节点联系。本文档涵盖了使用和不使用基于SIP的IP多媒体核心网络子系统（IMS）的场景。本文件不关注无线电接口的具体问题；本分析将涵盖3GPP第二代和第三代无线网络架构（GSM、GSM演进增强数据速率（EDGE）和UMTS/WCDMA）。
The 3GPP2 architecture is similar to 3GPP in many ways, but differs in enough details that this document does not include these variations in its analysis.
3GPP2架构在许多方面与3GPP类似，但在足够的细节上有所不同，因此本文档在其分析中不包括这些变化。
The transition mechanisms specified by the IETF Ngtrans and v6ops Working Groups shall be used. This memo shall not specify any new transition mechanisms, but only documents the need for new ones (if appropriate).
应使用IETF Ngtrans和v6ops工作组规定的过渡机制。本备忘录不应规定任何新的过渡机制，而应仅记录对新机制的需求（如适用）。
2G Second Generation Mobile Telecommunications, e.g., GSM and GPRS technologies
2G第二代移动通信，例如GSM和GPRS技术
3G Third Generation Mobile Telecommunications, e.g., UMTS technology
3G第三代移动通信，例如UMTS技术
3GPP Third Generation Partnership Project
3GPP第三代合作伙伴项目
ALG Application Level Gateway
应用级网关
APN Access Point Name. The APN is a logical name referring to a GGSN and an external network.
APN接入点名称。APN是指GGSN和外部网络的逻辑名称。
B2BUA Back-to-Back User Agent
B2BUA背对背用户代理
CSCF Call Session Control Function (in 3GPP Release 5 IMS)
CSCF呼叫会话控制功能（在3GPP第5版IMS中）
DNS Domain Name System
域名系统
EDGE Enhanced Data rates for GSM Evolution
用于GSM演进的边缘增强数据速率
GGSN Gateway GPRS Support Node (default router for 3GPP User Equipment)
GGSN网关GPRS支持节点（3GPP用户设备的默认路由器）
GPRS General Packet Radio Service
通用分组无线业务
GSM Global System for Mobile Communications
GSM全球移动通信系统
HLR Home Location Register
主位置寄存器
IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 IPv6-only part of the network
IMS IP多媒体（核心网络）子系统，3GPP第5版IPv6仅为网络的一部分
ISP Internet Service Provider
因特网服务提供商
NAT Network Address Translation
NAT网络地址转换
NAPT-PT Network Address Port Translation - Protocol Translation
NAPT-PT网络地址端口转换-协议转换
NAT-PT Network Address Translation - Protocol Translation
NAT-PT网络地址转换-协议转换
PCO-IE Protocol Configuration Options Information Element
PCO-IE协议配置选项信息元素
PDP Packet Data Protocol
分组数据协议
PPP Point-to-Point Protocol
点对点协议
SDP Session Description Protocol
会话描述协议
SGSN Serving GPRS Support Node
服务于GPRS支持节点的SGSN
SIIT Stateless IP/ICMP Translation Algorithm
SIIT无状态IP/ICMP转换算法
SIP Session Initiation Protocol
SIP会话启动协议
UE User Equipment, e.g., a UMTS mobile handset
UE用户设备，例如UMTS移动手持设备
UMTS Universal Mobile Telecommunications System
UMTS通用移动通信系统
WCDMA Wideband Code Division Multiple Access
宽带码分多址
Some terms used in 3GPP transition scenarios and analysis documents are briefly defined here.
这里简要定义了3GPP过渡场景和分析文档中使用的一些术语。
Dual Stack UE Dual Stack UE is a 3GPP mobile handset having both IPv4 and IPv6 stacks. It is capable of activating both IPv4 and IPv6 Packet Data Protocol (PDP) contexts. Dual stack UE may be capable of tunneling.
双栈UE双栈UE是同时具有IPv4和IPv6栈的3GPP移动手持设备。它能够激活IPv4和IPv6数据包协议（PDP）上下文。双栈UE可以能够进行隧道传输。
IPv6 UE IPv6 UE is an IPv6-only 3GPP mobile handset. It is only capable of activating IPv6 PDP contexts.
IPv6 UE IPv6 UE是仅限IPv6的3GPP移动手机。它只能激活IPv6 PDP上下文。
IPv4 UE IPv4 UE is an IPv4-only 3GPP mobile handset. It is only capable of activating IPv4 PDP contexts.
IPv4 UE IPv4 UE是仅IPv4的3GPP移动手持设备。它只能激活IPv4 PDP上下文。
IPv4 node IPv4 node is here defined to be the IPv4-capable node the UE is communicating with. The IPv4 node can be, e.g., an application server or another UE.
IPv4节点IPv4节点在此定义为UE与之通信的支持IPv4的节点。IPv4节点可以是，例如，应用服务器或另一个UE。
IPv6 node IPv6 node is here defined to be the IPv6-capable node the UE is communicating with. The IPv6 node can be, e.g., an application server or another UE.
IPv6节点IPv6节点在此定义为UE与之通信的支持IPv6的节点。IPv6节点可以是，例如，应用服务器或另一UE。
PDP Context Packet Data Protocol (PDP) Context is a connection between the UE and the GGSN, over which the packets are transferred. There are currently three PDP types: IPv4, IPv6, and PPP.
PDP上下文分组数据协议（PDP）上下文是UE和GGSN之间的连接，分组在其上传输。目前有三种PDP类型：IPv4、IPv6和PPP。
This section briefly introduces these IETF IPv4/IPv6 transition mechanisms:
本节简要介绍这些IETF IPv4/IPv6转换机制：
- dual IPv4/IPv6 stack [RFC4213] - tunneling [RFC4213] - protocol translators [RFC2766], [RFC2765]
- 双IPv4/IPv6堆栈[RFC4213]-隧道[RFC4213]-协议转换器[RFC2766]，[RFC2765]
In addition, DNS recommendations are given. The applicability of different transition mechanisms to 3GPP networks is discussed in sections 3 and 4.
此外，还提出了DNS建议。第3节和第4节讨论了不同过渡机制对3GPP网络的适用性。
The dual IPv4/IPv6 stack is specified in [RFC4213]. If we consider the 3GPP GPRS core network, dual stack implementation in the Gateway GPRS Support Node (GGSN) enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack and public (global) IP addresses can
[RFC4213]中指定了双IPv4/IPv6堆栈。如果我们考虑3GPP GPRS核心网，网关GPRS支持节点（GGSN）中的双栈实现支持IPv4和IPv6 PDP上下文。具有双栈和公共（全局）IP地址的UE可以
typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that private IPv4 addresses and NATs [RFC2663] have been used and will be used in mobile networks. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address that is visible to other nodes.
通常访问IPv4和IPv6服务时，网络中不需要额外的转换器。然而，最好记住，私有IPv4地址和NAT[RFC2663]已经被使用，并且将在移动网络中使用。对等服务也需要公共/全局IP地址：节点需要其他节点可见的公共/全局IP地址。
Tunneling is a transition mechanism that requires dual IPv4/IPv6 stack functionality in the encapsulating and decapsulating nodes. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6.
隧道是一种转换机制，需要在封装和解封装节点中具有双IPv4/IPv6堆栈功能。基本的隧道选择是IPv4中的IPv6和IPv6中的IPv4。
Tunneling can be static or dynamic. Static (configured) tunnels are fixed IPv6 links over IPv4, and they are specified in [RFC4213]. Dynamic (automatic) tunnels are virtual IPv6 links over IPv4 where the tunnel endpoints are not configured, i.e., the links are created dynamically.
隧道可以是静态的，也可以是动态的。静态（配置）隧道是IPv4上的固定IPv6链路，它们在[RFC4213]中指定。动态（自动）隧道是IPv4上的虚拟IPv6链路，其中未配置隧道端点，即动态创建链路。
A translator can be defined as an intermediate component between a native IPv4 node and a native IPv6 node to enable direct communication between them without requiring any modifications to the end nodes.
转换器可以定义为本机IPv4节点和本机IPv6节点之间的中间组件，以实现它们之间的直接通信，而无需对终端节点进行任何修改。
Header conversion is a translation mechanism. In header conversion, IPv6 packet headers are converted to IPv4 packet headers, or vice versa, and checksums are adjusted or recalculated if necessary. NAT-PT (Network Address Translation/Protocol Translation) [RFC2766] using Stateless IP/ICMP Translation [RFC2765] is an example of such a mechanism.
标题转换是一种转换机制。在报头转换中，IPv6数据包报头转换为IPv4数据包报头，反之亦然，并在必要时调整或重新计算校验和。使用无状态IP/ICMP转换[RFC2765]的NAT-PT（网络地址转换/协议转换）[RFC2766]就是这种机制的一个例子。
Translators may be needed in some cases when the communicating nodes do not share the same IP version; in others, it may be possible to avoid such communication altogether. Translation can take place at the network layer (using NAT-like techniques), the transport layer (using a TCP/UDP proxy), or the application layer (using application relays).
在某些情况下，当通信节点不共享相同的IP版本时，可能需要翻译器；在其他情况下，可能完全避免这种交流。转换可以在网络层（使用类似NAT的技术）、传输层（使用TCP/UDP代理）或应用层（使用应用程序中继）进行。
To avoid the DNS name space from fragmenting into parts where some parts of DNS are visible only using IPv4 (or IPv6) transport, the recommendation (as of this writing) is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information.
为了避免DNS名称空间被分割成仅使用IPv4（或IPv6）传输才能看到DNS某些部分的部分，建议（在撰写本文时）始终至少启用一个权威服务器IPv4，并确保递归DNS服务器支持IPv4。有关更多信息，请参阅DNS IPv6传输指南[RFC3901]。
This section discusses the scenarios that might occur when a GPRS UE contacts services or other nodes, e.g., a web server in the Internet.
本节讨论GPRS UE联系服务或其他节点（例如，Internet中的web服务器）时可能出现的场景。
The following scenarios described by [RFC3574] are analyzed here. In all of the scenarios, the UE is part of a network where there is at least one router of the same IP version, i.e., the GGSN, and the UE is connecting to a node in a different network.
此处分析[RFC3574]描述的以下场景。在所有场景中，UE是网络的一部分，其中存在相同IP版本的至少一个路由器，即GGSN，并且UE连接到不同网络中的节点。
1) Dual Stack UE connecting to IPv4 and IPv6 nodes
1) 连接到IPv4和IPv6节点的双栈UE
2) IPv6 UE connecting to an IPv6 node through an IPv4 network
2) IPv6 UE通过IPv4网络连接到IPv6节点
3) IPv4 UE connecting to an IPv4 node through an IPv6 network
3) IPv4 UE通过IPv6网络连接到IPv4节点
4) IPv6 UE connecting to an IPv4 node
4) 连接到IPv4节点的IPv6 UE
5) IPv4 UE connecting to an IPv6 node
5) 连接到IPv6节点的IPv4 UE
In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes.
在此场景中，双栈UE能够与IPv4和IPv6节点通信。
It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. The authors leave the PDP context activation policy to be decided by UE implementers, application developers, and operators. One discussed possibility is to activate both IPv4 and IPv6 types of PDP contexts in advance, because activation of a PDP context usually takes some time. However, that probably is not good usage of network resources. Generally speaking, IPv6 PDP contexts should be preferred even if that meant IPv6-in-IPv4 tunneling would be needed in the network (see Section 3.2 for more details). Note that this is transparent to the UE.
建议在与IPv6对等节点通信时激活IPv6 PDP上下文，在与IPv4对等节点通信时激活IPv4 PDP上下文。如果3GPP网络同时支持IPv4和IPv6 PDP上下文，则UE根据其已启动的应用程序的类型或其需要与之通信的对等主机的地址激活适当的PDP上下文。作者将PDP上下文激活策略留给UE实现人员、应用程序开发人员和操作员来决定。讨论的一种可能性是提前激活IPv4和IPv6类型的PDP上下文，因为激活PDP上下文通常需要一些时间。然而，这可能并不能很好地利用网络资源。一般来说，应首选IPv6 PDP上下文，即使这意味着网络中需要IPv6-in-IPv4隧道（有关更多详细信息，请参阅第3.2节）。注意，这对UE是透明的。
Although the UE is dual stack, the UE may find itself attached to a 3GPP network in which the Serving GPRS Support Node (SGSN), the GGSN, and the Home Location Register (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP contexts. This may happen in early phases of IPv6 deployment, or because the UE has "roamed" from a 3GPP network that supports IPv6 to one that does not. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to
尽管UE是双栈的，但是UE可能发现自己连接到3GPP网络，其中服务GPRS支持节点（SGSN）、GGSN和归属位置寄存器（HLR）支持IPv4 PDP上下文，但不支持IPv6 PDP上下文。这可能发生在IPv6部署的早期阶段，或者因为UE已从支持IPv6的3GPP网络“漫游”到不支持IPv6的3GPP网络。如果3GPP网络不支持IPv6-PDP上下文，并且UE上的应用程序需要
communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism.
通过与IPv6（-only）节点通信，UE可以激活IPv4 PDP上下文，并使用隧道机制将IPv6分组封装在IPv4分组中。
The tunneling mechanism may require public IPv4 addresses, but there are tunneling mechanisms and deployment scenarios in which private IPv4 addresses may be used, for instance, if the tunnel endpoints are in the same private domain, or the tunneling mechanism works through IPv4 NAT.
隧道机制可能需要公共IPv4地址，但也有隧道机制和部署场景，其中可以使用私有IPv4地址，例如，如果隧道端点位于同一私有域中，或者隧道机制通过IPv4 NAT工作。
One deployment scenario uses a laptop computer and a 3GPP UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and an IPv4 PDP context is activated. The tunneling mechanism depends on the laptop computer's support of tunneling mechanisms. Another deployment scenario is performing IPv6-in-IPv4 tunneling in the UE itself and activating an IPv4 PDP context.
一种部署方案使用膝上型计算机和3GPP UE作为调制解调器。IPv6数据包封装在笔记本电脑中的IPv4数据包中，并激活IPv4 PDP上下文。隧道机制取决于笔记本电脑对隧道机制的支持。另一种部署场景是在UE本身中执行IPv6-in-IPv4隧道并激活IPv4-PDP上下文。
Closer details for an applicable tunneling mechanism are not analyzed in this document. However, a simple host-to-router (automatic) tunneling mechanism can be a good fit. There is not yet consensus on the right approach, and proposed mechanisms so far include [ISATAP] and [STEP]. Especially ISATAP has had some support in the working group. Goals for 3GPP zero-configuration tunneling are documented in [zeroconf].
本文件不分析适用隧道机制的详细信息。然而，一个简单的主机到路由器（自动）隧道机制可能是一个很好的选择。目前还没有就正确的方法达成共识，目前提议的机制包括[ISATAP]和[STEP]。特别是ISATAP在工作组中得到了一些支持。3GPP零配置隧道的目标记录在[zeroconf]中。
This document strongly recommends that the 3GPP operators deploy basic IPv6 support in their GPRS networks. That makes it possible to lessen the transition effects in the UEs.
本文档强烈建议3GPP运营商在其GPRS网络中部署基本的IPv6支持。这使得减少ue中的过渡效应成为可能。
As a general guideline, IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node.
作为一般指导原则，IPv6通信优先于通过IPv4 NAT到同一双堆栈对等节点的IPv4通信。
Public IPv4 addresses are often a scarce resource for the operator, and usually it is not possible for a UE to have a public IPv4 address (continuously) allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive, and difficult to maintain.
对于运营商来说，公共IPv4地址通常是稀缺资源，并且UE通常不可能（连续地）为其使用分配公共IPv4地址。使用专用IPv4地址意味着在与运营商网络外的对等节点通信时使用NAT。在大型网络中，NAT系统可能变得非常复杂、昂贵且难以维护。
The best solution for this scenario is obtained with tunneling; i.e., IPv6-in-IPv4 tunneling is a requirement. An IPv6 PDP context is activated between the UE and the GGSN. Tunneling is handled in the network, because IPv6 UE does not have the dual stack functionality needed for tunneling. The encapsulating node can be the GGSN, the edge router between the border of the operator's IPv6 network and the
这种情况下的最佳解决方案是使用隧道法；i、 例如，IPv6-in-IPv4隧道是一项要求。在UE和GGSN之间激活IPv6 PDP上下文。隧道在网络中处理，因为IPv6 UE不具备隧道所需的双堆栈功能。封装节点可以是GGSN，即运营商IPv6网络边界和网络之间的边缘路由器
public Internet, or any other dual stack node within the operator's IP network. The encapsulation (uplink) and decapsulation (downlink) can be handled by the same network element. Typically, the tunneling handled by the network elements is transparent to the UEs and IP traffic looks like native IPv6 traffic to them. For the applications and transport protocols, tunneling enables end-to-end IPv6 connectivity.
公共互联网或运营商IP网络内的任何其他双栈节点。封装（上行链路）和去封装（下行链路）可由同一网络元件处理。通常，网元处理的隧道对UE是透明的，IP流量对UE来说就像本地IPv6流量一样。对于应用程序和传输协议，隧道可以实现端到端IPv6连接。
IPv6-in-IPv4 tunnels between IPv6 islands can be either static or dynamic. The selection of the type of tunneling mechanism is a policy decision for the operator/ISP deployment scenario, and only generic recommendations can be given in this document.
IPv6孤岛之间的IPv6-in-IPv4隧道可以是静态的，也可以是动态的。隧道机制类型的选择是运营商/ISP部署场景的一项政策决策，本文档中只能给出一般建议。
The following subsections are focused on the usage of different tunneling mechanisms when the peer node is in the operator's network or outside the operator's network. The authors note that where the actual 3GPP network ends and which parts of the network belong to the ISP(s) also depend on the deployment scenario. The authors are not commenting on how many ISP functions the 3GPP operator should perform. However, many 3GPP operators are ISPs of some sort themselves. ISP networks' transition to IPv6 is analyzed in [RFC4029].
以下小节重点介绍对等节点位于运营商网络内或运营商网络外时不同隧道机制的使用。作者注意到，实际3GPP网络在哪里结束以及网络的哪些部分属于ISP也取决于部署场景。作者没有评论3GPP运营商应该执行多少ISP功能。然而，许多3GPP运营商本身就是某种ISP。[RFC4029]分析了ISP网络向IPv6的过渡。
GPRS operators today have typically deployed IPv4 backbone networks. IPv6 backbones can be considered quite rare in the first phases of the transition.
今天的GPRS运营商通常部署IPv4骨干网络。IPv6主干网在过渡的第一阶段可以被认为是非常罕见的。
In initial IPv6 deployment, where a small number of IPv6-in-IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island can contain the GGSN while another island can contain the operator's IPv6 application servers. However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. In that case, upgrading parts of the backbone to dual stack may be the simplest choice. The administrative burden could also be mitigated by using automated management tools.
在初始IPv6部署中，当需要少量IPv6-In-IPv4隧道通过3GPP运营商的IPv4网络连接IPv6孤岛时，可以使用手动配置的隧道。在3GPP网络中，一个IPv6岛可以包含GGSN，而另一个岛可以包含运营商的IPv6应用服务器。但是，当岛的数量增加时，手动配置的隧道可能会成为管理负担，因此隧道也会增加。在这种情况下，将主干部分升级到双堆栈可能是最简单的选择。使用自动化管理工具也可以减轻管理负担。
Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels alone do not provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they can provide an adequate solution depending on the design of the network and the presence of other router redundancy mechanisms, such as the use of IPv6 routing protocols.
连接冗余也是3GPP网络中的一项重要要求。静态隧道本身并不能为IPv6路由中断的所有场景提供路由恢复解决方案。然而，它们可以根据网络的设计和其他路由器冗余机制的存在（如IPv6路由协议的使用）提供适当的解决方案。
This subsection includes the case in which the peer node is outside the operator's network. In that case, IPv6-in-IPv4 tunneling can be necessary to obtain IPv6 connectivity and reach other IPv6 nodes. In general, configured tunneling can be recommended.
本小节包括对等节点在运营商网络之外的情况。在这种情况下，IPv6-In-IPv4隧道可能是获得IPv6连接并到达其他IPv6节点所必需的。通常，建议使用配置的隧道。
Tunnel starting point can be in the operator's network depending on how far the 3GPP operator has come in implementing IPv6. If the 3GPP operator has not deployed IPv6 in its backbone, the encapsulating node can be the GGSN. If the 3GPP operator has deployed IPv6 in its backbone but the upstream ISP does not provide IPv6 connectivity, the encapsulating node could be the 3GPP operator's border router.
隧道起点可以在运营商的网络中，具体取决于3GPP运营商在实施IPv6方面取得的进展。如果3GPP运营商尚未在其主干网中部署IPv6，则封装节点可以是GGSN。如果3GPP运营商在其主干网中部署了IPv6，但上游ISP不提供IPv6连接，则封装节点可能是3GPP运营商的边界路由器。
The case is pretty straightforward if the upstream ISP provides IPv6 connectivity to the Internet and the operator's backbone network supports IPv6. Then the 3GPP operator does not have to configure any tunnels, since the upstream ISP will take care of routing IPv6 packets. If the upstream ISP does not provide IPv6 connectivity, an IPv6-in-IPv4 tunnel should be configured, e.g., from the border router to a dual stack border gateway operated by another ISP that is offering IPv6 connectivity.
如果上游ISP提供到Internet的IPv6连接，并且运营商的主干网支持IPv6，则情况非常简单。然后，3GPP运营商不必配置任何隧道，因为上游ISP将负责路由IPv6数据包。如果上游ISP不提供IPv6连接，则应配置IPv6-in-IPv4隧道，例如，从边界路由器到由另一个提供IPv6连接的ISP操作的双堆栈边界网关。
3GPP networks are expected to support both IPv4 and IPv6 for a long time, on the UE-GGSN link and between the GGSN and external networks. For this scenario, it is useful to split the end-to-end IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-v4NODE. This allows an IPv4-only UE to use an IPv4 link (an IPv4 PDP context) to connect to the GGSN without communicating over an IPv6 network.
3GPP网络预计将在UE-GGSN链路上以及GGSN和外部网络之间长期支持IPv4和IPv6。对于此场景，将端到端IPv4 UE到IPv4节点的通信拆分为UE到GGSN和GGSN到v4NODE是非常有用的。这允许仅IPv4的UE使用IPv4链路（IPv4 PDP上下文）连接到GGSN，而无需通过IPv6网络进行通信。
Regarding the GGSN-to-v4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore, it is not envisaged that tunneling of IPv4-in-IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may choose to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs.
关于GGSN到V4节点的通信，通常GGSN和外部网络之间的传输网络在早期阶段仅支持IPv4，并迁移到双栈，因为这些网络已经部署。因此，预计也不需要从GGSN到外部IPv4网络的IPv4-in-IPv6隧道。从长远来看，3GPP运营商可以选择逐步淘汰IPv4 ue和IPv4传输网络。这将只剩下IPv6 UE。
Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not considered very likely in 3GPP networks.
因此，总体而言，在3GPP网络中不太可能考虑涉及通过IPv6网络与IPv4对等方通信的IPv4 UE的转换场景。
Generally speaking, IPv6-only UEs may be easier to manage, but that would require all services to be used over IPv6, and the universal deployment of IPv6 probably is not realistic in the near future. Dual stack implementation requires management of both IPv4 and IPv6 networks, and one approach is that "legacy" applications keep using IPv4 for the foreseeable future and new applications requiring end-to-end connectivity (for example, peer-to-peer services) use IPv6. As a general guideline, IPv6-only UEs are not recommended in the early phases of transition until the IPv6 deployment has become so prevalent that direct communication with IPv4(-only) nodes will be the exception and not the rule. It is assumed that IPv4 will remain useful for quite a long time, so in general, dual stack implementation in the UE can be recommended. This recommendation naturally includes manufacturing dual stack UEs instead of IPv4-only UEs.
一般来说，仅使用IPv6的UE可能更容易管理，但这将要求所有服务都通过IPv6使用，并且IPv6的普遍部署在不久的将来可能不现实。双栈实现需要同时管理IPv4和IPv6网络，其中一种方法是“传统”应用程序在可预见的未来继续使用IPv4，而需要端到端连接（例如，对等服务）的新应用程序使用IPv6。作为一般指导原则，在过渡的早期阶段，不建议使用仅限IPv6的UE，直到IPv6部署变得如此普遍，以至于与IPv4（-only）节点的直接通信将是例外而不是规则。假设IPv4将在相当长的时间内保持有用，因此一般来说，可以建议在UE中实现双栈。本建议自然包括制造双栈UE，而非仅IPv4 UE。
However, if there is a need to connect to an IPv4(-only) node from an IPv6-only UE, it is recommended to use specific translation and proxying techniques; generic IP protocol translation is not recommended. There are three main ways for IPv6(-only) nodes to communicate with IPv4(-only) nodes (excluding avoiding such communication in the first place):
但是，如果需要从仅IPv6的UE连接到IPv4（-only）节点，建议使用特定的转换和代理技术；不建议使用通用IP协议转换。IPv6（-only）节点与IPv4（-only）节点通信的主要方式有三种（不包括首先避免这种通信）：
1. the use of generic-purpose translator (e.g., NAT-PT [RFC2766]) in the local network (not recommended as a general solution),
1. 在本地网络中使用通用翻译器（如NAT-PT[RFC2766]）（不建议作为通用解决方案），
2. the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 TCP relay configured for a couple of ports only [RFC3142]) or application proxies (e.g., HTTP proxy, SMTP relay) in the local network, or
2. 在本地网络中使用特定用途的协议中继（例如，仅为几个端口配置的IPv6<->IPv4 TCP中继[RFC3142]）或应用程序代理（例如，HTTP代理、SMTP中继），或
3. the use of specific-purpose mechanisms (as described above in 2) in the foreign network; these are indistinguishable from the IPv6-enabled services from the IPv6 UE's perspective and are not discussed further here.
3. 在外部网络中使用特定目的机制（如上文第2节所述）；从ipv6ue的角度来看，这些服务与支持IPv6的服务没有什么区别，这里不再进一步讨论。
For many applications, application proxies can be appropriate (e.g., HTTP proxies, SMTP relays, etc.) Such application proxies will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. Application proxies can be placed, for example, on the GGSN external interface ("Gi"), or inside the service network.
对于许多应用程序，应用程序代理可能是合适的（例如，HTTP代理、SMTP中继等），这样的应用程序代理对UE是不透明的。因此，应该使用一种灵活的机制来配置IPv6 UE上的这些代理，并尽量减少手动干预。例如，可以将应用程序代理放置在GGSN外部接口（“Gi”）上或服务网络内部。
The authors note that [NATPTappl] discusses the applicability of NAT-PT, and [NATPTexp] discusses general issues with all forms of IPv6-IPv4 translation. The problems related to NAT-PT usage in 3GPP networks are documented in Appendix A.
作者指出，[NATPTAPL]讨论了NAT-PT的适用性，[NATPTexp]讨论了所有形式的IPv6-IPv4转换的一般问题。与3GPP网络中NAT-PT使用相关的问题记录在附录A中。
The legacy IPv4 nodes are typically nodes that support the applications that are popular today in the IPv4 Internet: mostly e-mail and web browsing. These applications will, of course, be supported in the future IPv6 Internet. However, the legacy IPv4 UEs are not going to be updated to support future applications. As these applications are designed for IPv6, and to use the advantages of newer platforms, the legacy IPv4 nodes will not be able to take advantage of them. Thus, they will continue to support legacy services.
传统IPv4节点通常是支持当前IPv4 Internet中流行的应用程序（主要是电子邮件和web浏览）的节点。当然，这些应用程序将在未来的IPv6 Internet中得到支持。但是，传统IPv4 UE不会更新以支持未来的应用程序。由于这些应用程序是为IPv6设计的，并且为了利用较新平台的优势，传统IPv4节点将无法利用它们。因此，它们将继续支持遗留服务。
Taking the above into account, the traffic to and from the legacy IPv4 UE is restricted to a few applications. These applications already mostly rely on proxies or local servers to communicate between private address space networks and the Internet. The same methods and technology can be used for IPv4-to-IPv6 transition.
考虑到上述因素，往返于传统IPv4 UE的流量仅限于少数应用程序。这些应用程序主要依靠代理或本地服务器在专用地址空间网络和Internet之间进行通信。同样的方法和技术也可用于IPv4到IPv6的转换。
As IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically. The possible IMS scenarios are listed below and analyzed in Sections 4.1 and 4.2.
由于IMS是专用于IPv6的，因此可能的过渡场景数量大大减少。以下列出了可能的IMS场景，并在第4.1节和第4.2节中进行了分析。
1) UE connecting to a node in an IPv4 network through IMS 2) Two IPv6 IMS connected via an IPv4 network
1) UE通过IMS连接到IPv4网络中的节点2）通过IPv4网络连接的两个IPv6 IMS
For DNS recommendations, we refer to Section 2.4. As DNS traffic is not directly related to the IMS functionality, the recommendations are not in contradiction with the IPv6-only nature of the IMS.
有关DNS建议，请参阅第2.4节。由于DNS流量与IMS功能没有直接关系，因此这些建议与IMS仅限IPv6的特性并不矛盾。
This scenario occurs when an (IPv6) IMS UE connects to a node in the IPv4 Internet through the IMS, or vice versa. This happens when the other node is a part of a different system than 3GPP, e.g., a fixed PC, with only IPv4 capabilities.
当（IPv6）IMS UE通过IMS连接到IPv4 Internet中的节点时，就会出现这种情况，反之亦然。当另一个节点是与3GPP不同的系统的一部分（例如，只有IPv4功能的固定PC）时，就会发生这种情况。
Over time, users will upgrade the legacy IPv4 nodes to dual-stack, often by replacing the entire node, eliminating this particular problem in that specific deployment.
随着时间的推移，用户会将传统IPv4节点升级到双堆栈，通常是通过替换整个节点，从而消除特定部署中的这一特定问题。
Still, it is difficult to estimate how many non-upgradable legacy IPv4 nodes need to communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed.
然而，很难估计有多少不可升级的传统IPv4节点需要与IMS UE通信。假设此处描述的解决方案用于有限的情况，其中需要与少量传统IPv4 SIP设备进行通信。
As the IMS is exclusively IPv6 [3GPP-23.221], for many of the applications in the IMS, some kind of translators may need to be used in the communication between the IPv6 IMS and the legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot be upgraded to support IPv6.
由于IMS是专用于IPv6的[3GPP-23.221]，对于IMS中的许多应用，在无法升级这些传统IPv4主机以支持IPv6的情况下，可能需要在IPv6 IMS和传统IPv4主机之间的通信中使用某种转换器。
This section gives a brief analysis of the IMS interworking issues and presents a high-level view of SIP within the IMS. The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as possible as a task within the SIP-related Working Groups in the IETF.
本节简要分析了IMS互通问题，并介绍了IMS内SIP的高级视图。作者建议，作为IETF中与SIP相关的工作组中的一项任务，应尽快指定针对一般SIP/SDP/媒体IPv4/IPv6转换问题的详细解决方案。
The issue of the IPv4/IPv6 interworking in SIP is somewhat more challenging than many other protocols. The control (or signaling) and user (or data) traffic are separated in SIP calls, and thus, the IMS, the transition of IMS traffic from IPv6 to IPv4, must be handled at two levels:
SIP中的IPv4/IPv6互通问题比许多其他协议更具挑战性。控制（或信令）和用户（或数据）流量在SIP呼叫中分开，因此，IMS（IMS流量从IPv6到IPv4的转换）必须在两个级别上处理：
1. Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface)
1. 会话启动协议（SIP）[RFC3261]和会话描述协议（SDP）[RFC2327][RFC3266]（Mm接口）
2. the user data traffic (Mb-interface)
2. 用户数据流量（Mb接口）
In addition, SIP carries an SDP body containing the addressing and other parameters for establishing the user data traffic (the media). Hence, the two levels of interworking cannot be made independently.
此外，SIP携带SDP主体，其中包含用于建立用户数据通信（媒体）的寻址和其他参数。因此，这两个级别的互通不能独立进行。
Figure 1 shows an example setup for IPv4 and IPv6 interworking in IMS. The "Interworking Unit" comprises two internal elements a dual stack SIP server and a transition gateway (TrGW) for the media traffic. These two elements are interconnected for synchronizing the interworking of the SIP signaling and the media traffic.
图1显示了IMS中IPv4和IPv6互通的示例设置。“互通单元”包括两个内部元件：用于媒体通信的双栈SIP服务器和转换网关（TrGW）。这两个元件相互连接，用于同步SIP信令和媒体流量的互通。
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP Serv| |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| TrGW ||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP Serv| |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------|| TrGW ||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone
图1:UE使用IMS联系传统电话
On reception of an INVITE, the SIP server reserves an IP address and a port from the TrGW both for IPv4 and IPv6. Then, the SIP server acts as a B2BUA (Back-to-Back User Agent) and rewrites the SDP of the INVITE to insert the transition gateway in the middle of the media flow between the two endpoints.
在接收到INVITE时，SIP服务器从TrGW保留一个IP地址和一个端口，用于IPv4和IPv6。然后，SIP服务器充当B2BUA（背对背用户代理），并重写邀请的SDP，以在两个端点之间的媒体流中间插入过渡网关。
When performing its B2BUA role, the SIP server acts as a UA (User Agent) toward both the IMS and the IPv4 host. Consequently, the SIP server needs to support all the extensions that apply to the session, which are listed in the Require header fields of the SIP messages.
当执行B2BUA角色时，SIP服务器充当面向IMS和IPv4主机的UA（用户代理）。因此，SIP服务器需要支持应用于会话的所有扩展，这些扩展列在SIP消息的Require头字段中。
This approach has a number of important drawbacks, however. The biggest drawback is that the rewriting of the SDP in the SIP signaling prevents securing the SDP payload between the two endpoints. In addition, it breaks the end-to-end negotiation of SIP extensions required for each session. Therefore, the extensions to be used in a particular session are limited by the extensions supported by the SIP server acting as a B2BUA. That is, the introduction of a new extension requires upgrading not only the UAs but the B2BUAs as well.
然而，这种方法有许多重要的缺点。最大的缺点是在SIP信令中重写SDP会阻止保护两个端点之间的SDP有效负载。此外，它还打破了每个会话所需的SIP扩展的端到端协商。因此，在特定会话中使用的扩展受到充当B2BUA的SIP服务器支持的扩展的限制。也就是说，引入新的扩展不仅需要升级UAs，还需要升级B2BUA。
This analysis clearly shows that a new solution for IPv4-IPv6 interworking in SIP networks is needed. The ability to convey multiple alternative addresses in SDP session descriptions [RFC4091] represents a step in this direction.
这一分析清楚地表明，在SIP网络中需要一种新的IPv4-IPv6互通解决方案。在SDP会话描述[RFC4091]中传输多个备选地址的能力代表了这一方向的一个步骤。
Given the problems related to the use of B2BUAs, it is recommended that the SIP-related Working Groups quickly work on a solution to overcome the drawbacks of this approach.
考虑到与B2BUA使用相关的问题，建议SIP相关工作组尽快制定解决方案，以克服此方法的缺点。
At the early stages of IMS deployment, there may be cases where two IMS islands are separated by an IPv4 network such as the legacy Internet. Here both the UEs and the IMS islands are IPv6 only. However, the IPv6 islands are not connected natively with IPv6.
在IMS部署的早期阶段，可能存在两个IMS岛被IPv4网络（如传统互联网）分隔的情况。这里，ue和IMS岛都是IPv6。但是，IPv6孤岛不是与IPv6本机连接的。
In this scenario, the end-to-end SIP connections are based on IPv6. The only issue is to make connection between two IPv6-only IMS islands over IPv4 network. This scenario is closely related to GPRS scenario represented in Section 3.2. and similar tunneling solutions are applicable also in this scenario.
在此场景中，端到端SIP连接基于IPv6。唯一的问题是通过IPv4网络在两个仅限IPv6的IMS孤岛之间建立连接。该场景与第3.2节中描述的GPRS场景密切相关。类似的隧道解决方案也适用于这种情况。
This informative section aims to give a brief overview of the configuration needed in the UE in order to access IP-based services. There can also be other application-specific settings in the UE that are not described here.
此信息性部分旨在简要概述UE中访问基于IP的服务所需的配置。在UE中还可以存在此处未描述的其他特定于应用程序的设置。
UE configuration is required in order to access IPv6- or IPv4-based services. The GGSN Access Point has to be defined when using, for example, the web-browsing application. One possibility is to use over-the-air configuration [OMA-CP] to configure the GPRS settings. The user can, for example, visit the operator WWW page and subscribe the GPRS Access Point settings to his/her UE and receive the settings via Short Message Service (SMS). After the user has accepted the settings and a PDP context has been activated, he/she can start browsing. The Access Point settings can also be typed in manually or be pre-configured by the operator or the UE manufacturer.
需要UE配置才能访问基于IPv6或IPv4的服务。例如，在使用web浏览应用程序时，必须定义GGSN接入点。一种可能是使用无线配置[OMA-CP]来配置GPRS设置。例如，用户可以访问运营商的WWW页面，向其UE订阅GPRS接入点设置，并通过短消息服务（SMS）接收设置。用户接受设置并激活PDP上下文后，他/她可以开始浏览。接入点设置也可以手动输入，或者由运营商或UE制造商预先配置。
DNS server addresses typically also need to be configured in the UE. In the case of IPv4 type PDP context, the (IPv4) DNS server addresses can be received in the PDP context activation (a control plane mechanism). A similar mechanism is also available for IPv6: so-called Protocol Configuration Options Information Element (PCO-IE) specified by the 3GPP [3GPP-24.008]. It is also possible to use [RFC3736] (or [RFC3315]) and [RFC3646] for receiving DNS server addresses. Active IETF work on DNS discovery mechanisms is ongoing and might result in other mechanisms becoming available over time. The DNS server addresses can also be received over the air (using SMS) [OMA-CP] or typed in manually in the UE.
DNS服务器地址通常也需要在UE中配置。在IPv4类型PDP上下文的情况下，可以在PDP上下文激活（控制平面机制）中接收（IPv4）DNS服务器地址。IPv6也有类似的机制：由3GPP[3GPP-24.008]指定的所谓协议配置选项信息元素（PCO-IE）。也可以使用[RFC3736]（或[RFC3315]）和[RFC3646]来接收DNS服务器地址。关于DNS发现机制的主动IETF工作正在进行中，随着时间的推移，可能会导致其他机制变得可用。DNS服务器地址也可以通过空中（使用SMS）[OMA-CP]接收或在UE中手动键入。
When accessing IMS services, the UE needs to know the Proxy-Call Session Control Function (P-CSCF) IPv6 address. Either a 3GPP-specific PCO-IE mechanism or a DHCPv6-based mechanism ([RFC3736] and [RFC3319]) can be used. Manual configuration or configuration over
当访问IMS服务时，UE需要知道代理呼叫会话控制功能（P-CSCF）IPv6地址。可以使用3GPP特定的PCO-IE机制或基于DHCPv6的机制（[RFC3736]和[RFC3319]）。手动配置或通过
the air is also possible. IMS subscriber authentication and registration to the IMS and SIP integrity protection are not discussed here.
空气也是可能的。此处不讨论IMS用户身份验证和注册到IMS和SIP完整性保护。
This document has analyzed five GPRS and two IMS IPv6 transition scenarios. Numerous 3GPP networks are using private IPv4 addresses today, and introducing IPv6 is important. The two first GPRS scenarios and both IMS scenarios are seen as the most relevant. The authors summarize some main recommendations here:
本文分析了五种GPRS和两种IMS IPv6过渡方案。如今，许多3GPP网络都在使用专用IPv4地址，引入IPv6非常重要。前两种GPRS方案和两种IMS方案被视为最相关的方案。作者在此总结了一些主要建议：
- Dual stack UEs are recommended instead of IPv4-only or IPv6- only UEs. It is important to take care that applications in the UEs support IPv6. In other words, applications should be IP version independent. IPv6-only UEs can become feasible when IPv6 is widely deployed in the networks, and most services work on IPv6.
- 建议使用双栈UE，而不是仅IPv4或仅IPv6的UE。务必注意UEs中的应用程序支持IPv6。换句话说，应用程序应该是独立于IP版本的。当IPv6在网络中广泛部署，并且大多数服务都在IPv6上工作时，只有IPv6的UE才成为可行的。
- It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node.
- 建议在与IPv6对等节点通信时激活IPv6 PDP上下文，在与IPv4对等节点通信时激活IPv4 PDP上下文。
- IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node.
- IPv6通信优先于通过IPv4 NAT到同一双堆栈对等节点的IPv4通信。
- This document strongly recommends that the 3GPP operators deploy basic IPv6 support in their GPRS networks as soon as possible. That makes it possible to lessen the transition effects in the UEs.
- 本文档强烈建议3GPP运营商尽快在其GPRS网络中部署基本的IPv6支持。这使得减少ue中的过渡效应成为可能。
- A tunneling mechanism in the UE may be needed during the early phases of the IPv6 transition process. A lightweight, automatic tunneling mechanism should be standardized in the IETF. See [zeroconf] for more details.
- 在IPv6转换过程的早期阶段期间，可能需要UE中的隧道机制。IETF中应标准化轻型自动隧道机制。有关更多详细信息，请参阅[zeroconf]。
- Tunneling mechanisms can be used in 3GPP networks, and only generic recommendations are given in this document. More details can be found, for example, in [RFC4029].
- 隧道机制可用于3GPP网络，本文档仅给出一般建议。例如，可以在[RFC4029]中找到更多详细信息。
- The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem be specified as soon as possible as a task within the SIP-related Working Groups in the IETF.
- 作者建议，作为IETF中与SIP相关的工作组中的一项任务，尽快指定一个针对一般SIP/SDP/媒体IPv4/IPv6转换问题的详细解决方案。
Deploying IPv6 has some generic security considerations one should be aware of [V6SEC]; however, these are not specific to 3GPP transition and are therefore out of the scope of this memo.
部署IPv6有一些通用的安全注意事项[V6SEC]；然而，这些并不是3GPP过渡的特定内容，因此不在本备忘录的范围之内。
This memo recommends the use of a relatively small number of techniques. Each technique has its own security considerations, including:
本备忘录建议使用相对较少的技术。每种技术都有自己的安全注意事项，包括：
- native upstream access or tunneling by the 3GPP network operator,
- 3GPP网络运营商的本地上行接入或隧道，
- use of routing protocols to ensure redundancy,
- 使用路由协议确保冗余，
- use of locally deployed specific-purpose protocol relays and application proxies to reach IPv4(-only) nodes from IPv6-only UEs, or
- 使用本地部署的专用协议中继和应用程序代理从仅限IPv6的UE到达IPv4（-only）节点，或
- a specific mechanism for SIP signaling and media translation.
- SIP信令和媒体转换的特定机制。
The threats of configured tunneling are described in [RFC4213]. Attacks against routing protocols are described in the respective documents and in general in [ROUTESEC]. Threats related to protocol relays have been described in [RFC3142]. The security properties of SIP internetworking are to be specified when the mechanism is specified.
[RFC4213]中描述了配置隧道的威胁。针对路由协议的攻击在相应的文档和[ROUTESEC]中进行了描述。[RFC3142]中描述了与协议中继相关的威胁。指定机制时，应指定SIP互连的安全属性。
In particular, this memo does not recommend the following technique, which has security issues, not further analyzed here:
特别是，本备忘录不建议采用以下技术，此处未进一步分析该技术存在的安全问题：
- NAT-PT or other translator as a general-purpose transition mechanism
- NAT-PT或其他翻译器作为通用转换机制
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC2765，2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[RFC3574]Soininen，J.，“3GPP网络的过渡场景”，RFC 3574，2003年8月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[3GPP-23.060] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[3GPP-23.060]3GPP TS 23.060 V5.4.0，“通用分组无线业务（GPRS）；业务描述；第2阶段（第5版）”，2002年12月。
[3GPP-23.221] 3GPP TS 23.221 V5.7.0, "Architectural requirements (Release 5)", December 2002.
[3GPP-23.221]3GPP TS 23.221 V5.7.0，“体系结构要求（版本5）”，2002年12月。
[3GPP-23.228] 3GPP TS 23.228 V5.7.0, "IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", December 2002.
[3GPP-23.228]3GPP TS 23.228 V5.7.0，“IP多媒体子系统（IMS）；第2阶段（第5版）”，2002年12月。
[3GPP-24.228] 3GPP TS 24.228 V5.3.0, "Signalling flows for the IP multimedia call control based on SIP and SDP; Stage 3 (Release 5)", December 2002.
[3GPP-24.228]3GPP TS 24.228 V5.3.0，“基于SIP和SDP的IP多媒体呼叫控制信令流；第3阶段（第5版）”，2002年12月。
[3GPP-24.229] 3GPP TS 24.229 V5.3.0, "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", December 2002.
[3GPP-24.229]3GPP TS 24.229 V5.3.0，“基于SIP和SDP的IP多媒体呼叫控制协议；第3阶段（第5版）”，2002年12月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142]Hagino，J.和K.Yamamoto，“IPv6到IPv4传输中继转换器”，RFC3142，2001年6月。
[RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002.
[RFC3266]Olson，S.，Camarillo，G.，和A.Roach，“对IPv6会话描述协议（SDP）的支持”，RFC 3266，2002年6月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]Wasserman，M.，“第三代合作伙伴项目（3GPP）标准中IPv6的建议”，RFC 3314，2002年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319]Schulzrinne，H.和B.Volz，“会话启动协议（SIP）服务器的动态主机配置协议（DHCPv6）选项”，RFC 3319，2003年7月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 36462003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004.
[RFC3901]Durand，A.和J.Ihren，“DNS IPv6传输操作指南”，BCP 91，RFC 3901，2004年9月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091]Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）分组框架的替代网络地址类型（ANAT）语义”，RFC 4091，2005年6月。
[ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, September 2005.
[ISATAP]Templin，F.，Gleeson，T.，Talwar，M.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 4214，2005年9月。
[NATPTappl] Satapati, S., Sivakumar, S., Barany, P., Okazaki, S. and H. Wang, "NAT-PT Applicability", Work in Progress, October 2003.
[NATPTappl]Satapati，S.，Sivakumar，S.，Barany，P.，Okazaki，S.和H.Wang，“NAT-PT适用性”，正在进行的工作，2003年10月。
[NATPTexp] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", Work in Progress, July 2005.
[NATPTexp]Aoun，C.和E.Davies，“将NAT-PT转移到实验的原因”，正在进行的工作，2005年7月。
[ROUTESEC] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress, April 2004.
[ROUTESEC]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，正在进行的工作，2004年4月。
[STEP] Savola, P.: "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress, January 2004.
[步骤]Savola，P.：“简单的IPv6-in-IPv4隧道建立过程（步骤）”，正在进行的工作，2004年1月。
[V6SEC] Savola, P.: "IPv6 Transition/Co-existence Security Considerations", Work in Progress, February 2004.
[V6SEC]Savola，P.：“IPv6过渡/共存安全考虑”，正在进行的工作，2004年2月。
[zeroconf] Nielsen, K., Morelli, M., Palet, J., Soininen, J., and J. Wiljakka, "Goals for Zero-Configuration Tunneling in 3GPP", Work in Progress, October 2004.
[zeroconf]Nielsen，K.，Morelli，M.，Palet，J.，Soininen，J.，和J.Wiljakka，“3GPP中零配置隧道的目标”，正在进行的工作，2004年10月。
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
[3GPP-24.008]3GPP TS 24.008 V5.8.0，“移动无线电接口层3规范；核心网络协议；第3阶段（第5版）”，2003年6月。
[OMA-CP] OMA Client Provisioning: Provisioning Architecture Overview Version 1.1, OMA-WAP-ProvArch-v1_1-20021112-C, Open Mobile Alliance, 12-Nov-2002.
[OMA-CP]OMA客户端资源调配：资源调配体系结构概述版本1.1，OMA-WAP-ProvArch-v1_1-20021112-C，开放移动联盟，2002年11月12日。
Pekka Savola has contributed both text and his IPv6 experience to this document. He has provided a large number of helpful comments on the v6ops mailing list. Allison Mankin has contributed text for IMS Scenario 1 (Section 4.1).
Pekka Savola为本文档提供了文本和他的IPv6经验。他在v6ops邮件列表上提供了大量有用的评论。Allison Mankin为IMS场景1提供了文本（第4.1节）。
This document was written by:
本文件由以下人员编写：
Alain Durand, Comcast <alain_durand@cable.comcast.com>
阿兰·杜兰德，康卡斯特<阿兰_durand@cable.comcast.com>
Karim El-Malki, Ericsson Radio Systems <Karim.El-Malki@era.ericsson.se>
卡里姆·马尔基，爱立信无线电系统<Karim.El-Malki@era.ericsson.se>
Niall Richard Murphy, Enigma Consulting Limited <niallm@enigma.ie>
尼尔·理查德·墨菲，英格玛咨询有限公司<niallm@enigma.ie>
Hugh Shieh, AT&T Wireless <hugh.shieh@attws.com>
谢休，AT&T无线<谢休。shieh@attws.com>
Jonne Soininen, Nokia <jonne.soininen@nokia.com>
Jonne Soininen，诺基亚<Jonne。soininen@nokia.com>
Hesham Soliman, Flarion <h.soliman@flarion.com>
Hesham Soliman，Flarion<h。soliman@flarion.com>
Margaret Wasserman, ThingMagic <margaret@thingmagic.com>
玛格丽特·沃瑟曼，神奇的东西<margaret@thingmagic.com>
Juha Wiljakka, Nokia <juha.wiljakka@nokia.com>
诺基亚Juha Wiljakka<Juha。wiljakka@nokia.com>
The authors would like to give special thanks to Spencer Dawkins for proofreading.
作者要特别感谢斯宾塞·道金斯的校对。
The authors would like to thank Heikki Almay, Gabor Bajko, Gonzalo Camarillo, Ajay Jain, Jarkko Jouppi, David Kessens, Ivan Laloux, Allison Mankin, Jasminko Mulahusic, Janne Rinne, Andreas Schmid, Pedro Serna, Fred Templin, Anand Thakur, and Rod Van Meter for their valuable input.
作者要感谢海基·阿尔梅、加博·巴伊科、冈萨洛·卡马里洛、阿杰·杰恩、雅科·朱皮、大卫·凯森斯、伊万·拉卢克斯、艾利森·曼金、贾斯明科·穆拉胡西奇、詹妮·里恩、安德烈亚斯·施密德、佩德罗·塞纳、弗雷德·坦普林、阿南·塔库尔和罗德·范·米特的宝贵投入。
Appendix A - On the Use of Generic Translators in the 3GPP Networks
附录A-关于3GPP网络中通用翻译器的使用
This appendix lists mainly 3GPP-specific arguments about generic translators, even though the use of generic translators is discouraged.
本附录主要列出了关于通用翻译器的3GPP特定论点，尽管不鼓励使用通用翻译器。
Due to the significant lack of IPv4 addresses in some domains, port multiplexing is likely to be a necessary feature for translators (i.e., NAPT-PT). If NAPT-PT is used, it needs to be placed on the GGSN external interface (Gi), typically separate from the GGSN. NAPT-PT can be installed, for example, on the edge of the operator's network and the public Internet. NAPT-PT will intercept DNS requests and other applications that include IP addresses in their payloads, translate the IP header (and payload for some applications if necessary), and forward packets through its IPv4 interface.
由于某些域中明显缺少IPv4地址，端口多路复用可能是转换器（即NAPT-PT）的必要功能。如果使用NAPT-PT，则需要将其放置在GGSN外部接口（Gi）上，通常与GGSN分开。例如，NAPT-PT可以安装在运营商网络和公共互联网的边缘。NAPT-PT将拦截DNS请求和其他在有效负载中包含IP地址的应用程序，转换IP报头（以及某些应用程序的有效负载，如有必要），并通过其IPv4接口转发数据包。
NAPT-PT introduces limitations that are expected to be magnified within the 3GPP architecture. [NATPTappl] discusses the applicability of NAT-PT in more detail. [NATPTexp] discusses general issues with all forms of IPv6-IPv4 translation.
NAPT-PT引入了在3GPP体系结构中可能被放大的限制。[NATPTAPL]更详细地讨论了NAT-PT的适用性。[NATPTexp]讨论了所有形式的IPv6-IPv4转换的一般问题。
3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NAPT-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes.
3GPP网络预计将在单个GGSN（默认路由器）上处理大量用户。每个GGSN预计将处理数十万个连接。此外，预期3GPP网络具有高可靠性。因此，GGSN外部接口上的单点故障将引起对整体网络可靠性的关注。此外，IPv6用户预计将使用IMS提供的延迟敏感应用程序。因此，需要最小化IP主干内的转发延迟。此外，由于3GPP网络中默认路由器（GGSN）处理的连接数量前所未有，因此强制流量通过网络边缘的单个节点的网络设计（典型的NAPT-PT配置）不太可能扩展。翻译机制应允许多个翻译器，以实现负载共享和冗余。
To minimize the problems associated with NAPT-PT, the following actions can be recommended:
为尽量减少与NAPT-PT相关的问题，建议采取以下措施：
1. Separate the DNS ALG from the NAPT-PT node (in the "IPv6 to IPv4" case).
1. 将DNS ALG与NAPT-PT节点分离（在“IPv6到IPv4”的情况下）。
2. Ensure (if possible) that NAPT-PT does not become a single point of failure.
2. 确保（如可能）NAPT-PT不会成为单点故障。
3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NAPT-PT from becoming a single point of failure.
3. 允许不同翻译器之间共享负载。也就是说，不同的连接应该可以通过不同的翻译器。请注意，单独的负载共享并不能防止NAPT-PT成为单点故障。
Editor's Contact Information
编辑联系方式
Comments or questions regarding this document should be sent to the v6ops mailing list or directly to the document editor:
有关本文档的评论或问题应发送至v6ops邮件列表或直接发送至文档编辑器：
Juha Wiljakka Nokia Visiokatu 3 FIN-33720 TAMPERE, Finland
Juha Wiljakka诺基亚Visiokatu 3 FIN-33720芬兰坦佩雷
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。