Nokia

March Road Ottawa Ontario K2K 2T6 Canada hooman.bidgoli@nokia.com

Cisco Systems, Inc.

Tasman Drive San Jose CA 95134 United States of America stig@cisco.com

Cisco Systems, Inc.

Tasman Drive San Jose CA 95134 United States of America mankamis@cisco.com

Juniper Networks

Boston MA United States of America zzhang@juniper.net

Futurewei Technologies Inc.

Santa Clara CA United States of America michael.mcbride@futurewei.com

RTG pim This document specifies Protocol Independent Multicast Light (PIM Light) and the PIM Light Interface (PLI). A PLI does not need a PIM Hello message to accept PIM Join/Prune messages, and it can signal multicast states over networks that cannot support full PIM neighbor discovery, such as Bit Index Explicit Replication (BIER) networks that connect two or more PIM domains. This document outlines the PIM Light protocol and procedures to ensure loop-free multicast traffic between two or more PIM Light routers.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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 () 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

• .  Introduction
• .  Terminology
• .  PIM Light Interface
  • .  Message Types Supported by PIM Light
  • .  Considerations for the Absence of Hello Message
    • .  Join Attribute
    • .  DR Election
    • .  PIM Assert
  • .  PLI Configuration
  • .  Failures in PLR Domain
  • .  Reliable Transport Mechanism for PIM Light
  • .  PIM Variants Not Supported
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction This document specifies procedures for Protocol Independent Multicast Light (PIM Light) and the PIM Light Interface (PLI). The PLI is a new type of PIM interface that allows signaling of PIM Join/Prune packets without full PIM neighbor discovery. A PLI is useful in scenarios where multicast states need to be signaled over networks or media that cannot support full PIM neighborship between routers or, alternatively, where full PIM neighborship is not desired. These types of networks and media are called "PIM Light domains" within this document. Lack of full PIM neighborship will remove some PIM functionality as explained in of this document. PIM Light only supports the PIM - Sparse Mode (PIM-SM) protocol, including PIM Source-Specific Multicast (PIM-SSM), as per . This document details procedures and considerations needed for PIM Light and the PLI to ensure efficient routing of multicast groups for specific deployment environments.

Terminology 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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)" .

PIM Light Interface describes PIM neighbor discovery via Hello messages. notes that if a router receives a Join/Prune message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Join/Prune message SHOULD be discarded without further processing. In certain scenarios, it is desirable to establish multicast states between two routers without forming a PIM neighborship. This can be necessary for various reasons, such as signaling multicast states upstream between multiple PIM domains over a network that is not optimized for PIM or that does not necessitate PIM neighbor establishment. An example is a Bit Index Explicit Replication (BIER) network connecting multiple PIM domains, where PIM Join/Prune messages are tunneled via BIER as specified in . A PLI accepts Join/Prune messages from an unknown PIM router without requiring a PIM Hello message from the router. The absence of Hello messages on a PLI means there is no mechanism to discover neighboring PIM routers or their capabilities or to execute basic algorithms such as Designated Router (DR) election . Consequently, the PIM Light router does not create any general-purpose state for neighboring PIM routers and only processes Join/Prune messages from downstream routers in its multicast routing table. Processing these Join/Prune messages will introduce multicast states in a PIM Light router. Due to these constraints, a PLI should be deployed in very specific scenarios where PIM-SM is not suitable. The applications or the networks on which PLIs are deployed MUST ensure that there is no multicast packet duplication, such as multiple upstream routers sending the same multicast stream to a single downstream router. For example, an implementation should ensure that DR election is done on upstream redundant PIM routers that are at the edge of the PIM Light domain to ensure that a single DR forwards the PIM Join message from the receiver to the source.

Message Types Supported by PIM Light The "PIM Message Types" registry lists the message types supported by PIM. PIM Light only supports the following message types in that registry:

