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 (C) The Internet Society (1998). All Rights Reserved.
This document defines the "administratively scoped IPv4 multicast
space" to be the range 184.108.40.206 to 220.127.116.11. 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 <email@example.com> 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 have also provided insightful comments on earlier
versions of this document.
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 18.104.22.168 to 22.214.171.124.
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.