rfc2365.txt

RFC 的详细文档！

Network Working Group                                           D. Meyer
Request for Comments: 2365                          University of Oregon
BCP: 23                                                        July 1998
Category: Best Current Practice


                  Administratively Scoped IP Multicast

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 (1998).  All Rights Reserved.

1. Abstract

   This document defines the "administratively scoped IPv4 multicast
   space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
   describes a simple set of semantics for the implementation of
   Administratively Scoped IP Multicast. Finally, it provides a mapping
   between the IPv6 multicast address classes [RFC1884] and IPv4
   multicast address classes.

   This memo is a product of the MBONE Deployment Working Group (MBONED)
   in the Operations and Management Area of the Internet Engineering
   Task Force. Submit comments to <[e-mail]> or the author.

2. Acknowledgments

   Much of this memo is taken from "Administratively Scoped IP
   Multicast", Van Jacobson and Steve Deering, presented at the 30th
   IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
   Dave Thaler have also provided insightful comments on earlier
   versions of this document.

3. Introduction

   Most current IP multicast implementations achieve some level of
   scoping by using the TTL field in the IP header. Typical MBONE
   (Multicast Backbone) usage has been to engineer TTL thresholds that
   confine traffic to some administratively defined topological region.
   The basic forwarding rule for interfaces with configured TTL
   thresholds is that a packet is not forwarded across the interface
   unless its remaining TTL is greater than the threshold.



Meyer                    Best Current Practice                  [Page 1]

RFC 2365          Administratively Scoped IP Multicast         July 1998


   TTL scoping has been used to control the distribution of multicast
   traffic with the objective of easing stress on scarce resources
   (e.g., bandwidth), or to achieve some kind of improved privacy or
   scaling properties. In addition, the TTL is also used in its
   traditional role to limit datagram lifetime. Given these often
   conflicting roles, TTL scoping has proven difficult to implement
   reliably, and the resulting schemes have often been complex and
   difficult to understand.

   A more serious architectural problem concerns the interaction of TTL
   scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The
   particular problem is that in many common cases, TTL scoping can
   prevent pruning from being effective. Consider the case in which a
   packet has either had its TTL expire or failed a TTL threshold. The
   router which discards the packet will not be capable of pruning any
   upstream sources, and thus will sink all multicast traffic (whether
   or not there are downstream receivers). Note that while it might seem
   possible to send prunes upstream from the point at which a packet is
   discarded, this strategy can result in legitimate traffic being
   discarded, since subsequent packets could take a different path and
   arrive at the same point with a larger TTL.

   On the other hand, administratively scoped IP multicast can provide
   clear and simple semantics for scoped IP multicast. The key
   properties of administratively scoped IP multicast are that (i).
   packets addressed to administratively scoped multicast addresses do
   not cross configured administrative boundaries, and (ii).
   administratively scoped multicast addresses are locally assigned, and
   hence are not required to be unique across administrative boundaries.

4. Definition of the Administratively Scoped IPv4 Multicast Space

   The administratively scoped IPv4 multicast address space is defined
   to be the range 239.0.0.0 to 239.255.255.255.

5. Discussion

   In order to support administratively scoped IP multicast, a router
   should support the configuration of per-interface scoped IP multicast
   boundaries. Such a router, called a boundary router, does not forward
   packets matching an interface's boundary definition in either
   direction (the bi-directional check prevents problems with multi-
   access networks). In addition, a boundary router always prunes the
   boundary for dense-mode groups [PIMDM], and doesn't accept joins for
   sparse-mode groups [PIMSM] in the administratively scoped range.






Meyer                    Best Current Practice                  [Page 2]

RFC 2365          Administratively Scoped IP Multicast         July 1998


6. The Structure of the Administratively Scoped Multicast Space

   The structure of the IP version 4 administratively scoped multicast
   space is loosely based on the IP Version 6 Addressing Architecture
   described in RFC 1884 [RFC1884]. This document defines two important
   scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These
   scopes are described below.

6.1. The IPv4 Local Scope -- 239.255.0.0/16

   239.255.0.0/16 is defined to be the IPv4 Local Scope.  The Local
   Scope is the minimal enclosing scope, and hence is not further
   divisible. Although the exact extent of a Local Scope is site
   dependent, locally scoped regions must obey certain topological
   constraints. In particular, a Local Scope must not span any other
   scope boundary. Further, a Local Scope must be completely contained
   within or equal to any larger scope. In the event that scope regions
   overlap in area, the area of overlap must be in its own local scope.
   This implies that any scope boundary is also a boundary for the Local
   Scope. The more general topological requirements for administratively
   scoped regions are discussed below.

   6.1.1. Expansion of the IPv4 Local Scope

   The IPv4 Local Scope space grows "downward". As such, the IPv4 Local
   Scope may grow downward from 239.255.0.0/16 into the reserved ranges
   239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not
   be utilized until the 239.255.0.0/16 space is no longer sufficient.

6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14

   239.192.0.0/14 is defined to be the IPv4 Organization Local Scope,
   and is the space from which an organization should allocate sub-
   ranges when defining scopes for private use.

6.2.1. Expansion of the IPv4 Organization Local Scope

   The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are
   unassigned and available for expansion of this space.  These ranges
   should be left unassigned until the 239.192.0.0/14 space is no longer
   sufficient. This is to allow for the possibility that future
   revisions of this document may define additional scopes on a scale
   larger than organizations.

6.3. Other IPv4 Scopes of Interest

   The other two scope classes of interest, statically assigned link-
   local scope and global scope already exist in IPv4 multicast space.



Meyer                    Best Current Practice                  [Page 3]

RFC 2365          Administratively Scoped IP Multicast         July 1998


   The statically assigned link-local scope is 224.0.0.0/24. The
   existing static global scope allocations are somewhat more granular,
   and include

        224.1.0.0-224.1.255.255         ST Multicast Groups
        224.2.0.0-224.2.127.253         Multimedia Conference Calls
        224.2.127.254                   SAPv1 Announcements
        224.2.127.255                   SAPv0 Announcements (deprecated)
        224.2.128.0-224.2.255.255       SAP Dynamic Assignments
        224.252.0.0-224.255.255.255     DIS transient groups
        232.0.0.0-232.255.255.255       VMTP transient groups

   See [RFC1700] for current multicast address assignments (this list
   can also be found, possibly in a more current form, on
   ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).

7. Topological Requirements for Administrative Boundaries

   An administratively scoped IP multicast region is defined to be a
   topological region in which there are one or more boundary routers
   with common boundary definitions. Such a router is said to be a
   boundary for scoped addresses in the range defined in its
   configuration.

   Network administrators may configure a scope region whenever
   constrained multicast scope is required. In addition, an
   administrator may configure overlapping scope regions (networks can
   be in multiple scope regions) where convenient, with the only
   limitations being that a scope region must be connected (there must
   be a path between any two nodes within a scope region that doesn't
   leave that region), and convex (i.e., no path between any two points
   in the region can cross a region boundary). However, it is important
   to note that if administratively scoped areas intersect
   topologically, then the outer scope must consist of its address space
   minus the address spaces of any intersecting scopes. This requirement
   prevents the problem that would arise when a path between two points
   in a convex region crosses the boundary of an intersecting region.
   For this reason, it is recommended that administrative scopes that
   intersect topologically should not intersect in address range.

   Finally, note that any scope boundary is a boundary for the Local
   Scope. This implies that packets sent to groups covered by
   239.255.0.0/16 must not be forwarded across any link for which a
   scoped boundary is defined.







Meyer                    Best Current Practice                  [Page 4]