RFC 8815 - Deprecating Any-Source Multicast (ASM) for Interdomain Multicast 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8815.html
タイトル : RFC 8815 - ドメインマルチキャストのための任意のソースマルチキャスト（ASM）の非推奨
翻訳編集 : 自動生成

[要約] RFC 8815は、インタードメインマルチキャストのためのAny-Source Multicast (ASM)の廃止に関するもので、ASMの代わりにSource-Specific Multicast (SSM)を推奨しています。このRFCの目的は、ASMの複雑さとセキュリティ上の懸念を軽減し、インタードメインマルチキャストの効率性を向上させることです。

Internet Engineering Task Force (IETF)                    M. Abrahamsson
Request for Comments: 8815
BCP: 229                                                        T. Chown
Category: Best Current Practice                                     Jisc
ISSN: 2070-1721                                              L. Giuliano
                                                  Juniper Networks, Inc.
                                                               T. Eckert
                                             Futurewei Technologies Inc.
                                                             August 2020

Deprecating Any-Source Multicast (ASM) for Interdomain Multicast

ドメインマルチキャストのための任意のソースマルチキャスト（ASM）の非推奨

Abstract

概要

This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).

ドメイン間マルチキャストのための任意のソースマルチキャスト（ASM）の使用の廃止を推奨する。Domainマルチキャストアプリケーションのソース固有のマルチキャスト（SSM）を使用し、これらの展開のホストとルーターがSSMを完全にサポートすることをお勧めします。この文書の推奨事項は、単一の組織やドメイン内のASMの継続的な使用を排除しておらず、PIMスパースモード（PIM-SM）を使用したIntradomain ASMの既存の展開に特に採用できます。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモはインターネットの最高の現在の練習を文書化しています。

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 BCPs is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。BCPの詳細情報は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/rfc8815.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8815で取得できます。

著作権表示

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。

Table of Contents

   1.  Introduction
   2.  Background
     2.1.  Multicast Service Models
     2.2.  ASM Routing Protocols
       2.2.1.  PIM Sparse Mode (PIM-SM)
       2.2.2.  Embedded-RP
       2.2.3.  BIDIR-RP
     2.3.  SSM Routing Protocols
   3.  Discussion
     3.1.  Observations on ASM and SSM Deployments
     3.2.  Advantages of SSM for Interdomain Multicast
       3.2.1.  Reduced Network Operations Complexity
       3.2.2.  No Network-Wide IP Multicast Group-Address Management
       3.2.3.  Intrinsic Source-Control Security
   4.  Recommendations
     4.1.  Deprecating Use of ASM for Interdomain Multicast
     4.2.  Including Network Support for IGMPv3/MLDv2
     4.3.  Building Application Support for SSM
     4.4.  Developing Application Guidance: SSM, ASM, Service
           Discovery
     4.5.  Preferring SSM Applications Intradomain
     4.6.  Documenting an ASM/SSM Protocol Mapping Mechanism
     4.7.  Not Filtering ASM Addressing between Domains
     4.8.  Not Precluding Intradomain ASM
     4.9.  Evolving PIM Deployments for SSM
   5.  Future Interdomain ASM Work
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

IP Multicast has been deployed in various forms, within private networks, the wider Internet, and federated networks such as national or regional research networks. While a number of service models have been published, and in many cases revised over time, there has been no strong recommendation made by the IETF on the appropriateness of those models to certain scenarios, even though vendors and federations have often made such recommendations.

IPマルチキャストは、プライベートネットワーク、より広いインターネット、および国内または地域の研究ネットワークなどの連合ネットワーク内でさまざまな形式で展開されています。多くのサービスモデルが公開されている間、そして多くの場合に改訂されている間、ベンダーや連盟がしばしばそのような勧告されたとしても、特定のシナリオへのこれらのモデルの適切性についてIETFによって行われていません。

This document addresses this gap by making a BCP-level recommendation to deprecate the use of Any-Source Multicast (ASM) for interdomain multicast, leaving Source-Specific Multicast (SSM) as the recommended interdomain mode of multicast. Therefore, this document recommends that all hosts and routers that support interdomain multicast applications fully support SSM.

この文書は、ドメイン間マルチキャストのための任意のソースマルチキャスト（ASM）の使用を推奨することによって、このギャップに対処し、ソース固有のマルチキャスト（SSM）を推奨するマルチキャストのマルチキャストモードとして残します。したがって、この文書では、ドメインマルチキャストアプリケーションをサポートするすべてのホストとルーターがSSMを完全にサポートすることをお勧めします。

This document does not make any statement on the use of ASM within a single domain or organization and, therefore, does not preclude its use. Indeed, there are application contexts for which ASM is currently still widely considered well suited within a single domain.

この文書は、単一のドメインまたは組織内のASMの使用に関するステートメントは何もしません。したがって、その使用を妨げない。確かに、ASMが現在単一のドメイン内で非常に適していると依然として広く考慮されているアプリケーションコンテキストがあります。

The main issue in most cases with moving to SSM is application support. Many applications are initially deployed for intradomain use and are later deployed interdomain. Therefore, this document recommends that applications support SSM, even when they are initially intended for intradomain use. As explained below, SSM applications are readily compatible with existing intradomain ASM deployments using PIM-SM, as PIM-SSM is merely a subset of PIM-SM.

SSMへの移動を伴うほとんどの場合の主な問題はアプリケーションサポートです。Intradomainの使用には、多くのアプリケーションが最初にデプロイされており、後で展開されています。したがって、このドキュメントでは、最初に内部の使用を意図している場合でも、アプリケーションがSSMをサポートすることを推奨しています。以下に説明するように、PIM-SSMはPIM-SMのサブセットであるため、SSMアプリケーションはPIM-SMを使用する既存のイントラードメインASM展開と容易に互換性があります。

2. Background

2. バックグラウンド

2.1. Multicast Service Models

2.1. マルチキャストサービスモデル

Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are the two multicast service models in use today. In ASM, as originally described in [RFC1112], receivers express interest in joining a multicast group address, and routers use multicast routing protocols to deliver traffic from the sender(s) to the receivers. If there are multiple senders for a given group, traffic from all senders will be delivered to the receivers. Since receivers specify only the group address, the network -- and therefore the multicast routing protocols -- are responsible for source discovery.

任意のソースマルチキャスト（ASM）およびソース固有のマルチキャスト（SSM）は、今日使用されている2つのマルチキャストサービスモデルです。ASMでは、[RFC1112]で最初に説明されているように、受信者はマルチキャストグループアドレスを結合するための関心を示し、ルータは送信者から受信者へのトラフィックを配信するためにマルチキャストルーティングプロトコルを使用します。特定のグループの送信者が複数ある場合、すべての送信者からのトラフィックが受信者に配信されます。受信者はグループアドレス、ネットワーク - 、したがってマルチキャストルーティングプロトコルのみを指定しているので - ソース検出を担当します。

