Internet Engineering Task Force H. Asaeda Internet-Draft Keio University Intended status: Informational M. Eubanks Expires: August 19, 2012 AmericaFree.TV T. Tsou Huawei Technologies (USA) S. Venaas Cisco Systems February 16, 2012 Multicast Transition Overview draft-eubanks-mboned-transition-overview-02 Abstract IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another. This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains. 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 August 19, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Asaeda, et al. Expires August 19, 2012 [Page 1] Internet-Draft Multicast Transition Overview February 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. A Look At the Multicast Transition Problem Space . . . . . . . 3 3. A Look At the Solution Space For Multicast Transition . . . . . 4 3.1. AF Forwarding Plane Operation . . . . . . . . . . . . . . . 4 3.2. AF Control Plane Operation . . . . . . . . . . . . . . . . 5 3.3. Source Discovery . . . . . . . . . . . . . . . . . . . . . 5 3.4. Transitional Multicast Path Optimization . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Asaeda, et al. Expires August 19, 2012 [Page 2] Internet-Draft Multicast Transition Overview February 2012 1. Introduction IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another. This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains. Section 2 describes the problem space in detail. This section describes an environment that includes a content provider a customer and an intervening network. Any component of that environment may support only one version of IP or the other. At points where IPv4- only devices interface with IPv6-only devices, an adaptation function is required. Section 3 defines formal requirements for any proposed solution. Section 4 proposes a framework for the solution. 2. A Look At the Multicast Transition Problem Space Historically, IPTV providers have served IPv4 content to consumers over IPv4 multicast networks. CPE has supported IPv4 only. As the Internet transitions to IPv6, IPv6-capable equipment will be deployed by content providers and consumers, as well as the networks that connect them to one another. So long as all of the newly deployed gear supports both IPv4 and IPv6, the transition to IPv6 may not require new IETF protocol specifications. However, if some of the newly deployed gear supports IPv6 only, incompatibilities will be introduced. An incompatibility occurs when two IP-adjacent devices do not support a common version of IP (i.e., one device supports IPv4 only and the other supports IPv6 only). For the purposes of this document, we will call these points of incompatibility "IP version boundaries". The communication path between provider and consumer (which includes both endpoints) can include zero or more IP version boundaries. IP version boundaries may be introduced at any point along the path. These IP version boundaries may reside in the subscriber premises, at the CPE, in the intervening network etc. In addition, the Set Top Box (STB) and Electronic Program Guides (EPG) may have differnt IP Asaeda, et al. Expires August 19, 2012 [Page 3] Internet-Draft Multicast Transition Overview February 2012 versions. In order to maintain multicast connectivity, an adaptation function (AF) is required at each IP version boundary. The AF operates in both the forwarding and control planes. Because it provides an interface between the IPv4 and IPv6 domain, it must be both IPv4- capable and IPv6-capable. In most cases, the adaptation function will translate between IPv4 and IPv6 on both the control and forwarding planes. However, in scenarios where the path between provider and consumer contains multiple IP version boundaries, adaptation function instances may tunnel traffic between one another. 3. A Look At the Solution Space For Multicast Transition The AF operates on both the forwarding and control planes. On the forwarding plane, the AF inserts itself into the forwarding path translating multicast packets from one IP version to the other. On the control plane, the AF translates routing and signaling messages from one protocol to another. On both the forwarding and control plane, the AF can be viewed as a bump-in-the-wire that provides translation services. It provides no services other than translation. 3.1. AF Forwarding Plane Operation The AF accepts packets from one IP version, removes the IP header, and replaces it with an IP Header of the other version. A significant portion of that task is address translation. The address translation strategy used by AF must be algorithmic, stateless and reversible. This is to say that given a particular IPv4 address, any two AF instances will translate it to the same IPv6 address. Furthermore, because the algorithm is reversible, both AF instances can translate the IPv6 address back into the original IPv4 address. [RFC6052] provides an algorithm for translating unicast addresses between IPv4 and IPv6. Likewise [I-D.mboned-64-mcast-addr-fmt] provides an algorithm for multicast address conversion between IPv4 and IPv6. Other issues associated with IP version translation may arise (e.g., fragmentation). The scope of these issues is wider than that of multicast transition. As such issues are identified, they will be resolved in conjunction with appropriate IETF working groups. Asaeda, et al. Expires August 19, 2012 [Page 4] Internet-Draft Multicast Transition Overview February 2012 3.2. AF Control Plane Operation On the control plane, the AF performs the following translations: o IGMPv3 [RFC3376] to MLDv2 [RFC3810]; o PIM [RFC4601] to PIM; o IGMPv3 to PIM; o MLD to PIM; The IGMP-to-MLD translation may be configured to use only IGMPv2 features. It is defined in [draft to come]. The PIM-to-PIM translation translates a PIM message populated with addresses of one IP version to a similar PIM message populated with addresses of the other version. This translation is defined in [draft to come]. 3.3. Source Discovery Multicast requires a mechanism through which a receiver can associate a multicast stream with a multicast group address. The Session Announcement Protocol (SAP, [RFC2974]) is such a mechanism which is still in use in academic environments. AF translation rules for this protocol are also described in [draft to come]. For commercial purposes, different standards development organizations have specified protocols for transmission of electronic program guides. [ID.tsou-multrans-addr-acquisition] specifies the operation of the AF in such an environment [... in a future version of the draft which comes to a conclusion on the best way forward]. 3.4. Transitional Multicast Path Optimization A mechanism to optimize the path to the multicast source for a combination of IPv4 and IPv6 networks is not immediately required, but is a topic for future work. 4. Requirements From the description above, we can distill the following requirements: REQ 1: It must be possible for the receiver to acquire the multicast group address and, where applicable, the unicast source address of the target stream in the IP version that the receiver Asaeda, et al. Expires August 19, 2012 [Page 5] Internet-Draft Multicast Transition Overview February 2012 supports. REQ 2: It must be possible for the receiver to join the multicast distribution tree for the target stream even if the IP version used in the interior of the network to which the receiver is attached is different from the version supported by the receiver. REQ 3: Where local policy permits, it must be possible to extend the multicast distribution tree for a given stream across a network boundary where different IP versions are supported in the two networks separated by that boundary. REQ 4: When the multicast distribution tree for a given stream is extended across multiple network boundaries across one or more of which the IP version changes, it must be possible to avoid multicast routing loops. REQ 5: It must be possible to pass packets belonging to a given multicast stream to all joined receivers, regardless of changes in IP version encountered along the way. REQ 6: Both ASM and SSM technology must be supported. REQ 7: The solution(s) should allow operators to minimize the total incremental cost (investment plus operations during the transitional period)) due to multicast transition. REQ 8: The solution(s) should provide a clear evolutionary path to all-IPv6 operation. 5. Acknowledgements Ron Bonica inspired the writing of this memo and shaped its content. Michael McBride provided useful comments on an intermediate version of this document. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations To come. Asaeda, et al. Expires August 19, 2012 [Page 6] Internet-Draft Multicast Transition Overview February 2012 8. Informative References [I-D.mboned-64-mcast-addr-fmt] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work in Progress)", February 2012. [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. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [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. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [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 Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-0882 Japan Email: asaeda@wide.ad.jp URI: http://www.sfc.wide.ad.jp/~asaeda/ Asaeda, et al. Expires August 19, 2012 [Page 7] Internet-Draft Multicast Transition Overview February 2012 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 Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA Phone: Email: stig@cisco.com Asaeda, et al. Expires August 19, 2012 [Page 8]