BEHAVE Working Group                                        C. Jacquenet
Internet-Draft                                              M. Boucadair
Intended status: Informational                            France Telecom
Expires: December 4, 2011                                         Y. Lee
                                                                 Comcast
                                                                  J. Qin
                                                                     ZTE
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                           June 02, 2011


          IPv4-IPv6 Multicast: Problem Statement and Use Cases
                  draft-jaclee-behave-v4v6-mcast-ps-02

Abstract

   This document discusses issues and requirements raised by IPv4-IPv6
   multicast interconnection and co-existence scenarios.  It also
   discusses various multicast use cases which may occur during IPv6
   transitioning.

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

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 December 4, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Jacquenet, et al.       Expires December 4, 2011                [Page 1]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


   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
   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.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Organization of the Document . . . . . . . . . . . . . . .  4
   2.  Discussion and Service Requirements  . . . . . . . . . . . . .  4
     2.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Issues Raised by the Transition Period . . . . . . . . . .  5
     2.3.  Service Requirements . . . . . . . . . . . . . . . . . . .  6
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  IPv4 Receiver and Source Connected to an IPv6-Only
           Network  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  IPv6 Receiver and Source Connected to an IPv4-Only
           Network  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  IPv6 Receiver and IPv4 Source  . . . . . . . . . . . . . .  8
     3.4.  IPv4 Receiver and IPv6 Source  . . . . . . . . . . . . . .  8
     3.5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Design Considerations  . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Group and Source Discovery Considerations  . . . . . . . .  9
     4.2.  Subscription . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Multicast Tree Computation . . . . . . . . . . . . . . . . 10
     4.4.  Multicast Interworking Functions (IWF) . . . . . . . . . . 10
       4.4.1.  IWF For Control Flows  . . . . . . . . . . . . . . . . 11
       4.4.2.  IWF For Data Flows . . . . . . . . . . . . . . . . . . 12
       4.4.3.  Address Mapping  . . . . . . . . . . . . . . . . . . . 12
     4.5.  Combination of ASM and SSM Modes . . . . . . . . . . . . . 13
   5.  What Is Expected From The IETF . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14



Jacquenet, et al.       Expires December 4, 2011                [Page 2]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


1.  Introduction

   In current deployments, the IP multicast forwarding scheme is used by
   many service providers to deliver some services, such as live TV
   broadcasting services.  Multiple players intervene in the delivery of
   these services, including content and service providers.  Service
   providers are responsible for carrying multicast flows from head-ends
   to receivers.  The content can be supplied by a service provider or
   by other providers (e.g., case of externally paid channels).

   Transition to IPv6 raises issues and corresponding requirements.  In
   particular, IPv4 service continuity is an essential requirement from
   a business perspective.  This specifically includes continued
   receiver access to IPv4-formatted contents even when the assignment
   of a dedicated global IPv4 address to the receiver is no longer
   possible and even after the receivers have migrated to IPv6.
   Likewise, the delivery of IPv6-formatted contents to IPv4 receivers
   must also be possible.

   Finally, in cases where the underlying transport network is of a
   different address family from that of the source and/or receivers,
   the delivery of multicast data must still be guaranteed.  For
   example, in DS-Lite environments, the (access) network is IPv6-
   enabled, but both multicast sources and receivers are likely to
   remain IPv4-only.

   This document does not make any assumption on the techniques used for
   the delivery of multicast traffic (e.g., native IP multicast with or
   without traffic isolation features, etc.).

   This document further elaborates on the context and discusses
   multicast-related issues and requirements.

1.1.  Goals

   The objective of this document is to clarify the problem space.  In
   particular, this document further elaborates on the following issues:

   o  What are the hurdles encountered for the delivery of multicast-
      based service offerings when both IPv4 and IPv6 co-exist?

   o  What standardization effort is needed: are there any missing
      function and protocol extensions?

   o  Does the work on multicast transition have to cover both
      encapsulation and translation schemes, considering the requirement
      of multicast network performance among others?




Jacquenet, et al.       Expires December 4, 2011                [Page 3]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


