Internet Engineering Task Force (IETF)                          C. Byrne
Request for Comments: 7278                                  T-Mobile USA
Category: Informational                                         D. Drown
ISSN: 2070-1721                                                A. Vizdal
                                                     Deutsche Telekom AG
                                                               June 2014
        
Internet Engineering Task Force (IETF)                          C. Byrne
Request for Comments: 7278                                  T-Mobile USA
Category: Informational                                         D. Drown
ISSN: 2070-1721                                                A. Vizdal
                                                     Deutsche Telekom AG
                                                               June 2014
        

Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

将IPv6/64前缀从第三代合作伙伴计划(3GPP)移动接口扩展到LAN链路

Abstract

摘要

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

本文档描述了将IPv6/64前缀从用户设备第三代合作伙伴关系项目(3GPP)无线电接口扩展到LAN链路的要求,并描述了两个实现示例。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7278.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7278.

Copyright Notice

版权公告

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................3
   2. The Challenge of Providing IPv6 Addresses to a LAN Link via a
      3GPP UE .........................................................4
   3. Requirements for Extending the 3GPP Interface /64 IPv6
      Prefix to a LAN Link ............................................4
   4. Example Methods for Extending the 3GPP Interface /64
      IPv6 Prefix to a LAN Link .......................................5
      4.1. General Behavior for All Example Scenarios .................5
      4.2. Example Scenario 1: Global Address Only Assigned to
           LAN Link ...................................................5
      4.3. Example Scenario 2: A Single Global Address Assigned to a
           3GPP Radio and LAN Link ....................................7
   5. Security Considerations .........................................8
   6. Acknowledgments .................................................8
   7. Informative References ..........................................8
        
   1. Introduction ....................................................3
   2. The Challenge of Providing IPv6 Addresses to a LAN Link via a
      3GPP UE .........................................................4
   3. Requirements for Extending the 3GPP Interface /64 IPv6
      Prefix to a LAN Link ............................................4
   4. Example Methods for Extending the 3GPP Interface /64
      IPv6 Prefix to a LAN Link .......................................5
      4.1. General Behavior for All Example Scenarios .................5
      4.2. Example Scenario 1: Global Address Only Assigned to
           LAN Link ...................................................5
      4.3. Example Scenario 2: A Single Global Address Assigned to a
           3GPP Radio and LAN Link ....................................7
   5. Security Considerations .........................................8
   6. Acknowledgments .................................................8
   7. Informative References ..........................................8
        
1. Introduction
1. 介绍

3GPP mobile cellular networks such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), and Long Term Evolution (LTE) have architectural support for IPv6 [RFC6459], but only 3GPP Release-10 and onwards of the 3GPP specification [TS.23401] supports DHCPv6 Prefix Delegation [RFC3633] for delegating IPv6 prefixes to a single LAN link.

诸如全球移动通信系统(GSM)、通用移动通信系统(UMTS)和长期演进(LTE)等3GPP移动蜂窝网络具有IPv6[RFC6459]的体系结构支持,但只有3GPP规范[TS.23401]的3GPP版本10及更高版本支持DHCPv6前缀委派[RFC3633]用于将IPv6前缀委派给单个LAN链路。

To facilitate the use of IPv6 in a LAN prior to the deployment of DHCPv6 Prefix Delegation in 3GPP networks and in User Equipment (UE), this document describes requirements and provides examples on how the 3GPP UE radio interface assigned global /64 prefix may be extended from the 3GPP radio interface to a LAN link.

为了在3GPP网络和用户设备(UE)中部署DHCPv6前缀委派之前促进在LAN中使用IPv6,本文档描述了如何将3GPP UE无线接口分配的全局/64前缀扩展到LAN链路的要求并提供了示例。

There are two scenarios where this might be done. The first is where the 3GPP node sets up and manages its own LAN (e.g., an IEEE 802.11 Service Set Identifier (SSID)) and provides single-homed service to hosts that connect to this LAN. A second scenario is where the 3GPP node connects to an existing LAN and acts as a router in order to provide redundant or multi-homed IPv6 service.

有两种情况下可以这样做。第一个是3GPP节点建立和管理其自己的LAN(例如,IEEE 802.11服务集标识符(SSID))并向连接到此LAN的主机提供单宿服务的地方。第二种情况是3GPP节点连接到现有LAN并充当路由器,以提供冗余或多宿IPv6服务。

