idnits 2.17.1 draft-jaclee-behave-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 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 02, 2011) is 4552 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3810' is mentioned on line 846, but not defined == Missing Reference: 'RFC6145' is mentioned on line 906, but not defined ** Obsolete undefined reference: RFC 6145 (Obsoleted by RFC 7915) == Missing Reference: 'RFC6052' is mentioned on line 915, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group C. Jacquenet 3 Internet-Draft M. Boucadair 4 Intended status: Informational France Telecom 5 Expires: May 5, 2012 Y. Lee 6 Comcast 7 J. Qin 8 ZTE 9 T. Tsou 10 Huawei Technologies (USA) 11 November 02, 2011 13 IPv4-IPv6 Multicast: Problem Statement and Use Cases 14 draft-jaclee-behave-v4v6-mcast-ps-03 16 Abstract 18 This document discusses issues and requirements raised by IPv4-IPv6 19 multicast interconnection and co-existence scenarios. It also 20 discusses various multicast use cases which may occur during IPv6 21 transitioning. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 5, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.3. Organization of the Document . . . . . . . . . . . . . . . 5 67 2. Discussion and Service Requirements . . . . . . . . . . . . . 5 68 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Issues Raised by the Transition Period . . . . . . . . . . 6 70 2.3. Service Requirements . . . . . . . . . . . . . . . . . . . 7 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. IPv4 Receiver and Source Connected to an IPv6-Only 73 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2. IPv6 Receiver Connected to an IPv4 Source Through an 75 IPv4 Multicast-Disabled Access Network and an IPv6 76 Multicast Network . . . . . . . . . . . . . . . . . . . . 11 77 3.3. IPv6 Receiver and Source Connected to an IPv4-Only 78 Network . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.4. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 15 80 3.5. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 17 81 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 19 83 4.1. Group and Source Discovery Considerations . . . . . . . . 19 84 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 20 85 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 20 86 4.4. Multicast Interworking Functions (IWF) . . . . . . . . . . 21 87 4.4.1. IWF For Control Flows . . . . . . . . . . . . . . . . 21 88 4.4.2. IWF For Data Flows . . . . . . . . . . . . . . . . . . 22 89 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 22 90 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 23 91 5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 23 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 In current deployments, the IP multicast forwarding scheme is used by 103 many service providers to deliver some services, such as live TV 104 broadcasting services. Multiple players intervene in the delivery of 105 these services, including content and service providers. Service 106 providers are responsible for carrying multicast flows from head-ends 107 to receivers. The content can be supplied by a service provider or 108 by other providers (e.g., case of externally paid channels). 110 Transition to IPv6 raises issues and corresponding requirements. In 111 particular, IPv4 service continuity is an essential requirement from 112 a business perspective. This specifically includes continued 113 receiver access to IPv4-formatted contents even when the assignment 114 of a dedicated global IPv4 address to the receiver is no longer 115 possible and even after the receivers have migrated to IPv6. 116 Likewise, the delivery of IPv6-formatted contents to IPv4 receivers 117 must also be possible. 119 Finally, in cases where the underlying transport network is of a 120 different address family from that of the source and/or receivers, 121 the delivery of multicast data must still be guaranteed. For 122 example, in DS-Lite environments, the (access) network is IPv6- 123 enabled, but both multicast sources and receivers are likely to 124 remain IPv4-only. 126 This document does not make any assumption on the techniques used for 127 the delivery of multicast traffic (e.g., native IP multicast with or 128 without traffic isolation features, etc.). 130 This document further elaborates on the context and discusses 131 multicast-related issues and requirements. 133 1.1. Goals 135 The objective of this document is to clarify the problem space. In 136 particular, this document further elaborates on the following issues: 138 o What are the hurdles encountered for the delivery of multicast- 139 based service offerings when both IPv4 and IPv6 co-exist? 141 o What standardization effort is needed: are there any missing 142 function and protocol extensions? 144 o Does the work on multicast transition have to cover both 145 encapsulation and translation schemes, considering the requirement 146 of multicast network performance among others? 148 1.2. Terminology 150 This document uses the following terms: 152 o Multicast Source: Source, in short 154 o Multicast Receiver: Receiver, in short, e.g., STB (Set Top Box) 156 o Multicast Delivery Network: Network in short, covers the realm 157 from Designated Routers that are directly connected to sources to 158 IGMP/MLD (Internet Group Management Protocol/Multicast Listener 159 Discovery) Querier devices that process IGMP/MLD signalling 160 traffic exchanged with receivers. 162 1.3. Organization of the Document 164 This document is organized as follows: 166 o Section 2 details basic requirements that should be addressed by 167 providers involved in the delivery of multicast-based services 168 during the transition period, 170 o Section 3 discusses several use cases that reflect issues raised 171 by the forthcoming transition period, 173 o Section 4 details design considerations, 175 o Section 5 summarizes the standardization effort that should be 176 tackled by the IETF. 178 2. Discussion and Service Requirements 180 2.1. Scope 182 Intra-domain only: The delivery of multicast services such as live 183 TV broadcasting often relies upon walled garden designs that 184 restrict the scope to the domain where such services can be 185 subscribed. As a consequence, considerations about inter-domain 186 multicast are out of the scope of this document. 188 Multicast-enabled networks only: This document assumes that the 189 network is IP multicast-enabled. That is, whatever the IP address 190 family of the content, the latter will be multicast along 191 distribution trees that should be terminated as close to the 192 receivers as possible for the sake of bandwidth optimization. In 193 other words, considerations about forwarding multicast traffic 194 over unicast-only (access) networks is out of the scope of this 195 document. 197 Multicast to the receivers, not from the receivers: This document 198 only covers the case where multicast traffic is forwarded by the 199 service provider network to the receivers. This document does not 200 cover the case where the receivers send multicast traffic to the 201 network. 203 2.2. Issues Raised by the Transition Period 205 Global IPv4 address depletion inevitably challenges service providers 206 who must guarantee IPv4 service continuity during the forthcoming 207 transition period. In particular, access to IPv4 contents that are 208 multicast to IPv4 receivers becomes an issue when the forwarding of 209 multicast data assumes the use of global IPv4 addresses. 211 The rarefaction of global IPv4 addresses may indeed affect the 212 multicast delivery of IPv4-formatted contents to IPv4 receivers. For 213 example, the observed evolution of ADSL broadband access 214 infrastructures from a service-specific, multi-PVC (Permanent Virtual 215 Circuit) scheme towards a "service-agnostic", single PVC scheme, 216 assumes the allocation of a globally unique IPv4 address on the WAN 217 (Wide Area Network) interface of the CPE (Customer Premises 218 Equipment), or to a mobile terminal), whatever the number and the 219 nature of the services the customer has subscribed to. 221 Likewise, the global IPv4 address depletion encourages the 222 development of IPv6 receivers while contents may very well remain 223 IPv4-formatted. There is therefore a need to make sure such IPv6 224 receivers can access IPv4-formatted contents during the transition 225 period. 227 During the transition period, the usage of the remaining global IPv4 228 address blocks will have to be rationalized for the sake of IPv4 229 service continuity. The current state-of-the-art suggests the 230 introduction of NAT (Network Address Translation) capabilities 231 (generally denoted as CGN, for Carrier-Grade NAT) in providers' 232 networks, so that a global IPv4 address will be shared between 233 several customers. As a consequence, CPE or mobile UE (User 234 Equipment) devices will no longer be assigned a dedicated global IPv4 235 address anymore, and IPv4 traffic will be privately-addressed until 236 it reaches one of the CGN capabilities deployed in the network. 238 From a multicast delivery standpoint, this situation suggests the 239 following considerations: 241 o The current design of some multicast-based services like TV 242 broadcasting often relies upon the use of a private IPv4 243 addressing scheme because of a walled garden approach. Privately- 244 addressed IGMP [RFC2236] [RFC3376] traffic sent by IPv4 receivers 245 is generally forwarded over a specific (e.g. "IPTV") PVC towards 246 an IGMP Querier located in the access infrastructure, e.g.- in 247 some deployments it is hosted by a BRAS (BRoadband Access Server) 248 device that is the PPP (Point-to-Point Protocol) session endpoint 249 and which may also act as a PIM DR (Protocol Independent Multicast 250 Designated Router)[RFC4601] router. This design does not suffer 251 from global IPv4 address depletion by definition (since multicast 252 traffic relies upon the use of a private IPv4 addressing scheme), 253 but it is inconsistent with migrating the access infrastructure 254 towards a publicly-addressed single PVC design scheme. 256 o Likewise, other deployments (e.g., cable operators' environments) 257 rely upon the public CPE's address for multicast delivery and will 258 therefore suffer from IPv4 address depletion. 260 o The progressive introduction of IPv6 as the only perennial 261 solution to global IPv4 address depletion does not necessarily 262 assume that multicast-based IPv4 services will be migrated 263 accordingly. Access to IPv4 multicast contents when no global 264 IPv4 address can be assigned to a customer anymore raises several 265 issues: (1) The completion of the IGMP-based multicast group 266 subscription procedure, (2) The computation of the IPv4 multicast 267 distribution tree, and (3) The IPv4-inferred addressing scheme to 268 be used in a networking environment which will progressively 269 become IPv6-enabled. 271 2.3. Service Requirements 273 Given the issues highlighted in Section 2.2, the delivery of 274 multicast contents during the forthcoming transition period needs to 275 address the following requirements. Note that some of these 276 requirements are not necessarily specific to the IPv4-to-IPv6 277 transition context, but rather apply to a wide range of multicast- 278 based services whatever the environmental constraints. 280 But the forthcoming transition period further stresses these 281 requirements (see Section 4.4.1 for more details). 283 o Service_REQ-1: Optimize bandwidth. Contents SHOULD NOT be 284 multicast twice (using both versions of IP) for the sake of 285 bandwidth optimization. Injecting multicast content using both 286 IPv4 and IPv6 raises some dimensioning issues that should be 287 carefully evaluated by service providers during network planning 288 operations. For instance, if only few IPv6- enabled receivers are 289 in use, it can be more convenient to convey multicast traffic over 290 IPv4 rather than doubling the consumed resources for few users. 291 IPv4/IPv6 co-existence solutions SHOULD be designed to optimize 292 network resource utilization. 294 o Service_REQ-2: Zap rapidly. The time it takes to switch from one 295 content to another MUST be as short as possible. For example, 296 zapping times between two TV channels should be in the magnitude 297 of a few seconds at most, whatever the conditions to access the 298 multicast network. A procedure called "IGMP fast-leave" is 299 sometimes used to minimize this issue so that the corresponding 300 multicast stream is stopped as soon as the IGMP Leave message is 301 received by the Querier. In current deployments, IGMP fast-leave 302 often assumes the activation of the IGMP Proxy function in DSLAMs. 303 The complexity of such design is aggravated within a context where 304 IPv4 multicast control messages are encapsulated in IPv6. 306 o Service_REQ-3: Preserve the integrity of contents. Some contract 307 agreements may prevent a service provider from altering the 308 content owned by the content provider, because of copyright, 309 confidentiality and SLA assurance reasons. Multicast streams 310 SHOULD be delivered without altering their content. 312 o Service_REQ-4: Preserve service quality. Crossing a CGN or 313 performing multicast packet encapsulation may lead to 314 fragmentation or extra delays and may therefore impact the 315 perceived quality of service. Such degradation MUST be avoided. 317 o Service_REQ-5: Optimize IPv4-IPv6 inter-working design. In some 318 operational networks, a source-based stateful NAT function is 319 sometimes used for load balancing purposes, for example. Because 320 of the operational issues raised by such a stateful design, the 321 deployment of stateless IPv4-IPv6 interworking functions SHOULD be 322 privileged. 324 3. Use Cases 326 During the forthcoming IPv4-to-IPv6 transition period, there might be 327 a mix of multicast receivers, sources, and networks running in 328 different address families. However, service providers must 329 guarantee the delivery of multicast services to IPv4 receivers and, 330 presumably, IPv6 receivers. Because of the inevitable combination of 331 different IP version-related environments (sources, receivers and 332 networks), service providers should carefully plan and choose the 333 right transition technique that will optimize the network resources 334 to deliver multicast-based services. 336 Concretely, several use cases can be considered during the IPv4/ IPv6 337 co-existence period. Some of them are depicted in the following sub- 338 sections. 340 3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network 342 We refer to this scenario as 4-6-4. An example of such use case is a 343 DS-Lite environment, where customers will share global IPv4 344 addresses. IPv4 receivers are connected to CPE devices that are 345 provisioned with an IPv6 prefix only. Delivering multicast content 346 sent by an IPv4 source to such receivers requires the activation of 347 some adaptation functions (AFs). These may operate at the network 348 layer (interworking functions (IWF) or at the application layer 349 (application level gateways (ALGs)). 351 The signalling flow for the 4-6-4 use case is shown in Figure 1. 353 +------+ +-----+ +------+ +------+ 354 | Host | Sig1 | DS | | MR | PIM | MR | 355 | Rcvr |------| AF1 | | | . . . . | | 356 | | IPv4 | | | (BG) | IPv4 | (DR) | 357 +------+ +-----+ +------+ +------+ 358 / \ 359 MLD / IPv6 PIM \ IPv4 360 / \ 361 +------+ +----+ +------+ 362 | MR | PIM | | PIM | DS | 363 | |------| MR | . . . | AF2 | 364 | (DR) | IPv6 | | IPv6 | (BG) | 365 +------+ +----+ +------+ 367 -------------------------------------> 369 Rcvr: Multicast receiver 370 DS : Dual Stack 371 AF : Adaptation Function (ALG or IWF) 372 MR : Multicast Router 373 DR : Designated Router 374 BG : Border Gateway 376 Figure 1: Signalling Path for the 4-6-4 Scenario. 378 Sig1 denotes the signalling protocol used by the host. If the 379 adaptation function AF1 to which it sends this signalling is an ALG, 380 Sig1 will be an application-layer protocol such as HTTP or SIP. If 381 the adaptation function is an interworking function, Sig1 will be 382 IGMP. If the adaptation function is collocated with the multicast 383 router at the edge of the IPv6 network, the intermediate MLD step can 384 be avoided. 386 Another dual stack adaptation function AF2 is needed at the border 387 between the IPv6 multicast domain and the IPv4 multicast domain where 388 the source resides. This device acts as a multicast router either 389 terminating or interworking PIM signalling in the IPv6 network 390 directed toward the source, depending on whether it is acting as an 391 ALG or as an IWF. 393 On the IPv4 side, AF2 also acts as a multicast router, and uses PIMv4 394 signalling to join the IPv4 multicast group. If AF2 is acting as an 395 ALG, the PIMv4 signalling is triggered by application-level 396 signalling or management action. If AF2 is acting as an interworking 397 function, the PIMv4 signalling is triggered by the arrival of PIMv6 398 signalling directed toward the source. 400 The return path taken by the multicast content is shown in Figure 2. 402 +------+ +-----+ +------+ +------+ +-----+ 403 | Host | | DS | | MR | | MR | | | 404 | Rcvr |------| AF1 | | | . . . | |------| Src | 405 | | IPv4 | | | (BG) | IPv4 | (DR) | IPv4 | | 406 +------+ +-----+ +------+ +------+ +-----+ 407 / \ 408 / IPv6 \ IPv4 409 / \ 410 +------+ +----+ +------+ 411 | MR | | | | DS | 412 | |------| MR | . . . | AF2 | 413 | (DR) | IPv6 | | IPv6 | (BG) | 414 +------+ +----+ +------+ 416 <------------------------------------- 418 Rcvr: Multicast receiver 419 DS : Dual Stack 420 AF : Adaptation Function 421 MR : Multicast router 422 DR : Designated Router 423 BG : Border Gateway 424 Src : Multicast source 426 Figure 2: Multicast Content Distribution Path for the 4-6-4 Scenario. 428 Again, adaptation functions are needed whenever the IP protocol 429 version changes. The adaptation function instance AF2 at the 430 boundary between the source network and the IPv6 network may either 431 encapsulate or translate the headers of the IPv4 packets to allow the 432 content to cross the IPv6 network - note that encapsulation requires 433 knowledge that the receiver is IPv4. The adaptation function 434 instance at the boundary between the IPv6 network and the receiver 435 network performs the reverse operation to deliver IPv4 packets. 437 Given the current state-of-the-art where multicast content is likely 438 to remain IPv4-formatted while receiver devices such as Set Top Boxes 439 will also remain IPv4-only for quite some time, this scenario is 440 prioritized by some service providers, including those that are 441 deploying or will deploy DS-Lite CGN capabilities for the sake of 442 IPv4 service continuity. 444 3.2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 445 Multicast-Disabled Access Network and an IPv6 Multicast Network 447 One major provider faces a complex transitional situation where the 448 receiver is IPv6, the CPE router is dual stack but is provided by the 449 customer, and the IPv4 access network is not multicast capable. The 450 IPv4 access network connects to an IPv6 network that is multicast 451 capable, and which in turn connects to IPv4 sources. 453 This scenario is denoted as the 6-4-6-4 scenario. 455 Because the provider does not manage the CPE router, encapsulation of 456 IPv6 packets across the IPv4 network is unlikely. Figure 3 shows the 457 signalling path for this scenario. 459 +------+ +-----+ +----+ +------+ 460 | Host | Sig1 | DS | Sig1 | | Sig1 | DS | 461 | Rcvr |------| AF0 |------| PE | . . .| AF1 | 462 | | IPv6 |(CPE)| IPv4 | | IPv4 | (BG) | 463 +------+ +-----+ +----+ +------+ 464 / 465 -----------------<---------- 466 / MLD over IPv6 467 +------+ +----+ +------+ 468 | MR | PIM | | PIM | DS | 469 | |------| MR | . . . | AF2 | 470 | (DR) | IPv6 | | IPv6 | (BG) | 471 +------+ +----+ +------+ 472 / 473 -----------------<------- 474 / PIM over IPv4 475 +------+ +------+ 476 | MR | PIM | MR | 477 | | . . . . | | 478 | (BG) | IPv4 | (DR) | 479 +------+ +------+ 481 -------------------------------------> 483 Rcvr: Multicast receiver 484 DS : Dual Stack 485 AF : Adaptation Function (ALG or IWF) 486 MR : Multicast Router 487 DR : Designated Router 488 CPE : Customer Premises Equipement (Dual Stack router) 489 PE : Provider Edge router 490 BG : Border Gateway 492 Figure 3: Signalling Path For the 6-4-6-4 Scenario. 494 The major challenge of this scenario is how to ensure that signalling 495 packets from the CPE (AF0) reach the adaptation function instance at 496 the boundary between the IPv4 multicast-disabled access network and 497 the IPv6 multicast network (AF1). If the signalling Sig1 from the 498 receiver is MLD, the CPE router has to translate the MLD destination 499 address ff02::16 into the address of AF1. 501 This requires some sort of configuration by the provider. 502 Alternatively, Sig1 could be an application-layer protocol. in that 503 case, the CPE router can use DNS to get the address of AF1. The 504 adaptation function AF2 between the IPv6 multicast network and the 505 IPv4 network where the multicast source is connected is similar to 506 AF2 in the 4-6-4 scenario. 508 Figure 4 shows the path taken by multicast content flowing from the 509 source to the receiver. Again, AF2 can either encapsulate or 510 translate the headers of the incoming packets. AF1 performs the 511 reverse action, and forwards unencapsulated IPv4 packets towards AF0. 512 AF0 then performs header translation to convert the incoming packets 513 into IPv6 multicast packets before sending them on to the receiver. 515 +------+ +-----+ +----+ +------+ 516 | Host | | DS | | | | DS | 517 | Rcvr |------| AF0 |------| PE | . . .| AF1 | 518 | | IPv6 |(CPE)| IPv4 | | IPv4 | (BG) | 519 +------+ +-----+ +----+ +------+ 520 / 521 ----------------->---------- 522 / IPv6 523 +------+ +----+ +------+ 524 | MR | | | | DS | 525 | |------| MR | . . . | AF2 | 526 | (DR) | IPv6 | | IPv6 | (BG) | 527 +------+ +----+ +------+ 528 / 529 ----------------->------- 530 / IPv4 531 +------+ +------+ +-----+ 532 | MR | | MR | | | 533 | | . . . . | |------| Src | 534 | (BG) | IPv4 | (DR) | IPv4 | | 535 +------+ +------+ +-----+ 537 <------------------------------------- 539 Rcvr: Multicast receiver 540 Src : Multicast source 541 DS : Dual Stack 542 AF : Adaptation function (ALG or IWF) 543 MR : Multicast Router 544 DR : Designated Router 545 CPE : Customer Premises Equipment (Dual Stack router) 546 PE : Provider Edge router 547 BG : Border Gateway 549 Figure 4: Multicast Content Distribution Path For the 6-4-6-4 Scenario. 551 3.3. IPv6 Receiver and Source Connected to an IPv4-Only Network 553 We refer to this scenario as 6-4-6. According to a BEHAVE WG 554 consensus when elaborating the transition unicast scenarios, servers 555 are likely to remain IPv4-enabled in a first stage. This is also 556 true for multicast. Additionally, content providers who own the 557 content may not be ready for IPv6 migration for some reason. 558 Therefore, the content is likely to remain IPv4-formatted. 560 As a consequence, this 6-4-6 scenario is of lower priority than the 561 4-6-4 scenario. 563 The signalling path for the 6-4-6 scenario is illustrated in Figure 564 5. 566 +------+ +-----+ +------+ +------+ 567 | Host | Sig1 | DS | | MR | PIM | MR | 568 | Rcvr |------| AF1 | | | . . . . | | 569 | | IPv6 | | | (BG) | IPv6 | (DR) | 570 +------+ +-----+ +------+ +------+ 571 / \ 572 IGMP / IPv4 PIM \ IPv6 573 / \ 574 +------+ +----+ +------+ 575 | MR | PIM | | PIM | DS | 576 | |------| MR | . . . | AF2 | 577 | (DR) | IPv4 | | IPv4 | (BG) | 578 +------+ +----+ +------+ 580 -------------------------------------> 582 Rcvr: Multicast receiver 583 DS : Dual Stack 584 AF : Adaptation Function (ALG or IWF) 585 MR : Multicast Router 586 DR : Designated Router 587 BG : Border Gateway 589 Figure 5: Signalling Path For the 6-4-6 Scenario. 591 The multimedia content distribution path is shown in Figure 6. 593 +------+ +-----+ +------+ +------+ 594 | Host | | DS | | MR | | MR | 595 | Rcvr |------| AF1 | | | . . . | | 596 | | IPv6 | | | (BG) | IPv6 | (DR) | 597 +------+ +-----+ +------+ +------+ 598 / \ \ 599 / IPv4 \ IPv6 \ IPv6 600 / \ \ 601 +------+ +----+ +------+ +-----+ 602 | MR | | | | DS | | | 603 | |------| MR | . . . | AF2 | | Src | 604 | (DR) | IPv4 | | IPv4 | (BG) | | | 605 +------+ +----+ +------+ +-----+ 607 <------------------------------------- 609 Rcvr: Multicast receiver 610 DS : Dual Stack 611 AF : Adaptation Function 612 MR : Multicast Router 613 DR : Designated Router 614 BG : Border Gateway 615 Src : Multicast source 617 Figure 6: Multicast Content Distribution Path For the 6-4-6 Scenario. 619 3.4. IPv6 Receiver and IPv4 Source 621 We refer to this scenario as 6-4. An example of such use case is the 622 context of some mobile networks, where terminal devices are only 623 provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast 624 content from an IPv6-only receiver requires additional functions to 625 be enabled. 627 This scenario is privileged by mobile operators who deploy NAT64 628 capabilities in their network. It is illustrated in Figures 7 629 (signalling path) and 8 (distribution of multicast contents). Only 630 one adaptation function instance is needed, at the IPv4/IPv6 631 boundary. 633 +------+ +------+ +------+ 634 | Host | | MR | PIM | MR | 635 | Rcvr | | | . . . . | | 636 | | | (BG) | IPv4 | (DR) | 637 +------+ +------+ +------+ 638 \ \ 639 MLD \ IPv6 PIM \ IPv4 640 \ \ 641 +------+ +----+ +------+ 642 | MR | PIM | | PIM | DS | 643 | |------| MR | . . . | AF1 | 644 | (DR) | IPv6 | | IPv6 | (BG) | 645 +------+ +----+ +------+ 647 -------------------------------------> 649 Rcvr: Multicast receiver 650 DS : Dual Stack 651 AF : Adaptation Function (ALG or IWF) 652 MR : Multicast Router 653 DR : Designated Router 654 BG : Border Gateway 656 Figure 7: Signalling Path For the 6-4 Scenario. 658 +------+ +------+ +------+ 659 | Host | | MR | | MR | 660 | Rcvr | | | . . . . | | 661 | | | (BG) | IPv4 | (DR) | 662 +------+ +------+ +------+ 663 \ \ \ 664 \ IPv6 \ IPv4 \ IPv4 665 \ \ \ 666 +------+ +----+ +------+ +-----+ 667 | MR | | | | DS | | | 668 | |------| MR | . . . | AF1 | | Src | 669 | (DR) | IPv6 | | IPv6 | (BG) | | | 670 +------+ +----+ +------+ +-----+ 672 <------------------------------------- 674 Rcvr: Multicast receiver 675 DS : Dual Stack 676 AF : Adaptation Function 677 MR : Multicast Router 678 DR : Designated Router 679 BG : Border Gateway 680 Src : Multicast source 682 Figure 8: Multicast Content Distribution Path For the 6-4 Scenario. 684 3.5. IPv4 Receiver and IPv6 Source 686 We refer to this scenario as 4-6. According to a BEHAVE WG consensus 687 when elaborating the transition unicast scenarios, multicast sources 688 are likely to remain IPv4-enabled in a first stage; therefore, the 689 content is likely to remain IPv4-formatted. 691 As a consequence, this scenario is unlikely to occur during the first 692 years of the transition period, and has been assigned a lower 693 priority compared to the use cases depicted in Sections 3.1, 3.2 and 694 3.4. 696 The signalling path for this scenario is shown in Figure 9. The 697 multicast content distribution path is shown in Figure 10. There are 698 similarities with the 6-4 scenario but address mapping across IP 699 version boundaries is more challenging. 701 +------+ +------+ +------+ 702 | Host | | MR | PIM | MR | 703 | Rcvr | | | . . . . | | 704 | | | (BG) | IPv6 | (DR) | 705 +------+ +------+ +------+ 706 \ \ 707 IGMP \ IPv4 PIM \ IPv6 708 \ \ 709 +------+ +----+ +------+ 710 | MR | PIM | | PIM | DS | 711 | |------| MR | . . . | AF1 | 712 | (DR) | IPv4 | | IPv4 | (BG) | 713 +------+ +----+ +------+ 715 -------------------------------------> 717 Rcvr: Multicast receiver 718 DS : Dual Stack 719 AF : Adaptation Function (ALG or IWF) 720 MR : Multicast Router 721 DR : Designated Router 722 BG : Border Gateway 724 Figure 9: Signalling Path For the 4-6 Scenario. 726 +------+ +------+ +------+ 727 | Host | | MR | | MR | 728 | Rcvr | | | . . . . | | 729 | | | (BG) | IPv6 | (DR) | 730 +------+ +------+ +------+ 731 \ \ \ 732 \ IPv4 \ IPv6 \ IPv6 733 \ \ \ 734 +------+ +----+ +------+ +-----+ 735 | MR | | | | DS | | | 736 | |------| MR | . . . | AF1 | | Src | 737 | (DR) | IPv4 | | IPv4 | (BG) | | | 738 +------+ +----+ +------+ +-----+ 740 <------------------------------------- 742 Rcvr: Multicast receiver 743 DS : Dual Stack 744 AF : Adaptation Function 745 MR : Multicast Router 746 DR : Designated Router 747 BG : Border Gateway 748 Src : Multicast source 750 Figure 10: Multicast Content Distribution Path For the 4-6 Scenario. 752 3.6. Summary 754 To summarize, the use cases of highest priority are those involving 755 IPv4 sources, i.e., the 4-6-4, 6-4-6-4, and 6-4 scenarios. 757 4. Design Considerations 759 4.1. Group and Source Discovery Considerations 761 Multicast applications that embed address information in the payload 762 may require Application Level Gateway (ALG) during the transition 763 period. An ALG is application-specific by definition, and may 764 therefore be unnecessary depending on the nature of the multicast 765 service. 767 Such ALG (Application Level Gateway) may also be required to help an 768 IPv6 receiver select the appropriate multicast group address when 769 only the IPv4 address is advertised (e.g., when the SDP (Session 770 Description Protocol) protocol is used to advertise some contents); 771 otherwise, access to IPv4 multicast content from an IPv6 receiver may 772 be compromised. 774 ALGs may be located upstream in the network. As a consequence, these 775 ALGs do not know in advance whether the receiver is dual-stack or 776 IPv6-only. In order to avoid the use of an ALG in the path, an IPv4- 777 only source can advertise both an IPv4 multicast group address and 778 the corresponding IPv4-embedded IPv6 multicast group address [I-D. 779 boucadair-behave-64-multicast-address-format]. 781 However, a dual-stack receiver may prefer to use the IPv6 address to 782 receive the multicast content. The selection of the IPv6 multicast 783 address would then require multicast flows to cross an IPv4-IPv6 784 interworking function. 786 The receiver should therefore be able to unambiguously distinguish an 787 IPv4-embedded IPv6 multicast address from a native IPv6 multicast 788 address. 790 4.2. Subscription 792 Multicast distribution trees are receiver-initiated. IPv4 receivers 793 that wish to subscribe to an IPv4 multicast group will send the 794 corresponding IGMP Report message towards the relevant IGMP Querier. 795 In case the underlying access network is IPv6, the information 796 conveyed in IGMP messages should be relayed by corresponding MLD 797 messages. 799 4.3. Multicast Tree Computation 801 Grafting to an IPv4 multicast distribution tree through an IPv6 802 multicast domain suggests that IPv4 multicast traffic will have to be 803 conveyed along an "IPv6-equivalent" multicast distribution tree. 804 That is, part of the multicast distribution tree along which IPv4 805 multicast traffic will be forwarded SHOULD be computed and maintained 806 by means of the PIMv6 machinery, so that the distribution tree can be 807 terminated as close to the IPv4 receivers as possible for the sake of 808 the multicast forwarding efficiency. This assumes a close 809 interaction between the PIM designs enforced in both IPv4 and IPv6 810 multicast domains, by means of specific Inter-Working Functions that 811 are further discussed in Section 4.4. 813 Such interaction may be complicated by different combinations: the 814 IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point) 815 routers), while the IPv6 multicast domain may support both ASM (Any 816 Source Multicast) and SSM (Source Specific Multicast) [RFC3569] 817 modes. 819 4.4. Multicast Interworking Functions (IWF) 821 IPv4-IPv6 multicast interworking functions are required for both 822 translation (one address family to another) and traversal (one 823 address family over another) contexts. 825 Given the multiple versions of Group Membership management protocols, 826 issues may be raised when, for example, IGMPv2 is running in the IPv4 827 multicast domain that is connected to the IPv6 multicast domain by 828 means of an IWF, while MLDv2 is running in the IPv6 multicast domain. 829 To solve these problems, the design of the IWF function SHOULD adhere 830 to the IP version-independent, protocol interaction approach 831 documented in Section 8 of [RFC3810] and Section 7 of [RFC3376]. 833 Note that, for traversal cases, to improve the efficiency of the 834 multicast service delivery, traffic will be multicast along 835 distribution trees that should be terminated as close to the 836 receivers as possible for the sake of bandwidth optimization. As a 837 reminder, the traversal of unicast-only (access) networks is not 838 considered in this draft. 840 4.4.1. IWF For Control Flows 842 The IWF to process multicast signalling flows (such as IGMP or MLD 843 Report messages) should be independent of the IP version and consist 844 mainly of an IPv4-IPv6 adaptation element and an IP address 845 translation element. The message format adaptation must follow what 846 is specified in [RFC3810] or [RFC4601], and the device that embeds 847 the IWF device must be multicast-enabled, i.e., support IGMP, MLD 848 and/or PIM, depending on the context (address family-wise) and the 849 design (e.g., this device could be a PIM DR in addition to a MLD 850 Querier). 852 The IWF can then be operated in the following modes: IGMP-MLD, PIMv4- 853 PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-Specific 854 Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 signalling 855 traffic as well as the ability to directly send PIM (S, G) Join 856 messages towards the source). 858 The following sub-sections describe some interworking functions which 859 may be solicited, depending on the environment. 861 4.4.1.1. IGMP-MLD Interworking 863 The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying 864 function specified in [RFC4605] and the IGMP/MLD adaptation function 865 which is meant to reflect the contents of IGMP messages into MLD 866 messages, and vice versa. 868 For example, when an IGMP Report message is received to subscribe to 869 a given multicast group (which may be associated to a source address 870 if SSM mode is used), the IGMP-MLD Interworking Function MUST send an 871 MLD Report message to subscribe to the corresponding IPv6 multicast 872 group. 874 4.4.1.2. IPv4-IPv6 PIM Interworking 876 [RFC4601] allows the computation of PIM-based IPv4 or IPv6 877 distribution trees; PIM is IP version agnostic. There is no specific 878 IPv6 PIM machinery that would work differently than an IPv4 PIM 879 machinery. The new features needed for the IPv4-IPv6 PIM 880 Interworking Function consist in dynamically triggering the PIM 881 message of Address Family 1 upon receipt of the equivalent PIM 882 message of Address Family 2. 884 The address mapping MUST be performed similarly to that of the IGMP- 885 MLD Interworking Function. 887 4.4.1.3. MLD-IPv4 PIM Interworking 889 This IWF function is required when the MLD Querier is connected to an 890 IPv4 PIM domain. 892 The address mapping MUST be performed similarly to that of the IGMP- 893 MLD Interworking Function. 895 4.4.1.4. IGMP-IPv6 PIM Interworking 897 The address mapping MUST be performed similarly to that of the IGMP- 898 MLD Interworking Function. 900 4.4.2. IWF For Data Flows 902 The IWF to be used for multicast data flows is operated at the 903 boundary between IPv4 and IPv6 multicast networks. Either 904 encapsulation/de-capsulation or translation modes can be enforced, 905 depending on the design. Note that translation operations must 906 follow the algorithm specified in [RFC6145]. 908 4.4.3. Address Mapping 910 The address mapping mechanisms to be used in either a stateful or 911 stateless fashion need to be specified for the translation from one 912 address family to the other. 914 The address formats have been defined in [I-D.boucadair-behave-64- 915 multicast-address-format] and [RFC6052] for IPv4-embedded IPv6 916 multicast and unicast addresses. Mapping operations are performed in 917 a stateless manner by the algorithms specified in the aforementioned 918 documents. 920 In this context, the IPv6 prefixes required for embedding IPv4 921 addresses can be assigned to devices that support IWF features by 922 various means (e.g., static or dynamic configuration, out-of-band 923 mechanisms, etc.). 925 If stateful approaches are used, it is recommended to carefully 926 investigate the need to synchronize mapping states between multiple 927 boxes, and the coordination of the IWF and source/group discovery 928 elements is also required, at the cost of extra complexity. 930 4.5. Combination of ASM and SSM Modes 932 The ASM (Any Source Multicast) mode could be used to optimize the 933 forwarding of IPv4 multicast traffic sent by different sources into 934 the IPv6 multicast domain by selecting RP routers that could be 935 located at the border between the IPv6 and the IPv4 multicast 936 domains. This design may optimize the multicast forwarding 937 efficiency in the IPv6 domain when access to several IPv4 multicast 938 sources needs to be granted. 940 [To be further elaborated.] 942 5. What Is Expected From The IETF 944 This document highlights the following IETF standardization needs: 946 o Specify the inter-working function as described in Sections 4.4.1 947 and 4.4.2. In particular: 949 * Specify the algorithms used by various inter-working functions, 950 covering both encapsulation and translation approaches 952 * Specify the multicast IPv4-embedded address format 954 * Document a 6-4 multicast architecture 956 * Document a 6-4-6-4 multicast architecture 958 * Document a 4-6-4 multicast architecture 960 o Document a Management Information Base (MIB) to be used for the 961 management of IWF functions 963 o Encourage the publication of various Applicability Statement 964 documents to reflect IWF operational experience in different 965 contexts 967 6. IANA Considerations 969 This document makes no request to IANA. 971 Note to RFC Editor: this section may be removed on publication as an 972 RFC. 974 7. Security Considerations 976 Access to contents in a multicast-enabled environment raises 977 different security issues that have been already documented. This 978 draft does not introduce any specific security issue. 980 8. Acknowledgments 982 Special thanks to T. Taylor for providing the figures and some of the 983 text that illustrate the use cases depicted in Section 3. Thanks 984 also to N. Leymann and S. Venaas for their comments. 986 9. References 988 9.1. Normative References 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 994 Thyagarajan, "Internet Group Management Protocol, Version 995 3", RFC 3376, October 2002. 997 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 998 Multicast (SSM)", RFC 3569, July 2003. 1000 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1001 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1002 Protocol Specification (Revised)", RFC 4601, August 2006. 1004 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1005 "Internet Group Management Protocol (IGMP) / Multicast 1006 Listener Discovery (MLD)-Based Multicast Forwarding 1007 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1009 9.2. Informative References 1011 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1012 2", RFC 2236, November 1997. 1014 Authors' Addresses 1016 Christian Jacquenet 1017 France Telecom 1019 Email: christian.jacquenet@orange.com 1021 Mohamed Boucadair 1022 France Telecom 1023 Rennes 35000 1024 France 1026 Email: mohamed.boucadair@orange.com 1028 Yiu Lee 1029 Comcast 1030 US 1032 Email: Yiu_Lee@Cable.Comcast.com 1034 Jacni Qin 1035 ZTE 1036 China 1038 Email: jacniq@gmail.com 1040 Tina Tsou 1041 Huawei Technologies (USA) 1042 2330 Central Expressway 1043 Santa Clara, CA 95050 1044 USA 1046 Phone: +1 408 330 4424 1047 Email: tena@huawei.com