idnits 2.17.1 draft-qin-softwire-dslite-multicast-04.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 (June 13, 2011) is 4700 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 784, but no explicit reference was found in the text == Unused Reference: 'RFC4608' is defined on line 789, 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 ** 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: December 15, 2011 ZTE 6 M. Boucadair 7 C. Jacquenet 8 France Telecom 9 Y. Lee 10 Comcast 11 June 13, 2011 13 Multicast Extensions to DS-Lite Technique in Broadband Deployments 14 draft-qin-softwire-dslite-multicast-04 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 December 15, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 100 1. Introduction 102 DS-Lite [I-D.ietf-softwire-dual-stack-lite] is a technique to 103 rationalize the use of the remaining IPv4 addresses during the 104 transition period. The current design of DS-Lite covers unicast 105 services exclusively. 107 If customers access IPv4 multicast-based service offerings through a 108 DS-Lite environment, AFTR (Address Family Transition Router) devices 109 have to process all the IGMP reports [RFC2236] [RFC3376] received 110 within IPv4-in-IPv6 tunnels and behave as a replication point for 111 downstream multicast traffic. That is likely to severely affect the 112 multicast traffic forwarding efficiency by losing the benefits of 113 deterministic replication of the data as close to the receivers as 114 possible. As a consequence, the downstream bandwidth will be vastly 115 consumed while the AFTR capability may become rapidly overloaded, in 116 particular if the AFTR capability is deployed in a centralized 117 manner. 119 This document discusses an extension to the DS-Lite model to be used 120 for the delivery of IPv4 multicast-based service offerings. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Terminology 130 This document makes use of the following terms: 132 o IPv4-embedded IPv6 address: is an IPv6 address which embeds a 32 133 bit-encoded IPv4 address. An IPv4-embedded IPv6 address can be 134 unicast or multicast. 136 o mPrefix64: is a dedicated multicast IPv6 prefix for constructing 137 IPv4-embedded IPv6 multicast address 138 [I-D.boucadair-behave-64-multicast-address-format]. mPrefix64 can 139 be of two types: ASM_mPrefix64 used in ASM mode or SSM_mPrefix64 140 used in SSM mode [RFC4607]. 142 o uPrefix64: is a dedicated unicast IPv6 prefix for constructing 143 IPv4-embedded IPv6 unicast address [RFC6052]. 145 o Multicast AFTR (mAFTR for short): is a functional entity which is 146 part of both the IPv4 and IPv6 multicast distribution trees and 147 which replicates IPv4 multicast streams into IPv4-in-IPv6 streams 148 in the relevant branches of the IPv6 multicast distribution tree. 150 o Multicast B4 (mB4 for short): is a functional entity embedded in a 151 CPE, which is able to enforce an IGMP-MLD interworking function ( 152 refer to Section 6.1) together with a de-capsulation function of 153 received multicast IPv4-in-IPv6 packets. 155 3. Context and Scope 157 3.1. IPTV-centric View 159 IPTV generally includes two categories of service offerings: 161 1. VoD (Video on Demand) or Catch-up TV channels streams that are 162 delivered using unicast mode to receivers. 164 2. Live TV Broadcast services that are generally multicast to 165 receivers. 167 Numerous players intervene in the delivery of this service: 169 o Content Providers: the content can be provided by the same 170 provider as the one providing the connectivity service or by 171 distinct providers; 173 o Network Provider: the one providing network connectivity service 174 (e.g., responsible for carrying multicast flows from head-ends to 175 receivers). Refer to [I-D.ietf-mboned-multiaaa-framework]. 177 Many of the current IPTV contents are likely to remain IPv4-formatted 178 and out of control of the network providers. Additionally, there are 179 numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that 180 can't be upgraded or be easily replaced. As a consequence, IPv4 181 service continuity must be guaranteed during the transition period, 182 including the delivery of multicast-based services such as Live TV 183 Broadcasting. The dilemma is the same as in the transition of 184 unicast-based Internet services where the customer premises and 185 global Internet are out of control of the service providers even if 186 they would like to promote the use of IPv6. The DS-Lite design tries 187 to eliminate this issue by decoupling the IPv6 deployments in service 188 provider networks from that in global Internet and in customer 189 devices and applications. 191 DS-Lite can be seen as a catalyst for IPv6 deployment while 192 preserving customer's Quality of Experience (QoE). This is also the 193 design goal of the solution proposed in this document for DS-Lite 194 serviced customers who have subscribed to a multicast-based service 195 offering. 197 3.2. Scope 199 This document focuses only on issues raised by a DS-Lite networking 200 environment: subscription to an IPv4 multicast group and the delivery 201 of IPv4-formatted content to IPv4 receivers. In particular, only the 202 following case is covered: 204 1. An IPv4 receiver accessing IPv4 content (i.e., content formatted 205 and reachable in IPv4) 207 A viable scenario for this use case in DS-Lite environment: Customers 208 with legacy receivers must continue to access the IPv4-enabled 209 multicast services. This means the traffic should be accessed 210 through IPv4 and additional functions are needed to traverse 211 operators' IPv6- enabled network which is the purpose of this 212 document. While since technically, there is no extra function 213 required for the scenario of native access (i.e. to access dual-stack 214 content natively from the IPv6 receiver), this portion is not taken 215 into account. Refer to [I-D.jaclee-behave-v4v6-mcast-ps] for the 216 deployment considerations. 218 This document does not cover the case where an IPv4 host connected to 219 a CPE served by a DS-Lite AFTR can be the source of multicast 220 traffic. 222 Note that some contract agreements prevent a network provider to 223 alter the content as sent by the content provider, in particular for 224 copyright, confidentiality and SLA assurance reasons. The streams 225 should be delivered unaltered to requesting users. 227 4. Solution Overview 229 In the original DS-Lite specification 230 [I-D.ietf-softwire-dual-stack-lite], an IPv4-in-IPv6 tunnel is used 231 to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. 232 This document defines an IPv4-in-IPv6 encapsulation scheme to deliver 233 multicast traffic. Within the context of this document, an IPv4 234 derived IPv6 multicast address is used as the destination of the 235 encapsulated unidirectional IPv4-in-IPv6 multicast traffic from the 236 mAFTR to the mB4. The IPv4 address of the source of the multicast 237 content is represented in the IPv6 realm with an IPv4-embedded IPv6 238 address as well. 240 See following sections for the multicast distribution tree 241 establishment (Section 4.3) and the multicast traffic forwarding 242 (Section 4.4). 244 Note that IPv4-in-IPv6 encapsulated multicast flows are treated in an 245 IPv6 realm like any other IPv6 multicast flow. Upon completion of 246 the establishment of a multicast distribution tree, no extra function 247 is required to be defined to forward IPv4-in-IPv6 multicast traffic 248 in the IPv6 network. 250 4.1. Rationale 252 This document introduces two new functional elements (Figure 1): 254 1. The mAFTR: responsible for replicating IPv4 multicast flows in 255 the IPv6 domain owing to a stateless IPv4-in-IPv6 encapsulation 256 function. The mAFTR does not undertake any NAT operation. The 257 mAFTR is a demarcation point which connects to both the IPv4 and 258 IPv6 multicast networks. 260 2. The mB4: is a functional entity embedded in a CPE responsible for 261 the de-capsulation of the received IPv4-in-IPv6 multicast packets 262 and forwarding them to the appropriate IPv4 receivers. 264 +-----------+ 265 | IPv4 | 266 | Source | 267 +-----------+ 268 | 269 ------------ 270 / \ 271 | IPv4 network | 272 \ / 273 ------------ 274 | 275 +-------------+ 276 | mAFTR | 277 +-------------+ 278 | 279 ------------ 280 / \ 281 | IPv6 network | 282 \ / 283 ------------ 284 | 285 +-----------+ 286 | mB4 | 287 +-----------+ 288 | 289 +-----------+ 290 | IPv4 | 291 | Receiver | 292 +-----------+ 294 Figure 1: Functional Architecture 296 4.2. IPv4-embedded IPv6 Address Prefixes 298 A dedicated IPv6 multicast prefix (mPrefix64) is needed for forming 299 IPv6 multicast addresses, with IPv4 multicast address embedded. The 300 mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used in 301 ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode), and MUST 302 be derived from the corresponding IPv6 multicast address space 303 [I-D.boucadair-behave-64-multicast-address-format]. 305 In addition, the address of the IPv4 multicast source should be 306 mapped to IPv6 addresses in the IPv6 realm: an IPv6 unicast prefix 307 (uPrefix64) is therefore needed for forming IPv6 unicast addresses 308 with IPv4 unicast address embedded. The uPrefix64 MUST be derived 309 from the IPv6 unicast address space [RFC6052]. 311 The mAFTR and mB4 MUST use the same mPrefixe64 and uPrefix64, and the 312 same algorithm for building IPv4-embedded IPv6 addresses. Refer to 313 Section 5 for more details on the IPv6 address format. 315 4.3. Multicast Distribution Tree 317 Assume that an IPv4 receiver sends an IGMP Report towards the mB4 to 318 join a given multicast group. After receiving the IGMP Report 319 message, the mB4 converts the IGMP message into a MLD Report 320 [RFC2710] message which will then be forwarded upstream towards the 321 MLD Querier. The MLD Querier is likely to coexist with the PIM DR 322 where the PIMv6 Join message will be triggered and sent up hop by hop 323 along the PIMv6 routers. Note that the mAFTR is in the path to reach 324 the IPv4 source; this is typically achieved by the underlying unicast 325 IPv6 routing protocol that advertises the unicast IPv4-embedded IPv6 326 addresses: these addresses are used to represent IPv4 sources in the 327 IPv6 multicast domain. 329 Both the MLD and the PIMv6 Join messages convey the IPv6 address of 330 the multicast group to be joined. The corresponding IPv6 multicast 331 group address is constructed by using the pre-configured mPrefix64 332 and an algorithm so that the IPv4 multicast group address is embedded 333 accordingly. 335 When source-specific multicast is deployed, the IPv6 address of the 336 multicast source should be constructed in the same way (using 337 uPrefix64, with IPv4 multicast source embedded). Refer to Section 338 6.1 for more details of the mB4 function. 340 o If the mAFTR is embedded in the MLD Querier/PIMv6 DR, it should 341 process the received MLD Report message for the IPv4-embedded IPv6 342 group and send the corresponding IPv4 PIM Join message. 344 o If the mAFTR is embedded in some upstream PIMv6 router more than 345 one hop away from the mB4, it should process the received PIMv6 346 Join message for the IPv4-embedded IPv6 group and send the 347 corresponding IPv4 PIM Join message. 349 In both cases, an entry for an IPv6 multicast group address is 350 created by the mAFTR in its multicast Routing Information Base and is 351 used to forward multicast IPv4-in-IPv6 datagrams. Refer to Section 352 7.1 for more details about the mAFTR function. 354 A branch of the multicast distribution tree is then established, 355 comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 356 part (between the mB4 and the mAFTR). 358 4.4. Multicast Forwarding 360 Whenever an IPv4 multicast packet is received on a mAFTR (this 361 assumes the RPF Check has passed Section 7.1), it will be 362 encapsulated into an IPv6 packet using the IPv4-embedded IPv6 363 multicast address as the destination address and an IPv4-embedded 364 IPv6 unicast address as the source of the IPv4-in-IPv6 packet. The 365 new IPv6 multicast packet will then be sent through the outgoing 366 interface of the matching entry in the multicast routing table and 367 forwarded down the IPv6 multicast distribution tree towards the mB4. 369 When receiving the packet, the mB4 should de-capsulate it and forward 370 the original IPv4 multicast packet to the appropriate receiver. If 371 mB4 does not have any route to forward the packet (e.g., change of 372 the IPv4 address without cleaning MLD states), the encapsulated IPv4 373 datagram is silently dropped. 375 Note that: There is an alternative to the encapsulation based 376 mechanism (which is detailed in this memo) for Multicast Forwarding: 377 Translation based approach, which is per 378 [I-D.boucadair-behave-64-multicast-address-format], [RFC6052] and 379 [RFC6145]. Refer to Appendix A. 381 4.5. Multicast DS-Lite vs. Unicast DS-Lite 383 Unlike a unicast AFTR, a mAFTR does not perform any NAT for 384 delivering IPv4 multicast traffic. 386 Unlike unicast DS-Lite, a mB4 does not need to discover a mAFTR. 388 mAFTR is responsible for encapsulating in a stateless manner the IPv4 389 multicast traffic into IPv6 datagrams. mB4 is responsible for de- 390 capsulating in a stateless manner the IPv4-in-IPv6 multicast traffic. 391 Further elaboration is provided in the following sections about the 392 behaviour of the mAFTR and the mB4. 394 The corresponding multicast DS-Lite and the unicast DS-Lite 395 functional elements can be co-located in the same device or 396 separated. 398 5. Address Mapping 400 5.1. Prefix Assignment 402 In order to map the addresses of IPv4 multicast traffic with IPv6 403 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 404 unicast prefix (uPrefix64) are provided to mAFTR and mB4 elements. 406 The address format to be used is being left to the responsibility of 407 the service provider as indicated in [RFC6052] and 408 [I-D.boucadair-behave-64-multicast-address-format]. 410 The mPrefix64 and uPrefix64 together with the address format to be 411 used can be configured in the mB4 through a dedicated provisioning 412 protocol, such as DHCPv6 or another protocol. Two candidate DHCPv6 413 options are identified in [I-D.ietf-behave-nat64-learn-analysis]. 415 5.2. Text Representation Examples 417 Group address mapping example when a /96 is used: 419 +----------------------+--------------+-----------------------------+ 420 | mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | 421 +----------------------+--------------+-----------------------------+ 422 | ffxx:abc::/96 | 230.1.2.3 | ffxx:abc::230.1.2.3 | 423 +----------------------+--------------+-----------------------------+ 425 Source address mapping example when a /96 is used: 427 +----------------------+--------------+-----------------------------+ 428 | uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | 429 +----------------------+--------------+-----------------------------+ 430 | 2001:db8::/96 | 192.1.2.3 | 2001:db8::192.1.2.3 | 431 +----------------------+--------------+-----------------------------+ 433 6. Multicast B4 (mB4) 435 6.1. IGMP-MLD Interworking function 437 IGMP-MLD Interworking function combines the IGMP/MLD Proxying 438 function specified in [RFC4605] and the IGMP/MLD adaptation function 439 which is meant to reflect the contents of IGMP messages into MLD 440 messages. 442 Then mB4 performs the router portion of the IGMP protocol on each 443 downstream interface and performs the host portion of the MLD 444 protocol on the upstream interface (Figure 2). 446 The output of the operation is a set of membership information which 447 is maintained separately on each downstream interface (e.g., Wifi and 448 Wired Ethernet). In addition, the membership information on each 449 downstream interface is merged into the membership database on which 450 the IPv4 multicast packets are forwarded by mB4. 452 +----------+ IGMP +-------+ MLD +---------+ 453 | IPv4 |---------| CPE |---------| MLD | 454 | Receiver | | mB4 | | Querier | 455 +----------+ +-------+ +---------+ 457 Figure 2: IGMP-MLD Interworking 459 When an IGMP Report message is received from a receiver to subscribe 460 to a given multicast group G (e.g., 230.1.2.3) (and optionally 461 associated to a source 192.1.2.3 if SSM mode is used), the mB4 MUST 462 send an MLD Report message to subscribe to the corresponding IPv6 463 group identified by an IPv4-embedded IPv6 multicast address using a 464 pre-configured prefix and algorithm (e.g., ffxx:abc::230.1.2.3 (and 465 optionally source 2001:db8::192.1.2.3 if SSM mode is used)). The MLD 466 Report message is sent through the upstream interface natively (i.e., 467 without any encapsulation). 469 6.2. De-capsulation and Forwarding 471 When the mB4 receives an IPv6 multicast packet, it checks whether the 472 group address is in the range of mPrefix64 and the source address is 473 in the range of uPrefix64. If it is true, the mB4 MUST de-capsulate 474 the IPv4-in-IPv6 packets to extract the original IPv4 multicast 475 packets. 477 Then the IPv4 multicast packet will be forwarded to downstream 478 receivers based on information maintained by the mB4 in the 479 membership database. If no route is found, the packet is silently 480 dropped. 482 6.3. Fragmentation 484 Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding 485 reduces the effective MTU size by the size of an IPv6 header 486 (assuming [RFC2473] encapsulation). To avoid fragmentation, a 487 service provider may increase the MTU size by 40 bytes on the IPv6 488 network or mAFTR and mB4 may use IPv6 Path MTU discovery. 490 6.4. Host with mB4 function embedded 492 The mB4 function can be embedded in the CE or in a dual-stack host 493 behind the CP router (e.g., STB). If mB4 is embedded in the STB, the 494 IGMP-MLD interworking function is not needed. The STB should 495 formulate the MLD message correspondingly based on given IPv4 group 496 address to be joint using mPrefix64 (and uPrefix64 for IPv4-embedded 497 source if SSM is deployed), and de-encapsulate the downstream 498 multicast traffics received by itself. 500 7. Multicast AFTR (mAFTR) 502 7.1. Routing Considerations 504 Except the need for the mAFTR to belong to IPv4 multicast 505 distribution trees and to be on the reverse path towards the source 506 when performing RPF checks on PIMv6 routers, no further routing 507 constraint is to be taken into account. 509 Having the mAFTR in the reverse path ensures PIM Join sent to the 510 source (e.g., SSM mode or SPT mode in ASM) will be intercepted by the 511 mAFTR. 513 7.2. Processing PIM/MLD Join Messages 515 Upon receipt of the PIM/MLD Join for an IPv6 group (e.g., ffxx:abc:: 516 230.1.2.3), the mAFTR checks the corresponding entry in the IPv6 517 multicast routing table and adds the IPv6 interface through which the 518 Join message has been received into the Out-Interface-List of that 519 entry. If the entry does not exist, a new one will be created, as 520 per typical PIM machinery [RFC4601]. The mAFTR should check whether 521 the IPv6 group address belongs to the mPrefix64 (e.g., ffxx: 522 abc::/96). If so, the mAFTR will need to extract the IPv4 group 523 address (e.g., 230.1.2.3) from the IPv4-embedded IPv6 address (e.g., 524 according to [I-D.boucadair-behave-64-multicast-address-format]) and 525 check the corresponding entry in the IPv4 multicast routing table 526 then add the tunnel interface into the Out-Interface-List of that 527 entry. If the entry does not exist, a new entry should be created 528 and a PIM join message for that IPv4 group will be sent towards the 529 RP or source connected to the IPv4 network. 531 When SSM is deployed, the mAFTR would in addition check if the source 532 (e.g., 2001:db8::192.1.2.3) described in the PIMv6 Join message 533 belongs to uPrefix64 (e.g., 2001:db8::/96). If so, it can then send 534 a PIM (S, G) Join message directly towards the IPv4 source (e.g., 535 192.1.2.3). 537 The initialization of the tunnel interface (used for encapsulation 538 purposes) on the mAFTR is out of the scope of this document. 540 7.3. Reliability 542 For robustness, reliability and load distribution purposes, several 543 nodes in the network can embed the mAFTR function. In such case, the 544 same IPv6 prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to 545 build IPv4-embedded IPv6 addresses MUST be configured on those nodes. 547 7.4. ASM Mode: Building Shared Trees 549 7.4.1. IPv4 Side 551 For a given Rendezvous Point (RP) used in the IPv4 realm, there is no 552 new requirement. Like any other IPv4 PIM router, the RP of each IPv4 553 multicast groups is configured to the mAFTR or discovered using some 554 appropriate means. Moreover, PIM-SM registration procedure [RFC4601] 555 in the IPv4 realm is not impacted. 557 Shared IPv4 multicast trees are built using the procedure defined in 558 [RFC4601] for instance. 560 7.4.2. IPv6 Side 562 In the IPv6 side, the RP of IPv4-embedded IPv6 multicast groups is 563 configured to all IPv6 PIM routers or discovered using appropriate 564 means. For the sake of simplicity, it is RECOMMENDED to configure an 565 mAFTR as the RP for IPv4-embedded IPv6 multicast groups. 567 [Note 1: If some other IPv6 multicast router wants to become the 568 RP of the IPv4-embedded IPv6 multicast groups, it may require an 569 mAFTR to emulate the PIM Source Register procedure on behalf of 570 IPv4-embedded IPv6 sources with the RP. The PIM Source Register 571 procedure in the IPv4 domain is not altered.] 573 [Note 2: How the mAFTR is aware about the sources? This can be 574 considered as deployment-specific: 576 (i) By configuration: mAFTR can be configured to join a set of 577 IPv4 multicast groups and to initiate a registration procedure 578 on behalf of a set of sources to the RP in the v6 domain; 580 (ii) Dynamic: this assumes that mAFTR is configured to join a 581 set of IPv4 multicast groups. The source address of received 582 flows will be used as a trigger to initiate the registration 583 procedure to the RP in the IPv6 domain. There is a special 584 case where mAFTR is the RP of the IPv4 group in the IPv4 585 domain: The registration procedure should then be relayed to 586 the RP in the IPv6 domain. 588 ] 590 Shared IPv6 multicast trees are built using the procedure defined in 591 [RFC4601] for instance. Switching from a shared tree to source-based 592 tree can be accommodated since the mAFTR is in the path to join the 593 source. 595 The mAFTR will graft to the IPv4 shared tree either because it has 596 been configured with the list of IPv4 multicast groups that will be 597 subscribed by the DS-Lite serviced receivers downstream or upon 598 receipt of a PIMv6 Join message. 600 An example of the exchange of PIM messages is illustrated in 601 Figure 3. 603 ------------ 604 / \ 605 | IPv4 network | 606 \ / 607 ------------ 608 : | ^ 609 IPv4 Multicast : | : PIMv4 Join 610 v | : 611 +-------------+ 612 | mAFTR | 613 +-------------+ 614 |:| | ^ 615 IPv6 Multicast |:| | : (PIMv6 Join, PIMv6 Routers in between) 616 (IPv4 embedded) |.| ... . 617 ------------ 618 / \ 619 | IPv6 network | 620 \ / 621 ------------ 622 |:| | : MLD Report 623 |v| | : 624 +-----------+ 625 | mB4 | 626 +-----------+ 627 : | ^ 628 IPv4 Multicast : | : IGMP Report 629 v | : 630 +-----------+ 631 | IPv4 | 632 | Receiver | 633 +-----------+ 635 Figure 3: Procedure Overview 637 7.5. TTL/Scope 639 The Scope field of IPv4-in-IPv6 multicast addresses can be valued to 640 "E" (Global scope) or to "8" (Organization-local scope). This is 641 left to service providers taste. 643 7.6. Encapsulation and forwarding 645 When receiving an IPv4 multicast packet, a lookup of the IPv4 646 multicast routing table is performed by the PIMv4 router that embeds 647 the mAFTR capability. If an interface used for IPv4-in-IPv6 648 encapsulation is found in the Out-Interface-List of the matching 649 entry, the encapsulation operation is triggered. The mAFTR 650 encapsulates in a stateless fashion the IPv4 multicast packet into an 651 IPv6 multicast datagram. It MUST use the pre-provisioned mPrefix64/ 652 uPrefix64 together with an algorithm for building the IPv4-embedded 653 IPv6 multicast address that identifies the multicast group, as well 654 as the IPv6 source address that represents the IPv4 source in the 655 IPv6 network. 657 As an illustration, if a packet is received from source 192.1.2.3 and 658 forwarded to group 230.1.2.3, the mAFTR encapsulates it into an IPv6 659 multicast packet using ffxx:abc::230.1.2.3 as the destination IPv6 660 address and 2001:db8::192.1.2.3 as the multicast source address. 662 Then a lookup of the IPv6 multicast routing table is performed by the 663 PIMv6 router that embeds the mAFTR capability, based on the IPv4- 664 embedded IPv6 address. If a matching entry is found and there exist 665 IPv6 interfaces in the Out-Interface-List, the IPv6 multicast packet 666 will be sent out through these interfaces and forwarded down the 667 multicast distribution tree towards the mB4 devices. 669 8. Optimization in L2 Access Networks 671 The approach specified in this document is compatible with a Layer-2 672 infrastructure which may be involved for deterministic multicast 673 replication. 675 The IPv4-in-IPv6 encapsulated multicast flows destined to IPv4- 676 embedded IPv6 group addresses are treated as any IPv6 multicast flow, 677 and can be replicated across Multicast VLANs. Additionally, 678 mechanisms such as MLD Snooping, MLD Proxying, etc., can be 679 introduced into the distributed Access Network Nodes (e.g., 680 Aggregation Switches, xPON devices) which then could behave as MLD 681 Querier and replicate multicast flows as appropriate. Thus, the 682 multicast replication point is moved downward closer to the 683 receivers, so that bandwidth consumption is optimized. 685 9. Security Considerations 687 This document does not introduce any new security concern in addition 688 to what is discussed in Section 5 of [RFC6052], Section 10 of 690 [RFC3810] and Section 6 of [RFC4601]. 692 9.1. Firewall Configuration 694 The CPE should be configured to accept incoming MLD messages and 695 traffic forwarded to multicast groups subscribed by receivers located 696 in the customer premises. 698 10. Acknowledgements 700 The authors would like to thank Dan Wing for his guidance in the 701 early discussions which initiated this work. We also appreciate Peng 702 Sun, Jie Hu, Qiong Sun, Lizhong Jin, Alain Durand, Dean Cheng, and 703 Behcet Sarikaya for their valuable comments. 705 11. IANA Considerations 707 This document includes no request to IANA. 709 12. References 711 12.1. Normative References 713 [I-D.boucadair-behave-64-multicast-address-format] 714 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 715 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", 716 draft-boucadair-behave-64-multicast-address-format-01 717 (work in progress), February 2011. 719 [I-D.ietf-softwire-dual-stack-lite] 720 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 721 Stack Lite Broadband Deployments Following IPv4 722 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 723 in progress), May 2011. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, March 1997. 728 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 729 Listener Discovery (MLD) for IPv6", RFC 2710, 730 October 1999. 732 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 733 Thyagarajan, "Internet Group Management Protocol, Version 734 3", RFC 3376, October 2002. 736 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 737 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 739 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 740 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 741 Protocol Specification (Revised)", RFC 4601, August 2006. 743 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 744 "Internet Group Management Protocol (IGMP) / Multicast 745 Listener Discovery (MLD)-Based Multicast Forwarding 746 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 748 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 749 IP", RFC 4607, August 2006. 751 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 752 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 753 October 2010. 755 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 756 Algorithm", RFC 6145, April 2011. 758 12.2. Informative References 760 [I-D.ietf-behave-nat64-learn-analysis] 761 Korhonen, J. and T. Savolainen, "Analysis of solution 762 proposals for hosts to learn NAT64 prefix", 763 draft-ietf-behave-nat64-learn-analysis-00 (work in 764 progress), May 2011. 766 [I-D.ietf-mboned-multiaaa-framework] 767 Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. 768 He, "AAA and Admission Control Framework for 769 Multicasting", draft-ietf-mboned-multiaaa-framework-12 770 (work in progress), August 2010. 772 [I-D.jaclee-behave-v4v6-mcast-ps] 773 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 774 ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use 775 Cases", draft-jaclee-behave-v4v6-mcast-ps-02 (work in 776 progress), June 2011. 778 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 779 2", RFC 2236, November 1997. 781 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 782 IPv6 Specification", RFC 2473, December 1998. 784 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 785 Group Management Protocol Version 3 (IGMPv3) and Multicast 786 Listener Discovery Protocol Version 2 (MLDv2) for Source- 787 Specific Multicast", RFC 4604, August 2006. 789 [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific 790 Protocol Independent Multicast in 232/8", BCP 120, 791 RFC 4608, August 2006. 793 Appendix A. Translation vs. Encapsulation 795 In order to deliver IPv4 multicast flows to DS-Lite serviced 796 receivers, two options can be considered:(1) Translation; 797 (2)Encapsulation. 799 It should be noted that some contract agreement may prevent the 800 contents from being altered. In this case, the employment of the 801 translation approach may raise issues e.g., Integrity Check failures. 803 A.1. Translation 805 To delivery IPv4 multicasst contents to an IPv4 receiver: Introduce 806 translation functions at the boundaries of IPv6 network. The IPv4- 807 translated multicast streams are distributed within the IPv6 network 808 natively until the customer premises device where the IPv4-translated 809 IPv6 streams are translated back and passed to IPv4 receivers. 810 Multicast Distribution Tree is established by normal machinery of 811 control protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking 812 functions (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and 813 Section 7. The translation function is stateless owing to the use of 814 IPv4-Embedded IPv6 address 815 [I-D.boucadair-behave-64-multicast-address-format] and [RFC6052]. 817 A.2. Encapsulation 819 To deliver IPv4 multicast contents to an IPv4 receiver: Introduce two 820 elements at the boundaries of IPv6 network, mAFTR and mB4. Multicast 821 Distribution Tree is established by normal machinery of control 822 protocols (e.g. IGMP, MLD, PIMv4/v6) and the Interworking functions 823 (e.g. IGMP-MLD, PIMv6-PIMv4), refer to Section 6 and Section 7. 824 Multicast streams are forwarded to a receiver by using an IPv4-in- 825 IPv6 encapsulation scheme. The encapsulation/de-capsulation function 826 is stateless owing to the use of IPv4-Embedded IPv6 address 827 [I-D.boucadair-behave-64-multicast-address-format] and [RFC6052]. 829 Authors' Addresses 831 Qian Wang 832 China Telecom 833 No.118, Xizhimennei 834 Beijing, 100035 835 China 837 Phone: +86 10 5855 2177 838 Email: wangqian@ctbri.com.cn 840 Jacni Qin 841 ZTE 842 Shanghai, 843 China 845 Phone: +86 1391 8619 913 846 Email: jacniq@gmail.com 848 Mohamed Boucadair 849 France Telecom 850 Rennes, 35000 851 France 853 Phone: 854 Email: mohamed.boucadair@orange-ftgroup.com 856 Christian Jacquenet 857 France Telecom 858 Rennes, 35000 859 France 861 Phone: 862 Email: christian.jacquenet@orange-ftgroup.com 864 Yiu L. Lee 865 Comcast 866 U.S.A. 868 Phone: 869 Email: yiu_lee@cable.comcast.com 870 URI: http://www.comcast.com