This document is intended to address the first scenario; it is not applicable to the second scenario, because the operational complexities of the second scenario are not addressed.

本文件旨在解决第一种情况;它不适用于第二个场景,因为第二个场景的操作复杂性没有得到解决。

This can be achieved by receiving the Router Advertisement (RA) [RFC4861] announced globally unique /64 IPv6 prefix from the 3GPP radio interface by the UE and then advertising the same IPv6 prefix to the LAN link with RA. For all of the cases in the scope of this document, the UE may be any device that functions as an IPv6 router between the 3GPP network and a LAN.

这可以通过由UE从3GPP无线电接口接收路由器通告(RA)[RFC4861]宣布的全局唯一/64 IPv6前缀,然后通过RA向LAN链路通告相同的IPv6前缀来实现。对于本文档范围内的所有情况,UE可以是在3GPP网络和LAN之间用作IPv6路由器的任何设备。

This document describes requirements for achieving an IPv6 prefix extension from a 3GPP radio interface to a LAN link including two practical implementation examples:

本文档描述了实现从3GPP无线电接口到LAN链路的IPv6前缀扩展的要求,包括两个实际实施示例:

1) The 3GPP UE only has a global-scope address on the LAN link.

1) 3GPP UE在LAN链路上只有一个全局作用域地址。

2) The 3GPP UE maintains the same consistent 128-bit global-scope IPv6 anycast address [RFC4291] on the 3GPP radio interface and the LAN link. The LAN link is configured as a /64 and the 3GPP radio interface is configured as a /128.

2) 3GPP UE在3GPP无线电接口和LAN链路上保持相同的一致的128位全局范围IPv6选播地址[RFC4291]。LAN链路配置为a/64,3GPP无线电接口配置为a/128。

Section 4 describes the characteristics of each of the two example approaches.

第4节描述了两种示例方法的各自特点。

1.2. Special Language
1.2. 特殊语言

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

Note that this document is not a Standard, and conformance with it is not required in order to claim conformance with IETF Standards for IPv6.

请注意,本文档不是一个标准,声明符合IPv6的IETF标准并不需要符合它。

This document uses the normative keywords only for precision.

本文件使用规范性关键字仅用于精确性。

2. The Challenge of Providing IPv6 Addresses to a LAN Link via a 3GPP UE

2. 通过3GPP UE向LAN链路提供IPv6地址的挑战

As described in [RFC6459], 3GPP networks assign a /64 global-scope prefix to each UE using RA. DHCPv6 Prefix Delegation is an optional part of 3GPP Release-10 and is not covered by any earlier releases. Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been suggested as an option for extending the assigned /64 from the 3GPP radio interface to the LAN link, but ND Proxy is an Experimental protocol and has some limitations with loop avoidance.

如[RFC6459]中所述,3GPP网络使用RA向每个UE分配/64全局作用域前缀。DHCPv6前缀委派是3GPP Release-10的可选部分,不在任何早期版本的范围内。邻居发现代理(ND Proxy)[RFC4389]功能已被建议作为将分配的/64从3GPP无线电接口扩展到LAN链路的选项,但ND Proxy是一种实验性协议,在环路避免方面存在一些限制。

DHCPv6 is the best way to delegate a prefix to a LAN link. The methods described in this document SHOULD only be applied when deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP network and the UE. The methods described in this document are at various stages of implementation and deployment planning. The goal of this memo is to document the available methods that may be used prior to DHCPv6 deployment.

DHCPv6是将前缀委托给LAN链路的最佳方式。仅当在3GPP网络和UE中无法实现部署DHCPv6前缀委派时,才应应用本文档中描述的方法。本文档中描述的方法处于实施和部署规划的不同阶段。本备忘录的目的是记录DHCPv6部署之前可能使用的可用方法。

3. Requirements for Extending the 3GPP Interface /64 IPv6 Prefix to a LAN Link

3. 将3GPP接口/64 IPv6前缀扩展到LAN链路的要求

R-1: The 3GPP network provided /64 prefix MUST be made available on the LAN link.

R-1:提供的3GPP网络/64前缀必须在LAN链路上可用。

LAN attached devices shall be able to use the 3GPP network assigned IPv6 prefix (e.g. using IPv6 Stateless Address Autoconfiguration - SLAAC [RFC4862]).

LAN连接设备应能够使用3GPP网络分配的IPv6前缀(例如,使用IPv6无状态地址自动配置-SLAAC[RFC4862])。

