draft-ietf-mboned-admin-ip-space-02.txt   draft-ietf-mboned-admin-ip-space-03.txt 
INTERNET-DRAFT David Meyer MBONED Working Group David Meyer
draft-ietf-mboned-admin-ip-space-02.txt University of Oregon Internet Draft University of Oregon
Category:Best Current Practice April 1997 Category Best Current Practice
Administratively Scoped IP Multicast Administratively Scoped IP Multicast
Status of this Memo 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 This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract 2. Abstract
This document defines the "administratively scoped IPv4 multicast This document defines the "administratively scoped IPv4 multicast
space" to be the range 239.0.0.0 to 239.255.255.255 . In addition, space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
it describes a simple set of semantics for the implementation of describes a simple set of semantics for the implementation of
Administratively Scoped IP Multicast. Finally, it provides a mapping Administratively Scoped IP Multicast. Finally, it provides a mapping
between the IPv6 multicast address classes [RFC1884] and IPv4 between the IPv6 multicast address classes [RFC1884] and IPv4
multicast address classes. multicast address classes.
This memo is a product of the MBONE Deployment Working Group (MBONED) This memo is a product of the MBONE Deployment Working Group (MBONED)
in the Operational Requirements area of the Internet Engineering Task in the Operations and Management Area of the Internet Engineering
Force. Submit comments to <mboned@ns.uoregon.edu> or the author. Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
Acknowledgments 3. Acknowledgments
Much of this memo is taken from "Administratively Scoped IP Much of this memo is taken from "Administratively Scoped IP
Multicast", Van Jacobson and Steve Deering, presented at the 30th Multicast", Van Jacobson and Steve Deering, presented at the 30th
IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
Dave Thaler also provided insightful comments on earlier versions of Dave Thaler have also provided insightful comments on earlier
this draft. versions of this document.
Introduction 4. Introduction
Most current IP multicast implementations achieve some level of scop- Most current IP multicast implementations achieve some level of
ing by using the TTL field in the IP header. Typical MBONE (Multicast scoping by using the TTL field in the IP header. Typical MBONE
Backbone) usage has been to engineer TTL thresholds that confine (Multicast Backbone) usage has been to engineer TTL thresholds that
traffic to some administratively defined topological region. The confine traffic to some administratively defined topological region.
basic forwarding rule for interfaces with configured TTL thresholds The basic forwarding rule for interfaces with configured TTL
is that a packet is not forwarded across the interface unless its thresholds is that a packet is not forwarded across the interface
remaining TTL greater than the threshold. unless its remaining TTL is greater than the threshold.
TTL scoping has been used to control the distribution of multicast TTL scoping has been used to control the distribution of multicast
traffic with the objective of easing stress on scarce resources traffic with the objective of easing stress on scarce resources
(e.g., bandwidth), or to achieve some kind of improved privacy or (e.g., bandwidth), or to achieve some kind of improved privacy or
scaling properties. In addition, the TTL is also used in its tradi- scaling properties. In addition, the TTL is also used in its
tional role to limit datagram lifetime. Given these often conflicting traditional role to limit datagram lifetime. Given these often
roles, TTL scoping has proven difficult to implement reliably, and conflicting roles, TTL scoping has proven difficult to implement
the resulting schemes have often been complex and difficult to under- reliably, and the resulting schemes have often been complex and
stand. difficult to understand.
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 A more serious architectural problem concerns the interaction of TTL
can achieve locally scoped multicast with simple, clear semantics. 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.
The key properties of any implementation of administratively scoped On the other hand, administratively scoped IP multicast can provide
IP multicast are that (i). packets addressed to administratively clear and simple semantics for scoped IP multicast. The key
scoped multicast addresses do not cross configured administrative properties of administratively scoped IP multicast are that (i).
boundaries, and (ii). administratively scoped multicast addresses are packets addressed to administratively scoped multicast addresses do
locally assigned, and hence are not required to be unique across not cross configured administrative boundaries, and (ii).
administrative boundaries. These properties are sufficient to imple- administratively scoped multicast addresses are locally assigned, and
ment administrative scoping. hence are not required to be unique across administrative boundaries.
Allocation of the Administratively Scoped IPv4 Multicast Address Space 5. Definition of the Administratively Scoped IPv4 Multicast Space
IANA should allocate the range 239.0.0.0 to 239.255.255.255 to be The administratively scoped IPv4 multicast address space is defined
the "Administratively Scoped IPv4 Multicast" address space. to be the range 239.0.0.0 to 239.255.255.255.
Discussion 6. Discussion
In order to support administratively scoped IP multicast, a router In order to support administratively scoped IP multicast, a router
should support the configuration of scoped IP multicast boundaries. should support the configuration of per-interface scoped IP multicast
Such a router, called a boundary router, does not forward packets boundaries. Such a router, called a boundary router, does not forward
matching its boundary definition in either direction across its packets matching an interface's boundary definition in either
border (the bi-directional check prevents problems with multi-access direction (the bi-directional check prevents problems with multi-
networks). In addition, a boundary router always prunes the boundary access networks). In addition, a boundary router always prunes the
for dense-mode groups, or doesn't accept joins for sparse-mode groups boundary for dense-mode groups [PIMDM], and doesn't accept joins for
[PIMSM] in the administratively scoped range. sparse-mode groups [PIMSM] in the administratively scoped range.
Structure of the Administratively Scoped Multicast Space 7. The Structure of the Administratively Scoped Multicast Space
The structure of the IP version 4 administratively scoped multicast The structure of the IP version 4 administratively scoped multicast
space is based on the IP Version 6 Addressing Architecture described space is loosely based on the IP Version 6 Addressing Architecture
in RFC 1884. The following table outlines the partitioning of the described in RFC 1884 [RFC1884]. This document defines two important
IPv4 multicast space, and gives the mapping to IPv6 SCOP values scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These
[RFC1884]. scopes are described below.
IPv6 SCOP RFC 1884 Description IPv4 Prefix 7.1. The IPv4 Local Scope -- 239.255.0.0/16
==================================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned) 239.254.0.0/16
5 site-local scope 239.253.0.0/16
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
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.
239.255.0.0/16 is the IPv4 Local Scope. While how local is the Local 7.1.1. Expansion of the IPv4 Local Scope
Scope is site dependent, locally scoped regions must obey certain
topological constraints. In particular, a Local Scope must not span The IPv4 Local Scope space grows "downward". As such, the IPv4 Local
any other boundary. That is, it must be completely contained within, Scope may grow downward from 239.255.0.0/16 into the reserved ranges
or equal to, any larger scope. In the event that two scope regions 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not
overlap in area, the area that overlaps must be in it's own local be utilized until the 239.255.0.0/16 space is no longer sufficient.
scope. This also means that any scope boundary is also a boundary for
the Local Scope. The more general topological requirements for admin- 7.2. The IPv4 Organization Local Scope -- 239.192.0.0/14
istratively scoped regions are discussed below.
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.
7.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.
7.3. Other IPv4 Scopes of Interest
Other IPv4 Scopes of Interest
The other two scope classes of interest, statically assigned link- The other two scope classes of interest, statically assigned link-
local scope and global scope already exist to some extent in IP ver- local scope and global scope already exist in IPv4 multicast space.
sion 4 multicast space. In particular, the statically assigned link- The statically assigned link-local scope is 224.0.0.0/24. The
local scope is 224.0.0.0/24. The existing global scope allocations existing static global scope allocations are somewhat more granular,
are currently somewhat more granular, and include and include
224.1.0.0-224.1.255.255 ST Multicast Groups 224.1.0.0-224.1.255.255 ST Multicast Groups
224.2.0.0-224.2.127.253 Multimedia Conference Calls 224.2.0.0-224.2.127.253 Multimedia Conference Calls
224.2.127.254 SAPv1 Announcements 224.2.127.254 SAPv1 Announcements
224.2.127.255 SAPv0 Announcements (deprecated) 224.2.127.255 SAPv0 Announcements (deprecated)
224.2.128.0-224.2.255.255 SAP Dynamic Assignments 224.2.128.0-224.2.255.255 SAP Dynamic Assignments
224.252.0.0-224.255.255.255 DIS transient groups 224.252.0.0-224.255.255.255 DIS transient groups
232.0.0.0-232.255.255.255 VMTP transient groups 232.0.0.0-232.255.255.255 VMTP transient groups
See ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses See [RFC1700] for current multicast address assignments (this list
for current multicast address assignments. can also be found, possibly in a more current form, on
ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
Topological Requirements for Administrative Boundaries 8. Topological Requirements for Administrative Boundaries
An administratively scoped IP multicast region is defined to be a An administratively scoped IP multicast region is defined to be a
topological region in which there are one or more boundary routers topological region in which there are one or more boundary routers
with common boundary definitions. Such a router is said to be a boun- with common boundary definitions. Such a router is said to be a
dary for scoped addresses in the range defined in its configuration. boundary for scoped addresses in the range defined in its
configuration.
Network administrators may configure a scope region whenever local Network administrators may configure a scope region whenever
multicast scope is required. In addition, an administrator may con- constrained multicast scope is required. In addition, an
figure overlapping scope regions (networks can be in multiple scope administrator may configure overlapping scope regions (networks can
regions) where convenient, with the only limitations being that a be in multiple scope regions) where convenient, with the only
scope region must be connected (there must be a path between any two limitations being that a scope region must be connected (there must
nodes within a scope region that doesn't leave that region), and con- be a path between any two nodes within a scope region that doesn't
vex (i.e., no path between any two points in the region can cross a leave that region), and convex (i.e., no path between any two points
region boundary). Finally, as mentioned above, an important con- in the region can cross a region boundary).
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 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 Scope. This implies that packets sent to groups covered by
range must not be forwarded across any link with any scoped boundary 239.255.0.0/16 must not be forwarded across any link for which a
defined. That is, setting a boundary on a link for any prefix must scoped boundary is defined.
also set a boundary on that link for the local scope prefix.
Example: DVMRP 9. Partitioning of the Administratively Scoped Multicast Space
DVMRP [DVMRP] implementations could be extended to support a boundary The following table outlines the partitioning of the IPv4 multicast
attribute in the interface configuration [ASMA]. The boundary attri- space, and gives the mapping from IPv4 multicast prefixes to IPv6
bute that includes a prefix and mask, and has the semantics that SCOP values:
packets matching the prefix and mask do not not pass the boundary. As
mentioned above, the implementation would also prune the boundary.
Security Considerations IPv6 SCOP RFC 1884 Description IPv4 Prefix
==================================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
10. Security Considerations
While security considerations are not explicitly discussed in this While security considerations are not explicitly discussed in this
memo, it is important to note that a boundary router as described memo, it is important to note that a boundary router as described
here should not be considered to provide any kind of firewall func- here should not be considered to provide any kind of firewall
tionality. functionality.
References 11. References
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", , presented at the 30th IETF, Toronto, Multicast", , presented at the 30th IETF, Toronto,
Canada, 25 July 1994. Canada, 25 July 1994.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing [DVMRP] T. Pusateri, "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-03, September, Protocol", draft-ietf-idmr-dvmrp-v3-03.txt,
1996. September, 1996.
[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing [PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Architecture", RFC1884, December 1995. Version 2, Dense Mode Specification",
draft-ietf-idmr-pim-dm-05.txt, April, 1997.
[PIMSM] Estrin, D, et. al., "Protocol Independent Multicast [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Protocol Specification", Sparse Mode (PIM-SM): Protocol Specification",
draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1996. draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1997.
Author's Address [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,
1994.
[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
Architecture", RFC1884, December 1995.
12. Author's Address
David Meyer David Meyer
Advanced Network Technology Center Advanced Network Technology Center
University of Oregon University of Oregon
1225 Kincaid St. 1225 Kincaid St.
Eugene, OR 97403 Eugene, OR 97403
phone: +1 541.346.1747 phone: +1 541.346.1747
email: meyer@antc.uoregon.edu email: meyer@antc.uoregon.edu
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/