IPV6 地址架构

RFC4291：IP Version 6 Addressing Architecture，February 2006

本备忘录的状态

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

版权声明

版权所有 (C) 互联网协会 (2006)。

梗概

该规范定义了 IPV6 (IP Version 6) 协议的地址架构。该文档包括 IPv6 地址模型、IPv6 地址的文本表示、IPv6 单播地址、任播地址和组播地址的定义，以及 IPv6 节点所需的地址。

本文档废弃了 RFC 3513，“IPV6 地址体系结构”。

1、 简介

该规范定义了 IPV6 协议的地址架构。它包括各种类型的 IPv6 地址（单播、任播和组播）的基本格式。

2、 IPv6 地址

IPv6 地址是接口和接口集的 128 位标识符（其中“接口”在 [IPV6] 的第 2 节中定义）。地址分为三种类型：

Unicast：单播，单个接口的标识符。发送到单播地址的数据包被传递到由该地址标识的接口。

Anycast：任播，一组接口的标识符（通常属于不同的节点）。发送到任播地址的数据包被传递到由该地址标识的接口之一（“最近的”接口，根据路由协议的距离测量）。

Multicast：组播，一组接口的标识符（通常属于不同的节点）。发送到组播地址的数据包将传递到该地址标识的所有接口。

IPv6 中没有广播地址，它们的功能被组播地址所取代。

在本文档中，地址中的字段具有特定名称，例如“子网”。当此名称与名称后的标识符“ID”一词一起使用时（例如，“子网 ID”），它指的是命名字段的内容。当它与术语“前缀”（例如，“子网前缀”）一起使用时，它指的是从左到右并包括该字段的所有地址。

在 IPv6 中，所有 0 和所有 1 都是任何字段的合法值，除非特别排除。具体来说，前缀可能包含零值字段或以零值字段结尾。

2.1、 地址模型

所有类型的 IPv6 地址都分配给接口，而不是节点。IPv6 单播地址是指单个接口。由于每个接口都属于单个节点，因此该节点的任何接口的单播地址都可以用作该节点的标识符。

所有接口都必须至少有一个链路本地单播地址（有关其他所需地址，请参见第 2.8 节）。单个接口还可以有多个任意类型（单播、任播和组播）或范围的 IPv6 地址。对于不用作与非邻居之间的任何 IPv6 数据包的来源或目的地的接口，不需要范围大于链路范围的单播地址。这有时对点对点接口很方便。这种地址模型有一个例外：

如果实现在将多个物理接口呈现给互联网层时将多个物理接口视为一个接口，则可以将一个单播地址或一组单播地址分配给多个物理接口。这对于在多个物理接口上进行负载分担很有用。

目前，IPv6 延续了 IPv4 模型，即子网前缀与一条链路相关联。可以将多个子网前缀分配给同一链路。

2.2、 地址的文本表示

将 IPv6 地址表示为文本字符串的传统形式有以下三种：

1. 首选形式是 x:x:x:x:x:x:x:x，其中“x”是地址的八个 16 位片段的一到四个十六进制数字。例子：

ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A

请注意，不必在单个字段中写入前导零，但每个字段中必须至少有一个数字（2.中描述的情况除外）。

2. 由于某些分配某些样式的 IPv6 地址的方法，地址通常会包含长的零位字符串。为了使写入包含零位的地址更容易，可以使用一种特殊的语法来压缩零。 “::”的使用表示一组或多组 16 位零。“::”在一个地址中只能出现一次。"::" 也可用于压缩地址中的前导零或尾随零。

例如以下地址：

2001:DB8:0:0:8:800:200C:417A，单播地址
FF01:0:0:0:0:0:0:101，组播地址
0:0:0:0:0:0:0:1，环回地址
0:0:0:0:0:0:0:0，未指定地址

可以表示为：

2001:DB8::8:800:200C:417A，单播地址
FF01::101，组播地址
::1，环回地址
::，未指定地址

3. 在处理 IPv4 和 IPv6 节点的混合环境时，有时更方便的另一种形式是 x:x:x:x:x:x:d.d.d.d，其中“x”是六个高位的十六进制值地址的 16 位片段，'d' 是地址的四个低位 8 位片段的十进制值（标准 IPv4 表示）。例子：

