2.1 引言
本章介绍了 Internet 中使用的网络层地址，又称为 IP 地址。我们讨论了如何为 Internet 中的设备分配地址，有助于路由可扩展性的地址层次结构分配方式，以及特殊用途的地址，包括广播、组播和任播地址。我们还讨论了 IPv4 和 IPv6 地址结构和用途的区别。
连接到 Internet 的每个设备至少有一个 IP 地址。基于 TCP/IP 协议的专用网络中使用的设备也需要 IP 地址。在任何情况下， IP 路由器（见第 5 章）实现的转发程序使用 IP 地址来识别流量去向。 IP 地址也表示流量来源。 IP 地址在某些方面与电话号码相似，但最终用户通常知道并直接使用电话号码，而IP 地址通常被 Internet 中的 DNS （见第11章）屏蔽在用户视线之外， DNS 让大多数用户使用名字而不是数字地址。当用户需要自已建立网络或 DNS 由于某种原因失效时，用户需要直接处理 IP 地址。为了了解 Internet 如何识别主机和路由器，并在它们之间实现流量的交付，我们必须了解 IP 地址的作用。因此，我们对它们的管理、结构和用途感兴趣。
当一台设备连接到全球性的 Internet 时，为它们分配地址就必须经过协调，这样就不会重复使用网络中的其他地址。对于专用网络，使用的 IP 地址必须经过协调，以避免在专用网络中出现类似的重复。成组的 IP 地址被分配给用户和组织。这些地址的拥有者再将它们分配给设备，这通常根据某些“编号方案”进行。对于全球性的 Internet 地址，一个分层结构管理实体帮助用户和服务提供商分配地址。个人用户通常由 **Internet服务提供商（ ISP ）**分配地址，通过支付费用来获得地址和执行路由。
2.2 表示 IP 地址
大多数 Internet 用户熟悉IP地址，并且了解最流行的地址类型：IPv4 地址。这些地址通常采用所谓的点分四组或点分十进制表示法，例如 165.195.130.107。点分四组表示法由四个用点分隔的十进制数组成。每个这样的数字是一个非负整数，范围为 [0， 255]，代表整个 IP 地址的四分之一。点分四组表示法是编写完整的 IPv4 地址（一个用于 Internet 系统的 32 位非负整数）的简单方式，它使用便捷的十进制数。在很多情况下，我们将关注这种地址的二进制结构。很多 Internet 站点，例如 http://www.subnetmask.info 和 http://www.subnetcalculator.com ，包含用于 IP 地址和相关信息之间格式转换的计算器。表2-1给出了几个 IPv4 地址的例子，以及对应的二进制表示，供大家开始学习。
| 点分四组表示 | 二进制表示 |
|---|---|
| 0.0.0.0 | 00000000 00000000 00000000 00000000 |
| 1.2.3.4 | 00000001 00000010 00000011 00000100 |
| 10.0.0.255 | 00001010 00000000 00000000 11111111 |
| 255.255.255.255 | 11111111 11111111 11111111 11111111 |
在 IPv6 中，地址的长度是 128 位，是 IPv4 地址长度的 4 倍。一般来说，大多数用户对它不太熟悉。 IPv6 地址的传统表示方法是采用称为块或字段的四个十六进制数，这些被称为块或字段的数由冒号分隔。例如，一个包含 8 个块的 IPv6 地址可写为5f05:2000:80ad:5800:0058:0800:2023:1d71 。虽然不像用户熟悉的十进制数，但将十六进制数转换为二进制更容易。另外，一些已取得共识的 IPv6 地址简化表示法已被标准化 [RFC4291] ：
- 一个块中前导的零不必书写。在前面的例子中，地址可写为
5f05:2000:80ad:5800:58:800:2023:1d71。 - 全零的块可以省略，并用符号
::代替。例如，地址0:0:0:0:0:0:0:1可简写为::1。同样，地址2001:0db8:0:0:0:0:0:2可简写为2001:0db8::2。为了避免出现歧义，一个 IPv6 地址中符号::只能使用一次。 - 在 IPv6 格式中嵌入 IPv4 地址可使用混合符号形式，紧接着 IPv4 部分的地址块的值为
ffff，地址的其余部分使用点分四组格式。例如，IPv6 地址::ffff:10.0.0.1可表示 IPv4 地址10.0.0.1。它被称为 IPv4 映射的 IPv6 地址。 - IPv6 地址的低 32 位通常采用点分四组表示法。因此，IPv6 地址
::0102:f001相当于地址::1.2.240.1。它被称为IPv4 兼容的 IPv6 地址。需要注意，IPv4 兼容地址与 IPv4 映射地址不同；它们只是在能用类似 IPv4 地址的方式书写或由软件处理方面给人以兼容的感觉。这种地址最初用于 IPv4 和 IPv6 之间的过渡计划，但现在不再需要 [RFC4291] 。
表 2-2 介绍了一些 IPv6 地址的例子以及它们的二进制表示。
| 十六进制表示 | 二进制表示 |
|---|---|
| 5f05:2000:80ad:5800:0058:0800:2023:1d71 | 0101111100000101 0010000000000000 1000000010101101 0101100000000000 0000000001011000 0000100000000000 0010000000100011 0001110101110001 |
| ::1 | 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000001 |
| ::1.2.240.1 或 ::102:f001 | 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000100000010 1111000000000001 |
在某些情况下（例如表示一个包含地址的 URL 时），IPv6 地址中的冒号分隔符可能与其他分隔符混淆，例如 IP 地址和端口号之间使用的冒号。在这种情况下，用括号字符 [ 和 ] 包围 IPv6 地址。例如， URL
http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/
是指IPv6主机 2001:0db8:85a3:08d3:1319:8a2e:0370:7344 中的端口号 443 使用 HTTP、 TCP 和 IPv6 协议。
[RFC4291] 提供的灵活性造成了不必要的混淆，这是因为能用多种方式表示相同的 IPv6 地址。为了弥补这种情况，[RFC5952] 制定了一些规则，以缩小选择范围，同时与 [RFC4291] 保持兼容。这些规则如下：
- 前导的零必须压缩（例如，
2001:0db8::0022编程2001:db8::22）。 ::只能用于影响最大的地方（压缩最多的零），但并不只是针对 16 位的块。如果多个块中包含等长度的零，顺序靠前的块将被替换为::。- a 到 f 的十六进制数字应该用小写表示。
在大多数情况下，我们会遵守这些规则。
2.3 基本的 IP 地址结构
IPv4 地址空间中有 4 294 967 296 个可能的地址，而 IPv6 的地址个数为
340 282 366 920 938 463 463 374 607 431 768 211 456
由于拥有大量地址（特别是 IPv6），可以方便地将地址空间划分成块。IP 地址可根据类型和大小分组。大多数 IPv4 地址块最终被细分为一个地址，用于识别连接 Internet 或某些专用的内联网的计算机网络接口。这些地址称为单播地址。 IPv4 地址空间中大部分是单播地址空间。 IPv6 地址空间中大部分目前未使用。除了单播地址，其他类型的地址包括广播、组播和任播地址，它们可能涉及多个接口，还有一些特殊用途的地址，我们将在后面讨论它们。在开始介绍当前地址结构的细节之前，理解 IP 地址的历史演变是有用的。
2.3.1 分类寻址
当最初定义 Internet 地址结构时，每个单播 IP 地址都有一个网络部分，用于识别接口使用的 IP 地址在哪个网络中可被发现；以及一个主机地址，用于识别由网络部分给出的网络中的特定主机。因此，地址中的一些连续位称为网络号，其余位称为主机号。当时，大多数主机只有一个网络接口，因此术语接口地址和主机地址有时交替使用。
现实中的不同网络可能有不同数量的主机，每台主机都需要一个唯一的 IP 地址。一种划分方法是基于当前或预计的主机数量，将不同大小的 IP 地址空间分配给不同的站点。地址空间的划分涉及五大类。每类都基于网络中可容纳的主机数量，确定在一个 32 位的 IPv4 地址中分配给网络号和主机号的位数。图 2-1 显示了这个基本思路。
图 2-1 IPv4 地址空间最初分为五大类。A、B、C 类用于为 Internet （单播地址）中的接口分配地址，以及其他一些特殊情况下使用。类由地址中的头几位来定义：0 为 A 类，10 为 B 类，110 为 C 类等。D 类地址供组广播使用（见第 9 章），E 类地址保留
这里，我们看到5个类被命名为 A、 B、 C、 D 和 E。 A、 B、 C 类空间用于单播地址。如果我们仔细看这些地址结构，可看到不同类的相对大小，以及在实际使用中的地址范围。表 2-3 给出了这种类结构（有时被称为分类地址结构）。
| 类 | 地址范围 | 高序位 | 用途 | 百分比 | 网络数 | 主机数 |
|---|---|---|---|---|---|---|
| A | 0.0.0.0 ~ 127.255.255.255 | 0 | 单播/特殊 | 1/2 | 128 | 16777216 |
| B | 128.0.0.0 ~ 191.255.255.255 | 10 | 单播/特殊 | 1/4 | 16384 | 65536 |
| C | 192.0.0.0 ~ 223.255.255.255 | 110 | 单播/特殊 | 1/8 | 2097152 | 256 |
| D | 224.0.0.0 ~ 239.255.255.255 | 1110 | 组播 | 1/16 | N/A | N/A |
| E | 240.0.0.0 ~ 255.255.255.255 | 1111 | 保留 | 1/16 | N/A | N/A |
该表显示了分类地址结构的主要使用方式，如何将不同大小的单播地址块分配给用户。类划分基于给定大小的可用网络数和给定网络中的可分配主机数之间的折中。例如，某个站点分配了一个A类网络号 18.0.0.0 (MIT)，其中有 224 个地址分配给主机（即 IPv4 地址使用范围 18.0.0.0 ~ 18.255.255.255），但在整个 Internet 中只有 127 个A类网络。某个站点分配了一个 C 类网络号，例如 192.125.3.0，只能容纳 256 台主机（也就是说在范围 192.125.3.0 ~ 192.125.3.255 内），但有超过 200 万的 C 类网络号是可用的。
注意 这些数字是不准确的。有几个地址通常不作为单播地址使用。特别是，地址块中的第一个和最后一个地址通常不使用。在我们的例子中，站点分配的地址块为 18.0.0.0，实际能分配多达 224 - 2 = 16777214 个单播IP地址。
Internet 地址分类方法在经历 Internet 增长（20 世纪 80年代）的第一个十年中没有变化。此后，它开始出现规模问题，当每个新的网段被添加到 Internet 中，集中协调为其分配一个新的 A 类、B 类或 C 类网络号变得很不方便。另外， A 类和 B 类网络号通常浪费太多主机号，而 C 类网络号不能为很多站点提供足够的主机号。
2.3.2 子网寻址
Internet 发展初期首先遇到一个困难，那就是很难为接入 Internet 的新网段分配一个新的网络号。在 20 世纪 80 年代初，随着局域网（LAN）的发展和增加，这个问题变得更棘手。为了解决这个问题，人们很自然想到一种方式，在一个站点接入 Internet 后为其分配一个网络号，然后由站点管理员进一步划分本地的子网数。在不改变 Internet 核心路由基础设施的情况下解决这个问题将会更好。
实现这个想法需要改变一个 IP 地址的网络部分和主机部分的限制，但这样做只是针对一个站点自身而言； Internet 其余部分将只能“看到”传统的 A 类、 B 类和 C 类部分。支持此功能的方法称为 子网寻址 [RFCO950] 。通过子网寻址，一个站点被分配一个 A 类、 B 类或 C 类的网络号，保留一些剩余主机号进一步用于站点内分配。该站点可能将基础地址中的主机部分进一步划分为一个子网号和一个主机号。从本质上来说，子网寻址为 IP 地址结构增加了一个额外部分，但它没有为地址增加长度。因此，一个站点管理员能在子网数和每个子网中预期的主机数之间折中，同时不需要与其他站点协调。
子网寻址提供额外灵活性的代价是增加成本。由于当前的子网字段和主机字段的定义由站点指定的（不是由网络号分类决定），一个站点中所有路由器和主机需要一种新的方式，以确定地址中的子网部分和其中的主机部分。在出现子网之前，这个信息可直接从一个网络号中获得，只需知道是 A 类、 B 类或 C 类地址（由地址的前几位表示）。图 2-2 给出了使用子网寻址的例子，显示了一个 IPv4 地址可能的格式。
图 2-2 一个 B 类地址被划分子网的例子。它使用 8 位作为子网 ID，提供 256 个子网和每个子网中 254 台主机。这种划分可由网络管理员改变
图 2-2 是一个 B 类地址被“划分子网”的例子。假设 Internet 中的一个站点已被分配一个 B 类网络号。该站点将每个地址的前 16 位固定为某些特定号码，这是由于这些位已被分配给核心机构。后 16 位（仅用于在无子网的 B 类网络中创建主机号）现在可以由站点的网络管理员接需分配。在这个例子中， 8 位被选定为子网号，剩下 8 位为主机号。这个特殊配置允许站点支持 256 个子网，每个子网最多可包含 254 台主机（当前每个子网的第一个和最后一个地址无效，即从整个分配范围中除去第一个和最后一个地址)。注意，只有划分子网的网络中的主机和路由器知道子网结构。在需要进行子网寻址之前， Internet 其他部分仍将它作为站点相关的地址来看待。图 2-3 显示了如何工作。
图 2-3 某个站点被分配一个典型的 B 类网络号 128.320。网络管理员决定用于站点范围内的子网掩码为 255.255.255.0，提供 256 个子网，每个子网可容纳 256 - 2 = 254 台主机。同一子网中每台主机的 IPv4 地址拥有相同子网号。左侧的局域网段中主机的 IPv4 地址开始于 128.32.1，右侧的所有主机开始于 128.32.2
本图显示了一个虚拟的站点，使用一个边界路由器（即 Internet 的一个连接点）连接 Internet 和两个内部局域网。x 的值可以是 [0，255] 范围内的任意值。每个以太网是一个 IPv4 子网，整体分配为 B 类地址的网络号 128.32。 Internet 中的其他站点要访问这个站点，目的地址以 128.32 开始的所有流量直接由 Internet 路由系统交给边界路由器（特别是其接口的 IPv4 地址137.164.23.30)。在这点上，边界路由器必须区分 128.32 网络中的不同子网。特别是，它必须能区分和分离目的地址为 128.32.1.x 和目的地址为 128.32.2.x 的流量。这些地址分别表示子网号 1 和 2，它们都采用 128.32 的 B 类网络号。为了做到这点，路由器必须知道在地址中如何找到子网ID。这可通过一个配置参数实现，我们将在后面加以讨论。
2.3.3 子网掩码
子网掩码是由一台主机或路由器使用的分配位，以确定如何从一台主机对应 IP 地址中获得网络和子网信息。 IP 子网掩码与对应的 IP 地址长度相同（IPv4为 32 位， IPv6为 128 位）。它们通常在一台主机或路由器中以 IP 地址相同的方式配置，既可以是静态的（通常是路由器），也可以使用一些动态方式，例如动态主机配置协议(DHCP ；见第 6 章)。对于 IPv4，子网掩码以 IPv4 地址相同的方式（即点分十进制）编写。虽然最初不需要以这种方式分配，当前子网掩码由一些 1 后跟一些 0 构成。这样安排，就可以用容易记的格式表示掩码，只需给出一些连续位的 1 （左起）的掩码。这种格式是当前最常见的格式，有时也被称为前缀长度。表 2-4 列出了 IPv4 的一些例子。
| 点分十进制表示 | 容易记的格式（前缀长度） | 二进制表示 |
|---|---|---|
| 128.0.0.0 | /1 | 10000000 00000000 00000000 00000000 |
| 255.0.0.0 | /8 | 11111111 00000000 00000000 00000000 |
| 255.192.0.0 | /10 | 11111111 11000000 00000000 00000000 |
| 255.255.0.0 | /16 | 11111111 11111111 00000000 00000000 |
| 255.255.254.0 | /23 | 11111111 11111111 11111110 00000000 |
| 255.255.255.192 | /27 | 11111111 11111111 11111111 11100000 |
| 255.255.255.255 | /32 | 11111111 11111111 11111111 11111111 |
表 2-5 列出了 IPv6 的一些例子。
| 十六进制表示 | 容易记的格式（前缀长度） | 二进制表示 |
|---|---|---|
| ffff:ffff:ffff:ffff:: | /64 | 1111111111111111 1111111111111111 1111111111111111 1111111111111111 0000000000000000 0000000000000000 0000000000000000 0000000000000000 |
| ff00:: | /8 | 1111111100000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 |
掩码由路由器和主机使用，以确定一个 IP 地址的网络 / 子网部分的结束和主机部分的开始。子网掩码中的一位设为 1 表示一个 IP 地址的对应位与一个地址的网络 / 子网部分的对应位相结合，并将结果作为转发数据报的基础（见第5章）。相反，子网掩码中的一位设为 0，表示一个 IP 地址的对应位作为主机 ID 的一部分。例如，我们在图 2-4 中可以看到，当子网掩码为 255.255.255.0 时，如何处理 IPv4 地址 128.32.1.14。
图 2-4 一个 IP 地址可以与一个子网掩码使用按位与操作，以形成用于路由的地址的网络 / 子网标识符（前缀）。在这个例子中， IPv4 地址 128.32.1.14 使用长度为 24 的掩码得到前缀128.32.1.0/24
这里，我们看如何将地址中的每位与子网掩码中的对应位进行与运算。回顾按位与运算，如果掩码和地址中的对应位都是 1，则结果位都只能是 1。在这个例子中，我们看到地址 128.32.1.14 属于子网 128.32.1.0/24 。图 2-3 中是边界路由器需要的信息，以确定一个目的地址为 128.32.1.14 的数据报需要转发到的系统所在的子网。注意， Internet 路由系统其余部分不需要子网掩码的知识，因为站点之外的路由器做出路由决策只基于地址的网络号部分，并不需要网络 / 子网或主机部分。因此，子网掩码纯粹是站点内部的局部问题。
2.3.4 可变长度子网掩码
目前为止，我们已讨论如何将一个分配给站点的网络号进一步细分为多个可分配的大小相同的子网，并根据网络管理员的合理要求使每个子网能支持相同数量的主机。我们发现在同一站点的不同部分，可将不同长度的子网掩码应用于相同网络号。虽然这样增加了地址配置管理的复杂性，但也提高了子网结构的灵活性，这是由于不同子网可容纳不同数量的主机。目前，大多数主机、路由器和路由协议支持可变长度子网掩码（VLSM）。要了解 VLSM 如何工作，可以看图 2-5 所示的网络拓扑，它使用 VLSM 为图 2-3 扩展了两个额外的子网。
图 2-5 VLSM 可用于分割一个网络号，使每个子网支持不同数量的主机。每个路由器和主机除了 IP 地址，还需要配置一个子网掩码。大多数软件支持 VLSM，除了一些旧的路由协议（例如 RIP 版本 1）
在图 2-5 显示的更复杂的例子中，三个不同的子网掩码被用于站点中的子网 128.32.0.0/16 : /24、 /25 和 /26。这样，每个子网可提供不同数量的主机。主机数受 IP 地址中没有被网络 / 子网号使用的剩余位限制。对于 IPv4 和 /24 前缀，允许有 32-24=8 位 （ 256 台主机）；对于 /25，有 1/2 数量（ 128 台主机）；对于 /26 ，有 1/4 数量（ 64 台主机）。注意，主机和路由器的每个接口都需要用 IP 地址和子网掩码来描述，但掩码决定了网络拓扑的不同。基于路由器中运行的动态路由协议(例如 OSPF、 IS-IS、 RIPv2)，流量能正确地在同一站点中的主机之间流动，以及通过 Internet 前往或来自外部站点。
尽管这可能并不显而易见，但有一个常见情况，即一个子网中只包含两台主机。当路由器之间被一条点到点链路连接，则每个端点都需要分配一个 IP 地址，常见做法是 IPv4 使用 /31 为前缀，目前也有建议 IPv6 使用 /127 为前缀 [RFC6164] 。
2.3.5 广播地址
在每个 IPv4 子网中，一个特殊地址被保留作为子网广播地址。子网广播地址通过将 IPv4 地址的网络 / 子网部分设置为适当值，以及主机部分的所有位设置为 1 而形成。我们看图 2-5 中最左边的子网，它的前缀是 128.32.1.0/24。子网广播地址的构建方式为：对子网掩码取反（即将所有的0位改变为1，反之亦然），并与子网中任意计算机的地址(或等值的网络 / 子网前缀)进行按位或运算。注意，如果两个输入位之一为 1，按位或运算的结果为1。图 2-6 显示了这个计算过程，其中使用 IPv4 地址128.32.1.14。
图 2-6 子网广播地址由子网掩码首先取反，然后与 IPv4 地址进行或运算构成。在这种情况下，一个 /24 的子网掩码，剩余的 32-24 = 8 位设置为 1，得到一个十进制 255 和子网广播地址 128.32.1.255
如图2-6所示，子网 128.32.1.0/24 的子网广播地址是 128.32.1.255。从历史上看，使用这种地址作为目的地的数据报，也被称为定向广播。至少在理论上，这种广播可作为一个单独的数据报通过 Internet 路由直至到达目标子网，再作为一组广播数据报发送给子网中所有主机。对这个想法做进一步概括，我们可形成一个目的 IPv4 地址为 128.32.255.255 的数据报，并且通过图 2-3 或图 2-5 所示的连接网络将它发送到 Internet 。这时，该数据报将发送给目标站点中的所有主机。
注意 定向广播是一个大问题，从安全的角度来看，它们至今在 Internet 中仍被禁用。 [RFCO919] 描述了针对 IPv4 的各类广播， [RFC1812] 建议支持由路由器转发定向广播，它不仅可用，而且默认启用。 [RFC2644] 使这个策略发生逆转，路由器现在默认禁止转发定向广播，甚至完全省略支持能力。
除了子网广播地址，特殊用途地址 255.255.255.255 被保留为本地网络广播（也称为有限广播），它根本不会被路由器转发（详见 2.5 节中的特殊用途地址）。注意，虽然路由器可能不转发广播，但子网广播和连接在同一网络中的计算机的本地网络广播将工作，除非被终端主机明确禁用。这种广播不需要路由器；如果有的话，链路层的广播机制用于支持它们（见第3章）。广播地址通常与某些协议一起使用，例如 UDP/IP （第 10 章）或 ICMP （第 8 章），因为这些协议不涉及 TCP/IP 那样的双方会话。 IPv6 没有任何广播地址；广播地址可用于 IPv4 中，而 IPv6 仅使用组播地址（见第 9 章）。
2.3.6 IPv6 地址和接口标识符
除了比 IPv4 地址长 4 倍这个因素， IPv6 地址还有一些额外的特点。 IPv6 地址使用特殊前缀表示一个地址范围。一个 IPv6 地址范围是指它可用的网络规模。有关范围的重要例子包括节点本地（只用于同一计算机中通信）、链路本地（只用于同一网络链路或 IPv6 前缀中的节点）或全球性（ Internet 范围）。在 IPv6 中，大部分节点通常在同一网络接口上使用多个地址。虽然 IPv4 中也支持这样做，但是并不常见。一个 IPv6 节点中需要一组地址，包括组播地址(见 2.5.2 节)，它来源于 [RFC4291] 。
注意 另一个范围层次称为站点本地，使用的前缀为 fec0::/10，最初是由 IPv6 支持的，后来被 [RFC3879] 放弃并用于单播地址。主要问题包括如何处理这种地址，这是由于它可能被重用于多个站点，以及如何准确定义一个“站点”。
链路本地 IPv6 地址（和一些全球性 IPv6 地址）使用**接口标识符（ IID ）**作为一个单播 IPv6 地址的分配基础。除了地址是以二进制值 000 开始之外， IID 在所有情况下都作为一个 IPv6 地址的低序位，这样它们必须在同一网络中有唯一前缀。 IID 的长度通常是 64 位，并直接由一个网络接口相关的链路层 MAC 地址形成，该地址使用 修改的 EUI-64 格式 [EUI64]，或者由其他进程随机提供的值形成，以提供可防范地址跟踪的某种程度的隐私保护（见第 6 章）。
在 IEEE 标准中， EUI 表示扩展唯一标识符。 EUI-64 标识符开始于一个 24 位的组织唯一标识符（ OUI ），接着是一个由组织分配的 40 位扩展标识符，它由前面 24 位识别。 OUI 由 IEEE 注册权威机构 [IEEERA] 来维护和分配。 EUI 可能是“统一管理”或“本地管理”的。在 Internet 环境下，这种地址通常是统一管理的。
多年来，很多 IEEE 标准兼容的网络接口（例如以太网）在使用短格式的地址（48位的
EUI）。 EUI-48 和 EUI-64 格式之间的显著区别是它们的长度（见图 2-7）。
图 2-7 EUI-48 和 EUI-64 格式由 IEEE 定义。这些都是用于 IPv6 的地址，它们是通过将接口标识符反 u 位来形成的
OUI 的长度是 24 位，并占据 EU1-48 和 EU1-64 地址的前 3 个字节。这些地址的第一个字节的低两位分别是 u 位和 g 位。当 u 位被设置时，表示该地址是本地管理。当 g 位被设置时， 表示该地址是一组或组播类型的地址。目前，我们只关心 g 位未被设置的情况。
一个 EUI-64 地址可以由 EUI-48 地址形成，将 EU1-48 地址的24位 OUI 值复制到 EU1-64 地址，并将 EUI-64 地址的第 4 和第 5 个字节的 16 位替换为 1111111111111110 （十六进制 FFFE），然后复制由组织分配的剩余位。例如， EUI-48 地址 00-11-22-33-44-55 在 EUI-64地址中将会变成 00-11-22-FF-FE-33-44-55。 这个映射的第一步是当可以用基本 EUI-48 地址时由 IPv6 构造接口标识符。修改的 EUI-64 用于形成 IPv6 地址的 IID，但是需要对 u 位取反。
当一个 IPv6 接口标识符需要一种接口，并且该接口没有由制造商提供 EUI-48 地址，但是有其他类型的基本地址时（例如 AppleTalk ），基本地址可用 0 从左侧填充形成接口标识符。当接口标识符是为缺乏任意形式标识符的接口（例如隧道、串行链路）创建时，它可由相同节点上（不在同一子网中）的其他接口，或者与节点有关联的某些标识符派生。在缺乏其他选择的情况下，手动分配是最后的方案。
2.3.6.1 例子
我们探讨使用 Linux 的 ifconfig 命令形成一个链路本地 IPv6 地址的方式:
Linux% ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:30:48:2A:19:89
inet addr:12.46.129.28 Bcast:12.46.129.127
Mask:255.255.255.128
inet6 addr: fe80::230:48ff:fe2a:1989/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1359970341 errors:0 dropped:0 overruns:0 frame:0
TX packets:1472870787 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4021555658 (3.7 GiB) TX bytes:3258456176 (3.0 GiB)
Base address:0x3040 Memory:f8220000-f8240000
这里，我们可看到以太网硬件地址 00:30:48:2A:19:89 如何被映射为一个IPv6地址。首先，它被转换为 EUI-64 形成地址 00:30:48:ff:fe:2a:19:89。 接着， u 位被取反，形成 IID 值02:30:48:ff:fe:2a:19:89。 为了完成链路本地 IPv6 地址，我们使用保留的链路本地前缀 fe80::/10 （见 2.5 节）。总之，这样形成完整地址 fe80::230:48ff:fe2a:1989。 /64 是标准长度，用于从一个 IPv6 地址中识别子网/主机部分，它由 [RFC4291] 要求的一个 IID 派生。
另一个有趣的例子来自支持 IPv6 的 Windows 系统。在这个例子中，我们将看到一个特殊的隧道端点，它被用于使 IPv6 流量通过仅支持 IPv4 的网络:
c:\> ipconfig /all
...
Tunnel adapter Automatic Tunneling pseud Interface:
Connection-specific DNS Suffix . : foo
Description . . . . . . . . . . . : Automatic Tunneling
Pseudo一Interface
Physical Address . . . . . . . . . : 0A-99-BD-87
dhcp Enabled . . . . . . . . . . . : No
IP Address . . . . . . . . . . . . : fe80::5efe:10.153.141.135%2
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%2
fec0:0:0:ffff::2%2
fec0:0:0:ffff::3%2
NetBIOS over Tcpip . . . . . . . . : Disabled
在这个例子中，我们可以看到一个特殊的隧道接口为 ISATAP[RFC5214]。实际上，所谓的物理地址是 IPv4 地址的十六进制编码：0A-99-8D-87 与 10.153.141.135 相同。这里，使用的 OUI （00-00-5E）是由 IANA 分配的 [IANA]。它被用于与十六进制值 fe 组合，表示一个嵌入的 IPv4 地址。然后，这个组合与标准的链路本地前缀 fe80::/10 组合，最终形成地址 fe80::5efe:10.153.141.135。 附加在地址结尾的 %2 在 Windows 中称为** 区域ID**，表示主机中对应于 IPv6 地址的接口索引号。 IPv6 地址通常由一个自动配置过程创建，我们在第6章详细讨论这个过程。
2.4 CIDR 和聚合
20 世纪 90 年代初，在采用子网寻址缓解增长带来的痛苦后， Internet 开始面临更严重的规模问题。有三个问题很重要，需要立即引起注意：
- 到1994年，一半以上的 B 类地址已被分配。预计， B 类地址空间大约在 1995 年将被用尽。
- 32 位的 IPv4 地址被认为不足以应付 Internet 在 21 世纪初的预期规模。
- 全球性路由表的条目数（每个网络号对应一条）， 1995 年大约为 65000 个条目，目前仍在增长中。随着越来越多 A 类、 B 类和 C 类路由条目的出现，路由性能将受到影响。
从 1992 年开始，这些问题受到 IETF 中的 ROAD （路由和寻址）小组的关注。他们认为问题 1 和 3 将很快来临，问题 2 需要一个长期的解决方案。他们提出的短期解决方案是有效清除 IP 地址的分类缺陷，并提高层次化分配的 IP 地址的聚合能力。这些措施将有助于解决问题 1 和 3 。 IPv6 被设想用于解决问题 2。
2.4.1 前缀
为了帮助缓解 IPv4 地址（特别是B类地址）的压力，分类寻址方案通常使用一个类似 VLSM 的方案，扩展 Internet 路由系统以支持无类别域间路由（Classless Inter-Domain Routing，CIDR） [RFC4632]。这提供了一种方便的分配连续地址范围的方式，包含多于 255 台但少于 65536 台主机。也就是说，不只是单个 B 类或多个 C 类网络号可分配给站点。使用 CIDR，未经过预定义的任何地址范围可作为一个类的一部分：但需要一个类似于子网掩码的掩码，有时也称为 CIDR 掩码。CIDR 掩码不再局限于一个站点，而对全球性路由系统都是可见的。因此，除了网络号之外，核心 Internet 路由器必须能解释和处理掩码。这个数字组合称为网络前缀，它用于 IPv4 和 IPv6 地址管理。
消除一个 IP 地址中网络和主机号的预定义分隔，将使更细粒度的 IP 地址分配范围成为可能。与分类寻址类似，地址空间分割成块最容易通过数值连续的地址来实现，以便用于某种类型或某些特殊用途。目前，这些分组普遍使用地址空间的前缀表示。一个 n 位的前缀是一个地址的前 n 个位的预定义值。对于IPv4， n （前缀长度）的值通常在范围 0 ~ 32 ；对于 IPv6，通常在范围 0 ~ 128。它通常被追加到基本 IP 地址，并且后面跟着一个 / 字符。表 2-6 给出了一些前缀的例子，以及相应的 IPv4 或 IPv6 地址范围。
| 前缀 | 前缀（二进制） | 地址范围 |
|---|---|---|
| 0.0.0.0/0 | 00000000 00000000 00000000 00000000 | 0.0.0.0 ~ 255.255.255.255 |
| 128.0.0.0/1 | 10000000 00000000 00000000 00000000 | 128.0.0.0 ~ 255.255.255.255 |
| 128.0.0.0/24 | 10000000 00000000 00000000 00000000 | 128.0.0.0 ~ 128.0.0.255 |
| 198.128.128.192/27 | 11000110 10000000 10000000 11000000 | 198.128.128.192 ~ 198.128.128.223 |
| 165.195.130.107/32 | 10100101 11000011 100000010 01101011 | 165.195.130.107 |
| 2001:db8::/32 | 0010000000000001 0000110110111000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 | 2001:db8:: ~ 2001:db8:ffff:ffff |
在这个表中，由前缀来定义并固定的位被加粗表示。剩余位可设置为 0 和 1 的任意组合，从而涵盖可能的地址范围。显然，一个较小的前缀长度可对应于一个更大的地址范围。另外，早期的分类寻址方案易于被这个方案覆盖。例如， C 类网络号 192.125.3.0 可以写成前缀 192.125.3.0/24 或 192.125.3/24。 分类的 A 类和 B 类网络号可分别用前缀长度 /8 和 /16 表示。
2.4.2 聚合
通过取消分类结构的 IP 地址，能分配各种尺寸的 IP 地址块。但是，这样做没有解决问题列表中的第三个问题，它并没有帮助减少路由表条目数。一条路由表条目告诉一个路由器向哪里发送流量。从本质上来说，路由器检查每个到达的数据报中的目的 IP 地址，找到一条匹配的路由表条目，并从该条目中提取数据报的“下一跳”。这有点像驾驶汽车去一个特定地址，并在沿路每个路口找到一个标志，指示沿着哪个方向去目的地路线的下一个路口。如果你能理解在每个路口设置很多标志，以指向每个可能的目的地的情形，就能认识到20 世纪 90 年代初 Internet 面临的一些问题。
当时，没什么技术可以解决以下问题：在维护 Internet中 到所有目的地的最短路径的同时，又能够显著减少路由表条目数。最有名的方法是 20 世纪 70 年代末由 Kleiurock 和 Kamoun 发表的分层路由研究 [KK77]。他们发现，如果将网络拓扑排列为一棵树，并且以对这个网络拓扑“敏感的”方式来分配地址，这样可获得一个非常小的路由表，同时保持到所有目的地的最短路径。大家可以看图 2-8 。
图 2-8 中左侧树的根（顶级）是标记为 19.12.4.8 的路由器。为了知道每个可能的目的地的下一跳，它需要一个树中在其“下面的”所有路由器的条目：190.16.11.2、 86.12.0.112、159.66.2.231、 133.17.97.12、 66.103.2.19、 18.1.1.1、 19.12.4.9 203.44.23.198。 对于任何其他目的地，它只需简单地路由到标有“网络其他部分”的云中。结果共有 9 个条目。相比之下，右侧树的根被标记为 19.0.0.1，并要求其路由表中只有 3 个条目。注意，右树中左侧的所有路由器以前缀 19.1 开始，右侧的所有路由器以前缀 19.2 开始。因此，路由器 19.0.0.1 的表中只需将以 19.1 开始的目的地显示下一跳为 19.1.0.1，而将以 19.2 开始的目的地显示下一跳为 19.2.0.1。任何其他目的地都被路由到标有“网络其他部分”的云中。结果共有 3 个条目。注意，这种行为是递归的，图 2-8b 所示树中的任意路由器，需要的条目数都不会超过它拥有的链路数。这是这种特殊的地址分配方法所带来的直接结果。即使越来越多的路由器加人图 2-8b 所示的树，这个良好的属性也保持不变。这是[KK77]的分层路由思想的精髓。
图 2-8 在树状拓扑网络中，网络地址可采用特殊方式分配，以限制需保存在路由器中的路由信息（“状态”）数量。如果不以这种（左侧的）方式分配地址，没有存储与需到达的节点数量成正比的状态，则最短路径无法得到保证。当以保存状态的树状拓扑敏感的方式分配地址时，如果网络拓扑发生变化，通常需要重新分配地址
在 Internet 环境中，可采用分层路由思想以一种特定方式减少 Internet 路由条目数。这通过一个称为路由聚合的过程来实现。通过将相邻的多个 IP 前缀合并成一个短前缀（称为一个聚合或汇聚），可以覆盖更多地址空间。我们可以看图 2-9。
图 2-9 在这个例子中，箭头表示将两个地址前缀聚合为一个，带下划线的前缀是每一步的结果。第一步，190.154.27.0/26 和 190.154.27.64.0/26 可以聚合，这是由于它们数值相邻，但是190.154.27.192/26 不能聚合。通过与 190.154.27.128/26 相加，它们可经过两步聚合形成190.154.27.0/24。最后，通过与相邻的 190.154.26.0/24 相加，生成聚合结果 190.154.26.0/23
首先看图 2-9 中左侧的三个地址前缀。前两个（ 190.154.27.0/26 和190.154.27.64/26）数值相邻，因此可被组合（聚合）。箭头表示聚合发生的地方。前缀 190.154.27.192/26 不能在第一步被聚合，由于它们并非数值相邻。当增加一个新前缀 190.154.27.128/26 （下划线），前缀 190.154.27.192/26 和 190.154.27.128/26 可能被聚合，并形成 190.154.27.128/25 前缀。这个聚合现在与聚合 190.154.27.0/25 相邻，因此它们可进一步聚合成 190.154.27.0/24。当增加前缀 190.154.26.0/24 （下划线），两个 C 类的前缀可以聚合成 190.154.26.0/23。这样，原来的三个前缀和两个增加的前缀可聚合成一个前缀。
2.5 特殊用途地址
IPv4 和 IPv6 地址空间中都包括几个地址范围，它们被用于特殊用途（因此不能用于单播地址分配）。对于 IPv4 ，这些地址显示在表 2-7 中 [RFC5735]。
| 前缀 | 特殊用途 | 参考文献 |
|---|---|---|
| 0.0.0.0/8 | 本地网络中的主机。仅作为源 IP 地址使用 | [RFC1122] |
| 10.0.0.0/8 | 专用网络（内联网）的地址。这种地址不会出现在公共 Internet 中 | [RFC1918] |
| 127.0.0.0/8 | Internet 主机回送地址（同一计算机）。通常只用 127.0.0.1 | [RFC1122] |
| 169.254.0.0/16 | “链路本地”地址，只用于一条链路，通常自动分配。见第 6 章 | [RFC3927] |
| 172.16.0.0/12 | 专用网络（内联网）的地址。这种地址不会出现在公共 Internet 中 | [RFC1918] |
| 192.0.0.0/24 | IETF 协议分配（IANA 保留） | [RFC5736] |
| 192.0.2.0/24 | 批准用于文档中的 TEST-NET-1 地址。这种地址不会出现在公共 Internet 中 | [RFC5737] |
| 192.88.99.0/24 | 用于 6to4 中继（任播地址） | [RFC3068] |
| 192.168.0.0/16 | 专用网络（内联网）的地址。这种地址不会出现在公共 Internet 中 | [RFC1918] |
| 192.18.0.0/15 | 用于基准和性能测试 | [RFC2544] |
| 198.51.100.0/24 | TEST-NET-2 地址。被批准用于文档中 | [RFC5737] |
| 203.0.113.0/24 | TEST-NET-3 地址。被批准用于文档中 | [RFC5737] |
| 224.0.0.0/4 | IPv4 组播地址（以前的 D 类），仅作为目的 IP 地址使用 | [RFC5771] |
| 240.0.0.0/4 | 保留空间（以前的 E 类），除了 255.255.255.255 | [RFC1112] |
| 255.255.255.255/32 | 本地网络（受限的）广播地址 | [RFC0919] [RFC9022] |
在 IPv6 中，许多地址范围和个别地址用于特定用途，它们都列在表 2-8 中 [RFC5156]。
| 前缀 | 特殊用途 | 参考文献 |
|---|---|---|
| ::/0 | 默认路由条目。不用于寻址 | [RFC5156] |
| ::/128 | 未指定地址，可作为源 IP 地址使用 | [RFC4291] |
| ::1/128 | IPv6 主机回送地址，不用于发送出本地主机的数据报中 | [RFC4291] |
| ::ffff:0:0/96 | IPv4 映射地址。这种地址不会出现在分组头部，只用于内部主机 | [RFC4291] |
| ::{ipv4-address}/96 | IPv4 兼容地址。已过时，未使用 | [RFC4291] |
| 2001::/32 | Teredo 地址 | [RFC4380] |
| 2001:10::/28 | ORCHI（覆盖可路由加密散列标识符）。这种地址不会出现在公共 Internet 中 | [RFC4843] |
| 2001:db8::/32 | 用于文档和实例的地址范围。这种地址不会出现在公共 Internet 中 | [RFC3849] |
| 2002::/16 | 6to4 隧道中继的 6to4 地址 | [RFC3056] |
| 3ffe::/16 | 用于 6bone 实验。已过时，未使用 | [RFC3701] |
| 5f00::/16 | 用于 6bone 实验。已过时，未使用 | [RFC3701] |
| fc00::7 | 唯一的本地单播地址，不用于全球性 Internet | [RFC4193] |
| fe80::/10 | 链路本地单播地址 | [RFC4291] |
| ff00::/8 | IPv6 组播地址，仅作为目的 IP 地址使用 | [RFC4291] |
对于 IPv4 和 IPv6，没有指定作为特殊、组播或保留地址的地址范围可供单播使用。一些单播地址空间（IPv4 的前缀 10/8、 172.16/12 和 192.168/16，以及 IPv6 的前缀 fc00::/7） 被保留用于构建专用网络。来自这些范围的地址可用于一个站点或组织内部的主机和路由器之间的通信，但不能跨越全球性的 Internet。因此，这些地址有时也被称为不可路由的地址。也就是说，它们不能在公共 Internet 中路由。
专用、不可路由的地址空间管理完全由本地决定。IPv4 专用地址在家庭网络、中等规模和大型企业内部网络中很常见。它们经常与网络地址转换（NAT）结合使用，在 IP 数据报进入 Internet 时修改其中的 IP 地址。我们在第 7 章详细讨论 NAT。
2.5.1 IPv4/IPv6 地址转换
在有些网络中，可能需要在 IPv4 和 IPv6 之间转换 [RFC6127]。目前，已制定了一个用于单播转换的框架 [RFC6144]，以及一个正在开发的用于组播转换的方案 [IDv 4v6mc]。一个基本功能是提供自动、基于算法的地址转换。例如，使用“知名的” IPv6 前缀 64:ff9b::/96或其他指定前缀， [RFC6052] 定义了如何在单播地址中实现它。
该方案使用一种特殊地址格式，称为嵌入 IPv4 的 IPv6 地址。这种地址在 IPv6 地址内部包含 IPv4 地址。它可采用 6 种格式之一来编码， IPv6 前缀长度必须是下列数值之一：32、
40、 48、 56、 64 或 96。图 2-10 显示了可用的格式。
图 2-10 IPv4 地址可以嵌人 IPv6 地址中，形成一个嵌入 IPv4 的 IPv6 地址。有 6 种不同的格式可用，这取决于使用的 IPv6 前缀长度。众所周知的前缀（Well-Known Prefix） 64:ff9b::/96 可用于 IPv4 和 IPv6 单播地址之间的自动转换
在该图中，前缀既可以是一个众所周知的前缀，也可以是组织为转换器分配的唯一前缀。第 64 至 71 位必须设置为 0，以保持与 [RFC4291] 指定标识符的兼容性。后缀的位被保留，并且应设置为 00 然后，采用简单方法来生成嵌入 IPv4 的 IPv6 地址：将 IPv6 前缀与 32 位的 IPv4 地址相串联，并确保第 64 至 71 位被设置为 0 （如果有必要，插入）。在后缀的后面增加 0，直到生成一个 128 位地址。嵌入 IPv4 的 IPv6 地址使用 96 位前缀选项，该选项通常用前面提到的 IPv6 映射地址来表示（ [RFC4291]中的 2.2(3) 节）。例如，嵌入 IPv4 地址 198.51.100.16 和众所周知的前缀，生成地址 64:ff9b::198.51.100.16。
2.5.2 组播地址
IPv4 和 IPv6 支持组播寻址。一个 IP 组播地址（也称为组或组地址）标识一组主机接口，而不是单个接口。一般来说，一个组可以跨越整个 Internet。一个组所覆盖的网络部分称为组的范围 [RFC2365]。常见的范围包括节点本地（同一计算机）、链路本地（同一子网）、站点本地（适用于一些站点）、全球（整个Internet）和管理。管理范围的地址可用于一个网络区域内已手动配置到路由器的地址。站点管理员可将路由器配置为管理范围边界，这意味着相关组的组播流量不会被路由器转发。注意，站点本地和管理范围只在使用组播寻址时有效。
在软件的控制下，每个 Internet 主机中的协议栈能加入或离开一个组播组。当一台主机向一个组发送数据时，它会创建一个数据报，使用（单播） IP 地址作为源地址，使用组播 IP 地址作为目的地址。已加入组的所有主机将接收发送到该组的任何数据报。发送方通常不知道主机是否接收到数据报，除非它们明确做出应答。事实上，发送方甚至不知道通常有多少台主机接收它的数据报。
至此，原有的组播服务模型已成为大家所知的任意源组播（ASM）。在这种模型下，任何发送方可以发送给任何组；一个加入组的接收方被指定唯一的组地址。一种新方案称为源特定组播（SSM） [RFC3569][RFC4607]，在每个组中只使用一个发送方（见 [RFC4607] 的勘误表）。在这种情况下，当一台主机加入一个组后，它会被指定一个信道地址，其中包括一个组地址和一个源 IP 地址。 SSM 避免了 ASM 模型部署时的复杂性。尽管有多种组播形式在整个 Internet 中广泛使用，但 SSM 是当前更受欢迎的候选者。
在 Internet 社区中，对广域组播的理解和实现已经过十年以上的不懈努力，并且已经开发出大量的广域组播协议。全球性 Internet 组播如何工作的细节超出本文的范围，有兴趣的读者可以查看 [IMRO2]。第 9 章详细介绍本地 IP 组播如何工作。现在，我们要讨论 IPv4 和 IPv6 组播地址的格式和意义。
2.5.3 IPv4 组播地址
对于 IPv4， D 类空间（224.0.0.0 ~ 239.255.255.255）已被保留支持组播。 28 位空闲意味着可提供 228= 268 435 456 个主机组（每个组是一个 IP 地址）。这个地址空间被分为几个主要部分，它建立在对路由分配和处理的基础上 [IP4MA]。表 2-9 列出了这些主要部分。
| 范围（包含） | 特殊用途 | 参考文献 |
|---|---|---|
| 224.0.0.0 ~ 224.0.0.255 | 本地网络控制；不转发 | [RFC5771] |
| 224.0.1.0 ~ 224.0.1.255 | 互联网络控制；正常转发 | [RFC5771] |
| 224.0.2.0 ~ 224.0.255.255 | Ad hoc 块 1 | [RFC5771] |
| 224.1.0.0 ~ 224.1.255.255 | 保留 | [RFC5771] |
| 224.2.0.0 ~ 224.2.255.255 | SDP/SAP | [RFC4566] |
| 224.3.0.0 ~ 224.3.255.255 | Ad hoc 块 2 | [RFC5771] |
| 224.5.0.0 ~ 224.255.255.255 | 保留 | [IP4MA] |
| 225.0.0.0 ~ 231.255.255.255 | 保留 | [IP4MA] |
| 232.0.0.0 ~ 232.255.255.255 | 源特定组播（SSM） | [RFC4607] [RFC4608] |
| 233.0.0.0 ~ 233.251.255.255 | GLOP | [RFC3180] |
| 233.252.0.0 ~ 233.255.255.255 | Ad hoc 块 3（233.252.0.0/24 为文档保留） | [RFC5771] |
| 234.0.0.0 ~ 234.255.255.255 235.0.0.0 ~ 238.255.255.255 |
基于单播前缀的 IPv4 组播地址保留 | [RFC6034] [IP4MA] |
| 239.0.0.0 ~ 239.255.255.255 | 管理范围 | [RFC2365] |
到 224.255.255.255 的地址块被分配给某些应用协议或组织使用。这些分配工作由 IANA 或 IETF 完成。本地网络控制块限制为发送方的本地网络；发送到这些地址的数据报不会被组播路由器转发。 “所有主机”组（224.0.0.1）是这个块中的一个组。互联网络控制块类似于本地网络控制范围，其目的是控制需要被路由到本地链路的流量。该地址块的一个例子是网络时间协议（NTP）组播组（224.0.1.1） [RFC5905]。
第一个 Ad hoc（特定）块用于保留一些地址，避免它们落人本地或互联网络控制块。在此范围内的大多数分配是用于商业服务，其中一些不（或永远不）需要全球地址分配；它们可能最终被返还以支持 GLOP 寻址（见下一段落）。在 SDP/ SAP 块中包含某些应用所使用的地址，例如会话目录工具（SDR） [H96]，它使用会话通告协议（SAP）发送组播会议通告 [RFC2974]。新的会话描述协议（SDP） [RFC4566]最初只是 SAP 的一个组成部分，当前它不仅用于 IP 组播，而且与其他机制一起描述多媒体会话。
其他主要地址块的出现稍晚于 IP 组播的演变。如前面所述，某些应用使用 SSM 块实现 SSM，结合自已的单播源地址形成一个 SSM 信道。在 GLOP 块中，组播地址基于主机的**自治系统（AS）**号，该主机处于应用分配地址的一端。 AS 号用于 ISP 之间的 Internet 范围的路由协议，以聚合路由器和实现路由策略。 AS 号最初是 16 位，但现在已扩展到 32 位 [RFC4893]。GLOP 地址的生成是将一个 16 位 AS 号放在 IPv4 组播地址的第 2 和第 3 字节，并且保留 1 字节的空间表示可能的组播地址（即多达 256 个地址）。因此，它可在一个 16 位 AS 号和与这个 AS 号相关联的 GLOP 组播地址之间来回映射。这个计算过程很简单，目前已开发出几个在线计算器。
最近， IPv4 组播地址分配机制将多个组播地址与一个 IPv4 单播地址前缀关联。这被称为基于单播前缀的组播寻址（UBM），它在 [RFC6034] 中描述。它基于 IPv6 发展早期的一个类似结构，我们在前面 2.5.4 节讨论过。 UBM 的 IPv4 地址范围是 234.0.0.0 至 234.255.255.255。单播地址需分配一个 /24 或更短的前缀以使用 UBM 地址。分配更短的地
址（即 /25 或更长的前缀）必须使用一些其他机制。 UBM 地址被构造成前缀 234/8、分配的
单播前缀和组播组 ID 的串联。图 2-11 显示了这个格式。
为了确定与一个单播分配相关的 UBM 地址，分配前缀只是简单地在前面添加前缀 234/8。例如，单播 IPv4 地址前缀 192.0.2.0/24 有一个关联的 UBM 地址 234.192.0.2。 通过对组播地址简单地“左平移” 8 位，有可能确定一个组播地址的所有者。例如，我们知道组播地址范围 234.128.32.0/24 被分配给加州大学伯克利分校，这是由于相应的单播 IPv4 地址空间 128.32.0.0/16 （234.128.32.0 的“左移”版本）是由加州大学伯克利分校所拥有(可以使用 WHOIS 查询来确定，见 2.6.1.1 节)。
图 2-11 IPv4 的 UBM 地址格式。为单播地址分配 /24 或更短的前缀，关联的组播地址分配基于前缀 234/8、分配的单播前缀和组播组 ID 的串联。因此，较短的单播前缀分配包含更多单播和组
播地址
UBM 地址比其他类型的组播地址分配有更多优点。例如，用于 GLOP 寻址时，它们可以不受 16 位 AS 号限制。另外，它们可作为已存在的单播地址空间的分配结果。因此，使用组播地址的站点知道哪些地址可用，并且不需要进一步协调。最后， UBM 地址可以比 GLOP 地址更好地分配，对应的 AS 号可分配到更细粒度。在今天的 Internet 中，一个 AS 号可以与多个站点关联，但令人沮丧的是 UBM 支持在地址和所有者之间的简单映射。
管理范围的地址块可用于限制分布在路由器和主机的特定集合中的组播流量。它可以看作组播对专用单播 IP 地址的模拟。这种地址不能用于将组播分发到 Internet，这是因为其中大多数流量被阻塞在企业边界。大型站点有时会划分管理范围的组播地址，以用于某些特定范围（例如，工作组、部门和地理区域）。
2.5.4 IPv6 组播地址
对于 IPv6，对组播的使用相当积极，前缀 ff00::/8 已被预留给组播地址，并且 112 位可用于保存组号，可提供的组数为 2112= 5 192 296 858 534 827 628 530 496 329 220 096。其一般格式如图 2-12 所示。
图 2-12 基本的 IPv6 组播地址格式包括 4 个标志位（0，保留； R，包含会合点； P，使用单播前缀； T，是临时的）。 4 位范围值表示组播的范围（全球、本地等）。组 ID 编码在低序的 112 位中。如果 P 或 R 位被设置，则使用一种代替格式
IPv6 组播地址的第 2 字节包含一个 4 位标志字段和一个 4 位范围 ID 字段。范围字段表示到某些组播地址的数据报的分配限制。十六进制值 0、3 和 f 保留。十六进制值 6、 7 和 9 ~ d未分配。表 2-10 给出了这些值（根据 [RFC4291] 中的2.7节）。
| 值 | 范围 |
|---|---|
| 0 | 保留 |
| 1 | 接口/机器本地 |
| 2 | 链路/子网本地 |
| 3 | 保留 |
| 4 | 管理 |
| 5 | 站点本地 |
| 6 ~ 7 | 未分配 |
| 8 | 组织本地 |
| 9 ~ d | 未分配 |
| e | 全球 |
| f | 保留 |
很多 IPv6 组播地址由 IANA 分配为永久使用，并且故意跨越多个地址范围。这些组播地址对每个范围都有一定偏移量（由于这个原因，这些地址被称为相对范围或可变范围）。例如，可变范围的组播地址：ff0x::101 是由 [IP6MA] 为 NTP 服务器预留。 x 表示可变范围，表 2-11 显示了一些预留定义的地址。
| 地址 | 含义 |
|---|---|
| ff01::101 | 同一机器中的所有 NTP 服务器 |
| ff02::101 | 同一链路/子网中的所有 NTP 服务器 |
| ff04::101 | 某些管理定义范围内的所有 NTP 服务器 |
| ff05:101 | 同一站点中的所有 NTP 服务器 |
| ff08::101 | 同一组织中的所有 NTP 服务器 |
| ff0e::101 | Internet 中的所有 NTP 服务器 |
在 IPv6 中，当 P 和 R 位字段设置为 0 时，使用图 2-12 中给出的组播地址格式。当 P 设置为 1，无须基于每个组的全球性许可，对组播地址有两个可选方法。它们被描述在 [RFC3306] 和 [RFC4489] 中。第一种方法称为基于单播前缀的 IPv6 组播地址分配，由 ISP 或地址分配机构提供单播前缀分配，并且有效分配一个组播地址集合，从而限制了因避免重复而需全球协调的数量。第二种方法称为链路范围的 IPv6 组播，使用接口标识符，并且组播地址是基于主机的 IID。为了了解这些不同格式如何工作，首先要了解 IPv6 组播地址中位字段的使用细节。它们被定义在表 2-12 中。
| 位字段（标志） | 含义 | 参考文献 |
|---|---|---|
| R | 会合点标志（0，常规的；1，包括 RP 地址） | [RFC3956] |
| P | 前缀标志（0，常规的；1，基于单播前缀的地址） | [RFC3306] |
| T | 临时标志（0，永久分配的；1，临时的） | [RFC4291] |
当 T 位字段被设置时，表示组地址是临时或动态分配的；它不是 [IP6MA] 中定义的标准地址。当 P 位字段被设置为 1， T 位也必须被设置为 1 。 当这种情况发生时，使用基于单播地址前缀的特殊格式的 IPv6 组播地址，如图 2-13 所示。
图 2-13 IPv6 组 播地址可以基于单播 IPv6 地址来创建 [RFC3306]。在这样做时， P 位字段设置为 1，单播前缀和 32 位的组 ID 被加入地址。这种形式的组播地址分配简少了全球地址分配协议的需求
这里，我们可以看到如何使用基于单播前缀的地址改变组播地址格式，包括一个单播前缀及其长度，以及一个更小的（32 位）组 ID。该方案的目的是提供全球唯一的 IPv6 组播地址分配方式，同时不需要提出新的全球性机制。由于 IPv6 单播地址已分配全球性的前缀单元（见 2.6 节），所以在组播地址中可以使用这个前缀中的位，从而在组播应用中利用现有的单播地址分配方法。例如，一个组织分配了一个单播前缀 3ffe:ffff:1::/48，那么它随之分配了一个基于单播的组播前缀 ff3x:30:3ffe:ffff:1::/96，其中 x 是任何有效范围。 SSM 通过设置前缀长度和将前缀字段设置为 0 来支持这种格式，以便有效地将前缀 ffx::/32 （其中 x 是任何有效的范围值）用于所有这类 IPv6 SSM 组播地址。
为了创建唯一的链路本地范围的组播地址，可使用一种基于 IID 的方法 [RFC4489]，当只需要链路本地范围时，这种方法是基于单播前缀分配的首选。在这种情况下，可使用另一种形式的 IPv6 组播地址结构（见图 2-14 ）。
图 2-14 IPv6 链路范围的组播地址格式。只适用于链路（或更小）范围内的地址，组播地址可以结合 IPv6 接口 ID 和组 ID 来形成。这种映射是直接的，所有地址使用前缀形式 ff3:0011/32，其中 x 是范围 ID 并且小于 3
图 2-14 所示的地址格式与图 2-13 的格式相似，除了前缀长度字段被设置为 255，并将随后字段中的前缀替换为 IPv6 的 IID。这个结构的优点是不需要提供前缀以形成组播地址。在不需要路由器的 Ad hoc（无线自组织）网络中，一台单独的计算机可基于自已的 IID 形成唯一的组播地址，而无须运行一个复杂的许可协议。如前所述，这种格式只适用于本地链路或节点组播范围。但是，当需要更大的范围时，无论是基于单播前缀的地址还是永久组播地址都可使用。作为这种格式的一个例子，一个 IID 02-11-22-33-44-55-66-77 的主机将使用 组播地址 ff3x:0011:0211:2233:4455:6677:gggg:gggg，其中 x 是一个等于或小于 2 的范围值， gggg:gggg 是一个 32 位组播组 ID 的十六进制表示。
我们还要讨论的位字段是 R 位字段。当使用基于单播前缀的地址（P 位被设置）时，它表示组播路由协议需要知道一个会合点。
注意 会合点（RP）是一个路由器中用于处理一个或多个组播组的组播路由的 IP 地址。 RP 用于
PIM-SM协议 [RFC4601]，以帮助参加同一组播组中的发送方和接收方找到对方。 Internet 范围
的组播部署遇到的问题之一是会合点定位。这种方法重载 IPv6 组播地址以包含一个 RP 地址。因
此，从一个组地址找到一个 RP 是简单的，只需从中选择合适的位的子集。
当标志 P 被设置时，图 2-15 显示了组播地址修改后的格式。
图 2-15 所示的格式与图 2-13 类似，但不使用 SSM （这样前缀长度不能为零）。另外，新引入了一个称为 RIID 的 4 位字段。为了形成图 2-15 所示格式的基于 RP 地址的 IPv6 地址，前缀长度字段表示的位数从前缀字段提取，并放置在一个新的 IPv6 地址的高位。然后，RIID 字段值被用作 RP 地址的低 4 位。剩余的部分用零填充。作为一个例子，我们看一个组播地址ff75:940:2001:db8:dead:beef:f00d:face。在这个例子中，范围为 5 （站点本地）， RIID 字段值为 9，前缀长度为 0x40 = 64 位。因此，前缀本身为 2001:db8‥dead:beef， RP 地址为 2001‥db8:dead:beef::9。更多的例子见 [RFC3956]。
图 2-15 RP 的单播 IPv6 地址可以嵌入 IPv6 组播地址 [RFC3956]。56]。这样，它可以直接找到用于路由的 RP 关联的地址。RP 被用于组播路由系统，以协调不在同一子网中的组播发送方和接收方
与 IPv4 相似， IPv6 也有一些保留的组播地址。除了前面提到的可变范围地址，这些地址还根据范围划分成组。表 2-13 给出了一个 IPv6 组播空间中的保留列表。 [IP6MA] 提供了更多的信息。
| 地址 | 范围 | 特殊用途 | 参考文献 |
|---|---|---|---|
| ff01::1 | 节点 | 所有节点 | [RFC4291] |
| ff01::2 | 节点 | 所有路由器 | [RFC4291] |
| ff01::fb | 节点 | mDNSv6 | [IDChes] |
| ff02::1 | 链路 | 所有节点 | [RFC4291] |
| ff02::2 | 链路 | 所有路由器 | [RFC4291] |
| ff02::4 | 链路 | DVMRP 路由器 | [RFC1075] |
| ff02::5 | 链路 | OSPFIGP | [RFC2328] |
| ff02::6 | 链路 | 基于 OSPFIGP 设计的路由器 | [RFC2328] |
| ff02::9 | 链路 | RIPng 路由器 | [RFC2080] |
| ff02::a | 链路 | EIGRP 路由器 | [EIGRP] |
| ff02::d | 链路 | PIM 路由器 | [RFC5059] |
| ff02::16 | 链路 | 支持 MLDv2 的路由器 | [RFC3810] |
| ff02::6a | 链路 | 所有探测器 | [RFC4286] |
| ff02::6d | 链路 | LL-MANET 路由器 | [RFC5498] |
| ff02::fb | 链路 | mDNSv6 | [IDChes] |
| ff02::1:2 | 链路 | 所有 DHCP 代理 | [RFC3315] |
| ff02::1:3 | 链路 | LLMNR | [RFC4795] |
| ff02::1:ffxx:xxxx | 链路 | 请求节点地址范围 | [RFC4291] |
| ff05::2 | 站点 | 所有路由器 | [RFC4291] |
| ff05::fb | 站点 | mDNSv6 | [IDChes] |
| ff05::1:3 | 站点 | 所有 DHCP 服务器 | [RFC3315] |
| ff0x:: | 可变的 | 保留 | [RFC4291] |
| ff0x::fb | 可变的 | mDNSv6 | [IDChes] |
| ff0x::101 | 可变的 | NTP | [RFC5905] |
| ff0x::133 | 可变的 | 聚合服务器访问协议 | [RFC5352] |
| ff0x::18c | 可变的 | 所有 AC 的地址（CAPWAP） | [RFC5415] |
| ff3x::/32 | （特殊的） | SSM 块 | [RFC4607] |
2.5.5 任播地址
任播地址是一个单播 IPv4 或 IPv6 地址，这些地址根据它所在的网络确定不同的主机。这是通过配置路由器通知 Internet 中多个站点有相同单播路由来实现。因此，一个任播地址不是指 Internet 中的一台主机，而是对于任播地址“最合适”或“最接近”的一台主机。任播地址最常用于发现一台提供了常用服务的计算机 [RFC4786]。例如，某个数据报发送到一个任播地址，可用于找到 DNS 服务器（见第 11 章）， 6to4 网关将 IPv6 流量封装在 IPv4 隧道中 [RFC3068]，或用于组播路由的 RP 中 [RFC4610]。
2.6 分配
IP 地址空间通常被分配为大的块，这由一些分层次组织的权威机构完成。权威机构是为各种“所有者”分配地址空间的组织， “所有者”通常是 ISP 或其他较小的权威机构。权威机构经常参与全球单播地址空间分配，但有时也分配其他类型的地址（组播和特殊用途）。权威机构为用户分配一个不限时的地址块，或是一个限时（例如实验）的地址块。这个层次结构的顶部是 IANA [IANA] ，它负责分配 IP 地址和 Internet 协议使用的其他号码。
2.6.1 单播
对于单播 IPv4 和 IPv6 的地址空间， IANA 将分配权限主要委托给几个地区性 Internet 注册机构（RIR）。 RIR 之间通过一个组织互相协作，即 2003 年创建的号码资源组织（NRO）[NRO]。表 2-14 给出了本书写作时（2011 年中期）的一组 RIR，它们都加人了 NRO。截至 2011 年初， IANA 拥有的剩余的 IPv4 单播地址空间将移交给这些 RIR 分配。
| RIR 名称 | 负责的地区 | 参考文献 |
|---|---|---|
| AfriNIC——非洲网络信息中心 | 非洲 | http://www.afrinic.net |
| APNIC——亚洲太平洋地区网络信息中心 | 亚洲/太平洋地区 | http://www.apnic.net |
| ARIN——美洲 Internet 号码注册机构 | 北美洲 | http://www.arin.net |
| LACNIC——拉丁美洲和加勒比地区的 IP 地址注册 | 拉丁美洲和一些加勒比岛屿 | http://lacnic.net/en/index.html |
| RIPE NCC——欧洲网络协调中心 | 欧洲、中东、中亚 | http://www.ripe.net |
这些实体通常处理较大的地址块 [IP4AS] [IP6AS]。他们为一些国家（例如澳大利亚和新加坡）运营的小型注册机构和大型 ISP 分配地址空间。接下来， ISP 为自已和自已的客户提供地址空间。当用户登记 Internet 服务时，他们通常以地址前缀形式使用 ISP 地址空间的一部分（通常很小）。这些地址范围由客户的 ISP 拥有和管理，并被称为供应商聚合（PA）的地址，这是由于它们包含一个或多个前缀，并可与 ISP 的其他前缀实现聚合。这种地址有时也称为不可移植的地址。交换供应商通常需要客户自已修改连接到 Internet 的所有主机和路由器的IP前缀（这种不愉快的操作通常称为重新编号）。
一种可选的地址空间类型称为供应商独立（PI）的地址空间。从 PI 空间分配的地址可以直接分配给用户，并且可以由任何 ISP 来使用。但是，由于这些地址是客户拥有的，它们没有与 ISP 的地址在数字上相邻，因此它们不能聚合。一个 ISP 需要为客户的 PL 地址提供路由，客户可能需要为路由服务支付额外费用，或根本不支持这种服务。在某种意义上，一个 ISP 同意为客户的 PI 地址提供路由，相对于其他客户有一个额外成本，它会增加自已的路由表大小。另一方面，很多站点喜欢使用 PI 地址，他们可能愿意支付额外费用，因为有助于转换 ISP 时避免重新编号（这被称为供应商锁）。
2.6.1.1 例子
这时，可能需要使用 Internet 中的WHOIS服务，以确定如何分配地址空间。例如，我们可通过访问相应的URL http://whois.arin.net/rest/ip/72.1.140.203.txt ，形成一个对 IPv4 地址 72.1.140.203 的信息查询：
Net Range: 72.1.140.192 - 72.1.140.223
CIDR: 72.1.140.192/27
OriginAS:
NetName: SPEK-SEA5-PART-1
NetHandle: NET-71-1-140-192-1
Parent: NET-72-1-128-0-1
NetType: Reassigned
RegDate: 2005-06-29
Updated: 2005-06-29
Ref: http://whois.arin.net/rest/net/NET-71-1-140-192-1
这里，我们看到地址 72.140.203 实际上是网络 SPEK-SEA5-PART-1 的一部分，并且已分配地址范围 72.1.140.192/27。另外，我们可以看到， SPEK-SEA5-PART-1 的地址范围是 NET-72-1-128-0-1 的 PA 地址空间的一部分。我们可生成一个关于该网络的信息查询，需要访问 URL http://whois.arin.net/rest/net/NET-71-1-128-0-1.txt 。
Net Range: 72.1.128.0 - 72.1.191.255
CIDR: 72.1.128.0/18
OriginAS:
NetName: SPEAKEASY-6
NetHandle: NET-71-1-128-0-1
Parent: NET-72-0-0-0-0
NetType: Direct Allocation
RegDate: 2004-09-09
Updated: 2009-05-19
Ref: http://whois.arin.net/rest/net/NET-71-1-128-0-1
这个记录指出地址范围 72.1.128.0/18（称为“句柄”或名称 NET-72-1-128-0-1）已被直接分配，它在 ARIN 管理的地址范围 72.0.0.0/8 之外。有关 ARIN 支持的数据格式和多种方法的更多细节，可以通过 WHOIS 查询在 [WRWS] 中看到。
通过其他 Internet 注册机构，我们可以看到不同的结果。例如，如果使用 Web 查询接口 http://www.ripe.net/whois 搜索有关 IPv4 地址 193.5.93.80 的信息，我们将获得下面的结果：
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
%
% Note: This output has been filtered.
% To receive output for a database update， use the "-B" flag.
% Information related to '193.5.88.0 - 193.5.95.255'
inetnum: 193.5.88.0 - 193.5.95.255
netname: WIPONET
descr: World Intellectual Property Organization
descr: UN Specialized Agency
descr: Geneva
country: CH
org: ORG-WWIP1-RIPE
admin-c: AM4504-RIPE
tech-c: AM4504-RIPE
mnt-by: RIPE-NCC-END-MNT
status: ASSIGNED PI
mnt-by: ICC-NETMGR-MNT
mnt-by: CH-UNISOURCE-MNT
mnt-by: DE-COLT-MNT
created: 2002-08-16T08:00:36Z
last-modified: 2018-06-22T08:40:13Z
source: RIPE
sponsoring-org: ORG-UNIC3-RIPE
我们可以看到，地址 193.5.93.80 是分配给 WIPO 的地址块 193.5.88.0/21 的一部分。注意，这个块的状态为 ASSIGNED PI，意味着该地址块是供应商独立类型。 RPSL 的参考文献表示数据库记录使用路由策略规范语言 [RFC2622] [RFC4012]， ISP 用它来表示自已的路由策略。这些信息允许网络运营商配置路由器，以帮助缓解 Internet 中的路由不稳定。
2.6.2 组播
在 IPv4 和 IPv6 中，组播地址（即组地址）可根据其范围来描述，它们需要确定组播方式（静态、动态的协议或算法），以及是否使用 ASM 或 SSM。这些组的分配策略已被制定（ [RFC5771] 针对 IPv4 ； [RFC3307] 针对 IPv6 ），整体架构在 [RFC6308] 中详细描述。全球范围之外的组（例如管理范围的地址和 IPv6 链路范围的组播地址）可在 Internet 的各个部分重复使用，并由网络管理员配置管理范围之外的地址块或由端主机自动选择。静态分配的全球范围地址通常是固定的，并且可能被硬件编码到应用中。这种地址空间是有限的，特别是在 IPv4 中，这种地址实际上计划被用于任何其他 Internet 站点。通过算法确定的全球范围地址可以像 GLOP 基于 AS 号创建，或是根据相关的单播前缀分配。注意， SSM 可使用全球范围的地址（即来自SSM块）、管理范围的地址，或前缀实际为 0 的基于单播前缀的 IPv6 地址。
我们可以看到，大量的协议和复杂的组播地址格式，导致组播地址管理成为一个难题（更不用说全球组播路由 [RFC5110]）。从用户的角度来看，组播很少使用，可能受到的关注有限。从程序员的角度来看，在应用设计中支持组播可能是有价值的， [RFC3170]提供了一些这方面的设想。当网络管理员需要实现组播时，与服务提供商的交流可能是必要的。另外，一些组播地址分配方案已由厂商开发 [CGEMA] 。
2.7 单播地址分配
一个站点分配了单播 IP 地址范围后 —— 通常是从自己的 ISP 处获得，站点或网络管理员需要决定如何为每个网络接口指定地址，以及如何建立子网结构。如果这个站点只有一个物理网段（例如大多数家庭），这个过程相对简单。对于规模较大的企业，尤其是那些由多个 ISP 提供服务，并且多个物理网段分布在很大地理区域的企业，这个过程可能非常复杂。我们来看在以下情况下如何工作，家庭用户使用一个专用地址和一个 ISP 提供的 IPv4 地址。这是目前常见的场景。接着，我们继续介绍一些更复杂的情况。
2.7.1 单个供应商/无网络/单个地址
目前，我们可获得的最简单的 Internet 服务是由 ISP 提供一个在一台计算机上使用的 IP 地址（在美国通常只是IPv4）。例如，对于 DSL 服务，单个地址可被分配到一个点到点链路的一端，并可能只是暂时的。例如，如果用户的计算机通过 DSL 连接 Internet，它可能在某天被分配了一个地址63.204.134.177。在计算机上运行的任何程序可以发送和接收 Internet流量，这些流量将采用 63.204.134.177 作为 IPv4 源地址。一台主机同样也有其他活动的 IP 地址。这些地址包括本地的“回送”地址（127.0.0.1）和一些组播地址，至少包括所有主机的组播地址（224.0.0.1）。如果主机正在运行 IPv6，它至少使用所有节点的 IPv6 组播地址（ff02::!）、 ISP 分配的任何 IPv6 地址、 IPv6 回送地址( ::1 )和为每个网络接口配置的一个用于 IPv6 的链接本地地址。
为了在 Linux 上查看一台主机使用的组播地址（组），我们可使用 ifconfig 和 netstat 命令查看正在使用的 IP 地址和组：
Linux% ifconfig ppp0
ppp0 Link encap: Point-to-Point Protocol
inet addr:71.141.244.213
P-t-P:71.141.255.254 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:33134 errors:0 dropped:0 overruns:0 frame:0
TX packets:41031 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:17748984 (16.9 MiB) TX bytes:9272209 (8.8 MiB)
Linux% netstat -gn
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------- ------ ----------------
lo 1 224.0.0.1
ppp0 1 224.0.0.251
ppp0 1 224.0.0.1
lo 1 ff02::1
这里，我们看到设备 ppp0 关联的一条点到点链路，它已分配 IPv4 地址 71.141.244.213 ;但没有分配 IPv6 地址。这台主机系统已启用 IPv6，但当检查它的组成员时，我们看到其本地回送（lo）接口出现在“所有 IPv6 节点”组播组中。我们也可以看到， IPv4 所有节点组正在使用，以及 mDNS （组播DNS）服务 [IDChes] 。 mDNS 协议使用静态 IPv4 组播地址 224.0.0.251。
2.7.2 单个供应商/单个网络/单个地址
很多拥有多台计算机的 Internet 用户发现，只有一台计算机连接到 Internet 并不是理想情况。因此，他们通常拥有家庭局域网（LAN）或无线局域网（WLAN），并使用一台路由器或主机作为路由器连接 Internet。这种配置与单个计算机的情况相似，除了路由器将分组从家庭网络转发到 ISP，它们也执行 NAT （见第 7 章；在 Windows 中称为 Internet 连接共享（ICS）），在与 ISP 通信时重写分组中的 IP 地址。从 ISP 的角度来看，只有一个 IP 地址被使用。目前，这些操作大部分是自动的，因此需要手动配置的地址很少。路由器使用 DHCP 为家庭用户提供自动地址分配。如果有必要，它们也为与 ISP 建立链路提供地址分配。第 6 章详细介绍 DHCP 操作和主机配置。
2.7.3 单个供应商/多个网络/多个地址
很多组织发现仅分配一个单播地址，特别是当它只是暂时分配时，通常无法满足自己的上网需求。对于运行 Internet服务器（例如 Web 站点）的组织，通常希望拥有一个固定的 IP 地址。这些站点经常有多个局域网，其中有些是内部的（通过防火墙和 NAT 设备与 Internet 分离），有些可能是外部网（为 Internet 提供服务）。对于这样的网络，通常需要有一个站点或网络管理员，以确定站点需要多少个 IP 地址，如何构建网站的子网，以及哪些子网是内部或外部网。图 2-16 显示了典型的中小规模企业方案。
图 2-16 一个典型的小型到中型规模的企业网络。该网站已被分配 128.32.2.64/26 范围内的 64 个公开（可路由）的 IPv4 地址。 “DMZ”网络包含 Internet 中可见的服务器。内部路由器使用 NAT 为企业内部的计算机提供 Internet 访问
在该图中，一个站点已分配前缀 128.32.2.64/26，提供最多 64 （减 2）个可路由的 IPv4 地址。 “DMZ”网络（“非军事区”网络，在主防火墙之外，见第 7 章）用来连接服务器，以便 Internet 中的用户可以访问它们。这种计算机通常提供 Web 访问、登录服务器和其他服务。这些服务器的 IP 地址来自前缀范围的一小部分；很多站点只拥有少数的公共服务器。站点前缀中的保留地址交给 NAT 路由器，将它们作为一个“NAT 池”（见第 7 章）的基础。 NAT 路由器可以使用池中的任何地址重写进入或离开内部网络的数据报。图 2-16 显示的网络设置很方便，这里主要有两个原因。
首先，将内部网络与 DMZ 分隔开，有助于保护内部的计算机免受破坏，并由 DMZ 服务器来面对攻击。另外，它会设置区域内的 IP 地址。在边界路由器、 DMZ 和内部 NAT 路由器建立后，可在内部使用任何地址结构，其中可以使用很多（专用的） IP 地址。当然，这个例子只是建立小型的企业网络的一种方式，其他因素（例如成本）可能最终决定路由器、网络和 IP 地址在小型或中型规模的企业中的部署方式。
2.7.4 多个供应商/多个网络/多个地址（多宿主）
对于一些依赖 Internet 接人来保证持续运营的组织，他们通常使用一个以上的供应商（称为多宿主），以便在失效时或其他情况下提供冗余连接。由于 CIDR，只有一个 ISP 的组织通常拥有与该 ISP 相关联的 PA 地址。如果他们又使用一个 ISP，这样会出现每个主机使用哪个 IP 地址的问题。目前，已有针对多个 ISP 同时运行的方法，以及在 ISP 之间转换的指导原则（其中提出了一些类似问题）。对于 IPv4， [RFC4116]讨论了 PI 或 PA 地址如何用于多宿主。我们看图 2-17 所示的情况。
图 2-17 供应商聚合和供应商独立的 IPv4 地址用于一个假设的多宿主企业。如果 PI 地址是可用的，站点运营者倾向于选择使用 PI 空间。 ISP更喜欢 PA 空间，因为它可促进前缀聚合，减少路
由表的大小
这里，一个虚拟的站点 S 有两个 ISP，即 P1 和 P2。如果它使用来自 P1 块（12.46.129.0/25）的 PA 地址空间，将在 C 和 D 点把该前缀分别通知 P1 和 P2。 这个前缀可被 P1 聚合到自已的 12/8 块，并在 A 点将它通知 Internet 其他部分，但 P2 不能在 B 点聚合该前缀，因为它与自已的前缀（137.164/16）在数值上不相邻。另外，从Internet 其他部分的一些主机的角度来看， 12.46.129.0/25 的流量趋向于 ISP P2 而不是 ISP P1，因为站点 S 的前缀比它通过 P1 时更长（“更具体”）。这是 Internet 路由（详情见第 5 章）采用最长匹配前缀算法工作方式的结果。本质上，一台 Internet 其他部分的主机经过 A 点匹配的前缀 12.0.0.0/8 或 B 点匹配的前缀 12.46.129.0/25 都可到达 12.46.129.1。 由于每个前缀都匹配（即目的地址 12.46.129.1 中包含一组共同的前缀位），则具有更大或更长的那个前缀是首选，在这种情况下是 P2。因此， P2 位于无法聚合来自 S 的前缀的位置，并需要携带更多站点 S 的流量。
如果站点 S 决定使用 PI 空间而不是 PA 空间，这个情况更对称。但是，不聚合是可能的。在这种情况下，它在 C 和 D 点将 PI 前缀 198.134.135.0/24 分别通知 PI 和 P2，但任何 ISP 都不能聚合它，因为它与 ISP 地址块中任何一个数值都不相邻。因此，每个 ISP 在 A 点和 B 点通知可识别的前缀 198.134.135.0/24。在这种方式下，在 Internet 路由中执行“自然的”最短路径计算，站点 S 可通过更靠近发送主机的 ISP 到达。另外，如果站点 S 决定切换另一个 ISP，它不需要改变其分配的地址。不幸的是，无法聚合这种地址可能关系到 Internet 未来的扩展性，因此 PI 空间相对供不应求。
IPv6 多宿主已成为 IETF 近年来的研究课题，并出现了 Multi6 体系结构 [RFC4177] 和 Shim6 协议 [RFC5533] 。 Multi6 概括了一些已提出处理意见的方法。从广义上来说，上述选择包括使用一种相当于前面提到的 IPv4 多宿主的路由方式、使用移动 IPv6 的能力
[RFC6275]，以及采用一种将节点标识符与定位符分离的新方法。当前， IP 地址作为连接 Internet 的一个网络接口标识符（本质上是一种名称）和定位符（一种路由系统理解的地址）。
这种分离使得将来即使在底层 IP 地址改变的情况下网络协议也能够实现。提供这种分离的协议有时称为标识符/定位符分离或 id/loc 分离协议。
Shim6 介绍了一个网络层协议“隔离层”（shim），传输层协议使用它分离来自 IP 地址的“上层协议标识符” 。多宿主通过选择使用的 IP 地址（定位符）来实现，基于动态网络环境且不需要 PI 地址分配。通信主机（端点）之间对使用的定位符及交换的时机进行协商。标识符与定位符分离是其他几项工作的主题，包括实验性的主机标识协议（HIP） [RFC4423]，它使用加密的主机标识符来标识主机。这种标识符实际上是与主机相关的公共/私人密钥对中的公钥，因此来源于一个特定主机的 HIP 流量可被认证。第 18 章将详细讨论安全问题。
2.8 与 IP 地址相关的攻击
IP 地址基本上都是数字，只有少数网络攻击涉及它们。一般情况下，执行攻击可发送“欺骗”数据包（见第 5 章）或其他相关活动。也就是说， IP 地址现在有助于查明涉嫌不良活动的个体（例如，对等网络中的版权侵权或非法材料分发）。这样做可能被以下几个原因所误导。例如，在很多情况下，IP 地址只是暂时的，并在不同时间重新分配给不同用户。因此，在精确计时中出现任何错误，容易造成数据库中的 IP 地址到用户的映射出错。另外，访问控制没有被广泛和安全地部署；用户可能通过一些公共的接入点，或一些无意中开放的家庭或办公室的无线路由器连接 Internet。在这种情况下，不知情的家庭或企业所有者可能因 IP 地址而成为嫌疑人，即使这个人并不是网络流量的发送者。这种情况也可能因受攻击的主机被用于组成僵尸网络而发生。目前，这类计算机（和路由器）可通过基于 Internet 的黑市来租赁，并被用于执行攻击、非法内容服务和其他违法活动 [RFC4948] 。
2.9 总结
IP 地址用于识别和定位整个 Internet 系统（单播地址）中设备的网络接口。它也用于识别多个接口（组播、广播或任播地址）。每个接口有一个最少 32 位的 IPv4 地址，并且通常有几个 128 位的 IPv6 地址。单播地址由一些分层次组织的管理机构分配成块。由这些机构分配的前缀表示一个单播 IP 地址空间块，这些块通常分配给 ISP，并由它们为自已的用户分配地址。这种前缀通常是 ISP 地址块的子区间（称为供应商聚合的地址或 PA 地址），但也可能代之为用户拥有的地址（称为供应商独立的地址或 PI 地址）。数值相邻的地址前缀（PA 地址）可被聚合，以节省路由表空间和提高 Internet 扩展性。这种方法出现于由 A、 B、 C 类网络号组成的“有类别” Internet 网络结构被无类别域间路由（CIDR）所取代时。 CIDR 允许根据对地址空间的不同需求，将不同大小的地址块分配给某个组织， CIDR 实际上可以更有效地分配地址空间。任播地址是根据发送者位置指向不同主机的单播地址；这种地址常用于发现可能出现在不同位置的网络服务。
IPv6 单播地址与 IPv4 地址有所不同。最重要的是， IPv6 地址有一个范围的概念，无论是单播地址还是组播地址，都需要明确指出地址的有效范围。典型的范围包括节点本地、链路本地和全球范围。链路本地地址通常基于一个标准前缀和一个 IID 创建，这个 IID 可由低层协议（例如硬件 / MAC 地址）基于地址提供或取随机值。这种方法有助于自动配置 IPv6 地址。
IPv4 和 IPv6 都支持同时指向多个网络接口的地址格式。 IPv4 支持广播地址和组播地址，但 IPv6 只支持组播地址。广播允许一人对所有人通信，而组播允许一人对多人通信。发送方向组播组（IP 地址）的发送，其行为有点像电视频道；发送方并不知道接收方信息或一个信道中有多少个接收方。 Internet 中的全球性组播已发展了十多年，并且涉及很多协议，有些是针对路由，有些是针对地址分配和协调，有些是针对主机希望加入或离开一个组的信息。无论是 IPv4 还是 IPv6，特别是 IPv6，都有很多类型和用途的组播地址。 IPv6 组播地址格式变化提供了基于单播前缀分配组的方法，在组中嵌入路由信息（RP地址），并且能基于 IID 创建组播地址。
可以说 CIDR 的开发和部署是 Internet 核心路由系统的一个根本性变化。 CIDR 成功地为分配地址空间提供更多灵活性，并通过聚合提升路由的可扩展性。另外， IPv6 在 20 世纪 90 年代初开始受到更多重视，这是出于很快将会需要更多地址的想法。当时没有预见的是，NAT （见第7章）的广泛使用显著推迟了 IPv6 的使用，这是因为连接 Internet 的每台主机不再需要唯一的地址。相反，大型网络使用专用地址空间已司空见惯。但是，可用于路由的 IP 地址数量最终将减少到零，因此未来将会出现一些变化。 2011 年 2 月， IANA 分配了最后 5 个 /8 的 IPv4 地址前缀， 5 个 RIR 备分配 1 个前缀。2011 年 04 月 15 日， APNIC 用尽了其所有可分配的前缀。剩余前缀由不同 RIR 持有，预计最多只能几年保持未分配状态。 [IP4R] 是一个关于当前 IPv4 地址利用率的统计。
2.10 参考文献
[CGEMA] Cisco Systems, "Guidelines for Enterprise IP Multicast Address Allocation," 2004, http://www.cisco.com/warp/public/cc/techno/tity/prodlit/ipmlt_wp.pdf
[EIGRP] B.Albrightson, J.J.Garcia-Luna-Aceves, and J.Boyle, "EIGRP -- A Fast Routing Protocol Based on Distance Vectors," Proc. Infocom, 2004.
[EUI64] Institute for Electrical and Electronics Engineers, "Guidelines for 64-Bit Global Identifier (EU1-64) Registration Authority" Mar. 1997 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
[H96] M.Handley "The SDR Session Directory: An Mbone Conference Scheduling and Booking System," Department of Computer Science, University College London, Apr. 1996, http://cobweb.ecn.purdue.edu/~ace/mbone/mbone/sdr/intro.html
[IANA] Internet Assigned Numbers Authority, http://www.iana.org
[IDChes] S.Cheshire and M.Krochmal, "Multicast DNS," Internet draft-cheshire-dnsext-multicastdns, Work in progress, Oct. 2010
[IDv4v6mc] S.Venaas, X.Li, and C.Bao, "Framework for IPv4/IPv6 Multicast Translation," Internet draft-venaas-behave-v4v6mc-framework, Work in progress, Dec. 2010.
[IEEERA] IEEE Registration Authority, http://standards.ieee.org/regauth
[IMR02] B.Edwards, L.Giuliano, and B.Wright, Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions (Addison-Wesley, 2002).
[IP4AS] http://www.iana.org/assignments/ipv4-address-space
[IP4MA] http://www.iana.org/assignments/multicast-addresses
[IP4R] IPv4 Address Report, http://www.potaroo.net/tools/ipv4
[IP6AS] http://www.iana.org/assignments/ipv6-address-space
[IP6MA] http://www.iana.org/assignments/ipv6-multicast-addresses
[KK77] L.Kleinrock and F.Kamoun, "Hierarchical Routing for Large Networks, Performance Evaluation and optimization," Computer Networks, 1(3), 1977.
[NRO] Number Resource organization, http://www.uro.net
[RFCO919] J.C.Mogul, "Broadcasting Internet Datagrams," Internet RFC O919/BCP OOO5, Oct. 1984.
[RFCO922] J.C.Mogul, "Broadcasting Internet Datagrams in the Presence of Subnets," Internet RFC O922/STD OOO5, Oct. 1984.
[RFCO950] J.C.Mogul and T.Postel, "Internet Standard Subnetting Procedure," Internet RFC O950/STD OOO5, Aug. 1985.
[RFC1O75] D.Waitzman, C.Partridge, and S.E.Deering, "Distance Vector Multicast Routing Protocol," Internet RFC lO75 (experimental), Nov. 1988.
[RFC1112] S.E.Deering, "Host Extensions for IP Multicasting," Internet RFC 1112/STD OOO5, Aug. 1989.
[RFC1122] R.Braden, ed., "Requirements for Internet Hosts-Communication Layers," Internet RFC l122/STD OOO3, Oct. 1989.
[RFC1812] F.Baker, ed., "Requirements for IP Version 4 Routers," Internet RFC 1812/STD OOO4, June 1995.
[RFC1918] Y.Rekhter, B.Moskowitz, D.Karrenberg, G.J.deGroot, and E.Lear, "Address Allocation for Private Internets," Internet RFC 1918/BCP OOO5, Feb. 1996.
[RFC2080] G.Malkin and R.Minnear, "RIPng for IPv6," Internet RFC 2080, Jan. 1997
[RFC2328] J.Moy "OSPF Version 2," Internet RFC 2328/STD OO54, Apr. 1988.
[RFC2365] D. Meyer, "Administratively Scoped IP Multicast," Internet RFC 2365/ BCP OO23, July 1998.
[RFC2544] S.Bradner and J.McQuaid, "Benchmarking Methodology for Network Interconnect Devices," Internet RFC 2544 (informational), Mar. 1999.
[RFC2622] C.Alaettinoglu, C.Villamizar, E.Gerich, D.Kessens, D.Meyer, T.Bates, D.Karrenberg, and M.Terpstra, "Routing Policy Specification Language(RPSL)," Internet RFC 2622, June 1999.
[RFC2644] D.Senie, "Changing the Default for Directed Broadcasts in Routers," Internet RFC 2644/BCP OO34, Aug. 1999.
[RFC2974] M.Handley C.Perkins, and E.Whelan, "Session Announcement Protocol,″ Internet RFC 2974 (experimental), Oct. 2000.
[RFC3056] B.Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds," Internet RFC 3056, Feb. 2001.
[RFC3068] C.Huitema, "An Anycast Prefix for 6to4 Relay Routers," Internet RFC 3068, June 2001.
[RFC3170] B.Quinn and K.Almeroth, "IP Multicast Applications: Challenges and Solutions," Internet RFC 3170 (informational), Sept. 2001.
[RFC3180] D.Meyer and P.Lothberg, "GLOP Addressing in 233/8," Internet RFC 3180/BCP OO53, Sept. 2001.
[RFC3306] B.Haberman and D.Thaler, "Unicast-Prefix-Based IPv6 MulticastAddresses," Internet RFC 3306, Aug. 2002.
[RFC3307] B.Haberman, "Allocation Guidelines for IPv6 Multicast Addresses,″ Internet RFC 3307 Aug. 2002.
[RFC3315] R.Droms, ed., J.Bound, B.Volz, T.Lemon, C.Perkins, and M.Camey "Dynamic Host Configuration Protocol for IPv6 (DHCPv6),″ Internet RFC 3315, Aug. 2002.
[RFC3569] S. Bhattacharyya, ed., "An overview of Source-Specific Multicast (SSM)," Internet RFC 3569 (informational), July 2003.
[RFC3701] R.Fink and R.Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout," Internet RFC 3701 (informational), Mar. 2004.
[RFC3810] R.Vida and L.Costa, eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6,″ Internet RFC 3810, June 2004.
[RFC3849] G.Huston, A.Lord, and P.Smith, "IPv6 Address Prefix Reserved for Documentation," Internet RFC 3849 (informational), July 2004.
[RFC3879] C.Huitema and B.Carpenter, "Deprecating Site Local Addresses,″ Internet RFC 3879 Sept. 2004.
[RFC3927] S.Cheshire, B.Aboba, and E.Guttman, "Dynamic Configuration of IPv4 LinkLocal Addresses," Internet RFC 3927, May 2005.
[RFC3956] P.Savola and B.Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address," Internet RFC 3956, Nov 2004.
[RFC4012] L.Blunk, J.Damas, F.Parent, and A.Robachevsky, "Routing Policy Specification Language Next Generation (RPSLng)," Internet RFC 4012, Mar. 2005.
[RFC4116] J.Abley K.Lindqvist, E.Davies, B.Black, and V.Gill, "IPv4 Multi-homing Practices and Limitations,″ Internet RFC 4116 (informational), July 2005.
[RFC4177] G.Huston, "Architectural Approaches to Multi-homing for IPv6," Internet RFC 4177 (informational), Sept. 2005.
[RFC4193] R.Hinden and B.Haberman, "Unique Local IPv6 Unicast Addresses,″ Oct.2005.
[RFC4286] B.Haberman and J.Martin, "Multicast Router Discovery" Internet RFC 4286, Dec. 2005.
[RFC4291] R.Hinden and S.Deering, "IP Version 6 Addressing Architecture,″ Internet RFC 4291, Feb. 2006.
[RFC4380] C.Huitema, "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),″ Internet RFC 4380, Feb. 2006.
[RFC4423] R.Moskowitz and P.Nikander, "Host Identity Protocol (HIP) Architecture," Internet RFC 4423 (informational), May 2006.
[RFC4489] J.-S.Park, M.-K.Shin, and H.-J.Kim, "A Method for Generating Link-Scoped IPv6 Multicast Addresses," Internet RFC 4489 Apr. 2006.
[RFC4566] M.Handley, V.Jacobson, and C.Perkins, "SDP: Session Description Protocol," Internet RFC 4566, July 2006.
[RFC4601] B.Fenner, M.Handley H.Holbrook, and I.Kouvelas, "Protocol Independent Multicast-Sparse Mode (PIM-SM) : Protocol Specification (Revised),″ Internet RFC 4601, Aug. 2006.
[RFC4607] H.Holbrook and B.Cain, "Source-Specific Multicast for IP″ Internet RFC 4607, Aug. 2006.
[RFC4608] D.Meyer, R.Rockell, and G.Shepherd, "Source-Specific Protocol Independent Multicast in 232/8," Internet RFC 4608/BCP 0120, Aug. 2006.
[RFC4610] D.Farinacci and Y.Cai, "Anycast-RP Using Protocol Independent Multicast (PIM),″ Internet RFC 4610, Aug. 2006.
[RFC4632] V.Fuller and T.Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan," Internet RFC 4632/BCP 0122, Aug. 2006.
[RFC4786] J.Abley and K.Lindqvist, "Operation of Anycast Services,″ Internet RFC 4786/BCP O126, Dec. 2006.
[RFC4795] B.Aboba, D.Thaler, and L.Esibov, "LinkLocal Multicast Name Resolution (LLMNR)," Internet RFC 4795 (informational), Jan. 2007.
[RFC4843] P.Nikander, J.Laganier, and F.Dupont, "An IPv6 Prefix for overlay Routable Cryptographic Hash Identifiers (ORCHID),″ Internet RFC 4843 (experimental), Apr. 2007.
[RFC4893] Q.Vbhra and E.Chen, "BGP Support for Four-Octet AS Number Space,″ Internet RFC 4893, May 2007.
[RFC4948] L.Andersson, E.Davies, and L.Zhang, eds., "Report from the IAB Workshop on Unwanted Traffic March 9-10, 2006," Internet RFC 4948 (informational), Aug. 2007.
[RFC5059] N.Bhaskar, A.Ga11, J.Lingard, and S.Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM),″ Internet RFC 5059 Jan. 2008.
[RFC5110] P.Savola, "Overview of the Internet Multicast Routing Architecture," Internet RFC 5110 (informational), Jan. 2008.
[RFC5156] M.Blanchet, "Special-Use IPv6 Addresses," Internet RFC 5156 (informational), Apr. 2008.
[RFC5214] F.Templin, T.Gleeson, and D.Thaler, "Intra-Site Automatic Turnnel Addressing Protocol (ISATAP),″ Internet RFC 5214 (informational), Mar. 2008.
[RFC5352] R.Stewart, Q.Xie, M.Stillman, and M.Tuexen, "Aggregate Server Access Protocol (ASAP)," Internet RFC 5352 (experimental), Sept. 2008.
[RFC5415] P.Calhoun, M.Montemurro, and D.Stanley, eds., "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Specification,″ Internet RFC 5415, Mar. 2009.
[RFC5498] I.Chakeres, "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols,″ Internet RFC 5498, Mar. 2009.
[RFC5533] E.Nordmark and M.Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6," Internet RFC 5533, June 2009.
[RFC5735] M.Cotton and L.Vegoda, "Special Use IPv4 Addresses,″ Internet RFC 5735/BCP O153, Jan. 2010.
[RFC5736] G.Huston, M.Cotton, and L.Vegoda, "IANA IPv4 Special Purpose Address Registry" Internet RFC 5736 (informational), Jan. 2010.
[RFC5737] J.Arkko, M.Cotton, and L.Vegoda, "IPv4 Address Blocks Reserved for Documentation," Internet RFC 5737 (informational), Jan. 2010.
[RFC5771] M.Cotton, L.Vegoda, and D.Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments," Internet RFC 5771/BCP 0051, Mar. 2010.
[RFC5952] S.Kawamura and M.Kawashima, "A Recommendation for IPv6 Address Text Representation," Internet RFC 5952, Aug, 2010.
[RFC5905] D.Mills, J.Martin, ed., J.Burbank, and W.Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification," Internet RFC 5905, June 2010.
[RFC6034] D.Thaler, "Unicast-Prefix-Based IPv4 Multicast Addresses,″ Internet RFC 6034, Oct. 2010
[RFC6052] C.Bao, C.Huitema, M.Bagnulo, M.Boucadair, and X.Li, "IPv6 Addressing of IPv4/IPv6 Translators,″ Internet RFC 6052, Oct. 2010.
[RFC6217] J.Arkko and M.Townsley "IPv4 Run-Out and IPv4-1Pv6 Co-Existence Scenarios," Internet RFC 6127 (experimental), May 2011.
[RFC6144] F.Baker, X.Li, C.Bao, and K.Yin, "Framework for IPv4/IPv6 Translation,″ Internet RFC 6144 (informational), Apr. 2011.
[RFC6164] M.Kohno, B.Nitzan, R.Bush, Y.Matsuzaki, L.Colitti, and T.Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links," Internet RFC 6164, Apr. 2011.
[RFC6275] C.Perkins, ed., D.Johnson, and J.Arkko, "Mobility Support in IPv6," Internet RFC 3775, July 2011.
[RFC6308] P.Savola, "Overview of the Internet Multicast Addressing Architecture," Internet RFC 6308 (informational), June 2011.
[WRWS] http://www.arin.net/resources/whoisrws