RFC 6864

Updated Specification of the IPv4 ID Field

📅 published February 2013, from ietf

RFC 6864: Updated Specification of the IPv4 ID Field ✨

part 1 of 4 💖 more to come!

Okay bestie, so this one is RFC 6864, called Updated Specification of the IPv4 ID Field 🎀. J. Touch from USC/ISI wrote it, and it was published in February 2013. It's a Standards Track document with ISSN 2070-1721. It updates RFCs 791, 1122, and 2003 💅

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

Abstract

Okay so the IPv4 ID field is what makes fragmentation and reassembly work 🧩. Right now the spec says it is required to be unique within the maximum lifetime for every datagram with a given source address/destination address/protocol tuple. If you actually enforced that, every connection would be capped at 6.4 Mbps for typical datagram sizes 😭. Individual connections go way faster than that, so it's super clear that real systems already break the current spec.

This document updates the IPv4 ID field spec in RFCs 791, 1122, and 2003 so it matches what people actually do 🦋. It also lines the field up more closely with IPv6, so the value only gets defined when a datagram is actually fragmented. There's also a section on how these changes affect the way datagrams get used 💜.

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). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6864.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🔥.

1. Introduction ✨

In IPv4, the Identification (ID) field is a 16-bit value that has to be unique for every datagram from a given source address, destination address, and protocol 🎀. It must not repeat within the maximum datagram lifetime (MDL) [RFC791] [RFC1122]. Per the current spec, all datagrams between a source and destination for a given protocol need unique IPv4 ID values over a full MDL period. That's typically read as two minutes, and it's tied to the recommended reassembly timeout [RFC1122]. The uniqueness rule applies to every datagram, no matter what the fragmentation settings are 💅.

Here's the thing: high-speed devices break this uniqueness all the time 🏎️. If you enforced it strictly, one protocol between two IP endpoints would be limited to 6.4 Mbps for typical MTUs of 1500 bytes (assuming a 2-minute MDL, using the analysis in [RFC4963]). A single connection often runs way faster than that, which basically means the uniqueness rule for IPv4 ID is already moot 🙈. And some sources have been sending non-varying IPv4 IDs for years (cellphones, for example). That's why RObust Header Compression (ROHC) [RFC5225] ended up supporting it 🧚.

So this document updates the IPv4 ID field spec to match current practice better 💖. It also brings in the things that were considered when the similar field in IPv6 was specified 🌈.

2. Conventions Used in This Document

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

In this document, the characters >> at the start of one or more indented lines mean a requirement is using one of those key words above. It's a little signpost so reviewers can spot this document's explicit requirements fast 👀.

3. The IPv4 ID Field

IP supports datagram fragmentation, where big datagrams get split into smaller pieces so they can cross links with limited maximum transmission units (MTUs) 🍓. IPv4 and IPv6 mark fragments in different ways:

  • In IPv4, fragments are marked with four fields in the basic header: Identification (ID), Fragment Offset, a "Don't Fragment" (DF) flag, and a "More Fragments" (MF) flag [RFC791].
  • In IPv6, fragments are marked in an extension header that has an ID, Fragment Offset, and an M (more fragments) flag. These are similar to their IPv4 counterparts [RFC2460].

IPv6 fragmentation is different from IPv4 in a few important ways 🫶. In IPv6, fragmentation only happens at the source, so you don't need a DF bit to stop downstream devices from starting fragmentation (IPv6 always acts as if DF=1). The IPv6 fragment header only shows up when a datagram has been fragmented, or when the source gets a "packet too big" ICMPv6 error message saying the path can't support the required minimum 1280-byte IPv6 MTU, so the datagram is subject to translation [RFC2460] [RFC4443]. That second case only matters for IPv6 datagrams going to IPv4 destinations, so they can get fragmented after translating to IPv4 🦋.