In SSM, by contrast, receivers specify both group and source when expressing interest in joining a multicast stream. Source discovery in SSM is handled by some out-of-band mechanism (typically in the application layer), which drastically simplifies the network and how the multicast routing protocols operate.

これとは対照的に、SSMでは、受信者は、マルチキャストストリームを結合する際の興味を表現するときにグループとソースの両方を指定します。SSMのソース検出は、ネットワークを劇的に単純化し、マルチキャストルーティングプロトコルがどのように機能するか、およびマルチキャストルーティングプロトコルがどのように簡素化されるかによって処理されます。

IANA has reserved specific ranges of IPv4 and IPv6 address space for multicast addressing. Guidelines for IPv4 multicast address assignments can be found in [RFC5771], while guidelines for IPv6 multicast address assignments can be found in [RFC2375] and [RFC3307]. The IPv6 multicast address format is described in [RFC4291].

IANAは、マルチキャストアドレス指定のためのIPv4とIPv6アドレス空間の特定の範囲を予約しました。IPv4マルチキャストアドレスの割り当てのガイドラインは[RFC5771]で見つけることができますが、IPv6マルチキャストアドレスの割り当てのガイドラインは[RFC2375]と[RFC3307]にあります。IPv6マルチキャストアドレスフォーマットは[RFC4291]に記載されています。

2.2. ASM Routing Protocols

2.2. ASMルーティングプロトコル

2.2.1. PIM Sparse Mode (PIM-SM)

2.2.1. PIMスパースモード（PIM-SM）

The most commonly deployed ASM routing protocol is Protocol Independent Multicast - Sparse Mode (PIM-SM), as detailed in [RFC7761]. PIM-SM, as the name suggests, was designed to be used in scenarios where the subnets with receivers are sparsely distributed throughout the network. Because receivers do not indicate sender addresses in ASM (but only group addresses), PIM-SM uses the concept of a Rendezvous Point (RP) as a "meeting point" for sources and receivers, and all routers in a PIM-SM domain are configured to use a specific RP(s), either explicitly or through dynamic RP-discovery protocols.

最も一般的に展開されたASMルーティングプロトコルは、[RFC7761]に詳述されているように、プロトコル独立マルチキャストスパースモード（PIM-SM）です。PIM-SMは、名前が示唆しているように、受信機を持つサブネットがネットワーク全体にまばられるシナリオで使用されるように設計されていました。受信機はASM（ただしグループアドレスのみ）で送信者アドレスを指定しないので、PIM-SMはソースと受信機の「ミーティングポイント」としてRendezvous Point（RP）の概念を使用し、PIM-SMドメイン内のすべてのルータは明示的にまたは動的RP-Discoveryプロトコルを使用して、特定のRPを使用するように構成されています。

To enable PIM-SM to work between multiple domains, an interdomain, inter-RP signaling protocol known as Multicast Source Discovery Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to learn of the existence of a source in another domain. Deployment scenarios for MSDP are given in [RFC4611]. MSDP floods information about all active sources for all multicast streams to all RPs in all the domains -- even if there is no receiver for a given application in a domain. As a result of this key scalability and security issue, along with other deployment challenges with the protocol, MSDP was never extended to support IPv6 and remains an Experimental protocol.

PIM-SMを複数のドメイン間で働くことを可能にするために、マルチキャストソース検出プロトコル（MSDP）[RFC3618]と呼ばれる間のRP間シグナリングプロトコルは、1つのドメイン内のRPが他のドメインの存在を学ぶことを可能にするために使用されます。ドメイン。[RFC4611]にMSDPの展開シナリオが与えられています。MSDPは、ドメイン内の特定のアプリケーション用の受信者がない場合でも、すべてのドメイン内のすべてのRPSにすべてのRPSのすべてのRPSにすべてのアクティブソースに関する情報をフラッディングします。この主なスケーラビリティとセキュリティの問題の結果として、プロトコルによる他の展開の課題とともに、MSDPはIPv6をサポートするために延長され、実験プロトコルのままです。

At the time of writing, there is no IETF interdomain solution at the level of Proposed Standard for IPv4 ASM multicast, because MSDP was the de facto mechanism for the interdomain source discovery problem, and it is Experimental. Other protocol options were investigated at the same time but were never implemented or deployed and are now historic (e.g., [RFC3913]).

書き込み時には、MSDPはドメイン源発見問題のための事実上のメカニズムであり、実験的であるため、IPv4 ASMマルチキャストのための提案された標準のレベルでIETFイントドメインソリューションはありません。他のプロトコルオプションは同時に調査されましたが、実装または展開されたことがなく、現在歴史的（例えば、[RFC3913]）です。

2.2.2. Embedded-RP

2.2.2. 埋め込まれたrp.

Due to the availability of more bits in an IPv6 address than in IPv4, an IPv6-specific mechanism was designed in support of interdomain ASM, with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows routers supporting the protocol to determine the RP for the group without any prior configuration or discovery protocols, simply by observing the unicast RP address that is embedded (included) in the IPv6 multicast group address. Embedded-RP allows PIM-SM operation across any IPv6 network in which there is an end-to-end path of routers supporting this mechanism, including interdomain deployment.

IPv4以外のIPv6アドレスのビットが多いため、IPv6固有のメカニズムはDomain ASMをサポートして設計され、PIM-SMはそれらのビットを活用しています。Embedded-RP [RFC3956]プロトコルをサポートするルーターは、IPv6マルチキャストグループアドレスに埋め込まれているユニキャストRPアドレスを監視するだけで、以前の構成または検出プロトコルなしでグループのRPを決定できます。embedded-rpでは、Domain Deploymentを含むこのメカニズムをサポートするルータのエンドツーエンドのパスがある任意のIPv6ネットワーク全体でPIM-SM操作を可能にします。

2.2.3. BIDIR-RP

2.2.3. ビジル-RP.

BIDIR-PIM [RFC5015] is another protocol to support ASM. There is no standardized option to operate BIDIR-PIM interdomain. It is deployed intradomain for applications where many sources send traffic to the same IP multicast groups because, unlike PIM-SM, it does not create per-source state. BIDIR-PIM is one of the important reasons for this document to not deprecate intradomain ASM.

Bidir-PIM [RFC5015]はASMをサポートするための別のプロトコルです。Bidir-PIMイントドメインを操作するための標準化されたオプションはありません。PIM-SMとは異なり、それはソースごとの状態を作成しないため、多くのソースが同じIPマルチキャストグループにトラフィックを送信するアプリケーションに展開されています。Bidir-PIMは、この文書の重要な理由の1つです。

