RFC5214 ISATAP-站内自动隧道寻址协议|江阴雨辰互联

2023年7月31日发(作者：)

RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

RFC5214 ISATAP-站内自动隧道寻址协议

2008

第1页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

该备忘录状态：

本文档为Internet社区指定了Internet标准跟踪协议，并请求讨论和改进建议。有关本协议的标准化状态，请参阅当前版本的“互联网官方协议标准”（STD 1）。这份备忘录的分发是不受限制的。

ISEG注意事项：

IESG认为这项工作与在softwire工作组已经完成IETF工作有关，但这并不妨碍发布。

概述：

站内自动隧道寻址协议（ISATAP）通过IPv4网络连通双栈（IPv6/IPv4）节点。ISATAP将IPv4网络作为IPv6的链路层，并支持一种与非广播组播接入模型（NBMA）类似的自动隧道抽象机制。

译者注：RFC2529 6over4假定支持IPv4组播，构建IPv6 in IPv4的自动隧道。

修订记录

修订日期修改人修改内容

完成翻译初稿，英文原版：2020-07-07

程怀玺-Jade

/info/rfc5214

第2页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

目录 .................................................................... 3

引言 ................................................................... 5

需求 ................................................................... 5

术语 ................................................................... 5

适用范围 ............................................................... 6

节点需求 ............................................................... 6

地址需求 ............................................................... 7

6.1

6.2

6.3

ISATAP接口ID ................................................... 7

ISATAP接口地址配置 ............................................... 7

组播/任播 ........................................................ 7

自动隧道 ............................................................... 8

7.1

7.2

7.3

7.4

7.5

封装 ............................................................ 8

处理ICPMv4错误 .................................................. 8

解封装 .......................................................... 8

链路本地地址 ...................................................... 8

隧道上的邻居发现 .................................................. 9

8 ISATAP接口上的邻居发现 .................................................. 9

8.1

8.2

8.3

主机概念模型 ...................................................... 9

路由器和前缀发现 – 路由器规范 ....................................... 9

路由器和前缀发现 – 主机规范 ......................................... 9

主机变量 .................................................. 9

潜在路由器列表的初始化 ...................................... 10

处理接收到的RA ............................................ 10

发送RS .................................................. 10

8.3.1

8.3.2

8.3.3

8.3.4

8.4

邻居不可达检测 ................................................... 11

站点管理考虑 ........................................................... 11

安全考虑 ........................................................... 11

第3页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

IANA考虑 .......................................................... 12

致谢 .............................................................. 12

参考文档 ........................................................... 13

13.1

13.2

Normative Reference ............................................ 13

Informative Reference .......................................... 14

附录A: 在IANA以太网地址块中的EUI-64地址 .................................... 14

第4页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

1 引言

本文档指定了一种称为站内自动隧道寻址协议（ISATAP）的简单机制，其通过IPv4网络连通双栈（IPv6/IPv4）节点。双栈节点使用ISATAP自动隧道通过IPv4隧道IPv6数据包，即ISATAP将IPv4网络视为IPv6的链路层。

不论IPv4地址是公网地址还是私网地址，ISATAP都使能自动隧道，并且将其呈现为与[RFC2491]、[RFC2492]、[RFC2529]和[RFC3056]类似的非广播组播接入（NBMA）抽象。

本文的主要目标有：1）描述适用范围；2）指定寻址需求；3）使用ISATAP指定自动隧道；4）指定在ISTATP接口上的IPv6邻居发现操作；5）讨论站点管理、安全和IANA注意事项。

2 需求

本文档中出现的关键字MUST（必须）、MUST NOT（不得）、REQUIRED（必选的）、SHALL（将要）、SHALL NOT（将不会）、SHOULD（应该）、SHOULD NOT（不应该）、RECOMMENDED（推荐）、MAY（可能）、和OPTIONAL（可选），其含义参考RFC2119规范。

