跳到主要内容

RFC 6864 - Updated Specification of the IPv4 ID Field

  • 状态: Proposed Standard
  • 发布日期: February 2013
  • Stream: IETF
  • 更新了: RFC791, RFC1122, RFC2003
  • 勘误: 无勘误

Status of This Memo (本备忘录状态)​

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6864.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Abstract (摘要)​

IPv4 标识 (Identification, ID) 字段用于支持分片 (fragmentation) 和重组 (reassembly),按照当前规范的要求,对于具有相同源地址/目的地址/协议元组的所有数据报,该字段在最大生存时间内必须唯一.然而,当前的实现并未遵循该规范,而是将 ID 字段视为每个数据报的唯一值,这种做法在高速设备上可能导致 ID 字段耗尽.本文档更新了 RFC 791、RFC 1122 和 RFC 2003 中对 IPv4 ID 字段的规范,使其更贴近当前的实践,并讨论了这些变化对数据报设计者的影响.

Table of Contents (目录)​

1. Introduction (简介)​

2. The IPv4 ID Field (IPv4 ID 字段)​

  • 2.1 IPv4 ID Used for Fragmentation
  • 2.2 IPv4 ID Used for Duplicate Detection
  • 2.3 Background on IPv4 ID Reassembly Issues

3. Updates to the IPv4 ID Specification (IPv4 ID 规范的更新)​

  • 3.1 IPv4 ID for Atomic Datagrams
  • 3.2 IPv4 ID for Non-Atomic Datagrams
  • 3.3 Retaining IPv4 ID Behavior

4. Impact of Proposed Changes (建议变更的影响)​

  • 4.1 Impact on Legacy Internet Devices
  • 4.2 Impact on Datagram Generation
  • 4.3 Impact on Header Compression Schemes

5. Updates to Existing Standards (对现有标准的更新)​

  • 5.1 Updates to RFC 791
  • 5.2 Updates to RFC 1122
  • 5.3 Updates to RFC 2003

6. Security Considerations (安全考虑)​

7. References (参考文献)​

  • 7.1 Normative References
  • 7.2 Informative References

Appendix A. Duplicate Detectability (附录 A: 重复检测能力)​

Appendix B. Acknowledgments (附录 B: 致谢)​

Quick Reference (快速参考)​

