datatracker.ietf.org
Sign in
Version 5.6.2.p6, 2014-09-03
Report a bug

Source-Specific Protocol Independent Multicast in 232/8
RFC 4608

Document type: RFC - Best Current Practice (August 2006; No errata)
Also Known As BCP 120
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4608 (Best Current Practice)
Responsible AD: David Kessens
Send notices to: <dmm@1-4-5.net>,<sob@harvard.edu>

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),

[include full document text]