本文档同样使用内部概念性的变量描述协议的行为，并使用实现必须允许系统管理员修改的外部变量。特定的变量名字，它们的取值如何变化以及它们的设置如何影响协议的行为，都是被用来演示协议的行为。不强制要求实现必须按照完全一致的形式定义它们，而只要求其外部行为与本文档描述一致即可。

3 术语

[RFC2460]和[RFC4861]中的术语同样适用于本文档。如下附加的数据定义：

ISATAP node/host/router: ISATAP 节点/主机/路由器

实现本文中定义规范的支持双栈（IPv6/IPv4）的节点/主机/路由器。

第5页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

ISATAP interface: ISATAP接口

ISATAP节点的非广播多播多路访问（NBMA）IPv6接口，用于自动在IPv4中隧道IPv6封包。

ISATAP interface identifier: ISATAP接口标识符

按照第6.1章节定义的内嵌IPv4地址的IPv6接口ID。

ISATAP address: ISATAP地址

其匹配节点的ISATAP接口的on-link前缀的IPv6单播地址，并且包含了ISATAP接口ID。

locator: 定位器

一个IPv4地址与接口的映射；即节点的IPv4地址和其关联的接口。

locator set: 定位器集

与一个ISATAP接口关联的定位器的集合。集合中的每个定位器属于相同的站点。

4 适用范围

本技术规范的适用范围是在遵守本文档中的安全注意事项的站点内，自动在IPv4网络中为ISATAP节点传输IPv6数据包，包括在某些企业网络和3GPP/3GPP2无线运营商网络中主机到路由器、路由器到主机，主机到主机自动隧道（本文件中规定的机制确保具有足够信任基础的其他场景也属于该适用范围）。

对以上适用范围的扩展（比如，通过组合本文档的机制与其他技术规范中的机制）超过了本文档的范围。

5 节点需求

ISATAP节点遵守在[RFC4294]中指定的IPv6节点通用功能需求和在[RFC4213]中第2章定义的双IP层操作需求。它们同样实现了本文档指定的附加功能需求。

第6页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

6 地址需求

6.1 ISATAP接口ID

ISATAP接口标识符按照[RFC4291]第2.5.1章节中的Modified EUI-64格式构造，其拼接24-bit的IANA ODU（00-00-5E），8-bit的16进制值0xFE，以及32-bit的IPv4地址，以网络序排序如下：

当IPv4地址已知是全球唯一时，其中的"u" bit位(universal/local)被设置为1；否则"u" bit被设置为0。"g"表示individual/group，"m"表示IPv4地址的bit位集。

按照[RFC4291]的第2.5.1章节，不要求ISATAP节点验证由"u"设置为universal的modified

EUI-64标识符创建的接口ID是全球唯一的。

6.2 ISATAP接口地址配置

每个ISATAP接口配置了来自单一站点的由IPv4地址与接口映射组成的定位器的集合。即，一个ISATAP接口的定位器不得跨多个站点。

当从接口上移除一个IPv4地址时，对应的定位器应该从其关联的定位器集中删除。当给一个接口分配一个新的IPv4地址时，相应的定位器可以增加到合适的定位器集中。

ISATAP接口从它们的定位器集中IPv4地址组成ISATAP接口ID，并用接口ID生成链路本地ISATAP地址（[RFC4862]的第5.3章节）。

6.3 组播/任播

无法假定广域网上IPv4组播的可用性，所以（与6over4[RFC2529]不同），ISATAP必须假定其底层的IPv4载波网络仅仅具有单播能力。在ISATAP接口上支持IPv6组播不在本文档中讨论。

第7页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

同样，保留的IPv6子网任播地址的支持也不在本文档中讨论。

7 自动隧道

ISATAP接口使用[RFC4213]中第3章定义的基础隧道机制。如下子章节描述附加的规格。

7.1 封装

ISATAP地址通过静态计算映射为链路层地址。即ISATAP IPv6地址最后4个8位元组作为IPv4地址。

7.2 处理ICPMv4错误

