idnits 2.17.1 draft-matsushima-v6ops-transition-experience-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2011) is 4776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ymbk-aplusp' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 324, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-arkko-ipv6-only-experience-02 == Outdated reference: A later version (-04) exists of draft-dec-stateless-4v6-01 == Outdated reference: A later version (-09) exists of draft-ietf-behave-v4v6-bih-03 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-01 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-09 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Matsushima 3 Internet-Draft Softbank Telecom 4 Intended status: Informational Y. Yamazaki 5 Expires: September 30, 2011 Softbank Mobile 6 C. Sun 7 M. Yamanishi 8 J. Jiao 9 Softbank BB 10 March 29, 2011 12 Use case and consideration experiences of IPv4 to IPv6 transition 13 draft-matsushima-v6ops-transition-experience-02 15 Abstract 17 Service Providers will apply their use case when conducting IPv6 18 transition and determine helpful solutions with the assistance of the 19 IPv6 transition guideline document. More than one solution is 20 possible, and decisions must be made from not only the technical 21 point of view, but also from the economic point of view. This 22 document describes the conclusions reached by one operator based on 23 their considerations and their plans for IPv6 transition so as to 24 assist others who may have similar circumstances. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 30, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Transition overview and current status . . . . . . . . . . . . 3 62 3. Experience of IPv4-only Network and Assessment Approach . . . . 3 63 4. Considerations for IPv6-Only network . . . . . . . . . . . . . 4 64 5. Considerations for Mobile network . . . . . . . . . . . . . . . 5 65 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security considerations . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 IPv4 to IPv6 transition solutions are becoming more converged. Given 76 the variety of operators involved, various use-case scenarios exist 77 and efforts are underway to clarify them. Since the first group 78 addressing IPv6 transition are technically inclined, the economic 79 analyses needed for creating business plans are often delayed. One 80 key factor impacting the business plan is architecture. The solution 81 will be considered and then adopted so as to implement the most 82 efficient architecture for each operator. In other words, the 83 Service Provider who wants to ensure long-term viability must place 84 greater emphasis on the economic impact of IPv6 transition. The 85 author expect that IETF has great interest in this approach given its 86 engineering and standardization work. Moreover, sharing the 87 considerations described in this document would be helpful to 88 operators who are in similar circumstances. 90 2. Transition overview and current status 92 Various transition use-cases have been published. 94 [I-D.huang-v6ops-v4v6tran-bb-usecase] 95 [I-D.lee-v6ops-tran-cable-usecase] 96 [I-D.tsou-v6ops-mobile-transition-guide] [I-D.sunq-v6ops-ivi-sp] 98 IPv6 transition guideline document 99 [I-D.arkko-ipv6-transition-guidelines] presents four deployment 100 models. As our ultimate goal is the IPv6 only network, our strategy 101 to achieving it is: (1) provide IPv6 connectivity to the existing 102 IPv4-Only network, (2) build new IPv6-Only network, (3) migrate our 103 customers from the IPv4-Only network to the IPv6-Only network. Along 104 with the guideline, we had studied the "Crossing IPv4 Islands" model 105 in the guideline to realize (1), while performing (2) in parallel. 106 Subsequently, we started studying the "IPv6-Only Core Network" model 107 to achieve (3). Research into a deployment model for our mobile 108 network is now in progress. 110 3. Experience of IPv4-only Network and Assessment Approach 112 Our starting point is ensuring that the IPv4-Only network can provide 113 IPv6 connectivity. Since our final goal is to build a IPv6-only 114 network and migrate all customers to the network, we will not have to 115 accommodate new customers beyond current capacity in the existing 116 IPv4-only network. This means two things for the IPv4-only network; 117 one, "minimized additional resources will provided to keep the 118 network" and two, "there is less need to conserve IPv4 addresses in 119 the network". As the guideline document pointed out, many "IPv6 over 120 IPv4 tunneling" solutions have already been developed. Our criterion 121 for adopting the best solution involves not only technical pros/cons, 122 but also the cost efficiency of providing IPv6 connectivity to all 123 customers in the IPv4-only networks. 125 When the total capital and operational expense of the system is 126 represented as "Q", and the number of customers that can be served by 127 the system as "T", the metric of cost efficiency, "S", is given by 128 the following simple formula: 130 S=Q/T 132 We gathered the S values of all candidate products and solutions, and 133 decided to adopt the solution that had the lowest S value. Ignoring 134 the price difference between the products, the stateful solutions 135 have S values that are significantly different from those of the 136 stateless solutions. In stateful solutions, T is the total number of 137 system capable sessions divided by the number of sessions per 138 customer. In stateless solutions, on the other hand, T is the total 139 amount of system bandwidth capacity divided by the bandwidth 140 consumption per customer. 142 From our experience, S(A) < S(B), that is, S(A) is always more 143 efficient than S(B) (note S(A) is stateless, S(B) is stateful). We 144 consequently adopt 6rd [RFC5969] for IPv4-only network. As the 145 guideline document points out, it is not productive to implement an 146 optimal IPv6 transition system as a temporary solution with goal of 147 rich functionality. Many service providers hope that by allocating 148 more resource they can increase network performance, bandwidth 149 capacity, and the coverage of their network. In other words, we, as 150 a service provider, want to minimize the resources allocated to such 151 temporary solutions. 153 4. Considerations for IPv6-Only network 155 Our considerations suggest that a stateless solution should be 156 adopted for the IPv6-only network to minimize overall resource 157 allocation and to allocate resources to the more productive areas. 158 In one of IPv6-only network deployment scenario, routing and 159 addressing lie outside our control except for our own prefix, which 160 is assigned to the customers who connect to the network. It seems 161 like relation of operators among wholesale and retail. In that 162 network, it is difficult to avoid assigning well known and other 163 operator owned IPv4 prefixes if the stateless solution uses the 32bit 164 IPv4 address to IPv6 address mapping technique. The solution must 165 meet the requirements of: (1) The routing path for IPv4 should match 166 the optimized IPv6 routing path, (2) It should be capable to share 167 one IPv4 address among customers since the number of IPv4 addresses 168 is insufficient, (3) It must be stateless. We will adopt the 169 solution that satisfies these three requirements. According to 170 [I-D.sun-intarea-4rd-applicability], there are significant 171 characteristics in particular these three requirements are satisfied. 172 It is noted that since some customers require a service which no 173 address sharing, a non-address sharing solution is also needed, but 174 this does not need to be the same as the address sharing solution. 176 The guideline document describes that Dual-Stack-lite 177 [I-D.ietf-softwire-dual-stack-lite] is recommended only as a 178 transition solution on the way to the IPv6-only network. Compared to 179 other deployment scenarios such as crossing IPv4 island and IPv6-only 180 deployment, there are several candidate solutions for each deployment 181 model but only one solution for the scenario. It is noted that the 182 solutions not mentioned in the guideline are discussed in 183 [I-D.dec-stateless-4v6], which adopt 4rd [I-D.despres-intarea-4rd] 184 and dIVI [I-D.xli-behave-divi]. 186 5. Considerations for Mobile network 188 We believe that the requirements explained in the previous section 189 should be applied to the mobile network as well. [TR23.975], has 190 clarified the IPv6-only deployment model in the guideline as a IPv6 191 transition scenario. As [I-D.arkko-ipv6-only-experience] pointed 192 out, the operators' policy of service quality assurance may require 193 the solution of avoiding the IPv4 referral issue 194 [I-D.ietf-behave-v4v6-bih] 196 It is interesting that stateless address mapping techniques exist for 197 both encapsulation/decapsulation and translation in the case of IPv4 198 crossing IPv6-only network model. This means that, the requirements 199 listed in previous section could be achieved for the mobile network. 201 6. Conclusions 203 One of most significant areas that remain to be investigated is the 204 physical resources of our network. We also need to minimize the 205 investments needed to secure the IP transition (i.e. the temporary 206 solutions) because we believe that the ultimate goal of the 207 transition must be the long-term viability of the Internet and also 208 the provision of our services. To ensure that, our considerations 209 yielded the conclusion that the stateless solution should be 210 specified for all deployment models in the guideline document. It is 211 recommended that IETF standardize on stateless solutions for not only 212 the IPv4-only network, but also both the IPv6-only network and Ipv6- 213 only deployment models in the guideline. 215 7. Security considerations 217 A stateless solution without the appropriate implementation and 218 operation techniques would be vulnerable to denial of service 219 attacks, routing loops, spoofing, and other such malicious acts. To 220 eliminate these security vulnerabilities, a stateless solution, like 221 6rd, which is capable of validating consistency of IPv6 source 222 address with IPv4 source address, can be used to avoid these 223 vulnerabilities, based on its address mapping rule. If a stateless 224 solution supports IPv4 address sharing, it must take into account the 225 issues described in [I-D.ietf-intarea-shared-addressing-issues]. If 226 an operator is concerned about the unnecessary bandwidth consumption 227 created by unwanted packets from the outside, one recommended 228 solution is to implement appropriate firewall protection for not only 229 v4v6 transition solution, but also both native IPv4 and IPv6 230 networks. 232 8. Acknowledgements 234 The authors would like to thank the guideline document of IPv6 235 transition [I-D.arkko-ipv6-transition-guidelines], which guides us 236 through the transition way, and has motivated the authors to write 237 this document. We also would like to thank Miwa Fujii for her 238 helpful suggestions and supports to share our experience with many 239 people. 241 9. References 243 9.1. Normative References 245 [I-D.arkko-ipv6-transition-guidelines] 246 Arkko, J. and F. Baker, "Guidelines for Using IPv6 247 Transition Mechanisms during IPv6 Deployment", 248 draft-arkko-ipv6-transition-guidelines-14 (work in 249 progress), December 2010. 251 9.2. Informative References 253 [I-D.arkko-ipv6-only-experience] 254 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 255 Network", draft-arkko-ipv6-only-experience-02 (work in 256 progress), October 2010. 258 [I-D.dec-stateless-4v6] 259 Dec, W., "Stateless 4Via6 Address Sharing", 260 draft-dec-stateless-4v6-01 (work in progress), March 2011. 262 [I-D.despres-intarea-4rd] 263 Despres, R., Matsushima, S., Murakami, T., and O. Troan, 264 "IPv4 Residual Deployment across IPv6-Service networks 265 (4rd) ISP-NAT's made optional", 266 draft-despres-intarea-4rd-01 (work in progress), 267 March 2011. 269 [I-D.huang-v6ops-v4v6tran-bb-usecase] 270 Huang, C., Li, X., and L. Hu, "Use Case For IPv6 271 Transition For a Large-Scale Broadband network", 272 draft-huang-v6ops-v4v6tran-bb-usecase-01 (work in 273 progress), October 2010. 275 [I-D.ietf-behave-v4v6-bih] 276 Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts 277 Using "Bump-in-the-Host" (BIH)", 278 draft-ietf-behave-v4v6-bih-03 (work in progress), 279 March 2011. 281 [I-D.ietf-intarea-shared-addressing-issues] 282 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 283 Roberts, "Issues with IP Address Sharing", 284 draft-ietf-intarea-shared-addressing-issues-05 (work in 285 progress), March 2011. 287 [I-D.ietf-softwire-dual-stack-lite] 288 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 289 Stack Lite Broadband Deployments Following IPv4 290 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 291 in progress), March 2011. 293 [I-D.lee-v6ops-tran-cable-usecase] 294 Lee, Y. and V. Kuarsingh, "IPv6 Transition Cable Access 295 Network Use Cases", draft-lee-v6ops-tran-cable-usecase-00 296 (work in progress), October 2010. 298 [I-D.sun-intarea-4rd-applicability] 299 Sun, C., Matsushima, S., and J. Jiao, "4rd Applicability 300 Statement", draft-sun-intarea-4rd-applicability-01 (work 301 in progress), March 2011. 303 [I-D.sunq-v6ops-ivi-sp] 304 Sun, Q., Xie, C., Li, X., Bao, C., and M. Feng, 305 "Considerations for Stateless Translation (IVI/dIVI) in 306 Large SP Network", draft-sunq-v6ops-ivi-sp-02 (work in 307 progress), March 2011. 309 [I-D.tsou-v6ops-mobile-transition-guide] 310 ZOU), T. and T. Taylor, "IPv6 Transition Guide For A Large 311 Mobile Operator", 312 draft-tsou-v6ops-mobile-transition-guide-00 (work in 313 progress), October 2010. 315 [I-D.xli-behave-divi] 316 Li, X., Bao, C., and H. Zhang, "Address-sharing stateless 317 double IVI", draft-xli-behave-divi-01 (work in progress), 318 October 2009. 320 [I-D.ymbk-aplusp] 321 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 322 draft-ymbk-aplusp-09 (work in progress), February 2011. 324 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 325 Framework", RFC 5565, June 2009. 327 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 328 Infrastructures (6rd) -- Protocol Specification", 329 RFC 5969, August 2010. 331 [TR23.975] 332 "3GPP, IPv6 migration guidelines", 333 . 335 Authors' Addresses 337 Satoru Matsushima 338 Softbank Telecom 339 Tokyo Shiodome Building 340 1-9-1,Higashi-Shibashi,Minato-Ku 341 Tokyo 105-7322 342 JAPAN 344 Email: satoru.matsushima@tm.softbank.co.jp 345 Yuji Yamazaki 346 Softbank Mobile 347 Tokyo Shiodome Building 348 1-9-1,Higashi-Shibashi,Minato-Ku 349 Tokyo 105-7322 350 JAPAN 352 Email: yuyamaza@bb.softbank.co.jp 354 Chunfa Sun 355 Softbank BB 356 Tokyo Shiodome Building 357 1-9-1,Higashi-Shibashi,Minato-Ku 358 Tokyo 105-7322 359 JAPAN 361 Email: c-sun@bb.softbank.co.jp 363 Masato Yamanishi 364 Softbank BB 365 611 Wilshire Blvd., Suite 400 366 Los Angeles, CA 367 USA 369 Email: myamanis@bb.softbank.co.jp 371 Jie Jiao 372 Softbank BB 373 Tokyo Shiodome Building 374 1-9-1,Higashi-Shibashi,Minato-Ku 375 Tokyo 105-7322 376 JAPAN 378 Email: j-jiao@bb.softbank.co.jp