2.3. SSM Routing Protocols

2.3. SSMルーティングプロトコル

SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for routing of SSM. PIM-SSM is merely a subset of PIM-SM [RFC7761].

SSMは[RFC4607]に詳述されています。SSMのルーティング用のPIM-SSMの使用を義務付けています。PIM-SSMはPIM-SM [RFC7761]のサブセットのみです。

PIM-SSM expects the sender's source address(es) to be known in advance by receivers through some out-of-band mechanism (typically in the application layer); thus, the receiver's designated router can send a PIM Join message directly towards the source without needing to use an RP.

PIM-SSMは、送信者の送信元アドレスが、いくつかの帯域外機構（通常はアプリケーション層内）を介して受信機によって事前に知られることを期待している。したがって、受信機の指定されたルータは、RPを使用する必要なしに、PIM結合メッセージをソースに向かって直接送信することができる。

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 IPv6, the address prefix ff3x::/32 is reserved for source-specific multicast use. See [RFC4607].

232/8（232.0.0.0~232.255.255）のIPv4アドレスは、ソース固有のマルチキャスト（SSM）宛先アドレスとして指定され、ソース固有のアプリケーションおよびプロトコルで使用するために予約されています。IPv6の場合、アドレスプレフィックスFF3X :: / 32は、ソース固有のマルチキャスト使用のために予約されています。[RFC4607]を参照してください。

3. Discussion

3. 討論

3.1. Observations on ASM and SSM Deployments

3.1. ASMおよびSSM展開に関する観察

In enterprise and campus scenarios, ASM in the form of PIM-SM is likely the most commonly deployed multicast protocol. The configuration and management of an RP (including RP redundancy) within a single domain is a well-understood operational practice. However, if interworking with external PIM domains is needed in IPv4 multicast deployments, interdomain MSDP is required to exchange information about sources between domain RPs. Deployment experience has shown MSDP to be a complex and fragile protocol to manage and troubleshoot. Some of these issues include complex Reverse Path Forwarding (RPF) rules, state attack protection, and filtering of undesired sources.

企業のシナリオとキャンパスのシナリオでは、PIM-SMの形式のASMは、最も一般的に展開されたマルチキャストプロトコルです。単一のドメイン内のRP（RP冗長性を含む）の構成と管理は、よく理解されている運用慣行です。ただし、外部PIMドメインとのインターワーキングがIPv4マルチキャスト展開で必要な場合は、ドメインRP間のソースに関する情報を交換するためには、Domain MSDPが必要です。デプロイメントエクスペリエンスは、MSDPを管理してトラブルシューティングするための複雑で脆弱なプロトコルになるようになりました。これらの問題のいくつかには、複雑な逆パス転送（RPF）規則、状態攻撃保護、および望ましくないソースのフィルタリングが含まれます。

PIM-SM is a general-purpose protocol that can handle all use cases. In particular, it was designed for cases such as videoconferencing where multiple sources may come and go during a multicast session. But for cases where a single, persistent source for a group is used, and receivers can be configured to know of that source, PIM-SM has unnecessary complexity. Therefore, SSM removes the need for many of the most complex components of PIM-SM.

PIM-SMは、すべてのユースケースを処理できる汎用プロトコルです。特に、マルチキャストセッション中に複数のソースが発生して行く可能性があるテレビ会議などの場合に設計されていました。しかし、グループの単一の永続的なソースが使用され、受信機をそのソースから知るように設定できる場合は、PIM-SMは不要な複雑さを備えています。したがって、SSMはPIM-SMの最も複雑なコンポーネントの多くの必要性を取り除きます。

As explained above, MSDP was not extended to support IPv6. Instead, the proposed interdomain ASM solution for PIM-SM with IPv6 is Embedded-RP, which allows the RP address for a multicast group to be embedded in the group address, making RP discovery automatic for all routers on the path between a receiver and a sender. Embedded-RP can support lightweight ad hoc deployments. However, it relies on a single RP for an entire group that could only be made resilient within one domain. While this approach solves the MSDP issues, it does not solve the problem of unauthorized sources sending traffic to ASM multicast groups; this security issue is one of biggest problems of interdomain multicast.

上で説明したように、MSDPはIPv6をサポートするために拡張されませんでした。代わりに、IPv6を搭載したPIM-SM用のPIM-SM用のDomain ASMソリューションは埋め込みRPです。これにより、マルチキャストグループのRPアドレスをグループアドレスに埋め込むことができ、RPディスカバリを受信側と受信側との間のパス上のすべてのルータを自動化することができます。送信者Embedded-RPは、軽量アドホック展開をサポートできます。ただし、1つのドメイン内でのみ弾力性にできるグループ全体のための単一のRPに依存しています。このアプローチはMSDPの問題を解決していますが、不正なソースの問題はASMマルチキャストグループにトラフィックを送信するという問題を解決しません。このセキュリティの問題は、ドメイン間マルチキャストの最大の問題の1つです。

As stated in RFC 4607, SSM is particularly well suited to either dissemination-style applications with one or more senders whose identities are known (by some out-of-band mechanism) before the application starts running or applications that utilize some signaling to indicate the source address of the multicast stream (e.g., an electronic programming guide in IPTV applications). Therefore, SSM through PIM-SSM is very well suited to applications such as classic linear-broadcast TV over IP.

RFC 4607に記載されているように、SSMは、アプリケーションが実行を開始する前に（一部の帯域外メカニズムによって）識別されている1つ以上の送信者を持つSSMは、（一部の帯域外メカニズムによって）、またはそれらを示すためにいくつかのシグナリングを利用するアプリケーションのいずれかに適しています。マルチキャストストリームの送信元アドレス（例えば、IPTVアプリケーションの電子プログラミングガイド）。したがって、SSMからPIM-SSMを介して、IP上の古典的なリニアブロードキャストテレビなどのアプリケーションに非常に適しています。

SSM requires applications, host operating systems, and the designated routers connected to receiving hosts to support Internet Group Management Protocol, Version 3 (IGMPv3) [RFC3376] and Multicast Listener Discovery, Version 2 (MLDv2) [RFC3810]. While support for IGMPv3 and MLDv2 has been commonplace in routing platforms for a long time, it has also now become widespread in common operating systems for several years (Windows, Mac OS, Linux/Android) and is no longer an impediment to SSM deployment.

SSMは、インターネットグループ管理プロトコル、バージョン3（IGMPv3）[RFC3376]とマルチキャストリスナーディスカバリー、バージョン2（MLDv2）[RFC3810]をサポートするために、アプリケーション、ホストオペレーティングシステム、および指定されたルーターが必要です。IGMPv3とMLDV2のサポートは長期間ルーティングプラットフォームに共通点がありますが、これも数年間共通のオペレーティングシステムで広く普及しています（Windows、Mac OS、Linux / Android）、もはやSSMの展開への障害はもうありません。

