Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Intended status: Informational C. Zhou
Expires: September 1, 2011 T. Taylor
Huawei Technologies
February 28, 2011
A Classification and Evaluation of Approaches to Transitional Multicast
draft-tsou-multicast-transition-taxonomy-00
Abstract
A number of different contributions to the IETF make proposals in
support of multicast during the transition from IPv4 to IPv6. This
document provides a taxonomic framework to make it easier to see how
the different proposals relate to each other. It analyzes the
current work in progress in the light of this framework and draws a
number of conclusions regarding how this work should move forward in
the BEHAVE and SOFTWIRES Working Groups.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Tsou, et al. Expires September 1, 2011 [Page 1]
Internet-Draft Transitional Multicast Taxonomy February 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The Classification Framework . . . . . . . . . . . . . . . . . 3
3. Classification of the References According to the Framework . 4
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Tsou, et al. Expires September 1, 2011 [Page 2]
Internet-Draft Transitional Multicast Taxonomy February 2011
1. Introduction
As evidenced by the (probably incomplete) set of references shown
below, the handling of multicast during the transition from IPv4 to
IPv6 is the focus of a considerable amount of activity. This has
caused some difficulty within the BEHAVE and SOFTWIRES Working
Groups, where the question has been how to select the drafts that
should be Working Group work items, and which drafts would fit
together and should be combined.
This document introduces a framework for classification of the
subject matter of the various drafts dealing with multicast
transition. It applies the framework to the drafts shown in the
references, and draws conclusions from the results of the comparison.
1.1. Requirements Language
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].
However, this document is purely descriptive, and thus uses no
requirements language.
2. The Classification Framework
The classification framework proposed here consists of four
dimensions: the scenario(s) considered, the multicast topologies
considered, the translation techniques used, and whether multicast
content is encapsulated (aside from the tunneling used during the PIM
registration stage).
Scenarios
The scenarios considered in the various multicast transition
dicussions are either two-network (A, B) or three-network (A, B,
C), where A, B, and C are multicast-capable networks.
A and B always support different versions of IP, and in the three-
network case C supports the same IP version as A. Thus with
respect to IP version, the two-network cases can be classified as
IPv4 receiving IPv6 (4 <- 6) and IPv6 receiving IPv4 (6 <- 4).
The three-network cases can be classified as 4-6-4 or 6-4-6.
Multicast Topology
This refers to whether a contribution considers source specific
multicast (SSM), any-source multicast (ASM), or both.
Tsou, et al. Expires September 1, 2011 [Page 3]
Internet-Draft Transitional Multicast Taxonomy February 2011
Translation Technique
Address translation is always required at points where the IP
version changes, unless signalling and content are merely tunneled
across an intervening network rather than making use of that
network's native multicast capabilities. Different contributions
go into different levels of detail regarding the translation
schemes used for multicast source and group addresses. A basic
distinction is between stateful and stateless methods.
Use of tunneling
Some discussions deal only with translation. Others assume
tunneling of the multicast content, which necessarily implies a
three-network scenario. Translation is still required in this
case, to map between the <source, group> address pair used in
network B and the address pair used in networks A and C for the
same multicast stream. Tunneling does save a translation step for
multicast content reaching network A, compared with native
transport across network B.
3. Classification of the References According to the Framework
As an initial step, the following is a summary of the multicast
references covered in this document. The ordering of these documents
is that provided by the Datatracker search tool and is presumably
related to the date version -00 of each document was submitted.
1. An IPv4 - IPv6 multicast translator [ID.venaas-mcast46]
The initial version of this draft appeared in 2008, making it
the original source of the ideas appearing in the other drafts
described here. The basic scenario considered is two-network,
though three-network examples are considered (e.g., IPv4 host
sending to an IPv4 group through an IPv6 network). The document
discusses both 4 <- 6 and 6 <- 4, but the specific translation
mechanism proposed, embedding of IPv4 multicast addresses in
IPv6, places limits on the 4 <- 6 scenario. Both ASM and SSM
are considered. Alternatives are suggested for mapping of
unicast source addresses. For ASM, the translator is assumed to
be a rendezvous point on the IPv6 side. Tunneling is not
discussed.
2. Framework for IPv4/IPv6 Multicast Translation
[ID.venaas-v4v6mc-framework]
The initial part of this paper looks at a set of two-network
scenarios, both 4 <- 6 and 6 <- 4, with an additional variable
being whether network A or network B (but not both at once) is
Tsou, et al. Expires September 1, 2011 [Page 4]
Internet-Draft Transitional Multicast Taxonomy February 2011
the Internet. For each scenario it considers the applicable
mechanisms, which are those considered in [ID.venaas-mcast46]
but with further considerations and suggestions in the more
difficult cases. For this later paper, [RFC6052] is available
as a resource for translation of IPv4 source addresses to IPv6.
Both ASM and SSM are considered, and tunneling is mentioned at a
couple of points but not expanded upon. The latter part of the
paper discusses addressing, routing, translation, and
application issues in the light of the scenario analyses.
3. Multicast Proxy in IPv6/IPv4 Transition [ID.jiang-v4v6mc-proxy]
This document considers the two-network scenarios 4 <- 6 and 6
<- 4. It does not distinguish ASM or SSM. A multicast proxy
forwards requests for multicast streams from network A to
network B, receives the stream content, and forwards it directly
to the receivers. An implicit mapping step occurs at the
multicast proxy when a request from a network A receiver for a
network A multicast stream is translated into a request from the
multicast proxy for the corresponding network B multicast
stream. The reverse stream-to-stream mapping is needed to
ensure that the right streams from network B get forwarded to
the right receivers. There is no discussion of the mechanism
for achieving this mapping. There is no mention of tunneling.
4. Multicast Extensions to DS-Lite Technique in Broadband
Deployments [ID.qin-dslite-multicast]
This document considers the three-network 4-6-4 scenario
specifically as encountered when using the DS Lite transition
mechanism. Network A is the network at the customer site.
Network B is the IPv6 access network to which the customer site
is attached. DS Lite uses IPv4-in-IPv6 tunneling to carry IPv4
traffic across network B. The objective is to reduce the load on
the AFTR at the border between network B and network C and make
more efficient use of network B bandwidth through use of native
network B multicast capability. The paper effectively restricts
itself to SSM, although it discusses how to accommodate ASM
where the sources are all in network C. It uses the embedded
IPv4 address approach to translation, with specific dependency
on [RFC6052] for source addresses and
[ID.boucadair-64-multicast-address-format] for multicast group
addresses.
5. Multicast Considerations for Gateway-Initiated Dual-Stack Lite
[ID.brockners-mcast-gi-ds-lite]
Like the previous document, this one considers multicast for a
Tsou, et al. Expires September 1, 2011 [Page 5]
Internet-Draft Transitional Multicast Taxonomy February 2011
4-6-4 tunneling scenario. It restricts itself to SSM.
Translation is not discussed.
6. Softwire Mesh Multicast [ID.xu-mesh-multicast]
This document considers a three-network scenario where network B
is an IP backbone. Both 4-6-4 and 6-4-6 scenarios are
considered. No distinction is made between ASM and SSM. For
the 4-6-4 scenario, the usual device of embedded IPv4 addresses
is used. For the 6-4-6 scenario, additional signalling between
the edge devices (AFBRs) is used to ensure that the multicast
flows are matched up correctly. Tunneling is an essential
feature of the discussion.
7. IPv4-Embedded IPv6 Multicast Address Format
[ID.boucadair-64-multicast-address-format]
This document is written to standardize the format of the IPv4-
embedded IPv6 multicast address. Effectively it addresses the
two-network 6 <- 4 scenario or the three-network 4-6-4 scenario,
although that is not explicitly stated. Both ASM and SSM
addresses are considered. The proposal applies to both native
and tunneled transport.
8. IPv6 Multicast Using Native IPv4 Capabilities in a 6rd
Deployment [ID.tsou-6rd-multicast]
This document specifically addresses the three-network 6-4-6
scenario, where network A is the customer site and network B is
the access network to which the customer is attached. Neither
ASM nor SSM is mentioned, although the proposal is applicable to
both. The document relies on stateful mapping. Although
described in conjunction with a tunneling mechanism (6rd), the
proposal uses native transport for multicast content.
9. Multicast Support for NAT64 [ID.sarikaya-mcast4nat64]
This document considers the two-network 6 <- 4 scenario. ASM
and SSM are discussed. IPv4 embedded addresses are used for
translation, with explicit reference to
[ID.boucadair-64-multicast-address-format]. The document
assumes native transport rather than tunneling.
10. A Generic Approach to Multicast Translation In Support of IPv6
Transition [ID.tsou-translated-multicast]
This document considers the generic three-network scenario, with
intended applicability to both 4-6-4 and 6-4-6. Network A is
Tsou, et al. Expires September 1, 2011 [Page 6]
Internet-Draft Transitional Multicast Taxonomy February 2011
the customer site, network B is the access network to which the
customer is connected. (Note that the designations A, B, and C
used in the present document differ from those used in
[ID.tsou-translated-multicast].) ASM and SSM are both in the
intended scope. Translation uses the stateful mapping mechanism
described in [ID.tsou-6rd-multicast]. Tunneling of multicast
content is not considered.
11. A Generic Approach to Multicast tunneling In Support of IPv6
Transition [ID.tsou-encapsulated-multicast]
This document has the same scope as the previous document, with
the one difference that it considers tunneled transport of
multicast content.
12. IPv4/IPv6 Multicast Translation Framework
[ID.lee-v4v6-mcast-fwk]
This document is basically an enumeration of two-network
scenarios, both 6 <- 4 and 4 <- 6, with comments on when they
are likely to be encountered. Having become aware of
[ID.venaas-v4v6mc-framework], the authors intend to retarget
this work.
Table 1 summarizes the contents of the respective drafts according to
the four dimensions presented in Section 2. The first column of the
table identifies each draft by the sequence number given to it in the
descriptions presented above.
Tsou, et al. Expires September 1, 2011 [Page 7]
Internet-Draft Transitional Multicast Taxonomy February 2011
+-------+-----------+------------------------+---------+-----------+
| Draft | Scenarios | Translation Mechanism | ASM/SSM | Tunneling |
+-------+-----------+------------------------+---------+-----------+
| 1 | 4 <- 6 | Specific IPv6 prefixes | Both | No |
| | 6 <- 4 | Embedded IPv4 | | |
| ----- | ----- | ----- | ----- | ----- |
| 2 | 4 <- 6 | Various ideas | Both | No |
| | 6 <- 4 | Embedded IPv4 | | |
| ----- | ----- | ----- | ----- | ----- |
| 3 | 4 <- 6 | ND | ND | No |
| | 6 <- 4 | | | |
| ----- | ----- | ----- | ----- | ----- |
| 4 | 4-6-4 | Embedded IPv4 | SSM * | Yes |
| ----- | ----- | ----- | ----- | ----- |
| 5 | 4-6-4 | ND | SSM | Yes |
| ----- | ----- | ----- | ----- | ----- |
| 6 | 4-6-4 | Embedded IPv4 | ND | Yes |
| | 6-4-6 | Additional signalling | | |
| ----- | ----- | ----- | ----- | ----- |
| 7 | 6 <- 4 | Embedded IPv4 | Both | ND |
| | 4-6-4 | ditto | | |
| ----- | ----- | ----- | ----- | ----- |
| 8 | 6-4-6 | Stateful mapping | ND | No |
| ----- | ----- | ----- | ----- | ----- |
| 9 | 6 <- 4 | Embedded IPv4 | Both | No |
| ----- | ----- | ----- | ----- | ----- |
| 10 | 4-6-4 | Stateful mapping | ND | No |
| | 6-4-6 | ditto | | |
| ----- | ----- | ----- | ----- | ----- |
| 11 | 4-6-4 | Stateful mapping | ND | Yes |
| | 6-4-6 | ditto | | |
| ----- | ----- | ----- | ----- | ----- |
| 12 | 6 <- 4 | ND | ND | ND |
| | 4 <- 6 | | | |
+-------+-----------+------------------------+---------+-----------+
* [ID.qin-dslite-multicast] considers the use of ASM in network C
only. ND = Not discussed
Table 1: Multicast Transition Draft Content Summarized
4. Conclusions
The above analysis leads to a number of suggestions for moving
forward.
Tsou, et al. Expires September 1, 2011 [Page 8]
Internet-Draft Transitional Multicast Taxonomy February 2011
o It is suggested that, because of the completeness of its coverage,
[ID.venaas-v4v6mc-framework] should be the document on which all
other multicast transition work should be based. However, details
relating to embedding IPv4 addresses in IPv6 multicast addresses
should be removed and left for another document. It is possible
that other material may be subject to removal to a more
specialized document, but this requires further thought. The
document may belong formally to either BEHAVE or SOFTWIRES, but
must be reviewed and approved by both Working Groups.
o The need for [ID.boucadair-64-multicast-address-format] is quite
clear, and the document should become a BEHAVE work item.
o It should be possible to create a document considering the details
of multicast transition in a tunneling environment, applicable to
both 4-6-4 and 6-4-6. In particular, this document should make
clear that translation is also applicable when tunneling, but to a
lesser extent than in the case of native transport. It is
expected that with this document and [ID.venaas-v4v6mc-framework]
as starting points, [ID.qin-dslite-multicast] can discard some of
its content and end up looking more like
[ID.brockners-mcast-gi-ds-lite].
o [ID.xu-mesh-multicast] relates specifically to multicast
transition in a backbone network. In this, it differs from the
other documents reviewed, most of which assume that network B is
an access network. Some content may duplicate material in other
documents mentioned above and may thus be subject to removal, but
there is definitely enough material for this to remain a separate
document.
o The current priority is the 6 <- 4 or 4-6-4 scenario.
Nevertheless, it is desirable that work on good solutions for the
4 <- 6 or 6-4-6 scenario should continue, since this is a harder
problem and may take some time. BEHAVE would be the natural
location for this work.
The classification scheme proposed in this document did not capture
all of the contributions of the individual drafts. For instance,
[ID.sarikaya-mcast4nat64] has a number of useful details outside the
scope considered here. It may be possible to identify more problems
of general scope once work on the basics identified here is in hand.
It is also possible that a number of specialized documents like
[ID.xu-mesh-multicast] and [ID.brockners-mcast-gi-ds-lite] should be
written to cover specific scenarios.
Tsou, et al. Expires September 1, 2011 [Page 9]
Internet-Draft Transitional Multicast Taxonomy February 2011
5. Security Considerations
This document introduces no new security considerations.
6. IANA Considerations
This document introduces no IANA considerations.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[ID.boucadair-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
in progress)", February 2011.
[ID.brockners-mcast-gi-ds-lite]
Brockners, F. and Y. Lee, "Multicast Considerations for
Gateway-Initiated Dual-Stack Lite (Work in progress)",
October 2010.
[ID.jiang-v4v6mc-proxy]
Jiang, S. and D. Gu, "Multicast Proxy in IPv6/IPv4
Transition (Work in progress)", January 2011.
[ID.lee-v4v6-mcast-fwk]
Lee, Y. and J. Qin, "IPv4/IPv6 Multicast Translation
Framework (Work in progress)", February 2011.
[ID.qin-dslite-multicast]
Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C.,
and Y. Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments (Work in progress)", January 2011.
[ID.sarikaya-mcast4nat64]
Sarikaya, B., "Multicast Support for NAT64 (Work in
progress)", January 2011.
[ID.tsou-6rd-multicast]
Tsou, T., Taylor, T., Zhou, C., and H. Ji, "IPv6 Multicast
Tsou, et al. Expires September 1, 2011 [Page 10]
Internet-Draft Transitional Multicast Taxonomy February 2011
Using Native IPv4 Capabilities in a 6rd Deployment (Work
in progress)", January 2011.
[ID.tsou-encapsulated-multicast]
Tsou, T., Zhou, C., and H. Ji, "A Generic Approach to
Multicast tunneling In Support of IPv6 Transition (Work
in progress)", January 2011.
[ID.tsou-translated-multicast]
Tsou, T., Taylor, T., Zhou, C., and H. Ji, "A Generic
Approach to Multicast Translation In Support of IPv6
Transition (Work in progress)", January 2011.
[ID.venaas-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator (Work in progress)",
December 2010.
[ID.venaas-v4v6mc-framework]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation (Work in progress)", December 2010.
[ID.xu-mesh-multicast]
Xu, M., Cui, Y., Yang, S., Metz, C., and G. Shepherd,
"Softwire Mesh Multicast (Work in progress)",
October 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Authors' Addresses
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tena@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Tsou, et al. Expires September 1, 2011 [Page 11]
Internet-Draft Transitional Multicast Taxonomy February 2011
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.t
Ottawa, Ontario K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Tsou, et al. Expires September 1, 2011 [Page 12]