draft-ietf-mboned-admin-ip-space-00.txt   draft-ietf-mboned-admin-ip-space-01.txt 
INTERNET-DRAFT David Meyer INTERNET-DRAFT David Meyer
draft-ietf-mboned-admin-ip-space-00.txt University of Oregon draft-ietf-mboned-admin-ip-space-01.txt University of Oregon
Category: Informational November 1996 Category:Best Current Practice December 1996
Expire in six months
Administratively Scoped IP Multicast Administratively Scoped IP Multicast
Status of this Memo Status of this Memo
This document provides information for the Internet Community. It This document specifies an Internet Best Current Practice for the
does not define a standard of any kind. Distribution of this memo is Internet Community, and requests discussion and suggestions for
unlimited. improvements. Distribution of this memo is unlimited.
Internet Drafts 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
skipping to change at line 35 skipping to change at page 1, line 36
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 Abstract
This document defines the "administratively scoped IP multicast This document defines the "administratively scoped IP multicast
space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it space" to be the range 239.0.0.0 to 239.255.255.255 . In addition,
describes a simple set of semantics for the implementation of Admin- it describes a simple set of semantics for the implementation of
istratively Scoped IP Multicast. Administratively Scoped IP Multicast.
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 Operational Requirements area of the Internet Engineering Task
Force. Submit comments to <mboned@ns.uoregon.edu> or the author. Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
Acknowledgments Acknowledgments
Much of this memo is taken from "Administratively Scoped IP Multi- Much of this memo is taken from "Administratively Scoped IP
cast", Van Jacobson and Steve Deering, presented at the 30th IETF, Multicast", Van Jacobson and Steve Deering, presented at the 30th
Toronto, Canada, 25 July 1994. IETF, Toronto, Canada, 25 July 1994. Mark Handley and Dave Thaler
also made insightful comments on the orignal draft.
Introduction Introduction
Most current IP multicast implementations achieve some level of scop- Most current IP multicast implementations achieve some level of scop-
ing by using the TTL field in the IP header. Typical MBONE (Multicast ing by using the TTL field in the IP header. Typical MBONE (Multicast
Backbone) usage has been to engineer TTL thresholds that confine Backbone) usage has been to engineer TTL thresholds that confine
traffic to some administratively defined topological region. The traffic to some administratively defined topological region. The
basic forwarding rule for interfaces with configured TTL thresholds basic forwarding rule for interfaces with configured TTL thresholds
is that for a packet is not forwarded across the interface unless its is that for a packet is not forwarded across the interface unless its
remaining TTL greater than the threshold. remaining TTL greater than the threshold.
skipping to change at line 74 skipping to change at page 2, line 37
roles, TTL scoping has proven difficult to implement reliably, and roles, TTL scoping has proven difficult to implement reliably, and
the resulting schemes have often been complex and difficult to under- the resulting schemes have often been complex and difficult to under-
stand. stand.
On the other hand, by using administratively scoped IP multicast, one On the other hand, by using administratively scoped IP multicast, one
can achieve locally scoped multicast with simple, clear semantics. can achieve locally scoped multicast with simple, clear semantics.
The key properties of any implementation of administratively scoped The key properties of any implementation of administratively scoped
IP multicast are that (i). packets addressed to administratively IP multicast are that (i). packets addressed to administratively
scoped multicast addresses do not cross configured administrative scoped multicast addresses do not cross configured administrative
boundaries, and (ii). administratively scoped multicast addresses are boundaries, and (ii). administratively scoped multicast addresses are
locally assigned, and hence are not guaranteed to be unique across locally assigned, and hence are not required to be unique across
administrative boundaries. These properties are sufficient to imple- administrative boundaries. These properties are sufficient to imple-
ment administrative scoping. ment administrative scoping.
Allocation of the Administratively Scoped IP Multicast Address Space Allocation of the Administratively Scoped IP Multicast Address Space
IANA should allocate the range 239.0.0.0 to 239.255.255.255 to be IANA should allocate the range 239.0.0.0 to 239.255.255.255 to be
the "Administratively Scoped IP Multicast" address space. the "Administratively Scoped IP Multicast" address space.
Discussion 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 scoped IP multicast boundaries.
Such a router, called a boundary router, does not forward packets Such a router, called a boundary router, does not forward packets
matching its boundary definition in either direction across its matching its boundary definition in either direction across its
border (the bi-directional check prevents problems with multicaccess border (the bi-directional check prevents problems with multicaccess
networks). In addition, a boundary router always prunes the boundary networks). In addition, a boundary router always prunes the boundary
for dense-mode groups, or doesn't accept joins for sparse-mode groups for dense-mode groups, or doesn't accept joins for sparse-mode groups
[PIMSM]. [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, and is partitioned into the following scope
classes:
unassigned 239.0.0.0/10
unassigned 239.64.0.0/10
organization-local scope 239.128.0.0/10
site-local scope 239.192.0.0/10
The other two scope classes of interest, link-local scope and global
scope, already exist to some extent in IP version 4 multicast space.
In particular, the link-local scope is 224.0.0.0/24. The existing
global scope allocations are currently 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 ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses
for current multicast address assignments.
Topological Requirements for Administrative Boundaries 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 boun-
dary for scoped addresses in the range defined in its configuration. dary 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 local
multicast scope is required. In addition, an administrator may con- multicast scope is required. In addition, an administrator may con-
figure overlapping scope regions (networks can be in multiple scope figure overlapping scope regions (networks can be in multiple scope
regions) where convenient, with the only limitations being that a regions) where convenient, with the only limitations being that a
scope region must be connected (there must be a path between any two 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- nodes within a scope region that doesn't leave that region), and con-
vex (i.e., no path between any two points can cross a region boun- vex (i.e., no path between any two points in the region can cross a
dary). region boundary).
Example: DVMRP Example: DVMRP
DVMRP [DVMRP] implementations could be extended to support a boundary DVMRP [DVMRP] implementations could be extended to support a boundary
attribute in the interface configuration [ASMA]. The boundary attribute in the interface configuration [ASMA]. The boundary attri-
attribute that includes a prefix and mask, and has the semantics that 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 packets matching the prefix and mask do not not pass the boundary. As
mentioned above, the implementation would also prune the boundary. mentioned above, the implementation would also prune the boundary.
Security Considerations 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 func-
tionality. tionality.
skipping to change at line 126 skipping to change at page 4, line 37
mentioned above, the implementation would also prune the boundary. mentioned above, the implementation would also prune the boundary.
Security Considerations 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 func-
tionality. tionality.
References 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 Protocol", [DVMRP] T. Pusateri, "Distance Vector Multicast Routing
draft-ietf-idmr-dvmrp-v3-03, September, 1996. Protocol", draft-ietf-idmr-dvmrp-v3-03, September,
1996.
[PIMSM] Estrin, D, et. al., "Protocol Independent Multicast-Sparse [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
Mode (PIM-SM): Protocol Specification", Architecture", RFC1884, December 1995.
draft-ietf-idmr-pim-sm-spec-08.txt, October, 1996.
[PIMSM] Estrin, D, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Protocol Specification",
draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996.
Author's Address Author's Address
David Meyer David Meyer
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@ns.uoregon.edu
 End of changes. 

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