3.2. Advantages of SSM for Interdomain Multicast

3.2. ドメイン間マルチキャストのためのSSMの利点

This section describes the three key benefits that SSM with PIM-SSM has over ASM. These benefits also apply to intradomain deployment but are even more important in interdomain deployments. See [RFC4607] for more details.

このセクションでは、PIM-SSMのSSMがASMを超えるSSMの3つの主な利点について説明します。これらの利点は、ドメイン内展開にも適用されますが、ドメイン間の展開でさらに重要です。詳細については[RFC4607]を参照してください。

3.2.1. Reduced Network Operations Complexity

3.2.1. ネットワーク操作の複雑さの削減

A significant benefit of SSM is the reduced complexity that comes through eliminating the network-based source discovery required in ASM with PIM-SM. Specifically, SSM eliminates the need for RPs, shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, MSDP, dynamic RP-discovery mechanisms (Bootstrap Router (BSR) / AutoRP), and data-driven state creation. SSM simply utilizes a small subset of PIM-SM, alongside the integration with IGMPv3/MLDv2, where the source address signaled from the receiver is immediately used to create (S,G) state. Eliminating network-based source discovery for interdomain multicast means the vast majority of the complexity of multicast goes away.

SSMの重要な利点は、PIM-SMとASMで必要なネットワークベースのソース検出を排除することを通じて、複雑さの減少です。具体的には、SSMは、RPS、共有ツリー、最短パスツリー（SPT）切り替え、PIMレジスタ、MSDP、動的RP-Discovery Mecumity（Bootstrap Router（BSR）/ AUTORP）、およびデータ駆動状態の作成を排除します。SSMは、IGMPv3 / MLDv2との統合とともに、PIM-SMの小さなサブセットを利用して、受信機からシグナリングされた送信元アドレスは直ちに（S、G）状態を作成するために使用されます。ドメイン間マルチキャストのためのネットワークベースのソースディスカバリを排除すると、マルチキャストの複雑さの大部分が消えます。

This reduced complexity makes SSM radically simpler to manage, troubleshoot, and operate, particularly for backbone network operators. This is the main operator motivation for the recommendation to deprecate the use of ASM in interdomain scenarios.

この複雑さの減少により、SSMは、特にバックボーンネットワーク事業者にとって、管理、トラブルシューティング、および動作が急激に簡単になります。これは、DomainシナリオにおけるASMの使用を推奨する推奨事項の主なオペレータの動機です。

Note that this discussion does not apply to BIDIR-PIM, and there is (as mentioned above) no standardized interdomain solution for BIDIR-PIM. In BIDIR-PIM, traffic is forwarded to the RP instead of building state as in PIM-SM. This occurs even in the absence of receivers. Therefore, BIDIR-PIM offers a trade-off of state complexity at the cost of creating unnecessary traffic (potentially a large amount).

この議論はBidir-PIMには適用されず、（上記のように）Bidir-PIM用の標準化されたドメインソリューションはありません。Bidir-PIMでは、PIM-SMのようにスタート状態の代わりにトラフィックがRPに転送されます。これは受信機がない場合でも起こります。したがって、Bidir-PIMは、不要なトラフィックを作成するコスト（潜在的に大量）のコストで州の複雑さのトレードオフを提供します。

3.2.2. No Network-Wide IP Multicast Group-Address Management

3.2.2. ネットワーク全体のIPマルチキャストグループアドレス管理なし

In ASM, IP multicast group addresses need to be assigned to applications and instances thereof, so that two simultaneously active application instances will not share the same group address and receive IP multicast traffic from each other.

ASMでは、IPマルチキャストグループアドレスをアプリケーションとインスタンスに割り当てる必要があるため、2つの同時にアクティブなアプリケーションインスタンスは同じグループアドレスを共有し、互いにIPマルチキャストトラフィックを受信しません。

In SSM, no such IP multicast group management is necessary. Instead, the IP multicast group address simply needs to be assigned locally on a source like a unicast transport protocol port number: the only coordination required is to ensure that different applications running on the same host don't send to the same group address. This does not require any network-operator involvement.

SSMでは、そのようなIPマルチキャストグループ管理は必要ありません。代わりに、IPマルチキャストグループアドレスは、ユニキャストトランスポートプロトコルポート番号のようなソース上でローカルに割り当てる必要があります。必要な唯一の調整は、同じホスト上で実行されているさまざまなアプリケーションが同じグループアドレスに送信されないようにすることです。これはネットワークオペレータの関与を必要としません。

3.2.3. Intrinsic Source-Control Security

3.2.3. 組み込みソース管理セキュリティ

SSM is implicitly secure against off-path unauthorized/undesired sources. Receivers only receive packets from the sources they explicitly specify in their IGMPv3/MLDv2 membership messages, as opposed to ASM, where any host can send traffic to a group address and have it transmitted to all receivers. With PIM-SSM, traffic from sources not requested by any receiver will be discarded by the First-Hop Router (FHR) of that source, minimizing source attacks against shared network bandwidth and receivers.

SSMは、オフパスの不正/望ましくないソースに対して暗黙的に安全です。受信側は、ASMとは対照的に、それらがIGMPv3 / MLDv2メンバーシップメッセージで明示的に指定されたソースのみを受信し、任意のホストがグループアドレスにトラフィックを送信し、それをすべての受信機に送信できるようにすることができます。PIM-SSMでは、任意の受信機によって要求されていないソースからのトラフィックは、そのソースのファーストホップルータ（FHR）によって破棄され、共有ネットワーク帯域幅および受信機に対するソース攻撃を最小限に抑えます。

This benefit is particularly important in interdomain deployments because there are no standardized solutions for ASM control of sources and the most common intradomain operational practices such as Access Control Lists (ACLs) on the sender's FHR are not feasible for interdomain deployments.

ソースのASM制御には標準化されたソリューションがないため、これらの利点は特に重要です。ソースのASM制御には標準化されたソリューションがあり、送信者のFHR上のアクセス制御リスト（ACL）などの最も一般的な内部の運用慣行は、ドメイン間の展開には不可能ではありません。

This topic is expanded upon in [RFC4609].

このトピックは[RFC4609]で展開されています。

4. Recommendations

4. 勧告

This section provides recommendations for a variety of stakeholders in SSM deployment, including vendors, operators, and application developers. It also suggests further work that could be undertaken within the IETF.

このセクションでは、ベンダー、オペレータ、およびアプリケーション開発者など、SSM展開でさまざまな利害関係者に対する推奨事項を提供します。IETF内で行われる可能性があるさらなる作業も提案されています。

4.1. Deprecating Use of ASM for Interdomain Multicast