ISATAP接口应该处理地址解析协议（ARP）故障和持续的ICMPv4错误，作为指示到一个邻居的路径上可能已经失败的特定链路信息。

7.3 解封装

使用[RFC4213]中的第3.6章节中的规范。另外，当一个ISATAP节点接收到一个IPv4协议号为41的数据报，但是不属于一个已配置隧道接口，进一步确定封包的IPv4目的地址和到达接口是否匹配ISATAP接口上配置的定位集中的某个定位器。

如果找到了匹配定位器的ISATAP接口，解封装者必须验证封包的源地址相对被封装的IPv6源地址的正确性。如果满足下述条件则IPv4源地址是正确的：

o IPv6源地址是一个在其接口ID内嵌了IPv4源地址的ISATAP地址，或

o IPv4源地址是潜在路由器列表中的一员（参考8.1章节）。

对于IPv4源地址相对这个ISATAP接口不正确的封包执行进一步检查，以确定它们是否属于另一个隧道接口。

7.4 链路本地地址

ISATAP接口使用的链路本地地址按照本文档第6章的定义进行构造。

第8页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

7.5 隧道上的邻居发现

ISATAP接口使用的邻居发现规范由本文档的下一章节定义。

8 ISATAP接口上的邻居发现

ISATAP接口使用[RFC4861]章节中定义的邻居发现机制。以下章节定义了同样需要实现的规范。

8.1 主机概念模型

除了（[RFC4861]中第5.1章节）概念数据结构列表外，ISATAP接口新增变量如下：

Potential Router List (PRL): 潜在路由器列表

一个关于潜在路由器的条目集合；用于支持路由器和前缀发现。每个条目（"PRL(i)"）具有一个关联的定时器（"TIMER(i)"）和一个IPv4地址（"V4ADDR(i)"），该地址表示路由器的通告ISATAP接口。

8.2 路由器和前缀发现 – 路由器规范

通告ISATAP接口参照[RFC4861]中第6.2.6章节的定义发送被请求的RA消息，但是消息只是直接发送给请求的节点；即它们无法被链路上的其他节点接收到。

8.3 路由器和前缀发现 – 主机规范

使用了[RFC4861]中第6.3章节定义的主机规范。以下小节介绍了ISATAP接口新增的规范。

8.3.1

主机变量

除了（[RFC4861]的6.3.2章节）定义的主机变量列表，ISATAP接口新增了如下变量：

PrlRefreshInterval: PRL刷新周期

PRL初始化后，连续两次刷新间的间隔，以秒为单位。特定值0xffffffff表示无期限。

默认值: 3600秒

MinRouterSolicitInterval: 最小RS发送周期

以秒为单位的对同一通告ISATAP接口的RS请求的时间间隔。特定值0xffffffff表示无期限。

第9页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

8.3.2

潜在路由器列表的初始化

ISATAP节点使用IPv4地址初始化ISATAP接口的PRL，其中IPv4地址可以通过手动配置、DNS

FQDN[RFC1035]、DHCPv4[RFC2131]厂商特定选项或者其他未定义的方式获得。域名通过手动配置、接收到的DHCPv4域名选项[RFC2132]或其他未定义的方式取得。FQDN通过静态主机文件查找、查询DNS服务、查询站点特定的名字服务或者其他未定义的方式被解析为IPv4地址。

ISATAP接口完成PRL初始化后，节点为接口设置一个时长为PrlRefreshInterval的定时器，并在定时器超时后，按照上述要求重新初始化接口的PRL。当使用FQDN时，并且通过服务解析后其返回的地址包含TTL（Time to Live）（比如，DNS ’A’资源记录[RFC1035]），则定时器应该设置为PrlRefreshInterval和返回的TTL中较小的一个（零值TTL被解释为意味着PRL在每个路由器请求事件之前被重新初始化。请参阅第8.3.4节）。

8.3.3

处理接收到的RA