R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.

R-2:UE必须在LAN链路上保护其所有IPv6地址。

In case a LAN attached node will, for example, autoconfigure the same global IPv6 address as used on the 3GPP interface, the UE must fail the Duplicate Address Detection (DAD) [RFC4862] process run by the LAN node.

例如,在LAN连接的节点将自动配置与3GPP接口上使用的相同的全局IPv6地址的情况下,UE必须使LAN节点运行的重复地址检测(DAD)[RFC4862]过程失败。

R-3: The LAN link configuration MUST be tightly coupled with the 3GPP link state.

R-3:LAN链路配置必须与3GPP链路状态紧密耦合。

R-4: The UE MUST decrement the time to live (TTL) when passing packets between IPv6 links across the UE.

R-4:当通过UE在IPv6链路之间传递数据包时,UE必须减少生存时间(TTL)。

4. Example Methods for Extending the 3GPP Interface /64 IPv6 Prefix to a LAN Link

4. 将3GPP接口/64 IPv6前缀扩展到LAN链路的示例方法

4.1. General Behavior for All Example Scenarios
4.1. 所有示例场景的一般行为

As [RFC6459] describes, the 3GPP-network-assigned /64 is completely dedicated to the UE and the gateway does not consume any of the /64 addresses. The gateway routes the entire /64 to the UE and does not perform ND or Neighbor Unreachability Detection (NUD) [RFC4861]. Communication between the UE and the gateway is only done using link-local addresses and the link is point-to-point. This allows for the UE to reliably manipulate the /64 from the 3GPP radio interface without negatively impacting the point-to-point 3GPP radio link interface. The LAN link RA configuration must be tightly coupled with the 3GPP link state. If the 3GPP link goes down or changes the IPv6 prefix, that state should be reflected in the LAN link IPv6 configuration. Just as in a standard IPv6 router, the packet TTL will be decremented when passing packets between IPv6 links across the UE. The UE is employing the weak host model [RFC1122]. The RA function on the UE is exclusively run on the LAN link.

如[RFC6459]所述,分配/64的3GPP网络完全专用于UE,并且网关不使用/64地址中的任何地址。网关将整个/64路由到UE,并且不执行ND或邻居不可达性检测(NUD)[RFC4861]。UE和网关之间的通信仅使用链路本地地址完成,并且链路是点对点的。这允许UE从3GPP无线电接口可靠地操作/64,而不会对点对点3GPP无线电链路接口产生负面影响。LAN链路RA配置必须与3GPP链路状态紧密耦合。如果3GPP链路中断或更改IPv6前缀,则该状态应反映在LAN链路IPv6配置中。正如在标准IPv6路由器中一样,当通过UE在IPv6链路之间传递数据包时,数据包TTL将减小。UE采用弱主机模型[RFC1122]。UE上的RA功能仅在LAN链路上运行。

The LAN-link-originated RA message carries a copy of the following 3GPP radio-link-received RA message option fields:

源自LAN链路的RA消息包含以下3GPP无线链路接收到的RA消息选项字段的副本:

o MTU (if not provided by the 3GPP network, the UE will provide its 3GPP link MTU size)

o MTU(如果不是由3GPP网络提供,则UE将提供其3GPP链路MTU大小)

o Prefix Information

o 前缀信息

4.2. Example Scenario 1: Global Address Only Assigned to LAN Link
4.2. 示例场景1:仅分配给LAN链路的全局地址

For this case, the UE receives the RA from the 3GPP network but does not use a global address on the 3GPP interface. The 3GPP-interface-received RA /64 prefix information is used to configure the Neighbor Discovery Protocol (NDP) on the LAN. The UE assigns itself an IPv6 address on the LAN link from the 3GPP-interface-received RA. The LAN link uses RA to announce the prefix to the LAN. The UE LAN link interface defends its LAN IPv6 address with DAD. The UE shall not run SLAAC to assign a global address on the 3GPP radio interface while routing is enabled.

对于这种情况,UE从3GPP网络接收RA,但不使用3GPP接口上的全局地址。接收到RA/64前缀信息的3GPP接口用于在LAN上配置邻居发现协议(NDP)。UE在从3GPP接口接收到的LAN链路上为自己分配IPv6地址。LAN链路使用RA向LAN宣布前缀。UE LAN链路接口使用DAD保护其LAN IPv6地址。当路由启用时,UE不得运行SLAAC在3GPP无线电接口上分配全局地址。

