idnits 2.17.1 draft-ietf-softwire-dslite-multicast-00.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 date (September 10, 2011) is 4604 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 781, but no explicit reference was found in the text == Unused Reference: 'RFC4608' is defined on line 786, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-boucadair-behave-64-multicast-address-format-02 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-03) exists of draft-ietf-behave-nat64-learn-analysis-00 == Outdated reference: A later version (-03) exists of draft-jaclee-behave-v4v6-mcast-ps-02 Summary: 2 errors (**), 0 flaws (~~), 8 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: March 13, 2012 ZTE 6 M. Boucadair 7 C. Jacquenet 8 France Telecom 9 Y. Lee 10 Comcast 11 September 10, 2011 13 Multicast Extensions to DS-Lite Technique in Broadband Deployments 14 draft-ietf-softwire-dslite-multicast-00 16 Abstract 18 This document proposes a solution for the delivery of multicast 19 service offerings to DS-Lite serviced customers. The proposed 20 solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme 21 and does not require performing any NAT operation along the path used 22 to deliver multicast traffic. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 13, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. IPTV-centric View . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. IPv4-embedded IPv6 Address Prefixes . . . . . . . . . . . 8 67 4.3. Multicast Distribution Tree . . . . . . . . . . . . . . . 9 68 4.4. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 10 69 4.5. Multicast DS-Lite vs. Unicast DS-Lite . . . . . . . . . . 10 70 5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 10 72 5.2. Text Representation Examples . . . . . . . . . . . . . . . 11 73 6. Multicast B4 (mB4) . . . . . . . . . . . . . . . . . . . . . . 11 74 6.1. IGMP-MLD Interworking function . . . . . . . . . . . . . . 11 75 6.2. De-capsulation and Forwarding . . . . . . . . . . . . . . 12 76 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12 77 6.4. Host with mB4 function embedded . . . . . . . . . . . . . 12 78 7. Multicast AFTR (mAFTR) . . . . . . . . . . . . . . . . . . . . 13 79 7.1. Routing Considerations . . . . . . . . . . . . . . . . . . 13 80 7.2. Processing PIM/MLD Join Messages . . . . . . . . . . . . . 13 81 7.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.4. ASM Mode: Building Shared Trees . . . . . . . . . . . . . 14 83 7.4.1. IPv4 Side . . . . . . . . . . . . . . . . . . . . . . 14 84 7.4.2. IPv6 Side . . . . . . . . . . . . . . . . . . . . . . 14 85 7.5. TTL/Scope . . . . . . . . . . . . . . . . . . . . . . . . 15 86 7.6. Encapsulation and forwarding . . . . . . . . . . . . . . . 16 87 8. Optimization in L2 Access Networks . . . . . . . . . . . . . . 16 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 9.1. Firewall Configuration . . . . . . . . . . . . . . . . . . 17 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 94 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 95 Appendix A. Translation vs. Encapsulation . . . . . . . . . . . . 19 96 A.1. Translation . . . . . . . . . . . . . . . . . . . . . . . 19 97 A.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 DS-Lite [RFC6333] is a technique to rationalize the use of the 103 remaining IPv4 addresses during the transition period. The current 104 design of DS-Lite covers unicast services exclusively. 106 If customers access IPv4 multicast-based service offerings through a 107 DS-Lite environment, AFTR (Address Family Transition Router) devices 108 have to process all the IGMP reports [RFC2236] [RFC3376] received 109 within IPv4-in-IPv6 tunnels and behave as a replication point for 110 downstream multicast traffic. That is likely to severely affect the 111 multicast traffic forwarding efficiency by losing the benefits of 112 deterministic replication of the data as close to the receivers as 113 possible. As a consequence, the downstream bandwidth will be vastly 114 consumed while the AFTR capability may become rapidly overloaded, in 115 particular if the AFTR capability is deployed in a centralized 116 manner. 118 This document discusses an extension to the DS-Lite model to be used 119 for the delivery of IPv4 multicast-based service offerings. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Terminology 129 This document makes use of the following terms: 131 o IPv4-embedded IPv6 address: is an IPv6 address which embeds a 32 132 bit-encoded IPv4 address. An IPv4-embedded IPv6 address can be 133 unicast or multicast. 135 o mPrefix64: is a dedicated multicast IPv6 prefix for constructing 136 IPv4-embedded IPv6 multicast address 137 [I-D.boucadair-behave-64-multicast-address-format]. mPrefix64 can 138 be of two types: ASM_mPrefix64 used in ASM mode or SSM_mPrefix64 139 used in SSM mode [RFC4607]. 141 o uPrefix64: is a dedicated unicast IPv6 prefix for constructing 142 IPv4-embedded IPv6 unicast address [RFC6052]. 144 o Multicast AFTR (mAFTR for short): is a functional entity which is 145 part of both the IPv4 and IPv6 multicast distribution trees and 146 which replicates IPv4 multicast streams into IPv4-in-IPv6 streams 147 in the relevant branches of the IPv6 multicast distribution tree. 149 o Multicast B4 (mB4 for short): is a functional entity embedded in a 150 CPE, which is able to enforce an IGMP-MLD interworking function ( 151 refer to Section 6.1) together with a de-capsulation function of 152 received multicast IPv4-in-IPv6 packets. 154 3. Context and Scope 156 3.1. IPTV-centric View 158 IPTV generally includes two categories of service offerings: 160 1. VoD (Video on Demand) or Catch-up TV channels streams that are 161 delivered using unicast mode to receivers. 163 2. Live TV Broadcast services that are generally multicast to 164 receivers. 166 Numerous players intervene in the delivery of this service: 168 o Content Providers: the content can be provided by the same 169 provider as the one providing the connectivity service or by 170 distinct providers; 172 o Network Provider: the one providing network connectivity service 173 (e.g., responsible for carrying multicast flows from head-ends to 174 receivers). Refer to [I-D.ietf-mboned-multiaaa-framework]. 176 Many of the current IPTV contents are likely to remain IPv4-formatted 177 and out of control of the network providers. Additionally, there are 178 numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that 179 can't be upgraded or be easily replaced. As a consequence, IPv4 180 service continuity must be guaranteed during the transition period, 181 including the delivery of multicast-based services such as Live TV 182 Broadcasting. The dilemma is the same as in the transition of 183 unicast-based Internet services where the customer premises and 184 global Internet are out of control of the service providers even if 185 they would like to promote the use of IPv6. The DS-Lite design tries 186 to eliminate this issue by decoupling the IPv6 deployments in service 187 provider networks from that in global Internet and in customer 188 devices and applications. 190 DS-Lite can be seen as a catalyst for IPv6 deployment while 191 preserving customer's Quality of Experience (QoE). This is also the 192 design goal of the solution proposed in this document for DS-Lite 193 serviced customers who have subscribed to a multicast-based service 194 offering. 196 3.2. Scope 198 This document focuses only on issues raised by a DS-Lite networking 199 environment: subscription to an IPv4 multicast group and the delivery 200 of IPv4-formatted content to IPv4 receivers. In particular, only the 201 following case is covered: 203 1. An IPv4 receiver accessing IPv4 content (i.e., content formatted 204 and reachable in IPv4) 206 A viable scenario for this use case in DS-Lite environment: Customers 207 with legacy receivers must continue to access the IPv4-enabled 208 multicast services. This means the traffic should be accessed 209 through IPv4 and additional functions are needed to traverse 210 operators' IPv6- enabled network which is the purpose of this 211 document. While since technically, there is no extra function 212 required for the scenario of native access (i.e. to access dual-stack 213 content natively from the IPv6 receiver), this portion is not taken 214 into account. Refer to [I-D.jaclee-behave-v4v6-mcast-ps] for the 215 deployment considerations. 217 This document does not cover the case where an IPv4 host connected to 218 a CPE served by a DS-Lite AFTR can be the source of multicast 219 traffic. 221 Note that some contract agreements prevent a network provider to 222 alter the content as sent by the content provider, in particular for 223 copyright, confidentiality and SLA assurance reasons. The streams 224 should be delivered unaltered to requesting users. 226 4. Solution Overview 228 In the original DS-Lite specification [RFC6333], an IPv4-in-IPv6 229 tunnel is used to carry the bidirectional IPv4 unicast traffic 230 between B4 and AFTR. This document defines an IPv4-in-IPv6 231 encapsulation scheme to deliver multicast traffic. Within the 232 context of this document, an IPv4 derived IPv6 multicast address is 233 used as the destination of the encapsulated unidirectional IPv4-in- 234 IPv6 multicast traffic from the mAFTR to the mB4. The IPv4 address 235 of the source of the multicast content is represented in the IPv6 236 realm with an IPv4-embedded IPv6 address as well. 238 See following sections for the multicast distribution tree 239 establishment (Section 4.3) and the multicast traffic forwarding 240 (Section 4.4). 242 Note that IPv4-in-IPv6 encapsulated multicast flows are treated in an 243 IPv6 realm like any other IPv6 multicast flow. Upon completion of 244 the establishment of a multicast distribution tree, no extra function 245 is required to be defined to forward IPv4-in-IPv6 multicast traffic 246 in the IPv6 network. 248 4.1. Rationale 250 This document introduces two new functional elements (Figure 1): 252 1. The mAFTR: responsible for replicating IPv4 multicast flows in 253 the IPv6 domain owing to a stateless IPv4-in-IPv6 encapsulation 254 function. The mAFTR does not undertake any NAT operation. The 255 mAFTR is a demarcation point which connects to both the IPv4 and 256 IPv6 multicast networks. 258 2. The mB4: is a functional entity embedded in a CPE responsible for 259 the de-capsulation of the received IPv4-in-IPv6 multicast packets 260 and forwarding them to the appropriate IPv4 receivers. 262 +-----------+ 263 | IPv4 | 264 | Source | 265 +-----------+ 266 | 267 ------------ 268 / \ 269 | IPv4 network | 270 \ / 271 ------------ 272 | 273 +-------------+ 274 | mAFTR | 275 +-------------+ 276 | 277 ------------ 278 / \ 279 | IPv6 network | 280 \ / 281 ------------ 282 | 283 +-----------+ 284 | mB4 | 285 +-----------+ 286 | 287 +-----------+ 288 | IPv4 | 289 | Receiver | 290 +-----------+ 292 Figure 1: Functional Architecture 294 4.2. IPv4-embedded IPv6 Address Prefixes 296 A dedicated IPv6 multicast prefix (mPrefix64) is needed for forming 297 IPv6 multicast addresses, with IPv4 multicast address embedded. The 298 mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used in 299 ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode), and MUST 300 be derived from the corresponding IPv6 multicast address space 301 [I-D.boucadair-behave-64-multicast-address-format]. 303 In addition, the address of the IPv4 multicast source should be 304 mapped to IPv6 addresses in the IPv6 realm: an IPv6 unicast prefix 305 (uPrefix64) is therefore needed for forming IPv6 unicast addresses 306 with IPv4 unicast address embedded. The uPrefix64 MUST be derived 307 from the IPv6 unicast address space [RFC6052]. 309 The mAFTR and mB4 MUST use the same mPrefix64 and uPrefix64, and the 310 same algorithm for building IPv4-embedded IPv6 addresses. Refer to 311 Section 5 for more details on the IPv6 address format. 313 4.3. Multicast Distribution Tree 315 Assume that an IPv4 receiver sends an IGMP Report towards the mB4 to 316 join a given multicast group. After receiving the IGMP Report 317 message, the mB4 converts the IGMP message into a MLD Report 318 [RFC2710] message which will then be forwarded upstream towards the 319 MLD Querier. The MLD Querier is likely to coexist with the PIM DR 320 where the PIMv6 Join message will be triggered and sent up hop by hop 321 along the PIMv6 routers. Note that the mAFTR is in the path to reach 322 the IPv4 source; this is typically achieved by the underlying unicast 323 IPv6 routing protocol that advertises the unicast IPv4-embedded IPv6 324 addresses: these addresses are used to represent IPv4 sources in the 325 IPv6 multicast domain. 327 Both the MLD and the PIMv6 Join messages convey the IPv6 address of 328 the multicast group to be joined. The corresponding IPv6 multicast 329 group address is constructed by using the pre-configured mPrefix64 330 and an algorithm so that the IPv4 multicast group address is embedded 331 accordingly. 333 When source-specific multicast is deployed, the IPv6 address of the 334 multicast source should be constructed in the same way (using 335 uPrefix64, with IPv4 multicast source embedded). Refer to Section 336 6.1 for more details of the mB4 function. 338 o If the mAFTR is embedded in the MLD Querier/PIMv6 DR, it should 339 process the received MLD Report message for the IPv4-embedded IPv6 340 group and send the corresponding IPv4 PIM Join message. 342 o If the mAFTR is embedded in some upstream PIMv6 router more than 343 one hop away from the mB4, it should process the received PIMv6 344 Join message for the IPv4-embedded IPv6 group and send the 345 corresponding IPv4 PIM Join message. 347 In both cases, an entry for an IPv6 multicast group address is 348 created by the mAFTR in its multicast Routing Information Base and is 349 used to forward multicast IPv4-in-IPv6 datagrams. Refer to Section 350 7.1 for more details about the mAFTR function. 352 A branch of the multicast distribution tree is then established, 353 comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 354 part (between the mB4 and the mAFTR). 356 4.4. Multicast Forwarding 358 Whenever an IPv4 multicast packet is received on a mAFTR (this 359 assumes the RPF Check has passed Section 7.1), it will be 360 encapsulated into an IPv6 packet using the IPv4-embedded IPv6 361 multicast address as the destination address and an IPv4-embedded 362 IPv6 unicast address as the source of the IPv4-in-IPv6 packet. The 363 new IPv6 multicast packet will then be sent through the outgoing 364 interface of the matching entry in the multicast routing table and 365 forwarded down the IPv6 multicast distribution tree towards the mB4. 367 When receiving the packet, the mB4 should de-capsulate it and forward 368 the original IPv4 multicast packet to the appropriate receiver. If 369 mB4 does not have any route to forward the packet (e.g., change of 370 the IPv4 address without cleaning MLD states), the encapsulated IPv4 371 datagram is silently dropped. 373 Note that: There is an alternative to the encapsulation based 374 mechanism (which is detailed in this memo) for Multicast Forwarding: 375 Translation based approach, which is per 376 [I-D.boucadair-behave-64-multicast-address-format], [RFC6052] and 377 [RFC6145]. Refer to Appendix A. 379 4.5. Multicast DS-Lite vs. Unicast DS-Lite 381 Unlike a unicast AFTR, a mAFTR does not perform any NAT for 382 delivering IPv4 multicast traffic. 384 Unlike unicast DS-Lite, a mB4 does not need to discover a mAFTR. 386 mAFTR is responsible for encapsulating in a stateless manner the IPv4 387 multicast traffic into IPv6 datagrams. mB4 is responsible for de- 388 capsulating in a stateless manner the IPv4-in-IPv6 multicast traffic. 389 Further elaboration is provided in the following sections about the 390 behaviour of the mAFTR and the mB4. 392 The corresponding multicast DS-Lite and the unicast DS-Lite 393 functional elements can be co-located in the same device or 394 separated. 396 5. Address Mapping 398 5.1. Prefix Assignment 400 In order to map the addresses of IPv4 multicast traffic with IPv6 401 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 402 unicast prefix (uPrefix64) are provided to mAFTR and mB4 elements. 404 The address format to be used is being left to the responsibility of 405 the service provider as indicated in [RFC6052] and 406 [I-D.boucadair-behave-64-multicast-address-format]. 408 The mPrefix64 and uPrefix64 together with the address format to be 409 used can be configured in the mB4 through a dedicated provisioning 410 protocol, such as DHCPv6 or another protocol. Two candidate DHCPv6 411 options are identified in [I-D.ietf-behave-nat64-learn-analysis]. 413 5.2. Text Representation Examples 415 Group address mapping example when a /96 is used: 417 +----------------------+--------------+-----------------------------+ 418 | mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | 419 +----------------------+--------------+-----------------------------+ 420 | ffxx:abc::/96 | 230.1.2.3 | ffxx:abc::230.1.2.3 | 421 +----------------------+--------------+-----------------------------+ 423 Source address mapping example when a /96 is used: 425 +----------------------+--------------+-----------------------------+ 426 | uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | 427 +----------------------+--------------+-----------------------------+ 428 | 2001:db8::/96 | 192.1.2.3 | 2001:db8::192.1.2.3 | 429 +----------------------+--------------+-----------------------------+ 431 6. Multicast B4 (mB4) 433 6.1. IGMP-MLD Interworking function 435 IGMP-MLD Interworking function combines the IGMP/MLD Proxying 436 function specified in [RFC4605] and the IGMP/MLD adaptation function 437 which is meant to reflect the contents of IGMP messages into MLD 438 messages. 440 Then mB4 performs the router portion of the IGMP protocol on each 441 downstream interface and performs the host portion of the MLD 442 protocol on the upstream interface (Figure 2). 444 The output of the operation is a set of membership information which 445 is maintained separately on each downstream interface (e.g., Wifi and 446 Wired Ethernet). In addition, the membership information on each 447 downstream interface is merged into the membership database on which 448 the IPv4 multicast packets are forwarded by mB4. 450 +----------+ IGMP +-------+ MLD +---------+ 451 | IPv4 |---------| CPE |---------| MLD | 452 | Receiver | | mB4 | | Querier | 453 +----------+ +-------+ +---------+ 455 Figure 2: IGMP-MLD Interworking 457 When an IGMP Report message is received from a receiver to subscribe 458 to a given multicast group G (e.g., 230.1.2.3) (and optionally 459 associated to a source 192.1.2.3 if SSM mode is used), the mB4 MUST 460 send an MLD Report message to subscribe to the corresponding IPv6 461 group identified by an IPv4-embedded IPv6 multicast address using a 462 pre-configured prefix and algorithm (e.g., ffxx:abc::230.1.2.3 (and 463 optionally source 2001:db8::192.1.2.3 if SSM mode is used)). The MLD 464 Report message is sent through the upstream interface natively (i.e., 465 without any encapsulation). 467 6.2. De-capsulation and Forwarding 469 When the mB4 receives an IPv6 multicast packet, it checks whether the 470 group address is in the range of mPrefix64 and the source address is 471 in the range of uPrefix64. If it is true, the mB4 MUST de-capsulate 472 the IPv4-in-IPv6 packets to extract the original IPv4 multicast 473 packets. 475 Then the IPv4 multicast packet will be forwarded to downstream 476 receivers based on information maintained by the mB4 in the 477 membership database. If no route is found, the packet is silently 478 dropped. 480 6.3. Fragmentation 482 Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding 483 reduces the effective MTU size by the size of an IPv6 header 484 (assuming [RFC2473] encapsulation). To avoid fragmentation, a 485 service provider may increase the MTU size by 40 bytes on the IPv6 486 network or mAFTR and mB4 may use IPv6 Path MTU discovery. 488 6.4. Host with mB4 function embedded 490 The mB4 function can be embedded in the CE or in a dual-stack host 491 behind the CP router (e.g., STB). If mB4 is embedded in the STB, the 492 IGMP-MLD interworking function is not needed. The STB should 493 formulate the MLD message correspondingly based on given IPv4 group 494 address to be joint using mPrefix64 (and uPrefix64 for IPv4-embedded 495 source if SSM is deployed), and de-encapsulate the downstream 496 multicast traffics received by itself. 498 7. Multicast AFTR (mAFTR) 500 7.1. Routing Considerations 502 Except the need for the mAFTR to belong to IPv4 multicast 503 distribution trees and to be on the reverse path towards the source 504 when performing RPF checks on PIMv6 routers, no further routing 505 constraint is to be taken into account. 507 Having the mAFTR in the reverse path ensures PIM Join sent to the 508 source (e.g., SSM mode or SPT mode in ASM) will be intercepted by the 509 mAFTR. 511 7.2. Processing PIM/MLD Join Messages 513 Upon receipt of the PIM/MLD Join for an IPv6 group (e.g., ffxx:abc:: 514 230.1.2.3), the mAFTR checks the corresponding entry in the IPv6 515 multicast routing table and adds the IPv6 interface through which the 516 Join message has been received into the Out-Interface-List of that 517 entry. If the entry does not exist, a new one will be created, as 518 per typical PIM machinery [RFC4601]. The mAFTR should check whether 519 the IPv6 group address belongs to the mPrefix64 (e.g., ffxx: 520 abc::/96). If so, the mAFTR will need to extract the IPv4 group 521 address (e.g., 230.1.2.3) from the IPv4-embedded IPv6 address (e.g., 522 according to [I-D.boucadair-behave-64-multicast-address-format]) and 523 check the corresponding entry in the IPv4 multicast routing table 524 then add the tunnel interface into the Out-Interface-List of that 525 entry. If the entry does not exist, a new entry should be created 526 and a PIM join message for that IPv4 group will be sent towards the 527 RP or source connected to the IPv4 network. 529 When SSM is deployed, the mAFTR would in addition check if the source 530 (e.g., 2001:db8::192.1.2.3) described in the PIMv6 Join message 531 belongs to uPrefix64 (e.g., 2001:db8::/96). If so, it can then send 532 a PIM (S, G) Join message directly towards the IPv4 source (e.g., 533 192.1.2.3). 535 The initialization of the tunnel interface (used for encapsulation 536 purposes) on the mAFTR is out of the scope of this document. 538 7.3. Reliability 540 For robustness, reliability and load distribution purposes, several 541 nodes in the network can embed the mAFTR function. In such case, the 542 same IPv6 prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to 543 build IPv4-embedded IPv6 addresses MUST be configured on those nodes. 545 7.4. ASM Mode: Building Shared Trees 547 7.4.1. IPv4 Side 549 For a given Rendezvous Point (RP) used in the IPv4 realm, there is no 550 new requirement. Like any other IPv4 PIM router, the RP of each IPv4 551 multicast groups is configured to the mAFTR or discovered using some 552 appropriate means. Moreover, PIM-SM registration procedure [RFC4601] 553 in the IPv4 realm is not impacted. 555 Shared IPv4 multicast trees are built using the procedure defined in 556 [RFC4601] for instance. 558 7.4.2. IPv6 Side 560 In the IPv6 side, the RP of IPv4-embedded IPv6 multicast groups is 561 configured to all IPv6 PIM routers or discovered using appropriate 562 means. For the sake of simplicity, it is RECOMMENDED to configure an 563 mAFTR as the RP for IPv4-embedded IPv6 multicast groups. 565 [Note 1: If some other IPv6 multicast router wants to become the 566 RP of the IPv4-embedded IPv6 multicast groups, it may require an 567 mAFTR to emulate the PIM Source Register procedure on behalf of 568 IPv4-embedded IPv6 sources with the RP. The PIM Source Register 569 procedure in the IPv4 domain is not altered.] 571 [Note 2: How the mAFTR is aware about the sources? This can be 572 considered as deployment-specific: 574 (i) By configuration: mAFTR can be configured to join a set of 575 IPv4 multicast groups and to initiate a registration procedure 576 on behalf of a set of sources to the RP in the v6 domain; 578 (ii) Dynamic: this assumes that mAFTR is configured to join a 579 set of IPv4 multicast groups. The source address of received 580 flows will be used as a trigger to initiate the registration 581 procedure to the RP in the IPv6 domain. There is a special 582 case where mAFTR is the RP of the IPv4 group in the IPv4 583 domain: The registration procedure should then be relayed to 584 the RP in the IPv6 domain. 586 ] 588 Shared IPv6 multicast trees are built using the procedure defined in 589 [RFC4601] for instance. Switching from a shared tree to source-based 590 tree can be accommodated since the mAFTR is in the path to join the 591 source. 593 The mAFTR will graft to the IPv4 shared tree either because it has 594 been configured with the list of IPv4 multicast groups that will be 595 subscribed by the DS-Lite serviced receivers downstream or upon 596 receipt of a PIMv6 Join message. 598 An example of the exchange of PIM messages is illustrated in 599 Figure 3. 601 ------------ 602 / \ 603 | IPv4 network | 604 \ / 605 ------------ 606 : | ^ 607 IPv4 Multicast : | : PIMv4 Join 608 v | : 609 +-------------+ 610 | mAFTR | 611 +-------------+ 612 |:| | ^ 613 IPv6 Multicast |:| | : (PIMv6 Join, PIMv6 Routers in between) 614 (IPv4 embedded) |.| ... . 615 ------------ 616 / \ 617 | IPv6 network | 618 \ / 619 ------------ 620 |:| | : MLD Report 621 |v| | : 622 +-----------+ 623 | mB4 | 624 +-----------+ 625 : | ^ 626 IPv4 Multicast : | : IGMP Report 627 v | : 628 +-----------+ 629 | IPv4 | 630 | Receiver | 631 +-----------+ 633 Figure 3: Procedure Overview 635 7.5. TTL/Scope 637 The Scope field of IPv4-in-IPv6 multicast addresses can be valued to 638 "E" (Global scope) or to "8" (Organization-local scope). This is 639 left to service providers taste. 641 7.6. Encapsulation and forwarding 643 When receiving an IPv4 multicast packet, a lookup of the IPv4 644 multicast routing table is performed by the PIMv4 router that embeds 645 the mAFTR capability. If an interface used for IPv4-in-IPv6 646 encapsulation is found in the Out-Interface-List of the matching 647 entry, the encapsulation operation is triggered. The mAFTR 648 encapsulates in a stateless fashion the IPv4 multicast packet into an 649 IPv6 multicast datagram. It MUST use the pre-provisioned mPrefix64/ 650 uPrefix64 together with an algorithm for building the IPv4-embedded 651 IPv6 multicast address that identifies the multicast group, as well 652 as the IPv6 source address that represents the IPv4 source in the 653 IPv6 network. 655 As an illustration, if a packet is received from source 192.1.2.3 and 656 forwarded to group 230.1.2.3, the mAFTR encapsulates it into an IPv6 657 multicast packet using ffxx:abc::230.1.2.3 as the destination IPv6 658 address and 2001:db8::192.1.2.3 as the multicast source address. 660 Then a lookup of the IPv6 multicast routing table is performed by the 661 PIMv6 router that embeds the mAFTR capability, based on the IPv4- 662 embedded IPv6 address. If a matching entry is found and there exist 663 IPv6 interfaces in the Out-Interface-List, the IPv6 multicast packet 664 will be sent out through these interfaces and forwarded down the 665 multicast distribution tree towards the mB4 devices. 667 8. Optimization in L2 Access Networks 669 The approach specified in this document is compatible with a Layer-2 670 infrastructure which may be involved for deterministic multicast 671 replication. 673 The IPv4-in-IPv6 encapsulated multicast flows destined to IPv4- 674 embedded IPv6 group addresses are treated as any IPv6 multicast flow, 675 and can be replicated across Multicast VLANs. Additionally, 676 mechanisms such as MLD Snooping, MLD Proxying, etc., can be 677 introduced into the distributed Access Network Nodes (e.g., 678 Aggregation Switches, xPON devices) which then could behave as MLD 679 Querier and replicate multicast flows as appropriate. Thus, the 680 multicast replication point is moved downward closer to the 681 receivers, so that bandwidth consumption is optimized. 683 9. Security Considerations 685 This document does not introduce any new security concern in addition 686 to what is discussed in Section 5 of [RFC6052], Section 10 of 688 [RFC3810] and Section 6 of [RFC4601]. 690 9.1. Firewall Configuration 692 The CPE should be configured to accept incoming MLD messages and 693 traffic forwarded to multicast groups subscribed by receivers located 694 in the customer premises. 696 10. Acknowledgements 698 The authors would like to thank Dan Wing for his guidance in the 699 early discussions which initiated this work. We also appreciate Peng 700 Sun, Jie Hu, Qiong Sun, Lizhong Jin, Alain Durand, Dean Cheng, Behcet 701 Sarikaya, Tina Tsou, and Rajiv Asati for their valuable comments. 703 11. IANA Considerations 705 This document includes no request to IANA. 707 12. References 709 12.1. Normative References 711 [I-D.boucadair-behave-64-multicast-address-format] 712 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 713 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", 714 draft-boucadair-behave-64-multicast-address-format-02 715 (work in progress), June 2011. 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 721 Listener Discovery (MLD) for IPv6", RFC 2710, 722 October 1999. 724 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 725 Thyagarajan, "Internet Group Management Protocol, Version 726 3", RFC 3376, October 2002. 728 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 729 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 731 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 732 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 734 Protocol Specification (Revised)", RFC 4601, August 2006. 736 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 737 "Internet Group Management Protocol (IGMP) / Multicast 738 Listener Discovery (MLD)-Based Multicast Forwarding 739 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 741 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 742 IP", RFC 4607, August 2006. 744 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 745 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 746 October 2010. 748 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 749 Algorithm", RFC 6145, April 2011. 751 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 752 Stack Lite Broadband Deployments Following IPv4 753 Exhaustion", RFC 6333, August 2011. 755 12.2. Informative References 757 [I-D.ietf-behave-nat64-learn-analysis] 758 Korhonen, J. and T. Savolainen, "Analysis of solution 759 proposals for hosts to learn NAT64 prefix", 760 draft-ietf-behave-nat64-learn-analysis-00 (work in 761 progress), May 2011. 763 [I-D.ietf-mboned-multiaaa-framework] 764 Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. 765 He, "AAA and Admission Control Framework for 766 Multicasting", draft-ietf-mboned-multiaaa-framework-12 767 (work in progress), August 2010. 769 [I-D.jaclee-behave-v4v6-mcast-ps] 770 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 771 ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use 772 Cases", draft-jaclee-behave-v4v6-mcast-ps-02 (work in 773 progress), June 2011. 775 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 776 2", RFC 2236, November 1997. 778 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 779 IPv6 Specification", RFC 2473, December 1998. 781 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 782 Group Management Protocol Version 3 (IGMPv3) and Multicast 783 Listener Discovery Protocol Version 2 (MLDv2) for Source- 784 Specific Multicast", RFC 4604, August 2006. 786 [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific 787 Protocol Independent Multicast in 232/8", BCP 120, 788 RFC 4608, August 2006. 790 Appendix A. Translation vs. Encapsulation 792 In order to deliver IPv4 multicast flows to DS-Lite serviced 793 receivers, two options can be considered:(1) Translation; 794 (2)Encapsulation. 796 It should be noted that some contract agreement may prevent the 797 contents from being altered. In this case, the employment of the 798 translation approach may raise issues e.g., Integrity Check failures. 800 A.1. Translation 802 To delivery IPv4 multicasst contents to an IPv4 receiver: Introduce 803 translation functions at the boundaries of IPv6 network. The IPv4- 804 translated multicast streams are distributed within the IPv6 network 805 natively until the customer premises device where the IPv4-translated 806 IPv6 streams are translated back and passed to IPv4 receivers. 807 Multicast Distribution Tree is established by normal machinery of 808 control protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking 809 functions (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and 810 Section 7. The translation function is stateless owing to the use of 811 IPv4-Embedded IPv6 address 812 [I-D.boucadair-behave-64-multicast-address-format] and [RFC6052]. 814 A.2. Encapsulation 816 To deliver IPv4 multicast contents to an IPv4 receiver: Introduce two 817 elements at the boundaries of IPv6 network, mAFTR and mB4. Multicast 818 Distribution Tree is established by normal machinery of control 819 protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking functions 820 (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and Section 7. 821 Multicast streams are forwarded to a receiver by using an IPv4-in- 822 IPv6 encapsulation scheme. The encapsulation/de-capsulation function 823 is stateless owing to the use of IPv4-Embedded IPv6 address 824 [I-D.boucadair-behave-64-multicast-address-format] and [RFC6052]. 826 Authors' Addresses 828 Qian Wang 829 China Telecom 830 No.118, Xizhimennei 831 Beijing, 100035 832 China 834 Phone: +86 10 5855 2177 835 Email: wangqian@ctbri.com.cn 837 Jacni Qin 838 ZTE 839 Shanghai, 840 China 842 Phone: +86 1391 8619 913 843 Email: jacni@jacni.com 845 Mohamed Boucadair 846 France Telecom 847 Rennes, 35000 848 France 850 Phone: 851 Email: mohamed.boucadair@orange-ftgroup.com 853 Christian Jacquenet 854 France Telecom 855 Rennes, 35000 856 France 858 Phone: 859 Email: christian.jacquenet@orange-ftgroup.com 861 Yiu L. Lee 862 Comcast 863 U.S.A. 865 Phone: 866 Email: yiu_lee@cable.comcast.com 867 URI: http://www.comcast.com