idnits 2.17.00 (12 Aug 2021) /tmp/idnits44208/draft-venaas-behave-mcast46-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '... MUST NOT be translated, since a CPE...' RFC 2119 keyword, line 307: '...for IGMP/MLD/PIM MUST be same as the o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 22, 2010) is 4161 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) ** Obsolete normative reference: RFC 4601 (ref. '3') (Obsoleted by RFC 7761) ** Downref: Normative reference to an Experimental RFC: RFC 3618 (ref. '5') Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 UNINETT 4 Intended status: Standards Track H. Asaeda 5 Expires: June 25, 2011 Keio University 6 S. SUZUKI 7 ALAXALA Networks Corporation 8 T. Fujisaki 9 NTT PF Lab 10 December 22, 2010 12 An IPv4 - IPv6 multicast translator 13 draft-venaas-behave-mcast46-02.txt 15 Abstract 17 This document describes an IPv4 - IPv6 translator device that embeds 18 all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts 19 to receive from and send to any IPv4 multicast group. This mechanism 20 can be also used to allow IPv4 hosts to receive from and send to a 21 subset of the IPv6 multicast groups. 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 June 25, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Address Translation . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Embedding IPv4 multicast addresses into IPv6 . . . . . . . 5 63 5.2. Translating IPv6 multicast addresses into IPv4 . . . . . . 6 64 5.3. Embedding IPv4 source addresses into IPv6 . . . . . . . . 7 65 5.4. Translating IPv6 source addresses into IPv4 . . . . . . . 7 66 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. IPv6 host joining a group inside the /96 prefix . . . . . 8 68 6.2. IPv6 host sending to group inside the /96 prefix . . . . . 8 69 6.3. IPv4 host joining an IPv4 group . . . . . . . . . . . . . 9 70 6.4. IPv4 host sending to a group a.b.c.d . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 IPv4 and IPv6 will co-exist for many years, possibly decades. There 81 are several solutions for how IPv4 and IPv6 hosts and networks can 82 inter-operate. This is usually easy if a host is dual-stack. If 83 however an IPv6-only host needs to communicate with an IPv4-only 84 host, then somewhere along the data path there must be some form of 85 translation. There are several ways of doing this for unicast, but 86 not much work has been done on multicast. 88 Here we describe a multicast translator solution. This translator 89 could be placed at the border between IPv6-only and IPv4-only 90 networks to allow multicast access between them, or it may also be 91 placed in a dual-stack network, where it can support hosts or other 92 networks that are IPv6-only or IPv4-only. The goal is to give an 93 IPv6 host full access to send to and receive from any IPv4 multicast 94 group by using the usual IPv6 multicast protocols and applications 95 which will then operate on the respective IPv6 groups. It should 96 also allow this for multiple hosts. Multiple IPv4 hosts should be 97 able to use a single IPv4 group, multiple IPv6 hosts a corresponding 98 IPv6 group, and all hosts should be able to send to and receive from 99 all the others. Similar to hosts using the same group from the same 100 address family. The translator solution should work with no changes 101 to other infrastructure. 103 We will define a one-to-one mapping of multicast IPv4 addresses onto 104 a subset of the IPv6 multicast addresses. An IPv6 host will then be 105 able to receive data from any IPv4 multicast group by joining the 106 corresponding IPv6 group. An IPv6 host can also send, without 107 necessarily joining, to any IPv4 multicast group by sending to the 108 corresponding IPv6 group. Some way of translating unicast addresses 109 is also needed to translate addresses of multicast sources. 111 The one-to-one mapping also allows an IPv4 host access to send to and 112 receive from the mapped IPv6 multicast groups. 114 2. Terminology 116 "IPV6_TRASM_ADDRESS" is an IPv6 ASM multicast address translated by 117 IPv4-IPv6 multicast translator. IPV6_TRASM_ADDRESS is one of the 118 addresss in one specific /96 IPv6 ASM (non-SSM) prefix 119 ("IPV6_TRASM_ADDRESS prefix"). Since this document assumes the 120 translator acts as an RP in IPv6 ASM, this prefix may be used with 121 embedded-RP and be included in FF70::/12 [1]. 123 "IPV6_TRSSM_ADDRESS" is an IPv6 SSM multicast address translated by 124 IPv4-IPv6 multicast translator. IPV6_TRSSM_ADDRESS is one of the 125 addresss in one specific /96 IPv6 SSM prefix ("IPV6_TRSSM_ADDRESS 126 prefix"). This prefix will be included in FF3x:0::/32 [2]. 128 "IPV4_SSM_ADDRESS" is an IPv4 SSM multicast address. 129 IPV4_SSM_ADDRESS is one of the addresses from the IPv4 SSM address 130 232/8 [2]. 132 "IPV4_ASM_ADDRESS" is an IPv4 ASM multicast address translated by 133 IPv4-IPv6 multicast translator. It can in principle be any IPv4 134 multicast address outside the SSM range 232/8. 136 A multicast translator attaches both IPv6-only and IPv4-only networks 137 with two different interfaces. In this document, each interface is 138 named "IF6" and "IF4". 140 3. Abbreviations 142 ASM Any Source Multicast 143 DR Designated Router 144 IGMP Internet Group Management Protocol 145 MLD Multicast Listener Discovery 146 MSDP Multicast Source Discovery Protocol 147 PIM-SM Protocol Independent Multicast - Sparse Mode 148 RP Rendezvous Point 149 RPF Reverse Path Forwarding 150 SSM Source-Specific Multicast 152 4. Architecture 154 PIM/MLD PIM/IGMP 155 *** *** *** *** join +----------+ join *** *** *** *** 156 * ** ** ** ----->| tr |-----> ** ** ** * 157 * IPv6 <=====| an |====== IPv4 * 158 * only data |IF6 sl IF4| data only * 159 * network =====>| at |=====> network * 160 * ** ** ** <-----| or |<---- ** ** ** * 161 *** *** *** **PIM/MLD+----------+PIM/IGMP *** *** *** 162 join join 164 We propose that the translator makes use of PIM-SM (Sparse Mode) [3] 165 for IPv6. For ASM it should then be the RP for the /96 IPv6 prefix 166 used for ASM, "IPV6_TRASM_ADDRESS prefix". This allows the 167 translator to know which IPv4 groups the IPv6 hosts join, and also to 168 learn of IPv6 sources for those groups. It is sufficient to support 169 MLD if there are no IPv6 PIM neighbors (e.g. a single link or MLD 170 proxies [4]). 172 When the translator receives a PIM or MLD join for an IPv6 group in 173 "IPV6_TRASM_ADDRESS prefix" on IF6, it will need to join the 174 corresponding IPv4 multicast group on IF4. It may behave as an IPv4 175 host and send an IGMP join for the correspondig IPv4 group, or it 176 might be an IPv4 PIM router and send an IPv4 PIM join. 178 If the translator learns of an IPv6 source for an 179 "IPV6_TRASM_ADDRESS" it needs to receive the data on IF6, and send 180 the translated data out on IF4. If the translator is an IPv6 RP, it 181 may receive IPv6 PIM. As a regular IPv6 RP, it may then join towards 182 the source to receive packets natively on IF6. It may also be a 183 directly connected source or a source behind an MLD proxy [4], in 184 that case packets are also received on IF6. If the translator 185 behaves as an IPv4 host, it sends any such IPv6 packets out on IF4. 187 One can improve on this by making the translator behave as an IPv4 188 RP, or be an IPv4 PIM router running MSDP [5] to exchange information 189 about active IPv4 sources. The translator can then use MSDP to 190 signal its active IPv4 sources (that may be translated IPv6 sources) 191 so that it will receive PIM joins if there are IPv4 receivers for the 192 groups. It can also use MSDP to see if there are IPv4 sources for 193 IPv4 groups that IPv6 hosts have joined. 195 Note that for SSM this is much simpler with no RP nor MSDP involved. 196 It may still be an advantage to act as an IPv4 PIM router, in order 197 to only do translation from IPv6 to IPv4 when there are IPv4 198 listeners. 200 5. Address Translation 202 When IPv4 packets are resent as IPv6 we will need to replace the 203 source and destination addresses with suitable IPv6 addresses. And 204 similar replacement going from IPv6 to IPv4. The source addresses 205 are always unicast addresses, and the destination addresses are 206 always multicast addresses. 208 5.1. Embedding IPv4 multicast addresses into IPv6 210 We need a way of referring to an IPv4 multicast group using an IPv6 211 address. IPv4 multicast addresses are embedded into IPv6 by simply 212 prepending them with a specific /96 IPv6 prefix such that for each 213 IPv4 multicast address we have a respective IPv6 multicast address. 215 However, both IPv4 and IPv6 have special ranges for SSM usage, and 216 one might want to take scoping into account. 218 This document proposes the use of one specific /96 IPv6 SSM prefix 219 (IPV6_TRSSM_ADDRESS prefix) for all IPv4 SSM addresses, and one 220 specific /96 IPv6 ASM (non-SSM) prefix (IPV6_TRASM_ADDRESS prefix) 221 for all IPv4 ASM (non-SSM) addresses. Hence IPv4 multicast addresses 222 are embedded into IPv6 by appending them with a /96 223 IPV6_TRSSM_ADDRESS prefix if the IPv4 multicast addresses are in the 224 IPV4_SSM_ADDRESS range, or with a /96 IPV6_TRASM_ADDRESS prefix if 225 they are in the IPV4_ASM_ADDRESS range. 227 An administrator may choose the exact prefixes used, and depending on 228 the prefix, also which IPv6 scope. The prefix must be in accordance 229 with the IPv6 multicast address format defined in section 2.7 of [6]. 230 The addresses used will then be of the form FFxx:: where 231 flags, scope and the value of "blah" are chosen by the administrator. 232 "IPv4" is the last 32 bits specifying the IPv4 address of the IPv4 233 multicast group. For ASM it may be useful to use an Embedded-RP [1] 234 prefix based on an IPv6 unicast address of the translator. 236 Note that as specified in [7] the IPv4 address will become the Group 237 ID, and since all IPv4 multicast addresses have the leading bit set, 238 the IPv6 multicast addresses will become "server allocated" 239 addresses. We can regard the translator as the "allocation server". 241 The unicast addresses of multicast sources also need to be 242 translated. We recommend embedding all IPv4 unicast addresses into a 243 /96 IPv6 prefix. This allows different IPv4 unicast addresses to be 244 mapped to different IPv6 unicast addresses, and for IPv6 SSM joins to 245 address specific IPv4 SSM sources. Note that for ASM use, it may be 246 sufficient to map all IPv4 sources to one single IPv6 address. For 247 translating IPv6 sources into IPv4 sources, one may use a single 248 address, or a pool of IPv4 addresses. The same IPv4 address may need 249 to be re-used for different IPv6 sources. If the translator also 250 translates unicast packets, then it should use the same unicast 251 translation mechanism for source addresses in multicast packets. Due 252 to multicast RPF checks, the IPv4 and IPv6 unicast addresses used 253 need to be routed towards the translator. 255 5.2. Translating IPv6 multicast addresses into IPv4 257 For the multicast address translation from IPv6 to IPv4, we simply 258 extract the last 32 bits. However, if the IPv6 multicast address is 259 not in the range of either IPV6_TRSSM_ADDRESS or IPV6_TRASM_ADDRESS 260 range, IPv4 hosts cannot join the multicast whose destination address 261 is not in these address ranges. Therefore the translator does not 262 translate and does not forward such data from the interface IF4. 264 The translator can be implemented on a host (bumped into a stack), or 265 a layer 3 device. In the latter case, link-local multicast addresses 266 MUST NOT be translated, since a CPE has to treat IPv4 link-local 267 scope and IPv6 link-local scope as different ones. (Please note that 268 this is specific to an IGMP/MLD-based translator, since PIM does not 269 generate a join for link-local multicast addresses.) 271 5.3. Embedding IPv4 source addresses into IPv6 273 Unicast addresses of multicast sources also need to be translated. 274 An IPv4 unicast address of a multicast source is embedded into a /96 275 IPv6 unicast prefix. The /96 IPv6 unicast prefix will be prepared as 276 the address pool of the translator. It will be same or part of the 277 unicast prefix assigned at the translator's IF6. This allows PIM 278 join messages to be forwarded to the translator, and also enables 279 IPv6 SSM joins to be translated to IPv4 SSM joins. 281 One could consider using just a single IPv6 unicast address for all 282 IPv4 multicast translated into IPv6. For ASM use, it may be 283 sufficient to map all IPv4 sources to one single IPv6 address, and 284 this single IPv6 address can be the translator's IPv6 global unicast 285 address assigned on IF6, because this document assumes that the 286 translator acts as an RP for IPv6 PIM. On the other hand, for SSM, 287 each IPv6 SSM join should be translated to uniquely specify a 288 corresponding IPv4 SSM join. In order to do this, the simplest way 289 is that an IPv4 unicast address of a multicast source is embedded 290 into a /96 IPv6 unicast prefix the translator prepared. 292 An alternative to using a /96 IPv6 unicast prefix could also be to 293 dynamically allocate IPv6 unicast addresses from a pool, see [8]. 295 5.4. Translating IPv6 source addresses into IPv4 297 For translating IPv6 sources into IPv4 sources, one may use a single 298 address, or a pool of IPv4 addresses. The same IPv4 address may need 299 to be re-used for different IPv6 sources. If the translator also 300 translates unicast packets, then it should use the same unicast 301 translation mechanism for source addresses in multicast packets. 303 If unicast traffic is translated, then similar translation should be 304 used for the multicast source addresses. Note that for RTP the 305 application can know the real source and tell streams apart, even if 306 they are translated into the same multicast source address. The 307 translation mechanism for IGMP/MLD/PIM MUST be same as the one for 308 the multicast data. 310 6. Examples 312 To illustrate how the translator works, we will look at some 313 examples. In all the examples we assume that there is no previous 314 state in the translator. 316 6.1. IPv6 host joining a group inside the /96 prefix 318 An IPv6 host joins the group FFxx::a.b.c.d. If the translator 319 is the DR for the host, it will receive an MLD membership report. If 320 not, it will receive a PIM join since it is the RP for the group. 321 The translator checks whether the address is inside the /96 prefix, 322 and whether the last 32 bits (a.b.c.d) is an IPv4 multicast address. 323 If it is, it joins a.b.c.d using IGMP or PIM, and stays joined as 324 long as there are IPv6 receivers. 326 For SSM the translator would in addition check if the source in the 327 join is inside the /96 unicast prefix used. If this is the case, it 328 then uses the last 32 bits as the IPv4 source. It can then do a 329 source-specific IPv4 join. 331 When the translator receives a multicast packet for a.b.c.d it 332 prepends the /96 prefix to form the IPv6 address FFxx::a.b.c.d. 333 If the translator has outgoing interfaces for this group, it will 334 send an IPv6 packet to the same interfaces to which it would have 335 forwarded an IPv6 packet for the group. The destination address will 336 be FFxx::a.b.c.d, and the source address will be computed using 337 the /96 unicast prefix. For SSM, the translator would also check 338 that it got an outgoing interface for the specific source. 340 6.2. IPv6 host sending to group inside the /96 prefix 342 An IPv6 host sends to the group FFxx::a.b.c.d. If the 343 translator is the DR for the host, it will receive the data natively. 344 If not, it will receive PIM register messages containing the data 345 since it is the RP. For each packet received, either natively or 346 inside register messages, it will first check that the destination 347 address is inside the /96 prefix and that the last 32 bits (a.b.c.d) 348 is an IPv4 multicast address. If this is okay, it will resend the 349 packet to the IPv4 address a.b.c.d. The source address would be 350 chosen from a given pool of IPv4 unicast addresses (this may just be 351 a single fixed address). 353 If the translator is also an IPv4 PIM router, then we do some further 354 steps. For ASM, if the translator is an RP and uses MSDP, it should 355 announce the translated source in MSDP, and only forward translated 356 packets if it has a join for the group. For SSM, it should only 357 forward translated packets if it has a join for the specific source 358 and group. 360 6.3. IPv4 host joining an IPv4 group 362 In some cases, ISP network supports IPv6-multicast, but a host or an 363 application only supports IPv4-multicast. IGMP/MLD-proxy based 364 translator helps such case by accommodating such hosts. (IGMP/ 365 PIM-based translator would also work, but it is not described here 366 since the behavior is almost same as Section 6.1 and Section 6.2.) 368 We have mapped IPv4 multicast groups to a subset of the IPv6 369 multicast groups by embedding them in /96 IPv6 prefixes. Typically 370 one prefix for ASM and one for SSM. An IPv4 host joins to the group 371 a.b.c.d, and the translator will receive the IGMP join and resend an 372 MLD join for FFxx:::a.b.c.d to IF6. When an MLD query arrives 373 from IF6, the translator replies with MLD reports based on the IGMP 374 membership database (a.b.c.d) and the /96 prefix (FFxx:::). 376 In case of SSM, the translator in addition synthesizes an IPv6 source 377 address from the IPv4 source address in the IGMP join (see 378 Section 5.3), and resends a source-specific MLD join for the 379 synthesized IPv6 address. 381 When the translator receives an IPv6 multicast packet, it checks 382 whether the group address is inside the /96 prefix, and whether the 383 last 32bits (a.b.c.d) is an IPv4 multicast address. If both hold 384 true and a.b.c.d exists in the IGMP membership database, the 385 translator will convert the received IPv6 packet into IPv4 and send 386 it for the IF4 interfaces where a.b.c.d is subscribed. The source 387 address of the IPv4 packet is synthesised as in Section 5.4, and its 388 destination address is a.b.c.d. 390 6.4. IPv4 host sending to a group a.b.c.d 392 When the translator receives a packet for a.b.c.d and it is also a DR 393 for the host, it will convert the received IPv4 packet into IPv6 and 394 send it to IF6. The source and destination address of the IPv6 395 packet is synthesized as in Section 5.3 and Section 5.1, 396 respectively. 398 7. Acknowledgments 400 The authors thank Michal Przybylski and Pekka Savola for valuable 401 comments, and also people from the M6Bone community for testing a 402 prototype implementation. Also thanks to Teemu Kiviniemi who has 403 implemented and deployed a second translator implementation based on 404 this document. 406 8. Security Considerations 408 When using such a translator one needs to take some care of scoping 409 and TTL values. Due to differences in IPv4 and IPv6 scoping, a 410 narrow scope might be translated into a wider one. 412 One may wish to limit who can access the translator. If for instance 413 one wishes to restrict it to a site, one can use a /96 prefix of 414 site-local scope, and then filter at the site border, just like one 415 would for multicast in general. A translator implementation could 416 also offer a way of restricting which groups and sources should be 417 accepted. 419 9. References 421 9.1. Normative References 423 [1] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) 424 Address in an IPv6 Multicast Address", RFC 3956, November 2004. 426 [2] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 427 RFC 4607, August 2006. 429 [3] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 430 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 431 Specification (Revised)", RFC 4601, August 2006. 433 [4] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 434 Group Management Protocol (IGMP) / Multicast Listener Discovery 435 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 436 RFC 4605, August 2006. 438 [5] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 439 (MSDP)", RFC 3618, October 2003. 441 [6] Hinden, R. and S. Deering, "IP Version 6 Addressing 442 Architecture", RFC 4291, February 2006. 444 [7] Haberman, B., "Allocation Guidelines for IPv6 Multicast 445 Addresses", RFC 3307, August 2002. 447 9.2. Informative References 449 [8] Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An IPv6/ 450 IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)", 451 draft-tsuchiya-mtp-01 (work in progress), February 2003. 453 Authors' Addresses 455 Stig Venaas 456 UNINETT 457 Trondheim NO-7465 458 Norway 460 Email: venaas@uninett.no 462 Hitoshi Asaeda 463 Keio University 464 Graduate School of Media and Governance 465 5322 Endo 466 Fujisawa, Kanagawa 252-8520 467 Japan 469 Email: asaeda@wide.ad.jp 471 Shinsuke SUZUKI 472 ALAXALA Networks Corporation 473 Shinkawasaki Mitsui Bldg. 474 890 Kashimada 475 Saiwai-ku, Kawasaki, Kanagawa 212-0058 476 Japan 478 Email: suz@alaxala.net 480 Tomohiro Fujisaki 481 NTT PF Lab 482 3-9-11 Midori-Cho 483 Musashino-shi, Tokyo 180-8585 484 Japan 486 Email: fujisaki@nttv6.net