This method allows the UE to originate and terminate IPv6 communications as a host while acting as an IPv6 router. The movement of the IPv6 prefix from the 3GPP radio interface to the LAN link may result in long-lived data connections being terminated during the transition from a host-only mode to router-and-host mode. Connections that are likely to be affected are ones that have been specifically bound to the 3GPP radio interface. This method is appropriate if the UE or software on the UE cannot support multiple interfaces with the same anycast IPv6 address and the UE requires global connectivity while acting as a router.

该方法允许UE作为主机发起和终止IPv6通信,同时充当IPv6路由器。IPv6前缀从3GPP无线电接口移动到LAN链路可能导致在从仅主机模式过渡到路由器和主机模式期间终止长寿命数据连接。可能受到影响的连接是专门绑定到3GPP无线电接口的连接。如果UE或UE上的软件不能支持具有相同选播IPv6地址的多个接口,并且UE在充当路由器时需要全局连接,则此方法是合适的。

Below is the general procedure for this scenario:

以下是此场景的一般过程:

1. The user activates router functionality for a LAN on the UE.

1. 用户激活UE上LAN的路由器功能。

2. The UE checks to make sure the 3GPP interface is active and has an IPv6 address. If the interface does not have an IPv6 address, an attempt will be made to acquire one; otherwise, the procedure will terminate.

2. UE检查以确保3GPP接口处于活动状态并且具有IPv6地址。如果接口没有IPv6地址,将尝试获取IPv6地址;否则,程序将终止。

3. In this example, the UE finds the 3GPP interface is active and has the IPv6 address 2001:db8:ac10:f002:1234:4567:0:9 assigned.

3. 在此示例中,UE发现3GPP接口处于活动状态,并且分配了IPv6地址2001:db8:ac10:f002:1234:4567:0:9。

4. The UE moves the address 2001:db8:ac10:f002:1234:4567:0:9 as a /64 from the 3GPP interfaces to the LAN link interface, disables the IPv6 SLAAC feature on the 3GPP radio interface to avoid address autoconfiguration, and begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to the LAN. For this example, the LAN has 2001:db8:ac10:f002:1234:4567:0:9/64 and the 3GPP radio only has a link-local address.

4. UE将地址2001:db8:ac10:f002:1234:4567:0:9作为a/64从3GPP接口移动到LAN链路接口,禁用3GPP无线电接口上的IPv6 SLAAC功能以避免地址自动配置,并开始通过RA向LAN宣布前缀2001:db8:ac10:f002::/64。对于本例,LAN具有2001:db8:ac10:f002:1234:4567:0:9/64,并且3GPP无线电仅具有链路本地地址。

5. The UE directly processes all packets destined to itself at 2001:db8:ac10:f002:1234:4567:0:9.

5. UE在2001:db8:ac10:f002:1234:4567:0:9处直接处理目的地为其自身的所有分组。

6. The UE, acting as a router running NDP on the LAN, will route packets to and from the LAN. IPv6 packets passing between interfaces will have the TTL decremented.

6. UE作为LAN上运行NDP的路由器,将向LAN发送数据包,并从LAN发送数据包。在接口之间传递的IPv6数据包将减少TTL。

7. On the LAN link interface, there is no chance of address conflict since the address is defended using DAD. The 3GPP radio interface only has a link-local address.

7. 在LAN链路接口上,不存在地址冲突的可能性,因为地址使用DAD进行保护。3GPP无线电接口只有一个链路本地地址。

4.3. Example Scenario 2: A Single Global Address Assigned to a 3GPP Radio and LAN Link

4.3. 示例场景2:分配给3GPP无线电和LAN链路的单个全局地址

In this method, the UE assigns itself one address from the 3GPP-network RA-announced /64. This one address is configured as anycast [RFC4291] on both the 3GPP radio link as a /128 and on the LAN link as a /64. This allows the UE to maintain long-lived data connections since the 3GPP radio interface address does not change when the router function is activated. This method may cause complications for certain software that may not support multiple interfaces with the same anycast IPv6 address, or are sensitive to prefix length changes. This method also creates complications for ensuring uniqueness for Privacy Extensions [RFC4941]. When Privacy Extensions are in use, all temporary addresses will be copied from the 3GPP radio interface to the LAN link. The preferred and valid lifetimes will be synchronized, such that the temporary anycast addresses on both interfaces expire simultaneously.