1.2.  Terminology

   This document uses the following terms:

   o  Multicast Source: Source, in short

   o  Multicast Receiver: Receiver, in short, e.g., STB (Set Top Box)

   o  Multicast Delivery Network: Network in short, covers the realm
      from Designated Routers that are directly connected to sources to
      IGMP/MLD (Internet Group Management Protocol/Multicast Listener
      Discovery) Querier devices that process IGMP/MLD signalling
      traffic exchanged with receivers.

1.3.  Organization of the Document

   This document is organized as follows:

   o  Section 2 details basic requirements that should be addressed by
      providers involved in the delivery of multicast-based services
      during the transition period,

   o  Section 3 discusses several use cases that reflect issues raised
      by the forthcoming transition period,

   o  Section 4 details design considerations,

   o  Section 5 summarizes the standardization effort that should be
      tackled by the IETF.


2.  Discussion and Service Requirements

2.1.  Scope

   Intra-domain only:   The delivery of multicast services such as live
      TV broadcasting often relies upon walled garden designs that
      restrict the scope to the domain where such services can be
      subscribed.  As a consequence, considerations about inter-domain
      multicast are out of the scope of this document.

   Multicast-enabled networks only:  This document assumes that the
      network is IP multicast-enabled.  That is, whatever the IP address
      family of the content, the latter will be multicast along
      distribution trees that should be terminated as close to the
      receivers as possible for the sake of bandwidth optimization.  In
      other words, considerations about forwarding multicast traffic
      over unicast-only (access) networks is out of the scope of this



Jacquenet, et al.       Expires December 4, 2011                [Page 4]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


      document.

   Multicast to the receivers, not from the receivers:  This document
      only covers the case where multicast traffic is forwarded by the
      service provider network to the receivers.  This document does not
      cover the case where the receivers send multicast traffic to the
      network.

2.2.  Issues Raised by the Transition Period

   Global IPv4 address depletion inevitably challenges service providers
   who must guarantee IPv4 service continuity during the forthcoming
   transition period.  In particular, access to IPv4 contents that are
   multicast to IPv4 receivers becomes an issue when the forwarding of
   multicast data assumes the use of global IPv4 addresses.

   The rarefaction of global IPv4 addresses may indeed affect the
   multicast delivery of IPv4-formatted contents to IPv4 receivers.  For
   example, the observed evolution of ADSL broadband access
   infrastructures from a service-specific, multi-PVC (Permanent Virtual
   Circuit) scheme towards a "service-agnostic", single PVC scheme,
   assumes the allocation of a globally unique IPv4 address on the WAN
   (Wide Area Network) interface of the CPE (Customer Premises
   Equipment), or to a mobile terminal), whatever the number and the
   nature of the services the customer has subscribed to.

   During the transition period, the usage of the remaining global IPv4
   address blocks will have to be rationalized for the sake of IPv4
   service continuity.  The current state-of-the-art suggests the
   introduction of NAT (Network Address Translation) capabilities
   (generally denoted as CGN, for Carrier-Grade NAT) in providers'
   networks, so that a global IPv4 address will be shared between
   several customers.  As a consequence, CPE or mobile UE (User
   Equipment) devices will no longer be assigned a dedicated global IPv4
   address anymore, and IPv4 traffic will be privately-addressed until
   it reaches one of the CGN capabilities deployed in the network.

   From a multicast delivery standpoint, this situation suggests the
   following considerations:

   o  The current design of some multicast-based services like TV
      broadcasting often relies upon the use of a private IPv4
      addressing scheme because of a walled garden approach.  Privately-
      addressed IGMP [RFC2236] [RFC3376] traffic sent by IPv4 receivers
      is generally forwarded over a specific (e.g.  "IPTV") PVC towards
      an IGMP Querier located in the access infrastructure, e.g.- in
      some deployments it is hosted by a BRAS (BRoadband Access Server)
      device that is the PPP (Point-to-Point Protocol) session endpoint