Apart from those two cases, the ID field isn't present on non-fragmented datagrams. So it only means something for datagrams that are already fragmented, or that are meant to be fragmented as part of IPv4 translation 🧩. Last thing: the IPv6 ID field is 32 bits and must be unique per source/destination address pair. The IPv4 one is only 16 bits and must be unique per source address/destination address/protocol tuple 🔥.

This document is mostly about IPv4 ID field issues, since in IPv6 the field is bigger and only shows up in fragments 💜.

3.1. Uses of the IPv4 ID Field

The IPv4 ID field was originally meant for fragmentation and reassembly [RFC791] ✨. Within a given source address, destination address, and protocol, fragments of an original datagram get matched by their IPv4 ID. So IDs have to be unique within the source address/destination address/protocol tuple whenever fragmentation is possible (e.g., DF=0) or has already happened (e.g., frag_offset>0 or MF=1) 🎀.

People have come up with other uses for the IPv4 ID field too 🌸. Someone proposed using it to detect and remove duplicate datagrams, like at congested routers (noted in Section 3.2.1.5 of [RFC1122]) or in network accelerators 🚀. It's also been suggested for end hosts, to cut down on the impact of duplication on higher-layer protocols (like extra processing in TCP, or the need for application-layer duplicate suppression in UDP). This is talked about more in Section 5.1 💅.

Some diagnostic tools use the IPv4 ID field to match up datagrams measured at different spots along a network path 🔍. That's already not enough in IPv6, because unfragmented datagrams don't have an ID at all. So those tools are already being updated to stop relying on the ID field. This is also covered further in Section 5.1 🙈.

The ID definitely needs to be unique (within the MDL, and within the source address/destination address/protocol tuple) to support fragmentation and reassembly. But not every datagram gets fragmented or is allowed to be. So this document deprecates the non-fragmentation uses, and lets the ID repeat (within the MDL, and within the source address/destination address/protocol tuple) in those cases 👑.

3.2. Background on IPv4 ID Reassembly Issues 🎀

okay so this bit is a recap of the IPv4 fragment reassembly drama in high-speed environments that was already raised in [RFC4963] 🫶. Readers are encouraged to consult RFC 4963 for a more detailed discussion of these issues, and honestly it's worth the read bestie 📚.

With the maximum IPv4 datagram size of 64 KB, a 16-bit ID field that does not repeat within 120 seconds means 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. It's giving no escape 🙈.

IPv6, even at typical MTUs, is capable of 18.7 Tbps with fragmentation between two IP endpoints as an aggregate across all protocols ✨. That's because of the larger 32-bit ID field, and also because 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 🦋.

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, so the whole timing thing is kinda wild 😳.

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

4. Updates to the IPv4 ID Specification ✨

This document updates the specification of the IPv4 ID field in three distinct ways, and we'll unpack each one in the subsections 🌈:

  • Using the IPv4 ID field only for fragmentation
  • Encouraging safe operation when the IPv4 ID field is used
  • Avoiding a performance impact when the IPv4 ID field is used

There are two kinds of datagrams, which are defined below and used in the following discussion 🍓:

  • Atomic datagrams are datagrams not yet fragmented and for which further fragmentation has been inhibited.
  • Non-atomic datagrams are datagrams either that already have been fragmented or for which fragmentation remains possible.

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 🧠:

  • Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0)
  • 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 🫧.

4.1. IPv4 ID Used Only for Fragmentation 🔥

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, and the rule is hard and fast:

The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly.

Datagram de-duplication can still be accomplished using hash-based duplicate detection for cases where the ID field is absent (IPv6 unfragmented datagrams). That can also be applied to IPv4 atomic datagrams without utilizing the ID field [RFC6621] ✨.

In atomic datagrams, the IPv4 ID field has no meaning, so it can be set to an arbitrary value. In other words, the requirement for non-repeating IDs within the source address/destination address/protocol tuple is no longer required for atomic datagrams 🦋:

