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/