draft-ietf-mboned-v4v6-mcast-ps-01.txt		draft-ietf-mboned-v4v6-mcast-ps-02.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: May 13, 2013 Y. Lee		Expires: September 14, 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
	November 09, 2012		March 13, 2013
	IPv4-IPv6 Multicast: Problem Statement and Use Cases		IPv4-IPv6 Multicast: Problem Statement and Use Cases
	draft-ietf-mboned-v4v6-mcast-ps-01		draft-ietf-mboned-v4v6-mcast-ps-02
	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.
	Requirements Language		Status of This Memo
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 13, 2013.		This Internet-Draft will expire on September 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Organization of the Document . . . . . . . . . . . . . . 4
	1.3. Organization of the Document . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . 6		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. IPv4 Receiver and Source Connected to an IPv6-Only		3.1. IPv4 Receiver and Source Connected to an IPv6-Only
	Network . . . . . . . . . . . . . . . . . . . . . . . . . 7		Network . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. IPv6 Receiver and Source Connected to an IPv4-Only		3.2. IPv6 Receiver and Source Connected to an IPv4-Only
	Network . . . . . . . . . . . . . . . . . . . . . . . . . 9		Network . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 11		3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 10
	3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 13		3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 11
	3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15		3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15		4. Design Considerations . . . . . . . . . . . . . . . . . . . . 13
	4.1. Group and Source Discovery Considerations . . . . . . . . 15		4.1. Group and Source Discovery Considerations . . . . . . . . 13
	4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 16		4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 13
	4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 16		4.3. Multicast Tree Computation . . . . . . . . . . . . . . . 14
	4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 17		4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 14
	4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . . 17		4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . 14
	4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 18		4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 16
	4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 18		4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 16
	4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 19		4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . 16
	5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 19		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		8.1. Normative References . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 20		8.2. Informative References . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	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.
	The rarefaction of global IPv4 addresses may indeed affect the		The rarefaction of global IPv4 addresses may indeed affect the
	skipping to change at page 4, line 21		skipping to change at page 4, line 13
	therefore suffer from IPv4 address depletion.		therefore suffer from IPv4 address depletion.
	o The progressive introduction of IPv6 as the only perennial		o The progressive introduction of IPv6 as the only perennial
	solution to global IPv4 address depletion does not necessarily		solution to global IPv4 address depletion does not necessarily
	assume that multicast-based IPv4 services will be migrated		assume that multicast-based IPv4 services will be migrated
	accordingly. Access to IPv4 multicast contents when no global		accordingly. Access to IPv4 multicast contents when no global
	IPv4 address can be assigned to a customer raises several issues:		IPv4 address can be assigned to a customer raises several issues:
	(1) The completion of the IGMP-based multicast group subscription		(1) The completion of the IGMP-based multicast group subscription
	procedure, (2) The computation of the IPv4 multicast distribution		procedure, (2) The computation of the IPv4 multicast distribution
	tree, and (3) The IPv4-inferred addressing scheme to be used in a		tree, and (3) The IPv4-inferred addressing scheme to be used in a
	networking environment which will progressively become IPv6-		networking environment which will progressively become
	enabled.		IPv6-enabled.
	This document does not make any assumption on the techniques used for		This document does not make any assumption on the techniques used for
	the delivery of multicast traffic (e.g., native IP multicast with or		the delivery of multicast traffic (e.g., native IP multicast with or
	without traffic isolation features, etc.)		without traffic isolation features, etc.)
	This document elaborates on the context and discusses multicast-		This document elaborates on the context and discusses multicast-
	related issues and requirements.		related issues and requirements.
	1.1. Goals		1.1. Terminology
	The objective of this document is to clarify the problem space. In
	particular, this document elaborates on the following issues:
	o What are the hurdles encountered for the delivery of multicast-
	based service offerings when both IPv4 and IPv6 co-exist?
	o What standardization effort is needed: are there any missing
	function and protocol extension?
	o Does the work on multicast transition have to cover both
	encapsulation and translation schemes, considering the requirement
	of multicast network performance among others?
	1.2. Terminology
	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 Designated 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.3. 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
	during the transition period,		during the transition period,
	o Section 3 discusses several use cases that reflect issues raised		o Section 3 discusses several use cases that reflect issues raised
	by the forthcoming transition period,		by the forthcoming transition period,
	o Section 4 details design considerations,		o Section 4 details design considerations.
	o Section 5 summarizes the standardization effort that should be
	tackled by the IETF.
	2. Scope and Service Requirements		2. Scope and Service Requirements
	2.1. Scope		2.1. Scope
	Intra-domain only: The delivery of multicast services such as live		Intra-domain only: The delivery of multicast services such as live
	TV broadcasting often relies upon walled garden designs that		TV broadcasting often relies upon walled garden designs that
	restrict the scope to the domain where such services can be		restrict the scope to the domain where such services can be
	subscribed. As a consequence, considerations about inter-domain		subscribed. As a consequence, considerations about inter-domain
	multicast are out of the scope of this document.		multicast are out of the scope of this document.
	Multicast-enabled networks only: This document assumes that the		Multicast-enabled networks only: This document assumes that the
	network is *IP multicast-enabled*. That is, whatever the IP		network is IP multicast-enabled. That is, whatever the IP address
	address family of the content, this content will be multicast		family of the content, this content will be multicast along
	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. This document does not
	cover the case where the receivers send multicast traffic to the		cover the case where the receivers send multicast traffic to the
	network.		network.
	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).
	o Optimize bandwidth. Contents SHOULD NOT be multicast twice (i.e.,		o Optimize bandwidth. Contents should not be multicast twice (i.e.,
	using both versions of IP) to optimize bandwidth usage. Injecting		using both versions of IP) to optimize bandwidth usage. Injecting
	multicast content using both IPv4 and IPv6 raises some		multicast content using both IPv4 and IPv6 raises some
	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 in the magnitude of a few
	seconds at most, whatever the conditions to access the multicast		seconds at most, whatever the conditions to access the multicast
	network. A procedure called "IGMP fast-leave" is sometimes used		network. A procedure called "IGMP fast-leave" is sometimes used
	to minimize this issue so that the corresponding multicast stream		to minimize this issue so that the corresponding multicast stream
	is stopped as soon as the IGMP Leave message is received by the		is stopped as soon as the IGMP Leave message is received by the
	Querier. In current deployments, IGMP fast-leave often assumes		Querier. In current deployments, IGMP fast-leave often assumes
	the activation of the IGMP Proxy function in DSLAMs. The		the activation of the IGMP Proxy function in DSLAMs. The
	complexity of such design is aggravated within a context where		complexity of such design is aggravated within a context where
	IPv4 multicast control messages are encapsulated in IPv6.		IPv4 multicast control messages are encapsulated in IPv6.
	o Preserve the integrity of contents. Some contract agreements may		o Preserve the integrity of contents. Some contract agreements may
	prevent a service provider from altering the content owned by the		prevent a service provider from altering the content owned by the
	content provider, because of copyright, confidentiality and SLA		content provider, because of copyright, confidentiality and SLA
	assurance reasons. Multicast streams SHOULD be delivered without		assurance reasons. Multicast streams should be delivered without
	altering their content.		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
	deployment of stateless IPv4-IPv6 interworking functions SHOULD be		deployment of stateless IPv4-IPv6 interworking functions should be
	privileged.		privileged.
	3. Use Cases		3. Use Cases
	During the IPv4-to-IPv6 transition period, there might be a mix of		During the IPv4-to-IPv6 transition period, there might be a mix of
	multicast receivers, sources, and networks running in different		multicast receivers, sources, and networks running in different
	address families. However, service providers must guarantee the		address families. However, service providers must guarantee the
	delivery of multicast services to IPv4 receivers and, presumably,		delivery of multicast services to IPv4 receivers and, presumably,
	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),
	skipping to change at page 9, line 5		skipping to change at page 7, line 49
	Function AF2 is needed at the border between the IPv6 multicast		Function AF2 is needed at the border between the IPv6 multicast
	domain and the IPv4 multicast domain where the source resides. AF2		domain and the IPv4 multicast domain where the source resides. AF2
	is typically embedded in a multicast router that either terminates or		is typically embedded in a multicast router that either terminates or
	propagates PIM signalling directed toward the IPv4 source in the IPv6		propagates PIM signalling directed toward the IPv4 source in the IPv6
	multicast domain.		multicast domain.
	On the IPv4 side, AF2 also acts as a multicast router, and uses PIMv4		On the IPv4 side, AF2 also acts as a multicast router, and uses PIMv4
	signalling to join the IPv4 multicast group. The return path taken		signalling to join the IPv4 multicast group. The return path taken
	by multicast traffic is shown in Figure 2.		by multicast traffic is shown in Figure 2.
	+------+ +-----+ +------+ +------+ +-----+		+------+ +-----+ +------+ +------+ +-----+
	| Host | | DS | | MR | | MR | | |		| Host | | DS | | MR | | MR | | |
	| Rcvr |------| AF1 | | | . . . | |------| Src |		| Rcvr |------| AF1 | | | . . . | |------| Src |
	| | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | |		| | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | |
	+------+ +-----+ +------+ +------+ +-----+		+------+ +-----+ +------+ +------+ +-----+
	/ \		/ \
	/ IPv6 \ IPv4		/ IPv6 \ IPv4
	/ \		/ \
	+------+ +----+ +------+		+------+ +----+ +------+
	| MR | | | | DS |		| MR | | | | DS |
	| |------| MR | . . . | AF2 |		| |------| MR | . . . | AF2 |
	| (DR) | IPv6 | | IPv6 | (BG) |		| (DR) | IPv6 | | IPv6 | (BG) |
	+------+ +----+ +------+		+------+ +----+ +------+
	<-------------------------------------		<-------------------------------------
	Rcvr: Multicast receiver		Rcvr: Multicast receiver
	DS : Dual Stack		DS : Dual Stack
	AF : Adaptation Function		AF : Adaptation Function
	MR : Multicast router		MR : Multicast router
	DR : Designated Router		DR : Designated Router
	BG : Border Gateway		BG : Border Gateway
	Src : Multicast source		Src : Multicast source
	Figure 2: Multicast Traffic Forwarding Path for the 4-6-4 Scenario.		Figure 2: Multicast Traffic Forwarding Path for the 4-6-4 Scenario.
	Again, adaptation functions are needed whenever the IP protocol		Again, adaptation functions are needed whenever the IP protocol
	version changes. The adaptation function instance AF2 at the		version changes. The adaptation function instance AF2 at the
	boundary between the source network and the IPv6 network may either		boundary between the source network and the IPv6 network may either
	encapsulate or translate the headers of the IPv4 packets to allow the		encapsulate or translate the headers of the IPv4 packets to allow the
	content to cross the IPv6 network. The adaptation function instance		content to cross the IPv6 network. The adaptation function instance
	at the boundary between the IPv6 network and the receiver network		at the boundary between the IPv6 network and the receiver network
	performs the reverse operation to deliver IPv4 packets.		performs the reverse operation to deliver IPv4 packets.
	Given the current state-of-the-art where multicast content is likely		Given the current state-of-the-art where multicast content is likely
	skipping to change at page 11, line 5		skipping to change at page 9, line 36
	AF : Adaptation Function		AF : Adaptation Function
	MR : Multicast Router		MR : Multicast Router
	DR : Designated Router		DR : Designated Router
	BG : Border Gateway		BG : Border Gateway
	Figure 3: Signalling Path For the 6-4-6 Scenario.		Figure 3: Signalling Path For the 6-4-6 Scenario.
	Figure 4 shows the path taken by multicast traffic flowing from the		Figure 4 shows the path taken by multicast traffic flowing from the
	IPv6 source to the IPv6 receiver.		IPv6 source to the IPv6 receiver.
	+------+ +-----+ +------+ +------+		+------+ +-----+ +------+ +------+
	| Host | | DS | | MR | | MR |		| Host | | DS | | MR | | MR |
	| Rcvr |------| AF1 | | | . . . | |		| Rcvr |------| AF1 | | | . . . | |
	| | IPv6 | | | (BG) | IPv6 | (DR) |		| | IPv6 | | | (BG) | IPv6 | (DR) |
	+------+ +-----+ +------+ +------+		+------+ +-----+ +------+ +------+
	/ \ \		/ \ \
	/ IPv4 \ IPv6 \ IPv6		/ IPv4 \ IPv6 \ IPv6
	/ \ \		/ \ \
	+------+ +----+ +------+ +-----+		+------+ +----+ +------+ +-----+
	| MR | | | | DS | | |		| MR | | | | DS | | |
	| |------| MR | . . . | AF2 | | Src |		| |------| MR | . . . | AF2 | | Src |
	| (DR) | IPv4 | | IPv4 | (BG) | | |		| (DR) | IPv4 | | IPv4 | (BG) | | |
	+------+ +----+ +------+ +-----+		+------+ +----+ +------+ +-----+
	<-------------------------------------		<-------------------------------------
	Rcvr: Multicast receiver		Rcvr: Multicast receiver
	DS : Dual Stack		DS : Dual Stack
	AF : Adaptation Function		AF : Adaptation Function
	MR : Multicast Router		MR : Multicast Router
	DR : Designated Router		DR : Designated Router
	BG : Border Gateway		BG : Border Gateway
	Src : Multicast source		Src : Multicast source
	Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario.		Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario.
	3.3. IPv6 Receiver and IPv4 Source		3.3. IPv6 Receiver and IPv4 Source
	We refer to this scenario as 6-4. An example of such use case is the		We refer to this scenario as 6-4. An example of such use case is the
	context of some mobile networks, where terminal devices are only		context of some mobile networks, where terminal devices are only
	provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast		provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast
	content from an IPv6-only receiver requires additional functions to		content from an IPv6-only receiver requires additional functions to
	be enabled.		be enabled.
	This scenario is privileged by mobile operators who deploy NAT64		This scenario is privileged by mobile operators who deploy NAT64
	skipping to change at page 16, line 7		skipping to change at page 13, line 29
	Such ALG (Application Level Gateway) may also be required to help an		Such ALG (Application Level Gateway) may also be required to help an
	IPv6 receiver select the appropriate multicast group address when		IPv6 receiver select the appropriate multicast group address when
	only the IPv4 address is advertised (e.g., when the SDP (Session		only the IPv4 address is advertised (e.g., when the SDP (Session
	Description Protocol) protocol is used to advertise some contents);		Description Protocol) protocol is used to advertise some contents);
	otherwise, access to IPv4 multicast content from an IPv6 receiver may		otherwise, access to IPv4 multicast content from an IPv6 receiver may
	be compromised.		be compromised.
	ALGs may be located upstream in the network. As a consequence, these		ALGs may be located upstream in the network. As a consequence, these
	ALGs do not know in advance whether the receiver is dual-stack or		ALGs do not know in advance whether the receiver is dual-stack or
	IPv6-only. In order to avoid the use of an ALG in the path, an IPv4-		IPv6-only. In order to avoid the use of an ALG in the path, an
	only source can advertise both an IPv4 multicast group address and		IPv4-only source can advertise both an IPv4 multicast group address
	the corresponding IPv4-embedded IPv6 multicast group address		and the corresponding IPv4-embedded IPv6 multicast group address
	[I-D.ietf-mboned-64-multicast-address-format].		[I-D.ietf-mboned-64-multicast-address-format].
	However, a dual-stack receiver may prefer to use the IPv6 address to		However, a dual-stack receiver may prefer to use the IPv6 address to
	receive the multicast content. The selection of the IPv6 multicast		receive the multicast content. The selection of the IPv6 multicast
	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.
	skipping to change at page 16, line 36		skipping to change at page 14, line 11
	In case the underlying access network is IPv6, the information		In case the underlying access network is IPv6, the information
	conveyed in IGMP messages should be relayed by corresponding MLD		conveyed in IGMP messages should be relayed 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
	the multicast forwarding efficiency. This assumes a close		the multicast forwarding efficiency.
	interaction between the PIM designs enforced in both IPv4 and IPv6
	multicast domains, by means of specific Inter-Working Functions that		This assumes a close interaction between the PIM designs enforced in
	are further discussed in Section 4.4.		both IPv4 and IPv6 multicast domains, by means of specific Inter-
			Working Functions that are further discussed in Section 4.4.
	Such interaction may be complicated by different combinations: the		Such interaction may be complicated by different combinations: the
	IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point)		IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point)
	routers), while the IPv6 multicast domain may support both ASM (Any		routers), while the IPv6 multicast domain may support both ASM (Any
	Source Multicast) and SSM (Source Specific Multicast) [RFC3569]		Source Multicast) and SSM (Source Specific Multicast) [RFC3569]
	modes.		modes.
	4.4. Multicast Adaptation Functions (AF)		4.4. Multicast Adaptation Functions (AF)
	IPv4-IPv6 multicast interworking functions are required for both		IPv4-IPv6 multicast interworking functions are required for both
	translation (one address family to another) and traversal (one		translation (one address family to another) and traversal (one
	address family over another) contexts.		address family over another) contexts.
	Given the multiple versions of Group Membership management protocols,		Given the multiple versions of Group Membership management protocols,
	issues may be raised when, for example, IGMPv2 is running in the IPv4		issues may be raised when, for example, IGMPv2 is running in the IPv4
	multicast domain that is connected to the IPv6 multicast domain by		multicast domain that is connected to the IPv6 multicast domain by
	means of an IWF, while MLDv2 is running in the IPv6 multicast domain.		means of an IWF, while MLDv2 is running in the IPv6 multicast domain.
	To solve these problems, the design of the IWF function SHOULD adhere		To solve these problems, the design of the IWF function should adhere
	to the IP version-independent, protocol interaction approach		to the IP version-independent, protocol interaction approach
	documented in Section 8 of [RFC3810] and Section 7 of [RFC3376].		documented in Section 8 of [RFC3810] and Section 7 of [RFC3376].
	Note that, for traversal cases, to improve the efficiency of the		Note that, for traversal cases, to improve the efficiency of the
	multicast service delivery, traffic will be multicast along		multicast service delivery, traffic 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 bandwidth optimization purposes. As a		receivers as possible for bandwidth optimization purposes. As a
	reminder, the traversal of unicast-only (access) networks is not		reminder, the traversal of unicast-only (access) networks is not
	considered in this document.		considered in this document.
	4.4.1. AF For Control Flows		4.4.1. AF For Control Flows
	The IWF to process multicast signalling flows (such as IGMP or MLD		The IWF to process multicast signalling flows (such as IGMP or MLD
	Report messages) should be independent of the IP version and consist		Report messages) should be independent of the IP version and consist
	mainly of an IPv4-IPv6 adaptation element and an IP address		mainly of an IPv4-IPv6 adaptation element and an IP address
	translation element. The message format adaptation must follow what		translation element. The message format adaptation must follow what
	is specified in [RFC3810] or [RFC4601], and the device that embeds		is specified in [RFC3810] or [RFC4601], and the device that embeds
	the IWF device must be multicast-enabled, i.e., support IGMP, MLD		the IWF device must be multicast-enabled, i.e., support IGMP, MLD and
	and/or PIM, depending on the context (address family-wise) and the		/or PIM, depending on the context (address family-wise) and the
	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, PIMv4-		The IWF can then be operated in the following modes: IGMP-MLD,
	PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-Specific		PIMv4-PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-
	Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 signalling		Specific Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2
	traffic as well as the ability to directly send PIM (S, G) Join		signalling traffic as well as the ability to directly send PIM (S, G)
	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.
	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
	if SSM mode is used), the IGMP-MLD Interworking Function MUST send an		if SSM mode is used), the IGMP-MLD Interworking Function must send an
	MLD Report message to subscribe to the corresponding IPv6 multicast		MLD Report message to subscribe to the corresponding IPv6 multicast
	group.		group.
	4.4.1.2. IPv4-IPv6 PIM Interworking		4.4.1.2. IPv4-IPv6 PIM Interworking
	[RFC4601] allows the computation of PIM-based IPv4 or IPv6		[RFC4601] allows the computation of PIM-based IPv4 or IPv6
	distribution trees; PIM is IP version agnostic. There is no specific		distribution trees; PIM is IP version agnostic. There is no specific
	IPv6 PIM machinery that would work differently than an IPv4 PIM		IPv6 PIM machinery that would work differently than an IPv4 PIM
	machinery. The new features needed for the IPv4-IPv6 PIM		machinery. The new features needed for the IPv4-IPv6 PIM
	Interworking Function consist in dynamically triggering the PIM		Interworking Function consist in dynamically triggering the PIM
	message of Address Family 1 upon receipt of the equivalent PIM		message of Address Family 1 upon receipt of the equivalent PIM
	message of Address Family 2.		message of Address Family 2.
	The address mapping MUST be performed similarly to that of the IGMP-		The address mapping must be performed similarly to that of the IGMP-
	MLD Interworking Function.		MLD Interworking Function.
	4.4.1.3. MLD-IPv4 PIM Interworking		4.4.1.3. MLD-IPv4 PIM Interworking
	This IWF function is required when the MLD Querier is connected to an		This IWF function is required when the MLD Querier is connected to an
	IPv4 PIM domain.		IPv4 PIM domain.
	The address mapping MUST be performed similarly to that of the IGMP-		The address mapping must be performed similarly to that of the IGMP-
	MLD Interworking Function.		MLD Interworking Function.
	4.4.1.4. IGMP-IPv6 PIM Interworking		4.4.1.4. IGMP-IPv6 PIM Interworking
	The address mapping MUST be performed similarly to that of the IGMP-		The address mapping must be performed similarly to that of the IGMP-
	MLD Interworking Function.		MLD Interworking Function.
	4.4.2. AF For Data Flows		4.4.2. AF For Data Flows
	The IWF to be used for multicast data flows is operated at the		The IWF to be used for multicast data flows is operated at the
	boundary between IPv4 and IPv6 multicast networks. Either		boundary between IPv4 and IPv6 multicast networks. Either
	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 have been defined in
	[I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for IPv4-		[I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for
	embedded IPv6 multicast and unicast addresses. Mapping operations		IPv4-embedded IPv6 multicast and unicast addresses. Mapping
	are performed in a stateless manner by the algorithms specified in		operations are performed in a stateless manner by the algorithms
	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.).
	If stateful approaches are used, it is recommended to carefully		If stateful approaches are used, it is recommended to carefully
	investigate the need to synchronize mapping states between multiple		investigate the need to synchronize mapping states between multiple
	boxes, and the coordination of the IWF and source/group discovery		boxes, and the coordination of the IWF and source/group discovery
	elements is also required, at the cost of extra complexity.		elements is also required, at the cost of extra complexity.
	skipping to change at page 19, line 28		skipping to change at page 16, line 50
	4.5. Combination of ASM and SSM Modes		4.5. Combination of ASM and SSM Modes
	The ASM (Any Source Multicast) mode could be used to optimize the		The ASM (Any Source Multicast) mode could be used to optimize the
	forwarding of IPv4 multicast traffic sent by different sources into		forwarding of IPv4 multicast traffic sent by different sources into
	the IPv6 multicast domain by selecting RP routers that could be		the IPv6 multicast domain by selecting RP routers that could be
	located at the border between the IPv6 and the IPv4 multicast		located at the border between the IPv6 and the IPv4 multicast
	domains. This design may optimize the multicast forwarding		domains. This design may optimize the multicast forwarding
	efficiency in the IPv6 domain when access to several IPv4 multicast		efficiency in the IPv6 domain when access to several IPv4 multicast
	sources needs to be granted.		sources needs to be granted.
	5. What Is Expected From The IETF		5. IANA Considerations
	This document highlights the following IETF standardization needs:
	o Specify the inter-working function as described in Sections 4.4.1
	and 4.4.2. In particular:
	* Specify the algorithms used by various inter-working functions,
	covering both encapsulation and translation approaches
	* Specify the multicast IPv4-embedded address format
	* Document a 6-4 multicast architecture
	* Document a 4-6-4 multicast architecture
	o Document a Management Information Base (MIB) to be used for the
	management of IWF functions
	o Encourage the publication of various Applicability Statement
	documents to reflect IWF operational experience in different
	contexts
	6. 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.
	7. 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. This
	draft does not introduce any specific security issue.		draft does not introduce any specific security issue.
	8. Acknowledgments		7. Acknowledgments
	Special thanks to T. Taylor for providing the figures and some of the
	text that illustrate the use cases depicted in Section 3. Thanks
	also to H. Asaeda, M. Eubanks, N. Leymann and S. Venaas for their
	valuable comments.
	9. References		Special thanks to T. Taylor for providing the figures and some of
			the text that illustrate the use cases depicted in Section 3. Thanks
			also to H. Asaeda, M. Blanchet, M. Eubanks, N. Leymann, S.
			Perrault and S. Venaas for their valuable comments and support.
	9.1. Normative References		8. References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		8.1. Normative References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2236] Fenner, W., "Internet Group Management Protocol, Version		[RFC2236] Fenner, W.C., "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
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,		[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
	"Internet Group Management Protocol (IGMP) / Multicast		"Internet Group Management Protocol (IGMP) / Multicast
	Listener Discovery (MLD)-Based Multicast Forwarding		Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP
	("IGMP/MLD Proxying")", RFC 4605, August 2006.		/MLD Proxying")", RFC 4605, August 2006.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
	Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
	October 2010.
	[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.
	9.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",		Multicast Address", draft-ietf-mboned-64-multicast-
	draft-ietf-mboned-64-multicast-address-format-04 (work in		address-format-04 (work in progress), August 2012.
	progress), August 2012.
			[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
			Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
			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
End of changes. 51 change blocks.
	190 lines changed or deleted		139 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/