暂时未有相关云产品技术能力~
-
发表了文章 2023-03-05
基于TCP的DNS传输：实施要求
RFC7766：DNS Transport over TCP - Implementation Requirements，March 2016梗概本文档规定了支持 TCP 作为 DNS 实现的传输协议的要求，并提供了与 DNS-over-UDP 性能相当的 DNS-over-TCP 性能指南。本文档废弃了 RFC 5966，因此更新了 RFC 1035 和 RFC 1123。本备忘录的状态这是一份 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7766。版权声明版权所有 (c) 2016 IETF Trust 和文件作者。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。1、 简介大多数 DNS [RFC1034] 事务通过 UDP [RFC768] 进行。TCP [RFC793] 始终用于全区域传输（使用 AXFR），并且通常用于大小超过 DNS 协议原始 512 字节限制的消息。DNS 安全 (DNSSEC) 和 IPv6 的不断部署增加了响应大小，因此也增加了 TCP 的使用。增加 TCP 使用的需求也受到它提供的防止地址欺骗的保护以及因此在反射/放大攻击中利用 DNS 的驱动。它现在广泛用于响应率限制 [RRL1] [RRL2]。此外，最近关于 [DNS-over-TLS] 等 DNS 隐私解决方案的工作是重新审视 DNS-over-TCP 要求的另一个动机。[RFC1123] 的第 6.1.3.2 节规定：“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”然而，一些实现者认为上面引用的文本意味着 TCP 支持是 DNS 协议的一个可选特性。大多数 DNS 服务器运营商已经支持 TCP，并且大多数软件实现的默认配置是支持 TCP。本文档的主要受众是那些对 TCP 的有限支持限制互操作性并阻碍新 DNS 功能部署的实施者。因此，本文档更新了核心 DNS 协议规范，以便对 TCP 的支持从此成为完整 DNS 协议实现的必需部分。增加 TCP 的使用（见附录 A）有几个优点和缺点，以及需要考虑的实施细节。本文档解决了这些问题，并将 TCP 作为 DNS 的有效传输替代方案。它扩展了 [RFC5966] 的内容，并从 DNS 和其他 Internet 协议中 TCP 的研究、开发和实施中吸取了额外的考虑和经验教训。虽然本文档没有对 DNS 服务器的运营商提出具体要求，但它确实为运营商提供了一些建议，以帮助确保在其服务器和网络上对 TCP 的支持是最佳的。需要注意的是，不支持 TCP（或网络层 TCP 上的 DNS 阻塞）可能会导致解析失败和/或应用程序级超时。2、 需求术语本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 [RFC2119] 中的描述进行解释。3、 术语Persistent connection：持久连接，服务器在发送第一个响应后没有关闭，客户端收到第一个响应后也没有关闭的 TCP 连接。Connection Reuse ：连接复用，通过单个 TCP 连接发送多个查询和响应。Idle DNS-over-TCP session：空闲DNS-over-TCP会话，客户端和服务器以不同的方式查看应用程序级别的空闲。当 DNS 客户端没有待发送的查询并且没有未完成的响应时，DNS 客户端认为已建立的 DNS-over-TCP 会话处于空闲状态。当 DNS 服务器发送了对它在该连接上收到的所有查询的响应时，它认为已建立的 DNS-over-TCP 会话处于空闲状态。Pipelining：流水线，通过单个 TCP 连接发送多个查询和响应，但在发送另一个查询之前不等待任何未完成的回复。Out-of-Order Processing：无序处理，同时处理查询并在单个响应可用时立即返回，可能是无序的。这很可能发生在递归服务器中；但是，在具有不同后端数据存储的权威服务器中是可能的。4、 讨论在没有 EDNS0（DNS 0 的扩展机制 [RFC6891]；见下文）的情况下，任何需要发送超过 512 字节限制的 UDP 响应的 DNS 服务器的正常行为是服务器截断响应，以便它符合该限制，然后在响应标头中设置 TC 标志。当客户端收到这样的响应时，它会将 TC 标志作为它应该通过 TCP 重试的指示。RFC 1123 还说：“同样清楚的是，未来定义的一些新 DNS 记录类型将包含超过适用于 UDP 的 512 字节限制的信息，因此需要 TCP。因此，解析器和域名服务器现在应该实现 TCP 服务作为 UDP 的备份，并且知道它们将来会需要 TCP 服务。”DNSSEC [RFC4033] 的现有部署表明，在 512 字节边界处截断现在很常见。例如，来自使用 NextSECure 3 (NSEC3) [RFC5155] 的 DNSSEC 签名区域的不存在域 (NXDOMAIN) (RCODE == 3) 响应几乎总是大于 512 字节。自从编写了 DNS 的原始核心规范以来，就引入了 DNS 的扩展机制。这些扩展可用于指示客户端已准备好接收大于 512 字节的 UDP 响应。从 EDNS0 兼容客户端接收请求的 EDNS0 兼容服务器可以发送 UDP 数据包，直到该客户端宣布的缓冲区大小而不会截断。但是，超过路径 MTU 大小的 UDP 数据包的传输会导致 IP 数据包分片，这在许多情况下被发现是不可靠的。许多防火墙通常会阻止分片的 IP 数据包，并且有些防火墙没有实施重组分片数据包所需的算法。更糟糕的是，一些网络设备故意拒绝处理包含 EDNS0 选项的 DNS 数据包。与 UDP 传输和数据包大小有关的其他问题在 [RFC5625] 中讨论。在 Internet 核心中最常见的 MTU 约为 1500 字节，即使是 DNSSEC 签名的响应也经常超过这个限制。RFC 1123 中预期的未来已经到来，并且发现可能已经解决了数据包大小问题的唯一标准化的基于 UDP 的机制是不够的。5、 传输协议选择[RFC1123] 的第 6.1.3.2 节已更新：所有通用 DNS 实现必须同时支持 UDP 和 TCP 传输。“权威服务器实现必须支持 TCP，以便它们不会将响应的大小限制为适合单个 UDP 数据包的内容。”“递归服务器（或转发器）实现必须支持 TCP，以便它们不会阻止来自支持 TCP 的服务器的大型响应到达支持 TCP 的客户端。”“存根解析器实现（例如，操作系统的 DNS 解析库）必须支持 TCP，否则会限制它们自己的客户端和上游服务器之间的互操作性。”关于何时使用 UDP 或 TCP 的选择，RFC 1123 的第 6.1.3.2 节还说：“发送非区域传输查询的 DNS 解析器或服务器必须首先发送 UDP 查询。”特此放宽这一要求。存根解析器和递归解析器可以根据本地操作原因选择发送 TCP 或 UDP 查询。在发送任何 UDP 查询之前可以使用 TCP。如果解析器已经有一个开放的 TCP 连接到服务器，它应该复用这个连接。从本质上讲，TCP 应该被视为 UDP 的有效替代传输，而不是纯粹的重试选项。此外，请注意，所有递归和权威服务器必须使用与查询到达时相同的传输方式发送响应。在 TCP 的情况下，这也必须是同一个连接。6、 连接处理6.1、 目前的做法[RFC1035] 的第 4.2.2 节说：“服务器应假定客户端将启动连接关闭，并应延迟关闭其连接端，直到所有未完成的客户端请求都得到满足。”“如果服务器需要关闭一个休眠连接来回收资源，它应该等到连接空闲大约两分钟。特别是，服务器应允许在单个连接上进行 SOA 和 AXFR 请求序列（开始刷新操作）。由于服务器无论如何都无法回答查询，因此可以使用单方面关闭或重置来代替正常关闭。”其他更现代的协议（例如，HTTP/1.1 [RFC7230]、HTTP/2 [RFC7540]）默认支持所有请求的持久 TCP 连接。然后通常通过来自一方的“连接关闭”信号关闭连接。[RFC1035] 中的描述很清楚，服务器应该将连接视为持久连接（尤其是在接收到 SOA 之后），但不幸的是，它没有提供足够的细节来明确解释除 SOA 之外的查询的客户端行为。此外，DNS 还没有用于连接超时或关闭的信号机制，尽管已经提出了一些。6.1.1、 客户端目前在任何 RFC 中都没有关于 DNS 客户端何时应关闭 TCP 连接的明确指导，也没有关于 DNS 客户端空闲超时的具体建议。但是，在撰写本文时，客户端通常会在发送单个请求后关闭 TCP 连接（SOA/AXFR 情况除外）。6.1.2、 服务器许多 DNS 服务器实现使用较长的固定空闲超时，并默认使用少量 TCP 连接。它们还提供很少的 TCP 连接管理选项。这样做的缺点包括：“运营经验表明，长时间的服务器超时很容易导致资源枯竭，在重负载下响应不佳。”“故意打开许多连接并让它们闲置很容易造成 TCP 拒绝服务 (DoS) 攻击，因为许多 DNS 服务器没有能力通过修改其空闲超时或其他连接管理策略来防御这种情况。”“少量客户端同时尝试使用具有非零空闲超时的持久连接到此类服务器可能会无意中导致相同的 DoS 问题。”请注意，此 DoS 仅在 TCP 服务上。但是，在这些情况下，它不仅会影响出于操作原因希望使用 TCP 进行查询的客户端，还会影响所有在收到 TC=1 标志后选择从 UDP 回退到 TCP 的客户端。6.2、 建议以下部分包括旨在使 DNS-over-TCP 实施更加一致和可扩展的建议。6.2.1、 连接复用DNS over TCP 的一个明显缺点是增加了连接建立延迟，通常等于一个 RTT。为了分摊连接建立成本，客户端和服务器都应该通过在单个持久 TCP 连接上发送多个查询和响应来支持连接复用。当通过 TCP 连接发送多个查询时，客户端不得在该连接上复用正在进行的查询的 DNS 消息 ID 以避免消息 ID 冲突。如果服务器可能正在执行乱序处理，这一点尤其重要（参见第 7 节）。6.2.1.1、 查询流水线由于历史上 TCP 主要用于区域传输和截断响应，因此没有现有的 RFC 讨论通过 TCP 连接流水线化 DNS 查询的想法。为了达到与 UDP 同等的性能，DNS 客户端应该管道他们的查询。当 DNS 客户端向服务器发送多个查询时，它不应该在发送下一个查询之前等待未完成的回复。在考虑发送特定查询的时间时，客户端应该同等对待 TCP 和 UDP。DNS 服务器很可能需要同时处理流水线查询，并通过 TCP 发送无序响应，以提供 UDP 传输可能的性能水平。如果 TCP 性能很重要，客户端可能会发现使用服务器处理时间作为服务器和传输选择算法的输入很有用。DNS 服务器（尤其是递归的）必须期望接收流水线查询。服务器应该同时处理 TCP 查询，就像处理 UDP 一样。服务器应该回答所有流水线查询，即使它们是快速连续收到的。第 7 节介绍了对流水线查询的响应的处理。6.2.2、 并发连接为了减轻服务器意外过载的风险，DNS 客户端必须注意尽量减少与任何单个服务器建立的并发 TCP 连接的数量。建议对于任何给定的客户端/服务器交互，对于常规查询，一个用于区域传输的连接，一个用于在 TCP 之上使用的每个协议（例如，如果解析器使用TLS）。但是，请注意，出于操作原因（例如，支持多个区域的并发传输），具有许多繁忙区域的某些主要/次要配置可能需要使用多个 TCP 连接进行区域传输。同样，服务器可以对任何特定客户端 IP 地址或子网处理的并发 TCP 连接数施加限制。这些限制应该比上面的客户端指南宽松得多，因为服务器不知道，例如，如果客户端 IP 地址属于单个客户端，是否是单个机器上的多个解析器，或者是执行网络的设备后面的多个客户端地址转换 (NAT)。6.2.3、 空闲超时为了减轻服务器意外过载的风险，DNS 客户端必须注意尽量减少与任何单个服务器建立的 DNS-over-TCP 会话的空闲时间。DNS 客户端应该关闭空闲会话的 TCP 连接，除非使用其他一些信号机制建立了空闲超时，例如 [edns-tcp-keepalive]。为了降低意外服务器过载的风险，建议默认服务器应用程序级别的空闲时间大约为秒，但没有指定特定值。在实践中，空闲时间可以动态变化，服务器可以允许空闲连接在资源允许的情况下保持打开更长时间。对于正常操作，建议至少几秒钟的超时，以支持那些期望 SOA 和 AXFR 请求序列在 [RFC1035] 中最初指定的单个连接上进行的客户端。服务器在承受重负载或受到攻击时可以使用零超时。通过 TCP 传递的 DNS 消息可能会在多个段中到达。在接收到单个段后重置其空闲超时的 DNS 服务器可能容易受到“慢读攻击”的攻击。出于这个原因，服务器应该在收到完整的 DNS 消息时重置空闲超时，而不是在收到 DNS 消息的任何部分时。6.2.4、 拆除在正常操作下，DNS 客户端通常会在空闲连接上启动连接关闭；但是，如果超出本地策略设置的空闲超时，DNS 服务器可以关闭连接。此外，在防御攻击或系统故障/重启等异常情况下，任何一端都可以关闭连接。如果连接在收到所有未完成的响应之前关闭，DNS 客户端应该重试未回答的查询。本文档中没有指定具体的重试算法。如果 DNS 服务器在发送所有未决响应之前发现 DNS 客户端已关闭 TCP 会话（或会话已被中断），则服务器不得尝试发送这些响应。当然，DNS 服务器可以缓存这些响应。7、 响应重新排序RFC 1035 在 TCP 响应是否可以重新排序的问题上模棱两可——唯一相关的文本在第 4.2.1 节中，它与 UDP 相关：“查询或其响应可能会被网络重新排序，或者通过域名服务器中的处理来重新排序，因此解析器不应依赖于它们按顺序返回。”为避免将来产生疑问，此要求已明确。建议权威服务器和递归解析器支持并行准备响应并无序发送它们，而不管使用的传输协议如何。存根和递归解析器必须能够处理以不同于发送请求的顺序到达的响应，而不管使用的传输协议如何。为了达到与 UDP 同等的性能，递归解析器应该并行处理 TCP 查询，并在它们可用时立即返回单个响应，可能是乱序的。由于流水线响应可能会乱序到达，客户端必须使用消息 ID 将响应与同一 TCP 连接上的未完成查询匹配。如果响应包含问题部分，则客户端必须匹配 QNAME、QCLASS 和 QTYPE 字段。客户未能正确匹配对未决查询的响应可能会对互操作性产生严重后果。8、 TCP报文长度字段DNS 客户端和服务器应该同时将两个八位字节长度字段和由该长度字段描述的消息传递给 TCP 层（例如，在单个“写入”系统调用中），以使所有数据将在单个 TCP 段中传输。这是为了提高效率和避免由于某些 DNS 服务器实现在从 TCP 层读取数据时表现不佳（由于以前的文档中缺乏明确性）而导致的问题。例如，如果来自 TCP 层的第一次“读取”不包含长度字段和整个消息，则某些 DNS 服务器实现可能会中止 TCP 会话。澄清一下，DNS 服务器不能仅仅因为从 TCP 层“读取”的第一个“读取”不包含整个 DNS 消息而关闭连接，并且服务器应该应用第 6.2.3 节中指定的连接超时。9、 TCP 快速打开本部分是非规范性的。TCP 快速打开 (TFO) [RFC7413] 允许在 SYN 数据包中携带数据，从而降低重新打开 TCP 连接的成本。与标准 TCP 相比，它还最多可节省一个 RTT。TFO 通过使用服务器提供的 cookie 减轻了在 SYN 中发送数据所固有的安全漏洞，尤其是在可能发生放大攻击的 DNS 等系统上。TFO 客户端在新连接开始时在初始 SYN 数据包中请求服务器 cookie。服务器在其 SYN-ACK 中返回一个 cookie。客户端缓存 cookie 并在打开与同一服务器的后续连接时复用它。cookie 由客户端的 TCP 堆栈（内核）存储，并在客户端或服务器进程重新启动时保持不变。TFO 也优雅地回退到常规 TCP 握手。在启用 TFO 时，利用 IP 任播 [RFC4786] 的 DNS 服务可能需要采取额外的步骤。来自 [RFC7413]：“接受对同一服务器 IP 地址的连接请求的负载平衡器后面的服务器应使用相同的密钥，以便它们为特定客户端 IP 地址生成相同的快速打开 cookie。否则，客户端可能会通过连接获得不同的 cookie；它的快速开放尝试将退回到常规的 3WHS。”当 DNS-over-TCP 是 DNS 私有交换的传输时，如在 [DNS-over-TLS] 中，实施者需要了解 TFO 并确保需要保护的数据（例如用于 DNS 查询的数据）不会意外清运。请参阅 [DNS-over-TLS] 进行讨论。10、 安全注意事项一些 DNS 服务器运营商表示担心，更广泛地推广和使用基于 TCP 的 DNS 将使他们面临更高的 TCP 拒绝服务攻击风险（包括意外和故意）。尽管针对启用 TCP 的服务器的某些特定攻击的风险较高，但自从首次设计 DNS 以来，在网络级别缓解 DoS 攻击的技术已经有了很大的改进。建议读者熟悉 [CPNI-TCP]，这是一种 TCP 安全评估，详细介绍了已知的 TCP 攻击和对策，并参考了有关该主题的大多数相关 RFC。为了降低 DoS 攻击的风险，建议 DNS 服务器参与 TCP 连接管理。这可能包括维护现有连接的状态、复用现有连接以及控制请求队列以实现公平使用。提供可配置的连接管理选项可能是有利的，例如：** TCP 连接总数** 每个源 IP 地址或子网的最大 TCP 连接数** TCP 连接空闲超时** 每个 TCP 连接的最大 DNS 事务数** 最大 TCP 连接持续时间没有为这些参数推荐特定值。建议操作员熟悉操作系统 TCP 堆栈中可用的配置和调整参数。但是，关于此的详细建议超出了本文档的范围。建议递归服务器的操作员确保他们只接受来自预期客户端的连接（例如，通过使用访问控制列表ACL）并且不接受来自未知来源的连接。在 UDP 流量的情况下，这将有助于防止反射攻击 [RFC5358]；在 TCP 流量的情况下，它将防止未知客户端耗尽服务器对并发连接数的限制。11、 参考文献11.1、 规范性参考[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>. [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <http://www.rfc-editor.org/info/rfc5358>. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <http://www.rfc-editor.org/info/rfc5625>. [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, <http://www.rfc-editor.org/info/rfc5966>. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.11.2、 参考资料[Connection-Oriented-DNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", 2015 IEEE Symposium on Security and Privacy (SP), DOI 10.1109/SP.2015.18, <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7163025>. [CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf>. [DNS-over-TLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over TLS", Work in Progress, draft-ietf-dprive-dns-over-tls-06, February 2016. [edns-tcp-keepalive] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", Work in Progress, draft-ietf-dnsop-edns-tcp-keepalive-03, September 2015. [fragmentation-considered-poisonous] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>. [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>. [RRL1] Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012, <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>. [RRL2] ISC Support, "Using the Response Rate Limiting Feature in BIND 9.10", ISC Knowledge Base AA-00994, June 2013, <https://kb.isc.org/article/AA-00994/>.附录A、 将TCP用于DNS的优缺点总结TCP 握手通常可以防止地址欺骗，因此可以防止UDP的反射/放大攻击的困扰。与 UDP 相比，IP 分片对于 TCP 来说不是问题。TCP 堆栈通常实现路径 MTU 发现，因此它们可以避免 TCP 段的 IP 分片。另一方面，UDP 不提供重组；这意味着超过路径MTU大小的数据报必须经历分片[RFC5405]。众所周知，中间设备会阻止IP片段，从而导致超时并强制客户端实现“寻找”网络路径支持的 EDNS0 回复大小值。此外，碎片可能会导致缓存中毒 [fragmentation-considered-poisonous]。与 UDP 查询相比，TCP 设置需要额外的 RTT。设置成本可以通过复用连接、流水线查询和启用 TCP 快速打开来分摊。TCP 对客户端和服务器施加了额外的状态保持要求。TCP Fast Open 的使用降低了关闭和重新打开 TCP 连接的成本。由于路由更改，与任播服务器的长期 TCP 连接可能会中断。使用 TCP 进行 DNS 的客户端需要始终准备好重新建立连接或以其他方式重试未完成的查询。多路径 TCP [RFC6824] 也可能允许服务器将连接从任播地址移交给单播地址。今天有许多“中间设备”在使用通过端口 53 [RFC5625] 干扰 TCP。本文档没有提出任何解决方案，只是明确说明 TCP 是 DNS 的有效传输方式，并且支持它是所有实现的要求。关于面向连接的 DNS 更深入的讨论可以在其他地方找到 [Connection-Oriented-DNS]。附录B、 对RFC 5966的更改本文档废弃了 [RFC5966] 并且在几个方面与它不同。下面概述了实施者应注意的最重要的更改/更新。1. 添加了术语部分（第 3 部分），定义了几个新概念。2. 第 5 节的第 3 段将 TCP 与 UDP 置于比 RFC 5966 更平等的地位。例如，它指出：1. TCP 可以在发送任何 UDP 查询之前使用。2. TCP 应该被认为是 UDP 的有效替代传输，而不是纯粹的后备选项。3. 第 6.2.1 节增加了一个新的建议，即应该支持 TCP 连接复用。4. 第 6.2.1.1 节添加了一条新建议，即 DNS 客户端应该管道其查询，并且 DNS 服务器应该同时处理管道查询。5. 第 6.2.2 节添加了关于客户端/服务器交互的 TCP 连接数量和使用的新建议。6. 第 6.2.3 节添加了一条新建议，即 DNS 客户端应该关闭空闲会话，除非使用信令机制。7. 第 7 节阐明建议服务器并行准备 TCP 响应并无序发送响应。它还阐明了客户端应如何匹配 TCP 查询和响应。8. 第 8 节添加了关于 DNS 客户端和服务器应如何处理 TCP 消息的 2 字节消息长度字段的新建议。9. 第 9 节增加了关于 TCP Fast Open 使用的非规范性讨论。10. 第 10 节添加了有关 DoS 缓解技术的新建议。致谢作者要感谢 Francis Dupont 和 Paul Vixie 的详细评论，以及 Andrew Sullivan、Tony Finch、Stephane Bortzmeyer、Joe Abley、Tatuya Jinmei 以及为邮件列表讨论做出贡献的许多其他人。此外，作者感谢 Liang Zhu、Zi Hu 和 John Heidemann 对 DNS-over-TCP 的广泛讨论和代码，以及 Lucie Guiraud 和 Danny McPherson 审阅了本文档的早期草稿版本。我们还要感谢所有为 RFC 5966 做出贡献的人。
-
发表了文章 2023-03-05
基于TCP的DNS传输：操作要求
RFC9210：DNS Transport over TCP -Operational Requirements，March 2022梗概本文档更新了RFC 1123和RFC 1536。本文档要求将允许DNS消息在Internet上通过TCP传输的操作实践作为当前最佳实践。此操作要求与RFC 7766中的实施要求一致。TCP的使用包括基于未加密TCP的DNS以及加密的TLS会话。该文件还考虑了这种形式的DNS通信的后果，以及在不支持当前最佳实践时可能出现的潜在运营问题。本备忘录的状态本备忘录记录了 Internet 最佳当前实践。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 BCP 的更多信息，请参见 RFC 7841 的第 2 节。有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9210。版权声明版权所有 (c) 2022 IETF Trust 和文件作者。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (https://trustee.ietf.org/license-info) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节所述的修订版 BSD 许可文本，并且按照修订版 BSD 许可中的说明提供无担保。1、 简介DNS消息使用 UDP 或 TCP 通信传送。虽然大多数 DNS 事务都是通过 UDP 进行的，但一些运营商认为对于一般的 DNS 操作来说，任何基于 TCP 的 DNS 流量都是不需要或不必要的。当DNS over TCP受到限制时，经常会出现各种通信故障和调试挑战。随着 DNS 和新的域名系统功能的发展，TCP 作为一种传输方式对于 Internet DNS 的正确和安全运行变得越来越重要。反映现代用法，DNS 标准声明对 TCP 的支持是 DNS 实现规范 [RFC7766] 的必需部分。本文档相当于运营社区的正式要求，鼓励系统管理员、网络工程师和安全人员确保 DNS-over-TCP 通信支持与 DNS-over-UDP 通信相同。它更新了 [RFC1123] 的第 6.1.3.2 节以阐明所有 DNS 解析器和递归服务器必须支持和服务 TCP 和 UDP 查询，并更新 [RFC1536] 以消除 TCP 仅对区域传输有用的误解。1.1、 需求语言本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”，当且仅当它们以全部大写字母出现时，将按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。2、 DNS over TCP的历史运营最佳实践与 DNS 传输协议指南之间的奇怪分歧源于运营商从其他运营商、实施者甚至 IETF 收到的相互冲突的消息。有时这些混合信号是明确的；在其他情况下，相互矛盾的信息是隐含的。本节介绍了导致本文档的传奇且相互矛盾的历史的解释。本节仅供参考。2.1、不均匀传输的用途和偏好在最初的 DNS 规范套件中，[RFC1034] 和 [RFC1035] 明确规定 DNS 消息可以在 UDP 或 TCP 中传输，但它们也声明在一般情况下优先选择 UDP 作为查询的最佳传输。如 [RFC1035] 中所述：“虽然虚拟电路可用于任何 DNS 活动，但数据报更适合用于查询，因为它们的开销较低且性能更好。”另一个早期的、重要的和有影响力的文件，[RFC1123]，更明确地标记了对传输协议的偏好：“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”并进一步规定：“域名服务器可以限制它用于 TCP 查询的资源，但它不应该仅仅因为它会通过 UDP 成功而拒绝为 TCP 查询提供服务。”在 [RFC1536] 中达到高潮，基于 TCP 的 DNS 主要与区域传输机制相关联，而大多数 DNS 查询和响应被视为 UDP 的统治。2.2、 等待大消息和可靠性在原始规范中，最大 DNS-over-UDP 消息大小规定为 512 字节。然而，即使 [RFC1123] 更喜欢 UDP 进行非区域传输查询，它也预见到 DNS over TCP 将在未来变得更加流行，以克服这个限制：“很明显，未来定义的一些新 DNS 记录类型将包含超过适用于 UDP 的 512 字节限制的信息，因此需要 TCP。”至少有两个新的、被广泛期待的发展提高了对 DNS-over-TCP 事务的需求。第一个是 [RFC2136] 中定义的动态更新，第二个是统称为“DNSSEC”的扩展集，其操作注意事项最初在 [RFC2541] 中给出（注意 [RFC2541] 已被 [RFC6781] 废弃）。前者建议需要准确响应代码的请求者必须使用 TCP。而后者警告说，较大的密钥会增加 KEY 和 SIG RR 的大小。这增加了 DNS UDP 数据包溢出的可能性以及在响应中使用更高开销 TCP 的可能必要性。然而，出乎一些人的意料，在 1990 年代后期，基于 TCP 的 DNS 在互联网上的实际流量中仍然很少使用。动态更新在自治网络之间几乎没有部署。大约在首次定义 DNSSEC 的时候，另一个新功能帮助巩固了 UDP 传输在消息事务中的主导地位。2.3、 EDNS(0)1999 年，IETF 在 [RFC2671] 中发布了 DNS 扩展机制 (Extension Mechanisms for DNS，EDNS(0))（在 2013 年被 [RFC6891] 废弃）。该文档标准化了一种用于通信 DNS 节点以执行基本功能协商的方式。写入基本规范并出现在每个与 EDNS(0) 兼容的消息中的此类功能之一是发送方可以支持的最大 UDP 有效负载大小的值。这个无符号的 16 位字段以字节为单位指定节点能够通过 UDP 接收的最大（可能是分段的）DNS 消息大小。在实践中，典型值是 512 到 4096 字节范围的子集。在接下来的几年中，EDNS(0) 得到了广泛的部署，大量调查（参见 [CASTRO2010] 和 [NETALYZR]）表明，许多系统通过 EDNS(0) 支持更大的 UDP MTU。EDNS(0) 部署的自然效果意味着大于 512 字节的 DNS 消息对 TCP 的依赖程度将低于其他情况。虽然不可忽略的 DNS 系统群体缺少 EDNS(0) 或在必要时回退到 TCP，但 DNS 客户端仍然强烈倾向于使用 UDP 而不是 TCP。例如，截至 2014 年，DNS-over-TCP 事务在根域名服务器 [VERISIGN] 接收的整体 DNS 流量中仍然只占很小的一部分。2.4、 分片和截断尽管 EDNS(0) 为端点提供了一种表示支持超过 512 字节的 DNS 消息的方法，但 Internet 的多样化和不一致部署的现实可能导致一些大型消息无法到达其目的地。任何大小超过其传输的链路的 MTU 的 IP 数据报都将被分片，然后由接收主机重新组合。不幸的是，中间设备和防火墙阻止 IP 片段的情况并不少见。如果一个或多个片段没有到达，应用程序不会收到消息，请求超时。对于 IPv4 连接的主机，MTU 通常是 1500 字节的以太网负载大小。这意味着可以通过 IPv4 发送的最大未分段 UDP DNS 消息可能是 1472 字节，尽管在某些情况下隧道封装可能会减小最大消息大小。对于 IPv6，情况稍微复杂一些。首先，IPv6 报文头为 40 个字节（而 IPv4 中为 20 个字节）。其次，大约三分之一的 DNS 递归解析器使用 1280 字节的最小 MTU [APNIC]。第三，IPv6 中的分段只能由发起数据报的主机完成。分段的需要在 ICMPv6“数据包太大”消息中传达。始发主机指示带有 IPv6 扩展头的分段数据报。不幸的是，ICMPv6 和 IPv6 扩展报文头都被中间设备阻止是很常见的。根据 [HUSTON]，大约 35% 的支持 IPv6 的递归解析器无法接收分段的 IPv6 数据包。当始发主机收到需要分段的信号时，它应该为该目的地填充其路径 MTU 缓存。应用程序将在超时后重试查询，因为主机通常不会保留通过 UDP 发送的消息副本以用于可能的重传。所有这一切的实际后果是 DNS 请求者必须准备好使用不同的 EDNS(0) 最大消息大小值重试查询。[BIND] 的管理员可能熟悉在他们的系统日志中看到以下消息：“成功解析......在将通告的 EDNS(0) UDP 数据包大小减少到 512 个八位字节后”。通常，减小 EDNS(0) UDP 数据包大小会导致成功响应。也就是说，必要的数据适合较小的消息大小。但是，当数据不适合时，服务器会在其响应中设置截断标志，指示客户端应通过 TCP 重试以接收整个响应。从客户端的角度来看，这是不可取的，因为它增加了更多的延迟，并且从服务器的角度来看，由于 TCP 的资源需求增加，这可能是不可取的。请注意，接收方无法区分由于拥塞而丢失的数据包和防火墙或中间设备故意丢弃的数据包（片段）。在具有大量丢包的网络路径上，与较小的未分段响应相比，较大的分段 DNS 响应更有可能永远不会到达并超时。由于错误的原因，客户端可能会被误导使用不同的 EDNS(0) UDP 数据包大小值重试查询。围绕碎片、截断和 TCP 的问题正在推动 DNS 中的某些实施和政策决策。值得注意的是，Cloudflare 实施了一种技术，可最大限度地减少 DNSSEC 拒绝存在记录的数量（针对其在线签名平台）[CLOUDFLARE]，并使用椭圆曲线数字签名算法 (Elliptic Curve Digital Signature Algorithm，ECDSA)，使其签名响应轻松放入 512 个字节。密钥签名密钥 (Key Signing Key，KSK) 翻转设计团队 [DESIGNTEAM] 花了很多时间思考和担心响应大小。DNSSEC 社区越来越多的观点认为，超过 2048 位的 RSA 密钥大小是不切实际的，关键基础设施区域应过渡到椭圆曲线算法以保持响应大小可管理 [ECDSA]。最近，关于分段 DNS 消息的新安全问题（参见 [AVOID_FRAGS] 和 [FRAG_POISON]）导致实施者考虑更小的响应和更低的默认 EDNS(0) UDP 有效负载大小值，用于查询器和响应器 [FLAGDAY2020]。2.5、 “仅区域传输使用 TCP”今天，大多数 DNS 社区都希望，或者至少希望看到 DNS-over-TCP 事务在不受干扰的情况下发生 [FLAGDAY2020]。然而，一些运营商长期以来一直认为，尤其是出于安全相关的原因，DNS-over-TCP 服务应该被故意限制或根本不提供 [CHES94] [DJBDNS]。一个流行的梗是 TCP 上的 DNS 仅用于区域传输，否则通常是不必要的，过滤所有 TCP 上的 DNS 流量甚至被描述为最佳实践。鉴于 DNS 域名服务器的历史实现几乎没有提供 TCP 连接管理的方式（例如，有关更多详细信息，请参阅 [RFC7766] 的第 6.1.2 节），限制基于 TCP 的 DNS 的立场是有道理的。然而，现代标准和实施已接近与 HTTP(S) 服务器和负载均衡器等采用的更复杂的 TCP 管理技术相当。2.6、 复用、流水线和无序处理TCP 连接可以支持多个事务的想法可以追溯到 [RFC0883]，其中指出：“可以通过虚拟电路发送多个消息。”尽管更新前者的 [RFC1035] 省略了这一特定细节，但人们普遍认为 TCP 连接可用于多个查询和响应。[RFC5966] 阐明了服务器不需要在任何传输中保留查询和响应的顺序。[RFC7766] 更新了前者，进一步鼓励通过 TCP 进行查询流水线以达到与 UDP 相当的性能。当对较早查询的响应在对较早查询的响应之前准备好时，向流水线查询发送无序响应的服务器避免了线头阻塞。但是，由于数据包丢失，TCP 可能会遇到不同的线头阻塞问题。由于 TCP 本身强制执行排序，单个丢失的段会延迟任何后续段中的数据传递，直到丢失的段被重新传输并成功接收。3、 DNS-over-TCP 要求DNS 消息大小的平均增加（例如，由于 DNSSEC）、新 DNS 功能的持续开发（附录 A）以及拒绝服务缓解技术（第 8 节）都表明 DNS-over-TCP 事务是对于 Internet DNS 的正确和安全运行，与以往一样重要，甚至更重要。此外，有研究认为面向连接的 DNS 事务可能比 UDP 传输 [TDNS] 提供安全和隐私优势。事实上，DNS over TLS [RFC7858] 的标准就是这种规范。因此，本文档明确指出网络运营商不希望人为地禁止 DNS-over-TCP 传输。[RFC1123] 的第 6.1.3.2 节更新如下：之前是“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”现在是“所有 DNS 解析器和服务器必须支持和服务 UDP 和 TCP 查询。”注意：* DNS 服务器（包括转发器）必须支持和服务 TCP 以接收查询，以便客户端可以可靠地接收大于任何一方认为对于 UDP 来说太大的响应。* DNS 客户端必须支持 TCP 发送查询，以便它们可以在必要时重试截断的 UDP 响应。此外，[RFC1123] 的第 6.1.3.2 节中关于限制服务器用于查询的资源的要求在此更新：之前是“域名服务器可以限制它用于 TCP 查询的资源，但它不应该仅仅因为它会通过 UDP 成功而拒绝为 TCP 查询提供服务。”现在是“域名服务器可以限制它用于查询的资源，但它绝不能仅仅因为它可以使用另一个传输协议成功而拒绝为查询提供服务。”最后，更新了 [RFC1536] 的第 1 节，以消除 TCP 仅对区域传输有用的误解：之前是“DNS 实现了客户端-服务器交互的经典请求-响应方案。因此，UDP 是选择的通信协议，尽管 TCP 用于区域传输。”现在是“DNS 实现了客户端-服务器交互的经典请求-响应方案。”在一般情况下，通过 TCP 过滤 DNS 是有害的。DNS 解析器和服务器运营商必须支持并通过 UDP 和 TCP 传输提供 DNS 服务。同样，网络运营商必须允许通过 UDP 和 TCP 传输的 DNS 服务。众所周知，DNS-over-TCP 服务可能会带来单独运行 DNS over UDP 时不存在的操作挑战，反之亦然。但是，与允许使用 DNS 相比，禁止 DNS-over-TCP 服务所带来的潜在损害对 DNS 的持续实用性和成功更为不利。4、 网络和系统注意事项本节介绍系统和应用程序可以采取哪些措施来优化 TCP 的性能并保护自己免受基于 TCP 的资源耗尽和攻击。4.1、 连接建立和准入解析器和其他 DNS 客户端应该知道某些服务器可能无法通过 TCP 访问。出于这个原因，客户端可以跟踪和限制对单个服务器的 TCP 连接和连接尝试的数量。可达性问题可能是由靠近服务器、靠近客户端或它们之间路径上的任何地方的网络元素引起的。缓存连接失败的移动客户端可以在每个网络的基础上这样做，或者可以在网络更改时清除这样的缓存。此外，DNS 客户端可以对未建立的连接强制执行短暂的超时，而不是依赖主机操作系统的 TCP 连接超时，这通常约为 60-120 秒（即，由于 1 秒的初始重传超时，指数回退[RFC6298] 的规则，以及六次重试的限制，这是 Linux 中的默认值）。SYN 泛洪攻击是一种拒绝服务方法，影响运行 TCP 服务器进程的主机 [RFC4987]。如果不加以缓解，这种攻击可能非常有效。最有效的缓解技术之一是 SYN cookie，在 [RFC4987] 的第 3.6 节中进行了描述，它允许服务器避免分配任何状态，直到成功完成三次握手。不打算供公共 Internet 使用的服务，例如大多数递归域名服务器，应该受到访问控制的保护。理想情况下，这些控件放置在网络中，远在任何不需要的 TCP 数据包到达 DNS 服务器主机或应用程序之前。如果这是不可能的，可以将控件放置在应用程序本身中。在某些情况下（例如，攻击），可能有必要为原本应该可以全局访问的 DNS 服务部署访问控制。另见 [RFC5358]。FreeBSD 和 NetBSD 操作系统有一个“接受过滤器”特性（[accept_filter]），它可以推迟向应用程序发送 TCP 连接，直到收到完整、有效的请求。dns_accf(9) 过滤器确保接收到有效的 DNS 消息。如果没有，虚假连接永远不会到达应用程序。Linux TCP_DEFER_ACCEPT 功能虽然范围更有限，但可以提供与 BSD 接受过滤器功能相同的一些好处。这些功能是作为低级套接字选项实现的，不会自动激活。如果应用程序希望使用这些功能，他们需要进行特定调用以设置正确的选项，并且管理员可能还需要配置应用程序以适当地使用这些功能。根据 [RFC7766]，建议应用程序和管理员记住在发送任何 UDP 查询之前可以使用 TCP。不得将网络和应用程序配置为拒绝前面没有 UDP 查询的 TCP 查询。TCP 快速打开 (TCP Fast Open，TFO) [RFC7413] 允许 TCP 客户端缩短与同一服务器的后续连接的握手。TFO 在连接设置中节省了一次往返时间。DNS 服务器应该尽可能启用 TFO。此外，集群在单个服务地址后面的 DNS 服务器（例如，任播或负载均衡）应该在所有实例上使用相同的 TFO 服务器密钥，或者为集群的所有成员禁用 TFO。DNS 客户端也可以启用 TFO。在撰写本文时，它尚未在某些操作系统上实现或默认禁用。[WIKIPEDIA_TFO] 描述了支持 TFO 的应用程序和操作系统。4.2、 连接管理由于 TCP 状态的主机内存是有限资源，DNS 客户端和服务器应该主动管理它们的连接。不主动管理其连接的应用程序可能会遇到资源耗尽导致拒绝服务。对于 DNS，与在其他协议中一样，在保持连接开放以供未来可能使用和需要为即将到来的新连接释放资源之间进行权衡。DNS 服务器软件的运营商应该知道，操作系统和应用程序供应商可能会对已建立的连接总数施加限制。这些限制可能旨在防止 DDoS 攻击或性能下降。运营商应该了解如何在必要时增加这些限制以及这样做的后果。应用程序施加的限制应该低于操作系统施加的限制，以便应用程序可以将自己的策略应用于连接管理，例如首先关闭最旧的空闲连接。DNS 服务器软件可以对每个源 IP 地址或子网的已建立连接数提供可配置的限制。这可用于确保单个或一小组用户不能消耗所有 TCP 资源并拒绝向其他用户提供服务。但是请注意，如果启用此限制，它可能会限制客户端性能，同时使某些 TCP 资源未被使用。运营商应该意识到这些权衡，并确保根据用户的数量和多样性以及用户是从唯一的 IP 地址还是通过共享的网络地址转换器 (Network Address Translator，NAT) [RFC3022] 来适当设置此限制（如果已配置） .DNS 服务器软件应该为空闲 TCP 连接提供可配置的超时。这可用于为新连接释放资源并确保最终关闭空闲连接。同时，它可能会限制客户端性能，同时使一些 TCP 资源未被利用。对于非常繁忙的域名服务器，这可能会设置为较低的值，例如几秒钟。对于不太繁忙的服务器，它可能会设置为更高的值，例如几十秒。DNS 客户端和服务器应该使用 edns-tcp-keepalive EDNS(0) 选项 [RFC7828] 来通知它们的超时值。DNS 服务器软件可以对每个 TCP 连接的事务数量提供可配置的限制。这有助于防止不公平的连接使用（例如，不向其他客户端释放连接槽）和网络规避攻击。同样，DNS 服务器软件可以对 TCP 连接的总持续时间提供可配置的限制。这有助于防止不公平的连接使用、慢读攻击和网络规避攻击。由于客户端可能不知道服务器施加的限制，因此使用 TCP 进行 DNS 的客户端需要始终准备好重新建立连接或重试未完成的查询。4.3、 连接终止发起连接关闭的 TCP 对等体将套接字保持在 TIME_WAIT 状态一段时间，可能是几分钟。通常最好由客户端发起关闭 TCP 连接，这样繁忙的服务器就不会积累很多处于 TIME_WAIT 状态的套接字，这可能会导致性能问题甚至拒绝服务。edns-tcp-keepalive EDNS(0) 选项 [RFC7828] 可用于鼓励客户端关闭连接。在 TIME_WAIT 中观察到大量套接字（作为客户端或服务器）并影响应用程序性能的系统上，调整本地 TCP 参数可能很诱人。例如，Linux 内核有一个名为 net.ipv4.tcp_tw_reuse 的“sysctl”参数，它允许在特定情况下复用处于 TIME_WAIT 状态的连接。但是请注意，这仅影响传出（客户端）连接，对服务器没有影响。在大多数情况下，不建议更改与 TIME_WAIT 状态相关的参数。它只能由对 TCP 和受影响的应用程序有详细了解的人员来完成。4.4、 基于 TLS 的 DNSDNS 消息可以通过 TLS 发送，以在存根和递归解析器之间提供隐私。[RFC7858] 是一个标准跟踪文档，描述了它是如何工作的。尽管 DNS over TLS 使用 TCP 端口 853 而不是端口 53，但本文档同样适用于 DNS over TLS。但是请注意，在撰写本文时，仅在存根和递归之间定义了基于 TLS 的 DNS。TLS 的使用给 DNS 客户端和服务器带来了更大的运营负担。用于身份验证和加密的加密功能需要额外的处理。与 TCP 相比，使用 TLS 1.3 [RFC8446] 的未优化连接设置需要多一次往返。使用 TLS 1.2 的 TCP Fast Open 和 TLS False Start [RFC7918] 可以减少连接设置时间。TLS 1.3 会话恢复不会减少往返延迟，因为在撰写本文时尚未发布使用 DNS 的 TLS 0-RTT 数据的应用程序配置文件。但是，TLS 会话恢复可以减少加密操作的数量，并且在 TLS 1.2 中，会话恢复确实将额外的往返次数从两次减少到一次。4.5、 默认值和推荐限制在撰写本文时，对流行的开源 DNS 服务器实施进行了功能和默认设置的调查。本节记录了这些默认值，并就可在没有任何其他信息的情况下使用的可配置限制提出建议。本文档中的任何推荐值仅供不确定哪种限制可能是合理的管理员的起点。运营商应该使用特定于应用程序的监控、系统日志和系统监控工具来衡量他们的服务是否在这些限制范围内或超过这些限制范围内运行，并进行相应的调整。大多数开源 DNS 服务器实现对已建立的连接总数提供了可配置的限制。默认值范围从 20 到 150。在大多数情况下，大多数查询通过 UDP 进行，150 是一个合理的限制。对于大多数查询通过 TCP 或 TLS 进行的服务或环境，5000 是更合适的限制。只有一些开源实现提供了一种方法来限制每个源 IP 地址或子网的连接数，但默认设置是没有限制。对于可能需要启用此限制的环境或情况，每个源 IP 地址 25 个连接是一个合理的起点。当按子网聚合或大多数查询通过 TCP 或 TLS 进行的服务时，应增加限制。大多数开源实现都提供了可配置的连接空闲超时。默认值范围为 2 到 30 秒。在大多数情况下，10 秒是此限制的合理默认值。更长的超时时间可以提高连接复用，但繁忙的服务器可能需要使用下限。只有一些开源实现提供了一种方法来限制每个连接的事务数，但默认设置是没有限制。本文档不提供有关此类限制的特定值的建议。只有一些开源实现提供了一种限制连接持续时间的方法，但默认情况下是没有限制的。本文档不提供有关此类限制的特定值的建议。5、 DNS-over-TCP 过滤风险通过 TCP 过滤 DNS 的网络可能会失去对 DNS 域名空间的重要或重要部分的访问权限。由于各种原因，DNS 应答可能需要 DNS-over-TCP 查询。这可能包括大型消息、缺乏 EDNS(0) 支持或 DDoS 缓解技术（包括响应速率限制 [Response Rate Limiting，RRL]）；此外，也许一些尚未预见的未来能力也将需要 TCP 传输。例如，[RFC7901] 描述了一种在 DNS 响应中发送额外数据的延迟避免技术。这使得响应更大，并可能提高 DDoS 反射攻击的有效性。该规范要求使用 TCP 或 DNS cookie [RFC7873]。即使过去使用 UDP 成功返回了任何或所有特定响应，但在自治系统之间交换 DNS 消息时，无法保证这种持续行为。因此，通过 TCP 过滤 DNS 被认为是有害的，并且与 Internet 的安全和成功运行背道而驰。本节列举了在撰写本文时网络通过 TCP 过滤 DNS 时的一些已知风险。5.1、 截断、重试和超时通过 TCP 过滤 DNS 的网络可能会无意中导致第三方解析器出现问题，正如 [TOYAMA] 所经历的那样。例如，解析器接收对中等流行域的查询。解析器将查询转发到域的权威域名服务器，但这些服务器以设置的 TC 位进行响应。解析器通过 TCP 重试，但权威服务器通过 TCP 阻止 DNS。挂起的连接会消耗解析器上的资源，直到超时。如果这些被截断然后阻塞的查询的数量和频率足够高，那么解析器会将宝贵的资源浪费在永远无法回答的查询上。受影响的 DNS 解析器运营商通常不会轻易或完全缓解这种情况。5.2、 DNS 根区 KSK 轮转为根区域部署 DNSSEC KSK 的计划突出了检索根区域密钥集 [LEWIS] 的潜在问题。在 KSK 翻转过程的某些阶段，根区域 DNSKEY 响应大于 1280 字节，这是承载 IPv6 流量的链路的 IPv6 最小 MTU [RFC8200]。有人担心任何无法通过 UDP 接收大型 DNS 消息或任何通过 TCP 的 DNS 消息的 DNS 服务器在执行 DNSSEC 验证时会遇到中断 [KSK_ROLLOVER_ARCHIVES]。但是，在长达一年的 KSK 轮转延期期间，当新旧密钥都在区域中发布时，没有报告可归因于 1414 八位字节 DNSKEY 响应的问题。此外，在旧密钥发布为已撤销且 DNSKEY 响应大小为 1425 个八位字节 [ROLL_YOUR_ROOT] 的两个月期间，没有报告任何问题。6、 记录和监控记录或监控 DNS 的应用程序开发人员不应因为认为 TCP 很少使用或难以处理而忽略它。运营商应确保其监控和日志记录应用程序通过 TCP 正确捕获 DNS 消息。否则，可能无法检测到攻击、渗透尝试和正常流量。TCP 上的 DNS 消息不能保证在单个段中到达。事实上，聪明的攻击者可能会试图通过将某些消息强制通过非常小的 TCP 段来隐藏某些消息。捕获网络数据包的应用程序（例如，使用 libpcap [libpcap]）应该实现并执行完整的 TCP 流重组并分析重组后的流而不是单个数据包。否则，它们很容易受到网络规避攻击 [phrack]。此外，此类应用程序需要通过限制分配给跟踪未确认的连接状态数据的内存量来保护自己免受资源耗尽攻击。dnscap [dnscap] 是实现 TCP 流重组的 DNS 日志记录程序的开源示例。在构建和测试 DNS 监控应用程序时，开发人员还应该牢记连接复用、查询管道和乱序响应。作为数据包捕获的替代方案，一些 DNS 服务器软件支持 dnstap [dnstap] 作为旨在促进大规模 DNS 监控的集成监控协议。7、 IANA 考虑事项本文档没有 IANA 操作。8、 安全考虑本文档提供了操作要求，是 [RFC7766] 中提供的基于 TCP 的 DNS 实施要求的配套文件。[RFC7766] 中的安全考虑仍然适用。具有讽刺意味的是，返回截断的 DNS-over-UDP 响应以诱导客户端查询切换到基于 TCP 的 DNS 已成为对源地址欺骗、DNS 拒绝服务攻击 [RRL] 的常见响应。从历史上看，运营商一直对基于 TCP 的攻击保持警惕，但近年来，基于 UDP 的泛洪攻击已被证明是最常见的 DNS 协议攻击。然而，TCP 上的高速率短期 DNS 事务可能会带来挑战。事实上，如果可以预测 IP 标识符字段（IPv4 中的 16 位和 IPv6 中的 32 位）并且系统被强制分片而不是重传消息，则 [DAI21] 详细介绍了针对 DNS 事务的一类 IP 分片攻击。尽管许多运营商多年来一直在毫无胁迫地提供 DNS-over-TCP 服务，但过去的经验并不能保证未来的成功。基于 TCP 的 DNS 类似于许多其他 Internet TCP 服务。TCP 威胁和许多缓解策略已在 [RFC4953]、[RFC4987]、[RFC5927] 和 [RFC5961] 等一系列文档中详细记录。如第 6 节所述，实现 TCP 流重组的应用程序需要限制分配给连接跟踪的内存量。不这样做可能会导致日志记录或监控应用程序完全失败。强加资源限制在允许某些流重组继续和允许某些规避攻击成功之间进行权衡。本文档建议 DNS 服务器尽可能启用 TFO。[RFC7413] 建议负载均衡器后面的服务器池与共享服务器 IP 地址共享用于生成快速打开 cookie 的密钥，以防止过度回退到三次握手 (three-way handshake，3WHS)。该指南仍然准确，但有一个警告：破坏一台服务器会泄露此组共享密钥，并允许通过伪造无效的快速打开 cookie 来进行涉及池中其他服务器的攻击。9、 隐私注意事项由于 UDP 和 TCP 上的 DNS 使用相同的底层消息格式，使用一种传输而不是另一种传输不会改变消息内容的隐私特征（即被查询的名称）。最近开发了许多协议来提供 DNS 隐私，包括基于 TLS 的 DNS [RFC7858]、基于 DTLS 的 DNS [RFC8094]、基于 HTTPS 的 DNS [RFC8484]，还有更多协议正在开发中。因为 TCP 比 UDP 稍微复杂一些，所以 TCP 对话的某些特征可能会启用 DNS 客户端指纹识别和跟踪，而这在 UDP 中是不可能的。例如，初始序列号、窗口大小和选项的选择可能能够识别特定的 TCP 实现，甚至可以识别共享资源（如 NAT）后面的单个主机。10、 参考文献10.1、 规范性参考[RFC1035] Mockapetris, P., "Domain names -implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>. [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP -Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>. [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>. [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <https://www.rfc-editor.org/info/rfc7873>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.10.2、 参考资料[accept_filter] FreeBSD, "FreeBSD accept_filter(9)", June 2000, <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>. [APNIC] Huston, G., "DNS XL", October 2020, <https://labs.apnic.net/?p=1380>. [AVOID_FRAGS] Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-avoid-fragmentation-06, 23 December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-06>. [BIND] Internet Systems Consortium, "BIND 9", <https://www.isc.org/bind/>. [CASTRO2010] Castro, S., Zhang, M., John, W., Wessels, D., and K. claffy, "Understanding and Preparing for DNS Evolution", DOI 10.1007/978-3-642-12365-8_1, April 2010, <https://doi.org/10.1007/978-3-642-12365-8_1>. [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", First Edition, 1994. [CLOUDFLARE] Grant, D., "Economical With The Truth: Making DNSSEC Answers Cheap", June 2016, <https://blog.cloudflare.com/black-lies/>. [DAI21] Dai, T., Shulman, H., and M. Waidner, "DNS-over-TCP Considered Vulnerable", DOI 10.1145/3472305.3472884, July 2021, <https://doi.org/10.1145/3472305.3472884>. [DESIGNTEAM] ICANN, "Root Zone KSK Rollover Plan", March 2016, <https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf>. [DJBDNS] Bernstein, D., "When are TCP queries sent?", November 2002, <https://cr.yp.to/djbdns/tcp.html#why>. [dnscap] DNS-OARC, "DNSCAP", February 2014, <https://www.dns-oarc.net/tools/dnscap>. [dnstap] "dnstap", <https://dnstap.info>. [ECDSA] van Rijswijk-Deij, R., Sperotto, A., and A. Pras, "Making the Case for Elliptic Curves in DNSSEC", DOI 10.1145/2831347.2831350, October 2015, <https://dl.acm.org/doi/10.1145/2831347.2831350>. [FLAGDAY2020] DNS Software and Service Providers, "DNS Flag Day 2020", October 2020, <https://dnsflagday.net/2020/>. [FRAG_POISON] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <https://arxiv.org/pdf/1205.4011.pdf>. [HUSTON] Huston, G., "Dealing with IPv6 fragmentation in the DNS", August 2017, <https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/>. [KSK_ROLLOVER_ARCHIVES]ICANN, "KSK Rollover List Archives", January 2019,<https://mm.icann.org/pipermail/ksk-rollover/2019-January/date.html>. [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74, May 2017, <https://ripe74.ripe.net/presentations/25-RIPE74-lewis-submission.pdf>. [libpcap] The Tcpdump Group, "Tcpdump and Libpcap", <https://www.tcpdump.org>. [NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, "Netalyzr: Illuminating The Edge Network", DOI 10.1145/1879141.1879173, November 2010, <https://doi.org/10.1145/1879141.1879173>. [phrack] horizon, "Defeating Sniffers and Intrusion Detection Systems", Phrack Magazine, December 1998, <http://phrack.org/issues/54/10.html>. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>. [RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>. [RFC1034] Mockapetris, P., "Domain names -concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>. [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, <https://www.rfc-editor.org/info/rfc1536>. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>. [RFC2541] Eastlake 3rd, D., "DNS Security Operational Considerations", RFC 2541, DOI 10.17487/RFC2541, March 1999, <https://www.rfc-editor.org/info/rfc2541>. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>. [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September 1999, <https://www.rfc-editor.org/info/rfc2694>. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, <https://www.rfc-editor.org/info/rfc3225>. [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, DOI 10.17487/RFC3226, December 2001, <https://www.rfc-editor.org/info/rfc3226>. [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, <https://www.rfc-editor.org/info/rfc4472>. [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>. [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>. [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>. [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <https://www.rfc-editor.org/info/rfc5452>. [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, DOI 10.17487/RFC5507, April 2009, <https://www.rfc-editor.org/info/rfc5507>. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>. [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>. [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>. [RFC5966] Bellis, R., "DNS Transport over TCP -Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, <https://www.rfc-editor.org/info/rfc5966>. [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>. [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>. [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>. [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>. [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, March 2015, <https://www.rfc-editor.org/info/rfc7477>. [RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", RFC 7534, DOI 10.17487/RFC7534, May 2015, <https://www.rfc-editor.org/info/rfc7534>. [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service Protocol and Deployment Requirements", BCP 40, RFC 7720, DOI 10.17487/RFC7720, December 2015, <https://www.rfc-editor.org/info/rfc7720>. [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>. [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 10.17487/RFC7901, June 2016, <https://www.rfc-editor.org/info/rfc7901>. [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/info/rfc7918>. [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, DOI 10.17487/RFC8027, November 2016, <https://www.rfc-editor.org/info/rfc8027>. [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>. [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, <https://www.rfc-editor.org/info/rfc8324>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, October 2018, <https://www.rfc-editor.org/info/rfc8467>. [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, <https://www.rfc-editor.org/info/rfc8482>. [RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, October 2018, <https://www.rfc-editor.org/info/rfc8483>. [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>. [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, <https://www.rfc-editor.org/info/rfc8490>. [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, <https://www.rfc-editor.org/info/rfc8501>. [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, <https://www.rfc-editor.org/info/rfc8806>. [RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem in DNS Servers: Failure to Communicate", BCP 231, RFC 8906, DOI 10.17487/RFC8906, September 2020, <https://www.rfc-editor.org/info/rfc8906>. [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, October 2020, <https://www.rfc-editor.org/info/rfc8932>. [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, <https://www.rfc-editor.org/info/rfc8945>. [ROLL_YOUR_ROOT] Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung, T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll, Roll Your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover", DOI 10.1145/3355369.3355570, October 2019, <https://dl.acm.org/doi/10.1145/3355369.3355570>. [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS RRL)", ISC-TN-2012-1-Draft1, April 2012. [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", DOI 10.1109/SP.2015.18, May 2015, <https://doi.org/10.1109/SP.2015.18>. [TOYAMA] Toyama, K., Ishibashi, K., Toyono, T., Ishino, M., Yoshimura, C., and K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache Servers", NANOG 32, October 2004. [VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in Root Server DITL Data", DNS-OARC 2014 Fall Workshop, October 2014. [WIKIPEDIA_TFO] Wikipedia, "TCP Fast Open", February 2022, <https://en.wikipedia.org/w/index.php?title=TCP_Fast_Open&oldid=1071397204>.附录A、 与基于TCP的DNS传输相关的RFC本节列举了所有已知的 RFC，其状态为 Internet 标准、提议的标准、信息性、最佳当前实践或实验性，这些 RFC 隐含或明确地对使用 TCP 作为与本文档密切相关的 DNS 传输做出假设或陈述。A.1、 RFC 1035：域名-实施和规范Internet 标准 [RFC1035] 是基本 DNS 规范，明确定义了对基于 TCP 的 DNS 的支持。A.2、 RFC 1536：常见的 DNS 实施错误和建议的修复信息文档 [RFC1536] 指出 UDP 是“选择的通信协议，尽管 TCP 用于区域传输”。该声明现在应该在其历史背景下考虑，不再是现代期望的正确反映。A.3、 RFC 1995：DNS 中的增量区域传输提议的标准 [RFC1995] 记录了当增量区域传输 (Incremental Zone Transfer，IXFR) 响应不适合单个 UDP 响应时使用 TCP 作为回退传输。与权威传输 (Authoritative Transfer，AXFR) 一样，IXFR 消息通常在实践中默认通过 TCP 传递。A.4、 RFC 1996：区域更改提示通知机制 (DNS NOTIFY)提议的标准 [RFC1996] 建议主服务器可以决定通过 TCP 发出 NOTIFY 消息。在实践中，NOTIFY 消息通常通过 UDP 发送，但该规范留下了传输协议的选择取决于主服务器的可能性。因此，辅助服务器应该能够通过 UDP 和 TCP 运行。A.5、 RFC 2181：对 DNS 规范的澄清提议的标准 [RFC2181] 包括阐明客户端应如何对响应中设置的 TC 位作出反应的文本。建议丢弃响应并使用 TCP 重新发送查询。A.6、 RFC 2694：网络地址转换器 (DNS_ALG) 的 DNS 扩展信息文档 [RFC2694] 列举了 NAT 设备正确处理 DNS 流量的注意事项。值得注意的是，该文档的建议“[t] 通常，TCP 用于 AXFR 请求”，作为进一步的证据，有助于解释为什么 DNS over TCP 的处理方式通常与 DNS over UDP 在运营网络中的处理方式截然不同。A.7、 RFC 3225：指示 DNSSEC 的解析器支持提议的标准 [RFC3225] 声明表明基于 TCP 的 DNS 由于流量、延迟和服务器负载的增加而“有害”。本文档是 RFC 系列中的下一个文档的配套文档，该文档描述了对 DNSSEC 的 EDNS(0) 支持要求。A.8、 RFC 3226：DNSSEC 和 IPv6 A6 感知服务器/解析器消息大小要求尽管被后来的 DNSSEC RFC 更新，提议的标准 [RFC3226] 强烈主张支持 UDP 消息而不是 TCP，主要是出于性能原因。该文档声明 EDNS(0) 是 DNSSEC 服务器的一项要求，并主张在某些情况下，数据包分段可能比 TCP 更可取。A.9、 RFC 4472：IPv6 DNS 的操作注意事项和问题信息文档 [RFC4472] 指出，IPv6 数据可能会增加 DNS 响应，超出 UDP 消息的范围。特别值得一提的是，但今天可能比撰写本文档时少见的是，它指的是在不设置 TC 位的情况下截断数据以鼓励客户端使用 TCP 重新发送查询的实现。A.10、 RFC 5452：使 DNS 对伪造响应更具弹性的措施提议的标准 [RFC5452] 应运而生，因为公共 DNS 系统开始遭受来自欺骗性查询的广泛滥用，从而导致对不知情的受害者进行放大和反射攻击。[RFC5452]（“欺骗检测和对策”）的第 9.3 节简要描述了支持基于 TCP 的 DNS 以阻止这些攻击的主要理由之一。A.11、 RFC 5507：扩展 DNS 时的设计选择信息文档 [RFC5507] 主要是试图阻止新的 DNS 数据类型使 TXT 资源记录类型过载。在此过程中，它总结了 DNS 设计和实施实践的传统智慧。作者认为，与 UDP 相比，TCP 开销和有状态属性构成了挑战，并暗示 UDP 通常更适合性能和健壮性。A.12、 RFC 5625：DNS 代理实施指南Best Current Practice 文档 [RFC5625] 提供了 DNS 代理实施指南，包括要求代理“必须 [...] 准备通过 TCP 接收和转发查询”，尽管它表明，从历史上看，TCP 传输并未严格在存根解析器或递归服务器中是必需的。A.13、 RFC 5936：DNS 区域传输协议 (AXFR)提议的标准 [RFC5936] 提供了区域传输协议的详细规范，正如早期 DNS 标准中最初概述的那样。AXFR 操作仅限于 TCP，而不是为 UDP 指定。本文档详细讨论了 TCP 的使用。A.14、 RFC 7534：AS112 域名服务器操作信息文档 [RFC7534] 列举了 AS112 项目 DNS 服务器的操作要求。测试了新的 AS112 节点在 UDP 和 TCP 传输上提供服务的能力，这意味着 TCP 服务是正常操作的预期部分。A.15、 RFC 6762：组播 DNS在提议的标准 [RFC6762] 中，TC 位被认为具有与原始 DNS 规范中描述的基本相同的含义。也就是说，如果接收到设置了 TC 位的响应，“[...] 查询器应该使用 TCP 重新发出其查询，以便接收更大的响应。”A.16、 RFC 6891：DNS 的扩展机制 (EDNS(0))Internet 标准 [RFC6891] 有助于减缓 DNS-over-TCP 消息的使用和需求。本文档强调了广泛使用基于 TCP 的 DNS 时对服务器负载和可扩展性的担忧。A.17、 IAB RFC 6950：DNS 中应用程序功能的架构注意事项信息文档 [RFC6950] 提请注意 DNS 中的大数据。TCP 在上下文中被引用为一种常见的回退机制并对抗一些欺骗攻击。A.18、 RFC 7477：DNS 中的子到父同步提议的标准 [RFC7477] 指定了一个 RRType 和一个协议，以发信号通知和同步从子到父区域的 NS、A 和 AAAA 资源记录更改。由于该协议可能需要多个请求和响应，因此建议使用基于 TCP 的 DNS 来确保在一对一致的端节点之间进行对话。A.19、 RFC 7720：DNS 根名称服务协议和部署要求Best Current Practice 文档 [RFC7720] 声明根名称服务“必须支持 DNS 查询和响应的 UDP [RFC0768] 和 TCP [RFC0793] 传输”。A.20、 RFC 7766：基于 TCP 的 DNS 传输 - 实施要求提议的标准 [RFC7766] 指示 DNS 实施者为在其软件中承载 DNS-over-TCP 消息提供支持，并且可能被认为是此操作要求文档的直接祖先。实施要求文档规定了在兼容的 DNS 软件中对 DNS-over-TCP 的强制支持，但没有向运营商提供任何建议，我们在此寻求解决。A.21、 RFC 7828：edns-tcp-keepalive EDNS(0) 选项提议的标准 [RFC7828] 定义了一个 EDNS(0) 选项来协商长期 DNS-over-TCP 连接的空闲超时值。因此，本文档仅适用于和相关的 DNS-over-TCP 会话以及支持此选项的实现之间。A.22、 RFC 7858：传输层安全 (TLS) 上的 DNS 规范提议的标准 [RFC7858] 定义了一种使用 TLS 将 DNS 消息放入基于 TCP 的加密通道的方法。该规范值得注意的是明确针对存根到递归的流量，但不排除其应用从递归到权威的流量。A.23、 RFC 7873：域名系统 (DNS) Cookie提议的标准 [RFC7873] 描述了一个 EDNS(0) 选项，以提供额外的保护以防止查询和应答伪造。当 DNS cookie 不可用时，该规范提到基于 TCP 的 DNS 作为替代机制。该规范确实在两种特定情况下提到了 DNS-over-TCP 处理。一方面，当服务器在请求中仅接收到客户端 cookie 时，服务器应考虑请求是否通过 TCP 到达，如果是，则应考虑接受 TCP 足以验证请求并做出相应的响应。在另一种情况下，当客户端使用新的服务器 cookie 接收到 BADCOOKIE 回复时，客户端应使用 TCP 作为传输重试。A.24、 RFC 7901：DNS 中的链查询请求实验规范 [RFC7901] 描述了一个 EDNS(0) 选项，一个安全感知验证解析器可以使用该选项来请求和获取任何单个查询的完整 DNSSEC 验证路径。本文档要求使用基于 TCP 的 DNS 或由源 IP 地址验证的传输机制，例如 EDNS-COOKIE [RFC7873]。A.25、 RFC 8027：DNSSEC 路障规避最佳当前实践文档 [RFC8027] 详细说明了 DNSSEC 部署和缓解技术所观察到的问题。网络流量阻塞和限制，包括 DNS-over-TCP 消息，被强调为 DNSSEC 部署问题的原因之一。虽然本文档表明此类问题是由“不合规的基础设施”引起的，但该文档的范围仅限于检测和缓解技术，以避免所谓的 DNSSEC 障碍。A.26、 RFC 8094：数据报传输层安全性 (DTLS) 上的 DNS实验规范 [RFC8094] 详细说明了使用数据报传输 (UDP) 的协议，但规定“在 DTLS 上实现 DNS 的 DNS 客户端和服务器必须也通过 TLS 实现 DNS，以便为需要严格隐私的客户端提供隐私 [.. .]。”此要求意味着必须支持基于 TCP 的 DNS，以防消息大小大于路径 MTU。A.27、 RFC 8162：使用安全 DNS 将证书与 S/MIME 域名相关联实验规范 [RFC8162] 描述了一种通过 DNS 在 S/MIME 系统中验证用户 X.509 证书的技术。该文件指出，新的实验性资源记录类型预计会携带大量有效载荷，因此建议“应用程序应该使用 TCP——而不是 UDP——来执行对 SMIMEA 资源记录的查询”。A.28、 RFC 8324：DNS 隐私、授权、特殊用途、编码、字符、匹配和根结构：是时候再看看？信息文档 [RFC8324] 简要讨论了 DNS over TCP 在整个 DNS 历史中的共同作用和挑战。A.29、 RFC 8467：DNS 扩展机制的填充策略 (EDNS(0))实验文档 [RFC8467] 提醒实现者在使用 EDNS(0) 填充选项人为增加 DNS 消息大小时，在计算填充长度时考虑底层传输协议（例如 TCP）。A.30、 RFC 8482：为具有 QTYPE=ANY 的 DNS 查询提供最小大小的响应提议的标准 [RFC8482] 描述了 DNS 服务器可以响应 ANY 类型的查询的替代方式，这些查询有时用于在 DDoS 攻击中提供放大。规范指出，响应者的行为可能会有所不同，具体取决于传输方式。例如，最小大小的响应可以通过 UDP 传输使用，而完整的响应可以通过 TCP 给出。A.31、 RFC 8483：Yeti DNS 测试平台信息文档 [RFC8483] 描述了一个测试平台环境，该环境突出了一些 DNS-over-TCP 行为，包括涉及数据包分段和 TCP 流组装的操作要求的问题，以便进行 DNS 测量和分析。A.32、 RFC 8484：通过 HTTPS的 DNS 查询(DoH)提议的标准 [RFC8484] 定义了一种通过 HTTPS 发送 DNS 查询和响应的协议。本规范假设底层安全层和传输层分别使用 TLS 和 TCP。DoH 自称是一种更类似于隧道机制的技术，但在某种意义上，即使不是直接的，也可能暗示 DNS over TCP。A.33、 RFC 8490：DNS 有状态操作提议的标准 [RFC8490] 使用新的 OPCODE 更新了基本协议规范，以帮助管理持久会话中的有状态操作，例如 DNS over TCP 可能使用的那些操作。A.34、 RFC 8501：Internet 服务提供商的 IPv6 中的反向 DNS信息文档 [RFC8501] 确定了动态 DNS 的潜在运营挑战，包括拒绝服务威胁。该文档建议 TCP 可能提供一些优势，但更新主机需要明确配置为使用 TCP 而不是 UDP。A.35、 RFC 8806：运行解析器本地的根服务器信息文档 [RFC8806] 描述了如何获取和操作根区域的本地副本，并举例说明了如何使用 DNS-over-TCP 区域传输从权威来源中提取。A.36、 RFC 8906：DNS 服务器中的常见操作问题：无法通信Best Current Practice 文档 [RFC8906] 讨论了许多 DNS 操作失败场景以及如何避免它们。这包括涉及 DNS-over-TCP 查询、EDNS over TCP 和测试方法的讨论，其中包括关于验证 DNS-over-TCP 功能的部分。A.37、 RFC 8932：DNS 隐私服务运营商的建议Best Current Practice 文档 [RFC8932] 向 DNS 隐私服务运营商介绍了隐私注意事项。这些机制有时包括 TCP 的使用，因此容易受到信息泄露的影响，例如基于 TCP 的指纹识别。本文档还引用了本文档的早期草稿版本。A.38、 RFC 8945：DNS的密钥事务认证(TSIG)Internet 标准 [RFC8945] 建议客户端在收到截断的 TSIG 消息时使用 TCP。致谢本文档最初是受到学生反馈的启发，他们指出他们听到了关于过滤 DNS-over-TCP 消息的相互矛盾的信息。特别感谢一位教学同事 JPL，他可能在不知不觉中鼓励了对社区历史上所说和所做的差异的初步研究。感谢所有 NANOG 63 与会者，他们为早期讨论这个主题提供了反馈。以下人员提供了一系列反馈以帮助改进本文档：Joe Abley、Piet Barber、Sara Dickinson、Tony Finch、Bob Harold、Paul Hoffman、Geoff Huston、Tatuya Jinmei、Puneet Sood 和 Richard Wilhelm。作者还感谢 IETF 104 TCPM 工作组会议讨论所产生的贡献。任何剩余的错误或不完善之处均由文档作者承担。
-
发表了文章 2023-03-05
IPV6 的路径 MTU 发现
RFC8201：Path MTU Discovery for IP version 6，July 2017梗概本文档描述了 IPV6 的路径 MTU 发现 (Path MTU Discovery，PMTUD)。它主要源自 RFC 1191（你了解MTU和TCP MSS不？），它描述了 IPV4 的路径 MTU 发现。它已废弃 RFC 1981。本备忘录的状态这是一份 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8201。版权声明版权所有 (c) 2017 IETF Trust 和文件作者。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。本文档可能包含来自 2008 年 11 月 10 日之前发布或公开的 IETF 文档或 IETF 投稿的材料。控制本材料某些版权的人可能未授予 IETF 信托允许修改此类材料的权利在 IETF 标准流程之外。在未从控制此类材料版权的人那里获得充分许可的情况下，不得在 IETF 标准流程之外修改本文档，并且不得在 IETF 标准流程之外创建其衍生作品，除非将其格式化为作为 RFC 发布或将其翻译成英语以外的其他语言。1、 简介当一个 IPv6 节点有大量数据要发送到另一个节点时，数据以一系列 IPv6 数据包的形式传输。这些数据包的大小可以小于或等于路径 MTU (Path MTU，PMTU)。或者，它们可以是更大的数据包，被分成一系列分片，每个分片的大小小于或等于 PMTU。通常最好是这些数据包具有最大的大小，可以成功地穿过从源节点到目标节点的路径，而无需 IPv6 分片。这个数据包大小称为Path MTU，它等于一条路径中所有链路的最小链路MTU。本文档定义了一个节点发现任意路径的 PMTU 的标准机制。IPv6 节点应该实现路径 MTU 发现，以便发现和利用 PMTU 大于 IPv6 最小链路 MTU [RFC8200] 的路径。最小的 IPv6 实现（例如，在引导 ROM 中）可以选择省略路径 MTU 发现的实现。未实现路径 MTU 发现的节点必须使用 [RFC8200] 中定义的 IPv6 最小链路 MTU 作为最大数据包大小。在大多数情况下，这将导致使用比所需更小的数据包，因为大多数路径的 PMTU 大于 IPv6 最小链路 MTU。发送比 Path MTU 允许的小得多的数据包的节点正在浪费网络资源并且可能获得次优吞吐量。如果 ICMPv6 [ICMPv6] 消息被阻止或未传输，则实施路径 MTU 发现并发送大于 IPv6 最小链路 MTU 的数据包的节点很容易出现连接问题。例如，这将导致连接正确完成 TCP 三向握手，但在传输数据时会挂起。这种状态被称为黑洞连接 [RFC2923]。路径 MTU 发现依赖于 ICMPv6 数据包太大 (Packet Too Big，PTB) 来确定路径的 MTU。本文档中定义的路径 MTU 发现的扩展可以在 [RFC4821] 中找到。RFC 4821 定义了一种用于分组层路径 MTU 发现 (Packetization Layer Path MTU Discovery，PLPMTUD) 的方法，该方法设计用于在无法保证将 ICMPv6 消息传递到主机的路径上使用。注意：本文档是在 [RFC2119] 发布之前发布的 [RFC1981] 的更新。因此，尽管 RFC 1981 在大写和小写中使用了“should/must”样式语言，但本文档没有引用 RFC 2119 的定义，而仅对这些词使用小写。2、 术语node：节点，实现 IPv6 的设备。router：路由器，转发未明确寻址到自身的 IPv6 数据包的节点。host：主机，任何不是路由器的节点。upper layer：上层，紧接在 IPv6 之上的协议层。例如 TCP 和 UDP 等传输协议、ICMPv6 等控制协议、OSPF 等路由协议，以及通过（即封装在）IPv6 上“隧道化”的互联网层或较低层协议，例如互联网数据包交换 (Internetwork Packet Exchange，IPX)、AppleTalk 或 IPv6 本身。link：链路，一种通信设施或介质，节点可以在链路层（即 IPv6 紧接的层）进行通信。例如以太网（简单或桥接）；PPP链路；X.25、帧中继或 ATM 网络；互联网层或更高层的“隧道”，例如 IPv4 或 IPv6 本身的隧道。interface：接口，节点对链路的连接。address：地址，一个接口或一组接口的 IPv6 层标识符。packet：包，IPv6 报文头加上有效负载。数据包的大小可以小于或等于 PMTU。或者，这可以是一个更大的数据包，它被分成一系列分片，每个分片的大小小于或等于 PMTU。link MTU：链路 MTU，最大传输单元，即以八位字节为单位的最大数据包大小，可以在一条链路上以一个分片的形式传送。path：路径，数据包在源节点和目的节点之间经过的链路集合。path MTU：路径 MTU，源节点和目的节点之间路径中所有链路的最小链路MTU。PMTU：path MTU，路径 MTU。Path MTU Discovery：路径 MTU 发现，节点学习路径的 PMTU 的过程。EMTU_S：Effective MTU for sending，发送的有效 MTU；上层协议使用它来限制它们排队发送的 IP 数据包的大小 [RFC6691] [RFC1122]。EMTU_R：Effective MTU for receiving，接收的有效 MTU；接收端可以重组的最大数据包[RFC1122]。flow：流，从特定源发送到特定（单播或组播）目的地的数据包序列，源需要中间路由器对其进行特殊处理。flow id：流标识，源地址和非零流标签的组合。3、 协议概述本备忘录描述了一种动态发现路径 PMTU 的技术。基本思想是源节点最初假设路径的 PMTU 是路径中第一跳的（已知）MTU。如果在该路径上发送的任何数据包太大而无法被路径上的某个节点转发，则该节点将丢弃它们并返回 ICMPv6 Packet Too Big 消息。接收到这样的消息后，源节点会根据 Packet Too Big 消息中报告的收缩跳的 MTU 减少其假定的路径 PMTU。减小的 PMTU 会导致源发送更小的数据包或更改 EMTU_S 以导致上层减小它发送的 IP 数据包的大小。当源节点对 PMTU 的估计小于或等于实际 PMTU 时，路径 MTU 发现过程结束。请注意，在路径 MTU 发现过程结束之前，可能会发生数据包发送/数据包太大消息接收周期的多次迭代，因为可能存在沿路径更远的具有较小 MTU 的链路。或者，节点可以选择通过停止发送大于 IPv6 最小链路 MTU 的数据包来结束发现过程。由于路由拓扑的变化，路径的 PMTU 可能会随时间而变化。通过 Packet Too Big 消息检测 PMTU 的减少。为了检测路径 PMTU 的增加，节点周期性地增加其假定的 PMTU。这几乎总是会导致数据包被丢弃并生成 Packet Too Big 消息，因为在大多数情况下，路径的 PMTU 不会改变。因此，应该不经常尝试检测路径 PMTU 的增加。路径 MTU 发现支持组播和单播目的地。在组播目的地的情况下，数据包的副本可能经过许多不同的路径到达许多不同的节点。每条路径可能有不同的 PMTU，单个组播数据包可能会导致多个 Packet Too Big 消息，每个消息都报告不同的下一跳 MTU。正在使用的一组路径中的最小 PMTU 值决定了发送到组播目的地的后续数据包的大小。请注意，即使在节点“认为”目的地与自身连接到同一链路的情况下，也必须执行路径 MTU 发现，因为它的 PMTU 可能低于链路 MTU。在诸如相邻路由器充当某个目的地的代理 [ND] 的情况下，该目的地可能看起来是直接连接的，但实际上它不止一跳。4、 协议要求如第 1 节所述，IPv6 节点不需要实现路径 MTU 发现。本节中的要求仅适用于那些包括路径 MTU 发现的实现。节点应适当地验证 ICMPv6 PTB 消息的有效负载，以确保收到这些消息以响应每个 [ICMPv6] 传输的流量（即，与应用程序实际发送的 IPv6 数据包相对应的报告错误条件）。如果一个节点收到一个报文报告下一跳 MTU 小于 IPv6 最小链路 MTU 的 Packet Too Big 消息，它必须丢弃它。节点在收到 Packet Too Big 消息时，不得将其 Path MTU 估计值降低到 IPv6 最小链路 MTU 以下。当一个节点接收到一个 Packet Too Big 消息时，它必须根据消息中 MTU 字段的值来减少其对相关路径的 PMTU 的估计。由于不同的应用程序可能有不同的要求，并且不同的实现架构可能有不同的策略，因此没有指定在这种情况下节点的精确行为。在收到 Packet Too Big 消息后，节点必须尝试避免在不久的将来引发更多此类消息。节点必须减小它沿路径发送的数据包的大小。使用大于 IPv6 最小链路 MTU 的 PMTU 估计值可能会继续引发 Packet Too Big 消息。因为这些消息中的每一个（以及它们响应的丢弃数据包）都会消耗网络资源，所以使用路径 MTU 发现的节点必须尽快检测到 PMTU 的降低。节点可能会检测到 PMTU 的增加，但因为这样做需要发送比当前估计的 PMTU 更大的数据包，并且因为 PMTU 很可能不会增加，所以必须以不频繁的间隔进行。在收到给定路径的 Packet Too Big 消息后 5 分钟内不得尝试检测增加（通过发送大于当前估计的数据包）。此计时器的推荐设置是其最小值（10 分钟）的两倍。节点不得增加其对路径 MTU 的估计以响应 Packet Too Big 消息的内容。声称增加路径 MTU 的消息可能是在网络中漂浮的陈旧数据包、作为拒绝服务 (denial-of-service，DoS) 攻击的一部分注入的虚假数据包，或者是具有多个路径的结果到目的地，每个都有不同的 PMTU。5、 实施问题本节讨论与实现路径 MTU 发现相关的一些问题。这不是一个规范，而是为实施者提供的一组注释。这些问题包括：- 哪些层或哪些层实现路径 MTU 发现？- PMTU 信息是如何缓存的？- 如何删除陈旧的 PMTU 信息？- 传输层和更高层必须做什么？5.1、 分层在 IP 架构中，选择发送什么大小的数据包是由 IP 上一层的协议决定的。本备忘录将这样的协议称为“分组协议”。分组协议通常是传输协议（例如 TCP），但也可以是高层协议（例如，建立在 UDP 之上的协议）。在分组层实现路径 MTU 发现简化了一些层间问题，但有几个缺点：可能必须为每个分组协议重做实现，在不同分组层之间共享 PMTU 信息变得困难，以及面向连接的某些分组层维护的状态可能不容易扩展以长时间保存 PMTU 信息。因此建议 IP 层存储 PMTU 信息，并且 ICMPv6 层进程接收 Packet Too Big 消息。分组层可以通过改变它们发送的消息的大小来响应 PMTU 的变化。为了支持这种分层，分组层需要一种方法来了解 MMS_S 值的变化，即“最大发送传输消息大小”[RFC1122]。MMS_S 是通过从可以发送的最大 IP 数据包 EMTU_S 中减去 IPv6 报文头（包括 IPv6 扩展报文头）的大小来计算的传输消息大小。MMS_S 受到多种因素的限制，包括 PMTU、对数据包分片和重组的支持以及数据包重组限制（参见 [RFC8200] 的第 4.5 节“分片头”）。当源分片可用时，EMTU_S 设置为 EMTU_R，由接收器使用上层协议或基于协议要求（IPv6 为 1500 个八位字节）指示。当要传输大于 PMTU 的消息时，源会创建分片，每个分片都受 PMTU 限制。当不需要源分片时，EMTU_S 设置为 PMTU，并且上层协议预计要么执行自己的分片和重组，要么相应地限制其消息的大小。但是，鼓励分组层避免发送需要源分片的消息（关于反对分片的情况，请参阅 [FRAG]）。5.2、 存储 PMTU 信息理想情况下，PMTU 值应该与源节点和目标节点之间交换的数据包所经过的特定路径相链路。然而，在大多数情况下，节点将没有足够的信息来完全准确地识别这样的路径。相反，节点必须将 PMTU 值与路径的某些本地表示相链路。选择路径的本地表示留给实现。对于具有多个接口的节点，应为每个 IPv6 链路维护路径 MTU 信息。在组播目标地址的情况下，数据包的副本可能会经过许多不同的路径到达许多不同的节点。到组播目的地的“路径”的本地表示必须代表一组潜在的大路径。最低限度，一个实现可以维护一个单一的 PMTU 值，用于来自该节点的所有数据包。该 PMTU 值将是节点使用的所有路径集合中获知的最小 PMTU。这种方法可能会导致使用比许多路径所需的更小的数据包。在多路径路由（例如，等价多路径路由 (Equal-Cost Multipath Routing，ECMP)）的情况下，即使对于单个源和目标对，也可以存在一组路径。实现可以使用目标地址作为路径的本地表示。与目的地相链路的 PMTU 值将是通过到该目的地使用的所有路径的集合中获知的最小 PMTU。这种方法将导致在每个目的地的基础上使用最佳大小的数据包。这种方法与 [ND] 中描述的主机概念模型很好地集成：PMTU 值可以与目标缓存中的相应条目一起存储。如果流 [RFC8200] 正在使用中，则实现可以使用流 id 作为路径的本地表示。发送到特定目的地但属于不同流的数据包可能使用不同的路径，例如 ECMP，其中路径的选择可能取决于流 ID。这种方法可能会导致基于每个流使用最佳大小的数据包，提供比基于每个目标维护的 PMTU 值更精细的粒度。对于源路由数据包（即包含 IPv6 路由报文头 [RFC8200] 的数据包），源路由可以进一步限定路径的本地表示。最初，假设路径的 PMTU 值是第一跳链路的（已知）MTU。当收到 Packet Too Big 消息时，节点根据 Packet Too Big 消息的内容确定该消息适用于哪个路径。例如，如果目标地址用作路径的本地表示，则原始数据包中的目标地址将用于确定消息适用于哪个路径。注意：如果原始数据包包含路由报文头，则应使用路由报文头来确定原始数据包中目标地址的位置。如果 Segments Left 等于 0，则目标地址位于 IPv6 报文头的目标地址字段中。如果 Segments Left 大于零，则目标地址是 Routing 报文头中的最后一个地址 (Address[n])。然后，节点使用 Packet Too Big 消息中 MTU 字分片中的值作为暂定 PMTU 值或 IPv6 最小链路 MTU（如果该值较大），并将暂定 PMTU 与现有 PMTU 进行比较。如果暂定 PMTU 小于现有 PMTU 估计值，则暂定 PMTU 替换现有 PMTU 作为路径的 PMTU 值。必须通知分组层有关 PMTU 的减少。如果 PMTU 估计值降低，则必须通知正在使用该路径的任何分组层实例（例如 TCP 连接）。注意：即使 Packet Too Big 消息包含引用 UDP 数据包的 Original Packet Header，如果其任何连接使用给定路径，则必须通知 TCP 层。此外，发送引发 Packet Too Big 消息的数据包的实例应该被通知它的数据包已被丢弃，即使 PMTU 估计没有改变，以便它可以重新传输丢弃的数据。注意：实现可以通过将通知推迟到下一次尝试发送大于 PMTU 估计值的数据包来避免使用异步通知机制来降低 PMTU。在这种方法中，当尝试发送一个大于 PMTU 估计值的数据包时，SEND 函数应该失败并返回一个合适的错误指示。这种方法可能更适合无连接分组层（例如使用 UDP 的层），这（在某些实现中）可能难以从 ICMPv6 层“通知”。在这种情况下，将使用正常的基于超时的重传机制从丢弃的数据包中恢复。重要的是要理解，使用有关 PMTU 更改的路径的分组层实例的通知不同于包已被丢弃的特定实例的通知。后者应该尽快完成（即，从分组层实例的角度来看是异步的），而前者可能会延迟到分组层实例想要创建一个数据包。5.3、 清除陈旧的 PMTU 信息互联网络拓扑是动态的；路由随时间变化。虽然路径的本地表示可能保持不变，但实际使用的路径可能会发生变化。因此，节点缓存的 PMTU 信息可能会变得陈旧。如果过时的 PMTU 值太大，一旦在路径上发送了足够大的数据包，就会立即发现这一点。不存在这样的机制来实现过时的 PMTU 值太小，因此实现应该“老化”缓存值。当 PMTU 值有一段时间（大约 10 分钟）没有减小时，它应该探测以查找是否支持更大的 PMTU。注意：实现应提供更改超时持续时间的方法，包括将其设置为“无限”。例如，连接到具有大 MTU 的链路的节点，然后通过具有小 MTU 的链路连接到 Internet 的其余部分，永远不会发现新的非本地 PMTU，因此它们不必忍受每 10 分钟丢包一次。5.4、 分组层操作分组层（例如 TCP）必须将 PMTU 用于连接使用的路径；它不应发送会导致数据包大于 PMTU 的分片，除非在 PMTU 发现期间进行探测（此探测数据包不得分片到 PMTU）。一个简单的实现可以在每次创建新分片时向 IP 层询问该值，但这可能效率低下。实现通常缓存从 PMTU 派生的其他值。当 PMTU 改变时接收异步通知可能更简单，因此这些变量也可以更新。TCP 实现还必须存储从其对等方接收到的最大分片大小 (Maximum Segment Size，MSS) 值，该值表示 EMTU_R，接收方可以重组的最大数据包，并且不得发送任何大于此 MSS 的分片，无论 PMTU是多少。TCP MSS 选项中发送的值与 PMTU 无关；它由接收器重组限制 EMTU_R 确定。此 MSS 选项值由连接的另一端使用，它可能正在使用不相关的 PMTU 值。有关选择 TCP MSS 选项值的信息，请参见 [RFC8200] 的第 5 节“数据包大小问题”和第 8.3 节“最大上层有效负载大小”。收到 Packet Too Big 消息意味着发送 ICMPv6 消息的节点丢弃了一个数据包。一个可靠的上层协议会通过自己的方式检测到这种丢失，并通过其正常的重传方法来恢复它。重传可能会导致延迟，这取决于上层协议使用的丢失检测方法。如果路径 MTU 发现过程需要几个步骤来找到完整路径的 PMTU，这最终可能会使重传延迟许多往返时间。或者，可以立即响应路径 MTU 减少的通知进行重传，但仅针对 Packet Too Big 消息指定的特定连接。重传中使用的数据包大小不应大于新的 PMTU。注意：确定探测包丢失的分组层需要调整重传的分片大小。然而，使用最后一个 Packet Too Big 消息中报告的大小可能会导致进一步的丢失，因为沿路径更远的路由器可能存在较小的 PMTU 限制。这将导致丢失所有重新传输的分片，从而导致不必要的拥塞以及每次新路由器宣布较小的 MTU 时要发送的额外数据包。因此，任何使用重传的分组层也负责其重传的拥塞控制[RFC8085]。由接收到 Packet Too Big 消息指示的 PMTU 探测导致的丢失不能被视为拥塞通知，因此拥塞窗口可能不会改变。5.5、 其他传输协议的问题某些传输协议在进行重传时不允许重新分组。也就是说，一旦尝试传输某个大小的分片，传输就无法将该分片的内容拆分为更小的分片以进行重传。在这种情况下，原始分片可以在重传期间被 IP 层分片。第一次传输的后续分片不应大于路径 MTU 允许的大小。IPv4 的路径 MTU 发现 [RFC1191] 使用 NFS 作为受益于 PMTU 发现的基于 UDP 的应用程序的示例。从那时起，[RFC7530] 声明 NFS 和 IP 之间支持的传输层必须是 IETF 标准化传输协议，该协议被指定以避免网络拥塞；此类传输包括 TCP、流控制传输协议 (Stream Control Transmission Protocol，SCTP) [RFC4960] 和数据报拥塞控制协议 (Datagram Congestion Control Protocol，DCCP) [RFC4340]。在这种情况下，传输负责确保传输的分片（探测除外）符合路径 MTU，包括根据需要支持 PMTU 发现探测传输。5.6、 管理接口建议实现为系统实用程序提供一种方法：- 指定不在给定路径上进行路径 MTU 发现。- 更改与给定路径链路的 PMTU 值。前者可以通过将标志与路径相链路来完成；当在设置了此标志的路径上发送数据包时，IP 层不会发送大于 IPv6 最小链路 MTU 的数据包。这些功能可用于解决异常情况或由能够获得路径 MTU 值的路由协议实现使用。该实现还应提供一种方法来更改老化的陈旧 PMTU 信息的超时期限。6、 安全考虑这种路径 MTU 发现机制使两种 DoS 攻击成为可能，两种攻击都基于恶意方向节点发送错误的 Packet Too Big 消息。在第一次攻击中，虚假消息表明 PMTU 比实际小得多。作为响应，受害节点不应将其 PMTU 估计值设置为低于 IPv6 最小链路 MTU。错误地减少到此 MTU 的发送方将观察到次优性能。在第二次攻击中，虚假消息表明 PMTU 大于现实。如果相信，这可能会导致临时阻塞，因为受害者发送的数据包将被某些路由器丢弃。在一个往返时间内，节点会发现它的错误（从该路由器接收到 Packet Too Big 消息），但这种攻击的频繁重复可能会导致大量数据包被丢弃。但是，节点不得根据 Packet Too Big 消息提高其对 PMTU 的估计，因此它不应该容易受到这种攻击。这两种攻击都可能导致黑洞连接，即TCP三次握手正确完成，但在传输数据时连接挂起。如果恶意方可以阻止受害者接收合法的 Packet Too Big 消息，也可能会导致问题，但在这种情况下，可以使用更简单的 DoS 攻击。如果 ICMPv6 过滤阻止接收 ICMPv6 Packet Too Big 消息，则源将无法获知实际路径 MTU。“分组层路径 MTU 发现”[RFC4821] 不依赖网络对 ICMPv6 消息的支持，因此被认为比标准 PMTUD 更健壮。它不易受到 ICMPv6 消息过滤引起的“黑洞”连接的影响。有关过滤 ICMPv6 消息的建议，请参阅 [RFC4890]。7、 IANA 考虑因素本文档不需要任何 IANA 操作。8、 参考文献8.1、 规范性参考[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <http://www.rfc-editor.org/info/rfc8200>.8.2、 参考资料[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524, August 1987. [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <http://www.rfc-editor.org/info/rfc2923>. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>. [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <http://www.rfc-editor.org/info/rfc6691>. [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>. [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.附录 A、 与 RFC 1191 的比较RFC 1981（被本文档废弃）在很大程度上基于 RFC 1191，它描述了 IPv4 的路径 MTU 发现。RFC 1981 中不需要 RFC 1191 的某些部分：router specification：路由器规范，Packet Too Big 消息和相应的路由器行为在 [ICMPv6] 中定义Don't Fragment bit：不要分片位，IPv6 数据包中没有 DF 位TCP MSS discussion：TCP MSS 讨论，在 [RFC8200] 中讨论了在 TCP MSS 选项中选择要发送的值old-style messages：旧式消息，所有 Packet Too Big 消息都报告限制链路的 MTUMTU plateau tables：MTU 历史表，不需要，因为没有旧式消息附录 B、 自 RFC 1981 以来的更改本文档基于 RFC 1981，与 RFC 1981 相比有以下更改：** 在第 1 节“简介”中阐明，PMTUD 的目的是减少对 IPv6 分片的需求。** 在第 1 节“简介”中添加了有关 ICMPv6 消息被阻止时对 PMTUD 的影响的文本。** 在文档介绍中添加了“注释”，说明本规范未引用 RFC 2119，仅使用小写“应该/必须”语言。将所有大写“应该/必须”更改为小写。** 在第 1 节“简介”中添加了关于 PLPMTUD 的简短摘要以及对定义它的 RFC 4821 的引用。** 对齐第 2 节“术语”中的文本，以匹配当前的分组层术语。** 在第 4 节“协议要求”中添加了说明，即节点应根据 RFC 4443 验证 ICMP PTB 消息的有效负载，并且节点应尽快检测 PMTU 的降低。** 从第 4 节“协议要求”中删除了一个“注释”，该注释是关于报告下一跳 MTU 小于 IPv6 最小链路 MTU 的 Packet Too Big 消息，因为这已从 [RFC8200] 中删除。** 在第 5.2 节“存储 PMTU 信息”中添加了说明，如果 ICMPv6 Packet Too Big 消息包含的 MTU 小于 IPv6 最小链路 MTU，则该消息将被丢弃。** 在第 5.2 节“存储 PMTU 信息”中添加了说明，即对于具有多个接口的节点，应为每个链路存储路径 MTU 信息。** 删除了第 5.2 节“存储 PMTU 信息”中关于路由报文头类型 0 (Routing Header type 0，RH0) 的文本，因为它已被 RFC 5095 弃用。** 从第 5.2 节“存储 PMTU 信息”中删除了有关过时安全分类的文本。** 将第 5.4 节的标题更改为“分组层操作”，并更改了第一段中的文本以概括本节以涵盖所有分组层，而不仅仅是 TCP。** 澄清第 5.4 节“分组层操作”中的文本，以使用正常的分组层重传方法。** 删除了第 5.4 节“分组层操作”中描述 4.2 BSD 的文本，因为它已过时，并删除了对 TP4 的引用。** 更新了第 5.5 节“其他传输协议的问题”中关于 NFS 的文本，包括添加对 NFS 的当前引用和删除过时的文本。** 在第 6 节“安全注意事项”中添加了一段，关于未收到 PTB 消息时的黑洞连接以及与 PLPMTUD 的比较。** 更新了“致谢”。** 编辑更改。致谢我们要感谢 [RFC1191] 的作者和贡献者，本文档的大部分内容来自该文档。我们还要感谢 IPng 工作组成员的仔细审查和建设性的批评。我们还要感谢本次“IPV6 的路径 MTU 发现”更新的贡献者。这包括 6MAN 工作组的成员、地区董事会审查员、IESG，尤其是 Joe Touch 和 Gorry Fairhurst。
-
发表了文章 2023-03-05
数据中心基准测试术语
RFC8238：Data Center Benchmarking Terminology，August 2017梗概本信息文档的目的是为数据中心基准测试建立定义和描述测量技术，以及引入适用于数据中心网络设备性能评估的新术语。本文档确立了对数据中心中的网络交换机和路由器进行基准测试的重要概念，并且是测试方法文档(RFC 8239)的先决条件。这些术语和方法中的许多可能适用于超出本文档范围的网络设备，因为最初应用于数据中心的技术已部署在其他地方。本备忘录的状态本文档不是 Internet Standards Track 规范；它是为了提供信息而发布的。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。并非 IESG 批准的所有文件都适用于任何级别的互联网标准；请参阅 RFC 7841 的第 2 节。有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8238。版权声明版权所有 (c) 2017 IETF Trust 和文件作者。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。1、 简介数据中心的流量模式并不统一，并且在不断变化。它们取决于数据中心使用的应用程序的性质和种类。它们可能主要是一个数据中心的东西向流量（数据中心内的服务器到服务器）和另一个数据中心的南北向流量（从数据中心外部到服务器），而有些可能将两者结合起来。流量模式本质上可能是突发的，并且包含多对一、多对多或一对多的流量。每个流在包含 UDP 和 TCP 流量的混合时，也可能很小且对延迟敏感，或较大且对吞吐量敏感。所有这些都可以共存于单个集群中，并同时流经单个网络设备。网络设备的基准测试长期以来一直使用 [RFC1242]、[RFC2432]、[RFC2544]、[RFC2889] 和 [RFC3918]。这些基准测试主要集中在被测设备 (Device Under Test，DUT) 的各种延迟属性和最大吞吐量上。这些标准擅长测量测试条件下的理论最大吞吐量、转发速率和延迟，但它们并不代表可能影响这些网络设备的真实流量模式。涵盖的数据中心网络设备是交换机和路由器。目前，典型的数据中心组网设备具有以下特点：- 高端口密度（48 个或更多端口）。- 高速率（目前，每个端口高达 100 GB/s）。- 高吞吐量（二层和/或三层的所有端口上的线速）。- 低延迟（在微秒或纳秒范围内）。- 缓冲区空间小（在每个网络设备的 MB 范围内）。- 二层和三层转发能力（三层不是强制性的）。本文档定义了一组定义、度量和新术语，包括拥塞场景和交换机缓冲区分析，并重新定义了基本定义以表示各种流量状况。测试方法在 [RFC8239] 中定义。1.1、 需求语言关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时，本文档中的 " 将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。1.2、 定义格式- 要定义的术语（例如，“延迟”）。- 定义：该术语的具体定义。- 讨论：简要讨论该术语、其应用以及对测量程序的任何限制。- 测量单位：测量方法和用于报告相关术语测量的单位（如果适用）。2、 延迟2.1、 定义延迟是DUT传输一帧所需的时间。延迟以时间单位（秒、毫秒、微秒等）衡量。测量延迟的目的是了解在通信路径中添加设备的影响。可以在不同的事件组合之间评估延迟间隔，而不管交换设备的类型（位转发，也称为直通；或存储和转发设备）。[RFC1242] 为这些类型的设备中的每一种定义了不同的延迟。传统上，延迟测量定义是：- FILO（First In Last Out，先进后出）：从输入帧的第一位结束到达输入端口开始，到输出帧的最后一位出现在输出端口上的时间间隔。- FIFO（First In First Out，先进先出）：从输入帧的第一位的结尾到达输入端口开始，到输出帧的第一位的开始出现在输出端口上的时间间隔。位转发设备的延迟（如 [RFC1242] 中定义）使用这些事件。- LILO（Last In Last Out，后进后出）：从输入帧的最后一位到达输入端口，到输出帧的最后一位出现在输出端口的时间间隔。- LIFO（Last In First Out，后进先出）：从输入帧的最后一位到达输入端口开始，到在输出端口看到输出帧的第一位时结束的时间间隔。存储转发设备的延迟（如 [RFC1242] 中定义）使用这些事件。总结上述四个定义的另一种可能方法是引用通常出现的位的位置：输入到输出。- FILO 是 FL（First bit Last bit）。- FIFO 为 FF（First bit First bit）。- LILO 是 LL（Last bit Last bit）。- LIFO 是 LF（Last bit First bit）。如本节在数据中心交换机基准测试的上下文中所解释的，此定义代替了 RFC 1242 第 3.8 节中提供的“延迟”的先前定义，并在此处引用：对于存储和转发设备：从输入帧的最后一位到达输入端口开始，到在输出端口看到输出帧的第一个位结束的时间间隔。对于位转发设备：从输入帧的第一个位的结尾到达输入端口开始到输出帧的第一个位的开始出现在输出端口上的时间间隔。为了适应两种类型的网络设备和已经出现的两种类型的混合，根据本文档进行的交换机延迟测量必须使用 FILO 事件进行测量。FILO 将包括交换机的延迟和帧的延迟以及序列化延迟。这是通过 DUT 的“整体”延迟的图片。对于延迟敏感并且可以使用帧的初始字节运行的应用程序，可以使用 FIFO（或者，对于位转发设备，根据 RFC 1242 的延迟）。在所有情况下，必须报告延迟测量中使用的事件组合。2.2、 讨论如 2.1 节所述，FILO 是最重要的测量定义。并非所有 DUT 都专门用于直通或存储转发。数据中心 DUT 经常针对较小的数据包大小进行存储和转发，然后在特定的较大数据包大小时更改为直通行为。行为改变的数据包大小的值可能是可配置的，这取决于 DUT 制造商。FILO 涵盖了两种情况：存储转发和直通。行为变化的阈值对于基准测试并不重要，因为 FILO 涵盖了这两种可能的情况。LIFO 机制可以与存储转发交换机一起使用，但不能与直通交换机一起使用，因为它将为较大的数据包大小提供负延迟值，因为 LIFO 消除了序列化延迟。因此，在比较两个不同 DUT 的延迟时，不得使用此机制。2.3、 测量单位用于基准测试的测量方法如下：1) FILO 必须用作测量方法，因为这将包括数据包的延迟；今天，应用程序通常需要读取整个数据包来处理信息并采取行动。2) FIFO 可用于某些能够在第一位到达时处理数据的应用程序——例如，使用现场可编程门阵列 (Field-Programmable Gate Array，FPGA)。3) 不得使用 LIFO，因为与所有其他方法不同，它会减去数据包的延迟。3、 抖动3.1、 定义在数据中心的上下文中，抖动与常用术语“延迟变化”同义。它源自对单向延迟的多次测量，如 RFC 3393 中所述。“延迟变化”的强制性定义是 [RFC5481] 的第 4.2 节中定义的数据包延迟变化 (Packet Delay Variation，PDV)。当考虑一个数据包流时，所有数据包的延迟从流中所有数据包的最小延迟中减去。这有助于评估延迟变化范围 (Max - Min) 或 PDV 的高百分位数（第 99 个百分位数，用于对异常值的鲁棒性）。当 First-bit 到 Last-bit 时间戳用于延迟测量时，必须使用相同大小的数据包或帧来测量延迟变化，因为延迟的定义包括每个数据包的序列化时间。否则，如果使用 First-bit 到 First-bit，则大小限制不适用。3.2、 讨论除了 PDV 范围和/或 PDV 的高百分位数之外，[RFC5481] 的第 4.1 节中定义的包间延迟变化 (Inter-Packet Delay Variation，IPDV)（两个连续包之间的差异）可以用于确定包间隔的方式在传输过程中发生了变化——例如，查看数据包流是否变得紧密或“突发”。但是，不应使用 IPDV 的绝对值，因为这会将 IPDV 分布的“突发”和“分散”两侧“折叠”在一起。3.3、 测量单位延迟变化的测量以秒为单位表示。可以为测量的数据包群提供 PDV 直方图。4、 物理层的校准4.1、 定义物理层的校准包括定义和测量用于在 DUT 上执行测试的物理设备的延迟。它包括所有使用的物理层组件的列表，如下所示：- 用于生成流量/测量流量的设备类型。- 流量生成器上使用的线卡类型。- 流量发生器上的收发器类型。- DUT 上的收发器类型。- 电缆类型。- 电缆长度。- 流量发生器和 DUT 的软件名称和版本。- 可以提供并推荐 DUT 上启用的功能列表（尤其是在控制平面协议的情况下，例如链路层发现协议和生成树）。可以为此提供一个全面的配置文件。4.2、 讨论物理层的校准会导致端到端延迟，在评估 DUT 时应将其考虑在内。测试的物理组件的微小变化可能会影响正在测量的延迟；因此，在呈现结果时必须描述它们。4.3、 测量单位建议用于测试的所有电缆 (1) 具有相同的类型和长度，并且 (2) 尽可能来自同一供应商。必须记录第 4.1 节中列出的电缆规格以及测试结果。测试报告必须说明电缆延迟是否已从测试测量中减去。必须提供流量生成器测量的精度（对于当前的测试设备，这通常是 20 ns 范围内的值）。5、 线速5.1、 定义传输时序或最大传输数据速率由 DUT 中的“传输时钟”控制。接收时序（最大入口数据速率）来自所连接接口的发送时钟。线速或物理层帧速率是在 DUT 的传输时钟频率下发送特定大小的帧的最大容量。术语“线速的标称值”定义了给定端口的最大速度能力——例如（表示为GE千兆以太网）、1 GE、10 GE、40 GE、100 GE。任何两个连接的接口中传输时钟的频率（“时钟速率”）永远不会完全相同；因此，需要一个公差。这将由百万分率 (Parts Per Million，PPM) 值表示。IEEE 标准允许传输时钟速率有特定的 +/- 变化，而以太网的设计允许两个时钟速率之间存在小的正常变化。当流量从测试设备生成到 DUT 时，这会导致线速值的容差。线速应该以每秒帧数 (frames per second，FPS) 来衡量。5.2、 讨论对于发送时钟源，大多数以太网交换机使用密封的、内部温度补偿的、非常精确的“时钟模块”（也称为“振荡器模块”）。这些模块的输出频率是不可调节的，因为没有必要。然而，许多测试仪提供了由软件控制的传输时钟速率调整。这些调整应该用于“补偿”测试设备，以免发送超过 DUT 的线速。为了考虑到通常在商用时钟模块和其他基于晶体的振荡器的时钟速率中发现的微小变化，以太网标准规定最大传输时钟速率变化不超过计算出的中心频率的 +/- 100 PPM。因此，DUT 必须能够以 +/- 100 PPM 的速率接受帧以符合标准。很少有时钟电路精确到 +/- 0.0 PPM，因为：1. 以太网标准允许随时间变化的最大差异为 +/- 100 PPM。因此，振荡器电路的频率会随着时间和宽温度范围以及其他外部因素而发生变化是正常的。2. 晶体或时钟模块通常具有明显优于 +/- 100 PPM 的特定 +/- PPM 方差。通常，这是 +/- 30 PPM 或更好，以便被视为“认证工具”。当以“线速”测试以太网交换机吞吐量时，任何特定交换机都会有时钟速率差异。如果测试集的运行速度比被测交换机快 +1 PPM 并且执行持续的线速测试，则可以观察到延迟逐渐增加，最终随着交换机中缓冲区填充和溢出而丢包。根据两个连接的系统之间存在多少时钟差异，可能会在流量流运行几百微秒、几毫秒或几秒后看到效果。通过将测试集的链路占用率设置为略低于 100% 的链路占用率，可以证明同样的低延迟和无数据包丢失。通常，99% 的链路占用率会产生出色的低延迟并且不会丢失数据包。没有以太网交换机或路由器的传输时钟速率恰好为 +/- 0.0 PPM。很少（如果有的话）测试集的时钟频率精确到 +/- 0.0 PPM。测试设备制造商非常了解这些标准，并允许软件控制的 +/- 100 PPM“偏移”（时钟频率调整）来补偿 DUT 时钟速度的正常变化。这种偏移调整允许工程师确定所连接设备的大致运行速度，并验证它是否在标准允许的参数范围内。5.3、 测量单位“线速/Line rate”可以用“帧速率/frame rate”来衡量：Frame Rate = Transmit-Clock-Frequency / (Frame-Length*8 + Minimum_Gap + Preamble + Start-Frame Delimiter)Minimum_Gap 表示帧间间隙。此公式“放大”或“缩小”以表示 1 GB 以太网、10 GB 以太网等。具有 64 字节帧的 1 GB 以太网速度示例：Frame Rate = 1,000,000,000 / (64*8 + 96 + 56 + 8) = 1,000,000,000 / 672 = 1,488,095.2 帧/秒考虑到 +/- 100 PPM 的容差，交换机可以“合法地”以 1,487,946.4 FPS 和 1,488,244 FPS 之间的帧速率传输流量。时钟速率的每 1 PPM 变化将转化为 1.488 FPS 的帧速率增加或减少。在生产网络中，很难在很短的时间内看到精确的线速。以 99% 的线速和 100% 的线速丢弃数据包之间没有明显的区别。通过 -100 PPM 调整，可以在 100% 的线速下测量线速。线速应测量为 99.98%，调整为 0 PPM。PPM 调整应该只用于线速测量。6、 缓冲6.1、 缓冲6.1.1、 定义Buffer Size：缓冲区大小。术语“缓冲区大小”表示 DUT 上可用的帧缓冲存储器的总量。此大小以 B（bytes，字节）、KB（kilobytes，千字节）、MB（megabytes，兆字节）或 GB（gigabytes，千兆字节）表示。当表示缓冲区大小时，还需要指示用于该测量的帧 MTU（Maximum Transmission Unit，最大传输单元）以及 CoS（Class of Service，服务等级）或 DSCP（Differentiated Services Code Point，差分服务代码点）值集，通常是缓冲区是由服务质量实现来划分的。有关详细信息，请参阅 [RFC8239] 的第 3 节。示例：发送 1518 字节帧时 DUT 的 Buffer Size 为 18 MB。Port Buffer Size：端口缓冲区大小。端口缓冲区大小是单个入口端口、单个出口端口或单个端口的入口和出口缓冲位置组合的缓冲区量。我们提到端口缓冲区的三个位置，因为 DUT 的缓冲方案可能未知或未经测试，因此了解缓冲区位置有助于阐明缓冲区架构，从而了解总缓冲区大小。端口缓冲区大小是 DUT 供应商可能提供的信息值。它不是通过基准测试测试的值。基准测试将使用最大端口缓冲区大小或最大缓冲区大小方法来完成。Maximum Port Buffer Size：最大端口缓冲区大小。在大多数情况下，这与端口缓冲区大小相同。在称为“SoC”（switch on chip，片上交换机）的某种类型的交换机架构中，有一个端口缓冲区和一个可用于所有端口的共享缓冲池。最大端口缓冲区大小，就 SoC 缓冲区而言，表示端口缓冲区与该端口允许的共享缓冲区最大值之和，以 B（字节）、KB（千字节）、MB（兆字节）定义，或 GB（千兆字节）。最大端口缓冲区大小需要与用于测量的帧 MTU 以及为测试设置的 CoS 或 DSCP 位值一起表示。示例：已测量 DUT 具有 3 KB 的端口缓冲区用于 1518 字节帧，总共有 4.7 MB 的最大端口缓冲区用于 1518 字节帧，CoS 为 0。Maximum DUT Buffer Size：最大 DUT 缓冲区大小。这是可以测量 DUT 具有的总缓冲区大小。它很可能与最大端口缓冲区大小不同。它也可以不同于最大端口缓冲区大小的总和。最大缓冲区大小需要与用于测量的帧 MTU 以及测试期间设置的 CoS 或 DSCP 值一起表示。示例：已测量 DUT 具有 3 KB 的端口缓冲区用于 1518 字节帧，总共有 4.7 MB 的最大端口缓冲区用于 1518 字节帧。DUT 在 1500 B 时的最大缓冲区大小为 18 MB，CoS 为 0。Burst：突发。突发是针对定义的端口速度以一定百分比的线速发送的固定数量的数据包，发送的帧数量在间隔 T 上均匀分布。可以定义一个常数 C 来提供两个均匀间隔的连续数据包之间的平均时间。Microburst：微突发。微突发是一种突发类型，当链路或设备上没有持续或明显的拥塞时会发生丢包。微突发的一个特征是突发不均匀分布在 T 上并且小于常数 C（C = 两个均匀间隔的连续数据包之间的平均时间）。Intensity of Microburst：微突发强度。这是一个百分比，代表微突发的级别，介于 1 和 100% 之间。数字越高，微突发越高。I=[1-[ (Tp2-Tp1)+(Tp3-Tp2)+....(TpN-Tp(n-1) ] / Sum(packets)]]*100上述定义并不是要评论缓冲区的理想大小，而是要评论如何测量它。更大的缓冲区不一定更好，并且可能导致缓冲区膨胀问题。6.1.2、 讨论在 DUT 上测量缓冲时，了解每个端口的行为非常重要。这提供了交换机上可用缓冲总量的数据。缓冲区效率的术语有助于理解缓冲区的最佳数据包大小或特定数据包大小可用的缓冲区的实际容量。本节不讨论如何进行测试的方法；相反，它解释了缓冲区定义以及应为全面的数据中心设备缓冲基准测试提供哪些指标。6.1.3、 测量单位测量 DUT 缓冲器时：- 必须测量缓冲区大小。- 可以为每个端口提供端口缓冲区大小。- 必须测量最大端口缓冲区大小。- 必须测量最大 DUT 缓冲区大小。- 进行微突发测试时，可以提及微突发的强度。- 应提供测试期间设置的 CoS 或 DSCP 值。6.2、 Incast6.2.1、 定义在数据中心中非常常用的术语“Incast”是指多对一或多对多的流量模式。正如本节所定义的，它测量入口和出口端口的数量以及归因于它们的同步百分比。通常，在数据中心，它会引用许多不同的入口服务器端口（许多），将流量发送到公共上行链路（多对一）或多个上行链路（多对多）。这种模式适用于任何网络，因为许多传入端口将流量发送到一个或几个上行链路。Synchronous arrival time：同步到达时间。当两个或多个大小为 L1 和 L2 的帧到达它们各自的入口端口或多个入口端口并且 DUT 上的任何位的到达时间重叠时，则 L1 和 L2 帧具有同步到达时间。这称为“Incast”，无论模式是多对一（更简单）还是多对多。Asynchronous arrival time：异步到达时间。这是“同步到达时间”未定义的任何条件。Percentage of synchronization：同步百分比。这定义了大小为 L1、L2..Ln 的帧之间的重叠级别（位数）。示例：两个长度为 L1 和 L2 的 64 字节帧到达 DUT 的入口端口 1 和端口 2。两者之间有 6.4 字节的重叠，其中 L1 和 L2 帧同时在各自的入口端口上。因此，同步的百分比为 10%。Stateful traffic：有状态流量。有状态流量是使用有状态协议（例如 TCP）交换的数据包。Stateless traffic：无状态流量。无状态流量是使用无状态协议（如 UDP）交换的数据包。6.2.2、 讨论在这种情况下，缓冲器用于 DUT。在入口缓冲机制中，入口端口缓冲区将与虚拟输出队列（如果可用）一起使用，而在出口缓冲机制中，将使用一个传出端口的出口缓冲区。在任何一种情况下，无论缓冲存储器位于交换机架构中的哪个位置，Incast 都会创建缓冲区利用率。当一个或多个帧在 DUT 具有同步到达时间时，它们被认为正在形成 Incast。6.2.3、 测量单位必须测量入口和出口端口的数量。必须指定同步的非空百分比。7、 应用吞吐量：数据中心吞吐量7.1、 定义在数据中心网络中，平衡网络是任何给定时间最大吞吐量和最小损失的函数。这由 Goodput [TCP-INCAST] 捕获。Goodput 是应用程序级别的吞吐量。对于标准 TCP 应用程序，非常小的损失会对应用程序吞吐量产生巨大影响。[RFC2647] 提供了 Goodput 的定义；本文档中的定义是该定义的变体。Goodput 是每单位时间转发到 DUT 的正确目标接口的比特数，减去任何重新传输的比特。7.2、 讨论在数据中心基准测试中，有效产出是一个应该衡量的值。它提供了可用带宽使用的现实想法。数据中心环境的目标是最大化吞吐量，同时最小化损失。7.3、 测量单位然后通过以下公式测量 Goodput G：G = (S/F) * V Bps- S 表示有效负载字节，不包括数据包或 TCP 标头。- F 是帧大小。- V 是介质的速度，以每秒字节数为单位。示例：在 10 GB/s 介质上通过 HTTP 传输 TCP 文件。该文件不能作为单个连续流通过以太网传输。使用标准 MTU 时，必须将其分解为 1500 B 的单个帧。每个数据包需要20B的IP头信息和20B的TCP头信息；因此，每个数据包有 1460 B 可用于文件传输。基于 Linux 的系统进一步限制为 1448 B，因为它们还带有 12 B 时间戳。最后，在此示例中，数据通过以太网传输，这将每个数据包的1500 B增加26 B开销，将其增加到 1526 B。G = 1460/1526 x 10 Gbit/s, 结果是9.567 Gbit/s 或者 1.196 GB/s。请注意：此示例未考虑额外的以太网开销，例如帧间间隙（至少 96 位时间），也未考虑冲突（其影响可变，取决于网络负载）。进行 Goodput 测量时，除了第 4.1 节中列出的项目外，请记录以下信息：- 使用的 TCP 堆栈。- 操作系统版本。- 网络接口卡 (Network Interface Card，NIC) 固件版本和型号。例如，Windows TCP 堆栈和不同的 Linux 版本会影响基于 TCP 的测试结果。8、 安全考虑本备忘录中描述的基准测试活动仅限于在实验室环境中使用受控刺激进行技术表征，具有专用地址空间和上述部分中指定的约束。基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。此外，基准测试是在“黑盒”基础上执行的，仅依赖于 DUT 外部可观察到的测量值。DUT 中不应存在专门用于基准测试的特殊功能。DUT 对网络安全的任何影响在实验室和生产网络中应该是相同的。9、 IANA 考虑事项本文档不需要任何 IANA 操作。10、 参考文献10.1、 规范性参考[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>. [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8239] Avramov, L. and J. Rapp, "Data Center Benchmarking Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017, <https://www.rfc-editor.org/info/rfc8239>.10.2、 参考资料[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>. [RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, <https://www.rfc-editor.org/info/rfc2647>. [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>. [RFC3918] Stopp, D. and B. Hickman, "Methodology for IP Multicast Benchmarking", RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>. [TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, "Understanding TCP Incast and Its Implications for Big Data Workloads", April 2012, <http://yanpeichen.com/professional/usenixLoginIncastReady.pdf>.致谢作者要感谢 Al Morton、Scott Bradner、Ian Cox 和 Tim Stevenson 的评论和反馈。
-
发表了文章 2023-03-05
三层虚拟专用网络 (L3VPN) 操作和管理框架
RFC4176：Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management，October 2005本备忘录的状态本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2005)。梗概本文档为三层虚拟专用网络 (Layer 3 Virtual Private Networks，L3VPN) 的操作和管理提供了框架。该框架旨在对 L3VPN 管理解决方案设计中重要的重大技术问题进行连贯的描述。特定方法的选择以及信息模型和协议之间的选择超出了本文档的范围。1、 简介1.1、 术语在本文档中，以下术语的使用和定义如下：VPNVirtual Private Network，虚拟专用网络。一组传输和交换资源，将在共享基础架构上用于处理 (IP) 流量，这些流量表征通过此 VPN 互连的站点或场所之间的通信服务。参见 [RFC4026]。L3VPNL3VPN 基于三层地址互连多组主机和路由器。参见 [RFC4026]。VPN 实例从管理的角度来看，VPN 实例是与特定 VPN 相关的配置信息的集合，位于 PE 路由器上。VPN 站点VPN 客户的位置，通过 CE-PE 链路连接到服务提供商网络，可以访问至少一个 VPN。VPN 服务提供商 (SP)提供 VPN 相关服务的服务提供商。VPN 客户指从 VPN 服务提供商处购买 VPN 的客户。客户代理表示负责请求 VPN 客户特定信息的实体。服务水平协议（SLA）服务提供商和客户之间的合同协议，其中包括定义服务质量保证和未达到服务水平时的报偿程序的定性和定量指标。服务水平规范 (SLS)服务提供商用来管理客户服务质量水平的以内部为中心的服务性能规范。1.2、 管理功能对于任何类型的三层 VPN（基于 PE 或 CE 的 VPN），建议拥有一个可以收集和管理 VPN 相关信息的管理平台。服务和网络管理系统可以集中与 VPN 实例相关的信息，并允许用户从中心位置配置和供应每个实例。SP 必须能够管理其 VPN 服务的功能和特征。客户应该有办法确保他们订购的 VPN 服务得到履行。应尽可能支持自动化操作和与标准管理协议的互操作性。确定了两个主要的管理功能：客服管理功能：此功能为客户提供查询、配置和接收（事件/警报）客户特定 VPN 服务信息的方法。客户特定信息包括与联系人、计费、站点、接入网络、IP 地址、路由协议参数等相关的数据。它还可能包括机密数据，例如加密密钥。可以使用几种解决方案：* 专有网络管理系统* SNMP 管理器* PDP功能* 目录服务等提供者网络管理功能：此功能负责规划、构建、供应和维护网络资源，以满足提供给客户的 SLA 中概述的 VPN 服务级别协议。这主要包括（1）物理链路的建立和配置，（2）逻辑VPN服务配置的提供，以及（3）VPN服务的生命周期管理，包括VPN配置的增加、修改和删除。客户服务和供应商网络管理功能之间可能存在关系，因为供应商网络被管理以支持/实现/提供客户服务。这种关系的一个示例用途是提供 VPN-SLS 保证，以验证订购的 VPN 协议的履行情况。1.3、 参考模型ITU-T 电信管理网络具有以下通用要求结构：* 从网络角度设计、部署和管理支持服务的交换、路由和传输资源（网元管理）；* 管理部署在这些资源上的 VPN（网络管理）；* 管理 VPN 服务（服务管理）；图 1：基于 PE 的 L3VPN 管理参考模型图 2：基于 CE 的 L3VPN 管理参考模型上面，图 1 和图 2 显示了根据上述通用结构的基于 PE 和 CE 的 L3VPN 管理的参考模型。在这两种模型中，服务管理管理客户特定的属性，例如客户标识符 (Identifier，ID)、个人信息（例如姓名、地址、电话号码、信用卡号码等）、订购服务和参数、访问控制策略信息、计费和统计信息等。在基于 PE 的参考模型中，提供商网络管理器管理设备属性及其关系，涵盖 PE 设备和其他构建相应基于 PE 的 VPN 的设备。在基于 CE 的参考模型中，提供商网络管理员管理设备属性及其关系，涵盖构建相应的基于 CE 的 VPN 的 PE 和 CE 设备。负责管理 VPN 网络的网络和客户服务管理系统面临若干挑战，具体取决于它们需要管理的 VPN 网络的类型。2、 客户服务运营与管理供应商提供的服务可以从客户或供应商的角度来看待。本节从客户的角度描述服务管理，重点介绍客户管理功能。客户管理功能的目标是管理基于服务的操作，如服务订购、服务订购、激活等。客户管理功能驻留在服务管理层 (Service Management Layer，SML) 的 L3VPN 服务管理器中。它主要包括定义SP提供的L3VPN服务，收集和整合客户的L3VPN服务需求，以及为客户进行一些报告。该功能与网络管理层 (Network Management Layer，NML) 的网络管理功能相关联，用于启动 L3VPN 服务提供，并获得一些服务报告。2.1、 客户服务管理信息模型本节介绍了用于在 SML 进行 L3VPN 客户服务管理的框架。信息框架代表需要管理的数据以及它们的表示方式。在 SML，可预见的信息框架由服务水平协议 (Service Level Agreements，SLA) 和服务水平规范 (Service Level Specifications，SLS) 组成。服务通过服务水平协议 (SLA) 进行描述，服务水平协议是客户和服务提供商之间的合同文件。服务描述的技术部分称为服务水平规范 (SLS)。SLS 对不同类型的参数进行分组。有些与数据包传输的描述有关，有些与服务本身的规范有关。可以为每个接入网络连接、每个 VPN、每个 VPN 站点和/或每个 VPN 路由定义服务级别规范 (SLS)。服务提供商可以使用以下服务水平目标 (Service Level Objective，SLO) 参数至少为 SLS 定义目标和测量间隔：* QoS 和流量参数* 站点、VPN 或访问连接的可用性* 每个站点、路由或 VPN 的中断间隔持续时间* 服务激活间隔（例如，激活新站点的时间）* 故障报告响应时间间隔* 维修间隔时间* 来自站点或 (VPN) 路由的总传入/传出流量，或已通过整个 VPN 传输的总流量* 从一个站点或一个（VPN）路由，或通过整个VPN传输的不一致的传入/传出流量的测量（流量的一致性应该得到一些阐述，因为有很多方面——安全性、QoS、路由等）服务提供商和客户可以在提供商未达到（一组）SLS 性能目标的情况下协商合同处罚。应该为通过服务提供商场所和客户场所之间的分界线的传入和传出数据包定义流量参数和操作。例如，流量监管功能可以在服务提供商网络的入口处激活，而流量整形功能可以在服务提供商网络的出口处激活。2.2、 客户管理功能本节详细介绍了传统故障、配置、计费、性能和安全 (fault、configuration、accounting、performance、and security，FCAPS) 管理类别中的客户管理功能。2.2.1、 故障管理客户服务管理的故障管理功能依赖于对网络层故障信息的处理，并将事件报告给受影响的客户。此类报告应基于客户订购的 VPN 服务产品并与之相关。故障管理的客户管理功能支持包括：* 指示受故障影响的客户服务* 事件记录或日志* 测试频率* 能够从客户和提供商处调用探测* 能够在客户注意到之前发现故障2.2.2、 配置管理客户管理的配置管理功能必须能够根据提供商定义的服务模板，以客户能够指定的详细程度来配置 L3VPN 服务参数。服务模板包含在实例化时产生明确的服务要求或策略的字段。例如，IPsec 隧道 [RFC2401] 的模板将包含隧道端点、身份验证模式、加密和身份验证算法、共享密钥（如果有）和流量过滤器等字段。其他示例：基于 BGP/MPLS 的 VPN 服务模板将包含需要通过 VPN 互连的客户端等字段，而 QoS 协议模板将包含诸如单向传输延迟、包间延迟变化等字段、吞吐量和丢包阈值。2.2.3、 计费客户管理的计费管理功能提供网络层测量信息并管理该信息。客户管理负责以下计费职能：* 从 Provider Network Manager 检索计费信息* 测量的分析、存储和管理一些供应商可能需要测量信息的近实时报告，并可能将其作为客户网络管理服务的一部分提供。如果 SP 支持“动态带宽管理”服务，则执行请求的带宽分配更改所需的时间表和带宽量必须是可跟踪的，以用于监控和计费目的。解决方案应说明符合计费要求，如 [RFC2975] 的第 1.7 节所述。2.2.4、 性能管理从客户管理的角度来看，性能管理包括确定与服务级别规范的一致性级别所涉及的功能，例如 QoS 和可用性测量。目标是将计费信息与性能和故障管理信息相关联，以生成计费，该计费考虑了未满足服务水平目标的时间段内的 SLA 规定。性能信息应反映客户所感知的订购 VPN 服务的质量。该信息可以由提供商测量或由第三方控制。用于反映性能水平的参数可以在 VPN 服务协商阶段由服务提供商和客户协商并达成一致。性能管理还应支持对 L3VPN 重要方面的分析，例如带宽利用率、响应时间、可用性、QoS 统计和基于收集数据的趋势。2.2.5、 安全管理从客户管理的角度来看，安全管理功能包括保证VPN安全的管理功能。这包括设备、配置数据和访问连接的安全性。身份验证和授权（访问控制）也属于这一类。2.2.5.1、 访问控制管理访问控制确定用户对特定应用程序和网络部分的权限。如果没有这种控制，则只有数据和控制流量的安全性在其他设备或资源中受到保护（使提供 L3VPN 网络的设备不受保护）。访问控制功能保护这些设备，以确保用户只能访问他们被授权使用的资源和应用程序。2.2.5.2、 验证身份验证是验证 VPN 用户身份的过程。2.3、 客户管理功能描述本节提供了关于 SML 层的 L3VPN 管理框架架构的高级示例。目标是将第 2.2 节中描述的客户管理功能映射到架构功能块，并描述与其他 L3VPN 管理功能的通信。图 3：服务管理概述客户必须能够查看与已订购的 VPN 服务产品相关的拓扑、操作状态、订单状态和其他参数。由 SP 管理的有关 CE 设备和 L3VPN 客户属性的管理信息的所有方面都应该能够由经过身份验证的授权服务管理器进行配置和维护。客户代理应该能够动态请求更改描述服务的参数。客户应该能够从 SP 网络接收响应这些请求的响应（以必要协议的存在为模）。客户代理和 (VPN) 服务提供商之间的通信将依赖于查询/响应机制。可能无法负担管理其 CPE 的资源的客户应该能够将 VPN 的管理外包给支持网络的服务提供商。2.3.1、 L3VPN 服务产品管理希望 VPN 的部署能够满足客户的需求。因此，提供商必须有办法宣传其提供的基于 VPN 的服务。然后，潜在客户可以选择他们想要订购的服务。附加功能可能与此订购阶段相关联，例如选择与 VPN 服务交付相关的质量级别、SP 执行的 VPN 服务管理级别、安全选项等。2.3.2、 L3VPN服务订单管理该操作旨在管理客户发起的请求，并跟踪相关操作的实现状态。订单的激活取决于满足客户要求的资源的可用性以及商定的保证（请注意，这可能是客户和供应商之间谈判阶段的结果）。2.3.3、 L3VPN 服务保障客户可能需要评估与供应商签订的 SLA 履行情况的方法。因此，供应商应该监控、测量并向客户提供统计信息，假设双方就测量方法以及相应（一组）服务质量指标的规范达成一致。3、 供应商网络管理3.1、 提供商网络管理定义在一个域（或由单个 SP 管理的一组域）内实施 VPN 架构时，SP 必须能够查看 VPN 场所的物理和逻辑拓扑、VPN 运行状态、VPN 服务排序状态、 VPN 服务处理、VPN 服务激活状态以及与每个客户的 VPN 相关的其他方面。从提供商的角度来看，VPN 服务的管理主要包括：* 根据 SLA 管理客户（术语“客户”表示角色而不是最终用户，因此 SP 可能是客户）和最终用户* 管理 VPN 场所（尤其是创建、修改和删除操作，将相关信息编辑到特定链接，或监督 AAA [RFC2903] [RFC2906] 操作）* 管理 CE-PE 链路（特别是创建、修改和删除链路，编辑特定 VPN 的相关信息）* 根据支持的服务类别、流量隔离等管理服务排序，例如服务质量。目前，专有方法通常用于管理 VPN。不推荐与运营商必须使用多种专有的配置相关管理方法（例如，命令行界面 (Command Line Interface，CLI) 语言）来访问此类系统相关的额外费用，因为它会影响服务的总体成本（包括利用成本），尤其是在使用多种供应商技术（因此具有多种专业知识）来支持 VPN 服务产品时。因此，设备应提供基于标准的接口。从这个角度来看，需要研究对可能的互操作性问题和此类标准化管理接口的可用性的附加要求。3.2、 网络管理功能此外，为了满足客户的服务需求，SP可以提供内部服务。其中一些可能包括动态部署资源以支持客户可见服务的概念、可能由自动故障检测支持的客户高可用性服务以及自动切换到备用 VPN。这些是通过与提供商网络管理器的 FCAPS 功能互通来实现的。3.2.1、 故障管理Provider Network Manager 对故障管理的支持包括：* 故障检测（事件报告、警报、故障可视化）* 故障定位（分析报警报告、诊断）* 纠正措施（数据路径、路由、资源分配）由于 L3VPN 依赖于公共网络基础设施，提供商网络管理器提供了一种方法来通知服务管理器有关受基础设施故障影响的 VPN 客户的信息。提供商网络管理员应提供指向相关客户配置信息的指针，以有助于故障隔离和确定纠正措施的程序。需要检测由配置错误引起的故障，因为这些可能导致 VPN 服务失败，或不满足其他要求（例如，流量和路由隔离）。一种方法可以是一种协议，该协议系统地检查是否已考虑所有约束，并且在隧道配置过程中已强制执行一致性检查。必须提供旨在检查 VPN 内 IP 可达性的功能以用于诊断目的。必须提供旨在检查 VPN 设备配置的功能以用于诊断目的。3.2.2、 配置管理提供商网络管理器必须支持配置管理功能才能部署 VPN。为此，提供商网络管理器必须提供至少提供以下 L3VPN 组件的配置管理：PE、CE、分层隧道、访问连接、路由和 QoS，如本节所述。如果提供对 Internet 的访问，则此选项也必须是可配置的。添加或删除 VPN 客户端的配置应尽可能自动化。最后，提供商网络管理器必须确保一致且正确地提供这些设备和协议。该解决方案应提供一种检查服务订单是否正确供应的方法。这将代表一种诊断配置错误的方法。配置错误可能由多种原因引起：手动配置、入侵者攻击和冲突的服务需求。L3VPN 配置管理的要求是：* 提供商网络管理器必须支持 VPN 成员资格的配置。* 提供商网络管理器应使用 SP、L3VPN、PE、CE、分层隧道和访问连接的标识符。* PE/CE 设备之间必须配置隧道。这需要协调隧道标识符、路径、VPN 和任何相关的服务信息，例如 QoS 服务。* 必须配置在 PE 路由器和 CE 设备之间运行的路由协议。对于组播服务，组播路由协议也必须是可配置的。* PE 路由器之间以及 PE 和 P 路由器之间运行的路由协议也必须配置。仅基于 PE：* 在 PE 路由器和 CE 设备之间运行的路由协议（如果有）必须基于每个 VPN 进行配置。Provider Network Manager 必须支持为每个访问连接配置 CE 路由协议。* 基于 PE 的 L3VPN 的配置应与底层基础设施的配置相协调，包括互连 L3VPN 组件的物理层和二层网络。3.2.2.1、 提供基于路由的配置信息如果在 L3VPN 中运行 IGP，则提供商网络管理器必须提供相关参数。这包括指标、容量、QoS 能力和恢复参数。3.2.2.2、 提供基于访问的配置信息Provider Network Manager 必须在 SP 管理的 PE 和 CE 设备之间提供网络访问。3.2.2.3、 提供基于安全服务的配置信息当请求安全服务时，提供商网络管理器必须提供服务提供中涉及的实体和相关参数。例如，应该在 CE 和/或 PE 路由器上提供 IPsec 服务、隧道、选项、密钥和其他参数。在入侵检测服务的情况下，过滤和检测规则应基于 VPN 提供。3.2.2.4、 配置 VPN 资源参数服务提供商应该有一种方法来动态提供与 VPN 服务相关的资源。例如，在基于 PE 的服务中，应提供虚拟交换和转发表实例的数量和大小。如果 SP 支持“动态带宽管理”服务，则执行请求的带宽分配更改所需的日期、时间、数量和间隔可能是可追踪的，以用于计费目的。如果 SP 支持“动态带宽管理”服务，则供应系统必须能够在服务级别规范中指定的范围和界限内进行请求的更改。QoS 参数的示例是响应时间和能够为此类请求提供服务的概率。动态 VPN 资源分配对于应对客户表达的频繁更改请求（例如，加入或离开 VPN 的站点）以及实现可扩展性至关重要。PE 路由器应该能够动态分配 VPN 资源。此功能对于拨号和无线 VPN 服务尤其重要。3.2.2.5、 提供增值服务访问L3VPN 服务通过公共骨干网在一组站点之间提供受控访问。但是，许多服务提供商也提供一系列增值服务，例如：Internet 访问、防火墙服务、入侵检测、IP 电话和 IP Centrex、应用程序托管、备份等。定义不在本文档的范围内这些不同的服务是否以及如何与 VPN 服务产品交互。但是，VPN 服务应该能够提供对这些不同类型的增值服务的访问。VPN 服务应允许 SP 向客户提供普通网络运营和管理所需的各种知名 IP 服务（例如 DNS、NTP、RADIUS 等）。提供商应该能够从一台或多台服务器向多个客户提供 IP 服务。可能需要防火墙功能来限制从 Internet 访问 L3VPN [Y.1311]。尽管同一物理设备将支持多个 VPN，但可以基于每个 VPN 支持托管防火墙。在这种情况下，应在 L3VPN 的接入点提供托管防火墙。这些服务可以嵌入在 CE 或 PE 设备中，也可以在独立设备中实现。提供商网络管理器应允许客户将 IP 服务的管理外包给提供 VPN 的 SP 或第三方。管理系统应支持收集必要的信息，以响应客户的订单优化分配 IP 服务，并与支持服务的提供商提供的资源相关联。如果提供了 Internet 访问，则 SP 应可配置从/到 VPN 内的站点进出 Internet 的可访问性。配置路由策略来控制发布到 Internet 的 VPN 路由的分发可以实现这一点。3.2.2.6、 配置混合 VPN 服务还应支持互通 L3VPN 解决方案的配置，同时考虑安全性和端到端 QoS 问题。3.2.3、 计费Provider Network Manager 负责资源利用率的测量。3.2.4、 性能管理从 Provider Network Manager 的角度来看，性能管理包括监控和收集有关设备、设施和服务的性能数据的功能。Provider Network Manager 必须监控设备的行为以评估与 SLS 相关的性能指标。根据提供 SLA 的服务，可能需要不同的测量技术。示例服务是 QoS、安全、组播和临时访问。这些技术可以是侵入式的或非侵入式的，这取决于被监控的参数。提供商网络管理器还必须监控与 SLS 不直接关联的 VPN 方面，例如资源利用率、设备和传输设施的状态，以及对监控资源的控制，例如网络接入点的探测器和远程代理客户和移动用户使用。支持 L3VPN（其质量级别由 SLS 定义）的设备应具有实时性能测量，其中包含指标和阈值交叉警报。这样的阈值应该是可配置的。3.2.5、 安全管理从 Provider Network Manager 的角度来看，Provider Network Manager 的安全管理功能必须包括管理功能，以保证客户流量和控制数据的机密性，如 [RFC3809] 中所述。3.2.5.1、 认证管理提供商网络管理器必须支持对尝试访问 VPN 服务的用户进行身份验证的标准方法。可扩展性至关重要，因为游牧/移动客户端的数量正在迅速增加。为此类部署实施的身份验证方案必须可管理大量用户和 VPN 接入点。需要支持强身份验证方案，以确保 VPN 接入点到 VPN 接入点（PE 到 PE）和客户端到 VPN 接入点（CE 到 PE）通信的安全性。这对于防止 VPN 接入点 (VPN AP) 欺骗尤为重要。VPN 接入点欺骗是攻击者试图让 PE 或 CE 相信攻击者是 VPN 接入点的情况。如果攻击者成功，则设备会将 VPN 流量发送给攻击者（攻击者可以在损害机密性和/或完整性后将其转发到实际（和授予的）接入点）。换句话说，未经身份验证的 VPN AP 可以被中间人攻击欺骗，因为端点很少相互验证。一个经过弱认证的 VPN AP 可能会受到这种攻击。但是，强认证的 VPN AP 不会受到此类攻击，因为强认证算法导致中间人无法认证为真正的 AP。4、 L3VPN 设备4.1、 信息模型每个 L3VPN 解决方案都必须为 L3VPN 服务中涉及的网络元素指定管理信息（MIB、PIB、XML 模式等）。这是网络配置的基本要求。该方法应识别标准跟踪 MIB 模块中未包含的任何 L3VPN 特定信息。4.2、 沟通VPN 的部署可能跨越广泛的网络设备，可能包括来自多个供应商的设备。因此，需要通过标准的管理接口和模型来简化VPN统一网络管理视图的提供。这也将促进客户自我管理（监控）的网络设备或系统。在每当要提供新服务时都需要大量配置的情况下，出于可扩展性的原因，NMS 为相关配置操作提供高度自动化的机制是很重要的。VPN 服务的手动配置（即新站点或重新配置现有站点）可能会导致可扩展性问题，应避免。因此，网络运营商通过 NMS 系统保持对 VPN 的全貌的可见性非常重要。这应该通过使用标准跟踪协议（例如 SNMP）来实现。不推荐使用专有的命令行界面。5、 安全考虑本文档描述了 L3VPN 操作和管理的框架。尽管本文档讨论并解决了上面第 2.2.5 节和第 3.2.5 节中的一些安全问题，但它没有引入任何新的安全问题。6、 致谢特别感谢 Nathalie Charton、Alban Couturier、Christian Jacquenet 和 Harmen Van Der Linde 对文件的审阅和宝贵的建议。7、 规范性参考[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000. [RFC2906] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000. [RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [Y.1311] ITU, "Network-based IP VPN over MPLS architecture", ITU-T Y.1311.1, 2001.完整的版权声明版权所有 (C) 互联网协会 (2005)。本文档受 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 功能的资金目前由 Internet Society 提供。
-
发表了文章 2023-03-05
虚拟专用网络 (VPN) 术语
RFC4026：Provider Provisioned Virtual Private Network (VPN) Terminology，March 2005本备忘录的状态本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2005)。梗概对提供商提供的虚拟专用网络 (Virtual Private Network，VPN) 解决方案的广泛兴趣导致备忘录提出了不同且重叠的解决方案。IETF 工作组（首先是提供商提供的 VPN，后来是二层 VPN 和三层 VPN）已经讨论了这些提议和文档化规范。这导致了用于描述 VPN 服务集的部分新概念集的发展。在一定程度上，多个术语涵盖同一个概念，有时同一术语涵盖多个概念。本文档旨在使该领域的术语更加清晰和直观。1、 简介之前的 PPVPN 工作组，以及 L2VPN、L3VPN 和 PWE3 工作组已经提交了比较多的备忘录，它们都针对相同的问题空间；提供商为最终客户提供虚拟专用网络。备忘录涉及范围广泛的服务，但提议的解决方案之间也有很多共同点。这导致了用于描述这组 VPN 服务的部分新概念集的发展。在一定程度上，多个术语涵盖同一个概念，有时同一术语涵盖多个概念。本文档为 L2VPN 和 L3VPN 工作组的统一术语提供了基础。在某些情况下，PWE3 工作组中的并行概念被用作参考。2、 PPVPN 术语此列表中的概念和术语是从发送到 L2VPN 和 L3VPN 邮件列表（更早的 PPVPN 邮件列表）的 Internet 草案以及与 L2VPN 和 L3VPN 工作组相关的 RFC 中收集的。重点是特定于 PPVPN 领域的术语和概念，但这并不是严格执行的；例如，PWE3 和（通用）MPLS 领域内的一些概念和术语密切相关。我们试图找到术语和概念的最早用途。本文档旨在全面涵盖 L2VPN 和 L3VPN 工作组核心文档中的概念；即，[L3VPN-REQ]、[L2VPN-REQ]、[L3VPN-FRAME]、[L2VPN] 和 [RFC3809]。其目的是为这些文档创建一套全面统一的概念，并扩展为整个 PPVPN 领域。要做到这一点，也有必要给出该地区已经通过的一些开发概念。该文件分为四个主要部分。第 4 节列出了已经或将要指定的不同服务 第 5 节列出了用于指定这些服务的构建块 第 6 节列出了这些服务所需的功能。第 7 节列出了客户和提供商网络中使用的一些典型设备。3、 提供商提供的虚拟专用网络服务在本节中，我们定义了将服务集与 L2VPN 和 L3VPN 工作组指定的解决方案相关联的术语。包含属于 PWE3 工作组的“伪线”概念以供参考。有关提供商提供的 VPN 的要求，请参阅 [L3VPN-REQ]。所有术语和缩写都与服务的简要说明一起列出。该列表的结构是先给出更一般的信息，然后给出更具体的信息。IETF 正在为其制定解决方案的服务名称已移至列表顶部。较旧且过时的术语已被推到列表的末尾。3.1、 三层 VPN (L3VPN)L3VPN 基于三层地址互连多组主机和路由器；参见 [L3VPN-FRAME]。3.2、 二层 VPN (L2VPN)本文档描述了三种类型的 L2VPN：虚拟专用线路服务 (Virtual Private Wire Service，VPWS)（第 3.4 节）；虚拟专用 LAN 服务 (Virtual Private LAN Service，VPLS)（第 3.3 节）；和仅限 IP 的类 LAN 服务 (IP-only LAN-like Service，IPLS)（第 3.5 节）。3.3、 虚拟专用 LAN 服务 (VPLS)VPLS 是模拟传统局域网 (Local Area Network，LAN) 的全部功能的提供商服务。VPLS 使通过包交换网络 (packet switched network，PSN) 互连多个 LAN 段成为可能，并使远程 LAN 段表现为单个 LAN。有关为 VPLS 定义解决方案和协议的早期工作，请参阅 [L2VPN-REQ]、[VPLS-LDP] 和 [VPLS]。在 VPLS 中，提供商网络模拟学习网桥，并根据 MAC 地址或 MAC 地址和 VLAN 标签做出转发决策。3.4、 虚拟专线服务 (VPWS)虚拟专用线服务 (VPWS) 是连接两个客户边缘设备的点对点链路（链路）。该链路通过包交换网络建立为逻辑链路。客户网络中的 CE 通过连接链路连接到提供商网络中的 PE（参见第 6.1 节）；附件链路是物理链路或逻辑链路。核心网中的PE通过PW连接。CE 设备可以是路由器、网桥、交换机或主机。在一些实施方式中，使用一组 VPWS 来创建多站点 L2VPN 网络。[PPVPN-L2VPN] 中描述了 VPWS 解决方案的一个示例。VPWS 与 VPLS（第 3.3 节）的不同之处在于 VPLS 是点对多点，而 VPWS 是点对点。请参阅 [L2VPN]。3.5、 仅限 IP 的类 LAN 服务 (IPLS)IPLS 与 VPLS 非常相似（参见第 3.3 节），不同之处在于* 假设 CE 设备（参见第 5.1 节）是主机或路由器，而不是交换机，* 假设服务只需要携带IP包，支持ICMP、ARP等包（否则不支持不包含IP的二层包）；和* 服务仅承载 IP 数据包的假设同样适用于 IPv4 和 IPv6 数据包。虽然此服务是 VPLS 服务的功能子集，但它被单独考虑，因为它可能通过使用不同的机制来提供它，这可能允许它在某些不支持完整 VPLS 功能的硬件平台上运行 [L2VPN]。3.6、 伪线 (PW)IETF 内的 PWE3 工作组指定了伪线技术。伪线是包交换网络上的模拟点对点连接，允许使用任何 L2 技术互连两个节点。PW 与点对多点解决方案共享一些构建块和架构结构；例如，PE（参见第 5.2 节）和 CE（参见第 5.1 节）。[TRANS-MPLS] 中描述了 PW 的早期解决方案。在 [ENCAP-MPLS] 中描述了容易在 VPWS、VPLS 和 PW 中使用的封装格式。PW 的要求见 [RFC3916]，[PWE3-ARCH] 提出了 PW 的架构框架。3.7、 透明 LAN 服务 (TLS)TLS 是用于描述 VPLS 服务的早期名称。TLS 已被当前术语 VPLS 取代。3.8、 虚拟局域网 (VLAN)术语 VLAN 由 IEEE 802.1Q 指定；它定义了一种通过标记以太网帧来区分 LAN 上的流量的方法。通过扩展，VLAN 用于表示由以太网帧标记或类似机制分隔的流量。3.9、 虚拟专线服务 (VLLS)术语 VLLS 已被术语 VPWS 取代。VLLS 在一份现已过时的文档中使用，该文档旨在创建可以用来比较不同 L2VPN 解决方案的指标。该文件现已过期，工作已终止。3.10、 虚拟专用网络 (VPN)VPN 是一个通用术语，涵盖使用公共或专用网络来创建用户组，这些用户组与其他网络用户分开，并且可以在他们之间进行通信，就好像他们在专用网络上一样。可以提高分离级别（例如，通过端到端加密），但这超出了 IETF VPN 工作组章程的范围。此 VPN 定义来自 [RFC2764]。在 [L3VPN-FRAME] 中，术语 VPN 用于将一组特定的站点称为已配置为允许通信的 Intranet 或 Extranet。请注意，一个站点是至少一个 VPN 的成员，并且可能是多个 VPN 的成员。在本文档中，“VPN”也用作第 3 节中列出的所有服务的通用名称。3.11、 虚拟专用交换网络 (VPSN)术语 VPSN 已被术语 VPLS 取代。这些要求已合并到 L3VPN [L3VPN-REQ] 和 L2VPN [L2VPN-REQ] 要求中。4、 VPN的分类[RFC3809] 中使用的术语是根据下图定义的。图 1上图展示了 PPVPN 技术的分类。一些定义如下：基于 CE 的 VPN：共享服务提供商网络不了解客户 VPN 的一种 VPN 方法。此信息仅限于 CE 设备。所有 VPN 特定的过程都在 CE 设备中执行，PE 设备不知道它们正在处理的某些流量是 VPN 流量（另见 [L3VPN-FRAME]）。基于 PE 的 VPN：一种三层 VPN 方法，其中服务提供商网络用于使用共享资源互连客户站点。具体来说，PE设备维护VPN状态，将一个VPN的用户与另一个VPN的用户隔离开来。因为 PE 设备维护所有必需的 VPN 状态，所以 CE 设备的行为就像连接到专用网络一样。具体来说，基于 PE 的 VPN 中的 CE 必须不需要任何更改或附加功能即可连接到 PPVPN 而不是专用网络。PE 设备知道某些流量是 VPN 流量。它们根据数据包的目标 IP 地址转发流量（通过隧道），也可选择基于数据包 IP 标头中的其他信息。PE 设备本身就是隧道端点。隧道可以利用各种封装在 SP 网络上发送流量（例如但不限于 GRE、IP-in-IP、IPsec 或 MPLS 隧道）[L3VPN-FRAME]。虚拟路由器 (Virtual Router，VR) 样式：一种基于 PE 的 VPN 方法，其中 PE 路由器为其支持的每个 VPN 维护一个完整的逻辑路由器。每个逻辑路由器维护一个唯一的转发表并执行一个唯一的路由协议实例。这些 VPN 在 [L3VPN-VR] 中有描述。BGP/MPLS IP VPN：一种基于 PE 的 VPN 方法，其中 PE 路由器为每个 VPN 维护单独的转发环境和单独的转发表。为了在仅运行单个 BGP 实例的同时维护多个转发表实例，BGP/MPLS IP VPN 使用标识其 VPN 上下文的属性标记路由通告。这些 VPN 基于 [RFC2547bis] 中描述的方法。RFC 2547 风格：L3VPN 使用该术语来描述在信息 RFC 2547 [RFC2547] 中定义的 VPN 的扩展。该术语现在已被术语 BGP/MPLS IP VPN 取代。5. 组件从 L3VPN 规范（例如，2547 规范 [RFC2547] 和 [RFC2547bis] 以及虚拟路由器 [L3VPN-VR]）开始，开发了一种描述 VPN 解决方案中的构建块和功能分配的方法。构建块通常用于日常谈话，就好像它们是物理盒子一样，适用于所有服务。然而，由于不同的原因，这过于简单化了。任何构建块都可以在多个物理盒子上实现。这种实现的使用有多普遍超出了本文档的范围。5.1、 客户边缘设备 (CE)CE 是设备的名称，具有在客户场所访问由前 PPVPN 工作组指定的与 L3VPN [L3VPN-FRAME] 上完成的工作相关的服务所需的功能。概念已被修改；例如，当定义 L2VPN 和基于 CE 的 VPN 时。这将在本节的小节中进一步讨论。在命名 CE 设备时必须考虑两个不同的方面。可以从用于实现 CE 的设备类型开始（参见第 5.1.1 节）。也可以使用 CE 提供的服务，结果将是一组“带前缀的 CE”（参见第 5.1.2 节）。通常使用“CE”来表示任何这些设备，因为它在特定上下文中通常是明确的。5.1.1、 基于设备的 CE 命名5.1.1.1、 客户边缘路由器 (CE-R)CE-R 是客户网络中连接提供商网络的路由器。在客户网络中使用路由器的原因有很多；例如，在使用私有 IP 地址的 L3VPN 中，这是能够基于私有地址进行转发的路由器。要求在客户端使用 CE-R 的另一个原因是希望限制需要在提供商网络中学习的 MAC 地址的数量。CE-R 可用于访问 L2 和 L3 服务。5.1.1.2、 客户边缘交换机 (CE-S)CE-S 是客户网络中与提供商网络连接的服务感知 L2 交换机。在 VPWS 或 VPLS 中，不一定要在客户网络中使用路由器；二层交换机可能会很好地完成这项工作。5.1.2、 基于服务的 CE 命名下面的列表包含如何使用不同的功能来命名 CE 的示例。这种命名的例子很多，我们只介绍最常用的函数名。由于这些是功能名称，因此很可能在单个设备上存在用于多种功能的平台。例如，一个路由器可能同时是 L2VPN-CE 和 L3VPN-CE。L2VPN-CE 或 L3VPN-CE 所需的功能也可能分布在多个平台上。5.1.2.1、 L3VPN-CEL3VPN-CE 是客户端上连接到提供商提供的 L3VPN 的设备或设备组；例如，2547bis 实现。5.1.2.2、 VPLS-CEVPLS-CE 是客户端上连接到提供商提供的 VPLS 的设备或设备集。5.1.2.3、 VPWS-CEVPWS-CE 是客户端上连接到提供商提供的 VPWS 的设备或设备组。5.2、 提供商边缘设备 (PE)PE 是位于提供商网络边缘的设备或设备集的名称，具有与客户交互所需的功能。没有进一步的限定，PE 经常用于命名设备，因为它在上下文中是明确的。在命名 PE 时，我们需要考虑三个方面：它们支持的服务、服务所需的功能是否分布在多个设备上以及它们所构建的设备类型。5.2.1、 基于设备的 PE 命名路由器和交换机都可以用来实现PE；但是，缩放属性将根据选择的设备类型而完全不同。5.2.1.1、 提供商边缘路由器 (PE-R)PE-R 是一个 L3 设备，它参与 PSN（参见第 8 节）路由并根据路由信息转发数据包。5.2.1.2、 提供商边缘交换机 (PE-S)PE-S 是参与例如交换以太网的 L2 设备，该设备基于 L2 地址信息进行转发决策数据包。5.2.2、 基于服务的 PE 命名5.2.2.1、 L3VPN-PEL3VPN-PE 是位于提供商网络边缘的设备或设备集，与客户网络连接，具有 L3VPN 所需的功能。5.2.2.2、 VPWS-PEVPWS-PE 是提供商网络边缘的一个设备或一组设备，与客户网络连接，具有 VPWS 所需的功能。5.2.2.3、 VPLS-PEVPLS-PE 是位于提供商网络边缘的设备或设备集，与客户网络连接，具有 VPLS 所需的功能。5.2.3、 基于分布的 PE 命名出于扩展的原因，在 VPLS/VPWS 情况下，有时希望将 VPLS/VPWS-PE 中的功能分布在多个设备上。例如，将MAC地址学习分配在靠近客户站点的相对较小且便宜的设备上是否可行，而参与PSN信令和PE到PE隧道的建立由靠近网络核心的路由器完成。当跨设备分布功能时，需要一个协议在面向网络的 PE (N-PE)（参见第 5.2.3.1 节）和面向用户的 PE (U-PE)（参见第 5.2.3.2 节）之间交换信息。5.2.3.1、 面向网络的 PE (N-PE)N-PE 是当 VPLS-PE 分布在多个盒子上时分配信令和控制功能的设备。5.2.3.2、 面向用户的 PE (U-PE)U-PE 是在供应商网络入口处执行转发或交换决策所需的功能的设备。5.3、 核心设备5.3.1、 提供商路由器 (P)P 被定义为核心网络中没有直接面向客户的接口的路由器。因此，P 路由器不需要保持 VPN 状态并且是 VPN 不知道的。5.4、 在特定 Internet 草案中的命名5.4.1、 二层 PE (L2PE)L2PE 是提供商网络中实现 VPLS 或 VPWS 所需的 L2 功能的设备的联合名称。5.4.2、 逻辑 PE (LPE)逻辑 PE (Logical PE，LPE) 一词源于过时的 Internet 草案，“VPLS/LPE L2VPNs：使用逻辑 PE 架构的虚拟专用 LAN 服务”，用于描述供应商网络中用于实现 VPLS 的一组设备。在 LPE 中，VPLS 功能分布在小型设备（PE-Edges/U-PE）和连接到网络核心的设备（PE-Core/N-PE）上。在 LPE 解决方案中，PE-edge 和 PE-Core 可以通过交换以太网传输网络或上行链路互连。LPE 将作为单个 PE 出现在核心网络中。在本文档中，构成 LPE 的设备称为 N-PE 和 U-PE。5.4.3、 PE-CLE过期的 Internet 草案中建议的 U-PE 的替代名称“VPLS 架构”。5.4.4、 PE-核心请参阅第 5.4.2 节中此概念的起源和使用。5.4.5、 PE-边缘请参阅第 5.4.2 节中此概念的起源和使用。5.4.6、 PE-POP过期的 Internet 草案中建议的 U-PE 的替代名称“VPLS 架构”。5.4.7、 VPLS 边缘 (VE)VE 一词起源于分布式透明 LAN 服务上过时的 Internet 草案，用于描述提供商网络用于将 VPLS 移交给客户的设备。在本文档中，VE 称为 VPLS-PE。这个名字已经过时了。6、 功能在本节中，我们将一些概念和术语进行了分组，这些概念和术语必须执行才能使 VPN 服务正常工作。6.1、 连接链路 (AC)在二层 VPN 中，CE 通过连接链路 (Attachment Circuit，AC) 连接到 PE。AC 可以是物理或逻辑链路。6.2、 后门链接后门链接是由最终客户而非 SP 提供的 CE 设备之间的链接；它们可用于在多归属安排 [L3VPN-FRAME] 中互连 CE 设备。6.3、 端点发现端点发现是知道特定 VPN 服务的设备将找到属于同一服务的所有面向客户的端口的过程。[L3VPN-REQ] 中讨论了端点发现和信令的要求。这也是设计团队关于 VPN 发现活动的一份现已过时的 Internet 草案报告中的主题。6.4、 泛洪泛洪是与 L2 服务相关的功能；当 PE 接收到具有未知目标 MAC 地址的帧时，该帧将通过（泛滥）每隔一个接口发送出去。6.5、 MAC 地址学习MAC地址学习是与L2服务相关的功能；当 PE 接收到具有未知源 MAC 地址的帧时，该 MAC 地址和接口之间的关系会被学习，以便将来转发。在 L2VPN WG 的二层 VPN 解决方案中，该功能被分配给 VPLS-PE。6.5.1、 合格的学习在合格学习中，U-PE 的学习决策基于客户以太网帧的 MAC 地址和 VLAN 标签（如果存在 VLAN 标签）。如果不存在 VLAN 标记，则假定使用默认 VLAN。6.5.2、 不合格的学习在非限定学习中，学习仅基于客户以太网帧的 MAC 地址。6.6、 信令信令是背后有 VPN 的 PE 交换信息以建立 PW、PSN 隧道和隧道复用器的过程。这个过程可以通过协议自动化或通过手动配置完成。可以使用不同的协议来建立 PSN 隧道并交换隧道复用器。7、 “盒子/设备”我们列出了一组通常在支持不同类型 VPN 服务的环境中使用的设备。我们选择包含一些源自协议指定组织之外的盒子名称。7.1、 汇聚设备汇聚设备通常是不感知服务的 L2 交换机，仅用于将流量汇聚到网络中功能更丰富的点。7.2、 客户端设备 (CPE)CPE 设备是供应商放置在客户身上的盒子。它有两个目的：为客户提供可插入的端口，并使供应商能够监控与客户站点的连接。CPE 通常是功能有限的低成本盒子，并且在大多数情况下，它不知道提供商网络提供的 VPN 服务。CPE 设备不一定是分配了 CE 功能的设备，但它是提供商网络的一部分，用于监控目的。CPE 名称主要用于网络操作和部署环境，不应在协议规范中使用。7.3、 多租户单元 (MTU)MTU 通常是服务提供商放置在该服务提供商的多个客户所在的建筑物中的 L2 交换机。该术语是在 Internet 草案中引入的，该草案指定了在 [VPLS] 的上下文中在 MTU 和 PE 之间分配功能的 VPLS 解决方案。MTU 设备名称主要用于网络操作和部署上下文，不应在协议规范中使用，因为它也是用于最大传输单位的缩写。8、 包交换网络（PSN）PSN 是建立支持 VPN 服务的隧道的网络。8.1、 路由识别器 (RD)Route Distinguisher [RFC2547bis] 是一个 8 字节的值，它与 4 字节的 IPv4 地址一起标识一个 VPN-IPv4 地址族。如果两个 VPN 使用相同的 IPv4 地址前缀，PE 会将它们转换为唯一的 VPN-IPv4 地址前缀。这确保了如果在两个不同的 VPN 中使用相同的地址，则可以为该地址安装两条完全不同的路由，一个用于每个 VPN。8.2、 路由反射器路由反射器是服务提供商 (Service Provider，SP) 拥有的网络元素，用于将 BGP 路由分发到 SP 的启用 BGP 的路由器 [L3VPN-FRAME]。8.3、 路由目标 (RT)Route Target 属性 [RFC2547bis] 可以被认为是标识一组站点，或更准确地说，是一组 VRF（参见第 8.9 节）。将特定路由目标与路由相关联允许将该路由放置在用于路由从相应站点接收到的流量的所有 VRF 中。Route Target 属性也是 [RFC2547] 和 [BGP-VPN] 中使用的 BGP 扩展社区。Route Target 社区用于将 VPN 信息分发限制到 VRF 集。路由目标可以被视为识别一组站点，或更准确地说，是一组 VRF。8.4、 隧道隧道是通过 PSN 的连接，用于通过网络将流量从一个 PE 发送到另一个。隧道提供了一种将数据包从一个 PE 传输到另一个 PE 的方法。一个客户的流量与另一个客户的流量的分离是基于隧道多路复用器完成的（参见第 8.5 节）。隧道如何建立取决于 PSN 提供的隧道机制；例如，隧道可以基于 IP 报头、MPLS 标签、L2TP 会话 ID 或 GRE 密钥字段。8.5、 隧道多路复用器隧道多路复用器是一个实体，它与穿过隧道的数据包一起发送，以便确定数据包属于哪个服务实例以及从哪个发送者接收数据包。在 [PPVPN-L2VPN] 中，隧道复用器被格式化为 MPLS 标签。8.6、 虚拟隧道 (VC)VC 在隧道内传输并由其隧道复用器标识。虚拟隧道由 VCI（Virtual Channel Identifier，虚拟隧道标识符）标识。在 PPVPN 上下文中，VCI 是 VC 标签或隧道复用器，在 Martini 情况下，它等于 VCID。8.7、 VC 标签在启用 MPLS 的 IP 网络中，VC 标签是一种 MPLS 标签，用于识别属于特定 VPN 的隧道内的流量；即，VC 标签是使用 MPLS 标签的网络中的隧道复用器。8.8、 内部标签“内部标签”是 VC 标签的另一个名称（参见第 8.6 节）。8.9、 VPN 路由和转发 (VRF)在运行 2547 VPN [RFC2547] 的网络中，PE 路由器维护 VRF。VRF 是每个站点的转发表。PE 路由器所连接的每个站点都与这些表之一相关联。只有当数据包直接从与该表关联的站点到达时，才会在特定 VRF 中查找特定数据包的 IP 目标地址。8.10、 VPN 转发实例 (VFI)VPN 转发实例 (VPN Forwarding Instance，VFI) 是驻留在 PE 中的逻辑实体，包括路由器信息库和 VPN 实例的转发信息库 [L3VPN-FRAME]。8.11、 虚拟交换机实例 (VSI)在二层上下文中，VSI 是服务于单个 VPLS [L2VPN] 的虚拟交换实例。VSI 执行标准 LAN（即以太网）桥接功能。VSI 完成的转发基于 MAC 地址和 VLAN 标记，并且可能基于每个 VPLS 的其他相关信息。VSI 分配给VPLS-PE，或者在分布式情况下分配给U-PE。8.12、 虚拟路由器 (VR)虚拟路由器 (VR) 是基于软件和硬件的物理路由器仿真。虚拟路由器有独立的IP路由和转发表，相互隔离；参见 [L3VPN-VR]。9、 安全考虑这是一个术语文档，因此没有直接的安全隐患。安全注意事项将特定于解决方案、框架和规范文档，其术语在本文档中收集和讨论。10、 致谢本文档中的大部分内容都是基于 PPVPN 设计团队对“自动发现”和“l2vpn”的讨论。Dave McDysan、Adrian Farrel 和 Thomas Narten 仔细审查了该文档并提供了许多有用的建议。在从 Word 中提取可接受的版本之后，Thomas Narten 将该文档的几乎最终版本转换为 XML，这变得太痛苦了。Avri Doria 在指导我们使用 XML 方面非常有帮助。11、 参考资料[L2VPN] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work in Progress, June 2004. [L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Work in Progress, October 2004. [VPLS] Kompella, K., "Virtual Private LAN Service", Work in Progress, January 2005. [VPLS-LDP] Lasserre, M. and V. Kompella, "Virtual Private LAN Services over MPLS", Work in Progress, September 2004. [BGP-VPN] Ould-Brahim, H., Rosen, E., and Y. Rekhter, "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", Work in Progress, May 2004. [L3VPN-FRAME] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress, July 2003. [RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. [L3VPN-REQ] Carugi, M. and D. McDysan, "Service requirements for Layer 3 Virtual Private Networks", Work in Progress, July 2004. [RFC2547bis] Rosen, E., "BGP/MPLS IP VPNs", Work in Progress, October 2004. [L3VPN-VR] Knight, P., Ould-Brahim, H. and B. Gleeson, "Network based IP VPN Architecture using Virtual Routers", Work in Progress, April 2004. [PWE3-ARCH] Bryant, S. and P. Pate, "PWE3 Architecture", Work in Progress, March 2004. [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [PPVPN-L2VPN] Kompella, K., "Layer 2 VPNs Over Tunnels", Work in Progress, June 2002. [ENCAP-MPLS] Martini, L., "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", Work in Progress, September 2004. [TRANS-MPLS] Martini, L. and N. El-Aawar, "Transport of Layer 2 Frames Over MPLS", Work in Progress, June 2004. [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.完整的版权声明版权所有 (C) 互联网协会 (2005)。本文档受 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 功能的资金目前由 Internet Society 提供。
-
发表了文章 2023-03-05
边界网关协议 - 段路由的链路状态 (BGP-LS) 扩展
RFC9085：Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing，August 2021梗概段路由 (Segment Routing，SR) 允许通过将路径编码为称为“段”的拓扑子路径序列来灵活定义端到端路径。这些段由路由协议通告，例如 IGP 拓扑中的链路状态路由协议（IS-IS、OSPFv2 和 OSPFv3）。本文档定义了边界网关协议 - 链路状态 (Border Gateway Protocol - Link State，BGP-LS) 地址系列的扩展，以便通过 BGP 携带 SR 信息。本备忘录的状态这是一份 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9085。版权声明版权所有 (c) 2021 IETF Trust 和文件作者。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (https://trustee.ietf.org/license-info) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。1、 简介段路由 (SR) 允许通过组合称为“段”的子路径来灵活定义端到端路径。段可以表示任何指令：基于拓扑的或基于服务的。段可以具有对 SR 节点的局部语义或域内的全局语义。在 IGP 拓扑中，SR 路径被编码为一系列拓扑子路径，称为“IGP 段”。这些段由链路状态路由协议（IS-IS、OSPFv2 和 OSPFv3）通告。[RFC8402-SR：Segment Routing Architecture] 定义了链路状态 IGP 段——前缀、节点、任播和邻接段。根据 IGP 拓扑的状态，默认情况下，前缀段表示前缀的 ECMP 感知最短路径。邻接段表示在 IGP 中两个节点之间的特定邻接上的跳跃。前缀段通常是多跳路径，而邻接段在大多数情况下是单跳路径。节点和任播段是具有特定特征的前缀段的变体。在 IGP 域中启用 SR 时，段以段标识符 (Segment Identifiers，SID) 的形式发布。IGP 链路状态路由协议已扩展为通告 SID 和其他与 SR 相关的信息。IGP 扩展描述为：IS-IS [RFC8667]、OSPFv2 [RFC8665] 和 OSPFv3 [RFC8666]。使用这些扩展，可以在 IGP 域中启用 SR。SR 允许通告单跳或多跳路径。SR 的 IGP 扩展的泛洪范围是 IGP 区域范围的。因此，链路状态数据库（Link-State Database，LSDB）或流量工程数据库（Traffic Engineering Database，TED）的内容具有IGP区域的范围；因此，仅使用 IGP 来构建跨越多个 IGP 区域或自治系统 (Autonomous System，AS) 边界的段是不够的。为了满足需要跨 IGP 区域甚至跨 AS 的拓扑可见性的应用程序的需求，已定义 BGP-LS 地址族/子地址族以允许 BGP 携带链路状态信息。BGP-LS 的 BGP 网络层可达性信息 (Network Layer Reachability Information，NLRI) 编码格式和称为“BGP-LS 属性”的新 BGP 路径属性在 [RFC7752] 中定义。每个链路状态对象的标识键，即节点、链路或前缀，编码在 NLRI 中，对象的属性编码在 BGP-LS 属性中。图 1：链路状态信息收集图 1 表示一个典型的部署场景。在每个 IGP 区域中，一个或多个节点都配置了 BGP-LS。这些 BGP 扬声器通过连接到一个或多个路由反射器形成内部 BGP (Internal BGP，IBGP) 网格。这样，所有 BGP 发言者（特别是路由反射器）从所有 IGP 区域（以及来自外部 BGP (External BGP，EBGP) 对等方的其他 AS）获取链路状态信息。如 [RFC7752] 中所述，外部组件连接到路由反射器以获取此信息（可能由有关向外部组件发布或不发布哪些信息的策略调节）。本文档描述了对 BGP-LS 的扩展以通告 SR 信息。外部组件（例如，控制器）可以跨 SR 域收集 SR 信息（如 [RFC8402] 中所述）并构建需要应用于传入数据包的端到端路径（及其关联的 SID）以实现所需的端到端转发。SR 在由单个 AS 或由同一管理实体管理的多个 AS 组成的受信任域内运行，例如，在单个提供商网络内。1.1、 需求语言关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时，本文档中的 " 将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。2、 用于段路由的 BGP-LS 扩展本文档定义了 BGP-LS 的 SR 扩展，并指定了用于在 BGP-LS 属性中通告 SR 信息的 TLV 和子 TLV。2.4 和 2.5 节列出了 IS-IS、OSPFv2 和 OSPFv3 协议中的等效 TLV 和子 TLV。BGP-LS [RFC7752] 定义了 BGP-LS NLRI，它可以是节点 NLRI、链路 NLRI 或前缀 NLRI，它定义了将链路状态信息映射到 BGP-LS 属性中的 BGP-LS NLRI 的 TLV .本文档添加了额外的 BGP-LS 属性 TLV，以便对 SR 信息进行编码。它不会对 BGP-LS NLRI 的编码进行任何更改。2.1、 节点属性 TLV定义了以下节点属性 TLV：表 1：节点属性 TLV这些 TLV 应该只添加到与节点 NLRI 关联的 BGP-LS 属性中，该节点描述了 IGP 节点，该 IGP 节点发起了下面描述的相应 IGP TLV/子 TLV。2.1.1、 SID/标签 TLVSID/标签 TLV 被 SR 能力（第 2.1.2 节）和段路由本地块（SRLB）（第 2.1.4 节）TLV 用作子 TLV。此信息来自协议特定的通告。* IS-IS，由 [RFC8667] 的第 2.3 节中的 SID/标签子 TLV 定义。* OSPFv2/OSPFv3，由 [RFC8665] 第 2.1 节和 [RFC8666] 第 3.1 节中的 SID/Label Sub-TLV 定义。TLV 具有以下格式：图 2：SID/标签 TLV 格式在这里：Type：类型，1161Length：长度，可变。3 或 4 个八位字节，具体取决于值是编码为标签还是索引/SID。SID/Label：如果长度设置为3，那么最右边20位代表一个标签（TLV总大小为7），最左边4位设置为0。如果长度设置为4，那么值表示一个 32 位的 SID（总 TLV 大小为 8）。2.1.2、 SR 能力 TLVSR Capabilities TLV 用于通告节点的 SR 能力，包括其段路由全局库 (Segment Routing Global Base，SRGB) 范围。对于 IS-IS，这些能力还包括对 SR-MPLS 转发平面的 IPv4 和 IPv6 支持。此信息来自协议特定的通告。* IS-IS，由 [RFC8667] 第 3.1 节中的 SR-Capabilities Sub-TLV 定义。* OSPFv2/OSPFv3，由 [RFC8665] 第 3.2 节中的 SID/标签范围 TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。SR Capabilities TLV 具有以下格式：图 3：SR 功能 TLV 格式在这里：Type：类型，1034Length：长度，可变。最小长度为 12 个八位字节。Flags：标志，1 个八位字节的标志，如 [RFC8667] 的第 3.1 节中为 IS-IS 定义的。目前没有为 OSPFv2 和 OSPFv3 定义标志，必须设置为 0 并在收到时忽略。Reserved：保留，1 个八位字节，必须设置为 0 并在接收时忽略。一个或多个条目，每个条目的格式如下：Range Size：范围大小，3 个八位字节，非零值指示范围内的标签数量。SID/Label TLV：（定义见第 2.1.1 节）用作子 TLV，对范围内的第一个标签进行编码。由于 SID/Label TLV 用于指示 SRGB 范围的第一个标签，因此在 SR Capabilities TLV 下只有标签编码有效。2.1.3、 SR 算法 TLVSR-Algorithm TLV 用于通告节点支持的 SR 算法。此信息来自协议特定的通告。* IS-IS，由 [RFC8667] 第 3.2 节中的 SR-Algorithm Sub-TLV 定义。* OSPFv2/OSPFv3，由 [RFC8665] 第 3.1 节中的 SR 算法 TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。SR 算法 TLV 具有以下格式：图 4：SR 算法 TLV 格式在这里：Type：类型，1035Length：长度，可变。最小长度为 1 个八位字节，最大长度为 256。Algorithm：算法，一个或多个字段，每个字段为 1 个八位字节，用于标识算法。2.1.4、 SR 本地块 TLVSRLB TLV 包含节点为本地 SID 保留的标签范围。本地 SID 用于，例如，在 IGP（IS-IS，OSPF）中用于邻接 SID，也可以由 IGP 协议以外的组件分配。例如，应用程序或控制器可以指示节点分配特定的本地 SID。因此，为了让此类应用程序或控制器知道可用的本地 SID 的范围，节点需要通告其 SRLB。此信息来自协议特定的通告。* IS-IS，由 [RFC8667] 第 3.3 节中的 SRLB Sub-TLV 定义。* OSPFv2/OSPFv3，由 [RFC8665] 第 3.3 节中的 SR 本地块 TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。SRLB TLV 具有以下格式：图 5：SRLB TLV 格式在这里：Type：类型，1036Length：长度，可变。最小长度为 12 个八位字节。Flags：标志，1 个八位字节的标志。这些标志在 [RFC8667] 的第 3.3 节中为 IS-IS 定义。目前没有为 OSPFv2 和 OSPFv3 定义标志，必须设置为 0 并在收到时忽略。Reserved：保留，1 个八位字节，必须设置为 0 并在接收时忽略。对应于子范围的一个或多个条目，每个条目具有以下格式：Range Size：范围大小，3 个八位字节的值，指示范围内的标签数量。SID/Label TLV：（定义见第 2.1.1 节）用作子 TLV，对子范围中的第一个标签进行编码。由于 SID/Label TLV 用于指示 SRLB 子范围的第一个标签，因此在 SR Local Block TLV 下只有标签编码有效。2.1.5、 SRMS 优先级 TLV段路由映射服务器 (Segment Routing Mapping Server，SRMS) 优先级 TLV 用于将优先级与来自特定源的 SRMS 通告相关联。[RFC8661] 指定 SRMS 功能以及通告 SRMS 前缀到 SID 映射范围的节点的 SRMS 优先级。此信息来自协议特定的通告。* IS-IS，由 [RFC8667] 的第 3.4 节中的 SRMS Preference Sub-TLV 定义。* OSPFv2/OSPFv3，由 [RFC8665] 第 3.4 节中的 SRMS Preference TLV 定义。OSPFv3 利用为 OSPFv2 定义的相同 TLV。SRMS 优先级 TLV 具有以下格式：图 6：SRMS 优先级 TLV 格式在这里：Type：类型，1037Length：长度，1 个八位字节Preference：优先级，1 个八位字节，携带无符号 8 位 SRMS 优先级。2.2、 链路属性 TLV定义了以下链路属性 TLV：表 2：链路属性 TLV这些 TLV 应该只添加到与 Link NLRI 关联的 BGP-LS 属性，该属性描述了 IGP 节点的链路，该 IGP 节点发起了下面描述的相应 IGP TLV/sub-TLV。2.2.1、 邻接 SID TLV邻接 SID TLV 用于通告与邻接 SID 相关的信息。该信息来源于 IS-IS 的 Adj-SID Sub-TLV（[RFC8667] 的第 2.2.1 节）、OSPFv2（[RFC8665] 的第 6.1 节）和 OSPFv3（[RFC8666] 的第 7.1 节）。邻接 SID TLV 具有以下格式：图 7：邻接 SID TLV 格式在这里：Type：类型，1099Length：长度，可变。7 或 8 个八位字节，具体取决于 SID 的标签或索引编码。Flags：标志，应设置为 1 个八位字节的值：* [RFC8667] 第 2.2.1 节中定义的 IS-IS Adj-SID 标志。* [RFC8665] 第 6.1 节中定义的 OSPFv2 Adj-SID 标志。* [RFC8666] 第 7.1 节中定义的 OSPFv3 Adj-SID 标志。Weight：权重，1 个八位字节承载用于负载平衡目的的权重。[RFC8402] 的第 3.4 节描述了权重的使用。Reserved：保留，必须设置为 0 并在接收时忽略的 2 个八位字节。SID/索引/标签：IS-IS：[RFC8667] 第 2.2.1 节中定义的标签或索引值。OSPFv2：[RFC8665] 第 6.1 节中定义的标签或索引值。OSPFv3：[RFC8666] 第 7.1 节中定义的标签或索引值。该 TLV 的标志和作为扩展的 SID/索引/标签字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Link NLRI 的 Protocol-ID 用于确定解析这些字段的底层协议规范。2.2.2、 LAN 邻接 SID TLV对于 LAN，节点通常只宣布与 IS-IS 伪节点（或等效的 OSPF 指定和备份指定路由器）的邻接关系。LAN 邻接 SID TLV 允许节点在 BGP-LS 链路 NLRI 的单个实例中向连接到 LAN 的所有其他节点宣布邻接关系。如果没有此 TLV，则需要为每个附加邻接创建相应的 BGP-LS 链路 NLRI，以便为这些邻接邻接通告 SR TLV。该信息来源于 IS-IS 的 LAN-Adj-SID Sub-TLV（[RFC8667] 的第 2.2.2 节）、OSPFv2 的 LAN Adj-SID Sub-TLV（[RFC8665] 的第 6.2 节）和OSPFv3 的 LAN Adj-SID Sub-TLV（[RFC8666] 的第 7.2 节）。LAN 邻接 SID TLV 具有以下格式：图 8：LAN 邻接 SID TLV 格式在这里：Type：类型，1100Length：长度，可变。对于 IS-IS，它将是 13 或 14 个八位字节，具体取决于 SID 的标签或索引编码。对于 OSPF，它将是 11 或 12 个八位字节，具体取决于 SID 的标签或索引编码。Flags：标志，应设置为 1 个八位字节的值：* [RFC8667] 第 2.2.2 节中定义的 IS-IS LAN Adj-SID 标志。* [RFC8665] 第 6.2 节中定义的 OSPFv2 LAN Adj-SID 标志。* [RFC8666] 第 7.2 节中定义的 OSPFv3 LAN Adj-SID 标志。Weight：权重，1 个八位字节承载用于负载平衡目的的权重。[RFC8402] 的第 3.4 节描述了权重的使用。Reserved：保留，必须设置为 0 并在接收时忽略的 2 个八位字节。Neighbor ID：邻居 ID，IS-IS 的 6 个八位字节用于系统 ID，OSPF 的 4 个八位字节用于邻居的 OSPF Router-ID。SID/索引/标签：IS-IS：[RFC8667] 第 2.2.2 节中定义的标签或索引值。OSPFv2：[RFC8665] 第 6.2 节中定义的标签或索引值。OSPFv3：[RFC8666] 第 7.2 节中定义的标签或索引值。该 TLV 的邻居 ID、标志以及作为扩展的 SID/索引/标签字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Link NLRI 的 Protocol-ID 用于确定解析这些字段的底层协议规范。2.2.3、 L2 捆绑成员属性 TLVL2 Bundle Member Attributes TLV 标识 L2 Bundle Member 链路，该链路又与父 L3 链路相关联。L3 链路由 [RFC7752] 中定义的 Link NLRI 描述，L2 Bundle Member Attributes TLV 与 Link NLRI 相关联。TLV 可以包括描述与捆绑成员相关的属性的子 TLV。标识的捆绑成员表示从始发路由器到父 L3 链路中指定的邻居的单向路径。多个 L2 捆绑成员属性 TLV 可以与一个链路 NLRI 相关联。此信息源自 IS-IS 的 L2 捆绑成员属性 TLV（[RFC8668] 的第 2 节）。尚未为 OSPF 指定等效功能。L2 Bundle Member Attributes TLV 具有以下格式：图 9：L2 捆绑成员属性 TLV 格式在这里：Type：类型，1172Length：长度，可变。L2 Bundle Member Descriptor：4 字节字段，携带 [RFC4202] 中定义的链路本地标识符。L2 Bundle Member 链路的链路属性作为 L2 Bundle Member Attributes TLV 的子 TLV 进行通告。子 TLV 与下表中标识的现有 BGP-LS TLV 相同。表 3：BGP-LS 属性 TLV 也用作 L2 Bundle Member Attributes TLV 的子 TLV2.3、 前缀属性 TLV定义了以下前缀属性 TLV：表 4：前缀属性 TLV这些 TLV 应该只添加到与前缀 NLRI 关联的 BGP-LS 属性，该前缀描述了 IGP 节点的前缀，该 IGP 节点发起了下面描述的相应 IGP TLV/子 TLV。2.3.1、 前缀 SID TLVPrefix-SID TLV 用于通告与 Prefix-SID 相关的信息。该信息来源于 IS-IS 的 Prefix-SID Sub-TLV（[RFC8667] 第 2.1 节）、OSPFv2 的 Prefix-SID Sub-TLV（[RFC8665] 第 5 节）和 Prefix-SID Sub-TLV。OSPFv3 的 TLV（[RFC8666] 第 6 节）。Prefix-SID TLV 具有以下格式：图 10：前缀 SID TLV 格式在这里：Type：类型，1158Length：长度，可变。7 或 8 个八位字节，具体取决于 SID 的标签或索引编码。Flags：标志，应设置为 1 个八位字节的值：* [RFC8667] 第 2.1.1 节中定义的 IS-IS Prefix-SID 标志。* [RFC8665] 第 5 节中定义的 OSPFv2 Prefix-SID 标志。* [RFC8665] 第 6 节中定义的 OSPFv3 Prefix-SID 标志。Algorithm：算法，1 字节值标识算法。该算法的语义在 [RFC8402] 的第 3.1.1 节中描述。Reserved：保留，必须设置为 0 并在接收时忽略的 2 个八位字节。SID/索引/标签：IS-IS：[RFC8667] 第 2.1 节中定义的标签或索引值。OSPFv2：[RFC8665] 第 5 节中定义的标签或索引值。OSPFv3：[RFC8666] 第 6 节中定义的标签或索引值。该 TLV 的标志和作为扩展的 SID/索引/标签字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Prefix NLRI 的 Protocol-ID 用于确定解析这些字段的底层协议规范。2.3.2、 前缀属性标志 TLVPrefix Attribute Flags TLV 携带 IPv4/IPv6 前缀属性标志信息。这些标志在 [RFC7684] 的第 2.1 节中为 OSPFv2、[RFC5340] 的附录 A.4.1.1 中的 OSPFv3 和 [RFC7794] 的第 2.1 节中的 IS-IS 定义。前缀属性标志 TLV 具有以下格式：图 11：前缀属性标志 TLV 格式在这里：Type：类型，1170Length：长度，可变。Flags：可变长度的Flag字段（根据Length字段）。标志是特定于路由协议的，设置如下：* IS-IS 标志对应于 [RFC7794] 第 2.1 节中定义的 IPv4/IPv6 扩展可达性属性标志。在 X-flag 与 IPv6 前缀可达性相关联的情况下，该设置对应于 IS-IS TLV 236 [RFC5308] 和 237 [RFC5120] 的固定格式中的 X-flag 设置。* OSPFv2 标志对应于 [RFC7684] 第 2.1 节中定义的 OSPFv2 扩展前缀 TLV 的标志字段。* OSPFv3 标志映射到 [RFC5340] 的附录 A.4.1.1 中定义并在 [RFC8362] 的第 3.1 节中扩展的前缀选项字段。此 TLV 的标志字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Prefix NLRI 的 Protocol-ID 用于确定解析该字段的底层协议规范。2.3.3、 源路由器标识符 TLV源路由器标识符 TLV 包含前缀发起者的 IPv4 或 IPv6 路由器标识符。对于 IS-IS 协议，这是从 [RFC7794] 的第 2.2 节中定义的 IPv4/IPv6 源路由器 ID 子 TLV 派生的。对于 OSPF 协议，这是从 [RFC9084] 的第 2.2 节中定义的前缀源路由器地址子 TLV 派生的。源路由器标识符 TLV 具有以下格式：图 12：源路由器标识符 TLV 格式在这里：Type：类型，1171Length：长度，可变。IPv4 或 IPv6 前缀分别为 4 或 16 个八位字节。Router-ID：IS-IS 的 IPv4 或 IPv6 Router-ID，OSPF 的 IPv4 或 IPv6 Router Address。2.3.4、 源 OSPF 路由器 ID TLVSource OSPF Router-ID TLV 仅适用于 OSPF 协议，包含前缀发起者的 OSPF Router-ID。它源自 [RFC9084] 的第 2.1 节中定义的前缀源 OSPF 路由器 ID 子 TLV。源 OSPF 路由器 ID TLV 具有以下格式：图 13：源 OSPF 路由器 ID TLV 格式在这里：Type：类型，1174Length：长度，4 个八位字节OSPF Router-ID：产生前缀的节点的 OSPF Router-ID。2.3.5、 范围 TLVRange TLV 用于宣传一系列前缀到 SID 的映射，作为 SRMS 功能 [RFC8661] 的一部分，如相应的基础 IGP SR 扩展中所定义：[RFC8665] 第 4 节，[RFC8666] 第 5 节 ] 和 [RFC8667] 的第 2.4 节。Range TLV 中通告的信息在 IS-IS 的情况下来自 SID/标签绑定 TLV，在 OSPFv2/OSPFv3 的情况下来自 OSPFv2/OSPFv3 扩展前缀范围 TLV。只有当还有一个 IGP 度量 TLV (TLV 1095) 关联时，前缀 NLRI 才被认为是一个正常的路由前缀（即前缀可达性）。否则，它仅被视为前缀到 SID 映射通告范围内的第一个前缀。Range TLV 的格式如下：图 14：范围 TLV 格式在这里：Type：类型，1159Length：长度，可变。11 或 12 个八位字节，具体取决于 SID 的标签或索引编码。Flags：标志，应设置为 1 个八位字节的值：* [RFC8667] 第 2.4.1 节中定义的 IS-IS SID/标签绑定 TLV 标志。* OSPFv2 OSPF 扩展前缀范围 TLV 标志如 [RFC8665] 第 4 节中定义。* [RFC8666] 第 5 节中定义的 OSPFv3 扩展前缀范围 TLV 标志。Reserved：保留，1 个八位字节，必须设置为 0 并在接收时忽略。Range Size：范围大小，2 个八位字节，携带通告覆盖的前缀数量。此 TLV 的标志字段根据各自的底层 IS-IS、OSPFv2 或 OSPFv3 协议进行解释。BGP-LS Prefix NLRI 的 Protocol-ID 用于确定解析该字段的底层协议规范。前缀到 SID 的映射使用子 TLV 进行通告，如下所示：IS-IS：SID/标签范围 TLV 前缀 SID 子 TLVOSPFv2/OSPFv3：OSPFv2/OSPFv3 扩展前缀范围 TLV 前缀 SID 子 TLVBGP-LS：范围 TLV Prefix-SID TLV（在此上下文中用作子 TLV）BGP-LS Prefix-SID TLV（在此上下文中用作子 TLV）的前缀到 SID 映射信息按照第 2.3.1 节中的描述进行编码。2.4、 等效 IS-IS 段路由 TLV/子 TLV本节说明映射到本文档中定义的 IS-IS 段路由扩展 TLV 和子 TLV。对于每个 BGP-LS TLV，下表说明了它在 IS-IS 中的等效性。表 5：IS-IS 段路由扩展 TLV/子 TLV2.5、 等效 OSPFv2/OSPFv3 段路由 TLV/子 TLV本节说明 OSPFv2 和 OSPFv3 段路由扩展 TLV 和子 TLV 映射到本文档中定义的 TLV。对于每个 BGP-LS TLV，下表说明了它在 OSPFv2 和 OSPFv3 中的等效性。表 6：OSPFv2 段路由扩展 TLV/子 TLV表 7：OSPFv3 段路由扩展 TLV/子 TLV3、 IANA 考虑事项IANA 已根据表 8 在“边界网关协议 - 链路状态 (BGP-LS) 参数”注册表下的“BGP-LS 节点描述符、链路描述符、前缀描述符和属性 TLV”注册表中注册了以下代码点。注册表中定义的“IS-IS TLV/Sub-TLV”列不需要任何值，应留空。3.1、 TLV/Sub-TLV 代码点汇总本节包含本文档中定义的所有 TLV/子 TLV 的全局表。表 8：TLV/Sub-TLV 代码点汇总4、 可管理性考虑本节的结构按照 [RFC5706] 中的建议进行。本文档中引入的新协议扩展扩充了通过 [RFC7752] 分发的现有 IGP 拓扑信息。本文档中定义的程序和协议扩展不影响 BGP 协议的操作和管理，除非在 [RFC7752] 的可管理性考虑部分中讨论。具体来说，[RFC7752] 的故障管理部分中用于语法检查的格式错误的属性测试现在包含本文档中定义的新 BGP-LS 属性 TLV。本文档中指定的 TLV 的语义或内容检查以及它们与 BGP-LS NLRI 类型或其 BGP-LS 属性的关联留给 BGP-LS 信息的消费者（例如，应用程序或控制器），而不是BGP协议。BGP-LS 信息的消费者通过 BGP-LS 会话检索此信息（请参阅 [RFC7752] 的第 1 节和第 2 节）。消费者对语义或内容错误的处理将取决于其应用程序使用的性质，因此超出了本文档的范围。本文档仅介绍了新的属性 TLV，其中的任何语法错误都会导致 BGP-LS 属性被丢弃并显示错误日志。本规范在 BGP-LS 中引入的 SR 信息可以被 BGP-LS 消费者应用程序使用，例如 SR 路径计算引擎 (Path Computation Engine，PCE)，以了解拓扑中节点的 SR 能力以及 SR 段到这些节点的映射。这可以使 SR PCE 能够针对流量工程用例执行基于 SR 的路径计算，并将流量引导到与基于 IGP 的底层分布式最佳路径计算不同的路径上。SR 信息的编码或解码错误可能会导致此类信息对 SR PCE 不可用或向其提供不正确的信息。这可能导致 SR PCE 无法执行所需的基于 SR 的优化功能或以意外或不一致的方式执行它。SR PCE 等应用程序对此类错误的处理可能是特定于实现的，超出了本文档的范围。除了在 [RFC7752] 中讨论的内容外，本文档中指定的扩展不会在 BGP 或 BGP-LS 中引入任何新的配置或监控方面。[RFC9020]、[ISIS-SR-YANG] 和 [OSPF-SR-YANG] 涵盖了底层 SR 功能的可管理性方面。5、 安全考虑本文档中引入的新协议扩展扩充了通过 [RFC7752] 分发的现有 IGP 拓扑信息。本文档中定义的 SR 链路属性信息的通告存在与 [RFC7752] 中描述的现有链路属性信息集相关的类似风险。[RFC7752] 的安全考虑部分也适用于这些扩展。本文档中定义的过程和新 TLV 本身不影响 [RFC7752] 中讨论的 BGP-LS 安全模型。本文档中介绍的 TLV 用于传播 IGP 定义的信息（参见 [RFC8665]、[RFC8666] 和 [RFC8667]）。这些 TLV 代表与 IGP 节点、链路和前缀关联的 SR 信息。假设生成这些 TLV 的 IGP 实例支持所有必需的安全和认证机制（如 [RFC8665]、[RFC8666] 和 [RFC8667] 中所述），以防止在将 TLV 传播到 BGP-LS 时出现任何安全问题。BGP-LS SR 扩展支持 SR 域内的流量工程用例。SR 在可信域 [RFC8402] 内运行，其安全考虑也适用于携带 SR 信息时的 BGP-LS 会话。使用通过 BGP-LS 通告的 SID 的 SR 流量工程策略预计将完全在此受信任的 SR 域内使用（例如，在单个提供商网络内的多个 AS/域之间）。因此，有必要采取预防措施，以确保通过 BGP-LS 会话通告的链路状态信息（包括 SR 信息）以安全的方式在此受信任的 SR 域内仅限于消费者。可以为 SR 域外的路由器设置除链路状态以外的地址族的 BGP 对等会话。建议隔离 BGP-LS 对等会话，以确保 BGP-LS 拓扑信息（包括新添加的 SR 信息）不会发布到 SR 域之外的外部 BGP 对等会话。6、 参考文献6.1、 规范性参考[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <https://www.rfc-editor.org/info/rfc4202>. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-editor.org/info/rfc5308>. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>. [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>. [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, <https://www.rfc-editor.org/info/rfc7794>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>. [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>. [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>. [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>. [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>. [RFC9084] Wang, A., Lindem, A., Dong, J., Psenak, P., and K. Talaulikar, Ed., "OSPF Prefix Originator Extensions", RFC 9084, DOI 10.17487/RFC9084, August 2021, <https://www.rfc-editor.org/info/rfc9084>.6.2、 参考资料[ISIS-SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J.Tantsura, "YANG Data Model for IS-IS Segment Routing", Work in Progress, Internet-Draft, draft-ietf-isis-sr-yang-10, 21 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-isis-sr-yang-10>. [OSPF-SR-YANG] Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, "YANG Data Model for OSPF SR (Segment Routing) Protocol", Work in Progress, Internet-Draft, draft-ietf-ospf-sr-yang-15, 2 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-ospf-sr-yang-15>. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>. [RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing MPLS Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661, December 2019, <https://www.rfc-editor.org/info/rfc8661>. [RFC9020] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", RFC 9020, DOI 10.17487/RFC9020, May 2021, <https://www.rfc-editor.org/info/rfc9020>.致谢作者要感谢 Jeffrey Haas、Aijun Wang、Robert Raszuk 和 Susan Hares 对本文档的审阅和评论。作者还要感谢 Alvaro Retana 的广泛审查和评论，这有助于纠正问题和改进文档。
-
发表了文章 2023-03-05
IPv4 地址冲突检测
RFC5227：IPv4 Address Conflict Detection，July 2008本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。梗概当同一链路上的两台主机尝试同时使用相同的 IPv4 地址时（除非在少数特殊情况下已事先协调好），一台或两台主机都会出现问题。本文档描述了 (i) 主机可以提前采取的简单预防措施，以帮助防止发生这种错误配置，以及 (ii) 如果确实发生这种错误配置，主机可以在事后被动检测到的简单机制它已经发生，以便主机或管理员可以响应以纠正问题。1、 简介从历史上看，意外地将两台 Internet 主机配置为相同的 IP 地址通常是一个令人讨厌且难以诊断的问题。这是不幸的，因为现有的地址解析协议 (Address Resolution Protocol，ARP) 为主机提供了一种简单的方法来检测这种错误配置并将其报告给用户。DHCP 规范 [RFC2131] 简要提到了 ARP 在检测错误配置中的作用，如以下 RFC 2131 的三个节选所示：* 客户端应该探测新收到的地址，例如，使用 ARP* 客户端应该对参数进行最终检查（例如，分配网络地址的 ARP）* 如果客户端检测到地址已被使用（例如，通过使用 ARP），客户端必须向服务器发送 DHCPDECLINE 消息不幸的是，DHCP 规范没有为实现者提供关于要发送的 ARP 数据包的数量、数据包之间的间隔、在断定可以安全使用地址之前等待的总时间，或者甚至是主机的数据包类型的任何指导。应该倾听，才能做出这个决定。如果在断定一个地址可以安全使用之后，它没有指定主机应该采取的行动，它随后发现它是错误的。它也未能指定 DHCP 客户端应采取哪些预防措施来防范病理性故障情况，例如重复提供相同地址的 DHCP 服务器，即使它已被拒绝多次。DHCP 规范的作者当时可能有理由认为这些问题的答案似乎过于简单、明显和直截了当，不值得一提，但不幸的是，这给每个单独的实现者留下了协议设计的一些负担。本文件旨在通过明确规定以下方面所需的行动来弥补这一遗漏：1. 确定地址的使用是否可能导致寻址冲突。这包括 (a) 地址已被同一链路上的另一台主机主动使用的情况，以及 (b) 两台主机无意中开始使用同一地址的情况，并且两者同时处于探查以确定地址是否可以安全使用（第 2.1 节）。2. 后续被动检测网络上的另一台主机无意中使用了相同的地址。即使所有主机都采取了预防措施以避免使用已在使用的地址，但如果在初始接口配置时两台主机无法通信，仍然会发生冲突。如果主机暂时超出范围，则无线网络接口可能会发生这种情况，或者如果两个以太网集线器之间的链路在地址配置时不起作用，则可能会发生以太网接口。精心设计的主机不仅会处理在接口配置期间检测到的冲突，还会在主机使用地址的整个持续时间内处理以后检测到的冲突（第 2.4 节）。3. 在重复冲突次数过多的情况下，地址获取尝试的速率限制（第 2.1 节）。IPv4 地址冲突检测 (Address Conflict Detection，ACD) 的实用程序不仅限于 DHCP 客户端。无论地址是如何配置的，无论是通过人类用户手动输入、通过从 DHCP 服务器接收的信息，还是通过任何其他配置信息源，检测冲突都是有用的。在检测到冲突时，配置代理应该被通知错误。在配置代理是人类用户的情况下，该通知可以采用屏幕上的错误消息、简单网络管理协议 (Simple Network Management Protocol，SNMP) 通知或通过文本消息发送到移动电话的错误消息的形式。对于 DHCP 服务器，该通知采用发送到服务器的 DHCP DECLINE 消息的形式。在由某种其他类型的软件进行配置的情况下，该通知采用向所讨论的软件发出错误指示的形式，通知它它选择的地址与网络上的某个其他主机冲突。配置软件可以选择停止网络操作，也可以自动选择一个新地址，以便主机尽快重新建立IP连接。IPv4 链路本地地址的分配 [RFC3927] 可以被认为是这种机制的一个特例，其中配置代理是一个伪随机数生成器，它在收到冲突通知时采取的行动是选择一个不同的随机数，然后重试。事实上，这正是 1998 年在 Mac OS 9 中实现 IPv4 Link-Local Addressing 的方式。如果 DHCP 客户端未能从任何 DHCP 服务器获得响应，它将简单地组成一个包含随机 169.254.x.x 的虚假响应地址。如果 ARP 模块报告了该地址的冲突，则 DHCP 客户端将再次尝试，根据需要多次组成一个新的随机 169.254.x.x 地址，直到成功。将 ACD 实现为网络堆栈的标准功能有一个副作用，即它意味着 IPv4 链路本地寻址的一半工作已经完成。1.1、 本文档中使用的约定和术语本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是被解释为“在 RFC 中使用的关键字以指示需求级别”[RFC2119] 中的描述。本文档在 ARP 数据包上下文中使用术语“发送方 IP 地址”或“目标 IP 地址”时，指的是 ARP 规范 [RFC826] 中标识为“ar$spa”的 ARP 数据包字段（发送者协议地址）和'ar$tpa'（目标协议地址）。对于本文档中描述的 ARP 用法，这些字段中的每一个都始终包含一个 IPv4 地址。在本文档中，“ARP 探测”一词用于指在本地链路上广播的 ARP 请求数据包，其“发送方 IP 地址”为全零。“发送方硬件地址”必须包含发送数据包的接口的硬件地址。“发送方 IP 地址”字段必须设置为全零，以避免在地址已被另一台主机使用的情况下污染同一链路上其他主机中的 ARP 缓存。“目标硬件地址”字段被忽略，应该设置为全零。“目标 IP 地址”字段必须设置为被探测的地址。ARP 探测既传达了一个问题（“有人在使用这个地址吗？”），也传达了一个隐含的陈述（“这是我希望使用的地址。”）。在本文档中，术语“ARP 公告”用于指在本地链路上广播的 ARP 请求数据包，与上述 ARP 探测相同，除了发送方和目标 IP 地址字段都包含被宣布的 IP 地址.它传达了比 ARP Probe 更强的声明，即“这是我现在使用的地址”。本协议中使用的以下时序常数在第 2 节中引用，该节详细描述了协议的操作。（请注意，此处列出的值是固定常量；它们不打算由实施者、操作员或最终用户修改。这些常量在此处被赋予符号名称，以便于编写可能希望以不同方式引用本文档的未来标准这些命名常量的值；但是，目前不存在这样的未来标准。）PROBE_WAIT ：1 秒（初始随机延迟） PROBE_NUM ：3（探测包数） PROBE_MIN ：1 秒（重复探测前的最小延迟） PROBE_MAX ：2 秒（重复探测前的最大延迟） ANNOUNCE_WAIT ：2 秒（宣布前延迟） ANNOUNCE_NUM ：2（公告包数） ANNOUNCE_INTERVAL ：2 秒（公告包之间的时间） MAX_CONFLICTS ：10（限速前的最大冲突） RATE_LIMIT_INTERVAL ：60 秒（连续尝试之间的延迟） DEFEND_INTERVAL ：10 秒（防御性 ARP 之间的最小间隔）1.2、 与 RFC 826 的关系本文档不修改 RFC 826 中的任何协议规则。它不修改数据包格式或任何字段的含义。“数据包生成”和“数据包接收”的现有规则仍然完全按照 RFC 826 中的规定适用。本文档通过指定以下内容扩展了 RFC 826：(1) 配置接口时应生成特定的 ARP 请求，以发现该地址是否已在使用中，以及(2) 应该对每个接收到的 ARP 数据包执行额外的简单测试，以促进被动的持续冲突检测。这个额外的测试不会在网络上产生额外的数据包开销（不发送额外的数据包）并且对主机的额外 CPU 负担可以忽略不计，因为每个实现 ARP 的主机*已经*需要根据数据包接收规则中指定的处理每个接收到的 ARP 数据包RFC 826。这些规则已经包括检查 ARP 数据包的“发送者 IP 地址”是否出现在主机 ARP 缓存的任何条目中；附加测试只是检查“发送方 IP 地址”是否是主机的*自己的* IP 地址，在许多架构上可能只需一条附加机器指令。正如 RFC 826 中已经规定的那样，一个 ARP 请求数据包有两个功能，一个Assertion断言和一个question问题：* 断言：字段“ar$sha”（发送者硬件地址）和“ar$spa”（发送者协议地址）一起用作对事实的断言：所述协议地址映射到所述硬件地址。* 问题：字段“ar$tha”（目标硬件地址，零）和“ar$tpa”（目标协议地址）作为一个问题，询问所声明的协议地址，它映射到哪个硬件地址。本文件阐明了有一个没有另一个意味着什么。一些读者指出，要问任何真正纯粹的问题可能是不可能的；问任何问题必然会引发关于审讯者为什么想知道答案的猜测。就像有人指着一个空座位问：“有人坐吗？”暗示了一个不言而喻的“......因为如果不是那么我会”，这里也是如此。带有全零“发送方 IP 地址”的 ARP 探测可能表面上只是在问一个无辜的问题（“有人在使用这个地址吗？”），但一个知道 IPv4 地址冲突检测如何工作的智能实现应该能够识别这一点问题作为声明地址的前兆。因此，如果该实施也在那个确切的时刻，在问同一个问题的过程中，它应该认识到他们不能都坐在同一个座位上，所以询问其他座位是谨慎的。1.2.1、 广播 ARP 回复在 IPv4 地址冲突检测 (ACD) 的某些应用中，使用广播而不是单播来传递 ARP 回复可能是有利的，因为这样可以比其他方式更快地检测到地址冲突。例如，“IPv4 链路本地地址的动态配置”[RFC3927] 完全按照此处指定的方式使用 ACD，但另外指定应使用广播发送 ARP 回复，因为在这种情况下，增加广播流量以换取改进的可靠性和容错性被认为是适当的。可能还有其他适合相同权衡的未来规范。更多细节在第 2.6 节“广播 ARP 回复”中给出。RFC 826 暗示对 ARP 请求的回复通常使用单播传递，但也可以使用广播传递 ARP 回复。RFC 826 中的数据包接收规则指定应在检查“ar$op”字段之前*处理“ar$spa”字段的内容，因此任何正确实现 RFC 826 中指定的数据包接收算法的主机都将正确处理通过链路层广播传递的 ARP 回复。1.3、 适用性本规范适用于所有 IEEE 802 局域网 (Local Area Networks，LAN) [802]，包括以太网 [802.3]、令牌环 [802.5] 和 IEEE 802.11 无线 LAN [802.11]，以及其他运行的链路层技术数据速率至少为 1 Mb/s，往返延迟最多为一秒，并使用 ARP [RFC826] 从 IP 地址映射到链路层硬件地址。无论本文档在何处使用术语“IEEE 802”，该文本同样适用于任何这些网络技术。支持 ARP 但以低于 1 Mb/s 的速率或高于 1 秒的延迟运行的链路层技术仍可在此协议下正常工作，但更多情况下可能需要处理在探测阶段完成后检测到的后期冲突。在这些类型的链路上，可能需要为以下参数指定不同的值：(a) PROBE_NUM、PROBE_MIN 和 PROBE_MAX，ARP 探测的数量和间隔，在第 2.1 节中解释。(b) ANNOUNCE_NUM 和 ANNOUNCE_INTERVAL，ARP 公告的数量和间隔，在第 2.3 节中解释。(c) RATE_LIMIT_INTERVAL 和 MAX_CONFLICTS，控制可以尝试地址声明的最大速率，在第 2.1 节中解释。(d) DEFEND_INTERVAL，冲突 ARP 之间的时间间隔，低于该时间间隔主机不得试图保护其地址，在第 2.4 节中解释。不支持 ARP 的链路层技术可能能够使用其他技术来确定当前是否正在使用特定的 IP 地址。但是，为此类网络实施地址冲突检测超出了本文档的范围。为了使本文档中指定的协议有效，链路上的所有主机都不需要实现它。对于实现此规范的给定主机以防止意外地址冲突，所需要的只是同一链路上的对等方正确实施 RFC 826 中给出的 ARP 协议。具体而言，当对等主机收到 ARP 请求时如果 ARP 请求的目标协议地址与该接口上配置的主机 IP 地址（其中之一）匹配，那么只要它正确响应格式正确的 ARP 应答，查询主机就能够检测到该地址已被使用。本文档中的规范允许主机检测在同一物理链路上使用同一地址的两台主机之间的冲突。ACD 不会检测在不同物理链路上使用相同地址的两台主机之间的冲突，实际上它不应该检测。例如，地址 10.0.0.1 [RFC1918] 被全世界无数专用网络上的无数设备使用，这不是冲突，因为它们位于不同的链路上。只有当两个这样的设备连接到同一个链路时才会发生冲突，并且当这种情况发生时（有时会发生），这是 ACD 对检测和报告非常有用的情况的完美示例（和/或自动更正）此错误。就本文档而言，如果满足以下条件，则认为一组主机“位于同一链路上”：- 当该集合中的任何主机 A 使用单播、多播或广播向该集合中的任何其他主机 B 发送数据包时，整个链路层数据包有效负载未经修改地到达，并且- 由该组主机中的任何主机通过该链路发送的广播可以被该组中的所有其他主机接收。可以修改链路层 *header*，例如在令牌环源路由 [802.5] 中，但不能修改链路层 *payload*。特别是，如果任何转发数据包的设备修改了 IP 报文头或 IP 有效负载的任何部分，则不再认为该数据包位于同一链路上。这意味着数据包可以通过中继器、网桥、集线器或交换机等设备，并且仍被视为在本文档中位于同一链路上，但不能通过减少 TTL 的 IP 路由器等设备或以其他方式修改 IP 报文头。本文档使用术语“主机”的地方，它同样适用于路由器或其他多宿主主机上的接口，无论主机/路由器当前是否正在转发数据包。在许多情况下，路由器将是关键的网络基础设施，其 IP 地址在当地广为人知，并且被认为是相对恒定的。例如，默认路由器的地址是 DHCP 服务器通常与其客户端通信的参数之一，并且（至少在 DHCP Reconfigure [RFC3203] 等机制得到广泛实施之前）DHCP 没有任何实用的方法如果地址发生变化，服务器会通知客户端。因此，对于此类设备，通过选择新的 IP 地址来处理冲突并不是一个好的选择。在这些情况下，第 2.4 节（“正在进行的地址冲突检测和地址防御”）中的选项 (c) 适用。但是，即使手动为设备配置了固定地址，网络上的其他设备声称拥有相同的 IP 地址也会污染对等 ARP 缓存并阻止可靠通信，因此通知操作员仍然有帮助。如果在操作员设置固定手动地址时检测到冲突，则立即通知操作员是有帮助的；如果随后检测到冲突，通过一些适当的异步通信渠道通知操作员是有帮助的。即使无法通过冲突地址进行可靠通信，仍然可以通过其他仍在运行的通信通道通知操作员，例如通过路由器上的其他接口，通过动态 IPv4 链路本地地址，通过有效的 IPv6 地址，甚至通过一些完全不同的非 IP 技术，例如本地连接的屏幕或串行控制台。2、 地址探测、宣布、冲突检测和防御本节介绍了安全确定地址是否已在使用中的初始探测、宣布所选地址、正在进行的冲突检查以及可选使用广播 ARP 回复以提供更快的冲突检测。2.1、 探测地址在开始使用 IPv4 地址（无论是从手动配置、DHCP 还是其他方式接收）之前，实现此规范的主机必须通过广播 ARP Probe 数据包来测试该地址是否已在使用中。这也适用于以下情况：网络接口从非活动状态转换为活动状态、计算机从睡眠中唤醒、链路状态更改发出以太网电缆已连接的信号时、802.11 无线接口与新基站相关联时，或者当主机主动连接到逻辑链路时发生任何其他连接变化。当然，主机不得定期执行此检查。如第 2.4 节所述，这将浪费网络带宽，并且由于主机能够被动地发现冲突而没有必要。2.1.1、 探测详细信息主机通过广播针对所需地址的 ARP 请求来探测地址是否已被使用。客户端必须用发送数据包的接口的硬件地址填写 ARP 请求的“发送者硬件地址”字段。“发送者 IP 地址”字段必须设置为全零；这是为了避免在地址已被另一台主机使用的情况下污染同一链路上其他主机中的 ARP 缓存。“目标硬件地址”字段被忽略，应该设置为全零。“目标 IP 地址”字段必须设置为被探测的地址。以这种方式构造的具有全零“发送方 IP 地址”的 ARP 请求称为“ARP 探测”。当准备好开始探测时，主机应等待在 0 到 PROBE_WAIT 秒范围内统一选择的随机时间间隔，然后发送 PROBE_NUM 个探测包，这些探测包中的每一个随机且均匀地间隔，PROBE_MIN 到 PROBE_MAX 秒。这种初始随机延迟有助于确保同时启动的大量主机不会同时发送它们的初始探测数据包。如果在此期间，从探测过程开始到发送最后一个探测包后的 ANNOUNCE_WAIT 秒，主机在执行探测的接口上接收到任何 ARP 包（请求*或*回复），其中包的 ' sender IP address' 是被探测的地址，那么主机必须将此地址视为正在被其他主机使用，并且应该向配置代理（人工操作员、DHCP 服务器等）指示建议的地址不是可以接受。此外，如果在此期间主机收到任何 ARP 探测，其中数据包的“目标 IP 地址”是被探测的地址，并且数据包的“发送方硬件地址”不是任何主机接口的硬件地址，那么主机应该类似地将其视为地址冲突，并向配置代理发出错误信号，如上所述。如果两个（或更多）主机出于某种原因无意中配置了相同的地址，并且两者都同时在探测该地址以查看它是否可以安全使用，则可能会发生这种情况。注意：检查数据包的“发送者硬件地址”不是任何主机接口的硬件地址很重要。某些类型的以太网集线器（通常称为“缓冲中继器”）和许多无线接入点可能会将任何接收到的广播数据包“重新广播”给所有接收者，包括原始发送者本身。因此，上述预防措施对于确保主机在看到自己的 ARP 数据包回显时不会感到困惑是必要的。实现本规范的主机必须采取预防措施来限制它探测新候选地址的速率：如果主机在给定接口上遇到 MAX_CONFLICTS 或更多地址冲突，则主机必须限制它在其上探测新地址的速率此接口对每个 RATE_LIMIT_INTERVAL 的尝试新地址不超过一个。这是为了防止在病理性故障情况下发生灾难性的 ARP 风暴，例如有缺陷的 DHCP 服务器重复为每台请求的主机分配相同的地址。此限速规则不仅适用于在初始探测阶段经历的冲突，也适用于后来经历的冲突，如第 2.4 节“正在进行的地址冲突检测和地址防御”中所述。如果在最后一个 ARP 探测传输后的 ANNOUNCE_WAIT 秒内没有收到冲突的 ARP 应答或 ARP 探测，则主机已成功确定可以安全使用所需的地址。2.2、 在适当的网络技术上更短的超时可能会出现比本文档要求的延迟更短的网络技术。随后的 IETF 出版物可能会为这些技术的 PROBE_WAIT、PROBE_NUM、PROBE_MIN 和 PROBE_MAX 的不同值提供指导。如果出现链路上不同主机使用不同时序参数的情况，这不会导致任何问题。该协议不依赖于实现相同版本协议的链路上的所有主机；实际上，该协议根本不依赖于实现该协议的链路上的所有主机。所需要的只是所有主机都按照 RFC 826 中的规定实现 ARP，并正确回答它们收到的 ARP 请求。在不同的主机使用不同的时序参数的情况下，将会发生的只是一些主机将比其他主机更快地配置它们的接口。万一在地址探测阶段未检测到地址冲突，冲突仍将通过下面第 2.4 节中描述的持续地址冲突检测来检测。2.3、 宣布地址在探查确定可以安全使用所需地址后，实现此规范的主机必须随后通过广播 ANNOUNCE_NUM ARP 公告（间隔为 ANNOUNCE_INTERVAL 秒）来宣布它开始使用此地址。ARP 公告与上述 ARP 探测相同，只是现在发送方和目标 IP 地址都设置为主机新选择的 IPv4 地址。这些 ARP 公告的目的是确保链路上的其他主机没有旧的 ARP 缓存条目，这些条目是以前可能使用相同地址的其他主机留下的。主机可以在发送两个 ARP 公告中的第一个后立即开始合法地使用 IP 地址；第二个 ARP 公告的发送可以异步完成，与主机可能希望执行的其他网络操作并发。2.4、 持续的地址冲突检测和地址防御地址冲突检测不仅限于初始接口配置时间，当主机发送 ARP 探测时。地址冲突检测是一个持续的过程，只要主机正在使用地址，它就会一直有效。在任何时候，如果主机收到一个 ARP 数据包（请求*或*回复），其中“发送方 IP 地址”是在该接口上配置的主机自己的 IP 地址（其中之一），但“发送方硬件地址”不匹配任何主机自己的接口地址，则这是一个冲突的 ARP 数据包，表明其他主机也认为它正在有效地使用该地址。为了解决地址冲突，主机必须响应以下 (a)、(b) 或 (c) 中描述的冲突 ARP 数据包：(a) 在接收到一个冲突的 ARP 数据包时，主机可以选择立即停止使用该地址，并向配置代理发出错误信号，如上所述。(b) 如果主机当前有活动的 TCP 连接或其他原因更喜欢保持相同的 IPv4 地址，并且在最后的 DEFEND_INTERVAL 秒内没有看到任何其他冲突的 ARP 数据包，那么它可以选择尝试通过以下方式保护其地址记录收到冲突 ARP 数据包的时间，然后广播一个 ARP 公告，将自己的 IP 和硬件地址作为 ARP 的发送者地址，“目标 IP 地址”设置为自己的 IP 地址，然后“目标硬件地址”设置为全零。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。但是，如果这不是主机看到的第一个冲突 ARP 包，并且为前一个冲突 ARP 包记录的时间是最近的，在 DEFEND_INTERVAL 秒内，那么主机必须立即停止使用该地址并向配置代理发出错误信号如上所述。这是必要的，以确保两台主机不会陷入无限循环，两台主机都试图保护同一个地址。(c) 如果主机已配置为在任何情况下都不应放弃其地址（可能是因为它是需要具有众所周知的稳定 IP 地址的设备，例如链路的默认路由器或DNS 服务器）然后它可以选择无限期地保护它的地址。如果这样的主机收到一个冲突的 ARP 数据包，那么它应该采取适当的步骤从 ARP 数据包中记录有用的信息，例如源以太网地址，并将问题通知管理员。应适当控制此类通知的数量，以防止生成过多的错误报告。如果主机最近没有看到任何其他冲突的 ARP 数据包，在最后的 DEFEND_INTERVAL 秒内，那么它必须记录收到冲突的 ARP 数据包的时间，然后广播一个单一的 ARP 公告，给出它自己的 IP 和硬件地址。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。然而，如果这不是主机看到的第一个冲突的 ARP 包，并且为前一个冲突的 ARP 包记录的时间在 DEFEND_INTERVAL 秒内，那么主机不得发送另一个防御性 ARP 公告。这是必要的，以确保两个配置错误的主机不会陷入无限循环，在它们都试图保护同一个地址时，用广播流量淹没网络。希望提供可靠网络操作的主机必须响应上述 (a)、(b) 或 (c) 中所述的冲突 ARP 数据包。忽略冲突的 ARP 数据包会导致看似随机的网络故障，这些故障可能难以诊断，并且对人类用户来说非常令人沮丧。强制地址重新配置可能具有破坏性，导致 TCP（和其他传输层）连接中断。然而，这种中断应该是非常罕见的，如果发生无意的地址重复，那么通信中断是不可避免的。同一网络上使用相同 IP 地址的两台不同主机不可能可靠运行。在由于冲突而放弃地址之前，主机应该积极尝试使用该地址重置任何现有连接。如第 5 节所述，这减轻了地址重新配置带来的一些安全威胁。对于大多数不需要固定 IP 地址的客户端机器，一旦检测到冲突，立即请求配置代理（人类用户、DHCP 客户端等）配置新地址是尽快恢复有用通信的最佳方法尽可能。上述广播单个 ARP 公告以保护地址的机制通过帮助提高两个冲突主机之一可能能够保留其地址的机会，在一定程度上缓解了该问题。2.5、 持续检测从主机发送它的第一个 ARP 公告开始，直到它停止使用该 IP 地址，主机必须以 ARP 规范 [RFC826] 要求的通常方式回答 ARP 请求。具体来说，这意味着每当主机接收到 ARP 请求时，这不是上文第 2.4 节所述的冲突 ARP 数据包，其中 ARP 请求的“目标 IP 地址”是主机自己的 IP 地址（之一）在该接口上配置，主机必须以 RFC 826 中所述的 ARP 回复进行响应。这同样适用于具有非零发送方 IP 地址的标准 ARP 请求和具有全零发送方 IP 地址的探测请求。2.6、 广播 ARP 回复在手动分配地址的精心运行的网络中，或者具有可靠 DHCP 服务器和可靠 DHCP 客户端的网络中，地址冲突只应在极少数故障情况下发生，因此上文第 2.4 节中描述的被动监控就足够了。如果两台主机使用相同的 IP 地址，那么迟早一台主机或另一台将广播一个 ARP 请求，另一台将看到该请求，从而检测到并解决冲突。但是，冲突配置可能会在检测到之前持续一小段时间。假设两台主机 A 和 B 无意中因为某种原因被分配了同一个 IP 地址 X，所以在接口配置时都没有检测到冲突。假设现在通信链路已恢复，第三台主机 C 广播地址 X 的 ARP 请求。主机 A 和 B 都没有意识到任何冲突，都将向主机 C 发送单播 ARP 回复。主机 C 将看到这两个回复，并且可能有点困惑，但是主机 A 和 B 都不会看到对方的回复，也不会立即检测到有冲突需要解决。主机 A 和 B 将继续不知道冲突，直到其中一个或其他广播自己的 ARP 请求。如果需要更快的冲突检测，这可以通过让主机使用链路级广播发送 ARP 回复来实现，而不是仅通过广播发送 ARP 请求，并通过单播发送回复。不建议将其用于一般用途，但在 IPv4 ACD 上构建的其他规范可能会选择指定广播 ARP 回复（如果合适）。例如，“IPv4 链路本地地址的动态配置”[RFC3927] 指定广播 ARP 回复，因为在这种情况下，使用 IPv4 ACD 检测地址冲突不仅仅是检测其他配置机制故障的备用预防措施；使用 IPv4 ACD 检测地址冲突是唯一的配置机制。使用广播发送 ARP 回复确实会增加广播流量，但在最坏的情况下不会超过两倍。在 ARP 的传统用法中，单播 ARP 回复仅在响应广播 ARP 请求时发生，因此通过广播发送这些消息意味着我们最多生成一个广播回复以响应每个现有的广播请求。在许多网络上，ARP 流量在总流量中所占的比例微不足道，将其翻倍并没有实际意义。然而，这可能并非适用于所有网络，因此不应普遍使用广播 ARP 回复。如果更快的冲突检测的好处超过了增加广播流量和增加参与网络主机上的数据包处理负载的成本，则应使用广播 ARP 回复。3、 为什么使用ARP请求报文而不是ARP应答报文进行ARP通告？在 IETF 从 2000 年到 2008 年审议 IPv4 地址冲突检测期间，一个反复被问到的问题是，“难道 ARP 公告不应该使用免费的 ARP 应答数据包来执行吗？”从表面上看，这似乎是合理的。传统的 ARP 回复是对问题的回答。如果事实上没有提出任何问题，那么将这样的答复描述为免费是合理的。“免费回复”一词似乎完全适用于 ARP 公告：对实际上没有人提出的隐含问题的回答。不管这在原则上看起来多么合理，实际上有两个原因使争论倾向于使用 ARP 请求数据包。一是历史先例，二是实用主义。历史先例是（如上文第 4 节所述）免费 ARP 在 Stevens Networking [Ste94] 中记录为使用 ARP 请求数据包。BSD Unix、Microsoft Windows、Mac OS 9、Mac OS X 等都使用 Stevens 中描述的 ARP 请求数据包。在这个阶段，试图强制他们都切换到使用 ARP 回复数据包将是徒劳的。实际原因是 ARP 请求数据包更有可能与更多现有的 ARP 实现一起正常工作，其中一些可能无法完全正确地实现 RFC 826。RFC 826 中的数据包接收规则指出，操作码是在数据包处理中检查的最后一件事，所以这真的无关紧要，但可能会有“创造性”实现根据“ar$op”具有不同的数据包处理字段，并且有几个原因导致它们比免费 ARP 回复更有可能接受免费 ARP 请求：* 不正确的 ARP 实现可能会认为 ARP 回复仅通过单播发送。RFC 826 没有说明这一点，但不正确的实现可能会假设它；“最不意外原则”规定，如果有两种或多种方法可以解决网络问题，而这些方法在其他方面同样好，那么具有最少异常属性的一种方法可能与现有实现的互操作性问题最少。ARP Announcement 需要向链路上的所有主机广播信息。由于 ARP 请求数据包始终是广播的，而 ARP 应答数据包不是，因此通过广播接收 ARP 请求数据包比通过广播接收 ARP 应答数据包更令人惊讶。* 不正确的 ARP 实现可能会期望仅接收 ARP 回复以响应该实现最近发出的 ARP 请求。意外的主动回复可能会被忽略。* 不正确的 ARP 实现可能会忽略 'ar$tha' 与其硬件地址不匹配的 ARP 回复。* 不正确的 ARP 实现可能会忽略 'ar$tpa' 与其 IP 地址不匹配的 ARP 回复。总之，不正确的 ARP 实现可能会拒绝 ARP 回复（通常是由于客户端请求而发生），而不是 ARP 请求（已经预期会主动发生）。4、 历史笔记一些读者声称，如 Stevens [Ste94] 中所述，“免费 ARP”提供重复地址检测，从而不需要 ACD。这是不正确的。Stevens 所描述的免费 ARP 与本文档中使用更具描述性的术语“ARP 公告”所指的数据包完全相同。这种传统的免费 ARP 实现在首次配置接口时仅发送一个 ARP 公告。结果是受害者（现有地址持有者）记录了一个错误，而攻击者继续操作，通常甚至没有发现任何问题。然后两台机器通常会继续尝试使用相同的 IP 地址，但由于它们都在不断地重置对方的 TCP 连接而无法正常运行。预计人类管理员会注意到受害者机器上的日志消息并在事后修复损坏。通常，这必须通过物理访问相关机器来完成，因为在这种状态下，两者都无法保持 TCP 连接打开足够长的时间来通过网络执行任何有用的操作。Gratuitous ARP 实际上并没有提供有效的重复地址检测功能，并且（截至 2008 年 1 月）Google 搜索短语“Gratuitous ARP”的许多热门结果都是描述如何禁用它的文章。但是，IPv4 地址冲突检测的实施者应该意识到，在撰写本文时，免费 ARP 仍在广泛部署。本文档第 2.1 节和第 2.4 节中描述的步骤有助于使主机能够抵御错误配置和地址冲突，即使其他主机*不*按照相同的规则运行。5、 安全考虑IPv4 地址冲突检测 (ACD) 基于 ARP [RFC826]，它继承了该协议的安全漏洞。恶意主机可能会在网络上发送欺骗性的 ARP 包，干扰其他主机的正常运行。例如，主机很容易通过提供自己硬件地址的回复来回答所有 ARP 请求，从而声称拥有网络上每个地址的所有权。该规范使现有的 ARP 漏洞不会变得更糟，并且在某些方面使其变得更好：实现该规范的主机不会尝试自动重新配置，或者至少通知人类用户正在发生的事情，而不是默默地失败而没有说明原因。如果主机愿意选择一个新地址来响应 ARP 冲突，如第 2.4 节 (a) 小节所述，这可能会使同一链路上的恶意攻击者更容易劫持 TCP 连接。让主机在放弃地址之前主动重置任何现有连接有助于降低这种风险。6、 致谢本文档是 Zeroconf 工作组关于 IPv4 链路本地寻址 [RFC3927] 讨论的结果，其中许多参与者不清楚链路本地地址管理的哪些元素是特定于该特定问题空间的（例如，随机选择地址），以及哪些元素是通用的并且适用于所有 IPv4 地址配置机制（例如，地址冲突的检测）。以下人员在该工作和/或本文档的后续编辑过程中提出了宝贵意见：Bernard Aboba、Randy Bush、Jim Busse、James Carlson、Alan Cox、Spencer Dawkins、Pavani Diwanji、Ralph Droms、Donald Eastlake III、亚历克斯·埃尔德、斯蒂芬·法瑞尔、彼得·福特、斯宾塞·贾卡隆、乔什·格雷斯利、埃里克·格特曼、迈伦·哈蒂格、迈克·赫德、休·霍尔布鲁克、理查德·约翰逊、金容云、马克·克罗奇马尔、罗德·洛佩兹、罗里·麦奎尔、萨蒂什·蒙德拉、托马斯·纳滕Erik Nordmark、Randy Presuhn、Howard Ridenour、Pekka Savola、Daniel Senie、Dieter Siegmund、Valery Smyslov、Mark Townsley、Oleg Tychev 和 Ryan Troll。7、 参考文献7.1、 规范性参考[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.7.2、 参考资料[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [802.3] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3-1996), 1996. [802.5] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token ring access method and physical layer specifications, (also ANSI/IEEE Std 802.5-1998), 1998. [802.11] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.完整的版权声明版权所有 (C) IETF 信托 (2008)。本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。本文档和此处包含的信息按“原样”提供，贡献者、他/她代表或由（如果有）赞助的组织、互联网协会、IETF 信托和互联网工程任务组否认所有明示或暗示的保证，包括但不限于使用此处信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性的保证。知识产权IETF 对可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围或根据此类权利可能或可能不会获得任何许可的程度不持任何立场能得到的;它也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序信息，请参见 BCP 78 和 BCP 79。向 IETF 秘书处披露的 IPR 副本，以及任何保证可用的许可，或试图获得本规范的实施者或用户使用此类专有权利的一般许可或许可的结果来自位于 http://www.ietf.org/ipr 的 IETF 在线 IPR 存储库。IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施该标准可能需要的技术的其他专有权利。请将信息发送至 IETF，地址为 ietf-ipr@ietf.org。
-
发表了文章 2023-03-04
虚拟路由和转发 (VRF) 表上下文中的多点标签分发协议带内信令
RFC7246：Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context，June 2014梗概IP 组播分发树 (Multicast Distribution Tree，MDT) 可以遍历网络的标签交换（即多协议标签交换或 MPLS）和非标签交换区域。通常，MDT 在非 MPLS 区域中开始和结束，但要通过 MPLS 区域。在这种情况下，开始将 MDT 构建为纯 IP MDT，然后在进入启用 MPLS 的区域时将其转换为 MPLS 多点标签交换路径 (Multipoint Label Switched Path，MP-LSP)，然后将其转换回纯 IP MDT 进入未启用 MPLS 的区域时。其他文件规定了构建这种混合 MDT 的过程，在网络的非 MPLS 区域中使用协议独立组播 (Protocol Independent Multicast，PIM)，在 MPLS 区域中使用多点标签分发协议 (Multipoint Label Distribution Protocol，mLDP)。本文档扩展了这些程序以处理连接两个区域的链路是虚拟路由和转发 (Virtual Routing and Forwarding，VRF) 表链路的情况，如“BGP IP/MPLS VPN”规范中所定义。然而，本文档主要针对 VRF 用于支持组播 VPN 以外的组播应用的特定用例。本备忘录的状态这是一份 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7246。版权声明版权所有 (c) 2014 IETF Trust 和文件作者。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。1、 简介有时，IP 组播分发树 (MDT) 会遍历网络中启用 MPLS 的区域和未启用 MPLS 的区域。通常，MDT 在非 MPLS 区域中开始和结束，但要通过 MPLS 区域。在这种情况下，开始将 MDT 构建为纯 IP MDT，然后在进入启用 MPLS 的区域时将其转换为 MPLS 多点标签交换路径 (LSP)，然后将其转换回纯 IP进入未启用 MPLS 的区域时的 MDT。其他文件规定了构建这种混合 MDT 的过程，在网络的非 MPLS 区域中使用协议独立组播 (PIM)，在 MPLS 区域中使用多点标签分发协议 (mLDP)。本文档扩展了 [RFC6826] 中的程序，以处理连接两个区域的链路是虚拟路由和转发 (VRF) 表链路的情况，如“BGP IP/MPLS VPN”规范 [RFC6513] 中所定义。然而，本文档主要针对 VRF 用于支持组播 VPN 以外的组播应用的特定用例。在 PIM 中，树由源地址（或在双向树 [RFC5015] 的情况下，集合点地址或“RPA”）和组地址来标识。通过在源地址或 RPA 的方向发送 PIM 控制消息，从叶子向上构建树。在 mLDP 中，树由根地址和“不透明值”标识，并通过向根方向发送 mLDP 控制消息来构建。[RFC6826] 的过程解释了如何将 PIM <source address or RPA, group address> 对转换为 mLDP <root node, opaque value> 对以及如何将 mLDP <root node, opaque value> 对转换回原始 PIM <源地址或 RPA，组地址> 对。然而，[RFC6826] 中的过程假定进行 PIM/mLDP 转换的路由器在其全局路由表中具有到源地址或 RPA 的路由。因此，当将非 MPLS 启用区域连接到 MPLS 启用区域的接口是属于 [RFC4364] 中描述的 VRF 的接口时，这些过程不能完全按照指定的方式应用。本规范扩展了 [RFC6826] 的程序，以便它们可以在 VRF 上下文中应用。与 [RFC6826] 中一样，本文档的范围仅限于通过 PIM 创建的源特定或双向树在非 MPLS 启用区域中分发组播内容的情况。双向树总是映射到多点到多点 LSP，源特定树总是映射到点到多点 LSP。请注意，此处描述的过程不支持非双向 PIM 任意源组播 (Any-Source Multicast，ASM) 组，不支持在核心中使用除 mLDP 多点 LSP 之外的组播树，并且不提供聚合多个 PIM 树的能力到单个多点 LSP 上。如果需要这些特性中的任何一个，它们可以通过 [RFC6513] 和 [RFC6514] 的程序提供。但是，在某些情况下，组播服务是通过与 VRF 关联的接口提供的，并且 mLDP 用于核心，但不需要聚合。例如，一些服务提供商向他们的客户提供组播内容，但选择使用 VRF 来隔离各种客户和服务。与客户提供自己的组播内容、不受服务提供商控制的情况相比，这是一种更简单的情况，并且可以使用更简单的解决方案来处理。此外，当 PIM 树一对一映射到多点 LSP 时，将 PIM 源/组地址编码到 mLDP FEC（转发等效类）元素中（在本文档中称为“mLDP带内信号”。为了在一组特定 VRF 的上下文中对特定组地址使用 mLDP 带内信令过程，必须为这些 VRF 配置一个组播组地址范围，为这些地址启用 mLDP 带内信令。此配置符合 [RFC4364] 中定义的 VRF）。对于那些组，并且仅这些组，使用本文档的程序。对于其他组，可以使用通用组播 VPN 程序，尽管这个 VRF 更有可能专用于 mLDP 带内信令程序并且所有其他组都被丢弃。该配置必须存在于所有连接到站点的 PE 路由器中，这些站点包含给定组地址集的发送者或接收者。请注意，由于提供商很可能拥有组播内容和跨网络传输的方法，这对最终用户都是透明的，因此最终用户和提供商之间不需要进行协调。1.1、 本文档中使用的约定本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119] 中的描述进行解释。1.2、 术语In-band signaling：带内信令，使用 mLDP FEC 元素的不透明值对标识特定 IP 组播树的 (S,G) 或 (*,G) 进行编码。Ingress LSR：P2MP LSP 的来源，也称为根节点。IP multicast tree：IP 组播树，由源 IP 地址和/或 IP 组播目标地址标识的 IP 组播分发树，也称为 (S,G) 和 (*,G)。mLDP：多点 LDP。MP LSP：多点 LSP，P2MP 或 MP2MP LSP。MP2MP LSP：连接一组叶节点的 LSP，充当入口或出口（参见 [RFC6388]）。P2MP LSP：具有一个 Ingress LSR 和一个或多个 Egress LSR 的 LSP（参见 [RFC6388]）。RPA：Rendezvous Point Address，集合点地址，用作一系列组播组的分发树根的地址。RD：Route Distinguisher，在 VRF 上下文中使路由唯一的标识符。UMH：Upstream Multicast Hop，即在到达组播流源的路径中的上游路由器。VRF：Virtual Routing and Forwarding table，虚拟路由和转发表。2、 MP LSP 的 VRF 带内信令假设 PE 路由器 PE1 通过其与 VRF 关联的接口之一接收 PIM Join(S,G) 消息。按照 [RFC6513] 的第 5.1 节的过程，PE1 确定源地址 S 的“上游 RD”、“上游 PE”和“上游组播跳”（upstream multicast hop，UMH）。为了使用 VRF 带内信令通过多点 (MP) LSP 传输组播树，PE1 发送 mLDP 标签映射消息。该消息将包含一个 P2MP FEC 或一个 MP2MP FEC（参见 [RFC6388]），这取决于所传输的 PIM 树分别是源特定树还是双向树。FEC 包含一个“根”和一个“不透明值”。如果 UMH 和上游 PE 的 IP 地址相同（即上游 PE 是 UMH），则多点 FEC 的根设置为上游 PE 的 IP 地址。如果在此 VPN 的上下文中，(S,G) 指的是特定于源的 MDT，则 S、G 和上游 RD 的值被编码为不透明值。如果在此 VPN 的上下文中，G 是双向组地址，则 S 将替换为与 G 关联的 RPA 的值。编码细节在第 3 节中指定。从概念上讲，多点 FEC 可以被认为是一个有序对：{root=<Upstream-PE>; opaque_value=<S 或 RPA，G，上游-RD>}。然后，PE1 在其 LDP 会话上将 mLDP 标签映射消息发送到到上游 PE 的消息路径上的“下一跳”。“下一跳”通常是直接连接的下一跳，但请参阅 [RFC7060] 了解下一跳不直接连接的情况。如果UMH 和上游PE 没有相同的IP 地址，则应采用[RFC6512]第2 节的程序。多点 FEC 的根节点设置为 UMH。然后递归的不透明值设置如下：根节点设置为上游PE，不透明值设置为上一段中描述的多点FEC。也就是说，多点 FEC 可以被认为是以下递归有序对：{root=<UMH>; opaque_value=<root=Upstream-PE, opaque_value=<S or RPA, G, Upstream-RD>>}。多点 FEC 的编码还指定了拼接到多点 LSP 上的 PIM MDT 的“类型”。[RFC6826] 中定义了四种不透明编码：IPv4 源特定树、IPv6 源特定树、IPv4 双向树和 IPv6 双向树。当 PE 路由器接收到带有 P2MP 或 MP2MP FEC 的 mLDP 消息时，其中 PE 路由器本身是根节点，并且 opaque value 是第 3 节中定义的类型之一，那么它使用 opaque value 字段中编码的 RD确定 VRF 上下文。（该 RD 将与 PE VRF 之一相关联。）然后，在该 VRF 的上下文中，PE 遵循 [RFC6826] 第 2 节中指定的过程。3、 对 LDP MP FEC 的不透明值进行编码本节记录了不同的传输不透明编码。3.1、 中转 VPNv4 源 TLV当传输源和组地址为 IPv4 地址的源特定模式组播树时使用此不透明值类型。Type：类型，250Length：长度，16Source：IPv4 组播源地址，4 个八位字节。Group：IPv4 组播组地址，4 个八位字节。RD：Route Distinguisher，路由识别器，8 个八位字节。3.2、 中转 VPNv6 源 TLV当传输源和组地址为 IPv6 地址的源特定模式组播树时使用此不透明值类型。Type：类型，251Length：长度，40Source：IPv6 组播源地址，16 个八位字节。Group：IPv6 组播组地址，16 个八位字节。RD：Route Distinguisher，路由识别器，8 个八位字节。3.3、 中转 VPNv4 双向 TLV在传输组地址为 IPv4 地址的双向组播树时使用此不透明值类型。在这种情况下，RP 地址也是 IPv4 地址。Type：类型，9Length：长度，17Mask Len：左对齐并用作掩码的连续 1 位的数量，1 个八位字节。RP：用于编码组的集合点 (Rendezvous Point，RP) IPv4 地址，4 个八位字节。Group：IPv4 组播组地址，4 个八位字节。RD：路由识别器，8 个八位字节。3.4、 中转 VPNv6 双向 TLV当传输组地址为 IPv6 地址的双向组播树时使用此不透明值类型。在这种情况下，RP 地址也是 IPv6 地址。Type：类型，10Length：长度，41Mask Len：左对齐并用作掩码的连续 1 位的数量，1 个八位字节。RP：用于编码组的集合点 (RP) IPv6 地址，16 个八位字节。Group：IPv6 组播组地址，16 个八位字节。RD：路由识别器，8 个八位字节。4、 安全考虑相同的安全考虑适用于 [RFC5036] 中描述的基本 LDP 规范和 [RFC6388] 中描述的基本 mLDP 规范。操作者必须配置数据包过滤器以确保本备忘录中描述的机制不会导致非全局范围的 IPv6 组播数据包通过隧道超出其预期范围。5、 IANA 考虑事项[RFC6388]为“LDP MP 不透明值元素基本类型”定义了一个注册表。IANA 已在此注册表中分配了四个新代码点：中转 VPNv4 源 TLV 类型：250 中转 VPNv6 源 TLV 类型：251 中转 VPNv4 双向 TLV 类型：9 中转 VPNv6 双向 TLV 类型：106、 致谢感谢 Eric Rosen、Andy Green、Yakov Rekhter 和 Eric Gray 对文档的评论。7、 参考文献7.1、 规范性参考[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012. [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, January 2013.7.2、 参考资料[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, November 2013.
-
发表了文章 2023-03-04
FTP：文件传输协议
RFC959：FILE TRANSFER PROTOCOL (FTP)，October 1985本备忘录的状态本备忘录是文件传输协议 (File Transfer Protocol，FTP) 的官方规范。本备忘录的分发不受限制。 此版本的规范中包含以下新的可选命令：CDUP（Change to Parent Directory，更改到父目录）、SMNT（Structure Mount，结构挂载）、STOU（Store Unique，唯一存储）、RMD（Remove Directory，删除目录）、MKD（Make Directory，制作目录）、PWD（Print Directory，打印目录）和 SYST（System，系统）。请注意，此规范与以前的版本兼容。1、 介绍FTP 的目标是：1) 促进文件（计算机程序和/或数据）的共享，2) 鼓励间接或隐式（通过程序）使用远程计算机，3) 保护用户免受文件存储系统的变化影响主机，以及4) 可靠、高效地传输数据。 FTP 虽然可由用户在终端直接使用，但主要设计为供程序使用。本规范的尝试是通过简单、易于实现的协议设计来满足maxi-hosts、mini-hosts、个人工作站和TACs用户的多样化需求。本文假设您了解传输控制协议 (Transmission Control Protocol，TCP) [2] 和 Telnet 协议 [TELNET协议规范]。这些文档包含在 ARPA-Internet 协议手册 [1] 中。2、 概述在本节中，将讨论历史、术语和 FTP 模型。本节中定义的术语只是那些在 FTP 中具有特殊意义的术语。某些术语非常特定于 FTP 模型；一些读者可能希望在查看术语时转向有关 FTP 模型的部分。2.1、 历史多年来，FTP 经历了漫长的发展。附录3 是与 FTP 相关的征求意见文档的时间顺序汇编。其中包括 1971 年首次提出的文件传输机制，该机制是为在麻省理工学院的主机上实现而开发的。（RFC 114），以及 RFC 141 中的评论和讨论。RFC 172 为主机（包括终端 IMP）之间的文件传输提供了一个面向用户的协议。将此修订为 RFC 265，重申 FTP 以进行额外审查，而 RFC 281 建议进一步更改。 1982 年 1 月在 RFC 294 中提议使用“设置数据类型”事务。RFC 354 废弃了 RFC 264 和 265。文件传输协议现在被定义为 ARPANET 上主机之间文件传输的协议，FTP 的主要功能定义为在主机之间高效可靠地传输文件，并允许方便地使用远程文件存储能力。 RFC 385 进一步评论了错误、重点和协议的补充，而 RFC 414 提供了关于工作服务器和用户 FTP 的状态报告。 1973 年发布的 RFC 430（在其他 RFC 中不胜枚举）对 FTP 提出了进一步的评论。最后，一个“官方”的 FTP 文档被发布为 RFC 454。到 1973 年 7 月，与 FTP 的最后一个版本相比，发生了相当大的变化，但总体结构保持不变。 RFC 542 作为新的“官方”规范发布以反映这些更改。但是，许多基于旧规范的实现并未更新。1974 年，RFC 607 和 614 继续对 FTP 进行评论。 RFC 624 提出了进一步的设计更改和小的修改。 1975 年，名为“Leaving Well Enough Alone”的 RFC 686 讨论了所有早期和晚期 FTP 版本之间的差异。 RFC 691 提出了 RFC 686 的小修订版，涉及打印文件的主题。在从 NCP 过渡到作为底层协议的 TCP 的推动下，在 RFC 765 作为用于 TCP 的 FTP 规范的所有上述努力中诞生了凤凰。FTP 规范的当前版本旨在更正一些小的文档错误，改进对某些协议功能的解释，并添加一些新的可选命令。特别是，此版本的规范中包含了以下新的可选命令：CDUP - Change to Parent Directory，更改为父目录SMNT - Structure Mount，结构挂载STOU - Store Unique，唯一存储RMD - Remove Directory，删除目录MKD - Make Directory，制作目录PWD - Print Directory，打印目录SYST – System，系统该规范与以前的版本兼容。符合先前规范的程序应该自动符合本规范。2.2、 术语ASCIIASCII 字符集在 ARPA-Internet 协议手册中定义。在 FTP 中，ASCII 字符被定义为八位代码集的下半部分（即最高有效位为零）。访问控制访问控制（access controls）定义了用户对系统使用和该系统中文件的访问权限。访问控制是必要的，以防止未经授权或意外使用文件。调用访问控制是服务器 FTP 进程的特权。字节大小FTP 中有两种感兴趣的字节大小（byte size）：文件的逻辑字节大小和用于传输数据的传输字节大小。传输字节大小始终为 8 位。传输字节大小不一定是系统中要存储数据的字节大小，也不一定是用于解释数据结构的逻辑字节大小。控制连接USER-PI 和 SERVER-PI 之间用于交换命令和回复的通信路径。此连接遵循 Telnet 协议。数据连接以指定的模式和类型传输数据的全双工连接。传输的数据可以是文件的一部分、整个文件或多个文件。该路径可以在服务器-DTP 和用户-DTP 之间，或在两个服务器-DTP 之间。数据端口被动数据传输过程在数据端口（data port）上“侦听”来自主动传输过程的连接，以便打开数据连接。DTP数据传输过程（data transfer process）建立和管理数据连接。 DTP 可以是被动的或主动的。end-of-file行尾（end-of-file）顺序定义了打印行的分隔。顺序是回车，然后是换行。EOF文件结束条件，用于定义正在传输的文件的结尾。EOR记录结束（end-of-record）条件，定义正在传输的记录的结束。错误恢复允许用户从某些错误中恢复的过程，例如主机系统或传输过程的故障。在 FTP 中，错误恢复（error recovery）可能涉及在给定检查点重新启动文件传输。FTP命令一组命令，包含从用户 FTP 流向服务器 FTP 进程的控制信息。文件一组任意长度的有序计算机数据（包括程序），由路径名唯一标识。模式通过数据连接传输数据的模式（mode）。该模式定义了传输过程中的数据格式，包括 EOR 和 EOF。 FTP 中定义的传输模式在传输模式部分中描述。NVTTelnet 协议中定义的网络虚拟终端（Network Virtual Terminal）。NVFS网络虚拟文件系统（Network Virtual File System）。使用标准命令和路径名约定定义标准网络文件系统的概念。页一个文件可以被构造为一组称为页面（page）的独立部分。 FTP 支持将不连续文件作为独立索引页面进行传输。路径名路径名（pathname）被定义为必须由用户输入文件系统以识别文件的字符串。路径名通常包含设备和/或目录名称，以及文件名规范。 FTP 尚未指定标准路径名约定。每个用户都必须遵循传输中涉及的文件系统的文件命名约定。PI协议解释器（protocol interpreter）。协议的用户端和服务器端在用户 PI 和服务器 PI 中实现了不同的角色。记录一个顺序文件可以被构造为许多称为记录（record）的连续部分。 FTP 支持记录结构，但文件不需要具有记录结构。回复回复（reply）是响应 FTP 命令从服务器通过控制连接发送给用户的确认（肯定或否定）。回复的一般形式是完成代码（包括错误代码）后跟文本字符串。代码供程序使用，文本通常供人类用户使用。服务器-DTP数据传输过程在其正常的“活动”状态下，与“侦听”数据端口建立数据连接。它设置传输和存储参数，并根据来自其 PI 的命令传输数据。 DTP 可以置于“被动”状态以进行侦听，而不是在数据端口上发起连接。服务器-FTP进程一个进程或一组进程，与用户 FTP 进程以及可能的另一个服务器协作执行文件传输功能。这些功能包括协议解释器 (protocol interpreter，PI) 和数据传输过程 (data transfer process，DTP)。服务器PI服务器协议解释器（protocol interpreter）在端口 L 上“侦听”来自用户 PI 的连接并建立控制通信连接。它从用户 PI 接收标准 FTP 命令，发送回复，并管理服务器 DTP。类型用于数据传输和存储的数据表示类型（type）。类型意味着数据存储时间和数据传输时间之间的某些转换。 FTP 中定义的表示类型在“建立数据连接”部分中描述。用户希望获得文件传输服务的个人或代表个人的进程。人类用户（user）可以直接与服务器 FTP 进程交互，但首选使用用户 FTP 进程，因为协议设计侧重于自动机。用户-DTP数据传输进程在数据端口上“侦听”来自服务器 FTP 进程的连接。如果两台服务器在它们之间传输数据，则用户 DTP 处于非活动状态。用户FTP进程一组功能，包括协议解释器、数据传输过程和用户界面，它们与一个或多个服务器-FTP 过程共同执行文件传输功能。用户界面允许在与用户的命令-回复对话中使用本地语言。用户PI用户协议解释器启动从它的端口 U 到服务器 FTP 进程的控制连接，启动 FTP 命令，并在该进程是文件传输的一部分时管理用户 DTP。2.3、 FTP模型考虑到上述定义，可以为 FTP 服务绘制以下模型（如图 1 所示）。图 1 FTP 使用模型注意： 1. 数据连接可用于任一方向。2. 数据连接不必一直存在。在图 1 描述的模型中，用户协议解释器启动控制连接。控制连接遵循 Telnet 协议。在用户启动时，标准的 FTP 命令由用户 PI 生成并通过控制连接传输到服务器进程。 （用户可以建立到服务器-FTP 的直接控制连接，例如从 TAC 终端，并独立生成标准 FTP 命令，绕过用户-FTP 过程。）标准回复从服务器-PI 发送到用户- PI 通过控制连接响应命令。FTP 命令指定数据连接的参数（数据端口、传输模式、表示类型和结构）和文件系统操作的性质（存储、检索、追加、删除等）。用户-DTP 或其指定者应“监听”指定的数据端口，服务器根据指定的参数发起数据连接和数据传输。需要注意的是，数据端口不必在通过控制连接发起 FTP 命令的同一台主机上，但用户或用户 FTP 进程必须确保在指定的数据端口上“监听”。还应注意，数据连接可用于同时发送和接收。在另一种情况下，用户可能希望在两个主机之间传输文件，这两个主机都不是本地主机。用户建立到两台服务器的控制连接，然后安排它们之间的数据连接。以这种方式，控制信息被传递给用户 PI，但数据在服务器数据传输过程之间传输。以下是此服务器-服务器交互的模型。图2该协议要求在进行数据传输时打开控制连接。用户有责任在使用完 FTP 服务后请求关闭控制连接，而采取行动的是服务器。如果在没有命令的情况下关闭控制连接，服务器可能会中止数据传输。FTP和Telnet的关系：FTP 在控制连接上使用 Telnet 协议。这可以通过两种方式实现：第一，用户PI或服务器PI可以直接在自己的程序中实现Telnet协议的规则；或者，第二，用户PI或服务器PI可以利用系统中现有的Telnet模块。易于实现、共享代码和模块化编程支持第二种方法。效率和独立性支持第一种方法。实际上，FTP 对 Telnet 协议的依赖很少，因此第一种方法不一定涉及大量代码。3、 数据传输功能文件仅通过数据连接传输。控制连接用于传输命令，这些命令描述了要执行的功能以及对这些命令的回复（参见 FTP 回复部分）。几个命令与主机之间的数据传输有关。这些数据传输命令包括指定如何传输数据位的 MODE 命令，以及用于定义数据表示方式的 STRUcture 和 TYPE 命令。传输和表示基本独立，但“Stream”传输模式取决于文件结构属性，如果使用“压缩”传输模式，则填充字节的性质取决于表示类型。3.1、 数据表示和存储数据从发送主机中的存储设备传输到接收主机中的存储设备。通常需要对数据执行某些转换，因为两个系统中的数据存储表示不同。例如，NVT-ASCII 在不同的系统中有不同的数据存储表示。 DEC TOPS-20s 通常将 NVT-ASCII 存储为五个 7 位 ASCII 字符，在 36 位字中左对齐。 IBM 大型机将 NVT-ASCII 存储为 8 位 EBCDIC 代码。 Multics 将 NVT-ASCII 存储为 36 位字中的四个 9 位字符。在不同系统之间传输文本时，最好将字符转换为标准 NVT-ASCII 表示。发送站点和接收站点必须在标准表示与其内部表示之间执行必要的转换。在具有不同字长的主机系统之间传输二进制数据（不是字符代码）时，会出现不同的表示问题。发送方应该如何发送数据以及接收方如何存储数据并不总是很清楚。例如，当将 32 位字节从 32 位字长系统传输到 36 位字长系统时，可能需要（出于效率和实用性的原因）将 32 位字节右对齐存储在后一种系统中的 36 位字中。在任何情况下，用户都应该可以选择指定数据表示和转换函数。应该注意的是，FTP 提供了非常有限的数据类型表示。超出此有限能力所需的转换应由用户直接执行。3.1.1、 数据类型数据表示由用户指定表示类型在 FTP 中处理。这种类型可以隐式（如在 ASCII 或 EBCDIC 中）或显式（如在本地字节中）定义用于解释的字节大小，称为“逻辑字节大小”。请注意，这与用于通过数据连接传输的字节大小无关，称为“传输字节大小”，不应将两者混淆。例如，NVT-ASCII 的逻辑字节大小为 8 位。如果类型是本地字节，则 TYPE 命令具有指定逻辑字节大小的强制性第二个参数。传输字节大小始终为 8 位。3.1.1.1、 ASCII 类型这是默认类型，必须被所有 FTP 实现接受。它主要用于传输文本文件，除非两个主机都发现 EBCDIC 类型更方便。发送方将数据从内部字符表示转换为标准的 8 位 NVT-ASCII 表示（请参阅 Telnet 规范）。接收者将数据从标准格式转换为他自己的内部格式。根据 NVT 标准， 序列应在必要时用于表示一行文本的结尾。 （请参阅数据表示和存储部分末尾的文件结构讨论。）使用标准 NVT-ASCII 表示意味着数据必须被解释为 8 位字节。下面讨论 ASCII 和 EBCDIC 类型的格式参数。3.1.1.2、 EBCDIC 类型此类型用于在使用 EBCDIC 作为其内部字符表示的主机之间进行有效传输。对于传输，数据表示为 8 位 EBCDIC 字符。字符代码是 EBCDIC 和 ASCII 类型的功能规范之间的唯一区别。出于表示结构的目的，行尾（与记录尾相反——参见结构的讨论）可能很少与 EBCDIC 类型一起使用，但在必要时应使用 字符。3.1.1.3、 IMAGE类型数据作为连续位发送，为了传输，这些位被打包成 8 位传输字节。接收站点必须将数据存储为连续位。存储系统的结构可能需要将文件（或每个记录，对于记录结构的文件）填充到某个方便的边界（字节、字或块）。这种填充必须全为零，只能出现在文件的末尾（或每条记录的末尾），并且必须有一种方法来识别填充位，以便在检索文件时可以将它们剥离。应该很好地宣传填充转换，以使用户能够在存储站点处理文件。图像类型用于文件的高效存储和检索以及二进制数据的传输。建议所有 FTP 实现都接受此类型。3.1.1.4、 LOCAL类型数据以逻辑字节传输，其大小由强制性的第二个参数字节大小指定。 Byte size 的值必须是十进制整数；没有默认值。逻辑字节大小不一定与传输字节大小相同。如果字节大小不同，则逻辑字节应连续打包，不考虑传输字节边界并在末尾添加任何必要的填充。当数据到达接收主机时，它将以依赖于逻辑字节大小和特定主机的方式进行转换。这种转换必须是可逆的（即，如果使用相同的参数，则可以检索到相同的文件）并且应该由 FTP 实现者很好地宣传。例如，用户向具有 32 位字的主机发送 36 位浮点数可以将该数据作为逻辑字节大小为 36 的本地字节发送。然后接收主机将需要存储逻辑字节，以便他们可以很容易地被操纵；在本例中，将 36 位逻辑字节放入 64 位双字就足够了。在另一个例子中，一对 36 位字长的主机可以使用 TYPE L 36 以字的形式相互发送数据。 数据将以 8 位传输字节打包发送，以便 9 个传输字节携带两个主机字。3.1.1.5、 格式控制ASCII 和 EBCDIC 类型也采用第二个（可选）参数；这是为了指示哪种垂直格式控件（如果有）与文件相关联。 FTP 中定义了以下数据表示类型：字符文件可以出于以下三个目的之一传输到主机：用于打印、存储和以后检索，或用于处理。如果发送文件进行打印，接收主机必须知道垂直格式控件是如何表示的。在第二种情况下，必须可以将文件存储在主机上，然后以完全相同的形式检索它。最后，应该可以将文件从一台主机移动到另一台主机并在第二台主机上处理该文件而不会出现不必要的麻烦。单一的 ASCII 或 EBCDIC 格式不能满足所有这些条件。因此，这些类型具有指定以下三种格式之一的第二个参数：3.1.1.5.1、 NON PRINT如果省略第二个（格式）参数，这是要使用的默认格式。所有 FTP 实现都必须接受非输出格式。该文件不需要包含垂直格式信息。如果将其传递给输出进程，则该进程可能会假定间距和边距的标准值。通常，这种格式将用于处理或仅用于存储的文件。3.1.1.5.2、 Telnet 格式控制该文件包含 ASCII/EBCDIC 垂直格式控件（即 、、、、），输出进程将对其进行适当解释。 ，在这个序列中，也表示行尾。3.1.1.5.3、 传输控制 (ASA)该文件包含 ASA (FORTRAN) 垂直格式控制字符。 （参见 RFC 740 附录 C；和 ACM 通信，第 7 卷，第 10 期，第 606 页，1964 年 10 月。）在根据 ASA 标准格式化的行或记录中，第一个字符不打印.相反，它应该用于确定在打印记录的其余部分之前应该发生的纸张的垂直移动。ASA 标准规定了以下控制字符：显然，输出进程必须有某种方式来区分结构实体的结尾。如果文件有记录结构（见下文），这没问题；记录将在传输和存储过程中明确标记。如果文件没有记录结构， 行尾序列用于分隔打印行，但这些格式效应器会被 ASA 控件覆盖。3.1.2、 数据结构除了不同的表示类型外，FTP 还允许指定文件的结构。 FTP中定义了三种文件结构：文件结构，这里没有内部结构，文件被认为是一个连续的数据字节序列，记录结构，其中文件由顺序记录组成，和页面结构，其中文件由独立的索引页面组成。如果未使用 STRUcture 命令，则默认采用文件结构，但所有 FTP 实现都必须接受“文本”文件（即具有 TYPE ASCII 或 EBCDIC 的文件）的文件和记录结构。文件的结构将影响文件的传输模式（参见传输模式部分）以及文件的解释和存储。文件的“自然”结构将取决于存储文件的主机。源代码文件通常以固定长度记录的形式存储在 IBM 大型机上，但在 DEC TOPS-20 上作为分隔为行的字符流（例如通过 ）存储。如果要在此类不同站点之间传输文件有用，则一个站点必须有某种方式来识别另一个站点对文件的假设。由于一些站点天生面向文件，而另一些网站天生面向记录，如果将具有一种结构的文件发送到面向另一种结构的主机，则可能会出现问题。如果将带有记录结构的文本文件发送到面向文件的主机，则该主机应根据记录结构对文件应用内部转换。显然，这种转换应该是有用的，但它也必须是可逆的，以便可以使用记录结构检索相同的文件。在将具有文件结构的文件发送到面向记录的主机的情况下，存在主机应使用什么标准将文件划分为可在本地处理的记录的问题。如果此划分是必要的，则 FTP 实现应使用行尾序列， 用于 ASCII，或 用于 EBCDIC 文本文件，作为分隔符。如果 FTP 实现采用此技术，则必须准备好在使用文件结构检索文件时反转转换。3.1.2.1、 DATA结构如果未使用 STRUCture 命令，则默认采用文件结构（DATA STRUCTURES）。在文件结构中，没有内部结构，文件被认为是一个连续的数据字节序列。3.1.2.2、 记录结构所有 FTP 实现都必须接受“文本”文件（即具有 TYPE ASCII 或 EBCDIC 的文件）的记录结构（RECORD STRUCTURE）。在记录结构中，文件由顺序记录组成。3.1.2.3、 页面结构为了传输不连续的文件，FTP 定义了页面结构。这种类型的文件有时被称为“随机访问文件/random access files”，甚至被称为“多孔文件/holey files”。在这些文件中，有时还有与整个文件相关联的其他信息（例如，文件描述符），或与文件的一部分（例如，页面访问控制），或两者都有。在 FTP 中，文件的部分称为页面。为了提供各种页面大小和相关信息，每个页面都带有一个页面标题。页眉具有以下定义的字段：标题长度页头中包含该字节的逻辑字节数。最小标题长度为 4。页面索引文件此部分的逻辑页码。这不是本页的传输序号，而是用于标识文件本页的索引。数据长度页数据中的逻辑字节数。最小数据长度为 0。页面类型这是页面的类型。定义了以下页面类型：0 = 最后一页这用于指示分页结构化传输的结束。头部长度必须为4，数据长度必须为0。1 = 简单页面这是没有页面级关联控制信息的简单分页文件的正常类型。标头长度必须为 4。2 = 描述符页该类型用于传输文件整体的描述信息。3 = 访问控制页面此类型包括带有页面级访问控制信息的分页文件的附加头字段。标头长度必须为 5。可选字段更多的报头字段可用于提供每页控制信息，例如每页访问控制。所有字段的长度都是一个逻辑字节。逻辑字节大小由 TYPE 命令指定。有关更多详细信息和页面结构中的特定案例，请参阅附录1。关于参数的注意事项：如果检索的版本与最初传输的版本相同，则必须使用相同的参数存储和检索文件。相反，如果用于存储和检索文件的参数相同，则 FTP 实现必须返回与原始文件相同的文件。3.2、 建立数据连接传输数据的机制包括建立到适当端口的数据连接和选择传输参数。用户和服务器 DTP 都有一个默认数据端口。用户进程默认数据端口与控制连接端口（即 U）相同。服务器进程默认数据端口是与控制连接端口（即 L-1）相邻的端口。传输字节大小为 8 位字节。此字节大小仅与数据的实际传输相关；它与主机文件系统中的数据表示无关。被动数据传输过程（这可能是用户 DTP 或第二个服务器 DTP）应在发送传输请求命令之前“侦听”数据端口。 FTP 请求命令确定数据传输的方向。服务器在收到传输请求后，将启动与端口的数据连接。建立连接后，DTP 之间的数据传输开始，服务器 PI 向用户 PI 发送确认回复。每个 FTP 实现都必须支持使用默认数据端口，并且只有 USER-PI 可以发起对非默认端口的更改。用户可以使用 PORT 命令指定备用数据端口。用户可能希望将文件转储到 TAC 行式输出或从第三方主机检索。在后一种情况下，用户 PI 与两个服务器 PI 建立控制连接。然后（通过 FTP 命令）告诉一台服务器“侦听”另一台将启动的连接。用户 PI 向一个服务器 PI 发送一个 PORT 命令，指示另一个服务器的数据端口。最后，两者都被发送适当的传输命令。在用户控制器和服务器之间发送的命令和回复的确切顺序在 FTP 回复部分定义。通常，服务器负责维护数据连接——启动和关闭它。例外情况是当用户 DTP 以需要关闭连接以指示 EOF 的传输模式下发送数据时。服务器必须在以下条件下关闭数据连接：1、服务器已经完成发送数据的传输模式，需要close表示EOF。2、服务器收到用户的 ABORT 命令。3、端口规格由用户的命令更改。4、控制连接被合法或以其他方式关闭。5、发生不可恢复的错误情况。否则关闭是一个服务器选项，服务器必须仅通过 250 或 226 回复向用户进程指示执行该选项。3.3、 数据连接管理默认数据连接端口：所有 FTP 实现都必须支持使用默认数据连接端口，并且只有 User-PI 可以启动非默认端口的使用。协商非默认数据端口：用户 PI 可以使用 PORT 命令指定非默认用户端数据端口。 User-PI 可以通过 PASV 命令请求服务器端识别一个非默认的服务器端数据端口。由于连接是由地址对定义的，这些操作中的任何一个都足以获得不同的数据连接，但仍然允许执行这两个命令以在数据连接的两端使用新端口。数据连接的重用：当使用数据传输的流模式时，必须通过关闭连接来指示文件的结尾。如果要在会话中传输多个文件，这会导致问题，因为 TCP 需要将连接记录保留一段时间以保证可靠通信。因此无法立即重新打开连接。这个问题有两种解决方案：第一个是协商一个非默认端口。二是使用另一种传输方式。关于传输模式的评论。流传输模式本质上是不可靠的，因为人们无法确定连接是否过早关闭。其他传输模式（块、压缩）不会关闭连接以指示文件结束。它们具有足够的 FTP 编码，可以解析数据连接以确定文件的结尾。因此，使用这些模式可以让数据连接保持打开状态以进行多个文件传输。3.4、 传输模式传输数据的下一个考虑因素是选择合适的传输模式。共有三种模式：一种是格式化数据并允许重新启动程序；一种还压缩数据以实现高效传输；以及一种在很少或不进行处理的情况下传递数据的方法。在最后一种情况下，模式与结构属性交互以确定处理类型。在压缩模式下，表示类型决定了填充字节。所有数据传输都必须以文件结束符 (EOF) 完成，该文件结束符可以通过关闭数据连接来明确说明或暗示。对于具有记录结构的文件，所有记录结束标记 (EOR) 都是明确的，包括最后一个。对于以页面结构传输的文件，使用“最后一页”页面类型。注意：在本节的其余部分，字节表示“传输字节”，除非另有明确说明。为了标准化传输的目的，发送主机将其内部的行尾或记录结束表示转换为传输模式和文件结构规定的表示，而接收主机将对其内部表示进行逆转换。 IBM 大型机记录计数字段在另一台主机上可能无法识别，因此记录结束信息可能在流模式下作为两字节控制代码传输，或者作为块或压缩模式描述符中的标志位传输。没有记录结构的 ASCII 或 EBCDIC 文件中的行尾应分别由 或 指示。由于这些转换意味着某些系统需要额外的工作，因此传输非记录结构化文本文件的相同系统可能希望使用二进制表示和流模式进行传输。FTP中定义了以下传输模式：3.4.1、 流模式数据以字节流的形式传输。对使用的表示类型没有限制；记录结构是允许的。在记录结构文件中，EOR 和 EOF 将分别由一个两字节的控制代码表示。控制代码的第一个字节全是 1，即转义字符。对于 EOR，第二个字节的低位将打开，其他位置为零，而 EOF 的第二个低位将打开；也就是说，该字节的 EOR 值为 1，EOF 值为 2。 EOR 和 EOF 可以通过打开两个低位（即值 3）在传输的最后一个字节上一起指示。如果打算将全 1 的一个字节作为数据发送，则应在控制代码的第二个字节中重复该字节。如果结构是文件结构，EOF由发送主机关闭数据连接指示，所有字节都是数据字节。3.4.2、 块模式该文件作为一系列数据块传输，前面有一个或多个报头字节。头字节包含计数字段和描述符代码。计数字段以字节为单位指示数据块的总长度，从而标记下一个数据块的开始（没有填充位）。描述符代码定义：文件中的最后一个块 (EOF) 记录中的最后一个块 (EOR)、重新启动标记（请参阅错误恢复和重新启动部分）或可疑数据（即，正在传输的数据被怀疑有错误并且是不可靠的）。最后一个代码不是用于 FTP 中的错误控制。它的动机是交换某些类型的数据（例如地震或天气数据）的站点希望发送和接收所有数据，尽管本地错误（例如“磁带读取错误”），但在传输中表明某些部分是可疑的）。在这种模式下允许记录结构，并且可以使用任何表示类型。头部由三个字节组成。头信息的24位中，低16位代表字节数，高8位代表描述符代码，如下所示。区块头描述符代码由描述符字节中的位标志指示。分配了四个代码，其中每个代码编号是字节中相应位的十进制值。通过这种编码，对于特定块可能存在不止一个描述符编码条件。 可以标记尽可能多的位。重新启动标记作为整数个 8 位字节嵌入数据流中，表示控制连接上使用的语言（例如，默认值--NVT-ASCII）中的可打印字符。 （空格，在适当的语言中）不得在重新启动标记内使用。例如，要传输一个 6 个字符的标记，将发送以下内容：3.4.3、 压缩模式要发送的信息有三种：常规数据，以字节串形式发送； 压缩数据，包括复制或填充； 和控制信息，以两字节的转义序列发送。 如果发送了 n>0 个字节（最多 127 个）的常规数据，则这 n 个字节前面是一个字节，其中最左边的位设置为 0，最右边的 7 位包含数字 n。字节串：n 个数据字节的字符串 d(1),..., d(n)计数 n 必须为正。为了压缩数据字节 d 的 n 个复制的字符串，发送以下 2 个字节：复制字节：一串n个填充字节可以压缩成一个字节，填充字节随表示类型不同而不同。 如果类型为 ASCII 或 EBCDIC，则填充字节为 （空格，ASCII 代码 32，EBCDIC 代码 64）。 如果类型是图像或本地字节，则填充符为零字节。填充字符串：转义序列是一个双字节，第一个是转义字节（全为零），第二个包含块模式中定义的描述符代码。描述符代码与块模式中的含义相同，适用于后续的字节串。压缩模式对于在非常大的网络传输中以一点额外的 CPU 成本获得增加的带宽很有用。它可以最有效地用于减小输出文件的大小，例如由 RJE 主机生成的文件。3.5、 错误恢复和重启没有检测数据传输中丢失或加扰的位的规定；这一级别的错误控制由 TCP 处理。但是，提供了重新启动程序来保护用户免受严重的系统故障（包括主机、FTP 进程或底层网络的故障）。重启程序仅针对数据传输的块和压缩模式定义。它要求数据的发送方在带有一些标记信息的数据流中插入一个特殊的标记代码。标记信息仅对发送方有意义，但必须由控制连接的默认或协商语言（ASCII 或 EBCDIC）的可打印字符组成。标记可以表示位计数、记录计数或系统可以用来识别数据检查点的任何其他信息。数据接收方如果执行了重启程序，就会在接收系统中标记该标记的对应位置，并将该信息返回给用户。在系统出现故障的情况下，用户可以通过 FTP 重新启动程序识别标记点来重新启动数据传输。以下示例说明了重新启动过程的使用。数据的发送方在数据流中的方便点插入适当的标记块。接收主机在其文件系统中标记相应的数据点，并将最后已知的发送者和接收者标记信息直接或通过 110 回复中的控制连接（取决于谁是发送者）传送给用户。在系统故障的情况下，用户或控制器进程通过发送带有服务器标记代码作为参数的重新启动命令，在最后一个服务器标记处重新启动服务器。重启命令通过控制连接传输，紧随其后的是发生系统故障时正在执行的命令（如 RETR、STOR 或 LIST）。4、 文件传输功能从用户 PI 到服务器 PI 的通信通道建立为从用户到标准服务器端口的 TCP 连接。用户协议解释器负责发送FTP命令并解释收到的回复；服务器 PI 解释命令、发送回复并指示其 DTP 建立数据连接并传输数据。如果数据传输的第二方（被动传输过程）是user-DTP，那么它是通过user-FTP主机的内部协议进行管理的；如果它是第二个服务器 DTP，则它由来自用户 PI 的 PI on 命令控制。 FTP 回复将在下一节讨论。在本节中一些命令的描述中，明确说明可能的回复是有帮助的。4.1、 FTP 命令4.1.1、 访问控制命令以下命令指定访问控制标识符（命令代码显示在括号中）。用户名（USER）参数字段是标识用户的 Telnet 字符串。用户标识是服务器访问其文件系统所需的标识。此命令通常是用户在建立控制连接后发送的第一个命令（某些服务器可能需要此命令）。某些服务器也可能需要密码和/或帐户命令形式的附加标识信息。服务器可以允许在任何时候输入新的 USER 命令以更改访问控制和/或记帐信息。这具有刷新已提供的任何用户、密码和帐户信息并再次开始登录序列的效果。所有传输参数都保持不变，任何正在进行的文件传输都在旧的访问控制参数下完成。密码 (PASS)参数字段是指定用户密码的 Telnet 字符串。此命令必须紧跟在用户名命令之后，并且对于某些站点，完成用户的识别以进行访问控制。由于密码信息非常敏感，因此通常需要“屏蔽”它或禁止输入。服务器似乎没有万无一失的方法来实现这一点。因此，用户 FTP 进程有责任隐藏敏感的密码信息。帐户 (ACCT)参数字段是标识用户帐户的 Telnet 字符串。该命令不一定与 USER 命令相关，因为某些站点可能需要帐户才能登录，而其他站点仅用于特定访问，例如存储文件。在后一种情况下，命令可能随时到达。有回复代码来区分这些情况的自动化：当登录需要帐户信息时，对成功的 PASSword 命令的响应是回复代码 332。另一方面，如果登录不需要帐户信息，则回复 a成功的 PASSword 命令是 230；如果在对话中稍后发出的命令需要帐户信息，则服务器应分别返回 332 或 532 回复，具体取决于它是存储（等待接收 ACCounT 命令）还是丢弃该命令。更改工作目录 (CWD)此命令允许用户使用不同的目录或数据集进行文件存储或检索，而无需更改其登录或记帐信息。传输参数同样不变。参数是指定目录或其他系统相关文件组指示符的路径名。更改到父目录 (CDUP)此命令是 CWD 的一个特例，包含该命令是为了简化在具有不同命名父目录语法的操作系统之间传输目录树的程序的实现。回复码应与CWD 的回复码相同。有关详细信息，请参阅附录2。结构挂载 (SMNT)此命令允许用户挂载不同的文件系统数据结构，而无需更改其登录或记帐信息。传输参数同样不变。参数是指定目录或其他系统相关文件组指示符的路径名。重新初始化（REIN）此命令会终止 USER，刷新所有 I/O 和帐户信息，但允许完成正在进行的任何传输。所有参数都重置为默认设置，控制连接保持打开状态。这与用户在打开控制连接后立即发现自己的状态相同。可能会出现 USER 命令。退出（QUIT）此命令终止用户，如果文件传输不在进行中，服务器将关闭控制连接。如果文件传输正在进行，连接将保持打开状态以响应结果，然后服务器将关闭它。如果用户进程正在为多个用户传输文件，但不希望为每个用户关闭然后重新打开连接，则应使用 REIN 命令而不是 QUIT。控制连接的意外关闭将导致服务器采取有效的中止 (ABOR) 和注销 (QUIT) 操作。4.1.2、 传输参数命令所有数据传输参数都有默认值，只有当默认参数值需要改变时，才需要指定数据传输参数的命令。默认值是最后指定的值，或者如果未指定值，则标准默认值如此处所述。这意味着服务器必须“记住”适用的默认值。命令可以按任何顺序排列，但它们必须在 FTP 服务请求之前。以下命令指定数据传输参数：数据端口（PORT）参数是用于数据连接的数据端口的 HOST-PORT 规范。用户和服务器数据端口都有默认值，一般情况下不需要此命令及其回复。如果使用此命令，则参数是 32 位 Internet 主机地址和 16 位 TCP 端口地址的串联。该地址信息被分成 8 位字段，每个字段的值作为十进制数（以字符串表示）传输。字段以逗号分隔。端口命令将是：PORT h1,h2,h3,h4,p1,p2其中 h1 是 Internet 主机地址的高 8 位。被动 (PASV)此命令请求服务器 DTP 在数据端口（不是其默认数据端口）上“侦听”并等待连接而不是在接收到传输命令时启动连接。 对此命令的响应包括此服务器正在侦听的主机和端口地址。表示类型（TYPE）参数指定数据表示和存储部分中描述的表示类型。 几种类型采用第二个参数。 第一个参数由单个 Telnet 字符表示，ASCII 和 EBCDIC 的第二个 Format 参数也是如此； 本地字节的第二个参数是一个十进制整数，表示字节大小。 参数由 （空格，ASCII 代码 32）分隔。为类型分配了以下代码：默认表示类型是 ASCII 非打印。 如果更改了 Format 参数，并且稍后仅更改了第一个参数，则 Format 将返回到非打印默认值。文件结构 (STRU)参数是一个单独的 Telnet 字符代码，指定了数据表示和存储部分中描述的文件结构。为结构分配了以下代码：F - File (no record structure) R - Record structure P - Page structure默认结构是文件。传输模式（MODE）参数是单个 Telnet 字符代码，指定传输模式部分中描述的数据传输模式。为传输模式分配了以下代码：S - Stream B - Block C - Compressed默认传输模式为 Stream。4.1.3、 FTP 服务命令FTP 服务命令定义了用户请求的文件传输或文件系统功能。 FTP 服务命令的参数通常是路径名。路径名的语法必须符合服务器站点约定（适用标准默认值）和控制连接的语言约定。建议的默认处理是使用最后指定的设备、目录或文件名，或为本地用户定义的标准默认值。除了“rename from”命令后面必须跟“rename to”命令并且重启命令后面必须跟中断的服务命令（例如，STOR或RETR）之外，命令可以是任何顺序。响应 FTP 服务命令传输的数据应始终通过数据连接发送，某些信息性回复除外。以下命令指定 FTP 服务请求：检索 (RETR)此命令使服务器 DTP 将路径名中指定的文件副本传输到数据连接另一端的服务器或用户 DTP。服务器站点上文件的状态和内容不受影响。存储 (STOR)该命令使服务器-DTP 接受通过数据连接传输的数据并将数据作为文件存储在服务器站点。如果路径名中指定的文件存在于服务器站点，则其内容应由正在传输的数据替换。如果路径名中指定的文件不存在，则会在服务器站点上创建一个新文件。唯一存储 (STOU)此命令的行为与 STOR 类似，不同之处在于将在当前目录中以对该目录唯一的名称创建结果文件。 250 Transfer Started 响应必须包含生成的名称。APPEND（带创建）（APPE）该命令使服务器-DTP 接受通过数据连接传输的数据并将数据存储在服务器站点的文件中。如果路径名中指定的文件存在于服务器站点，则数据应附加到该文件中；否则将在服务器站点创建路径名中指定的文件。分配（ALLO）某些服务器可能需要此命令来保留足够的存储空间以容纳要传输的新文件。参数应是一个十进制整数，表示要为文件保留的存储的字节数（使用逻辑字节大小）。对于使用记录或页面结构发送的文件，可能还需要最大记录或页面大小（以逻辑字节为单位）；这由命令的第二个参数字段中的十进制整数表示。第二个参数是可选的，但是当出现时应该用三个 Telnet 字符 R 与第一个参数分开。该命令后面应跟有 STORe 或 APPEnd 命令。 ALLO 命令应该被那些不需要事先声明文件最大大小的服务器视为 NOOP（无操作），那些只对最大记录或页面大小感兴趣的服务器应该接受第一个参数并忽略它。重启（REST）参数字段表示要重新启动文件传输的服务器标记。此命令不会导致文件传输，而是跳过文件到指定的数据检查点。该命令应紧跟在适当的 FTP 服务命令之后，该命令将使文件传输恢复。重命名自 (RNFR)此命令指定要重命名的文件的旧路径名。此命令必须紧跟在指定新文件路径名的“重命名为”命令之后。重命名为（RNTO）此命令指定在紧接在前面的“rename from”命令中指定的文件的新路径名。这两个命令一起导致文件被重命名。中止（ABOR）此命令告诉服务器中止先前的 FTP 服务命令和任何相关的数据传输。 abort 命令可能需要“特殊操作”，如 FTP 命令部分所述，以强制服务器识别。如果之前的命令已经完成（包括数据传输），则不会采取任何行动。服务器不关闭控制连接，但必须关闭数据连接。服务器收到该命令有两种情况：（1）FTP服务命令已经完成，或者（2）FTP服务命令还在进行中。在第一种情况下，服务器关闭数据连接（如果它是打开的）并以 226 回复响应，表示成功处理了 abort 命令。第二种情况，服务器中止正在进行的FTP服务并关闭数据连接，返回426回复，表示服务请求异常终止。然后服务器发送 226 回复，表示成功处理了 abort 命令。删除（DELE）此命令会导致在服务器站点删除路径名中指定的文件。如果需要额外的保护级别（例如查询“您真的要删除吗？”），则应由用户 FTP 进程提供。删除目录 (RMD)此命令会导致将路径名中指定的目录作为目录（如果路径名是绝对的）或作为当前工作目录的子目录（如果路径名是相对的）删除。见附录二。创建目录 (MKD)此命令使路径名中指定的目录创建为目录（如果路径名是绝对的）或当前工作目录的子目录（如果路径名是相对的）。见附录二。打印工作目录 (PWD)此命令导致在回复中返回当前工作目录的名称。见附录二。列表（LIST）此命令会导致从服务器向被动 DTP 发送一个列表。如果路径名指定了一个目录或其他文件组，则服务器应传输指定目录中的文件列表。如果路径名指定了一个文件，那么服务器应该发送有关该文件的当前信息。空参数表示用户当前的工作目录或默认目录。数据传输通过 ASCII 类型或 EBCDIC 类型的数据连接进行。 （用户必须确保 TYPE 是适当的 ASCII 或 EBCDIC）。由于文件上的信息可能因系统而异，因此该信息可能难以在程序中自动使用，但对人类用户可能非常有用。名称列表 (NLST)此命令导致目录列表从服务器发送到用户站点。路径名应指定目录或其他特定于系统的文件组描述符；空参数意味着当前目录。服务器将返回文件名称流，不返回其他信息。数据将以 ASCII 或 EBCDIC 类型作为由 或 分隔的有效路径名字符串通过数据连接传输。 （同样，用户必须确保 TYPE 正确。）此命令旨在返回信息，程序可以使用这些信息来自动进一步处理文件。例如，在执行“多次获取”功能时。站点参数（SITE）服务器使用此命令来提供特定于其系统的服务，这些服务对于文件传输必不可少，但不够通用，无法作为命令包含在协议中。这些服务的性质和它们的语法规范可以在对 HELP SITE 命令的回复中说明。系统 (SYST)此命令用于查找服务器上的操作系统类型。答复应将当前版本的指定编号文档 [4] 中列出的系统名称作为其第一个单词。状态 (STAT)该命令将导致状态响应以回复的形式通过控制连接发送。该命令可以在文件传输期间发送（连同 Telnet IP 和同步信号 - 请参阅有关 FTP 命令的部分）在这种情况下，服务器将以正在进行的操作状态进行响应，或者它可以在文件之间发送转让。在后一种情况下，命令可能有一个参数字段。如果参数是路径名，则该命令类似于“list”命令，不同之处在于数据应通过控制连接传输。如果给出了部分路径名，服务器可能会以与该规范相关联的文件名或属性列表进行响应。如果没有给出参数，服务器应该返回关于服务器 FTP 进程的一般状态信息。这应该包括所有传输参数的当前值和连接状态。帮助（HELP）该命令将使服务器通过控制连接向用户发送有关其实现状态的有用信息。命令可以接受一个参数（例如，任何命令名称）并返回更具体的信息作为响应。回复类型为 211 或 214。建议在输入 USER 命令之前允许 HELP。服务器可以使用此回复来指定与站点相关的参数，例如，响应 HELP SITE。NOOP (NOOP)此命令不影响任何参数或以前输入的命令。除了服务器发送 OK 回复之外，它没有指定任何动作。对于控制连接上的所有通信，文件传输协议遵循 Telnet 协议的规范。由于用于 Telnet 通信的语言可能是协商选项，因此接下来两节中的所有引用都将指向“Telnet 语言”和相应的“Telnet 行尾代码”。目前，人们可能会将这些理解为 NVT-ASCII 和 。不会引用 Telnet 协议的其他规范。FTP 命令是由“Telnet 行尾代码”终止的“Telnet 字符串”。命令代码本身是由字符 （空格）终止的字母字符，如果参数跟在后面，否则为 Telnet-EOL。本节描述了命令代码和命令的语义；命令的详细语法在命令部分指定，回复序列在命令和回复排序部分讨论，说明命令使用的场景在典型 FTP 场景部分提供。FTP 命令可以划分为指定访问控制标识符、数据传输参数或 FTP 服务请求的命令。某些命令（例如 ABOR、STAT、QUIT）可以在数据传输过程中通过控制连接发送。有些服务器可能无法同时监控控制和数据连接，在这种情况下，需要采取一些特殊措施来引起服务器的注意。暂时推荐以下有序格式：1. 用户系统在Telnet流中插入Telnet“中断进程”(IP)信号。2. 用户系统发送Telnet“Synch”信号。3. 用户系统在 Telnet 流中插入命令（例如，ABOR）。4. 服务器 PI 在接收到“IP”后，扫描 Telnet 流以查找 EXACTLY ONE FTP 命令。（对于其他服务器，这可能不是必需的，但上面列出的操作应该没有异常影响。）4.2、 FTP 回复文件传输协议命令的回复旨在确保文件传输过程中请求和动作的同步，并保证用户进程始终知道服务器的状态。每个命令必须至少生成一个回复，尽管可能不止一个；在后一种情况下，必须很容易地区分多个答复。此外，一些命令出现在顺序组中，例如 USER、PASS 和 ACCT，或 RNFR 和 RNTO。如果所有前面的命令都成功，则回复显示中间状态的存在。序列中任何一点的失败都需要从头开始重复整个序列。命令-回复序列的细节在下面的一组状态图中得到了明确的说明。FTP 回复由一个三位数字（作为三个字母数字字符传输）和一些文本组成。该数字旨在供自动机使用以确定接下来要进入的状态；该文本适用于人类用户。这三个数字包含足够的编码信息，用户进程（User-PI）不需要检查文本，并且可能会丢弃它或将其传递给用户，视情况而定。特别是，文本可能依赖于服务器，因此每个回复代码可能有不同的文本。回复被定义为包含 3 位代码，后跟空格 ，后跟一行文本（已指定某些最大行长度），并以 Telnet 行尾代码终止。但是，在某些情况下，文本比一行还长。在这些情况下，完整的文本必须用括号括起来，以便用户进程知道何时可以停止读取回复（即停止处理控制连接上的输入）并去做其他事情。这需要在第一行使用特殊格式来指示多行即将到来，并在最后一行使用另一个格式将其指定为最后一行。其中至少有一个必须包含适当的回复代码以指示事务的状态。为了满足所有派系，决定第一行和最后一行代码应该相同。因此，多行回复的格式是第一行以确切所需的回复代码开头，紧接着是连字符“-”（也称为减号），然后是文本。最后一行将以相同的代码开头，紧接着是空格 、可选的一些文本和 Telnet 行尾代码。例如：123-First line Second line 234 A line beginning with numbers 123 The last line然后，用户进程只需要在一行的开头搜索第二次出现的相同回复代码，后跟 （空格），并忽略所有中间行。如果中间线以 3 位数字开头，则服务器必须填充前面以避免混淆。该方案允许将标准系统例程用于回复信息（例如用于 STAT 回复），并附加“人工”第一行和最后一行。在极少数情况下，这些例程能够在任何行的开头生成三个数字和一个空格，每个文本行的开头应该被一些中性文本偏移，例如空格。该方案假设多行回复可能不会嵌套。回复的三位数字各有特殊意义。这旨在允许用户进程进行一系列非常简单到非常复杂的响应。第一个数字表示响应是好、坏还是不完整。（参见状态图），一个简单的用户进程将能够通过简单地检查第一个数字来确定其下一步操作（按计划进行、重做、裁员等）。想要知道发生了什么样的错误（例如文件系统错误、命令语法错误）的用户进程可以检查第二个数字，保留第三个数字用于信息的最佳分级（例如，没有前面的 RNFR 的 RNTO 命令） .回复代码的第一位数字有五个值：1yz：正面初步答复正在启动请求的操作；在继续执行新命令之前期待另一个答复。 （用户进程在完成回复之前发送另一个命令将违反协议；但服务器 FTP 进程应该将任何到达的命令排队，而前一个命令正在进行中。）这种类型的回复可用于指示命令已被接受，用户进程现在可能会关注数据连接，以实现同时监控是困难的。服务器-FTP 进程最多可以发送每个命令一个 1yz 回复。2yz：主动完成回复请求的操作已成功完成。可以发起新的请求。3yz：正面中级回复命令已被接受，但请求的操作被搁置，等待收到进一步的信息。用户应发送另一个指定此信息的命令。该回复用于命令序列组。4yz：瞬态否定完成回复未接受命令且未执行请求的操作，但错误情况是暂时的，可能会再次请求操作。用户应返回到命令序列的开头（如果有）。很难为“瞬态”赋予含义，尤其是当两个不同的站点（服务器进程和用户进程）必须就解释达成一致时。 4yz 类别中的每个回复的时间值可能略有不同，但其目的是鼓励用户进程重试。确定回复是否适合 4yz 或 5yz（永久否定）类别的经验法则是，如果命令可以重复而无需更改命令形式或用户或服务器的属性（例如，命令的拼写与使用的参数相同；用户不会更改其文件访问权限或用户名；服务器不会提供新的实现。）5yz：永久否定完成回复未接受该命令且未执行请求的操作。不鼓励用户进程重复确切的请求（以相同的顺序）。甚至一些“永久性”错误条件也可以被纠正，因此人类用户可能希望在未来的某个时刻（例如，在拼写改变后，或者用户已经改变了他的目录状态。）以下功能分组编码在第二位：x0z语法 - 这些回复指的是语法错误、不适合任何功能类别的语法正确命令、未实现或多余的命令。x1z信息 - 这些是对信息请求的回复，例如状态或帮助。x2z连接 - 参考控制和数据连接的回复。x3z身份验证和记帐 - 对登录过程和记帐程序的答复。x4z至今未明。x5z文件系统 - 这些回复指示服务器文件系统相对于请求的传输或其他文件系统操作的状态。第三个数字在每个功能类别中给出了更精细的含义等级，由第二个数字指定。下面的答复列表将说明这一点。请注意，与每个回复关联的文本是推荐的，而不是强制性的，甚至可能会根据与之关联的命令而改变。另一方面，回复代码必须严格遵循上一节中的规范；也就是说，服务器实现不应该为与这里描述的情况略有不同的情况发明新的代码，而应该调整已经定义的代码。诸如 TYPE 或 ALLO 之类的命令如果成功执行并没有为用户进程提供任何新信息，将导致返回 200 回复。如果该命令没有由特定的 Server-FTP 进程执行，因为它与该计算机系统无关，例如在 TOPS20 站点上的 ALLO，仍然需要肯定完成答复，以便简单的用户进程知道它可以继续它的行动方针。在这种情况下使用 202 回复，例如回复文本：“无需分配存储空间”。另一方面，如果该命令请求非特定于站点的操作并且未实施，则响应为 502。对此的改进是对已实施但请求未实施参数的命令的 504 回复。4.2.1 功能组回复码200 命令完成。500 语法错误，命令无法识别。这可能包括命令行太长等错误。501 参数或参数中的语法错误。202 命令未执行，在此站点上是多余的。502 命令未执行。503 错误的命令序列。504 该参数未执行命令。110 重新启动标记回复。 在这种情况下，文本是准确的，而不是留给特定的实现； 它必须是：MARK yyyy = mmmm其中 yyyy 是用户进程数据流标记，以及 mmmm 服务器的等效标记（注意标记和“=”之间的空格）。211 系统状态，或系统帮助回复。212 目录状态。213 文件状态。214 帮助信息。关于如何使用服务器或特定非标准命令的含义。此回复仅对人类用户有用。215 命名系统类型。其中 NAME 是 Assigned Numbers 文档中列表中的正式系统名称。120 服务在 nnn 分钟内准备就绪。220 为新用户准备好服务。221 服务关闭控制连接。适当时注销。421 服务不可用，正在关闭控制连接。如果服务知道它必须关闭，这可能是对任何命令的回复。125 数据连接已打开；转移开始。225 数据连接打开；没有正在进行的转移。425 无法打开数据连接。226 关闭数据连接。请求的文件操作成功（例如，文件传输或文件中止）。426 连接关闭；传输中止。227 进入被动模式 (h1,h2,h3,h4,p1,p2)。230 用户登录，继续。530 未登录。331 用户名好，需要密码。332 需要账号登录。532 需要帐户来存储文件。150 文件状态正常； 即将打开数据连接。250 请求的文件操作正常，已完成。257 “路径名”已创建。350 请求的文件操作等待进一步的信息。450 未采取请求的文件操作。 文件不可用（例如，文件忙）。550 未采取请求的操作。 文件不可用（例如，未找到文件、无法访问）。451 请求的操作已中止。 处理中的局部错误。551 请求的操作已中止。 页面类型未知。452 未采取请求的操作。 系统存储空间不足。552 请求的文件操作已中止。 超出存储分配（对于当前目录或数据集）。553 未采取请求的操作。 不允许使用文件名。4.2.2 回复码数字顺序表110 重新启动标记回复。 在这种情况下，文本是准确的，而不是留给特定的实现； 它必须是：MARK yyyy = mmmm其中 yyyy 是用户进程数据流标记，以及 mmmm 服务器的等效标记（注意标记和“=”之间的空格）。120 服务在 nnn 分钟内准备就绪。125 数据连接已打开；转移开始。150 文件状态正常；即将打开数据连接。200 命令没问题。202 命令未执行，在此站点上是多余的。211 系统状态，或系统帮助回复。212 目录状态。213 文件状态。214 帮助信息。关于如何使用服务器或特定非标准命令的含义。此回复仅对人类用户有用。215 命名系统类型。其中 NAME 是 Assigned Numbers 文档中列表中的正式系统名称。220 为新用户准备好服务。221 服务关闭控制连接。适当时注销。225 数据连接打开；没有正在进行的转移。226 关闭数据连接。请求的文件操作成功（例如，文件传输或文件中止）。227 进入被动模式 (h1,h2,h3,h4,p1,p2)。230 用户登录，继续。250 请求的文件操作正常，已完成。257 “路径名”已创建。331 用户名好，需要密码。332 需要账号登录。350 请求的文件操作等待进一步的信息。421 服务不可用，正在关闭控制连接。如果服务知道它必须关闭，这可能是对任何命令的回复。425 无法打开数据连接。426 连接关闭；传输中止。450 未采取请求的文件操作。文件不可用（例如，文件忙）。451 请求的操作中止：处理中的本地错误。452 未采取请求的操作。系统存储空间不足。500 语法错误，命令无法识别。这可能包括命令行太长等错误。501 参数或参数中的语法错误。502 命令未执行。503 错误的命令序列。504 该参数未执行命令。530 未登录。532 需要帐户来存储文件。550 未采取请求的操作。文件不可用（例如，未找到文件、无法访问）。551 请求的操作中止：页面类型未知。552 请求的文件操作已中止。超出存储分配（对于当前目录或数据集）。553 未采取请求的操作。不允许使用文件名。5. 声明性规范5.1. 最低执行为了使 FTP 能够正常工作而没有不必要的错误消息，所有服务器都需要以下最低限度的实现：TYPE - ASCII Non-print MODE - Stream STRUCTURE - File, Record COMMANDS - USER, QUIT, PORT,TYPE, MODE, STRU, 对于默认值 RETR, STOR,NOOP.传输参数的默认值为：TYPE - ASCII Non-print MODE - Stream STRU - File所有主机都必须接受上述作为标准默认值。5.2.连接服务器协议解释器应“监听”端口 L。用户或用户协议解释器应启动全双工控制连接。服务器和用户进程应遵循 ARPA-Internet 协议手册 [1] 中指定的 Telnet 协议约定。服务器没有义务提供命令行的编辑，并且可能要求在用户主机中完成。在所有传输和回复完成后，服务器应用户请求关闭控制连接。用户-DTP 必须“监听”指定的数据端口；这可能是默认用户端口 (U) 或 PORT 命令中指定的端口。服务器应使用指定的用户数据端口从他自己的默认数据端口 (L-1) 启动数据连接。传输的方向和使用的端口将由 FTP 服务命令决定。请注意，所有 FTP 实现都必须支持使用默认端口的数据传输，并且只有 USER-PI 可以启动非默认端口的使用。当数据要在两台服务器 A 和 B（参见图 2）之间传输时，用户 PI C 与两个服务器 PI 建立控制连接。其中一个服务器，比如说 A，然后会收到一个 PASV 命令，告诉他在他收到传输服务命令时“监听”他的数据端口而不是启动连接。当用户 PI 收到对 PASV 命令的确认时，其中包括主机的身份和正在侦听的端口，然后用户 PI 在 PORT 命令中将 A 的端口 a 发送到 B；返回回复。然后，用户 PI 可以向 A 和 B 发送相应的服务命令。服务器 B 启动连接并继续传输。下面列出了命令-回复序列，其中消息垂直同步但水平异步：图 3数据连接应在建立数据连接部分所述的条件下由服务器关闭。如果在不需要关闭连接来指示文件结束的数据传输之后关闭数据连接，则服务器必须立即这样做。不允许等到新的传输命令之后，因为用户进程已经测试了数据连接以查看它是否需要进行“监听”； （请记住，用户必须在发送传输请求之前“监听”关闭的数据端口）。为了防止这里的竞争条件，服务器在关闭数据连接后发送回复（226）（或者如果连接保持打开，“文件传输完成”回复（250）并且用户 PI 应该等待其中之一在发出新的传输命令之前回复）。任何时候用户或服务器看到另一端正在关闭连接，它应该立即读取连接上排队的任何剩余数据并在自己端发出关闭。5.3.命令这些命令是通过控制连接传输的 Telnet 字符串，如 FTP 命令部分所述。命令功能和语义在访问控制命令、传输参数命令、FTP 服务命令和杂项命令一节中描述。命令语法在此处指定。命令以命令代码开头，后跟参数字段。命令代码是四个或更少的字母字符。大写和小写字母字符将被同等对待。因此，以下任何一项都可能代表检索命令：RETR Retr retr ReTr rETr这也适用于表示参数值的任何符号，例如 A 或 ASCII 类型的 a。 命令代码和参数字段由一个或多个空格分隔。参数字段由可变长度字符串组成，以字符序列 （回车，换行）结尾，用于 NVT-ASCII 表示； 对于其他协商语言，可能会使用不同的行尾字符。 需要注意的是，服务器在收到行尾代码之前不采取任何行动。下面在 NVT-ASCII 中指定了语法。 参数字段中的所有字符都是 ASCII 字符，包括任何 ASCII 表示的十进制整数。 方括号表示可选参数字段。 如果不采用该选项，则隐含适当的默认值。5.3.1. FTP 命令以下是FTP命令：USER <SP> <username> <CRLF> PASS <SP> <password> <CRLF> ACCT <SP> <account-information> <CRLF> CWD <SP> <pathname> <CRLF> CDUP <CRLF> SMNT <SP> <pathname> <CRLF> QUIT <CRLF> REIN <CRLF> PORT <SP> <host-port> <CRLF> PASV <CRLF> TYPE <SP> <type-code> <CRLF> STRU <SP> <structure-code> <CRLF> MODE <SP> <mode-code> <CRLF> RETR <SP> <pathname> <CRLF> STOR <SP> <pathname> <CRLF> STOU <CRLF> APPE <SP> <pathname> <CRLF> ALLO <SP> <decimal-integer> [<SP> R <SP> <decimal-integer>] <CRLF> REST <SP> <marker> <CRLF> RNFR <SP> <pathname> <CRLF> RNTO <SP> <pathname> <CRLF> ABOR <CRLF> DELE <SP> <pathname> <CRLF> RMD <SP> <pathname> <CRLF> MKD <SP> <pathname> <CRLF> PWD <CRLF> LIST [<SP> <pathname>] <CRLF> NLST [<SP> <pathname>] <CRLF> SITE <SP> <string> <CRLF> SYST <CRLF> STAT [<SP> <pathname>] <CRLF> HELP [<SP> <string>] <CRLF> NOOP <CRLF>5.3.2. FTP 命令参数上述参数字段的语法（在适用的情况下使用 BNF 表示法）是：<username> ::= <string> <password> ::= <string> <account-information> ::= <string> <string> ::= <char> | <char><string> <char> ::= any of the 128 ASCII characters except <CR> and <LF> <marker> ::= <pr-string> <pr-string> ::= <pr-char> | <pr-char><pr-string> <pr-char> ::= printable characters, any ASCII code 33 through 126 <byte-size> ::= <number> <host-port> ::= <host-number>,<port-number> <host-number> ::= <number>,<number>,<number>,<number> <port-number> ::= <number>,<number> <number> ::= any decimal integer 1 through 255 <form-code> ::= N | T | C <type-code> ::= A [<sp> <form-code>] | E [<sp> <form-code>] | I | L <sp> <byte-size> <structure-code> ::= F | R | P <mode-code> ::= S | B | C <pathname> ::= <string> <decimal-integer> ::= any decimal integer5.4.命令和回复的排序用户和服务器之间的通信旨在进行交替对话。因此，用户发出 FTP 命令，服务器以提示的主要回复进行响应。用户应该在发送进一步的命令之前等待这个初始的主要成功或失败响应。某些命令需要用户也应该等待的第二个答复。例如，这些回复可能会报告文件传输的进度或完成情况或数据连接的关闭情况。它们是对文件传输命令的辅助回复。一组重要的信息回复是连接问候语。在正常情况下，服务器会在连接完成时发送 220 回复“等待输入”。在发送任何命令之前，用户应该等待此问候消息。如果服务器无法立即接受输入，则应立即发送 120“预期延迟”回复，并在准备好时发送 220 回复。如果有延迟，用户将知道不要挂断。自发回复有时“系统”自发地有一条消息要发送给用户（通常是所有用户）。例如，“系统将在 15 分钟内停机”。 FTP 中没有规定从服务器向用户发送此类自发信息。建议将此类信息在服务器 PI 中排队，并在下一个回复中传递给用户 PI（可能使其成为多行回复）。下表列出了每个命令的替代成功和失败回复。这些必须严格遵守；服务器可以替换回复中的文本，但不能更改代码编号和特定命令回复序列所隐含的含义和动作。命令-回复序列在本节中，将介绍命令-应答序列。列出了每个命令及其可能的回复；命令组一起列出。首先列出初步答复（其后续答复缩进并在其下方），然后是肯定和否定完成，最后是中间答复，其中包含以下序列中的其余命令。此列表构成了状态图的基础，状态图将单独呈现。Connection Establishment 120 220 220 421LoginUSER 230 530 500, 501, 421 331, 332 PASS 230 202 530 500, 501, 503, 421 332 ACCT 230 202 530 500, 501, 503, 421 CWD 250 500, 501, 502, 421, 530, 550 CDUP 200 500, 501, 502, 421, 530, 550 SMNT 202, 250 500, 501, 502, 421, 530, 550LogoutREIN 120 220 220 421 500, 502 QUIT 221 500Transfer parametersPORT 200 500, 501, 421, 530 PASV 227 500, 501, 502, 421, 530 MODE 200 500, 501, 504, 421, 530 TYPE 200 500, 501, 504, 421, 530 STRU 200 500, 501, 504, 421, 530File action commandsALLO 200 202 500, 501, 504, 421, 530 REST 500, 501, 502, 421, 530 350 STOR 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 STOU 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 RETR 125, 150 (110) 226, 250 425, 426, 451 450, 550 500, 501, 421, 530 LIST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 NLST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 APPE 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 RNFR 450, 550 500, 501, 502, 421, 530 350 RNTO 250 532, 553 500, 501, 502, 503, 421, 530 DELE 250 450, 550 500, 501, 502, 421, 530 RMD 250 500, 501, 502, 421, 530, 550 MKD 257 500, 501, 502, 421, 530, 550 PWD 257 500, 501, 502, 421, 550 ABOR 225, 226 500, 501, 502, 421Informational commandsSYST 215 500, 501, 502, 421 STAT 211, 212, 213 450 500, 501, 502, 421, 530 HELP 211, 214 500, 501, 502, 421Miscellaneous commandsSITE 200 202 500, 501, 530 NOOP 200 500 4216. 状态图在这里，我们展示了一个非常简单的 FTP 实现的状态图。 仅使用回复代码的第一位数字。 每组 FTP 命令或命令序列都有一个状态图。命令分组是通过为每个命令构建一个模型然后将具有结构相同模型的命令收集在一起来确定的。对于每个命令或命令序列，存在三种可能的结果：成功 (S)、失败 (F) 和错误 (E)。 在下面的状态图中，我们使用符号 B 表示“开始”，使用符号 W 表示“等待回复”。我们首先展示代表最大组 FTP 命令的图表：此图为命令建模：ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, 和 TYPE.另一大组命令由非常相似的图表表示：此图为命令建模：APPE, LIST, NLST, REIN, RETR, STOR, 和 STOU.请注意，第二个模型也可以用于表示第一组命令，唯一的区别是在第一组中 100 系列回复是意外的，因此被视为错误，而第二组期望（有些可能需要）100 系列 回复。 请记住，每个命令最多允许一个 100 系列回复。其余的图表模型命令序列，其中最简单的可能是重命名序列：下图是 Restart 命令的简单模型：其中“cmd”是 APPE、STOR 或 RETR。我们注意到上述三个模型是相似的。 Restart 与 Rename two 的区别仅在于第二阶段对 100 系列回复的处理，而第二组期望（有些可能需要）100 系列回复。 请记住，每个命令最多允许一个 100 系列回复。最复杂的图是登录序列：最后，我们展示了一个通用图，可用于对命令和回复交换进行建模：7. 典型的 FTP 场景主机 U 上的用户想要向主机 S 传输文件/从主机 S 传输文件：通常，用户将通过中介用户 FTP 进程与服务器通信。 以下可能是一个典型的场景。 user-FTP 提示显示在括号中，'---->' 代表主机 U 到主机 S 的命令，'<----' 代表主机 S 到主机 U 的回复。8. 连接建立FTP控制连接是通过TCP在用户进程端口U和服务器进程端口L之间建立的。该协议被分配了服务端口21（25八进制），即L=21。附录1 - 页结构FTP 支持页面结构的需要主要源于支持在 TOPS-20 系统之间有效传输文件的需要，尤其是 NLS 使用的文件。TOPS-20 的文件系统基于页的概念。操作系统在将文件作为页面进行操作方面效率最高。操作系统为文件系统提供了一个接口，因此许多应用程序将文件视为连续的字符流。但是，一些应用程序直接使用底层页面结构，其中一些会创建有孔文件。TOPS-20 磁盘文件由四部分组成：路径名、页表、（可能为空的）页集和属性集。路径名在 RETR 或 STOR 命令中指定。它包括目录名、文件名、文件扩展名和代号。页表最多包含 2^18 个条目。每个条目可能是空的，也可能指向一个页面。如果不为空，也有一些页面特定的访问位；并非文件的所有页面都需要相同的访问保护。页是一组连续的 512 个字，每个字 36 位。文件的属性，在文件描述符块 (FDB) 中，包含诸如创建时间、写入时间、读取时间、写入器的字节大小、文件结束指针、读取和写入计数、备份系统磁带编号等内容， 等等。请注意，没有要求页表中的条目是连续的。在被占用的页表插槽之间可能有空的页表插槽。此外，文件指针的结尾只是一个数字。不要求它实际上指向文件中的“最后一个”数据。 TOPS-20 中的普通顺序 I/O 调用将导致文件尾指针在最后写入的数据之后被留下，但如果特定的编程系统需要，其他操作可能会导致它不是这样。事实上，在这两种特殊情况下，“有洞”文件和不在文件末尾的文件尾指针出现在 NLS 数据文件中。可以使用 FTP 传输参数发送 TOPS-20 分页文件：TYPE L 36、STRU P 和 MODE S（实际上，可以使用任何模式）。每页信息都有一个标题。每个作为逻辑字节的标头字段是一个 TOPS-20 字，因为 TYPE 是 L 36。标题字段是：Word 0: Header Length.标头长度为 5。Word 1: Page Index.如果数据是磁盘文件页面，则这是文件页面映射中该页面的编号。 文件中的空页（空洞）不会被发送。 请注意，一个洞与一页零不同。Word 2: Data Length.此页中的数据字数，跟在标题后面。 因此，传输单元的总长度是报头长度加上数据长度。Word 3: Page Type.这是什么类型的块的代码。 数据页是类型 3，FDB 页是类型 2。Word 4: Page Access Control.与文件页面映射中的页面相关联的访问位。 （这个完整的字数被程序从网络读取到磁盘放入一个 SPACS 的 AC2 中。）头部之后是数据长度数据字。 数据长度当前要么是数据页的 512，要么是 FDB 的 31。 磁盘文件页中的尾随零可能会被丢弃，在这种情况下使数据长度小于 512。附录2 - 目录命令由于 UNIX 具有树状目录结构，其中目录与普通文件一样易于操作，因此扩展这些机器上的 FTP 服务器以包含处理目录创建的命令非常有用。 由于ARPA-Internet 上还有其他主机具有树状目录（包括TOPS-20 和Multics），因此这些命令尽可能通用。FTP 添加了四个目录命令：MKD pathname创建一个名为“pathname”的目录。RMD pathname删除名为“pathname”的目录。PWD打印当前工作目录名称。CDUP切换到当前工作目录的父目录。“路径名”参数应该作为当前工作目录的子目录创建（删除），除非“路径名”字符串包含足够的信息来指定服务器，例如，“路径名”是一个绝对路径名（在 UNIX 和 Multics 中） )，或者路径名类似于 TOPS-20 的“<abso.lute.path>”。REPLY CODESCDUP 命令是 CWD 的一个特例，包含它是为了简化用于在具有不同命名父目录语法的操作系统之间传输目录树的程序的实现。 CDUP 的回复代码与 CWD 的回复代码相同。RMD 的回复代码与其类似文件 DELE 的回复代码相同。但是，MKD 的回复代码稍微复杂一些。 新创建的目录可能是未来 CWD 命令的对象。 不幸的是，MKD 的论据可能并不总是适合 CWD 的论据。 例如，当仅通过提供子目录名称创建 TOPS-20 子目录时，就是这种情况。 也就是说，用一个TOPS-20服务器FTP，命令序列MKD MYDIR CWD MYDIR将失败。 新目录只能以其“绝对”名称引用； 例如，如果上面的 MKD 命令是在连接到目录 <DFRANKLIN> 时发出的，则新的子目录只能由名称 <DFRANKLIN.MYDIR> 引用。然而，即使在 UNIX 和 Multics 上，给 MKD 的参数也可能不合适。 如果它是“相对”路径名（即相对于当前目录解释的路径名），则用户需要位于同一当前目录中才能到达子目录。 根据应用程序，这可能不方便。 在任何情况下它都不是很健壮。为了解决这些问题，在成功完成 MKD 命令后，服务器应返回以下形式的一行：257<space>"<directory-name>"<space><commentary>也就是说，服务器会告诉用户在引用创建的目录时使用什么字符串。 目录名可以包含任何字符； 嵌入的双引号应该被双引号转义（“双引号”约定）。例如，用户连接到目录 /usr/dm，并创建一个名为 pathname 的子目录：CWD /usr/dm 200 directory changed to /usr/dm MKD pathname 257 "/usr/dm/pathname" directory created带有嵌入式双引号的示例：MKD foo"bar 257 "/usr/dm/foo""bar" directory created CWD /usr/dm/foo"bar 200 directory changed to /usr/dm/foo"bar同名子目录的先前存在是一个错误，在这种情况下，服务器必须返回“访问被拒绝”错误回复。CWD /usr/dm 200 directory changed to /usr/dm MKD pathname 521-"/usr/dm/pathname" directory already exists; 521 taking no action.MKD 的失败回复类似于它的文件创建表亲 STOR。 此外，如果与子目录同名的文件名将与子目录的创建冲突（这在 UNIX 上是一个问题，但在 TOPS-20 上不应该是一个问题），则会给出“拒绝访问”返回。本质上，因为 PWD 命令返回与成功的 MKD 命令相同类型的信息，成功的 PWD 命令也使用 257 回复代码。SUBTLETIES因为这些命令在将子树从一台机器传输到另一台机器时最有用，所以仔细观察 MKD 的参数将被解释为当前工作目录的子目录，除非它包含足够的信息让目标主机以其他方式告知 . 在 TOPS-20 世界中使用它的一个假设示例：CWD <some.where> 200 Working directory changed MKD overrainbow 257 "<some.where.overrainbow>" directory created CWD overrainbow 431 No such directory CWD <some.where.overrainbow> 200 Working directory changed CWD <some.where> 200 Working directory changed to <some.where> MKD <unambiguous> 257 "<unambiguous>" directory created CWD <unambiguous>请注意，第一个示例生成连接目录的子目录。 相比之下，第二个示例中的参数包含足够的信息，TOPS-20 可以判断 <unambiguous> 目录是顶级目录。 另请注意，在第一个示例中，用户通过尝试访问新创建的目录而不是 TOPS-20 返回的名称来“违反”协议。 如果存在 <overrainbow> 目录，则在这种情况下可能会导致问题； 这是某些 TOPS-20 实现中固有的歧义。 类似的考虑适用于 RMD 命令。 关键是：除非这样做会违反主机用于表示相对路径名和绝对路径名的约定，否则主机应该将 MKD 和 RMD 命令的操作数视为子目录。 MKD 命令的 257 回复必须始终包含创建的目录的绝对路径名。附录3 – 关于FTP的 RFCBhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823), MIT-Project MAC, 16 April 1971. Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971. Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 (NIC 6794), MIT-Project MAC, 23 June 1971. Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663), UCLA/CCN, 29 September 1971. Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265 (NIC 7813), MIT-Project MAC, 17 November 1971. McKenzie, Alex, "A Suggested Addition to File Transfer Protocol", RFC 281 (NIC 8163), BBN, 8 December 1971. Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC, 25 January 1972. Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596), MIT-Project MAC, 8 July 1972. Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)", RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972. Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah, 27 November 1972. Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972. Braden, Bob, "Comments on File Transfer Protocol", RFC 430 (NIC 13299), UCLA/CCN, 7 February 1973. Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction", RFC 438 (NIC 13770), BBN, 15 January 1973. Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN, 27 February 1973. McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, 16 February 1973. Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458 (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973. Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, 12 July 1973. Krilanovich, Mark, and George Gregg, "Comments on the File Transfer Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974. Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974. Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB, Ames Research Center, SRI-ARC, 28 February 1974. Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463 (NIC 14573), MIT-DMCG, 21 February 1973. Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN, 8 March 1973. Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919), MIT-DMCG, 6 March 1973. Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II", RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973. White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), SRI-ARC, 8 March 1973. White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), SRI-ARC, 8 March 1973. Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 (NIC 16157), MIT-Multics, 26 June 1973. Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", RFC 520 (NIC 16819), Illinois, 25 June 1973. Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 (NIC 17451), UCSD-CC, 22 June 1973. Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, 15 November 1973. McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, 29 November 1973. Sussman, Julie, "FTP Error Code Usage for More Reliable Mail Service", RFC 630 (NIC 30237), BBN, 10 April 1974. Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843), UCLA/NMC, 5 June 1974. Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), SU-AI, 10 May 1975. Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI, 28 May 1975. Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, 31 October 1977. Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), SRI-KL, 30 December 1977. Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, 10 December 1978. Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI, June 1980. Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 776, BBN, December 1980. Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE, July 1985.参考文档[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook", Network Information Center, SRI International, March 1982. [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol Specification", RFC 854, ISI, May 1983. [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943, ISI, April 1985.
-
发表了文章 2023-03-04
用于封装安全载荷 (ESP) 中的基于计数器的密码的隐式初始化向量 (IV)
RFC8750：Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)，March 2020梗概封装安全载荷 (Encapsulating Security Payload，ESP) 在每个数据包中发送一个初始化向量 (initialization vector，IV)。IV 的大小取决于应用的变换，对于编写本文档时定义的变换，通常为 8 或 16 个八位字节。与 IPsec 一起使用时，一些算法，例如 AES-GCM、AES-CCM 和 ChaCha20-Poly1305，采用 IV 生成一个随机数，用作加密和解密的输入参数。这个 IV 必须是唯一的，但可以预测。因此，可以使用 ESP 序列号 (Sequence Number，SN) 中提供的值来生成随机数。在 AES-GCM、AES-CCM 和 ChaCha20-Poly1305 的情况下，这避免了发送 IV 本身并为每个数据包节省 8 个八位字节。本文档介绍了如何执行此操作。本备忘录的状态这是一个 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8750。版权声明版权所有 (c) 2020 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该条款自本文档发布之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍基于计数器的 AES 操作模式，例如 AES-CCM [RFC4309] 和 AES-GCM [RFC4106]，需要为每个 ESP 数据包指定一个随机数。这同样适用于 ChaCha20-Poly1305 [RFC7634]。目前，由于每个 ESP 数据包 [RFC4303] 中提供的初始化向量 (IV)，生成此随机数。这种做法在本文件中被指定为“显式 IV”。在某些情况下，例如物联网 (Internet of Things，IoT)，最好避免携带与 IV 关联的额外字节，而是在每个对等体本地生成它。IV 的本地生成在本文档中被指定为“隐式 IV”。这个 IV 的大小取决于具体的算法，但上面提到的所有算法都采用 8 个八位字节的 IV。本文档定义了在隐式时如何在本地计算 IV。它还指定了对等方如何同意 Internet 密钥交换版本 2 (IKEv2) [RFC7296] 关于使用隐式 IV 与显式 IV。本文档将其范围限制为上述算法。其他具有类似属性的算法可能会在以后定义为使用类似的机制。本文档不考虑 AES-CBC [RFC3602]，因为 AES-CBC 要求 IV 不可预测。如下所述直接从数据包计数器中获取它是不安全的，如 [RFC3602] 的第 6 节所述，并导致了现实世界中选择的明文攻击，例如 BEAST [BEAST]。本文档不考虑 AES-CTR [RFC3686]，因为它侧重于 [RFC8221] 中提供的推荐的带有关联数据的身份验证加密 (Authenticated Encryption with Associated Data，AEAD) 套件。2、 需求符号关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL” 当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。3、 术语IoT：Internet of Things，物联网IV：Initialization Vector，初始化向量IIV：Implicit Initialization Vector，隐式初始化向量Nonce：固定大小的八位字节字符串，只使用一次。在本文档中，IV 用于生成加密/解密的随机数输入。4、 隐式 IV对于第 1 节中列出的算法，对于给定的密钥，8 字节的 IV 不得重复。ESP 数据包与其 IV 之间的绑定是使用序列号或扩展序列号提供的。图 1 和图 2 分别表示具有常规 4 字节序列号和 8 字节扩展序列号的 IV。图 1：具有 4 字节序列号的隐式 IVSequence Number：序列号，ESP 数据包中携带的 4 字节序列号。Zero：零，所有位都设置为零的 4 字节数组。图 2：具有 8 字节扩展序列号的隐式 IVExtended Sequence Number：扩展序列号，安全联盟的 8 字节扩展序列号。ESP 数据包中携带四个低位字节。本文档仅定义了 AES-GCM 的[RFC4106]、AES-CCM 的[RFC4309]和ChaCha20-Poly1305 的[RFC7634]中定义的算法的IV 生成。这些算法的所有其他方面和参数都保持不变，并按照各自规范中的定义使用。5、 IKEv2 发起者行为支持此功能的发起者应该在 IKEv2 交换中的安全联盟 (Security Association，SA) 载荷内的提议子结构的转换类型 1（加密算法）子结构中提议隐式 IV（IIV）算法。为了促进与非支持对等体的向后兼容性，发起者还应该包括那些具有显式 IV 的相同算法作为单独的转换。6、 IKEv2 响应者行为SA 载荷处理的规则要求响应者从发起者发送的提议中选择其算法，从而确保响应者永远不会将包含 IIV 变换的 SA 载荷发送给未提出它的发起者。7、 安全考虑这些算法的随机数生成尚未明确定义。只要满足某些安全要求，它就留给了实现。通常，对于 AES-GCM、AES-CCM 和 ChaCha20-Poly1305，不允许对一个特定密钥重复 IV。本文档提供了一种明确且规范的方式来生成 IV。本文档中描述的机制满足所有相关算法的 IV 安全要求。由于当使用计数器模式密码时，IV 不得为一个 SA 重复，因此本文档中描述的隐式 IV 不得用于设置中，序列号可能与一个 SA 重叠。对于不使用扩展序列号的 SA，在传输第 2^32 个数据包之前，以及在传输使用扩展序列号的 SA 的第 2^64 个数据包。这可以防止普通点对点情况下的序列号重叠。[RFC5374]、[RFC6407] 和 [G-IKEv2] 中描述的组播是一个突出的例子，其中许多发送者共享一个密钥，因此共享一个 SA。因此，如果采用了一些机制来防止序列号对于一个 SA 重叠，则隐式 IV 只能与组播一起使用；否则，隐式 IV 不得与组播一起使用。本文档定义了三个使用隐式 IV 的新加密转换。与迄今为止定义的大多数加密转换（可同时用于 ESP 和 IKEv2）不同，这些转换仅针对 ESP 定义，不能在 IKEv2 中使用。原因是 IKEv2 消息不包含可用于 IV 生成的每个消息的唯一值。IKEv2 头中的 Message-ID 字段类似于 ESP 头中的 SN 字段，但最近的 IKEv2 扩展 [RFC6311] [RFC7383] 确实允许它重复，因此没有一种简单的方法可以从 IKEv2 头中导出唯一的 IV领域。8、 IANA 考虑IANA 已更新“互联网密钥交换版本 2 (Internet Key Exchange Version 2，IKEv2) 参数”注册表 [RFC7296]，将以下新代码点添加到“转换类型值”注册表 [IANA] 下的“转换类型 1 - 加密算法转换 ID”子注册表中：表 1：对“转换类型 1 - 加密算法转换 ID”注册表的添加9、 参考文献9.1、 规范参考[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003, <https://www.rfc-editor.org/info/rfc3602>. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, <https://www.rfc-editor.org/info/rfc3686>. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, <https://www.rfc-editor.org/info/rfc4106>. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>. [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005, <https://www.rfc-editor.org/info/rfc4309>. [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <https://www.rfc-editor.org/info/rfc5374>. [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, <https://www.rfc-editor.org/info/rfc6311>. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>. [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc-editor.org/info/rfc7383>. [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, DOI 10.17487/RFC7634, August 2015, <https://www.rfc-editor.org/info/rfc7634>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.9.2、 参考资料[BEAST] Duong, T. and J. Rizzo, "Here Come The xor Ninjas", May 2011, <https://www.researchgate.net/publication/266529975_Here_Come_The_Ninjas>. [G-IKEv2] Weis, B. and V. Smyslov, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf-ipsecme-g-ikev2-00, 8 January 2020, <https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-00>. [IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <https://www.iana.org/assignments/ikev2-parameters>.致谢我们要感谢 Valery Smyslov、Éric Vyncke、Alexey Melnikov、Adam Roach 和 Magnus Nyström（安全局）以及我们的三个安全 AD——Eric Rescorla、Benjamin Kaduk 和 Roman Danyliw——的宝贵意见。我们还要感谢 David Schinazi 的实施以及 Tero Kivinen 和 David Waltermire（IPSECME 主席）推动这项工作。
-
发表了文章 2023-03-04
MASQUE 中 IP 和 UDP 代理的传输注意事项
draft-westerlund-masque-transport-issues-02：Transport Considerations for IP and UDP Proxying in MASQUE，July 2021梗概HTTP Connect 方法使用往返代理的背靠背 TCP 连接。这种解决方案处理了许多传输方面以及与 IP 流相关的问题。另一方面，对于 UDP 和 IP 代理，需要考虑多个按数据包和按流的方面以保留端到端 IP/UDP 流的属性。本文档的目的是突出显示与 UDP 和 IP 代理相关的这些问题并提供解决方案。讨论场地在作为 RFC 发布之前，将删除此注释。本文档在 MASQUE 工作组邮件列表 (masque@ietf.org) 上进行讨论，该邮件列表存档于 https://mailarchive.ietf.org/arch/browse/masque/(https://mailarchive.ietf. org/arch/browse/masque/)。可以在 https://github.com/gloinul/draft-westerlund-masque-transport-issues。https://github.com/gloinul/draft-westerlund-masque-transport-issues本备忘录的状态本互联网草案完全符合 BCP 78 和 BCP 79 的规定。Internet-Drafts 是 Internet Engineering Task Force (IETF) 的工作文件。请注意，其他组也可以将工作文档作为 Internet 草案分发。当前互联网草案的列表位于 https://datatracker.ietf.org/drafts/current/。Internet-Drafts 是有效期最长为六个月的草稿文件，可以随时更新、替换或被其他文件淘汰。将互联网草案用作参考材料或引用它们而不是“正在进行的工作”是不合适的。该互联网草案将于 2022 年 1 月 13 日到期。版权声明版权所有 (c) 2021 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍本文档检查了与 UDP [RFC0768] over IP [RFC0791] [RFC8200] (IP/UDP) 流相关的几个方面，当它们根据 QUIC 上的 MASQUE 提案进行代理并使用 HTTP CONNECT 方法进行流建立 (Connect-UDP) [ ID.ietf-masque-connect-udp]。它还研究了 UDP 之上的传输协议如何使用此信息，并将其与使用 TCP [RFC0793] 或 QUIC [RFC9000] 的 HTTP Connect 方法 [RFC7231] 以及 TURN 协议 [RFC8656] 使用的方法进行对比.讨论的方面包括 ECN [RFC3168]、差分服务字段及其代码点 (Differentiated Services Field and its codepoint，DSCP) [RFC2474]、分片和 MTU、ICMP [RFC0792]、IPv6 FLOW ID [RFC8200]、IPv6 扩展报文头和 IPv4 选项 [RFC0791]。本文档还讨论了与 UDP 选项 [I-D.ietf-tsvwg-udp-options] 相关的 UDP 校验和的使用和 UDP 长度字段的使用。1.1、 定义* UDP Flow：UDP 流，共享一个 5 元组的 UDP 数据包序列。* ECN：Explicit Congestion Notification，显式拥塞通知 [RFC3168]。* DSCP：Differentiated Service Code Point，差异化服务代码点 [RFC2474]。* Proxy：代理，本文档根据上下文使用代理作为 MASQUE 服务器或 HTTP 代理的同义词。* Client：客户端，发起 MASQUE 隧道和与代理进行 UDP/IP 中继的端点。* Target：目标，客户端希望与之建立双向通信的远程端点。* UDP proxying：UDP 代理，代理通过 UDP“连接”将数据转发到目标。数据在代理处解封装，并在转发到目标之前由 UDP 和 IP 报文头修改。需要在客户端和代理之间保留或发送数据报边界。* IP proxying：IP代理，代理通过IP“连接”将数据转发到目标。数据在代理处解封装并在转发到目标之前由 IP 报文头修改。需要在客户端和代理之间保留或发送数据包边界。地址 = IP 地址 + UDP 端口图 1：节点及其地址图 1 提供了所涉及节点的概览图，即客户端、代理和目标，它们将在下面讨论。我们将名称目标用于客户端打算通过代理与之通信的节点或端点。还有两个网络路径。路径#1 是客户端到代理路径，其中 MASQUE 协议将通过 HTTP/3 会话（通常通过 QUIC）用于隧道 IP/UDP 流。路径#2 是代理和目标之间的路径。客户端将使用代理的服务地址来建立传输连接，在该连接上使用 MASQUE 协议与代理进行通信。MASQUE 协议将用于建立来自客户端的 IP/UDP 流的中继，使用代理的外部地址作为源地址并发送到目标地址。另外，建立后，在proxy上也进行了反向配置；从目标地址发送到代理的外部地址的 IP/UDP 数据包将被中继到客户端。1.2、 HTTP ConnectHTTP 连接方法 [RFC7231] 被定义为接收请求的 HTTP 代理将建立一个 TCP 连接到一个提供的（或解析的）目标地址。TCP 连接建立后，代理会将来自客户端的字节流连接到新 TCP 连接的字节流。在字节流级别，这只是隧道。另一方面，在传输层，建立了两个不同的传输连接。如果客户端到代理的连接是 HTTP/3，即通过 QUIC，基本的 HTTP Connect 方法仍然会导致从代理到目标服务器的 TCP 连接建立。在这种情况下，客户端代理 QUIC 流的字节流连接到代理到服务器的 TCP 连接。为简单起见，文档的其余部分将使用背对背 TCP 会话作为比较。由于字节流语义和传输协议代理的使用，头字段及其值的大部分传输含义是在每个路径的基础上处理的，例如对 ECN 拥塞体验 (Congestion Experienced，CE) 标记的响应。如果代理支持，可以在连接之间复制或转换某些可能端到端相关的信息，例如 DSCP 值。由于在连接中流动的数据的字节流性质，MTU 几乎不相关并且完全处理。如果两条路径之间的 MTU 不同，则发送特定数据对象所需的数据包数量也可能不同。但是，其影响很小，取决于两个连接之间的缓冲量。两个 TCP 连接之间不要求数据包一一对应。1.3、 TURN“围绕 NAT 使用中继进行遍历 (Traversal Using Relays around NAT，TURN)：NAT 会话遍历实用程序的中继扩展 (Session Traversal Utilities for NAT，STUN)” [RFC8656] 是一种用于中继 UDP 数据报的解决方案。但是，它是纯封装隧道和代理之间的混合体。下面对该协议进行了稍微简化的描述。客户端通过 TCP/TLS 连接向 TURN 服务器发出 TURN 请求，以对自身进行身份验证并获取长期机密。请注意，后续请求使用来自长期秘密交换的密钥材料进行保护。接下来，客户端可以通过 UDP 发送请求以在服务器的外部 IP 地址之一上分配 UDP 端口号。之后，客户端知道将用于发送到远程目标或从远程目标接收的任何 UDP 流的 TURN 服务器端的 IP 地址和 UDP 端口号。TURN 客户端可以通过两种方式发送 UDP 数据包。第一种解决方案是为每个要中继的 UDP 数据包包括一个发送指示。发送指示包含目标目的地地址和端口。另一种解决方案是创建一个绑定，其中客户端和 TURN 服务器之间的通道 ID 绑定到从 TURN 服务器到目标目的地的特定 5 元组。建立的通道是双向的。建立通道后，UDP 数据包可以以 4 字节的低开销进行中继。要在分配的端口上接收 UDP 数据包，客户端必须指定要允许的源地址和端口（目标地址），这称为建立权限。绑定一个通道同时创建一个权限。当 TURN 服务器从存在许可但没有通道的外部源接收到 UDP 数据包时，它将使用 DATA 指示中继数据，其中包括源地址。本文档中其余讨论的一个相关方面是 TURN 在客户端和 TURN 服务器之间的 IP/UDP/TURN 消息与在外部接收或发送的 IP/UDP 数据包之间具有一对一的映射关系。此外，虽然 TURN 消息和指示在 UDP 有效载荷中包含报文头信息，但在 TURN 服务器的每一侧都有不同的 IP/UDP 报文头。因此，TURN 协议能够保留存在于 IP/UDP 报文头中的每个流和每个数据包的功能。例如，与特定数据包关联的 ECN 和 DSCP 标记由中继通过将它们从传入数据包复制或转换为传出数据包来保留。1.4、 HTTP Connect-UDPMASQUE WG 被授权在客户端和 MASQUE 服务器之间的 QUIC 连接中处理 UDP 数据报的隧道（我们将在本文档的其余部分中将 MASQUE 服务器称为代理以与基本的 HTTP 连接术语保持一致）。代理将隧道传输的 UDP 负载转发到正确的目标地址。HTTP Connect-UDP 请求用于建立隧道并提供所需的寻址信息。在本文档中执行的审查中，我们假设需要最小化每个数据包的开销。具体来说，我们假设来自代理和目标之间交换的数据包的 IP/UDP 报文头信息不会在隧道内发送。需要为客户端想要与之通信的每个目标执行初始中继交换建立，即代理到目标路径上的每个 IP/UDP 流一个中继交换。在每个 UDP 流的基础上在代理中保持此状态似乎微不足道。因此，审查将确定每个流需要什么 IP/UDP 状态以及每个数据包信息需要什么。在这篇评论中，我们还旨在通过在流和/或数据报模式下使用 QUIC 作为隧道协议来确定对端到端流的影响。将考虑 IP/UDP 流的属性和更高级别的传输协议，例如 QUIC 或 RTP。将 Connect-UDP 与 TURN 进行比较时，需要进行两个高级观察。首先是 QUIC 是具有拥塞控制的适当传输协议。这意味着在相对于代理的任一路径上，影响传输的事件（例如拥塞指示）之间可能不存在一对一映射。第二个观察结果是，隧道化 UDP 数据报可以与多个 QUIC 数据包或多个 QUIC 数据报帧合并在单个 UDP 数据报中，单个 QUIC 数据包中。如果使用可靠流而不是数据报帧，则 UDP 有效负载甚至可能会被分割成多个包含 QUIC 数据包的 UDP 数据包。这一切都激发了对 IP 和 UDP 报文头信息以及如何在流级别或每个数据包级别进行处理以避免破坏流的端到端传输属性的非常仔细的考虑。2、 IP Header 的审查2.1、 基本头部字段本节回顾 IPv4 [RFC0791] 和 IPv6 [RFC8200] 中的报文头字段。它将记录哪些字段是特定于版本的。审查中不考虑大小差异，因为它侧重于功能和影响。2.1.1、 版本代理需要知道在代理上使用哪个 IP 版本来定位路径。如果在 Connect-UDP 请求中包含显式 IP 地址，代理将直接从 IP 地址格式中知道这一点。在使用域名获取目标IP地址的情况下，解析域名时需要指定IP版本或根据喜好选择IP版本。需要注意的是，需要代理进行翻译的两条路径上可能使用不同的IP版本。这也可能导致一个路径上携带的版本特定信息不会转换为另一路径上使用的版本的情况。2.1.2、 DSCPDiffserv 代码点主要用于指示转发行为。代理到目标路径上的 IP/UDP 流上的代码点设置在流级别或数据包级别。在流级别设置的代码点在流实例化时设置，并且可以在正在进行的中继期间更新。在目标到代理方向的 IP/UDP 数据包上接收到的 DSCP 值可以传播到代理到客户端路径。然而，当数据报在 QUIC 中隧道传输时，这是有问题的。面向连接的传输的 DART 考虑 [RFC7657] 在这里适用。如果多个 DSCP 用于单个连接，则需要为不同的转发行为设置单独的拥塞控制状态，这可能需要 QUIC 协议扩展。客户端发送到代理路径上的客户端的数据包存在相同的问题。通过为每个使用的转发行为建立单独的 QUIC 连接，可以在没有 QUIC 扩展的情况下启用连接客户端和代理的路径的两个方向上的不同转发行为。但是，这要求代理能够将从客户端接收的多个 QUIC 连接绑定到代理上的单个 IP/UDP 流到目标路径。这可能会对安全模型产生重大影响，因为需要授权才能将后续绑定添加到现有流。让我们考虑代理向目标发送带有数据包级 DSCP 标记的数据包的能力。这将至少需要每个数据包指示机制，并且可以在代理上启用不同的转发行为到目标路径。类似地，代理需要一个按数据包机制，以便能够将从目标接收到的 DSCP 值中继到客户端。后者的用处是确保 MASQUE 之上的传输协议能够确定是否需要针对接收到的 IP/UDP 流中不同分组子集的多个拥塞控制状态。WebRTC IP/UDP 流可以具有此属性。最基本的 DSCP 中继功能是在代理发送到特定 IP/UDP 流的同一目标的所有 IP/UDP 数据包上设置相同的 DSCP 值。这种能力只需要在流建立时发送所需值的信号。还应考虑为正在进行的流更新 DSCP 值的机制。DSCP 映射到转发行为的另一个问题是映射是按网络位置定义的，通常在一个路由管理域内。因此，它们可能会被重新映射到相对于代理的不同路径上。当客户端和代理位于两个不同的管理域中时，客户端将面临使用正确 DSCP 值的额外挑战。因此，MASQUE 协议中对 DSCP 的支持应该被限制为考虑每跳行为或映射表的使用，以便代理可以将传入的 DSCP 值转换为本地使用的值。2.1.3、 ECN显式拥塞通知 (Explicit Congestion Notification，ECN) [RFC3168] 字段携带每个数据包路径关于拥塞的信号。ECN 能力的讨论可以分为两部分，一个是针对与代理相关的每条路径。在客户端到代理路径上，用于隧道传输 UDP 数据包的 QUIC 连接可以在该路径上启用和使用 ECN。该路径上的任何拥塞经历 (ECN-CE) 标记都会影响客户端代理 QUIC 连接的拥塞窗口，从而间接影响端到端流量。在代理上使用 ECN 到目标路径的能力需要代理协议支持。这将使 ECN 在上层传输协议中的端到端使用成为可能。为了在使用 MASQUE 代理时支持 ECN 端到端，需要存在两个功能。首先，在从代理发送到目标的任何 IP/UDP 数据包上设置 ECN 字段值（Not-ECT、ECT(1)、ECT(0)）的能力。该值最初可以设置，但可以在正在进行的 IP/UDP 流代理期间更改，因为端到端传输可能随后确定该路径不支持 ECN。其次，对于代理从目标接收的每个数据包，客户端必须能够接收每个数据包的 ECN 字段值的指示。这确保上层传输协议接收每个中继 UDP 数据包的 ECN 信息。该信息将用于对 ECN-CE（拥塞经历）标记作出反应并用于验证 ECN 路径能力。由于多种原因，像 TURN 的 [RFC8656] 转换两条路径之间的 ECN 标记这样的解决方案是不可能的。首先，客户端到代理路径上的 ECN 标记将被用于隧道的 QUIC 连接消耗和响应。其次，前面讨论的 IP/UDP 数据包缺乏一对一关系会妨碍对 ECN 标记的准确跟踪，并使端到端验证失败。因此，代理和客户端之间需要额外的显式信令。2.1.4、 标识、标志和分片偏移量（仅限 IPv4）这些字段用于 IPv4 分片解决方案。作者认为应该避免 IP 级别的分片化。然而，由于不保证相对于代理的两条路径之间的一对一数据包关系，任何 IPv4 分片在端点和代理接收时都需要重新组装。为了支持路径 MTU 发现，需要为从代理到目标的所有传出 IP/UDP 数据包设置不分片 (Don't Fragment，DF) 位。需要支持此位的每流或每包设置。2.1.5、 流标签（仅限 IPv6）网络使用 IPv6 流标签来识别流，例如，在执行基于等价多路径 (Equal Cost Multipath，ECMP) 路由 [RFC6438] 的负载平衡时，防止单个流分布在多条路径上。流标签应由发起 IP/UDP 流的端点设置，因为它知道流何时有资格获得唯一的 IPv6 流标签。因此，预计承载客户端代理QUIC连接的IP/UDP流将使用一个IPv6流标签，而MASQUE协议建立到不同目标地址的每个IP/UDP流使用一个IPv6流标签。基于上述推理，似乎不需要 MASQUE 协议明确地发出信号或指示流标签。2.1.6、 总长度/有效载荷长度总长度 (IPv4) / 有效载荷长度 (IPv6) 字段包含 IP 数据包的大小，直接用于 IPv4，或间接用于 IPv6（通过提供固定 40 字节报文头后的长度，即用于扩展报文头和数据） .这些字段对于接收处理是必需的，但是它不需要基于每个数据包与客户端通信，也不需要由客户端提供，在 UDP 长度的上下文中讨论了一个潜在的例外字段（第 3.2 节）。2.1.7、 协议/下一个报文头协议 (IPv4) 和下一个报文头 (IPv6) 字段提供上层协议的标识，在这种情况下是 UDP。对于 IPv6，一个或多个扩展报文头在到达 UDP 之前可能首先在链中被识别。UDP 中继的使用需要明确通知以将其与其他类型的中继分开，例如 MASQUE 章程中讨论的 IP 隧道/中继。2.1.8、 生存时间/跳数限制生存时间 (IPv4) 和跳数限制 (IPv6) 字段的目的是防止数据包在路由循环的情况下具有无限的生命周期。从这里开始使用首字母缩略词 TTL 来描述这些字段中的任何一个。TTL 限制数据包存活的路由跳数，并且在它到期时应该会导致 ICMP 消息返回给发送者。因此，可以使用 TTL 来调查网络路径。目前尚不清楚在 MASQUE 协议上下文中是否需要支持这种机制。如果要支持跟踪路由之类的东西，则需要对每个数据包设置 TTL 字段。在从目标到客户端接收 IP/UDP 数据包时回显 TTL 字段值的需要似乎也非常有限。传输数据包时设置的值通常是操作系统设置的默认值。作者认为代理的默认值足以满足 MASQUE 协议的功能。2.1.9、 报文头校验和（仅限 IPv4）IPv4 校验和字段验证完整性，防止传输或处理 IP 报文头中的非故意错误。IPv6 缺少此校验和，而是依赖于传输协议校验和。该值是在从代理传输 IP 数据包并在接收时进行验证时生成的。不需要进一步的功能。2.1.10、 源地址和目的地址在从代理到目标的路径上，源地址将是中继 IP/UDP 数据包时应用的代理的外部地址。该地址将被确定为 IP/UDP 流隧道建立的一部分，并应由代理发回给客户端。使用的目标地址将是目标的 IP 地址。客户端用于代理路径的源地址仅用于客户端和代理之间的通信，并且是 QUIC 连接状态的一部分。因此，更改它的可能性将取决于 QUIC 中处理客户端地址迁移或多路径的机制。不需要进一步讨论。在 IP 代理的情况下，由于代理不能使用端口号，代理可能需要维护多个外部 IP 地址，以便识别从多个目标服务器接收的数据包的不同转发过程。如果代理保证在客户端和服务器之间的路径上，代理还可以将客户端的源 IP 地址保存为外部地址。因此，源地址和目标地址是 IP/UDP 流中继的基本状态的一部分，需要在启动时建立。从代理到目标和反向的 2元组（IP 代理）或 5 元组（IP/UDP 代理）需要明确地发出信号。客户端需要明确提供目标 IP 地址或代理可以解析为目标 IP 地址的域名。当在代理上发送到目标路径时，代理需要通知客户端它使用哪个源 IP 地址。2.2、 IPv4 选项头IPv4 选项报文头在一般 Internet 上的使用非常有限。因此很可能不需要任何功能。2.3、 IPv6 扩展头这里需要讨论的一个 IPv6 扩展报文头是分片报文头。尽管添加分片报文头的是 IP 发起节点，但 MASQUE 协议可能需要控制是否应使用 IPv6 分片，就像对 IPv4 DF 位一样。发起节点可以添加一些现有的 IPv6 扩展报文头。需要进一步调查它们是否需要向客户端发送任何明确的信号或中继数据。尤其是 Hop-by-Hop 选项，例如 IPv6 最小路径 MTU Hop-by-Hop 选项 [I-D.ietf-6man-mtu-option]。还有一些关于未来可能重要的扩展报文头的单独建议：网络令牌 [I-D.yiakoumis-network-tokens]、IPv6 Truncate 选项 [I-D.leddy-6man-truncate]。因此，需要考虑是否有必要在未来证明 Masque 协议，至少使未来的扩展能够支持每个数据包的扩展头。3、 UDP Header 的回顾3.1、 源和目的端口对于 UDP 代理，端点使用 UDP 目标端口来定位应该使用特定 UDP 数据报的目标进程。接收应用程序可以使用源端口来基于 5 元组分离流。如第 2.1.10 节所述，UDP 源端口和目标端口是 5 元组的一部分，需要在 IP/UDP 流建立时进行通信。3.2、 UDP长度UDP 长度字段以八位字节为单位指定 UDP 有效载荷长度。UDP 长度字段通常表示 UDP 有效载荷填满了 IP 数据包的其余部分。然而，这并非总是如此。具体来说，UDP 选项 [I-D.ietf-tsvwg-udp-options] 旨在利用 UDP 数据段末尾和 IP 数据包末尾之间的剩余区域。因此，为了让 MASQUE 协议保留在 UDP 中继这个剩余区域中携带 UDP 选项的能力，UDP 有效载荷数据长度字段需要从客户端双向传输到代理。3.3、 UDP 校验和UDP 校验和使用 IP 层信息验证 UDP 数据报报文头和有效载荷以及伪报文头。UDP 校验和应始终由接收方验证。UDP 校验和也可以设置为零以不提供验证。这主要用于隧道封装格式。如果希望将 IP/UDP 流从代理发送到具有零 UDP 校验和的目标地址，则 MASQUE 协议需要支持此愿望的指示。由于缺少 IP 报文头校验和 [RFC6936]，IPv6 零 UDP 校验和的使用比 IPv4 受到更多限制。作者认为没有必要能够发送带有零 UDP 校验和的 IP/UDP 数据报。也没有必要中继目标生成的 UDP 校验和，因为 QUIC 协议将为 UDP 数据报负载提供更强的加密完整性验证。此外，为了使目标生成的校验和对客户端有意义，需要重建完整的数据报和伪报文头，这可能需要额外的处理和数据复制。虽然通过这种方式可以检测到 MASQUE 协议对 IP/UDP 报文头字段的错误处理的某些情况，但认为这样做并不值得。对于客户端发送的要中继到目标目的地的数据包，让客户端创建 UDP 校验和将提供一些防止处理或实现错误的保护，尽管开销和额外的处理可能不值得付出努力。此外，传输报文头校验和的计算和验证是可以卸载到代理中的硬件的这些方面之一。4、 ICMPInternet 控制消息协议 (Internet Control Message Protocol，ICMP) [RFC0792][RFC4443] 消息是有关为什么发送的 IP 数据包在网络中消失的有用提示。特别是对于看似间歇性的问题，例如超过路径的 MTU。让我们首先阐明哪些 ICMP 消息可能与 MASQUE 协议中的处理相关。主要关心的是确保客户端接收任何 ICMP 响应，这些响应作为客户端通过代理向目标目的地中继的数据包的结果而发送回代理。代理应验证和识别与代理发送的特定 IP/UDP 流相关的 ICMP 消息。相关的 ICMP 信息，即类型和代码以及数据包中可用于识别客户端中实际 IP/UDP 数据包的任何包含的字节，应发送到客户端。这样的功能将使客户端能够接收加速路径 MTU 发现的 Packet Too Big 消息（第 5 节）。它还使客户端能够了解何时目标地址上似乎没有人，即端口、主机或网络不可达代码。从目标地址到达代理的 IP/UDP 数据包可能会导致 ICMP 消息被发送回目标。例如，如果数据包在客户端终止隧道会话后到达，则会发送端口不可达消息。由客户端和代理之间交换的 IP/UDP 数据包产生的与 QUIC 连接相关的任何 ICMP 数据包都将被 QUIC 实现验证和使用。因此，根据 ICMP 消息，MASQUE 协议需要考虑一种代理机制，以向客户端表明它已收到并验证了 ICMP 消息。如果 ICMP 消息指示连接失败，则可以使用 HTTP 响应错误代码。但是，对于 HTTP Connect-UDP，响应代码是在创建 UDP 套接字时发送的，而 ICMP 消息仅在中继 UDP 数据包后才会收到。5、 最大传输单元（MTU）UDP 有效负载可用的 MTU 取决于 QUIC 连接是使用数据报还是流在客户端到代理路径上携带 UDP 有效负载。当使用流时，外部 QUIC 连接可以对任何大小的 UDP 负载进行分片和重新组装。在这种情况下，代理到目标路径上将出现任何 MTU 问题。使用数据报时，除非 QUIC 数据报扩展提供分片解决方案，否则外层 QUIC 连接将提供一个 MTU，该 MTU 取决于可以传输的最大数据报负载。一个潜在的问题是，这可能会随着时间的推移而变化，这既是由于基础路径的变化，也是由于 QUIC 协议的可变元素。但是，应该可以根据最大 QUIC 数据包大小计算来自 QUIC 报文头的基本开销。根据需要为 MASQUE 封装提供额外净空的每个数据包信息的数量，可能需要。要启用 PMTUD 发现，需要某些方面或极大地简化过程。* 确保在从代理到目标的传出 IPv4/UDP 数据包上将 DF 位设置为 Don't Fragment。对于 IPv6，需要防止使用分片报文头。* 将代理信号返回给客户端，其当前接口 MTU 限制将从代理发送到目标的数据包。* 让隧道 QUIC 连接向 MASQUE 实现公开数据报的当前 MTU。这可能是动态的，可以随时更新。* 当由于代理到目标路径上的 MTU 而丢弃数据包时，从代理向客户端返回 ICMP 数据包太大 (Packet Too Big，PTB) 消息。应该注意的是，除非 QUIC 数据报扩展提供分片机制，否则在许多情况下这将是最有可能的 MTU 瓶颈并且没有解决方法，IP/UDP 隧道流量将需要适合或被丢弃。5.1、 IPv6 分片接收流量的重组将发生在每个节点、客户端、代理和目标上。通过向上传播工作 MTU，应该避免 IP 级分片的需要。流的初始 MTU 信令应该存在。但是，这可能是动态的，并且为客户端到代理路径上的外部 QUIC 隧道运行的 PMTUD 进程将更新支持的 MTU。应该考虑通过代理控制是否应该发生分片的选项。5.2、 IPv4 分片由于 IPv4 分片很灵活，并且允许路径上的节点对数据包进行分片，因此启用分片可以减少 MTU 问题。但是，建议改为使用路径 MTU 发现，原因如下：* 分片会增加丢包率。* IP 分片不能很好地穿过 NAT 和防火墙。这与 MASQUE 尤其相关，因为重要的部署将是在从客户端到代理的路径上具有 NAT 或防火墙的接入或住宅网络中的客户端。6、 总结让我们在几个类别中总结 IP/UDP 报文头字段和相关协议的各个方面。6.1、 UDP 流信息和配置此部分包含报文头字段，其值对于给定的 IP/UDP 流将是静态的，应用直到更改，或者可以在未给出每个数据包值时用作默认值。首先，IP源地址和目的地址以及UDP源和端口信息直接关系到代理和目标之间双向IP/UDP流的建立。如果地址表示为主机名，则还需要指明所需的 IP 版本，否则将通过地址格式给出。目标始终需要由客户端提供。由于在某些情况下客户端需要知道代理对目标使用的外部地址，因此客户端需要有一种方法来请求此信息。客户端和目标之间的上层协议可能具有使用 ECN 的不同能力。因此，必须能够用信号通知目标数据包的代理中的 ECN 字段是否应设置为 Not-ECT、ECT(0) 或 ECT(1)。如果需要除 0 以外的 DSCP 标记，即尽力而为，则可以将默认值设置为中继建立的一部分。这个值可能会在每个数据包的基础上被覆盖，或者在中继流生命周期的未来点被改变。不分片设置可能会默认为始终为真。但是，如果在某些情况下为某些数据包或所有数据包启用 IP 级分片会更好，我们邀请进一步讨论。跳数限制可能会使用节点默认值，除非有人提出一个用例，他们实际上想要在每个数据包的基础上调制值或为 IP/UDP 流设置显式值。代理对指定目标已知的 MTU 应在代理建立中继时发回。6.2、 每个数据包的潜力信息此部分包含在客户端请求发送或代理中继接收到的数据包时与特定数据包相关联所需的信息。对于每个数据包，代理接收到 ECN 字段的值需要中继到客户端，以便上层可以响应指示拥塞的 CE 标记或任何重新标记。有一些示例，其中 IP/UDP 流包含没有统一 DSCP 标记的数据包。要启用此类流的发送，客户端需要向代理指示除默认值之外的任何 DSCP 值。如果需要验证客户端中的 UDP 校验和以避免任何潜在错误，MASQUE 协议实现可能会导致接收到的 UDP 校验和值需要中继到客户端。UDP 校验和值也可以由客户端计算并包含在内。要支持 UDP 选项，需要通知 UDP 选项及其值。如果支持包含需要客户端信息的 IPv6 扩展报文头，则扩展报文头信息将需要由客户端指示并通过隧道传输。6.3、 基于事件的交互本节总结了由事件触发且未直接连接到正在中继的 IP/UDP 流中的特定数据包的信息。相反，这些更多是由网络、上层传输协议或应用程序引起的异步事件的性质。代理发送到目标的数据包的 ECN 设置可能需要更改。如果上层传输协议确定端到端路径不支持 ECN，则需要将 ECT 标记更改为 Not-ECT。某些协议可能会推迟对 ECT 功能的探测，直到发生某些初始握手和数据包交换之后。上层应用程序可能会更改其对 IP/UDP 流中的数据包的期望转发行为，因此客户端需要更改由代理发送到目标的数据包的默认应用 DSCP 值。代理接收 ICMP 消息可能是发送到目标的数据包的结果，但原因可能在网络中。发生这种情况时，需要将此 ICMP 消息通知客户端，尤其是当此事件导致连接失败时。由于接收到的 ICMP 消息在代理的 IP 堆栈中消耗并影响传出数据包的 MTU，代理可能会检测到代理到目标路径上的 MTU 更改。因此，代理可能需要向客户端指示它不再可以发送大于新 MTU 的非分片数据包。7、 结论该文档表明，IP/UDP 报文头中的许多字段可以在流建立时最初发出信号。特别是 IP 地址和潜在的端口需要进行通信，因为它们也需要用于流识别。它还表明某些字段值或相关信息需要根据异步应用程序或网络事件进行中继或发送信号。每个数据包中继可能需要其他字段信息。后者需要代理和客户端之间更活跃的双向通信通道。这些方面都需要在 CONNECT-UDP 方法的未来协议开发中加以考虑，以确保 MASQUE 协议不会阻止未来的 IP 和传输协议的演进。8、 参考文献8.1、 规范参考[I-D.ietf-masque-connect-udp]Schinazi, D., "The CONNECT-UDP HTTP Method", Work in Progress, Internet-Draft, draft-ietf-masque-connect-udp-03, 5 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-masque-connect-udp-03.txt>. [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-13.txt>. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://datatracker.ietf.org/doc/html/rfc768>. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://datatracker.ietf.org/doc/html/rfc791>. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://datatracker.ietf.org/doc/html/rfc792>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://datatracker.ietf.org/doc/html/rfc2474>. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://datatracker.ietf.org/doc/html/rfc3168>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://datatracker.ietf.org/doc/html/rfc8200>. [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://datatracker.ietf.org/doc/html/rfc9000>.8.2、 参考资料[I-D.ietf-6man-mtu-option]Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-by-Hop Option", Work in Progress, Internet-Draft, draft-ietf-6man-mtu-option-05, 28 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-6man-mtu-option-05.txt>. [I-D.leddy-6man-truncate]Leddy, J., Bonica, R., and I. Lubashev, "IPv6 Packet Truncation", Work in Progress, Internet-Draft, draft-leddy-6man-truncate-05, 10 October 2018, <https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate-05.txt>. [I-D.yiakoumis-network-tokens]Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network Tokens", Work in Progress, Internet-Draft, draft-yiakoumis-network-tokens-02, 22 December 2020, <https://datatracker.ietf.org/doc/html/draft-yiakoumis-network-tokens-02.txt>. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://datatracker.ietf.org/doc/html/rfc793>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://datatracker.ietf.org/doc/html/rfc4443>. [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://datatracker.ietf.org/doc/html/rfc6438>. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://datatracker.ietf.org/doc/html/rfc6936>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://datatracker.ietf.org/doc/html/rfc7231>. [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://datatracker.ietf.org/doc/html/rfc7657>. [RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020, <https://datatracker.ietf.org/doc/html/rfc8656>.
-
发表了文章 2023-03-04
以太网VPN(EVPN)和提供商骨干桥接EVPN(PBB-EVPN)中的以太网树(E-Tree)支持
RFC8317：Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)，January 2018梗概MEF 论坛 (MEF) 定义了一种称为以太网树 (Ethernet-Tree，E-Tree) 的有根多点以太网服务。在 RFC 7387“多协议标签交换 (Multiprotocol Label Switching，MPLS) 网络上的以太网树 (E-Tree) 服务框架”中描述了在 MPLS 网络中支持该服务的解决方案框架。本文档讨论了如何使用基于RFC 7432“基于 BGP MPLS 的以太网 VPN (Ethernet VPN，EVPN)”的解决方案来满足这些功能要求，并进行了一些扩展，并描述了此类解决方案如何提供比这些功能更有效的实现。RFC 7796-“虚拟专用 LAN 服务 (Virtual Private LAN Service，VPLS) 中的以太网树（E-Tree）支持”。本文档使用了由RFC 7385创建的 IANA 注册表管理的隧道类型字段的最高有效位（在 P-组播服务接口 (P-Multicast Service Interface，PMSI) 隧道属性中）；因此，它相应地更新了 RFC 7385。本备忘录的状态这是一个 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 团体字的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8317。版权声明版权所有 (c) 2018 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍MEF 论坛 (MEF) 定义了一种称为以太网树 (E-Tree) [MEF6.1] 的有根多点以太网服务。在 E-Tree 服务中，通常由接入电路 (Attachment Circuit，AC)（例如，802.1Q VLAN 标签 [IEEE.802.1Q]）表示的客户站点被标记为根站点或叶子站点。客户站点也可以由媒体访问控制 (Media Access Control，MAC) 地址和 VLAN 标记表示。根站点可以与所有其他客户站点（根站点和叶子站点）进行通信。但是，Leaf 站点可以与 Root 站点通信，但不能与其他 Leaf 站点通信。在本文档中，除非另有明确说明，站点始终由 AC 表示。[RFC7387] 描述了在 MPLS 网络中支持 E-Tree 服务的解决方案框架。本文档确定了在 MPLS 网络中模拟 E-Tree 服务的整体解决方案的功能组件，并补充了 [RFC7432] 和 [RFC7623] 中规定的多点对多点以太网 LAN (Ethernet LAN，E-LAN) 服务。[RFC7432] 定义了 EVPN，这是一种用于多点二层虚拟专用网络 (Layer 2 Virtual Private Network，L2VPN) 服务的解决方案，具有高级多宿主功能，使用 BGP 在 MPLS/IP 网络上分发客户/客户端 MAC 地址可达性信息。[RFC7623] 将 EVPN 的功能与 [IEEE.802.1ah] 提供商骨干桥接 (Provider Backbone Bridging，PBB) 相结合，以实现 MAC 地址可扩展性。本文档讨论了如何使用基于 EVPN [RFC7432] 和 PBB-EVPN [RFC7623] 的解决方案来满足 E-Tree 服务的功能要求，并对其过程和 BGP 属性进行了一些扩展。这种基于 PBB-EVPN 或 EVPN 的解决方案可以提供比[RFC7796]“虚拟专用局域网服务（VPLS）中的以太网树（E-Tree）支持”更有效的实现这些功能。这种效率是通过在入口提供商边缘 (Provider Edge，PE) 节点执行单播流量过滤而不是出口过滤来实现的，在出口过滤中，流量通过网络发送并在出口 PE 节点被过滤和丢弃。此入口过滤的详细信息在第 4.1 节中描述。由于本文档指定了基于 [RFC7432] 的解决方案，因此了解该文档是先决条件。本文档使用了由 [RFC7385] 创建的 IANA 注册管理机构管理的隧道类型字段的最高有效位（在 PMSI 隧道属性中）；因此，它相应地更新了 [RFC7385]。第 3 节讨论 E-Tree 场景，第 4 节和第 5 节描述 EVPN 和 PBB-EVPN（分别）的 E-Tree 解决方案，第 6 节涵盖 E-Tree 解决方案的 BGP 编码。2、 术语2.1、 需求说明关键词“必须”、“不得”、“要求”、“应该”、“不应该”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” “当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。2.2、 术语和缩写Broadcast Domain：广播域，在桥接网络中，广播域对应一个虚拟局域网 (Virtual LAN，VLAN)，其中一个 VLAN 通常由单个 VLAN ID (VID) 表示，但可以由多个 VID 表示，其中使用共享 VLAN 学习 (Shared VLAN Learning，SVL)根据 [IEEE.802.1ah]。Bridge Table：桥接表，MAC-VRF 上广播域的实例化。CE：Customer Edge，客户边缘设备，例如主机、路由器或交换机。EVI：跨越参与该 EVPN 的提供商边缘 (PE) 设备的 EVPN 实例（EVPN Instance）。MAC-VRF：PE 上媒体访问控制 (Media Access Control，MAC) 地址的虚拟路由和转发表（Virtual Routing and Forwarding，VRF）。ES：当客户站点（设备或网络）通过一组以太网链路连接到一个或多个 PE 时，该组链路称为“以太网段（Ethernet Segment）”。ESI：Ethernet Segment Identifier，以太网段标识符是标识 ES 的唯一非零标识符。Ethernet Tag：以太网标签，以太网标签标识特定的广播域，例如 VLAN。一个 EVPN 实例由一个或多个广播域组成。P2MP：Point-to-Multipoint，点对多点。PE：Provider Edge device，提供商边缘设备。3、 E-Tree 场景本文档根据根/叶子站点关联的性质将 E-Tree 场景分为以下三类：场景 1：每个 PE 的叶子或根站点；场景 2：每个接入电路 (AC) 的叶子站点或根站点；或者，场景 3：每个 MAC 地址的叶子站点或根站点。3.1、 场景 1：每个 PE 的叶子或根站点在这种情况下，对于给定的 MAC-VRF/网桥表，PE 可能会从根 AC 或叶子 AC 接收流量，但不能同时接收两者。换言之，提供商边缘 (PE) 设备上的给定 EVPN 实例 (EVI) 与根或叶子关联。尽管针对不同的 EVI，PE 可能同时具有根和叶子 AC。图 1：场景 1在这种情况下，可以使用在属于同一 EVI 的 PE 之间定制的 BGP 路由目标 (Route Target，RT) 导入/导出策略来阻止 Leaf PE 之间的通信。为了防止连接到同一 PE 并属于同一 EVI 的 Leaf AC 之间的通信，水平分割过滤用于阻止流量从一个 Leaf AC 到另一个 Leaf AC 在 MAC-VRF 上的给定 E-Tree EVI。此拓扑约束的目的是避免只有叶子站点的 PE 相互导入和处理 BGP MAC 路由。为了支持 EVPN 中的这种拓扑约束，每个 EVI 使用两个 BGP RT：一个 RT 与根站点（Root AC）相关联，另一个与叶子站点（Leaf AC）相关联。在每个 EVI 的基础上，每个 PE 导出与其站点类型相关联的单个 RT。此外，具有根站点的 PE 导入根和叶子 RT，而具有叶子站点的 PE 仅导入根 RT。对于这个场景，如果希望每个 EVI 只使用一个 RT（就像 [RFC7432] 中的 E-LAN 服务），那么需要使用场景 2 中的方法 B（如下所述）。3.2、 场景 2：每个 AC 的叶子或根站点在这种情况下，PE 可以从根 AC 和叶子 AC 接收给定 EVI 的流量。换句话说，PE 上的给定 EVI 可以与根和叶子相关联。图 2：场景 2在这个场景中（如场景 1 第 3.1 节），可以使用两个 RT（一个用于根，另一个用于叶子）。但不同的是，在同时具有Root和Leaf AC的PE上，远端MAC路由全部引入；因此，为了应用适当的入口过滤，需要有一种方法来区分与叶子 AC 相关联的远程 MAC 路由与与根 AC 相关联的远程 MAC 路由。为了识别目标 MAC 地址与 Leaf 或 Root AC 的关联，从而支持在具有 Leaf 和 Root AC 的入口 PE 上的入口过滤，MAC 地址需要在通告之前使用 Root 或 Leaf-Indication 着色给其他PE。这种着色有两种方法：(A) 始终使用两个 RT（一个指定叶子 RT，另一个指定根 RT），或(B) 允许每个 EVI 使用单个 RT，就像 [RFC7432] 一样，因此，通过新扩展团体字中的“颜色”标志对 MAC 地址进行着色，如第 6.1 节所述。如果每个 VLAN 使用的 MAC-VRF 和网桥表要与 [RFC7432] 的第 6 节保持一致，则方法 A 将需要与方法 B 相同的数据平面增强。为了避免方法 A 的数据平面增强，可以考虑每个 VLAN 有多个网桥表；但是，这有很大的缺点（如附录 A 中所述）；因此，不推荐。考虑到方法 A 和 B 都需要相同的数据平面增强功能，这里选择方法 B 是为了允许 RT 使用与基线 EVPN [RFC7432] 一致并具有更好的通用性。需要注意的是，如果想要使用RT约束来避免与Leaf AC相关的MAC通告给只有Leaf AC的PE，那么两种RT（一个用于Root，另一个用于Leaf）仍然可以与方法B一起使用；然而，在此类应用中，叶子/根 RT 将用于约束 MAC 通告，而不用于为入口过滤的 MAC 路由着色（即，在方法 B 中，着色始终通过新的扩展团体字完成）。如果对于给定的 EVI，大量 PE 同时连接了叶子和根站点（即使它们可能以仅根或仅叶子的 PE 开始），则应使用每个 EVI 的单个 RT。提出这种建议的原因是为了减轻与每个 EVI 使用两个 RT 相关的配置开销，代价是在 Leaf-only PE 上有一些不需要的 MAC 地址。3.3、 场景 3：每个 MAC 地址的叶子或根站点在这种情况下，客户根或叶子站点由 AC 上的 MAC 地址表示，PE 可能会从该 AC 上的根站点和叶子站点接收流量，用于 EVI。[RFC7387] 或 [MEF6.1] 中均未涵盖此场景；但是，为了完整起见，它在本文档中进行了介绍。在这种情况下，由于 AC 承载来自根站点和叶子站点的流量，因此识别根站点或叶子站点的粒度是基于每个 MAC 地址的。本文档针对仅具有已知单播流量的 EVPN 服务考虑了这种情况，因为根据 [RFC7432] 的指定转发器 (Designated Forwarder，DF) 过滤与所需的出口过滤不兼容；也就是说，在这种情况下不支持广播、未知单播和组播 (Broadcast, Unknown Unicast, and Multicast，BUM) 流量；它被入口 PE 丢弃。对于此场景，使用场景 2 中的方法 B 以允许服务提供商使用单个 RT。图 3：场景 3综上所述，方案二中的方案B是上述三种方案的推荐方案，相应的解决方案将在以下部分详细介绍。4、 EVPN 操作[RFC7432] 定义了以太网段标识符 (ESI) MPLS 标签的概念，用于在出口 PE 处对 BUM 流量进行水平分割过滤。此类出口过滤功能可用于提供 E-Tree 服务，因为它很快就会用于 BUM 流量。对于已知的单播流量，需要对 [RFC7432] 进行额外扩展（即，第 6.1 节中描述的叶子指示的新 BGP 扩展团体字）以启用入口过滤，如以下部分所述。4.1、 已知单播流量在 EVPN 中，MAC 学习是通过 BGP 路由的通告在控制平面中进行的。因此，E-Tree 服务对已知单播流量所需的过滤可以在入口 PE 处执行，从而提供非常有效的过滤并避免通过 MPLS/IP 核心发送已知单播流量以在出口 PE 处过滤，就像在传统的 E-Tree 解决方案中所做的一样（即，用于 VPLS [RFC7796] 的 E-Tree）。为了为已知的单播流量提供这种入口过滤，PE 必须向其他 PE 指示其 MAC 地址与哪种站点（根或叶子）相关联。这是通过通告叶子指示标志（通过扩展团体字）以及从叶子站点获知的每个 MAC/IP 通告路由来完成的。缺少此类标志表明 MAC 地址与根站点相关联。该方案适用于第 3 节中描述的所有场景。使用 Leaf-Indication 标记 MAC 地址使远程 PE 能够对已知单播流量执行入口过滤；也就是说，在入口 PE 上，MAC 目标地址查找产生（除了转发邻接之外）一个标志，指示目标 MAC 是否与叶子站点相关联。入口 PE 与始发 AC 的状态交叉检查此标志，如果两者都是叶子，则不转发数据包。在允许 MAC 在 Leaf 和 Root 站点之间迁移的情况下（例如，非静态 MAC），PE 可以接收针对相同 MAC 地址的多个 MAC/IP 通告路由，这些路由具有不同的 Root 或 Leaf-Indications（对于多宿主可能还有不同的 ESI）场景）。在这种情况下，MAC 迁移性过程（参见 [RFC7432] 的第 15 节）在将该 MAC 与根或叶子站点相关联之前首先确定 MAC 的位置。为了支持上述入口过滤功能，引入了一个带有叶子指示标志的新 E-Tree 扩展团体字（参见第 6.1 节）。这个新的扩展团体字必须使用从叶子站点获知的 MAC/IP 通告路由进行通告。除了 MAC/IP 通告路由之外，不需要其他 EVPN 路由来承载这个新的扩展团体字，以达到已知单播流量的目的。4.2、 BUM 流量本规范不支持在入口 PE 上过滤广播、未知单播和组播 (BUM) 流量；由于 BUM 流量的多目的地特性，不可能在入口 PE 上执行相同的过滤。因此，该解决方案依赖于出口过滤。为了应用适当的出口过滤，根据数据包是从叶子 AC 还是根 AC 发送，MPLS 封装的帧必须标记有它们何时起源于叶子 AC 的指示（即，到用第 6.1 节中指定的叶子标签标记）。该叶子标签允许处置 PE（例如，出口 PE）在类似于 [RFC7432] 中的 ESI 标签的数据平面中执行必要的出口过滤功能。叶子标签的分配基于每个 PE（例如，独立于 ESI 和 EVI），如以下部分所述。叶子标签可以上游分配给点对多点 (P2MP) 标签交换路径 (Label Switched Path，LSP) 或下游分配给入口复制隧道。下游分配的 Leaf 标签和上游分配的 Leaf 标签的主要区别在于，在下游分配的 Leaf 标签的情况下，并非所有出口 PE 设备都需要接收 MPLS 封装的 BUM 数据包中的标签，就像 Ingress 的 ESI 标签一样[RFC7432] 中定义的复制过程。在入口 PE 上，PE 需要将给定网桥域的所有叶子 AC 放置在单个水平分割组中，以防止其叶子 AC 之间的 PE 内转发。这种 PE 内水平分割过滤适用于 BUM 流量以及已知的单播流量。有以下四种情况需要考虑。在所有这些场景中，入口 PE 会根据以太网帧是源自该以太网段上的根站点还是叶子站点（ESI 标签或叶子标签）来强加与起源的以太网段 (ES) 相关联的正确 MPLS 标签。PE 识别给定帧是源自段上的根站点还是叶子站点的机制基于该段的 AC 标识符（例如，802.1Q 帧的帧的以太网标签 [IEEE.802.1Q]） .用于识别根或叶子站点的其他机制，例如使用接收帧的源 MAC 地址，是可选的。下面的场景是在根/叶子 AC 的上下文中描述的，但是，如果需要，它们可以扩展到根/叶子 MAC 地址。4.2.1、 来自叶子 AC 上的单宿主站点的 BUM 流量在这种情况下，入口 PE 添加使用 E-Tree 扩展团体字（见第 6.1 节）通告的 Leaf 标签，表示一个 Leaf 站点。该叶子标签用于单归属场景，不是基于每个 ES 而是基于每个 PE（即，单个叶子 MPLS 标签用于该 PE 上的所有单归属 ES）。该叶子标签使用 E-Tree 扩展团体字（参见第 6.1 节）以及 ESI 为零的以太网自动发现（Ethernet Auto-Discovery per ES，EAD-ES）路由和一组对应于所有 EVI 的 RT 通告给其他 PE 设备在每个 EVI 至少有一个叶子站点的 PE 上。如果需要携带的 RT 数量超过 [RFC7432] 中单个路由的限制，则需要通告多条 EAD-ES 路由。EAD-ES 路由的 ESI 设置为零以指示单宿主站点。当PE在数据路径中收到这个特殊的Leaf标签时，如果目的AC是Leaf类型，它就会阻塞这个数据包；否则，它转发数据包。4.2.2、 BUM 流量源自根 AC 上的单宿主站点在这种情况下，入口 PE 不添加任何 ESI 或叶子标签，它按照 [RFC7432] 中的程序运行。4.2.3、 来自叶子 AC 上的多宿主站点的 BUM 流量在这种情况下，假设同一 ES 上的不同 AC (VLAN) 可能具有不同的根/叶子指定（有些是根，有些是叶子），但同一个 VLAN 在所有 PE 上确实具有相同的根/叶子指定在同一个 ES 上。此外，假设子网之间没有转发（即服务是 EVPN L2 而不是 EVPN 集成路由和桥接 (Integrated Routing and Bridging，IRB) [EVPN-INTEGRATED]）。[EVPN-INTEGRATED] 中描述的 IRB 用例超出了本文档的范围。在这种情况下，如果组播或广播报文来自Leaf AC，那么它只需要携带一个Leaf标签，如4.2.1节所述。此标签足以提供必要的 BUM 流量出口过滤，以免发送到叶子 AC，包括同一 ES 上的叶子 AC。4.2.4、 BUM 流量源自根 AC 上的多宿主站点在这种情况下，入口和出口 PE 设备都遵循 [RFC7432] 中定义的过程来添加和/或处理 ESI MPLS 标签；也就是说，[RFC7432] 中现有的 BUM 流量程序就足够了，不需要添加 Leaf 标签。4.3、 EVPN 的 E-Tree 流量流根据 [RFC7387]，通用 E-Tree 服务支持以下所有流量：- 从 Root 到 Roots & Leafs 的已知单播流量- 从叶子到根的已知单播流量- 从 Root 到 Roots & Leafs 的 BUM 流量- 从叶子到根的 BUM 流量特定的 E-Tree 服务可能需要支持所有上述类型的流或仅支持选定的子集，具体取决于目标应用程序。在只需要支持组播和广播流的情况下，L2VPN PE可以避免执行任何MAC学习功能。以下小节将描述 EVPN 的操作以支持有和没有 MAC 学习的 E-Tree 服务。4.3.1、 带有 MAC 学习的 E-Tree当根和叶子站点之间必须支持单播流量时，实现 E-Tree 服务的 PE 必须执行 MAC 学习。在这种情况下，具有根站点的 PE 在 ES 上的数据路径中执行 MAC 学习，并在 EVPN MAC/IP 通告路由中通告可达性。这些路由将由该 EVI 的所有 PE 导入（即，具有叶子站点的 PE 以及具有根站点的 PE）。类似地，具有叶子站点的 PE 在其 ES 上的数据路径中执行 MAC 学习，并在 EVPN MAC/IP 通告路由中通告可达性。对于每个 EVI 使用两个不同 RT（一个指定 Root 站点，另一个指定 Leaf 站点）的场景，MAC/IP Advertisement 路由仅由 EVI 中至少有一个 Root site 的 PE 导入（即，一个只有叶子站点的 PE 不会导入这些路由）。具有根和/或叶子站点的 PE 可以使用每个 EVI 的以太网自动发现 (EAD-EVI) 路由进行别名（在多宿主段的情况下）和 EAD-ES 路由用于根据 [RFC7432] 的大量 MAC 撤回。为了支持从根站点到叶子站点的组播/广播，可以使用以 PE 为根的 P2MP 树和根站点（例如，根 PE）或入口复制（参见 [RFC7432] 的第 16 节）。组播隧道是通过 EVPN 包含组播路由的交换建立的，如 [RFC7432] 中所定义。为了支持从叶子节点到根站点的组播/广播，可以使用来自每个叶子 PE 的入口复制隧道或以每个叶子 PE 为根的 P2MP 树。以下两段描述了何时可以使用这些隧道方案中的每一个以及如何用信号通知它们。当只有少数根 PE 具有少量组播/广播流量从叶子 PE 到根 PE 时，从叶子 PE 到根 PE 的入口复制隧道就足够了。因此，如果 Root PE 需要在从自身到 Leaf PE 的传输方向上支持 P2MP 隧道，同时又希望在接收方向上支持 Ingress Replication 隧道，则 Root PE 可以通过使用6.2 节中定义的一种新的复合隧道类型。这种新的复合隧道类型由根 PE 通告，以同时为 BUM 流量指示发送方向上的 P2MP 隧道和接收方向上的入口复制隧道。如果Root PE数量较多，可以使用Leaf PE发起的P2MP隧道（例如Multipoint LDP（mLDP）或RSVP-TE）；因此，将不需要使用修改后的 PMSI 隧道属性和第 6.2 节中定义的复合隧道类型值。4.3.2、 没有 MAC 学习的 E-Tree当Root站点和Leaf站点之间的流量主要是组播或广播时，实现E-Tree业务的PE不需要进行MAC学习。在这种情况下，PE 之间不交换 EVPN MAC/IP 通告路由。相反，Inclusive Multicast Ethernet Tag 路由用于支持 BUM 流量。在这种情况下，少量单播流量（如果有）作为 BUM 流量的一部分发送。该路由的字段按照 [RFC7432] 中定义的过程填充，组播隧道设置标准如上一节所述。和上一节一样，如果根 PE 的数量只有几个，因此需要从叶子 PE 到这些根 PE 的入口复制，那么 6.2 节中定义的修改后的 PMSI 属性和复合隧道类型值应该是用过的。5、 PBB-EVPN 操作在 PBB-EVPN 中，PE 与每个骨干 MAC (Backbone MAC，B-MAC) 通告路由一起通告 Root 或 Leaf-Indication，以指示关联的 B-MAC 地址是对应于 Root 站点还是 Leaf 站点。就像 EVPN 的情况一样，第 6.1 节中定义的新 E-Tree 扩展团体字与每个 EVPN MAC/IP 通告路由一起通告。在多宿主 ES 同时连接根站点和叶子站点的情况下，会通告两个 B-MAC 地址：一个 B-MAC 地址是每个 ES（如 [RFC7623] 中指定的）并隐式表示根，另一个 B-MAC地址是每个 PE 并明确表示叶子。前者的 B-MAC 地址不与 E-Tree 扩展团体字一起通告，但表示叶子的后一个 B-MAC 地址与设置了“Leaf-indication”标志的新 E-Tree 扩展团体字一起通告。在 ES 同时具有根和叶子 AC 的多宿主场景中，假设虽然同一 ES 上的不同 AC (VLAN) 可能具有不同的根/叶子指定（一些是根，一些是叶子），但同一个 VLAN 确实有在同一 ES 上的所有 PE 上具有相同的根/叶子指定。此外，假设子网之间没有转发（即服务是 L2 而不是 IRB）。IRB 用例超出了本文档的范围。入口 PE 使用正确的 B-MAC 源地址，具体取决于以太网帧是源自该 ES 上的根 AC 还是叶子 AC。PE 识别给定帧是源自段上的根站点还是叶子站点的机制基于与该帧相关联的以太网标签。以太网标签之外的其他识别机制不在本文档的范围内。此外，PE 通告两个特殊的全局 B-MAC 地址，一个用于 Root，另一个用于 Leaf，并在 MAC Advertisement 路由中标记 Leaf。这些 B-MAC 地址用作源自单宿主网段的流量的源地址。用于指示叶子站点的 B-MAC 地址对于单宿主和多宿主段可以相同。5.1、 已知单播流量对于已知的单播流量，PE 执行入口过滤：在入口 PE 上，客户/客户端 MAC (C-MAC) [RFC7623] 目标地址查找产生，除了目标 B-MAC 地址和转发邻接，一个标志指示目标B-MAC 是与Root 站点还是Leaf 站点相关联。Ingress PE 也检查始发站点的状态；如果两者都是叶子，则不转发数据包。5.2、 BUM 流量对于 BUM 流量，PE 必须进行出口过滤。当 PE 收到 EVPN MAC/IP 通告路由（将用作 BUM 流量的源 B-MAC）时，它更新其出口过滤（基于源 B-MAC 地址）如下：- 如果EVPN MAC/IP Advertisement 路由表明通告的B-MAC 是Leaf，并且本地ES 也是Leaf，则将源B-MAC 地址添加到其用于出口过滤的B-MAC 列表中（即阻止来自该 B-MAC 地址的流量）。否则，不更新 B-MAC 过滤列表。- 如果 EVPN MAC/IP Advertisement 路由指示通告的 B-MAC 已将其指定从 Leaf 更改为 Root，并且本地 ES 是 Leaf，则从 B-MAC 列表中删除源 B-MAC 地址对应于用于出口过滤的本地 ES（即，解除来自该 B-MAC 地址的流量的阻塞）。当出口 PE 收到数据包时，它会检查 B-MAC 源地址以检查它是否应该过滤或转发该帧。请注意，这使用与 [RFC7623] 的第 6.2.1.3 节中描述的水平分割过滤相同的过滤逻辑，并且不需要数据平面中的任何额外标志。正如在第 4.2 节中一样，PE 将给定网桥域的所有叶子 ES 放置在单个水平分割组中，以防止叶子段之间的 PE 内转发。这种水平分割功能适用于 BUM 流量以及已知的单播流量。5.3、 没有 MAC 学习的 E-Tree在感兴趣的流量只是组播和/或广播的场景中，实现E-Tree服务的PE不需要做任何MAC学习。在这种情况下，必须对出口 PE 进行过滤。对于 PBB-EVPN，此类流量的处理按照第 5.2 节进行，无需 PBB-EVPN PE（在入口和出口处）的 I 组件（C 桥表）中的 C-MAC 学习（在数据平面中） PE）。6、 BGP 编码本文档为 EVPN 定义了一个新的 BGP 扩展团体字。6.1、 E-Tree 扩展团体字这个扩展团体字是一个新的可传递扩展团体字[RFC4360]，其类型字段值为 0x06（EVPN），子类型为 0x05。它用于已知单播和 BUM 流量的叶子指示。它表明该帧来自叶子站点。E-Tree 扩展团体字被编码为 8 个八位字节的值，如下所示：图 4：E-Tree 扩展团体字标志字段具有以下格式：本文档定义了以下标志：+ 叶子指示 (Leaf-Indication，L)值为 1 表示叶子 AC/站点。其余的标志位是保留的，应设置为零。当这个扩展团体字与 MAC/IP 通告路由（对于已知的单播流量）一起按照第 4.1 节进行通告时，叶子指示标志必须设置为 1，并且叶子标签应该设置为 0。接收 PE 必须忽略 Leaf 标签，只处理 Leaf-Indication 标志。与 MAC/IP 通告路由一起发送时，叶子指示标志的零值无效，应记录错误。当这个扩展团体字与 BUM 流量的 EAD-ES 路由（ESI 为零）一起被通告时，根据第 4.2.1 和 4.2.3 节在处置 PE 上启用出口过滤，叶子标签必须设置为有效的 MPLS标签（即非保留的、分配的 MPLS 标签 [RFC3032]）和叶子指示标志应该设置为零。20 位 MPLS 标签的值编码在 Leaf 标签字段的高 20 位中。接收 PE 必须忽略 Leaf-Indication 标志。与 EAD-ES 路由一起发送的无效 MPLS 标签应被忽略并记录为错误。保留位应该由发送器设置为零，并且必须被接收器忽略。6.2、 PMSI 隧道属性[RFC6514]定义了PMSI隧道属性，它是一个可选的传递属性，格式如下：表 1：PMSI 隧道属性本文档通过在隧道类型字段中引入新的“复合隧道”位并将 MPLS 标签添加到 PMSI 隧道属性的隧道标识符字段来定义新的复合隧道类型，如下详述。所有其他字段保持在 [RFC6514] 中的定义。复合隧道类型由根 PE 通告，以同时指示 BUM 流量在发送方向上的非入口复制隧道（例如，P2MP 隧道）和接收方向上的入口复制隧道。当需要接收方入口复制标签时，隧道类型字段的高位（复合隧道位）被设置，而其余的低七位指示隧道类型（对于现有的隧道类型）。当这个复合隧道位被设置时，“隧道标识符”字段以三个八位字节的标签开始，后跟传输隧道的实际隧道标识符。不理解高位新含义的 PE 将隧道类型视为未定义的隧道类型，并将 PMSI 隧道属性视为格式错误的属性 [RFC6514]。这就是为什么在隧道类型字段而不是标志字段中分配复合隧道位的原因。对于了解高阶新含义的PE，如果在发送BUM 流量时需要Ingress Replication，则PE 在发送BUM 流量时将使用Tunnel Identifier 字段中的标签。将复合隧道位用于隧道类型 0x00“无隧道信息存在”和 0x06“入口复制”是无效的。收到带有此类信息的 PMSI 隧道属性的 PE 认为其格式错误，并且它应该将此更新视为根据 [RFC6514] 的第 6 节已撤消此更新中包含的所有路由。7、 安全考虑由于本文档使用 [RFC7432] 和 [RFC7623] 的 EVPN 结构，因此这些文档中的相同安全考虑也适用于此处。此外，本文档通过允许网络运营商/服务提供商将 EVPN 实例的站点（或 AC）指定为“根”或“叶子”，从而防止“叶子”站点之间的任何流量交换，提供了额外的安全检查该 VPN 通过对已知单播流量的入口过滤和对 BUM 流量的出口过滤。由于（默认情况下和为了向后兼容）没有叶子指定的 AC 被认为是根 AC，为了避免叶子 AC 之间的任何流量交换，运营商应该为 AC 配置适当的角色（叶子或根）之前激活 AC。8、 IANA 考虑IANA 在 [RFC7153] 中定义的“EVPN 扩展团体字子类型”注册表中分配了子类型值 5，如下所示：本文档创建了一个名为“E-Tree Flags”的八位字节注册表。新注册将通过 [RFC8126] 中定义的“RFC 要求”程序进行。初始注册如下：8.1、 PMSI 隧道类型的注意事项“边界网关协议 (Border Gateway Protocol，BGP) 参数”注册表中的“P-组播服务接口 (PMSI) 隧道类型”注册表已更新，以反映最高有效位作为“复合隧道”位的使用（参见第 6.2 节） .为此，本文档通过更改先前未分配的值（即 0x08 - 0xFA）来更新 [RFC7385]，如下所示：值 0x08-0x7A 的分配策略是根据 IETF 审查 [RFC8126]。“实验性”的范围已扩展为包括先前分配的范围 0xFB-0xFE 和新的范围 0x7B-0x7E。不分配这些范围内的值。本文档中保留值 0x7F，它是 (0xFF) 的镜像。9、 参考文献9.1、 规范参考[MEF6.1] MEF Forum, "Ethernet Services Definitions - Phase 2", MEF 6.1, April 2008, <https://mef.net/PDF_Documents/technical-specifications/MEF6-1.pdf>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>. [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>. [RFC7385] Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, <https://www.rfc-editor.org/info/rfc7385>. [RFC7387] Key, R., Ed., Yong, L., Ed., Delord, S., Jounay, F., and L. Jin, "A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network", RFC 7387, DOI 10.17487/RFC7387, October 2014, <https://www.rfc-editor.org/info/rfc7387>. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>. [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.9.2、 参考资料[EVPN-INTEGRATED] Sajassi, A., Salam, S., Thoria, S., Drake, J., Rabadan, J., and L. Yong, "Integrated Routing and Bridging in EVPN", Work in Progress, draft-ietf-bess-evpn-inter-subnet-forwarding-03, February 2017. [IEEE.802.1ah] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", Clauses 25 and 26, IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146. [IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2011.6009146. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>. [RFC7796] Jiang, Y., Ed., Yong, L., and M. Paul, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)", RFC 7796, DOI 10.17487/RFC7796, March 2016, <https://www.rfc-editor.org/info/rfc7796>.附录 A、 每个 E-Tree 服务实例的多个桥接表当给定 PE 上的两个 MAC-VRF（每个 VLAN 两个网桥表）用于 E-Tree 服务（一个用于根 AC，另一个用于叶子 AC）时，数据平面路径中可能会出现以下复杂情况。为每个 VLAN 维护两个 MAC-VRF（两个网桥表）（当该 VLAN 存在叶子和根 AC 时）将需要在每个方向上的每个 MAC 地址执行两次查找，以防丢失，或者需要重复许多 MAC属于同一个 VLAN（同一个 E-Tree 实例）的两个网桥表之间的地址。除非进行两次查找，否则本地学习的和远程学习的 MAC 地址都需要重复 MAC 地址。从Leaf AC本地学习到的MAC地址需要复制到根桥表中，从Root AC本地学习到的MAC地址需要复制到Leaf桥表中。从根 AC 远程学习的 MAC 地址需要复制到根和叶子桥表中。由于与数据平面实施额外的 MAC 查找或 MAC 条目的重复相关的潜在低效率，在某些平台中，如果没有数据平面性能低效，则认为此选项无法实施；因此，本文档介绍了第 3.2 节中所述和第 4.1 节中详述的着色。致谢我们要感谢 Eric Rosen、Jeffrey Zhang、Wen Lin、Aldrin Issac、Wim Henderickx、Dennis Cai 和 Antoni Przygienda 的宝贵意见和贡献。作者还要感谢 Thomas Morin 对本文档的指导和提供的宝贵意见。
-
发表了文章 2023-03-04
IP/TCP 网络中的拥塞控制
RFC896：Congestion Control in IP/TCP Internetworks，6 January 1984本备忘录讨论了 IP/TCP 互联网络中拥塞控制的某些方面。它旨在激发对该主题的思考和进一步讨论。虽然对改进拥塞控制实施提出了一些具体建议，但本备忘录并未指定任何标准。1、 介绍拥塞控制是复杂网络中公认的问题。我们发现国防部的互联网协议 (Internet Protocol，IP) 是一种纯数据报协议，而传输控制协议 (Transmission Control Protocol，TCP) 是一种传输层协议，当一起使用时，会遇到由传输和数据报之间的交互引起的异常拥塞问题层。特别是，IP 网关容易受到我们称为“拥塞崩溃”的现象的影响，尤其是当此类网关连接带宽差异很大的网络时。我们已经开发出防止拥塞崩溃的解决方案。这些问题通常没有被认识到，因为这些协议最常用于建立在 ARPANET IMP 技术之上的网络。基于 ARPANET IMP 的网络传统上具有统一的带宽和相同的交换节点，并且具有大量过剩的容量。对于大多数 IP/TCP 主机和网络来说，这种过剩的容量以及 IMP 系统限制主机传输的能力足以处理拥塞。然而，随着最近 ARPANET 分裂为两个互连网络以及连接到 ARPANET 的具有不同属性的其他网络的增长，依赖 IMP 系统的良性属性已不再足以让主机快速可靠地通信。现在，要在负载下成功运行网络，必须改进拥塞处理。福特航空航天和通信公司及其母公司福特汽车公司运营着当今唯一的私有 IP/TCP 长途网络。该网络连接了四个设施（一个在密歇根州，两个在加利福尼亚州，一个在英格兰），其中一些设施具有广泛的本地网络。该网络与 ARPANET 交叉连接，但使用自己的长途线路；福特设施之间的流量通过私人租用线路流动，包括租用的跨大西洋卫星连接。所有交换节点都是纯 IP 数据包交换机，没有节点到节点的流量控制，并且所有主机都运行由 Ford 或 Ford Aerospace 编写或大量修改的软件。该网络中链路的带宽变化很大，从每秒 1200 到 10,000,000 位。总的来说，我们无法负担阿帕网拥有的超额长途带宽的奢侈，而且我们的长途链路在高峰期负载很重。因此，几秒钟的传输时间在我们的网络中很常见。由于我们纯数据包方向、重负载和带宽变化很大，我们不得不解决 ARPANET/MILNET 社区刚刚开始认识到的问题。我们的网络对主机 TCP 实现的次优行为很敏感，无论是在我们自己的网络上还是在我们自己的网络外。我们投入了大量精力来检查各种条件下的 TCP 行为，并解决了一些普遍存在的 TCP 问题。我们在这里提出两个问题及其解决方案。许多 TCP 实现都有这些问题；如果对于给定的 TCP 实现，通过 ARPANET/MILNET 网关的吞吐量比通过单个网络的吞吐量差，则 TCP 实现很可能存在这些问题中的一个或两个。2、 拥塞崩溃在我们继续讨论这两个具体问题及其解决方案之前，有必要先描述一下当这些问题没有得到解决时会发生什么。在具有端到端重传的重载纯数据报网络中，随着交换节点变得拥塞，通过网络的往返时间增加，并且网络内传输的数据报数量也增加。这是负载下的正常行为。只要传输中的每个数据报只有一个副本，拥塞就受到控制。一旦开始重传尚未交付的数据包，就有可能出现严重的问题。主机 TCP 实现预计会以增加的时间间隔多次重传数据包，直到达到重传间隔的某个上限。通常，这种机制足以防止严重的拥塞问题。然而，即使使用更好的自适应主机重传算法，网络上的突然负载也会导致往返时间上升得比发送主机的往返时间测量值更新得更快。当新的批量传输（例如文件传输）开始并开始填充大窗口时，就会发生此类加载。如果往返时间超过任何主机的最大重传间隔，该主机将开始将越来越多的相同数据报的副本引入网络。网络现在遇到了严重的问题。最终，交换节点中的所有可用缓冲区都将满，必须丢弃数据包。传送的数据包的往返时间现在已达到最大值。主机多次发送每个数据包，最终每个数据包的某个副本到达其目的地。这就是拥塞崩溃。这种情况是稳定的。一旦达到饱和点，如果选择要丢弃的数据包的算法是公平的，网络将继续在降级条件下运行。在这种情况下，每个数据包都被多次传输，吞吐量减少到正常的一小部分。我们已经通过实验将我们的网络推到了这种状态并观察了它的稳定性。往返时间可能会变得如此之大，以至于由于主机超时而导致连接中断。在 ARPANET/MILNET 系统中通常不会出现拥塞崩溃和病理性拥塞，因为这些网络具有大量的过剩容量。在连接不通过 IP 网关的情况下，IMP 到主机的流量控制机制通常可以防止拥塞崩溃，特别是因为 TCP 实现往往会针对与纯 ARPANET 情况相关的时间常数进行很好的调整。然而，除了 ICMP源抑制消息之外，当 TCP 在 ARPANET / MILNET 上运行并且数据包在网关处被丢弃时，没有什么能从根本上防止拥塞崩溃。值得注意的是，一些行为不良的主机本身可以使网关拥塞并阻止其他主机通过流量。我们已经在 ARPANET 上的某些主机（我们已与他们的管理员私下通信）中反复观察到这个问题。向网关添加额外的内存不会解决问题。添加的内存越多，在数据包被丢弃之前往返时间必须变得越长。因此，拥塞崩溃的开始将被延迟，但是当崩溃发生时，网络中更大比例的数据包将是重复的，吞吐量甚至会更糟。3、 两个问题已经观察到 TCP 实现工程的两个关键问题；我们称这些为小包问题和源抑制问题。第二个正在由几个实现者解决；第一个通常被认为（错误地）解决了。我们发现，一旦解决了小数据包问题，源抑制问题就变得更容易处理了。因此，我们首先介绍小数据包问题及其解决方案。3.1、 小包问题有一个与小数据包相关的特殊问题。当 TCP 用于传输源自键盘的单字符消息时，典型的结果是为每个有用的数据字节传输 41 字节的数据包（一个字节的数据，40 个字节的标头）。这 4000% 的开销很烦人，但在轻负载网络上是可以容忍的。然而，在负载很重的网络上，这种开销导致的拥塞可能导致数据报丢失和重传，以及交换节点和网关中的拥塞导致过多的传播时间。在实践中，吞吐量可能会下降到 TCP 连接被中止的程度。这个经典问题是众所周知的，最早在 1960 年代后期在 Tymnet 网络中得到解决。那里使用的解决方案是对每单位时间生成的数据报的数量施加限制。这个限制是通过将小数据包的传输延迟到很短（200-500 毫秒）的时间过去来强制执行的，希望在计时器用完之前，另外一个或两个字符可以添加到同一个数据包中。提高用户可接受性的附加功能是在接收到控制字符（例如回车符）时抑制时间延迟。此技术已用于 NCP Telnet、X.25 PAD 和 TCP Telnet。它的优点是易于理解，并且实施起来并不太难。它的缺陷是很难想出一个让所有人都满意的时间限制。一个足够短的时间限制以在每秒 10M 比特的以太网上提供高响应服务将太短以防止拥塞崩溃在一个具有 5 秒往返时间的重负载网络上；相反，如果时间限制足够长以处理负载过重的网络，则会在以太网上产生沮丧的用户。3.2、 小包问题的解决方案显然，一种适应性方法是可取的。人们会期望根据 TCP 观察到的往返延迟提出自适应数据包间时间限制。虽然这样的机制当然可以实施，但没有必要。已经发现了一个简单而优雅的解决方案。解决方案是，如果任何先前在连接上传输的数据仍未得到确认，则在来自用户的新传出数据到达时禁止发送新的 TCP 段。这种抑制是无条件的；不需要计时器、接收数据大小的测试或其他条件。实现通常需要在 TCP 程序中使用一两行。乍一看，这个解决方案似乎意味着 TCP 行为的急剧变化。事实并非如此。一切都在最后。让我们看看为什么会这样。当用户进程写入 TCP 连接时，TCP 会收到一些数据。它可以保存该数据以备将来发送或可以立即发送数据包。如果它现在不发送，它通常会在传入数据包到达并更改系统状态时稍后发送数据。状态以两种方式之一改变；传入的数据包确认远程主机已接收到的旧数据，或宣布远程主机中缓冲区空间的可用性可用于新数据。（这最后被称为“更新窗口”）。每次数据到达连接时，TCP 必须重新检查其当前状态，并且可能会发送一些数据包。因此，当我们省略从用户到达时发送数据时，我们只是将其传输推迟到下一条消息从远程主机到达。除非连接先前空闲或与另一端的通信已丢失，否则消息必须始终尽快到达。在第一种情况下，空闲连接，我们的方案将导致每当用户写入 TCP 连接时发送一个数据包。因此我们不会在空闲状态下死锁。在第二种情况下，远程主机出现故障，发送更多数据无论如何都是徒劳的。请注意，我们没有采取任何措施来抑制正常的 TCP 重传逻辑，因此丢失消息不是问题。对该方案在各种条件下的行为的检查表明该方案在所有情况下都有效。要检查的第一个案例是我们想要解决的案例，即面向字符的 Telnet 连接。让我们假设用户每 200 毫秒向 TCP 发送一个新字符，并且连接是通过以太网进行的，往返时间包括 50 毫秒的软件处理。没有任何防止小包拥塞的机制，每个字符发送一个包，响应最优。开销将是 4000%，但这在以太网上是可以接受的。经典的计时器方案，限制为每秒 2 个数据包，将导致每个数据包发送两个或三个字符。因此，即使在高带宽以太网上这是不必要的，响应也会降级。开销将下降到 1500%，但在以太网上这是一个糟糕的权衡。在我们的方案中，用户输入的每个字符都会找到具有空闲连接的 TCP，并且该字符将被立即发送，就像在无控制的情况下一样。用户不会看到任何可见的延迟。因此，我们的方案与无控制方案的性能一样好，并且提供了比定时器方案更好的响应能力。要检查的第二种情况是相同的 Telnet 测试，但通过具有 5 秒往返时间的长途链路进行测试。如果没有任何防止小数据包拥塞的机制，5 秒内将发送 25 个新数据包。（这里的开销是 4000%。）使用经典的计时器方案，以及每秒 2 个数据包的相同限制，仍然会有 10 个数据包未完成并导致拥塞。当然，发送许多数据包不会改善往返时间；通常情况会更糟，因为数据包会争用线路时间。开销现在下降到 1500%。然而，在我们的方案中，来自用户的第一个字符将找到空闲的 TCP 连接并立即发送。接下来的 24 个字符以 200 毫秒的间隔从用户到达，将等待来自远程主机的消息。当第一个数据包在 5 秒结束时收到 ACK 时，将发送一个包含 24 个排队字符的数据包。因此，我们的方案将开销减少到 320%，而不会影响响应时间。我们的方案通常会改进响应时间，因为减少了数据包开销，比经典定时器方案减少了 4.7 倍。这个因素会减少拥塞，往返延迟会急剧减少。对于这种情况，我们的方案比其他任何一种方法都有显着的优势。* 这个问题在纯 ARPANET 情况下不会出现，因为当未完成的数据包计数变得过多时，IMP 会阻塞主机，但在纯数据报本地网（如以太网）或纯数据报网关（如当涉及 ARPANET / MILNET 网关）时，可能会有大量未完成的小数据包。我们将我们的方案用于所有 TCP 连接，而不仅仅是 Telnet 连接。让我们看看使用我们的技术进行文件传输数据连接会发生什么。将再次考虑这两种极端情况。和以前一样，我们首先考虑以太网情况。用户现在以 512 字节块的形式向 TCP 写入数据，速度与 TCP 接受它们的速度一样快。用户对 TCP 的第一次写入将开始进行；我们的第一个数据报将是 512+40 字节或 552 字节长。用户对 TCP 的第二次写入不会导致发送，但会导致块被缓冲。假设用户在第一个 ACK 返回之前填满了 TCP 的传出缓冲区。然后当 ACK 进来时，所有排队的数据将被发送到窗口大小。从那时起，窗口将保持满状态，因为每个 ACK 启动一个发送周期并发送排队的数据。因此，在仅发送一个块的一个往返时间初始阶段之后，我们的方案稳定到最大吞吐量条件。以太网上的启动延迟只有50ms，因此启动瞬态无关紧要。在这种情况下，所有三种方案都提供了等效的性能。最后，让我们看看通过 5 秒往返时间连接的文件传输。同样，在第一个 ACK 返回之前，只会发送一个数据包；然后窗口将被填充并保持完整。由于往返时间为 5 秒，因此前 5 秒仅传输 512 字节的数据。假设一个2K的窗口，一旦第一个ACK进来，就会发送2K的数据，之后会保持每5秒2K的稳定速率。仅在这种情况下，我们的方案不如定时器方案，区别仅在于启动瞬态；稳态吞吐量相同。在上述条件下，naive 方案和定时器方案都需要 250 秒来传输 100K 字节的文件，而我们的方案需要 254 秒，相差 1.6%。因此，对于所有检查的情况，我们的方案提供了至少 98% 的其他方案的性能，并且在具有长往返时间的路径上提供了 Telnet 性能的显着改进。我们在福特航空航天软件工程网络中使用我们的方案，并且能够通过以太网运行屏幕编辑器并与远程 TOPS-20 主机通信，在这两种情况下都具有更高的性能。3.3、 使用 ICMP 进行拥塞控制在解决了小包拥塞问题以及我们自己网络中小包过度拥塞的问题后，我们将注意力转向了通用拥塞控制问题。由于我们自己的网络是没有节点到节点流量控制的纯数据包，因此在 IP 标准下我们唯一可用的机制是 ICMP源抑制消息。通过仔细处理，我们发现这足以防止严重的拥塞问题。我们确实发现有必要注意我们的主机和交换节点关于源抑制消息的行为。3.4、 何时发送 ICMP源抑制当前的 ICMP 标准规定，无论何时丢弃数据包都应发送 ICMP源抑制消息，此外还可以在网关发现自身资源短缺时发送。这里有一些歧义，但很明显，在不发送 ICMP 消息的情况下丢弃数据包是违反标准的。我们的基本假设是在正常网络操作期间不应丢弃数据包。因此，我们希望在发送者使交换节点和网关过载之前对其进行节流。我们所有的交换节点都会在缓冲区空间耗尽之前发送 ICMP源抑制消息；在发送 ICMP源抑制之前，它们不会等到有必要丢弃消息。正如我们对小数据包问题的分析所证明的那样，仅仅提供大量缓冲不是解决方案。一般来说，我们的经验是，当大约一半的缓冲空间耗尽时，应该发送源抑制；这不是基于广泛的实验，而是一个合理的工程决策。可以主张一种自适应方案，根据最近的经验调整抑制发生阈值；我们还没有发现这有必要。存在仅在一个以上的数据包被丢弃后才生成源抑制的其他网关实现。我们认为这种方法是不可取的，因为任何基于丢弃数据包来控制拥塞的系统都会浪费带宽，并且在重负载下可能容易发生拥塞崩溃。我们的理解是，极不情愿地产生源抑制的决定源于对确认流量将被抑制并且这将导致连接失败的恐惧。如下所示，主机实现中对源抑制的适当处理消除了这种可能性。3.5、 收到 ICMP源抑制后该怎么办当 ICMP 收到源抑制时，我们会通知 TCP 或该层的任何其他协议。我们的 TCP 实现的基本操作是减少与源抑制中提到的主机的连接上未完成的数据量。通过使发送 TCP 表现得好像远程主机的窗口大小已减小来应用此控制。我们的第一个实现很简单但很有效；一旦接收到源抑制，当窗口不为空时，我们的 TCP 就好像窗口大小为零一样。这种行为一直持续到收到一定数量的（目前为 10 个）ACK，此时 TCP 恢复正常运行。* Linkabit Corporation 的 David Mills 此后对其 DCN 中未完成数据包的计数实施了类似但更精细的限制系统。额外的复杂性似乎在吞吐量上产生了适度的增长，但我们还没有进行正式的测试。这两种实现都有效地防止了交换节点中的拥塞崩溃。* ARPANET RFC 792 是现行标准。美国国防通信局告知我们，MIL-STD-1777 中对 ICMP 的描述不完整，将从该标准的未来修订版中删除。因此，源抑制具有将连接限制为有限数量（可能是一个）未完成消息的效果。因此，通信可以继续，但速率会降低，这正是所需的效果。该方案的重要特性是源抑制不禁止发送确认或重传。完全在 IP 层内实现源抑制通常是不成功的，因为 IP 缺乏足够的信息来正确地限制连接。阻止确认往往会产生重传，从而产生不必要的流量。阻止重传可能会因重传超时而导致连接丢失。我们的方案将在严重过载的情况下保持连接活跃，但每个连接的带宽会减少。与 TCP 处于同一层的其他协议也应响应源抑制。在每种情况下，我们都会建议应限制新流量，但应正常处理确认。唯一严重的问题来自用户数据报协议，通常不是主要的流量生成器。我们尚未在这些协议中实施任何限制；所有都由 ICMP 传递源抑制消息，但忽略它们。4、 网关自卫正如我们所展示的，网关容易受到主机拥塞管理不善的影响。生成过多流量导致的主机不当行为不仅会阻止主机自己的流量通过，还会干扰其他无关的流量。该问题可以在主机级别处理，但由于一台故障主机可能会干扰其他主机，因此未来的网关应该能够保护自己免受讨厌或恶意主机的此类行为的影响。我们提供一些基本的自卫技巧。1983 年末有一次，ARPANET 主机中的 TCP 错误导致主机以ARPANET 接受它们的速度疯狂地生成相同数据报的重传。连接我们的网络与 ARPANET 的网关已经饱和，几乎没有有用的流量可以通过，因为网关到 ARPANET 的带宽比到我们的网络的带宽要多。网关忙着发送 ICMP源抑制消息，但故障主机忽略了它们。这持续了几个小时，直到故障主机崩溃。在此期间，我们的网络实际上与 ARPANET 断开了连接。* 这遵循控制工程的格言“永远不要打扰比例控制，除非 bang-bang 不起作用”。当网关被迫丢弃数据包时，该数据包由网关自行选择。做出此决定的经典技术是丢弃最近收到的数据包，或最长传出队列末尾的数据包。我们建议一个有价值的实际措施是丢弃来自主机的最新数据包，该主机源自当前在网关中排队的最多数据包。该策略倾向于平衡使用网关的主机之间的吞吐量。我们还没有尝试过这种策略，但它似乎是网关自我保护的合理起点。另一种策略是如果新到达的数据包与队列中已有的数据包重复，则丢弃该数据包。如果使用散列技术，则此检查的计算负载不是问题。此检查不会防范恶意主机，但会针对重传控制不佳的 TCP 实现提供一些保护。如果本地主机被调整为与本地网络很好地工作，则快速本地网络和较慢的长途网络之间的网关可能会发现此检查很有价值。理想情况下，网关应该检测故障主机并压制它们；这种检测在纯数据包系统中是困难的。但是，未能响应 ICMP源抑制消息应被视为网关采取措施断开主机连接的理由。检测此类故障并非易事，但值得进一步研究。5、结论与纯数据报网络相关的拥塞控制问题很困难，但存在有效的解决方案。如果 IP/TCP 网络要在高负载下运行，TCP 实现必须以至少与此处描述的方法一样有效的方式解决几个关键问题。
-
发表了文章 2023-03-04
TCP 选项和最大分片大小 (MSS)
RFC6691：TCP Options and Maximum Segment Size (MSS)，July 2012梗概本备忘录讨论了与 TCP 最大分片大小 (Maximum Segment Size，MSS) 选项一起使用的值，并更新了 RFC 879 和 RFC 2385。本备忘录的状态本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6691。版权声明版权所有 (c) 2012 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍在使用 IP 和 TCP 选项时，对于 TCP MSS 选项使用什么值存在一些混淆。RFC 879 [RFC879] 指出：MSS 只计算段中的数据八位字节，它不计算 TCP 报头或 IP 报头。该声明不清楚如何处理 IP 和 TCP 选项，因为它们是报文头的一部分。RFC 1122 [RFC1122] 阐明了 MSS 选项，这在附录 A 中进行了讨论，但似乎仍然存在一些混淆。1.1、 术语本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119] 中的描述进行解释。2、 简短声明在计算放入 TCP MSS 选项的值时，MTU 值应该仅减少固定 IP 和 TCP 报文头的大小，并且不应减少以考虑任何可能的 IP 或 TCP 选项；相反，发送方必须减少 TCP 数据长度以说明它在发送的数据包中包含的任何 IP 或 TCP 选项。本文档的其余部分仅阐述了该声明，其目标是避免 TCP 数据包的 IP 级分片。TCP固定头大小为20字节[RFC793]，IPv4固定头大小为20字节[RFC791]，IPv6固定头大小为40字节[RFC2460]。确定应该使用什么 MTU 值，尤其是在多宿主主机的情况下，超出了本文档的范围。3、 其他 RFC 中的 MSS3.1、 RFC 879RFC 879 [RFC879] 讨论了 MSS 选项和其他主题。在引言中，它指出：TCP 最大分片大小是 IP 最大数据报大小减去40。在第 13 节中，它指出：MSS 选项的定义可以表述为：在没有 IP 头选项的 IP 数据报中传输的没有 TCP 头选项的 TCP 段中，此 TCP 选项的发送方可以接收的最大数据八位字节数。这些都是正确的。然而，在下一段——在第 14 节中——它通过声明结果是：当 TCP 用于 IP 或 TCP 报头不是最小但可以接收的最大 IP 数据报仍然是 576 个八位字节的情况下时，必须使用 TCP 最大分片大小选项来减少对数据8位字节的限制TCP 段。例如，如果使用 IP 安全选项（11 个八位字节）并且 IP 最大数据报大小保持在 576 个八位字节，则 TCP 应发送值为 525 (536-11) 的 MSS。那是不正确的。更简单、更正确的说法是：当 TCP 用于 IP 或 TCP 报文头不是最小的情况时，发送方必须将任何给定数据包中的 TCP 数据量减少 IP 和 TCP 选项使用的八位字节数。3.2、 RFC 2385RFC 2385 [RFC2385] 在第 4.3 节中错误地指出：与添加到每个段的其他选项一样，MD5 选项的大小必须考虑到在连接协商期间提供给另一端的 MSS 中。具体来说，要从 MTU 中减去的报文头大小（无论是传出接口的 MTU 还是 IP 的最小 MTU 576 字节）现在至少要大 18 字节。这是不正确的。MSS 选项的值仅由固定 IP 和 TCP 报文头调整。4、 来自 TCP 大型 Windows 邮件列表的澄清最初的澄清于 1993 年发送到 TCP Large Windows 邮件列表 [Borman93]；本节基于该消息。要在 MSS 选项中发送的 MSS 值应等于有效 MTU 减去固定 IP 和 TCP 报文头。通过在计算 MSS 选项的值时同时忽略 IP 和 TCP 选项，如果数据包中有任何 IP 或 TCP 选项要发送，则发送方必须相应地减小 TCP 数据的大小。原因如下表所示：目标是不发送必须分片的 IP 数据包，并且发送带有此网格右下方约束的数据包将导致 IP 分片。由于发送方不知道接收到的 MSS 选项是否被调整为包含选项，因此保证数据包不会太长的唯一方法是数据发送方将 TCP 数据长度减少 IP 和 TCP 选项的大小.因此，由于发送方在发送 IP 和 TCP 选项时将调整 TCP 数据长度，因此无需在 MSS 值中包含 IP 和 TCP 选项长度。另一个反对在确定 MSS 值时包含 IP 或 TCP 选项的论点是 MSS 是一个固定值，而且就其本质而言，IP 和 TCP 选项的长度是可变的，因此 MSS 值永远无法准确反映所有可能的 IP和 TCP 选项组合。唯一确定任何给定数据包中有多少 IP 和 TCP 选项的是发送者；因此，发送方应该调整 TCP 数据长度以考虑任何 IP 和 TCP 选项。5、 其他注意事项5.1、 路径 MTU 发现TCP MSS 选项指定可以接收的数据包大小的上限。因此，将 MSS 选项中的值设置得太小会影响路径 MTU 发现找到更大路径 MTU 的能力。有关路径 MTU 发现的更多信息，请参阅：“路径 MTU 发现”[RFC1191] “路径 MTU 发现的 TCP 问题”[RFC2923] “分组层路径 MTU 发现” [RFC4821]5.2、 具有可变 MSS 值的接口有效 MTU 有时可能会有所不同，如与可变压缩一起使用时，例如 RObust 报文头压缩 (RObust Header Compression，ROHC) [RFC5795]。TCP 想要通告最大可能的 MSS，以支持最有效地使用压缩的有效载荷是很诱人的。不幸的是，一些压缩方案偶尔需要传输完整的报头（以及较小的有效载荷）以重新同步其端点压缩器/解压缩器的状态。如果最大 MTU 用于计算 MSS 选项中要通告的值，则 TCP 重传可能会干扰压缩器重新同步。因此，当接口的有效 MTU 变化时，TCP 应该使用接口的最小有效 MTU 来计算 MSS 选项中要通告的值。5.3、 IPv6 跳转为了支持 TCP over IPv6 jumbograms，实现需要能够发送大于 64K 的 TCP 段。RFC 2675 [RFC2675] 定义了 65,535 的值被视为无穷大，并且路径 MTU 发现 [RFC1981] 用于确定实际的 MSS。5.4、 避免分片太长的数据包将被分割或丢弃。如果数据包被分片，中间防火墙或中间设备可能会丢弃分片的数据包。在任何一种情况下，当数据包被丢弃时，连接都可能失败；因此，最好避免生成分片。6、 安全考虑本文档阐明了如何确定应该为 MSS 选项使用什么值，并且没有引入任何新的安全问题。7、 参考文献7.1、 规范参考[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, November 1983. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.7.2、 参考资料[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the tcplw mailing list, January 7, 1993. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.附录 A、 来自 RFC 793 和 RFC 1122 的详细信息RFC 793 [RFC793] 将 MSS 选项定义如下：最大分片大小选项数据：16 位如果存在此选项，则它会在发送此段的 TCP 处传达最大接收段大小。该字段只能在初始连接请求中发送（即，在设置了 SYN 控制位的段中）。如果未使用此选项，则允许任何段大小。RFC 1122 [RFC1122] 在第 85-86 页的第 4.2.2.6 节中提供了额外的说明。首先，当 MSS 选项不存在时，它会更改默认行为：如果在连接建立时没有收到 MSS 选项，TCP 必须假定默认发送 MSS 为 536 (576-40) [TCP:4]。然后，它阐明了如何确定要在 MSS 选项中使用的值：在 MSS 选项中发送的 MSS 值必须小于或等于：MMS_R - 20其中 MMS_R 是可以接收（和重组）的传输层消息的最大大小。TCP从IP层获取MMS_R和MMS_S；请参阅第 3.4 节中的通用调用 GET_MAXSIZES。RFC 1122 中暗示但未明确说明的是 20 是固定 TCP 报文头的大小。MMS_R 的定义见第 3.3.2 节，第 57 页：MMS_R 由下式给出：MMS_R = EMTU_R - 20因为 20 是 IP 报文头的最小大小。第 56 页（也是第 3.3.2 节）：我们指定了可以由 EMTU_R（“有效 MTU 接收”）重新组装的最大数据报大小；这有时称为“重组缓冲区大小”。EMTU_R 必须大于或等于 576，应该是可配置的或不确定的，并且应该大于或等于所连接网络的 MTU。这里需要注意的是，EMTU_R是可以重组的最大数据报大小，而不是不分片可以接收的最大数据报大小。从字面上看，由于大多数现代 TCP/IP 实现可以重新组装完整的 64K IP 数据包，因此实现应该使用 65535 - 20 - 20 或 65495 作为 MSS 选项。但还有更多。RFC 1122 还在第 86 页上指出：TCP 段大小的选择对性能有很大的影响。更大的段通过在更多的数据字节上分摊报头大小和每个数据报的处理开销来增加吞吐量；然而，如果数据包太大导致 IP 分片，如果任何分片丢失，效率就会急剧下降 [IP:9]。由于保证任何大于连接网络的 MTU 的 IP 数据报都必须被分片才能被接收，因此实现忽略了“应该大于或等于连接网络的 MTU”的“大于或”部分网络”。因此，要在 MSS 选项中发送的 MSS 值必须小于或等于：EMTU_R - FixedIPhdrsize - FixedTCPhdrsize其中 FixedTCPhdrsize 是 20，FixedIPhdrsize 是 IPv4 的 20 和 IPv6 的 40。
-
发表了文章 2023-03-04
DS：差异化服务架构
RFC2475：An Architecture for Differentiated Services，December 1998本备忘录的状态本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (1998)。版权所有。梗概本文档定义了在 Internet 中实现可扩展服务差异化的体系结构。该架构通过聚合流量分类状态来实现可扩展性，该状态通过使用 DS 字段 [DSFIELD] 的 IP 层数据包标记来传达。数据包被分类和标记以在其路径上的节点上接收特定的每跳转发行为。复杂的分类、标记、监管和整形操作只需在网络边界或主机上实施。网络资源通过服务供应策略分配给流量流，该策略控制流量在进入具有差异化服务能力的网络时如何标记和调节，以及流量如何在该网络内转发。可以在这些构建块之上实施各种各样的服务。1、 介绍1.1、 概述本文档定义了在 Internet 中实现可扩展服务差异化的体系结构。“服务”定义了跨网络内一组一条或多条路径在一个方向上的数据包传输的一些重要特征。这些特性可以通过吞吐量、延迟、抖动和/或损失的定量或统计术语来指定，或者可以其他方式根据对网络资源的访问的某些相对优先级来指定。需要服务差异化以适应异构应用需求和用户期望，并允许互联网服务的差异化定价。该架构由在网络节点中实现的许多功能元素组成，包括一小组每跳转发行为、数据包分类功能和流量调节功能，包括计量、标记、整形和监管。该架构通过仅在网络边界节点实现复杂的分类和调节功能，并将每跳行为应用于已使用 IPv4 或 IPv6 报头 [DSFIELD] 中的 DS 字段适当标记的流量聚合来实现可扩展性。每跳行为被定义为允许在竞争流量流之间的每个节点上分配缓冲区和带宽资源的合理粒度方法。每个应用程序流或每个客户转发状态不需要在网络核心内维护。保持以下区别：* 提供给流量聚合的服务，* 用于实现服务的条件函数和每跳行为，* 用于标记数据包以选择每跳行为的 DS 字段值（DS 代码点），以及* 实现每跳行为的特定节点实现机制。业务提供和流量调节策略与网络内部的转发行为充分解耦，允许实现多种业务行为，并有未来扩展的空间。这种架构仅在一个流量方向上提供服务差异化，因此是不对称的。互补对称架构的开发是当前研究的主题，但超出了本文档的范围；参见例如 [EXPLICIT]。第1.2章节是本文档中使用的术语表，第1.3章节列出了此架构所解决的要求，第1.4章节提供了与其他服务差异化方法的简要比较。第2章节详细讨论了架构的组件。第3章节提出了每跳行为规范的指导方针。第4章节讨论了与未实现本文档和 [DSFIELD] 中定义的差异化服务的节点和网络的互操作性问题。第5章节讨论了组播服务交付的问题。第6章节解决了安全和隧道方面的考虑。1.2、 术语本节给出了本文档中使用的术语的一般概念概述。本文档后面的部分对其中一些术语进行了更精确的定义。行为聚合 (Behavior Aggregate，BA)DS 行为聚合。BA分类器仅根据 DS 字段的内容选择数据包的分类器。边界链路连接两个域的边缘节点的链路。分类器根据定义的规则根据包头的内容选择包的实体。DS行为聚合具有相同 DS 代码点的数据包集合，沿特定方向穿过链路。DS边界节点将一个 DS 域连接到另一个 DS 域或不支持 DS 的域中的节点的 DS 节点。DS 能力能够实现本架构中描述的差异化服务；通常用于指由符合 DS 的节点组成的域。DS代码点DS 字段的 DSCP 部分的特定值，用于选择 PHB。符合 DS 标准能够支持 [DSFIELD]、本文档和其他差异化服务文档中定义的差异化服务功能和行为；通常用于指代节点或设备。DS域一个支持 DS 的域；一组连续的节点，这些节点使用一组通用的服务提供策略和 PHB 定义进行操作。DS出口节点DS 边界节点在其离开 DS 域时处理流量的角色。DS入口节点DS 边界节点在其进入 DS 域时处理流量的角色。DS内部节点不是 DS 边界节点的 DS 节点。DS字段当按照 [DSFIELD] 中给出的定义进行解释时，IPv4 报头 TOS 八位字节或 IPv6 流量类八位字节。DSCP 字段的位对 DS 代码点进行编码，而其余位当前未使用。DS节点符合 DS 的节点。DS区一组连续的 DS 域，可以通过跨这些 DS 域的路径提供差异化服务。下游DS域边界链路上流量下游的 DS 域。丢弃设备执行丢弃的设备。丢弃根据指定规则丢弃数据包的过程；策略。遗留节点实现 [RFC791,RFC1812] 中定义的 IPv4 优先级但不符合 DS 的节点。标记器执行标记的设备。打标根据定义的规则在数据包中设置 DS 代码点的过程；预先标记，重新标记。机制在节点中实现的特定算法或操作（例如，排队规则）以实现一组一个或多个每跳行为。计量器执行计量的设备。计量测量分类器选择的流量流的时间属性（例如，速率）的过程。该过程的瞬时状态可用于影响标记器、整形器或投放器的操作，和/或可用于计数和测量目的。微流应用程序到应用程序数据包流的单个实例，由源地址、源端口、目标地址、目标端口和协议 ID 标识。MF分类器一个多字段 (multi-field，MF) 分类器，它根据任意数量的报头字段的内容来选择数据包；通常是源地址、目标地址、DS 字段、协议 ID、源端口和目标端口的某种组合。每跳行为 (Per-Hop-Behavior，PHB)在符合 DS 的节点上应用到 DS 行为聚合的外部可观察转发行为。PHB组由于适用于集合中所有 PHB 的共同约束（例如队列服务或队列管理策略），一组一个或多个 PHB 只能有意义地同时指定和实施。PHB 组提供了一个服务构建块，允许将一组相关的转发行为一起指定（例如，四个丢弃优先级）。单个 PHB 是 PHB 组的特例。策略根据执行流量配置文件的相应计量器的状态，丢弃流量流中的数据包（通过丢弃器）的过程。预标记在进入下游 DS 域之前设置数据包的 DS 代码点。提供者 DS 域向源域提供 DS 服务的提供者。重标记更改数据包的 DS 代码点，通常由标记根据 TCA 执行。服务在 DS 域或端到端中对定义的客户流量子集的整体处理。服务水平协议 (Service Level Agreement，SLA)客户与服务提供者之间的服务合同，其中规定了客户应获得的转发服务。客户可能是一个用户组织（源域）或另一个 DS 域（上游域）。SLA 可能包括流量调节规则，这些规则构成了 TCA 的全部或部分内容。服务提供策略定义如何在 DS 边界节点上配置流量调节器以及如何将流量流映射到 DS 行为聚合以实现一系列服务的策略。整形器一种执行整形的设备。整形延迟流量流中的数据包以使其符合某些定义的流量配置文件的过程。源域一个域，其中包含发起接收特定服务的流量的节点。流量调节器执行流量的实体调节函数，其中可能包含仪表、标记、滴管和整形器。流量调节器通常仅部署在 DS 边界节点中。流量调节器可以重新标记流量流，或者可以丢弃或整形数据包以改变流的时间特性并使其符合流量配置文件。流量调节控制为强制执行 TCA 中指定的规则而执行的功能，包括计量、标记、整形和监管。流量调节协议 (Traffic Conditioning Agreement，TCA)协议指定分类器规则和任何相应的流量配置文件以及计量、标记、丢弃和/或整形规则，这些规则将应用于分类器选择的流量流。TCA 包含在 SLA 中明确指定的所有流量调节规则以及从相关服务要求和/或从 DS 域的服务供应策略中隐含的所有规则。流量概况流量流的时间属性的描述，例如速率和突发大小。流量流一组具有管理意义的一个或多个穿过路径段的微流。流量流可能由一组由特定分类器选择的活动微流组成。上游DS域边界链路上流量上游的 DS 域。1.3、 要求Internet 的历史一直是主机数量、应用程序的数量和种类以及网络基础设施容量不断增长的历史之一，并且在可预见的未来预计这种增长将持续下去。用于服务差异化的可扩展架构必须能够适应这种持续增长。在此架构中确定并解决了以下要求：* 应适应各种服务和供应策略，端到端扩展或在特定（组）网络内扩展，* 应该允许服务与正在使用的特定应用程序分离，* 应与现有应用程序一起使用，无需更改应用程序编程接口或主机软件修改（假设分类器、标记和其他流量调节功能的适当部署），* 应将流量调节和服务提供功能与核心网络节点内实现的转发行为分离，* 不应依赖于逐跳应用信令，* 应该只需要一小组转发行为，其实现复杂性不会主导网络设备的成本，并且不会为未来的高速系统实现带来瓶颈，* 应避免核心网络节点内的每个微流或每个客户的状态，* 应仅利用网络核心内的聚合分类状态，* 应允许在核心网络节点（BA 分类器）中实现简单的数据包分类，*应允许与非 DS 兼容网络节点的合理互操作性，* 应适应增量部署。1.4、 与其他方法的比较本文档中指定的差异化服务架构可以与其他现有的服务差异化模型进行对比。我们将这些替代模型分为以下几类：相对优先级标记、服务标记、标签交换、综合服务/RSVP 和静态每跳分类。相对优先级标记模型的示例包括 [RFC791] 中定义的 IPv4 优先级标记、802.5 令牌环优先级 [TR] 和 802.1p 流量类别的默认解释 [802.1p]。在该模型中，应用程序、主机或代理节点为数据包选择一个相对优先级或“优先级”（例如，延迟或丢弃优先级），传输路径上的网络节点应用与优先级值相对应的适当优先级转发行为在数据包的标头内。我们的架构可以被视为对该模型的改进，因为我们更清楚地指定了边界节点和流量调节器的作用和重要性，并且因为我们的每跳行为模型允许比相对延迟或丢弃优先级更通用的转发行为。服务标记模型的一个例子是 [RFC1349] 中定义的 IPv4 TOS。在这个例子中，每个数据包都标有对“服务类型”的请求，其中可能包括“最小化延迟”、“最大化吞吐量”、“最大化可靠性”或“最小化成本”。网络节点可以选择经过适当设计以满足服务请求的路由路径或转发行为。这个模型与我们的架构略有不同。请注意，我们没有描述使用 DS 字段作为路线选择的输入。[RFC1349] 中定义的 TOS 标记是非常通用的并且不跨越可能的服务语义的范围。此外，服务请求与每个单独的数据包相关联，而某些服务语义可能取决于数据包序列的聚合转发行为。服务标记模型不容易适应未来服务数量和范围的增长（因为代码点空间很小）并且涉及在每个核心网络节点中配置“TOS->转发行为”关联。标准化服务标记意味着标准化服务产品，这超出了 IETF 的范围。请注意，在 DS 代码点空间的分配中进行了规定，以允许提供者可以使用本地重要的代码点来支持服务标记语义 [DSFIELD]。标签交换（或虚拟电路）模型的例子包括帧中继、ATM 和 MPLS [FRELAY, ATM]。在此模型中，路径转发状态和流量管理或 QoS 状态是为网络路径上每一跳上的流量流建立的。不同粒度的流量聚合与入口节点处的标签交换路径相关联，每个标签交换路径内的数据包/信元都标有转发标签，用于查找下一跳节点、每跳转发行为、以及每一跳的替换标签。该模型允许对流量流进行更细粒度的资源分配，因为标签值不是全局重要的，而仅在单个链路上重要；因此，可以为在具有特定标签的链路上接收到的数据包/信元的聚合保留资源，并且标签交换语义控制下一跳选择，允许流量流遵循专门设计的路径通过网络。这种改进的粒度以建立和维护标签交换路径的额外管理和配置要求为代价。此外，在最佳情况下（假设多点对点标签交换路径），每个节点维护的转发状态量与网络边缘节点的数量成正比，并与网络边缘节点的平方成正比。最坏情况下的边缘节点数量，当采用具有预配资源的边缘-边缘标签交换路径时。集成服务/RSVP 模型在默认情况下依赖于传统的数据报转发，但允许源和接收器交换信令消息，这些消息在它们之间路径上的每个节点上建立额外的数据包分类和转发状态 [RFC1633，RSVP]。在没有状态聚合的情况下，每个节点上的状态量与并发预留的数量成比例，这在高速链路上可能会很大。该模型还需要应用程序支持 RSVP 信令协议。可以利用差异化服务机制来聚合网络核心 [Bernet] 中的集成服务/RSVP 状态。集成服务/RSVP 模型的一个变体通过仅利用在网络路径上的每个节点中实施的“静态”分类和转发策略，消除了对逐跳信令的要求。这些策略在管理时间尺度上更新，而不是响应网络中活跃的微流的瞬时混合。此变体的状态要求可能比使用 RSVP 时遇到的情况更糟糕，尤其是在骨干节点中，因为随着时间的推移可能适用于节点的静态策略的数量可能大于活动的发送方-接收方会话的数量。可能在节点上安装了保留状态。尽管支持大量分类器规则和转发策略在计算上可能是可行的，但与在可能被业务流穿越的骨干网络中的每个节点上安装和维护这些规则相关的管理负担是巨大的。尽管我们将我们的架构与这些服务差异化的替代模型进行了对比，但应该注意的是，使用这些技术的链路和节点可用于跨2层交换基础设施（例如，802.1p LAN、帧中继/ATM 主干）扩展差异化服务行为和语义互连 DS 节点，并且在 MPLS 的情况下可以用作替代的域内实现技术。在 DS 域的特定区域（或在提供对 DS 域的访问的网络中）使用特定链路层技术所施加的限制可能意味着在更粗粒度的基础上区分流量。根据 PHB 到不同链路层服务的映射以及在一组受限优先级（或不同类别和容量的虚拟电路）上调度数据包的方式，所有或部分使用中的 PHB 可能是可支持的（或可能无法区分）。2、 差异化服务架构模型差异化服务架构基于一个简单的模型，其中进入网络的流量被分类并可能在网络边界进行调节，并分配给不同的行为聚合。每个行为聚合都由单个 DS 代码点标识。在网络核心内，根据与 DS 代码点关联的每跳行为转发数据包。在本节中，我们将讨论差异化服务区域内的关键组件、流量分类和调节功能，以及如何通过流量调节和基于 PHB 转发的组合来实现差异化服务。2.1、 差异化服务领域DS 域是一组连续的 DS 节点，这些节点以公共服务提供策略和在每个节点上实施的一组 PHB 组运行。DS 域有一个明确定义的边界，由 DS 边界节点组成，这些节点对入口流量进行分类和可能的调节，以确保通过该域的数据包被适当标记，以从域内支持的 PHB 组之一中选择一个 PHB。DS 域内的节点根据其 DS 代码点选择数据包的转发行为，使用推荐的代码点->PHB 映射或本地自定义映射 [DSFIELD] 将该值映射到支持的 PHB 之一。在 DS 域中包含不符合 DS 的节点可能会导致不可预测的性能，并可能妨碍满足服务级别协议 (SLA) 的能力。DS 域通常由同一管理下的一个或多个网络组成；例如，组织的 Intranet 或 ISP。域的管理负责确保提供和/或保留足够的资源来支持域提供的 SLA。2.1.1、 DS 边界节点和内部节点DS域由DS边界节点和DS内部节点组成。DS 边界节点将 DS 域与其他 DS 或不支持 DS 的域互连，而 DS 内部节点仅连接到同一 DS 域内的其他 DS 内部或边界节点。DS 边界节点和内部节点都必须能够根据 DS 代码点对数据包应用适当的 PHB；否则可能会导致不可预测的行为。此外，DS 边界节点可能需要执行由它们的 DS 域和它们连接到的对等域之间的流量调节协议 (TCA) 定义的流量调节功能（参见第 2.3.3 节）。内部节点可能能够执行有限的流量调节功能，例如 DS 代码点重新标记。实现更复杂分类和流量调节功能的内部节点类似于 DS 边界节点（见第 2.3.4.4 节）。包含 DS 域的网络中的主机可以充当来自该主机上运行的应用程序的流量的 DS 边界节点；因此，我们说主机在 DS 域内。如果主机不充当边界节点，则拓扑上最接近该主机的 DS 节点充当该主机流量的 DS 边界节点。2.1.2、 DS 入口节点和出口节点DS 边界节点既充当 DS 入口节点又充当不同方向流量的 DS 出口节点。流量在 DS 入口节点进入 DS 域，并在 DS 出口节点离开 DS 域。DS 入口节点负责确保进入 DS 域的流量符合它与入口节点所连接的其他域之间的任何 TCA。DS 出口节点可以对转发到直接连接的对等域的流量执行流量调节功能，具体取决于两个域之间的 TCA 的详细信息。请注意，DS 边界节点可能充当某些接口集的 DS 内部节点。2.2、 差异化服务区域差异化服务区域（DS Region）是一组一个或多个连续的 DS 域。DS 区域能够沿着跨越区域内的域的路径支持差异化服务。DS 域中的 DS 域内部可能支持不同的 PHB 组和不同的 codepoint->PHB 映射。然而，为了允许跨域的服务，对等 DS 域必须各自建立一个对等 SLA，该 SLA 定义（显式或隐式）TCA，该 TCA 指定从一个 DS 域到另一个域的传输流量如何在两个域之间的边界处进行调节DS 域。一个 DS 区域内的多个 DS 域可能采用公共服务提供策略，并可能支持一组公共 PHB 组和代码点映射，从而消除这些 DS 域之间的流量调节需要。2.3、 流量分类和调节通过在上游网络和下游DS域之间建立SLA来跨越DS域边界扩展差异化服务。SLA 可以指定数据包分类和重新标记规则，还可以指定流量配置文件和对符合或超出配置文件的流量流的操作（参见第 2.3.2 节）。域之间的 TCA 源自（显式或隐式）此 SLA。数据包分类策略通过被调节和/或映射到 DS 域内的一个或多个行为聚合（通过 DS 代码点重新标记）来识别可以接收差异化服务的流量子集。流量调节执行计量、整形、管制和/或重新标记，以确保进入 DS 域的流量符合 TCA 中指定的规则，根据域的服务提供策略。所需的流量调节范围取决于服务提供的细节，范围可能从简单的代码点重新标记到复杂的监管和整形操作。网络之间协商的流量调节策略的详细信息超出了本文档的范围。2.3.1、 分类器数据包分类器根据数据包报头某些部分的内容选择流量流中的数据包。我们定义了两种类型的分类器。BA（行为聚合）分类器仅根据 DS 代码点对数据包进行分类。MF（Multi-Field）分类器根据一个或多个头域的组合值来选择数据包，例如源地址、目的地址、DS域、协议ID、源端口和目的端口号，以及其他信息，例如传入接口。分类器用于将匹配某些指定规则的数据包“引导”到流量调节器的元素以进行进一步处理。分类器必须根据适当的 TCA 由某些管理程序配置。分类器应该验证它用于对数据包进行分类的信息（参见第 6 节）。请注意，在出现上行数据包分段的情况下，检查传输层报头字段内容的 MF 分类器可能会错误地对第一个之后的数据包分段进行分类。这个问题的一个可能解决方案是保持碎片状态；然而，由于上游片段重新排序或发散路由路径的可能性，这不是通用的解决方案。应用于数据包片段的策略超出了本文档的范围。2.3.2、 流量概况流量配置文件指定由分类器选择的流量流的时间属性。它提供了用于确定特定数据包是在配置文件内还是在配置文件外的规则。例如，基于令牌桶的配置文件可能如下所示：codepoint=X, use token-bucket r, b上述配置文件表明，所有标有 DS 代码点 X 的数据包都应根据速率为 r 和突发大小为 b 的令牌桶计量器进行测量。在这个例子中，超出规范的数据包是流量流中的那些数据包，当桶中没有足够的令牌可用时到达。配置文件内和配置文件外的概念可以扩展到两个以上的级别，例如，可以定义和强制执行与配置文件的多个级别的一致性。可以对in-profile报文和out-of-profile报文应用不同的调节动作，也可以触发不同的计费动作。In-profile 数据包可能被允许进入 DS 域而无需进一步调节；或者，他们的 DS 代码点可能会改变。当 DS 代码点第一次设置为非默认值 [DSFIELD] 时，或者当数据包进入使用不同 PHB 组或代码点->PHB 映射策略的 DS 域时，会发生后者。超出配置文件的数据包可能会排队，直到它们符合配置文件（整形）、丢弃（监管）、用新代码点标记（重新标记）或在触发某些计数过程时原封不动地转发。不符合规范的数据包可能被映射到一个或多个行为聚合，这些行为聚合在转发性能的某个维度上“劣于”到符合规范的数据包被映射到的 BA。请注意，流量配置文件是 TCA 的可选组件，其使用取决于服务提供的细节和域的服务供应策略。2.3.3、 流量调节器流量调节器可能包含以下元素：计量器、标记器、整形器和丢弃设备。流量流由分类器选择，分类器将数据包引导至流量调节器的逻辑实例。使用计量器（在适当的情况下）根据流量配置文件测量流量。计量器关于特定数据包的状态（例如，它是在配置文件内还是在配置文件外）可用于影响标记、丢弃或整形动作。当数据包离开 DS 边界节点的流量调节器时，每个数据包的 DS 代码点必须设置为适当的值。图 1 显示了分类器和流量调节器的框图。请注意，流量调节器不一定包含所有四个元素。例如，在没有流量模板生效的情况下，数据包可能只通过一个分类器和一个标记。图 1：数据包分类器和流量调节器的逻辑视图2.3.3.1、 计量器流量计量器根据 TCA 中指定的流量配置文件测量分类器选择的数据包流的时间属性。计量器将状态信息传递给其他调节功能，以触发每个数据包的特定操作，这些数据包要么符合规范，要么不符合规范（在某种程度上）。2.3.3.2、 标记器数据包标记器将数据包的 DS 字段设置为特定的代码点，将标记的数据包添加到特定的 DS 行为聚合。标记器可以被配置为将被引导到它的所有数据包标记为单个代码点，或者可以被配置为将数据包标记为用于选择 PHB 组中的 PHB 的一组代码点中的一个，根据计量器。当标记更改数据包中的代码点时，它被称为“重新标记”了数据包。2.3.3.3、 整形器整形器延迟流量流中的部分或全部数据包，以使该流符合流量配置文件。整形器通常有一个有限大小的缓冲区，如果没有足够的缓冲区空间来容纳延迟的数据包，数据包可能会被丢弃。2.3.3.4、 丢弃设备Dropper 丢弃流量流中的部分或全部数据包，以使该流符合流量配置文件。这个过程被称为“监管”流。请注意，通过将整形器缓冲区大小设置为零（或几个）数据包，可以将丢弃器实现为整形器的特殊情况。2.3.4、 流量调节器和 MF 分类器的位置流量调节器通常位于 DS 入口和出口边界节点内，但也可能位于 DS 域内部的节点中，或位于不支持 DS 的域内。2.3.4.1、 源域内我们将源域定义为包含发起接收特定服务的流量的节点的域。源域内的流量源和中间节点可以执行流量分类和调节功能。来自源域的跨边界的流量在离开源域之前可以由流量源直接标记或由中间节点标记。这被称为初始标记或“预标记”。考虑一个公司的例子，该公司的策略是其 CEO 的数据包应该具有更高的优先级。CEO 的主机可以用指示“更高优先级”的 DS 代码点标记所有传出数据包的 DS 字段。或者，直接连接到 CEO 主机的第一跳路由器可以对流量进行分类，并用正确的 DS 代码点标记 CEO 的数据包。这种高优先级流量也可以在源附近进行调节，从而限制从特定源转发的高优先级流量。将数据包标记为靠近流量源有一些优点。首先，在决定哪些数据包应该接受更好的转发处理时，流量源可以更容易地考虑应用程序的偏好。此外，在流量与来自其他来源的数据包聚合之前，数据包的分类要简单得多，因为需要在单个节点内应用的分类规则的数量减少了。由于数据包标记可能分布在多个节点上，源 DS 域负责确保流向其提供者 DS 域的聚合流量符合适当的 TCA。额外的分配机制，如带宽代理或 RSVP，可用于为提供者网络内的特定 DS 行为聚合动态分配资源 [2BIT, Bernet]。源域的边界节点还应监控与 TCA 的一致性，并根据需要对数据包进行监管、整形或重新标记。2.3.4.2、 在 DS 域的边界业务流可以在边界链路的任一端（上游域的 DS 出口节点或下游域的 DS 入口节点）进行分类、标记和以其他方式进行调节。域之间的 SLA 应指定哪个域负责将流量流映射到 DS 行为聚合并根据适当的 TCA 调节这些聚合。但是，DS 入口节点必须假定传入流量可能不符合 TCA，并且必须准备好根据本地策略执行 TCA。当数据包在上游域中预先标记和调节时，下游 DS 域中需要支持的分类和流量调节规则可能更少。在这种情况下，下游 DS 域可能只需要重新标记或监管传入的行为聚合来强制执行 TCA。然而，更复杂的依赖于路径或源的服务可能需要在下游 DS 域的入口节点中进行 MF 分类。如果 DS 入口节点连接到上游不支持 DS 的域，则 DS 入口节点必须能够对传入流量执行所有必要的流量调节功能。2.3.4.3、 在不支持 DS 的域中不具备 DS 能力的域中的流量源或中间节点可以使用流量调节器在流量到达下游 DS 域的入口之前预先标记流量。通过这种方式，可以隐藏用于分类和标记的本地策略。2.3.4.4、 内部 DS 节点尽管基本架构假设复杂的分类和流量调节功能仅位于网络的入口和出口边界节点，但不排除在网络内部部署这些功能。例如，可能在跨洋链路上实施更严格的访问策略，需要链路上游节点中的 MF 分类和流量调节功能。由于可能需要维护大量潜在的分类和调节规则，因此该方法可能具有扩展限制。2.4、 每跳行为每跳行为 (PHB) 是对应用于特定 DS 行为聚合的 DS 节点的外部可观察转发行为的描述。在这种情况下，“转发行为”是一个通用概念。例如，在只有一个行为聚合占用一条链路的情况下，可观察到的转发行为（即丢失、延迟、抖动）通常仅取决于链路的相对负载（即，如果该行为假定节约工作的调度纪律）。当多个行为聚合竞争节点上的缓冲区和带宽资源时，主要观察到有用的行为区别。PHB 是节点向行为聚合分配资源的手段，在这种基本的逐跳资源分配机制之上，可以构建有用的差异化服务。PHB 的最简单示例是保证将 X% 的链路（在某个合理的时间间隔内）分配给行为聚合的最小带宽分配。在各种竞争性流量条件下，可以相当容易地测量此 PHB。稍微复杂的 PHB 将保证链路的 X% 的最小带宽分配，并按比例公平共享任何多余的链路容量。通常，PHB 的可观察行为可能取决于对相关行为聚合的流量特征或其他行为聚合的特征的某些约束。PHB 可以根据它们相对于其他 PHB 的资源（例如，缓冲区、带宽）优先级，或者根据它们相对可观察的流量特性（例如，延迟、丢失）来指定。这些 PHB 可以作为构建块来分配资源，并应指定为一个组（PHB 组）以保持一致性。PHB 组通常会共享一个应用于组内每个 PHB 的公共约束，例如数据包调度或缓冲区管理策略。组中 PHB 之间的关系可以是绝对优先级或相对优先级（例如，通过确定性或随机阈值丢弃优先级），但这不是必需的（例如，N 个相等的链路份额）。单独定义的单个 PHB 是 PHB 组的特例。PHB 是通过一些缓冲区管理和数据包调度机制在节点中实现的。PHB 是根据与服务提供策略相关的行为特征来定义的，而不是根据特定的实现机制来定义的。通常，多种实现机制可能适合于实现特定的 PHB 组。此外，一个节点上可能会实现一个以上的 PHB 组并在一个域内使用。应该定义 PHB 组，以便可以推断出组之间的适当资源分配，并且可以实施可以同时支持两个或更多组的集成机制。PHB 组定义应指出可能与先前记录的 PHB 组发生冲突，这可能会阻止同时操作。如[DSFIELD]中所述，通过接收数据包中DS码点的映射，在节点处选择PHB。标准化的 PHB 有一个推荐的代码点。但是，代码点的总空间大于可用于标准化 PHB 的推荐代码点的空间，并且 [DSFIELD] 为本地可配置映射留下了规定。一个代码点->PHB 映射表可能包含 1->1 和 N->1 映射。所有的代码点都必须映射到某个 PHB；在缺少某些本地策略的情况下，未根据 PHB 规范映射到标准化 PHB 的代码点应映射到默认 PHB。2.5、 网络资源分配DS 域节点中支持的 PHB 组的实现、配置、操作和管理应根据域的服务提供策略有效地划分这些节点的资源和行为聚合之间的节点间链路。流量调节器可以通过执行 TCA 以及可能通过来自域中节点和流量调节器的操作反馈来进一步控制这些资源的使用。尽管可以在没有复杂流量调节功能的情况下部署一系列服务（例如，仅使用静态标记策略），但诸如监管、整形和动态重新标记等功能可以部署提供定量性能指标的服务。流量调节器和内部节点之间的配置和交互应由域的管理控制进行管理，并且可能需要通过协议和控制实体进行操作控制。有多种可能的控制模型。这些组件之间交互的确切性质和实现超出了该架构的范围。然而，可扩展性要求域的控制不需要网络资源的微观管理。最具可扩展性的控制模型将在操作时间范围内以开环方式操作节点，并且只需要管理时间尺度管理，因为 SLA 是变化的。这个简单的模型在某些情况下可能不合适，并且可能需要一些自动化但缓慢变化的操作控制（分钟而不是秒）来平衡网络的利用率与最近的负载配置文件。3、 每跳行为规范指南[DSFIELD] 中给出了每跳行为标准化的基本要求。本节通过描述 PHB（组）规范的附加指南来详细说明该文本。这是为了帮助促进实施的一致性。在建议 PHB 组进行标准化之前，它应该适当地满足这些准则，以保持该体系结构的完整性。G.1：PHB 标准必须指定从为标准映射[DSFIELD] 保留的代码点空间中选择的推荐DS 代码点。推荐的代码点将由 IANA 分配。PHB 提议可能会从 EXP/LU 空间推荐一个临时代码点，以促进域间实验。确定数据包的 PHB 不得要求检查超出 DS 字段的附加数据包头字段。G.2： 每个新提议的 PHB 组的规范应包括行为概述和提议行为的目的。概述应包括针对 PHB 组的一个或多个问题陈述。概述应包括 PHB 组背后的基本概念。这些概念应该包括但不限于排队行为、丢弃行为和输出链路选择行为。最后，概述应指定 PHB 组解决问题陈述中指定的一个或多个问题的方法。G.3： PHB 组规范应指明指定的单个 PHB 的数量。如果指定了多个 PHB，则应明确指定这些 PHB 之间的交互以及组内所有 PHB 必须全局遵守的约束。例如，规范必须指出如果微流中的不同数据包被标记为组内不同的 PHB，则该微流中的数据包重新排序的概率是否会增加。G.4： 当 PHB 组的正常功能依赖于诸如供应限制之类的约束时，那么 PHB 定义应描述违反这些约束时的行为。此外，如果违反这些约束时需要进行丢包或重新标记等操作，则应具体规定这些操作。G.5： 可以指定一个 PHB 组供域内的本地使用，以提供某些特定于域的功能或特定于域的服务。在这种情况下，PHB 规范可用于为供应商提供 PHB 组的一致定义。但是，任何为本地使用而定义的 PHB 组都不应该考虑标准化，但可以作为信息 RFC 发布。相比之下，用于一般用途的 PHB 组将遵循更严格的标准化过程。因此，所有 PHB 提案都应明确说明是考虑将其用于一般用途还是本地用途。众所周知，可以设计 PHB 组以提供主机到主机、WAN 边缘到 WAN 边缘和/或域边缘到域边缘服务。为保持一致性，在 PHB 定义中使用术语“端到端”应解释为“主机到主机”。出于实验或操作目的，可以在域内本地定义和部署其他 PHB 组。没有要求必须公开记录这些 PHB 组，但它们应该使用来自 [DSFIELD] 中定义的 EXP/LU 池之一的 DS 代码点。G.6： 为一个PHB组内的一个PHB标记的数据包被重新标记以选择该组内的另一个PHB是可能的或合适的；在域内或跨域边界。进行此类 PHB 修改通常有以下三个原因：A. 与 PHB 组关联的代码点共同用于承载有关网络的状态，B. 存在需要 PHB 提升或降级数据包的条件（假设组内的 PHB 可以按某种顺序排列），C. SLA 不涵盖两个域之间的边界。在这种情况下，跨越边界链路时选择的代码点/PHB 将由上游域的本地策略确定。PHB 规范应该清楚地说明为 PHB 组内的 PHB 标记的数据包可以或应该修改（例如，提升或降级）为组内的另一个 PHB 的情况。如果不希望修改数据包的 PHB，则规范应明确说明修改 PHB 时的后续风险。无论是在 PHB 组内还是在 PHB 组外，更改数据包的 PHB 的可能风险是在微流内进行数据包重新排序的可能性更高。组内的 PHB 可能携带一些主机到主机、WAN 边缘到 WAN 边缘和/或域边缘到域边缘语义，如果数据包被重新标记为从组中选择另一个 PHB，这些语义可能难以复制（或其他）。对于某些 PHB 组，通过重新标记数据包以指定组内的另一个 PHB 来反映节点中的状态变化可能是合适的。如果 PHB 组旨在反映网络状态，则 PHB 定义必须充分描述 PHB 与其反映的状态之间的关系。此外，如果这些 PHB 限制了节点可以以某种方式执行的转发操作，则这些约束可以指定为节点应该或必须执行的操作。G.7： PHB 组规范应包括定义隧道对 PHB 组效用的影响的部分。当内部报头的原始 DS 字段封装在隧道中时，本节应指定新创建的外部报头的 PHB 组的效用的含义。本节还应该讨论当来自内部报头和外部报头的代码点都可以访问时，应该对隧道出口处的内部报头应用哪些可能的更改（参见第 6.2 节）。G.8： 指定 PHB 组的过程在本质上可能是渐进的。当提出新的 PHB 组时，应记录它们与先前指定的 PHB 组的已知相互作用。创建新的 PHB 组时，它的范围可以是全新的，也可以是现有 PHB 组的扩展。如果 PHB 组完全独立于部分或全部现有 PHB 规范，则应在 PHB 规范中包含一个部分，详细说明新的 PHB 组如何与那些已经标准化的 PHB 组共存。例如，本节可能指示在微流内对由与两个独立 PHB 组关联的代码点标记的数据包进行数据包重新排序的可能性。如果同一节点中两个（或多个）不同 PHB 组的并发操作是不可能的或有害的，则应说明这一点。如果两个（或多个）不同PHB 组的并发操作需要节点在同时处理来自这些不同PHB 组的标记为PHB 的数据包时节点的某些特定行为，则应说明这些行为。应注意避免 PHB 组定义的循环。如果提议的 PHB 组是现有 PHB 组的扩展，则应在 PHB 组规范中包含一个部分，详细说明此扩展如何与正在扩展的行为进行互操作。此外，如果扩展以某种方式改变或更狭义地定义了现有行为，也应明确指出。G.9： 每个 PHB 规范应包括一个部分，指定 PHB 组实现的最低一致性要求。本一致性部分旨在提供一种方法来指定行为的细节，同时允许在 PHB 规范允许的范围内进行实现变化。该一致性部分可以采用规则、表格、伪代码或测试的形式。G.10： PHB 规范应包括详细说明行为安全含义的部分。本节应讨论在隧道出口处重新标记内部报头的代码点及其对所需转发行为的影响。此外，本节还应讨论如何将提议的 PHB 组用于拒绝服务攻击、减少服务合同攻击和违反服务合同攻击。最后，本节应讨论检测此类攻击的可能方法，因为它们与提议的行为相关。G.11： PHB 规范应包括详细说明可能影响 PHB 操作和可能影响可能使用 PHB 的候选服务的配置和管理问题的部分。G.12： 强烈建议为每个 PHB 规范提供一个附录，以考虑提议的行为对当前和潜在服务的影响。这些服务可能包括但不限于用户特定、设备特定、域特定或端到端服务。还强烈建议附录包含一个部分，描述用户、设备和/或域如何验证服务。G.13： 建议针对域内本地使用的每个 PHB 规范提供一个附录，为转发到不支持 PHB 组的对等域的数据包选择 PHB 提供指导。G.14： 建议为每个 PHB 规范提供一个附录，以考虑提议的 PHB 组对现有高层协议的影响。在某些情况下，PHB 可能允许对高层协议进行可能的更改，这可能会增加或减少提议的 PHB 组的效用。G.15： 建议为每个 PHB 规范提供一个附录，该附录推荐到链路层 QoS 机制的映射，以支持 PHB 跨共享媒体或交换链路层的预期行为。确定 PHB 和链路层 QoS 机制之间最合适的映射取决于许多因素，超出了本文档的范围；然而，规范应该尝试提供一些指导。4、 与非差异化服务兼容节点的互操作性我们将非差异化服务兼容节点（非 DS 兼容节点）定义为不解释 [DSFIELD] 中指定的 DS 字段和/或不实现部分或全部标准化 PHB（或那些在特定 DS 域中使用）。这可能是由于节点的功能或配置所致。我们将遗留节点定义为非 DS 兼容节点的特例，该节点实现了 [RFC791，RFC1812] 中定义的 IPv4 优先级分类和转发，但在其他方面不符合 DS。IPv4 TOS 八位字节中的优先级值有意与 [DSFIELD] 中定义的类选择器代码点兼容，并且 [RFC791，RFC1812] 中定义的优先转发行为符合也在 [DSFIELD] 中定义的类选择器 PHB 要求。传统节点和符合 DS 的节点之间的一个关键区别在于，传统节点可能会也可能不会解释 [RFC1349] 中定义的 TOS 八位字节的第 3-6 位（“DTRC”位）；实际上，它不会按照 [DSFIELD] 中的规定解释这些位。我们假设不推荐使用 [RFC1349] 中定义的 TOS 标记。对于非零 DS 代码点的数据包，不符合 DS 标准且不是传统节点的节点可能会表现出不可预测的转发行为。差异化服务依赖于节点中每跳行为实现提供的资源分配机制。如果流量通过不兼容 DS 的节点或不支持 DS 的域，服务的质量或统计保证级别可能会崩溃。我们将研究两个不同的案例。第一种情况涉及在 DS 域内使用不符合 DS 的节点。请注意，PHB 转发主要用于以受控方式分配稀缺节点和链路资源。在高速、轻负载链路上，最坏情况的数据包延迟、抖动和丢失可以忽略不计，并且在此类链路的上游端使用不符合 DS 标准的节点可能不会导致服务降级。在更现实的情况下，节点中缺少 PHB 转发可能会导致无法跨节点的路径提供低延迟、低损耗或预配置的带宽服务。然而，使用遗留节点可能是一个可接受的替代方案，假设 DS 域将自身限制为仅使用 [DSFIELD] 中定义的类选择器代码点，并假设遗留节点中的特定优先级实现提供兼容的转发行为沿着穿过该节点的路径提供服务。请注意，将使用的代码点限制为类选择器代码点很重要，因为遗留节点可能会或可能不会根据 [RFC1349] 解释第 3-5 位，从而导致不可预测的转发结果。第二种情况涉及遍历不支持 DS 的域的服务的行为。为了论证起见，我们假设不具备 DS 能力的域不会在域边界节点上部署流量调节功能；因此，即使域由传统的或符合 DS 的内部节点组成，边界上缺乏流量执行也会限制跨域一致地提供某些类型服务的能力。DS 域和不支持 DS 的域可以协商一个协议，该协议管理在进入不支持 DS 的域之前应如何标记来自 DS 域的出口流量。可以通过流量采样而不是严格的流量调节来监控该协议的合规性。或者，如果知道不具备 DS 能力的域由传统节点组成，上游 DS 域可以机会性地将差异化服务流量重新标记为一个或多个类选择器代码点。如果不知道下游域的流量管理能力，并且没有适当的协议，DS 域出口节点可以选择将 DS 代码点重新标记为零，假设不具备 DS 能力的域将处理流量统一，尽力服务。如果不支持 DS 的域与 DS 域对等，则应根据适当的 SLA 或策略在 DS 域的 DS 入口节点处调节来自不支持 DS 的域的流量。5、 组播注意事项通过组播流量使用差异化服务引入了许多服务供应问题。首先，由于组播数据包复制，在入口节点进入DS域的组播数据包可能同时采取多条路径通过域的某些段。通过这种方式，它们比单播数据包消耗更多的网络资源。在组播组成员资格是动态的情况下，很难预先预测源自特定组的上游网络的组播流量可能消耗的网络资源量。这种不确定性的结果是可能难以向组播发送方提供定量服务保证。此外，可能需要为单播流量保留代码点和 PHB，以提供与组播流量的资源隔离。第二个问题是为到达 DS 入口节点的组播数据包选择 DS 代码点。因为该数据包可能在与多个下游域对等的多个 DS 出口节点处退出 DS 域，所以使用的 DS 代码点不应导致来自下游 DS 域的违反对等 SLA 的服务请求。当在 DS 入口节点为接收跨越域出口边界的差异化服务的流量集合建立分类器和流量调节器状态时，可以考虑相邻下游中转域的身份和相应对等 SLA 的细节进入配置决策（取决于路由策略和路由基础设施的稳定性）。通过这种方式，可以在上游域的入口部分实施与下游 DS 域的对等 SLA，从而减少上游域出口节点的分类和流量调节负担。由于动态组成员身份的可能性，这在组播流量的情况下不太容易执行。结果是单播流量的服务保证可能会受到影响。解决这个问题的一种方法是为组播流量建立一个单独的对等 SLA，或者为组播数据包使用一组特定的代码点，或者在 DS 出口节点中实施必要的分类和流量调节机制，以提供优先隔离与下游域的对等 SLA 一致的单播流量。6、 安全和隧道注意事项本节解决因引入差异化服务而引起的安全问题，主要是拒绝服务攻击的可能性，以及未经授权的流量窃取服务的相关可能性（第 6.1 节）。此外，还讨论了存在 IPsec 时差异化服务的运行及其与 IPsec 的交互（第 6.2 节），以及审计要求（第 6.3 节）。本节考虑使用 IPsec 和非 IPsec 隧道引入的问题。6.1、 盗窃和拒绝服务差异化服务的主要目标是允许为公共网络基础设施上的流量流提供不同级别的服务。可以使用多种资源管理技术来实现这一点，但最终结果将是某些数据包接收到与其他数据包不同（例如，更好）的服务。网络流量到导致不同（例如，更好或更差）服务的特定行为的映射主要由 DS 字段指示，因此攻击者可能能够通过将 DS 字段修改为指示所使用行为的代码点来获得更好的服务用于增强服务或通过将 DS 字段设置为此类代码点的数据包注入。考虑到其极限，当修改或注入的流量耗尽可用于转发它和其他流量流的资源时，这种服务盗窃就变成了拒绝服务攻击。防御此类盗窃和拒绝服务攻击包括将 DS 边界节点的流量调节与 DS 域内网络基础设施的安全性和完整性相结合。如第 2 节所述。2、DS入口节点必须调节进入DS域的所有流量，以确保它具有可接受的DS代码点。这意味着代码点必须符合适用的 TCA 和域的服务供应策略。因此，入口节点是防御基于修改后的 DS 代码点（例如，流量无权访问的代码点）的盗窃和拒绝服务攻击的主要防线，因为任何此类攻击的成功都构成了违反适用的 TCA 和/或服务提供策略。入口节点的一个重要实例是 DS 域中的任何流量发起节点都是该流量的入口节点，并且必须确保所有发起的流量都携带可接受的 DS 代码点。域的服务提供策略和 TCA 都可能要求入口节点更改某些进入数据包的 DS 代码点（例如，入口路由器可以根据适当的 SLA 设置客户流量的 DS 代码点）。入口节点必须调节所有其他入站流量以确保 DS 代码点是可接受的；发现具有不可接受代码点的数据包必须被丢弃或必须在转发之前将其 DS 代码点修改为可接受的值。例如，从不存在增强服务协议的域接收流量的入口节点可能会将 DS 代码点重置为默认 PHB 代码点 [DSFIELD]。可能需要流量身份验证来验证某些 DS 代码点（例如，对应于增强服务的代码点）的使用，并且此类身份验证可以通过技术手段（例如 IPsec）和/或非技术手段（例如，入站链路已知连接到一个客户站点）。通过使上游域部分或完全负责确保流量具有下游域可接受的 DS 代码点，域间协议可以减少或消除对入口节点流量调节的需要。在这种情况下，入口节点仍然可以执行冗余流量调节检查以减少对上游域的依赖（例如，此类检查可以防止盗窃服务攻击跨域边界传播）。如果由于上游域未履行其职责而导致此类检查失败，则该失败是可审计事件；生成的审计日志条目应包括接收数据包的日期/时间、源和目标 IP 地址以及导致失败的 DS 代码点。在实践中，在确定在这些情况下执行哪些检查（如果有）时，需要权衡此类检查的有限收益与其潜在的性能影响。DS 域中的内部节点可以依靠 DS 字段将差异化服务流量与用于实现增强服务的行为相关联。这样做的任何节点都依赖于 DS 域的正确操作，以防止带有不可接受的 DS 代码点的流量到达。健壮性问题要求具有不可接受的 DS 代码点的数据包的到达不得导致网络节点的故障（例如，崩溃）。内部节点不负责执行服务供应策略（或单个 SLA），因此在使用它们之前不需要检查 DS 代码点。内部节点可以对 DS 代码点执行一些流量调节检查（例如，检查从未用于特定链路上的流量的 DS 代码点）以提高安全性和鲁棒性（例如，对基于 DS 代码点修改的服务盗窃攻击的抵抗力）。任何检测到的此类检查失败都是可审核事件，生成的审核日志条目应包括接收数据包的日期/时间、源和目标 IP 地址以及导致失败的 DS 代码点。在实践中，在确定要在内部节点执行哪些检查（如果有）时，需要权衡此类检查的有限收益与其潜在的性能影响。任何不能充分保护 DS 代码点修改或攻击者注入流量的链路都应被视为边界链路（因此，该链路上的任何到达流量都被视为在入口节点进入域）。本地安全策略提供了“充分安全”的定义，并且这样的定义可能包括确定 DS 代码点修改和/或流量注入的风险和后果不能证明任何额外的链路安全措施是合理的。可以通过物理访问控制和/或软件手段（例如确保数据包完整性的隧道）来增强链路安全性。6.2、 IPsec 和隧道交互[ESP, AH] 中定义的 IPsec 协议在其任何加密计算中都不包括 IP 标头的 DS 字段（在隧道模式的情况下，不包括外部 IP 标头的 DS 字段）。因此，网络节点修改 DS 字段对 IPsec 的端到端安全没有影响，因为它不会导致任何 IPsec 完整性检查失败。因此，IPsec 不会针对攻击者修改 DS 字段（即中间人攻击）提供任何防御，因为攻击者的修改也不会对 IPsec 的端到端安全产生影响。在某些环境中，在不影响 IPsec 完整性检查的情况下修改 DS 字段的能力可能构成隐蔽通道；如果需要消除这样的通道或减少其带宽，则应配置 DS 域，以便可以在流量退出的 DS 出口节点执行所需的处理（例如，将敏感流量上的所有 DS 字段设置为单个值）更高的安全域。IPsec 的隧道模式为封装的 IP 报头的 DS 字段提供安全性。隧道模式 IPsec 数据包包含两个 IP 标头：由隧道入口节点提供的外部标头和由数据包的原始源提供的封装内部标头。当 IPsec 隧道（全部或部分）托管在差异化服务网络上时，中间网络节点对外部报头中的 DS 字段进行操作。在隧道出口节点，IPsec 处理包括剥离外部报头并使用内部报头转发数据包（如果需要）。如果隧道出口节点的DS域的DS入口节点没有处理内部IP头，则隧道出口节点是隧道出口流量的DS入口节点，因此必须执行相应的流量调节职责（参见Sec . 6.1)。如果 IPsec 处理包括对封装数据包的足够强的加密完整性检查（其中充分性由本地安全策略确定），则隧道出口节点可以安全地假设内部报头中的 DS 字段与它在隧道入口节点。这允许与隧道入口节点在同一 DS 域中的隧道出口节点安全地处理通过这种完整性检查的数据包，就好像它是从同一 DS 域内的另一个节点到达一样，省略了 DS 入口节点流量调节否则需要。一个重要的结果是，DS 域内部的不安全链路可以通过足够强大的 IPsec 隧道来保护。这种分析及其含义适用于任何执行完整性检查的隧道协议，但内部报头的 DS 字段的保证级别取决于隧道协议执行的完整性检查的强度。如果隧道可以通过当前 DS 域外的节点（或易受攻击），如果没有足够的保证，则必须将封装的数据包视为从域外到达 DS 入口节点。IPsec协议目前要求隧道出口节点的IPsec解封装处理不能改变内部报头的DS字段。这确保了对手对 DS 字段的修改不能用于跨 IPsec 隧道端点发起盗窃或拒绝服务攻击，因为任何此类修改都将在隧道端点被丢弃。本文档不更改该 IPsec 要求。如果将来修改IPsec规范，允许隧道出口节点根据外层头中的DS字段值修改内层IP头中的DS字段（例如，将部分或全部外层DS字段复制到内层DS 字段），则需要额外考虑。对于完全包含在单个 DS 域内且链路已充分保护以防止外部 DS 字段修改的隧道，对内部 DS 字段修改的唯一限制将是域的服务供应策略所施加的限制。否则，执行此类修改的隧道出口节点将充当离开隧道的流量的 DS 入口节点，并且必须执行入口节点的流量调节职责，包括防御盗窃和拒绝服务攻击（参见 Sec . 6.1)。如果隧道在不同于隧道出口节点的节点进入DS域，则隧道出口节点可以依赖于上游DS入口节点已经确保外部DS字段值是可接受的。即使在这种情况下，也有一些检查只能由隧道出口节点执行（例如，加密隧道的内部和外部 DS 代码点之间的一致性检查）。任何检测到的此类检查失败都是可审计事件，生成的审计日志条目应包括接收数据包的日期/时间、源和目标 IP 地址以及不可接受的 DS 代码点。从架构的角度来看，至少可以通过两种不同的方式来看待 IPsec 隧道。如果将隧道视为逻辑单跳“虚拟线路”，则转发隧道流量的中间节点的操作不应在隧道末端之外可见，因此不应在解封装过程中修改 DS 字段。相反，如果隧道被视为转发流量的多跳参与者，则可能需要修改 DS 字段作为隧道解封装处理的一部分。当隧道终止于域管理员不希望部署流量调节逻辑（例如，为了简化流量管理）的 DS 域的内部节点时，后一种情况的特定示例发生。这可以通过使用外部 IP 报头中的 DS 代码点（受 DS 入口节点的流量调节）来重置内部 IP 报头中的 DS 代码点来支持，有效地将 DS 入口流量调节责任从 IPsec 隧道出口转移节点到适当的上游 DS 入口节点（必须已经为未封装的流量执行该功能）。6.3、 审计并非所有支持差异化服务的系统都会实施审计。但是，如果将差异化服务支持合并到支持审计的系统中，那么差异化服务实现也应该支持审计。如果存在此类支持，则实施必须允许系统管理员从整体上启用或禁用对差异化服务的审计，并且可以允许部分启用或禁用此类审计。在大多数情况下，审计的粒度是局部问题。但是，本文档中确定了几个可审计的事件，并且为这些事件中的每一个定义了应包含在审计日志中的最小信息集。附加信息（例如，与触发可审计事件的信息包相关的数据包）也可以包含在这些事件中的每一个的审计日志中，并且本规范中没有明确指出的附加事件也可能导致审计日志条目。接收方不需要向声称的发送方传输任何消息以响应检测到可审计事件，因为此类行为可能导致拒绝服务。7、 致谢本文档得益于 Steven Blake、David Clark、Ed Ellesson、Paul Ferguson、Juha Heinanen、Van Jacobson、Kalevi Kilkki、Kathleen Nichols、Walter Weiss、John Wroclawski 和 Lixia Zhang 的早期草稿。作者感谢以下人士的有益评论和建议：Kathleen Nichols、Brian Carpenter、Konstantinos Dovrolis、Shivkumar Kalyana、Wu-chang Feng、Marty Borden、Yoram Bernet、Ronald Bonica、James Binder、Borje Ohlman、Alessio Casati、Scott Brim、Curtis Villamizar、Hamid Ould-Brahi、Andrew Smith、John Renwick、Werner Almesberger、Alan O'Neill、James Fu 和 Bob Braden。8、 参考文献[802.1p] ISO/IEC Final CD 15802-3 Information technology - Telecommunications and information exchange between systems -Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15). [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>, ATM Forum, April 1996. [Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. Nichols, and M. Speer, "A Framework for Use of RSVP with Diff-serv Networks", Work in Progress. [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp. 362-373. [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990. [RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992. [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, July 1994. [RFC1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997. [TR] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5-1995), 1995.完整的版权声明版权所有 (C) 互联网协会 (1998)。版权所有。本文件及其译文可能会被复制和提供给他人，并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文档本身，例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用，除非出于制定 Internet 标准的需要，在这种情况下，版权程序定义在必须遵循 Internet 标准流程，或按照要求将其翻译成英语以外的语言。上述授予的有限权限是永久性的，不会被互联网协会或其继任者或受让人撤销。本文档和其中包含的信息按“原样”提供，互联网协会和互联网工程工作队不提供所有明示或暗示的保证，包括但不限于任何保证，即使用此处的信息不会侵犯任何有关适销性或特定用途适用性的权利或任何默示保证。
-
发表了文章 2023-03-04
CHAP：PPP 质询握手认证协议
RFC1994：PPP Challenge Handshake Authentication Protocol (CHAP)，August 1996本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。梗概点对点协议 (Point-to-Point Protocol，PPP) [1] 提供了一种通过点对点链路传输多协议数据报的标准方法。PPP 还定义了一个可扩展的链路控制协议，它允许在允许网络层协议在链路上传输之前协商用于验证其对等体的身份验证协议。本文档定义了一种使用 PPP 进行身份验证的方法，该方法使用随机质询，并具有依赖于质询和密钥的加密散列响应。1、 介绍为了在点对点链路上建立通信，PPP 链路的每一端必须首先在链路建立阶段发送 LCP 数据包来配置数据链路。链路建立后，PPP 在进入网络层协议阶段之前提供一个可选的身份验证阶段。默认情况下，身份验证不是强制性的。如果需要对链路进行身份验证，则实现必须在链路建立阶段指定身份验证协议配置选项。这些身份验证协议主要供通过交换电路或拨号线路连接到 PPP 网络服务器的主机和路由器使用，但也可应用于专用链路。服务器可以在网络层协商的选项选择中使用连接主机或路由器的标识。本文档定义了 PPP 认证协议。链路建立和身份验证阶段以及身份验证协议配置选项在点对点协议 (PPP) [1] 中定义。1.1、 需求说明在本文档中，使用了几个词来表示规范的要求。这些词通常大写。MUST/必须这个词，或形容词“必须”，意味着定义是规范的绝对要求。MUST NOT/一定不这句话的意思是定义是对规范的绝对禁止。SHOULD/应该这个词，或者形容词“recommended/推荐”，意味着在特定情况下可能存在合理的理由忽略这个项目，但在选择不同的词语之前必须理解并仔细权衡全部含义。MAY/可以这个词，或者形容词“optional/可选”，意味着这个项目是一组允许的替代品之一。不包含该选项的实现必须准备好与包含该选项的另一个实现互操作。1.2、 术语本文档经常使用以下术语：authenticator/验证器需要身份验证的链路的末尾。身份验证器指定要在链路建立阶段的配置请求中使用的身份验证协议。peer/对等体点对点链路的另一端；验证器正在验证的端。silently discard/默默地丢弃这意味着实现会丢弃数据包而不进行进一步处理。实现应该提供记录错误的能力，包括静默丢弃数据包的内容，并且应该在统计计数器中记录事件。2、 质询握手认证协议质询握手身份验证协议 (Challenge-Handshake Authentication Protocol，CHAP) 用于使用 3 次握手定期验证对等体的身份。这是在初始链路建立时完成的，并且可以在链路建立后的任何时候重复。1. 链路建立阶段完成后，认证方向对端发送“质询”消息。2. 对等体点以使用“单向散列”函数计算的值进行响应。3. 验证器根据它自己对预期散列值的计算来检查响应。如果值匹配，则确认身份验证；否则连接应该被终止。4. 鉴权者以随机间隔向对等体发送新的质询，并重复步骤 1 至 3。2.1、 好处CHAP 通过使用增量变化的标识符和可变的质询值来防止对等体端的回放攻击。重复质询的使用旨在限制暴露于任何单一攻击的时间。验证者控制质询的频率和时间。这种身份验证方法取决于只有身份验证者和该对等体知道的“密钥”。密钥不是通过链路发送的。尽管身份验证只是单向的，但通过在两个方向上协商 CHAP，相同的密钥集可以很容易地用于相互身份验证。由于 CHAP 可用于验证许多不同的系统，因此名称字段可用作索引以在大型密钥表中定位正确的密钥。这也使得每个系统支持多个名称/密钥对成为可能，并且可以在会话期间随时更改正在使用的密钥。2.2、 缺点CHAP 要求密钥以明文形式提供。无法使用通常可用的不可逆转的加密密码数据库。对于大型部署，它不是那么有用，因为每个可能的密钥都保存在链路的两端。实施注意事项：为了避免通过网络中的其他链路发送密钥，建议在中央服务器而不是每个网络访问服务器上检查质询和响应值。否则，密钥应该以可逆加密的形式发送到这些服务器。这两种情况都需要信任关系，这超出了本规范的范围。2.3、 设计要求CHAP 算法要求密钥的长度必须至少为 1 个八位字节。密钥应该至少与精心选择的密码一样大且不可猜测。优选地，密钥至少是所选散列算法的散列值的长度（MD5为16个八位字节）。这是为了确保密钥有足够大的范围以提供针对穷举搜索攻击的保护。选择单向散列算法使得从已知的质询和响应值确定密钥在计算上是不可行的。每个质询值应该是唯一的，因为重复质询值与相同的密钥将允许攻击者用先前截获的响应进行回复。由于预期相同的密钥可以用于与不同地理区域的服务器进行身份验证，因此质询应该表现出全局和时间唯一性。每个质询值也应该是不可预测的，至少攻击者会诱使对等体点响应预测的未来质询，然后使用响应伪装成验证器的对等体点。尽管 CHAP 等协议无法抵御实时主动窃听攻击，但生成独特的不可预测的质询可以抵御范围广泛的主动攻击。Magic-Number 配置选项 [1] 中包含了对唯一性来源和发散概率的讨论。3、 配置选项格式下面显示了用于协商质询握手身份验证协议的身份验证协议配置选项格式的摘要。字段从左到右传输。Type：类型，3Length：长度，5Authentication-Protocol：认证协议，c223（十六进制）用于质询握手认证协议。Algorithm：算法，Algorithm 字段是一个八位字节，指示要使用的身份验证方法。最新值在最近的“指定数字”[2] 中指定。需要填充一个值：5 使用MD5的CHAP [3]4、 数据包格式PPP 数据链路层帧的信息字段中封装了一个Challenge-Handshake Authentication Protocol 数据包，其中协议字段指示类型为hex c223（Challenge-Handshake Authentication Protocol）。CHAP 数据包格式的摘要如下所示。字段从左到右传输。Code：代码，Code 字段是一个八位字节，用于标识 CHAP 数据包的类型。CHAP 代码分配如下：1 Challenge ，质询 2 Response ，回应 3 Success ，成功 4 Failure ，失败Identifier：标识符，标识符字段是一个八位字节，有助于匹配质询、响应和回复。Length：长度，Length 字段是两个八位字节，指示 CHAP 数据包的长度，包括 Code、Identifier、Length 和 Data 字段。长度字段范围之外的八位字节应被视为数据链路层填充并且在接收时应被忽略。Data：数据，数据字段是零个或多个八位字节。数据字段的格式由代码字段决定。4.1、 质询与回应Challenge 数据包用于开始 Challenge-Handshake 身份验证协议。认证者必须发送一个代码字段设置为 1（质询）的 CHAP 数据包。必须发送额外的质询数据包，直到收到有效的响应数据包，或者可选的重试计数器到期。质询包也可以在网络层协议阶段的任何时间传输，以确保连接没有被改变。在认证阶段和网络层协议阶段，对等体应该期待质询数据包。每当收到质询包时，对等体必须发送一个 CHAP 包，其代码字段设置为 2（响应）。每当接收到响应数据包时，验证器将响应值与其自己计算的期望值进行比较。基于这个比较，认证者必须发送一个成功或失败的数据包（如下所述）。实现注意事项：因为Success可能会丢失，认证器必须在完成认证阶段后的网络层协议阶段允许重复的响应数据包。为了防止发现替代名称和密钥，收到的任何具有当前质询标识符的响应数据包必须返回先前为该特定质询返回的相同回复代码（消息部分可能不同）。在任何其他阶段收到的任何响应数据包都必须被静默丢弃。当Failure 丢失，并且验证器终止链路时，LCP Terminate-Request 和Terminate-Ack 提供一个替代指示，表明验证失败。质询和响应数据包格式的摘要如下所示。字段从左到右传输。Code：代码1 为质询 2 为响应Identifier：标识符，标识符字段是一个八位字节。每次发送质询时，必须更改标识符字段。响应标识符必须从引起响应的质询的标识符字段中复制。Value-Size：值长度，该字段是一个八位字节，指示 Value 字段的长度。Value：值，Value 字段是一个或多个八位字节。首先传输最重要的八位字节。质询值是八位字节的可变流。质询值的唯一性及其与密钥的关系的重要性在上面进行了描述。每次发送质询时必须更改质询值。质询值的长度取决于用于生成八位字节的方法，并且与所使用的散列算法无关。响应值是在由标识符组成的八位字节流上计算的单向散列，后跟（连接）“密钥”，后跟（连接）质询值。响应值的长度取决于所使用的散列算法（MD5 为 16 个八位字节）。Name：名称，Name 字段是一个或多个八位字节，代表传输数据包的系统的标识。该字段的内容没有限制。例如，它可以包含 ASN.1 语法中的 ASCII 字符串或全局唯一标识符。名称不应为 NUL 或 CR/LF 终止。大小由长度字段确定。4.2、 成功与失败如果在响应中收到的值等于预期值，则实现必须发送一个 CHAP 数据包，其代码字段设置为 3（成功）。如果响应中收到的值不等于预期值，则实现必须发送一个代码字段设置为 4（失败）的 CHAP 数据包，并且应该采取措施终止链路。成功和失败数据包格式的摘要如下所示。字段从左到右传输。Code：代码3 成功 4 失败Identifier：标识符，标识符字段是一个八位字节，有助于匹配请求和回复。标识符字段必须从引起此回复的响应的标识符字段中复制。Message：信息，Message 字段是零个或多个八位字节，其内容取决于实现。它旨在供人类阅读，并且不得影响协议的操作。建议消息包含可显示的 ASCII 字符 32 到 126 十进制。扩展到其他字符集的机制是未来研究的主题。大小由长度字段确定。5、 安全注意事项安全问题是本 RFC 的主要主题。PPP 中认证协议的交互高度依赖于实现。这通过在整个文档中使用 SHOULD 来表示。例如，在认证失败时，一些实现不终止链路。相反，该实现将网络层协议中的流量类型限制为过滤的子集，这反过来又允许用户有机会更新密钥或向网络管理员发送邮件以指示问题。没有对失败的身份验证进行重试的规定。然而，LCP 状态机可以随时重新协商认证协议，从而允许新的尝试。建议任何用于验证失败的计数器在验证成功或失败链路的后续终止之前不要重置。没有要求认证是全双工的或在两个方向上使用相同的协议。在每个方向使用不同的协议是完全可以接受的。当然，这将取决于协商的具体协议。密钥不应该在两个方向上都相同。这允许攻击者重放对等体的质询，接受计算出的响应，并使用该响应进行身份验证。实际上，在每个 PPP 服务器内或与每个 PPP 服务器相关联，有一个数据库将“用户”名称与身份验证信息（“密钥”）相关联。预计不会通过多种方法对特定命名用户进行身份验证。这将使用户容易受到从一组中协商最不安全的方法（例如 PAP 而不是 CHAP）的攻击。如果使用相同的密钥，PAP 将透露该密钥，以便稍后与 CHAP 一起使用。相反，对于每个用户名，应该指示用于验证该用户名的确切方法。如果用户在不同的情况下需要使用不同的身份验证方法，那么应该使用不同的用户名，每个用户名都准确地标识一种身份验证方法。密码和其他密钥应存储在各自的末端，以便尽可能限制对其的访问。理想情况下，密钥应该只能由需要访问以执行身份验证的进程访问。密钥信息的分发机制应该限制处理（从而了解）密钥信息的实体数量。理想情况下，任何未经授权的人都不应该知道这些密钥。这种机制超出了本规范的范围。6、 致谢David Kaufman、Frank Heinrich 和 Karl Auerbach 在 1970 年代中期在为“安全”网络设计其中一个协议时使用了 SDC 的质询握手。汤姆·贝尔森 (Tom Bearson) 在 1982-83 年的时间范围内基于质询-响应概念构建了 Sytek 产品原型（“Poloneous”？）。另一个变体记录在各种 IBM SNA 手册中。Karl Auerbach 大约在 1991 年在 Telebit NetBlazer 中实现了另一个变体。Kim Toms 和 Barney Wolff 对本文档的早期版本提供了有用的评论。特别感谢 Dave Balenson、Steve Crocker、James Galvin 和 Steve Kent，他们提供了大量的解释和建议。现在，如果我们能让他们彼此同意就好了。参考[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DayDreamer, July 1994. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science and RSA Data Security, Inc., RFC 1321, April 1992.
-
发表了文章 2023-03-04
在 IP 或通用路由封装 (GRE) 中封装 MPLS
RFC4023：Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)，March 2005本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2005)。梗概MPLS 的各种应用程序使用具有多个条目的标签堆栈。在某些情况下，可以用基于 IP 的封装替换堆栈的顶部标签，从而使应用程序能够在其核心路由器中未启用 MPLS 的网络上运行。本文档规定了两种基于 IP 的封装：MPLS-in-IP 和 MPLS-in-GRE（Generic Routing Encapsulation，通用路由封装）。这些中的每一个都适用于某些情况。1、 动机在 MPLS 的许多应用中，通过 MPLS 骨干网的数据包携带具有多个标签的标签堆栈。如 [RFC3031-MPLS：多协议标签交换架构] 的 3.15 节所述，每个标签代表一个标签交换路径（Label Switched Path，LSP）。对于每个 LSP，有一个标签交换路由器 (Label Switching Router，LSR) 是“LSP 入口”，还有一个 LSR 是“LSP 出口”。如果 LSR A 和 B 分别是与数据包顶部标签对应的 LSP 的入口和出口，则 A 和 B 是与数据包的第二个标签（即紧接在顶部标签下方的标签）对应的 LSP 上的相邻 LSR .顶部标签的目的（或其中一个目的）是将数据包从 A 传送到 B，以便 B 可以根据第二个标签进一步处理数据包。从这个意义上说，顶部标签用作数据包其余部分的封装标头。在某些情况下，其他类型的封装头可以在不损失功能的情况下替换顶部标签。例如，IP 标头或通用路由封装 (GRE) 标头可以替换顶部标签。由于封装的数据包仍然是 MPLS 数据包，因此结果是 MPLS-in-IP 或 MPLS-in-GRE 封装。通过这些封装，LSP 上相邻的两个 LSR 可能被 IP 网络分隔开，即使该 IP 网络不提供 MPLS。要使用这些封装中的任何一种，封装 LSR 必须知道- 解封装 LSR 的 IP 地址，以及- 解封装的 LSR 实际上支持特定的封装。该知识可以通过手动配置或通过某种发现协议传送到封装 LSR。特别地，如果隧道被用于支持特定应用程序并且该应用程序具有设置或发现协议，则该应用程序的协议可以传达该知识。传达这些知识的方式超出了本文档的范围。2、 需求说明在本文档中，关键词“必须”、“不得”、“必需”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选” 将按照 [RFC2119-在 RFC 中用于表示需求级别的关键词] 中的描述进行解释。3、IP封装MPLS-in-IP 消息具有以下格式：IP Header/IP头该字段包含分别在 [RFC791-网络协议-INTERNET PROTOCOL] 或 [RFC2460] 中定义的 IPv4 或 IPv6 数据报头。源地址和目的地址分别设置为封装和解封装 LSR 的地址。MPLS Label Stack/MPLS 标签栈该字段包含 [RFC3032] 中定义的 MPLS 标签栈。Message Body/消息正文该字段包含一个 MPLS 消息体。IPv4 Protocol Number字段或IPv6 Next Header字段设置为137，表示MPLS单播报文。（本规范不支持将 MPLS-in-IP 封装用于 MPLS 组播数据包。）IP 报头之后是 MPLS 数据包，如 [RFC3032] 中所述。这种封装导致 MPLS 数据包通过“IP 隧道”发送。当隧道的接收端点收到一个数据包时，它通过去除 IP 头来解封装 MPLS 数据包。然后将数据包作为接收到的 MPLS 数据包进行处理，其“传入标签”[RFC3031] 是解封装数据包的最顶部标签。4、 GRE中的封装MPLS-in-GRE 封装将 MPLS 数据包封装在 GRE [RFC2784] 中。然后，数据包由 IP 标头（IPv4 或 IPv6）、GRE 标头和 MPLS 标签堆栈组成，如 [RFC3032-MPLS 标签栈编码] 中所述。GRE 报头中的协议类型字段必须设置为 MPLS 单播 (0x8847) 或组播 (0x8848) 的 Ethertype 值。这种封装导致 MPLS 数据包通过“GRE 隧道”发送。当隧道的接收端点收到数据包时，它会通过删除 IP 和 GRE 标头来解封装 MPLS 数据包。然后将数据包作为接收到的 MPLS 数据包进行处理，其“传入标签”[RFC3031] 是解封装数据包的最顶部标签。[RFC2784] 指定了可选的 GRE 校验和，[RFC2890] 指定了可选的 GRE 密钥和序列号字段。这些可选字段对于 MPLS-in-GRE 封装不是很有用。不需要序列号和校验和字段，因为在被隧道传输的本地 MPLS 数据包中没有相应的字段。解复用不需要 GRE 密钥字段，因为封装数据包的顶部 MPLS 标签用于此目的。GRE 密钥字段有时被视为一种安全功能，用作 32 位明文密码，但这是一种极其薄弱的安全形式。为了（a）促进封装/解封装过程的高速实现和（b）确保互操作性，我们要求所有实现都能够在没有这些可选字段的情况下正确运行。更准确地说，MPLS-in-GRE 解封装器的实现必须能够在没有这些可选字段的情况下正确处理数据包。它可能能够使用这些可选字段正确处理数据包。MPLS-in-GRE 封装器的实现必须能够生成没有这些可选字段的数据包。它可能有能力生成带有这些字段的数据包，但默认状态必须是生成的数据包没有这些字段。除非知道解封装器可以正确处理它们，否则封装器不得包含任何这些可选字段。传达这些知识的方法超出了本规范的范围。5、 通用程序某些过程对于 MPLS-in-IP 和 MPLS-in-GRE 封装都是通用的。在下文中，其地址出现在封装 IP 标头的 IP 源地址字段中的封装器称为“隧道头”。解封装器的地址出现在解封装 IP 标头的 IP 目标地址字段中，称为“隧道尾”。如果正在使用 IPv6（对于 MPLS-in-IPv6 或 MPLS-in-GRE-in-IPv6），[RFC2473] 的程序通常适用。5.1、 防止分片和重新组装如果 MPLS-in-IP 或 MPLS-in-GRE 数据包被分片（由于“普通”IP 分片），隧道尾部将必须在包含的 MPLS 数据包被解封装之前重新组装它。当隧道尾部是路由器时，这可能是不可取的；隧道尾部可能没有能力或资源以必要的性能水平进行重组。是否允许隧道数据包的分片必须在隧道头配置。默认值必须是数据包不被分片。只有在知道隧道尾部可以充分执行重组功能时才会更改默认值。本节其余部分规定的程序仅适用于不分片的数据包。显然，如果不将数据包分片，则隧道头在封装数据包之前不得将其分片。如果使用 IPv4，则隧道必须设置 DF 位。这可以防止隧道中的中间节点执行分片。（如果使用 IPv6，中间节点在任何情况下都不会执行分片。）隧道头应该执行路径 MTU 发现（[RFC1191-你了解MTU和TCP MSS不？] for IPv4，或 [RFC1981] for IPv6）。隧道头必须为每个隧道维护一个“隧道 MTU”；这是 (a) 管理配置值和 (b) 发现的路径 MTU 值减去封装开销中的最小值。如果隧道头接收到一个大小超过隧道 MTU 的 MPLS 数据包进行封装，则该数据包必须被丢弃。但是，静默丢弃此类数据包可能会导致严重的操作问题；数据包的发起者会注意到他的数据没有通过，但他可能没有意识到大数据包正在导致数据包丢失。因此，他可以继续发送被丢弃的数据包。路径 MTU 发现可以提供帮助（如果隧道头发回 ICMP 错误），但在隧道头处通常没有足够的可用信息来正确识别始发发送者。为了尽量减少问题，建议在实践中将 MTU 设计得足够大以避免分片。在某些情况下，隧道头接收用于封装的 IP 数据包，它首先封装在 MPLS 中，然后封装在 MPLS-in-IP 或 MPLS-in-GRE 中。如果 IP 数据包的源可以从隧道头到达，并且如果在 MPLS 中封装数据包的结果将是一个大小超过隧道 MTU 的数据包，那么隧道头应该使用的值在外面进行分片和 PMTU 发现隧道是隧道 MTU 值减去 MPLS 封装的大小。（也就是说，隧道 MTU 值减去 MPLS 封装的大小就是要在 ICMP 消息中报告的 MTU。）该数据包将不得不被丢弃，但隧道头应将丢弃的数据包的 IP 源发送到[RFC1191] 或 [RFC1981] 中指定的正确 ICMP 错误消息。5.2、 TTL 或跳数限制隧道头可以将 MPLS 标签栈中的 TTL 放入封装 IPv4 头的 TTL 字段或封装 IPv6 头的 Hop Limit 字段中。隧道尾部可以将来自封装 IPv4 报头的 TTL 或来自封装 IPv6 报头的 Hop Limit 放入 MPLS 报头的 TTL 字段中，但前提是这不会增加 MPLS 报头中的 TTL 值。是否进行此类修改以及如何进行修改的细节将取决于隧道尾部和隧道头部的配置。5.3、 差异化服务本文档中指定的过程使 LSP 能够通过 IP 或 GRE 隧道发送。[RFC2983]详细说明了在存在 IP-in-IP 隧道的情况下必须应用的许多考虑因素和程序，以正确支持差异化服务架构。这些注意事项和程序也适用于存在 MPLS-in-IP 或 MPLS-in-GRE 隧道的情况。因此，当隧道头将要发送 MPLS 数据包到 MPLS-in-IP 或 MPLS-in-GRE 隧道时，封装 IPv4 或 IPv6 头的 DS 字段的设置可以（至少部分地）由MPLS 数据包的“行为聚合”。[RFC3270] 中规定了确定 MPLS 数据包行为聚合的过程。类似地，在隧道尾部，封装的 IPv4 或 IPv6 头的 DS 字段可以用来确定封装的 MPLS 数据包的行为聚合。[RFC3270]规定了行为聚合和数据包的后续处置之间的关系。6、 适用性MPLS-in-IP 封装效率更高，在其他条件相同的情况下，它通常被认为是更可取的。但是，在某些情况下可以使用 MPLS-in-GRE 封装：- 两台路由器在 GRE 隧道上“相邻”，该隧道由于某种原因存在，超出了本文档的范围，并且这两个路由器必须通过该相邻发送 MPLS 数据包。由于通过此邻接发送的所有数据包都必须具有 GRE 封装，因此 MPLS-in-GRE 封装比替代方案更有效，即 MPLS-in-IP 封装然后封装在 GRE 中。- 实施考虑可能决定 MPLS-in-GRE 的使用。例如，某些硬件设备可能只能处理其快速路径中的 GRE 封装。7、 IANA 考虑IANA 已为 MPLS-in-IP 封装分配了 IP 协议编号 137，如第 3 节所述。以后不需要 IANA 采取任何行动。MPLS-in-GRE 封装不需要任何 IANA 操作。8、 安全考虑使用 IP 或 GRE 隧道时面临的主要安全问题是，隧道的接收端点可能会收到看似来自隧道的数据包，但实际上并未由隧道的传输端点放入隧道。 （指定的封装本身并不能使解封装器对封装器进行身份验证。）第二个问题是数据包在进入隧道和离开的时间之间有可能被改变。 （指定的封装本身并不能向解封装器保证数据包的完整性。）第三个问题是当数据包通过隧道传输时，数据包的内容可能会被看到。 （规范封装不确保隐私。）这些问题在实践中的重要性取决于其流量通过隧道发送的应用程序的安全要求。例如，如果生成数据包的应用程序不需要隐私，则隧道数据包缺乏隐私并不是一个重要问题。由于使用所描述的封装机制的不同应用程序具有不同的潜在安全要求、部署场景和性能考虑因素，因此本规范将 IPsec 支持定义为 OPTIONAL。如果实现了 IPsec，基本实现要求在 8.1 节中描述。如果未实施 IPsec，则可能必须实施和部署其他机制。这些将在第 8.2 节中讨论。8.1、 使用 IPsec 保护隧道如果使用 IPsec 保护 MPLS-in-IP 或 MPLS-in-GRE 隧道，所有这些安全问题都可以避免。如果实施了 IPsec，则本节中定义的实施要求适用。当使用 IPsec 时，隧道头和隧道尾应被视为安全关联的端点。为此，隧道头的单个IP地址将用作源IP地址，隧道尾的单个IP地址将用作目的IP地址。每个节点知道另一个节点的正确地址的方式超出了本文档的范围。如果使用控制协议来建立隧道（例如，将另一个隧道的 IP 地址通知一个隧道端点），则控制协议必须具有身份验证机制，并且必须在建立隧道时使用此机制。如果隧道是自动建立的，例如由 BGP 分发的信息，那么使用 BGP 的基于 MD5 的认证机制是令人满意的。MPLS-in-IP 或 MPLS-in-GRE 封装的数据包应被视为起源于隧道头，目的地为隧道尾；因此应该使用 IPsec 传输模式。当隧道头使用 IPsec 传输模式来保护 MPLS-in-IP 数据包时，MPLS-in-IP 数据包的 IP 报头将成为结果数据包的外部 IP 报头。后面跟着一个 IPsec 标头，后面跟着 MPLS 标签栈。IPsec 标头必须使用第 3 节中指定的 IP 协议编号将负载类型设置为 MPLS。如果 IPsec 传输模式应用于 MPLS-in-GRE 数据包，则 GRE 标头跟在 IPsec 标头之后。在隧道尾部，IPsec 出站处理恢复包含的 MPLS-in-IP/GRE 数据包。然后隧道尾部剥离封装的 IP/GRE 标头以恢复 MPLS 数据包，然后根据其标签堆栈转发该数据包。注意隧道尾和隧道头是LSP邻接，这意味着通过隧道发送的任何数据包的最顶层标签必须是由隧道尾分配给隧道头的标签。隧道尾部必须准确地知道它已分配给 IPsec 安全隧道的隧道头部的标签。该集合中的标签不得由隧道尾部分发到任何 LSP 邻接，除了 IPsec 安全隧道的隧道头。如果在没有 IPsec 封装的情况下接收 MPLS 数据包，并且它的最顶层标签在此集合中，则必须丢弃该数据包。IPsec 保护的 MPLS-in-IP 或 MPLS-in-GRE 隧道必须提供身份验证和完整性。（请注意，身份验证和完整性将应用于整个 MPLS 数据包，包括 MPLS 标签堆栈。）因此，实现必须支持 ESP will null 加密。如果源需要机密性，可以支持带加密的 ESP。如果使用 ESP，隧道尾部必须检查在给定 SA 上接收的任何数据包的源 IP 地址是否是预期的。密钥分发可以通过 IKE [RFC2409-IKE：互联网密钥交换] 手动或自动完成。必须支持手动键控。如果实现自动键控，则必须支持主模式下具有预共享密钥的 IKE。特定应用程序可能会升级此要求并请求实现自动键控。手动密钥分发比自动密钥分发简单得多，但可扩展性也较差。因此，负责隧道端点的管理员（或管理员对）必须仔细考虑哪种密钥分发方法适用于特定隧道。如果认为特定隧道需要重放保护，则应配置自动密钥分发。如果使用 MPLS-in-IP 封装，则与 SA 关联的选择器将是上述源地址和目标地址，加上第 3 节中指定的 IP 协议编号。如果需要保护多个 MPLS-in-IP在给定的一对节点之间分别建立隧道，每个隧道必须有唯一的 IP 地址对。如果使用 MPLS-in-GRE 封装，则与 SA 关联的选择器将是上述源地址和目标地址，以及代表 GRE (47) 的 IP 协议编号。如果需要分别保护给定节点对之间的多个 MPLS-in-GRE 隧道，每个隧道必须具有唯一的 IP 地址对。8.2、 在没有 IPsec 的情况下如果隧道没有使用 IPsec 进行保护，那么应该使用其他一些方法来确保只有当这些数据包被隧道头封装时，隧道尾部才对数据包进行解封装和转发。如果隧道完全位于单个管理域内，则可以使用边界地址过滤来确保具有隧道端点IP 源地址或隧道端点IP 目标地址的数据包无法从外部进入域。然而，当隧道头和隧道尾不在同一个管理域中时，这可能变得困难，如果数据包必须穿越公共互联网，基于目的地址的过滤甚至变得不可能。有时，在管理域的边界上只进行源地址过滤（而不是目标地址过滤）。如果是这种情况，除非 MPLS-in-IP 或 MPLS-in-GRE 的解封装器验证数据包的 IP 源地址，否则过滤根本不会提供有效保护。本文档不要求解封装器验证隧道数据包的 IP 源地址，但应理解，如果不这样做，则预先假定存在有效的基于目的地（或基于源和基于目的地的组合）过滤在边界。9、 致谢该规范结合了 Tom Worster、Paul Doolan、Yasuhiro Katsube、Tom K. Johnson、Andrew G. Malis 和 Rick Wilder 在 IP 中封装 MPLS 的先前工作，以及 Yakov Rekhter、Daniel Tappan 在 GRE 中封装 MPLS 的先前工作，和埃里克·罗森。目前的作者要感谢所有这些作者的贡献。许多人提出了宝贵的意见和更正，包括 Rahul Aggarwal、Scott Bradner、Alex Conta、Mark Duffy、Francois Le Feucheur、Allison Mankin、Thomas Narten、Pekka Savola 和 Alex Zinin。10、 规范性引用[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.11、 参考资料[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.完整的版权声明版权所有 (C) 互联网协会 (2005)。本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性保证。知识产权对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不代表它已作出任何独立努力来确定任何此类权利。可以在 BCP 78 和 BCP 79 中找到有关 RFC 文档中权利的程序的信息。可以获得向 IETF 秘书处披露的知识产权副本和任何可用许可的保证，或者可以获得本规范的实施者或用户使用此类专有权利的一般许可或许可的尝试结果来自 IETF 在线知识产权资源库 http://www.ietf.org/ipr。IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准可能需要的技术的其他专有权利。请将信息发送至 IETF ietf-ipr@ietf.org。致谢RFC 编辑器功能的资金目前由互联网协会提供。
-
发表了文章 2023-03-04
CPP：IP 连接配置文件
RFC7297：IP Connectivity Provisioning Profile (CPP)，July 2014梗概本文档描述了连接配置文件 (Connectivity Provisioning Profile，CPP) 并提出了一个 CPP 模板来捕获要在服务交付环境（例如，IP 语音或 IP 电视）内满足的 IP/MPLS 连接要求。CPP 定义了底层传输网络支持的 IP 传输参数集以及可达性范围和带宽/容量需求。适当的性能指标，例如单向延迟或单向延迟变化，用于表征 IP 传输服务。全局和受限可达性范围都可以在 CPP 中捕获。这种通用的 CPP 模板旨在：(1) 促进服务协商和激活过程的自动化，从而加速服务提供，(2) 设置流量工程功能和服务管理功能的（流量）目标，以及(3) 改进服务和具有基于协商/提供的 CPP 的“决策”能力的网络管理系统。本备忘录的状态本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。这是对 RFC 系列的贡献，独立于任何其他 RFC 流。RFC 编辑器已自行决定发布此文档，并且不对其实施或部署的价值作出任何声明。由 RFC 编辑批准发布的文件不适合任何级别的 Internet 标准；请参阅 RFC 5741 的第 2 节。有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7297。版权声明版权所有 (c) 2014 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。1、 介绍本文档描述了连接配置文件 (CPP) 并提出了一个 CPP 模板来捕获要在服务交付环境中满足的 IP/MPLS 连接要求（例如，IP 语音、IP TV 和 VPN 服务）。在本文档中，IP连接服务是一种以(Source Nets, Destination Nets, Guarantees, Scope)元组为特征的IP传输能力，其中“Source Nets”是一组单播IP地址，“Destination Nets”是一组IP地址单播和/或组播地址，“Guarantees”反映了将流量正确转发到所述“Destination”的保证（例如，以服务质量 (Quality Of Service，QoS)、性能和可用性表示）。最后，“Scope”表示需要提供所述保证的（网络）边界（例如，提供商边缘（PE）路由器或客户节点之间）。1.1、 连接供应接口 (CPI)图 1 显示了 CPP 涵盖的各种连接供应接口：客户网络 CPI、服务网络 CPI 和网络网络 CPI。其参数通过通过服务网络 CPI 交换的 CPP 捕获的服务和应用程序可以由操作底层网络的同一管理实体或由另一个实体（例如，内容提供商）提供。图 1：连接配置接口图 1 中描述的界面可以概括为图 2 所示。图 2 中所示的客户可能是另一个网络提供商（例如，IP 传输提供商）、需要调用网络提供商提供的资源的服务提供商（例如，IP 电话服务提供商），或者想要 通过订阅网络提供商提供的 VPN 服务，将其各个站点互连。提议的 CPP 可用于公开、捕获和促进这些不同实体之间服务参数的协商，从而提供用于描述可用连接服务的通用模板。图 2：CPP：通用连接配置接口在本文档的其余部分，“客户”用作通用术语，表示订阅网络提供商提供的连接服务的业务实体（参见图 2）。1.2、 基本原理知识产权服务的设计和运营程序变得越来越多样化和复杂。协商服务参数然后继续进行相应的资源分配所花费的时间因此可以以天计，甚至以周计。然而，经验表明，通常发生在客户和网络提供商之间的双边讨论从不依赖于某种标准清单，客户将被邀请勾选适用于其环境的所有参数。然后将根据可用资源、客户的期望、提供商的网络规划策略等与网络提供商协商这些参数。因此，在服务（包括第三方应用程序）和网络层之间定义清晰的接口将有助于上述讨论，从而通过优化网络基础设施的设计来改进整体服务交付过程。实际上，CPP 接口旨在以与技术无关的方式公开和表征在调用由网络提供商在一组客户节点之间运营的网络的 IP 传输能力时要满足的 IP 传输要求。（例如，多媒体网关[RFC2805] 的第 11.2.7 节，会话边界控制器 [RFC5853] 等）。这些要求包括：可达性范围（例如，有限范围、互联网范围）、方向、带宽要求、QoS 参数（例如，单向延迟 [RFC2679]、丢失 [RFC2680] 或单向延迟变化 [RFC3393]） 、保护和高可用性指南（例如，在不到 50 毫秒、100 毫秒或 1 秒内恢复）。然后将这些要求转化为与 IP/MPLS 相关的技术条款（例如，需要恢复手段、定义服务等级、需要控制平面保护等）。在稍后的阶段，这些不同的条款将通过激活适当的网络功能和特定于技术的操作（例如，多协议标签交换流量工程（Multiprotocol Label Switching Traffic Engineering，MPLS-TE，[RFC3346]）、资源预留协议（Resource Reservation Protocol，RSVP，[RFC2205]）来解决)、开放最短路径优先 (Open Shortest Path First，OSPF)、中间系统到中间系统 (Intermediate System to Intermediate System，IS-IS) 等），通过 CPP 派生的配置信息。出于流量一致性的目的，CPP 还包括参与节点在必须根据所述 CPP 定义的特定服务处理流量时遵循的流识别和分类规则。CPP 模板旨在捕捉连接需求并以标准化方式表示和评估这些需求。特定于服务和客户的 IP 配置规则可能会导致需要在网络中（预）设计的 IP 传输类的数量急剧增加。因此，为了性能和可扩展性，应避免将每个 CPP 实例化为不同的服务类别。因此，应推荐与应用程序无关的 IP 配置实践，因为 CPP 中捕获的要求可用于确定将使用哪种网络服务类别来满足这些要求/保证。从这个角度来看，CPP 概念旨在设计数量有限的通用类，以便通过捕获服务、应用程序和客户的连接要求，可以轻松地将各个 CPP 文档映射到这些类。CPP 还可用作网络提供商的网络尺寸和规划团队的指南，以确保已提供适当的资源（例如，网卡、路由器、链路容量等）。否则，（底层）传输网络将无法满足所有 CPP 请求中表达的目标。这样一个通用的 CPP 模板：** 促进服务协商和激活程序的自动化，从而缩短服务交付时间；** 可以帮助设置流量工程功能和服务管理功能目标，例如作为特定时间段内要处理的CPP模板数量的函数；和** 通过添加基于协商/提供的 CPP 的“决策”功能来改进服务和网络管理系统。此外，此 CPP 抽象明确区分了连接供应要求和需要由参与节点应用并旨在满足此类要求的相关技术特定规则。CPP 定义了由底层传输网络提供的一组 IP/MPLS 传输保证以及可达性范围和容量需求。适当的性能指标，例如单向延迟或单向延迟变化，用于表征 IP 传输服务。CPP 中还包括与可用性和弹性相关的保证。CPP 可用于集成业务环境（其中服务和网络基础设施由同一管理实体管理）或其他业务环境（其中一个管理实体管理服务而另一个管理网络基础设施）。在以下部分中，不对业务环境（集成与否）做出任何假设。可以通过调整属于不同维度的各种参数（例如，转发、路由、传入流量的处理、流量分类等）来实施网络层的服务差异化。本文档不对如何在网络基础设施中实现网络服务做出任何假设。激活单播或组播功能以提供连接服务可以由客户在 CPP 中明确请求，也可以是网络提供商基于对客户连接供应需求的分析做出的工程决策。CPP 使用的示例包括由基于应用程序的网络操作 (Application-Based Network Operations，ABNO) 框架 [NET-OPS] 引入的北向接口以及 [RFC7149] 中定义的用于公开网络服务及其特征的技术。1.3、 参考架构客户节点属于一个客户（包括企业客户）或一个服务基础设施（见图 1）。在某些情况下，客户节点可以由网络提供商提供和管理。这些客户节点之间的连接反映了由于一组 IP 资源的分配而实现的 IP 传输能力。IP 传输能力被高层服务（例如传输层和应用层服务）视为黑匣子。将（通过专用方式）向客户节点传达适当的通知和报告，以评估经验丰富的 IP 传输服务是否符合与相应 CPP 协商的内容。这些通知还可用于评估在网络基础设施中实施的各种策略的效率，以适应 CPP 中详述的要求。CPP 参考架构如图 3、4 和 5 所示。客户基础设施可以通过由一个或多个网络提供商管理的网络基础设施进行连接。图 3：参考架构：由同一网络提供商使用不同的互连节点提供的连接服务图 4：参考架构：由同一网络提供商使用单个互连节点提供的连接服务图 5：参考架构：不同网络提供商提供的连接服务2、 本文件的范围本文件详细介绍了 CPP 的条款。本文档不讨论可用于协商和执行给定 CPP 的候选协议（例如 [CPNP]）。除 CPP 条款外，客户与提供商之间的协议中还可能包含其他条款（例如，联系点、升级程序、事件管理、计费等）。详细说明所有这些附加条款超出了本文档的范围。提供了如何将 CPP 条款转化为具体政策的示例，以供说明之用。提供满足 CPP 中详述目标的技术手段的详尽清单超出了本文件的范围。CPP 主要针对 IP 连接服务而设计。然而，它可以用于其他非 IP 传输方案。评估 CPP 对这些非 IP 方案的适用性超出了本文件的范围。本文档涵盖单播和组播连接服务。任意源组播（Any-Source Multicast，ASM，[RFC1112]）和源特定组播（Source-Specific Multicast，SSM，[RFC4607]）模式都可以在 CPP 中捕获。3、 连接配置文件 (CPP)CPP 可被视为与 IP 传输服务相关的连接供应要求清单。CPP 条款在以下小节中详细说明。第 4 节提供了 CPP 模板。3.1、 客户节点图CPP 必须包括要连接到底层 IP 传输网络的客户节点（例如，客户边缘 (Customer Edges，CE)）的列表。这些节点应该被明确标识（例如，使用唯一的 Service_identifier、媒介接入控制 (Media Access Control，MAC) 地址等）。对于每个客户节点，应标识边界链路或属于连接客户节点的域的节点。该子句可以指定客户节点的地理位置信息。根据客户节点的位置，应该采取适当的操作来检索相应的边界链路或“提供商节点”（例如，PE）。此操作可以是手动的或自动的。“服务站点”将位于给定的客户节点后面。可以在 CPP 中捕获站点标识符以提供托管 VPN 服务 [RFC4026]，例如 Site_identifier。一个客户节点可以连接到多个提供商节点。多个客户节点可以连接到同一个提供商节点，如图 4 所示。3.2、 范围范围条款从传入和传出流量的角度指定每个涉及的客户节点的可达性，从而产生特定的流量方向性考虑。它被定义为单向参数。这两个方向都应在 CPP 中进行描述。可达性范围指定可从给定客户站点（由一组源前缀标识）到达的一组目标前缀。全局和受限可达性范围都可以在 CPP 中捕获。全局可达性范围意味着客户站点可以到达 Internet 中的任何目的地，并且可以从任何远程主机到达。受限可达性范围意味着不允许全局可达性；从客户站点只能到达一组目的地，和/或只有一组源可以到达客户站点。CPP 中指定了传入和传出可达性范围。可以指定 IPv4 和 IPv6 可达性范围。可达性范围条款可以包括组播和/或单播地址。对于SSM，除了目的组播地址外，还可以指定一组单播源地址。范围子句还可用于界定拓扑（或地理）网络部分，超出该部分性能和可用性保证不适用。范围可以由一组“入口”点和“出口”点来定义。可以考虑几种类型，例如：(1) “1:1”管道模型。只允许点对点通信。(2) “1:N”软管道型号。只允许从一个站点到一组目的地的通信。(3) “1:any”未指定的软管道型号。允许所有出站通信。入口和出口点可以是客户节点/提供商节点或外部节点，前提是这些节点被明确标识（例如，IPv6 前缀）或一组 IP 目的地。3.3、 服务质量保证QoS 保证表示一组 IP 传输性能指标，这些指标表征从（一组）“客户节点”发出或转发到（一组）“客户节点”的流所经历的 IP 传输处理的质量（当穿过 IP 传输基础设施时） .IP 性能指标可以表示为定性或定量参数（不能在同一个 CPP 中指定定量和定性保证）。定量保证可以指定为平均值、最大界限或测量方法中应指明的测量间隔的百分位数。已经定义了几个性能指标，例如：** 流量丢失 [RFC2680]** 单向延迟 [RFC2679]** 单向延迟变化 [RFC3393]这些参数可能特定于给定的路径或给定的范围（例如，在两个客户节点之间）。CPP 中指示的 IP 性能度量值应反映一组客户节点之间或一个客户节点与一组提供商节点之间的度量。只能为配置文件内的流量（即达到一定的流量速率）指定定量保证。CPP 可以包括吞吐量保证；在指定时，这些保证等同于数量或质量损失保证。当使用定性指标时，可以使用 Meta-QoS-Class 概念 [RFC5160]。3.4、 可用性本条款规定了商定的 IP 性能保证适用的时间百分比。该子句可以表示为最大值或平均值。子句值的确切含义是在 CPP 协商过程中定义的。保证涵盖 QoS 恶化（即 IP 传输服务可用，但低于商定的性能界限）、物理故障或服务不可用。为了满足可用性保证，可能会在客户和网络提供商之间的边界处实施多种工程实践，例如多宿主设计。提供以下机制作为示例，以表明可以选择不同的技术选项来满足服务可用性目标：** 当内部网关协议 (Interior Gateway Protocol，IGP) 实例在“客户节点”和“提供商节点”之间运行时，激活专用协议，例如双向转发检测 (Bidirectional Forwarding Detection，BFD，[RFC5881][RFC5883])，以控制 IGP可用性并确保亚秒级 IGP 邻接故障检测。** 使用标签交换路径 Ping (Label Switched Path Ping，LSP Ping) 能力检测 LSP 可用性（检查 LSP 是否就位）[RFC4379][RFC6424][RFC6425][RFC6426][RFC6829]。** 当 MPLS 网络连接客户节点 [RFC4090] 时，预安装备份 LSP 用于快速重新路由。** 启用虚拟路由器冗余协议 (Virtual Router Redundancy Protocol，VRRP, [RFC5798])。** 启用 IP 快速重新路由功能（例如，[RFC5286] 或 [RFC6981]）。3.5、 容量本节描述了由底层 IP 传输网络提供的所需容量。此容量受定义的“范围”（参见第 3.2 节）和 IP 传输性能保证（参见第 3.3 和 3.4 节）的约束。容量可以针对两个业务方向（即传入和传出）和每个边界链路表示。能力条款定义了数量保证的应用限制。由管理 IP 传输网络的管理实体决定其网络 [RFC5136] 的适当尺寸以满足所有协商的 CPP 中表达的容量要求。3.6、 一致性流量当容量信息（参见第 3.5 节）包含在 CPP 中时，还需要在 CPP 中表达对超出规范的流量处理的要求。可以应用整形/管制过滤器以评估流量是在容量配置文件内还是在配置文件外。超出规范的流量可能会被丢弃或分配另一个类别（例如，使用低工作量每域行为（Lower Effort Per-Domain Behavior，LE PDB）[RFC3662]）。分组 MTU 条件也可以在 CPP 中指示。3.7、 整体流量保障当未指定容量（第 3.5 节）和一致性流量（第 3.6 节）条款时，定义了总体流量保证。或者，如果它们确实被指定，那么超出配置文件的流量会被分配另一类服务，但不会被丢弃。这种保证只能是定性延迟和/或定性损失或吞吐量保证。如果未指定总体流量保证，则暗示了尽力而为转发。3.8、 流量隔离本节指出在穿越 IP 传输网络时，是否应该隔离由“客户节点”发出或发往“客户节点”的流量。本条款还可用于指定附加的安全保护要求（包括隐私保护要求）。然后，该条款可以转换为 VPN 策略提供信息，例如与使用 IPsec、BGP/MPLS VPN 设施 [RFC4364] 或其组合激活专用隧道有关的信息。此类功能的激活应与已协商的可用性和性能保证一致。3.9、 流量识别为了识别需要在给定 CPP 的环境中处理的流，流标识符应在 CPP 中指示。流标识符用于流量分类目的。[RFC2475]中定义了一个包分类器的例子。流标识符可以由（但不限于）以下参数组成：** 源IP地址，** 源端口号，** 目标 IP 地址，** 目标端口号，** 服务类型 (Type of Service，ToS) 或差异化服务代码点 (Differentiated Services Code Point，DSCP) 字段，** 尾端隧道端点，或** 任何组合。可以对弹性和非弹性流量实施不同的处理（例如，参见 [RFC5160] 中定义的“流量约束”条款）。流分类规则可能特定于给定的链接，也可能适用于一组或所有边界链接。这应该在 CPP 中清楚地体现出来。CPP 中可能会指明一些做法，例如 DSCP 重新标记。重新标记操作由干预以提供连接服务的底层节点负责。可以对从客户节点接收或发往客户节点的传出和传入流量强制执行重新标记。这些重新标记操作不得改变特定于服务的标记完整性（例如，VPN 服务）。该条款可以指定在出口节点对从客户节点接收的数据包实施的策略（例如，DSCP 重新标记）。如果未指定此类策略，则网络提供商对离开其管理域的数据包强制执行其本地策略（例如，清除 DSCP 标记）。3.10、 路由和转发该条款用于指定外包路由操作，例如安装专用路由以将流量传送到其（服务）目的地。可以出于流量工程或弹性目的计算、选择和安装这些专用路由。对于流量工程，这些路径可用于智能地将流量从可能遭受拥塞或避免穿越竞争对手网络的某些节点/链路转移。对于弹性，备份路径通常是预先安装的，以便绕过受保护的节点/链接。本节还用于指定必须在转发路径中调用的中间功能（例如，将流量重定向到防火墙、调用拓扑隐藏功能等）或指定地理路由限制。还可以考虑建立逻辑路由拓扑 [RFC4915] [RFC5120] 的要求，例如，以促进在 CPP 中定义的流量转发中涉及的节点的管理。这种做法应在 CPP 中指明；否则，路径计算将留给底层 IP 路由功能。转发行为（例如，每域行为（Per-Domain Behavior，PDB）[RFC3086]）也可以在 CPP 中指定，但仍然是可选的。如果指出，应仔细确保与 CPP 中定义的 IP 性能界限的一致性。出于说明目的，路由策略将避免基于 IP 语音 (Voice over IP，VoIP) 部署的卫星链路，因为这可能会降低所提供的服务。3.11、 激活方式本节指出了为激活对 IP 连接服务的访问而需要采取的行动。这些操作的示例包括激活 IGP 实例、建立 BGP [RFC4271] 或多协议 BGP (Multiprotocol BGP，MP-BGP) 会话 [RFC4760]、协议无关组播 (Protocol Independent Multicast，PIM, [RFC4601]) 等。3.12、 调用方式定义了两种类型：隐式：该子句表示不需要调用连接服务的显式方法。对连接服务的访问主要取决于请求的网络容量。显式：该条款表明需要显式方式来访问连接服务。此类手段的示例包括使用 RSVP [RFC2205]、RSVP-TE [RFC3209]、互联网组管理协议（Internet Group Management Protocol，IGMP，[RFC3376]）或组播侦听器发现（Multicast Listener Discovery，MLD，[RFC3810]）。必须执行适当的准入控制程序 [RFC6601]，例如，检查实际使用的容量是否不高于商定的阈值。3.13、 通知出于运营目的（例如，监督）和服务履行需求，需要将可能影响服务交付的关键事件通知管理平台。通知程序应在 CPP 中指明。此过程可以指定要发送的信息类型、间隔、数据模型等。可以使用简单网络管理协议（Simple Network Management Protocol，SNMP，[RFC3416]）、系统日志通知[RFC5424]、连接提供协商协议（Connectivity Provisioning Negotiation Protocol，CPNP）信号[CPNP]、网络配置协议（Network Configuration Protocol，NETCONF）事件通知[RFC5277]向管理平台发送通知]，或一个电话！4、 CPP 模板图 6 提供了 CPP 模板的 Routing Backus-Naur Form (RBNF, [RFC5511]) 格式。CPP 文档包括几个连接供应组件；每一个都被构建为一个 CPP。CPP 可能包括额外的可选信息元素，例如用于服务保证目的的度量、激活计划等。<CONNECTIVITY_PROVISIONING_DOCUMENT> ::= <Connectivity Provisioning Component> ... <Connectivity Provisioning Component>::= <CONNECTIVITY_PROVISIONING_PROFILE> ... <CONNECTIVITY_PROVISIONING_PROFILE> ::= <Customer Nodes Map> <Scope> <QoS Guarantees> <Availability> <Capacity> <Traffic Isolation> <Conformance Traffic> <Flow Identification> <Overall Traffic Guarantees> <Routing and Forwarding> <Activation Means> <Invocation Means> <Notifications> <Optional Information Element> ... <Customer Nodes Map> ::= <Customer Node> ... <Customer Node> ::= <IDENTIFIER> <LINK_IDENTIFIER> <LOCALIZATION> 图 6：CPP 模板这些条款的描述在第 3 节中提供。CPP 还可能包括客户的管理信息，例如姓名和其他联系方式。客户信息的 RBNF 格式示例如图 7 所示。<Customer Description> ::= <NAME> <Contact Information> <Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>] [<TELEPHONE_NUMBER> ...] 图 7：客户描述条款CPP 也可能包括网络提供商的管理信息（姓名、自治系统编号和其他联系方式）。提供者信息的 RBNF 格式示例如图 8 所示。<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>] <Contact Information> ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>] [<TELEPHONE_NUMBER> ...] 图 8：提供者描述条款5、 安全考虑本文档不定义架构或指定协议。然而，需要调查提供有关客户身份的保证及其通过 CPP 向网络提供商公开连接要求的能力的方法。同样，应仔细研究为网络提供商的身份和公开其能力的能力提供保证的方法，更不用说通过 CPP 捕获客户的要求了。应保护 CPP 文件免遭非法修改（例如，修改、撤回）；应启用授权手段。这些方法是特定于部署的。网络提供商必须采取措施保护 CPP 文档 [RFC6462] 中捕获的隐私相关信息。特别是，未经客户同意，不得将这些信息透露给外部各方。网络提供商应执行政策，使客户指纹识别更难实现。有关隐私的更多讨论，请参阅 [RFC6462] 和 [RFC6973]。6、 致谢本文档中的某些项目是与 E. Mykoniati 和 D. Griffin 多次讨论的结果。特别感谢他们。非常感谢 P. Georgatsos 的讨论和对本文档的详细审查。感谢 S. Shah、G. Huston、D. King 和 S. Bryant 审阅文档并提供有用的意见。7、 参考资料[CPNP] Boucadair, M., Jacquenet, C., and D. Zhang, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, June 2014. [NET-OPS] King, D. and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", Work in Progress, February 2014. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 2000. [RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008. [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, March 2008. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011. [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011. [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012. [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", RFC 6601, April 2012. [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, August 2013. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014.
-
发表了文章 2023-03-04
用于同步光网络 (SONET) 和同步数字体系 (SDH) 控制的通用多协议标签交换 (GMPLS) 扩展
RFC4606：Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control，August 2006本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2006)。梗概本文档对 RFC 3946 进行了细微的澄清。本文档是通用多协议标签交换 (Generalized Multi-protocol Label Switching，GMPLS) 信令的配套文件。它定义了使用 GMPLS 信令时所需的同步光网络 (Synchronous Optical Network，SONET)/同步数字体系 (Synchronous Digital Hierarchy，SDH) 技术特定信息。1、 介绍如 [RFC3945] 中所述，通用 MPLS (GMPLS) 从支持分组（Packet Switching Capable，或 PSC）接口和交换扩展 MPLS 以包括对四种新接口和交换类别的支持：2层交换能力 (Layer-2 Switch Capable，L2SC)、时分复用(Time-Division Multiplex，TDM)、Lambda 交换能力 (Lambda Switch Capable，LSC) 和光纤交换能力 (Fiber-Switch Capable，FSC)。[RFC3471] 中提供了支持新接口和交换类别所需的 MPLS 信令扩展的功能描述。[RFC3473] 描述了支持所有五类接口所需的 RSVP-TE 特定格式和机制，在 [RFC3472] 中可以找到 CR-LDP 扩展。本文档提供了特定于同步光网络 (SONET)/同步数字体系结构 (SDH) 的详细信息。根据 [RFC3471]，SONET/SDH 特定参数在信令协议中携带在流量参数特定对象中。本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是解释为 [RFC2119] 中的描述。此外，假设读者熟悉美国国家标准协会 (ANSI) [T1.105] 和 ITU-T [G.707] 中的术语，以及 [RFC3471]、[RFC3472] 和[RFC3473]。本文档中使用了以下缩写：DCC: Data Communications Channel，数据通信通道。LOVC: Lower-Order Virtual Container，低阶虚拟容器。HOVC: Higher-Order Virtual Container，高阶虚拟容器。MS: Multiplex Section，多路复用部分。MSOH: Multiplex Section overhead，多路复用段开销。POH: Path overhead，路径开销。RS: Regenerator Section，再生器部分。RSOH: Regenerator Section overhead，再生器段开销。SDH: Synchronous digital hierarchy，同步数字体系。SOH: Section overhead，段开销。SONET: Synchronous Optical Network，同步光网络。SPE: Synchronous Payload Envelope，同步有效载荷包络。STM(-N): Synchronous Transport Module (-N) (SDH)，同步传输模块 (-N) (SDH)。STS(-N): Synchronous Transport Signal-Level N (SONET)，同步传输信号级别 N (SONET)。VC-n: Virtual Container-n (SDH)，虚拟容器-n (SDH)。VTn: Virtual Tributary-n (SONET)，虚拟支流-n (SONET)。2、 SONET 和 SDH 流量参数本节定义了 SONET/SDH 的 GMPLS 流量参数。SONET/SDH 特定的 RSVP-TE 对象和 CR-LDP TLV 的协议特定格式分别在第 2.2 和 2.3 节中描述。这些流量参数为 SONET ANSI [T1.105] 和 SDH ITU-T [G.707] 指定了一组基本功能，例如级联和透明度。其他文档将来可能会进一步增强这组功能。例如，可以定义通过 PDH ITU-T G.832 或 sub-STM-0 ITU-T G.708 接口的 SDH 信令。当标签被编码为本备忘录中定义的 SUKLM 时，必须使用下文定义的流量参数（见第 2.1 节）（见第 3 节）。当请求部分/RS 或线路/MS 开销透明 STS-1/STM-0、STS-3*N/STM-N（N=1、4、16、64、256）信号之一时，也必须使用它们。[RFC3471] 第 3.2 节中定义的流量参数和标签编码必须用于完全透明的 STS-1/STM-0、STS-3*N/STM-N（N=1、4、16、64、256 ) 信号请求。完全透明的信号是中间节点不修改所有开销的信号；即，如果使用第 2.1 节中定义的流量参数，则将设置所有定义的透明 (T，Transparency) 位。2.1、 SONET/SDH 流量参数SONET/SDH 的流量参数组织如下：附件 1 列出了 SONET 和 SDH 信号编码的示例。o) 信号类型 (Signal Type，ST)：8 位该字段指示构成请求的标签交换路径 (Label Switched Path，LSP) 的基本信号的类型。可以在基本信号上连续应用多个变换，以构建实际为 LSP 请求的最终信号。每个变换应用程序都是可选的，如果为零则必须被忽略，但乘数 (Multiplier，MT) 除外，它不能为零，并且如果等于 1，将被忽略。必须严格按照以下顺序应用转换：- 首先，连续串联（通过使用 RCC 和 NCC 字段）可以选择性地应用于基本信号，从而产生连续串联的信号。- 其次，虚拟串联（通过使用 NVC 字段）可以选择性地应用于基本信号，从而产生虚拟串联信号。- 第三，当帧被请求为信号而不是基于 SPE 或 VC 的信号时，可以选择性地指定一些透明度（通过使用透明字段）。- 第四，乘法（通过使用 Multiplier 字段）可以选择性地直接应用于基本信号、从第一阶段获得的连续连接信号、从第二阶段获得的虚拟连接信号，或者这些信号与一些透明度。SONET/SDH 的允许信号类型值为专用信号类型被分配给 SONET STS-3c SPE，而不是被编码为三个 STS-1 SPE 的连续串联。这样做是为了在 SONET 和 SDH 信令之间提供简单的互通。附录 1 为上述值添加了一种信号类型（可选）。o) 请求的连续连接 (Requested Contiguous Concatenation，RCC)：8 位该字段用于请求基本信号的可选 SONET/SDH 连续级联。该字段是标志向量。每个标志表示支持特定类型的连续连接。可以同时设置多个标志以指示选择。这些标志允许上游节点向下游节点指示它支持的不同类型的连续连接。但是，下游节点根据自己的规则决定使用哪个。同时接收多个标志的下游节点会根据超出本文档范围的标准选择特定类型的连续连接（如果支持）。不支持该字段指示的任何级联类型的下游节点必须拒绝 LSP 请求。特别是，如果它根本不支持连续连接，它必须拒绝 LSP 请求。当设置了多个标志时，上游节点通过查看第一个标签指示的位置和下游节点返回的标签数量来检索下游节点选择的（单一）类型的连续串联（另请参见第 3 节）。整个字段设置为零以指示根本不需要连续连接（默认值）。非零字段表示请求了一些连续的连接。定义了以下标志：标志 1（位 1）：标准连续连接。标志 1 表示支持标准 SONET/SDH 连续级联，如 [T1.105]/[G.707] 中定义的那样。请注意，位 1 是低位。其他标志保留用于扩展；如果不使用，它们在发送时必须设置为零，并且在接收时应该被忽略。当组件数量是三的倍数时，请参阅 NCC 部分中关于 STS-1 SPE 的 SONET 连续串联的注释 1。o) 连续组件数 (Number of Contiguous Components，NCC)：16 位该字段指示请求连接的相同 SONET SPE/SDH VC（即基本信号）的数量，如 RCC 字段中所指定。注 1：当请求 N=3*X 的 SONET STS-Nc SPE 时，要使用的基本信号必须始终是 STS-3c_SPE 信号类型，并且 NCC 的值必须始终等于 X。这允许方便SONET 和 SDH 之间的互通。特别是，这意味着不能请求三个 STS-1 SPE 的连续级联，因为根据本规范，这种类型的信号必须使用 STS-3c SPE 信号类型进行编码。注 2：当请求透明 STS-N/STM-N 信号仅限于单个连续连接的 STS-Nc_SPE/VC-4-Nc 时，信号类型必须为 STS-N/STM-N，带有标志的 RCC 1、NCC设置为1。NCC 值必须与 RCC 字段中请求的连续连接类型一致。特别是，如果没有请求连续连接（RCC = 0），则该字段无关紧要。在这种情况下，它在发送时必须设置为零，并且在接收时应该被忽略。不同于 0 的 RCC 值意味着多个连续组件大于或等于 1。注 3：遵循这些规则，当请求 VC-4 信号时，RCC 和 NCC 值应该设置为 0，而对于 STS-3c SPE 信号，RCC 和 NCC 值应该设置为 1。但是，如果本地条件允许，由于 RCC 和 NCC 值的设置是本地驱动的，请求上游节点可以将 RCC 和 NCC 值设置为 SDH 或 SONET 设置而不影响功能。此外，如果本地条件允许，下游节点应该接受请求的值。如果这些值不能被支持，接收者下游节点应该产生一个 PathErr/NOTIFICATION 消息（分别参见第 2.2 和 2.3 节）。o) 虚拟组件数 (Number of Virtual Components，NVC)：16 位该字段表示请求虚拟级联的信号数量。根据定义，这些信号都属于同一类型。它们是基本信号 SPE/VC，在本文档中为其定义了信号类型；即 VT1.5_SPE/VC-11、VT2_SPE/VC-12、VT3_SPE、VT6_SPE/VC-2、STS-1_SPE/VC-3 或 STS-3c_SPE/VC-4。此字段设置为 0（默认值）以指示不请求虚级联。o) 乘法器 (Multiplier，MT)：16 位该字段表示为 LSP 请求的相同信号的数量；即，形成最终信号。这些信号可以是相同的基本信号、相同的连续连接信号或相同的虚拟连接信号。请注意，因此所有这些信号都属于同一 LSP。多个虚拟级联信号的分量之间的区别是通过信令中指定的标签顺序来完成的。第一组标签必须描述第一个分量（属于第一个虚级联信号的单个信号集），第二组必须描述第二个分量（属于第二个虚级联信号的单个信号集），依此类推。此字段设置为 1（默认值）以指示正在请求信号的一个实例。中间节点和出口节点必须验证节点本身和将在其上建立 LSP 的接口可以支持请求的乘数值。如果不能支持请求的值，接收方节点必须生成一个 PathErr/NOTIFICATION 消息（分别参见第 2.2 和 2.3 节）。零是无效值。如果接收到零，节点必须生成一个 PathErr/NOTIFICATION 消息（分别参见第 2.2 和 2.3 节）。注 1：当请求透明 STS-N/STM-N 信号仅限于单个连续连接的 STS-Nc-SPE/VC-4-Nc 时，乘数字段必须等于 1（仅有效值）。o) 透明度 (Transparency，T)：32 位该字段是一个标志向量，指示所请求的透明度类型。可以组合多个标志以提供不同类型的透明度。并非所有组合都必须有效。此字段的默认值为零，即不要求透明度。从本信令规范的角度定义的透明性仅适用于 SONET/SDH 帧开销中的字段。在 SONET 情况下，这些是段开销 (Section Overhead，SOH) 和线路开销 (Line Overhead，LOH) 中的字段。在 SDH 情况下，这些是再生段开销 (Regenerator Section Overhead，RSOH)、复用段开销 (Multiplex Section overhead，MSOH) 中的字段以及两者之间的指针字段。对于 SONET，指针字段是 LOH 的一部分。另请注意，透明度仅在使用以下信号类型时适用：STS-1/STM-0、STS-3/STM-1、STS-12/STM-4、STS-48/STM-16、STS-192 /STM-64 和 STS-768/STM-256。请求此类信号类型时，必须至少指定一种透明度类型。透明性准确地表明这些开销中的哪些字段必须在 LSP 的另一端未经修改地传递。请求透明的入口标签交换路由器 (Label Switching Router，LSR) 将传递这些开销字段，这些开销字段必须不加任何更改地传送到出口 LSR。从入口和出口 LSR 的角度来看，必须将这些字段视为未修改。透明度不是应用在与发起和终止 LSR 的接口上，而是仅在中间 LSR 之间应用。透明字段用于请求支持所请求透明类型的LSP；它还可用于设置要应用于每个中间 LSR 的透明度过程。不同的透明度标志如下：标志 1（位 1）：Section/Regenerator Section 层标志 2（位 2）：线路/复用段层其中位 1 是低位。保留其他标志；发送时应将它们设置为零，接收时应将其忽略。标志设置为 1 以指示请求相应的透明度。中间节点和出口节点必须验证节点本身和将建立 LSP 的接口可以支持请求的透明度。如果不能支持请求的标志，接收方节点必须生成一个 PathErr/NOTIFICATION 消息（分别参见第 2.2 和 2.3 节）。Section/Regenerator Section 层透明度意味着整个帧必须未经修改地交付。这意味着不能调整指针。当使用 Section/Regenerator Section 层透明度时，必须忽略所有其他标志。线路/复用段层透明意味着 LOH/MSOH 必须未经修改地交付。这意味着不能调整指针。o) 配置文件 (Profile，P)：32 位该字段旨在指示 LSP 必须支持的特定能力；例如，监控能力。当前没有定义标准配置文件，这个字段应该在发送时设置为零，在接收时忽略。将来，可能会创建基于 TLV 的扩展。2.2、 RSVP-TE 详细信息对于 RSVP-TE，SONET/SDH 流量参数携带在 SONET/SDH SENDER_TSPEC 和 FLOWSPEC 对象中。SENDER_TSPEC 对象和 FLOWSPEC 对象都使用相同的格式。对象的内容在上面的第 2.1 节中定义。对于 SONET ANSI T1.105 和 SDH ITU-T G.707，对象具有以下类和类型：SONET/SDH SENDER_TSPEC 对象：Class = 12，C-Type = 4SONET/SDH FLOWSPEC 对象：Class = 9，C-Type = 4没有与 SONET/SDH SENDER_TSPEC 相关联的 Adspec。要么省略 Adspec，要么使用具有默认通用特征参数和保证服务片段的 int-serv Adspec；参见 [RFC2210]。对于会话中的特定发送方，在 Resv 消息中接收到的 FLOWSPEC 对象的内容应该与在相应路径消息中接收到的 SENDER_TSPEC 对象的内容相同。如果对象不匹配，则应生成带有“流量控制错误/错误流规范值”错误的 ResvErr 消息。中间节点和出口节点必须验证节点本身和将建立 LSP 的接口可以支持请求的信号类型、RCC、NCC、NVC 和乘法器（如第 2.1 节中所定义）。如果请求的值不能被支持，接收方节点必须生成一个带有“Traffic Control Error/Service unsupported”指示的 PathErr 消息（见 [RFC2205]）。此外，如果收到的 MT 字段为零值，则节点必须生成带有“流量控制错误/错误 Tspec 值”指示的 PathErr 消息（参见 [RFC2205]）。中间节点还必须验证节点本身和将在其上建立 LSP 的接口可以支持请求的透明性（如第 2.1 节中所定义）。如果请求的值不被支持，接收方节点必须生成一个带有“Traffic Control Error/Service unsupported”指示的 PathErr 消息（参见 [RFC2205]）。2.3、 CR-LDP 详细信息对于CR-LDP，SONET/SDH 流量参数携带在SONET/SDH 流量参数TLV 中。TLV 的内容在上文第 2.1 节中定义。TLV 的头具有以下格式：SONET/SDH 流量参数 TLV 的类型字段是 0x0838。中间节点和出口节点必须验证节点本身和将建立 LSP 的接口可以支持请求的信号类型、RCC、NCC、NVC 和乘法器（如第 2.1 节中所定义）。如果请求的值不被支持，接收方节点必须生成一个带有“资源不可用”状态码的通知消息（参见 [RFC3212]）。此外，如果收到的 MT 字段为零值，则节点必须生成带有“资源不可用”状态代码的 NOTIFICATION 消息（参见 [RFC3212]）。中间节点还必须验证节点本身和将在其上建立 LSP 的接口可以支持请求的透明性（如第 2.1 节中所定义）。如果请求的值不被支持，接收方节点必须生成一个带有“资源不可用”状态码的通知消息（参见 [RFC3212]）。3、 SONET 和 SDH 标签SONET 和 SDH 各自定义了一个多路复用结构。两种结构都是树，其根分别是 STS-N 或 STM-N，叶子是可以通过时隙传输并在入口端口内的时隙和一个端口内的时隙之间切换的信号。出口端口；即，VTx SPE、STS-x SPE 或 VC-x。SONET/SDH 标签将识别多路复用结构中特定 VTx SPE、STS-x SPE 或 VC-x 信号的确切位置（即第一个时隙）。SONET 和 SDH 标签携带在根据 [RFC3473] 和 [RFC3472] 的通用标签中。请注意，时隙是指在多路复用中按逻辑顺序出现的时隙，而不是在任何可能的交织之后出现的时隙。这些多路复用结构将用作命名树以创建唯一的多路复用条目名称或标签。SONET 和 SDH 使用相同的标签格式。如 [RFC3471] 中所述，标签不标识标签所属的“类”。这由使用标签的链接隐式确定。在信号串联或乘法的情况下，标签列表可以出现在通用标签的标签字段中。在连续串联的情况下，标签字段中只会出现一个标签。该唯一标签被编码为通用标签对象（Class-Num = 16，C-Type = 2）/TLV (0x0825) 的单个 32 位标签值（如本节中所定义）。该标签标识由连续连接的信号占用的最低时隙。最低时隙是指当作为整数值进行比较时具有最低标签（值）的时隙；即，遇到下行树的级联信号的第一个分量信号所占用的时隙。在虚连接的情况下，给出连接中所有标签的显式有序列表。这个有序的标签列表被编码为通用标签对象 (Class-Num = 16, C-Type = 2)/TLV (0x0825) 的 32 位标签值序列（如本节中所定义）。每个标签表示由虚拟级联信号的一个分量占据的第一个时隙。标签的顺序必须反映要连接的有效负载的顺序（而不是时隙的物理顺序）。上述表示将虚级联限制在单个（组件）链接内；因此，与 ANSI [T1.105]/ITU-T [G.707] 建议相比，它施加了限制。虚级联的标准定义允许每个虚级联组件通过不同的路径传播。在 GMPLS 中，如果虚级联组件是同一 LSP 的一部分，则它们必须通过同一（组件）链路传输。这是由于标签绑定到（组件）链接的方式。但是请注意，不同路径上组件的路由实际上等同于建立不同的 LSP，每个 LSP 都有自己的路由。多个 LSP 可以在相同节点之间启动和终止，然后它们相应的组件可以关联在一起（即，虚拟连接）。在乘法的情况下（即使用乘法器变换），给出参与最终信号的所有标签的显式有序列表。这个有序的标签列表被编码为通用标签对象 (Class-Num = 16, C-Type = 2)/TLV (0x0825) 的 32 位标签值序列（如本节中所定义）。在虚拟连接信号相乘的情况下，给出参与最终信号的标签集的显式有序列表。第一组标签表示第一虚级联信号占用的时隙，第二组标签表示第二虚级联信号占用的时隙，以此类推。上述表示将乘法限制为保持在单个（组件）链接内。SONET 和/或 SDH TDM-LSR 链路的标签格式为这是[G.707]第7.3.7至7.3.13节中定义的编号方案的扩展；即 (K, L, M) 编号。注意[G.707]第 7.3.1 至 7.3.6 节中定义的高阶编号方案在此未使用。每个字母表示从多路复用结构中的父节点开始的可能分支编号。分支被认为是按递增顺序编号的，从多路复用结构的顶部开始。编号从 1 开始；零用于表示不重要或被忽略的字段。当一个字段在特定上下文中不重要或被忽略时，它必须在发送时设置为零，在接收时忽略。当使用 SONET/SDH LSP 的层次结构时，可以使用具有给定带宽的高阶 LSP 来承载低阶 LSP。请记住，高阶 LSP 是通过 SONET/SDH 高阶路径层网络建立的，而低阶 LSP 是通过 SONET/SDH 低阶路径层网络建立的（另见 ITU-T G.803，第 3 节, 对应的定义）。在这种情况下，高阶 SONET/SDH LSP 表现为具有给定带宽（例如 VC-3）的“虚拟链路”；它也可以用作转发邻接。低阶 SONET/SDH LSP 可以通过高阶 LSP 建立。由于标签是（虚拟）链接的本地标签，因此该标签的最高部分（即 S、U 和 K 字段）是不重要的并设置为零；即，标签是“0,0,0,L,M”。类似地，如果低阶 LSP 的结构未知或不相关，则该标签的最低部分（即 L 和 M 字段）不重要并设置为零；即，标签是“S,U,K,0,0”。例如，VC-3 LSP 可用于承载低阶 LSP。在这种情况下，在 VC-3 LSP 两端分配给低阶 LSP 的标签将 S、U 和 K 设置为零（即不重要），而 L 和 M 将用于指示在那个 VC-3 中分配的信号。在隧道的情况下，例如 VC-4 包含 VC-3 包含 VC-12/VC-11，其中 SUKLM 结构不足以表示完整的信号结构，必须使用分层方法；即，每层网络信令。S、U、K、L 和 M 的可能值定义如下：1. S=1-N 是 STS-N/STM-N 多路复用中特定 STS-3/AUG-1 的索引。S 仅对 SONET STS-N (N>1) 和 SDH STM-N (N>0) 有意义。S 必须为 0 并且对于 STS-1 和 STM-0 被忽略。2. U=1-3 是 STS-3/AUG-1 中特定 STS-1_SPE/VC-3 的索引。U 仅对 SONET STS-N (N>1) 和 SDH STM-N (N>0) 有意义。U 必须为 0，对于 STS-1 和 STM-0 将被忽略。3. K=1-3 是 VC-4 中特定 TUG-3 的索引。K 仅对 TUG-3 中结构的 SDH VC-4 有意义。K 必须为 0，并在所有其他情况下被忽略。4. L=1-7 是 STS-1_SPE/TUG-3 或 VC-3 中特定 VT_Group/TUG-2 的索引。L 必须为 0 并且在所有其他情况下被忽略。5. M 是 VT_Group/TUG-2 中特定 VT1.5_SPE/VC-11、VT2_SPE/VC-12 或 VT3_SPE 的索引。M=1-2表示对应VT Group内的特定VT3 SPE；这些值不得用于 SDH，因为没有与 SDH 等效的 VT3。M=3-5 表示对应的VT_Group/TUG-2内部有特定的VT2_SPE/VC-12。M=6-9 表示对应的VT_Group/TUG-2内部有特定的VT1.5_SPE/VC-11。请注意，标签始终必须根据 SONET/SDH 流量参数进行解释；即，标签本身不允许知道正在请求哪个信号（标签是上下文敏感的）。本节定义的标签格式，称为 SUKLM，必须用于任何不透明的 SONET/SDH 信号请求；即，当第 2.1 节中定义的所有透明 (T) 位都设置为零时。任何透明的 STS-1/STM-0/STS-3*N/STM-N（N=1、4、16、64、256）信号请求必须使用 [RFC3471] 中定义的标签格式。S编码总结如下表：U编码总结如下表：K编码总结如下表：L编码总结如下表：M编码总结如下表：标签示例例1：Sth STS-3/AUG-1中STS-3c_SPE/VC-4的标签为：S>0，U=0，K=0，L=0，M=0。例2：Sth AUG-1内VC-4内Kth-1 TUG-3内VC-3的标签为：S>0, U=0, K>0, L=0, M=0。例3：Sth STS-3/AUG-1内Uth-1 STS-1_SPE/VC-3的标签为：S>0，U>0，K=0，L=0，M=0。例4：Sth STS-3/AUG-1内Uth-1 STS-1_SPE/VC-3中Lth-1 VT Group/TUG-2中VT6/VC-2的标签为：S>0 , U>0, K=0, L>0, M=0。例5：Sth STS-3/AUG-1内Uth-1 STS-1_SPE/VC-3内Lth-1 VT Group/TUG-2内第3 VT1.5_SPE/VC-11的标签为：S>0，U>0，K=0，L>0，M=8。例6：STS-12c SPE/VC-4-4c使用第9个STS-3/AUG-1作为其第一个时隙的标签为：S=9, U=0, K=0, L=0, M=0。在连续串联的情况下，使用的标签是连续串联信号的最低标签（值），如前所述。标签的较高部分表示信号开始的位置，最低部分不重要。在 STM-0/STS-1 的情况下，根据字段编码规则，S、U 和 K 的值必须为零。例如，当请求 STM-0 中的 VC-3 时，标签为：S=0、U=0、K=0、L=0、M=0。当请求STM-0中VC-3中的VC-11时，标签为：S=0，U=0，K=0，L>0，M=6..9。注意：当请求一个Section/RS或Line/MS透明STS-1/STM-0/STS-3*N/STM-N(N=1, 4, 16, 64, 256)信号时，SUKLM标签格式并且编码不适用，标签编码必须遵循[RFC3471]第3.2节中定义的规则。4、 致谢从 CCAMP 邮件列表收到了宝贵的评论和意见，其中进行了出色的讨论。作者要感谢 Richard Rabbat 的宝贵意见，这导致了本次修订。5、 安全考虑本文档没有对 [RFC3473] 或 [RFC3472] 引入新的安全考虑。GMPLS 安全在 [RFC3471] 的第 11 节中描述，并参考 [RFC3209] 的 RSVP-TE 和 [RFC3212] 的 CR-LDP。6、 IANA 考虑IANA 为 RFC 3946 定义的三个值现在适用于本文档。注册表中的两个 RSVP C 类型：http://www.iana.org/assignments/rsvp-parameters- SONET/SDH SENDER_TSPEC 对象：Class = 12，C-Type = 4（参见第 2.2 节）。- SONET/SDH FLOWSPEC 对象：Class = 9，C-Type = 4（参见第 2.2 节）。注册表中的一种 LDP TLV 类型：http://www.iana.org/assignments/ldp-namespaces- SONET/SDH 流量参数 TLV 的类型字段（参见第 2.3 节）。附录 1、 VC-3 的信号类型值扩展本附录为第 2.1 节的信号类型字段定义了以下可选的附加信号类型值：根据ITU-T[G.707]建议，SDH复用的TU-3/TUG-3/VC-4/AU-4分支中的VC-3不能在TUG-2s中构造；但是，AU-3 分支中的 VC-3 可以。此外，如果需要，可以在两个分支之间切换 VC-3。VC-3 电路可以终止在 LSR 的入口接口上（例如，形成 VC-3 转发邻接）。这个 LSR 然后可能想要解复用这个 VC-3 并切换内部低阶 LSP。出于实施原因，这只有在 LSR 收到 AU-3 分支中的 VC-3 时才有可能。例如，对于在解复用之前无法在其传入接口上从 TU-3 分支内部切换到 AU-3 分支的 LSR，然后使用其交换结构交换内容。在那种情况下，指示 VC-3 LSP 必须在 AU-3 分支而不是 TU-3 分支的末端终止是有用的。这是通过使用“最后通过 AU-3 的 VC-3”信号类型来实现的。例如，倒数第二个 LSR 可以使用此信息将在任何分支中接收到的入局 VC-3 切换到到目标 LSR 的出站接口上的 AU-3 分支。“通过 AU-3 末端的 VC-3”信号类型并不意味着 VC-3 必须通过网络中其他一些地方的 AU-3 分支进行切换。VC-3 信号类型仅表示任何分支中的 VC-3 是合适的。附件 1、 示例本附件定义了 SONET 和 SDH 信号编码的示例。目的是帮助读者理解流量参数编码的工作原理，而不是举例说明典型的 SONET 或 SDH 信号。如上所述，信号类型是基本信号，可以对其应用连续的串联、乘法和透明变换以获得最终信号。1. VC-4 信号由值为 0 的 RCC、值为 0 的 NCC、值为 0 的 NVC、值为 1 的 MT 和值为 0 的 T 应用于 VC-4 基本信号形成。2. VC-4-7v信号由值为0的RCC、值为0的NCC、值为7的NVC（7个分量的虚拟串联）、值为1的MT和值为0的T应用于VC而形成-4 基本信号。3. VC-4-16c 信号由值为 1（标准连续连接）的 RCC、值为 16 的 NCC、值为 0 的 NVC、值为 1 的 MT 和值为 0 的 T 应用于 VC-4 形成基本信号。4. 具有复用段层透明性的 STM-16 信号是通过将值为 0 的 RCC、值为 0 的 NCC、值为 0 的 NVC、值为 1 的 MT 和带有标志 2 的 T 应用于 STM-16 基本信号而形成的.5. 具有复用段层透明性的 STM-4 信号是通过将值为 0 的 RCC、值为 0 的 NCC、值为 0 的 NVC、值为 1 的 MT 和带有标记 2 的 T 应用到 STM-4 Elementary 形成的信号。6. 具有复用段层透明性的 STM-256 信号是通过将值为 0 的 RCC、值为 0 的 NCC、值为 0 的 NVC、值为 1 的 MT 和带有标记 2 的 T 应用到 STM-256 Elementary 形成的信号。7. STS-1 SPE信号由值为0的RCC、值为0的NCC、值为0的NVC、值为1的MT和值为0的T应用于STS-1 SPE基本信号而形成。8. STS-3c SPE信号由值为1的RCC（标准连续连接）、值为1的NCC、值为0的NVC、值为1的MT和值为0的T应用于STS-3c SPE形成基本信号。9. STS-48c SPE信号由值为1的RCC（标准连续连接）、值为16的NCC、值为0的NVC、值为1的MT和值为0的T应用于STS-3c SPE形成基本信号。10. STS-1-3v SPE 信号由值为 0 的 RCC、值为 3 的 NVC（3 个分量的虚拟连接）、值为 1 的 MT 和值为 0 的 T 应用于 STS-1 SPE Elementary 形成信号。11. STS-3c-9v SPE信号由值为1的RCC、值为1的NCC、值为9的NVC（9个STS-3c的虚拟串联）、值为1的MT和值为0的T的应用形成 到 STS-3c SPE 基本信号。12. 具有段层（完全）透明的 STS-12 信号是通过将值为 0 的 RCC、值为 0 的 NCC、值为 0 的 NVC、值为 1 的 MT 和带有标志 1 的 T 应用到 STS-12 中形成的 基本信号。13. 3 x STS-768c SPE 信号是通过将值为 1 的 RCC、值为 256 的 NCC、值为 0 的 NVC、值为 3 的 MT 和值为 0 的 T 应用于 STS-3c SPE 基本信号而形成的。14. 5 x VC-4-13v 组合信号是通过将值为 0 的 RCC、值为 13 的 NVC、值为 5 的 MT 和值为 0 的 T 应用于 VC-4 基本信号而形成的。这些示例的编码总结在下表中：规范参考[G.707] ITU-T Recommendation G.707, "Network Node Interface for the Synchronous Digital Hierarchy", October 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats", ANSI T1.105, October 2000.完整的版权声明版权所有 (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) 提供。
-
发表了文章 2023-03-04
使用以太网 VPN (EVPN) 的网络虚拟化Overlay解决方案
RFC8365：A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)，March 2018梗概本文档详细说明了以太网 VPN (Ethernet VPN，EVPN) 如何用作网络虚拟化Overlay (Network Virtualization Overlay，NVO) 解决方案，并探讨了 IP 上的各种隧道封装选项及其对 EVPN 控制平面和程序的影响。特别地，分析了以下封装选项：虚拟可扩展局域网 (Virtual Extensible LAN，VXLAN)、使用通用路由封装的网络虚拟化 (Network Virtualization using Generic Routing Encapsulation，NVGRE) 和 MPLS over GRE。本规范也适用于通用网络虚拟化封装（Generic Network Virtualization Encapsulation，GENEVE）；但是，需要一些增量工作，这将在单独的文件中介绍。该文件还规定了用于水平分割过滤和批量撤销的新多宿主程序。它还规定了 VXLAN/NVGRE 封装的 EVPN 路由结构和网络虚拟化边缘 (Network Virtualization Edge，NVE) 设备多宿主的自治系统边界路由器 (Autonomous System Border Router，ASBR) 程序。本备忘录的状态这是一个 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 团体的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8365。版权声明版权所有 (c) 2018 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍本文档详细说明了以太网 VPN (EVPN) [RFC7432-基于BGP MPLS的EVPN] 如何用作网络虚拟化Overlay (NVO) 解决方案，并探讨了 IP 上的各种隧道封装选项及其对 EVPN 控制平面和程序的影响。特别地，分析了以下封装选项：虚拟可扩展局域网 (VXLAN) [RFC7348-VXLAN基于三层网络实现二层虚拟化的框架]、使用通用路由封装的网络虚拟化 (NVGRE) [RFC7637] 和基于通用路由封装 (GRE) 的 MPLS [RFC4023]。本规范也适用于通用网络虚拟化封装（GENEVE）[GENEVE]；但是，需要一些增量工作，这将在单独的文档 [EVPN-GENEVE] 中介绍。该文件还规定了用于水平分割过滤和批量撤销的新多宿主程序。它还规定了 VXLAN/NVGRE 封装的 EVPN 路由结构和网络虚拟化边缘 (NVE) 设备多宿主的自治系统边界路由器 (ASBR) 程序。在本文档的环境中，NVO 是一种解决多租户数据中心需求的解决方案，尤其是具有虚拟化主机（例如虚拟机 (Virtual Machines，VM) 或虚拟工作负载）的数据中心。如 [RFC7364] 中所述，此类解决方案的关键要求如下：- 隔离每个租户的网络流量- 支持大量租户（数万或数十万）- 跨数据中心内或不同数据中心之间不同交付点 (Points of Delivery，PoD) 的属于指定租户段（子网）的不同 VM 之间的2层 (Layer 2，L2) 连接扩展- 允许指定的 VM 在指定的 L2 段内的不同物理连接点之间迁移假设 NVO 解决方案的底层网络提供 NVO 端点之间的 IP 连接。本文档描述了如何将 EVPN 用作 NVO 解决方案，并探讨 EVPN 功能和程序的适用性。特别地，它描述了 EVPN over IP 的各种隧道封装选项及其对 EVPN 控制平面的影响以及两个主要场景的程序：(a) 单宿主 NVE - 当 NVE 驻留在虚拟机管理程序中时，以及(b) 多宿主 NVE - 当 NVE 驻留在架顶式 (Top-of-Rack，ToR) 设备中时。本文档中分析的 EVPN Overlay的可能封装选项包括：- VXLAN 和 NVGRE- MPLS over GRE在开始介绍 EVPN over IP 的不同封装选项之前，重要的是强调 EVPN 解决方案的主要功能、这些功能当前的支持方式以及封装对这些功能的任何影响。2、 需求符号和约定关键词“必须”、“不得”、“要求”、“应该”、“不应该”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” “当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。3、 术语本文档中使用的大部分术语来自 [RFC7432-基于BGP MPLS的EVPN] 和 [RFC7365-数据中心（DC）网络虚拟化框架]。VXLAN：Virtual Extensible LAN，虚拟可扩展局域网GRE：Generic Routing Encapsulation，通用路由封装NVGRE：Network Virtualization using Generic Routing Encapsulation，使用通用路由封装的网络虚拟化GENEVE：Generic Network Virtualization Encapsulation，通用网络虚拟化封装PoD：Point of Delivery，交付点NV：Network Virtualization，网络虚拟化NVO：Network Virtualization Overlay，网络虚拟化OverlayNVE：Network Virtualization Edge，网络虚拟化边缘VNI：VXLAN Network Identifier，VXLAN 网络标识符VSID：Virtual Subnet Identifier，虚拟子网标识符（用于 NVGRE）I-SID：Service Instance Identifier，服务实例标识符EVPN：Ethernet VPN，以太网VPNEVI：EVPN Instance，EVPN 实例。跨越参与该 EVPN 的提供商边缘 (Provider Edge，PE) 设备的 EVPN 实例MAC-VRF：PE 上媒体访问控制 (Media Access Control，MAC) 地址的虚拟路由和转发表（Virtual Routing and Forwarding table）IP-VRF：PE 上 Internet 协议 (Internet Protocol，IP) 地址的虚拟路由和转发表（Virtual Routing and Forwarding table）ES：Ethernet Segment，以太网段。当客户站点（设备或网络）通过一组以太网链路连接到一个或多个 PE 时，该组链路称为“以太网段”。ESI：Ethernet Segment Identifier，以太网段标识符，标识以太网段的唯一非零标识符称为“以太网段标识符”。Ethernet Tag：以太网标签，以太网标签标识特定的广播域，例如 VLAN。一个 EVPN 实例由一个或多个广播域组成。PE：Provider Edge，提供商边缘Single-Active Redundancy Mode：单活冗余模式，当连接到 ES 的所有 PE 中只有一个 PE 被允许向/从该 ES 转发指定 VLAN 的流量时，以太网段被定义为在单活冗余中运行模式。All-Active Redundancy Mode：全活冗余模式，当允许连接到以太网段的所有 PE 向/从该 ES 转发指定 VLAN 的已知单播流量时，ES 被定义为在全活冗余模式下运行。PIM-SM：Protocol Independent Multicast - Sparse-Mode，协议独立组播 - 稀疏模式PIM-SSM：Protocol Independent Multicast - Source-Specific Multicast，协议独立组播 - 特定于源的组播BIDIR-PIM：Bidirectional PIM，双向 PIM4、 EVPN 功能EVPN [RFC7432-基于BGP MPLS的EVPN] 最初旨在支持 [RFC7209-EVPN：以太网VPN的要求] 中详述的要求，因此具有以下直接解决控制平面扩展和易于部署问题的属性。1. 控制平面信息通过 BGP 分发，广播和组播流量使用共享组播树或入口复制发送。2. 控制平面学习用于 MAC（和 IP）地址，而不是数据平面学习。后者需要未知单播和地址解析协议 (Address Resolution Protocol，ARP) 帧的泛洪；而前者不需要任何泛洪。3. 路由反射器（Route Reflector，RR）用于将 PE 设备之间的全网状 BGP 会话减少为 PE 和 RR 之间的单个 BGP 会话。此外，可以利用 RR 层次结构来扩展 RR 上 BGP 路由的数量。4. 通过BGP自动发现用于发现参与指定VPN的PE设备、参与指定冗余组的PE设备、隧道封装类型、组播隧道类型、组播成员等。5. 使用全活多宿主。这允许指定的客户边缘 (Customer Edge，CE) 设备具有到多个 PE 的多条链路，并且进出该 CE 的流量充分利用所有这些链路。6. 当CE 和PE 之间的链路发生故障时，通过撤消单个EVPN 路由通知该EVI 的PE。这允许这些 PE 删除作为与故障链路关联的每个 MAC 地址的下一跳的撤销 PE。这被称为“大规模撤销”。7. 利用 BGP 路由过滤和约束路由分发来确保指定 EVI 的控制平面流量仅分发到该 EVI 中的 PE。8. 当CE和PE之间使用IEEE 802.1Q [IEEE.802.1Q]接口时，该接口上的每个VLAN ID（VID）都可以映射到一个网桥表（最多4094个这样的网桥表）。所有这些网桥表都可以映射到单个 MAC-VRF（在 VLAN 感知绑定服务的情况下）。9. VM 迁移机制确保指定 EVI 中的所有 PE 知道指定 VM（由其 MAC 和 IP 地址标识）当前与其关联的 ES。10. RT 用于允许操作员（或客户）定义一系列逻辑网络拓扑，包括网状、中心辐射和外联网（例如，站点由不同企业拥有的 VPN），而无需专有软件或其他虚拟或物理设备的帮助。由于 NVO 的设计目标是每个通用物理基础设施有数百万个实例，因此 NVO 控制平面的扩展特性极其重要。EVPN 和此处描述的扩展在设计时就考虑到了这种级别的可扩展性。5、 EVPN Overlay的封装选项5.1、 VXLAN/NVGRE 封装VXLAN 和 NVGRE 都是提供数据平面封装的技术示例，该封装用于通过网络虚拟化边缘 (NVE) 之间的公共物理 IP 基础设施传输数据包，例如 VXLAN 网络中的 VXLAN 隧道端点 (VXLAN Tunnel End Points，VTEP)。这两种技术都在每个数据包中包含特定 NVO 实例的标识符，VXLAN 中的 VNI 和 NVGRE 中的 VSID。在本文档的其余部分，我们使用 VNI 作为 NVO 实例的表示，并理解如果封装是 NVGRE，则 VSID 也可以同等使用，除非另有说明。请注意，PE 等效于 NVE/VTEP。VXLAN 封装基于UDP，UDP 头后面有一个8 字节的头。VXLAN 提供 24 位 VNI，通常提供到租户 VID 的一对一映射，如 [RFC7348] 中所述。在这种情况下，入口 VTEP 在封装的帧上不包含内层 VLAN 标记，出口 VTEP 会丢弃带有内层 VLAN 标记的帧。[RFC7348] 中的这种操作模式映射到 [RFC7432] 中的基于 VLAN 的服务，其中租户 VID 被映射到 EVI。如果在 VTEP 中明确配置，VXLAN 还提供了在封装帧中包含内部 VLAN 标记的选项。这种操作模式可以映射到 [RFC7432] 中的 VLAN Bundle Service，因为所有租户的标记帧都映射到单个网桥表/MAC-VRF，并且在执行 VXLAN 解封装时，内部 VLAN 标记不被配置 PE 用于查找在 [RFC7348] 的第 6 节中描述。[RFC7637] 封装基于 GRE 封装，它要求包含可选的 GRE Key 字段，该字段携带 VSID。VSID 和租户 VID 之间存在一对一的映射，如 [RFC7637] 中所述。禁止包含内部 VLAN 标记。[RFC7637] 中的这种操作模式映射到 [RFC7432] 中的基于 VLAN 的服务。如下一节所述，除了使用 BGP 封装扩展团体来指示封装类型（例如，VXLAN 或 NVGRE）外，EVPN 路由的编码没有更改以支持 VXLAN 或 NVGRE 封装。但是，根据 NVE 所在的位置（即在管理程序或 ToR 中）以及是否需要多宿主功能，对 EVPN 程序有潜在影响。5.1.1、 虚拟标识符范围尽管 VNI 被定义为 24 位全局唯一值，但在某些情况下，需要为 VNI 使用本地有效值，尤其是在数据中心互连的环境中。5.1.1.1、 数据中心与网关互联在不同数据中心的NVE需要互联的情况下，NVE需要使用VNI作为数据中心内的全局唯一标识符，那么就需要在数据中心网络（data-center network，DCN）的边缘采用网关（Gateway，GW）。这是因为网关将在跨越网络边界时提供转换 VNI 的功能，这可能与操作员的控制范围边界一致。例如，考虑图 1 的网络。假设有三个网络操作员：DC1、DC2 和 WAN 网络各有一个。位于数据中心边缘的网关负责在每个 DCN 中使用的值和 WAN 中使用的值之间转换 VNI。图 1：数据中心与网关互连5.1.1.2、 无网关的数据中心互连在不同数据中心的NVE需要互联的情况下，NVE需要使用本地分配的VNI（例如，类似于MPLS标签），可能不需要在DCN的边缘部署网关。更具体地说，发送 NVE 使用的 VNI 值由接收流量的 NVE 分配（换句话说，这类似于“下游分配的”MPLS 标签）。这允许 VNI 空间在不同 DCN 之间解耦，而无需在数据中心边缘使用专用网关。此主题在第 10.2 节中介绍。图 2：数据中心互连与 ASBR5.1.2、 虚拟标识符到 EVI 映射就像在 [RFC7432] 中，存在两个选项用于将广播域（由 VLAN ID 表示）映射到 EVI，当 EVPN 控制平面与 VXLAN（或 NVGRE 封装）结合使用时，也有两个选项用于映射广播由 VXLAN VNI（或 NVGRE VSID）表示的域到 EVI：选项 1：每个 EVI 一个广播域在此选项中，由 VNI 表示的单个以太网广播域（例如，子网）映射到唯一的 EVI。这对应于 [RFC7432] 中的基于 VLAN 的服务，其中面向租户的接口、逻辑接口（例如，由 VID 表示）或物理接口被映射到 EVI。因此，每个 NVE 上的每个 VNI 都需要一个 BGP 路由识别符 (Route Distinguisher，RD) 和路由目标 (Route Target，RT)。该模型的优点是它允许使用 BGP RT 约束机制，以将路由的传播和导入限制为仅对指定 VNI 感兴趣的 NVE。如果 RD 和 RT 不是从 VNI 自动派生的，则此模型的缺点可能是配置开销。在此选项中，MAC-VRF 表由控制平面中的 RT 和数据平面中的 VNI 标识。在此选项中，特定的 MAC-VRF 表仅对应于单个网桥表。选项 2：每个 EVI 多个广播域在此选项中，多个子网（每个子网由唯一的 VNI 表示）映射到单个 EVI。例如，如果租户有多个段/子网，每个段/子网都由一个 VNI 表示，那么该租户的所有 VNI 都映射到单个 EVI；例如，这种情况下的 EVI 代表租户而不是子网。这对应于 [RFC7432] 中的 VLAN 感知绑定服务。此模型的优点是不需要为每个 VNI 配置 RD/RT。但是，与使用自动推导的选项 1 相比，这是一个有争议的问题。此模型的缺点是路由将由可能对指定 VNI 不感兴趣的 NVE 导入。在该选项中，MAC-VRF表由控制平面中的RT标识；该 MAC-VRF 的特定桥接表由控制平面中的 <RT, Ethernet Tag ID> 标识。在此选项中，数据平面中的 VNI 足以识别特定的桥接表。5.1.2.1、 RT 的自动推导为了简化配置，当使用每个 EVI 的单个 VNI 选项时，用于 EVPN 的 RT 可以自动导出。RD 可以按照 [RFC7432] 中的描述自动生成，RT 可以按照下面的描述自动导出。由于图 1 中描述的网关 PE 同时参与 DCN 和 WAN BGP 会话，因此重要的是，当 RT 值自动从 VNI 派生时，DCN 和 WAN 之间的 RT 空间不存在冲突，假设两者都是在同一个自治系统 (Autonomous System，AS) 内运行。此外，在某些情况下，同一 DCN 中可能需要 VXLAN 和 NVGRE 封装，并且它们对应的 VNI 是独立管理的，这意味着 VNI 空间可以重叠。为了避免 RT 空间中的冲突，DCN 的 6 字节 RT 值和 2 个八位字节的 AS 编号可以自动导出如下：6 个八位字节的 RT 字段由两个子字段组成：- Global Administrator子字段：2 个八位字节。该子字段包含由 IANA <https://www.iana.org/assignments/as-numbers/> 分配的 AS 编号。- Local Administrator子字段：4 个八位字节* A：一个单比特字段，指示这个 RT 是否是自动导出的0：自动导出 1：手动导出* Type：类型，一个 3 位字段，用于标识定义其他 3 个字节的空间。定义了以下空间：0 : VID (802.1Q VLAN ID) 1 : VXLAN 2 : NVGRE 3 : I-SID 4 : EVI 5 : dual-VID (QinQ VLAN ID)* D-ID：一个 4 位字段，用于标识域 ID。domain-id 的默认值为零，表示对于指定技术仅存在单个编号空间。但是，如果指定技术存在多个数字空间（例如，重叠的 VXLAN 空间），则每个数字空间都需要通过其从 1 开始的相应域 ID 来标识。* Service ID：服务ID，此 3 个八位字节字段设置为 VNI、VSID、I-SID 或 VID。需要注意的是，RT 自动推导适用于 2 个八位字节的 AS 编号。对于 4个八位字节的AS 号，RT 需要手动配置，因为 3个八位字节的VNI 字段无法放入 2个八位字节的本地管理员字段。5.1.3、 构建EVPN BGP路由在 EVPN 中，例如标识转发表的 MPLS 标签由出口 PE 通过 EVPN 控制平面分发，并由入口 PE 放置在指定数据包的 MPLS 标头中。该标签在出口 PE 接收到该数据包时用于处理该数据包。这与出口 NVE 使用 VNI 非常相似，不同之处在于 MPLS 标签具有局部意义，而 VNI 通常具有全局意义。因此，特别是为了支持本地分配的 VNI 选项、MAC/IP 通告路由中的 MPLS 标签1 字段、每个 EVI 路由的以太网 AD 中的 MPLS 标签字段以及 P-组播服务接口（P-Multicast Service Interface，PMSI）中的 MPLS 标签字段包含组播以太网标签（Inclusive Multicast Ethernet Tag，IMET）路由的隧道属性用于承载VNI。为了本备忘录的平衡，上述 MPLS 标签字段将被称为 VNI 字段。VNI 字段用于本地和全局 VNI；无论哪种情况，整个 24 位字段都用于对 VNI 值进行编码。对于基于 VLAN 的服务（每个 MAC-VRF 有一个 VNI），MAC/IP 通告中的以太网标签字段、每个 EVI 的以太网 AD 和 IMET 路由必须设置为零，就像在 [RFC7432]。对于 VLAN 感知绑定服务（每个 MAC-VRF 有多个 VNI，每个 VNI 与自己的网桥表相关联），MAC 通告中的以太网标签字段、每个 EVI 的以太网 AD 和 IMET 路由必须标识 MAC 内的网桥表-VRF;该 EVI 的以太网标签集需要在该 EVI 内的所有 PE 上一致配置。对于本地分配的 VNI，以太网标签字段中通告的值必须设置为 VID，就像在 [RFC7432] 中的 VLAN 感知绑定服务中一样。必须在指定域内参与该 EVI 的所有 PE 设备上一致地进行此类设置。对于全局 VNI，以太网标签字段中通告的值应该设置为 VNI，只要它匹配以太网标签的现有语义，即，它标识 MAC-VRF 内的网桥表，并且 VNI 集已配置在该 EVI 中的每个 PE 上始终如一。为了指示要使用哪种类型的数据平面封装（即 GRE 中的 VXLAN、NVGRE、MPLS 或 MPLS），[RFC5512] 中定义的 BGP 封装扩展团体包含在所有 EVPN 路由（即 MAC出口 PE 通告的通告、每个 EVI 的以太网 AD、每个 ESI、IMET 和以太网段的以太网 AD）。IANA 分配了五个新值以扩展 [RFC5512] 中定义的封装类型列表；它们列在第 11 节中。需要第 11 节中列出的 MPLS 封装隧道类型，以区分仅支持非 MPLS 封装的广播节点和支持 MPLS 和非 MPLS 封装的广播节点。仅支持 MPLS 封装的通告节点不需要通告任何封装隧道类型；即，如果 BGP 封装扩展团体不存在，则假定 MPLS 封装或静态配置的封装。路由的 MP_REACH_NLRI 属性的 Next Hop 字段必须设置为 NVE 的 IPv4 或 IPv6 地址。每个路由中的其余字段根据 [RFC7432] 设置。请注意，此处定义的程序——在指定使用 VNI 的隧道封装扩展团体存在的情况下使用 MPLS 标签字段携带 VNI——与[TUNNEL-ENCAP]的第 8.2.2.2 节中描述的程序一致。（“当尚未发出有效 VNI 信号时”）。5.2、 基于 GRE 的 MPLSEVPN 数据平面被建模为位于 MPLS PSN 隧道服务器层之上的 EVPN MPLS 客户端层。某些 EVPN 功能（水平分割、别名和备份路径）与 MPLS 客户端层相关联。如果使用 MPLS over GRE 封装，则 EVPN MPLS 客户端层可以透明地通过 IP PSN 隧道承载。因此，对 EVPN 程序和相关数据平面操作没有影响。[RFC4023] 定义了使用 MPLS over GRE 封装的标准，可用于此目的。但是，当 MPLS over GRE 与 EVPN 结合使用时，建议存在 GRE 密钥字段并仅在 P 节点可以执行基于等价多路径 (Equal-Cost Multipath，ECMP) 散列的情况下才用于提供 32 位熵值在 GRE 键上；否则，GRE 头不应该包含 GRE 密钥字段。不得包括校验和和序列号字段，并且必须将 GRE 头中相应的 C 和 S 位设置为零。能够支持这种封装的 PE 应该通告它的 EVPN 路由以及隧道封装扩展团体，指示 MPLS over GRE 封装，如上一节所述。6、 具有多个数据平面封装的 EVPN根据 [RFC5512] 使用 BGP 封装扩展团体允许指定 EVI 中的每个 NVE 了解该 EVI 中每个其他 NVE 支持的每个封装。也就是说，指定 EVI 中的每个 NVE 都可以支持多个数据平面封装。只有当出口 NVE 通告的封装集与入口 NVE 支持的封装集形成非空交集时，入口 NVE 才能向出口 NVE 发送帧；从这个交集中选择哪个封装由入口 NVE 决定。（如第 5.1.3 节所述，如果 BGP 封装扩展团体不存在，则假定默认 MPLS 封装或本地配置的封装。）当 PE 通告多个支持的封装时，它必须通告使用相同 EVPN 程序的封装，包括与第 8.3.1 节中描述的水平分割过滤相关的程序。例如，VXLAN 和 NVGRE（或 MPLS 和 MPLS over GRE）封装使用相同的 EVPN 程序；因此，PE 可以同时通告它们，并且可以同时支持它们中的任何一个或两者。但是，PE 不得同时通告 VXLAN 和 MPLS 封装，因为 (a) EVPN 路由的 MPLS 字段设置为 MPLS 标签或 VNI，但不能同时设置和 (b) 某些 EVPN 程序（例如水平分割过滤）对于 VXLAN/NVGRE 和 MPLS 封装是不同的。使用共享组播树发送广播或组播帧的入口节点可以为每个不同的封装类型维护不同的树。指定 EVI 的操作员有责任确保该 EVI 中的所有 NVE 支持至少一种通用封装。如果违反此条件，可能会导致服务中断或失败。BGP 封装扩展团体的使用提供了一种检测何时违反此条件的方法，但要采取的措施由操作员自行决定，不在本文档的范围内。7、 单宿主NVE-驻留在Hypervisor中的NVE当 NVE 及其主机/虚拟机位于同一物理设备中时，例如，当它们驻留在服务器中时，它们之间的链路是虚拟的，并且它们通常共享命运。也就是说，主题主机/VM 通常不是多宿主的，或者如果它们是多宿主的，则多宿主对于托管 VM 和 NVE 的服务器来说是纯粹的本地事务，并且不需要对驻留在其上的任何其他 NVE“可见”其他服务器。因此，它不需要任何特定的协议机制。最常见的情况是 NVE 驻留在虚拟机管理程序上。在接下来的小节中，我们将讨论当 NVE 驻留在虚拟机管理程序上并且使用 VXLAN（或 NVGRE）封装的情况下对 EVPN 过程的影响。7.1、 对 VXLAN/NVGRE 封装的 EVPN BGP 路由和属性的影响在不同数据中心组位于不同管理域下，并且这些数据中心通过一个或多个骨干核心提供商连接的场景中，如 [RFC7365] 所述，RD 必须是每个 EVI 或每个 NVE 的唯一值，如 [RFC7432]。换句话说，只要全局 VNI 有多个管理域，就必须使用唯一的 RD；或者，只要 VNI 值具有本地意义，就必须使用唯一的 RD。因此，建议始终使用 [RFC7432] 中描述的唯一 RD。当 NVE 驻留在虚拟机管理程序上时，不再需要与多宿主关联的 EVPN BGP 路由和属性。这将所需的路由和属性减少到 [RFC7432] 的第 7 节中列出的总共八个中的四个的以下子集：- MAC/IP 通告路由- 包含组播以太网标签路由- MAC 迁移扩展团体- 默认网关扩展团体但是，如 [RFC7432] 的第 8.6 节所述，为了使单归属入口 NVE 在与附加到指定 ES 的多归属出口 NVE 交互时能够利用快速收敛、别名和备份路径，单归属入口 NVE 应该能够接收和处理每个 ES 的以太网 AD 和每个 EVI 的以太网 AD 的路由。7.2、 对 VXLAN/NVGRE 封装的 EVPN 程序的影响当 NVE 驻留在虚拟机管理程序上时，不再需要与多宿主关联的 EVPN 过程。这将 NVE 上的程序限制为以下子集。1. 根据 [RFC7432-基于BGP MPLS的EVPN] 的第 10.1 节从 VM 接收到的 MAC 地址的本地学习。2. 使用 MAC/IP 通告路由在 BGP 中通告本地学习的 MAC 地址。3. 根据 [RFC7432] 的第 9.2 节使用 BGP 执行远程学习。4. 发现其他NVE并使用IMET路由构建组播隧道。5. 按照 [RFC7432] 中第 15 节的程序处理 MAC 地址迁移事件。然而，如 [RFC7432] 的第 8.6 节所述，为了使单归属入口 NVE 在与附加到指定 ES 的多归属出口 NVE 交互时能够利用快速收敛、别名和备份路径，单归属入口 NVE 应实现路由的入口节点处理，这些路由是 [RFC7432] 的第 8.2 节（“快速收敛”）和 8.4（“别名和备份路径”）中定义的每个 ES 的以太网 AD 和每个 EVI 的以太网 AD。8、 多宿主NVE-驻留在ToR交换机中的NVE在本节中，我们讨论 NVE 驻留在 ToR 交换机中并且服务器（VM 驻留的地方）多宿主到这些 ToR 交换机的场景。多宿主 NVE 在全活或单活冗余模式下运行。如果服务器是单宿主到 ToR 交换机，那么就所需的 EVPN 功能而言，情况将类似于 NVE 驻留在虚拟机管理程序上的情况，如第 7 节所述。[RFC7432] 定义了一组 BGP 路由、属性和过程来支持多宿主。我们首先描述这些功能和过程，然后讨论其中哪些受 VXLAN（或 NVGRE）封装的影响以及需要进行哪些修改。正如本节稍后将看到的，唯一受非 MPLS Overlay封装（例如，VXLAN 或 NVGRE）影响的 EVPN 过程是水平分割过滤，它为一个 ID 而不是一堆标签提供空间对于第 8.3.1 节中描述的多宿主 ES。8.1、 EVPN 多宿主功能在本节中，我们将回顾 EVPN 的多宿主特性以突出封装依赖性。本节仅在较高级别描述特性和功能。更详细的内容请读者参考[RFC7432]。8.1.1、 多宿主 ES 自动发现连接到同一 ES（例如，通过链路聚合组 (Link Aggregation Group，LAG) 的同一服务器）的 EVPN NVE（或 PE）可以通过交换 BGP 路由，以最少或无需配置自动发现彼此。8.1.2、 快速收敛和大量撤销EVPN 定义了一种机制，可以在与 ES 的连接发生故障（例如，链路或端口故障）时，向远程 NVE 有效且快速地发出信号，通知需要更新其转发表。这是通过让每个 NVE 为每个本地连接段为每个 ES 通告以太网 A-D 路由来完成的。在连接到连接段失败时，NVE 撤消相应的以太网 A-D 路由。这会触发所有收到撤销请求的 NVE 更新与相关 ES 关联的所有 MAC 地址的下一跳邻接关系。如果没有其他 NVE 为同一段通告了以太网 A-D 路由，那么收到撤销的 NVE 只会使该段的 MAC 条目无效。否则，NVE 相应地更新下一跳邻接表。8.1.3、 水平分割如果服务器多宿主到两个或多个 NVE（由 ES ES1 表示）并在全活冗余模式下运行，则向这些 NVE 之一发送 BUM（即，广播、未知单播或组播）数据包，然后它确保数据包不会通过连接到此服务器的另一个 NVE 环回服务器很重要。NVE 上防止此类循环和数据包重复的过滤机制称为“水平分割过滤”。8.1.4、 别名和备份路径在一个站点多宿主到多个 NVE 的情况下，可能只有一个 NVE 获知与该站点传输的流量相关联的一组 MAC 地址。这导致远程 NVE 从单个 NVE 接收这些地址的 MAC 通告路由的情况，即使多个 NVE 连接到多宿主站也是如此。结果，远程 NVE 无法在连接到多宿主 ES 的 NVE 之间有效地负载均衡流量。例如，当 NVE 对访问执行数据路径学习并且站上的负载均衡功能将流量从指定的源 MAC 地址散列到单个 NVE 时，可能就是这种情况。另一种发生这种情况的情况是，当 NVE 依赖控制平面学习访问时（例如，使用 ARP），因为 ARP 流量将散列到 LAG 中的单个链路。为了缓解这个问题，EVPN 引入了“别名”的概念。这是指 NVE 发出信号表明它可以到达指定的本地连接 ES 的能力，即使它没有从该网段获知任何 MAC 地址。为此使用每个 EVI 的以太网 A-D 路由。接收具有非零 ESI 的 MAC 通告路由的远程 NVE 应将 MAC 地址视为可通过所有使用具有相同 ESI 和单活标志重置的以太网 A-D 路由通告相关段的可达性的 NVE 可达。Backup Path 是一项密切相关的功能，尽管它适用于冗余模式为 Single-Active 的情况。在这种情况下，NVE 发出信号，表明它也可以使用以太网 A-D 路由到达指定的本地连接 ES。接收 MAC 通告路由的远程 NVE，具有非零 ESI，应认为 MAC 地址可通过通告 NVE 访问。此外，远程 NVE 应该为所述 MAC 安装一个备份路径，该 NVE 使用具有相同 ESI 和单活标志集的以太网 A-D 路由通告了相关段的可达性。8.1.5、 DF选举如果主机多宿主到运行在全活冗余模式下的 ES 上的两个或多个 NVE，那么对于指定的 EVI，只有这些 NVE 中的一个，称为“指定转发器”（ Designated Forwarder，DF）负责向其发送广播，组播，如果为该 EVI 配置了未知单播帧。这是必需的，以防止在全活冗余的情况下将多目标帧重复传送到多宿主主机或 VM。在从主机接收到标记为 IEEE 802.1Q [IEEE.802.1Q] 的帧的 NVE 中，应该根据 [RFC7432] 的第 8.5 节中的主机 VID 执行 DF 选择。此外，指定 ES 的多宿主 PE 可以使用配置的 ID（例如 VNI、EVI、规范化 VID 等）执行 DF 选举，因为这些 ID 在多宿主 PE 上是一致配置的。在接收到 VXLAN 封装帧的 GW 中，在 VNI 上进行 DF 选举。再次假设，对于指定的以太网段，VNI 是唯一且一致的（例如，不存在重复的 VNI）。8.2、 对 EVPN BGP 路由和属性的影响由于在这种情况下支持多宿主，因此使用了 [RFC7432] 中定义的整个 BGP 路由和属性集。MAC 通告、Ethernet A-D per EVI 和 IMET) 路由中以太网标签字段的设置遵循第 5.1.3 节的设置。此外，每个 EVI 路由的 MAC 通告和以太网 A-D 中 VNI 字段的设置遵循第 5.1.3 节的设置。8.3、 对 EVPN 程序的影响这里需要检查两种情况，具体取决于 NVE 是在单活还是全活冗余模式下运行。首先，让我们考虑单活冗余模式的情况，其中主机多宿主到一组 NVE；但是，对于指定的 VNI，在指定的时间点只有一个 NVE 处于活动状态。在这种情况下，不需要Aliasing，也可以不需要水平分割过滤，但需要其他功能，如多宿主ES自动发现、快速收敛和批量撤销、Backup Path、DF选举。其次，让我们考虑 All-Active 冗余模式的情况。在这种情况下，在第 8.1 节中列出的所有 EVPN 多宿主功能中，使用 VXLAN 或 NVGRE 封装会影响水平分割和别名功能，因为这两个功能依赖于 MPLS 客户端层。鉴于这些类型的封装不存在此 MPLS 客户端层，因此需要替代程序和机制来提供所需的功能。接下来将详细讨论这些。8.3.1、 水平分割在 EVPN 中，MPLS 标签用于水平分割过滤以支持全活多宿主，其中入口 NVE 在封装数据包时添加与源站点对应的标签（也称为 ESI 标签）。出口 NVE 在尝试从接口转发多目标帧时检查 ESI 标签，如果标签对应于与该接口关联的相同站点标识符 (ESI)，则数据包将被丢弃。这可以防止转发循环的发生。由于 VXLAN 和 NVGRE 封装不包括 ESI 标签，因此必须为这些封装设计其他执行水平分割过滤功能的方法。当使用 VXLAN（或 NVGRE）封装时，建议使用以下方法进行水平分割过滤。每个 NVE 都跟踪与其共享多宿主 ES 的其他 NVE 关联的 IP 地址。当 NVE 收到来自Overlay网络的多目标帧时，它会检查隧道头中的源 IP 地址（对应于入口 NVE）并在连接到与入口共享的 ES 的所有本地接口上过滤掉该帧NVE。使用这种方法，入口 NVE 需要在本地执行复制到所有直接连接的以太网段（无论 DF 选举状态如何），用于所有来自访问接口（即来自主机）的洪泛流量入口。这种方法被称为“本地偏差”，其优点是每个 NVE 只需要使用一个 IP 地址来进行水平分割过滤，而不是每个 NVE 每个以太网段需要一个 IP 地址。为了允许在同一组多宿主 PE 设备之间正确运行水平分割过滤，PE 设备与 MPLS over GRE 封装的混合运行来自 [RFC7432] 的程序，一方面用于水平分割过滤和 VXLAN/NVGRE不得配置在指定以太网段上的另一个上运行本地偏置程序的封装。8.3.2、 别名和备份路径VXLAN/NVGRE 封装的别名和备份路径过程与 MPLS 的非常相似。在 MPLS 的情况下，对应 ES 运行在 All-Active 多宿主中时，每个 EVI 的以太网 A-D 路由用于 Aliasing，当相应 ES 运行在 Single-Active 多宿主时，相同的路由用于 Backup Path。在 VXLAN/NVGRE 的情况下，相同的路由用于别名和备份路径，不同之处在于每个 EVI 路由的以太网 A-D 中的以太网标签和 VNI 字段的设置如第 5.1.3 节所述。8.3.3、 未知单播流量指定在 EVPN 中，当入口 PE 使用入口复制将未知单播流量泛洪到出口 PE 时，入口 PE 使用不同的 EVPN MPLS 标签（与用于已知单播流量的标签不同）来识别此类 BUM 流量。出口 PE 使用此标签来识别此类 BUM 流量，从而为全活多宿主站点应用 DF 过滤。在没有未知单播流量指定和启用未知单播泛洪的情况下，在以下条件下可能会出现临时复制流量到全活多宿主站点：主机 MAC 地址由出口 PE 获知并公布到入口 PE；然而，MAC Advertisement 尚未被入口PE 接收或处理，导致主机MAC 地址在入口PE 上未知，但在出口PE 上已知。因此，当发往该主机 MAC 地址的数据包到达入口 PE 时，它通过入口复制将其泛洪到所有出口 PE，并且由于出口 PE 知道它们，因此将多个副本发送到All-Active 多宿主站点。应该注意的是，这种瞬时数据包复制仅在以下情况下发生：a) 目标主机通过 All-Active 冗余模式进行多宿主，b) 在网络中启用了未知单播的泛洪，c) 使用入口复制，以及 d)目标主机在通过 BGP EVPN 通告获知主机 MAC 地址之前到达入口 PE。如果希望避免这种瞬态重复数据包的发生（尽管可能性很小），则需要在这些 PE 之间使用 VXLAN-GPE 封装，并且入口 PE 需要设置 BUM 流量位（B 位）[VXLAN -GPE] 表示这是入口复制的 BUM 流量。9、 支持组播EVPN IMET 路由用于发现与用于基于 VLAN 的服务的指定 EVI（例如，指定的 VNI）和用于 VLAN 感知绑定服务的指定 <EVI, VLAN> 相关联的端点之间的组播隧道。该路由的所有字段都按照第 5.1.3 节中的描述进行设置。始发路由器的 IP 地址字段设置为 NVE 的 IP 地址。该路由使用 PMSI 隧道属性进行标记，该属性用于对要使用的组播隧道类型以及组播隧道标识符进行编码。根据第 5.1.1 节，通过添加 BGP 封装扩展团体对隧道封装进行编码。例如，PMSI隧道属性可以指示组播隧道是协议无关组播-稀疏模式（PIM-SM）类型；而 BGP 封装扩展团体可能指示该隧道的封装类型为 VXLAN。[RFC6514] 中定义的以下隧道类型可用于 VXLAN/NVGRE 的 PMSI 隧道属性：+ 3 - PIM-SSM 树 + 4 - PIM-SM 树 + 5 - BIDIR-PIM 树 + 6 - 入口复制在 VXLAN 和 NVGRE 封装与本地分配的 VNI 的情况下，就像在 [RFC7432] 中一样，每个 PE 必须向 EVPN 实例中的其他 PE 通告一条 IMET 路由，用于它使用的组播隧道类型（即入口复制、PIM-SM 、PIM-SSM 或 BIDIR-PIM 隧道）。然而，对于全局分配的 VNI，每个 PE 必须向 EVPN 实例中的其他 PE 通告一条 IMET 路由以用于入口复制或 PIM-SSM 隧道，并且它们可以为 PIM-SM 或 BIDIR-PIM 隧道通告 IMET 路由。在 PIM-SM 或 BIDIR-PIM 隧道的情况下，PE 不需要 IMET 路由中的信息来建立这些隧道。在组播隧道是树的场景中，Inclusive 和 Aggregate Inclusive 变体都可以使用。在前一种情况下，组播树专用于 VNI。而在后者中，组播树在多个 VNI 之间共享。对于基于 VNI 的服务，聚合包含模式是通过让 NVE 通告具有不同 RT（每个 VNI 一个）但具有在 PMSI 隧道属性中编码的相同隧道标识符的多个 IMET 路由来实现的。对于 VNI 感知绑定服务，聚合包含模式是通过让 NVE 通告多个 IMET 路由来实现的，这些 IMET 路由具有在以太网标签字段中编码的不同 VNI，但具有在 PMSI 隧道属性中编码的相同隧道标识符。10、 数据中心互连 (DCI)对于 DCI，在 MPLS/IP 核心网络上连接运行 evpn-overlay（如此处所述）的数据中心时，会考虑以下两个主要场景：- 场景 1：DCI 使用 GW- 场景 2：DCI 使用 ASBR以下两个小节描述了这些场景中的每一个的操作。10.1、 DCI 使用 GW这是通过 WAN 互连数据中心的典型场景。在这种情况下，EVPN 路由在每个 GW 中终止和处理，MAC/IP 路由总是从 DC 到 WAN 重新通告，但从 WAN 到 DC，如果未知 MAC 地址（和默认 IP 地址）被重新通告，则它们不会重新通告在 NVE 中使用。在这种情况下，每个 GW 为每个 EVI 维护一个 MAC-VRF（和/或 IP-VRF）。这种方法的主要优点是当使用默认IP路由和未知MAC路由时，NVE不需要维护来自任何远程数据中心的MAC和IP地址；也就是说，他们只需要维护自己DC本地的路由。当使用默认 IP 路由和未知 MAC 路由时，来自 NVE 的任何未知 IP 和 MAC 数据包都会转发到维护所有 VPN MAC 和 IP 路由的 GW。这种方法显着减少了 NVE 的 MAC-VRF 和 IP-VRF 的大小。此外，由于与故障相关的 BGP 路由（例如大量撤销消息）不需要一直传播到远程远程 DC 中的 NVE。[DCI-EVPN-OVERLAY]的第3.4节详细描述了这种方法。10.2、 使用 ASBR 的 DCI这种方法可以被认为是第一种方法的对立面。它有利于简化 DCI 设备而不是 NVE，因此需要在 NVE 上维护更大的 MAC-VRF（和 IP-VRF）表；而 DCI 设备不需要维护任何 MAC（和 IP）转发表。此外，DCI 设备不需要终止和处理与多宿主相关的路由，而是中继这些消息以建立端到端标签交换路径 (Label Switched Path，LSP)。换句话说，这种方法中的 DCI 设备的操作类似于 ASBR 的 AS 间选项 B（参见 [RFC4364] 的第 10 节）。这要求使用本地分配的 VNI，就像下游分配的 MPLS VPN 标签一样，在所有实际用途中，VNI 的功能类似于 24 位 VPN 标签。这种方法同样适用于采用 MPLS 封装的数据中心（或操作员以太网）。在跨域选项B中，当ASBR通过内部BGP（iBGP）从其DC接收到一条EVPN路由并将其重新通告给其他ASBR时，它通过向自身重新写入BGP下一跳来重新通告EVPN路由，从而丢失发起通告的 PE 的身份。BGP 下一跳的这种重写对 EVPN 大规模撤销路由（每个 ES 的以太网 A-D）及其过程产生不利影响。但是，它不会影响 EVPN 别名机制/过程，因为当通告别名路由（每个 EVI 的以太网 AD）时，接收 PE 首先将指定 EVI 的 MAC 地址解析为其相应的 <ES, EVI>，然后，它将 <ES, EVI> 解析为多个路径（及其相关的下一跳），通过这些路径可以到达 <ES, EVI>。由于别名和 MAC 路由都基于每个 EVI 进行通告，并且它们使用相同的 RD 和 RT（每个 EVI），因此接收 PE 可以基于每个 BGP 路径（例如，每个始发 PE）将它们关联在一起.因此，它可以执行递归路由解析，例如，MAC 可通过 <ES, EVI> 到达，而后者又可通过一组 BGP 路径到达；因此，MAC 可以通过一组 BGP 路径到达。由于基于per-EVI，MAC路由和对应的Aliasing路由的关联是固定的，由同一个RD和RT决定；当这些路由通过 ASBR 时重写这些路由的 BGP 下一跳时没有歧义。也就是说，接收 PE 可能会从单个下一跳（单个 ASBR）接收到同一个 EVI 的多个别名路由，并且它仍然可以创建多个通往该 <ES, EVI> 的路径。但是，当源PE对应的BGP下一跳地址被改写时，大量撤销路由（Ethernet AD per ES）与其对应的MAC路由之间的关联不能基于它们的RD和RT，因为mass的RD撤销路由与MAC路由不同。因此，ASBR 和接收 PE 所需的功能取决于是否发起批量撤销路由以及是否需要处理该路由的路由解析歧义。以下两个小节描述了 ASBR 和接收 PE 所需的功能，具体取决于 NVE 是驻留在虚拟机管理程序中还是驻留在 ToR 交换机中。10.2.1、 具有单归属 NVE 的 ASBR 功能如第 7.1 节所述，当 NVE 驻留在虚拟机管理程序中时，不存在多宿主；因此，始发 NVE 无需为每个 ES 发送以太网 A-D 或每个 EVI 路由发送以太网 A-D。然而，如第 7 节所述，为了使单归属入口 NVE 在与附加到指定 ES 的多归属出口 NVE 交互时能够利用快速收敛、别名和备份路径，单归属 NVE 应该能够接收和处理每个 ES 的以太网 AD 和每个 EVI 路由的以太网 AD。这些路由的处理将在下一节中描述。10.2.2、 具有多宿主 NVE 的 ASBR 功能当 NVE 驻留在 ToR 交换机中并在多宿主冗余模式下运行时，如第 8 节所述，需要发端多宿主 NVE 发送每个 ES 路由的以太网 AD（用于大规模撤销）和每个 EVI 的以太网 AD路线（用于别名）。如上所述，当远程 NVE 在不同的 ASBR 中接收每个 ES 路由的以太网 AD 时，ASBR 对 BGP 下一跳的重写会产生歧义，因为接收 NVE 无法将该路由与该 ES 通告的 MAC/IP 路由相关联。相同的起源 NVE。这种模糊性通过在不同的 AS 中接收 NVE 抑制了每个 ES 的大规模撤销功能。例如，考虑一个CE多宿主到PE1和PE2的场景，这些PE通过ASBR1然后ASBR2连接到远程PE3。此外，请考虑PE1 从CE1 接收M1 而不是PE2。因此，PE1 为每个 ES1 通告以太网 A-D，每个 EVI1 和 M1 通告以太网 A-D；而 PE2 只为 ES1 通告以太网 A-D，为每个 EVI1 通告以太网 A-D。ASBR1 接收所有这五个通告并将它们传递给 ASBR2（将其自身作为 BGP 下一跳）。反过来，ASBR2 将它们传递到远程 PE3，并将其自身作为 BGP 下一跳。PE3 收到这 5 条路由，它们都具有相同的 BGP 下一跳（即 ASBR2）。此外，PE3收到的每ES路由的两条以太网A-D具有相同的信息，即相同的ESI和相同的BGP下一跳。尽管这两条路由都由 PE3 中的 BGP 进程维护（因为它们具有不同的 RD，因此被视为不同的 BGP 路由），但 L2 路由表 (L2 RIB) 中仅使用其中之一的信息。图 3：跨域选项 B现在，当 PE2 和 CE 之间的 AC 发生故障并且 PE2 为每个 ES 路由发送以太网 AD 的网络层可达性信息 (Network Layer Reachability Information，NLRI) 撤销，并且该撤销被 PE3 传播和接收时，PE3 中的 BGP 进程将删除相应的 BGP路线;但是，它不会从 L2 路由表 (L2 RIB) 中删除相关信息（即 ESI 和 BGP 下一跳），因为它仍然具有每个 ES 路由（源自 PE1）的其他以太网 A-D 具有相同信息。这就是为什么在使用 AS 间选项 B 进行 DCI 时，批量撤销机制不起作用的原因。但是，如前所述，别名功能起作用，“每个 EVI 的批量撤销”也起作用（这与撤销与别名，即每个 EVI 路由的以太网 AD）。在上例中，PE3 收到两条具有相同BGP 下一跳（ASBR2）但RD 不同的Aliasing 路由。Aliasing 路由之一与通告的 MAC 路由 (M1) 具有相同的 RD。PE3 收到两条 Aliasing 路由后，遵循 [RFC7432] 中规定的路由解析程序；也就是说，它将 M1 解析为 <ES, EVI1>，然后将 <ES, EVI1> 解析为一个 BGP 路径列表，其中包含两条路径以及相应的 VNI/MPLS 标签（一个与 PE1 相关联，另一个与PE2)。需要注意的是，即使两条路径都是由同一个 BGP 下一跳（ASRB2）通告的，接收端 PE3 也可以正确处理它们。因此，M1 可通过两条路径到达。这为 M1 创建了两条端到端 LSP，从 PE3 到 PE1，从 PE3 到 PE2，这样当 PE3 想要转发目的地为 M1 的流量时，它可以在两条 LSP 之间进行负载均衡。尽管 [RFC7432] 中没有明确提到具有相同 BGP 下一跳的别名路由的路由解析，但这是预期的操作；因此，在此详细说明。当PE2和CE之间的AC发生故障，PE2发送每个EVI路由的以太网A-D的NLRI撤销，并且这些撤销被PE3传播和接收时，PE3删除Aliasing路由并更新路径列表；即删除PE2对应的路径。因此，指向该路径列表的 <ES, EVI> 的所有相应 MAC 路由现在将具有更新的路径列表，其中包含与 PE1 关联的单个路径。这个动作可以被认为是per-EVI级别的大规模撤销。per-EVI级别的大规模撤销比per-ES级别的大规模撤销具有更长的收敛时间；然而，它比在每个 MAC 基础上完成撤销时的收敛时间要快得多。如果 PE 与指定的 ES 分离，那么，除了撤销其先前公布的每个 ES 路由的以太网 A-D 之外，它还必须撤销其先前为该 ES 公布的每个 EVI 路由的以太网 A-D。对于通过一个或多个 EVPN 跨域选项 B ASBR 与撤销 PE 分隔的远程 PE，每个 ES 路由撤销以太网 A-D 是不可操作的。然而，远程 PE 能够将每个 EVI 路由的先前通告的以太网 A-D 与撤销 PE 为该 <ES, EVI, BD> 通告的任何 MAC/IP 通告路由相关联。因此，当它收到每个 EVI 路由的以太网 A-D 撤销时，它应该删除撤销的 PE 作为与该 <ES, EVI, BD> 关联的所有 MAC 地址的下一跳。在前面的例子中，当PE2和CE之间的AC发生故障时，PE2将根据ES和EVI路由撤销其以太网A-D。当 PE3 收到每个 EVI 路由的以太网 A-D 的撤销时，它删除 PE2 作为与相应 <ES, EVI, BD> 关联的所有 MAC 地址的有效下一跳。因此，该 <ES, EVI, BD> 的所有 MAC 下一跳现在将具有单个下一跳，即。LSP 到 PE1。总之，可以看出别名（和备份路径）功能应该像 AS 间选项 B 一样工作，而不需要 ASBR 或 PE 中的任何附加功能。然而，对于AS间选项B，批量撤销功能从per-ES模式回退到per-EVI模式。也就是说，从同一AS接收到大量撤销路由的PE对每个ES路由的以太网A-D采取行动；而从不同 AS 接收大量撤销路由的 PE 对每个 EVI 路由的以太网 A-D 采取行动。11、 安全考虑本文档使用基于 IP 的隧道技术来支持数据平面传输。因此，这些隧道技术的安全考虑适用。本文档定义了对 VXLAN [RFC7348] 和 NVGRE 封装 [RFC7637] 的支持。这些 RFC 的安全考虑适用于本文档的数据平面方面。与 [RFC5512] 一样，用于形成封装标头、选择隧道类型或为特定负载类型选择特定隧道的信息的任何修改都可能导致用户数据包被错误路由、错误传送和/或掉了。更广泛地说，使用 BGP 传输 IP 可达性信息的安全考虑在[RFC4271]和 [RFC4272] 中讨论，并且同样适用于本文档中描述的扩展。12、 IANA 考虑本文档在“BGP 隧道封装属性隧道类型”注册表中注册了以下内容。值 名称 8 VXLAN 封装 9 NVGRE 封装 10 MPLS 封装 11 MPLS GRE 封装 12 VXLAN GPE 封装13、 参考文献13.1、 规范参考[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>. [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, <https://www.rfc-editor.org/info/rfc5512>. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <https://www.rfc-editor.org/info/rfc4023>. [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>.13.2、 参考资料[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>. [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, <https://www.rfc-editor.org/info/rfc7364>. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, <https://www.rfc-editor.org/info/rfc7365>. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>. [TUNNEL-ENCAP] Rosen, E., Ed., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", Work in Progress draft-ietf-idr-tunnel-encaps-09, February 2018. [DCI-EVPN-OVERLAY] Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi, A., and J. Drake, "Interconnect Solution for EVPN Overlay networks", Work in Progress, draft-ietf-bess-dci-evpn-overlay-10, March 2018. [EVPN-GENEVE] Boutros, S., Sajassi, A., Drake, J., and J. Rabadan, "EVPN control plane for Geneve", Work in Progress, draft-boutros-bess-evpn-geneve-02, March 2018. [VXLAN-GPE] Maino, F., Kreeger, L., Ed., and U. Elzur, Ed., "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-05, October 2017. [GENEVE] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-06, March 2018. [IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q.致谢作者要感谢 Aldrin Isaac、David Smith、John Mullooly、Thomas Nadeau、Samir Thoria 和 Jorge Rabadan 的宝贵意见和反馈。作者还要感谢 Jakob Heitz 对第 10.2 节的贡献。
-
发表了文章 2023-03-04
奥拓”？应用层流量优化 (ALTO) 要求
RFC6708：Application-Layer Traffic Optimization (ALTO) Requirements，September 2012梗概许多 Internet 应用程序用于访问资源，例如在不同主机上的多个等效副本中可用的信息或服务器进程。这包括但不限于点对点文件共享应用程序。应用层流量优化 (Application-Layer Traffic Optimization，ALTO) 的目标是为应用程序提供指导，这些应用程序必须从一组能够提供所需资源的候选主机中选择一个或多个主机。该指南应基于影响主机之间数据传输性能和效率的参数，例如拓扑距离。最终目标是提高应用程序的性能或体验质量，同时降低底层网络基础设施的利用率。本文档列举了指定、评估或比较协议和实现的要求。本备忘录的状态本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6708。版权声明版权所有 (c) 2012 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍应用层流量优化 (ALTO) 的动机在 ALTO 问题陈述 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 中有所描述。ALTO 的目标是提供可以帮助点对点(peer-to-peer，P2P) 应用程序在对等体选择方面做出更好决策的信息。但是，ALTO 也可能对非 P2P 应用程序有用。例如，客户端-服务器应用程序的客户端可以使用 ALTO 提供的信息来选择多个服务器或信息副本之一。作为另一个示例，ALTO 信息可用于选择 NAT 穿越所需的媒体中继。这些明智决策的目标是提高应用程序的性能或体验质量，同时降低底层网络基础设施的利用率。通常，由于复杂性或因为它基于网络拓扑信息、网络运营成本或网络策略，相应的网络提供商不想详细披露。提供 ALTO 服务的功能实体不参与实际的用户数据传输，即它们不实现中继用户数据的功能。这些功能实体可以放置在各种物理节点上，例如，在专用服务器上，作为路由器中的辅助进程，P2P 应用程序的“跟踪器”或“超级对等体”等。2、 术语和架构框架2.1、 需求符号本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是解释为 [RFC2119] 中的描述。2.2、 ALTO术语本文档使用以下 ALTO 相关术语，这些术语在 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 中定义：Application，Peer，P2P，Resource，Resource Identifier，Resource Provider，Resource Consumer，Transport Address，Overlay Network，Resource Directory，ALTO Service，ALTO Server，ALTO Client，ALTO Query，ALTO Response，ALTO Transaction，Local Traffic，Peering Traffic，Transit Traffic，Application Protocol，ALTO Client Protocol，和 Provisioning Protocol。此外，将使用以下附加术语：Host-Group Descriptor/主机组描述符用于描述一个或多个 Internet 主机（例如寻求 ALTO 指导的资源消费者，或一个或多个候选资源提供者）及其在网络拓扑中的位置的信息。可以有多种不同类型的主机组描述符，例如，单个 IP 地址、包含主机的地址前缀或地址范围或自治系统 (Autonomous System，AS) 编号。不同的主机组描述符类型可能提供不同级别的详细信息。根据系统架构的不同，这可能会影响 ALTO 能够提供的指导质量、是否可以汇总建议，以及可能会向其他方披露多少有关用户的隐私敏感信息。Rating Criterion/评级标准定义“优于随机同行选择”中“更好”的条件或关系，这是ALTO的最终目标。示例可能包括“主机的互联网访问不受基于流量的收费（统一费率）”或“低拓扑距离”。一些评级标准，例如“低拓扑距离”，需要包括一个参考点，例如“距给定资源消费者的低拓扑距离”。该参考点可以通过主机组描述符来描述。Host-Characteristics Attribute/主机特性属性主机的属性，主机组描述符除外。可以根据一个或多个评级标准对其进行评估。该信息可以存储在 ALTO 服务器中并通过 ALTO 协议传输。主机特性属性的一个示例是一个数据字段，该字段指示主机的 Internet 访问是否需要按量计费（统一费率）。Target-Aware Query Mode/目标感知查询模式在这种操作模式下，当所需资源和一组候选资源提供者已知时，ALTO 客户端执行 ALTO 查询，即在分布式哈希表 (Distributed Hash Table，DHT) 查找后，查询到资源目录等。为此，ALTO 客户端将主机组描述符列表和可选的一个或多个评级标准传输到 ALTO 服务器。ALTO 服务器根据指定的标准或默认标准评估主机组描述符。它将这些主机组描述符的列表返回给 ALTO 客户端，该列表根据评级标准进行排序和/或通过主机特征属性进行丰富。Target-Independent Query Mode/目标无关查询模式在这种操作模式下，ALTO 查询是提前或定期执行的，以获得全面的指导。ALTO 客户端在 ALTO 查询中指示所需的主机特征属性。ALTO 服务器用一个列表回答所有已知的主机组描述符（可能受服务器策略的影响）所需的主机特征属性。这些列表将在本地缓存并在稍后访问资源时进行评估。2.3、 ALTO 的架构框架ALTO 实现有多种架构选择。指定或强制要求一种特定的架构超出了本文档的范围。除了术语（参见 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 的第 2 节和本文档的第 2.2 节），[RFC5693] 还提供了一个图表，该图给出了这些组件之间协议交互的高级概述。本文档逐条列出了对以下组件的要求：ALTO 客户端协议、ALTO 服务器发现机制、主机组描述符、评级标准和主机特性属性。此外，还提出了有关整体架构的要求，尤其是在安全和隐私问题方面。请注意，此类协议和机制的详细规范超出了本文档的范围。事实上，本文档甚至没有假设这些组件中的每一个都只有一个单独的规范。但是，本文档列举了在指定、评估或比较协议和实现时要考虑的 ALTO 要求。3、 ALTO 要求3.1、 ALTO 客户端协议3.1.1、 一般要求要求AR-1：ALTO 服务由一台或多台 ALTO 服务器提供。ALTO 客户可能会询问它，以寻求选择合适的资源提供商的指导。ALTO 客户端和 ALTO 服务器必须实现 ALTO 客户端协议。ALTO 客户端协议必须能够将 ALTO 查询从 ALTO 客户端传输到 ALTO 服务器，并且它必须能够将相应的 ALTO 回复从 ALTO 服务器传输到 ALTO 客户端。ALTO 客户端协议的详细规范超出了本文档的范围。事实上，本文档甚至没有假设只有一个协议规范。但是，本文档列举了 ALTO 的要求，在指定、评估或比较协议和实现时要考虑这些要求。要求AR-2：ALTO 客户端协议必须提供足够的操作和管理支持机制，如 RFC 5706 [RFC5706] 中所述。3.1.2、 主机组描述符支持ALTO 指南基于对多个资源提供者或资源提供者组的评估，并考虑一个或多个评级标准。资源提供者或资源提供者组通过主机组描述符来表征。要求AR-3：ALTO 客户端协议必须支持使用多种主机组描述符类型。要求AR-4：ALTO 客户端和 ALTO 服务器必须清楚地识别在 ALTO 查询或响应中发送的每个主机组描述符的类型。ALTO 协议规范必须提供适当的协议元素。要求AR-5：ALTO 客户端协议必须支持主机组描述符类型“IPv4 地址前缀”和“IPv6 地址前缀”。它们可用于指定一台主机的 IP 地址，或包含所有相关主机的 IP 地址范围（以无类别域间路由 (Classless Inter-Domain Routing，CIDR) 表示法）。要求AR-6：ALTO 客户端协议必须是可扩展的，以便将来支持其他主机组描述符类型。ALTO 客户端协议规范必须定义适当的程序来添加新的主机组描述符类型，例如，通过建立 IANA 注册。要求AR-7：对于除“IPv4 地址前缀”和“IPv6 地址前缀”以外的主机组描述符类型，主机组描述符类型标识必须通过引用可用于转换主机组描述符的工具来补充这种类型的 IPv4/IPv6 地址前缀，例如，通过映射表或算法。要求AR-8：将其他主机组描述符类型映射到 IPv4/IPv6 地址前缀的协议功能应该被设计和指定为 ALTO 客户端协议的一部分，并且相应的地址映射信息应该由想要的同一实体提供在 ALTO 客户端协议中使用这些主机组描述符。然而，ALTO 服务器或 ALTO 客户端也可以发送对外部映射工具的引用，例如，要通过替代机制获得的转换表。前两个要求的基本原理：主机组描述符的首选类型是 IPv4 和 IPv6 前缀。但是，在某些情况下，一方可能更喜欢使用另一种类型，例如 AS 号码。通常，寻求 ALTO 指导的应用程序使用 IP 地址，例如，在建立连接时。理解基于其他主机组描述符类型的指导信息，即从这些其他类型映射到 IP 前缀并返回，可能是一项重要的任务。因此，在一方可以使用其他主机组描述符类型之前，他们必须提供到 IP 前缀的映射机制。要求AR-9：ALTO 客户端协议规范必须定义可由 ALTO 服务器使用的机制，以指示 ALTO 客户端使用的主机组描述符是不受支持的类型，或者指示的映射机制无法使用。要求AR-10：ALTO 客户端协议规范必须定义可由 ALTO 客户端使用的机制，以指示 ALTO 服务器使用的主机组描述符是不受支持的类型，或者指示的映射机制无法使用。3.1.3、 评级标准支持要求AR-11：ALTO 客户端协议规范必须定义可用于表达和评估“相对运营商偏好”的评级标准。这是一个相对度量，即它不与任何度量单位相关联。根据此标准，首选评级表明应用程序应优先选择相应的候选资源提供者，而不是其他具有较低首选评级的资源提供者（除非来自非 ALTO 来源的信息建议不同的选择，例如表明路径当前拥塞的传输尝试）。ALTO 服务器的运营商不必公开评级是如何以及基于哪些数据实际计算的。示例可能是：对等体或传输流量的成本、网络内的流量工程和其他策略。要求AR-12：ALTO 客户端协议必须是可扩展的，以便将来支持其他评级标准类型。ALTO 客户端协议规范必须定义适当的程序来添加新的评级标准类型，例如，通过建立 IANA 注册。要求AR-13：ALTO 客户端协议规范不得定义与瞬时网络拥塞状态密切相关的评级标准，即评级标准的主要目的是作为既定拥塞控制策略的替代方案，例如使用基于 TCP 的传输。要求AR-14：使用 ALTO 引导的应用程序不得仅依赖 ALTO 引导以避免导致网络拥塞。相反，他们必须使用其他适当的方式，例如基于 TCP 的传输，以避免造成过度拥塞。先前要求的基本原理： ALTO 的一个设计假设是主机特性属性可以接受，这些属性在 ALTO 服务器中存储和处理以提供指导，但很少更新。典型的更新间隔可能比典型的网络层数据包往返时间 (round-trip time，RTT) 长几个数量级。因此，ALTO 不能替代类似 TCP 的拥塞控制机制。要求AR-15：在目标独立查询模式下，ALTO 查询消息应该允许 ALTO 客户端表达应该返回哪些主机特征属性。要求AR-16：在目标感知查询模式下，ALTO 查询消息应该允许 ALTO 客户端表达服务器应该考虑哪些评级标准，以及它们与最终将使用指导。相应的 ALTO 响应消息应该允许 ALTO 服务器表达在生成响应时考虑了哪些评级标准。要求AR-17：ALTO 客户端协议规范必须定义可由 ALTO 客户端和 ALTO 服务器使用的机制，以指示另一方使用的评级标准是不受支持的类型。3.1.4、 实体的放置和操作的时间关于 ALTO 客户端的放置，存在几种操作模式：ALTO 操作的一种模式是 ALTO 客户端可以直接嵌入到资源消费者中，即最终将向/从所选资源提供者发起数据传输以访问所需资源的应用协议实体。例如，ALTO 客户端可以集成到 P2P 应用程序的对等体中，该应用程序使用分布式算法（例如“查询泛洪”）进行资源发现。另一种操作方式是将ALTO客户端集成到第三方中，比如资源目录。考虑到各自的资源消费者，该第三方可以发出 ALTO 查询以征求对潜在资源提供者的偏好。例如，可以将 ALTO 客户端集成到基于跟踪器的 P2P 应用程序的跟踪器中，以便代表联系跟踪器的对等体请求 ALTO 指导。要求AR-18：ALTO 客户端协议必须支持 ALTO 客户端直接嵌入资源消费者的操作模式。要求AR-19：ALTO 客户端协议必须支持 ALTO 客户端嵌入第三方的操作模式。该第三方代表资源消费者执行查询。要求AR-20：ALTO 客户端协议的设计方式必须确保 ALTO 服务可以由不是底层 IP 网络运营商的实体提供。要求AR-21：ALTO 客户端协议的设计方式必须使不同提供商运营的 ALTO 服务的不同实例可以共存。要求AR-22：ALTO 客户端协议规范必须至少指定一种查询模式，目标感知或独立于目标的查询模式。请注意，此需求文档并不假设只有一个协议规范。要求AR-23：ALTO 客户端协议规范应该指定目标感知和目标独立查询模式。如果 ALTO 客户端协议规范指定了多个查询模式，则必须将这些模式中的至少一种定义为 REQUIRED 以供 ALTO 客户端和 ALTO 服务器实现。此外，它必须为 ALTO 客户端和 ALTO 服务器之间的协商指定适当的协议机制，使用哪种查询模式。要求AR-24：ALTO 客户端协议应该支持 ALTO 事务中的版本编号、TTL（time-to-live，生存时间）属性和/或类似机制，以便为缓存启用时间有效性检查，并启用对获得的多个建议的比较通过再分配。要求AR-25：ALTO 客户端协议应该允许 ALTO 服务器将有关适当重用模式的信息添加到其 ALTO 响应中。重用可能包括将 ALTO 响应重新分发给其他方，以及在资源目录中使用相同的 ALTO 信息来改进在 ALTO 响应的指定生命周期内对不同资源消费者的响应。ALTO 服务器应该能够表达** 不应发生重复使用。** 重用适用于特定的“目标受众”，即由主机组描述符列表明确定义的一组资源消费者。ALTO 服务器可以在 ALTO 响应中指定一个“目标受众”，它只是已知实际“目标受众”的一个子集，例如，如果运营商政策要求。** 重用适用于将发送（或导致第三方代表它发送）相同 ALTO 查询（即，具有相同的查询参数，除了资源使用者 ID，如果适用）的任何资源使用者ALTO服务器。** 重用适用于将向任何资源消费者发送（或导致第三方代表它发送）相同 ALTO 查询（即，具有相同的查询参数，除了资源消费者 ID，如果适用）的任何资源消费者与此 ALTO 服务器一起发现的其他 ALTO 服务器（使用 ALTO 发现机制）。** 重用适用于将向任何资源消费者发送（或导致第三方代表它发送）相同 ALTO 查询（即，具有相同的查询参数，除了资源消费者 ID，如果适用）的任何资源消费者全网ALTO服务器。要求AR-26：ALTO 客户端协议必须支持 ALTO 事务的传输，即使 ALTO 客户端位于网络地址转换器 (network address translator，NAT) 后面的私有地址域中。有不同类型的 NAT，参见 [RFC4787] 和 [RFC5382]。3.1.5、 协议扩展性要求AR-27：ALTO 客户端协议必须支持以无中断、向后兼容的方式添加协议扩展。要求AR-28：ALTO 客户端协议必须包括协议版本支持，以便清楚地区分不兼容的协议版本。3.1.6、 错误处理和过载保护要求AR-29：ALTO 客户端协议必须使用拥塞感知传输，例如，通过使用 TCP。要求AR-30：ALTO 客户端协议规范必须为 ALTO 服务器指定机制，以通知客户端即将发生或正在发生的过载情况，或如何利用底层协议层提供的适当机制。这些机制必须为服务器提供以下所有选项：* 终止与客户端的对话，* 将客户端重定向到另一个 ALTO 服务器，以及* 请求客户端限制其查询率。特别是，一种简单的节流形式是让 ALTO 服务器用错误消息回答查询，建议客户端稍后重试查询（例如，使用协议功能，如 HTTP 的 Retry-After 报文头（[RFC2616]，第 14.37 节））。另一个简单的选择是用所需的信息实际回答查询，但添加一个指示，表明 ALTO 客户端不应在指定的时间段过去之前向该 ALTO 服务器发送进一步的查询。要求AR-31：ALTO 客户端协议规范必须为 ALTO 服务器指定机制，以通知客户端由于技术问题或系统维护而无法回答查询，或者如何利用底层协议层提供的适当机制。这些机制必须为服务器提供以下所有选项：* 终止与客户端的对话，* 将客户端重定向到另一个 ALTO 服务器，以及* 请求客户端稍后重试查询。注意：上述协议机制的存在并不意味着ALTO服务器在面临过载、技术问题或维护情况时必须分别使用它们。在这种情况下，某些服务器可能无法使用它们，或者它们可能更愿意简单地拒绝连接或根本不发送任何答案。3.2、 ALTO 服务器发现ALTO 客户端协议由一个或多个 ALTO 服务器发现机制支持，ALTO 客户端可以使用这些机制来确定一个或多个 ALTO 服务器，ALTO 请求可以发送到这些服务器。本节列举了 ALTO 客户端的要求，以及 ALTO 服务器发现机制要满足的一般要求。要求AR-32：ALTO 服务器发现机制必须支持允许嵌入在资源消费者中的 ALTO 客户端使用与 ALTO 客户端兼容的 ALTO 协议版本找到一个或多个可以提供适合资源消费者的 ALTO 指导的 ALTO 服务器的功能。这种操作模式称为“资源消费者发起的ALTO服务器发现”。要求AR-33：ALTO 服务器发现机制必须支持允许嵌入资源目录中的 ALTO 客户端并代表远程资源消费者执行第三方 ALTO 查询的功能，以找到一个或多个可以提供适用于以下情况的 ALTO 指导的 ALTO 服务器各自的资源消费者，使用与 ALTO 客户端兼容的 ALTO 协议版本。这种操作模式称为“第三方ALTO服务器发现”。要求AR-34：ALTO 客户端必须能够执行资源消费者发起的 ALTO 服务器发现，即使它们位于 NAT 后面。要求AR-35：ALTO 客户端必须能够执行第三方 ALTO 服务器发现，即使它们位于 NAT 之后。要求AR-36：ALTO 客户端必须能够执行第三方 ALTO 服务器发现，即使将代表 ALTO 查询发送的资源消费者位于 NAT 之后。要求AR-37：ALTO 服务器发现机制应该利用现有的协议或机制，例如基于 DNS、DHCP 或 PPP 的自动配置等。具有广泛适用性的单一机制应该优先于几种不同的机制范围更窄。要求AR-38：每个 ALTO 服务器发现机制应该能够返回多个 ALTO 服务器各自的联系信息。要求AR-39：每个 ALTO 服务器发现机制应该能够指示每个返回的 ALTO 服务器联系信息的偏好。3.3、 安全和隐私注意：以下要求要求在协议规范级别包含某些安全机制。在给定的部署场景中启用这些机制是否有意义取决于针对该特定场景的威胁分析。信息披露潜在风险分类参见5.2节。要求AR-40：ALTO 客户端协议规范必须指定 ALTO 服务器的身份验证机制或指定如何利用底层协议层提供的适当机制。要求AR-41：ALTO 客户端协议规范必须指定 ALTO 客户端的身份验证机制或指定如何利用底层协议层提供的适当机制。要求AR-42：ALTO 客户端协议规范必须指定消息加密机制或指定如何利用底层协议层提供的适当机制。要求AR-43：ALTO 客户端不需要实施机制或遵守限制其重新分发从 ALTO 服务器检索到的信息给第三方的能力的规则。要求AR-44：ALTO 客户端协议必须支持查询和响应中不同级别的详细信息，以保护用户的隐私，以确保 ALTO 服务器的运营商和同一应用程序的其他用户无法获得敏感信息。要求AR-45：ALTO 客户端协议可以包括 ALTO 客户端在请求指导以指定其想要访问的资源（例如，内容标识符）时可以使用的机制。ALTO 服务器必须提供足够的指导，即使 ALTO 客户端不想指定所需的资源（例如，保持数据字段为空）。如果 ALTO 客户端不愿意指定资源标识符（例如，P2P 文件共享中的文件名），则该机制必须设计为使得 ALTO 服务器的运营商无法轻易推断出资源标识符。要求AR-46：ALTO 客户端协议规范必须指定适当的机制来保护 ALTO 服务免受拒绝服务 (Denial-of-Service，DoS) 攻击或指定如何利用底层协议层提供的适当机制。4、 IANA 考虑本要求文件不强制要求立即采取任何 IANA 行动。但是，此类 IANA 考虑因素可能来自未来的 ALTO 规范文档，这些文档试图满足此处给出的要求。5、 安全考虑5.1、 高级安全注意事项ALTO 服务的高级安全注意事项可以在 ALTO 问题陈述文档 [RFC5693-“奥拓”？应用层流量优化 (ALTO) 问题陈述] 的“安全注意事项”部分找到。5.2、 信息披露场景不必要的信息披露是与 ALTO 相关的关键问题之一。ALTO 服务器或使用或滥用 ALTO 服务的第三方都不应以侵犯用户隐私的方式推断应用程序行为或关联数据，例如，谁使用 P2P 文件共享与谁交换哪些文件应用。此外，许多网络运营商担心可能通过 ALTO 发布的与其网络基础设施相关的信息量（例如，拓扑信息、“高级客户”数量或利用率统计信息）。本节对信息披露场景和潜在对策进行分类和讨论。5.2.1、 信息披露场景分类以下问题可能被视为 ALTO 服务器运营商的风险，具体取决于具体部署场景：(1) 向授权的 ALTO 客户端过度披露 ALTO 服务器运营商的数据。 ALTO 服务器的运营商必须将信息（例如将主机组描述符映射到主机特征属性的表）提供给服务器，从而使其能够为 ALTO 客户端提供指导。一些运营商可能认为该信息的完整集合是机密的（例如，运营商网络拓扑的详细地图），并且可能只想公开其中的一个子集或以某种方式向 ALTO 客户端公开混淆的信息。(2) 向未经授权的第三方披露 ALTO 服务器运营商的数据（例如，网络拓扑信息）。这里有三个子案例：(2a) ALTO 服务器接收并回答来自未经授权的 ALTO 客户端的查询。(2b) 未授权方窥探从 ALTO 服务器到授权 ALTO 客户端的数据传输。(2c) 授权的 ALTO 客户端有意将其从 ALTO 服务器接收到的信息转发给未授权方。(3) 通过合作ALTO客户端对ALTO服务器运营商数据的过度检索。几个授权的 ALTO 客户端可以向一个或多个 ALTO 服务器请求指导，可能在很长一段时间内多次，并在彼此之间重新分配响应（另见案例 2c）。通过汇总和关联 ALTO 响应，他们可以找到比 ALTO 服务器运营商打算披露的更多信息。以下问题可能被视为对 ALTO 客户端用户的风险，具体取决于特定的部署场景：(4) 向（授权的）ALTO服务器披露应用行为或其他用户隐私数据。 ALTO 服务器的运营商可以从 ALTO 客户端发送的 ALTO 查询推断应用程序行为（例如，P2P 文件共享应用程序中的内容标识符，或考虑建立连接的资源提供者列表）。(5) 向未经授权的第三方披露应用行为或其他用户隐私数据。这里有三个子案例：(5a) ALTO 客户端愿意直接向不受信任或恶意的 ALTO 服务器发送查询，这可能是由于 ALTO 服务器发现机制的伪造响应。(5b) 未授权方窥探从 ALTO 客户端到授权 ALTO 服务器的数据传输。(5c) 授权的 ALTO 服务器有意将其从 ALTO 客户端收到的信息转发给未授权方。(6) 一个或多个协作（见案例 5c）ALTO 服务器可能会尝试通过聚合和关联来自一个或多个 ALTO 客户端的查询来推断应用程序行为或其他用户私有数据，可能是在很长一段时间内。5.2.2、 信息披露情景讨论ALTO 服务器运营商应考虑：** 问题 (1) 可以由 ALTO 服务器操作员选择要填充到 ALTO 服务器并在响应中返回的信息的详细级别来解决。例如，通过指定比所讨论的一组主机实际使用的地址范围更广的地址范围（即，更短的前缀长度），ALTO 服务器运营商可以在一定程度上控制关于网络拓扑结构的多少信息被公开。此外，可能会在 ALTO 服务器中安装用于根据经过身份验证的 ALTO 客户端身份过滤 ALTO 响应的访问控制机制，尽管鉴于缺乏用于寻址 (2c) 和 (3) 的有效机制，这可能不是有效的，见下文。** (2a) 和 (2b) 可以通过 ALTO 客户端协议的身份验证、访问控制和加密方案来解决。然而，由于缺乏用于寻址 (2c) 和 (3) 的有效机制，加密方案的部署可能不会有效，见下文。** 简单的认证和加密方案无助于解决（2c）和（3），并且没有其他已知的简单有效的机制。复杂方法的成本，例如基于数字版权管理 (DRM) 的方法，可能很容易超过整个 ALTO 解决方案的好处；因此，它们不被视为可行的解决方案。也就是说，ALTO服务器运营商必须意识到，（2c）和（3）的发生是无法避免的；因此，他们应该只将这样的数据馈送到 ALTO 服务器，他们认为对于 (2c) 和 (3) 不敏感。ALTO 客户端的用户应该考虑：** 问题 (4) 可以并且需要通过多种方式解决：如果 ALTO 客户端嵌入在资源消费者中，则资源消费者的 IP 地址（或资源消费者前面最外层 NAT 的“公共”IP 地址）原则上会向 ALTO 服务器公开，因为它位于 IP 报文头的源地址字段中。通过使用代理，可以避免将源地址泄露给 ALTO 服务器，代价是将它们泄露给所述代理。相反，如果 ALTO 客户端嵌入在代表资源消费者发出 ALTO 请求的第三方（例如，资源目录）中，则可以向 ALTO 服务器隐藏资源消费者的确切地址，例如，通过将 IP 地址的最后几位清零或随机化。但是，存在产生不准确结果的潜在副作用。通过允许 ALTO 客户端使用与目标无关的查询模式，可以避免将候选资源提供者的地址泄露给 ALTO 服务器。在这种操作模式下，从 ALTO 服务器检索引导信息（例如，“地图”）并完全由 ALTO 客户端在本地使用，即，无需将候选资源提供者的主机位置属性发送到 ALTO 服务器。在目标感知查询模式下，ALTO 客户端可以通过混淆候选资源消费者的身份来解决这个问题，例如，通过指定比一组有问题的主机实际使用的地址范围更广的地址范围（即更短的前缀长度） ，或者通过将 IP 地址的最后几位清零或随机化。但是，存在产生不准确结果的潜在副作用。** (5a) 可以通过强制要求 ALTO 服务器发现过程作为一个整体必须安全防止欺骗来解决。注意：鉴于本文档并未强制要求特定的系统架构，因此很难指定比发现过程作为一个整体应该是安全的、可以防止欺骗的更多细节。有许多不同的架构选项，例如，具有不安全的发现机制并使用服务器证书稍后验证其响应（参见万维网中广泛使用的 DNS + HTTPS 安全模型）。因此，在这个需求阶段，发现机制本身并不强制要求能够抵御欺骗攻击。** (5b) 可以通过 ALTO 客户端协议的加密方案来解决。但是，应该针对任何特定部署场景评估工作量与收益，同时还要考虑问题 (4)、(5c) 和 (6) 的风险和解决方案。** 直接的身份验证和加密方案无助于解决 (5c) 和 (6)。但是，可以使用与问题 (4) 相同的方法来减轻潜在风险，请参见上文。这些见解反映在本文档的要求中。5.3、 ALTO 服务器发现见上面(5a)的讨论。5.4、 安全要求有关一组特定的安全要求，请参阅本文档的第 3.3 节。6、 参考文献6.1、 规范参考[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.6.2、 参考资料[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.附录 A、 贡献者本文档的早期草稿版本由 Laird Popkin 合著。附录 B、 致谢作者要感谢 Vijay K. Gurbani 和 Enrico Marocco 促成了导致创建本文档的讨论，并对其提出了宝贵的意见。作者要感谢 P2PI 和 ALTO 邮件列表成员的贡献和反馈，特别是：Richard Alimi、Jason Livingood、Michael Scharf、Nico Schwan 和 Jan Seedorf。Laird Popkin 和 Y. Richard Yang 对 P4P 工作组和耶鲁大学网络系统实验室成员的许多贡献表示感谢。P4P 工作组由 DCIA 主持。Martin Stiemerling 得到了 COAST 项目（内容感知搜索、检索和流媒体，http://www.coast-fp7.eu）的部分支持，该研究项目由欧盟委员会根据其第 7 框架计划（合同编号 248036）提供支持.此处包含的观点和结论是作者的观点和结论，不应被解释为必然代表 COAST 项目或欧盟委员会的官方政策或认可，无论明示或暗示。
-
发表了文章 2023-03-04
BMP：BGP监控协议
RFC7854：BGP Monitoring Protocol (BMP)，June 2016梗概本文档定义了 BGP 监控协议 (BGP Monitoring Protocol，BMP)，可用于监控 BGP 会话。BMP 旨在提供一个方便的接口来获取路由视图。在引入 BMP 之前，屏幕抓取是获取此类视图最常用的方法。设计目标是保持 BMP 简单、有用、易于实现和最小的服务影响。BMP 不适合用作路由协议。本备忘录的状态这是一个 Internet 标准跟踪文档。本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7854。版权声明版权所有 (c) 2016 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。本文档可能包含来自于 2008 年 11 月 10 日之前发布或公开提供的 IETF 文档或 IETF 贡献的材料。控制本材料某些版权的人可能未授予 IETF 信托允许修改此类材料的权利在 IETF 标准流程之外。如果没有从控制此类材料版权的人那里获得足够的许可，则不得在 IETF 标准流程之外修改本文档，并且不得在 IETF 标准流程之外创建其衍生作品，除非将其格式化为作为 RFC 发布或将其翻译成英语以外的语言。1、 介绍许多研究人员和网络运营商希望能够访问路由器的 BGP 路由信息库 (Routing Information Bases，RIB) 的内容以及路由器正在接收的协议更新的视图。这个监控任务无法通过标准的协议机制来实现。在引入 BMP 之前，这些数据只能通过屏幕抓取获得。BMP 持续提供对对等体方的 Adj-RIB-In 的访问，并提供某些统计数据的定期转储，监控站可将其用于进一步分析。从高层次来看，BMP 可以被认为是将在各种受监控的 BGP 会话上接收到的消息多路复用在一起的结果。1.1、 需求语言关键词“必须”、“不得”、“要求”、“应该”、“不应该”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” " 在本文档中，应按照 RFC 2119 [RFC2119] 中的描述进行解释。2、 定义Adj-RIB-In如 [RFC4271] 中所定义，“Adj-RIBs-In 包含未处理的路由信息，这些信息已由其对等体通告给本地 BGP 发言者。”这在本文档中也称为 pre-policy Adj-RIB-In。Post-Policy Adj-RIB-In将入站策略应用于 Adj-RIB-In 的结果，但在应用路由选择以形成 Loc-RIB 之前。3、 BMP操作概述3.1、 BMP 消息以下是BMP提供的消息：路由监控 (Route Monitoring，RM)用于提供从对等体方接收到的所有路由的初始转储，以及向监控站发送由对等体方通告和撤销的增量路由的持续机制。对等体Down通知（Peer Down Notification）发送的消息表示对等体会话已关闭，并带有指示会话断开原因的信息。统计报告 (Stats Reports，SR)持续的统计数据转储，监控站可以将其用作路由器中正在进行的活动的高级指示。对等体Up通知（Peer Up Notification）发送的消息表示已建立对等体会话。该消息包括关于在它们的 OPEN 消息中的对等体之间交换的数据的信息，以及关于对等体 TCP 会话本身的信息。除了在对等体方转换到已建立状态时发送之外，当 BMP 会话本身出现时，还会为处于已建立状态的每个对等体方发送对等体方通知。发起（Initiation）被监控路由器通知监控站其厂商、软件版本等的一种方式。终止（Termination）被监控路由器通知监控站其关闭BMP会话的原因的一种方式。路由镜像（Route Mirroring）被监控路由器发送接收到的消息的逐字副本的一种方式。可用于精确镜像受监控的 BGP 会话。还可用于报告格式错误的 BGP 协议数据单元 (Protocol Data Units，PDU)。3.2、 连接建立和终止BMP 在 TCP 上运行。所有选项都由受监控路由器上的配置控制。没有 BMP 消息从监控站发送到被监控的路由器。被监控的路由器可以采取措施阻止监控站发送数据（例如，通过半关闭 TCP 会话或将其窗口大小设置为 0）或者它可以默默地丢弃监控站发送的任何数据。路由器可以被一个或多个监控站监控。对于每一对（路由器和监控站），一方在 TCP 会话建立方面是主动的，而另一方是被动的。哪一方主动，哪一方被动，由配置控制。被动方配置为侦听特定 TCP 端口，而主动方配置为与该端口建立连接。如果主动方无法连接到被动方，它会定期重试连接。重试必须受到某种程度的退避。建议使用默认初始退避 30 秒和最大 720 秒的指数退避。路由器可以限制它接受连接的 IP 地址集。它应该限制它允许来自给定 IP 地址的同时连接数。这个限制的默认值应该是 1，尽管一个实现可以允许在配置中禁用这个限制。路由器还必须限制可以建立会话的速率。建议的默认设置是每分钟 2 个会话的建立速率。路由器（或管理站）可以实现检测冗余连接的逻辑，如果双方都配置为活动，则可能会发生这种情况，并且可以选择终止冗余连接。为此目的定义了终止原因代码。一旦建立连接，路由器就会通过它发送消息。没有初始化或握手阶段，只要连接建立就发送消息。如果监控站打算结束或重新发起 BMP 处理，它只会断开连接。3.3、 BMP 会话的生命周期路由器被配置为与一个或多个监控站对话 BMP。它可以配置为仅发送其 BGP 对等体的子集的监控信息。否则，假定所有 BGP 对等体都受到监控。当活动方（路由器或管理站，由配置决定）成功打开 TCP 会话（“BMP 会话”）时，BMP 会话开始。一旦会话建立起来，路由器就开始发送 BMP 消息。它必须以发送发起消息开始。随后，它通过 BMP 会话为其处于已建立状态的每个受监控 BGP 对等体发送 Peer Up 消息。随后发送封装在路由监控消息中的 Adj-RIBs-In（前策略、后策略或两者，参见第 5 节）的内容。一旦它发送了给定对等体的所有路由，它必须为该对等体发送一个 End-of-RIB 消息；当 End-of-RIB 已发送给每个受监控的对等体方时，初始表转储已完成。（一旦收集到与每个 Peer Up 消息相对应的 End-of-RIB 或 Peer Down 消息，只想收集表转储的监控站可以关闭连接。）在初始表转储之后，路由器发送封装在路由监控消息中的增量更新。根据配置，它可以定期发送统计报告甚至新的发起消息。如果任何新的受监控 BGP 对等体建立，则会发送相应的 Peer Up 消息。如果发送 Peer Up 消息的任何 BGP 对等体脱离已建立状态，则发送相应的 Peer Down 消息。当承载它的 TCP 会话因任何原因关闭时，BMP 会话结束。路由器可以在关闭会话之前发送终止消息。4、 BMP 报文格式4.1、 通用报文头以下公共报文头出现在所有 BMP 消息中。BMP 消息中的其余数据取决于公共头中的消息类型字段。Version：版本（1 字节），表示 BMP 版本。对于本规范中定义的所有消息，这都设置为“3”。（本文档的草稿版本使用了“1”和“2”。）版本 0 是保留的，不得发送。Message Length：消息长度（4 字节），消息的长度，以字节为单位（包括报文头、数据和封装的消息，如果有的话）。Message Type：消息类型（1 字节），这标识了 BMP 消息的类型。BMP 实现必须在收到时忽略无法识别的消息类型。* Type = 0：路由监控* Type = 1：统计报告* Type = 2：Peer Down 通知* Type = 3：Peer Up 通知* Type = 4：发起消息* Type = 5：终止消息* Type = 6：路由镜像消息4.2、 每对等体报文头对于大多数 BMP 消息，每个对等体报文头遵循公共报文头。BMP 消息中的其余数据取决于公共头中的消息类型字段。Peer Type：对等体类型（1字节），标识对等体的类型。目前，确定了三种类型的对等体点：* Peer Type = 0：全局实例Peer* Peer Type = 1：RD Instance Peer* Peer Type = 2：本地实例对等体Peer Flags（1 字节）：这些标志提供有关对等体的更多信息。 标志定义如下：* V 标志，表示 Peer 地址是 IPv6 地址。对于 IPv4 对等体点，此值设置为 0。* L 标志，如果设置为 1，表示该消息反映了 post-policy Adj-RIB-In（即，它的路径属性反映了入站策略的应用）。如果消息反映了 pre-policy Adj-RIB-In，则设置为 0。本地来源的路由也带有 L 标志 1。有关详细信息，请参阅第 5 节。当与路由镜像消息（第 4.7 节）一起使用时，此标志没有意义。* A 标志，如果设置为 1，表示使用旧的 2 字节 AS_PATH 格式格式化消息。如果设置为 0，则消息使用 4 字节 AS_PATH 格式 [RFC6793] 进行格式化。BMP 说话者可以选择传播从其对等体方接收到的 AS_PATH 信息，或者它可以选择将所有 AS_PATH 信息重新格式化为 4 字节格式，而不管它是如何从对等体方接收到的。在后一种情况下，AS4_PATH 或 AS4_AGGREGATOR 路径属性不应该在 BMP UPDATE 消息中发送。当与路由镜像消息（第 4.7 节）一起使用时，此标志没有意义。* 其余位保留供将来使用。它们必须作为 0 传输并且它们的值在接收时必须被忽略。Peer Distinguisher：对等体标识符（8 字节），今天的路由器可以有多个实例（例如：3层虚拟专用网络 (Layer 3 Virtual Private Networks，L3VPN) [RFC4364]）。该字段用于区分属于一个地址域的对等体和另一个。如果对等体方是“全局实例对等体方”，则此字段填零。如果对等体是“RD 实例对等体”，则将其设置为对等体所属的特定实例的路由标识符。如果对等体方是“本地实例对等体方”，则将其设置为唯一的、本地定义的值。在所有情况下，效果是 Peer Type 和 Peer Distinguisher 的组合足以消除其他识别信息可能重叠的对等体点的歧义。Peer Address：对等体地址，与接收封装 PDU 的 TCP 会话相关联的远程 IP 地址。如果在该字段中携带 IPv4 地址（其中 12 个最高有效字节用零填充），则长度为 4 个字节，如果在该字段中携带 IPv6 地址，则长度为 16 个字节。Peer AS：收到封装 PDU 的对等体方的自治系统编号。如果在该字段 [RFC6793] 中存储了 16 位 AS 编号，则应在其最高 16 位中填充零。Peer BGP ID：从其接收封装的 PDU 的对等体的 BGP 标识符。Timestamp：收到封装路由的时间（也可以认为这是它们安装在 Adj-RIB-In 中的时间），以从(UTC)1970年1月1日午夜（零时）开始的秒和微秒表示。如果为零，则时间不可用。时间戳的精度取决于实现。4.3、 发起消息发起消息为被监控路由器提供了一种方法来通知监控站其供应商、软件版本等。发起消息必须作为 TCP 会话出现后的第一条消息发送。如果受监控路由器上的更改保证，则可以在此后的任何时候发送发起消息。发起消息由公共 BMP 报文头组成，后跟两个或多个信息 TLV（第 4.4 节），其中包含有关受监控路由器的信息。必须发送 sysDescr 和 sysName 信息 TLV，其他任何 TLV 都是可选的。字符串 TLV 可以被包含多次。4.4、 信息TLVInitiation（第 4.3 节）和 Peer Up（第 4.10 节）消息使用信息 TLV。** Information Type：信息类型（2字节），提供的信息类型。定义的类型是：* Type = 0：字符串。信息字段包含一个自由格式的 UTF-8 字符串，其长度由信息长度字段给出。该值是通过管理方式分配的。不需要用空（或任何其他特定）字符来终止字符串——信息长度字段给出了它的终止。如果包含多个字符串，则在报告它们时必须保留它们的顺序。* Type = 1: sysDescr。信息字段包含一个 ASCII 字符串，其值必须设置为等于 sysDescr MIB-II [RFC1213] 对象的值。* Type = 2：系统名称。信息字段包含一个 ASCII 字符串，其值必须设置为等于 sysName MIB-II [RFC1213] 对象的值。** Information Length：信息长度（2 字节），以下信息字段的长度，以字节为单位。** Information：信息（变量），有关受监控路由器的信息，根据类型。4.5、 终止消息终止消息为受监控的路由器提供了一种方式来指示它终止会话的原因。尽管建议使用此消息，但监控站必须始终为会话终止而没有消息做好准备。一旦路由器发送了一个终止消息，它必须关闭 TCP 会话而不发送任何进一步的消息。同样，监测站必须在收到终止消息后关闭 TCP 会话。终止消息由公共 BMP 报文头和一个或多个包含终止原因信息的 TLV 组成，如下所示：** Information Type：信息类型（2字节），提供的信息类型。定义的类型是：* Type = 0：字符串。信息字段包含一个自由格式的 UTF-8 字符串，其长度由信息长度字段给出。包含此 TLV 是可选的。它可以用于为任何定义的原因提供进一步的细节。消息中可以包含多个字符串 TLV。* Type = 1：原因。信息字段包含一个 2 字节的代码，指示连接终止的原因。某些原因可能有更多的 TLV 与之相关。需要包含此 TLV。明确的原因是：+ 原因 = 0：会话管理性关闭。会话可能会重新发起。 + 原因 = 1：未指定原因。 + 原因 = 2：资源不足。路由器已耗尽可用于 BMP 会话的资源。 + 原因 = 3：冗余连接。路由器已确定此连接与另一个连接是冗余的。 + 原因 = 4：会话在管理上永久关闭，不会重新发起。监控站应降低（可能为 0）尝试重新连接到受监控路由器的速率。** Information Length：信息长度（2 字节），以下信息字段的长度，以字节为单位。** Information：信息（变量），有关受监控路由器的信息，根据类型。4.6、 路由监控路由监控消息用于 ADJ-RIBs-In 的初始同步。它们还用于持续监控 ADJ-RIB-In 状态。路由监控消息是状态压缩的。这在第 5 节中有更详细的讨论。在公共 BMP 报文头和每个对等体报文头之后是 BGP 更新 PDU。4.7、 路由镜像路由镜像消息用于逐字复制收到的消息。镜像的一种可能用途是对一个或多个受监控的 BGP 会话进行精确镜像，无需状态压缩。另一个可能的用途是镜像已被视为撤销的消息 [RFC7606]，用于调试目的。镜像消息可以被采样，或者可以是无损的。提供消息丢失信息代码以允许指示丢失。第 6 节提供了更多详细信息。在公共 BMP 报文头和每个对等体报文头之后是一组 TLV，其中包含有关一条消息或一组消息的信息。每个 TLV 包括一个 2 字节类型代码、一个 2 字节长度字段和一个可变长度值。包含任何给定的 TLV 是可选的；但是，至少应该包含一个 TLV，否则发送消息就没有意义了。定义的 TLV 如下：** Type = 0：BGP 消息。一个 BGP PDU。这个 PDU 可能是也可能不是更新消息。如果 BGP 消息 TLV 出现在路由镜像消息中，它必须出现在 TLV 列表的最后。** Type = 1：信息。提供有关镜像消息或消息流的信息的 2 字节代码。定义的代码是：* Code = 0：错误的 PDU。发现包含的消息有一些错误，使其无法使用，导致它被视为撤销 [RFC7606]。BGP 消息 TLV 也必须出现在 TLV 列表中。 * Code = 1：消息丢失。一条或多条消息可能已丢失。这可能发生，例如，如果一个实现用完可用的缓冲区空间来排队镜像消息。可以在发送路由监控消息合法的任何时候发送路由镜像消息。4.8、 统计报告这些消息包含监控站可以用来观察路由器上发生的有趣事件的信息。SR 消息的传输可以是定时器触发的或事件驱动的（例如，当发生重大事件或达到阈值时）。本规范没有对这些报告必须在何时以及在什么事件上传输施加任何时间限制。由实现来确定传输定时——但是，应该提供定时器和/或阈值的配置控制。本文档仅规定了SR消息的形式和内容。在公共 BMP 报文头和 per-peer 报文头之后是一个 4 字节的字段，它指示 stats 消息中的计数器数量，其中每个计数器都编码为 TLV。每个计数器的编码如下：**Stat Type（2字节）：定义Stat Data字段携带的统计类型。**Stat Len（2字节）：定义 Stat Data 字段的长度。该规范定义了以下统计信息。BMP 实现必须在接收时忽略无法识别的统计类型，同样必须忽略统计数据字段中的意外数据。Stats 是计数器或仪表，分别在 [RFC1155] 的第 3.2.3.3 节和 [RFC2856] 的第 4 节中的示例之后定义如下：32 位计数器：一个非负整数，单调递增直到达到最大值，当它环绕并从 0 开始再次递增时。它的最大值为 2^32-1（十进制为 4294967295）。64 位仪表：一个非负整数，可以增加或减少，但不得超过最大值，也不得低于最小值。最大值不能大于 2^64-1（18446744073709551615 十进制），最小值不能小于 0。当被建模的信息大于或等于其最大值时，该值具有最大值，并且有当被建模的信息小于或等于其最小值时，它的最小值。如果建模的信息随后减少到最大值以下（或增加到最小值以上），则 64 位 Gauge 也会减少（或增加）。Stat Type = 0：（32 位计数器）入站策略拒绝的前缀数。 Stat Type = 1：（32 位计数器）（已知）重复前缀通告的数量。 Stat Type = 2：（32 位计数器）（已知）重复撤销的数量。 Stat Type = 3：（32 位计数器）由于 CLUSTER_LIST 循环而无效的更新数。 Stat Type = 4：（32 位计数器）由于 AS_PATH 循环而无效的更新数。 Stat Type = 5：（32 位计数器）由于 ORIGINATOR_ID 而失效的更新数量。 Stat Type = 6：（32 位计数器）由于 AS_CONFED 循环而无效的更新数。 Stat Type = 7: (64-bit Gauge) Adj-RIBs-In 中的路由数量。 Stat Type = 8: (64-bit Gauge) Loc-RIB 中的路由数量。 Stat Type = 9：per-AFI/SAFI Adj-RIB-In 中的路由数量。该值的结构为：2 字节地址族标识符 (AFI)、1 字节后续地址族标识符 (SAFI)，后跟 64 位仪表。 Stat Type = 10：per-AFI/SAFI Loc-RIB 中的路由数量。该值的结构为：2 字节 AFI、1 字节 SAFI，后跟 64 位 Gauge。 Stat Type = 11: (32-bit Counter) 接受视为撤销处理的更新数量 [RFC7606]。 Stat Type = 12: (32-bit Counter) 接受视为撤销处理的前缀数 [RFC7606]。 Stat Type = 13：（32 位计数器）收到的重复更新消息的数量。尽管当前规范仅将 4 字节计数器和 8 字节仪表指定为“统计数据”，但这并不排除未来版本合并更复杂的 TLV 类型“统计数据”（例如，可以携带特定前缀数据的数据）。SR 消息是可选的。但是，如果发送 SR 消息，则必须在其中携带至少一个统计信息。4.9、 对等体Down通知此消息用于指示对等体会话已终止。原因指示会话关闭的原因。定义的值是：**原因1：本地系统关闭会话。跟在 Reason 之后的是一个 BGP PDU，其中包含一个 BGP NOTIFICATION 消息，该消息将被发送到对等体。**原因2：本地系统关闭会话。没有发送通知消息。原因代码之后是一个 2 字节的字段，其中包含与导致系统关闭会话的有限状态机 (Finite State Machine，FSM) 事件对应的代码（参见 [RFC4271] 的第 8.1 节）。两个都设置为 0 的字节用于表示没有定义相关的事件代码。**原因3：远程系统通过通知消息关闭会话。Reason 之后是一个 BGP PDU，其中包含从对等体接收到的 BGP NOTIFICATION 消息。**原因4：远程系统在没有通知消息的情况下关闭了会话。这包括传输会话的任何意外终止，因此在某些情况下本地和远程系统都可能认为这适用。**原因5：由于配置原因，此peer的信息将不再发送到监控站。严格来说，这并不表示对等体方已关闭，但确实表示监控站将不会收到对等体方的更新。Peer Down 消息隐式撤消与相关对等体相关联的所有路由。BMP 实现可以省略为此类路由发送显式撤销。4.10、 对等体通知Peer Up 消息用于指示对等体会话已出现（即已转换为已建立状态）。在通用 BMP 报文头和 per-peer 报文头之后是以下内容：** Local Address：本地地址，与对等体 TCP 会话关联的本地 IP 地址。如果此字段中携带 IPv4 地址，则长度为 4 个字节，这由 V 标志（其中 12 个最高有效字节填充零）确定，如果此字段中携带 IPv6 地址，则长度为 16 个字节。** Local Port：本地端口，与对等体 TCP 会话关联的本地端口号，如果实际上不存在 TCP 会话，则为 0（请参阅第 8.2 节）。** Remote Port：远程端口，与对等体 TCP 会话关联的远程端口号，如果实际上不存在 TCP 会话，则为 0（参见第 8.2 节）。（远程地址可以在固定头的 Peer Address 字段中找到。）**Sent OPEN Message：受监控路由器向其对等体传输的完整 OPEN 消息。**Received OPEN Message：受监控路由器从其对等体接收的完整 OPEN 消息。** Information：信息，有关对等体的信息，使用信息 TLV（第 4.4 节）格式。在这个上下文中只定义了字符串类型；它可能会重复。包括信息字段是可选的。它的存在或不存在可以通过检查公共头中的消息长度来推断。5、 路由监控在 BMP 的正常操作模式下，在 BMP 会话建立后，路由监控消息用于提供每个被监控对等体的 Adj-RIB-In 的快照。这是通过使用标准 BGP 更新消息发送存储在这些对等体方的 Adj-RIB-In 中的所有路由来完成的，这些路由封装在路由监控消息中。对等体转储中的消息顺序没有要求。当给定对等体的初始转储完成时，必须通过发送该对等体的 End-of-RIB 标记来指示（如 [RFC4724] 的第 2 节中所指定，加上 BMP 封装头）。另见第 9 节。BMP 发言者可以发送策略前路由、策略后路由或两者。选择可能是由于实施限制（例如，BGP 实施可能不存储已被策略过滤掉的路由）。Pre-policy 路由必须在 BMP 头中清除它们的 L 标志（见第 4 节），post-policy 路由必须设置它们的 L 标志。当一个实现选择发送策略前和策略后路由时，它有效地将两个更新流复用到 BMP 会话上。这些流通过它们的 L 标志来区分。如果实现能够提供有关何时收到路由的信息，它可以在 BMP 时间戳字段中提供此类信息。否则，BMP 时间戳字段必须设置为 0，表示时间不可用。持续监控是通过在 BGP 更新 PDU 中传播路由更改并将这些 PDU 转发到监控站来完成的，再次使用 RM 消息。当路由发生变化时，例如属性发生变化，路由器必须用新的属性更新监控站。如上所述，它可以生成一个清除 L 标志并设置它的更新，或两个更新，一个清除 L 标志，另一个设置 L 标志。当一个路由被peer撤销时，相应的撤销被发送到监控站。撤销必须将其 L 标志设置为对应于任何先前公告的标志；如果有问题的路由先前被通知并同时清除并设置了 L 标志，则撤销必须类似地发送两次，同时清除并设置 L 标志。在可行的情况下，多个更改的路由可以分组为单个 BGP UPDATE PDU，与标准 BGP 协议完全相同。需要注意的是，RM 消息不是从对等体接收到的复制消息。 （如果需要，则提供路由镜像（第 6 节）。）虽然路由器应尝试迅速生成更新，但在接收更新、生成 RM 消息和将其传输到监测站。如果该前缀的临时状态发生变化，则路由器生成该前缀的最终状态给监控站是可以接受的。这有时被称为“状态压缩”。生成并传输到站点的实际 PDU 也可能与从对等体接收的确切 PDU 不同，例如，由于不同实现格式路径属性之间的差异。6、 路由镜像提供路由镜像消息有两个主要原因：首先，使实现能够在一种模式下运行，在这种模式下，它提供从其对等体接收到的所有消息的全保真视图，没有状态压缩。正如我们在第 5 节中提到的，BMP 的正常操作模式无法提供这一点。实施者被强烈警告，如果没有状态压缩，实施可能需要无限存储来缓冲排队等待镜像的消息。路由镜像不太可能适合在传统路由器中实施，除非实施者仔细考虑了权衡，否则不推荐使用它。这些权衡包括：路由器资源耗尽、可能干扰 BGP UPDATE 消息的传输或接收，以及路由收敛速度变慢。路由镜像的第二个应用是错误报告和诊断。当使用 BGP UPDATE 消息的修订错误处理 [RFC7606] 时，路由器可以处理确定包含错误的 BGP 消息，而无需重置 BGP 会话。此类消息可以被镜像。用于这种镜像的缓冲应该是有限的。如果由于缓冲区耗尽而无法镜像错误消息，则应发送带有“消息丢失”代码的消息来指示这一点。（这意味着应为此用途保留缓冲区。）7、 统计报告如上所述，SR 消息用于监视受监视路由器上的特定事件和计数器。一种类型的监控可能是查明在被监控路由器上是否有过多的路由通告和撤销发生（流失）。另一个指标是评估路由器上循环 AS_PATH 的数量。虽然本文档一开始提出了一小部分计数器，但作者设想这个列表将来可能会随着需要 BMP 式监控的新应用程序而增长。8、 其他注意事项8.1、 多个实例一些路由器可能支持 BGP 协议的多个实例，例如，作为“逻辑路由器”或通过一些其他设施。BMP 协议与 BGP 的单个实例相关；因此，如果路由器支持多个 BGP 实例，它也应该支持多个 BMP 实例（每个 BGP 实例一个）。不同的 BMP 实例应该生成彼此不同的发起消息，例如，通过使用可区分的 sysNames 或通过在字符串 TLV 中包含实例标识信息。8.2、 本地路线对于由本地路由器发起到 BGP 的路由，无论是由于来自另一个协议的重新分配还是出于某些其他原因，都需要进行一些考虑。这样的路由可以被建模为由路由器发送给它自己，将路由器自己的地址放在报头的 Peer Address 字段中。建议这样做时，路由器应使用与 BMP 会话的本地地址相同的地址。由于在这种情况下实际上不存在传输会话，Peer Up 消息的本地和远程端口字段必须设置为 0。显然，Peer Up 消息的 OPEN 消息字段将同样没有被物理传输，但应该代表本地路由器的相关能力。此外，回想一下 L 标志用于指示本地来源的路由，请参阅第 4.2 节。9、 使用 BMP一旦建立了 BMP 会话，路由监控就开始同时转储当前快照和增量更改。让这些操作同时发生是可以的。如果初始转储访问路由并且随后接收到撤消，则这将被转发到监控站，监控站必须关联并反映在其内部状态中该路由的删除。无论如何，这是监测站需要支持的操作。如果路由器甚至在对等体转储过程访问该前缀之前就收到了对前缀的撤销，则路由器将从其内部状态中清除该路由，并且不会将其转发到监控站。在这种情况下，监控站可能会收到虚假撤销，它可以安全地忽略。10、 IANA 考虑IANA 为以下 BMP 参数创建了注册表，这些参数被组织在一个新组“BGP 监控协议 (BMP) 参数”中。10.1、 BMP 消息类型本文档定义了用于在协作系统之间传输 BGP 消息的七种消息类型（第 4 节）：类型 0：路由监控 类型 1：统计报告 类型 2：Peer Down 通知 类型 3：Peer Up 通知 类型 4：发起 类型 5：终止 类型 6：路由镜像类型值 0 到 127 必须使用“标准操作”策略分配，值 128 到 250 使用 [RFC5226] 中定义的“规范要求”策略分配。值 251 到 254 是实验性的，值 255 是保留的。10.2、 BMP 对等体类型为了解释 Peer Distinguisher 字段（第 4.2 节），本文档定义了三种类型的对等体点：对等体类型 = 0：全局实例对等体 对等体类型 = 1：RD 实例对等体 对等体类型 = 2：本地实例对等体Peer Type 值 0 到 127 必须使用“Standards Action”策略分配，值 128 到 250 使用“Specification Required”策略分配，在 [RFC5226] 中定义。值 251 到 254 是实验性的，值 255 是保留的。10.3、 BMP 对等体标志本文档在每个对等体头（第 4.2 节）的对等体标志字段中定义了三个位标志。这些位从 0（高位或最左边的位）到 7（低位或最右边的位）编号：标志 0：V 标志 标志 1：L 标志 标志 2：一个标志标志 3 到 7 未分配。注册处的注册程序是“标准操作”。10.4、 BMP 统计类型本文档为统计报告定义了 14 种统计类型（第 4.8 节）：Stat Type = 0：入站策略拒绝的前缀数 Stat Type = 1：（已知）重复前缀通告的数量 Stat Type = 2：（已知）重复撤销的数量 Stat Type = 3：由于 CLUSTER_LIST 循环而失效的更新次数 Stat Type = 4：由于 AS_PATH 循环而失效的更新次数 Stat Type = 5：由于 ORIGINATOR_ID 而失效的更新次数 Stat Type = 6：由于在 AS_CONFED_SEQUENCE 或 AS_CONFED_SET 中发现循环而失效的更新次数 Stat Type = 7：Adj-RIBs-In 中的路由数 Stat Type = 8：Loc-RIB 中的路由数量 Stat Type = 9：per-AFI/SAFI Adj-RIB-In 中的路由数量 Stat Type = 10：per-AFI/SAFI Loc-RIB 中的路由数量 Stat Type = 11：被视为撤销的更新数量 Stat Type = 12：被视为撤销的前缀数 Stat Type = 13：收到的重复更新消息的数量Stat Type 值 0 到 32767 必须使用“Standards Action”策略分配，值 32768 到 65530 使用“Specification Required”策略分配，在 [RFC5226] 中定义。值 65531 到 65534 是实验性的，值 65535 是保留的。10.5、 BMP 发起消息 TLV本文档定义了 Initiation 消息（第 4.3 节）中携带的三种信息类型：类型 = 0：字符串 类型 = 1：sysDescr 类型 = 2：系统名称信息类型值 0 到 32767 必须使用“标准操作”策略分配，值 32768 到 65530 使用“规范要求”策略分配，定义在 [RFC5226] 中。值 65531 到 65534 是实验性的，值 65535 是保留的。10.6、 BMP 终止消息 TLV本文档为 Termination 消息（第 4.5 节）中携带的信息定义了两种类型：类型 = 0：字符串 类型 = 1：原因信息类型值 0 到 32767 必须使用“标准操作”策略分配，值 32768 到 65530 使用“规范要求”策略分配，定义在 [RFC5226] 中。值 65531 到 65534 是实验性的，值 65535 是保留的。10.7、 BMP 终止消息原因代码本文档定义了 Termination 消息（第 4.5 节）Reason code 中携带的信息的五种类型：类型 = 0：管理关闭 类型 = 1：未指定原因 类型 = 2：资源不足 类型 = 3：冗余连接 类型 = 4：永久管理关闭信息类型值 0 到 32767 必须使用“标准操作”策略分配，值 32768 到 65530 使用“规范要求”策略分配，定义在 [RFC5226] 中。值 65531 到 65534 是实验性的，值 65535 是保留的。10.8、 BMP 对等体Down原因代码本文档定义了 Peer Down Notification（第 4.9 节）原因代码中携带的信息的五种类型（并保留了另一种类型）：Type = 0 是保留的。 Type = 1：本地系统关闭，通知 PDU 跟随 Type = 2：本地系统关闭，FSM 事件跟随 Type = 3：远程系统关闭，通知 PDU 跟随 Type = 4：远程系统关闭，无数据 Type = 5：对等体方解除配置信息类型值 0 到 32767 必须使用“标准操作”策略分配，值 32768 到 65530 使用“规范要求”策略分配，定义在 [RFC5226] 中。值 65531 到 65534 是实验性的，值 0 和 65535 是保留的。10.9、 路由镜像 TLV本文档为路由镜像消息（4.7 节）中携带的信息定义了两种类型：类型 = 0：BGP 消息 类型 = 1：信息信息类型值 0 到 32767 必须使用“标准操作”策略分配，值 32768 到 65530 使用“规范要求”策略分配，定义在 [RFC5226] 中。值 65531 到 65534 是实验性的，值 65535 是保留的。10.10、 BMP路由镜像信息代码本文档定义了路由镜像信息（4.7 节）代码中携带的两种信息类型：类型 = 0：错误的 PDU 类型 = 1：消息丢失信息类型值 0 到 32767 必须使用“标准操作”策略分配，值 32768 到 65530 使用“规范要求”策略分配，定义在 [RFC5226] 中。值 65531 到 65534 是实验性的，值 65535 是保留的。11、 安全考虑本文档定义了一种获取完整转储或提供对 BGP 发言者的 BGP 路由（包括接收到的 BGP 消息）的持续监控的机制。这种能力可以允许外部方获得否则无法获得的信息。例如，尽管很难将公共 Internet 中 BGP 路由的内容视为机密，但 BGP 也用于私有上下文，例如，用于 L3VPN [RFC4364]。作为另一个例子，聪明的攻击者可能能够通过比较 BMP 公开的前策略路由和 BGP 中导出的后策略路由来推断被监控路由器的导入策略的内容。该协议的实现应该需要被监控和监控设备的手动配置。除非使用提供相互身份验证的传输，否则攻击者可以伪装成被监控的路由器并欺骗监控站接受虚假信息，或者他们可以伪装成监控站并获得对 BMP 数据的未授权访问。除非使用提供机密性的传输，否则被动或主动攻击者可以访问或篡改传输中的 BMP 数据。当上述安全考虑是一个问题时，该协议的用户应该在隧道模式下使用 IPsec [RFC4303] 和预共享密钥。12、 参考文献12.1、 规范参考[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, <http://www.rfc-editor.org/info/rfc1213>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.12.2、 参考资料[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, <http://www.rfc-editor.org/info/rfc1155>. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, <http://www.rfc-editor.org/info/rfc2856>. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.致谢感谢 Ebben Aries、Michael Axelrod、Serpil Bayraktar、Tim Evens、Pierre Francois、Jeffrey Haas、John Ioannidis、John Kemp、Mack McBride、Danny McPherson、David Meyer、Dimitri Papadimitriou、Tom Petch、Robert Raszuk、Erik Romijn、Peter Schoenmaker， GROW 工作组成员的意见。
-
发表了文章 2023-03-04
CDN：内容分发网络互连 (CDNI) 问题陈述
RFC6707：Content Distribution Network Interconnection (CDNI) Problem Statement，September 2012梗概内容分发网络 (Content Delivery Networks，CDN) 为可缓存的内容提供了许多好处：降低了交付成本，提高了最终用户的体验质量，并提高了交付的稳健性。由于这些原因，它们经常用于大规模内容分发。因此，现有的 CDN 提供商正在扩大其基础设施，许多网络服务提供商 (Network Service Providers，NSP) 正在部署自己的 CDN。通常希望可以将指定的内容项传送给最终用户，而不管该最终用户的位置或连接网络如何。这是互连独立 CDN 的动机，因此它们可以作为开放的内容分发基础设施进行互操作，以便从内容服务提供商 (Content Service Providers，CSP) 到最终用户的端到端内容分发。然而，目前不存在促进这种 CDN 互连的标准或开放规范。本文档的目标是为 IETF CDNI（CDN Interconnection，CDN互连）工作组概述 CDN 互连的问题领域。本备忘录的状态本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。本文档是 Internet 工程任务组 (Internet Engineering Task Force，IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (Internet Engineering Steering Group，IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6707。版权声明版权所有 (c) 2012 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。1、 介绍通过 Internet 传送的视频和多媒体内容的数量正在迅速增加，并且预计在未来将继续增加。面对这种增长，内容分发网络 (CDN) 为可缓存内容提供了许多好处：降低了交付成本、提高了最终用户 (End Users，EU) 的体验质量以及提高了交付的稳健性。由于这些原因，CDN 经常用于大规模内容分发。因此，现有的 CDN 提供商正在扩大其基础设施，许多网络服务提供商 (NSP) 正在部署自己的 CDN。通常希望可以将指定的内容项传送到 EU，而不管该 EU 的位置或它们所连接的网络。然而，负责交付指定内容的指定 CDN 可能没有足够接近EU当前位置或连接网络的覆盖范围，或者可能没有必要的资源来实现用户体验和成本效益CDN 基础设施将允许。这是互连独立 CDN 的动机，以便可以利用其集体 CDN 足迹和资源将内容从内容服务提供商 (CSP) 端到端交付到 EU。例如，CSP 可以与“权威”CDN 提供商就内容分发签订合同，而权威 CDN 提供商可以与一个或多个下游 CDN 提供商签订合同，代表权威机构分发和交付部分或全部内容。CDN 提供商。典型的端到端内容分发场景将涉及以下业务部署：* EU与其 CSP 之间的业务部署，授权EU访问 CSP 控制的内容项目。* CSP 与“权威”CDN 提供商之间的业务部署，其中 CSP 要求 CDN 提供商代表 CSP 执行内容分发。* 权威 CDN 提供商与另一个（或其他）CDN 之间的业务部署，其中权威 CDN 可以将某些内容分发请求的实际服务委托给其他 CDN。一种特殊情况是，该其他 CDN 提供商恰好也是向EU提供网络访问的网络服务提供商，在这种情况下，EU与 NSP 之间也存在单独且独立的业务关系，用于相应的网络访问。CSP 和 CDN 提供商之间以及一个 CDN 提供商和另一个 CDN 提供商之间的任何业务关系的形成和详细信息超出了本文档的范围。然而，本文档关注的是，从技术角度来看，目前不存在标准或开放规范来促进此类 CDN 互连。下面描述了通过 CDN 互联执行端到端内容分发的一种可能流程：* 来自EU用户代理的初始内容请求首先由权威（上游）CDN 接收，该 CDN 是与 CSP 有业务部署的 CDN。* 权威（上游）CDN 可以自己为请求提供服务，也可以选择使用 CDN 互联将请求重定向到更适合这样做的下游 CDN（例如，“更接近”的下游 CDN）到EU。* EU的用户代理将“跟随”权威 CDN 返回的重定向，并从下游 CDN 请求内容。如果需要，Downstream CDN将从权威（上游）CDN获取请求的内容，如果需要，Authoritative CDN将从内容服务提供商处获取请求的内容。本文档的目标是概述 CDN 互联的问题领域。第 2 节讨论 CDN 互连的用例。第 3 节介绍了 IETF 正在考虑的 CDNI 模型和问题领域。第 4 节分别描述了每个 CDNI 接口，并重点介绍了可以考虑重用或利用以实现 CDNI 接口的示例候选协议。附录 B.2 描述了 CDNI 问题空间与其他相关 IETF 工作组和 IRTF 研究组之间的关系。1.1、 术语本文档使用以下术语：Authoritative CDN：权威 CDN，与 CSP 有直接关系的 CDN，用于通过权威 CDN 或权威 CDN 的下游 CDN 分发和交付该 CSP 的内容。CDN Interconnection(CDNI)：CDN互连，一对 CDN 之间的关系，使一个 CDN 能够代表另一个 CDN 提供内容分发服务。CDN互连可以全部或部分通过一组接口实现，一对CDN通过这些接口相互通信，以实现由一个CDN（下游CDN）中的代理代表另一个CDN向用户代理交付内容（上游 CDN）。CDN Provider：CDN 提供商，运营 CDN 并提供内容分发服务的服务提供商，通常由内容服务提供商或其他 CDN 提供商使用。请注意，一个指定的实体可能扮演多个角色。例如，一家公司可能同时作为内容服务提供商、网络服务提供商和 CDN 提供商运营。CDNI Metadata：CDNI元数据，具有跨 CDN 范围的内容分发元数据的子集。例如，CDNI 元数据可以包括地理封锁信息（即，定义要提供或阻止内容的地理区域的信息）、可用性窗口（即定义要使内容可用或被阻止的时间窗口的信息）和要强制执行的访问控制机制（例如，URI 签名验证）。CDNI 元数据还可能包括有关所需分发策略（例如，预先定位与动态获取）以及有关 CDN 可以在哪里/如何获取内容的信息。Content：内容，任何形式的数字数据。对分发和交付具有额外约束的一种重要内容形式是连续媒体（即，源和接收器之间存在时间关系）。Content Distribution Metadata：内容分发元数据，与内容分发相关的内容元数据子集。这是 CDN 所需的元数据，以便启用和控制 CDN 的内容分发和交付。在 CDN 互连环境中，某些内容分发元数据可能具有 CDN范围内（因此不需要在 CDN 之间进行通信），而某些内容分发元数据可能具有 CDN范围间（因此需要CDN 之间进行通信）。Content Distribution Network(CDN)/Content Delivery Network(CDN)：内容分发网络，网络基础设施中的网络元素在第 4 层到第 7 层进行协作，以便更有效地将内容分发给用户代理。通常，CDN 由请求路由系统、分发系统（包括一组代理）、日志记录系统和 CDN 控制系统组成。Content Metadata：内容元数据，这是关于内容的元数据。内容元数据包括：1. 与内容分发相关的元数据（因此与参与该内容分发的 CDN 相关）。我们将这种类型的元数据称为“内容分发元数据”。另请参阅内容分发元数据的定义。2. 与实际内容或内容表示相关的元数据，与该内容的分发没有直接关系。例如，此类元数据可能包括与内容的类型、演员表、评级等有关的信息以及与内容表示的分辨率、纵横比等有关的信息。Content Service：内容服务，由内容服务提供商提供的服务。内容服务包含完整的服务，可能不仅仅是提供对内容项的访问；例如，内容服务还包括任何中间件、密钥分发、节目指南等，它们可能不需要与内容分发和交付中涉及的 CDN 或 CDN 进行任何直接交互。Content Service Provider(CSP)：内容服务提供商，向最终用户（他们通过用户代理访问）提供内容服务。CSP 可以拥有作为内容服务的一部分提供的内容，或者可以从另一方许可内容权利。Control system：控制系统，CDN 内的功能，负责引导和控制 CDN 的其他组件以及处理与外部系统的交互（例如，处理交付服务创建/更新/删除请求，或特定服务供应请求）。Delivery：交付，CDN 代理中负责向用户代理交付一段内容的功能。例如，交付可能基于 HTTP 渐进式下载或 HTTP 自适应流。Distribution system：分发系统，CDN 内的功能，负责分发内容分发元数据以及 CDN 内的内容本身（例如，下至代理）。Downstream CDN：下游 CDN，对于指定的最终用户请求，另一个 CDN（上游 CDN）将请求重定向到的 CDN（在一对直接互连的 CDN 内）。请注意，在连续重定向（例如，CDN1-->CDN2-->CDN3）的情况下，指定的 CDN（例如，CDN2）可以充当重定向的下游 CDN（例如，CDN1-->CDN2）并作为上游 CDN，用于相同请求的后续重定向（例如，CDN2-->CDN3）。Dynamic CDNI Metadata acquisition：动态 CDNI 元数据获取，在 CDN 互连的环境中，动态 CDNI 元数据获取意味着下游 CDN 在某个时间点从上游 CDN 获取内容的 CDNI 元数据，该内容的请求由上游委托给下游 CDN CDN（并且该特定 CDNI 元数据在下游 CDN 中尚不可用）。另请参阅下游 CDN 和上游 CDN 的定义。Dynamic content acquisition：动态内容获取，动态内容获取是 CDN 从内容源获取内容以响应最终用户从 CDN 请求内容的地方。在 CDN 互连的环境中，动态获取意味着下游 CDN 在某个时间点从上游 CDN（以及特定的内容在下游 CDN 中尚不可用）。End User(EU)：最终用户，系统的“真实”用户，通常是人类，但也可能是模拟人类的硬件和/或软件的某种组合（例如，用于自动质量监控等）。Logging system：日志系统，CDN 中负责收集分发和交付活动的测量和记录的功能。日志系统记录的信息可用于各种目的，包括收费（例如，CSP）、分析和监控。Metadata：元数据，元数据一般是关于数据的数据。 Network Service Provider(NSP)：网络服务提供商，为最终用户提供基于网络的连接/服务。Over-the-top (OTT)：一种服务，例如使用 CDN 的内容分发，由与该服务的用户所连接的 NSP 不同的运营商运营。Pre-positioned CDNI Metadata acquisition：预置 CDNI 元数据获取，在 CDN 互连的环境中，CDNI 元数据预置是下游 CDN 在任何最终用户从下游 CDN 请求内容之前或独立于其获取内容的 CDNI 元数据。Pre-positioned content acquisition：预置内容获取，内容预置是 CDN 在任何最终用户从 CDN 请求内容之前或独立于内容源获取内容的地方。在 CDN 互连的环境中，上游 CDN 指示下游 CDN 提前或独立于任何终端用户请求从内容源（包括上游 CDN）获取内容。Quality of Experience(QoE)：体验质量，如 [RFC6390] 的第 2.4 节中所定义。Request Routing system：请求路由系统，CDN 内的功能，负责接收来自用户代理的内容请求，获取和维护关于一组候选代理或候选 CDN 的必要信息，以及用于选择用户并将用户重定向到适当的代理或 CDN。要启用 CDN 互连，请求路由系统还必须能够处理由另一个 CDN 传递给它的用户代理内容请求。Surrogate：代理，一种设备/功能（通常称为缓存），它与 CDN 的其他元素交互以控制和分发 CDN 内的内容，并与用户代理交互以交付内容。通常，代理将缓存请求的内容，以便他们可以直接传送相同的内容以响应来自多个用户代理（及其最终用户）的请求，从而避免内容需要多次通过网络核心（即，从内容起源于代理）。Upstream CDN：上游CDN，对于指定的最终用户请求，将请求重定向到另一个 CDN 的 CDN（在一对直接互连的 CDN 内）。User Agent(UA)：用户代理，最终用户通过其与内容服务交互的软件（或硬件和软件的组合）。用户代理将与内容服务通信以选择内容，并与一个或多个 CDN 通信以交付内容。此类通信不限于 HTTP，还可以通过各种协议进行。用户代理（非穷举）的例子有浏览器、机顶盒(Set Top Boxes，STB)、专用内容应用程序（例如媒体播放器）等。1.2、 CDN背景假设读者熟悉 CDN 的架构、特性和操作。对于不太熟悉 CDN 操作的读者，以下资源可能有用：* RFC 3040 [RFC3040] 描述了许多用于构建 CDN 的组件技术。* 分类法 [TAXONOMY] 比较了多个 CDN 的架构。* RFC 3466 [RFC3466] 和 RFC 3570 [RFC3570] 是 IETF 内容分发互联网 (Content Distribution Internetworking，CDI) 工作组的输出，该工作组于 2003 年关闭。注意：本文档中使用的某些术语与上述参考文档中使用的术语相似。阅读本文件时，术语应理解为具有第 1.1 节中提供的定义。2、 CDN 互联用例越来越多的 NSP 正在部署 CDN，以经济高效地应对日益增长的点播视频服务和其他内容分发应用程序的使用。CDN 允许缓存更靠近网络边缘的内容，以便 CDN 代理（即缓存）可以将指定的内容项目交付给多个用户代理（及其最终用户），而无需多次通过网络核心传输（即，从内容来源到代理）。这有助于降低 NSP 的带宽成本并提高最终用户的体验质量。CDN 还支持跨多个代理复制流行内容，这使得内容可以同时提供给大量用户代理。这也有助于处理诸如突发访问和拒绝服务攻击等情况。NSP 部署的 CDN 不仅限于内容分发以支持网络服务提供商自己的“秘密花园”服务，例如向机顶盒提供电视服务的 IP 交付，还用于向其他设备交付内容，包括个人电脑、平板电脑、手机等。一些服务提供商在多个地区运营并联合多个附属 NSP。这些 NSP 通常运行独立的 CDN。随着他们服务的发展（例如，为跨附属 NSP 向漫游用户提供内容服务的无缝支持），需要将这些 CDN 互连；这代表了 CDNI 的第一个用例。但是，没有开放的规范，也没有通用的最佳实践来定义如何实现这种 CDN 互连。CSP 希望能够将他们的（部分）内容提供给通常分布在多个地区的大量最终用户，同时保持高质量的体验，而无需与以下人员保持直接业务关系许多不同的 CDN 提供商（或必须将他们自己的 CDN 扩展到大量位置）。一些 NSP 正在考虑将其各自的 CDN（以及可能的顶级 CDN）互连，以便该集体基础设施能够以具有成本效益的方式满足 CSP 的要求。这代表了 CDNI 的第二个用例。特别是，这将使 CSP 能够尽可能从网内交付（即，在网络服务提供商自己的网络/CDN 覆盖范围内）中受益，否则就可以从网外交付中受益，而无需 CSP 与所有供应商保持直接业务关系。参与交付的 CDN。同样，CDN 提供商（NSP 或顶级 CDN 运营商）面临缺乏开放规范和最佳实践的问题。NSP 通常在特定服务或环境的环境中部署 CDN 作为专门的成本降低项目。一些 NSP 为单独的服务运行单独的 CDN。例如，可能有用于托管 IPTV 服务交付的 CDN、用于网络电视交付的 CDN 和用于向移动终端交付视频的 CDN。随着 NSP 集成其服务组合，需要将这些 CDN 互连，这是 CDNI 的第三个用例。同样，NSP 面临着 CDN 互连缺乏开放接口的问题。出于运营原因（例如，灾难、突发访问）或商业原因，over-the-top CDN 可能会选择使用另一个 CDN（例如，具有网络代理的 NSP CDN）来为子集提供服务的用户请求（例如，来自附加到该 NSP 的用户的请求），这导致 CDNI 的第四个用例，因为 CDN 提供商（顶级 CDN 提供商或 NSP）面临缺乏开放规范和最佳实践。CDN 互连的用例在 [CDNI-USE-CASES] 中进一步讨论。3、 IETF 的 CDN 互连模型和问题领域本节讨论 IETF 在 CDN 互连方面工作的问题领域。互连 CDN 涉及形成每个 CDN 的多个不同功能和组件之间的交互。只有其中一些需要 IETF 的额外规范。一些 NSP 已经开始进行实验，以探索他们的 CDN 用例是否已经可以通过现有的 CDN 实现来解决。[CDNI-EXPERIMENTS] 中记录了一组这样的实验。这些实验的结论是，虽然使用现有 CDN 技术可以实现一些基本的有限 CDN 互连功能，但当前缺乏具有必要功能级别的任何标准化 CDNI 接口（例如本文档中讨论的那些），这阻碍了 CDN 互连的部署.下面列出了互连一对 CDN 所需的四个接口，它们构成了 CDN 互连的问题空间，以及目前尚不存在标准的每个接口所需的功能。作为 CDNI 接口开发的一部分，还需要就如何识别和命名将在互连 CDN 之间交换的数据对象的通用机制达成一致。术语“接口”的使用旨在涵盖交换 CDNI 数据表示（例如 CDNI 元数据对象）的协议以及数据表示本身的规范（即，每个对象包含哪些属性/字段，其结构等）。** CDNI Control 接口：该接口允许互连 CDN 中的“CDNI Control”系统进行通信。该接口可能支持以下内容：* 允许引导其他 CDNI 接口（例如，接口地址/URL 发现和安全关联的建立）。* 允许配置其他 CDNI 接口（例如，上游 CDN 指定要通过 CDNI 日志记录接口报告的信息）。* 允许下游 CDN 传达有关其交付能力和策略的静态（或相当静态）信息。* 允许引导 CDN 之间的接口以获取内容（即使该接口本身不在 CDNI 工作的范围内）。* 允许上游 CDN 发起或请求在下游 CDN 中执行的特定操作。例如，允许上游 CDN 启动内容或 CDNI 元数据获取（预定位）或请求无效或清除下游 CDN 中的内容文件和/或 CDNI 元数据。** CDNI 请求路由接口：该接口允许互连 CDN 中的请求路由系统进行通信，以确保最终用户请求可以从上游 CDN（重新）定向到下游 CDN 中的代理，特别是在选择职责可能跨 CDN 拆分（例如，上游 CDN 可能负责选择下游 CDN，而下游 CDN 可能负责选择该下游 CDN 内的实际代理）。具体来说，CDN请求路由接口的功能可以划分如下：* CDNI 请求路由重定向接口，允许上游 CDN 在请求路由时查询下游 CDN，然后再将请求重定向到下游 CDN。* CDNI Footprint & Capabilities 通告接口，允许下游 CDN 向上游 CDN 提供（静态或动态）信息（例如，资源、足迹、负载），以方便上游 CDN 请求路由系统在以下情况下选择下游 CDN处理来自用户代理的后续内容请求。** CDNI Metadata接口：该接口允许互连CDN中的分发系统进行通信，以确保CDNI Metadata可以跨CDN交换。有关 CDNI 元数据的定义和示例，请参见第 1.1 节。** CDNI Logging 接口：该接口允许互连 CDN 中的 Logging 系统通信相关活动日志，以便允许使用日志的应用程序在多 CDN 环境中运行。例如，上游 CDN 可以从下游 CDN 收集交付日志，以便对 CSP 执行统一收费或用于跨 CDN 的结算。类似地，上游 CDN 可以从下游 CDN 收集交付日志，以便向 CSP 提供统一的报告和监控。请注意，这四个接口下的实际功能分组在此阶段被认为是暂定的，并且可能会在进一步研究后进行更改（例如，某些功能子集可能会从一个接口移动到另一个接口）。上面的列表涵盖了一个重要的潜在问题空间，部分原因是为了互连两个 CDN，有几个“接触点”需要标准化。但是，预计 CDNI 接口不需要从头开始定义，而是可以在很大程度上重用或利用现有协议；这将在第 4 节中进一步讨论。形成 CDNI 问题区域的接口如图 1 所示。图 1：CDNI 问题领域的模型<==> CDNI范围内的接口 **** CDNI范围之外的接口 .... CDNI范围之外的接口如图 1 所示，互连 CDN 之间的内容获取超出了 CDNI 的范围；这值得一些额外的解释。这种决定的结果是，本文档中描述的 CDNI 问题空间仅专注于定义 CDNI 的控制平面，而 CDNI 数据平面（即实际内容对象的获取和分发）超出了范围。做出这种决定的理由是，今天的 CDN 通常已经使用标准化协议（例如 HTTP、FTP、rsync 等）来从其 CSP 客户获取内容，并且预期相同的协议可用于互连 CDN 之间的获取。因此，内容获取的问题被认为已经解决了，从 CDNI 工作组制定的规范中获取内容所需的一切就是在 CDNI 元数据中描述用于检索内容的参数——例如，要连接的 IP 地址/主机名、使用什么协议来检索内容等。4、 界定 CDNI 问题本节概述了如何通过重用或利用现有协议来实现 CDNI 接口来限制解决 CDNI 问题空间的工作范围。本次讨论的目的不是抢占任何工作组关于选择实现 CDNI 接口的最合适的协议、技术和解决方案的决定，而是旨在说明 CDNI 接口不需要在真空中创建和重用或利用现有协议是可能的。CDNI问题区中第3节描述的四个CDNI接口（CDNI Control接口、CDNI请求路由接口、CDNI元数据接口和CDNI Logging接口）都是运行在应用层（OSI网络模型中的第7层）的控制平面接口）。首先，由于与 Internet 中的许多其他现有应用程序相比，预计这些接口不会表现出独特的会话、传输或网络要求，因此预计 CDNI 接口将在现有会话、传输、和网络协议。其次，虽然可以专门为 CDNI 设计一个新的应用协议，但我们下面的分析表明这是不必要的，建议重用或利用现有的应用协议（HTTP [RFC2616]、Atom 发布协议 [RFC5023]、可扩展消息传递和在线协议 (Extensible Messaging and Presence Protocol，XMPP) [RFC6120]，例如）来实现 CDNI 接口。4.1、 CDNI控制接口CDNI 控制接口允许互连 CDN 中的控制系统进行通信。目前，CDNI 控制接口所需支持的确切的 CDN 间控制功能的定义不如其他三个 CDNI 接口。预计 Control 接口和其他 CDNI 接口一样，可以重用或利用现有协议。4.2、 CDNI 请求路由接口CDNI 请求路由接口启用上游 CDN 中的请求路由功能，以查询下游 CDN 中的请求路由功能，以确定下游 CDN 是否能够（并愿意）接受委托的内容请求。它还允许下游 CDN 控制上游请求路由功能应在重定向消息中返回给用户代理的内容。因此，CDNI 请求路由接口是一个相当简单的请求/响应接口，可以通过任意数量的请求/响应协议实现。例如，它可以使用常见的 WebServices 方法之一（可扩展标记语言-远程过程调用 (Extensible Markup Language-Remote Procedure Calling，XML-RPC)、对已知 URI 的 HTTP 查询等）实现为 WebService。这消除了 CDNI 工作组为 CDNI 请求路由接口的请求/响应元素定义新协议的需要。此外，如第 3 节所述，CDNI 请求路由接口也有望使下游 CDN 能够向上游 CDN 提供（静态或动态）信息（例如，资源、足迹、负载），以便通过以下方式选择下游 CDN在处理来自用户代理的后续内容请求时，上游 CDN 请求路由系统。预计 CDNI 请求路由的此类功能可以由 CDNI 工作组指定，并显着利用支持可达性信息动态分发的现有 IETF 协议（例如，通过利用现有路由协议）或支持应用程序级查询拓扑信息（例如，使用利用应用层流量优化 (Application-Layer Traffic Optimization，ALTO) [RFC5693]）。4.3、 CDNI元数据接口CDNI 元数据接口使下游 CDN 中的分发系统能够从上游 CDN 请求 CDNI 元数据，以便下游 CDN 可以正确处理和响应通过 CDNI 请求路由接口接收的重定向请求和直接从用户代理接收的内容请求。CDNI 元数据接口因此类似于 CDNI 请求路由接口，因为它是一个请求/响应接口，具有潜在的附加功能，即 CDNI 元数据搜索可能比简单的请求路由重定向请求具有更复杂的语义。因此，与 CDNI 请求路由接口一样，CDNI 元数据接口可以使用常见的 WebServices 方法之一（XML-RPC、对已知 URI 的 HTTP 查询等）或可能使用其他现有协议（如 XMPP）实现为 WebService [RFC6120]。这消除了 CDNI 工作组为 CDNI 元数据接口的请求/响应元素定义新协议的需要。4.4、 CDNI 日志接口CDNI Logging 接口允许在互连的 CDN 之间交换内容分发和交付活动的详细信息——例如，与内容分发相关的日志记录的交换，类似于 Web 服务器访问日志中记录的日志记录。已经存在几种可能用于在互连 CDN 之间交换 CDNI 日志的协议，包括简单网络管理协议 (Simple Network Management Protocol，SNMP)、系统日志、FTP（和安全变体）、HTTP POST 等。5、 安全考虑CDN 分发内容有一系列安全考虑，例如如何根据 CSP 策略强制控制最终用户对内容的访问，或者如何信任 CDN 生成的日志信息以用于为 CSP 付费。如今，CDN 提供商和 CSP 已经在独立 CDN 的背景下处理了这些安全问题。然而，CDN 的互连通过将信任模型扩展到信任链（即，CSP“信任”一个“信任”另一个 CDN 的 CDN）引入了一组新的安全考虑。在多 CDN 环境中用于缓解这些风险的机制可能类似于在单 CDN 情况下使用的机制，但必须验证它们在这种更复杂环境中的适用性。除了适用于单一 CDN 的情况之外，CDN 的互连还可能引入额外的隐私考虑。在多 CDN 环境中，不同的 CDN 可能位于不同的法律制度中，需要执行不同的隐私要求。此类隐私要求可能会影响可跨 CDNI 接口交换的信息的粒度。例如，在与上游 CDN 交换包含最终用户交付详细信息的日志记录之前，下游 CDN 中的日志记录系统可能需要应用某种程度的匿名化、混淆，甚至完全删除某些字段。维护内容本身、其相关元数据（包括交付策略）以及分发和交付内容的 CDN 的安全性是 CDN 提供商和 CSP 的关键要求，并且 CDN 互连接口必须提供足够的机制来维护内容的安全性。互连 CDN 的整个系统以及通过任何一组互连 CDN 分发和交付的信息（内容、元数据、日志等）。5.1、 CDNI 控制接口的安全性通过此接口在互连 CDN 之间交换的信息具有敏感性。一对 CDN 使用此接口来允许引导所有其他 CDNI 接口，可能包括建立保护这些接口的机制。因此，该接口的损坏可能会导致所有其他接口的损坏。使用这个接口，上游 CDN 可以预先定位或删除下游 CDN 中的内容或元数据，下游 CDN 可以向上游 CDN 提供管理信息等。所有这些操作都需要对等 CDN 进行适当的身份验证，并且可以确保它们之间流动的信息的机密性和完整性。5.2、 CDNI 请求路由接口的安全性在此接口中必须使用适当级别的身份验证和机密性，因为它允许上游 CDN 查询下游 CDN 以重定向请求，相反，允许下游 CDN 影响上游 CDN 的请求路由功能。在此接口上缺乏适当的安全性的情况下，超负荷的上游 CDN 可能会用虚假请求淹没下游 CDN，或者让下游 CDN 发送超负荷的上游 CDN 私有信息。此外，超负荷的下游 CDN 可能会影响上游 CDN，因此上游 CDN 将请求重定向到超负荷的下游 CDN 或另一个下游 CDN，以便例如吸引额外的交付收入。5.3、 CDNI 元数据接口的安全性该接口允许下游 CDN 向上游 CDN 请求 CDNI 元数据，因此上游 CDN 在发送数据之前必须确保前者经过适当的身份验证。相反，下游 CDN 必须在请求元数据之前对上游 CDN 进行身份验证，以使其自身免受超负荷的上游 CDN 的毒害。必须保护对等点之间交换的信息的机密性和完整性。5.4、 CDNI 日志接口的安全性日志数据包含潜在的敏感信息（最终用户访问了哪些媒体资源、最终用户的 IP 地址、潜在名称和订阅者帐户信息等）。由于日志记录在 CDN 之间移动，因此必须保护此信息的机密性。从它可以作为跨 CDN 收费的基础的角度来看，此信息也可能是敏感的。因此，需要适当级别的保护以防止此信息的损坏、重复和丢失。6、 致谢作者要感谢 Andre Beck、Gilles Bertrand、Mark Carlson、Bruce Davie、David Ferguson、Yiu Lee、Kent Leung、Will Li、Kevin Ma、Julien Maisonneuve、Guy Meador、Larry Peterson、Emile Stephan、Oskar van Deventer、Mahesh Viveganandhan 和 Richard Woundy 的评论和对文本的贡献。7、 参考资料[ALTO-CDN-USE-CASES] Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012. [ALTO-Charter] "IETF ALTO WG Charter",. [CDNI-EXPERIMENTS] Bertrand, G., Ed., Le Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", Work in Progress, February 2012. [CDNI-USE-CASES] Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", Work in Progress, August 2012. [DECADE-Charter] "IETF DECADE WG Charter",. [P2PRG-CDNI] Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 'Peering Peer-to-Peer'", March 2010,. [PPSP-Charter] "IETF PPSP WG Charter",. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003. [RFC5023] Gregorio, J., Ed., and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content Delivery Networks", 2007,.附录 A、 实现 CDNI 接口的设计考虑本节在单独描述每个 CDNI 接口之前扩展了 CDNI 接口如何重用和利用现有协议，并重点介绍可以考虑重用或利用以实现 CDNI 接口的示例候选协议。但是，此处讨论的选项纯粹是示例，并未就稍后要使用的协议达成任何共识。A.1、 CDNI控制接口CDNI 控制接口允许互连 CDN 中的控制系统进行通信。目前，CDNI 控制接口所需支持的确切的 CDN 间控制功能的定义不如其他三个 CDNI 接口。但是，如第 3 节所述，可能需要 CDNI 控制接口来支持类似于以下的功能：允许上游 CDN 和下游 CDN 建立、更新或终止其 CDNI 互连。允许引导其他 CDNI 接口（例如，协议地址发现和安全关联的建立）。允许配置其他 CDNI 接口（例如，上游 CDN 指定要通过 CDNI 日志记录接口报告的信息）。允许下游 CDN 传达有关其交付能力、资源和策略的静态信息。允许引导 CDN 之间的接口以获取内容（即使该接口本身不在 CDNI 工作的范围内）。预计 Control 接口和其他 CDNI 接口一样，可以重用或利用现有协议。一旦对 Control 接口的要求得到细化，就会考虑这些。A.2、 CDNI 请求路由接口CDNI 请求路由接口启用上游 CDN 中的请求路由功能，以查询下游 CDN 中的请求路由功能，以确定下游 CDN 是否能够（并愿意）接受委托的内容请求，并允许下游 CDN 进行控制上游请求路由功能应该在重定向消息中返回给用户代理的内容。因此，CDNI 请求路由接口需要提供一种机制，让上游 CDN 向下游 CDN 发出“重定向请求”。请求路由接口需要能够支持通过 DNS 以及特定内容应用协议（例如 HTTP、实时流协议 (RTSP)、实时消息传递协议 (RTMP) 等）。因此，重定向请求应包含以下信息：上游 CDN 通过其接收初始用户代理请求的协议（例如 DNS、HTTP）。下游 CDN 执行有效请求路由所需的用户代理请求的其他详细信息。对于 DNS，这通常是代表用户代理发出请求的 DNS 解析器的 IP 地址。对于通过特定于内容的应用程序协议接收的请求，重定向请求可能包含更多与原始用户代理请求相关的信息，但至少应包括用户代理的 IP 地址、等效的 HTTP 主机标头和等效的[RFC2616] 中定义的 HTTP abs_path。需要注意的是，CDNI架构需要考虑下游CDN可能会收到来自用户代理的请求，而无需先收到来自上游CDN的针对相应用户代理请求的重定向请求，例如：用户代理（或 DNS 解析器）可以缓存来自请求路由器的 DNS 或应用程序响应。通过请求路由接口对重定向请求的响应可能是可缓存的。一些 CDN 可能依赖于简单的粗略策略，例如，CDN B 同意始终为 CDN A 的委托重定向请求提供服务，在这种情况下，必要的重定向详细信息在带外（CDNI 接口）交换，例如，配置。收到重定向请求后，下游 CDN 将使用请求中提供的信息来确定它是否能够（并愿意）接受委托的内容请求，并需要将其决定结果返回给上游 CDN。因此，来自下游 CDN 的重定向响应应包含以下信息：表示接受或拒绝的状态代码（可能有伴随的原因）。允许上游 CDN 重定向的信息。在基于 DNS 的请求路由的情况下，这应该包括上游 CDN 应返回给请求 DNS 解析器的等效 DNS 记录（例如，CNAME）。在基于应用程序的请求路由的情况下，这应该包括构建特定于应用程序的重定向响应以返回到请求用户代理所需的信息。对于来自用户代理的 HTTP 请求，这可能包括上游 CDN 可以在 HTTP 3xx 响应中返回的 URI。因此，CDNI 请求路由接口是一个相当简单的请求/响应接口，可以通过任意数量的请求/响应协议实现。例如，它可以使用常见的 WebServices 方法之一（XML-RPC、对已知 URI 的 HTTP 查询等）实现为 WebService。这消除了 CDNI 工作组为 CDNI 请求路由接口的请求/响应元素定义新协议的需要。因此，CDNI 工作组将只负责指定：推荐的请求/响应协议与特定于 CDNI 请求路由接口的任何附加语义和程序一起使用（例如，处理格式错误的请求/响应）。重定向请求和响应的语法（即表示/编码）。重定向请求和响应的语义（即含义和预期内容）。此外，如第 3 节所述，CDNI 请求路由接口也有望使下游 CDN 能够向上游 CDN 提供（静态或动态）信息（例如，资源、足迹、负载），以便通过以下方式选择下游 CDN在处理来自用户代理的后续内容请求时，上游 CDN 请求路由系统。预计 CDNI 请求路由的此类功能可以由 CDNI 工作组指定，并显着利用支持可达性信息动态分发的现有 IETF 协议（例如，通过利用现有路由协议）或支持应用程序级查询拓扑信息（例如，通过利用 ALTO）。A.3、 CDNI元数据接口CDNI元数据接口使下游CDN中的分发系统能够从上游CDN获取CDNI元数据，以便下游CDN能够正确处理和响应：通过 CDNI 请求路由接口接收的重定向请求。直接从用户代理收到的内容请求。CDNI 元数据接口需要为上游 CDN 提供一种机制以：** 将 CDNI 元数据分发/更新/删除到下游 CDN。和/或允许下游 CDN：** 直接请求 CDNI 元数据对象。** 对 CDNI 元数据进行递归请求——例如，使下游 CDN 能够沿着具有对象间关系的对象树向下走。CDNI 元数据接口因此类似于 CDNI 请求路由接口，因为它是一个请求/响应接口，具有潜在的附加功能，即 CDNI 元数据搜索可能比简单的请求路由重定向请求具有更复杂的语义。因此，与 CDNI 请求路由接口一样，CDNI 元数据接口可以使用常见的 WebServices 方法之一（XML-RPC、对已知 URI 的 HTTP 查询等）或可能使用其他现有协议（如 XMPP）实现为 WebService [RFC6120]。这消除了 CDNI 工作组为 CDNI 元数据接口的请求/响应元素定义新协议的需要。因此，CDNI 工作组将只负责指定：推荐的请求/响应协议与特定于 CDNI 元数据接口的任何附加语义一起使用（例如，处理格式错误的请求/响应）。将通过接口交换的 CDNI 元数据对象的语法（即表示/编码）。元数据对象的各个属性的语义（即含义和预期内容）。如何表示不同 CDNI 元数据对象之间的关系。A.4、 CDNI 日志接口CDNI Logging 接口允许在互连的 CDN 之间交换内容分发和交付活动的详细信息，例如与内容分发相关的日志记录（类似于 Web 服务器访问日志中记录的日志记录）。在当今的 CDN 中，日志记录用于多种目的。具体来说，CDN 使用日志来生成呼叫数据记录 (CDR)，以传递给计费和支付系统以及实时（和近实时）分析系统。此类应用程序对 CDNI 日志记录接口提出了要求，以支持在互连 CDN 之间保证和及时地传递日志消息。可能还需要能够证明接收到的日志消息的完整性。已经存在几种可能用于在互连 CDN 之间交换 CDNI 日志的协议，包括 SNMP 陷阱、系统日志、FTP、HTTP POST 等，尽管某些候选协议可能不太适合满足所有CDNI 的要求。例如，SNMP 陷阱会带来可扩展性问题，并且 SNMP 不支持陷阱的保证交付，因此可能会导致日志记录丢失，并且无法生成该内容分发的后续 CDR 和计费记录，以及该内容分发不可见到任何分析平台。尽管没有必要为跨 CDNI Logging 接口交换日志定义新协议，但 CDNI 工作组仍需要指定：推荐使用的协议。一组默认的日志字段及其语法和语义。今天，没有跨不同内容分发协议的标准通用日志字段集，在某些情况下，甚至没有针对同一交付协议的不同实现的标准日志字段名称和值集。触发日志记录生成的一组默认条件。附录 B、 附加材料本部分记录了作为定义 CDNI 问题陈述的一部分而产生的相关信息。B.1、 非IETF的目标下面列出了作者建议不属于 CDNI 工作组范围的内容分发方面：内容服务提供商和权威 CDN 之间的接口（即由 CSP 签约的上游 CDN，由该 CDN 或其下游 CDN 交付）。交付 CDN Surrogate 和 User Agent 之间的交付接口，例如流协议。用户代理和指定 CDN 的请求路由系统之间的请求接口。现有的 IETF 协议（例如 HTTP、RTSP、DNS）通常被用户代理用来从 CDN 请求内容，并被 CDN 请求路由系统用来重定向用户代理请求。CDNI 工作组不需要为此定义新的协议。但是请注意，CDNI 控制平面接口可能会间接影响通过请求接口（例如 URI）交换的某些信息。CDN之间的内容获取接口（即一段内容从一个CDN到另一个CDN的实际交付的数据平面接口）。这预计将使用现有协议，例如 HTTP 或其他论坛中定义的协议，用于源服务器和 CDN 之间的内容获取（例如，电信行业解决方案联盟 IPTV 互操作性论坛内容点播服务的基于 HTTP 的 C2 参考点（ ATIS IIF CoD))。因此，鉴于促进互操作性，本文档中描述的 CDN 互连问题空间可能仅关注协议/协商方面，其中内容获取协议将在两个互连的 CDN 之间使用。最终用户/用户代理身份验证。最终用户/用户代理身份验证和授权是内容服务提供商的责任。内容准备，包括编码和转码。CDNI 架构旨在允许跨互联 CDN 分发被视为不透明对象的内容。对象的解释和处理以及代理对最终用户的这些对象的优化交付不在 CDNI 的范围内。数字版权管理 (Digital Rights Management，DRM)。DRM 是内容保护系统和用户代理之间的端到端问题。使用 CDNI 日志的应用程序（例如，收费、分析、报告等）。内部 CDN 接口和协议（即一个 CDN 内的接口和协议）。单个 CDN 的可扩展性。虽然 CDNI 接口/方法的可扩展性在范围内，但单个 CDN 的扩展方式不在范围内。请求路由系统选择 CDN 或代理的实际算法（但是，当需要跨 CDN 进行通信时，这些算法的输入所需的某些特定参数可能在范围内）。代理算法。例如，缓存算法和内容获取方法不在 CDNI 工作的范围内。与 CDNI 内容管理策略相关的内容管理（例如，内容删除）在范围内，但缓存使用的内部算法来确定何时不再缓存内容项（在没有任何特定元数据的情况下） ) 超出范围。元素管理界面。与 CDN 互连相关的商业、商业和法律方面。B.2、 与相关 IETF 工作组和 IRTF 研究组的关系B.2.1、 ALTO工作组正如 ALTO 工作组章程 [ALTO-Charter] 中所述：工作组将设计并指定应用层流量优化 (ALTO) 服务，该服务将为应用程序提供信息以执行优于随机的初始对等选择。ALTO 服务可能会采取不同的方法来平衡最大带宽、最小跨域流量、最低用户成本等因素。工作组将考虑 BitTorrent、无跟踪器 P2P 和其他应用程序的需求，例如内容分发网络 (CDN) 和镜像选择。特别是，ALTO 服务可以被 CDN 请求路由系统用来改进它对 CDN 代理的选择，以服务于特定的用户代理请求（或服务于来自另一个代理的请求）。[ALTO-CDN-USE-CASES] 描述了 CDN 能够从 ALTO 服务器获取网络拓扑和成本信息的许多用例，并讨论了如何将 CDN 请求路由用作 ALTO 的集成点到 CDN。在基于 CDN 互连的多 CDN 环境中，ALTO 服务有可能以相同的方式使用。例如，上游 CDN 可以在其决定中利用 ALTO 服务来选择应将用户请求委托给的下游 CDN。但是，ALTO 当前的工作是对本文档中描述的工作的补充而不是重叠，因为 ALTO 和 CDN 之间的集成是特定 CDN 的内部决定，因此超出了 CDNI 工作组的范围。需要进一步研究的一个领域是 ALTO 服务是否应提供附加信息以促进 CDNI CDN 选择。B.2.2、 DECADE工作组DECADE 工作组 [DECADE-Charter] 正在解决减少最后一英里上行链路以及由点对点 (peer-to-peer，P2P) 流和文件共享应用程序引起的骨干和传输链路流量的问题。它通过使应用程序端点能够从网络内存储服务提供内容并允许其他应用程序端点从那里检索内容来解决这个问题。以这种方式通过网络内存储服务交换数据，而不是通过直接通信，在以下情况下提供了显着的收益：从网内存储服务到应用端点的网络容量/带宽显着超过从应用端点到应用端点的容量/带宽（例如，由于最终用户上行链路瓶颈）；和内容将由应用程序端点的多个实例访问（例如，P2P 应用程序的典型情况）。而与任何其他数据分发应用程序的情况一样，DECADE 架构和机制可能用于通过网络内存储服务交换 CDNI 控制平面信息（而不是直接在终止 CDNI 接口的实体之间）邻居 CDN，我们观察到：从 DECADE 的角度来看，CDNI 将作为“内容分发应用程序”运行（即，将在 DECADE 之上运行）。将负责与网络内存储服务本身控制相关的信令信息的 DECADE 控制平面与负责特定于应用程序的 CDNI 交互（例如 CDNI 的交换）的 CDNI 控制平面集成在一起似乎没有明显的好处元数据、CDNI 请求重定向和 CDNI 日志信息的传输）。使用 DECADE 网络存储服务通常会带来有限的好处，因为 CDNI 接口预计会被每个 CDN 中的极少数 CDNI 客户端（如果不是一个）终止，并且 CDNI 客户端是预计在彼此直接通信时受益于高带宽/容量（至少与通过网络内存储服务器进行通信一样高）。DECADE 网络存储架构和机制理论上可用于在互连的 CDN 之间获取内容对象本身。在内容对象仅从上游 CDN 到下游 CDN 获取一次（然后根据需要在下游 CDN 内部分发）的典型情况下，预计这不会有明显的好处。但它可能在某些特定情况下有好处。由于 CDN 之间的获取协议超出了 CDNI 的工作范围，这个问题留待进一步研究。DECADE 网络内存储架构和机制也可能在指定的 CDN 中用于在该 CDN 的代理之间分发内容对象本身。由于 CDNI 的工作本身并不关心 CDN 内的操作，因此这个问题留待进一步研究。因此，DECADE 的工作可能与本文档中描述的 CDNI 工作互补，但不重叠。B.2.3、 PPSP工作组正如 PPSP 工作组章程 [PPSP-Charter] 中所述：点对点流媒体协议 (Peer-to-Peer Streaming Protocol，PPSP) 工作组为点对点 (P2P) 流媒体系统开发了两种信令和控制协议，用于传输具有近乎实时交付要求的实时和时移媒体内容...... PPSP 工作组设计了跟踪器和对等体之间的信令和控制协议（PPSP“跟踪器协议”）和对等体之间通信的信令和控制协议（PPSP“对等体协议”）。这两种协议使对等方能够在特定内容项目所需的时间限制内接收流数据。因此，PPSP 关注流内容本身的分发以及分发内容所需的必要信令和控制。因此，它有可能用于跨互联 CDN 获取流式内容。但是由于获取协议超出了 CDNI 建议的工作范围，我们将其留待进一步研究。此外，由于其流媒体性质，PPSP 不被视为适用于 CDNI 控制平面和 CDNI 数据表示的分发和控制。因此，PPSP 的工作可能与本文档中描述的 CDNI 工作互补，但不重叠。B.2.4、 IRTF P2P研究组在 IETF 77 的 P2P 研究组中介绍了有关 CDN 互连动机和技术问题的一些信息。该介绍可以在 [P2PRG-CDNI] 中找到。
-
发表了文章 2023-03-04
多协议标签交换 (MPLS) 标签堆栈条目：“EXP”字段重命名为“TC”字段
RFC5462：Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field，February 2009本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。版权声明版权所有 (c) 2009 IETF Trust 和确定为文档作者的人员。版权所有。本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定的约束，该法律规定自本文件发布之日起生效 (http://trustee.ietf.org/license-info)。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。梗概早期的多协议标签交换 (Multiprotocol Label Switching，MPLS) 文档定义了 MPLS 标签堆栈条目的形式。这包括称为“EXP 字段”的三位字段。这些文件没有定义该字段的确切用途，只是声明它“保留用于实验用途”。尽管 EXP 字段的预期用途是作为“服务等级”(Class of Service，CoS) 字段，但这些早期文档并未将其命名为 CoS 字段，因为此类 CoS 字段的使用未被认为是充分定义的。今天，许多标准文档将其用途定义为 CoS 字段。为避免对该字段的使用方式产生误解，重命名该字段变得越来越有必要。本文档将该字段的名称更改为“Traffic Class field”（“TC 字段”）。这样做时，它还更新定义 EXP 字段当前使用的文档。1、 介绍MPLS 标签堆栈条目的格式由 RFC 3032 [RFC3032] 定义，包括一个称为“EXP field”的三位字段。RFC 3032 没有定义该字段的确切用途，只是声明它“保留用于实验用途”。EXP 字段从一开始就旨在携带“服务等级”(CoS) 信息。在发布为 RFC 3032 的工作组文档的早期版本中，该字段实际上被称为“服务等级字段”。但是，在 RFC 3032 发布时，此“服务等级”字段的确切用法是未达成一致，该领域被指定为“实验性使用”；因此，此名称一直是“EXP 字段”。“用于实验用途”这一名称导致其他标准开发组织 (Standards Development Organizations，SDO) 和实施者假设可以将该领域用于其他目的。本文档更改了该字段的名称，以明确表明其用作流量分类字段。起初，我们讨论了使用原始的“CoS 字段”作为字段的名称，但有人指出，该名称不包括自 RFC 3032 发布以来在其用法方面发生的以下更改。1. EXP 字段的使用首先在 RFC 3270 [RFC3270] 中定义，其中指定了一种定义 Diffserv 标签交换路径 (Label Switched Paths，LSP) 变体的方法，称为 EXP-Inferred-PSC LSP (E-LSP)。PSC 是一个两阶段首字母缩写词，扩展为 PHB（Per Hop Behavior，每跳行为）调度类 (Scheduling Class，PSC)。2. RFC 3270 中定义的 EXP 字段的使用在 RFC 5129 [RFC5129] 中得到了进一步扩展，其中定义了 MPLS 中显式拥塞标记的方法。因此，本文档使用名称“流量类别字段（TC 字段）”，它更好地涵盖了潜在用途。MPLS TC 字段与 MPLS 封装的数据包相关，就像 IPv6 TC 字段与 IPv6 封装的数据包或 IPv4 Precedence 字段与 IPv4 封装的数据包相关一样。EXP 字段如何使用的定义在 RFC 3270 和 RFC 5129 中非常清楚。但是，这些 RFC 没有明确声明它们更新了 RFC 3032，并且这个事实直到本文档的工作开始后才被记录在 RFC 存储库中.本文档更新了 RFC 3032、RFC 3270 和 RFC 5129，以阐明 TC 字段的预期用途。对这些 RFC 的更改需要对这些文档中的实际文本进行一些更改；第 2 节解释了这些变化。本文档还更新了其他几个 RFC；见第 2.4 节。对于这些文档，更改仅限于更改标签堆栈输入字段的名称。本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119] 中的描述进行解释。2、 变更详情现在根据以下内容更新了三个 RFC 3032、3270 和 5129。2.1、 RFC 3032RFC 3032 第 4 页上的说明：3. 实验使用该三位字段保留供实验使用。本段现改为：3. 流量等级 (TC) 字段这个三位字段用于携带流量类别信息，名称的更改适用于它出现在 IETF RFC 和其他 IETF 文档中的所有地方。RFC 3270 和 RFC 5129 更新了 TC 字段的定义并描述了如何使用该字段。在 RFC 3032 第 3 页的图 1 中，标签堆栈条目的格式指定为：图1Label: 标签，标签值，20 位 Exp: Experimental Use，实验性使用，3 位 S: Bottom of Stack，栈底，1位 TTL: Time to Live，生存时间，8 位RFC 3032 中的图 1 现在已更改以匹配名称更改为 TC 字段：图1（新）Label: 标签，标签值，20 位 TC: Traffic Class field，流量类别字段，3 位 S: Bottom of Stack，栈底，1位 TTL: Time to Live，生存时间，8 位注意：将上图指定为“图 1（新）”是为了区分本文档中的图。它仍然是 RFC 3032 中的“图 1”。2.2、 RFC 3270RFC 3270 在第 6 页上说：1.2 EXP-Inferred-PSC LSP (E-LSP)单个 LSP 可用于支持一个或多个 OA。这样的 LSP 最多可以支持给定 FEC 的八个 BA，而不管这些 BA 跨越多少个 OA。对于此类 LSP，LSR 使用 MPLS Shim Header 的 EXP 字段来确定要应用于数据包的 PHB。这包括 PSC 和丢弃首选项。我们将此类 LSP 称为“EXP-inferred-PSC LSP”（E-LSP），因为在此 LSP 上传输的数据包的 PSC 取决于该数据包的 EXP 字段值。对于给定的此类 LSP，从 EXP 字段到 PHB（即到 PSC 和丢弃优先级）的映射，要么在标签设置时明确发出信号，要么依赖于预先配置的映射。E-LSP 的详细操作在下面的第 3 节中详细说明。RFC 3270 现在更新如下：A. 第一节“引言”末尾新增一段：EXP 字段已重命名为 TC 字段，因此 RFC 3270 中对 EXP 字段的所有引用现在都引用 TC 字段。B. 第 1.1 节“术语”中增加了一个新术语：TC Traffic Class（取代术语 EXP）C. 在第 1.1 节“术语”中，首字母缩略词 E-LSP 现在被理解为：E-LSP，Explicitly TC-encoded-PSC LSP，显式TC编码的PSC LSPRFC 3270 第 6 页上的第 1.2 节现在更改为：1.2 显式 TC 编码的 PSC LSP（E-LSP）EXP 字段已重命名为 TC 字段，因此 RFC 3270 中对 EXP 字段的所有引用现在都引用 TC 字段。但是，我们保留首字母缩略词 E-LSP（显式 TC-encoded-PSC LSP），因为该首字母缩略词被广泛使用。单个 LSP 可用于支持一个或多个 OA。这样的 LSP 最多可以支持给定 FEC 的八个 BA，而不管这些 BA 跨越多少个 OA。对于此类 LSP，LSR 使用 MPLS Shim Header 的 TC 字段来确定要应用于数据包的 PHB。这包括 PSC 和丢弃首选项。我们将此类 LSP 称为“显式 TC 编码 PSC LSP”（E-LSP），因为在此 LSP 上传输的数据包的 PSC 取决于该数据包的 TC 字段（以前称为 EXP 字段）值。对于给定的此类 LSP，从 TC 字段到 PHB（即到 PSC 和丢弃优先级）的映射要么在标签设置时明确发出信号，要么依赖于预先配置的映射。这是对 RFC 3032 [RFC3032] 的更新，符合 MPLS Shim 标头中该字段应如何使用（作为 TC 字段）的原始意图。RFC 3270 本身已由 RFC 5129 [RFC5129] 更新。E-LSP 的详细操作在 RFC 3270 的第 3 节中指定。2.3、 RFC 5129RFC 5129 现在更新如下：在第 1.1 节“背景”的末尾添加了一个新段落：EXP 字段已重命名为 TC 字段，因此 RFC 5129 中对 EXP 字段的所有引用现在都引用 TC 字段。RFC 5129 第 7 页的第 2 节（第 5 条）说：[Shayman] 提出了第三种可能的方法。在该方案中，内部 LSR 假设端点具有 ECN 能力，但在弹出最终标签时会检查该假设。如果内部 LSR 在 shim 报头的 EXP 字段中标记了 ECN，但 IP 报头表明端点不支持 ECN，则边缘路由器（或倒数第二个路由器，如果使用倒数第二跳弹出）丢弃数据包。我们推荐这种方案，我们称之为“每域 ECT 检查”，并在下一节中对其进行更精确的定义。它的主要缺点是会导致数据包在遇到拥塞后转发，却在 MPLS 域的出口被丢弃。第 8.1 节给出了该决定的基本原理。RFC 5129 的第 2 节（第 5 条）现已更新为： [Shayman] 提出了第三种可能的方法。在该方案中，内部 LSR 假设端点具有 ECN 能力，但在弹出最终标签时会检查该假设。如果内部 LSR 在 shim 标头的 TC 字段中标记了 ECN，但 IP 标头表示端点不具备 TC 功能，则边缘路由器（或倒数第二个路由器，如果使用倒数第二跳弹出）丢弃数据包。我们推荐这种方案，我们称之为“每域 ECT 检查”，并在下一节中对其进行更精确的定义。它的主要缺点是会导致数据包在遇到拥塞后转发，却在 MPLS 域的出口被丢弃。第 8.1 节给出了该决定的基本原理。该方案是对 RFC 3032 [RFC3032] 和 RFC 3270 [RFC3270] 的更新。2.4、 本次变更的范围本文档明确更新的 RFC 中有几个地方引用了“Exp 字段”，有时他们将该字段称为“Exp 位”、“EXP 位”或“EXP”。在所有这些情况下，引用现在都引用了 TC 字段。还有其他 RFC（例如 RFC 3272 [RFC3272]、RFC 3443 [RFC3443]、RFC 3469 [RFC3469]、RFC 3564 [RFC3564]、RFC 3985 [RFC3985]、RFC 4182 [RFC4182]、RFC 4364 [RFC4364]、RFC 4379 [RFC4379]、RFC 4448 [RFC4448] 和 RFC 4761 [RFC4761]) 引用了“Exp 字段”；有时他们将该字段称为“Exp 位”、“EXP 位”和“EXP”。对于所有 RFC，包括但不限于本段中提到的那些，此类引用现在引用 TC 字段。3、 TC字段的使用由于 TC 字段中的比特数有限，因此它们用于 QoS 和 ECN（Explicit Congestion Notification，显式拥塞通知）功能的目的是灵活的。这些函数可能会重写 TC 字段中的所有或部分位。当前的实现查看带有和不带有标签上下文的 TC 字段，并且可以将 TC 字段复制到推送到标签堆栈上的标签堆栈条目。这样做是为了避免将标签堆栈条目推送到与其余标签堆栈条目具有不同 TC 字段的现有标签堆栈上。4、 安全考虑本文档仅更改 MPLS shim 头中的一个字段的名称，因此不引入任何新的安全考虑。5、 致谢作者要感谢 Stewart Bryant、Bruce Davie、George Swallow 和 Francois Le Faucheur 对当前文档的投入和审阅。作者还要感谢 George Swallow、Khatri Paresh 和 Phil Bedard 在语法和拼写方面的帮助；特别感谢 Adrian Farrel 仔细审查并帮助在 RFC-sea 中搜索引用 EXP 字段的 RFC。6、 参考文献6.1、 规范参考[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. [RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003. [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.6.2、 参考资料[Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal Congestion Withi
-
发表了文章 2023-03-04
IPsec ESP 数据包的 UDP 封装
RFC3948：UDP Encapsulation of IPsec ESP Packets，January 2005本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（Internet Official Protocol Standards，STD 1）。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2005)。梗概该协议规范定义了在 UDP 数据包内封装和解封装 IP 封装安全载荷 (Encapsulating Security Payload，ESP) 数据包以遍历网络地址转换器的方法。本文档中定义的 ESP 封装可用于 IPv4 和 IPv6 场景。无论何时协商，都将封装与互联网密钥交换 (Internet Key Exchange，IKE) 一起使用。1、 简介该协议规范定义了在 UDP 数据包中封装和解封装 ESP 数据包以穿越网络地址转换器 (Network Address Translators，NAT) 的方法（参见 [RFC3715]，第 2.2 节，案例 i）。UDP 端口号与 IKE 流量使用的端口号相同，如 [RFC3947] 中所定义。选择共享 IKE 和 UDP 封装的 ESP 流量的端口号是因为它提供了更好的扩展性（NAT 中只有一个 NAT 映射；无需发送单独的 IKE keepalive）、更容易配置（仅在防火墙中配置一个端口），更容易实现。客户端的需求应该决定支持传输模式还是隧道模式（参见 [RFC3715]，第 3 节，“远程办公场景”）。L2TP/IPsec 客户端必须支持 [RFC3193] 中定义的模式。IPsec 隧道模式客户端必须支持隧道模式。支持此协议规范的 IKE 实现不得对 ESP 数据包使用 ESP SPI 字段零。这样可以确保 IKE 数据包和 ESP 数据包可以相互区分。如本文档中所定义，ESP 数据包的 UDP 封装是根据 IPv4 报文头编写的。IPv6 报文头不能用作外部报文头和/或内部报文头没有技术原因。由于 IPsec AH 中对外部 IP 地址的保护本质上与 NAT 不兼容，因此 IPsec AH 被排除在本协议规范的范围之外。该协议还假定 IKE（IKEv1 [RFC2401] 或 IKEv2 [IKEv2]）用于协商 IPsec SA。不支持手动键控。本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是解释为 [RFC2119] 中的描述。2、 数据包格式2.1、 UDP 封装的 ESP 报文头格式UDP 报文头是标准的 [RFC0768] 报文头，其中* 源端口和目标端口必须与 IKE 流量使用的相同，* IPv4 UDP 校验和应该作为零值传输，并且* 接收器不得依赖于 UDP 校验和为零值。ESP 头中的 SPI 字段不得为零值。2.2、 端口 4500 的 IKE 报文头格式UDP 报文头是标准的 [RFC0768] 报文头，并按照 [RFC3947] 中的定义使用。本文档未对 IKE 数据包的校验和处理设置任何新要求。非 ESP 标记是与 ESP 数据包的 SPI 字段对齐的 4 个零值字节。2.3、 NAT-Keepalive 数据包格式UDP 报文头是标准的 [RFC0768] 报文头，其中* 源端口和目标端口必须与第 2.1 节的 UDP-ESP 封装使用的相同，* IPv4 UDP 校验和应该作为零值传输，并且* 接收器不得依赖于 UDP 校验和为零值。发送方必须使用值为 0xFF 的一个八位字节长的有效载荷。接收方应该忽略接收到的 NAT-keepalive 数据包。3、 封装和解封装过程3.1、 辅助程序3.1.1、 隧道模式解封装 NAT 程序当使用隧道模式传输数据包时（参见 [RFC3715]，第 3 节，标准“模式支持”和“电信场景”），内部 IP 报文头可能包含不适合当前网络的地址。此过程定义了如何将这些地址转换为适合当前网络的地址。根据本地策略，必须执行以下操作之一：1. 如果策略中为对端封装的报文定义了有效的源IP地址空间，则根据策略检查内部报文的源IP地址是否有效。2. 如果已经为远程对端分配了地址，则检查内部数据包中使用的源IP地址是否为分配的IP地址。3. 对数据包进行 NAT，使其适合在本地网络中传输。3.1.2、 传输模式解封装 NAT 程序当使用传输模式传输数据包时，由于传输过程中 IP 报文头部分的变化，包含的 TCP 或 UDP 报文头将具有不正确的校验和。此过程定义了如何修复这些校验和（参见 [RFC3715]，第 2.1 节，情况 b）。根据本地策略，必须执行以下操作之一：1、如果ESP头后面的协议头是TCP/UDP头，并且根据[RFC3947]已经收到对端真实的源IP地址和目的IP地址，增量重新计算TCP/UDP校验和：* 从校验和中减去接收到的数据包中的 IP 源地址。* 将通过 IKE 收到的真实 IP 源地址添加到校验和（从 NAT-OA 获得）* 从校验和中减去接收到的数据包中的 IP 目的地址。* 将通过 IKE 接收到的真实 IP 目标地址添加到校验和（从 NAT-OA 获得）。注意：如果给定地址（例如，源地址）的接收地址和实际地址相同，则操作取消并且不需要执行。2. 如果ESP头之后的协议头是TCP/UDP头，则重新计算TCP/UDP头中的校验和字段。3. 如果 ESP 头之后的协议头是 UDP 头，则将 UDP 头中的校验和字段设置为零。如果 ESP 报文头之后的协议是 TCP 报文头，并且如果有一个选项可以向堆栈标记不需要计算 TCP 校验和，则可以使用该标志。这应该只在传输模式下进行，并且数据包是完整性保护的。必须验证隧道模式 TCP 校验和。（这并不违反 [RFC1122] 中第 4.2.2.7 节的精神，因为发送方正在生成校验和并由接收方验证。该校验和是 IPsec 对数据包执行的完整性。）此外，一个实现可以修复任何被 NAT 破坏的包含的协议（参见 [RFC3715]，第 2.1 节，案例 g）。3.2、 传输模式ESP封装1. 采用普通ESP封装方法。2. 在所示位置插入格式正确的 UDP 报头。3. 编辑 IP 报文头中的总长度、协议和报文头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。3.3、 传输模式 ESP 解封装1. UDP 报头从数据包中删除。2. 编辑新 IP 报头中的总长度、协议和报头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。3. 使用普通的ESP解封装程序。4. 使用传输模式解封装 NAT 过程。3.4、 隧道模式ESP封装1. 采用普通ESP封装方法。2. 在所示位置插入格式正确的 UDP 报头。3. 编辑新 IP 报头中的总长度、协议和报头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。3.5、 隧道模式 ESP 解封装1. UDP 报头从数据包中删除。2. 编辑新 IP 报头中的总长度、协议和报头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。3. 使用普通的ESP解封装程序。4. 使用隧道模式解封装NAT程序。4、 NAT Keepalive程序发送 NAT-keepalive 数据包的唯一目的是在对等体之间的连接期间保持 NAT 映射处于活动状态（参见 [RFC3715]，第 2.2 节，案例 j）。NAT-keepalive 数据包的接收不得用于检测连接是否有效。如果对等体之间存在一个或多个阶段 I 或阶段 II SA，或者如果此类 SA 最多在 N 分钟之前存在，则对等体可以发送 NAT 保持连接数据包。N 是本地可配置参数，默认值为 5 分钟。如果根据 [RFC3947] 检测到需要，并且在 M 秒内没有其他数据包发送到对等体，则对等体应该发送 NAT-keepalive 数据包。M 是本地可配置参数，默认值为 20 秒。5、 安全考虑5.1、 隧道模式冲突实施者被警告说，远程对等体可能会协商在 SGW（security gatewa，安全网关）中重叠的条目，这是一个影响隧道模式的问题（参见 [RFC3715]，第 2.1 节，案例 e）。因为 SGW 现在会看到两个可能的 SA，它们通向 10.1.2.3，所以它可能会混淆将来自 Suzy 的服务器的数据包发送到哪里。实施者必须设计出防止这种情况发生的方法。建议 SGW 为 Ari 和 Bob 的笔记本电脑分配本地唯一的 IP 地址（通过使用 IPsec 上的 DHCP 等协议）或使用 NAT 将 Ari 和 Bob 的笔记本电脑源 IP 地址更改为这些本地唯一地址，然后再将数据包转发到 Suzy 的服务器。这涵盖了 [RFC3715] 中第 3 节的“Scaling”标准。请参阅附录 A。5.2、 传输方式冲突另一个类似的问题可能发生在传输模式中，2 个客户端 Ari 和 Bob 在同一个 NAT 后面安全地与同一个服务器通信（参见 [RFC3715]，第 2.1 节，案例 e）。Cliff 想与同一台服务器畅所欲言。现在，服务器上的传输 SA 将如下所示：到 Ari：服务器到 NAT，，UDP encap <4500，Y>给 Bob：服务器到 NAT，，UDP encap <4500，Z>Cliff 的流量畅通无阻，因此没有 SA。<traffic desc> 是协议和端口信息。UDP 封装端口是在 2.1 节的 UDP 封装的 ESP 格式中使用的端口。Y、Z 是 NAT 在 IKE 协商时分配的动态端口。因此，来自 Ari 笔记本电脑的 IKE 流量通过 UDP <4500,4500> 流出。它以 UDP 的形式到达服务器，其中 Y 是动态分配的端口。如果 与 重叠，那么简单的过滤器查找可能不足以确定必须使用哪个 SA 来发送流量。实现必须处理这种情况，要么通过禁止冲突连接，要么通过其他方式。现在假设 Cliff 想要以明文方式连接到服务器。这将很难配置，因为服务器已经有一个策略（从服务器到 NAT 的外部地址）来保护 。对于完全不重叠的流量描述，这是可能的。示例服务器策略可能如下：到 Ari：服务器到 NAT，所有 UDP，加密到 Bob：服务器到 NAT，所有 TCP，加密到 Cliff：服务器到 NAT，所有 ICMP，明文请注意，此策略还允许 Ari 和 Bob 向服务器发送明文 ICMP。服务器将 NAT 后面的所有客户端视为相同的 IP 地址，因此原则上不可能为相同的流量描述符设置不同的策略。服务器上的一个有问题的配置示例如下：服务器到 NAT、TCP、加密（适用于 Ari 和 Bob）服务器到 NAT、TCP、铭文（用于 Cliff）服务器无法执行他的策略，因为行为不端的 Bob 可能会明文发送流量。这与 Cliff 以明文方式发送流量时无法区分。因此，不可能保证来自 NAT 后面的某些客户端的安全性，同时允许来自同一 NAT 后面的不同客户端的明文。但是，如果服务器的安全策略允许这样做，则它可以尽最大努力进行加密：如果来自 NAT 后面的客户端启动安全性，他的连接将受到保护。如果他发送明文，服务器仍将接受该明文。为了安全保证，服务器上不得允许上述有问题的场景。为了尽力而为安全，可以使用这种情况。请参阅附录 A。6、 IAB 考虑UNSAF [RFC3424] 问题由 IPsec-NAT 兼容性要求文档 [RFC3715] 解决。7、 致谢感谢 Tero Kivinen 和 William Dixon，他们为本文档做出了积极贡献。感谢 Joern Sierwald、Tamir Zegman、Tatu Ylonen 和 Santeri Paavolainen，他们为有关 NAT 穿越的早期文档做出了贡献。8、 参考文献8.1、 规范参考[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.8.2、 参考资料[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004.附录A、 潜在NAT多客户端解决方案的说明本附录阐明了同一 NAT 后面的多个客户端同时连接到同一目标 IP 地址的问题的潜在解决方案。5.1 和 5.2 节说你必须避免这个问题。由于这不是有线协议的问题，而是本地实现的问题，因此这些机制不属于协议规范本身。它们在本附录中列出。选择一个选项可能取决于一个人使用/支持 IPsec NAT-T 的场景。此列表并非详尽无遗，因此可能存在其他解决方案。我们首先描述解决所有上层协议问题的通用选择。ESP 传输模式的通用选择：Tr1) 在 IPsec 解封装之上实现内置的 NAT（network address translatio，网络地址转换）。Tr2) 在 IPsec 解封装之上实现内置的 NAPT（network address port translatio，网络地址端口转换）。Tr3) 一旦检测到 NAT，发起方可以决定不请求传输模式，而是可以请求隧道模式 SA。这可能是响应方拒绝传输模式后的重试，或者发起方可能会选择最初提出隧道 SA。这并不比知道是否提出没有 NAT 的传输模式或隧道模式更困难。如果由于某种原因，响应者喜欢或需要隧道模式用于 NAT 穿越，它必须拒绝传输模式的快速模式 SA 提议。ESP 隧道模式的通用选择：Tn1) 与 Tr1 相同。Tn2) 与 Tr2 相同。Tn3) 如果发起方可以通过其隧道 SA 分配一个地址，而响应方使用 DHCP，则此选项是可能的。发起者最初可以通过 DHCP-IPsec 方法请求内部地址，而不管它是否知道它在 NAT 之后。在响应者的快速模式SA传输模式提议失败后，它可以重新发起DHCP隧道SA的IKE快速模式协商。这发生在发送 NAT-OA 载荷时，或者因为它从 NAT-D 发现发起方位于 NAT 之后，并且其本地配置/策略仅在通过 DHCP-IPsec 分配地址时才接受 NAT 连接。还有一些实现选择提供有限的互操作性。如果选择了这些选项，实施者应该指定哪些应用程序或协议应该工作。请注意，如下所述，Tr4 和 Tn4 都不能用于 TCP 流量。ESP 传输模式的有限互操作性选择：Tr4) 实现对入站和出站 IPsec SA 的上层协议感知，使其不使用源 IP 和源端口作为会话标识符（例如，映射到 IPsec SA 对的 L2TP 会话 ID使用 UDP 源端口或源 IP 地址以获得对等唯一性）。Tr5) 实现与 IKE 发起的应用集成，以便在 IKE 快速模式 SA 提议被响应方拒绝时重新绑定到不同的源端口；然后它可以重新提出新的 QM 选择器。ESP 隧道模式的有限互操作性选择：Tn4) 与 Tr4 相同。完整的版权声明版权所有 (C) 互联网协会 (2005)。本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性保证。知识产权对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不代表它已作出任何独立努力来确定任何此类权利。有关 IETF 文件中权利的 IETF 程序的信息可以在 BCP 78 和 BCP 79 中找到。可以获得向 IETF 秘书处披露的知识产权副本和任何许可保证，或试图获得通用许可或本规范的实施者或用户使用此类专有权利的许可的结果来自 IETF 在线 IPR 存储库，网址为 http://www.ietf.org/ipr。IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准可能需要的技术的其他专有权利。请将信息发送至 IETF ietf-ipr@ietf.org。致谢RFC 编辑器功能的资金目前由互联网协会提供。
-
发表了文章 2023-03-04
一种基于流量的检测不活跃互联网密钥交换(IKE)对等体的方法
RFC3607：A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers，February 2004本备忘录的状态本备忘录为 Internet 社区提供信息。它不指定任何类型的 Internet 标准。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2004)。保留所有权利。梗概本文档描述了许多供应商目前正在使用的检测失效互联网密钥交换 (Internet Key Exchange，IKE) 对等体的方法。这种称为死对等体检测 (Dead Peer Detection，DPD) 的方法使用 IPSec 流量模式来最大限度地减少确认活动所需的 IKE 消息数量。与其他保活机制一样，需要 DPD 来确定何时执行 IKE 对等体故障转移并回收丢失的资源。1、 简介当两个对等体通过 IKE [2] 和 IPSec [3] 通信时，可能会出现两者之间的连接意外断开的情况。这种情况可能是由于路由问题、一台主机重启等原因造成的，在这种情况下， IKE 和 IPSec 通常无法识别对等体连接的丢失。因此，SA 可以一直保留到它们的生命周期自然到期，从而导致数据包被隧道传送到遗忘的“黑洞”情况。通常需要尽快识别黑洞，以便实体可以快速故障转移到不同的对等体点。同样，有时需要检测黑洞以恢复丢失的资源。检测死 IKE 对等体的问题已通过需要发送周期性 HELLO/ACK 消息以证明活跃性的提案解决。这些方案往往是单向的（仅 HELLO）或双向的（HELLO/ACK 对）。在本文档中，“heartbeat”一词将指证明活跃性的单向消息。同样，“keepalive”一词将指双向消息。当前心跳和保活提议的问题在于它们依赖于定期发送的消息。在实现中，这转化为管理一些定时器来为这些消息间隔提供服务。同样，因为通常需要快速检测死对等体点，这些消息必须以某种频率发送，再次转化为消息处理的相当大的开销。在管理大量并发 IKE 会话的实施和安装中，这些定期的心跳/保持连接被证明是不可行的。为此，许多供应商已经实施了他们自己的方法来检测对等体活跃度，而无需定期发送消息。本信息文档描述了这些实施的当前实践。这种称为死对等体点检测 (DPD) 的方案依赖于IKE Notify 消息，用于查询 IKE 对等体的活跃度。本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC-2119 [1] 中的描述进行解释。2、 文档路线图如上所述，已经提出了检测死对等体问题的解决方案。第 3 节阐述了使用 IKE 消息交换来查询对等体点活跃度的基本原理。第 4 节检查了基于 keepalives 的方法以及基于心跳的方法。第 5 节全面介绍了 DPD 提案，突出了 DPD 与第 4 节中提出的方案之间的差异并强调了可扩展性问题。第 6 节检查了围绕重放消息和虚假的存活。3、 定期消息交换以证明活跃度的基本原理正如介绍中提到的，通常需要尽快检测到对等体无法访问。IKE 没有提供任何方法来实现这一点——除了等待重新加密期间，然后尝试（并且重新加密失败）。这将导致在安全联盟 (security association，SA) 的剩余生命周期内失去连接一段时间，在大多数部署中，这是不可接受的。因此，需要一种方法来随意检查对等体的状态。不同的方法有出现，通常使用 IKE 通知来查询对等体方的活跃度。这些方法依赖于双向“keepalive”消息交换（HELLO 后跟一个 ACK），或单向“heartbeat”消息交换（仅 HELLO）。部分考虑了这两种方案。4、 Keepalives和Heartbeats4.1、 Keepalives考虑一个keepalives方案，其中peer A和peer B需要定期确认彼此的活跃度。消息通过经过身份验证的通知有效载荷交换。两个peer必须就发送keepalive的时间间隔达成一致，这意味着一些协商是阶段 1 期间需要。为了使任何快速故障转移成为可能，还必须以相当频繁的间隔发送保活——大约 10 秒左右。在这个假设的保活场景中，对等体方 A 和 B 同意每 10 秒交换保活。本质上, 每 10 秒，一个 peer 必须向另一个发送一个 HELLO。这个 HELLO 作为发送实体活跃度的证明。反过来，另一个 peer 必须确认每个 keepalive HELLO。如果 10 秒过去了，并且一方没有收到 HELLO，它将自己发送 HELLO 消息，使用对等体的 ACK 作为活跃度的证明。收到 HELLO 或 ACK 会导致实体的 keepalive 计时器重置。在特定时间段内未能收到 ACK 表示错误。以下说明：场景1：对等体 A 的 10 秒计时器首先过去，并向 B 发送 HELLO。B 以 ACK 响应。场景2：Peer A 的 10 秒计时器首先过去，它向 B 发送 HELLO。B 没有响应。A 可以重传，以防其初始 HELLO 丢失。这种情况描述了 Peer A 如何检测到它的 peer 已死。在一些错误之后，A 假设 B 已经死了；删除 SA 并可能启动故障转移。该方案的一个优点是，对另一方的活跃度感兴趣的一方开始消息交换。在场景1中，对等体方A对节点B的活跃度感兴趣，因此对等体方A发送HELLO。可以想象在这种方案中，对等体方 B 永远不会对节点 A 的活跃度感兴趣。在这种情况下，发起交换的责任总是落在节点 A 身上。4.2、 Heartbeats相比之下，考虑一个涉及单向（未确认）消息的存活证明方案。对其对等体方的活力感兴趣的实体将依赖对等体方本身发送展示活力的定期消息。在这样的方案中，消息交换可能如下所示 ：场景 3：Peer A 和 Peer B 对彼此的活跃度感兴趣。每个 Peer 都依赖另一个发送周期性的 HELLO。场景 4：Peer A 未能收到 B 的 HELLO 并将其标记为 Dead。这就是实体检测其 Peer 已死的方式。过了一段时间，A 假设 B 已经死了。这种方案的缺点是依赖peer表现活跃度。为此，peer B可能永远不会对peer A的活跃度感兴趣。但是，如果A对B的活跃度感兴趣，B必须意识到这一点，并保持必要的定期向 A 发送 HELLO 的状态信息。这种方案的缺点在远程访问场景中变得明显。考虑一个 VPN 聚合器，它终止大量会话（大约 50,000 个对等体点）。每个对等体点都需要公平快速故障转移，因此需要聚合器每 10 秒左右发送一次 HELLO 数据包。这种方案缺乏可扩展性，因为聚合器必须每隔几秒发送 50,000 条消息。在这两种方案（keepalives 和 heartbeats）中，必须发生一些消息间隔的协商，以便每个实体可以知道其对等体方期望 HELLO 的频率。这立即增加了一定程度的复杂性。同样，需要发送定期消息（不考虑其他 IPSec/IKE 活动），也会增加系统的计算开销。5、 DPD协议DPD 通过引入更合理的消息交换逻辑来解决 IKE keepalives 和 heartbeats 方案的缺点。本质上，keepalives 和 heartbeats 要求定期交换 HELLO。相比之下，使用 DPD，每个对等体方的 DPD 状态在很大程度上独立于其他的。一个对等体点可以在需要时自由地请求活跃度证明——而不是在规定的时间间隔内。DPD 交换的这种异步特性允许发送更少的消息，这就是 DPD 实现更大可扩展性的方式。作为详细说明，考虑两个 DPD 对等体点 A 和 B。如果两者之间存在正在进行的有效 IPSec 流量，则几乎不需要活跃度证明。IPSec 流量本身就是活跃度的证明。如果，另一方面，一段时间内没有数据包交换，每个peer的活跃度是有问题的。但是，只有在有流量要发送的情况下才迫切需要知道peer的活跃度。例如，如果peer A有一些IPSec数据包空闲一段时间后发送，需要知道peer B是否还活着。此时peer A可以发起DPD交换。为此，每个对等体点可能对检测活跃度证明有不同的要求。例如，对等体点 A 可能需要快速故障转移，而对等体点 B 对资源清理的要求则不那么紧迫。在 DPD 中，每个对等体点都可以定义自己的“担忧度量”：定义 DPD 交换紧迫性的时间间隔。继续该示例，对等体 A 可能将其 DPD 间隔定义为 10 秒。然后，如果对等体方 A 发送出站 IPSec 流量，但在 10 秒内未能收到任何入站流量，则它可以发起 DPD 交换。另一方面，Peer B 将其不太紧急的 DPD 间隔定义为 5 分钟。如果 IPSec 会话空闲 5 分钟，Peer B 可以在下次向 A 发送 IPSec 数据包时发起 DPD 交换。重要的是要注意，关于何时启动 DPD 交换的决定是特定于实现的。实现甚至可能定义 DPD 消息在空闲期之后定期发送。有关更多实现建议，请参见第 5.5 节。5.1、 DPD 供应商 ID为了演示 DPD 功能，实体必须发送 DPD 供应商 ID。IKE 会话的双方必须在 DPD 交换开始之前发送 DPD 供应商 ID。DPD 供应商 ID 的格式是：其中 HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}，和当前 MJR1 和 0。如果它希望参与 DPD 交换，IKE 对等体必须发送供应商 ID。5.2、 消息交换DPD 交换是一个双向（HELLO/ACK）通知消息。交换定义为：R-U-THERE 消息对应于“HELLO”，R-U-THERE-ACK 对应于“ACK”。这两个消息都只是 ISAKMP Notify 有效载荷，因此，本文档定义了这两种新的 ISAKMP Notify 消息类型：发送 DPD 供应商 ID 的实体必须响应 R-U-THERE 查询。此外，实体必须拒绝未加密的 R-U-THERE 和 R-U-THERE-ACK 消息。5.3、 NOTIFY(R-U-THERE/R-U-THERE-ACK)消息格式发送时，R-U-THERE 消息必须采用以下形式：由于此消息是 ISAKMP NOTIFY，因此应相应设置 Next Payload、RESERVED 和 Payload Length 字段。其余字段设置为：- Domain of Interpretation：解释域（4 个八位字节），应该设置为 IPSEC-DOI。- Protocol ID：协议ID(1 octet)，必须设置为 ISAKMP 的协议 ID。- SPI Size ：SPI 大小（1 个八位字节），应设置为十六 (16)，即两个八位字节大小的 ISAKMP cookie 的长度。- Notify Message Type：通知消息类型（2 个八位字节），必须设置为 R-U-THERE- Security Parameter Index：安全参数索引（16 个八位字节），应该设置为 IKE SA 的发起方和响应方的 cookie（按此顺序）- Notification Data：通知数据（4 个八位字节），必须设置为与此消息对应的序列号R-U-THERE-ACK 消息的格式是相同的，除了通知消息类型必须设置为 R-U-THERE-ACK。同样，通知数据必须发送到与接收到的 R-U-THERE 消息对应的序列号。5.4、 DPD 交换的动力再一次，DPD 不强制要求在任何时间交换 R-U-THERE 消息，而不是依靠某些协商的时间间隔来强制交换消息。相反，IKE 对等体方应该仅在对这个 peer 的活跃度感兴趣。为此，如果流量在两个 peer 之间定期交换，任何一个 peer 都应该使用这个流量作为活跃度的证明，并且两个 peer 都不应该发起 DPD 交换。对等体点必须跟踪给定 DPD 交换的状态。也就是说，一旦它发送了一个 R-U-THERE 查询，它就会在某个实现定义的时间段内期待一个 ACK 响应。一个实现应该重传 R-U-THERE 查询当它未能收到 ACK 时。经过一定数量的重传消息后，实现应该假设其对等体方不可达，并删除对等体方的 IPSec 和 IKE SA。5.5、 实施建议由于只有当没有流量交换时，对等体方的活跃度才会受到质疑，因此可行的实现可能从监控空闲开始。沿着这些思路，只有当有出站流量要发送时，对等体方的活跃度才重要。为此，实现可以当有一段时间空闲时启动 DPD 交换（即，发送 R-U-THERE 消息），然后是希望发送出站流量。同样，如果实体已发送出站 IPSec 流量，则它可以启动 DPD 交换，但是没有收到任何入站 IPSec 数据包作为响应。一个完整的 DPD 交换（即 R-U-THERE 的传输和相应的 R-U-THERE-ACK 的接收）将作为活跃度的证明，直到下一个空闲期。同样，由于 DPD 不强制要求任何间隔，因此此“空闲期”（或“担忧指标”）留作实施决策。它不是协商值。5.6、 比较DPD 相对于传统的 keepalives 和 heartbeats 方案提供的性能优势来自于不需要发送常规消息的事实。回到 4.1 节中提供的示例，像所提供的那样的 keepalive 实现需要一个计时器来指示何时发送 HELLO 消息和另一个定时器以“超时”来自对等体的 ACK（这也可以是重传定时器）。类似地，4.2 节中介绍的心跳方案需要保持一个定时器来发信号何时发送 HELLO，以及另一个定时器来表示对等体方的 HELLO 期望。相比之下，DPD 方案需要保留时间戳以跟踪来自对等体的最后接收流量（从而标记“ idle period”。一旦发送了 DPD R-U-THERE 消息，实现只需要维护一个定时器来通知重传。因此，维护活动定时器状态的需要减少了，从而导致可扩展性改进（假设维护时间戳比活动计时器成本更低）。此外，由于 DPD 交换仅在实体最近没有收到来自其对等体方的流量时才发生，因此要发送和处理的 IKE 消息数量也减少了。因此，DPD 的可扩展性比 keepalives 和 heartbeats 好得多。DPD 维护由 keepalives 提供的 HELLO/ACK 模型，因为它遵循仅由对其对等体方的活跃度感兴趣的实体发起交换。6、 抗重放攻击和活体虚假证明6.1、 DPD 消息中的序列号为了防止消息重放攻击和错误的活性证明，每个 R-U-THERE 消息必须提供一个 32 位的序列号。R-U-THERE 消息的响应者必须发送一个具有相同序列号的 R-U-THERE-ACK。收到 R-U-THERE-ACK 消息后，初始发送方应该检查序列号的有效性。如果序列号与随 R-U-THERE 消息发送的序列号不匹配，初始发送方应该拒绝 R-U-THERE-ACK .此外，R-U-THERE 和 R-U-THERE-ACK 消息的接收者都应该检查在有效载荷的 SPI 字段中呈现的发起者和响应者 cookie 的有效性。6.2、 序列号的选择和维护由于两个 DPD peer 都可以发起 DPD 交换（即两个 peer 都可以发送 R-U-THERE 消息），每个 peer 必须为 R-U-THERE 消息维护自己的序列号。会话中发送的第一个 R-U-THERE 消息必须是随机的选择的数字。为了防止滚动超过 32 位边界溢出，序列号的高位最初应该设置为零。随后的 R-U-THERE 消息必须将序列号增加一。序列号可以在到期时重置IKE SA，移动到新选择的随机数。每个实体也应该维护其对等体的 R-U-THERE 序列号，如果它未能匹配预期的序列号，实体应该拒绝 R-U-THERE 消息。实现可以维护一个可接受序列号的窗口，但本规范不假设这是如何完成的。同样，这是一个实现特定的细节。7、 安全注意事项正如上一节所强调的，DPD 使用序列号来确保活跃度。本节描述了使用序列号相对于随机 nonce 来确保活跃度的优势。虽然序列号确实要求实体保持每个对等体的状态，但它们也为某些重放攻击提供了一种额外的保护方法。考虑这样一种情况，对等体 A 向对等体 B 发送一个有效的 DPD R-U-THERE 消息。攻击者 C 可以拦截此消息并用多个消息副本淹没 B。B 必须解密和处理每个数据包（无论使用的是序列号还是随机数）。使用序列号 B 可以检测到数据包被重放：这些重放中的序列号数据包将与 B 期望从 A 接收的递增序列号不匹配。这防止 B 需要构建、加密和发送 ACK。相比之下，如果 DPD 协议使用随机数，它将无法让 B 检测到消息被重播（除非 B 维护了最近收到的随机数列表）。序列号的另一个好处是它增加了对端活跃度的额外保证。只要接收方验证 DPD R-U-THERE 消息的有效性（通过验证其递增的序列号），那么接收方就可以确保对端的发件人发起查询这一事实的活跃度。相比之下，随机数不能提供这种保证。8、 IANA 考虑此文档不需要 IANA 操作。DPD 使用来自私有范围的通知号码。9、 参考资料9.1、 规范性参考[1]Bradner, S., "Key words for use in RFCs to Indicate RequirementLevels", BCP 14, RFC 2119, March 1997.9.2、 参考资料[2]Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",RFC 2409, November 1998. [3]Kent, S. and R. Atkinson, "Security Architecture for theInternet Protocol", RFC 2401, November 1998.10、 完整的版权声明版权所有 (C) The Internet Society (2004)。本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性保证。知识产权对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序的信息可以在 BCP 78 和 BCP 79 中找到。可以获得向 IETF 秘书处披露的 IPR 副本和将提供的任何许可保证，或获得本规范的实施者或用户使用此类专有权利的一般许可或许可的尝试结果来自 IETF 在线 IPR 存储库，网址为 http://www.ietf.org/ipr。IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准可能需要的技术的其他专有权利。请通过 ietf-ipr@ietf 将信息发送给 IETF。组织。致谢RFC 编辑器功能的资金目前由互联网协会提供。
-
发表了文章 2023-03-04
CLAS：用于软件定义网络SDN的协作分层架构
RFC8597：Cooperating Layered Architecture for Software-Defined Networking (CLAS)，May 2019梗概软件定义网络 (Software-Defined Networking，SDN) 提倡将网络节点中的控制平面与数据平面分离，并将其逻辑集中在一个或一组控制实体上。大多数网络和/或服务智能被转移到这些控制实体。通常，这样的实体被视为以垂直、紧密集成的方式交互控制功能的概要。将控制功能从多个分布式网络节点重新定位到逻辑中央实体，在概念上将具有不同目的的多个控制功能放在一起。因此，现有的解决方案没有明确区分传输控制和依赖传输能力的服务。本文档描述了一种称为软件定义网络协作分层架构 (Cooperating Layered Architecture for Software-Defined Networking，CLAS) 的方法，其中与传输相关的控制功能与与服务相关的控制功能以这样一种方式区分，即它们可以独立提供和维护，并且可以遵循自己的演进路径。本备忘录的状态本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。这是对 RFC 系列的贡献，独立于任何其他 RFC 流。RFC 编辑已选择自行决定发布此文档，并且不对其实施或部署的价值作出任何声明。由 RFC 编辑批准发布的文件不适合任何级别的 Internet 标准；请参阅 RFC 7841 的第 2 节。有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8597。版权声明版权所有 (c) 2019 IETF Trust 和确定为文档作者的人员。版权所有。本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。1、 简介网络软件化的进步正在促进在电信运营商的服务和基础设施中引入可编程性。这通常是通过在网络中引入软件定义网络 (SDN) [RFC7149] [RFC7426] 功能来实现的，包括控制器和协调器。然而，这些 SDN 功能必须解决不同性质的问题。一方面，需要采取侧重于对网络进行编程以处理远程节点之间数字数据的连接或转发的操作。另一方面，还需要专门对处理（或操纵）此类数字数据的功能或服务进行编程的操作。SDN主张通过在网络节点中引入控制平面与数据平面之间的抽象，将网络节点中的控制平面与数据平面分离，使功能实体（通常称为SDN控制器）上的控制逻辑集中；可以部署一个或多个控制器。然后在转发实体（在网络节点处）和控制实体之间定义编程接口。通过该接口，控制实体指示转发平面中涉及的节点并相应地修改它们的流量转发行为。通过这种编程接口 [RFC7149]，可以预期支持其他功能（例如，性能监控、故障管理等）。大多数智能都转移到这种功能实体上。通常，这样的实体被视为以垂直、紧密集成的方式交互控制功能的概要。考虑一个全能控制实体管理网络的整体方面，尤其是传输网络和在其上支持的服务的方法，提出了许多问题：** 从供应商的角度来看，不同的部门通常负责处理服务和连接（即顶部服务的传输能力），上述方法为完整的服务提供和交付提供了不明确的责任。** 复杂的功能重用以提供服务。** 封闭的单片控制架构。** 功能组件难以实现互操作性和互换性。** 供应商之间的业务界限模糊，特别是在一个供应商仅提供连接而另一供应商在该连接之上提供更复杂服务的情况下。** 复杂的服务/网络诊断和故障排除，特别是确定哪一层对故障负责。将控制功能从多个分布式网络节点重新定位到另一个实体，在概念上将具有不同目的的多个控制功能放在一起。因此，现有的 SDN 解决方案没有明确区分服务和传输控制。这里，服务和传输之间的分离遵循 [Y.2011] 提供的区别，并在本文档的第 2 节中定义。本文档描述了一种称为 SDN 协作分层架构 (CLAS) 的方法，其中与传输相关的控制功能与与服务相关的控制功能以可以独立提供和维护的方式进行区分，并且可以遵循自己的演进路径。尽管存在这种差异，服务层和传输层（或 [Y.2011] 中的层）和相关组件之间的密切合作对于提供资源的有效利用是必要的。2、 术语本文档使用了以下术语：** Transport：传输，表示网络基础设施提供的传输能力。传输能力可以依赖于纯 IP 技术或其他方式，例如 MPLS 或光学。** Service：服务，表示利用传输能力的逻辑结构。本文档不对可以在传输基础设施之上构建的服务的功能范围做出任何假设。因此，可以向客户提供服务或调用服务以交付另一项（增值）服务。** Layer：层，指支持传输或服务能力的元素集，如前文所定义。在 [Y.2011] 中，这被称为“stratum”，这两个术语可以互换使用。** Domain：域，是一组具有共同属性或特征的元素。在本文档中，它适用于管理域（即属于同一组织的元素）、技术域（实现同类技术的元素，如光节点）等。** SDN Intelligence：SDN智能，指由一个节点或一组节点托管的决策过程。这些节点称为SDN控制器。智能可以是集中式的，也可以是分布式的。这两种方案都在本文件的范围内。SDN 智能依赖于来自各种功能块的输入，例如：网络拓扑发现、服务拓扑发现、资源分配、业务指南、客户档案、服务档案等。除了此处讨论的分层之外，SDN 智能的确切分解超出了本文档的范围。此外，本文档中使用了以下首字母缩略词：CLAS：Cooperating Layered Architecture for SDN，SDN 的协作分层架构FCAPS：Fault, Configuration, Accounting, Performance, and Securit，故障、配置、计费、性能和安全SDN：Software-Defined Networkin，软件定义网络SLA：Service Level Agreemen，服务水平协议3、 架构概述当前运营商网络支持多种传输技术上的多种服务（例如，IP 电话 (VoIP)、IPTV、移动 VoIP、关键任务应用等）。独立于底层传输能力的服务的提供和交付需要分离与服务相关的功能和传输网络的抽象，以隐藏底层传输技术的细节，同时提供一组通用的能力。从服务或传输网络的角度来看，这种分离可以提供配置灵活性和适应性。可以在公共传输基础设施之上提供多种服务；同样，不同的技术可以适应某种服务的连接要求。一致的服务交付（层间合作）需要这些元素之间的密切协调。本文件特别关注以下方法：** 向服务公开传输能力。** 获取服务的传输需求。** 通知服务智能底层传输事件，例如，根据底层传输事件调整服务决策过程。** 指示底层传输能力以适应新的要求等。一个示例是保证某些服务质量 (Quality-of-Service，QoS) 级别。不同的基于 QoS 的产品可以出现在服务层和传输层。应该建立用于链接服务和传输 QoS 机制的垂直机制，以便为最终用户提供质量保证。CLAS 架构假定逻辑上集中的控制功能被分成两个功能层。功能层之一包括与服务相关的功能，而另一层包含与传输相关的功能。两层之间的合作有望通过标准接口实现。图 1 显示了 CLAS 架构。它基于 ITU-T 在 [Y.2011] 中定义的下一代网络 (Next Generation Network，NGN) 架构中的功能分离，其中定义了两个功能层。这些层是服务层，包括与服务相关的功能，以及传输层，包括与传输相关的功能。这些层中每一层的功能进一步分为控制、管理和用户（或数据）平面。CLAS 采用 [Y.2011] 中描述的相同结构模型，但通过 SDN [RFC7149] 将其应用于可编程性目标。在这方面，CLAS 提倡以分开的方式处理服务和传输，因为它们的关注点不同。图 1：SDN 的协作分层架构在 CLAS 架构中，控制和管理功能都被认为是由一个或一组 SDN 控制器执行的（例如，由于可扩展性、可靠性），以存在分离的 SDN 控制器的方式提供 SDN 智能在服务和传输层。管理功能被认为是 SDN 智能的一部分，以允许在服务供应商生态系统中进行有效操作 [RFC7149]，尽管一些最初的提议并未将此类管理视为 SDN 环境 [ONFArch] 的一部分。此外，NGN 架构中包含的通用用户或数据平面功能在此称为资源平面功能。每个层中的资源平面由相应的SDN智能通过标准接口控制。SDN 控制器在服务的提供和交付方面进行合作。存在一个层次结构，其中服务 SDN 智能向传输 SDN 智能发出请求以提供传输功能。服务 SDN 智能充当传输 SDN 智能的客户端。此外，传输 SDN 智能与服务 SDN 智能交互以通知它有关传输网络中可以激发服务层中的操作的事件。尽管未在图 1 中显示，但每个层的资源平面都可以连接。这将取决于所提供的服务类型。此外，服务层可以为应用程序提供一个接口，以向这些应用程序或客户公开网络服务功能。3.1、 功能层如前所述，存在将传输相关功能与服务相关功能分开的功能拆分。两个层级合作以提供一致的服务。一致性由服务层确定和表征。3.1.1、 传输层传输层包括专注于通信端点之间（例如，最终用户设备之间、两个服务网关之间等）之间数据传输的功能。数据转发节点由传输 SDN 组件控制和管理。SDN智能中的控制平面负责指示转发设备为每次通信建立端到端的数据路径或确保转发服务正确设置。转发不能仅仅依赖于预先配置的条目；可以启用手段，以便涉及的节点可以动态地构建路由和转发路径（这将要求节点保留一些控制和管理能力来启用它）。最后，作为传输层功能的一部分，管理平面在这些设备上执行管理功能（即 FCAPS），例如故障或性能管理。3.1.2、 服务层服务层包含与提供服务和提供给外部应用程序的能力相关的功能。资源平面由服务交付所涉及的资源组成，如计算资源、注册中心、数据库等。控制平面负责控制和配置这些资源，并在客户端模式下与传输层的控制平面交互以请求给定服务的传输能力。同理，管理平面对业务相关资源进行管理动作，并与传输层中的管理平面进行交互，保证各层之间的管理协作。3.1.3、 递归性递归分层可能发生在某些使用场景中，其中传输层本身是在服务和传输层中构建的。除了纯数据传输（例如，给定 SLA [RFC7297] 的维护）之外，在提供补充有高级功能的传输服务时可能就是这种情况。[ONFArch] 中也讨论了递归性作为实现可扩展性和模块化的一种方式，其中每个更高的级别都可以提供更大的抽象能力。此外，递归可以允许一些涉及单个或多个管理域的多域场景，例如第 6.3 节中描述的那些。3.2、 平面分离CLAS 架构利用平面分离。如第 3.1.1 和 3.1.2 节所述，每个层都考虑三个不同的平面。这三个平面（与其他层中的相应平面）之间的通信基于开放的标准接口。3.2.1、 控制平面控制平面在逻辑上集中了各层的控制功能，直接控制相应的资源。[RFC7426] 介绍了控制平面在 SDN 架构中的作用。该平面是 SDN 智能的一部分，可以与相同或不同层中的其他控制平面交互以执行控制功能。3.2.2、 管理平面管理平面在逻辑上集中了每个层的管理功能，包括控制平面和资源平面的管理。[RFC7426]描述了SDN环境中管理平面的功能。该平面也是SDN智能的一部分，可以与驻留在同一层或不同层的SDN控制器中的相应管理平面进行交互。3.2.3、 资源平面资源平面包括用于传输或服务功能的资源。在某些情况下，服务资源可以连接到传输资源（例如，作为传输功能的终止点）；在其他情况下，它可以与传输资源分离（例如，一个数据库为最终用户保留注册）。[RFC7426] 中提出的转发和操作平面都将成为该架构中资源平面的一部分。4、 必备功能由于 CLAS 架构意味着具有不同目的和职责的不同层的交互，因此需要支持许多功能：** Abstraction：抽象，将物理资源映射到相应的抽象资源。** Service-Parameter Translation：服务参数转换，根据不同的策略将服务参数（例如，以 SLA 的形式）转换为传输参数（或能力）。** Monitoring：监控，为了动态更新（抽象的）资源状态同时考虑到例如流量负载的可用机制（例如，事件通知）。** Resource Computation：资源计算，能够决定哪些资源将用于给定服务请求的功能。例如，可以使用 PCE 之类的函数来计算/选择/决定某个路径。** Orchestration：编排，以最佳方式组合不同资源（例如 IT 和网络资源）的能力。** Accounting：计费，资源使用记录。** Security：安全性，组件之间的安全通信，例如防止 DoS 攻击。5、 SDN 控制器之间的通信分别驻留在 Service 和 Transport Strata 中的 SDN 控制器需要建立紧密的协调。应定义为每一层传输相关信息的机制。从服务的角度来看，Service SDN Intelligence 需要通过定义良好的 API 轻松访问传输资源，以检索传输层提供的能力。可能有不同的方式来获取这种传输感知信息，即通过发现或发布机制。在前一种情况下，服务 SDN 智能可以处理有关传输层提供的传输能力（包括资源）的完整信息。在后一种情况下，传输层揭示可用功能，例如，通过目录，减少底层网络的详细信息量。另一方面，传输层必须正确捕获服务需求。这些可以包括具有特定指标（例如延迟）的 SLA 要求、要提供的保护级别、最大/最小容量、适用的资源限制等。控制器之间的通信也必须是安全的，例如，通过防止拒绝服务或任何其他类型的威胁（同样，与网络节点的通信必须是安全的）。6、 部署场景根据给定部署中涉及的网络的特性，可以发现不同的情况。6.1、 全 SDN 环境本案例认为，提供和交付给定服务所涉及的网络具有 SDN 功能。6.1.1、 与单个传输层相关联的多个服务层单个传输层可以向多个服务层提供传输功能。传输层为每个服务层提供标准接口。服务层是传输层的客户。传输层提供的一些功能可以是传输资源的隔离（切片）、独立路由等。6.1.2、 与多个传输层相关联的单一服务层单个服务层可以利用不同的传输层来提供特定服务。服务层调用每个传输层的标准接口，并编排提供的传输功能以构建端到端的传输需求。6.2、 混合环境这种情况考虑了其中一个层完全或部分遗留的情况。6.2.1、 与传统传输层相关联的 SDN 服务层SDN 服务层可以通过互通功能与传统传输层交互，该功能能够使基于 SDN 的控制和管理服务相关命令适应传统传输相关协议，正如传统传输层所期望的那样。服务层中的 SDN 智能不知道底层传输层的遗留性质。6.2.2、 与 SDN 传输层相关联的传统服务层传统服务层可以通过互通功能的中介与支持 SDN 的传输层一起工作，该功能能够解释来自传统服务功能的命令并将它们转换为 SDN 协议，以便与支持 SDN 的传输层一起操作。6.3、 传输层多领域场景传输层可以由属于不同管理、拓扑或技术领域的传输资源组成。服务层可以与传输层中的单个实体交互，以防传输部分提供一些抽象功能来模拟单个层。这些抽象能力构成了传输层向使用该层的服务提供的服务本身。该服务侧重于提供传输能力，这与使用此类能力的最终通信服务不同。在这种特殊情况下，这种递归允许传输级别的多域场景。多域情况可能发生在单运营商和多运营商场景中。在单运营商场景中，多域或端到端抽象组件可以为所有域提供底层异构传输能力的同构抽象视图。传输层的多运营商场景应支持以编程方式跨相关网络建立端到端路径。例如，这可以通过每个管理域交换其流量工程信息 [RFC7926] 来实现。7、 用例本节介绍了许多用例，作为 CLAS 方法适用性的示例。7.1、 网络功能虚拟化 (NFV)NFV 环境提供两种可能的 SDN 控制级别 [GSNFV-EVE005]。一层是需要控制 NFV 基础设施 (Network Function Virtualization Infrastructure，NFVI) 以提供 VNF（Virtual Network Functions，虚拟网络功能）之间或 VNF 和 PNF（Physical Network Functions，物理网络功能）之间的端到端连接。第二个层次是VNF本身的控制和配置（换言之，这些VNF实现的网络服务的配置），这得益于SDN带来的可编程性。这两个控制问题本质上是分开的。然而，为了优化、扩展或影响彼此，可以预期两者之间的交互。7.2、 TE网络的抽象与控制TE 网络的抽象和控制 (Abstraction and Control of TE Networks，ACTN) [RFC8453] 提出了一个框架，该框架允许向客户提供虚拟网络的创建。ACTN 中“provider”的概念仅限于提供虚拟网络服务。这些服务本质上是传输服务，对应于 CLAS 中的传输层。另一方面，CLAS 中的服务层可以被同化为 ACTN 上下文中的客户。ACTN 定义了控制器的层次结构，以促进虚拟网络的创建和操作。为请求这些虚拟网络服务的客户与负责编排和服务此类请求的控制器之间的关系定义了一个接口。这种接口等同于图 1（第 3 节）中定义的服务和传输层之间的接口。8、 服务和传输层之间实施操作的挑战服务和传输问题的区别在两个层级之间的通信中提出了许多挑战。以下列表反映了一些已确定的挑战：** 层间交互的标准机制：如今，有许多提案可以满足从服务层到传输层的请求。一些提案可能是解决方案，如连接供应协商协议（Connectivity Provisioning Negotiation Protocol）[CPNP] 或中间控制器平面接口 (Intermediate-Controller Plane Interface，I-CPI) [ONFArch]。其他潜在的候选者可能是传输 API [TAPI] 或传输北向接口 [TRANS-NORTH]。这些选项中的每一个都有不同的范围。** 多供应商感知：在涉及多个传输级别供应商的多域场景中，服务层可能会或可能不会感知到这种域的多样性。如果服务层不知道多域情况，那么作为服务层请求入口点的传输层应该负责管理多域问题。相反，如果服务层感知到多域情况，它应该负责协调对不同底层传输层的请求，以组成服务端点（即服务功能）之间的最终端到端路径）。** SLA 映射：两个层都将处理 SLA，但这些 SLA 的性质可能不同。因此，每个层中的实体都需要将服务 SLA 映射到连接 SLA，以确保正确的服务交付。** 层之间的关联：层之间的关联可以预先配置，或者两个层都可以要求使用动态建立层之间关联的发现机制。** 安全性：如前所述，层之间的通信必须是安全的，以防止攻击和威胁。此外，应强制执行隐私，尤其是在传输级别解决多供应商场景时。** 计费：在层间的通信中应该支持对服务使用和消耗的资源的控制和计费。9、 IANA 考虑本文档没有 IANA 操作。10. 安全考虑CLAS 架构依赖于在 [RFC7149] 和 [RFC7426] 中引入的功能实体。因此，必须特别考虑 [RFC7149] 第 5 节中讨论的安全注意事项。服务和传输 SDN 控制器之间的通信必须依赖于实现以下目标的安全方法：** 在采取任何操作之前，必须启用相互认证。** 消息完整性保护。必须向每个控制器提供有关可以向对等控制器公开的信息集（和粒度）的指令。必须启用防止隐私数据泄露的手段（例如，从服务层到传输层）。要共享的确切信息集是特定于部署的。损坏的控制器可能会对另一个控制器造成一些干扰。应启用针对此类攻击的保护。此处描述的层之间通信的安全性应适用于要在它们之间定义的 API（和/或协议）。因此，安全问题将对应于特定的解决方案。11、 参考文献11.1、 规范参考[Y.2011] International Telecommunication Union, "General principles and general reference model for Next Generation Networks", ITU-T Recommendation Y.2011, October 2004, <https://www.itu.int/rec/T-REC-Y.2011-200410-I/en>.11.2、 参考资料[CPNP] Boucadair, M., Jacquenet, C., Zhang, D., and P. Georgatsos, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, draft-boucadair-connectivity-provisioning-protocol-15, December 2017. [GSNFV-EVE005] ETSI, "Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural Framework", ETSI GS NFV-EVE 005, V1.1.1, December 2015, <https://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/005/01.01.01_60/gs_nfv-eve005v010101p.pdf>. [ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", June 2014, <https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf>. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>. [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>. [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>. [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>. [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>. [SDN-ARCH] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., and P. Iovanna, "Cooperating Layered Architecture for SDN", Work in Progress, draft-irtf-sdnrg-layered-sdn-01, October 2016. [TAPI] Open Networking Foundation, "Functional Requirements for Transport API", June 2016, <https://www.opennetworking.org/wp-content/uploads/2014/10/TR-527_TAPI_Functional_Requirements.pdf>. [TRANS-NORTH] Busi, I., King, D., Zheng, H., and Y. Xu, "Transport Northbound Interface Applicability Statement", Work in Progress, draft-ietf-ccamp-transport-nbi-app-statement-05, March 2019.附录 A、 与 RFC 7426 的关系[RFC7426] 通过定义多个平面、抽象层和其中的接口或 API 来引入 SDN 分类法，作为阐明 SDN 的不同组成部分（网络设备、控制和管理）如何关联的手段。定义了许多平面，包括：** 转发平面：专注于根据从控制平面收到的指令在数据路径中传递数据包。** 操作平面：以管理网络设备的操作状态为中心。** 控制平面：专用于指示设备应如何转发数据包。** 管理平面：负责监控和维护网络设备。** 应用平面：允许以这种方式控制的所有设备用于不同目的（由每个应用程序确定）。除此之外，[RFC7426] 提出了许多抽象层，允许通过公共接口集成不同的平面。CLAS 将控制、管理和资源平面作为其架构的基本部分。本质上，控制平面修改受控资源的行为和动作。管理平面监控和检索这些资源的状态。最后，资源平面将与每个层的关注点相关的所有资源进行分组。从这个角度来看，CLAS 平面可以看作是 [RFC7426] 中定义的那些平面的超集。然而，在某些情况下，并非 [RFC7426] 中考虑的所有平面都可能完全存在于 CLAS 表示中（例如，服务层中的转发平面）。话虽如此，CLAS 层的内部结构可以遵循 [RFC7426] 中定义的分类法。不同之处在于通过区分服务和传输来实现 SDN 环境的专业化。致谢该文档之前在 IRTF SDN RG 中被讨论并采用为 [SDN-ARCH]。IRTF SDN RG 关闭后，该文件作为独立提交文件进行处理，以记录（部分）该小组的讨论。作者要感谢（按字母顺序） Bartosz Belter、Gino Carrozzo、Ramon Casellas、Gert Grammel、Ali Haider、Evangelos Haleplidis、Zheng Haomian、Giorgios Karagiani、Gabriel Lopez、Maria Rita Palatella、Christian Esteve Rothenberg 和 Jacek Wytrebowicz他们的意见和建议。感谢 Adrian Farrel 的评论。
-
发表了文章 2023-03-04
IKE中NAT-Traversal的协商
RFC3947：Negotiation of NAT-Traversal in the IKE，January 2005本备忘录的状态本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。版权声明版权所有 (C) 互联网协会 (2005)。梗概本文档描述了如何检测 IPsec 主机之间的一个或多个网络地址转换设备 (network address translation，NAT)，以及如何通过 Internet 密钥交换 (Internet Key Exchange，IKE) 中的 NAT 设备协商使用 IPsec 数据包的 UDP 封装。1、 简介本文档分为两部分。第一个描述了在 IKE 阶段 1 中需要什么来支持 NAT 穿越。这包括检测另一端是否支持NAT-Traversal，检测对等体之间是否存在一个或多个NAT。第二部分描述了如何在 IKE 的快速模式下协商使用 UDP 封装的 IPsec 数据包。如果需要，它还描述了如何将原始源地址和目标地址传输到对端。这些地址在传输模式下用于逐步更新 TCP/IP 校验和，以便它们在 NAT 转换后匹配。（NAT 不能这样做，因为 TCP/IP 校验和在 UDP 封装的 IPsec 数据包内。）文档 [RFC3948] 描述了 UDP 封装的细节，[RFC3715] 提供了 NAT-Traversal 的一般背景信息和动机。结合[RFC3948]，本文档代表了一个“无条件兼容”的解决方案，以满足[RFC3715]定义的要求。在本文档的基本场景中，发起方位于 NA(P)T 之后，响应方拥有固定的静态 IP 地址。本文档定义了一个即使两端都在 NAT 之后也能工作的协议，但如何定位另一端的过程超出了本文档的范围。在一种情况下，响应者位于静态NAT主机之后（每个 IP 只有一个响应者，因为除了 500/4500 之外，无法使用任何目标端口）。也就是说，它是由配置已知的。2、 需求说明本文件应使用关键字“必须”、“不得”、“需要”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”来描述要求。它们将按照 [RFC2119] 中的描述进行解释。3、 第一阶段在 IKE [RFC2409] 阶段 1 中，检测对 NAT 穿越的支持和沿两个 IKE 对等体之间的路径检测 NAT。NAT 可能会更改 IKE UDP 源端口，并且接收方必须能够处理源端口不同于 500 的 IKE 数据包。如果出现以下情况，NAT 不必更改源端口：** 只有一台 IPsec 主机在 NAT 后面，或者** 对于第一个IPsec主机，NAT可以保留500端口，NAT只会为以后的连接改变端口号。接收者必须回复来自数据包的源地址（参见 [RFC3715]，第 2.1 节，情况 d）。这意味着当原始响应者正在对原始发起者进行密钥更新或发送通知时，它必须使用上次使用 IKE SA 时使用的相同端口和 IP 号集发送数据包。例如，当发起方发送一个源端口和目的端口为 500 的数据包时，NAT 可能会将其更改为源端口为 12312 和目的端口为 500 的数据包。响应方必须能够处理源端口为 12312 的数据包。它必须回复一个源端口为 500 和目标端口为 12312 的数据包。NAT 然后将这个数据包转换为源端口 500 和目标端口 500。3.1、 检测是否支持 NAT 穿越远程主机的 NAT 穿越能力由供应商 ID 负载的交换决定。在阶段 1 的前两个消息中，如果支持（并且双方必须接收），则必须发送此规范的供应商 id 有效负载，以便继续进行 NAT 穿越探测。有效载荷的内容是“RFC 3947”的MD5 哈希值。有效载荷的十六进制确切内容是：4a131c81070358455c5728f20e95452f3.2、 检测 NAT 的存在NAT-D 负载不仅检测两个 IKE 对等体之间是否存在 NAT，还检测 NAT 在哪里。NAT 设备的位置很重要，因为保活必须从 NAT“后面”的对端发起。要检测两台主机之间的 NAT，我们必须检测 IP 地址或端口是否沿路径发生变化。这是通过将两个 IKE 对端的 IP 地址和端口的哈希值从每一端发送到另一端来完成的。如果两端都计算这些哈希并得到相同的结果，他们就知道它们之间没有 NAT。如果HASH不匹配，则有人转换了地址或端口。这意味着我们必须进行 NAT-Traversal 才能通过 IPsec 数据包。如果数据包的发送者不知道自己的 IP 地址（在多个接口的情况下，并且实现不知道使用哪个 IP 地址将数据包路由出去），则发送者可以在数据包中包含多个本地哈希（如单独的 NAT-D 有效载荷）。在这种情况下，当且仅当所有HASH都不匹配时，才会检测到 NAT。HASH作为一系列 NAT-D（NAT 发现）有效负载发送。每个负载包含一个哈希，因此在多个哈希的情况下，将发送多个 NAT-D 负载。在正常情况下，只有两个 NAT-D 有效载荷。NAT-D 负载包含在主模式的第三个和第四个数据包中，以及在主动模式的第二个和第三个数据包中。NAT-D 报文格式为：NAT 发现负载的负载类型为 20。HASH 计算如下：HASH = HASH(CKY-I | CKY-R | IP | Port)这使用协商的 HASH 算法。HASH 中的所有数据都是按网络字节顺序排列的。IP 为 IPv4 地址的 4 个八位字节和 IPv6 地址的 16 个八位字节。端口号以网络字节顺序编码为 2 个八位字节数。第一个 NAT-D 负载包含远程端的 IP 地址和端口（即 UDP 数据包的目标地址）。剩余的 NAT-D 负载包含可能的本地 IP 地址和端口（即 UDP 数据包的所有可能的源地址&#