IPv6 Packet Identification

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 May 2022.¶

Copyright Notice

Copyright (c) 2021 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Unlike Internet Protocol, version 4 (IPv4) [RFC0791], Internet Protocol, version 6 (IPv6) [RFC8200] does not include an Identification field in the basic packet header. Instead, IPv6 includes a 32-bit Identification field in a Fragment Header extension since the architecture assumed that the sole purpose for an Identification is to support the fragmentation and reassembly process. This document asserts that per-packet Identifications may be useful for other purposes, e.g., to allow recipients to detect spurious packets that may have been injected into the network by an attacker. But, rather than defining a new extension header, this document recommends employing the existing Fragment Header for per-packet identification even if the packet itself appears as an "atomic fragment".¶

Atomic fragments are defined as "IPv6 packets that contain a Fragment Header with the Fragment Offset set to 0 and the M flag set to 0" [RFC6946]. When an IPv6 source includes a Fragment Header (i.e., either in an atomic fragment or in multiple fragments), only the source itself and not an intermediate IPv6 node on the path is permitted to alter its contents. This is mandated in the base IPv6 specification which states "unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path".¶

IPv6 sources that include a Fragment Header include an unpredictable Identification value with each packet [RFC7739]. If the IPv6 source and destination maintain a "window" of acceptable Identification values, this may allow the destination to discern packets originated by the true IPv6 source from spurious packets injected into the network by an attacker.¶

This document therefore asserts that IPv6 sources are permitted to include a Fragment Header in their packet transmissions (i.e., whether as atomic fragments or in multiple fragments) as long as they include suitable unpredictable Identification values. This includes IPv6 "jumbograms" (i.e., packets larger than 65,535 octets [RFC2675]) which can only be prepared as atomic fragments since they are not eligible for fragmentation. Since the current jumbogram specification forbids sources from including a Fragment Header of any kind, this document updates [RFC2675].¶

2. IPv6 Packet Identification

When IPv6 sources and destinations have some way of maintaining "windows" of acceptable Identification values, the destination may be able to examine received packet Identifications to determine whether they likely originated from the source. The AERO [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni] specifications discuss methods for maintaining windows of unpredictable values that may reduce attack profiles in some environments.¶

3. RFC2675 Updates

The following updates to [RFC2675] are requested:¶

• Section 3, third paragraph, change: "The Jumbo Payload option must not be used in a packet that carries a Fragment header" to: "The Jumbo Payload option must not be used in a packet that carries a non-atomic Fragment header [RFC6946]".¶
• Section 3, in the list of errors, change: "error: Jumbo Payload option present and Fragment header present" to: "error: Jumbo Payload option present and non-atomic Fragment header present".¶
• Add [RFC6946] to Informative References.¶

4. Implementation Status

TBD.¶

5. IANA Considerations

This document has no IANA considerations.¶

6. Security Considerations

Communications networking security is necessary to preserve confidentiality, integrity and availability.¶

7. Acknowledgements

This work was inspired by ongoing AERO/OMNI/DTN investigations.¶

.¶

Author's Address