idnits 2.17.00 (12 Aug 2021) /tmp/idnits34953/draft-ietf-ngtrans-6to4-multicast-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == 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.) ** 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 134: '... MLD reports sent to a 6to4 relay MUST...' RFC 2119 keyword, line 140: '...periodic reports MUST be initialized t...' RFC 2119 keyword, line 145: '... local router, it SHOULD also function...' RFC 2119 keyword, line 182: '...gateway MUST determin an IPv4 unicast ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (29 June 2002) is 7259 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) ** Downref: Normative reference to an Informational RFC: RFC 2715 (ref. 'INTEROP') ** Obsolete normative reference: RFC 2893 (ref. 'MECH') (Obsoleted by RFC 4213) == Outdated reference: draft-ietf-ipngwg-uni-based-mcast has been published as RFC 3306 -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. 'ANYCAST') (Obsoleted by RFC 7526) == Outdated reference: draft-ietf-bgmp-spec has been published as RFC 3913 -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. 'PIMSM') (Obsoleted by RFC 4601, RFC 5059) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NGTrans Working Group Dave Thaler 3 INTERNET-DRAFT Microsoft 4 Expires December 2002 29 June 2002 6 Support for Multicast over 6to4 Networks 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Draft 6to4 Multicast June 2002 37 1. Abstract 39 6to4 Tunneling allows isolated IPv6 domains or hosts, attached to 40 an IPv4 network which has no native IPv6 support, to communicate 41 with other such IPv6 domains or hosts with minimal manual 42 configuration. This document defines support for IPv6 Multicast 43 over 6to4 networks. 45 2. Introduction 47 6to4 Tunneling [6TO4] allows isolated IPv6 domains or hosts, 48 attached to an IPv4 network which has no native IPv6 support, to 49 communicate with other such IPv6 domains or hosts with minimal 50 manual configuration. Effectively it treats the IPv4 network as a 51 link layer. Since [6TO4] does not define support for multicast, 52 the purpose of this document is to define such support. 54 Unlike [6OVER4], 6to4 does not assume the general availability of 55 wide-area IPv4 multicast. The 6to4 mechanism assumes only 56 unicast capability in its underlying IPv4 carrier network. As a 57 result, the IPv4 network appears as a large Non-Broadcast Multi- 58 Access (NBMA) link, over which we require the ability to 59 multicast. To do this, IPv6 multicast packets being sent to or 60 from a 6to4 router must be encapsulated in IPv4 unicast packets. 61 If the tree has multiple branches in the 6to4 address space, 6to4 62 encapsulation of the same multicast packet will take place 63 multiple times by necessity. 65 In this document, we refer to the device in a 6to4 site which has 66 a 6to4 pseudo-interface as a 6to4 "gateway". The gateway may 67 either be a host (if the site is just a single host), or a router 68 (if the site includes IPv6 links). We use the term "relay" as 69 defined in [6TO4]. 71 3. Overview 73 We assume each 6to4 gateway points an IPv6 default route at a 74 particular relay reachable across the IPv4 infrastructure. Each 75 relay, plus the set of all gateways (perhaps unknown to the relay) 76 using the relay, together can be thought of as being on a separate 77 NBMA link. 79 Draft 6to4 Multicast June 2002 81 All IPv6 multicast packets will be encapsulated in IPv4 unicast 82 packets over the logical NBMA link. This requires the 6to4 relay 83 to keep state for each gateway which has joined a particular 84 group. IPv6 multicast packets from the IPv6 native infrastructure 85 behind the relay will be sent to each gateway which has requested 86 them. 88 Since the number of gateways using a relay can be quite large, and 89 we expect that most sites will not want to receive most groups, an 90 explicit-joining protocol is required for gateways to communicate 91 group membership information to a relay. The two most likely 92 candidates are the Multicast Listener Discovery [MLD] protocol, 93 and the PIM-Sparse Mode [PIMSM] protocol. Since a 6to4 gateway 94 may be a host, and hosts typically do not implement routing 95 protocols, gateways will use MLD as described in Section 4 below. 96 This allows a host kernel to easily implement 6to4 gateway 97 behavior, and obviates the relay from the need to know whether a 98 given gateway is a host or a router. From the relay's 99 perspective, all gateways are indistinguishable from hosts on an 100 NBMA leaf network. 102 All IPv6 multicast packets sourced within the 6to4 site (and sent 103 to a scope larger than the 6to4 site) are forwarded by the 6to4 104 gateway to the relay over the 6to4 pseudo-interface, regardless of 105 whether any remote receivers exist. This is done so that the 106 gateway (which may be a host) need not be aware of external 107 membership information. 109 When a relay receives a multicast packet via 6to4 encapsulation, 110 it applies a Reverse-Path Forwarding check by dropping it unless 111 the source address is a 6to4 address. If it is not dropped, the 112 packet is forwarded to all other 6to4 gateways which have 113 requested it, in addition to being forwarded out any native IPv6 114 interfaces according to the rules of the multicast routing 115 protocol(s) running on the relay. When applying the rules for 116 multicast interoperability [INTEROP], the 6to4 link is treated 117 using the MLD equivalents of the rules for an IGMP-only link. 119 4. Multicast Listener Discovery 121 The MLD protocol usually operates by having the Querier multicast 122 an MLD Query message on the link. This behavior does not work on 123 NBMA links which do not support multicast. Since the set of 124 gateways is typically unknown to the relay (and potentially quite 125 Draft 6to4 Multicast June 2002 127 large), unicasting the queries is also impractical. The following 128 behavior is used instead. 130 The relay operates passively, sending no Queries but simply 131 tracking membership information according to Reports and Done 132 messages. To provide robustness, gateways unicast Reports to the 133 relay every [Query Interval] (defined as 125 in [MLD]) seconds. 134 The IPv6 source address of MLD reports sent to a 6to4 relay MUST 135 be a link-local address formed as specified in Section 3.7 of 136 [MECH]. 138 Reports are not relayed to other gateways by the 6to4 relay, and 139 no report suppression is done. As a result, the timer used to 140 send periodic reports MUST be initialized to a random value from 141 the interval [0, [Query Interval] ] before sending the first 142 periodic report, in order to prevent startup synchronization 143 (e.g., after a power outage). 145 If a gateway is serving as a local router, it SHOULD also function 146 as an "MLD Proxy". MLD Proxy behavior can be summarized as 147 follows. First, the gateway will serve as an MLD querier on its 148 private interface(s), and send MLD reports to the relay for groups 149 which are scoped larger than a site and have members present on 150 its private interface(s). Second, the gateway will forward 151 multicast packets received encapsulated from a relay to any 152 private interface with members present. 154 5. Scalability Considerations 156 The requirement that a relay keep group state per gateway that has 157 joined the group introduces potential scalability concerns. In 158 this section, we discuss how these concerns may be addressed. 160 Scalability of 6to4 can be achieved by adding more relays, and 161 using an appropriate relay discovery mechanism for gateways to 162 discover relays. Since there are non-multicast related reasons, 163 such as bandwidth bottlenecks at relays, to add more relays as 164 well, a detailed discussion of relay discovery is outside the 165 scope of this document. 167 There is, however, work in progress on this topic. One solution 168 is be to use a well-known DNS name, and have gateways periodically 169 (e.g. once a day) re-resolve the DNS name and update their relay's 170 address to use accordingly. A potentially better solution is to 171 Draft 6to4 Multicast June 2002 173 assign an IPv4 anycast address to relays (e.g., [ANYCAST]). 174 However, sending periodic MLD Reports to an anycast address can 175 cause duplicates. Specifically, if routing changes such that a 176 different relay receives a periodic MLD Report, both the new and 177 old relays will encapsulate data to the 6to4 site until the old 178 relay's state times out. This is obviously undesirable. 180 Hence, if a gateway is aware that a relay's IPv4 address is an 181 anycast address (such as because it is well-known), then the 182 gateway MUST determin an IPv4 unicast address of a relay and use 183 that instead for all MLD encapsulation. The recommended procedure 184 is that a gateway having an anycast address of a relay should send 185 an ICMPv4 Echo Request to the anycast address, and that relays 186 should respond with an Echo Reply from their unicast address 187 (since anycast addresses should not be used as source addresses). 188 These "pings" may be done periodically (e.g. once a day) to re- 189 resolve the unicast address of a close relay. 191 Since adding another relay has the result of adding another 192 independent NBMA link, this allows the gateways to be spread out 193 among more relays so as to keep the number of relays per gateway 194 at a reasonable level. 196 6. Supporting Multiple Relays in the Presence of RPF 198 A problem with the simple mechanisms described above can occur 199 when multiple relays exist, and a multicast routing protocol is 200 used that employs Reverse-Path Forwarding (RPF) checks against the 201 source address, such as occurs when [PIMSM] is used by the IPv6 202 infrastructure. Namely, if an IPv6 router on the path to a 203 receiver in the native IPv6 infrastructure expects to receive data 204 from a 6to4 site via the closest relay to the receiver, that relay 205 may not be the one to which the 6to4 site is encapsulating data, 206 and no data will be seen. 208 The solution specified by this document is that if a relay 209 receives an explicit join from the native IPv6 infrastructure, for 210 a given source and group pair where the source is a 6to4 address, 211 then the relay will periodically (using the same rules in Section 212 4) unicast an MLD report for the group to the 6to4 site gateway. 213 The 6to4 gateway must keep state per relay from which an MLD 214 Report has been sent, and in addition to forwarding multicast 215 traffic from the site to its relay of choice, traffic is also 216 Draft 6to4 Multicast June 2002 218 forwarded to all relays from which Reports have been received. 219 The choice of whether this state and replication is done at at the 220 link-layer (i.e., by the tunnel interface) or at the network-layer 221 is implementation-dependent. 223 The solution above will scale to an arbitrary number of relays, as 224 long at the number of relays requiring multicast traffic from a 225 given 6to4 site remains reasonable enough to not overly burden the 226 site gateway. (Note that bi-directional tree protocols such as 227 BGMP [BGMP] do not use RPF checks, and so would prevent the 228 problem from occurring to begin with.) 230 7. Supporting Site-Site Multicast 232 Since we require gateways to accept MLD unicast reports, as 233 described above, it is also possible to support multicast among 234 6to4 sites, without requiring assistance from any relays, in two 235 cases. 237 First, when a site gateway wants to join a given (source, group) 238 pair, where the source is another 6to4 address, then it 239 periodically unicast encapsulates an MLD Report to the site 240 gateway for the source. 242 The second case is when it wants to join a unicast-prefix-based 243 multicast addresses [UNIMCAST], and the unicast prefix embedded in 244 the multicast address is another site's 6to4 prefix. In this 245 case, it periodically unicast encapsulates an MLD Report to the 246 site gateway for that prefix. 248 For all other types of joins, the gateway periodically sends MLD 249 Reports to the relay, as discussed in section 4. 251 We note that this can result in a significant amount of state at a 252 site gateway sourcing multicast to a large number of other 6to4 253 sites. However, it is expected that this is not unreasonable for 254 two reasons. First, the 6to4 most likely does not have native 255 multicast connectivity (or else it could use 6over4 instead), and 256 as a result is likely doing unicast replication at present. The 257 amount of state is thus the same as what such a site already deals 258 with. Secondly, any site expecting to source traffic to a large 259 number of sites could get a point-to-point tunnel to the native 260 IPv6 infrastruction, and use that instead of 6to4. 262 Draft 6to4 Multicast June 2002 264 8. Security Considerations 266 The same security considerations and solutions discussed in [6TO4] 267 apply to multicast traffic. 269 9. Acknowledgements 271 The following individuals provided helpful discussion on the 272 mechanisms in this document: Rich Draves, Brian Zill, Steve 273 Deering, and Brian Carpenter. 275 10. Author's Address 277 Dave Thaler 278 Microsoft Corporation 279 One Microsoft Way 280 Redmond, WA 98052-6399 281 Phone: +1 425 703 8835 282 EMail: dthaler@microsoft.com 284 11. Normative References 286 [6TO4] 287 Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 288 IPv4 Clouds", RFC 3056, February 2001. 290 [INTEROP] 291 D. Thaler, "Interoperability Rules for Multicast Routing 292 Protocols", RFC 2715, October 1999. 294 [MECH] 295 Gilligan, R., and E. Nordmark, "Transition Mechanisms for 296 IPv6 Hosts and Routers", RFC 2893, August 2000. 298 [MLD] 299 Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 300 Discovery (MLD) for IPv6", RFC 2710, October 1999. 302 [UNIMCAST] 303 Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 304 Multicast Addresses", Work in progress, draft-ietf-ipngwg- 305 uni-based-mcast-03.txt, October 2001. 307 Draft 6to4 Multicast June 2002 309 12. Non-Normative References 311 [6OVER4] 312 Carpenter, B., and C. Jung, "Transmission of IPv6 over IPv4 313 Domains without Explicit Tunnels", RFC 2529, March 1999. 315 [ANYCAST] 316 C. Huitema, "An anycast prefix for 6to4 relay routers", RFC 317 3068, June 2001. 319 [BGMP] 320 D. Thaler, "Border Gateway Multicast Protocol (BGMP): 321 Protocol Specification", draft-ietf-bgmp-spec-03.txt, Work in 322 progress, June 2002. 324 [PIMSM] 325 Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S., 326 Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. 327 "Protocol Independent Multicast-Sparse Mode (PIM-SM): 328 Protocol Specification", RFC 2362, June 1998. 330 13. Full Copyright Statement 332 Copyright (C) The Internet Society (2002). All Rights Reserved. 334 This document and translations of it may be copied and furnished 335 to others, and derivative works that comment on or otherwise 336 explain it or assist in its implmentation may be prepared, copied, 337 published and distributed, in whole or in part, without 338 restriction of any kind, provided that the above copyright notice 339 and this paragraph are included on all such copies and derivative 340 works. However, this document itself may not be modified in any 341 way, such as by removing the copyright notice or references to the 342 Internet Society or other Internet organizations, except as needed 343 for the purpose of developing Internet standards in which case the 344 procedures for copyrights defined in the Internet Standards 345 process must be followed, or as required to translate it into 346 languages other than English. 348 The limited permissions granted above are perpetual and will not 349 be revoked by the Internet Society or its successors or assigns. 351 This document and the information contained herein is provided on 352 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 353 Draft 6to4 Multicast June 2002 355 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 356 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 357 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.