draft-ietf-mboned-v4v6-mcast-ps-00.txt		draft-ietf-mboned-v4v6-mcast-ps-01.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: November 12, 2012 Y. Lee		Expires: May 13, 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
	May 11, 2012		November 09, 2012
	IPv4-IPv6 Multicast: Problem Statement and Use Cases		IPv4-IPv6 Multicast: Problem Statement and Use Cases
	draft-ietf-mboned-v4v6-mcast-ps-00		draft-ietf-mboned-v4v6-mcast-ps-01
	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		Requirements Language
	skipping to change at page 1, line 47		skipping to change at page 1, line 47
	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 November 12, 2012.		This Internet-Draft will expire on May 13, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Organization of the Document . . . . . . . . . . . . . . . 6		1.3. Organization of the Document . . . . . . . . . . . . . . . 5
	2. Scope and Service Requirements . . . . . . . . . . . . . . . . 6		2. Scope and Service Requirements . . . . . . . . . . . . . . . . 5
	2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Service Requirements . . . . . . . . . . . . . . . . . . . 7		2.2. Service Requirements . . . . . . . . . . . . . . . . . . . 6
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . . . . . . . . . 8		Network . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. IPv6 Receiver Connected to an IPv4 Source Through an		3.2. IPv6 Receiver and Source Connected to an IPv4-Only
	IPv4 Multicast-Disabled Access Network and an IPv6		Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Multicast Network . . . . . . . . . . . . . . . . . . . . 10		3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 11
	3.3. IPv6 Receiver and Source Connected to an IPv4-Only		3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 13
	Network . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.4. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 14		4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15
	3.5. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 16		4.1. Group and Source Discovery Considerations . . . . . . . . 15
	3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18		4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 16
	4. Design Considerations . . . . . . . . . . . . . . . . . . . . 18		4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 16
	4.1. Group and Source Discovery Considerations . . . . . . . . 18		4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 17
	4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 19		4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . . 17
	4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 19		4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 18
	4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 20		4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 18
	4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . . 20		4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 19
	4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 21		5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 19
	4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 21		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 22		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 22		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 23		9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . . 21
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	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 6, line 41		skipping to change at page 5, line 41
	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 address		network is *IP multicast-enabled*. That is, whatever the IP
	family of the content, the latter will be multicast along		address family of the content, this content will be multicast
	distribution trees that should be terminated as close to the		along 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 is 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
	skipping to change at page 10, line 46		skipping to change at page 9, line 46
	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
	to remain IPv4-formatted while receiver devices such as Set Top Boxes		to remain IPv4-formatted while receiver devices such as Set Top Boxes
	will also remain IPv4-only for quite some time, this scenario is		will also remain IPv4-only for quite some time, this scenario is
	prioritized by some service providers, including those that are		prioritized by some service providers, including those that are
	deploying or will deploy DS-Lite CGN capabilities for the sake of		deploying or will deploy DS-Lite CGN capabilities for the sake of
	IPv4 service continuity.		IPv4 service continuity.
	3.2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4		3.2. IPv6 Receiver and Source Connected to an IPv4-Only Network
	Multicast-Disabled Access Network and an IPv6 Multicast Network
	One major provider faces a complex transitional situation where the
	receiver is IPv6, the CPE router is dual stack unmanaged router, and
	the IPv4 access network is not multicast-enabled. This IPv4 unicast-
	only access network connects to the IPv4 source via an IPv6
	multicast-enabled metro network.
	This scenario is denoted as the 6-4-6-4 scenario.
	Because the provider does not manage the CPE router, encapsulation of
	IPv6 packets across the IPv4 network is unlikely. Figure 3 shows the
	signalling path for this scenario.
	+------+ +-----+ +----+ +------+
	| Host | MLD | DS | IGMP | | PIM | DS |
	| Rcvr |------| AF0 |------| PE | . . .| AF1 |
	| | IPv6 |(CPE)| IPv4 | | IPv4 | (BG) |
	+------+ +-----+ +----+ +------+
	/
	-----------------<----------
	/ MLD over IPv6
	+------+ +----+ +------+
	| MR | PIM | | PIM | DS |
	| |------| MR | . . . | AF2 |
	| (DR) | IPv6 | | IPv6 | (BG) |
	+------+ +----+ +------+
	/
	-----------------<-------
	/ PIM over IPv4
	+------+ +------+
	| MR | PIM | MR |
	| | . . . . | |
	| (BG) | IPv4 | (DR) |
	+------+ +------+
	------------------------------------->
	Rcvr: Multicast receiver
	DS : Dual Stack
	AF : Adaptation Function
	MR : Multicast Router
	DR : Designated Router
	CPE : Customer Premises Equipment (Dual Stack router)
	PE : Provider Edge router
	BG : Border Gateway
	Figure 3: Signalling Path For the 6-4-6-4 Scenario.
	The major challenge of this scenario is how to ensure that signalling
	packets from the CPE that embeds AF0 reach the adaptation function
	AF1 located at the boundary between the IPv4 multicast-disabled
	access network and the IPv6 multicast network.
	Figure 4 shows the path taken by multicast traffic flowing from the
	source to the receiver. Again, AF2 can either encapsulate or
	translate the headers of the incoming packets. AF1 performs the
	reverse action, and forwards unencapsulated IPv4 packets towards AF0.
	AF0 then needs to forward the IPv6 multicast packets that are
	equivalent to the incoming IPv4 multicast packets towards the IPv6
	receiver.
	+------+ +-----+ +----+ +------+
	| Host | | DS | | | | DS |
	| Rcvr |------| AF0 |------| PE | . . .| AF1 |
	| | IPv6 |(CPE)| IPv4 | | IPv4 | (BG) |
	+------+ +-----+ +----+ +------+
	/
	----------------->----------
	/ IPv6
	+------+ +----+ +------+
	| MR | | | | DS |
	| |------| MR | . . . | AF2 |
	| (DR) | IPv6 | | IPv6 | (BG) |
	+------+ +----+ +------+
	/
	----------------->-------
	/ IPv4
	+------+ +------+ +-----+
	| MR | | MR | | |
	| | . . . . | |------| Src |
	| (BG) | IPv4 | (DR) | IPv4 | |
	+------+ +------+ +-----+
	<-------------------------------------
	Rcvr: Multicast receiver
	Src : Multicast source
	DS : Dual Stack
	AF : Adaptation function
	MR : Multicast Router
	DR : Designated Router
	CPE : Customer Premises Equipment (Dual Stack router)
	PE : Provider Edge router
	BG : Border Gateway
	Figure 4: Multicast Traffic Forwarding Path For the 6-4-6-4 Scenario.
	3.3. IPv6 Receiver and Source Connected to an IPv4-Only Network
	We refer to this scenario as 6-4-6. Since providers who own the		We refer to this scenario as 6-4-6. Since providers who own the
	multicast content may not be ready for IPv6 migration beofre some		multicast content may not be ready for IPv6 migration beofre some
	time, the content is likely to remain IPv4-formatted. As a		time, the content is likely to remain IPv4-formatted. As a
	consequence, this 6-4-6 scenario is of lower priority than the 4-6-4		consequence, this 6-4-6 scenario is of lower priority than the 4-6-4
	scenario.		scenario.
	The signalling path for the 6-4-6 scenario is illustrated in Figure		The signalling path for the 6-4-6 scenario is illustrated in Figure
	5.		3.
	+------+ +-----+ +------+ +------+		+------+ +-----+ +------+ +------+
	| Host | MLD | DS | | MR | PIM | MR |		| Host | MLD | DS | | MR | PIM | MR |
	| Rcvr |------| AF1 | | | . . . . | |		| Rcvr |------| AF1 | | | . . . . | |
	| | IPv6 | | | (BG) | IPv6 | (DR) |		| | IPv6 | | | (BG) | IPv6 | (DR) |
	+------+ +-----+ +------+ +------+		+------+ +-----+ +------+ +------+
	/ \		/ \
	IGMP / IPv4 PIM \ IPv6		IGMP / IPv4 PIM \ IPv6
	/ \		/ \
	+------+ +----+ +------+		+------+ +----+ +------+
	skipping to change at page 13, line 34		skipping to change at page 10, line 31
	------------------------------------->		------------------------------------->
	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
	Figure 5: Signalling Path For the 6-4-6 Scenario.		Figure 3: Signalling Path For the 6-4-6 Scenario.
	Figure 6 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
	/ \ \		/ \ \
	skipping to change at page 14, line 29		skipping to change at page 11, line 29
	<-------------------------------------		<-------------------------------------
	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 6: Multicast Traffic Forwarding Path For the 6-4-6 Scenario.		Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario.
	3.4. 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
	capabilities in their network. It is illustrated in Figures 7		capabilities in their network. It is illustrated in Figures 5
	(signalling path) and 8 (forwarding of multicast traffic). Only one		(signalling path) and 6 (forwarding of multicast traffic). Only one
	adaptation function instance is needed, and it will be located at the		adaptation function instance is needed, and it will be located at the
	IPv4/IPv6 multicast domain boundary.		IPv4/IPv6 multicast domain boundary.
	+------+ +------+ +------+		+------+ +------+ +------+
	| Host | | MR | PIM | MR |		| Host | | MR | PIM | MR |
	| Rcvr | | | . . . . | |		| Rcvr | | | . . . . | |
	| | | (BG) | IPv4 | (DR) |		| | | (BG) | IPv4 | (DR) |
	+------+ +------+ +------+		+------+ +------+ +------+
	\ \		\ \
	MLD \ IPv6 PIM \ IPv4		MLD \ IPv6 PIM \ IPv4
	skipping to change at page 15, line 28		skipping to change at page 12, line 28
	------------------------------------->		------------------------------------->
	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
	Figure 7: Signalling Path For the 6-4 Scenario.		Figure 5: Signalling Path For the 6-4 Scenario.
	+------+ +------+ +------+		+------+ +------+ +------+
	| Host | | MR | | MR |		| Host | | MR | | MR |
	| Rcvr | | | . . . . | |		| Rcvr | | | . . . . | |
	| | | (BG) | IPv4 | (DR) |		| | | (BG) | IPv4 | (DR) |
	+------+ +------+ +------+		+------+ +------+ +------+
	\ \ \		\ \ \
	\ IPv6 \ IPv4 \ IPv4		\ IPv6 \ IPv4 \ IPv4
	\ \ \		\ \ \
	+------+ +----+ +------+ +-----+		+------+ +----+ +------+ +-----+
	skipping to change at page 16, line 29		skipping to change at page 13, line 29
	<-------------------------------------		<-------------------------------------
	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 8: Multicast Traffic Forwarding Path For the 6-4 Scenario.		Figure 6: Multicast Traffic Forwarding Path For the 6-4 Scenario.
	3.5. IPv4 Receiver and IPv6 Source		3.4. IPv4 Receiver and IPv6 Source
	We refer to this scenario as 4-6. Yet, multicast sources are likely		We refer to this scenario as 4-6. Yet, multicast sources are likely
	to remain IPv4-enabled in a first stage; therefore, the content is		to remain IPv4-enabled in a first stage; therefore, the content is
	likely to remain IPv4-formatted. As a consequence, this scenario is		likely to remain IPv4-formatted. As a consequence, this scenario is
	unlikely to occur during the first years of the transition period,		unlikely to occur during the first years of the transition period.
	and has been assigned a lower priority compared to the use cases
	depicted in Sections 3.1, 3.2 and 3.4.
	The signalling path for this scenario is shown in Figure 9. The		The signalling path for this scenario is shown in Figure 7. The
	multicast traffic forwarding path is shown in Figure 10. There are		multicast traffic forwarding path is shown in Figure 8. There are
	similarities with the 6-4 scenario but address mapping across IP		similarities with the 6-4 scenario but address mapping across IP
	version boundaries is more challenging.		version boundaries is more challenging.
	+------+ +------+ +------+		+------+ +------+ +------+
	| Host | | MR | PIM | MR |		| Host | | MR | PIM | MR |
	| Rcvr | | | . . . . | |		| Rcvr | | | . . . . | |
	| | | (BG) | IPv6 | (DR) |		| | | (BG) | IPv6 | (DR) |
	+------+ +------+ +------+		+------+ +------+ +------+
	\ \		\ \
	IGMP \ IPv4 PIM \ IPv6		IGMP \ IPv4 PIM \ IPv6
	skipping to change at page 17, line 28		skipping to change at page 14, line 28
	------------------------------------->		------------------------------------->
	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
	Figure 9: Signalling Path For the 4-6 Scenario.		Figure 7: Signalling Path For the 4-6 Scenario.
	+------+ +------+ +------+		+------+ +------+ +------+
	| Host | | MR | | MR |		| Host | | MR | | MR |
	| Rcvr | | | . . . . | |		| Rcvr | | | . . . . | |
	| | | (BG) | IPv6 | (DR) |		| | | (BG) | IPv6 | (DR) |
	+------+ +------+ +------+		+------+ +------+ +------+
	\ \ \		\ \ \
	\ IPv4 \ IPv6 \ IPv6		\ IPv4 \ IPv6 \ IPv6
	\ \ \		\ \ \
	+------+ +----+ +------+ +-----+		+------+ +----+ +------+ +-----+
	| MR | | | | DS | | |		| MR | | | | DS | | |
	| |------| MR | . . . | AF1 | | Src |		| |------| MR | . . . | AF1 | | 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 10: Multicast Traffic Forwarding Path For the 4-6 Scenario.		Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario.
	3.6. 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, 6-4-6-4 and 6-4 scenarios.		IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios.
	4. Design Considerations		4. Design Considerations
	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.
	skipping to change at page 22, line 42		skipping to change at page 19, line 42
	o Specify the inter-working function as described in Sections 4.4.1		o Specify the inter-working function as described in Sections 4.4.1
	and 4.4.2. In particular:		and 4.4.2. In particular:
	* Specify the algorithms used by various inter-working functions,		* Specify the algorithms used by various inter-working functions,
	covering both encapsulation and translation approaches		covering both encapsulation and translation approaches
	* Specify the multicast IPv4-embedded address format		* Specify the multicast IPv4-embedded address format
	* Document a 6-4 multicast architecture		* Document a 6-4 multicast architecture
	* Document a 6-4-6-4 multicast architecture
	* Document a 4-6-4 multicast architecture		* Document a 4-6-4 multicast architecture
	o Document a Management Information Base (MIB) to be used for the		o Document a Management Information Base (MIB) to be used for the
	management of IWF functions		management of IWF functions
	o Encourage the publication of various Applicability Statement		o Encourage the publication of various Applicability Statement
	documents to reflect IWF operational experience in different		documents to reflect IWF operational experience in different
	contexts		contexts
	6. IANA Considerations		6. IANA Considerations
	skipping to change at page 24, line 23		skipping to change at page 21, line 19
	Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,		Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
	October 2010.		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		9.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, "IPv4-Embedded IPv6 Multicast Address Format",		M. Xu, "IPv6 Multicast Address With Embedded IPv4
	draft-ietf-mboned-64-multicast-address-format-01 (work in		Multicast Address",
	progress), February 2012.		draft-ietf-mboned-64-multicast-address-format-04 (work in
			progress), August 2012.
	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
	skipping to change at page 25, line 14		skipping to change at page 22, line 14
	Yiu Lee		Yiu Lee
	Comcast		Comcast
	US		US
	Email: Yiu_Lee@Cable.Comcast.com		Email: Yiu_Lee@Cable.Comcast.com
	Jacni Qin		Jacni Qin
	Cisco Systems		Cisco Systems
	People's Republic of China		People's Republic of China
	Email: jacniq@gmail.com		Email: jacni@jacni.com
	Tina Tsou		Tina Tsou
	Huawei Technologies (USA)		Huawei Technologies (USA)
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95050		Santa Clara, CA 95050
	USA		USA
	Phone: +1 408 330 4424		Phone: +1 408 330 4424
	Email: tena@huawei.com		Email: tena@huawei.com
End of changes. 30 change blocks.
	190 lines changed or deleted		85 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/