[要約] RFC 4608は、232/8の範囲でのソース固有のプロトコル非依存のマルチキャストに関する要約です。このRFCの目的は、ソース固有のマルチキャストをサポートするためのプロトコル仕様を提供することです。
Network Working Group D. Meyer
Request for Comments: 4608 R. Rockell
BCP: 120 G. Shepherd
Category: Best Current Practice August 2006
Source-Specific Protocol Independent Multicast in 232/8
232/8のソース固有のプロトコル独立マルチキャスト
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range.
232/8（232.0.0.0〜232.255.255.255）のIPマルチキャストグループアドレスは、ソース固有のマルチキャスト宛先アドレスとして指定されており、ソース固有のマルチキャストアプリケーションとプロトコルで使用するために予約されています。このドキュメントでは、232/8の範囲内でソース固有の動作を確保するための運用上の推奨事項を定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. BCP, Experimental Protocols, and Normative References ......2
2. Operational practices in 232/8 ..................................4
2.1. Preventing Local Sources from Sending to Shared Tree .......4
2.2. Preventing Remote Sources from Being Learned/Joined
via MSDP ...................................................4
2.3. Preventing Receivers from Joining the Shared Tree ..........4
2.4. Preventing RPs as Candidates for 232/8 .....................5
3. Acknowledgements ................................................5
4. Security Considerations .........................................5
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informative References .....................................6
Current Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] relies on the shared Rendezvous Point (RP) tree to learn about active sources for a group and to support group-generic (Any Source Multicast or ASM) data distribution. The IP Multicast group address range 232/8 has been designated for Source-Specific Multicast [RFC3569] applications and protocols [IANA] and SHOULD support source-only trees only, precluding the requirement of an RP and a shared tree; active sources in the 232/8 range will be discovered out of band. PIM Sparse Mode Designated Routers (DR) with local membership are capable of joining the shortest path tree for the source directly using SSM functionality of PIM-SM.
現在のプロトコル独立マルチキャスト - スパースモード（PIM-SM）[RFC4601]は、共有ランデブーポイント（RP）ツリーに依存して、グループのアクティブソースについて学び、グループジェネリック（任意のソースマルチキャストまたはASM）データ分布をサポートします。IPマルチキャストグループアドレス範囲232/8は、ソース固有のマルチキャスト[RFC3569]アプリケーションとプロトコル[IANA]に指定されており、RPと共有ツリーの要件を排除して、ソース専用ツリーのみをサポートする必要があります。232/8の範囲のアクティブソースは、バンドから発見されます。PIMスパースモード指定ルーター（DR）は、ローカルメンバーシップを使用して、PIM-SMのSSM機能を使用して、ソースの最短パスツリーを直接結合できます。
Operational best common practices in the 232/8 group address range are necessary to ensure shortest path source-only trees across multiple domains in the Internet [RFC3569], and to prevent data from sources sending to groups in the 232/8 range from arriving via shared trees. This avoids unwanted data arrival and allows several sources to use the same group address without conflict at the receivers.
インターネット内の複数のドメインにわたって最短のパスソースのみのツリーを確保し、232/8の到着から到着してから232/8のグループに送信するソースからのデータを防ぐためには共有木。これにより、不要なデータの到着が回避され、いくつかのソースがレシーバーで競合することなく同じグループアドレスを使用できます。
The operational practices SHOULD:
運用慣行は次のとおりです。
o Prevent local sources from sending to shared tree
o ローカルソースが共有ツリーに送信できないようにします
o Prevent receivers from joining the shared tree
o レシーバーが共有ツリーに参加できないようにします
o Prevent RPs as candidates for 232/8
o 232/8の候補としてRPSを防ぎます
o Prevent remote sources from being learned/joined via Multicast Source Discovery Protocol (MSDP) [RFC3618]
o マルチキャストソースディスカバリープロトコル（MSDP）[RFC3618]を介してリモートソースが学習/結合されるのを防ぐ
This document describes the best current practice for a widely deployed Experimental protocol, MSDP. There is no plan to advance MSDP's status (for example, to Proposed Standard). The reasons for this include:
このドキュメントでは、広く展開されている実験プロトコルであるMSDPの最良の現在のプラクティスについて説明しています。MSDPのステータスを前進させる計画はありません（たとえば、提案された標準）。これの理由は次のとおりです。
o MSDP was originally envisioned as a temporary protocol to be supplanted by whatever the Inter-Domain Multicast Routing (IDMR) working group produced as an inter-domain protocol. However, the IDMR WG (or subsequently, the Border Gateway Multicast Protocol (BGMP) WG) never produced a protocol that could be deployed to replace MSDP.
o MSDPはもともと、ドメイン間プロトコルとして作成されたドメイン間マルチキャストルーティング（IDMR）ワーキンググループが何であれ、一時的なプロトコルとして想定されていました。ただし、IDMR WG（またはその後、Border Gateway Multicast Protocol（BGMP）WG）は、MSDPを置き換えるために展開できるプロトコルを作成しませんでした。
o One of the primary reasons given for MSDP to be classified as Experimental was that the MSDP Working Group came up with modifications to the protocol that the WG thought made it better but that implementors didn't see any reasons to deploy. Without these modifications (e.g., UDP or GRE encapsulation), MSDP can have negative consequences to initial packets in datagram streams.
o MSDPが実験として分類される主な理由の1つは、MSDPワーキンググループがWGが考えたプロトコルの変更を考え出したことでした。これらの変更（UDPやGREのカプセル化など）がなければ、MSDPはデータグラムストリームの初期パケットにマイナスの結果をもたらす可能性があります。
o Scalability: Although we don't know what the hard limits might be, readvertising everything you know every 60 seconds clearly limits the amount of state you can advertise.
o スケーラビリティ：厳しい制限が何であるかはわかりませんが、60秒ごとに知っているすべてを読み取り、宣伝できる状態の量を明確に制限します。
o MSDP reached nearly ubiquitous deployment as the de facto standard inter-domain multicast protocol in the IPv4 Internet.
o MSDPは、IPv4インターネットでの事実上の標準標準のドメイン間マルチキャストプロトコルとして、ほぼユビキタスな展開に達しました。
o No consensus could be reached regarding the reworking of MSDP to address the many concerns of various constituencies within the IETF. As a result, a decision was taken to document what is (ubiquitously) deployed and to move that document to Experimental. Although advancement of MSDP to Proposed Standard was considered, for the reasons mentioned above, it was immediately discarded.
o IETF内のさまざまな選挙区の多くの懸念に対処するために、MSDPの再加工に関してはコンセンサスに達することはできませんでした。その結果、（遍在的に）展開されているものを文書化し、そのドキュメントを実験的に移動するという決定が下されました。提案された標準へのMSDPの進歩は考慮されましたが、上記の理由により、すぐに廃棄されました。
o The advent of protocols such as source-specific multicast and bi-directional PIM, as well as embedded RP techniques for IPv6, have further reduced consensus that a replacement protocol for MSDP for the IPv4 Internet is required.
o ソース固有のマルチキャストや双方向PIMなどのプロトコルの出現、およびIPv6の埋め込みRPテクニックは、IPv4インターネットのMSDPの交換プロトコルが必要であるというコンセンサスをさらに減らしました。
The RFC Editor's policy regarding references is that they be split into two categories known as "normative" and "informative". Normative references specify those documents that must be read for one to understand or implement the technology in an RFC (or whose technology must be present for the technology in the new RFC to work) [RFCED]. In order to understand this document, one must also understand both the PIM [RFC4601] and MSDP [RFC3618] documents. As a result, references to these documents are normative.
参照に関するRFCエディターのポリシーは、それらが「規範」および「有益」として知られる2つのカテゴリに分割されることです。規範的参照は、RFCでテクノロジーを理解または実装するために読む必要があるドキュメントを指定します（または、新しいRFCのテクノロジーが機能するためにテクノロジーが存在する必要があります）[RFCED]。この文書を理解するには、PIM [RFC4601]とMSDP [RFC3618]ドキュメントの両方を理解する必要があります。その結果、これらのドキュメントへの言及は規範的です。
The IETF has adopted the policy that BCPs must not have normative references to Experimental protocols. However, this document is a special case in that the underlying Experimental document (MSDP) is not planned to be advanced to Proposed Standard.
IETFは、BCPSが実験プロトコルへの規範的な参照を持っていてはならないというポリシーを採用しています。ただし、このドキュメントは、基礎となる実験文書（MSDP）が提案された標準に進む予定ではないという特別なケースです。
The MBONED Working Group requests approval under the Variance Procedure as documented in RFC 2026 [RFC2026]. The IESG followed the Variance Procedure and, after an additional 4-week IETF Last Call, evaluated the comments and status and has approved the document.
MBONEDワーキンググループは、RFC 2026 [RFC2026]で文書化されているように、分散手順に基づく承認を要求します。IESGは分散手順に従い、追加の4週間のIETF最後の呼び出しの後、コメントとステータスを評価し、ドキュメントを承認しました。
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
「必須」、「必要」、「必須」、「「shall」、「shall」、「obs "、" should "、" nove "、" becommented "、" "、" optional "、「suld」、" wheRFC 2119 [RFC2119]に記載されているように解釈されます。
In order to eliminate the use of shared trees for groups in 232/8, while maintaining coexistence with ASM in PIM-SM, the behavior of the RP and/or the DR needs to be modified. This can be accomplished by
PIM-SMのASMとの共存を維持しながら、232/8のグループの共有ツリーの使用を排除するには、RPおよび/またはDRの挙動を変更する必要があります。これはによって達成できます
- preventing data for 232/8 groups from being sent encapsulated to the RP by the DR,
- 232/8グループのデータがDRによってRPにカプセル化されるのを防ぐ、
- preventing the RP from accepting registers for 232/8 groups from the DR, and
- RPがDRから232/8グループのレジスタを受け入れるのを防ぐと
- preventing the RP from forwarding accepted data down (*,G) tree for 232/8 groups.
- RPが受け入れられたデータを232/8グループのツリーに転送するのを防ぎます。
SSM does not require active source announcements via MSDP. All source announcements are received out of band, and the last hop router is responsible for sending (S,G) joins directly to the source. To prevent propagation of SAs in the 232/8 range, an RP SHOULD
SSMは、MSDPを介したアクティブなソースアナウンスを必要としません。すべてのソースアナウンスはバンドから受け取られ、最後のホップルーターはソースに直接結合する（s、g）を送信する責任があります。232/8の範囲でのSASの伝播を防ぐために、RPは
- never originate an SA for any 232/8 groups, and
- 232/8グループのSAを発信することはありません。
- never accept or forward an SA for any 232/8 groups.
- 232/8グループのSAを受け入れたり転送したりしないでください。
Local PIM domain practices need to be enforced to prevent local receivers from joining the shared tree for 232/8 groups. This can be accomplished by
ローカルPIMドメインのプラクティスは、232/8グループのローカルレシーバーが共有ツリーに参加するのを防ぐために実施する必要があります。これはによって達成できます
- preventing DR from sending (*,G) joins for 232/8 groups, and
- DRの送信（*、g）が232/8グループに参加するのを防ぎ、
- preventing RP from accepting (*,G) join for 232/8 groups.
- RPが232/8グループに参加するのを防ぐ（*、g）。
However, within a local PIM domain, any last-hop router NOT preventing (*,G) joins may trigger unwanted (*,G) state toward the RP that intersects an existing (S,G) tree, allowing the receiver on the shared tree to receive the data, which breaks the source-specific
ただし、ローカルPIMドメイン内では、結合を防止しないラストホップルーターはすべて、既存の（s、g）ツリーと交差するRPに向かって不要な（*、g）状態をトリガーする場合があり、共有のレシーバーが共有されます。ソース固有のデータを壊すデータを受信するツリー
[RFC3569] service model. It is therefore recommended that ALL routers in the domain MUST reject AND never originate (*,G) joins for 232/8 groups.
[RFC3569]サービスモデル。したがって、ドメイン内のすべてのルーターが拒否し、232/8グループに結合することはない（*、g）を拒否しないことをお勧めします。
In those cases in which an ISP is offering its customers (or others) the use of the ISP's RP, the ISP SHOULD NOT allow (*,G) joins in the 232/8 range.
ISPが顧客（または他の人）にISPのRPの使用を提供している場合、ISPは232/8の範囲に参加することはできません（*、g）。
Because SSM does not require an RP, all RPs SHOULD NOT offer themselves as candidates in the 232/8 range. This can be accomplished by
SSMはRPを必要としないため、すべてのRPSは232/8の範囲の候補者として自分自身を提供するべきではありません。これはによって達成できます
- preventing RP/BSR from announcing in the 232/8 range,
- RP/BSRが232/8の範囲で発表するのを防ぐ、
- preventing ALL routers from accepting RP delegations in the 232/8 range, and
- すべてのルーターが232/8の範囲でRP代表団を受け入れるのを防ぐ、
- precluding RP functionality on RP for the 232/8 range.
- 232/8範囲のRPでRP機能を排除します。
Note that in typical practice, RPs announce themselves as candidates for the 224/4 (which obviously includes 232/8). It is still acceptable to allow the advertisement of 224/4 (or any other superset of 232/8); however, this approach relies on the second point, above; namely, that routers silently ignore the RP delegation in the 232/8 range and prevent sending or receiving using the shared tree, as described previously. Finally, an RP SHOULD NOT be configured as a candidate RP for 232/8 (or for a more specific range).
典型的な実践では、RPSは224/4の候補者としての地位を発表していることに注意してください（明らかに232/8を含む）。224/4（または232/8のその他のスーパーセット）の広告を許可することはまだ許容されます。ただし、このアプローチは上記の2番目のポイントに依存しています。つまり、ルーターは232/8の範囲のRP委任を静かに無視し、以前に説明したように共有ツリーを使用して送信または受信しないようにします。最後に、RPを232/8の候補RPとして構成しないでください（またはより具体的な範囲の場合）。
This document is the work of many people in the multicast community, including (but not limited to) Dino Farinacci, John Meylor, John Zwiebel, Tom Pusateri, Dave Thaler, Toerless Eckert, Leonard Giuliano, Mike McBride, and Pekka Savola.
この文書は、Dino Farinacci、John Meylor、John Zwiebel、Tom Pusateri、Dave Thaler、Toerless Eckert、Leonard Giuliano、Mike McBride、Pekka Savolaなど、マルチキャストコミュニティの多くの人々の仕事です（ただし、これらに限定されませんが）。
This document describes operational practices that introduce no new security issues to PIM-SM [RFC4601] in either or SSM [RFC3569] or ASM operation.
このドキュメントは、いずれかまたはSSM [RFC3569]またはASM操作のPIM-SM [RFC4601]に新しいセキュリティの問題を導入しない運用慣行について説明します。
However, in the event that the operational practices described in this document are not adhered to, some problems may surface. In particular, Section 2.3 describes the effects of non-compliance of last-hop routers (or, to some degree, rogue hosts sending PIM messages themselves) on the source-specific service model. Creating the (*,G) state for source-specific (S,G) could enable a receiver to receive data it should not get. This can be mitigated by host-side multicast source filtering.
ただし、このドキュメントで説明されている運用慣行が順守されていない場合、いくつかの問題が発生する可能性があります。特に、セクション2.3では、ソース固有のサービスモデルに対する最終ホップルーター（または、ある程度、PIMメッセージ自体を送信するRogueホスト）の非コンプライアンスの効果について説明します。ソース固有（s、g）の（*、g）状態を作成すると、受信者が取得しないデータを受信できるようになります。これは、ホスト側のマルチキャストソースフィルタリングによって軽減できます。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、 "Protocol Independent Multicast -Sparse Mode（PIM -SM）：Protocol Specification（改訂）、RFC 4601、2006年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[IANA] http://www.iana.org
[IANA] http://www.iana.org
[RFCED] http://www.rfc-editor.org/policy.html
[rfced] http://www.rfc-editor.org/policy.html
Authors' Addresses
著者のアドレス
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
Robert Rockell Sprint
ロバート・ロッケル・スプリント
EMail: rrockell@sprint.net
Greg Shepherd Cisco
グレッグシェパードシスコ
EMail: gjshep@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。