• type 1 (Register)
• type 2 (Register Stop)
• type 3 (Join/Prune)
• type 8 (Candidate RP Advertisement)
• type 13.0 (PIM Packed Null-Register)
• type 13.1 (PIM Packed Register-Stop)
• Any future PIM message types where the destination is a unicast IP address

No other message types are supported by PIM Light; other message types MUST NOT be processed if received on a PLI.

Considerations for the Absence of Hello Message Because Hello messages are not processed in a PIM Light domain, the considerations in the subsections below should be taken into account.

Join Attribute Since a PLI does not use PIM Hello messages, it also does not support the Join Attribute option in PIM Hello as specified in . As such, PIM Light is unaware of its neighbor's capability to process Join Attributes and SHOULD NOT send a Join message containing a Join Attribute. There are two cases in which a PLI can support a Join Attribute:

• The neighbors on the PLI are known via configuration to be capable of processing the attribute.
• Internet-Drafts and RFCs may dictate that certain Join Attributes are allowed to be used without explicit configuration of the PLI in certain scenarios. The details are left to those Internet-Drafts and RFCs.

DR Election Due to the absence of Hello messages, DR election is not supported on a PIM Light router. The network design must ensure DR election occurs within the PIM domain, assuming the PIM Light domain interconnects PIM domains. For instance, in a BIER domain connecting two PIM domains as in the figure below, a PLI can be used between BIER edge routers solely for multicast state communication and transmit only PIM Join/Prune messages. If there are redundant PIM routers at the edge of the BIER domain, they MUST establish PIM adjacency as per to prevent multicast stream duplication and to ensure DR election at the edge of the BIER domain. For example, DR election could be between router D and F in the figure below. When the Join or Prune message arrives from a PIM domain to the downstream BIER edge router, it can be forwarded over the BIER tunnel to the upstream BIER edge router only via the DR. Bier edge router Bier edge router |--PIM domain--|--BIER domain (PLI)--|--PIM domain--| Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host | PIM Adj| | | |PIM Adj | |------------( E )-------| |-------( F )------------| (DR election)

PIM Assert In scenarios where multiple PIM routers peer over a shared LAN or a point-to-multipoint medium, more than one upstream router may have valid forwarding state for a packet, which can potentially cause packet duplication. PIM Assert is used to select a single transmitter when such duplication is detected. According to , PIM Assert should only be accepted from a known PIM neighbor. In PIM Light implementations, care must be taken to avoid duplicate streams arriving from multiple upstream PIM Light routers to a single downstream PIM Light router. If network design constraints prevent this, the implemented network architecture must take measures to avoid traffic duplication. For example, in a scenario with PIM Light over a BIER domain, a downstream IBBR (Ingress BIER Border Router) in a BIER domain can identify the nearest EBBRs (Egress BIER Border Routers) to the source using the Shortest Path First (SPF) algorithm with post-processing as described in Appendix A.1 of . If the downstream IBBR identifies two EBBRs, it can select one using a unique IP selection algorithm, such as choosing the EBBR with the lowest or highest IP address. If the selected EBBR goes offline, the downstream router can use the next EBBR based on the IP selection algorithm, which is beyond the scope of this document.

PLI Configuration Since a PLI doesn't require PIM Hello Messages and PIM neighbor adjacency is not checked for arriving Join/Prune messages, there needs to be a mechanism to enable PLIs on interfaces. Join/Prune messages not received from a PIM neighbor MUST be dropped unless PLI is enabled on the interface. In some cases, a PLI may be enabled automatically via an underlying mechanism on a logical interface. For example, in a BIER domain, a logical interface can connect two or more BIER edge routers as per .

