RFC 9947

Application of the Alternate-Marking Method to the Segment Routing Header

📅 published March 2026, from ietf

RFC 9947: Application of the Alternate-Marking Method to the Segment Routing Header ✨

Okay bestie, let's get into it 🦋. This is an Experimental doc (category: Experimental, independent submission, so no IETF stamp of approval) from March 2026. The authors are G. Fioccola (Huawei), T. Zhou (Huawei), G. Mishra (Verizon Inc.), X. Wang (Ruijie), G. Zhang (China Mobile), and M. Cociglio. The ISSN is 2070-1721. It's a fresh experimental take on how to do Alternate-Marking inside the SRH, and it updates nothing and obsoletes nothing 💅. The title block says what it is, so let's dive into the actual content 🌸.

Abstract

This document describes an alternative experimental approach for applying the Alternate-Marking Method to Segment Routing for IPv6 (SRv6) 🎀. It uses an experimental TLV in the Segment Routing Header (SRH), so participation in this experiment should be between coordinating parties in a controlled domain 🔒. The approach has potential scaling and simplification benefits over the technique described in RFC 9343 🌈, and the whole point of the experiment is to find out whether those benefits are significant and attractive to the community 👑.

This protocol extension was developed outside the IETF as an alternative to the IETF's Standards Track specification RFC 9343, so it does not have IETF consensus 🙈. It's published here to guide experimental implementation and ensure interoperability among implementations, so everyone can better figure out how valuable this approach is 💖. Researchers are invited to submit their evaluations of this work to the Independent Submissions Editor or to the IETF SPRING Working Group as Internet-Drafts 🧚.

Status of This Memo

This document is not an Internet Standards Track specification 🍓. It's published for examination, experimental implementation, and evaluation ✨.

This document defines an Experimental Protocol for the Internet community 💜. It's a contribution to the RFC Series, independent of any other RFC stream 🎀. The RFC Editor chose to publish it at its discretion and makes no statement about its value for implementation or deployment 💅. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841 🫶.

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc9947 🌸.

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, because they describe your rights and restrictions with respect to this document 🙈.

Table of Contents

1.  Introduction
  1.1.  Observations on RFC 9343
  1.2.  Requirements Language
2.  Application of the Alternate-Marking Method to SRv6
  2.1.  Controlled Domain
3.  Definition of the SRH AltMark TLV
  3.1.  Base Alternate-Marking Data Fields
  3.2.  Optional Extended Data Fields for Enhanced Alternate
        Marking
4.  Use of the SRH AltMark TLV
  4.1.  Compatibility
5.  Experimentation Overview
  5.1.  Objective of the Experiment
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🦋

[RFC9341] and [RFC9342] describe a passive performance measurement method 🔍, which can measure packet loss, latency, and jitter on live traffic 📊. Because it works by marking consecutive batches of packets, people often call it the "Alternate-Marking Method" 🎨.

The Alternate-Marking Method needs a marking field so that packet flows can be told apart and identified 🏷️. [RFC9343] defines the standard for encoding that marking field in a new TLV, either in a Hop-by-Hop or a Destination Options Header of IPv6 packets, to achieve Alternate Marking 💫. This mechanism also works for Segment Routing for IPv6 (SRv6) networks [RFC8402] 🌸.

This document describes an alternative experimental approach that encodes the marking field in a new TLV carried in the Segment Routing Header (SRH) [RFC8754] of an SRv6 packet 🎀. This approach only applies to SRv6 deployments 💅. It's meant to take advantage of the assumption that Segment Routing (SR) nodes are supposed to support fast parsing and processing of the SRH, while SR nodes may not handle Destination Options properly, as discussed in [RFC9098] and [EH-LIMITS] 👀. The experiment is there to find out whether there are significant and attractive advantages for the community. If there are, the work may be brought back for IETF consideration 👑.

This protocol extension was developed outside the IETF as an alternative to the IETF's Standards Track specification [RFC9343]; it does not have IETF consensus 🙈. It's published here to guide experimental implementation and ensure interoperability among implementations, so we can better determine the value of this approach 💖. As also highlighted in [IETF-EXPERIMENTS], when two protocol extensions are proposed to solve a single problem, an experiment can be started to gather operational experience and "determine which, if either, of the protocols should be progressed to the standards track." That's the purpose of this document 🧚. See Section 5 for more details about the experiment ✨.

