idnits 2.17.1 draft-jcurran-v6transitionplan-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2008) is 5783 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2050 (Obsoleted by RFC 7020) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John Curran 2 Expires: November 1, 2008 May 19, 2008 3 Intended status: Informational 5 An Internet Transition Plan 6 draft-jcurran-v6transitionplan-03 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 1, 2008. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2008). 37 Abstract 39 This memo provides one possible plan for transitioning the Internet 40 from a predominantly IPv4-based connectivity model to a predominantly 41 IPv6-based connectivity model. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 RFC 2119 defines the use of these key words to help make the intent 49 of standards track documents as clear as possible. While not a 50 standards track document, the same key words are used in this 51 document only for sake of clarity in describing the proposed 52 transition plan. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. A Phased Transition Model . . . . . . . . . . . . . . . . . . . 2 58 2.1 Preparation Stage . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2 Transition Stage . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3 Post-Transition Stage . . . . . . . . . . . . . . . . . . . . 4 61 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Intellectual Property and Copyright Statements . . . . . . . . . . 8 72 1. Introduction 74 This memo provides one possible plan for transitioning the Internet 75 from a predominantly IPv4-based connectivity model to a predominantly 76 IPv6-based connectivity model. 78 Other transition plans are possible and this purely informational 79 document does not create an obligation on any party to undertake any 80 of the actions specified herein, and the use of requirements language 81 per RFC 2119 is only for the purpose of clearly describing the 82 proposed transition plan in unambiguous terms. 84 The motivation for an Internet-wide transition plan is to facilitate 85 coordination of expectations among innumerable, highly decentralized 86 entities during a period of significant change, thus reducing risk to 87 the defining Internet property of universal connectivity. 89 The purpose of specifying this particular transition plan is to allow 90 for overall assessment of the challenges of accomplishing the desired 91 transition and to continue the discussion of Internet-wide transition 92 plans in general. 94 2. A Phased Transition Model 96 It is not reasonable to specify the changes that each and every system 97 connected to the Internet must undergo in order to achieve the desired 98 transition, as the number of connected systems precludes creating one 99 plan that contains such a level of detail. Further, while there are 100 common scenarios that may be specified for transitioning individual 101 networks (refer to [RFC3750] [RFC4057] and [CAMPUS]), the specific 102 timeline and mechanisms utilized for a given network will be unique. 103 Despite these challenges, it is necessary to coordinate expectations 104 on an overall basis so that Internet-wide connectivity is maintained 105 throughout the transition. 107 This document specifies a three phase transition plan that includes 108 preparation, transition, and post-transition phases, and delineates 109 the necessary activities within each phase based on the role that an 110 organization plays in the provision and use of Internet services. 112 An important distinction made in this transition plan is identifying 113 the explicit requirement for existing end-site organizations to add 114 IPv6-based connectivity to their public-facing servers during a 115 transition phase. An accelerated adoption of IPv6 for public-facing 116 servers enables new organizations in the post-transition phase to be 117 connected to the Internet only via IPv6 and still have access to a 118 substantial representative base of publicly available servers. 120 For nearly every organization, the task of IPv6-enabling their public 121 facing servers is far easier than undertaking an organization-wide 122 adoption of IPv6. Still, the requirement for existing Internet 123 connected organizations to add IPv6 connectivity (even to a small 124 number of systems) will be a significant hurdle and require a level 125 of effort which may not be achievable given the lack of compelling 126 additional benefits to these organizations [RFC1669]. This transition 127 plan presumes that "connectivity is its own reward" [RFC1958] and 128 that there still exists a sufficient level of cooperation among 129 Internet participants to make this evolution possible. 131 The three proposed phases are: Preparation Phase, Transition Phase, 132 and Post-Transition Phase. The timeline for the phases has been set 133 to allow entry to the Post-Transition Phase prior to the projected 134 IPv4 address pool exhaustion date [IPUSAGE]. 136 2.1 Preparation Phase - Present to December 2009 138 In the Preparation Phase, Service Providers pilot test their 139 IPv6 network services, and end-site organizations prepare to 140 provide Internet facing services via IPv6-based connectivity 141 while continuing to provide Internet-facing services via IPv4 142 connectivity. 144 During the Preparation Phase, the following principles apply: 146 2.1.1 Service Providers SHOULD offer pilot IPv6-based Internet 147 Service to their Internet customers. IPv6-based Internet 148 Service MAY be provided via IPv6 transition mechanisms 149 (such as those described in [RFC4213] for example) or 150 via native IPv6 network service. 151 2.1.2 Organizations SHOULD arrange for IPv6-based Internet 152 connectivity for any Internet-facing servers (e.g. web, 153 email, and domain name servers). Internet-facing IPv6 154 servers in this phase SHOULD use separate service names 155 per [RFC4472] to avoid impact to production IPv4-based 156 services unless the organization supports production 157 IPv6 connectivity. 158 2.1.3 Organizations MAY provide IPv6-based Internet connectivity 159 to internal user communities. 161 2.2 Transition Phase - January 2010 to December 2011 163 In the Transition Phase, Service Providers offer production 164 IPv6 and IPv4 services to their Internet customers. End-site 165 organizations provide Internet-facing services in a production 166 manner via IPv6-based connectivity in addition to IPv4-based 167 connectivity. 169 During the Transition Phase, the following principles apply: 171 2.2.1 Service Providers MUST offer IPv6-based Internet Service to 172 their Internet customers. IPv6-based Internet Service SHOULD 173 be via native IPv6 network service but MAY be via IPv6 174 transition mechanisms if necessary. 175 2.2.2 Organizations MUST arrange for IPv6-based Internet 176 connectivity for any Internet-facing servers (e.g. web, 177 email, and domain name servers). Internet-facing IPv6 178 servers SHOULD be treated as production by the organization, 179 and SHOULD be treated as production by other Internet 180 organizations. 181 2.2.3 Organizations SHOULD provide IPv6-based Internet connectivity 182 to their internal user communities, and provide IPv6 internal 183 supporting servers (e.g. DNS, DHCP). IPv6-based Internet 184 connectivity MAY be via native IPv6 network service or MAY 185 be via IPv6 transition mechanisms. 187 2.3 Post-Transition Phase - January 2012 to the Future 189 In the Post-Transition Phase, End-site organizations provide all 190 Internet-facing services via IPv6-based connectivity, thus allowing 191 for new Internet customers connected solely by IPv6. 193 During the Post-Transition Phase, the following principles apply: 195 2.3.1 Service Providers MUST offer IPv6-based Internet Service to 196 their Internet customers. IPv6-based Internet Service SHOULD 197 be via native IPv6 network service. 198 2.3.2 Organizations MUST arrange for IPv6-based Internet connectivity 199 for any Internet-facing servers (e.g. web, email, and domain 200 name servers). Internet-facing IPv6 servers MUST be treated 201 as production by the organization, and SHOULD be treated as 202 production by other Internet organizations. 203 2.3.3 Organizations SHOULD provide IPv6-based Internet connectivity to 204 internal user communities, and provide IPv6 internal supporting 205 infrastructure (e.g. routers, DNS, DHCP, etc). IPv6-based 206 Internet connectivity SHOULD be via native IPv6 network service 207 or MAY be via IPv6 transition mechanisms. 208 2.3.4 Service Providers MAY continue to offer IPv4-based Internet 209 connectivity to their Internet customers. Organizations MAY 210 continue to use IPv4-based Internet connectivity. 212 3. Summary 214 In order to facilitate full Internet-wide connectivity during the 215 transition from IPv4-based connectivity to IPv6-based connectivity, 216 a transition plan which provides clear guidance to organizations 217 regarding expectations is necessary. As the specific expectations 218 change over time, and vary greatly by organization, a phased approach 219 is specified in this document, with the timeline for each phase set 220 with the intention of allowing enough time for the necessary planning 221 and deployment steps which each organization much undertake. This 222 Internet Transition Plan provides for transition to predominantly 223 IPv6-connectivity by January 2012 which, with careful management, may 224 meet the overall requirements of allowing the Internet to scale as 225 specified in "The Recommendation for the IP Next Generation Protocol" 226 [RFC1752]. 228 4. Security Considerations 230 This memo describes the transition of the Internet from IPv4-based 231 connectivity to predominantly IPv6-based connectivity. This change 232 inherently has security implications due to the widespread deployment 233 of a new version of the Internet Protocol but these are beyond the 234 scope of this document and are covered in [RFC4942]. This document 235 raises no new security issues itself. 237 5. IANA Considerations 239 While no new name or identifier space is created by this document, 240 the policies for management of Internet Protocol version 4 (IPv4) 241 address space may not provide for IPv4 availability through the 242 Transition Phase as intended by this plan. The IANA should work with 243 all parties to develop policies per [RFC2050] which allow continued 244 general availability of IPv4 address resources sufficiently long for 245 any transition plan that receives widespread community support. 247 6. Acknowledgments 249 This document would not have been possible without the abundant 250 suggestions made by members of the Internet community at large, 251 but specific thanks go to Fred Baker, Jim Bound, Scott Bradner, 252 Bob Braden, Randy Bush, David Divins, Geoff Huston, Chris Morrow, 253 Jordi Palet Ken Shores, James Woodyatt, and the members of the 254 IETF V6 Operations Working Group for their review and insightful 255 suggestions for improvement. 257 7. References 259 7.1. Normative References 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition 265 Mechanisms for IPv6 Hosts and Routers", RFC 4213, 266 October 2005. 268 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 269 Considerations and Issues with IPv6 DNS", RFC 4472, 270 April 2006. 272 [RFC1752] Bradner, S., Mankin, A.," The Recommendation for the 273 IP Next Generation Protocol", RFC 1752, Feburary 1995. 275 7.2. Informative References 277 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 278 RFC 1958, June 1996. 280 [RFC1669] Curran, J., "Market Viability as a IPng Criteria", 281 RFC 1669, August 1994. 283 [IPUSAGE] IPv4 Address Report,February 2008, by Geoff Huston. 284 286 [RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", 287 RFC 4057, June 2005. 289 [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, 290 "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, 291 April 2004. 293 [CAMPUS] Chown, T., "IPv6 Campus Transition Scenario Description and 294 Analysis", (Work in Progress), March 2007. 296 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 297 J. Postel, "Internet Registry IP Allocation Guidelines", 298 BCP 12, RFC 2050, November 1996. 300 [RFC4942] Davies, E., "IPv6 Transition/Coexistence Security 301 Considerations", September 2007. 303 Appendix A. Change History 305 Changes from -02 version to -03 version: 307 o Revise Introduction to provide additional motivation language. 309 o Revise Introduction and requirements language preface to better 310 clarify use of RFC 2119 style terminology. 312 o Clarify need for IPv6-capable infrastructure rather than simply 313 servers in final phase. 315 o Correct misc typos and capitlization errors. 317 o Updated Acknowledgements section appropriately. 319 Changes from -01 version to -02 version: 321 o Clarification of pilot nature of IPv6 services prior to 322 start of Transition Phase. 324 o Strengthen use of native IPv6 in Post-Transition Phase. 326 Changes from -00 version to -01 version: 328 o Expanded discussion of phased transition model. 330 o Extended Preparation phase by one year to reflect overwhelming 331 community concern about the state of IPv6 readiness. 333 o Clarified use of IPv6 services in Preparation phase to advise 334 caution with respect to DNS interactions per RFC 4472. 336 o Removed last sentence of Post-Transition phase regarding removal 337 of IPv4-based connectivity. Removal of IPv4 is considered out of 338 the scope of this document. 340 o Updated Introduction to clarify use of RFC 2119 terminology 341 despite inherently non-standards nature of this document. 343 o Corrected misc typographic errors. 345 o Updated acknowledgments section. 347 Author's Address 349 John Curran 350 99 Otis Street 351 Cambridge, MA USA 20190 353 Email: jcurran@istaff.org 355 Full Copyright Statement 357 Copyright (C) The IETF Trust (2008). 359 This document is subject to the rights, licenses and restrictions 360 contained in BCP 78, and except as set forth therein, the authors 361 retain all their rights. 363 This document and the information contained herein are provided on an 364 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 365 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 366 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 367 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 368 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 369 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 371 Intellectual Property 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org. 395 Acknowledgment 397 Funding for the RFC Editor function is provided by the IETF 398 Administrative Support Activity (IASA).