0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38

或压缩形式：

::13.1.68.3
::FFFF:129.144.52.38

2.3、 地址前缀的文本表示

IPv6 地址前缀的文本表示类似于以无类域间路由 (Classless Inter-Domain Routing，CIDR) 表示法 [CIDR] 编写 IPv4 地址前缀的方式。IPv6 地址前缀由以下符号表示：

ipv6-address/prefix-length

在这里：

ipv6-address：ipv6地址，是第 2.2 节中列出的任何符号中的 IPv6 地址。

prefix-length：前缀长度，是一个十进制值，指定地址的最左边有多少个连续位构成前缀。

例如，以下是 60 位前缀 20010DB80000CD3（十六进制）的合法表示：

2001:0DB8:0000:CD30:0000:0000:0000:0000/60
2001:0DB8::CD30:0:0:0:0/60
2001:0DB8:0:CD30::/60

以下不是上述前缀的合法表示：

2001:0DB8:0:CD3/60

可以在地址的任何 16 位块内删除前导零，但不能删除尾随零

2001:0DB8::CD30/60，“/”左侧的地址扩展为 ：

2001:0DB8:0000:0000:0000:0000:0000:CD30

2001:0DB8::CD3/60，“/”左侧的地址扩展为 ：

2001:0DB8:0000:0000:0000:0000:0000:0CD3

当同时写入节点地址和该节点地址的前缀（例如，节点的子网前缀）时，可以将两者组合如下：

节点地址 2001:0DB8:0:CD30:123:4567:89AB:CDEF 及其子网号 2001:0DB8:0:CD30::/60

可简写为2001:0DB8:0:CD30:123:4567:89AB:CDEF/60

2.4、 地址类型识别

IPv6地址的类型由地址的高位标识，如下：

任播地址取自（任何范围的）单播地址空间，在语法上与单播地址没有区别。

全球单播地址的一般格式在第 2.5.4 节中描述。第 2.5.5 节描述了包含嵌入式 IPv4 地址（为了 IPv4-IPv6 互操作的目的）的全球单播地址的一些特殊用途子类型。

未来的规范可能会出于其他目的重新定义全球单播空间的一个或多个子范围，但除非发生这种情况，否则实现必须将所有不以上述任何前缀开头的地址视为全球单播地址。

2.5、 单播地址

IPv6 单播地址可以使用任意位长的前缀进行聚合，类似于无类域间路由下的 IPv4 地址。

IPv6 中有几种类型的单播地址，特别是全球单播、站点本地单播（已弃用，参见第 2.5.7 节）和链路本地单播。全球单播还有一些特殊用途的子类型，例如带有嵌入式 IPv4 地址的 IPv6 地址。将来可以定义其他地址类型或子类型。

IPv6 节点可能对 IPv6 地址的内部结构有相当多或很少的了解，这取决于节点所扮演的角色（例如，主机与路由器）。至少，一个节点可以认为单播地址（包括它自己的）没有内部结构：

一个稍微复杂的主机（但仍然相当简单）可能还知道它所连接的链路的子网前缀，其中不同的地址可能具有不同的 n 值：

尽管一个非常简单的路由器可能不知道 IPv6 单播地址的内部结构，但路由器通常会知道一个或多个用于路由协议操作的分层边界。已知边界因路由器而异，具体取决于路由器在路由层次结构中的位置。

除了前面段落中讨论的子网边界知识外，节点不应对 IPv6 地址的结构做出任何假设。

2.5.1、 接口标识符

IPv6 单播地址中的接口标识符用于标识链路上的接口。它们在子网前缀中必须是唯一的。建议不要将相同的接口标识符分配给链路上的不同节点。它们也可能在更广泛的范围内是独一无二的。在某些情况下，接口的标识符将直接从该接口的链路层地址派生。相同的接口标识符可以用于单个节点上的多个接口，只要它们连接到不同的子网即可。

请注意，接口标识符的唯一性与 IPv6 地址的唯一性无关。例如，可以使用本地范围接口标识符创建全局单播地址，并且可以使用通用范围接口标识符创建链路本地地址。

对于所有单播地址，除了以二进制值 000 开头的地址外，接口 ID 必须为 64 位长，并以修改后的 EUI-64 格式构造。

