< draft-ietf-mboned-admin-ip-space-04.txt		draft-ietf-mboned-admin-ip-space-05.txt >
	MBONED Working Group David Meyer		MBONED Working Group David Meyer
	Internet Draft University of Oregon		Internet Draft University of Oregon
	Category Best Current Practice		Category Best Current Practice
	draft-ietf-mboned-admin-ip-space-04.txt November 1997		draft-ietf-mboned-admin-ip-space-05.txt June 1998
	Administratively Scoped IP Multicast		Administratively Scoped IP Multicast
	1. Status of this Memo		1. Status of this Memo
	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.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 30 ¶
	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).
	2. 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, it		space" to be the range 239.0.0.0 to 239.255.255.255. In addition, 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 Operations and Management Area of the Internet Engineering		in the Operations and Management Area of the Internet Engineering
	Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.		Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
	3. Acknowledgments		3. Acknowledgments
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	assignments. A relative assignment is an integer offset from highest		assignments. A relative assignment is an integer offset from highest
	address in the scope and represents a 32-bit address (for IPv4). For		address in the scope and represents a 32-bit address (for IPv4). For
	example, in the Local Scope defined above, 239.255.255.0/24 is		example, in the Local Scope defined above, 239.255.255.0/24 is
	reserved for relative allocations. The de-facto relative assignment		reserved for relative allocations. The de-facto relative assignment
	"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for		"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
	SAP [SAP]. The next relative assignment, "1", corresponds to the		SAP [SAP]. The next relative assignment, "1", corresponds to the
	address 239.255.255.254 in the Local Scope. The rest of a scoped		address 239.255.255.254 in the Local Scope. The rest of a scoped
	region below the reserved /24 is available for dynamic assignment		region below the reserved /24 is available for dynamic assignment
	(presumably by an address allocation protocol).		(presumably by an address allocation protocol).
	In is important to note that a scope discovery protocol will have to		In is important to note that a scope discovery protocol [MZAP] will
	be developed to make practical use of scopes other that the Local		have to be developed to make practical use of scopes other than the
	Scope. In addition, since any use of any administratively scoped		Local Scope. In addition, since any use of any administratively
	region, including the Local Scope, requires dynamically assigned		scoped region, including the Local Scope, requires dynamically
	addressing, an Address Allocation Protocol (AAP) will need to be		assigned addressing, an Address Allocation Protocol (AAP) will need
	developed to make administrative scoping generally useful.		to be developed to make administrative scoping generally useful.
	10.1. Relative Assignment Guidelines		10.1. Relative Assignment Guidelines
	Requests for relative assignments should be directed to the IANA. In		Requests for relative assignments should be directed to the IANA. In
	general, relative addresses will be used only for bootstrapping to		general, relative addresses will be used only for bootstrapping to
	dynamic address assignments from within the scope. As such, relative		dynamic address assignments from within the scope. As such, relative
	assignments should only be made to those services that cannot use a		assignments should only be made to those services that cannot use a
	dynamic address assignment protocol to find the address used by that		dynamic address assignment protocol to find the address used by that
	service within the desired scope, such as a dynamic address		service within the desired scope, such as a dynamic address
	assignment service itself.		assignment service itself.
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 30 ¶
	as an application feature and merely needs to be enabled (and		as an application feature and merely needs to be enabled (and
	appropriate cryptographic keys securely distributed). For many other		appropriate cryptographic keys securely distributed). For many other
	applications, the use of the IP Encapsulating Security Payload (ESP)		applications, the use of the IP Encapsulating Security Payload (ESP)
	[RFC-1825, RFC-1827] can provide IP-layer confidentiality though		[RFC-1825, RFC-1827] can provide IP-layer confidentiality though
	encryption.		encryption.
	Within the context of an administratively scoped IP multicast group,		Within the context of an administratively scoped IP multicast group,
	the use of manual key distribution might well be feasible. While		the use of manual key distribution might well be feasible. While
	dynamic key management for IP Security is a research area at the time		dynamic key management for IP Security is a research area at the time
	this note is written, it is expected that the IETF will be extending		this note is written, it is expected that the IETF will be extending
	the ISAKMP key management protocol [draft-ietf-ipsec-isakmp-*.txt,		the ISAKMP key management protocol to support scalable multicast key
	draft-ietf-ipsec-ipsec-doi-*.txt] to support scalable multicast key
	distribution in the future.		distribution in the future.
	It is important to note that the "boundary router" described in this		It is important to note that the "boundary router" described in this
	note is not necessarily providing any kind of firewall capability.		note is not necessarily providing any kind of firewall capability.
	12. References		12. 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.txt,		Protocol", draft-ietf-idmr-dvmrp-v3-05.txt,
	September, 1996.		October, 1997.
			[MZAP] M. Handley, "Multicast-Scope Zone Announcement
			Protocol (MZAP)", draft-ietf-mboned-mzap-00.txt,
			December, 1997.
	[PIMDM] Deering, S, et. al., "Protocol Independent Multicast		[PIMDM] Deering, S, et. al., "Protocol Independent Multicast
	Version 2, Dense Mode Specification",		Version 2, Dense Mode Specification",
	draft-ietf-idmr-pim-dm-05.txt, April, 1997.		draft-ietf-idmr-pim-dm-05.txt, May, 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-specv2-00.txt, September		draft-ietf-idmr-pim-sm-specv2-00.txt,
	9,1997.
			September,1997.
	[RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,		[RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,
	1994.		1994.
	[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing		[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
	Architecture", RFC1884, December 1995.		Architecture", RFC1884, December 1995.
	[SAP] Handley, Mark, "SAP: Session Announcement Protocol",		[SAP] Handley, Mark, "SAP: Session Announcement Protocol",
	draft-ietf-mmusic-sap-00.txt, November, 1996.		draft-ietf-mmusic-sap-00.txt, November, 1996.
	13. Author's Address		13. Author's Address
	David Meyer		David Meyer
	Advanced Network Technology Center		Cisco Systems
	University of Oregon		San Jose, CA
	1225 Kincaid St.		email: dmm@cisco.com
	Eugene, OR 97403
	phone: +1 541.346.1747
	email: meyer@antc.uoregon.edu
End of changes. 9 change blocks.
	17 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/