Internet Engineering Task Force T. Tsou, Ed. Internet-Draft Huawei Technologies(USA) Intended status: Informational T. Taylor Expires: September 16, 2011 Huawei Technologies March 15, 2011 Multicast Transition to IPv6 Only in Broadband Deployments draft-tsou-v6ops-multicast-transition-v6only-01 Abstract This document proposes a multicast transition solution from the old IPv4 only network to the IPv6 only network. It enumerates the transition steps and then analyzes the transition cost in various dimensions. This document is intended to eventually meet the criteria for a specification in the series envisioned by the v4-to-v6 transition framework. 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 September 16, 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 Tsou & Taylor Expires September 16, 2011 [Page 1] Internet-Draft Multicast Transition To IPv6 Only March 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Transition Steps . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The Old IPv4 Only Multicast Network . . . . . . . . . . . . 4 3.2. First Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Second Upgrade, Dropping IPv4 . . . . . . . . . . . . . . . 4 3.4. The Pure IPv6 Multicast Network . . . . . . . . . . . . . . 5 4. Analysis of the Multicast Transition Cost . . . . . . . . . . . 5 4.1. IPTV Source Server . . . . . . . . . . . . . . . . . . . . 5 4.2. Bandwidth Consumed By Multicast . . . . . . . . . . . . . . 5 4.3. Border Devices . . . . . . . . . . . . . . . . . . . . . . 5 4.4. IPTV Terminal . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Normative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Tsou & Taylor Expires September 16, 2011 [Page 2] Internet-Draft Multicast Transition To IPv6 Only March 2011 1. Introduction [ID.v4v6tran-framework] defines the required content for a series of documents describing how to move from IPv4 to IPv6 for specific network scenarios. The present document is an initial sketch of one such document. Content will be added in later versions to allow it to meet the criteria set by [ID.v4v6tran-framework]. The handling of unicast during the transition from IPv4 to IPv6 is the focus of a considerable amount of activity within the BEHAVE and SOFTWIRES Working Groups, which have worked on tools such as NAT64, 6rd, and DS Lite. At the same time, even though some ISPs have chosen 6rd or dual stack as their unicast transition solution, they want to keep their IPv4 only multicast system unchanged as long as possible, simply because they have enough IPv4 multicast address. While IPv4 unicast addresses will soon be exhausted, ISPs have no motivation to update multicast until the day when there are few IPv4 unicast users, it is near the point where the IPv4 stack in network equipment can be turned off, and the update of the network to IPv6 only is nearly complete. This document discusses a multicast transition model to keep the old IPv4 only multicast service while 6rd or dual stack is deployed for unicast transition, and then to migrate the IPv4 only multicast system to an IPv6 only multicast system "directly". 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. Scope The multicast framework proposed here corresponds to some unicast transition scenarios in the SOFTWIRES Working Group as follows: 1. The access network moves from IPv4 only to 6rd [RFC5969] and then to dual stack and finally to IPv6 only. This path may be preferred by some ISPs. 2. The access network moves from IPv4 only to dual stack directly, and then to IPv6 only. This path may be preferred by other ISPs. 3. The access network is deployed from its beginning as an IPv6 only network. Tsou & Taylor Expires September 16, 2011 [Page 3] Internet-Draft Multicast Transition To IPv6 Only March 2011 This document considers unicast transition Scenarios 1 and 2. Scenario 3 is not considered in this draft because DS-Lite is good as its unicast solution and [ID.qin-dslite-multicast] is good as its multicast solution. 3. Transition Steps The multicast transition solution has four steps as described below. 3.1. The Old IPv4 Only Multicast Network In this stage, both unicast and multicast services are based on an IPv4 only network. 3.2. First Upgrade In this stage, the user IPTV terminal is either IPv4 only or has been upgraded to dual stack. The network is now dual stack. Multicast sources continue to be IPv4. The IPv4 core network is changed to dual stack to support more and more use of IPv6 unicast, but not multicast in this stage. In a variation, some ISPs may choose to start with 6rd and then move to dual stack as their unicast transition solution. The corresponding multicast solution in that scenario is the same as for a direct move to dual stack. In this stage, new dual stack IPTV terminals may be deployed only for compatibility with the future IPv6 only network. This stage may exist in more than 15 years. At the end of the stage, IPv4 unicast traffic may only take up at most 10% of the total bandwidth. Moreover, at the end of this stage, the IPv4 source servers should be updated to dual stack. The IPv6 stack is operated only for testing, just make sure it will work well in the next stage when the day comes that the ISP decides to turn off the IPv4 stack in all equipment in its network. 3.3. Second Upgrade, Dropping IPv4 In this stage the user terminal is either the dual stack device introduced in the previous stage or a new IPv6 only IPTV Terminal. The network and the IPTV source are both IPv6 only. This stage begins when the ISP finds that the IPv4 unicast traffic in Tsou & Taylor Expires September 16, 2011 [Page 4] Internet-Draft Multicast Transition To IPv6 Only March 2011 its network is insignificant and decides to turn of all IPv4 stacks in all of its network devices. At that point the IPv4 only IPTV terminal will be useless, and the IPv4 stack of the source servers will be turned off, too. 3.4. The Pure IPv6 Multicast Network In the final stage, the old dual stack IPTV terminals disappear. The network is purely IPv6. 4. Analysis of the Multicast Transition Cost 4.1. IPTV Source Server The IPv4 IPTV source servers may operate for more than 15 years, so that the ISP investment in the old IPv4 IPTV system is well protected. Only at the end of stage 2 (Section 3.2) must the ISP add the IPv6 stack to the source server for testing in preparation for stage 3. 4.2. Bandwidth Consumed By Multicast Because the production servers are always running just one IP version, bandwidth consumption for multicast is not affected by the transition. The only exception is at the end of the second stage, when the servers are upgraded to dual stack. Stray customer IPv6 traffic could boost bandwidth, but this can be prevented by proper filtering to allow IPv6 access only to test traffic for the moment. 4.3. Border Devices The suggested evolution path avoids the need to deploy the NAT64 function in border routers, such as the Border Relay in 6rd unicast deployment. NAT64 can seriously degrade performance. 4.4. IPTV Terminal The suggested evolution path requires an upgrade to IPTV terminals over a period in the order of 15 years, from IPv4 to dual stack. Later, the IPv4 stack in these terminals has to be turned off. In the long run they will be replaced by IPv6 terminals. The time frames involved are probably longer than the working life of an individual terminal, so that no extra investment is involved. Tsou & Taylor Expires September 16, 2011 [Page 5] Internet-Draft Multicast Transition To IPv6 Only March 2011 5. Security Considerations TBD 6. IANA Considerations This document requires no IANA action. 7. Acknowledgements Thanks to Fred Baker for preliminary comments.. 8. References 8.1. Informative References [ID.qin-dslite-multicast] Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C., and Y. Lee, "Multicast Extensions to DS-Lite Technique in Broadband Deployments (Work in progress)", January 2011. [ID.v4v6tran-framework] Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for IP Version Transition Scenarios", February 2011. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 8.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Tsou & Taylor Expires September 16, 2011 [Page 6] Internet-Draft Multicast Transition To IPv6 Only March 2011 Authors' Addresses Tina Tsou (editor) Huawei Technologies(USA) 2330 Central Expresswayt Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tena@huawei.com Tom Taylor Huawei Technologies 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Phone: Email: tom111.taylor@bell.net Tsou & Taylor Expires September 16, 2011 [Page 7]