IPv6作用域地址体系结构_杨振互联网服务中心

RFC4007：IPv6 Scoped Address Architecture，March 2005
关于本备忘录

本文档为互联网社区指定了一个互联网标准跟踪协议，并要求讨论和提出改进建议。请参阅当前版本的“互联网官方协议标准”（STD 1），了解该协议的标准化状态和状态。这份备忘录的分发是无限的。
版权声明

版权所有（C）互联网协会（2005）。
摘要

本文档详细说明了不同作用域的IPv6地址的体系结构特征、预期行为、文本表示和使用。根据IPv6工作组的一项决定，本文档有意避免单播站点本地地址的语法和使用。
1、导言

IPv6包括对不同“作用域”地址的支持；即，全局和非全局（例如，链路本地）地址。尽管在IPv4互联网中引入了非全局寻址，包括使用私有地址空间（“net 10”等）和管理作用域的组播地址，但IPv6的设计正式将地址作用域的概念纳入了其基础架构。本文档详细说明了不同作用域的IPv6地址的体系结构特征、预期行为、文本表示和使用。

尽管当前的地址架构规范[1]定义了单播站点本地地址，但IPv6工作组决定弃用语法和用法[5]，目前正在研究其他形式的本地IPv6寻址。未来，任何新形式的本地地址的使用都将记录在其他地方。因此，本文有意只关注链路本地和组播作用域。
2、定义

本文件中的关键词“必须”、“禁止”、“需要”、“应”、“不应”、“宜”、“不宜”、“推荐”、“可以”和“可选”应按照[2]中的描述进行解释。
3、基本术语

术语链路、接口、节点、主机和路由器在[3]中定义。单播地址作用域（链路本地和全局）和组播地址作用域（接口本地、链路本地等）的定义包含在[1]中。
4、地址作用域

除了未指定的地址之外，每个IPv6地址都有一个特定的作用域；即地址可以用作接口或接口集的唯一标识符的拓扑跨度。地址的作用域被编码为地址的一部分，如[1]中所述。
对于单播地址，本文档讨论了两个定义的作用域：
*链路本地作用域，仅用于唯一标识单个链路内（即连接到）的接口。
*全局作用域，用于唯一标识互联网中任何地方的接口。
IPv6单播环回地址::1被视为在虚拟“环回接口”所连接的虚拟链路内具有链路本地作用域。
未指定的地址::是一种特殊情况。它没有任何作用域，因为根据[1]，它绝不能被分配给任何节点。但是，请注意，一个实现可能会对未指定的地址使用依赖于实现的语义，并可能希望允许未指定地址具有特定的作用域。例如，实现通常使用未指定的地址来表示API中的“任何”地址。在这种情况下，实现可能会将具有给定特定作用域的未指定地址视为表示“作用域内的任何地址”的概念。本文档并不禁止这种用法，只要它在实现过程中受到限制。

[1] 将嵌入IPv4地址的IPv6地址定义为全局地址的一部分。因此，就IPv6作用域的地址架构而言，这些地址具有全局作用域。然而，为了方便起见，实现可能会使用这些地址，就像它们有其他作用域一样。例如，[6]将链路本地作用域分配给IPv4自动配置的链路本地地址（前缀169.254.0.0/16[7]中的地址），并将这些地址转换为IPv4映射的IPv6地址，以便在IPv4和IPv6地址之间进行目的地地址选择。这将隐含地意味着，与IPv4自动配置链路本地地址等效的IPv4映射IPv6地址具有链路本地作用域。本文档并不排除这种用法，只要它在实现过程中受到限制。
Anycast地址[1]从单播地址空间分配，并具有与单播地址相同的作用域属性。本文档中关于单播的所有陈述同样适用于任何广播。
对于组播地址，有14种可能的作用域，从接口本地到全局（包括链路本地）。接口本地作用域仅跨越单个接口；接口本地作用域的组播地址仅对单个节点内的组播环回传递有用；例如作为计算机内进程间通信的一种形式。与单播环回地址不同，接口本地组播地址可以分配给任何接口。
作用域之间存在大小关系：
*对于单播作用域，链路本地作用域比全局作用域小。
*对于组播作用域，组播地址的“scop”子字段中值较小的作用域（[1]第2.7节）小于值较大的作用域，接口本地最小，全局最大。
然而，两个不同大小的作用域可能覆盖完全相同的拓扑区域。例如，一个（组播）站点可能由一个链路组成，其中链路本地和站点本地作用域有效地覆盖了相同的拓扑跨度。
5、作用域区域

