



Network                                                     Shaofu. Peng
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                        14 November 2025
Expires: 18 May 2026


                       Fragment Header for PREOF
                     draft-peng-detnet-fh-preof-00

Abstract

   This document re-use IPv6 Fragment Header to support DetNet Packet
   Replication, Elimination, and Ordering Functions (PREOF).

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 18 May 2026.

Copyright Notice

   Copyright (c) 2025 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.







Peng                       Expires 18 May 2026                  [Page 1]

Internet-Draft                    FH-ex                    November 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Fragment Header Extensions  . . . . . . . . . . . . . . . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   DetNet architecture [RFC8655] defined service protection that aims to
   mitigate or eliminate packet loss due to equipment failures,
   including random media and/or memory faults.  These types of packet
   loss can be greatly reduced by spreading the data over multiple
   disjoint forwarding paths.  Service protection includes three
   functions: Packet Replication Function (PRF), Packet Elimination
   Function (PEF), and Packet Ordering Function (POF).  These functions
   are collectively referred to as PREOF.  In general, the use of PREOF
   require sequencing information to be included in the packets of a
   DetNet compound flow.

   The current IPv6 specification lacks support for sequence number
   information and relies on other methods, such as inserting MPLS
   labels and associated control word in IPv6 encapsulation, as defined
   in [RFC9566], which is high cost and requires the IPv6 data plane to
   support additional logic beyond pure IPv6 forwarding.

   [RFC8200] defines Fragment Header (FH), which can be used by IPv6
   sources to fragment packets when their size exceeds the MTU of the
   transmission path.  The identification field of FH is used to
   identifying multiple fragments belonging to the same original large
   packet.  That is, fragment packets belonging to the same original
   packet must have the same Identification and flow identifiers (such
   as IP 5-tuple).  If there are different original packets that need to
   be fragmented between the same source and destination, their
   identification must be different.

   This document re-use the existing Identification field of FH to carry
   sequence number information, without any new defined functions to the
   IPv6 data plane, as a low cost encapsulation method to support DetNet
   PREOF.







Peng                       Expires 18 May 2026                  [Page 2]

Internet-Draft                    FH-ex                    November 2025


1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Fragment Header Extensions

   As defined in [RFC8200], Fragment Header has the following format:


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Identification                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                  Figure 1

   Fragment Offset indicates the offset of the starting position of a
   fragment relative to the the original fragmented packet.  For
   example, the offset of the first fragment is 0, the offset of the
   second fragment is the length of the first fragment, and so on.

   Flag M indicates whether it is the last fragment of the original
   packet.  If M =0, it is the last fragment; Otherwise, not.

   Identification field is used to identify the original package.

   This document redefines the Identification field of FH: it is not
   only used to identify the original packet, but also to represent the
   sequence number of the original packet of the same flow.  The flow
   identifier may use IP 5-tuple or 6-tuple.

   The above new definition make no modifactions to the existing
   fragment logic, but just impose a constraint on the assignment value
   of the Identification, i.e., the Identification field MUST be
   incremented by one for each new App-flow packet sent under the
   context of that flow.

   For data packets that need to be re-ordered, such as packets
   forwarded along PW (pseudo-wire) or DetNet PREOF paths, FH can be
   specified to carry the sequence number, by signaling negotiation or
   configuration, but that is out the scope of this document.




Peng                       Expires 18 May 2026                  [Page 3]

Internet-Draft                    FH-ex                    November 2025


   For any flow, the Identification of the first data packet sent by the
   source must be set to 1, and increased by 1 for each subsequent
   packet.  Here, the mentioned packet is the original packet before
   fragment.

   For a given original packet, if it is not fragmented, the Fragment
   Offset and flag M are both set to 0, to indicate that the packet is
   an independent complete packet.  This setting is typical in DetNet,
   where fragmentation should be avoided as suggested in [RFC8939].

   For a given original packet, if it is fragmented, the Fragment
   Offset, flag M, and Identification of each fragment packet is set
   according to the [RFC8200] . Note that fragments don't include the
   transport headers, and may affect the identification of DetNet flow,
   such as being mistaken for low priority flows.  However, EDP
   (Enhanced DetNet Data Plane) generally contains additional metadata
   in the IPv6 header for deterministic forwarding, without relying on
   decapsulate the transport header.

   If an IPv6 node implements packets replication or elimination
   function, it may uniformly determine whether two packets of the same
   flow are duplicated based on whether their Identification, Fragment
   Offset and flag M parameters are the same, regardless of whether they
   are original packet or fragment packet.  The original packet may
   indeed be treated as a special fragment packet.

   Eliminating redundant packets and retaining only one copy will make
   the subsequent reassembly process simpler.  However, even without
   implementing elimination, the fragment reassembly process defined in
   [RFC8200] can be re-used to filter out duplicate packets.

3.  IANA Considerations

   There are no IANA requirements in this document.

4.  Security Considerations

   There are no new DetNet-related security considerations in this
   document, please refer to [RFC8939] for basic security considerations
   in DetNet IP data plane.

5.  Acknowledgements

   TBD.

6.  Normative References





Peng                       Expires 18 May 2026                  [Page 4]

Internet-Draft                    FH-ex                    November 2025


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
              <https://www.rfc-editor.org/info/rfc8939>.

   [RFC9566]  Varga, B., Farkas, J., and A. Malis, "Deterministic
              Networking (DetNet) Packet Replication, Elimination, and
              Ordering Functions (PREOF) via MPLS over UDP/IP",
              RFC 9566, DOI 10.17487/RFC9566, April 2024,
              <https://www.rfc-editor.org/info/rfc9566>.

Author's Address

   Shaofu Peng
   ZTE Corporation
   China
   Email: peng.shaofu@zte.com.cn















Peng                       Expires 18 May 2026                  [Page 5]
