Network Working Group D. Meyer
Request for Comments: 4608 R. Rockell
BCP: 120 G. Shepherd
Category: Best Current Practice August 2006
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).
版权所有（C）互联网协会（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
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组地址范围内的操作最佳通用做法是必要的，以确保跨Internet中多个域的最短路径仅源目录树[RFC3569]，并防止发送到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 防止RPs作为232/8的候选
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工作组（或随后的边界网关多播协议（BGMP）工作组）从未产生过可以部署以取代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被归类为实验性协议的一个主要原因是，MSDP工作组提出了对协议的修改，工作组认为这些修改使协议变得更好，但实施者看不到任何部署的理由。如果没有这些修改（例如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 Internet中事实上的标准域间多播协议几乎无处不在。
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 未能就修改MSDP以解决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编辑关于参考文献的政策是将参考文献分为“规范性”和“信息性”两类。规范性参考文件规定了为理解或实施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采取的政策是，BCP不得对实验协议进行规范性引用。然而，本文件是一个特例，因为基本实验文件（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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 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
为了在232/8中消除组共享树的使用，同时在PIM-SM中保持与ASM的共存，需要修改RP和/或DR的行为。这可以通过以下方式实现：
- preventing data for 232/8 groups from being sent encapsulated to the RP by the DR,
- 防止DR将232/8组的数据封装发送到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组的接受数据（*，G）树。
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）连接直接发送到源。为防止SAs在232/8范围内传播，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为232/8组发送（*，G）联接，以及
- preventing RP from accepting (*,G) join for 232/8 groups.
- 阻止RP接受（*，G）232/8组的连接。
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域内，任何不阻止（*，G）连接的最后一跳路由器可能会向与现有（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不应允许（*，G）在232/8范围内加入。
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，所以所有RP都不应提供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的任何其他超集）的广告仍然可以接受；然而，这种方法依赖于上述第二点；也就是说，如前所述，路由器在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.
本文档是多播社区中许多人的作品，包括（但不限于）迪诺·法里纳奇、约翰·梅洛、约翰·兹维贝尔、汤姆·普萨特里、戴夫·泰勒、无趾埃克特、伦纳德·朱利亚诺、迈克·麦克布莱德和佩卡·萨沃拉。
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
但是，如果不遵守本文件中描述的操作规程，可能会出现一些问题。特别是，第2.3节描述了最后一跳路由器（或在某种程度上，发送PIM消息的恶意主机本身）不符合性对源特定服务模型的影响。创建
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.
源特定（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，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年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）”，RFC3618，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
EMail: dmm@1-4-5.net
Robert Rockell Sprint
罗伯特·洛克尔斯普林特
EMail: rrockell@sprint.net
EMail: rrockell@sprint.net
Greg Shepherd Cisco
格雷格·谢泼德·思科
EMail: gjshep@gmail.com
EMail: gjshep@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。