One document matched: draft-tsou-softwire-6rd-multicast-02.xml
<?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" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC3973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3973.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC5569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5569.xml">
<!ENTITY RFC5969 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.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-tsou-softwire-6rd-multicast-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or 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 abbrev="IPv6 Multicast With 6rd" >IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment </title>
<author initials="T." surname="Tsou" fullname="Tina 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>
<uri>http://tinatsou.weebly.com/contact.html</uri>
</address>
</author>
<author initials="T." surname="Taylor" fullname="Tom Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region>Ontario</region>
<country>Canada</country>
<code></code>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author fullname="Hui Ji" initials="H."
surname="Ji">
<organization>China Telecom</organization>
<address>
<postal>
<street>NO19.North Street</street>
<region>Chaoyangmen,Dongcheng District</region>
<city>Beijing</city>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>jihui@chinatelecom.com.cn</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>General</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. -->
<keyword>multicast</keyword>
<keyword>6rd</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes how IPv6 multicast can be extended across
an IPv4 network to an IPv6 host, using the native multicast capabilities
of the IPv4 network.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>6rd (<xref target="RFC5569"/>, <xref target="RFC5969"/>) provides
a means to connect IPv6 hosts to the IPv6 Internet across an IPv4 provider
network. Unicast traffic is carried through IPv6-in-IPv4 tunnels. It
is possible to carry multicast traffic from the IPv6 network through
the IPv4 network in the same way, but if multiple customers wish access
to the same multicast channels, the failure to use the native multicast
capabilities of the IPv4 network wastes resources in that network. </t>
<t>This document describes a solution using the native multicast capabilities
of the IPv4 network to acquire and forward multicast traffic from the IPv6
Internet to an IPv6 host attached to the IPv4 network. Typically this
solution will operate in combination with 6rd for unicast traffic. However,
no IPv6-in-IPv4 tunneling is required for signalling, only the ability to
interwork between IPv4 and IPv6 at the 6rd Customer Equipment (6rd CE) and
the 6rd Border Relay (6rd BR). </t>
<section title="Terminology">
<t>The term "address pair" is used to denote the combination of unicast
source address and multicast group address corresponding to a given
multicast stream at a given point along the path between the source and
receiver. </t>
</section>
</section> <!-- intro -->
<section anchor="sol" title="Description of the Solution">
<t>A number of problems have to be solved to allow an IPv6 host attached
to an IPv4 network to request and receive a multicast stream originating
in a neighbouring IPv6 network and passing through the IPv4 network using
the native multicast facilities of that network. These problems are
described in detail in the course of presenting proposed solutions to
them. </t>
<t>It is assumed that the IPv6 host wishing to receive a multicast stream
acquires the corresponding IPv6 address pair by means out of scope of this
document. See <xref target="ID.mboned-multrans-addr-acq"/>. </t>
<section anchor="arch" title="Assumed Architecture">
<t>This document assumes an architecture similar to that of 6rd
<xref target="RFC5569"/>, <xref target="RFC5969"/>, with additional
capabilities for the 6rd Customer Edge (CE) and the 6rd Border Relay (6rd BR). See
<xref target="fig_mularch"/>.</t>
<figure anchor="fig_mularch"
title="IPv6 Multicast Across an IPv4 Domain Using a Translator Function">
<artwork>
+----+ +----+ Access +--------+ +------+
|IPv6| LAN | 6rd| Link |Provider| IPv4 |Border| IPv6
|Host|--------| CE |--------|IP Edge |-- network --|Relay |--- network
+----+ +----+ +--------+ +------+
</artwork>
</figure>
<t>In addition to its 6rd responsibilities, the 6rd CE is responsible for:
<list style="symbols">
<t>mapping between the IPv6 address pair presented
by the IPv6 Host and an IPv4 address pair designating the same multicast
stream in the provider's IPv4 network;</t>
<t>accepting MLD <xref target="RFC3810"/> on the IPv6 Host side
and emitting IGMP <xref target="RFC3376"/> toward the
provider's IPv4 network; </t>
<t>using the reverse mapping from IPv6 to IPv4 address
pairs to translate incoming IPv4 multicast streams to IPv6 before
forwarding them to the IPv6 Host. Alternatively, decapsulating IPv6
multicast data packets from incoming IPv4 packets.</t>
</list>
</t>
<t>The Provider IP Edge has the normal function of interworking
between IGMP <xref target="RFC3376"/> and PIM <xref target="RFC4601"/>
multicast signalling.</t>
<t>The Border Relay has the usual 6rd responsibilities. In addition,
it is responsible for:
<list style="symbols">
<t>mapping between IPv4 address pairs received in PIM messages from the
IPv4 network and IPv6 address pairs denoting the same multicast streams
in the neighbouring IPv6 network;</t>
<t>translating addresses in PIM between the IPv4 and IPv6 networks;</t>
<t>using the reverse mapping from IPv6 to IPv4 address pairs to
translate and forward multicast data packets coming from the IPv6
network. Alternatively, using the reverse mapping to generate
encapsulating IPv4 headers for the IPv6 packets before forwarding
them as multicast IPv4 data.</t>
</list>
</t>
</section>
<section anchor="solSteps" title="Components of the Proposed Solution">
<section anchor="map" title="Address Mapping">
<t>Both the 6rd CE and the 6rd BR need to map between IPv6 and IPv4 addresses,
in both directions. The IPv6 address pairs do not have to be the same at the
two nodes, so long as the IPv6 address pair used by the host designates the
same multicast stream as the IPv6 address pair generated at the 6rd BR or
received from the source IPv6 network.</t>
<t>Because the source network uses IPv6, mapping between the addresses
used in that network and the IPv4 addresses used in the provider network
is in general a difficult problem. The most general solution is to
configure static mappings between the IPv6 and corresponding IPv4 address
pairs at the 6rd BR. Mapping at the 6rd CE can use IPv4-embedded IPv6 addresses
as defined in <xref target="RFC6052"/> for the unicast source addresses,
and <xref target="ID.mboned-64-mcast-addr-fmt"/> for the multicast group
addresses. This assumes that the IPv6 host has been provided with such
addresses in the first place. It also assumes that the IPv4 network provider
can configure suitable prefixes at the 6rd CE for the purpose of such
mapping.</t>
<t>With restrictions on the IPv6 addresses used for multicast source and
group addresses in the IPv6 network, it may be possible to use algorithmic
instead of static mapping at the 6rd BR. This generally requires
coordination between the IPv4 and IPv6 network operators.</t>
</section>
<section anchor="rout" title="Multicast Routing">
<t>For each IPv4 address to which an IPv6 source address is mapped, the
routing tables that PIM uses must result in a path that passes through a
multicast-enabled 6rd BR. At the routing level, this means that the 6rd BR must
advertise reachability to the mapped IPv4 source addresses it knows about
into the IPv4 domain. Its distance metrics to those addresses must reflect
the routing information it receives on the IPv6 side for their IPv6
counterparts. </t>
</section>
<section anchor="mldIGMP" title="Translation From MLD To IGMP">
<t>See <xref target="ID.perreault-igmp-mld-translation"/>.</t>
</section>
<section anchor="pimINTWK" title="Interworking Between PIM With IPv4 and PIM with IPv6 At the 6rd BR">
<t>See <xref target="ID.taylor-pim-v4v6-translation"/>.</t>
</section>
<section anchor="data" title="Transport of Multicast Data Packets and Unicast RTCP Feedback">
<t>The documents cited in the previous two sections describe the process of
header translation for multicast data packets. The address mapping aspect
of that translation was discussed in <xref target="map"/>. If the 6rd BR and
6rd CE are configured to use encapsulation/decapsulation of multicast data
packets instead, the encapsulating IPv4 header uses the IPv4 address pair
mapped from the original IPv6 address pair as source and destination.
However, this requires that the IPv6 host uses the same IPv6 addresses
as the source IPv6 network for each multicast stream it receives. That may
force the 6rd CE to use static rather than algorithmic mapping for address
pairs for its MLD/IGMP translation. </t>
<t>When the IPv6 Host sends unicast RTCP <xref target="RFC3550"/>
feedback toward the source, the packets are treated by the 6rd CE and
6rd BR like any other unicast packets. That is, they are encapsulated
at the 6rd CE, transported across the IPv4 network as IPv6-in-IPv4, and
decapsulated at the 6rd BR before forwarding into the IPv6 network.</t>
</section>
</section><!-- solSteps -->
</section> <!-- sol -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Awaiting comments.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo currently includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To come.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC3376;
&RFC3810;
&RFC3973;
&RFC4601;
&RFC5969;
&RFC6052;
<reference anchor="ID.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="August" year="2012"/>
</front>
</reference>
<reference anchor="ID.perreault-igmp-mld-translation">
<front>
<title>Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation") (Work in progress)</title>
<author initials="S." surname="Perrault" fullname="S. Perrault">
<organization>Viagenie</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC3550;
&RFC5569;
<reference anchor="ID.mboned-multrans-addr-acq">
<front>
<title>Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions (Work in progress)</title>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<author initials="A." surname="Clauberg" fullname="A. Clauberg">
<organization>Deutsche Telekom</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="S." surname="Venaas" fullname="S. Venaas">
<organization>Cisco Systems</organization>
</author>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<date month="March" year="2012"/>
</front>
</reference>
<reference anchor="ID.taylor-pim-v4v6-translation">
<front>
<title>Operation of a Dual-Stack Multicast Router With Address Translation (Work in progress)</title>
<author initials="T." surname="Taylor" fullname="T. Taylor">
<organization>Huawei Technologies</organization>
</author>
<author initials="C." surname="Zhou" fullname="C. Zhou">
<organization>Huawei Technologies</organization>
</author>
<date month="July" year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:26 |