Independent Submission S. Steffann
Request for Comments: 7059 S.J.M. Steffann Consultancy
Category: Informational I. van Beijnum
ISSN: 2070-1721 Institute IMDEA Networks
R. van Rein
OpenFortress
November 2013
Independent Submission S. Steffann
Request for Comments: 7059 S.J.M. Steffann Consultancy
Category: Informational I. van Beijnum
ISSN: 2070-1721 Institute IMDEA Networks
R. van Rein
OpenFortress
November 2013
A Comparison of IPv6-over-IPv4 Tunnel Mechanisms
IPv6-over-IPv4隧道机制的比较
Abstract
摘要
This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.
本文档概述了通过IPv4网络隧道IPv6数据包的各种方法。它涵盖了当前使用的机制，涉及了目前仅具有历史意义的几种机制，并讨论了一些在出版时未广泛使用的较新隧道机制。本文档的目标是帮助需要IPv6-in-IPv4隧道的用户选择可能适用于他们的机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7059.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7059.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 7
3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 8
3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 9
3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 10
3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 10
3.5.1. 6to4 Provider Managed Tunnels . . . . . . . . . . . . 11
3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 12
3.7. Intra-Site Automatic Tunnel Addressing (ISATAP) . . . . . 13
3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 14
3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 15
3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 16
3.11. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 16
3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 18
3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 19
4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 20
4.2. SixXS Heartbeat Protocol . . . . . . . . . . . . . . . . . 20
4.3. Tunnel Information and Control Protocol (TIC) . . . . . . 21
5. Common Aspects . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Protocol 41 Encapsulation . . . . . . . . . . . . . . . . 22
5.2. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 22
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 24
5.4. IPv4 Addresses Embedded in IPv6 Addresses . . . . . . . . 25
6. Evaluation of Tunnel Mechanisms . . . . . . . . . . . . . . . 28
6.1. Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 28
6.2. Supported Network Topologies . . . . . . . . . . . . . . . 29
6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Gateway State . . . . . . . . . . . . . . . . . . . . . . 32
6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10. Informative References . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Evaluation Criteria . . . . . . . . . . . . . . . . . 40
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 7
3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 8
3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 9
3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 10
3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 10
3.5.1. 6to4 Provider Managed Tunnels . . . . . . . . . . . . 11
3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 12
3.7. Intra-Site Automatic Tunnel Addressing (ISATAP) . . . . . 13
3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 14
3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 15
3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 16
3.11. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 16
3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 18
3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 19
4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 20
4.2. SixXS Heartbeat Protocol . . . . . . . . . . . . . . . . . 20
4.3. Tunnel Information and Control Protocol (TIC) . . . . . . 21
5. Common Aspects . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Protocol 41 Encapsulation . . . . . . . . . . . . . . . . 22
5.2. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 22
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 24
5.4. IPv4 Addresses Embedded in IPv6 Addresses . . . . . . . . 25
6. Evaluation of Tunnel Mechanisms . . . . . . . . . . . . . . . 28
6.1. Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 28
6.2. Supported Network Topologies . . . . . . . . . . . . . . . 29
6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Gateway State . . . . . . . . . . . . . . . . . . . . . . 32
6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10. Informative References . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Evaluation Criteria . . . . . . . . . . . . . . . . . 40
During the transition from IPv4 to IPv6, IPv6 islands are separated by a sea of IPv4. Tunnels provide connectivity between these IPv6 islands. Tunnels work by encapsulating IPv6 packets inside IPv4 packets, as shown in the figure.
在从IPv4过渡到IPv6的过程中，IPv6岛被IPv4的海洋隔开。隧道提供这些IPv6岛之间的连接。隧道通过将IPv6数据包封装在IPv4数据包中来工作，如图所示。
+---------------+
| IPv4 |
| Header |
+---------------+
: Optional :
: Encapsulation :
: Header :
+---------------+ +---------------+
| IPv6 | | IPv6 |
| Header | | Header |
+---------------+ +---------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+---------------+ +---------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+---------------+ +---------------+
+---------------+
| IPv4 |
| Header |
+---------------+
: Optional :
: Encapsulation :
: Header :
+---------------+ +---------------+
| IPv6 | | IPv6 |
| Header | | Header |
+---------------+ +---------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+---------------+ +---------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+---------------+ +---------------+
Encapsulating IPv6 in IPv4
在IPv4中封装IPv6
Various tunnel mechanisms have been proposed over time. So many, in fact, that it is difficult to get an overview. Some tunnel mechanisms have been abandoned by the community, others have known problems, and yet others have shown to be reliable. Some tunnel mechanisms were designed with a particular use case in mind; others are generic. There may be documented limitations as well as limitations that have cropped up in deployment.
随着时间的推移，人们提出了各种隧道机制。事实上，数量如此之多，很难得到一个概览。一些隧道机制已经被社区抛弃，其他一些已经知道存在问题，还有一些已经证明是可靠的。一些隧道机制的设计考虑了特定的用例；其他是通用的。可能存在文档化的限制，也可能存在部署中突然出现的限制。
This document provides an overview of available and/or noteworthy tunnel mechanisms, with the intention to guide selection of the best mechanism for a particular purpose. As such, the discussion of the different tunnel mechanisms is limited to the working principles of the different mechanisms and a few important details.
本文件概述了可用和/或值得注意的隧道机制，旨在指导为特定目的选择最佳机制。因此，对不同隧道机制的讨论仅限于不同机制的工作原理和一些重要细节。
Please use the references to learn the full details of each mechanism. For brevity, only the most relevant documents are referenced. Refer to these for additional specifications, updates, and links to older versions of protocol specifications, as well as links to more general background information.
请使用参考资料了解每个机制的全部细节。为简洁起见，仅引用最相关的文档。有关其他规范、更新、协议规范旧版本的链接以及更多一般背景信息的链接，请参阅这些。
The intended audience for this document is everyone who needs a connection to the IPv6 Internet at large, but is not in the position to use native (untunneled) IPv6 connectivity, and thus needs to select an appropriate tunnel mechanism. However, when native IPv6 connectivity is available, this should be preferred over tunneled connectivity as per rule 7 in Section 6 of [RFC6724]. This document is also intended as a quick reference to tunnel mechanisms for the IETF community.
本文档的目标受众是所有需要连接到IPv6 Internet，但不能使用本机（未启用）IPv6连接的人，因此需要选择适当的隧道机制。但是，当本机IPv6连接可用时，根据[RFC6724]第6节中的规则7，应首选本机IPv6连接而不是隧道连接。本文件还旨在作为IETF社区隧道机制的快速参考。
The scope of this document is limited to tunnel mechanisms for providing IPv6 connectivity over an IPv4 infrastructure. Mechanisms for Virtual Private Networks (VPNs) and security architectures such as IPsec [RFC4301], as well as IPv4-over-IPv6 tunneling, are out of scope for this document as they serve a different purpose, even if they could technically be used to provide IPv6 connectivity.
本文档的范围仅限于通过IPv4基础设施提供IPv6连接的隧道机制。虚拟专用网络（VPN）和安全体系结构（如IPsec[RFC4301]）以及IPv4-over-IPv6隧道的机制不在本文档的范围内，因为它们具有不同的用途，即使它们在技术上可用于提供IPv6连接。
Anycast: Mechanism to provide a service, in multiple locations and/or using multiple servers, by configuring each server with the same IP address.
Anycast：在多个位置和/或使用多个服务器，通过将每个服务器配置为相同的IP地址来提供服务的机制。
Carrier-Grade NAT (CGN): A Network Address Translation (see NAT) device used by an ISP so multiple subscribers can be served using a single IPv4 address.
运营商级NAT（CGN）：ISP使用的网络地址转换（见NAT）设备，因此可以使用单个IPv4地址为多个订户提供服务。
Dual stack: Also known as "dual IP layer". Nodes run IPv4 and IPv6 side by side, and can communicate with other dual stack nodes (using IPv4 or IPv6), as well as IPv4-only nodes (using IPv4) and IPv6-only nodes (using IPv6). Most current operating systems are set up to use IPv4 when available as well as use IPv6 when available, allowing them to run in IPv4-only, IPv6-only, or dual stack mode as circumstances permit. Except for a few things concerning the Domain Name System (DNS), there is no separate specification for dual stack beyond the specifications relevant to running IPv4 and IPv6. Dual stack is one of the three IPv4-to-IPv6 transition tools; the others are translation and tunnels.
双栈：也称为“双IP层”。节点并行运行IPv4和IPv6，并且可以与其他双堆栈节点（使用IPv4或IPv6）以及仅IPv4节点（使用IPv4）和仅IPv6节点（使用IPv6）通信。大多数当前的操作系统都设置为在可用时使用IPv4，也在可用时使用IPv6，允许它们在情况允许时以仅IPv4、仅IPv6或双堆栈模式运行。除了与域名系统（DNS）有关的一些事项外，除了与运行IPv4和IPv6相关的规范外，没有针对双堆栈的单独规范。双栈是三种IPv4到IPv6转换工具之一；其他的是翻译和隧道。
Encapsulation: Transporting a packet as data inside another packet. For instance, an IPv6 packet inside an IPv4 packet.
封装：将一个包作为数据传输到另一个包中。例如，IPv4数据包中的IPv6数据包。
Firewall: A device that selectively filters IP packets, allowing some protocols through but not others. A firewall may act as a switch, operating below the IP layer, or as a router.
防火墙：一种选择性过滤IP数据包的设备，允许某些协议通过，但不允许其他协议通过。防火墙可以作为交换机，在IP层下运行，也可以作为路由器。
Host: A device that communicates using the Internet Protocol and only transmits packets from its own address.
主机：使用互联网协议进行通信的设备，仅从其自身地址传输数据包。
ISP: Internet Service Provider; the party connecting the outside of the local network's perimeter to the public Internet.
ISP：互联网服务提供商；将本地网络外围连接到公共互联网的一方。
MTU: Maximum Transmission Unit, the maximum size of a packet that can be transmitted over a link (or tunnel) without splitting it into multiple fragments.
MTU：最大传输单位，在链路（或隧道）上传输的数据包的最大大小，无需将其拆分为多个片段。
NAT: Network Address Translation or Network Address Translator. NAT makes it possible for a number of hosts to share a single IP address. TCP and UDP port numbers are used to distinguish the traffic to/from different hosts served by the NAT; protocols other than TCP and UDP may be incompatible with NAT due to lack of port numbers. NAT also breaks protocols that depend on the IP addresses used in some way. Typically, NAT devices behave as a host towards the public Internet, and as a router towards the internal network.
NAT：网络地址转换或网络地址转换器。NAT使许多主机可以共享一个IP地址。TCP和UDP端口号用于区分NAT服务的不同主机之间的通信量；由于缺少端口号，TCP和UDP以外的协议可能与NAT不兼容。NAT也会破坏以某种方式依赖于IP地址的协议。通常情况下，NAT设备充当通向公共互联网的主机，以及通向内部网络的路由器。
NBMA: Non-Broadcast Multi-Access. This is a network configuration in which nodes can exchange packets directly by addressing them at the desired destination. However, broadcasts or multicasts are not supported, so autodiscovery mechanisms such as IPv6 Neighbour Discovery must be modified to use unicast to work.
NBMA：非广播多址接入。这是一种网络配置，其中节点可以通过在所需目的地寻址来直接交换数据包。但是，不支持广播或多播，因此必须修改自动发现机制（如IPv6邻居发现）以使用单播工作。
Node: A device that implements IP, either a host or a router; also known as a system. See note at "NAT".
节点：实现IP的设备，主机或路由器；也称为系统。见“NAT”中的注释。
Path stretch: The difference between the shortest path through the network and the path (tunneled) packets actually take.
路径延伸：通过网络的最短路径与数据包实际使用的路径（隧道）之间的差异。
PMTUD: Path MTU Discovery, a method to determine the smallest MTU on the path between two nodes. There are separate specifications for PMTUD over IPv4 [RFC1191] and IPv6 [RFC1981].
路径MTU发现，一种确定两个节点之间路径上最小MTU的方法。IPv4[RFC1191]和IPv6[RFC1981]上的PMTUD有单独的规范。
Router: A device that forwards IP packets that it didn't generate itself. See note at "NAT".
路由器：一种转发自己未生成的IP数据包的设备。见“NAT”中的注释。
System: A device that implements IP, either a host or a router; a network node.
系统：实现IP的设备，主机或路由器；网络节点。
Translation: The IPv6 and IPv4 headers are similar enough that it is possible to translate between them. This allows IPv6-only hosts to communicate with IPv4-only hosts. The original specification for translating between IPv6 and IPv4 was heavily criticised by the Internet Architecture Board, but new specifications for translating between IPv6 and IPv4 were later published [RFC6145]. Translation is one of the three IPv4-to-IPv6 transition tools; the others are dual stack and tunnels.
转换：IPv6和IPv4标头非常相似，可以在它们之间进行转换。这允许仅IPv6主机与仅IPv4主机通信。最初的IPv6和IPv4之间转换规范受到了互联网体系结构委员会的严厉批评，但后来发布了IPv6和IPv4之间转换的新规范[RFC6145]。转换是三种IPv4到IPv6转换工具之一；其他是双烟囱和隧道。
Tunnel: By encapsulating IPv6 packets inside IPv4 packets, IPv6- capable hosts and IPv6-capable networks isolated from other IPv6- capable systems or the IPv6 Internet at large can exchange IPv6 packets over IPv4-only infrastructure. There are numerous ways to tunnel IPv6 over IPv4. This document compares these mechanisms. Tunneling is one of the three IPv4-to-IPv6 transition tools; the others are translation and dual stack.
隧道：通过将IPv6数据包封装在IPv4数据包中，与其他支持IPv6的系统或整个IPv6 Internet隔离的支持IPv6的主机和支持IPv6的网络可以通过仅支持IPv4的基础设施交换IPv6数据包。通过IPv4隧道IPv6的方法有很多种。本文件比较了这些机制。隧道是三种IPv4到IPv6转换工具之一；其他的是平移和双堆栈。
Tunnel broker: A service that provides tunneled connectivity to the IPv6 Internet, such as SixXS [SIXXS], tunnelbroker.net [TUNBROKER], and gogo6 [GOGO6].
隧道代理：提供到IPv6 Internet的隧道连接的服务，如SixXS[SixXS]、tunnelbroker.net[TUNBROKER]和gogo6[gogo6]。
Automatic tunnels (Section 3.2), configured tunnels (Section 3.1), 6over4 (Section 3.3), 6to4 (Section 3.5), the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (Section 3.7), and 6rd (Section 3.9) solve similar problems at different scales. They all encapsulate IPv6 packets immediately inside an IPv4 packet, without using additional headers. This is called "protocol 41 encapsulation" (see Section 5.1), as the Protocol field in the IPv4 header is set to 41 to indicate that what follows is an IPv6 packet.
自动隧道（第3.2节）、配置隧道（第3.1节）、6over4（第3.3节）、6to4（第3.5节）、站点内自动隧道寻址协议（ISATAP）（第3.7节）和6rd（第3.9节）解决了不同规模的类似问题。它们都将IPv6数据包立即封装在IPv4数据包中，而不使用额外的头。这被称为“协议41封装”（参见第5.1节），因为IPv4报头中的协议字段被设置为41，以指示接下来是IPv6数据包。
6to4, 6rd, ISATAP, and automatic tunneling each generate an IPv6 address or range of IPv6 addresses for the host or router running the protocol based on the system's IPv4 address in one way or another (see Section 5.4). This lets 6to4, 6rd, ISATAP, and automatic tunnels determine the IPv4 destination address in the outer IPv4 header from the IPv6 address of the destination, allowing for automatic operation without the need to administratively configure the remote tunnel endpoint.
6to4、6rd、ISATAP和自动隧道都会基于系统的IPv4地址以某种方式为运行协议的主机或路由器生成IPv6地址或IPv6地址范围（请参见第5.4节）。这允许6to4、6rd、ISATAP和自动隧道根据目标的IPv6地址确定外部IPv4报头中的IPv4目标地址，从而允许自动操作，而无需管理性地配置远程隧道端点。
6over4 and ISATAP provide IPv6 connectivity between IPv6-capable systems within a single organisation's network that is otherwise IPv4 only. 6rd allows ISPs to provide IPv6 connectivity to their customers over IPv4-only last-mile infrastructures. 6to4 directly provides connectivity to the global IPv6 Internet without involving an ISP.
6over4和ISATAP在单个组织网络内的支持IPv6的系统之间提供IPv6连接，否则仅限于IPv4。6rd允许ISP通过仅限IPv4的最后一英里基础设施向其客户提供IPv6连接。6to4直接提供到全球IPv6 Internet的连接，无需ISP参与。
Configured tunnels (Section 3.1) also use protocol 41 encapsulation but rely on manual configuration of the remote tunnel endpoint. (The Heartbeat Protocol (Section 4.2) solves this.) Configured tunnels can be used within an organisation's network but are typically used by tunnel-broker services to provide connectivity to the IPv6 Internet. GRE (Section 3.4) is similar to configured tunnels, but also supports encapsulating protocols other than IPv6.
配置的隧道（第3.1节）也使用协议41封装，但依赖于远程隧道端点的手动配置。（心跳协议（第4.2节）解决了这一问题。）配置的隧道可以在组织的网络中使用，但通常由隧道代理服务用于提供到IPv6 Internet的连接。GRE（第3.4节）类似于配置的隧道，但也支持除IPv6之外的封装协议。
AYIYA (Section 3.6) is similar to configured tunnels and GRE but typically uses a UDP header for better compatibility with NATs and is generally used with the Tunnel Information and Control (TIC) protocol (Section 4.3) to set up the tunnel rather than rely on manual configuration. Teredo (Section 3.8), 6a44 (Section 3.10), and 6bed4 (Section 3.13) are similar to 6to4, except that they are designed to work through NATs by running over UDP. Of these, Teredo and 6bed4 assume no ISP involvement and 6a44 does; 6bed4 is designed to work over direct IPv4 paths between peers whenever possible.
AYIYA（第3.6节）与配置的隧道和GRE类似，但通常使用UDP报头以更好地与NAT兼容，并且通常与隧道信息和控制（TIC）协议（第4.3节）一起使用以设置隧道，而不是依赖于手动配置。Teredo（第3.8节）、6a44（第3.10节）和6bed4（第3.13节）与6to4类似，只是它们的设计目的是通过UDP运行，通过NAT工作。其中，Teredo和6bed4假设没有ISP参与，6a44假设没有；6bed4设计用于尽可能在对等方之间的直接IPv4路径上工作。
The Locator/ID Separation Protocol (LISP) (Section 3.11) is a system for abstracting the identifying function from the location function of IP addresses; this allows for the use of IPv6 for the former and IPv4 for the latter.
定位器/ID分离协议（LISP）（第3.11节）是一个系统，用于从IP地址的位置功能中提取识别功能；这允许前者使用IPv6，后者使用IPv4。
The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Section 3.12) and its companion technologies (Virtual Enterprise Traversal (VET), Asymmetric Extended Route Optimization (AERO), Internet Routing Overlay Network (IRON), and Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)) provide a configured tunnel system for IPv6-in-IPv4 tunneling to default routers as well as automatic tunnel endpoint discovery for optimisation of more-specific routes.
子网封装和适配层（SEAL）（第3.12节）及其配套技术（虚拟企业遍历（VET）、非对称扩展路由优化（AERO）、互联网路由覆盖网络（IRON）以及具有全局企业递归的网络中的路由和寻址（RANGER））为IPv6-in-IPv4隧道到默认路由器以及自动隧道端点发现提供配置的隧道系统，以优化更具体的路由。
Dual-Stack Lite [RFC6333] and MAP [MAP], both developed by the IETF Softwire working group, often come up in discussions about IPv6 tunneling. However, they are _not_ IPv6-in-IPv4 tunnel mechanisms. They are IPv4-in-IPv6 mechanisms for providing IPv4 connectivity over an IPv6 infrastructure.
IETF Softwire工作组开发的双栈Lite[RFC6333]和MAP[MAP]经常出现在有关IPv6隧道的讨论中。但是，它们不是IPv6-in-IPv4隧道机制。它们是IPv6中的IPv4机制，用于通过IPv6基础结构提供IPv4连接。
Please refer to Section 5 for more information about issues common to many tunnel mechanisms; those issues are not discussed separately for each mechanism. The mechanisms are discussed below in roughly chronological order.
有关许多隧道机制常见问题的更多信息，请参阅第5节；对于每个机制，这些问题没有单独讨论。下面将按大致的时间顺序讨论这些机制。
Configured and automatic tunnels are the two oldest tunnel mechanisms, originally published in "Transition Mechanisms for IPv6 Hosts and Routers" [RFC1933] in 1996. The latest specification of configured tunnels is "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], published in 2005. The mechanism is sometimes called "manual tunnels", "static tunnels", "protocol 41 tunnels", or "6in4".
配置隧道和自动隧道是最古老的两种隧道机制，最初发表在1996年的“IPv6主机和路由器的转换机制”[RFC1933]中。配置隧道的最新规范是2005年发布的“IPv6主机和路由器的基本转换机制”[RFC4213]。该机制有时被称为“手动隧道”、“静态隧道”、“协议41隧道”或“6in4”。
Configured tunnels connect two systems in point-to-point fashion using protocol 41 encapsulation. The configuration that the name of the mechanism alludes to consists of a remote "tunnel endpoint".
配置的隧道使用协议41封装以点对点方式连接两个系统。机制名称所指的配置由远程“隧道端点”组成。
This is the IPv4 address of the system on the other side of the tunnel. When a system (potentially) has multiple IPv4 addresses, the local tunnel endpoint address may also need to be configured.
这是隧道另一端系统的IPv4地址。当系统（可能）具有多个IPv4地址时，可能还需要配置本地隧道端点地址。
The need to explicitly set up configured tunnels makes them more difficult to deploy than automatic mechanisms. However, because there is a fixed, single remote tunnel endpoint, performance is predictable and the tunnel is easy to debug.
需要显式设置已配置的隧道使得它们比自动机制更难部署。但是，由于存在固定的单个远程隧道端点，因此性能是可预测的，并且隧道易于调试。
In the early days, it was not unheard of for a small network to get IPv6 connectivity from another continent. This excessive path stretch makes communication over short geographic distances much less efficient because the distance travelled by packets may be larger than the geographic distance by an order of magnitude or more.
在早期，小型网络从另一个大陆获得IPv6连接并非闻所未闻。这种过度的路径延伸使得短地理距离上的通信效率大大降低，因为分组所经过的距离可能比地理距离大一个数量级或更多。
Configured tunnels are widely implemented. Common operating systems can terminate configured tunnels, as well as IPv6-capable routers and home gateways. The mechanism is versatile but is mostly used between isolated smaller IPv6-capable networks and the IPv6 Internet, often through a "tunnel broker" such as tunnelbroker.net [TUNBROKER], SixXS [SIXXS], or gogo6 [GOGO6].
配置隧道被广泛实施。通用操作系统可以终止已配置的隧道，以及支持IPv6的路由器和家庭网关。该机制用途广泛，但主要用于支持IPv6的孤立较小网络和IPv6 Internet之间，通常通过“隧道代理”，如tunnelbroker.net[TUNBROKER]、SixXS[SixXS]或gogo6[gogo6]。
[RFC4891] discusses the use of IPsec to protect the confidentiality and integrity of IPv6 traffic exchanged over configured tunnels.
[RFC4891]讨论了使用IPsec保护通过已配置隧道交换的IPv6流量的机密性和完整性。
Automatic tunneling is described in [RFC2893], "Transition Mechanisms for IPv6 Hosts and Routers", but removed in [RFC4213], which is a replacement of RFC 2893. Configured tunnels (Section 3.1) are closely related to automatic tunnels and are specified in RFCs 2893 and 4213, too. Both use protocol 41 encapsulation.
[RFC2893]，“IPv6主机和路由器的转换机制”中描述了自动隧道，但[RFC4213]中删除了自动隧道，它是RFC 2893的替代品。配置隧道（第3.1节）与自动隧道密切相关，并且在RFCs 2893和4213中也有规定。两者都使用协议41封装。
Hosts that are capable of automatic tunneling use special IPv6 addresses: IPv4-compatible addresses. An IPv4-compatible IPv6 address consists of 96 zero bits followed by the system's IPv4 address. When sending packets to destinations within the IPv4- compatible ::/96 prefix, the IPv4 destination address in the outer IPv4 header is taken from the IPv4 address in the IPv4-compatible IPv6 destination address.
能够自动隧道的主机使用特殊的IPv6地址：与IPv4兼容的地址。与IPv4兼容的IPv6地址由96个零位组成，后跟系统的IPv4地址。将数据包发送到IPv4兼容的：：/96前缀内的目标时，外部IPv4标头中的IPv4目标地址取自IPv4兼容的IPv6目标地址中的IPv4地址。
Automatic tunneling has a big limitation: it only allows for communication between IPv6-capable systems that both support automatic tunneling. There are no provisions for communicating with the native IPv6 Internet. As such, the mechanism is of almost no practical use and is not implemented in current operating systems, as 6to4 (Section 3.5) does what automatic tunneling was supposed to do, but it also provides connectivity to the rest of the IPv6 Internet.
自动隧道有一个很大的限制：它只允许支持自动隧道的支持IPv6的系统之间进行通信。没有与本机IPv6 Internet通信的规定。因此，该机制几乎没有实际用途，也没有在当前的操作系统中实现，因为6to4（第3.5节）实现了自动隧道的功能，但它也提供了与IPv6 Internet其余部分的连接。
"Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" [RFC2529] was published in 1999. The mechanism is commonly known as "6over4".
“通过IPv4域传输IPv6而不使用显式隧道”[RFC2529]于1999年发布。这种机制通常被称为“6over4”。
6over4 is designed to work within a single organisation's IPv4 network, where IPv6-capable hosts and routers are separated by IPv4- only routers. 6over4 treats the IPv4 network as a "virtual Ethernet" for the purpose of IPv6 communication. It uses IPv4 multicast to tunnel IPv6 multicast packets. A node's IPv4 address is included in the Interface Identifier used on the virtual 6over4 interface, allowing the exchange of protocol 41 encapsulated packets between 6over4 nodes without prior administrative configuration.
6over4设计用于单个组织的IPv4网络，其中支持IPv6的主机和路由器由仅IPv4的路由器分隔。6over4将IPv4网络视为用于IPv6通信的“虚拟以太网”。它使用IPv4多播来隧道IPv6多播数据包。节点的IPv4地址包含在虚拟6over4接口上使用的接口标识符中，允许在6over4节点之间交换协议41封装的数据包，而无需事先进行管理配置。
Because multicast is supported, standard IPv6 Neighbour Discovery and Stateless Address Autoconfiguration [RFC4862] can be used. Although, like automatic tunnels (Section 3.2) and other mechanisms, 6over4 embeds the IPv4 address of the host in the IPv6 address, the destination IPv4 address in the outer IPv4 header is *not* derived from the IPv6 address embedded in the inner IPv6 header, but learnt through Neighbour Discovery [RFC4861]. In effect, the IPv4 addresses of the hosts are used as link-layer addresses in the same way that Media Access Control (MAC) addresses are used on Ethernet networks.
由于支持多播，因此可以使用标准IPv6邻居发现和无状态地址自动配置[RFC4862]。尽管与自动隧道（第3.2节）和其他机制一样，6over4将主机的IPv4地址嵌入IPv6地址，但外部IPv4报头中的目标IPv4地址*不是*从嵌入内部IPv6报头中的IPv6地址派生，而是通过邻居发现学习的[RFC4861]。实际上，主机的IPv4地址用作链路层地址的方式与以太网上使用媒体访问控制（MAC）地址的方式相同。
One or more routers with connectivity to the global IPv6 Internet send out Router Advertisements to provide 6over4 hosts with connectivity to the rest of the IPv6 Internet.
一个或多个连接到全局IPv6 Internet的路由器发送路由器广告，以提供6台以上连接到IPv6 Internet其余部分的主机。
6over4 has the minimal overhead for protocol 41 encapsulation and doesn't require manual configuration. Hosts can only take advantage of 6over4 if they run the mechanism themselves. 6over4 packets can't pass through a NAT successfully, as the IPv4 address exchanged through Neighbour Discovery will be different from the one needed to reach the host in question, and because, without port numbers, protocol 41 doesn't allow for multiplexing multiple hosts using this encapsulation behind a single IPv4 address. However, 6over4 works within IPv4 domains that reside behind a NAT in their entirety and use RFC 1918 addressing.
6over4具有协议41封装的最小开销，不需要手动配置。如果主机自己运行该机制，则只能利用6over4。6超过4个数据包无法成功通过NAT，因为通过邻居发现交换的IPv4地址将不同于到达相关主机所需的地址，并且因为没有端口号，协议41不允许在单个IPv4地址后使用此封装多路复用多个主机。然而，6over4在整个NAT后面的IPv4域中工作，并使用RFC1918寻址。
Because of its reliance on IPv4 multicast and because local IPv6 communication is relatively easy to facilitate using IPv6 routers, 6over4 is not supported in current operating systems. ISATAP (Section 3.7) provides very similar functionality without requiring IPv4 multicast capability and is implemented more widely.
由于6over4依赖IPv4多播，并且使用IPv6路由器相对容易实现本地IPv6通信，因此当前操作系统不支持6over4。ISATAP（第3.7节）提供了非常类似的功能，不需要IPv4多播功能，并且实现得更广泛。
Generic Routing Encapsulation (GRE) [RFC2784] is a generic point-to-point tunnel mechanism that allows many other protocols to be encapsulated in IP.
通用路由封装（GRE）[RFC2784]是一种通用的点到点隧道机制，允许在IP中封装许多其他协议。
GRE is a simple protocol that is similar to configured tunnels (Section 3.1) when used for IPv6-in-IPv4 tunneling. The main benefit of GRE is that it can encapsulate any protocol's packets, not only IPv6 packets. The GRE header causes an extra overhead of 8 to 16 bytes depending on which options are used. GRE sets the Protocol field in the IP header to 47.
GRE是一个简单的协议，当用于IPv6-in-IPv4隧道时，它类似于配置的隧道（第3.1节）。GRE的主要优点是它可以封装任何协议的数据包，而不仅仅是IPv6数据包。GRE头会导致8到16字节的额外开销，具体取决于所使用的选项。GRE将IP头中的协议字段设置为47。
The GRE header can optionally contain a checksum, a key to separate different traffic flows (for example, different tunnels) between the same endpoints, and a sequence number that can be used to prevent packets from being processed out of order.
GRE报头可以选择性地包含校验和、用于分离相同端点之间的不同流量（例如，不同隧道）的密钥以及可用于防止数据包被无序处理的序列号。
GRE is implemented in many routers but not in most consumer-level home gateways or desktop operating systems.
GRE在许多路由器中实现，但在大多数消费者级家庭网关或桌面操作系统中没有实现。
6to4 is specified in "Connection of IPv6 Domains via IPv4 Clouds" [RFC3056]. It creates a block of IPv6 addresses from a locally configured IPv4 address by concatenating that IPv4 address to the prefix 2002::/16, resulting in a /48 IPv6 prefix. Addresses in 2002::/16 are considered reachable through the tunnel interface, so the 6to4 network functions as a Non-Broadcast Multi-Access (NBMA) network through which 6to4 users can communicate. IPv6 packets are encapsulated by adding an IPv4 header with the Protocol field set to 41.
6to4在“通过IPv4云连接IPv6域”[RFC3056]中指定。它通过将本地配置的IPv4地址连接到前缀2002:：/16，从该IPv4地址创建IPv6地址块，从而生成/48 IPv6前缀。2002年的地址：：/16被认为可以通过隧道接口访问，因此6to4网络作为非广播多址（NBMA）网络运行，6to4用户可以通过该网络进行通信。IPv6数据包通过添加协议字段设置为41的IPv4报头进行封装。
The /48 prefix allows a single system running 6to4 to act as a gateway or router for a large number of IPv6 hosts. Alternatively, an individual host may run 6to4 and not act as a gateway or router. The system running 6to4 must have a globally reachable IPv4 address. Using 6to4 with a private IPv4 address [RFC1918] is not possible.
/48前缀允许运行6to4的单个系统充当大量IPv6主机的网关或路由器。或者，单个主机可以运行6to4，而不充当网关或路由器。运行6to4的系统必须具有全局可访问的IPv4地址。无法将6to4与专用IPv4地址[RFC1918]一起使用。
"An Anycast Prefix for 6to4 Relay Routers" [RFC3068] specifies an anycast mechanism for 6to4 relays that provide connectivity between the 6to4 network and the regular IPv6 Internet. All public relays share the IPv4 address 192.88.99.1, which corresponds to 2002:c058: 6301::. Relays advertise reachability towards 2002::/16 to the native IPv6 Internet, so packets addressed to systems using 6to4 addresses are routed to the closest gateway. The gateway encapsulates these packets and forwards them to the IPv4 address included in the IPv6 address. Systems running 6to4 have a default
“6to4中继路由器的选播前缀”[RFC3068]指定6to4中继的选播机制，该机制提供6to4网络和常规IPv6 Internet之间的连接。所有公共中继共享IPv4地址192.88.99.1，对应于2002:c058:6301:：。中继向本机IPv6 Internet播发2002:：/16的可达性，因此使用6to4地址发往系统的数据包被路由到最近的网关。网关封装这些数据包并将其转发到IPv6地址中包含的IPv4地址。运行6to4的系统具有默认设置
route pointing to 2002:c058:6301::, so they tunnel packets addressed to non-6to4 IPv6 destinations to the closest relay, which decapsulates the packet and forwards them as IPv6 packets.
路由指向2002:c058:6301:：，因此它们通过隧道将发往非6to4 IPv6目的地的数据包传输到最近的中继，中继将数据包解封并作为IPv6数据包转发。
The 6to4 protocol adds minimal overhead for protocol 41 encapsulation and requires no manual configuration from users. The biggest problem specific to 6to4 is that it is unpredictable which 6to4 anycast relay is used. These relays are often provided by third parties on a best-effort basis. In practice, this has caused unpredictable performance. Traffic from the 6to4 network to the regular IPv6 Internet will likely use a different 6to4 relay than the traffic in the opposite direction. If either of those relays is not reliable, then the communication between those networks is affected. Especially the lack of control over the relay used for return traffic is considered to be a problem with 6to4.
6to4协议为协议41封装增加了最小的开销，并且不需要用户手动配置。6to4特有的最大问题是无法预测使用哪个6to4选播中继。这些继电器通常由第三方尽最大努力提供。实际上，这导致了不可预测的性能。从6to4网络到常规IPv6互联网的流量可能会使用与反向流量不同的6to4中继。如果这些继电器中的任何一个不可靠，则这些网络之间的通信将受到影响。尤其是对用于返回通信的中继缺乏控制被认为是6to4的一个问题。
To avoid problems with 6to4, the IPv6 Default Address Selection algorithm [RFC6724] gives IPv4 addresses a higher preference than 6to4 addresses. When making a connection, a system will prefer native IPv6 over IPv4, and IPv4 over 6to4 IPv6. This causes 6to4 to be used only when a destination is not reachable over IPv4 and no other IPv6 connectivity is available.
为了避免6to4出现问题，IPv6默认地址选择算法[RFC6724]给予IPv4地址比6to4地址更高的优先级。建立连接时，系统将首选本机IPv6而不是IPv4，IPv4而不是6to4 IPv6。这导致仅当无法通过IPv4访问目标并且没有其他IPv6连接可用时，才使用6to4。
For more information about 6to4, see "Advisory Guidelines for 6to4 Deployment" [RFC6343].
有关6to4的更多信息，请参阅“6to4部署咨询指南”[RFC6343]。
*Warning*:
*警告*：
Although many, if not all, 6to4 implementations disable the mechanism when the system only has an RFC 1918 address, recently a block of IPv4 addresses has been set aside for use in service-provider-operated Network Address Translators, also known as Carrier-Grade NATs (CGNs). [RFC6598] sets aside the block 100.64.0.0/10 for the use between CGNs and subscriber devices. As 100.64.0.0/10 is not an RFC 1918 address block, systems implementing 6to4 may fail to disable the mechanism, but due to the shared nature of the 100.64.0.0/10 prefix, 6to4 cannot work using these addresses. The same issue is present if an ISP decides to use regular global unicast IPv4 address space behind a CGN.
尽管许多（如果不是全部的话）6to4实现在系统只有RFC1918地址时禁用了该机制，但最近，一组IPv4地址被预留用于服务提供商操作的网络地址转换器，也称为载波级NAT（CGN）。[RFC6598]留出块100.64.0.0/10供CGN和订户设备之间使用。由于100.64.0.0/10不是RFC 1918地址块，实现6to4的系统可能无法禁用该机制，但由于100.64.0.0/10前缀的共享性质，6to4无法使用这些地址工作。如果ISP决定在CGN后面使用常规全局单播IPv4地址空间，则会出现相同的问题。
[RFC6732] describes "6to4 provider managed tunnels", which are a way to make 6to4 work behind a CGN. This is accomplished by running a 6to4 gateway at the 6to4 gateway anycast address, and then translating the IPv6 addresses used by 6to4 users behind the CGN to IPv6 addresses from the ISP's range. Unlike IPv4 NAT, where multiple
[RFC6732]描述了“6to4提供者管理的隧道”，这是一种使6to4在CGN后面工作的方法。这是通过在6to4网关选播地址运行6to4网关来实现的，然后将CGN后面的6to4用户使用的IPv6地址转换为ISP范围内的IPv6地址。与IPv4 NAT不同，IPv4 NAT
internal hosts share a single public IPv4 address, prefix translation maps entire prefixes, so each host has its own public IPv6 address and can receive incoming packets as usual.
内部主机共享一个公共IPv4地址，前缀转换映射整个前缀，因此每个主机都有自己的公共IPv6地址，并且可以像往常一样接收传入的数据包。
However, if IPv6 applications are not aware that translation is happening (and they have no reason to expect that it is), they may not use their externally visible address in referrals, so applications that use referrals are likely to fail. Additionally, the translation is only specified for packets that flow through the 6to4 gateway, not for packets sent directly to other 6to4 users. So, communication with other 6to4 users is not possible. As such, the use of 6to4 provider managed tunnels is discouraged except as a very last resort.
但是，如果IPv6应用程序不知道正在发生转换（并且他们没有理由预期会发生），他们可能不会在转介中使用其外部可见地址，因此使用转介的应用程序可能会失败。此外，仅为流经6to4网关的数据包指定转换，而不为直接发送给其他6to4用户的数据包指定转换。因此，无法与其他6to4用户通信。因此，不鼓励使用6to4提供商管理的隧道，除非作为最后手段。
AYIYA [AYIYA] is designed for use by the SixXS [SIXXS] tunnel-broker service. For more information, see the specification [MASSAR].
AYIYA[AYIYA]是为SixXS[SixXS]隧道代理服务设计的。有关更多信息，请参阅规范[MASSAR]。
The AYIYA protocol defines a method for encapsulating any protocol in any other protocol. The most common way of deploying AYIYA is to use the following sequence of headers: IPv4-UDP-AYIYA-IPv6, although other combinations like IPv4-AYIYA-IPv6 or IPv6-SCTP-AYIYA-IPv4 are also possible. That document does not limit the contents nor the protocol that carries the AYIYA packets. In this document, we only look at the most common usage (IPv4-UDP-AYIYA-IPv6) that is deployed on the SixXS tunnel brokers to provide IPv6 access to clients behind NAT devices.
AYIYA协议定义了将任何协议封装到任何其他协议中的方法。部署AYIYA最常见的方法是使用以下报头序列：IPv4-UDP-AYIYA-IPv6，但也可以使用其他组合，如IPv4-AYIYA-IPv6或IPv6-SCTP-AYIYA-IPv4。该文件不限制内容，也不限制携带AYIYA数据包的协议。在本文档中，我们仅介绍部署在SixXS隧道代理上的最常见用法（IPv4-UDP-AYIYA-IPv6），以向NAT设备后面的客户端提供IPv6访问。
AYIYA specifies the encapsulation, identification, checksum, security, and certain management operations that can be used once the tunnel is established. It does not specify how the tunnel configuration parameters can be negotiated. Typically, the TIC protocol described in Section 4.3 is used for that part of the tunnel setup, although the Tunnel Setup Protocol (TSP) (Section 4.1) could just as well be used.
AYIYA指定了封装、标识、校验和、安全性以及隧道建立后可以使用的某些管理操作。它没有指定如何协商隧道配置参数。通常，第4.3节中描述的TIC协议用于隧道设置的该部分，尽管也可以使用隧道设置协议（TSP）（第4.1节）。
AYIYA provides a point-to-point tunnel, over which the endpoints can route traffic for any source and destination. When using SHA-1 hashing for authentication, as is common when using the Automatic IPv6 Connectivity Client Utility (AICCU) client with a SixXS tunnel server, the total packet overhead is 72 bytes (20 for the IPv4 header, 8 for UDP, and 44 for AYIYA).
AYIYA提供了一个点对点隧道，端点可以通过该隧道为任何源和目的地路由流量。当使用SHA-1哈希进行身份验证时，就像在SixXS隧道服务器上使用自动IPv6连接客户端实用程序（AICCU）客户端时一样，总数据包开销为72字节（IPv4报头为20字节，UDP为8字节，AYIYA为44字节）。
AYIYA provides operational commands for querying the hostname, address, contact information, software version, and last error message. An operational command to ask the other side of the tunnel to shut down is also available. These commands in the protocol can make debugging of AYIYA tunnels easier if the tools support them.
AYIYA提供用于查询主机名、地址、联系信息、软件版本和最后一条错误消息的操作命令。还可以发出要求隧道另一侧关闭的操作命令。如果工具支持，协议中的这些命令可以使AYIYA隧道的调试更容易。
The main advantage of AYIYA is that it can provide a stable tunnel through an IPv4 NAT. The UDP port numbers allow multiple AYIYA users to share a single IPv4 address behind a NAT.
AYIYA的主要优点是它可以提供通过IPv4 NAT的稳定隧道。UDP端口号允许多个AYIYA用户在NAT后面共享单个IPv4地址。
The client will contact the tunnel server at regular intervals, and the tunnel server will automatically adapt to changing IPv4 addresses and/or UDP port numbers. To prevent a third party from injecting rogue packets into the tunnel, the client can optionally be authenticated by using the identity and signature fields. A timestamp is included in the AYIYA header to guard against replay attacks.
客户端将定期联系隧道服务器，隧道服务器将自动适应IPv4地址和/或UDP端口号的变化。为了防止第三方将恶意数据包注入隧道，可以选择使用标识和签名字段对客户端进行身份验证。AYIYA标头中包含时间戳，以防止重播攻击。
There is currently a single implementation of this protocol: the AICCU [AICCU] client software used with the SixXS [SIXXS] tunnel-broker service.
该协议目前只有一个实现：与SixXS[SixXS]隧道代理服务一起使用的AICCU[AICCU]客户端软件。
ISATAP [RFC5214] uses protocol 41 encapsulation to provide connectivity between isolated IPv6-capable nodes within an organisation's internal network. It is similar to 6over4 (Section 3.3), but without the requirement that the IPv4 network supports multicast; unlike 6over4, ISATAP uses a Non-Broadcast Multi-Access (NBMA) communication model and thus doesn't support multicasts. The mechanism assigns IPv6 addresses whose Interface Identifier is solely defined by a node's IPv4 address, which is assumed to be unique.
ISATAP[RFC5214]使用协议41封装来提供组织内部网络中支持IPv6的孤立节点之间的连接。它类似于6over4（第3.3节），但不要求IPv4网络支持多播；与6over4不同，ISATAP使用非广播多址（NBMA）通信模型，因此不支持多播。该机制分配IPv6地址，其接口标识符仅由节点的IPv4地址定义，假定该地址是唯一的。
In order to obtain a /64 prefix, an ISATAP host needs to send a unicast Router Solicitation to receive a unicast Router Advertisement from an ISATAP router. Without the ability to send and receive IPv6 multicasts, an ISATAP host must be configured with a Potential Router List through an all-IPv4 mechanism, such as manual setup, DHCP, or the DNS. Site administrators are encouraged to use a DNS Fully Qualified Domain Name using the convention "isatap.domainname" (e.g., isatap.example.com). Hosts will accept packets with IPv4 sender addresses that are either on the Potential Router List or embedded in the IPv6 sender address.
为了获得/64前缀，ISATAP主机需要发送单播路由器请求以从ISATAP路由器接收单播路由器广告。由于无法发送和接收IPv6多播，ISATAP主机必须通过全IPv4机制（如手动设置、DHCP或DNS）配置潜在的路由器列表。鼓励站点管理员使用约定“isatap.domainname”（例如isatap.example.com）的DNS完全限定域名。主机将接受IPv4发送方地址在潜在路由器列表上或嵌入IPv6发送方地址中的数据包。
The router's prefix and the IPv4 address together define the IPv6 address for the ISATAP interface. This means that precisely one ISATAP address is available for each IPv4 address. As such, each
路由器的前缀和IPv4地址一起定义ISATAP接口的IPv6地址。这意味着每个IPv4地址正好有一个ISATAP地址可用。因此，每个
host needs to run ISATAP itself in order to enjoy ISATAP IPv6 connectivity. The IPv4 address in the destination IPv6 address is used to bootstrap Neighbour Discovery.
主机需要自行运行ISATAP才能享受ISATAP IPv6连接。目标IPv6地址中的IPv4地址用于引导邻居发现。
[RFC5214] doesn't explicitly address the use of ISATAP using private RFC 1918 addresses. Despite that, the mechanism seems compatible with private addresses. NAT, however, breaks the relationship between the IPv4 address embedded in the IPv6 address and would therefore make communication between ISATAP hosts impossible. Any device that can communicate with the ISATAP hosts over IPv4 using protocol 41 can participate in the IPv6 subnet.
[RFC5214]没有使用专用RFC 1918地址明确说明ISATAP的使用。尽管如此，该机制似乎与私有地址兼容。但是，NAT会破坏嵌入IPv6地址中的IPv4地址之间的关系，从而使ISATAP主机之间无法通信。任何可以使用协议41通过IPv4与ISATAP主机通信的设备都可以参与IPv6子网。
ISATAP is available in Windows, Linux, and Cisco IOS.
ISATAP可在Windows、Linux和Cisco IOS中使用。
Teredo is specified in [RFC4380] and a few updates; it is designed as an automatic tunnel mechanism of last resort. It can configure an IPv6 address behind most NAT devices, but not all. Because Teredo uses encapsulation in UDP, multiple Teredo clients can be simultaneously active behind the same NAT. For each Teredo client, a single IPv6 address is then created at the expense of a single external UDP port.
Teredo在[RFC4380]和一些更新中指定；它是作为最后手段的自动隧道机制而设计的。它可以在大多数NAT设备后面配置IPv6地址，但不是全部。因为Teredo在UDP中使用封装，所以多个Teredo客户端可以在同一NAT后面同时处于活动状态。对于每个Teredo客户端，将创建一个IPv6地址，而不使用单个外部UDP端口。
The operation of Teredo is based on a classification of NAT [RFC3489] as established during an interaction with a Teredo server. This classification has since been obsoleted (by [RFC5389]) because it assigns more properties to NAT than achieved in reality.
Teredo的操作基于与Teredo服务器交互期间建立的NAT[RFC3489]分类。这种分类已经被淘汰（被[RFC5389]），因为它为NAT分配了比实际更多的属性。
Teredo is present in Windows XP and later and is enabled by default in Windows Vista and later. However, if IPv6 connectivity is only possible through Teredo, then Windows will not look up AAAA records when resolving domain names. This means that Teredo is only used to connect to explicit IPv6 addresses obtained through another mechanism than DNS. An open-source implementation named Miredo exists for other platforms.
Teredo存在于Windows XP和更高版本中，在Windows Vista和更高版本中默认启用。但是，如果IPv6连接只能通过Teredo实现，那么Windows在解析域名时将不会查找AAAA记录。这意味着Teredo仅用于连接到通过DNS以外的其他机制获得的显式IPv6地址。其他平台也有一个名为Miredo的开源实现。
The performance of Teredo falls noticeably short of that of IPv4. The setup time of a connection involves finding a Teredo relay nearby the native address to encapsulate and decapsulate traffic, and finding this relay can take in the order of seconds. This process is not sufficiently reliable; Teredo fails in about 37% [TERTST] of its attempts to connect to native IPv6 destinations. The roundtrip time of traffic can add tenths of a second, and jitter generally worsens if it is dependent on a public relay.
Teredo的性能明显低于IPv4。连接的设置时间包括在本机地址附近查找Teredo中继以封装和解除封装通信，查找此中继可能需要几秒钟的时间。这一过程不够可靠；Teredo在尝试连接到本机IPv6目的地时，约有37%的[TERTST]失败。交通的往返时间可以增加十分之一秒，如果依赖于公共中继，抖动通常会恶化。
Teredo clients need to be configured with a Teredo server when setting up their local IPv6 address and when initiating a connection to a native IPv6 destination. The hostnames of the Teredo servers are usually preconfigured by the vendor of the Teredo implementation. All Microsoft Windows implementations use Teredo servers provided by Microsoft by default.
在设置Teredo客户端的本地IPv6地址和启动与本机IPv6目标的连接时，需要使用Teredo服务器配置Teredo客户端。Teredo服务器的主机名通常由Teredo实现的供应商预先配置。默认情况下，所有Microsoft Windows实施都使用Microsoft提供的Teredo服务器。
6rd [RFC5969] is used by service providers to connect customer networks behind a CPE (Customer Premises Equipment) to the IPv6 Internet.
6rd[RFC5969]用于服务提供商将CPE（客户场所设备）后面的客户网络连接到IPv6互联网。
The structure of the 6rd protocol is based on 6to4, and it has the same minimal overhead as all protocols that use protocol 41 encapsulation. The main differences between 6rd and 6to4 are that 6rd is meant to be used inside a service provider's network and does not use a special IPv6 prefix but one or more prefixes routed to the service provider. As such, 6rd users aren't immediately recognisable by their IPv6 address the way 6to4 users are. Where 6to4 uses relays based on global anycast routing, 6rd uses relays provided and maintained by the service provider. Because of this architecture, the tunnel does not traverse unknown networks; this makes any debugging much easier.
第6rd协议的结构基于6to4，它具有与使用协议41封装的所有协议相同的最小开销。6rd和6to4之间的主要区别在于6rd用于服务提供商的网络内部，不使用特殊的IPv6前缀，而是使用一个或多个路由到服务提供商的前缀。因此，第6位用户无法像第6到4位用户那样通过IPv6地址立即识别。其中6to4使用基于全局选播路由的中继，6rd使用由服务提供商提供和维护的中继。由于这种结构，隧道不会穿越未知网络；这使得任何调试都更加容易。
6rd is completely stateless once it is configured. The tunnel endpoints can therefore be deployed using anycast. This is commonly done for the 6rd border relays deployed by the service provider to provide redundancy.
6rd在配置后完全无状态。因此，可以使用anycast部署隧道端点。这通常适用于服务提供商部署的第六边界中继，以提供冗余。
Because of the different prefix, the device used as the 6rd client cannot use the hard-coded IPv6 prefix calculation and relay addresses of 6to4. Instead, the 6rd client needs to receive configuration information to work. In principle, 6rd nodes may be configured in a variety of ways, the most common one being through DHCP. If the client receives its IPv4 address from a DHCPv4 server, then the 6rd configuration can be included in the DHCP message exchange using the 6rd DHCPv4 Option defined in [RFC5969]. Manual configuration of 6rd options and configuration using [TR-069] is also possible.
由于前缀不同，用作第6个客户端的设备无法使用硬编码IPv6前缀计算和中继地址6to4。相反，第6个客户端需要接收配置信息才能工作。原则上，第6个节点可以以多种方式配置，最常见的方式是通过DHCP。如果客户端从DHCPv4服务器接收到其IPv4地址，则可以使用[RFC5969]中定义的第6个DHCPv4选项将第6个配置包括在DHCP消息交换中。也可以手动配置第6个选项和使用[TR-069]进行配置。
The main advantage of using 6rd is that it allows service providers to deploy IPv6 on last-mile access networks that for some reason cannot provide native IPv6 connectivity. It does not share the lack of predictable routing that 6to4 suffers from because all routing, encapsulation, and decapsulation are done by the service provider.
使用6rd的主要优点是，它允许服务提供商在最后一英里接入网络上部署IPv6，因为某些原因，这些网络无法提供本机IPv6连接。它没有像6to4那样缺少可预测的路由，因为所有路由、封装和去封装都是由服务提供商完成的。
6rd is intended to be a service managed by an ISP or enterprise IT department that must explicitly make 6rd available for clients to be able to use it.
6rd是由ISP或企业IT部门管理的服务，必须明确地向客户提供6rd，以便客户能够使用它。
Inspired by Teredo, the 6a44 tunnel is described in "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)" [RFC6751]. Its purpose is to enable Internet Service Providers to establish IPv6 connectivity for their customers, in spite of the use of a CPE or home gateway that is not prepared for IPv6. The infrastructure required for this is a 6a44 relay in the ISP's network and a 6a44 client in the customer's internal network.
受Teredo的启发，6a44隧道在“IPv4到IPv4 NAT客户场所设备（6a44）背后的本机IPv6”中进行了描述[RFC6751]。其目的是使Internet服务提供商能够为其客户建立IPv6连接，尽管使用的是未准备好用于IPv6的CPE或家庭网关。这所需的基础设施是ISP网络中的6a44中继和客户内部网络中的6a44客户端。
6a44 was explicitly designed to overcome the noted problems with Teredo. Where Teredo was designed as a global solution without dependency on ISP cooperation, the 6a44 tunnel explicitly assumes ISP cooperation. Instead of using Teredo's well-known prefix, a /48 prefix out of the ISP's address space is used. A well-known (anycast) IPv4 address has been assigned for the 6a44 relay to be run inside the ISP network without client configuration. This well-known address is allocated from the same IPv4 /24 as 6to4.
6a44的明确设计是为了克服Teredo的突出问题。当Teredo被设计为一个不依赖ISP合作的全球解决方案时，6a44隧道明确假设ISP合作。使用ISP地址空间外的/48前缀，而不是使用Teredo众所周知的前缀。已为6a44中继分配了一个众所周知的（选播）IPv4地址，以便在ISP网络内运行，无需客户端配置。这个众所周知的地址是从与6to4相同的IPv4/24分配的。
As part of its bootstrapping, a 6a44 client requests an address from the 6a44 relay, and a regular keepalive sent by the 6a44 client to the 6a44 relay keeps mapping state in NATs and firewalls on the path alive. Traffic passed from the native IPv6 Internet to 6a44 is encapsulated in UDP and IPv4 by the relay and decapsulated by the 6a44 client; the opposite is done in the other direction.
作为其引导的一部分，6a44客户端从6a44中继请求地址，并且由6a44客户端发送到6a44中继的常规keepalive保持NAT和路径上防火墙的映射状态处于活动状态。从本机IPv6 Internet传递到6a44的流量由中继封装在UDP和IPv4中，并由6a44客户端解除封装；相反的方向是相反的。
The Locator/ID Separation Protocol (LISP) [RFC6830] is a protocol to separate the identity of systems from their location on the Internet and/or internal network. The addresses of the systems are called Endpoint Identifiers (EIDs), and the addresses of the gateways are called Routing Locators (RLOCs). It is possible to use IPv6 EIDs with IPv4 RLOCs and thereby use LISP for tunneling IPv6 over IPv4.
定位器/ID分离协议（LISP）[RFC6830]是一种将系统标识与其在Internet和/或内部网络上的位置分离的协议。系统的地址称为端点标识符（EID），网关的地址称为路由定位器（RLOC）。可以将IPv6 EID与IPv4 RLOC一起使用，从而使用LISP通过IPv4对IPv6进行隧道传输。
LISP defines its own packet formats for encapsulation of data packets and for control messages. All such packets are then encapsulated in UDP. Data packets use port 4341, and control packets use port 4342.
LISP为数据包的封装和控制消息定义了自己的包格式。然后，所有这些数据包都封装在UDP中。数据包使用端口4341，控制包使用端口4342。
The LISP specification consists of several RFCs. The relevant ones for IPv6-in-IPv4 tunneling are the base specification [RFC6830], "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites" [RFC6832], and "Locator/ID Separation Protocol (LISP) Map-Server Interface" [RFC6833].
LISP规范由几个RFC组成。IPv6-in-IPv4隧道的相关规范有基本规范[RFC6830]、“定位器/ID分离协议（LISP）和非LISP站点之间的互通”[RFC6832]和“定位器/ID分离协议（LISP）映射服务器接口”[RFC6833]。
+----+ +----+
| MS | | MR |
+----+ +----+ +-----+ /-----------\
| | /---| xTR |---| LISP site |
+------+ /------------\---/ +-----+ \-----------/
| PxTR |---| IP network |
+------+ \------------/---\ +-----+ /-----------\
| \---| xTR |---| LISP site |
/---------------\ +-----+ \-----------/
| Non-LISP site |
\---------------/
+----+ +----+
| MS | | MR |
+----+ +----+ +-----+ /-----------\
| | /---| xTR |---| LISP site |
+------+ /------------\---/ +-----+ \-----------/
| PxTR |---| IP network |
+------+ \------------/---\ +-----+ /-----------\
| \---| xTR |---| LISP site |
/---------------\ +-----+ \-----------/
| Non-LISP site |
\---------------/
An Example of a LISP Deployment
LISP部署的一个示例
LISP introduces new terminology and new concepts. The relevant ones for this document are:
LISP引入了新术语和新概念。本文件的相关内容包括：
ITR: Ingress Tunnel Router, a router encapsulating data packets at the border of a LISP site
ITR：入口隧道路由器，在LISP站点边界封装数据包的路由器
ETR: Egress Tunnel Router, a router decapsulating data packets at the border of a LISP site
ETR：出口隧道路由器，一种在LISP站点边界处解封装数据包的路由器
xTR: A router performing both the ITR and the ETR functions
xTR：同时执行ITR和ETR功能的路由器
PITR: Proxy ITR, a router accepting traffic from non-LISP sites, encapsulating it, and tunneling it to the LISP sites
PITR：代理ITR，一种路由器，接收来自非LISP站点的流量，将其封装，并通过隧道将其传输到LISP站点
PETR: Proxy ETR, a router accepting traffic from LISP sites to send it to non-LISP sites
PETR:Proxy ETR，一种路由器，接受来自LISP站点的流量，将其发送到非LISP站点
PxTR: A router performing both the PITR and the PETR functions
PxTR：同时执行PITR和PETR功能的路由器
MS: Map Server, a server accepting RLOC registrations from ETRs
MS:Map Server，从ETRs接受RLOC注册的服务器
MR: Map Resolver, a server that can resolve queries for RLOCs from ITRs
MR:Map Resolver，一个可以从ITRs解析RLOC查询的服务器
LISP ETRs register the EID prefixes for which they can handle traffic with one or more Map Servers. ITRs and PITRs can then query Map Resolvers to determine which RLOCs to use when sending traffic to a LISP site. PITRs advertise aggregates of EID prefixes to the global routing table and provide tunneling services for them so that non-LISP sites can reach LISP sites. PETRs provide a way for LISP sites to send traffic to non-LISP sites.
LISP ETR注册EID前缀，它们可以处理一个或多个地图服务器的流量。然后，ITR和PITR可以查询映射解析器，以确定在向LISP站点发送流量时要使用哪些RLOC。PITR向全局路由表公布EID前缀的聚合，并为它们提供隧道服务，以便非LISP站点可以到达LISP站点。PETR为LISP站点提供了一种向非LISP站点发送流量的方法。
LISP is a complex protocol if only used for tunneling. Features of LISP are that ETRs can advertise their own RLOC addresses, that one site can have multiple xTRs with independent RLOCs, and that the LISP site administrator can specify priorities and weights for those RLOCs. This provides redundancy and explicit load balancing between RLOCs. It also allows for automatic tunneling between different sites without using a PxTR if both sites use Map Servers and Map Resolvers that are interconnected, for example, by participating in the LISP Beta Network [LISPBETA]. To facilitate these interconnections, the LISP Delegated Database Tree (DDT) system is available.
如果仅用于隧道，LISP是一个复杂的协议。LISP的特点是ETR可以公布自己的RLOC地址，一个站点可以有多个具有独立RLOC的XTR，LISP站点管理员可以指定这些RLOC的优先级和权重。这在RLOC之间提供了冗余和显式负载平衡。如果两个站点都使用相互连接的地图服务器和地图解析器（例如，通过参与LISP Beta网络[LISPBETA]），则它还允许在不同站点之间进行自动隧道，而不使用PxTR。为了促进这些互连，可以使用LISP委托数据库树（DDT）系统。
LISP is implemented on most Cisco devices. There are implementations available for FreeBSD and Linux, as well as a platform-independent implementation in the Python programming language. Note that for LISP to work, a mapping service not unlike the DNS must be in place.
LISP在大多数Cisco设备上实现。有针对FreeBSD和Linux的实现，以及Python编程语言中的独立于平台的实现。请注意，为了使LISP正常工作，必须提供与DNS不同的映射服务。
The Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL] (along with its companion technologies cited therein) provides a hybrid configured/automatic tunneling system. SEAL itself provides a mid-layer of encapsulation between the inner IPv6 header and the outer IPv4 header, i.e., as IPv4-SEAL-IPv6. SEAL can also be used in conjunction with an outer UDP encapsulation header, e.g., if NAT traversal is necessary.
子网络封装和适配层（SEAL）[SEAL]（以及其中引用的配套技术）提供了一个混合配置/自动隧道系统。SEAL本身在内部IPv6报头和外部IPv4报头之间提供了中间层封装，即作为IPv4-SEAL-IPv6。SEAL还可以与外部UDP封装头一起使用，例如，如果需要NAT遍历。
The SEAL tunnel endpoint creates bidirectional configured tunnels to reach default IPv6 routers, and it discovers unidirectional automatic tunnels. SEAL tunnels can be configured over multiple underlying IPv4 links whether the addresses are provisioned from public or private IPv4 addressing domains. In that case, multihoming and traffic engineering are naturally supported.
SEAL tunnel端点创建双向配置的隧道以到达默认IPv6路由器，并发现单向自动隧道。无论地址是从公共或私有IPv4寻址域提供的，都可以在多个基础IPv4链路上配置密封隧道。在这种情况下，自然支持多主和流量工程。
SEAL provides an optional 32-bit identifier and variable-length Integrity Check Vector that can be used for packet identification, message origin authentication, anti-replay, and a mid-layer segmentation and reassembly capability. SEAL also provides a SEAL Control Message Protocol (SCMP) used for neighbour coordinations between tunnel endpoints. These coordinations are used for functions such as tunnel MTU signalling, route optimisations, neighbour reachability testing, and so on.
SEAL提供可选的32位标识符和可变长度完整性检查向量，可用于数据包标识、消息源身份验证、反重放以及中间层分段和重新组装功能。SEAL还提供了用于隧道端点之间相邻协调的SEAL控制消息协议（SCMP）。这些协调用于隧道MTU信令、路由优化、邻居可达性测试等功能。
SEAL ensures that packets that are no larger than 1500 bytes can be transported through the tunnel by using a tunnel segmentation function. IPv6 packets that are too large to transport through the tunnel whole are split into segments. The segments are encapsulated in IPv4 and reassembled into the original IPv6 packets at the remote
SEAL通过使用隧道分段功能确保不超过1500字节的数据包可以通过隧道传输。太大而无法通过整个隧道传输的IPv6数据包被分成多个段。这些段被封装在IPv4中，并在远程重新组装到原始IPv6数据包中
tunnel endpoint. SEAL also admits packets larger than 1500 bytes into the tunnel on a best-effort basis in case the path between the tunnel endpoints can support the larger size.
隧道端点。如果隧道端点之间的路径可以支持较大的数据包大小，SEAL也会尽最大努力将大于1500字节的数据包放入隧道。
When SEAL is used alone without its companion technologies, it can be used in the same scenarios as for GRE. However, SEAL provides advanced capabilities that make it better suited than GRE for many use cases. There is currently an experimental open-source implementation of SEAL.
如果单独使用SEAL而不使用其配套技术，则可以在与GRE相同的场景中使用SEAL。然而，SEAL提供了先进的功能，使其比GRE更适合许多用例。目前有一个实验性的SEAL开源实现。
The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any Internetwork" [6BED4]. A specific goal of 6bed4 is to achieve direct communication between peers when the intermediate infrastructure does not prohibit it. The advantage of direct communication is to get a performance level similar to IPv4. The address of a 6bed4 peer is formed from the publicly visible IPv4 address and UDP port. The tunnel service used for fallback connectivity can run anywhere -- perhaps at the local ISP or with a third-party service provider for 6bed4, or even on a well-known address. It is currently an NBMA protocol; there are openings for expansion with multicast.
6bed4隧道在“6bed4:Any Internetwork上的对等IPv6”[6bed4]中指定。6bed4的一个具体目标是在中间基础设施不禁止的情况下实现对等点之间的直接通信。直接通信的优点是获得类似于IPv4的性能级别。6bed4对等方的地址由公开可见的IPv4地址和UDP端口组成。用于回退连接的隧道服务可以在任何地方运行——可能在本地ISP或与第三方服务提供商（针对6bed4）一起运行，甚至可以在已知地址上运行。它目前是一个NBMA协议；通过多播可以进行扩展。
The setup of 6bed4 is somewhat similar to 6to4, except that it employs UDP so it can be used behind NAT. It also has elements found in Teredo but without a need to classify NATs and induce behaviour from that. The 6bed4 tunnel makes no assumptions about the capabilities of NAT devices beyond being able to do straightforward NAT on UDP packets. Given this, 6bed4 can create reliable IPv6 tunnels.
6bed4的设置与6to4有些相似，只是它使用UDP，因此可以在NAT后面使用。它也有在Teredo中发现的元素，但不需要对NAT进行分类并由此诱导行为。除了能够在UDP数据包上直接进行NAT外，6bed4隧道对NAT设备的功能没有任何假设。有鉴于此，6bed4可以创建可靠的IPv6隧道。
In environments where direct connections between 6bed4 peers are possible, additional path stretch compared to IPv4 communication is avoided, so 6bed4 performance comes close to IPv4 performance. In situations where it is not possible to run over the direct path between two peers because a NAT that does not conform to [RFC4787] is on the path, a fallback to a tunnel server is used. This increases path stretch and affects scalability through its impact on roundtrip times and jitter.
在6bed4对等方之间可以直接连接的环境中，与IPv4通信相比，避免了额外的路径扩展，因此6bed4性能接近IPv4性能。在由于路径上存在不符合[RFC4787]的NAT而无法在两个对等方之间的直接路径上运行的情况下，将使用回退到隧道服务器。这增加了路径拉伸，并通过影响往返时间和抖动来影响可伸缩性。
Another area where the tunnel server is needed is for connectivity between 6bed4 peers and native IPv6 hosts. For reasons of performance and scalability, connections between 6bed4 peers are preferred over connections between a 6bed4 peer and a native IPv6 host. A default address exists to support zero-config operation, but it is possible to locally configure a tunnel server as a fallback route, which then also defines the tunnel server for the return path.
另一个需要隧道服务器的领域是6bed4对等方和本机IPv6主机之间的连接。出于性能和可扩展性的原因，6bed4对等机之间的连接优先于6bed4对等机和本机IPv6主机之间的连接。存在支持零配置操作的默认地址，但可以将隧道服务器本地配置为回退路由，然后还可以为返回路径定义隧道服务器。
6bed4 has been specifically designed to support real-time interactive traffic streams, such as SIP calls, between 6bed4-supporting end points, assuming that each prefers 6bed4-to-6bed4 traffic over 6bed4- to-native traffic. Under that premise, the only hosts that need to go through a tunnel server are those that are behind a NAT with Address-Dependent Mapping or Address and Port-Dependent Mapping. A number of different implementations of 6bed4 have been constructed [6BED4] during the ongoing development of its specification.
6bed4专门设计用于支持6bed4支持端点之间的实时交互流量流，如SIP呼叫，假设每个端点都更喜欢6bed4到6bed4流量，而不是6bed4到本机流量。在此前提下，需要通过隧道服务器的主机只有那些位于NAT后面的主机，这些主机具有地址依赖映射或地址和端口依赖映射。在规范的持续开发过程中，已经构建了许多不同的6bed4实现[6bed4]。
The following protocols are not tunnel mechanisms, but they can be used in the configuration and/or setup phase of such protocols.
以下协议不是隧道机制，但可用于此类协议的配置和/或设置阶段。
The Tunnel Setup Protocol [RFC5572] specifies a protocol for negotiating the setup of a variety of tunnel encapsulations. In this document, we are only interested in the encapsulation of IPv6 in IPv4. The Tunnel Setup Protocol can negotiate these as a protocol 41 encapsulated tunnel or as a UDP-encapsulated tunnel. The tunnel negotiation is performed as an XML exchange over UDP or TCP.
隧道设置协议[RFC5572]规定了协商各种隧道封装设置的协议。在本文档中，我们只对IPv4中IPv6的封装感兴趣。隧道设置协议可以将它们协商为协议41封装隧道或UDP封装隧道。隧道协商作为UDP或TCP上的XML交换执行。
As a TSP client exchanges all IPv6 traffic with the same tunnel server, there are no concerns caused by NAT implementations. The only concern is to send regular keepalives, for which ICMPv6 ping messages to the tunnel server are suggested. When encapsulating IPv6 packets directly in IPv4, all protocol 41 limitations apply. To avoid these, an additional UDP header may be used.
由于TSP客户端与同一个隧道服务器交换所有IPv6流量，因此NAT实现不会引起任何问题。唯一需要考虑的是发送常规的keepalives，建议将ICMPv6 ping消息发送到隧道服务器。在IPv4中直接封装IPv6数据包时，所有协议41限制都适用。为了避免这些情况，可以使用额外的UDP报头。
The Tunnel Setup Protocol treats all protocols and ports for one IPv4 client address as equivalent. This suffices when protocol 41 is used, but for UDP it creates a situation where one user can set up a tunnel behind NAT, and another user could hijack the tunnel privileges.
隧道设置协议将一个IPv4客户端地址的所有协议和端口视为等效的。当使用协议41时，这就足够了，但对于UDP，它会造成一种情况，即一个用户可以在NAT后面建立一个隧道，而另一个用户可以劫持隧道权限。
Open-source clients for the Tunnel Setup Protocol and a matching tunnel infrastructure are provided from the Freenet6 tunnel service [GOGO6].
Freenet6隧道服务[GOGO6]提供了隧道设置协议的开源客户端和匹配的隧道基础设施。
The SixXS Heartbeat Protocol [HEARTBEAT] allows nodes that have intermittent connectivity or a dynamic IPv4 address that changes from time to time to have continuing tunneled IPv6 connectivity. One of the goals of the protocol is to determine when a node is no longer present at its previous IPv4 address and then stop sending tunneled packets to prevent them from being delivered to the wrong node. The
SixXS心跳协议[Heartbeat]允许具有间歇性连接或动态IPv4地址（不时更改）的节点具有持续的隧道式IPv6连接。该协议的目标之一是确定节点何时不再位于其以前的IPv4地址，然后停止发送隧道数据包，以防止它们被传递到错误的节点。这个
Heartbeat Protocol then allows a tunnel broker to determine a client's new IPv4 address and continue sending tunneled packets with minimal interruption.
然后，心跳协议允许隧道代理确定客户端的新IPv4地址，并以最小的中断继续发送隧道数据包。
To accomplish this, a node sends periodic heartbeat packets to the tunnel broker. If the tunnel broker fails to receive valid heartbeat packets, it shuts down the tunnel in question. Heartbeat packets contain an MD5 message authentication code and a timestamp to avoid replay attacks. The Heartbeat Protocol can work with different tunnel mechanisms, but it is often used with configured tunnels (Section 3.1).
为此，节点向隧道代理发送周期性心跳数据包。如果隧道代理无法接收有效的心跳数据包，它将关闭有问题的隧道。心跳数据包包含MD5消息身份验证代码和时间戳，以避免重播攻击。Heartbeat协议可以使用不同的隧道机制，但它通常用于已配置的隧道（第3.1节）。
The protocol is implemented in the SixXS tunnel broker; client implementations are available for common operating systems. AYIYA can be considered the successor of the Heartbeat Protocol.
该协议在SixXS隧道代理中实现；客户端实现可用于通用操作系统。AYIYA可以被认为是心跳协议的继承者。
The Tunnel Information and Control (TIC) protocol [TIC] is the setup protocol for the [SIXXS] tunnel-broker service.
隧道信息和控制（TIC）协议[TIC]是[SIXXS]隧道代理服务的设置协议。
With the TIC protocol, a tunnel-broker user can request a list of available tunnels and points of presence (POPs) from the tunnel-broker service. When the user chooses one of the tunnels, the configuration parameters for that tunnel can then be requested through TIC. TIC also provides commands to control the tunnel, for example, to change the tunnel endpoints or to enable or disable the tunnel.
通过TIC协议，隧道代理用户可以从隧道代理服务请求可用隧道和存在点（POP）的列表。当用户选择其中一个隧道时，可通过TIC请求该隧道的配置参数。TIC还提供控制隧道的命令，例如更改隧道端点或启用或禁用隧道。
Authentication of users is done based on username and password. Certain tunnel mechanisms, such as AYIYA (Section 3.6) and configured tunnels (Section 3.1) with heartbeat (Section 4.2), need a synchronised clock between the tunnel server and the client. TIC facilitates this by providing a server timestamp on request. The client can use that to verify that its clock is synchronised with the server and show an error message to the user if it is not.
根据用户名和密码对用户进行身份验证。某些隧道机制，如AYIYA（第3.6节）和配置了心跳信号的隧道（第3.1节）（第4.2节），在隧道服务器和客户端之间需要同步时钟。TIC通过在请求时提供服务器时间戳来实现这一点。客户端可以使用它来验证其时钟是否与服务器同步，如果不同步，则向用户显示错误消息。
The TIC protocol is implemented in the AICCU client software (see [AICCU]) and in AVM Fritz!Box home routers.
TIC协议在AICCU客户端软件（参见[AICCU]）和AVM Fritz中实现！盒子家庭路由器。
The following are aspects common to many or all tunnel mechanisms.
以下是许多或所有隧道机制的共同方面。
The most straightforward way to encapsulate an IPv6 packet inside an IPv4 packet is by simply adding an IPv4 header in front of the IPv6 header. In this case, the Protocol field in the IPv4 header is set to the value 41. This encapsulation is also known as "IPv6 in IPv4" and "IP6 Encapsulation".
将IPv6数据包封装到IPv4数据包中最简单的方法是在IPv6数据包头之前添加一个IPv4数据包头。在这种情况下，IPv4报头中的协议字段设置为值41。这种封装也称为“IPv4中的IPv6”和“IP6封装”。
This simple "protocol 41" encapsulation is used by a number of tunnel mechanisms:
许多隧道机制都使用这种简单的“协议41”封装：
configured tunnels (Section 3.1)
配置隧道（第3.1节）
automatic tunneling (Section 3.2)
自动掘进（第3.2节）
6over4 (Section 3.3)
6概述4（第3.3节）
6to4 (Section 3.5)
6to4（第3.5节）
ISATAP (Section 3.7)
ISATAP（第3.7节）
6rd (Section 3.9)
第6条（第3.9节）
It is not uncommon for NATs and firewalls to block protocol 41 encapsulated packets, especially at the boundary between an organisation's internal network and the public Internet. Tunnel mechanisms that don't use protocol 41 encapsulation typically employ a UDP header and are somewhat less likely to be filtered, assuming that tunneling is initiated on the LAN side. UDP is usually subjected to Network Address Port Translation (NAPT) [RFC2663], which additionally translates between internal and external port numbers. (Often, the term "NAT" is used where "NAPT" may be more appropriate.)
NAT和防火墙拦截协议41封装的数据包并不少见，尤其是在组织内部网络和公共互联网之间的边界。不使用协议41封装的隧道机制通常采用UDP报头，并且假设隧道是在LAN端启动的，则不太可能被过滤。UDP通常需要进行网络地址端口转换（NAPT）[RFC2663]，这还需要在内部和外部端口号之间进行转换。（通常，在“NAPT”可能更合适的地方使用术语“NAT”。）
Although protocol 41 can in principle work through NAT, there are two issues. First, when the IPv6 address is derived from the IPv4 address (see Section 5.4), NATing of the outer IPv4 header breaks the relationship between the IPv4 and IPv6 addresses. Second, because protocol 41 does not use port numbers, the number of protocol 41 tunnel endpoints that can be supported behind a NAT device is equal to its number of external IPv4 addresses (see Section 6.1). This limitation also applies to GRE.
虽然协议41原则上可以通过NAT工作，但有两个问题。首先，当IPv6地址是从IPv4地址派生的（请参见第5.4节）时，外部IPv4报头的本地设置会中断IPv4和IPv6地址之间的关系。其次，由于协议41不使用端口号，NAT设备后面可支持的协议41隧道端点的数量等于其外部IPv4地址的数量（请参见第6.1节）。这一限制也适用于GRE。
Tunnels that pass through a NAT device or stateful firewall need to generate traffic at regular intervals to refresh the NAT or firewall mapping. If the mapping is lost, tunneled packets from the outside won't be able to pass through the NAT or firewall until a system behind the NAT or firewall sends a tunneled packet and the mapping is re-created. Alternatively, a static mapping (often in the form of a "default" or "DMZ" host) may be configured manually.
通过NAT设备或有状态防火墙的隧道需要定期生成流量以刷新NAT或防火墙映射。如果映射丢失，则来自外部的隧道数据包将无法通过NAT或防火墙，直到NAT或防火墙后面的系统发送隧道数据包并重新创建映射。或者，可以手动配置静态映射（通常以“默认”或“DMZ”主机的形式）。
The following tunnel mechanisms are incompatible with NAT because their addresses must be derived from a globally unique IPv4 address:
以下隧道机制与NAT不兼容，因为它们的地址必须从全局唯一的IPv4地址派生：
automatic tunneling (Section 3.2)
自动掘进（第3.2节）
6to4 (Section 3.5)
6to4（第3.5节）
6rd (Section 3.9)
第6条（第3.9节）
LISP (Section 3.11)
LISP（第3.11节）
Note that it is common to run 6to4 or 6rd on a home gateway device that also performs IPv4 NAT. In this configuration, NAT is not applied to tunneled packets, so NAT and 6to4/6rd can coexist.
请注意，在同时执行IPv4 NAT的家庭网关设备上运行6to4或6rd是常见的。在此配置中，NAT不应用于隧道数据包，因此NAT和6to4/6rd可以共存。
The following tunnel mechanisms cannot operate between nodes on opposing sides of a NAT, but they do work if _all_ nodes are behind a NAT (where RFC 1918 addresses are often used):
以下隧道机制无法在NAT相对侧的节点之间运行，但如果所有节点都位于NAT后面（通常使用RFC 1918地址），则它们确实可以工作：
6over4 (Section 3.3)
6概述4（第3.3节）
ISATAP (Section 3.7)
ISATAP（第3.7节）
The following tunnel mechanisms may work through NAT in some circumstances, but are not designed for NAT compatibility:
在某些情况下，以下隧道机制可能通过NAT工作，但不是为NAT兼容性而设计的：
configured tunnels (Section 3.1)
配置隧道（第3.1节）
GRE (Section 3.4)
GRE（第3.4节）
The following tunnel mechanisms are designed for NAT compatibility:
以下隧道机制设计用于NAT兼容性：
AYIYA (Section 3.6)
AYIYA（第3.6节）
Teredo (Section 3.8); but it is unreliable
Teredo（第3.8节）；但这是不可靠的
6a44 (Section 3.10)
6a44（第3.10节）
SEAL (Section 3.12)
密封（第3.12节）
6bed4 (Section 3.13)
6bed4（第3.13节）
The LISP specification requires that locator addresses (the addresses in the outer IPv4 header) are globally routable public addresses.
LISP规范要求定位器地址（外部IPv4报头中的地址）是全局可路由的公共地址。
A tunnel built over UDP makes a claim on a resource, namely, an external UDP port. This may impact how well a tunnel will scale in an organisation; for instance, if every desktop runs its own tunnel client over UDP, then the claim on this resource may have some impact.
基于UDP构建的隧道声明资源，即外部UDP端口。这可能会影响隧道在组织中的规模；例如，如果每个桌面都通过UDP运行自己的隧道客户端，那么对该资源的声明可能会产生一些影响。
Note that ISPs may have multiple subscribers share a public IPv4 address by performing NAT (Carrier-Grade NAT in this context). In this case, the subscribers' home gateways may receive an address in the 100.64.0.0/10 block [RFC6598]. For the purposes of tunnel mechanisms, this address block is similar to the RFC 1918 address blocks. However, tunnel implementations that are aware of NAT and RFC 1918 addresses may not recognise 100.64.0.0/10 as non-public addresses and fail to operate successfully. The same issue is present if an ISP decides to use regular global unicast IPv4 address space behind a CGN.
请注意，ISP可能通过执行NAT（在此上下文中为运营商级NAT）让多个订户共享一个公共IPv4地址。在这种情况下，订户的家庭网关可以接收100.64.0.0/10块[RFC6598]中的地址。出于隧道机制的目的，该地址块类似于RFC1918地址块。但是，知道NAT和RFC1918地址的隧道实现可能无法将100.64.0.0/10识别为非公共地址，并且无法成功运行。如果ISP决定在CGN后面使用常规全局单播IPv4地址空间，则会出现相同的问题。
Because of the extra IPv4 header and possible additional headers between the IPv4 and IPv6 headers, tunnels experience a reduced maximum packet size (MTU) compared to native IPv6 communication.
由于额外的IPv4报头以及IPv4和IPv6报头之间可能存在的额外报头，与本机IPv6通信相比，隧道的最大数据包大小（MTU）减小。
Path MTU discovery (PMTUD) should handle this in nearly all cases, but filtering of ICMPv6 "packet too big" messages may lead to an inability to communicate because senders of large packets fail to perform PMTUD successfully. However, when a tunnel terminates directly on the host using it, the TCP maximum segment size (MSS) option communicates the maximum packet size to the remote endpoint, so TCP-based communication may still succeed. If not, the initial TCP SYN/ACK exchange happens without issue, but then the session stalls as the larger packets containing data are lost.
路径MTU发现（PMTUD）应在几乎所有情况下处理此问题，但对ICMPv6“数据包太大”消息的过滤可能会导致无法通信，因为大数据包的发送方无法成功执行PMTUD。但是，当隧道直接在使用它的主机上终止时，TCP最大段大小（MSS）选项将最大数据包大小传递给远程端点，因此基于TCP的通信仍然可能成功。如果不是，则初始TCP SYN/ACK交换不会出现问题，但由于包含数据的较大数据包丢失，会话会暂停。
With tunnel mechanisms where the MTU is left unspecified, it is possible for the two endpoints to have different MTUs: typically, one uses the IPv6 minimum (1280 bytes), while the other uses the physical MTU minus tunnel overhead (often 1480 bytes). In theory, this should lead to PMTUD failures because the "big" side unknowingly sends packets that the "small" side can't handle. However, in practice, implementations handle incoming packets larger than their own MTU without issue.
对于未指定MTU的隧道机制，两个端点可能具有不同的MTU：通常，一个使用IPv6最小值（1280字节），而另一个使用物理MTU减去隧道开销（通常为1480字节）。理论上，这会导致PMTUD失败，因为“大”端在不知不觉中发送“小”端无法处理的数据包。然而，在实践中，实现处理比自己的MTU更大的传入数据包时不会出现问题。
Only when the IPv4 MTU is reduced below 1500 bytes, for instance, when using PPP over Ethernet (PPPoE, [RFC2516]), issues are more likely to arise. So, when the possibility exists that tunneled packets encounter a PPPoE link, it is prudent to set the MTU of a tunnel to no more than 1472 bytes, so that tunneled packets don't have to be fragmented. Additionally, Section 3.2.1 of [RFC4213] recommends limiting the MTU of tunnels to a minimum of 1280 bytes.
只有当IPv4 MTU减少到1500字节以下时，例如，当使用以太网PPP（PPPoE，[RFC2516]），问题才更有可能出现。因此，当隧道包遇到PPPoE链路的可能性存在时，谨慎的做法是将隧道的MTU设置为不超过1472字节，这样隧道包就不必分段。此外，[RFC4213]第3.2.1节建议将隧道的MTU限制为至少1280字节。
SEAL was specifically designed to overcome these limitations by adding the capability to fragment IPv6 packets prior to encapsulation in IPv4 and then to reassemble the fragments at the remote tunnel endpoint. This way, the SEAL tunnel ensures that packets that are no larger than 1500 bytes will be transported to the tunnel far end even if there are restricting links in the path. SEAL can also admit larger packets into the tunnel on a best-effort basis in case the path between the tunnel endpoints can support this larger size.
SEAL是专门为克服这些限制而设计的，它添加了在IPv4封装之前对IPv6数据包进行分段的功能，然后在远程隧道端点重新组装这些分段。这样，即使路径中存在限制链路，SEAL隧道也确保不大于1500字节的数据包将被传输到隧道远端。如果隧道端点之间的路径能够支持较大的数据包，SEAL还可以尽最大努力将较大的数据包引入隧道。
Many tunnel mechanisms embed IPv4 addresses or further information in the IPv6 addresses they use. There are two possible reasons for this. First, with an IPv4 address embedded in the IPv6 address, the outer IPv4 header can be derived without a need to explicitly configure tunnel endpoints. Automatic tunneling, 6to4, ISATAP, 6bed4, and Teredo do this. 6over4 embeds the IPv4 address for the second reason; it is embedded in the Interface Identifier and thus the IPv6 address because, that way, a (presumably) globally unique Interface Identifier can be generated.
许多隧道机制在它们使用的IPv6地址中嵌入IPv4地址或其他信息。这可能有两个原因。首先，通过在IPv6地址中嵌入IPv4地址，可以派生外部IPv4报头，而无需显式配置隧道端点。自动隧道，6to4，ISATAP，6bed4，和Teredo这样做。6over4出于第二个原因嵌入IPv4地址；它被嵌入到接口标识符中，从而嵌入到IPv6地址中，因为这样可以生成（大概）全局唯一的接口标识符。
Automatic tunneling uses IPv4-compatible addresses in the prefix ::/96 (i.e., the first 96 bits are all zero).
自动隧道使用前缀中与IPv4兼容的地址：：/96（即，前96位均为零）。
| 96 bits | 32 |
+------------------------------------------------+-----------------+
| 0:0:0:0:0:0 | IPv4 address |
+------------------------------------------------+-----------------+
| 96 bits | 32 |
+------------------------------------------------+-----------------+
| 0:0:0:0:0:0 | IPv4 address |
+------------------------------------------------+-----------------+
The IPv4-Compatible Address Structure
IPv4兼容的地址结构
Systems running 6to4 have addresses in the 6to4 prefix 2002::/16.
运行6to4的系统的地址在6to4前缀2002:：/16中。
| 16 bits | 32 | 16 | 64 |
+---------+----------------+--------+------------------------------+
| 2002 | IPv4 address | Subnet | Interface ID |
+---------+----------------+--------+------------------------------+
| 16 bits | 32 | 16 | 64 |
+---------+----------------+--------+------------------------------+
| 2002 | IPv4 address | Subnet | Interface ID |
+---------+----------------+--------+------------------------------+
The 6to4 Address Structure
6to4地址结构
Because a 6rd domain might share a common IPv4 prefix, it is not always necessary to encode all 32 bits of the IPv4 address in the 6rd delegated prefix. The bits that become available because of this optimisation can be used to provide more subnet IDs to the user and/or to use a smaller address block for the 6rd prefix.
因为第6个域可能共享一个公共IPv4前缀，所以并不总是需要在第6个委派前缀中对IPv4地址的所有32位进行编码。由于这种优化而变得可用的位可用于向用户提供更多的子网ID和/或为第6个前缀使用更小的地址块。
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+-----------------------+
| 6rd prefix | IPv4 prefix | Subnet ID | Interface ID |
+---------------+--------------+-----------+-----------------------+
|<--- 6rd delegated prefix --->|
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+-----------------------+
| 6rd prefix | IPv4 prefix | Subnet ID | Interface ID |
+---------------+--------------+-----------+-----------------------+
|<--- 6rd delegated prefix --->|
The 6rd Address Structure
第六地址结构
6over4 uses the IPv4 address to generate a 64-bit Interface Identifier, which can then be used to create a 128-bit IPv6 address through Stateless Address Autoconfiguration.
6over4使用IPv4地址生成64位接口标识符，然后可通过无状态地址自动配置使用该标识符创建128位IPv6地址。
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | 0:0 | IPv4 address |
+---------------------+--------+-----------------+-----------------+
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | 0:0 | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The 6over4 Address Structure
6over4地址结构
The ISATAP address structure is similar to the 6over4 address structure, except that the unique/local (u) bit signifies whether the IPv4 address in the Interface Identifier is unique. Presumably, this is the case for any IPv4 address that is not as defined in RFC 1918. The group (g) bit is set to zero, and the remaining bits are set to 0x00005EFE.
ISATAP地址结构类似于6over4地址结构，只是唯一/本地（u）位表示接口标识符中的IPv4地址是否唯一。据推测，对于RFC1918中未定义的任何IPv4地址都是如此。组（g）位设置为零，其余位设置为0x00005EFE。
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | ug00:5EFE | IPv4 address |
+---------------------+--------+-----------------+-----------------+
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | ug00:5EFE | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The ISATAP Address Structure
ISATAP地址结构
Teredo embeds the Teredo server's IPv4 address, a number of flags, and a UDP port number, as well as the Teredo client's IPv4 address in the IPv6 addresses it creates. For good measure, the UDP port and client IPv4 address are "obfuscated" by flipping their bits.
Teredo将Teredo服务器的IPv4地址、多个标志和UDP端口号以及Teredo客户端的IPv4地址嵌入到它创建的IPv6地址中。为了更好地衡量，UDP端口和客户端IPv4地址通过翻转位进行“模糊处理”。
| 32 bits | 32 | 16 | 16 | 32 |
+----------------+---------------+-------+-------+-----------------+
| 2001:0 | Server IPv4 | Flags | Port | Client IPv4 |
+----------------+---------------+-------+-------+-----------------+
| 32 bits | 32 | 16 | 16 | 32 |
+----------------+---------------+-------+-------+-----------------+
| 2001:0 | Server IPv4 | Flags | Port | Client IPv4 |
+----------------+---------------+-------+-------+-----------------+
The Teredo Address Structure
Teredo地址结构
6a44 can be seen as a combination of 6rd and Teredo. The 6a44 prefix is given out by an ISP. Both the customer site (home gateway) IPv4 address as well as the host's/client's RFC 1918 IPv4 address and a port number are embedded in the IPv6 address.
6a44可以看作是6rd和Teredo的组合。6a44前缀由ISP提供。客户站点（家庭网关）IPv4地址以及主机/客户端的RFC 1918 IPv4地址和端口号都嵌入到IPv6地址中。
| 48 bits | 32 | 16 | 32 |
+----------------------+-----------------+-------+-----------------+
| 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 |
+----------------------+-----------------+-------+-----------------+
| 48 bits | 32 | 16 | 32 |
+----------------------+-----------------+-------+-----------------+
| 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 |
+----------------------+-----------------+-------+-----------------+
The 6a44 Address Structure
6a44地址结构
6bed4 embeds two combinations of an IPv4 address and UDP port (together acting as a "6bed4 address") in the IPv6 address. The first address is for a tunnel server that everyone is certain to reach; the other is for the direct address that most peers should be able to reach directly. The tunnel server, however, is the only one with guaranteed access to the direct address.
6bed4在IPv6地址中嵌入IPv4地址和UDP端口的两种组合（一起充当“6bed4地址”）。第一个地址是每个人都一定会到达的隧道服务器；另一个是大多数对等方应该能够直接访问的直接地址。然而，隧道服务器是唯一一个保证直接地址访问的服务器。
| 32 bits | 32 | 50 | 14 |
+----------+---------------------+-------------------------+-------+
| prefix |general 6bed4 address| direct 6bed4 address | lanIP |
+----------+---------------------+-------------------------+-------+
| 32 bits | 32 | 50 | 14 |
+----------+---------------------+-------------------------+-------+
| prefix |general 6bed4 address| direct 6bed4 address | lanIP |
+----------+---------------------+-------------------------+-------+
The 6bed4 Address Structure
6bed4地址结构
The general 6bed4 address field conceals the well-known UDP port for the 6bed4 service. The direct 6bed4 address field includes two extra bits to adhere to the EUI-64 address format. The lanIP bits are free for local purposes, such as creating a DHCPv6 range.
general 6bed4 address字段隐藏6bed4服务的已知UDP端口。direct 6bed4地址字段包括两个附加位，以符合EUI-64地址格式。lanIP位对于本地用途是免费的，例如创建DHCPv6范围。
The following subsections deal with various aspects of tunnels that guide their selection.
以下小节介绍了指导其选择的隧道的各个方面。
With the depletion of the IPv4 address space, the ability to deploy a tunnel mechanism behind NAT as well as the number of IPv6 subscribers, subnets, and individual hosts that can be supported behind a single IPv4 address have become important considerations.
随着IPv4地址空间的耗尽，在NAT后面部署隧道机制的能力以及在单个IPv4地址后面可以支持的IPv6订户、子网和单个主机的数量已成为重要的考虑因素。
These issues are irrelevant to tunnel mechanisms that provide IPv6 connectivity between hosts within the same administrative domain, such as ISATAP or 6over4, as they can use private IPv4 addresses. This is also true for 6rd; it is used between an ISP and its customers' home gateways when the ISP has implemented NAT.
这些问题与在同一管理域内的主机（如ISATAP或6over4）之间提供IPv6连接的隧道机制无关，因为它们可以使用专用IPv4地址。第六次也是如此；当ISP实现NAT时，它用于ISP与其客户的家庭网关之间。
6to4 cannot work behind any kind of NAT. Most other mechanisms based on protocol 41 can work behind NAT, at least in principle. In practice, this difference is not as big because the protocol 41 encapsulation doesn't provide any fields that allow a NAT to demultiplex tunneled packets. This means that only a single protocol 41 tunnel endpoint can be supported for each public IPv4 address.
6to4不能在任何NAT后面工作。基于协议41的大多数其他机制至少在原则上可以在NAT后面工作。在实践中，这种差异并没有那么大，因为协议41封装没有提供任何允许NAT对隧道数据包进行多路复用的字段。这意味着每个公共IPv4地址只能支持一个协议41隧道端点。
This makes configured tunnels (as well as 6to4) incompatible with service-provider-operated NATs, where multiple subscribers share an IPv4 address.
这使得配置的隧道（以及6to4）与服务提供商操作的NAT不兼容，其中多个订户共享一个IPv4地址。
Teredo, 6a44, 6bed4, AYIYA, SEAL, and TSP are designed to work through NATs and use a UDP header, so multiple tunnel endpoints can be hosted behind a single IPv4 address. On the other hand, Teredo only provides IPv6 connectivity to a single host.
Teredo、6a44、6bed4、AYIYA、SEAL和TSP设计用于通过NAT工作并使用UDP报头，因此可以在单个IPv4地址后面承载多个隧道端点。另一方面，Teredo只提供到单个主机的IPv6连接。
The following table shows how many IPv4 addresses each tunnel mechanism requires and how many IPv6 hosts it can connect. The mechanisms are listed in order of increasing numbers of supported IPv6 hosts per IPv4 address.
下表显示了每个隧道机制需要多少IPv4地址以及它可以连接多少IPv6主机。这些机制按每个IPv4地址支持的IPv6主机数量的增加顺序列出。
+------------+-------------+-------------+-------------+------------+
| Mechanism | Tunnels per | IPv6 hosts | Public IPv4 | NAT |
| | IPv4 addr. | per tunnel | address | compatible |
+------------+-------------+-------------+-------------+------------+
| Auto. tun. | one | one | required | no |
| 6to4 | one | multiple | required | no |
| LISP | one | multiple | required | no |
| 6rd | one | multiple | not needed | no |
| Conf. tun. | one | multiple | not needed | limited |
| GRE | one | multiple | not needed | limited |
| Teredo | multiple | one | not needed | yes (*) |
| 6bed4 | multiple | multiple | not needed | yes |
| 6a44 | multiple | multiple | not needed | yes |
| AYIYA | multiple | multiple | not needed | yes |
| SEAL | multiple | multiple | not needed | yes |
+------------+-------------+-------------+-------------+------------+
+------------+-------------+-------------+-------------+------------+
| Mechanism | Tunnels per | IPv6 hosts | Public IPv4 | NAT |
| | IPv4 addr. | per tunnel | address | compatible |
+------------+-------------+-------------+-------------+------------+
| Auto. tun. | one | one | required | no |
| 6to4 | one | multiple | required | no |
| LISP | one | multiple | required | no |
| 6rd | one | multiple | not needed | no |
| Conf. tun. | one | multiple | not needed | limited |
| GRE | one | multiple | not needed | limited |
| Teredo | multiple | one | not needed | yes (*) |
| 6bed4 | multiple | multiple | not needed | yes |
| 6a44 | multiple | multiple | not needed | yes |
| AYIYA | multiple | multiple | not needed | yes |
| SEAL | multiple | multiple | not needed | yes |
+------------+-------------+-------------+-------------+------------+
Tunneled IPv6 Hosts per IPv4 Address
每个IPv4地址的隧道IPv6主机
(*) Although Teredo is designed for NAT compatibility, it doesn't work through all existing NATs.
（*）尽管Teredo是为NAT兼容性而设计的，但它并不适用于所有现有的NAT。
There are two ways to use an IPv6-in-IPv4 tunnel to connect to the IPv6 Internet: using a point-to-point tunnel to a tunnel broker or an ISP-operated gateway, or using a Non-Broadcast Multi-Access (NBMA) tunnel and anycasted public gateways or relays.
使用IPv4隧道中的IPv6连接到IPv6 Internet有两种方法：使用到隧道代理或ISP操作的网关的点对点隧道，或使用非广播多址（NBMA）隧道和任意广播的公共网关或中继。
The advantages of the point-to-point model are predictable performance and flexibility regarding the IPv6 addresses used. The advantage of the NBMA model is that traffic between two hosts or networks that both use the mechanism can flow directly without passing through a gateway (direct peer-to-peer communication). An extra advantage of the NBMA model with public gateways is automatic configuration and no involvement from an ISP.
点到点模型的优点是可预测的性能和所用IPv6地址的灵活性。NBMA模型的优点是，使用该机制的两台主机或网络之间的流量可以直接流动，而无需通过网关（直接对等通信）。带有公共网关的NBMA模型的一个额外优势是自动配置，并且没有ISP的参与。
Unfortunately, the advantages of this NBMA public anycast model come at a price: both the peer-to-peer connectivity between tunnel users and the connectivity towards the native IPv6 Internet may suffer from reliability and performance issues.
不幸的是，这种NBMA公共选播模式的优势是有代价的：隧道用户之间的点对点连接以及与本机IPv6 Internet的连接都可能受到可靠性和性能问题的影响。
The anycast mechanism allows tunnel users to utilise the nearest gateway to connect to the IPv6 Internet by simply giving each gateway the same address. Routing protocols then select the lowest-cost (and presumably, shortest) path towards a gateway. However, this makes the path taken by tunneled packets hard to predict or influence. It is common for traffic in two directions to use different gateways,
选播机制允许隧道用户通过简单地为每个网关提供相同的地址，利用最近的网关连接到IPv6 Internet。然后，路由协议选择通向网关的最低成本（大概也是最短的）路径。然而，这使得隧道包所采用的路径难以预测或影响。两个方向的流量通常使用不同的网关，
complicating debugging even further. Because nobody is in charge or gets paid for operating a gateway, the number of public gateways is lower than would be ideal. This increases the distance to the nearest gateway for some users. There is also the possibility that gateways encounter more traffic than they can handle.
使调试更加复杂。因为没有人负责运营网关或为其付费，所以公共网关的数量比理想情况要少。这会增加某些用户到最近网关的距离。还有一种可能性是，网关遇到的流量超过了它们所能处理的流量。
The advantage of a tunnel provided by an ISP or tunnel broker is that there is a clear responsibility for providing a good service with well-maintained gateways.
ISP或隧道代理提供的隧道的优点是，有明确的责任通过维护良好的网关提供良好的服务。
+------------+---------------+--------------------------------+
| Mechanism | Peer-to-peer | Gateway provided by |
+------------+---------------+--------------------------------+
| Conf. tun. | No | ISP or tunnel broker |
| AYIYA | No | ISP or tunnel broker |
| GRE | No | N/A |
| 6a44 | Within domain | ISP |
| 6rd | Within domain | ISP |
| 6over4 | Globally | N/A |
| ISATAP | Within domain | Own organisation |
| Teredo | Globally | Public |
| 6to4 | Globally | Public or ISP |
| 6bed4 | Globally | Public or ISP or tunnel broker |
| Auto. tun. | Globally | N/A |
| LISP | Configurable | ISP or tunnel broker |
| SEAL | Configurable | ISP or tunnel broker |
+------------+---------------+--------------------------------+
+------------+---------------+--------------------------------+
| Mechanism | Peer-to-peer | Gateway provided by |
+------------+---------------+--------------------------------+
| Conf. tun. | No | ISP or tunnel broker |
| AYIYA | No | ISP or tunnel broker |
| GRE | No | N/A |
| 6a44 | Within domain | ISP |
| 6rd | Within domain | ISP |
| 6over4 | Globally | N/A |
| ISATAP | Within domain | Own organisation |
| Teredo | Globally | Public |
| 6to4 | Globally | Public or ISP |
| 6bed4 | Globally | Public or ISP or tunnel broker |
| Auto. tun. | Globally | N/A |
| LISP | Configurable | ISP or tunnel broker |
| SEAL | Configurable | ISP or tunnel broker |
+------------+---------------+--------------------------------+
Topologies Supported per Tunnel Mechanism
每个隧道机制支持的拓扑
Tunnels may fail for three main reasons: when tunneled packets are filtered, typically by a firewall; when a tunnel endpoint IPv4 address changes; or when tunneled packets are filtered or because of NAT issues.
隧道失败有三个主要原因：当隧道包被过滤时，通常由防火墙过滤；当隧道端点IPv4地址更改时；或者当隧道数据包被过滤时，或者由于NAT问题。
If a tunnel endpoint gets a new address, the other side of the tunnel needs to know to send packets to the new address. With mechanisms that derive IPv6 addresses from the IPv4 address, the previous IPv6 addresses become unreachable, and new IPv6 addresses must be configured.
如果隧道端点获得新地址，则隧道的另一端需要知道如何将数据包发送到新地址。使用从IPv4地址派生IPv6地址的机制，以前的IPv6地址将无法访问，必须配置新的IPv6地址。
Some tunnel mechanisms don't work through NAT, or are limited when working through NAT. NAT mappings can typically only be created by traffic from the "inside" to the "outside", not by traffic from outside the NAT to the network behind the NAT.
有些隧道机制无法通过NAT工作，或者在通过NAT工作时受到限制。NAT映射通常只能通过从“内部”到“外部”的流量创建，而不能通过从NAT外部到NAT后面的网络的流量创建。
Point-to-point tunnel mechanisms either work consistently or they always fail. As such, a simple ping to the other side of the tunnel is sufficient to learn its state. Also, point-to-point tunnels may support routing protocols, which can automatically reroute traffic around a failed tunnel.
点对点隧道机制要么持续工作，要么总是失败。因此，对隧道另一侧进行简单的ping操作就足以了解其状态。此外，点对点隧道可能支持路由协议，该协议可以自动重新路由故障隧道周围的流量。
Some tunnel mechanisms use a public gateway to reach the native IPv6 Internet. Public gateways may or may not be operational and/or reachable, and they may have limited performance, depending on distance and usage.
一些隧道机制使用公共网关来访问本机IPv6 Internet。公共网关可能运行和/或不可访问，也可能性能有限，具体取决于距离和使用情况。
Tunnel mechanisms that use a broadcast or Non-Broadcast Multi-Access (NBMA) communication model may experience failures between some combinations of tunnel endpoints and not others.
使用广播或非广播多址（NBMA）通信模型的隧道机制可能会在隧道端点的某些组合（而不是其他组合）之间遇到故障。
The following table lists tunnel mechanisms that provide connectivity to the IPv6 Internet in order of decreasing robustness. (However, even less-robust mechanisms may function well in suitable environments.)
下表列出了为IPv6 Internet提供连接以降低健壮性的隧道机制。（然而，即使不太坚固的机制也可能在合适的环境中发挥良好的作用。）
+------------+---------------+--------------------------------------+
| Mechanism | Endpoint | Main issues |
| | address | |
| | change | |
+------------+---------------+--------------------------------------+
| LISP | automatic | None |
| 6rd | interrupt | None |
| AYIYA | automatic | Transient NAT mapping issues |
| Conf. + | interrupt | Proto 41 filtering, competition for |
| Heartbeat | | NAT mappings (1) |
| Conf. tun. | failure | Proto 41 filtering, competition for |
| | | NAT mappings, address change (1) |
| GRE | failure | Proto 47 filtering, address change |
| 6a44 | interrupt | NAT mapping towards peers |
| 6bed4 | interrupt | NAT mapping towards peers |
| 6to4 | interrupt | Enabled out of the box but filtered, |
| | | gateway performance (2) |
| Teredo | interrupt | NAT compatibility, mapping towards |
| | | peers (3) |
+------------+---------------+--------------------------------------+
+------------+---------------+--------------------------------------+
| Mechanism | Endpoint | Main issues |
| | address | |
| | change | |
+------------+---------------+--------------------------------------+
| LISP | automatic | None |
| 6rd | interrupt | None |
| AYIYA | automatic | Transient NAT mapping issues |
| Conf. + | interrupt | Proto 41 filtering, competition for |
| Heartbeat | | NAT mappings (1) |
| Conf. tun. | failure | Proto 41 filtering, competition for |
| | | NAT mappings, address change (1) |
| GRE | failure | Proto 47 filtering, address change |
| 6a44 | interrupt | NAT mapping towards peers |
| 6bed4 | interrupt | NAT mapping towards peers |
| 6to4 | interrupt | Enabled out of the box but filtered, |
| | | gateway performance (2) |
| Teredo | interrupt | NAT compatibility, mapping towards |
| | | peers (3) |
+------------+---------------+--------------------------------------+
Susceptibility of Tunnel Mechanisms to Problems
隧道机制对问题的敏感性
Notes:
笔记：
(1): Only one protocol 41 tunnel endpoint can receive a NAT mapping behind a NAT using a single public IPv4 address. Additional endpoints will not receive incoming packets. When a tunnel endpoint changes its internal address, the old NAT mapping needs to time out before a new one can be created.
（1） ：只有一个协议41隧道端点可以使用单个公共IPv4地址在NAT后面接收NAT映射。其他端点将不会接收传入的数据包。当隧道端点更改其内部地址时，旧的NAT映射需要超时才能创建新的NAT映射。
(2): 6to4 implementations automatically disable the mechanism when the system has an RFC 1918 address. However, 6to4 may remain enabled and be non-operational when ISPs apply NAT using addresses that are not as defined in RFC 1918 [RFC6598].
（2） ：6to4实现在系统具有RFC 1918地址时自动禁用该机制。但是，当ISP使用RFC1918[RFC6598]中未定义的地址应用NAT时，6to4可能会保持启用状态且不可操作。
(3): Whether Teredo can obtain an address depends on the type of NAT it detects. Whether Teredo functions at such an address depends on the accuracy of that determination, which is founded on an incomplete model of NAT.
（3） ：Teredo能否获得地址取决于它检测到的NAT类型。Teredo是否在这样一个地址工作取决于该确定的准确性，该确定是建立在NAT的不完整模型上的。
On some widely used implementations, 6to4 has been enabled by default without checking whether there was connectivity to the anycasted public gateway address. As a result, 6to4-derived connectivity to the IPv6 Internet was often found to be broken because of protocol 41 filtering. Because of this, many operating systems now try to avoid using IPv6 over 6to4. See [RFC6343].
在一些广泛使用的实现中，默认情况下启用了6to4，而不检查是否连接到任意广播的公共网关地址。因此，人们经常发现，由于协议41过滤，6to4衍生的与IPv6 Internet的连接中断。因此，许多操作系统现在都试图避免在6to4上使用IPv6。见[RFC6343]。
Also see [TERTST] for more information about the robustness of Teredo.
有关Teredo健壮性的更多信息，请参见[TERTST]。
There is not a single tunnel mechanism that is more robust in all possible ways than every other tunnel mechanism. However, in general, mechanisms that use public gateways and peer-to-peer tunneling tend to have the most issues. Configured tunnels, on the other hand, often work very well, especially if there is no NAT on the path, but they may need administrative intervention when a tunnel endpoint address changes.
没有一种隧道机制比其他任何隧道机制在所有可能的方面都更健壮。然而，一般来说，使用公共网关和点对点隧道的机制往往存在最多的问题。另一方面，配置的隧道通常工作得很好，特别是在路径上没有NAT的情况下，但是当隧道端点地址更改时，它们可能需要管理干预。
There is an additional consideration that is important to operators of gateways that connect IPv6-in-IPv4 tunnels to the IPv6 Internet: how much state a tunnel mechanism requires.
对于将IPv6-in-IPv4隧道连接到IPv6 Internet的网关运营商来说，还有一个重要的考虑因素：隧道机制需要多少状态。
6to4, 6rd, 6a44 and 6bed4 require no state at all: when encapsulating IPv6 packets inside an IPv4 packet, the IPv4 destination address is directly copied from bits in the IPv6 destination address. This makes all possible tunneled destinations directly reachable through a single virtual interface.
6to4、6rd、6a44和6bed4完全不需要状态：在IPv4数据包中封装IPv6数据包时，IPv4目标地址直接从IPv6目标地址中的位复制。这使得通过单个虚拟接口可以直接访问所有可能的隧道目的地。
Teredo relays maintain a list of peers and are intended to service a limited number of hosts. The Teredo server, however, is a stateless gateway component.
Teredo中继维护一个对等点列表，旨在为有限数量的主机提供服务。然而，Teredo服务器是一个无状态网关组件。
With configured tunnels, GRE, AYIYA, and SEAL, there is no direct mapping from (part of) the IPv6 destination address to the IPv4 destination address. A typical implementation of these mechanisms has a virtual tunnel interface for each tunnel. Packets are forwarded to the correct virtual interface through a routing table lookup. Routing tables can grow very large and remain fast, so the number of virtual interfaces tends to be the limiting factor for tunnel gateways. AYIYA and the SixXS Heartbeat Protocol also keep track of the reachability status of each tunnel.
通过配置隧道、GRE、AYIYA和SEAL，IPv6目标地址（部分）与IPv4目标地址之间没有直接映射。这些机制的典型实现为每个隧道都有一个虚拟隧道接口。数据包通过路由表查找转发到正确的虚拟接口。路由表可能会变得非常大并保持快速，因此虚拟接口的数量往往是隧道网关的限制因素。AYIYA和SixXS心跳协议还跟踪每个隧道的可达性状态。
There are several reasons why tunneled connectivity may perform inferior to native, untunneled connectivity. Inherently, tunnels add one or more extra headers, and therefore increase overhead. However, for an Ethernet packet of maximum size (1500 bytes), the additional overhead of an IPv4 header is only 1.3%.
隧道连接的性能可能不如本机未隧道连接的原因有很多。从本质上讲，隧道会添加一个或多个额外的标头，因此会增加开销。然而，对于最大大小（1500字节）的以太网数据包，IPv4报头的额外开销仅为1.3%。
The process of encapsulation is not inherently slow, but in some implementations, it may be. Larger routers that normally forward packets using special-purpose hardware often don't have high-performance CPUs. If tunnel encapsulation must then be done by that relatively slow CPU, performance will be worse than regular hardware-based packet forwarding.
封装过程本身并不缓慢，但在某些实现中，它可能是缓慢的。通常使用专用硬件转发数据包的大型路由器通常没有高性能CPU。如果隧道封装必须由相对较慢的CPU完成，那么性能将比常规的基于硬件的数据包转发更差。
The path that tunneled packets take can be longer than the path that untunneled packets would take (i.e., increased path stretch can occur). This may or may not lead to decreased performance.
隧道数据包所采用的路径可能比未隧道数据包所采用的路径长（即，可能出现路径延长）。这可能会也可能不会导致性能下降。
+------------+-----------------+----------------------+-------------+
| Mechanism | Overhead | Increased path | Variability |
| | (bytes) | stretch | |
+------------+-----------------+----------------------+-------------+
| Conf. tun. | 20 | may be large | none |
| Auto. tun. | 20 | none | none |
| 6over4 | 20 | none | none |
| GRE | 28 - 36 | may be large | none |
| 6to4 | 20 | may be large | high |
| AYIYA | 72 | may be large | low |
| ISATAP | 20 | none | none |
| Teredo | 28 - 36 | may be large | high |
| 6rd | 20 | small | low |
| 6a44 | 20 - 28 | small | low |
| 6bed4 | 28 | may be large | high |
| LISP | 36 | small | low |
| SEAL | 24 - variable | small | low |
+------------+-----------------+----------------------+-------------+
+------------+-----------------+----------------------+-------------+
| Mechanism | Overhead | Increased path | Variability |
| | (bytes) | stretch | |
+------------+-----------------+----------------------+-------------+
| Conf. tun. | 20 | may be large | none |
| Auto. tun. | 20 | none | none |
| 6over4 | 20 | none | none |
| GRE | 28 - 36 | may be large | none |
| 6to4 | 20 | may be large | high |
| AYIYA | 72 | may be large | low |
| ISATAP | 20 | none | none |
| Teredo | 28 - 36 | may be large | high |
| 6rd | 20 | small | low |
| 6a44 | 20 - 28 | small | low |
| 6bed4 | 28 | may be large | high |
| LISP | 36 | small | low |
| SEAL | 24 - variable | small | low |
+------------+-----------------+----------------------+-------------+
Typical Tunnel Performance
典型隧道性能
There are many security considerations with tunneling. An important one is that through a tunnel, connectivity to the IPv6 Internet may exist even though network administrators did not intend for it to be there. "Security Concerns with IP Tunneling" [RFC6169] discusses this issue in detail.
隧道有许多安全方面的考虑。重要的一点是，通过隧道，可以连接到IPv6 Internet，即使网络管理员不希望它存在。“IP隧道的安全问题”[RFC6169]详细讨论了这个问题。
Although, in principle, ingress filtering (BCP 38, [RFC2827]) is possible with tunnels, in practice, it is relatively easy for spoofed packets to make their way through a tunnel. Not only is it often easy to spoof the outer IPv4 header and make false IPv6 packets seem to originate from a tunnel broker or gateway, it may also be possible for an attacker to route false IPv6 packets through a legitimate tunnel broker or gateway. Many tunneling protocols have various means of detecting and rejecting such packets, while others have limited or no such provisions. For instance, see [RFC3964] for how this can be addressed with 6to4.
虽然原则上，入口过滤（BCP 38，[RFC2827]）在隧道中是可能的，但在实践中，欺骗数据包通过隧道相对容易。不仅很容易欺骗外部IPv4报头并使虚假IPv6数据包看起来源自隧道代理或网关，攻击者还可能通过合法的隧道代理或网关路由虚假IPv6数据包。许多隧道协议有各种检测和拒绝此类数据包的方法，而其他协议则有限制或没有此类规定。例如，请参见[RFC3964]了解如何使用6to4解决此问题。
So it is important to recognise that unless special measures are taken (like [RFC4301]), both IPv4 and IPv6 addresses in tunnel packets may be spoofed and cannot be relied upon for access controls. Such spoofing was used successfully to discover IPv6-in-IPv4 tunnels in [TUNDISC].
因此，重要的是要认识到，除非采取特殊措施（如[RFC4301]），否则隧道数据包中的IPv4和IPv6地址都可能被欺骗，无法用于访问控制。此类欺骗已成功用于在[TUNDISC]中发现IPv4中的IPv6隧道。
Tunnels may also be used by third parties to obfuscate their activities or perform amplification attacks. To avoid contributing to this problem, it is important to make sure only locally generated packets with legitimate addresses are sent out over tunnels.
隧道也可能被第三方用于混淆其活动或执行放大攻击。为了避免造成这个问题，确保只有本地生成的具有合法地址的数据包通过隧道发送是很重要的。
Job Snijders contributed text to the points of comparison. Fred Templin provided the text for SEAL and contributed to the security considerations. Jeroen Massar, Brian Carpenter, Tina Tsou, John Mann, Suresh Krishnan, Victor Kuarsingh, Dan Jones, Nejc Skoberne, and Fred Baker reviewed the document and/or offered suggestions for improvement.
Job Snijders为比较点提供了文本。Fred Templin为SEAL提供了文本，并为安全考虑做出了贡献。Jeroen Massar、Brian Carpenter、Tina Tsou、John Mann、Suresh Krishnan、Victor Kuarsingh、Dan Jones、Nejc Skoberne和Fred Baker审查了文件并/或提出了改进建议。
We wish to thank SURFnet and Rogier Spoor for commissioning this work; both their initiative and funding have helped this document to be written.
我们要感谢SURFnet和Rogier Spoor委托开展这项工作；他们的倡议和资金都有助于编写这份文件。
[6BED4] Van Rein, R., "6bed4: Peer-to-Peer IPv6 on Any Internetwork", Work in Progress, July 2013.
[6BED4]Van Rein，R.，“6BED4：任何互联网上的对等IPv6”，正在进行的工作，2013年7月。
[AICCU] SixXS, "Automatic IPv6 Connectivity Client Utility (AICCU)", <http://www.sixxs.net/tools/aiccu/>.
[AICCU]SixXS，“自动IPv6连接客户端实用程序（AICCU）”<http://www.sixxs.net/tools/aiccu/>.
[AYIYA] SixXS, "Anything In Anything (AYIYA)", <http://www.sixxs.net/tools/ayiya/>.
[AYIYA]SixXS，“任何事物中的任何事物（AYIYA）”<http://www.sixxs.net/tools/ayiya/>.
[GOGO6] gogo6, "Freenet6: Free and Easy IPv6 Connectivity", <http://www.gogo6.com/freenet6>.
[GOGO6]GOGO6，“Freenet6：免费轻松的IPv6连接”<http://www.gogo6.com/freenet6>.
[HEARTBEAT] Massar, J., "SixXS Heartbeat Protocol", Work in Progress, June 2005.
[心跳]马萨，J.，“SixXS心跳协议”，正在进行的工作，2005年6月。
[LISPBETA] LISP4/LISP6.net, "LISP Beta Network", <http://www.lisp4.net/beta-network/>.
[LISPBETA]LISP4/LISP6.net，“LISP测试版网络”<http://www.lisp4.net/beta-network/>.
[MAP] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", Work in Progress, August 2013.
[MAP]Troan，O.，Dec，W.，Li，X.，Bao，C.，Matsushima，S.，Murakami，T.，和T.Taylor，“地址和端口的封装映射（MAP）”，正在进行的工作，2013年8月。
[MASSAR] Massar, J., "AYIYA: Anything In Anything", Work in Progress, July 2004.
[马萨]马萨，J.，“AYIYA：任何事物中的任何事物”，进展中的工作，2004年7月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，1996年4月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516]Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 2893，2000年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC3489] 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.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891]Graveman，R.，Parthasarathy，M.，Savola，P.，和H.Tschofenig，“使用IPsec保护IPv4隧道中的IPv6”，RFC 4891，2007年5月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC5572]Blanchet，M.和F.Parent，“具有隧道设置协议（TSP）的IPv6隧道代理”，RFC 5572，2010年2月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年4月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 63432011年8月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", RFC 6732, September 2012.
[RFC6732]Kuarsingh，V.，Lee，Y.，和O.Vautrin，“6to4提供商管理的隧道”，RFC 6732，2012年9月。
[RFC6751] Despres, R., Carpenter, B., Wing, D., and S. Jiang, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", RFC 6751, October 2012.
[RFC6751]Despres，R.，Carpenter，B.，Wing，D.，和S.Jiang，“IPv4到IPv4 NAT客户场所设备（6a44）背后的本机IPv6”，RFC 6751，2012年10月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，2013年1月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832]Lewis，D.，Meyer，D.，Farinaci，D.，和V.Fuller，“定位器/ID分离协议（LISP）和非LISP站点之间的互通”，RFC 6832，2013年1月。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
[RFC6833]Fuller，V.和D.Farinaci，“定位器/ID分离协议（LISP）地图服务器接口”，RFC 6833，2013年1月。
[SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, October 2013.
[SEAL]Templin，F.，“子网络封装和适配层（SEAL）”，正在进行的工作，2013年10月。
[SIXXS] Massar, J. and P. van Pelt, "IPv6 Deployment & Tunnel Broker", <http://www.sixxs.net/>.
[SIXXS]Massar，J.和P.van Pelt，“IPv6部署和隧道代理”<http://www.sixxs.net/>.
[TERTST] Huston, G., "Testing Teredo", April 2011, <http://www.potaroo.net/ispcol/2011-04/teredo.html>.
[TERTST]Huston，G.，“测试Teredo”，2011年4月<http://www.potaroo.net/ispcol/2011-04/teredo.html>.
[TIC] SixXS, "Tunnel Information and Control protocol (TIC)", <http://www.sixxs.net/tools/tic/>.
[TIC]SixXS，“隧道信息和控制协议（TIC）”<http://www.sixxs.net/tools/tic/>.
[TR-069] The Broadband Forum, "CPE WAN Management Protocol", July 2011, <http://www.broadband-forum.org/technical/ download/TR-069_Amendment-4.pdf>.
[TR-069]宽带论坛，“CPE WAN管理协议”，2011年7月<http://www.broadband-forum.org/technical/ 下载/TR-069_-Amendment-4.pdf>。
[TUNBROKER] Hurricane Electric, "Hurricane Electric Free IPv6 Tunnel Broker", <http://www.tunnelbroker.net/>.
[TUNBROKER]飓风电气，“飓风电气免费IPv6隧道代理”<http://www.tunnelbroker.net/>.
[TUNDISC] Colitti, L., Di Battista, G., and M. Patrignani, "IPv6-in-IPv4 tunnel discovery: methods and experimental results", IEEE eTransactions on Network and Service Management (eTNSM), vol. 1, no. 1, p. 2-10, April 2004.
[TUNDISC]Coletti，L.，Di Battista，G.，和M.Patrignani，“IPv4中的IPv6隧道发现：方法和实验结果”，IEEE关于网络和服务管理的电子交易（eTNSM），第1卷，第1期，第页。2004年4月2日至10日。
Each type of tunnel has specific advantages and disadvantages. We have considered the following points when evaluating the different protocols. Not every point is mentioned in each section where a protocol is described, only those that are specifically relevant to that protocol.
每种类型的隧道都有各自的优缺点。在评估不同协议时，我们考虑了以下几点。在描述协议的每一节中，并不是每一点都提到，只是那些与该协议具体相关的点。
Protocol overhead: How much overhead does the tunneling protocol cause? There are two factors that play a role: the number of interactions to set up the tunnel and the packet header size causing a lower MTU and/or fragmentation.
协议开销：隧道协议会造成多少开销？有两个因素起作用：设置隧道的交互次数和导致较低MTU和/或碎片的数据包头大小。
Automatic configuration: Does this protocol require manual configuration at the endpoints?
自动配置：此协议是否需要在端点进行手动配置？
Predictability: How predictable is the functioning of the protocol?
可预测性：议定书的运作可预测性如何？
Single host or network: Is this protocol intended to be used by a single host or by a router that then provides IPv6 connectivity to multiple hosts?
单主机或网络：该协议是由一台主机使用，还是由一台路由器使用，然后该路由器向多台主机提供IPv6连接？
Load balancing: Does the tunnel traffic have enough entropy and/or "hashability" to be able to be load-balanced over multiple links, or do all tunnel packets have the same outer 5-tuple?
负载平衡：隧道流量是否具有足够的熵和/或“哈希能力”，能够在多个链路上进行负载平衡，或者所有隧道数据包是否具有相同的外部5元组？
Path stretch: Does the tunnel optimise the route, or is there a big potential for a much longer path when using the tunnel?
路径延伸：隧道是否优化了路线，或者在使用隧道时，是否存在更长路径的巨大潜力？
NAT traversal: Can the tunnel pass through a NAT gateway, and does it require configuration on that NAT gateway?
NAT穿越：隧道能否通过NAT网关，它是否需要在该NAT网关上进行配置？
Tunnel endpoint mobility: Are the IPv4 addresses of the tunnel fixed, or do they adjust automatically when an endpoint moves?
隧道端点移动：隧道的IPv4地址是固定的，还是在端点移动时自动调整？
State: Are the endpoints required to keep state for the tunnel, or is the tunnel stateless?
状态：端点是保持隧道状态所必需的，还是隧道是无状态的？
Network type: Is this network a point-to-point or NBMA type of network?
网络类型：该网络是点对点网络还是NBMA网络？
Purpose: What is the intended purpose of this tunnel protocol?
目的：本隧道协议的预期目的是什么？
Related protocols: To which protocols is this tunnel protocol related? Are there alternatives?
相关协议：此隧道协议与哪些协议相关？还有其他选择吗？
Implementations: Is this protocol supported on the major operating systems, routers, and firewalls?
实现：主要操作系统、路由器和防火墙是否支持此协议？
Limitations: What are the known limitations of this protocol?
限制：本协议的已知限制是什么？
Authors' Addresses
作者地址
Sander Steffann S.J.M. Steffann Consultancy Tienwoningenweg 46 Apeldoorn, Gelderland 7312 DN The Netherlands
Sander Steffann S.J.M.Steffann咨询公司Tienwoningenweg 46 Apeldoorn，Gelderland 7312 DN荷兰
EMail: sander@steffann.nl
EMail: sander@steffann.nl
Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van Beijnum研究所IMDEA Networks Avda。德尔马尔地中海，22勒加内斯，马德里28918西班牙
EMail: iljitsch@muada.com
EMail: iljitsch@muada.com
Rick van Rein OpenFortress Haarlebrink 5 Enschede, Overijssel 7544 WP The Netherlands
Rick van Rein OpenFortress Haarlebrink 5 Enschede，Overijssel 7544 WP荷兰
EMail: rick@openfortress.nl
EMail: rick@openfortress.nl