Originating sources MAY set the IPv4 ID field of atomic datagrams to any value.

Second, all network nodes (whether at intermediate routers, destination hosts, or other devices such as NATs and other address-sharing mechanisms, firewalls, or 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.

The IPv4 ID field is thus meaningful only for non-atomic datagrams, meaning 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 💖.

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

4.2. Encouraging Safe IPv4 ID Use 🫶

This document also changes the specification of the IPv4 ID field to encourage its safe use 🌈.

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 💅:

The IPv4 ID of non-atomic datagrams MUST NOT be reused when sending a copy of an earlier non-atomic datagram.

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

4.3. IPv4 ID Requirements That Persist 💜

This document does not relax the IPv4 ID field uniqueness requirements of [RFC791] for non-atomic datagrams. That is 🔒:

Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID values within one MDL for a given source address/destination address/protocol tuple.

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 🔮

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 🕰️

Legacy uses of the IPv4 ID field consist of fragment generation, fragment reassembly, duplicate datagram detection, and "other" uses 🧃.

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

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

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 ✨

okay so this is basically the recap of everything we changed for the IPv4 ID field 🎀 Because atomic datagrams can use any IPv4 ID value, the ID field stops being a performance problem for them 🦋 Non-atomic datagrams still have the performance hit though, so:

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

Also, the MDL has no strict definition, so reassembly hazards show up no matter what the IPv4 ID reuse interval or the reassembly timeout is 😭 So:

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

Extra integrity checks can come from tunnels, like the Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], IPsec [RFC4301], or the Stream Control Transmission Protocol (SCTP) [RFC4960]. These checks can avoid the reassembly hazards that happen with UDP and TCP checksums [RFC4963] or with partial checksums as in UDP-Lite [RFC3828]. Since those integrity checks can dodge the impact of reassembly errors:

  • Sources of non-atomic IPv4 datagrams using strong integrity checks MAY reuse the ID within intervals that are smaller than typical MDL values. 🌸

Lowkey though, frequent reuse can still lead to corrupted reassembly and poor throughput. It just wouldn't push those reassembly errors up to the higher-layer protocols 🙈

5.3. Impact on Middleboxes 🧚

Middleboxes are things like 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 without being routers, like accelerators and firewalls 👑

The changes in this document may not be implemented by middleboxes. Still, these changes are more likely to make current middlebox behavior compliant than to mess with the service those devices provide 💜

5.3.1. Rewriting Middleboxes 🍓

NATs and NAPTs rewrite IP fields, and tunnel ingresses (using IPv4 encapsulation) copy and modify some IPv4 fields. So they're all considered datagram sources, and so is any device that rewrites any part of the source address/destination address/protocol/ID tuple for any datagrams [RFC3022]. The same goes for other ASMs, including IPv4 Residual Deployment (4rd) [De11], IVI [RFC6219], and others in the "A+P" (address plus port) family [Bo11]. It's equally true for any other datagram-rewriting mechanism 💅 That means they get all the requirements of any datagram source, like we said before.

NATs/ASMs/rewriters are in a seriously tricky spot with fragmentation 😬 They overwrite parts of the reassembly tuple in both directions, so they can destroy tuple uniqueness and cause a reassembly hazard. Whenever the IPv4 source address, destination address, or protocol fields get modified, a NAT/ASM/rewriter needs to make sure the ID field is generated properly, not just copied from the incoming datagram ✨

So, 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. 🔥

This compliance means the IPv4 ID field of non-atomic datagrams translated at a NAT/ASM/rewriter has to follow the uniqueness requirements of any IPv4 datagram source. Unfortunately, translated fragments already break that rule, since they repeat an IPv4 ID within the MDL for a given source address/destination address/protocol tuple 😭

Problems with sending fragments through NATs/ASMs/rewriters are already known. Translation is usually based on the transport port number, which is only present in the first fragment anyway [RFC3022]. This document underlines that reassembly (and possibly subsequent fragmentation) isn't just required for translation, it can also help avoid IPv4 ID uniqueness issues 🦋

