<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2974 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml">
<!ENTITY RFC3376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="info" docName="draft-eubanks-mboned-transition-overview-04" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
     pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>Multicast Transition Overview</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

  <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
    <organization>Keio University</organization>
    <address>
      <postal>
        <street>Graduate School of Media and Governance</street>
        <street>5322 Endo</street>
        <city>Fujisawa</city> <region>Kanagawa</region>
        <code>252-0882</code>
        <country>Japan</country>
      </postal>
      <email>asaeda@wide.ad.jp</email>
      <uri>http://www.sfc.wide.ad.jp/~asaeda/</uri>
    </address>
  </author>

  <author initials="M." surname="Eubanks" fullname="Marshall Eubanks">
    <organization>AmericaFree.TV</organization>
    <address>
      <postal>
        <street>P.O. Box 141</street>
        <city>Clifton</city>
        <region>VA</region>
        <code>20124</code>
        <country>USA</country>
      </postal>
      <phone></phone>
      <email>marshall.eubanks@gmail.com</email>
    </address>
  </author>

    <author fullname="Tina Tsou" initials="T." surname="Tsou">
      <organization>Huawei Technologies (USA)</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>USA</country>
        </postal>
        <phone>+1 408 330 4424</phone>
        <email>Tina.Tsou.Zouting@huawei.com</email>
      </address>
    </author>

  <author initials="S." surname="Venaas" fullname="Stig Venaas">
    <organization>Cisco Systems</organization>
    <address>
      <postal>
        <street>Tasman Drive</street>
        <city>San Jose</city>
        <region>CA</region>
        <code>95134</code>
        <country>USA</country>
      </postal>
      <phone></phone>
      <email>stig@cisco.com</email>
    </address>
  </author>

    <date year="2012" />

    <!-- If the month and year are both specified and are the current ones,
    xml2rfc will fill in the current day for you. If only the current year is
    specified, xml2rfc will fill in the current day and month for you. If the
    year is not the current one, it is necessary to specify at least a month
    (xml2rfc assumes day="1" if not specified for the purpose of calculating
    the expiry date).  With drafts it is normally sufficient to specify just
    the year. -->

    <!-- Meta-data Declarations -->

    <area>Operations and Administration</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
   If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <abstract>
      <t> IPTV providers must serve content to their customers during the period
      of transition from IPv4 to IPv6. During this period, the content provider
      may support only one version of IP while the customer&apos;s receiver device 
      supports only the
      other. Likewise, the network between the provider and its customer may
      include segments supporting only one version of IP or another. </t>
      
      <t>This document provides an overview of the multicast transition problem.
      It also provides an overview of the solution space. The solution space is
      characterized by an adaptation function (AF) that provides an interface 
      between IPv4 and IPv6 multicast domains. This
   document also discusses various multicast use cases which may occur
   during IPv6 transitioning.  These use cases motivate the solution
   space discussion and the requirements that appear at the end.
</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>IPTV providers must serve content to their customers during the period
      of transition from IPv4 to IPv6. During this period, the content provider
      may support only one version of IP while the customer supports only the
      other. Likewise, the network between the provider and its customer may 
      include segments supporting only one version of IP or another. </t>
      
      <t>In current deployments, the IP multicast forwarding scheme is used by
   many service providers to deliver services such as live TV
   broadcasting.  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).
    </t>
    
    <t>   Unlike the situation for unicast addresses, the IPv4 multicast address
