<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<rfc category="std" ipr="trust200902"
     docName="draft-venaas-behave-mcast46-02.txt">

  <front>
    <title>An IPv4 - IPv6 multicast translator</title>
    <author initials='S.' surname='Venaas' fullname='Stig Venaas'>
      <organization>UNINETT</organization>
      <address>
        <postal>
          <city>Trondheim</city>
          <code>NO-7465</code>
          <country>Norway</country>
        </postal>
        <email>venaas@uninett.no</email>
      </address>
    </author>
    <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, Kanagawa</city>
          <code>252-8520</code>
          <country>Japan</country>
        </postal>
        <email>asaeda@wide.ad.jp</email>
      </address>
    </author>
    <author initials='S.' surname='SUZUKI' fullname='Shinsuke SUZUKI'>
      <organization>ALAXALA Networks Corporation</organization>
      <address>
        <postal>
          <street>Shinkawasaki Mitsui Bldg.</street>
          <street>890 Kashimada</street>
          <city>Saiwai-ku, Kawasaki, Kanagawa</city>
          <code>212-0058</code>
          <country>Japan</country>
        </postal>
        <email>suz@alaxala.net</email>
      </address>
    </author>
    <author initials='T.' surname='Fujisaki' fullname='Tomohiro Fujisaki'>
      <organization>NTT PF Lab</organization>
      <address>
        <postal>
          <street>3-9-11 Midori-Cho</street>
          <city>Musashino-shi, Tokyo</city>
          <code>180-8585</code>
          <country>Japan</country>
        </postal>
        <email>fujisaki@nttv6.net</email>
      </address>
    </author>

    <date/>
    <abstract><t>This document describes an IPv4 - IPv6 translator device
that embeds
all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts
to receive from and send to any IPv4 multicast group. 
This mechanism can be also used to allow IPv4 hosts to receive from and
send to a subset of the IPv6 multicast groups.
    </t></abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="intro">
<t>IPv4 and IPv6 will co-exist for many years, possibly decades. There
are several solutions for how IPv4 and IPv6 hosts and networks can
inter-operate. This is usually easy if a host is dual-stack. If
however an IPv6-only host needs to communicate with an IPv4-only
host, then somewhere along the data path there must be some form of
translation. There are several ways of doing this for unicast, but
not much work has been done on multicast.
</t><t>
Here we describe a multicast translator solution. This translator
could be placed at the border between IPv6-only and IPv4-only
networks to allow multicast access between them, or it may also be
placed in a dual-stack network, where it can support hosts or other
networks that are IPv6-only or IPv4-only. The goal is to give
an IPv6 host full access to send to and receive from any IPv4
multicast group by using the usual IPv6 multicast protocols and
applications which will then operate on the respective IPv6 groups.
It should also allow this for multiple hosts. Multiple IPv4 hosts
should be able to use a single IPv4 group, multiple IPv6 hosts a
corresponding IPv6 group, and all hosts should be able to send to
and receive from all the others. Similar to hosts using the same
group from the same address family.
The translator solution should work with no changes to other
infrastructure.
</t><t>
We will define a one-to-one mapping of multicast IPv4 addresses
onto a subset of the IPv6 multicast addresses. An IPv6 host will
then be able to receive data from any IPv4 multicast group by joining the
corresponding IPv6 group. An IPv6 host can also send, without
necessarily joining, to any IPv4 multicast group by sending to the
corresponding IPv6 group. Some way of translating unicast addresses
is also needed to translate addresses of multicast sources.
</t><t>
The one-to-one mapping also allows an IPv4 host access to send to and
receive from the mapped IPv6 multicast groups.
</t>
    </section>
    <section title="Terminology" anchor="terms">
