idnits 2.17.1 draft-ietf-v6ops-isp-scenarios-analysis-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages 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.) ** There are 68 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 472 has weird spacing: '...dicated route...' == Line 581 has weird spacing: '...ackbone infra...' -- 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 (December 2003) is 7432 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) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-06 -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-00 == Outdated reference: A later version (-04) exists of draft-shirasaki-dualstack-service-02 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft M. Lind 2 TeliaSonera 3 Expires : May 2004 V. Ksinant 4 6WIND 5 D. Park 6 Samsung Electronics 7 A. Baudot 8 France Telecom 9 December 2003 11 Scenarios and Analysis for Introducing IPv6 into ISP Networks 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document first describes different scenarios for the 38 introduction of IPv6 into an existing IPv4 ISP network without 39 disrupting the IPv4 service. Then, this document analyses these 40 scenarios and evaluates the suitability of the already defined 41 transition mechanisms in this context. Known challenges are also 42 identified. 44 Table of Contents 46 1. Introduction..................................................3 47 1.1 Goal and scope of the document..........................3 48 1.2 Terminology used........................................3 49 2. Brief description of a generic ISP network....................4 50 3. Transition scenarios..........................................6 51 3.1 Identification of scenarios.............................6 52 3.1.1 Assumptions............................................6 53 3.1.2 Customer requirements and ISP offerings................7 54 3.1.3 Stage 1 Scenarios: Launch..............................8 55 3.1.4 Stage 2a Scenarios: Backbone...........................8 56 3.1.5 Stage 2b Scenarios: Customer connection................8 57 3.1.6 Stage 3 scenarios: Complete............................9 58 3.1.7 Stage 2a and 3 combination scenarios...................9 59 3.2 Transition Scenarios....................................9 60 3.3 Actions needed when deploying IPv6 in an ISP network...10 61 4. Backbone transition actions..................................11 62 4.1 Steps in transitioning backbone networks...............11 63 4.2 Configuration of backbone equipment....................13 64 4.3 Routing................................................13 65 4.3.1 IGP...................................................13 66 4.3.2 EGP...................................................14 67 4.3.3 Routing protocols transport...........................15 68 4.4 Multicast..............................................15 69 5. Customer connection transition actions.......................15 70 5.1 Steps in transitioning customer connection networks....15 71 5.2 Access control requirements............................17 72 5.3 Configuration of customer equipment....................17 73 5.4 Requirements for Traceability..........................18 74 5.5 Multi-homing...........................................18 75 5.6 Ingress filtering in the customer connection network...19 76 6. Network and service operation actions........................19 77 7. Future Stages................................................20 78 8. Example networks.............................................20 79 8.1 Example 1..............................................22 80 8.2 Example 2..............................................22 81 8.3 Example 3..............................................23 82 9. Security Considerations......................................23 83 10. Acknowledgements.............................................23 84 11. Informative references.......................................23 85 1. Introduction 87 1.1 Goal and scope of the document 89 When an ISP deploys IPv6, its goal is to provide IPv6 connectivity 90 to its customers. The new IPv6 service must be added to an already 91 existing IPv4 service and the introduction of the IPv6 must not 92 interrupt this IPv4 service. The case of an IPv6-only service 93 provider is not addressed in this document. 95 An ISP offering an IPv4 service will find that there are different 96 ways to add IPv6 to this service. This document discusses a small 97 set of scenarios for the introduction of IPv6 in an ISP IPv4 98 network. It evaluates the suitability of the existing transition 99 mechanisms in the context of these deployment scenarios, and it 100 points out the lack of functionality essential to the ISP operation 101 of an IPv6 service.. 103 The present document is focused on services that include both IPv6 104 and IPv4 and does not cover issues surrounding an IPv6-only service. 105 It is also outside the scope of this document to describe different 106 types of access or network technologies. 108 1.2 Terminology used 110 This section defines and clarifies the terminology used in this 111 document: 113 "CPE" : Customer Premise Equipment 115 "PE" : Provider Edge equipment 117 "Network and service operation": 118 : This is the part of the ISP network which hosts the 119 services required for the correct operation of the 120 ISP network. These services usually include 121 management, supervision, accounting, billing and 122 customer management applications. 124 "Customer connection": 125 : This is the part of the network which is used by a 126 customer when connecting to an ISP network. It 127 includes the CPEs, the last hop links and the parts 128 of the PE interfacing to the last hop links. 130 "Backbone" : 131 This is the rest of the ISP network infrastructure. 132 It includes the parts of the PE interfacing to the 133 core, the core routers of the ISP and the 134 border routers used in order to exchange routing 135 information with other ISPs (or other administrative 136 entities). 138 "Dual-stack network": 139 A network which supports natively both IPv4 and 140 IPv6. 142 2. Brief description of a generic ISP network 144 A generic ISP network topology can be divided into two main parts; 145 the backbone network and the customer connection networks connecting 146 the customers. 148 The backbone is the part of the network that interconnects the 149 different customer connection networks and provides transport to the 150 rest of the Internet via exchange points or other means. The 151 backbone network can be built on different technologies but in this 152 document the only interest is whether it is capable of carrying IPv6 153 traffic natively or not. Since there is no clear definition of 154 "backbone", it is defined in this document as being all routers that 155 are a part of the same routed domain in the transport network. This 156 means that all routers up to (and including, at least partially) the 157 PE router are a part of the backbone. 159 The customer connection networks provide connectivity to enterprise 160 and private customers. Other ISPs might as well be customers and 161 connected to the ISP's customer connection network. As with the 162 backbone the absence or presence of native IPv6 capability is the 163 only thing of real interest in the customer connection network 164 technology. 166 It is noticeable that, in some cases (e.g. incumbent national or 167 regional operators), a given customer connection network may have 168 to be shared between different ISPs. According to the type of the 169 customer connection network used (e.g. involving only layer 2 170 devices, or involving non-IP technology), this constraint may result 171 in architectural considerations that may be relevant in this 172 document. 174 "Network and service operation" building blocks refer to the basic 175 main functions needed for a regular backbone operation. This 176 building block is dealing with: network management, customers' 177 authentication and accounting, address assignment and naming. It 178 represents the minimum functions needed to provide a customer 179 service, referring to both network infrastructure operation, and 180 administrative management of customers. 182 It doesn't matter if these customer networks have a single node or a 183 large routed network. What is of interest is if routing information 184 is exchanged or not since it will affect the ISP's network. The 185 existence of customer premise equipment will also affect how a 186 service can be delivered. In addition to the ISP's actual network 187 components there are a lot of support and backend systems that have 188 to be considered. 190 The basic components in an ISP network are depicted in Figure 1. 192 ------------ ---------- 193 | Network and| | | 194 | service |--| Backbone | 195 | operation | | |\ 196 ------------ ---------- \ 197 . / | \ \ 198 . / | \ \_Peering( Direct & IX ) 199 . / | \ 200 . / | \ 201 . / | \ 202 ---------- / ---------- \ ----------- 203 | Customer | / | Customer | \ | Customer | 204 |Connection|--/ |Connection| \--|Connection| 205 | 1 | | 2 | | 3 | 206 ---------- ---------- ---------- 207 | | | ISP Network 208 ------------------------------------------------------- 209 | | | Customer Networks 210 +--------+ +--------+ +--------+ 211 | | | | | | 212 |Customer| |Customer| |Customer| 213 | | | | | | 214 +--------+ +--------+ +--------+ 215 Figure 1: ISP network topology 217 3. Transition scenarios 218 3.1 Identification of scenarios 220 This section describes different stages an ISP might consider when 221 introducing IPv6 connectivity in the existing IPv4 network and the 222 different scenarios that might occur in the respective stages. 224 The stages here are snapshots of an ISP's network with respect to 225 IPv6 maturity. Since an ISP's network is constantly evolving, a 226 stage is a measure of how far an ISP has come in turn of 227 implementing necessary functionality to offer IPv6 to the customers. 229 It is possible to freely transition between different stages. 230 However, a network segment can only be in one stage at a time but an 231 ISP network as a whole can be in different stages. There are 232 different transition paths between the first and final stage. The 233 transition between two stages does not have to be immediate but can 234 occur gradually. 236 Each stage has different IPv6 properties. An ISP can therefore, 237 based on the requirements it has, decide into which stage it will 238 transform its network. 240 This document is not aimed to cover very small or small ISPs or 241 hosting providers/data centers; only the scenarios applicable to the 242 ISPs eligible for a /32 IPv6 prefix allocation from a RIR are 243 covered. 245 3.1.1 Assumptions 247 The stages are derived from the generic description of an ISP 248 network in section 2. A combination of different building blocks 249 that constitute an ISP environment will lead to a number of 250 scenarios, which an ISP can choose from. The scenarios of most 251 relevance to this document are considered to be the ones that in the 252 most efficient and feasible way maximize the ability for an ISP to 253 offer IPv6 to its customers. 255 The most predominant case today is considered to be an operator with 256 a core and access IPv4 network delivering IPv4 service to a customer 257 that is running IPv4 as well. At some point in the future, it is 258 expected that the customer will want to have an IPv6 service, in 259 addition to the already existing IPv4 service. This IPv6 service may 260 be offered by the same ISP, or by a different one. Anyway the 261 challenge for the ISP is to deliver the requested IPv6 service over 262 the existing infrastructure and at the same time keep the IPv4 263 service intact. 265 3.1.2 Customer requirements and ISP offerings 267 Looking at the scenarios from the end customer's perspective there 268 might be a demand for three different services; the customer might 269 demand IPv4 service, IPv6 service or both services. This can lead to 270 two scenarios depending on the stage the ISP's network is in. 272 If an ISP only offers IPv4 or IPv6 service and a customer wants to 273 connect a device or network that only supports one service and if 274 that service is not offered, it will lead to a dead-end. If the 275 customer or ISP instead connects a dual stack device it is possible 276 to circumvent the lack of the missing service in the customer 277 connection network by using some kind of tunneling mechanism. This 278 scenario will only be considered in the perspective of the ISP 279 offering a mechanism to bridge the customer connection and reach the 280 IPv6 backbone. 282 In the case where the customer connects a single stack device to a 283 corresponding single stack customer connection network or when the 284 customer connects a single stack device to a dual stack customer 285 connection network is covered by the all over dual stack case. 286 Therefore, neither of these cases need further be explored 287 separately in this document but can be seen as a part of a full dual 288 stack case. 290 After eliminating a number of cases explained above, there are four 291 stages that are most probable and where an ISP will find its network 292 in. Which stage a network is in depends on whether or not some part 293 of the network previously has been upgraded to support IPv6 or if it 294 is easier to enable IPv6 in one part or another. For instance, 295 routers in the backbone might have IPv6 support or might be easily 296 upgradeable, while the hardware in the customer connection network 297 might have to be completely replaced in order to handle IPv6 298 traffic. 300 Note that in every stage except Stage 1, the ISP can offer both IPv4 301 and IPv6 services to the customer. 303 The four most probable stages are: 305 o Stage 1 Launch 306 o Stage 2a Backbone 307 o Stage 2b Customer connection 308 o Stage 3 Complete 310 Generally the ISP is able to upgrade current IPv4 network to 311 IPv4/IPv6 dual-stack network via Stage 2b but the IPv6 service can 312 also be implemented at a small cost with simple tunnel mechanisms on 313 the existing system. When designing a new network, Stage 3 might be 314 the first and last step since there are no legacy concerns. Absence 315 of IPv6 capability in the network equipment can still be a limiting 316 factor nevertheless. 318 3.1.3 Stage 1 Scenarios: Launch 320 The first stage is an IPv4 only ISP with an IPv4 customer. This is 321 the most common case today and has to be the starting point for the 322 introduction of IPv6. From this stage, an ISP can move (transition) 323 to any other stage with the goal to offer IPv6 to its customer. 325 The immediate first step consists of getting a prefix allocation 326 (typically a /32) from the appropriate RIR according to allocation 327 procedures. 329 3.1.4 Stage 2a Scenarios: Backbone 331 Stage 2a is an ISP with customer connection networks that are IPv4 332 only and a backbone that supports both IPv4 and IPv6. In particular, 333 the ISP considers it possible to make the backbone IPv6 capable 334 either through software or hardware upgrade, or a combination of 335 both. In this stage the customer should have support for both IPv4 336 and IPv6. The ISP has to provide IPv6 connectivity through its IPv4 337 customer connection networks. 339 In particular, the existence of NATs and firewalls in the path (at 340 the CPE, or in the customer's network) need to be considered. 342 3.1.5 Stage 2b Scenarios: Customer connection 344 Stage 2b is an ISP with a backbone network that is IPv4 and an 345 customer connection network that supports both IPv4 and IPv6. Since 346 the service to the customer is native IPv6 there is no requirement 347 for the customer to support both IPv4 and IPv6. This is the biggest 348 difference in comparison to the previous stage. The need to 349 exchange IPv6 traffic or similar still exists but might be more 350 complicated than in the previous case since the backbone isn't IPv6 351 enabled. After completing stage 2b the original IPv4 backbone still 352 is unchanged. This doesn't imply that there is no IPv6 backbone just 353 that the IPv6 backbone is an overlay to or partially separated from 354 the IPv4 backbone. 356 Generally, the ISP will continue providing IPv4 connectivity; in 357 many cases private addresses and NATs will continue to be used. 359 3.1.6 Stage 3 scenarios: Complete 361 Stage 3 can be said to be the final step in introducing IPv6, at 362 least in the scope of this document. This is an all over IPv6 363 service with native support for IPv6 and IPv4 in both backbone and 364 customer connection networks. This stage is identical to the 365 previous stage in the customer's perspective since the customer 366 connection network hasn't changed. The requirement for exchanging 367 IPv6 traffic is identical to stage 2. 369 3.1.7 Stage 2a and 3 combination scenarios 371 Some ISPs may use different access technologies of varying IPv6 372 maturity. This may result in a combination of the stages 2a and 3: 373 some customer connections do not support IPv6, but some do; and the 374 backbone is dual-stack. 376 This is equivalent to stage 2a, but requiring support for native 377 IPv6 customer connections on some access technologies. 379 3.2 Transition Scenarios 381 Given the different stages it is clear that the ISP has to be able 382 to transition from one stage to another. The initial stage, in this 383 document, is the IPv4 only service and network. The end stage is the 384 dual IPv4/IPv6 service and network. As mentioned in the scope, this 385 document does not cover the IPv6 only service and network and its 386 implications on IPv4 customers. This has nothing to do with the 387 usability of an IPv6 only service. 389 The transition starts out with the IPv4 ISP and then moves to one of 390 three choices. These choices are the different transition 391 scenarios. One way would be to upgrade the backbone first which 392 leads to stage 2a. Another way to go could be to upgrade the 393 customer connection network which leads to stage 2b. The final 394 possibility is to introduce IPv6 in both the backbone and customer 395 connections as needed which would lead to stage 3. 397 The choice is dependent on many different issues. For example it 398 might not be possible to upgrade the backbone or the customer 399 connection network without large investments in new equipment which 400 could lead to any of the two first choices. In another case it might 401 be easier to take the direct step to a complete IPv6/IPv4 network 402 due to routing protocol issues or similar. 404 If a partially upgraded network (stage 2a or 2b) was chosen as the 405 first step, a second step remains before the network is all over 406 native IPv6/IPv4. This is the transition to an all over dual stack 407 network. This step is perhaps not necessary for stage 2b with an 408 already native IPv6 service to the customer but might still occur 409 when the timing is right. For stage 2a it is more obvious that a 410 transition to a dual stack network is necessary since it has to be 411 done to offer a native IPv6 service. 413 As most of the ISPs keep evolving continuously their backbone IPv4 414 networks (new firmware versions in the routers, new routers), they 415 will be able to get them IPv6 ready, without additional investment, 416 except the staff training. It may be a slower transition path, but 417 useful since it allows an IPv6 introduction without any actual 418 customer demand. This will probably be better than making everything 419 at the last minute with a higher investment. 421 3.3 Actions needed when deploying IPv6 in an ISP network 423 When looking at the transitions described above, it appears that it 424 is possible to split the work required by each transition in a small 425 set of actions. Each action is mostly independent from the others 426 and some actions may be common to several transitions. 428 The analysis of the possible transitions leads to a small list of 429 actions: 431 * backbone transition actions: 433 - Connect dual-stack customer connection networks to other 434 IPv6 networks through an IPv4 backbone, 436 - Transform an IPv4 backbone into a dual-stack one. This 437 action can be performed directly or through intermediate 438 steps, 440 * customer connection transition actions: 442 - Connect IPv6 customers to an IPv6 backbone through an IPv4 443 network, 445 - Transform an IPv4 customer connection network into a dual- 446 stack one, 448 * network and service operation transition actions: 449 - configure IPv6 functions into either backbone or network 450 and service operation devices 451 - upgrade regular network management and monitoring 452 applications to take IPv6 into account 453 - [Network and service operation actions - To be completed.] 455 More detailed descriptions of each action follow. 457 4. Backbone transition actions 459 4.1 Steps in transitioning backbone networks 461 In terms of physical equipment, backbone networks consist mainly in 462 core and edge high-speed routers. Border routers provide peering 463 with other providers. Filtering, routing policy and policing type 464 functions are generally managed on border routers. 466 The initial step is an IPv4-only backbone, and the final step is a 467 whole dual-stack backbone. In between, intermediate steps may be 468 identified: 470 Tunnels Tunnels 471 IPv4-only ----> or ---> or + DS -----> Full DS 472 IPv6 dedicated IPv6 dedicated routers 473 links links 475 The first step involves tunnels or dedicated links but existing 476 routers are left unchanged. Only a small set of routers then have 477 IPv6 capabilities. Configured tunnels are adequate for use during 478 this step. 480 When MPLS is already deployed in the backbone, it may be desirable 481 to provide IPv6-over-MPLS connectivity. However, the problem is that 482 setting up an IPv6 Label Switched Path (LSP) requires some signaling 483 through the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs, 484 but this would require a software upgrade in the MPLS core network. 485 A workaround is to use BGP for signaling and/or to perform IPv6- 486 over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, for 487 example, as described in [BGPTUNNEL]. There seem to be multiple 488 possibilities, some of which may be more preferable than others. 489 More analysis is needed in order to determine which are the best 490 approach(es): 492 1) require that MPLS networks deploy native IPv6 support or 493 use configured tunneling for IPv6. 495 2) require that MPLS networks support setting up IPv6 LSPs, 496 and IPv6 connectivity is set up using them, or configured 497 tunneling is used. 499 3) use only configured tunneling over the IPv4 LSPs; this 500 seems practical with small-scale deployments when the 501 number of tunnels is low. 503 4) use something like [BGPTUNNEL] to perform IPv6-over- 504 IPv4/MPLS encapsulation for IPv6 connectivity. 506 In the second step, some dual stack routers are added in this 507 network in a progressive manner. 509 The final stage is reached when all or most routers are dual-stack. 511 According to many reasons (technical, financial, etc), an ISP may 512 move forward from step to step or reach directly the final one. One 513 of the important criteria in this evolution is the number of IPv6 514 customers the ISP gets on its initial deployments. If few customers 515 connect to the first IPv6 infrastructure, then the ISP is likely to 516 remain on the initial steps for a long time. 518 In short, each step remains possible, but no one is mandatory. 520 4.2 Configuration of backbone equipment 522 In the backbone, the number of devices is small and IPv6 523 configuration mainly deals with routing protocols parameters, 524 interface addresses, loop-back addresses, ACLs... 526 These IPv6 parameters are not supposed to be automatically 527 configured. 529 4.3 Routing 531 ISPs need routing protocols to advertise the reachability and to 532 find the shortest working paths both internally and externally. 534 OSPFv2 and IS-IS are typically used as an IPv4 IGP. 535 RIPv2 is typically not in use in operator networks. 536 BGP is the only IPv4 EGP. Static routes are used in both. 538 Note that it is possible to configure a given network so that it 539 results in having an IPv6 topology different from the IPv4 topology. 540 For example, some links or interfaces may be dedicated to IPv4-only 541 or IPv6-only traffic, or some routers may be dual-stack while some 542 others maybe single stacked (IPv4 or IPv6). In this case, the 543 routing must be able to manage multiple topologies. 545 4.3.1 IGP 547 Once the IPv6 topology has been determined the choice of IPv6 IGP 548 must be made: either OSPFv3 or IS-IS for IPv6. RIPng is less 549 appropriate in many contexts and is not discussed here. The IGP 550 typically includes the routers' point-to-point and loop-back 551 addresses. 553 The most important decision to make is whether one wishes to have 554 separate routing protocol processes for IPv4 and IPv6. Having them 555 separate requires more memory and CPU for route calculations e.g. 556 when the links flap. On the other hand, the separation provides a 557 better reassurance that if problems come up with IPv6 routing, they 558 will not affect IPv4 routing protocol at all. In the first phases 559 if it is uncertain whether joint IPv4/IPv6 networks work as 560 intended, having separate processes may be desirable and easier to 561 manage. 563 Thus the combinations are: 565 - Separate processes: 566 o OSPFv2 for IPv4, IS-IS for IPv6 (-only) 567 o OSPFv2 for IPv4, OSPFv3 for IPv6, or 568 o IS-IS for IPv4, OSPFv3 for IPv6 570 - The same process: 571 o IS-IS for both IPv4 and IPv6 573 Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 574 topologies must be "convex", unless the Multiple-topology IS-IS 575 extensions [MTISIS] have been implemented. In simpler networks or 576 with careful planning of IS-IS link costs, it is possible to keep 577 even non-congruent IPv4/IPv6 topologies "convex". 579 Therefore, the use of same process is recommended especially for 580 large ISPs which intend to deploy, in the short-term, a fully dual- 581 stack backbone infrastructure. If the topologies are not similar 582 in the short term, two processes (or Multi-topology IS-IS 583 extensions) are recommended. 585 The IGP is not typically used to carry customer prefixes or external 586 routes. Internal BGP (iBGP), as described in the next section, is 587 most often deployed in all routers to spread the other routing 588 information. 590 As some of the simplest devices, e.g. CPE routers, may not implement 591 other routing protocols than RIPng, in some cases it may be 592 necessary to also run RIPng in a limited fashion in addition to 593 another IGP, and somehow redistribute the routing information to the 594 other routing protocol(s). 596 4.3.2 EGP 598 BGP is used for both internal BGP and external BGP sessions. 600 BGP can be used for IPv6 with Multi-protocol extensions [RFC 2858], 601 [RFC 2545]. These enable exchanging both IPv6 routing information 602 as establishing BGP sessions using TCP over IPv6. 604 It is possible to use a single BGP session to advertise both IPv4 605 and IPv6 prefixes between two peers. However, typically, separate 606 BGP sessions are used. 608 4.3.3 Routing protocols transport 610 IPv4 routing information should be carried by IPv4 transport and 611 IPv6 one by IPv6 for several reasons: 613 * The IPv6 connectivity may work when the IPv4 one is down (or 614 vice-versa). 615 * The best route for IPv4 is not always the best one for IPv6. 616 * The IPv4 logical topology and the IPv6 one may be different 617 because, the administrator may want to use different metric 618 values for one physical link for load balancing or tunnels 619 may be used. 621 4.4 Multicast 623 Currently, IPv6 multicast is not a strong concern for most ISPs. 624 However, some of them consider deploying it. Multicast is achieved 625 using PIM-SM and PIM-SSM protocols. These also work with IPv6. 627 Information about multicast sources is exchanged using MSDP in IPv4, 628 but it is not defined, on purpose, for IPv6. An alternative 629 mechanism is to use only PIM-SSM or an alternative mechanism for 630 conveying the information [EMBEDRP]. 632 To be completed. send feedback/text! 634 5. Customer connection transition actions 636 5.1 Steps in transitioning customer connection networks 638 customer connection networks are generally composed of a large 639 number of CPEs connected to a small set of PEs. Transitioning this 640 infrastructure to IPv6 can be made in several steps, but some ISPs 641 may avoid some of the steps depending on their perception of risks. 643 Connecting IPv6 customers to an IPv6 backbone through an IPv4 644 network can be considered as a first careful step taken by an ISP in 645 order to provide IPv6 services to its IPv4 customers. More, some 646 ISPs also provide IPv6 services to customers who get their IPv4 647 services from another ISP. 649 This IPv6 service can be provided by using tunneling techniques. The 650 tunnel may terminate at the CPE corresponding to the IPv4 service or 651 in some other part of the customer's infrastructure (for instance, 652 on an IPv6 specific CPE or even on a host). 654 Several tunneling techniques have already been defined: configured 655 tunnels with tunnel broker, 6to4, Teredo... 657 The selection of one candidate depends largely on the presence or 658 not of NATs between the two tunnel end-points, and whether the 659 user's IPv4 tunnel end-point address is static or dynamic. In most 660 cases, 6to4 and ISATAP are incompatible with NATs and an UDP 661 encapsulation for configured tunnels has not been specified. 663 Firewalls in the way can also break these types of tunnels. The 664 administrator of the firewall will have to create a hole for the 665 tunnel. It is not a big deal as long as the firewall is controlled 666 either by the customer or the ISP, which is almost always the case. 668 An ISP has practically two kinds of customers in the customer 669 connection networks: small end users (mostly "unmanaged networks"; 670 home and SOHO users), and others. The former category typically has 671 a dynamic IPv4 address which is often NATted; a reasonably static 672 address is also possible. The latter category typically has static 673 IPv4 addresses, and at least some of them are public; however, NAT 674 traversal or configuring the NAT may be required to reach an 675 internal IPv6 access router, though. 677 Tunneling consideration for small and end sites are discussed in 678 [UNMANCON], that may identify solutions relevant to the first 679 category of unmanaged network. These solutions will be further 680 discussed within an ISP context, when available. 682 For the second category, usually: 684 * Configured tunnels as-is are a good solution when an NAT is not in 685 the way and the IPv4 end-point addresses are static. A mechanism to 686 punch through NATs or to forward packets through it may be desirable 687 in some scenarios. If fine-grained access control is needed, an 688 authentication protocol needs to be used. 690 * A tunnel brokering solution, to help facilitate the set-up of a 691 bi-directional tunnel, has been proposed: the Tunnel Set-up 692 Protocol. Whether this is the right way needs to be determined. 694 * Automatic tunneling mechanisms such as 6to4 or Teredo are not 695 applicable in this scenario. 697 Some other ISPs may take a more direct approach and avoid the use of 698 tunnels as much as possible. 700 Note that when the customers use dynamic IPv4 addresses, the 701 tunneling techniques may be more difficult at the ISP's end, 702 especially if a protocol not including authentication (like PPP for 703 IPv6) is not used. This may need to be considered in more detail 704 with tunneling mechanisms. 706 5.2 Access control requirements 708 Access control is usually required in ISP networks because the ISPs 709 need to control to who they are giving access. For instance, it is 710 important to check if the user who tries to connect is really a 711 valid customer. In some cases, it is also important for billing 712 purposes. 714 However, an IPv6 specific access control is not always required. 715 This is for instance the case when a customer of the IPv4 service 716 has automatically access to the IPv6 service. Then, the IPv4 access 717 control also gives access to the IPv6 services. 719 When the provider does not wish to give to its IPv4 customers 720 automatically access to IPv6 services, a specific access control for 721 IPv6 must be performed in parallel to the IPv4 one. It does not mean 722 that a different user authentication must be performed for IPv6, but 723 the authentication process may lead to different results for IPv4 724 and IPv6 access. 726 Access control traffic may use IPv4 or IPv6 transport. For instance, 727 Radius traffic related to an IPv6 service can be transported over 728 IPv4. 730 5.3 Configuration of customer equipment 732 The customer connection networks are composed of CPEs and PEs. 733 Usually, each PE connects a large number of CPEs to the backbone 734 network infrastructure. This number may reach tens of thousands or 735 more. The configuration of CPEs is an heavy task for the ISP and 736 this is even made harder as the configuration must be done remotely. 737 In this context, the use of auto-configuration mechanisms is very 738 beneficial, even if manual configuration is still an option. 740 The parameters that usually need to be automatically provided to the 741 customers are: 743 - The network prefix delegated by the ISP, 744 - The address of the Domain Name System server (DNS), 745 - Some other parameters such as the address of an NTP server 746 may also be needed sometimes. 748 When access control is required on the ISP network, DHCPv6 can 749 provide the configuration parameters. This is discussed more in 750 details in [DUAL ACCESS]. 752 When access control is not required (unusual case), a stateless 753 mechanism could be used, but no standard definition exists at the 754 moment. 756 5.4 Requirements for Traceability 758 Most ISPs have some kind of mechanism to trace the origin of traffic 759 in their networks. This has also to be available for IPv6 traffic. 760 This means that specific IPv6 address or prefix has to be tied to a 761 certain customer, or that records of which customer had which 762 address/prefix must be maintained. This also applies to the 763 customers with tunneled connectivity. 765 This can be done for example by mapping a DHCP response to a 766 physical connection and storing this in a database. It can also be 767 done by assigning a static address or refix to the customer. 769 For any traceability to be useful, ingress filtering must be 770 deployed towards all the customers. 772 5.5 Multi-homing 774 Customers may desire multihoming or multi-connecting for a number of 775 reasons [RFC3582]. 777 Multihoming to more than one ISP is a subject still under debate. 778 Deploying multiple addresses from each ISP and using the addresses 779 of the ISP when sending traffic to that ISP is at least one working 780 model; in addition, tunnels may be used for robustness [RFC3178]. 781 Currently, there are no provider-independent addresses for end- 782 sites. 784 Multi-connecting more than once to just one ISP is a simple 785 practice, and this can be done e.g. with BGP with public or private 786 AS numbers and a prefix assigned to the customer. 788 To be further defined as the multihoming situation gets clearer. 790 5.6 Ingress filtering in the customer connection network 792 Ingress filtering must be deployed everywhere towards the customers, 793 to ensure traceability, prevent DoS attacks using spoofed addresses, 794 prevent illegitimate access to the management infrastructure, etc. 796 The ingress filtering can be done for example using access lists or 797 Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are 798 described in [BCP38UPD]. 800 6. Network and service operation actions 802 The network and service operation actions fall into different 803 categories listed below: 805 - IPv6 network devices configuration: for initial configuration 806 and updates 807 - IPv6 Network Management 808 - IPv6 Monitoring 809 - IPv6 customer management 810 - built-in "network and service operation" IPv6 security 812 Some of these actions will require an IPv6 native transport layer to 813 be available, while some other will not. 815 In a first step, network devices configuration and regular network 816 management operations can be performed over an IPv4 transport, as 817 IPv6 MIBs are also available over IPv4 transport. 819 Nevertheless, some monitoring functions require IPv6 transport 820 availability. This is for instance the case when ICMP messages are 821 used by the monitoring applications. 823 In a second step, IPv6 transport can be provided for any of these 824 network and service operation facilities. 826 [To be completed, send feedback/text!] 828 7. Future Stages 830 After a while the ISP might want to transition to a service that is 831 IPv6 only, at least in certain parts of the network. This 832 transition creates a lot of new cases in which to factor in how to 833 maintain the IPv4 service. Providing an IPv6 only service is not 834 much different than the dual IPv4/IPv6 service described in stage 3 835 except from the need to phase out the IPv4 service. The delivery of 836 IPv4 services over an IPv6 network and the phase out is left for a 837 future document. 839 8. Example networks 841 In this section, a number of different network examples are 842 presented. They are only example networks and will not necessary 843 match to any existing networks. Nevertheless, the examples will 844 hopefully be useful even in the cases when they do not match the 845 target networks. The purpose of the example networks is to exemplify 846 the applicability of the transition mechanisms described in this 847 document on a number of different example networks with different 848 prerequisites. 850 The example network layout will be the same in all network examples. 851 The networks examples are to be seen as a specific representation of 852 the generic network with a limited number of network devices. An 853 arbitrary number (in this case 7) of routers have been selected to 854 represent the network examples. However, since the network examples 855 follow the implementation strategies recommended for the generic 856 network scenario, it should be possible to scale the example to fit 857 a network with an arbitrary number, e.g. several hundreds or 858 thousands, of routers. 860 The routers in the example are interconnected with each other as 861 well as with another ISP. The connection to another ISP can either 862 be a direct connection or through an exchange point. In addition to 863 these connections, there are also a number of customer connection 864 networks connected to the routers. customer connection networks are 865 normally connected to the backbone via access routers, but can in 866 some cases be directly connected to the backbone routers. As 867 described earlier in the generic network scenarios, the customer 868 connection networks are used to connect the customers. customer 869 connection networks can, for example, be xDSL or cable network 870 equipment. 871 | 872 ISP1 | ISP2 873 +------+ | +------+ 874 | | | | | 875 |Router|--|--|Router| 876 | | | | | 877 +------+ | +------+ 878 / \ +----------------------- 879 / \ 880 / \ 881 +------+ +------+ 882 | | | | 883 |Router|----|Router| 884 | | | | 885 +------+ +------+\ 886 | | \ | Exchange point 887 +------+ +------+ \ +------+ | +------+ 888 | | | | \_| | | | |-- 889 |Router|----|Router|----\|Router|--|--|Switch|-- 890 | | | | | | | | |-- 891 +------+ /+------+ +------+ | +------+ 892 | / | | 893 +-------+/ +-------+ | 894 | | | | 895 |Access1| |Access2| 896 | | | | 897 +-------+ +-------+ 898 ||||| ||||| ISP Network 899 ----|-----------|---------------------- 900 | | Customer Networks 901 +--------+ +--------+ 902 | | | | 903 |Customer| |Customer| 904 | | | | 905 +--------+ +--------+ 906 Figure 2: ISP network example 908 8.1 Example 1 910 In example 1 a network built according to the example topology is 911 present with a native IPv4 backbone, the routers. The backbone is 912 running IS-IS and IBGP as routing protocol for internal and external 913 routes respectively. In the connection to ISP2 and the exchange 914 point MBGP is used to exchange routes. Multicast is present and is 915 using PIM-SM routing. QoS is present and is using DiffServ. 917 Access 1 is xDSL, connected to the backbone through an access 918 router. The xDSL equipment, except for the access router, is 919 considered to be layer 2 only, e.g. Ethernet or ATM. IPv4 addresses 920 are dynamically assigned to the customer using DHCP. No routing 921 information is exchanged with the customer. Access control and 922 traceability is done in the access router. Customers are separated 923 in VLANs or separate ATM PVCs up to the access router. 925 Access 2 is Fiber to the building/home connected directly to the 926 backbone router. The FTTB/H is considered to be layer 3 aware and 927 performs access control and traceability through its layer 3 928 awareness. IPv4 addresses are dynamically assigned to the customers 929 using DHCP. No routing information is exchanged with the customer. 931 8.2 Example 2 933 In example 2 the backbone is running IPv4 with MPLS. Routing 934 protocols used are OSPF and IBGP for internal and external routes. 935 In the connection to ISP2 and the exchange point BGP is used to 936 exchange routes. Multicast and QoS are not present. 938 Access 1 is a fixed line access, e.g. fiber, connected directly to 939 the backbone. CPE is present at the customer and routing information 940 is in some cases exchanged otherwise static routing is used. Access 941 1 can also be connected to BGP/MPLS-VPN running in the backbone. 943 Access 2 is xDSL connected directly to the backbone router. The xDSL 944 is layer 3 aware. Addresses are dynamically assigned using DHCP. 945 Access control is achieved on the physical layer and traceability is 946 achieved using DHCP snooping. No routing information is exchanged 947 with the customer. 949 8.3 Example 3 951 A transit provider offers IP connectivity to other providers, but 952 not to end users or enterprises. IS-IS and IBGP is used internally 953 and BGP externally. Its accesses connect Tier-2 provider cores. No 954 multicast or QoS is used. 956 9. Security Considerations 958 This document analyses scenarios and identifies some transition 959 mechanisms that could be used for the scenarios. It does not 960 introduce any new security issues. Security considerations of each 961 mechanism are described in the respective documents. 963 10. Acknowledgements 965 This draft has greatly benefited from inputs by Pekka Savola, Marc 966 Blanchet, Jordi Palet. 968 11. Informative references 970 [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of 971 RP in IPv6 Multicast Address" - 972 draft-ietf-mboned-embeddedrp-00.txt 974 [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- 975 ISIS: Multi Topology (MT) Routing in IS-IS" 976 draft-ietf-isis-wg-multi-topology-06.txt 978 [RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, 979 "Multiprotocol Extensions for BGP-4" 980 RFC 2858 982 [RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol 983 Extensions for IPv6 Inter-Domain Routing" 984 RFC 2545 986 [BCP38UPD] F. Baker, P. Savola "Ingress Filtering for 987 Multihomed Networks" 989 [RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- 990 Multihoming Architectures" 991 RFC 3582 993 [RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at 994 Site Exit Routers" 995 RFC 3178 997 [BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost, 998 F. Le Faucheur "Connecting IPv6 Islands across IPv4 999 Clouds with BGP" 1000 draft-ooms-v6ops-bgp-tunnel-00.txt 1002 [DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi 1003 "A Model of IPv6/IPv4 Dual Stack Internet Access 1004 Service" 1005 draft-shirasaki-dualstack-service-02.txt 1007 [UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations 1008 for IPv6 Tunneling Solutions in Small End Sites" 1009 draft-chown-v6ops-unmanaged-connectivity-00 1011 Authors' Addresses 1013 Mikael Lind 1014 TeliaSonera 1015 Vitsandsgatan 9B 1016 SE-12386 Farsta, Sweden 1017 Email: mikael.lind@teliasonera.com 1019 Vladimir Ksinant 1020 6WIND S.A. 1021 Immeuble Central Gare - Bat.C 1022 1, place Charles de Gaulle 1023 78180, Montigny-Le-Bretonneux - France 1024 Phone: +33 1 39 30 92 36 1025 Email: vladimir.ksinant@6wind.com 1027 Soohong Daniel Park 1028 Mobile Platform Laboratory, SAMSUNG Electronics. 1030 416, Maetan-3dong, Paldal-Gu, 1031 Suwon, Gyeonggi-do, Korea 1032 Email: soohong.park@samsung.com 1034 Alain Baudot 1035 France Telecom R&D 1036 42, rue des coutures 1037 14066 Caen - FRANCE 1038 Email: alain.baudot@rd.francetelecom.com 1040 Intellectual Property Statement 1042 The IETF takes no position regarding the validity or scope of any 1043 intellectual property or other rights that might be claimed to 1044 pertain to the implementation or use of the technology described in 1045 this document or the extent to which any license under such rights 1046 might or might not be available; neither does it represent that it 1047 has made any effort to identify any such rights. Information on the 1048 IETF's procedures with respect to rights in standards-track and 1049 standards-related documentation can be found in BCP-11. Copies of 1050 claims of rights made available for publication and any assurances 1051 of licenses to be made available, or the result of an attempt made 1052 to obtain a general license or permission for the use of such 1053 proprietary rights by implementers or users of this specification 1054 can be obtained from the IETF Secretariat. 1056 The IETF invites any interested party to bring to its attention any 1057 copyrights, patents or patent applications, or other proprietary 1058 rights which may cover technology that may be required to practice 1059 this standard. Please address the information to the IETF Executive 1060 Director. 1062 Full Copyright Statement 1064 Copyright (C) The Internet Society (2003). All Rights Reserved. 1066 This document and translations of it may be copied and furnished to 1067 others, and derivative works that comment on or otherwise explain it 1068 or assist in its implementation may be prepared, copied, published 1069 and distributed, in whole or in part, without restriction of any 1070 kind, provided that the above copyright notice and this paragraph 1071 are included on all such copies and derivative works. However, this 1072 document itself may not be modified in any way, such as by removing 1073 the copyright notice or references to the Internet Society or other 1074 Internet organizations, except as needed for the purpose of 1075 developing Internet standards in which case the procedures for 1076 copyrights defined in the Internet Standards process must be 1077 followed, or as required to translate it into languages other than 1078 English. 1080 The limited permissions granted above are perpetual and will not be 1081 revoked by the Internet Society or its successors or assignees. 1083 This document and the information contained herein is provided on an 1084 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1085 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1086 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1087 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1088 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.