修改后的基于 EUI-64 格式的接口标识符在从通用令牌（例如，IEEE 802 48 位 MAC 或 IEEE EUI-64 标识符 [EUI64]）派生时可能具有通用范围，或者可能具有全局令牌不可用的本地范围 （例如，串行链路、隧道端点）或不需要全局令牌的地方（例如，用于隐私的临时令牌 [PRIV]）。

当从 IEEE EUI-64 标识符形成接口标识符时，通过反转“u”位（IEEE EUI-64 术语中的通用/本地位）来形成修改的 EUI-64 格式接口标识符。在生成的修改后的 EUI-64 格式中，“u”位设置为一 (1) 以指示通用范围，设置为零 (0) 以指示本地范围。IEEE EUI-64 标识符的二进制前三个八位字节如下：

以 Internet 标准位顺序编写，其中“u”是通用/本地位，“g”是个人/组位，“c”是 company_id 的位。附录 A，“创建修改后的 EUI-64 格式接口标识符”，提供了创建修改后的 EUI-64 格式接口标识符的示例。

在形成接口标识符时反转“u”位的动机是让系统管理员在硬件令牌不可用时更容易手动配置非全局标识符。例如，预计串行链路和隧道端点就是这种情况。替代方案是这些格式为 0200:0:0:1、0200:0:0:2 等，而不是更简单的 0:0:0:1、0:0:0:2等。

IPv6 节点不需要验证使用修改后的 EUI-64 令牌创建的接口标识符是否是唯一的。

在修改后的 EUI-64 格式标识符中使用通用/本地位是为了允许开发可以利用具有通用范围的接口标识符的未来技术。

形成接口标识符的细节在适当的“IPv6 over <link>”规范中定义，例如“IPv6 over Ethernet”[ETHER]和“IPv6 over FDDI”[FDDI]。

2.5.2、 未指定地址

地址 0:0:0:0:0:0:0:0 称为未指定地址。它绝不能分配给任何节点，它表示没有地址。其使用的一个示例是在初始化主机获知自己的地址之前发送的任何 IPv6 数据包的源地址字段中。

未指定地址不得用作 IPv6 数据包的目标地址或 IPv6 路由标头中。IPv6 路由器绝不能转发具有未指定源地址的 IPv6 数据包。

2.5.3、 环回地址

单播地址 0:0:0:0:0:0:0:1 称为环回地址。节点可以使用它向自己发送 IPv6 数据包。不得将其分配给任何物理接口。它被视为具有 Link-Local 范围，并且可以被认为是虚拟接口（通常称为“环回接口”）的 Link-Local 单播地址，连接到无处可去的假想链路。

环回地址不得用作在单个节点外部发送的 IPv6 数据包中的源地址。目标地址为 loopback 的 IPv6 数据包绝不能发送到单个节点之外，并且绝不能由 IPv6 路由器转发。必须丢弃在目的地址为 loopback 的接口上接收到的数据包。

2.5.4、 全球单播地址

IPv6 全球单播地址的一般格式如下：

其中全局路由前缀是分配给站点（子网/链路集群）的（通常是分层结构的）值，子网 ID 是站点内链路的标识符，接口 ID 定义见第 2.5.1节。

除二进制 000 开头的地址外，所有全球单播地址都有一个 64 位的接口 ID 字段（即 n + m = 64），其格式如第 2.5.1 节所述。以二进制 000 开头的全球单播地址对接口 ID 字段的大小或结构没有这种限制。

以二进制 000 开头的全球单播地址的示例是第 2.5.5 节中描述的具有嵌入式 IPv4 地址的 IPv6 地址。在 [GLOBAL] 中可以找到以 000 以外的二进制值开头的全局地址示例（因此具有 64 位接口 ID 字段）。

2.5.5、 具有嵌入式 IPv4 地址的 IPv6 地址

定义了两种类型的 IPv6 地址，它们在地址的低 32 位中携带 IPv4 地址。它们是“IPv4 兼容的 IPv6 地址”和“IPv4 映射的 IPv6 地址”。

2.5.5.1、 与 IPv4 兼容的 IPv6 地址

