idnits 2.17.1 draft-ietf-mboned-v4v6-mcast-ps-01.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 09, 2012) is 4183 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: 3 errors (**), 0 flaws (~~), 3 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: May 13, 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 November 09, 2012 15 IPv4-IPv6 Multicast: Problem Statement and Use Cases 16 draft-ietf-mboned-v4v6-mcast-ps-01 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 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 13, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Organization of the Document . . . . . . . . . . . . . . . 5 68 2. Scope and Service Requirements . . . . . . . . . . . . . . . . 5 69 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Service Requirements . . . . . . . . . . . . . . . . . . . 6 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. IPv4 Receiver and Source Connected to an IPv6-Only 73 Network . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. IPv6 Receiver and Source Connected to an IPv4-Only 75 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 11 77 3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 13 78 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15 80 4.1. Group and Source Discovery Considerations . . . . . . . . 15 81 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 16 83 4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 17 84 4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . . 17 85 4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 18 86 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 18 87 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 19 88 5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 19 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 Global IPv4 address depletion inevitably challenges service providers 100 who must guarantee IPv4 service continuity during the forthcoming 101 transition period. In particular, access to IPv4 contents that are 102 multicast to IPv4 receivers becomes an issue when the forwarding of 103 multicast data assumes the use of global IPv4 addresses. 105 The rarefaction of global IPv4 addresses may indeed affect the 106 multicast delivery of IPv4-formatted contents to IPv4 receivers. For 107 example, the observed evolution of ADSL broadband access 108 infrastructures from a service-specific, multi-PVC (Permanent Virtual 109 Circuit) scheme towards a "service-agnostic", single PVC scheme, 110 assumes the allocation of a globally unique IPv4 address on the WAN 111 (Wide Area Network) interface of the CPE (Customer Premises 112 Equipment), or to a mobile terminal), whatever the number and the 113 nature of the services the customer has subscribed to. 115 Likewise, the global IPv4 address depletion encourages the 116 development of IPv6 receivers while contents may very well remain 117 IPv4-formatted. There is therefore a need to make sure such IPv6 118 receivers can access IPv4-formatted contents during the transition 119 period. 121 During the transition period, the usage of the remaining global IPv4 122 address blocks will have to be rationalized for the sake of IPv4 123 service continuity. The current state-of-the-art suggests the 124 introduction of NAT (Network Address Translation) capabilities 125 (generally denoted as CGN, for Carrier-Grade NAT) in providers' 126 networks, so that a global IPv4 address will be shared between 127 several customers. 129 As a consequence, CPE or mobile UE (User Equipment) devices will no 130 longer be assigned a dedicated global IPv4 address anymore, and IPv4 131 traffic will be privately-addressed until it reaches one of the CGN 132 capabilities deployed in the network. From a multicast delivery 133 standpoint, this situation suggests the following considerations: 135 o The current design of some multicast-based services like TV 136 broadcasting often relies upon the use of a private IPv4 137 addressing scheme because of a walled garden approach. Privately- 138 addressed IGMP [RFC2236][RFC3376] traffic sent by IPv4 receivers 139 is generally forwarded over a specific (e.g., "IPTV") PVC towards 140 an IGMP Querier located in the access infrastructure, e.g., in 141 some deployments it is hosted by a BRAS (BRoadband Access Server) 142 device that is the PPP (Point-to-Point Protocol) session endpoint 143 and which may also act as a PIM DR (Protocol Independent Multicast 144 Designated Router)[RFC4601]. This design does not suffer from 145 global IPv4 address depletion by definition (since multicast 146 traffic relies upon the use of a private IPv4 addressing scheme), 147 but it is inconsistent with migrating the access infrastructure 148 towards a publicly-addressed single PVC design scheme. 150 o Likewise, other deployments (e.g., cable operators' environments) 151 rely upon the public CPE's address for multicast delivery and will 152 therefore suffer from IPv4 address depletion. 154 o The progressive introduction of IPv6 as the only perennial 155 solution to global IPv4 address depletion does not necessarily 156 assume that multicast-based IPv4 services will be migrated 157 accordingly. Access to IPv4 multicast contents when no global 158 IPv4 address can be assigned to a customer raises several issues: 159 (1) The completion of the IGMP-based multicast group subscription 160 procedure, (2) The computation of the IPv4 multicast distribution 161 tree, and (3) The IPv4-inferred addressing scheme to be used in a 162 networking environment which will progressively become IPv6- 163 enabled. 165 This document does not make any assumption on the techniques used for 166 the delivery of multicast traffic (e.g., native IP multicast with or 167 without traffic isolation features, etc.) 169 This document elaborates on the context and discusses multicast- 170 related issues and requirements. 172 1.1. Goals 174 The objective of this document is to clarify the problem space. In 175 particular, this document elaborates on the following issues: 177 o What are the hurdles encountered for the delivery of multicast- 178 based service offerings when both IPv4 and IPv6 co-exist? 180 o What standardization effort is needed: are there any missing 181 function and protocol extension? 183 o Does the work on multicast transition have to cover both 184 encapsulation and translation schemes, considering the requirement 185 of multicast network performance among others? 187 1.2. Terminology 189 This document uses the following terms: 191 o Multicast Source: Source of contents that are multicast to 192 receivers. A video streaming server is an example of such source. 194 o Multicast Receiver: Receiver, in short. A Set Top Box (STB) is an 195 example of such receiver. 197 o Multicast Delivery Network: Network in short, covers the realm 198 from Designated Routers that are directly connected to sources to 199 IGMP/MLD (Internet Group Management Protocol/Multicast Listener 200 Discovery) Querier devices that process IGMP/MLD signalling 201 traffic exchanged with receivers. 203 1.3. Organization of the Document 205 This document is organized as follows: 207 o Section 2 details basic requirements that should be addressed by 208 providers involved in the delivery of multicast-based services 209 during the transition period, 211 o Section 3 discusses several use cases that reflect issues raised 212 by the forthcoming transition period, 214 o Section 4 details design considerations, 216 o Section 5 summarizes the standardization effort that should be 217 tackled by the IETF. 219 2. Scope and Service Requirements 221 2.1. Scope 223 Intra-domain only: The delivery of multicast services such as live 224 TV broadcasting often relies upon walled garden designs that 225 restrict the scope to the domain where such services can be 226 subscribed. As a consequence, considerations about inter-domain 227 multicast are out of the scope of this document. 229 Multicast-enabled networks only: This document assumes that the 230 network is *IP multicast-enabled*. That is, whatever the IP 231 address family of the content, this content will be multicast 232 along distribution trees that should be terminated as close to the 233 receivers as possible for the sake of bandwidth optimization. In 234 other words, *considerations about forwarding multicast traffic 235 over unicast-only (access) networks are out of the scope of this 236 document.* 238 Multicast to the receivers, not from the receivers: This document 239 only covers the case where multicast traffic is forwarded by the 240 service provider network to the receivers. This document does not 241 cover the case where the receivers send multicast traffic to the 242 network. 244 2.2. Service Requirements 246 The delivery of multicast contents during the forthcoming transition 247 period needs to address the following requirements. Note that some 248 of these requirements are not necessarily specific to the IPv4-to- 249 IPv6 transition context, but rather apply to a wide range of 250 multicast-based services whatever the environmental constraints, but 251 the forthcoming transition period further stresses these requirements 252 (see Section 4.4.1 for more details). 254 o Optimize bandwidth. Contents SHOULD NOT be multicast twice (i.e., 255 using both versions of IP) to optimize bandwidth usage. Injecting 256 multicast content using both IPv4 and IPv6 raises some 257 dimensioning issues that should be carefully evaluated by service 258 providers during network planning operations. For instance, if 259 only few IPv6-enabled receivers are in use, it can be more 260 convenient to convey multicast traffic over IPv4 rather than 261 doubling the consumed resources for few users. IPv4/IPv6 co- 262 existence solutions SHOULD be designed to optimize network 263 resource utilization. 265 o Zap rapidly. The time it takes to switch from one content to 266 another MUST be as short as possible. For example, zapping times 267 between two TV channels should be in the magnitude of a few 268 seconds at most, whatever the conditions to access the multicast 269 network. A procedure called "IGMP fast-leave" is sometimes used 270 to minimize this issue so that the corresponding multicast stream 271 is stopped as soon as the IGMP Leave message is received by the 272 Querier. In current deployments, IGMP fast-leave often assumes 273 the activation of the IGMP Proxy function in DSLAMs. The 274 complexity of such design is aggravated within a context where 275 IPv4 multicast control messages are encapsulated in IPv6. 277 o Preserve the integrity of contents. Some contract agreements may 278 prevent a service provider from altering the content owned by the 279 content provider, because of copyright, confidentiality and SLA 280 assurance reasons. Multicast streams SHOULD be delivered without 281 altering their content. 283 o Preserve service quality. Crossing a CGN or performing multicast 284 packet encapsulation may lead to fragmentation or extra delays and 285 may therefore impact the perceived quality of service. Such 286 degradation MUST be avoided. 288 o Optimize IPv4-IPv6 inter-working design. In some operational 289 networks, a source-based stateful NAT function is sometimes used 290 for load balancing purposes, for example. Because of the 291 operational issues raised by such a stateful design, the 292 deployment of stateless IPv4-IPv6 interworking functions SHOULD be 293 privileged. 295 3. Use Cases 297 During the IPv4-to-IPv6 transition period, there might be a mix of 298 multicast receivers, sources, and networks running in different 299 address families. However, service providers must guarantee the 300 delivery of multicast services to IPv4 receivers and, presumably, 301 IPv6 receivers. Because of the inevitable combination of different 302 IP version-related environments (sources, receivers and networks), 303 service providers should carefully plan and choose the appropriate 304 technique that will optimize the network resources to deliver 305 multicast-based services. 307 Concretely, several use cases can be considered during the IPv4/ IPv6 308 co-existence period. Some of them are depicted in the following sub- 309 sections. 311 3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network 313 We refer to this scenario as 4-6-4. An example of such use case is a 314 DS-Lite environment, where customers will share global IPv4 315 addresses. IPv4 receivers are connected to CPE devices that are 316 provisioned with an IPv6 prefix only. Delivering multicast content 317 sent by an IPv4 source to such receivers requires the activation of 318 some adaptation functions (AFs). These may operate at the network 319 layer (interworking functions (IWF) or at the application layer 320 (application level gateways (ALGs)). 322 The signalling flow for the 4-6-4 use case is shown in Figure 1. 324 +------+ +-----+ +------+ +------+ 325 | Host | IGMP | DS | | MR | PIM | MR | 326 | Rcvr |------| AF1 | | | . . . . | | 327 | | IPv4 | | | (BG) | IPv4 | (DR) | 328 +------+ +-----+ +------+ +------+ 329 / \ 330 MLD / IPv6 PIM \ IPv4 331 / \ 332 +------+ +----+ +------+ 333 | MR | PIM | | PIM | DS | 334 | |------| MR | . . . | AF2 | 335 | (DR) | IPv6 | | IPv6 | (BG) | 336 +------+ +----+ +------+ 338 -------------------------------------> 340 Rcvr: Multicast receiver 341 DS : Dual Stack 342 AF : Adaptation Function (ALG or IWF) 343 MR : Multicast Router 344 DR : Designated Router 345 BG : Border Gateway 347 Figure 1: Signalling Path for the 4-6-4 Scenario. 349 AF1 refers to an IGMP/MLD Adaptation Function. Another Adaptation 350 Function AF2 is needed at the border between the IPv6 multicast 351 domain and the IPv4 multicast domain where the source resides. AF2 352 is typically embedded in a multicast router that either terminates or 353 propagates PIM signalling directed toward the IPv4 source in the IPv6 354 multicast domain. 356 On the IPv4 side, AF2 also acts as a multicast router, and uses PIMv4 357 signalling to join the IPv4 multicast group. The return path taken 358 by multicast traffic is shown in Figure 2. 360 +------+ +-----+ +------+ +------+ +-----+ 361 | Host | | DS | | MR | | MR | | | 362 | Rcvr |------| AF1 | | | . . . | |------| Src | 363 | | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | | 364 +------+ +-----+ +------+ +------+ +-----+ 365 / \ 366 / IPv6 \ IPv4 367 / \ 368 +------+ +----+ +------+ 369 | MR | | | | DS | 370 | |------| MR | . . . | AF2 | 371 | (DR) | IPv6 | | IPv6 | (BG) | 372 +------+ +----+ +------+ 374 <------------------------------------- 376 Rcvr: Multicast receiver 377 DS : Dual Stack 378 AF : Adaptation Function 379 MR : Multicast router 380 DR : Designated Router 381 BG : Border Gateway 382 Src : Multicast source 384 Figure 2: Multicast Traffic Forwarding Path for the 4-6-4 Scenario. 386 Again, adaptation functions are needed whenever the IP protocol 387 version changes. The adaptation function instance AF2 at the 388 boundary between the source network and the IPv6 network may either 389 encapsulate or translate the headers of the IPv4 packets to allow the 390 content to cross the IPv6 network. The adaptation function instance 391 at the boundary between the IPv6 network and the receiver network 392 performs the reverse operation to deliver IPv4 packets. 394 Given the current state-of-the-art where multicast content is likely 395 to remain IPv4-formatted while receiver devices such as Set Top Boxes 396 will also remain IPv4-only for quite some time, this scenario is 397 prioritized by some service providers, including those that are 398 deploying or will deploy DS-Lite CGN capabilities for the sake of 399 IPv4 service continuity. 401 3.2. IPv6 Receiver and Source Connected to an IPv4-Only Network 403 We refer to this scenario as 6-4-6. Since providers who own the 404 multicast content may not be ready for IPv6 migration beofre some 405 time, the content is likely to remain IPv4-formatted. As a 406 consequence, this 6-4-6 scenario is of lower priority than the 4-6-4 407 scenario. 409 The signalling path for the 6-4-6 scenario is illustrated in Figure 410 3. 412 +------+ +-----+ +------+ +------+ 413 | Host | MLD | DS | | MR | PIM | MR | 414 | Rcvr |------| AF1 | | | . . . . | | 415 | | IPv6 | | | (BG) | IPv6 | (DR) | 416 +------+ +-----+ +------+ +------+ 417 / \ 418 IGMP / IPv4 PIM \ IPv6 419 / \ 420 +------+ +----+ +------+ 421 | MR | PIM | | PIM | DS | 422 | |------| MR | . . . | AF2 | 423 | (DR) | IPv4 | | IPv4 | (BG) | 424 +------+ +----+ +------+ 426 -------------------------------------> 428 Rcvr: Multicast receiver 429 DS : Dual Stack 430 AF : Adaptation Function 431 MR : Multicast Router 432 DR : Designated Router 433 BG : Border Gateway 435 Figure 3: Signalling Path For the 6-4-6 Scenario. 437 Figure 4 shows the path taken by multicast traffic flowing from the 438 IPv6 source to the IPv6 receiver. 440 +------+ +-----+ +------+ +------+ 441 | Host | | DS | | MR | | MR | 442 | Rcvr |------| AF1 | | | . . . | | 443 | | IPv6 | | | (BG) | IPv6 | (DR) | 444 +------+ +-----+ +------+ +------+ 445 / \ \ 446 / IPv4 \ IPv6 \ IPv6 447 / \ \ 448 +------+ +----+ +------+ +-----+ 449 | MR | | | | DS | | | 450 | |------| MR | . . . | AF2 | | Src | 451 | (DR) | IPv4 | | IPv4 | (BG) | | | 452 +------+ +----+ +------+ +-----+ 454 <------------------------------------- 456 Rcvr: Multicast receiver 457 DS : Dual Stack 458 AF : Adaptation Function 459 MR : Multicast Router 460 DR : Designated Router 461 BG : Border Gateway 462 Src : Multicast source 464 Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario. 466 3.3. IPv6 Receiver and IPv4 Source 468 We refer to this scenario as 6-4. An example of such use case is the 469 context of some mobile networks, where terminal devices are only 470 provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast 471 content from an IPv6-only receiver requires additional functions to 472 be enabled. 474 This scenario is privileged by mobile operators who deploy NAT64 475 capabilities in their network. It is illustrated in Figures 5 476 (signalling path) and 6 (forwarding of multicast traffic). Only one 477 adaptation function instance is needed, and it will be located at the 478 IPv4/IPv6 multicast domain boundary. 480 +------+ +------+ +------+ 481 | Host | | MR | PIM | MR | 482 | Rcvr | | | . . . . | | 483 | | | (BG) | IPv4 | (DR) | 484 +------+ +------+ +------+ 485 \ \ 486 MLD \ IPv6 PIM \ IPv4 487 \ \ 488 +------+ +----+ +------+ 489 | MR | PIM | | PIM | DS | 490 | |------| MR | . . . | AF1 | 491 | (DR) | IPv6 | | IPv6 | (BG) | 492 +------+ +----+ +------+ 494 -------------------------------------> 496 Rcvr: Multicast receiver 497 DS : Dual Stack 498 AF : Adaptation Function 499 MR : Multicast Router 500 DR : Designated Router 501 BG : Border Gateway 503 Figure 5: Signalling Path For the 6-4 Scenario. 505 +------+ +------+ +------+ 506 | Host | | MR | | MR | 507 | Rcvr | | | . . . . | | 508 | | | (BG) | IPv4 | (DR) | 509 +------+ +------+ +------+ 510 \ \ \ 511 \ IPv6 \ IPv4 \ IPv4 512 \ \ \ 513 +------+ +----+ +------+ +-----+ 514 | MR | | | | DS | | | 515 | |------| MR | . . . | AF1 | | Src | 516 | (DR) | IPv6 | | IPv6 | (BG) | | | 517 +------+ +----+ +------+ +-----+ 519 <------------------------------------- 521 Rcvr: Multicast receiver 522 DS : Dual Stack 523 AF : Adaptation Function 524 MR : Multicast Router 525 DR : Designated Router 526 BG : Border Gateway 527 Src : Multicast source 529 Figure 6: Multicast Traffic Forwarding Path For the 6-4 Scenario. 531 3.4. IPv4 Receiver and IPv6 Source 533 We refer to this scenario as 4-6. Yet, multicast sources are likely 534 to remain IPv4-enabled in a first stage; therefore, the content is 535 likely to remain IPv4-formatted. As a consequence, this scenario is 536 unlikely to occur during the first years of the transition period. 538 The signalling path for this scenario is shown in Figure 7. The 539 multicast traffic forwarding path is shown in Figure 8. There are 540 similarities with the 6-4 scenario but address mapping across IP 541 version boundaries is more challenging. 543 +------+ +------+ +------+ 544 | Host | | MR | PIM | MR | 545 | Rcvr | | | . . . . | | 546 | | | (BG) | IPv6 | (DR) | 547 +------+ +------+ +------+ 548 \ \ 549 IGMP \ IPv4 PIM \ IPv6 550 \ \ 551 +------+ +----+ +------+ 552 | MR | PIM | | PIM | DS | 553 | |------| MR | . . . | AF1 | 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 566 Figure 7: Signalling Path For the 4-6 Scenario. 568 +------+ +------+ +------+ 569 | Host | | MR | | MR | 570 | Rcvr | | | . . . . | | 571 | | | (BG) | IPv6 | (DR) | 572 +------+ +------+ +------+ 573 \ \ \ 574 \ IPv4 \ IPv6 \ IPv6 575 \ \ \ 576 +------+ +----+ +------+ +-----+ 577 | MR | | | | DS | | | 578 | |------| MR | . . . | AF1 | | Src | 579 | (DR) | IPv4 | | IPv4 | (BG) | | | 580 +------+ +----+ +------+ +-----+ 582 <------------------------------------- 584 Rcvr: Multicast receiver 585 DS : Dual Stack 586 AF : Adaptation Function 587 MR : Multicast Router 588 DR : Designated Router 589 BG : Border Gateway 590 Src : Multicast source 592 Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario. 594 3.5. Summary 596 To summarize, the use cases of highest priority are those involving 597 IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios. 599 4. Design Considerations 601 4.1. Group and Source Discovery Considerations 603 Multicast applications that embed address information in the payload 604 may require Application Level Gateway (ALG) during the transition 605 period. An ALG is application-specific by definition, and may 606 therefore be unnecessary depending on the nature of the multicast 607 service. 609 Such ALG (Application Level Gateway) may also be required to help an 610 IPv6 receiver select the appropriate multicast group address when 611 only the IPv4 address is advertised (e.g., when the SDP (Session 612 Description Protocol) protocol is used to advertise some contents); 613 otherwise, access to IPv4 multicast content from an IPv6 receiver may 614 be compromised. 616 ALGs may be located upstream in the network. As a consequence, these 617 ALGs do not know in advance whether the receiver is dual-stack or 618 IPv6-only. In order to avoid the use of an ALG in the path, an IPv4- 619 only source can advertise both an IPv4 multicast group address and 620 the corresponding IPv4-embedded IPv6 multicast group address 621 [I-D.ietf-mboned-64-multicast-address-format]. 623 However, a dual-stack receiver may prefer to use the IPv6 address to 624 receive the multicast content. The selection of the IPv6 multicast 625 address would then require multicast flows to cross an IPv4-IPv6 626 interworking function. 628 The receiver should therefore be able to unambiguously distinguish an 629 IPv4-embedded IPv6 multicast address from a native IPv6 multicast 630 address. 632 4.2. Subscription 634 Multicast distribution trees are receiver-initiated. IPv4 receivers 635 that want to subscribe to an IPv4 multicast group will send the 636 corresponding IGMP Report message towards the relevant IGMP Querier. 637 In case the underlying access network is IPv6, the information 638 conveyed in IGMP messages should be relayed by corresponding MLD 639 messages. 641 4.3. Multicast Tree Computation 643 Grafting to an IPv4 multicast distribution tree through an IPv6 644 multicast domain suggests that IPv4 multicast traffic will have to be 645 conveyed along an "IPv6-equivalent" multicast distribution tree. 646 That is, part of the multicast distribution tree along which IPv4 647 multicast traffic will be forwarded SHOULD be computed and maintained 648 by means of the PIMv6 machinery, so that the distribution tree can be 649 terminated as close to the IPv4 receivers as possible for the sake of 650 the multicast forwarding efficiency. This assumes a close 651 interaction between the PIM designs enforced in both IPv4 and IPv6 652 multicast domains, by means of specific Inter-Working Functions that 653 are further discussed in Section 4.4. 655 Such interaction may be complicated by different combinations: the 656 IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point) 657 routers), while the IPv6 multicast domain may support both ASM (Any 658 Source Multicast) and SSM (Source Specific Multicast) [RFC3569] 659 modes. 661 4.4. Multicast Adaptation Functions (AF) 663 IPv4-IPv6 multicast interworking functions are required for both 664 translation (one address family to another) and traversal (one 665 address family over another) contexts. 667 Given the multiple versions of Group Membership management protocols, 668 issues may be raised when, for example, IGMPv2 is running in the IPv4 669 multicast domain that is connected to the IPv6 multicast domain by 670 means of an IWF, while MLDv2 is running in the IPv6 multicast domain. 671 To solve these problems, the design of the IWF function SHOULD adhere 672 to the IP version-independent, protocol interaction approach 673 documented in Section 8 of [RFC3810] and Section 7 of [RFC3376]. 675 Note that, for traversal cases, to improve the efficiency of the 676 multicast service delivery, traffic will be multicast along 677 distribution trees that should be terminated as close to the 678 receivers as possible for bandwidth optimization purposes. As a 679 reminder, the traversal of unicast-only (access) networks is not 680 considered in this document. 682 4.4.1. AF For Control Flows 684 The IWF to process multicast signalling flows (such as IGMP or MLD 685 Report messages) should be independent of the IP version and consist 686 mainly of an IPv4-IPv6 adaptation element and an IP address 687 translation element. The message format adaptation must follow what 688 is specified in [RFC3810] or [RFC4601], and the device that embeds 689 the IWF device must be multicast-enabled, i.e., support IGMP, MLD 690 and/or PIM, depending on the context (address family-wise) and the 691 design (e.g., this device could be a PIM DR in addition to a MLD 692 Querier). 694 The IWF can then be operated in the following modes: IGMP-MLD, PIMv4- 695 PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-Specific 696 Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 signalling 697 traffic as well as the ability to directly send PIM (S, G) Join 698 messages towards the source). 700 The following sub-sections describe some interworking functions which 701 may be solicited, depending on the environment. 703 4.4.1.1. IGMP-MLD Interworking 705 The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying 706 function specified in [RFC4605] and the IGMP/MLD adaptation function 707 which is meant to reflect the contents of IGMP messages into MLD 708 messages, and vice versa. 710 For example, when an IGMP Report message is received to subscribe to 711 a given multicast group (which may be associated to a source address 712 if SSM mode is used), the IGMP-MLD Interworking Function MUST send an 713 MLD Report message to subscribe to the corresponding IPv6 multicast 714 group. 716 4.4.1.2. IPv4-IPv6 PIM Interworking 718 [RFC4601] allows the computation of PIM-based IPv4 or IPv6 719 distribution trees; PIM is IP version agnostic. There is no specific 720 IPv6 PIM machinery that would work differently than an IPv4 PIM 721 machinery. The new features needed for the IPv4-IPv6 PIM 722 Interworking Function consist in dynamically triggering the PIM 723 message of Address Family 1 upon receipt of the equivalent PIM 724 message of Address Family 2. 726 The address mapping MUST be performed similarly to that of the IGMP- 727 MLD Interworking Function. 729 4.4.1.3. MLD-IPv4 PIM Interworking 731 This IWF function is required when the MLD Querier is connected to an 732 IPv4 PIM domain. 734 The address mapping MUST be performed similarly to that of the IGMP- 735 MLD Interworking Function. 737 4.4.1.4. IGMP-IPv6 PIM Interworking 739 The address mapping MUST be performed similarly to that of the IGMP- 740 MLD Interworking Function. 742 4.4.2. AF For Data Flows 744 The IWF to be used for multicast data flows is operated at the 745 boundary between IPv4 and IPv6 multicast networks. Either 746 encapsulation/de-capsulation or translation modes can be enforced, 747 depending on the design. Note that translation operations must 748 follow the algorithm specified in [RFC6145]. 750 4.4.3. Address Mapping 752 The address mapping mechanisms to be used in either a stateful or 753 stateless fashion need to be specified for the translation from one 754 address family to the other. 756 The address formats have been defined in 757 [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for IPv4- 758 embedded IPv6 multicast and unicast addresses. Mapping operations 759 are performed in a stateless manner by the algorithms specified in 760 the aforementioned documents. 762 In this context, the IPv6 prefixes required for embedding IPv4 763 addresses can be assigned to devices that support IWF features by 764 various means (e.g., static or dynamic configuration, out-of-band 765 mechanisms, etc.). 767 If stateful approaches are used, it is recommended to carefully 768 investigate the need to synchronize mapping states between multiple 769 boxes, and the coordination of the IWF and source/group discovery 770 elements is also required, at the cost of extra complexity. 772 4.5. Combination of ASM and SSM Modes 774 The ASM (Any Source Multicast) mode could be used to optimize the 775 forwarding of IPv4 multicast traffic sent by different sources into 776 the IPv6 multicast domain by selecting RP routers that could be 777 located at the border between the IPv6 and the IPv4 multicast 778 domains. This design may optimize the multicast forwarding 779 efficiency in the IPv6 domain when access to several IPv4 multicast 780 sources needs to be granted. 782 5. What Is Expected From The IETF 784 This document highlights the following IETF standardization needs: 786 o Specify the inter-working function as described in Sections 4.4.1 787 and 4.4.2. In particular: 789 * Specify the algorithms used by various inter-working functions, 790 covering both encapsulation and translation approaches 792 * Specify the multicast IPv4-embedded address format 794 * Document a 6-4 multicast architecture 796 * Document a 4-6-4 multicast architecture 798 o Document a Management Information Base (MIB) to be used for the 799 management of IWF functions 801 o Encourage the publication of various Applicability Statement 802 documents to reflect IWF operational experience in different 803 contexts 805 6. IANA Considerations 807 This document makes no request to IANA. 809 Note to RFC Editor: this section may be removed on publication as an 810 RFC. 812 7. Security Considerations 814 Access to contents in a multicast-enabled environment raises 815 different security issues that have been already documented. This 816 draft does not introduce any specific security issue. 818 8. Acknowledgments 820 Special thanks to T. Taylor for providing the figures and some of the 821 text that illustrate the use cases depicted in Section 3. Thanks 822 also to H. Asaeda, M. Eubanks, N. Leymann and S. Venaas for their 823 valuable comments. 825 9. References 827 9.1. Normative References 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, March 1997. 832 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 833 2", RFC 2236, November 1997. 835 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 836 Thyagarajan, "Internet Group Management Protocol, Version 837 3", RFC 3376, October 2002. 839 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 840 Multicast (SSM)", RFC 3569, July 2003. 842 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 843 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 845 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 846 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 847 Protocol Specification (Revised)", RFC 4601, August 2006. 849 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 850 "Internet Group Management Protocol (IGMP) / Multicast 851 Listener Discovery (MLD)-Based Multicast Forwarding 852 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 854 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 855 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 856 October 2010. 858 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 859 Algorithm", RFC 6145, April 2011. 861 9.2. Informative References 863 [I-D.ietf-mboned-64-multicast-address-format] 864 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 865 M. Xu, "IPv6 Multicast Address With Embedded IPv4 866 Multicast Address", 867 draft-ietf-mboned-64-multicast-address-format-04 (work in 868 progress), August 2012. 870 Authors' Addresses 872 Christian Jacquenet 873 France Telecom Orange 874 4 rue du Clos Courtel 875 Cesson-Sevigne 35512 876 France 878 Phone: +33 2 99 12 43 82 879 Email: christian.jacquenet@orange.com 881 Mohamed Boucadair 882 France Telecom Orange 883 4 rue du Clos Courtel 884 Cesson-Sevigne 35512 885 France 887 Phone: +33 2 99 12 43 71 888 Email: mohamed.boucadair@orange.com 889 Yiu Lee 890 Comcast 891 US 893 Email: Yiu_Lee@Cable.Comcast.com 895 Jacni Qin 896 Cisco Systems 897 People's Republic of China 899 Email: jacni@jacni.com 901 Tina Tsou 902 Huawei Technologies (USA) 903 2330 Central Expressway 904 Santa Clara, CA 95050 905 USA 907 Phone: +1 408 330 4424 908 Email: tena@huawei.com 910 Qiong Sun 911 China Telecom 912 Room 708, No.118, Xizhimennei Street 913 Beijing 100035 914 People's Republic of China 916 Phone: >+86-10-58552936 917 Email: sunqiong@ctbri.com.cn