除了（[RFC4861]的6.1.2章节）用于验证RA消息的检查列表外，ISATAP接口增加：

o IP源地址是某些PRL(i)中内嵌V4ADDR(i)的链路本地ISATAP地址

从ISATAP接口上接收到的有效的RA按照[RFC4861]中第6.3.4章节处理。

8.3.4

发送RS

除了（[RFC4861]中第6.3.7章节）触发RS发送的时间列表外，ISATAP接口新增如下事件：

o 某个PRL(i)的TIMER(i)超时。

因为主动通告RA的可能是不完整的和/或缺席的，ISATAP节点可以为特定的PRL(i)设置相应的TIMER(i)，安排周期性的RS事件。

当调度周期的路由器征询事件时，节点应该设置TIMER(i)，以便下个事件在它们过期前为PRL(i)

刷新存储的剩余生命周期，包括路由器生命周期、接收到的前缀信息选项[RFC4191]的有效生命周期。TIMER(i)必须设置为不低于MinRouterSolicitInterval秒，其中MinRouterSolicitInterval是为节点或为特定PRL(i)而配置的，其应该有保守默认值（比如，2分钟）。

第10页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

当TIMER(i)超时后，节点按照[RFC4861]中第6.3.7章节发送RS消息（直接发往PRL(i)）；即它们不会被其他路由器接收到。当节点继续要求PRL(i)定期发出路由器请求事件，而PRL(i)继续充当路由器时，如上所述，节点在每个到期事件之后重置TIMER(i)。

8.4 邻居不可达检测

ISATAP主机应该执行邻居不可达检测（[RFC4861]的第7.3章节）。ISATAP路由器可以执行NUD,但是这可能无法在所有环境中扩展。

在地址解析后，ISATAP主机应该通过发送NS消息和接收NA消息，执行初始的可达性确认。ISATAP路由器可以执行初始可达性确认，但是这可能无法在所有环境中扩展。

9 站点管理考虑

站点管理员维护潜在路由器列表（PRL），列表成员的IPv4地址标识路由器的通告ISATAP接口。

PRL通常在站点的名称服务中作为ISATAP服务的FQDN维护（请参阅第8.3.2节）。FQDN的选择没有强制性规则，但是鼓励站点管理员使用约定"name"（例如）。

当网站的名称服务包含带有返回的IPv4地址的TTL时，网站管理员应为TTL配置保守的值，以最大程度地减少控制面流量。

10 安全考虑

实现者应该注意到，除了可能的对IPv6的攻击外，也必须考虑到针对IPv4的安全攻击。处于性能考虑，应该避免同时使用IPv4和IPv6安全。比如，如果IPv6运行加密，则对IPv4进行加密则是冗余的，除非流量分析也被认为是安全威胁。如果IPv6运行认证，则IPv4认证只会增加一点安全性；反过来，当数据包离开IPv6-over-IPv4域时，IPv4安全将不能保护IPv6流量的安全。因此，即使IPv4安全可用，也需要实现IPv6安全。

第11页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

与IPv6u发现相关的安全威胁在[RFC3756]中描述。

存在一种可能的欺骗攻击，其将伪造的ip协议号为41的封包从外部注入到ISATAP链路上。因为ISATAP链路跨越了整个IPv4站点，限制对该链路的访问可以通过限制对站点的访问来实现；即，通过让站点边界路由器实现IPv4入口过滤和ip-protocol-41过滤。

另一种可能的欺骗攻击是由一个伪装成路由器的节点从ISATAP链路上注入伪造的协议号为41的IP封包。潜在路由器列表（PRL）提供了一个IPv4地址列表，表示主机在筛选决策中使用的路由器的ISATAP接口。站点管理员应确保PRL是最新的，并且其解决方案机制（见第9节）不会被破坏。

在ISATAP接口上使用临时地址[RFC4941]和加密生成的地址[RFC3972]超出了本规范的范围。

11 IANA考虑