space seems sufficient for most proposed uses.  Hence the key motivation for the work
   described here is to preserve the efficiencies of multicast
   distribution of content (i.e., by reducing total traffic on the
   network and minimizing the distance that multicast streams must
   travel) when both IPv4 and IPv6 segments lie on the path from source
   to receiver.
    </t>
      
      <t>This document provides an overview of the multicast transition problem.
      It also provides an overview of the solution space. The solution space is
      characterized by an adaptation function (AF) that provides an interface 
      between IPv4 and IPv6 multicast segments.  The
   scope of this document is currently limited to IP transport, and covers both single
   operator and inter-operator flows.
    </t> 

      <t>Section 2 describes the problem space in detail. This section describes
      an environment that includes a content provider, a customer, and an
      intervening network. Any component of that environment may support only
      one version of IP or the other. At points where IPv4-only devices lie on
      one side and IPv6-only devices on the other, an adaptation function is
      required.</t>
      
      <t>Section 3 proposes a framework for the solution.
      Section 4 defines formal requirements for any proposed solution.</t>

    </section>

    <section anchor="probs" title="A Look At the Multicast Transition Problem Space">
   
       <t>Historically, IPTV providers have served IPv4 content to receivers 
       over IPv4 multicast networks. CPE has thus until recently 
       supported IPv4 only. As the Internet
       transitions to IPv6, IPv6-capable equipment will be deployed by content
       providers and receivers, as well as the networks that connect them to one
       another. So long as all of the newly deployed gear supports both IPv4 and
       IPv6, the transition to IPv6 may not require new IETF protocol 
       specifications in support of multicast deployment. In this case of dual-stack environments, either 
       IP address family can be used end to end for the multicast traffic. However, if some of the newly 
       deployed gear supports IPv6
       only, incompatibilities will be introduced. These IPv6-only scenarios are being planned and deployed because the exhaustion of IPv4 unicast address space. Instead of running large NAT and IPv6 all together, some providers prefer to run a single address family that is future proof, which is IPv6. This also brings simpler management of the network. In this unicast case, IPv4 traffic can be either tunneled over IPv6 (e.g. softwire, dslite, 4rd)  or translated (NAT64). Therefore, some access networks are IPv6 only. </t>
       
       <t>An incompatibility occurs at a device lying along the path between the
       source and the receiver when the next device on the path on one side of 
       it supports a different version of IP from the next device on the path on
       the other side of it (i.e., one device supports IPv4 only and the other 
       supports IPv6 only). For the purposes of this document, we will call these
       points of incompatibility "IP version transition points". The communication
       path between source and receiver (which includes both endpoints) can
       include zero or more IP version transition points. </t>
       
       <t>IP version transition points may be introduced at any point along the path.
       These IP version transition points may reside in the subscriber premises, at the
       CPE, in the intervening network etc. In addition, the Set Top Box (STB)
       and Electronic Program Guides (EPG) may have different IP versions. </t>
       
       <t>In order to maintain multicast connectivity, one or more adaptation
       functions (AF) are required. 
       The AF operates in both
       the forwarding and control planes. Because it provides an interface
       between the IPv4 and IPv6 domain, it must be both IPv4-capable and 
       IPv6-capable. </t>
       
       <t>In most cases, the adaptation function will mediate between IPv4
       and IPv6 on both the control and forwarding planes. However, in scenarios
       where the path between source and receiver contains multiple IP version
       transition points, adaptation function instances may tunnel traffic between one
       another. </t>
       
       <section anchor="signal_channels" title="Signaling Channels using Multicast Addresses">