作用域区域，或简称为区域，是给定作用域拓扑的连接区域。例如，由特定（组播）站点内的路由器连接的链路集以及连接到这些链路的接口组成了组播站点本地作用域的单个区域。
请注意，区域是拓扑区域的特定实例（例如，Alice的站点或Bob的站点），而作用域是拓扑区域（例如，站点或链路）的大小。
特定非全局地址所属的区域不是在地址本身中编码的，而是由上下文确定的，例如发送或接收该地址的接口。因此，给定（非全局）作用域的地址可以在该作用域的不同区域中重复使用。例如，两个不同的物理链路可能各自包含一个链路本地地址为fe80::1的节点。

不同作用域的区域实例化如下：
*节点上的每个接口都包括一个接口本地作用域区域（仅用于组播）。
*每个链路和连接到该链路的接口都包括一个链路本地作用域区域（用于单播和组播）。
*有一个全局作用域的单一区域（用于单播和组播），包括互联网中的所有链路和接口。
*除接口本地、链路本地和全局之外的作用域的区域边界必须由网络管理员定义和配置。
区域边界是相对静态的特征，不会随着拓扑的短期变化而变化。因此，要求区域内的拓扑“连接”是为了包括可能只是偶尔连接的链路和接口。例如，即使拨号链路断开，通过拨号到雇主（组播）站点获得互联网接入的住宅节点或网络也可能被视为雇主（多广播）站点本地区域的一部分。同样，路由器、接口或链路的故障导致区域被分区，不会将该区域拆分为多个区域。相反，不同的分区仍被认为属于同一区域。
分区具有以下附加属性：
*区域边界穿过节点，而不是链路。（请注意，全局区域没有边界，界面局部区域的边界只包含一个界面。）
*同一作用域的区域不能重叠；即它们可以没有共同的链路或接口。
*给定作用域（小于全局）的区域完全属于更大作用域的区域。也就是说，与共享任何链路或接口的任何较大作用域区域相比，较小作用域区域不能包含更多的拓扑。
*从布线角度来看，每个区域都需要是“凸形”的；即从一个接口发送到同一区域中的任何其他接口的分组永远不会被路由到该区域之外。然而，请注意，如果一个区域包含隧道链路（例如IPv6 over IPv6隧道链路[8]），则隧道的较低层网络可以位于该区域之外，而不会破坏凸性属性。
每个接口只属于每个可能作用域的一个区域。请注意，这意味着一个接口属于一个作用域区域，而不管该接口具有什么样的单播地址，也不管节点在该接口上加入了哪些组播组。
6、区域索引

由于同一非全局地址可能在同一作用域的多个区域中使用（例如，在两个单独的物理链路中使用链路本地地址fe80::1），并且节点可能具有连接到同一作用域不同区域的接口（例如，路由器通常具有连接到不同链路的多个接口），因此节点需要一种内部手段来识别非全局地址属于哪个区域。这是通过在节点内为该节点所连接的同一作用域的每个区域分配一个不同的“区域索引”，并允许区域索引限定地址的所有内部使用来实现的。
区域索引的分配如下图所示：

