idnits 2.17.1 draft-jiang-behave-v4v6mc-proxy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 07, 2011) is 4858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Behave Work Group S. Jiang 2 Internet Draft D. Gu 3 Intended status: Standard Track Huawei Technologies Co., Ltd 4 Expires: July 10, 2011 January 07, 2011 6 Multicast Proxy in IPv6/IPv4 Transition 7 draft-jiang-behave-v4v6mc-proxy-02.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on July 10, 2011. 26 Copyright Notice 28 Copyright (c) 2011 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 During the long co-existing period of IPv6 and IPv4, the 44 interoperation between IPv6 network and IPv4 network is essential. 45 Multicast services across IPv6 and IPv4 networks are also needed. 46 Besides the packet-based multicast translation mechanism, this 47 document describes a multicast proxy solution. The multicast proxy is 48 deployed at the border of IPv6/IPv4 networks. It is mainly based on 49 content cache concept. Without packet-based translation, it retires 50 the content data from IPvX network, caches the data, and multicasts 51 the data in IPvY network. It acts as a multicast leaf in the IPvX 52 network where the data source locates. It also acts as a multicast 53 source in IPvY network where the multicast client locates. 55 Table of Contents 57 1. Introduction.................................................3 58 2. Terminology..................................................3 59 3. Multicast Proxy without packet-based IPv6/IPv4 Translation...3 60 3.1. Overview................................................3 61 3.2. Operation procedure.....................................5 62 4. Security Considerations......................................6 63 5. IANA Considerations..........................................7 64 6. Change Log [RFC Editor please remove]........................7 65 7. References...................................................7 66 7.1. Normative References....................................7 67 7.2. Informative References..................................7 68 Author's Addresses..............................................8 70 1. Introduction 72 The confirmation of IPv4 address exhaustion clearly indicates that 73 global IPv6 deployment is inevitably going to happen. However, it is 74 also widely agreed that IPv4 will be still in use for a long period. 75 During the long co-existing period of IPv6 and IPv4, the 76 interoperation between IPv6 network and IPv4 network is essential. 78 Now, multimedia has been deployed widely, such as IPTV and video 79 conference etc. They also face the IPv6 and IPv4 intercommunication 80 issues. The multicast applications are complicated and face more 81 difficulties than unicast applications deployment. 83 [I-D.draft-venaas-behave-v4v6mc-framework] proposes a packet-based 84 translation framework between IPv4/IPv6 multicast services. It 85 describes the packet-based translation operations and 86 intercommunication in network layer to support a single source send 87 to multiple receivers in different IP networks. 89 Besides the packet-based multicast translation mechanism, this 90 document describes a multicast proxy solution, which is mainly based 91 on content cache. 93 A multicast proxy can be deployed at the border between IPv4/IPv6 94 networks. Without packet-based translation, it retires the content 95 data from IPvX network, caches the data, and multicasts the data in 96 IPvY network. It acts as a multicast leaf in the IPvX network where 97 the data source locates. It also acts as a multicast source in IPvY 98 network where the multicast client locates. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC2119 [RFC2119]. 106 3. Multicast Proxy without packet-based IPv6/IPv4 Translation 108 3.1. Overview 110 Within this document, we describe the network where the data source 111 locates as IPvX network and the network where the multicast client 112 locates as IPvY network. When IPvX is IPv6, IPvY must be IPv4, vice 113 versa. 115 | 116 <----------IPvX---------->|<---------IPvY-----------> 117 | 118 +-----------+ +-----------+ +-----------+ 119 | multicast |------>| multicast |------>| multicast | 120 | source | | proxy | | client | 121 +-----------+ +-----------+ +-----------+ 122 | 123 Figure 1: Multicast proxy Forward Contents to different IP networks 125 As showed in Figure 1, the proposed multicast proxy is deployed at 126 the border of IPv4/IPv6 networks. It MUST support both IPv4 and IPv6. 127 It MUST support both IGMP (Internet Group Management Protocol, 128 [RFC3376]), which is used for IPv4 multicast management functions, 129 and MLD (Multicast Listener Discovery, [RFC3810]), which is used in a 130 similar way in IPv6 Environment. In the IPvX network, the multicast 131 proxy joins the multicast distribution tree as a leaf. In the IPvY 132 network, the multicast proxy broadcasts contents as a multicast 133 source. The establishment of multicast distribution trees obeys the 134 current multicast specifications for each IP family, such as Protocol 135 Independent Multicast (PIM [RFC4601]). 137 Notice that there are two different multicast distribution trees in 138 two sides of the multicast proxy. They are operational independent 139 from each other in the network layer. 141 Logically, they are relevant to each other and there are 142 interoperation behaviors between them. The contents published through 143 the multicast distribution tree in IPvY network inherits from the 144 IPvX network. They are received by the multicast proxy, which is a 145 multicast leaf in the multicast distribution tree in IPvX network. 146 Within the multicast proxy, contents are mapped between receiver 147 function and publisher function. The operations of the multicast 148 distribution tree in IPvY network MAY trigger some operations of the 149 multicast distribution tree in IPvX network. For example, a multicast 150 client joins a multicast group in IPvY network, and requests 151 multicast contents may cause the multicast proxy joins a multicast 152 group in IPvX network. 154 However, as mentioned earlier, in network or IP layer, the two 155 multicast distribution trees are independent from each other. Their 156 operations are separated in two sides of the multicast proxy. 157 Conceptually, the multicast proxy can be presented virtually in 158 functional modules like below Figure 2. 160 <------------IPvX-------------->|<------------IPvY---------------> 161 +-------------------------------+ 162 | +-------------------+ | 163 | |Content cache & mgt| | 164 | +-------------------+ | 165 | / \ | 166 +---------+ | +----------+ +----------+ | +---------+ 167 |multicast| | | proxy | | proxy | | |multicast| 168 | source |-----+>| receiver | | publisher|-+---->| client | 169 | | | | (IPvX) | | (IPvY) | | | | 170 +---------+ | +----------+ +----------+ | +---------+ 171 +-------------------------------+ 172 | 173 Figure 2: Separate function model of multicast proxy 175 As shown in Figure 2, the proxy receiver module in IPvX network joins 176 IPvX multicast groups as a receiver client. Thereby it receives 177 packets bound for the IPvX multicast groups, and then hands the 178 content to the content cache and management module. The content cache 179 and management module then forward the on-demand content to the 180 multicast proxy function module in IPvY network, which acts as a 181 publisher and multicast source in IPvY network. 183 3.2. Operation procedure 185 <-------------IPvX---------------->|<------------IPvY---------------> 186 multicast source multicast proxy multicast client 187 | Content cache & mgt | 188 | proxy receiver | proxy publisher | 189 | | | | | 190 | | | | Join IPvY | 191 | | | |multicast group| 192 | | | Report to mgt |<-----(1)------| 193 | | Send request |<-----(2)------| | 194 |Join IPvX group|<-----(3)------| | | 195 |<-----(4)------| | | | 196 | | | | | 197 | Send IPvX | | | | 198 |multicastpacket| | | | 199 |------(5)----->|Report contents|Divert request&| | 200 | |------(6)----->|Divert contents| Send IPvY | 201 | | |------(7)----->|multicastpacket| 202 | | | |------(8)----->| 203 | | | | | 205 Figure. 3 The interaction communicating from IPvX to IPvY 207 As shown in Figure 3, a client, which locates in IPvY network, 208 connects to the multicast proxy, requesting a multicast service whose 209 source locates in the IPvX network. 211 First, the client sends a join IPvY multicast group report (1) to the 212 multicast proxy. The proxy publisher module, which also locates in 213 the IPvY network, receives this report, then forwards the content 214 request to the content cache & management module (2). The content 215 cache & mgt module maintains a content & multicast service table, 216 including all available multicast services from IPvX network. The 217 content cache & mgt module searches the client request in its 218 dynamically updated table. 220 If the requested content is already multicasted in the IPvY network, 221 the content cache & mgt module diverts the user report back to the 222 proxy publisher module (7). The proxy publisher module adds the new 223 client into its existing multicast tree. Then the requested content 224 can be sent to the client (8). 226 If the requested content is available but not multicasted in IPvY 227 network yet, the content cache & mgt module sends a request to the 228 proxy receiver module, which locates in the IPvX network (3). It 229 initiates the proxy receiver module to send a join IPvX multicast 230 group report (4) to the multicast source. The multicast source adds 231 the multicast proxy into its multicast tree and sends IPvX multicast 232 packets (5). When receiving the multicast packets, the proxy receiver 233 module drops all network layer information, such as IP headers, etc., 234 and only reports contents to the content cache & mgt module (6). The 235 content cache & mgt module then diverts contents to the proxy 236 publisher module (7). The proxy publisher module builds up a new 237 multicast tree in the IPvY network, and sends multicast packets to 238 clients (8). 240 If all the clients, requesting a certain multicast service in the 241 IPvY network, leave the IPvY multicast group, the multicast proxy MAY 242 leave the IPvX multicast group in IPvX network. 244 Multicast proxies MAY also perform load-balancing, user 245 authentication and other additional functions. 247 4. Security Considerations 249 The multicast proxy solution actually separate the IPv4 and IPv6 250 multicast services effectively. It prevents the attacks at only one 251 side of it. 253 However, multicast proxy itself is as vulnerable as normal multicast 254 sources and multicast leafs in each IPv4 or IPv6 environment. The 255 security mechanisms for IGMP/MLD can be used to enhance the security 256 of multicast proxy. 258 5. IANA Considerations 260 This draft does not request any IANA action. 262 6. Acknowledgments 264 The authors would like to thank Stig Venaas, Cisco for his valuable 265 comments. 267 7. Change Log [RFC Editor please remove] 269 draft-jiang-behave-v4v6mc-proxy-00, original version, 2010-03-01 271 draft-jiang-behave-v4v6mc-proxy-01, private discussion and comments 272 from Stig Venaas, 2010-07-09 274 draft-jiang-behave-v4v6mc-proxy-02, regular update, 2011-01-07 276 8. References 278 8.1. Normative References 280 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner and A. 284 Thyagarajan, "Internet Group Management Protocol, Version 285 3", RFC 3376, October 2002. 287 [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery 2 288 (MLDv2) for IPv6", RFC 3810, June 2004. 290 [RFC4601] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, 291 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 292 Specification (Revised)", RFC 4601, August 2006. 294 8.2. Informative References 296 [I-D.draft-venaas-behave-v4v6mc-framework] 297 S. Venaas, X. Li and C. Bao, "Framework for IPv4/IPv6 298 Multicast Translation ", draft-venaas-behave-v4v6mc- 299 framework, working in progress, October 2009. 301 Author's Addresses 303 Sheng Jiang 304 Huawei Technologies Co., Ltd 305 Huawei Building, No.3 Xinxi Rd., 306 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 307 P.R. China 308 Email: shengjiang@huawei.com 310 Dujuan Gu 311 Huawei Technologies Co., Ltd 312 156 Bei-Qing Road, Hai-Dian District, Beijing 100085 313 P.R. China 314 Email: gudujuan@huawei.com