4.1. ドメインマルチキャストのASMの非推奨使用

This document recommends that the use of ASM be deprecated for interdomain multicast; thus, implicitly, it recommends that hosts and routers that support such interdomain applications fully support SSM and its associated protocols. Best current practices for deploying interdomain multicast using SSM are documented in [RFC8313].

この文書は、ASMの使用がドメインマルチキャストのために推奨されることを推奨しています。したがって、暗黙のうちに、そのようなドメインアプリケーションをサポートするホストとルータは、SSMとその関連プロトコルを完全にサポートすることを推奨します。SSMを使用してドメイン間マルチキャストを展開するための最良の現在の慣行は[RFC8313]に文書化されています。

The recommendation applies to the use of ASM between domains where either MSDP (IPv4) or Embedded-RP (IPv6) is used.

推奨事項は、MSDP（IPv4）またはEmbedded-RP（IPv6）が使用されているドメイン間のASMの使用に適用されます。

An interdomain use of ASM multicast in the context of this document is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers operated by two or more separate administrative entities.

このドキュメントのコンテキストでのASMマルチキャストのドメイン間使用は、RPS / MSDP / Embedded-RPを持つPIM-SMが2つ以上の別々の管理エンティティによって運用されるルータ上で実行されるものです。

The focus of this document is deprecation of interdomain ASM multicast, and while encouraging the use of SSM within domains, it leaves operators free to choose to use ASM within their own domains. A more inclusive interpretation of this recommendation is that it also extends to deprecating use of ASM in the case where PIM is operated in a single operator domain, but where user hosts or non-PIM network edge devices are under different operator control. A typical example of this case is a service provider offering IPTV (single operator domain for PIM) to subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).

この文書の焦点はドメイン間ASMマルチキャストの償却であり、ドメイン内のSSMの使用を促進しながら、オペレータは自分のドメイン内でASMを使用することを自由に選択します。この勧告のより包括的な解釈は、PIMが単一のオペレータドメインで操作されているが、ユーザホストまたは非PIMネットワークエッジ装置が異なるオペレータ制御下にある場合には、ASMの使用を非推奨することにも及ぶことである。このケースの典型的な例は、IGMPプロキシホームゲートウェイおよびIGMPv3 / MLDv2ホスト（コンピュータ、タブレット、セットトップボックス）を操作する加入者へのIPTV（PIM用の単一オペレータドメイン）を提供するサービスプロバイダーです。

4.2. Including Network Support for IGMPv3/MLDv2

4.2. IGMPv3 / MLDv2のネットワークサポートを含む

This document recommends that all hosts, router platforms, and security appliances used for deploying multicast support the components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to support SSM (i.e., explicitly sending source-specific reports). "IPv6 Node Requirements" [RFC8504] states that MLDv2 must be supported in all implementations. Such support is already widespread in common host and router platforms.

このドキュメントでは、マルチキャストのサポートの展開に使用されるすべてのホスト、ルータープラットフォーム、およびセキュリティアプライアンスが、SSMをサポートするために必要なIGMPv3 [RFC3376]とMLDV2 [RFC3810]のコンポーネント（すなわち、ソース固有のレポートを明示的に送信されます）をサポートすることをお勧めします。"IPv6ノード要件" [RFC8504]は、MLDV2がすべての実装でサポートされている必要があります。そのようなサポートは、共通のホストプラットフォームおよびルータープラットフォームではすでに広く広くなっています。

Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].

IGMPv3とMLDv2のさらなるガイダンスは[RFC4604]に与えられます。

Multicast snooping is often used to limit the flooding of multicast traffic in a Layer 2 network. With snooping, an L2 switch will monitor IGMP/MLD messages and only forward multicast traffic out on host ports that have interested receivers connected. Such snooping capability should therefore support IGMPv3 and MLDv2. There is further discussion in [RFC4541].

マルチキャストスヌーピングは、レイヤ2ネットワーク内のマルチキャストトラフィックのフラッディングを制限するためによく使用されます。スヌーピングでは、L2スイッチはIGMP / MLDメッセージを監視し、関心のある受信機が接続されているホストポートにマルチキャストトラフィックを転送します。したがって、そのようなスヌーピング機能はIGMPv3とMLDv2をサポートするはずです。[RFC4541]ではさらなる議論があります。

4.3. Building Application Support for SSM

4.3. SSMのアプリケーションサポートの構築

The recommendation to use SSM for interdomain multicast means that applications should properly trigger the sending of IGMPv3/MLDv2 source-specific report messages. It should be noted, however, that there is a wide range of applications today that only support ASM. In many cases, this is due to application developers being unaware of the operational concerns of networks and the implications of using ASM versus SSM. This document serves to provide clear direction for application developers who might currently only consider using ASM to instead support SSM, which only requires relatively minor changes for many applications, particularly those with single sources.

DomainマルチキャストにSSMを使用する推奨事項は、アプリケーションがIGMPv3 / MLDv2ソース固有のレポートメッセージの送信を正しくトリガすることを意味します。ただし、ASMをサポートするのは今日さまざまなアプリケーションがあることに注意すべきです。多くの場合、これはアプリケーション開発者がネットワークの運用上の懸念と、ASM対SSMの使用の影響に気付いていないためです。このドキュメントは、現在、ASMを代わりにSSMをサポートするためだけにASMを使用するだけである可能性があるアプリケーション開発者には明確な方向を提供するのに役立ちます。

It is often thought that ASM is required for multicast applications where there are multiple sources. However, RFC 4607 also describes how SSM can be used instead of PIM-SM for multi-party applications:

ASMが複数のソースがあるマルチキャストアプリケーションに必要であるとしばしば考えられています。ただし、RFC 4607では、マルチパーティアプリケーション用のPIM-SMの代わりにSSMを使用できる方法についても説明します。

   |  SSM can be used to build multi-source applications where all
   |  participants' identities are not known in advance, but the multi-
   |  source "rendezvous" functionality does not occur in the network
   |  layer in this case.  Just like in an application that uses unicast
   |  as the underlying transport, this functionality can be implemented
   |  by the application or by an application-layer library.

Some useful considerations for multicast applications can be found in [RFC3170].

マルチキャストアプリケーションに関する便利な考慮事項は、[RFC3170]にあります。

4.4. Developing Application Guidance: SSM, ASM, Service Discovery

4.4. アプリケーションガイダンスの開発：SSM、ASM、サービス発見

Applications with many-to-many communication patterns can create more (S,G) state than is feasible for networks to manage, whether the source discovery is done by ASM with PIM-SM or at the application level and SSM/PIM-SSM. These applications are not best supported by either SSM/PIM-SSM or ASM/PIM-SM.

