Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track January 12, 2011 Expires: July 16, 2011 Multicast Support for NAT64 draft-sarikaya-behave-mcast4nat64-00.txt Abstract This memo specifies modifications required to NAT64 so that IPv6 only hosts can receive multicast data from IPv4 only servers. The protocol is based on translating IPv4 multicast data before delivering it to the host in IPv6. The protocol also allows IPv6 only host to join IPv4 any source/ source specific multicast group in IPv6 using Multicast Listener Discovery protocol. 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 July 16, 2011. 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 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 Sarikaya Expires July 16, 2011 [Page 1] Internet-Draft Multicast for NAT64 January 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. NAT64 Multicast Operation . . . . . . . . . . . . . . . . . . 5 5.1. Address Translation . . . . . . . . . . . . . . . . . . . 5 5.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative references . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Sarikaya Expires July 16, 2011 [Page 2] Internet-Draft Multicast for NAT64 January 2011 1. Introduction With IPv4 address depletion on the horizon, many techniques are being standardized for IPv6 migration including NAT64 [I-D.ietf-behave-v6v4-xlate-stateful]. NAT64 together with DNS64 [I-D.ietf-behave-dns64] and the translation algorithm [I-D.ietf-behave-v6v4-xlate] enables IPv6-only hosts to communicate with IPv4-only servers. NAT64 currently supports only unicast communication [I-D.ietf-behave-v6v4-xlate-stateful], [I-D.ietf-behave-v6v4-xlate], [RFC6052]. With the advent of IPTV and Mobile IPTV, there is a need to provide support for multicast communication as well. The document continues in Section 3 with a set of requirements on a solution for NAT64 multicast support. In Section 4 the architecture is presented. Multicast translation protocol is explained in Section 5. 2. Terminology This document uses the terminology defined in [I-D.ietf-behave-v6v4-xlate-stateful], [I-D.ietf-behave-v6v4-xlate], [RFC6052], [I-D.boucadair-behave-64-multicast-address-format], [RFC3810] and [RFC3376]. 3. Requirements This section states requirements on NAT64 translation protocol. The protocol MUST support IPv4-embedded IPv6 multicast addresses as defined in [I-D.boucadair-behave-64-multicast-address-format]. The translation protocol MUST enable an IPv6 only host to join IPv4 multicast groups where IPv6 only host identifies IPv4 groups using IPv4-embedded IPv6 multicast addresses. Both any source multicast (ASM) and source specific multicast (SSM) MUST be supported. In IPv4 network, Protocol Independent Multicast routing MAY be supported. In IPv4 network, Internet Group Management Protocol routing MAY be supported. User Datagram Protocol (UDP) MUST be supported. Transmission Control Protocol (TCP) MAY be supported. Sarikaya Expires July 16, 2011 [Page 3] Internet-Draft Multicast for NAT64 January 2011 4. Architecture We consider an IPv6 only host (Host 1, H1) that wishes to receive multicast data sent to IPv4 multicast groups, sent by an IPv4 only host (Host 2, H2). Multicast data sent to an IPv4 multicast group such as 232.1.2.3 must be translated into an IPv6 multicast group data such as FF3E::232.1.2.3. So a translator element is needed in the architecture. The translator has to be connected simultaneously into IPv4 network and IPv6 network. +---------------------------+ +---------------+ | | | | |IPv6 network +-------+ | IPv4 | | | +-----+ |IGMPv3 | | Network | | |--| MLD | |Client | -- | | | | +-----+ +-------+ | +----+ | | +----+ | +------+ |--- | H2 | | | | H1 |---| | PIM | | +----+ | | +----+ | +------+ | 232.1.2.3 | |FF3E:: | +-----------+ | | | 232.1.2.3|----- |Translator |---- | | | | +-----------+ | | | | | | | +---------------------------+ +---------------+ Figure 1: Key elements of NAT64 Multicast Translator In order to receive multicast data, the host H1 must first subscribe to the multicast group of interest. In IPv6 this is done using MLD protocol [RFC3810] by sending MLD Membership Report message indicating the group address which should have an IPv4 multicast group address embedded such as FF3E::232.1.2.3. MLD entity has to communicate the group membership information to an entity that supports wide-area multicast routing protocol such as PIM [RFC3973], [RFC4601], [RFC5015]. PIM supports both IPv4 and IPv6. IPv4 group address in MLD membership Report message should be communicated to an entity that supports IGMP protocol [RFC3376]. So an IGMP Client is needed to handle joining and leaving IPv4 multicast groups by sending IGMPv3 Report messages to IPv4 network. Once IGMP Client subscribes to an IPv4 multicast group, all IPv4 multicast packets can be received from the interface connected to IPv4 network. The translator translates such packets into IPv6 multicast data packets and forwards them to IPv6 network which delivers it to IPv6 hosts that have joined the corresponding IPv6 multicast group. All the elements of NAT64 multicast translation system are shown in Figure 1. Not shown in the figure are MLD Proxies which are located Sarikaya Expires July 16, 2011 [Page 4] Internet-Draft Multicast for NAT64 January 2011 in Host 1's first hop router. MLD Proxy optimizes MLD operation by providing only aggregate multicast group membership information to the upstream MLD router and duplicating multicast data at a place close to the hosts. Note that the architecture in Figure 1 is generic and does not prescribe any solution as to where in a real network the different components can be hosted or whether the architecture can be duplicated in the same network. While in unicast communication multiple NAT64 boxes can be supported in an operator's network using multiple Pref64s, in multicast NAT64 the same does not hold because IPv6 only hosts do not send multicast data. The elements in the architecture in Figure 1 are best placed in where the designated MLD router/ querier is hosted. In broadband networks Broadband Network Gateway (BNG), in 3GPP networks Packet Data Network Gateway (P-GW) are the candidates for such a placement. 5. NAT64 Multicast Operation In this section we specify how the host can receive IPv4 multicast data from IPv4-only content provider based on the architecture defined in Section 4. The reverse translation of IPv6 multicast data for IPv4-only receivers is out of scope. Multicast translation involves address translation defined in Section 5.1 and protocol (IPv4 to IPv6) translation defined in Section 5.2. 5.1. Address Translation IPv6-only H1 will join IPv4 multicast group by sending MLD Membership Report message upstream towards the MLD entity in Figure 1. H1 MUST use synthesized IPv6 address of IPv4 multicast group address using 64 Multicast Address Format [I-D.boucadair-behave-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. In both ASM_MPREFIX64 and SSM_MPREFIX64, S bit MUST be set to 1 to indicate that the multicast flows are to be transported in native IPv6 and IPv4-IPv6 Interconnection Function is a translator as in Figure 1. IPv6 Embedded-RP ASM_MPREFIX64 values are formed by setting R bit to 1 and P and T bits to 1. This yields FFFE1::/96 as the only IPv6 Embedded-RP ASM_MPREFIX64 value. For non-embedded cases, R bit must be set to zero. This gives two different ASM_MPREFIX64 values of Sarikaya Expires July 16, 2011 [Page 5] Internet-Draft Multicast for NAT64 January 2011 FF4E1::/96 and FF5E1::/96 [RFC4291], [RFC3306], [RFC3956]. Each translator is assigned a unique ASM_MPREFIX64 prefix. The hosts can learn this value by means out of scope with this document. With this, the host can easily create an IPv6 multicast address from the IPv4 group address a.b.c.d that it 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 FF7E1::/96 as the unique SSM prefix. This prefix is referred to as SSM_PREFIX64. Since SSM translation requires a unique address for each IPv4 multicast source, an IPv6 unicast prefix must be configured to the translator 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 entity in the translator. The translator 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.2. Protocol Translation Translator, after processing the addresses will then translate IPv4 multicast data packet into an IPv6 multicast data packet. The destination address is IPv6 group address ASM_MPREFIX64::a.b.c.d and source address is the translator's IPv6 interface address. The value in Type of Service (TOS) field of IPv4 packet is copied into IPv6 Traffic Class field. IPv4 Protocol and TTL fields are copied into IPv6 Next Header and Hop Limit fields respectively. IPv4 payload is copied into IPv6 payload. UDP checksum is updated which completes the packet translation process [Thesis]. The packet is sent towards the host and on its way it may be duplicated for each member of this group and then sent to the individual host separately. Sarikaya Expires July 16, 2011 [Page 6] Internet-Draft Multicast for NAT64 January 2011 Any IPv4 fragments sent by the routers must be translated into IPv6 packets with IPv6 Fragment Header. Fragmentation Offset field is copied into the corresponding field in the Fragment Header. 16-bit Identification field is copied into the low-order 16 bits of IPv6 Fragment Header Identification field. The high-order bits of the 32- bit IPv6 Fragment Header Identification field are set to zero. More Fragments (MF) flag is copied to the corresponding field in IPv6 Fragment Header [Thesis]. Multicast translation described in this section is not specific to the hosts. Translator gets the join message from the host and then updates the membership database. Translator and any MLD Proxies downstream have to know all members of each IPv4 group so that they can correctly duplicate the data packets and deliver to the individual hosts. Also this prefix must be routed towards the translator on the IPv6 network, to enable reverse path forwarding for multicast, and to inform other PIM routers about the correct destination for PIM (S,G) Join messages [Thesis]. 6. Security Considerations Security considerations for IPv4 interface of the translator is similar to [I-D.ietf-behave-v6v4-xlate-stateful] and the considerations stated there apply. 7. IANA Considerations TBD. 8. Acknowledgements Many ideas especially those stated in protocol translation section of this document have been adopted from Teemu Kiviniemi, the author of [Thesis]. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sarikaya Expires July 16, 2011 [Page 7] Internet-Draft Multicast for NAT64 January 2011 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 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. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [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. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-11 (work in progress), October 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Sarikaya Expires July 16, 2011 [Page 8] Internet-Draft Multicast for NAT64 January 2011 October 2010. [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in progress), September 2010. [I-D.boucadair-behave-64-multicast-address-format] Boucadair, M., Qin, J., and Y. Lee, "IPv4-Embedded IPv6 Multicast Address Format", draft-boucadair-behave-64-multicast-address-format-00 (work in progress), December 2010. 9.2. Informative references [Thesis] Teemu Kiviniemi, Helsinki University of Technology, Master's Thesis, "Implementation of an IPv4 to IPv6 Multicast Translator", October 2009. Sarikaya Expires July 16, 2011 [Page 9] Internet-Draft Multicast for NAT64 January 2011 Author's Address Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Sarikaya Expires July 16, 2011 [Page 10]