Independent Submission F. Templin, Ed.
Request for Comments: 5579 Boeing Research & Technology
Category: Informational February 2010
ISSN: 2070-1721
Independent Submission F. Templin, Ed.
Request for Comments: 5579 Boeing Research & Technology
Category: Informational February 2010
ISSN: 2070-1721
Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
通过站点内自动隧道寻址协议（ISATAP）接口传输IPv4数据包
Abstract
摘要
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces.
站点内自动隧道寻址协议（ISATAP）指定了一种非广播、多址（NBMA）接口类型，用于使用自动IPv6-in-IPv4封装通过IPv4网络传输IPv6数据包。然而，原始规范没有对IPv4数据包的封装和传输做出规定。本文档指定了通过ISATAP接口传输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/rfc5579.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5579.
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. ISATAP Interface Model ..........................................3
4. ISATAP Interface MTU ............................................4
5. IPv6 Operation ..................................................4
6. IPv4 Operation ..................................................4
6.1. ISATAP IPv4 Address Configuration ..........................4
6.2. IPv4 Route Configuration ...................................5
6.3. ISATAP Interface Determination .............................5
6.4. Next-Hop Resolution ........................................5
6.5. Encapsulation and Transmission .............................6
6.6. IPv4 Multicast Mapping .....................................6
6.7. Recursive Encapsulation Avoidance ..........................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
Appendix A. Encapsulation Avoidance ................................9
1. Introduction ....................................................3
2. Terminology .....................................................3
3. ISATAP Interface Model ..........................................3
4. ISATAP Interface MTU ............................................4
5. IPv6 Operation ..................................................4
6. IPv4 Operation ..................................................4
6.1. ISATAP IPv4 Address Configuration ..........................4
6.2. IPv4 Route Configuration ...................................5
6.3. ISATAP Interface Determination .............................5
6.4. Next-Hop Resolution ........................................5
6.5. Encapsulation and Transmission .............................6
6.6. IPv4 Multicast Mapping .....................................6
6.7. Recursive Encapsulation Avoidance ..........................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
Appendix A. Encapsulation Avoidance ................................9
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. ISATAP interfaces therefore typically configure IPv6 addresses and prefixes, but they do not configure IPv4 addresses and prefixes. In typical implementations and deployments, an ISATAP interface therefore appears as an ordinary interface configured for IPv6 operation but with a null IPv4 configuration. This places an unnecessary limitation on the ISATAP domain of applicability.
站点内自动隧道寻址协议（ISATAP）[RFC5214]指定了一种非广播、多址（NBMA）接口类型，用于使用自动IPv6-in-IPv4封装通过IPv4网络传输IPv6数据包。因此，ISATAP接口通常配置IPv6地址和前缀，但不配置IPv4地址和前缀。在典型的实现和部署中，ISATAP接口因此显示为为IPv6操作配置的普通接口，但具有空IPv4配置。这对ISATAP的适用范围造成了不必要的限制。
ISATAP interfaces perform automatic IPv6-in-IPv4 encapsulation over a virtual IPv6 overlay that spans a region within a connected IPv4 routing topology (i.e., a "site") comprising ordinary IPv4 routers. ISATAP interfaces configure IPv6 link-local addresses that encapsulate an IPv4 address assigned to an underlying IPv4 interface within the IPv6 link-local prefix "fe80::/10", as specified in Sections 6 and 7 of [RFC5214]. ISATAP interfaces may additionally configure IPv6 addresses from a non-link-local IPv6 prefix in exactly the same fashion. As a result, [RFC5214] extends the basic transition mechanisms specified in [RFC4213].
ISATAP接口在虚拟IPv6覆盖上执行IPv6-in-IPv4自动封装，虚拟IPv6覆盖跨越由普通IPv4路由器组成的连接IPv4路由拓扑（即“站点”）内的区域。ISATAP接口配置IPv6链路本地地址，按照[RFC5214]第6节和第7节的规定，这些地址封装了分配给IPv6链路本地前缀“fe80:：/10”内底层IPv4接口的IPv4地址。ISATAP接口还可以以完全相同的方式从非链路本地IPv6前缀配置IPv6地址。因此，[RFC5214]扩展了[RFC4213]中指定的基本转换机制。
This document specifies mechanisms and operational practices that enable automatic IPv4-in-IPv4 encapsulation over ISATAP interfaces in the same manner as for IPv6-in-IPv4 encapsulation. As a result, this document also extends the IPv4-in-IPv4 tunneling mechanisms specified in [RFC2003]. These mechanisms are useful in a wide variety of enterprise network scenarios, e.g., as discussed in the RANGER [RANGER] and VET [VET] proposals.
本文档指定了以与IPv6-in-IPv4封装相同的方式通过ISATAP接口实现IPv4-in-IPv4自动封装的机制和操作实践。因此，本文档还扩展了[RFC2003]中指定的IPv4-in-IPv4隧道机制。这些机制在各种各样的企业网络场景中都很有用，例如，如RANGER[RANGER]和VET[VET]提案中所述。
The following sections specify IPv4 operation over ISATAP interfaces. A working knowledge of the IPv4 and IPv6 protocols ([RFC0791] and [RFC2460]), IPv4-in-IPv4 encapsulation [RFC2003], and IPv6-in-IPv4 encapsulation ([RFC4213] and [RFC5214]) is assumed.
以下各节指定ISATAP接口上的IPv4操作。假设具备IPv4和IPv6协议（[RFC0791]和[RFC2460]）、IPv4-in-IPv4封装[RFC2003]和IPv6-in-IPv4封装（[RFC4213]和[RFC5214]）的工作知识。
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 [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
ISATAP interfaces use automatic IPv6-in-IPv4 encapsulation to span a region within a connected IPv4 routing topology (i.e., a "site") in a single IPv6 hop. That is to say that the site comprises border nodes
ISATAP接口使用自动IPv6-in-IPv4封装来跨越单个IPv6跃点中连接的IPv4路由拓扑（即“站点”）内的区域。也就是说，站点由边界节点组成
with ISATAP interfaces that forward IPv6-in-IPv4 packets across the site in a single IPv6 hop, and ordinary IPv4 routers between the border nodes that decrement the Time to Live (TTL) in the outer IPv4 header. Border nodes that configure ISATAP interfaces within the same site therefore see each other as single-hop neighbors.
通过ISATAP接口，在单个IPv6跃点中跨站点转发IPv6-in-IPv4数据包，以及边界节点之间的普通IPv4路由器，减少外部IPv4报头中的生存时间（TTL）。因此，在同一站点内配置ISATAP接口的边界节点将彼此视为单跳邻居。
ISATAP interfaces are configured over one or more of the node's underlying IPv4 interfaces connected to the site. These underlying IPv4 interfaces configure site- or greater-scoped IPv4 addresses, and the underlying IPv4 interfaces of two "neighboring" ISATAP interfaces may be separated by many IPv4 hops within the site.
ISATAP接口通过连接到站点的一个或多个节点的基础IPv4接口进行配置。这些基础IPv4接口配置站点或更大范围的IPv4地址，两个“相邻”ISATAP接口的基础IPv4接口可能由站点内的许多IPv4跃点分隔。
This specification simply extends the ISATAP interface model to also support IPv4-in-IPv4 encapsulation. When IPv4-in-IPv4 encapsulation is used, the ISATAP interface spans exactly the same underlying site as for IPv6-in-IPv4 encapsulation.
该规范只是扩展了ISATAP接口模型，以支持IPv4-in-IPv4封装。当使用IPv4-in-IPv4封装时，ISATAP接口跨越与IPv6-in-IPv4封装完全相同的基础站点。
ISATAP interface MTU considerations are exactly as specified in Section 3.2 of [RFC4213] and apply equally for both IPv6 and IPv4 operation.
ISATAP接口MTU注意事项与[RFC4213]第3.2节中的规定完全相同，同样适用于IPv6和IPv4操作。
IPv6 operations over ISATAP interfaces are exactly as specified in [RFC5214].
ISATAP接口上的IPv6操作完全符合[RFC5214]中的规定。
The following sections specify IPv4 operation over ISATAP interfaces:
以下部分指定了ISATAP接口上的IPv4操作：
As for IPv6 operation, IPv4 operation requires that all ISATAP interfaces connected to the same site configure a unique Layer 3 IPv4 address ("L3ADDR") taken from an IPv4 prefix for the site. L3ADDR is used for next-hop determination, but it may also be used as the source address for packets that originate from the ISATAP interface itself.
对于IPv6操作，IPv4操作要求连接到同一站点的所有ISATAP接口配置一个唯一的第3层IPv4地址（“L3ADDR”），该地址取自该站点的IPv4前缀。L3ADDR用于下一跳的确定，但也可以用作源自ISATAP接口本身的数据包的源地址。
When a unique "name" for the ISATAP site is required (e.g., to distinguish it from other ISATAP sites), L3ADDR is taken from a public IPv4 prefix. Otherwise, it may be taken from a link-local-scoped IPv4 prefix (e.g., 169.254/16 [RFC3927]).
当需要ISATAP站点的唯一“名称”时（例如，将其与其他ISATAP站点区分开来），L3ADDR取自公共IPv4前缀。否则，它可能来自链路本地作用域IPv4前缀（例如，169.254/16[RFC3927]）。
Methods for ensuring L3ADDR uniqueness include dynamic allocation using DHCP [RFC2131], manual configuration, etc.
确保L3ADDR唯一性的方法包括使用DHCP[RFC2131]的动态分配、手动配置等。
As for any IPv4 interface, IPv4 Forwarding Information Base (FIB) entries (i.e., IPv4 routes) are configured over ISATAP interfaces via either administrative or dynamic mechanisms.
对于任何IPv4接口，IPv4转发信息库（FIB）条目（即IPv4路由）通过管理或动态机制通过ISATAP接口进行配置。
Next-hop addresses in FIB entries configured over an ISATAP interface correspond to the L3ADDR assigned to the ISATAP interface of a neighbor.
通过ISATAP接口配置的FIB条目中的下一跳地址对应于分配给邻居的ISATAP接口的L3ADDR。
When the node's IPv4 layer has a packet to send, it performs an IPv4 FIB lookup to determine the outgoing ISATAP interface and the next-hop L3ADDR. The node then checks the packet length against the MTU configured on the ISATAP interface.
当节点的IPv4层有数据包要发送时，它将执行IPv4 FIB查找以确定传出ISATAP接口和下一跳L3ADDR。然后，节点根据ISATAP接口上配置的MTU检查数据包长度。
If the packet is no larger than the MTU, the node admits it into the ISATAP interface without fragmentation. If the packet is larger than the MTU, the node examines the "Don't Fragment (DF)" flag in the IPv4 header. If DF=1, it drops the packet and returns an ICMPv4 "fragmentation needed" message to the original source [RFC1191]; otherwise, it fragments the packet using IPv4 fragmentation and admits each fragment into the ISATAP interface.
如果数据包不大于MTU，则节点允许其进入ISATAP接口，而不会出现碎片。如果数据包大于MTU，则节点检查IPv4报头中的“不分段（DF）”标志。如果DF=1，则丢弃数据包并将ICMPv4“需要碎片”消息返回给原始源[RFC1191]；否则，它将使用IPv4分段对数据包进行分段，并允许每个分段进入ISATAP接口。
As for ISATAP for IPv6, ISATAP for IPv4 requires a means for determining the L3ADDR of neighbors on the ISATAP interface that can provide a next-hop toward the final destination. Next-hop determination for default routes is through the Potential Router List (PRL) discovery procedures specified in Section 8.3.2 of [RFC5214]. Next-hop determination methods for more-specific routes include forwarding initial packets via a default router until a redirect is received, name service lookup (e.g., as described in [VET]), etc.
至于IPv6的ISATAP，IPv4的ISATAP需要一种方法来确定ISATAP接口上邻居的L3ADDR，该接口可以向最终目的地提供下一跳。通过[RFC5214]第8.3.2节规定的潜在路由器列表（PRL）发现程序确定默认路由的下一跳。用于更具体路由的下一跳确定方法包括经由默认路由器转发初始分组直到接收到重定向、名称服务查找（例如，如[VET]中所述）等。
After a next-hop L3ADDR is discovered, the node admits IPv4 packets/fragments into the ISATAP interface and maps the next-hop L3ADDR into a next-hop Layer 2 address ("L2ADDR"), which in reality is the IPv4 address of an underlying interface of the ISATAP neighbor that may be many IPv4 hops away.
发现下一跳L3ADDR后，节点允许IPv4数据包/片段进入ISATAP接口，并将下一跳L3ADDR映射到下一跳第2层地址（“L2ADDR”），该地址实际上是ISATAP邻居的底层接口的IPv4地址，可能距离IPv4跳数很多。
Address mapping for IPv4 differs from the IPv6 version in that no algorithmic mapping between L3ADDR and L2ADDR is possible. ISATAP for IPv4 therefore requires an L3ADDR->L2ADDR address mapping method that is coordinated on a per-site basis such that all nodes in the site follow the same convention. Examples include name service lookup (e.g., as described in [VET]), static mapping table lookup,
IPv4的地址映射与IPv6版本的不同之处在于，L3ADDR和L2ADDR之间不可能存在算法映射。因此，IPv4的ISATAP需要L3ADDR->L2ADDR地址映射方法，该方法在每个站点的基础上进行协调，以便站点中的所有节点遵循相同的约定。示例包括名称服务查找（如[VET]中所述）、静态映射表查找、，
etc.
等
The node next performs an IPv4 FIB lookup on the next-hop L2ADDR to determine the correct underlying IPv4 interface. If the FIB lookup fails, the node drops the packet and returns an ICMPv4 "Destination Unreachable" message to the original source [RFC0792]; otherwise, it encapsulates the packet and submits it to the IPv4 layer as described below.
节点接下来在下一跳L2ADDR上执行IPv4 FIB查找，以确定正确的底层IPv4接口。如果FIB查找失败，则节点丢弃数据包并向原始源[RFC0792]返回ICMPv4“Destination Unreachable”消息；否则，它将封装数据包并将其提交到IPv4层，如下所述。
After performing the IPv4 FIB lookup on the next-hop L2ADDR, the node encapsulates the packet as specified in [RFC2003] with the IPv4 address of the underlying interface as the outer IPv4 source address and the next-hop L2ADDR as the outer IPv4 destination address. The node sets the DF flag in the outer IPv4 header according to Section 3.2 of [RFC4213]. The node also sets the IP protocol field in the outer IPv4 header to 4 (i.e., ip-protocol-4).
在下一跳L2ADDR上执行IPv4 FIB查找后，节点按照[RFC2003]中的规定封装数据包，将底层接口的IPv4地址作为外部IPv4源地址，下一跳L2ADDR作为外部IPv4目标地址。节点根据[RFC4213]第3.2节在外部IPv4报头中设置DF标志。该节点还将外部IPv4报头中的IP协议字段设置为4（即IP-protocol-4）。
The node then submits the encapsulated packet to the IPv4 layer. The IPv4 layer fragments the packet if necessary, then forwards each fragment to the underlying IPv4 interface. The underlying IPv4 interface then performs address resolution on the outer IPv4 destination address (i.e., the next-hop L2ADDR) and submits the packet for transmission on the underlying link layer.
然后，节点将封装的数据包提交到IPv4层。IPv4层根据需要对数据包进行分段，然后将每个分段转发到底层IPv4接口。然后，底层IPv4接口对外部IPv4目标地址（即下一跳L2ADDR）执行地址解析，并提交数据包以在底层链路层上传输。
In many aspects, ISATAP is simply a unicast-only derivative of "6over4" [RFC2529]. For various reasons, however, ISATAP has seen practical wide-scale deployment while the 6over4 approach has been silently carried forward through ongoing research efforts. This specification extends the ISATAP interface model to support IPv4 multicast mapping in a manner that exactly parallels IPv6 multicast mapping in 6over4 (see [RFC2529], Section 6). Indeed, the approach might more aptly be named "4over4" were it not for the fact that the name "ISATAP" has already become ingrained in the widely published terminology.
在许多方面，ISATAP只是“6over4”[RFC2529]的单播派生。然而，由于各种原因，ISATAP已经看到了实际的大规模部署，而6over4方法已经通过正在进行的研究工作默默地推进。本规范扩展了ISATAP接口模型，以支持IPv4多播映射，其方式与6over4中的IPv6多播映射完全相同（请参见[RFC2529]，第6节）。事实上，如果不是因为“ISATAP”这个名字已经在广泛出版的术语中根深蒂固，这种方法可能更适合命名为“4over4”。
IPv4 multicast mapping is available only on ISATAP interfaces configured over sites that support IPv4 multicast. For such sites, an IPv4 packet sent on an ISATAP interface with a multicast destination address DST MUST be encapsulated for transmission on an underlying IPv4 interface to the IPv4 multicast address of Organization-Local Scope using the mapping below. The mapped address SHOULD be taken from the block 239.193.0.0/16, a different sub-block of the Organization-Local Scope address block, or -- if none of those are available -- from the expansion blocks defined in [RFC2365].
IPv4多播映射仅在通过支持IPv4多播的站点配置的ISATAP接口上可用。对于此类站点，必须封装在ISATAP接口上发送的具有多播目标地址DST的IPv4数据包，以便使用以下映射在基础IPv4接口上传输到组织本地范围的IPv4多播地址。映射地址应从块239.193.0.0/16、组织本地作用域地址块的不同子块中获取，或者（如果这些子块都不可用）从[RFC2365]中定义的扩展块中获取。
Note that when they are formed using the expansion blocks, they use only a /16-sized block.
请注意，当它们使用扩展块形成时，它们仅使用/16大小的块。
+-------+-------+-------+-------+
| 239 | OLS | DST2 | DST3 |
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| 239 | OLS | DST2 | DST3 |
+-------+-------+-------+-------+
DST2, DST3 Last two bytes of IPv4 multicast address.
DST2、DST3 IPv4多播地址的最后两个字节。
OLS From the configured Organization-Local Scope address block. SHOULD be 193; see [RFC2365] for details.
配置的组织本地作用域地址块中的OLS。应该是193；有关详细信息，请参见[RFC2365]。
Figure 1: ISATAPv4 Multicast Mapping
图1:ISATAPv4多播映射
No new IANA registration procedures are required for the above.
上述项目不需要新的IANA注册程序。
The node must take care in managing its IPv4 FIB table entries in order to avoid looping through recursive encapsulations.
节点必须注意管理其IPv4 FIB表项，以避免通过递归封装循环。
The security considerations specified in [RFC2003] apply equally to this document. The security considerations specified in ISATAP [RFC5214] and 6over4 [RFC2529] also apply, with the exception that ip-protocol-4 encapsulation is used instead of ip-protocol-41.
[RFC2003]中规定的安全注意事项同样适用于本文件。ISATAP[RFC5214]和6over4[RFC2529]中规定的安全注意事项也适用，但使用ip-protocol-4封装代替ip-protocol-41除外。
Updated tunnel security considerations are found in [SECURITY].
更新的隧道安全注意事项可在[安全]中找到。
This work extends the ISATAP interface model, which has evolved through the insights of many contributers over the course of many decades. Special thanks to Brian Carpenter and Jari Arkko for their helpful review input.
这项工作扩展了ISATAP接口模型，该模型在几十年的时间里通过许多贡献者的洞察而发展。特别感谢Brian Carpenter和Jari Arkko提供的有用评论意见。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[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月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[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月。
[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月。
[SECURITY] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008.
[安全]Hoagland，J.，Krishnan，S.，和D.Thaler，“IP隧道的安全问题”，正在进行的工作，2008年10月。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[VET]Templin，F.，“虚拟企业遍历（VET）”，RFC 5558，2010年2月。
[RANGER] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RANGER]Templin，F.，“具有全局企业递归的网络中的路由和寻址（RANGER）”，RFC 5720，2010年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
In some instances, an ISATAP interface may be configured over a site in which the L3ADDRs and L2ADDRs of all ISATAP neighbors are also known to be routable within the underlying site. In that case, the ISATAP interface MAY avoid encapsulation and submit the unencapsulated packets directly to the IPv4 layer. Note however that this approach does not provide for the use of indirection afforded through encapsulation.
在某些情况下，可以在一个站点上配置ISATAP接口，其中所有ISATAP邻居的L3ADDR和L2ADDR也可以在基础站点内路由。在这种情况下，ISATAP接口可以避免封装，并将未封装的数据包直接提交到IPv4层。但是请注意，此方法不提供通过封装提供的间接寻址的使用。
Author's Address
作者地址
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
Fred L.Templin（编辑）美国华盛顿州西雅图波音研究与技术公司邮政信箱3707 MC 7L-49 98124
EMail: fltemplin@acm.org
EMail: fltemplin@acm.org