定义了“与 IPv4 兼容的 IPv6 地址”以协助 IPv6 过渡。“IPv4-Compatible IPv6 address”的格式如下：

注意：“IPv4-Compatible IPv6 address”中使用的 IPv4 地址必须是全球唯一的 IPv4 单播地址。

“IPv4 兼容的 IPv6 地址”现在已被弃用，因为当前的 IPv6 转换机制不再使用这些地址。不需要新的或更新的实现来支持这种地址类型。

2.5.5.2、 IPv4 映射的 IPv6 地址

定义了包含嵌入式 IPv4 地址的第二种 IPv6 地址。此地址类型用于将 IPv4 节点的地址表示为 IPv6 地址。“IPv4映射的IPv6地址”的格式如下：

有关“IPv4 映射的 IPv6 地址”的使用背景，请参阅 [RFC4038]。

2.5.6、 链路本地 IPv6 单播地址

链路本地地址用于单个链路，链路本地地址具有以下格式：

链路本地地址设计用于在单个链路上地址，用于自动地址配置、邻居发现或不存在路由器时。

路由器不得将任何具有 Link-Local 源或目标地址的数据包转发到其他链路。

2.5.7、 站点本地 IPv6 单播地址

站点本地地址最初设计用于在站点内部进行地址，而不需要全局前缀。现在不推荐使用 [SLDEP] 中定义的站点本地地址。

站点本地地址具有以下格式：

在 [RFC3513] 中定义的此前缀的特殊行为必须不再在新实现中得到支持（即，新实现必须将此前缀视为全局单播）。

现有的实现和部署可能会继续使用这个前缀。

2.6、 任播地址

IPv6 任播地址是分配给多个接口（通常属于不同节点）的地址，根据路由，发送到任播地址的数据包将被路由到具有该地址的“最近”接口协议的距离度量。

任播地址是从单播地址空间分配的，使用任何定义的单播地址格式。因此，任播地址在语法上与单播地址无法区分。当一个单播地址被分配给多个接口，从而将其变成一个任播地址时，分配地址的节点必须明确配置为知道它是一个任播地址。

对于任何分配的任播地址，该地址的最长前缀 P 标识属于该任播地址的所有接口所在的拓扑区域。在 P 标识的区域内，任播地址必须作为单独的条目在路由系统中维护（通常称为“主机路由”）；在 P 标识的区域之外，任播地址可以聚合到前缀 P 的路由条目中。

请注意，在最坏的情况下，任播集的前缀 P 可能是空前缀，即该集的成员可能没有拓扑局部性。在这种情况下，任播地址必须作为一个单独的路由条目在整个互联网上进行维护，这对可以支持多少这样的“全局”任播集提出了严格的扩展限制。因此，预计对全局任播集的支持可能不可用或非常有限。

任播地址的一个预期用途是识别属于提供 Internet 服务的组织的一组路由器。这样的地址可以用作 IPv6 路由报头中的中间地址，以使数据包通过特定的服务提供商或服务提供商的序列传递。

一些其他可能的用途是识别连接到特定子网的路由器集，或提供进入特定路由域的路由器集。

2.6.1、 所需任播地址

子网路由器任播地址是预定义的。其格式如下：

任播地址中的“子网前缀”是标识特定链路的前缀。此任播地址在语法上与接口标识符设置为零的链路上的接口的单播地址相同。

发送到 Subnet-Router 任播地址的数据包将被传送到子网上的一个路由器。所有路由器都必须支持它们具有接口的子网的 Subnet-Router 任播地址。

Subnet-Router 任播地址旨在用于节点需要与一组路由器中的任何一个进行通信的应用程序。

2.7、 组播地址

IPv6 组播地址是一组接口（通常在不同节点上）的标识符。一个接口可以属于任意数量的组播组。组播地址具有以下格式：

地址开头的二进制 11111111 将该地址标识为组播地址。

flgs 是一组 4 个标志：

高位标志是保留的，必须初始化为 0。

T = 0 表示永久分配的（“众所周知的”）组播地址，由 Internet 编号分配机构 (Internet Assigned Numbers Authority，IANA) 分配。

T = 1 表示非永久分配的（“瞬态”或“动态”分配的）组播地址。

