idnits 2.17.1 draft-qin-softwire-dslite-multicast-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 14, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4604' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'RFC4608' is defined on line 822, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-boucadair-behave-64-multicast-address-format-01 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-03) exists of draft-jaclee-behave-v4v6-mcast-ps-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG Q. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track J. Qin 5 Expires: September 15, 2011 P. Sun 6 ZTE 7 M. Boucadair 8 C. Jacquenet 9 France Telecom 10 Y. Lee 11 Comcast 12 March 14, 2011 14 Multicast Extensions to DS-Lite Technique in Broadband Deployments 15 draft-qin-softwire-dslite-multicast-03 17 Abstract 19 This document proposes a solution for the delivery of multicast 20 service offerings to DS-Lite serviced customers. The proposed 21 solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme 22 and does not require performing any NAT operation along the path used 23 to deliver multicast traffic. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 15, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. IPTV-centric View . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Mitigation Alternatives . . . . . . . . . . . . . . . . . 6 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. IPv4-embedded IPv6 Address Prefixes . . . . . . . . . . . 8 69 4.3. Multicast Distribution Tree . . . . . . . . . . . . . . . 9 70 4.4. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 10 71 4.5. Multicast DS-Lite vs. Unicast DS-Lite . . . . . . . . . . 10 72 4.6. Fall-Back Mode . . . . . . . . . . . . . . . . . . . . . . 10 73 5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 11 75 5.2. Text Representation Examples . . . . . . . . . . . . . . . 11 76 6. Multicast B4 (mB4) . . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. IGMP-MLD Interworking function . . . . . . . . . . . . . . 11 78 6.2. De-capsulation and Forwarding . . . . . . . . . . . . . . 12 79 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12 80 6.4. Host with mB4 function embedded . . . . . . . . . . . . . 13 81 7. Multicast AFTR (mAFTR) . . . . . . . . . . . . . . . . . . . . 13 82 7.1. Routing Considerations . . . . . . . . . . . . . . . . . . 13 83 7.2. Processing PIM/MLD Join Messages . . . . . . . . . . . . . 13 84 7.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 14 85 7.4. ASM Mode: Building Shared Trees . . . . . . . . . . . . . 14 86 7.4.1. IPv4 Side . . . . . . . . . . . . . . . . . . . . . . 14 87 7.4.2. IPv6 Side . . . . . . . . . . . . . . . . . . . . . . 14 88 7.5. TTL/Scope . . . . . . . . . . . . . . . . . . . . . . . . 16 89 7.6. Encapsulation and forwarding . . . . . . . . . . . . . . . 16 90 8. Optimization in L2 Access Networks . . . . . . . . . . . . . . 17 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 9.1. Firewall Configuration . . . . . . . . . . . . . . . . . . 17 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 98 Appendix A. Translation vs. Encapsulation . . . . . . . . . . . . 20 99 A.1. Translation . . . . . . . . . . . . . . . . . . . . . . . 20 100 A.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 20 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 103 1. Introduction 105 DS-Lite [I-D.ietf-softwire-dual-stack-lite] is a technique to 106 rationalize the use of the remaining IPv4 addresses during the 107 transition period. The current design of DS-Lite covers unicast 108 services exclusively. 110 If customers access IPv4 multicast-based service offerings through a 111 DS-Lite environment, AFTR (Address Family Transition Router) devices 112 have to process all the IGMP reports [RFC2236] [RFC3376] received 113 within IPv4-in-IPv6 tunnels and behave as a replication point for 114 downstream multicast traffic. That is likely to severely affect the 115 multicast traffic forwarding efficiency by losing the benefits of 116 deterministic replication of the data as close to the receivers as 117 possible. As a consequence, the downstream bandwidth will be vastly 118 consumed while the AFTR capability may become rapidly overloaded, in 119 particular if the AFTR capability is deployed in a centralized 120 manner. 122 This document discusses an extension to the DS-Lite model to be used 123 for the delivery of IPv4 multicast-based service offerings. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 2. Terminology 133 This document makes use of the following terms: 135 o IPv4-embedded IPv6 address: is an IPv6 address which embeds a 32 136 bit-encoded IPv4 address. An IPv4-embedded IPv6 address can be 137 unicast or multicast. 139 o mPrefix64: is a dedicated multicast IPv6 prefix for constructing 140 IPv4-embedded IPv6 multicast address 141 [I-D.boucadair-behave-64-multicast-address-format]. mPrefix64 can 142 be of two types: ASM_mPrefix64 used in ASM mode or SSM_mPrefix64 143 used in SSM mode [RFC4607]. 145 o uPrefix64: is a dedicated unicast IPv6 prefix for constructing 146 IPv4-embedded IPv6 unicast address [RFC6052]. 148 o Multicast AFTR (mAFTR for short): is a functional entity which is 149 part of both the IPv4 and IPv6 multicast distribution trees and 150 which replicates IPv4 multicast streams into IPv4-in-IPv6 streams 151 in the relevant branches of the IPv6 multicast distribution tree. 153 o Multicast B4 (mB4 for short): is a functional entity embedded in a 154 CPE, which is able to enforce an IGMP-MLD interworking function ( 155 refer to Section 6.1) together with a de-capsulation function of 156 received multicast IPv4-in-IPv6 packets. 158 3. Context and Scope 160 3.1. IPTV-centric View 162 IPTV generally includes two categories of service offerings: 164 1. VoD (Video on Demand) or Catch-up TV channels streams that are 165 delivered using unicast mode to receivers. 167 2. Live TV Broadcast services that are generally multicast to 168 receivers. 170 Numerous players intervene in the delivery of this service: 172 o Content Providers: the content can be provided by the same 173 provider as the one providing the connectivity service or by 174 distinct providers; 176 o Network Provider: the one providing network connectivity service 177 (e.g., responsible for carrying multicast flows from head-ends to 178 receivers). Refer to [I-D.ietf-mboned-multiaaa-framework]. 180 Many of the current IPTV contents are likely to remain IPv4-formatted 181 and out of control of the network providers. Additionally, there are 182 numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that 183 can't be upgraded or be easily replaced. As a consequence, IPv4 184 service continuity must be guaranteed during the transition period, 185 including the delivery of multicast-based services such as Live TV 186 Broadcasting. The dilemma is the same as in the transition of 187 unicast-based Internet services where the customer premises and 188 global Internet are out of control of the service providers even if 189 they would like to promote the use of IPv6. The DS-Lite design tries 190 to eliminate this issue by decoupling the IPv6 deployments in service 191 provider networks from that in global Internet and in customer 192 devices and applications. 194 DS-Lite can be seen as a catalyst for IPv6 deployment while 195 preserving customer's Quality of Experience (QoE). This is also the 196 design goal of the solution proposed in this document for DS-Lite 197 serviced customers who have subscribed to a multicast-based service 198 offering. 200 3.2. Scope 202 This document focuses only on issues raised by a DS-Lite networking 203 environment: subscription to an IPv4 multicast group and the delivery 204 of IPv4-formatted content to IPv4 receivers. In particular, only the 205 following case is covered: 207 1. An IPv4 receiver accessing IPv4 content (i.e., content formatted 208 and reachable in IPv4) 210 A viable scenario for this use case in DS-Lite environment: Customers 211 with legacy receivers must continue to access the IPv4-enabled 212 multicast services. This means the traffic should be accessed 213 through IPv4 and additional functions are needed to traverse 214 operators' IPv6- enabled network which is the purpose of this 215 document. While since technically, there is no extra function 216 required for the scenario of native access (i.e. to access dual-stack 217 content natively from the IPv6 receiver), this portion is not taken 218 into account. Refer to [I-D.jaclee-behave-v4v6-mcast-ps] for the 219 deployment considerations. 221 This document does not cover the case where an IPv4 host connected to 222 a CPE served by a DS-Lite AFTR can be the source of multicast 223 traffic. 225 Note that some contract agreements prevent a network provider to 226 alter the content as sent by the content provider, in particular for 227 copyright, confidentiality and SLA assurance reasons. The streams 228 should be delivered unaltered to requesting users. 230 3.3. Mitigation Alternatives 232 In order to prevent complications raised when multicast flows are to 233 cross a unicast DS-Lite AFTR, Service Providers may opt for a 234 separate IPv4 addressing scheme for the delivery of multicast-based 235 service offerings. Service-specific IPv4 addresses are then assigned 236 to multicast receivers to access a multicast-based service offering. 237 In such case, no extra complication is raised for this deployment 238 scenario. This approach is out of scope of this document. 240 For Service Providers who use a service-agnostic IP addressing scheme 241 (i.e., only one IP address is assigned to access all subscribed 242 services), dedicated solutions are to be specified to deliver 243 multicast content to DS-Lite serviced customers. This document 244 focuses on this scenario. 246 4. Solution Overview 248 In the original DS-Lite specification 249 [I-D.ietf-softwire-dual-stack-lite], an IPv4-in-IPv6 tunnel is used 250 to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. 251 This document defines an IPv4-in-IPv6 encapsulation scheme to deliver 252 multicast traffic. Within the context of this document, an IPv4 253 derived IPv6 multicast address is used as the destination of the 254 encapsulated unidirectional IPv4-in-IPv6 multicast traffic from the 255 mAFTR to the mB4. The IPv4 address of the source of the multicast 256 content is represented in the IPv6 realm with an IPv4-embedded IPv6 257 address as well. 259 See following sections for the multicast distribution tree 260 establishment (Section 4.3) and the multicast traffic forwarding 261 (Section 4.4). 263 Note that IPv4-in-IPv6 encapsulated multicast flows are treated in an 264 IPv6 realm like any other IPv6 multicast flow. Upon completion of 265 the establishment of a multicast distribution tree, no extra function 266 is required to be defined to forward IPv4-in-IPv6 multicast traffic 267 in the IPv6 network. 269 4.1. Rationale 271 This document introduces two new functional elements (Figure 1): 273 1. The mAFTR: responsible for replicating IPv4 multicast flows in 274 the IPv6 domain owing to a stateless IPv4-in-IPv6 encapsulation 275 function. The mAFTR does not undertake any NAT operation. The 276 mAFTR is a demarcation point which connects to both the IPv4 and 277 IPv6 multicast networks. 279 2. The mB4: is a functional entity embedded in a CPE responsible for 280 the de-capsulation of the received IPv4-in-IPv6 multicast packets 281 and forwarding them to the appropriate IPv4 receivers. 283 +-----------+ 284 | IPv4 | 285 | Source | 286 +-----------+ 287 | 288 ------------ 289 / \ 290 | IPv4 network | 291 \ / 292 ------------ 293 | 294 +-------------+ 295 | mAFTR | 296 +-------------+ 297 | 298 ------------ 299 / \ 300 | IPv6 network | 301 \ / 302 ------------ 303 | 304 +-----------+ 305 | mB4 | 306 +-----------+ 307 | 308 +-----------+ 309 | IPv4 | 310 | Receiver | 311 +-----------+ 313 Figure 1: Functional Architecture 315 4.2. IPv4-embedded IPv6 Address Prefixes 317 A dedicated IPv6 multicast prefix (mPrefix64) is needed for forming 318 IPv6 multicast addresses, with IPv4 multicast address embedded. The 319 mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used in 320 ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode), and MUST 321 be derived from the corresponding IPv6 multicast address space 322 [I-D.boucadair-behave-64-multicast-address-format]. 324 In addition, the address of the IPv4 multicast source should be 325 mapped to IPv6 addresses in the IPv6 realm: an IPv6 unicast prefix 326 (uPrefix64) is therefore needed for forming IPv6 unicast addresses 327 with IPv4 unicast address embedded. The uPrefix64 MUST be derived 328 from the IPv6 unicast address space [RFC6052]. 330 The mAFTR and mB4 MUST use the same mPrefixe64 and uPrefix64, and the 331 same algorithm for building IPv4-embedded IPv6 addresses. Refer to 332 Section 5 for more details on the IPv6 address format. 334 4.3. Multicast Distribution Tree 336 Assume that an IPv4 receiver sends an IGMP Report towards the mB4 to 337 join a given multicast group. After receiving the IGMP Report 338 message, the mB4 converts the IGMP message into a MLD Report 339 [RFC2710] message which will then be forwarded upstream towards the 340 MLD Querier. The MLD Querier is likely to coexist with the PIM DR 341 where the PIMv6 Join message will be triggered and sent up hop by hop 342 along the PIMv6 routers. Note that the mAFTR is in the path to reach 343 the IPv4 source; this is typically achieved by the underlying unicast 344 IPv6 routing protocol that advertises the unicast IPv4-embedded IPv6 345 addresses: these addresses are used to represent IPv4 sources in the 346 IPv6 multicast domain. 348 Both the MLD and the PIMv6 Join messages convey the IPv6 address of 349 the multicast group to be joined. The corresponding IPv6 multicast 350 group address is constructed by using the pre-configured mPrefix64 351 and an algorithm so that the IPv4 multicast group address is embedded 352 accordingly. 354 When source-specific multicast is deployed, the IPv6 address of the 355 multicast source should be constructed in the same way (using 356 uPrefix64, with IPv4 multicast source embedded). Refer to Section 357 6.1 for more details of the mB4 function. 359 o If the mAFTR is embedded in the MLD Querier/PIMv6 DR, it should 360 process the received MLD Report message for the IPv4-embedded IPv6 361 group and send the corresponding IPv4 PIM Join message. 363 o If the mAFTR is embedded in some upstream PIMv6 router more than 364 one hop away from the mB4, it should process the received PIMv6 365 Join message for the IPv4-embedded IPv6 group and send the 366 corresponding IPv4 PIM Join message. 368 In both cases, an entry for an IPv6 multicast group address is 369 created by the mAFTR in its multicast Routing Information Base and is 370 used to forward multicast IPv4-in-IPv6 datagrams. Refer to Section 371 7.1 for more details about the mAFTR function. 373 A branch of the multicast distribution tree is then established, 374 comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 375 part (between the mB4 and the mAFTR). 377 4.4. Multicast Forwarding 379 Whenever an IPv4 multicast packet is received on a mAFTR (this 380 assumes the RPF Check has passed Section 7.1), it will be 381 encapsulated into an IPv6 packet using the IPv4-embedded IPv6 382 multicast address as the destination address and an IPv4-embedded 383 IPv6 unicast address as the source of the IPv4-in-IPv6 packet. The 384 new IPv6 multicast packet will then be sent through the outgoing 385 interface of the matching entry in the multicast routing table and 386 forwarded down the IPv6 multicast distribution tree towards the mB4. 388 When receiving the packet, the mB4 should de-capsulate it and forward 389 the original IPv4 multicast packet to the appropriate receiver. If 390 mB4 does not have any route to forward the packet (e.g., change of 391 the IPv4 address without cleaning MLD states), the encapsulated IPv4 392 datagram is silently dropped. 394 Note that: There is an alternative to the encapsulation based 395 mechanism (which is detailed in this memo) for Multicast Forwarding: 396 Translation based approach, which is per 397 [I-D.boucadair-behave-64-multicast-address-format], [RFC6052] and 398 [I-D.ietf-behave-v6v4-xlate]. Refer to Appendix A. 400 4.5. Multicast DS-Lite vs. Unicast DS-Lite 402 Unlike a unicast AFTR, a mAFTR does not perform any NAT for 403 delivering IPv4 multicast traffic. 405 Unlike unicast DS-Lite, a mB4 does not need to discover a mAFTR. 407 mAFTR is responsible for encapsulating in a stateless manner the IPv4 408 multicast traffic into IPv6 datagrams. mB4 is responsible for de- 409 capsulating in a stateless manner the IPv4-in-IPv6 multicast traffic. 410 Further elaboration is provided in the following sections about the 411 behaviour of the mAFTR and the mB4. 413 The corresponding multicast DS-Lite and the unicast DS-Lite 414 functional elements can be co-located in the same device or 415 separated. 417 4.6. Fall-Back Mode 419 If MLD is not activated on mB4, and if this is allowed in the CPE, 420 multicast flows may be exchanged in a Fall-Back mode. That is to be 421 based on the Unicast DS-Lite architecture where the IGMP messages are 422 encapsulated and transmitted through the tunnel, additionally the 423 AFTR will perform the IGMP Querier function. 425 Note: It is obvious that the Fall-Back mode is not optimal if the 426 unicast AFTR is not the first IP node. In a such mode, multicast 427 capabilities are not used in the leg between the CE and the AFTR. 428 This is NOT RECOMMENDED. 430 5. Address Mapping 432 5.1. Prefix Assignment 434 In order to map the addresses of IPv4 multicast traffic with IPv6 435 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 436 unicast prefix (uPrefix64) are provided to mAFTR and mB4 elements. 438 The address format to be used is being left to the responsibility of 439 the service provider as indicated in [RFC6052] and 440 [I-D.boucadair-behave-64-multicast-address-format]. 442 The mPrefix64 and uPrefix64 together with the address format to be 443 used can be configured in the mB4 through a dedicated provisioning 444 protocol, such as DHCPv6 or another protocol. Two candidate DHCPv6 445 options are identified in [I-D.korhonen-behave-nat64-learn-analysis]. 447 5.2. Text Representation Examples 449 Group address mapping example when a /96 is used: 451 +----------------------+--------------+-----------------------------+ 452 | mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | 453 +----------------------+--------------+-----------------------------+ 454 | ffxx:abc::/96 | 230.1.2.3 | ffxx:abc::230.1.2.3 | 455 +----------------------+--------------+-----------------------------+ 457 Source address mapping example when a /96 is used: 459 +----------------------+--------------+-----------------------------+ 460 | uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | 461 +----------------------+--------------+-----------------------------+ 462 | 2001:db8::/96 | 192.1.2.3 | 2001:db8::192.1.2.3 | 463 +----------------------+--------------+-----------------------------+ 465 6. Multicast B4 (mB4) 467 6.1. IGMP-MLD Interworking function 469 IGMP-MLD Interworking function combines the IGMP/MLD Proxying 470 function specified in [RFC4605] and the IGMP/MLD adaptation function 471 which is meant to reflect the contents of IGMP messages into MLD 472 messages. 474 Then mB4 performs the router portion of the IGMP protocol on each 475 downstream interface and performs the host portion of the MLD 476 protocol on the upstream interface (Figure 2). 478 The output of the operation is a set of membership information which 479 is maintained separately on each downstream interface (e.g., Wifi and 480 Wired Ethernet). In addition, the membership information on each 481 downstream interface is merged into the membership database on which 482 the IPv4 multicast packets are forwarded by mB4. 484 +----------+ IGMP +-------+ MLD +---------+ 485 | IPv4 |---------| CPE |---------| MLD | 486 | Receiver | | mB4 | | Querier | 487 +----------+ +-------+ +---------+ 489 Figure 2: IGMP-MLD Interworking 491 When an IGMP Report message is received from a receiver to subscribe 492 to a given multicast group G (e.g., 230.1.2.3) (and optionally 493 associated to a source 192.1.2.3 if SSM mode is used), the mB4 MUST 494 send an MLD Report message to subscribe to the corresponding IPv6 495 group identified by an IPv4-embedded IPv6 multicast address using a 496 pre-configured prefix and algorithm (e.g., ffxx:abc::230.1.2.3 (and 497 optionally source 2001:db8::192.1.2.3 if SSM mode is used)). The MLD 498 Report message is sent through the upstream interface natively (i.e., 499 without any encapsulation). 501 6.2. De-capsulation and Forwarding 503 When the mB4 receives an IPv6 multicast packet, it checks whether the 504 group address is in the range of mPrefix64 and the source address is 505 in the range of uPrefix64. If it is true, the mB4 MUST de-capsulate 506 the IPv4-in-IPv6 packets to extract the original IPv4 multicast 507 packets. 509 Then the IPv4 multicast packet will be forwarded to downstream 510 receivers based on information maintained by the mB4 in the 511 membership database. If no route is found, the packet is silently 512 dropped. 514 6.3. Fragmentation 516 Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding 517 reduces the effective MTU size by the size of an IPv6 header 518 (assuming [RFC2473] encapsulation). To avoid fragmentation, a 519 service provider may increase the MTU size by 40 bytes on the IPv6 520 network or mAFTR and mB4 may use IPv6 Path MTU discovery. 522 6.4. Host with mB4 function embedded 524 The mB4 function can be embedded in the CE or in a dual-stack host 525 behind the CP router (e.g., STB). If mB4 is embedded in the STB, the 526 IGMP-MLD interworking function is not needed. The STB should 527 formulate the MLD message correspondingly based on given IPv4 group 528 address to be joint using mPrefix64 (and uPrefix64 for IPv4-embedded 529 source if SSM is deployed), and de-encapsulate the downstream 530 multicast traffics received by itself. 532 7. Multicast AFTR (mAFTR) 534 7.1. Routing Considerations 536 Except the need for the mAFTR to belong to IPv4 multicast 537 distribution trees and to be on the reverse path towards the source 538 when performing RPF checks on PIMv6 routers, no further routing 539 constraint is to be taken into account. 541 Having the mAFTR in the reverse path ensures PIM Join sent to the 542 source (e.g., SSM mode or SPT mode in ASM) will be intercepted by the 543 mAFTR. 545 7.2. Processing PIM/MLD Join Messages 547 Upon receipt of the PIM/MLD Join for an IPv6 group (e.g., ffxx:abc:: 548 230.1.2.3), the mAFTR checks the corresponding entry in the IPv6 549 multicast routing table and adds the IPv6 interface through which the 550 Join message has been received into the Out-Interface-List of that 551 entry. If the entry does not exist, a new one will be created, as 552 per typical PIM machinery [RFC4601]. The mAFTR should check whether 553 the IPv6 group address belongs to the mPrefix64 (e.g., ffxx: 554 abc::/96). If so, the mAFTR will need to extract the IPv4 group 555 address (e.g., 230.1.2.3) from the IPv4-embedded IPv6 address (e.g., 556 according to [I-D.boucadair-behave-64-multicast-address-format]) and 557 check the corresponding entry in the IPv4 multicast routing table 558 then add the tunnel interface into the Out-Interface-List of that 559 entry. If the entry does not exist, a new entry should be created 560 and a PIM join message for that IPv4 group will be sent towards the 561 RP or source connected to the IPv4 network. 563 When SSM is deployed, the mAFTR would in addition check if the source 564 (e.g., 2001:db8::192.1.2.3) described in the PIMv6 Join message 565 belongs to uPrefix64 (e.g., 2001:db8::/96). If so, it can then send 566 a PIM (S, G) Join message directly towards the IPv4 source (e.g., 567 192.1.2.3). 569 The initialization of the tunnel interface (used for encapsulation 570 purposes) on the mAFTR is out of the scope of this document. 572 7.3. Reliability 574 For robustness, reliability and load distribution purposes, several 575 nodes in the network can embed the mAFTR function. In such case, the 576 same IPv6 prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to 577 build IPv4-embedded IPv6 addresses MUST be configured on those nodes. 579 7.4. ASM Mode: Building Shared Trees 581 7.4.1. IPv4 Side 583 For a given Rendezvous Point (RP) used in the IPv4 realm, there is no 584 new requirement. Like any other IPv4 PIM router, the RP of each IPv4 585 multicast groups is configured to the mAFTR or discovered using some 586 appropriate means. Moreover, PIM-SM registration procedure [RFC4601] 587 in the IPv4 realm is not impacted. 589 Shared IPv4 multicast trees are built using the procedure defined in 590 [RFC4601] for instance. 592 7.4.2. IPv6 Side 594 In the IPv6 side, the RP of IPv4-embedded IPv6 multicast groups is 595 configured to all IPv6 PIM routers or discovered using appropriate 596 means. For the sake of simplicity, it is RECOMMENDED to configure an 597 mAFTR as the RP for IPv4-embedded IPv6 multicast groups. 599 [Note 1: If some other IPv6 multicast router wants to become the 600 RP of the IPv4-embedded IPv6 multicast groups, it may require an 601 mAFTR to emulate the PIM Source Register procedure on behalf of 602 IPv4-embedded IPv6 sources with the RP. The PIM Source Register 603 procedure in the IPv4 domain is not altered.] 605 [Note 2: How the mAFTR is aware about the sources? This can be 606 considered as deployment-specific: 608 (i) By configuration: mAFTR can be configured to join a set of 609 IPv4 multicast groups and to initiate a registration procedure 610 on behalf of a set of sources to the RP in the v6 domain; 612 (ii) Dynamic: this assumes that mAFTR is configured to join a 613 set of IPv4 multicast groups. The source address of received 614 flows will be used as a trigger to initiate the registration 615 procedure to the RP in the IPv6 domain. There is a special 616 case where mAFTR is the RP of the IPv4 group in the IPv4 617 domain: The registration procedure should then be relayed to 618 the RP in the IPv6 domain. 620 ] 622 Shared IPv6 multicast trees are built using the procedure defined in 623 [RFC4601] for instance. Switching from a shared tree to source-based 624 tree can be accommodated since the mAFTR is in the path to join the 625 source. 627 The mAFTR will graft to the IPv4 shared tree either because it has 628 been configured with the list of IPv4 multicast groups that will be 629 subscribed by the DS-Lite serviced receivers downstream or upon 630 receipt of a PIMv6 Join message. 632 An example of the exchange of PIM messages is illustrated in 633 Figure 3. 635 ------------ 636 / \ 637 | IPv4 network | 638 \ / 639 ------------ 640 : | ^ 641 IPv4 Multicast : | : PIMv4 Join 642 v | : 643 +-------------+ 644 | mAFTR | 645 +-------------+ 646 |:| | ^ 647 IPv6 Multicast |:| | : (PIMv6 Join, PIMv6 Routers in between) 648 (IPv4 embedded) |.| ... . 649 ------------ 650 / \ 651 | IPv6 network | 652 \ / 653 ------------ 654 |:| | : MLD Report 655 |v| | : 656 +-----------+ 657 | mB4 | 658 +-----------+ 659 : | ^ 660 IPv4 Multicast : | : IGMP Report 661 v | : 662 +-----------+ 663 | IPv4 | 664 | Receiver | 665 +-----------+ 667 Figure 3: Procedure Overview 669 7.5. TTL/Scope 671 The Scope field of IPv4-in-IPv6 multicast addresses can be valued to 672 "E" (Global scope) or to "8" (Organization-local scope). This is 673 left to service providers taste. 675 7.6. Encapsulation and forwarding 677 When receiving an IPv4 multicast packet, a lookup of the IPv4 678 multicast routing table is performed by the PIMv4 router that embeds 679 the mAFTR capability. If an interface used for IPv4-in-IPv6 680 encapsulation is found in the Out-Interface-List of the matching 681 entry, the encapsulation operation is triggered. The mAFTR 682 encapsulates in a stateless fashion the IPv4 multicast packet into an 683 IPv6 multicast datagram. It MUST use the pre-provisioned mPrefix64/ 684 uPrefix64 together with an algorithm for building the IPv4-embedded 685 IPv6 multicast address that identifies the multicast group, as well 686 as the IPv6 source address that represents the IPv4 source in the 687 IPv6 network. 689 As an illustration, if a packet is received from source 192.1.2.3 and 690 forwarded to group 230.1.2.3, the mAFTR encapsulates it into an IPv6 691 multicast packet using ffxx:abc::230.1.2.3 as the destination IPv6 692 address and 2001:db8::192.1.2.3 as the multicast source address. 694 Then a lookup of the IPv6 multicast routing table is performed by the 695 PIMv6 router that embeds the mAFTR capability, based on the IPv4- 696 embedded IPv6 address. If a matching entry is found and there exist 697 IPv6 interfaces in the Out-Interface-List, the IPv6 multicast packet 698 will be sent out through these interfaces and forwarded down the 699 multicast distribution tree towards the mB4 devices. 701 8. Optimization in L2 Access Networks 703 The approach specified in this document is compatible with a Layer-2 704 infrastructure which may be involved for deterministic multicast 705 replication. 707 The IPv4-in-IPv6 encapsulated multicast flows destined to IPv4- 708 embedded IPv6 group addresses are treated as any IPv6 multicast flow, 709 and can be replicated within Multicast VLANs. Additionally, 710 mechanisms such as MLD Snooping, MLD Proxying, etc., can be 711 introduced into the distributed Access Network Nodes (e.g., 712 Aggregation Switches, xPON devices) which then could behave as MLD 713 Querier and replicate multicast flows as appropriate. Thus, the 714 multicast replication point is moved downward closer to the 715 receivers, so that bandwidth consumption is optimized. 717 9. Security Considerations 719 This document does not introduce any new security concern in addition 720 to what is discussed in Section 5 of [RFC6052], Section 10 of 721 [RFC3810] and Section 6 of [RFC4601]. 723 9.1. Firewall Configuration 725 The CPE should be configured to accept incoming MLD messages and 726 traffic forwarded to multicast groups subscribed by receivers located 727 in the customer premises. 729 10. Acknowledgements 731 The authors would like to thank Dan Wing for his guidance in the 732 early discussions which initiated this work. We also appreciate Jie 733 Hu, Qiong Sun, Lizhong Jin, Alain Durand, Dean Cheng, Behcet Sarikaya 734 for their valuable comments. 736 11. IANA Considerations 738 This document includes no request to IANA. 740 12. References 742 12.1. Normative References 744 [I-D.boucadair-behave-64-multicast-address-format] 745 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 746 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", 747 draft-boucadair-behave-64-multicast-address-format-01 748 (work in progress), February 2011. 750 [I-D.ietf-behave-v6v4-xlate] 751 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 752 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 753 progress), September 2010. 755 [I-D.ietf-softwire-dual-stack-lite] 756 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 757 Stack Lite Broadband Deployments Following IPv4 758 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 759 in progress), March 2011. 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 765 Listener Discovery (MLD) for IPv6", RFC 2710, 766 October 1999. 768 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 769 Thyagarajan, "Internet Group Management Protocol, Version 770 3", RFC 3376, October 2002. 772 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 773 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 775 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 776 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 777 Protocol Specification (Revised)", RFC 4601, August 2006. 779 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 780 "Internet Group Management Protocol (IGMP) / Multicast 781 Listener Discovery (MLD)-Based Multicast Forwarding 782 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 784 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 785 IP", RFC 4607, August 2006. 787 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 788 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 789 October 2010. 791 12.2. Informative References 793 [I-D.ietf-mboned-multiaaa-framework] 794 Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. 795 He, "AAA and Admission Control Framework for 796 Multicasting", draft-ietf-mboned-multiaaa-framework-12 797 (work in progress), August 2010. 799 [I-D.jaclee-behave-v4v6-mcast-ps] 800 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 801 ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use 802 Cases", draft-jaclee-behave-v4v6-mcast-ps-00 (work in 803 progress), March 2011. 805 [I-D.korhonen-behave-nat64-learn-analysis] 806 Korhonen, J. and T. Savolainen, "Analysis of solution 807 proposals for hosts to learn NAT64 prefix", 808 draft-korhonen-behave-nat64-learn-analysis-02 (work in 809 progress), February 2011. 811 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 812 2", RFC 2236, November 1997. 814 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 815 IPv6 Specification", RFC 2473, December 1998. 817 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 818 Group Management Protocol Version 3 (IGMPv3) and Multicast 819 Listener Discovery Protocol Version 2 (MLDv2) for Source- 820 Specific Multicast", RFC 4604, August 2006. 822 [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific 823 Protocol Independent Multicast in 232/8", BCP 120, 824 RFC 4608, August 2006. 826 Appendix A. Translation vs. Encapsulation 828 In order to deliver IPv4 multicast flows to DS-Lite serviced 829 receivers, two options can be considered:(1) Translation; 830 (2)Encapsulation. 832 Refer to [I-D.jaclee-behave-v4v6-mcast-ps] for the issues and 833 requirements of Translation vs. Encapsulation. 835 A.1. Translation 837 To delivery IPv4 multicasst contents to an IPv4 receiver: Introduce 838 translation functions at the boundaries of IPv6 network. The IPv4- 839 translated multicast streams are distributed within the IPv6 network 840 natively until the customer premises device where the IPv4-translated 841 IPv6 streams are translated back and passed to IPv4 receivers. 842 Multicast Distribution Tree is established by normal machinery of 843 control protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking 844 functions (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and 845 Section 7. The translation function is stateless owing to the use of 846 IPv4-Embedded IPv6 address 847 [I-D.boucadair-behave-64-multicast-address-format] and [RFC6052]. 849 A.2. Encapsulation 851 To deliver IPv4 multicast contents to an IPv4 receiver: Introduce two 852 elements at the boundaries of IPv6 network, mAFTR and mB4. Multicast 853 Distribution Tree is established by normal machinery of control 854 protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking functions 855 (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and Section 7. 856 Multicast streams are forwarded to a receiver by using an IPv4-in- 857 IPv6 encapsulation scheme. The encapsulation/de-capsulation function 858 is stateless owing to the use of IPv4-Embedded IPv6 address 859 [I-D.boucadair-behave-64-multicast-address-format] and [RFC6052]. 861 Authors' Addresses 863 Qian Wang 864 China Telecom 865 No.118, Xizhimennei 866 Beijing, 100035 867 China 869 Phone: +86 10 5855 2177 870 Email: wangqian@ctbri.com.cn 872 Jacni Qin 873 ZTE 874 Shanghai, 875 China 877 Phone: +86 1391 8619 913 878 Email: jacniq@gmail.com 880 Peng Sun 881 ZTE 882 Shanghai, 883 China 885 Phone: +86 21 6889 7101 886 Email: sun.peng@zte.com.cn 888 Mohamed Boucadair 889 France Telecom 890 Rennes, 35000 891 France 893 Phone: 894 Email: mohamed.boucadair@orange-ftgroup.com 896 Christian Jacquenet 897 France Telecom 898 Rennes, 35000 899 France 901 Phone: 902 Email: christian.jacquenet@orange-ftgroup.com 903 Yiu L. Lee 904 Comcast 905 U.S.A. 907 Phone: 908 Email: yiu_lee@cable.comcast.com 909 URI: http://www.comcast.com