Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track T. Kiviniemi Expires: July 11, 2013 CSC January 7, 2013 Multicast Support for NAT64 draft-sarikaya-behave-mcast4nat64-07.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 11, 2013. Copyright Notice Copyright (c) 2013 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 Sarikaya & Kiviniemi Expires July 11, 2013 [Page 1] Internet-Draft Multicast for NAT64 January 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. NAT64 Multicast Operation . . . . . . . . . . . . . . . . . . 5 5.1. Address Translation . . . . . . . . . . . . . . . . . . . 5 5.1.1. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast Addresses . . . . . . . . . . . . . . . 6 5.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 7 5.2.1. Differences with IP/ICMP Translation . . . . . . . . . 8 5.2.2. PIM versus IGMP . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Sarikaya & Kiviniemi Expires July 11, 2013 [Page 2] Internet-Draft Multicast for NAT64 January 2013 1. Introduction With IPv4 address depletion on the horizon, many techniques are being standardized for IPv6 migration including NAT64 [RFC6146]. NAT64 together with DNS64 [RFC6147] and the translation algorithm [RFC6145] enables IPv6-only hosts to communicate with IPv4-only servers. NAT64 currently supports only unicast communication [RFC6146], [RFC6145], [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 [RFC6146], [RFC6145], [RFC6052], [I-D.ietf-mboned-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.ietf-mboned-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. 4. Architecture We consider an IPv6 only host (Host 1, H1) that wishes to receive Sarikaya & Kiviniemi Expires July 11, 2013 [Page 3] Internet-Draft Multicast for NAT64 January 2013 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 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 Sarikaya & Kiviniemi Expires July 11, 2013 [Page 4] Internet-Draft Multicast for NAT64 January 2013 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. This implies that NAT64 multicast translator may be hosted in a different network element than NAT64 unicast translator [RFC6146]. 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 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 2 [RFC4291], [RFC3306], [RFC3956]. | 8 | 4 | 4 | 4 | 76 | 32 | +--------+----+----+----+------------------------------+----------+ |11111111|0111|scop|1000| sub-group-id |v4 address| +--------+----+----+----+-----------------------------------------+ Sarikaya & Kiviniemi Expires July 11, 2013 [Page 5] Internet-Draft Multicast for NAT64 January 2013 Figure 2: ASM_MPREFIX64 Formation 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 FF3x00008x::/96 as the SSM prefix. This prefix is referred to as SSM_PREFIX64 Figure 3. | 8 | 4 | 4 | 16 | 4 | 60 | 32 | +--------+----+----+-----------+----+------------------+----------+ |11111111|0011|scop|00.......00|1000| sub-group-id |v4 address| +--------+----+----+-----------+----+------------------+----------+ Figure 3: 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 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.1.1. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast Addresses The hosts 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.sarikaya-softwire-6man-raoptions] describes a Router Sarikaya & Kiviniemi Expires July 11, 2013 [Page 6] Internet-Draft Multicast for NAT64 January 2013 Advertisement based method which is suitable for mobile hosts accessing 3GPP networks. 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 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. 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]. Sarikaya & Kiviniemi Expires July 11, 2013 [Page 7] Internet-Draft Multicast for NAT64 January 2013 5.2.1. Differences with IP/ICMP Translation The Stateless IP/ICMP translation [RFC6145] is designed for unicast communication. IP/ICMP Translation uses a different address translation than multicast address translation described Section 5.1. However some parts of IP/ICMP Translation can be used in multicast translation. In this section we describe the differences of IP/ICMP Translation with NAT64 translation. IP/ICMP Translation translates IPv4 packets into IPv6 using minimum MTU size of 1280 bytes. However in DVB-IPTV data streams, 1364 byte IPv6 packets need to be supported. NAT64 translator must perform IPv6 path MTU discovery and set the MTU size accordingly, not necessarily always to 1280 byte MTU size. Note that IPv4 routers must not send ICMPv4 error message in response to a multicast packet [RFC1812] while in IPv6 this is not the case which enables path MTU discovery for multicast. Path MTU values are kept in the translator for each multicast group. However, for SSM, a different MTU value MUST be kept for each SSM channel. IP/ICMP Translation does not require transport layer checksum modifications because the prefixes used in IP/ICMP Translation are checksum neutral. NAT64 translator 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. 5.2.2. PIM versus IGMP To handle joining and leaving IPv4 multicast groups, PIM client instead of IGMPv3 client as mentioned in Section 4 can be used. With IGMPv3, SSM support requires that all neighboring routers support IGMPv3. If they support IGMPv1 or IGMPv2 the translator has to also support IGMPv1 or IGMPv2 for compatibility and as a result, SSM could not be supported. SSM can be supported with a PIM Client at the translator. There are other advantages of having PIM client at the translator. PIM can communicate with neighboring IPv4 routers over flexible connections. The need to enable IGMP in the neighboring routers is removed if PIM is used. On the other hand, IGMP, being a simpler protocol than PIM, is more widely supported. IGMP does not need to know the location of rendezvous points (RP) which makes it easier to configure the translator. Sarikaya & Kiviniemi Expires July 11, 2013 [Page 8] Internet-Draft Multicast for NAT64 January 2013 6. Security Considerations Security considerations for IPv4 interface of the translator is similar to [RFC6146] and the considerations stated there apply. 7. IANA Considerations TBD. 8. Acknowledgements TBD. 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. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [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 Sarikaya & Kiviniemi Expires July 11, 2013 [Page 9] Internet-Draft Multicast for NAT64 January 2013 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. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 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 With Embedded IPv4 Multicast Address", draft-ietf-mboned-64-multicast-address-format-04 (work in progress), August 2012. 9.2. Informative references [I-D.sarikaya-softwire-6man-raoptions] Sarikaya, B., "IPv6 RA Options for Translation Multicast Prefixes", draft-sarikaya-softwire-6man-raoptions-00 (work in progress), August 2012. [Thesis] Teemu Kiviniemi, Helsinki University of Technology, Master's Thesis, "Implementation of an IPv4 to IPv6 Multicast Translator", October 2009. Sarikaya & Kiviniemi Expires July 11, 2013 [Page 10] Internet-Draft Multicast for NAT64 January 2013 Authors' Addresses Behcet Sarikaya Huawei USA 5340 Legacy Drive, Suite 175 Plano, TX 75074 Phone: +1 469-277-5700 Email: sarikaya@ieee.org Teemu Kiviniemi CSC Phone: Email: teemu.kiviniemi@csc.fi Sarikaya & Kiviniemi Expires July 11, 2013 [Page 11]