https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

Return to Security-Related RFCs, Network Security, Container Security - Kubernetes Security, Cloud Security, Web Security, DevSecOps

See: 6864 on datatracker.ietf.org

The title of this RFC is “Updated Specification of the IPv4 ID Field (RFC 6864).”

RFC 6864 addresses issues related to the IPv4 identification (ID) field in the IP header. The primary purpose of the ID field is to allow fragmented packets to be reassembled by matching fragments that belong to the same datagram. In the original specification of IPv4, the ID field was used to ensure that all fragments of a packet could be properly reassembled, even if those fragments were transmitted out of order. However, this field was designed at a time when packet fragmentation was more common, and modern networks often avoid fragmentation, creating new challenges for the use of the ID field. The related RFC is RFC 791, which defines the original IPv4 protocol. https://en.wikipedia.org/wiki/IPv4 https://tools.ietf.org/html/rfc791

In modern networks, the ID field is less frequently used because fragmentation is generally avoided, either by using Path MTU Discovery or by ensuring that datagrams are small enough to be transmitted without fragmentation. As a result, the value of the ID field is often ignored or set to arbitrary values. This change in usage has created ambiguity in how the ID field should be handled in non-fragmented packets, leading to concerns about its proper use and the potential for reassembly errors in specific cases. The related RFC is RFC 1191, which discusses Path MTU Discovery. https://en.wikipedia.org/wiki/Path_MTU_Discovery https://tools.ietf.org/html/rfc1191

RFC 6864 updates the specification of the ID field by clarifying that it is only meaningful for fragmented packets. For non-fragmented packets, the ID field is not required to have a unique value, and its contents may be set to any value, including zero. This change reflects the reduced reliance on fragmentation in modern networks and reduces the unnecessary use of unique ID values for packets that do not require fragmentation. This clarification helps avoid performance issues related to generating unique ID values in high-speed networks. The related RFC is RFC 2460, which defines the IPv6 protocol, where fragmentation is handled differently. https://en.wikipedia.org/wiki/IPv6 https://tools.ietf.org/html/rfc2460

Another important clarification made by RFC 6864 is that the ID field should be unique only for fragmented packets that share the same source and destination addresses, IP protocol, and source and destination ports (if applicable). This ensures that the ID field is used properly for reassembling fragmented packets, while reducing the burden on routers and endpoints that handle non-fragmented packets. By focusing on fragmented traffic, RFC 6864 improves the efficiency of IPv4 packet processing and reduces the likelihood of reassembly errors. The related RFC is RFC 791, which originally defined the IPv4 fragmentation and reassembly processes. https://en.wikipedia.org/wiki/IPv4 https://tools.ietf.org/html/rfc791

RFC 6864 also notes that, in some cases, certain types of network devices, such as NATs or firewalls, may modify the ID field in IPv4 headers. These modifications can interfere with the reassembly of fragmented packets, leading to errors or packet loss. To mitigate this risk, RFC 6864 encourages the use of Path MTU Discovery to avoid fragmentation whenever possible, as this reduces the need for ID field modifications and improves the overall reliability of IPv4 packet transmission. The related RFC is RFC 3234, which discusses various middlebox behaviors, including the potential impact on fragmentation. https://en.wikipedia.org/wiki/Network_address_translation https://tools.ietf.org/html/rfc3234

Another key change introduced in RFC 6864 is the recommendation that the ID field should be set to zero in non-fragmented IPv4 packets that use the Don't Fragment (DF) flag. By setting the ID field to zero in these packets, network devices can more easily distinguish between packets that are subject to fragmentation and those that are not. This practice reduces the processing overhead associated with maintaining unique ID values for non-fragmented packets, which can be a significant performance improvement in high-speed networks. The related RFC is RFC 791, which specifies the DF flag in the IPv4 header. https://en.wikipedia.org/wiki/IPv4 https://tools.ietf.org/html/rfc791

The updates provided in RFC 6864 are important for high-performance networks, especially in environments where packet processing speed is critical. By reducing the reliance on unique ID values for non-fragmented packets, this RFC allows network devices to focus on processing other aspects of the packet header, improving throughput and reducing the potential for bottlenecks. These changes are particularly relevant for systems that handle a high volume of traffic, such as data centers and cloud computing environments. The related RFC is RFC 2544, which provides benchmarking methodologies for evaluating network performance. https://en.wikipedia.org/wiki/Data_center https://tools.ietf.org/html/rfc2544

The title of this RFC is “Updated Specification of the IPv4 ID Field (RFC 6864).” RFC 6864 updates the original specification of the IPv4 ID field by clarifying its role in modern networks, where fragmentation is less common. The ID field is now only required to be unique for fragmented packets, reducing the processing burden on routers and endpoints. By encouraging the use of Path MTU Discovery and recommending that the ID field be set to zero for non-fragmented packets, RFC 6864 improves the efficiency and reliability of IPv4 networking, making it more suitable for high-performance environments. These updates help ensure that IPv4 remains a robust and efficient protocol in modern networking scenarios.