Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track July 16, 2012 Expires: January 17, 2013 Multicast Support for 6rd draft-sarikaya-softwire-6rdmulticast-04.txt Abstract This memo specifies 6rd's multicast component so that IPv6 hosts can receive multicast data from IPv6 servers. In 6rd encapsulation solution, multicast communication is completely integrated into 6rd tunnel. 6rd Customer Edge router is extended with Multicast Listener Discovery (MLD) protocol Proxy entity. MLD Proxy receives join requests from 6rd IPv6 hosts and sends them upstream in 6rd's IPv4 in IPv6 tunnel to 6rd Border Relay (BR). This tunnel is used to exchange MLD messages to establish multicast state at 6rd BR so that 6rd BR can use 6rd's IPv4 in IPv6 tunnel to send IPv6 multicast data to 6rd CEs. At the CEs, multicast data is decapsulated and MLD Proxy delivers it to IPv6 hosts based on MLD group membership state. 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." Sarikaya Expires January 17, 2013 [Page 1] Internet-Draft Multicast Support for 6rd July 2012 This Internet-Draft will expire on January 17, 2013. Copyright Notice 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. Sarikaya Expires January 17, 2013 [Page 2] Internet-Draft Multicast Support for 6rd July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. 6rd Tunneling Architecture . . . . . . . . . . . . . . . . 6 4.2. Translation Architecture . . . . . . . . . . . . . . . . . 6 5. 6rd Tunneling Multicast Operation . . . . . . . . . . . . . . 7 5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 9 5.2. Avalanche Problem . . . . . . . . . . . . . . . . . . . . 9 6. 6rd Translation Multicast Operation . . . . . . . . . . . . . 10 6.1. Solution Based on Layer 2 Multicast Support . . . . . . . 11 6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative references . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Sarikaya Expires January 17, 2013 [Page 3] Internet-Draft Multicast Support for 6rd July 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. In 6rd encapsulation approach, 6rd multicast is integrated into 6rd unicast solution. 6rd customer premise equipment (CPE) is extended to support MLD proxy [RFC4605] which receives MLD Membership Report messages requesting to join a multicast group and tunnels aggregated join requests upstream to the 6rd Border Router (BR) using IPv6 in IPv4 encapsulation. 6rd Border Router is extended to support MLD querrier sends join requests upstream towards the multicast source(s) and becomes part of the multicast tree and thus receives IPv6 multicast data. 6rd Border Router encapsulates IPv6 multicast data using 6rd's IPv6 in IPv4 encapsulation and sends to each member CPE. CPE decapsulates the packet and MLD proxy sends IPv6 multicast data downstream to the member hosts. In the translation approach, native IPv4 multicast support in the network between Customer Edge routers and Border Router can be exploited. Translation protocol requires MLD to IGMP translation at the Customer Edge and IGMP to MLD translation at the border router. Border router needs to translate IPv6 multicast data into IPv4 multicast data and Customer Edge router needs to translate IPv4 multicast data back into IPv6 multicast data. In both approaches, 6rd's CE to CE forwarding feature is not used. Sarikaya Expires January 17, 2013 [Page 4] Internet-Draft Multicast Support for 6rd July 2012 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. 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 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. Sarikaya Expires January 17, 2013 [Page 5] Internet-Draft Multicast Support for 6rd July 2012 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. 6rd Tunneling 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. In order to support multicast, the 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 unicast using IPv6 in IPv4 encapsulation. Dual Stack Hosts IPv4 +----+ Network | H1 | IPv4 +----+ +-----+ only +-------+ + +----+ | CE | network -- | BR | | H2 | ---| MLD |--- IPv6 | MLD | IPv6 +----+ |Proxy| in |Querier| Network +----+ +-----+ IPv4 +-------+ | H3 | Encapsulation +----+ Figure 1: Architecture of 6rd Tunneling Multicast Protocol 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 multicast support system are shown in Figure 1. 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. Sarikaya Expires January 17, 2013 [Page 6] Internet-Draft Multicast Support for 6rd July 2012 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 | +----+ Figure 2: Architecture of 6rd Translation Multicast 5. 6rd Tunneling 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 1. 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. The tunnel is IPv4 based but it will carry IP traffic, MLD messages back and forth and IPv6 multicast data messages downstream. CE is regular MLD proxy and it keeps MLD proxy membership database. CE inserts multicast forwarding state on the incoming interface, and Sarikaya Expires January 17, 2013 [Page 7] Internet-Draft Multicast Support for 6rd July 2012 merges state updates into the MLD proxy membership database. CE updates or remove 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. 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. 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. When BR receives MLD join requests from downstream CEs BR sends PIM join message upstream towards multicast source(s). This results in a multicast tree formation and BR is at the leaf of the multicast tree which enables BR to receive IPv6 multicast data sent by the source. 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 tunnel from BR to the corresponding CE. Sarikaya Expires January 17, 2013 [Page 8] Internet-Draft Multicast Support for 6rd July 2012 5.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 fragmentation. However packets downstream, i.e. multicast data to CE may be subject to fragmentation. Source and destination addresses of MLD messages in IPv6-in-IPv4 tunnel from CE is as follows: Source address of IPv4 header is CE WAN interface IPv4 address, destination address is BR anycast address when an invite message is sent to group G. Subsequent messages to group G contain BR unicast address as destination address. Source address of inner MLD message is the link local address. Destination address is all MLDv2-capable multicast routers or FF02:0: 0:0:0:0:0:16 for MLD Version 2 Multicast Listener Reports. Source and destination addresses of MLD messages in IPv6-in-IPv4 softwire from BR is as follows: Source address of IPv4 header is BR IPv4 unicast address, destination address is CE IPv4 address. Source address of inner MLD message is the link local address, destination address is link-scope all-nodes multicast address, or FF02::1 for General Queries or IPv6 multicast group address for specific queries. Source address of IPv6 multicast data is unicast IPv6 address of the multicast source, e.g. the content provider, destination address is IPv6 multicast group address. 5.2. Avalanche Problem 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 tunneling multicast, 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 colocating it at the access network gateway such as at the Border Network Gateway (BNG) is another possibility. Sarikaya Expires January 17, 2013 [Page 9] Internet-Draft Multicast Support for 6rd July 2012 In 6rd tunneling multicast operation, CEs are enabled to exploit multiple BRs that can be deployed in the network by using BR anycast address anytime 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. 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 1. 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 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 Sarikaya Expires January 17, 2013 [Page 10] Internet-Draft Multicast Support for 6rd July 2012 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. 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. Sarikaya Expires January 17, 2013 [Page 11] Internet-Draft Multicast Support for 6rd July 2012 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 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 Sarikaya Expires January 17, 2013 [Page 12] Internet-Draft Multicast Support for 6rd July 2012 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 6rd Translation 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 TBD. 9. Acknowledgements 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. 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 Sarikaya Expires January 17, 2013 [Page 13] Internet-Draft Multicast Support for 6rd July 2012 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. 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, "IPv6 Multicast Address Format With Embedded IPv4 Multicast Address", draft-ietf-mboned-64-multicast-address-format-02 (work in progress), May 2012. [I-D.ietf-mboned-auto-multicast] Bumgardner, G., "Automatic Multicast Tunneling", draft-ietf-mboned-auto-multicast-14 (work in progress), June 2012. [I-D.ietf-softwire-dslite-multicast] Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Wang, "Multicast Extensions to DS-Lite Technique in Broadband Deployments", draft-ietf-softwire-dslite-multicast-02 (work in progress), May 2012. Sarikaya Expires January 17, 2013 [Page 14] Internet-Draft Multicast Support for 6rd July 2012 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-05 (work in progress), June 2012. Sarikaya Expires January 17, 2013 [Page 15] Internet-Draft Multicast Support for 6rd July 2012 Author's Address Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano, TX 75074 Phone: Email: sarikaya@ieee.org Sarikaya Expires January 17, 2013 [Page 16]