多対多間の通信パターンを持つアプリケーションは、ネットワークが管理することができるよりも多くの（S、G）の状態を作成できます。ソース検出は、PIM-SMまたはアプリケーションレベルでSSM / PIM-SSMでASMによって行われるかどうかを示します。これらのアプリケーションは、SSM / PIM-SSMまたはASM / PIM-SMのいずれかによって最もよくサポートされていません。

Instead, these applications are better served by routing protocols that do not create (S,G), such as BIDIR-PIM. Unfortunately, many applications today use ASM solely for service discovery. One example is where clients send IP multicast packets to elicit unicast replies from server(s). Deploying any form of IP multicast solely in support of such service discovery is, in general, not recommended. Dedicated service discovery via DNS-based Service Discovery (DNS-SD) [RFC6763] should be used for this instead.

代わりに、これらのアプリケーションは、Bidir-PIMなどの作成しないプロトコルをルーティングすることによって提供されます。残念ながら、今日の多くのアプリケーションはサービス発見のためだけにASMを使用しています。1つの例は、クライアントがサーバーからユニキャスト応答を引き出すためにIPマルチキャストパケットを送信する場所です。そのようなサービス発見をサポートするだけで任意の形式のIPマルチキャストの展開は、一般的にはお勧めできません。DNSベースのサービス検出による専用サービス検出（DNS-SD）[RFC6763]は代わりに使用する必要があります。

This document describes best practices to explain when to use SSM in applications -- e.g., when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used. However, specifying how applications can support these practices is outside the scope of this document. Further work on this subject may be expected within the IETF.

この文書では、ネットワーク内のasmが優れている場合、または専用のサービス発見メカニズムを使用する場合、またはアプリケーションでSSMを使用する場合を説明するためのベストプラクティスについて説明します。ただし、アプリケーションがこれらの慣行をサポートできる方法を指定することは、この文書の範囲外です。この被写体のさらなる作業は、IETF内で予想されるかもしれません。

4.5. Preferring SSM Applications Intradomain

4.5. SSMアプリケーションを好む

If feasible, it is recommended for applications to use SSM even if they are initially only meant to be used in intradomain environments supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing intradomain PIM-SM networks are automatically compatible with SSM applications. Thus, SSM applications can operate alongside existing ASM applications. SSM's benefits of simplified address management and significantly reduced operational complexity apply equally to intradomain use.

実行可能であれば、それらが最初にASMをサポートしている内索環境でのみ使用されることだけであっても、SSMを使用することをお勧めします。PIM-SSMはPIM-SMのサブセットであるため、既存のIntradomain PIM-SMネットワークはSSMアプリケーションと自動的に互換性があります。したがって、SSMアプリケーションは既存のASMアプリケーションと一緒に動作することができます。SSMのSSMのアドレス管理の利点は、運用の複雑さを大幅に削減したことの利点が、内外の使用に等しく適用されます。

However, for some applications, it may be prohibitively difficult to add support for source discovery, so intradomain ASM may still be appropriate.

しかし、いくつかのアプリケーションでは、ソース発見のためのサポートを追加することは法外に困難であるため、Intradomain ASMは依然として適切である可能性があります。

4.6. Documenting an ASM/SSM Protocol Mapping Mechanism

4.6. ASM / SSMプロトコルマッピングメカニズムの文書化

In the case of existing ASM applications that cannot readily be ported to SSM, it may be possible to use some form of protocol mapping -- i.e., to have a mechanism to translate a (*,G) join or leave to a (S,G) join or leave for a specific source S. The general challenge in performing such mapping is determining where the configured source address, S, comes from.

SSMに容易に移植できない既存のASMアプリケーションの場合、何らかの形式のプロトコルマッピングを使用することが可能かもしれません - （*、g）の参加を翻訳するためのメカニズムを持つことができます（S、S、g）特定の送信元Sのために参加または休暇を取る。そのようなマッピングを実行する際の一般的なチャレンジは、構成された送信元アドレスSがどこから来るかを決定することです。

There are existing vendor-specific mechanisms deployed that achieve this function, but none are documented in IETF documents. This may be a useful area for the IETF to work on as an interim transition mechanism. However, these mechanisms would introduce additional administrative burdens, along with the need for some form of address management, neither of which are required in SSM. Hence, this should not be considered a long-term solution.

この関数を達成する既存のベンダー固有のメカニズムが展開されていますが、IETF文書には何も文書化されていません。これは、IETFが暫定的な移行メカニズムとして機能するのに役立つ領域であり得る。ただし、これらのメカニズムは、SSMにはどちらも必須ではありません。したがって、これは長期的な解決策と見なされるべきではありません。

4.7. Not Filtering ASM Addressing between Domains

4.7. ドメイン間でASMアドレス指定をフィルタリングしないでください

A key benefit of SSM is that the receiver specifies the source-group tuple when signaling interest in a multicast stream. Hence, the group address need not be globally unique, so there is no need for multicast address allocation as long the reserved SSM range is used.

SSMの主な利点は、受信側がマルチキャストストリームへの関心があるときにソースグループタプルを指定することです。したがって、グループアドレスはグローバルに一意である必要はないので、予約されたSSM範囲が使用されるようにマルチキャストアドレス割り当てを必要としない。

Despite the deprecation of interdomain ASM, it is recommended that operators not filter ASM group ranges at domain boundaries, as some form of ASM-SSM mappings may continue to be used for some time.

Domain ASMの非推奨にもかかわらず、何らかの形のASM-SSMマッピングがしばらくの間使用され続けることができるので、オペレータはドメイン境界でASMグループの範囲をフィルタリングしないことが推奨されます。

4.8. Not Precluding Intradomain ASM

4.8. ASMを裂くことはないでください

