idnits 2.17.1 draft-ietf-mboned-v4v6-mcast-ps-03.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 (June 05, 2013) is 3970 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-05 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: December 07, 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 June 05, 2013 15 IPv4-IPv6 Multicast: Problem Statement and Use Cases 16 draft-ietf-mboned-v4v6-mcast-ps-03 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 December 07, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. IPv6 Receiver and Source Connected to an IPv4-Only 69 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 Requirements . . . . . . . . . . . . . . . . . . . . . 13 74 4.1. Group and Source Discovery Considerations . . . . . . . . 13 75 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 14 76 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . 14 77 4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 14 78 4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 17 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 8.2. Informative References . . . . . . . . . . . . . . . . . 18 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 First Hop 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. The draft does not 216 consider multicast services that assume a source/receiver 217 heuristic, e.g., videoconferencing services. The draft primarily 218 focuses on residential multicast-based services, as per a typical 219 1:n group communication scheme. 221 2.2. Service Requirements 223 The delivery of multicast contents during the forthcoming transition 224 period needs to address the following requirements. Note that some 225 of these requirements are not necessarily specific to the IPv4-to- 226 IPv6 transition context, but rather apply to a wide range of 227 multicast-based services whatever the environmental constraints, but 228 the forthcoming transition period further stresses these requirements 229 (see Section 4.4.1 for more details). 231 o Optimize bandwidth. Contents should not be multicast twice (i.e., 232 using both versions of IP) to optimize bandwidth usage. Injecting 233 multicast content using both IPv4 and IPv6 raises some 234 dimensioning issues that should be carefully evaluated by service 235 providers during network planning operations. For instance, if 236 only few IPv6-enabled receivers are in use, it can be more 237 convenient to convey multicast traffic over IPv4 rather than 238 doubling the consumed resources for few users. IPv4/IPv6 co- 239 existence solutions should be designed to optimize network 240 resource utilization. 242 o Zap rapidly. The time it takes to switch from one content to 243 another must be as short as possible. For example, zapping times 244 between two TV channels should be comparable to an IPv4 case, 245 i.e., less than a second so that translation does not 246 significantly affect the overhead, whatever the conditions to 247 access the multicast network. A procedure called "IGMP fast- 248 leave" is sometimes used to minimize this issue so that the 249 corresponding multicast stream is stopped as soon as the IGMP 250 Leave message is received by the Querier. In current deployments, 251 IGMP fast-leave often assumes the activation of the IGMP Proxy 252 function in DSLAMs. The complexity of such design is aggravated 253 within a context where IPv4 multicast control messages are 254 encapsulated in IPv6. 256 o Preserve the integrity of contents that the user sees, i.e., not 257 the contents of IP packets. Some contract agreements may prevent 258 a service provider from altering the content owned by the content 259 provider, because of copyright, confidentiality and SLA assurance 260 reasons. Multicast streams should be delivered without altering 261 their content. 263 o Preserve service quality. Crossing a CGN or performing multicast 264 packet encapsulation may lead to fragmentation or extra delays and 265 may therefore impact the perceived quality of service. Such 266 degradation must be avoided. 268 o Optimize IPv4-IPv6 inter-working design. In some operational 269 networks, a source-based stateful NAT function is sometimes used 270 for load balancing purposes, for example. Because of the 271 operational issues raised by such a stateful design, the 272 deployment of stateless IPv4-IPv6 interworking functions should be 273 privileged. 275 3. Use Cases 277 During the IPv4-to-IPv6 transition period, there might be a mix of 278 multicast receivers, sources, and networks running in different 279 address families. However, service providers must guarantee the 280 delivery of multicast services to IPv4 receivers and, presumably, 281 IPv6 receivers. Because of the inevitable combination of different 282 IP version-related environments (sources, receivers and networks), 283 service providers should carefully plan and choose the appropriate 284 technique that will optimize the network resources to deliver 285 multicast-based services. 287 Concretely, several use cases can be considered during the IPv4/ IPv6 288 co-existence period. Some of them are depicted in the following sub- 289 sections. 291 Note that the following diagrams are meant to illustrate the 292 conceptual model. As such, they do not necessarily mean that the 293 Adaptation Functions (AF) are embedded in a separate device and that 294 messages need to be explicitly translated into new messages. 296 3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network 298 We refer to this scenario as 4-6-4. An example of such use case is a 299 DS-Lite environment, where customers will share global IPv4 300 addresses. IPv4 receivers are connected to CPE devices that are 301 provisioned with an IPv6 prefix only. Delivering multicast content 302 sent by an IPv4 source to such receivers requires the activation of 303 some adaptation functions (AFs). These may operate at the network 304 layer (interworking functions (IWF) or at the application layer 305 (application level gateways (ALGs)). 307 The signalling flow for the 4-6-4 use case is shown in Figure 1. 309 +------+ +-----+ +------+ +------+ 310 | Host | IGMP | DS | | MR | PIM | MR | 311 | Rcvr |------| AF1 | | | . . . . | | 312 | | IPv4 | | | (BG) | IPv4 | (DR) | 313 +------+ +-----+ +------+ +------+ 314 / \ 315 MLD / IPv6 PIM \ IPv4 316 / \ 317 +------+ +----+ +------+ 318 | MR | PIM | | PIM | DS | 319 | |------| MR | . . . | AF2 | 320 | (DR) | IPv6 | | IPv6 | (BG) | 321 +------+ +----+ +------+ 323 -------------------------------------> 325 Rcvr: Multicast receiver 326 DS : Dual Stack 327 AF : Adaptation Function (ALG or IWF) 328 MR : Multicast Router 329 DR : Designated Router 330 BG : Border Gateway 332 Figure 1: Signalling Path for the 4-6-4 Scenario. 334 AF1 refers to an IGMP/MLD Adaptation Function. Another Adaptation 335 Function AF2 is needed at the border between the IPv6 multicast 336 domain and the IPv4 multicast domain where the source resides. AF2 337 is typically embedded in a multicast router that either terminates or 338 propagates PIM signalling directed toward the IPv4 source in the IPv6 339 multicast domain. 341 On the IPv4 side, AF2 also acts as a multicast router, and uses PIMv4 342 signalling to join the IPv4 multicast group. The return path taken 343 by multicast traffic is shown in Figure 2. 345 +------+ +-----+ +------+ +------+ +-----+ 346 | Host | | DS | | MR | | MR | | | 347 | Rcvr |------| AF1 | | | . . . | |------| Src | 348 | | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | | 349 +------+ +-----+ +------+ +------+ +-----+ 350 / \ 351 / IPv6 \ IPv4 352 / \ 353 +------+ +----+ +------+ 354 | MR | | | | DS | 355 | |------| MR | . . . | AF2 | 356 | (DR) | IPv6 | | IPv6 | (BG) | 357 +------+ +----+ +------+ 359 <------------------------------------- 361 Rcvr: Multicast receiver 362 DS : Dual Stack 363 AF : Adaptation Function 364 MR : Multicast router 365 DR : Designated Router 366 BG : Border Gateway 367 Src : Multicast source 369 Figure 2: Multicast Traffic Forwarding Path for the 4-6-4 Scenario. 371 Again, adaptation functions are needed whenever the IP protocol 372 version changes. The adaptation function instance AF2 at the 373 boundary between the source network and the IPv6 network may either 374 encapsulate or translate the headers of the IPv4 packets to allow the 375 content to cross the IPv6 network. The adaptation function instance 376 at the boundary between the IPv6 network and the receiver network 377 performs the reverse operation to deliver IPv4 packets. 379 Given the current state-of-the-art where multicast content is likely 380 to remain IPv4-formatted while receiver devices such as Set Top Boxes 381 will also remain IPv4-only for quite some time, this scenario is 382 prioritized by some service providers, including those that are 383 deploying or will deploy DS-Lite CGN capabilities for the sake of 384 IPv4 service continuity. 386 3.2. IPv6 Receiver and Source Connected to an IPv4-Only Network 388 We refer to this scenario as 6-4-6. Since providers who own the 389 multicast content may not be ready for IPv6 migration beofre some 390 time, the content is likely to remain IPv4-formatted. As a 391 consequence, this 6-4-6 scenario is of lower priority than the 4-6-4 392 scenario. 394 The signalling path for the 6-4-6 scenario is illustrated in Figure 395 3. 397 +------+ +-----+ +------+ +------+ 398 | Host | MLD | DS | | MR | PIM | MR | 399 | Rcvr |------| AF1 | | | . . . . | | 400 | | IPv6 | | | (BG) | IPv6 | (DR) | 401 +------+ +-----+ +------+ +------+ 402 / \ 403 IGMP / IPv4 PIM \ IPv6 404 / \ 405 +------+ +----+ +------+ 406 | MR | PIM | | PIM | DS | 407 | |------| MR | . . . | AF2 | 408 | (DR) | IPv4 | | IPv4 | (BG) | 409 +------+ +----+ +------+ 411 -------------------------------------> 413 Rcvr: Multicast receiver 414 DS : Dual Stack 415 AF : Adaptation Function 416 MR : Multicast Router 417 DR : Designated Router 418 BG : Border Gateway 420 Figure 3: Signalling Path For the 6-4-6 Scenario. 422 Figure 4 shows the path taken by multicast traffic flowing from the 423 IPv6 source to the IPv6 receiver. 425 +------+ +-----+ +------+ +------+ 426 | Host | | DS | | MR | | MR | 427 | Rcvr |------| AF1 | | | . . . | | 428 | | IPv6 | | | (BG) | IPv6 | (DR) | 429 +------+ +-----+ +------+ +------+ 430 / \ \ 431 / IPv4 \ IPv6 \ IPv6 432 / \ \ 434 +------+ +----+ +------+ +-----+ 435 | MR | | | | DS | | | 436 | |------| MR | . . . | AF2 | | Src | 437 | (DR) | IPv4 | | IPv4 | (BG) | | | 438 +------+ +----+ +------+ +-----+ 440 <------------------------------------- 442 Rcvr: Multicast receiver 443 DS : Dual Stack 444 AF : Adaptation Function 445 MR : Multicast Router 446 DR : Designated Router 447 BG : Border Gateway 448 Src : Multicast source 450 Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario. 452 3.3. IPv6 Receiver and IPv4 Source 454 We refer to this scenario as 6-4. An example of such use case is the 455 context of some mobile networks, where terminal devices are only 456 provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast 457 content from an IPv6-only receiver requires additional functions to 458 be enabled. 460 This scenario is privileged by mobile operators who deploy NAT64 461 capabilities in their network. It is illustrated in Figures 5 462 (signalling path) and 6 (forwarding of multicast traffic). Only one 463 adaptation function instance is needed, and it will be located at the 464 IPv4/IPv6 multicast domain boundary. 466 +------+ +------+ +------+ 467 | Host | | MR | PIM | MR | 468 | Rcvr | | | . . . . | | 469 | | | (BG) | IPv4 | (DR) | 470 +------+ +------+ +------+ 471 \ \ 472 MLD \ IPv6 PIM \ IPv4 473 \ \ 474 +------+ +----+ +------+ 475 | MR | PIM | | PIM | DS | 476 | |------| MR | . . . | AF1 | 477 | (DR) | IPv6 | | IPv6 | (BG) | 478 +------+ +----+ +------+ 480 -------------------------------------> 482 Rcvr: Multicast receiver 483 DS : Dual Stack 484 AF : Adaptation Function 485 MR : Multicast Router 486 DR : Designated Router 487 BG : Border Gateway 489 Figure 5: Signalling Path For the 6-4 Scenario. 491 +------+ +------+ +------+ 492 | Host | | MR | | MR | 493 | Rcvr | | | . . . . | | 494 | | | (BG) | IPv4 | (DR) | 495 +------+ +------+ +------+ 496 \ \ \ 497 \ IPv6 \ IPv4 \ IPv4 498 \ \ \ 499 +------+ +----+ +------+ +-----+ 500 | MR | | | | DS | | | 501 | |------| MR | . . . | AF1 | | Src | 502 | (DR) | IPv6 | | IPv6 | (BG) | | | 503 +------+ +----+ +------+ +-----+ 505 <------------------------------------- 507 Rcvr: Multicast receiver 508 DS : Dual Stack 509 AF : Adaptation Function 510 MR : Multicast Router 511 DR : Designated Router 512 BG : Border Gateway 513 Src : Multicast source 515 Figure 6: Multicast Traffic Forwarding Path For the 6-4 Scenario. 517 3.4. IPv4 Receiver and IPv6 Source 519 We refer to this scenario as 4-6. Yet, multicast sources are likely 520 to remain IPv4-enabled in a first stage; therefore, the content is 521 likely to remain IPv4-formatted. As a consequence, this scenario is 522 unlikely to occur during the first years of the transition period. 524 The signalling path for this scenario is shown in Figure 7. The 525 multicast traffic forwarding path is shown in Figure 8. There are 526 similarities with the 6-4 scenario but address mapping across IP 527 version boundaries is more challenging. 529 +------+ +------+ +------+ 530 | Host | | MR | PIM | MR | 531 | Rcvr | | | . . . . | | 532 | | | (BG) | IPv6 | (DR) | 533 +------+ +------+ +------+ 534 \ \ 535 IGMP \ IPv4 PIM \ IPv6 536 \ \ 537 +------+ +----+ +------+ 538 | MR | PIM | | PIM | DS | 539 | |------| MR | . . . | AF1 | 540 | (DR) | IPv4 | | IPv4 | (BG) | 541 +------+ +----+ +------+ 543 -------------------------------------> 545 Rcvr: Multicast receiver 546 DS : Dual Stack 547 AF : Adaptation Function 548 MR : Multicast Router 549 DR : Designated Router 550 BG : Border Gateway 552 Figure 7: Signalling Path For the 4-6 Scenario. 554 +------+ +------+ +------+ 555 | Host | | MR | | MR | 556 | Rcvr | | | . . . . | | 557 | | | (BG) | IPv6 | (DR) | 558 +------+ +------+ +------+ 559 \ \ \ 560 \ IPv4 \ IPv6 \ IPv6 561 \ \ \ 562 +------+ +----+ +------+ +-----+ 563 | MR | | | | DS | | | 564 | |------| MR | . . . | AF1 | | Src | 565 | (DR) | IPv4 | | IPv4 | (BG) | | | 566 +------+ +----+ +------+ +-----+ 568 <------------------------------------- 570 Rcvr: Multicast receiver 571 DS : Dual Stack 572 AF : Adaptation Function 573 MR : Multicast Router 574 DR : Designated Router 575 BG : Border Gateway 576 Src : Multicast source 578 Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario. 580 3.5. Summary 582 To summarize, the use cases of highest priority are those involving 583 IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios. 585 4. Design Requirements 587 4.1. Group and Source Discovery Considerations 589 Multicast applications that embed address information in the payload 590 may require Application Level Gateway (ALG) during the transition 591 period. An ALG is application-specific by definition, and may 592 therefore be unnecessary depending on the nature of the multicast 593 service. 595 Such ALG (Application Level Gateway) may also be required to help an 596 IPv6 receiver select the appropriate multicast group address when 597 only the IPv4 address is advertised (e.g., when the SDP (Session 598 Description Protocol) protocol is used to advertise some contents); 599 otherwise, access to IPv4 multicast content from an IPv6 receiver may 600 be compromised. 602 ALGs may be located upstream in the network. As a consequence, these 603 ALGs do not know in advance whether the receiver is dual-stack or 604 IPv6-only. In order to avoid the use of an ALG in the path, an 605 IPv4-only source can advertise both an IPv4 multicast group address 606 and the corresponding IPv4-embedded IPv6 multicast group address 607 [I-D.ietf-mboned-64-multicast-address-format]. 609 However, a dual-stack receiver may prefer to use the IPv6 address to 610 receive the multicast content. The selection of the IPv6 multicast 611 address would then require multicast flows to cross an IPv4-IPv6 612 interworking function. 614 The receiver should therefore be able to unambiguously distinguish an 615 IPv4-embedded IPv6 multicast address from a native IPv6 multicast 616 address. 618 4.2. Subscription 620 Multicast distribution trees are receiver-initiated. IPv4 receivers 621 that want to subscribe to an IPv4 multicast group will send IGMP 622 Report messages accordingly. In case the underlying access network 623 is IPv6, the information conveyed in IGMP messages should be relayed 624 by corresponding MLD messages. 626 4.3. Multicast Tree Computation 628 Grafting to an IPv4 multicast distribution tree through an IPv6 629 multicast domain suggests that IPv4 multicast traffic will have to be 630 conveyed along an "IPv6-equivalent" multicast distribution tree. 631 That is, part of the multicast distribution tree along which IPv4 632 multicast traffic will be forwarded should be computed and maintained 633 by means of the PIMv6 machinery, so that the distribution tree can be 634 terminated as close to the IPv4 receivers as possible for the sake of 635 the multicast forwarding efficiency. 637 This assumes a close interaction between the PIM designs enforced in 638 both IPv4 and IPv6 multicast domains, by means of specific Inter- 639 Working Functions that are further discussed in Section 4.4. 641 Such interaction may be complicated by different combinations: the 642 IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point) 643 routers), while the IPv6 multicast domain may support both ASM (Any 644 Source Multicast) and SSM (Source Specific Multicast) [RFC3569] 645 modes. 647 4.4. Multicast Adaptation Functions (AF) 649 IPv4-IPv6 multicast interworking functions are required for both 650 translation (one address family to another) and traversal (one 651 address family over another) contexts. 653 Given the multiple versions of Group Membership management protocols, 654 issues may be raised when, for example, IGMPv2 is running in the IPv4 655 multicast domain that is connected to the IPv6 multicast domain by 656 means of an IWF, while MLDv2 is running in the IPv6 multicast domain. 657 To solve these problems, the design of the IWF function should adhere 658 to the IP version-independent, protocol interaction approach 659 documented in Section 8 of [RFC3810] and Section 7 of [RFC3376]. 661 Note that, for traversal cases, to improve the efficiency of the 662 multicast service delivery, traffic will be multicast along 663 distribution trees that should be terminated as close to the 664 receivers as possible for bandwidth optimization purposes. As a 665 reminder, the traversal of unicast-only (access) networks is not 666 considered in this document. 668 4.4.1. AF For Control Flows 670 The IWF to process multicast signalling flows (such as IGMP or MLD 671 Report messages) should be independent of the IP version and consist 672 mainly of an IPv4-IPv6 adaptation element and an IP address 673 translation element. The message format adaptation must follow what 674 is specified in [RFC3810] or [RFC4601], and the device that embeds 675 the IWF device must be multicast-enabled, i.e., support IGMP, MLD and 676 /or PIM, depending on the context (address family-wise) and the 677 design (e.g., this device could be a PIM DR in addition to a MLD 678 Querier). 680 The IWF can then be operated in the following modes: IGMP-MLD, 681 PIMv4-PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source- 682 Specific Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 683 signalling traffic as well as the ability to directly send PIM (S, G) 684 Join messages towards the source). 686 The following sub-sections describe some interworking functions which 687 may be solicited, depending on the environment. Note that it may not 688 be a stand-alone IWF that simply translates messages, but, for 689 example, the combination of IPv4 and IPv6 states that would trigger 690 the forwarding of aggregated MLD Report messages upstream that would 691 include IPv6 groups based upon IPv4 states. 693 4.4.1.1. IGMP-MLD Interworking 695 The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying 696 function specified in [RFC4605] and the IGMP/MLD adaptation function 697 which is meant to reflect the contents of IGMP messages into MLD 698 messages, and vice versa. 700 For example, when an IGMP Report message is received to subscribe to 701 a given multicast group (which may be associated to a source address 702 if SSM mode is used), the IGMP-MLD Interworking Function must send an 703 MLD Report message to subscribe to the corresponding IPv6 multicast 704 group. 706 4.4.1.2. IPv4-IPv6 PIM Interworking 708 [RFC4601] allows the computation of PIM-based IPv4 or IPv6 709 distribution trees; PIM is IP version agnostic. There is no specific 710 IPv6 PIM machinery that would work differently than an IPv4 PIM 711 machinery. The new features needed for the IPv4-IPv6 PIM 712 Interworking Function consist in dynamically triggering the PIM 713 message of Address Family 1 upon receipt of the equivalent PIM 714 message of Address Family 2. 716 The address mapping must be performed similarly to that of the IGMP- 717 MLD Interworking Function. 719 4.4.1.3. MLD-IPv4 PIM Interworking 721 This IWF function is required when the MLD Querier is connected to an 722 IPv4 PIM domain. 724 The address mapping must be performed similarly to that of the IGMP- 725 MLD Interworking Function. 727 4.4.1.4. IGMP-IPv6 PIM Interworking 729 The address mapping must be performed similarly to that of the IGMP- 730 MLD Interworking Function. 732 4.4.2. AF For Data Flows 734 The IWF to be used for multicast data flows is operated at the 735 boundary between IPv4 and IPv6 multicast networks. Either 736 encapsulation/de-capsulation or translation modes can be enforced, 737 depending on the design. Note that translation operations must 738 follow the algorithm specified in [RFC6145]. 740 4.4.3. Address Mapping 742 The address mapping mechanisms to be used in either a stateful or 743 stateless fashion need to be specified for the translation from one 744 address family to the other. 746 The address formats can be those defined in 747 [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for 748 IPv4-embedded IPv6 multicast and unicast addresses. Mapping 749 operations are performed in a stateless manner by the algorithms 750 specified in the aforementioned documents. 752 In this context, the IPv6 prefixes required for embedding IPv4 753 addresses can be assigned to devices that support IWF features by 754 various means (e.g., static or dynamic configuration, out-of-band 755 mechanisms, etc.). 757 If stateful approaches are used, it is recommended to carefully 758 investigate the need to synchronize mapping states between multiple 759 boxes, and the coordination of the IWF and source/group discovery 760 elements is also required, at the cost of extra complexity. 762 4.5. Combination of ASM and SSM Modes 764 The ASM (Any Source Multicast) mode could be used to optimize the 765 forwarding of IPv4 multicast traffic sent by different sources into 766 the IPv6 multicast domain by selecting RP routers that could be 767 located at the border between the IPv6 and the IPv4 multicast 768 domains. This design may optimize the multicast forwarding 769 efficiency in the IPv6 domain when access to several IPv4 multicast 770 sources needs to be granted. 772 5. IANA Considerations 774 This document makes no request to IANA. 776 Note to RFC Editor: this section may be removed on publication as an 777 RFC. 779 6. Security Considerations 781 Access to contents in a multicast-enabled environment raises 782 different security issues that have been already documented. In 783 particular: 785 o When translating ASM-SSM there are certain security expectations 786 from SSM (only receiving from the single specified sender), which 787 are not the same expectations that come from ASM. 789 o If mappings are not stateful, it may be harder to monitor and 790 troubleshoot the traffic. 792 o There are concepts of IPv4 and IPv6 multicast scopes. When 793 translating, it must be taken into account how to reasonably map 794 between scopes, and it is important that the scopes are configured 795 appropriately on the routers so that a scope intended to be within 796 a site for IPv4 (for example), doesn't leak outside the site due 797 to translation to IPv6 inside the site. 799 7. Acknowledgments 801 Special thanks to T. Taylor for providing the figures and some of the 802 text that illustrate the use cases depicted in Section 3. Thanks 803 also to H. Asaeda, M. Blanchet, M. Eubanks, B. Haberman, N. Leymann, 804 S. Perrault and S. Venaas for their valuable comments and support. 806 8. References 808 8.1. Normative References 810 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 811 2", RFC 2236, November 1997. 813 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 814 Thyagarajan, "Internet Group Management Protocol, Version 815 3", RFC 3376, October 2002. 817 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 818 Multicast (SSM)", RFC 3569, July 2003. 820 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 821 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 823 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 824 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 825 Protocol Specification (Revised)", RFC 4601, August 2006. 827 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 828 "Internet Group Management Protocol (IGMP) / Multicast 829 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 830 /MLD Proxying")", RFC 4605, August 2006. 832 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 833 Algorithm", RFC 6145, April 2011. 835 8.2. Informative References 837 [I-D.ietf-mboned-64-multicast-address-format] 838 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 839 M. Xu, "IPv6 Multicast Address With Embedded IPv4 840 Multicast Address", draft-ietf-mboned-64-multicast- 841 address-format-05 (work in progress), April 2013. 843 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 844 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 845 October 2010. 847 Authors' Addresses 848 Christian Jacquenet 849 France Telecom Orange 850 4 rue du Clos Courtel 851 Cesson-Sevigne 35512 852 France 854 Phone: +33 2 99 12 43 82 855 Email: christian.jacquenet@orange.com 857 Mohamed Boucadair 858 France Telecom Orange 859 4 rue du Clos Courtel 860 Cesson-Sevigne 35512 861 France 863 Phone: +33 2 99 12 43 71 864 Email: mohamed.boucadair@orange.com 866 Yiu Lee 867 Comcast 868 US 870 Email: Yiu_Lee@Cable.Comcast.com 872 Jacni Qin 873 Cisco Systems 874 People's Republic of China 876 Email: jacni@jacni.com 878 Tina Tsou 879 Huawei Technologies (USA) 880 2330 Central Expressway 881 Santa Clara, CA 95050 882 USA 884 Phone: +1 408 330 4424 885 Email: tena@huawei.com 886 Qiong Sun 887 China Telecom 888 Room 708, No.118, Xizhimennei Street 889 Beijing 100035 890 People's Republic of China 892 Phone: >+86-10-58552936 893 Email: sunqiong@ctbri.com.cn