idnits 2.17.1 draft-ietf-v6ops-isp-scenarios-00.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 date (April 15, 2010) is 5124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-PD' is mentioned on line 722, but not defined == Unused Reference: 'I-D.ietf-v6ops-cpe-simple-security' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ipv6-cpe-router' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-04 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-04 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-10 == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-ipv6-cpe-router-04 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-04 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-05 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: October 17, 2010 Huawei Technologies Co., Ltd 6 April 15, 2010 8 Emerging Service Provider Scenarios for IPv6 Deployment 9 draft-ietf-v6ops-isp-scenarios-00 11 Abstract 13 This document describes practices and plans that are emerging among 14 Internet Service Providers for the deployment of IPv6 services. They 15 are based on practical experience so far, as well as current plans 16 and requirements, reported in a survey of a number of ISPs carried 17 out in early 2010. The document identifies a number of technology 18 gaps, but does not make recommendations. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 17, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Survey of ISP's experience, plans and requirements . . . . . . 4 56 2.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. General questions about IP service . . . . . . . . . . . . 4 58 2.3. Requirements for IPv6 service . . . . . . . . . . . . . . 5 59 2.4. Status and plans for IPv6 service . . . . . . . . . . . . 5 60 2.5. IPv6 technologies . . . . . . . . . . . . . . . . . . . . 5 61 2.6. Effect of size . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Lessons from experience and planning . . . . . . . . . . . . . 7 63 4. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Product issues . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2. Protocol issues . . . . . . . . . . . . . . . . . . . . . 9 66 4.3. Documentation and general issues . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 72 Appendix A. Summary of replies . . . . . . . . . . . . . . . . . 14 73 Appendix B. Questionnaire . . . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 As is well known, the approaching exhaustion of IPv4 address space 79 will bring about a situation in which Internet Service Providers 80 (ISPs) are faced with a choice between one or more of three major 81 alternatives: 82 1. Squeeze the use of IPv4 addresses even harder than today, using 83 smaller and smaller address blocks per enterprise customer, and 84 possibly trading address blocks with other ISPs. 85 2. Install multiple layers of network address translation 86 [I-D.nishitani-cgn], or share IPv4 addresses by other methods 87 such as address-plus-port mapping [I-D.ymbk-aplusp], 88 [I-D.boucadair-port-range]. 89 3. Deploy IPv6, and operate IPv4-IPv6 coexistence and interworking 90 mechanisms. 91 This document focuses on alternative (3), while recognizing that many 92 ISPs may be obliged by circumstances to prolong the life of IPv4 by 93 using (1) or (2) while preparing for (3). 95 The document describes IPv6 deployment scenarios already adopted or 96 currently planned by a set of ISPs who responded to a technical 97 questionnaire. Thus, it is a factual record of the responses from 98 those ISPs. It makes no recommendations; the best choice of 99 scenarios will depend on the circumstances of individual ISPs. 101 We consider various aspects of IPv6 deployment: addressing, routing, 102 DNS, management, and IPv4-IPv6 coexistence and interworking. We do 103 not consider application services in detail, but we do cover general 104 aspects. 106 The reader is assumed to be familiar with IPv6. The IETF's view of 107 core IPv6 requirements is to be found in [RFC4294] (currently being 108 updated as [I-D.ietf-6man-node-req-bis]). However, this does not 109 give a complete view of mechanisms an ISP may need to deploy, since 110 it considers the requirements for an individual node, not for a 111 network or service infrastructure as a whole. 113 [RFC4029] discusses scenarios for introducing IPv6 into ISP networks, 114 as the problem was viewed some years ago. Its end goal is simply a 115 dual-stack ISP backbone. Today's view is that this is insufficient, 116 as it does not allow for interworking between IPv6-only and legacy 117 (IPv4-only) hosts. Indeed, the end goal today might be an IPv6-only 118 ISP backbone, with some form of legacy IPv4 support. 120 [RFC4779] discusses deployment in broadband access networks such as 121 CATV, ADSL and wireless. [RFC5181], [RFC5121] and 122 [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16] deal specifically 123 with IEEE 802.16 access networks. MPLS-based ISPs may use the 6PE 125 [RFC4798] mechanism. 127 [RFC4942] covers IPv6 security issues, especially those that are 128 specific to transition and IPv4-IPv6 coexistence scenarios. 129 [RFC4864] discusses "Local Network Protection", i.e., how the 130 internal structure of an IPv6 site network can be protected. This 131 affects how well an ISP's customers are protected after they deploy 132 IPv6. 134 Although the basic IPv6 standards have long been stable, it should be 135 noted that considerable work continues in the IETF, particularly to 136 resolve the issue of highly scalable multihoming support for IPv6 137 sites, and to resolve the problem of IP layer interworking between 138 IPv6-only and IPv4-only hosts. IPv6/IPv4 interworking at the 139 application layers is handled within the original dual-stack model of 140 IPv6 deployment: either one end of an application session will have 141 dual-stack connectivity, or a dual-stack intermediary such as an HTTP 142 proxy or SMTP server will interface to both IPv4-only and IPv6-only 143 hosts or applications. 145 [RFC5211] describes an independent view of a possible sequence of 146 events for IPv6 adoption in the Internet as a whole, with direct 147 implications for ISPs. Its main point, perhaps, is that by 2012 it 148 will be appropriate to regard IPv4 networks as the legacy solution. 150 2. Survey of ISP's experience, plans and requirements 152 2.1. Methodology 154 To obtain a view of the IPv6 experience, plans and requirements of 155 ISPs, a questionnaire was issued by the authors in December 2009 and 156 announced widely to the operational community. We promised to keep 157 the replies strictly confidential and to publish only combined 158 results, without identifying information about individual ISPs in any 159 published results. The raw technical questions are shown in 160 Appendix B, and a detailed summary of the replies is in Appendix A. 161 Note that although the questionnaire was widely announced, those who 162 chose to reply were self-selected and we can make no claim of 163 statistical significance or freedom from bias in the results. In 164 particular, we assume that ISPs with a pre-existing interest in IPv6 165 are more likely to have replied than others. The results should 166 therefore be interpreted with some care. 168 2.2. General questions about IP service 170 Thirty-one ISPs replied before the cutoff date for this analysis. 65% 171 of responses were from European ISPs but large operators in North 172 America and Asia/Pacific regions are included. Commercial ISPs 173 operating nationally predominate, with a vast range of size (from 30 174 customers up to 40 million). Note that some providers chose not to 175 answer about the exact number of customers. Nevertheless, it can be 176 stated that 6 providers each had millions of customers, the next 10 177 each had more than 10,000 customers, and the remaining 15 each had 178 fewer than 10,000 customers. 180 80% of the respondents offer both transit and origin-only service; 181 29% offer IP multicast service; 80% have multihomed customers. 183 A very wide variety of access technologies is used: xDSL, DOCSIS, 184 leased line (X.25, TDM/PDH, SDH), ATM, frame relay, dialup, 185 microwave, FTTP, CDMA, UMTS, LTE, WiMAX, BWA, WiFi, Ethernet (100M- 186 10G), Ethernet/SDH, MetroEthernet/MPLS. Most ISPs provide CPE to 187 some or all of their customers, but these CPE are often unable to 188 support IPv6. 190 Estimates of when ISPs will run out of public IPv4 address space for 191 internal use vary widely, between "now" and "never". Public IPv4 192 address space for customers is mainly expected to run out between 193 2010 and 2015, but four or five ISPs suggested it will never happen, 194 or at least not in the foreseeable future. About 19% of ISPs offer 195 RFC 1918 space to customers, and about 39% use such addresses 196 internally. 198 2.3. Requirements for IPv6 service 200 61% of ISPs report that some big customers are requesting IPv6. 201 Predictions for when 10% of customers will require IPv6 range from 202 2010 to 2017, and for 50% from 2011 to 2020. These ISPs require IPv6 203 to be a standard service by 2010 to 2015; the most common target date 204 is 2011. 206 2.4. Status and plans for IPv6 service 208 42% of ISPs already offer IPv6 as a regular service, although in 209 general it is used by fewer than 1% of customers. Another 48% of 210 ISPs have IPv6 deployment in progress or planned. These all plan at 211 least beta-test service in 2010. Planned dates for regular service 212 are between 2010 and 2013 (except for one ISP who replied that it 213 depends on the marketing department). When asked when IPv6 will 214 reach 50% of total traffic, the most common answer is 2015. 216 2.5. IPv6 technologies 218 Turning to technology choices, the overwhelming choice of approach 219 (94%) is a dual stack routing backbone, and the reason given is 220 simplicity and cost. 39% run, or plan to run, a 6to4 relay as well, 221 and 16% run or plan a Teredo server. However, 77% of ISPs don't have 222 or plan any devices dedicated to IPv6. A different 77% don't see 223 IPv6 as an opportunity to restructure their network topology. 225 When asked which types of equipment are unable to support IPv6, the 226 most common answer was CPE (10 mentions). Also mentioned: handsets; 227 DSLAMs; routers (including several specific models); traffic 228 management boxes; load balancers; VPN boxes; some SIP platforms; 229 management interfaces & systems; firewalls; billing systems. When 230 asked if such devices can be field-upgraded, the answers were gloomy: 231 5 yes, 4 partially, 10 no, and numerous "don't know" or "hopefully". 233 84% support or plan DNS AAAA queries over IPv6, and all but one of 234 these include reverse DNS lookup for IPv6. 236 The ISPs surveyed have prefixes ranging from /19 to /48, and have a 237 variety of policies for customer prefixes. Fifteen ISPs offer more 238 than one of /48, /52, /56, /60 or /64. Two offer /56 only, eight 239 offer /48 only. Two wired operators offer /64 only. Mobile 240 operators offer /64 in accordance with 3GPP, but at least one would 241 like to be allowed to offer /128 or /126. Also, as many as 30% of 242 the operators already have IPv6 customers preferring a PI (provider 243 independent) prefix. The methods chosen for prefix delegation to 244 CPEs are manual, DHCPv6[-PD], SLAAC, RADIUS, and PPPoE (although in 245 fact the latter two cannot assign a prefix on their own). 247 About 50% of ISPs already operate or plan dual-stack SMTP, POP3, IMAP 248 and HTTP services. In terms of internal services, it seems that 249 firewalls, intrusion detection, address management, monitoring, and 250 network management tools are also around the 50% mark. However, 251 accounting and billing software is only ready at 23% of ISPs. 253 Considering IPv4-IPv6 interworking, 58% of ISPs don't expect to have 254 IPv6-only customers (but mobile operators are certain they will have 255 millions). Five ISPs report customers who explicitly refused to 256 consider IPv6. When asked how long customers will run IPv4-only 257 applications, the most frequent answer is "more than ten years". 258 Only three ISPs state that IPv6-IPv4 interworking at the the IP layer 259 is not needed. On the other hand, only three (a different three!) 260 run or plan to run NAT-PT. At least 30% plan to run some kind of 261 translator (presumably NAT64/DNS64), but only two felt that a 262 multicast translator was essential. Among those who do not plan a 263 translator, when asked how they plan to connect IPv6-only customers 264 to IPv4-only services, seven rely on dual stack and four have no plan 265 (one said, paraphrasing, "it's their problem"). 267 Asked about plans for Mobile IPv6 (or Nemo mobile networks), 19% said 268 yes, and 71% said no, with the others uncertain. A detailed analysis 269 shows that of the six ISPs who responded positively, three are large 270 mobile operators (and a fourth mobile operator said "No"). The other 271 three who responded positively were broadband ISPs ranging from small 272 to very large. 274 2.6. Effect of size 276 We examined the data to see whether any other differences emerge 277 between the very large (millions of customers), medium (at least 278 10,000), and small (fewer than 10,000) operators. However, the range 279 of answers seems to be broadly similar in all cases. The major 280 exception is that among the six very large operators, one plans to 281 use 6PE and DS-lite, and another to use 6VPE, instead of a simple 282 dual stack. The other large operators and all the medium and small 283 operators prefer a simple dual stack. 285 3. Lessons from experience and planning 287 This section is assembled and paraphrased from general comments made 288 in the various questionnaire responses. Any inconsistencies or 289 contradictions are present in the original data. Comments related to 290 missing features and products have been included in Section 4. 292 As noted in the summary above, the ISPs that responded overwhelmingly 293 prefer a native dual stack deployment. Numerous comments mentioned 294 the simplicity of this model and the complexity and sub-optimal 295 routing of tunnel-based solutions. Topology redesign is not 296 generally considered desirable, because congruent IPv4 and IPv6 297 topology simplifies maintenance and engineering. Nevertheless, 6to4 298 is considered convenient for cable modem (DOCSIS) users and 6RD is 299 considered an attractive model by some. Various operators, but by no 300 means all, also see a need for Teredo. One very large MPLS-based 301 operator prefers 6PE because it avoids an IPv6 IGP and reduces 302 operational costs. This operator also sees IPv4 scarcity addressed 303 by DS-lite [I-D.ietf-softwire-dual-stack-lite] and Carrier Grade NAT, 304 also acting as a catalyst for IPv6. Another very large operator with 305 an existing NAT44 infrastructure plans to use 6VPE [RFC4659] and 306 believes that NAT64 will be similar to NAT44 in support requirements. 308 Several ISPs observe that IPv6 deployment is technically not hard. 309 The most eloquent statement: "Just do it, bit by bit. It is very 310 much an 'eating the elephant' problem, but at one mouthful at a time, 311 it appears to be surprisingly easy." Other comments paraphrased from 312 the replies are: 314 o Despite the known gaps, the tools and toolkits are fairly mature 315 at this point. 316 o Managerial commitment and a systematic approach to analysing 317 requirements and readiness are essential. 318 o Evangelization remains a must, as it seems that many ISP and IT 319 managers are still unaware of the need for an IPv6 plan, and are 320 inclined to dismiss IPv4 depletion as a false alarm, and also seem 321 unaware that NATs create expensive support requirements. 322 o Without customers wanting IPv6, getting business backing is very 323 hard, and IPv6 security and scale was not a focus for vendors 324 until very recently. 325 o Operators lack real experience with customer usage of IPv6, and 326 the resulting lack of confidence causes delay. 328 Three further quotations are of interest: 330 "We are planning to move all our management addressing from IPv4 to 331 IPv6 to free up IPv4 addresses." 333 "I am actively pushing our larger customers to start testing IPv6 as 334 our development has pretty much stopped as we need some real world 335 testing to be done." 337 "Customer support needs to be aware that IPv6 is being started in 338 your network, or servers. We experienced many IPv6 blocking 339 applications, applications that do not fall back to IPv4, etc. The 340 most difficult part may be to get engineers, sales, customer support 341 personnel to like IPv6." 343 4. Gap analysis 345 The survey has shown a certain number of desirable features to be 346 missing, either in relevant specifications, or in many products. 347 This section summarizes those gaps. 349 4.1. Product issues 351 As noted above, numerous models of various types of product still do 352 not support IPv6: 353 o CPE 354 o Handsets 355 o DSLAMs 356 o Routers 357 o Traffic management boxes 358 o Load balancers 359 o VPN boxes 360 o SIP and other appliances 361 o Management interfaces and systems 362 o Firewalls. 363 o Even where they support IPv6, customer side firewalls and routers 364 need to operate at 25-100 Mbit/s. 365 o Intrusion detection systems 366 o Accounting and billing systems 368 It is not the purpose of this document to name and shame vendors, but 369 it is today becoming urgent for all products to avoid becoming part 370 of the IPv4 legacy. ISPs stated that they want consistent feature- 371 equal support for IPv4 and IPv6 in all equipment and software at 372 reasonable or no extra cost. The problems can be quite subtle: for 373 example, one CPE with "full" IPv6 support does not support IPv6 374 traffic shaping, so the ISP cannot cap IPv6 traffic to contractual 375 limits. 377 Numerous ISPs want a scaleable NAT64/DNS64 product. 379 The need for IPv6 support in "all the best open source tools" was 380 also mentioned. 382 Several ISPs also noted that much commercial applications software 383 does not correctly support IPv6 and that this will cause customer 384 problems. Also, some operating systems are still shipped with IPv6 385 disabled by default, or with features such as IPv4-mapped addresses 386 disabled by default. 388 4.2. Protocol issues 390 Various needs and issues related mainly to protocols were mentioned: 391 o A specific CPE need is an intelligent prefix sub-delegation 392 mechanism (ease of use issue). 393 o "Getting it right" so that a dual stack client doesn't end up 394 trying to use the wrong transport to reach a site. 395 o "User-side port allocation mechanisms. UPnP IGD and NAT-PMP can 396 be used for IPv4, but nothing exists for IPv6 (yet)". [Editor's 397 comment: even though port mapping is in principle unnecessary for 398 IPv6, a method of opening ports through firewalls on demand seems 399 necessary.] 400 o Full RA support on LAN side of ADSL CPE. 401 o PPPoE and RADIUS support. Specifically, global unicast address 402 assignment for L2TP/PPPoE. Currently the PPPoE client will be 403 assigned a link-local address, requiring a second step (DHCPv6 or 404 SLAAC). 406 o Simple automatic distribution of DNS server details is essential; 407 a DNS server option in RA [RFC5006] is wanted. 408 o ISPs need fully featured DHCPv6, especially since SLAAC does not 409 allow settings to be pushed out (except for RFC 5006). 410 o Firewall systems should not use separate IPv4 and IPv6 rules. 411 o Gaps in infrastructure security for IPv6 management. 412 o Gaps in routers' treatment of header options. 413 o RA-Guard in switches. 414 o VRRP support. 415 o PE-CE routing protocols (OSPF and IS-IS). 416 o Problems using a single BGP session to exchange routes for both 417 IPv4 and IPv6. 418 o Consistent IPv6 address display format in outputs and 419 configuration input. Inconsistency breaks a lot of existing 420 tools. 422 4.3. Documentation and general issues 424 We also note areas where there was clearly confusion among the ISPs 425 responding, which may denote weaknesses of existing documentation: 426 o Perhaps due to poor phrasing in the survey questions, some ISPs 427 indicated that they would use PPPoE or RADIUS to assign prefixes 428 to CPEs. In fact, IPv6 PPP only negotiates 64 bit interface 429 identifiers; a full address has to be assigned by another method, 430 and even this does not delegate a prefix to a CPE router. RADIUS 431 alone is also insufficient, as it needs to be combined with 432 another method for full address assignment. 433 o Although most ISPs see a need for IPv4-IPv6 interworking at the 434 network layer, many of them do not see a need for an ISP to 435 operate the resulting translator. Yet their customers, whether 436 subscribers or content providers, will be the first to suffer when 437 IPv6-only clients cannot reach IPv4-only services. 438 o Most ISPs seemed to misunderstand the nature of a tunnel broker, 439 even though this is a service that any ISP could consider offering 440 to its subscribers. 442 Global IPv6 connectivity still has issues; for example ISPs in the 443 Pacific region may have to obtain IPv6 transit via the USA (a 444 situation faced by IPv4 operators in Europe about twenty years ago). 445 Also, there are persistent PMTUD issues in various places on the net, 446 and a lack of multicast peering. 448 Finally, there was a comment that real deployment case studies must 449 be shown to operators, along with multihoming and traffic engineering 450 best practices. 452 5. Security Considerations 454 As a report on a survey, this document creates no security issues in 455 itself. ISPs did not register any general concerns about IPv6 456 security. However, we note that about half of all firewall and 457 intrusion detection products are still reported not to support IPv6. 458 Some ISPs expressed concern about firewall performance and about the 459 need for separate firewall configurations for IPv4 and IPv6. 461 6. IANA Considerations 463 This document makes no request of the IANA. 465 7. Acknowledgements 467 We are grateful to all those who answered the questionnaire: Stewart 468 Bamford, Pete Barnwell, Cameron Byrne, Gareth Campling, Kevin 469 Epperson, David Freedman, Wesley George, Steinar Haug, Paul 470 Hoogsteder, Mario Iseli, Christian Jacquenet, Kurt Jaeger, Seiichi 471 Kawamura, Adrian Kennard, Simon Leinen, Riccardo Loselli, Janos 472 Mohacsi, Jon Morby, Michael Newbery, Barry O'Donovan, Al Pooley, 473 Antonio Querubin, Anthony Ryan, Marc Schaeffer, Valeriu Vraciu, Bill 474 Walker and those who preferred to remain anonymous. 476 The ISPs willing to be named were: AISP, Alphanet, Breedband Delft, 477 Claranet, E4A, Fidonet, Finecom, France Telecom, Hungarnet, Imagine, 478 LavaNet, Level 3 Communications LLC, NEC BIGLOBE, Nepustilnet, Net 479 North West, RoEduNet, SWITCH, Snap, Sprint, Star Technology, T-Mobile 480 USA, Ventelo, and Whole Ltd. 482 Useful comments and contributions were also made by Shane Amante, 483 Mohamed Boucadair, Mark Smith, and others. 485 This document was produced using the xml2rfc tool [RFC2629]. 487 8. Change log 489 draft-ietf-v6ops-isp-scenarios-00: added 31st ISP, updated according 490 to WG comments, general editorial improvements, renamed draft, 2010- 491 04-15 493 draft-carpenter-v6ops-isp-scenarios-02: updated summary and 494 discussion of questionnaire results, deleted material to repurpose 495 document as survey results only, 2010-04-13 496 draft-carpenter-v6ops-isp-scenarios-01: added summary and discussion 497 of questionnaire results, 2010-02-23 499 draft-carpenter-v6ops-isp-scenarios-00: original version, 2009-10-13 501 9. Informative References 503 [I-D.boucadair-port-range] 504 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 505 "IPv4 Connectivity Access in the Context of IPv4 Address 506 Exhaustion: Port Range based IP Architecture", 507 draft-boucadair-port-range-02 (work in progress), 508 July 2009. 510 [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16] 511 Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP 512 over Ethernet over IEEE 802.16 Networks", 513 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 (work 514 in progress), September 2009. 516 [I-D.ietf-6man-node-req-bis] 517 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 518 Requirements RFC 4294-bis", 519 draft-ietf-6man-node-req-bis-04 (work in progress), 520 March 2010. 522 [I-D.ietf-softwire-dual-stack-lite] 523 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 524 Y., and R. Bush, "Dual-Stack Lite Broadband Deployments 525 Following IPv4 Exhaustion", 526 draft-ietf-softwire-dual-stack-lite-04 (work in progress), 527 March 2010. 529 [I-D.ietf-v6ops-cpe-simple-security] 530 Woodyatt, J., "Recommended Simple Security Capabilities in 531 Customer Premises Equipment for Providing Residential IPv6 532 Internet Service", draft-ietf-v6ops-cpe-simple-security-10 533 (work in progress), March 2010. 535 [I-D.ietf-v6ops-ipv6-cpe-router] 536 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 537 Troan, "Basic Requirements for IPv6 Customer Edge 538 Routers", draft-ietf-v6ops-ipv6-cpe-router-04 (work in 539 progress), January 2010. 541 [I-D.nishitani-cgn] 542 Yamagata, I., Nishitani, T., Miyakawa, S., Nakagawa, A., 543 and H. Ashida, "Common requirements for IP address sharing 544 schemes", draft-nishitani-cgn-04 (work in progress), 545 March 2010. 547 [I-D.ymbk-aplusp] 548 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 549 draft-ymbk-aplusp-05 (work in progress), October 2009. 551 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 552 June 1999. 554 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 555 Savola, "Scenarios and Analysis for Introducing IPv6 into 556 ISP Networks", RFC 4029, March 2005. 558 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 559 April 2006. 561 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 562 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 563 IPv6 VPN", RFC 4659, September 2006. 565 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 566 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 567 Access Networks", RFC 4779, January 2007. 569 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 570 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 571 Provider Edge Routers (6PE)", RFC 4798, February 2007. 573 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 574 E. Klein, "Local Network Protection for IPv6", RFC 4864, 575 May 2007. 577 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 578 Co-existence Security Considerations", RFC 4942, 579 September 2007. 581 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 582 "IPv6 Router Advertisement Option for DNS Configuration", 583 RFC 5006, September 2007. 585 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 586 Madanapalli, "Transmission of IPv6 via the IPv6 587 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 588 February 2008. 590 [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 591 Deployment Scenarios in 802.16 Networks", RFC 5181, 592 May 2008. 594 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 595 July 2008. 597 Appendix A. Summary of replies 599 This summarises the 31 replies received by April 14, 2010. Note that 600 the answers to some questions do not total to 31, due to missing 601 answers or to multiple choices in some cases. The ISPs are 602 distributed as follows: 603 Europe: 20 604 North America: 7 605 Asia/Pacific: 4 607 They can additionally be classified as: 608 Commercial: 26 609 Academic/research: 4 610 Operating internationally: 6 611 Operating nationally: 25 613 Basic data about IP service offerings: 614 o Offering both origin-only and transit service: 25 615 o Offering no transit: 6 616 o Number of private/small office customers (one IPv4 address): a few 617 with zero, then from 30 units up to 40 million 618 o Number of corporate customers (block of IPv4 addresses): a few 619 with zero, then from 40 units up to 40000 620 o IP multicast service? 9 yes, 22 no 621 o Do any customers require multihoming to multiple ISPs? 25 yes, 6 622 no 623 o Access technologies used: xDSL, DOCSIS, leased line (X.25, TDM/ 624 PDH, SDH), ATM, frame relay, dialup, microwave, FTTP, CDMA, UMTS, 625 LTE, WiMAX, BWA, WiFi, Ethernet (100M-10G), Ether/SONET, Ether/ 626 MPLS, IPv6-in-IPv4 tunnels 628 Customer Premises Equipment: 629 o Do customers use CPE that ISP supplies? 27 yes (10% to 100% of 630 customers), 4 no 631 o Does the CPE provided support native IPv6? 17 yes (some), 10 no 632 o (Note that these numbers include answers that apply to tens of 633 millions of mobile handsets.) 635 IPv4 Address Space: 637 o When do you expect to run out of public IPv4 address space inside 638 your own network? Estimates run from "now" to 2020, but 5 ISPs 639 say "never" or "unforeseeable". 640 o Do you run RFC1918 addresses and NAT within your network? 9 yes; 641 18 no; 3 others say yes, but only for equipment management or 642 L3VPN. 643 o What % of IPv4 space is needed for ISP use (not for customers)? 1% 644 to 30% (and 100% for NRENs with PI customers). 645 o When do you expect to run out of public IPv4 address space for 646 customers? Answers range from 2010 to 2015; 4 ISPs say it depends 647 on their registry. 4 or 5 give answers suggesting it will never 648 happen. 649 o Do you offer RFC1918 addresses to customers? 6 yes, 24 no 651 IPv6 Requirements: 652 o Are some big customers requesting IPv6? 19 yes, 12 no 653 o When do you predict 10% and 50% of customers to require IPv6 654 service? Ignoring unclear answers, answers for 10% range from 655 2010 to 2017, and for 50% from 2011 to 2020. 656 o When do you require IPv6 to be a standard service available to all 657 customers? Answers range from 2010 to 2015; the most common 658 answer is 2011. 659 o When do you predict IPv6 traffic to reach 50% of total traffic? 660 Answers range from 2011 to 2020; the most common answer is 2015. 662 IPv6 Status and Plans: 663 o Do you currently offer IPv6 as a regular service? 13 yes, 5 664 partial, 12 no 665 o What % of customers currently use IPv6? <1% to 30%; mostly 0 or 666 <1% 667 o When do you plan to start IPv6 deployment? 12 complete, 12 in 668 progress, 3 in plan, 4 have no plan 669 o When do you plan to offer IPv6 as a special or beta-test service? 670 For all those in progress or with a plan, the answer was either 671 "now" or during 2010. 672 o When do you plan to offer IPv6 as a regular service to all 673 customers? For all those in progress or with a plan, the answer 674 was between "now" and 2013 (except for one ISP who replied that it 675 depends on the marketing department). 677 IPv6 Technologies. Note the answers refer to actual deployment or to 678 plans, as the case may be: 679 o Which basic IPv6 access method(s) apply? 680 * Dual stack routing backbone: 29 yes, 1 maybe 681 * Separate IPv4 and IPv6 backbones: 2 yes, 1 maybe 682 * 6to4 relay: 12 yes 683 * Teredo server: 5 yes 684 * Tunnel broker: Unfortunately this question was unclear and 685 obviously misunderstood by most respondents. Several 686 respondents mentioned that they are getting their own transit 687 connectivity via static tunnels. 688 * Something else: Answers were 6VPE + NAT64/DNS64; PNAT; 689 "considering 6RD" 690 o Please briefly explain the main reasons/issues behind your choice: 691 The best summary of the answers is "dual stack is simplest, why do 692 anything else?". 693 o Which types of equipment in your network are unable to support 694 IPv6? The most common answer was CPE (9 mentions). Also 695 mentioned: handsets; DSLAMs; routers (including several specific 696 models); traffic management boxes; load balancers; VPN boxes; some 697 SIP platforms; management interfaces & systems; firewalls; billing 698 systems. 699 o Can they be field-upgraded? 5 yes, 4 partially, 10 no and numerous 700 "don't know" or "hopefully" 701 o Is any equipment 100% dedicated to IPv6? 7 yes, 24 no 702 o Is IPv6 an opportunity to restructure your whole topology? 2 yes, 703 5 partial, 23 no 704 o Do you include support for DNS AAAA queries over IPv6? 21 yes, 5 705 plan, 4 no 706 o Do you include support for reverse DNS for IPv6 addresses? 22 yes, 707 3 plan, 5 no 708 o What length(s) of IPv6 prefix do you have or need from the 709 registry? 1 /19, 1 /21 (plus several /32s), 1 /22 1 /30, 3 710 multiple /32s, 21 /32, 3 /48 711 o What length(s) of IPv6 prefix are offered to customers? 15 ISPs 712 offer more than one of /48, /52, /56, /60 or /64. 2 offer /56 713 only, 8 offer /48 only. Two wired operators offer /64 only. 714 Mobile operators offer /64 in accordance with 3GPP, but at least 715 one would like to be allowed to offer /128 or /126. 716 o Do any customers share their IPv6 prefix among multiple hosts? 717 Unfortunately this question was unclear and obviously 718 misunderstood by most respondents. 719 o Do any of your customers prefer to use PI IPv6 prefixes? 10 yes, 720 17 no 721 o How are IPv6 prefixes delegated to CPEs? 16 manual, 10 722 DHCPv6[-PD], 8 SLAAC, 8 RADIUS, 2 PPPoE. (Note: RADIUS and PPP 723 cannot in fact delegate prefixes.) 724 o Are your SMTP, POP3 and IMAP services dual-stack? 10 yes, 6 plan, 725 13 no 726 o Are your HTTP services, including caching and webmail, dual-stack? 727 9 yes, 1 partial, 4 plan, 15 no 728 o Are any other services dual-stack? 11 yes, 2 plan, 11 no 729 o Is each of the following dual-stack? 730 * Firewalls: 12 yes, 3 partial, 3 plan, 9 no 731 * Intrusion detection: 10 yes, 2 plan, 13 no 732 * Address management software: 15 yes, 1 plan, 13 no 733 * Accounting software: 7 yes, 21 no 734 * Monitoring software: 16 yes,2 partial,2 plan, 11 no 735 * Network management tools: 13 yes, 4 partial,1 plan, 11 no 736 o Do you or will you have IPv6-only customers? 13 yes (or maybe), 18 737 no (or not likely) 738 o Do you have customers who have explicitly refused to consider 739 IPv6? 5 yes, 23 no 740 o Interworking issues: 741 * How many years do you expect customers to run any IPv4-only 742 applications? Answers range from 2 years to infinity, most 743 frequent answer is >10 years. 744 * Is IPv6-IPv4 interworking at the the IP layer needed? 16 yes,9 745 uncertain, 3 no 746 * Do you include a NAT-PT IPv6/IPv4 translator? 2 yes,1 plan, 26 747 no 748 * If yes, does that include DNS translation? 1 plan, 2 no 749 * If not, do you plan to operate an IPv6/IPv4 translator? 10 plan 750 (NAT64), 8 no, others uncertain 751 * If not, how do you plan to connect IPv6-only customers to IPv4- 752 only services? 7 rely on dual stack; 4 have no plan (one said 753 "their problem") 754 * If you offer IP multicast, will that need to be translated too? 755 2 yes, 2 uncertain, 5 no 756 o Any plans for Mobile IPv6 (or Nemo mobile networks)? 6 yes,2 757 uncertain, 22 no 759 Appendix B. Questionnaire 761 This appendix reproduces the technical body of the questionnaire that 762 was made available for ISPs to express their requirements, plans and 763 experience. 765 I. General questions about IP service 766 1.Do you offer origin-only (stub, end-user) IP service, transit IP 767 service, or both? 768 2.Approximate number of private/small office customers (one IPv4 769 address) 770 3.Approximate number of corporate customers (block of IPv4 771 addresses, not included in Q2) 772 4.Do you offer IP multicast service? 773 5.Do any of your customers require multihoming to multiple ISPs? 774 6.Access technologies used (ADSL,etc.) 775 7.Do your customers use CPE that you supply? 776 7.1.What % of customers? 777 7.2.Does the CPE that you provide support native IPv6? 778 8.When do you expect to run out of public IPv4 address space 779 inside your own network? 780 8.1.Do you run private (RFC1918) addresses and NAT within your 781 network (i.e., a second layer of NAT in the 782 case of customers with their own NAT)? 783 8.2.What % of your IPv4 space is needed for your own use (not for 784 customers)? 785 9.When do you expect to run out of public IPv4 address space for 786 customers? 787 9.1.Do you offer private (RFC1918) addresses to your customers? 788 II. Questions about requirements for IPv6 service 789 10.Are some big customers requesting IPv6? 790 11.When do you predict 10% and 50% of your customers to require 791 IPv6 service? 792 12.When do you require IPv6 to be a standard service available to 793 all customers? 794 13.When do you predict IPv6 traffic to reach 50% of total traffic? 795 III. Questions about status and plans for IPv6 service 796 14.Do you currently offer IPv6 as a regular service? 797 14.1.What % of your customers currently use IPv6? 798 14.2.When do you plan to start IPv6 deployment? 799 14.3.When do you plan to offer IPv6 as a special or beta-test 800 service to customers? 801 15.When do you plan to offer IPv6 as a regular service to all 802 customers? 803 IV. Questions about IPv6 technologies 804 16.Which basic IPv6 access method(s) apply: 805 16.1. dual stack routing backbone? 806 16.2. separate IPv4 and IPv6 backbones? 807 16.3. 6to4 relay? 808 16.4. Teredo server? 809 16.5. tunnel broker? If so, which one? 810 16.6. Something else? Please briefly describe your method: 811 16.7. If possible, please briefly explain the main reasons/issues 812 behind your choice. 813 17.Which types of equipment in your network are unable to support 814 IPv6? 815 17.1.Can they be field-upgraded to support IPv6? 816 17.2.Is any equipment 100% dedicated to IPv6? 817 18.Is IPv6 an opportunity to restructure your whole topology? 818 19.Do you include support for DNS AAAA queries over IPv6? 819 20.Do you include support for reverse DNS for IPv6 addresses? 820 21.What length(s) of IPv6 prefix do you have or need from the 821 registry? 822 22.What length(s) of IPv6 prefix are offered to customers? 823 22.1.Do any customers share their IPv6 prefix among multiple 824 hosts? 825 23.Do any of your customers prefer to use PI IPv6 prefixes instead 826 of a prefix from you? 827 24.How are IPv6 prefixes delegated to CPEs? (Manual, PPPoE, 828 RADIUS, DHCPv6, stateless autoconfiguration/RA, etc...) 829 25.Are your SMTP, POP3 and IMAP services dual-stack? 830 26.Are your HTTP services, including caching and webmail, dual- 831 stack? 832 27.Are any other services dual-stack? 833 28.Is each of the following dual-stack? 834 28.1.Firewalls 835 28.2.Intrusion detection 836 28.3.Address management software 837 28.4.Accounting software 838 28.5.Monitoring software 839 28.6.Network management tools 840 29.Do you or will you have IPv6-only customers? 841 30.Do you have customers who have explicitly refused to consider 842 IPv6? 843 31.How many years do you expect customers to run any IPv4-only 844 applications? 845 32.Is IPv6-IPv4 interworking at the the IP layer needed? 846 33.Do you include a NAT-PT IPv6/IPv4 translator? 847 33.1.If yes, does that include DNS translation? 848 33.2.If not, do you plan to operate an IPv6/IPv4 translator? 849 33.3.If not, how do you plan to connect IPv6-only customers to 850 IPv4-only services? 851 33.4.If you offer IP multicast, will that need to be translated 852 too? 853 34.Any plans for Mobile IPv6 (or Nemo mobile networks)? 854 35.What features and tools are missing today for IPv6 deployment 855 and operations? 856 36.Any other comments about your IPv6 experience or plans? What 857 went well, what was difficult, etc. 859 Authors' Addresses 861 Brian Carpenter 862 Department of Computer Science 863 University of Auckland 864 PB 92019 865 Auckland, 1142 866 New Zealand 868 Email: brian.e.carpenter@gmail.com 870 Sheng Jiang 871 Huawei Technologies Co., Ltd 872 KuiKe Building, No.9 Xinxi Rd., 873 Shang-Di Information Industry Base, Hai-Dian District, Beijing 874 P.R. China 876 Email: shengjiang@huawei.com