Failures in PLR Domain Because Hello messages are not processed on the PLI, PLI failures may not be discovered in a PIM Light domain, and multicast routes will not be pruned toward the source on the PIM Light domain. This results in the upstream routers continuously sending multicast streams until the outgoing interface (OIF) expires. Other protocols can be used to detect these failures in the PIM Light domain, and they can be implementation specific. As an example, the interface on which PIM Light is configured can be protected via Bidirectional Forwarding Detection (BFD) or similar technology. If BFD to the far-end PLI goes down and the PIM Light router is upstream and has an OIF for a multicast route (S,G), PIM must remove that PLI from its OIF list. In another example, the PLI is configured automatically between the BIER Edge Routers (BERs) as in the figure below. When the Downstream BIER Edge Router (DBER) is no longer reachable on the Upstream BIER Edge Router (UBER), the UBER (which is also a PIM Light router) can prune the (S,G) advertised toward the source on the PIM domain to stop the transmission of the multicast stream. UBER DBER |--PIM domain--|--BIER domain (PLI)--|--PIM domain--| Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host <--Prune (S,G) <failure on D>

Reliable Transport Mechanism for PIM Light defines a reliable transport mechanism called PIM Over Reliable Transport (PORT) for PIM transmission of Join/Prune messages, using either TCP or SCTP as the transport protocol. Both TCP and SCTP use destination port number 8471. SCTP is explained in and is used as a second option for PORT. mentions that when a router is configured to use PIM over TCP on a given interface, it MUST include the PIM-over-TCP-Capable Hello Option in its Hello messages for that interface. The same is true for SCTP; the router MUST include the PIM-over-SCTP-Capable Hello Option in its Hello messages on that interface. These Hello options contain a Connection ID, which is an IPv4 or IPv6 address used to establish the SCTP or TCP connection. For PORT using TCP, the Connection ID is used to determine which peer is doing an active transport open to the neighbor and which peer is doing passive transport open, as per . When the router is using SCTP, the Connection ID is not used to determine the active and passive peer since SCTP can handle call collision. Because PIM Light lacks Hello messages, the PLI can be configured with the Connection ID (i.e., the IPv4 or IPv6 address used to establish the SCTP or TCP connection). For PIM Light using the TCP PORT option, each end of the PLI must be explicitly and correctly configured as being either active transport open or passive transport open to ensure that call collision is avoided.

PIM Variants Not Supported The following PIM variants are not supported with PIM Light and not covered by this document:

• PIM - Dense Mode (PIM-DM)
• Bidirectional PIM (BIDIR-PIM)

IANA Considerations This document has no IANA actions.

Security Considerations Since PIM Light does not require PIM Hello messages and does not verify PIM neighbor adjacency for incoming Join/Prune messages, for security reasons, it is crucial that implementations ensure that only Join/Prune messages arriving at a configured PLI are processed. Any Join/Prune messages received on an interface that is not configured as a PLI MUST be discarded and not processed. Additionally, as a secondary line of defense, route policies SHOULD be implemented to process only the Join/Prune messages associated with the desired (S,G) pairs, while all other (S,G) pairs MUST be discarded and not processed. Furthermore, because PIM Light can be used for signaling PIM-SM Join/Prune messages, the security considerations outlined in and SHOULD be considered where appropriate. Per , only forged Join/Prune messages should be considered as a potential attack vector, as PIM Light does not process Hello or Assert messages. In addition, as detailed in , the authentication mechanisms described in can be applied to PIM Light via IPsec Encapsulating Security Payload (ESP) or, optionally, the Authentication Header (AH).

References Normative References IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK] A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK] RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK] This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. This document defines an Experimental Protocol for the Internet community. This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users: The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Informative References Nokia Verizon Nokia Cisco System Cisco System Juniper Networks Work in Progress This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.

Acknowledgments The authors would like to thank and for their suggestions and contributions to this document.

Authors' Addresses Nokia

March Road Ottawa Ontario K2K 2T6 Canada hooman.bidgoli@nokia.com

Cisco Systems, Inc.

Tasman Drive San Jose CA 95134 United States of America stig@cisco.com

Cisco Systems, Inc.

Tasman Drive San Jose CA 95134 United States of America mankamis@cisco.com

Juniper Networks

Boston MA United States of America zzhang@juniper.net

Futurewei Technologies Inc.

Santa Clara CA United States of America michael.mcbride@futurewei.com