Multicast Support for 6rd
draft-sarikaya-softwire-6rdmulticast-02

Network Working Group                                        B. Sarikaya
Internet-Draft                                                Huawei USA
Intended status: Standards Track                        October 11, 2011
Expires: April 13, 2012

                       Multicast Support for 6rd
              draft-sarikaya-softwire-6rdmulticast-02.txt

Abstract

   This memo specifies modifications required to 6rd so that both IPv6
   hosts can receive multicast data from IPv6 servers.  In AMT based
   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
   Proxy Multicast solution, the protocol is based on proxying MLD at
   the 6rd Customer Edge router and then tunneling MLD messages to 6rd
   Border Relays where IPv6 multicast routing is supported.  Multicast
   data received at 6rd Border Relay is tunneled to 6rd Customer Edge
   node and then delivered to the hosts.  We show that IPv4 multicast
   and IGMP can be supported in a similar way.

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 April 13, 2012.

Copyright Notice

   Copyright (c) 2011 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

Sarikaya                 Expires April 13, 2012                 [Page 1]
Internet-Draft          Multicast Support for 6rd           October 2011

   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.  Proxy Architecture . . . . . . . . . . . . . . . . . . . .  6
   5.  6rd AMT Multicast Operation  . . . . . . . . . . . . . . . . .  7
     5.1.  Modifications to AMT Messages  . . . . . . . . . . . . . .  8
     5.2.  Supporting IPv4 Multicast in 6rd AMT Multicast . . . . . .  9
   6.  6rd Proxy Multicast Operation  . . . . . . . . . . . . . . . . 10
     6.1.  Tunnel Interface Considerations  . . . . . . . . . . . . . 11
     6.2.  Supporting IPv4 Multicast in 6rd Proxy Multicast . . . . . 11
   7.  Solution Based on Layer 2 Multicast Support  . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     11.2. Informative references . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15

Sarikaya                 Expires April 13, 2012                 [Page 2]
Internet-Draft          Multicast Support for 6rd           October 2011

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.

   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.  We also show how IPv4
   multicast can be supported for home IPv4 users.  Both solutions use
   IPv6 and IPv4 multicast addressing and do not require any new
   multicast address prefixes such as IPv4-embedded IPv6 multicast
   addresses to be allocated.

   Automatic IP 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).

   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
   architectures: Automatic IP Multicast tunneling (AMT) and MLD Proxy
   based solutions.  Solution based on Layer 2 multicast support is also
   described for 6rd.

Sarikaya                 Expires April 13, 2012                 [Page 3]
Internet-Draft          Multicast Support for 6rd           October 2011

2.  Terminology

   This document uses the terminology defined in [RFC5969], [RFC5569],
   [RFC3810] and [RFC3376].

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 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 proxy 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
   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

Sarikaya                 Expires April 13, 2012                 [Page 4]
Internet-Draft          Multicast Support for 6rd           October 2011

   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 IP Multicast
   Tunneling 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 April 13, 2012                 [Page 5]
Internet-Draft          Multicast Support for 6rd           October 2011

           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.  Proxy Architecture

   In order to support multicast, CE implements MLD Proxy function
   [RFC4605].  IPv6 hosts send their join requests (MLD Membership
   Report messages) to CE.  CE as a proxy sends aggregated Report
   messages upstream towards BR.

   In order to support SSM, MLDv2 must be supported by the host, CE and
   BR.

   BR is the default multicast querier for CE.  BR implements multicast
   router function or it could be another MLD proxy.

   All the elements of 6rd proxy-based multicast support system are
   shown in Figure 2.

           Dual Stack Hosts                                      IPv4
                  +----+                                        Network
                  | H1 |                 IPv4
                  +----+      +-----+    only       +-------+     +
                  +----+      | CE  |    network    |   BR  |
                  | H2 |   ---| MLD |---         -- |   MLD |    IPv6
                  +----+      |Proxy|               |Querier|   Network
                  +----+      +-----+               +-------+
                  | H3 |
                  +----+

               Figure 2: Architecture of 6rd Proxy Multicast

Sarikaya                 Expires April 13, 2012                 [Page 6]
Internet-Draft          Multicast Support for 6rd           October 2011

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
   data packet encapsulated in UDP packet with IP header.

   CE receives AMT Multicast Data message over the pseudo interface

Sarikaya                 Expires April 13, 2012                 [Page 7]
Internet-Draft          Multicast Support for 6rd           October 2011

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x1  |M|I| Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Discovery Nonce                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   AMT Relay Advertisement message changes include the addition of two

Sarikaya                 Expires April 13, 2012                 [Page 8]
Internet-Draft          Multicast Support for 6rd           October 2011

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x2  |M|I| Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Discovery Nonce                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Relay Address                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.
   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

Sarikaya                 Expires April 13, 2012                 [Page 9]
Internet-Draft          Multicast Support for 6rd           October 2011

   encapsulated IPv4 messages to AMT Gateway.

6.  6rd Proxy 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
   establishes a tunnel interface with a Border Relay.  CE encapsulates
   MLD Membership Report message in IPv6-in-IPv4 tunnel and sends IPv4
   message to BR's IPv4 anycast address, 6rdBRIPv4Address [RFC5969].
   The tunnel is IPv4 based but it will carry IPv6 traffic, MLD messages
   back and forth and IPv6 multicast data messages downstream.  CE gets
   unicast IPv4 address of BR from the first reply containing MLD
   message encapsulated in IPv4 and thereafter uses the BR unicast
   address as long as any multicast state exists.

   6rd CE operation is similar to [RFC6224] but the operation is much
   simpler.  In 6rd environment there is no requirement to handle host
   mobility.  CE does not have to keep more than one tunnel interfaces,
   a single interface is sufficient.  MLD Proxy at the CE does not have
   to have more than one proxy instances, a single instance is
   sufficient.

   CE is regular MLD proxy and it keeps MLD proxy membership database.
   CE inserts multicast forwarding state on the incoming interface, and
   merges state updates into the MLD proxy membership database.  CE
   updates or removes elements from the database as required.  CE will
   then send an aggregated Report via the upstream tunnel to the BR when
   the membership database changes.

   CE answers MLD queries from BR based on the membership database.
   CE's downstream link follows the traditional multipoint channel
   forwarding and does not pose any specific problems.

   CE receives IPv6 multicast data from the BR tunneled over the tunnel
   interface.  CE decapsulates the packet and then forwards it
   downstream.  Each member host receives the data packet based on Layer
   2 multicast interface.  No packet duplication is necessary.