P 标志的定义和用法可以在 [RFC3306] 中找到。

R 标志的定义和用法可以在 [RFC3956] 中找到。

scop 是一个 4 位的组播范围值，用于限制组播组的范围。值如下：

Interface-Local 范围仅跨越节点上的单个接口，并且仅对组播的环回传输有用。

Link-Local链路本地组播范围与相应的单播范围跨越相同的拓扑区域。

Admin-Local 范围是必须进行管理配置的最小范围，即不会自动从物理连接或其他非组播相关配置派生。

Site-Local站点本地范围旨在跨越单个站点。

Organization-Local组织本地范围旨在跨越属于单个组织的多个站点。

标记为“（unassigned，未分配）”的范围可供管理员定义其他组播区域。

组 ID 标识给定范围内的组播组，无论是永久的还是临时的。组播组 ID 字段结构的附加定义在 [RFC3306] 中提供。

永久分配的组播地址的“含义”与范围值无关。例如，如果为“NTP 服务器组”分配了组 ID 为 101（十六进制）的永久组播地址，则

FF01:0:0:0:0:0:0:101 表示与发送方在同一接口（即同一节点）上的所有 NTP 服务器。

FF02:0:0:0:0:0:0:101 表示与发送方在同一链路上的所有 NTP 服务器。

FF05:0:0:0:0:0:0:101 表示与发送方位于同一站点的所有 NTP 服务器。

FF0E:0:0:0:0:0:0:101 表示 Internet 中的所有 NTP 服务器。

非永久分配的组播地址仅在给定范围内有意义。例如，在一个站点上由非永久性站点本地组播地址 FF15:0:0:0:0:0:0:101 标识的组与在不同站点使用相同地址的组没有关系，也不适用于使用相同组 ID 但范围不同的非永久组，也不会适用于具有相同组 ID 的永久组。

组播地址不得用作 IPv6 数据包中的源地址或出现在任何路由标头中。

路由器不得转发任何超出目标组播地址中范围字段指示的范围的组播数据包。

节点不得将数据包发送到其范围字段包含保留值 0 的组播地址；如果收到这样的数据包，则必须静默丢弃。节点不应向其范围字段包含保留值 F 的组播地址发起数据包；如果发送或接收此类数据包，则必须将其视为发往全局（范围 E）组播地址的数据包。

2.7.1、 预定义的组播地址

以下众所周知的组播地址是预定义的。本节中定义的组 ID 是为显式范围值定义的。

不允许将这些组 ID 用于任何其他范围值，且 T 标志等于 0。

保留组播地址：

FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0

上述组播地址是保留的，不得分配给任何组播组。

所有节点地址：

FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1

上述组播地址标识范围 1（接口本地）或 2（链路本地）内的所有 IPv6 节点组。

所有路由器地址：

FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2

上述组播地址标识范围 1（本地接口）、2（本地链路）或 5（本地站点）内的所有 IPv6 路由器组。

请求节点地址：

FF02:0:0:0:0:1:FFXX:XXXX

Solicited-Node 组播地址是根据节点的单播和任播地址计算的。 请求节点组播地址是通过获取地址的低 24 位（单播或任播）并将这些位附加到前缀 FF02:0:0:0:0:1:FF00::/104 来形成的范围内的组播地址

FF02:0:0:0:0:1:FF00:0000到FF02:0:0:0:0:1:FFFF:FFFF

例如，IPv6地址4037::01:800:200E:8C6C对应的Solicited-Node组播地址为FF02::1:FF0E:8C6C。仅高位不同的 IPv6 地址（例如，由于与不同聚合相关的多个高位前缀）将映射到相同的 Solicited-Node 地址，从而减少节点必须加入的组播地址的数量。

节点需要计算和加入（在适当的接口上）已为节点接口（手动或自动）配置的所有单播和任播地址的关联 Solicited-Node 组播地址。

2.8、 节点所需的地址

主机需要将以下地址识别为标识自己：

** 每个接口所需的链路本地地址。

** 已为节点接口（手动或自动）配置的任何其他单播和任播地址。

** 环回地址。

** 第 2.7.1 节中定义的所有节点组播地址。

** 每个单播和任播地址的请求节点组播地址。

** 节点所属的所有其他组的组播地址。

