Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 6908 Comcast
Category: Informational R. Maglione
ISSN: 2070-1721 Cisco Systems
C. Williams
MCSR Labs
C. Jacquenet
M. Boucadair
France Telecom
March 2013
Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 6908 Comcast
Category: Informational R. Maglione
ISSN: 2070-1721 Cisco Systems
C. Williams
MCSR Labs
C. Jacquenet
M. Boucadair
France Telecom
March 2013
Deployment Considerations for Dual-Stack Lite
双栈Lite的部署注意事项
Abstract
摘要
This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.
本文档讨论双栈Lite（DS Lite）的部署问题以及部署和操作要求。本文档描述了DS Lite体系结构的各种部署注意事项和适用性。
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/rfc6908.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6908.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Overview ........................................................3
2. AFTR Deployment Considerations ..................................3
2.1. Interface Consideration ....................................3
2.2. MTU and Fragmentation Considerations .......................4
2.3. Logging at the AFTR ........................................4
2.4. Blacklisting a Shared IPv4 Address .........................5
2.5. AFTR's Policies ............................................5
2.5.1. Outgoing Policy .....................................5
2.5.2. Incoming Policy .....................................6
2.6. AFTR Impacts on Accounting Process .........................6
2.7. Reliability Considerations of AFTR .........................7
2.8. Strategic Placement of AFTR ................................8
2.9. AFTR Considerations for Geographically Aware Services ......8
2.10. Impacts on QoS Policy .....................................9
2.11. Port Forwarding Considerations ............................9
2.12. DS-Lite Tunnel Security ..................................10
2.13. IPv6-Only Network Considerations .........................10
3. B4 Deployment Considerations ...................................10
3.1. DNS Deployment Considerations .............................11
3.2. IPv4 Service Monitoring ...................................11
3.2.1. B4 Remote Management ...............................11
3.2.2. IPv4 Connectivity Check ............................11
4. Security Considerations ........................................12
5. Acknowledgements ...............................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
1. Overview ........................................................3
2. AFTR Deployment Considerations ..................................3
2.1. Interface Consideration ....................................3
2.2. MTU and Fragmentation Considerations .......................4
2.3. Logging at the AFTR ........................................4
2.4. Blacklisting a Shared IPv4 Address .........................5
2.5. AFTR's Policies ............................................5
2.5.1. Outgoing Policy .....................................5
2.5.2. Incoming Policy .....................................6
2.6. AFTR Impacts on Accounting Process .........................6
2.7. Reliability Considerations of AFTR .........................7
2.8. Strategic Placement of AFTR ................................8
2.9. AFTR Considerations for Geographically Aware Services ......8
2.10. Impacts on QoS Policy .....................................9
2.11. Port Forwarding Considerations ............................9
2.12. DS-Lite Tunnel Security ..................................10
2.13. IPv6-Only Network Considerations .........................10
3. B4 Deployment Considerations ...................................10
3.1. DNS Deployment Considerations .............................11
3.2. IPv4 Service Monitoring ...................................11
3.2.1. B4 Remote Management ...............................11
3.2.2. IPv4 Connectivity Check ............................11
4. Security Considerations ........................................12
5. Acknowledgements ...............................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
DS-Lite [RFC6333] is a transition technique that enables operators to multiplex public IPv4 addresses while provisioning only IPv6 to users. DS-Lite is designed to continue offering IPv4 services while operators upgrade their networks incrementally to IPv6. DS-Lite combines IPv4-in-IPv6 softwire [RFC2473] and Network Address Translator IPv4/IPv4 (NAT44) [RFC3022] to enable more than one user to share a public IPv4 address.
DS Lite[RFC6333]是一种转换技术，它使运营商能够多路传输公共IPv4地址，同时只向用户提供IPv6。DS Lite旨在继续提供IPv4服务，同时运营商以增量方式将其网络升级到IPv6。DS Lite将IPv4-in-IPv6软线[RFC2473]和网络地址转换器IPv4/IPv4（NAT44）[RFC3022]结合起来，使多个用户能够共享公共IPv4地址。
While Appendix A of [RFC6333] explains how to deploy DS-Lite within specific scenarios, the purpose of this document is to describe problems that arise when deploying DS-Lite and what guidance should be taken to mitigate those issues. The information is based on real deployment experience and is compiled in one comprehensive document so that operators aren't required to search through various RFCs deciding which sections are applicable and impact their DS-Lite deployment.
虽然[RFC6333]的附录A解释了如何在特定场景中部署DS Lite，但本文档的目的是描述部署DS Lite时出现的问题，以及应采取何种指导来缓解这些问题。这些信息基于实际的部署经验，并汇编在一份综合文档中，因此运营商无需搜索各种RFC，以确定哪些部分适用并影响其DS Lite部署。
Address Family Transition Router (AFTR) is a network element that is deployed inside the operator's network. An AFTR can be a stand-alone device or be embedded into a router. The AFTR is the IPv4-in-IPv6 tunnel termination point and the NAT44 device. It is deployed at the IPv4-IPv6 network border where the tunnel interface is IPv6 and the external NAT44 interface is IPv4. The Basic Bridging BroadBand (B4) element [RFC6333] is a function implemented on a dual-stack-capable node (either a host device or a home gateway) that creates a tunnel to an AFTR. Although an operator can configure both softwire tunnel termination and interface for NAT44 functions on a single physical interface (yet, keep them logically separated), there are scenarios we recommend to configure two individual interfaces (i.e., one dedicated for IPv4 and one dedicated for IPv6) to segregate the functions.
地址族转换路由器（AFTR）是部署在运营商网络内的网络元件。AFTR可以是独立设备，也可以嵌入路由器。AFTR是IPv4-in-IPv6隧道终止点和NAT44设备。它部署在IPv4-IPv6网络边界，其中隧道接口为IPv6，外部NAT44接口为IPv4。基本桥接宽带（B4）元素[RFC6333]是在双堆栈功能节点（主机设备或家庭网关）上实现的功能，该节点创建到AFTR的隧道。尽管运营商可以在单个物理接口上为NAT44功能配置软线隧道终端和接口（但要保持逻辑上的分离），但我们建议在某些情况下配置两个单独的接口（即，一个专用于IPv4，另一个专用于IPv6）以分离功能。
o The access network between the B4 and AFTR is an IPv6-only network, and the network between the AFTR and IPv4 network is an IPv4-only network. In this deployment scenario, the AFTR interface to the IPv6-only network and the interface to the IPv4 network should use two physical interfaces on the AFTR.
o B4和AFTR之间的接入网络为仅限IPv6的网络，AFTR和IPv4之间的网络为仅限IPv4的网络。在此部署场景中，仅IPv6网络的AFTR接口和IPv4网络的接口应使用AFTR上的两个物理接口。
o Operators may use Operations Support System (OSS) tools (e.g., Multi Router Traffic Grapher) to collect interface data packet count information. If an operator wants to separate the softwire function and NAT44 function on different physical interfaces for
o 运营商可使用运营支持系统（OSS）工具（如多路由器流量记录仪）收集接口数据包计数信息。如果操作员希望在不同的物理接口上分离softwire功能和NAT44功能
collecting a data packet count, and the AFTR does not support packet count for logical interfaces, they should use two physical interfaces on the AFTR.
收集数据包计数时，如果AFTR不支持逻辑接口的数据包计数，则应在AFTR上使用两个物理接口。
DS-Lite is part tunneling protocol. Tunneling introduces overhead to the packet and decreases the effective MTU size after encapsulation. DS-Lite users may experience problems with applications such as not being able to download Internet pages or transfer large files.
DS Lite是部分隧道协议。隧道为数据包带来了开销，并在封装后减小了有效的MTU大小。DS Lite用户可能会遇到应用程序问题，例如无法下载Internet页面或传输大型文件。
Since fragmentation and reassembly is not optimal, the operator should do everything possible to eliminate the need for it. If the operator uses simple IPv4-in-IPv6 softwire [RFC2473], it is recommended that the MTU size of the IPv6 network between the B4 and the AFTR accounts for the additional overhead (40 bytes). If the access network MTU size is fixed and cannot be changed, the operator should be aware that the B4 and the AFTR must support fragmentation as defined in [RFC6333]. The operator should also be aware that reassembly at the Tunnel Exit-Point is resource intensive as a large number of B4 may terminate on the same AFTR. Scalability of the AFTR is advised in this scenario.
由于碎片和重新组装不是最优的，操作员应尽一切可能消除对碎片和重新组装的需要。如果运营商使用简单的IPv4-in-IPv6软线[RFC2473]，建议B4和AFTR之间IPv6网络的MTU大小考虑额外开销（40字节）。如果接入网络MTU大小固定且无法更改，则运营商应注意B4和AFTR必须支持[RFC6333]中定义的碎片。运营商还应意识到，在隧道出口点重新组装是资源密集型的，因为大量B4可能在同一AFTR上终止。在此场景中建议AFTR的可伸缩性。
A source-specific log is essential for backtracking specific hosts when a problem is identified with one of the AFTR's NAT-ed addresses. The source-specific log contains the B4 IPv6 source address, transport protocol, source port, and source IPv4 address after it has been NAT-ed. Using the source-specific log, operators can uniquely identify a specific host when a DS-Lite host experiences problems accessing the IPv4 network. To maximize IPv4 shared ratio, an operator may configure a short timeout value for NAT44 entries. This will result in a large number of logs created by the AFTR. For operators who desire to aggregate the logs, they can configure the AFTR to preallocate a range of ports to each B4. This range of ports will be used in the NAT44 function, and the AFTR will create one log entry for the whole port range. This aggregation can significantly reduce the log size for source-specific logging.
当AFTR的NAT地址之一出现问题时，源特定日志对于回溯特定主机至关重要。源特定日志包含经过NAT-ed后的B4 IPv6源地址、传输协议、源端口和源IPv4地址。使用源特定日志，当DS Lite主机在访问IPv4网络时遇到问题时，操作员可以唯一地识别特定主机。为了最大化IPv4共享比率，操作员可以为NAT44条目配置短超时值。这将导致AFTR创建大量日志。对于希望聚合日志的操作员，他们可以将AFTR配置为向每个B4预先分配一系列端口。NAT44函数将使用此端口范围，AFTR将为整个端口范围创建一个日志条目。此聚合可以显著减少源特定日志记录的日志大小。
Some operators may require logging both source and destination information for a host's connections. This is called a destination-specific log. A destination-specific log contains the B4's IPv6 address, transport protocol, source port, source IPv4 address after it has been NAT-ed, destination port, and destination IPv4 address. A destination-specific log is session-based; the operators should be aware that they will not be able to aggregate log entries. When using a destination-specific log, the operator must be careful of the
某些操作员可能需要记录主机连接的源和目标信息。这称为目标特定日志。目标特定日志包含B4的IPv6地址、传输协议、源端口、NAT后的源IPv4地址、目标端口和目标IPv4地址。特定于目的地的日志是基于会话的；操作员应该知道，他们将无法聚合日志条目。使用特定于目的地的日志时，操作员必须小心
large number of log entries created by the AFTR. Some AFTR implementations may keep the logs in their main memory. This may be CPU and memory resource intensive. The operators should configure the AFTR to periodically send logs to storage facility and then purge them from the AFTR.
AFTR创建的大量日志条目。一些AFTR实现可能会将日志保留在主内存中。这可能是CPU和内存资源密集型的。操作员应将AFTR配置为定期向存储设施发送日志，然后从AFTR中清除日志。
The AFTR is a NAT device. It enables multiple B4s to share a single public IPv4 address. [RFC6269] discusses some considerations when sharing an IPv4 address. When a public IPv4 address is blacklisted by a remote peer, this may affect multiple users or hosts. Operators deploying DS-Lite should be aware that Internet hosts may not be aware that a given single IPv4 address is actually shared by multiple B4s. A content provider might block services for a shared IPv4 address and this would then impact all B4s sharing this particular IPv4 address. The operator would be likely to receive calls related to service outage and would then need to take appropriate corrective actions. [RFC6302] describes necessary information required to identify a user or host in shared address environment. It is also worth mention that [NAT-REVEAL] analyses different approaches to identify a user or host in a shared address environment.
AFTR是一种NAT设备。它允许多个B4共享一个公共IPv4地址。[RFC6269]讨论了共享IPv4地址时的一些注意事项。当公共IPv4地址被远程对等方列入黑名单时，这可能会影响多个用户或主机。部署DS Lite的运营商应该知道，Internet主机可能不知道给定的单个IPv4地址实际上由多个B4共享。内容提供商可能会阻止共享IPv4地址的服务，这将影响共享此特定IPv4地址的所有B4。运营商可能会接到与服务中断相关的电话，然后需要采取适当的纠正措施。[RFC6302]描述了在共享地址环境中识别用户或主机所需的必要信息。还值得一提的是，[NAT-REVEL]分析了在共享地址环境中识别用户或主机的不同方法。
There are two types of AFTR policies:
AFTR政策有两种类型：
o Outgoing Policies apply to packets originating from B4 to the AFTR. These policies should be provisioned on the AFTR's IPv6 interface that is connected to the B4s.
o 传出策略适用于从B4到AFTR的数据包。应在连接到B4s的AFTR的IPv6接口上设置这些策略。
o Incoming Policies apply to packets originating from IPv4 networks to B4s. These policies should be provisioned on the IPv4 interface connected to the IPv4 network.
o 传入策略适用于从IPv4网络发送到B4的数据包。应在连接到IPv4网络的IPv4接口上设置这些策略。
Outgoing Policies may include Access Control List (ACL) and Quality of Service (QoS) settings. These policies control the packets from B4s to the AFTR. For example, the operator may configure the AFTR only to accept B4 connections that originated from specific IPv6 prefixes configured in the AFTR. More discussion of this use case can be found in Section 2.12. An operator may configure the AFTR to give priority to the packets marked by certain Differentiated Services Code Point (DSCP) values [RFC2475]. Furthermore, an AFTR may also apply an Outgoing Policy to limit the rate of port allocation for a single B4's IPv6 address.
传出策略可能包括访问控制列表（ACL）和服务质量（QoS）设置。这些策略控制从B4s到AFTR的数据包。例如，运营商可将AFTR配置为仅接受源自AFTR中配置的特定IPv6前缀的B4连接。关于这个用例的更多讨论可以在第2.12节中找到。运营商可配置AFTR，以优先考虑由特定区分服务代码点（DSCP）值标记的数据包[RFC2475]。此外，AFTR还可以应用传出策略来限制单个B4的IPv6地址的端口分配速率。
Some operators offer different service level agreements (SLAs) to users to meet their requirements. Some users may require more ports and some may require different service priority. In this deployment scenario, the operator can implement Outgoing Policies specified to a user's B4 or a group of B4s sharing the same policies.
一些运营商向用户提供不同的服务级别协议（SLA）以满足其需求。有些用户可能需要更多端口，有些用户可能需要不同的服务优先级。在此部署场景中，操作员可以实施为用户的B4或共享相同策略的一组B4指定的传出策略。
Similar to the Outgoing Policy, an Incoming Policy may also include ACL and QoS settings. The Outgoing Policy controls packets coming from the IPv4 network to the B4s. Incoming packets are normally treated equally, so these policies are globally applied. For example, an operator wants to use a predefined DSCP value to signal the IPv6 access network to apply certain traffic policies. In this deployment scenario, the operator can configure the AFTR to mark the incoming packets with the predefined DSCP value. This policy will apply to all incoming packets from the IPv4 network.
与传出策略类似，传入策略还可以包括ACL和QoS设置。传出策略控制从IPv4网络到B4s的数据包。传入的数据包通常被同等对待，因此这些策略在全球范围内应用。例如，运营商希望使用预定义的DSCP值向IPv6接入网络发送信号，以应用某些流量策略。在此部署场景中，操作员可以配置AFTR，以使用预定义的DSCP值标记传入数据包。此策略将应用于来自IPv4网络的所有传入数据包。
This section discusses IPv4 and IPv6 traffic accounting in the DS-Lite environment. In a typical broadband access scenario (e.g., DSL or Cable), the B4 is embedded in a Residential Gateway. The edge router for the B4s in the provider's network is an IPv6 edge router. The edge router is usually responsible for IPv6 accounting and the user management functions such as authentication, authorization, and accounting (AAA). However, given the fact that IPv4 traffic is encapsulated in an IPv6 packet at the B4 and only decapsulated at the AFTR, the edge router will require additional functionality to associate IPv4 accounting information to the B4 IPv6 address. If DS-Lite is the only application using the IPv4-in-IPv6 protocol in the IPv6 access network, the operator can configure the edge router to check the IPv6 Next Header field in the IPv6 header, identify the protocol type (i.e., 0x04), and collect IPv4 accounting information.
本节讨论DS Lite环境中的IPv4和IPv6流量计费。在典型的宽带接入场景（例如，DSL或电缆）中，B4嵌入在住宅网关中。提供商网络中B4s的边缘路由器是IPv6边缘路由器。边缘路由器通常负责IPv6计费和用户管理功能，如身份验证、授权和计费（AAA）。然而，考虑到IPv4流量在B4封装在IPv6数据包中，并且仅在AFTR解除封装，边缘路由器将需要额外的功能来将IPv4记帐信息与B4 IPv6地址相关联。如果DS Lite是IPv6接入网络中使用IPv4-in-IPv6协议的唯一应用程序，则运营商可以配置边缘路由器以检查IPv6报头中的IPv6下一个报头字段，识别协议类型（即0x04），并收集IPv4记帐信息。
Alternatively, the AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges, especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, the AFTR may not have the AAA parameters (e.g., Account Session ID) associated with B4s to generate an IPv4 accounting record. IPv4 traffic accounting at the AFTR is not recommended when the AAA parameters necessary to generate complete IPv4 accounting records are not available. The accounting process at the AFTR is only necessary if the operator requires separating per-B4 accounting records for IPv4 and IPv6 traffic. If the per-B4 IPv6 accounting records, collected
或者，AFTR可以对IPv4流量执行记帐。然而，运营商必须意识到这将带来一些挑战，特别是在DSL部署中。在DSL部署中，AAA事务通常发生在边缘路由器（即宽带网络网关）和AAA服务器之间。[RFC6333]不要求AFTR与AAA服务器或边缘路由器交互。因此，AFTR可能没有与B4关联的AAA参数（例如，帐户会话ID）来生成IPv4记帐记录。当生成完整IPv4计费记录所需的AAA参数不可用时，不建议在AFTR进行IPv4流量计费。只有当运营商要求分离IPv4和IPv6流量的per-B4记帐记录时，AFTR的记帐过程才有必要。如果收集了per-B4 IPv6会计记录
by the edge router, are sufficient, then the additional complexity of enabling IPv4 accounting at the AFTR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contains the total amount of traffic (i.e., IPv4 and IPv6).
通过边缘路由器，这就足够了，那么就不需要在AFTR上启用IPv4记帐的额外复杂性。需要注意的是，由于IPv4流量封装在IPv6数据包中，因此边缘路由器为IPv6流量收集的数据已经包含了流量总量（即IPv4和IPv6）。
Even if detailed accounting records collection for IPv4 traffic may not be required, it would be useful for an operator, in some scenarios, to have information that the edge router generates for the IPv6 traffic. This information can be used to identify the AFTR who is handling the IPv4 traffic for that B4. This can be achieved by adding additional information to the IPv6 accounting records. For example, operators can use RADIUS attribute information specified in [RFC6519] or a new attribute to be specified in Internet Protocol Detailed Record (IPDR).
即使可能不需要收集IPv4流量的详细记帐记录，在某些情况下，运营商也可以获得边缘路由器为IPv6流量生成的信息。此信息可用于识别正在处理该B4的IPv4流量的AFTR。这可以通过向IPv6记帐记录添加其他信息来实现。例如，操作员可以使用[RFC6519]中指定的RADIUS属性信息，或在Internet协议详细记录（IPDR）中指定的新属性。
For robustness, reliability, and load distribution purposes, operators may deploy multiple AFTRs. In such cases, the IPv6 prefixes and algorithm to build the tunneling mechanisms configured on each of these AFTRs will be the same. In [RFC6333], Appendix A.3 mentions that High Availability (HA) is the operator's responsibility. Since DS-Lite is a stateful mechanism, all requirements for load-balancing and failover mechanisms apply. There are many ways to implement HA in a stateful mechanism; the most common are Cold Standby mode and Hot Standby mode. More discussion on deploying these two modes for NAT can be found in [NAT-STANDBY]. In Cold Standby mode, the AFTR states are not replicated from the Primary AFTR to the Backup AFTR. When the Primary AFTR fails, all the existing established sessions will be flushed out. The internal hosts are required to reestablish sessions with the external hosts. In Hot Standby mode, the session's states are replicated on-the-fly from the Primary AFTR to the Backup AFTR. When the Primary AFTR fails, the Backup AFTR will take over all the existing established sessions. In this mode, the internal hosts are not required to reestablish sessions with the external hosts.
出于健壮性、可靠性和负载分配目的，运营商可以部署多个AFTR。在这种情况下，用于构建每个AFTR上配置的隧道机制的IPv6前缀和算法将是相同的。在[RFC6333]中，附录A.3提到高可用性（HA）是运营商的责任。由于DS Lite是一种有状态机制，因此所有负载平衡和故障切换机制的要求都适用。有很多方法可以在有状态机制中实现HA；最常见的是冷备用模式和热备用模式。有关为NAT部署这两种模式的更多讨论，请参见[NAT-STANDBY]。在冷备用模式下，AFTR状态不会从主AFTR复制到备份AFTR。当主AFTR失败时，所有现有的已建立会话将被清除。内部主机需要与外部主机重新建立会话。在热备用模式下，会话状态会从主AFTR动态复制到备份AFTR。当主AFTR失败时，备份AFTR将接管所有现有的已建立会话。在此模式下，内部主机无需与外部主机重新建立会话。
For operators, the decision to use Cold Standby mode or Hot Standby mode depends on the trade-off between capital cost and operational cost. Cold Standby mode does not require a Backup Standby AFTR to synchronize session states. This simplifies the operational model. When the Primary AFTR goes down, any AFTR with extra capacity can take over. Hot Standby mode provides a smoother failover experience to users; the cost for the operators is more careful failover planning. For most deployment scenarios, we believe that Cold Standby mode should be sufficient enough and is thus recommended.
对于运营商而言，使用冷备用模式还是热备用模式取决于资本成本和运营成本之间的权衡。冷备用模式不需要备份备用AFTR来同步会话状态。这简化了操作模型。当主AFTR关闭时，任何具有额外容量的AFTR都可以接管。热备用模式为用户提供更流畅的故障切换体验；运营商的成本是更仔细的故障切换规划。对于大多数部署场景，我们认为冷备用模式应该足够了，因此建议使用冷备用模式。
In the DS-Lite environment, the AFTR is the logical next-hop router of the B4s to access the IPv4 network, so the placement of the AFTR will affect the traffic flows in the access network and overall network design. In general, there are two placement models to deploy an AFTR. Model One deploys the AFTR at the edge of the network to cover a small region. Model Two deploys the AFTR at the core of the network to cover a large region.
在DS Lite环境中，AFTR是B4s接入IPv4网络的逻辑下一跳路由器，因此AFTR的放置将影响接入网络中的流量和整体网络设计。一般来说，部署AFTR有两种布局模型。模型一在网络边缘部署AFTR以覆盖一个小区域。模型二在网络的核心部署AFTR，以覆盖一个大区域。
When an operator considers where to deploy the AFTR, the operator must make trade-offs. The AFTR in Model One serves fewer B4s; thus, it requires a less powerful AFTR. Moreover, the traffic flows are more evenly distributed to the AFTRs. However, it requires deploying more AFTRs to cover the entire network. Often, the operation cost increases proportionally with the amount of network equipment.
当运营商考虑在何处部署AFTR时，运营商必须做出权衡。模型一中的AFTR服务较少的B4；因此，它需要一个功能较弱的AFTR。此外，交通流更均匀地分布到AFTR。然而，它需要部署更多的AFTR来覆盖整个网络。通常，运营成本随着网络设备的数量成比例增加。
The AFTR in Model Two covers a larger area; thus, it serves more B4s. The operator could deploy only a few AFTRs to support the entire user base. However, this model requires a more powerful AFTR to sustain the load at peak hours. Since the AFTR would support B4s from different regions, the AFTR would be deployed closer to the core network.
模式二的AFTR覆盖范围更大；因此，它服务于更多的B4。运营商只能部署几个AFTR来支持整个用户群。然而，这种模式需要更强大的AFTR来维持高峰时段的负荷。由于AFTR将支持来自不同地区的B4，因此AFTR将部署在更靠近核心网络的地方。
DS-Lite framework can be incrementally deployed. An operator may consider starting with Model Two. When the demand increases, the operator can push the AFTR closer to the edge, which would effectively become Model One.
DS Lite框架可以增量部署。操作员可以考虑从模型二开始。当需求增加时，操作员可以将AFTR推近边缘，这将有效地成为模型一。
By centralizing public IPv4 addresses in the AFTR, remote services can no longer rely on an IPv4 address and IPv4 routing information to derive a host's geographical information. For example, the IPv6 access network and the AFTR may be in two different cities. If the remote services rely on the IPv4 address to locate a host, they may have thought the host was in a different city. [RFC6269] Section 7 describes the problem in more detail. Applications could explicitly ask users to enter location information, such as postal code or telephone number, before offering geographical service. In contrast, applications could use HTTP-Enabled Location Delivery (HELD) [RFC5985] to get the location information from the Location Information Server and give this information to the remote peer. [RFC6280] describes an architecture to enable location-based services. However, to mitigate the impact, we recommend that operators deploy the AFTR as close to B4s as possible.
通过在AFTR中集中公共IPv4地址，远程服务不再依赖IPv4地址和IPv4路由信息来获取主机的地理信息。例如，IPv6接入网络和AFTR可能位于两个不同的城市。如果远程服务依赖IPv4地址来定位主机，他们可能认为主机位于不同的城市。[RFC6269]第7节更详细地描述了该问题。应用程序可以明确要求用户在提供地理服务之前输入位置信息，如邮政编码或电话号码。相反，应用程序可以使用启用HTTP的位置传递（HOLD）[RFC5985]从位置信息服务器获取位置信息，并将此信息提供给远程对等方。[RFC6280]描述了支持基于位置的服务的体系结构。然而，为了减轻影响，我们建议运营商将AFTR部署在尽可能靠近B4s的位置。
This section describes the application of [RFC2983] to the DS-Lite deployment model. Operators must ensure that the QoS policy that is in place operates properly within the DS-Lite deployment. In this regard, operators commonly use DSCP [RFC2475] to classify and prioritize different types of traffic in their networks. DS-Lite tunnel can be seen as a particular case of uniform conceptual tunnel model, as described in Section 3.1 of [RFC2983]. The uniform model views an IP tunnel only as a necessary mechanism to forward traffic to its destination: the tunnel has no significant impact on traffic conditioning. In this model, any packet has exactly one DSCP field that is used for traffic conditioning at any point, and it is the field in the outermost IP header. In the DS-Lite model, this is the Traffic Class field in the IPv6 header. According to [RFC2983], implementations of this model copy the DSCP value to the outer IP header at encapsulation and copy the outer header's DSCP value to the inner IP header at decapsulation.
本节介绍[RFC2983]在DS Lite部署模型中的应用。运营商必须确保现有的QoS策略在DS Lite部署中正常运行。在这方面，运营商通常使用DSCP[RFC2475]对其网络中不同类型的流量进行分类和优先级排序。DS Lite隧道可视为统一概念隧道模型的特例，如[RFC2983]第3.1节所述。统一模型仅将IP隧道视为将流量转发到其目的地的必要机制：隧道对流量调节没有显著影响。在该模型中，任何数据包都有一个DSCP字段，用于在任何点进行流量调节，它是最外层IP报头中的字段。在DS Lite模型中，这是IPv6标头中的流量类字段。根据[RFC2983]，此模型的实现在封装时将DSCP值复制到外部IP报头，并在解除封装时将外部报头的DSCP值复制到内部IP报头。
Operators should use this model by provisioning the network such that the AFTR copies the DSCP value in the IPv4 header to the Traffic Class field in the IPv6 header, after the encapsulation for the downstream traffic. Similarly, the B4 copies the DSCP value in the IPv4 header to the Traffic Class field to the IPv6 header, after the encapsulation for the upstream traffic. Traffic identification and classification can be done by examining the outer IPv6 header in the IPv6 access network.
运营商应通过配置网络来使用此模型，以便AFTR在对下游流量进行封装后，将IPv4报头中的DSCP值复制到IPv6报头中的Traffic Class字段。类似地，在对上游流量进行封装之后，B4将IPv4报头中的DSCP值复制到IPv6报头的Traffic Class字段。流量识别和分类可以通过检查IPv6接入网络中的外部IPv6报头来完成。
Some applications behind the B4 require the B4 to accept incoming requests. If the remote application wants to communicate to the application behind the B4, the remote application must know both the NAT-ed IPv4 address used by the B4 and the IPv4 destination port. Some applications use Universal Plug and Play (UPnP) (e.g., popular gaming consoles) or Interactive Community Establishment (ICE) [RFC5245] to request incoming ports. Some applications rely on Application Level Gateway (ALG) or manual port configuration to reserve a port in the NAT. For the DS-Lite deployment scenario whereby the B4 does not own a full IPv4 address, the operator will manage port-forwarding in the serving AFTR. Operators may use Port Control Protocol (PCP) [PCP-BASE] as guidance to provide port forwarding service. Operators will deploy PCP client in the B4s. PCP permits the PCP server to be deployed in a stand-alone server. However, we recommend that operators consider deploying the PCP server in the AFTR. This will ease the overhead to design a global configuration for the PCP server for many AFTRs because each PCP server will be dedicated to the collocated AFTR.
B4后面的一些应用程序要求B4接受传入请求。如果远程应用程序希望与B4后面的应用程序通信，则远程应用程序必须知道B4使用的NAT IPv4地址和IPv4目标端口。一些应用程序使用通用即插即用（UPnP）（例如，流行的游戏控制台）或交互式社区建立（ICE）[RFC5245]来请求传入端口。一些应用程序依靠应用程序级网关（ALG）或手动端口配置在NAT中保留端口。对于B4不拥有完整IPv4地址的DS Lite部署场景，运营商将在服务AFTR中管理端口转发。运营商可以使用端口控制协议（PCP）[PCP-BASE]作为指导来提供端口转发服务。运营商将在B4s中部署PCP客户端。PCP允许在独立服务器中部署PCP服务器。但是，我们建议运营商考虑在AFTR中部署PCP服务器。这将减轻为许多AFTR设计PCP服务器全局配置的开销，因为每个PCP服务器将专用于并置AFTR。
When sharing an IPv4 address, not all of the ports are available to a B4. Some restricted ports (i.e., 0-1023) are well known such as TCP port 25 and 80. Many users may want to be provisioned with the restricted ports. For fairness, we recommend that operators configure the AFTR and not allocate the restricted ports to regular DS-Lite B4s. This operation model ensures that DS-Lite B4s will have uniform configuration, which can simplify provisioning and operation. For users who want to use the restricted ports, operators can consider provisioning a full IPv4 address to those users' B4s. If an operator still wants to provision restricted ports to specific B4s, it may require implementing a static B4's configuration in the AFTR to match the B4's IPv6 address to the NAT rules. Alternatively, the B4 may dynamically allocate the ports, and the AFTR authenticates the session's request using PCP [PCP-BASE].
共享IPv4地址时，并非所有端口都可用于B4。一些受限端口（即0-1023）是众所周知的，例如TCP端口25和80。许多用户可能希望配置受限制的端口。为了公平起见，我们建议运营商配置AFTR，不要将受限端口分配给常规DS Lite B4。此操作模型确保DS Lite B4s具有统一的配置，从而简化资源调配和操作。对于想要使用受限端口的用户，运营商可以考虑向这些用户的B4S提供一个完整的IPv4地址。如果运营商仍希望为特定B4提供受限端口，则可能需要在AFTR中实施静态B4配置，以使B4的IPv6地址与NAT规则相匹配。或者，B4可以动态分配端口，并且AFTR使用PCP[PCP-BASE]认证会话的请求。
[RFC6333], Section 11 describes security issues associated with the DS-Lite mechanism. To restrict the service offered by the AFTR only to registered B4s, an operator can implement the Outgoing Policy on the AFTR's tunnel interface to accept only the IPv6 prefixes defined in the policy. For static provisioning, the operator will need to know in advance the IPv6 prefixes provisioned to the B4s for the softwire in order to configure the policy. To simplify operation, operators should configure the AFTRs in the same region with the same IPv6 prefixes' Outgoing Policy. The AFTRs will accept both regular connections and failover connections from the B4s in the same service region.
[RFC6333]，第11节描述了与DS Lite机制相关的安全问题。为了将AFTR提供的服务仅限于注册的B4，运营商可以在AFTR的隧道接口上实施传出策略，以仅接受策略中定义的IPv6前缀。对于静态配置，运营商需要提前知道为软线配置到B4s的IPv6前缀，以便配置策略。为简化操作，运营商应使用相同IPv6前缀的传出策略在同一地区配置AFTR。AFTR将接受来自同一服务区域中B4的常规连接和故障切换连接。
In environments where the operator wants to deploy the AFTR in an IPv6-only network, the AFTR nodes may not have direct IPv4 connectivity. In this scenario, the operator extends the IPv6-only boundary to the border of the network and only the border routers have IPv4 connectivity. For both scalability and performance purposes, the AFTR is located in the IPv6-only network closer to B4s. In this scenario, the AFTR has only IPv6 connectivity and must be able to send and receive IPv4 packets. Enhancements to the DS-Lite AFTR are required to achieve this. [DS-LITE] describes such issues and enhancements to DS-Lite in IPv6-only deployments.
在运营商希望在仅IPv6网络中部署AFTR的环境中，AFTR节点可能没有直接的IPv4连接。在此场景中，运营商将仅IPv6边界扩展到网络边界，并且只有边界路由器具有IPv4连接。出于可扩展性和性能目的，AFTR位于靠近B4s的仅IPv6网络中。在这种情况下，AFTR只有IPv6连接，必须能够发送和接收IPv4数据包。要实现这一点，需要对DS Lite AFTR进行增强。[DS-LITE]介绍了此类问题以及仅在IPv6部署中对DS-LITE的增强。
In order to configure the IPv4-in-IPv6 tunnel, the B4 needs the IPv6 address of the AFTR. This IPv6 address can be configured using a variety of methods ranging from an out-of-band mechanism, manual configuration, and DHCPv6 option to RADIUS. If an operator uses
为了配置IPv6隧道中的IPv4，B4需要AFTR的IPv6地址。可以使用多种方法配置此IPv6地址，包括带外机制、手动配置、DHCPv6选项和RADIUS。如果操作员使用
DHCPv6 to provision the B4, the B4 must implement the DHCPv6 option defined in [RFC6334]. If an operator uses RADIUS to provision the B4, the B4 must implement [RFC6519].
DHCPv6要提供B4，B4必须实现[RFC6334]中定义的DHCPv6选项。如果操作员使用RADIUS提供B4，B4必须执行[RFC6519]。
[RFC6333] recommends that the B4 send DNS queries to an external recursive resolver over IPv6. The B4 should implement a proxy resolver that will proxy a DNS query from IPv4 transport to the DNS server in the IPv6 network. [RFC6333] does not describe the DNS proxy behavior. In deployment, the operator must ensure that the DNS proxy implementation must follow [RFC5625]. This is important especially for operators who have deployed, or will consider deploying, DNSSEC [RFC4035].
[RFC6333]建议B4通过IPv6向外部递归解析器发送DNS查询。B4应实现代理解析程序，该解析程序将DNS查询从IPv4传输代理到IPv6网络中的DNS服务器。[RFC6333]未描述DNS代理行为。在部署中，运营商必须确保DNS代理实现必须遵循[RFC5625]。这对于部署或将部署DNSSEC[RCF4035]的运营商来说尤其重要。
Some operators may want to give hosts behind the B4 an IPv4 address of an external DNS recursive resolver. The B4 will treat the DNS packets as normal IP packets and forward them over the softwire. Note that there is no effective way to provision an IPv4 DNS address to the B4 over IPv6; operators who use this DNS deployment model must be aware that how to provision an IPv4 DNS address over an IPv6 network is undefined, so it will introduce additional complexity in B4 provisioning. Moreover, this will increase the load to the AFTR by creating entries in the NAT table for DNS sessions. Operators may deploy a local DNS caching resolver in the AFTR to reduce the load in the NAT table. Nonetheless, this DNS model is not covered in [RFC6333] and is not recommended.
一些运营商可能希望为B4后面的主机提供外部DNS递归解析器的IPv4地址。B4将DNS数据包视为普通IP数据包，并通过软线转发它们。注意，没有有效的方法通过IPv6向B4提供IPv4 DNS地址；使用此DNS部署模型的运营商必须知道，如何通过IPv6网络配置IPv4 DNS地址尚未定义，因此这将在B4配置中引入额外的复杂性。此外，这将通过在DNS会话的NAT表中创建条目来增加AFTR的负载。运营商可以在AFTR中部署本地DNS缓存解析器，以减少NAT表中的负载。尽管如此，[RFC6333]并未涵盖此DNS模型，因此不推荐使用。
B4 is connected to the IPv6 access network to offer IPv4 services. When users experience IPv4 connectivity issues, operators must be able to remotely access (e.g., TR-069) the B4 to verify its configuration and status. Operators should access B4s using native IPv6. Operators should not access B4 over the softwire.
B4连接到IPv6接入网络以提供IPv4服务。当用户遇到IPv4连接问题时，运营商必须能够远程访问（例如TR-069）B4以验证其配置和状态。运营商应使用本机IPv6访问B4。操作员不应通过软线访问B4。
The DS-Lite framework provides IPv4 services over the IPv6 access network. Operators and users must be able to check the IPv4 connectivity from the B4 to its AFTR using ping and IPv4 traceroute. The AFTR should be configured with an IPv4 address to enable a PING test and a Traceroute test. Operators should assign the same IPv4 address (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs. IANA has allocated the 192.0.0.0/29 network prefix to provide IPv4 addresses for this purpose [RFC6333].
DS Lite框架通过IPv6访问网络提供IPv4服务。运营商和用户必须能够使用ping和IPv4跟踪路由检查从B4到其AFTR的IPv4连接。AFTR应配置IPv4地址以启用PING测试和跟踪路由测试。运营商应为所有AFTR分配相同的IPv4地址（例如192.0.0.2/32[RFC6333]）。IANA已分配192.0.0.0/29网络前缀，以便为此目的提供IPv4地址[RFC6333]。
This document does not present any new security issues. [RFC6333] discusses DS-Lite related security issues.
本文档不存在任何新的安全问题。[RFC6333]讨论与DS Lite相关的安全问题。
Thanks to Mr. Nejc Skoberne and Dr. Maoke Chen for their thorough review and helpful comments. We also want to thank Mr. Hu Jie for sharing his DS-Lite deployment experience with us. He gave us recommendations of what his company learned while testing DS-Lite in the production network.
Thanks to Mr. Nejc Skoberne and Dr. Maoke Chen for their thorough review and helpful comments. We also want to thank Mr. Hu Jie for sharing his DS-Lite deployment experience with us. He gave us recommendations of what his company learned while testing DS-Lite in the production network.translate error, please retry
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 63342011年8月。
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-Stack Lite", RFC 6519, February 2012.
[RFC6519]Maglione，R.和A.Durand，“双堆栈Lite的半径扩展”，RFC 6519，2012年2月。
[DS-LITE] Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual-Stack Lite in IPv6 Network", Work in Progress, April 2011.
[DS-LITE]Boucadair，M.，Jacquenet，C.，Grimault，J.，Kassi Lahlou，M.，Levis，P.，Cheng，D.，和Y.Lee，“在IPv6网络中部署双栈LITE”，正在进行的工作，2011年4月。
[NAT-REVEAL] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", Work in Progress, March 2013.
[NAT-REVEL]Boucadair，M.，Touch，J.，Levis，P.，和R.Penno，“分析备选解决方案，以揭示共享地址部署中的主机标识符（主机ID）”，正在进行的工作，2013年3月。
[NAT-STANDBY] Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy Requirements and Framework for Stateful Network Address Translators (NAT)", Work in Progress, October 2010.
[NAT-STANDBY]Xu，X.，Boucadair，M.，Lee，Y.，和G.Chen，“有状态网络地址转换器（NAT）的冗余要求和框架”，正在进行的工作，2010年10月。
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, November 2012.
[PCP-BASE]Wing，D.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，正在进行的工作，2012年11月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.translate error, please retry
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.translate error, please retry
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302]Durand，A.，Gashinsky，I.，Lee，D.，和S.Sheppard，“面向Internet服务器的日志记录建议”，BCP 162，RFC 6302，2011年6月。
Authors' Addresses
作者地址
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 U.S.A.
Yiu L.Lee Comcast美国宾夕法尼亚州费城Comcast中心1号，邮编：19103。
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Roberta Maglione Cisco Systems 181 Bay Street Toronto, ON M5J 2T3 Canada
Roberta Maglione思科系统公司位于加拿大多伦多湾街181号M5J 2T3
EMail: robmgl@cisco.com
EMail: robmgl@cisco.com
Carl Williams MCSR Labs U.S.A.
美国卡尔·威廉姆斯MCSR实验室。
EMail: carlw@mcsr-labs.org
EMail: carlw@mcsr-labs.org
Christian Jacquenet France Telecom Rennes France
克里斯蒂安·雅克网法国电信法国雷恩
EMail: christian.jacquenet@orange.com
EMail: christian.jacquenet@orange.com
Mohamed Boucadair France Telecom Rennes France
穆罕默德·布卡达尔法国电信公司法国雷恩
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com