idnits 2.17.1 draft-venaas-behave-v4v6mc-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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 21, 2011) is 4683 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC5245' is defined on line 720, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft cisco Systems 4 Intended status: Informational X. Li 5 Expires: December 23, 2011 C. Bao 6 CERNET Center/Tsinghua 7 University 8 June 21, 2011 10 Framework for IPv4/IPv6 Multicast Translation 11 draft-venaas-behave-v4v6mc-framework-03.txt 13 Abstract 15 This draft describes how IPv4/IPv6 multicast translation may be used 16 in various scenarios and attempts to be a framework for possible 17 solutions. This can be seen as a companion document to the document 18 "Framework for IPv4/IPv6 Translation" by Baker et al. When 19 considering scenarios and solutions for unicast translation, one 20 should also see how they may be extended to provide multicast 21 translation. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 23, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Translation scenarios . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Scenario 1: An IPv6 network receiving multicast from 60 the IPv4 Internet . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Scenario 2: The IPv4 Internet receiving multicast from 62 an IPv6 network . . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Scenario 3: The IPv6 Internet receiving multicast from 64 an IPv4 network . . . . . . . . . . . . . . . . . . . . . 7 65 2.4. Scenario 4: An IPv4 network receiving multicast from 66 the IPv6 Internet . . . . . . . . . . . . . . . . . . . . 7 67 2.5. Scenario 5: An IPv6 network receiving multicast from 68 an IPv4 network . . . . . . . . . . . . . . . . . . . . . 8 69 2.6. Scenario 6: An IPv4 network receiving multicast from 70 an IPv6 network . . . . . . . . . . . . . . . . . . . . . 8 71 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1.1. Source addressing . . . . . . . . . . . . . . . . . . 10 74 3.1.2. Group addressing . . . . . . . . . . . . . . . . . . . 10 75 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.1. Translation with PIM and SSM . . . . . . . . . . . . . 11 77 3.2.2. Translation with PIM and ASM . . . . . . . . . . . . . 11 78 3.2.3. Translation with IGMP/MLD . . . . . . . . . . . . . . 12 79 3.3. Translation in operation . . . . . . . . . . . . . . . . . 12 80 3.3.1. Stateless Translation . . . . . . . . . . . . . . . . 12 81 3.3.2. Stateful Translation . . . . . . . . . . . . . . . . . 13 82 3.4. Application layer issues . . . . . . . . . . . . . . . . . 15 83 3.5. Further Work . . . . . . . . . . . . . . . . . . . . . . . 17 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 There will be a long period of time where IPv4 and IPv6 systems and 95 networks need to coexist. There are various solutions for how this 96 can be done for unicast, some of which are based on translation. The 97 document [RFC6144] discusses the needs and provides a framework for 98 unicast translation for various scenarios. Here we discuss the need 99 for multicast translation for those scenarios. 101 For unicast the problem is basically how two hosts can communicate 102 when they are not able to use the same IP protocol. For multicast we 103 can restrict ourselves to looking at how a single source can 104 efficiently send to multiple receivers. When using a single IP 105 protocol one builds a multicast distribution tree from the source to 106 the receivers, and independent of the number of receivers, one sends 107 each data packet only once on each link. We wish to maintain the 108 same characteristics when there are different IP protocols used. 109 That is, when the nodes of the tree (source, receivers and routers) 110 cannot all use the same IP protocol. In general there may be 111 multiple sources sending to a multicast group, but that can be 112 thought of as separate trees, one per source. We will focus on the 113 case where the source and the receivers cannot all use the same IP 114 protocol. If the issue is the network in between, encapsulation may 115 be a better alternative. Note that if the source supports both IPv4 116 and IPv6, then one alternative could be for the source to send two 117 streams. This need not be the same host. There could be two 118 different hosts, and in different locations/networks, sending the 119 same content. 121 2. Translation scenarios 123 We will consider six different translation scenarios. For each of 124 the scenarios we will look at how host in one network can receive 125 multicast from a source in another network. For unicast one might 126 consider the following six scenarios as described in [RFC6144]: 128 Scenario 1: An IPv6 network to the IPv4 Internet 130 Scenario 2: The IPv4 Internet to an IPv6 network 132 Scenario 3: The IPv6 Internet to an IPv4 network 134 Scenario 4: An IPv4 network to the IPv6 Internet 136 Scneario 5: An IPv6 network to an IPv4 network 138 Scenario 6: An IPv4 network to an IPv6 network 140 We have intentionally left out how one might connect the entire IPv4 141 Internet with the entire IPv6 Internet. In these scenarios one would 142 look at how a host in one network initiates a uni- or bi-directional 143 flow to another network. The initiator needs to somehow know which 144 address to send the initial packet to, and the initial packet gets 145 translated before reaching its destination. 147 For unicast translation it is quite natural to talk about networks 148 and the Internet. For multicast this is not so clear, since there is 149 limited use of multicast on the Internet. Certain parts of the 150 Internet, e.g. academic and research networks and the links 151 connecting them do carry multicast though. Also, the challenges and 152 ideas described here regarding the Internet, also applies in other 153 cases where there are multiple connected networks exchanging 154 multicast. 156 For multicast one generally need a receiver to signal the group (and 157 sometimes also the source) it wants to receive from. The signalling 158 generally goes hop-by-hop towards the source to build multicast 159 forwarding state that later is used to forward multicast in the 160 reverse direction. This means that for the receiving host to receive 161 multicast, it must first somehow know which group (and possibly 162 source) it should signal that it wants to receive. These signals 163 would then probably go hop-by-hop to a translator, and then the 164 translated signalling would go hop-by-hop from the translator to the 165 source. Note that this description is correct for SSM (source- 166 specific multicast), but is in reality more complex for ASM (any- 167 source multicast). An anology to unicast might perhaps be TCP 168 streaming where a SYN is sent from the host that wants to receive the 169 stream to the source of the stream. Then the application data flows 170 in the reverse direction of the initial signal. Hence we argue that 171 the above unicast scenarios correspond to the following multicast 172 scenarios, respectively: 174 Scenario 1: An IPv6 network receiving multicast from the IPv4 175 Internet 177 Scenario 2: The IPv4 Internet receiving multicast from an IPv6 178 network 180 Scneario 3: The IPv6 Internet receiving multicast from an IPv4 181 network 183 Scenario 4: An IPv4 network receiving multicast from the IPv6 184 Internet 186 Scenario 5: An IPv6 network receiving multicast from an IPv4 network 188 Scenario 6: An IPv4 network receiving multicast from an IPv6 network 190 2.1. Scenario 1: An IPv6 network receiving multicast from the IPv4 191 Internet 193 Here we have a network, say ISP or enterprise, that for some reason 194 is IPv6-only, but the hosts in the IPv6-only network should be able 195 to receive multicast from sources in the IPv4 internet. The unicast 196 equivalent is "IPv6 network to the IPv4 Internet". 198 This is simple because the global IPv4 address space can be embedded 199 into IPv6 [RFC6052]. Unicast addresses according to the unicast 200 translation in use. For multicast one may embed all IPv4 multicast 201 addresses inside a single IPv6 multicast prefix. Or one may have 202 multiple embeddings to allow for appropriate mapping of scopes and 203 ASM versus SSM. Using this embedding, the IPv6 host (or an 204 application running on the host) can send IPv6 MLD reports for IPv6 205 groups (and if SSM, also sources) that specify which IPv4 source and 206 groups that it wants to receive. The usual IPv6 state (including MLD 207 and possibly PIM) needs to be created. If PIM is involved we need to 208 use RPF to set up the tree and accept data, so the source addresses 209 must be routed towards some translation device. This is likely to be 210 the same device that would do the unicast translation. The 211 translation device can in this case be completely stateless. There 212 is some multicast state, but that is similar to the state in a 213 multicast router when translation is not performed. Basically if the 214 translator receives MLD or PIM messages asking for a specific group 215 (or source and group), it uses these mappings to find out which IPv4 216 group (or source and group) it needs to send IGMP or PIM messages 217 for. This is no different than multicast in general, except for the 218 translation. Whenever the translator receives data from the IPv4 219 source, it checks if it has anyone interested in the respective IPv6 220 group (or source and group), and if so, translates and forwards the 221 data packets. 223 IPv6 applications need to somehow learn which IPv6 group (or source 224 and group) to join. This is further discussed in Section 3.4. 226 2.2. Scenario 2: The IPv4 Internet receiving multicast from an IPv6 227 network 229 Here we will consider an IPv6 network connected to the IPv4 internet, 230 and how any IPv4 host may receive multicast from a source in the IPv6 231 network. The unicast equivalent is "the IPv4 Internet to an IPv6 232 network". 234 This is difficult since the IPv6 multicast address space cannot be 235 embedded into IPv4. Indeed this case has many similarities with how 236 IPv4 networks can receive from the IPv6 Internet. See scenario (4), 237 Section 2.4. However, in this case, all IPv4 hosts on the Internet 238 should use the same mapping, and it might make sense to have 239 additional requirements on the IPv6 network, rather than to add 240 requirements for the IPv4 Internet. 242 One solution here might be for the IPv6 source application to somehow 243 register with the translator to set up a mapping and receive an IPv4 244 address. The application could then possibly send SDP that includes 245 both its IPv6 source and group, and the IPv4 source and group it got 246 from the translator. Of course the signalling could also be done by 247 manually adding a static mapping to the translator and specifying 248 that address to the application. If instead we were to do signalling 249 on the IPv4 side, then an IPv4 receiver would probably need a 250 mechanism for finding an IPv4 address of the translator for a given 251 IPv6 group. The IPv4 address could perhaps be embedded in the IPv6 252 group address? Or with say SDP there could be a way of specifying 253 the IPv4 translator address. The IPv4 host could then communicate 254 with the translator to establish a mapping (unless one exists) and 255 learn which IPv4 group to join. 257 The best alternative might be to restrict the IPv6 multicast groups 258 that should be accessible on the IPv4 internet to a certain IPv6 259 prefix. This may allow stateless translation. This could also be 260 used in the reverse direction, for an IPv6 host to receive from an 261 IPv4 source. Or in other words, the same mapping can be used in both 262 directions. This has similarities with IVI [I-D.xli-behave-ivi], 263 [RFC6145], [RFC6052] and also [I-D.venaas-behave-mcast46]. By using 264 IVI source addresses (IPv4-translatable addresses) and a similar 265 technique for multicast addresses, the correct IPv4 source and group 266 addresses can be derived from those. This method has many benefits, 267 the main issue is that it cannot work for arbitrary IPv6 multicast 268 addresses. 270 2.3. Scenario 3: The IPv6 Internet receiving multicast from an IPv4 271 network 273 We here consider the case where the Internet is IPv6, but there is 274 some network of perhaps legacy IPv4 hosts that is IPv4-only. We want 275 any IPv6 host on the Internet to be able to receive multicast from an 276 IPv4 source. The unicast equivalent is "the IPv6 Internet to an IPv4 277 network". 279 This scenario can be solved using the same techniques as in Scenario 280 1, Section 2.1. There may however be differences regarding exactly 281 which mappings are used and how applications may become aware of 282 them. To obtain full benefit of multicast, all IPv6 hosts need to 283 use the same mappings. 285 2.4. Scenario 4: An IPv4 network receiving multicast from the IPv6 286 Internet 288 Here we consider how an IPv4-only host in an IPv4 network may receive 289 from an IPv6 multicast sender on the Internet. The unicast 290 equivalent is "an IPv4 network to the IPv6 Internet". 292 For dual-stack hosts in an IPv4 network one should consider 293 tunneling. This is difficult since we cannot embed the entire IPv6 294 space into IPv4. One might consider some of the techniques from 295 scenario (2), Section 2.2. That scenario is however much easier 296 since one may restrict which IPv6 groups are used and there is a 297 limited number of sources. 299 For unicast one might use a DNS-ALG for this, where the ALG would 300 instantiate translator mappings as needed. This is the technique 301 used in NAT-PT [RFC2766], which was deprecated by [RFC4966]. 303 However, for multicast one generally does not use DNS. One could 304 consider doing the same with an ALG for some other protocol. E.g. 305 translate addresses in SDP files when they pass the translator, or in 306 any other protocol that might transfer multicast addresses. This 307 would be very complicated and not recommended. 309 Rather than using an ALG that translates addresses in application 310 protocol payload, one could consider new signalling mechanisms for 311 more explicit signalling. The additional signalling could be either 312 on the IPv6 or the IPv4 side. It may however not be a good idea to 313 require additional behavior by host and applications on the IPv6 314 Internet to accomodate legacy IPv4 networks. Also, since one may not 315 be able to provide unique IPv4 multicast addresses for all the IPv6 316 multicast groups that are in use, it makes more sense that the 317 mappings are done locally in each of the IPv4 networks, where IPv4 318 multicast addresses might be assigned on-demand. An IPv4 receiver 319 might somehow request an IPv4 mapping for an IPv6 group (and possibly 320 source). This creates a mapping in the translator so that when the 321 IPv4 receiver joins the IPv4 group, the translator knows which IPv6 322 group (and possibly source) to translate it into. Of course the 323 signalling could also be done manually by adding a static mapping to 324 the translator and somehow specifying the right IPv4 address to the 325 application. 327 2.5. Scenario 5: An IPv6 network receiving multicast from an IPv4 328 network 330 In this scenario we consider IPv4 and IPv6 networks belonging to the 331 same organization. The unicast equivalent is "an IPv6 network to an 332 IPv4 network". 334 We would like any IPv6 host to receive from any IPv4 sources. Here 335 one can use the same techniques as for an IPv6 network receiving from 336 the IPv4 internet. It is really a special case of scenario (1), 337 Section 2.1. 339 The fact that the number of hosts are limited and that there is 340 common management might simplify things. Due to the limited scale, 341 one could perhaps just manually configure all the static mappings 342 needed in the translator and manually create the necessary 343 announcements or in some cases have the applications create the 344 necessary announcements. But it might be better to use a stateless 345 approach where IPv4 unicast and multicast addresses are embedded into 346 IPv6. Like IVI [I-D.xli-behave-ivi], or [I-D.venaas-behave-mcast46]. 348 2.6. Scenario 6: An IPv4 network receiving multicast from an IPv6 349 network 351 In this scenario we consider IPv4 and IPv6 networks belonging to the 352 same organization. The unicast equialent is "an IPv4 network to an 353 IPv6 network". 355 We would like any IPv4 host to receive from any IPv6 source. This 356 can be seen as special cases of either scenario (2), Section 2.2 or 357 scenario (4), Section 2.4, where any of those techniques might apply. 358 However, as discussed in scenario (5) Section 2.5 where we looked at 359 how to do multicast in the reverse direction; the limited number of 360 hosts and common managment might allow us to just use static mappings 361 or a stateless approach by restricting which IPv6 addresses are used. 362 By using these techniques one may be able to create mappings that can 363 be used for multicast in both directions, combining this scenario 364 with scenario (5). 366 3. Framework 368 Having considered some possible scenarios for where and how we may 369 use multicast translation, we will now consider some general issues 370 and the different components of such solutions. 372 3.1. Addressing 374 When doing stateless translation, one need to somehow encode IPv4 375 addresses inside IPv6 addresses so that there is a well defined way 376 for the translator to transform an IPv6 address into IPv4. This can 377 be done with techniques like IVI [I-D.xli-behave-ivi] and 378 [I-D.venaas-behave-mcast46]. 380 There are two types of addressing schemes related to the IPv4/IPv6 381 multicast translation. The source addressing and the group 382 addressing. 384 3.1.1. Source addressing 386 Source addressing issues is the same as in the unicast IPv4/IPv6 387 translation defined in [RFC6052]. The IPv4-mapped address is used 388 for representing IPv4 in IPv6 and the IPv4-translatable address is 389 used for representing IPv6 in IPv4 when the stateless translator is 390 used. The multicast RPF relies on the source address to build the 391 distribution tree. Therefore, depending on the operation mode of the 392 IPv4/IPv6 translator and receiving directions, the IPv4-mapped or the 393 IPv4-translatable addresses will be used. 395 3.1.2. Group addressing 397 Group addressing issue is unique to the IPv4/IPv6 multicast 398 translation. The entire IPv4 group addresses can be uniquely 399 represented by the IPv6 group addresses, while the entire IPv6 group 400 addresses cannot be uniquely represented by the IPv6 group addresses. 401 Therefore, special group address mapping rule between IPv4 group 402 addresses and IPv6 group addresses should be defined for the IPv4/ 403 IPv6 multicast translation. 405 3.2. Routing 407 The actual translation of multicast packets may not be very 408 complicated, in particular if it can be stateless. For the multicast 409 to actually go through the translator we need to have routes for the 410 multicast source addresses involved, so that multicast packets both 411 on their way to and from the translator satisfy RPF checks. These 412 routes are also needed for protocols like PIM-SM to establish a 413 multicast tree, since RPF is used to determine where to send join 414 messages. To go into more detail we need to look at different 415 scenarios like SSM (Source-Specific Multicast) and ASM (Any-Source 416 Multicast), and PIM versus IGMP/MLD. 418 3.2.1. Translation with PIM and SSM 420 When doing SSM, a receiver specifies both source and group addresses. 421 If the receiver is to receive translated packets, it must do an IGMP/ 422 MLD join for the source and group address that the data packets will 423 have after translation. We will later look at how it may learn those 424 addresses. For the source address it joins, the unicast routing (or 425 it may be an alternate topology specific to multicast), must point 426 towards the translator. With this in place, PIM should build a tree 427 hop-by-hop from the last-hop router to the translator. The 428 translator then maps the source and group addresses in the PIM join 429 to the source and group the data packets have before translation. 430 The translator then does a PIM join for that source and group. 431 Provided the routing is correct, this will then build a tree all the 432 way to the source. Finally when these joins reach the source, any 433 data sent by the source will follow this path to the translator, get 434 translated, and then continue to the receiver. 436 3.2.2. Translation with PIM and ASM 438 Let us first consider PIM Sparse Mode. In this case a receiver just 439 joins a group. If this group is to be received via the translator we 440 need to send joins towards the translator, but initially PIM will 441 send joins towards the RP (Rendezvous-Point) for the group. The most 442 efficient solution is probably to make sure that the translator is 443 configured as an RP for all groups that one may receive through it. 444 That is, for the groups it translates to. E.g. if IPv4 groups are 445 embedded into an IPv6 multicast prefix, then the translator could be 446 an RP for that specific prefix. The translator may then translate 447 the group and join towards the group address that is used before 448 translation. Note that if the translator also is an RP for the 449 addresses used before translation, it should know which sources exist 450 and join each of these. If it is not an RP, it needs to join towards 451 the RP. If the translator did not know the sources, it may join each 452 of the sources as soon as it receives from them (that is, switching 453 to Shortest Path Trees). When the translator receives data, it 454 translates it and then sends the translated data. This then follows 455 the joins for the translated groups to the receivers. When the last- 456 hop routers start receiving, they will probably (this is usually the 457 default behavior) switch to SPTs (Shortest Path Trees). These trees 458 also need to go to the translator and would probably follow the same 459 path as the previously built shared tree. One might argue here that 460 switching to the SPT has no benefit if it is the same path anyway. 461 Also with shared trees, RPF is not an issue, so the translated source 462 addresses don't need to be routed towards the translator. 464 At the end of the previous paragraph we pointed out that there is no 465 benefit in switching to shortest path trees if they have to go via 466 the translator anyway. A possibility here could be to use 467 Bidirectional PIM where there is no source specific state and data 468 always go through the RP. It is possible to use Bidir just for those 469 groups that are translated, and then make the translator the RP. 471 3.2.3. Translation with IGMP/MLD 473 For translation taking place close to the edge, e.g. a home gateway, 474 one may consider just using IGMP and MLD, and no PIM. In that case 475 the translator should for any received MLD reports for IPv6 groups 476 that correspond to translated IPv4 groups, map those into IGMP 477 reports that it sends out on the IPv4 side. And vice versa for data 478 in the other direction. Note that a translator implementation could 479 also choose to do this in just one direction. For SSM it would also 480 need to translate the source addresses. 482 3.3. Translation in operation 484 Currently, the proposed solutions for IPv6/IPv4 translation are 485 classified into stateless translation and stateful translation. 487 3.3.1. Stateless Translation 489 For stateless translation, the translation information is carried in 490 the address itself, permitting both IPv4->IPv6 and IPv6- receiving 518 receiving <---- sending 520 Figure 1: Stateless translation for Scenarios 1 and 2 522 -------- --------- 523 // \\ // \\ 524 / +----+ \ 525 | |XLAT| | 526 | An IPv4 +----+ An IPv6 | 527 | Network +----+ Network | XLAT: v4/v6 528 | |DNS | | Translator 529 \ +----+ / DNS: DNS64/DNS46 530 \\ // \\ // 531 -------- --------- 532 sending ----> receiving 533 receiving <---- sending 535 Figure 2: Stateless translator for Scenarios 5 and 6 537 3.3.2. Stateful Translation 539 For stateful translation, the translation state is maintained between 540 IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 541 systems to open sessions with IPv4 systems. See [RFC6145] and 542 [RFC6146]. 544 Stateful translator can be used for Scenarios 1, 3 and 5, i.e. it 545 supports "An IPv6 network receiving multicast from the IPv4 546 Internet", "The IPv6 Internet receiving multicast from an IPv4 547 network" and "An IPv6 network receiving multicast from an IPv4 548 network". 550 In the stateful translation, an IPv6 network or the IPv6 Internet use 551 any IPv6 addresses, while the IPv4 Internet or an IPv4 network can be 552 represented by IPv4-mapped addresses. 554 -------- 555 // \\ ----------- 556 / \ // \\ 557 / +----+ \ 558 | |XLAT| | 559 | The IPv4 +----+ An IPv6 | 560 | Internet +----+ Network | XLAT: Stateful v4/v6 561 | |DNS | | Translator 562 \ +----+ / DNS: DNS64 563 \ / \\ // 564 \\ // ----------- 565 -------- 566 sending ----> receiving 568 Figure 3: Stateful translator for Scenario 1 570 ----------- 571 ---------- // \\ 572 // \\ / \ 573 / +----+ \ 574 | |XLAT| | 575 | An IPv4 +----+ The IPv6 | 576 | Network +----+ Internet | XLAT: v4/v6 577 | |DNS | | Translator 578 \ +----+ / DNS: DNS64 579 \\ // \ / 580 --------- \\ // 581 ----------- 582 sending ----> receiving 584 Figure 4: Stateful translator for Scenario 3 585 -------- --------- 586 // \\ // \\ 587 / +----+ \ 588 | |XLAT| | 589 | An IPv4 +----+ An IPv6 | 590 | Network +----+ Network | XLAT: v4/v6 591 | |DNS | | Translator 592 \ +----+ / DNS: DNS64 593 \\ // \\ // 594 -------- --------- 595 sending ----> receiving 597 Figure 5: Stateful translator for Scenario 5 599 3.4. Application layer issues 601 The main application layer issue is perhaps how the applications 602 learn what groups (or sources and groups) to join. For unicast, 603 applications may often obtain addresses via DNS and a DNS-ALG. For 604 multicast, DNS is usually not used, and there are a wide range of 605 different ways applications learn addresses. It can be through 606 configuration or user input, it can be URLs on a web page, it can be 607 SDP files (via SAP or from web page or mail etc), or also via 608 protocols like RTSP/SIP. It is no easy task to handle all of these 609 possible methods using ALGs. 611 SDP is maybe the most common way for applications to learn which 612 multicast addresses (and other parameters) to use in order to receive 613 a multicast session. Inside the SDP files it is common to use 614 literal IP addresses, but it is also possible to specify domain 615 names. Applications would then query the DNS for the addresses, and 616 a DNS-ALG could perform the necessary translation. There is however 617 a problem with this. 619 Here is a typical SDP taken from RFC 2327: 621 v=0 622 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 623 s=SDP Seminar 624 i=A Seminar on the session description protocol 625 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 626 e=mjh@isi.edu (Mark Handley) 627 c=IN IP4 224.2.17.12/127 628 t=2873397496 2873404696 629 a=recvonly 630 m=audio 49170 RTP/AVP 0 631 m=video 51372 RTP/AVP 31 632 m=application 32416 udp wb 633 a=orient:portrait 635 The line of interest here is "c=IN IP4 224.2.17.12/127". It is legal 636 to use a domain name, this line would then become e.g. "c=IN IP4 637 mcast.example.com/127". The problem here is that the application is 638 told to use IPv4. It will expect the name to resolve to an IPv4 639 address, and may ignore any IPv6 replies. One could argue that it 640 would be incorrect to use IPv6, since IPv4 is specified. For DNS to 641 solve our problem, we would need a new IP neutral SDP syntax, and 642 applications would need to be updated to support it. 644 An alternative to rewriting addresses in the network is to make the 645 applications aware of the translation and mappings in use. One 646 approach could be for the source to create say SDP that includes both 647 the original and the translated addresses. This may require use of 648 techniques like CCAP [I-D.boucadair-mmusic-ccap] for specifying both 649 IPv4 and IPv6 multicast addresses, allowing the receiver to choose 650 which one to use. The other alternative would be for the receiving 651 application to be aware of the translation and the mapping in use. 652 This means that the receiving application can receive the original 653 SDP, but then apply the mapping to those addresses. 655 As we just discussed, it may be useful for applications to perform 656 the mappings. The next question is how they may learn those 657 mappings. The easiest would be if there was a standard way used for 658 all mappings, e.g. a well-known IPv6 prefix for embedding IPv4 659 addresses. But that does not work in all scenarios. There could be 660 a way for applications to learn which prefix to use, see 661 [I-D.wing-behave-learn-prefix]. But note that there may be different 662 multicast prefixes depending on whether we are doing SSM or ASM and 663 scope. In addition we need the unicast prefix for the multicast 664 source addresses. Alternatively one could imagine applications 665 requesting mappings for specific addresses on demand from the 666 translator. The translator could have static mappings, or install 667 mappings as requested by applications. 669 An alternative to making applications aware of the translation and 670 rewriting addresses as needed, could be to do translation in the API 671 or stack, so that e.g. an application joins an IPv4 group, the API or 672 stack rewrites that into IPv6 and sends the necessary MLD reports. 673 When IPv6 packets arrive, the API/stack can rewrite those packets 674 back to IPv4. This could allow legacy IPv4 applications to run on a 675 dual-stack node (or IPv6-only with translation in the API) to receive 676 IPv4 packets through an IPv6-only network. But in this case it might 677 be better to just use tunneling. 679 3.5. Further Work 681 There are some special cases and scenarios that should be added to 682 this document. One is addressing. Are there certain types of IPv6 683 multicast addresses that could make translation easier? What happens 684 if there are multiple translators? And also more details on 685 translation in the host, e.g. bump-in-the-stack or bump-in-the-API. 687 The document layout of the IPv4/IPv6 multicast translation should be 688 presented in this document. 690 4. IANA Considerations 692 This document requires no IANA assignments. 694 5. Security Considerations 696 This requires more thought, but the author is not aware of any 697 obvious security issues specific to multicast translation. 699 6. Acknowledgements 701 Dan Wing provided early feedback that helped shape this document. 702 Dave Thaler also provided good feedback that unfortunately still has 703 not been addressed in this document. See Section 3.5. 705 7. References 707 7.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 713 Translation - Protocol Translation (NAT-PT)", RFC 2766, 714 February 2000. 716 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 717 Address Translator - Protocol Translator (NAT-PT) to 718 Historic Status", RFC 4966, July 2007. 720 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 721 (ICE): A Protocol for Network Address Translator (NAT) 722 Traversal for Offer/Answer Protocols", RFC 5245, 723 April 2010. 725 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 726 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 727 October 2010. 729 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 730 IPv4/IPv6 Translation", RFC 6144, April 2011. 732 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 733 Algorithm", RFC 6145, April 2011. 735 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 736 NAT64: Network Address and Protocol Translation from IPv6 737 Clients to IPv4 Servers", RFC 6146, April 2011. 739 7.2. Informative References 741 [I-D.xli-behave-ivi] 742 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 743 CERNET IVI Translation Design and Deployment for the IPv4/ 744 IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 745 (work in progress), January 2010. 747 [I-D.venaas-behave-mcast46] 748 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 749 IPv4 - IPv6 multicast translator", 750 draft-venaas-behave-mcast46-02 (work in progress), 751 December 2010. 753 [I-D.wing-behave-learn-prefix] 754 Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ 755 IPv4 Translator", draft-wing-behave-learn-prefix-04 (work 756 in progress), October 2009. 758 [I-D.boucadair-mmusic-ccap] 759 Boucadair, M. and H. Kaplan, "Session Description Protocol 760 (SDP) Connectivity Capability (CCAP) Attribute", 761 draft-boucadair-mmusic-ccap-00 (work in progress), 762 July 2009. 764 Authors' Addresses 766 Stig Venaas 767 cisco Systems 768 Tasman Drive 769 San Jose, CA 95134 770 USA 772 Email: stig@cisco.com 774 Xing Li 775 CERNET Center/Tsinghua University 776 Room 225, Main Building, Tsinghua University 777 Beijing 100084 778 CN 780 Phone: +86 10-62785983 781 Email: xing@cernet.edu.cn 783 Congxiao Bao 784 CERNET Center/Tsinghua University 785 Room 225, Main Building, Tsinghua University 786 Beijing 100084 787 CN 789 Phone: +86 10-62785983 790 Email: congxiao@cernet.edu.cn