INTERNET-DRAFT                                           David Meyer
draft-ietf-mboned-admin-ip-space-02.txt         University of Oregon
Category:Best Current Practice                         December 1996                            April 1997

                  Administratively Scoped IP Multicast

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


   This document defines the "administratively scoped IP 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 of the Internet Engineering Task
   Force. Submit comments to <> or the author.


   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 also made provided insightful comments on the orignal earlier versions of
   this draft.


   Most current IP multicast implementations achieve some level of scop-
   ing 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 for a packet is not forwarded across the interface unless its
   remaining TTL 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-
   tional 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-

   A more serious architectural problem with TTL scoping is that, in
   many cases, it can prevent pruning from being effective. Consider the
   case in which a packet either has its TTL expire or does not meet a
   TTL threshold. The point (e.g., tunnel, interface) at which the
   packet fails the TTL check will not be capable of pruning upstream
   and hence will sink all traffic, independent of whether there are
   downstream group members. Note that without somehow associating prune
   state and TTL, this problem will persist. For example, while it might
   seem possible to send a prune upstream from the point where the
   packet is discarded, this strategy could prevent legitimate traffic
   from being forwarded (subsequent packets could take a different path
   and wind up 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.

   On the other hand, by using administratively scoped IP multicast, one
   can achieve locally scoped multicast with simple, clear semantics.

   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.

Allocation of the Administratively Scoped IP IPv4 Multicast Address Space

   IANA should allocate the  range to to be
   the "Administratively Scoped IP IPv4 Multicast" address space.


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

Structure of the IPv4 Administratively Scoped Multicast Space

   The structure of the IP version 4 administratively scoped multicast
   space is loosely based on the IP Version 6 Multicast Addresses
   [RFC1884] assignments, Addressing Architecture described
   in RFC 1884. The following table outlines the partitioning of the
   IPv4 multicast space, and is partitioned into gives the following 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

The IPv4 Local Scope -- is the IPv4 Local Scope.  While how local is the Local
   Scope is site dependent, locally scoped regions must obey certain
   topological constraints. In particular, a Local Scope must not span
   any other boundary.  That is, it must be completely contained within,
   or equal to, any larger scope. In the event that two scope       regions
   overlap in area, the area that overlaps must be in it's own local
   scope. This also means that any scope boundary is also a boundary for
   the Local Scope. The more general topological requirements for admin-
   istratively scoped regions are discussed below.

Other IPv4 Scopes of Interest
   The other two scope classes of interest, link-local statically assigned link-
   local scope and global
   scope, scope already exist to some extent in IP version ver-
   sion 4 multicast space. In particular, the link-local statically assigned link-
   local scope is The existing 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

   for current multicast address assignments.

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-
   dary for scoped addresses in the range defined in its configuration.

   Network administrators may configure a scope region whenever local
   multicast scope is required. In addition, an administrator may con-
   figure 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 (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 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 a boundary
   attribute in the interface configuration [ASMA]. The boundary attri-
   bute that includes a prefix and mask, and has the semantics that
   packets matching the prefix and mask do not not pass the boundary. As
   mentioned above, the implementation would also prune the boundary.

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-


      [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, September,

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

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

Author's Address

   David Meyer
   Advanced Network Technology Center
   University of Oregon
   1225 Kincaid St.

   Eugene, OR 97403

   phone:  +1 541.346.1747