idnits 2.17.1 draft-carpenter-v6ops-isp-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 13, 2009) is 5309 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-03 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-07 == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-ipv6-cpe-router-01 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-04 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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: April 16, 2010 Huawei Technologies Co., Ltd 6 October 13, 2009 8 Emerging Service Provider Scenarios for IPv6 Deployment 9 draft-carpenter-v6ops-isp-scenarios-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 16, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes scenarios that are emerging among Internet 48 Service Providers for the deployment of IPv6. They are based on 49 practical experience so far, as well as current plans and 50 requirements, but they are not intended as binding recommendations. 51 [[ NOTE: This a preliminary version with incomplete content. ]] 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Review of existing documents . . . . . . . . . . . . . . . . . 4 57 3. Review of ISP experience, plans and requirements . . . . . . . 6 58 4. Lessons from experience and planning . . . . . . . . . . . . . 6 59 5. Suggested scenarios . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 11. Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Questionnaire . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 [[ NOTE: This a preliminary version with incomplete content. Later 72 sections will be filled out after the authors have obtained feedback 73 from various ISPs. This version is published to clarify our 74 intention when approaching ISPs for input. ]] 76 As is well known, the approaching exhaustion of IPv4 address space 77 will bring about a situation in which Internet Service Providers 78 (ISPs) are faced with a choice between three major alternatives: 79 1. Squeeze the use of IPv4 addresses even harder than today, using 80 smaller and smaller address blocks per customer, and possibly 81 trading address blocks with other ISPs. 82 2. Install multiple layers of network address translation, or share 83 IPv4 addresses by other methods such as address-plus-port mapping 84 [I-D.ymbk-aplusp], [I-D.boucadair-port-range]. 85 3. Deploy IPv6, and operate IPv4-IPv6 coexistence and interworking 86 mechanisms. 87 This document focuses on alternative (3), while recognizing that many 88 ISPs may be obliged by circumstances to prolong the life of IPv4 by 89 using (1) or (2) as well. 91 The document is intended as a guide to useful IPv6 deployment 92 scenarios. However, it is not a "cookbook" of operational recipes, 93 and the best choice of scenario will depend on the circumstances of 94 individual ISPs. 96 We consider various aspects of IPv6 deployment: addressing, routing, 97 DNS, management and of course IPv4 coexistence and interworking. We 98 do not consider application services in detail, but we do discuss 99 general aspects. 101 We first review several documents produced in the past by the IETF, 102 and mention relevant work in progress in the IETF. We then survey 103 requirements, plans, and practical experience from various ISPs. 104 Several deployment scenarios that result from that input are then 105 described; these are not formal recommendations, but are intended as 106 example scenarios which ISPs may choose to copy or modify to suit 107 their own technical, economic and regulatory situation. We conclude 108 with a gap analysis and security considerations. 110 The reader is assumed to be familiar with IPv6 in general. The 111 IETF's view of core IPv6 requirements is to be found in [RFC4294] 112 (currently being updated as [I-D.ietf-6man-node-req-bis]). However, 113 this does not give a complete view of mechanisms an ISP may need to 114 deploy, since it considers the requirements for an individual node, 115 not for a network as a whole. 117 2. Review of existing documents 119 [RFC4029] discusses scenarios for introducing IPv6 into ISP networks, 120 as the problem was viewed some years ago. The document is still 121 valuable as a general introduction to the process that an ISP must 122 design, but it does not consider today's situation where IPv4 123 addresses have in practical terms run out, and interworking between 124 IPv6-only and IPv4-only clients and servers must be supported in 125 addition to basic dual-stack and tunneling scenarios. We can extract 126 a list of basic issues and needs from RFC4029: 127 o Customer Premises Equipment (CPE) - must support IPv6, or allow 128 IPv6-in-IPv4 tunnels. CPE requirements and security are currently 129 being specified by the IETF [I-D.ietf-v6ops-ipv6-cpe-router], 130 [I-D.ietf-v6ops-cpe-simple-security]. 131 o Provider Edge Equipment (PE) - ditto. 132 o ISP backbone (core and border routers, switches if used) - must 133 support dual stack, or allow IPv6-in-IPv4 tunnels. An alternative 134 is a newly built IPv6 backbone that allows IPv4-in-IPv6 tunnels. 135 o Network management and monitoring applications must take IPv6 into 136 account. 137 o Customer management (e.g., RADIUS) mechanisms must be able to 138 supply IPv6 prefixes and other information to customers. 139 o Accounting and billing mechanisms must support both versions. 140 o Security mechanisms must support both versions. 142 The end goal described in RFC4029 is simply a dual-stack ISP 143 backbone. Today's view is that this is insufficient, as it does not 144 allow for interworking between IPv6-only and legacy (IPv4-only) 145 hosts. Indeed, the end goal today might be an IPv6-only ISP 146 backbone, with some form of legacy IPv4 support. 148 [RFC4779] discusses deployment in broadband access networks such as 149 CATV, ADSL and wireless. [RFC5181] deals specifically with IEEE 150 802.16 access networks. In some access scenarios, the access 151 protocol allows separately for IPv4 and IPv6, as for DOCSIS-based 152 CATV and for one variant of IEEE 802.16 [RFC5121]. In other 153 scenarios, the broadband service is essentially an emulation of raw 154 Ethernet, as for Wi-Fi, or for another variant of IEEE 802.16 155 [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16]. Another issue is 156 whether the ISP uses MPLS for back-haul from the access network, in 157 which case the 6PE [RFC4798] mechanism may be appropriate to carry 158 IPv6. 160 [RFC4942] covers IPv6 security issues, especially those that are 161 specific to transition and coexistence scenarios. The main message 162 for ISPs is that the switch to IPv6 does not mean that IP layer 163 security issues will go away, and of course security issues that are 164 not specific to the IP layer will hardly change. 166 Also related to security, [RFC4864] discusses what is referred to as 167 "Local Network Protection", i.e., how the internal structure of a 168 site network that is not hidden behind a network address translator 169 can be protected. Although not directly relevant to ISP operations, 170 this topic does affect the issue of how well an ISP's customers are 171 protected after they deploy IPv6. 173 [RFC5211] describes an independent view of a possible sequence of 174 events for IPv6 adoption in the Internet as a whole, with direct 175 implications for ISPs. Its main point, perhaps, is that by 2012 it 176 will be necessary to regard IPv4 networks as the legacy solution. 178 Although the basic IPv6 standards have long been stable, it should be 179 noted that considerable work continues in the IETF, particularly to 180 resolve the issue of highly scalable multihoming support for IPv6 181 sites, and to resolve the problem of IP layer interworking between 182 IPv6-only and IPv4-only hosts. Progress continues in various IETF 183 working groups that may affect ISP scenarios in due course. 184 o The 6MAN WG maintains the basic IPv6 standards. This work should 185 have little direct effect on ISPs. 186 o The V6OPS WG produces documents of direct interest for operational 187 practice as well as security practice. Current work includes CPE 188 requirements, CPE security, and Internet Exchange Point practice. 189 The present document will be discussed in V6OPS. 190 o The SOFTWIRE WG is working on additional protocols for IP-in-IP 191 tunnels in an ISP context. 192 o The BEHAVE WG is working on specifications for NAT64 and DNS64, 193 methods of supporting access from IPv6-only initiators to reach 194 IPv4-only services. 195 o The DHC WG maintains and extends DHCPv6. 196 o The SHIM6 WG is finalising work on a host-based protocol for IPv6 197 multihoming, based on the usage of multiple IPv6 prefixes for a 198 customer connected to multiple ISPs. 199 o The LISP WG is developing experimental standards for a scalable 200 tunnel-based routing mechanism which would, if successful, support 201 an alternative multihoming model. 203 Readers may find the current documents of these WGs via 204 . 206 The IETF is not currently discussing IPv6/IPv4 interworking at the 207 transport or application layers. The former is not generally 208 considered to be a valuable approach. The latter is considered to be 209 handled within the original dual-stack model of IPv6 deployment: 210 either one end of an application session will have dual-stack 211 connectivity, or a dual-stack intermediary such as an HTTP proxy or 212 SMTP server will interface to both IPv4-only and IPv6-only hosts. 213 While valid and useful for many common applications, this approach 214 does not solve all possible interworking issues. In any case it does 215 not require further standards work at the network layer. 217 3. Review of ISP experience, plans and requirements 219 [[ NOTE: this section will be filled out when the authors have 220 received feedback from various ISPs, by means of a questionnaire. ]] 222 4. Lessons from experience and planning 224 What was easy, what was difficult, what problems remain. 226 [[ NOTE: this section will be filled out after the previous section. 227 ]] 229 5. Suggested scenarios 231 This document does not make firm recommendations; the circumstances 232 of each ISP may be different. Rather, it describes several suggested 233 deployment scenarios that appear, from the analysis above, to have 234 the best operational characteristics. Each ISP should make its own 235 choices, according to its own technical, economic and regulatory 236 environment. 238 [[ NOTE: this section will be filled out after the previous sections. 239 It will also discuss changes since the older analyses discussed in 240 Section 2 ]] 242 6. Gap analysis 244 The analysis has shown a certain number of desirable features to be 245 missing, either in relevant specifications, or in many products. 246 This section summarizes those gaps. 248 [[ NOTE: this section will be filled out after the previous sections. 249 ]] 251 7. Security Considerations 253 [[ NOTE: this section will be filled out after the previous sections. 254 ]] 256 8. IANA Considerations 258 This document makes no request of the IANA. 260 9. Acknowledgements 262 We are grateful to all those ISPs who provided input. Some of them 263 preferred to remain anonymous. Valuable comments and contributions 264 were made by ... 266 This document was produced using the xml2rfc tool [RFC2629]. 268 10. Change log 270 draft-carpenter-v6ops-isp-scenarios-00: original version, 2009-10-13 272 11. Informative References 274 [I-D.boucadair-port-range] 275 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 276 "IPv4 Connectivity Access in the Context of IPv4 Address 277 Exhaustion: Port Range based IP Architecture", 278 draft-boucadair-port-range-02 (work in progress), 279 July 2009. 281 [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16] 282 Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP 283 over Ethernet over IEEE 802.16 Networks", 284 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 (work 285 in progress), September 2009. 287 [I-D.ietf-6man-node-req-bis] 288 Loughney, J. and T. Narten, "IPv6 Node Requirements RFC 289 4294-bis", draft-ietf-6man-node-req-bis-03 (work in 290 progress), July 2009. 292 [I-D.ietf-v6ops-cpe-simple-security] 293 Woodyatt, J., "Recommended Simple Security Capabilities in 294 Customer Premises Equipment for Providing Residential 295 IPv6 Internet Service", 296 draft-ietf-v6ops-cpe-simple-security-07 (work in 297 progress), July 2009. 299 [I-D.ietf-v6ops-ipv6-cpe-router] 300 Singh, H. and W. Beebee, "IPv6 CPE Router 301 Recommendations", draft-ietf-v6ops-ipv6-cpe-router-01 302 (work in progress), August 2009. 304 [I-D.ymbk-aplusp] 305 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 306 draft-ymbk-aplusp-04 (work in progress), July 2009. 308 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 309 June 1999. 311 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 312 Savola, "Scenarios and Analysis for Introducing IPv6 into 313 ISP Networks", RFC 4029, March 2005. 315 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 316 April 2006. 318 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 319 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 320 Access Networks", RFC 4779, January 2007. 322 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 323 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 324 Provider Edge Routers (6PE)", RFC 4798, February 2007. 326 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 327 E. Klein, "Local Network Protection for IPv6", RFC 4864, 328 May 2007. 330 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 331 Co-existence Security Considerations", RFC 4942, 332 September 2007. 334 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 335 Madanapalli, "Transmission of IPv6 via the IPv6 336 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 337 February 2008. 339 [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 340 Deployment Scenarios in 802.16 Networks", RFC 5181, 341 May 2008. 343 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 344 July 2008. 346 Appendix A. Questionnaire 348 This appendix reproduces a questionnaire that was made available for 349 ISPs to express their requirements, plans and experience. 351 TBD 353 Authors' Addresses 355 Brian Carpenter 356 Department of Computer Science 357 University of Auckland 358 PB 92019 359 Auckland, 1142 360 New Zealand 362 Email: brian.e.carpenter@gmail.com 364 Sheng Jiang 365 Huawei Technologies Co., Ltd 366 KuiKe Building, No.9 Xinxi Rd., 367 Shang-Di Information Industry Base, Hai-Dian District, Beijing 368 P.R. China 370 Email: shengjiang@huawei.com