图1：区域索引示例
此示例节点有五个接口：
*虚环回链路（无处可去的虚链路）的环回接口。
*同一以太网链路的两个接口。
*点对点链路的接口。
*隧道接口（例如，IPv6 over IPv6隧道[8]的抽象端点，可能是通过以太网或点对点链路建立的）。
因此，它被附加到由接口索引1至5标识的五个接口局部区域。
由于两个以太网接口连接到同一链路，因此节点仅连接到由链路索引1到4标识的四个链路本地区域。还要注意，即使隧道接口是通过以太网建立的，隧道链路也会获得自己的链路索引，这与以太网链路区域的索引不同。
特定作用域的每个区域索引都应包含足够的信息来指示作用域，以便所有作用域的所有索引在节点内都是唯一的，并且区域索引本身可以用于特定目的。使用索引来标识管理信息库（Management Information Base，MIB）中的条目是专用目的的一个例子。对作用域进行编码的实际表示取决于实现，不在本文档的作用域内。在本文档中，为了可读性，索引仅以“链路索引2”等格式表示。
区域索引严格局限于节点。例如，点对点链路另一端的节点可能会对该链路使用完全不同的接口和链路索引值。
实现还应支持每个作用域的“默认”区域的概念。而且，在支持的情况下，每个作用域的索引值零应该保留为“使用默认区域”。与其他区域索引不同，默认索引不包含任何作用域，作用域由默认索引附带的地址决定。实现还可以为每个作用域定义一个单独的默认区域。这些默认索引也可以用作节点仅连接到一个区域的地址的区域限定符；例如当使用全局地址时。
目前，节点无法自动确定其哪些接口属于同一区域；例如相同的链路或大于接口的相同组播作用域区域。未来，可能会制定协议来确定这些信息。在没有此类协议的情况下，实施必须提供手动分配和/或重新分配区域索引的方法。此外，为了避免在大多数情况下执行手动配置，默认情况下，实现最初应仅按如下方式分配区域索引：
*每个接口的唯一接口索引。
*每个接口的唯一链路索引。
那么，只有在节点具有多个接口到单个链路或具有不同（仅组播）作用域的区域接口的情况下，才需要手动配置。
因此，图1中示例节点的默认区域索引分配如下图2所示。然后需要手动配置，例如，为两个以太网接口分配相同的链路索引，如图1所示。

图2：默认区域索引示例
除了如上所述最初分配区域索引外，实现还应为每个有多个选择的作用域自动选择一个默认区域，以便在没有区域索引（或区域索引为零）的情况下指定地址时使用。例如，在图2所示的示例中，实现可能会自动选择intf2和link2作为这两个作用域的默认区域。（一种可能的选择算法是选择第一个包含环回接口以外的接口的区域作为每个作用域的默认区域。）还必须提供一种手动为作用域分配默认区域的方法，覆盖任何自动分配。
单播环回地址::1不能分配给环回接口以外的任何接口。因此，建议无论何时在没有区域索引或使用默认区域索引的情况下指定::1，都应将其解释为属于环回链路本地区域，而不管选择哪个链路本地区域作为默认区域。如果这样做，那么对于只有一个非环回接口（例如，一个以太网接口）的节点，在常见情况下，链路本地地址不需要用区域索引来限定。非限定地址::1将始终指向包含环回接口的链路本地区域。所有其他不合格的链路本地地址将指向包含非环回接口的链路本地区域（只要默认链路本地区域设置为包含非环返回接口的区域）。
由于要求给定作用域的区域完全落入较大作用域的区域内（见上文第5节），分配给不同作用域S区域的两个接口也必须分配给所有小于S作用域的不同区域。因此，为一个作用域手动分配不同的区域索引可能需要为较小作用域自动分配不同的分区索引。例如，假设在图1中手动分配了不同的组播站点本地索引1和2，站点1包含链路1、2和3，但站点2只包含链路4。此配置将导致自动创建相应的管理本地（即组播“scop”值4）索引1和2，因为管理本地作用域小于站点本地作用域。
考虑到上述因素，图1中示例节点的完整区域索引集以及这里的其他配置如下图3所示。

图3：完整区域索引示例
尽管上述示例显示了从一开始为每个作用域顺序分配索引值的区域，但区域索引值是任意的。实现可以用它选择的任何值标记一个区域，只要所有作用域的每个区域的索引值在节点内都是唯一的。应保留零以表示默认区域。选择遵循推荐的基本API[10]的实现将希望将它们的索引值限制为那些可以由sockaddr_in6结构的sin6_scope_id字段表示的索引值。
7、发送数据包

