Network Working Group M. Xu Internet-Draft Y. Cui Expires: March 17, 2007 F. Meng Tsinghua University C. Metz Cisco Systems, Inc. September 13, 2006 IPv4 over IPv6 multicast draft-xu-softwire-4over6multicast-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on March 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The 4over6 mechanism is a mechanism to interconnect IPv4 networks over IPv6 backbones and provide IPv4-to-IPv6 transparent routing. The 4over6 unicast has been described in draft-wu-softwire-mesh-framework-00.txt. Xu, et al. Expires March 17, 2007 [Page 1] Internet-Draft 4over6 September 2006 This memo provides the 4over6 multicast mechanism. We use BGP for discovering and maintaining the membership among all the Provider Edges (PE), and use IPv6 and IPv4 PIM-SM to construct the distribution tree. In the IPv6 backbone, static PIM-SSM trees are initially constructed for every PE. All the multicast traffic from the same PE are forwarded through only one PIM-SSM tree to avoid P routers maintaining too much state information. The process of encapsulation and decapsulation is the same as 4over6 unicast. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Constructing the RPT . . . . . . . . . . . . . . . . . . . . . 4 3. Forwarding data . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Xu, et al. Expires March 17, 2007 [Page 2] Internet-Draft 4over6 September 2006 1. Introduction This document gives the protocols and procedures that enable a SP (Service Provider) to provide multicast service for 4over6 which is based on the BGP MP attribute. Using multicast distribution tree is the most efficient way to forward multicast data. In 4over6 multicast, the distribution tree comes through both the IPv4 and IPv6 networks. We employ PIM-SM to construct the distribution tree. Sub-trees in IPv4 customers and IPv6 backbone compose the whole RPT. Common PIM-SM requires that the backbone maintain one or more source-trees which are specific for a particular group. Each such tree requires that state be maintained in all the routers that are in the tree. This may bring too much overload to the backbone. To avoid this, for every PE we construct only one source-tree whose leaves are all the other PEs. All the multicast traffic from the same PE are forwarded through this tree. This may cause some PE receives packets that they do not need. This method is just a trade-off between maintaining a lot of states in P routers and the optimality of the multicast routing. Xu, et al. Expires March 17, 2007 [Page 3] Internet-Draft 4over6 September 2006 2. Constructing the RPT The 4over6 unicast uses BGP to discover a new PE automatically and carry the IPv4 routes behind the PE and the corresponding IPv6 address of the PE's virtual interface. We can use the automatic PE discovery mechanism to construct an IPv6 PIM-SSM tree whose source is a PE, and leaves are all the other PEs. All multicast traffic from the PE are forwarded through this tree in the IPv6 backbone. We must construct such an IPv6 PIM-SSM tree for each PE. For example, as soon as a new PE1 is founded by PE2, PE2 will send Join message to register to the PIM-SSM tree whose source is PE1. The group addresses for these trees are: ff18:aaaa:aaaa::x Where a is the IPv4 address of the source PE's virtual interface, and it is carried by BGP updates to other PES. After all the IPv6 PIM-SSM trees are constructed, once a host in an IPv4 customer network wants to register to a multicast group whose RP is in another IPv4 customer network, the IPv4 Join message will be delivered to the PE which connects the IPv4 network to IPv6 the back bone. Then the PE lookups the IPv6 address of the PE connecting to the IPv4 customer network which the RP belongs to, and encapsulates the IPv4 Join message into an IPv6 unicast packet like a common 4over6 packet. When the encapsulated Join message arrives at the egress PE, it will be decapsulated, and will continue to register to the RP in IPv4 customer network. If an ISP does not care to maintain the whole state information, constructing PIM-SSM tree for every multicast group in the IPv6 backbone may also be adopted. Obviously, this option is optimistic because no PE receives redundant packets. In this way, the PIM-SM message will be translated in the ingress and egress PEs respectively to construct the PIM-SSM tree in the IPv6 backbone, and the IPv4 (S, G) can be mapped to the IPv6 (S', G'), where S' is the IPv6 virtual interface address of the PE which is connected to the RP, G' is ff18:ssss:ssss:gggg:gggg::x If the source is in the same IPv4 network with the RP, its registration procedure is the same as that of IPv4. Xu, et al. Expires March 17, 2007 [Page 4] Internet-Draft 4over6 September 2006 3. Forwarding data When a source wants to send data to the whole group, it first sends the unicast packets to the RP in IPv4 network as PIM-SM specified. If the source is in the same IPv4 network with the RP, the data forwarding is the same as that of IPv4 network, otherwise the data must traverse through the IPv6 backbone and be encapsulated and decapsulated as a common IPv4 unicast packet. Then the RP hands the packets out to all the members by multicast. When the IPv4 multicast packets arrive at the ingress PE, they are encapsulated into IPv6 multicast packets with the IPv6 address of PE virtual interface as source and the mapping group address as IPv6 group address. The encapsulated multicast packets are delivered as common IPv6 multicast packets until arriving at the egress PE, where they are decapsulated and forwarded along the IPv4 PIM-SM RPT. If the IPv4 multicast data rate exceeds the configured threshold, the RPT should switch to shortest path tree (SPT) as the PIM-SM specified. Receivers in IPv4 must register to the source as they register to the RP. When using static PIM-SSM trees, there is nothing modified in the IPv6 backbone. In contrast, when using a PIM-SSM tree for every group, a new PIM-SSM tree may be initialized in the IPv6 backbone whose source is the PE which is connected to the same IPv4 customer network with the source. Xu, et al. Expires March 17, 2007 [Page 5] Internet-Draft 4over6 September 2006 4. Security Considerations The PE routers could maintain secure communications through the use of Security Architecture for the Internet Protocol as described in [RFC4301]. Xu, et al. Expires March 17, 2007 [Page 6] Internet-Draft 4over6 September 2006 5. IANA Considerations To be supplied. Xu, et al. Expires March 17, 2007 [Page 7] Internet-Draft 4over6 September 2006 6. References 6.1 Normative References [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 6.2 Informative References [I-D.ietf-l3vpn-2547bis-mcast-bgp] Aggarwal, R., "BGP Encodings for Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-00 (work in progress), August 2006. [I-D.ietf-softwire-4over6vpns] Shepherd, G., "IPv4 unicast/multicast VPNs over an IPv6 core", draft-ietf-softwire-4over6vpns-00 (work in progress), June 2006. Authors' Addresses Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-62785822 Email: xmw@tsinghua.edu.cn Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: cuiyong@tsinghua.edu.cn Xu, et al. Expires March 17, 2007 [Page 8] Internet-Draft 4over6 September 2006 Fanqi Meng Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-62785822 Email: mfq@mails.tsinghua.edu.cn Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 America Email: Email: chmetz@cisco.com Xu, et al. Expires March 17, 2007 [Page 9] Internet-Draft 4over6 September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Xu, et al. Expires March 17, 2007 [Page 10]