Supporting IOAM in IPv6
draft-song-ippm-ioam-ipv6-support-08

IPPM                                                             H. Song
Internet-Draft                                                 Futurewei
Intended status: Standards Track                                   Z. Li
Expires: 4 February 2027                                         S. Peng
                                                     Huawei Technologies
                                                             J. Guichard
                                                               Futurewei
                                                           3 August 2026

                        Supporting IOAM in IPv6
                  draft-song-ippm-ioam-ipv6-support-08

Abstract

   IOAM pre-allocated trace option data fields can be encapsulated in
   the IPv6 Hop-by-Hop (HbH) Options header as described in RFC 9486.
   However, due to the potentially large size of the trace data and the
   location of the HbH Options header in the IPv6 packet, this scheme
   creates practical challenges for implementation, especially when
   other extension headers, such as a routing header, are also present
   and require on-path processing.  In addition to IOAM Direct Export
   (DEX), this document proposes two alternative approaches to address
   this challenge: separating the IOAM incremental trace data from the
   IOAM instruction header, or applying the segment IOAM trace data
   export scheme, depending on the network scenario and application
   requirements.  We discuss the pros and cons of each approach.

Requirements Language

   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 BCP 14 RFC 2119
   [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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

Song, et al.             Expires 4 February 2027                [Page 1]
Internet-Draft              IOAM IPv6 Support                August 2026

   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 4 February 2027.

Copyright Notice

   Copyright (c) 2026 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IOAM Trace Data Separate and Postpose . . . . . . . . . . . .   4
     2.1.  IOAM Incremental Trace Data Encapsulation . . . . . . . .   5
   3.  Segment IOAM Data Export  . . . . . . . . . . . . . . . . . .   5
     3.1.  Independent of SRv6 . . . . . . . . . . . . . . . . . . .   5
     3.2.  Export at SRv6 Node . . . . . . . . . . . . . . . . . . .   6
   4.  Direct Export Option  . . . . . . . . . . . . . . . . . . . .   7
   5.  Comparison  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   In-situ OAM (IOAM) [RFC9197] defines two trace options, the pre-
   allocated trace option and the incremental trace option, which record
   hop-by-hop data along a packet's forwarding path.  [RFC9486]
   describes a method to encapsulate IOAM pre-allocated trace option
   data fields in IPv6.  Because the trace options require per-hop
   processing, such options can only be encapsulated in the IPv6 Hop-by-
   Hop (HbH) Options header.

Song, et al.             Expires 4 February 2027                [Page 2]
Internet-Draft              IOAM IPv6 Support                August 2026

   [RFC8200] mandates that the HbH Options header, if present, must be
   the first extension header following the IPv6 header.  However, the
   IOAM trace data can be large, amounting to tens or hundreds of bytes,
   which makes it difficult or even impossible for some routers to
   access the headers that follow it.  There are practical limitations
   on how far forwarding hardware can reach into a packet.  The IOAM
   trace option cannot be applied if it makes other extension headers
   inaccessible.  Even if the other headers can be reached, the deeper
   they are, the higher the cost to access and process them, and the
   lower the forwarding performance.  Note that [RFC9486] does not
   support the incremental trace option, because it would expand the HbH
   header at each hop and push back all the headers that follow it.  The
   changing location of the later extension headers could further
   complicate the hardware implementation and degrade forwarding
   performance.

   The issue becomes more severe when SRv6 and IOAM coexist.  The
   Segment Routing Extension Header (SRH) [RFC8754] is encapsulated in a
   routing header, which follows the HbH Options header.  The SRH itself
   can be large, and it requires read and write operations at each SRv6
   segment endpoint node.  If it is deeply embedded in a packet and its
   location keeps shifting, either it is beyond the reach of the
   hardware or the forwarding performance degrades.

   We can avoid the problem by not using both at the same time, but this
   is not ideal, because IOAM is an important OAM tool and it is even
   more desirable when SRv6 introduces additional operational complexity
   into IPv6 networks.

   A second recourse is to limit IOAM to SRv6 nodes only.  That is, to
   consider SRv6 as an overlay tunnel over IPv6 and apply the IOAM pipe
   mode as discussed in [I-D.song-ippm-ioam-tunnel-mode], which only
   collects data at each SRv6 segment endpoint node.  To realize this,
   [I-D.ali-spring-ioam-srv6] describes an approach that encapsulates
   the IOAM option data fields in an SRH TLV, and [RFC9259] describes
   another approach that enables postcard-based telemetry for SRv6
   without needing IOAM option encapsulation.  In either case, the SRH
   is close to the front of the packet and its location is fixed.  While
   these approaches are useful for use cases that only need to monitor
   the segment endpoints, they fail to cover all the IPv6 nodes on the
   packet forwarding path in an IOAM domain.

Song, et al.             Expires 4 February 2027                [Page 3]
Internet-Draft              IOAM IPv6 Support                August 2026

   The proposition of this draft is as follows: if we need to apply IOAM
   on all nodes in an SRv6 network, how can we amend the approach in
   [RFC9486] or use alternative approaches to circumvent the
   aforementioned issues?  In this draft, we propose two viable
   approaches: (1) separating the IOAM trace data from the instruction
   header into a different extension header option placed after the
   routing header (if one exists), and (2) applying the segment IOAM
   trace export scheme.  We discuss the pros and cons of each approach.

2.  IOAM Trace Data Separate and Postpose

   The IOAM trace-type data fields contain two parts: the instruction
   and the trace data.  Although by convention the trace data part
   immediately follows the instruction part, there is no fundamental
   reason why these two parts must be kept together.  This observation
   provides an optimization opportunity to amend the original proposal
   in [RFC9486].

   We separate the IOAM trace-type data fields into the instruction part
   and the trace data part.  We encapsulate only the instruction part in
   the HbH Options header, and encapsulate the trace data part in
   another extension header option placed after all the IPv6 extension
   headers that need to be examined and processed on the packet
   forwarding path (e.g., a routing header).  This arrangement allows us
   to use the incremental trace option efficiently.  Even if the trace
   data increases in size at each node, all IPv6 extension headers
   before it remain a fixed size, and new data is guaranteed to be
   inserted at a fixed location.

   Figure 1 shows the HbH option format for the IOAM incremental trace
   type instruction.  The field specification is identical to that in
   [RFC8200] and [RFC9197].

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Option Type  |  Opt Data Len |   Reserved    |   IOAM Type   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<---
 |        Namespace-ID           |NodeLen  | Flags | RemainingLen| IOAM
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trace
 |               IOAM-Trace-Type                 |  Reserved     | Type
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<Inst.

      Figure 1: HbH Option Format for IOAM Incremental Trace Type
                              Instruction

   Figure 2 shows the TLV option format for the IOAM trace type data.
   The IOAM trace type data format is compliant with [RFC9197].

Song, et al.             Expires 4 February 2027                [Page 4]
Internet-Draft              IOAM IPv6 Support                August 2026

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   IOAM Type   |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      IOAM Trace Type Data                     ~
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: Option Format for IOAM Incremental Trace Type Data

2.1.  IOAM Incremental Trace Data Encapsulation

   There are basically two methods to encapsulate the IOAM incremental
   trace data.  First, we can define a new IPv6 extension header
   dedicated to metadata.  Once standardized, this extension header
   could also be used to host potential metadata from other
   applications, such as NSH for SFC [RFC8300].  Second, this option can
   be carried as a TLV option in an existing extension header, such as
   the Destination Options header (DOH).  The only requirement is that
   this extension header be the last one in the extension header chain.
   The first method is cleaner, but it requires standardizing a new
   extension header type; the second method is simpler, but it needs to
   overcome the access constraints imposed by [RFC8200].

3.  Segment IOAM Data Export

   If the overhead of the IOAM trace-type data fields is under control,
   we may still manage to encapsulate both the instruction and the data
   in the HbH Options header as described in [RFC9486].  To this end, we
   introduce two sub-approaches.

3.1.  Independent of SRv6

   [I-D.song-ippm-segment-ioam] proposes an enhancement to the IOAM
   trace type that can configure the allowable overhead of the IOAM
   trace-type data fields.  Once the trace data size reaches the limit
   at a network node (i.e., a segment, or a fixed number of network
   nodes, has been traversed), the trace data is stripped and exported
   so that room is made to accommodate new trace data from nodes in the
   next segment of the forwarding path.

   This approach requires some moderate updates to the IOAM trace-type
   data fields, as described in [I-D.song-ippm-segment-ioam].  Figure 3
   shows the format of the HbH Option header containing segment IOAM
   trace-type data fields.  A flag bit (#23) in the Flags field is used

Song, et al.             Expires 4 February 2027                [Page 5]
Internet-Draft              IOAM IPv6 Support                August 2026

   to indicate that the current header is a segment IOAM header.  In
   this context, the last octet in the IOAM header is partitioned into
   two 4-bit nibbles.  The first nibble (SSize) is used to save the
   segment size, and the second nibble (RHop) is used to save the
   remaining hops.  This limits the maximum segment size to 15.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Type  |  Opt Data Len |   Reserved    |   IOAM Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<------+
|       Namespace-ID            |NodeLen|Flags|1| SSize | RHop  | IOAM
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Segment
|               IOAM-Trace-Type                 |  Reserved     | Trace
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type
|                                                               | Data
|                  Node Data List []                            | Fields
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<------+

 Figure 3: HbH Option Format for Segment IOAM Trace Type Data Fields

   At the beginning of each segment, the segment size (SSize) and the
   remaining hops (RHop) are initialized: RHop is set equal to SSize.
   At each hop, if RHop is not zero, the node data is added to the node
   data list and then RHop is decremented by 1.  If RHop is equal to 0
   when the packet is received, the node needs to remove (in the
   incremental trace option) or clear (in the pre-allocated trace
   option) the IOAM node data list and reset RHop to SSize.

   In this case, if we use the IOAM pre-allocated trace type, the size
   and location of each IPv6 extension header are fixed and predictable,
   and the hardware capability and performance can be guaranteed.

3.2.  Export at SRv6 Node

   Whenever a packet with the IOAM option reaches an SRv6 segment
   endpoint node that needs to access the SRH, we can configure the node
   to immediately export the IOAM trace data accumulated so far.  In
   this case, at each SRv6 segment endpoint node, after the trace data
   export, the HbH header size is fixed and the header contains an IOAM
   option with only the instruction part.  After the SRH processing,
   this node can add local IOAM trace data to the HbH option header
   before forwarding the packet.

   The incremental trace type is more appropriate than the pre-allocated
   trace type in this approach, due to the uncertainty in the number of
   hops between two segment endpoints.  In an extreme case where every

Song, et al.             Expires 4 February 2027                [Page 6]
Internet-Draft              IOAM IPv6 Support                August 2026

   node is also an SRv6 node, this approach regresses to a per-hop
   postcard-based telemetry approach such as IOAM DEX, as described in
   [RFC9326].

4.  Direct Export Option

   It is worth noting that, instead of using the IOAM trace options, the
   IOAM Direct Export (DEX) option type [RFC9326] can be used for fixed
   and small packet overhead, since it only needs to encapsulate a
   fixed-size instruction header in the HbH Options header.  This scheme
   is covered in [RFC9486].

5.  Comparison

   The following table compares the existing approach (RFC 9486) with
   the alternative approaches discussed in this draft.

   +--------------+-------------------------+--------------------------+
   |  Approach    |   Pros                  |   Cons                   |
   |              |                         |                          |
   +--------------+-------------------------+--------------------------+
   |IOAM Trace    |Comply w/ IOAM Data Spec |Variable, long HbH        |
   |Option in     |                         |header impedes access of  |
   |HbH (RFC9486) |                         |other extension headers   |
   +--------------+-------------------------+--------------------------+
   |IOAM Trace    |Fix-size and short HbH   |Need extra extension      |
   |Data Separate |header, good for         |header option to hold     |
   |and Postpose  |accessing other extension|trace data                |
   |(Sec. 2)      |headers                  |                          |
   +--------------+-------------------------+--------------------------+
   |Segment IOAM  |Fix-size and controllable|Need to update IOAM trace |
   |Data Export   |HbH header size          |type data field spec.     |
   |(Sec. 3.1)    |                         |                          |
   +--------------+-------------------------+--------------------------+
   |Trace Export  |Can be done through      |Specific to SRv6;         |
   |at SRv6 nodes |configuration            |No better than IOAM       |
   |(Sec. 3.2)    |                         |DEX in the worst case     |
   +--------------+-------------------------+--------------------------+
   |IOAM Direct   |Comply w/ IOAM DEX Spec; |Need export data          |
   |Export in HbH |Fix-size and short HbH   |correlation, and other    |
   |(RFC9486)     |                         |issues of DEX (RFC9326)   |
   +--------------+-------------------------+--------------------------+

               Figure 4: Comparison of Different Approaches

Song, et al.             Expires 4 February 2027                [Page 7]
Internet-Draft              IOAM IPv6 Support                August 2026

   The IOAM trace option is easy to implement and extensible in its data
   types.  Complementary to [RFC9486], the scalable solutions for using
   it in IPv6 networks discussed in this document can fully realize the
   benefits of the IOAM trace option while avoiding the potential issues
   associated with variable and high header overhead.

6.  Security Considerations

   No new security issue is identified other than those for the IOAM
   trace option [RFC9197], IOAM DEX [RFC9326], and IPv6 extension
   headers [RFC8200].

7.  IANA Considerations

   This document requires no IANA actions.

8.  Acknowledgments

9.  Normative References

   [I-D.ali-spring-ioam-srv6]
              Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar,
              N. K., Pignataro, C., Li, C., Chen, M., and G. Dawra,
              "Segment Routing Header encapsulation for In-situ OAM
              Data", Work in Progress, Internet-Draft, draft-ali-spring-
              ioam-srv6-06, 10 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-ali-spring-
              ioam-srv6-06>.

   [I-D.song-ippm-ioam-tunnel-mode]
              Song, H., Li, Z., Zhou, T., and Z. Wang, "In-situ OAM
              Processing in Tunnels", Work in Progress, Internet-Draft,
              draft-song-ippm-ioam-tunnel-mode-00, 27 June 2018,
              <https://datatracker.ietf.org/doc/html/draft-song-ippm-
              ioam-tunnel-mode-00>.

   [I-D.song-ippm-segment-ioam]
              Song, H. and T. Zhou, "Control In-situ OAM Overhead with
              Segment IOAM", Work in Progress, Internet-Draft, draft-
              song-ippm-segment-ioam-01, 17 April 2018,
              <https://datatracker.ietf.org/doc/html/draft-song-ippm-
              segment-ioam-01>.

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

Song, et al.             Expires 4 February 2027                [Page 8]
Internet-Draft              IOAM IPv6 Support                August 2026

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

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9259]  Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
              Chen, "Operations, Administration, and Maintenance (OAM)
              in Segment Routing over IPv6 (SRv6)", RFC 9259,
              DOI 10.17487/RFC9259, June 2022,
              <https://www.rfc-editor.org/info/rfc9259>.

   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In Situ Operations, Administration, and
              Maintenance (IOAM) Direct Exporting", RFC 9326,
              DOI 10.17487/RFC9326, November 2022,
              <https://www.rfc-editor.org/info/rfc9326>.

   [RFC9486]  Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
              In Situ Operations, Administration, and Maintenance
              (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
              <https://www.rfc-editor.org/info/rfc9486>.

Authors' Addresses

   Haoyu Song
   Futurewei
   United States of America
   Email: haoyu.song@futurewei.com

Song, et al.             Expires 4 February 2027                [Page 9]
Internet-Draft              IOAM IPv6 Support                August 2026

   Zhenbin Li
   Huawei Technologies
   China
   Email: lizhenbin@huawei.com

   Shuping Peng
   Huawei Technologies
   China
   Email: pengshuping@huawei.com

   James Guichard
   Futurewei
   United States of America
   Email: james.n.guichard@futurewei.com

Song, et al.             Expires 4 February 2027               [Page 10]