在该方法中,UE从3GPP网络RA/64为自己分配一个地址。这一地址在3GPP无线链路上配置为a/128,在LAN链路上配置为a/64。这允许UE维持长寿命的数据连接,因为当路由器功能被激活时3GPP无线电接口地址不会改变。此方法可能会使某些软件复杂化,这些软件可能不支持具有相同选播IPv6地址的多个接口,或者对前缀长度更改敏感。这种方法还为确保隐私扩展的唯一性带来了复杂性[RFC4941]。当使用隐私扩展时,所有临时地址将从3GPP无线电接口复制到LAN链路。首选和有效的生存期将同步,以便两个接口上的临时选播地址同时过期。

There might also be more complex scenarios in which the prefix length is not changed and privacy extensions are supported by having the subnet span multiple interfaces, as ND Proxy does [RFC4389]. Further elaboration is out of scope of the present document.

可能还有更复杂的场景,其中前缀长度不变,并且子网跨多个接口支持隐私扩展,就像ND Proxy一样[RFC4389]。进一步的阐述超出了本文件的范围。

Below is the general procedure for this scenario:

以下是此场景的一般过程:

1. The user activates router functionality for a LAN on the UE.

1. 用户激活UE上LAN的路由器功能。

2. The UE checks to make sure the 3GPP interface is active and has an IPv6 address. If the interface does not have an IPv6 address, an attempt will be made to acquire one; otherwise, the procedure will terminate.

2. UE检查以确保3GPP接口处于活动状态并且具有IPv6地址。如果接口没有IPv6地址,将尝试获取IPv6地址;否则,程序将终止。

3. In this example, the UE finds the 3GPP interface is active and has the IPv6 address 2001:db8:ac10:f002:1234:4567:0:9 assigned.

3. 在此示例中,UE发现3GPP接口处于活动状态,并且分配了IPv6地址2001:db8:ac10:f002:1234:4567:0:9。

4. The UE moves the address 2001:db8:ac10:f002:1234:4567:0:9 as an anycast /64 from the 3GPP interface to the LAN interface and begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to the LAN. The 3GPP interface maintains the same IPv6 anycast address with a /128. For this example, the LAN has 2001:db8:ac10:f002:1234:4567:0:9/64 and the 3GPP radio interface has 2001:db8:ac10:f002:1234:4567:0:9/128.

4. UE将地址2001:db8:ac10:f002:1234:4567:0:9作为选播/64从3GPP接口移动到LAN接口,并开始通过RA向LAN宣布前缀2001:db8:ac10:f002::/64。3GPP接口与a/128保持相同的IPv6选播地址。对于本例,LAN具有2001:db8:ac10:f002:1234:4567:0:9/64,而3GPP无线电接口具有2001:db8:ac10:f002:1234:4567:0:9/128。

5. The UE directly processes all packets destined to itself at 2001:db8:ac10:f002:1234:4567:0:9.

5. UE在2001:db8:ac10:f002:1234:4567:0:9处直接处理目的地为其自身的所有分组。

6. On the LAN interface, there is no chance of address conflict since the address is defended using DAD. The 3GPP radio interface only has a /128 and no other systems on the 3GPP radio point-to-point link may use the global /64.

6. 在LAN接口上,不存在地址冲突的可能性,因为地址使用DAD进行保护。3GPP无线电接口仅具有a/128,并且3GPP无线电点到点链路上的任何其他系统都不能使用global/64。

5. Security Considerations
5. 安全考虑

Since the UE will be switched from an IPv6 host mode to an IPv6 router-and-host mode, basic IPv6 Customer Premises Equipment (CPE) security functions [RFC6092] SHOULD be applied.

由于UE将从IPv6主机模式切换到IPv6路由器和主机模式,因此应应用基本的IPv6客户场所设备(CPE)安全功能[RFC6092]。

Despite the use of temporary IPv6 addresses, the mobile-network-provided /64 prefix is common to all the LAN-attached devices potentially concerning privacy. An IPv6 prefix provided by a nomadic device (e.g., a smartphone) is not a long-lived one due to re-attaches caused by a device reload, traveling through loosely covered areas, etc. The network will provide a new IPv6 prefix after a successful re-attach.

