idnits 2.17.00 (12 Aug 2021) /tmp/idnits55472/draft-ietf-v6ops-v4v6tran-framework-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 : ---------------------------------------------------------------------------- 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 (July 26, 2011) is 3945 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-6man-node-req-bis has been published as RFC 6434 -- 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: 0 errors (**), 0 flaws (~~), 2 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: January 27, 2012 Huawei Technologies Co., Ltd 6 V. Kuarsingh 7 Rogers Communications 8 July 26, 2011 10 Framework for IP Version Transition Scenarios 11 draft-ietf-v6ops-v4v6tran-framework-02 13 Abstract 15 This document sets out a framework agreed by the V6OPS WG for the 16 presentation of scenarios and recommendations for a variety of 17 approaches to the transition from IPv4 to IPv6, given the necessity 18 for a long period of co-existence of the two protocols. 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 January 27, 2012. 37 Copyright Notice 39 Copyright (c) 2011 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. Document Topics . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 This document sets out a framework for the presentation of scenarios 66 and recommendations for a variety of approaches to the transition 67 from IPv4 to IPv6, given the necessity for a long period of co- 68 existence of the two protocols. A general "call to arms" for 69 transition is found in [RFC5211], and a recommendation for four 70 principal scenarios is given in [RFC6180]. A report on experience 71 and plans of various Internet Service Providers (ISPs) is given in 72 [RFC6036]. However, it is clear that operators require more detailed 73 technical recommendations than are available so far. Unfortunately, 74 the number of different combinations of existing IPv4 deployment 75 models, customer profiles and requirements, and possible coexistence 76 and transition models, is enormous, so it is quite impracticable to 77 produce either a set of recommendations for each case, or a 78 recommended "one size fits all" model. That is why this document 79 proposes a set of topics or dimensions, as a framework for a 80 reasonable number of recommendation documents. 82 The reader is assumed to be familiar with IPv6. The IETF's view of 83 core IPv6 requirements is to be found in [RFC4294] (currently being 84 updated as [I-D.ietf-6man-node-req-bis]). However, this does not 85 give a complete view of mechanisms an ISP may need to deploy, since 86 it considers the requirements for an individual node, not for a 87 network or service infrastructure as a whole. 89 [RFC4029] discussed scenarios for introducing IPv6 into ISP networks, 90 as the problem was viewed some years ago. Its end goal was simply a 91 dual-stack ISP backbone. Today's view is that this is insufficient, 92 as it does not allow for prolonged interworking between IPv6-only and 93 legacy (IPv4-only) hosts. Indeed, the end goal today might be an 94 IPv6-only ISP backbone, with some form of legacy IPv4 support 95 [RFC6180]. 97 Although the basic IPv6 standards are stable, considerable work 98 continues in several IETF working groups, on issues such as 99 multihoming, tunneling, and IP layer interworking between IPv6-only 100 and IPv4-only hosts. However, operators faced with IPv4 address 101 exhaustion in the coming few years need immediate guidance. These 102 operators cannot avoid the need for general skills acquisition, or 103 the need to write their own detailed deployment plan, but they also 104 need guidance for generic scenarios similar to their actual 105 situation. They cannot obtain such guidance from individual protocol 106 specifications developed by the IETF, so there is a need for 107 additional documents. 109 This draft is maintained as a "living document" of the V6OPS WG, 110 because it is not considered necessary to archive it as an RFC. 112 2. Document Topics 114 On the assumption that a series of documents are produced describing 115 and recommending transition scenarios, there are two basic 116 conditions: 117 1. The documents will not be primary protocol specifications, 118 because those are the outcome of IETF working groups chartered to 119 work on specific protocol mechanisms. 120 2. The documents are addressed to service providers who have taken 121 the decision to support IPv6, have acquired basic knowledge and 122 skills, have determined how they will obtain upstream IPv6 123 connectivity, and are ready to write their operational plan for 124 transition. 126 The documents should describe scenarios for real transition to IPv6, 127 not life extensions to IPv4 or other matters best handled in other 128 working groups. They should each cover some or all of the following 129 aspects or dimensions: 130 o For the convenience of readers, each document should briefly 131 describe its network model in the Abstract (or Introduction) for 132 quick reference. 133 o The documents should explain how certain technology components fit 134 together in a given transition and co-existence scenario. 135 o They will present major generic network models, and their subsets, 136 which exist (or are firmly planned) today, including network 137 topologies and/or architectures. 138 o They should specify their scope: the range of technologies that 139 they do or do not apply to (e.g. specific access network 140 technologies, core network technologies and topologies, mobile vs 141 fixed hosts, business vs private customers, etc.). 142 o They should develop analysis criteria on how to recognize 143 appropriate transition technologies for existing provider networks 144 within their scope. This should include information related to 145 deployed protocols and functions which may assist or hinder 146 various transition technologies from being deployed. 147 o If multiple transition technologies are needed for provider 148 environments where access networks differ and have various 149 capabilities, the documents should show how these technologies can 150 be deployed simultaneously. 151 o They should describe how multiple technologies can co-exist, if 152 necessary, during all stages of migration (e.g., moving from IPv4 153 Only to Dual-Stack to DS-Lite to NAT64). 154 o They should cover considerations for legacy operation while moving 155 to IPv6 and its transition technologies. Many operators will have 156 large quantities of IPv4-only equipment which cannot feasibly be 157 upgraded until the end of its economic life, or which is under 158 customer control. 160 o They should cover considerations which apply when retro-fitting 161 various technologies to existing networks. Included in this would 162 be impacts on ancillary protocols, routing platforms/systems, 163 security policies, provisioning systems, network services (i.e. 164 DHCP, DNS etc), law enforcement procedures and more. 165 o They should quantify scaling characteristics of deployment modes 166 for each technology model and intersections during co-existence 167 (e.g. if some of the Network is DS-Lite and some is classical Dual 168 Stack; peak load on NAT64; etc.). 169 o The documents should include security considerations for their 170 specific transition scenario(s). 172 A desirable outcome would be a set of Best Current Practice (BCP) or 173 advisory (Informational) documents for a range of generic deployment 174 models and how they fit into a network, including key services such 175 as subscriber authentication, DHCP, and DNS. However, it must not be 176 forgotten that every service provider is different and such documents 177 can never replace specific deployment plans drawn up by each 178 individual service provider. 180 3. Security Considerations 182 Service providers will insist on having security for IPv6 services, 183 and for all transition technologies, that is at least as good as for 184 IPv4 services in all respects. Particular attention must be paid to 185 security exposures that are specific to transition and coexistence 186 mechanisms. Thus, all recommendations for transition scenarios must 187 include any security aspects that are specific to that scenario. 189 4. IANA Considerations 191 This document makes no request of the IANA. 193 5. Acknowledgements 195 Useful comments and contributions were made by Randy Bush and other 196 members of the V6OPS WG. 198 This document was produced using the xml2rfc tool [RFC2629]. 200 6. Change log 202 draft-ietf-v6ops-v4v6tran-framework-02: updated as living document 203 for WG, 2011-07-26 204 draft-ietf-v6ops-v4v6tran-framework-01: small addition following 205 WGLC, 2011-02-02 207 draft-ietf-v6ops-v4v6tran-framework-00: adopted by WG at IETF 79, 208 2010-12-01 210 draft-carpenter-v4v6tran-framework-00: original version, 2010-08-18 212 7. Informative References 214 [I-D.ietf-6man-node-req-bis] 215 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 216 Requirements", draft-ietf-6man-node-req-bis-11 (work in 217 progress), May 2011. 219 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 220 June 1999. 222 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 223 Savola, "Scenarios and Analysis for Introducing IPv6 into 224 ISP Networks", RFC 4029, March 2005. 226 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 227 April 2006. 229 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 230 July 2008. 232 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 233 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 235 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 236 Transition Mechanisms during IPv6 Deployment", RFC 6180, 237 May 2011. 239 Authors' Addresses 241 Brian Carpenter 242 Department of Computer Science 243 University of Auckland 244 PB 92019 245 Auckland, 1142 246 New Zealand 248 Email: brian.e.carpenter@gmail.com 249 Sheng Jiang 250 Huawei Technologies Co., Ltd 251 Huawei Building, No.3 Xinxi Rd., 252 Shang-Di Information Industry Base, Hai-Dian District, Beijing 253 P.R. China 255 Email: jiangsheng@huawei.com 257 Victor Kuarsingh 258 Rogers Communications 259 Canada 261 Email: Victor.Kuarsingh@rci.rogers.com