NGTrans Working Group Dave Thaler INTERNET-DRAFT Microsoft Expires January 2001 14 July 2000 Support for Multicast over 6to4 Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Expires January 2001 [Page 1] Draft 6to4 Multicast July 2000 1. Abstract 6to4 Tunneling allows isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration. This document defines support for IPv6 Multicast over 6to4 networks. 2. Introduction 6to4 Tunneling [6TO4] allows isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration. Effectively it treats the IPv4 network as a link layer. Since [6TO4] does not define support for multicast, the purpose of this document is to define such support. Unlike [6OVER4], 6to4 does not assume the general availability of wide-area IPv4 multicast. The 6to4 mechanism assumes only unicast capability in its underlying IPv4 carrier network. As a result, the IPv4 network appears as a large Non-Broadcast Multi- Access (NBMA) link, over which we require the ability to multicast. To do this, IPv6 multicast packets being sent to or from a 6to4 router must be encapsulated in IPv4 unicast packets. If the tree has multiple branches in the 6to4 address space, 6to4 encapsulation of the same multicast packet will take place multiple times by necessity. In this document, we refer to the device in a 6to4 site which has a 6to4 pseudo-interface as a 6to4 "gateway". The gateway may either be a host (if the site is just a single host), or a router (if the site includes IPv6 links). We use the term "relay" as defined in [6TO4]. 3. Overview We assume each 6to4 gateway points an IPv6 default route at a particular relay reachable across the IPv4 infrastructure. This document only defines support for multicast when such a relay exists. Support for multicast among clouds of 6to4 sites with no default route is outside the scope of this document. Expires January 2001 [Page 2] Draft 6to4 Multicast July 2000 Each relay, plus the set of all gateways (perhaps unknown to the relay) using the relay, together are treated as being on a separate NBMA link. All IPv6 multicast packets will be encapsulated in IPv4 unicast packets over the logical NBMA link. This requires the 6to4 relay to keep state for each gateway which has joined a particular group. IPv6 multicast packets from the IPv6 native infrastructure behind the relay will be sent to each gateway which has requested them. Since the number of gateways using a relay can be quite large, and we expect that most sites will not want to receive most groups, an explicit-joining protocol is required for gateways to communicate group membership information to a relay. The two most likely candidates are the Multicast Listener Discovery [MLD] protocol, and the PIM-Sparse Mode [PIMSM] protocol. Since a 6to4 gateway may be a host, and hosts typically do not implement routing protocols, gateways will use MLD as described in Section 4 below. This allows a host kernel to easily implement 6to4 gateway behavior, and obviates the relay from the need to know whether a given gateway is a host or a router. From the relay's perspective, all gateways are indistinguishable from hosts on an NBMA leaf network. All IPv6 multicast packets sourced within the 6to4 site (and sent to a scope larger than the 6to4 site) are forwarded by the 6to4 gateway to the relay over the 6to4 pseudo-interface, regardless of whether any remote receivers exist. This is done so that the gateway (which may be a host) need not be aware of external membership information. When a relay receives a multicast packet over the 6to4 pseudo- interface, it applies a Reverse-Path Forwarding check by dropping it unless the source address is a 6to4 address. If it is not dropped, the packet is forwarded to all other 6to4 gateways which have requested it, in addition to being forwarded out any native IPv6 interfaces according to the rules of the multicast routing protocol(s) running on the relay. When applying the rules for multicast interoperability [INTEROP], the 6to4 link is treated using the MLD equivalents of the rules for an IGMP-only link. Expires January 2001 [Page 3] Draft 6to4 Multicast July 2000 4. Multicast Listener Discovery The MLD protocol usually operates by having the Querier multicast an MLD Query message on the link. This behavior does not work on NBMA links which do not support multicast. Since the set of gateways is typically unknown to the relay (and potentially quite large), unicasting the queries is also impractical. The following behavior is used instead. The relay operates passively, sending no Queries but simply tracking membership information according to Reports and Done messages. To provide robustness, gateways unicast Reports to the relay every [Query Interval] (defined as 125 in [MLD]) seconds. The IPv6 source address of MLD reports sent to a 6to4 relay MUST be a link-local address formed as specified in Section 3.7 of [MECH]. Reports are not relayed to other gateways by the 6to4 relay, and no report suppression is done. As a result, the timer used to send periodic reports MUST be initialized to a random value from the interval [0, [Query Interval] ] before sending the first periodic report, in order to prevent startup synchronization (e.g., after a power outage). If a gateway is serving as a local router, it SHOULD also function as an "MLD Proxy". MLD Proxy behavior can be summarized as follows. First, the gateway will serve as an MLD querier on its private interface(s), and send MLD reports to the relay for groups which are scoped larger than a site and have members present on its private interface(s). Second, the gateway will forward multicast packets received encapsulated from a relay to any private interface with members present. 5. Scalability Considerations The requirement that a relay keep group state per gateway that has joined the group introduces potential scalability concerns. In this section, we discuss how these concerns may be addressed. Note that there may be non-multicast related reasons, such as bandwidth bottlenecks at relays, to do the behavior recommended here as well. When configuring gateways to use a relay, it is RECOMMENDED that gateways should be configured with a DNS name rather than an IPv4 Expires January 2001 [Page 4] Draft 6to4 Multicast July 2000 address of the relay. This allows the relay owners to easily add more relays by having the same DNS name resolve to the IPv4 addresses of multiple relays. Since adding another relay has the result of adding another independent NBMA link, this allows the gateways to be spread out among more relays so as to keep the number of relays per gateway at a reasonable level. Gateways SHOULD periodically (e.g., once a day) re-resolve the DNS name and update the relay's address to use accordingly. 6. Supporting Multiple Relays in the Presence of RPF A problem with the simple mechanisms described above can occur when multiple relays exist, and a multicast routing protocol is used that employs Reverse-Path Forwarding (RPF) checks against the source address, such as occurs when [PIMSM] is used by the IPv6 infrastructure. Namely, if an IPv6 router on the path to a receiver in the native IPv6 infrastructure expects to receive data from a 6to4 site via the closest relay to the receiver, that relay may not be the one to which the 6to4 site is encapsulating data, and no data will be seen. The solution specified by this document is that if a relay receives an explicit join from the native IPv6 infrastructure, for a given source and group pair where the source is a 6to4 address, then the relay will periodically (using the same rules in Section 4) unicast an MLD report for the group to the 6to4 site gateway. The 6to4 gateway must keep state per relay from which an MLD Report has been sent, and in addition to forwarding multicast traffic from the site to its relay of choice, traffic is also forwarded to all relays from which Reports have been received. The solution above will scale to an arbitrary number of relays, as long at the number of relays requiring multicast traffic from a given 6to4 site remains reasonable enough to not overly burden the site gateway. (Note that bi-directional tree protocols such as BGMP [BGMP] do not use RPF checks, and so would prevent the problem from occurring to begin with.) 7. Security Considerations The same security considerations and solutions discussed in [6TO4] apply to multicast traffic. Expires January 2001 [Page 5] Draft 6to4 Multicast July 2000 8. Acknowledgements The following individuals provided helpful discussion on the mechanisms in this document: Rich Draves, Brian Zill, Steve Deering, and Brian Carpenter. 9. Author's Address Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com 10. References [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", draft-ietf- ngtrans-6to4-06.txt, June 2000. [6OVER4] Carpenter, B., and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [BGMP] Thaler, D., Estrin, D., and D. Meyer, "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Work in progress, draft-ietf-bgmp-spec-01.txt, March 2000. [INTEROP] D. Thaler, "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999. [MECH] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress, April, 2000. [MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. Expires January 2001 [Page 6] Draft 6to4 Multicast July 2000 [PIMSM] Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires January 2001 [Page 7]