尽管使用了临时IPv6地址,但移动网络提供的/64前缀对于所有可能涉及隐私的LAN连接设备来说是通用的。游牧设备(如智能手机)提供的IPv6前缀不是长期存在的前缀,因为设备重新加载、穿越松散覆盖区域等导致重新连接。成功重新连接后,网络将提供新的IPv6前缀。

3GPP-mobile-network-capable CPEs (e.g., a router) are likely to keep the mobile network data connection up for a longer time. Some mobile networks may be re-setting the mobile network connection regularly (e.g., every 24 hours), others may not. Privacy-concerned users shall take appropriate measures to not keep their IPv6 prefixes long lived.

具有3GPP移动网络能力的cpe(例如,路由器)可能将移动网络数据连接保持更长时间。一些移动网络可能会定期(例如,每24小时)重新设置移动网络连接,而另一些则可能不会。关注隐私的用户应采取适当措施,避免其IPv6前缀长期存在。

6. Acknowledgments
6. 致谢

Many thanks for review and discussion from Dave Thaler, Sylvain Decremps, Mark Smith, Dmitry Anipko, Masanobu Kawashima, Teemu Savolainen, Mikael Abrahamsson, Eric Vyncke, Alexandru Petrescu, Jouni Korhonen, Lorenzo Colitti, Julien Laganier, Owen DeLong, Holger Metschulat, Yaron Sheffer, and Victor Kuarsingh. Special thanks to Ann Cerveny for her language review.

非常感谢Dave Thaler、Sylvain Decremps、Mark Smith、Dmitry Anipko、Masanobu Kawashima、Teemu Savolainen、Mikael Abrahamsson、Eric Vyncke、Alexandru Petrescu、Jouni Korhonen、Lorenzo Coletti、Julien Laganier、Owen DeLong、Holger Metschulat、Yaron Sheffer和Victor Kuarsingh的评论和讨论。特别感谢Ann Cerveny的语言评论。

7. Informative References
7. 资料性引用

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]Braden,R.,Ed.“互联网主机的要求-通信层”,STD 3,RFC 1122,1989年10月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[RFC3633]Troan,O.和R.Droms,“动态主机配置协议(DHCP)版本6的IPv6前缀选项”,RFC 3633,2003年12月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291]Hinden,R.和S.Deering,“IP版本6寻址体系结构”,RFC 42912006年2月。

[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.

[RFC4389]Thaler,D.,Talwar,M.,和C.Patel,“邻居发现代理(ND代理)”,RFC 4389,2006年4月。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

[RFC4861]Narten,T.,Nordmark,E.,Simpson,W.,和H.Soliman,“IP版本6(IPv6)的邻居发现”,RFC 48612007年9月。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862]Thomson,S.,Narten,T.,和T.Jinmei,“IPv6无状态地址自动配置”,RFC 48622007年9月。

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.

[RFC4941]Narten,T.,Draves,R.,和S.Krishnan,“IPv6中无状态地址自动配置的隐私扩展”,RFC 49412007年9月。

[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.

[RFC6092]Woodyatt,J.,Ed.,“提供住宅IPv6互联网服务的客户场所设备(CPE)中推荐的简单安全功能”,RFC 6092,2011年1月。

[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.

[RFC6459]Korhonen,J.,Ed.,Soininen,J.,Patil,B.,Savolainen,T.,Bajko,G.,和K.Iisakkila,“第三代合作伙伴关系项目(3GPP)中的IPv6演进包系统(EPS)”,RFC 6459,2012年1月。

[TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.0.0, June 2010.

[TS.23401]3GPP,“通用分组无线业务(GPRS)对演进型通用地面无线接入网(E-UTRAN)接入的增强”,3GPP TS 23.401 10.0.02010年6月。

Authors' Addresses

作者地址

Cameron Byrne T-Mobile USA Bellevue, Washington, USA EMail: Cameron.Byrne@T-Mobile.com

Cameron Byrne T-Mobile USA Bellevue,华盛顿,USA电子邮件:Cameron。Byrne@T-Mobile.com

Dan Drown EMail: Dan@Drown.org

Dan溺水电子邮件:Dan@Drown.org

Ales Vizdal Deutsche Telekom AG Tomickova 2144/1 Prague, 149 00 Czech Republic EMail: Ales.Vizdal@T-Mobile.cz

Ales Vizdal德国电信公司托米科娃2144/1布拉格,14900捷克共和国电子邮件:Ales。Vizdal@T-Mobile.cz