Also, NATs/ASMs already need to be extra careful when sending datagrams on their public side, because merging datagrams from lots of sources onto one outgoing source address can cause IPv4 ID collisions. That situation was already there before this document and isn't changed by it. It gets worse in large-scale, so-called "carrier grade" NATs [Pe11] 💀

Tunnel ingresses act as sources for the outermost header, but tunnels act as routers for the inner headers (i.e., the datagram as it arrives 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 🌈

5.3.2. Filtering Middleboxes 🫧

Middleboxes also include devices that filter datagrams, like network accelerators and firewalls. Some of these reportedly do datagram de-duplication that relies on IP ID uniqueness to spot duplicates, which we already talked about in Section 5.1 🧐

5.4. Impact on Header Compression 🎀

Header compression algorithms already handle the different ways the IPv4 ID can change between sequential datagrams [RFC1144] [RFC2508] [RFC3545] [RFC5225]. These algorithms currently assume the IPv4 ID is preserved end-to-end. Some of them already allow the assumption that the ID doesn't change (e.g., ROHC [RFC5225]), while others handle non-changing IDs through zero deltas (e.g., Enhanced Compressed RTP (ECRTP) [RFC3545]) ✨

When compression assumes a changing ID by default, a non-changing ID can make compression less efficient. Non-changing IDs have been described in several RFCs (e.g., footnote 21 of [RFC1144] and cRTP [RFC2508]). When compression can assume a non-changing IPv4 ID, like with ROHC and ECRTP, efficiency can go up 📈

5.5. Impact of Network Reordering and Loss 🌊

Being tolerant to network reordering and loss is a key feature of the Internet architecture 💖 Most current IP networks avoid these things on purpose, but reordering and loss can and do happen anyway. Datagrams are already expected to get reordered or lost, and recovery from those errors (where it's supported) already happens at the transport or higher protocol layers 🙌

Reordering usually comes from routing transients or flows being split across multiple paths. Loss is usually linked to path congestion or link failure (partial or complete). The impact of these events is different for atomic and non-atomic datagrams, and we'll go through it below. Basically, the recommendations here make the Internet more robust to reordering and loss by emphasizing ID uniqueness for non-atomic datagrams, and by spelling out more clearly what these requirements mean for both endpoints and datagram transit devices 🫶

5.5.1. Atomic Datagrams Experiencing Reordering or Loss 🍒

Reusing ID values doesn't affect atomic datagrams when the DF bit is correctly respected, because order restoration doesn't 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 get interleaved, and then they get incorrectly reassembled and discarded. Reusing ID values in atomic datagrams, as this document allows, can lead to higher datagram loss in those cases. Situations like this can already 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 haven't been reported. Not hearing about those reports means either there isn't much reordering or loss in those cases, or the losses are tolerated 🤷‍♀️ If issues like this do get reported, it would be more productive to go after the non-compliant devices (the ones that ignore DF=1), because it's impractical to define Internet specifications that tolerate devices ignoring those specifications 🙅‍♀️ That's why this document stresses honoring DF=1, and why datagram transit devices need to keep the DF bit as received (i.e., rather than clearing it) 💅

5.5.2. Non-atomic Datagrams Experiencing Reordering or Loss 🌷

Non-atomic datagrams rely on the uniqueness of the ID value to tolerate reordering of fragments, especially when fragments of different datagrams get interleaved because of that reordering. Fragment loss can cause reassembly of fragments from different origin datagrams, which is exactly why ID reuse in non-atomic datagrams is based on datagram (fragment) maximum lifetime, not just expected reordering interleaving 🕰️

This document doesn't change the uniqueness requirements for IDs in non-atomic datagrams, so it doesn't change how they tolerate reordering or loss. What it does do is emphasize the need for ID uniqueness across all datagram sources, including rewriting middleboxes. It also stresses rate-limiting sources to keep IDs unique, not reusing the ID for retransmitted datagrams, and using higher-layer integrity checks to prevent reassembly errors. All of that adds up to a higher tolerance to reordering or loss events 🌟

6. Updates to Existing Standards 📚

Next up are the specific changes this document makes to existing protocols 👀

6.1. Updates to RFC 791 🦋

RFC 791 says:

   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.

Then it goes on to say:

   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 like so:

  • IPv4 ID uniqueness applies to only non-atomic datagrams. 🎯
  • Retransmitted non-atomic IPv4 datagrams are no longer permitted to reuse the ID value. 🚫

6.2. Updates to RFC 1122 💅

okay so RFC 1122 has this bit in Section 3.2.1.5 (the "Identification: RFC 791 Section 3.2" part) that says:

   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.

and this document changes it in two ways 🫶

  • the IPv4 ID field is no longer allowed to be used for duplicate detection. this covers both atomic and non-atomic datagrams 🙅‍♀️
  • retransmitted non-atomic IPv4 datagrams are no longer allowed to reuse the ID value ✨

6.3. Updates to RFC 2003 🎀

this one is about IPv4-in-IPv4 tunnels and how they make IPv4 ID values for the outer header [RFC2003]. the update only applies the same way it applies to any other IPv4 datagram source. RFC 2003 says the following, where [10] is RFC 791:

   Identification, Flags, Fragment Offset

      These three fields are set as specified in [10]...

and this document changes RFC 2003 like so:

  • the IPv4 ID field is set as permitted by RFC 6864. ✨

7. Security Considerations 🔥

okay this section is SERIOUS bestie 💀

when the IPv4 ID gets ignored on receipt (like for atomic datagrams), its value becomes unconstrained. that means the field can way more easily be used as a covert channel 👀 for some atomic datagrams it's now possible, and maybe even desirable, to rewrite the IPv4 ID field so it can't be used that way. rewriting is prohibited for datagrams protected by the IPsec Authentication Header (AH), although we do not recommend using AH to get this result [RFC4302].

the IPv4 ID also adds way less entropy to the header of a datagram now 🥀 that entropy could be used as input to cryptographic algorithms or pseudorandom generators, but IDs were never guaranteed to have enough entropy for that anyway. the IPv4 ID used to be unique (for a given source/address pair and protocol field) within one MDL. this requirement was never enforced, though, and it's clearly usually ignored. the IPv4 ID of atomic datagrams is not required to be unique, so it contributes no entropy to the header at all.

the deprecation of IPv4 ID 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 though, so don't get it twisted 🙈

8. References 📚

8.1. Normative References

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

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References 🌸

   [Be02]     Bellovin, S., "A Technique for Counting NATted Hosts",
              Internet Measurement Conference, Proceedings of the 2nd
              ACM SIGCOMM Workshop on Internet Measurement,
              November 2002.

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

   [RFC2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              February 1999.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

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

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

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

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
              Errors at High Data Rates", RFC 4963, July 2007.

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

   [RFC5320]  Templin, F., Ed., "The Subnetwork Encapsulation and
              Adaptation Layer (SEAL)", RFC 5320, February 2010.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

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

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, May 2012.

9. Acknowledgments 🫶

this doc was inspired by a bunch of chats with the author from Jari Arkko, Lars Eggert, Dino Farinacci, and Fred Templin, plus folks in the Internet Area Working Group 💜 detailed feedback came from Gorry Fairhurst, Brian Haberman, Ted Hardie, Mike Heard, Erik Nordmark, Carlos Pignataro, and Dan Wing. it started life as an Independent Submissions stream document co-authored by Matt Mathis, PSC, and his contributions are seriously appreciated 🙌

this document was initially prepared using 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.

   Phone: +1 (310) 448-9151
   EMail: touch@isi.edu
📦 where this page comes from