Internet Engineering Task Force T. Tsou Internet-Draft Huawei Technologies (USA) Intended status: Standards Track T. Taylor Expires: July 9, 2011 C. Zhou Huawei Technologies H. Ji China Telecom January 5, 2011 IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment draft-tsou-softwire-6rd-multicast-00 Abstract This document describes how IPv6 multicast can be extended across an IPv4 network to an IPv6 host, using the native multicast capabilities of the IPv4 network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 9, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Tsou, et al. Expires July 9, 2011 [Page 1] Internet-Draft IPv6 Multicast With 6rd January 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Description of the Solution . . . . . . . . . . . . . . . . . . 3 2.1. Assumed Architecture . . . . . . . . . . . . . . . . . . . 3 2.2. Steps In the Proposed Solution . . . . . . . . . . . . . . 5 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Tsou, et al. Expires July 9, 2011 [Page 2] Internet-Draft IPv6 Multicast With 6rd January 2011 1. Introduction 6rd ([RFC5569], [RFC5969]) provides a means to connect IPv6 hosts to the IPv6 Internet across an IPv4 provider network. Unicast traffic is carried through IPv6-in-IPv4 tunnels. It is possible to carry multicast traffic from the IPv6 network through the IPv4 network in the same way, but if multiple customers wish access to the same multicast channels, the failure to use the native multicast capabilities of the IPv4 network wastes resources in that network. This document describes a solution use the native multicast capabilities of the IPv4 network to acquire and forward multicast traffic from IPv6 Internet to an IPv6 host attached to the IPv4 network. Typically this solution will operate in combination with 6rd for unicast traffic. However, no IPv6-in-IPv4 tunneling is required for signalling, only the ability to interwork between IPv4 and IPv6 at the 6rd Customer Equipment (6rd CE) and the 6rd Border Relay (BR). 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Description of the Solution A number of problems have to be solved to allow an IPv6 host attached to an IPv4 network to request and receive a multicast stream originating in a neighbouring IPv6 network and passing through the IPv4 network using the native multicast facilities of that network. These problems are described in detail in the course of presenting proposed solutions to them. 2.1. Assumed Architecture This document assumes an architecture similar to that of 6rd [RFC5569], [RFC5969], with additional capabilities for the 6rd CE and the 6rd Border Relay. In addition, it postulates a multicast source discovery and translation function, which MAY be collocated with the BR. See Figure 1. Tsou, et al. Expires July 9, 2011 [Page 3] Internet-Draft IPv6 Multicast With 6rd January 2011 +------------+ | Translator | -| function |- / +------------+ \ +----+ +----+ Access +--------+ / \ |IPv6| LAN | 6rd| Link |Provider| IPv4 +------+ IPv6 |Host|--------| CE |--------|IP Edge |- network ---|Border|--- network +----+ +----+ +--------+ |Relay | +------+ Figure 1: IPv6 Multicast Across an IPv4 Domain Using a Translator Function In addition to its 6rd responsibilities, the 6rd CE is responsible for: o requesting a mapping between IPv6 pairs presented by the IPv6 Host and IPv4 pairs valid for the provider's IPv4 network; o interworking between MLD [RFC3810] presented by the IPv6 Host and IGMP [RFC3376] forwarded toward the provider's IPv4 network; o translating incoming IPv4 multicast streams to IPv6 before forwarding them to the IPv6 Host. The Provider IP Edge has the normal function of interworking between IGMP [RFC3376] and PIM [RFC4601] multicast signalling. The Border Relay has the usual 6rd responsibilities. In addition, it is responsible for: o requesting a mapping between IPv4 pairs received in PIM messages from the IPv4 network and IPv6 pairs valid for the neighbouring IPv6 network; o translating PIM messaging between the IPv4 and IPv6 networks; o using the reverse mapping from IPv6 to IPv4 pairs to translate and forward multicast media streams coming from the IPv6 network. The Translator function has the following responsibilities: o creating a mapping between IPv6 and IPv4 address pairs for multicast streams, beginning with IPv6 address pairs provided in requests from the 6rd CE and assigning the corresponding IPv4 unicast and multicast addresses from pool of Tsou, et al. Expires July 9, 2011 [Page 4] Internet-Draft IPv6 Multicast With 6rd January 2011 addresses with which it is configured. o responding to requests for mappings in either direction. 2.2. Steps In the Proposed Solution 1. Initial discovery and Join request The IPv6 Host discovers the address pair of a multicast stream the user wants to receive. The discovery is by means outside the scope of this specification (e.g., via the web). The IPv6 Host sends an MLDv2 [RFC3810] request to the 6rd CE to acquire the stream. +----+ +----+ |IPv6| LAN | 6rd| |Host|--------| CE | +----+ +----+ -------> MLD/IPv6 Figure 2 2. Address Mapping At 6rd CE The 6rd CE checks its cache of mappings to see if it already has a mapping between the IPv6 address pair received in the MLD request and a corresponding pair of IPv4 addresses. Failing to find a mapping, it sends a request for the required mapping to the Translator. The Translator in turn checks whether it has already created the mapping. If not, it assigns unicast and multicast IPv4 addresses from its pool and records the mapping for further use. In either case it returns the requested mapping to the 6rd CE, which caches it. [Editor's Note: The transaction is carried out over a protocol to be specified in a later version of this document.] +----+ Access +--------+ +------------+ | 6rd| Link |Provider| IPv4 | Translator | | CE |--------|IP Edge |- network -| function | +----+ +--------+ +------------+ -----------------------------> TBD protocol / IPv4 Figure 3 3. Propagation Of the Join Request Into the IPv4 Network The 6rd CE interworks between the MLDv2 request it received and an Tsou, et al. Expires July 9, 2011 [Page 5] Internet-Draft IPv6 Multicast With 6rd January 2011 IGMPv3 [RFC3376] request which it forwards to the Provider IP Edge. It uses the address pair mapping it received from the Translator as part of this interworking. The Provider IP Edge acts on the IGMP request by forwarding a PIM [RFC3973] or [RFC4601] request into the IPv4 network, indicating the IPv4 address pair it was given and ensuring that it is on the multicast tree for the stream concerned. [Editor's note: details later.] Eventually the PIM request finds its way to the 6rd Border Relay. [Editor's note: details needed here to make sure this happens. Alternatively, we could recast this as using any Border Router and not a 6rd Relay in particular, but we would end up with possibly different paths for the multicast packets and the returning unicast RTCP feedback. Maybe that doesn't matter.] +----+ Access +--------+ +------+ | 6rd| Link |Provider| IPv4 |Border| IPv6 | CE |--------|IP Edge |- network -|Relay |- network +----+ +--------+ +------+ --------> ------------> IGMP/IPv4 PIM/IPv4 Figure 4 4. Remapping the Address Pair At the 6rd BR The 6rd BR needs to map from the IPv4 address pair it received back to the corresponding IPv6 address pair before propagating the PIM request into the IPv6 network. It sends a request to the Translator to provide that mapping. The Translator already has this mapping, as a result of the original 6rd CE request, and returns it to the 6rd BR. [Editor's note: protocol again to be specified later. It can probably be the same as the one used by the 6rd CE, since both nodes are operator-managed even if the 6rd CE is more likely to have been hacked. Have to work out the security considerations.] Tsou, et al. Expires July 9, 2011 [Page 6] Internet-Draft IPv6 Multicast With 6rd January 2011 +------+ |Border| |Relay | +------+ | TBD protocol | /IPv4 +----V-------+ | Translator | | function | +------------+ Figure 5 5. Propagation Of the PIM Request Into the IPv6 Network The 6rd BR propagates translates the PIM request from IPv4 to IPv6 using the mapping it received. It propagates the request into the IPv6 network to complete the construction of the path for the requested multicast stream. [Editor's note: probably don't have to go this far if there are already other listeners attached to the IPv4 network. Have to insert corresponding text in previous steps. Also, if PIM can return errors, the 6rd BR should notify the Translator so it can mark the IPv6 address pair as bad (so it doesn't get remapped) while releasing the assigned IPv4 addresses.] +------+ |Border| IPv6 |Relay |- network +------+ -----------> PIM/IPv6 Figure 6 6. Transport of Multicast Media and Unicast RTCP Feedback If the 6rd BR receives a multicast packet from the IPv6 network, it translates the source and group addresses to IPv4 using the mapping it has retained from Step 4. It then forwards it to the next hop in the multicast tree for that stream. Tsou, et al. Expires July 9, 2011 [Page 7] Internet-Draft IPv6 Multicast With 6rd January 2011 +------+ IPv4 |Border| IPv6 network -|Relay |- network +------+ <---------- <---------- Media packet Media packet /IPv4 /IPv6 Figure 7 When the 6rd CE receives a multicast packet from the IPv4 network, it translates the packet to IPv4 using the mapping which it has retained from Step 2. When the IPv6 Host sends unicast RTCP [RFC3550] feedback toward the source, the packets are treated by the 6rd CE and 6rd BR like any other unicast packets. That is, they are encapsulated at the 6rd CE, transported across the IPv4 network as IPv6-in-IPv4, and decapsulated at the 6rd BR before forwarding into the IPv6 network. Finally, if the IPv6 Host emits multicast packets destined for an any-source multicast group, the 6rd CE and 6rd BR translate the packets from IPv6 to IPv4 and back again using the mappings they have retained. 3. Acknowledgements Awaiting comments. 4. IANA Considerations This memo currently includes no request to IANA. 5. Security Considerations To come. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Tsou, et al. Expires July 9, 2011 [Page 8] Internet-Draft IPv6 Multicast With 6rd January 2011 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 6.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. Authors' Addresses Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tena@huawei.com URI: http://tinatsou.weebly.com/contact.html Tsou, et al. Expires July 9, 2011 [Page 9] Internet-Draft IPv6 Multicast With 6rd January 2011 Tom Taylor Huawei Technologies 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Phone: +1 613 680 2675 Email: tom111.taylor@bell.net Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Hui Ji China Telecom NO19.North Street Beijing, Chaoyangmen,Dongcheng District P.R. China Phone: Email: jihui@chinatelecom.com.cn Tsou, et al. Expires July 9, 2011 [Page 10]