IANA已在IANA以太网地址块中指定了用于Modified EUI-64地址构造的格式（[RFC4291]的附录A）。本文档附录中的文本已作为示例规范提供。可以通过以下地址访问IANA类型在IANA注册中心的最新版本：

/assignments/ethernet-numbers

12 致谢

本文档中的想法不是原创的，并且作者感谢原创者。这项工作的一部分是通过SRI International和诺基亚以及波音公司的内部项目和政府合同赞助的。政府赞助商包括Monica Farah Stapleton和Russell Langan（美国陆军CECOM ASEO）和Allen Moshfegh博士（美国海军研究办公室）。

SRI International的赞助商包括Mike Frankel博士，J。Peter Marcotullio博士，Lou

Rodriguez博士和Ambatipudi Sastry博士。

感谢以下提供评审的同行：Jim Bound、Rich Draves、Cyndi Jung、Ambatipudi Sastry、Aaron Schrader、Ole Troan和Vlad Yasevich。

第12页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

感谢以下人员作出的卓越贡献：Marcelo Albuquerque, Brian Carpenter、 Alain Durand、

Hannu Flinck、 Jason Goldschmidt、 Christian Huitema、 Nathan Lutchansky、 Karen

Nielsen、 Mohan Parthasarathy、 Chirayu Patel、 Art Shelest、 Markku Savela、

Pekka Savola、 Margaret Wasserman、 Brian Zill以及IETF IPv6和V6OPS工作组的成员。Mohit Talwar为该文档的早期版本做出了贡献。

作者感谢Brian Carpenter和Cyndi Jung在RFC 2529中所做的工作，该工作引入了站点内自动隧道的概念。此概念后来称为：“虚拟以太网”，由Quang Nguyen在张丽霞博士的指导下进行了研究。

13 参考文档

13.1 Normative Reference

[RFC1035] Mockapetris, P., "Domain names - implementation and

specification", STD 13, RFC 1035, November 1987.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC

2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor

Extensions", RFC 2132, March 1997.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6

(IPv6) Specification", RFC 2460, December 1998.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,

"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,

September 2007.

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms

for IPv6 Hosts and Routers", RFC 4213, October 2005.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing

Architecture", RFC 4291, February 2006.

第13页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless

Address Autoconfiguration", RFC 4862, September 2007.

13.2 Informative Reference

[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6

over Non-Broadcast Multiple Access (NBMA) networks", RFC

2491, January 1999.

[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM

Networks", RFC 2492, January 1999.

[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4

Domains without Explicit Tunnels", RFC 2529, March 1999.

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains

via IPv4 Clouds", RFC 3056, February 2001.

[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6

Neighbor Discovery (ND) Trust Models and Threats", RFC

3756, May 2004.

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",

RFC 3972, March 2005.

[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and

More-Specific Routes", RFC 4191, November 2005.

[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,

April 2006.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy

Extensions for Stateless Address Autoconfiguration in

IPv6", RFC 4941, September 2007.

附录A: 在IANA以太网地址块中的EUI-64地址

在IANA以太网地址块中的修改的EUI-64地址（[RFC4291]的第2.5.1章节和附录A）通过拼接24-bit的IANTA OUI(00-00-5E)和40-bit的扩展标识符并翻转“u”bit而成。即"u" bit 第14页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

位设置为1表示全球范围，设置为0，表示本地范围。修改的EUI-64地址在内存中有如下形式（8位元组内按照从右到左传输，元组间按照从左到右传输）：

当扩展ID前两个8位元组编码为16进制的0xFFFE时，扩展ID中余下的部分编码为24-bit的厂商特定ID，如下：

当扩展ID的第一个8位元组编码为16进制的0xFE时，扩展ID的剩余部分编码为32-bit的IPv4地址，如下：

第15页/共16页 RFC5214 ISATAP-站内自动隧道寻址协议 March

2008

作者信息

Fred L. Templin

Boeing Phantom Works

P.O. Box 3707 MC 7L-49

Seattle, WA 98124

USA