idnits 2.17.1 draft-jiang-v6ops-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 (October 22, 2012) is 4175 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 v6ops Work Group S. Jiang 2 Internet Draft D. Gu 3 Intended status: Informational Y. Fu 4 Expires: April 21, 2013 B. Liu 5 Huawei Technologies Co., Ltd 6 October 22, 2012 8 Multicast Proxy in IPv6/IPv4 Transition 9 draft-jiang-v6ops-v4v6mc-proxy-02 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on April 21, 2013. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 During the long co-existing period of IPv6 and IPv4, the 46 interoperation between IPv6 network and IPv4 network is essential. 47 Multicast services across IPv6 and IPv4 networks are also needed. 48 Besides the packet-based multicast translation mechanism, this 49 document describes a multicast proxy solution. The solution is a 50 multicast deployment for transition scenario. It does not propose 51 any new protocol or protocol modification/extension for multicast. 52 The multicast proxy is deployed at the border of IPv6/IPv4 networks. 53 It is mainly based on content 54 cache. Without packet-based translation, it acquires the content data 55 from IPvX network, caches the data, and multicasts the data in IPvY 56 network. It acts as a multicast leaf in the IPvX network where the 57 data source locates while acting as a multicast source in IPvY 58 network where the multicast client locates. 60 Table of Contents 62 1. Introduction ................................................ 3 63 2. Terminology ................................................. 3 64 3. Multicast Proxy without packet-based IPv6/IPv4 Translation .. 3 65 3.1. Overview ............................................... 3 66 3.2. Operation procedure .................................... 5 67 4. Security Considerations ..................................... 6 68 5. IANA Considerations ......................................... 7 69 6. Acknowledgments ............................................. 7 70 7. References .................................................. 7 71 7.1. Normative References ................................... 7 72 7.2. Informative References ................................. 7 73 Author's Addresses ............................................. 8 75 1. Introduction 77 The deployment of IPv6 is now in progress, and users with 78 no IPv4 access are likely to appear in increasing numbers in the 79 coming years. However, it is also widely agreed that IPv4 will be 80 still in use for a long period. During the long co-existing period of 81 IPv6 and IPv4, the interoperation between IPv6 network and IPv4 82 network is essential. 84 Now, multimedia has been deployed widely, such as IPTV and video 85 conference etc. They also face the IPv6 and IPv4 intercommunication 86 issues. The multicast applications are complicated and face more 87 difficulties than unicast applications deployment. 89 [I-D.draft-venaas-behave-v4v6mc-framework] proposes a packet-based 90 translation framework between IPv4/IPv6 multicast services. It 91 describes the packet-based translation operations and 92 intercommunication in network layer to support a single source send 93 to multiple receivers in different IP networks. 95 Besides the packet-based multicast translation mechanism, this 96 document describes a multicast proxy solution, which is mainly based 97 on content cache. It is a multicast deployment for IPv6 transition 98 scenario. It doesn't propose any new protocol or protocol 99 modification/extension for multicast. 101 A multicast proxy can be deployed at the border between IPv4/IPv6 102 networks. Without packet-based translation, it acquires the content 103 data from IPvX network, caches the data, and multicasts the data in 104 IPvY network. It acts as a multicast leaf in the IPvX network where 105 the data source locates while acting as a multicast source in IPvY 106 network where the multicast client locates. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119 [RFC2119]. 114 3. Multicast Proxy without packet-based IPv6/IPv4 Translation 116 3.1. Overview 118 Within this document, we describe the network where the data source 119 locates as IPvX network and the network where the multicast client 120 locates as IPvY network. When IPvX is IPv6, IPvY must be IPv4, vice 121 versa. 123 | 124 <----------IPvX---------->|<---------IPvY-----------> 125 | 126 +-----------+ +-----------+ +-----------+ 127 | multicast |------>| multicast |------>| multicast | 128 | source | | proxy | | client | 129 +-----------+ +-----------+ +-----------+ 130 | 131 Figure 1: Multicast proxy Forwards Contents to different IP networks 133 As showed in Figure 1, the proposed multicast proxy is deployed at 134 the border of IPv4/IPv6 networks. It MUST support both IPv4 and IPv6. 135 It MUST support both IGMP (Internet Group Management Protocol, 136 [RFC3376]), which is used for IPv4 multicast management functions, 137 and MLD (Multicast Listener Discovery, [RFC3810]), which is used in a 138 similar way in IPv6 Environment. In the IPvX network, the multicast 139 proxy joins the multicast distribution tree as a leaf. In the IPvY 140 network, the multicast proxy broadcasts contents as a multicast 141 source. The establishment of multicast distribution trees obeys the 142 current multicast specifications for each IP family, such as Protocol 143 Independent Multicast (PIM [RFC4601]). 145 Notice that there are two different multicast distribution trees in 146 two sides of the multicast proxy. They are operational independent 147 from each other in the network layer. 149 Logically, they are relevant to each other and there are 150 interoperation behaviors between them. The contents published through 151 the multicast distribution tree in IPvY network inherits from the 152 IPvX network. They are received by the multicast proxy, which is a 153 multicast leaf in the multicast distribution tree in IPvX network. 154 Within the multicast proxy, contents are mapped between receiver 155 function and publisher function. The operations of the multicast 156 distribution tree in IPvY network MAY trigger some operations of the 157 multicast distribution tree in IPvX network. For example, a multicast 158 client joins a multicast group in IPvY network, and requests 159 multicast contents may cause the multicast proxy joins a multicast 160 group in IPvX network. 162 However, as mentioned earlier, in network or IP layer, the two 163 multicast distribution trees are independent from each other. Their 164 operations are separated in two sides of the multicast proxy. 165 Conceptually, the multicast proxy can be presented virtually in 166 functional modules like below Figure 2. 168 <------------IPvX-------------->|<------------IPvY---------------> 169 +-------------------------------+ 170 | +-------------------+ | 171 | |Content cache & mgt| | 172 | +-------------------+ | 173 | / \ | 174 +---------+ | +----------+ +----------+ | +---------+ 175 |multicast| | | proxy | | proxy | | |multicast| 176 | source |-----+>| receiver | | publisher|-+---->| client | 177 | | | | (IPvX) | | (IPvY) | | | | 178 +---------+ | +----------+ +----------+ | +---------+ 179 +-------------------------------+ 180 | 181 Figure 2: Separate function model of multicast proxy 183 As shown in Figure 2, the proxy receiver module in IPvX network joins 184 IPvX multicast groups as a receiver client. Thereby it receives 185 packets bound for the IPvX multicast groups, and then hands the 186 content to the content cache and management module. The content cache 187 and management module then forward the on-demand content to the 188 multicast proxy function module in IPvY network, which acts as a 189 publisher and multicast source in IPvY network. 191 3.2. Operation procedure 193 <-------------IPvX---------------->|<------------IPvY---------------> 194 multicast source multicast proxy multicast client 195 | Content cache & mgt | 196 | proxy receiver | proxy publisher | 197 | | | | | 198 | | | | Join IPvY | 199 | | | |multicast group| 200 | | | Report to mgt |<-----(1)------| 201 | | Send request |<-----(2)------| | 202 |Join IPvX group|<-----(3)------| | | 203 |<-----(4)------| | | | 204 | | | | | 205 | Send IPvX | | | | 206 |multicastpacket| | | | 207 |------(5)----->|Report contents|Divert request&| | 208 | |------(6)----->|Divert contents| Send IPvY | 209 | | |------(7)----->|multicastpacket| 210 | | | |------(8)----->| 211 | | | | | 213 Figure. 3 The interaction communicating from IPvX to IPvY 215 As shown in Figure 3, a client, which locates in IPvY network, 216 connects to the multicast proxy, requesting a multicast service whose 217 source locates in the IPvX network. 219 First, the client sends a join IPvY multicast group report (1) to the 220 multicast proxy. The proxy publisher module, which also locates in 221 the IPvY network, receives this report, then forwards the content 222 request to the content cache & management module (2). The content 223 cache & mgt module maintains a content & multicast service table, 224 including all available multicast services from IPvX network. The 225 content cache & mgt module searches the client request in its 226 dynamically updated table. 228 If the requested content is already multicasted in the IPvY network, 229 the content cache & mgt module diverts the user report back to the 230 proxy publisher module (7). The proxy publisher module adds the new 231 client into its existing multicast tree. Then the requested content 232 can be sent to the client (8). 234 If the requested content is available but not multicasted in IPvY 235 network yet, the content cache & mgt module sends a request to the 236 proxy receiver module, which locates in the IPvX network (3). It 237 initiates the proxy receiver module to send a join IPvX multicast 238 group report (4) to the multicast source. The multicast source adds 239 the multicast proxy into its multicast tree and sends IPvX multicast 240 packets (5). After receiving the multicast packets, the proxy 241 receiver module extracts the contents while dropping all network 242 layer information, such as IP headers, etc. It then imports the 243 contents to the content cache & mgt module (6). The content cache & 244 mgt module then diverts contents to the correspondent channel of the 245 proxy publisher module (7). The proxy publisher module builds up a 246 new multicast tree in the IPvY network, and sends multicast packets 247 to clients (8). 249 If all the clients, requesting a certain multicast service in the 250 IPvY network, leave the IPvY multicast group, the multicast proxy MAY 251 leave the IPvX multicast group in IPvX network. 253 Multicast proxies MAY also perform load-balancing, user 254 authentication and other additional functions. 256 4. Security Considerations 258 The multicast proxy solution actually separate the IPv4 and IPv6 259 multicast services effectively. It prevents the attacks at only one 260 side of it. 262 However, multicast proxy itself is as vulnerable as normal multicast 263 sources and multicast leafs in each IPv4 or IPv6 environment. The 264 security mechanisms for IGMP/MLD can be used to enhance the security 265 of multicast proxy. 267 5. IANA Considerations 269 This draft does not request any IANA action. 271 6. Acknowledgments 273 The authors would like to thank Stig Venaas for his valuable 274 comments. 276 7. References 278 7.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 7.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, June 2011. 301 Author's Addresses 303 Sheng Jiang 304 Huawei Technologies Co., Ltd 305 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 306 P.R. China 307 Email: jiangsheng@huawei.com 309 Dujuan Gu 310 Huawei Technologies Co., Ltd 311 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 312 P.R. China 313 Email: gudujuan@huawei.com 315 Yu Fu 316 Huawei Technologies Co., Ltd 317 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 318 P.R. China 319 Email: eleven.fuyu@huawei.com 321 Bing Liu 322 Huawei Technologies Co., Ltd 323 156 Bei-Qing Road, Hai-Dian District, Beijing 100095 324 P.R. China 325 Email: leo.liubing@huawei.com