One document matched: draft-tsou-softwire-6rd-multicast-00.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">
]>
<?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="std" docName="draft-tsou-softwire-6rd-multicast-00" 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>tena@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>1852 Lorraine Ave</street>
<city>Ottawa</city>
<region>Ontario</region>
<country>Canada</country>
<code>K1H 6Z8</code>
</postal>
<phone>+1 613 680 2675</phone>
<email>tom111.taylor@bell.net</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>cathyzhou@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="2011" />
<!-- 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 use the native multicast capabilities
of the IPv4 network to acquire and forward multicast traffic from 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 (BR). </t>
<section title="Requirements Language">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</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>
<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 CE and the 6rd Border Relay. In addition,
it postulates a multicast source discovery and translation function,
which MAY be collocated with the BR. See <xref target="fig_mularch"/>.</t>
<figure anchor="fig_mularch"
title="IPv6 Multicast Across an IPv4 Domain Using a Translator Function">
<artwork>
+------------+
| Translator |
-| function |-
/ +------------+ \
+----+ +----+ Access +--------+ / \
|IPv6| LAN | 6rd| Link |Provider| IPv4 +------+ IPv6
|Host|--------| CE |--------|IP Edge |- network ---|Border|--- network
+----+ +----+ +--------+ |Relay |
+------+
</artwork>
</figure>
<t>In addition to its 6rd responsibilities, the 6rd CE is responsible for:
<list style="symbols">
<t>requesting a mapping between IPv6 <Source, Group> pairs presented
by the IPv6 Host and IPv4 <Source, Group> pairs valid for the
provider's IPv4 network;</t>
<t>interworking between MLD <xref target="RFC3810"/> presented by the
IPv6 Host and IGMP <xref target="RFC3376"/> forwarded toward the
provider's IPv4 network; </t>
<t>translating incoming IPv4 multicast streams to IPv6 before
forwarding them to the IPv6 Host.</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>requesting a mapping between IPv4 <Source, Group> pairs received
in PIM messages from the IPv4 network and IPv6 <Source, Group>
pairs valid for the neighbouring IPv6 network;</t>
<t>translating PIM messaging between the IPv4 and IPv6 networks;</t>
<t>using the reverse mapping from IPv6 to IPv4 <Source, Group>
pairs to translate and forward multicast media streams coming from
the IPv6 network.</t>
</list>
</t>
<t>The Translator function has the following responsibilities:
<list style="symbols">
<t>creating a mapping between IPv6 and IPv4 <Source, Group>
address pairs for multicast streams, beginning with IPv6 address
pairs provided in requests from the 6rd CE and assigning the
corresponding IPv4 unicast and multicast addresses from pool of
addresses with which it is configured.</t>
<t>responding to requests for mappings in either direction.</t>
</list>
</t>
</section>
<section anchor="solSteps" title="Steps In the Proposed Solution">
<t>1. Initial discovery and Join request</t>
<t>The IPv6 Host discovers the <Source, Group> address pair of a multicast
stream the user wants to receive. The discovery is by means outside
the scope of this specification (e.g., via the web). The IPv6 Host
sends an MLDv2 <xref target="RFC3810"/> request to the 6rd CE to
acquire the stream.</t>
<figure anchor="fig_step1">
<artwork>
+----+ +----+
|IPv6| LAN | 6rd|
|Host|--------| CE |
+----+ +----+
------->
MLD/IPv6
</artwork>
</figure>
<t>2. <Source, Group> Address Mapping At 6rd CE</t>
<t>The 6rd CE checks its cache of mappings to see if it already has a
mapping between the IPv6 <Source, Group> address pair received in
the MLD request and a corresponding pair of IPv4 addresses. Failing
to find a mapping, it sends a request for the required mapping to the
Translator. The Translator in turn checks whether it has already
created the mapping. If not, it assigns unicast and multicast IPv4
addresses from its pool and records the mapping for further use. In
either case it returns the requested mapping to the 6rd CE, which caches
it. [Editor's Note: The transaction is carried out over a protocol to be
specified in a later version of this document.]</t>
<figure anchor="fig_step2">
<artwork>
+----+ Access +--------+ +------------+
| 6rd| Link |Provider| IPv4 | Translator |
| CE |--------|IP Edge |- network -| function |
+----+ +--------+ +------------+
----------------------------->
TBD protocol / IPv4
</artwork>
</figure>
<t>3. Propagation Of the Join Request Into the IPv4 Network</t>
<t>The 6rd CE interworks between the MLDv2 request it received and an
IGMPv3 <xref target="RFC3376"/> request which it forwards to the
Provider IP Edge. It uses the address pair mapping it received from
the Translator as part of this interworking.</t>
<t>The Provider IP Edge acts on the IGMP request by forwarding a PIM
<xref target="RFC3973"/> or <xref target="RFC4601"/> request into the
IPv4 network, indicating the IPv4 <Source, Group> address pair it
was given and ensuring that it is on the multicast tree for the stream
concerned. [Editor's note: details later.]</t>
<t>Eventually the PIM request finds its way to the 6rd Border Relay.
[Editor's note: details needed here to make sure this happens.
Alternatively, we could recast this as using any Border Router and not
a 6rd Relay in particular, but we would end up with possibly different
paths for the multicast packets and the returning unicast RTCP feedback. Maybe
that doesn't matter.]</t>
<figure anchor="fig_step3" title="">
<artwork>
+----+ Access +--------+ +------+
| 6rd| Link |Provider| IPv4 |Border| IPv6
| CE |--------|IP Edge |- network -|Relay |- network
+----+ +--------+ +------+
--------> ------------>
IGMP/IPv4 PIM/IPv4
</artwork>
</figure>
<t>4. Remapping the <Source, Group> Address Pair At the 6rd BR</t>
<t>The 6rd BR needs to map from the IPv4 <Source, Group> address
pair it received back to the corresponding IPv6 address pair before
propagating the PIM request into the IPv6 network. It sends a request
to the Translator to provide that mapping. The Translator already
has this mapping, as a result of the original 6rd CE request, and
returns it to the 6rd BR. [Editor's note: protocol again to be specified
later. It can probably be the same as the one used by the 6rd CE, since
both nodes are operator-managed even if the 6rd CE is more likely to
have been hacked. Have to work out the security considerations.] </t>
<figure anchor="fig_step4">
<artwork>
+------+
|Border|
|Relay |
+------+
| TBD protocol
| /IPv4
+----V-------+
| Translator |
| function |
+------------+
</artwork>
</figure>
<t>5. Propagation Of the PIM Request Into the IPv6 Network</t>
<t>The 6rd BR propagates translates the PIM request from IPv4 to IPv6
using the mapping it received. It propagates the request into the IPv6
network to complete the construction of the path for the requested
multicast stream. [Editor's note: probably don't have to go this far
if there are already other listeners attached to the IPv4 network.
Have to insert corresponding text in previous steps. Also, if PIM
can return errors, the 6rd BR should notify the Translator so it can
mark the IPv6 address pair as bad (so it doesn't get remapped) while
releasing the assigned IPv4 addresses.]</t>
<figure anchor="fig_step5">
<artwork>
+------+
|Border| IPv6
|Relay |- network
+------+
----------->
PIM/IPv6
</artwork>
</figure>
<t>6. Transport of Multicast Media and Unicast RTCP Feedback</t>
<t>If the 6rd BR receives a multicast packet from the IPv6 network, it
translates the source and group addresses to IPv4 using the mapping it
has retained from Step 4. It then forwards it to the next hop in the
multicast tree for that stream.</t>
<figure anchor="fig_step6">
<artwork>
+------+
IPv4 |Border| IPv6
network -|Relay |- network
+------+
<---------- <----------
Media packet Media packet
<S',G'>/IPv4 <S,G>/IPv6
</artwork>
</figure>
<t>When the 6rd CE receives a multicast packet from the IPv4 network,
it translates the packet to IPv4 using the mapping which it has
retained from Step 2.</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>
<t>Finally, if the IPv6 Host emits multicast packets destined for an
any-source multicast group, the 6rd CE and 6rd BR translate the packets
from IPv6 to IPv4 and back again using the mappings they have retained.</t>
</section>
</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;
</references>
<references title="Informative References">
&RFC3550;
&RFC5569;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:55 |