Key Terms (关键术语)​

  • Atomic datagram (原子数据报): IPv4 数据报,其 DF (Don't Fragment) 标志位被设置为 1
  • Non-atomic datagram (非原子数据报): IPv4 数据报,其 DF 标志位被设置为 0
  • ID reuse interval (ID 重用间隔): 具有相同源地址/目的地址/协议元组的数据报之间,重用相同 ID 值的最小时间间隔

Core Updates (核心更新)​

  1. 原子数据报的 ID 字段: DF=1 的数据报,其 ID 字段可以设置为任意值
  2. 非原子数据报的 ID 字段: DF=0 的数据报,其 ID 字段必须在重组超时期间内唯一
  3. 接收端行为: 接收端应忽略原子数据报的 ID 字段值

Updates to RFCs (更新的 RFC)​

  • RFC 791: 更新了 IPv4 规范中关于 ID 字段的要求
  • RFC 1122: 更新了主机要求中关于 ID 字段的规定
  • RFC 2003: 更新了 IP-in-IP 封装中关于 ID 字段的处理

Official Source: RFC 6864 at IETF

1. Introduction (简介)​

在 IPv4 中,标识 (Identification, ID) 字段是一个 16 位值,用于支持数据报的分片 (fragmentation) 和重组 (reassembly).根据当前的规范,ID 字段在具有相同源地址、目的地址和协议的数据报中,在最大生存时间 (Maximum Segment Lifetime, MSL) 内必须唯一.然而,当前的实现并未严格遵循该规范,而是将 ID 字段视为每个数据报的唯一标识符,无论该数据报是否会被分片.

在 IPv4 中,传输层和上层协议通常使用 16 位或 32 位字段来检测重复数据报,例如 TCP 的序列号 (sequence number) 或 UDP 的校验和 (checksum).然而,IPv4 的 ID 字段仅有 16 位,这意味着在高速网络环境下,ID 字段可能会在短时间内耗尽,导致无法为新的数据报分配唯一的 ID 值.

在 IPv6 中,分片仅由源节点执行,且分片头 (Fragment Header) 包含一个 32 位的标识字段.IPv6 规范明确指出,该标识字段仅在数据报被分片时才需要唯一.相比之下,IPv4 的 ID 字段在所有数据报中都存在,无论是否分片.

本文档更新了 RFC 791、RFC 1122 和 RFC 2003 中对 IPv4 ID 字段的规范,使其更贴近当前的实践,并与 IPv6 的处理方式保持一致.具体而言,本文档明确了以下几点:

  1. 原子数据报 (Atomic Datagrams): 对于设置了 DF (Don't Fragment) 标志位的数据报,其 ID 字段可以设置为任意值,接收端应忽略该字段的值.

  2. 非原子数据报 (Non-Atomic Datagrams): 对于未设置 DF 标志位的数据报,其 ID 字段必须在重组超时期间内唯一,以确保分片能够正确重组.

  3. 兼容性: 本文档讨论了这些变化对现有设备和协议的影响,并提供了过渡期间的建议.

本文档使用 RFC 2119 中定义的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 来表示要求级别.

在本文档中,字符 "^" 表示逻辑非 (logical NOT),"|" 表示逻辑或 (logical OR),"&" 表示逻辑与 (logical AND).

1.1 Terminology (术语)​

本文档使用以下术语:

  • Atomic datagram (原子数据报): IPv4 数据报,其 DF (Don't Fragment) 标志位被设置为 1.原子数据报不会被中间路由器分片.

  • Non-atomic datagram (非原子数据报): IPv4 数据报,其 DF 标志位被设置为 0.非原子数据报可以被中间路由器分片.

  • Source node (源节点): 生成 IPv4 数据报的主机或设备.

  • Intermediate node (中间节点): 转发 IPv4 数据报的路由器或网关.

  • Destination node (目的节点): 接收 IPv4 数据报的主机或设备.

  • ID reuse interval (ID 重用间隔): 具有相同源地址/目的地址/协议元组的数据报之间,重用相同 ID 值的最小时间间隔.

Navigation:

2. The IPv4 ID Field (IPv4 ID 字段)​

IPv4 标识 (ID) 字段最初设计用于支持数据报的分片和重组.根据 RFC 791 的规定,ID 字段在具有相同源地址、目的地址和协议的数据报中,在最大生存时间 (MSL) 内必须唯一.然而,随着网络速度的提升和应用需求的变化,当前的实现已经偏离了原始规范.

本章节详细讨论了 IPv4 ID 字段的两种主要用途: 用于分片 (fragmentation) 和用于重复检测 (duplicate detection),并分析了当前实现中存在的问题.

2.1 IPv4 ID Used for Fragmentation (用于分片的 IPv4 ID)​

IPv4 ID 字段的主要用途是支持数据报的分片和重组.当一个数据报需要通过最大传输单元 (MTU) 较小的链路时,中间路由器可以将该数据报分片为多个较小的片段.每个片段都包含相同的 ID 值,以便目的节点能够将这些片段重组为原始数据报.

根据 RFC 791 的规定,对于具有相同源地址、目的地址和协议的数据报,其 ID 字段在 MSL 内必须唯一.这一要求确保了即使在网络延迟较大的情况下,目的节点也能够正确地将分片重组为原始数据报,而不会将来自不同数据报的分片错误地组合在一起.

然而,在高速网络环境下,16 位的 ID 字段可能会在短时间内耗尽.例如,在 10 Gbps 的链路上,假设每个数据报的平均大小为 1500 字节,那么每秒可以传输约 833,333 个数据报.如果每个数据报都需要一个唯一的 ID 值,那么 16 位的 ID 字段 (最多 65,536 个不同的值) 将在约 0.079 秒内耗尽.

为了解决这一问题,本文档引入了 原子数据报 (atomic datagram) 和 非原子数据报 (non-atomic datagram) 的概念:

  • 原子数据报: 设置了 DF (Don't Fragment) 标志位的数据报.这些数据报不会被中间路由器分片,因此其 ID 字段不需要用于重组.

  • 非原子数据报: 未设置 DF 标志位的数据报.这些数据报可以被中间路由器分片,因此其 ID 字段必须在重组超时期间内唯一.

2.2 IPv4 ID Used for Duplicate Detection (用于重复检测的 IPv4 ID)​

除了用于分片和重组外,IPv4 ID 字段还可以用于检测重复数据报.在某些情况下,网络中可能会出现重复的数据报,例如由于路由环路或链路层重传导致的重复.传输层协议 (如 TCP) 通常使用序列号来检测重复数据报,但在某些情况下,IPv4 ID 字段也可以提供额外的保护.

然而,IPv4 ID 字段仅有 16 位,这意味着在高速网络环境下,ID 字段可能会在短时间内重复使用.因此,依赖 IPv4 ID 字段进行重复检测并不可靠,特别是在高速网络环境下.

RFC 1122 指出,传输层协议应该使用自己的机制来检测重复数据报,而不应依赖 IPv4 ID 字段.例如,TCP 使用序列号和确认号来检测重复数据报,UDP 则依赖应用层协议来处理重复.

本文档进一步明确了这一点: IPv4 ID 字段主要用于支持分片和重组,而不应被用作重复检测的主要机制.对于原子数据报 (DF=1),其 ID 字段可以设置为任意值,接收端应忽略该字段的值.

2.3 Background on IPv4 ID Reassembly Issues (IPv4 ID 重组问题的背景)​

在高速网络环境下,IPv4 ID 字段的 16 位限制可能导致以下问题:

  1. ID 字段耗尽: 在高速链路上,16 位的 ID 字段可能会在短时间内耗尽,导致无法为新的数据报分配唯一的 ID 值.

  2. 重组错误: 如果两个不同的数据报使用了相同的 ID 值,并且它们的分片在网络中同时存在,那么目的节点可能会将来自不同数据报的分片错误地组合在一起,导致重组错误.

  3. 性能下降: 为了避免 ID 字段耗尽,某些实现可能会限制数据报的发送速率,从而导致性能下降.

RFC 4963 详细讨论了在高速网络环境下 IPv4 重组错误的问题,并指出当前的 IPv4 ID 字段规范在高速网络环境下已经不再适用.

为了解决这些问题,本文档提出了以下解决方案:

  1. 区分原子数据报和非原子数据报: 对于原子数据报 (DF=1),其 ID 字段不需要用于重组,因此可以设置为任意值.对于非原子数据报 (DF=0),其 ID 字段必须在重组超时期间内唯一.

  2. 接收端行为更新: 接收端应忽略原子数据报的 ID 字段值,仅对非原子数据报的分片进行重组.

  3. 发送端行为更新: 发送端应根据数据报的 DF 标志位来决定如何设置 ID 字段.对于原子数据报,可以使用简化的 ID 生成算法 (如固定值或简单计数器).对于非原子数据报,应使用能够确保 ID 唯一性的算法.

这些变化使得 IPv4 的 ID 字段处理方式与 IPv6 保持一致,并减轻了高速网络环境下的 ID 字段耗尽问题.

Navigation:

3. Updates to the IPv4 ID Specification (IPv4 ID 规范的更新)​

本章节详细说明了对 IPv4 ID 字段规范的更新.这些更新旨在解决高速网络环境下 ID 字段耗尽的问题,并使 IPv4 的处理方式与 IPv6 保持一致.

3.1 IPv4 ID for Atomic Datagrams (原子数据报的 IPv4 ID)​

原子数据报 (atomic datagram) 是指设置了 DF (Don't Fragment) 标志位的 IPv4 数据报.由于这些数据报不会被中间路由器分片,因此其 ID 字段不需要用于重组.

3.1.1 发送端行为 (Sender Behavior)​

对于原子数据报,发送端 可以 (MAY) 将 ID 字段设置为任意值.具体而言:

  • 固定值: 发送端可以将所有原子数据报的 ID 字段设置为相同的固定值 (例如 0).

  • 简单计数器: 发送端可以使用简单的计数器来生成 ID 值,而无需考虑 ID 的唯一性.

  • 随机值: 发送端可以为每个原子数据报生成随机的 ID 值.

这种灵活性允许发送端简化 ID 字段的生成逻辑,从而提高性能并减少资源消耗.

3.1.2 接收端行为 (Receiver Behavior)​

对于原子数据报,接收端 必须 (MUST) 忽略 ID 字段的值.具体而言:

  • 接收端不应使用 ID 字段来检测重复数据报.

  • 接收端不应假设原子数据报的 ID 字段具有任何特定的含义或顺序.

  • 接收端应依赖传输层协议 (如 TCP 的序列号) 来检测重复数据报.

3.1.3 中间节点行为 (Intermediate Node Behavior)​

中间节点 (如路由器) 在转发原子数据报时:

  • 不得 (MUST NOT) 修改 ID 字段的值,除非执行 IP-in-IP 封装或类似操作.

  • 不得 (MUST NOT) 对原子数据报进行分片.如果数据报的大小超过了下一跳链路的 MTU,中间节点应丢弃该数据报并向源节点发送 ICMP "Fragmentation Needed" 消息.

3.2 IPv4 ID for Non-Atomic Datagrams (非原子数据报的 IPv4 ID)​

非原子数据报 (non-atomic datagram) 是指未设置 DF 标志位的 IPv4 数据报.这些数据报可以被中间路由器分片,因此其 ID 字段必须用于支持分片和重组.

3.2.1 发送端行为 (Sender Behavior)​

对于非原子数据报,发送端 必须 (MUST) 确保 ID 字段在重组超时期间内唯一.具体而言:

  • 对于具有相同源地址、目的地址和协议的数据报,其 ID 字段在重组超时期间内不得重复.

  • 重组超时期间通常设置为 60-120 秒,具体取决于实现.

  • 发送端应使用能够确保 ID 唯一性的算法,例如:

    • 全局计数器: 为所有数据报维护一个全局计数器.
    • 每流计数器: 为每个 (源地址, 目的地址, 协议) 元组维护一个独立的计数器.
    • 基于时间的算法: 使用时间戳或其他基于时间的机制来生成 ID 值.

3.2.2 接收端行为 (Receiver Behavior)​

对于非原子数据报的分片,接收端 必须 (MUST) 使用 ID 字段来进行重组.具体而言:

  • 接收端应将具有相同源地址、目的地址、协议和 ID 值的分片组合在一起.

  • 接收端应在重组超时期间内保留未完成的分片.如果在超时期间内未能接收到所有分片,接收端应丢弃已接收的分片.

  • 接收端不应假设非原子数据报的 ID 字段具有任何特定的顺序或模式.

3.2.3 中间节点行为 (Intermediate Node Behavior)​

中间节点在处理非原子数据报时:

  • 可以 (MAY) 对数据报进行分片,如果数据报的大小超过了下一跳链路的 MTU.

  • 必须 (MUST) 保留原始数据报的 ID 字段值,以便目的节点能够正确重组分片.

  • 不得 (MUST NOT) 修改 ID 字段的值,除非执行 IP-in-IP 封装或类似操作.

3.3 Retaining IPv4 ID Behavior (保留 IPv4 ID 行为)​

在某些情况下,设备可能需要保留传统的 IPv4 ID 行为,即为所有数据报 (无论是否设置 DF 标志位) 生成唯一的 ID 值.这种情况包括:

  1. 兼容性要求: 与不支持本文档更新的旧设备进行互操作.

  2. 特殊应用: 某些应用可能依赖 ID 字段的唯一性来进行调试或监控.

  3. 安全考虑: 某些安全机制可能依赖 ID 字段的随机性或唯一性.

在这些情况下,设备 可以 (MAY) 选择为所有数据报生成唯一的 ID 值,而不区分原子数据报和非原子数据报.然而,这种做法可能会导致性能下降,特别是在高速网络环境下.

3.3.1 过渡期建议 (Transition Recommendations)​

为了确保平滑过渡,本文档建议:

  1. 新设备: 新设备应实现本文档中描述的更新行为,即区分原子数据报和非原子数据报.

  2. 现有设备: 现有设备可以通过软件更新来实现新的行为.在更新之前,这些设备应继续使用传统的 ID 生成算法.

  3. 互操作性测试: 设备制造商应进行互操作性测试,以确保新旧设备能够正确互操作.

  4. 文档和配置: 设备应提供清晰的文档和配置选项,说明其 ID 字段的生成策略.

Navigation:

4. Impact of Proposed Changes (建议变更的影响)​

本章节分析了对 IPv4 ID 字段规范的更新对现有设备、数据报生成和头部压缩方案的影响.

4.1 Impact on Legacy Internet Devices (对传统互联网设备的影响)​

本文档提出的更新对传统互联网设备的影响主要体现在以下几个方面:

4.1.1 发送端影响 (Sender Impact)​

传统发送端: 传统的发送端通常为所有数据报生成唯一的 ID 值,无论是否设置 DF 标志位.这种做法在本文档的更新下仍然是合法的,因为:

  • 对于原子数据报 (DF=1),发送端 可以 (MAY) 将 ID 字段设置为任意值,包括唯一值.
  • 对于非原子数据报 (DF=0),发送端 必须 (MUST) 确保 ID 字段的唯一性.

因此,传统发送端无需修改其行为即可符合本文档的要求.

新发送端: 实现本文档更新的新发送端可以选择为原子数据报使用简化的 ID 生成算法 (如固定值或简单计数器),从而提高性能并减少资源消耗.

4.1.2 接收端影响 (Receiver Impact)​

传统接收端: 传统的接收端通常会处理所有数据报的 ID 字段,无论是否设置 DF 标志位.然而,对于原子数据报,接收端实际上不需要使用 ID 字段,因为这些数据报不会被分片.

根据本文档的更新,接收端 必须 (MUST) 忽略原子数据报的 ID 字段值.这意味着:

  • 传统接收端可能需要更新其实现,以忽略原子数据报的 ID 字段.
  • 然而,即使传统接收端继续处理原子数据报的 ID 字段,也不会导致功能错误,因为原子数据报不会被分片.

新接收端: 实现本文档更新的新接收端应明确忽略原子数据报的 ID 字段,并仅对非原子数据报的分片进行重组.

4.1.3 中间节点影响 (Intermediate Node Impact)​

路由器和网关: 中间节点 (如路由器和网关) 通常不会修改数据报的 ID 字段,除非执行分片操作.本文档的更新对中间节点的影响较小:

  • 对于原子数据报 (DF=1),中间节点不得对其进行分片,这与现有行为一致.
  • 对于非原子数据报 (DF=0),中间节点可以对其进行分片,并保留原始的 ID 字段值.

因此,中间节点无需修改其行为即可符合本文档的要求.

4.1.4 兼容性总结 (Compatibility Summary)​

总体而言,本文档的更新对传统互联网设备的影响较小:

  • 向后兼容: 传统设备无需修改即可继续工作.
  • 向前兼容: 新设备可以利用更新的规范来提高性能.
  • 互操作性: 新旧设备可以正确互操作,不会导致功能错误.

4.2 Impact on Datagram Generation (对数据报生成的影响)​

本文档的更新对数据报生成的影响主要体现在 ID 字段的生成策略上.

4.2.1 原子数据报的 ID 生成 (ID Generation for Atomic Datagrams)​

对于原子数据报 (DF=1),发送端可以使用以下简化的 ID 生成策略:

  1. 固定值: 将所有原子数据报的 ID 字段设置为相同的固定值 (例如 0).这是最简单的策略,但可能会暴露设备的行为模式.

  2. 简单计数器: 使用一个全局计数器为所有原子数据报生成 ID 值.这种策略简单高效,但可能会暴露数据报的发送顺序.

  3. 随机值: 为每个原子数据报生成随机的 ID 值.这种策略提供了更好的隐私保护,但需要额外的计算资源.

  4. 每流计数器: 为每个 (源地址, 目的地址, 协议) 元组维护一个独立的计数器.这种策略在性能和隐私之间取得了平衡.

4.2.2 非原子数据报的 ID 生成 (ID Generation for Non-Atomic Datagrams)​

对于非原子数据报 (DF=0),发送端必须确保 ID 字段在重组超时期间内唯一.常用的 ID 生成策略包括:

  1. 全局计数器: 为所有数据报维护一个全局计数器.这种策略简单高效,但在高速网络环境下可能导致 ID 字段耗尽.

  2. 每流计数器: 为每个 (源地址, 目的地址, 协议) 元组维护一个独立的计数器.这种策略可以有效减少 ID 字段耗尽的风险.

  3. 基于时间的算法: 使用时间戳或其他基于时间的机制来生成 ID 值.这种策略可以确保 ID 的唯一性,但需要精确的时钟同步.

  4. 混合算法: 结合计数器和随机值来生成 ID.这种策略在性能、唯一性和隐私之间取得了平衡.

4.2.3 性能考虑 (Performance Considerations)​

本文档的更新可以显著提高数据报生成的性能:

  • 减少计算开销: 对于原子数据报,可以使用简化的 ID 生成算法,从而减少计算开销.

  • 减少状态维护: 对于原子数据报,无需维护复杂的 ID 唯一性状态,从而减少内存消耗.

  • 提高吞吐量: 在高速网络环境下,简化的 ID 生成算法可以显著提高数据报的发送速率.

4.3 Impact on Header Compression Schemes (对头部压缩方案的影响)​

头部压缩方案 (如 ROHC, RFC 5795) 通常依赖 IPv4 头部字段的可预测性来实现高效的压缩.本文档的更新对头部压缩方案的影响如下:

4.3.1 原子数据报的压缩 (Compression for Atomic Datagrams)​

对于原子数据报 (DF=1),由于 ID 字段可以设置为任意值,头部压缩方案需要考虑以下情况:

  1. 固定值: 如果发送端将所有原子数据报的 ID 字段设置为相同的固定值,头部压缩方案可以高效地压缩该字段.

  2. 简单计数器: 如果发送端使用简单计数器,头部压缩方案可以利用 ID 字段的递增模式来实现高效压缩.

  3. 随机值: 如果发送端使用随机值,头部压缩方案可能无法有效压缩 ID 字段,但可以选择不压缩该字段.

4.3.2 非原子数据报的压缩 (Compression for Non-Atomic Datagrams)​

对于非原子数据报 (DF=0),由于 ID 字段必须唯一,头部压缩方案可以继续使用现有的压缩算法.通常,头部压缩方案会利用 ID 字段的递增模式来实现高效压缩.

4.3.3 压缩方案的更新建议 (Recommendations for Compression Schemes)​

为了适应本文档的更新,头部压缩方案应:

  1. 区分原子数据报和非原子数据报: 根据 DF 标志位来决定如何压缩 ID 字段.

  2. 自适应压缩: 根据 ID 字段的实际模式 (固定值、递增、随机) 来选择最优的压缩策略.

  3. 协商机制: 在压缩会话建立时,协商 ID 字段的生成策略,以便选择最优的压缩算法.

总体而言,本文档的更新对头部压缩方案的影响较小,现有的压缩方案可以通过适当的调整来适应新的规范.

Navigation:

5. Updates to Existing Standards (对现有标准的更新)​

本章节详细说明了本文档对 RFC 791、RFC 1122 和 RFC 2003 的具体更新内容.

5.1 Updates to RFC 791 (对 RFC 791 的更新)​

RFC 791 是 IPv4 协议的基础规范,定义了 IPv4 头部格式和各字段的语义.本文档对 RFC 791 中关于标识 (Identification, ID) 字段的规范进行了以下更新:

5.1.1 原始规范 (Original Specification)​

RFC 791 第 3.2 节对 ID 字段的描述如下:

"Identification: 16 bits

An identifying value assigned by the sender to aid in assembling the fragments of a datagram."

RFC 791 还规定:

"The choice of the Identification value is left to the sender, but it must be unique for each datagram during the time the datagram (or any fragment of it) could be alive in the internet."

这意味着,对于具有相同源地址、目的地址和协议的数据报,其 ID 字段在最大生存时间 (MSL) 内必须唯一.

5.1.2 更新内容 (Updates)​

本文档对 RFC 791 的更新如下:

对于原子数据报 (DF=1):

  • 发送端 可以 (MAY) 将 ID 字段设置为任意值.
  • ID 字段不需要在数据报之间保持唯一性.
  • 接收端 必须 (MUST) 忽略原子数据报的 ID 字段值.

对于非原子数据报 (DF=0):

  • 发送端 必须 (MUST) 确保 ID 字段在重组超时期间内唯一.
  • 对于具有相同源地址、目的地址和协议的数据报,其 ID 字段在重组超时期间内不得重复.
  • 接收端 必须 (MUST) 使用 ID 字段来重组分片.

5.1.3 更新后的规范文本 (Updated Specification Text)​

RFC 791 第 3.2 节中关于 ID 字段的描述应更新为:

"Identification: 16 bits

An identifying value assigned by the sender to aid in assembling the fragments of a datagram.

For atomic datagrams (DF=1), the sender MAY set the Identification field to any value, and the receiver MUST ignore the Identification field.

For non-atomic datagrams (DF=0), the sender MUST ensure that the Identification field is unique for all datagrams with the same source address, destination address, and protocol during the reassembly timeout period. The receiver MUST use the Identification field to reassemble fragments."

5.2 Updates to RFC 1122 (对 RFC 1122 的更新)​

RFC 1122 定义了互联网主机的要求,包括对 IPv4 协议的实现要求.本文档对 RFC 1122 中关于 ID 字段的规范进行了以下更新:

5.2.1 原始规范 (Original Specification)​

RFC 1122 第 3.2.1.5 节对 ID 字段的描述如下:

"When sending an identical copy of an earlier datagram, a host MAY optionally retain the same Identification field in the copy."

RFC 1122 还规定:

"Some Internet protocol experts have maintained that when a host sends an identical copy of an earlier datagram, the new copy should contain the same Identification value as the original. There are two suggested advantages: (1) if the datagrams are fragmented and some of the fragments are lost, the receiver may be able to reconstruct a complete datagram from fragments of the original and the copies; (2) a congested gateway might use the IP Identification field (and Fragment Offset) to discard duplicate datagrams from the queue."

然而,RFC 1122 也指出:

"However, the Identification field is not intended for this purpose. The IP Identification field is intended to be used only for fragmentation and reassembly."

5.2.2 更新内容 (Updates)​

本文档对 RFC 1122 的更新如下:

对于原子数据报 (DF=1):

  • 主机 可以 (MAY) 将 ID 字段设置为任意值,包括固定值、计数器或随机值.
  • 主机 不应 (SHOULD NOT) 依赖 ID 字段来检测重复数据报.
  • 主机 必须 (MUST) 使用传输层协议 (如 TCP 序列号) 来检测重复数据报.

对于非原子数据报 (DF=0):

  • 主机 必须 (MUST) 确保 ID 字段在重组超时期间内唯一.
  • 主机 应该 (SHOULD) 为每个 (源地址, 目的地址, 协议) 元组维护独立的 ID 计数器.

5.2.3 更新后的规范文本 (Updated Specification Text)​

RFC 1122 第 3.2.1.5 节应更新为:

"For atomic datagrams (DF=1), a host MAY set the Identification field to any value. The host MUST NOT rely on the Identification field for duplicate detection and MUST use transport-layer mechanisms (e.g., TCP sequence numbers) for this purpose.

For non-atomic datagrams (DF=0), a host MUST ensure that the Identification field is unique for all datagrams with the same source address, destination address, and protocol during the reassembly timeout period. The host SHOULD maintain separate Identification counters for each (source address, destination address, protocol) tuple."

5.3 Updates to RFC 2003 (对 RFC 2003 的更新)​

RFC 2003 定义了 IP-in-IP 封装 (IP Encapsulation within IP),用于 IP 隧道和移动 IP.本文档对 RFC 2003 中关于 ID 字段的规范进行了以下更新:

5.3.1 原始规范 (Original Specification)​

RFC 2003 第 3.1 节对外部 IPv4 头部的 ID 字段描述如下:

"Identification: A new number must be assigned for the encapsulating datagram. This is not related to the Identification field of the original datagram."

这意味着,在执行 IP-in-IP 封装时,外部 IPv4 头部的 ID 字段必须独立于内部 IPv4 头部的 ID 字段.

5.3.2 更新内容 (Updates)​

本文档对 RFC 2003 的更新如下:

对于外部 IPv4 头部 (Outer IPv4 Header):

  • 如果外部头部的 DF 标志位设置为 1 (原子数据报),封装设备 可以 (MAY) 将外部头部的 ID 字段设置为任意值.

  • 如果外部头部的 DF 标志位设置为 0 (非原子数据报),封装设备 必须 (MUST) 确保外部头部的 ID 字段在重组超时期间内唯一.

对于内部 IPv4 头部 (Inner IPv4 Header):

  • 封装设备 不得 (MUST NOT) 修改内部 IPv4 头部的 ID 字段.

  • 解封装设备 必须 (MUST) 保留内部 IPv4 头部的 ID 字段,并根据内部头部的 DF 标志位来处理该字段.

5.3.3 更新后的规范文本 (Updated Specification Text)​

RFC 2003 第 3.1 节应更新为:

"Identification: A new number must be assigned for the outer encapsulating datagram. This is not related to the Identification field of the inner datagram.

For atomic outer datagrams (outer DF=1), the encapsulator MAY set the outer Identification field to any value.

For non-atomic outer datagrams (outer DF=0), the encapsulator MUST ensure that the outer Identification field is unique for all outer datagrams with the same outer source address, outer destination address, and protocol during the reassembly timeout period.

The encapsulator MUST NOT modify the Identification field of the inner datagram. The decapsulator MUST preserve the Identification field of the inner datagram and process it according to the inner DF flag."

5.4 Summary of Updates (更新总结)​

本文档对以下 RFC 进行了更新:

RFC更新内容影响范围
RFC 791区分原子数据报和非原子数据报的 ID 字段要求IPv4 协议规范
RFC 1122更新主机对 ID 字段的生成和处理要求互联网主机实现
RFC 2003更新 IP-in-IP 封装中对 ID 字段的处理要求IP 隧道和移动 IP

这些更新使得 IPv4 的 ID 字段处理方式与 IPv6 保持一致,并解决了高速网络环境下的 ID 字段耗尽问题.

Navigation:

6. Security Considerations (安全考虑)​

本章节讨论了对 IPv4 ID 字段规范的更新所带来的安全影响,包括对隐私、攻击面和防御机制的影响.

6.1 Privacy Implications (隐私影响)​

IPv4 ID 字段的生成策略可能会泄露有关发送端的信息,从而影响用户隐私.

6.1.1 ID 字段的可预测性 (Predictability of ID Field)​

如果发送端使用简单的全局计数器来生成 ID 字段,攻击者可以通过观察 ID 字段的变化来推断:

  1. 数据报发送速率: 通过观察 ID 字段的增长速率,攻击者可以估算发送端的数据报发送速率.

  2. 设备指纹识别: 不同的设备可能使用不同的 ID 生成算法,攻击者可以通过分析 ID 字段的模式来识别设备类型.

  3. 用户活动跟踪: 攻击者可以通过跟踪 ID 字段的变化来推断用户的网络活动模式.

6.1.2 缓解措施 (Mitigation Strategies)​

为了减少隐私泄露的风险,本文档建议:

  1. 使用随机值: 对于原子数据报 (DF=1),发送端可以使用随机值来生成 ID 字段,从而增加攻击者推断信息的难度.

  2. 每流计数器: 对于非原子数据报 (DF=0),发送端应使用每流计数器 (per-flow counter),而不是全局计数器,以减少信息泄露.

  3. 定期重置: 发送端可以定期重置 ID 计数器,以防止长期跟踪.

  4. 随机化初始值: 在启动或重置计数器时,使用随机的初始值,而不是固定的初始值 (如 0).

6.2 Fragmentation Attacks (分片攻击)​

IPv4 分片机制可能被攻击者利用来发起各种攻击.

6.2.1 分片重组攻击 (Fragmentation Reassembly Attacks)​

攻击者可以发送精心构造的分片来:

  1. 资源耗尽: 发送大量不完整的分片,导致接收端耗尽内存资源.

  2. 重组错误: 发送具有相同 ID 但内容不同的分片,导致接收端错误地重组数据报.

  3. 绕过防火墙: 通过分片来绕过防火墙或入侵检测系统的检查.

6.2.2 缓解措施 (Mitigation Strategies)​

本文档的更新有助于缓解某些分片攻击:

  1. 原子数据报: 通过使用原子数据报 (DF=1),可以完全避免分片,从而消除与分片相关的攻击风险.

  2. 路径 MTU 发现: 发送端应使用路径 MTU 发现 (Path MTU Discovery, PMTUD) 来确定最优的数据报大小,从而避免分片.

  3. 分片限制: 接收端应限制未完成分片的数量和存储时间,以防止资源耗尽攻击.

  4. 分片验证: 接收端应验证分片的完整性和一致性,以防止重组错误.

6.3 ID Collision Attacks (ID 冲突攻击)​

攻击者可能尝试利用 ID 字段的有限性来发起攻击.

6.3.1 攻击场景 (Attack Scenarios)​

  1. ID 预测攻击: 如果攻击者能够预测发送端的 ID 生成算法,可能会发送伪造的分片,导致接收端错误地重组数据报.

  2. ID 耗尽攻击: 攻击者可能尝试快速耗尽发送端的 ID 空间,导致合法数据报无法获得唯一的 ID 值.

  3. 重组干扰攻击: 攻击者可能发送具有相同 ID 的伪造分片,干扰合法数据报的重组过程.

6.3.2 缓解措施 (Mitigation Strategies)​

  1. 随机化 ID 生成: 使用随机化的 ID 生成算法,增加攻击者预测 ID 值的难度.

  2. 每流 ID 空间: 为每个 (源地址, 目的地址, 协议) 元组维护独立的 ID 空间,减少 ID 冲突的概率.

  3. 传输层验证: 依赖传输层协议 (如 TCP 序列号、UDP 校验和) 来验证数据报的完整性,而不仅仅依赖 IPv4 ID 字段.

  4. IPsec: 使用 IPsec 来保护数据报的完整性和真实性,防止伪造分片攻击.

6.4 Denial of Service (拒绝服务攻击)​

IPv4 ID 字段的处理可能成为拒绝服务攻击的目标.

6.4.1 攻击向量 (Attack Vectors)​

  1. 分片洪水攻击: 攻击者发送大量需要分片的数据报,导致中间节点或接收端的资源耗尽.

  2. ID 耗尽攻击: 攻击者快速发送大量数据报,导致发送端的 ID 空间耗尽,无法为新的数据报分配唯一的 ID 值.

  3. 重组资源耗尽: 攻击者发送大量不完整的分片,导致接收端的重组缓冲区耗尽.

6.4.2 缓解措施 (Mitigation Strategies)​

  1. 速率限制: 对分片数据报的发送和接收速率进行限制,防止洪水攻击.

  2. 资源管理: 合理管理重组缓冲区和 ID 生成器的资源,防止资源耗尽.

  3. 优先级处理: 对原子数据报 (DF=1) 给予更高的处理优先级,因为它们不需要分片和重组.

  4. 防火墙和过滤: 使用防火墙和过滤规则来阻止可疑的分片流量.

6.5 Comparison with IPv6 (与 IPv6 的比较)​

IPv6 的分片机制在安全性方面与 IPv4 有所不同:

  1. 端到端分片: IPv6 仅允许源节点执行分片,中间节点不能对数据报进行分片.这减少了中间节点的攻击面.

  2. 32 位标识字段: IPv6 的分片头包含 32 位的标识字段,相比 IPv4 的 16 位 ID 字段,提供了更大的 ID 空间,减少了 ID 冲突的风险.

  3. 显式分片头: IPv6 使用独立的分片扩展头 (Fragment Extension Header),使得分片处理更加清晰和安全.

本文档的更新使得 IPv4 的 ID 字段处理方式与 IPv6 更加一致,特别是对于原子数据报 (DF=1) 的处理,从而提高了安全性.

6.6 Recommendations (建议)​

为了确保安全性,本文档建议:

  1. 优先使用原子数据报: 应用和协议应优先使用原子数据报 (DF=1),并通过路径 MTU 发现来避免分片.

  2. 随机化 ID 生成: 对于需要生成 ID 的情况,应使用随机化的算法来增加安全性.

  3. 传输层保护: 依赖传输层协议 (如 TLS、IPsec) 来保护数据的完整性和真实性.

  4. 监控和检测: 部署监控和检测机制来识别和响应与分片相关的攻击.

  5. 定期更新: 保持设备和软件的更新,以修复已知的安全漏洞.

Navigation:

Appendix A. Duplicate Detectability (附录 A: 重复检测能力)​

本附录讨论了 IPv4 ID 字段在重复数据报检测中的作用,以及本文档提出的更新对重复检测能力的影响.

A.1 Background on Duplicate Detection (重复检测的背景)​

在网络通信中,重复数据报 (duplicate datagrams) 可能由多种原因产生:

  1. 链路层重传: 链路层协议 (如以太网、Wi-Fi) 可能会重传丢失的帧,导致同一数据报被多次传输.

  2. 路由环路: 网络配置错误或路由协议故障可能导致数据报在路由器之间循环.

  3. 负载均衡: 某些负载均衡机制可能会将同一数据报复制到多个路径.

  4. 恶意攻击: 攻击者可能故意发送重复的数据报来发起拒绝服务攻击.

传统上,IPv4 ID 字段被认为可以用于检测重复数据报.然而,由于 ID 字段仅有 16 位,在高速网络环境下,ID 字段可能会快速重复使用,从而降低其作为重复检测机制的有效性.

A.2 Limitations of IPv4 ID for Duplicate Detection (IPv4 ID 用于重复检测的局限性)​

IPv4 ID 字段作为重复检测机制存在以下局限性:

A.2.1 有限的 ID 空间 (Limited ID Space)​

16 位的 ID 字段最多只能表示 65,536 个不同的值.在高速网络环境下,这个空间可能在短时间内耗尽.例如:

  • 10 Gbps 链路: 假设平均数据报大小为 1,500 字节,每秒可以传输约 833,333 个数据报,ID 空间将在约 0.079 秒内耗尽.

  • 100 Gbps 链路: 在相同假设下,ID 空间将在约 0.0079 秒内耗尽.

这意味着在高速网络环境下,依赖 IPv4 ID 字段进行重复检测是不可靠的.

A.2.2 ID 生成算法的多样性 (Diversity of ID Generation Algorithms)​

不同的设备和操作系统可能使用不同的 ID 生成算法:

  • 全局计数器: 所有数据报共享一个全局计数器.
  • 每流计数器: 每个 (源地址, 目的地址, 协议) 元组维护独立的计数器.
  • 随机值: 为每个数据报生成随机的 ID 值.

这种多样性使得接收端难以依赖 ID 字段来可靠地检测重复数据报.

A.2.3 分片的影响 (Impact of Fragmentation)​

当数据报被分片时,所有分片共享相同的 ID 值.这意味着:

  • 接收端无法仅通过 ID 字段来区分来自同一数据报的不同分片和来自不同数据报的分片.
  • 如果两个不同的数据报使用了相同的 ID 值,并且它们都被分片,接收端可能会错误地将来自不同数据报的分片组合在一起.

A.3 Impact of RFC 6864 Updates (RFC 6864 更新的影响)​

本文档提出的更新对重复检测能力的影响如下:

A.3.1 原子数据报 (Atomic Datagrams)​

对于原子数据报 (DF=1):

  • 发送端: 可以将 ID 字段设置为任意值,包括固定值、简单计数器或随机值.
  • 接收端: 必须忽略 ID 字段的值,不应依赖 ID 字段进行重复检测.

这意味着对于原子数据报,IPv4 ID 字段不再提供任何重复检测能力.接收端必须依赖传输层协议 (如 TCP 序列号、UDP 校验和) 或应用层机制来检测重复数据报.

A.3.2 非原子数据报 (Non-Atomic Datagrams)​

对于非原子数据报 (DF=0):

  • 发送端: 必须确保 ID 字段在重组超时期间内唯一.
  • 接收端: 必须使用 ID 字段来重组分片.

然而,即使对于非原子数据报,ID 字段的主要用途仍然是支持分片和重组,而不是重复检测.接收端不应依赖 ID 字段作为主要的重复检测机制.

由于 IPv4 ID 字段在重复检测方面的局限性,本文档建议使用以下机制来检测重复数据报:

A.4.1 传输层机制 (Transport Layer Mechanisms)​

TCP (Transmission Control Protocol):

  • TCP 使用 32 位的序列号 (sequence number) 来唯一标识每个字节的数据.
  • 接收端可以通过检查序列号来检测重复的 TCP 段.
  • TCP 的确认机制 (acknowledgment) 也有助于检测和处理重复.

UDP (User Datagram Protocol):

  • UDP 本身不提供重复检测机制.
  • 应用层协议应实现自己的重复检测机制,例如使用序列号、时间戳或唯一标识符.

SCTP (Stream Control Transmission Protocol):

  • SCTP 使用传输序列号 (Transmission Sequence Number, TSN) 来检测重复数据块.

A.4.2 应用层机制 (Application Layer Mechanisms)​

应用层协议可以实现以下重复检测机制:

  1. 序列号: 为每个消息分配唯一的序列号.
  2. 时间戳: 在消息中包含时间戳,接收端可以根据时间戳来检测重复.
  3. 消息 ID: 为每个消息生成唯一的标识符 (如 UUID).
  4. 幂等性设计: 设计应用协议使其操作是幂等的,即重复执行相同的操作不会产生副作用.

A.4.3 网络层机制 (Network Layer Mechanisms)​

IPsec (IP Security):

  • IPsec 的 ESP (Encapsulating Security Payload) 和 AH (Authentication Header) 协议包含序列号字段.
  • 接收端可以使用 IPsec 序列号来检测重放攻击 (replay attacks) 和重复数据报.

A.5 Conclusion (结论)​

IPv4 ID 字段的主要用途是支持数据报的分片和重组,而不是重复检测.由于 ID 字段的有限性和高速网络环境下的快速重复使用,依赖 IPv4 ID 字段进行重复检测是不可靠的.

本文档的更新进一步明确了这一点,特别是对于原子数据报 (DF=1),接收端必须忽略 ID 字段的值.应用和协议设计者应依赖传输层或应用层的机制来检测重复数据报,而不应依赖 IPv4 ID 字段.

这种方法与 IPv6 的设计理念一致,IPv6 中的标识字段仅在分片时使用,不用于重复检测.

Navigation:

Appendix B. Acknowledgments (附录 B: 致谢)​

本文档的作者感谢以下人员和组织对本文档的贡献和支持.

B.1 Contributors (贡献者)​

本文档的开发得益于 IETF 社区众多成员的贡献和反馈.特别感谢以下人员在技术讨论、审查和改进过程中提供的宝贵意见:

  • Fred Baker - 对 IPv4 和 IPv6 分片机制的深入分析和比较
  • Brian Carpenter - 对互操作性和过渡策略的建议
  • Wesley Eddy - 对传输层协议影响的分析
  • Fernando Gont - 对安全考虑和攻击场景的详细讨论
  • Alfred Hoenes - 对文档结构和技术细节的仔细审查
  • John Leslie - 对 ID 生成算法的讨论
  • Carlos Pignataro - 对实现影响的分析
  • Dan Wing - 对头部压缩方案影响的讨论

B.2 Working Group Contributions (工作组贡献)​

本文档在 IETF INTAREA (Internet Area) 工作组中进行了广泛的讨论和审查.感谢工作组成员的积极参与和建设性反馈.

特别感谢工作组主席和文档编辑在协调讨论、解决争议和推进文档标准化过程中的努力.

B.3 Review and Feedback (审查与反馈)​

本文档在标准化过程中经过了多轮审查,包括:

  • IETF Last Call: 感谢在 IETF Last Call 期间提供反馈的所有成员
  • IESG Review: 感谢 Internet Engineering Steering Group (IESG) 成员的详细审查和建议
  • Security Directorate Review: 感谢安全专家对安全考虑章节的审查
  • Transport Area Review: 感谢传输层专家对传输层影响的审查

B.4 Implementation Experience (实现经验)​

本文档的开发参考了多个实现的经验和反馈,包括:

  • 操作系统实现: Linux、FreeBSD、Windows 等操作系统的 IPv4 协议栈实现
  • 网络设备: 路由器、防火墙和负载均衡器的实现经验
  • 应用程序: 各种网络应用程序对 IPv4 ID 字段的使用情况

感谢这些实现者分享他们的经验和遇到的问题,这些反馈对于制定实用和可行的规范至关重要.

B.5 Historical Context (历史背景)​

本文档的开发受到了以下历史文档和讨论的启发:

  • RFC 791 (1981) - Internet Protocol 的原始规范
  • RFC 1122 (1989) - Requirements for Internet Hosts
  • RFC 4963 (2007) - IPv4 Reassembly Errors at High Data Rates

这些文档为理解 IPv4 ID 字段的设计意图和演进提供了重要的历史背景.

B.6 Organizational Support (组织支持)​

本文档的作者感谢以下组织的支持:

  • USC/ISI (University of Southern California / Information Sciences Institute): 为作者提供研究环境和资源支持
  • IETF (Internet Engineering Task Force): 提供标准化平台和流程支持
  • IRTF (Internet Research Task Force): 提供相关研究成果和理论基础

B.7 Special Thanks (特别感谢)​

特别感谢所有在邮件列表、会议和私下讨论中提供反馈和建议的人员.虽然无法在此一一列举,但每一条反馈都对本文档的质量和完整性做出了贡献.

感谢 RFC Editor 团队在编辑、格式化和出版过程中的专业工作.

B.8 Author's Address (作者地址)​

Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
U.S.A.

Phone: +1 (310) 448-9151
Email: [email protected]
URI: http://www.isi.edu/touch

Navigation: