



PIM                                                       T. Eckert, Ed.
Internet-Draft                                Futurewei Technologies USA
Intended status: Informational                                    Y. Liu
Expires: 22 January 2026                                    China Mobile
                                                                  Y. Zhu
                                                           China Telecom
                                                                  C. Lin
                                                    New H3C Technologies
                                                            21 July 2025


   Proposal for experimentation with stateless IPv6 multicast source
   routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing
                             Headers (MRH)
                   draft-eckert-pim-mrh-experiment-02

Abstract

   This document proposes experimentation to evaluate benefits and
   feasibility of an IPv6 routing extension header based architecture,
   implementation and deployment of stateless IPv6 multicast
   specifically for IPv6 only networks using SRv6 for IP unicast.

   This experimentation intends to explore options to support easier
   proliferation of technologies developed by BIER-WG by providing an
   IPv6/SRv6 network optimized packet header and per-hop forwarding
   mechanisms than BIERin6.  It also discusses how this work related to
   exploring advanced in-packet tree encoding mechanisms for both IPv6/
   SRv6 networks as well as BIER networks as a related effort.

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 January 2026.





Eckert, et al.           Expires 22 January 2026                [Page 1]

Internet-Draft               mrh-experiment                    July 2025


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.

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background: The road towards BIER . . . . . . . . . . . . . .   4
   3.  BIER for IPv6 networks  . . . . . . . . . . . . . . . . . . .   8
   4.  Challenges of BIER with IPv6  . . . . . . . . . . . . . . . .   9
     4.1.  Oerational, architectural, performance  . . . . . . . . .   9
     4.2.  Architectural and functional  . . . . . . . . . . . . . .  10
     4.3.  IETF process  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  List of target benefits / directions  . . . . . . . . . . . .  11
   6.  Intial proposed MRH definitions . . . . . . . . . . . . . . .  13
     6.1.  MRH Header  . . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  BIER MRH Sub-Type format  . . . . . . . . . . . . . . . .  14
     6.3.  Further MRH Sub-Type considerations . . . . . . . . . . .  15
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Changelog  . . . . . . . . . . . . . . . . . . . . .  18
   Appendix B.  History  . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Overview

   This document proposes experimentation to evaluate benefits and
   feasibility of an IPv6 routing extension header based multicast
   forwarding.  Experimentation should include implementation and
   experimental deployment to evaluate the feasability and benefits of
   this approach for IPv6 only networks, especially those using SRv6 for
   unicast compared to alternative approaches such as using
   [I-D.ietf-bier-bierin6].









Eckert, et al.           Expires 22 January 2026                [Page 2]

Internet-Draft               mrh-experiment                    July 2025


   This document is mostly meant to be a process document to vet support
   for the direction, and if that exists, it would be followed up by an
   appropriate IPv6 extension header draft proposal as well as other
   deemed necessary documents, such as an architectural document to
   describe howto apply the SRv6 SID semantic to the addresses used (or
   indicated) vby the IPv6+extension header for stateless multicast.

   The new IPv6 routing extension header would initially be using using
   one or two of the [RFC4727] Experiment Routing Types (253, 254).
   Upon successfull completion of experimentation, assignment of a
   permanent Routing Type could be requested.

   The new routing extension header should inherit all re-useable
   aspects of the pre-existing unicast routing headers (RPL source route
   header and SRH), so that no unnecessary re-invention of already
   applicable SRv6 technology is done.

   Likewise, the new routing extension header should in one option
   explore how to best re-use the IETF BIER established stateless
   multicast forwarding architecture, [RFC8279] while also complying to
   [RFC8200], and only exceeding it, when seen beneficial.

   Experimentation is also meant to investigate how multiple different
   encodings of the stateless multicast forwarding information could
   best be encoded in such multicast routing extension header options;
   these are henceforth called MRH - Multicast Routing Header.

   For example, different encodings could use different Routing Type
   code points as used for example across the different compressed
   unicast routing header options such as CRH-16, CRH-32.  In another
   option, different encoding options could be selected from a further
   code-point within a single MRH Routing Type header.

   The experimentation should include two different encoding options.
   One is the aforementioned [RFC8296] architecture based stateless
   multicast forwarding information (bitstring plus metadata).

   The second encoding should be an initial proposed encoding for
   stateless tree encoding within the MRH, such as derived from, but not
   necessarily [I-D.eckert-pim-rts-forwarding].  Note that like also in
   unicast SRv6 and its various forms of compressed routing header
   options, ultimtely different type of networks may prefer different
   encodings for multicast, and hence ensuring the design for
   extensibility is one core goal of this experimentation.

   This document does not (yet) propose an exact list of target
   documents required to perform the experiment or which WG it should
   best happen, but observes the following:



Eckert, et al.           Expires 22 January 2026                [Page 3]

Internet-Draft               mrh-experiment                    July 2025


   *  6MAN-WG is the responsible working group for IPv6 extension
      headers, but it requires a show of sufficient demand for the
      extension header in technology cases like this.  One of the goals
      of the initial work with 6MAN-WG should be to determine how much
      of the encoding variations could be done without repeated work for
      6MAN-WG, but instead by only work of the more expert work for such
      encodings, such as BIER.  This would follow the logic, by which
      different semantics of QoS information in the DSCP field where
      also not performed by 6MAN-WG but other working groups (such as
      TSVWG).

   *  SPRING-WG is the overall responsible WG for the IPv6/SRv6
      archtiecture as well as its unicast forwarding designs.  SPRING-WG
      has delegated responsibility for IPv6 multicast aspects to PIM-WG.
      Hence this document is also positioned for PIM-WG for first
      considerations.

   *  BIER-WG is the working group which has introduced stateless
      multicast replication to the IETF, and where all the experience
      with hardware forwadrding implementation for stateless multicast
      replication exists.  Given how the goal of this experimentation is
      to not re-invent any aspect of BIER-WG except for those aspects
      that will support better adoption of the technology to IPv6-only/
      SRv6 networks, it is highly desirable to involve BIER in any of
      the aspects of the experiment where this expertise can be drawn
      upon and where consistency with existing BIER approaches needs to
      be vetted.

   *  New encoding options for stateless multicast forwarding should not
      only be defined for encapsulation within an IPv6 MRH, but if BIER-
      WG is also interested in that encoding, then the encoding should
      be specified agnostic to header encoding, such that it could
      support encapsulation both into IPv6/MRH as well as BIER/[RFC8296]
      headers.

2.  Background: The road towards BIER

   This background section is intended as an overview to motivate why
   operators have shown interest in an IPv6/SRv6-SRH aligned solution
   for stateless multicast for many operational reasons, and why BIER-WG
   did arrive at a different conclusion for technology when adopting
   [I-D.ietf-bier-bierin6].  This is written in the hope that the
   experimentation proposed by this document is understood as a
   complementary technology that is ultimately meant to proliferade the
   BIER-WG spearheaded technology into more markets with minimum
   additional standardization and development effort.





Eckert, et al.           Expires 22 January 2026                [Page 4]

Internet-Draft               mrh-experiment                    July 2025


   Before BIER, multicast solutions where defined as extensions of the
   unicast (inter)network solution run in the network.  RFC1112 defined
   IP Multicast which re-used IPv4 ([RFC791]) packet headers and added
   multicast semantic through a range of dedicated-to-multicast IPv4
   destination adress range.  IPv6 kept this architecture but already
   included it in [RFC2460].  In result, so-called dual-plane IPv4/IPv6
   network did also have to run dual-plane IPv4/IPv6 multicast.  In
   networks that only could or wanted to run a single version of IP,
   solutions for encapsulation of one version over the other also exist
   for both unicast and multicast.

   In MPLS networks, initially IP multicast was run by using IPv4
   multicast in parallel to MPLS for unicast, but operators expected
   that the protocol stack for multicast both in the forwarding plane as
   well as the control plane was adjusted to leverage the same protocols
   as for MPLS unicast, so that at least in name the variety of
   protocols that needed to be run in the network for unicast and
   multicast was not increased over an MPLS unicast only network.  Even
   though implementations of PIM for an MPLS forwarding plane already
   existed since 1998, the PIM approach was explicitly not choosen
   because this was a protocol unfamiliar to MPLS network operators.
   Instead, the industry and thereafter the IETF chose to embed the
   necessary multicast functionality into the dominant MPLS unicast
   protocols LDP and RSVP-TE.  This resultet in mLDP (multicast LDP) and
   RSVP-TE/P2MP (Point to Multipoint).

   Likewise, PIM overlay signaling for multicast VPN services was also
   re-invented due to operator demand by bringing similar multicast
   group membership signaling into BGP, thus allowing service providers
   to completely run on only BGP and IGP but without PIM for multicast.
   Whether the forwarding plane uses IPv4/IPv6 or MPLS.  This was done
   even though no other than operational reasons of familiary by
   operators with BGP where brought forward versus the already well
   deployed option of using PIM for overlay signaling in those VPN
   solutions.

   While this approach of having the multicast solution be embedded in
   the networks unicast solution does have a wide range of benefits, it
   also came with downsides.  When classical MPLS solutions with LDP
   where superceeded by SR-MPLS network solution for unicast, this was
   also done to eliminate LDP from the network, which had a range of
   problems co-existing with unicast IGPs, and/or arguably unnecessary
   complexity and duplication of protocol state.  But in the wake of
   this unicast network architecture evolution towards unicast SR-MPLS,
   operators also asked to eliminate multicast MPLS using mLDP and RSVP-
   TE/P2MP.





Eckert, et al.           Expires 22 January 2026                [Page 5]

Internet-Draft               mrh-experiment                    July 2025


   More fundamentally, multicast solutions including all the
   aforementioned ones are based on explicit multicast tree state, which
   is managed hop-by-hop in the network.  This is completely contrary to
   what operators are used to do with MPLS or IP unicast.  In unicast,
   the network, especially the transit nodes (called P-nodes in service
   provider networks) only carry topology state (routing tables), but
   not state belonging to or influenced by individual subscribers of the
   network.  Subscribers may send arbitrary traffic, but that will not
   impact the IP/MPLS unicast routing tables on P-nodes.

   In IP/MPLS multicast, this is not the case.  When a subscriber starts
   multicast sender and receiver applications, then they will cause
   mLDP, PIM or BGP signaling to propagate through the network including
   transit service provider hops and ultimately create multicast tree
   state, which is similar in nature to unicast routing tables: It
   requires hardware forwarding resources that can get exhausted, and it
   requires control plane activity that may put undesirable load onto
   the control plane CPU not only during creation or change of the
   applications, but even more so during reconvergence due to
   topological changes in the network (failures, recoveries).

   While advanced multicast VPN protocol options do allow service
   providers to put bounds on this state (I-PMSI state and aggregated
   S-PMSI state), this too is causing additional complexity and
   diagnostic/troubleshooting overhead.

   Even when there is no misbehavior in the network, keeping track and
   troubleshooting multicast state hop-by-hop in the network can be a
   real operational challenge, and even with aforementioned multicast
   VPN mechanisms in place, it still is the equivalent of having unicast
   (BGP) VPN subscriber routing table entry related state on P-routers,
   whereas in unicast those P-routers only carry a completetely
   subscriber agnosted IGP routing table.

   In result of all these operational experiences by operators, several
   of them opted to move from their prior (stateful) multicast solution
   to one where there would be no multicast state at all across the
   service provider core network, instead replicating multicast traffic
   on the ingress PE as unicast traffic, one copy each to each egress PE
   that required the packet.  This was much later standardized as
   ([RFC7988]).  This is called "multicast ingress replication"

   BIER was invented out of the early recognition of these operational
   challenges and in fear that the non-scalability of multicast ingress
   replication would ultimately lead to the demise of solutions relying
   on network based multicast.  The BIER architecture, [RFC8279] defines
   a mechanism by which a packet header which includes a bitstring and
   associated metadata can source-route and replicate the packet hop-by-



Eckert, et al.           Expires 22 January 2026                [Page 6]

Internet-Draft               mrh-experiment                    July 2025


   hop across P-routers to a set of egress (PE) routers using only the
   same type of of routing information as already present in a service
   provider network - addressing information for the core networks P/PE
   routers specific to BIER, but not to any subscriber information.

   With BIER, no multicast tree state ever needs to exist on the transit
   (P) routers.  The BIER technology also makes it easy to evolve from
   multicast ingress replication solutions, by simply adding the BIER to
   the P/PE routers and letting the ingress router determine the BIER
   header bitstring instead of creating a separate copy per packet to
   each required PE.  Even partial deployment of BIER across P/PE
   routers is well considered in the BIER architecture and feasible
   automastically without additional provisioning, albeit this is likely
   not fully supported by existing implementations today.

   The BIER architecture does not specify the way such a BIER header was
   to be packetized.  Initially during the work on BIER it was seen as a
   real possibility to create per-unicast-network-design encapsulations
   as it was done in before for IPv4/IPv6 and MPLS.  Nevertheless, when
   work towards the first BIER encapsulation(s) progressed, it became
   obvious that the definition of multiple different encapsulations was
   at the non-mature and non-adopted state of the technology too
   ambitious and time consuming (note that the same may be said about
   the current evolution towards multiple comprssed unicast routing
   headers).

   Instead, BIER-WG chose an approach where the metadata required for
   different type of networks was coalesced into a single BIER header
   approach, which ultimately became [RFC8296] - "Encapsulation for BIER
   in MPLS and Non-MPLS Networks".  This header includes a DSCP field
   for use in IP network, and the first 32 bits mimic exactly a 32-bit
   word of an MPLS stack.

   When BIER packets are propagated through an MPLS network, there is no
   end-to-end MPLS label stack or even MPLS "packet" in that BIER
   packet.  Logically the per-hop BIER forwarding happens solely at the
   BIER layer, and on every hop the packet is encapsulated into a
   single-LSE MPLS frame.  In a network with full BIER support, where
   BIER routers are L2 adjacenty, this is functionally equivalent to
   simply encapsulate the BIER packet into an ethernet frame with a BIER
   ethernet type.  The core reasons for the MPLS encapsulation was the
   MPLS network operator preference to only see MPLS frames on the wires
   and the possible simplification of MPLS centric router hardware
   forwarding plane designs to demultiplex packets easier on an LSE than
   on an ethertype.  An actual functional benefit of the MPLS
   encapsulation exists, in a partial deployment, when the next BIER
   router is not L2 adjacent, and the MPLS label could for example be an
   SR-MPLS label to the closest BIER capable router.



Eckert, et al.           Expires 22 January 2026                [Page 7]

Internet-Draft               mrh-experiment                    July 2025


   As a result of this originally "optimized-for-MPLS" approach,
   architecturally [RFC8296] marked for BIER the desire to embrace an
   approach where the BIER multicast solution should be seen as a "one-
   size-fits-all" multicast network designs: To avoid the problem that
   any change/evolution in unicast forwarding technologies would create
   undesirable asks for change in the multicast technology - and hence
   cause unnecessary technology churn.

   Of course, this approach for the BIER forwarding plane does not
   prevent possible churn on the necessary BIER control plane.  If for
   example use of IGP in networks (as is the standard today in SR
   networks) should fall out of fashion, and would be replaced by some
   (maybe AI controlled ?) SDN-controller control plane, then the same
   would be necessary also for BIER.

3.  BIER for IPv6 networks

   Operators of IPv6-only networks using SRv6 for unicast traffic
   steering and service management expressed interest in adopting
   stateless source-routed technologies for multicast across their
   networks.

   The BIER architecture [RFC8279] was the obvious starting point to
   provide this functionality.  Additional service requirements such as
   traffic engineering could be solved via BIER extensions such as BIER-
   TE ([RFC9262]) without IPv6 specific changes required.

   Some SRv6 networks are amongst the largest Service Provider networks
   in the world, hence there is likely going to be more of an upper-end
   scaling evaluation to be done for SRv6 networks.

   However, the core challenge for IPv6-only network operators comes
   through the "one-size-fits-all" model adopted via [RFC8296] by BIER.
   By itself, this RFC is insufficient to operate BIER in a network
   without MPLS.  For this reason, [I-D.ietf-bier-bierin6] (BIERin6)
   defines how to operate BIER in an IPv6 only network based on the
   requirements stated in [I-D.draft-ietf-bier-ipv6-requirements].  This
   approach repeats the MPLS network approach for BIER in IPv6 networks:
   end-to-end forwarding is via an [RFC8296] BIER header and BIER hop-
   by-hop an IPv6 specific IPv6 "tunnel" header can be added if that is
   so desired, to make the packet appear as IPv6 on the wire.  In a full
   deployment those L2 IPv6 encapsulations could even use link-local
   IPv6 addresses.

   In addition, the encoding and control plane signaling of the BIER
   metadata that needs change from its [RFC8296] MPLS bindings also
   requires new drafts, [I-D.ietf-bier-non-mpls-bift-encoding] and
   [I-D.ietf-bier-lsr-non-mpls-extensions].



Eckert, et al.           Expires 22 January 2026                [Page 8]

Internet-Draft               mrh-experiment                    July 2025


4.  Challenges of BIER with IPv6

4.1.  Oerational, architectural, performance

   The main challenge is that the requirements that lead to BIERin6 did
   not take the operational and architectural preferences of operators
   running IPv6-only networks into account by replicating the model
   developed with primarily MPLS in mind.  For operators of IPv6/SRv6
   networks, BIERin6 marks a significant departure from their unicast
   IPv6 network architecture and operations.

   One key difference between IPv6 and MPLS designs is that the cost of
   headers and encap/decap.  When operators in an IPv6 network expect
   for operational reasons to see only IPv6 packets on the wire, the
   BIERin6 approach would require per-L2-hop additional IPv6 tunnel
   encapsulations, which is a significant overhead, whereas the MPLS
   equivalent is no additional encapsulation overhead at all, because
   the BIER header itself already start with a 32 bit word that serves
   as an MPLS LSE and single-entry label stack to demultiplex to BIER.

   If instead (as proposed to be experimented in this document), the
   [RFC8200] approach of IPv6 extension header source-routing was used,
   then this additional IPv6 per-hop encapsulation header was not
   required, but the end-to-end IPv6 header (plus extension header) that
   is always required would suffice.

   Note too, that this difference also holds true, when there is only a
   partial deployment of stateless multicast replication capable
   routers, because by virtue of the pre-existing end-to-end IPv6 header
   and [RFC8200] defined forwarding rules, the forwarding across non-
   stateless-multicast-capable IPv6 routers would solely require
   forwarding based on the IPv6 destination address of the IPv6 (base)
   header.

   In addition to overhead on the wire, different type of forwarding
   planes may also incur different degrees of performance loss when per
   L2-hop packets actually need to be decapsulated and re-encapsulated
   into link-local address IPv6 headers.  Keeping an encapsulation IPv6
   header and re-writing it hop-by with not only the destination address
   (as required by [RFC8200], but also the source-address might equally
   be a challenge if hardware is not specifically optimized for that.
   The author has the unfortunate experience with this type of hop-by-
   hop IPv6 tunneling in a completely different use-case domain, where
   it has served as the core obstacle to adoption (see [RFC8994]).







Eckert, et al.           Expires 22 January 2026                [Page 9]

Internet-Draft               mrh-experiment                    July 2025


4.2.  Architectural and functional

   While these differences between BIERin6 and extension header based
   approaches are mostly router-implementation, performance and operator
   preference, there is also a more fundamental issue with BIER which
   the proposed extension header resolves, and that is that the packet
   on the wire can not be identified as an IPv6 multicast packet, and
   hence the wide range of collateral forwarding plane functions that
   have already been defined in routers to manage IPv6 multicast traffic
   are not applicable or would require a lot more complex, variable
   length lookup of the IPv6 multicast destination address across
   protocol layer boundaries.  These features are listed further below
   in the document.

   Another way to look at this functional difference is that BIER was
   designed to require an IP Multicast flow overlay so that BIER could -
   maybe similar to MPLS - be a common "L2.5" technology, whereas IPv6
   multicast is designed as an end-to-end L3 technology just like IPv6
   unicast, and the IPv6 extension header approach is the only obvious
   way to achieve this, and minimize or completely eliminate additional
   layering overheads necessary otherwise.

4.3.  IETF process

   In the discussions about the best BIER for IPv6 network solution, one
   of the foremost argument by those in favor of BIERin6 was also
   explicitly to prove investment protection for those vendors who had
   already invested into [RFC8279] and [RFC8296].  While it certainly
   makes sense to support commercial goals in IETF, this specific ask
   was never admitted in any prior technology decision between MPLS and
   IPv6 solutions nor for other Multicast technologies (e.g.:
   introducing BGP instead of PIM overlay signaling was providing all
   the necessary functionality, or introducing MPLS multicast forwarding
   when many operators had deployed native IPv4 multicast in MPLS
   networks).  Nor was it done in the case of other technologies, such
   as OSPF vs. IS-IS.  Instead, if and when different competing designs
   existed due to customer demand, the IETF always tried to provide
   equally optimized solutions for each customer network type and let
   the market decide.












Eckert, et al.           Expires 22 January 2026               [Page 10]

Internet-Draft               mrh-experiment                    July 2025


   While technically similar approaches may pose additional work in the
   IETF, they have typically always shown to be beneficial for the
   overall set of customers of IETF standards, broadening the scope of
   applicability to more candidate customers.  The hope of this
   experimentation is equally that this would hold true for the
   proliveration of original BIER technoligies into IPv6/SRv6 only
   networks - more so than what BIERin6 alone could achieve (in the
   opinion of the author).  Expecting for BIERin6 to make BIER
   successfull in IPv6-only/SRv6 networks is a highly risky proposition
   and can easily result in less than more adoption of the technology.

   Hence this document proposes for the IETF to at least embrace
   experimentation with the IPv6 extension header based options which do
   provide the best technically and operational solutions for IPv6-only/
   SRv6 networks.  Especially given the recent varied work on different
   unicast steering header options for SRv6 unicast, it seems highly
   unlikely that the industry could not endure an additional encoding
   alternative to [RFC8296] for stateless multicast replication in IPv6
   networks.

5.  List of target benefits / directions

   The following is a candidate list of benefits/technical targets of
   the solutions

   The solution uses an IPv6 routing extension header in the same
   fashion as SRv6 unicast does this ([RFC8754]) for high-speed networks
   or [RFC6554] for IoT networks.  Ideally, it should be sufficient to
   have a single new IPv6 routing extension header for stateless
   multicast (instead of two for unicast for different networks).

   For operational safety, it seems prudent to allocate a new routing
   extension header code point so that this technology can be introduced
   into networks which already run either of the existing unicast
   extension headers without having to change any of the unicast
   specific fowarding plane code - because demultiplexing between
   unicast and multicast would already be able to happen at the
   extension header code point.

   If instead it is seen by IPv6 experts that it is equally safe and
   feasible to encode the information necessary for stateless multicast
   into the existing SRH extension header, using similar tricks to how
   compressed unicast steering is encoded
   ([I-D.ietf-spring-srv6-srh-compression]), and that this is
   preferrable, then this could of course equally be considered.






Eckert, et al.           Expires 22 January 2026               [Page 11]

Internet-Draft               mrh-experiment                    July 2025


   All forwarding should follow the [RFC8200] and [RFC8986] principles
   to the extend that they are applicable to packets that need to be
   replicated.  This specifically means that on each steering or
   replication hop, the IPv6 header destination address gets rewritten
   by the next steering/replication hop IPv6 address ("SID") derived
   from the extension header.

   While application software stacks for other network protocols beside
   IP do exist, they are by far not as widely and easily accessible
   across wide ranges of platforms/operating systems. use of IPv6
   extension headers is the likely most easy proliferable solution to
   bring stateless multicast replication into the software realm.  This
   is not only useful for softwareization of traditional routers with
   new implementations, or decomposition thereof into network function
   application code, but even more so for actual classical end-to-end
   applications using IP multicast.  Enabling such applications, to
   solely rely on stateless multicast, for example in data centers is an
   explicit additional market space that this effort intends to support.

   To directly support the established IP multicast service interfaces
   of ASM and SSM, the extension header must support to directly
   indicate IP multicast.  Technically this means that the extension
   header also needs to be able to carry an IPv6 mulicast destination
   address directly, namely when there is the need to indicate an IPv6
   multicast packet.  This is a significant difference over SRv6 unicast
   and BIER.  BIER specifically does support IP multicast only in the
   way MPLS does it: as an L2.5 underlay, which can encapsulate an IP
   multicast packet.  The stateless IPv6 multicast solution intends to
   avoid this duplication of IPv6 header when it is used end-to-end.

   With this architecture, IPv6 multicast applications could be made to
   rely on stateless IPv6 multicast if the socket/network layer in the
   multicast hope can simply insert the routing extension header
   indicating the stateless distribution tree - without the need for any
   additions IPv6 in IPv6 encapsulations or other complexity.  This for
   example could easily be something to make deployment of IPv6
   multicast easier in data center encvironments where the extension
   header data could be requested from and provided by a network
   controller.

   Carrying the IPv6 multicast destination address in a fixed offset
   part of an IPv6 extension headers makes it possible (at somewhat
   higher parsing cost) to maintain traditional operational benefits of
   IP multicast: It allows per-hop operation of IP specific forwarding
   plane features:

   *  IP multicast IPfix for accounting, billing and performance quality
      troubleshooting



Eckert, et al.           Expires 22 January 2026               [Page 12]

Internet-Draft               mrh-experiment                    July 2025


   *  IP multicast group address (range) derived QoS handling (common in
      several network and well matching [RFC8986] "programming" goals).

   *  IPmulticast group range derived accounting, billing, policiing or
      other policies.

6.  Intial proposed MRH definitions

6.1.  MRH Header

   This chapter gives a non-normative idea of how the extension header
   structures to be defined by the experiment could look like

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    MSER-Segment (128 bit IPv6 address)                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  MRH Sub-Type .         MRH Sub-Type specific data            |
       +.+.+.+.+.+.+.+.+                                              //
       //                         ...                                 //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                                                             //
       //         Optional Type Length Value (TLV) objects (variable) //
       //                                                             //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 1: MRH format

   The actual "Multicast Routing Header" is identified by one "Routing
   Type" value.  If multiple encodings ("MRH Sub-Type") are required,
   then multiple "Routing Types" would need to be assigned (for
   experimentation only two are available), or instad, a new "MRH Sub-
   Type" demultiplexer field could be defined.  With a worst-case small
   number of different MRH Sub-Types of maybe <=5 required, it may be
   deemed appropriate by 6MAN-WG to allocate up to e.g.: four Routing
   Types before requiring a Sub-Type encoding to avoid Routing Type
   exhaustion.

   "Segments Left" was defined by [RFC8200].  It may not actually be
   useful in all encodings, so one of the experimentation question is
   whether it would be acceptable to avoid wasting this space if it is
   not needed, or to reuse it for a more appropriate purpose.






Eckert, et al.           Expires 22 January 2026               [Page 13]

Internet-Draft               mrh-experiment                    July 2025


   The "MSER-Segment" ("Multicast Source Exit Router Segment") can carry
   the IPv6 multicast packets destination address.  This is necessary
   when an MRH is to be used to carry an actual IPv6 Multicast packet.
   Alternatively, this MSER-Segment can carry a non-IPv6 multicast group
   range IPv6 address.  In this case it is a group-SID, indicating for
   example programmability parameters to the receivers.

   When deploying MRH with BIER-like overlays, the MSER Segment may not
   be required.  If one wanted to avoid wasting those 128 bits for such
   use-cases, then appropriate encoding options should be found
   (different Routing Type).  However, one of the big benefits for IPv6
   from using MRH (as opposed to a BIER header) could come from the
   ability to always have this destination IPv6 address present in a
   fixed location in the IPv6 (extended) header to trigger various
   collateral forwarding plane functions, as mentioned elsewhere in this
   document.  Therefore, the functional (not performance) preference
   would be to always include this field.  Likewise, in many
   applications a "shared IPv6 SID" for all receivers of the packet
   seems likely very useful, even if its semantic is not that of an IPv6
   multicast group address.

   The "MRH Sub-Type specific data" if present may carry the encoding
   for a particular method of stateless IPv6 multicast forwarding

6.2.  BIER MRH Sub-Type format

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  BSL  |       SD      |       SI      |OAM| Entropy           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                BitString  (first 32 bits)                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                BitString  (last 32 bits)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: BIER MRH Sub-Type format

   Figure 2 is an example initial proposal for encoding of BIER (and
   BIER-TE, [RFC9262]) into an MRH Sub-Type.

   Most of the signaling elements of the [RFC8296] BIER header are not
   required:






Eckert, et al.           Expires 22 January 2026               [Page 14]

Internet-Draft               mrh-experiment                    July 2025


   BFIR-id is not required because in an IPv6 environment, the IPv6
   (base) header IPv6 source address (which can be a SID) serves the
   same purpose.

   If necessary to maintain existing signaling for 16-bit BFR-ID values,
   then an appropriate SID format for the 128 bit address with such a 16
   bit field can be specified.

   Likewise, TTL, DSCP and Ver fields are not required as they already
   exist in the IPv6 header.

   The Proto field is not required, because the "Next Header" field in
   the MRH serves the same purpose.

   Nibble, TC and S fields are not required because they are artefacts
   of the BIER header for MPLS.

   The remaining signaling elements keep their existing semantic but are
   slightly different encoded:

   [I-D.ietf-bier-non-mpls-bift-encoding] proposes to encode BSL, SD and
   SI into the BIFT-id field.  This proposal picks up the same encoding,
   eliminating therefore also the separate BSL field.

   OAM is maintained unchanged.  BitString is maintained unchanged.

   Entropy is shortened to allow fitting the non-bitstring signaling
   elements into 32 bits. 1024 different path options are more than
   enough, so no functional deterioration is expected.

6.3.  Further MRH Sub-Type considerations

   The encoding for other "MRH Sub-Type specific data" fields are not
   presented here.  For example, if RTS ([I-D.eckert-pim-rts-forwarding]
   was used as a Sub-Type, then that field would be encoded according to
   that drafts header, specified in [I-D.eckert-pim-rts-forwarding],
   section 4.3.

   Independent of MRH Sub-Type, the per-hop forwarding rules need to be
   specified, should be the same as IPv6 unicast source routing: Every
   hop determines for every packet copy a next-hop ipv6 next-hop
   address, which will be copied into the IPv6 header destination
   address field.

   Different from IPv6 unicast, the different MRH Sub-Type encodings
   will require different modifications to the MRH header.  In the BIER
   Sub-Type case for example, bits in the Bitstring need to be cleared.
   In headers such as RTS, it may be necessary to update two index



Eckert, et al.           Expires 22 January 2026               [Page 15]

Internet-Draft               mrh-experiment                    July 2025


   fields in the Sub-Type data to indicate to the next-hop the active
   part of the Sub-Type header that needs to be parsed.  This is
   equivalent to the Segments-Left field in IPv6 unicast routing header
   cases.

7.  Informative References

   [I-D.draft-ietf-bier-ipv6-requirements]
              McBride, M., Xie, J., Geng, X., Dhanaraj, S., Asati, R.,
              Zhu, Y., Mishra, G. S., and Z. J. Zhang, "BIER IPv6
              Requirements", Work in Progress, Internet-Draft, draft-
              ietf-bier-ipv6-requirements-09, 28 September 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              ipv6-requirements-09>.

   [I-D.eckert-msr6-problem-statement]
              Eckert, T. T., "Yet another Problem Statement for IPv6
              Multicast Source Routing (MSR6)", Work in Progress,
              Internet-Draft, draft-eckert-msr6-problem-statement-00, 24
              October 2022, <https://datatracker.ietf.org/doc/html/
              draft-eckert-msr6-problem-statement-00>.

   [I-D.eckert-msr6-rbs]
              Eckert, T. T., Geng, X., Zheng, X., Meng, R., and F. Li,
              "Recursive Bitstring Structure (RBS) for Multicast Source
              Routing over IPv6 (MSR6)", Work in Progress, Internet-
              Draft, draft-eckert-msr6-rbs-01, 24 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-eckert-msr6-
              rbs-01>.

   [I-D.eckert-pim-rts-forwarding]
              Eckert, T. T., Menth, M., Lindner, S., and Y. Liu,
              "Stateless Multicast Replication with Segment Routed
              Recursive Tree Structures (RTS)", Work in Progress,
              Internet-Draft, draft-eckert-pim-rts-forwarding-03, 6 July
              2025, <https://datatracker.ietf.org/doc/html/draft-eckert-
              pim-rts-forwarding-03>.

   [I-D.ietf-bier-bierin6]
              Zhang, Z., Zhang, Z. J., Wijnands, I., Mishra, M. P.,
              Bidgoli, H., and G. S. Mishra, "Supporting BIER in IPv6
              Networks (BIERin6)", Work in Progress, Internet-Draft,
              draft-ietf-bier-bierin6-11, 2 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              bierin6-11>.






Eckert, et al.           Expires 22 January 2026               [Page 16]

Internet-Draft               mrh-experiment                    July 2025


   [I-D.ietf-bier-lsr-non-mpls-extensions]
              Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, Z.
              J., and J. Xie, "LSR Extensions for BIER non-MPLS
              Encapsulation", Work in Progress, Internet-Draft, draft-
              ietf-bier-lsr-non-mpls-extensions-03, 7 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              lsr-non-mpls-extensions-03>.

   [I-D.ietf-bier-non-mpls-bift-encoding]
              Wijnands, I., Mishra, M. P., Xu, X., and H. Bidgoli, "An
              Optional Encoding of the BIFT-id Field in the non-MPLS
              BIER Encapsulation", Work in Progress, Internet-Draft,
              draft-ietf-bier-non-mpls-bift-encoding-04, 30 May 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
              non-mpls-bift-encoding-04>.

   [I-D.ietf-spring-srv6-srh-compression]
              Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
              Clad, "Compressed SRv6 Segment List Encoding (CSID)", Work
              in Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
              compression-23, 6 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-srh-compression-23>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/rfc/rfc2460>.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727,
              DOI 10.17487/RFC4727, November 2006,
              <https://www.rfc-editor.org/rfc/rfc4727>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6554>.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/rfc/rfc791>.

   [RFC7988]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
              Replication Tunnels in Multicast VPN", RFC 7988,
              DOI 10.17487/RFC7988, October 2016,
              <https://www.rfc-editor.org/rfc/rfc7988>.




Eckert, et al.           Expires 22 January 2026               [Page 17]

Internet-Draft               mrh-experiment                    July 2025


   [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/rfc/rfc8200>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/rfc/rfc8279>.

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/rfc/rfc8296>.

   [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/rfc/rfc8754>.

   [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/rfc/rfc8986>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8994>.

   [RFC9262]  Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
              Engineering for Bit Index Explicit Replication (BIER-TE)",
              RFC 9262, DOI 10.17487/RFC9262, October 2022,
              <https://www.rfc-editor.org/rfc/rfc9262>.

Appendix A.  Changelog

   00: addd new co-authors

   00: initial version.








Eckert, et al.           Expires 22 January 2026               [Page 18]

Internet-Draft               mrh-experiment                    July 2025


Appendix B.  History

   This document is an evolution from the process whose last draft was
   [I-D.eckert-msr6-problem-statement].  That informational draft covers
   in a more concise way two core problem areas

   1.  The Desire and need for an IPv6 routing extension header based
       solution architecture for stateless IPv6 multicast source routing
       in support of IPv6/SSRv6-only networks.  This is covered in
       P4...P7 and according explanationsj.

   2.  The desire and need for an easier to operate and better to scale
       stateless replication mechanism instad of [RFC8279], such as
       proposals like [I-D.eckert-pim-rts-forwarding] or
       [I-D.eckert-msr6-rbs].  These are covered in P1...P3,P8 and
       according explanations.

   Point 1 in that problem state document can be resolved by an IPv6
   routing extension header based solution, which is what this document
   explains in more detail and proposes to introduce through
   experimental IETF work.

   It is thus overlapping with that problem statments P4...P7.  Such an
   IPv6 routing extension header based solution can and should leverage
   both an [RFC8279] based payload, which would allow a minimal change
   and new development from existing BIER specifciations, replacing only
   [RFC8296] as the encapsulation and replacing the need for
   [I-D.ietf-bier-bierin6].

   Point 2 is not detailled in this document except to explain what
   aspects in the new IPv6 routing extension header are required to
   enable such alternative encodings compared to the existing BIER
   bitstring.

Authors' Addresses

   Toerless Eckert (editor)
   Futurewei Technologies USA
   United States of America
   Email: tte@cs.fau.de


   Yisong Liu
   China Mobile
   China
   Email: liuyisong@chinamobile.com





Eckert, et al.           Expires 22 January 2026               [Page 19]

Internet-Draft               mrh-experiment                    July 2025


   Yongqing Zhu
   China Telecom
   China
   Email: zhuyq8@chinatelecom.cn


   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com









































Eckert, et al.           Expires 22 January 2026               [Page 20]
