Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 6864 USC/ISI
Updates: 791, 1122, 2003 February 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 6864 USC/ISI
Updates: 791, 1122, 2003 February 2013
Category: Standards Track
ISSN: 2070-1721
Updated Specification of the IPv4 ID Field
更新了IPv4 ID字段的规范
Abstract
摘要
The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used.
IPv4标识（ID）字段支持分段和重新组装，并且按照当前的规定，对于具有给定源地址/目标地址/协议元组的所有数据报，要求在最大生存期内是唯一的。如果强制执行，对于典型数据报大小，此唯一性要求将所有连接限制为6.4 Mbps。由于单个连接通常超过此速度，现有系统显然违反了当前规范。本文档更新了RFCs 791、1122和2003中IPv4 ID字段的规范，以更紧密地反映当前实践，并更紧密地匹配IPv6，从而仅当数据报实际分段时才定义该字段的值。本文还讨论了这些更改对数据报使用方式的影响。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6864.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. The IPv4 ID Field ...............................................4
3.1. Uses of the IPv4 ID Field ..................................4
3.2. Background on IPv4 ID Reassembly Issues ....................5
4. Updates to the IPv4 ID Specification ............................6
4.1. IPv4 ID Used Only for Fragmentation ........................7
4.2. Encouraging Safe IPv4 ID Use ...............................8
4.3. IPv4 ID Requirements That Persist ..........................8
5. Impact of Proposed Changes ......................................9
5.1. Impact on Legacy Internet Devices ..........................9
5.2. Impact on Datagram Generation .............................10
5.3. Impact on Middleboxes .....................................11
5.3.1. Rewriting Middleboxes ..............................11
5.3.2. Filtering Middleboxes ..............................12
5.4. Impact on Header Compression ..............................12
5.5. Impact of Network Reordering and Loss .....................13
5.5.1. Atomic Datagrams Experiencing Reordering or Loss ...13
5.5.2. Non-atomic Datagrams Experiencing
Reordering or Loss .................................14
6. Updates to Existing Standards ..................................14
6.1. Updates to RFC 791 ........................................14
6.2. Updates to RFC 1122 .......................................15
6.3. Updates to RFC 2003 .......................................16
7. Security Considerations ........................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
9. Acknowledgments ................................................19
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. The IPv4 ID Field ...............................................4
3.1. Uses of the IPv4 ID Field ..................................4
3.2. Background on IPv4 ID Reassembly Issues ....................5
4. Updates to the IPv4 ID Specification ............................6
4.1. IPv4 ID Used Only for Fragmentation ........................7
4.2. Encouraging Safe IPv4 ID Use ...............................8
4.3. IPv4 ID Requirements That Persist ..........................8
5. Impact of Proposed Changes ......................................9
5.1. Impact on Legacy Internet Devices ..........................9
5.2. Impact on Datagram Generation .............................10
5.3. Impact on Middleboxes .....................................11
5.3.1. Rewriting Middleboxes ..............................11
5.3.2. Filtering Middleboxes ..............................12
5.4. Impact on Header Compression ..............................12
5.5. Impact of Network Reordering and Loss .....................13
5.5.1. Atomic Datagrams Experiencing Reordering or Loss ...13
5.5.2. Non-atomic Datagrams Experiencing
Reordering or Loss .................................14
6. Updates to Existing Standards ..................................14
6.1. Updates to RFC 791 ........................................14
6.2. Updates to RFC 1122 .......................................15
6.3. Updates to RFC 2003 .......................................16
7. Security Considerations ........................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
9. Acknowledgments ................................................19
In IPv4, the Identification (ID) field is a 16-bit value that is unique for every datagram for a given source address, destination address, and protocol, such that it does not repeat within the maximum datagram lifetime (MDL) [RFC791] [RFC1122]. As currently specified, all datagrams between a source and destination of a given protocol must have unique IPv4 ID values over a period of this MDL, which is typically interpreted as two minutes and is related to the recommended reassembly timeout [RFC1122]. This uniqueness is currently specified as for all datagrams, regardless of fragmentation settings.
在IPv4中，标识（ID）字段是一个16位的值，对于给定源地址、目标地址和协议的每个数据报，该值是唯一的，因此在最大数据报生存期（MDL）[RFC791][RFC1122]内不会重复。按照目前的规定，给定协议的源和目标之间的所有数据报在此MDL期间必须具有唯一的IPv4 ID值，该MDL通常解释为两分钟，并与建议的重新组装超时有关[RFC1122]。此唯一性当前指定为所有数据报的唯一性，而与碎片设置无关。
Uniqueness of the IPv4 ID is commonly violated by high-speed devices; if strictly enforced, it would limit the speed of a single protocol between two IP endpoints to 6.4 Mbps for typical MTUs of 1500 bytes (assuming a 2-minute MDL, using the analysis presented in [RFC4963]). It is common for a single connection to operate far in excess of these rates, which strongly indicates that the uniqueness of the IPv4 ID as specified is already moot. Further, some sources have been generating non-varying IPv4 IDs for many years (e.g., cellphones), which resulted in support for such in RObust Header Compression (ROHC) [RFC5225].
高速设备通常会破坏IPv4 ID的唯一性；如果严格执行，它会将两个IP端点之间的单个协议的速度限制为1500字节的典型MTU的6.4 Mbps（使用[RFC4963]中提供的分析，假设2分钟MDL）。通常，单个连接的运行速率远远超过这些速率，这强烈表明指定的IPv4 ID的唯一性已经没有意义。此外，一些来源多年来一直在生成不可变的IPv4 ID（例如手机），这导致了对此类ID的支持，即健壮的报头压缩（ROHC）[RFC5225]。
This document updates the specification of the IPv4 ID field to more closely reflect current practice and to include considerations taken into account during the specification of the similar field in IPv6.
本文档更新了IPv4 ID字段的规范，以更紧密地反映当前实践，并包括在IPv6中指定类似字段时考虑的因素。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In this document, the characters ">>" preceding one or more indented lines indicate a requirement using the key words listed above. This convention aids reviewers in quickly identifying or finding this document's explicit requirements.
在本文档中，一行或多行缩进前的字符“>>”表示使用上述关键字的需求。本公约有助于审查人员快速确定或找到本文件的明确要求。
IP supports datagram fragmentation, where large datagrams are split into smaller components to traverse links with limited maximum transmission units (MTUs). Fragments are indicated in different ways in IPv4 and IPv6:
IP支持数据报分段，其中大数据报被分割成更小的组件，以通过具有有限最大传输单元（MTU）的链路。在IPv4和IPv6中，片段以不同的方式表示：
o In IPv4, fragments are indicated using four fields of the basic header: Identification (ID), Fragment Offset, a "Don't Fragment" (DF) flag, and a "More Fragments" (MF) flag [RFC791].
o 在IPv4中，使用基本标头的四个字段来指示片段：标识（ID）、片段偏移量、一个“不片段”（DF）标志和一个“更多片段”（MF）标志[RFC791]。
o In IPv6, fragments are indicated in an extension header that includes an ID, Fragment Offset, and an M (more fragments) flag similar to their counterparts in IPv4 [RFC2460].
o 在IPv6中，片段在扩展头中指示，扩展头包括一个ID、片段偏移量和一个M（更多片段）标志，类似于IPv4中的对应项[RFC2460]。
IPv6 fragmentation differs from IPv4 fragmentation in a few important ways. IPv6 fragmentation occurs only at the source, so a DF bit is not needed to prevent downstream devices from initiating fragmentation (i.e., IPv6 always acts as if DF=1). The IPv6 fragment header is present only when a datagram has been fragmented, or when the source has received a "packet too big" ICMPv6 error message indicating that the path cannot support the required minimum 1280-byte IPv6 MTU and is thus subject to translation [RFC2460] [RFC4443]. The latter case is relevant only for IPv6 datagrams sent to IPv4 destinations to support subsequent fragmentation after translation to IPv4.
IPv6碎片在几个重要方面与IPv4碎片不同。IPv6碎片仅在源位置发生，因此不需要DF位来防止下游设备启动碎片（即，IPv6始终充当DF=1的角色）。只有当数据报被分段时，或者当源收到“数据包太大”ICMPv6错误消息时，IPv6片段头才会出现，该消息指示路径无法支持所需的最小1280字节IPv6 MTU，因此需要进行转换[RFC2460][RFC4443]。后一种情况仅适用于发送到IPv4目的地的IPv6数据报，以支持转换为IPv4后的后续分段。
With the exception of these two cases, the ID field is not present for non-fragmented datagrams; thus, it is meaningful only for datagrams that are already fragmented or datagrams intended to be fragmented as part of IPv4 translation. Finally, the IPv6 ID field is 32 bits and required unique per source/destination address pair for IPv6, whereas for IPv4 it is only 16 bits and required unique per source address/destination address/protocol tuple.
除这两种情况外，对于非碎片数据报，ID字段不存在；因此，它仅对已经分段的数据报或打算作为IPv4转换的一部分分段的数据报有意义。最后，IPv6 ID字段是32位，对于IPv6，每个源/目标地址对要求唯一，而对于IPv4，它只有16位，每个源地址/目标地址/协议元组要求唯一。
This document focuses on the IPv4 ID field issues, because in IPv6 the field is larger and present only in fragments.
本文档主要关注IPv4 ID字段问题，因为在IPv6中，该字段更大，并且仅以片段形式出现。
The IPv4 ID field was originally intended for fragmentation and reassembly [RFC791]. Within a given source address, destination address, and protocol, fragments of an original datagram are matched based on their IPv4 ID. This requires that IDs be unique within the source address/destination address/protocol tuple when fragmentation is possible (e.g., DF=0) or when it has already occurred (e.g., frag_offset>0 or MF=1).
IPv4 ID字段最初用于分段和重新组装[RFC791]。在给定的源地址、目标地址和协议中，原始数据报的片段根据其IPv4 ID进行匹配。这要求在可能出现碎片（例如DF=0）或已经发生碎片（例如frag_offset>0或MF=1）时，源地址/目标地址/协议元组中的ID是唯一的。
Other uses have been envisioned for the IPv4 ID field. The field has been proposed as a way to detect and remove duplicate datagrams, e.g., at congested routers (noted in Section 3.2.1.5 of [RFC1122]) or in network accelerators. It has similarly been proposed for use at end hosts to reduce the impact of duplication on higher-layer protocols (e.g., additional processing in TCP or the need for application-layer duplicate suppression in UDP). This is discussed further in Section 5.1.
IPv4 ID字段还有其他用途。该字段被提议作为一种检测和删除重复数据报的方法，例如在拥挤的路由器（见[RFC1122]第3.2.1.5节）或网络加速器中。类似地，建议在终端主机上使用它，以减少复制对高层协议的影响（例如，TCP中的附加处理或UDP中应用层复制抑制的需要）。这将在第5.1节中进一步讨论。
The IPv4 ID field is used in some diagnostic tools to correlate datagrams measured at various locations along a network path. This is already insufficient in IPv6 because unfragmented datagrams lack an ID, so these tools are already being updated to avoid such reliance on the ID field. This is also discussed further in Section 5.1.
IPv4 ID字段在一些诊断工具中用于关联在网络路径上不同位置测量的数据报。这在IPv6中已经不够，因为未分段的数据报缺少ID，所以这些工具已经在更新，以避免对ID字段的依赖。第5.1节对此也作了进一步讨论。
The ID clearly needs to be unique (within the MDL, within the source address/destination address/protocol tuple) to support fragmentation and reassembly, but not all datagrams are fragmented or allow fragmentation. This document deprecates non-fragmentation uses, allowing the ID to be repeated (within the MDL, within the source address/destination address/protocol tuple) in those cases.
ID显然需要是唯一的（在MDL中，在源地址/目标地址/协议元组中），以支持分段和重组，但并非所有数据报都是分段的或允许分段的。本文档不支持非分段使用，允许在这些情况下重复ID（在MDL中，在源地址/目标地址/协议元组中）。
The following is a summary of issues with IPv4 fragment reassembly in high-speed environments raised previously [RFC4963]. Readers are encouraged to consult RFC 4963 for a more detailed discussion of these issues.
以下是先前提出的高速环境中IPv4片段重组问题的摘要[RFC4963]。鼓励读者参考RFC 4963，以获得关于这些问题的更详细讨论。
With the maximum IPv4 datagram size of 64 KB, a 16-bit ID field that does not repeat within 120 seconds means that the aggregate of all TCP connections of a given protocol between two IP endpoints is limited to roughly 286 Mbps; at a more typical MTU of 1500 bytes, this speed drops to 6.4 Mbps [RFC791] [RFC1122] [RFC4963]. This limit currently applies for all IPv4 datagrams within a single protocol (i.e., the IPv4 protocol field) between two IP addresses, regardless of whether fragmentation is enabled or inhibited and whether or not a datagram is fragmented.
最大IPv4数据报大小为64 KB，在120秒内不重复的16位ID字段意味着两个IP端点之间给定协议的所有TCP连接的聚合限制在大约286 Mbps；在1500字节的更典型MTU中，该速度降至6.4 Mbps[RFC791][RFC1122][RFC4963]。该限制目前适用于两个IP地址之间的单个协议（即IPv4协议字段）内的所有IPv4数据报，无论是否启用或禁止分段，也不管数据报是否分段。
IPv6, even at typical MTUs, is capable of 18.7 Tbps with fragmentation between two IP endpoints as an aggregate across all protocols, due to the larger 32-bit ID field (and the fact that the IPv6 next-header field, the equivalent of the IPv4 protocol field, is not considered in differentiating fragments). When fragmentation is not used, the field is absent, and in that case IPv6 speeds are not limited by the ID field uniqueness.
由于较大的32位ID字段（并且在区分片段时不考虑与IPv4协议字段等效的IPv6下一个报头字段这一事实），即使在典型的MTU上，IPv6也能够以18.7 TB的速率在两个IP端点之间形成碎片，作为所有协议的聚合。不使用分段时，该字段不存在，在这种情况下，IPv6速度不受ID字段唯一性的限制。
Note also that 120 seconds is only an estimate on the MDL. It is related to the reassembly timeout as a lower bound and the TCP Maximum Segment Lifetime as an upper bound (both as noted in [RFC1122]). Network delays are incurred in other ways, e.g., satellite links, which can add seconds of delay even though the Time to Live (TTL) is not decremented by a corresponding amount. There is thus no enforcement mechanism to ensure that datagrams older than 120 seconds are discarded.
还请注意，120秒只是MDL的估计值。它与作为下限的重新组装超时和作为上限的TCP最大段生存期有关（如[RFC1122]中所述）。网络延迟是以其他方式产生的，例如卫星链路，即使生存时间（TTL）没有相应减少，也会增加秒的延迟。因此，没有强制机制来确保丢弃超过120秒的数据报。
Wireless Internet devices are frequently connected at speeds over 54 Mbps, and wired links of 1 Gbps have been the default for several years. Although many end-to-end transport paths are congestion limited, these devices easily achieve 100+ Mbps application-layer throughput over LANs (e.g., disk-to-disk file transfer rates), and numerous throughput demonstrations with Commercial-Off-The-Shelf (COTS) systems over wide-area paths have exhibited these speeds for over a decade. This strongly suggests that IPv4 ID uniqueness has been moot for a long time.
无线互联网设备经常以超过54 Mbps的速度连接，数年来，1 Gbps的有线链路一直是默认的。尽管许多端到端传输路径受到拥塞限制，但这些设备很容易在局域网上实现100+Mbps的应用层吞吐量（例如，磁盘到磁盘的文件传输速率），并且在广域路径上使用商用现货（COTS）系统进行的大量吞吐量演示已经展示了这些速度超过十年。这有力地表明，IPv4 ID唯一性长期以来一直存在争议。
This document updates the specification of the IPv4 ID field in three distinct ways, as discussed in subsequent subsections:
本文档以三种不同的方式更新IPv4 ID字段的规范，如后续小节所述：
o Using the IPv4 ID field only for fragmentation
o 仅对碎片使用IPv4 ID字段
o Encouraging safe operation when the IPv4 ID field is used
o 使用IPv4 ID字段时鼓励安全操作
o Avoiding a performance impact when the IPv4 ID field is used
o 使用IPv4 ID字段时避免性能影响
There are two kinds of datagrams, which are defined below and used in the following discussion:
有两种数据报，其定义如下，并在以下讨论中使用：
o Atomic datagrams are datagrams not yet fragmented and for which further fragmentation has been inhibited.
o 原子数据报是尚未分段的数据报，其进一步分段已被禁止。
o Non-atomic datagrams are datagrams either that already have been fragmented or for which fragmentation remains possible.
o 非原子数据报是已经碎片化的数据报，或者碎片化仍然存在。
This same definition can be expressed in pseudo code, using common logical operators (equals is ==, logical 'and' is &&, logical 'or' is ||, greater than is >, and the parenthesis function is used typically) as follows:
这个相同的定义可以用伪代码表示，使用常见的逻辑运算符（equals is==，logical'和'is&&，logical'或'is|| |，大于is>，通常使用括号函数），如下所示：
o Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0)
o 原子数据报：（DF==1）和&（MF==0）和&（frag_offset==0）
o Non-atomic datagrams: (DF==0)||(MF==1)||(frag_offset>0)
o 非原子数据报：（DF==0）| |（MF==1）| |（frag_offset>0）
The test for non-atomic datagrams is the logical negative of the test for atomic datagrams; thus, all possibilities are considered.
非原子数据报的测试是原子数据报测试的逻辑否定；因此，考虑了所有可能性。
Although RFC 1122 suggests that the IPv4 ID field has other uses, including datagram de-duplication, such uses are already not interoperable with known implementations of sources that do not vary their ID. This document thus defines this field's value only for fragmentation and reassembly:
尽管RFC 1122建议IPv4 ID字段具有其他用途，包括重复数据报消除，但此类用途已经无法与不改变其ID的已知源实现进行互操作。因此，本文档仅为碎片和重组定义了此字段的值：
>> The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly.
>>IPv4 ID字段不得用于碎片和重新组装以外的目的。
Datagram de-duplication can still be accomplished using hash-based duplicate detection for cases where the ID field is absent (IPv6 unfragmented datagrams), which can also be applied to IPv4 atomic datagrams without utilizing the ID field [RFC6621].
对于缺少ID字段的情况（IPv6非分段数据报），仍然可以使用基于哈希的重复检测来完成重复数据报消除，这也可以在不使用ID字段的情况下应用于IPv4原子数据报[RFC6621]。
In atomic datagrams, the IPv4 ID field has no meaning; thus, it can be set to an arbitrary value, i.e., the requirement for non-repeating IDs within the source address/destination address/protocol tuple is no longer required for atomic datagrams:
在原子数据报中，IPv4 ID字段没有意义；因此，可以将其设置为任意值，即，原子数据报不再需要源地址/目标地址/协议元组内的非重复ID要求：
>> Originating sources MAY set the IPv4 ID field of atomic datagrams to any value.
>>始发源可以将原子数据报的IPv4 ID字段设置为任何值。
Second, all network nodes, whether at intermediate routers, destination hosts, or other devices (e.g., NATs and other address-sharing mechanisms, firewalls, tunnel egresses), cannot rely on the field of atomic datagrams:
其次，所有网络节点，无论是在中间路由器、目标主机或其他设备（例如NAT和其他地址共享机制、防火墙、隧道出口）上，都不能依赖原子数据报字段：
>> All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams.
>>所有检查IPv4标头的设备都必须忽略原子数据报的IPv4 ID字段。
The IPv4 ID field is thus meaningful only for non-atomic datagrams -- either those datagrams that have already been fragmented or those for which fragmentation remains permitted. Atomic datagrams are detected by their DF, MF, and fragmentation offset fields as explained in Section 4, because such a test is completely backward compatible; thus, this document does not reserve any IPv4 ID values, including 0, as distinguished.
因此，IPv4 ID字段仅对非原子数据报有意义——要么是那些已经被分段的数据报，要么是那些允许分段的数据报。原子数据报由其DF、MF和碎片偏移字段检测，如第4节所述，因为这样的测试是完全向后兼容的；因此，本文档不保留任何IPv4 ID值，包括0。
Deprecating the use of the IPv4 ID field for non-reassembly uses should have little -- if any -- impact. IPv4 IDs are already frequently repeated, e.g., over even moderately fast connections and from some sources that do not vary the ID at all, and no adverse impact has been observed. Duplicate suppression was suggested
不赞成将IPv4 ID字段用于非重组用途应该不会有什么影响。IPv4 ID已经频繁重复，例如，即使是通过中等速度的连接，并且来自一些根本不改变ID的来源，并且没有观察到任何不利影响。建议重复抑制
[RFC1122] and has been implemented in some protocol accelerators, but no impacts of IPv4 ID reuse have been noted to date. Routers are not required to issue ICMPs on any particular timescale, and so IPv4 ID repetition should not have been used for validation purposes; this scenario has not been observed. Besides, repetition already occurs and would have been noticed [RFC1812]. ICMP relaying at tunnel ingresses is specified to use soft state rather than a datagram cache; for similar reasons, if the latter is used, this should have been noticed [RFC2003]. These and other legacy issues are discussed further in Section 5.1.
[RFC1122]并已在一些协议加速器中实现，但迄今为止尚未注意到IPv4 ID重用的影响。路由器不需要在任何特定的时间尺度上发布ICMP，因此IPv4 ID重复不应用于验证目的；尚未观察到这种情况。此外，重复已经发生，并且会被注意到[RFC1812]。隧道入口处的ICMP中继指定为使用软状态，而不是数据报缓存；出于类似原因，如果使用后者，则应注意这一点[RFC2003]。第5.1节将进一步讨论这些和其他遗留问题。
This document also changes the specification of the IPv4 ID field to encourage its safe use.
本文档还更改了IPv4 ID字段的规范，以鼓励其安全使用。
As discussed in RFC 1122, if TCP retransmits a segment, it may be possible to reuse the IPv4 ID (see Section 6.2). This can make it difficult for a source to avoid IPv4 ID repetition for received fragments. RFC 1122 concludes that this behavior "is not useful"; this document formalizes that conclusion as follows:
如RFC 1122中所述，如果TCP重新传输一段，则可以重用IPv4 ID（参见第6.2节）。这会使源很难避免接收片段的IPv4 ID重复。RFC1122得出结论，这种行为“没有用处”；本文件将该结论正式化如下：
>> The IPv4 ID of non-atomic datagrams MUST NOT be reused when sending a copy of an earlier non-atomic datagram.
>>发送早期非原子数据报的副本时，不得重用非原子数据报的IPv4 ID。
RFC 1122 also suggests that fragments can overlap. Such overlap can occur if successive retransmissions are fragmented in different ways but with the same reassembly IPv4 ID. This overlap is noted as the result of reusing IPv4 IDs when retransmitting datagrams, which this document deprecates. However, it is also the result of in-network datagram duplication, which can still occur. As a result, this document does not change the need for receivers to support overlapping fragments.
RFC1122还表明片段可以重叠。如果连续的重新传输以不同的方式分段，但具有相同的重新组装IPv4 ID，则可能会发生这种重叠。这种重叠是由于在重新传输数据报时重用IPv4 ID造成的，本文档对此表示反对。然而，这也是网络内数据报重复的结果，这种情况仍然可能发生。因此，本文档不会改变接收器支持重叠片段的需要。
This document does not relax the IPv4 ID field uniqueness requirements of [RFC791] for non-atomic datagrams, that is:
本文件并未放宽[RFC791]对非原子数据报的IPv4 ID字段唯一性要求，即：
>> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID values within one MDL for a given source address/destination address/protocol tuple.
>>对于给定的源地址/目标地址/协议元组，发出非原子数据报的源不得在一个MDL内重复IPv4 ID值。
Such sources include originating hosts, tunnel ingresses, and NATs (including other address-sharing mechanisms) (see Section 5.3).
此类源包括始发主机、隧道入口和NAT（包括其他地址共享机制）（见第5.3节）。
This document does not relax the requirement that all network devices honor the DF bit, that is:
本文件并未放宽所有网络设备遵守DF位的要求，即：
>> IPv4 datagrams whose DF=1 MUST NOT be fragmented.
>>DF=1的IPv4数据报不得分段。
>> IPv4 datagram transit devices MUST NOT clear the DF bit.
>>IPv4数据报传输设备不得清除DF位。
Specifically, DF=1 prevents fragmenting atomic datagrams. DF=1 also prevents further fragmenting received fragments. In-network fragmentation is permitted only when DF=0; this document does not change that requirement.
具体来说，DF=1可以防止原子数据报的碎片化。DF=1还可以防止进一步分割接收到的片段。仅当DF=0时才允许网络内分段；本文件不会改变该要求。
This section discusses the impact of the proposed changes on legacy devices, datagram generation in updated devices, middleboxes, and header compression.
本节讨论建议的更改对遗留设备、更新设备中的数据报生成、中间盒和报头压缩的影响。
Legacy uses of the IPv4 ID field consist of fragment generation, fragment reassembly, duplicate datagram detection, and "other" uses.
IPv4 ID字段的传统用途包括片段生成、片段重组、重复数据报检测和“其他”用途。
Current devices already generate ID values that are reused within the source address/destination address/protocol tuple in less than the current estimated Internet MDL of two minutes. They assume that the MDL over their end-to-end path is much lower.
当前设备已经生成了ID值，这些ID值在源地址/目标地址/协议元组中重用的时间少于当前估计的两分钟的Internet MDL。他们假设端到端路径上的MDL要低得多。
Existing devices have been known to generate non-varying IDs for atomic datagrams for nearly a decade, notably some cellphones. Such constant ID values are the reason for their support as an optimization of ROHC [RFC5225]. This is discussed further in Section 5.4. Generation of IPv4 datagrams with constant (zero) IDs is also described as part of the IP/ICMP translation standard [RFC6145].
近十年来，人们已经知道现有设备可以为原子数据报生成非可变ID，特别是一些手机。此类恒定ID值是其作为ROHC优化支持的原因[RFC5225]。这将在第5.4节中进一步讨论。IP/ICMP转换标准[RFC6145]还描述了使用恒定（零）ID生成IPv4数据报。
Many current devices support fragmentation that ignores the IPv4 Don't Fragment (DF) bit. Such devices already transit traffic from sources that reuse the ID. If fragments of different datagrams reusing the same ID (within the source address/destination address/protocol tuple) arrive at the destination interleaved, fragmentation would fail and traffic would be dropped. Either such interleaving is uncommon or traffic from such devices is not widely traversing these DF-ignoring devices, because significant occurrence of reassembly errors has not been reported. DF-ignoring devices do not comply with existing standards, and it is not feasible to update the standards to allow them as compliant.
许多当前设备支持忽略IPv4不分段（DF）位的分段。此类设备已经从重用ID的源传输流量。如果重用同一ID的不同数据报片段（在源地址/目标地址/协议元组内）交错到达目的地，则碎片将失败，流量将被丢弃。这样的交织是不常见的，或者来自这样的设备的流量没有广泛地穿过这些DF忽略设备，因为没有报告重组错误的重大发生。DF忽略设备不符合现有标准，更新标准以使其符合标准是不可行的。
The ID field has been envisioned for use in duplicate detection, as discussed in Section 4.1. Although this document now allows IPv4 ID reuse for atomic datagrams, such reuse is already common (as noted above). Protocol accelerators are known to implement IPv4 duplicate detection, but such devices are also known to violate other Internet standards to achieve higher end-to-end performance. These devices would already exhibit erroneous drops for this current traffic, and this has not been reported.
如第4.1节所述，已设想将ID字段用于重复检测。尽管本文档现在允许对原子数据报重用IPv4 ID，但这种重用已经很常见（如上所述）。众所周知，协议加速器可以实现IPv4重复检测，但这类设备也会违反其他互联网标准以实现更高的端到端性能。这些设备对于当前的流量已经显示出错误的下降，但这尚未报告。
There are other potential uses of the ID field, such as for diagnostic purposes. Such uses already need to accommodate atomic datagrams with reused ID fields. There are no reports of such uses having problems with current datagrams that reuse IDs.
ID字段还有其他潜在用途，例如用于诊断目的。这样的使用已经需要使用重用的ID字段来容纳原子数据报。目前还没有关于此类使用与重用ID的当前数据报存在问题的报告。
Thus, as a result of previous requirements, this document recommends that IPv4 duplicate detection and diagnostic mechanisms apply IPv6-compatible methods, i.e., methods that do not rely on the ID field (e.g., as suggested in [RFC6621]). This is a consequence of using the ID field only for reassembly, as well as the known hazard of existing devices already reusing the ID field.
因此，根据先前的要求，本文件建议IPv4重复检测和诊断机制采用与IPv6兼容的方法，即不依赖ID字段的方法（如[RFC6621]中建议的方法）。这是仅将ID字段用于重新组装的结果，以及现有设备重复使用ID字段的已知危险。
The following is a summary of the recommendations that are the result of the previous changes to the IPv4 ID field specification.
以下是由于先前对IPv4 ID字段规范进行了更改而产生的建议摘要。
Because atomic datagrams can use arbitrary IPv4 ID values, the ID field no longer imposes a performance impact in those cases. However, the performance impact remains for non-atomic datagrams. As a result:
由于原子数据报可以使用任意IPv4 ID值，因此在这些情况下，ID字段不再对性能产生影响。但是，对于非原子数据报，性能影响仍然存在。因此：
>> Sources of non-atomic IPv4 datagrams MUST rate-limit their output to comply with the ID uniqueness requirements. Such sources include, in particular, DNS over UDP [RFC2671].
>>非原子IPv4数据报的源必须对其输出进行速率限制，以符合ID唯一性要求。此类来源尤其包括UDP上的DNS[RFC2671]。
Because there is no strict definition of the MDL, reassembly hazards exist regardless of the IPv4 ID reuse interval or the reassembly timeout. As a result:
因为MDL没有严格的定义，所以无论IPv4 ID重用间隔或重新组装超时如何，都存在重新组装危险。因此：
>> Higher-layer protocols SHOULD verify the integrity of IPv4 datagrams, e.g., using a checksum or hash that can detect reassembly errors (the UDP and TCP checksums are weak in this regard, but better than nothing).
>>高层协议应验证IPv4数据报的完整性，例如，使用能够检测重组错误的校验和或散列（UDP和TCP校验和在这方面很弱，但总比没有好）。
Additional integrity checks can be employed using tunnels, as supported by the Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], IPsec [RFC4301], or the Stream Control Transmission Protocol (SCTP) [RFC4960]. Such checks can avoid the reassembly
如子网封装和适配层（SEAL）[RFC5320]、IPsec[RFC4301]或流控制传输协议（SCTP）[RFC4960]所支持，可使用隧道进行额外的完整性检查。这样的检查可以避免重新组装
hazards that can occur when using UDP and TCP checksums [RFC4963] or when using partial checksums as in UDP-Lite [RFC3828]. Because such integrity checks can avoid the impact of reassembly errors:
使用UDP和TCP校验和[RFC4963]或使用UDP Lite[RFC3828]中的部分校验和时可能发生的危险。由于此类完整性检查可避免重新组装错误的影响：
>> Sources of non-atomic IPv4 datagrams using strong integrity checks MAY reuse the ID within intervals that are smaller than typical MDL values.
>>使用强完整性检查的非原子IPv4数据报源可能会在小于典型MDL值的间隔内重用ID。
Note, however, that such frequent reuse can still result in corrupted reassembly and poor throughput, although it would not propagate reassembly errors to higher-layer protocols.
然而，请注意，这种频繁的重用仍然会导致重组损坏和吞吐量降低，尽管它不会将重组错误传播到更高层的协议。
Middleboxes include rewriting devices such as network address translators (NATs), network address/port translators (NAPTs), and other address-sharing mechanisms (ASMs). They also include devices that inspect and filter datagrams but that are not routers, such as accelerators and firewalls.
中间盒包括重写设备，如网络地址转换器（NAT）、网络地址/端口转换器（NAPT）和其他地址共享机制（ASM）。它们还包括检查和过滤数据报但不是路由器的设备，如加速器和防火墙。
The changes proposed in this document may not be implemented by middleboxes; however, these changes are more likely to make current middlebox behavior compliant than to affect the service provided by those devices.
本文件中提出的变更不得由中间商实施；但是，这些更改更有可能使当前的中间包行为符合要求，而不是影响这些设备提供的服务。
NATs and NAPTs rewrite IP fields, and tunnel ingresses (using IPv4 encapsulation) copy and modify some IPv4 fields; all are therefore considered datagram sources, as are any devices that rewrite any portion of the source address/destination address/protocol/ID tuple for any datagrams [RFC3022]. This is also true for other ASMs, including IPv4 Residual Deployment (4rd) [De11], IVI [RFC6219], and others in the "A+P" (address plus port) family [Bo11]. It is equally true for any other datagram-rewriting mechanism. As a result, they are subject to all the requirements of any datagram source, as has been noted.
NAT和NAPT重写IP字段，隧道入口（使用IPv4封装）复制和修改一些IPv4字段；因此，所有设备都被视为数据报源，重写任何数据报的源地址/目标地址/协议/ID元组的任何部分的设备也是如此[RFC3022]。其他ASM也是如此，包括IPv4剩余部署（4rd）[De11]、IVI[RFC6219]和“A+P”（地址加端口）系列[Bo11]中的其他ASM。这同样适用于任何其他数据报重写机制。因此，如前所述，它们受制于任何数据报源的所有要求。
NATs/ASMs/rewriters present a particularly challenging situation for fragmentation. Because they overwrite portions of the reassembly tuple in both directions, they can destroy tuple uniqueness and result in a reassembly hazard. Whenever IPv4 source address, destination address, or protocol fields are modified, a NAT/ASM/rewriter needs to ensure that the ID field is generated appropriately, rather than simply copied from the incoming datagram.
NAT/ASMs/重写器对于碎片化来说是一种特别具有挑战性的情况。因为它们会在两个方向上覆盖重组元组的部分，所以它们会破坏元组的唯一性并导致重组危险。每当修改IPv4源地址、目标地址或协议字段时，NAT/ASM/重写器都需要确保正确生成ID字段，而不是简单地从传入数据报复制。
Specifically:
明确地：
>> Address-sharing or rewriting devices MUST ensure that the IPv4 ID field of datagrams whose addresses or protocols are translated comply with these requirements as if the datagram were sourced by that device.
>>地址共享或重写设备必须确保其地址或协议被转换的数据报的IPv4 ID字段符合这些要求，就像数据报由该设备来源一样。
This compliance means that the IPv4 ID field of non-atomic datagrams translated at a NAT/ASM/rewriter needs to obey the uniqueness requirements of any IPv4 datagram source. Unfortunately, translated fragments already violate that requirement, as they repeat an IPv4 ID within the MDL for a given source address/destination address/protocol tuple.
这种遵从性意味着在NAT/ASM/重写器上转换的非原子数据报的IPv4 ID字段需要遵守任何IPv4数据报源的唯一性要求。不幸的是，翻译的片段已经违反了这一要求，因为它们在MDL中为给定的源地址/目标地址/协议元组重复IPv4 ID。
Such problems with transmitting fragments through NATs/ASMs/rewriters are already known; translation is typically based on the transport port number, which is present in only the first fragment anyway [RFC3022]. This document underscores the point that not only is reassembly (and possibly subsequent fragmentation) required for translation, it can be used to avoid issues with IPv4 ID uniqueness.
通过NAT/ASMs/重写器传输片段的此类问题已经为人所知；转换通常基于传输端口号，该端口号仅出现在第一个片段中[RFC3022]。本文档强调了一点，即转换不仅需要重新组装（以及可能的后续碎片），还可以使用它来避免IPv4 ID唯一性问题。
Note that NATs/ASMs already need to exercise special care when emitting datagrams on their public side, because merging datagrams from many sources onto a single outgoing source address can result in IPv4 ID collisions. This situation precedes this document and is not affected by it. It is exacerbated in large-scale, so-called "carrier grade" NATs [Pe11].
请注意，NAT/ASM在公共端发送数据报时已经需要特别小心，因为将来自多个源的数据报合并到单个传出源地址可能会导致IPv4 ID冲突。这种情况发生在本文件之前，不受其影响。这种情况在大规模的所谓“载波级”NAT中加剧[Pe11]。
Tunnel ingresses act as sources for the outermost header, but tunnels act as routers for the inner headers (i.e., the datagram as arriving at the tunnel ingress). Ingresses can always fragment as originating sources of the outer header, because they control the uniqueness of that IPv4 ID field and the value of DF on the outer header independent of those values on the inner (arriving datagram) header.
隧道入口充当最外层报头的源，但隧道充当内部报头的路由器（即到达隧道入口的数据报）。入口始终可以作为外部报头的原始源进行分段，因为它们控制IPv4 ID字段的唯一性和外部报头上的DF值，而与内部（到达数据报）报头上的值无关。
Middleboxes also include devices that filter datagrams, such as network accelerators and firewalls. Some such devices reportedly feature datagram de-duplication that relies on IP ID uniqueness to identify duplicates, which has been discussed in Section 5.1.
中间盒还包括过滤数据报的设备，如网络加速器和防火墙。据报道，一些此类设备具有数据报重复数据消除功能，该功能依赖于IP ID唯一性来识别重复数据，这已在第5.1节中讨论。
Header compression algorithms already accommodate various ways in which the IPv4 ID changes between sequential datagrams [RFC1144] [RFC2508] [RFC3545] [RFC5225]. Such algorithms currently assume that the IPv4 ID is preserved end-to-end. Some algorithms already allow
报头压缩算法已经适应了IPv4 ID在顺序数据报[RFC1144][RFC2508][RFC3545][RFC5225]之间变化的各种方式。这些算法目前假定IPv4 ID是端到端保留的。一些算法已经允许
the assumption that the ID does not change (e.g., ROHC [RFC5225]), where others include non-changing IDs via zero deltas (e.g., Enhanced Compressed RTP (ECRTP) [RFC3545]).
假设ID不变（例如ROHC[RFC5225]），其他假设包括通过零增量的不变ID（例如增强型压缩RTP（ECRTP）[RFC3545]）。
When compression assumes a changing ID as a default, having a non-changing ID can make compression less efficient. Such non-changing IDs have been described in various RFCs (e.g., footnote 21 of [RFC1144] and cRTP [RFC2508]). When compression can assume a non-changing IPv4 ID -- as with ROHC and ECRTP -- efficiency can be increased.
当压缩假定更改ID为默认值时，使用不更改的ID可能会降低压缩效率。在各种RFC（例如，[RFC1144]的脚注21和cRTP[RFC2508]）中已经描述了这种不改变的ID。当压缩可以假定一个不变的IPv4 ID时——就像ROHC和ECRTP一样——效率可以提高。
Tolerance to network reordering and loss is a key feature of the Internet architecture. Although most current IP networks avoid gratuitous such events, both reordering and loss can and do occur. Datagrams are already intended to be reordered or lost, and recovery from those errors (where supported) already occurs at the transport or higher protocol layers.
容忍网络重新排序和丢失是Internet体系结构的一个关键特性。尽管目前大多数IP网络都避免了这种不必要的事件，但重新排序和丢失都会发生。数据报已经准备好重新排序或丢失，并且在传输层或更高的协议层已经发生了从这些错误中恢复（如果支持的话）。
Reordering is typically associated with routing transients or where flows are split across multiple paths. Loss is typically associated with path congestion or link failure (partial or complete). The impact of such events is different for atomic and non-atomic datagrams and is discussed below. In summary, the recommendations of this document make the Internet more robust to reordering and loss by emphasizing the requirements of ID uniqueness for non-atomic datagrams and by more clearly indicating the impact of these requirements on both endpoints and datagram transit devices.
重新排序通常与路由瞬变或流在多条路径上拆分相关。丢失通常与路径拥塞或链路故障（部分或完全）有关。此类事件对原子和非原子数据报的影响不同，下文将对此进行讨论。总而言之，本文件的建议通过强调非原子数据报的ID唯一性要求，并通过更明确地指出这些要求对端点和数据报传输设备的影响，使互联网对重新排序和丢失更具鲁棒性。
Reusing ID values does not affect atomic datagrams when the DF bit is correctly respected, because order restoration does not depend on the datagram header. TCP uses a transport header sequence number; in some other protocols, sequence is indicated and restored at the application layer.
当DF位得到正确尊重时，重用ID值不会影响原子数据报，因为顺序恢复不依赖于数据报头。TCP使用传输头序列号；在其他一些协议中，在应用层指示和恢复序列。
When DF=1 is ignored, reordering or loss can cause fragments of different datagrams to be interleaved and thus incorrectly reassembled and discarded. Reuse of ID values in atomic datagrams, as permitted by this document, can result in higher datagram loss in such cases. Situations such as this already can exist because there are known devices that use a constant ID for atomic datagrams (some cellphones), and there are known devices that ignore DF=1, but high levels of corresponding loss have not been reported. The lack of such reports indicates either a lack of reordering or a loss in such cases or a tolerance to the resulting losses. If such issues are
当忽略DF=1时，重新排序或丢失可能会导致不同数据报的片段交错，从而错误地重新组装和丢弃。本文档允许在原子数据报中重复使用ID值，在这种情况下可能会导致更高的数据报丢失。这样的情况已经存在，因为已知的设备对原子数据报（某些手机）使用恒定ID，并且已知的设备忽略DF=1，但没有报告相应的高丢失率。缺乏此类报告表明，在这种情况下，要么缺乏重新订购，要么出现损失，要么对由此产生的损失有容忍度。如果这些问题得到解决
reported, it would be more productive to address non-compliant devices (that ignore DF=1), because it is impractical to define Internet specifications to tolerate devices that ignore those specifications. This is why this document emphasizes the need to honor DF=1, as well as that datagram transit devices need to retain the DF bit as received (i.e., rather than clear it).
据报道，解决不符合要求的设备（忽略DF=1）将更有成效，因为定义互联网规范来容忍忽略这些规范的设备是不切实际的。这就是为什么本文件强调需要遵守DF=1，以及数据报传输设备需要在接收时保留DF位（即，而不是清除它）。
Non-atomic datagrams rely on the uniqueness of the ID value to tolerate reordering of fragments, notably where fragments of different datagrams are interleaved as a result of such reordering. Fragment loss can result in reassembly of fragments from different origin datagrams, which is why ID reuse in non-atomic datagrams is based on datagram (fragment) maximum lifetime, not just expected reordering interleaving.
非原子数据报依赖于ID值的唯一性来容忍片段的重新排序，特别是在不同数据报的片段由于这种重新排序而交织的情况下。片段丢失可能导致来自不同来源数据报的片段重新组装，这就是为什么非原子数据报中的ID重用基于数据报（片段）的最大生存期，而不仅仅是预期的重新排序交错。
This document does not change the requirements for uniqueness of IDs in non-atomic datagrams and thus does not affect their tolerance to such reordering or loss. This document emphasizes the need for ID uniqueness for all datagram sources, including rewriting middleboxes; the need to rate-limit sources to ensure ID uniqueness; the need to not reuse the ID for retransmitted datagrams; and the need to use higher-layer integrity checks to prevent reassembly errors -- all of which result in a higher tolerance to reordering or loss events.
本文件不改变非原子数据报中ID唯一性的要求，因此不影响其对此类重新排序或丢失的容忍度。本文件强调所有数据报源的ID唯一性，包括重写中间盒；需要对来源进行评级限制，以确保ID的唯一性；不需要为重新传输的数据报重用该ID；需要使用更高层次的完整性检查来防止重新组装错误——所有这些都会导致对重新排序或丢失事件的更高容忍度。
The following sections address the specific changes to existing protocols indicated by this document.
以下各节介绍了本文件所述现有协议的具体变更。
RFC 791 states that:
RFC 791规定：
The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system.
互联网数据报的原始协议模块将标识字段设置为一个值，该值对于该源-目的地对和协议来说必须是唯一的，并且在该数据报将在互联网系统中处于活动状态的时间内。
It later states that:
它后来指出：
Thus, the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet.
因此，发送方必须选择在数据报（或其任何片段）在互联网上存在的时间内，该源、目的地对和协议的唯一标识符。
It seems then that a sending protocol module needs to keep a table of Identifiers, one entry for each destination it has communicated with in the last maximum datagram lifetime for the internet.
这样看来，发送协议模块需要保留一个标识符表，其中每个目的地对应一个条目，该目的地在互联网的最后一个最大数据报生存期内与其通信。
However, since the Identifier field allows 65,536 different values, some host may be able to simply use unique identifiers independent of destination.
然而，由于标识符字段允许65536个不同的值，一些主机可能能够简单地使用独立于目的地的唯一标识符。
It is appropriate for some higher level protocols to choose the identifier. For example, TCP protocol modules may retransmit an identical TCP segment, and the probability for correct reception would be enhanced if the retransmission carried the same identifier as the original transmission since fragments of either datagram could be used to construct a correct TCP segment.
对于一些更高级别的协议来说，选择标识符是合适的。例如，TCP协议模块可重新传输相同的TCP段，并且如果重新传输携带与原始传输相同的标识符，则正确接收的概率将增强，因为任一数据报的片段可用于构造正确的TCP段。
This document changes RFC 791 as follows:
本文件将RFC 791更改如下：
o IPv4 ID uniqueness applies to only non-atomic datagrams.
o IPv4 ID唯一性仅适用于非原子数据报。
o Retransmitted non-atomic IPv4 datagrams are no longer permitted to reuse the ID value.
o 重新传输的非原子IPv4数据报不再允许重用ID值。
RFC 1122 states in Section 3.2.1.5 ("Identification: RFC 791 Section 3.2") that:
RFC 1122在第3.2.1.5节（“标识：RFC 791第3.2节”）中规定：
When sending an identical copy of an earlier datagram, a host MAY optionally retain the same Identification field in the copy.
当发送先前数据报的相同副本时，主机可以选择在副本中保留相同的标识字段。
DISCUSSION: 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.
讨论：一些互联网协议专家坚持认为，当主机发送与先前数据报相同的副本时，新副本应包含与原始数据报相同的标识值。有两个建议的优点：（1）如果数据报是碎片化的，并且一些碎片丢失，则接收器可以从原始和副本的碎片重建完整的数据报；（2） 拥塞网关可能使用IP标识字段（和片段偏移量）来丢弃队列中的重复数据报。
This document changes RFC 1122 as follows:
本文件将RFC 1122更改如下：
o The IPv4 ID field is no longer permitted to be used for duplicate detection. This applies to both atomic and non-atomic datagrams.
o IPv4 ID字段不再允许用于重复检测。这适用于原子和非原子数据报。
o Retransmitted non-atomic IPv4 datagrams are no longer permitted to reuse the ID value.
o 重新传输的非原子IPv4数据报不再允许重用ID值。
This document updates how IPv4-in-IPv4 tunnels create IPv4 ID values for the IPv4 outer header [RFC2003], but only in the same way as for any other IPv4 datagram source. Specifically, RFC 2003 states the following, where [10] refers to RFC 791:
本文档更新IPv4-in-IPv4隧道如何为IPv4外部标头[RFC2003]创建IPv4 ID值，但仅以与任何其他IPv4数据报源相同的方式。具体而言，RFC 2003规定如下，其中[10]指RFC 791：
Identification, Flags, Fragment Offset
标识、标志、碎片偏移
These three fields are set as specified in [10]...
这三个字段按[10]中的规定设置。。。
This document changes RFC 2003 as follows:
本文件将RFC 2003更改如下：
o The IPv4 ID field is set as permitted by RFC 6864.
o IPv4 ID字段设置为RFC 6864允许的。
When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), its value becomes unconstrained; therefore, that field can more easily be used as a covert channel. For some atomic datagrams it is now possible, and may be desirable, to rewrite the IPv4 ID field to avoid its use as such a channel. Rewriting would be prohibited for datagrams protected by the IPsec Authentication Header (AH), although we do not recommend use of the AH to achieve this result [RFC4302].
当IPv4 ID在接收时被忽略时（例如，对于原子数据报），其值变得不受约束；因此，该字段可以更容易地用作隐蔽通道。对于某些原子数据报，现在可以重写IPv4 ID字段，以避免将其用作此类通道，这也是可取的。对于受IPsec身份验证头（AH）保护的数据报，将禁止重写，尽管我们不建议使用AH来实现此结果[RFC4302]。
The IPv4 ID also now adds much less to the entropy of the header of a datagram. Such entropy might be used as input to cryptographic algorithms or pseudorandom generators, although IDs have never been assured sufficient entropy for such purposes. The IPv4 ID had previously been unique (for a given source/address pair, and protocol field) within one MDL, although this requirement was not enforced and clearly is typically ignored. The IPv4 ID of atomic datagrams is not required unique and so contributes no entropy to the header.
IPv4 ID现在也大大减少了数据报报头的熵。这种熵可以用作密码算法或伪随机发生器的输入，尽管从未保证ID有足够的熵用于这种目的。IPv4 ID以前在一个MDL中是唯一的（对于给定的源/地址对和协议字段），尽管这一要求没有强制执行，显然通常会被忽略。原子数据报的IPv4 ID不要求唯一，因此不会对报头产生熵。
The deprecation of the IPv4 ID field's uniqueness for atomic datagrams can defeat the ability to count devices behind a NAT/ASM/rewriter [Be02]. This is not intended as a security feature, however.
不推荐IPv4 ID字段对原子数据报的唯一性可能会破坏NAT/ASM/重写器后面的设备计数功能[Be02]。然而，这并不是一个安全特性。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Be02] Bellovin, S., "A Technique for Counting NATted Hosts", Internet Measurement Conference, Proceedings of the 2nd ACM SIGCOMM Workshop on Internet Measurement, November 2002.
[Be02]Bellovin，S.，“计算NATted主机的技术”，互联网测量会议，第二届ACM SIGCOMM互联网测量研讨会论文集，2002年11月。
[Bo11] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments", Work in Progress, September 2011.
[Bo11]Boucadair，M.，Touch，J.，Levis，P.，和R.Penno，“分析备选解决方案以揭示共享地址部署中的主机标识符”，正在进行的工作，2011年9月。
[De11] Despres, R., Ed., Matsushima, S., Murakami, T., and O. Troan, "IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional", Work in Progress, March 2011.
[De11]Despres，R.，Ed.，Matsushima，S.，Murakami，T.，和O.Troan，“跨IPv6服务网络的IPv4剩余部署（第四代）ISP-NAT成为可选”，正在进行的工作，2011年3月。
[Pe11] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", Work in Progress, December 2012.
[Pe11]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，在建工程，2012年12月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[RFC3545]Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.，和P.Ruddy，“具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 35452003年7月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，Ed.，和G.Fairhurst，Ed.，“轻量级用户数据报协议（UDP-Lite）”，RFC 38282004年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225]Pelletier，G.和K.Sandlund，“鲁棒头压缩版本2（ROHCv2）：RTP、UDP、IP、ESP和UDP Lite的配置文件”，RFC 52252008年4月。
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320]Templin，F.，Ed.“子网络封装和适配层（SEAL）”，RFC 5320，2010年2月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, May 2011.
[RFC6219]Li，X.，Bao，C.，Chen，M.，Zhang，H.，和J.Wu，“针对IPv4/IPv6共存和过渡的中国教育和研究网络（CERNET）IVI翻译设计和部署”，RFC 6219，2011年5月。
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, May 2012.
[RFC6621]Macker，J.，Ed.，“简化多播转发”，RFC 6621，2012年5月。
This document was inspired by numerous discussions with the author by Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin, as well as members participating in the Internet Area Working Group. Detailed feedback was provided by Gorry Fairhurst, Brian Haberman, Ted Hardie, Mike Heard, Erik Nordmark, Carlos Pignataro, and Dan Wing. This document originated as an Independent Submissions stream document co-authored by Matt Mathis, PSC, and his contributions are greatly appreciated.
本文件的灵感来源于Jari Arkko、Lars Eggert、Dino Farinaci和Fred Templin与作者的多次讨论，以及参与互联网领域工作组的成员。戈里·费尔赫斯特、布赖恩·哈伯曼、特德·哈迪、迈克·赫德、埃里克·诺德马克、卡洛斯·皮格纳塔罗和丹·温提供了详细的反馈。本文件源于Matt Mathis，PSC合著的独立提交流文件，非常感谢他的贡献。
This document was initially prepared using 2-Word-v2.0.template.dot.
本文件最初使用2-Word-v2.0.template.dot编制。
Author's Address
作者地址
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292-6695号。
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
Phone: +1 (310) 448-9151
EMail: touch@isi.edu