Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track March 25, 2012
Expires: September 26, 2012
Multicast Support for 6rd
draft-sarikaya-softwire-6rdmulticast-03.txt
Abstract
This memo specifies 6rd's multicast component so that IPv6 hosts can
receive multicast data from IPv6 servers. In AMT based encapsulation
solution, AMT Gateway at the 6rd Customer Edge router uses AMT
protocol to establish a tunnel interface with AMT Relay at the 6rd
Border Relay and this tunnel is used to exchange MLD messages to
establish multicast state at AMT Relay so that AMT Relay can tunnel
IPv6 multicast data to IPv6 hosts connected to AMT Gateway. In 6rd
Translation Multicast based solution, the protocol is based on
proxying MLD at the 6rd Customer Edge router and then translating MLD
messages to IGMP messages and sending them upstream to a network
which supports IPv4 multicast. 6rd Border Relay is multicast router
and IGMP-MLD translator. It translates IGMP join back to MLD join
message and sends it to multicast source. IPv6 Multicast data
received at 6rd Border Relay is translated into IPv4 multicast data
and then sent to IPv4 multicast tree downstream to 6rd Customer Edge
which translates back to IPv6 multicast data then delivers to the
hosts.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2012.
Copyright Notice
Sarikaya Expires September 26, 2012 [Page 1]
Internet-Draft Multicast Support for 6rd March 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. AMT Architecture . . . . . . . . . . . . . . . . . . . . . 5
4.2. Translation Architecture . . . . . . . . . . . . . . . . . 6
5. 6rd AMT Multicast Operation . . . . . . . . . . . . . . . . . 7
5.1. Modifications to AMT Messages . . . . . . . . . . . . . . 8
5.2. Supporting IPv4 Multicast in 6rd AMT Multicast . . . . . . 10
5.3. Avalanche Problem . . . . . . . . . . . . . . . . . . . . 10
6. 6rd Translation Multicast Operation . . . . . . . . . . . . . 10
6.1. Solution Based on Layer 2 Multicast Support . . . . . . . 12
6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative references . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Sarikaya Expires September 26, 2012 [Page 2]
Internet-Draft Multicast Support for 6rd March 2012
1. Introduction
With IPv4 address depletion on the horizon, many techniques are being
standardized for IPv6 migration including 6rd [RFC5969]. 6rd enables
IPv6 hosts to communicate with external hosts using IPv4 only legacy
ISP network. 6rd Customer Edge (CE) device's LAN side is dual stack
and WAN side is IPv4 only. CE tunnels IPv6 packets received from the
LAN side to 6rd Border Relays (BR) after encapsulating IPv6 packet in
an IPv4 packet. BRs have anycast IPv4 addresses and receive
encapsulated packets from CEs over a virtual interface. 6rd operation
is stateless. Packets are received/ sent independent of each other
and no state needs to be maintained.
It should be noted that there is no depletion problem for IPv4
address space allocated for any source multicast and source specific
multicast [RFC3171]. This document is not motivated by the depletion
of IPv4 multicast addresses.
6rd as defined in [RFC5969] and [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.
Automatic Multicast Tunneling (AMT) enables the host(s) in an AMT
site to connect to an AMT Relay which is a multicast router in the
multicast infrastructure [I-D.ietf-mboned-auto-multicast]. The
network between an AMT site and Relay is not multicast enabled and is
seen as non-broadcast multi-access (NBMA) link layer [RFC2491].
When an AMT gateway receives an MLD join message to an Any-Source
Multicast (ASM) or Source-Specific Multicast (SSM) group, it first
discovers an AMT Relay using Anycast Relay IP address. Using a three
way handshake, the gateway sends MLD membership report message in a
UDP tunnel to the relay. Relay joins the source in the multicast
infrastructure and sends multicast data downstream to all member
gateways in a UDP tunnel. When a gateway has no membership state,
i.e. after all member hosts leave the group(s), its state with the
relay expires and the gateway can start relay discovery all over
again. Periodically the relay and gateway exchage AMT Query and AMT
Membership Update messages. All AMT control messages are secured
using message authentication codes (MAC)
[I-D.ietf-mboned-auto-multicast].
AMT works for both IPv4 using IGMP and IPv6 using MLD. IGMP messages
are encapsulated in IPv4 using UDP encapsulation and MLD messages are
encapsulated in IPv6 using UDP encapsulation.
In this document we address 6rd multicast problem and propose two
Sarikaya Expires September 26, 2012 [Page 3]
Internet-Draft Multicast Support for 6rd March 2012
architectures: Automatic Multicast tunneling (AMT) and translation
based solutions. Layer 2 multicast support for the translatiom
solution is also described.
2. Terminology
This document uses the terminology defined in [RFC5969], [RFC5569],
[RFC3810], [RFC3376] and [I-D.ietf-softwire-dslite-multicast].
3. Requirements
This section states requirements on 6rd multicast support protocol.
IPv6 hosts connected to 6rd CE router MUST be able to join multicast
groups in IPv6 and receive multicast data.
Both any source multicast (ASM) and source specific multicast (SSM)
MUST be supported.
6rd multicast MUST NOT introduce the need to use IPv4 addresses
thereby contributing to the public IPv4 address depletion.
6rd CE MAY support AMT gateway as defined in
[I-D.ietf-mboned-auto-multicast]. Modifications to AMT protocol
defined in this document applies.
6rd BR MAY support AMT relay as defined in
[I-D.ietf-mboned-auto-multicast]. Modifications to AMT protocol
defined in this document applies.
In case of translation solution, 6rd CE MUST support MLD Proxy as
defined in [RFC4605]. 6rd CE MAY support IGMP Proxy.
In case of proxy solution, 6rd BR MUST support MLD Querier. 6rd CE
MAY support IGMP Querier.
4. Architecture
In 6rd, there are hosts (possibly IPv4/ IPv6 dual stack) served by
6rd Customer Edge device. CE is dual stack facing the hosts and IPv4
only facing the network or WAN side. At the boundary of the network
there is 6rd Border Relay. BR receives IPv6 packets tunneled in IPv4
from CE and decapsulates them and sends them out to IPv6 network.
Unicast 6rd is stateless. Each IPv6 packet sent by CE treated
Sarikaya Expires September 26, 2012 [Page 4]
Internet-Draft Multicast Support for 6rd March 2012
separately and different packets from the same CE may go to different
BRs. CE encapsulates IPv6 packet in IPv4 with destination address
set to BR address (usually anycast IPv4 address). BRs are placed
where IPv6 native connectivity exists. BR receives the encapsulated
packet and decapsulates and send it to IPv6 network. CEs are
configured with 6rd Prefixes from ISPs prefix and with a number of BR
IPv4 addresses. Each host is given a prefix which contains 6rd
Prefix and the host's IPv4 prefix. BR receives IPv6 packets
addressed to this ISP and from the destination address it extracts
the destination host's IPv4 address and uses this address as
destination address and encapsulates the IPv6 packet in IPv4 and
sends it to IPv4-only network.
6rd considers IPv4-only network as an NBMA link from IPv6 point of
view and all 6rd CEs and BRs are defined as off-link neighbors from
one other.
4.1. AMT Architecture
6rd network lends itself easily to the Automatic Multicast Tunneling
(AMT) architecture. Dual stack hosts connected to the Customer Edge
router is an AMT site and it is multicast enabled. IPv4 only network
is the unicast only network. At the boundary of the network 6rd
Border Relay is connected to the native multicast backbone
infrastructure.
We place AMT Gateway at the CE router instead of at the hosts. CE
router serves all the connected hosts. For multicast traffic, CE
Router has an AMT pseudo-interface that serves as a default multicast
route. It is a tunneling interface.
AMT Relay is placed at 6rd BR. AMT Relay also has a pseudo-
interface. A given relay and all CEs (AMT Gateways) connected to it
can be considered to be on a separate logical NBMA link. On this
link, gateways and relay communicate using AMT protocol to transmit
and receive multicast control messages for membership management and
multicast data from the relay to the gateways.
All the elements of 6rd multicast support system with AMT are shown
in Figure 1.
AMT protocol is designed to provide IPv6 multicast to the hosts in
AMT site using AMT messages in IPv6. AMT protocol is designed to
provide IPv4 multicast to the hosts in AMT site using AMT messages in
IPv4. However, in 6rd the network is IPv4 only. We need to modify
it to use IPv4 AMT protocol to transmit IPv6 multicast messages such
as MLD messages and IPv6 multicast data.
Sarikaya Expires September 26, 2012 [Page 5]
Internet-Draft Multicast Support for 6rd March 2012
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +-------+ only +-----+ +
+----+ | CE | network | BR |
| H2 | ---| AMT |--- -- | AMT | IPv6
+----+ |Gateway| |Relay| Network
+----+ +-------+ +-----+
| H3 |
+----+
Figure 1: Architecture of 6rd AMT Multicast
4.2. Translation Architecture
In order to support multicast, CE implements MLD Proxy [RFC4605] and
MLD to IGMP translation function. IPv6 hosts send their join
requests (MLD Membership Report messages) to CE. CE as a proxy sends
aggregated IGMP Report messages upstream towards BR.
In order to support SSM, MLDv2 and IGMPv3 MUST be supported by the
host, CE and BR.
BR is the default multicast querier for CE. BR implements IGMP to
MLD translation function and multicast router function or it could be
another MLD proxy.
It is assumed that IPv4 only network to which CE and BR are connected
supports native IPv4 multicast.
All the elements of 6rd translation-based multicast support system
are shown in Figure 2.
Dual Stack Hosts IPv4
+----+ Network
| H1 | IPv4
+----+ +----------------+ only +------------------+
+----+ | CE MLD | network |IGMP BR | +
| H2 | ---| MLD IGMP |-----------| MLD MLD | IPv6
+----+ |Proxy Translator| |Translator Querier| Network
+----+ +----------------+ +------------------+
| H3 |
+----+
Sarikaya Expires September 26, 2012 [Page 6]
Internet-Draft Multicast Support for 6rd March 2012
Figure 2: Architecture of 6rd Translation Multicast
5. 6rd AMT Multicast Operation
When a host (H1, H2 or H3 in Figure 1) wants to join an IPv6
multicast group, it sends an MLD report (MLDv2 report for a source-
specific group) to CE router. CE router uses one of 6rdBRIPv4Address
values (anycast address of BR) this CE router is configured with.
CE sends AMT Relay Discovery IPv4 message which is a UDP message sent
to a IANA reserved AMT port, e.g. 2268. In the payload of this
message CE MUST set the M bit to indicate that CE will encapsulate
MLD messages in IPv4. Note that all UMT messages are UDP messages.
BR (topologically closest to this CE router) receives the message and
replies with AMT Relay Advertisement UDP message in IPv4. BR checks
to see if it can provide IPv6 multicast service and if yes it replies
with AMT Relay Advertisement message. BR MUST set the M bit to
indicate that it can provide IPv6 multicast service.
CE receives AMT Relay Advertisement message. CE now has BR's unicast
address which it uses to send all multicast packets for this session.
CE sends AMT Request message to BR's unicast address to begin the
process of joining IPv6 multicast group. CE initializes a timer used
to send periodic requests.
BR sends AMT Query message. In this message an MLD Listener Query
message is encapsulated [I-D.ietf-mboned-auto-multicast] with an IP
header.
CE receives AMT Query message and responds by sending AMT Membership
Update message. This message encapsulates MLD Membership Report
message with an IP header to request BR to join IPv6 multicast group
the host wants to join.
BR receives AMT Membership Update message and it adds the tunnel to
the CE in its outgoing interface list for the group that the host
wants to join. BR will send a join message towards the source of the
multicast group to build a multicast tree in the native multicast
infrastructure.
After the initial three way handshake, periodically AMT Membership
Query and AMT Membership Update messages are exchanged between BR and
CE. As for multicast data, the data packets from the source received
at BR will be replicated to all interfaces in it's outgoing interface
list as well as the tunnel outgoing interface for all member CEs. BR
sends multicast data in AMT Multicast Data messages to CE with the
Sarikaya Expires September 26, 2012 [Page 7]
Internet-Draft Multicast Support for 6rd March 2012
data packet encapsulated in UDP packet with IP header.
CE receives AMT Multicast Data message over the pseudo interface
associated with the tunnel to BR. CE forwards the packet to the
outgoing interfaces joined by the hosts.
Another host wants to join another IPv6 multicast group, three-way
handshake involving AMT Request/ AMT Membership Query and AMT
Membership Update is needed but AMT Relay Discovery/ AMT Relay
Advertisement messages are not needed.
5.1. Modifications to AMT Messages
This specification uses AMT messages as defined in
[I-D.ietf-mboned-auto-multicast] except the changes stated in this
section.
AMT Relay Discovery message changes include the addition of two
flags, M and I flags. AMT gateway uses these flags to negotiate MLD
(IGMP) message transmission in IPv4 (IPv6).
A summary of the AMT Relay Discovery message format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=1 |M|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The protocol version number
Type
The type of the message
M Flag
Set to 1 if AMT Gateway wants to send MLD messages encapsulated in
IPv4
I Flag
Set to 1 if AMT Gateway wants to send IGMP messages encapsulated
in IPv6
Sarikaya Expires September 26, 2012 [Page 8]
Internet-Draft Multicast Support for 6rd March 2012
Reserved
A 22-bit reserved field. Sent as 0, ignored on receipt.
Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the
relay.
AMT Relay Advertisement message changes include the addition of two
flags, M and I flags. AMT relay uses these flags to let AMT Gateway
know if AMT Relay is capable of MLD (IGMP) message transmission in
IPv4 (IPv6).
A summary of the AMT Relay Advertisement message format is shown
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=2 |M|I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The protocol version number
Type
The type of the message
M Flag
Set to 1 if AMT Gateway wants to send MLD messages encapsulated in
IPv4
I Flag
Set to 1 if AMT Gateway wants to send IGMP messages encapsulated
in IPv6
Reserved
A 22-bit reserved field. Sent as 0, ignored on receipt.
Discovery Nonce
A 32-bit random value generated by the gateway and replayed by the
relay.
Sarikaya Expires September 26, 2012 [Page 9]
Internet-Draft Multicast Support for 6rd March 2012
Relay Address
The unicast IPv4 address of the AMT relay.
5.2. Supporting IPv4 Multicast in 6rd AMT Multicast
IPv4 multicast can be supported in a way similar to IPv6 using AMT
architecture as described in Section 5. 6rd Customer Edge device has
AMT Gateway function as described in [I-D.ietf-mboned-auto-multicast]
with no extensions. IPv4 hosts connected to AMT Gateway send and
receive IGMP messages [RFC3376] to AMT Gateway which uses AMT
protocol to subscribe the multicast groups with AMT Relay at 6rd
Border Relay. AMT Relay sends IPv4 multicast data in UDP
encapsulated IPv4 messages to AMT Gateway.
5.3. Avalanche Problem
As in Section 5, 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 there are very large number
of downstream member CEs such as in IPTV application, see Appendix A
in [I-D.ietf-softwire-dslite-multicast].
In 6rd multicast, avalanche problem can be avoided by careful network
partitioning. More BRs can be deployed in areas where IPv6 users are
increasing in numbers. Deploying BRs colocating it at the access
network gateway such as at the Border Network Gateway (BNG) is
another possibility.
6. 6rd Translation Multicast Operation
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 Figure 2.
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.
Customer Edge device is MLD Proxy. After receiving the first MLD
Report message requesting subscription to an IPv6 multicast group, CE
translates MLD Membership Report message into IGMP Membership report
message and sends it upstream only if joining a new group is needed.
Address translation in generating IGMP Membership report message is
done as follows: Destination address is copied from the last 32 bits
Sarikaya Expires September 26, 2012 [Page 10]
Internet-Draft Multicast Support for 6rd March 2012
of IPv6 multicast group address. CE inserts IPv4 address of its WAN
interface into the source address. It is assumed that IPv6 multicast
group address in MLD Report message conforms to the addressing scheme
described in [I-D.ietf-mboned-64-multicast-address-format], i.e. for
any-source and source-specific multicast address format.
Source addresses in MLDv2 payload are translated as follows:
Multicast source addresses in MLD Membership Report message MUST use
uPrefix64, i.e. 64:ff9b::/96 defined in [RFC6052]. uPrefix64
facilitates translation into IPv4 source address to be used in IGMPv3
Membership Report message for source-specific multicast, i.e. by
extracting the last 32 bits of IPv6 source address.
IGMP Report message is received by IGMP Querier/Proxy upstream on the
link (normally this node is Broadband Network Gateway, BNG in
broadband networks). IGMP Querier/Proxy sends IGMPv3 Report message
to the neighboring routers to join the group. In networks where PIM
is supported, IGMP Report message may be received by PIM Designated
Router. PIM router sends PIMv4 join message to join IPv4 group.
The border router that receives the join message translates the
message into MLD. IPv6 Multicast group address is obtained from the
destination address to join IPv6 group for any-source multicast. For
source-specific multicast, IPv6 source address is generated after
obtaining IPv4 source address of Membership Report message's Group
Record Source Address field. BR sends PIMv6 join message upstream
towards the source.
BR MUST act as the designated router to which the source of the
source-specific IGMP join message is connected. 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 CE and BR and IPv6 multicast tree upstream from BR
for the same ASM or SSM group.
IPv6 multicast data received from the source at the border router is
translated into IPv4. The last 32 bits of the source and destination
address fields determine the source and destination addresses of IPv4
multicast data packet. This packet is sent downstream on the
multicast tree already formed for this IPv4 multicast group.
Multicast data packet address translation follows the rules in
[I-D.ietf-mboned-64-multicast-address-format] for the multicast group
address and [RFC6052] for source-specific multicast source address,
i.e. using uPrefix64. For any-source multicast, Border Router
inserts an IPv4 source address, different for each source.
Sarikaya Expires September 26, 2012 [Page 11]
Internet-Draft Multicast Support for 6rd March 2012
Packet header translation follows the rules in [RFC6145].
Fragmentation and reassembly are handled as described in [RFC6145].
After IPv4 multicast data packet is sent downstream from BR it may be
fragmented by the routers.
CE receives IPv4 multicast data packet, possibly in fragments and
reassembles the fragments. CE translates IPv4 multicast data packet
back to IPv6 multicast data packet. Address translation is done
following [I-D.ietf-mboned-64-multicast-address-format] for multicast
group addresses and [RFC6052] for unicast SSM source addresses.
Header translation is done as in [RFC6145].
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.
6.1. Solution Based on Layer 2 Multicast Support
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.
In the switches called snooping switches, multicast MAC address based
filters are setup 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)
[I-D.ietf-6man-lineid].
When an IGMP Report message is received, the bridge will setup a
multicast filter entry that allows (in case of a join message) or
prevents (in case of a leave message) packets to flow 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 [RFC4541].
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.
In a 6rd network the snooping switches MUST detect IGMP packets sent
upstream by 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
Sarikaya Expires September 26, 2012 [Page 12]
Internet-Draft Multicast Support for 6rd March 2012
packet duplication at the access node level.
6.2. Analysis
An analysis of the translation solution reveals the following:
Translation solution imposes a requirement on the IPv6 source-
specific multicast sources to use uPrefix64 compatible source
addresses. This requirement can not be satified with simple
configuration of the CPE router and Border Router.
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.
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.
Border router must act as the designated router or the rendez-vous
point for 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.
7. Security Considerations
All AMT control messages are secured using Message Authentication
Code (MAC) that is a cryptographic hash of a private secret, the
originators address, and the request nonce. AMT data messages are
not secured. 6rd Proxy Multicast control and data message security
are as described in [RFC5969]. The threats and their mitigation
described in [RFC5969] apply to multicast communication as well.
8. IANA Considerations
AMT Relay Discovery and AMT Relay Advertisement messages are modified
as in Section 5.1.
9. Acknowledgements
We would like to specially thank Mark Townsley for his constructive
comments. Steve Wright's online and very many offline comments
Sarikaya Expires September 26, 2012 [Page 13]
Internet-Draft Multicast Support for 6rd March 2012
helped us improve the document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Sarikaya Expires September 26, 2012 [Page 14]
Internet-Draft Multicast Support for 6rd March 2012
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[I-D.ietf-mboned-64-multicast-address-format]
Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
M. Xu, "IPv4-Embedded IPv6 Multicast Address Format",
draft-ietf-mboned-64-multicast-address-format-01 (work in
progress), February 2012.
[I-D.ietf-mboned-auto-multicast]
Bumgardner, G. and T. Morin, "Automatic Multicast
Tunneling", draft-ietf-mboned-auto-multicast-12 (work in
progress), February 2012.
[I-D.ietf-softwire-dslite-multicast]
Jacquenet, C., Qin, J., Boucadair, M., Wang, Q., and Y.
Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments",
draft-ietf-softwire-dslite-multicast-01 (work in
progress), October 2011.
10.2. Informative references
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
RFC 3171, August 2001.
[I-D.ietf-6man-lineid]
Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
Nordmark, "The Line Identification Destination Option",
draft-ietf-6man-lineid-04 (work in progress), March 2012.
Sarikaya Expires September 26, 2012 [Page 15]
Internet-Draft Multicast Support for 6rd March 2012
Author's Address
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75074
Phone:
Email: sarikaya@ieee.org
Sarikaya Expires September 26, 2012 [Page 16]