One document matched: draft-zhou-softwire-6rdmulticast-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" [
<!-- 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 I-D.ietf-softwire-dslite-multicast SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dslite-multicast.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2491.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3171.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 RFC4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY RFC4286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4286.xml">
<!ENTITY RFC4541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4541.xml">
<!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC4605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4605.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">
<!ENTITY RFC6145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
<!ENTITY RFC6788 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6788.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-zhou-softwire-6rdmulticast-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> IPv6 Multicast in a 6rd Deployment </title>
<author initials="B." surname="Sarikaya" fullname="B. Sarikaya">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 175</street>
<city>Plano</city>
<region>TX</region>
<code>75024</code>
<country>USA</country>
</postal>
<phone></phone>
<email>sarikaya@ieee.org</email>
</address>
</author>
<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 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>
<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="Qiong Sun" initials="Q.S." surname="Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street>Room 708, No.118, Xizhimennei Street</street>
<street/>
<city>Beijing </city>
<region>P.R. China</region>
<code>100035</code>
</postal>
<phone>+86-10-58552936</phone>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<date year="2014" />
<!-- 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 memo specifies 6rd's multicast component so that IPv6 hosts
can receive multicast data from IPv6 servers. In the 6rd
encapsulation solution, multicast communication is completely
integrated into the 6rd tunnel. In the 6rd translation solution, the
protocol is based on proxying MLD at the 6rd Customer Edge router
interworking the MLD messages to IGMP messages and sending them
upstream through a network which supports IPv4 multicast. The 6rd
Border Relay is a multicast router and interworks the IGMP to MLD for
onward propasgation toward the IPv6 multicast source. IPv6 Multicast
data received at 6rd Border Relay is translated into IPv4 multicast
data and and delivered through the IPv4 multicast tree downstream to
the 6rd Customer Edge. The latter translates it back to IPv6 multicast
data then delivers it to the hosts.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>With IPv4 address depletion on the horizon, many techniques are
being standardized for IPv6 migration including 6rd <xref
target="RFC5969"/>. 6rd enables IPv6 hosts to communicate with
external hosts using an IPv4-only legacy ISP network. The 6rd Customer
Edge (CE) device's LAN side is dual stack and the WAN side is IPv4
only. The CE tunnels IPv6 packets received from the LAN side to 6rd
Border Relays (BR) after encapsulating them as IPv4 packets. The BRs
have anycast IPv4 addresses and receive encapsulated packets from CEs
over a virtual interface. 6rd operation is stateless. Packets are
received/ sent independently of each other and no state needs to be
maintained.</t>
<t>It should be noted that there is no depletion problem for IPv4
address space allocated for any source multicast and source specific
multicast <xref target="RFC3171"/>. This document is not motivated by
the depletion of IPv4 multicast addresses.</t>
<t>6rd as defined in <xref target="RFC5969"/> and <xref
target="RFC5569"/> is unicast only. It does not support multicast.
In this document we specify how multicast from home IPv6 users can be
supported in 6rd. This is what is meant by 6rd multicast
protocol.</t>
<t>In the 6rd encapsulation approach, 6rd multicast is integrated into
the 6rd unicast solution. 6rd customer premise equipment (CPE) is
extended to support an MLD proxy <xref target="RFC4605"/>. This proxy
receives MLD Membership Report messages <xref target="RFC4601"/>
requesting to join a multicast group from its subtended hosts. It
tunnels aggregated join requests upstream to the 6rd Border Router
(BR) using IPv6 in IPv4 encapsulation. The 6rd Border Router is
extended to support an MLD querier, which sends join requests upstream
towards the multicast source(s, becomes part of the multicast tree,
and thus receives IPv6 multicast data. The 6rd Border Router
encapsulates the IPv6 multicast data using 6rd's IPv6 in IPv4
encapsulation and sends it to each member CPE that has joined the
stream concerned. The CPE decapsulates the packet and the MLD proxy
sends the IPv6 multicast data downstream to the member hosts.</t>
<t>In the translation approach, native IPv4 multicast support in the
network between Customer Edge routers and Border Router can be
exploited. The translation approach requires MLD to IGMP interworking
at the Customer Edge and IGMP to MLD interworking at the border
router. The border router needs to translate IPv6 multicast data into
IPv4 multicast data and the Customer Edge router needs to translate
IPv4 multicast data back into IPv6 multicast data.</t>
<t>6rd's CE to CE forwarding feature is not used in either
approach.</t>
</section> <!-- intro -->
<section anchor="term" title="Terminology">
<t>This document uses the terminology defined in <xref
target="RFC5969"/>, <xref target="RFC5569"/>, <xref
target="RFC3810"/>, <xref target="RFC3376"/>, and
<xref target="I-D.ietf-softwire-dslite-multicast"/>.</t>
<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> <!-- term -->
<section anchor="req" title="Requirements">
<t>This section states requirements on 6rd multicast support
protocol.</t>
<t>IPv6 hosts connected to 6rd CE router MUST be able to join
multicast groups in IPv6 and receive multicast data.</t>
<t>Both any source multicast (ASM) and source specific multicast (SSM)
MUST be supported.</t>
<t>6rd multicast MUST NOT introduce the need to use more IPv4
addresses, thereby contributing to public IPv4 address depletion.</t>
</section> <!-- req -->
<section anchor="arch" title="Architecture">
<t>In 6rd, IPv6 or IPv4/IPv6 dual stack hosts are served by the 6rd
Customer Edge device (CE). The CE is dual stack facing the hosts and
IPv4 only facing the network or WAN side. The CE tunnels IPv6 packets
in IPv4 to the 6rd Border Relay (BR). The BR decapsulates the
tunneled packets and forwards them to the IPv6 network. In the reverse
direction, the BR receives IPv6 packets from the IPv6 network tunnels
them in IPv4 to the CE. The CE decapsulates the IPv6 packets and
forwards them to the hosts.</t>
<t>Unicast 6rd is stateless. Each IPv6 packet sent by the CE is
treated separately and different packets from the same CE may go to
different BRs. The CE encapsulates IPv6 packets in IPv4 with the IPv4
destination address set to the BR address (usually an anycast IPv4
address). BRs are placed where IPv6 native connectivity exists to
other networks. A CE is configured with its own IPv4 address (public
or private), with a 6rd IPv6 prefix from which the CE's IPv4 address
can be derived, and with one or more BR IPv4 addresses. When the BR
receives IPv6 packets addressed to the CE, it extracts the CE's IPv4
address from the destination IPv6 address and uses this address as the
destination address for the IPv4 encapsulation of the IPv6 packet.
6rd views the IPv4-only network as an NBMA link from the IPv6 point of
view and all 6rd CEs and BRs are defined as off-link neighbors from
one other.</t>
<section anchor="encaps" title="6rd Tunneling Architecture">
<t>In order to support multicast, the CE implements an MLD Proxy
function <xref target="RFC4605"/>. IPv6 hosts send their join
requests (MLD Membership Report messages) to CE. The CE as a proxy sends
aggregated Report messages upstream towards BR in unicast using IPv6
in IPv4 encapsulation.</t>
<figure anchor="fig_tun" title="Architecture of 6rd Tunneling Multicast Protocol">
<artwork>
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +-----+ only +-------+ +
+----+ | CE | network -- | BR |
| H2 | ---| MLD |--- IPv6 | MLD | IPv6
+----+ |Proxy| in |Querier| Network
+----+ +-----+ IPv4 +-------+
| H3 | Encapsulation
+----+
</artwork>
</figure>
<t>The BR is the default multicast querier for the CE. The BR
implements a multicast router function or it could be another MLD
proxy.</t>
<t>All the elements of 6rd multicast support system are shown in <xref
target="fig_tun"/>.</t>
</section> <!-- encaps -->
<section anchor="transl" title="Translation Architecture">
<t>In order to support multicast, CE implements MLD Proxy
<xref target="RFC4605"/> and MLD to IGMP interworking function
<xref target="ID.perreault-igmp-mld-translation"/>. IPv6 hosts send
their join requests (MLD Membership Report messages) to CE. CE as a
proxy sends aggregated IGMP Report messages upstream towards BR.</t>
<t>In order to support SSM, MLDv2 <xref target="RFC3810"/> and IGMPv3
<xref target="RFC3376"/> must be supported by the CE and BR, and MLDv2
must be supported by the host.</t>
<t>The BR is the default multicast querier for the CE. The BR
implements an IGMP to MLD interworking function and multicast router
function or it could be another MLD proxy.</t>
<t>It is assumed that the IPv4 only network to which the CE and the BR
are connected supports native IPv4 multicast.</t>
<t>All the elements of 6rd translation-based multicast support system
are shown in <xref target="fig_transl"/>.</t>
<figure anchor="fig_transl" title="Architecture of 6rd Translation-Based Multicast">
<artwork>
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +----------------+ only +------------------+
+----+ | CE MLD | network |IGMP BR | +
| H2 | ---| MLD IGMP |-----------| MLD MLD |
+----+ |Proxy Translator| |Translator Querier|
+----+ +----------------+ +------------------+
| H3 | IPv6
+----+ Network
</artwork>
</figure>
</section> <!-- transl -->
</section> <!-- arch -->
<section anchor="tunop" title="6rd Tunneling Multicast Operation">
<t>In this section we specify how the host can subscribe and receive
IPv6 multicast data from IPv6 content providers based on the
architecture defined in <xref target="fig_tun"/>.</t>
<t>The hosts will send their subscription requests for IPv6 multicast
groups upstream to the default router, i.e., Costumer Edge device.
After subscribing the group, the host can receive multicast data from
the CE. The host implements MLD protocol's host part.</t>
<t>The Customer Edge device is an MLD Proxy. After receiving the
first MLD Report message requesting subscription to an IPv6 multicast
group, the CE establishes a tunnel interface with a Border Relay. The
tunnel is IPv4 based but it will carry MLD messages back and forth and
IPv6 multicast data messages downstream.</t>
<t>The CE is a regular MLD proxy and it keeps an MLD proxy membership
database. The CE inserts multicast forwarding state on the incoming
interface, and merges state updates into the MLD proxy membership
database. The CE updates or remove elements from the database as
required. The CE will then send an aggregated Report via the upstream
tunnel to the BR when the membership database changes.</t>
<t>The CE answers MLD queries from the BR based on the membership
database. The CE's downstream link follows the traditional multipoint
channel forwarding and does not pose any specific problems.</t>
<t>The CE receives IPv6 multicast data from the BR tunneled over the
tunnel interface. The CE decapsulates the packet and then forwards it
downstream. Each member host receives the data packet based on the
Layer 2 multicast interface. No packet duplication is necessary.</t>
<t>The Border Relay acts as the default multicast querier for all CEs
that have established an IPv4 tunnel with it. In order to keep a
consistent multicast state between a CE and BR, once a CE is connected
it will stay connected until the state becomes empty. After that
point, the CE may establish another tunnel to a different BR.</t>
<t>According to aggregated MLD reports received from subtending CEs,
the BR establishes group/source-specific multicast forwarding states
at its corresponding downstream tunnel interfaces. After that, the BR
maintains or removes the state as required by the aggregated reports
received from CEs.</t>
<t>At the upstream interface, the BR procures for aggregated multicast
membership maintenance. Based on the multicast-transparent operations
of the CEs, the BR treats its tunnel interfaces as multicast enabled
downstream links, serving zero to many listening nodes.</t>
<t>When the BR receives MLD join requests from downstream CEs, the BR
sends PIM join messages upstream towards multicast source(s). This
results in a multicast tree formation where the BR is at the leaf of
the multicast tree, enabling the BR to receive IPv6 multicast data
sent by the source.</t>
<t>Multicast traffic arriving at the BR is transparently forwarded
according to its multicast forwarding information base. Multicast
data is first replicated according to MLD multicast group state and
then forwarded in IPv6-in-IPv4 tunnels from the BR to the
corresponding CEs.</t>
<section anchor="tunif" title="Tunnel Interface Considerations">
<t>IPv6 in IPv4 tunneling is performed as specified in
<xref target="RFC4213"/>. Considerations specified in
<xref target="RFC5969"/> apply. Packets passing upstream from the CE
carry only MLD signaling messages and they are not expected to be
fragmented. However packets downstream, i.e., multicast data to the
CEs, may be subject to fragmentation.</t>
<t>Source and destination addresses of MLD messages in IPv6-in-IPv4
tunnel from CE are as follows:
<list style="symbols">
<t>The source address of IPv4 header is the CE WAN interface IPv4
address. The destination address is the BR anycast address when an
invite message is sent to group G. Subsequent messages to group G
contain the BR unicast address as destination address.</t>
<t>The source address of the inner MLD message is the link local
address. The destination address is all MLDv2-capable multicast
routers or FF02::16 for MLD Version 2 Multicast Listener Reports.</t>
</list>
</t>
<t>The source and destination addresses of MLD messages in the IPv6-
in-IPv4 softwire from BR are as follows:
<list style="symbols">
<t>The source address of the IPv4 header is the BR IPv4 unicast
address. The destination address is the CE IPv4 address. This also
holds for multicast data.</t>
<t>The source address of the inner MLD message is the link local
address. The destination address is the link-scope all-nodes multicast
address (FF02::1) for General Queries, or the IPv6 multicast group
address for specific queries.</t>
</list>
</t>
<t>The source address of IPv6 multicast data is the unicast IPv6
address of the multicast source, e.g., the content provider. The
destination address is the3 IPv6 multicast group address.</t>
</section> <!-- tunif -->
<section anchor="avalanch" title="Avalanche Problem">
<t>In <xref target="tunif"/>, multicast data is replicated to all
interfaces, i.e., to all member CEs at the BR. This replication
(often called avalanche problem) can be very costly if is a very large
number of downstream member CEs such as in the IPTV application. See
Appendix A in <xref target="I-D.ietf-softwire-dslite-multicast"/>.</t>
<t>In 6rd tunneling multicast, the avalanche problem can be reduced by
careful network partitioning. More BRs can be deployed in areas where
IPv6 users are increasing in numbers. Deploying BRs by collocating
them with the access network gateway as with the Border Network
Gateway (BNG) is another possibility.</t>
<t>In the 6rd tunneling multicast operation, CEs are enabled to
exploit multiple BRs that can be deployed in the network by using the
BR anycast address any time they send an upstream MLD join request and
then using the same BR that received the join message in subsequent
MLD messages by using the same BR's unicast address.</t>
</section> <!-- avalanch -->
</section> <!-- tunop -->
<section anchor="translop" title="6rd Translation Multicast Operation">
<t>In this section we specify how the host can subscribe and receive
IPv6 multicast data from IPv6 content providers based on the
architecture defined in <xref target="fig_transl"/>.</t>
<t>The hosts will send their subscription requests for IPv6 multicast
groups upstream to the default router, i.e., the Costumer Edge device.
After subscribing the group, the host can receive multicast data from
the CE. The host implements the MLD protocol's host part.</t>
<t>The Customer Edge device is an MLD Proxy. After receiving the
first MLD Report message requesting subscription to an IPv6 multicast
group, the CE interworks the MLD Membership Report message to an IGMP
Membership report message. It sends it upstream only if joining a new
group is needed.</t>
<t>Address translation in generating an IGMP Membership report message
is done as follows: the destination address is copied from the last 32
bits of IPv6 multicast group address. The CE inserts the IPv4 address
of its WAN interface into the source address. It is assumed that the
IPv6 multicast group address in MLD Report message conforms to the
addressing scheme described in
<xref target="I-D.ietf-mboned-64-multicast-address-format"/>, for
any-source and source-specific multicast address formats.</t>
<t>Source addresses in the MLDv2 payload are translated as follows.
Multicast source addresses in MLD Membership Report message MUST use
uPrefix64, i.e. 64:ff9b::/96 defined in <xref target="RFC6052"/>.
uPrefix64 facilitates translation into an IPv4 source address to be
used in IGMPv3 Membership Report messages for source-specific
multicast, i.e., by extracting the last 32 bits of IPv6 source
address.</t>
<t>The IGMP Report message is received by the IGMP Querier/Proxy
upstream on the link. (Normally this node is the Broadband Network
Gateway, BNG in broadband networks.) The IGMP Querier/Proxy sends
IGMPv3 Report message to the neighboring routers to join the group.
In networks where PIM is supported, the IGMP Report message may be
received by the PIM Designated Router. The PIM router sends a PIMv4
join message to join an IPv4 group.</t>
<t>The border router that receives the join message translates the
message into MLD. To join an IPv6 group for any-source multicast, the
IPv6 Multicast group address is obtained from the destination address.
For source-specific multicast, the IPv6 source address is generated
after obtaining the IPv4 source address of Membership Report message's
Group Record Source Address field. The BR sends the PIMv6 join
message upstream towards the source.</t>
<t>The BR MUST act as the designated router to which the source of the
source-specific IGMP join message is connected. The BR MUST act as
the rendez-vous point (RP) of the multicast group for the any-source
multicast IGMP join message. Normally there is one such BR in an
operator's network. An IPv4 multicast tree eventually forms in the
network between the CE and BR and an IPv6 multicast tree upstream from
the BR for the same ASM or SSM group.</t>
<t>IPv6 multicast data received at the border router from the source
is translated into IPv4. The last 32 bits of the source and
destination address fields determine the source and destination
addresses of the IPv4 multicast data packet. This packet is sent
downstream on the multicast tree already formed for this IPv4
multicast group.</t>
<t>Multicast data packet address translation follows the rules in
<xref target="I-D.ietf-mboned-64-multicast-address-format"/> for the
multicast group address and <xref target="RFC6052"/> for source-
specific multicast source address, i.e. using uPrefix64. For any-
source multicast, the Border Router inserts an IPv4 source address,
different for each source.</t>
<t>Packet header translation follows the rules in <xref
target="RFC6145"/>. Fragmentation and reassembly are handled as
described in <xref target="RFC6145"/>. After the IPv4 multicast data
packet is sent downstream from the BR it may be fragmented by the
routers.</t>
<t>The CE receives the IPv4 multicast data packet, possibly in
fragments, and reassembles the fragments. The CE translates the IPv4
multicast data packet back to an IPv6 multicast data packet. Address
translation is done following
<xref target="I-D.ietf-mboned-64-multicast-address-format"/> for
multicast group addresses and <xref target="RFC6052"/> for unicast SSM
source addresses. Header translation is done as in
<xref target="RFC6145"/>.</t>
<t>IPv6 multicast data is sent on the home link to the host(s). IEEE
802.3 or IEEE 802.11 multicast link support usually handles this
delivery in Layer 2 without any packet duplication if there are more
than one members to the any-source multicast group or SSM source and
multicast group.</t>
<section anchor="l2transup" title="Solution Based on Layer 2 Multicast Support">
<t>In this section we assume that Layer 2 multicast is supported in
the network. Layer 2 multicast support is done in order to forward
multicast data downstream to the ports of Layer 2 devices, i.e.
switches that requested a multicast group instead of flooding the data
to all the ports.</t>
<t>In the switches, called snooping switches, multicast MAC address
based filters are set up which link layer 2 multicast groups to the
egress ports. IGMP snooping switches are commonly used in operators'
networks, most commonly at the access nodes (AN)
<xref target="RFC6788"/>.</t>
<t> When an IGMP Report message is received, the bridge will set up a
multicast filter entry that allows (in case of a join message) or
prevents (in case of a leave message) packets to flow on the port on
which the IGMP Report message was received. In terms of IPv4
multicast addresses, the mapping is not unique as 32 IPv4 multicast
addresses map to a single Ethernet multicast MAC address
<xref target="RFC4541"/>.</t>
<t>The main functionality of a snooping switch is to forward multicast
data packets based on the filters that are setup, i.e. to those egress
ports with multicast groups downstream and also to the router
ports.</t>
<t>In a 6rd network the snooping switches must detect IGMP packets
sent upstream by the CE and set the filtering rules accordingly. When
IPv4 data packets are received the IGMP snooping switches forward
these packets towards all CEs that have members, effectively achieving
packet duplication at the access node level.</t>
</section> <!-- l2transup -->
<section anchor="analys" title="Analysis">
<t>An analysis of the translation solution reveals the following:\
<list style="symbols">
<t>The translation solution imposes a requirement on the IPv6 source-
specific multicast sources to use uPrefix64 compatible source
addresses. This requirement cannot be satified with simple
configuration of the CPE router and Border Router.</t>
<t>In the case of any-source multicast, the border router must use a
public IPv4 address distinctively to represent each IPv6 any-source
multicast source.</t>
<t>In deployments which use IGMP routers, not PIM routers,
source-specific multicast can be supported only if all routers have
been upgraded to IGMPv3 and no IGMPv1 or IGMPv2 systems are present.
Otherwise the operation reverts to the older version of IGMP to
preserve compatibility and thus SSM can not be supported. With the
use of PIM routers, this is avoided.</t>
<t>The border router must act as the designated router or the rendez-
vous point for the IPv4/IPv6 multicast group and this may lead to the
use of a single border router in the network instead of load sharing
with various border routers.</t>
</list>
</t>
</section> <!-- analys -->
</section> <!-- translop -->
<section anchor="seccons" title="Security Considerations">
<t>6rd Translation Multicast control and data message security are as
described in <xref target="RFC5969"/>. The threats and their
mitigation described in <xref target="RFC5969"/> apply to multicast
communication as well.</t>
</section> <!-- seccons -->
<section anchor="iana" title="IANA Considerations">
<t>TBD.</t>
</section> <!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>We would like to specially thank Mark Townsley for his constructive
comments. Steve Wright's online and very many offline comments helped
us improve the document.</t>
</section> <!-- ack -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC2491;
&RFC2629;
&RFC3376;
&RFC3810;
&RFC4213;
&RFC4286;
&RFC4541;
&RFC4601;
&RFC4605;
&RFC5569;
&RFC5969;
&RFC6052;
&RFC6145;
<reference anchor="I-D.ietf-mboned-64-multicast-address-format">
<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="I-D.ietf-mboned-auto-multicast">
<front>
<title>Automatic Multicast Tunneling (work in progress)</title>
<author initials="G." surname="Bumgardner">
<organization>Cisco</organization>
</author>
<date month="June" year="2012"/>
</front>
</reference>
&I-D.ietf-softwire-dslite-multicast;
<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="February" year="2013"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC3171;
&RFC6788;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:08:28 |