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