RFC4632：Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan，August 2006
本备忘录的状态
本文档为 Internet 社区指定了 Internet 最佳当前实践，并请求讨论和改进建议。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (2006)。
梗概
本备忘录讨论了现有 32 位 IPv4 地址空间的地址分配策略，以保护地址空间并限制全局路由状态的增长率。本文档废弃了 RFC 1519 中的原始无类别域间路由 (Classless Inter-domain Routing，CIDR) 规范，进行了更改以阐明其引入的概念，并在 12 年多之后更新 Internet 社区关于部署所描述技术的结果。
1、 介绍
本备忘录讨论了现有 32 位 IPv4 地址空间的地址分配策略，以保护地址空间并限制全局路由状态的增长率。本文档废弃了最初的 CIDR 规范 [RFC1519]，进行了更改以阐明其引入的概念，并在 12 年多之后更新 Internet 社区关于部署所描述技术的结果。
2、 历史和问题描述
现在所称的 Internet 始于 1970 年代的一个研究项目，旨在设计和开发一组协议，这些协议可以与许多不同的网络技术一起使用，以提供无缝的端到端设施，用于互连不同的端系统。当确定如何使用 32 位地址空间时，对要连接的组织数量、每个组织的端系统数量以及网络上的端系统总数做出了某些假设。最终结果是建立（参见 [RFC791]）三类网络：A 类（MSB（most significant address，最高有效地址）位为“00”），每个网络有 128 个可能的网络和 16777216 个终端系统（减去为网络/广播地址保留的特殊位值)；B 类（MSB '10'），有 16384 个可能的网络，每个网络有 65536 个端系统（保留值较少）；和 C 类（MSB '110'），以及 2097152 个可能的网络和 254 个终端系统（256 位组合减去保留的全零和全 1 模式）。MSB 为“111”的地址集保留供将来使用；其中的一部分最终被定义 (MSB '1110') 用于 IPv4 多播，并且在撰写本文档时仍有部分保留。
在 80 年代后期，前研究网络的扩展和商业化导致许多新组织连接到快速发展的 Internet，每个新组织都需要根据 A/B/C 类寻址计划进行地址分配。随着对新网络数量（尤其是 B 类空间）的需求呈指数级增长，运营和工程社区的一些成员开始担心 A/B/C系统开始思考如何修改网络号分配策略和路由协议以适应增长。1991 年 11 月，互联网工程任务组 (IETF) 成立了 ROAD（Routing and Addressing，路由和寻址）小组来检查这种情况。该小组于 1992 年 1 月开会并确定了三个主要问题：
1. B 类网络地址空间耗尽。此问题的一个根本原因是缺乏适合中型组织的规模的网络类别。最多有 254 个主机地址的 C 类太小了，而最多允许 65534 个主机地址的 B 类对于大多数组织来说太大了，但最适合用于子网划分。
2. Internet 路由器中路由表的增长超出了当前软件、硬件和人员的有效管理能力。
3. 最终耗尽 32 位 IPv4 地址空间。
很明显，当时的 Internet 增长速度将导致前两个问题在 1993 年和 1995 年之间的某个时间变得至关重要。无连接网络服务 (Connectionless Network Service，CLNS) 寻址拓扑分配的工作已经在进行中，该工作已在1990 年 12 月 Boulder IETF 提出了如何重新构建 32 位 IPv4 地址空间以延长其生命周期的想法。ROAD 小组的工作随之而来，最终导致了 [RFC1338] 和后来的 [RFC1519] 的发布。
CIDR 的设计和部署旨在通过提供一种机制来减缓全局路由表的增长并降低 IPv4 地址空间的消耗率来解决这些问题。它没有也不会试图解决第三个问题，这是一个更长期的问题；相反，它努力缓解中短期困难，使互联网能够继续有效运行，同时在长期解决方案上取得进展。
有关这项工作和 ROAD 组的更多历史背景可以在 [RFC1380] 和 [LWRD] 中找到。
3、 作为解决方案的无类别寻址
社区创建的解决方案是弃用 A/B/C 类网络地址分配系统，转而使用“无类别”、分层的 IP 地址块（称为前缀）。前缀的分配旨在大致遵循底层 Internet 拓扑，以便聚合可用于促进全球路由系统的扩展。该策略的一个含义是前缀分配和聚合通常根据提供者-订阅者关系完成，因为互联网拓扑就是这样确定的。
当最初在 [RFC1338] 和 [RFC1519] 中提出时，该寻址计划旨在作为一个相对短期的响应，持续大约三到五年，在此期间将设计和实施更持久的寻址和路由架构。从原始文件的日期可以看出，CIDR已经远远超过其预期寿命，成为上述问题的中期解决方案。
请注意，在下面的文本中，我们描述了为实现此处讨论的分配架构而实施的当前政策和程序。此描述不应被解释为对 IANA 的指示。
再加上地区互联网注册管理机构实施的地址管理策略（详见 [NRO]），CIDR 式寻址的部署也降低了 IPv4 地址空间的消耗率，从而提供了中短期的缓解问题#3，如上所述。
请注意，根据定义，该计划既不需要也不需要重新分配遗留“C 类”空间中不适合聚合的那些部分（有时称为“沼泽”）。这样做会在一定程度上减少路由表的大小（目前估计“沼泽”包含大约 15,000 个条目），尽管需要大量的重新编号成本。类似地，在更改中转服务提供商时没有硬性要求任何终端站点重新编号，但鼓励终端站点这样做以消除将其前缀显式通告到全球路由系统中的需要。
3.1、 基本概念和前缀表示法
从最简单的意义上讲，从 A/B/C 类网络号到无类别前缀的变化是明确表示 32 位 IPv4 地址中的哪些位被解释为与站点关联的网络号（或前缀），哪些是用于对站点内的各个终端系统进行编号。在 CIDR 表示法中，前缀显示为 4 个八位字节的数量，就像传统的 IPv4 地址或网络号一样，后跟“/”（斜线）字符，后跟一个 0 到 32 之间的十进制值，用于描述重要位。
例如，传统的“B 类”网络 172.16.0.0，隐含网络掩码 255.255.0.0，被定义为前缀 172.16.0.0/16，“/16”表示提取网络部分的掩码前缀是一个 32 位值，其中最高 16 位是 1，最低 16 位是 0。类似地，传统的“C 类”网络号 192.168.99.0 被定义为前缀 192.168.99.0/24；最高有效的 24 位是 1，最低有效的 8 位是零。
使用具有显式前缀长度的无类别前缀可以根据实际需要更灵活地匹配地址空间块。在以前只有三种网络大小可用的情况下，可以定义前缀来描述 1 到 2^32 个端系统地址之间的两个大小块的任何幂。实际上，未分配的地址池由互联网号码分配机构 ([IANA]) 管理。IANA 根据需要从该池中分配给地区互联网注册管理机构。这些分配是在 2^24 个地址（又名 /8 前缀）的连续位对齐块中进行的。区域互联网注册管理机构 (Regional Internet Registries，RIR) 反过来向本地互联网注册管理机构 (Local Internet Registries，LIR) 或互联网服务提供商 (Internet Service Providers，ISP) 分配或分配较小的地址块。这些实体可能会直接使用分配（对于 ISP 来说通常是这种情况），或者可能会进一步向其客户再分配地址。这些 RIR 地址分配根据每个 ISP 或 LIR 的需要而有所不同。例如，大型 ISP 可能会分配一个包含 2^17 个地址（前缀 /15）的地址块，而较小的 ISP 可能会分配一个包含 2^11 个地址（前缀 /21）的地址块。
请注意，术语“分派/allocate”和“分配/assign”在互联网地址注册系统中具有特定含义；“分派”是指将地址空间块委托给预期执行进一步子委托的组织，“分配”用于直接使用（即，编号单个主机）收到的地址块的站点。
下表提供了所有 CIDR 前缀大小的便捷快捷方式，显示了每个前缀中可能的地址数量以及可以在 32 位 IPv4 地址空间中编号的该大小的前缀数量：
n 是 8 位十进制八位字节值。点对点链接在[RFC3021]中有更详细的讨论。
x 是 1 到 7 位的值，基于前缀长度，移入八位字节的最高有效位并转换为十进制形式；八位字节的最低有效位为零。
在实践中，长度短于 8 的前缀尚未分配或分配，尽管如果或当执行积极聚合时，路由表中可能存在到这种短前缀的路由。在撰写本文时，全球路由系统中还没有看到这样的路由，但操作员错误和其他事件导致其中一些（即 128.0.0.0/1 和 192.0.0.0/2）在某些网络在过去的某些时候。
4、 地址分配和路由聚合
无类别寻址和路由最初的开发主要是为了改进全球 Internet 上路由的缩放特性。由于路由的扩展与地址的使用方式紧密相关，因此 CIDR 的部署会对地址分配的方式产生影响。
4.1、 聚合效率和限制
减少分组交换网络上的路由状态的唯一普遍理解的方法是通过信息聚合。为了让 CIDR 成功地降低全球路由系统的规模和增长率，需要改变 IPv4 地址分配过程，使路由信息沿拓扑线聚合成为可能。由于通常网络的拓扑结构由构建它的服务提供商决定，因此具有拓扑意义的地址分配必然是面向服务提供商的。
对于连接到一个服务提供商的终端站点来说，聚合很简单：它使用由其服务提供商分配的地址空间，并且该地址空间是分配给服务提供商的较大块的一小部分。终端站点不需要明确的路由；服务提供商为更大的块通告单个聚合路由。此通告为块中编号的所有客户提供可达性和可路由性。
有两种更复杂的情况会降低聚合的有效性：
1、一个多宿主的组织。由于多宿主组织必须由其每个服务提供商向系统通告，因此将其路由信息聚合到这些提供商中的任何一个的地址空间中通常是不可行的。请注意，组织仍然可以从服务提供商的地址空间（这具有其他优势）接收其地址分配，但在最一般情况下，其所有服务提供商都会明确通告到组织前缀的路由。因此，多宿主组织的全局路由成本通常与采用 CIDR 之前的相同。可以在 [RFC4116] 中找到对多宿主实践的更详细考虑。
2、更改服务提供商但不重新编号的组织。这具有在原始服务提供商的聚合路由通告之一中“打洞”的效果。CIDR 通过要求较新的服务提供商为重新归位的组织做通告来处理这种情况；此通告比提供者聚合更受欢迎，因为它是一个更长的匹配。为了保持聚合效率，建议更改服务提供商的组织最终计划将其网络迁移到从其新提供商的地址空间分配的前缀中。为此，建议尽可能部署促进此类迁移的机制，例如使用 [RFC2131]) 的动态主机地址分配，并完成额外的协议工作以开发改进的重新编号技术。
请注意，对于多宿主站点（以及通常由多个逻辑 IPv4 网络组成的任何站点），仍然可以获得一些聚合效率增益；通过向站点分配连续的 2 次幂块地址空间（与多个独立前缀相反），站点的路由信息可以聚合到单个前缀中。此外，由于与从服务提供商的地址空间分配多宿主站点相关的路由成本不大于由中央权威机构分配序列号的旧方法，因此将所有终端站点地址空间分配到服务提供商的地址空间之外是有意义的。分配给服务提供商的块。
还值得一提的是，由于聚合可能发生在系统的多个级别，因此仍有可能在可能存在的任何层次结构的更高级别聚合这些异常路由。例如，如果一个站点多宿主到两个相对较小的提供商，这些提供商都从同一个大型提供商处获得连接和地址空间，那么大型提供商从较小网络中聚合的路由将包括到多宿主站点的所有路由.这种二级聚合的可行性取决于站点、其直接连接的供应商和它们所连接的其他供应商之间是否存在拓扑层次结构；它在全球互联网的某些地区可能是实用的，但在其他地区则不然。
注意：在接下来的讨论和示例中，前缀表示法用于表示路由目的地。这仅用于说明，并不要求路由协议在其更新中使用此表示。
4.2、 地址空间的分布式分配
在 Internet 的早期，IPv4 地址空间分配由中央网络信息中心 (Network Information Center，NIC) 执行。A/B/C 类网络编号的分配顺序基本上是任意的，大致根据请求它们的组织的规模来分配。所有分配都集中记录，并且没有尝试以允许路由聚合的方式分配网络编号。
最初部署 CIDR 时，中央分配机构继续存在，但更改了其程序，将大块“C 类”网络号码分配给每个服务提供商。反过来，每个服务提供商将提供商地址空间的面向位掩码的子集分配给每个客户。只要服务提供商的数量相对较少且相对稳定，这种方法就相当有效，但由于服务提供商的数量快速增长，因此无法很好地扩展。
随着互联网在 1990 年代开始迅速扩张，很明显，单一的、集中的地址分配机构是有问题的。当欧洲互联网站点的地址空间分配以 16777216 个地址（CIDR 后来定义为 /8）的位对齐块委托给 RIPE NCC ([RIPE]) 时，此功能开始分散，有效地使其成为第一个 RIR。从那时起，地址分配作为分层职能正式分配给 IANA、RIR 和服务提供商。消除负责全球互联网地址空间的单一组织的瓶颈，大大提高了新任务的效率和响应时间。
以这种方式分层分配地址意味着具有从给定服务提供商分配的地址的站点，出于路由目的，是该服务提供商的一部分，并将通过其基础设施进行路由。这意味着有关多宿主组织（即连接到多个网络服务提供商的组织）的路由信息仍需要被层次结构中的更高级别知道。
[RFC1518] 中描述了对这些问题的历史观点。其他讨论也可以在 [RFC3221] 中找到。
5、 路由实现注意事项
随着从有类网络号到无类别前缀的变化，无法从 IPv4 地址的初始位模式推断网络掩码。这对路由信息的存储和传播方式有影响。网络掩码或前缀长度必须在路由协议中明确携带。内部路由协议，例如 OSPF [RFC2328]、中间系统到中间系统 (IS-IS) [RFC1195]、RIPv2 [RFC2453] 和 Cisco 增强型内部网关路由协议 (Enhanced Interior Gateway Routing Protocol，EIGRP)，以及 BGP4 外部路由协议 [RFC4271] ，都支持此功能，在 1990 年代作为无类别域间路由部署的一部分进行了开发或修改。
较旧的内部路由协议，例如 RIP [RFC1058]、HELLO 和 Cisco 内部网关路由协议 (Interior Gateway Routing Protocol，IGRP)，以及较旧的外部路由协议，例如外部网关协议 (Exterior Gateway Protocol，EGP) [RFC904]，不支持显式携带前缀长度/mask，因此除了在非常有限的存根配置中之外，不能在 Internet 上有效地使用。尽管它们的使用可能适用于简单的传统终端站点配置，但它们被认为已过时，不应在连接到全球互联网的传输网络中使用。
同样，三层网络设备中的路由和转发表必须组织起来存储前缀和前缀长度或掩码。不能期望根据传统 A/B/C 类网络/子网约定组织其路由/转发信息的设备在连接到全球互联网的网络上正常工作；不推荐使用此类设备。幸运的是，如今很少使用此类设备。
5.1、 路由通告规则
1. Internet 中的转发是按最长匹配进行的。这意味着与路由域相关的多宿主目的地必须始终明确地宣布到该路由域中（即，它们不能被汇总）。如果网络是多宿主的，则其进入网络层次结构中“更高”的路由域的所有路径都必须为“更高”的网络所知）。
2. 为多个更具体的路由生成聚合路由的路由器必须丢弃与聚合路由匹配的数据包，但不会丢弃任何更具体的路由。换句话说，聚合路由的“下一跳”应该是空目的地。当聚合覆盖的某些地址不可访问时，这对于防止转发环路是必要的。
请注意，在故障期间，可能会发生将流量部分路由到从一个服务提供商处获取其地址空间但实际上只能通过另一个服务提供商访问的站点（即，站点已更改服务提供商的情况），因为此类流量将沿聚合路由通告的路径转发。规则#2：将通过导致聚合路由的通告商丢弃此类流量来防止数据包误投，但“traceroute”和其他类似工具的输出将表明该网络中存在问题，而不是网络中存在的问题更长的通告更具体的前缀。这可能会让那些试图诊断连接问题的人感到困惑；有关详细信息，请参阅第 6.2 节中的示例。对这种感知到的“问题”的解决方案超出了本文档的范围；它在于更好地教育用户/运营商社区，而不是路由技术。
还应推广遵循这些规则的实现，以便所有路由目的地都接受任意网络号和掩码。唯一突出的限制是掩码必须保持连续。请注意，到前缀 0.0.0.0/0 的退化路由用作默认路由，并且必须被所有实现接受。此外，为了防止通过域间协议意外通告此路由，仅当路由器明确配置为这样做时，才应将此路由通告到另一个路由域，绝不能作为未配置的“默认”选项。
5.2、 规则如何运作
规则#1：保证所使用的转发算法在路由协议和实现之间是一致的。多宿主网络总是由其路由所通过的每个服务提供商明确地公布，即使它们是一个服务提供商的集合的特定子集（如果不是，则显然必须明确地公布）。看起来好像“主要”服务提供商可以将多宿主站点隐式地作为其聚合的一部分进行通告，但最长匹配转发导致这不起作用。[RFC4116] 提供了更多细节。
规则#2：保证不会因聚合而形成路由环路。考虑一个站点，它的“父”提供商分配了 192.168.64/19，它有 192.168.0.0/16。“父”网络将向“子”网络通告 192.168.0.0/16。如果“子”网络失去与 192.168.65.0/24（这是其聚合的一部分）的内部连接，则从“父”到“子”的、目的地为 192.168.65.1 的流量将跟随“子”公布的路线。然而，当该流量到达“子”时，子*不得*沿着路由 192.168.0.0/16 返回到“父”，因为这会导致转发环路。规则#2 规定，“子”可能不会遵循与其自身聚合路由之一匹配的目的地的不太具体的路由（通常，这是通过为所有聚合前缀安装“丢弃”或“空”路由来实现的）一个网络向另一个网络做通告。请注意，处理“默认”路由 (0.0.0.0/0) 是此规则的一个特例；网络不得遵循默认的目的地，这些目的地是其聚合通告之一的一部分。
5.3、 关于前缀过滤器格式的说明
处理路由公告的系统必须能够根据策略规则验证它们接收到的信息是可接受的。过滤路由通告的实现必须允许过滤器元素中的掩码或前缀长度。因此，以前指定为的过滤器元素
accept 172.16.0.0 accept 172.25.120.0.0 accept 172.31.0.0 deny 10.2.0.0 accept 10.0.0.0
现在看起来像这样：
accept 172.16.0.0/16 accept 172.25.0.0/16 accept 172.31.0.0/16 deny 10.2.0.0/16 accept 10.0.0.0/8
这只是明确了网络号码的 A/B/C 类分类所隐含的网络掩码。增强过滤能力以允许前缀和所有具有相同位模式的更具体前缀的匹配也很有用；幸运的是，该功能已被 Internet 上使用的大多数设备供应商实现。
5.4、 聚合的职责和配置
在正常情况下，已分配或分配了一组前缀的路由域（或“自治系统”）全权负责聚合这些前缀。在通常情况下，AS 将在其一个或多个路由器中安装配置，以根据其内部路由系统已知的更具体的路由生成聚合路由。这些聚合路由由路由域的边界路由器通告到全局路由系统中。与聚合路由重叠的更具体的内部路由不应全局发布。在某些情况下，AS 可能希望将聚合责任委托给另一个 AS（例如，客户可能希望其服务提供商代表其生成聚合路由信息）；在这种情况下，聚合是由第二个 AS 中的路由器根据它从第一个 AS 接收到的路由执行的，并结合描述这些路由应该如何聚合的配置策略信息。
请注意，一个提供者可能会选择在没有明确同意的情况下对从另一个提供者接收的路由执行聚合；这被称为“代理聚合”。这对于减少 AS 必须携带和传播到其客户和邻居的路由状态数量是一个有用的工具。然而，代理聚合也会在流量工程中产生意想不到的后果。考虑如果 AS 2 和 3 都从 AS 1 接收路由，但 AS 2 执行代理聚合而 AS 3 没有，会发生什么情况。从 AS 2 和 AS 3 接收中转路由信息的其他 AS 将看到由 AS 1 发起的路由信息的不一致视图。这可能导致 AS 3 的客户和任何其他接收到的 AS 1 到 AS 3 的流量意外转移来自 AS 3 的中转路由。因为代理聚合会对与聚合路由的源或提供聚合的一方没有关系的 Internet 部分造成意外后果，因此应极其谨慎地使用它。
要组合成聚合的路由的配置是路由策略的一种实现，需要一些手动维护的信息。作为对一组可路由前缀必须维护的信息的补充，聚合配置通常只是定义要聚合的 IPv4 地址块范围的一两行。执行其自己聚合的站点正在为已分配的地址块执行此操作；由于同意委托聚合，代表另一个站点执行聚合的站点知道此信息。假设网络管理员的最佳常见做法是交换彼此接受的前缀列表，聚合信息的配置不会引入显着的额外管理开销。
聚合路由的生成通常是静态指定的，或者是响应于了解聚合路由中包含的前缀的活动动态路由。如果进行了这种动态聚合路由通告，则应注意不要过多地添加或撤消路由（称为“路由摆动”）。一般而言，当聚合的至少一个组件变得可达时添加动态聚合路由通告，并且仅当所有组件变得不可达时才撤回它。正确配置的聚合路由比非聚合路由更稳定，从而提高全局路由稳定性。
实施说明：“D 类”（组播）地址空间的聚合超出了本文档的范围。
5.5、 路由传播和路由协议注意事项
在最初部署 CIDR 之前，通常的做法是通过站点的内部路由协议（通常为 OSPF、IS-IS 或 RIP）传播通过外部路由协议（即 EGP 或 BGP）获知的路由。这样做是为了确保选择一致且正确的出口点，以便将流量发送到通过这些协议获知的目的地。四种演进效应——CIDR 的出现、全球路由状态的爆炸性增长、BGP4 的广泛采用以及传播完整路径信息的要求——结合起来反对这种做法。为确保正确的路径传播并防止 AS 间路由不一致（BGP4 的环路检测/预防机制需要完整的路径传播），传输网络必须使用内部 BGP (iBGP) 来承载从其他提供商处获悉的路由，无论是在其网络内部还是通过其网络。
6、 新地址分配和路由示例
6.1、 地址委托
考虑分配给单个网络提供商“PA”的 524288 (2^19) 个地址块，从 10.24.0.0 开始并以 10.31.255.255 结束。这在大小上相当于一块 2048 个旧的“C 类”网络号码（或 /24s）。到此块的无类别路由将被描述为 10.24.0.0，掩码为 255.248.0.0，前缀为 10.24.0.0/13。
假设该服务提供商按以下顺序连接六个站点（意义重大，因为它展示了服务提供商的地址空间中如何形成临时“漏洞”）：
“C1”，需要少于 2048 个地址（/21 或 8 x /24） “C2”，需要少于 4096 个地址（/20 或 16 x /24） “C3”，需要少于 1024 个地址（/22 或 4 x /24） “C4”，需要少于 1024 个地址（/22 或 4 x /24） “C5”，需要少于 512 个地址（/23 或 2 x /24） “C6”，需要少于 512 个地址（/23 或 2 x /24）
在所有情况下，假设每个站点“需要”的 IPv4 地址数量允许显着增长。服务提供者按如下方式委托其地址空间：
C1：分配 10.24.0 到 10.24.7。该网络块由路由 10.24.0.0/21（掩码 255.255.248.0）描述。 C2：分配 10.24.16 到 10.24.31。该块由路由 10.24.16.0/20（掩码 255.255.240.0）描述。 C3：分配 10.24.8 到 10.24.11。该块由路由 10.24.8.0/22（掩码 255.255.252.0）描述。 C4：分配 10.24.12 到 10.24.15。该块由路由 10.24.12.0/22（掩码 255.255.252.0）描述。 C5：分配 10.24.32 和 10.24.33。该块由路由 10.24.32.0/23（掩码 255.255.254.0）描述。 C6：分配 10.24.34 和 10.24.35。该块由路由 10.24.34.0/23（掩码 255.255.254.0）描述。
- 这六个站点应表示为提供商 IGP 中大小不一的六个前缀。如果出于某种原因，提供商使用不支持无类别路由或可变长度子网的过时 IGP，则必须携带所有 /24 的显式路由。
为了使这个例子更真实，假设 C4 和 C5 是通过其他服务提供商“PB”进行多宿主的。进一步假设存在一个站点“C7”，该站点最初连接到“RB”但已移至“PA”。出于这个原因，它有一个网络号块，分配给（下一个）2048 x /24 的 PB 块。
C7：分配 10.32.0 到 10.32.15。该块由路由 10.32.0.0/20（掩码 255.255.240.0）描述。
对于多宿主站点，假设 C4 通过“RA”通告为主站点，通过“RB”通告为次站点；并且 C5 通过“RB”是主要的，通过“RA”是次要的。此外，假设“RA”和“RB”都连接到同一个转接服务提供商“BB”。
从图形上看，此拓扑如下所示：
6.2、 路由通告
为了遵循规则#1，PA 将需要通告给定的地址块和 C7。由于 C4 是多宿主且主要通过 PA，因此也必须对其进行通告。C5 是多宿主和主要通过 PB。原则上（在上面的例子中），它不需要做通告，因为 PB 的最长匹配将自动选择 PB 作为主要的，而 PA 聚合的通告将用作次要的。在实际操作中，C5 通常会通过两个提供商进行通告。
从“PA”到“BB”的通告将
10.24.12.0/22 主要（通告 C4） 10.32.0.0/20 主要（通告 C7） 10.24.0.0/13 主要（通告 PA 的其余部分）
对于 PB，通告还必须包括 C4 和 C5，以及它的地址块。
从“PB”到“BB”的通告将
10.24.12.0/22 次要（通告 C4） 10.24.32.0/23 主要（通告 C5） 10.32.0.0/13 主要（通告 RB 的其余部分）
为了说明第 5.1 节中提到的问题诊断问题，请考虑如果 PA 失去与 C7（分配到 PB 空间之外的站点）的连接会发生什么。在有状态协议中，PA 将向 BB 宣布 10.32.0.0/20 已变得无法访问。现在，当 BB 从其路由表中清除此信息时，由于 PB 的不太具体的匹配 10.32，任何未来通过它发送到该目的地的流量都将转发到 PB（根据规则 #2 将在那里丢弃）。0.0/13。尽管这不会导致操作问题（C7 在任何情况下都无法访问），但它确实会在“BB”上产生一些额外的流量（并且也可能使尝试使用“traceroute”调试中断的人感到困惑）。缓存这种不可访问状态的机制可能很好，但这超出了本文档的范围。
7、 域名服务注意事项
受迁移到 CIDR 显着影响的 Internet 服务的一个方面是用于地址到名称转换的机制：域系统的 IN-ADDR.ARPA 区域。由于此区域仅在八位字节边界上委派，因此转向使用面向位掩码寻址的地址分配计划导致维护部分 IN-ADDR.ARPA 区域的人员的工作量有所增加。
[RFC2317] 中描述了填充不与八位字节边界对齐的块的地址时填充 IN-ADDR.ARPA 区域的技术的描述。
8、 过渡到长期解决方案
CIDR 旨在为 IPv4 Internet 上的路由状态和地址耗尽问题提供短期解决方案。它不会改变基本的 Internet 路由或寻址架构。预计不会影响任何过渡到更长期解决方案的计划，除非推迟制定此类解决方案的紧迫性。
9、CIDR对全局路由状态的影响分析
当 CIDR 在 1990 年代初首次被提出时，原作者对全球路由状态的增长率进行了一些观察，并提供了关于 CIDR 部署如何有望将指数增长降低到更可持续的速度的预测。自那次部署以来，一项名为“CIDR 报告”[CRPT] 的持续努力试图量化和跟踪该增长率。以下是截至 2005 年 3 月的 CIDR 报告的简要摘要，试图解释自 1988 年开始测量全球路由状态大小以来发生的各种模式和增长率变化。
当检查“活动 BGP 表条目”[CBGP] 的图表时，似乎有几种不同的增长趋势，具有不同的拐点，反映了政策和实践的变化。被认为导致它们的趋势和事件如下：
1. 图表最左侧的指数增长。这代表了前研究网络的早期扩展和商业化时期，从 1980 年代后期到大约 1994 年。这种增长的主要驱动力是传输提供商缺乏聚合能力，以及广泛使用传统的 C 类分配用于终端网站。每次将一个新站点连接到全球 Internet 时，都会生成一个或多个新路由条目。
2. 1993 年末和 1994 年初的指数趋势加速，因为 CIDR“超网”块首先由 NIC 分配，并由服务提供商作为单独的传统 C 类网络进行路由。
3. 1994 年急剧下降，因为供应商的 BGP4 部署允许“超网”块的聚合。请注意，路由表条目数量下降幅度最大的时期通常对应于 IETF CIDR 部署工作组每次会议之后的几周。
4. 从 1994 年中期到 1999 年初，随着基于 CIDR 的地址分配和在整个网络中添加聚合路由，大致呈线性增长。
5. 从 1999 年初到 2001 年再次出现指数增长的新时期，因为“高科技泡沫”推动了互联网的快速扩张，以及多归属和流量工程的更具体路线通告的大量增加。
6. 由于“互联网泡沫破灭”导致许多组织停止运营，以及旨在提高聚合效率的“CIDR 警察”[CPOL] 工作的结合，导致 2001 年增长趋于平缓。
7. 2002 年和 2003 年大致呈线性增长。这很可能代表了“泡沫”之前观察到的“正常”增长率的恢复，以及“CIDR 警察”努力的结束。
8. 从 2004 年开始的最近呈指数增长趋势。最好的解释似乎是全球经济的改善推动了互联网的进一步扩张，以及“CIDR 警察”工作的持续缺失，该工作以前作为一种教育新提供商提高聚合效率的工具。在某些情况下，服务提供商故意取消聚合前缀以试图减轻由冲突路由通告引起的安全问题（参见第 12 节）。虽然这种行为可能会解决此类提供商所看到的短期问题，但它从根本上是不可扩展的，并且对整个社区非常不利。此外，似乎有许多提供商同时通告其分配的前缀及其所有 /24 组件，这可能是由于缺乏关于推荐路由配置的一致当前信息。
10、 结论和建议
1992 年，当 CIDR 首次开发时，互联网的持续增长面临着严重的问题。路由状态复杂性的增长和地址空间消耗的快速增长使得一个或两个问题似乎会在短短几年内阻止 Internet 的持续增长。
CIDR 的部署，结合 BGP4 对承载无类别前缀路由的支持，缓解了短期危机。只有通过设备制造商和供应商社区的共同努力才能实现这一目标。通告前缀收费网络的威胁（以及在某些情况下可能是实际实施）可能为共享地址空间提供了额外的激励，从而增加了向服务提供商通告路由的相关成本。
IPv4 路由系统架构承载基于聚合地址通告和与流量工程、多宿主和本地配置相关联的更具体通告的集合的拓扑信息。截至 2005 年 3 月，路由系统中的基本聚合地址负载大约有 75,000 个条目。
大约 85,000 个附加条目是此基本“根”集合的更具体条目。有理由相信，这些附加条目中有许多是为了解决区域甚至局部范围的问题而存在的，不需要在全球范围内传播。
一个明显的问题是 CIDR 是否可以继续作为一种可行的方法来保持全球路由状态增长和地址空间消耗以可持续的速度。最近的测量表明指数增长已经恢复，但进一步的分析表明，可以通过更积极的努力来教育服务提供商了解有效的聚合策略和适当的设备配置，从而缓解这种趋势。展望未来，显然需要不需要每个站点的全局路由状态的更好的多宿主技术，以及不需要添加更多状态的执行流量负载平衡的方法。如果没有这样的发展，也没有重大的架构变化，聚合是在全球互联网中实现路由规模的唯一工具。
11、 CIDR 文件的状态更新
本备忘录已废止并要求将以下描述 CIDR 使用和部署的 RFC 重新归类为历史：
RFC 1467：Internet 中 CIDR 部署的状态
这份信息性 RFC 描述了 1993 年 CIDR 部署的状态。截至 2005 年，CIDR 已被彻底部署，因此此状态说明仅提供历史数据点。
RFC 1481：IAB 建议用于解决扩展问题的中间策略
这个非常简短的信息 RFC 描述了 IAB 对使用 CIDR 来解决扩展问题的认可。因为 RFC 1481 的目标已经实现，所以现在只有历史价值。
RFC 1482：NSFNET 基于策略的路由数据库中的聚合支持
此信息性 RFC 描述了在 NSFNET 上支持 CIDR 指定的路由聚合的计划。因为 NSFNET 早已不复存在并且 CIDR 已经无处不在，RFC 1482 现在只具有历史意义。
RFC 1517：无类别域间路由 (CIDR) 实施的适用性声明
该标准跟踪 RFC 描述了预期需要 CIDR 的位置以及预期（强烈）推荐的位置。随着 CIDR 在 Internet 上的全面部署，不需要 CIDR 的情况仅具有历史意义。
RFC 1518：具有 CIDR 的 IP 地址分配架构
此标准跟踪 RFC 详细讨论了路由和地址聚合注意事项。本文档的第 3.1 节总结了其中一些问题。由于地址分配政策和程序现在主要由 RIR 负责，因此尝试在标准跟踪 RFC 中记录这些做法是不合适的。此外，[RFC3221] 还从路由系统的角度描述了许多相同的问题。
RFC 1520：在 CIDR 环境中跨提供商边界交换路由信息
此信息性 RFC 描述了过渡场景，其中 CIDR 不完全支持在提供者之间交换路由信息。随着 CIDR 在 Internet 上的全面部署，此类场景不再具有操作相关性。
RFC 1817：CIDR 和有类路由
这个信息性 RFC 描述了 1995 年 CIDR 部署的含义；它指出，以前的分类地址将使用 CIDR 机制分配，并描述了对非 CIDR 感知站点的默认路由的使用。随着 CIDR 在 Internet 上的全面部署，此类场景不再具有操作相关性。
RFC 1878：IPv4 的可变长度子网表
此信息性 RFC 提供了一个表格，其中包含每个子网大小的预先计算的子网掩码和地址计数。将类似的表格合并到本文档中后（参见第 3.1 节），不再需要将其记录在单独的 RFC 中。
RFC 2036：对 Internet 中 A 类地址空间组件使用的观察
此信息 RFC 描述了与从先前有类地址空间分配无类别前缀相关的几个操作问题。随着 CIDR 在 Internet 上的全面部署以及从历史的“A 类”地址空间中进行无类别前缀分配的六年多的经验，该 RFC 现在只有历史价值。
12、 安全考虑
支持无类别前缀的路由协议的引入以及向转发模型的转变，该模型要求更具体（最长匹配）的路由与指向不太具体的前缀的路由重叠时，至少会引入两个安全问题：
1. 流量可以通过为给定目的地通告前缀来劫持，该前缀比通常为该目的地通告的聚合更具体。例如，假设地址为 192.168.17.100 的流行终端系统连接到通告 192.168.16.0/20 的服务提供商。有意拦截该站点流量的恶意网络运营商可能会或至少尝试将 192.168.17.0/24 通告到全球路由系统中。由于此前缀比“正常”前缀更具体，因此流量将从合法终端系统转移到恶意运营商拥有的网络。在 CIDR 出现之前，有可能诱导来自网络某些部分的流量跟随与特定网络号码完全匹配的虚假通告；CIDR 使这个问题变得更糟，因为最长匹配路由通常会导致所有流量更喜欢更具体的路由而不是不太具体的路由。不过，针对基于 CIDR 的攻击的补救措施与针对基于 CIDR 之前的攻击相同：在提供商之间建立信任关系，并在提供商边界加上强大的路由策略过滤器。不幸的是，在高度分散的互联网中，这种过滤器的实现是困难的。作为一种变通方法，许多提供者确实实施了通用过滤器，这些过滤器根据从其他提供者接受的前缀长度来设置上限，这些上限来自于他们分配的块大小的 RIR 指南。请注意，已观察到“垃圾邮件发送者”使用此类攻击临时劫持地址空间，以隐藏他们生成的流量（“垃圾邮件”电子邮件）的来源。
2. 拒绝服务攻击可以通过将大量路由通告到系统中来针对互联网基础设施的许多部分发起。这种攻击旨在通过溢出路由和转发表来导致路由器故障。导致此类故障的非恶意事件的一个很好的例子是臭名昭著的“AS 7007”事件 [7007]，其中运营商的路由器错误配置导致大量无效路由通过全局路由传播系统。同样，这种攻击对于 CIDR 来说并不是什么新鲜事。使用传统的 A/B/C 类路由，最多可以向全局路由系统通告 16843008 个唯一网络号，这个数字足以给 2005 年制造的最现代的路由设备造成问题。有什么不同是在存在 CIDR 的情况下正确配置路由器的中等复杂性往往会使此类意外“攻击”更有可能发生。防止此类攻击的措施与上述劫持的措施大致相同，此外，最佳常见做法也是配置边界路由器将从其邻居接受的合理的最大前缀数。
请注意，这并不是对 CIDR 使攻击变得更容易的类型的详尽分析；对全球路由系统中安全漏洞的更全面分析超出了本文档的范围。
13、 致谢
作者希望对 RFC 1519 的其他原作者（Kannan Varadhan、Jessica Yu）表示感谢；到 ROAD 小组，CIDR 背后的许多想法都是与他们一起启发和发展的；并向此重制版文档的早期审阅者（Barry Greene、Danny McPherson、Dave Meyer、Eliot Lear、Bill Norton、Ted Seely、Philip Smith、Pekka Savola）致谢，他们的评论、更正和建议非常宝贵。我们要特别感谢 Geoff Huston 的贡献远远超出职责范围。
14、 参考文献
14.1、 规范参考
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
14.2、 参考资料
[7007] "NANOG mailing list discussion of the "AS 7007" incident", <http://www.merit.edu/mail.archives/nanog/1997-04/msg00340.html>. [CBGP] "Graph: Active BGP Table Entries, 1988 to Present", <http://bgp.potaroo.net/as4637/>. [CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", <http://www.nanog.org/mtg-0302/cidr.html>. [CRPT] "The CIDR Report", <http://www.cidr-report.org/>. [IANA] "Internet Assigned Numbers Authority", <http://www.iana.org>. [LWRD] "The Long and Winding Road", <http://rms46.vlsm.org/1/42.html>. [NRO] "Number Resource Organization", <http://www.nro.net>. [RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1 1984. [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, June 1992. [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992. [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000. [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
完整的版权声明
版权所有 (C) 互联网协会 (2006)。
本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性保证。
知识产权
对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不代表它已作出任何独立努力来确定任何此类权利。可以在 BCP 78 和 BCP 79 中找到有关 RFC 文档中权利的程序的信息。
可以获得向 IETF 秘书处披露的知识产权副本和任何可用许可的保证，或者可以获得本规范的实施者或用户使用此类专有权利的一般许可或许可的尝试结果来自 IETF 在线知识产权资源库 http://www.ietf.org/ipr。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准可能需要的技术的其他专有权利。请将信息发送至 IETF ietf-ipr@ietf.org。
致谢
RFC 编辑器功能的资金由 IETF 管理支持活动 (IASA) 提供。
