draft-ietf-mboned-embeddedrp-04.txt		draft-ietf-mboned-embeddedrp-05.txt
	mboned Working Group P. Savola		mboned Working Group P. Savola
	Internet Draft CSC/FUNET		Internet Draft CSC/FUNET
	Expiration Date: October 2004		Expiration Date: December 2004
	B. Haberman		B. Haberman
	Caspian Networks		Caspian Networks
	April 2004		June 2004
	Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address		Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
	draft-ietf-mboned-embeddedrp-04.txt		draft-ietf-mboned-embeddedrp-05.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, I certify that any applicable
	of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at http://
	http://www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	To view the list Internet-Draft Shadow Directories, see		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This memo defines an address allocation policy in which the address		This memo defines an address allocation policy in which the address
	of the Rendezvous Point (RP) is encoded in an IPv6 multicast group		of the Rendezvous Point (RP) is encoded in an IPv6 multicast group
	address. For Protocol Independent Multicast - Sparse Mode (PIM-SM),		address. For Protocol Independent Multicast - Sparse Mode (PIM-SM),
	this can be seen as a specification of a group-to-RP mapping		this can be seen as a specification of a group-to-RP mapping
	mechanism. This allows an easy deployment of scalable inter-domain		mechanism. This allows an easy deployment of scalable inter-domain
	multicast, and simplifies the intra-domain multicast configuration as		multicast, and simplifies the intra-domain multicast configuration as
	skipping to change at page 2, line 38		skipping to change at page 2, line 38
	7.2. Overview of the Model .................................. 11		7.2. Overview of the Model .................................. 11
	8. Scalability Analysis ....................................... 12		8. Scalability Analysis ....................................... 12
	9. Acknowledgements ........................................... 13		9. Acknowledgements ........................................... 13
	10. Security Considerations ................................... 14		10. Security Considerations ................................... 14
	11. References ................................................ 15		11. References ................................................ 15
	11.1. Normative References .................................. 15		11.1. Normative References .................................. 15
	11.2. Informative References ................................ 15		11.2. Informative References ................................ 15
	Authors' Addresses ............................................. 16		Authors' Addresses ............................................. 16
	A. Discussion about Design Tradeoffs .......................... 16		A. Discussion about Design Tradeoffs .......................... 16
	B. Changes .................................................... 17		B. Changes .................................................... 17
			B.4 Changes since -04 ....................................... 17
	B.3 Changes since -03 ....................................... 17		B.3 Changes since -03 ....................................... 17
	B.2 Changes since -02 ....................................... 17		B.2 Changes since -02 ....................................... 17
	B.3 Changes since -01 ....................................... 18		B.3 Changes since -01 ....................................... 18
	B.4 Changes since -00 ....................................... 18		B.4 Changes since -00 ....................................... 18
	Intellectual Property Statement ................................ 18
	Full Copyright Statement ....................................... 19
	1. Introduction		1. Introduction
	1.1. Background		1.1. Background
	As has been noticed [V6MISSUES], there exists a deployment problem		As has been noticed [V6MISSUES], there exists a deployment problem
	with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no		with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
	way of communicating the information about (active) multicast sources		way of communicating the information about (active) multicast sources
	to other multicast domains, as Multicast Source Discovery Protocol		to other multicast domains, as Multicast Source Discovery Protocol
	(MSDP) [MSDP] has not been, on purpose, specified for IPv6.		(MSDP) [MSDP] has not been, on purpose, specified for IPv6.
	skipping to change at page 17, line 26		skipping to change at page 17, line 26
	much state is being generated to reach in a resource exhaustion DoS		much state is being generated to reach in a resource exhaustion DoS
	attack, some forms of rate-limiting or other mechanisms could be		attack, some forms of rate-limiting or other mechanisms could be
	deployed to mitigate the threats while trying not to disturb the		deployed to mitigate the threats while trying not to disturb the
	legitimate usage. However, as the threats are generic, they are		legitimate usage. However, as the threats are generic, they are
	considered out of scope and discussed separately in [PIMSEC].		considered out of scope and discussed separately in [PIMSEC].
	B. Changes		B. Changes
	[[ RFC-Editor: please remove before publication ]]		[[ RFC-Editor: please remove before publication ]]
			B.4 Changes since -04
			o Only update the boilerplates.
	B.3 Changes since -03		B.3 Changes since -03
	o Further clarifications, especially regarding Inter/intra-domain		o Further clarifications, especially regarding Inter/intra-domain
	terminology.		terminology.
	o Recommend more strongly that multicast groups can be configured,		o Recommend more strongly that multicast groups can be configured,
	and that they should be explicitly configured, to protect against		and that they should be explicitly configured, to protect against
	abuse.		abuse.
	o Note that more detailed controls on who can use a multicast		o Note that more detailed controls on who can use a multicast
	address are out of scope.		address are out of scope.
	o Add discussion about controls/manageability and how that has		o Add discussion about controls/manageability and how that has
	skipping to change at page 18, line 35		skipping to change at page 18, line 37
	o Clarify the usability/scalability issues in section 8.		o Clarify the usability/scalability issues in section 8.
	o Clarify the security issues in Sections 8, Security		o Clarify the security issues in Sections 8, Security
	Considerations and Appendix A, mainly by referring to a separate		Considerations and Appendix A, mainly by referring to a separate
	document.		document.
	o Add a MUST that embedded-RP mappings must be honored by		o Add a MUST that embedded-RP mappings must be honored by
	implementations.		implementations.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the IETF's procedures with respect to rights in IETF Documents can
	standards-related documentation can be found in BCP-11. Copies of		be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at ietf-
	Director.		ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/