Internet Engineering Task Force (IETF) J. Livingood
Request for Comments: 6589 Comcast
Category: Informational April 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Livingood
Request for Comments: 6589 Comcast
Category: Informational April 2012
ISSN: 2070-1721
Considerations for Transitioning Content to IPv6
将内容转换到IPv6的注意事项
Abstract
摘要
This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers.
本文档描述了将Internet上的最终用户内容转换为IPv6的注意事项。虽然这是为解决最终用户内容（通常基于web）而定制的，但本文档的许多方面可能更广泛地适用于其他应用程序和服务向IPv6的过渡。本文档探讨了向IPv6过渡所涉及的挑战、潜在的迁移策略、可能的迁移阶段以及其他注意事项。本文档的受众通常是互联网社区，尤其是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/rfc6589.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6589.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................4
2. Challenges When Transitioning Content to IPv6 ...................4
2.1. IPv6-Related Impairment ....................................5
2.2. Operational Maturity Concerns ..............................5
2.3. Volume-Based Concerns ......................................5
3. IPv6 Adoption Implications ......................................6
4. Potential Migration Tactics .....................................6
4.1. Solving Current End-User IPv6 Impairments ..................7
4.2. Using IPv6-Specific Names ..................................8
4.3. Implementing DNS Resolver Whitelisting .....................8
4.3.1. How DNS Resolver Whitelisting Works ................11
4.3.2. Similarities to Content Delivery Networks
and Global Server Load Balancing ...................15
4.3.3. Similarities to DNS Load Balancing .................15
4.3.4. Similarities to Split DNS ..........................15
4.3.5. Related Considerations .............................16
4.4. Implementing DNS Blacklisting .............................17
4.5. Transitioning Directly to Native Dual Stack ...............18
5. Potential Implementation Phases ................................19
5.1. No Access to IPv6 Content .................................19
5.2. Using IPv6-Specific Names .................................19
5.3. Deploying DNS Resolver Whitelisting Using Manual
Processes .................................................19
5.4. Deploying DNS Resolver Whitelisting Using
Automated Processes .......................................19
5.5. Turning Off DNS Resolver Whitelisting .....................20
5.6. Deploying DNS Blacklisting ................................20
5.7. Fully Dual-Stack Content ..................................20
6. Other Considerations ...........................................20
6.1. Security Considerations ...................................20
6.2. Privacy Considerations ....................................21
6.3. Considerations with Poor IPv4 and Good IPv6 Transport .....22
7. Contributors ...................................................23
8. Acknowledgements ...............................................23
9. References .....................................................24
9.1. Normative References ......................................24
9.2. Informative References ....................................25
1. Introduction ....................................................4
2. Challenges When Transitioning Content to IPv6 ...................4
2.1. IPv6-Related Impairment ....................................5
2.2. Operational Maturity Concerns ..............................5
2.3. Volume-Based Concerns ......................................5
3. IPv6 Adoption Implications ......................................6
4. Potential Migration Tactics .....................................6
4.1. Solving Current End-User IPv6 Impairments ..................7
4.2. Using IPv6-Specific Names ..................................8
4.3. Implementing DNS Resolver Whitelisting .....................8
4.3.1. How DNS Resolver Whitelisting Works ................11
4.3.2. Similarities to Content Delivery Networks
and Global Server Load Balancing ...................15
4.3.3. Similarities to DNS Load Balancing .................15
4.3.4. Similarities to Split DNS ..........................15
4.3.5. Related Considerations .............................16
4.4. Implementing DNS Blacklisting .............................17
4.5. Transitioning Directly to Native Dual Stack ...............18
5. Potential Implementation Phases ................................19
5.1. No Access to IPv6 Content .................................19
5.2. Using IPv6-Specific Names .................................19
5.3. Deploying DNS Resolver Whitelisting Using Manual
Processes .................................................19
5.4. Deploying DNS Resolver Whitelisting Using
Automated Processes .......................................19
5.5. Turning Off DNS Resolver Whitelisting .....................20
5.6. Deploying DNS Blacklisting ................................20
5.7. Fully Dual-Stack Content ..................................20
6. Other Considerations ...........................................20
6.1. Security Considerations ...................................20
6.2. Privacy Considerations ....................................21
6.3. Considerations with Poor IPv4 and Good IPv6 Transport .....22
7. Contributors ...................................................23
8. Acknowledgements ...............................................23
9. References .....................................................24
9.1. Normative References ......................................24
9.2. Informative References ....................................25
This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. The issues explored herein will be of particular interest to major web content sites (sometimes described hereinafter as "high-service-level domains"), which have specific and unique concerns related to maintaining a high-quality user experience for all of their users during their transition to IPv6. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. Some sections of this document also include information about the potential implications of various migration tactics or phased approaches to the transition to IPv6.
本文档描述了将Internet上的最终用户内容转换为IPv6的注意事项。虽然这是为解决最终用户内容（通常基于web）而定制的，但本文档的许多方面可能更广泛地适用于其他应用程序和服务向IPv6的过渡。本文探讨的问题对主要web内容站点（有时在下文中称为“高服务级别域”）特别有意义，这些站点在向IPv6过渡期间为其所有用户维护高质量的用户体验具有特定和独特的关注点。本文档探讨了向IPv6过渡所涉及的挑战、潜在的迁移策略、可能的迁移阶段以及其他注意事项。本文档的某些部分还包括有关向IPv6过渡的各种迁移策略或分阶段方法的潜在影响的信息。
The goal in transitioning content to IPv6 is to make that content natively dual-stack enabled, which provides native access to all end users via both IPv4 and IPv6. However, there are technical and operational challenges in being able to transition smoothly for all end users, which has led to the development of a variety of migration tactics. A first step in understanding various migration tactics is to first outline the challenges involved in moving content to IPv6.
将内容转换为IPv6的目标是使该内容本机启用双堆栈，从而通过IPv4和IPv6为所有最终用户提供本机访问。然而，在为所有最终用户顺利过渡方面存在技术和操作方面的挑战，这导致了各种迁移策略的发展。理解各种迁移策略的第一步是首先概述将内容移动到IPv6所涉及的挑战。
Implementers of these various migration tactics are attempting to protect users of their services from having a negative experience (poor performance) when they receive DNS responses containing AAAA resource records or when attempting to use IPv6 transport. There are two main concerns that pertain to this practice: one is IPv6-related impairment, and the other is the maturity or stability of IPv6 transport (and associated network operations) for high-service-level domains. Both can negatively affect the experience of end users.
这些不同迁移策略的实施者正试图保护其服务的用户在接收到包含AAAA资源记录的DNS响应或尝试使用IPv6传输时不会有负面体验（性能差）。与此实践相关的主要问题有两个：一个是与IPv6相关的损害，另一个是高服务级别域的IPv6传输（和相关网络操作）的成熟度或稳定性。两者都会对最终用户的体验产生负面影响。
Not all domains may face the same challenges in transitioning content to IPv6, since the user base of each domain, traffic sources, traffic volumes, and other factors obviously will vary between domains. As a result, while some domains have used an IPv6 migration tactic, others have run brief IPv6 experiments and then decided to simply turn on IPv6 for the domain without further delay and without using any specialized IPv6 migration tactics [Heise]. Each domain should therefore consider its specific situation when formulating a plan to move to IPv6; there is not one approach that will work for every domain.
并非所有域在将内容转换为IPv6时都面临相同的挑战，因为每个域的用户基础、流量源、流量和其他因素在域之间显然会有所不同。因此，虽然一些域使用了IPv6迁移策略，但另一些域进行了简短的IPv6实验，然后决定在不再延迟和不使用任何专门的IPv6迁移策略的情况下为该域启用IPv6[Heise]。因此，每个域在制定IPv6移动计划时应考虑其具体情况；没有一种方法适用于每个领域。
Some implementers have observed that when they added AAAA resource records to their authoritative DNS servers in order to support IPv6 access to their content, a small fraction of end users had slow or otherwise impaired access to a given website with both AAAA and A resource records. The fraction of users with such impaired access has been estimated to be as high as 0.078% of total Internet users [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness].
一些实施者观察到，当他们向其权威DNS服务器添加AAAA资源记录以支持对其内容的IPv6访问时，一小部分最终用户对既有AAAA又有a资源记录的给定网站的访问速度较慢或受到影响。据估计，这种访问受损的用户比例高达互联网用户总数的0.078%【IETF-77-DNSOP】【NW Article DNSOP】【IPv6增长】【IPv6中断】。
While it is outside the scope of this document to explore the various reasons why a particular user's system (host) may have impaired IPv6 access, and the potential solutions [RFC6555] [RFC6343], for the users who experience this impairment, it has a very real performance impact. It would impact access to all or most dual-stack services to which the user attempts to connect. This negative end-user experience can range from access that is somewhat slower than usual (as compared to native IPv4-based access), to extremely slow access, to no access to the domain's resources whatsoever. In essence, whether the end user even has an IPv6 address or not, merely by receiving a AAAA record response, the user either cannot access a Fully Qualified Domain Name (FQDN, representing a service or resource sought) or it is so slow that the user gives up and assumes the destination is unreachable.
虽然探讨特定用户的系统（主机）可能破坏IPv6访问的各种原因以及可能的解决方案[RFC6555][RFC6343]超出了本文档的范围，但对于经历这种破坏的用户来说，这会对性能产生非常实际的影响。这将影响对用户尝试连接的所有或大多数双堆栈服务的访问。这种负面的最终用户体验包括访问速度比平时慢（与基于IPv4的本机访问相比），访问速度非常慢，甚至无法访问域资源。本质上，无论最终用户是否拥有IPv6地址，仅通过接收AAAA记录响应，用户要么无法访问完全限定的域名（FQDN，表示所寻求的服务或资源），要么速度太慢，以至于用户放弃并假设无法访问目的地。
Some implementers have discovered that network operations, operations support and business support systems, and other operational processes and procedures are less mature for IPv6 as compared to IPv4, since IPv6 has not heretofore been pervasively deployed. This operational immaturity may be observed not just within the network of a given domain but also in any directly or indirectly interconnected networks. As a result, many domains consider it prudent to undertake any network changes that will cause traffic to shift to IPv6 gradually, in order to provide time and experience for IPv6 operations and network practices to mature.
一些实施者发现，与IPv4相比，IPv6的网络操作、操作支持和业务支持系统以及其他操作流程和过程不太成熟，因为IPv6迄今尚未得到广泛部署。不仅在给定域的网络中，而且在任何直接或间接互连的网络中，都可以观察到这种操作不成熟。因此，许多领域认为进行任何网络更改都是谨慎的，这将导致业务逐渐转移到IPv6，以便为IPv6操作和网络实践成熟提供时间和经验。
While Section 2.2 pertains to risks due to immaturity in operations, a related concern is that some technical issues may not become apparent until some moderate to high volume of traffic is sent via IPv6 to and from a domain. As above, this may be the case not just within the network of that domain but also for any directly or indirectly interconnected networks. Furthermore, compared to domains with small to moderate traffic volumes, whether by the count of end users or count of bytes transferred, high-traffic domains receive
虽然第2.2节涉及运营不成熟带来的风险，但相关的问题是，在通过IPv6向域发送中到高流量的通信之前，一些技术问题可能不会变得明显。如上所述，不仅在该域的网络内，而且对于任何直接或间接互连的网络也可能如此。此外，与具有小到中等流量的域相比，无论是从最终用户数还是传输的字节数来看，高流量域都会收到
such a level of usage that it is prudent to undertake any network changes gradually and in a manner that minimizes the risk of disruption. One can imagine that for one of the top ten sites globally, for example, the idea of suddenly turning on a significant amount of IPv6 traffic is quite daunting and would carry a relatively high risk of network and/or other disruptions.
这样一种使用水平，谨慎的做法是以尽量减少中断风险的方式逐步进行任何网络更改。例如，可以想象，对于全球排名前十的站点之一，突然开启大量IPv6流量的想法是相当令人畏惧的，并且会带来相对较高的网络和/或其他中断风险。
It is important that the challenges in transitioning content to IPv6 as noted in Section 2 are addressed, especially for high-service-level domains. Some high-service-level domains may find the prospect of transitioning to IPv6 extremely daunting without having some ability to address these challenges and to incrementally control their transition to IPv6. Lacking such controls, some domains may choose to substantially delay their transition to IPv6. A substantial delay in moving content to IPv6 could certainly mean there are somewhat fewer motivating factors for network operators to deploy IPv6 to end-user hosts (though they have many significant motivating factors that are largely independent of content). At the same time, unless network operators transition to IPv6, there are of course fewer motivations for domain owners to transition content to IPv6. Without progress in each part of the Internet ecosystem, networks and/or content sites may delay, postpone, or cease adoption of IPv6, or to actively seek alternatives to it. Such alternatives may include the use of multi-layer or large-scale network address translation (NAT), which is not preferred relative to native dual stack.
如第2节所述，解决将内容转换为IPv6的难题非常重要，特别是对于高服务级别的域。一些高服务级别的域可能会发现过渡到IPv6的前景非常令人望而生畏，而不具备应对这些挑战和增量控制过渡到IPv6的能力。由于缺乏此类控制，一些域可能会选择大幅推迟向IPv6的过渡。将内容移动到IPv6方面的重大延迟当然可能意味着网络运营商将IPv6部署到最终用户主机的激励因素有所减少（尽管他们有许多重要的激励因素，这些因素在很大程度上与内容无关）。同时，除非网络运营商过渡到IPv6，否则域所有者将内容过渡到IPv6的动机当然会减少。如果互联网生态系统的每个部分都没有进展，网络和/或内容站点可能会延迟、推迟或停止采用IPv6，或积极寻求替代方案。此类替代方案可包括使用多层或大规模网络地址转换（NAT），相对于本机双堆栈而言，这不是优选的。
Obviously, transitioning content to IPv6 is important to IPv6 adoption overall. While challenges do exist, such a transition is not an impossible task for a domain to undertake. A range of potential migration tactics, as noted below in Section 4, can help meet these challenges and enable a domain to successfully transition content and other services to IPv6.
显然，将内容转换到IPv6对于IPv6的总体采用非常重要。虽然挑战确实存在，但对于一个领域来说，这样的过渡并不是一项不可能完成的任务。如下文第4节所述，一系列潜在的迁移策略有助于应对这些挑战，并使域能够成功地将内容和其他服务转换到IPv6。
Domains have a wide range of potential tactics at their disposal that may be used to facilitate the migration to IPv6. This section includes many of the key tactics that could be used by a domain but by no means provides an exhaustive or exclusive list. Only a specific domain can judge whether or not a given (or any) migration tactic applies to it and meets its needs. A domain may also decide to pursue several of these tactics in parallel. Thus, the usefulness of each tactic and the associated pros and cons will vary from domain to domain.
域有一系列可供使用的潜在策略，可用于促进向IPv6的迁移。本节包括许多域可以使用的关键策略，但绝不提供详尽或排他性的列表。只有特定的域才能判断给定（或任何）迁移策略是否适用于它并满足它的需求。一个领域也可能决定同时采用其中的几种策略。因此，每种策略的有用性以及相关的利弊将因领域而异。
Domains can endeavor to fix the underlying technical problems experienced by their end users during the transition to IPv6, as noted in Section 2.1. One challenge with this option is that a domain may have little or no control over the network connectivity, operating system, client software (such as a web browser), and/or other capabilities of the end users of that domain. In most cases, a domain is only in a position to influence and guide its end users. While this is not the same sort of direct control that may exist, for example, in an enterprise network, major domains are likely to be trusted by their end users and may therefore be able to influence and guide these users in solving any IPv6-related impairments.
如第2.1节所述，域可以努力解决其最终用户在过渡到IPv6期间遇到的潜在技术问题。此选项的一个挑战是，域可能对该域最终用户的网络连接、操作系统、客户端软件（如web浏览器）和/或其他功能几乎没有控制权。在大多数情况下，域只能影响和引导其最终用户。虽然这与可能存在的直接控制不同，例如，在企业网络中，主要域可能受到其最终用户的信任，因此可能能够影响和指导这些用户解决任何与IPv6相关的损害。
Another challenge is that end-user impairments are something that one domain on its own cannot solve. This means that domains may find it more effective to coordinate with many others in the Internet community to solve what is really a collective problem that affects the entire Internet. Of course, it can sometimes be difficult to motivate members of the Internet community to work collectively towards such a goal, sharing the labor, time, and costs related to such an effort. However, World IPv6 Day [W6D] shows that such community efforts are possible, and despite any potential challenges, the Internet community continues to work together in order to solve end-user IPv6 impairments.
另一个挑战是，最终用户损伤是一个领域本身无法解决的问题。这意味着域可能会发现与互联网社区中的许多其他人进行协调更有效，以解决影响整个互联网的真正集体问题。当然，有时很难激励互联网社区的成员为实现这一目标而共同努力，分享与这一努力相关的劳动力、时间和成本。然而，世界IPv6日[W6D]表明，这样的社区努力是可能的，尽管存在任何潜在的挑战，互联网社区仍在继续合作，以解决最终用户IPv6的障碍。
One potential tactic may be to identify which users have such impairments and then to communicate this information to affected users. Such end-user communication is likely to be most helpful if the end users are not only alerted to a potential problem but are given careful and detailed advice on how to resolve this on their own, or are guided to where they can seek help in doing so. Another potential tactic is for a domain to collect, track over time, and periodically share with the Internet community the rate of impairment observed for that domain. In any such end-user IPv6-related analysis and communication, Section 6.2 is worth taking into account.
一种可能的策略是确定哪些用户有这种损伤，然后将此信息传达给受影响的用户。如果终端用户不仅对潜在问题保持警觉，而且就如何自行解决问题向其提供仔细和详细的建议，或者被引导到他们可以寻求帮助的地方，那么这种终端用户沟通可能最有帮助。另一种可能的策略是，域收集、跟踪一段时间，并定期与互联网社区共享观察到的该域的受损率。在任何此类最终用户IPv6相关分析和通信中，第6.2节值得考虑。
However, while these tactics can help reduce IPv6-related impairments (Section 2.1), they do not address either operational maturity concerns (noted in Section 2.2) or volume-based concerns (noted in Section 2.3), which should be considered and addressed separately.
然而，尽管这些策略有助于减少IPv6相关的损害（第2.1节），但它们既不能解决运营成熟度问题（第2.2节中有说明），也不能解决基于卷的问题（第2.3节中有说明），这两个问题应单独考虑和解决。
Another potential migration tactic is for a domain to gain experience using a special FQDN. This has become typical for domains beginning the transition to IPv6, whereby an address-family-specific name such as ipv6.example.com or www.ipv6.example.com is used. An end user would have to know to use this special IPv6-specific name; it is not the same name used for regular traffic.
另一种潜在的迁移策略是让域获得使用特殊FQDN的经验。这已成为开始过渡到IPv6的域的典型情况，其中使用了特定于地址系列的名称，如IPv6.example.com或www.IPv6.example.com。最终用户必须知道如何使用此特定于IPv6的特殊名称；它与用于常规通信的名称不同。
This special IPv6-specific name directs traffic to a host or hosts that have been enabled for native IPv6 access. In some cases, this name may point to hosts that are separate from those used for IPv4 traffic (via www.example.com), while in other cases it may point to the same hosts used for IPv4 traffic. A subsequent phase, if separate hosts are used to support special IPv6-specific names, is to move to the same hosts used for regular traffic in order to utilize and exercise production infrastructure more fully. Regardless of whether or not dedicated hosts are used, the use of the special name is a way to incrementally control traffic as a tool for a domain to gain IPv6 experience and increase IPv6 use on a relatively controlled basis. Any lessons learned can then inform plans for a full transition to IPv6. This also provides an opportunity for a domain to develop any necessary training for staff, to develop IPv6-related testing procedures for its production network and lab, to deploy IPv6 functionality into its production network, and to develop and deploy IPv6-related network and service monitors. It is also an opportunity to add a relatively small amount of IPv6 traffic to ensure that network gear, network interconnects, and IPv6 routing in general are working as expected.
此特定于IPv6的特殊名称将流量定向到已启用本机IPv6访问的一台或多台主机。在某些情况下，此名称可能指向与IPv4流量使用的主机（通过www.example.com）不同的主机，而在其他情况下，它可能指向与IPv4流量使用的主机相同的主机。如果使用单独的主机来支持特定于IPv6的特殊名称，则下一个阶段是移动到用于常规通信的相同主机，以便更充分地利用和使用生产基础设施。无论是否使用专用主机，使用特殊名称都是一种增量控制流量的方法，作为域获得IPv6体验和在相对受控的基础上增加IPv6使用的工具。任何经验教训都可以为全面过渡到IPv6提供参考。这也为域提供了一个机会，使其能够为员工开发任何必要的培训，为其生产网络和实验室开发与IPv6相关的测试程序，将IPv6功能部署到其生产网络中，以及开发和部署与IPv6相关的网络和服务监控器。这也是一个添加相对少量IPv6通信量的机会，以确保网络设备、网络互连和IPv6路由总体上按预期工作。
While using a special IPv6-specific name is a good initial step to functionally test and prepare a domain for IPv6 -- including developing and maturing IPv6 operations, as noted in Section 2.2 -- the utility of the tactic is limited, since users must know the IPv6- specific name, the traffic volume will be low, and the traffic is unlikely to be representative of the general population of end users (they are likely to be self-selecting early adopters and more technically advanced than average), among other reasons. As a result, any concerns and risks related to traffic volume, as noted in Section 2.3, should still be considered and addressed separately.
虽然使用特定于IPv6的特殊名称是对IPv6域进行功能测试和准备的良好初始步骤，包括开发和完善IPv6操作，如第2.2节所述，但该策略的实用性有限，因为用户必须知道特定于IPv6的名称，因此通信量将很低，除其他原因外，流量不太可能代表终端用户的一般人群（他们可能是自我选择的早期采用者，技术上比平均水平更先进）。因此，如第2.3节所述，与交通量相关的任何问题和风险仍应单独考虑和解决。
Another potential tactic -- especially when a high-service-level domain is ready to move beyond an IPv6-specific name, as described in Section 4.2 -- is to selectively return AAAA resource records (RRs), which contain IPv6 addresses. This selective response of DNS records is performed by an authoritative DNS server for a domain in response
另一种可能的策略——特别是当高服务级别域准备好超越IPv6特定名称时，如第4.2节所述——是有选择地返回AAAA资源记录（RRs），其中包含IPv6地址。DNS记录的这种选择性响应由响应域的权威DNS服务器执行
to DNS queries sent by DNS recursive resolvers [RFC1035]. This is commonly referred to in the Internet community as "DNS Resolver Whitelisting", and will be referred to as such hereafter, though in essence it is simply a tactic enabling the selective return of DNS records based upon various technical factors. An end user is seeking a resource by name, and this selective response mechanism enables what is perceived to be the most reliable and best performing IP address family to be used (IPv4 or IPv6). It shares similarities with Content Delivery Networks (CDNs), Global Server Load Balancing (GSLB), DNS Load Balancing, and Split DNS, as described below in Sections 4.3.2, 4.3.3, and 4.3.4. A few high-service-level domains have either implemented DNS Resolver Whitelisting (one of many migration tactics they have used or are using) or are considering doing so [NW-Article-DNS-WL] [WL-Ops].
到DNS递归解析程序发送的DNS查询[RFC1035]。这在互联网社区中通常被称为“DNS解析程序白名单”，并将在下文中被称为“DNS解析程序白名单”，尽管本质上它只是一种策略，能够基于各种技术因素选择性地返回DNS记录。最终用户正在按名称查找资源，而这种选择性响应机制使人们认为最可靠、性能最好的IP地址系列（IPv4或IPv6）得以使用。如下文第4.3.2、4.3.3和4.3.4节所述，它与内容交付网络（CDN）、全局服务器负载平衡（GSLB）、DNS负载平衡和拆分DNS具有相似性。一些高服务级别的域已经实现了DNS解析器白名单（他们已经使用或正在使用的许多迁移策略之一），或者正在考虑这样做[NW Article DNS WL][WL Ops]。
This is a migration tactic used by domains as a method for incrementally transitioning inbound traffic to a domain to IPv6. If an incremental tactic like this is not used, a domain might return AAAA resource records to any relevant DNS query, meaning the domain could go quickly from no IPv6 traffic to a potentially significant amount as soon as the AAAA resource records are published. When DNS Resolver Whitelisting is implemented, a domain's authoritative DNS will selectively return a AAAA resource record to DNS recursive resolvers on a whitelist maintained by the domain, while returning no AAAA resource records to DNS recursive resolvers that are not on that whitelist. This tactic will not have a direct impact on reducing IPv6-related impairments (Section 2.1), though it can help a domain address operational maturity concerns (Section 2.2) as well as concerns and risks related to traffic volume (Section 2.3). While DNS Resolver Whitelisting does not solve IPv6-related impairments, it can help a domain to avoid users that have them. As a result, the tactic removes their impact in all but the few networks that are whitelisted. DNS Resolver Whitelisting also allows website operators to protect non-IPv6 networks (i.e., networks that do not support IPv6 and/or do not have plans to do so in the future) from IPv6-related impairments in their networks. Finally, domains using this tactic should understand that the onus is on them to ensure that the servers being whitelisted represent a network that has proven to their satisfaction that they are IPv6-ready and that this will not create a poor end-user experience for users of the whitelisted server.
这是一种迁移策略，域将其用作将入站流量增量转换到域到IPv6的方法。如果不使用这种增量策略，域可能会将AAAA资源记录返回到任何相关的DNS查询，这意味着一旦发布AAAA资源记录，域可能会很快从没有IPv6流量变为潜在的大量流量。当实施DNS解析程序白名单时，域的权威DNS将有选择地将AAAA资源记录返回给域维护的白名单上的DNS递归解析程序，而不将AAAA资源记录返回给不在该白名单上的DNS递归解析程序。此策略不会对减少IPv6相关损害（第2.1节）产生直接影响，但它可以帮助域解决运营成熟度问题（第2.2节）以及与流量相关的问题和风险（第2.3节）。虽然DNS解析程序白名单不能解决IPv6相关的损害，但它可以帮助域避免拥有这些损害的用户。结果，除了少数被列入白名单的网络外，这一策略消除了它们在所有网络中的影响。DNS解析器白名单还允许网站运营商保护其网络中的非IPv6网络（即不支持IPv6和/或未来不打算支持IPv6的网络）免受IPv6相关损害。最后，使用此策略的域应该明白，他们有责任确保被列入白名单的服务器代表一个网络，该网络已证明其已准备好IPv6，并且不会为白名单服务器的用户创造糟糕的最终用户体验。
There are of course challenges and concerns related to DNS Resolver Whitelisting. Some of the concerns with a whitelist of DNS recursive resolvers may be held by parties other than the implementing domain, such as network operators or end users that may not have had their DNS recursive resolvers added to a whitelist. Additionally, the IP address of a DNS recursive resolver is not a precise indicator of the IPv6 preparedness, or lack of IPv6-related impairment, of end-user
当然，与DNS解析程序白名单相关的挑战和担忧也是存在的。与DNS递归解析器白名单有关的一些问题可能由实施域以外的各方持有，例如可能尚未将其DNS递归解析器添加到白名单的网络运营商或最终用户。此外，DNS递归解析器的IP地址并不是最终用户IPv6准备就绪或缺乏IPv6相关损害的精确指标
hosts that query (use) a particular DNS recursive resolver. While the IP addresses of DNS recursive resolvers on networks known to have deployed IPv6 may be an imperfect proxy for judging IPv6 preparedness, or lack of IPv6-related impairment, this method is one of the better available methods at the current time. For example, implementers have found that it is possible to measure the level of IPv6 preparedness of the end users behind any given DNS recursive resolver by conducting ongoing measurement of the IPv6 preparedness of end users querying for one-time-use hostnames and then correlating the domain's authoritative DNS server logs with their web server logs. This can help implementers form a good picture of which DNS recursive resolvers have working IPv6 users behind them and which do not, what the latency impact of turning on IPv6 for any given DNS recursive resolver is, etc. In addition, given the current state of global IPv6 deployment, this migration tactic allows content providers to selectively expose the availability of their IPv6 services. While opinions in the Internet community concerning DNS Resolver Whitelisting are understandably quite varied, there is clear consensus that DNS Resolver Whitelisting can be a useful tactic for use during the transition of a domain to IPv6. In particular, some high-service-level domains view DNS Resolver Whitelisting as one of the few practical and low-risk approaches enabling them to transition to IPv6, without which their transition may not take place for some time. However, there is also consensus that this practice is workable on a manual basis (see below) only in the short term and that it will not scale over the long term. Thus, some domains may find DNS Resolver Whitelisting a beneficial temporary tactic in their transition to IPv6.
查询（使用）特定DNS递归解析器的主机。虽然已知已部署IPv6的网络上DNS递归解析程序的IP地址可能是判断IPv6准备情况或是否存在IPv6相关损害的不完善代理，但该方法是目前可用性较好的方法之一。例如实施者发现，通过对查询一次性使用主机名的最终用户的IPv6准备情况进行持续测量，然后将域的权威DNS服务器日志与其web服务器日志关联，可以测量任何给定DNS递归解析程序后面的最终用户的IPv6准备情况。这可以帮助实施者很好地了解哪些DNS递归解析程序背后有工作的IPv6用户，哪些没有，为任何给定的DNS递归解析程序打开IPv6的延迟影响是什么，等等。此外，考虑到全球IPv6部署的当前状态，这种迁移策略允许内容提供商有选择地公开其IPv6服务的可用性。虽然互联网社区中关于DNS解析程序白名单的观点差异很大，这是可以理解的，但有一个明确的共识，即DNS解析程序白名单可以是在域过渡到IPv6期间使用的有用策略。特别是，一些高服务级别的域将DNS解析程序白名单视为少数几个实用且低风险的方法之一，使它们能够过渡到IPv6，没有IPv6，它们的过渡可能在一段时间内不会发生。然而，也有一种共识，即这种做法只能在短期内以人工方式（见下文）可行，而且不会在长期内扩大规模。因此，一些域可能会发现DNS解析程序在过渡到IPv6时将白名单列为一种有益的临时策略。
At the current time, generally speaking, a domain that implements DNS Resolver Whitelisting does so manually. This means that a domain manually maintains a list of networks that are permitted to receive IPv6 records (via their DNS resolver IP addresses) and that these networks typically submit applications, or follow some other process established by the domain, in order to be added to the DNS Whitelist. However, implementers foresee that a subsequent phase of DNS Resolver Whitelisting is likely to emerge in the future, possibly in the near future. In this new phase, a domain would return IPv6 and/or IPv4 records dynamically based on automatically detected technical capabilities, location, or other factors. It would then function much like (or indeed as part of) GSLB, a common practice already in use today, as described in Section 4.3.2. Furthermore, in this future phase, networks would be added to and removed from a DNS Whitelist automatically, and possibly on a near-real-time basis. This means, crucially, that networks would no longer need to apply to be added to a whitelist, which may alleviate many of the key concerns that network operators may have with this tactic when it is implemented on a manual basis.
目前，一般来说，实现DNS解析程序白名单的域会手动执行此操作。这意味着域手动维护允许接收IPv6记录（通过其DNS解析程序IP地址）的网络列表，并且这些网络通常提交应用程序，或遵循域建立的某些其他过程，以便添加到DNS白名单中。然而，实现者预见到DNS解析器白名单的后续阶段很可能在未来出现，可能在不久的将来。在此新阶段，域将根据自动检测到的技术能力、位置或其他因素动态返回IPv6和/或IPv4记录。然后，它的功能与GSLB非常相似（或实际上是GSLB的一部分），这是目前已在使用的一种常见做法，如第4.3.2节所述。此外，在未来的这个阶段，网络将自动添加到DNS白名单并从中删除，并且可能是近实时的。这意味着，至关重要的是，网络将不再需要申请加入白名单，这可能会缓解网络运营商在手动实施这一策略时可能面临的许多关键问题。
Using a "whitelist" in a generic sense means that no traffic (or traffic of a certain type) is permitted to the destination host unless the originating host's IP address is contained in the whitelist. In contrast, using a "blacklist" means that all traffic is permitted to the destination host unless the originating host's IP address is contained in the blacklist. In the case of DNS Resolver Whitelisting, the resource that an end user seeks is a name, not an IP address or IP address family. Thus, an end user is seeking a name such as www.example.com, without regard to the underlying IP address family (IPv4 or IPv6) that may be used to access that resource.
使用一般意义上的“白名单”意味着不允许向目标主机发送流量（或特定类型的流量），除非源主机的IP地址包含在白名单中。相比之下，使用“黑名单”意味着所有流量都允许发送到目标主机，除非源主机的IP地址包含在黑名单中。在DNS解析程序白名单的情况下，最终用户寻找的资源是名称，而不是IP地址或IP地址族。因此，最终用户正在寻找诸如www.example.com之类的名称，而不考虑可用于访问该资源的基础IP地址系列（IPv4或IPv6）。
DNS Resolver Whitelisting is implemented in authoritative DNS servers, not in DNS recursive resolvers. These authoritative DNS servers selectively return AAAA resource records using the IP address of the DNS recursive resolver that has sent them a query. Thus, for a given operator of a website, such as www.example.com, the domain operator implements whitelisting on the authoritative DNS servers for the domain example.com. The whitelist is populated with the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on the Internet, which have been authorized to receive AAAA resource record responses. These DNS recursive resolvers are operated by third parties, such as Internet Service Providers (ISPs), universities, governments, businesses, and individual end users. If a DNS recursive resolver is not matched in the whitelist, then AAAA resource records WILL NOT be sent in response to a query for a hostname in the example.com domain (and an A record would be sent). However, if a DNS recursive resolver is matched in the whitelist, then AAAA resource records WILL be sent. As a result, while Section 2.2 of [RFC4213] notes that a stub resolver can make a choice between whether to use a AAAA record or A record response, with DNS Resolver Whitelisting the authoritative DNS server can also decide whether to return a AAAA record, an A record, or both record types.
DNS解析程序白名单在权威DNS服务器中实现，而不是在DNS递归解析程序中实现。这些权威DNS服务器使用已向其发送查询的DNS递归解析程序的IP地址选择性地返回AAAA资源记录。因此，对于网站（如www.example.com）的给定运营商，域运营商在域example.com的权威DNS服务器上实现白名单。白名单中填充了Internet上DNS递归解析程序的IPv4和/或IPv6地址或前缀范围，这些地址或前缀范围已被授权接收AAAA资源记录响应。这些DNS递归解析器由第三方操作，如互联网服务提供商（ISP）、大学、政府、企业和个人最终用户。如果DNS递归解析器在白名单中不匹配，则不会发送AAAA资源记录以响应example.com域中主机名的查询（并且会发送a记录）。但是，如果DNS递归解析器在白名单中匹配，则将发送AAAA资源记录。因此，[RFC4213]的第2.2节指出，存根解析程序可以在使用AAAA记录还是记录响应之间做出选择，而DNS解析程序白名单中的权威DNS服务器也可以决定是否返回AAAA记录、a记录或两种记录类型。
When implemented on a manual basis, DNS Resolver Whitelisting generally means that a very small fraction of the DNS recursive resolvers on the Internet (those in the whitelist) will receive AAAA responses. The large majority of DNS recursive resolvers on the Internet will therefore receive only A resource records containing IPv4 addresses. Domains may find the practice imposes some incremental operational burdens insofar as it can consume staff time to maintain a whitelist (such as additions and deletions to the list), respond to and review applications to be added to a whitelist, maintain good performance levels on authoritative DNS servers as the whitelist grows, create new network monitors to check the health of a whitelist function, perform new types of troubleshooting related to whitelisting, etc. In addition, manually based whitelisting imposes
当以手动方式实现时，DNS解析程序白名单通常意味着互联网上的一小部分DNS递归解析程序（白名单中的那些）将收到AAAA响应。因此，Internet上绝大多数DNS递归解析程序将只接收包含IPv4地址的资源记录。域可能会发现这种做法会带来一些增量操作负担，因为它可能会占用员工时间来维护白名单（例如添加和删除白名单）、响应和审查要添加到白名单的应用程序、随着白名单的增长在权威DNS服务器上保持良好的性能水平，创建新的网络监视器，以检查白名单功能的运行状况，执行与白名单相关的新类型故障排除等。此外，手动设置白名单
some incremental burdens on operators of DNS recursive resolvers (such as network operators), since they will need to apply to be whitelisted with any implementing domains, and will subsequently need processes and systems to track the status of whitelisting applications, respond to requests for additional information pertaining to these applications, and track any de-whitelisting actions.
DNS递归解析程序的运营商（如网络运营商）的一些增量负担，因为他们需要申请任何实施域的白名单，并且随后需要流程和系统来跟踪白名单应用程序的状态，响应有关这些应用程序的其他信息的请求，并跟踪任何取消白名单操作。
When implemented on an automated basis in the future, DNS recursive resolvers listed in the whitelist could expand and contract dynamically, and possibly in near-real time, based on a wide range of factors. As a result, it is likely that the number of DNS recursive resolvers on the whitelist will be substantially larger than when such a list is maintained manually, and it is also likely that the whitelist will grow at a rapid rate. This automation can eliminate most of the significant incremental operational burdens on implementing domains as well as operators of DNS recursive resolvers, which is clearly a factor that is motivating implementers to work to automate this function.
当将来在自动化的基础上实现时，白名单中列出的DNS递归解析器可以根据各种因素动态地扩展和收缩，并且可能是近实时地扩展和收缩。因此，白名单上的DNS递归解析程序的数量可能比手动维护此类列表时大得多，并且白名单也可能快速增长。这种自动化可以消除实施域以及DNS递归解析器操作员的大部分重大增量操作负担，这显然是促使实施者努力实现此功能自动化的一个因素。
Section 4.3.1.1 and Figure 1 provide more details on DNS Resolver Whitelisting in general. In addition, the potential deployment models of DNS Resolver Whitelisting (manual and automated) are described in Section 5. It is also important to note that DNS Resolver Whitelisting also works independently of whether an authoritative DNS server, DNS recursive resolver, or end-user host uses IPv4 transport, IPv6, or both. So, for example, whitelisting may not result in the return of AAAA responses even in those cases where the DNS recursive resolver has queried the authoritative server over an IPv6 transport. This may also be the case in some situations when the end-user host's original query to its DNS recursive resolver was over IPv6 transport, if that DNS recursive resolver is not on a given whitelist. One important reason for this is that even though the DNS recursive resolver may have no IPv6-related impairments, this is not a reliable predictor of whether the same is true of the end-user host. This also means that a DNS Whitelist can contain both IPv4 and IPv6 addresses.
第4.3.1.1节和图1提供了有关DNS解析器白名单的更多详细信息。此外，DNS解析器白名单的潜在部署模型（手动和自动）在第5节中进行了描述。还需要注意的是，DNS解析程序白名单也可以独立于权威DNS服务器、DNS递归解析程序或最终用户主机是否使用IPv4传输、IPv6或两者都使用而工作。因此，例如，白名单可能不会导致返回AAAA响应，即使在DNS递归解析器通过IPv6传输查询权威服务器的情况下也是如此。如果最终用户主机对其DNS递归解析程序的原始查询是通过IPv6传输的，并且该DNS递归解析程序不在给定的白名单上，则在某些情况下也可能出现这种情况。这样做的一个重要原因是，即使DNS递归解析器可能没有与IPv6相关的损害，但这并不能可靠地预测最终用户主机是否存在同样的损害。这也意味着DNS白名单可以同时包含IPv4和IPv6地址。
Specific implementations will vary from domain to domain, based on a range of factors such as the technical capabilities of a given domain. As such, any examples listed herein should be considered general examples and are not intended to be exhaustive.
根据一系列因素（如给定领域的技术能力），不同领域的具体实现会有所不同。因此，本文所列的任何示例都应视为一般示例，并非详尽无遗。
The system logic of DNS Resolver Whitelisting is as follows:
DNS解析器白名单的系统逻辑如下：
1. The authoritative DNS server for example.com receives DNS queries for the A (IPv4) and/or AAAA (IPv6) address resource records for the FQDN www.example.com, for which AAAA (IPv6) resource records exist.
1. example.com的权威DNS服务器接收FQDN www.example.com的A（IPv4）和/或AAAA（IPv6）地址资源记录的DNS查询，其中AAAA（IPv6）资源记录存在。
2. The authoritative DNS server checks the IP address (IPv4, IPv6, or both) of the DNS recursive resolver sending the AAAA (IPv6) query against the whitelist (i.e., the DNS Whitelist).
2. 权威DNS服务器根据白名单（即DNS白名单）检查发送AAAA（IPv6）查询的DNS递归解析程序的IP地址（IPv4、IPv6或两者）。
3. If the DNS recursive resolver's IP address IS matched in the whitelist, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address resource records.
3. 如果DNS递归解析器的IP地址在白名单中匹配，则对该特定DNS递归解析器的响应可以包含AAAA（IPv6）地址资源记录。
4. If the DNS recursive resolver's IP address IS NOT matched in the whitelist, then the response to that specific DNS recursive resolver cannot contain AAAA (IPv6) address resource records. In this case, the server will likely return a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section for the AAAA record query.
4. 如果DNS递归冲突解决程序的IP地址在白名单中不匹配，则对该特定DNS递归冲突解决程序的响应不能包含AAAA（IPv6）地址资源记录。在这种情况下，服务器可能会返回一个响应，响应代码（RCODE）设置为0（无错误），AAAA记录查询的应答部分为空。
+--------------------------------------------------------------------+
| Caching Server 1 - IS NOT ON the DNS Whitelist |
| Caching Server 2 - IS ON the DNS Whitelist |
| Note: Transport between each host can be IPv4 or IPv6. |
+--------------------------------------------------------------------+
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 1 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | NOT on Whitelist
| | DNS Response: |
| | example.com A |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A | |
|<----------------------| |
+--------------------------------------------------------------------+
| Caching Server 1 - IS NOT ON the DNS Whitelist |
| Caching Server 2 - IS ON the DNS Whitelist |
| Note: Transport between each host can be IPv4 or IPv6. |
+--------------------------------------------------------------------+
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 1 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | NOT on Whitelist
| | DNS Response: |
| | example.com A |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A | |
|<----------------------| |
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 2 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | IS on Whitelist
| | DNS Response: |
| | example.com A, AAAA |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A, AAAA | |
|<----------------------| |
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 2 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | IS on Whitelist
| | DNS Response: |
| | example.com A, AAAA |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A, AAAA | |
|<----------------------| |
Figure 1: DNS Resolver Whitelisting Diagram
图1:DNS解析器白名单图
4.3.2. Similarities to Content Delivery Networks and Global Server Load Balancing
4.3.2. 与内容交付网络和全局服务器负载平衡的相似之处
DNS Resolver Whitelisting is functionally similar to CDNs and GSLB. When using a CDN or GSLB, a geographically aware authoritative DNS server function is usually part of that overall system. As a result, the use of a CDN or GSLB with an authoritative DNS server function enables the IP address resource records returned to a resolver in response to a query to vary, based on the estimated geographic location of the resolver [Wild-Resolvers] or a range of other technical factors. This CDN or GSLB DNS function is performed in order to attempt to direct hosts to a) connect either to the nearest host (as measured in round-trip time) or to the host that has the best connectivity to an end user, b) route around failures, c) avoid sites where maintenance work has taken down hosts, and/or d) connect to the host that will otherwise provide the best service experience for an end user at a given point in time. As a result, one can see a direct similarity to DNS Resolver Whitelisting insofar as different IP address resource records are selectively returned to resolvers based on the IP address of each resolver and/or other imputed factors related to that IP address.
DNS解析器白名单在功能上类似于CDN和GSLB。当使用CDN或GSLB时，地理感知权威DNS服务器功能通常是整个系统的一部分。因此，使用具有权威DNS服务器功能的CDN或GSLB使得响应于查询返回到解析程序的IP地址资源记录能够根据解析程序[野生解析程序]的估计地理位置或一系列其他技术因素而变化。执行此CDN或GSLB DNS功能是为了尝试将主机定向到a）连接到最近的主机（按往返时间测量）或与最终用户具有最佳连接的主机，b）绕过故障的路由，c）避免维护工作导致主机停机的站点，和/或d）连接到在给定时间点为最终用户提供最佳服务体验的主机。因此，只要不同的IP地址资源记录基于每个解析程序的IP地址和/或与该IP地址相关的其他插补因子选择性地返回给解析程序，就可以看到与DNS解析程序白名单的直接相似性。
DNS Resolver Whitelisting has some similarities to DNS Load Balancing. There are of course many ways that DNS Load Balancing can be performed. In one example, multiple IP address resource records (A and/or AAAA) can be added to the DNS for a given FQDN. This approach is referred to as DNS round robin [RFC1794]. DNS round robin may also be employed where SRV resource records are used [RFC2782]. In another example, one or more of the IP address resource records in the DNS will direct traffic to a load balancer. That load balancer, in turn, may be application-aware, and pass the traffic on to one or more hosts that are connected to the load balancer and that have different IP addresses. In cases where private IPv4 addresses are used [RFC1918], as well as when public IP addresses are used, those end hosts may not necessarily be directly reachable without passing through the load balancer first. So, similar to DNS Resolver Whitelisting, a load balancer will control what server host an end-user's host communicates with when using an FQDN.
DNS解析程序白名单与DNS负载平衡有一些相似之处。当然，有许多方法可以执行DNS负载平衡。在一个示例中，可以将多个IP地址资源记录（A和/或AAAA）添加到给定FQDN的DNS中。这种方法称为DNS循环[RFC1794]。在使用SRV资源记录的情况下，也可以使用DNS循环[RFC2782]。在另一个示例中，DNS中的一个或多个IP地址资源记录将流量定向到负载平衡器。该负载平衡器又可以是应用程序感知的，并将流量传递给连接到负载平衡器且具有不同IP地址的一个或多个主机。在使用专用IPv4地址[RFC1918]的情况下，以及在使用公共IP地址的情况下，如果不首先通过负载平衡器，这些终端主机不一定可以直接访问。因此，与DNS解析器白名单类似，负载平衡器将控制最终用户的主机在使用FQDN时与哪个服务器主机通信。
DNS Resolver Whitelisting has some similarities to so-called Split DNS, briefly described in Section 3.8 of [RFC2775]. When Split DNS is used, the authoritative DNS server selectively returns different responses, depending upon what host has sent the query. While
DNS解析程序白名单与[RFC2775]第3.8节中简要描述的所谓拆分DNS有一些相似之处。使用拆分DNS时，权威DNS服务器根据发送查询的主机有选择地返回不同的响应。虽然
[RFC2775] notes that the typical use of Split DNS is to provide one answer to hosts on an Intranet (internal network) and a different answer to hosts on the Internet (external or public network), the basic idea is that different answers are provided to hosts on different networks. This is similar to the way that DNS Resolver Whitelisting works, whereby hosts on different networks that use different DNS recursive resolvers receive different answers if one DNS recursive resolver is on the whitelist and the other is not. However, Internet transparency and Internet fragmentation concerns regarding Split DNS are detailed in Section 2.1 of [RFC2956]. Section 2.7 of [RFC2956] notes concerns regarding Split DNS, including the concern that the deployment of Split DNS "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex". Section 3.5 of [RFC2956] further recommends that maintaining a stable approach to DNS operations is key during transitions, such as the one to IPv6 that is underway now, and states that "Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS".
[RFC2775]注意，拆分DNS的典型用途是为Intranet（内部网络）上的主机提供一个答案，为Internet（外部或公共网络）上的主机提供不同的答案，其基本思想是为不同网络上的主机提供不同的答案。这类似于DNS解析程序白名单的工作方式，即如果一个DNS递归解析程序在白名单上而另一个不在白名单上，则使用不同DNS递归解析程序的不同网络上的主机会收到不同的答案。但是，有关拆分DNS的互联网透明度和互联网碎片问题，请参见[RFC2956]的第2.1节。[RFC2956]第2.7节说明了有关拆分DNS的问题，包括拆分DNS的部署“使完全限定域名（FQDN）作为端点标识符的使用更加复杂”的问题。[RFC2956]第3.5节进一步建议，在过渡期间，保持DNS操作的稳定方法是关键，例如目前正在进行的IPv6过渡，并指出“DNS的运行稳定性至关重要，尤其是在网络层过渡期间，IPv6和某些网络地址转换技术都给DNS带来了更大的负担”。
While techniques such as GSLB and DNS Load Balancing -- which share
much in common with DNS Resolver Whitelisting -- are widespread, some
in the community have raised a range of concerns about all of these
practices. Some concerns are specific to DNS Resolver Whitelisting
[WL-Concerns]. Other concerns are not as specific and pertain to the
general practice of implementing content location or other network
policy controls in the "middle" of the network, in a so-called
"middlebox" function. Whether such DNS-related functions are really
part of a middlebox is debatable. Nevertheless, implementers should
at least be aware of some of the risks of middleboxes, as noted in
[RFC3724]. A related document, [RFC1958], explains that configured
state, policies, and other functions needed in the middle of the
network should be minimized as a design goal. In addition,
Section 2.16 of [RFC3234] makes specific statements concerning
modified DNS servers. Section 1.2 of [RFC3234] also outlines more
general concerns about the introduction of new failure modes when
configuration is no longer limited to two ends of a session, so that
diagnosis of failures and misconfigurations could become more
complex. Two additional sources worth considering are [Tussle] and
[Rethinking], in which the authors note concerns regarding the
introduction of new control points (e.g., in middleboxes or in
the DNS).
While techniques such as GSLB and DNS Load Balancing -- which share
much in common with DNS Resolver Whitelisting -- are widespread, some
in the community have raised a range of concerns about all of these
practices. Some concerns are specific to DNS Resolver Whitelisting
[WL-Concerns]. Other concerns are not as specific and pertain to the
general practice of implementing content location or other network
policy controls in the "middle" of the network, in a so-called
"middlebox" function. Whether such DNS-related functions are really
part of a middlebox is debatable. Nevertheless, implementers should
at least be aware of some of the risks of middleboxes, as noted in
[RFC3724]. A related document, [RFC1958], explains that configured
state, policies, and other functions needed in the middle of the
network should be minimized as a design goal. In addition,
Section 2.16 of [RFC3234] makes specific statements concerning
modified DNS servers. Section 1.2 of [RFC3234] also outlines more
general concerns about the introduction of new failure modes when
configuration is no longer limited to two ends of a session, so that
diagnosis of failures and misconfigurations could become more
complex. Two additional sources worth considering are [Tussle] and
[Rethinking], in which the authors note concerns regarding the
introduction of new control points (e.g., in middleboxes or in
the DNS).
However, state, policies, and other functions have always been necessary to enable effective, reliable, and high-quality end-to-end communications on the Internet. In addition, the use of GSLB, CDNs, DNS Load Balancing, and Split DNS are not only widely deployed but are almost uniformly viewed as essential to the functioning of the Internet and highly beneficial to the quality of the end-user experience on the Internet. These techniques have had, and continue to have, a beneficial effect on the experience of a wide range of Internet applications and protocols. So, while there are valid concerns about implementing policy controls in the "middle" of the network, or anywhere away from edge hosts, the definition of what constitutes the middle and edge of the network is debatable in this case. This is particularly so given that GSLBs and CDNs facilitate connections from end hosts and the optimal content hosts, and could therefore be considered a modest and, in many cases, essential network policy extension of a network's edge, especially in the case of high-service-level domains.
然而，国家、政策和其他职能对于在互联网上实现有效、可靠和高质量的端到端通信始终是必要的。此外，GSLB、CDN、DNS负载平衡和拆分DNS的使用不仅被广泛部署，而且几乎被一致认为是互联网功能的关键，对互联网上最终用户体验的质量非常有益。这些技术已经并将继续对各种互联网应用和协议的体验产生有益的影响。因此，尽管在网络的“中间”或远离边缘主机的任何地方实施策略控制都存在合理的顾虑，但在这种情况下，构成网络中间和边缘的定义仍有争议。考虑到GSLBs和CDN促进了来自终端主机和最佳内容主机的连接，因此可以将其视为网络边缘的适度且在许多情况下是基本的网络策略扩展，尤其是在高服务级别域的情况下。
There may be additional implications for end users that have configured their hosts to use a third party as their DNS recursive resolver, rather than the one(s) provided by their network operator. In such cases, it will be more challenging for a domain using whitelisting to determine the level of IPv6-related impairment when such third-party DNS recursive resolvers are used, given the wide variety of end-user access networks that may be used and given that this mix may change in unpredictable ways over time.
对于已将其主机配置为使用第三方（而不是其网络运营商提供的）作为DNS递归解析程序的最终用户，可能会有其他影响。在这种情况下，对于使用白名单的域来说，在使用此类第三方DNS递归解析程序时，确定IPv6相关损害的级别将更具挑战性，因为可能使用的最终用户访问网络种类繁多，而且这种混合可能会随时间以不可预测的方式发生变化。
With DNS Resolver Whitelisting, DNS recursive resolvers can receive AAAA resource records only if they are on the whitelist. DNS Blacklisting is by contrast the opposite of that, whereby all DNS recursive resolvers can receive AAAA resource records unless they are on the blacklist. Some implementers of DNS Resolver Whitelisting may choose to subsequently transition to DNS Blacklisting. It is not clear when and if it may be appropriate for a domain to change from whitelisting to blacklisting, nor is it clear how implementers will judge that network conditions have changed sufficiently to justify disabling such controls.
使用DNS解析程序白名单，DNS递归解析程序只有在AAAA资源记录在白名单上时才能接收这些记录。DNS黑名单与此相反，所有DNS递归解析程序都可以接收AAAA资源记录，除非它们在黑名单上。DNS解析程序白名单的一些实现者可能会选择随后过渡到DNS黑名单。目前尚不清楚域何时以及是否适合从白名单更改为黑名单，也不清楚实施者将如何判断网络条件已经发生了足够的变化，从而有理由禁用此类控制。
When a domain uses blacklisting, it is enabling all DNS recursive resolvers to receive AAAA record responses, except for what is presumed to be a relatively small number that are on the blacklist. Over time, it is likely that the blacklist will become smaller as the networks associated with the blacklisted DNS recursive resolvers are able to meaningfully reduce IPv6-related impairments to some acceptable level, though it is possible that some networks may never achieve that. DNS Blacklisting is also likely less labor intensive
当一个域使用黑名单时，它使所有DNS递归解析程序都能够接收AAAA记录响应，但黑名单上被假定为相对较小的数字除外。随着时间的推移，黑名单可能会变小，因为与黑名单DNS递归解析程序相关联的网络能够有意义地将IPv6相关损害降低到某种可接受的水平，尽管有些网络可能永远无法实现这一点。DNS黑名单也可能不那么劳动密集
for a domain than performing DNS Resolver Whitelisting on a manual basis. This is simply because the domain would presumably be focused on a smaller number of DNS recursive resolvers with well-known IPv6-related problems.
对于域，请不要手动执行DNS解析程序白名单。这仅仅是因为该领域可能会关注数量较少的DNS递归解析程序，这些解析程序具有众所周知的IPv6相关问题。
It is also worth noting that the email industry has a long experience with blacklists and, very generally speaking, blacklists tend to be effective and well received when it is easy to discover if an IP address is on a blacklist, if there is a transparent and easily understood process for requesting removal from a blacklist, and if the decision-making criteria for placing a server on a blacklist are transparently disclosed and perceived as fair. However, in contrast to an email blacklist where a blacklisted host cannot send email to a domain at all, with DNS Resolver Whitelisting, communications will still occur over IPv4 transport.
还值得注意的是，电子邮件行业在黑名单方面有着长期的经验，而且，一般来说，当很容易发现某个IP地址是否在黑名单上，如果有一个透明且易于理解的流程来请求从黑名单中删除时，黑名单往往是有效的，并且广受欢迎，如果将服务器列入黑名单的决策标准被透明地披露并被认为是公平的。然而，与被列入黑名单的主机根本无法向域发送电子邮件的电子邮件黑名单不同，使用DNS解析程序白名单，通信仍将通过IPv4传输进行。
As an alternative to adopting any of the aforementioned migration tactics, domains can choose to transition to native dual stack directly by adding native IPv6 capabilities to their network and hosts and by publishing AAAA resource records in the DNS for their named resources. Of course, a domain can still control this transition gradually, on a name-by-name basis, by adding native IPv6 to one name at a time, such as mail.example.com first and www.example.com later. So, even a "direct" transition can be performed gradually.
作为采用上述任何迁移策略的替代方案，域可以选择直接过渡到本机双堆栈，方法是向其网络和主机添加本机IPv6功能，并在DNS中为其命名资源发布AAAA资源记录。当然，一个域仍然可以通过一次将本机IPv6添加到一个名称（例如先添加mail.example.com，然后添加www.example.com）来逐个名称地逐步控制这种转换。因此，即使是“直接”转换也可以逐渐执行。
It is then up to end users with IPv6-related impairments to discover and fix any applicable impairments. However, the concerns and risks related to traffic volume (Section 2.3) should still be considered and managed, since those are not directly related to such impairments. Not all content providers (or other domains) may face the challenges detailed herein or face them to the same degree, since the user base of each domain, traffic sources, traffic volumes, and other factors obviously vary between domains.
然后，有IPv6相关缺陷的最终用户将发现并修复任何适用的缺陷。但是，仍应考虑和管理与交通量（第2.3节）相关的问题和风险，因为这些问题和风险与此类损害没有直接关系。并非所有内容提供商（或其他域）都可能面临本文详述的挑战，或面临相同程度的挑战，因为每个域的用户基础、流量源、流量和其他因素在域之间明显不同。
For example, while some content providers have implemented DNS Resolver Whitelisting (one migration tactic), others have run IPv6 experiments whereby they added AAAA resource records and observed and measured errors, and then decided not to implement DNS Resolver Whitelisting [Heise]. A more widespread example of such an experiment was World IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011. This was a unique opportunity for hundreds of domains to add AAAA resource records to the DNS without using DNS Resolver Whitelisting, all at the same time. Some of the participating domains chose to leave AAAA resource records in place following the experiment based on their experiences.
例如，虽然一些内容提供商已经实现了DNS解析程序白名单（一种迁移策略），但其他内容提供商已经运行了IPv6实验，通过这些实验，他们添加了AAAA资源记录并观察和测量了错误，然后决定不实现DNS解析程序白名单[Heise]。一个更广泛的例子是2011年6月8日由互联网协会主办的世界IPv6日[W6D]。这是一个独特的机会，数百个域可以在不使用DNS解析程序白名单的情况下同时向DNS添加AAAA资源记录。一些参与的域根据他们的经验选择在实验后保留AAAA资源记录。
Content providers can run their own independent experiments in the future, adding AAAA resource records for a brief period of time (minutes, hours, or days), and then analyzing any impacts or effects on traffic and the experience of end users. They can also simply turn on IPv6 for their domain, which may be easier when the transition does not involve a high-service-level domain.
内容提供商可以在未来运行自己的独立实验，在短时间内（分钟、小时或天）添加AAAA资源记录，然后分析对流量和最终用户体验的任何影响或影响。他们还可以简单地为自己的域打开IPv6，当过渡不涉及高服务级别的域时，这可能会更容易。
The usefulness of each tactic in Section 4, and the associated pros and cons associated with each tactic, are relative to each potential implementer and will therefore vary from one implementer to another. As a result, it is not possible to say that the potential phases below make sense for every implementer. This also means that the duration of each phase will vary between implementers, and even that different implementers may skip some of these phases entirely. Finally, the tactics listed in Section 4 are by no means exclusive.
第4节中每种策略的有用性，以及与每种策略相关联的优缺点，都与每个潜在的实施者相关，因此每个实施者都会有所不同。因此，不可能说下面的潜在阶段对每个实现者都有意义。这也意味着每个阶段的持续时间在实现者之间会有所不同，甚至不同的实现者可能会完全跳过其中的一些阶段。最后，第4节中列出的策略绝不是排他性的。
In this phase, a site is accessible only via IPv4 transport. At the time of this writing, the majority of content on the Internet is in this state and is not accessible natively over IPv6.
在此阶段，只能通过IPv4传输访问站点。在撰写本文时，Internet上的大多数内容都处于这种状态，无法通过IPv6进行本机访问。
One possible first step for a domain is to gain experience using a specialized new FQDN, such as ipv6.example.com or www.ipv6.example.com, as explained in Section 4.2.
域的第一步可能是获得使用专用新FQDN的经验，如ipv6.example.com或www.ipv6.example.com，如第4.2节所述。
As noted in Section 4.3, a domain could begin using DNS Resolver Whitelisting as a way to incrementally enable IPv6 access to content. This tactic may be especially interesting to high-service-level domains.
如第4.3节所述，域可以开始使用DNS解析器白名单作为增量启用IPv6内容访问的方法。这种策略对于高服务级别的域来说可能特别有趣。
For a domain that decides to undertake DNS Resolver Whitelisting on a manual basis, the domain may subsequently move to perform DNS Resolver Whitelisting on an automated basis. This is explained in Section 4.3, and can significantly ease any operational burdens related to a manually maintained whitelist.
对于决定手动执行DNS解析程序白名单的域，该域随后可能会自动执行DNS解析程序白名单。第4.3节对此进行了解释，可以显著减轻与手动维护白名单相关的任何操作负担。
Domains that choose to implement DNS Resolver Whitelisting generally consider it to be a temporary measure. Many implementers have announced that they plan to permanently turn off DNS Resolver Whitelisting beginning on the date of the World IPv6 Launch, on June 6, 2012 [World-IPv6-Launch]. For any implementers that do not turn off DNS Resolver Whitelisting at that time, it may be unclear how each and every one will judge the point in time that network conditions have changed sufficiently to justify turning off DNS Resolver Whitelisting. That being said, it is clear that the extent of IPv6 deployment to end users in networks, the state of IPv6- related impairment, and the maturity of IPv6 operations are all important factors. Any such implementers may wish to take into consideration that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably small number of hosts will inevitably be left behind as end users elect not to upgrade them or because some hosts are incapable of being upgraded.
选择实现DNS解析器白名单的域通常认为它是临时措施。许多实现者已经宣布，他们计划从2012年6月6日世界IPv6发布之日开始永久关闭DNS解析器白名单[世界IPv6-Launch]。对于当时未关闭DNS解析程序白名单的任何实现者，可能不清楚每个人如何判断网络条件已发生足够变化以证明关闭DNS解析程序白名单的合理性的时间点。话虽如此，很明显，网络中最终用户部署IPv6的程度、IPv6相关损害的状态以及IPv6操作的成熟度都是重要因素。任何此类实施者可能希望考虑到，作为一个实际问题，不可能达到不再存在任何IPv6相关损害的程度；由于最终用户选择不升级主机，或者由于某些主机无法升级，一些数量合理的主机将不可避免地落在后面。
Regardless of whether a domain has first implemented DNS Resolver Whitelisting or has never done so, DNS Blacklisting, as described in Section 4.4, may be of interest. This may be at the point in time when domains wish to make their content widely available over IPv6 but still wish to protect end users of a few networks with well-known IPv6 limitations from having a bad end-user experience.
无论域是否首先实现了DNS解析程序白名单，或者从未实现过，如第4.4节所述，DNS黑名单可能会引起关注。这可能是在域名希望通过IPv6广泛提供其内容，但仍希望保护少数具有众所周知的IPv6限制的网络的最终用户，以免其最终用户体验不好的时候。
A domain can arrive at this phase by either following the use of a previous IPv6 migration tactic or going directly to this point, as noted in Section 4.5. In this phase, the site's content has been made natively accessible via both IPv4 and IPv6 for all end users on the Internet, or at least without the use of any other IPv6 migration tactic.
如第4.5节所述，域可以通过使用以前的IPv6迁移策略或直接进入这一阶段来达到这一阶段。在这一阶段，该网站的内容已通过IPv4和IPv6为互联网上的所有最终用户提供了本地访问，或者至少不使用任何其他IPv6迁移策略。
If DNS Resolver Whitelisting is adopted, as noted in Section 4.3, then organizations that apply DNS Resolver Whitelisting policies in their authoritative servers should have procedures and systems that do not allow unauthorized parties to modify the whitelist (or blacklist), just as all configuration settings for name servers should be protected by appropriate procedures and systems. Such
如第4.3节所述，如果采用DNS解析程序白名单，则在其权威服务器中应用DNS解析程序白名单策略的组织应具有不允许未经授权方修改白名单（或黑名单）的程序和系统，正如名称服务器的所有配置设置都应该受到适当的过程和系统的保护一样。这样的
unauthorized additions or removals from the whitelist (or blacklist) can be damaging, causing content providers and/or network operators to incur support costs resulting from end-user and/or customer contacts, as well as causing potential dramatic and disruptive swings in traffic from IPv6 to IPv4 or vice versa.
未经授权从白名单（或黑名单）中添加或删除内容可能会造成损害，导致内容提供商和/或网络运营商因最终用户和/或客户联系而产生支持成本，并导致从IPv6到IPv4的通信量可能发生剧烈和破坏性波动，反之亦然。
DNS Security Extensions (DNSSEC) as defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS Resolver Whitelisting is implemented on an authoritative DNS server, which provides different answers, depending upon which DNS resolver has sent a query, the DNSSEC chain of trust is not altered. So, even though an authoritative DNS server will selectively return AAAA resource records or a non-existence response, both types of responses will be signed and will validate. In practical terms, this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC. As a result, there should not be any negative impact on DNSSEC for those domains that have implemented DNSSEC on their Security-Aware Authoritative Name Servers and also implemented DNS Resolver Whitelisting. As for any party implementing DNSSEC, such domains should of course ensure that resource records are being appropriately and reliably signed and are consistent with the response being returned.
[RFC4033]、[RFC4034]和[RFC4035]中定义的DNS安全扩展（DNSSEC）使用加密数字签名为DNS数据提供原始身份验证和完整性保证。这是通过在安全感知的权威名称服务器上为DNS数据创建签名来完成的，安全感知的解析程序可以使用该服务器来验证答案。由于DNS解析程序白名单是在权威DNS服务器上实现的，根据哪个DNS解析程序发送了查询，该服务器提供不同的答案，因此不会更改DNSSEC信任链。因此，即使权威DNS服务器将有选择地返回AAAA资源记录或不存在的响应，这两种类型的响应都将被签名并进行验证。实际上，这意味着使用两个单独的视图或区域，每个视图或区域都有签名，因此无论是否存在特定的资源记录，仍然可以使用DNSSEC验证记录的存在或不存在。因此，对于已经在其安全感知权威名称服务器上实现了DNSSEC并且还实现了DNS解析程序白名单的那些域，应该不会对DNSSEC产生任何负面影响。对于实施DNSSEC的任何一方来说，这些域当然应该确保资源记录得到适当和可靠的签名，并且与返回的响应一致。
However, network operators that run DNS recursive resolvers should be careful not to modify the responses received from authoritative DNS servers. It is possible that some networks may attempt to do so in order to prevent AAAA record responses from going to end-user hosts, due to some IPv6-related impairment or other lack of IPv6 readiness within that network. But when a network operates a Security-Aware Resolver, modifying or suppressing AAAA resource records for a DNSSEC-signed domain could break the chain of trust established with DNSSEC.
但是，运行DNS递归解析程序的网络运营商应小心，不要修改从权威DNS服务器收到的响应。一些网络可能会尝试这样做，以防止AAAA记录响应发送到最终用户主机，因为该网络中存在一些与IPv6相关的损坏或其他IPv6准备不足的情况。但是，当网络运行安全感知解析器时，修改或禁止DNSSEC签名域的AAAA资源记录可能会打破与DNSSEC建立的信任链。
As noted in Section 4.1, there is a benefit in sharing IPv6-related impairment statistics within the Internet community over time. Any statistics that are shared or disclosed publicly should be aggregate statistics, such as "the domain example.com has observed an average daily impairment rate of 0.05% in September 2011, down from 0.15% in January 2011". They should not include information that can directly
如第4.1节所述，随着时间的推移，在互联网社区内共享与IPv6相关的减值统计数据是有益的。公开共享或披露的任何统计数据均应为汇总统计数据，如“domain example.com观察到2011年9月的平均每日减值率为0.05%，低于2011年1月的0.15%”。它们不应包括可直接使用的信息
or indirectly identify individuals, such as names or email addresses. Sharing only aggregate data can help protect end-user privacy and any information that may be proprietary to a domain.
或间接识别个人，如姓名或电子邮件地址。仅共享聚合数据有助于保护最终用户隐私和域专有的任何信息。
In addition, there are often methods to detect IPv6-related impairments for a specific end user, such as running an IPv6 test when an end user visits the website of a particular domain. Should a domain then choose to automatically communicate the facts of an impairment to an affected user, there are likely no direct privacy considerations. However, if the domain then decides to share information concerning that particular end user with that user's network operator or another third party, then the domain may wish to consider advising the end user of this and seeking to obtain the end-user's consent to share such information.
此外，通常有一些方法可以检测特定最终用户的IPv6相关损害，例如在最终用户访问特定域的网站时运行IPv6测试。如果域选择自动向受影响的用户传达损害的事实，则可能没有直接的隐私考虑。然而，如果域随后决定与该用户的网络运营商或另一方第三共享关于该特定终端用户的信息，则域可能希望考虑向该终端用户提供建议，并寻求获得最终用户同意共享此类信息。
Appropriate guidelines for any information-sharing likely varies by country and/or legal jurisdiction. Domains should consider any potential privacy issues when considering what information can be shared. If a domain does publish or share detailed impairment statistics, it would be well advised to avoid identifying individual hosts or users.
任何信息共享的适当指南可能因国家和/或法律管辖区而异。域名应考虑任何潜在的隐私问题时，考虑什么信息可以共享。如果某个域确实发布或共享详细的减值统计数据，最好避免识别单个主机或用户。
Finally, if a domain chooses to contact end users directly concerning their IPv6 impairments, that domain should ensure that such communication is permissible under any applicable privacy policies of the domain or its websites.
最后，如果域选择就其IPv6损害直接联系最终用户，则该域应确保该域或其网站的任何适用隐私政策允许此类通信。
There are situations where the differing quality of the IPv4 and IPv6 connectivity of an end user could cause complications in accessing content when a domain is using an IPv6 migration tactic. While today most end users' IPv4 connectivity is typically superior to IPv6 connectivity (if such connectivity exists at all), there could be implications when the reverse is true and an end user has markedly superior IPv6 connectivity as compared to IPv4. This is not a theoretical situation; it has been observed by at least one major content provider.
在某些情况下，当域使用IPv6迁移策略时，最终用户IPv4和IPv6连接的不同质量可能会导致访问内容的复杂性。虽然目前大多数最终用户的IPv4连接通常优于IPv6连接（如果存在这种连接），但如果情况正好相反，并且最终用户的IPv6连接明显优于IPv4，则可能会产生影响。这不是一种理论上的情况；至少有一家主要内容提供商观察到了这一点。
For example, in one possible scenario, a user is issued IPv6 addresses by their ISP and has a home network and devices or operating systems that fully support native IPv6. As a result, this theoretical user has very good IPv6 connectivity. However, this end-user's ISP has exhausted their available pool of unique IPv4 addresses, and uses NAT in order to share IPv4 addresses among end users. So, for IPv4 content, the end user must send their IPv4 traffic through some additional network element (e.g., large-scale NAT, proxy server, tunnel server). Use of this additional network
例如，在一种可能的情况下，用户的ISP向其发送IPv6地址，并且用户拥有完全支持本机IPv6的家庭网络和设备或操作系统。因此，该理论用户具有非常好的IPv6连接。但是，该最终用户的ISP已耗尽其唯一IPv4地址的可用池，并使用NAT在最终用户之间共享IPv4地址。因此，对于IPv4内容，最终用户必须通过一些额外的网络元素（例如，大规模NAT、代理服务器、隧道服务器）发送其IPv4流量。使用此附加网络
element might cause an end user to experience sub-optimal IPv4 connectivity when certain protocols or applications are used. This user then has good IPv6 connectivity but impaired IPv4 connectivity. As a result, the user's poor IPv4 connectivity situation could potentially be exacerbated when accessing a domain that is using a migration tactic that causes this user to only be able to access content over IPv4 transport for whatever reason.
元素可能会导致最终用户在使用某些协议或应用程序时体验次优IPv4连接。该用户随后具有良好的IPv6连接，但IPv4连接受损。因此，当访问使用迁移策略的域时，用户的IPv4连接状况可能会恶化，该迁移策略会导致该用户出于任何原因只能通过IPv4传输访问内容。
Should this sort of situation become widespread in the future, a domain may wish to take it into account when deciding how and when to transition content to IPv6.
如果这种情况在未来变得普遍，域可能希望在决定如何以及何时将内容转换到IPv6时将其考虑在内。
The following people made significant textual contributions to this document and/or played an important role in the development and evolution of this document:
以下人员对本文件做出了重要的文字贡献和/或在本文件的发展和演变中发挥了重要作用：
- John Brzozowski - Chris Griffiths - Tom Klieber - Yiu Lee - Rich Woundy
- 约翰·布佐夫斯基-克里斯·格里菲斯-汤姆·克莱伯-姚·李-里奇·沃恩迪
The author and contributors also wish to acknowledge the assistance of the following individuals or groups. Some of these people provided helpful and important guidance in the development of this document and/or in the development of the concepts covered in this document. Other people assisted by performing a detailed review of this document and then providing feedback and constructive criticism for revisions to this document, or engaged in a healthy debate over the subject of the document. All of this was helpful, and therefore the following individuals merit acknowledgement:
作者和撰稿人还希望感谢以下个人或团体的帮助。其中一些人为本文件的编制和/或本文件所涵盖概念的编制提供了有益和重要的指导。其他人员协助对本文件进行详细审查，然后对本文件的修订提供反馈和建设性批评，或者就本文件的主题进行健康的辩论。所有这些都是有益的，因此以下个人值得表扬：
- Bernard Aboba - Mark Andrews - Jari Arkko - Fred Baker - Ron Bonica - Frank Bulk - Brian Carpenter - Lorenzo Colitti - Alissa Cooper - Dave Crocker - Ralph Droms - Wesley Eddy
- 伯纳德·阿博巴-马克·安德鲁斯-贾里·阿克科-弗雷德·贝克-罗恩·博尼卡-弗兰克·布克-布莱恩·卡彭特-洛伦佐·科利蒂-艾丽莎·库珀-戴夫·克罗克-拉尔夫·德罗姆斯-韦斯利·艾迪
- J.D. Falk - Adrian Farrel - Stephen Farrell - Tony Finch - Karsten Fleischhauer - Igor Gashinsky - Wesley George - Philip Homburg - Jerry Huang - Ray Hunter - Joel Jaeggli - Erik Kline - Suresh Krishnan - Victor Kuarsingh - Marc Lampo - Donn Lee - John Leslie - John Mann - Danny McPherson - Milo Medin - Martin Millnert - Russ Mundy - Thomas Narten - Pekka Savola - Robert Sparks - Barbara Stark - Joe Touch - Hannes Tschofenig - Tina Tsou - Members of the Broadband Internet Technical Advisory Group (BITAG)
- J.D.福克-阿德里安·法雷尔-斯蒂芬·法雷尔-托尼·芬奇-卡斯滕·弗莱施豪尔-伊戈尔·加辛斯基-韦斯利·乔治-菲利普·霍姆堡-杰里·黄-雷·亨特-乔尔·贾格利-埃里克·克莱恩-苏雷什·克里希南-维克多·夸辛格-马克·兰波-唐恩·李-约翰·莱斯利-约翰·曼-丹尼·麦克弗森-米洛·梅丁-马丁·米尔内特-罗斯·芒迪-托马斯·纳滕-Pekka Savola-Robert Sparks-Barbara Stark-Joe Touch-Hannes Tschofenig-Tina Tsou-宽带互联网技术咨询小组（BITAG）成员
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[RFC1794]Brisco，T.，“DNS对负载平衡的支持”，RFC17941995年4月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000.
[RFC2956]Kaat，M.，“1999年IAB网络层研讨会概述”，RFC 2956，2000年10月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724]Kempf，J.，Ed.，Austein，R.，Ed.，和IAB，“中部崛起和端到端的未来：互联网架构演变的思考”，RFC 37242004年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[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月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[Heise] Heise.de, "The Big IPv6 Experiment", Heise.de Website http://www.h-online.com, January 2011, <http://www.h-online.com/features/ The-big-IPv6-experiment-1165042.html>.
[Heise]Heise.de，“IPv6大实验”，Heise.de网站http://www.h-online.com，2011年1月<http://www.h-online.com/features/ -big-IPv6-experiment-1165042.html>。
[IETF-77-DNSOP] Gashinsky, I., "IPv6 & recursive resolvers: How do we make the transition less painful?", IETF 77 DNS Operations Working Group, March 2010, <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IETF-77-DNSOP]Gashinsky，I.，“IPv6和递归解析器：我们如何使转换更轻松？”，IETF 77 DNS操作工作组，2010年3月<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6-Brokenness] Anderson, T., "Measuring and Combating IPv6 Brokenness", Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[IPv6断开]Anderson，T.，“测量和打击IPv6断开”，2010年11月，研究IP欧洲（RIME）第61次会议<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[IPv6-Growth] Colitti, L., Gunderson, S., Kline, E., and T. Refice, "Evaluating IPv6 adoption in the Internet", Proceedings of the 11th International Conference on Passive and Active Measurement (PAM 2010), Springer, Lecture Notes in Computer Science, 2010, Volume 6032, Passive and Active Measurement, Pages 141-150.
[IPv6增长]Coletti，L.，Gunderson，S.，Kline，E.，和T.Refice，“评估互联网中IPv6的采用”，第11届被动和主动测量国际会议记录（PAM 2010），Springer，《计算机科学讲稿》，2010年，第6032卷，被动和主动测量，第141-150页。
[NW-Article-DNS-WL] Marsan, C., "Google, Microsoft, Netflix in talks to create shared list of IPv6 users", Network World, March 2010, <http://www.networkworld.com/news/2010/ 032610-dns-ipv6-whitelist.html>.
[NW Article DNS WL]Marsan，C.，“谷歌、微软、Netflix正在谈判创建IPv6用户共享列表”，网络世界，2010年3月<http://www.networkworld.com/news/2010/ 032610-dns-ipv6-whitelist.html>。
[NW-Article-DNSOP] Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Network World, March 2010, <http://www.networkworld.com/ news/2010/032610-yahoo-dns.html>.
[NW Article DNSOP]Marsan，C.，“雅虎提议对DNS进行‘非常丑陋的黑客攻击”，《网络世界》，2010年3月<http://www.networkworld.com/ news/2010/032610 yahoo dns.html>。
[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月。
[Rethinking] Blumenthal, M. and D. Clark, "Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World", ACM Transactions on Internet Technology, Volume 1, Number 1, Pages 70-109, August 2001, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/ Rethinking the design of the internet2001.pdf>.
[反思]Blumenthal，M.和D.Clark，“反思互联网的设计：端到端的争论与勇敢的新世界”，ACM互联网技术交易，第1卷，第1号，第70-109页，2001年8月<http://groups.csail.mit.edu/ana/Publications/PubPDFs/ 反思internet2001.pdf>的设计。
[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of ACM Sigcomm 2002, August 2002, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/ Tussle2002.pdf>.
[Tussle]Clark，D.，Wroclawski，J.，Sollins，K.，和R.Braden，“网络空间中的争斗：定义明天的互联网”，ACM Sigcomm 2002年会议记录，2002年8月<http://groups.csail.mit.edu/ana/Publications/PubPDFs/ Tussle2002.pdf>。
[W6D] The Internet Society, "World IPv6 Day - June 8, 2011", Internet Society Website http://www.isoc.org, January 2011, <http://isoc.org/wp/worldipv6day/>.
[W6D]互联网协会，“世界IPv6日-2011年6月8日”，互联网协会网站http://www.isoc.org，2011年1月<http://isoc.org/wp/worldipv6day/>.
[WL-Concerns] Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?", ISOC (Internet Society) IPv6 Deployment Workshop, April 2010, <http://www.comcast6.net/ IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.
[WL关注点]Brzowski，J.，Griffiths，C.，Klieber，T.，Lee，Y.，Livingood，J.，和R.Woundy，“IPv6 DNS白名单-它会阻碍IPv6的采用吗？”，互联网协会IPv6部署研讨会，2010年4月<http://www.comcast6.net/ IPv6\u DNS\u白名单\u关注点\u 20100416.pdf>。
[WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google IPv6 Implementors Conference, June 2010, <http://sites.google.com/site/ipv6implementors/2010/ agenda/IPv6_Whitelist_Operations.pdf>.
[WL Ops]Kline，E.，“IPv6白名单操作”，谷歌IPv6实施者会议，2010年6月<http://sites.google.com/site/ipv6implementors/2010/ 议程/IPv6\u白名单\u Operations.pdf>。
[Wild-Resolvers] Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, "Comparing DNS Resolvers in the Wild", ACM Sigcomm Internet Measurement Conference 2010, November 2010, <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
[Wild Resolver]Ager，B.，Smaragdakis，G.，Muhlbauer，W.，和S.Uhlig，“在野外比较DNS解析器”，2010年11月ACM Sigcomm互联网测量会议<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
[World-IPv6-Launch] The Internet Society, "World IPv6 Launch Website", June 2012, <http://www.worldipv6launch.org/>.
[World-IPv6-Launch]互联网协会，“世界IPv6发布网站”，2012年6月<http://www.worldipv6launch.org/>.
Author's Address
作者地址
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US
美国宾夕法尼亚州费城约翰·F·肯尼迪大道1701号康卡斯特一号康卡斯特有线通信中心Jason Livingood
EMail: jason_livingood@cable.comcast.com
URI: http://www.comcast.com
EMail: jason_livingood@cable.comcast.com
URI: http://www.comcast.com