Internet Engineering Task Force Qian. Wang Internet-Draft Qiong. Sun Intended status: Standards Track China Telecom Expires: April 11, 2011 Jacni. Qin Peng. Sun ZTE October 8, 2010 Extensions to DS-Lite for Multicast Deployment draft-qin-softwire-dslite-multicast-00 Abstract DS-Lite enables broadband service providers to provide IPv4 unicast service following IPv4 exhaustion by combining two mechanisms: NAT (for IPv4 address sharing) and IPv4-in-IPv6 tunnel(a bridging link, for carrying IPv4 traffic). Meanwhile, native IPv6 services, both unicast and multicast can be provided. This document describes extensions to DS-Lite to support IPv4 multicast. 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 April 11, 2011. Copyright Notice Copyright (c) 2010 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 Wang, et al. Expires April 11, 2011 [Page 1] Internet-Draft DS-Lite Multicast October 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wang, et al. Expires April 11, 2011 [Page 2] Internet-Draft DS-Lite Multicast October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel encapsulation for Multicast . . . . . . . . . . . . 5 2.2. IPv4-embedded IPv6 address prefixes . . . . . . . . . . . . 5 2.3. Multicast Distribution Tree . . . . . . . . . . . . . . . . 6 2.4. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 6 2.5. BNG with AFTR integrated . . . . . . . . . . . . . . . . . 7 3. Operation Details . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. B4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. AFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Multicast Traffic Optimization . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Wang, et al. Expires April 11, 2011 [Page 3] Internet-Draft DS-Lite Multicast October 2010 1. Introduction If DS-Lite is used for IPv4 multicast, there will be some problems. AFTR MUST work as the multicast replication point where all the IGMP reports are terminated. Especially when centralized AFTR is implemented, it will be a great challenge for AFTR to process the protocol messages and data forwarding. Meanwhile, the downstream bandwidth will be vastly consumed. In practice, similar issue exists in native IPv4 networks for multicast. To deal with it, mechanisms like IGMP snooping, multicast VLAN, are introduced into distributed Access Network Nodes (e.g. Aggregation Switches, xPON devices) which then occupy the role of terminating IGMP requests and replicating multicast traffic. In this way, the multicast replication point can be moved downward and closer to the subscribers, so the bandwidth consumption and the great pressure of the layer 3 gateway is reduced substantially. While in DS-Lite, IGMP snooping does NOT work on Access Network Nodes due to the current tunnel encapsulation. In this document, we try to extend DS-Lite and make it more feasible for IPv4 multicast. While the key characteristic of this proposal is exactly the same as DS-Lite: communications stay within their address family. 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. Overview The overall process is described in this section based on the example below where AFTR is a standalone box apart from the IPv6 BNG(there may be multiple hops in between), and PIM Sparse Mode is used for multicast routing. Wang, et al. Expires April 11, 2011 [Page 4] Internet-Draft DS-Lite Multicast October 2010 +----------+ +-----------+ -------| AFTR | | v6 Router |------- +----------+ +-----------+ | \ / | | \ / | | \ / | | +-----------+ | | | v6 BNG | | | +-----------+ | IPv4-embedded | | | Native IPv6 Multicast | | | IPv6 Multicast | | | | +----------+ | | | B4 | | | +----------+ | | / \ | V / \ V +------+ +------+ | v4 | | v6 | | Host | | Host | +------+ +------+ Figure 1 2.1. Tunnel encapsulation for Multicast In the original DS-Lite, IPv4-in-IPv6 tunnel encapsulation is used to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. Here we would like to use IPv6 Multicast address(IPv4-embedded) as the destination of tunnel encapsulation to carry the unidirectional IPv4 multicast from AFTR to B4. The IPv4 address of multicast source will be mapped to IPv6 address using special IPv6 prefix. 2.2. IPv4-embedded IPv6 address prefixes One special IPv6 multicast prefix(here we name it, Dedicated mPrefix) is needed for constructing IPv6 multicast addresses, with IPv4 multicast address embedded. Meanwhile, the addresses of IPv4 multicast source(also RP of shared tree) should be mapped to IPv6 addresses, so an IPv6 unicast prefix(here we name it Dedicated uPrefix) is needed for constructing IPv6 unicast addresses with IPv4 unicast address embedded(the multicast source or RP's address). The length of the IPv6 prefixes should be less than 96, with no other restrictions(except for the source-specific multicast, since IANA has assigned special ranges of group addresses for that). The exact policy of address format is controlled by service provider. Wang, et al. Expires April 11, 2011 [Page 5] Internet-Draft DS-Lite Multicast October 2010 These two prefixes can be configured onto B4 through DHCPv6 options or some out-of-band mechanism. 2.3. Multicast Distribution Tree Suppose that an IPv4 host has acquired the address of IPv4 multicast group which it is interested in, then the host will send an IGMP Report to B4 joining that group. After receiving IGMP message from the host, B4 performs the "IGMP Proxying" function similarly as described in [RFC4605], but translates the IGMP message to MLD message when sending upwards this membership report. In the MLD message, the IPv6 address of multicast group to be joined is constructed using Dedicated mPrefix, and with IPv4 multicast address embedded. If the source-specific multicast is deployed, the IPv6 address of the multicast source can be constructed in the same way (using Dedicated uPrefix, with IPv4 multicast source embedded). Receiving this MLD membership report on the BNG may trigger the PIM join up to RP or the multicast source. Make sure the calculated RPF interface for sending PIM join be on the path up to AFTR. This can be easily achieved by making AFTR advertise the route of Dedicated uPrefix throughout the service provider's IPv6 Network. To send PIM join triggered by native IPv6 MLD membership report, the RPF interface calculation can be done based on native IPv6 unicast routing information. After receiving the PIM join, AFTR will add the IPv6 interface receiving the join message to the Out Interface List of corresponding entry in the IPv4 multicast routing table(indicated by the IPv4 multicast address embedded). If the entry for this IPv4 multicast group doesn't exist, a new entry will be created and a PIM join message will be sent up further towards the source. Till now, the multicast distribution tree from B4 up to AFTR is established in service provider's IPv6 network. 2.4. Multicast Forwarding Whenever a IPv4 multicast packet is received on AFTR, a search of multicast routing table is performed, and probably an IPv6 interface will be found in the Out-Interface-List of the matching entry, this IPv6 interface was added into Out-Interface-List in the process of multicast distribution tree establishment as described previously. Then AFTR should encapsulate the IPv4 multicast packet into IPv6 tunnel using the "IPv4-embedded" multicast address as the destination of the IPv6 tunnel. The new IPv6 multicast packet will then be sent out of the IPv6 interface and flow down the multcast distribution Wang, et al. Expires April 11, 2011 [Page 6] Internet-Draft DS-Lite Multicast October 2010 tree to B4 through service provider's IPv6 network. When receiving the IPv6 multicast packet sent to this special group, B4 should decapsulate the IPv6 tunnel and pass the original IPv4 multicast packet to the IPv4 host in LAN. ?? to trigger the tunnel decapsulation operation, should B4 join this special IPv6 group itself? 2.5. BNG with AFTR integrated If the AFTR function is integrated into BNGs(have to be dual stack), the multicast distribution tree will be much simpler, and the multicast forwarding is the same as described above. 3. Operation Details 3.1. B4 To be added... 3.2. AFTR To be added... 4. Multicast Traffic Optimization To be added... 5. Acknowledgements The authors would like to thank Dan Wing for his guidance during the discussions which initiated this work. We also appreciate Jie Hu, Lizhong Jin for their valuable input. 6. IANA Considerations This document includes no request to IANA. 7. Security Considerations 8. References Wang, et al. Expires April 11, 2011 [Page 7] Internet-Draft DS-Lite Multicast October 2010 8.1. Normative References [I-D.ietf-behave-address-format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), August 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [I-D.venaas-behave-mcast46] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", draft-venaas-behave-mcast46-01 (work in progress), July 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [TR-101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL Aggregation", 2006. 8.2. Informative References [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Wang, et al. Expires April 11, 2011 [Page 8] Internet-Draft DS-Lite Multicast October 2010 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006. Authors' Addresses Qian Wang China Telecom No.118, Xizhimennei Beijing, 100035 China Phone: +86 10 5855 2177 Email: wangqian@ctbri.com.cn Qiong Sun China Telecom No.118, Xizhimennei Beijing, 100035 China Phone: +86 10 5855 2116 Email: sunqiong@ctbri.com.cn Jacni Qin ZTE Shanghai, China Phone: +86 1391 8619 913 Email: jacniq@gmail.com Wang, et al. Expires April 11, 2011 [Page 9] Internet-Draft DS-Lite Multicast October 2010 Peng Sun ZTE Shanghai, China Phone: +86 21 6889 7101 Email: sun.peng@zte.com.cn Wang, et al. Expires April 11, 2011 [Page 10]