Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6586 A. Keranen
Category: Informational Ericsson
ISSN: 2070-1721 April 2012
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6586 A. Keranen
Category: Informational Ericsson
ISSN: 2070-1721 April 2012
Experiences from an IPv6-Only Network
从纯IPv6网络获得的经验
Abstract
摘要
This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.
本文档讨论了我们将少量用户移动到仅限IPv6的网络，并通过NAT64设备访问Internet上仅限IPv4的部分的经验。本文件涵盖了此类网络设置的实际经验、障碍和机会。该文件还就此类网络的适用范围以及网络设计中应考虑的内容提出了一些建议。本文档还讨论了使仅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/rfc6586.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6586.
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 ....................................................3
2. Technology and Terminology ......................................4
3. Network Setup ...................................................4
3.1. The IPv6-Only Network ......................................5
3.2. DNS Operation ..............................................6
4. General Experiences .............................................7
5. Experiences with IPv6-Only Networking ...........................9
5.1. Operating Systems ..........................................9
5.2. Programming Languages and APIs ............................10
5.3. Instant Messaging and VoIP ................................11
5.4. Gaming ....................................................12
5.5. Music Services ............................................13
5.6. Appliances ................................................13
5.7. Other Differences .........................................13
6. Experiences with NAT64 .........................................13
6.1. IPv4 Address Literals .....................................14
6.2. Comparison of Web Access via NAT64 to Other Methods .......15
7. Future Work ....................................................15
8. Conclusions and Recommendations ................................16
9. Security Considerations ........................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Acknowledgments .......................................21
1. Introduction ....................................................3
2. Technology and Terminology ......................................4
3. Network Setup ...................................................4
3.1. The IPv6-Only Network ......................................5
3.2. DNS Operation ..............................................6
4. General Experiences .............................................7
5. Experiences with IPv6-Only Networking ...........................9
5.1. Operating Systems ..........................................9
5.2. Programming Languages and APIs ............................10
5.3. Instant Messaging and VoIP ................................11
5.4. Gaming ....................................................12
5.5. Music Services ............................................13
5.6. Appliances ................................................13
5.7. Other Differences .........................................13
6. Experiences with NAT64 .........................................13
6.1. IPv4 Address Literals .....................................14
6.2. Comparison of Web Access via NAT64 to Other Methods .......15
7. Future Work ....................................................15
8. Conclusions and Recommendations ................................16
9. Security Considerations ........................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Acknowledgments .......................................21
This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. This arrangement has been done with a permanent change in mind rather than as a temporary experiment, involves both office and home users, heterogeneous computing equipment, and varied applications. We have learned both practical details, roadblocks and opportunities, as well as a more general understanding of when such a configuration can be recommended and what should be taken into account in the network design. Note that this memo documents our experiences primarily from 2010. As time goes by, the situation changes with updated software versions, newer products, and so on.
本文档讨论了我们将少量用户移动到仅限IPv6的网络，并通过NAT64设备访问Internet上仅限IPv4的部分的经验。这种安排是永久性的改变，而不是暂时的实验，涉及办公室和家庭用户、异构计算设备和各种应用程序。我们已经了解了实际细节、障碍和机会，以及对何时可以推荐这种配置以及在网络设计中应该考虑什么的更全面理解。请注意，这份备忘录主要记录了我们2010年的经验。随着时间的推移，情况会随着更新的软件版本、更新的产品等而变化。
The networks involved in this setup have been in dual-stack mode for a considerable amount of time, in one case, for over ten years. Our IPv6 connectivity is stable and in constant use with no significant problems. Given that the IETF is working on technology such as NAT64 [RFC6144] and several network providers are discussing the possibility of employing IPv6-only networking, we decided to take our network beyond the "comfort zone" and make sure that we understand the implications of having no IPv4 connectivity at all. This also allowed us to test a NAT64 device that is being developed by Ericsson.
此设置中涉及的网络在相当长的时间内一直处于双堆栈模式，在一个案例中，超过十年。我们的IPv6连接稳定且持续使用，没有重大问题。鉴于IETF正在研究NAT64[RFC6144]等技术，且多家网络供应商正在讨论采用纯IPv6网络的可能性，我们决定将我们的网络置于“舒适区”之外，并确保我们理解完全没有IPv4连接的含义。这也使我们能够测试爱立信正在开发的NAT64设备。
The main conclusion is that it is possible to employ IPv6-only networking, though there are a number of issues such as lack of IPv6 support in some applications and bugs in untested parts of code. As a result, dual-stack [RFC4213] remains as our recommended model for general purpose networking at this time, but IPv6-only networking can be employed by early adopters or highly controlled networks. The document also suggests actions to make IPv6-only networking applicable in all environments. In particular, resolving problems with a few key applications would have a significant impact for enabling IPv6-only networking for large classes of users and networks. It is important that the Internet community understands these deployment barriers and works to remove them.
主要结论是，虽然存在一些问题，如某些应用程序中缺乏IPv6支持，以及未经测试的代码部分存在bug，但也可以只使用IPv6网络。因此，目前双栈[RFC4213]仍然是我们推荐的通用网络模型，但早期采用者或高度控制的网络可以使用仅IPv6网络。该文件还建议采取措施，使仅IPv6联网适用于所有环境。特别是，解决几个关键应用程序的问题将对为大量用户和网络启用仅IPv6联网产生重大影响。互联网社区了解这些部署障碍并努力消除它们是很重要的。
The rest of this document is organized as follows. Section 2 introduces some relevant technology and terms, Section 3 describes the network setup, Section 4 discusses our general experiences, Section 5 discusses experiences related to having only IPv6 networking available, and Section 6 discusses experiences related to NAT64 use. Finally, Section 7 presents some of our ideas for future work, Section 8 draws conclusions and makes recommendations on when and how one should employ IPv6-only networks, and Section 9 discusses relevant security considerations.
本文件其余部分的组织如下。第2节介绍了一些相关技术和术语，第3节介绍了网络设置，第4节讨论了我们的一般经验，第5节讨论了仅使用IPv6网络的相关经验，第6节讨论了NAT64使用的相关经验。最后，第7节介绍了我们对未来工作的一些想法，第8节就何时以及如何使用仅IPv6网络得出结论并提出建议，第9节讨论了相关的安全注意事项。
In this document, the following terms are used. "NAT44" refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663].
在本文件中，使用以下术语。“NAT44”是指[RFC2663]定义的任何IPv4到IPv4网络地址转换算法，包括“基本NAT”和“网络地址/端口转换器（NAPT）”。
"Dual-stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213].
“双栈”指的是在主机和路由器中为互联网协议（IPv4和IPv6）提供完全支持的技术[RFC4213]。
"NAT64" refers to a Network Address Translator - Protocol Translator defined in [RFC6144], [RFC6145], [RFC6146], [RFC6052], [RFC6147], and [RFC6384].
“NAT64”是指[RFC6144]、[RFC6145]、[RFC6146]、[RFC6052]、[RFC6147]和[RFC6384]中定义的网络地址转换器-协议转换器。
We have tested IPv6-only networking in two different network environments: office and home. In both environments, all hosts had normal dual-stack native IPv4 and IPv6 Internet access already in place. The networks were also already employing IPv6 in their servers and DNS records. Similarly, the network was a part of whitelisting arrangement to ensure that IPv6-capable content providers would be able to serve their content to the network over IPv6.
我们已经在两种不同的网络环境中测试了仅限IPv6的网络：办公室和家庭。在这两种环境中，所有主机都具有正常的双栈本机IPv4和IPv6 Internet访问。这些网络还在其服务器和DNS记录中使用IPv6。类似地，网络是白名单安排的一部分，以确保支持IPv6的内容提供商能够通过IPv6向网络提供其内容。
The office environment has heterogeneous hardware with PCs, laptops, and routers running Linux, BSD, Mac OS X, and Microsoft Windows operating systems. Common uses of the network include email, Secure Shell (SSH), web browsing, and various instant messaging and Voice over IP (VoIP) applications. The hardware in the home environment consists of PCs, laptops, and a number of server, camera, and sensor appliances. The primary operating systems in this environment are Linux and Microsoft Windows operating systems. Common applications include web browsing, streaming, instant messaging and VoIP applications, gaming, file storage, and various home control applications. Both environments employ extensive firewalling practices, and filtering is applied for both IPv4 and IPv6 traffic. However, firewall capabilities, especially with older versions of firewall software, dictate some differences between the filtering applied for IPv4 and IPv6 since some features commonly supported for IPv4 were not yet implemented for IPv6. In addition, in the home environment, the individual devices are directly accessible from the Internet on IPv6 (on select protocols such as SSH) but not on IPv4 due to lack of available public IPv4 addresses.
办公环境具有异构硬件，包括运行Linux、BSD、Mac OS X和Microsoft Windows操作系统的PC、笔记本电脑和路由器。网络的常见用途包括电子邮件、Secure Shell（SSH）、web浏览以及各种即时消息和IP语音（VoIP）应用程序。家庭环境中的硬件包括个人电脑、笔记本电脑以及许多服务器、摄像头和传感器设备。此环境中的主要操作系统是Linux和Microsoft Windows操作系统。常见的应用程序包括web浏览、流媒体、即时消息和VoIP应用程序、游戏、文件存储和各种家庭控制应用程序。这两种环境都采用了广泛的防火墙实践，并且对IPv4和IPv6流量都应用了过滤。但是，防火墙功能，特别是较旧版本的防火墙软件，决定了IPv4和IPv6应用的过滤之间的一些差异，因为IPv6尚未实现IPv4通常支持的某些功能。此外，在家庭环境中，由于缺少可用的公共IPv4地址，单个设备可以通过IPv6（在SSH等选定协议上）直接从Internet访问，但不能通过IPv4访问。
In both environments, volunteers had the possibility to opt-in for the IPv6-only network. The number of users was small: there were roughly five permanent users and a dozen users who had been in the network at least for some amount of time. Each user had to connect to the IPv6-only wired or wireless network and, depending on their software, possibly configure their computer by indicating that there is no IPv4 and/or setting DNS server addresses. The users were also asked to report their experiences back to the organizers.
在这两种环境中，志愿者都可以选择只使用IPv6的网络。用户数量很少：大约有5个永久用户和12个至少在网络中呆了一段时间的用户。每个用户都必须连接到仅限IPv6的有线或无线网络，并且根据他们的软件，可能通过指示没有IPv4和/或设置DNS服务器地址来配置他们的计算机。用户还被要求向组织者报告他们的经历。
The IPv6-only network was provided as a parallel network on the side of the already existing dual-stack network. It was important to retain the dual-stack network for the benefit of those users who did not decide to opt-in and because we knew that there were some IPv4- only devices in the network. A separate wired access network was created using Virtual Local Area Networks (VLANs). This network had its own IPv6 prefix. A separate wireless network, bridged to the wired network, was also created. In our case, the new wireless network required additional access point hardware in order to accommodate advertising multiple wireless networks. The simple access point model that we employed in these networks did not allow this on a single device, although many other access points support this. All the secondary infrastructure resulted in some additional management burden and cost, however. An added complexity was that the home network already employed two types of infrastructure, one for family members and another one for visitors. In order to duplicate this model for the IPv6-only network, there are now four separate networks, with several access points on each.
仅IPv6网络作为并行网络提供在现有双栈网络的一侧。为了那些没有决定选择加入的用户的利益，保留双栈网络非常重要，因为我们知道网络中有一些只使用IPv4的设备。使用虚拟局域网（VLAN）创建了一个单独的有线接入网络。此网络有自己的IPv6前缀。一个单独的无线网络，桥接到有线网络，也被创建。在我们的例子中，新的无线网络需要额外的接入点硬件，以适应多个无线网络。我们在这些网络中采用的简单接入点模型不允许在单个设备上实现这一点，尽管许多其他接入点支持这一点。然而，所有的二级基础设施都带来了一些额外的管理负担和成本。更复杂的是，家庭网络已经采用了两种类型的基础设施，一种用于家庭成员，另一种用于访客。为了在仅IPv6的网络上复制此模型，现在有四个独立的网络，每个网络上有多个接入点。
A stateful NAT64 [RFC6146] with integrated DNS64 was installed on the edge of the IPv6-only networks. No IPv4 routing or Dynamic Host Configuration Protocol (DHCP) was offered on these networks. The NAT64 device sends Router Advertisements (RAs) [RFC4861] from which the hosts learn the IPv6 prefix and can automatically configure IPv6 addresses for them. Each new IPv6-only network needed one new /64 prefix to be used in these advertisements. In addition, each NAT64 device needed another /64 prefix to be used for the representation of IPv4 destinations in the IPv6-only network. As a result, one IPv6- only network requires /63 of address space. This space was easily available in our networks, as IPv6 allocations are purposefully made in sufficiently large blocks. Additional address space needs can be accommodated from the existing block without registry involvement. Another option would have been to use the Well-Known Prefix [RFC6052] for the representation of IPv4 destinations in the IPv6-only network. In any case, the prefixes have to be listed in the intra-domain routing system so that they can be reached. In one case, the
在仅IPv6网络的边缘上安装了带有集成DNS64的有状态NAT64[RFC6146]。这些网络上未提供IPv4路由或动态主机配置协议（DHCP）。NAT64设备发送路由器广告（RAs）[RFC4861]，主机从中学习IPv6前缀，并可以自动为其配置IPv6地址。每个仅限IPv6的新网络都需要在这些播发中使用一个新的/64前缀。此外，每个NAT64设备都需要另一个/64前缀，用于表示纯IPv6网络中的IPv4目的地。因此，一个只支持IPv6的网络需要1/63的地址空间。这个空间在我们的网络中很容易获得，因为IPv6分配是有目的地在足够大的块中进行的。在不涉及注册表的情况下，可以从现有块中满足额外的地址空间需求。另一种选择是使用众所周知的前缀[RFC6052]表示纯IPv6网络中的IPv4目的地。在任何情况下，必须在域内路由系统中列出前缀，以便访问它们。在其中一个案例中，该公司
increase from one block to multiple also made it necessary to employ an improved routing configuration. In addition to routing, the new prefixes have to be listed in the appropriate firewall rules.
从一个块增加到多个块也使得有必要采用改进的路由配置。除了路由，新的前缀必须在相应的防火墙规则中列出。
Setting up NAT64 and DNS64 by themselves is easy and can be done quickly by an experienced network manager. However, when duplicate infrastructure is needed for dual-stack and IPv6-only networks, the additional switches, cables, access points, etc., will take some amount of installation effort. In addition, if whitelisting agreements or IPv6 ISP connectivity is needed, setting these up requires negotiations with external partners.
自行设置NAT64和DNS64很容易，而且可以由经验丰富的网络管理器快速完成。然而，当双栈和仅IPv6网络需要重复的基础设施时，额外的交换机、电缆、接入点等将需要一些安装工作量。此外，如果需要白名单协议或IPv6 ISP连接，则设置这些协议需要与外部合作伙伴协商。
Router Advertisements are used to carry DNS Configuration options [RFC6106], listing the DNS64 as the DNS server the hosts should use. In addition, aliases were added to the DNS64 device to allow it to receive packets on the well-known DNS server addresses that Windows operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0: 0:0:ffff::3). At a later stage, support for stateless DHCPv6 [RFC3736] was added. We do recommend enabling RFC 6106, well-known addresses, and stateless DHCPv6 in order to maximize the likelihood of different types of IPv6-only hosts being able to use DNS without manual configuration. DNS server discovery was never a problem in dual-stack networks, because DNS servers on the IPv4 side can easily provide IPv6 information (AAAA records) as well. With IPv6-only networking, it becomes crucial that the local DNS server can also be reached via IPv6. In principle, this is exactly the same as needing IPv4-based DNS and DNS discovery in IPv4-only networks. However, in IPv6, the discovery mechanisms are somewhat more complicated because there are several alternative techniques.
路由器广告用于承载DNS配置选项[RFC6106]，将DNS64列为主机应使用的DNS服务器。此外，还向DNS64设备添加了别名，以允许其在Windows操作系统使用的众所周知的DNS服务器地址（fec0:0:ffff:：1、fec0:0:ffff:：2和fec0:0:ffff:：3）上接收数据包。在后期，添加了对无状态DHCPv6[RFC3736]的支持。我们建议启用RFC 6106、已知地址和无状态DHCPv6，以便最大限度地提高不同类型的仅IPv6主机能够使用DNS而无需手动配置的可能性。DNS服务器发现在双栈网络中从来都不是问题，因为IPv4端的DNS服务器也可以轻松提供IPv6信息（AAAA记录）。使用仅限IPv6的网络，也可以通过IPv6访问本地DNS服务器变得至关重要。原则上，这与只在IPv4网络中需要基于IPv4的DNS和DNS发现完全相同。然而，在IPv6中，发现机制有些复杂，因为有几种替代技术。
When a host served by the DNS64 asks for a domain name that does not have a AAAA (IPv6 address) record, but has an A (IPv4 address) record, a AAAA record is synthesized from the A record (as defined for DNS64 in [RFC6147]) and sent in the DNS response to the host. IP packets sent to this synthesized address are routed via the NAT64, translated to IPv4 by the NAT64, and forwarded to the queried host's IPv4 address; return traffic is translated back from IPv4 to IPv6 and forwarded to the host behind the NAT64 (as described in [RFC6144]). This allows the hosts in the IPv6-only network to contact any host in the IPv4 Internet as long as the hosts in the IPv4 Internet have DNS address records.
当DNS64服务的主机请求一个没有AAAA（IPv6地址）记录但有a（IPv4地址）记录的域名时，AAAA记录从a记录（如[RFC6147]中对DNS64的定义）合成，并在DNS响应中发送给主机。发送到此合成地址的IP数据包通过NAT64路由，由NAT64转换为IPv4，并转发到查询主机的IPv4地址；返回流量从IPv4转换回IPv6，并转发到NAT64后面的主机（如[RFC6144]中所述）。这允许仅IPv6网络中的主机联系IPv4 Internet中的任何主机，只要IPv4 Internet中的主机具有DNS地址记录。
The NAT64 devices have standard dual-stack connectivity and their DNS64 function can use both IPv4 and IPv6 when requesting information from DNS. A destination that has both an A and AAAA records is not treated in any special manner, because the hosts in the IPv6-only
NAT64设备具有标准的双堆栈连接，当从DNS请求信息时，其DNS64功能可以同时使用IPv4和IPv6。同时具有A和AAAA记录的目标不会以任何特殊方式处理，因为只有IPv6中的主机
network can contact the destination over IPv6. Destinations with only an A record will be given a synthesized AAAA record as explained above. However, in one of our open visitor networks that is sharing the infrastructure with the home network, we needed a special arrangement. Currently, the home network obtains its IPv6 connectivity through a tunnel via the office network, and it is undesirable to allow outsiders using the visitor network to generate traffic through the office network, even if the traffic is just passing by and forwarded to the IPv6 Internet. As a result, in the visitor network, there is a special IPv6-only to IPv4-only configuration where the DNS64 never asks for AAAA records and always generates synthesized records. Therefore, no traffic from the visitor network, even if it is destined to the IPv6 Internet, is routed via the office network, but traffic from the home network can still use the IPv6 connectivity provided by the office network.
网络可以通过IPv6与目标联系。如上文所述，只有A记录的目的地将获得合成AAAA记录。然而，在与家庭网络共享基础设施的开放访客网络中，我们需要特殊安排。目前，家庭网络通过办公室网络通过隧道获得其IPv6连接，并且不希望允许使用访客网络的外部人员通过办公室网络生成流量，即使流量只是经过并转发到IPv6 Internet。因此，在访问者网络中，存在一种特殊的仅IPv6到仅IPv4的配置，其中DNS64从不要求AAAA记录，而是始终生成合成记录。因此，来自访客网络的流量（即使其目的地是IPv6 Internet）不会通过办公网络进行路由，但来自家庭网络的流量仍可使用办公网络提供的IPv6连接。
Note: This configuration may also be useful for other purposes. For instance, one drawback of the standard behavior is that if a destination publishes AAAA records but has bad IPv6 connectivity, the hosts in the IPv6-only network have no fallback. In the dual-stack model, a host can always try IPv4 if the IPv6 connection fails. In the special configuration, IPv6 is only used internally at the site but never across the Internet, eliminating this problem. This is not a recommended mode of operation, but it is interesting to note that it may solve some issues.
注意：此配置也可用于其他目的。例如，标准行为的一个缺点是，如果目标发布AAAA记录但IPv6连接不良，则仅IPv6网络中的主机没有回退。在双栈模型中，如果IPv6连接失败，主机始终可以尝试IPv4。在特殊配置中，IPv6仅在站点内部使用，而不在Internet上使用，从而消除了此问题。这不是推荐的操作模式，但值得注意的是，它可以解决一些问题。
Note that in NAT64 (unlike in its older variant [RFC4966]) it is possible to decouple the packet translation, IPv6 routing, and DNS64 functions. Since clients are configured to use a DNS64 as their DNS server, there is no need for having an Application Layer Gateway (ALG) on the path sniffing and spoofing DNS packets. This decoupling possibility was implemented by one of our users, as he is outside of our physical network and wants to communicate directly on IPv6 where it is possible without having to go through our central network equipment. His DNS queries go to our DNS64 and to establish communications to an IPv4 destination our central NAT64 is used. If there is a need to translate some packets, these packets find the translator device through normal IPv6 routing means since the synthesized addresses have our NAT64's prefix. However, for non-synthesized IPv6 addresses the packets are routed directly to the destination.
请注意，在NAT64中（与旧版本[RFC4966]不同），可以解耦数据包转换、IPv6路由和DNS64功能。由于客户端配置为使用DNS64作为其DNS服务器，因此不需要在路径上设置应用层网关（ALG）来嗅探和欺骗DNS数据包。这种脱钩的可能性是由我们的一位用户实现的，因为他不在我们的物理网络中，希望在IPv6上直接通信，而无需通过我们的中央网络设备。他的DNS查询转到我们的DNS64，并使用我们的中央NAT64与IPv4目的地建立通信。如果需要翻译某些数据包，这些数据包通过正常的IPv6路由方式找到转换器设备，因为合成的地址具有NAT64的前缀。但是，对于非合成IPv6地址，数据包直接路由到目的地。
Based on our experiences, it is possible to live (and work) with an IPv6-only network. For instance, at the time of this writing, one of the authors has been in an IPv6-only network for about a year and a half and has had no major problems. Most things work well in the new
根据我们的经验，使用仅限IPv6的网络生活（和工作）是可能的。例如，在撰写本文时，其中一位作者在仅使用IPv6的网络中工作了大约一年半，没有遇到任何重大问题。在新的环境中，大多数事情都很顺利
environment; for example, we have been unable to spot any practical difference in the web browsing (HTTP and HTTPS) experience. Also, email, software upgrades, operating system services, many chat systems, and media streaming work well. On certain Symbian mobile handsets that we tried, all applications work even on an IPv6-only network. In another case, with the Android operating system, all the basic applications worked without problems. In order to make the latter handset architecture support IPv6-only networks, however, a small change was needed in the operating system so that it could discover IPv6-only DNS servers.
环境例如，我们无法发现web浏览（HTTP和HTTPS）体验中的任何实际差异。此外，电子邮件、软件升级、操作系统服务、许多聊天系统和媒体流也能很好地工作。在我们尝试过的某些Symbian手机上，所有应用程序都可以工作，即使是在仅限IPv6的网络上。在另一个例子中，使用Android操作系统，所有的基本应用程序都可以正常工作。然而，为了使后一种手持设备体系结构支持仅限IPv6的网络，需要在操作系统中进行一些小的更改，以便它能够发现仅限IPv6的DNS服务器。
However, in general, there is some pain involved and thus IPv6-only networking is not suitable for everyone just yet. Switching IPv4 off does break many things as well. Some of the users in our environment left due to these issues, as they missed some key feature that they needed from their computing environment. These issues fall in several categories:
然而，总的来说，这会带来一些痛苦，因此仅IPv6网络还不适合所有人。关闭IPv4也会破坏很多东西。由于这些问题，我们环境中的一些用户离开了，因为他们错过了他们的计算环境所需要的一些关键功能。这些问题分为几类：
Bugs
漏洞
We saw many issues that can be classified as bugs, likely related to so few people having tried the software in question in an IPv6- only network. For instance, some operating system facilities support IPv6 but have annoying problems that are only uncovered in IPv6-only networking.
我们看到了许多可以归类为bug的问题，很可能是因为很少有人在纯IPv6的网络中尝试过该软件。例如，一些操作系统设施支持IPv6，但有一些恼人的问题，这些问题只有在纯IPv6网络中才能发现。
Lack of IPv6 Support
缺乏IPv6支持
We also saw many applications that do not support IPv6 at all. These range from minor, old tools (such as the Unix dict(1) command) to major applications that are important to our users (such as Skype) and even to entire classes of applications (many games have issues). As our experiment continued, we have seen improvements in some areas, such as gaming.
我们还看到许多应用程序根本不支持IPv6。这些工具从小型的旧工具（如Unix dict（1）命令）到对我们的用户很重要的主要应用程序（如Skype），甚至到整个应用程序类别（许多游戏都有问题）。随着实验的继续，我们看到了一些领域的进步，比如游戏。
Protocol, Format, and Content Problems
协议、格式和内容问题
There are many protocols that carry IP addresses in them, and using these protocols through a translator can lead to problems. In our current network setup, we did not employ any ALGs except for FTP [RFC6384]. However, we have observed a number of protocol issues with IPv4 addresses. For instance, some instant messaging services do not work due to this. Finally, content on some web pages may refer to IPv4 address literals (i.e., plain IP addresses instead of host and domain names). This renders some links inaccessible in an IPv6-only network. While this problem is easily quantifiable in measurements, the authors have run into it only a couple of times during real-life web browsing.
有许多协议在其中携带IP地址，通过转换器使用这些协议可能会导致问题。在我们当前的网络设置中，除了FTP[RFC6384]之外，我们没有使用任何ALG。但是，我们发现IPv4地址存在许多协议问题。例如，一些即时消息服务因此无法工作。最后，某些网页上的内容可能涉及IPv4地址文本（即普通IP地址，而不是主机名和域名）。这使得某些链接在仅IPv6的网络中无法访问。虽然这个问题在测量中很容易量化，但作者在现实网络浏览中只遇到过几次。
Firewall Issues
防火墙问题
We also saw a number of issues related to lack of features in IPv6 support in firewalls. In particular, while we did not experience any Maximum Transmission Unit (MTU) and fragmentation problems in our networks, there is potential for generating problems, as the support for IPv6 fragment headers is not complete in all firewalls and the NAT64 specifications call for use of the fragment header (even in situations where fragmentation has not yet occurred, e.g., if an IPv4 packet that is not a fragment does not have the Don't Fragment (DF) bit set).
我们还看到了一些与防火墙中IPv6支持功能缺失相关的问题。特别是，虽然我们的网络中没有遇到任何最大传输单元（MTU）和碎片问题，但有可能产生问题，因为并非所有防火墙都支持IPv6碎片头，NAT64规范要求使用碎片头（即使在尚未发生碎片的情况下，例如，如果不是碎片的IPv4数据包没有设置Don't fragment（DF）位）。
In general, most of the issues relate to poor testing and lack of IPv6 support in some applications. IPv6 itself and NAT64 did not cause any major issues for us, once our setup and NAT64 software was stable. In general, the authors feel that with the exception of some applications, our experience with translation to reach the IPv4 Internet has been equal to our past experiences with NAT44-based Internet access. While translation implies loss of end-to-end connectivity, in practice, direct connectivity has also not been available to the authors in the IPv4 Internet for a number of years.
一般来说，大多数问题都与测试不佳以及某些应用程序中缺乏IPv6支持有关。一旦我们的设置和NAT64软件稳定，IPv6本身和NAT64并没有给我们带来任何重大问题。总的来说，作者认为，除了一些应用程序外，我们通过翻译实现IPv4互联网的经验与我们过去基于NAT44的互联网接入的经验是相同的。虽然翻译意味着端到端连接的丢失，但实际上，IPv4互联网上的作者已经有好几年没有直接连接了。
It should be noted that the experience with a properly configured set of ALGs and workarounds such as proxies may be different. Some of the problems we encountered can be solved through these means. For instance, a problematic application can be configured to use a proxy that in turn has both IPv4 and IPv6 access.
应该注意的是，使用一组正确配置的ALG和代理等变通方法的经验可能会有所不同。我们遇到的一些问题可以通过这些方法解决。例如，可以将有问题的应用程序配置为使用代理，该代理又具有IPv4和IPv6访问权限。
The overall experience was as explained above. The remainder of this section discusses specific issues with different operating systems, programming languages, applications, and appliances.
总体经验如上所述。本节的其余部分将讨论不同操作系统、编程语言、应用程序和设备的具体问题。
Even operating systems have some minor problems with IPv6. For example, in Linux, Router Advertisement (RA) information is not automatically updated when the network changes while the computer is on, and this requires an unnecessary suspend/resume cycle to restore its proper state. We have also had issues with the rdnssd daemon, which first does not come as a default feature in Ubuntu and does not always appear to work reliably. To resolve these issues, we had to configure the network manager to use a specific server address. Later, a new version of the Linux distribution that we used solved these problems, even if some problems still remained. For instance, in the latest Ubuntu Long-Term Support release (10.04), we have experienced that the network manager by default returns to an
甚至操作系统在IPv6上也有一些小问题。例如，在Linux中，当计算机处于开机状态时网络发生变化时，路由器广告（RA）信息不会自动更新，这需要一个不必要的挂起/恢复周期来恢复其正确状态。我们还遇到了rdnsd守护进程的问题，它首先不是Ubuntu中的默认功能，而且似乎并不总是可靠地工作。为了解决这些问题，我们必须将网络管理器配置为使用特定的服务器地址。后来，我们使用的Linux发行版的新版本解决了这些问题，即使有些问题仍然存在。例如，在最新的Ubuntu长期支持版本（10.04）中，我们体验到网络管理器在默认情况下返回到
available IPv4 wireless network even if there is a previously used IPv6-only network available and the IPv4 network has no global connectivity before a web-based login is completed.
可用的IPv4无线网络，即使以前使用的只有IPv6的网络可用，并且IPv4网络在基于web的登录完成之前没有全局连接。
In Mac OS X (Snow Leopard), the network manager needed to be explicitly told not to expect IPv4. A more annoying issue was that in order to switch between an IPv6-only and IPv4-only network, these settings had to be manually changed, making it undesirable for Mac OS X users to employ IPv6-only networks.
在Mac OS X（Snow Leopard）中，需要明确告知网络管理器不要使用IPv4。一个更令人恼火的问题是，为了在纯IPv6和纯IPv4网络之间切换，必须手动更改这些设置，这使得Mac OS X用户不希望使用纯IPv6网络。
Also, on Microsoft Windows 7, we experienced problems when relying on default, well-known DNS server addresses: without manual configuration, the host was unable to use the DNS addresses, even though the system displays them as current DNS server addresses.
此外，在Microsoft Windows 7上，我们在依赖默认的、众所周知的DNS服务器地址时遇到了问题：没有手动配置，主机无法使用DNS地址，即使系统将其显示为当前DNS服务器地址。
Latest versions of the Android operating system support IPv6 on its wireless LAN interface, but due to lack of DNS discovery mechanisms, this does not work in IPv6-only networks. We corrected this, however, and prototype phones in our networks work well now, even in an IPv6-only environment. This change, DNS Discovery Daemon (DDD) now exists as open source software. Interestingly, all applications that we have tried so far seem to work without problems with IPv6- only connectivity, though no exhaustive testing was done, nor did we try known troublesome applications.
最新版本的Android操作系统在其无线LAN接口上支持IPv6，但由于缺少DNS发现机制，这在仅IPv6的网络中不起作用。然而，我们纠正了这一点，我们网络中的原型手机现在运行良好，即使是在仅限IPv6的环境中。这个改变，DNS发现守护程序（DDD）现在作为开源软件存在。有趣的是，到目前为止，我们尝试过的所有应用程序似乎都可以在仅IPv6连接的情况下正常工作，尽管没有进行详尽的测试，我们也没有尝试已知的麻烦应用程序。
While all these operating systems (or their predecessors) have already supported IPv6 for a number of years, these kinds of small glitches seem to imply that they have not been thoroughly tested in networks lacking IPv4 connectivity. At the very least, their usability leaves something to be desired.
虽然所有这些操作系统（或其前身）已经支持IPv6多年，但这些小故障似乎意味着它们尚未在缺乏IPv4连接的网络中进行彻底测试。至少，它们的可用性还有待改进。
For applications to be able to support IPv6, they need access to the necessary APIs. Luckily, IPv6 seems to be well supported by a majority of the commonly used APIs. The Perl programming language used to be an exception with only partial IPv6 support up to the version 5.14 (released May 14, 2011). This version finally includes full IPv6 support, with that in the core libraries and older modules being updated as well. With previous versions of Perl, while IPv6 socket support is available as an extension module, it may not be possible to install this module without administrative rights. This has also resulted in other networking core libraries (such as FTP and SMTP) not being able to fully support IPv6; thus, many existing Perl programs using network functionality may not work properly in an IPv6-only environment.
为了使应用程序能够支持IPv6，它们需要访问必要的API。幸运的是，IPv6似乎得到了大多数常用API的良好支持。Perl编程语言曾经是一个例外，在版本5.14（2011年5月14日发布）之前，它只支持部分IPv6。此版本最终包括对IPv6的全面支持，核心库和旧模块中的支持也将得到更新。对于以前版本的Perl，虽然IPv6套接字支持作为扩展模块提供，但如果没有管理权限，可能无法安装此模块。这也导致其他网络核心库（如FTP和SMTP）无法完全支持IPv6；因此，许多使用网络功能的现有Perl程序可能无法在仅IPv6的环境中正常工作。
By far, the biggest complaint from our group of users was that Skype stopped working. In some environments, even Skype can be made to work through a proxy configuration, and this was verified in our setting but not used as a permanent solution. More generally, we tested a number of instant messaging applications in an IPv6-only network with NAT64; the test results can be found in Table 1. The versions used in the tests were the latest versions available in the summer of 2010.
到目前为止，我们用户组最大的抱怨是Skype停止工作。在某些环境中，甚至可以通过代理配置使Skype工作，这已在我们的设置中得到验证，但未用作永久解决方案。更一般地说，我们使用NAT64在仅限IPv6的网络中测试了许多即时消息应用程序；试验结果见表1。测试中使用的版本是2010年夏天可用的最新版本。
SYSTEM STATUS
系统状态
Facebook on the web (http) OK Facebook via a client (xmpp) OK Jabber.org chat service (xmpp) OK Gmail chat on the web (http) OK Gmail chat via a client (xmpp) OK Google Talk client NOT OK AIM (AOL) NOT OK ICQ (AOL) NOT OK Skype NOT OK MSN NOT OK Webex NOT OK Sametime OK (NOW)
网上Facebook（http）OK通过客户端Facebook（xmpp）OK Jabber.org聊天服务（xmpp）OK Gmail网上聊天（http）OK Gmail通过客户端聊天（xmpp）OK Google Talk客户端不OK AIM（AOL）不OK ICQ（AOL）不OK Skype不OK MSN不OK Webex不OK Sametime OK（现在）
Table 1. Instant Messaging Applications in an IPv6-Only Network
表1。仅IPv6网络中的即时消息应用程序
Packet tracing revealed that the issues in AIM, ICQ, and MSN appear to be related to passing literal IPv4 addresses in the protocol. It remains to be determined whether this can be solved through configuration, proxies, or ALGs. The problem with the Google Talk client is that the software does not support IPv6 connections at this time. We are continuing our tests with additional applications, and we have also seen changes over time. For instance, a new version of Sametime suddenly started working with IPv6-only networks, presumably due to the new version being more careful with the use of DNS names as opposed to IPv4 addresses. One problem in running these tests is to ensure that we can distinguish IPv6 and NAT64 issues from other issues, such as a generic issue on a given operating system platform.
数据包跟踪显示，AIM、ICQ和MSN中的问题似乎与在协议中传递文本IPv4地址有关。这一问题是否可以通过配置、代理或ALG解决尚待确定。Google Talk客户端的问题是，该软件目前不支持IPv6连接。我们正在继续使用其他应用程序进行测试，并且随着时间的推移，我们也看到了变化。例如，Sametime的新版本突然开始使用仅限IPv6的网络，这可能是因为新版本在使用DNS名称而不是IPv4地址时更加小心。运行这些测试的一个问题是确保我们能够区分IPv6和NAT64问题与其他问题，例如给定操作系统平台上的一般问题。
Some of these problems are solvable, however. For instance, we used localhost as a proxy for Skype, and then used SSH to tunnel to an external web proxy, bypassing Skype's limitations with regard to connecting to IPv6 destinations or even IPv6 proxies.
然而，其中一些问题是可以解决的。例如，我们使用localhost作为Skype的代理，然后使用SSH通过隧道连接到外部web代理，绕过Skype在连接到IPv6目标甚至IPv6代理方面的限制。
Another class of applications that we tried was games. We tried both web-based gaming and standalone gaming applications that have "network", "Internet", or "LAN" gaming modes. The results are shown in Table 2.
我们尝试的另一类应用程序是游戏。我们尝试了基于网络的游戏和具有“网络”、“互联网”或“局域网”游戏模式的独立游戏应用程序。结果如表2所示。
SYSTEM STATUS
系统状态
Web-based (e.g., armorgames) OK Runescape (on the web) NOT OK Flat out 2 NOT OK Battlefield NOT OK Secondlife NOT OK Guild Wars NOT OK Age of Empires NOT OK Star Wars: Empire at War NOT OK Crysis NOT OK Lord of the Rings: Conquest NOT OK Rome Total War NOT OK Lord of the Rings: Battle for Middle Earth 2 NOT OK
基于网络的（例如，armorgames）OK Runescape（在网络上）不正常2不正常战场不正常第二人生不正常激战不正常帝国时代不正常星球大战：帝国战争不正常水晶不正常指环王：征服不正常罗马全面战争不正常指环王：中土之战2不正常
Table 2. Gaming Applications in an IPv6-Only Network
表2。仅IPv6网络中的游戏应用程序
Most web-based games worked well, as expected from our earlier good general web experience. However, we were also able to find one web-based game that failed to work (Runescape). This particular game is a Java application that fails on an attempt to perform a HTTP GET request. The reason remains unclear, but a likely theory is the use of an IPv4-literal in the application itself.
大多数基于网络的游戏运行良好，正如我们早期良好的一般网络体验所预期的那样。然而，我们也找到了一款失败的网络游戏（Runescape）。这个特殊的游戏是一个Java应用程序，在尝试执行HTTP GET请求时失败。原因尚不清楚，但一个可能的理论是在应用程序本身中使用IPv4文本。
The experience with standalone games was far more discouraging. Without exception, all games failed to enable either connections to ongoing games in the Internet or even LAN-based connections to other computers in the same IPv6-only LAN segment. This is somewhat surprising, and the results require further verification. Unfortunately, the games provide no diagnostics about their operation, so it is hard to guess what is going on. It is possible that their networking code employs older APIs that cannot use IPv6 addresses [RFC4038]. The inability to provide any LAN-based connectivity is even more surprising, as this must mean that they are unable to use IPv4 link local connectivity, which should have been available to the devices (IPv4 was not blocked; just that no DHCP answers were provided on IPv4).
单机游戏的体验更令人沮丧。毫无例外，所有游戏都无法连接到Internet上正在进行的游戏，甚至无法连接到同一个仅限IPv6的LAN网段中的其他计算机。这有点令人惊讶，结果需要进一步验证。不幸的是，这些游戏没有提供关于其运行的诊断，因此很难猜测到底发生了什么。他们的网络代码可能使用了不能使用IPv6地址的旧API[RFC4038]。无法提供任何基于LAN的连接更令人惊讶，因为这一定意味着他们无法使用IPv4链路本地连接，这本应可用于设备（IPv4未被阻止；只是IPv4上未提供DHCP应答）。
While none of the standalone games we tested in the summer of 2010 were IPv6-capable, the situation improved during the experiment. For instance, a popular online game, World of Warcraft, now has IPv6
虽然我们在2010年夏天测试的独立游戏中没有一款支持IPv6，但在实验期间情况有所改善。例如，一款流行的在线游戏《魔兽世界》现在有了IPv6
support in its latest version and some of the older games that have been re-released as open source (e.g., Quake) have been patched IPv6- capable by the open source community.
最新版本的支持，以及一些作为开放源代码重新发布的旧游戏（如Quake），已经由开放源代码社区修补了支持IPv6的补丁。
Most of the web-based music services appear to work fine, presumably because they employ TCP and HTTP as a transport. One notable exception is Spotify, which requires communication to specific IPv4 addresses. A proxy configuration similar to the one we used for Skype makes it possible to use Spotify as well.
大多数基于web的音乐服务似乎工作正常，大概是因为它们使用TCP和HTTP作为传输。一个值得注意的例外是Spotify，它需要与特定的IPv4地址通信。类似于我们在Skype中使用的代理配置，也可以使用Spotify。
There are also problems with different appliances such as webcams. Many of them do not support IPv6; hence, they will not work in an IPv6-only network. Also, not all firewalls support IPv6. Or even if they do, they may still experience issues with some aspects of IPv6 such as fragments.
网络摄像头等不同设备也存在问题。其中许多不支持IPv6；因此，它们不会在仅IPv6的网络中工作。此外，并非所有防火墙都支持IPv6。或者，即使他们这样做了，他们可能仍然会遇到IPv6的某些方面的问题，例如片段。
Some of these issues are easily solved when the appliance works as a server, such as what most webcams and our sensor gateway devices do. We placed the appliance in the IPv4 part of the network (in this case, in private address space), added its name to the local DNS, and simply allowed devices from the IPv6-only network reach it through NAT64.
当设备作为服务器工作时，其中一些问题很容易解决，例如大多数网络摄像头和传感器网关设备所做的工作。我们将设备放置在网络的IPv4部分（在本例中，是在专用地址空间中），将其名称添加到本地DNS，并简单地允许来自仅IPv6网络的设备通过NAT64访问它。
One thing that becomes simplified in an IPv6-only network is source address selection [RFC3484]. As there is no IPv4 connectivity, the host only needs to consider its IPv6 source address. For global communications, there is typically just one possible source address.
在纯IPv6网络中简化的一件事是源地址选择[RFC3484]。由于没有IPv4连接，主机只需要考虑它的IPv6源地址。对于全球通信，通常只有一个可能的源地址。
Some networks that advertise IPv6 addresses in their DNS records in reality have some problems. For instance, a popular short URL forwarding service has advertised a deprecated IPv4-compatible IPv6 address [RFC4291] in its AAAA record, making it impossible for this site to be reached unless either IPv4 or NAT64 translation to an IPv4 destination is used.
实际上，一些在DNS记录中公布IPv6地址的网络存在一些问题。例如，一个流行的短URL转发服务在其AAAA记录中公布了一个不推荐使用的IPv4兼容IPv6地址[RFC4291]，这使得除非使用IPv4或NAT64转换到IPv4目标，否则无法访问此站点。
After correcting some initial bugs and stability issues, the NAT64 operation itself has been relatively problem-free. There have been no unexplained DNS problems or lost sessions. With the exception of the specific applications mentioned above and IPv4 literals, the user
在纠正了一些初始错误和稳定性问题之后，NAT64操作本身就相对没有问题。没有出现无法解释的DNS问题或会话丢失。除上述特定应用程序和IPv4文本外，用户
experience has been in line with using IPv4 Internet through a NAT44 device. These failures with the specific applications are clearly very different from the IPv4 experience, however.
通过NAT44设备使用IPv4互联网的经验是一致的。但是，特定应用程序的这些故障显然与IPv4的体验非常不同。
The rest of this section discusses our measurements on specific issues. These tests and measurements were performed during the year 2011 and present a snapshot of the situation on that time. More up-to-date measurement information can be found from various online tools such as [HE-IPv6].
本节的其余部分将讨论我们对特定问题的度量。这些测试和测量是在2011年进行的，呈现了当时情况的快照。可以从各种在线工具（如[HE-IPv6]）中找到更多最新的测量信息。
While browsing in general works, IPv4 literals embedded in the HTML code may break some parts of the web pages when using IPv6-only access. This happens because the DNS64 cannot synthesize AAAA records for the literals since the addresses are not queried from the DNS. Luckily, the IPv4 literals seem to be fairly rarely encountered, at least so that they would be noticed, with regular web surfing. The authors have run into this issue only few times during the entire experiment. Only two of those cases had a practical impact (in YouTube, some of the third-party applications for downloading content did not work and one hotel's web page had a literal link to its reservation system).
在一般情况下浏览时，HTML代码中嵌入的IPv4文本在使用仅限IPv6访问时可能会破坏网页的某些部分。这是因为DNS64无法合成文本的AAAA记录，因为没有从DNS查询地址。幸运的是，IPv4文本似乎很少遇到，至少在经常上网时会被注意到。在整个实验过程中，作者只遇到过几次这个问题。其中只有两个案例产生了实际影响（在YouTube上，一些用于下载内容的第三方应用程序不起作用，一家酒店的网页上有一个与预订系统的文字链接）。
We have attempted to measure the likelihood of running into an IPv4 literal in the web. To do this, we took the top 1,000 and 10,000 web sites from the Alexa popular web site list. With 1,000 top sites, 0.2% needed an IPv4 literal to render all components in their top page (e.g., images, videos, JavaScript, and Cascading Style Sheet (CSS) files). With 10,000 top sites, this number increases to 2%.
我们试图测量在web上遇到IPv4文本的可能性。为此，我们从Alexa热门网站列表中选出了前1000和10000个网站。对于1000个顶级站点，0.2%的站点需要IPv4文本来呈现其顶级页面中的所有组件（例如，图像、视频、JavaScript和层叠样式表（CSS）文件）。拥有10000个顶级网站，这一数字增加到2%。
However, it is not clear what conclusions can be made about this. It is often the case that there are unresolvable or inaccessible components on a web page anyway for various reasons, and to understand the true impact we would have to know how "important" a given page component was. Also, we did not measure the number of links with IPv4 literals on these pages, nor did we attempt to search the site in any thorough manner for these literals.
然而，目前尚不清楚对此可以得出什么结论。通常情况下，由于各种原因，网页上存在无法解决或无法访问的组件，为了了解真正的影响，我们必须知道给定页面组件的“重要性”。此外，我们没有测量这些页面上具有IPv4文本的链接的数量，也没有尝试以任何彻底的方式搜索站点以查找这些文本。
As noted, personal anecdotal evidence says that IPv4 literals are not a big problem. But clearly, cleaning the most important parts of the web from IPv4 literals would be useful. With tools such as the popular web site list, some user pressure, and co-operation from the content providers the most urgent part of the problem could hopefully be solved as a one-time effort. While IPv4 literals still exist in the web, using a suitable HTTP proxy (e.g., [ADD-LITERALS]) can help to cope with them.
如前所述，个人轶事证据表明IPv4文本不是一个大问题。但显然，从IPv4文本中清除web最重要的部分将是有用的。有了流行网站列表、一些用户压力和内容提供商的合作等工具，问题中最紧迫的部分有望一次性解决。虽然IPv4文本仍然存在于web中，但使用合适的HTTP代理（例如[ADD-literals]）可以帮助解决这些问题。
We also compared how well the web works behind a NAT64 compared to IPv4-only and native IPv6 access. For this purpose, we used wget to go through the same top web site lists as described in Section 6.1, again downloading everything needed to render their front page. The tests were repeated and average failure rate was calculated over all of the runs. Separate tests were conducted with an IPv4-only network, an IPv6-only network, and an IPv6-only network with NAT64.
我们还比较了NAT64与仅IPv4和本机IPv6访问相比，web在NAT64之后的工作情况。为此，我们使用wget浏览了第6.1节中描述的同一个顶级网站列表，再次下载了呈现其首页所需的所有内容。重复试验，并计算所有运行期间的平均故障率。分别对仅IPv4网络、仅IPv6网络和仅IPv6网络（NAT64）进行了测试。
When accessed with the IPv4-only network, our tests show that 1.9% of the sites experienced some sort of error or failure. The failure could be that the whole site was not accessible, or just that a single image (e.g., an advertisement banner) was not loaded properly. It should also be noted that access through wget is somewhat different from a regular browser: some web sites refuse to serve content to wget, browsers typically have DNS heuristics to fill in "www." in front of a domain name where needed, and so on. In addition to missing advertisement banners, temporary routing glitches and other mistakes, these differences also help to explain the reason for the high baseline error rate in this test. It should also be noted that variations in wget configuration options produced highly different results, but we believe that the options we settled on bear closest resemblance to real-world browsing.
当使用仅IPv4网络访问时，我们的测试显示1.9%的站点出现了某种错误或故障。失败可能是整个站点无法访问，或者只是单个图像（例如广告横幅）未正确加载。还应该注意的是，通过wget进行访问与普通浏览器有所不同：一些网站拒绝向wget提供内容，浏览器通常使用DNS试探法在需要的域名前填写“www”，等等。除了缺少广告横幅、临时路由故障和其他错误外，这些差异也有助于解释本测试中基线错误率高的原因。还应该注意的是，wget配置选项的变化产生了非常不同的结果，但我们相信我们确定的选项与现实世界的浏览最为相似。
When we tried to access the same sites with native IPv6 (without NAT64), 96% of the sites failed to load correctly. This was as expected, given that most of the Internet content is not available on IPv6. The few exceptions included, for instance, sites managed by Google.
当我们尝试使用本机IPv6（无NAT64）访问相同的站点时，96%的站点无法正确加载。这是意料之中的，因为大部分互联网内容在IPv6上都不可用。例如，少数例外包括谷歌管理的网站。
When the sites were accessed from the IPv6-only network via a NAT64 device, the failure rate increased to 2.1%. Most of these failures appear to be due to IPv4 address literals, and the increased failure rate matches that of IPv4 literal occurrence in the same set of top web sites. With the top 10,000 sites, the failure rate with NAT64 increases similarly to our test on IPv4 address literals.
当通过NAT64设备从纯IPv6网络访问这些站点时，故障率增加到2.1%。这些故障中的大多数似乎是由于IPv4地址文本造成的，并且增加的故障率与同一组顶级网站中IPv4文本出现的故障率相匹配。对于排名前10000的站点，NAT64的故障率与我们对IPv4地址文本的测试类似。
One important set of measurements remains for future work. It would be useful to understand the effect of DNS64 and NAT64 on response time and end-to-end communication delays. Some users have anecdotal reports of slow web browsing response times, but we have been unable to determine if this was due to the IPv6-only network mechanisms or for some other reason. Measurements on pure DNS response times and packet round-trip delays does not show a significant difference from a NAT44 environment. It would be particularly interesting to measure
还有一组重要的测量结果有待于今后的工作。了解DNS64和NAT64对响应时间和端到端通信延迟的影响将非常有用。一些用户有关于web浏览响应时间缓慢的轶事报道，但我们无法确定这是由于仅限IPv6的网络机制还是其他原因。对纯DNS响应时间和数据包往返延迟的测量结果与NAT44环境没有显著差异。这将是特别有趣的测量
delays in the context of dual-stack versus NAT64-based IPv6-only networking. When using dual-stack, broken IPv6 connectivity can be repaired by falling back to IPv4 use. With NAT64, this is not always possible as discussed in Section 3.2.
与基于NAT64的纯IPv6网络相比，双堆栈环境下的延迟。使用双栈时，可以通过恢复IPv4使用来修复损坏的IPv6连接。对于NAT64，这并非如第3.2节所述始终可行。
Also, more programs, especially VoIP and Peer-to-Peer (P2P) applications should be tested with NAT64. In addition, tunneling and mobility protocols should be tested and especially Virtual Private Network (VPN) protocols and applications would deserve more thorough investigation.
此外，更多的程序，特别是VoIP和对等（P2P）应用程序应该使用NAT64进行测试。此外，应测试隧道和移动协议，特别是虚拟专用网（VPN）协议和应用程序，应进行更彻底的调查。
The main conclusion is that it is possible to employ IPv6-only networking. For large classes of applications, there are no downsides or the downsides are negligible. We have been unable to spot any practical difference in the web browsing experience, for instance. Additionally, IPv6 usage -- be it in dual-stack or IPv6- only form -- comes with inherent advantages, such as enabling direct end-to-end connectivity. In our case, we employed this by enabling direct connectivity to devices in a home network from anywhere in the (IPv6) Internet. There are, however, a number of issues as well, such as lack of IPv6 support in some applications or bugs in untested parts of the code.
主要结论是，仅采用IPv6网络是可能的。对于大类应用程序，没有缺点，或者缺点可以忽略不计。例如，我们无法发现网络浏览体验的任何实际差异。此外，IPv6的使用——无论是双栈形式还是纯IPv6形式——都具有固有的优势，例如支持直接的端到端连接。在我们的案例中，我们采用了这一点，实现了从（IPv6）互联网的任何位置直接连接到家庭网络中的设备。但是，也存在一些问题，例如某些应用程序中缺少IPv6支持，或者代码中未经测试的部分存在bug。
Our experience with IPv6-only networking confirms that dual stack should still be our recommended model for general purpose networking at this point in time. However, IPv6-only networking can be employed by early adopters or highly controlled networks. One example of such a controlled network is a mobile network with operator-driven selection of handsets. For instance, on some handsets that we tested, we were unable to see any functional difference between IPv4 and IPv6.
我们在纯IPv6网络方面的经验证实，目前双栈仍然应该是我们推荐的通用网络模型。但是，早期采用者或高度控制的网络可以使用仅限IPv6的网络。这种受控网络的一个例子是具有运营商驱动的手机选择的移动网络。例如，在我们测试的一些手机上，我们无法看到IPv4和IPv6之间的任何功能差异。
Our recommendations apply at the present time. With effort and time, deployment barriers can be removed and IPv6-only networking becomes applicable in all networking situations.
我们的建议目前适用。通过努力和时间，可以消除部署障碍，并且只使用IPv6的网络可以应用于所有网络情况。
Some of the improvements are already in process in the form of new products and additional IPv6 support. For instance, we expect that the handset market will have a much higher number of IPv6-capable devices in the near future. However, some of the changes do not come without the community spending additional effort. We have identified a number of actions that should be taken to improve the state of IPv6-only networking. These include the following:
一些改进已经在进行中，包括新产品和额外的IPv6支持。例如，我们预计手机市场在不久的将来将有更多支持IPv6的设备。然而，如果社区不付出额外的努力，一些变化是不会发生的。我们已经确定了一些应该采取的行动，以改善仅IPv6网络的状态。这些措施包括：
DNS Discovery
DNS发现
The state of DNS discovery continues to be one of the main barriers for easy adoption of IPv6-only networking. Since DNS discovery is not a problem in dual-stack networking, there has been too little effort in testing and deploying the necessary components. For instance, it would be useful if RA-based DNS discovery came as a standard feature and not as an option in Linux distributions. Our hope is that recent standardization of the RA-based DNS discovery at the IETF will help this happen. Other operating systems face similar issues. The authors believe that at this time, prudent operational practices call for maximizing the number of offered automatic configuration mechanisms on the network side. It might be useful for an IETF document to provide guidance on operating DNS in IPv6-only networks.
DNS发现的状态仍然是易于采用纯IPv6网络的主要障碍之一。由于DNS发现在双栈网络中不是问题，因此在测试和部署必要组件方面的工作太少。例如，如果基于RA的DNS发现作为标准功能而不是Linux发行版中的选项出现，那么它将非常有用。我们希望IETF最近基于RA的DNS发现标准化将有助于实现这一点。其他操作系统也面临类似的问题。作者认为，此时，谨慎的操作实践要求最大限度地增加网络端提供的自动配置机制的数量。IETF文档可能有助于提供在仅IPv6网络中操作DNS的指导。
Network Managers
网络管理员
Other key software components are the various network management and attachment tools in operating systems. These tools generally have the required functionality, but do not always appear to have been tested very extensively on IPv6, or let alone IPv6-only networks. Further work is required here.
其他关键软件组件是操作系统中的各种网络管理和连接工具。这些工具通常具有所需的功能，但并不总是在IPv6上进行过广泛的测试，更不用说仅在IPv6网络上测试了。这里需要进一步的工作。
Firewalls
防火墙
More work is needed to ensure that IPv6 is supported in equal manner in various firewall products.
需要做更多的工作来确保在各种防火墙产品中以平等的方式支持IPv6。
Application Support
应用程序支持
By far, the most important action, at least for our group of users, would be to bring some key applications (e.g., instant messaging and VoIP applications and games) to a state where they can be easily run on IPv6-only networks and behind a NAT64. To facilitate this, application programmers should use IP-version-agnostic APIs so that applications automatically use IPv4 or IPv6 depending on what is available. In some cases, it may also be necessary to add support for new types of ALGs.
到目前为止，最重要的行动（至少对我们的用户群体而言）将是将一些关键应用程序（例如，即时消息和VoIP应用程序和游戏）带到一个可以在仅IPv6网络上和NAT64后面轻松运行的状态。为了促进这一点，应用程序程序员应该使用IP版本无关的API，以便应用程序根据可用的内容自动使用IPv4或IPv6。在某些情况下，可能还需要添加对新型ALG的支持。
IPv4 Literals
IPv4文本
The web should be cleaned of IPv4 literals. Also, IPv4 literals should be avoided in application protocol signaling messages.
应清除web上的IPv4文本。此外，应用程序协议信令消息中应避免使用IPv4文本。
Measurements and Analysis
测量和分析
It is also important to continue with testing, measurement, and analysis of which Internet technologies work in IPv6-only networks, to what extent, at what speed, and where the remaining problems are.
同样重要的是，继续测试、测量和分析哪些互联网技术在仅限IPv6的网络中工作，在多大程度上、以多快的速度工作，以及剩余的问题在哪里。
Guidelines
指导方针
It is also useful to provide guidance for network administrators and users on how to turn on IPv6-only networking.
为网络管理员和用户提供有关如何启用仅IPv6网络的指导也很有用。
As can be seen from the above list, there are only minor things that can be done through standardization. Most of the effort is practical and centers around improving various implementations.
从上面的列表中可以看出，只有一些小事情可以通过标准化来完成。大部分工作都是实用的，主要围绕着改进各种实现。
By itself, the use of IPv6 instead of IPv4 does not make a big security difference. The main security requirement is that, naturally, network security devices need to be able to deal with IPv6 in these networks. This is already required in all dual-stack networks. As noted, it is important, e.g., to ensure firewall capabilities. Security considerations for NAT64 and DNS64 are discussed in [RFC6146] and [RFC6147].
就其本身而言，使用IPv6而不是IPv4并不会带来很大的安全差异。主要的安全要求是，网络安全设备自然需要能够在这些网络中处理IPv6。这在所有双栈网络中都是必需的。如前所述，重要的是确保防火墙功能。[RFC6146]和[RFC6147]中讨论了NAT64和DNS64的安全注意事项。
In our experience, many of the critical security functions in a network end up being on the dual-stack part of the network anyway. For instance, our mail servers obviously still have to be able to communicate with both the IPv4 and IPv6 Internet, and as a result, they and the associated spam and filtering components are not in the IPv6-only part of the network.
根据我们的经验，网络中的许多关键安全功能最终都位于网络的双堆栈部分。例如，我们的邮件服务器显然仍然必须能够与IPv4和IPv6 Internet通信，因此，它们以及相关的垃圾邮件和过滤组件不在网络中仅IPv6的部分。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[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月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966]Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[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月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6384]van Beijnum，I.“用于IPv6到IPv4转换的FTP应用层网关（ALG）”，RFC 6384，2011年10月。
[ADD-LITERALS] Wing, D., "Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators", Work in Progress, March 2010.
[ADD-LITERALS]Wing，D.“使用IPv6/IPv4转换器处理HTTP URI中的IP地址文字”，正在进行的工作，2010年3月。
[HE-IPv6] Hurricane Electric, "Global IPv6 Deployment Progress Report", February 2012, <http://bgp.he.net/ipv6-progress-report.cgi>.
[HE-IPv6]飓风电气，“全球IPv6部署进度报告”，2012年2月<http://bgp.he.net/ipv6-progress-report.cgi>.
The authors would like to thank the many people who have engaged in discussions around this topic, and particularly the people who were involved in building some of the new tools used in our network, our users who were interested in going where only few had dared to venture before, or people who helped us in this effort. In particular, we would like to thank Martti Kuparinen, Tero Kauppinen, Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and Cameron Byrne. Also, Marcelo Braun, Iljitsch van Beijnum, Miika Komu, and Jouni Korhonen have provided useful discussion and comments on the document.
作者要感谢参与讨论这个话题的许多人，特别是那些参与构建我们网络中使用的一些新工具的人，那些对去以前很少有人敢去的地方感兴趣的用户，或者在这方面帮助我们的人。特别是，我们要感谢马尔蒂·库帕里宁、泰罗·考皮宁、海基·马科宁、扬·梅伦、弗雷德里克·加内伊、克里斯蒂安·戈塔雷、蒂姆·里塔·阿霍、佩特里·约凯拉、米科·萨雷拉、奥利·阿尔科、拉塞·阿尔科和卡梅隆·伯恩。此外，Marcelo Braun、Iljitsch van Beijnum、Miika Komu和Jouni Korhonen对该文件进行了有益的讨论和评论。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Ari Keranen Ericsson Jorvas 02420 Finland
Ari Keranen Ericsson Jorvas 02420芬兰
EMail: ari.keranen@ericsson.com
EMail: ari.keranen@ericsson.com