1.1. Observations on RFC 9343 🔎

Like any other IPv6 use case, Hop-by-Hop and Destination Options can also be used when the SRH is present 🌈. As specified in [RFC8200], the Hop-by-Hop Options Header carries optional information that needs to be examined at every hop along the path 🚶‍♀️, while the Destination Options Header carries optional information that only needs to be examined by the packet's destination node(s) 🎯.

When a Routing Header exists, and the SRH is a Routing Header, Destination Options present in the IPv6 packet before the SRH are processed by the destination indicated in the SRH's route list 📋. As specified in [RFC8754], SR segment endpoint nodes process the local Segment Identifier (SID) that matches the packet destination address 🆔. Then the destination address is updated according to the segment list 🔄. The SRH TLV provides metadata for segment processing while the SID is processed, if the node is locally configured to do so ⚙️. Both the Destination Options Header before the SRH and the SRH TLV are processed at the node indicated in the destination address field of the IPv6 header 📍.

The difference between the alternatives is most noticeable for SRv6 packets that cross a network where the paths between sequential segment endpoints include multiple hops 🛣️. If the Hop-by-Hop Option is used, every hop along the path processes the AltMark data 🔁. If the Destination Option placed before the SRH is used, or the SRH AltMark TLV is used, then only the segment endpoints process the AltMark data, unless the intermediate node has a different priority rule 🚦.

Both [RFC9343] and the approach in this document can coexist 🤝. In fact, this document does not change or invalidate any procedures defined in [RFC9343] 💯. However, deployment issues may come up, as discussed further below 😬.

The rest of this document is structured as follows:

  • Section 2 covers the application of the Alternate-Marking Method to SRv6 🧩,
  • Section 3 specifies the AltMark SRH TLV to carry the base data fields (Section 3.1) and the extended data fields (Section 3.2) 📦,
  • Section 4 discusses the use of the AltMark TLV, and 🛠️
  • Section 5 describes the experiment and the objectives of the experimentation (Section 5.1) 🧪.

1.2. 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. Application of the Alternate-Marking Method to SRv6 🌸

SRv6 uses the IPv6 SRH, which can embed TLVs to provide metadata for segment processing, as described in [RFC8754] 🧠. This document defines the SRH AltMark TLV to carry Alternate-Marking data fields for use in SRv6 networks 🎨, and it's an alternative to the method described in [RFC9343] ✌️. [RFC9343] defines how the Alternate-Marking Method can be carried in the Option Headers (Hop-by-Hop or Destination) of an IPv6 packet 📬. The AltMark data fields format defined in [RFC9343] is the basis of the AltMark SRH TLV introduced in Section 3 🧱.

Besides the base data fields of [RFC9343], inserting optional extended data fields that are not present in [RFC9343] is also allowed 🎁. These extended data fields can support metadata for additional telemetry requirements, as described further below 📈.

2.1. Controlled Domain 🏰

[RFC8799] introduces the concept of specific limited domain solutions and mentions applying the Alternate-Marking Method as an example 🗺️.

Despite the flexibility of IPv6, when innovative applications are proposed, they're often applied within controlled domains to help constrain domain-wide policies, supported options, the style of network management, and security requirements 🔐. This is also the case for applying the Alternate-Marking Method to SRv6 💅.

So, the experiment of applying the Alternate-Marking Method to SRv6 MUST only be deployed within a controlled domain 🚧. For SRv6, the controlled domain corresponds to an SR domain, as defined in [RFC8402] 🗂️. The Alternate-Marking measurement domain overlaps with the controlled domain 🤍.

Using a controlled domain is also appropriate for deploying an experimental protocol extension 🧪. Carefully bounding the domain reduces the risk of the experiment leaking out and clashing with other experiments or causing unforeseen consequences in wider deployments 🫧.

Part 1 of 4 done bestie 💖 Sections 3 onwards are coming in the next parts, so stay tuned 🎀✨

3. Definition of the SRH AltMark TLV ✨

Okay bestie, the AltMark SRH TLV is the little container that carries all the Alternate-Marking data 📦💖. It has some starter fields that are always there, plus extra fields that only show up when Enhanced Alternate Marking is switched on 💅.

Here's the layout in Figure 1 🎀:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | SRH TLV Type  |  SRH TLV Len  |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              FlowMonID                |L|D|  Reserved |  NH   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~              Optional extended data fields (variable)         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1: The AltMark SRH TLV for Alternate Marking

Here's what each field does 🦋:

  • SRH TLV Type: The 8-bit identifier of the Alternate-Marking SRH TLV. The value comes from the range 124-126. It's an Experimental code point for a TLV that doesn't change en route. Deploying this document means the value has to be coordinated across every implementation taking part in the experiment. So it's smart for experiments to think hard about any other implementations running in the controlled domain, so they don't clash with other SRH TLVs 🧚.
  • SRH TLV Len: The length of the Data Fields of this TLV in bytes. It's set to 6 when Enhanced Alternate Marking isn't in use.
  • Reserved: Reserved for future use 🌸. These bits MUST be set to zero when sent and ignored when received.
  • FlowMonID: The Flow Monitoring Identification field. It's a 20-bit unsigned integer, as defined in [RFC9343].
  • L: The Loss flag, as defined in [RFC9343].
  • D: The Delay flag, as defined in [RFC9343].
  • NH: The NextHeader field. It tells you whether extended data fields are there to support Enhanced Alternate Marking, like this 👑:
    • A NextHeader value of 0x0 means there's no extended data field attached.
    • NextHeader values 0x1-0x8 are reserved for further usage.
    • A NextHeader value of 0x9 means the extended data fields are present, as described in Section 3.2.
    • NextHeader values 0xA-0xF are reserved for further usage.

Optional extended data fields may be present according to the setting of the NH field and as described in Section 3.2 ✨.

3.1. Base Alternate-Marking Data Fields 🍓

The base AltMark data fields are the Loss (L) flag, the Delay (D) flag, and the Flow Monitoring Identification (FlowMonID) field, as in [RFC9343]. Okay so L and D are the marking fields of the Alternate-Marking Method 🔥, and FlowMonID identifies monitored flows and helps keep implementation and scaling optimized. Also, as already highlighted in [RFC9343], FlowMonID is used to identify the monitored flow because the Flow Label field of the IPv6 Header can't be used for that 🙈.

Now the tea ☕: if the 20-bit FlowMonID is set by the domain entry nodes, there's a chance of collision, even when the values are picked with a pseudorandom algorithm 💀. So it may not be enough to uniquely identify a monitored flow. In those cases, packets need extra flow information tagged on so they can be told apart 🫶. That extra tagging can be carried in the extended data fields described in Section 3.2.

3.2. Optional Extended Data Fields for Enhanced Alternate Marking 🌈

These optional extended data fields support Enhanced Alternate Marking, and they're shown in Figure 2. They're present when the NH field of the AltMark TLV is set to 0x9 🦄.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           FlowMonID Ext               |M|F|W|R|  Len  | Rsvd  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           MetaInfo            |      Optional MetaData        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~               Optional MetaData (variable)                    ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2: Optional Extended Data Fields for Enhanced Alternate
                                  Marking

Here's the breakdown of the extended data fields 💅:

  • FlowMonID Ext: A 20-bit unsigned integer that extends the FlowMonID to reduce conflicts when random allocation is applied 🌟. The disambiguation of the FlowMonID field is discussed in "IPv6 Application of the Alternate-Marking Method" [RFC9343].

