idnits 2.17.1 draft-tsou-v6ops-multicast-transition-v6only-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 15, 2011) is 4783 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou, Ed. 3 Internet-Draft Huawei Technologies(USA) 4 Intended status: Informational T. Taylor 5 Expires: September 16, 2011 Huawei Technologies 6 March 15, 2011 8 Multicast Transition to IPv6 Only in Broadband Deployments 9 draft-tsou-v6ops-multicast-transition-v6only-01 11 Abstract 13 This document proposes a multicast transition solution from the old 14 IPv4 only network to the IPv6 only network. It enumerates the 15 transition steps and then analyzes the transition cost in various 16 dimensions. 18 This document is intended to eventually meet the criteria for a 19 specification in the series envisioned by the v4-to-v6 transition 20 framework. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 16, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 58 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Transition Steps . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. The Old IPv4 Only Multicast Network . . . . . . . . . . . . 4 61 3.2. First Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Second Upgrade, Dropping IPv4 . . . . . . . . . . . . . . . 4 63 3.4. The Pure IPv6 Multicast Network . . . . . . . . . . . . . . 5 64 4. Analysis of the Multicast Transition Cost . . . . . . . . . . . 5 65 4.1. IPTV Source Server . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Bandwidth Consumed By Multicast . . . . . . . . . . . . . . 5 67 4.3. Border Devices . . . . . . . . . . . . . . . . . . . . . . 5 68 4.4. IPTV Terminal . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 8.1. Informative References . . . . . . . . . . . . . . . . . . 6 74 8.2. Normative References . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 [ID.v4v6tran-framework] defines the required content for a series of 80 documents describing how to move from IPv4 to IPv6 for specific 81 network scenarios. The present document is an initial sketch of one 82 such document. Content will be added in later versions to allow it 83 to meet the criteria set by [ID.v4v6tran-framework]. 85 The handling of unicast during the transition from IPv4 to IPv6 is 86 the focus of a considerable amount of activity within the BEHAVE and 87 SOFTWIRES Working Groups, which have worked on tools such as NAT64, 88 6rd, and DS Lite. At the same time, even though some ISPs have 89 chosen 6rd or dual stack as their unicast transition solution, they 90 want to keep their IPv4 only multicast system unchanged as long as 91 possible, simply because they have enough IPv4 multicast address. 92 While IPv4 unicast addresses will soon be exhausted, ISPs have no 93 motivation to update multicast until the day when there are few IPv4 94 unicast users, it is near the point where the IPv4 stack in network 95 equipment can be turned off, and the update of the network to IPv6 96 only is nearly complete. 98 This document discusses a multicast transition model to keep the old 99 IPv4 only multicast service while 6rd or dual stack is deployed for 100 unicast transition, and then to migrate the IPv4 only multicast 101 system to an IPv6 only multicast system "directly". 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Scope 111 The multicast framework proposed here corresponds to some unicast 112 transition scenarios in the SOFTWIRES Working Group as follows: 114 1. The access network moves from IPv4 only to 6rd [RFC5969] and then 115 to dual stack and finally to IPv6 only. This path may be 116 preferred by some ISPs. 118 2. The access network moves from IPv4 only to dual stack directly, 119 and then to IPv6 only. This path may be preferred by other ISPs. 121 3. The access network is deployed from its beginning as an IPv6 only 122 network. 124 This document considers unicast transition Scenarios 1 and 2. 125 Scenario 3 is not considered in this draft because DS-Lite is good as 126 its unicast solution and [ID.qin-dslite-multicast] is good as its 127 multicast solution. 129 3. Transition Steps 131 The multicast transition solution has four steps as described below. 133 3.1. The Old IPv4 Only Multicast Network 135 In this stage, both unicast and multicast services are based on an 136 IPv4 only network. 138 3.2. First Upgrade 140 In this stage, the user IPTV terminal is either IPv4 only or has been 141 upgraded to dual stack. The network is now dual stack. Multicast 142 sources continue to be IPv4. 144 The IPv4 core network is changed to dual stack to support more and 145 more use of IPv6 unicast, but not multicast in this stage. In a 146 variation, some ISPs may choose to start with 6rd and then move to 147 dual stack as their unicast transition solution. The corresponding 148 multicast solution in that scenario is the same as for a direct move 149 to dual stack. 151 In this stage, new dual stack IPTV terminals may be deployed only for 152 compatibility with the future IPv6 only network. 154 This stage may exist in more than 15 years. At the end of the stage, 155 IPv4 unicast traffic may only take up at most 10% of the total 156 bandwidth. 158 Moreover, at the end of this stage, the IPv4 source servers should be 159 updated to dual stack. The IPv6 stack is operated only for testing, 160 just make sure it will work well in the next stage when the day comes 161 that the ISP decides to turn off the IPv4 stack in all equipment in 162 its network. 164 3.3. Second Upgrade, Dropping IPv4 166 In this stage the user terminal is either the dual stack device 167 introduced in the previous stage or a new IPv6 only IPTV Terminal. 168 The network and the IPTV source are both IPv6 only. 170 This stage begins when the ISP finds that the IPv4 unicast traffic in 171 its network is insignificant and decides to turn of all IPv4 stacks 172 in all of its network devices. At that point the IPv4 only IPTV 173 terminal will be useless, and the IPv4 stack of the source servers 174 will be turned off, too. 176 3.4. The Pure IPv6 Multicast Network 178 In the final stage, the old dual stack IPTV terminals disappear. The 179 network is purely IPv6. 181 4. Analysis of the Multicast Transition Cost 183 4.1. IPTV Source Server 185 The IPv4 IPTV source servers may operate for more than 15 years, so 186 that the ISP investment in the old IPv4 IPTV system is well 187 protected. Only at the end of stage 2 (Section 3.2) must the ISP add 188 the IPv6 stack to the source server for testing in preparation for 189 stage 3. 191 4.2. Bandwidth Consumed By Multicast 193 Because the production servers are always running just one IP 194 version, bandwidth consumption for multicast is not affected by the 195 transition. The only exception is at the end of the second stage, 196 when the servers are upgraded to dual stack. Stray customer IPv6 197 traffic could boost bandwidth, but this can be prevented by proper 198 filtering to allow IPv6 access only to test traffic for the moment. 200 4.3. Border Devices 202 The suggested evolution path avoids the need to deploy the NAT64 203 function in border routers, such as the Border Relay in 6rd unicast 204 deployment. NAT64 can seriously degrade performance. 206 4.4. IPTV Terminal 208 The suggested evolution path requires an upgrade to IPTV terminals 209 over a period in the order of 15 years, from IPv4 to dual stack. 210 Later, the IPv4 stack in these terminals has to be turned off. In 211 the long run they will be replaced by IPv6 terminals. The time 212 frames involved are probably longer than the working life of an 213 individual terminal, so that no extra investment is involved. 215 5. Security Considerations 217 TBD 219 6. IANA Considerations 221 This document requires no IANA action. 223 7. Acknowledgements 225 Thanks to Fred Baker for preliminary comments.. 227 8. References 229 8.1. Informative References 231 [ID.qin-dslite-multicast] 232 Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C., 233 and Y. Lee, "Multicast Extensions to DS-Lite Technique in 234 Broadband Deployments (Work in progress)", January 2011. 236 [ID.v4v6tran-framework] 237 Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for 238 IP Version Transition Scenarios", February 2011. 240 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 241 Infrastructures (6rd) -- Protocol Specification", 242 RFC 5969, August 2010. 244 8.2. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 Authors' Addresses 251 Tina Tsou (editor) 252 Huawei Technologies(USA) 253 2330 Central Expresswayt 254 Santa Clara, CA 95050 255 USA 257 Phone: +1 408 330 4424 258 Email: tena@huawei.com 260 Tom Taylor 261 Huawei Technologies 262 1852 Lorraine Ave 263 Ottawa, Ontario K1H 6Z8 264 Canada 266 Phone: 267 Email: tom111.taylor@bell.net