Network Working Group C. Huitema
Request for Comments: 3904 Microsoft
Category: Informational R. Austein
ISC
S. Satapati
Cisco Systems, Inc.
R. van der Pol
NLnet Labs
September 2004
Network Working Group C. Huitema
Request for Comments: 3904 Microsoft
Category: Informational R. Austein
ISC
S. Satapati
Cisco Systems, Inc.
R. van der Pol
NLnet Labs
September 2004
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
非托管网络IPv6转换机制的评估
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed.
本文档分析了“非托管网络”从IPv4过渡到IPv6过程中涉及的问题。非托管网络通常对应于家庭网络或小型办公室网络。另一篇论文分析了这些网络向IPv6过渡的各种场景中所需的机制需求。从这一分析开始，我们评估已经指定、提议或部署的机制的适用性。
Table of Contents:
目录：
1. Introduction ................................................. 2
2. Evaluation of Tunneling Solutions ............................ 3
2.1. Comparing Automatic and Configured Solutions ........... 3
2.1.1. Path Optimization in Automatic Tunnels ......... 4
2.1.2. Automatic Tunnels and Relays ................... 4
2.1.3. The Risk of Several Parallel IPv6 Internets .... 5
2.1.4. Lifespan of Transition Technologies ............ 6
2.2. Cost and Benefits of NAT Traversal ..................... 6
2.2.1. Cost of NAT Traversal .......................... 7
2.2.2. Types of NAT ................................... 7
2.2.3. Reuse of Existing Mechanisms ................... 8
2.3. Development of Transition Mechanisms ................... 8
1. Introduction ................................................. 2
2. Evaluation of Tunneling Solutions ............................ 3
2.1. Comparing Automatic and Configured Solutions ........... 3
2.1.1. Path Optimization in Automatic Tunnels ......... 4
2.1.2. Automatic Tunnels and Relays ................... 4
2.1.3. The Risk of Several Parallel IPv6 Internets .... 5
2.1.4. Lifespan of Transition Technologies ............ 6
2.2. Cost and Benefits of NAT Traversal ..................... 6
2.2.1. Cost of NAT Traversal .......................... 7
2.2.2. Types of NAT ................................... 7
2.2.3. Reuse of Existing Mechanisms ................... 8
2.3. Development of Transition Mechanisms ................... 8
3. Meeting Case A Requirements .................................. 9
3.1. Evaluation of Connectivity Mechanisms .................. 9
3.2. Security Considerations in Case A ...................... 9
4. Meeting case B Requirements .................................. 10
4.1. Connectivity ........................................... 10
4.1.1. Extending a Subnet to Span Multiple Links ...... 10
4.1.2. Explicit Prefix Delegation ..................... 11
4.1.3. Recommendation ................................. 11
4.2. Communication Between IPv4-only and IPv6-Capable Nodes . 11
4.3. Resolution of Names to IPv6 Addresses .................. 12
4.3.1. Provisioning the Address of a DNS Resolver ..... 12
4.3.2. Publishing IPv6 Addresses to the Internet ...... 12
4.3.3. Resolving the IPv6 Addresses of Local Hosts .... 13
4.3.4. Recommendations for Name Resolution ............ 13
4.4. Security Considerations in Case B ...................... 14
5. Meeting Case C Requirements .................................. 14
5.1. Connectivity ........................................... 14
6. Meeting the Case D Requirements .............................. 14
6.1. IPv6 Addressing Requirements ........................... 15
6.2. IPv4 Connectivity Requirements ........................ 15
6.3. Naming Requirements .................................... 15
7. Recommendations .............................................. 15
8. Security Considerations ...................................... 16
9. Acknowledgements ............................................. 16
10. References ................................................... 16
11. Authors' Addresses ........................................... 18
12. Full Copyright Statement ..................................... 19
3. Meeting Case A Requirements .................................. 9
3.1. Evaluation of Connectivity Mechanisms .................. 9
3.2. Security Considerations in Case A ...................... 9
4. Meeting case B Requirements .................................. 10
4.1. Connectivity ........................................... 10
4.1.1. Extending a Subnet to Span Multiple Links ...... 10
4.1.2. Explicit Prefix Delegation ..................... 11
4.1.3. Recommendation ................................. 11
4.2. Communication Between IPv4-only and IPv6-Capable Nodes . 11
4.3. Resolution of Names to IPv6 Addresses .................. 12
4.3.1. Provisioning the Address of a DNS Resolver ..... 12
4.3.2. Publishing IPv6 Addresses to the Internet ...... 12
4.3.3. Resolving the IPv6 Addresses of Local Hosts .... 13
4.3.4. Recommendations for Name Resolution ............ 13
4.4. Security Considerations in Case B ...................... 14
5. Meeting Case C Requirements .................................. 14
5.1. Connectivity ........................................... 14
6. Meeting the Case D Requirements .............................. 14
6.1. IPv6 Addressing Requirements ........................... 15
6.2. IPv4 Connectivity Requirements ........................ 15
6.3. Naming Requirements .................................... 15
7. Recommendations .............................................. 15
8. Security Considerations ...................................... 16
9. Acknowledgements ............................................. 16
10. References ................................................... 16
11. Authors' Addresses ........................................... 18
12. Full Copyright Statement ..................................... 19
This document analyzes the issues involved in the transition from IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the "unmanaged networks", which typically correspond to home networks or small office networks, and the requirements for transition mechanisms in various scenarios of transition to IPv6.
本文档分析了从IPv4过渡到IPv6[IPv6]过程中涉及的问题。在一篇配套论文[UNMANREQ]中，我们定义了“非托管网络”，它通常对应于家庭网络或小型办公室网络，以及过渡到IPv6的各种场景中对过渡机制的要求。
The requirements for unmanaged networks are expressed by analyzing four classes of applications: local, client, peer to peer, and servers, and are considering four cases of deployment. These are:
非托管网络的需求通过分析四类应用程序来表达：本地、客户端、对等和服务器，并考虑四种部署情况。这些是：
A) a gateway which does not provide IPv6 at all;
B) a dual-stack gateway connected to a dual-stack ISP;
C) a dual-stack gateway connected to an IPv4-only ISP; and
D) a gateway connected to an IPv6-only ISP.
A) a gateway which does not provide IPv6 at all;
B) a dual-stack gateway connected to a dual-stack ISP;
C) a dual-stack gateway connected to an IPv4-only ISP; and
D) a gateway connected to an IPv6-only ISP.
During the transition phase from IPv4 to IPv6 there will be IPv4- only, dual-stack, or IPv6-only nodes. In this document, we make the hypothesis that the IPv6-only nodes do not need to communicate with
在从IPv4到IPv6的过渡阶段，将有仅IPv4、双堆栈或仅IPv6的节点。在本文中，我们假设仅IPv6节点不需要与其他节点通信
IPv4-only nodes; devices that want to communicate with both IPv4 and IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be dual-stack.
仅IPv4节点；希望同时与IPv4和IPv6节点通信的设备应同时实现IPv4和IPv6，即双栈。
The issues involved are described in the next sections. This analysis outlines two types of requirements: connectivity requirements, i.e., how to ensure that nodes can exchange IP packets, and naming requirements, i.e., how to ensure that nodes can resolve each-other's names. The connectivity requirements often require tunneling solutions. We devote the first section of this memo to an evaluation of various tunneling solutions.
下一节将介绍涉及的问题。此分析概述了两种类型的需求：连接性需求（即如何确保节点可以交换IP数据包）和命名需求（即如何确保节点可以解析彼此的名称）。连接要求通常需要隧道解决方案。我们将在本备忘录的第一部分对各种隧道解决方案进行评估。
In the case A and case C scenarios described in [UNMANREQ], the unmanaged network cannot obtain IPv6 service, at least natively, from its ISP. In these cases, the IPv6 service will have to be provided through some form of tunnel. There have been multiple proposals on different ways to tunnel IPv6 through an IPv4 service. We believe that these proposals can be categorized according to two important properties:
在[UNMANREQ]中描述的案例A和案例C场景中，非托管网络无法从其ISP获得IPv6服务，至少本机无法。在这些情况下，IPv6服务必须通过某种形式的隧道提供。关于通过IPv4服务隧道IPv6的不同方式，已经有多种建议。我们认为，这些提案可根据两个重要性质进行分类：
* Is the deployment automatic, or does it require explicit configuration or service provisioning?
* 部署是自动的，还是需要显式配置或服务供应？
* Does the proposal allow for the traversal of a NAT?
* 该方案是否允许穿越NAT？
These two questions divide the solution space into four broad classes. Each of these classes has specific advantages and risks, which we will now develop.
这两个问题将解空间划分为四大类。这些类别中的每一个都有特定的优势和风险，我们现在将开发这些优势和风险。
It is possible to broadly classify tunneling solutions as either "automatic" or "configured". In an automatic solution, a host or a router builds an IPv6 address or an IPv6 prefix by combining a pre-defined prefix with some local attribute, such as a local IPv4 address [6TO4] or the combination of an address and a port number [TEREDO]. Another typical and very important characteristic of an automatic solution is they aim to work with a minimal amount of support or infrastructure for IPv6 in the local or remote ISPs.
可以将隧道解决方案大致分类为“自动”或“配置”。在自动解决方案中，主机或路由器通过将预定义前缀与某些本地属性（例如本地IPv4地址[6TO4]或地址与端口号[TEREDO]的组合）组合来构建IPv6地址或IPv6前缀。自动化解决方案的另一个典型且非常重要的特征是，它们旨在在本地或远程ISP中使用最少的IPv6支持或基础设施。
In a configured solution, a host or a router identifies itself to a tunneling service to set up a "configured tunnel" with an explicitly defined "tunnel router". The amount of actual configuration may vary from manually configured static tunnels to dynamic tunnel services requiring only the configuration of a "tunnel broker", or even a completely automatic discovery of the tunnel router.
在配置的解决方案中，主机或路由器将自己标识为隧道服务，以使用明确定义的“隧道路由器”建立“配置的隧道”。实际配置的数量可能会有所不同，从手动配置的静态隧道到只需要配置“隧道代理”甚至完全自动发现隧道路由器的动态隧道服务。
Configured tunnels have many advantages over automatic tunnels. The client is explicitly identified and can obtain a stable IPv6 address. The service provider is also well identified and can be held responsible for the quality of the service. It is possible to route multicast packets over the established tunnel. There is a clear address delegation path, which enables easy support for reverse DNS lookups.
与自动隧道相比，配置隧道具有许多优势。客户端被明确标识，可以获得稳定的IPv6地址。服务提供商也有明确的身份，并对服务质量负责。可以通过已建立的隧道路由多播数据包。有一个清晰的地址委派路径，可以轻松支持反向DNS查找。
Automatic tunnels generally cannot provide the same level of service. The IPv6 address is only as stable as the underlying IPv4 address, the quality of service depends on relays operated by third parties, there is typically no support for multicast, and there is often no easy way to support reverse DNS lookups (although some workarounds are probably possible). However, automatic tunnels have other advantages. They are obviously easier to configure, since there is no need for an explicit relation with a tunnel service. They may also be more efficient in some cases, as they allow for "path optimization".
自动隧道通常不能提供相同水平的服务。IPv6地址仅与基础IPv4地址一样稳定，服务质量取决于第三方操作的中继，通常不支持多播，并且通常没有支持反向DNS查找的简单方法（尽管可能有一些解决方法）。然而，自动隧道还有其他优点。它们显然更易于配置，因为不需要与隧道服务建立明确的关系。在某些情况下，它们可能更有效，因为它们允许“路径优化”。
In automatic tunnels like [TEREDO] and [6TO4], the bulk of the traffic between two nodes using the same technology is exchanged on a direct path between the endpoints, using the IPv4 services to which the endpoints already subscribe. By contrast, the configured tunnel servers carry all the traffic exchanged by the tunnel client.
在像[TEREDO]和[6TO4]这样的自动隧道中，使用相同技术的两个节点之间的大部分流量在端点之间的直接路径上交换，使用端点已经订阅的IPv4服务。相比之下，配置的隧道服务器承载隧道客户端交换的所有流量。
Path optimization is not a big issue if the tunnel server is close to the client on the natural path between the client and its peers. However, if the tunnel server is operated by a third party, this third party will have to bear the cost of provisioning the bandwidth used by the client. The associated costs can be significant.
如果隧道服务器在客户端与其对等方之间的自然路径上靠近客户端，则路径优化不是一个大问题。但是，如果隧道服务器由第三方操作，则该第三方必须承担提供客户端使用的带宽的成本。相关成本可能是巨大的。
These costs are largely absent when the tunnels are configured by the same ISP that provides the IPv4 service. The ISP can place the tunnel end-points close to the client, i.e., mostly on the direct path between the client and its peers.
当隧道由提供IPv4服务的同一ISP配置时，这些成本基本不存在。ISP可以将隧道端点放置在靠近客户端的位置，即，主要位于客户端与其对等方之间的直接路径上。
The economics arguments related to path optimization favor either configured tunnels provided by the local ISP or automatic tunneling regardless of the co-operation of ISPs. However, automatic solutions require that relays be configured throughout the Internet. If a host that obtained connectivity through an automatic tunnel service wants to communicate with a "native" host or with a host using a configured
与路径优化相关的经济学论据支持本地ISP提供的配置隧道或自动隧道，无论ISP是否合作。然而，自动解决方案要求在整个互联网上配置继电器。如果通过自动隧道服务获得连接的主机希望与“本机”主机或使用配置的
tunnel, it will need to use a relay service, and someone will have to provide and pay for that service. We cannot escape economic considerations for the deployment of these relays.
隧道，它将需要使用中继服务，并将有人提供和支付该服务。我们无法逃避部署这些继电器的经济考虑。
It is desirable to locate these relays close to the "native host". During the transition period, the native ISPs have an interest in providing a relay service for use by their native subscribers. Their subscribers will enjoy better connectivity, and will therefore be happier. Providing the service does not result in much extra bandwidth requirement: the packets are exchanged between the local subscribers and the Internet; they are simply using a v6-v4 path instead of a v6-v6 path. (The native ISPs do not have an incentive to provide relays for general use; they are expected to restrict access to these relays to their customers.)
最好将这些继电器定位在靠近“本机主机”的位置。在过渡期内，本地ISP有兴趣提供中继服务供其本地用户使用。他们的用户将享受更好的连通性，因此会更快乐。提供该服务不会导致额外的带宽需求：数据包在本地用户和Internet之间交换；他们只是使用v6-v4路径而不是v6-v6路径。（本地ISP没有提供通用继电器的动机；他们希望限制客户使用这些继电器。）
We should note however that different automatic tunneling techniques have different deployment conditions.
但是，我们应该注意，不同的自动隧道技术具有不同的部署条件。
In an early deployment of the Teredo service by Microsoft, the relays are provided by the native (or 6to4) hosts themselves. The native or 6to4 hosts are de-facto "multi-homed" to native and Teredo hosts, although they never publish a Teredo address in the DNS or otherwise. When a native host communicates with a Teredo host, the first packets are exchanged through the native interface and relayed by the Teredo server, while the subsequent packets are tunneled "end-to-end" over IPv4 and UDP. This enables deployment of Teredo without having to field an infrastructure of relays in the network.
在微软早期部署Teredo服务时，中继由本机（或6to4）主机自己提供。本机或6to4主机实际上是本机和Teredo主机的“多宿主”，尽管它们从不在DNS或其他方式中发布Teredo地址。当本机主机与Teredo主机通信时，第一个数据包通过本机接口交换并由Teredo服务器中继，而随后的数据包通过IPv4和UDP进行“端到端”隧道传输。这使得Teredo的部署无需在网络中部署中继基础设施。
This type of solution carries the implicit risk of developing two parallel IPv6 Internets, one native and one using Teredo: in order to communicate with a Teredo-only host, a native IPv6 host has to implement a Teredo interface. The Teredo implementations try to mitigate this risk by always preferring native paths when available, but a true mitigation requires that native hosts do not have to implement the transition technology. This requires cooperation from the IPv6 ISP, who will have to support the relays. An IPv6 ISP that really wants to isolate its customers from the Teredo technology can do that by providing native connectivity and a Teredo relay. The ISP's customers will not need to implement their own relay.
这种类型的解决方案隐含着开发两个并行IPv6 Internet的风险，一个是本机的，另一个是使用Teredo的：为了与仅Teredo主机通信，本机IPv6主机必须实现Teredo接口。Teredo实现试图通过在可用时始终优先选择本机路径来降低此风险，但真正的降低要求本机主机不必实现转换技术。这需要IPv6 ISP的合作，他们必须支持中继。如果IPv6 ISP真的想将其客户与Teredo技术隔离开来，可以通过提供本机连接和Teredo中继来实现这一点。ISP的客户不需要实现他们自己的中继。
Communication between 6to4 networks and native networks uses a different structure. There are two relays, one for each direction of communication. The native host sends its packets through the nearest 6to4 router, i.e., the closest router advertising the 2002::/16 prefix through the IPv6 routing tables; the 6to4 network sends its packet through a 6to4 relay that is either explicitly configured or
6to4网络和本机网络之间的通信使用不同的结构。有两个继电器，每个通信方向一个。本机主机通过最近的6to4路由器发送其数据包，即通过IPv6路由表发布2002:：/16前缀的最近路由器；6to4网络通过6to4中继发送其数据包，该中继可以是显式配置的，也可以是非显式配置的
discovered through the 6to4 anycast address 192.88.99.1 [6TO4ANYCAST]. The experience so far is that simple 6to4 routers are easy to deploy, but 6to4 relays are scarce. If there are too few relays, these relays will create a bottleneck. The communications between 6to4 and native networks will be slower than the direct communications between 6to4 hosts. This will create an incentive for native hosts to somehow "multi-home" to 6to4, de facto creating two parallel Internets, 6to4 and native. This risk will only be mitigated if there is a sufficient deployment of 6to4 relays.
通过6to4选播地址192.88.99.1[6to4选播]发现。到目前为止的经验是，简单的6to4路由器很容易部署，但6to4中继很少。如果继电器太少，这些继电器将造成瓶颈。6to4与本机网络之间的通信速度将低于6to4主机之间的直接通信速度。这将促使本机主机以某种方式“多家”连接到6to4，事实上创建了两个并行互联网，6to4和本机。只有在充分部署6to4继电器的情况下，才能降低此风险。
The configured tunnel solutions do not carry this type of risk.
配置的隧道解决方案不存在此类风险。
A related issue is the lifespan of the transition solutions. Since automatic tunneling technologies enable an automatic deployment, there is a risk that some hosts never migrate out of the transition. The risk is arguably less for explicit tunnels: the ISPs who provide the tunnels have an incentive to replace them with a native solution as soon as possible.
一个相关的问题是过渡解决方案的寿命。由于自动隧道技术支持自动部署，因此存在一些主机永远不会迁移出转换的风险。可以说，显性隧道的风险较小：提供隧道的ISP有动机尽快用本地解决方案取代它们。
Many implementations of automatic transition technologies incorporate an "implicit sunset" mechanism: the hosts will not configure a transition technology address if they have native connectivity; the address selection mechanisms will prefer native addresses when available. The transition technologies will stop being used eventually, when native connectivity has been deployed everywhere. However, the "implicit sunset" mechanism does not provide any hard guarantee that transition will be complete at a certain date.
许多自动转换技术的实现都包含“隐式日落”机制：如果主机具有本机连接，则不会配置转换技术地址；地址选择机制将在可用时首选本机地址。当本地连接被部署到所有地方时，过渡技术最终将停止使用。然而，“隐性日落”机制并不能提供任何硬保证，保证过渡将在某一日期完成。
Yet, the support of transition technologies has a cost for the entire network: native IPv6 ISPS have to support relays in order to provide good performance and avoid the "parallel Internet" syndrome. These costs may be acceptable during an initial deployment phase, but they can certainly not be supported for an indefinite period. The "implicit sunset" mechanisms may not be sufficient to guarantee a finite lifespan of the transition.
然而，支持过渡技术对整个网络来说是有代价的：本机IPv6 ISP必须支持中继，以提供良好的性能并避免“并行互联网”综合症。在最初部署阶段，这些费用可能是可以接受的，但在无限期内肯定无法支持。“隐式日落”机制可能不足以保证过渡的有限寿命。
During the transition, some hosts will be located behind IPv4 NATs. In order to participate in the transition, these hosts will have to use a tunneling mechanism designed to traverse NAT.
在转换期间，一些主机将位于IPv4 NAT之后。为了参与转换，这些主机必须使用设计用于穿越NAT的隧道机制。
We may ask whether NAT traversal should be a generic property of any transition technology, or whether it makes sense to develop two types of technologies, some "NAT capable" and some not. An important question is also which kinds of NAT boxes one should be able to
我们可能会问NAT遍历是否应该是任何转换技术的通用属性，或者开发两种类型的技术是否有意义，一种是“支持NAT的”，另一种是不支持NAT的。一个重要的问题是，一个人应该能够使用哪种NAT盒
traverse. One should probably also consider whether it is necessary to build an IPv6 specific NAT traversal mechanism, or whether it is possible to combine an existing IPv4 NAT traversal mechanism with some form of IPv6 in IPv4 tunneling. There are many IPv4 NAT traversal mechanisms; thus one may ask whether these need re-invention, especially when they are already complex.
穿过还应该考虑是否需要构建IPv6特定NAT穿越机制，或者是否可以将现有的IPv4 NAT穿越机制与IPv4隧道中的某种形式的IPv6相结合。IPv4 NAT穿越机制很多；因此，人们可能会问，这些技术是否需要重新发明，特别是当它们已经很复杂的时候。
A related question is whether the NAT traversal technology should use automatic tunnels or configured tunnels. We saw in the previous section that one can argue both sides of this issue. In fact, there are already deployed automatic and configured solutions, so the reality is that we will probably see both.
一个相关的问题是NAT穿越技术应该使用自动隧道还是配置隧道。我们在上一节中看到，人们可以对这个问题的两个方面进行辩论。事实上，已经部署了自动和配置的解决方案，因此现实情况是，我们可能会同时看到这两种解决方案。
NAT traversal technologies generally involve encapsulating IPv6 packets inside a transport protocol that is known to traverse NAT, such as UDP or TCP. These transport technologies require significantly more overhead than the simple tunneling over IPv4 used in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on UDP require the frequent transmission of "keep alive" packets to maintain a "mapping" in the NAT; solutions based on TCP may not require such a mechanism, but they incur the risk of "head of queue blocking", which may translate in poor performance. Given the difference in performance, it makes sense to consider two types of transition technologies, some capable of traversing NAT and some aiming at the best performance.
NAT穿越技术通常涉及将IPv6数据包封装在已知可穿越NAT的传输协议（如UDP或TCP）内。与6to4中使用的简单IPv4隧道或IPv4隧道中使用的IPv6隧道相比，这些传输技术需要更大的开销。例如，基于UDP的解决方案需要频繁传输“保持活动”数据包，以在NAT中保持“映射”；基于TCP的解决方案可能不需要这种机制，但它们会带来“队列头阻塞”的风险，这可能导致性能低下。考虑到性能的差异，考虑两种类型的过渡技术是有意义的，一些能够穿越NAT和一些目标是最好的性能。
There are many kinds of NAT on the market. Different models implement different strategies for address and port allocations, and different types of timers. It is desirable to find solutions that cover "almost all" models of NAT.
市场上有很多种NAT。不同的模型实现了不同的地址和端口分配策略，以及不同类型的计时器。人们希望找到覆盖“几乎所有”NAT模型的解决方案。
A configured tunnel solution will generally make fewer hypotheses on the behavior of the NAT than an automatic solution. The configured solutions only need to establish a connection between an internal node and a server; this communication pattern is supported by pretty much all NAT configurations. The variability will come from the type of transport protocols that the NAT supports, especially when the NAT also implements "firewall" functions. Some models will allow establishment of a single "protocol 41" tunnel, while some may prevent this type of transmission. Some models will allow UDP transmission, while other may only allow TCP, or possibly HTTP.
配置的隧道解决方案通常比自动解决方案对NAT的行为做出更少的假设。配置的解决方案只需要在内部节点和服务器之间建立连接；几乎所有NAT配置都支持这种通信模式。可变性将来自NAT支持的传输协议类型，特别是当NAT还实现“防火墙”功能时。一些模型允许建立单个“协议41”隧道，而一些模型可能阻止这种类型的传输。有些型号允许UDP传输，而另一些型号可能只允许TCP，或者HTTP。
The automatic solutions have to rely on a "lowest common denominator" that is likely to be accepted by most models of NAT. In practice, this common denominator is UDP. UDP based NAT traversal is required by many applications, e.g., networked games or voice over IP. The experience shows that most recent "home routers" are designed to support these applications. In some edge cases, the automatic solutions will require explicit configuration of a port in the home router, using the so-called "DMZ" functions; however, these functions are hard to use in an "unmanaged network" scenario.
自动解决方案必须依赖于大多数NAT模型可能接受的“最低公分母”。在实践中，这个公共分母是UDP。许多应用程序都需要基于UDP的NAT穿越，例如网络游戏或IP语音。经验表明，最新的“家庭路由器”是为支持这些应用而设计的。在某些边缘情况下，自动解决方案需要使用所谓的“DMZ”功能在家庭路由器中明确配置端口；但是，这些函数很难在“非托管网络”场景中使用。
NAT traversal is not a problem for IPv6 alone. Many IPv4 applications have developed solutions, or kludges, to enable communication across a NAT.
NAT遍历并不仅仅是IPv6的问题。许多IPv4应用程序都开发了解决方案或kludges，以支持跨NAT的通信。
Virtual Private Networks are established by installing tunnels between VPN clients and VPN servers. These tunnels are designed today to carry IPv4, but in many cases could easily carry IPv6. For example, the proposed IETF standard, L2TP, includes a PPP layer that can encapsulate IPv6 as well as IPv4. Several NAT models are explicitly designed to pass VPN traffic, and several VPN solutions have special provisions to traverse NAT. When we study the establishment of configured tunnels through NAT, it makes a lot of sense to consider existing VPN solutions.
虚拟专用网络是通过在VPN客户端和VPN服务器之间安装隧道来建立的。如今，这些隧道设计用于承载IPv4，但在许多情况下可以轻松承载IPv6。例如，提议的IETF标准L2TP包括一个PPP层，该层可以封装IPv6和IPv4。几个NAT模型被明确设计用于传递VPN流量，并且几个VPN解决方案具有穿越NAT的特殊规定。当我们研究通过NAT建立配置隧道时，考虑现有VPN解决方案有很多意义。
[STUN] is a protocol designed to facilitate the establishment of UDP associations through NAT, by letting nodes behind NAT discover their "external" address. The same function is required for automatic tunneling through NAT, and one could consider reusing the STUN specification as part of an automatic tunneling solution. However, the automatic solutions also require a mechanism of bubbles to establish the initial path through a NAT. This mechanism is not present in STUN. It is not clear that a combination of STUN and a bubble mechanism would have a technical advantage over a solution specifically designed for automatic tunneling through NAT.
[STUN]是一种协议，旨在通过NAT促进UDP关联的建立，让NAT后面的节点发现其“外部”地址。通过NAT自动隧穿需要相同的功能，并且可以考虑将STUN规范重用为自动隧道解决方案的一部分。然而，自动解决方案还需要气泡机制来建立通过NAT的初始路径。这种机制在STUN中不存在。目前尚不清楚，与专门为NAT自动隧道设计的解决方案相比，STUN和气泡机制的组合是否具有技术优势。
The previous sections make the case for the development of four transition mechanism, covering the following 4 configurations:
前面几节介绍了四种过渡机制的开发，包括以下四种配置：
- Configured tunnel over IPv4 in the absence of NAT; - Automatic tunnel over IPv4 in the absence of NAT; - Configured tunnel across a NAT; - Automatic tunnel across a NAT.
- 在没有NAT的情况下通过IPv4配置的隧道；-没有NAT时IPv4上的自动隧道；-跨NAT配置的隧道；-穿越NAT的自动隧道。
Teredo is an example of an already designed solution for automatic tunnels across a NAT; 6to4 is an example of a solution for automatic tunnels over IPv4 in the absence of NAT.
Teredo是一个已经设计好的NAT自动隧道解决方案的例子；6to4是在没有NAT的情况下通过IPv4进行自动隧道的解决方案的一个示例。
All solutions should be designed to meet generic requirements such as security, scalability, support for reverse name lookup, or simple management. In particular, automatic tunneling solutions may need to be augmented with a special purpose reverse DNS lookup mechanism, while configured tunnel solutions would benefit from an automatic service configuration mechanism.
所有解决方案的设计都应满足一般要求，如安全性、可扩展性、支持反向名称查找或简单管理。特别是，自动隧道解决方案可能需要增加一个特殊用途的反向DNS查找机制，而配置的隧道解决方案将受益于自动服务配置机制。
In case A, isolated hosts need to acquire some form of connectivity. In this section, we first evaluate how mechanisms already defined or being worked on in the IETF meet this requirement. We then consider the "remaining holes" and recommend specific developments.
在案例A中，隔离主机需要获得某种形式的连接。在本节中，我们首先评估IETF中已经定义或正在使用的机制如何满足这一要求。然后我们考虑“剩余的洞”，并建议具体的发展。
In case A, IPv6 capable hosts seek IPv6 connectivity in order to communicate with applications in the global IPv6 Internet. The connectivity requirement can be met using either configured tunnels or automatic tunnels.
在情况A中，支持IPv6的主机寻求IPv6连接，以便与全球IPv6 Internet中的应用程序通信。可使用配置隧道或自动隧道满足连接要求。
If the host is located behind a NAT, the tunneling technology should be designed to traverse NAT; tunneling technologies that do not support NAT traversal can obviously be used if the host is not located behind a NAT.
如果主机位于NAT后面，则隧道技术应设计为穿越NAT；如果主机不位于NAT后面，显然可以使用不支持NAT遍历的隧道技术。
When the local ISP is willing to provide a configured tunnel solution, we should make it easy for the host in case A to use it. The requirements for such a service will be presented in another document.
当本地ISP愿意提供一个配置好的隧道解决方案时，我们应该使主机易于使用它。此类服务的要求将在另一份文件中提出。
An automatic solution like Teredo appears to be a good fit for providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 deployment. The service is designed for minimizing the cost of deploying the server, which matches the requirement of minimizing the cost of the "supporting infrastructure".
在部署IPv6的情况下，Teredo这样的自动解决方案似乎非常适合为NAT后面的主机提供IPv6连接。该服务旨在最大限度地降低部署服务器的成本，这符合最小化“支持基础设施”成本的要求。
A characteristic of case A is that an isolated host acquires global IPv6 connectivity, using either Teredo or an alternative tunneling mechanism. If no precaution is taken, there is a risk of exposing to the global Internet some applications and services that are only expected to serve local hosts, e.g., those located behind the NAT
案例A的一个特点是，隔离主机使用Teredo或其他隧道机制获取全局IPv6连接。如果不采取预防措施，则存在向全球互联网公开某些仅预期服务于本地主机的应用程序和服务的风险，例如位于NAT后面的应用程序和服务
when a NAT is present. Developers and administrators should make sure that the global IPv6 connectivity is restricted to only those applications that are expressly designed for global Internet connectivity. The users should be able to configure which applications get IPv6 connectivity to the Internet and which should not.
当NAT出现时。开发人员和管理员应确保全球IPv6连接仅限于专门为全球互联网连接设计的应用程序。用户应该能够配置哪些应用程序可以连接到Internet，哪些应用程序不能连接到Internet。
Any solution to the NAT traversal problem is likely to involve relays. There are concerns that improperly designed protocols or improperly managed relays could open new avenues for attacks against Internet services. This issue should be addressed and mitigated in the design of the NAT traversal protocols and in the deployment guides for relays.
NAT穿越问题的任何解决方案都可能涉及中继。有人担心，设计不当的协议或管理不当的中继可能会为针对互联网服务的攻击开辟新的途径。这个问题应该在NAT穿越协议的设计和中继部署指南中加以解决和缓解。
In case B, we assume that the gateway and the ISP are both dual-stack. The hosts on the local network may be IPv4-only, dual-stack, or IPv6-only. The main requirements are: prefix delegation and name resolution. We also study the potential need for communication between IPv4 and IPv6 hosts, and conclude that a dual-stack approach is preferable.
在案例B中，我们假设网关和ISP都是双栈。本地网络上的主机可以是仅IPv4、双栈或仅IPv6。主要要求是：前缀委派和名称解析。我们还研究了IPv4和IPv6主机之间通信的潜在需求，并得出结论，双堆栈方法更可取。
The gateway must be able to acquire an IPv6 prefix, delegated by the ISP. This can be done through explicit prefix delegation (e.g., [DHCPV6, PREFIXDHCPV6]), or if the ISP is advertising a /64 prefix on the link, such a link can be extended by the use of an ND proxy or a bridge.
网关必须能够获取由ISP授权的IPv6前缀。这可以通过显式前缀委托（例如，[DHCPV6，PREFIXDHCPV6]）实现，或者如果ISP在链路上公布/64前缀，则可以通过使用ND代理或网桥来扩展这样的链路。
An ND proxy can also be used to extend a /64 prefix to multiple physical links of different properties (e.g., an Ethernet and a PPP link).
ND代理还可用于将/64前缀扩展到具有不同属性的多个物理链路（例如，以太网和PPP链路）。
A /64 subnet can be extended to span multiple physical links using a bridge or ND proxy. Bridges can be used when bridging multiple similar media (mainly, Ethernet segments). On the other hand, an ND proxy must be used if a /64 prefix has to be shared across media (e.g., an upstream PPP link and a downstream Ethernet), or if an interface cannot be put into promiscuous mode (e.g., an upstream wireless link).
可以使用网桥或ND代理将A/64子网扩展为跨多个物理链路。桥接多个类似介质（主要是以太网段）时，可以使用桥接器。另一方面，如果必须在媒体上共享/64前缀（例如，上游PPP链路和下游以太网），或者如果接口不能进入混杂模式（例如，上游无线链路），则必须使用ND代理。
Extending a single subnet to span from the ISP to all of the unmanaged network is not recommended, and prefix delegation should be used when available. However, sometimes it is unavoidable. In
不建议将单个子网从ISP扩展到所有非托管网络，如果可用，则应使用前缀委派。然而，有时这是不可避免的。在里面
addition, sometimes it's necessary to extend a subnet in the unmanaged network, at the "customer-side" of the gateway, and changing the topology using routing might require too much expertise.
此外，有时有必要在网关的“客户端”扩展非托管网络中的子网，并且使用路由更改拓扑可能需要太多的专业知识。
The ND proxy method results in the sharing of the same prefix over several links, a procedure generally known as "multi-link subnet". This sharing has effects on neighbor discovery protocols, and possibly also on other protocols such as LLMNR [LLMNR] that rely on "link local multicast". These effects need to be carefully studied.
ND代理方法导致在多个链路上共享相同的前缀，这一过程通常称为“多链路子网”。这种共享会影响邻居发现协议，也可能会影响依赖于“链路本地多播”的其他协议，如LLMNR[LLMNR]。这些影响需要仔细研究。
Several networks have already started using an explicit prefix delegation mechanism using DHCPv6. In this mechanism, the gateway uses a DHCP request to obtain an adequate prefix from a DHCP server managed by the Internet Service Provider. The DHCP request is expected to carry proper identification of the gateway, which enables the ISP to implement prefix delegation policies. It is expected that the ISP assigns a /48 to the customer. The gateway should automatically assign /64s out of this /48 to its internal links.
一些网络已经开始使用DHCPv6使用显式前缀委派机制。在这种机制中，网关使用DHCP请求从由Internet服务提供商管理的DHCP服务器获取适当的前缀。DHCP请求应带有网关的正确标识，这使ISP能够实施前缀委派策略。预计ISP会将a/48分配给客户。网关应自动将/48中的/64分配给其内部链路。
DHCP is insecure unless authentication is used. This may be a particular problem if the link between gateway and ISP is shared by multiple subscribers. DHCP specification includes authentication options, but the operational procedures for managing the keys and methods for sharing the required information between the customer and the ISP are unclear. To be secure in such an environment in practice, the practical details of managing the DHCP authentication need to be analyzed.
除非使用身份验证，否则DHCP是不安全的。如果网关和ISP之间的链路由多个订户共享，这可能是一个特殊的问题。DHCP规范包括身份验证选项，但管理密钥的操作程序以及在客户和ISP之间共享所需信息的方法尚不清楚。为了在实际中在这样的环境中保持安全，需要分析管理DHCP身份验证的实际细节。
The ND proxy and DHCP methods appear to have complementary domains of application. ND proxy is a simple method that corresponds well to the "informal sharing" of a link, while explicit delegation provides strong administrative control. Both methods require development: specify the interaction with neighbor discovery for ND proxy; provide security guidelines for explicit delegation.
ND代理和DHCP方法似乎具有互补的应用领域。ND proxy是一种简单的方法，它很好地对应于链接的“非正式共享”，而显式委托提供了强大的管理控制。这两种方法都需要开发：为ND代理指定与邻居发现的交互；为明确授权提供安全指南。
During the transition phase from IPv4 to IPv6, there will be IPv4- only, dual-stack, and IPv6-only nodes. In theory, there may be a need to provide some interconnection services so that IPv4-only and IPv6-only hosts can communicate. However, it is hard to develop a translation service that does not have unwanted side effects on the efficiency or the security of communications. As a consequence, the authors recommend that, if a device requires communication with
在从IPv4到IPv6的过渡阶段，将有仅IPv4、双栈和仅IPv6的节点。理论上，可能需要提供一些互连服务，以便仅IPv4和仅IPv6主机可以通信。然而，很难开发出一种对通信的效率或安全没有不必要的副作用的翻译服务。因此，作者建议，如果设备需要与
IPv4-only hosts, this device implements an IPv4 stack. The only devices that should have IPv6-only connectivity are those that are intended to only communicate with IPv6 hosts.
仅IPv4主机，此设备实现IPv4堆栈。唯一应该具有仅IPv6连接的设备是那些仅用于与IPv6主机通信的设备。
There are three types of name resolution services that should be provided in case B: local IPv6 capable hosts must be able to obtain the IPv6 addresses of correspondent hosts on the Internet, they should be able to publish their address if they want to be accessed from the Internet, and they should be able to obtain the IPv6 address of other local IPv6 hosts. These three problems are described in the next sections. Operational considerations and issues with IPv6 DNS are analyzed in [DNSOPV6].
案例B中应提供三种类型的名称解析服务：支持IPv6的本地主机必须能够获取Internet上对应主机的IPv6地址，如果希望从Internet访问，则应能够发布其地址，他们应该能够获得其他本地IPv6主机的IPv6地址。这三个问题将在下一节中描述。[DNSOPV6]中分析了IPv6 DNS的操作注意事项和问题。
In an unmanaged environment, IPv4 hosts usually obtain the address of the local DNS resolver through DHCPv4; the DHCPv4 service is generally provided by the gateway. The gateway will also use DHCPv4 to obtain the address of a suitable resolver from the local Internet service provider.
在非托管环境中，IPv4主机通常通过DHCPv4获取本地DNS解析程序的地址；DHCPv4服务通常由网关提供。网关还将使用DHCPv4从本地互联网服务提供商处获取合适的解析器地址。
The DHCPv4 solution will suffice in practice for the gateway and also for the dual-stack hosts. There is evidence that DNS servers accessed over IPv4 can serve arbitrary DNS records, including AAAA records.
DHCPv4解决方案在实践中可以满足网关和双堆栈主机的需要。有证据表明，通过IPv4访问的DNS服务器可以服务于任意DNS记录，包括AAAA记录。
Just using DHCPv4 will not be an adequate solution for IPv6-only local hosts. The DHCP working group has defined how to use (stateless) DHCPv6 to obtain the address of the DNS server [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked at in the DNSOP Working Group.
对于仅限IPv6的本地主机，仅使用DHCPv4并不是一个合适的解决方案。DHCP工作组定义了如何使用（无状态）DHCPv6来获取DNS服务器的地址[DNSDHCPV6]。DNSOP工作组正在研究DHCPv6和其他几种可能性。
IPv6 capable hosts may be willing to provide services accessible from the global Internet. They will thus need to publish their address in a server that is publicly available. IPv4 hosts in unmanaged networks have a similar problem today, which they solve using one of three possible solutions:
支持IPv6的主机可能愿意提供可从全球互联网访问的服务。因此，他们需要在一个公开的服务器上发布他们的地址。如今，非托管网络中的IPv4主机也有类似的问题，它们使用以下三种可能的解决方案之一来解决：
* Manual configuration of a stable address in a DNS server; * Dynamic configuration using the standard dynamic DNS protocol; * Dynamic configuration using an ad hoc protocol.
* DNS服务器中稳定地址的手动配置；*使用标准动态DNS协议进行动态配置；*使用自组织协议进行动态配置。
Manual configuration of stable addresses is not satisfactory in an unmanaged IPv6 network: the prefix allocated to the gateway may or may not be stable, and in any case, copying long hexadecimal strings through a manual procedure is error prone.
在非托管IPv6网络中，手动配置稳定地址并不令人满意：分配给网关的前缀可能稳定，也可能不稳定，而且在任何情况下，通过手动过程复制长十六进制字符串都容易出错。
Dynamic configuration using the same type of ad hoc protocols that are common today is indeed possible, but the IETF should encourage the use of standard solutions based on Dynamic DNS (DDNS).
使用当今常见的相同类型的自组织协议进行动态配置确实是可能的，但IETF应鼓励使用基于动态DNS（DDN）的标准解决方案。
There are two possible ways of resolving the IPv6 addresses of local hosts: one may either publish the IPv6 addresses in a DNS server for the local domain, or one may use a peer-to-peer address resolution protocol such as LLMNR.
解析本地主机的IPv6地址有两种可能的方法：一种可以在本地域的DNS服务器中发布IPv6地址，另一种可以使用对等地址解析协议（如LLMNR）。
When a DNS server is used, this server could in theory be located anywhere on the Internet. There is however a very strong argument for using a local server, which will remain reachable even if the network connectivity is down.
当使用DNS服务器时，理论上该服务器可以位于Internet上的任何位置。然而，有一个非常有力的理由支持使用本地服务器，即使网络连接中断，本地服务器仍然可以访问。
The use of a local server requires that IPv6 capable hosts discover this server, as explained in 4.3.1, and then that they use a protocol such as DDNS to publish their IPv6 addresses to this server. In practice, the DNS address discovered in 4.3.1 will often be the address of the gateway itself, and the local server will thus be the gateway.
使用本地服务器要求支持IPv6的主机发现此服务器，如4.3.1所述，然后使用DDNS等协议将其IPv6地址发布到此服务器。实际上，在4.3.1中发现的DNS地址通常是网关本身的地址，因此本地服务器将是网关。
An alternative to using a local server is LLMNR, which uses a multicast mechanism to resolve DNS requests. LLMNR does not require any service from the gateway, and also does not require that hosts use DDNS. An important problem is that some networks only have limited support for multicast transmission, for example, multicast transmission on 802.11 network is error prone. However, unmanaged networks also use multicast for neighbor discovery [NEIGHBOR]; the requirements of ND and LLMNR are similar; if a link technology supports use of ND, it can also enable use of LLMNR.
使用本地服务器的替代方案是LLMNR，它使用多播机制来解析DNS请求。LLMNR不需要来自网关的任何服务，也不要求主机使用DDN。一个重要的问题是，一些网络对多播传输的支持有限，例如，802.11网络上的多播传输容易出错。然而，非托管网络也使用多播进行邻居发现[邻居]；ND和LLMNR的要求相似；如果链路技术支持ND的使用，它还可以启用LLMNR的使用。
The IETF should quickly provide a recommended procedure for provisioning the DNS resolver in IPv6-only hosts.
IETF应快速提供建议的程序，用于在仅IPv6主机中配置DNS解析器。
The most plausible candidate for local name resolution appears to be LLMNR; the IETF should quickly proceed to the standardization of that protocol.
本地名称解析最有可能的候选者似乎是LLMNR；IETF应迅速着手该协议的标准化。
The case B solutions provide global IPv6 connectivity to the local hosts. Removing the limit to connectivity imposed by NAT is both a feature and a risk. Implementations should carefully limit global IPv6 connectivity to only those applications that are specifically designed to operate on the global Internet. Local applications, for example, could be restricted to only use link-local addresses, or addresses whose most significant bits match the prefix of the local subnet, e.g., a prefix advertised as "on link" in a local router advertisement. There is a debate as to whether such restrictions should be "per-site" or "per-link", but this is not a serious issue when an unmanaged network is composed of a single link.
案例B解决方案提供到本地主机的全局IPv6连接。取消NAT对连接的限制既是一个特性也是一个风险。实施应谨慎地将全局IPv6连接限制为仅限于那些专门设计用于在全球互联网上运行的应用程序。例如，本地应用程序可被限制为仅使用链路本地地址，或其最高有效位匹配本地子网前缀的地址，例如，在本地路由器广告中广告为“在链路上”的前缀。关于这种限制应该是“每个站点”还是“每个链接”存在争议，但当非托管网络由单个链接组成时，这不是一个严重的问题。
Case C is very similar to case B, the difference being that the ISP is not dual-stack. The gateway must thus use some form of tunneling mechanism to obtain IPv6 connectivity, and an address prefix.
案例C与案例B非常相似，不同之处在于ISP不是双栈。因此，网关必须使用某种形式的隧道机制来获得IPv6连接和地址前缀。
A simplified form of case B is a single host with a global IPv4 address, i.e., with a direct connection to the IPv4 Internet. This host will be able to use the same tunneling mechanisms as a gateway.
案例B的简化形式是具有全局IPv4地址的单个主机，即直接连接到IPv4 Internet。此主机将能够使用与网关相同的隧道机制。
Connectivity in case C requires some form of tunneling of IPv6 over IPv4. The various tunneling solutions are discussed in section 2.
案例C中的连接需要某种形式的IPv4上IPv6的隧道。第2节讨论了各种隧道解决方案。
The requirements of case C can be solved by an automatic tunneling mechanism such as 6to4 [6TO4]. An alternative may be the use of a configured tunnels mechanism [TUNNELS], but as the local ISP is not IPv6-enabled, this may not be feasible. The practical conclusion of our analysis is that "upgraded gateways" will probably support the 6to4 technology, and will have an optional configuration option for "configured tunnels".
案例C的要求可以通过自动隧道机制（如6to4[6to4]）来解决。另一种选择可能是使用已配置的隧道机制[隧道]，但由于本地ISP未启用IPv6，这可能不可行。我们的分析得出的实际结论是，“升级网关”可能支持6to4技术，并且将为“配置隧道”提供可选配置选项。
The tunnel broker technology should be augmented to include support for some form of automatic configuration.
隧道代理技术应该得到扩展，以包括对某种形式的自动配置的支持。
Due to concerns with potential overload of public 6to4 relays, the 6to4 implementations should include a configuration option that allows the user to take advantage of specific relays.
由于担心公共6to4继电器可能过载，6to4实施应包括允许用户利用特定继电器的配置选项。
In case D, the ISP only provides IPv6 services.
在案例D中，ISP仅提供IPv6服务。
We expect IPv6 addressing in case D to proceed similarly to case B, i.e., use either an ND proxy or explicit prefix delegation through DHCPv6 to provision an IPv6 prefix on the gateway.
我们希望情况D中的IPv6寻址与情况B类似，即通过DHCPv6使用ND代理或显式前缀委托在网关上提供IPv6前缀。
Local IPv4 capable hosts may still want to access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. There are no standardized solutions and the IETF has devoted very little effort to this issue, although there is ongoing work with [DSTM] and [TSP]. A solution needs to be standardized. The standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers.
支持IPv4的本地主机可能仍希望访问仅IPv4的服务。对于非托管网络中的双堆栈节点，正确的方法是开发一种形式的“IPv4 over IPv6”隧道。虽然[DSTM]和[TSP]正在进行工作，但没有标准化的解决方案，IETF对此问题投入的精力很少。解决方案需要标准化。标准化必须涵盖配置问题，即如何为支持IPv4的主机提供本地IPv4隧道服务器的地址。
Naming requirements are similar to case B, with one difference: the gateway cannot expect to use DHCPv4 to obtain the address of the DNS resolver recommended by the ISP.
命名要求与案例B类似，但有一个区别：网关不能期望使用DHCPv4获取ISP推荐的DNS解析程序的地址。
After a careful analysis of the possible solutions, we can list a set of recommendations for the V6OPS working group:
在仔细分析可能的解决方案后，我们可以为V6OPS工作组列出一组建议：
1. To meet case A and case C requirements, we need to develop, or continue to develop, four types of tunneling technologies: automatic tunnels without NAT traversal such as [6TO4], automatic tunnels with NAT traversal such as [TEREDO], configured tunnels without NAT traversal such as [TUNNELS, TSP], and configured tunnels with NAT traversal.
1. 为了满足案例A和案例C的要求，我们需要开发或继续开发四种类型的隧道技术：无NAT穿越的自动隧道，如[6TO4]，有NAT穿越的自动隧道，如[TEREDO]，无NAT穿越的配置隧道，如[tunnels，TSP]，以及有NAT穿越的配置隧道。
2. To facilitate the use of configured tunnels, we need a standardized way for hosts or gateways to discover the tunnel server or tunnel broker that may have been configured by the local ISP.
2. 为了便于使用已配置的隧道，我们需要一种标准化的方法，让主机或网关发现可能已由本地ISP配置的隧道服务器或隧道代理。
3. To meet case B "informal prefix sharing" requirements, we would need a standardized way to perform "ND proxy", possibly as part of a "multi-link subnet" specification. (The explicit prefix delegation can be accomplished through [PREFIXDHCPV6].)
3. 为了满足案例B“非正式前缀共享”的要求，我们需要一种执行“ND代理”的标准化方法，可能作为“多链路子网”规范的一部分。（显式前缀委托可以通过[PREFIXDHCPV6]完成。）
4. To meet case B naming requirements, we need to proceed with the standardization of LLMNR. (The provisioning of DNS parameters can be accomplished through [DNSDHCPV6].)
4. 为了满足案例B命名要求，我们需要继续进行LLMNR的标准化。（DNS参数的设置可通过[DNSDHCPV6]完成。）
5. To meet case D IPv4 connectivity requirement, we need to standardize an IPv4 over IPv6 tunneling mechanism, as well as the associated configuration services.
5. 为了满足案例D IPv4连接要求，我们需要标准化IPv4 over IPv6隧道机制以及相关的配置服务。
This memo describes the general requirements for transition mechanisms. Specific security issues should be studied and addressed during the development of the specific mechanisms.
本备忘录描述了过渡机制的一般要求。在制定具体机制的过程中，应研究和解决具体的安全问题。
When hosts which have been behind a NAT are exposed to IPv6, the security assumptions may change radically. This is mentioned in sections 3.2 and 4.4. One way to cope with that is to have a default firewall with a NAT-like access configuration; however, any such firewall configuration should allow for easy authorization of those applications that actually need global connectivity. One might also restrict applications which can benefit from global IPv6 connectivity on the nodes.
当NAT后面的主机暴露于IPv6时，安全性假设可能会发生根本性的变化。第3.2节和第4.4节中提到了这一点。解决这个问题的一种方法是使用一个默认的防火墙，它具有类似NAT的访问配置；但是，任何这样的防火墙配置都应该允许对实际需要全局连接的应用程序进行轻松授权。还可以限制可以从节点上的全局IPv6连接中获益的应用程序。
Security policies should be consistent between IPv4 and IPv6. A policy which prevents use of v6 while allowing v4 will discourage migration to v6 without significantly improving security. Developers and administrators should make sure that global Internet connectivity through either IPv4 or IPv6 is restricted to only those applications that are expressly designed for global Internet connectivity.
IPv4和IPv6之间的安全策略应一致。在允许v4的同时阻止使用v6的策略将阻止迁移到v6而不会显著提高安全性。开发人员和管理员应确保通过IPv4或IPv6的全局Internet连接仅限于那些专门为全局Internet连接设计的应用程序。
Several transition technologies require relays. There are concerns that improperly designed protocols or improperly managed relays could open new avenues for attacks against Internet services. This issue should be addressed and mitigated in the design of the transition technologies and in the deployment guides for relays.
一些过渡技术需要继电器。有人担心，设计不当的协议或管理不当的中继可能会为针对互联网服务的攻击开辟新的途径。应在过渡技术设计和继电器部署指南中解决和缓解该问题。
This memo has benefited from the comments of Margaret Wasserman, Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms, Bill Sommerfeld, and Fred Templin. Tim Chown provided a lot of the analysis for the tunneling requirements work.
这份备忘录得益于玛格丽特·瓦瑟曼、佩卡·萨沃拉、奇拉尤·帕特尔、托尼·海恩、马克·布兰切特、拉尔夫·德罗姆斯、比尔·索末菲尔德和弗雷德·坦普林的评论。Tim Chown为隧道需求工作提供了大量分析。
[UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004.
[UNMANREQ]Huitema，C.，Austein，R.，Satapati，S.，和R.van der Pol，“非托管网络IPv6过渡场景”，RFC 37502004年4月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[邻居]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 246112998年12月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6TO4]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[6TO4ANYCAST]Huitema，C.，“6to4中继路由器的选播前缀”，RFC 3068，2001年6月。
[TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[隧道]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPV6]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPV6）”，RFC 33151003年7月。
[DNSDHCPV6] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[DNSDHCPV6]Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 36462003年12月。
[PREFIXDHCPV6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[PREFIXDHCPV6]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[STUN]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational Considerations and Issues with IPv6 DNS", Work in Progress.
[DNSOPV6]Durand，A.，Ihren，J.，和P.Savola。“IPv6 DNS的操作注意事项和问题”，正在进行中。
[LLMNR] Esibov, L., Aboba, B., and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", Work in Progress.
[LLMNR]Esibov，L.，Aboba，B.，和D.Thaler，“链接本地多播名称解析（LLMNR）”，工作正在进行中。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", Work in Progress.
[TSP]Blanchet，M.，“具有隧道设置协议（TSP）的IPv6隧道代理”，正在进行中。
[DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in Progress.
[DSTM]Bound，J.，“双堆栈转换机制”，正在进行中。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
[TEREDO]Huitema，C.，“TEREDO：通过NAT通过UDP传输IPv6”，工作正在进行中。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Rob Austein互联网系统联合会950 Charter Street Redwood City，加利福尼亚州94063
EMail: sra@isc.org
EMail: sra@isc.org
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 USA
Suresh Satapati思科系统公司，美国加利福尼亚州圣何塞95134
EMail: satapati@cisco.com
EMail: satapati@cisco.com
Ronald van der Pol NLnet Labs Kruislaan 419 1098 VA Amsterdam NL
罗纳德·范德波尔NLnet实验室Kruislaan 419 1098弗吉尼亚州阿姆斯特丹NL
EMail: Ronald.vanderPol@nlnetlabs.nl
EMail: Ronald.vanderPol@nlnetlabs.nl
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。