Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6036 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
October 2010
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6036 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
October 2010
Emerging Service Provider Scenarios for IPv6 Deployment
IPv6部署的新兴服务提供商场景
Abstract
摘要
This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations.
本文档描述了Internet服务提供商在部署IPv6服务方面出现的做法和计划。它们基于到目前为止的实践经验，以及当前的计划和要求，在2010年初对一些ISP进行的调查中报告了这些计划和要求。本文件确定了一些技术差距，但未提出建议。
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/rfc6036.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6036.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Survey of ISP's Experience, Plans, and Requirements .............4
2.1. Methodology ................................................4
2.2. General Questions about IP Service .........................4
2.3. Requirements for IPv6 Service ..............................5
2.4. Status and Plans for IPv6 Service ..........................5
2.5. IPv6 Technologies ..........................................5
2.6. Effect of Size .............................................6
3. Lessons from Experience and Planning ............................7
4. Gap Analysis ....................................................8
4.1. Product Issues .............................................8
4.2. Protocol Issues ............................................9
4.3. Documentation and General Issues ..........................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. Informative References .........................................12
Appendix A. Summary of Replies ....................................14
Appendix B. Questionnaire .........................................19
1. Introduction ....................................................2
2. Survey of ISP's Experience, Plans, and Requirements .............4
2.1. Methodology ................................................4
2.2. General Questions about IP Service .........................4
2.3. Requirements for IPv6 Service ..............................5
2.4. Status and Plans for IPv6 Service ..........................5
2.5. IPv6 Technologies ..........................................5
2.6. Effect of Size .............................................6
3. Lessons from Experience and Planning ............................7
4. Gap Analysis ....................................................8
4.1. Product Issues .............................................8
4.2. Protocol Issues ............................................9
4.3. Documentation and General Issues ..........................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. Informative References .........................................12
Appendix A. Summary of Replies ....................................14
Appendix B. Questionnaire .........................................19
As is well known, the approaching exhaustion of IPv4 address space will bring about a situation in which Internet Service Providers (ISPs) are faced with a choice between one or more of three major alternatives:
众所周知，IPv4地址空间即将耗尽，这将导致互联网服务提供商（ISP）面临三种主要选择中的一种或多种选择：
1. Squeeze the use of IPv4 addresses even harder than today, using smaller and smaller address blocks per enterprise customer, and possibly trading address blocks with other ISPs.
1. 压缩IPv4地址的使用比现在更加困难，每个企业客户使用越来越小的地址块，并可能与其他ISP交换地址块。
2. Install multiple layers of Network Address Translation (NAT) [CGN] or share IPv4 addresses by other methods such as address-plus-port mapping [APLUSP], [PRANGE].
2. 安装多层网络地址转换（NAT）[CGN]或通过地址加端口映射[APLUSP]、[PRANGE]等其他方法共享IPv4地址。
3. Deploy IPv6 and operate IPv4-IPv6 coexistence and interworking mechanisms.
3. 部署IPv6并运行IPv4-IPv6共存和互通机制。
This document focuses on alternative (3), while recognizing that many ISPs may be obliged by circumstances to prolong the life of IPv4 by using (1) or (2) while preparing for (3).
本文件重点介绍备选方案（3），同时认识到许多ISP可能因情况而有义务在准备（3）时使用（1）或（2）延长IPv4的使用寿命。
This document describes IPv6 deployment scenarios already adopted or currently planned by a set of ISPs who responded to a technical questionnaire. Thus, it is a factual record of the responses from those ISPs. It makes no recommendations; the best choice of scenarios will depend on the circumstances of individual ISPs.
本文档描述了一组ISP已经采用或目前正在计划的IPv6部署场景，这些ISP对一份技术问卷进行了回复。因此，这是这些ISP的回复的真实记录。它没有提出建议；最佳方案的选择将取决于各个ISP的情况。
We consider various aspects of IPv6 deployment: addressing, routing, DNS, management, and IPv4-IPv6 coexistence and interworking. We do not consider application services in detail, but we do cover general aspects.
我们考虑IPv6部署的各个方面：寻址、路由、DNS、管理和IPv4-IPv6共存和互通。我们不详细考虑应用服务，但我们涵盖了一般方面。
The reader is assumed to be familiar with IPv6. The IETF's view of core IPv6 requirements is to be found in [RFC4294] (currently being updated as [NODEREQ]). However, this does not give a complete view of mechanisms an ISP may need to deploy, since it considers the requirements for an individual node, not for a network or service infrastructure as a whole.
假定读者熟悉IPv6。IETF对IPv6核心需求的看法见[RFC4294]（目前更新为[NODEREQ]）。然而，这并没有给出ISP可能需要部署的机制的完整视图，因为它考虑的是单个节点的需求，而不是整个网络或服务基础设施的需求。
[RFC4029] discusses scenarios for introducing IPv6 into ISP networks, as the problem was viewed some years ago. Its end goal is simply a dual-stack ISP backbone. Today's view is that this is insufficient, as it does not allow for interworking between IPv6-only and legacy (IPv4-only) hosts. Indeed, the end goal today might be an IPv6-only ISP backbone, with some form of legacy IPv4 support.
[RFC4029]讨论了在ISP网络中引入IPv6的场景，正如几年前所看到的那样。它的最终目标只是一个双栈ISP主干网。今天的观点是，这是不够的，因为它不允许仅IPv6主机和旧式（仅IPv4）主机之间的互通。事实上，今天的最终目标可能是只支持IPv6的ISP主干网，并提供某种形式的传统IPv4支持。
[RFC4779] discusses deployment in broadband access networks such as Cable Television (CATV), Asymmetric Digital Subscriber Line (ADSL), and wireless. [RFC5181], [RFC5121], and [RFC5692] deal specifically with IEEE 802.16 access networks. MPLS-based ISPs may use the IPv6 Provider Edge Router (6PE) [RFC4798] mechanism.
[RFC4779]讨论了宽带接入网络的部署，如有线电视（CATV）、非对称数字用户线（ADSL）和无线网络。[RFC5181]、[RFC5121]和[RFC5692]专门处理IEEE 802.16接入网络。基于MPLS的ISP可以使用IPv6提供商边缘路由器（6PE）[RFC4798]机制。
[RFC4942] covers IPv6 security issues, especially those that are specific to transition and IPv4-IPv6 coexistence scenarios. [RFC4864] discusses "Local Network Protection", i.e., how the internal structure of an IPv6 site network can be protected. This affects how well an ISP's customers are protected after they deploy IPv6.
[RFC4942]涵盖IPv6安全问题，特别是特定于过渡和IPv4-IPv6共存场景的问题。[RFC4864]讨论了“本地网络保护”，即如何保护IPv6站点网络的内部结构。这会影响ISP的客户在部署IPv6后受到保护的程度。
Although the basic IPv6 standards have long been stable, it should be noted that considerable work continues in the IETF, particularly to resolve the issue of highly scalable multihoming support for IPv6 sites, and to resolve the problem of IP layer interworking between IPv6-only and IPv4-only hosts. IPv6/IPv4 interworking at the application layers is handled within the original dual-stack model of IPv6 deployment: either one end of an application session will have dual-stack connectivity, or a dual-stack intermediary such as an HTTP proxy or SMTP server will interface to both IPv4-only and IPv6-only hosts or applications.
尽管基本IPv6标准长期以来一直稳定，但应注意的是，IETF仍在进行大量工作，特别是解决IPv6站点的高度可扩展多宿支持问题，以及解决仅IPv6和仅IPv4主机之间的IP层互通问题。应用层的IPv6/IPv4互通在IPv6部署的原始双堆栈模型中处理：应用程序会话的一端将具有双堆栈连接，或者双堆栈中介（如HTTP代理或SMTP服务器）将与仅IPv4和仅IPv6的主机或应用程序连接。
[RFC5211] describes an independent view of a possible sequence of events for IPv6 adoption in the Internet as a whole, with direct implications for ISPs. Its main point, perhaps, is that by the year 2012, it will be appropriate to regard IPv4 networks as the legacy solution.
[RFC5211]描述了整个互联网采用IPv6的可能事件序列的独立视图，对ISP有直接影响。其要点可能是，到2012年，将IPv4网络视为遗留解决方案将是合适的。
To obtain a view of the IPv6 experience, plans, and requirements of ISPs, a questionnaire was issued by the authors in December 2009 and announced widely to the operational community. We promised to keep the replies strictly confidential and to publish only combined results, without identifying information about individual ISPs in any published results. The raw technical questions are shown in Appendix B, and a detailed summary of the replies is in Appendix A. Note that although the questionnaire was widely announced, those who chose to reply were self-selected and we can make no claim of statistical significance or freedom from bias in the results. In particular, we assume that ISPs with a pre-existing interest in IPv6 are more likely to have replied than others. The results should therefore be interpreted with some care.
为了了解互联网服务提供商的IPv6经验、计划和要求，作者于2009年12月发布了一份调查问卷，并向运营社区广泛发布。我们承诺对回复严格保密，只公布合并结果，不在任何公布的结果中确定个别ISP的信息。原始技术问题如附录B所示，答复的详细摘要如附录a所示。请注意，尽管广泛公布了调查问卷，但选择答复的人是自选的，我们不能声称结果具有统计意义或没有偏见。特别是，我们假设对IPv6感兴趣的ISP比其他ISP更有可能做出回复。因此，应谨慎解释结果。
Thirty-one ISPs replied before the cutoff date for this analysis. 65% of responses were from European ISPs but large operators in North America and Asian/Pacific regions are included. Commercial ISPs operating nationally predominate, with a vast range of size (from 30 customers up to 40 million). Note that some providers chose not to answer about the exact number of customers. Nevertheless, it can be stated that 6 providers each had millions of customers, the next 10 each had more than 10,000 customers, and the remaining 15 each had fewer than 10,000 customers.
31家ISP在本次分析截止日期前回复。65%的回复来自欧洲ISP，但包括北美和亚太地区的大型运营商。在全国范围内运营的商业ISP占主导地位，规模广泛（从30个客户到4000万）。请注意，一些提供商选择不回答客户的确切数量。尽管如此，可以说，6家供应商各自拥有数百万客户，接下来的10家供应商都拥有10000多个客户，其余15家供应商的客户都不到10000个。
80% of the respondents offer both transit and origin-only service; 29% offer IP multicast service; 80% have multihomed customers.
80%的受访者同时提供过境和始发服务；29%提供IP组播服务；80%拥有多址客户。
A very wide variety of access technologies is used: xDSL, Data Over Cable Service Interface Specification (DOCSIS), leased line (X.25, Time Division Multiplexer / Plesiochronous Digital Hierarchy (TDM/ PDH), Synchronous Digital Hierarchy (SDH)), ATM, frame relay, dialup, microwave, Fiber To The Premises (FTTP), CDMA, Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), Broadband Wireless Access (BWA), WiFi, Ethernet (100M-10G), Ethernet/SDH, MetroEthernet/MPLS. Most ISPs provide Customer Premises Equipment (CPE) to some or all of their customers, but these CPE are often unable to support IPv6.
使用的接入技术非常广泛：xDSL、有线数据业务接口规范（DOCSIS）、专线（X.25、时分复用器/准同步数字体系（TDM/PDH）、同步数字体系（SDH））、ATM、帧中继、拨号、微波、光纤到楼宇（FTTP）、CDMA、，通用移动通信系统（UMTS）、长期演进（LTE）、全球微波接入互操作性（WiMAX）、宽带无线接入（BWA）、WiFi、以太网（100M-10G）、以太网/SDH、MetroEthernet/MPLS。大多数ISP向其部分或全部客户提供客户场所设备（CPE），但这些CPE通常无法支持IPv6。
Estimates of when ISPs will run out of public IPv4 address space for internal use vary widely, between "now" and "never". Public IPv4 address space for customers is mainly expected to run out between
ISP何时会耗尽内部使用的公共IPv4地址空间的估计差异很大，从“现在”到“永远”。客户的公共IPv4地址空间预计将在
2010 and 2015, but four or five ISPs suggested it will never happen, or at least not in the foreseeable future. About 19% of ISPs offer RFC 1918 space to customers, and about 39% use such addresses internally.
2010年和2015年，但四五家互联网服务提供商表示，这种情况永远不会发生，或者至少在可预见的未来不会发生。约19%的ISP向客户提供RFC1918空间，约39%的ISP在内部使用此类地址。
61% of ISPs report that some big customers are requesting IPv6. Predictions for when 10% of customers will require IPv6 range from 2010 to 2017, and for 50% from 2011 to 2020. These ISPs require IPv6 to be a standard service by 2010 to 2015; the most common target date is 2011.
61%的ISP报告说一些大客户正在请求IPv6。对10%的客户何时需要IPv6的预测范围为2010年至2017年，对50%的客户何时需要IPv6的预测范围为2011年至2020年。这些ISP要求IPv6在2010年至2015年成为标准服务；最常见的目标日期是2011年。
42% of ISPs already offer IPv6 as a regular service, although, in general, it is used by fewer than 1% of customers. Another 48% of ISPs have IPv6 deployment in progress or planned. These all plan at least beta-test service in 2010. Planned dates for regular service are between 2010 and 2013 (except for one ISP who replied that it depends on the marketing department). When asked when IPv6 will reach 50% of total traffic, the most common answer is 2015.
42%的ISP已经将IPv6作为常规服务提供，但一般来说，只有不到1%的客户使用它。另有48%的ISP正在或计划部署IPv6。这些都计划在2010年至少提供beta测试服务。定期服务的计划日期为2010年至2013年（一家ISP回答说这取决于营销部门除外）。当被问及IPv6何时将达到总流量的50%时，最常见的答案是2015年。
Turning to technology choices, the overwhelming choice of approach (94%) is a dual-stack routing backbone, and the reason given is simplicity and cost. 39% run, or plan to run, a 6to4 relay as well, and 16% run or plan a Teredo server. However, 77% of ISPs don't have or plan to have any devices dedicated to IPv6. A different 77% don't see IPv6 as an opportunity to restructure their network topology.
谈到技术选择，压倒性的方法选择（94%）是双栈路由主干，给出的理由是简单性和成本。39%运行或计划运行6to4中继，16%运行或计划运行Teredo服务器。然而，77%的ISP没有或计划有任何专用于IPv6的设备。另外77%的人不认为IPv6是重组网络拓扑的机会。
When asked which types of equipment are unable to support IPv6, the most common answer was CPE (10 mentions). Also mentioned: handsets; Digital Subscriber Line Access Multiplexers (DSLAMs); routers (including several specific models); traffic management boxes; load balancers; VPN boxes; some SIP platforms; management interfaces & systems; firewalls; billing systems. When asked if such devices can be field-upgraded, the answers were gloomy: 5 yes, 4 partially, 10 no, and numerous "don't know" or "hopefully".
当被问及哪些类型的设备无法支持IPv6时，最常见的答案是CPE（提及10次）。还提到：手机；数字用户线路接入多路复用器（DSLAM）；路由器（包括若干特定型号）；交通管理箱；负载均衡器；VPN箱；一些SIP平台；管理接口和系统；防火墙；计费系统。当被问及这些设备是否可以现场升级时，答案是悲观的：5个是，4个部分，10个不是，还有很多“不知道”或“希望”。
84% support or plan DNS Authentication, Authorization, Accounting, and Auditing (AAAA) queries over IPv6, and all but one of these include reverse DNS lookup for IPv6.
84%的用户支持或计划IPv6上的DNS身份验证、授权、记帐和审核（AAAA）查询，除一个查询外，所有查询都包括IPv6的反向DNS查找。
The ISPs surveyed have prefixes ranging from /19 to /48, and have a
variety of policies for customer prefixes. Fifteen ISPs offer more
than one of /48, /52, /56, /60, or /64. Two offer /56 only, eight
The ISPs surveyed have prefixes ranging from /19 to /48, and have a
variety of policies for customer prefixes. Fifteen ISPs offer more
than one of /48, /52, /56, /60, or /64. Two offer /56 only, eight
offer /48 only. Two wired operators offer /64 only. Mobile operators offer /64 in accordance with 3GPP, but at least one would like to be allowed to offer /128 or /126. Also, as many as 30% of the operators already have IPv6 customers preferring a PI (provider independent) prefix. The methods chosen for prefix delegation to CPEs are manual, DHCPv6[-PD], Stateless Address Autoconfiguration (SLAAC), RADIUS, and Point-to-Point Protocol over Ethernet (PPPoE). However, in fact, the latter two cannot assign a prefix on their own.
仅提供/48。两个有线运营商仅提供/64。移动运营商根据3GPP提供/64，但至少有一家希望被允许提供/128或/126。此外，多达30%的运营商已经有IPv6客户喜欢PI（独立于提供商）前缀。为CPE的前缀委派选择的方法有手动、DHCPv6[-PD]、无状态地址自动配置（SLAAC）、RADIUS和以太网点对点协议（PPPoE）。然而，事实上，后两者不能自行分配前缀。
About 50% of ISPs already operate or plan dual-stack SMTP, Post Office Protocol 3 (POP3), IMAP, and HTTP services. In terms of internal services, it seems that firewalls, intrusion detection, address management, monitoring, and network management tools are also around the 50% mark. However, accounting and billing software is only ready at 23% of ISPs.
大约50%的ISP已经运营或计划使用双栈SMTP、邮局协议3（POP3）、IMAP和HTTP服务。就内部服务而言，防火墙、入侵检测、地址管理、监控和网络管理工具似乎也在50%左右。然而，只有23%的ISP提供了会计和计费软件。
Considering IPv4-IPv6 interworking, 58% of ISPs don't expect to have IPv6-only customers (but mobile operators are certain they will have millions). Five ISPs report customers who explicitly refused to consider IPv6. When asked how long customers will run IPv4-only applications, the most frequent answer is "more than ten years". Only three ISPs state that IPv6-IPv4 interworking at the IP layer is not needed. On the other hand, only three (a different three!) run or plan to run NAT-PT (Protocol Translation). At least 30% plan to run some kind of translator (presumably NAT64/DNS64), but only two felt that a multicast translator was essential. Among those who do not plan a translator, when asked how they plan to connect IPv6-only customers to IPv4-only services, seven rely on dual stack and four have no plan (one said, paraphrasing, "it's their problem").
考虑到IPv4-IPv6的互通性，58%的ISP不希望拥有仅限IPv6的客户（但移动运营商确信他们将拥有数百万）。五个ISP报告客户明确拒绝考虑IPv6。当被问及客户将只运行IPv4应用程序多长时间时，最常见的回答是“超过十年”。只有三家ISP表示不需要在IP层进行IPv6-IPv4互通。另一方面，只有三个（不同的三个！）运行或计划运行NAT-PT（协议转换）。至少有30%的人计划运行某种转换器（大概是NAT64/DNS64），但只有两个人认为多播转换器是必不可少的。在那些没有计划翻译的人中，当被问及他们计划如何将只支持IPv6的客户连接到只支持IPv4的服务时，7人依赖双栈，4人没有计划（一人说，这是他们的问题）。
Asked about plans for Mobile IPv6 (or Nemo mobile networks), 19% said yes, and 71% said no, with the others uncertain. A detailed analysis shows that of the six ISPs who responded positively, three are large mobile operators (and a fourth mobile operator said no). The other three who responded positively were broadband ISPs ranging from small to very large.
当被问及移动IPv6（或Nemo移动网络）的计划时，19%的人表示同意，71%的人表示不同意，其他人则不确定。一项详细的分析显示，在六家做出积极回应的ISP中，有三家是大型移动运营商（第四家移动运营商拒绝）。其他三个积极响应的是宽带ISP，从小型到大型不等。
We examined the data to see whether any other differences would emerge between the very large (millions of customers), medium (at least 10,000), and small (fewer than 10,000) operators. However, the range of answers seems to be broadly similar in all cases. The major exception is that among the six very large operators, one plans to use 6PE and dual-stack lite (DS-lite), and another to use IPv6 on VPN to Provider Edge Router (6VPE), instead of a simple dual stack. The other large operators and all the medium and small operators prefer a simple dual stack.
我们检查了数据，以确定超大（数百万客户）、中型（至少10000家）和小型（少于10000家）运营商之间是否会出现任何其他差异。然而，在所有情况下，答案的范围似乎大致相同。主要的例外是，在六家大型运营商中，一家计划使用6PE和双栈lite（DS lite），另一家计划在VPN到提供商边缘路由器（6VPE）上使用IPv6，而不是简单的双栈。其他大型运营商和所有中小型运营商都喜欢简单的双堆栈。
This section is assembled and paraphrased from general comments made in the various questionnaire responses. Any inconsistencies or contradictions are present in the original data. Comments related to missing features and products have been included in Section 4.
本节是根据各种问卷答复中的一般性意见汇编和解释的。原始数据中存在任何不一致或矛盾。与缺失功能和产品相关的评论已包含在第4节中。
As noted in the summary above, the ISPs that responded overwhelmingly prefer a native dual-stack deployment. Numerous comments mentioned the simplicity of this model and the complexity and sub-optimal routing of tunnel-based solutions. Topology redesign is not generally considered desirable, because congruent IPv4 and IPv6 topology simplifies maintenance and engineering. Nevertheless, 6to4 is considered convenient for cable modem (DOCSIS) users and IPv6 Rapid Deployment (6RD) is considered an attractive model by some. Various operators, but by no means all, also see a need for Teredo. One very large MPLS-based operator prefers 6PE because it avoids an IPv6 IGP and reduces operational costs. This operator also sees IPv4 scarcity addressed by DS-lite [DSLITE] and Carrier Grade NAT, also acting as a catalyst for IPv6. Another very large operator with an existing NAT44 infrastructure plans to use 6VPE [RFC4659] and believes that NAT64 will be similar to NAT44 in support requirements.
正如上面的总结所指出的，绝大多数响应的ISP更喜欢本机双堆栈部署。许多评论提到了该模型的简单性以及基于隧道的解决方案的复杂性和次优路由。拓扑重新设计通常被认为是不可取的，因为一致的IPv4和IPv6拓扑简化了维护和工程。然而，6to4被认为对电缆调制解调器（DOCSIS）用户很方便，而IPv6快速部署（6RD）被一些人认为是一种很有吸引力的模式。不同的运营商（但并非所有运营商）也认为需要Teredo。一家基于MPLS的大型运营商更喜欢6PE，因为它避免了IPv6 IGP并降低了运营成本。该运营商还发现，DS-lite[DSLITE]和运营商级NAT解决了IPv4的稀缺性问题，同时也是IPv6的催化剂。另一家拥有现有NAT44基础设施的大型运营商计划使用6VPE[RFC4659]，并相信NAT64在支持需求方面与NAT44类似。
Several ISPs observe that IPv6 deployment is technically not hard. The most eloquent statement: "Just do it, bit by bit. It is very much an 'eating the elephant' problem, but at one mouthful at a time, it appears to be surprisingly easy." Other comments paraphrased from the replies are:
一些ISP观察到IPv6部署在技术上并不困难。最雄辩的说法是：“一点一点地去做。这在很大程度上是一个‘吃大象’的问题，但一口一口地吃，这似乎非常容易。”从回答中转述的其他评论如下：
o Despite the known gaps, the tools and toolkits are fairly mature at this point.
o 尽管存在已知的差距，但目前这些工具和工具包已经相当成熟。
o Managerial commitment and a systematic approach to analyzing requirements and readiness are essential.
o 管理承诺和分析需求和准备状态的系统方法至关重要。
o Evangelization remains a must, as it seems that many ISP and IT managers are still unaware of the need for an IPv6 plan, and are inclined to dismiss IPv4 depletion as a false alarm, and also seem unaware that NATs create expensive support requirements.
o 宣传仍然是必须的，因为许多ISP和it经理似乎仍然不知道IPv6计划的必要性，并且倾向于将IPv4耗尽视为虚惊一场，也似乎不知道NAT会产生昂贵的支持需求。
o Without customers wanting IPv6, getting business backing is very hard, and IPv6 security and scale was not a focus for vendors until very recently.
o 如果没有想要IPv6的客户，获得业务支持是非常困难的，直到最近，IPv6的安全性和规模才成为供应商关注的焦点。
o Operators lack real experience with customer usage of IPv6, and the resulting lack of confidence causes delay.
o 运营商缺乏客户使用IPv6的实际经验，由此造成的信心不足会导致延迟。
Three further quotations are of interest:
还有三个报价值得关注：
"We are planning to move all our management addressing from IPv4 to IPv6 to free up IPv4 addresses."
“我们计划将所有管理寻址从IPv4移动到IPv6，以释放IPv4地址。”
"I am actively pushing our larger customers to start testing IPv6 as our development has pretty much stopped as we need some real world testing to be done."
“我正在积极推动我们的大客户开始测试IPv6，因为我们的开发几乎已经停止，因为我们需要进行一些真实世界的测试。”
"Customer support needs to be aware that IPv6 is being started in your network, or servers. We experienced many IPv6 blocking applications, applications that do not fall back to IPv4, etc. The most difficult part may be to get engineers, sales, customer support personnel to like IPv6."
“客户支持需要知道IPv6正在您的网络或服务器中启动。我们遇到了许多IPv6阻塞应用程序、不返回IPv4的应用程序等。最困难的部分可能是让工程师、销售人员和客户支持人员喜欢IPv6。”
The survey has shown a certain number of desirable features to be missing, either in relevant specifications, or in many products. This section summarizes those gaps.
调查显示，无论是在相关规范中，还是在许多产品中，都缺少一定数量的理想特性。本节总结了这些差距。
As noted above, numerous models of various types of product still do not support IPv6:
如上所述，各种类型产品的许多型号仍然不支持IPv6：
o CPE
o 氯化聚乙烯
o Handsets
o 手机
o DSLAMs
o 数码相机
o Routers
o 路由器
o Traffic management boxes
o 交通管理箱
o Load balancers
o 负载平衡器
o VPN boxes
o VPN箱
o SIP and other appliances
o SIP和其他设备
o Management interfaces and systems
o 管理接口和系统
o Firewalls
o 防火墙
o Even where they support IPv6, customer-side firewalls and routers need to operate at 25-100 Mbit/s
o 即使在支持IPv6的地方，客户端防火墙和路由器也需要以25-100 Mbit/s的速度运行
o Intrusion detection systems
o 入侵检测系统
o Accounting and billing systems
o 会计和帐单系统
It is not the purpose of this document to name and shame vendors, but today it is becoming urgent for all products to avoid becoming part of the IPv4 legacy. ISPs stated that they want consistent feature-equivalent support for IPv4 and IPv6 in all equipment and software at reasonable or no extra cost. The problems can be quite subtle: for example, one CPE with "full" IPv6 support does not support IPv6 traffic shaping, so the ISP cannot cap IPv6 traffic to contractual limits.
本文档的目的不是点名羞辱供应商，但如今，所有产品都迫切需要避免成为IPv4遗留产品的一部分。ISP表示，他们希望在所有设备和软件中以合理或不额外的成本对IPv4和IPv6提供一致的功能等效支持。问题可能相当微妙：例如，一个具有“完全”IPv6支持的CPE不支持IPv6流量整形，因此ISP无法将IPv6流量限制在合同限制内。
Numerous ISPs want a scalable NAT64/DNS64 product.
许多ISP需要可扩展的NAT64/DNS64产品。
The need for IPv6 support in "all the best open source tools" was also mentioned.
还提到“所有最好的开源工具”都需要支持IPv6。
Several ISPs also noted that much commercial applications software does not correctly support IPv6 and that this will cause customer problems. Also, some operating systems are still shipped with IPv6 disabled by default or with features such as IPv4-mapped addresses disabled by default.
几家ISP还指出，许多商业应用软件不正确支持IPv6，这将导致客户问题。此外，某些操作系统仍默认禁用IPv6，或默认禁用IPv4映射地址等功能。
Various needs and issues related mainly to protocols were mentioned:
提到了主要与议定书有关的各种需要和问题：
o A specific CPE need is an intelligent prefix sub-delegation mechanism (ease of use issue).
o 一个特定的CPE需求是智能前缀子委托机制（易用性问题）。
o "Getting it right" so that a dual-stack client doesn't end up trying to use the wrong transport to reach a site.
o “正确使用”，这样双栈客户端就不会试图使用错误的传输到达站点。
o "User-side port allocation mechanisms. UPnP IGD and NAT-PMP can be used for IPv4, but nothing exists for IPv6 (yet)." UPnP IGD refers to the Universal Plug and Play Forum's Internet Gateway Device. NAT-PMP is the NAT Port Mapping Protocol.
o “用户端端口分配机制。UPnP IGD和NAT-PMP可用于IPv4，但IPv6（尚未）不存在。”UPnP IGD指通用即插即用论坛的互联网网关设备。NAT-PMP是NAT端口映射协议。
Editor's comment: even though port mapping is in principle unnecessary for IPv6, a method of opening ports through firewalls on demand seems necessary.
编者按：尽管IPv6原则上不需要端口映射，但通过防火墙按需打开端口的方法似乎是必要的。
o Full Router Advertisement (RA) support on LAN side of ADSL CPE.
o 在ADSL CPE的LAN端提供完整的路由器广告（RA）支持。
o PPPoE and RADIUS support. Specifically, global unicast address assignment for Layer 2 Tunneling Protocol (L2TP) / PPPoE. Currently, the PPPoE client will be assigned a link-local address, requiring a second step (DHCPv6 or SLAAC).
o PPPoE和RADIUS支持。具体而言，第2层隧道协议（L2TP）/PPPoE的全局单播地址分配。目前，PPPoE客户端将被分配一个链路本地地址，需要第二步（DHCPv6或SLAAC）。
o Simple automatic distribution of DNS server details is essential; a DNS server option in RA [RFC5006] is wanted.
o DNS服务器详细信息的简单自动分发至关重要；需要RA[RFC5006]中的DNS服务器选项。
o ISPs need fully featured DHCPv6, especially since SLAAC does not allow settings to be pushed out (except for RFC 5006).
o ISP需要功能齐全的DHCPv6，特别是因为SLAAC不允许推出设置（RFC 5006除外）。
o Firewall systems should not use separate IPv4 and IPv6 rules.
o 防火墙系统不应使用单独的IPv4和IPv6规则。
o Gaps in infrastructure security for IPv6 management.
o IPv6管理基础架构安全方面的差距。
o Gaps in routers' treatment of header options.
o 路由器对报头选项的处理存在差距。
o RA-Guard in switches.
o 开关中的RA防护装置。
o Virtual Router Redundancy Protocol (VRRP) support.
o 虚拟路由器冗余协议（VRRP）支持。
o PE-CE routing protocols (OSPF and IS-IS).
o PE-CE路由协议（OSPF和IS-IS）。
o Problems using a single BGP session to exchange routes for both IPv4 and IPv6.
o 使用单个BGP会话为IPv4和IPv6交换路由时出现问题。
o Consistent IPv6 address display format in outputs and configuration input. Inconsistency breaks a lot of existing tools.
o 输出和配置输入中的一致IPv6地址显示格式。不一致性破坏了许多现有工具。
We also note areas where there was clearly confusion among the ISPs responding, which may denote weaknesses of existing documentation:
我们还注意到，作出答复的ISP之间存在明显的混淆，这可能表明现有文件存在缺陷：
o Perhaps due to poor phrasing in the survey questions, some ISPs indicated that they would use PPPoE or RADIUS to assign prefixes to CPEs. In fact, IPv6 PPP only negotiates 64-bit interface identifiers; a full address has to be assigned by another method, and even this does not delegate a prefix to a CPE router. RADIUS alone is also insufficient, as it needs to be combined with another method for full address assignment.
o 可能是由于调查问题措辞不当，一些ISP表示他们将使用PPPoE或RADIUS为CPE分配前缀。事实上，IPv6 PPP只协商64位接口标识符；完整地址必须由另一种方法分配，即使这样也不会将前缀委托给CPE路由器。RADIUS本身也是不够的，因为它需要与另一种方法相结合来分配完整的地址。
o Although most ISPs see a need for IPv4-IPv6 interworking at the network layer, many of them do not see a need for an ISP to operate the resulting translator. Yet, their customers, whether subscribers or content providers, will be the first to suffer when IPv6-only clients cannot reach IPv4-only services.
o 尽管大多数ISP认为需要在网络层进行IPv4-IPv6互通，但他们中的许多人并不认为需要ISP操作生成的转换器。然而，当仅限IPv6的客户端无法访问仅限IPv4的服务时，他们的客户（无论是订户还是内容提供商）将首先受到影响。
o Most ISPs seemed to misunderstand the nature of a tunnel broker, even though this is a service that any ISP could consider offering to its subscribers.
o 大多数ISP似乎误解了隧道经纪人的本质，尽管这是ISP可以考虑向其用户提供的服务。
Global IPv6 connectivity still has issues; for example, ISPs in the Pacific region may have to obtain IPv6 transit via the USA (a situation faced by IPv4 operators in Europe about twenty years ago). Also, there are persistent Path MTU Discovery (PMTUD) issues in various places on the net, and a lack of multicast peering.
全球IPv6连接仍然存在问题；例如，太平洋地区的ISP可能必须通过美国获得IPv6传输（大约20年前欧洲的IPv4运营商就面临这种情况）。此外，在网络上的各个地方都存在持久路径MTU发现（PMTUD）问题，并且缺少多播对等。
Finally, there was a comment that real deployment case studies must be shown to operators along with multihoming and traffic engineering best practices.
最后，有人评论说，必须向运营商展示实际部署案例研究以及多主和流量工程最佳实践。
As a report on a survey, this document creates no security issues in itself. ISPs did not register any general concerns about IPv6 security. However, we note that about half of all firewall and intrusion detection products are still reported not to support IPv6. Some ISPs expressed concern about firewall performance and about the need for separate firewall configurations for IPv4 and IPv6.
作为调查报告，本文档本身不存在安全问题。ISP并未对IPv6安全性表示任何普遍担忧。然而，我们注意到，据报道，大约一半的防火墙和入侵检测产品仍然不支持IPv6。一些ISP对防火墙性能以及IPv4和IPv6需要单独配置防火墙表示担忧。
We are grateful to all those who answered the questionnaire: Stewart Bamford, Pete Barnwell, Cameron Byrne, Gareth Campling, Kevin Epperson, David Freedman, Wesley George, Steinar Haug, Paul Hoogsteder, Mario Iseli, Christian Jacquenet, Kurt Jaeger, Seiichi Kawamura, Adrian Kennard, Simon Leinen, Riccardo Loselli, Janos Mohacsi, Jon Morby, Michael Newbery, Barry O'Donovan, Al Pooley, Antonio Querubin, Anthony Ryan, Marc Schaeffer, Valeriu Vraciu, Bill Walker, and those who preferred to remain anonymous.
我们感谢所有回答问卷的人：Stewart Bamford、Pete Barnwell、Cameron Byrne、Gareth Campling、Kevin Epperson、David Freedman、Wesley George、Steinar Haug、Paul Hoogsteder、Mario Iseli、Christian Jacquenet、Kurt Jaeger、Seichi Kawamura、Adrian Kennard、Simon Leinen、Riccardo Loselli、Janos Mohacsi、Jon Morby、，迈克尔·纽伯里、巴里·奥多诺万、艾尔·普尔、安东尼奥·克鲁宾、安东尼·瑞安、马克·谢弗、瓦莱里奥·弗拉西奥、比尔·沃克以及那些喜欢匿名的人。
The ISPs willing to be named were: AISP, Alphanet, Breedband Delft, Claranet, E4A, Fidonet, Finecom, France Telecom, Hungarnet, Imagine, LavaNet, Level 3 Communications LLC, NEC BIGLOBE, Nepustilnet, Net North West, RoEduNet, SWITCH, Snap, Sprint, Star Technology, T-Mobile USA, Ventelo, and Whole Ltd.
愿意被点名的ISP有：AISP、Alphanet、Breedband Delft、Claranet、E4A、Fidonet、Finecom、法国电信、Hungarnet、Imagine、LavaNet、Level 3 Communications LLC、NEC BIGLOBE、Nepustilnet、Net North West、RoEduNet、SWITCH、Snap、Sprint、Star Technology、T-Mobile USA、Ventelo和Whole Ltd。
Useful comments and contributions were also made by Shane Amante, Mohamed Boucadair, Mark Smith, and others.
Shane Amante、Mohamed Boucadair、Mark Smith和其他人也发表了有益的评论和贡献。
This document was produced using the xml2rfc tool [RFC2629].
本文档是使用xml2rfc工具[RFC2629]生成的。
[APLUSP] Bush, R., "The A+P Approach to the IPv4 Address Shortage", Work in Progress, October 2009.
[Aplup]Bush，R.，“IPv4地址短缺的A+P方法”，正在进行的工作，2009年10月。
[CGN] Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", Work in Progress, July 2010.
[CGN]Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“IP地址共享方案的通用要求”，正在进行的工作，2010年7月。
[DSLITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, August 2010.
[DSLITE]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，正在进行的工作，2010年8月。
[NODEREQ] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements RFC 4294-bis", Work in Progress, July 2010.
[NODEREQ]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求RFC 4294之二”，正在进行的工作，2010年7月。
[PRANGE] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture", Work in Progress, July 2009.
[PRANGE]Boucadair，M.，Levis，P.，Bajko，G.，和T.Savolainen，“IPv4地址耗尽背景下的IPv4连接访问：基于端口范围的IP架构”，正在进行的工作，2009年7月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，“IPv6节点要求”，RFC 42942006年4月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月。
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and J. Palet, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", RFC 4779, January 2007.
[RFC4779]Asadullah，S.，Ahmed，A.，Popoviciu，C.，Savola，P.，和J.Palet，“宽带接入网络中的ISP IPv6部署场景”，RFC 4779，2007年1月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 49422007年9月。
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007.
[RFC5006]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 5006，2007年9月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[RFC5121]Patil，B.，Xia，F.，Sarikaya，B.，Choi，JH.，和S.Madanapalli，“通过IEEE 802.16网络上的IPv6聚合子层传输IPv6”，RFC 51212008年2月。
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[RFC5181]Shin，M-K.，Han，Y-H.，Kim，S-E.，和D.Premec，“802.16网络中的IPv6部署场景”，RFC 5181，2008年5月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211]Curran，J.，“互联网转型计划”，RFC 52112008年7月。
[RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009.
[RFC5692]Jeon，H.，Jeong，S.，和M.Riegel，“通过IEEE 802.16网络通过以太网传输IP”，RFC 5692，2009年10月。
This summarizes the 31 replies received by April 14, 2010. Note that the answers to some questions do not total to 31, due to missing answers or to multiple choices in some cases. The ISPs are distributed as follows:
这总结了截至2010年4月14日收到的31份答复。请注意，由于缺少答案或在某些情况下有多项选择，某些问题的答案总数不到31。互联网服务供应商的分布情况如下：
Europe: 20
欧洲：20
North America: 7
北美洲：7
Asia/Pacific: 4
亚洲/太平洋：4
They can additionally be classified as:
此外，它们还可分为：
Commercial: 26
商业：26
Academic/research: 4
学术/研究：4
Operating internationally: 6
国际运作：6
Operating nationally: 25
在全国开展业务：25
Basic data about IP service offerings:
有关IP服务产品的基本数据：
o Offering both origin-only and transit service: 25
o 仅提供始发地和中转服务：25
o Offering no transit: 6
o 不提供过境服务：6
o Number of private/small office customers (one IPv4 address): a few with zero, then from 30 units up to 40 million
o 私人/小型办公室客户数量（一个IPv4地址）：少数为零，然后从30个单位增加到4000万个
o Number of corporate customers (block of IPv4 addresses): a few with zero, then from 40 units up to 40000
o 公司客户数量（IPv4地址块）：少数为零，然后从40个单位增加到40000个单位
o IP multicast service? 9 yes, 22 no
o IP多播服务？9是，22不是
o Do any customers require multihoming to multiple ISPs? 25 yes, 6 no
o 是否有客户需要多家ISP的多主服务？25是，6不是
o Access technologies used: xDSL, DOCSIS, leased line (X.25, TDM/ PDH, SDH), ATM, frame relay, dialup, microwave, FTTP, CDMA, UMTS, LTE, WiMAX, BWA, WiFi, Ethernet (100M-10G), Ether/SONET, Ether/ MPLS, IPv6-in-IPv4 tunnels.
o 使用的接入技术：xDSL、DOCSIS、专线（X.25、TDM/PDH、SDH）、ATM、帧中继、拨号、微波、FTTP、CDMA、UMTS、LTE、WiMAX、BWA、WiFi、以太网（100M-10G）、以太网/SONET、以太网/MPLS、IPv6-in-IPv4隧道。
Customer Premises Equipment:
客户场所设备：
o Do customers use CPE that ISP supplies? 27 yes (10% to 100% of customers), 4 no
o 客户是否使用ISP提供的CPE？27是（10%至100%的客户），4否
o Does the CPE provided support native IPv6? 17 yes (some), 10 no
o CPE提供的是否支持本机IPv6？17是（部分），10不是
o (Note that these numbers include answers that apply to tens of millions of mobile handsets.)
o （请注意，这些数字包括适用于数千万部手机的答案。）
IPv4 Address Space:
IPv4地址空间：
o When do you expect to run out of public IPv4 address space inside your own network? Estimates run from "now" to 2020, but 5 ISPs say "never" or "unforeseeable".
o 您希望什么时候用完自己网络中的公共IPv4地址空间？估计从“现在”到2020年，但有5家ISP表示“从未”或“无法预见”。
o Do you run RFC1918 addresses and NAT within your network? 9 yes; 18 no; 3 others say yes, but only for equipment management or L3VPN.
o 您是否在网络中运行RFC1918地址和NAT？9是；18没有；3其他人同意，但仅限于设备管理或L3VPN。
o What % of IPv4 space is needed for ISP use (not for customers)? 1% to 30% (and 100% for NRENs with PI customers).
o ISP使用（而非客户）需要多少%的IPv4空间？1%至30%（有PI客户的NREN为100%）。
o When do you expect to run out of public IPv4 address space for customers? Answers range from 2010 to 2015; 4 ISPs say it depends on their registry. 4 or 5 give answers suggesting it will never happen.
o 您预计客户的公共IPv4地址空间何时会用完？答案从2010年到2015年不等；4家ISP表示这取决于他们的注册。4或5给出的答案表明它永远不会发生。
o Do you offer RFC1918 addresses to customers? 6 yes, 24 no
o 您是否向客户提供RFC1918地址？6是，24不是
IPv6 Requirements:
IPv6要求：
o Are some big customers requesting IPv6? 19 yes, 12 no
o 是否有一些大客户请求IPv6？19是，12不是
o When do you predict 10% and 50% of customers to require IPv6 service? Ignoring unclear answers, answers for 10% range from 2010 to 2017, and for 50% from 2011 to 2020.
o 您预测10%和50%的客户何时需要IPv6服务？忽略不清楚的答案，10%的答案从2010年到2017年，50%的答案从2011年到2020年。
o When do you require IPv6 to be a standard service available to all customers? Answers range from 2010 to 2015; the most common answer is 2011.
o 您何时要求IPv6成为可供所有客户使用的标准服务？答案从2010年到2015年不等；最常见的答案是2011年。
o When do you predict IPv6 traffic to reach 50% of total traffic? Answers range from 2011 to 2020; the most common answer is 2015.
o 您预计IPv6流量何时会达到总流量的50%？答案从2011年到2020年不等；最常见的答案是2015年。
IPv6 Status and Plans:
IPv6状态和计划：
o Do you currently offer IPv6 as a regular service? 13 yes, 5 partial, 12 no
o 您目前是否将IPv6作为常规服务提供？13是，5部分，12否
o What % of customers currently use IPv6? <1% to 30%; mostly 0 or <1%
o 目前有多少%的客户使用IPv6<1%至30%；大部分为0或<1%
o When do you plan to start IPv6 deployment? 12 complete, 12 in progress, 3 in plan, 4 have no plan
o 您计划何时开始IPv6部署？12个已完成，12个在进行中，3个在计划中，4个没有计划
o When do you plan to offer IPv6 as a special or beta-test service? For all those in progress or with a plan, the answer was either "now" or during 2010.
o 您计划何时将IPv6作为一种特殊或测试服务提供？对于所有正在进行或有计划的人来说，答案要么是“现在”，要么是2010年。
o When do you plan to offer IPv6 as a regular service to all customers? For all those in progress or with a plan, the answer was between "now" and 2013 (except for one ISP who replied that it depends on the marketing department).
o 您计划何时向所有客户提供IPv6作为常规服务？对于所有正在进行或有计划的人来说，答案是从“现在”到2013年（除了一家ISP回答说这取决于营销部门）。
IPv6 Technologies. Note the answers refer to actual deployment or to plans, as the case may be:
IPv6技术。注：答案指实际部署或计划，视情况而定：
o Which basic IPv6 access method(s) apply?
o 应用哪种基本IPv6访问方法？
* Dual-stack routing backbone: 29 yes, 1 maybe
* 双堆栈路由主干：29是的，可能1个
* Separate IPv4 and IPv6 backbones: 2 yes, 1 maybe
* 独立的IPv4和IPv6主干：2个是，1个可能
* 6to4 relay: 12 yes
* 6to4继电器：12是
* Teredo server: 5 yes
* Teredo服务器：5是
* Tunnel broker: Unfortunately this question was unclear and obviously misunderstood by most respondents. Several respondents mentioned that they are getting their own transit connectivity via static tunnels.
* 隧道经纪人：不幸的是，这个问题不清楚，显然被大多数受访者误解了。一些受访者提到，他们正在通过静态隧道实现自己的公交连接。
* Something else: Answers were 6VPE + NAT64/DNS64; PNAT; "considering 6RD"
* 另外：答案是6VPE+NAT64/DNS64；PNAT；“考虑第6条”
o Please briefly explain the main reasons/issues behind your choice: The best summary of the answers is "dual stack is simplest, why do anything else?".
o 请简要说明您选择的主要原因/问题：答案的最佳总结是“双堆栈最简单，为什么还要做其他事情？”。
o Which types of equipment in your network are unable to support IPv6? The most common answer was CPE (9 mentions). Also mentioned: handsets; DSLAMs; routers (including several specific
o 您网络中的哪些类型的设备无法支持IPv6？最常见的答案是CPE（9次提及）。还提到：手机；数码相机；路由器（包括几个特定的
models); traffic management boxes; load balancers; VPN boxes; some SIP platforms; management interfaces & systems; firewalls; billing systems.
模型）；交通管理箱；负载均衡器；VPN箱；一些SIP平台；管理接口和系统；防火墙；计费系统。
o Can they be field-upgraded? 5 yes, 4 partially, 10 no and numerous "don't know" or "hopefully"
o 它们可以现场升级吗？5个是，4个部分，10个不是，还有很多“不知道”或“希望”
o Is any equipment 100% dedicated to IPv6? 7 yes, 24 no
o 是否有设备100%专用于IPv6？7是，24不是
o Is IPv6 an opportunity to restructure your whole topology? 2 yes, 5 partial, 23 no
o IPv6是重组整个拓扑结构的机会吗？2个是，5个部分，23个不是
o Do you include support for DNS AAAA queries over IPv6? 21 yes, 5 plan, 4 no
o 您是否支持IPv6上的DNS AAAA查询？21是，5个计划，4个否
o Do you include support for reverse DNS for IPv6 addresses? 22 yes, 3 plan, 5 no
o 您是否支持IPv6地址的反向DNS？22是，3个计划，5个不是
o What length(s) of IPv6 prefix do you have or need from the registry? 1 /19, 1 /21 (plus several /32s), 1 /22 1 /30, 3 multiple /32s, 21 /32, 3 /48
o 您在注册表中拥有或需要多少长度的IPv6前缀？1/19，1/21（加上几个/32），1/22 1/30，3个倍数/32，21/32，3/48
o What length(s) of IPv6 prefix are offered to customers? 15 ISPs offer more than one of /48, /52, /56, /60 or /64. 2 offer /56 only, 8 offer /48 only. Two wired operators offer /64 only. Mobile operators offer /64 in accordance with 3GPP, but at least one would like to be allowed to offer /128 or /126.
o 向客户提供的IPv6前缀长度是多少？15家ISP提供/48、/52、/56、/60或/64中的多家。2个报价/56，8个报价/48。两个有线运营商仅提供/64。移动运营商根据3GPP提供/64，但至少有一家希望被允许提供/128或/126。
o Do any customers share their IPv6 prefix among multiple hosts? Unfortunately this question was unclear and obviously misunderstood by most respondents.
o 是否有客户在多台主机之间共享其IPv6前缀？不幸的是，这个问题不清楚，显然被大多数受访者误解了。
o Do any of your customers prefer to use PI IPv6 prefixes? 10 yes, 17 no
o 您的客户是否喜欢使用PI IPv6前缀？10是，17不是
o How are IPv6 prefixes delegated to CPEs? 16 manual, 10 DHCPv6[-PD], 8 SLAAC, 8 RADIUS, 2 PPPoE. (Note: RADIUS and PPP cannot in fact delegate prefixes.)
o IPv6前缀如何委托给CPE？16手动，10 DHCPv6[-PD]，8 SLAAC，8半径，2 PPPoE。（注意：RADIUS和PPP实际上不能委托前缀。）
o Are your SMTP, POP3 and IMAP services dual stack? 10 yes, 6 plan, 13 no
o 您的SMTP、POP3和IMAP服务是双堆栈的吗？10是，6计划，13否
o Are your HTTP services, including caching and webmail, dual-stack? 9 yes, 1 partial, 4 plan, 15 no
o 您的HTTP服务（包括缓存和webmail）是双堆栈的吗？9是，1部分，4计划，15否
o Are any other services dual stack? 11 yes, 2 plan, 11 no
o 还有其他服务是双栈的吗？11是，2计划，11否
o Is each of the following dual stack?
o 以下每一个都是双堆栈吗？
* Firewalls: 12 yes, 3 partial, 3 plan, 9 no
* 防火墙：12个是，3个部分，3个计划，9个否
* Intrusion detection: 10 yes, 2 plan, 13 no
* 入侵检测：10是，2计划，13否
* Address management software: 15 yes, 1 plan, 13 no
* 地址管理软件：15个是，1个计划，13个否
* Accounting software: 7 yes, 21 no
* 会计软件：7个是，21个不是
* Monitoring software: 16 yes, 2 partial, 2 plan, 11 no
* 监控软件：16是，2部分，2计划，11否
* Network management tools: 13 yes, 4 partial, 1 plan, 11 no
* 网络管理工具：13个是，4个部分，1个计划，11个否
o Do you or will you have IPv6-only customers? 13 yes (or maybe), 18 no (or not likely)
o 您是否或是否将拥有仅限IPv6的客户？13是（或可能），18否（或不太可能）
o Do you have customers who have explicitly refused to consider IPv6? 5 yes, 23 no
o 你有没有明确拒绝考虑IPv6的客户？5是，23不是
o Interworking issues:
o 互通问题：
* How many years do you expect customers to run any IPv4-only applications? Answers range from 2 years to infinity, most frequent answer is >10 years.
* 您希望客户在几年内运行任何仅IPv4的应用程序？答案从2年到无限期不等，最常见的答案是>10年。
* Is IPv6-IPv4 interworking at the IP layer needed? 16 yes, 9 uncertain, 3 no
* 是否需要在IP层进行IPv6-IPv4互通？16是，9不确定，3不确定
* Do you include a NAT-PT IPv6/IPv4 translator? 2 yes, 1 plan, 26 no
* 是否包含NAT-PT IPv6/IPv4转换器？2是，1计划，26否
* If yes, does that include DNS translation? 1 plan, 2 no
* 如果是，是否包括DNS翻译？1份计划，2份
* If not, do you plan to operate an IPv6/IPv4 translator? 10 plan (NAT64), 8 no, others uncertain
* 如果没有，您是否计划运行IPv6/IPv4转换器？10个计划（NAT64），8个，其他不确定
* If not, how do you plan to connect IPv6-only customers to IPv4- only services? 7 rely on dual stack; 4 have no plan (one said "their problem")
* 如果没有，您计划如何将仅限IPv6的客户连接到仅限IPv4的服务？7依靠双栈；4没有计划（有人说“他们的问题”）
* If you offer IP multicast, will that need to be translated too? 2 yes, 2 uncertain, 5 no
* 如果您提供IP多播，是否也需要翻译？2是，2不确定，5否
o Any plans for Mobile IPv6 (or Nemo mobile networks)? 6 yes, 2 uncertain, 22 no
o 有关于移动IPv6（或Nemo移动网络）的计划吗？6是，2不确定，22否
This appendix reproduces the technical body of the questionnaire that was made available for ISPs to express their requirements, plans, and experience.
本附录复制了调查问卷的技术主体，供ISP表达其要求、计划和经验。
I. General questions about IP service
一、关于IP服务的一般问题
1. Do you offer origin-only (stub, end-user) IP service, transit IP service, or both?
1. 您是否只提供源站（存根、最终用户）IP服务、中转IP服务，还是两者都提供？
2. Approximate number of private/small office customers (one IPv4 address)
2. 私人/小型办公室客户的大概数量（一个IPv4地址）
3. Approximate number of corporate customers (block of IPv4 addresses, not included in Q2)
3. 公司客户的大致数量（IPv4地址块，不包括在第2季度）
4. Do you offer IP multicast service?
4. 你们提供IP多播服务吗？
5. Do any of your customers require multihoming to multiple ISPs?
5. 您的任何客户是否需要多家ISP的多主服务？
6. Access technologies used (ADSL,etc.)
6. 使用的接入技术（ADSL等）
7. Do your customers use CPE that you supply?
7. 您的客户是否使用您提供的CPE？
7.1. What % of customers?
7.1. 多少%的客户？
7.2. Does the CPE that you provide support native IPv6?
7.2. 您提供的CPE是否支持本机IPv6？
8. When do you expect to run out of public IPv4 address space inside your own network?
8. 您希望什么时候用完自己网络中的公共IPv4地址空间？
8.1. Do you run private (RFC1918) addresses and NAT within your network (i.e., a second layer of NAT in the case of customers with their own NAT)?
8.1. 您是否在您的网络中运行专用（RFC1918）地址和NAT（即，如果客户拥有自己的NAT，则为第二层NAT）？
8.2. What % of your IPv4 space is needed for your own use (not for customers)?
8.2. 您需要多少%的IPv4空间供自己使用（不供客户使用）？
9. When do you expect to run out of public IPv4 address space for customers?
9. 您预计客户的公共IPv4地址空间何时会用完？
9.1. Do you offer private (RFC1918) addresses to your customers?
9.1. 您是否向客户提供私人（RFC1918）地址？
II. Questions about requirements for IPv6 service
二,。关于IPv6服务要求的问题
10. Are some big customers requesting IPv6?
10. 是否有一些大客户请求IPv6？
11. When do you predict 10% and 50% of your customers to require IPv6 service?
11. 您预计10%和50%的客户何时需要IPv6服务？
12. When do you require IPv6 to be a standard service available to all customers?
12. 您何时要求IPv6成为可供所有客户使用的标准服务？
13. When do you predict IPv6 traffic to reach 50% of total traffic?
13. 您预计IPv6流量何时会达到总流量的50%？
III. Questions about status and plans for IPv6 service
三、 有关IPv6服务的状态和计划的问题
14. Do you currently offer IPv6 as a regular service?
14. 您目前是否将IPv6作为常规服务提供？
14.1. What % of your customers currently use IPv6?
14.1. 您有多少%的客户目前使用IPv6？
14.2. When do you plan to start IPv6 deployment?
14.2. 您计划何时开始IPv6部署？
14.3. When do you plan to offer IPv6 as a special or beta-test service to customers?
14.3. 您计划何时向客户提供IPv6作为特殊或测试版服务？
15. When do you plan to offer IPv6 as a regular service to all customers?
15. 您计划何时向所有客户提供IPv6作为常规服务？
IV. Questions about IPv6 technologies
四、 关于IPv6技术的问题
16. Which basic IPv6 access method(s) apply:
16. 适用哪些基本IPv6访问方法：
16.1. dual stack routing backbone?
16.1. 双栈路由主干网？
16.2. separate IPv4 and IPv6 backbones?
16.2. 独立的IPv4和IPv6主干网？
16.3. 6to4 relay?
16.3. 6to4接力？
16.4. Teredo server?
16.4. Teredo服务器？
16.5. tunnel broker? If so, which one?
16.5. 隧道经纪人？如果是，哪一个？
16.6. Something else? Please briefly describe your method:
16.6. 还有别的吗？请简要描述您的方法：
16.7. If possible, please briefly explain the main reasons/ issues behind your choice.
16.7. 如果可能，请简要说明您选择的主要原因/问题。
17. Which types of equipment in your network are unable to support IPv6?
17. 您网络中的哪些类型的设备无法支持IPv6？
17.1. Can they be field-upgraded to support IPv6?
17.1. 它们是否可以现场升级以支持IPv6？
17.2. Is any equipment 100% dedicated to IPv6?
17.2. 是否有设备100%专用于IPv6？
18. Is IPv6 an opportunity to restructure your whole topology?
18. IPv6是重组整个拓扑结构的机会吗？
19. Do you include support for DNS AAAA queries over IPv6?
19. 您是否支持IPv6上的DNS AAAA查询？
20. Do you include support for reverse DNS for IPv6 addresses?
20. 您是否支持IPv6地址的反向DNS？
21. What length(s) of IPv6 prefix do you have or need from the registry?
21. 您在注册表中拥有或需要多少长度的IPv6前缀？
22. What length(s) of IPv6 prefix are offered to customers?
22. 向客户提供的IPv6前缀长度是多少？
22.1. Do any customers share their IPv6 prefix among multiple hosts?
22.1. 是否有客户在多台主机之间共享其IPv6前缀？
23. Do any of your customers prefer to use PI IPv6 prefixes instead of a prefix from you?
23. 您的客户是否愿意使用PI IPv6前缀而不是您提供的前缀？
24. How are IPv6 prefixes delegated to CPEs? (Manual, PPPoE, RADIUS, DHCPv6, stateless autoconfiguration/RA, etc...)
24. IPv6前缀如何委托给CPE？（手动、PPPoE、RADIUS、DHCPv6、无状态自动配置/RA等）
25. Are your SMTP, POP3 and IMAP services dual-stack?
25. 您的SMTP、POP3和IMAP服务是双堆栈的吗？
26. Are your HTTP services, including caching and webmail, dual-stack?
26. 您的HTTP服务（包括缓存和webmail）是双堆栈的吗？
27. Are any other services dual-stack?
27. 还有其他服务是双栈的吗？
28. Is each of the following dual-stack?
28. 以下每一个都是双堆栈吗？
28.1. Firewalls
28.1. 防火墙
28.2. Intrusion detection
28.2. 入侵检测
28.3. Address management software
28.3. 地址管理软件
28.4. Accounting software
28.4. 会计软件
28.5. Monitoring software
28.5. 监控软件
28.6. Network management tools
28.6. 网络管理工具
29. Do you or will you have IPv6-only customers?
29. 您是否或是否将拥有仅限IPv6的客户？
30. Do you have customers who have explicitly refused to consider IPv6?
30. 你有没有明确拒绝考虑IPv6的客户？
31. How many years do you expect customers to run any IPv4-only applications?
31. 您希望客户在几年内运行任何仅IPv4的应用程序？
32. Is IPv6-IPv4 interworking at the IP layer needed?
32. 是否需要在IP层进行IPv6-IPv4互通？
33. Do you include a NAT-PT IPv6/IPv4 translator?
33. 是否包含NAT-PT IPv6/IPv4转换器？
33.1. If yes, does that include DNS translation?
33.1. 如果是，是否包括DNS翻译？
33.2. If not, do you plan to operate an IPv6/IPv4 translator?
33.2. 如果没有，您是否计划运行IPv6/IPv4转换器？
33.3. If not, how do you plan to connect IPv6-only customers to IPv4-only services?
33.3. 如果没有，您计划如何将仅限IPv6的客户连接到仅限IPv4的服务？
33.4. If you offer IP multicast, will that need to be translated too?
33.4. 如果您提供IP多播，是否也需要翻译？
34. Any plans for Mobile IPv6 (or Nemo mobile networks)?
34. 有关于移动IPv6（或Nemo移动网络）的计划吗？
35. What features and tools are missing today for IPv6 deployment and operations?
35. 目前IPv6部署和操作缺少哪些功能和工具？
36. Any other comments about your IPv6 experience or plans? What went well, what was difficult, etc.
36. 对您的IPv6体验或计划还有其他意见吗？什么进展顺利，什么困难，等等。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China
中国北京市海淀区上地信息产业基地新西路9号盛江华为技术有限公司魁克大厦
EMail: shengjiang@huawei.com
EMail: shengjiang@huawei.com