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]