idnits 2.17.1 draft-thaler-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 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 138: '... MLD reports sent to a 6to4 relay MUST...' RFC 2119 keyword, line 144: '...periodic reports MUST be initialized t...' RFC 2119 keyword, line 149: '... local router, it SHOULD also function...' RFC 2119 keyword, line 167: '...to use a relay, it is RECOMMENDED that...' 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 (14 July 2000) is 8679 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 (-07) exists of draft-ietf-ngtrans-6to4-06 == Outdated reference: A later version (-06) exists of draft-ietf-bgmp-spec-01 ** Downref: Normative reference to an Historic draft: draft-ietf-bgmp-spec (ref. 'BGMP') ** Downref: Normative reference to an Informational RFC: RFC 2715 (ref. 'INTEROP') -- Possible downref: Non-RFC (?) normative reference: ref. 'MECH' ** Obsolete normative reference: RFC 2362 (ref. 'PIMSM') (Obsoleted by RFC 4601, RFC 5059) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 January 2001 14 July 2000 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 (2000). All Rights Reserved. 35 Draft 6to4 Multicast July 2000 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. This 75 document only defines support for multicast when such a relay 76 exists. Support for multicast among clouds of 6to4 sites with no 77 default route is outside the scope of this document. 79 Draft 6to4 Multicast July 2000 81 Each relay, plus the set of all gateways (perhaps unknown to the 82 relay) using the relay, together are treated as being on a 83 separate NBMA link. 85 All IPv6 multicast packets will be encapsulated in IPv4 unicast 86 packets over the logical NBMA link. This requires the 6to4 relay 87 to keep state for each gateway which has joined a particular 88 group. IPv6 multicast packets from the IPv6 native infrastructure 89 behind the relay will be sent to each gateway which has requested 90 them. 92 Since the number of gateways using a relay can be quite large, and 93 we expect that most sites will not want to receive most groups, an 94 explicit-joining protocol is required for gateways to communicate 95 group membership information to a relay. The two most likely 96 candidates are the Multicast Listener Discovery [MLD] protocol, 97 and the PIM-Sparse Mode [PIMSM] protocol. Since a 6to4 gateway 98 may be a host, and hosts typically do not implement routing 99 protocols, gateways will use MLD as described in Section 4 below. 100 This allows a host kernel to easily implement 6to4 gateway 101 behavior, and obviates the relay from the need to know whether a 102 given gateway is a host or a router. From the relay's 103 perspective, all gateways are indistinguishable from hosts on an 104 NBMA leaf network. 106 All IPv6 multicast packets sourced within the 6to4 site (and sent 107 to a scope larger than the 6to4 site) are forwarded by the 6to4 108 gateway to the relay over the 6to4 pseudo-interface, regardless of 109 whether any remote receivers exist. This is done so that the 110 gateway (which may be a host) need not be aware of external 111 membership information. 113 When a relay receives a multicast packet over the 6to4 pseudo- 114 interface, it applies a Reverse-Path Forwarding check by dropping 115 it unless the source address is a 6to4 address. If it is not 116 dropped, the packet is forwarded to all other 6to4 gateways which 117 have requested it, in addition to being forwarded out any native 118 IPv6 interfaces according to the rules of the multicast routing 119 protocol(s) running on the relay. When applying the rules for 120 multicast interoperability [INTEROP], the 6to4 link is treated 121 using the MLD equivalents of the rules for an IGMP-only link. 123 Draft 6to4 Multicast July 2000 125 4. Multicast Listener Discovery 127 The MLD protocol usually operates by having the Querier multicast 128 an MLD Query message on the link. This behavior does not work on 129 NBMA links which do not support multicast. Since the set of 130 gateways is typically unknown to the relay (and potentially quite 131 large), unicasting the queries is also impractical. The following 132 behavior is used instead. 134 The relay operates passively, sending no Queries but simply 135 tracking membership information according to Reports and Done 136 messages. To provide robustness, gateways unicast Reports to the 137 relay every [Query Interval] (defined as 125 in [MLD]) seconds. 138 The IPv6 source address of MLD reports sent to a 6to4 relay MUST 139 be a link-local address formed as specified in Section 3.7 of 140 [MECH]. 142 Reports are not relayed to other gateways by the 6to4 relay, and 143 no report suppression is done. As a result, the timer used to 144 send periodic reports MUST be initialized to a random value from 145 the interval [0, [Query Interval] ] before sending the first 146 periodic report, in order to prevent startup synchronization 147 (e.g., after a power outage). 149 If a gateway is serving as a local router, it SHOULD also function 150 as an "MLD Proxy". MLD Proxy behavior can be summarized as 151 follows. First, the gateway will serve as an MLD querier on its 152 private interface(s), and send MLD reports to the relay for groups 153 which are scoped larger than a site and have members present on 154 its private interface(s). Second, the gateway will forward 155 multicast packets received encapsulated from a relay to any 156 private interface with members present. 158 5. Scalability Considerations 160 The requirement that a relay keep group state per gateway that has 161 joined the group introduces potential scalability concerns. In 162 this section, we discuss how these concerns may be addressed. 163 Note that there may be non-multicast related reasons, such as 164 bandwidth bottlenecks at relays, to do the behavior recommended 165 here as well. 167 When configuring gateways to use a relay, it is RECOMMENDED that 168 gateways should be configured with a DNS name rather than an IPv4 169 Draft 6to4 Multicast July 2000 171 address of the relay. This allows the relay owners to easily add 172 more relays by having the same DNS name resolve to the IPv4 173 addresses of multiple relays. Since adding another relay has the 174 result of adding another independent NBMA link, this allows the 175 gateways to be spread out among more relays so as to keep the 176 number of relays per gateway at a reasonable level. Gateways 177 SHOULD periodically (e.g., once a day) re-resolve the DNS name and 178 update the relay's address to use accordingly. 180 6. Supporting Multiple Relays in the Presence of RPF 182 A problem with the simple mechanisms described above can occur 183 when multiple relays exist, and a multicast routing protocol is 184 used that employs Reverse-Path Forwarding (RPF) checks against the 185 source address, such as occurs when [PIMSM] is used by the IPv6 186 infrastructure. Namely, if an IPv6 router on the path to a 187 receiver in the native IPv6 infrastructure expects to receive data 188 from a 6to4 site via the closest relay to the receiver, that relay 189 may not be the one to which the 6to4 site is encapsulating data, 190 and no data will be seen. 192 The solution specified by this document is that if a relay 193 receives an explicit join from the native IPv6 infrastructure, for 194 a given source and group pair where the source is a 6to4 address, 195 then the relay will periodically (using the same rules in Section 196 4) unicast an MLD report for the group to the 6to4 site gateway. 197 The 6to4 gateway must keep state per relay from which an MLD 198 Report has been sent, and in addition to forwarding multicast 199 traffic from the site to its relay of choice, traffic is also 200 forwarded to all relays from which Reports have been received. 202 The solution above will scale to an arbitrary number of relays, as 203 long at the number of relays requiring multicast traffic from a 204 given 6to4 site remains reasonable enough to not overly burden the 205 site gateway. (Note that bi-directional tree protocols such as 206 BGMP [BGMP] do not use RPF checks, and so would prevent the 207 problem from occurring to begin with.) 209 7. Security Considerations 211 The same security considerations and solutions discussed in [6TO4] 212 apply to multicast traffic. 214 Draft 6to4 Multicast July 2000 216 8. Acknowledgements 218 The following individuals provided helpful discussion on the 219 mechanisms in this document: Rich Draves, Brian Zill, Steve 220 Deering, and Brian Carpenter. 222 9. Author's Address 224 Dave Thaler 225 Microsoft Corporation 226 One Microsoft Way 227 Redmond, WA 98052-6399 228 Phone: +1 425 703 8835 229 EMail: dthaler@microsoft.com 231 10. References 233 [6TO4] 234 Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 235 IPv4 Clouds without Explicit Tunnels", draft-ietf- 236 ngtrans-6to4-06.txt, June 2000. 238 [6OVER4] 239 Carpenter, B., and C. Jung, "Transmission of IPv6 over IPv4 240 Domains without Explicit Tunnels", RFC 2529, March 1999. 242 [BGMP] 243 Thaler, D., Estrin, D., and D. Meyer, "Border Gateway 244 Multicast Protocol (BGMP): Protocol Specification", Work in 245 progress, draft-ietf-bgmp-spec-01.txt, March 2000. 247 [INTEROP] 248 D. Thaler, "Interoperability Rules for Multicast Routing 249 Protocols", RFC 2715, October 1999. 251 [MECH] 252 Gilligan, R., and E. Nordmark, "Transition Mechanisms for 253 IPv6 Hosts and Routers", Work in Progress, April, 2000. 255 [MLD] 256 Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 257 Discovery (MLD) for IPv6", RFC 2710, October 1999. 259 Draft 6to4 Multicast July 2000 261 [PIMSM] 262 Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S., 263 Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. 264 "Protocol Independent Multicast-Sparse Mode (PIM-SM): 265 Protocol Specification", RFC 2362, June 1998. 267 11. Full Copyright Statement 269 Copyright (C) The Internet Society (2000). All Rights Reserved. 271 This document and translations of it may be copied and furnished 272 to others, and derivative works that comment on or otherwise 273 explain it or assist in its implmentation may be prepared, copied, 274 published and distributed, in whole or in part, without 275 restriction of any kind, provided that the above copyright notice 276 and this paragraph are included on all such copies and derivative 277 works. However, this document itself may not be modified in any 278 way, such as by removing the copyright notice or references to the 279 Internet Society or other Internet organizations, except as needed 280 for the purpose of developing Internet standards in which case the 281 procedures for copyrights defined in the Internet Standards 282 process must be followed, or as required to translate it into 283 languages other than English. 285 The limited permissions granted above are perpetual and will not 286 be revoked by the Internet Society or its successors or assigns. 288 This document and the information contained herein is provided on 289 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 290 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 291 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 292 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.