Transmission of IPv6 Jumbograms as Atomic Fragments

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

Table of Contents

1. Introduction

Internet Protocol version 6 (IPv6) [RFC8200] provides a jumbogram service for transmission of IPv6 packets larger than 65,535 octets [RFC2675]. Such large packets are not eligible for fragmentation, and the current specification forbids sources from including a Fragment Header of any kind. However, some implementations may wish to include an unpredictable Identification value with each jumbogram [RFC7739]. This document therefore proposes the transmission of IPv6 jumbograms as "atomic fragments" and in the process updates [RFC2675].¶

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]. Such Fragment Headers may be inserted by the original source only and may not be modified by any intermediate IPv6 nodes on the path. Hence, an atomic fragment generated by the original source will remain as an atomic fragment along the entire path up to and including the final destination. The original source should therefore be permitted to include an atomic fragment Fragment Header in the jumbograms it produces. The following section recommends updates to [RFC2675] to permit the transmission of IPv6 jumbograms as atomic fragments.¶

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

3. Implementation Status

TBD.¶

4. IANA Considerations

This document has no IANA considerations.¶

5. Security Considerations

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

6. Acknowledgements

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

.¶

Author's Address