当上层协议向非全局目标地址发送数据包时，对于节点连接到目标地址作用域内的多个区域的情况，它必须有一种向IPv6层标识预期区域的方法。
尽管识别输出接口足以识别预期区域（因为每个接口只连接到每个作用域的一个区域），但在许多情况下，这比预期的更具体。例如，当从具有多个到预期链路的接口的节点向链路发送本地单播地址时（一种不寻常的配置），上层协议可能不关心这些接口中的哪一个用于传输。相反，它更愿意将该选择留给IP层中的路由功能。因此，当发送到非全局、非环回目标地址时，上层需要能够指定区域索引。
8、接收数据包

当上层协议接收到包含非全局源或目的地址的数据包时，可以从到达接口确定该地址所属的区域，因为到达接口只能附加到与所考虑的地址作用域相同的一个区域。但是，建议IP层向上层传达到达源和目的地址的正确区域索引，以及到达接口标识符。
9、转发

当路由器接收到发往自身以外节点的数据包时，它必须考虑目的地和源地址的区域，如下所示：
*目的地址的区域由地址的作用域和数据包的到达接口决定。通过在特定于该区域的（概念性）路由表中查找目标地址来选择下一跳接口（见第10节）。该路由表仅限于引用属于该区域的接口。
*在选择下一跳接口后，考虑源地址的区域。与目标地址一样，源地址的区域由地址的作用域和数据包的到达接口决定。如果在所选的下一跳接口上传输数据包会导致数据包离开源地址的区域，即跨越源地址作用域的区域边界，则丢弃该数据包。此外，如果数据包的目的地地址是单播地址，则会向原始数据包的源发送一条代码为2（“超出源地址作用域”）的ICMP目的地不可达消息[4]。请注意，[4]中代码2目前未分配，但IANA将为新目的重新分配该值，[4]将随此更改进行修订。

请注意，即使单播站点本地地址被弃用，上述过程仍然适用于链路本地地址。因此，如果路由器接收到的数据包的链路本地目的地地址不是路由器在到达链路上的链路本地地址之一，则路由器应尝试将数据包转发到该链路上的目的地（前提是通过邻居发现协议成功确定了目的地的链路层地址[9]）。转发的数据包可以通过到达接口或通过连接到同一链路的任何其他接口发回。
接收到发往自身并包含剩余分段数大于零的路由报头的数据包的节点（[3]第4.4节）首先检查路由报头中下一个地址的作用域。如果下一个地址的作用域小于原始目的地址的作用域，则节点必须丢弃该数据包。否则，它将原始目的地地址与路由报文头中的下一个地址进行交换。然后，上述转发规则适用如下：
*新目的地址的区域由下一个地址的作用域和数据包的到达接口决定。根据上述规则的第一个项目符号选择下一跳接口。
*在选择下一跳接口后，根据上述规则的第二个项目符号考虑源地址的区域。
对下一个地址作用域的检查确保了当数据包到达其最终目的地时，如果该目的地是链路本地的，则接收节点可以知道该数据包源自链路。这将有助于接收节点发送一个“响应”数据包，将接收到的数据包的最终目的地作为源地址，而不会破坏其源区域。
请注意，虽然通常不建议使用路由报文头，但可以在之前使用的下一个地址字段中使用路由报文头在其关联的区域边界上传递非全局地址。例如，考虑一种情况，其中链路边界节点（例如路由器）接收到目的地为链路本地地址、源地址为全局地址的数据包。如果数据包包含路由报头，其中下一个地址是全局地址，则到全局地址的下一跳接口可能属于与原始目的地不同的链路。这是允许的，因为下一个地址的作用域不小于原始目的地的作用域。
10、路由

请注意，由于单播站点本地地址已被弃用，链路本地地址不需要路由，因此本节中的讨论仅适用于组播作用域的路由。
当路由协议确定它在区域边界上运行时，它必须保护区域间的完整性并保持区域内的连接。
为了保持连接，路由协议必须能够为全局组和每个连接区域的所有作用域组创建转发信息。最直接的方法是为每个特定区域创建（概念性）转发表。
为了保护区域间的完整性，路由器必须在与相邻路由器共享的组信息中具有选择性。路由器经常与相邻路由器交换路由信息。当路由器传输此路由信息时，除了分配给用于传输信息的接口的区域外，它不得包含任何关于区域的信息。

