MBONED Working Group                                         David Meyer
Internet Draft                                      University of Oregon
Category                                           Best Current Practice                            April 1997
                  Administratively Scoped IP Multicast

1. Status of this Memo

   This document specifies an Internet Best Current Practice for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Internet Drafts

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

2. Abstract

   This document defines the "administratively scoped IPv4 multicast
   space" to be the range to . 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 Operational Requirements area Operations and Management Area of the Internet Engineering
   Task Force. Submit comments to <> or the author.

3. 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 draft. document.

4. Introduction

   Most current IP multicast implementations achieve some level of scop-
   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.

   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 tradi-
   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 under-
   stand. understand.

   A more serious architectural problem with concerns the interaction of TTL
   scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The
   particular problem is that, that in many common cases, it TTL scoping can
   prevent pruning from being effective. Consider the case in which a
   packet either has either had its TTL expire or does not meet failed a TTL threshold. The point (e.g., tunnel, interface) at
   router which discards the packet fails the TTL check will not be capable of pruning any
   upstream sources, and hence thus will sink all traffic, independent of whether multicast traffic (whether
   or not there are downstream group members. receivers). Note that without somehow associating prune
   state and TTL, this problem will persist. For example, while it might seem
   possible to send a prune prunes upstream from the point where the at which a packet is
   discarded, this strategy could prevent can result in legitimate traffic
   from being forwarded (subsequent
   discarded, since subsequent packets could take a different path and wind up
   arrive at the same point with a larger TTL). However, if a prune
   had been sent, the packet may not be forwarded on interfaces that it
   should have been. TTL.

   On the other hand, by using administratively scoped IP multicast, one
   can achieve locally scoped multicast with simple, can provide
   clear semantics. and simple semantics for scoped IP multicast. The key
   properties of any implementation 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. These properties are sufficient to imple-
   ment administrative scoping.


5. Definition of the Administratively Scoped IPv4 Multicast Address Space

   IANA should allocate

   The administratively scoped IPv4 multicast address space is defined
   to be the range to to be
   the "Administratively Scoped IPv4 Multicast" address space.

6. 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 its an interface's boundary definition in either
   direction across its
   border (the bi-directional check prevents problems with  multi-access multi-
   access networks). In addition, a boundary router always prunes the
   boundary for dense-mode groups, or groups [PIMDM], and doesn't accept joins for
   sparse-mode groups [PIMSM] in the administratively scoped range.

7. 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. The following table outlines the partitioning of 1884 [RFC1884]. This document defines two important
   scopes: the IPv4 multicast space, Local Scope and gives the mapping to IPv6 SCOP values

   IPv6 SCOP         RFC 1884 Description IPv4 Prefix
      0                  reserved
      1                  node-local scope
      2                  link-local scope   
      3                  (unassigned)       
      4                  (unassigned)       
      5                  site-local scope   
      6                  (unassigned)
      7                  (unassigned)
      8                  organization-local scope
      A                  (unassigned)
      B                  (unassigned)
      C                  (unassigned)
      D                  (unassigned)
      E                  global scope       
      F                  reserved
                         (unassigned)        Organization Local Scope. These
   scopes are described below.

7.1. The IPv4 Local Scope -- is defined to be the IPv4 Local Scope.  While how local  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.  That is, it Further, a Local Scope must be completely contained within,
   within or equal to, to any larger scope. In the event that two scope regions
   overlap in area, the area that overlaps of overlap must be in it's its own local scope.
   This also means implies that any scope boundary is also a boundary for the Local
   Scope. The more general topological requirements for admin-
   istratively administratively
   scoped regions are discussed below.

7.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 into the reserved ranges and However, these ranges should not
   be utilized until the space is no longer sufficient.

7.2. The IPv4 Organization Local Scope -- 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.

7.2.1. Expansion of the IPv4 Organization Local Scope

   The ranges, and are
   unassigned and available for expansion of this space.  These ranges
   should be left unassigned until the 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.

7.3. Other IPv4 Scopes of Interest

   The other two scope classes of interest, statically assigned link-
   local scope and global scope already exist to some extent in IP ver-
   sion 4 IPv4 multicast space. In particular, the
   The statically assigned link-
   local link-local scope is The
   existing static global scope allocations are currently somewhat more granular,
   and include

          ST Multicast Groups
          Multimedia Conference Calls
                    SAPv1 Announcements
                    SAPv0 Announcements (deprecated)
        SAP Dynamic Assignments
      DIS transient groups
        VMTP transient groups

   See [RFC1700] for current multicast address assignments. assignments (this list
   can also be found, possibly in a more current form, on

8. 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 boun-
   boundary for scoped addresses in the range defined in its

   Network administrators may configure a scope region whenever local
   constrained multicast scope is required. In addition, an
   administrator may con-
   figure 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 con-
   vex convex (i.e., no path between any two points
   in the region can cross a region boundary).

   Finally, as mentioned above, an important con-
   straint on the configuration of local scopes is that the local scope
   must not span any other boundary.

   Finally, note that any scope boundary is a boundary for the Local
   Scope. This implies that packets sent to groups in the 239.255/16
   range covered by must not be forwarded across any link with any scoped boundary
   defined. That is, setting a boundary on a link for any prefix must
   also set a boundary on that link for the local scope prefix.

Example: DVMRP

   DVMRP [DVMRP] implementations could be extended to support which a
   scoped boundary
   attribute in is defined.

9. Partitioning of the interface configuration [ASMA]. Administratively Scoped Multicast Space

   The boundary attri-
   bute that includes a prefix and mask, and has following table outlines the semantics that
   packets matching partitioning of the prefix IPv4 multicast
   space, and mask do not not pass the boundary. As
   mentioned above, the implementation would also prune gives the boundary. mapping from IPv4 multicast prefixes to IPv6
   SCOP values:

   IPv6 SCOP         RFC 1884 Description             IPv4 Prefix
      0                  reserved
      1                  node-local scope
      2                  link-local scope   
      3                  (unassigned)       
      4                  (unassigned)
      5                  site-local scope
      6                  (unassigned)
      7                  (unassigned)
      8                  organization-local scope
      A                  (unassigned)
      B                  (unassigned)
      C                  (unassigned)
      D                  (unassigned)
      E                  global scope       
      F                  reserved

10. Security Considerations

   While security considerations are not explicitly discussed in this
   memo, it is important to note that a boundary router as described
   here should not be considered to provide any kind of firewall func-

11. References

      [ASMA]    V. Jacobson,  S. Deering, "Administratively Scoped IP
                Multicast", , presented at the 30th IETF, Toronto,
                Canada, 25 July 1994.

      [DVMRP]   T. Pusateri, "Distance Vector Multicast Routing
                Protocol", draft-ietf-idmr-dvmrp-v3-03, draft-ietf-idmr-dvmrp-v3-03.txt,
                September, 1996.

      [RFC1884] R. Hinden.

      [PIMDM]   Deering, S, et. al., "IP "Protocol Independent Multicast
                Version 6 Addressing
                Architecture", RFC1884, December 1995. 2, Dense Mode Specification",
                draft-ietf-idmr-pim-dm-05.txt, April, 1997.

      [PIMSM]   Estrin, D, et. al., "Protocol Independent Multicast
                Sparse Mode (PIM-SM): Protocol Specification",
      , March, 1996. 1997.

      [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,

      [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
                Architecture", RFC1884, December 1995.

12. Author's Address

   David Meyer
   Advanced Network Technology Center
   University of Oregon
   1225 Kincaid St.
   Eugene, OR 97403

   phone:  +1 541.346.1747