Network Working Group R. Gilligan
Request for Comments: 2893 FreeGate Corp.
Obsoletes: 1933 E. Nordmark
Category: Standards Track Sun Microsystems, Inc.
August 2000
Network Working Group R. Gilligan
Request for Comments: 2893 FreeGate Corp.
Obsoletes: 1933 E. Nordmark
Category: Standards Track Sun Microsystems, Inc.
August 2000
Transition Mechanisms for IPv6 Hosts and Routers
IPv6主机和路由器的转换机制
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933.
本文档指定了可由IPv6主机和路由器实现的IPv4兼容机制。这些机制包括提供两个版本的Internet协议（IPv4和IPv6）的完整实现，以及通过IPv4路由基础设施对IPv6数据包进行隧道传输。它们旨在允许IPv6节点保持与IPv4的完全兼容性，这将大大简化IPv6在Internet中的部署，并促进整个Internet最终过渡到IPv6。本文件废除了RFC 1933。
Table of Contents
目录
1. Introduction............................................. 2
1.1. Terminology......................................... 3
1.2. Structure of this Document.......................... 5
2. Dual IP Layer Operation.................................. 6
2.1. Address Configuration............................... 7
2.2. DNS................................................. 7
2.3. Advertising Addresses in the DNS.................... 8
3. Common Tunneling Mechanisms.............................. 9
3.1. Encapsulation....................................... 11
3.2. Tunnel MTU and Fragmentation........................ 11
3.3. Hop Limit........................................... 13
3.4. Handling IPv4 ICMP errors........................... 13
3.5. IPv4 Header Construction............................ 15
3.6. Decapsulation....................................... 16
3.7. Link-Local Addresses................................ 17
3.8. Neighbor Discovery over Tunnels..................... 18
4. Configured Tunneling..................................... 18
4.1. Default Configured Tunnel........................... 19
4.2. Default Configured Tunnel using IPv4 "Anycast Address" 19
4.3. Ingress Filtering................................... 20
5. Automatic Tunneling...................................... 20
5.1. IPv4-Compatible Address Format...................... 20
5.2. IPv4-Compatible Address Configuration............... 21
5.3. Automatic Tunneling Operation....................... 22
5.4. Use With Default Configured Tunnels................. 22
5.5. Source Address Selection............................ 23
5.6. Ingress Filtering................................... 23
6. Acknowledgments.......................................... 24
7. Security Considerations.................................. 24
8. Authors' Addresses....................................... 24
9. References............................................... 25
10. Changes from RFC 1933................................... 26
11. Full Copyright Statement................................ 29
1. Introduction............................................. 2
1.1. Terminology......................................... 3
1.2. Structure of this Document.......................... 5
2. Dual IP Layer Operation.................................. 6
2.1. Address Configuration............................... 7
2.2. DNS................................................. 7
2.3. Advertising Addresses in the DNS.................... 8
3. Common Tunneling Mechanisms.............................. 9
3.1. Encapsulation....................................... 11
3.2. Tunnel MTU and Fragmentation........................ 11
3.3. Hop Limit........................................... 13
3.4. Handling IPv4 ICMP errors........................... 13
3.5. IPv4 Header Construction............................ 15
3.6. Decapsulation....................................... 16
3.7. Link-Local Addresses................................ 17
3.8. Neighbor Discovery over Tunnels..................... 18
4. Configured Tunneling..................................... 18
4.1. Default Configured Tunnel........................... 19
4.2. Default Configured Tunnel using IPv4 "Anycast Address" 19
4.3. Ingress Filtering................................... 20
5. Automatic Tunneling...................................... 20
5.1. IPv4-Compatible Address Format...................... 20
5.2. IPv4-Compatible Address Configuration............... 21
5.3. Automatic Tunneling Operation....................... 22
5.4. Use With Default Configured Tunnels................. 22
5.5. Source Address Selection............................ 23
5.6. Ingress Filtering................................... 23
6. Acknowledgments.......................................... 24
7. Security Considerations.................................. 24
8. Authors' Addresses....................................... 24
9. References............................................... 25
10. Changes from RFC 1933................................... 26
11. Full Copyright Statement................................ 29
The key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transitioning the Internet to IPv6. This specification defines a set of mechanisms that IPv6 hosts and routers may implement in order to be compatible with IPv4 hosts and routers.
成功过渡IPv6的关键是与大量IPv4主机和路由器的兼容性。在部署IPv6的同时保持与IPv4的兼容性将简化将Internet转换为IPv6的任务。本规范定义了一组IPv6主机和路由器可以实现的机制，以便与IPv4主机和路由器兼容。
The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in
本文档中的机制设计用于需要与IPv4主机互操作并利用IPv4路由基础设施的IPv6主机和路由器。我们预计大多数节点在
the Internet will need such compatibility for a long time to come, and perhaps even indefinitely.
互联网在很长一段时间内都需要这种兼容性，甚至可能是无限期的。
However, IPv6 may be used in some environments where interoperability with IPv4 is not required. IPv6 nodes that are designed to be used in such environments need not use or even implement these mechanisms.
但是，在某些不需要与IPv4互操作性的环境中，可以使用IPv6。设计用于此类环境的IPv6节点不需要使用甚至实现这些机制。
The mechanisms specified here include:
此处指定的机制包括：
- Dual IP layer (also known as Dual Stack): A technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers.
- 双IP层（也称为双堆栈）：一种在主机和路由器中为Internet协议（IPv4和IPv6）提供完全支持的技术。
- Configured tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
- 已配置的IPv4上的IPv6隧道：通过将IPv6数据包封装在IPv4报头中以在IPv4路由基础结构上传输这些数据包而形成的点对点隧道。
- IPv4-compatible IPv6 addresses: An IPv6 address format that employs embedded IPv4 addresses.
- 与IPv4兼容的IPv6地址：采用嵌入式IPv4地址的IPv6地址格式。
- Automatic tunneling of IPv6 over IPv4: A mechanism for using IPv4-compatible addresses to automatically tunnel IPv6 packets over IPv4 networks.
- IPv4上IPv6的自动隧道：一种使用IPv4兼容地址在IPv4网络上自动隧道IPv6数据包的机制。
The mechanisms defined here are intended to be part of a "transition toolbox" -- a growing collection of techniques which implementations and users may employ to ease the transition. The tools may be used as needed. Implementations and sites decide which techniques are appropriate to their specific needs. This document defines the initial core set of transition mechanisms, but these are not expected to be the only tools available. Additional transition and compatibility mechanisms are expected to be developed in the future, with new documents being written to specify them.
这里定义的机制旨在成为“转换工具箱”的一部分，这是一个不断增长的技术集合，实现和用户可以使用这些技术来简化转换。可根据需要使用这些工具。实现和站点决定哪些技术适合它们的特定需求。本文档定义了过渡机制的初始核心集，但这些不是唯一可用的工具。预计今后将开发更多的过渡和兼容性机制，并编写新的文件来具体说明这些机制。
The following terms are used in this document:
本文件中使用了以下术语：
Types of Nodes
节点类型
IPv4-only node:
仅IPv4节点：
A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
仅实现IPv4的主机或路由器。仅IPv4节点不理解IPv6。转换开始之前存在的IPv4主机和路由器的安装基数是仅IPv4节点。
IPv6/IPv4 node:
IPv6/IPv4节点：
A host or router that implements both IPv4 and IPv6.
同时实现IPv4和IPv6的主机或路由器。
IPv6-only node:
仅限IPv6的节点：
A host or router that implements IPv6, and does not implement IPv4. The operation of IPv6-only nodes is not addressed here.
实现IPv6而不实现IPv4的主机或路由器。此处不讨论仅IPv6节点的操作。
IPv6 node:
IPv6节点：
Any host or router that implements IPv6. IPv6/IPv4 and IPv6- only nodes are both IPv6 nodes.
实现IPv6的任何主机或路由器。IPv6/IPv4和仅IPv6的节点都是IPv6节点。
IPv4 node:
IPv4节点：
Any host or router that implements IPv4. IPv6/IPv4 and IPv4- only nodes are both IPv4 nodes.
实现IPv4的任何主机或路由器。IPv6/IPv4和仅IPv4的节点都是IPv4节点。
Types of IPv6 Addresses
IPv6地址的类型
IPv4-compatible IPv6 address:
IPv4兼容IPv6地址：
An IPv6 address bearing the high-order 96-bit prefix 0:0:0:0:0:0, and an IPv4 address in the low-order 32-bits. IPv4-compatible addresses are used by IPv6/IPv4 nodes which perform automatic tunneling,
带有高阶96位前缀0:0:0:0:0:0的IPv6地址和低阶32位的IPv4地址。IPv4兼容地址由执行自动隧道的IPv6/IPv4节点使用，
IPv6-native address:
IPv6本机地址：
The remainder of the IPv6 address space. An IPv6 address that bears a prefix other than 0:0:0:0:0:0.
IPv6地址空间的其余部分。带有0:0:0:0:0:0以外前缀的IPv6地址。
Techniques Used in the Transition
过渡时期使用的技术
IPv6-over-IPv4 tunneling:
IPv6-over-IPv4隧道：
The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.
在IPv4中封装IPv6数据包的技术，以便它们可以跨IPv4路由基础结构进行传输。
Configured tunneling:
配置的隧道：
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined by configuration information on the encapsulating node. The tunnels can be either unidirectional or bidirectional. Bidirectional configured tunnels behave as virtual point-to-point links.
IPv6-over-IPv4隧道，其中IPv4隧道端点地址由封装节点上的配置信息确定。隧道可以是单向的，也可以是双向的。双向配置的隧道充当虚拟点到点链路。
Automatic tunneling:
自动隧道：
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined from the IPv4 address embedded in the IPv4- compatible destination address of the IPv6 packet being tunneled.
IPv6-over-IPv4隧道，其中IPv4隧道端点地址由嵌入在正在隧道的IPv6数据包的IPv4兼容目标地址中的IPv4地址确定。
IPv4 multicast tunneling:
IPv4多播隧道：
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined using Neighbor Discovery [7]. Unlike configured tunneling this does not require any address configuration and unlike automatic tunneling it does not require the use of IPv4-compatible addresses. However, the mechanism assumes that the IPv4 infrastructure supports IPv4 multicast. Specified in [3] and not further discussed in this document.
IPv6-over-IPv4隧道，其中IPv4隧道端点地址是使用邻居发现确定的[7]。与已配置的隧道不同，它不需要任何地址配置，与自动隧道不同，它不需要使用IPv4兼容的地址。但是，该机制假定IPv4基础结构支持IPv4多播。[3]中规定，本文件中未进一步讨论。
Other transition mechanisms, including other tunneling mechanisms, are outside the scope of this document.
其他过渡机制，包括其他隧道机制，不在本文件范围内。
Modes of operation of IPv6/IPv4 nodes
IPv6/IPv4节点的操作模式
IPv6-only operation:
仅限IPv6的操作：
An IPv6/IPv4 node with its IPv6 stack enabled and its IPv4 stack disabled.
已启用IPv6堆栈且已禁用IPv4堆栈的IPv6/IPv4节点。
IPv4-only operation:
仅IPv4操作：
An IPv6/IPv4 node with its IPv4 stack enabled and its IPv6 stack disabled.
已启用IPv4堆栈且已禁用IPv6堆栈的IPv6/IPv4节点。
IPv6/IPv4 operation:
IPv6/IPv4操作：
An IPv6/IPv4 node with both stacks enabled.
启用了两个堆栈的IPv6/IPv4节点。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [16].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[16]中的说明进行解释。
The remainder of this document is organized as follows:
本文件其余部分的组织结构如下：
- Section 2 discusses the operation of nodes with a dual IP layer, IPv6/IPv4 nodes.
- 第2节讨论具有双IP层（IPv6/IPv4节点）的节点的操作。
- Section 3 discusses the common mechanisms used in both of the IPv6-over-IPv4 tunneling techniques.
- 第3节讨论了两种IPv6-over-IPv4隧道技术中使用的常见机制。
- Section 4 discusses configured tunneling.
- 第4节讨论配置的隧道。
- Section 5 discusses automatic tunneling and the IPv4-compatible IPv6 address format.
- 第5节讨论自动隧道和与IPv4兼容的IPv6地址格式。
The most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 nodes that provide a complete IPv4 and IPv6 implementations are called "IPv6/IPv4 nodes." IPv6/IPv4 nodes have the ability to send and receive both IPv4 and IPv6 packets. They can directly interoperate with IPv4 nodes using IPv4 packets, and also directly interoperate with IPv6 nodes using IPv6 packets.
IPv6节点保持与仅IPv4节点兼容的最直接的方法是提供完整的IPv4实现。提供完整IPv4和IPv6实现的IPv6节点称为“IPv6/IPv4节点”。IPv6/IPv4节点能够发送和接收IPv4和IPv6数据包。它们可以使用IPv4数据包直接与IPv4节点互操作，也可以使用IPv6数据包直接与IPv6节点互操作。
Even though a node may be equipped to support both protocols, one or the other stack may be disabled for operational reasons. Thus IPv6/IPv4 nodes may be operated in one of three modes:
即使一个节点可能装备为支持这两个协议，一个或另一个堆栈也可能由于操作原因而被禁用。因此，IPv6/IPv4节点可在以下三种模式之一下运行：
- With their IPv4 stack enabled and their IPv6 stack disabled.
- 其IPv4堆栈已启用，IPv6堆栈已禁用。
- With their IPv6 stack enabled and their IPv4 stack disabled.
- 其IPv6堆栈已启用，IPv4堆栈已禁用。
- With both stacks enabled.
- 启用两个堆栈时。
IPv6/IPv4 nodes with their IPv6 stack disabled will operate like IPv4-only nodes. Similarly, IPv6/IPv4 nodes with their IPv4 stacks disabled will operate like IPv6-only nodes. IPv6/IPv4 nodes MAY provide a configuration switch to disable either their IPv4 or IPv6 stack.
禁用IPv6堆栈的IPv6/IPv4节点将像只运行IPv4的节点一样运行。类似地，禁用IPv4堆栈的IPv6/IPv4节点将像只运行IPv6的节点一样运行。IPv6/IPv4节点可以提供配置交换机来禁用其IPv4或IPv6堆栈。
The dual IP layer technique may or may not be used in conjunction with the IPv6-over-IPv4 tunneling techniques, which are described in sections 3, 4 and 5. An IPv6/IPv4 node that supports tunneling MAY support only configured tunneling, or both configured and automatic tunneling. Thus three modes of tunneling support are possible:
双IP层技术可以与IPv6-over-IPv4隧道技术结合使用，也可以不结合使用，如第3、4和5节所述。支持隧道的IPv6/IPv4节点可能仅支持已配置的隧道，或者同时支持已配置和自动隧道。因此，三种隧道支护模式是可能的：
- IPv6/IPv4 node that does not perform tunneling.
- 不执行隧道的IPv6/IPv4节点。
- IPv6/IPv4 node that performs configured tunneling only.
- 仅执行已配置隧道的IPv6/IPv4节点。
- IPv6/IPv4 node that performs configured tunneling and automatic tunneling.
- 执行已配置隧道和自动隧道的IPv6/IPv4节点。
Because they support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6 addresses. IPv6/IPv4 nodes use IPv4 mechanisms (e.g. DHCP) to acquire their IPv4 addresses, and IPv6 protocol mechanisms (e.g. stateless address autoconfiguration) to acquire their IPv6-native addresses. Section 5.2 describes a mechanism by which IPv6/IPv4 nodes that support automatic tunneling MAY use IPv4 protocol mechanisms to acquire their IPv4-compatible IPv6 address.
由于IPv6/IPv4节点支持这两种协议，因此可以同时配置IPv4和IPv6地址。IPv6/IPv4节点使用IPv4机制（例如DHCP）获取其IPv4地址，使用IPv6协议机制（例如无状态地址自动配置）获取其IPv6本机地址。第5.2节描述了支持自动隧道的IPv6/IPv4节点可以使用IPv4协议机制获取其IPv4兼容IPv6地址的机制。
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map between hostnames and IP addresses. A new resource record type named "A6" has been defined for IPv6 addresses [6] with support for an earlier record named "AAAA". Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "A6" and "AAAA" records.
IPv4和IPv6都使用域名系统（DNS）在主机名和IP地址之间进行映射。已为IPv6地址[6]定义了名为“A6”的新资源记录类型，并支持名为“AAAA”的早期记录。由于IPv6/IPv4节点必须能够直接与IPv4和IPv6节点进行互操作，因此它们必须提供能够处理IPv4“A”记录以及IPv6“A6”和“AAAA”记录的解析器库。
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both A6/AAAA and A records. However, when a query locates an A6/AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY filter or order the results returned to the application in order to influence the version of IP packets used to communicate with that node. In terms of filtering, the resolver library has three alternatives:
IPv6/IPv4节点上的DNS解析程序库必须能够处理A6/AAAA和A记录。然而，当查询查找到包含IPv6地址的A6/AAAA记录和包含IPv4地址的a记录时，解析程序库可能会过滤或排序返回给应用程序的结果，以影响用于与该节点通信的IP数据包的版本。在过滤方面，解析器库有三种选择：
- Return only the IPv6 address to the application.
- 仅向应用程序返回IPv6地址。
- Return only the IPv4 address to the application.
- 仅向应用程序返回IPv4地址。
- Return both addresses to the application.
- 将两个地址返回到应用程序。
If it returns only the IPv6 address, the application will communicate with the node using IPv6. If it returns only the IPv4 address, the application will communicate with the node using IPv4. If it returns both addresses, the application will have the choice which address to use, and thus which IP protocol to employ.
如果只返回IPv6地址，应用程序将使用IPv6与节点通信。如果只返回IPv4地址，应用程序将使用IPv4与节点通信。如果它返回两个地址，应用程序将可以选择使用哪个地址，从而选择使用哪个IP协议。
If it returns both, the resolver MAY elect to order the addresses -- IPv6 first, or IPv4 first. Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications.
如果它同时返回这两个地址，解析程序可能会选择对地址进行排序——IPv6优先，或IPv4优先。由于大多数应用程序都会按照解析程序返回的顺序尝试地址，这可能会影响应用程序的IP版本“首选项”。
The decision to filter or order DNS results is implementation specific. IPv6/IPv4 nodes MAY provide policy configuration to control filtering or ordering of addresses returned by the resolver, or leave the decision entirely up to the application.
筛选或排序DNS结果的决定是特定于实现的。IPv6/IPv4节点可以提供策略配置来控制解析程序返回的地址的过滤或排序，或者完全由应用程序决定。
An implementation MUST allow the application to control whether or not such filtering takes place.
实现必须允许应用程序控制是否进行此类过滤。
There are some constraint placed on the use of the DNS during transition. Most of these are obvious but are stated here for completeness.
在转换期间，DNS的使用受到一些限制。其中大多数都是显而易见的，但为了完整起见，在这里进行了说明。
The recommendation is that A6/AAAA records for a node should not be added to the DNS until all of these are true:
建议不要将节点的A6/AAAA记录添加到DNS中，直到所有这些都为真：
1) The address is assigned to the interface on the node.
1) 地址分配给节点上的接口。
2) The address is configured on the interface.
2) 该地址在接口上配置。
3) The interface is on a link which is connected to the IPv6 infrastructure.
3) 接口位于连接到IPv6基础结构的链路上。
If an IPv6 node is isolated from an IPv6 perspective (e.g. it is not connected to the 6bone to take a concrete example) constraint #3 would mean that it should not have an address in the DNS.
如果一个IPv6节点从IPv6角度隔离（例如，举一个具体的例子，它没有连接到6bone），那么约束#3意味着它不应该在DNS中有地址。
This works great when other dual stack nodes tries to contact the isolated dual stack node. There is no IPv6 address in the DNS thus the peer doesn't even try communicating using IPv6 but goes directly to IPv4 (we are assuming both nodes have A records in the DNS.)
当其他双堆栈节点尝试接触隔离的双堆栈节点时，这非常有效。DNS中没有IPv6地址，因此对等方甚至不尝试使用IPv6进行通信，而是直接转到IPv4（我们假设两个节点在DNS中都有一个记录）
However, this does not work well when the isolated node is trying to establish communication. Even though it does not have an IPv6 address in the DNS it will find A6/AAAA records in the DNS for the peer. Since the isolated node has IPv6 addresses assigned to at least one interface it will try to communicate using IPv6. If it has no IPv6 route to the 6bone (e.g. because the local router was upgraded to advertise IPv6 addresses using Neighbor Discovery but that router doesn't have any IPv6 routes) this communication will fail. Typically this means a few minutes of delay as TCP times out. The TCP specification says that ICMP unreachable messages could be due to routing transients thus they should not immediately terminate the TCP connection. This means that the normal TCP timeout of a few minutes apply. Once TCP times out the application will hopefully try the IPv4 addresses based on the A records in the DNS, but this will be painfully slow.
但是，当隔离节点尝试建立通信时，这并不起作用。即使DNS中没有IPv6地址，它也会在DNS中找到对等方的A6/AAAA记录。由于隔离节点已将IPv6地址分配给至少一个接口，因此它将尝试使用IPv6进行通信。如果它没有到6bone的IPv6路由（例如，因为本地路由器升级为使用邻居发现播发IPv6地址，但该路由器没有任何IPv6路由），此通信将失败。通常这意味着TCP超时时会有几分钟的延迟。TCP规范指出，ICMP无法访问的消息可能是由于路由瞬态造成的，因此它们不应立即终止TCP连接。这意味着将应用几分钟的正常TCP超时。一旦TCP超时，应用程序将有希望根据DNS中的A记录尝试IPv4地址，但这将非常缓慢。
A possible implication of the recommendations above is that, if one enables IPv6 on a node on a link without IPv6 infrastructure, and choose to add A6/AAAA records to the DNS for that node, then external IPv6 nodes that might see these A6/AAAA records will possibly try to reach that node using IPv6 and suffer delays or communication failure due to unreachability. (A delay is incurred if the application correctly falls back to using IPv4 if it can not establish communication using IPv6 addresses. If this fallback is not done the application would fail to communicate in this case.) Thus it is suggested that either the recommendations be followed, or care be taken to only do so with nodes that will not be impacted by external accessing delays and/or communication failure.
上述建议的一个可能含义是，如果在没有IPv6基础设施的链路上的节点上启用IPv6，并选择向该节点的DNS添加A6/AAAA记录，然后，可能看到这些A6/AAAA记录的外部IPv6节点可能会尝试使用IPv6到达该节点，并由于无法访问而遭受延迟或通信失败。（如果应用程序无法使用IPv6地址建立通信，则如果应用程序正确退回到使用IPv4，则会产生延迟。如果不退回，则应用程序在这种情况下将无法通信。）因此，建议遵循以下建议之一：，或者，应注意仅对不会受到外部访问延迟和/或通信故障影响的节点执行此操作。
In the future when a site or node removes the support for IPv4 the above recommendations apply to when the A records for the node(s) should be removed from the DNS.
将来，当站点或节点删除对IPv4的支持时，上述建议适用于应从DNS中删除节点的a记录的情况。
In most deployment scenarios, the IPv6 routing infrastructure will be built up over time. While the IPv6 infrastructure is being deployed, the existing IPv4 routing infrastructure can remain functional, and can be used to carry IPv6 traffic. Tunneling provides a way to utilize an existing IPv4 routing infrastructure to carry IPv6 traffic.
在大多数部署场景中，IPv6路由基础设施将随着时间的推移而建立。在部署IPv6基础设施时，现有的IPv4路由基础设施可以保持功能，并可用于承载IPv6流量。隧道提供了一种利用现有IPv4路由基础设施来承载IPv6流量的方法。
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 routing topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways:
IPv6/IPv4主机和路由器可以通过将IPv6数据报封装在IPv4数据包中，在IPv4路由拓扑的区域上对其进行隧道传输。隧道可通过多种方式使用：
- Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
- 路由器对路由器。由IPv4基础设施互连的IPv6/IPv4路由器可以在它们之间通过隧道传输IPv6数据包。在这种情况下，隧道跨越IPv6数据包所采用的端到端路径的一段。
- Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path.
- 主机到路由器。IPv6/IPv4主机可以通过隧道将IPv6数据包传输到可通过IPv4基础结构访问的中间IPv6/IPv4路由器。这种类型的隧道跨越数据包端到端路径的第一段。
- Host-to-Host. IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path that the packet takes.
- 主机对主机。由IPv4基础结构互连的IPv6/IPv4主机可以在它们之间通过隧道传输IPv6数据包。在这种情况下，隧道跨越数据包所采用的整个端到端路径。
- Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. This tunnel spans only the last segment of the end-to-end path.
- 路由器到主机。IPv6/IPv4路由器可以通过隧道将IPv6数据包传输到其最终目标IPv6/IPv4主机。此隧道仅跨越端到端路径的最后一段。
Tunneling techniques are usually classified according to the mechanism by which the encapsulating node determines the address of the node at the end of the tunnel. In the first two tunneling methods listed above -- router-to-router and host-to-router -- the IPv6 packet is being tunneled to a router. The endpoint of this type of tunnel is an intermediary router which must decapsulate the IPv6 packet and forward it on to its final destination. When tunneling to a router, the endpoint of the tunnel is different from the destination of the packet being tunneled. So the addresses in the IPv6 packet being tunneled can not provide the IPv4 address of the tunnel endpoint. Instead, the tunnel endpoint address must be determined from configuration information on the node performing the tunneling. We use the term "configured tunneling" to describe the type of tunneling where the endpoint is explicitly configured.
隧道技术通常根据封装节点确定隧道末端节点地址的机制进行分类。在上面列出的前两种隧道方法（路由器到路由器和主机到路由器）中，IPv6数据包通过隧道传输到路由器。这种隧道类型的端点是一个中间路由器，它必须解除IPv6数据包的封装并将其转发到其最终目的地。当隧道传输到路由器时，隧道的端点与被隧道传输的数据包的目的地不同。因此，被隧道化的IPv6数据包中的地址不能提供隧道端点的IPv4地址。相反，隧道端点地址必须根据执行隧道的节点上的配置信息确定。我们使用术语“配置的隧道”来描述显式配置端点的隧道类型。
In the last two tunneling methods -- host-to-host and router-to-host -- the IPv6 packet is tunneled all the way to its final destination. In this case, the destination address of both the IPv6 packet and the encapsulating IPv4 header identify the same node! This fact can be exploited by encoding information in the IPv6 destination address that will allow the encapsulating node to determine tunnel endpoint IPv4 address automatically. Automatic tunneling employs this technique, using an special IPv6 address format with an embedded IPv4 address to allow tunneling nodes to automatically derive the tunnel endpoint IPv4 address. This eliminates the need to explicitly configure the tunnel endpoint address, greatly simplifying configuration.
在最后两种隧道方法（主机到主机和路由器到主机）中，IPv6数据包通过隧道一直传输到其最终目的地。在这种情况下，IPv6数据包和封装IPv4报头的目标地址标识相同的节点！可以通过对IPv6目标地址中的信息进行编码来利用这一事实，这将允许封装节点自动确定隧道端点IPv4地址。自动隧道采用这种技术，使用带有嵌入式IPv4地址的特殊IPv6地址格式，允许隧道节点自动派生隧道端点IPv4地址。这消除了显式配置隧道端点地址的需要，大大简化了配置。
The two tunneling techniques -- automatic and configured -- differ primarily in how they determine the tunnel endpoint address. Most of the underlying mechanisms are the same:
自动和配置这两种隧道技术的主要区别在于它们如何确定隧道端点地址。大多数基本机制都是相同的：
- The entry node of the tunnel (the encapsulating node) creates an encapsulating IPv4 header and transmits the encapsulated packet.
- 隧道的入口节点（封装节点）创建封装IPv4报头并传输封装的数据包。
- The exit node of the tunnel (the decapsulating node) receives the encapsulated packet, reassembles the packet if needed, removes the IPv4 header, updates the IPv6 header, and processes the received IPv6 packet.
- 隧道的出口节点（解除封装节点）接收封装的数据包，根据需要重新组装数据包，删除IPv4报头，更新IPv6报头，并处理接收到的IPv6数据包。
- The encapsulating node MAY need to maintain soft state information for each tunnel recording such parameters as the MTU of the tunnel in order to process IPv6 packets forwarded into the tunnel. Since the number of tunnels that any one host or router may be using may grow to be quite large, this state information can be cached and discarded when not in use.
- 封装节点可能需要为记录诸如隧道的MTU之类的参数的每个隧道维护软状态信息，以便处理转发到隧道中的IPv6分组。由于任何一台主机或路由器可能使用的隧道数量可能会增加到相当大，因此在不使用时可以缓存和丢弃此状态信息。
The remainder of this section discusses the common mechanisms that apply to both types of tunneling. Subsequent sections discuss how the tunnel endpoint address is determined for automatic and configured tunneling.
本节剩余部分将讨论适用于这两种类型隧道的常见机制。后续章节将讨论如何为自动和配置的隧道确定隧道端点地址。
The encapsulation of an IPv6 datagram in IPv4 is shown below:
IPv4中IPv6数据报的封装如下所示：
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
Encapsulating IPv6 in IPv4
在IPv4中封装IPv6
In addition to adding an IPv4 header, the encapsulating node also has to handle some more complex issues:
除了添加IPv4标头外，封装节点还必须处理一些更复杂的问题：
- Determine when to fragment and when to report an ICMP "packet too big" error back to the source.
- 确定何时对ICMP“数据包太大”错误进行分段以及何时向源报告。
- How to reflect IPv4 ICMP errors from routers along the tunnel path back to the source as IPv6 ICMP errors.
- 如何将路由器沿隧道路径返回到源的IPv4 ICMP错误反映为IPv6 ICMP错误。
Those issues are discussed in the following sections.
以下各节将讨论这些问题。
The encapsulating node could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulating node would need only to report IPv6 ICMP "packet too big" errors back to the source for packets that exceed this MTU. However, such a scheme would be inefficient for two reasons:
封装节点可以将封装视为IPv6，使用IPv4作为具有非常大MTU的链路层（准确地说是65535-20字节；封装IPv4报头需要20字节“额外”）。对于超过此MTU的数据包，封装节点只需向源报告IPv6 ICMP“数据包太大”错误。然而，由于两个原因，这样的计划效率低下：
1) It would result in more fragmentation than needed. IPv4 layer fragmentation SHOULD be avoided due to the performance problems caused by the loss unit being smaller than the retransmission unit [11].
1) 这将导致比需要更多的碎片。由于丢失单元小于重传单元而导致的性能问题，应避免IPv4层碎片[11]。
2) Any IPv4 fragmentation occurring inside the tunnel would have to be reassembled at the tunnel endpoint. For tunnels that terminate at a router, this would require additional memory to reassemble the IPv4 fragments into a complete IPv6 packet before that packet could be forwarded onward.
2) 隧道内发生的任何IPv4碎片都必须在隧道端点重新组装。对于在路由器上终止的隧道，这将需要额外的内存来将IPv4片段重新组装成完整的IPv6数据包，然后才能转发该数据包。
The fragmentation inside the tunnel can be reduced to a minimum by having the encapsulating node track the IPv4 Path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording the resulting path MTU. The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header.
通过让封装节点跨隧道跟踪IPv4路径MTU，使用IPv4路径MTU发现协议[8]并记录生成的路径MTU，可以将隧道内的碎片减少到最小。然后，封装节点中的IPv6层可以将隧道视为MTU等于IPv4路径MTU减去封装IPv4报头大小的链路层。
Note that this does not completely eliminate IPv4 fragmentation in the case when the IPv4 path MTU would result in an IPv6 MTU less than 1280 bytes. (Any link layer used by IPv6 has to have an MTU of at least 1280 bytes [4].) In this case the IPv6 layer has to "see" a link layer with an MTU of 1280 bytes and the encapsulating node has to use IPv4 fragmentation in order to forward the 1280 byte IPv6 packets.
请注意，当IPv4路径MTU将导致IPv6 MTU小于1280字节时，这并不能完全消除IPv4碎片。（IPv6使用的任何链路层必须具有至少1280字节的MTU[4]）在这种情况下，IPv6层必须“查看”MTU为1280字节的链路层，并且封装节点必须使用IPv4分段以转发1280字节的IPv6数据包。
The encapsulating node can employ the following algorithm to determine when to forward an IPv6 packet that is larger than the tunnel's path MTU using IPv4 fragmentation, and when to return an IPv6 ICMP "packet too big" message:
封装节点可以采用以下算法来确定何时使用IPv4分段转发大于隧道路径MTU的IPv6数据包，以及何时返回IPv6 ICMP“数据包太大”消息：
if (IPv4 path MTU - 20) is less than or equal to 1280
if packet is larger than 1280 bytes
Send IPv6 ICMP "packet too big" with MTU = 1280.
Drop packet.
else
Encapsulate but do not set the Don't Fragment
flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer on
the encapsulating node or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send IPv6 ICMP "packet too big" with
MTU = (IPv4 path MTU - 20).
Drop packet.
else
if (IPv4 path MTU - 20) is less than or equal to 1280
if packet is larger than 1280 bytes
Send IPv6 ICMP "packet too big" with MTU = 1280.
Drop packet.
else
Encapsulate but do not set the Don't Fragment
flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer on
the encapsulating node or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send IPv6 ICMP "packet too big" with
MTU = (IPv4 path MTU - 20).
Drop packet.
else
Encapsulate and set the Don't Fragment flag in the IPv4 header. endif endif
封装并设置IPv4标头中的“不分段”标志。endif endif
Encapsulating nodes that have a large number of tunnels might not be able to store the IPv4 Path MTU for all tunnels. Such nodes can, at the expense of additional fragmentation in the network, avoid using the IPv4 Path MTU algorithm across the tunnel and instead use the MTU of the link layer (under IPv4) in the above algorithm instead of the IPv4 path MTU.
封装具有大量隧道的节点可能无法存储所有隧道的IPv4路径MTU。这些节点可以以网络中的额外碎片为代价，避免在隧道中使用IPv4路径MTU算法，而是在上述算法中使用链路层（IPv4下）的MTU，而不是IPv4路径MTU。
In this case the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header.
在这种情况下，不得在封装IPv4标头中设置“不分段”位。
IPv6-over-IPv4 tunnels are modeled as "single-hop". That is, the IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the tunnel. The single-hop model serves to hide the existence of a tunnel. The tunnel is opaque to users of the network, and is not detectable by network diagnostic tools such as traceroute.
IPv6-over-IPv4隧道被建模为“单跳”。也就是说，当IPv6数据包通过隧道时，IPv6跃点限制减少1。单跳模型用于隐藏隧道的存在。隧道对网络用户来说是不透明的，并且不能被网络诊断工具（如traceroute）检测到。
The single-hop model is implemented by having the encapsulating and decapsulating nodes process the IPv6 hop limit field as they would if they were forwarding a packet on to any other datalink. That is, they decrement the hop limit by 1 when forwarding an IPv6 packet. (The originating node and final destination do not decrement the hop limit.)
单跳模型是通过让封装和解封装节点处理IPv6跳限制字段来实现的，就像它们将数据包转发到任何其他数据链路时一样。也就是说，它们在转发IPv6数据包时将跃点限制减少1。（发起节点和最终目的地不减少跃点限制。）
The TTL of the encapsulating IPv4 header is selected in an implementation dependent manner. The current suggested value is published in the "Assigned Numbers RFC. Implementations MAY provide a mechanism to allow the administrator to configure the IPv4 TTL such as the one specified in the IP Tunnel MIB [17].
封装IPv4报头的TTL是以依赖于实现的方式选择的。当前建议值发布在“分配号码RFC”中。实施可能提供一种机制，允许管理员配置IPv4 TTL，如IP隧道MIB中指定的TTL[17]。
In response to encapsulated packets it has sent into the tunnel, the encapsulating node might receive IPv4 ICMP error messages from IPv4 routers inside the tunnel. These packets are addressed to the encapsulating node because it is the IPv4 source of the encapsulated packet.
作为对已发送到隧道中的封装数据包的响应，封装节点可能会从隧道内的IPv4路由器接收IPv4 ICMP错误消息。这些数据包被发送到封装节点，因为它是封装数据包的IPv4源。
The ICMP "packet too big" error messages are handled according to IPv4 Path MTU Discovery [8] and the resulting path MTU is recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to determine if an IPv6 ICMP "packet too big" error has to be generated as described in section 3.2.
ICMP“数据包太大”错误消息根据IPv4路径MTU发现[8]进行处理，结果路径MTU记录在IPv4层中。IPv6使用记录的路径MTU来确定是否必须生成IPv6 ICMP“数据包太大”错误，如第3.2节所述。
The handling of other types of ICMP error messages depends on how much information is included in the "packet in error" field, which holds the encapsulated packet that caused the error.
其他类型ICMP错误消息的处理取决于“错误中的数据包”字段中包含多少信息，该字段保存导致错误的封装数据包。
Many older IPv4 routers return only 8 bytes of data beyond the IPv4 header of the packet in error, which is not enough to include the address fields of the IPv6 header. More modern IPv4 routers are likely to return enough data beyond the IPv4 header to include the entire IPv6 header and possibly even the data beyond that.
许多较旧的IPv4路由器只返回数据包IPv4报头以外的8字节数据，这不足以包含IPv6报头的地址字段。更现代的IPv4路由器可能会返回足够多的超出IPv4报头的数据，以包括整个IPv6报头，甚至可能包括超出该报头的数据。
If the offending packet includes enough data, the encapsulating node MAY extract the encapsulated IPv6 packet and use it to generate an IPv6 ICMP message directed back to the originating IPv6 node, as shown below:
如果有问题的数据包包含足够的数据，则封装节点可以提取封装的IPv6数据包，并使用它生成定向回发起IPv6节点的IPv6 ICMP消息，如下所示：
+--------------+
| IPv4 Header |
| dst = encaps |
| node |
+--------------+
| ICMP |
| Header |
- - +--------------+
| IPv4 Header |
| src = encaps |
IPv4 | node |
+--------------+ - -
Packet | IPv6 |
| Header | Original IPv6
in +--------------+ Packet -
| Transport | Can be used to
Error | Header | generate an
+--------------+ IPv6 ICMP
| | error message
~ Data ~ back to the source.
| |
- - +--------------+ - -
+--------------+
| IPv4 Header |
| dst = encaps |
| node |
+--------------+
| ICMP |
| Header |
- - +--------------+
| IPv4 Header |
| src = encaps |
IPv4 | node |
+--------------+ - -
Packet | IPv6 |
| Header | Original IPv6
in +--------------+ Packet -
| Transport | Can be used to
Error | Header | generate an
+--------------+ IPv6 ICMP
| | error message
~ Data ~ back to the source.
| |
- - +--------------+ - -
IPv4 ICMP Error Message Returned to Encapsulating Node
IPv4 ICMP错误消息返回到封装节点
When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 header fields are set as follows:
在IPv4数据报中封装IPv6数据包时，IPv4标头字段设置如下：
Version:
版本：
4
4.
IP Header Length in 32-bit words:
IP标头长度（32位字）：
5 (There are no IPv4 options in the encapsulating header.)
5（封装标头中没有IPv4选项。）
Type of Service:
服务类别：
0. [Note that work underway in the IETF is redefining the Type of Service byte and as a result future RFCs might define a different behavior for the ToS byte when tunneling.]
0. [注意，IETF中正在进行的工作是重新定义服务字节的类型，因此未来RFC可能会在隧道时为ToS字节定义不同的行为。]
Total Length:
总长度：
Payload length from IPv6 header plus length of IPv6 and IPv4 headers (i.e. a constant 60 bytes).
IPv6标头的有效负载长度加上IPv6和IPv4标头的长度（即恒定的60字节）。
Identification:
识别：
Generated uniquely as for any IPv4 packet transmitted by the system.
为系统传输的任何IPv4数据包唯一生成。
Flags:
旗帜：
Set the Don't Fragment (DF) flag as specified in section 3.2. Set the More Fragments (MF) bit as necessary if fragmenting.
按照第3.2节的规定设置不分段（DF）标志。如果需要碎片，请根据需要设置更多碎片（MF）位。
Fragment offset:
碎片偏移量：
Set as necessary if fragmenting.
如有必要，设置为碎片。
Time to Live:
生存时间：
Set in implementation-specific manner.
以特定于实现的方式设置。
Protocol:
协议：
41 (Assigned payload type number for IPv6)
41（为IPv6分配的有效负载类型号）
Header Checksum:
标题校验和：
Calculate the checksum of the IPv4 header.
计算IPv4标头的校验和。
Source Address:
来源地址：
IPv4 address of outgoing interface of the encapsulating node.
封装节点的传出接口的IPv4地址。
Destination Address:
目的地地址：
IPv4 address of tunnel endpoint.
隧道终结点的IPv4地址。
Any IPv6 options are preserved in the packet (after the IPv6 header).
任何IPv6选项都保留在数据包中（在IPv6标头之后）。
When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 address, and the value of the protocol field is 41, it reassembles if the packet if it is fragmented at the IPv4 level, then it removes the IPv4 header and submits the IPv6 datagram to its IPv6 layer code.
当IPv6/IPv4主机或路由器接收到一个地址为其自己的IPv4地址之一的IPv4数据报，并且协议字段的值为41时，如果该数据包在IPv4级别被分段，则它将重新组装，然后删除IPv4报头并将IPv6数据报提交给其IPv6层代码。
The decapsulating node MUST be capable of reassembling an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).
解封装节点必须能够重新组装1300字节（1280字节加IPv4报头）的IPv4数据包。
The decapsulation is shown below:
脱封过程如下所示：
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
Decapsulating IPv6 from IPv4
从IPv4解除IPv6的封装
When decapsulating the packet, the IPv6 header is not modified. [Note that work underway in the IETF is redefining the Type of Service byte and as a result future RFCs might define a different behavior for the ToS byte when decapsulating a tunneled packet.] If the packet is subsequently forwarded, its hop limit is decremented by one.
解除对数据包的封装时，不会修改IPv6标头。[请注意，IETF中正在进行的工作是重新定义服务字节的类型，因此，未来RFC可能会在解除隧道数据包的封装时为ToS字节定义不同的行为。]如果随后转发数据包，则其跳数限制将减少1。
As part of the decapsulation the node SHOULD silently discard a packet with an invalid IPv4 source address such as a multicast address, a broadcast address, 0.0.0.0, and 127.0.0.1. In general it SHOULD apply the rules for martian filtering in [18] and ingress filtering [13] on the IPv4 source address.
作为解除封装的一部分，节点应悄悄丢弃具有无效IPv4源地址（如多播地址、广播地址、0.0.0和127.0.0.1）的数据包。一般来说，它应该对IPv4源地址应用[18]中的火星筛选规则和[13]中的入口筛选规则。
The encapsulating IPv4 header is discarded.
将丢弃封装IPv4标头。
After the decapsulation the node SHOULD silently discard a packet with an invalid IPv6 source address. This includes IPv6 multicast addresses, the unspecified address, and the loopback address but also IPv4-compatible IPv6 source addresses where the IPv4 part of the address is an (IPv4) multicast address, broadcast address, 0.0.0.0, or 127.0.0.1. In general it SHOULD apply the rules for martian filtering in [18] and ingress filtering [13] on the IPv4-compatible source address.
在解除封装后，节点应自动丢弃具有无效IPv6源地址的数据包。这包括IPv6多播地址、未指定地址和环回地址，但也包括与IPv4兼容的IPv6源地址，其中地址的IPv4部分是（IPv4）多播地址、广播地址、0.0.0或127.0.0.1。一般来说，它应该在IPv4兼容源地址上应用[18]中的火星筛选规则和[13]中的入口筛选规则。
The decapsulating node performs IPv4 reassembly before decapsulating the IPv6 packet. All IPv6 options are preserved even if the encapsulating IPv4 packet is fragmented.
解封节点在解封IPv6数据包之前执行IPv4重新组装。即使封装的IPv4数据包是碎片化的，所有IPv6选项都将保留。
After the IPv6 packet is decapsulated, it is processed almost the same as any received IPv6 packet. The only difference being that a decapsulated packet MUST NOT be forwarded unless the node has been explicitly configured to forward such packets for the given IPv4 source address. This configuration can be implicit in e.g., having a configured tunnel which matches the IPv4 source address. This restriction is needed to prevent tunneling to be used as a tool to circumvent ingress filtering [13].
IPv6数据包解除封装后，其处理方式与任何接收到的IPv6数据包几乎相同。唯一的区别是，除非节点已明确配置为针对给定IPv4源地址转发此类数据包，否则不得转发已解除封装的数据包。此配置可以隐式表示，例如，具有与IPv4源地址匹配的已配置隧道。这种限制是为了防止隧道被用作绕过入口过滤的工具[13]。
Both the configured and automatic tunnels are IPv6 interfaces (over the IPv4 "link layer") thus MUST have link-local addresses. The link-local addresses are used by routing protocols operating over the tunnels.
配置隧道和自动隧道都是IPv6接口（通过IPv4“链路层”），因此必须具有链路本地地址。链路本地地址由在隧道上运行的路由协议使用。
The Interface Identifier [14] for such an Interface SHOULD be the 32-bit IPv4 address of that interface, with the bytes in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Note that the
此类接口的接口标识符[14]应为该接口的32位IPv4地址，字节的顺序与它们在IPv4数据包报头中出现的顺序相同，左侧用零填充，总计64位。请注意
"Universal/Local" bit is zero, indicating that the Interface Identifier is not globally unique. When the host has more than one IPv4 address in use on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made.
“通用/本地”位为零，表示接口标识符不是全局唯一的。当主机在相关物理接口上使用多个IPv4地址时，将对其中一个IPv4地址进行管理选择。
The IPv6 Link-local address [14] for an IPv4 virtual interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IPv4虚拟接口的IPv6链路本地地址[14]是通过将接口标识符（如上所述）附加到前缀FE80:：/64来形成的。
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
Automatic tunnels and unidirectional configured tunnels are considered to be unidirectional. Thus the only aspects of Neighbor Discovery [7] and Stateless Address Autoconfiguration [5] that apply to these tunnels is the formation of the link-local address.
自动隧道和单向配置隧道被认为是单向的。因此，适用于这些隧道的邻居发现[7]和无状态地址自动配置[5]的唯一方面是链路本地地址的形成。
If an implementation provides bidirectional configured tunnels it MUST at least accept and respond to the probe packets used by Neighbor Unreachability Detection [7]. Such implementations SHOULD also send NUD probe packets to detect when the configured tunnel fails at which point the implementation can use an alternate path to reach the destination. Note that Neighbor Discovery allows that the sending of NUD probes be omitted for router to router links if the routing protocol tracks bidirectional reachability.
如果一个实现提供了双向配置的隧道，它必须至少接受和响应邻居不可达性检测所使用的探测数据包[7]。此类实现还应发送NUD探测数据包，以检测所配置的隧道何时失败，在该点上，实现可以使用备用路径到达目的地。注意，如果路由协议跟踪双向可达性，则邻居发现允许省略路由器到路由器链路的NUD探测发送。
For the purposes of Neighbor Discovery the automatic and configured tunnels specified in this document as assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have address. This means that a sender of Neighbor Discovery packets
出于邻居发现的目的，本文档中指定的自动和配置隧道假定没有链路层地址，即使链路层（IPv4）没有地址。这意味着邻居发现数据包的发送方
- SHOULD NOT include Source Link Layer Address options or Target Link Layer Address options on the tunnel link.
- 不应在隧道链路上包括源链路层地址选项或目标链路层地址选项。
- MUST silently ignore any received SLLA or TLLA options on the tunnel link.
- 必须以静默方式忽略隧道链路上接收到的任何SLLA或TLLA选项。
In configured tunneling, the tunnel endpoint address is determined from configuration information in the encapsulating node. For each tunnel, the encapsulating node must store the tunnel endpoint address. When an IPv6 packet is transmitted over a tunnel, the
在已配置的隧道中，隧道端点地址由封装节点中的配置信息确定。对于每个隧道，封装节点必须存储隧道端点地址。当通过隧道传输IPv6数据包时
tunnel endpoint address configured for that tunnel is used as the destination address for the encapsulating IPv4 header.
为该隧道配置的隧道端点地址用作封装IPv4标头的目标地址。
The determination of which packets to tunnel is usually made by routing information on the encapsulating node. This is usually done via a routing table, which directs packets based on their destination address using the prefix mask and match technique.
通常通过封装节点上的路由信息来确定要隧道哪些数据包。这通常是通过路由表完成的，路由表使用前缀掩码和匹配技术根据数据包的目的地地址指示数据包。
IPv6/IPv4 hosts that are connected to datalinks with no IPv6 routers MAY use a configured tunnel to reach an IPv6 router. This tunnel allows the host to communicate with the rest of the IPv6 Internet (i.e. nodes with IPv6-native addresses). If the IPv4 address of an IPv6/IPv4 router bordering the IPv6 backbone is known, this can be used as the tunnel endpoint address. This tunnel can be configured into the routing table as an IPv6 "default route". That is, all IPv6 destination addresses will match the route and could potentially traverse the tunnel. Since the "mask length" of such a default route is zero, it will be used only if there are no other routes with a longer mask that match the destination. The default configured tunnel can be used in conjunction with automatic tunneling, as described in section 5.4.
连接到没有IPv6路由器的数据链路的IPv6/IPv4主机可以使用配置的隧道到达IPv6路由器。此隧道允许主机与IPv6 Internet的其余部分（即具有IPv6本机地址的节点）通信。如果与IPv6主干相邻的IPv6/IPv4路由器的IPv4地址已知，则可以将其用作隧道端点地址。此隧道可以作为IPv6“默认路由”配置到路由表中。也就是说，所有IPv6目标地址都将与路由匹配，并可能穿越隧道。由于这种默认路由的“掩码长度”为零，因此只有当没有其他具有与目的地匹配的更长掩码的路由时，才会使用它。默认配置的隧道可与自动隧道一起使用，如第5.4节所述。
The tunnel endpoint address of such a default tunnel could be the IPv4 address of one IPv6/IPv4 router at the border of the IPv6 backbone. Alternatively, the tunnel endpoint could be an IPv4 "anycast address". With this approach, multiple IPv6/IPv4 routers at the border advertise IPv4 reachability to the same IPv4 address. All of these routers accept packets to this address as their own, and will decapsulate IPv6 packets tunneled to this address. When an IPv6/IPv4 node sends an encapsulated packet to this address, it will be delivered to only one of the border routers, but the sending node will not know which one. The IPv4 routing system will generally carry the traffic to the closest router.
这种默认隧道的隧道端点地址可以是IPv6主干边界处的一个IPv6/IPv4路由器的IPv4地址。或者，隧道端点可以是IPv4“选播地址”。通过这种方法，边界上的多个IPv6/IPv4路由器将IPv4可达性通告到同一IPv4地址。所有这些路由器都将发送到此地址的数据包作为自己的数据包接受，并将对通过隧道发送到此地址的IPv6数据包进行解密。当IPv6/IPv4节点将封装的数据包发送到此地址时，它将只发送到一个边界路由器，但发送节点不知道是哪一个。IPv4路由系统通常将流量传送到最近的路由器。
Using a default tunnel to an IPv4 "anycast address" provides a high degree of robustness since multiple border router can be provided, and, using the normal fallback mechanisms of IPv4 routing, traffic will automatically switch to another router when one goes down. However, care must be taking when using such a default tunnel to prevent different IPv4 fragments from arriving at different routers for reassembly. This can be prevented by either avoiding fragmentation of the encapsulated packets (by ensuring an IPv4 MTU of at least 1300 bytes) or by preventing frequent changes to IPv4 routing.
使用到IPv4“选播地址”的默认隧道提供了高度的健壮性，因为可以提供多个边界路由器，并且，使用IPv4路由的正常回退机制，当一个路由器出现故障时，流量将自动切换到另一个路由器。然而，在使用这样一个默认隧道时必须小心，以防止不同的IPv4片段到达不同的路由器进行重新组装。这可以通过避免封装数据包的碎片化（通过确保IPv4 MTU至少为1300字节）或防止频繁更改IPv4路由来防止。
The decapsulating node MUST verify that the tunnel source address is acceptable before forwarding decapsulated packets to avoid circumventing ingress filtering [13]. Note that packets which are delivered to transport protocols on the decapsulating node SHOULD NOT be subject to these checks. For bidirectional configured tunnels this is done by verifying that the source address is the IPv4 address of the other end of the tunnel. For unidirectional configured tunnels the decapsulating node MUST be configured with a list of source IPv4 address prefixes that are acceptable. Such a list MUST default to not having any entries i.e. the node has to be explicitly configured to forward decapsulated packets received over unidirectional configured tunnels.
解封节点必须在转发解封数据包之前验证隧道源地址是否可接受，以避免绕过入口过滤[13]。请注意，发送到解封装节点上的传输协议的数据包不应接受这些检查。对于双向配置的隧道，这是通过验证源地址是否为隧道另一端的IPv4地址来完成的。对于单向配置的隧道，解封装节点必须配置可接受的源IPv4地址前缀列表。这样的列表必须默认为没有任何条目，即节点必须明确配置为转发通过单向配置的隧道接收的解除封装的数据包。
In automatic tunneling, the tunnel endpoint address is determined by the IPv4-compatible destination address of the IPv6 packet being tunneled. Automatic tunneling allows IPv6/IPv4 nodes to communicate over IPv4 routing infrastructures without pre-configuring tunnels.
在自动隧道中，隧道端点地址由正在隧道的IPv6数据包的IPv4兼容目标地址确定。自动隧道允许IPv6/IPv4节点通过IPv4路由基础结构进行通信，而无需预先配置隧道。
IPv6/IPv4 nodes that perform automatic tunneling are assigned IPv4- compatible address. An IPv4-compatible address is identified by an all-zeros 96-bit prefix, and holds an IPv4 address in the low-order 32-bits. IPv4-compatible addresses are structured as follows:
为执行自动隧道的IPv6/IPv4节点分配与IPv4兼容的地址。IPv4兼容地址由全零96位前缀标识，并将IPv4地址保持在低位32位。IPv4兼容地址的结构如下所示：
| 96-bits | 32-bits |
+--------------------------------------+--------------+
| 0:0:0:0:0:0 | IPv4 Address |
+--------------------------------------+--------------+
IPv4-Compatible IPv6 Address Format
| 96-bits | 32-bits |
+--------------------------------------+--------------+
| 0:0:0:0:0:0 | IPv4 Address |
+--------------------------------------+--------------+
IPv4-Compatible IPv6 Address Format
IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunneling. A node SHOULD be configured with an IPv4-compatible address only if it is prepared to accept IPv6 packets destined to that address encapsulated in IPv4 packets destined to the embedded IPv4 address.
IPv4兼容地址专门分配给支持自动隧道的节点。仅当节点准备接受以该地址为目的地的IPv6数据包（封装在以嵌入IPv4地址为目的地的IPv4数据包中）时，才应使用IPv4兼容地址配置节点。
An IPv4-compatible address is globally unique as long as the IPv4 address is not from the private IPv4 address space [15]. An implementation SHOULD behave as if its IPv4-compatible address(es) are assigned to the node's automatic tunneling interface, even if the implementation does not implement automatic tunneling using a concept of interfaces. Thus the IPv4-compatible address SHOULD NOT be viewed as being attached to e.g. an Ethernet interface i.e. implications
只要IPv4地址不是来自专用IPv4地址空间，IPv4兼容地址就具有全局唯一性[15]。即使实现没有使用接口概念实现自动隧道，实现的行为也应与将其IPv4兼容地址分配给节点的自动隧道接口的行为相同。因此，不应将IPv4兼容地址视为连接到以太网接口，即
should not use the Neighbor Discovery mechanisms like NUD [7] at the Ethernet. Any such interactions should be done using the encapsulated packets i.e. over the automatic tunneling (conceptual) interface.
不应在以太网上使用NUD[7]等邻居发现机制。任何此类交互都应使用封装的数据包完成，即通过自动隧道（概念）接口。
An IPv6/IPv4 node with an IPv4-compatible address uses that address as one of its IPv6 addresses, while the IPv4 address embedded in the low-order 32-bits serves as the IPv4 address for one of its interfaces.
具有IPv4兼容地址的IPv6/IPv4节点将该地址用作其IPv6地址之一，而嵌入低位32位的IPv4地址用作其接口之一的IPv4地址。
An IPv6/IPv4 node MAY acquire its IPv4-compatible IPv6 addresses via IPv4 address configuration protocols. It MAY use any IPv4 address configuration mechanism to acquire its IPv4 address, then "map" that address into an IPv4-compatible IPv6 address by pre-pending it with the 96-bit prefix 0:0:0:0:0:0. This mode of configuration allows IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address configuration servers.
IPv6/IPv4节点可以通过IPv4地址配置协议获取其IPv4兼容的IPv6地址。它可以使用任何IPv4地址配置机制获取其IPv4地址，然后通过使用96位前缀0:0:0:0:0预挂起该地址，将该地址“映射”到与IPv4兼容的IPv6地址。此配置模式允许IPv6/IPv4节点“利用”IPv4地址配置服务器的已安装基础。
The specific algorithm for acquiring an IPv4-compatible address using IPv4-based address configuration protocols is as follows:
使用基于IPv4的地址配置协议获取IPv4兼容地址的具体算法如下：
1) The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols to acquire the IPv4 address for one of its interfaces. These include:
1) IPv6/IPv4节点使用标准IPv4机制或协议获取其某个接口的IPv4地址。这些措施包括：
- The Dynamic Host Configuration Protocol (DHCP) [2]
- 动态主机配置协议（DHCP）[2]
- The Bootstrap Protocol (BOOTP) [1]
- 引导协议（BOOTP）[1]
- The Reverse Address Resolution Protocol (RARP) [9]
- 反向地址解析协议（RARP）[9]
- Manual configuration
- 手动配置
- Any other mechanism which accurately yields the node's own IPv4 address
- 准确生成节点自己的IPv4地址的任何其他机制
2) The node uses this address as the IPv4 address for this interface.
2) 节点将此地址用作此接口的IPv4地址。
3) The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit IPv4 address that it acquired in step (1). The result is an IPv4- compatible IPv6 address with one of the node's IPv4-addresses embedded in the low-order 32-bits. The node uses this address as one of its IPv6 addresses.
3) 节点将96位前缀0:0:0:0:0:0作为其在步骤（1）中获取的32位IPv4地址的前缀。结果是一个IPv4兼容的IPv6地址，其中一个节点的IPv4地址嵌入在低位32位中。节点将此地址用作其IPv6地址之一。
In automatic tunneling, the tunnel endpoint address is determined from the packet being tunneled. If the destination IPv6 address is IPv4-compatible, then the packet can be sent via automatic tunneling. If the destination is IPv6-native, the packet can not be sent via automatic tunneling.
在自动隧道中，隧道端点地址由正在隧道的数据包确定。如果目标IPv6地址与IPv4兼容，则可以通过自动隧道发送数据包。如果目标是IPv6本机，则无法通过自动隧道发送数据包。
A routing table entry can be used to direct automatic tunneling. An implementation can have a special static routing table entry for the prefix 0:0:0:0:0:0/96. (That is, a route to the all-zeros prefix with a 96-bit mask.) Packets that match this prefix are sent to a pseudo-interface driver which performs automatic tunneling. Since all IPv4-compatible IPv6 addresses will match this prefix, all packets to those destinations will be auto-tunneled.
路由表条目可用于指导自动隧道。一个实现可以有一个前缀为0:0:0:0:0:0/96的特殊静态路由表条目。（即，到带有96位掩码的全零前缀的路由。）匹配此前缀的数据包被发送到执行自动隧道的伪接口驱动程序。由于所有与IPv4兼容的IPv6地址都将与此前缀匹配，因此到这些目的地的所有数据包都将自动通过隧道传输。
Once it is delivered to the automatic tunneling module, the IPv6 packet is encapsulated within an IPv4 header according to the rules described in section 3. The source and destination addresses of the encapsulating IPv4 header are assigned as follows:
一旦它被传送到自动隧道模块，IPv6数据包将根据第3节中描述的规则封装在IPv4报头中。封装IPv4标头的源地址和目标地址分配如下：
Destination IPv4 address:
目标IPv4地址：
Low-order 32-bits of IPv6 destination address
IPv6目标地址的低位32位
Source IPv4 address:
源IPv4地址：
IPv4 address of interface the packet is sent via
数据包通过的接口的IPv4地址
The automatic tunneling module always sends packets in this encapsulated form, even if the destination is on an attached datalink.
自动隧道模块始终以这种封装形式发送数据包，即使目的地位于连接的数据链路上。
The automatic tunneling module MUST NOT send to IPv4 broadcast or multicast destinations. It MUST drop all IPv6 packets destined to IPv4-compatible destinations when the embedded IPv4 address is broadcast, multicast, the unspecified (0.0.0.0) address, or the loopback address (127.0.0.1). Note that the sender can only tell if an address is a network or subnet broadcast for broadcast addresses assigned to directly attached links.
自动隧道模块不得发送到IPv4广播或多播目标。当嵌入的IPv4地址为广播、多播、未指定的（0.0.0.0）地址或环回地址（127.0.0.1）时，它必须丢弃所有发往IPv4兼容目标的IPv6数据包。请注意，对于分配给直接连接链接的广播地址，发送方只能判断地址是网络广播还是子网广播。
Automatic tunneling is often used in conjunction with the default configured tunnel technique. "Isolated" IPv6/IPv4 hosts -- those with no on-link IPv6 routers -- are configured to use automatic tunneling and IPv4-compatible IPv6 addresses, and have at least one default configured tunnel to an IPv6 router. That IPv6 router is
自动隧道通常与默认配置的隧道技术结合使用。“隔离的”IPv6/IPv4主机（那些没有链路上IPv6路由器的主机）配置为使用自动隧道和与IPv4兼容的IPv6地址，并且至少有一个到IPv6路由器的默认配置隧道。那个IPv6路由器是
configured to perform automatic tunneling as well. These isolated hosts send packets to IPv4-compatible destinations via automatic tunneling and packets for IPv6-native destinations via the default configured tunnel. IPv4-compatible destinations will match the 96- bit all-zeros prefix route discussed in the previous section, while IPv6-native destinations will match the default route via the configured tunnel. Reply packets from IPv6-native destinations are routed back to the an IPv6/IPv4 router which delivers them to the original host via automatic tunneling. Further examples of the combination of tunneling techniques are discussed in [12].
配置为同时执行自动隧道。这些隔离主机通过自动隧道将数据包发送到IPv4兼容的目的地，并通过默认配置的隧道将数据包发送到IPv6本机目的地。IPv4兼容的目的地将匹配上一节讨论的96位全零前缀路由，而IPv6本机目的地将通过配置的隧道匹配默认路由。来自IPv6本机目的地的应答数据包被路由回IPv6/IPv4路由器，该路由器通过自动隧道将它们传送到原始主机。[12]中讨论了隧道技术组合的更多示例。
When an IPv6/IPv4 node originates an IPv6 packet, it must select the source IPv6 address to use. IPv6/IPv4 nodes that are configured to perform automatic tunneling may be configured with global IPv6-native addresses as well as IPv4-compatible addresses. The selection of which source address to use will determine what form the return traffic is sent via. If the IPv4-compatible address is used, the return traffic will have to be delivered via automatic tunneling, but if the IPv6-native address is used, the return traffic will not be automatic-tunneled. In order to make traffic as symmetric as possible, the following source address selection preference is RECOMMENDED:
当IPv6/IPv4节点发起IPv6数据包时，它必须选择要使用的源IPv6地址。配置为执行自动隧道的IPv6/IPv4节点可以配置全局IPv6本机地址以及IPv4兼容地址。选择要使用的源地址将决定返回流量的发送形式。如果使用IPv4兼容地址，则返回流量必须通过自动隧道传输，但如果使用IPv6本机地址，则返回流量将不会自动隧道传输。为了使通信尽可能对称，建议使用以下源地址选择首选项：
Destination is IPv4-compatible:
目标与IPv4兼容：
Use IPv4-compatible source address associated with IPv4 address of outgoing interface
使用与传出接口的IPv4地址关联的IPv4兼容源地址
Destination is IPv6-native:
目标是IPv6本机：
Use IPv6-native address of outgoing interface
使用传出接口的IPv6本机地址
If an IPv6/IPv4 node has no global IPv6-native address, but is originating a packet to an IPv6-native destination, it MAY use its IPv4-compatible address as its source address.
如果IPv6/IPv4节点没有全局IPv6本机地址，但正在向IPv6本机目标发送数据包，则可以使用其IPv4兼容地址作为源地址。
The decapsulating node MUST verify that the encapsulated packets are acceptable before forwarding decapsulated packets to avoid circumventing ingress filtering [13]. Note that packets which are delivered to transport protocols on the decapsulating node SHOULD NOT be subject to these checks. Since automatic tunnels always encapsulate to the destination (i.e. the IPv4 destination will be the destination) any packet received over an automatic tunnel SHOULD NOT be forwarded.
解封装节点必须在转发解封装的数据包之前验证封装的数据包是否可接受，以避免绕过入口过滤[13]。请注意，发送到解封装节点上的传输协议的数据包不应接受这些检查。由于自动隧道始终封装到目的地（即IPv4目的地将是目的地），因此不应转发通过自动隧道接收的任何数据包。
We would like to thank the members of the IPng working group and the Next Generation Transition (ngtrans) working group for their many contributions and extensive review of this document. Special thanks are due to Jim Bound, Ross Callon, and Bob Hinden for many helpful suggestions and to John Moy for suggesting the IPv4 "anycast address" default tunnel technique.
我们要感谢IPng工作组和下一代过渡（ngtrans）工作组的成员对本文件的大量贡献和广泛审查。特别感谢Jim Bound、Ross Callon和Bob Hinden提出的许多有益建议，以及John Moy提出的IPv4“选播地址”默认隧道技术。
Tunneling is not known to introduce any security holes except for the possibility to circumvent ingress filtering [13]. This is prevented by requiring that decapsulating routers only forward packets if they have been configured to accept encapsulated packets from the IPv4 source address in the receive packet. Additionally, in the case of automatic tunneling, nodes are required by not forwarding the decapsulated packets since automatic tunneling ends the tunnel and the destination.
目前还不知道隧道会引入任何安全漏洞，除非有可能绕过入口过滤[13]。这是通过要求解除封装的路由器仅在其已配置为从接收数据包中的IPv4源地址接受封装数据包的情况下转发数据包来防止的。此外，在自动隧道的情况下，由于自动隧道结束隧道和目的地，因此不转发解除封装的分组需要节点。
Robert E. Gilligan FreeGate Corp 1208 E. Arques Ave Sunnyvale, CA 94086 USA
罗伯特·吉利根·弗里盖特公司美国加利福尼亚州桑尼维尔市东阿克斯大道1208号，邮编94086
Phone: +1-408-617-1004
Fax: +1-408-617-1010
EMail: gilligan@freegate.com
Phone: +1-408-617-1004
Fax: +1-408-617-1010
EMail: gilligan@freegate.com
Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Rd. Palo Alto, CA 94303 USA
Erik Nordmark Sun Microsystems，Inc.美国加利福尼亚州帕洛阿尔托市圣安东尼奥路901号，邮编94303
Phone: +1-650-786-5166
Fax: +1-650-786-5896
EMail: nordmark@eng.sun.com
Phone: +1-650-786-5166
Fax: +1-650-786-5896
EMail: nordmark@eng.sun.com
[1] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[1] Croft，W.和J.Gilmore，“引导协议”，RFC 9511985年9月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993.
[2] Droms，R.，“动态主机配置协议”，RFC 15411993年10月。
[3] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[3] Carpenter，B.和C.Jung，“无显式隧道的IPv4域上IPv6传输”，RFC 2529，1999年3月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration," RFC 2462, December 1998.
[5] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[6] Crawford, M., Thomson, S., and C. Huitema. "DNS Extensions to Support IPv6 Address Allocation and Renumbering", RFC 2874, July 2000.
[6] M.克劳福德、S.汤姆森和C.惠特马。“支持IPv6地址分配和重新编号的DNS扩展”，RFC 28742000年7月。
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[8] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[8] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[9] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[9] Finlayson，R.，Mann，T.，Mogul，J.和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，1984年6月。
[10] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[10] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[11] Kent, C. and J. Mogul, "Fragmentation Considered Harmful". In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August 1987.
[11] Kent，C.和J.Mogul，“碎片化被认为是有害的”。在过程中。SIGCOMM'87计算机通信技术前沿研讨会。1987年8月。
[12] Callon, R. and D. Haskin, "Routing Aspects of IPv6 Transition", RFC 2185, September 1997.
[12] Callon，R.和D.Haskin，“IPv6过渡的路由方面”，RFC2185，1997年9月。
[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[13] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，RFC 2267，1998年1月。
[14] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[14] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[15] Rechter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[15] 雷克特，Y.，莫斯科维茨，B.，卡伦伯格，D.，德格罗特，G.J.和E.李尔，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[17] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
[17] Thaler，D.，“IP隧道MIB”，RFC 2667，1999年8月。
[18] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[18] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
- Deleted section 3.1.1 (IPv4 loopback address) in order to prevent it from being mis-construed as requiring routers to filter the address ::127.0.0.1, which would put another test in the forwarding path for IPv6 routers.
- 删除了第3.1.1节（IPv4环回地址），以防止错误地将其理解为要求路由器过滤地址：：127.0.0.1，这将在IPv6路由器的转发路径中进行另一项测试。
- Deleted section 4.4 (Default Sending Algorithm). This section allowed nodes to send packets in "raw form" to IPv4-compatible destinations on the same datalink. Implementation experience has shown that this adds complexity which is not justified by the minimal savings in header overhead.
- 删除了第4.4节（默认发送算法）。此部分允许节点以“原始形式”向同一数据链路上的IPv4兼容目标发送数据包。实施经验表明，这增加了复杂性，而这并不是因为报头开销的最小节省就可以实现的。
- Added definitions for operating modes for IPv6/IPv4 nodes.
- 添加了IPv6/IPv4节点的操作模式定义。
- Revised DNS section to clarify resolver filtering and ordering options.
- 修订了DNS部分，以澄清解析程序筛选和排序选项。
- Re-wrote the discussion of IPv4-compatible addresses to clarify that they are used exclusively in conjunction with the automatic tunneling mechanism. Re-organized document to place definition of IPv4-compatible address format with description of automatic tunneling.
- 重新撰写了关于IPv4兼容地址的讨论，以澄清这些地址仅与自动隧道机制结合使用。重新组织文档以放置IPv4兼容地址格式的定义和自动隧道的描述。
- Changed the term "IPv6-only address" to "IPv6-native address" per current usage.
- 根据当前使用情况，将术语“仅IPv6地址”更改为“IPv6本机地址”。
- Updated to algorithm for determining tunnel MTU to reflect the change in the IPv6 minimum MTU from 576 to 1280 bytes [4].
- 更新为用于确定隧道MTU的算法，以反映IPv6最小MTU从576字节到1280字节的变化[4]。
- Deleted the definition for the term "IPv6-in-IPv4 encapsulation." It has not been widely used.
- 删除了术语“IPv6-in-IPv4封装”的定义。该术语尚未广泛使用。
- Revised IPv4-compatible address configuration section (5.2) to recognize multiple interfaces.
- 修订了IPv4兼容地址配置部分（5.2），以识别多个接口。
- Added discussion of source address selection when using IPv4- compatible addresses.
- 添加了使用IPv4兼容地址时源地址选择的讨论。
- Added section on the combination of the default configured tunneling technique with hosts using automatic tunneling.
- 添加了关于默认配置的隧道技术与使用自动隧道的主机的组合的部分。
- Added prohibition against automatic tunneling to IPv4 broadcast or multicast destinations.
- 增加了对自动隧道到IPv4广播或多播目的地的禁止。
- Clarified that configured tunnels can be unidirectional or bidirectional.
- 阐明了配置的隧道可以是单向的，也可以是双向的。
- Added description of bidirectional virtual links as another type of tunnels. Nodes MUST respond to NUD probes on such links and SHOULD send NUD probes.
- 添加了双向虚拟链路作为另一种隧道类型的说明。节点必须响应此类链接上的NUD探测，并应发送NUD探测。
- Added reference to [16] specification as an alternative for tunneling over a multicast capable IPv4 cloud.
- 添加了对[16]规范的参考，作为通过支持多播的IPv4云进行隧道传输的替代方案。
- Clarified that IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunnels i.e. nodes that can receive such packets.
- 阐明IPv4兼容地址仅分配给支持自动隧道的节点，即可以接收此类数据包的节点。
- Added text about formation of link-local addresses and use of Neighbor Discovery on tunnels.
- 添加了关于形成链路本地地址和在隧道上使用邻居发现的文本。
- Added restriction that decapsulated packets not be forwarded unless the source address is acceptable to the decapsulating router.
- 增加了一个限制，即除非解封路由器接受源地址，否则不转发解封数据包。
- Clarified that decapsulating nodes MUST be capable of reassembling an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).
- 阐明了解封装节点必须能够重新组装1300字节（1280字节加IPv4报头）的IPv4数据包。
- Clarified that when using a default tunnel to an IPv4 "anycast address" the network must either have an IPv4 MTU of least 1300 bytes (to avoid fragmentation of minimum size IPv6 packets) or be configured to avoid frequent changes to IPv4 routing to the "anycast address" (to avoid different IPv4 fragments arriving at different tunnel endpoints).
- 阐明当使用IPv4“选播地址”的默认隧道时，网络必须具有至少1300字节的IPv4 MTU（以避免最小大小IPv6数据包的碎片化），或者配置为避免频繁更改IPv4路由到“选播地址”（以避免不同的IPv4碎片到达不同的隧道端点）。
- Using A6/AAAA instead of AAAA to reference IPv6 address records in the DNS.
- 使用A6/AAAA代替AAAA引用DNS中的IPv6地址记录。
- Specified when to put IPv6 addresses in the DNS.
- 指定何时将IPv6地址放入DNS。
- Added reference to the tunnel mib for TTL specification for the tunnels.
- 为隧道的TTL规范添加了隧道mib参考。
- Added a table of contents.
- 增加了一个目录。
- Added recommendations for use of source and target link layer address options for the tunnel links.
- 增加了使用隧道链路的源链路层和目标链路层地址选项的建议。
- Added checks in the decapsulation checking both an IPv4-compatible IPv6 source address and the outer IPv4 source addresses for multicast, broadcast, all-zeros etc.
- 在解封装中添加了检查多播、广播、全零等的IPv4兼容IPv6源地址和外部IPv4源地址的检查。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。