Four different bit flags indicate special-purpose usage 🎀:

  • M bit: Measurement mode. If M=0, it's for segment-by-segment monitoring. If M=1, it's for end-to-end monitoring.
  • F bit: Fragmentation. If F=1, the original packet is fragmented, so only a single packet should be counted, ignoring all the following fragments with F set to 1 🧩. Note that F is set to 0 for the first fragment.
  • W bit: Flow direction identification. This flag is used when backward direction flow monitoring is requested to be set up automatically, so the egress node gets told to set up the backward flow monitoring 🦋. If W=1, the flow direction is forward. If W=0, the flow direction is backward.
  • R bit: Reserved. This bit MUST be set to zero and ignored on receipt 🌸.
  • Len: Length. The length of the extended data fields for Enhanced Alternate Marking, as a multiple of 4 bytes. It includes all of the fields shown in Figure 2, plus any metadata that's present 📏.
  • Rsvd: Reserved for further use. These bits MUST be set to zero on transmission and ignored on receipt 🫧.
  • MetaInfo: A 16-bit Bitmap that shows which additional metadata is attached in the Optional MetaData field for enhanced functions 🧠. More than one bit may be set, and when that happens the additional metadata shows up in the order the bits are set. MetaInfo bits are numbered from 0 as the most significant bit. Three bits and their metadata are defined, like so ✨:

bit 0: If set to 1, a 6-byte Timestamp is present, as shown in Figure 3 ⏰.

        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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |    Timestamp(s)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Timestamp(ns)                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: The Timestamp Extended Data Field

The encapsulation node can fill in this Timestamp, and it's carried all the way to the decapsulation node 🚀. That lets every intermediate node compare it against its own local time and measure the one-way delay. The Timestamp has two fields:

  • Timestamp(s): A 16-bit integer that carries the number of seconds.
  • Timestamp(ns): A 32-bit integer that carries the number of nanoseconds.

The Timestamp data field lets all the intermediate nodes measure the one-way delay, and it can be correlated with the implementation of [IPFIX] and [YANG-TELEMETRY] 💜. [IPFIX] introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay. [YANG-TELEMETRY] defines a YANG data model for monitoring On-Path Telemetry data, including the path delay. Iconic crossover 🙌.

bit 1: If set to 1, the control information to set up the backward direction flow monitoring is included, based on the trigger packet presence, as shown in Figure 4 🔁.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  DIP Mask     |  SIP Mask     |P|I|O|V|S|T|    Period         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 4: Control Information for Backward Direction Flow
                                  Monitoring

The control information has several fields and flags to match, so the backward direction can be set up 🎯:

  • DIP Mask: The length of the destination IP prefix used to match the flow.
  • SIP Mask: The length of the source IP prefix used to match the flow.
  • P bit: If set to 1, the flow is matched using the protocol identifier in the trigger packet.
  • I bit: If set to 1, it matches the source port.
  • O bit: If set to 1, it matches the destination port.
  • V bit: If set to 1, the node will automatically set up reverse direction monitoring and allocate a FlowMonID 🪄.
  • S bit: If set to 1, it matches the Differentiated Services Code Point (DSCP).
  • T bit: Used to control the scope of tunnel measurement. T=1 means measure between Network-to-Network Interfaces (i.e., NNI to NNI). T=0 means measure between User-to-Network Interfaces (i.e., UNI to UNI).
  • Period: The Alternate-Marking period, counted in seconds ⏳.

bit 2: If set to 1, a 4-byte Sequence Number is present, as shown in Figure 5 🔢.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Sequence Number                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 5: Sequence Number Data Field

The unique Sequence Number can detect out-of-order packets, and it also enables packet loss measurement 🕵️‍♀️. Plus, the Sequence Number can be used together with the latency measurement to access per-packet Timestamps 💖.

4. Use of the SRH AltMark TLV ✨

Okay bestie, since the measurement domain is congruent with the SR-controlled domain 🦋, the whole AltMark-in-SRv6-SRH thing is pretty chill. Here's the vibe for each role:

  • Ingress SR Node: As part of SRH encapsulation, the Ingress SR Node of an SR domain or an SR Policy [RFC9256] that supports the mechanisms in this document, and that wants to do the Alternate-Marking Method, adds the AltMark TLV to the SRH of the data packets 💅
  • Intermediate SR Node: Any node that gets an IPv6 packet whose destination address is a local Segment Identifier (SID) 👀. If it can't handle the AltMark TLV, it just ignores it following the processing rules of [RFC8754] 🙈. If it can handle it, it checks whether the SRH AltMark TLV is in the packet and processes it 💖
  • Egress SR Node: The last node in the segment list of the SRH 🏁. Processing the AltMark TLV here is exactly the same as at the Intermediate SR Nodes 🫶

