idnits 2.17.1 draft-sarikaya-softwire-6rdmulticast-06.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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2013) is 3873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-mboned-auto-multicast' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC2491' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC4286' is defined on line 567, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-softwire-dslite-multicast-05 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Sarikaya 3 Internet-Draft T. Tsou 4 Intended status: Informational Huawei Technologies (USA) 5 Expires: March 15, 2014 H. Ji 6 China Telecom 7 C. Zhou 8 Huawei Technologies 9 September 11, 2013 11 IPv6 Multicast in a 6rd Deployment 12 draft-sarikaya-softwire-6rdmulticast-06 14 Abstract 16 This memo specifies 6rd's multicast component so that IPv6 hosts can 17 receive multicast data from IPv6 servers. In the 6rd encapsulation 18 solution, multicast communication is completely integrated into the 19 6rd tunnel. In the 6rd translation solution, the protocol is based 20 on proxying MLD at the 6rd Customer Edge router interworking the MLD 21 messages to IGMP messages and sending them upstream through a network 22 which supports IPv4 multicast. The 6rd Border Relay is a multicast 23 router and interworks the IGMP to MLD for onward propasgation toward 24 the IPv6 multicast source. IPv6 Multicast data received at 6rd 25 Border Relay is translated into IPv4 multicast data and and delivered 26 through the IPv4 multicast tree downstream to the 6rd Customer Edge. 27 The latter translates it back to IPv6 multicast data then delivers it 28 to the hosts. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 15, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. 6rd Tunneling Architecture . . . . . . . . . . . . . . . 4 68 4.2. Translation Architecture . . . . . . . . . . . . . . . . 5 69 5. 6rd Tunneling Multicast Operation . . . . . . . . . . . . . . 6 70 5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 7 71 5.2. Avalanche Problem . . . . . . . . . . . . . . . . . . . . 8 72 6. 6rd Translation Multicast Operation . . . . . . . . . . . . . 8 73 6.1. Solution Based on Layer 2 Multicast Support . . . . . . . 10 74 6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 10.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 With IPv4 address depletion on the horizon, many techniques are being 86 standardized for IPv6 migration including 6rd [RFC5969]. 6rd enables 87 IPv6 hosts to communicate with external hosts using an IPv4-only 88 legacy ISP network. The 6rd Customer Edge (CE) device's LAN side is 89 dual stack and the WAN side is IPv4 only. The CE tunnels IPv6 90 packets received from the LAN side to 6rd Border Relays (BR) after 91 encapsulating them as IPv4 packets. The BRs have anycast IPv4 92 addresses and receive encapsulated packets from CEs over a virtual 93 interface. 6rd operation is stateless. Packets are received/ sent 94 independently of each other and no state needs to be maintained. 96 It should be noted that there is no depletion problem for IPv4 97 address space allocated for any source multicast and source specific 98 multicast [RFC3171]. This document is not motivated by the depletion 99 of IPv4 multicast addresses. 101 6rd as defined in [RFC5969] and [RFC5569] is unicast only. It does 102 not support multicast. In this document we specify how multicast 103 from home IPv6 users can be supported in 6rd. This is what is meant 104 by 6rd multicast protocol. 106 In the 6rd encapsulation approach, 6rd multicast is integrated into 107 the 6rd unicast solution. 6rd customer premise equipment (CPE) is 108 extended to support an MLD proxy [RFC4605]. This proxy receives MLD 109 Membership Report messages [RFC4601] requesting to join a multicast 110 group from its subtended hosts. It tunnels aggregated join requests 111 upstream to the 6rd Border Router (BR) using IPv6 in IPv4 112 encapsulation. The 6rd Border Router is extended to support an MLD 113 querier, which sends join requests upstream towards the multicast 114 source(s, becomes part of the multicast tree, and thus receives IPv6 115 multicast data. The 6rd Border Router encapsulates the IPv6 116 multicast data using 6rd's IPv6 in IPv4 encapsulation and sends it to 117 each member CPE that has joined the stream concerned. The CPE 118 decapsulates the packet and the MLD proxy sends the IPv6 multicast 119 data downstream to the member hosts. 121 In the translation approach, native IPv4 multicast support in the 122 network between Customer Edge routers and Border Router can be 123 exploited. The translation approach requires MLD to IGMP 124 interworking at the Customer Edge and IGMP to MLD interworking at the 125 border router. The border router needs to translate IPv6 multicast 126 data into IPv4 multicast data and the Customer Edge router needs to 127 translate IPv4 multicast data back into IPv6 multicast data. 129 6rd's CE to CE forwarding feature is not used in either approach. 131 2. Terminology 133 This document uses the terminology defined in [RFC5969], [RFC5569], 134 [RFC3810], [RFC3376], and [I-D.ietf-softwire-dslite-multicast]. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 3. Requirements 142 This section states requirements on 6rd multicast support protocol. 144 IPv6 hosts connected to 6rd CE router MUST be able to join multicast 145 groups in IPv6 and receive multicast data. 147 Both any source multicast (ASM) and source specific multicast (SSM) 148 MUST be supported. 150 6rd multicast MUST NOT introduce the need to use more IPv4 addresses, 151 thereby contributing to public IPv4 address depletion. 153 4. Architecture 155 In 6rd, IPv6 or IPv4/IPv6 dual stack hosts are served by the 6rd 156 Customer Edge device (CE). The CE is dual stack facing the hosts and 157 IPv4 only facing the network or WAN side. The CE tunnels IPv6 158 packets in IPv4 to the 6rd Border Relay (BR). The BR decapsulates 159 the tunneled packets and forwards them to the IPv6 network. In the 160 reverse direction, the BR receives IPv6 packets from the IPv6 network 161 tunnels them in IPv4 to the CE. The CE decapsulates the IPv6 packets 162 and forwards them to the hosts. 164 Unicast 6rd is stateless. Each IPv6 packet sent by the CE is treated 165 separately and different packets from the same CE may go to different 166 BRs. The CE encapsulates IPv6 packets in IPv4 with the IPv4 167 destination address set to the BR address (usually an anycast IPv4 168 address). BRs are placed where IPv6 native connectivity exists to 169 other networks. A CE is configured with its own IPv4 address (public 170 or private), with a 6rd IPv6 prefix from which the CE's IPv4 address 171 can be derived, and with one or more BR IPv4 addresses. When the BR 172 receives IPv6 packets addressed to the CE, it extracts the CE's IPv4 173 address from the destination IPv6 address and uses this address as 174 the destination address for the IPv4 encapsulation of the IPv6 175 packet. 6rd views the IPv4-only network as an NBMA link from the 176 IPv6 point of view and all 6rd CEs and BRs are defined as off-link 177 neighbors from one other. 179 4.1. 6rd Tunneling Architecture 181 In order to support multicast, the CE implements an MLD Proxy 182 function [RFC4605]. IPv6 hosts send their join requests (MLD 183 Membership Report messages) to CE. The CE as a proxy sends 184 aggregated Report messages upstream towards BR in unicast using IPv6 185 in IPv4 encapsulation. 187 Dual Stack Hosts IPv4 188 +----+ Network 189 | H1 | IPv4 190 +----+ +-----+ only +-------+ + 191 +----+ | CE | network -- | BR | 192 | H2 | ---| MLD |--- IPv6 | MLD | IPv6 193 +----+ |Proxy| in |Querier| Network 194 +----+ +-----+ IPv4 +-------+ 195 | H3 | Encapsulation 196 +----+ 198 Figure 1: Architecture of 6rd Tunneling Multicast Protocol 200 The BR is the default multicast querier for the CE. The BR 201 implements a multicast router function or it could be another MLD 202 proxy. 204 All the elements of 6rd multicast support system are shown in Figure 205 1. 207 4.2. Translation Architecture 209 In order to support multicast, CE implements MLD Proxy [RFC4605] and 210 MLD to IGMP interworking function 211 [ID.perreault-igmp-mld-translation]. IPv6 hosts send their join 212 requests (MLD Membership Report messages) to CE. CE as a proxy sends 213 aggregated IGMP Report messages upstream towards BR. 215 In order to support SSM, MLDv2 [RFC3810] and IGMPv3 [RFC3376] must be 216 supported by the CE and BR, and MLDv2 must be supported by the host. 218 The BR is the default multicast querier for the CE. The BR 219 implements an IGMP to MLD interworking function and multicast router 220 function or it could be another MLD proxy. 222 It is assumed that the IPv4 only network to which the CE and the BR 223 are connected supports native IPv4 multicast. 225 All the elements of 6rd translation-based multicast support system 226 are shown in Figure 2. 228 Dual Stack Hosts IPv4 229 +----+ Network 230 | H1 | IPv4 231 +----+ +----------------+ only +------------------+ 232 +----+ | CE MLD | network |IGMP BR | + 233 | H2 | ---| MLD IGMP |-----------| MLD MLD | 234 +----+ |Proxy Translator| |Translator Querier| 235 +----+ +----------------+ +------------------+ 236 | H3 | IPv6 237 +----+ Network 239 Figure 2: Architecture of 6rd Translation-Based Multicast 241 5. 6rd Tunneling Multicast Operation 243 In this section we specify how the host can subscribe and receive 244 IPv6 multicast data from IPv6 content providers based on the 245 architecture defined in Figure 1. 247 The hosts will send their subscription requests for IPv6 multicast 248 groups upstream to the default router, i.e., Costumer Edge device. 249 After subscribing the group, the host can receive multicast data from 250 the CE. The host implements MLD protocol's host part. 252 The Customer Edge device is an MLD Proxy. After receiving the first 253 MLD Report message requesting subscription to an IPv6 multicast 254 group, the CE establishes a tunnel interface with a Border Relay. 255 The tunnel is IPv4 based but it will carry MLD messages back and 256 forth and IPv6 multicast data messages downstream. 258 The CE is a regular MLD proxy and it keeps an MLD proxy membership 259 database. The CE inserts multicast forwarding state on the incoming 260 interface, and merges state updates into the MLD proxy membership 261 database. The CE updates or remove elements from the database as 262 required. The CE will then send an aggregated Report via the 263 upstream tunnel to the BR when the membership database changes. 265 The CE answers MLD queries from the BR based on the membership 266 database. The CE's downstream link follows the traditional 267 multipoint channel forwarding and does not pose any specific 268 problems. 270 The CE receives IPv6 multicast data from the BR tunneled over the 271 tunnel interface. The CE decapsulates the packet and then forwards 272 it downstream. Each member host receives the data packet based on 273 the Layer 2 multicast interface. No packet duplication is necessary. 275 The Border Relay acts as the default multicast querier for all CEs 276 that have established an IPv4 tunnel with it. In order to keep a 277 consistent multicast state between a CE and BR, once a CE is 278 connected it will stay connected until the state becomes empty. 279 After that point, the CE may establish another tunnel to a different 280 BR. 282 According to aggregated MLD reports received from subtending CEs, the 283 BR establishes group/source-specific multicast forwarding states at 284 its corresponding downstream tunnel interfaces. After that, the BR 285 maintains or removes the state as required by the aggregated reports 286 received from CEs. 288 At the upstream interface, the BR procures for aggregated multicast 289 membership maintenance. Based on the multicast-transparent 290 operations of the CEs, the BR treats its tunnel interfaces as 291 multicast enabled downstream links, serving zero to many listening 292 nodes. 294 When the BR receives MLD join requests from downstream CEs, the BR 295 sends PIM join messages upstream towards multicast source(s). This 296 results in a multicast tree formation where the BR is at the leaf of 297 the multicast tree, enabling the BR to receive IPv6 multicast data 298 sent by the source. 300 Multicast traffic arriving at the BR is transparently forwarded 301 according to its multicast forwarding information base. Multicast 302 data is first replicated according to MLD multicast group state and 303 then forwarded in IPv6-in-IPv4 tunnels from the BR to the 304 corresponding CEs. 306 5.1. Tunnel Interface Considerations 308 IPv6 in IPv4 tunneling is performed as specified in [RFC4213]. 309 Considerations specified in [RFC5969] apply. Packets passing 310 upstream from the CE carry only MLD signaling messages and they are 311 not expected to be fragmented. However packets downstream, i.e., 312 multicast data to the CEs, may be subject to fragmentation. 314 Source and destination addresses of MLD messages in IPv6-in-IPv4 315 tunnel from CE are as follows: 317 o The source address of IPv4 header is the CE WAN interface IPv4 318 address. The destination address is the BR anycast address when 319 an invite message is sent to group G. Subsequent messages to group 320 G contain the BR unicast address as destination address. 322 o The source address of the inner MLD message is the link local 323 address. The destination address is all MLDv2-capable multicast 324 routers or FF02::16 for MLD Version 2 Multicast Listener Reports. 326 The source and destination addresses of MLD messages in the IPv6- in- 327 IPv4 softwire from BR are as follows: 329 o The source address of the IPv4 header is the BR IPv4 unicast 330 address. The destination address is the CE IPv4 address. This 331 also holds for multicast data. 333 o The source address of the inner MLD message is the link local 334 address. The destination address is the link-scope all-nodes 335 multicast address (FF02::1) for General Queries, or the IPv6 336 multicast group address for specific queries. 338 The source address of IPv6 multicast data is the unicast IPv6 address 339 of the multicast source, e.g., the content provider. The destination 340 address is the3 IPv6 multicast group address. 342 5.2. Avalanche Problem 344 In Section 5.1, multicast data is replicated to all interfaces, i.e., 345 to all member CEs at the BR. This replication (often called 346 avalanche problem) can be very costly if is a very large number of 347 downstream member CEs such as in the IPTV application. See 348 Appendix A in [I-D.ietf-softwire-dslite-multicast]. 350 In 6rd tunneling multicast, the avalanche problem can be reduced by 351 careful network partitioning. More BRs can be deployed in areas 352 where IPv6 users are increasing in numbers. Deploying BRs by 353 collocating them with the access network gateway as with the Border 354 Network Gateway (BNG) is another possibility. 356 In the 6rd tunneling multicast operation, CEs are enabled to exploit 357 multiple BRs that can be deployed in the network by using the BR 358 anycast address any time they send an upstream MLD join request and 359 then using the same BR that received the join message in subsequent 360 MLD messages by using the same BR's unicast address. 362 6. 6rd Translation Multicast Operation 364 In this section we specify how the host can subscribe and receive 365 IPv6 multicast data from IPv6 content providers based on the 366 architecture defined in Figure 2. 368 The hosts will send their subscription requests for IPv6 multicast 369 groups upstream to the default router, i.e., the Costumer Edge 370 device. After subscribing the group, the host can receive multicast 371 data from the CE. The host implements the MLD protocol's host part. 373 The Customer Edge device is an MLD Proxy. After receiving the first 374 MLD Report message requesting subscription to an IPv6 multicast 375 group, the CE interworks the MLD Membership Report message to an IGMP 376 Membership report message. It sends it upstream only if joining a 377 new group is needed. 379 Address translation in generating an IGMP Membership report message 380 is done as follows: the destination address is copied from the last 381 32 bits of IPv6 multicast group address. The CE inserts the IPv4 382 address of its WAN interface into the source address. It is assumed 383 that the IPv6 multicast group address in MLD Report message conforms 384 to the addressing scheme described in 385 [I-D.ietf-mboned-64-multicast-address-format], for any-source and 386 source-specific multicast address formats. 388 Source addresses in the MLDv2 payload are translated as follows. 389 Multicast source addresses in MLD Membership Report message MUST use 390 uPrefix64, i.e. 64:ff9b::/96 defined in [RFC6052]. uPrefix64 391 facilitates translation into an IPv4 source address to be used in 392 IGMPv3 Membership Report messages for source-specific multicast, 393 i.e., by extracting the last 32 bits of IPv6 source address. 395 The IGMP Report message is received by the IGMP Querier/Proxy 396 upstream on the link. (Normally this node is the Broadband Network 397 Gateway, BNG in broadband networks.) The IGMP Querier/Proxy sends 398 IGMPv3 Report message to the neighboring routers to join the group. 399 In networks where PIM is supported, the IGMP Report message may be 400 received by the PIM Designated Router. The PIM router sends a PIMv4 401 join message to join an IPv4 group. 403 The border router that receives the join message translates the 404 message into MLD. To join an IPv6 group for any-source multicast, 405 the IPv6 Multicast group address is obtained from the destination 406 address. For source-specific multicast, the IPv6 source address is 407 generated after obtaining the IPv4 source address of Membership 408 Report message's Group Record Source Address field. The BR sends the 409 PIMv6 join message upstream towards the source. 411 The BR MUST act as the designated router to which the source of the 412 source-specific IGMP join message is connected. The BR MUST act as 413 the rendez-vous point (RP) of the multicast group for the any-source 414 multicast IGMP join message. Normally there is one such BR in an 415 operator's network. An IPv4 multicast tree eventually forms in the 416 network between the CE and BR and an IPv6 multicast tree upstream 417 from the BR for the same ASM or SSM group. 419 IPv6 multicast data received at the border router from the source is 420 translated into IPv4. The last 32 bits of the source and destination 421 address fields determine the source and destination addresses of the 422 IPv4 multicast data packet. This packet is sent downstream on the 423 multicast tree already formed for this IPv4 multicast group. 425 Multicast data packet address translation follows the rules in 426 [I-D.ietf-mboned-64-multicast-address-format] for the multicast group 427 address and [RFC6052] for source- specific multicast source address, 428 i.e. using uPrefix64. For any- source multicast, the Border Router 429 inserts an IPv4 source address, different for each source. 431 Packet header translation follows the rules in [RFC6145]. 432 Fragmentation and reassembly are handled as described in [RFC6145]. 433 After the IPv4 multicast data packet is sent downstream from the BR 434 it may be fragmented by the routers. 436 The CE receives the IPv4 multicast data packet, possibly in 437 fragments, and reassembles the fragments. The CE translates the IPv4 438 multicast data packet back to an IPv6 multicast data packet. Address 439 translation is done following 440 [I-D.ietf-mboned-64-multicast-address-format] for multicast group 441 addresses and [RFC6052] for unicast SSM source addresses. Header 442 translation is done as in [RFC6145]. 444 IPv6 multicast data is sent on the home link to the host(s). IEEE 445 802.3 or IEEE 802.11 multicast link support usually handles this 446 delivery in Layer 2 without any packet duplication if there are more 447 than one members to the any-source multicast group or SSM source and 448 multicast group. 450 6.1. Solution Based on Layer 2 Multicast Support 452 In this section we assume that Layer 2 multicast is supported in the 453 network. Layer 2 multicast support is done in order to forward 454 multicast data downstream to the ports of Layer 2 devices, i.e. 455 switches that requested a multicast group instead of flooding the 456 data to all the ports. 458 In the switches, called snooping switches, multicast MAC address 459 based filters are set up which link layer 2 multicast groups to the 460 egress ports. IGMP snooping switches are commonly used in operators' 461 networks, most commonly at the access nodes (AN) [RFC6788]. 463 When an IGMP Report message is received, the bridge will set up a 464 multicast filter entry that allows (in case of a join message) or 465 prevents (in case of a leave message) packets to flow on the port on 466 which the IGMP Report message was received. In terms of IPv4 467 multicast addresses, the mapping is not unique as 32 IPv4 multicast 468 addresses map to a single Ethernet multicast MAC address [RFC4541]. 470 The main functionality of a snooping switch is to forward multicast 471 data packets based on the filters that are setup, i.e. to those 472 egress ports with multicast groups downstream and also to the router 473 ports. 475 In a 6rd network the snooping switches must detect IGMP packets sent 476 upstream by the CE and set the filtering rules accordingly. When 477 IPv4 data packets are received the IGMP snooping switches forward 478 these packets towards all CEs that have members, effectively 479 achieving packet duplication at the access node level. 481 6.2. Analysis 483 An analysis of the translation solution reveals the following:\ 485 o The translation solution imposes a requirement on the IPv6 source- 486 specific multicast sources to use uPrefix64 compatible source 487 addresses. This requirement cannot be satified with simple 488 configuration of the CPE router and Border Router. 490 o In the case of any-source multicast, the border router must use a 491 public IPv4 address distinctively to represent each IPv6 any- 492 source multicast source. 494 o In deployments which use IGMP routers, not PIM routers, source- 495 specific multicast can be supported only if all routers have been 496 upgraded to IGMPv3 and no IGMPv1 or IGMPv2 systems are present. 497 Otherwise the operation reverts to the older version of IGMP to 498 preserve compatibility and thus SSM can not be supported. With 499 the use of PIM routers, this is avoided. 501 o The border router must act as the designated router or the rendez- 502 vous point for the IPv4/IPv6 multicast group and this may lead to 503 the use of a single border router in the network instead of load 504 sharing with various border routers. 506 7. Security Considerations 508 6rd Translation Multicast control and data message security are as 509 described in [RFC5969]. The threats and their mitigation described 510 in [RFC5969] apply to multicast communication as well. 512 8. IANA Considerations 514 TBD. 516 9. Acknowledgements 518 We would like to specially thank Mark Townsley for his constructive 519 comments. Steve Wright's online and very many offline comments 520 helped us improve the document. 522 10. References 524 10.1. Normative References 526 [I-D.ietf-mboned-64-multicast-address-format] 527 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 528 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work 529 in progress)", August 2012. 531 [I-D.ietf-mboned-auto-multicast] 532 Bumgardner, G., "Automatic Multicast Tunneling (work in 533 progress)", June 2012. 535 [I-D.ietf-softwire-dslite-multicast] 536 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 537 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 538 over an IPv6 Multicast Network", draft-ietf-softwire- 539 dslite-multicast-05 (work in progress), April 2013. 541 [ID.perreault-igmp-mld-translation] 542 Perrault, S. and T. Tsou, "Internet Group Management 543 Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 544 Multicast Translation ("IGMP/MLD Translation") (Work in 545 progress)", February 2013. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 551 over Non-Broadcast Multiple Access (NBMA) networks", RFC 552 2491, January 1999. 554 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 555 June 1999. 557 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 558 Thyagarajan, "Internet Group Management Protocol, Version 559 3", RFC 3376, October 2002. 561 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 562 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 564 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 565 for IPv6 Hosts and Routers", RFC 4213, October 2005. 567 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 568 RFC 4286, December 2005. 570 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 571 "Considerations for Internet Group Management Protocol 572 (IGMP) and Multicast Listener Discovery (MLD) Snooping 573 Switches", RFC 4541, May 2006. 575 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 576 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 577 Protocol Specification (Revised)", RFC 4601, August 2006. 579 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 580 "Internet Group Management Protocol (IGMP) / Multicast 581 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 582 /MLD Proxying")", RFC 4605, August 2006. 584 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 585 Infrastructures (6rd)", RFC 5569, January 2010. 587 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 588 Infrastructures (6rd) -- Protocol Specification", RFC 589 5969, August 2010. 591 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 592 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 593 October 2010. 595 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 596 Algorithm", RFC 6145, April 2011. 598 10.2. Informative References 600 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 601 "IANA Guidelines for IPv4 Multicast Address Assignments", 602 RFC 3171, August 2001. 604 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 605 Nordmark, "The Line-Identification Option", RFC 6788, 606 November 2012. 608 Authors' Addresses 609 B. Sarikaya 610 Huawei Technologies (USA) 611 5340 Legacy Dr. Building 175 612 Plano, TX 75024 613 USA 615 Email: sarikaya@ieee.org 617 Tina Tsou 618 Huawei Technologies (USA) 619 2330 Central Expressway 620 Santa Clara, CA 95050 621 USA 623 Phone: +1 408 330 4424 624 Email: Tina.Tsou.Zouting@huawei.com 625 URI: http://tinatsou.weebly.com/contact.html 627 Hui Ji 628 China Telecom 629 NO19.North Street 630 Beijing, Chaoyangmen,Dongcheng District 631 P.R. China 633 Email: jihui@chinatelecom.com.cn 635 Cathy Zhou 636 Huawei Technologies 637 Bantian, Longgang District 638 Shenzhen 518129 639 P.R. China 641 Email: cathy.zhou@huawei.com