v6ops Work Group S. Jiang Internet Draft D. Gu Intended status: Informational Y. Fu Expires: April 21, 2013 B. Liu Huawei Technologies Co., Ltd October 22, 2012 Multicast Proxy in IPv6/IPv4 Transition draft-jiang-v6ops-v4v6mc-proxy-02 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 April 21, 2013. 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 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. Jiang, et al. Expires April 21, 2013 [Page 1] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 Abstract During the long co-existing period of IPv6 and IPv4, the interoperation between IPv6 network and IPv4 network is essential. Multicast services across IPv6 and IPv4 networks are also needed. Besides the packet-based multicast translation mechanism, this document describes a multicast proxy solution. The solution is a multicast deployment for transition scenario. It does not propose any new protocol or protocol modification/extension for multicast. The multicast proxy is deployed at the border of IPv6/IPv4 networks. It is mainly based on content cache. Without packet-based translation, it acquires the content data from IPvX network, caches the data, and multicasts the data in IPvY network. It acts as a multicast leaf in the IPvX network where the data source locates while acting as a multicast source in IPvY network where the multicast client locates. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. Multicast Proxy without packet-based IPv6/IPv4 Translation .. 3 3.1. Overview ............................................... 3 3.2. Operation procedure .................................... 5 4. Security Considerations ..................................... 6 5. IANA Considerations ......................................... 7 6. Acknowledgments ............................................. 7 7. References .................................................. 7 7.1. Normative References ................................... 7 7.2. Informative References ................................. 7 Author's Addresses ............................................. 8 Jiang, et al. Expires April 21, 2013 [Page 2] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 1. Introduction The deployment of IPv6 is now in progress, and users with no IPv4 access are likely to appear in increasing numbers in the coming years. However, it is also widely agreed that IPv4 will be still in use for a long period. During the long co-existing period of IPv6 and IPv4, the interoperation between IPv6 network and IPv4 network is essential. Now, multimedia has been deployed widely, such as IPTV and video conference etc. They also face the IPv6 and IPv4 intercommunication issues. The multicast applications are complicated and face more difficulties than unicast applications deployment. [I-D.draft-venaas-behave-v4v6mc-framework] proposes a packet-based translation framework between IPv4/IPv6 multicast services. It describes the packet-based translation operations and intercommunication in network layer to support a single source send to multiple receivers in different IP networks. Besides the packet-based multicast translation mechanism, this document describes a multicast proxy solution, which is mainly based on content cache. It is a multicast deployment for IPv6 transition scenario. It doesn't propose any new protocol or protocol modification/extension for multicast. A multicast proxy can be deployed at the border between IPv4/IPv6 networks. Without packet-based translation, it acquires the content data from IPvX network, caches the data, and multicasts the data in IPvY network. It acts as a multicast leaf in the IPvX network where the data source locates while acting as a multicast source in IPvY network where the multicast client locates. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 3. Multicast Proxy without packet-based IPv6/IPv4 Translation 3.1. Overview Within this document, we describe the network where the data source locates as IPvX network and the network where the multicast client Jiang, et al. Expires April 21, 2013 [Page 3] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 locates as IPvY network. When IPvX is IPv6, IPvY must be IPv4, vice versa. | <----------IPvX---------->|<---------IPvY-----------> | +-----------+ +-----------+ +-----------+ | multicast |------>| multicast |------>| multicast | | source | | proxy | | client | +-----------+ +-----------+ +-----------+ | Figure 1: Multicast proxy Forwards Contents to different IP networks As showed in Figure 1, the proposed multicast proxy is deployed at the border of IPv4/IPv6 networks. It MUST support both IPv4 and IPv6. It MUST support both IGMP (Internet Group Management Protocol, [RFC3376]), which is used for IPv4 multicast management functions, and MLD (Multicast Listener Discovery, [RFC3810]), which is used in a similar way in IPv6 Environment. In the IPvX network, the multicast proxy joins the multicast distribution tree as a leaf. In the IPvY network, the multicast proxy broadcasts contents as a multicast source. The establishment of multicast distribution trees obeys the current multicast specifications for each IP family, such as Protocol Independent Multicast (PIM [RFC4601]). Notice that there are two different multicast distribution trees in two sides of the multicast proxy. They are operational independent from each other in the network layer. Logically, they are relevant to each other and there are interoperation behaviors between them. The contents published through the multicast distribution tree in IPvY network inherits from the IPvX network. They are received by the multicast proxy, which is a multicast leaf in the multicast distribution tree in IPvX network. Within the multicast proxy, contents are mapped between receiver function and publisher function. The operations of the multicast distribution tree in IPvY network MAY trigger some operations of the multicast distribution tree in IPvX network. For example, a multicast client joins a multicast group in IPvY network, and requests multicast contents may cause the multicast proxy joins a multicast group in IPvX network. However, as mentioned earlier, in network or IP layer, the two multicast distribution trees are independent from each other. Their operations are separated in two sides of the multicast proxy. Conceptually, the multicast proxy can be presented virtually in functional modules like below Figure 2. Jiang, et al. Expires April 21, 2013 [Page 4] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 <------------IPvX-------------->|<------------IPvY---------------> +-------------------------------+ | +-------------------+ | | |Content cache & mgt| | | +-------------------+ | | / \ | +---------+ | +----------+ +----------+ | +---------+ |multicast| | | proxy | | proxy | | |multicast| | source |-----+>| receiver | | publisher|-+---->| client | | | | | (IPvX) | | (IPvY) | | | | +---------+ | +----------+ +----------+ | +---------+ +-------------------------------+ | Figure 2: Separate function model of multicast proxy As shown in Figure 2, the proxy receiver module in IPvX network joins IPvX multicast groups as a receiver client. Thereby it receives packets bound for the IPvX multicast groups, and then hands the content to the content cache and management module. The content cache and management module then forward the on-demand content to the multicast proxy function module in IPvY network, which acts as a publisher and multicast source in IPvY network. 3.2. Operation procedure <-------------IPvX---------------->|<------------IPvY---------------> multicast source multicast proxy multicast client | Content cache & mgt | | proxy receiver | proxy publisher | | | | | | | | | | Join IPvY | | | | |multicast group| | | | Report to mgt |<-----(1)------| | | Send request |<-----(2)------| | |Join IPvX group|<-----(3)------| | | |<-----(4)------| | | | | | | | | | Send IPvX | | | | |multicastpacket| | | | |------(5)----->|Report contents|Divert request&| | | |------(6)----->|Divert contents| Send IPvY | | | |------(7)----->|multicastpacket| | | | |------(8)----->| | | | | | Figure. 3 The interaction communicating from IPvX to IPvY Jiang, et al. Expires April 21, 2013 [Page 5] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 As shown in Figure 3, a client, which locates in IPvY network, connects to the multicast proxy, requesting a multicast service whose source locates in the IPvX network. First, the client sends a join IPvY multicast group report (1) to the multicast proxy. The proxy publisher module, which also locates in the IPvY network, receives this report, then forwards the content request to the content cache & management module (2). The content cache & mgt module maintains a content & multicast service table, including all available multicast services from IPvX network. The content cache & mgt module searches the client request in its dynamically updated table. If the requested content is already multicasted in the IPvY network, the content cache & mgt module diverts the user report back to the proxy publisher module (7). The proxy publisher module adds the new client into its existing multicast tree. Then the requested content can be sent to the client (8). If the requested content is available but not multicasted in IPvY network yet, the content cache & mgt module sends a request to the proxy receiver module, which locates in the IPvX network (3). It initiates the proxy receiver module to send a join IPvX multicast group report (4) to the multicast source. The multicast source adds the multicast proxy into its multicast tree and sends IPvX multicast packets (5). After receiving the multicast packets, the proxy receiver module extracts the contents while dropping all network layer information, such as IP headers, etc. It then imports the contents to the content cache & mgt module (6). The content cache & mgt module then diverts contents to the correspondent channel of the proxy publisher module (7). The proxy publisher module builds up a new multicast tree in the IPvY network, and sends multicast packets to clients (8). If all the clients, requesting a certain multicast service in the IPvY network, leave the IPvY multicast group, the multicast proxy MAY leave the IPvX multicast group in IPvX network. Multicast proxies MAY also perform load-balancing, user authentication and other additional functions. 4. Security Considerations The multicast proxy solution actually separate the IPv4 and IPv6 multicast services effectively. It prevents the attacks at only one side of it. Jiang, et al. Expires April 21, 2013 [Page 6] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 However, multicast proxy itself is as vulnerable as normal multicast sources and multicast leafs in each IPv4 or IPv6 environment. The security mechanisms for IGMP/MLD can be used to enhance the security of multicast proxy. 5. IANA Considerations This draft does not request any IANA action. 6. Acknowledgments The authors would like to thank Stig Venaas for his valuable comments. 7. References 7.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4601] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Specification (Revised)", RFC 4601, August 2006. 7.2. Informative References [I-D.draft-venaas-behave-v4v6mc-framework] S. Venaas, X. Li and C. Bao, "Framework for IPv4/IPv6 Multicast Translation ", draft-venaas-behave-v4v6mc- framework, working in progress, June 2011. Jiang, et al. Expires April 21, 2013 [Page 7] Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012 Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 P.R. China Email: jiangsheng@huawei.com Dujuan Gu Huawei Technologies Co., Ltd 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 P.R. China Email: gudujuan@huawei.com Yu Fu Huawei Technologies Co., Ltd 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 P.R. China Email: eleven.fuyu@huawei.com Bing Liu Huawei Technologies Co., Ltd 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 P.R. China Email: leo.liubing@huawei.com Jiang, et al. Expires April 21, 2013 [Page 8]