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
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).
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.
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
Meyer, et al. Best Current Practice [Page 1]
RFC 4608 Source-Specific PIM in 232/8 August 2006
1. Introduction
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.
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.
The operational practices SHOULD:
o Prevent local sources from sending to shared tree
o Prevent receivers from joining the shared tree
o Prevent RPs as candidates for 232/8
o Prevent remote sources from being learned/joined via Multicast
Source Discovery Protocol (MSDP) [RFC3618]
1.1. BCP, Experimental Protocols, and Normative References
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:
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.
Meyer, et al. Best Current Practice [Page 2]
RFC 4608 Source-Specific PIM in 232/8 August 2006
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),
datatracker.ietf.org