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/