The use of ASM within a single multicast domain such as a campus or enterprise is still relatively common today. There are even global enterprise networks that have successfully been using PIM-SM for many years. The operators of such networks most often use Anycast-RP [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of the extra operational complexity. These existing practices are unaffected by this document.

キャンパスや企業などの単一のマルチキャストドメイン内のASMの使用は、今日でも比較的一般的です。長年にわたってPIM-SMを使用してきたグローバルエンタープライズネットワークさえあります。そのようなネットワークのオペレータは、追加の運用上の複雑さを犠牲にして、RP回復力のためにAnycast-RP [RFC4610]またはMSDP（IPv4）を使用しています。これらの既存の慣行はこの文書の影響を受けません。

In the past decade, some BIDIR-PIM deployments have scaled interdomain ASM deployments beyond the capabilities of PIM-SM. This, too, is unaffected by this document; instead, it is encouraged where necessary due to application requirements (see Section 4.4).

過去10年間で、いくつかのBidir-PIM展開は、PIM-SMの機能を超えてドメイン間のASM展開を拡大しました。これもこの文書の影響を受けません。代わりに、アプリケーション要件のために必要な場所に奨励されます（4.4節を参照）。

This document also does not preclude continued use of ASM with multiple PIM-SM domains inside organizations, such as with IPv4 MSDP or IPv6 Embedded-RP. This includes organizations that are federations and have appropriate, nonstandardized mechanisms to deal with the interdomain ASM issues explained in Section 3.2.

この文書では、IPv4 MSDPまたはIPv6埋め込みRPなど、組織内の複数のPIM-SMドメインとの継続的な使用を排除していません。これには、セクション3.2で説明されているドメイン間のASMの問題に対処するための適切な非標準のメカニズムがあります。

4.9. Evolving PIM Deployments for SSM

4.9. SSM用の進化するPIM展開

Existing PIM-SM deployments can usually be used to run SSM applications with few-to-no changes. In some widely available router implementations of PIM-SM, PIM-SSM is simply enabled by default in the designated SSM address spaces whenever PIM-SM is enabled. In other implementations, simple configuration options exist to enable it. This allows migration of ASM applications to SSM/PIM-SSM solely through application-side development to handle source-signaling via IGMPv3/MLDv2 and using SSM addresses. No network actions are required for this transition; unchanged ASM applications can continue to coexist without issues.

既存のPIM-SMの展開は通常、いくつかの変更されていない変更でSSMアプリケーションを実行するために使用できます。PIM-SMの広く利用可能なルータ実装の中では、PIM-SMが有効になっているときはいつでも、指定されたSSMアドレススペースでPIM-SSMがデフォルトで有効になっています。他の実装形態では、有効にするために単純な設定オプションが存在します。これにより、ASMアプリケーションをSSM / PIM-SSMに移行することができ、IGMPv3 / MLDV2を介してSSMアドレスを使用してソースシグナリングを処理するためにアプリケーションサイドの開発を通してSSM / PIM-SSMへの移行を可能にします。この遷移にはネットワークアクションは必要ありません。変更されていないASMアプリケーションは、問題なく共存し続けることができます。

When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also result in the desired PIM-SSM (S,G) operations and bypass any RP procedures. This is not standardized but depends on implementation and may require additional configuration in available products. In general, it is recommended to always use SSM address space for SSM applications. For example, the interaction of IGMPv3/MLDv2 (S,G) membership reports and BIDIR-PIM is undefined and may not result in forwarding of any traffic.

PIM-SMを実行すると、IGMPv3 / MLDv2（S、G）のメンバーシップレポートは、任意のPIM-SSM（S、G）操作をもたらし、RP手順を迂回します。これは標準化されていませんが、実装に依存し、利用可能な製品に追加の構成が必要になる場合があります。一般に、SSMアプリケーションのSSMアドレス・スペースを常に使用することをお勧めします。たとえば、IGMPv3 / MLDv2（S、G）のメンバーシップレポートとBidir-PIMとの相互作用は未定義であり、トラフィックを転送することはできません。

Note that these migration recommendations do not include considerations on when or how to evolve those intradomain applications best served by ASM/BIDIR-PIM from PIM-SM to BIDIR-PIM. This may also be important but is outside the scope of this document.

これらの移行の推奨事項は、PIM-SMからBidir-PIMへのASM / Bidir-PIMから最も役立つそれらの内翻訳アプリケーションをどのように進化させるかについての考慮事項を含まないことに注意してください。これは重要でも重要ですが、この文書の範囲外です。

5. Future Interdomain ASM Work

5. 将来のドメインasm勤務

Future work may attempt to overcome current limitations of ASM solutions, such as interdomain deployment solutions for BIDIR-PIM or source-access-control mechanisms for IPv6 PIM-SM with embedded-RP. Such work could modify or amend the recommendations of this document (like any future IETF Standards Track / BCP work).

将来の作業は、IPv6 PIM-SMのためのDodir-PIMまたはEmbedded-RPを備えたIPv6 PIM-SMのソースアクセス制御メカニズムなど、ASMソリューションの現在の制限を克服しようとする可能性があります。このような作業は、この文書の推奨事項を変更または修正することができました（将来のIETF規格のTRACK / BCPの作業と同様）。

Nevertheless, it is very unlikely that any ASM solution, even with such future work, can ever provide the same intrinsic security and network- and address-management simplicity as SSM (see Section 3.2). Accordingly, this document recommends that future work for general-purpose interdomain IP multicast focus on SSM items listed in Section 4.

それにもかかわらず、そのような将来の作業でさえも、SSMとして同じ固有のセキュリティとネットワーク管理のシンプルさを提供することができることは非常にほとんどありません（セクション3.2を参照）。したがって、この文書は、セクション4に記載されているSSM項目に対する汎用のイントラノンドメインIPマルチキャストの将来の作業を推奨しています。

6. Security Considerations

6. セキュリティに関する考慮事項

This document adds no new security considerations. It instead removes security issues incurred by interdomain ASM with PIM-SM/MSDP, such as infrastructure control-plane attacks and application and bandwidth/congestion attacks from unauthorized sources sending to ASM multicast groups. RFC 4609 describes the additional security benefits of using SSM instead of ASM.

このドキュメントは新しいセキュリティ上の考慮事項を追加しません。代わりに、インフラストラクチャの制御飛行機の攻撃やアプリケーションや帯域幅/輻輳攻撃など、PIM-SM / MSDPがASMマルチキャストグループに送信するなど、PIM-SM / MSDPで発生したセキュリティ問題を削除します。RFC 4609は、ASMの代わりにSSMを使用するという追加のセキュリティ上の利点を説明しています。

7. IANA Considerations

7. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1112] THERER、S。、STD 5、RFC 1112、DOI 10.17487 / RFC1112、<https://www.rfc-editor.org/info/rfc1112>。