<t>The receiver is provided the necessary multicast addresses for channel reception by some means such as 
an Electronic Program Guide (EPG). If the source uses the same address family as the receiver, the receiver will subscribe to a multicast address of the appropriate address family. However, If the source uses the other address family, then the signaling must be translated in the path (or at the program guide). </t>
<t>An early assessment of the market seems to suggest that most signaling is done with proprietary protocols, and that most EPG are also
proprietary. It remains to be seen if a standardized solution for this issue a need or even a possibility, given these market realities.</t>
       </section>
       
         <section anchor="operatorview" title="Operator View of Use Cases">
         
            <t>
            Discussion with operators has indicated in the first place that the
   distribution of Electronic Program Guide material is done by
   proprietary means, and they have no interest in a standardized
   solution.  SSM (Specific Source Multicast) is the technically
   preferable mode of operation.  However, some operators may have to
   use ASM (Any Source Multicast) because of the limitations of existing
   receivers (i.e., limitations on the support of IGMP v3 or MLD v2).
            </t>
            
            <t>
               In what follows, this document uses the following numeric convention
   to specify a particular scenario:
     &lt;receiver version&gt;&ndash;&lt;network version(s)&gt;&ndash;&lt;source version&gt;
   (e.g., 6&ndash;4&ndash;6&ndash;4 for the second scenario described below).
            </t>
            
            <t>
            For a number of operators, the expected evolution path is to first
   upgrade the network to IPv6, then upgrade the receivers to IPv6
   through a gradual process of replacement, and then add IPv6 sources
   when a critical mass of IPv6 receivers is reached.  This sequence
   implies that the immediate priority is to support the 4&ndash;6&ndash;4 scenario
   shown in Figure 1.  One can immediately see that two instances of the
   AF are needed, one at each side of the IPv6 network.  The receiver
   signals using IGMP.  The AF translates the IGMP either to MLD
   <xref target="RFC3810"/> or to PIM <xref target="RFC4601"/> running on IPv6.  At the other side,
   the AF most likely interworks between PIM with IPv6 and PIM with
   IPv4.  In the reverse direction, multicast data packets can either be
   translated or tunneled between the AF instances, as noted above.
            </t>
            <figure anchor="figure_1" title="An Initial Scenario: IPv4 Source and Receiver Via an IPv6
                                  Network">
            <artwork>
   +------+      +-----+       +----+       +------+      +-----+
   | Host |      | DS  |       |    |       |  MR  |      |     |
   | Rcvr |------| AF  |       | MR | . . . |      |------| Src |
   |      | IPv4 |     |       |    | IPv4  | (DR) | IPv4 |     |
   +------+      +-----+       +----+       +------+      +-----+
                  /               \
                 / IPv6            \ IPv4
                /                   \
           +----+      +----+       +------+
           |    |      |    |       |  DS  |
           | MR |------| MR | . . . |  AF  |
           |    | IPv6 |    | IPv6  |      |
           +----+      +----+       +------+
           
    Rcvr: Multicast receiver
    DS  : Dual Stack
    AF  : Adaptation Function
    MR  : Multicast router
    DR  : Designated Router
    Src : Multicast source
            </artwork>
            </figure>
            
            
        <t>
           An alternative view of network evolution contemplates a more
   immediate rollout of IPv6 receivers, but a slow evolution of sources
   from IPv4 to IPv6.  The backbone network will be IPv6 in all cases,
   but the metro network may be either IPv4 or IPv6.  The first case
   (6&ndash;4&ndash;6&ndash;4), with an IPv4 metro network, is shown in Figure 2.  Three
   AF instances are needed, at the IP version transition points between
   the source and backbone network, between the backbone and metro
   network, and between the metro network and the receiver.
        </t>
            <figure anchor="figure_2" title="Initial Scenario With IPv6 Host, IPv4 Source, and Both IPv4
                       and IPv6 Intervening Networks">
            <artwork>
               
   +------+      +-----+      +----+      +------+
   | Host |      | DS  |      |    |      |  DS  |
   | Rcvr |------| AF  |------| MR | . . .|  AF  |
   |      | IPv6 |     | IPv4 |    | IPv4 |      |
   +------+      +-----+      +----+      +------+
                                             /
                 ----------------------------
                /         IPv6
           +----+      +----+       +------+
           |    |      |    |       |  DS  |
           | MR |------| MR | . . . |  AF  |
           |    | IPv6 |    | IPv6  |      |
           +----+      +----+       +------+
                                       /
              -------------------------
             /        IPv4
            +----+         +------+      +-----+
            |    |         |  MR  |      |     |
            | MR | . . . . |      |------| Src |
            |    |   IPv4  | (DR) | IPv4 |     |
            +----+         +------+      +-----+

   Rcvr: Multicast receiver
   Src : Multicast source
   DS  : Dual Stack
   AF  : Adaptation function
   MR  : Multicast Router
   DR  : Designated Router
            </artwork>
            </figure>

    <t>
     The case where the metro network has evolved to IPv6 (6&ndash;6&ndash;4) is shown
   in Figure 3.  Here, only one AF instance is needed.  It translates
   between  IPv6 PIM  in the receiver network and  IPv4 PIM
   in the content provider network.
    </t>
    
            <figure anchor="figure_3" title="Initial Scenario With IPv6 Host, IPv4 Source, and IPv6
                            Intervening Network">
            <artwork>
   +------+      +-----+      +----+      +------+
   | Host |      | MR  |      |    |      |  DS  |
   | Rcvr |------|     |------| MR | . . .|  AF  |
   |      | IPv6 |(DR) | IPv6 |    | IPv6 |      |
   +------+      +-----+      +----+      +------+
                                             /
                    -------------------------
                   /        IPv4
                  +----+         +------+      +-----+
                  |    |         |  MR  |      |     |
                  | MR | . . . . |      |------| Src |
                  |    |   IPv4  | (DR) | IPv4 |     |
                  +----+         +------+      +-----+

   Rcvr: Multicast receiver
   Src : Multicast source
   DS  : Dual Stack
   AF  : Adaptation function
   MR  : Multicast Router
   DR  : Designated Router
            </artwork>
            </figure>

        
        </section>
        <section anchor="usecases" title="Requirements From The Use Cases">
        
        <t>
           All three of the immediately relevant scenarios just described
   feature IPv4 sources.  This means that no solution is required in the
   short term for translation from general IPv6 addresses to IPv4
   addresses.  In the longer run operators may have the situation of
   IPv6 sources serving receivers that have remained at IPv4.
   That presents a more difficult translation problem, but the scenario
   has low priority.
        </t>
        
        <t>
          The three cases illustrate a number of protocol interworking
   combinations.  As indicated below, some combinations can act as a
   part of others, reducing the total development effort.
        </t>
        
        <t>
          In summary, the use cases expose the following gaps for which there
   are no existing IETF standards:
 
                <list style='symbols'>
                <t>Translating from IPv4 to IPv6 multicast addresses and back again.
                </t>
                <t>
                Translating from IGMP downstream to MLD upstream (4&ndash;6&ndash;4 case) and
      from MLD downstream to IGMP upstream (6&ndash;4&ndash;6&ndash;4 case).
                </t>
                
                <t>
                 Interworking between IGMP and PIM with IPv6 (4&ndash;6&ndash;4 case).  This
      could be synthesized by translating the IGMP to MLD and having MLD
      interwork with PIM as usual.
                </t>
            
                <t>
                Interworking between MLD and PIM with IPv4 (6&ndash;4&ndash;6&ndash;4 case).  Again,
      this could be synthesized, by translating MLD to IGMP and
      interworking the latter to PIM as usual.
                </t>
                
                <t>
                    Operating PIM with IPv4 downstream and IPv6 upstream (6&ndash;4&ndash;6&ndash;4
      case) and with IPv6 downstream and IPv4 upstream (4&ndash;6&ndash;4 and 6&ndash;6&ndash;4
      cases).         
                </t>
 
            </list>
        </t>
        
        </section>


    </section><!-- probs -->
    
    
    <section anchor="solns" title="A Look At the Solution Space For Multicast Transition">
   
 			<t>The AF operates on both the forwarding and control planes. On the 
 			forwarding plane, the AF inserts itself into the forwarding path translating
 			multicast packets from one IP version to the other. On the control plane, 
 			the AF receives routing and signaling messages of one protocol and sends 
 			out routing and signaling messages of another protocol.[Forward reference to 
            future high-level description of the AF.]
            </t>
 			
 		  <section anchor="fwdPlane" title="AF Forwarding Plane Operation">
 		
 			  <t>The AF accepts packets from one IP version, removes the IP header,
 			  and replaces it with an IP Header of the other version. A significant 
 			  portion of that task is address translation. Ideally the address translation 
 		  	  strategy used by an AF should be algorithmic, stateless and reversible. This
			  should be simple when addresses from one IP version can simply be embedded
			  into another (IPv4 into IPv6), but this may not be possible in the opposite
			  direction. That the translation is reversible means that there is a stateless
			  algorithm for translating back into the original address.</t>
 			
 			  <t><xref target="RFC6052"/> provides an algorithm for translating unicast
 			  addresses between IPv4 and IPv6. Likewise 
 			  <xref target="I-D.mboned-64-mcast-addr-fmt"/> provides an algorithm for 
 			  multicast address conversion between IPv4 and IPv6. Note that using this
			  algorithm, different translators could choose different IPv6 prefixes for
			  embedding the IPv4 addresses. But the format allows for stateless
			  translation back to the original IPv4 addresses.</t> 			

 			  <t>Other issues associated with IP version translation may arise (e.g.,
 			  fragmentation and checksums and will be
			  resolved as appropriate in conjunction with appropriate IETF working groups.</t>
 		
 		  </section>
 		  
 		  
 		  <section anchor="ctlPlane" title="AF Control Plane Operation">
 		 
 		 	  <t>On the control plane, the AF mediates between:
 		 	  <list style="symbols">
 		 	    <t>IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/>;</t>
 		 	    <t>PIM(v4) <xref target="RFC4601"/> and PIM(v6);</t>
 		 	    <t>IGMPv3 and PIM(v6);</t>
 		 	    <t>MLD and PIM(v4);</t>
 		 	  </list>
 		 	  </t>
 		 	  
 		 	  <t>The IGMP-to-MLD translation may be configured to use only IGMPv2 
 		 	  features. It is defined in [draft to come].
              <xref target="I-D.perreault-mboned-igmp-mld-translation"/> 
is a candidate for
             this specification.
              </t>
 		 	  
 		 	  <t>The PIM-to-PIM mediation operates between PIM protocol operations of
			  one IP version with operations of the other version. 
              <xref target="I-D.taylor-pim-v4v6-translation"/> 
is a candidate for
             this specification.
              </t>
 		 
 		  </section>
 		 
 		  
 		  <section anchor="discover" title="Source Discovery">
 		 
 		 	  <t>
              Source discovery is out of scope and is left for further study. 
               <xref target="I-D.tsou-mboned-multrans-addr-acquisition"/> 
   provides an informative discussion of the options open to operators.
              </t>
 		 
 		  </section>
 		  
 		  
 		  <section anchor="pathOpt" title="Transitional Multicast Path Optimization">
 		 
 		 	  <t>A mechanism to optimize the path to the multicast source for a 
 		 	  combination of IPv4 and IPv6 networks is not immediately required, but
 		 	  is a topic for future work. <xref target="I-D.zhou-mboned-multrans-path-optimization"/> 
              is a candidate for this specification.
               </t>
 		 
 		  </section>
 		 
    </section><!-- solns -->    
    
    
   
   
    <section anchor="Contributors" title="Contributors">
    
      <t>Some of the introductory text of this document was drawn from
   <xref target="I-D.jaclee-behave-v4v6-mcast-ps"/>.  Figures from Section 3 of that document were
   the starting point for the figures in Section 2.1 of this document.
   The strong participation of the authors of <xref target="I-D.jaclee-behave-v4v6-mcast-ps"/> in
   the work on multicast transition leading up to the creation of this
   document must be acknowledged.  These authors include two co-authors
   of the present document, plus Mohamed Boucadair, Yiu Lee, Hitoshi 
   Asaeda, and Jacni Qin, who should be considered honorary co-authors.</t>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
    
      <t>Ron Bonica inspired the writing of this memo and shaped its content.
      Michael McBride and Marc Blanchet provided useful comments on intermediate versions of
      this document. </t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
    
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
    
      <t>To come.</t>
      
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Informative References">
    
      &RFC3376;
      &RFC3810;
      &RFC4601;
      &RFC6052;
      
			<reference anchor="I-D.mboned-64-mcast-addr-fmt">
				<front>
          <title>IPv4-Embedded IPv6 Multicast Address Format (Work in Progress)</title>
          <author initials="M." surname="Boucadair" fullname="M. Boucadair">
            <organization>France Telecom</organization>
          </author>
          <author initials="J." surname="Qin" fullname="J. Qin">
            <organization>ZTE</organization>
          </author>
          <author initials="Y." surname="Lee" fullname="Y. Lee">
            <organization>Comcast</organization>
          </author>
          <author initials="S." surname="Venaas" fullname="S. Venaas">
            <organization>Cisco Systems</organization>
          </author>
          <author initials="X." surname="Li" fullname="X. Li">
            <organization>CERNET Center/Tsinghua University</organization>
          </author>
          <author initials="M." surname="Xu" fullname="M. Xu">
            <organization>Tsinghua University</organization>
          </author>
          <date month="March" year="2012"/>
        </front>
			</reference>

      
      <?rfc include="reference.I-D.jaclee-behave-v4v6-mcast-ps.xml"?>
      <?rfc include="reference.I-D.draft-perreault-mboned-igmp-mld-translation-00.xml"?>  
      
       <?rfc include="reference.I-D.draft-taylor-pim-v4v6-translation-00.xml"?>
      <?rfc include="reference.I-D.tsou-mboned-multrans-addr-acquisition.xml"?>
       <?rfc include="reference.I-D.zhou-mboned-multrans-path-optimization.xml"?>
   
    </references>

  </back>
</rfc>