图4：多组织组播路由器
例如，图4中的路由器必须在五个接口上交换路由信息。交换的信息如下（为简单起见，此处不考虑小于或大于组织作用域（全局作用域除外）的组播作用域）：
**接口1
*所有全局组
*从接口1、2和3中学到的所有组织组
**接口2
*所有全局组
*从接口1、2和3中学到的所有组织组
**接口3
*所有全局组
*从接口1、2和3中学到的所有组织组
**接口4
*所有全局组
*从接口4中学习到的所有组织组
**接口5
*所有全局组
*从接口5中学习到的所有组织组
通过实施路由交换规则，通过保持区域内包含的所有特定于区域的路由信息来维护区域完整性。
11、文本表示

如前所述，为了明确指定IPv6非全局地址，还应指定预期的作用域。作为指定作用域区域的常用符号，实现应该支持以下格式：
%
在这里：
是一个字面意义上的IPv6地址，
是一个标识地址区域的字符串，以及
`%’是一个分隔符，用于区分和。
以下小节描述了格式的详细定义、具体示例和其他注释。
11.1、非全局地址
该格式适用于非全局作用域的所有类型的单播和组播地址，但未指定的地址除外，该地址没有作用域。该格式没有意义，不应用于全局地址。环回地址属于平凡链路；即连接到环回接口的链路。因此，该格式也不应用于环回地址。当是未指定的地址时，本文档没有指定格式的用法，因为该地址没有作用域。然而，本文档并不禁止实现将这些特殊地址的格式用于与实现相关的目的。
11.2、部分

在文本表示中，部分应该能够识别地址作用域内的特定区域。尽管如第6节所述，区域索引应包含足够的信息来确定作用域，并且在所有作用域中都是唯一的，但此格式的部分不必包含作用域。这是因为部分应该指定适当的作用域。这也意味着部分不必在所有作用域中都是唯一的。
有了这个松散的属性，实现可以使用作为方便的表示。例如，为了表示链路索引2，实现可以简单地使用“2”作为，这将比包含“链路”作用域的其他表示更具可读性。
当实现解释格式时，它应该从部分和部分指定的作用域构造包含作用域的“完整”区域索引。（请记住，区域索引本身应包含作用域，如第6节所述。）
一个实现应该至少支持非负十进制整数的数值索引，如。默认区域索引通常应为0（见第6节），包含在整数中。当为默认值时，可以省略分隔符“%”和。同样，如果给出的IPv6地址的文本表示没有区域索引，则应将其解释为%，其中所具有作用域的默认区域索引。

一个实现可能支持其他类型的非空字符串，如。但是，字符串不得与分隔符冲突。附加字符串的精确格式和语义取决于实现。
这些字符串的一个可能候选者是接口名称，因为接口唯一地消除了任何作用域的歧义。特别是，接口名称可以用作接口和链路的“默认标识符”，因为默认情况下，接口和第6节中描述的每个作用域之间都有一对一的映射。
对于大于链路的作用域，实现也可以使用作为接口名称，但这种用法可能会有一些混淆。例如，当多个接口属于同一（组播）站点时，用户会对应该使用哪个接口感到困惑。此外，从地址到域名的映射函数在打印具有接口名称的地址作为区域索引时也会遇到同样的问题。本文档没有具体说明如何处理这些情况，而是取决于实现。
不能假设索引在区域中的所有节点上都是通用的（见第6节）。因此，该格式必须仅在节点内使用，除非解释该格式的每个节点在语义上达成一致，否则不得在线路上发送。
11.3、示例

以下地址
fe80::1234（在节点的第1个链路上）
ff02::5678（在节点的第5个链路上）
ff08::9abc（在节点的第10个组织）
将表示如下：
fe80::1234%1
ff02::5678%5
ff08::9abc%10
（这里我们假设从区域索引到部分的自然转换，其中任何作用域的第N个区域都转换为“N”。）
如果我们使用作为接口名称，这些地址也可以表示如下：
fe80::1234%ne0
ff02::5678%pvc1.3
ff08::9abc%interface10
其中接口“ne0”属于第1个链路，“pvc1.3”属于第5个链路，而“interface10”属于第10个组织。
11.4、使用示例

应该在终端主机（如telnet、ftp和ssh）中使用的应用程序可能不明确支持地址作用域的概念，特别是链路本地地址。然而，专家用户（例如网络管理员）有时甚至必须提供此类应用程序的链路本地地址。
这里有一个具体的例子。考虑一个名为“R1”的多链路路由器，它至少有两个点对点接口（链路）。每个接口分别连接到另一个路由器“R2”和“R3”。还假设点对点接口只有链路本地地址。
现在假设R2上的路由系统挂起，必须重新调用。在这种情况下，我们可能无法使用R2的全局地址，因为这是路由问题，我们不能指望有足够的路由来实现R2的全局可达性。
因此，我们必须先登录R1，然后尝试使用链路本地地址登录R2。在这种情况下，我们必须将R2的链路本地地址提供给例如telnet。这里我们假设地址是fe80::2。
请注意，我们不能只输入
% telnet fe80::2
这里，由于R1有多个链路，因此telnet命令无法检测到它应该尝试使用哪个链路进行连接。相反，我们应该键入带有链路索引的链路本地地址，如下所示：
% telnet fe80::2%3
其中分隔符“%”后的“3”对应于点对点链路的链路索引。
11.5、相关API

推荐的基本API的扩展定义了在将节点名转换为地址的库函数中应如何处理非全局地址的格式，反之亦然[11]。
11.6、省略区域索引

本文档中定义的格式并不打算使非全局地址的原始格式无效；即没有区域索引部分的格式。如第6节所述，在默认区域索引概念的一些常见情况下，作用域区域不会有任何歧义。在这种环境中，实现可以省略“%”部分。因此，它可以表现得好像根本不支持扩展格式。
11.7、分隔符字符的组合

还有为IPv6地址定义的其他类型的分隔符。在本小节中，我们将描述如何将它们与非全局地址的格式相结合。
IPv6寻址架构[1]还定义了IPv6前缀的语法。如果前缀的地址部分是非全局的，并且其作用域应消除歧义，则地址部分应采用以下格式。例如，第二条链路上的链路本地前缀fe80::/64可以表示如下：
fe80::%2/64
在这种组合中，当我们考虑通过域名到地址库函数解析格式时，将区域索引部分放在前缀长度之前非常重要[11]。也就是说，我们可以首先将带有区域索引的地址与前缀长度分开，然后将前者传递给库函数。
URL中文字IPv6地址的首选格式也已定义[12]。当用户键入应明确指定其区域的IPv6非全局地址的首选格式时，用户可以使用与首选格式相结合的非全局地址格式。
然而，键入的URL通常是通过网络发送的，如果应用程序在发送前没有删除部分，就会造成混淆。请注意，应用程序不需要关心它们使用的是哪种地址，更不用说解析或删除地址的部分了。
此外，非全局地址的格式可能与URI语法[13]冲突，因为该语法将分隔符（“%”）定义为转义符。例如，这种冲突需要将带分隔符的区域1的部分表示为“%251”。这也意味着我们不能简单地从其他来源复制非转义格式作为URI解析器的输入。此外，如果URI解析器在将转义格式传递给域名到地址库之前没有对其进行转换，则转换将失败。所有这些问题都会降低本节所述文本表示的好处。
因此，本文档没有指定非全局地址的格式应如何与文字IPv6地址的首选格式相结合。在任何情况下，只要FQDN可用，建议在URL中使用FQDN而不是文字IPv6地址。
12、安全考虑

没有区域索引的有限作用域地址具有安全影响，不能用于某些安全上下文。例如，当IKE消息通过全局地址传输时，链路本地地址不能在由网络密钥交换（Internet Key Exchange，IKE）建立的安全关联的流量选择器中使用。此外，没有区域索引的链路本地地址不能在访问控制列表中使用。
本文档的路由部分指定了一组指南，路由器可以通过这些指南防止特定区域的信息泄露到每个区域。例如，如果组播站点边界路由器允许将站点路由信息转发到站点外部，则站点的完整性可能会受到损害。
由于非全局地址的文本表示仅限于在单个节点内使用，因此不会从节点外部创建安全漏洞。然而，恶意节点可能会发送一个包含文本IPv6非全局地址和区域索引的数据包，意图欺骗接收节点关于非全局地址的区域。因此，当一个实现接收到包含文本非全局地址作为数据的数据包时，应该小心。
13、贡献者

本文件是几项单独工作的结合。Atsushi Onoe在其中一项提案中发挥了重要作用，并作为单独提案的合著者为第11条的内容做出了重大贡献。
14、致谢

IPv6工作组的许多成员对这份文件提供了有益的评论和反馈。特别是，Margaret Wasserman和Bob Hinden领导工作组就IPv6本地寻址达成共识。Richard Draves提出了一个额外的规则来处理包含作用域地址的Routing报文头。Dave Thaler和Francis Dupont就相关的API定义区域索引的语义提出了有价值的建议。Pekka Savola非常仔细地审查了该文件的一个版本，并对严重问题发表了详细评论。Steve Bellovin、Ted Hardie、Bert Wijnen和Timothy Gleeson在准备出版期间审查并帮助改进了该文件。
15、参考文献

15.1、规范性引用文件

[1] Hinden, R. and S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture”, RFC 3513, April 2003.
[2] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[3] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.
[4] Conta, A. and S. Deering, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, RFC 2463, December 1998.
15.2、资料性引用

[5] Huitema, C. and B. Carpenter, “Deprecating Site Local Addresses”, RFC 3879, September 2004.
[6] Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6)”, RFC 3484, February 2003.
[7] Cheshire, S., Aboba, B., and E. Guttman, “Dynamic Configuration of Link-Local IPv4 Addresses”, Work in Progress.
[8] Conta, A. and S. Deering, “Generic Packet Tunneling in IPv6 Specification”, RFC 2473, December 1998.
[9] Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6)”, RFC 2461, December 1998.
[10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6”, RFC 3493, February 2003.
[11] Gilligan, R., “Scoped Address Extensions to the IPv6 Basic Socket API”, Work in Progress, July 2002.
[12] Hinden, R., Carpenter, B., and L. Masinter, “Format for Literal IPv6 Addresses in URL’s”, RFC 2732, December 1999.
[13] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 3986, January 2005.
完整版权声明

IETF对可能声称与本文档所述技术的实施或使用有关的任何知识产权或其他权利的有效性或作用域，或此类权利下的任何许可可能或可能不可用的程度，不持任何立场；它也不代表它已经做出了任何独立的努力来确定任何此类权利。有关RFC文档中权限程序的信息，请参阅BCP 78和BCP 79。
向IETF秘书处披露的知识产权副本以及提供许可证的任何保证，或本规范的实施者或用户试图获得使用此类专有权利的一般许可或许可的结果，可以从IETF在线知识产权存储库获得，网址为http://www.ietf.org/ipr.
IETF邀请任何利益相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准所需技术的其他专有权利。请将信息发送至IETFietf-ipr@ietf.org.
致谢

RFC编辑器功能的资金目前由互联网协会提供。
推荐阅读
使用DHCPv6注册自生成的IPv6地址
UDP封装中的GRE
IPv4和IPv6（单跳）的双向转发检测（BFD）
IP层安全（IPsec）文件路线图
IP网络地址转换器（NAT）的协议复杂性
NAT域隧道模式IPsec安全模型
IPv4链路本地地址的动态配置
Linux用户、组管理
在Linux中创建、查看和编辑文件
Linux权限与设置ACL
在VMware安装一台CentOS虚拟机
在Linux中命令行管理文件和帮助
使用Spring boot整合MyBatis，实现根据用户id查询用户信息功能

声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/424501.html

IPv6作用域地址体系结构

作者专栏

铁军哥