路由器需要识别主机需要识别的所有地址，以及以下地址来标识自己：

** 配置为充当路由器的所有接口的子网路由器任播地址。

** 已配置路由器的所有其他任播地址。

** 第 2.7.1 节中定义的所有路由器组播地址。

3、 安全考虑

IPv6 地址文件对 Internet 基础设施安全没有任何直接影响。IPv6 数据包的身份验证在 [AUTH] 中定义。

4、 IANA 考虑因素

本文档不推荐使用“与 IPv4 兼容的 IPv6 地址”。IANA 应继续在 http://www.iana.org/assignments/ipv6-address-space 将包含这些地址的地址块列为“由 IETF 保留”，而不是出于任何其他目的重新分配它。例如：

0000::/8 由 IETF [RFC3513] [1] 保留

IANA 已添加以下注释和指向此地址块的链路。

[5] 0000::/96 以前被定义为“与 IPv4 兼容的 IPv6 地址”前缀。此定义已被 RFC 4291 弃用。

IANA 已相应更新了 IANA 注册管理机构中 IPv6 地址架构的参考。

5. 致谢

作者要感谢 Paul Francis、Scott Bradner、Jim Bound、Brian Carpenter、Matt Crawford、Deborah Estrin、Roger Fajman、Bob Fink、Peter Ford、Bob Gilligan、Dimitry Haskin、Tom Harsch、Christian Huitema、Tony Li、Greg Minshall、Thomas Narten、Erik Nordmark、Yakov Rekhter、Bill Simpson、Sue Thomson、Markku Savela、Larry Masinter、Jun-ichiro Itojun Hagino、Tatuya Jinmei、Suresh Krishnan 和 Mahmood Ali。

6. 参考文献

6.1、 规范性参考

