idnits 2.17.1 draft-jaclee-behave-v4v6-mcast-ps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 02, 2011) is 4711 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3810' is mentioned on line 489, but not defined == Missing Reference: 'RFC6145' is mentioned on line 549, but not defined ** Obsolete undefined reference: RFC 6145 (Obsoleted by RFC 7915) == Missing Reference: 'RFC6052' is mentioned on line 558, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 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: December 4, 2011 Y. Lee 6 Comcast 7 J. Qin 8 ZTE 9 T. Tsou 10 Huawei Technologies (USA) 11 June 02, 2011 13 IPv4-IPv6 Multicast: Problem Statement and Use Cases 14 draft-jaclee-behave-v4v6-mcast-ps-02 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 December 4, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Organization of the Document . . . . . . . . . . . . . . . 4 67 2. Discussion and Service Requirements . . . . . . . . . . . . . 4 68 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Issues Raised by the Transition Period . . . . . . . . . . 5 70 2.3. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 8 77 3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 8 78 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Group and Source Discovery Considerations . . . . . . . . 9 81 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 10 83 4.4. Multicast Interworking Functions (IWF) . . . . . . . . . . 10 84 4.4.1. IWF For Control Flows . . . . . . . . . . . . . . . . 11 85 4.4.2. IWF For Data Flows . . . . . . . . . . . . . . . . . . 12 86 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 12 87 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 13 88 5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 13 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 In current deployments, the IP multicast forwarding scheme is used by 100 many service providers to deliver some services, such as live TV 101 broadcasting services. Multiple players intervene in the delivery of 102 these services, including content and service providers. Service 103 providers are responsible for carrying multicast flows from head-ends 104 to receivers. The content can be supplied by a service provider or 105 by other providers (e.g., case of externally paid channels). 107 Transition to IPv6 raises issues and corresponding requirements. In 108 particular, IPv4 service continuity is an essential requirement from 109 a business perspective. This specifically includes continued 110 receiver access to IPv4-formatted contents even when the assignment 111 of a dedicated global IPv4 address to the receiver is no longer 112 possible and even after the receivers have migrated to IPv6. 113 Likewise, the delivery of IPv6-formatted contents to IPv4 receivers 114 must also be possible. 116 Finally, in cases where the underlying transport network is of a 117 different address family from that of the source and/or receivers, 118 the delivery of multicast data must still be guaranteed. For 119 example, in DS-Lite environments, the (access) network is IPv6- 120 enabled, but both multicast sources and receivers are likely to 121 remain IPv4-only. 123 This document does not make any assumption on the techniques used for 124 the delivery of multicast traffic (e.g., native IP multicast with or 125 without traffic isolation features, etc.). 127 This document further elaborates on the context and discusses 128 multicast-related issues and requirements. 130 1.1. Goals 132 The objective of this document is to clarify the problem space. In 133 particular, this document further elaborates on the following issues: 135 o What are the hurdles encountered for the delivery of multicast- 136 based service offerings when both IPv4 and IPv6 co-exist? 138 o What standardization effort is needed: are there any missing 139 function and protocol extensions? 141 o Does the work on multicast transition have to cover both 142 encapsulation and translation schemes, considering the requirement 143 of multicast network performance among others? 145 1.2. Terminology 147 This document uses the following terms: 149 o Multicast Source: Source, in short 151 o Multicast Receiver: Receiver, in short, e.g., STB (Set Top Box) 153 o Multicast Delivery Network: Network in short, covers the realm 154 from Designated Routers that are directly connected to sources to 155 IGMP/MLD (Internet Group Management Protocol/Multicast Listener 156 Discovery) Querier devices that process IGMP/MLD signalling 157 traffic exchanged with receivers. 159 1.3. Organization of the Document 161 This document is organized as follows: 163 o Section 2 details basic requirements that should be addressed by 164 providers involved in the delivery of multicast-based services 165 during the transition period, 167 o Section 3 discusses several use cases that reflect issues raised 168 by the forthcoming transition period, 170 o Section 4 details design considerations, 172 o Section 5 summarizes the standardization effort that should be 173 tackled by the IETF. 175 2. Discussion and Service Requirements 177 2.1. Scope 179 Intra-domain only: The delivery of multicast services such as live 180 TV broadcasting often relies upon walled garden designs that 181 restrict the scope to the domain where such services can be 182 subscribed. As a consequence, considerations about inter-domain 183 multicast are out of the scope of this document. 185 Multicast-enabled networks only: This document assumes that the 186 network is IP multicast-enabled. That is, whatever the IP address 187 family of the content, the latter will be multicast along 188 distribution trees that should be terminated as close to the 189 receivers as possible for the sake of bandwidth optimization. In 190 other words, considerations about forwarding multicast traffic 191 over unicast-only (access) networks is out of the scope of this 192 document. 194 Multicast to the receivers, not from the receivers: This document 195 only covers the case where multicast traffic is forwarded by the 196 service provider network to the receivers. This document does not 197 cover the case where the receivers send multicast traffic to the 198 network. 200 2.2. Issues Raised by the Transition Period 202 Global IPv4 address depletion inevitably challenges service providers 203 who must guarantee IPv4 service continuity during the forthcoming 204 transition period. In particular, access to IPv4 contents that are 205 multicast to IPv4 receivers becomes an issue when the forwarding of 206 multicast data assumes the use of global IPv4 addresses. 208 The rarefaction of global IPv4 addresses may indeed affect the 209 multicast delivery of IPv4-formatted contents to IPv4 receivers. For 210 example, the observed evolution of ADSL broadband access 211 infrastructures from a service-specific, multi-PVC (Permanent Virtual 212 Circuit) scheme towards a "service-agnostic", single PVC scheme, 213 assumes the allocation of a globally unique IPv4 address on the WAN 214 (Wide Area Network) interface of the CPE (Customer Premises 215 Equipment), or to a mobile terminal), whatever the number and the 216 nature of the services the customer has subscribed to. 218 During the transition period, the usage of the remaining global IPv4 219 address blocks will have to be rationalized for the sake of IPv4 220 service continuity. The current state-of-the-art suggests the 221 introduction of NAT (Network Address Translation) capabilities 222 (generally denoted as CGN, for Carrier-Grade NAT) in providers' 223 networks, so that a global IPv4 address will be shared between 224 several customers. As a consequence, CPE or mobile UE (User 225 Equipment) devices will no longer be assigned a dedicated global IPv4 226 address anymore, and IPv4 traffic will be privately-addressed until 227 it reaches one of the CGN capabilities deployed in the network. 229 From a multicast delivery standpoint, this situation suggests the 230 following considerations: 232 o The current design of some multicast-based services like TV 233 broadcasting often relies upon the use of a private IPv4 234 addressing scheme because of a walled garden approach. Privately- 235 addressed IGMP [RFC2236] [RFC3376] traffic sent by IPv4 receivers 236 is generally forwarded over a specific (e.g. "IPTV") PVC towards 237 an IGMP Querier located in the access infrastructure, e.g.- in 238 some deployments it is hosted by a BRAS (BRoadband Access Server) 239 device that is the PPP (Point-to-Point Protocol) session endpoint 240 and which may also act as a PIM DR (Protocol Independent Multicast 241 Designated Router)[RFC4601] router. This design does not suffer 242 from global IPv4 address depletion by definition (since multicast 243 traffic relies upon the use of a private IPv4 addressing scheme), 244 but it is inconsistent with migrating the access infrastructure 245 towards a publicly-addressed single PVC design scheme. 247 o Likewise, other deployments (e.g., cable operators' environments) 248 rely upon the public CPE's address for multicast delivery and will 249 therefore suffer from IPv4 address depletion. 251 o The progressive introduction of IPv6 as the only perennial 252 solution to global IPv4 address depletion does not necessarily 253 assume that multicast-based IPv4 services will be migrated 254 accordingly. Access to IPv4 multicast contents when no global 255 IPv4 address can be assigned to a customer anymore raises several 256 issues: (1) The completion of the IGMP-based multicast group 257 subscription procedure, (2) The computation of the IPv4 multicast 258 distribution tree, and (3) The IPv4-inferred addressing scheme to 259 be used in a networking environment which will progressively 260 become IPv6-enabled. 262 2.3. Service Requirements 264 Given the issues highlighted in Section 2.2, the delivery of 265 multicast contents during the forthcoming transition period needs to 266 address the following requirements. Note that some of these 267 requirements are not necessarily specific to the IPv4-to-IPv6 268 transition context, but rather apply to a wide range of multicast- 269 based services whatever the environmental constraints. 271 But the forthcoming transition period further stresses these 272 requirements (see Section 4.4.1 for more details). 274 o Service_REQ-1: Optimize bandwidth. Contents SHOULD NOT be 275 multicast twice (using both versions of IP) for the sake of 276 bandwidth optimization. Injecting multicast content using both 277 IPv4 and IPv6 raises some dimensioning issues that should be 278 carefully evaluated by service providers during network planning 279 operations. For instance, if only few IPv6- enabled receivers are 280 in use, it can be more convenient to convey multicast traffic over 281 IPv4 rather than doubling the consumed resources for few users. 282 IPv4/IPv6 co-existence solutions SHOULD be designed to optimize 283 network resource utilization. 285 o Service_REQ-2: Zap rapidly. The time it takes to switch from one 286 content to another MUST be as short as possible. For example, 287 zapping times between two TV channels should be in the magnitude 288 of a few seconds at most, whatever the conditions to access the 289 multicast network. A procedure called "IGMP fast-leave" is 290 sometimes used to minimize this issue so that the corresponding 291 multicast stream is stopped as soon as the IGMP Leave message is 292 received by the Querier. In current deployments, IGMP fast-leave 293 often assumes the activation of the IGMP Proxy function in DSLAMs. 294 The complexity of such design is aggravated within a context where 295 IPv4 multicast control messages are encapsulated in IPv6. 297 o Service_REQ-3: Preserve the integrity of contents. Some contract 298 agreements may prevent a service provider from altering the 299 content owned by the content provider, because of copyright, 300 confidentiality and SLA assurance reasons. Multicast streams 301 SHOULD be delivered without altering their content. 303 o Service_REQ-4: Preserve service quality. Crossing a CGN or 304 performing multicast packet encapsulation may lead to 305 fragmentation or extra delays and may therefore impact the 306 perceived quality of service. Such degradation MUST be avoided. 308 o Service_REQ-5: Optimize IPv4-IPv6 inter-working design. In some 309 operational networks, a source-based stateful NAT function is 310 sometimes used for load balancing purposes, for example. Because 311 of the operational issues raised by such a stateful design, the 312 deployment of stateless IPv4-IPv6 interworking functions SHOULD be 313 privileged. 315 3. Use Cases 317 During the forthcoming IPv4-to-IPv6 transition period, there might be 318 a mix of multicast receivers, sources, and networks running in 319 different address families. However, service providers must 320 guarantee the delivery of multicast services to IPv4 receivers and, 321 presumably, IPv6 receivers. Because of the inevitable combination of 322 different IP version-related environments (sources, receivers and 323 networks), service providers should carefully plan and choose the 324 right transition technique that will optimize the network resources 325 to deliver multicast-based services. 327 Concretely, several use cases can be considered during the IPv4/ IPv6 328 co-existence period. Some of them are depicted in the following sub- 329 sections. 331 3.1. IPv4 Receiver and Source Connected to an IPv6-Only Network 333 We refer to this scenario as 4-6-4. An example of such use case is a 334 DS-Lite environment, where some customers will share global IPv4 335 addresses. IPv4 receivers are connected to CPE devices that are 336 provisioned with an IPv6 prefix only. Delivering multicast content 337 sent by an IPv4 source to such receivers requires the activation of 338 some interworking functions. Multicast traffic can be either 339 encapsulated or translated. 341 Given the current state-of-the-art where multicast content is likely 342 to remain IPv4-formatted while receiver devices such as Set Top Boxes 343 will also remain IPv4-only for quite some time, this scenario is 344 prioritized by service providers, including those that are deploying 345 or will deploy DS-Lite CGN capabilities for the sake of IPv4 service 346 continuity. 348 3.2. IPv6 Receiver and Source Connected to an IPv4-Only Network 350 We refer to this scenario as 6-4-6. According to a BEHAVE WG 351 consensus when elaborating the transition unicast scenarios, servers 352 are likely to remain IPv4-enabled in a first stage. This is also 353 true for multicast. Additionally, content providers who own the 354 content may not be ready for IPv6 migration for some reason. 355 Therefore the content is likely to remain IPv4-formatted. 357 As a consequence, this 6-4-6 scenario is of lower priority than the 358 4-6-4 scenario. 360 3.3. IPv6 Receiver and IPv4 Source 362 We refer to this scenario as 6-4. An example of such use case is the 363 context of some mobile networks, where terminal devices are only 364 provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast 365 content from an IPv6-only receiver requires additional functions to 366 be enabled. 368 This scenario is privileged by mobile operators who deploy NAT64 369 capabilities in their network. 371 3.4. IPv4 Receiver and IPv6 Source 373 We refer to this scenario as 4-6. According to a BEHAVE WG consensus 374 when elaborating the transition unicast scenarios, multicast sources 375 are likely to remain IPv4-enabled in a first stage; therefore, the 376 content is likely to remain IPv4-formatted. 378 As a consequence, this scenario is unlikely to occur during the first 379 years of the transition period, and has been assigned a lower 380 priority compared to the use cases depicted in Sections 3.1 and 3.3. 382 3.5. Summary 384 The following table summarizes the use cases: 386 +------------------+------------+ 387 | Use Cases | Priority | 388 +------------------+------------+ 389 | R4, S4 over IPv6 | High | 390 +------------------+------------+ 391 | R6, S4 | High | 392 +------------------+------------+ 393 | R6, S6 over IPv4 | Low | 394 +-------------------------------+ 395 | R4, S6 | Low | 396 +------------------+------------+ 398 Figure 1: Multicast Transition Use Case Summary 400 4. Design Considerations 402 4.1. Group and Source Discovery Considerations 404 Multicast applications that embed address information in the payload 405 may require Application Level Gateway (ALG) during the transition 406 period. An ALG is application-specific by definition, and may 407 therefore be unnecessary depending on the nature of the multicast 408 service. 410 Such ALG (Application Level Gateway) may also be required to help an 411 IPv6 receiver select the appropriate multicast group address when 412 only the IPv4 address is advertised (e.g., when the SDP (Session 413 Description Protocol) protocol is used to advertise some contents); 414 otherwise, access to IPv4 multicast content from an IPv6 receiver may 415 be compromised. 417 ALGs may be located upstream in the network. As a consequence, these 418 ALGs do not know in advance whether the receiver is dual-stack or 419 IPv6-only. In order to avoid the use of an ALG in the path, an IPv4- 420 only source can advertise both an IPv4 multicast group address and 421 the corresponding IPv4-embedded IPv6 multicast group address [I-D. 422 boucadair-behave-64-multicast-address-format]. 424 However, a dual-stack receiver may prefer to use the IPv6 address to 425 receive the multicast content. The selection of the IPv6 multicast 426 address would then require multicast flows to cross an IPv4-IPv6 427 interworking function. 429 The receiver should therefore be able to unambiguously distinguish an 430 IPv4-embedded IPv6 multicast address from a native IPv6 multicast 431 address. 433 4.2. Subscription 435 Multicast distribution trees are receiver-initiated. IPv4 receivers 436 that wish to subscribe to an IPv4 multicast group will send the 437 corresponding IGMP Report message towards the relevant IGMP Querier. 438 In case the underlying access network is IPv6, the information 439 conveyed in IGMP messages should be relayed by corresponding MLD 440 messages. 442 4.3. Multicast Tree Computation 444 Grafting to an IPv4 multicast distribution tree through an IPv6 445 multicast domain suggests that IPv4 multicast traffic will have to be 446 conveyed along an "IPv6-equivalent" multicast distribution tree. 447 That is, part of the multicast distribution tree along which IPv4 448 multicast traffic will be forwarded SHOULD be computed and maintained 449 by means of the PIMv6 machinery, so that the distribution tree can be 450 terminated as close to the IPv4 receivers as possible for the sake of 451 the multicast forwarding efficiency. This assumes a close 452 interaction between the PIM designs enforced in both IPv4 and IPv6 453 multicast domains, by means of specific Inter-Working Functions that 454 are further discussed in Section 4.4. 456 Such interaction may be complicated by different combinations: the 457 IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point) 458 routers), while the IPv6 multicast domain may support both ASM (Any 459 Source Multicast) and SSM (Source Specific Multicast) [RFC3569] 460 modes. 462 4.4. Multicast Interworking Functions (IWF) 464 IPv4-IPv6 multicast interworking functions are required for both 465 translation (one address family to another) and traversal (one 466 address family over another) contexts. 468 Given the multiple versions of Group Membership management protocols, 469 issues may be raised when, for example, IGMPv2 is running in the IPv4 470 multicast domain that is connected to the IPv6 multicast domain by 471 means of an IWF, while MLDv2 is running in the IPv6 multicast domain. 472 To solve these problems, the design of the IWF function SHOULD adhere 473 to the IP version-independent, protocol interaction approach 474 documented in Section 8 of [RFC3810] and Section 7 of [RFC3376]. 476 Note that, for traversal cases, to improve the efficiency of the 477 multicast service delivery, traffic will be multicast along 478 distribution trees that should be terminated as close to the 479 receivers as possible for the sake of bandwidth optimization. As a 480 reminder, the traversal of unicast-only (access) networks is not 481 considered in this draft. 483 4.4.1. IWF For Control Flows 485 The IWF to process multicast signalling flows (such as IGMP or MLD 486 Report messages) should be independent of the IP version and consist 487 mainly of an IPv4-IPv6 adaptation element and an IP address 488 translation element. The message format adaptation must follow what 489 is specified in [RFC3810] or [RFC4601], and the device that embeds 490 the IWF device must be multicast-enabled, i.e., support IGMP, MLD 491 and/or PIM, depending on the context (address family-wise) and the 492 design (e.g., this device could be a PIM DR in addition to a MLD 493 Querier). 495 The IWF can then be operated in the following modes: IGMP-MLD, PIMv4- 496 PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-Specific 497 Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 signalling 498 traffic as well as the ability to directly send PIM (S, G) Join 499 messages towards the source). 501 The following sub-sections describe some interworking functions which 502 may be solicited, depending on the environment. 504 4.4.1.1. IGMP-MLD Interworking 506 The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying 507 function specified in [RFC4605] and the IGMP/MLD adaptation function 508 which is meant to reflect the contents of IGMP messages into MLD 509 messages, and vice versa. 511 For example, when an IGMP Report message is received to subscribe to 512 a given multicast group (which may be associated to a source address 513 if SSM mode is used), the IGMP-MLD Interworking Function MUST send an 514 MLD Report message to subscribe to the corresponding IPv6 multicast 515 group. 517 4.4.1.2. IPv4-IPv6 PIM Interworking 519 [RFC4601] allows the computation of PIM-based IPv4 or IPv6 520 distribution trees; PIM is IP version agnostic. There is no specific 521 IPv6 PIM machinery that would work differently than an IPv4 PIM 522 machinery. The new features needed for the IPv4-IPv6 PIM 523 Interworking Function consist in dynamically triggering the PIM 524 message of Address Family 1 upon receipt of the equivalent PIM 525 message of Address Family 2. 527 The address mapping MUST be performed similarly to that of the IGMP- 528 MLD Interworking Function. 530 4.4.1.3. MLD-IPv4 PIM Interworking 532 This IWF function is required when the MLD Querier is connected to an 533 IPv4 PIM domain. 535 The address mapping MUST be performed similarly to that of the IGMP- 536 MLD Interworking Function. 538 4.4.1.4. IGMP-IPv6 PIM Interworking 540 The address mapping MUST be performed similarly to that of the IGMP- 541 MLD Interworking Function. 543 4.4.2. IWF For Data Flows 545 The IWF to be used for multicast data flows is operated at the 546 boundary between IPv4 and IPv6 multicast networks. Either 547 encapsulation/de-capsulation or translation modes can be enforced, 548 depending on the design. Note that translation operations must 549 follow the algorithm specified in [RFC6145]. 551 4.4.3. Address Mapping 553 The address mapping mechanisms to be used in either a stateful or 554 stateless fashion need to be specified for the translation from one 555 address family to the other. 557 The address formats have been defined in [I-D.boucadair-behave-64- 558 multicast-address-format] and [RFC6052] for IPv4-embedded IPv6 559 multicast and unicast addresses. Mapping operations are performed in 560 a stateless manner by the algorithms specified in the aforementioned 561 documents. 563 In this context, the IPv6 prefixes required for embedding IPv4 564 addresses can be assigned to devices that support IWF features by 565 various means (e.g., static or dynamic configuration, out-of-band 566 mechanisms, etc.). 568 If stateful approaches are used, it is recommended to carefully 569 investigate the need to synchronize mapping states between multiple 570 boxes, and the coordination of the IWF and source/group discovery 571 elements is also required, at the cost of extra complexity. 573 4.5. Combination of ASM and SSM Modes 575 The ASM (Any Source Multicast) mode could be used to optimize the 576 forwarding of IPv4 multicast traffic sent by different sources into 577 the IPv6 multicast domain by selecting RP routers that could be 578 located at the border between the IPv6 and the IPv4 multicast 579 domains. This design may optimize the multicast forwarding 580 efficiency in the IPv6 domain when access to several IPv4 multicast 581 sources needs to be granted. 583 [To be further elaborated.] 585 5. What Is Expected From The IETF 587 This document highlights the following IETF standardization needs: 589 o Specify the inter-working function as described in Sections 4.4.1 590 and 4.4.2. In particular: 592 * Specify the algorithms used by various inter-working functions, 593 covering both encapsulation and translation approaches 595 * Specify the multicast IPv4-embedded address format 597 * Document a multicast 6-4 (that is, the R6-S4 use case of Figure 598 1) architecture 600 * Document a 4-6-4 (that is, the R4-S4 over IPv6 use case of 601 Figure 1) multicast architecture 603 o Document a Management Information Base (MIB) to be used for the 604 management of IWF functions 606 o Encourage the publication of various Applicability Statement 607 documents to reflect IWF operational experience in different 608 contexts 610 6. IANA Considerations 612 This document makes no request to IANA. 614 Note to RFC Editor: this section may be removed on publication as an 615 RFC. 617 7. Security Considerations 619 Access to contents in a multicast-enabled environment raises 620 different security issues that have been already documented. This 621 draft does not introduce any specific security issue. 623 8. Acknowledgments 625 Thanks to N. Leymann, T. Taylor and S. Venaas for their comments. 627 9. References 629 9.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 635 Thyagarajan, "Internet Group Management Protocol, Version 636 3", RFC 3376, October 2002. 638 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 639 Multicast (SSM)", RFC 3569, July 2003. 641 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 642 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 643 Protocol Specification (Revised)", RFC 4601, August 2006. 645 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 646 "Internet Group Management Protocol (IGMP) / Multicast 647 Listener Discovery (MLD)-Based Multicast Forwarding 648 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 650 9.2. Informative References 652 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 653 2", RFC 2236, November 1997. 655 Authors' Addresses 657 Christian Jacquenet 658 France Telecom 660 Email: christian.jacquenet@orange-ftgroup.com 661 Mohamed Boucadair 662 France Telecom 663 Rennes 35000 664 France 666 Email: mohamed.boucadair@orange-ftgroup.com 668 Yiu Lee 669 Comcast 670 US 672 Email: Yiu_Lee@Cable.Comcast.com 674 Jacni Qin 675 ZTE 676 China 678 Email: jacniq@gmail.com 680 Tina Tsou 681 Huawei Technologies (USA) 682 2330 Central Expressway 683 Santa Clara, CA 95050 684 USA 686 Phone: +1 408 330 4424 687 Email: tena@huawei.com