Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Informational                                   C. Zhou
Expires: September 15, 2011                                    T. Taylor
                                                     Huawei Technologies
                                                          March 14, 2011


A Classification and Evaluation of Approaches to Transitional Multicast
              draft-tsou-multicast-transition-taxonomy-01

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 15, 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 15, 2011               [Page 1]


Internet-Draft       Transitional Multicast Taxonomy          March 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  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
































Tsou, et al.           Expires September 15, 2011               [Page 2]


Internet-Draft       Transitional Multicast Taxonomy          March 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 15, 2011               [Page 3]


Internet-Draft       Transitional Multicast Taxonomy          March 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 15, 2011               [Page 4]


Internet-Draft       Transitional Multicast Taxonomy          March 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 15, 2011               [Page 5]


Internet-Draft       Transitional Multicast Taxonomy          March 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 15, 2011               [Page 6]


Internet-Draft       Transitional Multicast Taxonomy          March 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.

   13.  IPv4-IPv6 Multicast: Problem Statement and Use Cases
        [ID.jaclee-v4v6-mcast-ps]

        This document is a more in-depth examination of various
        scenarios that arise depending on the transition mechanisms
        deployed by the operator.  It notes operational issues that can
        complicate the choice of transition techniques in particular
        deployments.  One point raised is how to handle situations where
        there is a mixture of IPv6 and IPv4 terminals.  A key constraint
        on the discussion is that the transition methods consider must
        accommodate a trend to single virtual connections between the
        customer site and the IP edge, as opposed to multiple service-
        specific connections.  This is translated into a requirement to
        avoid use of private IPv4 addressing for the multicast
        sources(?).

   14.  Automatic IP Multicast Without Explicit Tunnels (AMT)
        [ID.mboned-auto-multicast]

        This document defines an architecture and protocol in the spirit
        of 6to4 ([RFC3056]), whereby isolated multicast sites can
        connect either to a multicast backbone or directly to each
        other.  Access to each site is through an AMT Gateway.  Access
        to the multicast backbone is through AMT Relays.  The unicast



Tsou, et al.           Expires September 15, 2011               [Page 7]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


        network serves as a link between these entities, through the
        mechanism of encapsulation.  Scalability issues are addressed
        when necessary by supplementing this structure with permanent
        tunnels between the the AMT sites and the multicast backbone.
        Following discovery and handshakes using the protocol defined in
        the AMT document, IGMP/MLD signalling is sent to the AMT
        Gateways to establish listener relationships.  AMT supports SSM
        only from AMT sites, but allows them to receive ASM.  From the
        point of view of the network model used in this document, the
        AMT site corresponds to network A, the intervening unicast
        network to network B, and the multicast backbone to network C.

   15.  Multicast Support for Dual Stack Lite and 6RD
        [ID.sarikaya-dslite-multicast]

        This document considers the DS-Lite (4-6-4) and 6rd (6-4-6)
        scenarios.  In both cases it proposes the simplest multicast
        strategy: encapsulation of multicast signalling in the one
        direction and multicast content in the other as unicast traffic.
        The customer equipment (DS-Lite B4, 6rd CE) is required to act
        as a proxy for IGMP or MLD respectively.  The border element
        (DS-Lite AFTR, 6rd Border Relay) is required to act as an IGMP
        querier (respectively MLD querier).  Otherwise network B is
        unaware of the multicast traffic.

   16.  Multicast Transition to IPv6 Only in Broadband Deployments
        [ID.tsou-multicast-transition-v6only]

        This document defines a transition path that assumes the
        technology of the CPE, access network, and multicast sources are
        all under operator control.  The basic evolution of each of
        these three components is through dual stack to IPv6, but the
        timing is different for the different elements.  In consequence
        of the suggested transition path, neither translation nor
        encapsulation is required at any stage.

   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.

   +-------+-----------+--------------------+-------------+------------+
   | Draft | Scenarios | Translation        |   ASM/SSM   |  Tunneling |
   |       |           | Mechanism          |             |            |
   +-------+-----------+--------------------+-------------+------------+
   |   1   | 4 <- 6    | Specific IPv6      |     Both    |     No     |
   |       |           | prefixes           |             |            |
   |       | 6 <- 4    | Embedded IPv4      |             |            |



Tsou, et al.           Expires September 15, 2011               [Page 8]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


   | ----- | -----     | -----              |    -----    |    -----   |
   |   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    |                    |             |            |
   | ----- | -----     | -----              |    -----    |    -----   |
   |   13  | All       | General discussion |     Some    |   General  |
   |       |           |                    | restriction | discussion |
   | ----- | -----     | -----              |    -----    |    -----   |
   |   14  | 4-6-4     | Special prefixes   |     SSM     |     Yes    |
   |       |           | plus supplementary |             |            |
   |       |           | protocol           |             |            |
   |       | 6-4-6     |                    |             |            |
   | ----- | -----     | -----              |    -----    |    -----   |
   |   15  | 4-6-4     | Border element     |     SSM     |     Yes    |
   |       |           | retains leaf node  |             |            |
   |       |           | multicast state    |             |            |
   |       | 6-4-6     | ditto              |             |            |
   | ----- | -----     | -----              |    -----    |    -----   |
   |   16  | 4-4-4     | None               |      ND     |     No     |
   +-------+-----------+--------------------+-------------+------------+

   ND = Not discussed. * [ID.qin-dslite-multicast] considers the use of



Tsou, et al.           Expires September 15, 2011               [Page 9]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


                          ASM in network C only.

          Table 1: Multicast Transition Draft Content Summarized


4.  Conclusions

   The above analysis leads to a number of suggestions for moving
   forward.

   o  For lack of time, a detailed comparison of
      [ID.venaas-v4v6mc-framework] and [ID.lee-v4v6-mcast-fwk] has not
      yet been carried out.  This needs to be done to determine what the
      latter document adds to the discussion and the implications for
      the organization of documentation related to multicast transition.

   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.





Tsou, et al.           Expires September 15, 2011              [Page 10]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


   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.


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.jaclee-v4v6-mcast-ps]
              Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
              Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use



Tsou, et al.           Expires September 15, 2011              [Page 11]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


              Cases (Work in progress)", March 2011.

   [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.mboned-auto-multicast]
              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
              Pusateri, "Automatic IP Multicast Without Explicit Tunnels
              (AMT) (Work in progress)", March 2010.

   [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-dslite-multicast]
              Sarikaya, B., "Multicast Support for Dual Stack Lite and
              6RD (Work in progress)", March 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
              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-multicast-transition-v6only]
              Tsou, T. and T. Taylor, "Multicast Transition to IPv6 Only
              in Broadband Deployments (Work in progress)", March 2010.

   [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]



Tsou, et al.           Expires September 15, 2011              [Page 12]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


              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.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [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


   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathyzhou@huawei.com









Tsou, et al.           Expires September 15, 2011              [Page 13]


Internet-Draft       Transitional Multicast Taxonomy          March 2011


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave.t
   Ottawa, Ontario  K1H 6Z8
   Canada

   Phone:
   Email: tom111.taylor@bell.net











































Tsou, et al.           Expires September 15, 2011              [Page 14]