The AltMark TLV can also be combined with SRv6 network programming [RFC8986] 🧚. Specifically, an SRv6 endpoint can decide whether to process or ignore certain SRH TLVs (like the AltMark TLV) based on the SID function linked to the SID that an Intermediate or Egress SR Node advertised and put in the Destination Address field of the SRv6 packet. If a packet is addressed to a SID that doesn't support Alternate-Marking, the receiving node doesn't have to look for or process the SRH AltMark TLV, and it can simply ignore it. This also means Alternate-Marking data only gets collected from the segment endpoints that actually support it ✨

4.1. Compatibility

As highlighted in Section 1.1, carrying the AltMark data in a Destination Option placed before the SRH is equivalent to the SRH AltMark TLV 🎀. So it's important to analyze what happens when both the SRH AltMark TLV and the Destination Option are present, and how that would affect processing and complexity 🤔

Here's the tea: the SRH AltMark TLV and the Destination Option carrying AltMark data can coexist just fine 💅. If both are there, the only issue is duplicated information, and that won't affect the device or the network services in any way 🌸. Both this document and [RFC9343] require a controlled domain for security purposes, which keeps this duplication inside a single service provider network 🔒. Still, duplicating the same info in different places should be avoided, and analyzing the use of only the SRH AltMark TLV is recommended as part of this experiment 🍓

5. Experimentation Overview 🧪

The protocol extension in this document is built on existing technology and uses an Experimental code point 💜. Experiment participants have to use a code point picked from the Experimental range, as noted in Section 3, and should make it possible for the operator to configure the value used in a deployment, so multiple non-conflicting experiments can run on the same network 👑

This experiment is trying to figure out whether the SRH AltMark TLV actually brings advantages 🤩. That's especially relevant for implementations that can't support multiple IPv6 extension headers in the same packet, that don't support Destination Options Header processing, or that process the Destination Options Header on the slow path 🐢

The experiment also needs to determine whether the proposed protocol extensions achieve the desired function and can be supported alongside normal SRv6 processing 🫧. In particular, it needs to verify the ability to support SR network programming, SID function control, and the support or non-support of the AltMark TLV 💅

This experiment is expected to stay inside a single service provider network, in line with the constraints of an SR domain, and also in line with the limits on sharing performance monitoring data collected on the path of packets in the network 🔐. How big the experimental deployment gets may depend on how many implementations are available and how willing operators are to deploy it on live networks 🌈

Results from this experiment will be collected and shared with the Independent Submissions Editor or with the IETF SPRING Working Group as Internet-Drafts, to help move along the discussions that will shape how Alternate-Marking Method solutions develop for SRv6 networks 📝. Initial results are expected within two years of this document being published as an RFC ⏰

5.1. Objective of the Experiment

Researchers are invited to compare the SRH AltMark TLV against the existing approach in [RFC9343] 🔍. There are several potential areas to explore and analyze:

  • Does the SRH AltMark TLV survive across a network better or worse than an extension header does?
  • Does SRH TLV processing make the device perform better or worse than the Destination Option does?
  • Is forwarding plane performance affected across different device architecture types when comparing the SRH TLV with the Destination Option?
  • How does the use of the extended data fields, introduced in Section 3.2, compare to other on-path telemetry methods from the point of view of operators? 🧐

6. Security Considerations 🛡️

The security considerations of SRv6 are discussed in [RFC8754] and [RFC8986], and the security considerations of Alternate Marking in general and its application to IPv6 are discussed in [RFC9341] and [RFC9343] 🔐.

[RFC9343] analyzes different security concerns and related solutions 🧠. Those aspects are valid and apply to this document too 💯. The big one is this: the fundamental security requirement is that Alternate Marking MUST only be applied in a limited domain, as also mentioned in [RFC8799] and Section 2.1 🚨. This is non-negotiable, bestie 😭

Alternate Marking is a feature for a trusted domain, where a single operator decides how to use and configure it based on their needs 🏰. On top of that, operators need to properly secure the Alternate-Marking domain against malicious configuration and attacks, which could include injecting malicious packets into the domain 🕵️. So Alternate Marking gets applied inside a controlled domain, where the network nodes are locally administered and packets carrying the AltMark TLV are kept from entering or leaving the domain 🚧. A limited administrative domain gives the network administrator the means to select, monitor, and control access to the network 👀

