draft-ietf-mboned-v4v6-mcast-ps-02.txt		draft-ietf-mboned-v4v6-mcast-ps-03.txt
	MBONED Working Group C. Jacquenet		MBONED Working Group C. Jacquenet
	Internet-Draft M. Boucadair		Internet-Draft M. Boucadair
	Intended status: Informational France Telecom Orange		Intended status: Informational France Telecom Orange
	Expires: September 14, 2013 Y. Lee		Expires: December 07, 2013 Y. Lee
	Comcast		Comcast
	J. Qin		J. Qin
	Cisco Systems		Cisco Systems
	T. Tsou		T. Tsou
	Huawei Technologies (USA)		Huawei Technologies (USA)
	Q. Sun		Q. Sun
	China Telecom		China Telecom
	March 13, 2013		June 05, 2013
	IPv4-IPv6 Multicast: Problem Statement and Use Cases		IPv4-IPv6 Multicast: Problem Statement and Use Cases
	draft-ietf-mboned-v4v6-mcast-ps-02		draft-ietf-mboned-v4v6-mcast-ps-03
	Abstract		Abstract
	This document discusses issues and requirements raised by IPv4-IPv6		This document discusses issues and requirements raised by IPv4-IPv6
	multicast interconnection and co-existence scenarios. It also		multicast interconnection and co-existence scenarios. It also
	discusses various multicast use cases which may occur during IPv6		discusses various multicast use cases which may occur during IPv6
	transitioning.		transitioning.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on September 14, 2013.		This Internet-Draft will expire on December 07, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22		skipping to change at page 2, line 22
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Organization of the Document . . . . . . . . . . . . . . 4		1.2. Organization of the Document . . . . . . . . . . . . . . 4
	2. Scope and Service Requirements . . . . . . . . . . . . . . . 5		2. Scope and Service Requirements . . . . . . . . . . . . . . . 5
	2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Service Requirements . . . . . . . . . . . . . . . . . . 5		2.2. Service Requirements . . . . . . . . . . . . . . . . . . 5
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. IPv4 Receiver and Source Connected to an IPv6-Only		3.1. IPv4 Receiver and Source Connected to an IPv6-Only
	Network . . . . . . . . . . . . . . . . . . . . . . . . . 6		Network . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. IPv6 Receiver and Source Connected to an IPv4-Only		3.2. IPv6 Receiver and Source Connected to an IPv4-Only
	Network . . . . . . . . . . . . . . . . . . . . . . . . . 8		Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 10		3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 10
	3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 11		3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 11
	3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4. Design Considerations . . . . . . . . . . . . . . . . . . . . 13		4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 13
	4.1. Group and Source Discovery Considerations . . . . . . . . 13		4.1. Group and Source Discovery Considerations . . . . . . . . 13
	4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 14
	4.3. Multicast Tree Computation . . . . . . . . . . . . . . . 14		4.3. Multicast Tree Computation . . . . . . . . . . . . . . . 14
	4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 14		4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 14
	4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . 14		4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . 15
	4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 16		4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 16
	4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 16		4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 16
	4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . 16		4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . 17
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Global IPv4 address depletion inevitably challenges service providers		Global IPv4 address depletion inevitably challenges service providers
	who must guarantee IPv4 service continuity during the forthcoming		who must guarantee IPv4 service continuity during the forthcoming
	transition period. In particular, access to IPv4 contents that are		transition period. In particular, access to IPv4 contents that are
	multicast to IPv4 receivers becomes an issue when the forwarding of		multicast to IPv4 receivers becomes an issue when the forwarding of
	multicast data assumes the use of global IPv4 addresses.		multicast data assumes the use of global IPv4 addresses.
	skipping to change at page 4, line 34		skipping to change at page 4, line 34
	This document uses the following terms:		This document uses the following terms:
	o Multicast Source: Source of contents that are multicast to		o Multicast Source: Source of contents that are multicast to
	receivers. A video streaming server is an example of such source.		receivers. A video streaming server is an example of such source.
	o Multicast Receiver: Receiver, in short. A Set Top Box (STB) is an		o Multicast Receiver: Receiver, in short. A Set Top Box (STB) is an
	example of such receiver.		example of such receiver.
	o Multicast Delivery Network: Network in short, covers the realm		o Multicast Delivery Network: Network in short, covers the realm
	from Designated Routers that are directly connected to sources to		from First Hop Routers that are directly connected to sources to
	IGMP/MLD (Internet Group Management Protocol/Multicast Listener		IGMP/MLD (Internet Group Management Protocol/Multicast Listener
	Discovery) Querier devices that process IGMP/MLD signalling		Discovery) Querier devices that process IGMP/MLD signalling
	traffic exchanged with receivers.		traffic exchanged with receivers.
	1.2. Organization of the Document		1.2. Organization of the Document
	This document is organized as follows:		This document is organized as follows:
	o Section 2 details basic requirements that should be addressed by		o Section 2 details basic requirements that should be addressed by
	providers involved in the delivery of multicast-based services		providers involved in the delivery of multicast-based services
	skipping to change at page 5, line 26		skipping to change at page 5, line 26
	network is IP multicast-enabled. That is, whatever the IP address		network is IP multicast-enabled. That is, whatever the IP address
	family of the content, this content will be multicast along		family of the content, this content will be multicast along
	distribution trees that should be terminated as close to the		distribution trees that should be terminated as close to the
	receivers as possible for the sake of bandwidth optimization. In		receivers as possible for the sake of bandwidth optimization. In
	other words, considerations about forwarding multicast traffic		other words, considerations about forwarding multicast traffic
	over unicast-only (access) networks are out of the scope of this		over unicast-only (access) networks are out of the scope of this
	document.		document.
	Multicast to the receivers, not from the receivers: This document		Multicast to the receivers, not from the receivers: This document
	only covers the case where multicast traffic is forwarded by the		only covers the case where multicast traffic is forwarded by the
	service provider network to the receivers. This document does not		service provider network to the receivers. The draft does not
	cover the case where the receivers send multicast traffic to the		consider multicast services that assume a source/receiver
	network.		heuristic, e.g., videoconferencing services. The draft primarily
			focuses on residential multicast-based services, as per a typical
			1:n group communication scheme.
	2.2. Service Requirements		2.2. Service Requirements
	The delivery of multicast contents during the forthcoming transition		The delivery of multicast contents during the forthcoming transition
	period needs to address the following requirements. Note that some		period needs to address the following requirements. Note that some
	of these requirements are not necessarily specific to the IPv4-to-		of these requirements are not necessarily specific to the IPv4-to-
	IPv6 transition context, but rather apply to a wide range of		IPv6 transition context, but rather apply to a wide range of
	multicast-based services whatever the environmental constraints, but		multicast-based services whatever the environmental constraints, but
	the forthcoming transition period further stresses these requirements		the forthcoming transition period further stresses these requirements
	(see Section 4.4.1 for more details).		(see Section 4.4.1 for more details).
	skipping to change at page 6, line 4		skipping to change at page 6, line 7
	dimensioning issues that should be carefully evaluated by service		dimensioning issues that should be carefully evaluated by service
	providers during network planning operations. For instance, if		providers during network planning operations. For instance, if
	only few IPv6-enabled receivers are in use, it can be more		only few IPv6-enabled receivers are in use, it can be more
	convenient to convey multicast traffic over IPv4 rather than		convenient to convey multicast traffic over IPv4 rather than
	doubling the consumed resources for few users. IPv4/IPv6 co-		doubling the consumed resources for few users. IPv4/IPv6 co-
	existence solutions should be designed to optimize network		existence solutions should be designed to optimize network
	resource utilization.		resource utilization.
	o Zap rapidly. The time it takes to switch from one content to		o Zap rapidly. The time it takes to switch from one content to
	another must be as short as possible. For example, zapping times		another must be as short as possible. For example, zapping times
	between two TV channels should be in the magnitude of a few		between two TV channels should be comparable to an IPv4 case,
	seconds at most, whatever the conditions to access the multicast		i.e., less than a second so that translation does not
	network. A procedure called "IGMP fast-leave" is sometimes used		significantly affect the overhead, whatever the conditions to
	to minimize this issue so that the corresponding multicast stream		access the multicast network. A procedure called "IGMP fast-
	is stopped as soon as the IGMP Leave message is received by the		leave" is sometimes used to minimize this issue so that the
	Querier. In current deployments, IGMP fast-leave often assumes		corresponding multicast stream is stopped as soon as the IGMP
	the activation of the IGMP Proxy function in DSLAMs. The		Leave message is received by the Querier. In current deployments,
	complexity of such design is aggravated within a context where		IGMP fast-leave often assumes the activation of the IGMP Proxy
	IPv4 multicast control messages are encapsulated in IPv6.		function in DSLAMs. The complexity of such design is aggravated
			within a context where IPv4 multicast control messages are
			encapsulated in IPv6.
	o Preserve the integrity of contents. Some contract agreements may		o Preserve the integrity of contents that the user sees, i.e., not
	prevent a service provider from altering the content owned by the		the contents of IP packets. Some contract agreements may prevent
	content provider, because of copyright, confidentiality and SLA		a service provider from altering the content owned by the content
	assurance reasons. Multicast streams should be delivered without		provider, because of copyright, confidentiality and SLA assurance
	altering their content.		reasons. Multicast streams should be delivered without altering
			their content.
	o Preserve service quality. Crossing a CGN or performing multicast		o Preserve service quality. Crossing a CGN or performing multicast
	packet encapsulation may lead to fragmentation or extra delays and		packet encapsulation may lead to fragmentation or extra delays and
	may therefore impact the perceived quality of service. Such		may therefore impact the perceived quality of service. Such
	degradation must be avoided.		degradation must be avoided.
	o Optimize IPv4-IPv6 inter-working design. In some operational		o Optimize IPv4-IPv6 inter-working design. In some operational
	networks, a source-based stateful NAT function is sometimes used		networks, a source-based stateful NAT function is sometimes used
	for load balancing purposes, for example. Because of the		for load balancing purposes, for example. Because of the
	operational issues raised by such a stateful design, the		operational issues raised by such a stateful design, the
	skipping to change at page 6, line 48		skipping to change at page 7, line 5
	IPv6 receivers. Because of the inevitable combination of different		IPv6 receivers. Because of the inevitable combination of different
	IP version-related environments (sources, receivers and networks),		IP version-related environments (sources, receivers and networks),
	service providers should carefully plan and choose the appropriate		service providers should carefully plan and choose the appropriate
	technique that will optimize the network resources to deliver		technique that will optimize the network resources to deliver
	multicast-based services.		multicast-based services.
	Concretely, several use cases can be considered during the IPv4/ IPv6		Concretely, several use cases can be considered during the IPv4/ IPv6
	co-existence period. Some of them are depicted in the following sub-		co-existence period. Some of them are depicted in the following sub-
	sections.		sections.
			Note that the following diagrams are meant to illustrate the
			conceptual model. As such, they do not necessarily mean that the
			Adaptation Functions (AF) are embedded in a separate device and that
			messages need to be explicitly translated into new messages.
	3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network		3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network
	We refer to this scenario as 4-6-4. An example of such use case is a		We refer to this scenario as 4-6-4. An example of such use case is a
	DS-Lite environment, where customers will share global IPv4		DS-Lite environment, where customers will share global IPv4
	addresses. IPv4 receivers are connected to CPE devices that are		addresses. IPv4 receivers are connected to CPE devices that are
	provisioned with an IPv6 prefix only. Delivering multicast content		provisioned with an IPv6 prefix only. Delivering multicast content
	sent by an IPv4 source to such receivers requires the activation of		sent by an IPv4 source to such receivers requires the activation of
	some adaptation functions (AFs). These may operate at the network		some adaptation functions (AFs). These may operate at the network
	layer (interworking functions (IWF) or at the application layer		layer (interworking functions (IWF) or at the application layer
	(application level gateways (ALGs)).		(application level gateways (ALGs)).
	skipping to change at page 13, line 10		skipping to change at page 13, line 13
	BG : Border Gateway		BG : Border Gateway
	Src : Multicast source		Src : Multicast source
	Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario.		Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario.
	3.5. Summary		3.5. Summary
	To summarize, the use cases of highest priority are those involving		To summarize, the use cases of highest priority are those involving
	IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios.		IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios.
	4. Design Considerations		4. Design Requirements
	4.1. Group and Source Discovery Considerations		4.1. Group and Source Discovery Considerations
	Multicast applications that embed address information in the payload		Multicast applications that embed address information in the payload
	may require Application Level Gateway (ALG) during the transition		may require Application Level Gateway (ALG) during the transition
	period. An ALG is application-specific by definition, and may		period. An ALG is application-specific by definition, and may
	therefore be unnecessary depending on the nature of the multicast		therefore be unnecessary depending on the nature of the multicast
	service.		service.
	Such ALG (Application Level Gateway) may also be required to help an		Such ALG (Application Level Gateway) may also be required to help an
	skipping to change at page 13, line 46		skipping to change at page 14, line 8
	address would then require multicast flows to cross an IPv4-IPv6		address would then require multicast flows to cross an IPv4-IPv6
	interworking function.		interworking function.
	The receiver should therefore be able to unambiguously distinguish an		The receiver should therefore be able to unambiguously distinguish an
	IPv4-embedded IPv6 multicast address from a native IPv6 multicast		IPv4-embedded IPv6 multicast address from a native IPv6 multicast
	address.		address.
	4.2. Subscription		4.2. Subscription
	Multicast distribution trees are receiver-initiated. IPv4 receivers		Multicast distribution trees are receiver-initiated. IPv4 receivers
	that want to subscribe to an IPv4 multicast group will send the		that want to subscribe to an IPv4 multicast group will send IGMP
	corresponding IGMP Report message towards the relevant IGMP Querier.		Report messages accordingly. In case the underlying access network
	In case the underlying access network is IPv6, the information		is IPv6, the information conveyed in IGMP messages should be relayed
	conveyed in IGMP messages should be relayed by corresponding MLD		by corresponding MLD messages.
	messages.
	4.3. Multicast Tree Computation		4.3. Multicast Tree Computation
	Grafting to an IPv4 multicast distribution tree through an IPv6		Grafting to an IPv4 multicast distribution tree through an IPv6
	multicast domain suggests that IPv4 multicast traffic will have to be		multicast domain suggests that IPv4 multicast traffic will have to be
	conveyed along an "IPv6-equivalent" multicast distribution tree.		conveyed along an "IPv6-equivalent" multicast distribution tree.
	That is, part of the multicast distribution tree along which IPv4		That is, part of the multicast distribution tree along which IPv4
	multicast traffic will be forwarded should be computed and maintained		multicast traffic will be forwarded should be computed and maintained
	by means of the PIMv6 machinery, so that the distribution tree can be		by means of the PIMv6 machinery, so that the distribution tree can be
	terminated as close to the IPv4 receivers as possible for the sake of		terminated as close to the IPv4 receivers as possible for the sake of
	skipping to change at page 15, line 17		skipping to change at page 15, line 31
	design (e.g., this device could be a PIM DR in addition to a MLD		design (e.g., this device could be a PIM DR in addition to a MLD
	Querier).		Querier).
	The IWF can then be operated in the following modes: IGMP-MLD,		The IWF can then be operated in the following modes: IGMP-MLD,
	PIMv4-PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-		PIMv4-PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-
	Specific Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2		Specific Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2
	signalling traffic as well as the ability to directly send PIM (S, G)		signalling traffic as well as the ability to directly send PIM (S, G)
	Join messages towards the source).		Join messages towards the source).
	The following sub-sections describe some interworking functions which		The following sub-sections describe some interworking functions which
	may be solicited, depending on the environment.		may be solicited, depending on the environment. Note that it may not
			be a stand-alone IWF that simply translates messages, but, for
			example, the combination of IPv4 and IPv6 states that would trigger
			the forwarding of aggregated MLD Report messages upstream that would
			include IPv6 groups based upon IPv4 states.
	4.4.1.1. IGMP-MLD Interworking		4.4.1.1. IGMP-MLD Interworking
	The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying		The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying
	function specified in [RFC4605] and the IGMP/MLD adaptation function		function specified in [RFC4605] and the IGMP/MLD adaptation function
	which is meant to reflect the contents of IGMP messages into MLD		which is meant to reflect the contents of IGMP messages into MLD
	messages, and vice versa.		messages, and vice versa.
	For example, when an IGMP Report message is received to subscribe to		For example, when an IGMP Report message is received to subscribe to
	a given multicast group (which may be associated to a source address		a given multicast group (which may be associated to a source address
	skipping to change at page 16, line 24		skipping to change at page 16, line 43
	encapsulation/de-capsulation or translation modes can be enforced,		encapsulation/de-capsulation or translation modes can be enforced,
	depending on the design. Note that translation operations must		depending on the design. Note that translation operations must
	follow the algorithm specified in [RFC6145].		follow the algorithm specified in [RFC6145].
	4.4.3. Address Mapping		4.4.3. Address Mapping
	The address mapping mechanisms to be used in either a stateful or		The address mapping mechanisms to be used in either a stateful or
	stateless fashion need to be specified for the translation from one		stateless fashion need to be specified for the translation from one
	address family to the other.		address family to the other.
	The address formats have been defined in		The address formats can be those defined in
	[I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for		[I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for
	IPv4-embedded IPv6 multicast and unicast addresses. Mapping		IPv4-embedded IPv6 multicast and unicast addresses. Mapping
	operations are performed in a stateless manner by the algorithms		operations are performed in a stateless manner by the algorithms
	specified in the aforementioned documents.		specified in the aforementioned documents.
	In this context, the IPv6 prefixes required for embedding IPv4		In this context, the IPv6 prefixes required for embedding IPv4
	addresses can be assigned to devices that support IWF features by		addresses can be assigned to devices that support IWF features by
	various means (e.g., static or dynamic configuration, out-of-band		various means (e.g., static or dynamic configuration, out-of-band
	mechanisms, etc.).		mechanisms, etc.).
	skipping to change at page 17, line 11		skipping to change at page 17, line 30
	5. IANA Considerations		5. IANA Considerations
	This document makes no request to IANA.		This document makes no request to IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	6. Security Considerations		6. Security Considerations
	Access to contents in a multicast-enabled environment raises		Access to contents in a multicast-enabled environment raises
	different security issues that have been already documented. This		different security issues that have been already documented. In
	draft does not introduce any specific security issue.		particular:
			o When translating ASM-SSM there are certain security expectations
			from SSM (only receiving from the single specified sender), which
			are not the same expectations that come from ASM.
			o If mappings are not stateful, it may be harder to monitor and
			troubleshoot the traffic.
			o There are concepts of IPv4 and IPv6 multicast scopes. When
			translating, it must be taken into account how to reasonably map
			between scopes, and it is important that the scopes are configured
			appropriately on the routers so that a scope intended to be within
			a site for IPv4 (for example), doesn't leak outside the site due
			to translation to IPv6 inside the site.
	7. Acknowledgments		7. Acknowledgments
	Special thanks to T. Taylor for providing the figures and some of		Special thanks to T. Taylor for providing the figures and some of the
	the text that illustrate the use cases depicted in Section 3. Thanks		text that illustrate the use cases depicted in Section 3. Thanks
	also to H. Asaeda, M. Blanchet, M. Eubanks, N. Leymann, S.		also to H. Asaeda, M. Blanchet, M. Eubanks, B. Haberman, N. Leymann,
	Perrault and S. Venaas for their valuable comments and support.		S. Perrault and S. Venaas for their valuable comments and support.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2236] Fenner, W.C., "Internet Group Management Protocol, Version		[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
	2", RFC 2236, November 1997.		2", RFC 2236, November 1997.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, October 2002.		3", RFC 3376, October 2002.
	[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific		[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
	Multicast (SSM)", RFC 3569, July 2003.		Multicast (SSM)", RFC 3569, July 2003.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	skipping to change at page 18, line 7		skipping to change at page 18, line 40
	[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation		[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
	Algorithm", RFC 6145, April 2011.		Algorithm", RFC 6145, April 2011.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-mboned-64-multicast-address-format]		[I-D.ietf-mboned-64-multicast-address-format]
	Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and		Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
	M. Xu, "IPv6 Multicast Address With Embedded IPv4		M. Xu, "IPv6 Multicast Address With Embedded IPv4
	Multicast Address", draft-ietf-mboned-64-multicast-		Multicast Address", draft-ietf-mboned-64-multicast-
	address-format-04 (work in progress), August 2012.		address-format-05 (work in progress), April 2013.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.		[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
	Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,		Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
	October 2010.		October 2010.
	Authors' Addresses		Authors' Addresses
	Christian Jacquenet		Christian Jacquenet
	France Telecom Orange		France Telecom Orange
	4 rue du Clos Courtel		4 rue du Clos Courtel
	Cesson-Sevigne 35512		Cesson-Sevigne 35512
	France		France
	Phone: +33 2 99 12 43 82		Phone: +33 2 99 12 43 82
	Email: christian.jacquenet@orange.com		Email: christian.jacquenet@orange.com
	Mohamed Boucadair		Mohamed Boucadair
End of changes. 25 change blocks.
	49 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/