[要約] RFC 6864は、IPv4のIDフィールドの仕様を更新するためのものであり、要約すると以下のようになります。1. IPv4のIDフィールドの仕様を改善し、セキュリティとパフォーマンスを向上させる。 2. パケットの識別とフラグメントの再構築を効率的に行うための新しいアルゴリズムを提案する。 3. IPv4ネットワークの信頼性と効率性を向上させるための標準化を目指す。
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に制限されます。個々の接続は通常この速度を超えるため、既存のシステムが現在の仕様に違反していることは明らかです。このドキュメントでは、RFC 791、1122、および2003のIPv4 IDフィールドの仕様を更新して、現在の慣例をより厳密に反映し、IPv6とより厳密に一致させることで、フィールドの値がデータグラムが実際にフラグメント化される場合にのみ定義されるようにします。また、これらの変更がデータグラムの使用方法に与える影響についても説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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値が必要です。これは、通常2分と解釈され、推奨される再構成タイムアウト[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の一意性は、一般的に高速デバイスによって侵害されます。厳密に実施された場合、2つのIPエンドポイント間の単一プロトコルの速度が1500バイトの標準MTUの6.4 Mbpsに制限されます（[RFC4963]で提示されている分析を使用して、2分のMDLを想定）。単一の接続がこれらの速度をはるかに超えて動作することは一般的です。これは、指定されたIPv4 IDの一意性がすでに問題であることを強く示しています。さらに、一部のソースは長年にわたって不変のIPv4 IDを生成してきました（たとえば、携帯電話）。その結果、RObust Header Compression（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
このドキュメントでは、1つ以上のインデントされた行の前にある文字 ">>"は、上記のキーワードを使用した要件を示しています。この規則は、レビュー担当者がこのドキュメントの明示的な要件をすばやく特定または見つけるのに役立ちます。
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では、フラグメントは基本ヘッダーの4つのフィールドを使用して示されます：識別（ID）、フラグメントオフセット、 "Do n't Fragment"（DF）フラグ、および "More Fragments"（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、フラグメントオフセット、およびIPv4 [RFC2460]の対応するものと同様のM（より多くのフラグメント）フラグを含む拡張ヘッダーで示されます。
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のように動作します）。 IPv6フラグメントヘッダーは、データグラムがフラグメント化されている場合、またはソースが「パケットが大きすぎる」ICMPv6エラーメッセージを受信した場合にのみ存在します。これは、パスが必要な最小1280バイトのIPv6 MTUをサポートできず、変換の対象となることを示します[ RFC2460] [RFC4443]。後者のケースは、IPv4への変換後の後続のフラグメンテーションをサポートするためにIPv4宛先に送信されるIPv6データグラムにのみ関連します。
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.
これら2つのケースを除いて、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フィールドは、一部の診断ツールで、ネットワークパスに沿ったさまざまな場所で測定されたデータグラムを関連付けるために使用されます。フラグメント化されていないデータグラムにはIDがないため、これはIPv6ではすでに不十分であり、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フィールドは、2つのIPエンドポイント間の特定のプロトコルのすべてのTCP接続の集約が約286 Mbpsに制限されることを意味します。 1500バイトのより一般的なMTUでは、この速度は6.4 Mbpsに低下します[RFC791] [RFC1122] [RFC4963]。現在、この制限は、フラグメンテーションが有効か禁止か、データグラムがフラグメント化されているかどうかに関係なく、2つの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.
典型的なMTUであっても、IPv6は18.7 Tbpsに対応しており、32ビットのIDフィールドが大きいため（およびIPv6の次のヘッダーフィールドと同等）、2つのIPエンドポイント間のフラグメンテーションがすべてのプロトコルにわたって集約されます。 IPv4プロトコルフィールド。差別化フラグメントでは考慮されません）。フラグメンテーションを使用しない場合、フィールドは存在せず、その場合、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の有線リンクが数年間デフォルトになっています。多くのエンドツーエンドのトランスポートパスは輻輳が制限されていますが、これらのデバイスは、LANを介した100 Mbps以上のアプリケーションレイヤースループット（ディスク間ファイル転送レートなど）と、商用オフザザによる多数のスループットデモを簡単に実現します。広域パス上のシェルフ（COTS）システムは、10年以上にわたってこれらの速度を示してきました。これは、IPv4 IDの一意性が長い間問題になっていることを強く示唆しています。
This document updates the specification of the IPv4 ID field in three distinct ways, as discussed in subsequent subsections:
このドキュメントでは、後続のサブセクションで説明するように、3つの異なる方法で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:
2種類のデータグラムがあり、以下で定義され、次の説明で使用されます。
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:
この同じ定義は、次のように、一般的な論理演算子（等しい==、論理「and」は&&、論理 'or'は||、より大きい>、および括弧関数は通常使用されます）を使用して、擬似コードで表すことができます。 ：
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) The test for non-atomic datagrams is the logical negative of the test for atomic datagrams; thus, all possibilities are considered.
o非アトミックデータグラム：（DF == 0）||（MF == 1）||（frag_offset> 0）非アトミックデータグラムのテストは、アトミックデータグラムのテストの論理否定です。したがって、すべての可能性が考慮されます。
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フィールドは、断片化と再構成以外の目的で使用してはなりません（MUST NOT）。
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フィールドを任意の値に設定できます（MAY）。
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フィールドは、非アトミックデータグラム（すでに断片化されているデータグラムか、断片化が許可されたままのデータグラム）に対してのみ意味があります。アトミックデータグラムは、セクション4で説明されているように、DF、MF、およびフラグメンテーションオフセットフィールドによって検出されます。したがって、このドキュメントでは、区別されるように、0を含むIPv4 ID値を予約していません。
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の繰り返しを回避することが困難になる可能性があります。 RFC 1122は、この動作は「役に立たない」と結論しています。このドキュメントでは、その結論を次のように形式化しています。
>> 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.
RFC 1122は、フラグメントが重複する可能性があることも示唆しています。このようなオーバーラップは、連続した再送信が異なる方法でフラグメント化されているが、同じ再構成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.
>>非アトミックデータグラムを送信するソースは、特定のソースアドレス/宛先アドレス/プロトコルタプルの1つの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ビットをクリアしてはなりません（MUST NOT）。
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値をすでに生成しており、現在の推定インターネットMDLは2分未満です。彼らは、エンドツーエンドパス上の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].
既存のデバイスは、特に一部の携帯電話など、ほぼ10年間、アトミックデータグラムの不変IDを生成することが知られています。このような定数ID値は、ROHC [RFC5225]の最適化としてサポートされる理由です。これについては、5.4項で詳しく説明します。定数（ゼロ）IDを持つIPv4データグラムの生成も、IP / ICMP変換標準[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.
現在の多くのデバイスは、IPv4 Do n't Fragment（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一意性要件に準拠するために、その出力をレート制限する必要があります。このようなソースには、特に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).
>>上位層プロトコルは、たとえば、再構成エラーを検出できるチェックサムまたはハッシュを使用して、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 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:
サブネットワークカプセル化および適応層（SEAL）[RFC5320]、IPsec [RFC4301]、またはストリーム制御伝送プロトコル（SCTP）[RFC4960]でサポートされているように、追加の整合性チェックをトンネルを使用して採用できます。このようなチェックにより、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を再利用できます（MAY）。
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]。これは、IPv4 Residual Deployment（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 / ASM /リライタは、フラグメンテーションに関して特に困難な状況をもたらします。再組み立てタプルの一部を両方向で上書きするため、タプルの一意性が失われ、再組み立ての危険が生じる可能性があります。 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 / ASM /リライタを介したフラグメントの送信に関するこのような問題はすでに知られています。変換は通常、トランスポートポート番号に基づいています。トランスポートポート番号はとにかく最初のフラグメントにのみ存在します[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].
多くのソースからのデータグラムを単一の発信ソースアドレスにマージするとIPv4 IDの衝突が発生する可能性があるため、NAT / ASMはすでにパブリック側でデータグラムを送信するときに特別な注意を払う必要があることに注意してください。この状況はこのドキュメントの前にあり、影響を受けません。これは、いわゆる「キャリアグレード」の大規模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.
トンネルの入口は最も外側のヘッダーのソースとして機能しますが、トンネルは内側のヘッダーのルーターとして機能します（つまり、データグラムはトンネルの入口に到着します）。内部IPv6 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 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]).
ヘッダー圧縮アルゴリズムは、IPv4 IDが順次データグラム間で変化するさまざまな方法にすでに対応しています[RFC1144] [RFC2508] [RFC3545] [RFC5225]。このようなアルゴリズムは現在、IPv4 IDがエンドツーエンドで保持されることを前提としています。一部のアルゴリズムは、IDが変更されないという仮定をすでに許可しています（たとえば、ROHC [RFC5225]）。他のアルゴリズムは、ゼロデルタを介して変更されないIDを含みます（たとえば、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を使用すると、圧縮の効率が低下する可能性があります。このような変更されないIDは、さまざまなRFCで説明されています（たとえば、[RFC1144]の脚注21およびcRTP [RFC2508]）。 ROHCやECRTPのように、圧縮によってIPv4 IDが変化しないと想定できる場合は、効率を高めることができます。
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.
ネットワークの並べ替えと損失に対する耐性は、インターネットアーキテクチャの重要な機能です。現在のほとんどの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 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が無視されると、並べ替えまたは損失により、異なるデータグラムのフラグメントがインターリーブされ、誤って再構成されて破棄される可能性があります。このドキュメントで許可されているように、アトミックデータグラムでID値を再利用すると、そのような場合にデータグラムの損失が増える可能性があります。アトミックデータグラム（一部の携帯電話）に一定のIDを使用する既知のデバイスがあり、DF = 1を無視する既知のデバイスがありますが、対応する高レベルの損失は報告されていません。そのようなレポートの欠如は、そのような場合の並べ替えの欠如または損失、または結果として生じる損失への許容のいずれかを示します。このような問題が報告された場合、非準拠デバイス（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.
その場合、送信プロトコルモジュールは識別子のテーブルを保持する必要があるようです。インターネットの最後の最大データグラムライフタイムで通信した宛先ごとに1つのエントリです。
However, since the Identifier field allows 65,536 different values, some host may be able to simply use unique identifiers independent of destination.
ただし、Identifierフィールドでは65,536の異なる値を使用できるため、一部のホストは宛先に関係なく一意の識別子を簡単に使用できる場合があります。
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.
以前のデータグラムの同一のコピーを送信するとき、ホストはオプションでコピー内の同じ識別フィールドを保持してもよい（MAY）。
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.
ディスカッション：一部のインターネットプロトコルの専門家は、ホストが以前のデータグラムの同一のコピーを送信する場合、新しいコピーには元のデータグラムと同じ識別値を含める必要があると主張しています。推奨される利点は2つあります。（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]...
これら3つのフィールドは、[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は以前は1つの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。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、編、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、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。、「NATされたホストを数える技術」、インターネット測定会議、インターネット測定に関する第2回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、「Analysis of Solution Candidates to Be a Host Identifier in Shared Address Deployments」、Work in Progress、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.、Muramikami、T。、およびO. Troan、「IPv6サービスネットワーク全体でのIPv4の残りの展開（第4）ISP-NATはオプションになりました」、進行中の作業、3月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.
[Pe11] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common requirements for Carrier Grade NATs（CGNs）"、Work in Progress、2012年12月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「Compressing TCP / IP Headers for Low-Speed Serial Links」、RFC 1144、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、「Compressing IP / UDP / RTP Headers for Low-Speed Serial Links」、RFC 2508、1999年2月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional 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 3545、 2003年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、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 2004年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年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、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963] Heffner、J.、Matis、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、「RObust Header Compression Version 2（ROHCv2）：Profiles for RTP、UDP、IP、ESP and UDP-Lite」、RFC 5225、2008年4月。
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320] Templin、F。、編、「The Subnetwork Encapsulation and Adaptation Layer（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 6145、2011年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。、編、「Simplified Multicast Forwarding」、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 Farinacci、Fred Templin、およびインターネットエリアワーキンググループに参加しているメンバーによる著者との数多くの議論に触発されました。詳細なフィードバックは、Gorry Fairhurst、Brian Haberman、Ted Hardie、Mike Heard、Erik Nordmark、Carlos Pignataro、Dan Wingから提供されました。このドキュメントは、PSCのMatt Mathisが共同執筆したIndependent Submissionsストリームドキュメントとして作成されました。彼の貢献は高く評価されています。
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 Admiralty Way Marina del Rey、CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151
EMail: touch@isi.edu