idnits 2.17.1 draft-lind-v6ops-isp-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 2003) is 7614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Lind (ed.) 3 TeliaSonera 4 Expires: December 2003 June 2003 6 Scenarios for Introducing IPv6 into ISP Networks 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes different scenarios for the introduction of 31 IPv6 in an IPv4 ISP network. The goal is the addition of a native 32 IPv6 service to the already existing IPv4 service without 33 interruption of the IPv4 service. During the IPv6 introduction the 34 network can go through 4 different stages including the initial IPv4 35 only stage. To move between the stages there will be some form of 36 transition that can be defined in different transition scenarios. 38 Table of Contents 40 1. Introduction...................................................2 41 2. Scope..........................................................3 42 3. Brief description of a generic ISP network.....................3 43 4. Stages.........................................................4 44 4.1 Assumptions................................................4 45 4.2 Customer requirements and ISP offerings....................5 46 4.3 Stage 1 � Launch...........................................5 47 4.4 Stage 2a - Core............................................6 48 4.5 Stage 2b - Access..........................................6 49 4.6 Stage 3 � Complete.........................................6 50 4.7 Future stages..............................................7 51 5. Transition Scenarios...........................................7 52 6. Security Considerations........................................8 54 1. Introduction 56 An ISP offering an IPv4 service will find that there are different 57 ways to add IPv6 to this service. During the introduction of IPv6 the 58 network will go through different stages of IPv6 maturity. In 59 addition to this there has to be a transition between these stages to 60 make them feasible to implement. In some cases it might not be 61 possible to introduce IPv6 as a native part of the network, due to 62 hardware limitations or similar. Instead some coexistence mechanism 63 has to be used. 64 This leaves two choices; a native IPv6 transport in a part of the 65 network or some mechanism to transport IPv6 over the existing IPv4 66 network. From the customer perspective this can be seen as the ISP 67 offering a native IPv6 service or not depending on what is relevant 68 in the access network. If the ISP is not offering native IPv6 69 transport, then the service is limited in the sense that the customer 70 has to have a dual stack network, or some kind of coexistence 71 mechanism. 72 In this document different transition scenarios and situations during 73 the introduction of IPv6 are covered in a broader perspective and 74 deals only with a generic view of how an ISP network is build. This 75 should be seen as the starting point for further documentation of how 76 the introduction of IPv6 can be done in an ISP network in companion. 77 What also will be included in these documents are issues specific to 78 different network configurations and special network equipment. This 79 document should therefore be seen as the working frame for the 80 transition steps of the IPv6 introduction that will be documented in 81 companion documents. 83 2. Scope 85 The scope of the document is to describe different cases for the 86 introduction of an IPv6 service in a generic IPv4 ISP network. This 87 means that the document will be limited to services that include both 88 IPv6 and IPv4 and will not cover issues surrounding an IPv6 only 89 service. The scope also includes transition scenarios between the 90 different stages. The different building blocks that will be 91 considered are a customer network, an access network, a core network 92 and exchange points. It is outside the scope of this document to 93 describe different types of access or network technologies. It is 94 also outside of the scope to propose different solutions. Solutions 95 will be covered in a separate document. 97 3. Brief description of a generic ISP network 99 A generic ISP network topology can be divided into two main parts; 100 core network and access network. The core network or the backbone is 101 the part of the network that interconnects the different access 102 networks and provides transport to the rest of the Internet via 103 exchange points or other means. The core network can be built on 104 different technologies but in this document the only interest is 105 whether it is capable of carrying IPv6 traffic natively or not. The 106 same applies to the access network. The access network provides 107 connectivity to enterprise and private customers. Other ISPs might as 108 well be customers and connected to the ISP's network. 109 __________ _________ 110 | | | | 111 |Backoffice|----| CORE | 112 |__________| |_________|\ 113 . / | \ \ 114 . / | \ \_Peering( Direct & IX ) 115 . / | \ 116 . / | \ 117 ___.___ / ___|___ \ _______ 118 | |____/ | | \____| | 119 |Access1| |Access2| |Access3| 120 |_______| |_______| |_______| 121 | | | 122 | | | ISP Network 123 ----|---------------|---------------|----------------- 124 | | | Customer Networks 125 ___|____ ___|____ ___|____ 126 | | | | | | 127 |Customer| |Customer| |Customer| 128 |________| |________| |________| 129 Figure 1: ISP network topology 131 It doesn't matter if these customer networks have a single node or a 132 large routed network. What is of interest is if routing information 133 is exchanged or not since it will affect the ISP's network. The 134 existence of customer placed equipment will also affect how a service 135 can be delivered. In addition to the ISP's actual network components 136 there are a lot of support and backend systems that have to be 137 considered. 139 4. Stages 141 The stages here are snapshots of an ISP's network with respect to 142 IPv6 maturity. Since an ISP's network is constantly evolving, a stage 143 is a measure of how far an ISP has come in turn of implementing 144 necessary functionality to offer IPv6 to the customers. 146 It is possible to freely transition between different stages. 147 However, a network segment can only be in one stage at a time but an 148 ISP network as a whole can be in different stages. There are 149 different transition paths between the first and final stage. The 150 transition between two stages does not have to be immediate but can 151 occur gradually. 153 Each stage has different IPv6 properties. An ISP can therefore, based 154 on the requirements it has, decide into which stage it will transform 155 its network. 157 4.1 Assumptions 159 The stages are derived from the generic description of an ISP network 160 in section 3. A combination of different building blocks that 161 constitute an ISP environment will lead to a number of scenarios, 162 which an ISP can choose from. The scenarios of most relevance to this 163 document are considered to be the ones that in the most efficient and 164 feasible way maximizes the ability for an ISP to offer IPv6 to its 165 customers. 167 The most predominant case today is considered to be an operator with 168 a core and access IPv4 network delivering IPv4 service to a customer 169 that is running IPv4 as well. At some point in the future, it is 170 expected that the customer will want to have an IPv6 service, in 171 addition to the already existing IPv4 service. The challenge for the 172 ISP is to deliver the requested IPv6 service over the existing 173 infrastructure and at the same time keep the IPv4 service intact. The 174 next step, which is not covered in this document, will be to remove 175 the IPv4 service when there no longer is a demand for it or deliver 176 the IPv4 service over an IPv6 only network. 178 4.2 Customer requirements and ISP offerings 180 Looking at the scenarios from the end customer's perspective there 181 might be a demand for three different services; the customer might 182 demand IPv4 service, IPv6 service or both services. This can lead to 183 two scenarios depending on the stage the ISP's network is in. 185 If an ISP only offer IPv4 or IPv6 service and a customer wants to 186 connect a device or network that only supports one service and if 187 that service is not offered, it will lead to a dead-end. If the 188 customer or ISP instead connects a dual stack device it is possible 189 to circumvent the lack of the missing service in the access network 190 by using some kind of coexistence mechanism. This scenario will only 191 be considered in the perspective of the ISP offering a mechanism to 192 bridge the access and reach the IPv6 core. 194 In the case where the customer connects a single stack device to a 195 corresponding single stack access network, there will be no problem 196 from the customer's perspective. The same is valid if a single stack 197 device is connected to a dual stack access network. Therefore, 198 neither of these cases need further be explored in this document but 199 can be seen as a part of a full dual stack case. 201 After eliminating a number of cases explained above, there are four 202 stages that are most probable and where an ISP will find its network 203 in. Which stage a network is in; depend on whether or not some part 204 of the network previously has been upgraded to support IPv6 or if it 205 is easier to enable IPv6 in one part or another. For instance, 206 routers in the core might have IPv6 support or might be easily 207 upgradeable, while the hardware in the access might have to be 208 completely replaced in order to handle IPv6 traffic. 210 Note that in every stage except Stage 1, the ISP can offer both IPv4 211 and IPv6 services to the customer. 213 The four most probable stages are: 214 Stage 1 � Launch 215 Stage 2a � Core 216 Stage 2b � Access 217 Stage 3 � Complete 219 4.3 Stage 1 � Launch 221 The first stage is an IPv4 only ISP with an IPv4 customer. This is 222 the most common case today and has to be the starting point for the 223 introduction of IPv6. From this stage, an ISP can move (transition) 224 to any other stage with the goal to offer IPv6 to its customer. 226 Customer Access Core Exchange 227 ------ ------ ------ ------ 228 | | | | | | | | 229 | IPv4 |---| IPv4 |---| IPv4 |---| IPv4 | 230 | | | | | | | | 231 ------ ------ ------ ------ 232 Figure 2. IPv4 network 234 4.4 Stage 2a - Core 236 Stage 2a is an ISP with an access network that is IPv4 only and a 237 core that is IPv4 and IPv6. In this stage the customer should have 238 support for both IPv4 and IPv6 and use a coexistence mechanism to be 239 able to run the IPv6 service. To offer the IPv6 service, the ISP also 240 has to connect to an IPv6 exchange point or somehow else exchange 241 IPv6 traffic with other ISPs. 243 Customer Access Core Exchange 244 ------ ------ ------ ------ 245 | | | | | | | IPv4 | 246 | Dual |---| IPv4 |---| Dual |---| + | 247 | | | | | | | IPv6 | 248 ------ ------ ------ ------ 249 Figure 3. Upgraded core 251 4.5 Stage 2b - Access 253 Stage 2b is an ISP with a core network that is IPv4 and an access 254 that is IPv4 and IPv6. Since the service to the customer is native 255 IPv6 there is no requirement for the customer to support both IPv4 256 and IPv6. This is the biggest difference in comparison to the 257 previous stage. The need to exchange IPv6 traffic or similar still 258 exists but might be more complicated than in the previous case since 259 the core isn't IPv6 enabled. 261 Customer Access Core Exchange 262 ------ ------ ------ ------ 263 | | | | | | | IPv4 | 264 | Dual |---| Dual |---| IPv4 |---| + | 265 | | | | | | | IPv6 | 266 ------ ------ ------ ------ 267 Figure 4. Upgraded access 269 4.6 Stage 3 � Complete 271 Stage 3 can be said to be the final step in introducing IPv6, at 272 least in the scope of this document. This is an all over IPv6 service 273 with native support for IPv6 and IPv4 in both core and access 274 networks. This stage is identical to the previous stage in the 275 customer's perspective since the access network hasn't changed. The 276 connection to the IPv6 exchange point is identical to stage 2. 278 Customer Access Core Exchange 279 ------ ------ ------ ------ 280 | | | | | | | IPv4 | 281 | Dual |---| Dual |---| Dual |---| + | 282 | | | | | | | IPv6 | 283 ------ ------ ------ ------ 284 Figure 5. Completely upgraded network 286 4.7 Future stages 288 After a while the ISP might want to transition to a service that is 289 IPv6 only, at least in certain parts of the network. This transition 290 creates a lot of new cases in which to factor in how to maintain the 291 IPv4 service. Providing an IPv6 only service is not much different 292 than the dual IPv4/IPv6 service described in stage 3 except from the 293 need to phase out the IPv4 service. The delivery of IPv4 services 294 over an IPv6 network and the phase out will be left for a future 295 document. 297 5. Transition Scenarios 299 Given the different stages it is clear that the ISP has to be able to 300 transition from one stage to another. The initial stage, in this 301 document, is the IPv4 only service and network. The end stage is the 302 dual IPv4/IPv6 service and network. As mentioned in the scope, this 303 document does not cover the IPv6 only service and network and its 304 implications on IPv4 customers. This has nothing to do with the 305 usability of an IPv6 only service. 307 The transition starts out with the IPv4 ISP and then moves to one of 308 three choices. These choices are the different transition scenarios. 309 One way would be to upgrade the core first which leads to stage 2a. 310 Another way to go could be to upgrade the access network which leads 311 to stage 2b. The final possibility is to introduce IPv6 in the whole 312 network at once which would lead to stage 3. 314 The choice is dependent on many different issues. For example it 315 might not be possible to upgrade the core or the access network 316 without large investments in new equipment which could lead to any of 317 the two first choices. In another case it might be easier to take the 318 direct step to a complete IPv6/IPv4 network due to routing protocol 319 issues or similar. 321 If a partially upgraded network (stage 2a or 2b) was chosen as the 322 first step, a second step remains before the network is all over 323 native IPv6/IPv4. This is the transition to an all over dual stack 324 network. This step is perhaps not necessary for stage 2b with an 325 already native IPv6 service to the customer but might still occur 326 when the timing is right. For stage 2a it is more obvious that a 327 transition to a dual stack network is necessary since it has to be 328 done to offer a native IPv6 service. 330 6. Security Considerations 332 This document describes different cases for the introduction of IPv6 333 in an IPv4 ISP network. Solutions are described in other documents 334 hence this document has no security considerations. 336 Intellectual Property Statement 338 The IETF takes no position regarding the validity or scope of any 339 intellectual property or other rights that might be claimed to 340 pertain to the implementation or use of the technology described in 341 this document or the extent to which any license under such rights 342 might or might not be available; neither does it represent that it 343 has made any effort to identify any such rights. Information on the 344 IETF's procedures with respect to rights in standards-track and 345 standards-related documentation can be found in BCP-11. Copies of 346 claims of rights made available for publication and any assurances of 347 licenses to be made available, or the result of an attempt made to 348 obtain a general license or permission for the use of such 349 proprietary rights by implementors or users of this specification can 350 be obtained from the IETF Secretariat. 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights which may cover technology that may be required to practice 355 this standard. Please address the information to the IETF Executive 356 Director. 358 Full Copyright Statement 360 Copyright (C) The Internet Society (2003). All Rights Reserved. 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it 364 or assist in its implementation may be prepared, copied, published 365 and distributed, in whole or in part, without restriction of any 366 kind, provided that the above copyright notice and this paragraph are 367 included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing 369 the copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of 371 developing Internet standards in which case the procedures for 372 copyrights defined in the Internet Standards process must be 373 followed, or as required to translate it into languages other than 374 English. 376 The limited permissions granted above are perpetual and will not be 377 revoked by the Internet Society or its successors or assignees. 379 This document and the information contained herein is provided on an 380 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 381 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 382 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 383 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 384 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Acknowledgements 388 This draft has benefited from input by Jordi Palet, Suresh Satapati, 389 Myung-Ki Shin, Vladmir Ksinant, Alain Baudot, Soohong Daniel Park, 390 Cleve Mickles, Pekka Savola and Margaret Wasserman. 392 Authors' Addresses 394 Mikael Lind 395 TeliaSonera 396 Vitsandsgatan 9B 397 SE-12386 Farsta 398 Email: mikael.lind@teliasonera.com 400 Jasminko Mulahusic 401 TeliaSonera 402 Vitsandsgatan 9B 403 SE-12386 Farsta 404 Email: jasminko.mulahusic@teliasonera.com