idnits 2.17.1 draft-ietf-mboned-v4v6-mcast-ps-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 (March 13, 2013) is 4063 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-06) exists of draft-ietf-mboned-64-multicast-address-format-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group C. Jacquenet 3 Internet-Draft M. Boucadair 4 Intended status: Informational France Telecom Orange 5 Expires: September 14, 2013 Y. Lee 6 Comcast 7 J. Qin 8 Cisco Systems 9 T. Tsou 10 Huawei Technologies (USA) 11 Q. Sun 12 China Telecom 13 March 13, 2013 15 IPv4-IPv6 Multicast: Problem Statement and Use Cases 16 draft-ietf-mboned-v4v6-mcast-ps-02 18 Abstract 20 This document discusses issues and requirements raised by IPv4-IPv6 21 multicast interconnection and co-existence scenarios. It also 22 discusses various multicast use cases which may occur during IPv6 23 transitioning. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 14, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Organization of the Document . . . . . . . . . . . . . . 4 62 2. Scope and Service Requirements . . . . . . . . . . . . . . . 5 63 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Service Requirements . . . . . . . . . . . . . . . . . . 5 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. IPv4 Receiver and Source Connected to an IPv6-Only 67 Network . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. IPv6 Receiver and Source Connected to an IPv4-Only 69 Network . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 10 71 3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 11 72 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 74 4.1. Group and Source Discovery Considerations . . . . . . . . 13 75 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 13 76 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . 14 77 4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 14 78 4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . 14 79 4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 16 80 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 16 81 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . 16 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 8.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 Global IPv4 address depletion inevitably challenges service providers 93 who must guarantee IPv4 service continuity during the forthcoming 94 transition period. In particular, access to IPv4 contents that are 95 multicast to IPv4 receivers becomes an issue when the forwarding of 96 multicast data assumes the use of global IPv4 addresses. 98 The rarefaction of global IPv4 addresses may indeed affect the 99 multicast delivery of IPv4-formatted contents to IPv4 receivers. For 100 example, the observed evolution of ADSL broadband access 101 infrastructures from a service-specific, multi-PVC (Permanent Virtual 102 Circuit) scheme towards a "service-agnostic", single PVC scheme, 103 assumes the allocation of a globally unique IPv4 address on the WAN 104 (Wide Area Network) interface of the CPE (Customer Premises 105 Equipment), or to a mobile terminal), whatever the number and the 106 nature of the services the customer has subscribed to. 108 Likewise, the global IPv4 address depletion encourages the 109 development of IPv6 receivers while contents may very well remain 110 IPv4-formatted. There is therefore a need to make sure such IPv6 111 receivers can access IPv4-formatted contents during the transition 112 period. 114 During the transition period, the usage of the remaining global IPv4 115 address blocks will have to be rationalized for the sake of IPv4 116 service continuity. The current state-of-the-art suggests the 117 introduction of NAT (Network Address Translation) capabilities 118 (generally denoted as CGN, for Carrier-Grade NAT) in providers' 119 networks, so that a global IPv4 address will be shared between 120 several customers. 122 As a consequence, CPE or mobile UE (User Equipment) devices will no 123 longer be assigned a dedicated global IPv4 address anymore, and IPv4 124 traffic will be privately-addressed until it reaches one of the CGN 125 capabilities deployed in the network. From a multicast delivery 126 standpoint, this situation suggests the following considerations: 128 o The current design of some multicast-based services like TV 129 broadcasting often relies upon the use of a private IPv4 130 addressing scheme because of a walled garden approach. Privately- 131 addressed IGMP [RFC2236][RFC3376] traffic sent by IPv4 receivers 132 is generally forwarded over a specific (e.g., "IPTV") PVC towards 133 an IGMP Querier located in the access infrastructure, e.g., in 134 some deployments it is hosted by a BRAS (BRoadband Access Server) 135 device that is the PPP (Point-to-Point Protocol) session endpoint 136 and which may also act as a PIM DR (Protocol Independent Multicast 137 Designated Router)[RFC4601]. This design does not suffer from 138 global IPv4 address depletion by definition (since multicast 139 traffic relies upon the use of a private IPv4 addressing scheme), 140 but it is inconsistent with migrating the access infrastructure 141 towards a publicly-addressed single PVC design scheme. 143 o Likewise, other deployments (e.g., cable operators' environments) 144 rely upon the public CPE's address for multicast delivery and will 145 therefore suffer from IPv4 address depletion. 147 o The progressive introduction of IPv6 as the only perennial 148 solution to global IPv4 address depletion does not necessarily 149 assume that multicast-based IPv4 services will be migrated 150 accordingly. Access to IPv4 multicast contents when no global 151 IPv4 address can be assigned to a customer raises several issues: 152 (1) The completion of the IGMP-based multicast group subscription 153 procedure, (2) The computation of the IPv4 multicast distribution 154 tree, and (3) The IPv4-inferred addressing scheme to be used in a 155 networking environment which will progressively become 156 IPv6-enabled. 158 This document does not make any assumption on the techniques used for 159 the delivery of multicast traffic (e.g., native IP multicast with or 160 without traffic isolation features, etc.) 162 This document elaborates on the context and discusses multicast- 163 related issues and requirements. 165 1.1. Terminology 167 This document uses the following terms: 169 o Multicast Source: Source of contents that are multicast to 170 receivers. A video streaming server is an example of such source. 172 o Multicast Receiver: Receiver, in short. A Set Top Box (STB) is an 173 example of such receiver. 175 o Multicast Delivery Network: Network in short, covers the realm 176 from Designated Routers that are directly connected to sources to 177 IGMP/MLD (Internet Group Management Protocol/Multicast Listener 178 Discovery) Querier devices that process IGMP/MLD signalling 179 traffic exchanged with receivers. 181 1.2. Organization of the Document 183 This document is organized as follows: 185 o Section 2 details basic requirements that should be addressed by 186 providers involved in the delivery of multicast-based services 187 during the transition period, 189 o Section 3 discusses several use cases that reflect issues raised 190 by the forthcoming transition period, 192 o Section 4 details design considerations. 194 2. Scope and Service Requirements 196 2.1. Scope 198 Intra-domain only: The delivery of multicast services such as live 199 TV broadcasting often relies upon walled garden designs that 200 restrict the scope to the domain where such services can be 201 subscribed. As a consequence, considerations about inter-domain 202 multicast are out of the scope of this document. 204 Multicast-enabled networks only: This document assumes that the 205 network is IP multicast-enabled. That is, whatever the IP address 206 family of the content, this content will be multicast along 207 distribution trees that should be terminated as close to the 208 receivers as possible for the sake of bandwidth optimization. In 209 other words, considerations about forwarding multicast traffic 210 over unicast-only (access) networks are out of the scope of this 211 document. 213 Multicast to the receivers, not from the receivers: This document 214 only covers the case where multicast traffic is forwarded by the 215 service provider network to the receivers. This document does not 216 cover the case where the receivers send multicast traffic to the 217 network. 219 2.2. Service Requirements 221 The delivery of multicast contents during the forthcoming transition 222 period needs to address the following requirements. Note that some 223 of these requirements are not necessarily specific to the IPv4-to- 224 IPv6 transition context, but rather apply to a wide range of 225 multicast-based services whatever the environmental constraints, but 226 the forthcoming transition period further stresses these requirements 227 (see Section 4.4.1 for more details). 229 o Optimize bandwidth. Contents should not be multicast twice (i.e., 230 using both versions of IP) to optimize bandwidth usage. Injecting 231 multicast content using both IPv4 and IPv6 raises some 232 dimensioning issues that should be carefully evaluated by service 233 providers during network planning operations. For instance, if 234 only few IPv6-enabled receivers are in use, it can be more 235 convenient to convey multicast traffic over IPv4 rather than 236 doubling the consumed resources for few users. IPv4/IPv6 co- 237 existence solutions should be designed to optimize network 238 resource utilization. 240 o Zap rapidly. The time it takes to switch from one content to 241 another must be as short as possible. For example, zapping times 242 between two TV channels should be in the magnitude of a few 243 seconds at most, whatever the conditions to access the multicast 244 network. A procedure called "IGMP fast-leave" is sometimes used 245 to minimize this issue so that the corresponding multicast stream 246 is stopped as soon as the IGMP Leave message is received by the 247 Querier. In current deployments, IGMP fast-leave often assumes 248 the activation of the IGMP Proxy function in DSLAMs. The 249 complexity of such design is aggravated within a context where 250 IPv4 multicast control messages are encapsulated in IPv6. 252 o Preserve the integrity of contents. Some contract agreements may 253 prevent a service provider from altering the content owned by the 254 content provider, because of copyright, confidentiality and SLA 255 assurance reasons. Multicast streams should be delivered without 256 altering their content. 258 o Preserve service quality. Crossing a CGN or performing multicast 259 packet encapsulation may lead to fragmentation or extra delays and 260 may therefore impact the perceived quality of service. Such 261 degradation must be avoided. 263 o Optimize IPv4-IPv6 inter-working design. In some operational 264 networks, a source-based stateful NAT function is sometimes used 265 for load balancing purposes, for example. Because of the 266 operational issues raised by such a stateful design, the 267 deployment of stateless IPv4-IPv6 interworking functions should be 268 privileged. 270 3. Use Cases 272 During the IPv4-to-IPv6 transition period, there might be a mix of 273 multicast receivers, sources, and networks running in different 274 address families. However, service providers must guarantee the 275 delivery of multicast services to IPv4 receivers and, presumably, 276 IPv6 receivers. Because of the inevitable combination of different 277 IP version-related environments (sources, receivers and networks), 278 service providers should carefully plan and choose the appropriate 279 technique that will optimize the network resources to deliver 280 multicast-based services. 282 Concretely, several use cases can be considered during the IPv4/ IPv6 283 co-existence period. Some of them are depicted in the following sub- 284 sections. 286 3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network 288 We refer to this scenario as 4-6-4. An example of such use case is a 289 DS-Lite environment, where customers will share global IPv4 290 addresses. IPv4 receivers are connected to CPE devices that are 291 provisioned with an IPv6 prefix only. Delivering multicast content 292 sent by an IPv4 source to such receivers requires the activation of 293 some adaptation functions (AFs). These may operate at the network 294 layer (interworking functions (IWF) or at the application layer 295 (application level gateways (ALGs)). 297 The signalling flow for the 4-6-4 use case is shown in Figure 1. 299 +------+ +-----+ +------+ +------+ 300 | Host | IGMP | DS | | MR | PIM | MR | 301 | Rcvr |------| AF1 | | | . . . . | | 302 | | IPv4 | | | (BG) | IPv4 | (DR) | 303 +------+ +-----+ +------+ +------+ 304 / \ 305 MLD / IPv6 PIM \ IPv4 306 / \ 307 +------+ +----+ +------+ 308 | MR | PIM | | PIM | DS | 309 | |------| MR | . . . | AF2 | 310 | (DR) | IPv6 | | IPv6 | (BG) | 311 +------+ +----+ +------+ 313 -------------------------------------> 315 Rcvr: Multicast receiver 316 DS : Dual Stack 317 AF : Adaptation Function (ALG or IWF) 318 MR : Multicast Router 319 DR : Designated Router 320 BG : Border Gateway 322 Figure 1: Signalling Path for the 4-6-4 Scenario. 324 AF1 refers to an IGMP/MLD Adaptation Function. Another Adaptation 325 Function AF2 is needed at the border between the IPv6 multicast 326 domain and the IPv4 multicast domain where the source resides. AF2 327 is typically embedded in a multicast router that either terminates or 328 propagates PIM signalling directed toward the IPv4 source in the IPv6 329 multicast domain. 331 On the IPv4 side, AF2 also acts as a multicast router, and uses PIMv4 332 signalling to join the IPv4 multicast group. The return path taken 333 by multicast traffic is shown in Figure 2. 335 +------+ +-----+ +------+ +------+ +-----+ 336 | Host | | DS | | MR | | MR | | | 337 | Rcvr |------| AF1 | | | . . . | |------| Src | 338 | | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | | 339 +------+ +-----+ +------+ +------+ +-----+ 340 / \ 341 / IPv6 \ IPv4 342 / \ 343 +------+ +----+ +------+ 344 | MR | | | | DS | 345 | |------| MR | . . . | AF2 | 346 | (DR) | IPv6 | | IPv6 | (BG) | 347 +------+ +----+ +------+ 349 <------------------------------------- 351 Rcvr: Multicast receiver 352 DS : Dual Stack 353 AF : Adaptation Function 354 MR : Multicast router 355 DR : Designated Router 356 BG : Border Gateway 357 Src : Multicast source 359 Figure 2: Multicast Traffic Forwarding Path for the 4-6-4 Scenario. 361 Again, adaptation functions are needed whenever the IP protocol 362 version changes. The adaptation function instance AF2 at the 363 boundary between the source network and the IPv6 network may either 364 encapsulate or translate the headers of the IPv4 packets to allow the 365 content to cross the IPv6 network. The adaptation function instance 366 at the boundary between the IPv6 network and the receiver network 367 performs the reverse operation to deliver IPv4 packets. 369 Given the current state-of-the-art where multicast content is likely 370 to remain IPv4-formatted while receiver devices such as Set Top Boxes 371 will also remain IPv4-only for quite some time, this scenario is 372 prioritized by some service providers, including those that are 373 deploying or will deploy DS-Lite CGN capabilities for the sake of 374 IPv4 service continuity. 376 3.2. IPv6 Receiver and Source Connected to an IPv4-Only Network 378 We refer to this scenario as 6-4-6. Since providers who own the 379 multicast content may not be ready for IPv6 migration beofre some 380 time, the content is likely to remain IPv4-formatted. As a 381 consequence, this 6-4-6 scenario is of lower priority than the 4-6-4 382 scenario. 384 The signalling path for the 6-4-6 scenario is illustrated in Figure 385 3. 387 +------+ +-----+ +------+ +------+ 388 | Host | MLD | DS | | MR | PIM | MR | 389 | Rcvr |------| AF1 | | | . . . . | | 390 | | IPv6 | | | (BG) | IPv6 | (DR) | 391 +------+ +-----+ +------+ +------+ 392 / \ 393 IGMP / IPv4 PIM \ IPv6 394 / \ 395 +------+ +----+ +------+ 396 | MR | PIM | | PIM | DS | 397 | |------| MR | . . . | AF2 | 398 | (DR) | IPv4 | | IPv4 | (BG) | 399 +------+ +----+ +------+ 401 -------------------------------------> 403 Rcvr: Multicast receiver 404 DS : Dual Stack 405 AF : Adaptation Function 406 MR : Multicast Router 407 DR : Designated Router 408 BG : Border Gateway 410 Figure 3: Signalling Path For the 6-4-6 Scenario. 412 Figure 4 shows the path taken by multicast traffic flowing from the 413 IPv6 source to the IPv6 receiver. 415 +------+ +-----+ +------+ +------+ 416 | Host | | DS | | MR | | MR | 417 | Rcvr |------| AF1 | | | . . . | | 418 | | IPv6 | | | (BG) | IPv6 | (DR) | 419 +------+ +-----+ +------+ +------+ 420 / \ \ 421 / IPv4 \ IPv6 \ IPv6 422 / \ \ 423 +------+ +----+ +------+ +-----+ 424 | MR | | | | DS | | | 425 | |------| MR | . . . | AF2 | | Src | 426 | (DR) | IPv4 | | IPv4 | (BG) | | | 427 +------+ +----+ +------+ +-----+ 429 <------------------------------------- 431 Rcvr: Multicast receiver 432 DS : Dual Stack 433 AF : Adaptation Function 434 MR : Multicast Router 435 DR : Designated Router 436 BG : Border Gateway 437 Src : Multicast source 439 Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario. 441 3.3. IPv6 Receiver and IPv4 Source 443 We refer to this scenario as 6-4. An example of such use case is the 444 context of some mobile networks, where terminal devices are only 445 provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast 446 content from an IPv6-only receiver requires additional functions to 447 be enabled. 449 This scenario is privileged by mobile operators who deploy NAT64 450 capabilities in their network. It is illustrated in Figures 5 451 (signalling path) and 6 (forwarding of multicast traffic). Only one 452 adaptation function instance is needed, and it will be located at the 453 IPv4/IPv6 multicast domain boundary. 455 +------+ +------+ +------+ 456 | Host | | MR | PIM | MR | 457 | Rcvr | | | . . . . | | 458 | | | (BG) | IPv4 | (DR) | 459 +------+ +------+ +------+ 460 \ \ 461 MLD \ IPv6 PIM \ IPv4 462 \ \ 463 +------+ +----+ +------+ 464 | MR | PIM | | PIM | DS | 465 | |------| MR | . . . | AF1 | 466 | (DR) | IPv6 | | IPv6 | (BG) | 467 +------+ +----+ +------+ 469 -------------------------------------> 471 Rcvr: Multicast receiver 472 DS : Dual Stack 473 AF : Adaptation Function 474 MR : Multicast Router 475 DR : Designated Router 476 BG : Border Gateway 477 Figure 5: Signalling Path For the 6-4 Scenario. 479 +------+ +------+ +------+ 480 | Host | | MR | | MR | 481 | Rcvr | | | . . . . | | 482 | | | (BG) | IPv4 | (DR) | 483 +------+ +------+ +------+ 484 \ \ \ 485 \ IPv6 \ IPv4 \ IPv4 486 \ \ \ 487 +------+ +----+ +------+ +-----+ 488 | MR | | | | DS | | | 489 | |------| MR | . . . | AF1 | | Src | 490 | (DR) | IPv6 | | IPv6 | (BG) | | | 491 +------+ +----+ +------+ +-----+ 493 <------------------------------------- 495 Rcvr: Multicast receiver 496 DS : Dual Stack 497 AF : Adaptation Function 498 MR : Multicast Router 499 DR : Designated Router 500 BG : Border Gateway 501 Src : Multicast source 503 Figure 6: Multicast Traffic Forwarding Path For the 6-4 Scenario. 505 3.4. IPv4 Receiver and IPv6 Source 507 We refer to this scenario as 4-6. Yet, multicast sources are likely 508 to remain IPv4-enabled in a first stage; therefore, the content is 509 likely to remain IPv4-formatted. As a consequence, this scenario is 510 unlikely to occur during the first years of the transition period. 512 The signalling path for this scenario is shown in Figure 7. The 513 multicast traffic forwarding path is shown in Figure 8. There are 514 similarities with the 6-4 scenario but address mapping across IP 515 version boundaries is more challenging. 517 +------+ +------+ +------+ 518 | Host | | MR | PIM | MR | 519 | Rcvr | | | . . . . | | 520 | | | (BG) | IPv6 | (DR) | 521 +------+ +------+ +------+ 522 \ \ 524 IGMP \ IPv4 PIM \ IPv6 525 \ \ 526 +------+ +----+ +------+ 527 | MR | PIM | | PIM | DS | 528 | |------| MR | . . . | AF1 | 529 | (DR) | IPv4 | | IPv4 | (BG) | 530 +------+ +----+ +------+ 532 -------------------------------------> 534 Rcvr: Multicast receiver 535 DS : Dual Stack 536 AF : Adaptation Function 537 MR : Multicast Router 538 DR : Designated Router 539 BG : Border Gateway 541 Figure 7: Signalling Path For the 4-6 Scenario. 543 +------+ +------+ +------+ 544 | Host | | MR | | MR | 545 | Rcvr | | | . . . . | | 546 | | | (BG) | IPv6 | (DR) | 547 +------+ +------+ +------+ 548 \ \ \ 549 \ IPv4 \ IPv6 \ IPv6 550 \ \ \ 551 +------+ +----+ +------+ +-----+ 552 | MR | | | | DS | | | 553 | |------| MR | . . . | AF1 | | Src | 554 | (DR) | IPv4 | | IPv4 | (BG) | | | 555 +------+ +----+ +------+ +-----+ 557 <------------------------------------- 559 Rcvr: Multicast receiver 560 DS : Dual Stack 561 AF : Adaptation Function 562 MR : Multicast Router 563 DR : Designated Router 564 BG : Border Gateway 565 Src : Multicast source 567 Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario. 569 3.5. Summary 571 To summarize, the use cases of highest priority are those involving 572 IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios. 574 4. Design Considerations 576 4.1. Group and Source Discovery Considerations 578 Multicast applications that embed address information in the payload 579 may require Application Level Gateway (ALG) during the transition 580 period. An ALG is application-specific by definition, and may 581 therefore be unnecessary depending on the nature of the multicast 582 service. 584 Such ALG (Application Level Gateway) may also be required to help an 585 IPv6 receiver select the appropriate multicast group address when 586 only the IPv4 address is advertised (e.g., when the SDP (Session 587 Description Protocol) protocol is used to advertise some contents); 588 otherwise, access to IPv4 multicast content from an IPv6 receiver may 589 be compromised. 591 ALGs may be located upstream in the network. As a consequence, these 592 ALGs do not know in advance whether the receiver is dual-stack or 593 IPv6-only. In order to avoid the use of an ALG in the path, an 594 IPv4-only source can advertise both an IPv4 multicast group address 595 and the corresponding IPv4-embedded IPv6 multicast group address 596 [I-D.ietf-mboned-64-multicast-address-format]. 598 However, a dual-stack receiver may prefer to use the IPv6 address to 599 receive the multicast content. The selection of the IPv6 multicast 600 address would then require multicast flows to cross an IPv4-IPv6 601 interworking function. 603 The receiver should therefore be able to unambiguously distinguish an 604 IPv4-embedded IPv6 multicast address from a native IPv6 multicast 605 address. 607 4.2. Subscription 609 Multicast distribution trees are receiver-initiated. IPv4 receivers 610 that want to subscribe to an IPv4 multicast group will send the 611 corresponding IGMP Report message towards the relevant IGMP Querier. 612 In case the underlying access network is IPv6, the information 613 conveyed in IGMP messages should be relayed by corresponding MLD 614 messages. 616 4.3. Multicast Tree Computation 618 Grafting to an IPv4 multicast distribution tree through an IPv6 619 multicast domain suggests that IPv4 multicast traffic will have to be 620 conveyed along an "IPv6-equivalent" multicast distribution tree. 621 That is, part of the multicast distribution tree along which IPv4 622 multicast traffic will be forwarded should be computed and maintained 623 by means of the PIMv6 machinery, so that the distribution tree can be 624 terminated as close to the IPv4 receivers as possible for the sake of 625 the multicast forwarding efficiency. 627 This assumes a close interaction between the PIM designs enforced in 628 both IPv4 and IPv6 multicast domains, by means of specific Inter- 629 Working Functions that are further discussed in Section 4.4. 631 Such interaction may be complicated by different combinations: the 632 IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point) 633 routers), while the IPv6 multicast domain may support both ASM (Any 634 Source Multicast) and SSM (Source Specific Multicast) [RFC3569] 635 modes. 637 4.4. Multicast Adaptation Functions (AF) 639 IPv4-IPv6 multicast interworking functions are required for both 640 translation (one address family to another) and traversal (one 641 address family over another) contexts. 643 Given the multiple versions of Group Membership management protocols, 644 issues may be raised when, for example, IGMPv2 is running in the IPv4 645 multicast domain that is connected to the IPv6 multicast domain by 646 means of an IWF, while MLDv2 is running in the IPv6 multicast domain. 647 To solve these problems, the design of the IWF function should adhere 648 to the IP version-independent, protocol interaction approach 649 documented in Section 8 of [RFC3810] and Section 7 of [RFC3376]. 651 Note that, for traversal cases, to improve the efficiency of the 652 multicast service delivery, traffic will be multicast along 653 distribution trees that should be terminated as close to the 654 receivers as possible for bandwidth optimization purposes. As a 655 reminder, the traversal of unicast-only (access) networks is not 656 considered in this document. 658 4.4.1. AF For Control Flows 660 The IWF to process multicast signalling flows (such as IGMP or MLD 661 Report messages) should be independent of the IP version and consist 662 mainly of an IPv4-IPv6 adaptation element and an IP address 663 translation element. The message format adaptation must follow what 664 is specified in [RFC3810] or [RFC4601], and the device that embeds 665 the IWF device must be multicast-enabled, i.e., support IGMP, MLD and 666 /or PIM, depending on the context (address family-wise) and the 667 design (e.g., this device could be a PIM DR in addition to a MLD 668 Querier). 670 The IWF can then be operated in the following modes: IGMP-MLD, 671 PIMv4-PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source- 672 Specific Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 673 signalling traffic as well as the ability to directly send PIM (S, G) 674 Join messages towards the source). 676 The following sub-sections describe some interworking functions which 677 may be solicited, depending on the environment. 679 4.4.1.1. IGMP-MLD Interworking 681 The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying 682 function specified in [RFC4605] and the IGMP/MLD adaptation function 683 which is meant to reflect the contents of IGMP messages into MLD 684 messages, and vice versa. 686 For example, when an IGMP Report message is received to subscribe to 687 a given multicast group (which may be associated to a source address 688 if SSM mode is used), the IGMP-MLD Interworking Function must send an 689 MLD Report message to subscribe to the corresponding IPv6 multicast 690 group. 692 4.4.1.2. IPv4-IPv6 PIM Interworking 694 [RFC4601] allows the computation of PIM-based IPv4 or IPv6 695 distribution trees; PIM is IP version agnostic. There is no specific 696 IPv6 PIM machinery that would work differently than an IPv4 PIM 697 machinery. The new features needed for the IPv4-IPv6 PIM 698 Interworking Function consist in dynamically triggering the PIM 699 message of Address Family 1 upon receipt of the equivalent PIM 700 message of Address Family 2. 702 The address mapping must be performed similarly to that of the IGMP- 703 MLD Interworking Function. 705 4.4.1.3. MLD-IPv4 PIM Interworking 707 This IWF function is required when the MLD Querier is connected to an 708 IPv4 PIM domain. 710 The address mapping must be performed similarly to that of the IGMP- 711 MLD Interworking Function. 713 4.4.1.4. IGMP-IPv6 PIM Interworking 715 The address mapping must be performed similarly to that of the IGMP- 716 MLD Interworking Function. 718 4.4.2. AF For Data Flows 720 The IWF to be used for multicast data flows is operated at the 721 boundary between IPv4 and IPv6 multicast networks. Either 722 encapsulation/de-capsulation or translation modes can be enforced, 723 depending on the design. Note that translation operations must 724 follow the algorithm specified in [RFC6145]. 726 4.4.3. Address Mapping 728 The address mapping mechanisms to be used in either a stateful or 729 stateless fashion need to be specified for the translation from one 730 address family to the other. 732 The address formats have been defined in 733 [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for 734 IPv4-embedded IPv6 multicast and unicast addresses. Mapping 735 operations are performed in a stateless manner by the algorithms 736 specified in the aforementioned documents. 738 In this context, the IPv6 prefixes required for embedding IPv4 739 addresses can be assigned to devices that support IWF features by 740 various means (e.g., static or dynamic configuration, out-of-band 741 mechanisms, etc.). 743 If stateful approaches are used, it is recommended to carefully 744 investigate the need to synchronize mapping states between multiple 745 boxes, and the coordination of the IWF and source/group discovery 746 elements is also required, at the cost of extra complexity. 748 4.5. Combination of ASM and SSM Modes 750 The ASM (Any Source Multicast) mode could be used to optimize the 751 forwarding of IPv4 multicast traffic sent by different sources into 752 the IPv6 multicast domain by selecting RP routers that could be 753 located at the border between the IPv6 and the IPv4 multicast 754 domains. This design may optimize the multicast forwarding 755 efficiency in the IPv6 domain when access to several IPv4 multicast 756 sources needs to be granted. 758 5. IANA Considerations 760 This document makes no request to IANA. 762 Note to RFC Editor: this section may be removed on publication as an 763 RFC. 765 6. Security Considerations 767 Access to contents in a multicast-enabled environment raises 768 different security issues that have been already documented. This 769 draft does not introduce any specific security issue. 771 7. Acknowledgments 773 Special thanks to T. Taylor for providing the figures and some of 774 the text that illustrate the use cases depicted in Section 3. Thanks 775 also to H. Asaeda, M. Blanchet, M. Eubanks, N. Leymann, S. 776 Perrault and S. Venaas for their valuable comments and support. 778 8. References 780 8.1. Normative References 782 [RFC2236] Fenner, W.C., "Internet Group Management Protocol, Version 783 2", RFC 2236, November 1997. 785 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 786 Thyagarajan, "Internet Group Management Protocol, Version 787 3", RFC 3376, October 2002. 789 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 790 Multicast (SSM)", RFC 3569, July 2003. 792 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 793 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 795 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 796 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 797 Protocol Specification (Revised)", RFC 4601, August 2006. 799 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 800 "Internet Group Management Protocol (IGMP) / Multicast 801 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 802 /MLD Proxying")", RFC 4605, August 2006. 804 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 805 Algorithm", RFC 6145, April 2011. 807 8.2. Informative References 809 [I-D.ietf-mboned-64-multicast-address-format] 810 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 811 M. Xu, "IPv6 Multicast Address With Embedded IPv4 812 Multicast Address", draft-ietf-mboned-64-multicast- 813 address-format-04 (work in progress), August 2012. 815 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 816 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 817 October 2010. 819 Authors' Addresses 821 Christian Jacquenet 822 France Telecom Orange 823 4 rue du Clos Courtel 824 Cesson-Sevigne 35512 825 France 827 Phone: +33 2 99 12 43 82 828 Email: christian.jacquenet@orange.com 830 Mohamed Boucadair 831 France Telecom Orange 832 4 rue du Clos Courtel 833 Cesson-Sevigne 35512 834 France 836 Phone: +33 2 99 12 43 71 837 Email: mohamed.boucadair@orange.com 839 Yiu Lee 840 Comcast 841 US 843 Email: Yiu_Lee@Cable.Comcast.com 845 Jacni Qin 846 Cisco Systems 847 People's Republic of China 849 Email: jacni@jacni.com 850 Tina Tsou 851 Huawei Technologies (USA) 852 2330 Central Expressway 853 Santa Clara, CA 95050 854 USA 856 Phone: +1 408 330 4424 857 Email: tena@huawei.com 859 Qiong Sun 860 China Telecom 861 Room 708, No.118, Xizhimennei Street 862 Beijing 100035 863 People's Republic of China 865 Phone: >+86-10-58552936 866 Email: sunqiong@ctbri.com.cn