V6OPS Work Group S. Jiang Internet Draft D. Gu Intended status: Standard Stack Huawei Technologies Co., Ltd Expires: August 27, 2010 March 1, 2010 Multicast Proxy in IPv6/IPv4 Transition draft-jiang-behave-v4v6mc-proxy-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 27, 2010. Copyright Notice Copyright (c) 2010 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 BSD License. Jiang & Gu Expires August 27, 2010 [Page 1] Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010 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 multicast translation mechanism, this document describes a multicast proxy solution. The multicast proxy is deployed at the border of IPv6/IPv4 networks. It acts as a multicast leaf in the network that the data source locates. It also acts as a multicast source in other IP network. Without translation, it multicasts the data retrieved and cached from different IP network. Table of Contents 1. Introduction................................................3 2. Terminology.................................................3 3. Multicast Proxy without IPv6/IPv4 Translation...............3 3.1. Overview...............................................3 3.2. Operation procedure....................................5 4. Security Considerations.....................................5 5. IANA Considerations.........................................5 6. Change Log [RFC Editor please remove].......................5 7. References..................................................5 7.1. Normative References...................................5 7.2. Informative References.................................6 Author's Addresses.............................................6 Jiang & Gu Expires August 27, 2010 [Page 2] Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010 1. Introduction The confirmation of IPv4 address exhaustion clearly indicates that global IPv6 deployment is inevitably going to happen. 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 translation framework between IPv4/IPv6 multicast services. It describes the translation operations and intercommunication in network layer to support a single source send to multiple receivers in different IP networks. Besides the multicast translation mechanism, this document describes a multicast proxy solution, which is conceptually similar to an application-level gateway. A multicast proxy can be deployed at the border between IPv4/IPv6 networks. It acts as a multicast leaf in the network that the data source locates. It also acts as a multicast source in other IP network. Without translation, it multicasts the data retrieved and cached from different IP network. 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 IPv6/IPv4 Translation 3.1. Overview | <----------IPvX---------->|<---------IPvY-----------> | +-----------+ +-----------+ +-----------+ | multicast |------>| multicast |------>| multicast | | source | | proxy | | client | +-----------+ +-----------+ +-----------+ Jiang & Gu Expires August 27, 2010 [Page 3] Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010 | Figure 1: Multicast proxy Forward 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 is one multicast distribution tree in each sides of the multicast proxy. 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, in network or IP layer, they are independent from each other. Conceptually, the multicast proxy can be presented virtually like below Figure 2. | <------------IPvX-------------->|<------------IPvY---------------> | +---------+ +----------+ +-----------+ +---------+ |multicast| |multicast | mapping | multicast | |multicast| | source |---->| proxy |-------->| proxy |---->| client | | | |(Receiver)| interop |(Publisher)| | | +---------+ +----------+ +-----------+ +---------+ | Figure 2: Separate function model of multicast proxy Jiang & Gu Expires August 27, 2010 [Page 4] Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010 3.2. Operation procedure A client, locates in IPvY network, connects to the multicast proxy, requesting a multicast service whose source locates in IPvX network. The multicast proxy maintains a multicast service table, including available multicast services from itself and IPvX network. The multicast proxy searches the client request in its multicast service table. If the requested multicast service is from IPvX network, the multicast proxy connects to the multicast source in IpvX network and requesting the service on behalf of the client. When a second client in IPvY network requests the same multicast service, the multicast proxy can provide the service without any additional operation. If all the clients, requesting a certain multicast service in IPvY network, leave the multicast group in IPvY network, the multicast proxy MAY leave the multicast group in IPvX network. Multicast Proxy MAY also perform load-balancing, authentication and caching 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. 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. Change Log [RFC Editor please remove] draft-jiang-behave-v4v6mc-proxy-00, original version, 2010-03-01 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. Jiang & Gu Expires August 27, 2010 [Page 5] Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010 [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, October 2009. Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836081 Email: shengjiang@huawei.com Dujuan Gu Huawei Technologies Co., Ltd 156 Bei-Qing Road, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-59723287 Email: gudujuan@huawei.com Jiang & Gu Expires August 27, 2010 [Page 6]