Jacquenet, et al.       Expires December 4, 2011                [Page 5]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


      and which may also act as a PIM DR (Protocol Independent Multicast
      Designated Router)[RFC4601] router.  This design does not suffer
      from global IPv4 address depletion by definition (since multicast
      traffic relies upon the use of a private IPv4 addressing scheme),
      but it is inconsistent with migrating the access infrastructure
      towards a publicly-addressed single PVC design scheme.

   o  Likewise, other deployments (e.g., cable operators' environments)
      rely upon the public CPE's address for multicast delivery and will
      therefore suffer from IPv4 address depletion.

   o  The progressive introduction of IPv6 as the only perennial
      solution to global IPv4 address depletion does not necessarily
      assume that multicast-based IPv4 services will be migrated
      accordingly.  Access to IPv4 multicast contents when no global
      IPv4 address can be assigned to a customer anymore raises several
      issues: (1) The completion of the IGMP-based multicast group
      subscription procedure, (2) The computation of the IPv4 multicast
      distribution tree, and (3) The IPv4-inferred addressing scheme to
      be used in a networking environment which will progressively
      become IPv6-enabled.

2.3.  Service Requirements

   Given the issues highlighted in Section 2.2, the delivery of
   multicast contents during the forthcoming transition period needs to
   address the following requirements.  Note that some of these
   requirements are not necessarily specific to the IPv4-to-IPv6
   transition context, but rather apply to a wide range of multicast-
   based services whatever the environmental constraints.

   But the forthcoming transition period further stresses these
   requirements (see Section 4.4.1 for more details).

   o  Service_REQ-1: Optimize bandwidth.  Contents SHOULD NOT be
      multicast twice (using both versions of IP) for the sake of
      bandwidth optimization.  Injecting multicast content using both
      IPv4 and IPv6 raises some dimensioning issues that should be
      carefully evaluated by service providers during network planning
      operations.  For instance, if only few IPv6- enabled receivers are
      in use, it can be more convenient to convey multicast traffic over
      IPv4 rather than doubling the consumed resources for few users.
      IPv4/IPv6 co-existence solutions SHOULD be designed to optimize
      network resource utilization.

   o  Service_REQ-2: Zap rapidly.  The time it takes to switch from one
      content to another MUST be as short as possible.  For example,
      zapping times between two TV channels should be in the magnitude



Jacquenet, et al.       Expires December 4, 2011                [Page 6]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


      of a few seconds at most, whatever the conditions to access the
      multicast network.  A procedure called "IGMP fast-leave" is
      sometimes used to minimize this issue so that the corresponding
      multicast stream is stopped as soon as the IGMP Leave message is
      received by the Querier.  In current deployments, IGMP fast-leave
      often assumes the activation of the IGMP Proxy function in DSLAMs.
      The complexity of such design is aggravated within a context where
      IPv4 multicast control messages are encapsulated in IPv6.

   o  Service_REQ-3: Preserve the integrity of contents.  Some contract
      agreements may prevent a service provider from altering the
      content owned by the content provider, because of copyright,
      confidentiality and SLA assurance reasons.  Multicast streams
      SHOULD be delivered without altering their content.

   o  Service_REQ-4: Preserve service quality.  Crossing a CGN or
      performing multicast packet encapsulation may lead to
      fragmentation or extra delays and may therefore impact the
      perceived quality of service.  Such degradation MUST be avoided.

   o  Service_REQ-5: Optimize IPv4-IPv6 inter-working design.  In some
      operational networks, a source-based stateful NAT function is
      sometimes used for load balancing purposes, for example.  Because
      of the operational issues raised by such a stateful design, the
      deployment of stateless IPv4-IPv6 interworking functions SHOULD be
      privileged.


3.  Use Cases

   During the forthcoming IPv4-to-IPv6 transition period, there might be
   a mix of multicast receivers, sources, and networks running in
   different address families.  However, service providers must
   guarantee the delivery of multicast services to IPv4 receivers and,
   presumably, IPv6 receivers.  Because of the inevitable combination of
   different IP version-related environments (sources, receivers and
   networks), service providers should carefully plan and choose the
   right transition technique that will optimize the network resources
   to deliver multicast-based services.

   Concretely, several use cases can be considered during the IPv4/ IPv6
   co-existence period.  Some of them are depicted in the following sub-
   sections.

3.1.  IPv4 Receiver and Source Connected to an IPv6-Only Network

   We refer to this scenario as 4-6-4.  An example of such use case is a
   DS-Lite environment, where some customers will share global IPv4



Jacquenet, et al.       Expires December 4, 2011                [Page 7]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


   addresses.  IPv4 receivers are connected to CPE devices that are
   provisioned with an IPv6 prefix only.  Delivering multicast content
   sent by an IPv4 source to such receivers requires the activation of
   some interworking functions.  Multicast traffic can be either
   encapsulated or translated.

   Given the current state-of-the-art where multicast content is likely
   to remain IPv4-formatted while receiver devices such as Set Top Boxes
   will also remain IPv4-only for quite some time, this scenario is
   prioritized by service providers, including those that are deploying
   or will deploy DS-Lite CGN capabilities for the sake of IPv4 service
   continuity.

3.2.  IPv6 Receiver and Source Connected to an IPv4-Only Network

   We refer to this scenario as 6-4-6.  According to a BEHAVE WG
   consensus when elaborating the transition unicast scenarios, servers
   are likely to remain IPv4-enabled in a first stage.  This is also
   true for multicast.  Additionally, content providers who own the
   content may not be ready for IPv6 migration for some reason.
   Therefore 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 scenario.

3.3.  IPv6 Receiver and IPv4 Source

   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
   provisioned with an IPv6 prefix.  Accessing IPv4-formatted multicast
   content from an IPv6-only receiver requires additional functions to
   be enabled.

   This scenario is privileged by mobile operators who deploy NAT64
   capabilities in their network.

3.4.  IPv4 Receiver and IPv6 Source

   We refer to this scenario as 4-6.  According to a BEHAVE WG consensus
   when elaborating the transition unicast scenarios, multicast sources
   are likely to remain IPv4-enabled in a first stage; therefore, the
   content is likely to remain IPv4-formatted.

   As a consequence, this scenario is 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 and 3.3.





Jacquenet, et al.       Expires December 4, 2011                [Page 8]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


3.5.  Summary

   The following table summarizes the use cases:



                       +------------------+------------+
                       |    Use Cases     |  Priority  |
                       +------------------+------------+
                       | R4, S4 over IPv6 |    High    |
                       +------------------+------------+
                       |      R6, S4      |    High    |
                       +------------------+------------+
                       | R6, S6 over IPv4 |    Low     |
                       +-------------------------------+
                       |      R4, S6      |    Low     |
                       +------------------+------------+

              Figure 1: Multicast Transition Use Case Summary


4.  Design Considerations

4.1.  Group and Source Discovery Considerations

   Multicast applications that embed address information in the payload
   may require Application Level Gateway (ALG) during the transition
   period.  An ALG is application-specific by definition, and may
   therefore be unnecessary depending on the nature of the multicast
   service.

   Such ALG (Application Level Gateway) may also be required to help an
   IPv6 receiver select the appropriate multicast group address when
   only the IPv4 address is advertised (e.g., when the SDP (Session
   Description Protocol) protocol is used to advertise some contents);
   otherwise, access to IPv4 multicast content from an IPv6 receiver may
   be compromised.

   ALGs may be located upstream in the network.  As a consequence, these
   ALGs do not know in advance whether the receiver is dual-stack or
   IPv6-only.  In order to avoid the use of an ALG in the path, an IPv4-
   only source can advertise both an IPv4 multicast group address and
   the corresponding IPv4-embedded IPv6 multicast group address [I-D.
   boucadair-behave-64-multicast-address-format].

   However, a dual-stack receiver may prefer to use the IPv6 address to
   receive the multicast content.  The selection of the IPv6 multicast
   address would then require multicast flows to cross an IPv4-IPv6



Jacquenet, et al.       Expires December 4, 2011                [Page 9]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


   interworking function.

   The receiver should therefore be able to unambiguously distinguish an
   IPv4-embedded IPv6 multicast address from a native IPv6 multicast
   address.

4.2.  Subscription

   Multicast distribution trees are receiver-initiated.  IPv4 receivers
   that wish to subscribe to an IPv4 multicast group will send the
   corresponding IGMP Report message towards the relevant IGMP Querier.
   In case the underlying access network is IPv6, the information
   conveyed in IGMP messages should be relayed by corresponding MLD
   messages.

4.3.  Multicast Tree Computation

   Grafting to an IPv4 multicast distribution tree through an IPv6
   multicast domain suggests that IPv4 multicast traffic will have to be
   conveyed along an "IPv6-equivalent" multicast distribution tree.
   That is, part of the multicast distribution tree along which IPv4
   multicast traffic will be forwarded SHOULD be computed and maintained
   by means of the PIMv6 machinery, so that the distribution tree can be
   terminated as close to the IPv4 receivers as possible for the sake of
   the multicast forwarding efficiency.  This assumes a close
   interaction between the PIM designs enforced in both IPv4 and IPv6
   multicast domains, by means of specific Inter-Working Functions that
   are further discussed in Section 4.4.

   Such interaction may be complicated by different combinations: the
   IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point)
   routers), while the IPv6 multicast domain may support both ASM (Any
   Source Multicast) and SSM (Source Specific Multicast) [RFC3569]
   modes.

