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字段的规范



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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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中指定类似字段时考虑的因素。

2. Conventions Used in This Document
2. 本文件中使用的公约

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.


3. The IPv4 ID Field
3. IPv4 ID字段

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:


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中,该字段更大,并且仅以片段形式出现。

3.1. Uses of the IPv4 ID Field
3.1. IPv4 ID字段的使用

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 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.


3.2. Background on IPv4 ID Reassembly Issues
3.2. IPv4 ID重组问题的背景

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.


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唯一性长期以来一直存在争议。

4. Updates to the IPv4 ID Specification
4. 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.


4.1. IPv4 ID Used Only for Fragmentation
4.1. IPv4 ID仅用于分段

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].


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:


>> 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节将进一步讨论这些和其他遗留问题。

4.2. Encouraging Safe IPv4 ID Use
4.2. 鼓励安全使用IPv4 ID

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造成的,本文档对此表示反对。然而,这也是网络内数据报重复的结果,这种情况仍然可能发生。因此,本文档不会改变接收器支持重叠片段的需要。

4.3. IPv4 ID Requirements That Persist
4.3. 持续存在的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).


This document does not relax the requirement that all network devices honor the DF bit, that is:


>> IPv4 datagrams whose DF=1 MUST NOT be fragmented.


>> IPv4 datagram transit devices MUST NOT clear the DF bit.


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.


5. Impact of Proposed Changes
5. 拟议变更的影响

This section discusses the impact of the proposed changes on legacy devices, datagram generation in updated devices, middleboxes, and header compression.


5.1. Impact on Legacy Internet Devices
5.1. 对传统互联网设备的影响

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].


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.


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.


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.


5.2. Impact on Datagram Generation
5.2. 对数据报生成的影响

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].


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).


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


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.


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.


5.3. Impact on Middleboxes
5.3. 对中间商的影响

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.


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.


5.3.1. Rewriting Middleboxes
5.3.1. 重写中间盒

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.


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.




>> 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值,而与内部(到达数据报)报头上的值无关。

5.3.2. Filtering Middleboxes
5.3.2. 过滤中间盒

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节中讨论。

5.4. Impact on Header Compression
5.4. 对报头压缩的影响

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]).


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一样——效率可以提高。

5.5. Impact of Network Reordering and Loss
5.5. 网络重新排序和丢失的影响

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.


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.


5.5.1. Atomic Datagrams Experiencing Reordering or Loss
5.5.1. 正在经历重新排序或丢失的原子数据报

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.


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


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).


5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss
5.5.2. 经历重新排序或丢失的非原子数据报

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.


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.


6. Updates to Existing Standards
6. 现有标准的更新

The following sections address the specific changes to existing protocols indicated by this document.


6.1. Updates to RFC 791
6.1. RFC791的更新

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.


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.


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值。

6.2. Updates to RFC 1122
6.2. RFC1122的更新

RFC 1122 states in Section ("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值。

6.3. Updates to RFC 2003
6.3. RFC 2003的更新

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]...


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允许的。

7. Security Considerations
7. 安全考虑

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]。然而,这并不是一个安全特性。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.


[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月。

8.2. Informative References
8.2. 资料性引用

[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.


[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.


[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.


[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.


[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.


[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月。

9. Acknowledgments
9. 致谢

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


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
   Phone: +1 (310) 448-9151