Sarikaya                 Expires April 13, 2012                [Page 10]
Internet-Draft          Multicast Support for 6rd           October 2011

   Border Relay acts as the 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.

   According to aggregated MLD reports received from a CE, BR
   establishes group/source-specific multicast forwarding states at its
   corresponding downstream tunnel interfaces.  After that, BR maintains
   or removes the state as required by the aggregated reports received
   from CE.

   At the upstream interface, 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.

   Multicast traffic arriving at the BR is transparently forwarded
   according to its multicast forwarding information base.  Multicast
   data is first replicated and then forwarded in IPv6-in-IPv4 tunnel
   from BR to the corresponding CE.

6.1.  Tunnel Interface Considerations

   IPv6 in IPv4 tunneling is performed as specified in [RFC4213].
   Considerations specified in [RFC5969] apply.  Packets upstream from
   CE carry only MLD signaling messages and they are not expected to be
   subject to fragmentation.  However packets downstream, i.e. multicast
   data to CE may be subject to fragmentation.

6.2.  Supporting IPv4 Multicast in 6rd Proxy Multicast

   IPv4 multicast can be supported in a way similar to IPv6 as described
   in Section 6. 6rd Customer Edge device has IGMP Proxy function.
   Proxy operation for IGMP [RFC3376] is described in [RFC4605].

   CE receives IGMP join requests from the hosts and then sends
   aggregated IGMP Report messages upstream in an IPv4 in IPv4 tunnel.
   Tunnel addressing is in IPv4 and is as described in [RFC5969].
   Multicast membership database is maintained for all active IPv4
   multicast groups the hosts subscribe.

   6rd Border Relay is IGMP querier or another IGMP Proxy.  It serves
   all CEs downstream and treats its tunnel interfaces as multicast
   enabled downstream links, serving zero to many listening nodes.
   Multicast membership database is maintained based on the aggregated

Sarikaya                 Expires April 13, 2012                [Page 11]
Internet-Draft          Multicast Support for 6rd           October 2011

   Reports received from downstream tunnel interfaces.

   IPv4 multicast data received from the multicast Single Source
   Multicast or Any Source Multicast sources are replicated according to
   the multicast membership database and the data packets are tunneled
   to the CEs that have one of more members of this multicast group.

   CEs receive multicast data upstream in the CE-BR tunnel and
   decapsulate it and then forward the packet downstream.  Each member
   host receive IPv4 multicast data packet from its Layer 2 interface.

7.  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.  When an MLD 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 MLD Report message was received.  In terms of IP multicast
   addresses, the mapping is not unique as 2 ** (112 - 32) IPv6
   multicast addresses map to a single Ethernet multicast MAC address.
   This would be reduced to 32 if allocation policy of using only the
   lower 32 bits in 112 bit group ID field of IPv6 multicast address is
   followed.

   Snooping switches maintain a list of multicast routers and the ports
   on which they are attached called router ports.  For this purpose
   multicast router discovery protocol described in [RFC4286] is used.
   The switch sends an ICMPv6 Multicast Router Solicitation message and
   the router sends ICMPv6 Multicast Router Advertisement message in
   reply.

   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 MLD packets in the
   tunnel between CE and BR as described in Section 6.  This requires
   IPv6 snooping switches to be capable of reading IPv4 protocol field
   values.  A value of 58 indicates that an ICMPv6 packet is

Sarikaya                 Expires April 13, 2012                [Page 12]
Internet-Draft          Multicast Support for 6rd           October 2011

   encapsulated.  A value of 41 indicates that an IPv6 data packet is
   encapsulated.  The fact that MLD packets are ICMPv6 packets
   complicates the operation of snooping switch.  The switch needs to
   look further into the packet to correctly identify an MLD packet.

   In case multicast is supported in Layer 2, BR after receiving a
   multicast data packet does not attempt to replicate the packet.  The
   packet replication is taken care of by the snooping switches.  So
   Layer 2 multicast support avoids packet duplication at the BR which
   could be costly in some cases.

8.  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.

9.  IANA Considerations

   AMT Relay Discovery and AMT Relay Advertisement messages are modified
   as in Section 5.1.

10.  Acknowledgements

   We would like to specially thank Mark Townsley for his constructive
   comments.

11.  References

11.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.

Sarikaya                 Expires April 13, 2012                [Page 13]
Internet-Draft          Multicast Support for 6rd           October 2011

   [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.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

   [I-D.ietf-mboned-auto-multicast]
              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L.,
              Pusateri, T., and T. Morin, "Automatic IP Multicast
              Tunneling", draft-ietf-mboned-auto-multicast-11 (work in
              progress), July 2011.

11.2.  Informative references

Sarikaya                 Expires April 13, 2012                [Page 14]
Internet-Draft          Multicast Support for 6rd           October 2011

Author's Address

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Dr. Building 175
   Plano, TX  75074

   Phone:
   Email: sarikaya@ieee.org

Sarikaya                 Expires April 13, 2012                [Page 15]