4.4.  Multicast Interworking Functions (IWF)

   IPv4-IPv6 multicast interworking functions are required for both
   translation (one address family to another) and traversal (one
   address family over another) contexts.

   Given the multiple versions of Group Membership management protocols,
   issues may be raised when, for example, IGMPv2 is running in the IPv4
   multicast domain that is connected to the IPv6 multicast domain by
   means of an IWF, while MLDv2 is running in the IPv6 multicast domain.
   To solve these problems, the design of the IWF function SHOULD adhere
   to the IP version-independent, protocol interaction approach
   documented in Section 8 of [RFC3810] and Section 7 of [RFC3376].



Jacquenet, et al.       Expires December 4, 2011               [Page 10]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


   Note that, for traversal cases, to improve the efficiency of the
   multicast service delivery, traffic will be multicast along
   distribution trees that should be terminated as close to the
   receivers as possible for the sake of bandwidth optimization.  As a
   reminder, the traversal of unicast-only (access) networks is not
   considered in this draft.

4.4.1.  IWF For Control Flows

   The IWF to process multicast signalling flows (such as IGMP or MLD
   Report messages) should be independent of the IP version and consist
   mainly of an IPv4-IPv6 adaptation element and an IP address
   translation element.  The message format adaptation must follow what
   is specified in [RFC3810] or [RFC4601], and the device that embeds
   the IWF device must be multicast-enabled, i.e., support IGMP, MLD
   and/or PIM, depending on the context (address family-wise) and the
   design (e.g., this device could be a PIM DR in addition to a MLD
   Querier).

   The IWF can then be operated in the following modes: IGMP-MLD, PIMv4-
   PIMv6, MLD-PIMv4 and IGMP-PIMv6.  In particular, Source-Specific
   Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 signalling
   traffic as well as the ability to directly send PIM (S, G) Join
   messages towards the source).

   The following sub-sections describe some interworking functions which
   may be solicited, depending on the environment.