<t>
"IPV6_TRASM_ADDRESS" is an IPv6 ASM multicast address translated by
IPv4-IPv6 multicast translator. IPV6_TRASM_ADDRESS is one of the
addresss in one specific /96 IPv6 ASM (non-SSM) prefix
("IPV6_TRASM_ADDRESS prefix"). Since this document assumes the
translator acts as an RP in IPv6 ASM, this prefix may be used
with embedded-RP and be included in FF70::/12 <xref target="RFC3956"/>.
</t><t>
"IPV6_TRSSM_ADDRESS" is an IPv6 SSM multicast address translated by
IPv4-IPv6 multicast translator. IPV6_TRSSM_ADDRESS is one of the
addresss in one specific /96 IPv6 SSM prefix ("IPV6_TRSSM_ADDRESS
prefix"). This prefix will be included in FF3x:0::/32 <xref target="RFC4607"/>.
</t><t>
"IPV4_SSM_ADDRESS" is an IPv4 SSM multicast address.
IPV4_SSM_ADDRESS is one of the addresses from the IPv4 SSM address
232/8 <xref target="RFC4607"/>.
</t><t>
"IPV4_ASM_ADDRESS" is an IPv4 ASM multicast address translated by
IPv4-IPv6 multicast translator. It can in principle be any IPv4
multicast address outside the SSM range 232/8.
</t><t>
A multicast translator attaches both IPv6-only and IPv4-only
networks with two different interfaces. In this document, each
interface is named "IF6" and "IF4".
</t>
    </section>
    <section title="Abbreviations" anchor="abbr">
<t>
  <figure>
    <artwork><![CDATA[
ASM     Any Source Multicast
DR      Designated Router
IGMP    Internet Group Management Protocol
MLD     Multicast Listener Discovery
MSDP    Multicast Source Discovery Protocol
PIM-SM  Protocol Independent Multicast - Sparse Mode
RP      Rendezvous Point
RPF     Reverse Path Forwarding
SSM     Source-Specific Multicast
    ]]>
    </artwork>
  </figure>
</t>
    </section>
    <section title="Architecture" anchor="arch">
<t>
  <figure>
    <artwork><![CDATA[
                        PIM/MLD          PIM/IGMP
      ***  ***  ***  *** join +----------+ join ***  ***  ***  ***
     *   **   **   **   ----->|    tr    |----->   **   **   **   *
    *        IPv6       <=====|    an    |======       IPv4        *
     *       only        data |IF6 sl IF4| data        only       *
    *       network     =====>|    at    |=====>      network      *
     *   **   **   **   <-----|    or    |<----   **   **   **   *
      ***  ***  ***  **PIM/MLD+----------+PIM/IGMP  ***  ***  ***
                         join              join
    ]]>
    </artwork>
  </figure>
</t><t>
We propose that the translator makes use of PIM-SM (Sparse Mode)
<xref target="RFC4601"/> for IPv6. For ASM it should then be the
RP for the /96 IPv6 prefix used for ASM, "IPV6_TRASM_ADDRESS prefix".
This allows the translator
to know which IPv4 groups the IPv6 hosts join, and also to learn of
IPv6 sources for those groups. It is sufficient to support MLD
if there are no IPv6 PIM neighbors (e.g. a single link or MLD
proxies <xref target="RFC4605"/>).
</t><t>
When the translator receives a PIM or MLD join for an IPv6 group in
"IPV6_TRASM_ADDRESS prefix" on IF6, it will need to join the corresponding
IPv4 multicast group on IF4. It may behave as an IPv4 host and send
an IGMP join for the correspondig IPv4 group, or it might be an IPv4
PIM router and send an IPv4 PIM join.
</t><t>
If the translator learns of an IPv6 source for an
"IPV6_TRASM_ADDRESS" it needs to receive the data on IF6, and send
the translated data out on IF4. If the translator is an IPv6 RP,
it may receive IPv6 PIM. As a regular IPv6 RP, it may then join
towards the source to receive packets natively on IF6. It may also
be a directly connected source or a source behind an MLD proxy
<xref target="RFC4605"/>, in
that case packets are also received on IF6. If the translator behaves
as an IPv4 host, it sends any such IPv6 packets out on IF4.
</t><t>
One can improve on this by making the translator behave as an IPv4
RP, or be an IPv4 PIM router running MSDP <xref target="RFC3618"/>
to exchange information
about active IPv4 sources. The translator can then use MSDP to signal
its active IPv4 sources (that may be translated IPv6 sources) so that
it will receive PIM joins if there are IPv4 receivers for the groups.
It can also use MSDP to see if there are IPv4 sources for IPv4 groups
that IPv6 hosts have joined.
</t><t>
Note that for SSM this is much simpler with no RP nor MSDP involved.
It may still be an advantage to act as an IPv4 PIM router, in order to
only do translation from IPv6 to IPv4 when there are IPv4 listeners.
</t>
    </section>
    <section title="Address Translation" anchor="addrtrans">
<t>
When IPv4 packets are resent as IPv6 we will need to replace the
source and destination addresses with suitable IPv6 addresses. And
similar replacement going from IPv6 to IPv4. The source addresses
are always unicast addresses, and the destination addresses are always
multicast addresses.
</t>
      <section title="Embedding IPv4 multicast addresses into IPv6"
	       anchor="mcembed">
<t>We need a way of referring to an IPv4 multicast group using an IPv6
address. IPv4 multicast addresses are embedded into IPv6 by
simply prepending them with a specific /96 IPv6 prefix such that for
each IPv4 multicast address we have a respective IPv6 multicast
address. However, both IPv4 and IPv6 have special ranges for SSM
usage, and one might want to take scoping into account.
</t><t>
This document proposes the use of one specific /96 IPv6 SSM prefix
(IPV6_TRSSM_ADDRESS prefix) for all IPv4 SSM addresses, and one
specific /96 IPv6 ASM (non-SSM) prefix (IPV6_TRASM_ADDRESS prefix)
for all IPv4 ASM (non-SSM) addresses. Hence IPv4 multicast
addresses are embedded into IPv6 by appending them with a /96
IPV6_TRSSM_ADDRESS prefix if the IPv4 multicast addresses are in the
IPV4_SSM_ADDRESS range, or with a /96 IPV6_TRASM_ADDRESS prefix if
they are in the IPV4_ASM_ADDRESS range.
</t><t>
An administrator may choose the exact prefixes used, and depending
on the prefix, also which IPv6 scope. The prefix must be in
accordance with the IPv6 multicast address format defined in section
2.7 of <xref target="RFC4291"/>.
The addresses used will then be of the form FFxx:&lt;blah&gt;:&lt;IPv4&gt; where
flags, scope and the value of "blah" are chosen by the administrator.
"IPv4" is the last 32 bits specifying the IPv4 address of the IPv4
multicast group. For ASM it may be useful to use an Embedded-RP
<xref target="RFC3956"/> prefix based on an IPv6 unicast address of
the translator.
</t><t>
Note that as specified in <xref target="RFC3307"/> the IPv4 address
will become the Group ID, and since all IPv4 multicast addresses have
the leading bit set, the IPv6 multicast addresses will become
"server allocated" addresses. We can regard the translator as the
"allocation server".
</t><t>
The unicast addresses of multicast sources also need to be
translated. We recommend embedding all IPv4 unicast addresses into
a /96 IPv6 prefix. This allows different IPv4 unicast addresses to
be mapped to different IPv6 unicast addresses, and for IPv6 SSM joins
to address specific IPv4 SSM sources. Note that for ASM use, it
may be sufficient to map all IPv4 sources to one single IPv6 address.
For translating IPv6 sources into IPv4 sources, one may use a single
address, or a pool of IPv4 addresses. The same IPv4 address may need
to be re-used for different IPv6 sources. If the translator also
translates unicast packets, then it should use the same unicast
translation mechanism for source addresses in multicast packets. Due
to multicast RPF checks, the IPv4 and IPv6 unicast addresses used need
to be routed towards the translator.
</t>
      </section>
      <section title="Translating IPv6 multicast addresses into IPv4"
	       anchor="mctrans">
<t>
For the multicast address translation from IPv6 to IPv4, we simply
extract the last 32 bits. However, if the IPv6 multicast address is
not in the range of either IPV6_TRSSM_ADDRESS or IPV6_TRASM_ADDRESS
range, IPv4 hosts cannot join the multicast whose destination
address is not in these address ranges. Therefore the translator
does not translate and does not forward such data from the interface
IF4.
</t><t>
The translator can be implemented on a host (bumped into a stack), or
a layer 3 device. In the latter case, link-local multicast addresses
MUST NOT be translated, since a CPE has to treat IPv4 link-local scope
and IPv6 link-local scope as different ones. (Please note that this is
specific to an IGMP/MLD-based translator, since PIM does not generate
a join for link-local multicast addresses.)
</t>
      </section>
      <section title="Embedding IPv4 source addresses into IPv6"
	       anchor="ucembed">
<t>
Unicast addresses of multicast sources also need to be translated.
An IPv4 unicast address of a multicast source is embedded into a
/96 IPv6 unicast prefix. The /96 IPv6 unicast prefix will be
prepared as the address pool of the translator. It will be same or
part of the unicast prefix assigned at the translator's
IF6. This allows PIM join messages to be forwarded to the
translator, and also enables IPv6 SSM joins to be translated to
IPv4 SSM joins.
</t><t>
One could consider using just a single IPv6 unicast address for all
IPv4 multicast translated into IPv6. For ASM use, it may be
sufficient to map all IPv4 sources to one single IPv6 address, and
this single IPv6 address can be the translator's IPv6 global
unicast address assigned on IF6, because this document assumes
that the translator acts as an RP for IPv6 PIM. On the other hand,
for SSM, each IPv6 SSM join should be translated to uniquely
specify a corresponding IPv4 SSM join.  In order to do this, the
simplest way is that an IPv4 unicast address of a multicast source
is embedded into a /96 IPv6 unicast prefix the translator prepared.
</t><t>
An alternative to using a /96 IPv6 unicast prefix could also be to
dynamically allocate IPv6 unicast addresses from a pool, see
<xref target="I-D.tsuchiya-mtp"/>.
</t>
      </section>
      <section title="Translating IPv6 source addresses into IPv4"
	       anchor="uctrans">
<t>
For translating IPv6 sources into IPv4 sources, one may use a single
address, or a pool of IPv4 addresses.  The same IPv4 address may need
to be re-used for different IPv6 sources.  If the translator also
translates unicast packets, then it should use the same unicast
translation mechanism for source addresses in multicast packets.
</t><t>
If unicast traffic is translated, then similar translation should be
used for the multicast source addresses.  Note that for RTP the
application can know the real source and tell streams apart, even if
they are translated into the same multicast source address.
The translation mechanism for IGMP/MLD/PIM MUST be same as the one
for the multicast data.
</t>
      </section>
    </section>
    <section title="Examples" anchor="examples">
<t>To illustrate how the translator works, we will look at some examples. In
all the examples we assume that there is no previous state in the translator.
</t>
      <section title="IPv6 host joining a group inside the /96 prefix" anchor="join6">
<t>An IPv6 host joins the group FFxx:&lt;blah&gt;:a.b.c.d. If the translator
is the DR for the host, it will receive an MLD membership report. If
not, it will receive a PIM join since it is the RP for the group.
The translator checks whether the address is
inside the /96 prefix, and whether the last 32 bits (a.b.c.d) is an
IPv4 multicast address. If it is, it joins a.b.c.d using IGMP or PIM,
and stays joined as long as there are IPv6 receivers.
</t><t>
For SSM the translator would in addition check if the source in the
join is inside the /96 unicast prefix used. If this is the case, it
then uses the last 32 bits as the IPv4 source. It can then do a
source-specific IPv4 join.
</t><t>
When the translator receives a multicast packet for a.b.c.d it prepends
the /96 prefix to form the IPv6 address FFxx:&lt;blah&gt;:a.b.c.d. If the
translator has outgoing interfaces for this group, it will send an IPv6
packet to the same interfaces to which it would have forwarded an
IPv6 packet for the group.  The destination address will be
FFxx:&lt;blah&gt;:a.b.c.d, and the source address will be computed using the
/96 unicast prefix. For SSM, the translator would also check that it
got an outgoing interface for the specific source.
</t>
      </section>
      <section title="IPv6 host sending to group inside the /96 prefix" anchor="send6">
<t>An IPv6 host sends to the group FFxx:&lt;blah&gt;:a.b.c.d. If the translator
is the DR for the host, it will receive the data natively. If not, it
will receive PIM register messages containing the data since it is the
RP. For each packet received, either natively or inside register
messages, it will first check that the destination address is inside
the /96 prefix and that the last 32 bits (a.b.c.d) is an IPv4
multicast address. If this is okay, it will resend the packet to the
IPv4 address a.b.c.d. The source address would be chosen from a given
pool of IPv4 unicast addresses (this may just be a single fixed address).
</t><t>
If the translator is also an IPv4 PIM router, then we do some further
steps. For ASM, if the translator is an RP and uses MSDP, it should announce
the translated source in MSDP, and only forward translated packets if it
has a join for the group. For SSM, it should only forward translated packets
if it has a join for the specific source and group.
</t>
      </section>
      <section title="IPv4 host joining an IPv4 group" anchor="join4">
<t>
In some cases, ISP network supports IPv6-multicast, but 
a host or an application only supports IPv4-multicast.
IGMP/MLD-proxy based translator helps such case by accommodating
such hosts.  (IGMP/PIM-based translator would also work, but it is
not described here since the behavior is almost same as <xref target="join6"/>
and <xref target="send6"/>.)
</t>

<t>
We have mapped IPv4 multicast groups to a subset of the IPv6 multicast
groups by embedding them in /96 IPv6 prefixes. Typically one prefix for
ASM and one for SSM.
An IPv4 host joins to the group a.b.c.d, and the translator will receive the
IGMP join and resend an MLD join for FFxx:&lt;blah&gt;::a.b.c.d to IF6. When
an MLD query arrives from IF6, the translator replies with MLD reports based
on the IGMP membership database (a.b.c.d) and the /96 prefix
(FFxx:&lt;blah&gt;::).
</t>

<t>In case of SSM, the translator in addition synthesizes an IPv6 source
address from the IPv4 source address in the IGMP join
(see <xref target="ucembed"/>), and resends a source-specific MLD join
for the synthesized IPv6 address.
</t>

<t>
When the translator receives an IPv6 multicast packet, it checks whether
the group address is inside the /96 prefix, and whether the last 32bits
(a.b.c.d) is an IPv4 multicast address. If both hold true and a.b.c.d exists
in the IGMP membership database, the translator will convert the received
IPv6 packet into IPv4 and send it for the IF4 interfaces where a.b.c.d is
subscribed. The source address of the IPv4 packet is synthesised as in
<xref target="uctrans"/>, and its destination address is a.b.c.d.
</t>
        </section>
        <section title="IPv4 host sending to a group a.b.c.d">
<t>
When the translator receives a packet for a.b.c.d and it is also a DR for
the host, it will convert the received IPv4 packet into IPv6 and send it
to IF6. The source and destination address of the IPv6 packet is synthesized
as in <xref target="ucembed"/> and <xref target="mcembed"/>, respectively.
</t>
      </section>
    </section>
    <section title="Acknowledgments" anchor="acks">
<t>The authors thank Michal Przybylski and Pekka Savola for
valuable comments, and also people from the M6Bone community for
testing a prototype implementation. Also thanks to Teemu Kiviniemi
who has implemented and deployed a second translator implementation
based on this document.
</t>
    </section>
    <section title="Security Considerations" anchor="seccon">
<t>When using such a translator one needs to take some care of
scoping and TTL values. Due to differences in IPv4 and IPv6 scoping,
a narrow scope might be translated into a wider one.
</t><t>
One may wish to limit who can access the translator. If for instance one
wishes to restrict it to a site, one can use a /96 prefix of
site-local scope, and then filter at the site border, just like one would
for multicast in general. A translator implementation could also offer a
way of restricting which groups and sources should be accepted.
</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3307" ?>
      <?rfc include="reference.RFC.3618" ?>
      <?rfc include="reference.RFC.3956" ?>
      <?rfc include="reference.RFC.4291" ?>
      <?rfc include="reference.RFC.4601" ?>
      <?rfc include="reference.RFC.4605" ?>
      <?rfc include="reference.RFC.4607" ?>
    </references>
    <references title="Informative References">
      <?rfc include="reference.I-D.tsuchiya-mtp.xml" ?>
    </references>
  </back>
</rfc>
