idnits 2.17.1 draft-sarikaya-softwire-4rdmulticast-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 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 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 == There are 2 instances 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 19, 2013) is 4084 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: 'RFC2119' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC2491' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC2765' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'RFC6145' is defined on line 747, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-04 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-01 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-softwire-4rd (ref. 'I-D.ietf-softwire-4rd') == Outdated reference: A later version (-06) exists of draft-ietf-mboned-64-multicast-address-format-04 == Outdated reference: A later version (-01) exists of draft-sarikaya-softwire-6man-raoptions-00 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track February 19, 2013 5 Expires: August 23, 2013 7 Multicast Support for MAP-E 8 draft-sarikaya-softwire-4rdmulticast-06.txt 10 Abstract 12 This memo specifies MAP-E (together with MAP-T and 4rd)'s multicast 13 component so that IPv4 hosts can receive multicast data from IPv4 14 servers over an IPv6 network. In the encapsulation solution for 15 encapsulation variant of Mapping of Address and Port (MAP), MAP-E, 16 IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunnel 17 established by MAP-E to exchange IGMP messages to establish multicast 18 state at MAP-E Border Relay so that MAP-E Border Relay can tunnel 19 IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge 20 device. In the Translation Multicast solution for the translation 21 variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD 22 messages at the CE router which is IGMP/MLD Proxy and sent to the 23 network in IPv6. MAP-T/4rd Border Relay does the reverse translation 24 and joins IPv4 multicast group for MAP-T/4rd hosts. Border Relay as 25 multicast router receives IPv4 multicast data and translates the 26 packet into IPv6 multicast data and sends downstream on the multicast 27 tree. Member CEs receive multicast data, translate it back to IPv4 28 and transmit 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 August 23, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Encapsulation Multicast Architecture . . . . . . . . . . . 5 68 4.2. MAP-T and 4rd Translation Architecture . . . . . . . . . . 6 69 5. Encapsulation Multicast Operation . . . . . . . . . . . . . . 7 70 5.1. Encapsulation Interface Considerations . . . . . . . . . . 9 71 5.2. Avalanche Problem Considerations . . . . . . . . . . . . . 10 72 6. MAP-T and 4rd Translation Multicast Operation . . . . . . . . 10 73 6.1. Address Translation . . . . . . . . . . . . . . . . . . . 11 74 6.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 12 75 6.3. Supporting IPv6 Multicast in MAP-T and 4rd Translation 76 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.4. Learning Multicast Prefixes for IPv4-embedded IPv6 78 Multicast Addresses . . . . . . . . . . . . . . . . . . . 14 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 10.2. Informative references . . . . . . . . . . . . . . . . . . 17 85 Appendix A. Group Membership Message Translation Details . . . . 18 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 With IPv4 address depletion on the horizon, many techniques are being 91 standardized for IPv6 migration including Mapping of Address and Port 92 (MAP) - Encapsulation, - Translation and 4rd [I-D.ietf-softwire-map], 93 [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd]. MAP/4rd enables 94 IPv4 hosts to communicate with external hosts using IPv6 only ISP 95 network. MAP/4rd Customer Edge (CE) device's LAN side is dual stack 96 and WAN side is IPv6 only. CE tunnels/translates IPv4 packets 97 received from the LAN side to 4rd Border Relays (BR). BRs have 98 anycast IPv6 addresses and receive encapsulated/translated packets 99 from CEs over a virtual interface. MAP/4rd operation is stateless. 100 Packets are received/ sent independent of each other and no state 101 needs to be maintained except for NAT44 operation on IPv4 packets 102 received from the user. 104 It should be noted that there is no depletion problem for IPv4 105 address space allocated for any source multicast and source specific 106 multicast [RFC3171]. This document is not motivated by the depletion 107 of IPv4 multicast addresses. 109 MAP-E, MAP-T and 4rd are unicast only. They do not support 110 multicast. In this document we specify how multicast from home IPv4 111 users can be supported in MAP-E (as well as MAP-T and 4rd). 113 In case of MAP-E we integrate the multicast solution into the MAP-E 114 tunnel resulting in a multicast tunneling protocol. Multicast 115 tunneling protocol has the advantage of not requiring multicast 116 enabled IPv6 network between CE routers and MAP-E BRs. 118 When MAP-E CE router receives an IGMP join message to an Any-Source 119 Multicast (ASM) [RFC1112] or Source-Specific Multicast (SSM) group 120 [RFC4607], it sends an aggregated IGMP membership report message in 121 the IPv4-in-IPv6 tunnel to the border relay. MAP-E BR joins the 122 source in the multicast infrastructure and sends multicast data 123 downstream to all member CEs in the IPv4-in-IPv6 tunnel. When a CE 124 has no membership state, i.e. after all member hosts leave the 125 group(s), its state with the BR expires and the CE can send the next 126 join message in anycast. IPv4 multicast data received at the BR is 127 tunneled to the member CE in IPv6 and CE decapsulates the packet and 128 sends IPv4 multicast data packet to the member hosts. 130 In case IPv6 network is multicast enabled, MAP-T/4rd can provide 131 multicast service to the hosts using MAP-T/4rd Multicast Translation 132 based solution. A Multicast Translator can be used that receives 133 IPv4 multicast group management messages in IGMP and generates 134 corresponding IPv6 group management messages in MLD and sends them to 135 IPv6 network towards MAP-T/4rd Border Relay. We use 137 [I-D.ietf-softwire-map-t] or [I-D.ietf-softwire-4rd] for sending IPv4 138 multicast data in IPv6 to the CE routers. At MAP-T/4rd CE router 139 another translator is needed to translate IPv6 multicast data into 140 IPv4 multicast data. 142 It should be noted that if IPv6 network is multicast enabled the 143 translation multicast solution presented in Section 6 can also be 144 used for MAP-E. 146 In this document we address MAP-E (and MAP-T/4rd) multicast problem 147 and propose two architectures: Multicast Tunneling and Multicast 148 Translation based solutions. Section 2 is on terminology, Section 3 149 is on requirements, Section 4 is on architecture, Section 5 is on 150 multicast tunneling protocol Section 6 is on multicast translation 151 protocol, and Section 7 states security considerations. 153 2. Terminology 155 This document uses the terminology defined in 156 [I-D.ietf-softwire-map], [I-D.ietf-softwire-map-t], 157 [I-D.ietf-softwire-4rd], [RFC3810] and [RFC3376]. 159 3. Requirements 161 This section states requirements on MAP-E, MAP-T and 4rd multicast 162 support protocol. 164 IPv4 hosts connected to MAP-E, MAP-T and 4rd CE router MUST be able 165 to join multicast groups in IPv4 and receive multicast data. 167 Any source multicast (ASM) SHOULD be supported and source specific 168 multicast (SSM) MUST be supported. 170 In case of encapsulation solution, MAP-E CE MUST support IGMP Proxy 171 as defined in [RFC4605]. MAP-E BR MUST support IGMP querier 172 downstream and MAP-E BR may support PIM protocol or IGMP router 173 upstream. 175 In case of translation solution, MAP-T and 4rd CE MUST support IGMP 176 to MLD translation. MAP-T and 4rd CE MUST be MLD Proxy as defined in 177 [RFC4605]. MAP-T and 4rd BR MUST support MLD Querier. MAP-T and 4rd 178 BR MUST support join/leave operations in IPv4 multicast upstream. 180 4. Architecture 182 In MAP-E, MAP-T and 4rd, there are hosts (possibly IPv4/ IPv6 dual 183 stack) served by MAP-E, MAP-T and 4rd Customer Edge device. CE is 184 dual stack facing the hosts and IPv6 only facing the network or WAN 185 side. MAP-E, MAP-T and 4rd CE may be local IPv4 Network Address and 186 Port Translation (NAPT) box [RFC3022] by assigning private IPv4 187 addresses to the hosts. MAP-E, MAP-T and 4rd CEs in the same domain 188 may use shared public IPv4 addresses on their WAN side and if they do 189 they should avoid ports outside of the allocated port set for NAPT 190 operation. At the boundary of the network there is MAP-E, MAP-T and 191 4rd Border Relay. BR receives IPv4 packets tunneled in IPv6 from CE 192 and decapsulates them and sends them out to IPv4 network. 194 Unicast MAP-E, MAP-T and 4rd are stateless except for the local NAPT 195 at the CE. Each IPv4 packet sent by CE treated separately and 196 different packets from the same CE may go to different BRs or CEs. 197 CE encapsulates IPv4 packet in IPv6 with destination address set to 198 BR address (usually anycast IPv6 address). BR receives the 199 encapsulated packet and decapsulates and send it to IPv4 network. 200 CEs are configured with Rule IPv4 Prefixes, Rule IPv6 Prefixes and 201 with an BR IPv6 anycast address. BR receives IPv4 packets addressed 202 to this ISP and from the destination address it extracts the 203 destination host's IPv4 address and uses this address as destination 204 address and encapsulates the IPv4 packet in IPv6 and sends it to 205 IPv6-only network. 207 4.1. Encapsulation Multicast Architecture 209 Encapsulation variant of MAP called MAP-E network lends itself easily 210 to the Multicast Tunneling architecture. Dual stack hosts are 211 connected to the Customer Edge router and it is multicast enabled. 212 It is assumed that IPv6 only network is the unicast only network and 213 that IPv6 multicast is not enabled or IPv6 multicast is partially 214 enabled. At the boundary of the network MAP-E Border Relay is 215 connected to the native multicast backbone infrastructure. 217 We place IGMP Proxy at the CE router. CE router serves all the 218 connected hosts. For multicast traffic, CE Router uses MAP-E 219 tunneling interface with MAP-E BR to send/receive IGMP messages using 220 IPv4-in-IPv6 tunnel [RFC2473]. 222 MAP-E BR is IGMP Router towards the CEs and it could be IGMP Router 223 or PIM router upstream. A given relay and all CEs connected to it 224 can be considered to be on a separate logical link. On this link, 225 gateways and relay communicate using IPv4-in-IPv6 tunneling to 226 transmit and receive multicast control messages for membership 227 management and multicast data from the relay to the gateways. 229 All the elements of MAP-E multicast support system with tunneling are 230 shown in Figure 1. 232 Dual Stack Hosts IPv4 233 +----+ Network 234 | H1 | IPv6 235 +----+ +-------+ only +--------------+ + 236 +----+ | CE | network | BR | 237 | H2 | ---| IGMP |--- -- |IGMP | IGMP | IPv6 238 +----+ | Proxy | |Router| PIM | Network 239 +----+ +-------+ +--------------+ 240 | H3 | 241 +----+ 243 Figure 1: Architecture of MAP-E Multicast Tunneling 245 4.2. MAP-T and 4rd Translation Architecture 247 In case IPv6 only network is multicast enabled, translation multicast 248 architecture can be used. CE implements IGMP Proxy function 249 [RFC4605] towards the LAN side and MLD Proxy on its WAN interface. 250 IPv4 hosts send their join requests (IGMP Membership Report messages) 251 to CE. CE as a MLD proxy sends aggregated MLD Report messages 252 upstream towards BR. CE replies MLD membership query messages with 253 MLD membership report messages based on IGMP membership state in the 254 IGMP/MLD proxy. 256 BR is MLD querier on its WAN side. On its interface to IPv4 network 257 BR may either have IGMP client or PIM. PIM being able to support 258 both IPv4 and IPv6 multicast should be preferred. BR receives MLD 259 join requests, extracts IPv4 multicast group address and then joins 260 the group upstream, possibly by issuing a PIM join message. 262 IPv4 multicast data received by the BR as a leaf node in IPv4 263 multicast distribution tree is translated into IPv6 multicast data by 264 the translator using [I-D.ietf-softwire-map-t], 265 [I-D.ietf-softwire-4rd] and then sent downstream to the IPv6 part of 266 the multicast tree to all downstream routers that are members. IPv6 267 data packet eventually gets to the CE. At the CE, a reverse 268 [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd] operation takes 269 place by the translator and then IPv4 multicast data packet is sent 270 to the member hosts on the LAN interface. [I-D.ietf-softwire-map-t], 271 [I-D.ietf-softwire-4rd] are modified to handle multicast addresses. 273 In order to support SSM, IGMPv3 MUST be supported by the host, CE and 274 BR. For ASM, BR MUST be the Rendezvous Point (RP). 276 MAP-T and 4rd Translation Multicast solution uses the multicast 46 277 translator in not one but two places in the architecture: at the CE 278 router and at the Border Relay. IPv4 multicast data received at 4rd 279 BR goes through a [I-D.ietf-softwire-4rd] header-mapping into IPv6 280 multicast data at the BR and another [I-D.ietf-softwire-4rd] header- 281 mapping back to IPv4 multicast data at the CE router. Encapsulation 282 variant of [I-D.ietf-softwire-4rd] is not used. In case of MAP-T, 283 IPv4 data packet is translated using v4 to v6 header translation 284 using multicast addresses instead of the mapping algorithm used in 285 [I-D.ietf-softwire-map-t]. 287 All the elements of MAP-T and 4rd translation-based multicast support 288 system are shown in Figure 2. 290 Dual Stack Hosts IPv4 291 +----+ Network 292 | H1 | +----------+ IPv6 +-------------+ 293 | | | CE | | BR | 294 +----+ |Translator| only | Translator | 295 |MAP-T/4rd | | MAP-T/4rd | 296 +----+ | | network | |IGMP| + 297 | H2 | ---|IGMP-MLD |--------- -- |MLD | or | IPv6 298 +----+ | Proxy | |Querier |PIM | Network 299 +----+ +----------+ +-------------+ 300 | H3 | 301 +----+ 303 Figure 2: Architecture of MAP-T and 4rd Translation Multicast 305 5. Encapsulation Multicast Operation 307 When a host (H1, H2 or H3 in Figure 1) wants to join an IPv4 308 multicast group G or (S,G), it sends an IGMP report (IGMPv3 report 309 for a source-specific group) to CE router. 311 CE encapsulates IGMP report messages in IPv6 and sends it over the 312 tunnel to BR in anycast. CE router uses BR's anycast address this CE 313 router is configured with. After CE receives unicast address of BR, 314 it sends all subsequent IGMP messages for G or (S,G) in unicast. 316 BR (topologically closest to this CE router) receives the message, 317 decapsulates it and then lets IGMP router to process it. On the 318 upstream, an IGMP Join message is sent to subscribe group G or (S,G) 319 or a PIMv4 Join message is sent if PIM is supported. BR establishes 320 membership state for group G or (S,G). BR sends all related IGMP 321 messages to this CE in unicast using IPv4-in-IPv6 tunneling. 323 CE now has BR's unicast address which it uses to send all IGMP 324 packets for group G for any source multicast or (S,G) for source 325 specific multicast. If CE receives multiple join messages for the 326 same group G, CE sends an aggregated join message to BR. 328 If CE receives another join message for a different group G', (S',G') 329 CE encapsulates it and sends it in anycast to the BR. This enables 330 the use of multiple BRs that may be deployed as anchor points and 331 makes downstream multicast data delivery more efficient. 333 A CE is required to assist in IGMP signaling and data forwarding 334 between the hosts that it serves and the corresponding BRs that are 335 handling the multicast group G or (S,G). CE must have IGMP Proxy for 336 each upstream tunnel interface that has been established with the BR. 337 The CE decides on the mapping of downstream links to a proxy instance 338 connected to an upstream link to a BR based on the unicast source 339 IPv6 address in the packets received from BR. Because of this BRs 340 MUST use the unicast source IPv6 address in packets sent to CEs. 341 Encapsulation at the CE is according to [RFC2473] with an IPv4 342 payload carrying IGMP messages. 344 On the reception of IGMP reports from the hosts, the CE must identify 345 the corresponding proxy instance from the incoming interface and 346 perform regular IGMP proxy operations of inserting, updating or 347 removing multicast forwarding state on the incoming interface and 348 will merge state updates into the IGMP proxy membership database. It 349 will then send an aggregated Report via the upstream tunnel to the BR 350 when the membership database changes. 352 On the reception of IGMP queries, the CE proxy instance will answer 353 the Queries on behalf of all active downstream receivers maintained 354 in its membership database. Queries sent by the BR do not force the 355 CE to trigger corresponding messages immediately towards hosts. 357 BR acts as the default multicast querier for the corresponding CE. 358 It implements the function of the designated multicast router or a 359 further IGMP proxy. After BR receives IGMP Join message it adds the 360 tunnel to the CE in its outgoing interface list for the group (G) or 361 the source, group (S,G) that the host wants to join. BR establishes 362 group-/source-specific multicast forwarding states at its 363 corresponding downstream tunnel interfaces. Afterwards, BR 364 maintains/removes these group-/source-specific multicast forwarding 365 states. BR treats its tunnel interfaces as multicast-enabled 366 downstream links, serving zero to many listening nodes. BR will send 367 a join message upstream towards the source of the multicast group to 368 build a multicast tree in the native multicast infrastructure and 369 becomes a leaf node in the multicast tree. 371 BR will send any group management messages (IGMP Report or Query 372 messages) downstream to specific CEs on the tunnel interface by 373 encapsulating these IGMP messages in IPv6 using [RFC2473]. 375 As for multicast data, the data packets from the source received at 376 the BR will be replicated to all interfaces in it's outgoing 377 interface list as well as the tunnel outgoing interface for all 378 member CEs. BR sends multicast data in IPv4-in-IPv6 tunnel to the CE 379 with the data packet encapsulated. Encapsulation is according to 380 [RFC2473] with an IPv4 payload. 382 CE receives Multicast Data message over the tunnel interface 383 associated with the tunnel to BR. After decapsulation, multicast 384 traffic arriving at the CE on an upstream interface will be forwarded 385 according to the group-specific or source-specific forwarding states 386 as acquired for each downstream interface within the IGMP proxy 387 instance. 389 5.1. Encapsulation Interface Considerations 391 Legacy IPv4 in IPv6 tunneling is performed as in [RFC2473]. Packets 392 upstream from CE carry only IGMP signaling messages and they are not 393 expected to be subject to fragmentation. However packets downstream, 394 i.e. multicast data to CE may be subject to fragmentation. 396 Source and destination addresses of IGMP messages in IPv4-in-IPv6 397 softwire from CE is as follows: 399 Source address of IPv6 header is CE IPv6 address, e.g. 400 2001:db8:0:1::1, destination address is BR anycast address, possibly 401 shared of the MAP domain. 403 Source address of IGMP messages is CE's IPv4 interface address, e.g. 404 192.0.0.2, destination address is the all-systems multicast address 405 of 224.0.0.1 for IGMP Query, all IGMPv3-capable multicast routers of 406 224.0.0.22 for IGMPv3 Report, the multicast group specified in the 407 Group Address field of the Report for IGMPv1 or IGMPv2 Report. 409 Source and destination addresses of IGMP messages in IPv4-in-IPv6 410 softwire from BR is as follows: 412 Source address of IPv6 header is BR's unicast IPv6 address, e.g. 413 2001:db8:0:2::1, destination address is CE IPv6 address, e.g. 2001: 414 db8:0:1::1. 416 Source address of IGMP messages is CE's IPv4 interface address, e.g. 417 192.0.2.1, destination address is the all-systems multicast address 418 of 224.0.0.1 for IGMP Query, all IGMPv3-capable multicast routers of 419 224.0.0.22 for IGMPv3 Report, the multicast group specified in the 420 Group Address field of the Report for IGMPv1 or IGMPv2 Report. 422 Source and destination addresses of multicast data messages in IPv4- 423 in-IPv6 softwire is as follows: 425 Source address of IPv6 header is BR IPv6 unicast address, e.g. 2001: 426 db8:0:2::1, destination address is CE IPv6 address, e.g. 427 2001:db8:0:1::1. 429 Source address of IPv4 multicast data is unicast IPv4 address of the 430 multicast source, e.g. the content provider, destination address is 431 IPv4 multicast group address. 433 BR decapsulates datagrams carrying IGMP messages from CE's and then 434 IGMP/PIM router processing takes over. Network Address Translation 435 (NAT) is not applied on IGMP messages. 437 5.2. Avalanche Problem Considerations 439 In Section 5 BR replicates the data packets from the source received 440 to all outgoing interfaces for all member CEs. This replication 441 (often called avalanche problem) can be very costly if there are very 442 large number of downstream member CEs such as in IPTV application. 443 Note that the avalanche problem is faced by all multicast solutions 444 that use tunneling to bypass non-multicast enabled access network. 446 In multicast MAP-E, one approach that can be used is to deploy MAP-E 447 BRs close to the user. BRs colocated at the access network gateway 448 such as at the Border Network Gateway (BNG) could reduce the packet 449 duplication bottleneck considerably. 451 In multicast MAP-E, another approach is to exploit multiple BRs that 452 can be deployed in the network. MAP-E CE can use BR anycast address 453 when sending an encapsulated upstream IGMP join request and then use 454 the unicast source address of this BR in subsequent IGMP messages. 456 6. MAP-T and 4rd Translation Multicast Operation 458 In this section we specify how the host can subscribe and receive 459 IPv4 multicast data from IPv4 content providers based on the 460 architecture defined in Figure 2 in two parts: address translation 461 and protocol translation. Translation details are given in 462 Appendix A. 464 6.1. Address Translation 466 IPv4-only host, H1 will join IPv4 multicast group by sending IGMP 467 Membership Report message upstream towards the IGMP Proxy in 468 Figure 2. MLD Proxy first creates a synthesized IPv6 address of IPv4 469 multicast group address using IPv4-embedded IPv6 multicast address 470 format [I-D.ietf-mboned-64-multicast-address-format]. ASM_MPREFIX64 471 for any source multicast groups and SSM_MPREFIX64 for source specific 472 multicast groups are used. Both are /96 prefixes. 474 SSM_MPREFIX64 is set to ff3x:0:8000::/96, with 'x' set to any valid 475 scope. ASM_MPREFIX64 values are formed as shown in Figure 3. M bit 476 MUST BE set to 1. "flgs" and "scop" fields are defined in [RFC3956]. 477 The usage of the "rsv" bits is the same as defined in [RFC3306]. 478 "sub-group-id" field MUST follow the recommendations specified in 479 [RFC3306] if unicast-based prefix is used or the recommendations 480 specified in [RFC3956] if embedded-RP is used. The default value is 481 all zeros. 483 | 8 | 4 | 4 | 4 | 76 | 32 | 484 +--------+----+----+----+------------------------------+----------+ 485 |11111111|flgs|scop|rsvM| sub-group-id |v4 address| 486 +--------+----+----+----+-----------------------------------------+ 488 Figure 3: ASM_MPREFIX64 Formation 490 Each translator in the upstream BR is assigned a unique ASM_MPREFIX64 491 prefix. CE (MLD Proxy in CE) can learn this value by means out of 492 scope with this document. With this, CE can easily create an IPv6 493 multicast address from the IPv4 group address a.b.c.d that the host 494 wants to join. 496 Source-Specific Multicast (SSM) can also be supported similar to the 497 Any Source Multicast (ASM) described above. In case of SSM, IPv4 498 multicast addresses use 232.0.0.0/8 prefix. IPv6 SSM_MPREFIX64 is 499 set to FF3x:0:8000::/96. 501 Since SSM translation requires a unique address for each IPv4 502 multicast source, an IPv6 unicast prefix must be configured to the 503 translator in the upstream BR to represent IPv4 sources. This prefix 504 is prepended to IPv4 source addresses in translated packets. 506 The join message from the host for the group ASM_MPREFIX64:a.b.c.d or 507 SSM_MPREFIX64:a.b.c.d or an aggregate join message will be received 508 by MLD querier at the BR. BR as multicast anchor checks the group 509 address and recognizes ASM_MPREFIX64 or SSM_MPREFIX64 prefix. It 510 next checks the last 32 bits is an IPv4 multicast address in range 511 224/8 - 239/8. If all checks succeed, IGMPv4 Client joins a.b.c.d 512 using IGMP on its IPv4 interface. 514 Joining IPv4 groups can also be done using PIM since PIM supports 515 both IPv4 and IPv6. The advantage of using PIM is that there is no 516 need to enable IGMP support in neighboring IPv4 routers. The 517 advantage of using IGMP is that IGMP is a simpler protocol and it is 518 supported by a wider range of routers. The use of PIM or IGMP is 519 left as an implementation choice. 521 6.2. Protocol Translation 523 The hosts will send their subscription requests for IPv4 multicast 524 groups upstream to the default router, i.e. Costumer Edge device. 525 After subscribing the group, the host can receive multicast data from 526 the CE. The host implements IGMP protocol's host part. 528 Customer Edge device is IGMP Proxy facing the LAN interface. After 529 receiving the first IGMP Report message requesting subscription to an 530 IPv4 multicast group, a.b.c.d, MLD Proxy in the CE's WAN interface 531 synthesizes an IPv6 multicast group address corresponding to a.b.c.d 532 and sends an MLD Report message upstream to join the group. 534 When CE is a NAT or NAPT box assigning private IPv4 addresses to the 535 hosts, IP Multicast requirements for a Network Address Translator 536 (NAT) and a Network Address Port Translator (NAPT) stated in 537 [RFC5135] apply to IGMP messages and IPv4 multicast data packets. 539 When MAP-T or 4rd BR receives IPv4 multicast data for an IPv4 group 540 a.b.c.d it [I-D.ietf-softwire-4rd] translates/encapsulates IPv4 541 packet into IPv6 multicast packet and sends it to IPv6 synthesized 542 address corresponding to a.b.c.d using ASM_MPREFIX64 or 543 SSM_MPREFIX64. The header mapping described in 544 [I-D.ietf-softwire-4rd] Section 4.2 (using Table 1) is used except 545 for mapping the source and destination addresses. In this document 546 we use the multicast address translation described in Section 6.1 and 547 propose it as a complementary enhancement to the translation 548 algorithm in [I-D.ietf-softwire-4rd]. 550 The IP/ICMP translation translates IPv4 packets into IPv6 using 551 minimum MTU size of 1280 bytes (Section 4.3 in 552 [I-D.ietf-softwire-4rd]) but this can be changed for multicast. Path 553 MTU discovery for multicast is possible in IPv6 so 4rd BR can perform 554 path MTU discovery for each ASM group and use these values instead of 555 1280. For SSM, a different MTU value MUST be kept for each SSM 556 channel. Because of this 8 bytes added by IPv6 fragment header in 557 each data packet can be tolerated. 559 Since multicast address translation does not preserve checksum 560 neutrality, [I-D.ietf-softwire-4rd] translator/encapsulator at 4rd BR 561 must however modify the UDP checksum to replace the IPv4 addresses 562 with the IPv6 source and destination addresses in the pseudo-header 563 which consists of source address, destination address, protocol and 564 UDP length fields before calculating the new checksum. 566 IPv6 multicast data must be translated back to IPv4 at the 4rd CE 567 (e.g. using Table 2 in Section 4.3 of [I-D.ietf-softwire-4rd]). Such 568 a task is much simpler than the translation at 4rd BR because IPv6 569 header is much simpler than IPv4 header and IPv4 link on the LAN side 570 of 4rd CE is a local link. The packet is sent on the local link to 571 IPv4 group address a.b.c.d for IPv6 group address of ASM_MPREFIX64: 572 a.b.c.d or SSM_MPREFIX64:a.b.c.d. 574 In case an IPv4 multicast source sends multicast data with the don't 575 fragment (DF) flag set to 1, [I-D.ietf-softwire-4rd] header mapping 576 sets the D bit in IPv6 fragment header before sending the packet 577 downstream as in Fig. 3 in Section 4.3 of [I-D.ietf-softwire-4rd]. 578 This feature of [I-D.ietf-softwire-4rd] preserves the semantics of DF 579 flag at the BR and CE. 581 Because MAP-T/4rd is stateless, Multicast MAP-T/4rd should stay 582 faithful to this as much as possible. Border Relay acts as the 583 default multicast querier for all CEs that have established multicast 584 communication with it. In order to keep a consistent multicast state 585 between a CE and BR, CE MUST use the same IPv6 multicast prefixes 586 (ASM_MPREFIX64/SSM_REFIX64) until the state becomes empty. After 587 that point, the CE may obtain different values for these prefixes, 588 effectively changing to a different 4rd BR. 590 6.3. Supporting IPv6 Multicast in MAP-T and 4rd Translation Multicast 592 IPv6 multicast can be supported natively since IPv6-only network is 593 assumed to be multicast enabled. MAP-T or 4rd Customer Edge device 594 has MLD Proxy function. Proxy operation for MLD [RFC3810] is 595 described in [RFC4605]. 597 CE receives MLD join requests from the hosts and then sends 598 aggregated MLD Report messages upstream towards BR. No address or 599 protocol translation is needed at the CE or at the BR. IPv6 Hosts in 600 MAP-T or 4rd domain use any source multicast block FF0X [RFC4291] or 601 source specific multicast block FF3X::8000:0-FF3X::FFFF:FFFF for 602 dynamic allocation by a host [RFC4607], [RFC3307]. 604 MAP-T or 4rd Border Relay is MLD querier. It serves all CEs 605 downstream. After receiving an MLD join message, BR sends PIM join 606 message upstream to join IPv6 multicast group. Multicast membership 607 database is maintained based on the aggregated Reports received from 608 downstream interfaces in the multicast tree. 610 MAP-T or 4rd Border Relay is a Rendezvous Point (RP) for ASM groups. 611 For SSM, BR MUST support MLDv2. 613 IPv6 multicast data received from the Single Source Multicast or Any 614 Source Multicast sources are replicated according to the multicast 615 membership database and the data packets are sent downstream on the 616 multicast tree and eventually received by the CEs that have one of 617 more members of this multicast group. 619 MLD Proxy in the CE receives multicast data then forwards the packet 620 downstream. Each member host receives IPv6 multicast data packet 621 from its Layer 2 interface. 623 6.4. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast 624 Addresses 626 CE can be pre-configured with Multicast Prefix64 of ASM_MPREFIX64 and 627 SSM_MPREFIX64 that are supported in their network. However 628 automating this process is also desired. 630 A new router advertisement option, a Multicast ASM Translation Prefix 631 option, can be defined for this purpose. The option contains IPv6 632 ASM multicast translation prefix, ASM_MPREFIX64. A new router 633 advertisement option, a Multicast SSM Translation Prefix option, can 634 be defined for this purpose. The option contains IPv6 SSM multicast 635 prefix translation prefix SSM_MPREFIX64. 637 After the host gets the multicast prefixes, when an application in 638 the host wishes to join an IPv4 multicast group the host MUST use 639 ASM_MPREFIX64 or SSM_MPREFIX64 and then obtain the synthesized IPv6 640 group address before sending MLD join message. 642 Source-specific multicast (SSM) group membership message payloads in 643 IGMPv3 and MLDv2 contain address literals and their translation 644 requires another multicast translation prefix option. IPv4 source 645 addresses in IGMPv3 Membership Report message are unicast addresses 646 of IPv4 sources and they have to be translated into unicast IPv6 647 source addresses in MLDv2 Membership Report message. A new router 648 advertisement option, a Multicast Translation Unicast Prefix option 649 can be defined for this purpose. The option contains IPv6 unicast 650 Network-Specific Prefix U_PREFIX64. The host can be configured by 651 its default router using router advertisements containing the 652 prefixes [I-D.sarikaya-softwire-6man-raoptions]. 64:ff9b::/96 is the 653 global value called well-known prefix that is assigned to U_PREFIX64 654 [RFC6052]. Organization specific values called Network-Specific 655 Prefixes can also be used. Since multicast is potentially inter- 656 domain, the use of well-known prefix for U_PREFIX64 is recommended. 658 Note that U_PREFIX64 is also used in multicast data packet address 659 translation. Source-specific multicast source address in multicast 660 data packets coming from SSM sources MUST be translated using 661 U_PREFIX64. 663 7. Security Considerations 665 4rd Encapsulation Multicast control and data message security can be 666 provided by the security architecture, mechanisms, and services 667 described in [RFC4301], [RFC4302] and [RFC4303]. 4rd Translation 668 Multicast control and data message security are as described in 669 [RFC4607] for source specific multicast. 671 8. IANA Considerations 673 TBD. 675 9. Acknowledgements 677 TBD. 679 10. References 681 10.1. Normative References 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, March 1997. 686 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 687 June 1999. 689 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 690 RFC 1112, August 1989. 692 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 693 February 1997. 695 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 696 RFC 2711, October 1999. 698 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 699 "IANA Guidelines for IPv4 Multicast Address Assignments", 700 RFC 3171, August 2001. 702 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 703 "Internet Group Management Protocol (IGMP) / Multicast 704 Listener Discovery (MLD)-Based Multicast Forwarding 705 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 707 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 708 IP", RFC 4607, August 2006. 710 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 711 Addresses", RFC 3307, August 2002. 713 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 714 over Non-Broadcast Multiple Access (NBMA) networks", 715 RFC 2491, January 1999. 717 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 718 IPv6 Specification", RFC 2473, December 1998. 720 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 721 (SIIT)", RFC 2765, February 2000. 723 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 724 Address Translator (Traditional NAT)", RFC 3022, 725 January 2001. 727 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 728 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 730 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 731 Thyagarajan, "Internet Group Management Protocol, Version 732 3", RFC 3376, October 2002. 734 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 735 Internet Protocol", RFC 4301, December 2005. 737 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 738 December 2005. 740 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 741 RFC 4303, December 2005. 743 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 744 Network Address Translator (NAT) and a Network Address 745 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 747 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 748 Algorithm", RFC 6145, April 2011. 750 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 751 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 752 October 2010. 754 [I-D.ietf-softwire-map] 755 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., and 756 T. Murakami, "Mapping of Address and Port with 757 Encapsulation (MAP)", draft-ietf-softwire-map-04 (work in 758 progress), February 2013. 760 [I-D.ietf-softwire-map-t] 761 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 762 T. Murakami, "Mapping of Address and Port using 763 Translation (MAP-T)", draft-ietf-softwire-map-t-01 (work 764 in progress), February 2013. 766 [I-D.ietf-softwire-4rd] 767 Jiang, S., Despres, R., Penno, R., Lee, Y., Chen, G., and 768 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 769 Solution (4rd)", draft-ietf-softwire-4rd-04 (work in 770 progress), October 2012. 772 [I-D.ietf-mboned-64-multicast-address-format] 773 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 774 M. Xu, "IPv6 Multicast Address With Embedded IPv4 775 Multicast Address", 776 draft-ietf-mboned-64-multicast-address-format-04 (work in 777 progress), August 2012. 779 10.2. Informative references 781 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 782 Multicast Addresses", RFC 3306, August 2002. 784 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 785 Point (RP) Address in an IPv6 Multicast Address", 786 RFC 3956, November 2004. 788 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 789 Architecture", RFC 4291, February 2006. 791 [I-D.sarikaya-softwire-6man-raoptions] 792 Sarikaya, B., "IPv6 RA Options for Translation Multicast 793 Prefixes", draft-sarikaya-softwire-6man-raoptions-00 (work 794 in progress), August 2012. 796 [I-D.perreault-mboned-igmp-mld-translation] 797 Perreault, S. and T. Tsou, "Internet Group Management 798 Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 799 Multicast Translation ("IGMP/MLD Translation")", 800 draft-perreault-mboned-igmp-mld-translation-01 (work in 801 progress), April 2012. 803 Appendix A. Group Membership Message Translation Details 805 IGMP Report messages (IGMP type number 0x12 and 0x16, in IGMPv1 and 806 IGMPv2 and 0x22 in IGMPv3) are translated into MLD Report messages 807 (MLDv1 ICMPv6 type number 0x83 and MLDv2 type number 0x8f). IGMP 808 Query message (IGMP type number 0x11) is translated into MLD Query 809 message (ICMPv6 type number 0x82) 810 [I-D.perreault-mboned-igmp-mld-translation]. 812 Destination address in ASM, i.e. IGMPv1, IGMPv2 and MLDv1, is the 813 multicast group address so the destination address in IGMP message is 814 translated into the destination address in MLD message using 815 [I-D.ietf-mboned-64-multicast-address-format]. 817 Destination address in SSM, i.e. IGMPv3 and MLDv2 is translated as 818 follows: it could be all nodes on link, which has the value of 819 224.0.0.1 (IGMPv3) and ff02::1 (MLDv2), all routers on link, which 820 has the value of 224.0.0.2 (IGMPv3) and ff02::2 (MLDv2), all IGMP/ 821 MLD-capable routers on link, which has the value of 224.0.0.22 822 (IGMPv3) and ff02::16 (MLDv2). 824 Source address of MLD message that CE sends is set to link-local IPv6 825 address of CE's WAN side interface. Source address of MLD message 826 that BR sends is set to link-local IPv6 address of BR's downstream 827 interface. 829 Multicast Address or Group Address field in IGMP message payloads is 830 translated using [I-D.ietf-mboned-64-multicast-address-format] as 831 described above into the corresponding field in MLD message. 833 Source Address in IGMPv3 message payloads is translated using 834 U_PREFIX64, the IPv6 unicast prefix to be used by SSM source. 835 [RFC6052] defines in Section 2.3 the address translation algorithm of 836 embedding an IPv4 source address and obtaining an IPv6 source address 837 using a network specific prefix like U_PREFIX64. At the BR on its 838 upstream interface or at the CE on its LAN interface, IPv4 addresses 839 are extracted from the IPv4-embedded IPv6 addresses. 841 Maximum Response Time (MRT) field in IGMPv2 and IGMPv3 queries are 842 translated into Maximum Response Delay (MRD) in MLDv1 and MLDv2 843 queries, respectively. In the corresponding MLD message, MRD is set 844 to 100 times the value of MRT. At the BR on its upstream interface 845 or at the CE on its LAN interface, MRT value is obtained by dividing 846 MRD into 100 and rounding it to the nearest integer. 848 IGMP messages are sent with a Router Alert IPv4 option [RFC2113]. 849 The translated MLD message are sent with a Router Alert option in a 850 Hop-By-Hop IPv6 extension header [RFC2711]. In both cases, 2-octet 851 value is set to 0. 853 Author's Address 855 Behcet Sarikaya 856 Huawei USA 857 5340 Legacy Dr. Building 175 858 Plano, TX 75024 860 Phone: 861 Email: sarikaya@ieee.org