Internet Engineering Task Force (IETF) H. Bidgoli, Ed.
Request for Comments: 9739 Nokia
Category: Standards Track S. Venaas
ISSN: 2070-1721 M. Mishra
Cisco Systems, Inc.
Z. Zhang
Juniper Networks
M. McBride
Futurewei Technologies Inc.
March 2025
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.
このドキュメントは、プロトコル独立したマルチキャストライト（PIMライト）とPIMライトインターフェイス（PLI）を指定しています。PLIは、PIM結合/プルーンメッセージを受け入れるためにPIM Helloメッセージを必要としません。また、2つ以上のPIMドメインを接続するBITインデックス明示的複製（BIER）ネットワークなど、完全なPIMネイバーディスカバリーをサポートできないネットワークでマルチキャスト状態を信号することができます。このドキュメントでは、PIMライトプロトコルと手順の概要を説明して、2つ以上のPIMライトルーター間のループフリーのマルチキャストトラフィックを確保しています。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9739で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. PIM Light Interface
3.1. Message Types Supported by PIM Light
3.2. Considerations for the Absence of Hello Message
3.2.1. Join Attribute
3.2.2. DR Election
3.2.3. PIM Assert
3.3. PLI Configuration
3.4. Failures in PLR Domain
3.5. Reliable Transport Mechanism for PIM Light
3.6. PIM Variants Not Supported
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
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 Section 3.2 of this document. PIM Light only supports the PIM - Sparse Mode (PIM-SM) protocol, including PIM Source-Specific Multicast (PIM-SSM), as per [RFC7761]. This document details procedures and considerations needed for PIM Light and the PLI to ensure efficient routing of multicast groups for specific deployment environments.
このドキュメントは、プロトコルに依存しないマルチキャストライト（PIMライト）とPIMライトインターフェイス（PLI）の手順を指定します。PLIは、完全なPIMネイバーディスカバリーなしでPIM結合/プルーンパケットのシグナル伝達を可能にする新しいタイプのPIMインターフェイスです。PLIは、ルーター間の完全なPIMネイバーシップをサポートできないネットワークまたはメディアでマルチキャスト状態を通知する必要があるシナリオや、完全なPIM隣接が望まれない場合に役立ちます。これらのタイプのネットワークとメディアは、このドキュメント内の「PIMライトドメイン」と呼ばれます。完全なPIMネイバーシップの欠如は、このドキュメントのセクション3.2で説明されているように、PIM機能を削除します。PIM Lightは、[RFC7761]に従って、PIMソース固有のマルチキャスト（PIM-SSM）を含むPIM-SPARSEモード（PIM-SM）プロトコルのみをサポートします。この文書は、特定の展開環境のマルチキャストグループの効率的なルーティングを確保するために、PIM LightとPLIに必要な手順と考慮事項を詳述しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses terminology from "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)" [RFC7761].
このドキュメントでは、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」[RFC7761]の用語を使用しています。
Section 4.3.1 of [RFC7761] describes PIM neighbor discovery via Hello messages. Section 4.5 of [RFC7761] 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.
[RFC7761]のセクション4.3.1は、Helloメッセージを介したPIM Neighbor Discoveryについて説明しています。[RFC7761]のセクション4.5は、ルーターが特定のIPソースアドレスから結合/プルーンメッセージを受信し、そのソースアドレスからPIM Helloメッセージが表示されていない場合、Join/ Pruneメッセージをさらに処理することなく破棄する必要があることを示しています。
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) [RFC8279] network connecting multiple PIM domains, where PIM Join/ Prune messages are tunneled via BIER as specified in [BIER-PIM].
特定のシナリオでは、PIM隣接を形成せずに2つのルーター間でマルチキャスト状態を確立することが望ましいです。これは、PIM用に最適化されていない、またはPIM隣接施設を必要としないネットワーク上の複数のPIMドメイン間の上流のマルチキャスト状態を合図するなど、さまざまな理由で必要になる場合があります。例は、[Bier-PIM]で指定されているように、PIM結合/プルーンメッセージがビアを介してトンネル化される複数のPIMドメインを接続する、少しインデックス明示的な複製（Bier）[RFC8279]ネットワークです。
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 [RFC7761]. 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.
PLIは、ルーターからのPIM Helloメッセージを必要とせずに、未知のPIMルーターからの結合メッセージを受け入れます。PLIにハローメッセージがないことは、隣接するPIMルーターまたはその機能を発見したり、指定されたルーター（DR）選挙[RFC7761]などの基本的なアルゴリズムを実行するメカニズムがないことを意味します。したがって、PIMライトルーターは、隣接するPIMルーターの汎用状態を作成せず、マルチキャストルーティングテーブルの下流ルーターからのメッセージのみがメッセージを結合/プルンします。これらの結合/プルーンメッセージを処理すると、PIMライトルーターにマルチキャスト状態が導入されます。
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.
これらの制約のため、PIM-SMが適切でない非常に特定のシナリオにPLIを展開する必要があります。PLIが展開されるアプリケーションまたはネットワークは、同じマルチキャストストリームを単一のダウンストリームルーターに送信する複数のアップストリームルーターなど、マルチキャストパケットの複製がないことを確認する必要があります。たとえば、実装では、PIMライトドメインの端にある上流の冗長PIMルーターでDR選挙が行われるようにして、単一のDRがPIM結合メッセージを受信機からソースに転送するようにします。
The "PIM Message Types" registry [IANA-PIM-Mess-Types] lists the message types supported by PIM. PIM Light only supports the following message types in that registry:
「PIMメッセージタイプ」レジストリ[IANA-PIM-Mess-Types]には、PIMでサポートされているメッセージタイプがリストされています。PIM Lightは、そのレジストリで次のメッセージタイプのみをサポートしています。
* type 1 (Register)
* タイプ1（登録）
* type 2 (Register Stop)
* タイプ2（登録停止）
* type 3 (Join/Prune)
* タイプ3（結合/プルーン）
* type 8 (Candidate RP Advertisement)
* タイプ8（候補RP広告）
* type 13.0 (PIM Packed Null-Register)
* タイプ13.0（PIMパックヌルレジスター）
* type 13.1 (PIM Packed Register-Stop)
* タイプ13.1（PIMパックレジスタストップ）
* Any future PIM message types where the destination is a unicast IP address
* 宛先がユニキャストIPアドレスである将来のPIMメッセージタイプ
No other message types are supported by PIM Light; other message types MUST NOT be processed if received on a PLI.
PIM Lightでサポートされている他のメッセージタイプはありません。PLIで受信した場合、他のメッセージタイプを処理しないでください。
Because Hello messages are not processed in a PIM Light domain, the considerations in the subsections below should be taken into account.
HelloメッセージはPIM Lightドメインで処理されていないため、以下のサブセクションの考慮事項を考慮する必要があります。
Since a PLI does not use PIM Hello messages, it also does not support the Join Attribute option in PIM Hello as specified in [RFC5384]. 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.
PLIはPIM Helloメッセージを使用していないため、[RFC5384]で指定されているように、PIM Helloの結合属性オプションもサポートしていません。そのため、PIM Lightは、結合属性を処理する隣人の能力に気付いておらず、参加属性を含むJoinメッセージを送信しないでください。
There are two cases in which a PLI can support a Join Attribute:
PLIが参加属性をサポートできる2つのケースがあります。
* The neighbors on the PLI are known via configuration to be capable of processing the attribute.
* PLIの隣人は、属性を処理できる構成を介して知られています。
* 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.
* インターネットドラフトとRFCは、特定のシナリオでPLIの明示的な構成なしに特定の結合属性を使用することが許可されることを決定する場合があります。詳細は、それらのインターネットドラフトとRFCに残されています。
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.
Helloメッセージがないため、Pim Lightルーターでは選挙博士はサポートされていません。ネットワーク設計では、PIMライトドメインがPIMドメインを相互接続すると仮定して、PIMドメイン内でDR選挙が発生するようにする必要があります。
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 [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.
たとえば、下の図のように2つのPIMドメインを接続するビアドメインでは、マルチキャスト状態通信のためにBier Edgeルーター間でPLIを使用し、PIM結合/プルーンメッセージのみを送信できます。ビアドメインの端に冗長PIMルーターがある場合、マルチキャストストリームの複製を防ぎ、ビアドメインの端での選挙を確保するために、[RFC7761]に従ってPIM隣接を確立する必要があります。たとえば、下の図の選挙博士はルーターDとFの間にある可能性があります。結合またはプルーンメッセージがPIMドメインから下流のビアエッジルーターに到着すると、Bierトンネルを介してDRを介して上流のBier Edgeルーターに転送できます。
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)
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 Section 4.6 of [RFC7761], PIM Assert should only be accepted from a known PIM neighbor.
複数のPIMルーターが共有LANまたはポイントツーマルチポイント媒体を覗き込むシナリオでは、複数の上流のルーターがパケットの有効な転送状態を持つ可能性があり、パケットの重複を引き起こす可能性があります。PIM Assertは、そのような複製が検出されたときに単一の送信機を選択するために使用されます。[RFC7761]のセクション4.6によれば、PIM Assertは既知のPIM隣接からのみ受け入れられるべきです。
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 [BIER-PIM]. 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.
PIM Lightの実装では、複数の上流のPIMライトルーターから単一の下流のPIMライトルーターに到着する重複ストリームを避けるために注意する必要があります。ネットワークの設計上の制約がこれを妨げる場合、実装されたネットワークアーキテクチャは、トラフィックの重複を避けるために対策を講じる必要があります。たとえば、Bierドメイン上のPIMライトを備えたシナリオでは、ビアドメインの下流のIBBR（イングレスビアボーダールーター）は、[Bier-Pim]の付録A.1に記載されているように、ポストプロセスに記載されているように、最短パス（SPF）アルゴリズムを使用して、最短パス（SPF）アルゴリズムを使用してソースに最も近いEBBR（出口ビア境界ルーター）を識別できます。下流のIBBRが2つのEBBRを識別する場合、最低または最高のIPアドレスを持つEBBRの選択など、一意のIP選択アルゴリズムを使用して1つを選択できます。選択したEBBRがオフラインになった場合、下流のルーターは、このドキュメントの範囲を超えたIP選択アルゴリズムに基づいて次のEBBRを使用できます。
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 [BIER-PIM].
PLIはPIM HelloメッセージとPIM Neighborの隣接順がJoin/Pruneメッセージの到着をチェックしていないため、インターフェイスでPLIを有効にするメカニズムが必要です。PLIがインターフェイスで有効になっていない限り、PIMネイバーから受信していないメッセージを削除する必要があります。場合によっては、論理インターフェイス上の基礎となるメカニズムを介してPLIが自動的に有効になる場合があります。たとえば、Bierドメインでは、論理インターフェイスは[Bier-PIM]に従って2つ以上のビアエッジルーターを接続できます。
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.
HelloメッセージはPLIで処理されないため、PLI障害はPIMライトドメインで発見されず、マルチキャストルートはPIMライトドメインのソースに向かって剪定されません。これにより、上流のルーターは、発信インターフェイス（OIF）が失効するまでマルチキャストストリームを連続的に送信します。
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.
他のプロトコルを使用して、PIMライトドメイン内のこれらの障害を検出でき、実装固有のものにすることができます。例として、PIMライトが構成されているインターフェイスは、双方向転送検出（BFD）または同様の技術を介して保護できます。ファーエンドPLIへのBFDがダウンし、PIMライトルーターが上流で、マルチキャストルート（S、G）のOIFがある場合、PIMはそのPLIをOIFリストから削除する必要があります。
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.
別の例では、下の図のように、PLIはビアエッジルーター（BERS）間で自動的に構成されます。下流のビアエッジルーター（DBER）が上流のビアエッジルーター（Uber）で到達できなくなった場合、Uber（PIMライトルーターでもあります）は、マルチキャストストリームの送信を停止するためにPIMドメインのソースに向かって宣伝された（S、G）を剪定できます。
UBER DBER
|--PIM domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
<--Prune (S,G) <failure on D>
[RFC6559] 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 [RFC9260] and is used as a second option for PORT. [RFC6559] 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.
[RFC6559]は、TCPまたはSCTPを輸送プロトコルとして使用して、Join/PruneメッセージのPIM送信用の信頼できる輸送（ポート）上のPIMと呼ばれる信頼できる輸送メカニズムを定義します。TCPとSCTPの両方が宛先ポート番号8471を使用します。SCTPは[RFC9260]で説明されており、ポートの2番目のオプションとして使用されます。[RFC6559]は、ルーターが特定のインターフェイスでTCPを介してPIMを使用するように構成されている場合、そのインターフェイスのHelloメッセージにPIM-TCP対応のHelloオプションを含める必要があることを述べています。同じことがSCTPにも当てはまります。ルーターには、そのインターフェイス上のhelloメッセージにpim-over-sctp対応のhelloオプションを含める必要があります。
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 Section 4 of [RFC6559]. 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.
これらのハローオプションには、SCTPまたはTCP接続の確立に使用されるIPv4またはIPv6アドレスである接続IDが含まれています。TCPを使用したポートの場合、接続IDを使用して、[RFC6559]のセクション4に従って、どのピアが隣接するアクティブなトランスポートを実行し、どのピアがパッシブトランスポートを開いているかを判断します。ルーターがSCTPを使用している場合、SCTPはコール衝突を処理できるため、接続IDはアクティブおよびパッシブピアを決定するために使用されません。
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 Lightにはハローメッセージがないため、PLIは接続ID（つまり、SCTPまたはTCP接続の確立に使用されるIPv4またはIPv6アドレス）で構成できます。TCPポートオプションを使用したPIMライトの場合、PLIの各端は、通話衝突が回避されるように、アクティブな輸送オープンまたはパッシブトランスポートオープンのいずれかとして明示的かつ正確に構成する必要があります。
The following PIM variants are not supported with PIM Light and not covered by this document:
次のPIMバリアントは、PIMライトでサポートされておらず、このドキュメントでカバーされていません。
* PIM - Dense Mode (PIM-DM) [RFC3973]
* PIM-濃度モード（PIM -DM）[RFC3973]
* Bidirectional PIM (BIDIR-PIM) [RFC5015]
* 双方向PIM（Bidir-PIM）[RFC5015]
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
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.
PIM LightはPIM Helloメッセージを必要とせず、着信の結合/PruneメッセージのPIM Neighbor隣接を確認しないため、セキュリティ上の理由により、実装が構成されたPLIに到達する結合/プルーンメッセージのみが処理されることを保証することが重要です。PLIとして構成されていないインターフェイスで受信/プルーンメッセージを破棄し、処理しない必要があります。さらに、二次防衛線として、ルートポリシーを実装して、目的の（s、g）ペアに関連付けられた結合/プルーンメッセージのみを処理する必要がありますが、他のすべての（s、g）ペアは破棄し、処理されない必要があります。
Furthermore, because PIM Light can be used for signaling PIM-SM Join/ Prune messages, the security considerations outlined in [RFC7761] and [RFC4607] SHOULD be considered where appropriate.
さらに、PIMライトをPIM-SM結合/プルーンメッセージのシグナリングに使用できるため、[RFC7761]および[RFC4607]で概説されているセキュリティ上の考慮事項は、必要に応じて考慮する必要があります。
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).
[RFC7761]のセクション6.1.1に従って、PIM Lightはメッセージを処理したり、メッセージをアサートしたりしないため、Forged Join/Pruneメッセージのみを潜在的な攻撃ベクトルと見なす必要があります。さらに、[RFC7761]のセクション6.3で詳述されているように、[RFC5796]に記載されている認証メカニズムは、セキュリティペイロード（ESP）をカプセル化するIPSECまたはオプションで認証ヘッダー（AH）を介してPIM光に適用できます。
[IANA-PIM-Mess-Types]
IANA, "PIM Message Types",
<https://www.iana.org/assignments/pim-parameters>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[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>.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
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>.
[RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M.
Napierala, "A Reliable Transport Mechanism for PIM",
RFC 6559, DOI 10.17487/RFC6559, March 2012,
<https://www.rfc-editor.org/info/rfc6559>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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/info/rfc8279>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[BIER-PIM] Bidgoli, H., Ed., Xu, F., Kotalwar, J., Wijnands, I.,
Mishra, M., and Z. Zhang, "PIM Signaling Through BIER
Core", Work in Progress, Internet-Draft, draft-ietf-bier-
pim-signaling-13, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
pim-signaling-13>.
[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>.
The authors would like to thank Zheng (Sandy) Zhang and Tanmoy Kundu for their suggestions and contributions to this document.
著者は、この文書への提案と貢献について、Zheng（Sandy）ZhangとTanmoy Kunduに感謝したいと思います。
Hooman Bidgoli (editor)
Nokia
March Road
Ottawa Ontario K2K 2T6
Canada
Email: hooman.bidgoli@nokia.com
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: stig@cisco.com
Mankamana Mishra
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: mankamis@cisco.com
Zhaohui Zhang
Juniper Networks
Boston, MA
United States of America
Email: zzhang@juniper.net
Mike McBride
Futurewei Technologies Inc.
Santa Clara, CA
United States of America
Email: michael.mcbride@futurewei.com