7. IANA Considerations 📭

This document has no IANA actions 🌷.

8. References 📚

8.1. Normative References

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

[RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
           Decraene, B., Litkowski, S., and R. Shakir, "Segment
           Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
           July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
           and T. Zhou, "Alternate-Marking Method", RFC 9341,
           DOI 10.17487/RFC9341, December 2022,
           <https://www.rfc-editor.org/info/rfc9341>.

[RFC9342]  Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
           T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
           DOI 10.17487/RFC9342, December 2022,
           <https://www.rfc-editor.org/info/rfc9342>.

[RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
           Pang, "IPv6 Application of the Alternate-Marking Method",
           RFC 9343, DOI 10.17487/RFC9343, December 2022,
           <https://www.rfc-editor.org/info/rfc9343>.

8.2. Informative References

[EH-LIMITS]
           Herbert, T., "Limits on Sending and Processing IPv6
           Extension Headers", Work in Progress, Internet-Draft,
           draft-ietf-6man-eh-limits-19, 27 February 2025,
           <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
           limits-19>.

[IETF-EXPERIMENTS]
           Bonica, R. and A. Farrel, "IETF Experiments", Work in
           Progress, Internet-Draft, draft-bonica-gendispatch-exp-07,
           19 January 2026, <https://datatracker.ietf.org/doc/html/
           draft-bonica-gendispatch-exp-07>.

[IPFIX]    Graf, T., Claise, B., and A. H. Feng, "Export of Delay
           Performance Metrics in IP Flow Information eXport
           (IPFIX)", Work in Progress, Internet-Draft, draft-ietf-
           opsawg-ipfix-on-path-telemetry-23, 30 September 2025,
           <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
           ipfix-on-path-telemetry-23>.

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

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

[RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
           Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
           <https://www.rfc-editor.org/info/rfc8799>.

[RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
           D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
           (SRv6) Network Programming", RFC 8986,
           DOI 10.17487/RFC8986, February 2021,
           <https://www.rfc-editor.org/info/rfc8986>.

[RFC9098]  Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
           G., and W. Liu, "Operational Implications of IPv6 Packets
           with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
           September 2021, <https://www.rfc-editor.org/info/rfc9098>.

[RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
           A., and P. Mattes, "Segment Routing Policy Architecture",
           RFC 9256, DOI 10.17487/RFC9256, July 2022,
           <https://www.rfc-editor.org/info/rfc9256>.

[YANG-TELEMETRY]
           Fioccola, G., Zhou, T., Zhu, Y., Zhang, W., and K. Zhu,
           "On-Path Telemetry YANG Data Model", Work in Progress,
           Internet-Draft, draft-ietf-ippm-on-path-telemetry-yang-02,
           2 January 2026, <https://datatracker.ietf.org/doc/html/
           draft-ietf-ippm-on-path-telemetry-yang-02>.

Acknowledgements 🫶

The authors would like to thank Eliot Lear, Adrian Farrel, Joel M. Halpern, and Haoyu Song for the precious comments and suggestions. 🌈💖

Contributors ✨

okay so these three legends all contributed to this doc and deserve a shoutout 🫶

Fabio Bulgarella
Telecom Italia
Email: fabio.bulgarella@guest.telecomitalia.it
Massimo Nilo
FiberCop
Email: massimo.nilo@fibercop.com
Fabrizio Milan
FiberCop
Email: fabrizio.milan@fibercop.com

Authors' Addresses 💅

and here are the authors, bestie, so you know where to find them 🦋

Giuseppe Fioccola
Huawei
Viale Martesana, 12
20055 Vimodrone (Milan)
Italy
Email: giuseppe.fioccola@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com
Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Xuewei Wang
Ruijie
Email: wangxuewei1@ruijie.com.cn
Geng Zhang
China Mobile
Email: zhanggeng@chinamobile.com
Mauro Cociglio
Email: mauro.cociglio@outlook.com
📦 where this page comes from