rfc9739.original   rfc9739.txt 
Network Working Group H. Bidgoli, Ed. Internet Engineering Task Force (IETF) H. Bidgoli, Ed.
Internet-Draft Nokia Request for Comments: 9739 Nokia
Intended status: Standards Track S. Venaas Category: Standards Track S. Venaas
Expires: 8 June 2025 Cisco System, Inc. ISSN: 2070-1721 M. Mishra
M. Mishra Cisco Systems, Inc.
Cisco System
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
M. McBride M. McBride
Futurewei Technologies Inc. Futurewei Technologies Inc.
5 December 2024 February 2025
Protocol Independent Multicast Light (PIM Light) Protocol Independent Multicast Light (PIM Light)
draft-ietf-pim-light-11
Abstract Abstract
This document specifies Protocol Independent Multicast Light (PIM This document specifies Protocol Independent Multicast Light (PIM
Light) and PIM Light Interface (PLI) which does not need PIM Hello Light) and the PIM Light Interface (PLI). A PLI does not need a PIM
message to accept PIM Join/Prune messages. PLI can signal multicast Hello message to accept PIM Join/Prune messages, and it can signal
states over networks that can not support full PIM neighbor multicast states over networks that cannot support full PIM neighbor
discovery, as an example BIER networks that are connecting two or discovery, such as Bit Index Explicit Replication (BIER) networks
more PIM domains. This document outlines the PIM Light protocol and that connect two or more PIM domains. This document outlines the PIM
procedures to ensure loop-free multicast traffic between two or more Light protocol and procedures to ensure loop-free multicast traffic
PIM Light routers. between two or more PIM Light routers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9739.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Terminology
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. PIM Light Interface
3. PIM Light Interface . . . . . . . . . . . . . . . . . . . . . 3 3.1. Message Types Supported by PIM Light
3.1. PLI supported Messages . . . . . . . . . . . . . . . . . 4 3.2. Considerations for the Absence of Hello Message
3.2. Absence of Hello Message consideration . . . . . . . . . 4 3.2.1. Join Attribute
3.2.1. Join Attribute . . . . . . . . . . . . . . . . . . . 4 3.2.2. DR Election
3.2.2. DR Election . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. PIM Assert
3.2.3. PIM Assert . . . . . . . . . . . . . . . . . . . . . 5 3.3. PLI Configuration
3.3. PLI Configuration . . . . . . . . . . . . . . . . . . . . 6 3.4. Failures in PLR Domain
3.4. Failures in PLR domain . . . . . . . . . . . . . . . . . 6 3.5. Reliable Transport Mechanism for PIM Light
3.5. Reliable Transport Mechanism for PIM LIGHT . . . . . . . 7 3.6. PIM Variants Not Supported
3.6. PIM Variants not supported . . . . . . . . . . . . . . . 7 4. IANA Considerations
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 Acknowledgments
7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document specifies the Protocol Independent Multicast Light (PIM This document specifies procedures for Protocol Independent Multicast
Light) and PIM Light Interface (PLI) procedures. PLI is a new type Light (PIM Light) and the PIM Light Interface (PLI). The PLI is a
of PIM interface that allows signaling of PIM Join/Prune packets new type of PIM interface that allows signaling of PIM Join/Prune
without full PIM neighbor discovery. PLI is useful in scenarios packets without full PIM neighbor discovery. A PLI is useful in
where multicast states needs to be signalled over networks or media scenarios where multicast states need to be signaled over networks or
that cannot support full PIM neighborship between routers or media that cannot support full PIM neighborship between routers or,
alternatively full PIM neighborship is not desired. These type of alternatively, where full PIM neighborship is not desired. These
networks or medias are addressed as a PIM Light Domain within this types of networks and media are called "PIM Light domains" within
document. Lack of full PIM neighborship will remove some PIM this document. Lack of full PIM neighborship will remove some PIM
functionality as explained in section 3.2 of this document. PIM functionality as explained in Section 3.2 of this document. PIM
Light only supports Protocol Independent Multicast Sparse Mode (PIM- Light only supports the PIM - Sparse Mode (PIM-SM) protocol,
SM) protocol including PIM Source-Specific Multicast (PIM-SSM) as per including PIM Source-Specific Multicast (PIM-SSM), as per [RFC7761].
[RFC7761]. The document details procedures and considerations needed This document details procedures and considerations needed for PIM
for PIM Light and PLI to ensure efficient routing of multicast groups Light and the PLI to ensure efficient routing of multicast groups for
for specific deployment environments. specific deployment environments.
2. Conventions used in this document 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Definitions This document uses terminology from "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)" [RFC7761].
This document uses definitions used in Protocol Independent Multicast
- Sparse Mode (PIM-SM): Protocol Specification [RFC7761]
3. PIM Light Interface 3. PIM Light Interface
RFC [RFC7761] section 4.3.1 describes the PIM neighbor discovery via Section 4.3.1 of [RFC7761] describes PIM neighbor discovery via Hello
Hello messages. In section 4.5 it describes that if a router messages. Section 4.5 of [RFC7761] notes that if a router receives a
receives a Join/Prune message from a particular IP source address and Join/Prune message from a particular IP source address and it has not
it has not seen a PIM Hello message from that source address, then seen a PIM Hello message from that source address, then the Join/
the Join/Prune message SHOULD be discarded without further Prune message SHOULD be discarded without further processing.
processing.
In certain scenarios, it is desirable to establish multicast states In certain scenarios, it is desirable to establish multicast states
between two layer-3 adjacent routers without forming a PIM between two routers without forming a PIM neighborship. This can be
neighborship. This can be necessary for various reasons, such as necessary for various reasons, such as signaling multicast states
signaling multicast states upstream between multiple PIM domains over upstream between multiple PIM domains over a network that is not
a network that is not optimized for PIM or does not necessitate PIM optimized for PIM or that does not necessitate PIM neighbor
Neighbor establishment. For example, in a Bit Index Explicit establishment. An example is a Bit Index Explicit Replication (BIER)
Replication (BIER) [RFC8279] networks connecting multiple PIM [RFC8279] network connecting multiple PIM domains, where PIM Join/
domains, where PIM Join/Prune messages are tunneled via BIER as Prune messages are tunneled via BIER as specified in [BIER-PIM].
specified in [draft-ietf-bier-pim-signaling].
A PIM Light Interface (PLI) accepts Join/Prune messages from an A PLI accepts Join/Prune messages from an unknown PIM router without
unknown PIM router without requiring a PIM Hello message from the requiring a PIM Hello message from the router. The absence of Hello
router. The absence of Hello messages on a PLI means there is no messages on a PLI means there is no mechanism to discover neighboring
mechanism to discover neighboring PIM routers or their capabilities, PIM routers or their capabilities or to execute basic algorithms such
nor to execute basic algorithms such as Designated Router (DR) as Designated Router (DR) election [RFC7761]. Consequently, the PIM
election [RFC7761]. Consequently, the PIM Light router does not Light router does not create any general-purpose state for
create any general-purpose state for neighboring PIM routers and only neighboring PIM routers and only processes Join/Prune messages from
processes Join/Prune messages from downstream routers in its downstream routers in its multicast routing table. Processing these
multicast routing table. Processing these Join/Prune messages will Join/Prune messages will introduce multicast states in a PIM Light
introduce multicast states in a PIM Light router. router.
Due to these constraints, a PLI should be deployed in very specific Due to these constraints, a PLI should be deployed in very specific
scenarios where PIM-SM is not suitable. The applications or the scenarios where PIM-SM is not suitable. The applications or the
networks that PLIs are deployed on MUST ensure there is no multicast networks on which PLIs are deployed MUST ensure that there is no
packet duplication, such as multiple upstream routers sending the multicast packet duplication, such as multiple upstream routers
same multicast stream to a single downstream router. As an example sending the same multicast stream to a single downstream router. For
the implementation should ensure that DR election is done on upstream example, an implementation should ensure that DR election is done on
Redundant PIM routers that are at the edge of the PIM Light Domain to upstream redundant PIM routers that are at the edge of the PIM Light
ensure a single Designated Router to forward the PIM Join message domain to ensure that a single DR forwards the PIM Join message from
from reviver to the Source. the receiver to the source.
3.1. PLI supported Messages 3.1. Message Types Supported by PIM Light
IANA [iana_pim-parameters_message-types], lists the PIM supported The "PIM Message Types" registry [IANA-PIM-Mess-Types] lists the
message types. PIM Light only supports the following message types message types supported by PIM. PIM Light only supports the
from the table "PIM Message Types" following message types in that registry:
1. type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed * type 1 (Register)
in [RFC7761].
2. type 1 (Register) * type 2 (Register Stop)
3. type 2 (Register Stop) * type 3 (Join/Prune)
4. type 8 (Candidate RP Advertisement) * type 8 (Candidate RP Advertisement)
5. type 13 (PIM Packed Null-Register) * type 13.0 (PIM Packed Null-Register)
6. type 13.1 (PIM Packed Register-Stop) * type 13.1 (PIM Packed Register-Stop)
7. Any future PIM message types that use unicast destination IP. * Any future PIM message types where the destination is a unicast IP
address
No other message types are supported for PIM Light and MUST NOT be No other message types are supported by PIM Light; other message
process if received on a PLI. types MUST NOT be processed if received on a PLI.
3.2. Absence of Hello Message consideration 3.2. Considerations for the Absence of Hello Message
In a PIM Light domain, the following considerations should be taken Because Hello messages are not processed in a PIM Light domain, the
into account due to the lack of processing Hello messages. considerations in the subsections below should be taken into account.
3.2.1. Join Attribute 3.2.1. Join Attribute
Since a PLI does not process PIM Hello messages, it also does not Since a PLI does not use PIM Hello messages, it also does not support
support the join attributes option in PIM Hello as specified in the Join Attribute option in PIM Hello as specified in [RFC5384]. As
[RFC5384]. As such, PIM Light is unaware of its neighbor's such, PIM Light is unaware of its neighbor's capability to process
capability to process join attributes and it SHOULD NOT process a Join Attributes and SHOULD NOT send a Join message containing a Join
join message containing it. Attribute.
For a PLI to send and process a join attributes there can be two There are two cases in which a PLI can support a Join Attribute:
cases:
1. It must be configured with appropriate join attribute type that * The neighbors on the PLI are known via configuration to be capable
the PLI is capable of processing as per of processing the attribute.
[iana_pim-parameters_join-attribute-types] table.
2. Separate IETF drafts or RFCs may dictate that certain join * Internet-Drafts and RFCs may dictate that certain Join Attributes
attributes are allowed to be used without explicit configuration are allowed to be used without explicit configuration of the PLI
of the PLI in certain scenarios. The details are left to those in certain scenarios. The details are left to those Internet-
drafts or RFCs. Drafts and RFCs.
3.2.2. DR Election 3.2.2. DR Election
Due to the absence of Hello messages, DR Election is not supported on Due to the absence of Hello messages, DR election is not supported on
a PIM Light router. The network design must ensure DR Election a PIM Light router. The network design must ensure DR election
occurs within the PIM domain, assuming the PIM Light domain occurs within the PIM domain, assuming the PIM Light domain
interconnects PIM domains. interconnects PIM domains.
Bier edge router Bier edge router (BER) For instance, in a BIER domain connecting two PIM domains as in the
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| figure below, a PLI can be used between BIER edge routers solely for
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host 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 [RFC7761] 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 | | PIM Adj| | | |PIM Adj |
|------------( E )-------| |-------( F )------------| |------------( E )-------| |-------( F )------------|
(DR Election) (DR election)
For instance, in a BIER domain connecting two PIM networks, 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, to prevent
multicast stream duplication, they MUST establish PIM adjacency as
per [RFC7761] to ensure DR election at the edge of BIER domain. An
example DR election could be DR election between router D and F in
above figure. When the Join or Prune message arrives from a PIM
domain to the down stream BIER edge router, it can be forwarded over
the BIER tunnel to the upstream BIER edge router only via the
designated router.
3.2.3. PIM Assert 3.2.3. PIM Assert
In scenarios where multiple PIM routers peer over a shared LAN or a In scenarios where multiple PIM routers peer over a shared LAN or a
Point-to-Multipoint medium, more than one upstream router may have point-to-multipoint medium, more than one upstream router may have
valid forwarding state for a packet, potentially causing packet valid forwarding state for a packet, which can potentially cause
duplication. PIM Assert is used to select a single transmitter when packet duplication. PIM Assert is used to select a single
such duplication is detected. According to [RFC7761] section 4.6, transmitter when such duplication is detected. According to
PIM Assert should only be accepted from a known PIM neighbor. Section 4.6 of [RFC7761], PIM Assert should only be accepted from a
known PIM neighbor.
In PIM Light implementations, care must be taken to avoid duplicate In PIM Light implementations, care must be taken to avoid duplicate
streams arriving from multiple upstream PIM Light routers to a single streams arriving from multiple upstream PIM Light routers to a single
downstream PIM Light router. If network design constraints prevent downstream PIM Light router. If network design constraints prevent
this, the implemented network architecture must take measures to this, the implemented network architecture must take measures to
avoid traffic duplication. For example, in a PIM Light over a BIER avoid traffic duplication. For example, in a scenario with PIM Light
domain scenario, downstream IBBR (Ingress BIER Border Router) in a over a BIER domain, a downstream IBBR (Ingress BIER Border Router) in
BIER domain can identify the nearest EBBRs (Egress BIER Border a BIER domain can identify the nearest EBBRs (Egress BIER Border
Routers) to the source using the Shortest Path First (SPF) algorithm Routers) to the source using the Shortest Path First (SPF) algorithm
with a post-processing as described in with post-processing as described in Appendix A.1 of [BIER-PIM]. If
[draft-ietf-bier-pim-signaling] Appendix A.1. If the downstream IBBR the downstream IBBR identifies two EBBRs, it can select one using a
identifies two EBBRs, it can select one using a unique IP selection unique IP selection algorithm, such as choosing the EBBR with the
algorithm, such as choosing the EBBR with the lowest or highest IP lowest or highest IP address. If the selected EBBR goes offline, the
address. If the selected EBBR goes offline, the downstream router downstream router can use the next EBBR based on the IP selection
can use the next EBBR based on the IP selection algorithm, which is algorithm, which is beyond the scope of this document.
beyond the scope of this document.
3.3. PLI Configuration 3.3. PLI Configuration
Since a PLI doesn't require PIM Hello Messages and PIM neighbor Since a PLI doesn't require PIM Hello Messages and PIM neighbor
adjacency is not checked for arriving Join/Prune messages, there adjacency is not checked for arriving Join/Prune messages, there
needs to be a mechanism to enable PLI on interfaces. If a router needs to be a mechanism to enable PLIs on interfaces. Join/Prune
supports PIM Light, only when PLI is enabled on an interface, messages not received from a PIM neighbor MUST be dropped unless PLI
arriving Join/Prune messages MUST be processed, otherwise they MUST is enabled on the interface. In some cases, a PLI may be enabled
be dropped. While on some logical interfaces PLI maybe enabled automatically via an underlying mechanism on a logical interface.
automatically or via an underlying mechanism, as an example the For example, in a BIER domain, a logical interface can connect two or
logical interface connecting two or more BIER edge routers in a BIER more BIER edge routers as per [BIER-PIM]).
subdomain [draft-ietf-bier-pim-signaling].
3.4. Failures in PLR domain 3.4. Failures in PLR Domain
Because the Hello messages are not processed on the PLI, PIM Light Because Hello messages are not processed on the PLI, PLI failures may
Interface failures may not be discovered in a PIM Light domain and not be discovered in a PIM Light domain, and multicast routes will
multicast routes will not be pruned toward the source on the PIM not be pruned toward the source on the PIM Light domain. This
Light domain, leaving the upstream routers continuously sending results in the upstream routers continuously sending multicast
multicast streams until the outgoing interface (OIF) expires. streams until the outgoing interface (OIF) expires.
Other protocols can be used to detect these failures in the PIM Light Other protocols can be used to detect these failures in the PIM Light
domain and they can be implementation specific. As an example, the domain, and they can be implementation specific. As an example, the
interface that PIM Light is configured on can be protected via interface on which PIM Light is configured can be protected via
Bidirectional Forwarding Detection (BFD) or similar technology. If Bidirectional Forwarding Detection (BFD) or similar technology. If
BFD to the far-end PLI goes down, and the PIM Light Router is BFD to the far-end PLI goes down and the PIM Light router is upstream
upstream and has an OIF for a multicast route <S,G>, PIM must remove and has an OIF for a multicast route (S,G), PIM must remove that PLI
that PLI from its OIF list. from its OIF list.
UBER DBER In another example, the PLI is configured automatically between the
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| BIER Edge Routers (BERs) as in the figure below. When the Downstream
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host BIER Edge Router (DBER) is no longer reachable on the Upstream BIER
<--Prune <S,G> <failure on D> 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.
In another example, where the PLI is configured automatically between UBER DBER
the BIER Edge Routers (BER), when the downstream BIER Edge Router |--PIM domain--|--BIER domain (PLI)--|--PIM domain--|
(DBER) is no longer reachable on the upstream BIER Edge Router Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
(UBER), the UBER which is also a PIM Light Router can prune the <S,G> <--Prune (S,G) <failure on D>
advertised toward the source on the PIM domain to stop the
transmission of the multicast stream.
3.5. Reliable Transport Mechanism for PIM LIGHT 3.5. Reliable Transport Mechanism for PIM Light
[RFC6559] defines a reliable transport mechanism for PIM transmission [RFC6559] defines a reliable transport mechanism called PIM Over
of Join/Prune messages, using either TCP or SCTP as transport Reliable Transport (PORT) for PIM transmission of Join/Prune
protocol. For TCP, PIM over reliable transport (PORT) uses port 8471 messages, using either TCP or SCTP as the transport protocol. Both
which is assigned by IANA. SCTP is explained in [RFC9260], and it is TCP and SCTP use destination port number 8471. SCTP is explained in
used as a second option for PORT. [RFC6559] mentions that when a [RFC9260] and is used as a second option for PORT. [RFC6559]
router is configured to use PIM over TCP on a given interface, it mentions that when a router is configured to use PIM over TCP on a
MUST include the PIM-over-TCP-Capable Hello Option in its Hello given interface, it MUST include the PIM-over-TCP-Capable Hello
messages for that interface. The same is true for SCTP and the Option in its Hello messages for that interface. The same is true
router must include PIM-over-SCTP-Capable Hello Option in its Hello for SCTP; the router MUST include the PIM-over-SCTP-Capable Hello
messsage on that interface. Option in its Hello messages on that interface.
These Hello options contain a Connection ID which is an IPv4 or IPv6 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 address used to establish the SCTP or TCP connection. For PORT using
TCP, the connection ID is used for determining which peer is doing an 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 active transport open to the neighbor and which peer is doing passive
transport open, as per section 4 of [RFC6559] transport open, as per Section 4 of [RFC6559]. When the router is
using SCTP, the Connection ID is not used to determine the active and
When the router is using SCTP, the Connection ID IP address passive peer since SCTP can handle call collision.
comparison need not be done since the SCTP protocol can handle call
collision.
PIM Light lacks Hello messages, the PLI can be configured with the Because PIM Light lacks Hello messages, the PLI can be configured
Connection ID IPv4 or IPv6 addresses used to establish the SCTP or with the Connection ID (i.e., the IPv4 or IPv6 address used to
TCP connection. For PIM Light using TCP PORT option each end of the establish the SCTP or TCP connection). For PIM Light using the TCP
PLI must be explicitly and correct configured as being active PORT option, each end of the PLI must be explicitly and correctly
transport open or passive transport open to ensure handle call configured as being either active transport open or passive transport
collision is avoided. open to ensure that call collision is avoided.
3.6. PIM Variants not supported 3.6. PIM Variants Not Supported
The following PIM variants are not supported with PIM Light and not The following PIM variants are not supported with PIM Light and not
covered by this document: covered by this document:
1. Protocol Independent Multicast - Dense Mode (PIM-DM)[RFC3973] * PIM - Dense Mode (PIM-DM) [RFC3973]
2. Bidirectional Protocol Independent Multicast (BIDIR-PIM) * Bidirectional PIM (BIDIR-PIM) [RFC5015]
[RFC5015]
4. IANA Considerations 4. IANA Considerations
There are no new IANA considerations for this document. This document has no IANA actions.
5. Security Considerations 5. Security Considerations
Since PIM Light does not require PIM Hello messages and does not Since PIM Light does not require PIM Hello messages and does not
verify PIM neighbor adjacency for incoming Join/Prune messages, it is verify PIM neighbor adjacency for incoming Join/Prune messages, for
crucial for security reasons, that the implementation ensures only security reasons, it is crucial that implementations ensure that only
Join/Prune messages arriving at a configured PLI are processed. Any Join/Prune messages arriving at a configured PLI are processed. Any
Join/Prune messages received on an interface that is not configured Join/Prune messages received on an interface that is not configured
as a PLI MUST be discarded and not processed. Additionally, as a as a PLI MUST be discarded and not processed. Additionally, as a
secondary line of defense, route policies SHOULD be implemented to secondary line of defense, route policies SHOULD be implemented to
process only the Join/Prune messages associated with the desired process only the Join/Prune messages associated with the desired
(S,G) pairs, while all other (S,G) pairs MUST be discarded and not (S,G) pairs, while all other (S,G) pairs MUST be discarded and not
processed. processed.
Furthermore, because PIM Light can be used for signaling Source- Furthermore, because PIM Light can be used for signaling PIM-SM Join/
Specific and Sparse Mode Join/Prune messages, the security Prune messages, the security considerations outlined in [RFC7761] and
considerations outlined in [RFC7761] and [RFC4607] SHOULD be [RFC4607] SHOULD be considered where appropriate.
considered where appropriate.
In section 6.1.1 of [RFC7761], only forged join/prune message should
be considered as a potential attack vector, as PIM Light does not
process Hello or Assert messages. In addition, as detailed in
Section 6.3, the authentication mechanisms described in [RFC5796] can
be applied to PIM Light via IPsec Encapsulating Security Payload
(ESP) or, optionally, the Authentication Header (AH).
6. Acknowledgments Per Section 6.1.1 of [RFC7761], 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
Section 6.3 of [RFC7761], the authentication mechanisms described in
[RFC5796] can be applied to PIM Light via IPsec Encapsulating
Security Payload (ESP) or, optionally, the Authentication Header
(AH).
Would like to thank Sandy <Zhang Zheng> and Tanmoy Kundu for their 6. References
suggestions and contribution to this document.
7. References 6.1. Normative References
7.1. Normative References [IANA-PIM-Mess-Types]
IANA, "PIM Message Types",
<https://www.iana.org/assignments/pim-parameters>.
[iana_pim-parameters_join-attribute-types] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"", January 2022, <https://www.iana.org/assignments/pim- Requirement Levels", BCP 14, RFC 2119,
parameters/pim-parameters.xhtml#pim-parameters-2>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[iana_pim-parameters_message-types] [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
"", January 2022, <https://www.iana.org/assignments/pim- IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
parameters/pim-parameters.xhtml#message-types>. <https://www.rfc-editor.org/info/rfc4607>.
[RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
Requirement Levels"", March 1997. "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[RFC4607] "H. Holbrook, B. Cain "Source-Specific Multicast for IP"". [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008,
<https://www.rfc-editor.org/info/rfc5384>.
[RFC5015] "M. Handley, I. Kouvelas, T. Speakman, L. Vicisano [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
"Bidirectional Protocol Independent Multicast"". Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796,
DOI 10.17487/RFC5796, March 2010,
<https://www.rfc-editor.org/info/rfc5796>.
[RFC5384] "A. Boers, I. Wijnands, E. Rosen "PIM Join Attribute [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M.
Format"", March 2016. Napierala, "A Reliable Transport Mechanism for PIM",
RFC 6559, DOI 10.17487/RFC6559, March 2012,
<https://www.rfc-editor.org/info/rfc6559>.
[RFC5796] "W. Atwood, S. Islam, M. Siami "Authentication and [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Confidentiality in PIM-SM"". Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC6559] "D. Farinacci, I. Wijnands, S. Venaas, M. Napierala "A [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
reliable Transport Mechanism for PIM"". 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7761] "B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh, [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Z.Zhang "PIM Sparse Mode"", March 2016. 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/info/rfc8279>.
[RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC [RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
2119 Key Words"", May 2017. Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC8279] "Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. 6.2. Informative References
and S. Aldrin, "Multicast using Bit Index Explicit
Replication"", October 2016.
[RFC9260] "R. Stewart, M. Tuxen, K. Nielsen, "Stream Control [BIER-PIM] Bidgoli, H., Ed., Xu, F., Kotalwar, J., Wijnands, I.,
Transmission Protocol"", June 2022. Mishra, M., and Z. Zhang, "PIM Signaling Through BIER
Core", Work in Progress, Internet-Draft, draft-ietf-bier-
pim-signaling-12, 25 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
pim-signaling-12>.
7.2. Informative References [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[draft-ietf-bier-pim-signaling] Acknowledgments
"H.Bidgoli, F.XU, J. Kotalwar, I. Wijnands, M.Mishra, Z.
Zhang, "PIM Signaling Through BIER Core"", July 2021.
[RFC3973] "A. Adams, J. Nicholas, W. Siadak, "Protocol Independent The authors would like to thank Zheng (Sandy) Zhang and Tanmoy Kundu
Multicast - Dense Mode"". for their suggestions and contributions to this document.
Authors' Addresses Authors' Addresses
Hooman Bidgoli (editor) Hooman Bidgoli (editor)
Nokia Nokia
March Road March Road
Ottawa Ontario K2K 2T6 Ottawa Ontario K2K 2T6
Canada Canada
Email: hooman.bidgoli@nokia.com Email: hooman.bidgoli@nokia.com
Stig Venaas Stig Venaas
Cisco System, Inc. Cisco Systems, Inc.
Tasman Drive Tasman Drive
San Jose, California 95134 San Jose, CA 95134
United States of America United States of America
Email: stig@cisco.com Email: stig@cisco.com
Mankamana Mishra Mankamana Mishra
Cisco System Cisco Systems, Inc.
Tasman Drive Tasman Drive
San Jose, California 95134 San Jose, CA 95134
United States of America United States of America
Email: mankamis@cisco.com Email: mankamis@cisco.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
Boston, Boston, MA
United States of America United States of America
Email: zzhang@juniper.com Email: zzhang@juniper.net
Mike McBride Mike McBride
Futurewei Technologies Inc. Futurewei Technologies Inc.
Santa Clara, Santa Clara, CA
United States of America United States of America
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
 End of changes. 86 change blocks. 
286 lines changed or deleted 293 lines changed or added

This html diff was produced by rfcdiff 1.48.