Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6883 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
March 2013
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6883 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
March 2013
IPv6 Guidance for Internet Content Providers and Application Service Providers
互联网内容提供商和应用程序服务提供商的IPv6指南
Abstract
摘要
This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.
本文档为希望同时向IPv6和IPv4客户提供服务的Internet内容提供商和应用程序服务提供商提供指导和建议。其中许多要点也将适用于主机提供商或为IPv6用户准备的任何企业网络。
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/rfc6883.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6883.
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. Introduction ....................................................2
2. General Strategy ................................................3
3. Education and Skills ............................................5
4. Arranging IPv6 Connectivity .....................................6
5. IPv6 Infrastructure .............................................7
5.1. Address and Subnet Assignment ..............................7
5.2. Routing ....................................................8
5.3. DNS ........................................................9
6. Load Balancers .................................................10
7. Proxies ........................................................11
8. Servers ........................................................12
8.1. Network Stack .............................................12
8.2. Application Layer .........................................12
8.3. Logging ...................................................13
8.4. Geolocation ...............................................13
9. Coping with Transition Technologies ............................13
10. Content Delivery Networks .....................................15
11. Business Partners .............................................16
12. Possible Complexities .........................................16
13. Operations and Management .....................................17
14. Security Considerations .......................................18
15. Acknowledgements ..............................................20
16. References ....................................................20
16.1. Normative References .....................................20
16.2. Informative References ...................................22
1. Introduction ....................................................2
2. General Strategy ................................................3
3. Education and Skills ............................................5
4. Arranging IPv6 Connectivity .....................................6
5. IPv6 Infrastructure .............................................7
5.1. Address and Subnet Assignment ..............................7
5.2. Routing ....................................................8
5.3. DNS ........................................................9
6. Load Balancers .................................................10
7. Proxies ........................................................11
8. Servers ........................................................12
8.1. Network Stack .............................................12
8.2. Application Layer .........................................12
8.3. Logging ...................................................13
8.4. Geolocation ...............................................13
9. Coping with Transition Technologies ............................13
10. Content Delivery Networks .....................................15
11. Business Partners .............................................16
12. Possible Complexities .........................................16
13. Operations and Management .....................................17
14. Security Considerations .......................................18
15. Acknowledgements ..............................................20
16. References ....................................................20
16.1. Normative References .....................................20
16.2. Informative References ...................................22
The deployment of IPv6 [RFC2460] is now in progress, and users without direct IPv4 access are likely to appear in increasing numbers in the coming years. Any provider of content or application services over the Internet will need to arrange for IPv6 access or else risk losing large numbers of potential users. For users who already have dual-stack connectivity, direct IPv6 access might provide more satisfactory performance than indirect access via NAT.
IPv6[RFC2460]的部署正在进行中，在未来几年中，没有直接IPv4访问的用户可能会越来越多。任何通过互联网提供内容或应用服务的提供商都需要安排IPv6访问，否则就有可能失去大量潜在用户。对于已经具有双栈连接的用户，直接IPv6访问可能比通过NAT间接访问提供更令人满意的性能。
In this document, we often refer to the users of content or application services as "customers" to clarify the part they play, but this is not intended to limit the scope to commercial sites.
在本文档中，我们通常将内容或应用程序服务的用户称为“客户”，以明确他们所扮演的角色，但这并不是为了将范围限制在商业网站上。
The time for action is now, while the number of IPv6-only customers is small, so that appropriate skills, software, and equipment can be acquired in good time to scale up the IPv6 service as demand increases. An additional advantage of early support for IPv6
现在是采取行动的时候了，而仅限IPv6的客户数量很少，因此可以及时获得适当的技能、软件和设备，以便随着需求的增加扩大IPv6服务的规模。早期支持IPv6的另一个优势
customers is that it will reduce the number of customers connecting later via IPv4 "extension" solutions such as double NAT or NAT64 [RFC6146], which will otherwise degrade the user experience.
客户认为，这将减少以后通过IPv4“扩展”解决方案（如双NAT或NAT64[RFC6146]）连接的客户数量，否则将降低用户体验。
Nevertheless, it is important that the introduction of IPv6 service should not make service for IPv4 customers worse. In some circumstances, technologies intended to assist in the transition from IPv4 to IPv6 are known to have negative effects on the user experience. A deployment strategy for IPv6 must avoid these effects as much as possible.
然而，重要的是，IPv6服务的引入不应使IPv4客户的服务变得更差。在某些情况下，旨在帮助从IPv4过渡到IPv6的技术会对用户体验产生负面影响。IPv6的部署策略必须尽可能避免这些影响。
The purpose of this document is to provide guidance and suggestions for Internet Content Providers (ICPs) and Application Service Providers (ASPs) who wish to offer their services to both IPv6 and IPv4 customers but who are currently supporting only IPv4. For simplicity, the term "ICP" is mainly used in the body of this document, but the guidance also applies to ASPs. Any hosting provider whose customers include ICPs or ASPs is also concerned. Many of the points in this document will also apply to enterprise networks that do not classify themselves as ICPs. Any enterprise or department that runs at least one externally accessible server, such as an HTTP server, may also be concerned. Although specific managerial and technical approaches are described, this is not a rule book; each operator will need to make its own plan, tailored to its own services and customers.
本文档旨在为希望同时向IPv6和IPv4客户提供服务但目前仅支持IPv4的Internet内容提供商（ICP）和应用程序服务提供商（ASP）提供指导和建议。为简单起见，“ICP”一词主要用于本文件正文，但本指南也适用于ASPs。客户包括ICP或ASP的任何托管提供商也会受到关注。本文档中的许多要点也适用于不将自身归类为ICP的企业网络。任何运行至少一个外部可访问服务器（如HTTP服务器）的企业或部门也可能会受到关注。虽然描述了具体的管理和技术方法，但这不是一本规则手册；每个运营商都需要根据自己的服务和客户制定自己的计划。
The most important advice here is to actually have a general strategy. Adding support for a second network-layer protocol is a new experience for most modern organizations, and it cannot be done casually on an unplanned basis. Even if it is impossible to write a precisely dated plan, the intended steps in the process need to be defined well in advance. There is no single blueprint for this. The rest of this document is meant to provide a set of topics to be taken into account in defining the strategy. Other documents about IPv6 deployment, such as [IPv6-NETWORK-DESIGN], should be consulted as well.
这里最重要的建议是制定一个总体战略。添加对第二网络层协议的支持对于大多数现代组织来说都是一种新的体验，不能在计划外的基础上随意进行。即使不可能写一份精确注明日期的计划，也需要提前确定过程中的预期步骤。这方面没有单一的蓝图。本文档的其余部分旨在提供一组在定义策略时要考虑的主题。有关IPv6部署的其他文件，如[IPv6网络设计]，也应参考。
In determining the urgency of this strategy, it should be noted that the central IPv4 registry (IANA) ran out of spare blocks of IPv4 addresses in February 2011, and the various regional registries are expected to exhaust their reserves over the next one to two years. After this, Internet Service Providers (ISPs) will run out at dates determined by their own customer base. No precise date can be given for when IPv6-only customers will appear in commercially significant
在确定这一战略的紧迫性时，应注意的是，中央IPv4注册中心（IANA）在2011年2月用完了IPv4地址的备用块，各区域注册中心预计将在未来一到两年耗尽其储备。在此之后，互联网服务提供商（ISP）将在其客户群确定的日期用完。无法给出仅限IPv6的客户何时会出现在具有商业意义的市场上的确切日期
numbers, but -- particularly in the case of mobile users -- it may be quite soon. Complacency about this is therefore not an option for any ICP that wishes to grow its customer base over the coming years.
数字，但——特别是在移动用户的情况下——可能很快就会出现。因此，任何希望在未来几年扩大客户群的国际比较项目都不能对此感到自满。
The most common strategy for an ICP is to provide dual-stack services -- both IPv4 and IPv6 on an equal basis -- to cover both existing and future customers. This is the recommended strategy in [RFC6180] for straightforward situations. Some ICPs who already have satisfactory operational experience with IPv6 might consider an IPv6-only strategy, with IPv4 clients being supported by translation or proxy in front of their IPv6 content servers. However, the present document is addressed to ICPs without IPv6 experience, who are likely to prefer the dual-stack model to build on their existing IPv4 service.
ICP最常见的策略是提供双栈服务——在平等的基础上提供IPv4和IPv6——以覆盖现有和未来的客户。这是[RFC6180]中针对简单情况的推荐策略。一些已经具备了IPv6的操作经验的ICP可能考虑IPv6的唯一策略，IPv4客户端在IPv6内容服务器的前面通过翻译或代理来支持。然而，本文档针对的是没有IPv6经验的ICP，他们可能更喜欢双栈模型，以现有IPv4服务为基础。
Due to the widespread impact of supporting IPv6 everywhere within an environment, it is important to select a focused initial approach based on clear business needs and real technical dependencies.
由于支持IPv6在环境中的任何地方都会产生广泛的影响，因此根据明确的业务需求和实际的技术依赖性选择一种有重点的初始方法是很重要的。
Within the dual-stack model, two approaches could be adopted, sometimes referred to as "outside in" and "inside out":
在双堆栈模型中，可采用两种方法，有时称为“外-内”和“内-外”：
o Outside in: Start by providing external users with an IPv6 public access to your services, for example, by running a reverse proxy that handles IPv6 customers (see Section 7 for details). Progressively enable IPv6 internally.
o 由外到内：首先为外部用户提供对您的服务的IPv6公共访问，例如，通过运行处理IPv6客户的反向代理（有关详细信息，请参阅第7节）。逐步在内部启用IPv6。
o Inside out: Start by enabling internal networking infrastructure, hosts, and applications to support IPv6. Progressively reveal IPv6 access to external customers.
o 由内而外：首先启用内部网络基础设施、主机和应用程序以支持IPv6。逐步向外部客户展示IPv6访问。
Which of these approaches to choose depends on the precise circumstances of the ICP concerned. "Outside in" has the benefit of giving interested customers IPv6 access at an early stage, and thereby gaining precious operational experience, before meticulously updating every piece of equipment and software. For example, if some back-office system that is never exposed to users only supports IPv4, it will not cause delay. "Inside out" has the benefit of completing the implementation of IPv6 as a single project. Any ICP could choose this approach, but it might be most appropriate for a small ICP without complex back-end systems.
选择哪种方法取决于相关ICP的具体情况。“由外而内”的好处是，在对每一台设备和软件进行精心更新之前，尽早为感兴趣的客户提供IPv6接入，从而获得宝贵的运营经验。例如，如果某些从不向用户公开的后台系统只支持IPv4，则不会导致延迟。“由内而外”的好处是将IPv6的实施作为一个单独的项目来完成。任何ICP都可以选择这种方法，但它可能最适合于没有复杂后端系统的小型ICP。
A point that must be considered in the strategy is that some customers will remain IPv4-only for many years, others will have both IPv4 and IPv6 access, and yet others will have only IPv6. Additionally, mobile customers may find themselves switching between IPv4 and IPv6 access as they travel, even within a single session.
该战略中必须考虑的一点是，一些客户将只保留IPv4多年，其他客户将同时具有IPv4和IPv6访问权限，而其他客户将仅具有IPv6。此外，移动客户可能会发现自己在旅行时在IPv4和IPv6访问之间切换，即使在单个会话中也是如此。
Services and applications must be able to deal with this, just as easily as they deal today with a user whose IPv4 address changes (see the discussion of cookies in Section 8.2).
服务和应用程序必须能够处理这一问题，就像今天处理IPv4地址发生变化的用户一样简单（请参阅第8.2节中有关cookie的讨论）。
Nevertheless, the end goal is to have a network that does not need major changes when at some point in the future it becomes possible to transition to IPv6-only, even if only for some parts of the network. That is, the IPv6 deployment should be designed in such a way as to more or less assume that IPv4 is already absent, so the network will function seamlessly when it is indeed no longer there.
尽管如此，最终目标是拥有一个不需要重大更改的网络，在将来的某个时候，它可以仅过渡到IPv6，即使只过渡到网络的某些部分。也就是说，IPv6部署的设计应该或多或少地假设IPv4已经不存在，因此当IPv4确实不存在时，网络将无缝运行。
An important step in the strategy is to determine from hardware and software suppliers details of their planned dates for providing sufficient IPv6 support, with performance equivalent to IPv4, in their products and services. Relevant specifications such as [RFC6434] and [IPv6-CE-REQS] should be used. Even if complete information cannot be obtained, it is essential to determine which components are on the critical path during successive phases of deployment. This information will make it possible to draw up a logical sequence of events and identify any components that may cause holdups.
该战略中的一个重要步骤是从硬件和软件供应商处确定其在产品和服务中提供足够IPv6支持（性能相当于IPv4）的计划日期细节。应使用相关规范，如[RFC6434]和[IPv6 CE REQS]。即使无法获得完整信息，也必须确定在后续部署阶段哪些组件位于关键路径上。这些信息将有助于制定事件的逻辑顺序，并确定可能导致滞留的任何部件。
Some staff may have experience running multiprotocol networks, which were common twenty years ago before the dominance of IPv4. However, IPv6 will be new to them and also to staff brought up only on TCP/IP. It is not enough to have one "IPv6 expert" in a team. On the contrary, everybody who knows about IPv4 needs to know about IPv6, from network architect to help desk responder. Therefore, an early and essential part of the strategy must be education, including practical training, so that all staff acquire a general understanding of IPv6, how it affects basic features such as the DNS, and the relevant practical skills. To take a trivial example, any staff used to dotted-decimal IPv4 addresses need to become familiar with the colon-hexadecimal format used for IPv6.
一些员工可能有运行多协议网络的经验，这在IPv4占主导地位的二十年前很常见。然而，IPv6对他们来说是新的，对那些只在TCP/IP上长大的员工来说也是新的。团队中只有一名“IPv6专家”是不够的。相反，了解IPv4的每个人都需要了解IPv6，从网络架构师到帮助台响应者。因此，该战略的早期和基本部分必须是教育，包括实践培训，以便所有员工都能大致了解IPv6、它如何影响DNS等基本功能以及相关的实践技能。举一个简单的例子，任何使用点十进制IPv4地址的员工都需要熟悉IPv6使用的冒号十六进制格式。
There is an anecdote of one IPv6 deployment in which prefixes including the letters A to F were avoided by design, to avoid confusing system administrators unfamiliar with hexadecimal notation. This is not a desirable result. There is another anecdote of a help desk responder telling a customer to "disable one-Pv6" in order to solve a problem. It should be a goal to avoid having untrained staff who don't understand hexadecimal or who can't even spell "IPv6".
有一个关于IPv6部署的轶事，其中通过设计避免了前缀（包括字母A到F），以避免让不熟悉十六进制表示法的系统管理员感到困惑。这不是一个理想的结果。还有一个轶事是，一位服务台响应人员告诉客户“禁用one-Pv6”以解决问题。目标应该是避免未经培训的员工不懂十六进制或甚至不会拼写“IPv6”。
It is very useful to have a small laboratory network available for training and self-training in IPv6, where staff may experiment and make mistakes without disturbing the operational IPv4 service. This lab should run both IPv4 and IPv6, to gain experience with a dual-stack environment and new features such as having multiple addresses per interface, and addresses with lifetimes and deprecation.
有一个小型实验室网络可用于IPv6的培训和自我培训是非常有用的，在这里，工作人员可以在不干扰IPv4服务的情况下进行实验并犯错误。本实验室应同时运行IPv4和IPv6，以获得双堆栈环境的经验和新功能，如每个接口具有多个地址，以及具有生存期和弃用的地址。
Once staff are trained, they will likely need to support IPv4, IPv6, and dual-stack customers. Rather than having separate internal escalation paths for IPv6, it generally makes sense for questions that may have an IPv6 element to follow normal escalation paths; there should not be an "IPv6 Department" once training is completed.
一旦员工接受培训，他们可能需要支持IPv4、IPv6和双栈客户。与IPv6有单独的内部升级路径不同的是，对于可能有IPv6元素的问题，遵循正常的升级路径通常是有意义的；培训结束后，不应设立“IPv6部门”。
A final remark about training is that it should not be given too soon, or it will be forgotten. Training has a definite need to be done "just in time" in order to properly "stick". Training, lab experience, and actual deployment should therefore follow each other immediately. If possible, training should even be combined with actual operational experience.
关于培训的最后一点意见是，培训不应过早进行，否则将被遗忘。培训必须“及时”完成，以便正确地“坚持”。因此，培训、实验室经验和实际部署应立即相互跟进。如果可能，培训甚至应与实际操作经验相结合。
There are, in theory, two ways to obtain IPv6 connectivity to the Internet.
从理论上讲，有两种方法可以实现IPv6与Internet的连接。
o Native. In this case, the ISP simply provides IPv6 on exactly the same basis as IPv4 -- it will appear at the ICP's border router(s), which must then be configured in dual-stack mode to forward IPv6 packets in both directions. This is by far the better method. An ICP should contact all its ISPs to verify when they will provide native IPv6 support, whether this has any financial implications, and whether the same service level agreement will apply as for IPv4. Any ISP that has no definite plan to offer native IPv6 service should be avoided.
o 出生地的在这种情况下，ISP只是在与IPv4完全相同的基础上提供IPv6——它将出现在ICP的边界路由器上，然后必须将其配置为双堆栈模式，以便在两个方向转发IPv6数据包。这是迄今为止更好的方法。ICP应联系其所有ISP，以验证他们何时提供本机IPv6支持，这是否有任何财务影响，以及是否将适用与IPv4相同的服务级别协议。应该避免任何没有明确计划提供本机IPv6服务的ISP。
o Managed Tunnel. It is possible to configure an IPv6-in-IPv4 tunnel to a remote ISP that offers such a service. A dual-stack router in the ICP's network will act as a tunnel endpoint, or this function could be included in the ICP's border router.
o 管理隧道。可以将IPv6-in-IPv4隧道配置到提供此类服务的远程ISP。ICP网络中的双栈路由器将充当隧道端点，或者该功能可包含在ICP边界路由器中。
A managed tunnel is a reasonable way to obtain IPv6 connectivity for initial testing and skills acquisition. However, it introduces an inevitable extra latency compared to native IPv6, giving customers a noticeably worse response time for complex web pages. A tunnel may become a performance bottleneck (especially if offered as a free service) or a target for malicious attack.
托管隧道是获得IPv6连接以进行初始测试和获取技能的合理方式。然而，与本机IPv6相比，它不可避免地引入了额外的延迟，使客户对复杂网页的响应时间明显缩短。隧道可能成为性能瓶颈（特别是作为免费服务提供时）或恶意攻击的目标。
It is also likely to limit the IPv6 MTU size. In normal circumstances, native IPv6 will provide an MTU size of at least 1500 bytes, but it will almost inevitably be less for a tunnel, possibly as low as 1280 bytes (the minimum MTU allowed for IPv6). Apart from the resulting loss of efficiency, there are cases in which Path MTU Discovery fails and IPv6 fragmentation therefore fails; in this case, the lower tunnel MTU will actually cause connectivity failures for customers.
它还可能限制IPv6 MTU的大小。在正常情况下，本机IPv6将提供至少1500字节的MTU大小，但对于隧道来说几乎不可避免地会更小，可能低至1280字节（IPv6允许的最小MTU）。除了由此导致的效率损失外，还存在路径MTU发现失败，IPv6分段因此失败的情况；在这种情况下，较低的隧道MTU实际上会导致客户的连接故障。
For these reasons, ICPs are strongly recommended to obtain native IPv6 service before attempting to offer a production-quality service to their customers. Unfortunately, it is impossible to prevent customers from using unmanaged tunnel solutions (see Section 9).
出于这些原因，强烈建议ICP在尝试向其客户提供生产质量服务之前获得本机IPv6服务。不幸的是，无法阻止客户使用非托管隧道解决方案（请参见第9节）。
Some larger organizations may find themselves needing multiple forms of IPv6 connectivity, for their ICP data centers and for their staff working elsewhere. It is important to obtain IPv6 connectivity for both, as testing and supporting an IPv6-enabled service is challenging for staff without IPv6 connectivity. This may involve short-term alternatives to provide IPv6 connectivity to operations and support staff, such as a managed tunnel or HTTP proxy server with IPv6 connectivity. Note that unmanaged tunnels (such as 6to4 and Teredo) are generally not useful for support staff, as recent client software will avoid them when accessing dual-stack sites.
一些较大的组织可能会发现，他们的ICP数据中心和在其他地方工作的员工需要多种形式的IPv6连接。获得两者的IPv6连接非常重要，因为对于没有IPv6连接的员工来说，测试和支持支持支持IPv6的服务是一项挑战。这可能涉及向运营和支持人员提供IPv6连接的短期替代方案，例如具有IPv6连接的托管隧道或HTTP代理服务器。请注意，非托管隧道（如6to4和Teredo）通常对支持人员没有用处，因为最新的客户端软件在访问双堆栈站点时会避免使用它们。
An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix for IPv6. This option is available either from an ISP that acts as a Local Internet Registry or directly from the relevant Regional Internet Registry. The alternative is to obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However, the scaling properties of the wide-area routing system (BGP-4) mean that the number of PI prefixes should be limited, so only large content providers can justify obtaining a PI prefix and convincing their ISPs to route it. Millions of enterprise networks, including smaller content providers, will use PA prefixes. In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using the procedure outlined in [RFC4192].
ICP必须首先决定是否为IPv6申请自己的独立于提供商（PI）地址前缀。此选项可以从作为本地Internet注册中心的ISP处获得，也可以直接从相关的区域Internet注册中心获得。另一种方法是从ISP获取提供商聚合（PA）前缀。这两种解决方案在IPv6中都是可行的。然而，广域路由系统（BGP-4）的扩展特性意味着PI前缀的数量应该受到限制，因此只有大型内容提供商才有理由获得PI前缀并说服其ISP对其进行路由。包括小型内容提供商在内的数百万企业网络将使用PA前缀。在这种情况下，ISP的更改将需要使用[RFC4192]中概述的程序更改相应的PA前缀。
An ICP that has connections via multiple ISPs but does not have a PI prefix would therefore have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers or load balancers. If one address fails due to an ISP malfunction, sessions using that address would be lost. At the time of this writing, there is very limited operational experience with this approach [MULTIHOMING-WITHOUT-NAT].
因此，通过多个ISP连接但没有PI前缀的ICP将具有多个PA前缀，每个ISP一个。这将导致ICP的服务器或负载平衡器具有多个IPv6地址。如果一个地址由于ISP故障而失败，使用该地址的会话将丢失。在撰写本文时，这种方法[无NAT的多宿]的运行经验非常有限。
An ICP may also choose to operate a Unique Local Address prefix [RFC4193] for internal traffic only, as described in [RFC4864].
ICP也可以选择仅为内部通信操作唯一的本地地址前缀[RFC4193]，如[RFC4864]所述。
Depending on its projected future size, an ICP might choose to obtain /48 PI or PA prefixes (allowing 16 bits of subnet address) or longer PA prefixes, e.g., /56 (allowing 8 bits of subnet address). Clearly, the choice of /48 is more future-proof. Advice on the numbering of subnets may be found in [RFC5375]. An ICP with multiple locations will probably need a prefix per location.
根据其预计的未来大小，ICP可能选择获得/48 PI或PA前缀（允许16位子网地址）或更长的PA前缀，例如/56（允许8位子网地址）。显然，选择/48更能证明未来。有关子网编号的建议，请参见[RFC5375]。具有多个位置的ICP可能需要每个位置的前缀。
An ICP that has its service hosted by a colocation provider, cloud provider, or the like will need to follow the addressing policy of that provider.
由托管提供商、云提供商等托管服务的ICP需要遵循该提供商的寻址策略。
Since IPv6 provides for operating multiple prefixes simultaneously, it is important to check that all relevant tools, such as address management packages, can deal with this. In particular, the possible need to allow for multiple PA prefixes with IPv6, and the possible need to renumber, mean that the common technique of manually assigned static addresses for servers, proxies, or load balancers, with statically defined DNS entries, could be problematic [RFC6866]. An ICP of reasonable size might instead choose to operate DHCPv6 [RFC3315] with standard DNS, to support stateful assignment. In either case, a configuration management system is likely to be used to support stateful and/or on-demand address assignment.
由于IPv6提供了同时操作多个前缀的功能，因此检查所有相关工具（如地址管理包）是否能够处理这一问题非常重要。特别是，可能需要允许使用IPv6的多个PA前缀，以及可能需要重新编号，这意味着使用静态定义的DNS条目为服务器、代理或负载平衡器手动分配静态地址的常见技术可能存在问题[RFC6866]。合理规模的ICP可能会选择使用标准DNS操作DHCPv6[RFC3315]，以支持有状态分配。无论哪种情况，配置管理系统都可能用于支持有状态和/或按需地址分配。
Theoretically, it would also be possible to operate an ICP's IPv6 network using only Stateless Address Autoconfiguration [RFC4862], with Dynamic DNS [RFC3007] to publish server addresses for external users.
理论上，也可以只使用无状态地址自动配置[RFC4862]和动态DNS[RFC3007]来为外部用户发布服务器地址，从而操作ICP的IPv6网络。
In a dual-stack network, most IPv4 and IPv6 interior routing protocols operate quite independently and in parallel. The common routing protocols, such as OSPFv3 [RFC5340], IS-IS [RFC5308], and even the Routing Information Protocol Next Generation (RIPng) [RFC2080] [RFC2081], all support IPv6. It is worth noting that whereas OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the advantage of handling them both in a single instance of
在双栈网络中，大多数IPv4和IPv6内部路由协议都是独立并行运行的。常见的路由协议，如OSPFv3[RFC5340]，IS-IS[RFC5308]，甚至下一代路由信息协议（RIPng）[RFC2080][RFC2081]，都支持IPv6。值得注意的是，尽管IPv4和IPv6之间的OSPF和RIP存在显著差异，但is-is的优势是在单个实例中处理它们
the protocol, with the potential for operational simplification in the long term. Some versions of OSPFv3 may also have this advantage [RFC5838]. In any case, for trained staff, there should be no particular difficulty in deploying IPv6 routing without disturbance to IPv4 services. In some cases, firmware upgrades may be needed on some network devices.
该协议具有长期简化操作的潜力。某些版本的OSPFv3也可能具有此优势[RFC5838]。在任何情况下，对于训练有素的员工来说，在不干扰IPv4服务的情况下部署IPv6路由应该不会有特别的困难。在某些情况下，某些网络设备可能需要固件升级。
The performance impact of dual-stack routing needs to be evaluated. In particular, what forwarding performance does the router vendor claim for IPv6? If the forwarding performance is significantly inferior compared to IPv4, will this be an operational problem? Is extra memory or ternary content-addressable memory (TCAM) space needed to accommodate both IPv4 and IPv6 tables? To answer these questions, the ICP will need a projected model for the amount of IPv6 traffic expected initially and its likely rate of increase.
需要评估双堆栈路由的性能影响。特别是，路由器供应商声称IPv6具有什么样的转发性能？如果转发性能明显低于IPv4，这会是一个操作问题吗？是否需要额外的内存或三元内容寻址内存（TCAM）空间来容纳IPv4和IPv6表？为了回答这些问题，国际比较项目将需要一个预测模型，用于预测最初预期的IPv6通信量及其可能的增长率。
If a site has multiple PA prefixes as mentioned in Section 5.1, complexities in routing configuration will appear. In particular, source-based routing rules might be needed to ensure that outgoing packets are routed to the appropriate border router and ISP link. Normally, a packet sourced from an address assigned by ISP X should not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] [RFC3704]. Additional considerations may be found in [MULTIHOMING-WITHOUT-NAT]. Note that the prefix translation technique discussed in [RFC6296] does not describe a solution for enterprises that offer publicly available content servers.
如第5.1节所述，如果一个站点有多个PA前缀，路由配置将出现复杂性。特别是，可能需要基于源的路由规则来确保传出数据包路由到适当的边界路由器和ISP链路。通常情况下，来自ISP X分配的地址的数据包不应通过ISP Y发送，以避免Y[RFC2827][RFC3704]过滤进入。其他注意事项可在[无NAT的多址通信]中找到。请注意，[RFC6296]中讨论的前缀转换技术并没有描述为提供公共内容服务器的企业提供的解决方案。
Each IPv6 subnet that supports end hosts normally has a /64 prefix, leaving another 64 bits for the interface identifiers of individual hosts. In contrast, a typical IPv4 subnet will have no more than 8 bits for the host identifier, thus limiting the subnet to 256 or fewer hosts. A dual-stack design will typically use the same physical or VLAN subnet topology for IPv4 and IPv6, and therefore the same router topology. In other words, the IPv4 and IPv6 topologies are congruent. This means that the limited subnet size of IPv4 (such as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix will allow many more hosts. It would be theoretically possible to avoid this limitation by implementing a different physical or VLAN subnet topology for IPv6. This is not advisable, as it would result in extremely complex fault diagnosis when something went wrong.
支持终端主机的每个IPv6子网通常都有一个/64前缀，为各个主机的接口标识符保留另一个64位。相比之下，典型的IPv4子网的主机标识符不超过8位，因此将子网限制为256个或更少的主机。对于IPv4和IPv6，双栈设计通常使用相同的物理或VLAN子网拓扑，因此使用相同的路由器拓扑。换句话说，IPv4和IPv6拓扑是一致的。这意味着IPv4的有限子网大小（例如256个主机）将强制应用于IPv6，即使IPv6前缀将允许更多主机。理论上可以通过为IPv6实现不同的物理或VLAN子网拓扑来避免这种限制。这是不可取的，因为当出现故障时，这将导致极其复杂的故障诊断。
It must be understood that as soon as a AAAA record for a well-known name is published in the DNS, the corresponding server will start to receive IPv6 traffic. Therefore, it is essential that an ICP test thoroughly to ensure that IPv6 works on its servers, load balancers, etc., before adding their AAAA records to DNS. There have been
必须理解的是，一旦在DNS中发布了知名名称的AAAA记录，相应的服务器将开始接收IPv6流量。因此，在将其AAAA记录添加到DNS之前，必须进行全面的ICP测试，以确保IPv6在其服务器、负载平衡器等上工作。有
numerous cases of ICPs breaking their sites for all IPv6 users during a roll-out by returning AAAA records for servers improperly configured for IPv6.
在推出期间，ICP通过返回未正确配置IPv6的服务器的AAAA记录，为所有IPv6用户破坏其站点的大量案例。
Once such tests have succeeded, each externally visible host (or virtual host) that has an A record for its IPv4 address needs a AAAA record [RFC3596] for its IPv6 address, and a reverse entry (in ip6.arpa) if applicable. Note that if CNAME records are in use, the AAAA record must be added alongside the A record at the end of the CNAME chain. It is not possible to have the AAAA record on the same name as used for a CNAME record, as per [RFC1912].
一旦此类测试成功，每个具有IPv4地址A记录的外部可见主机（或虚拟主机）需要其IPv6地址的AAAA记录[RFC3596]，如果适用，还需要一个反向条目（在ip6.arpa中）。请注意，如果正在使用CNAME记录，则必须将AAAA记录添加到CNAME链末尾的A记录旁边。根据[RFC1912]，AAAA记录不可能与CNAME记录使用的名称相同。
One important detail is that some clients (especially Windows XP) can only resolve DNS names via IPv4, even if they can use IPv6 for application traffic. Also, a dual-stack resolver might attempt to resolve queries for A records via IPv6, or AAAA records via IPv4. It is therefore advisable for all DNS servers to respond to queries via both IPv4 and IPv6.
一个重要的细节是，某些客户端（尤其是Windows XP）只能通过IPv4解析DNS名称，即使它们可以使用IPv6进行应用程序通信。此外，双堆栈解析器可能会尝试通过IPv6解析记录查询，或通过IPv4解析AAAA记录查询。因此，建议所有DNS服务器通过IPv4和IPv6响应查询。
Most available load balancers now support IPv6. However, it is important to obtain appropriate assurances from vendors about their IPv6 support, including performance aspects (as discussed for routers in Section 5.2). The update needs to be planned in anticipation of expected traffic growth. It is to be expected that IPv6 traffic will initially be low, i.e., a small but growing percentage of total traffic. For this reason, it might be acceptable to have IPv6 traffic bypass load balancing initially, by publishing a AAAA record for a specific server instead of the load balancer. However, load balancers often also provide for server fail-over, in which case it would be better to implement IPv6 load balancing immediately.
大多数可用的负载平衡器现在都支持IPv6。但是，从供应商处获得有关其IPv6支持的适当保证，包括性能方面，这一点很重要（如第5.2节中针对路由器所讨论的）。更新需要在预期流量增长的情况下进行规划。预计IPv6流量最初将很低，即占总流量的比例很小，但在不断增长。出于这个原因，最初可以通过发布特定服务器的AAAA记录而不是负载平衡器，让IPv6流量绕过负载平衡。然而，负载平衡器通常还提供服务器故障转移，在这种情况下，最好立即实现IPv6负载平衡。
The same would apply to Transport Layer Security (TLS) or HTTP proxies used for load-balancing purposes.
这同样适用于用于负载平衡目的的传输层安全性（TLS）或HTTP代理。
An HTTP proxy [RFC2616] can readily be configured to handle incoming connections over IPv6 and to proxy them to a server over IPv4. Therefore, a single proxy can be used as the first step in an outside-in strategy, as shown in the following diagram:
HTTP代理[RFC2616]可以很容易地配置为通过IPv6处理传入连接，并通过IPv4将它们代理到服务器。因此，可以使用单个代理作为由外到内策略的第一步，如下图所示：
___________________________________________
( )
( IPv6 Clients in the Internet )
(___________________________________________)
|
-------------
| Ingress |
| router |
-------------
____________|_____________
|
-------------
| IPv6 stack|
|-----------|
| HTTP proxy|
|-----------|
| IPv4 stack|
-------------
____________|_____________
|
-------------
| IPv4 stack|
|-----------|
| HTTP |
| server |
-------------
___________________________________________
( )
( IPv6 Clients in the Internet )
(___________________________________________)
|
-------------
| Ingress |
| router |
-------------
____________|_____________
|
-------------
| IPv6 stack|
|-----------|
| HTTP proxy|
|-----------|
| IPv4 stack|
-------------
____________|_____________
|
-------------
| IPv4 stack|
|-----------|
| HTTP |
| server |
-------------
In this case, the AAAA record for the service would provide the IPv6 address of the proxy. This approach will work for any HTTP or HTTPS applications that operate successfully via a proxy, as long as IPv6 load remains low. Additionally, many load-balancer products incorporate such a proxy, in which case this approach would be possible at high load.
在这种情况下，服务的AAAA记录将提供代理的IPv6地址。只要IPv6负载保持较低，这种方法将适用于通过代理成功运行的任何HTTP或HTTPS应用程序。此外，许多负载平衡器产品都包含这样的代理，在这种情况下，这种方法在高负载下是可能的。
Note that in any proxy scenario, an ICP will need to make sure that both IPv4 and IPv6 addresses are being properly passed to application servers in any relevant HTTP headers and that those application servers are properly handling the IPv6 addresses.
请注意，在任何代理场景中，ICP都需要确保IPv4和IPv6地址在任何相关HTTP头中正确传递给应用服务器，并且这些应用服务器正确处理IPv6地址。
The TCP/IP network stacks in popular operating systems have supported IPv6 for many years. In most cases, it is sufficient to enable IPv6 and possibly DHCPv6; the rest will follow. Servers inside an ICP network will not need to support any transition technologies beyond a simple dual stack, with a possible exception for 6to4 mitigation noted below in Section 9.
流行操作系统中的TCP/IP网络栈多年来一直支持IPv6。在大多数情况下，启用IPv6和DHCPv6就足够了；其余的都会随之而来。ICP网络内的服务器不需要支持简单双堆栈以外的任何过渡技术，第9节中提到的6to4缓解可能例外。
As some operating systems have separate firewall rule sets for IPv4 and IPv6, an ICP should also evaluate those rule sets and ensure that appropriate firewall rules are configured for IPv6. More details are discussed in Section 14.
由于某些操作系统具有单独的IPv4和IPv6防火墙规则集，ICP还应评估这些规则集，并确保为IPv6配置了适当的防火墙规则。更多细节将在第14节中讨论。
Basic HTTP servers have been able to handle an IPv6-enabled network stack for some years, so at the most it will be necessary to update to a more recent software version. The same is true of generic applications such as email protocols. No general statement can be made about other applications, especially proprietary ones, so each ASP will need to make its own determination. As changes to the network layer to introduce IPv6 addresses can ripple through applications, testing of both client and server applications should be performed in IPv4-only, IPv6-only, and dual-stack environments prior to dual-stacking a production environment.
一些年来，基本HTTP服务器已经能够处理支持IPv6的网络堆栈，因此最多需要更新到更新的软件版本。电子邮件协议等通用应用程序也是如此。对于其他应用程序，尤其是专有应用程序，不能做出一般性的声明，因此每个ASP都需要自己做出决定。由于引入IPv6地址的网络层更改可能会影响应用程序，因此在生产环境中进行双堆栈之前，应在仅IPv4、仅IPv6和双堆栈环境中对客户端和服务器应用程序进行测试。
One important recommendation here is that all applications should use domain names, which are IP-version-independent, rather than IP addresses. Applications based on middleware platforms that have uniform support for IPv4 and IPv6, for example, Java, may be able to support both IPv4 and IPv6 naturally without additional work. Security certificates should also contain domain names rather than addresses.
这里的一个重要建议是，所有应用程序都应该使用独立于IP版本的域名，而不是IP地址。基于统一支持IPv4和IPv6的中间件平台的应用程序（例如Java）可以自然地支持IPv4和IPv6，而无需额外工作。安全证书还应包含域名而不是地址。
A specific issue for HTTP-based services is that IP address-based cookie authentication schemes will need to deal with dual-stack clients. Servers might create a cookie for an IPv4 connection or an IPv6 connection, depending on the setup at the client site and on the whims of the client operating system. There is no guarantee that a given client will consistently use the same address family, especially when accessing a collection of sites rather than a single site, such as when cookies are used for federated authentication. If the client is using privacy addresses [RFC4941], the IPv6 address
基于HTTP的服务的一个具体问题是，基于IP地址的cookie身份验证方案将需要处理双堆栈客户端。服务器可能会为IPv4连接或IPv6连接创建cookie，具体取决于客户端站点的设置和客户端操作系统的突发奇想。无法保证给定的客户端将始终使用相同的地址系列，特别是在访问站点集合而不是单个站点时，例如当cookie用于联合身份验证时。如果客户端使用的是隐私地址[RFC4941]，则IPv6地址
(but usually not its /64 prefix) might change quite frequently. Any cookie mechanism based on 32-bit IPv4 addresses will need significant remodeling.
（但通常不是其/64前缀）可能会经常更改。任何基于32位IPv4地址的cookie机制都需要进行重大重构。
Generic considerations on application transition are discussed in [RFC4038], but many of them will not apply to the dual-stack ICP scenario. An ICP that creates and maintains its own applications will need to review them for any dependency on IPv4.
[RFC4038]中讨论了应用程序转换的一般注意事项，但其中许多注意事项不适用于双堆栈ICP场景。创建和维护自己的应用程序的ICP需要检查它们是否依赖于IPv4。
The introduction of IPv6 clients will generally also result in IPv6 addresses appearing in the "client ip" field of server logs. It might be convenient to use the same log field to hold a client's IP address, whether it is IPv4 or IPv6. Downstream systems looking at logs and client IP addresses may also need testing to ensure that they can properly handle IPv6 addresses. This includes any of an ICP's databases recording client IP addresses, such as for recording IP addresses of online purchases and comment posters.
IPv6客户端的引入通常也会导致IPv6地址出现在服务器日志的“客户端ip”字段中。使用相同的日志字段来保存客户端的IP地址（无论是IPv4还是IPv6）可能比较方便。查看日志和客户端IP地址的下游系统可能还需要测试，以确保它们能够正确处理IPv6地址。这包括记录客户IP地址的ICP数据库，例如用于记录在线购买和评论海报的IP地址。
It is worth noting that accurate traceback from logs to individual customers requires end-to-end address transparency. This is additional motivation for an ICP to support native IPv6 connectivity, since otherwise, IPv6-only customers will inevitably connect via some form of translation mechanism, interfering with traceback.
值得注意的是，从日志到单个客户的准确回溯需要端到端的地址透明性。这是ICP支持本机IPv6连接的另一个动机，因为否则，仅IPv6的客户将不可避免地通过某种形式的转换机制进行连接，从而干扰回溯。
Initially, ICPs may observe some weakness in geolocation for IPv6 clients. As time goes on, it is to be assumed that geolocation methods and databases will be updated to fully support IPv6 prefixes. There is no reason they will be more or less accurate in the long term than those available for IPv4. However, we can expect many more clients to be mobile as time goes on, so geolocation based on IP addresses alone may in any case become problematic. A more robust technique such as HTTP-Enabled Location Delivery (HELD) [RFC5985] could be considered.
最初，ICP可能会发现IPv6客户端在地理定位方面存在一些弱点。随着时间的推移，可以假设地理定位方法和数据库将被更新以完全支持IPv6前缀。从长远来看，它们没有理由比IPv4提供的更准确。然而，随着时间的推移，我们可以预期会有更多的客户端是移动的，因此仅基于IP地址的地理定位在任何情况下都可能成为问题。可以考虑一种更健壮的技术，例如支持HTTP的位置传递（HOLD）[RFC5985]。
As mentioned above, an ICP should obtain native IPv6 connectivity from its ISPs. In this way, the ICP can avoid most of the complexities of the numerous IPv4-to-IPv6 transition technologies that have been developed; they are all second-best solutions. However, some clients are sure to be using such technologies. An ICP needs to be aware of the operational issues this may cause and how to deal with them.
如上所述，ICP应从其ISP获得本机IPv6连接。通过这种方式，ICP可以避免已开发的众多IPv4到IPv6转换技术的大部分复杂性；它们都是次优解决方案。然而，一些客户肯定会使用这些技术。ICP需要了解这可能导致的运营问题以及如何处理这些问题。
In some cases outside the ICP's control, clients might reach a content server via a network-layer translator from IPv6 to IPv4. ICPs who are offering a dual-stack service and providing both A and AAAA records, as recommended in this document, should not normally receive IPv4 traffic from NAT64 translators [RFC6146]. Exceptionally, however, such traffic could arrive via IPv4 from an IPv6-only client whose DNS resolver failed to receive the ICP's AAAA record for some reason. Such traffic would be indistinguishable from regular IPv4-via-NAT traffic.
在ICP无法控制的某些情况下，客户端可能通过网络层转换器从IPv6到IPv4到达内容服务器。按照本文档的建议，提供双堆栈服务并同时提供a和AAAA记录的ICP通常不应从NAT64转换器接收IPv4流量[RFC6146]。但是，在例外情况下，此类流量可能通过IPv4从仅限IPv6的客户端到达，该客户端的DNS解析器由于某种原因未能接收ICP的AAAA记录。这样的流量将无法通过NAT流量与常规IPv4流量区分开来。
Alternatively, ICPs who are offering a dual-stack service might exceptionally receive IPv6 traffic translated from an IPv4-only client that somehow failed to receive the ICP's A record. An ICP could also receive IPv6 traffic with translated prefixes [RFC6296]. These two cases would only be an issue if the ICP was offering any service that depends on the assumption of end-to-end IPv6 address transparency.
或者，提供双堆栈服务的ICP可能会异常地接收从仅IPv4的客户端转换过来的IPv6流量，该客户端以某种方式未能接收ICP的a记录。ICP还可以接收带有翻译前缀的IPv6流量[RFC6296]。这两种情况只有在ICP提供的服务依赖于端到端IPv6地址透明度的假设时才会成为问题。
Finally, some traffic might reach an ICP that has been translated twice en route (e.g., from IPv6 to IPv4 and back again). Again, the ICP will be unable to detect this. It is likely that real-time geolocation will be highly inaccurate for such traffic, since it will at best indicate the location of the second translator, which could be very distant from the customer.
最后，一些流量可能会到达一个ICP，该ICP在路由过程中被转换了两次（例如，从IPv6到IPv4再转换回来）。同样，ICP将无法检测到这一点。实时地理定位对于此类流量可能非常不准确，因为它最多只能指示第二个翻译器的位置，而第二个翻译器可能离客户非常远。
In other cases, also outside the ICP's control, IPv6 clients may reach the IPv6 Internet via some form of IPv6-in-IPv4 tunnel. In this case, a variety of problems can arise, the most acute of which affect clients connected using the Anycast 6to4 solution [RFC3068]. Advice on how ICPs may mitigate these 6to4 problems is given in Section 4.5. of [RFC6343]. For the benefit of all tunneled clients, it is essential to verify that Path MTU Discovery works correctly (i.e., the relevant ICMPv6 packets are not blocked) and that the server-side TCP implementation correctly supports the Maximum Segment Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic.
在其他情况下，也在ICP的控制范围之外，IPv6客户端可能通过某种形式的IPv6-In-IPv4隧道到达IPv6 Internet。在这种情况下，可能会出现各种问题，其中最严重的问题会影响使用Anycast 6to4解决方案连接的客户端[RFC3068]。第4.5节给出了ICP如何缓解这些6to4问题的建议。属于[RFC6343]。为了使所有隧道客户端受益，必须验证路径MTU发现是否正常工作（即，相关ICMPv6数据包未被阻止），以及服务器端TCP实现是否正确支持IPv6流量的最大段大小（MSS）协商机制[RFC2923]。
Some ICPs have implemented an interim solution to mitigate transition problems by limiting the visibility of their AAAA records to users with validated IPv6 connectivity [RFC6589] (known as "DNS whitelisting"). At the time of this writing, this solution seems to be passing out of use, being replaced by "DNS blacklisting" of customer sites known to have problems with IPv6 connectivity. In the reverse direction, it is worth being aware that some ISPs with significant populations of clients with broken IPv6 setups have begun filtering AAAA record lookups by their clients. None of these solutions are appropriate in the long term.
一些ICP已经实施了一个临时解决方案，通过将其AAAA记录的可见性限制在具有经过验证的IPv6连接的用户[RFC6589]（称为“DNS白名单”）来缓解过渡问题。在撰写本文时，此解决方案似乎已经过时，取而代之的是已知存在IPv6连接问题的客户站点的“DNS黑名单”。相反，值得注意的是，一些拥有大量IPv6设置中断的客户端的ISP已经开始过滤其客户端的AAAA记录查找。从长远来看，这些解决方案都不合适。
Another approach taken by some ICPs is to offer IPv6-only support via a specific DNS name, e.g., ipv6.example.com, if the primary service is www.example.com. In this case, ipv6.example.com would have a AAAA record only. This has some value for testing purposes but is otherwise only of interest to hobbyist users willing to type in special URLs.
一些ICP采取的另一种方法是，如果主要服务是www.example.com，则通过特定的DNS名称（例如IPv6.example.com）仅提供IPv6支持。在这种情况下，ipv6.example.com将只有AAAA记录。这对于测试有一定的价值，但对于那些愿意键入特殊URL的业余用户来说，这只是一个有趣的问题。
There is little an ICP can do to deal with client-side or remote ISP deficiencies in IPv6 support, but it is hoped that the "Happy Eyeballs" [RFC6555] approach will improve the ability for clients to deal with such problems.
ICP几乎无法解决IPv6支持中客户端或远程ISP的不足，但希望“快乐眼球”[RFC6555]方法将提高客户端处理此类问题的能力。
DNS-based techniques for diverting users to Content Delivery Network (CDN) points of presence (POPs) will work for IPv6, if AAAA records as well as A records are provided. In general, the CDN should follow the recommendations of this document, especially by operating a full dual-stack service at each POP. Additionally, each POP will need to handle IPv6 routing exactly like IPv4, for example, running BGP-4+ [RFC4760].
如果提供AAAA记录和A记录，用于将用户转移到内容交付网络（CDN）存在点（POP）的基于DNS的技术将适用于IPv6。一般来说，CDN应遵循本文档的建议，尤其是通过在每个POP上运行完整的双堆栈服务。此外，每个POP将需要完全像IPv4一样处理IPv6路由，例如，运行BGP-4+[RFC4760]。
Note that if an ICP supports IPv6 but its external CDN provider does not, its clients will continue to use IPv4 and any IPv6-only clients will have to use a transition solution of some kind. This is not a desirable situation, since the ICP's work to support IPv6 will be wasted.
请注意，如果ICP支持IPv6，但其外部CDN提供商不支持，则其客户端将继续使用IPv4，并且任何仅支持IPv6的客户端将必须使用某种转换解决方案。这不是一个理想的情况，因为ICP支持IPv6的工作将被浪费。
An ICP might face a complex situation if its CDN provider supports IPv6 at some POPs but not at others. IPv6-only clients could only be diverted to a POP supporting IPv6. There are also scenarios where a dual-stack client would be diverted to a mixture of IPv4 and IPv6 POPs for different URLs, according to the A and AAAA records provided and the availability of optimizations such as "Happy Eyeballs". A related side effect is that copies of the same content viewed at the same time via IPv4 and IPv6 may be different, due to latency in the underlying data synchronization process used by the CDN. This effect has in fact been observed in the wild for a major social network supporting dual stack. These complications do not affect the viability of relying on a dual-stack CDN, however.
如果ICP的CDN提供商在某些POP上支持IPv6，但在其他POP上不支持IPv6，则ICP可能面临复杂的情况。仅限IPv6的客户端只能转移到支持IPv6的POP。根据提供的a和AAAA记录以及诸如“快乐眼球”等优化的可用性，还存在双栈客户端将转向不同URL的IPv4和IPv6 POP的混合的情况。一个相关的副作用是，由于CDN使用的底层数据同步过程中的延迟，通过IPv4和IPv6同时查看的相同内容的副本可能不同。事实上，对于支持双堆栈的主要社交网络，这种效应在野外已经被观察到。然而，这些复杂性并不影响依赖双堆栈CDN的可行性。
The CDN itself faces related complexity: "As IPv6 rolls out, it's going to roll out in pockets, and that's going to make the routing around congestion points that much more important but also that much harder," stated John Summers of Akamai in 2010 [CDN-UPGRADE].
CDN本身面临着相关的复杂性：“随着IPv6的推出，它将在口袋中推出，这将使拥塞点周围的路由变得更加重要，但也更加困难，”Akamai的John Summers在2010年[CDN-UPGRADE]中表示。
A converse situation that might arise is that an ICP has not yet started its deployment of IPv6 but finds that its CDN provider already supports IPv6. Then, assuming that the CDN provider announces appropriate AAAA DNS Resource Records, dual-stack and IPv6-only customers will obtain IPv6 access, and the ICP's content may well be delivered to them via IPv6. In normal circumstances, this should create no problems, but it is a situation that the ICP and its support staff need to be aware of. In particular, support staff should be given IPv6 connectivity in order to be able to investigate any problems that might arise (see Section 4).
可能出现的相反情况是，ICP尚未开始部署IPv6，但发现其CDN提供商已经支持IPv6。然后，假设CDN提供商宣布适当的AAAA DNS资源记录，双栈和仅限IPv6的客户将获得IPv6访问，ICP的内容很可能通过IPv6交付给他们。在正常情况下，这不会产生任何问题，但国际比较项目及其支持人员需要了解这种情况。特别是，应为支持人员提供IPv6连接，以便能够调查可能出现的任何问题（参见第4节）。
As noted earlier, it is in an ICP's or ASP's best interests that their users have direct IPv6 connectivity, rather than indirect IPv4 connectivity via double NAT. If the ICP or ASP has a direct business relationship with some of their clients, or with the networks that connect them to their clients, they are advised to coordinate with those partners to ensure that they have a plan to enable IPv6. They should also verify and test that there is first-class IPv6 connectivity end-to-end between the networks concerned. This is especially true for implementations that require IPv6 support in specialized programs or systems in order for the IPv6 support on the ICP/ASP side to be useful.
如前所述，ICP或ASP的用户通过双NAT实现直接IPv6连接而不是间接IPv4连接符合其最大利益。如果ICP或ASP与其某些客户或将其连接到客户的网络有直接业务关系，建议他们与这些合作伙伴协调，以确保他们有启用IPv6的计划。他们还应验证和测试相关网络之间是否存在一流的IPv6端到端连接。对于需要在专用程序或系统中支持IPv6以使ICP/ASP端的IPv6支持发挥作用的实施，尤其如此。
Some additional considerations come into play for some types of complex or distributed sites and applications that an ICP may be delivering. For example, an ICP may have a site spread across many hostnames (not all under their control). Other ICPs may have their sites or applications distributed across multiple locations for availability, scale, or performance.
对于ICP可能提供的某些类型的复杂或分布式站点和应用程序，还需要考虑一些其他因素。例如，ICP可能有一个站点分布在多个主机名上（并非所有主机名都在其控制之下）。其他ICP可能将其站点或应用程序分布在多个位置，以实现可用性、规模或性能。
Many modern web sites and applications now use a collection of resources and applications, some operated by the ICP and others by third parties. While most clients support sites containing a mixture of IPv4-only and dual-stack elements, an ICP should track the IPv6 availability of embedded resources (such as images), as otherwise their site may only be partially functional or may have degraded performance for IPv6-only users.
许多现代网站和应用程序现在使用一系列资源和应用程序，其中一些由国际比较项目运营，另一些由第三方运营。虽然大多数客户端支持包含纯IPv4和双栈元素的站点，但ICP应跟踪嵌入式资源（如图像）的IPv6可用性，否则其站点可能仅部分功能，或者可能对纯IPv6用户的性能有所降低。
DNS-based load-balancing techniques for diverting users to servers in multiple POPs will work for IPv6, if the load balancer supports IPv6 and if AAAA records are provided. Depending on the architecture of the load balancer, an ICP may need to operate a full dual-stack service at each POP. With other architectures, it may be acceptable to initially only have IPv6 at a subset of locations. Some
如果负载平衡器支持IPv6，并且提供AAAA记录，用于将用户转移到多个POP中的服务器的基于DNS的负载平衡技术将适用于IPv6。根据负载平衡器的体系结构，ICP可能需要在每个POP运行完整的双堆栈服务。对于其他体系结构，最初仅在一部分位置使用IPv6可能是可以接受的。一些
architectures will make it preferable for IPv6 routing to mirror IPv4 routing (for example, running BGP-4+ [RFC4760] if appropriate), but this may not always be possible, as IPv6 and IPv4 connectivity can be independent.
架构将使IPv6路由更好地镜像IPv4路由（例如，如果合适，运行BGP-4+[RFC4760]），但这可能并不总是可能的，因为IPv6和IPv4连接可以是独立的。
Some complexities may arise when a client supporting both IPv4 and IPv6 uses different POPs for each IP version (such as when IPv6 is only available in a subset of locations). There are also scenarios where a dual-stack client would be diverted to a mixture of IPv4 and IPv6 POPs for different URLs, according to the A and AAAA records provided and the availability of optimizations such as "Happy Eyeballs" [RFC6555]. A related side effect is that copies of the same content viewed at the same time via IPv4 and IPv6 may be different, due to latency in the underlying data synchronization process used at the application layer. This effect has in fact been observed in the wild for a major social network supporting dual stack.
当同时支持IPv4和IPv6的客户端对每个IP版本使用不同的POP时（例如IPv6仅在一部分位置可用），可能会出现一些复杂性。根据提供的a和AAAA记录以及诸如“快乐眼球”等优化的可用性[RFC6555]，还存在双栈客户端将被转移到不同URL的IPv4和IPv6 POP的混合的情况。一个相关的副作用是，由于应用层使用的底层数据同步过程中的延迟，通过IPv4和IPv6同时查看的相同内容的副本可能不同。事实上，对于支持双堆栈的主要社交网络，这种效应在野外已经被观察到。
Even with a single POP, unexpected behavior may arise if a client switches spontaneously between IPv4 and IPv6 as a performance optimization [RFC6555] or if its IPv6 address changes frequently for privacy reasons [RFC4941]. Such changes may affect cookies, geolocation, load balancing, and transactional integrity. Although unexpected changes of client address also occur in an IPv4-only environment, they may be more frequent with IPv6.
即使只有一个POP，如果客户端作为性能优化在IPv4和IPv6之间自动切换[RFC6555]，或者由于隐私原因其IPv6地址频繁更改[RFC4941]，也可能出现意外行为。这些更改可能会影响cookie、地理位置、负载平衡和事务完整性。虽然客户端地址的意外更改也会发生在仅IPv4的环境中，但在IPv6中可能会更频繁。
There is no doubt that, initially, IPv6 deployment will have operational impact, and will also require education and training as mentioned in Section 3. Staff will have to update network elements such as routers, update configurations, provide information to end users, and diagnose new problems. However, for an enterprise network, there is plenty of experience, e.g., on numerous university campuses, showing that dual-stack operation is no harder than IPv4-only in the steady state.
毫无疑问，最初，IPv6部署将对运营产生影响，并且还需要第3节中提到的教育和培训。工作人员必须更新路由器等网络元件，更新配置，向最终用户提供信息，并诊断新问题。然而，对于企业网络来说，有大量的经验（例如，在许多大学校园中）表明，只有在稳定状态下，双栈操作并不比IPv4更难。
Whatever management, monitoring, and logging are performed for IPv4 are also needed for IPv6. Therefore, all products and tools used for these purposes must be updated to fully support IPv6 management data. It is important to verify that tools have been fully updated to support 128-bit addresses entered and displayed in hexadecimal format [RFC5952]. Since an IPv6 network may operate with more than one IPv6 prefix and therefore more than one address per host, the tools must deal with this as a normal situation. This includes any address management tool in use (see Section 5.1) as well as tools used for creating DHCP and DNS configurations. There is significant overlap here with the tools involved in site renumbering [RFC6879].
无论对IPv4执行何种管理、监视和日志记录，IPv6都需要。因此，必须更新用于这些目的的所有产品和工具，以完全支持IPv6管理数据。必须验证工具是否已完全更新，以支持以十六进制格式输入和显示的128位地址[RFC5952]。由于IPv6网络可能使用多个IPv6前缀运行，因此每个主机有多个地址，因此这些工具必须将此作为正常情况处理。这包括任何正在使用的地址管理工具（见第5.1节）以及用于创建DHCP和DNS配置的工具。此处与站点重新编号所涉及的工具有重大重叠[RFC6879]。
At an early stage of IPv6 deployment, it is likely that IPv6 will be mainly managed via IPv4 transport. This allows network management systems to test for dependencies between IPv4 and IPv6 management data. For example, will reports mixing IPv4 and IPv6 addresses display correctly?
在IPv6部署的早期阶段，IPv6可能主要通过IPv4传输进行管理。这允许网络管理系统测试IPv4和IPv6管理数据之间的依赖关系。例如，混合IPv4和IPv6地址的报告能否正确显示？
In a second phase, IPv6 transport should be used to manage the network. Note that it will also be necessary for an ICP to provide IPv6 connectivity for its operations and support staff, even when working remotely. As far as possible, mutual dependency between IPv4 and IPv6 should be avoided, for both the management data and the transport. Failure of one should not cause a failure of the other. One precaution to avoid this would be for network management systems to be dual-stacked. It would then be possible to use IPv4 connectivity to repair IPv6 configurations, and vice versa.
在第二阶段，应使用IPv6传输来管理网络。请注意，ICP还需要为其运营和支持人员提供IPv6连接，即使在远程工作时也是如此。对于管理数据和传输，应尽可能避免IPv4和IPv6之间的相互依赖。一方的失败不应导致另一方的失败。避免这种情况的一个预防措施是网络管理系统采用双重堆叠。这样就可以使用IPv4连接修复IPv6配置，反之亦然。
Dual stack, while necessary, does have management scaling and overhead considerations. As noted earlier, the long-term goal is to move to single-stack IPv6, when the network and its customers can support it. This is an additional reason why mutual dependency between the address families should be avoided in the management system in particular; a hidden dependency on IPv4 that had been forgotten for many years would be highly inconvenient. In particular, a management tool that manages IPv6 but itself runs only over IPv4 would prove disastrous on the day that IPv4 is switched off.
虽然有必要，但双堆栈确实有管理扩展和开销方面的考虑。如前所述，长期目标是在网络及其客户能够支持的情况下转向单栈IPv6。这是一个额外的原因，特别是在管理系统中应避免地址族之间的相互依赖；对IPv4的隐藏依赖已经被遗忘多年，这将非常不方便。特别是，如果一个管理IPv6但自身仅在IPv4上运行的管理工具在IPv4关闭的那一天被证明是灾难性的。
An ICP should ensure that any end-to-end availability monitoring systems are updated to monitor dual-stacked servers over both IPv4 and IPv6. A particular challenge here may be monitoring systems relying on DNS names, as this may result in monitoring only one of IPv4 or IPv6, resulting in a loss of visibility to failures in network connectivity over either address family.
ICP应确保更新任何端到端可用性监控系统，以监控IPv4和IPv6上的双堆叠服务器。这里的一个特殊挑战可能是监视依赖DNS名称的系统，因为这可能导致仅监视IPv4或IPv6中的一个，从而导致无法看到通过任一地址系列的网络连接故障。
As mentioned above, it will also be necessary for an ICP to provide IPv6 connectivity for its operations and support staff, even when working remotely.
如上所述，ICP还必须为其运营和支持人员提供IPv6连接，即使在远程工作时也是如此。
While many ICPs may still be in the process of experimenting with and configuring IPv6, there is mature malware in the wild that will launch attacks over IPv6. For example, if a AAAA DNS record is added for a hostname, malware using client OS libraries may automatically switch from attacking that hostname over IPv4 to attacking that hostname over IPv6. As a result, it is crucial that firewalls and other network security appliances protecting servers support IPv6 and have rules tested and configured.
虽然许多ICP可能仍在试验和配置IPv6，但在野外有成熟的恶意软件会通过IPv6发起攻击。例如，如果为主机名添加AAAA DNS记录，则使用客户端OS库的恶意软件可能会自动从通过IPv4攻击该主机名切换到通过IPv6攻击该主机名。因此，防火墙和其他保护服务器的网络安全设备支持IPv6并测试和配置规则至关重要。
Security experience with IPv4 should be used as a guide as to the threats that may exist in IPv6, but they should not be assumed to be equally likely nor should they be assumed to be the only threats that could exist in IPv6. However, essentially every threat that exists for IPv4 exists or will exist for IPv6, to a greater or lesser extent. It is essential to update firewalls, intrusion detection systems, denial-of-service precautions, and security auditing technology to fully support IPv6. Needless to say, it is also essential to turn on well-known security mechanisms such as DNS Security and DHCPv6 Authentication. Otherwise, IPv6 will become an attractive target for attackers.
IPv4的安全经验应作为IPv6中可能存在的威胁的指南，但不应假定它们的可能性相同，也不应假定它们是IPv6中可能存在的唯一威胁。然而，本质上，IPv4存在的每一种威胁都或多或少地存在于或将存在于IPv6。更新防火墙、入侵检测系统、拒绝服务预防措施和安全审计技术以完全支持IPv6至关重要。不用说，还必须启用众所周知的安全机制，如DNS安全和DHCPv6身份验证。否则，IPv6将成为攻击者的攻击目标。
When multiple PA prefixes are in use as mentioned in Section 5.1, firewall rules must allow for all valid prefixes and must be set up to work as intended even if packets are sent via one ISP but return packets arrive via another.
如第5.1节所述，当使用多个PA前缀时，防火墙规则必须允许所有有效前缀，并且必须设置为按预期工作，即使数据包通过一个ISP发送，但返回的数据包通过另一个ISP到达。
Performance and memory size aspects of dual-stack firewalls must be considered (as discussed for routers in Section 5.2).
必须考虑双堆栈防火墙的性能和内存大小方面（如第5.2节中针对路由器所讨论的）。
In a dual-stack operation, there may be a risk of cross-contamination between the two protocols. For example, a successful IPv4-based denial-of-service attack might also deplete resources needed by the IPv6 service, or vice versa. This risk strengthens the argument that IPv6 security must be up to the same level as IPv4. Risks can also occur with dual-stack Virtual Private Network (VPN) solutions [VPN-LEAKAGES].
在双堆栈操作中，两个协议之间可能存在交叉污染的风险。例如，成功的基于IPv4的拒绝服务攻击也可能耗尽IPv6服务所需的资源，反之亦然。这种风险强化了IPv6安全性必须达到与IPv4相同级别的论点。双栈虚拟专用网络（VPN）解决方案也可能出现风险[VPN-Leaks]。
A general overview of techniques to protect an IPv6 network against external attacks is given in [RFC4864]. Assuming that an ICP has native IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4 tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this kind should be blocked, except for the case noted in Section 4.5 of [RFC6343]. ICMPv6 traffic should only be blocked in accordance with [RFC4890]; in particular, Packet Too Big messages, which are essential for Path MTU Discovery, must not be blocked.
[RFC4864]中概述了保护IPv6网络免受外部攻击的技术。假设ICP具有本机IPv6连接，建议使用IPv4协议类型41阻止传入的IPv6-in-IPv4隧道流量。除[RFC6343]第4.5节所述情况外，应阻止此类传出流量。ICMPv6通信应仅按照[RFC4890]进行阻断；特别是，对于路径MTU发现至关重要的数据包过大消息，不得阻止。
Brute-force scanning attacks to discover the existence of hosts are much less likely to succeed for IPv6 than for IPv4 [RFC5157]. However, this should not lull an ICP into a false sense of security, as various naming or addressing conventions can result in IPv6 address space being predictable or guessable. In the extreme case, IPv6 hosts might be configured with interface identifiers that are very easy to guess; for example, hosts or subnets manually numbered with consecutive interface identifiers starting from "1" would be much easier to guess. Such practices should be avoided, and other
发现主机存在的暴力扫描攻击在IPv6中比在IPv4中成功的可能性要小得多[RFC5157]。但是，这不应使ICP产生错误的安全感，因为各种命名或寻址约定可能导致IPv6地址空间是可预测或可猜测的。在极端情况下，IPv6主机可能配置了非常容易猜测的接口标识符；例如，使用从“1”开始的连续接口标识符手动编号的主机或子网将更容易猜测。应避免此类做法，并采取其他措施
useful precautions are discussed in [RFC6583]. Also, attackers might find IPv6 addresses in logs, packet traces, DNS records (including reverse records), or elsewhere.
[RFC6583]中讨论了有用的预防措施。此外，攻击者可能在日志、数据包跟踪、DNS记录（包括反向记录）或其他地方找到IPv6地址。
Protection against rogue Router Advertisements (RA Guard) should also be considered [RFC6105].
还应考虑针对恶意路由器广告（RA Guard）的保护[RFC6105]。
Transport Layer Security version 1.2 [RFC5246] and its predecessors work correctly with TCP over IPv6, meaning that HTTPS-based security solutions are immediately applicable. The same should apply to any other transport-layer or application-layer security techniques.
传输层安全版本1.2[RFC5246]及其前身可在IPv6上的TCP上正常工作，这意味着基于HTTPS的安全解决方案立即适用。这同样适用于任何其他传输层或应用层安全技术。
If an ASP uses IPsec [RFC4301] and the Internet Key Exchange (IKE) protocol [RFC5996] in any way to secure connections with clients, these too are fully applicable to IPv6, but only if the software stack at each end has been appropriately updated.
如果ASP以任何方式使用IPsec[RFC4301]和Internet密钥交换（IKE）协议[RFC5996]来保护与客户端的连接，则这些协议也完全适用于IPv6，但前提是两端的软件堆栈已适当更新。
Valuable contributions were made by Erik Kline. Useful comments were received from Tore Anderson, Cameron Byrne, Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel Jaeggli, Roger Jorgensen, Victor Kuarsingh, Bing Liu, Trent Lloyd, John Mann, Michael Newbery, Erik Nygren, Arturo Servin, Mark Smith, and other participants in the V6OPS working group.
埃里克·克莱恩做出了宝贵的贡献。Tore Anderson、Cameron Byrne、Tassos Chatzittomoglou、Wesley George、邓辉、Joel Jaeggli、Roger Jorgensen、Victor Kuarsingh、Bing Liu、Trent Lloyd、John Mann、Michael Newbery、Erik Nygren、Arturo Servin、Mark Smith以及V6OPS工作组的其他参与者提出了有用的意见。
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work.
布赖恩·卡彭特是剑桥大学计算机实验室的一名访客，他参与了这项工作。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC20801997年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[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月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308]Hopps，C.，“使用IS-IS路由IPv6”，RFC5308，2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838]Lindem，A.，Mirtorabi，S.，Roy，A.，Barnes，M.，和R.Aggarwal，“OSPFv3中地址家庭的支持”，RFC 5838，2010年4月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月。
[CDN-UPGRADE] Marsan, C., "Akamai: Why our IPv6 upgrade is harder than Google's", Network World, September 2010, <http:// www.networkworld.com/news/2010/091610-akamai-ipv6.html>.
[CDN-UPGRADE]Marsan，C.，“Akamai：为什么我们的IPv6升级比谷歌的更难”，网络世界，2010年9月，<http://www.networkworld.com/news/2010/091610-Akamai-IPv6.html>。
[IPv6-CE-REQS] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, October 2012.
[IPv6 CE要求]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，正在进行的工作，2012年10月。
[IPv6-NETWORK-DESIGN] Matthews, P., "Design Choices for IPv6 Networks", Work in Progress, February 2013.
[IPv6网络设计]Matthews，P.，“IPv6网络的设计选择”，正在进行的工作，2013年2月。
[MULTIHOMING-WITHOUT-NAT] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012.
[MULTIHOMING-WITHOUT-NAT]Troan，O.，Ed.，Miles，D.，Matsushima，S.，Okimoto，T.，和D.Wing，“无网络地址转换的IPv6多主”，正在进行的工作，2012年2月。
[RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996.
[RFC1912]Barr，D.，“常见DNS操作和配置错误”，RFC1912，1996年2月。
[RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", RFC 2081, January 1997.
[RFC2081]Malkin，G.“RIPng协议适用性声明”，RFC 2081，1997年1月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038]Shin，M-K.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，2005年3月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157]Chown，T.，“IPv6对网络扫描的影响”，RFC 5157，2008年3月。
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008.
[RFC5375]Van de Velde，G.，Popoviciu，C.，Chown，T.，Bonness，O.，和C.Hahn，“IPv6单播地址分配注意事项”，RFC 5375，2008年12月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180]Arkko，J.和F.Baker，“IPv6部署期间使用IPv6转换机制的指南”，RFC 6180，2011年5月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 63432011年8月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，2012年4月。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6583]Gashinsky，I.，Jaeggli，J.，和W.Kumari，“操作邻居发现问题”，RFC 6583，2012年3月。
[RFC6589] Livingood, J., "Considerations for Transitioning Content to IPv6", RFC 6589, April 2012.
[RFC6589]Livingood，J.，“将内容转换为IPv6的注意事项”，RFC 6589，2012年4月。
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013.
[RFC6866]Carpenter，B.和S.Jiang，“企业网络中使用静态地址重新编号IPv6主机的问题声明”，RFC 6866，2013年2月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879]Jiang，S.，Liu，B.和B.Carpenter，“IPv6企业网络重新编号方案、注意事项和方法”，RFC 6879，2013年2月。
[VPN-LEAKAGES] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks", Work in Progress, December 2012.
[VPN-Leaks]Gont，F.，“双堆栈主机/网络中的虚拟专用网络（VPN）流量泄漏”，正在进行的工作，2012年12月。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
中国北京海淀区北青路156号华为校区盛江华为技术有限公司Q14，邮编100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com