Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track July 17, 2012 Expires: January 18, 2013 Multicast Support for 4rd draft-sarikaya-softwire-4rdmulticast-03.txt Abstract This memo specifies 4rd technology's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In 4rd Translation Multicast solution for 4rd and translation variant of MAP, MAP-T, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. 4rd Border Relay does the reverse translation and joins IPv4 multicast group for 4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. In 4rd encapsulation solution for encapsulation variant of MAP, MAP-E, IGMP Proxy at the 4rd Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP Border Relay so that MAP Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP Customer Edge device. 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 January 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Sarikaya Expires January 18, 2013 [Page 1] Internet-Draft Multicast Support for 4rd July 2012 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. 4rd Translation Architecture . . . . . . . . . . . . . . . 5 4.2. Encapsulation Multicast Architecture . . . . . . . . . . . 6 5. 4rd Translation Multicast Operation . . . . . . . . . . . . . 7 5.1. Address Translation . . . . . . . . . . . . . . . . . . . 7 5.1.1. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast Addresses . . . . . . . . . . . . . . . 8 5.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 9 5.3. Supporting IPv6 Multicast in 4rd Translation Multicast . . 10 6. Encapsulation Multicast Operation . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative references . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Sarikaya Expires January 18, 2013 [Page 2] Internet-Draft Multicast Support for 4rd July 2012 1. Introduction With IPv4 address depletion on the horizon, many techniques are being standardized for IPv6 migration including 4rd [I-D.ietf-softwire-map], [I-D.ietf-softwire-4rd]. 4rd enables IPv4 hosts to communicate with external hosts using IPv6 only ISP network. 4rd Customer Edge (CE) device's LAN side is dual stack and WAN side is IPv6 only. CE tunnels/translates IPv4 packets received from the LAN side to 4rd Border Relays (BR). BRs have anycast IPv6 addresses and receive encapsulated/translated packets from CEs over a virtual interface. 4rd operation is stateless. Packets are received/ sent independent of each other and no state needs to be maintained. 4rd as defined in [I-D.ietf-softwire-map] and [I-D.ietf-softwire-4rd] is unicast only. It does not support multicast. In this document we specify how multicast from home IPv4 users can be supported in 4rd. In case IPv6 network is multicast enabled, 4rd can provide multicast service to the hosts using 4rd Multicast Translation based solution. A Multicast Translator can be used that receives IPv6 multicast group management messages in MLD and generates corresponding IPv4 group management messages in IGMP and sends them to IPv4 network in 4rd Border Relay. We use [I-D.ietf-softwire-4rd] for sending IPv6 multicast data in IPv4 to the CE routers. At 4rd CE router another translator is needed to translate IPv6 multicast data into IPv4 multicast data. In case of 4rd variants that use encapsulation such as MAP-E we integrate 4rd multicast into the MAP-E tunnel resulting in a multicast tunneling protocol. Multicast tunneling protocol has the advantage of not requiring multicast enabled IPv6 network between CE routers and MAP (4rd) BRs. When MAP-E CE router receives an IGMP join message to an Any-Source Multicast (ASM) [RFC1112] or Source-Specific Multicast (SSM) group [RFC4607], it sends an aggregated IGMP membership report message in the IPv4-in-IPv6 tunnel to the border relay. MAP-E BR joins the source in the multicast infrastructure and sends multicast data downstream to all member CEs in the IPv4-in-IPv6 tunnel. When a CE has no membership state, i.e. after all member hosts leave the group(s), its state with the BR expires and the CE can send the next join message in anycast. In this document we address 4rd multicast problem and propose two architectures: Multicast Tunneling and Multicast Translation based solutions. Section 2 is on terminology, Section 3 is on requirements, Section 4 is on architecture, Section 5 is on multicast translation protocol, Section 6 is on multicast tunneling protocol Sarikaya Expires January 18, 2013 [Page 3] Internet-Draft Multicast Support for 4rd July 2012 and Section 7 states security considerations. 2. Terminology This document uses the terminology defined in [I-D.ietf-softwire-map], [I-D.ietf-softwire-4rd], [RFC3810] and [RFC3376]. 3. Requirements This section states requirements on 4rd multicast support protocol. IPv4 hosts connected to 4rd CE router MUST be able to join multicast groups in IPv4 and receive multicast data. Any source multicast (ASM) SHOULD be supported and source specific multicast (SSM) MUST be supported. In case of translation solution, 4rd CE MUST support IGMP to MLD translation. 4rd CE MUST be MLD Proxy as defined in [RFC4605]. In case of translation solution, 4rd BR MUST support MLD Querier. 4rd BR MUST support MLD to IGMP translator upstream. MAP (4rd) CE MAY support IGMP Proxy as defined in [RFC4605]. MAP (4rd) BR MAY support IGMP router downstream. 4rd BR may support PIM protocol upstream. 4. Architecture In 4rd, there are hosts (possibly IPv4/ IPv6 dual stack) served by 4rd Customer Edge device. CE is dual stack facing the hosts and IPv6 only facing the network or WAN side. 4rd CE may be local IPv4 Network Address and Port Translation (NAPT) box [RFC3022] by assigning private IPv4 addresses to the hosts. 4rd CEs in the same domain may use shared public IPv4 addresses on their WAN side and if they do they should avoid ports outside of the allocated port set for NAPT operation. At the boundary of the network there is 4rd Border Relay. BR receives IPv4 packets tunneled in IPv6 from CE and decapsulates them and sends them out to IPv4 network. Unicast 4rd is stateless except for the local NAPT at the CE. Each IPv4 packet sent by CE treated separately and different packets from the same CE may go to different BRs or CEs. CE encapsulates IPv4 Sarikaya Expires January 18, 2013 [Page 4] Internet-Draft Multicast Support for 4rd July 2012 packet in IPv6 with destination address set to BR address (usually anycast IPv6 address). BR receives the encapsulated packet and decapsulates and send it to IPv4 network. CEs are configured with domain 4rd Prefixes, IPv6 Prefixes and with an BR IPv6 anycast address. BR receives IPv4 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 IPv4 packet in IPv6 and sends it to IPv6-only network. 4.1. 4rd Translation Architecture In case IPv6 only network is multicast enabled, translation multicast architecture can be used. CE implements IGMP Proxy function [RFC4605] towards the LAN side and MLD Proxy on its WAN interface. IPv4 hosts send their join requests (IGMP Membership Report messages) to CE. CE as a MLD proxy sends aggregated MLD Report messages upstream towards BR. CE replies MLD membership query messages with MLD membership report messages based on IGMP membership state in the IGMP/MLD proxy. BR is MLD querier on its WAN side. On its interface to IPv4 network BR may either have IGMP client or PIM. PIM being able to support both IPv4 and IPv6 multicast should be preferred. BR receives MLD join requests, extracts IPv4 multicast group address and then joins the group upstream, possibly by issuing a PIM join message. IPv4 multicast data received by the BR as a leaf node in IPv4 multicast distribution tree is translated into IPv6 multicast data by the translator using [I-D.ietf-softwire-4rd] and then sent downstream to the IPv6 part of the multicast tree to all downstream routers that are members. IPv6 data packet eventually gets to the CE. At the CE, a reverse [I-D.ietf-softwire-4rd] operation takes place by the translator and then IPv4 multicast data packet is sent to the member hosts on the LAN interface. [I-D.ietf-softwire-4rd] is modified to handle multicast addresses. In order to support SSM, IGMPv3 MUST be supported by the host, CE and BR. For ASM, BR MUST be the Rendezvous Point (RP). 4rd Translation Multicast solution uses the multicast 46 translator in not one but two places in the architecture: at the CE router and at the Border Relay. IPv4 multicast data received at 4rd BR goes through a [I-D.ietf-softwire-4rd] header-mapping into IPv6 multicast data at the BR and another [I-D.ietf-softwire-4rd] header-mapping back to IPv4 multicast data at the CE router. Encapsulation variant of [I-D.ietf-softwire-4rd] is not used. All the elements of 4rd translation-based multicast support system Sarikaya Expires January 18, 2013 [Page 5] Internet-Draft Multicast Support for 4rd July 2012 are shown in Figure 1. Dual Stack Hosts IPv4 +----+ Network | H1 | +----------+ IPv6 +-------------+ | | | CE | | BR | +----+ |Translator| only | Translator | | 4rd | | 4rd | +----+ | | network | |IGMP| + | H2 | ---|IGMP-MLD |--------- -- |MLD | or | IPv6 +----+ | Proxy | |Querier |PIM | Network +----+ +----------+ +-------------+ | H3 | +----+ Figure 1: Architecture of 4rd Translation Multicast 4.2. Encapsulation Multicast Architecture Encapsulation variant of MAP (4rd) (MAP-E) network lends itself easily to the Multicast Tunneling architecture. Dual stack hosts are connected to the Customer Edge router and it is multicast enabled. It is assumed that IPv6 only network is the unicast only network. At the boundary of the network MAP (4rd) Border Relay is connected to the native multicast backbone infrastructure. We place IGMP Proxy at the CE router. CE router serves all the connected hosts. For multicast traffic, CE Router uses MAP (4rd) tunneling interface with MAP (4rd) BR to send/receive IGMP messages using IPv4-in-IPv6 tunnel [RFC2473]. MAP (4rd) BR is IGMP Router towards the CEs and it could be IGMP Router or PIM router upstream. A given relay and all CEs connected to it can be considered to be on a separate logical link. On this link, gateways and relay communicate using IPv4-in-IPv6 tunneling to transmit and receive multicast control messages for membership management and multicast data from the relay to the gateways. All the elements of MAP (4rd) multicast support system with tunneling are shown in Figure 2. Sarikaya Expires January 18, 2013 [Page 6] Internet-Draft Multicast Support for 4rd July 2012 Dual Stack Hosts IPv4 +----+ Network | H1 | IPv6 +----+ +-------+ only +--------------+ + +----+ | CE | network | BR | | H2 | ---| IGMP |--- -- |IGMP | IGMP | IPv6 +----+ | Proxy | |Router| PIM | Network +----+ +-------+ +--------------+ | H3 | +----+ Figure 2: Architecture of 4rd Multicast Tunneling 5. 4rd Translation Multicast Operation In this section we specify how the host can subscribe and receive IPv4 multicast data from IPv4 content providers based on the architecture defined in Figure 1 in two parts: address translation and protocol translation. 5.1. Address Translation IPv4-only H1 will join IPv4 multicast group by sending IGMP Membership Report message upstream towards the IGMP Proxy in Figure 1. MLD Proxy first creates a synthesized IPv6 address of IPv4 multicast group address using IPv4-embedded IPv6 multicast address format [I-D.ietf-mboned-64-multicast-address-format]. ASM_MPREFIX64 for any source multicast groups and SSM_MPREFIX64 for source specific multicast groups are used. Both are /96 prefixes. In both ASM_MPREFIX64 and SSM_MPREFIX64, M bit MUST be set to 1 to indicate that an IPv4 address is embedded in the last 32 bits of the multicast IPv6 address. ASM_MPREFIX64 values are formed by setting flgs bits to make it an embedded RP prefix by setting R bit to 1 and P and T bits to 1 as shown in Figure 3 [RFC4291], [RFC3306], [RFC3956]. | 8 | 4 | 4 | 4 | 76 | 32 | +--------+----+----+----+------------------------------+----------+ |11111111|0111|scop|1000| sub-group-id |v4 address| +--------+----+----+----+-----------------------------------------+ Figure 3: ASM_MPREFIX64 Formation Each translator in the upstream BR is assigned a unique ASM_MPREFIX64 Sarikaya Expires January 18, 2013 [Page 7] Internet-Draft Multicast Support for 4rd July 2012 prefix. CE (MLD Proxy in CE) can learn this value by means out of scope with this document. With this, CE can easily create an IPv6 multicast address from the IPv4 group address a.b.c.d that the host wants to join. Source-Specific Multicast (SSM) can also be supported similar to the Any Source Multicast (ASM) described above. In case of SSM, IPv4 multicast addresses use 232.0.0.0/8 prefix. IPv6 SSM_MPREFIX64 values are formed by setting R bit to zero, P and T bits to 1. This gives FF3x00008x::/96 as the SSM prefix. This prefix is referred to as SSM_PREFIX64 Figure 4. | 8 | 4 | 4 | 16 | 4 | 60 | 32 | +--------+----+----+-----------+----+------------------+----------+ |11111111|0011|scop|00.......00|1000| sub-group-id |v4 address| +--------+----+----+-----------+----+------------------+----------+ Figure 4: SSM_MPREFIX64 Formation Since SSM translation requires a unique address for each IPv4 multicast source, an IPv6 unicast prefix must be configured to the translator in the upstream BR to represent IPv4 sources. This prefix is prepended to IPv4 source addresses in translated packets. The join message from the host for the group ASM_MPREFIX64:a.b.c.d or SSM_MPREFIX64:a.b.c.d or an aggregate join message will be received by MLD querier at the BR. BR as multicast anchor checks the group address and recognizes ASM_MPREFIX64 or SSM_MPREFIX64 prefix. It next checks the last 32 bits is an IPv4 multicast address in range 224/8 - 239/8. If all checks succeed, IGMPv4 Client joins a.b.c.d using IGMP on its IPv4 interface. Joining IPv4 groups can also be done using PIM since PIM supports both IPv4 and IPv6. The advantage of using PIM is that there is no need to enable IGMP support in neighboring IPv4 routers. The advantage of using IGMP is that IGMP is a simpler protocol and it is supported by a wider range of routers. The use of PIM or IGMP is left as an implementation choice. 5.1.1. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast Addresses CE can be pre-configured with Multicast Prefix64 of ASM_MPREFIX64 and SSM_MPREFIX64 that are supported in their network. However automating this process is also desired. [I-D.wing-behave-learn-prefix] suggests several methods including DHCPv6. Sarikaya Expires January 18, 2013 [Page 8] Internet-Draft Multicast Support for 4rd July 2012 A new DHCPv6 option, OPTION_AFT_PREFIX_DHCP, can be defined for this purpose. The option contains IPv6 ASM and SSM prefixes. The host can request these prefixes by sending this option in its request to the DHCP server and the server replies with the option containing the prefixes. After the host gets the multicast prefixes, when an application in the host wishes to join an IPv4 multicast group the host MUST use ASM_MPREFIX64 or SSM_MPREFIX64 and then obtain the synthesized IPv6 group address before sending MLD join message. 5.2. Protocol Translation The hosts will send their subscription requests for IPv4 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 IGMP protocol's host part. Customer Edge device is IGMP Proxy facing the LAN interface. After receiving the first IGMP Report message requesting subscription to an IPv4 multicast group, a.b.c.d, MLD Proxy in the CE's WAN interface synthesizes an IPv6 multicast group address corresponding to a.b.c.d and sends an MLD Report message upstream to join the group. When CE is a NAT or NAPT box assigning private IPv4 addresses to the hosts, IP Multicast requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) stated in [RFC5135] apply to IGMP messages and IPv4 multicast data packets. 4rd BR as MLD router receives/sends MLD messages on its WAN interface. 4rd BR does all corresponding actions on its upstream interface connected to IPv4 network in IGMP/PIM in IPv4. The two sides on the BR share MLD membership state. When 4rd BR receives IPv4 multicast data for an IPv4 group a.b.c.d it [I-D.ietf-softwire-4rd] translates/encapsulates IPv4 packet into IPv6 multicast packet and sends it to IPv6 synthesized address corresponding to a.b.c.d using ASM_MPREFIX64 or SSM_MPREFIX64. The header mapping described in [I-D.ietf-softwire-4rd] Section 4.2 (using Table 1) is used except for mapping the source and destination addresses. In this document we use the multicast address translation described in Section 5.1 and propose it as a complementary enhancement to the translation algorithm in [I-D.ietf-softwire-4rd]. The IP/ICMP translation translates IPv4 packets into IPv6 using minimum MTU size of 1280 bytes (Section 4.1 in [I-D.ietf-softwire-4rd]) but this can be changed for multicast. Path MTU discovery for multicast is possible in IPv6 so 4rd BR can perform Sarikaya Expires January 18, 2013 [Page 9] Internet-Draft Multicast Support for 4rd July 2012 path MTU discovery for each ASM group and use these values instead of 1280. For SSM, a different MTU value MUST be kept for each SSM channel. Because of this 8 bytes added by IPv6 fragment header in each data packet can be tolerated. Since multicast address translation does not preserve checksum neutrality, [I-D.ietf-softwire-4rd] translator/encapsulator at 4rd BR must however modify the UDP checksum to replace the IPv4 addresses with the IPv6 source and destination addresses in the pseudo-header which consists of source address, destination address, protocol and UDP length fields before calculating the new checksum. IPv6 multicast data must be translated back to IPv4 at the 4rd CE (e.g. using Table 2 in Section 4.2 of [I-D.ietf-softwire-4rd]). Such a task is much simpler than the translation at 4rd BR because IPv6 header is much simpler than IPv4 header and IPv4 link on the LAN side of 4rd CE is a local link. The packet is sent on the local link to IPv4 group address a.b.c.d for IPv6 group address of ASM_MPREFIX64: a.b.c.d or SSM_MPREFIX64:a.b.c.d. In case an IPv4 multicast source sends multicast data with the don't fragment (DF) flag set to 1, [I-D.ietf-softwire-4rd] header mapping sets the D bit in IPv6 fragment header before sending the packet downstream as in Fig. 3 in Section 4.2 of [I-D.ietf-softwire-4rd]. This feature of [I-D.ietf-softwire-4rd] preserves the semantics of DF flag at the BR and CE. Because 4rd is stateless, Multicast 4rd should stay faithful to this as much as possible. Border Relay acts as the default multicast querier for all CEs that have established multicast communication with it. In order to keep a consistent multicast state between a CE and BR, CE MUST use the same IPv6 multicast prefixes (ASM_MPREFIX64/ SSM_REFIX64) until the state becomes empty. After that point, the CE may obtain different values for these prefixes, effectively changing to a different 4rd BR. 5.3. Supporting IPv6 Multicast in 4rd Translation Multicast IPv6 multicast can be supported natively in 4rd in case IPv6-only network is multicast enabled. 4rd Customer Edge device has MLD Proxy function. Proxy operation for MLD [RFC3810] is described in [RFC4605]. CE receives MLD join requests from the hosts and then sends aggregated MLD Report messages upstream towards BR. No address or protocol translation is needed at the CE or at the BR. IPv6 Hosts in 4rd domain use any source multicast block FF0X [RFC4291] or source specific multicast block FF3X::8000:0-FF3X::FFFF:FFFF for dynamic Sarikaya Expires January 18, 2013 [Page 10] Internet-Draft Multicast Support for 4rd July 2012 allocation by a host [RFC4607], [RFC3307]. 4rd Border Relay is MLD querier. It serves all CEs downstream. After receiving an MLD join message, BR sends PIM join message upstream to join IPv6 multicast group. Multicast membership database is maintained based on the aggregated Reports received from downstream interfaces in the multicast tree. 4rd Border Relay is a Rendezvous Point (RP) for ASM groups. For SSM, BR MUST support MLDv2. IPv6 multicast data received from the Single Source Multicast or Any Source Multicast sources are replicated according to the multicast membership database and the data packets are sent downstream on the multicast tree and eventually received by the CEs that have one of more members of this multicast group. MLD Proxy in the CE receives multicast data then forwards the packet downstream. Each member host receives IPv6 multicast data packet from its Layer 2 interface. 6. Encapsulation Multicast Operation When a host (H1, H2 or H3 in Figure 2) wants to join an IPv4 multicast group, it sends an IGMP report (IGMPv3 report for a source- specific group) to CE router. CE router uses BR's anycast address this CE router is configured with. CE encapsulates IGMP report messages in IPv6 and sends it over the tunnel to BR in anycast. After CE receives unicast address of BR, it sends all subsequent IGMP messages in unicast. BR (topologically closest to this CE router) receives the message decapsulates it and then lets IGMP router to process it. Upstream an IGMP Join message is sent to subscribe group G or a PIMv4 Join message is sent if PIM is supported. BR establishes membership state for group G. BR sends all related IGMP messages to this CE in unicast using IPv4-in-IPv6 tunneling. CE now has BR's unicast address which it uses to send all multicast packets for group G. If CE receives multiple join messages for the same group G, CE sends an aggregated join message to BR. If CE receives another join message for a different group G', CE encapsulates it and sends it in anycast to the BR. After BR receives IGMP Join message it adds the tunnel to the CE in its outgoing interface list for the group that the host wants to Sarikaya Expires January 18, 2013 [Page 11] Internet-Draft Multicast Support for 4rd July 2012 join. BR will send a join message towards the source of the multicast group to build a multicast tree in the native multicast infrastructure and becomes a leaf node in the multicast tree. As for multicast data, the data packets from the source received at the 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 IPv4-in-IPv6 tunnel to the CE with the data packet encapsulated. CE receives Multicast Data message over the tunnel interface associated with the tunnel to BR. CE forwards the packet IGMP Proxy which in its turn forward the message to the outgoing interfaces joined by the hosts. 7. Security Considerations 4rd Encapsulation Multicast control and data message security can be provided by the security architecture, mechanisms, and services described in [RFC4301], [RFC4302] and [RFC4303]. 4rd Translation Multicast control and data message security are as described in [RFC4607] for source specific multicast. 8. IANA Considerations TBD. 9. Acknowledgements We are grateful to Remi Despres for his contributions to this document. Mohamed Boucadair provided many comments offline that 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. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, Sarikaya Expires January 18, 2013 [Page 12] Internet-Draft Multicast Support for 4rd July 2012 RFC 1112, August 1989. [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. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [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. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Sarikaya Expires January 18, 2013 [Page 13] Internet-Draft Multicast Support for 4rd July 2012 Algorithm", RFC 6145, April 2011. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, S., and T. Murakami, "Mapping of Address and Port (MAP)", draft-ietf-softwire-map-01 (work in progress), June 2012. [I-D.ietf-softwire-4rd] Despres, R., Penno, R., Lee, Y., Chen, G., Jiang, S., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", draft-ietf-softwire-4rd-03 (work in progress), July 2012. [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. 10.2. Informative references [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [I-D.wing-behave-learn-prefix] Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ IPv4 Translator", draft-wing-behave-learn-prefix-04 (work in progress), October 2009. Sarikaya Expires January 18, 2013 [Page 14] Internet-Draft Multicast Support for 4rd 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 18, 2013 [Page 15]