Internet Engineering Task Force H. Asaeda Internet-Draft Intended status: Informational M. Eubanks Expires: July 13, 2012 AmericaFree.TV T. Tsou Huawei Technologies (USA) S. Venaas Cisco Systems January 10, 2012 Multicast Transition Overview draft-eubanks-mboned-transition-overview-00 Abstract The transition from IPv4 to IPv6 raises issues for multicast signaling and multicast content distribution. This memo describes the problem and briefly surveys the solution space. 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 13, 2012. 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 Asaeda, et al. Expires July 13, 2012 [Page 1] Internet-Draft Multicast Transition Overview January 2012 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. A Look At the Multicast Transition Problem Space . . . . . . . 3 3. A Look At the Solution Space For Multicast Transition . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Asaeda, et al. Expires July 13, 2012 [Page 2] Internet-Draft Multicast Transition Overview January 2012 1. Introduction The transition from IPv4 to IPv6 presents challenges for multicast operation. It is common in practice to encounter differences between IP versions supported along the path between the source and the receiver, with some nodes only supporting IPv4, some IPv6, for both multicast and unicast. [ID.jaclee-behave-v4v6-mcast-ps] illustrates the different end-to-end configurations that can occur during transition (and identifies the most likely ones) while exploring the problem of multicast transition for IPTV applications in particular. The reason that the draft concentrates on IPTV is that this application is encountering multicast transition issues in the present and these are likely to intensify in the near future. In this document, "multicast transition" will specifically refer to transitions between IPv4 and IPv6 or vice versa, including networks with multiple transitions, say from IPv4 to IPv6 and back to IPv4, and a "multicast domain" will refer to a network or sub-network supporting one or both variants of Internet multicast. Note that networks may support both versions of the Internet protocol without supporting multicast in both versions, and so multicast transitions may be required even in cases where end-to-end unicast transport is supported. The present memo provides a quick survey of the problem space and the possible solutions, as an aid to further discussion of the topic of multicast transition. 1.1. Requirements Language This document contains no requirements language. 2. A Look At the Multicast Transition Problem Space As [ID.jaclee-behave-v4v6-mcast-ps] points out, in common practice multicast video transport actually happens in three stages. First, the receiver has to acquire the address(es) that it needs to request a particular multicast stream. It always needs to learn the multicast group address or addresses. If source-specific multicast (SSM) is deployed, it also needs to learn the associated unicast source address for each multicast group address. Existing arrangements to support this acquisition process will in some cases need modification to ensure that the receiver acquires the address(es) in the IP version that it understands. Following address acquisition, the receiver uses multicast signaling to request delivery of the user-selected multicast stream or streams. The key issue at this stage is that each time the multicast signaling Asaeda, et al. Expires July 13, 2012 [Page 3] Internet-Draft Multicast Transition Overview January 2012 crosses a boundary between a network supporting one IP version and a network supporting the other, the address(es) designating the requested multicast stream need to be remapped to the new version. This is required in all cases for the group addresses, and also for unicast source addresses for SSM. In addition, in the particular case where there is a transition at the receiver itself, protocol interworking between IGMP ([RFC2236], [RFC3376]) and MLD ([RFC2710], [RFC3810]) may be necessary. Even in the case where the receiver shares a link with a (dual stack) multicast router, such interworking may be considered to occur internally in the multicast router as an intermediate step. The creation of multicast trees in response to multicast signaling relies on the use of reverse path forwarding (RPF) to avoid the creation of routing loops; this is also required in networks performing transitions between multicast domains. In the face of address remapping, it has been suggested that each network along the path from source to receiver needs to know the ultimate source address for RPF to work. Thus, part of the multicast transition problem is to make sure that this information is available at the appropriate point in the routing process, or to devise an alternative means for doing this that would avoid routing loops without end to end source discovery. The final stage of multicast acquisition is the actual delivery of packets of multicast content, i.e., the flooding of data down the multicast trees. Again, address mapping is required across each IP version boundary. The source and group addresses appearing in the one network must be replaced by corresponding source and group addresses in the other IP version before the packet can be forwarded for its next stage of travel. Address remapping across IP version boundaries is required in all three stages of acquisition of a multicast stream. [ID.venaas-behave-v4v6mc-framework] examines the issue of translation between IPv4 and IPv6 multicast addresses in various scenarios. In many cases of practical interest, stateless mapping is possible. A key point is that address mapping requires coordination both in space and in time. To ensure that the multicast stream requested is the one delivered, the same address(es), or a unique mapping of those addresses, must be used to designate the stream at any given point, whether at the stage of address acquisition, multicast signaling, or multicast content delivery. Moreover, coordination between successive multicast domains in the path is required to ensure that the address(es) requested by the receiver are mapped in the source network to the stream that the user wishes to acquire. In stateless mapping, the network must ensure that two streams that might be Asaeda, et al. Expires July 13, 2012 [Page 4] Internet-Draft Multicast Transition Overview January 2012 requested by a given user are not given the same address(es) at the same time; this is more difficult when transitioning into an IPv4 domain given the smaller range of address space available in IPv4. 3. A Look At the Solution Space For Multicast Transition Consistently with the problem space overview, the multicast transition problem divides naturally into three parts: 1. providing a multicast group and possibly unicast source address to the receiver in the IP version supported by the receiver; 2. mediating the exchange of multicast signaling and content between the receiver and its network when the two support different IP versions; 3. mediating the exchange of multicast signaling and content between two networks supporting different IP versions along the path between the source and the receiver. Problem 1 is addressed in [ID.tsou-multrans-addr-acquisition]. In the IPTV case, the key element in the solution for address acquisition (discovery) is the processing of the electronic program guide (EPG) that provides the receiver with the multicast group and possibly the unicast source addresses it needs to request specific program instances. Three possible strategies are considered: o recognition and conversion of unsupported-IP-version addresses at the receiver after it receives the EPG, through a protocol exchange with a mapping function in the network; o interception and remapping of addresses in the EPG as necessary by the network to which the receiver is attached, before the receiver receives information from the EPG; o administrative modification of the EPG in advance of acquisition, either to provide the specific version required by each receiver or to carry addresses in both versions in a form that allows the receiver to select the version it supports. Problem 2 is addressed in [ID.zhou-multrans-af1-specification]. That draft uses the term "Type 1 Adaptation Function" (AF1) for a mediating function between the receiver and the network. This function has two parts: translating the multicast access signaling (IGMP or MLD) to the signaling appropriate to the other IP version (MLD or IGMP respectively), and modifying incoming packets of content to the version supported by the receiver. These packets may need Asaeda, et al. Expires July 13, 2012 [Page 5] Internet-Draft Multicast Transition Overview January 2012 either header translation or decapsulation, depending on the deployment. Difficulties in evolution of the decapsulation option with the transition to all-IPv6 operation are noted. Problem 3 is addressed in [ID.taylor-multrans-af2-specification]. Here the term "Type 2 Adaptation Function" (AF2) is used for the function required. Again, this function operates both on multicast signaling and multicast content. On the signaling side, the function maps the addresses contained in PIM messages from one IP version to the other. With respect to content, depending on deployment, the AF2 either encapsulates or translates the headers of incoming packets of multicast content before forwarding them toward the receiver. A basic tool required for all of these problems is a method to map consistently between IPv4 and IPv6 versions of the source and group addresses. [RFC6052] provides the necessary mapping for the unicast source addresses, if present. [ID.boucadair-behave-64-multicast-address-format] provides a stateless solution for the mapping between IPv4 and IPv6 multicast addresses. [ID.softwire-dslite-multicast] is essentially an applicability statement, showing the application of the AF1, AF2, and address mapping to the particular case where DS-Lite is deployed. AF1 is located in the "multicast B4" (mB4), along with the unicast DS-Lite B4 function, at the customer edge. AF2 is located in the "multicast AFTR" at the border between the IPv6 network to which the customer is attached and the IPv4 network containing the source. The draft specifies the use of encapsulation of multicast content across the IPv6 network. [ID.xu-softwire-mesh-multicast] deals with the particular case where a multicast-capable network provides a transit service between other multicast-capable networks of differing IP versions. Its interaction with the proposed AF2 functionality requires further study. 4. Acknowledgements Ron Bonica inspired the writing of this memo and shaped its content. 5. IANA Considerations This memo includes no request to IANA. Asaeda, et al. Expires July 13, 2012 [Page 6] Internet-Draft Multicast Transition Overview January 2012 6. Security Considerations To come. 7. Informative References [ID.boucadair-behave-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work in progress)", October 2011. [ID.jaclee-behave-v4v6-mcast-ps] Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. Tsou, "IPv4-IPv6 Multicast: Problem Statement and Use Cases (Work in progress)", November 2011. [ID.softwire-dslite-multicast] Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y. Lee, "Multicast Extensions to DS-Lite Technique in Broadband Deployments (Work in progress)", October 2011. [ID.taylor-multrans-af2-specification] Taylor, T. and C. Zhou, "Specification of an Adaptation Function Between Two Multicast Networks Supporting Different IP Versions (Work in progress)", December 2011. [ID.tsou-multrans-addr-acquisition] Tsou, T., "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions (Work in progress)", December 2011. [ID.venaas-behave-v4v6mc-framework] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation (Work in progress)", June 2011. [ID.xu-softwire-mesh-multicast] Xu, M., Cui, Y., Yang, S., Metz, C., and G. Shepherd, "Softwire Mesh Multicast (Work in progress)", July 2011. [ID.zhou-multrans-af1-specification] Zhou, C. and T. Taylor, "Specification of a Provider- Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version (Work in progress)", December 2011. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. Asaeda, et al. Expires July 13, 2012 [Page 7] Internet-Draft Multicast Transition Overview January 2012 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Authors' Addresses Hitoshi Asaeda Phone: Email: asaeda@sfc.wide.ad.jp Marshall Eubanks AmericaFree.TV P.O. Box 141 Clifton, VA 20124 USA Phone: Email: marshall.eubanks@gmail.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: Tina.Tsou.Zouting@huawei.com Asaeda, et al. Expires July 13, 2012 [Page 8] Internet-Draft Multicast Transition Overview January 2012 Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA Phone: Email: stig@cisco.com Asaeda, et al. Expires July 13, 2012 [Page 9]