idnits 2.17.00 (12 Aug 2021) /tmp/idnits53707/draft-venaas-mboned-v4v6mcastgw-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7028 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 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2362 (ref. 'PIM-SM') (Obsoleted by RFC 4601, RFC 5059) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Venaas 3 Internet Draft UNINETT 4 Expiration Date: August 2003 5 February 2003 7 An IPv4 - IPv6 multicast gateway 9 draft-venaas-mboned-v4v6mcastgw-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes an IPv4 - IPv6 gateway solution that embeds 35 all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts 36 to receive from and send to IPv4 multicast groups. 38 Table of Contents 40 1. Introduction ............................................... 2 41 2. Embedding IPv4 multicast group addresses into IPv6 ......... 3 42 3. Architecture ............................................... 3 43 4. Address rewriting .......................................... 4 44 5. Examples ................................................... 4 45 5.1. IPv6 host joining a group inside the /96 prefix ........ 4 46 5.2. IPv6 host sending to group inside the /96 prefix ....... 5 47 6. Issues ..................................................... 5 48 7. Acknowledgments ............................................ 5 49 8. Security Considerations .................................... 5 50 9. References ................................................. 6 51 9.1. Normative References ................................... 6 52 9.2. Informative References ................................. 6 53 Author's Address ............................................... 6 54 Appendix A: Source addressing issues ........................... 6 55 Appendix B: Possible enhancements .............................. 7 56 Appendix C: Comparison with MTP ................................ 7 58 1. Introduction 60 IPv4 and IPv6 will co-exist for many years, possibly decades. There 61 are several solutions for how IPv4 and IPv6 hosts and networks can 62 inter-operate. This is usually easy if a host is dual stack. If 63 however an IPv6-only host needs to communicate with an IPv4-only 64 host, then somewhere along the data path there must be some form of 65 translation. There are several ways of doing this for unicast, while 66 for multicast the only mechanism known to the author is [MTP]. 68 Here we describe a possible multicast gateway solution. This gateway 69 could be placed at the border between IPv6-only and IPv4-only 70 networks to allow multicast access between them. The goal is to give 71 an IPv6 host full access to send to and receive from any IPv4 72 multicast group by using the usual IPv6 multicast protocols and 73 applications which will then operate on the respective IPv6 groups. 74 The gateway solution can be used with no changes to other 75 infrastructure. 77 We will define a one-to-one mapping of IPv4 addresses onto a subset 78 of the IPv6 multicast addresses. An IPv6 host will then be able to 79 receive data from any IPv4 multicast group by joining the 80 corresponding IPv6 group. An IPv6 host can also send, without 81 necessarily joining, to any IPv4 multicast group by sending to the 82 corresponding IPv6 group. 84 2. Embedding IPv4 multicast group addresses into IPv6 86 We need a way of referring to an IPv4 multicast group using an IPv6 87 address. We do this by embedding IPv4 multicast addresses into IPv6 88 by prepending them with a specific /96 IPv6 prefix such that for each 89 IPv4 multicast address we have a respective IPv6 multicast address. 90 Depending on the prefix they might be of any scope desired. 92 An administrator deploying a gateway needs to choose a /96 prefix in 93 accordance with the IPv6 multicast address format defined in section 94 2.7 of [ADDRARCH]. 96 The addresses used will then be of the form FFxx:: where 97 flags, scope and the value of "blah" are chosen by the administrator. 98 "IPv4" is the last 32 bits specifying the IPv4 address of the IPv4 99 multicast group. The administrator may choose to use Unicast-Prefix- 100 based multicast addresses as defined in [UNIPRFXM]. 102 3. Architecture 104 The gateway makes use of PIM Sparse Mode [PIM-SM]. It is a complete 105 IPv6 PIM-SM router that also is the RP for the /96 IPv6 prefix. With 106 respect to the IPv4 network, it behaves as an IPv4 multicast host. 107 When it receives a PIM join message for a new IPv6 group inside the 108 /96 prefix, it will join the IPv4 multicast group specified by the 109 last 32 bits in the address. It should also do this if it gets MLD 110 listener reports for such groups on links where it is the DR. 112 When an IPv6 source starts sending, the data will reach the gateway. 113 If the gateway is the DR for the source, it will receive the packets 114 natively and resend them as IPv4 multicast provided that the 115 multicast address is within the /96 prefix, and the last 32 bits form 116 a valid IPv4 multicast address. If the gateway is not the DR, then it 117 will receive PIM register messages. Again if the multicast address 118 fulfills the requirements above, the multicast packets are resent as 119 IPv4 multicast. When receiving register messages, it may, according 120 to normal PIM behaviour, join the IPv6 group to receive packets 121 natively instead. These packets are also resent. 123 Note that by being the Rendezvous Point, it can keep track of all 124 IPv6 sources and receive all their data. And it will also know which 125 groups there are listeners for. It does not however, have knowledge 126 of IPv4 sources and listeners. A drawback with this, is that it will 127 resend IPv6 data even if there are no IPv4 listeners, and it will 128 also join and wait for IPv4 data even if there are no sources. 130 4. Address rewriting 132 When IPv4 packets are resent as IPv6 we will need to replace the 133 source and destination addresses with suitable IPv6 addresses. And 134 similar replacement going from IPv6 to IPv4. 136 The destination address is easy. That is the multicast address. As 137 described above, we map IPv4 multicast addresses into IPv6 by 138 prepending them with a /96-prefix. And going the other direction, we 139 simply extract the last 32 bits. 141 For the source address we propose using one fixed IPv4 unicast 142 address, and one fixed IPv6 unicast address. There are no special 143 requirements, they might be any unicast addresses assigned to the 144 router. From the perspective of an IPv6 receiver, the gateway will 145 look like the source of all data resent from IPv4. Similarly in the 146 other direction. 148 5. Examples 150 To illustrate how the gateway works, we will look at two examples. In 151 both examples we assume that there are no previous state in the 152 gateway. 154 5.1. IPv6 host joining a group inside the /96 prefix 156 An IPv6 host joins the group FFxx::a.b.c.d. If the gateway is 157 the DR for the host, it will receive an MLD membership report. If 158 not, it will receive a PIM join since it is the RP for the group. The 159 gateway will then get (*, G) state for the group. So far this is 160 normal PIM behaviour. The gateway checks whether the address is 161 inside the /96 prefix, and whether the last 32 bits (a.b.c.d) is an 162 IPv4 multicast address. If it is, it joins a.b.c.d using IGMP, and 163 stays joined as long as it has state for the group. 165 When the gateway receives a multicast packet for a.b.c.d it prepends 166 the /96 prefix to form the IPv6 address FFxx::a.b.c.d. If the 167 gateway has outgoing interfaces for this group, it will send an IPv6 168 packet to the same interfaces to which it would have forwarded an 169 IPv6 packet for the group. The destination address will be 170 FFxx::a.b.c.d, and the source address will be the fixed IPv6 171 unicast address used for all resent packets. 173 5.2. IPv6 host sending to group inside the /96 prefix 175 An IPv6 host sends to the group FFxx::a.b.c.d. If the gateway 176 is the DR for the host, it will receive the data natively. If not, it 177 will receive PIM register messages containing the data since it's the 178 RP. For each packet received, either natively or inside register 179 messages, it will first check that the destination address is inside 180 the /96 prefix and that the last 32 bits (a.b.c.d) is an IPv4 181 multicast address. If this is okay, it will resend the packet to the 182 IPv4 address a.b.c.d. The source address is the fixed IPv4 unicast 183 address used for all resent packets. 185 6. Issues 187 The gateway should work well for most multicast protocols and 188 applications. Since addresses are rewritten, there might, as with 189 [NAT-PT], be problems with application protocols carrying IP 190 addresses though. There might also be issues with using the same IP 191 source address when resending packets from different sources, see 192 appendix A. 194 7. Acknowledgments 196 The author wishes to thank Michal Przybylski and Pekka Savola for 197 valuable comments, and also people from the M6Bone community for 198 testing a prototype implementation. 200 8. Security Considerations 202 The gateway as specified in this document does not take scoping into 203 account. Hence there is a danger that multicast content that is 204 supposed to be available only in a small scope on one side of the 205 gateway, becomes available in a larger scope on the other side. The 206 gateway could possibly try to translate IPv6 scopes into IPv4 ttl 207 values and vice versa. In order to support multiple scopes one would 208 then use multiple /96 multicast prefixes. 210 One may wish to limit who can access the gateway. If for instance one 211 wishes to restrict it to a site, one can use a /96 prefix of site- 212 local scope, and then filter at the site border, just like one would 213 for multicast in general. A gateway implementation could also offer a 214 way of restricting which groups and sources should be accepted. 216 9. References 218 9.1. Normative References 220 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 221 Architecture", RFC 2373, July 1998. 223 [UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 224 Multicast Addresses", RFC 3306, August 2002. 226 [PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., 227 Deering, S., Handley, M., Jacobson, V., Liu, C., 228 Sharma, P. and L. Wei, "Protocol Independent 229 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 230 RFC 2362, June 1998. 232 9.2. Informative References 234 [MTP] Tsuchiya, K., Higuchi, H., Sawada, S., Nozaki, S., 235 "An IPv6/IPv4 Multicast Translator based on IGMP/MLD 236 Proxying (mtp)", work-in-progress, 237 draft-ietf-ngtrans-mtp-03.txt, October 2002. 239 [NAT-PT] Tsirtsis, G., Srisuresh, P., "Network Address 240 Translation - Protocol Translation (NAT-PT)", RFC 2766, 241 February 2000. 243 Author's Address 245 Stig Venaas 246 UNINETT 247 Trondheim, Norway 248 Email: venaas@uninett.no 250 Appendix A: Source addressing issues 252 As specified above, we use one fixed IPv4 unicast address and one 253 fixed IPv6 unicast address for all multicast packets resent by the 254 gateway. This works fine for common mbone tools like vic and rat. It 255 may cause problems for some applications though. If there are 256 multiple sources sending to the same group on one side of the 257 gateway, an application running on a host on the other side may be 258 unable to know which packets come from which source. 260 The idea is that for packets with different source addresses on one 261 side of the gateway, there should also be different source addresses 262 on the other side. This can be done by rewriting these unicast 263 address like one would do for [NAT-PT]. Rewriting IPv4 into IPv6 is 264 simple, we can use the same trick as for multicast and use a /96 265 prefix. Note that this must be different from the prefix used for 266 multicast since the first bits are different in unicast and multicast 267 addresses. Going from IPv6 to IPv4 we have a much bigger problem. We 268 suggest using a pool of IPv4 addresses being dynamically allocated to 269 the different IPv6 sources. If the total amount of IPv6 sources is 270 larger than the number of addresses in the pool, one might reuse 271 addresses between groups, so that the size of the pool would only 272 need to be as large as the largest number of sources in each group. 273 Note that these unicast addresses are only used by the gateway as 274 source addresses, but they must still have valid routes for PIM with 275 its RPF checks to work. 277 Appendix B: Possible enhancements 279 The main draft documents what we see as a complete working gateway 280 solution. There are however several enhancements possible. 282 As specified, the gateway operates as an IPv4 host using IGMP. One 283 could possibly let the gateway be an IPv4 PIM router. It could then 284 stop sending IPv4 packets if it receives register stop messages from 285 the RP. When it receives register stop messages, it could itself 286 send register stop messages for IPv6 sources. 288 One could possibly add SSM support. One might consider using SSM to 289 reach the gateway, and not necessarily let it be an RP. One could 290 also allow IPv6 hosts to join specific IPv4 sources, by using some 291 /96 IPv6 unicast prefix to embed IPv4 addresses into IPv6. In the 292 first case we go from IPv6 SSM to IPv4 ASM. In the second we go from 293 IPv6 SSM to IPv4 SSM. 295 Appendix C: Comparison with MTP 297 The gateway solution described in this draft has some resemblance to 298 [MTP]. They both try to offer multicast connectivity between 299 IPv4-only and IPv6-only hosts with some sort of translation device 300 placed at the border between the IPv4 and IPv6 domains. 302 The main difference between the two is perhaps that MTP only operates 303 at the IGMP and MLD level. This solution uses standard PIM and MLD 304 mechanisms to know which groups to resend, while MTP as specified, 305 requires an administrator to configure which groups to resend. This 306 might limit the number of groups that can be resent, and there is a 307 risk that one keeps resending data when there are no receivers 308 present. MTP might be used together with some out-of-band mechanism 309 for the user or application to signal interest, this will however 310 make the solution less transparent to the users, or require software 311 modifications.