[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

6.2、 参考资料

[AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2005.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.

附录 A、 创建修改后的 EUI-64 格式接口标识符

根据特定链路或节点的特性，有多种方法可用于创建修改后的 EUI-64 格式接口标识符。本附录描述了其中一些方法。

A.1、 带有 IEEE EUI-64 标识符的链路或节点

将 IEEE EUI-64 标识符转换为接口标识符所需的唯一更改是反转“u”（通用/本地）位。一个示例是全球唯一的 IEEE EUI-64 标识符，其形式为：

其中“c”是分配的 company_id 的位，“0”是表示通用范围的通用/本地位的值，“g”是单个/组位，“m”是制造商选择的位扩展标识符。IPv6 接口标识符将采用以下形式：

唯一的变化是反转通用/本地位的值。

A.2、 具有 IEEE 802 48 位 MAC 的链路或节点

[EUI64] 定义了一种从 IEEE 48 位 MAC 标识符创建 IEEE EUI-64 标识符的方法。这是在 48 位 MAC 中间（company_id 和供应商提供的 id 之间）插入两个八位字节，十六进制值为 0xFF 和 0xFE（参见附录末尾的注释）。一个示例是具有全局范围的 48 位 IEEE MAC：

其中“c”是分配的 company_id 的位，“0”是表示全局范围的通用/本地位的值，“g”是单个/组位，“m”是制造商选择的位 扩展标识符。接口标识符将采用以下形式：

当 IEEE 802 48 位 MAC 地址可用（在接口或节点上）时，由于它们的可用性和唯一性属性，实现可以使用它们来创建接口标识符。

A.3、 与其他类型标识符的链路

除了 IEEE EUI-64 或 IEEE 802 48 位 MAC，还有许多类型的链路具有链路层接口标识符。示例包括 LocalTalk 和 Arcnet。创建修改后的 EUI-64 格式标识符的方法是取链路标识符（例如，LocalTalk 8 位节点标识符）并将其填充到左侧。例如，十六进制值为 0x4F 的 LocalTalk 8 位节点标识符会产生以下接口标识符：

请注意，这会导致通用/本地位设置为“0”以指示本地范围。

A.4、 没有标识符的链路

有许多链路没有任何类型的内置标识符。其中最常见的是串行链路和配置的隧道。必须选择在子网前缀中唯一的接口标识符。

当链路上没有可用的内置标识符时，首选方法是使用来自另一个接口或分配给节点本身的通用接口标识符。使用这种方法时，将同一节点连接到同一子网前缀的任何其他接口都不能使用相同的标识符。

如果链路上没有可用的通用接口标识符，则实现需要创建一个本地范围的接口标识符。唯一的要求是它在子网前缀中是唯一的。有许多可能的方法来选择子网前缀唯一的接口标识符。其中包括：

Manual Configuration，手动配置

Node Serial Number，节点序列号

Other Node-Specific Token，其他节点特定令牌

子网前缀唯一接口标识符的生成方式应使其在重新启动节点或从节点添加或删除接口后不会更改。

适当算法的选择取决于链路和实现。形成接口标识符的细节在适当的“IPv6 over <link>”规范中定义。强烈建议将碰撞检测算法实现为任何自动算法的一部分。

注意：[EUI-64] 实际上将 0xFF 和 0xFE 定义为要插入的位，以从 IEEE MAC-48 标识符创建 IEEE EUI-64 标识符。以 IEEE EUI-48 标识符开头时使用 0xFF 和 0xFE 值。由于对 IEEE MAC-48 和 EUI-48 标识符之间的差异的误解，在规范的早期版本中使用了不正确的值。

本文档有意继续使用 0xFF 和 0xFE，因为它满足 IPv6 接口标识符的要求（即它们在链路上必须是唯一的），IEEE EUI-48 和 MAC-48 标识符在语法上是等效的，并且它不在实践中不会引起任何问题。

附录 B、 对 RFC 3513 的更改

以下更改来自 RFC 3513，“IPv6 地址架构”：

** 取消了使用 IPv6 任播地址的限制，因为现在有足够的使用任播地址的经验，这些问题并非特定于 IPv6，GROW 工作组正在这方面开展工作。

** 不推荐使用站点本地单播前缀。更改包括以下内容：

- 从第 2.4 节的特殊前缀列表中删除了 Site-Local。

- 将标题为“本地使用 IPv6 单播地址”的部分拆分为两个部分，“链路本地 IPv6 单播地址”和“站点本地 IPv6 单播地址”。

- 在描述站点本地弃用的新部分中添加了文本。

** 为解决 IAB 对 Robert Elz 上诉的回应中提出的问题所做的更改。更改包括以下内容：

- 在第 2.5 节中添加了说明，即节点不应对 IPv6 地址的结构做出任何假设。

- 更改了第 2.5.1 节和附录 A 中的文本，以引用“u”位设置为一 (1) 的修改后的 EUI-64 格式接口标识符作为通用。

- 在第 2.5.1 节中添加了说明，即 IPv6 节点不需要验证以修改后的 EUI-64 格式创建的接口标识符，“u”位设置为 1 是唯一的。

** 将第 2.5.4 节“全球单播地址”中指示的参考更改为 RFC 3587。

** 删除了示例中提到的 NSAP 地址。

** 澄清文本表示中的“x”可以是一到四位数字。

** 弃用了“IPv6 兼容地址”，因为它没有在 IPv6 转换机制中使用。

** 在组播地址的第 2.7 节中添加了“R”和“P”标志，以及指向定义它们的文档的指针。

** 编辑更改。

完整的版权声明

版权所有 (C) 互联网协会 (2006)。

本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。

本文档和此处包含的信息按“原样”提供，贡献者、他/她代表或由（如果有）赞助的组织、互联网协会和互联网工程工作组不提供任何明示或暗示的，包括但不限于任何保证使用此处的信息不会侵犯任何权利或任何关于适销性或特定用途适用性的暗示保证。

知识产权

IETF 对可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或在此类权利下的任何许可可能或可能不会的程度不持任何立场能得到的;它也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序信息，请参见 BCP 78 和 BCP 79。

向 IETF 秘书处披露的 IPR 披露副本以及任何保证可用的许可，或试图获得本规范的实施者或用户使用此类专有权利的一般许可或许可的结果，可以获得来自位于 http://www.ietf.org/ipr 的 IETF 在线 IPR 存储库。

IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施该标准可能需要的技术的其他专有权利。请将信息发送至 IETF，地址为 ietf-ipr@ietf.org。

致谢

RFC Editor 功能的资金由 IETF 管理支持活动 (IASA) 提供。