4.4.1.1.  IGMP-MLD Interworking

   The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying
   function specified in [RFC4605] and the IGMP/MLD adaptation function
   which is meant to reflect the contents of IGMP messages into MLD
   messages, and vice versa.

   For example, when an IGMP Report message is received to subscribe to
   a given multicast group (which may be associated to a source address
   if SSM mode is used), the IGMP-MLD Interworking Function MUST send an
   MLD Report message to subscribe to the corresponding IPv6 multicast
   group.

4.4.1.2.  IPv4-IPv6 PIM Interworking

   [RFC4601] allows the computation of PIM-based IPv4 or IPv6
   distribution trees; PIM is IP version agnostic.  There is no specific
   IPv6 PIM machinery that would work differently than an IPv4 PIM
   machinery.  The new features needed for the IPv4-IPv6 PIM
   Interworking Function consist in dynamically triggering the PIM



Jacquenet, et al.       Expires December 4, 2011               [Page 11]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


   message of Address Family 1 upon receipt of the equivalent PIM
   message of Address Family 2.

   The address mapping MUST be performed similarly to that of the IGMP-
   MLD Interworking Function.

4.4.1.3.  MLD-IPv4 PIM Interworking

   This IWF function is required when the MLD Querier is connected to an
   IPv4 PIM domain.

   The address mapping MUST be performed similarly to that of the IGMP-
   MLD Interworking Function.