[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <https://www.rfc-editor.org/info/rfc3307>.

[RFC3307] Haberman、B.、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、DOI 10.17487 / RFC3307、2002年8月、<https://www.rfc-editor.org/info/rfc3307>。

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.

[RFC3376] Cain、B.、Theering、S.、Kouvelas、I.、Fenner、B.、およびA.Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、<https://www.rfc-editor.org/info/rfc3376>。

[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC3810] VIDA、R.、ED。L. Costa、Ed。、「IPv6のマルチキャストリスナー発見バージョン2（MLDV2）、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https：//www.rfc-editor.org/info/rfc3810>。

[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, DOI 10.17487/RFC3956, November 2004, <https://www.rfc-editor.org/info/rfc3956>.

[RFC3956] Savola、P.およびB.B. Haberman、「IPv6マルチキャストアドレスにおけるRendezvous Point（RP）アドレスの埋め込み、RFC 3956、DOI 10.17487 / RFC3956、2004年11月、<https：//www.rfc-編集者。ORG / INFO / RFC3956>。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。

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

[RFC4607] Holbrook、H.およびB. CAIN、「IPのソース固有マルチキャスト」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<https://www.rfc-editor.org/info/rfc4607>。

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <https://www.rfc-editor.org/info/rfc5771>.

[RFC5771]綿、M.、Vegoda、L.、D.Meyer、「IANAガイドラインのIANAガイドライン」、BCP 51、RFC 5771、DOI 10.17487 / RFC5771、2010年3月、<https：//www.rfc-editor.org/info/rfc5771>。

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

[RFC7761] Fenner、B、Handley、M.、Holbrook、H.、Kouvelas、I。、Parekh、R.、Zhang、Z.、L.Zheng、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂） "、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https：//www.rfc-editor.org/info/rfc7761>。

[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., Ed., and R. Krishnan, "Use of Multicast across Inter-domain Peering Points", BCP 213, RFC 8313, DOI 10.17487/RFC8313, January 2018, <https://www.rfc-editor.org/info/rfc8313>.

[RFC8313] Tarapore、P.、ED。、Sayko、R.、Shepherd、G.、Eckert、T.、Ed。、R. Krishnan、「ドメイン間ピアリングポイント間のマルチキャストの使用」、BCP 213、RFC8313、DOI 10.17487 / RFC8313、2018年1月、<https://www.rfc-editor.org/info/rfc8313>。

8.2. Informative References

8.2. 参考引用

[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, <https://www.rfc-editor.org/info/rfc2375>.

[RFC2375] Hinden、R.およびS.Theering、 "IPv6マルチキャストアドレス割り当て"、RFC 2375、DOI 10.17487 / RFC2375、1998年7月、<https://www.rfc-editor.org/info/rfc2375>。

[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, September 2001, <https://www.rfc-editor.org/info/rfc3170>.

[RFC3170] Quinn、B.およびK. Almeroth、 "IPマルチキャストアプリケーション：課題とソリューション"、RFC 3170、DOI 10.17487 / RFC3170、2001年9月、<https://www.rfc-editor.org/info/rfc3170>。

[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, <https://www.rfc-editor.org/info/rfc3618>.

[RFC3618] Fenner、B、ED。D. Meyer、Ed。、「マルチキャストソース検出プロトコル（MSDP）」、RFC 3618、DOI 10.17487 / RFC3618、2003年10月、<https：//www.rfc-editor.org/info/rfc3618>。

[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, September 2004, <https://www.rfc-editor.org/info/rfc3913>.

[RFC3913] Thaler、D.、「ボーダーゲートウェイマルチキャストプロトコル（BGMP）：プロトコル仕様」、RFC 3913、DOI 10.17487 / RFC3913、2004年9月、<https：//www.rfc-editor.org/info/rfc3913>。

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.

[RFC4541] Christensen、M.、Kimball、K.、F. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチ（MLD）スヌーピングスイッチ（MLD）スヌーピングスイッチに関する考察 "、RFC 4541、DOI 10.17487 / RFC4541、2006年5月、<https://www.rfc-editor.org/info/rfc4541>。

[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.

[RFC4604] Holbrook、H.、Cain、B、B.B. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPv3）およびマルチキャストリスナーディスカバリープロトコルバージョン2（MLDv2）、RFC 4604、DOI10.17487 / RFC4604、2006年8月、<https://www.rfc-editor.org/info/rfc4604>。

[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609, October 2006, <https://www.rfc-editor.org/info/rfc4609>.

[RFC4609] Savola、P.、Lehtonen、R.、D. Meyer、「プロトコル独立マルチキャスト - スパースモード（PIM-SM）マルチキャストルーティングセキュリティ問題と機能強化」、RFC 4609、DOI 10.17487 / RFC4609、2006年10月、<https://www.rfc-editor.org/info/rfc4609>。

[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, <https://www.rfc-editor.org/info/rfc4610>.

[RFC4610] Farinacci、D.およびY. CAI、「Anycast-RP（Protocol Independent Multicast（PIM）」、RFC 4610、DOI 10.17487 / RFC4610、2006年8月、<https://www.rfc-editor.org/info/ RFC4610>。

[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, RFC 4611, DOI 10.17487/RFC4611, August 2006, <https://www.rfc-editor.org/info/rfc4611>.

[RFC4611] McBride、M.、Meylor、J.、およびD.Meyer、「マルチキャストソース検出プロトコル（MSDP）展開シナリオ」、BCP 121、RFC 4611、DOI 10.17487 / RFC4611、2006年8月、<HTTPS：// WWW.rfc-editor.org / info / rfc4611>。

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

[RFC5015]ハンドリー、M.、Kouvelas、I。、Speakman、T.、およびL.県県県県県、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<https：//www.rfc-editor.org/info/rfc5015>。

[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.

[RFC6763] Cheshire、S.およびM. Krochmal、「DNSベースのサービス発見」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https：//www.rfc-editor.org/info/rfc6763>。

[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.

[RFC8504] Chown、T.、Loughney、J.、およびT.Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487 / RFC8504、2019年1月、<https：//www.rfc-editor.org/ info / rfc8504>。

Acknowledgments

謝辞

The authors would like to thank members of the IETF MBONE Deployment Working Group for discussions on the content of this document, with specific thanks to the following people for their contributions to the document: Hitoshi Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and Sandy Zhang.

著者らは、この文書の内容に関する議論のためにIETF MBONE展開ワーキンググループのメンバーに感謝します。この文書への貢献については、次のような人々に貢献しています。McBride、Nihlen、Greg Shepherd、James Stevens、Stig Venaas、Nils Warnke、Sandy Zhang。

Authors' Addresses

著者の住所

Mikael Abrahamsson Stockholm Sweden

Mikael Abrahamssonストックホルムスウェーデン

   Email: swmike@swm.pp.se

Tim Chown Jisc Harwell Oxford Lumen House, Library Avenue Didcot OX11 0SG United Kingdom

Tim Chown Jisc Harwellオックスフォードルーメンハウス、図書館Avenue Didcot OX11 0SGイギリス

   Email: tim.chown@jisc.ac.uk

Lenny Giuliano Juniper Networks, Inc. 2251 Corporate Park Drive Herndon, Virginia 20171 United States of America

Lenny Giuliano Juniper Networks、Inc。2251 Corporate Park Drive Herndon、Virginia 20171アメリカ合衆国

   Email: lenny@juniper.net

Toerless Eckert Futurewei Technologies Inc. 2330 Central Expy Santa Clara, California 95050 United States of America

TOERLESS ECKERT FUTOUREWII Technologies Inc. 2330 Central Expy Santa Clara、カリフォルニア州95050アメリカ合衆国

   Email: tte@cs.fau.de