4.4.1.4.  IGMP-IPv6 PIM Interworking

   The address mapping MUST be performed similarly to that of the IGMP-
   MLD Interworking Function.

4.4.2.  IWF For Data Flows

   The IWF to be used for multicast data flows is operated at the
   boundary between IPv4 and IPv6 multicast networks.  Either
   encapsulation/de-capsulation or translation modes can be enforced,
   depending on the design.  Note that translation operations must
   follow the algorithm specified in [RFC6145].

4.4.3.  Address Mapping

   The address mapping mechanisms to be used in either a stateful or
   stateless fashion need to be specified for the translation from one
   address family to the other.

   The address formats have been defined in [I-D.boucadair-behave-64-
   multicast-address-format] and [RFC6052] for IPv4-embedded IPv6
   multicast and unicast addresses.  Mapping operations are performed in
   a stateless manner by the algorithms specified in the aforementioned
   documents.

   In this context, the IPv6 prefixes required for embedding IPv4
   addresses can be assigned to devices that support IWF features by
   various means (e.g., static or dynamic configuration, out-of-band
   mechanisms, etc.).

   If stateful approaches are used, it is recommended to carefully
   investigate the need to synchronize mapping states between multiple
   boxes, and the coordination of the IWF and source/group discovery
   elements is also required, at the cost of extra complexity.



Jacquenet, et al.       Expires December 4, 2011               [Page 12]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


4.5.  Combination of ASM and SSM Modes

   The ASM (Any Source Multicast) mode could be used to optimize the
   forwarding of IPv4 multicast traffic sent by different sources into
   the IPv6 multicast domain by selecting RP routers that could be
   located at the border between the IPv6 and the IPv4 multicast
   domains.  This design may optimize the multicast forwarding
   efficiency in the IPv6 domain when access to several IPv4 multicast
   sources needs to be granted.

   [To be further elaborated.]


5.  What Is Expected From The IETF

   This document highlights the following IETF standardization needs:

   o  Specify the inter-working function as described in Sections 4.4.1
      and 4.4.2.  In particular:

      *  Specify the algorithms used by various inter-working functions,
         covering both encapsulation and translation approaches

      *  Specify the multicast IPv4-embedded address format

      *  Document a multicast 6-4 (that is, the R6-S4 use case of Figure
         1) architecture

      *  Document a 4-6-4 (that is, the R4-S4 over IPv6 use case of
         Figure 1) multicast architecture

   o  Document a Management Information Base (MIB) to be used for the
      management of IWF functions

   o  Encourage the publication of various Applicability Statement
      documents to reflect IWF operational experience in different
      contexts


6.  IANA Considerations

   This document makes no request to IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.






Jacquenet, et al.       Expires December 4, 2011               [Page 13]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


7.  Security Considerations

   Access to contents in a multicast-enabled environment raises
   different security issues that have been already documented.  This
   draft does not introduce any specific security issue.


8.  Acknowledgments

   Thanks to N. Leymann, T. Taylor and S. Venaas for their comments.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, July 2003.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

9.2.  Informative References

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.


Authors' Addresses

   Christian Jacquenet
   France Telecom

   Email: christian.jacquenet@orange-ftgroup.com




Jacquenet, et al.       Expires December 4, 2011               [Page 14]


Internet-Draft   IPv4-IPv6 Multicast: Problem Statement        June 2011


   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Yiu Lee
   Comcast
   US

   Email: Yiu_Lee@Cable.Comcast.com


   Jacni Qin
   ZTE
   China

   Email: jacniq@gmail.com


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tena@huawei.com





















Jacquenet, et al.       Expires December 4, 2011               [Page 15]