idnits 2.17.1 draft-ietf-v6ops-isp-scenarios-analysis-01.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 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 (February 2004) is 7376 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) == Missing Reference: 'STEP' is mentioned on line 641, but not defined == Missing Reference: 'TSP' is mentioned on line 641, but not defined -- 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 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Lind 3 TeliaSonera 4 V. Ksinant 5 6WIND 6 S. Park 7 Samsung Electronics 8 A. Baudot 9 France Telecom 10 P. Savola 11 CSC/Funet 12 Expires: August 2004 February 2004 14 Scenarios and Analysis for Introducing IPv6 into ISP Networks 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document first describes different scenarios for the 39 introduction of IPv6 into an ISP's existing IPv4 network without 40 disrupting the IPv4 service. Then, this document analyses these 41 scenarios and evaluates the relevance of the already defined 42 transition mechanisms in this context. Known challenges are also 43 identified. 45 Table of Contents 47 1. Introduction................................................2 48 1.1 Goal and Scope of the Document...........................2 49 2. Brief Description of a Generic ISP Network..................3 50 3. Transition Scenarios........................................4 51 3.1 Identification of Stages and Scenarios...................4 52 3.2 Stages...................................................5 53 3.2.1 Stage 1 Scenarios: Launch..............................5 54 3.2.2 Stage 2a Scenarios: Backbone...........................6 55 3.2.3 Stage 2b Scenarios: Customer Connection................6 56 3.2.4 Stage 3 Scenarios: Complete............................6 57 3.2.5 Stages 2a and 3: Combination Scenarios.................7 58 3.3 Transition Scenarios.....................................7 59 3.4 Actions Needed When Deploying IPv6 in an ISP's network...7 60 4. Backbone Transition Actions.................................8 61 4.1 Steps in Transitioning Backbone Networks.................8 62 4.1.1 MPLS Backbone..........................................9 63 4.2 Configuration of Backbone Equipment.....................10 64 4.3 Routing.................................................10 65 4.3.1 IGP...................................................10 66 4.3.2 EGP...................................................11 67 4.3.3 Transport of Routing Protocols........................12 68 4.4 Multicast...............................................12 69 5. Customer Connection Transition Actions.....................12 70 5.1 Steps in Transitioning Customer Connection Networks.....12 71 5.2 Access Control Requirements.............................14 72 5.3 Configuration of Customer Equipment.....................15 73 5.4 Requirements for Traceability...........................16 74 5.5 Ingress Filtering in the Customer Connection Network....16 75 5.6 Multi-Homing............................................16 76 5.7 Quality of Service......................................16 77 6. Network and Service Operation Actions......................17 78 7. Future Stages..............................................17 79 8. Example Networks...........................................18 80 8.1 Example 1...............................................19 81 8.2 Example 2...............................................21 82 8.3 Example 3...............................................21 83 9. Security Considerations....................................22 84 10. Acknowledgements...........................................22 85 11. Informative References.....................................22 87 1. Introduction 89 1.1 Goal and Scope of the Document 91 When an ISP deploys IPv6, its goal is to provide IPv6 connectivity 92 to its customers. The new IPv6 service must be added to an already 93 existing IPv4 service, and the introduction of IPv6 must not 94 interrupt this IPv4 service. 96 An ISP offering IPv4 service will find different ways to add IPv6 to 97 this service. This document discusses a small set of scenarios for 98 the introduction of IPv6 into an ISP's IPv4 network. It evaluates the 99 relevance of the existing transition mechanisms in the context of 100 these deployment scenarios, and points out the lack of functionality 101 essential to the ISP's operation 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 IPv6-only service. 105 It is also outside the scope of this document to describe different 106 types of access or network technologies. 108 2. Brief Description of a Generic ISP Network 110 A generic network topology for an ISP can be divided into two main 111 parts: the backbone network and the customer connection networks 112 connecting the customers. It includes, in addition to these, some 113 other building blocks such as network and service operations. The 114 additional building blocks used in this document are defined as 115 follows: 117 "CPE" : Customer Premises Equipment 119 "PE" : Provider Edge equipment 121 "Network and service operation" 122 : This is the part of the ISP's network that hosts the 123 services required for the correct operation of the 124 ISP's network. These services usually include 125 management, supervision, accounting, billing, and 126 customer management applications. 128 "Customer connection" 129 : This is the part of the network used by a customer 130 when connecting to an ISP's network. It includes the 131 CPE, the last hop link and the parts of the PE 132 interfacing to the last hop link. 134 "Backbone" : This is the rest of the ISP's network infrastructure. 135 It includes the parts of the PE interfacing to the 136 core, the core routers of the ISP, and the border 137 routers used to exchange routing information with 138 other ISPs (or other administrative entities). 140 "Dual-stack network": 141 A network that supports natively both IPv4 and 142 IPv6. 144 It is noted that, in some cases (e.g., incumbent national or 145 regional operators), a given customer connection network may have 146 to be shared between or among different ISPs. According to the type 147 of customer connection network used (e.g., one involving only layer 2 148 devices or one involving non-IP technology), this constraint may 149 result in architectural considerations relevant to this document. 151 The basic components in the ISP's network are depicted in Figure 1. 153 ------------ ---------- 154 | Network and| | | 155 | Service |--| Backbone | 156 | Operation | | |\ 157 ------------ ---------- \ 158 . / | \ \ 159 . / | \ \_Peering( Direct and IX ) 160 . / | \ 161 . / | \ 162 . / | \ 163 ---------- / ---------- \ ---------- 164 | Customer | / | Customer | \ | Customer | 165 |Connection|--/ |Connection| \--|Connection| 166 | 1 | | 2 | | 3 | 167 ---------- ---------- ---------- 168 | | | ISP's Network 169 ------------------------------------------------------- 170 | | | Customers' Networks 171 +--------+ +--------+ +--------+ 172 | | | | | | 173 |Customer| |Customer| |Customer| 174 | | | | | | 175 +--------+ +--------+ +--------+ 176 Figure 1: ISP Network Topology. 178 3. Transition Scenarios 180 3.1 Identification of Stages and Scenarios 182 This section describes different stages an ISP might consider when 183 introducing IPv6 connectivity into its existing IPv4 network and the 184 different scenarios that might occur in the respective stages. 186 The stages here are snapshots of the ISP's network with respect to 187 IPv6 maturity. Because the ISP's network is continually evolving, a 188 stage is a measure of how far along the ISP has come in terms of 189 implementing the functionality necessary to offer IPv6 to the 190 customers. 192 It is possible to transition freely between different stages. 193 Although a network segment can only be in one stage at a time, the 194 ISP's network as a whole can be in different stages. Different 195 transition paths can be followed from the first to the final stage. 196 The transition between two stages does not have to be instantaneous; 197 it can occur gradually. 199 Each stage has different IPv6 properties. An ISP can, therefore, 200 based on its requirements, decide which set of stages it will follow 201 to transform its network. 203 This document is not aimed to cover small ISPs, hosting providers, or 204 data centers; only the scenarios applicable to ISPs eligible for a 205 /32 IPv6 prefix allocation from a RIR are covered. 207 3.2 Stages 209 The stages are derived from the generic description of an ISP's 210 network in Section 2. Combinations of different building blocks 211 that constitute an ISP's environment lead to a number of scenarios 212 from which the ISP can choose. The scenarios most relevant for this 213 document are the ones that maximize ISP's ability to offer IPv6 to 214 its customers in the most efficient and feasible way. The assumption 215 in all stages is that the ISP's goal is to offer both IPv4 and IPv6 216 to the customer. 218 The four most probable stages are: 220 o Stage 1 Launch 221 o Stage 2a Backbone 222 o Stage 2b Customer connection 223 o Stage 3 Complete 225 Generally, an ISP is able to upgrade a current IPv4 network to an 226 IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can 227 also be implemented at a small cost by adding simple tunnel 228 mechanisms to the existing configuration. When designing a new 229 network, Stage 3 might be the first and last step, because there are 230 no legacy concerns. Nevertheless, the absence of IPv6 capability in 231 the network equipment can still be a limiting factor. 233 Note that in every stage except Stage 1, the ISP can offer both IPv4 234 and IPv6 services to its customers. 236 3.2.1 Stage 1 Scenarios: Launch 238 The first stage is an IPv4-only ISP with an IPv4 customer. This is 239 the most common case today and the natural starting point for the 240 introduction of IPv6. From this stage, the ISP can move (transition) 241 from Stage 1 to any other stage with the goal of offering IPv6 to its 242 customer. 244 The immediate first step consists of getting a prefix allocation 245 (typically a /32) from the appropriate RIR according to allocation 246 procedures. 248 3.2.2 Stage 2a Scenarios: Backbone 250 Stage 2a consists of an ISP with IPv4-only customer connection 251 networks and a backbone that supports both IPv4 and IPv6. In 252 particular, the ISP has the possibility of making the backbone IPv6- 253 capable through either software upgrades, hardware upgrades, or a 254 combination of both. 256 Since the customer connections are not yet upgraded, a tunneling 257 mechanism has to be used to provide IPv6 connectivity through the 258 IPv4 customer connection networks. The customer can terminate the 259 tunnel at the CPE (if it has IPv6 support) or at each individual 260 device. In the former case, the CPE will then provide global IPv6 261 connectivity to all devices in the customer's network. 263 3.2.3 Stage 2b Scenarios: Customer Connection 265 Stage 2b consists of an ISP with an IPv4 backbone network and a 266 customer connection network that supports both IPv4 and IPv6. Because 267 the service to the customer is native IPv6, the customer is not 268 required to support both IPv4 and IPv6. This is the biggest 269 difference in comparison with the previous stage. The need to 270 exchange IPv6 traffic still exists but might be more complicated than 271 in the previous case, because the backbone is not IPv6-enabled. After 272 completing Stage 2b, the original IPv4 backbone is unchanged. This 273 means that the IPv6 traffic is transported by either tunnelling over 274 the existing IPv4 backbone, or in an IPv6 overlay network more or 275 less separated from the IPv4 backbone. 277 Normally the ISP will continue to provide IPv4 connectivity; in 278 many cases private IPv4 addresses and NATs will continue to be used. 280 3.2.4 Stage 3 Scenarios: Complete 282 Stage 3 can be said to be the final step in introducing IPv6, at 283 least within the scope of this document. This consists of ubiquitous 284 IPv6 service with native support for IPv6 and IPv4 in both backbone 285 and customer connection networks. This stage is identical to the 286 previous stage from the customer's perspective, because the customer 287 connection network has not changed. The requirement for exchanging 288 IPv6 traffic is identical to Stage 2. 290 3.2.5 Stages 2a and 3: Combination Scenarios 292 Some ISPs may use different access technologies of varying IPv6 293 maturity. This may result in a combination of the Stages 2a and 3: 294 some customer connections do not support IPv6, but others do; in both 295 cases the backbone is dual-stack. 297 This is equivalent to Stage 2a, but it requires support for native 298 IPv6 customer connections on some access technologies. 300 3.3 Transition Scenarios 302 Given the different stages, it is clear that an ISP has to be able 303 to transition from one stage to another. The initial stage, in this 304 document, is IPv4-only service and network. The end stage is dual 305 IPv4/IPv6 service and network. 307 The transition starts with an IPv4 ISP and then moves in one of 308 three directions. This choice corresponds to the different 309 transition scenarios. Stage 2a consists of upgrading the backbone 310 first. Stage 2b consists of upgrading the customer connection 311 network. Finally, Stage 3 consists of introducing IPv6 in both the 312 backbone and customer connections as needed. 314 Because most of ISPs continually evolve their backbone IPv4 networks 315 (firmware replacements in routers, new routers, etc.), they will be 316 able to get them ready for IPv6 without additional investment 317 (except staff training). This may be a slower but still useful 318 transition path, because it allows for IPv6 introduction without any 319 actual customer demand. This may be superior to doing everything 320 at the last minute, which may entail a higher investment. However, it 321 is important to start considering (and requesting from the vendors) 322 IPv6 features in all new equipment from the start. Otherwise, the 323 time and effort to remove non-IPv6-capable hardware from the network 324 will be significant. 326 3.4 Actions Needed When Deploying IPv6 in an ISP's network 328 Examination of the transitions described above reveals that it 329 is possible to split the work required for each transition into a 330 small set of actions. Each action is largely independent from the 331 others, and some actions may be common to multiple transitions. 333 Analysis of the possible transitions leads to a small list of 334 actions: 336 * Actions required for backbone transition: 338 - Connect dual-stack customer connection networks to other 339 IPv6 networks through an IPv4 backbone. 341 - Transform an IPv4 backbone into a dual-stack one. This 342 action can be performed directly or through intermediate 343 steps. 345 * Actions required for customer connection transition: 347 - Connect IPv6 customers to an IPv6 backbone through an IPv4 348 network. 350 - Transform an IPv4 customer connection network into a dual- 351 stack one. 353 * Actions required for network and service operation transition: 355 - Configure IPv6 functions into network components. 357 - Upgrade regular network management and monitoring 358 applications to take IPv6 into account. 360 - Extend customer management (e.g., RADIUS) mechanisms 361 to be able to supply IPv6 prefixes and other information 362 to customers. 364 - Enhance accounting, billing, etc. to work with IPv6 365 as needed. (Note: if dual-stack service is offered, this 366 may not be necessary.) 368 - Implement security for network and service operation. 370 Sections 4, 5, and 6 contain detailed descriptions of each action. 372 4. Backbone Transition Actions 374 4.1 Steps in Transitioning Backbone Networks 376 In terms of physical equipment, backbone networks consist mainly of 377 high-speed core and edge routers. Border routers provide peering 378 with other providers. Filtering, routing policy, and policing 379 functions are generally managed on border routers. 381 The initial step is an IPv4-only backbone, and the final step is a 382 completely dual-stack backbone. In between, intermediate steps may be 383 identified: 385 Tunnels Tunnels 386 IPv4-only ----> or ---> or + DS -----> Full DS 387 dedicated IPv6 dedicated IPv6 routers 388 links links 389 Figure 2: Migration Path. 391 The first step involves tunnels or dedicated links but leaves 392 existing routers unchanged. Only a small set of routers then have 393 IPv6 capabilities. Using configured tunnels is adequate during 394 this step. 396 In the second step, some dual stack routers are added, progressively, 397 to this network. 399 The final step is reached when all or almost all routers are dual- 400 stack. 402 For many reasons (technical, financial, etc.), the ISP may progress 403 step by step or jump directly the final one. One of the important 404 criteria in planning this evolution is the number of IPv6 405 customers the ISP expects during its initial deployments. If few 406 customers connect to the original IPv6 infrastructure, then the ISP 407 is likely to remain in the initial steps for a long time. 409 In short, each intermediate step is possible, but none is mandatory. 411 4.1.1 MPLS Backbone 413 If MPLS is already deployed in the backbone, it may be desirable 414 to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 415 Label Switched Path (LSP) requires signaling through the MPLS 416 network; both LDP and RSVP-TE can set up IPv6 LSPs, but this would 417 require a software upgrade in the MPLS core network. An alternative 418 approach is to use BGP for signaling or to perform, for example, 419 IPv6-over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, 420 as described in [BGPTUNNEL]. Some of the multiple possibilities are 421 preferable to others depending on the specific environment under 422 consideration. More analysis is needed, case by case, to determine 423 the best approach or approaches: 425 1) Require that MPLS networks deploy native IPv6 support or 426 use configured tunneling for IPv6. 428 2) Require that MPLS networks support setting up IPv6 LSPs, 429 and set up IPv6 connectivity by using either these or 430 configured tunneling. 432 3) Use only configured tunneling over IPv4 LSPs; this seems 433 practical with small-scale deployments having few tunnels. 435 4) Use [BGPTUNNEL] or something comparable to perform IPv6-over- 436 IPv4/MPLS encapsulation for IPv6 connectivity. 438 Approaches 1 and 2 are the most attractive if the ISP is willing to 439 perform an upgrade to the MPLS network. Approach 3 does not require 440 any upgrades but may lack scalability. Approach 4 may be economically 441 attractive for an operator who does not wish to upgrade the MPLS 442 network and has a large-scale deployment. 444 MPLS networks have typically been deployed to facilitate services 445 such as Provider-Provisioned VPNs. Software upgrades are commonplace 446 in MPLS networks. No particular reason exists to avoid adding IPv6 447 functionality, except if the vendor is unable to provide sufficient 448 IPv6 forwarding capability (e.g., line-speed) in the existing 449 hardware (independent of the capabilities for handling MPLS frames). 450 Therefore, recommending mechanisms like [BGPTUNNEL] as the final 451 solution might not be such a good idea. 453 4.2 Configuration of Backbone Equipment 455 In the backbone, the number of devices is small and IPv6 456 configuration mainly deals with routing protocol parameters, 457 interface addresses, loop-back addresses, ACLs, etc. 459 These IPv6 parameters are not supposed to be configured 460 automatically. 462 4.3 Routing 464 ISPs need routing protocols to advertise reachability and to 465 find the shortest working paths, both internally and externally. 467 OSPFv2 and IS-IS are typically used as an IPv4 IGP. RIPv2 is not 468 typically used in operator networks. BGP is the only IPv4 EGP. 469 Static routes also are used in both cases. 471 Note that it is possible to configure a given network so that it 472 results in having an IPv6 topology different from its IPv4 topology. 473 For example, some links or interfaces may be dedicated to IPv4-only 474 or IPv6-only traffic, or some routers may be dual-stack whereas 475 others may be IPv4 or IPv6 only. In this case, routing protocols must 476 be able to understand and cope with multiple topologies. 478 4.3.1 IGP 480 Once the IPv6 topology has been determined, the choice of IPv6 IGP 481 must be made: either OSPFv3 or IS-IS for IPv6. RIPng is less 482 appropriate in many contexts and is not discussed here. The IGP 483 typically includes the routers' point-to-point and loop-back 484 addresses. 486 The most important decision is whether one wishes to have separate 487 routing protocol processes for IPv4 and IPv6. Separating them 488 requires more memory and CPU for route calculations, e.g., when the 489 links flap. On the other hand, separation provides a certain measure 490 of assurance that if problems arise with IPv6 routing, they will not 491 affect IPv4 the routing protocol at all. In the initial phases, if 492 it is uncertain whether joint IPv4-IPv6 networking is working as 493 intended, running separate processes may be desirable and easier to 494 manage. 496 Thus the possible combinations are: 498 - with separate processes: 499 o OSPFv2 for IPv4, IS-IS for IPv6 (only) 500 o OSPFv2 for IPv4, OSPFv3 for IPv6, or 501 o IS-IS for IPv4, OSPFv3 for IPv6 503 - with the same process: 504 o IS-IS for both IPv4 and IPv6 506 Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 507 topologies must be "convex," unless the Multiple-topology IS-IS 508 extensions [MTISIS] have been implemented. In simpler networks or 509 with careful planning of IS-IS link costs, it is possible to keep 510 even incongruent IPv4/IPv6 topologies "convex." 512 Therefore, the use of same process is recommended especially for 513 large ISPs intending to deploy, in the short-term, a fully dual- 514 stack backbone infrastructure. If the topologies will not be similar 515 in the short term, two processes (or Multi-topology IS-IS 516 extensions) are recommended. 518 The IGP is not typically used to carry customer prefixes or external 519 routes. Internal BGP (iBGP), as described in the next section, is 520 most often deployed in all routers to distribute such other routing 521 information. 523 Because some of the simplest devices, e.g., CPE routers, may not 524 implement routing protocols other than RIPng, in some cases it may 525 also be necessary to run RIPng in addition to one of the above IGPs, 526 at least in a limited fashion, and somehow to redistribute routing 527 information between the routing protocols. 529 4.3.2 EGP 530 BGP is used for both internal and external BGP sessions. 532 BGP with Multi-protocol extensions [RFC 2858] can be used for IPv6 533 [RFC 2545]. These extensions enable exchanging both IPv6 routing 534 information and establishing BGP sessions using TCP over IPv6. 535 It is possible to use a single BGP session to advertise both IPv4 536 and IPv6 prefixes between two peers. However, typically, separate 537 BGP sessions are used. 539 4.3.3 Transport of Routing Protocols 541 IPv4 routing information should be carried by IPv4 transport and 542 similarly IPv6 routing information by IPv6 for several reasons: 544 * IPv6 connectivity may work when IPv4 connectivity is down 545 (or vice-versa). 546 * The best route for IPv4 is not always the best one for IPv6. 547 * The IPv4 logical topology and the IPv6 one may be different, 548 because the administrator may want to assign different metrics 549 to a physical link for load balancing or tunnels may be used. 551 4.4 Multicast 553 Currently, IPv6 multicast is not a major concern for most ISPs. 554 However, some of them are considering deploying it. Multicast is 555 achieved using the PIM-SM and PIM-SSM protocols. These also work with 556 IPv6. 558 Information about multicast sources is exchanged using MSDP in IPv4, 559 but MSDP is intentionally not defined for IPv6. Instead, one should 560 use only PIM-SSM or an alternative mechanism for conveying the 561 information [EMBEDRP]. 563 5. Customer Connection Transition Actions 565 5.1 Steps in Transitioning Customer Connection Networks 567 Customer connection networks are generally composed of a small set of 568 PEs connected to a large set of CPEs. Transitioning this 569 infrastructure to IPv6 can be accomplished in several steps, but some 570 ISPs, depending on their perception of the risks, may avoid some of 571 the steps. 573 Connecting IPv6 customers to an IPv6 backbone through an IPv4 574 network can be considered as a first careful step taken by an ISP to 575 provide IPv6 services to its IPv4 customers. In addition, some 576 ISPs may also provide IPv6 services to customers who get their IPv4 577 services from another ISP. 579 This IPv6 service can be provided by using tunneling techniques. The 580 tunnel may terminate at the CPE corresponding to the IPv4 service or 581 in some other part of the customer's infrastructure (for instance, 582 on IPv6-specific CPE or even on a host). 584 Several tunneling techniques have already been defined: configured 585 tunnels with tunnel broker, 6to4, Teredo, etc. 587 The selection of one candidate depends largely on the presence or 588 absence of NATs between the two tunnel end-points and whether the 589 user's IPv4 tunnel end-point address is static or dynamic. In most 590 cases, 6to4 and ISATAP are incompatible with NATs, and UDP 591 encapsulation for configured tunnels has not been specified. 593 However, NAT traversal can be avoided if the NAT supports 594 forwarding protocol-41 [PROTO41]. 596 Firewalls in the path can also break these types of tunnels. The 597 administrator of the firewall needs to create a hole for the 598 tunnel. This is usually manageable, as long as the firewall is 599 controlled by either the customer or the ISP, which is almost always 600 the case. 602 When the CPE is performing NAT or firewall functions, terminating the 603 tunnels directly at the CPE typically simplifies the scenario 604 considerably, avoiding the NAT and firewall traversal. If such an 605 approach is adopted, the CPE has to support the tunneling mechanism 606 used, or be upgraded to do so. 608 In practice, an ISP has two kinds of customers in its customer 609 connection networks: small end users (mostly unmanaged networks-- 610 home and SOHO users) and others. The former category typically uses 611 a dynamic IPv4 address, which is often non-routable; a reasonably 612 static address is also possible. The latter category typically has 613 static IPv4 addresses, and at least some of them are public; however, 614 NAT traversal or configuration may be required to reach an internal 615 IPv6 access router. 617 Tunneling consideration for small end sites are discussed in 618 [UNMANCON] and [UNMANEVA]. These identify solutions relevant to the 619 first category of unmanaged networks. 621 The connectivity mechanisms can be categorized as "managed" or 622 "opportunistic." The former consist of native service or a 623 configured tunnel (with or without a tunnel broker); the latter 624 include 6to4 and, e.g., Teredo; they provide "short-cuts" between 625 nodes using the same mechanisms and are available without contracts 626 with the ISP. 628 The ISP may offer opportunistic services, mainly a 6to4 relay, 629 especially as a test when no "real" service is offered yet. At the 630 later phases, ISPs might also deploy 6to4 relays or Teredo servers 631 (or similar) to optimize their customers' connectivity to 6to4 or 632 Teredo nodes. 634 Most interesting are the managed services. When dual-stack is not an 635 option, a form of tunneling must be used. When configured tunneling 636 is not an option (e.g., due to dynamic IPv4 addressing), some form of 637 automation has to be used. The options are basically either to deploy 638 an L2TP architecture (whereby the customers would run L2TP clients 639 and PPP over it to initiate IPv6 sessions) or to deploy a tunnel 640 configuration service. The prime candidates for tunnel configuration 641 are STEP [STEP] and TSP [TSP], which are not analyzed further in this 642 document. 644 For connecting larger customers: 646 * Dual-stack access service is often a realistic possibility since 647 the customer network is managed. 649 * Configured tunnels, as-is, are a good solution when a NAT is not in 650 the way and the IPv4 end-point addresses are static. In this 651 scenario, NAT traversal is not typically required. If fine-grained 652 access control is needed, an authentication protocol needs to be 653 used. 655 * A tunnel brokering solution, to help facilitate the set-up of a 656 bi-directional tunnel, has been proposed: the Tunnel Set-up 657 Protocol. Whether this is the right approach needs to be 658 determined. 660 * Automatic tunneling mechanisms such as 6to4 or Teredo are not 661 suggested in this scenario. 663 Other ISPs may take a more direct approach and avoid the use of 664 tunnels as much as possible. 666 Note that when customers use dynamic IPv4 addresses, the 667 tunneling techniques may be more difficult to deploy at the ISP's 668 end, especially if a protocol including authentication (like PPP for 669 IPv6) is not used. This may need to be considered in more detail 670 with tunneling mechanisms. 672 5.2 Access Control Requirements 674 Access control is usually required in ISP networks, because the ISPs 675 need to control to whom they are granting access. For instance, it is 676 important to check whether the user who tries to connect is really a 677 valid customer. In some cases, it is also important for billing. 679 However, IPv6-specific access control is not always required. 680 This is the case, for instance, when a customer of the IPv4 service 681 has automatically access to IPv6 service. Then, the IPv4 access 682 control also provides access to the IPv6 services. 684 When a provider does not wish to give its IPv4 customers 685 automatic access to IPv6 services, specific IPv6 access control must 686 be performed in parallel with the IPv4 access control. This does not 687 imply that different user authentication must be performed for IPv6, 688 but merely that the authentication process may lead to different 689 results for IPv4 and IPv6 access. 691 Access control traffic may use IPv4 or IPv6 transport. For instance, 692 Radius traffic related to IPv6 service can be transported over 693 IPv4. 695 5.3 Configuration of Customer Equipment 697 The customer connection networks are composed of PE and CPE(s). 698 Usually, each PE connects multiple CPE components to the backbone 699 network infrastructure. This number may reach tens of thousands or 700 more. The configuration of CPE is, in general, a difficult task for 701 the ISP, and even more so in this case, because configuration must be 702 done remotely. In this context, the use of auto-configuration 703 mechanisms is beneficial, even if manual configuration is still an 704 option. 706 The parameters that usually need to be provided to customers 707 automatically are: 709 - The network prefix delegated by the ISP, 710 - The address of the Domain Name System server (DNS), 711 - Possibly other parameters, e.g., the address of a NTP server. 713 When user identification is required on the ISP's network, DHCPv6 may 714 be used to provide configurations otherwise either DHCPv6 or a 715 stateless mechanism can be used. This is discussed in more detail in 716 [DUAL ACCESS]. 718 Note that when the customer connection network is shared between the 719 users or the ISPs, and not just a point-to-point link, authenticating 720 the configuration of the parameters (esp. prefix delegation) requires 721 further study. 723 As long as IPv4 service is available alongside of IPv6, no critical 724 need exists to be able to autoconfigure IPv6 parameters (except for 725 the prefix) in the CPE-- IPv4 settings work as well. 727 5.4 Requirements for Traceability 729 Most ISPs have some kind of mechanism to trace the origin of traffic 730 in their networks. This also has to be available for IPv6 traffic, 731 which means that a specific IPv6 address or prefix has to be tied to 732 a certain customer, or that records of which customer had which 733 address or prefix must be maintained. This also applies to the 734 customers with tunneled connectivity. 736 This can be done, for example, by mapping a DHCP response to a 737 physical connection and storing this in a database. It can also be 738 done by assigning a static address or prefix to the customer. 740 5.5 Ingress Filtering in the Customer Connection Network 742 Ingress filtering must be deployed towards the customers, everywhere, 743 to ensure traceability, to prevent DoS attacks using spoofed 744 addresses, to prevent illegitimate access to the management 745 infrastructure, etc. 747 Ingress filtering can be done, for example, by using access lists or 748 Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are 749 described in [BCP38UPD]. 751 5.6 Multi-Homing 753 Customers may desire multi-homing or multi-connecting for a number of 754 reasons [RFC3582]. 756 Multi-homing to more than one ISP is a subject still under debate. 757 Deploying multiple addresses from each ISP and using the addresses 758 of the ISP when sending traffic to that ISP is at least one working 759 model; in addition, tunnels may be used for robustness [RFC3178]. 760 Currently, there are no provider-independent addresses for end- 761 sites. 763 Multi-connecting more than once to just one ISP is a simple 764 practice, and this can be done, e.g., by using BGP with public or 765 private AS numbers and a prefix assigned to the customer. 767 5.7 Quality of Service 769 In most networks, quality of service in one form or another is 770 important. 772 Naturally, the introduction of IPv6 should not impair existing 773 Service Level Agreements (SLAs) or similar quality reassurances. 775 Depending on the deployment of the IPv6 service, the service could 776 be best-effort, at least initially, even if the IPv4 service had a 777 SLA. 779 Both IntServ and DiffServ are equally applicable in IPv6 as well as 780 in IPv4 and work in a similar fashion. Of these, typically only 781 DiffServ has been implemented. 783 6. Network and Service Operation Actions 785 The network and service operation actions fall into different 786 categories as listed below: 788 - IPv6 network device configuration: for initial configuration 789 and updates 790 - IPv6 network management 791 - IPv6 monitoring 792 - IPv6 customer management 793 - IPv6 network and service operation security 795 Some of these items will require an IPv6 native transport layer to 796 be available, whereas others will not. 798 As a first step, network device configuration and regular network 799 management operations can be performed over an IPv4 transport, 800 because IPv6 MIBs are also available over IPv4 transport. 801 Nevertheless, some monitoring functions require the availability of 802 IPv6 transport. This is the case, for instance, when ICMPv6 messages 803 are used by the monitoring applications. 805 The current inability to get IPv4 and IPv6 traffic statistics for 806 management purposes by using SNMP separately from dual-stack 807 interfaces is an issue. 809 As a second step, IPv6 transport can be provided for any of these 810 network and service operation facilities. 812 7. Future Stages 814 At some point, an ISP might want to transition to a service that is 815 IPv6 only, at least in certain parts of its network. This 816 transition creates a lot of new cases into which it must factor how 817 to maintain the IPv4 service. Providing an IPv6-only service is not 818 much different from the dual IPv4/IPv6 service described in stage 3 819 except for the need to phase out the IPv4 service. The delivery of 820 IPv4 services over an IPv6 network and the phase out of IPv4 are left 821 for a subsequent document. 823 8. Example Networks 825 In this section, a number of different network examples are 826 presented. These are only example networks and will not necessarily 827 match any existing networks. Nevertheless, the examples are intended 828 be useful even in cases in which they do not match specific target 829 networks. The purpose of the example networks is to exemplify 830 the applicability of the transition mechanisms described in this 831 document to a number of different situations with different 832 prerequisites. 834 The sample network layout will be the same in all network examples. 835 The network examples should be viewed as specific representations of 836 a generic network with a limited number of network devices. A small 837 number of routers have been used in the network examples. However, 838 because the network examples follow the implementation strategies 839 recommended for the generic network scenario, it should be possible 840 to scale the examples to fit a network with an arbitrary number, e.g. 841 several hundreds or thousands, of routers. 843 The routers in the sample network layout are interconnected with each 844 other as well as with another ISP. The connection to another ISP can 845 be either direct or through an exchange point. In addition to these 846 connections, a number of customer connection networks are also 847 connected to the routers. Customer connection networks can be, for 848 example, xDSL or cable network equipment. 850 ISP1 | ISP2 851 +------+ | +------+ 852 | | | | | 853 |Router|--|--|Router| 854 | | | | | 855 +------+ | +------+ 856 / \ +----------------------- 857 / \ 858 / \ 859 +------+ +------+ 860 | | | | 861 |Router|----|Router| 862 | | | | 863 +------+ +------+\ 864 | | \ | Exchange point 865 +------+ +------+ \ +------+ | +------+ 866 | | | | \_| | | | |-- 867 |Router|----|Router|----\|Router|--|--|Switch|-- 868 | | | | | | | | |-- 869 +------+ /+------+ +------+ | +------+ 870 | / | | 871 +-------+/ +-------+ | 872 | | | | 873 |Access1| |Access2| 874 | | | | 875 +-------+ +-------+ 876 ||||| ||||| ISP Network 877 ----|-----------|---------------------- 878 | | Customer Networks 879 +--------+ +--------+ 880 | | | | 881 |Customer| |Customer| 882 | | | | 883 +--------+ +--------+ 884 Figure 3: ISP Sample Network Layout. 886 8.1 Example 1 888 Example 1 presents a network built according to the sample network 889 layout with a native IPv4 backbone. The backbone is running IS-IS and 890 IBGP as routing protocols for internal and external routes, 891 respectively. MBGP is used to exchange routes over the connections to 892 ISP2 and the exchange point. Multicast using PIM-SM routing is 893 present. QoS using DiffServ is deployed. 895 Access 1 is xDSL connected to the backbone through an access 896 router. The xDSL equipment, except for the access router, is 897 considered to be layer 2 only, e.g., Ethernet or ATM. IPv4 addresses 898 are dynamically assigned to the customer using DHCP. No routing 899 information is exchanged with the customer. Access control and 900 traceability are preformed in the access router. Customers are 901 separated into VLANs or separate ATM PVCs up to the access router. 903 Access 2 is Fiber to the building or home (FTTB/H) connected directly 904 to the backbone router. This is considered to be layer-3-aware, 905 because it is using layer 3 switches and it performs access control 906 and traceability through its layer 3 awareness by using DHCP 907 snooping. IPv4 addresses are dynamically assigned to the customers 908 using DHCP. No routing information is exchanged with the customer. 910 The actual IPv6 deployment might start by enabling IPv6 on a couple 911 of backbone routers, configuring tunnels between them (if not 912 adjacent), and connecting to a few peers or upstream providers 913 (either through tunnels or at an internet exchange). 915 After a trial period, the rest of the backbone is upgraded to dual- 916 stack, and IS-IS without multi-topology extensions (the upgrade order 917 is considered with care) is used as an IPv6 and IPv4 IGP. When 918 upgrading, it's important to note that until IPv6 customers are 919 connected behind a backbone router, the convexity requirement is not 920 critical: the routers just will not be able to be reached using IPv6. 921 That is, a software supporting IPv6 could be installed even though 922 the routers would not be used for (customer) IPv6 traffic yet. That 923 way, IPv6 could be enabled in the backbone on a need-to-enable basis 924 when needed. 926 Separate IPv6 BGP sessions are built, similar to IPv4. Multicast 927 (through SSM and Embedded-RP) and DiffServ are offered at a later 928 phase of the network, e.g., after a year of stable IPv6 unicast 929 operations. 931 Customers (with some exceptions) are not connected using a tunnel 932 broker, because offering native service faster is considered more 933 important -- and then there will not be unnecessary parallel 934 infrastructures to tear down later on. However, a 6to4 relay is 935 provided in the meantime for optimized 6to4 connectivity. xDSL 936 equipment, operating as bridges at Layer 2 only, do not require 937 changes in CPE: IPv6 connectivity can be offered to the customers by 938 upgrading the PE router to IPv6. In the initial phase, only Router 939 Advertisements are used; DHCPv6 Prefix Delegation can be added as the 940 next step if no other mechanisms are available. 942 The FTTB/H access has to be upgraded to support access control and 943 traceability in the switches, probably by using DHCP snooping or a 944 similar IPv6 capability, but it also has to be compatible with prefix 945 delegation and not just address assignment. This could, however, lead 946 to the need to use DHCPv6 for address assignment. 948 8.2 Example 2 950 In example 2 the backbone is running IPv4 with MPLS and is using OSPF 951 and IBGP are for internal and external routes respectively. The 952 connection to ISP2 and the exchange point run BGP to exchange routes. 953 Multicast and QoS are not deployed. 955 Access 1 is a fixed line, e.g., fiber, connected directly to the 956 backbone. Routing information is in some cases exchanged with CPE at 957 the customer's site; otherwise static routing is used. Access 1 can 958 also be connected to BGP/MPLS-VPN running in the backbone. 960 Access 2 is xDSL connected directly to the backbone router. The xDSL 961 is layer 2 only, and access control and traceability are achieved 962 through PPPoE/PPPoA. PPP also provides address assignment. No routing 963 information is exchanged with the customer. 965 IPv6 deployment might start with an upgrade of a couple of PE routers 966 to support [BGPTUNNEL], because this will allow large-scale IPv6 967 support without hardware or software upgrades in the core. In a later 968 phase, perhaps years later, IPv6 traffic would run natively in the 969 whole network. In that case IS-IS or OSPF could be used for the 970 internal routing, and a separate IPv6 BGP session would be run. 972 For the fixed-line customers the CPE has to be upgraded and prefix 973 delegation using DHCPv6 or static assignment would be used. An IPv6 974 MBGP session would be used when routing information has to be 975 exchanged. In the xDSL case the same conditions for IP-tunneling as 976 in Example 1 apply. In addition to IP-tunneling an additional PPP 977 session can be used to offer IPv6 access to a limited number of 978 customers. Later, when clients and servers have been updated, the 979 IPv6 PPP session can be replaced with a combined PPP session for both 980 IPv4 and IPv6. PPP has to be used for address and prefix assignment. 982 8.3 Example 3 984 A transit provider offers IP connectivity to other providers, but 985 not to end users or enterprises. IS-IS and IBGP are used internally 986 and BGP externally. Its accesses connect Tier-2 provider cores. No 987 multicast or QoS is used. 989 Even though the RIR policies on getting IPv6 prefixes require the 990 assignment of at least 200 /48 prefixes to the customers, this type 991 of transit provider obtains an allocation nonetheless, as the number 992 of customers their customers serve is significant. The whole backbone 993 can be upgraded to dual-stack in a reasonably rapid pace after 994 trialing it with a couple of routers. IPv6 routing is performed 995 using the same IS-IS and separate IPv6 BGP sessions. 997 The ISP provides IPv6 transit to its customers for free, as a 998 competitive advantage. It also provides, at the first phase only, a 999 configured tunnel service with BGP peering to the significant sites 1000 and customers (those with an AS number) which are the customers of 1001 its customers whenever its own customer networks are not offering 1002 IPv6. This is done both to introduce them to IPv6 and to create a 1003 beneficial side-effect: a bit of extra revenue is generated from its 1004 direct customers as the total amount of transited traffic grows. 1006 9. Security Considerations 1008 This document analyses scenarios and identifies some transition 1009 mechanisms that could be used for the scenarios. It does not 1010 introduce any new security issues. Security considerations of each 1011 mechanism are described in the respective documents. 1013 However, a few generic observations are in order. 1015 o introducing IPv6 adds new classes of security threats or 1016 requires adopting new protocols or operational models 1017 than with IPv6; typically these are generic issues, and 1018 to be further discussed in other documents, for example, 1019 [V6SEC]. 1021 o the more complex the transition mechanisms employed become, 1022 the more difficult it will be to manage or analyze their 1023 impact on security; consequently, simple mechanisms are to 1024 be preferred. 1026 o this document has identified a number of requirements for 1027 analysis or further work which should be explicitly considered 1028 when adopting IPv6: how to perform access control over 1029 shared media or shared ISP customer connection media, 1030 how to manage the configuration management security on such 1031 environments (e.g., DHCPv6 authentication keying), and 1032 how to manage customer traceability if stateless address 1033 autoconfiguration is used. 1035 10. Acknowledgements 1037 This draft has greatly benefited from inputs by Marc Blanchet, Jordi 1038 Palet, Francois Le Faucheur and Cleve Mickles. Special thanks to 1039 Richard Graveman for proofreading the document. 1041 11. Informative References 1043 [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of 1044 RP in IPv6 Multicast Address" - 1045 Work in progress 1047 [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- 1048 ISIS: Multi Topology (MT) Routing in IS-IS" 1049 Work in progress 1051 [RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, 1052 "Multiprotocol Extensions for BGP-4" 1053 RFC 2858 1055 [RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol 1056 Extensions for IPv6 Inter-Domain Routing" 1057 RFC 2545 1059 [BCP38UPD] F. Baker, P. Savola "Ingress Filtering for 1060 Multihomed Networks" 1061 Work in progress 1063 [RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- 1064 Multihoming Architectures" 1065 RFC 3582 1067 [RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at 1068 Site Exit Routers" 1069 RFC 3178 1071 [BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost, 1072 F. Le Faucheur "Connecting IPv6 Islands across IPv4 1073 Clouds with BGP" 1074 draft-ooms-v6ops-bgp-tunnel-00.txt 1076 [DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi 1077 "A Model of IPv6/IPv4 Dual Stack Internet Access 1078 Service" 1079 Work in progress 1081 [UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations 1082 for IPv6 Tunneling Solutions in Small End Sites" 1083 Work in progress 1085 [UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol, 1086 "Evaluation of Transition Mechanisms for Unmanaged 1087 Networks" 1088 Work in progress 1090 [PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding 1091 Protocol 41 in NAT Boxes" 1092 Work in progress 1094 [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security 1095 Considerations" 1096 Work in progress 1098 Authors' Addresses 1100 Mikael Lind 1101 TeliaSonera 1102 Vitsandsgatan 9B 1103 SE-12386 Farsta, Sweden 1104 Email: mikael.lind@teliasonera.com 1106 Vladimir Ksinant 1107 6WIND S.A. 1108 Immeuble Central Gare - Bat.C 1109 1, place Charles de Gaulle 1110 78180, Montigny-Le-Bretonneux - France 1111 Phone: +33 1 39 30 92 36 1112 Email: vladimir.ksinant@6wind.com 1114 Soohong Daniel Park 1115 Mobile Platform Laboratory, SAMSUNG Electronics. 1116 416, Maetan-3dong, Paldal-Gu, 1117 Suwon, Gyeonggi-do, Korea 1118 Email: soohong.park@samsung.com 1120 Alain Baudot 1121 France Telecom R&D 1122 42, rue des coutures 1123 14066 Caen - FRANCE 1124 Email: alain.baudot@rd.francetelecom.com 1126 Pekka Savola 1127 CSC/FUNET 1128 Espoo, Finland 1129 EMail: psavola@funet.fi 1131 Intellectual Property Statement 1133 The IETF takes no position regarding the validity or scope of any 1134 intellectual property or other rights that might be claimed to 1135 pertain to the implementation or use of the technology described in 1136 this document or the extent to which any license under such rights 1137 might or might not be available; neither does it represent that it 1138 has made any effort to identify any such rights. Information on the 1139 IETF's procedures with respect to rights in standards-track and 1140 standards-related documentation can be found in BCP-11. Copies of 1141 claims of rights made available for publication and any assurances 1142 of licenses to be made available, or the result of an attempt made 1143 to obtain a general license or permission for the use of such 1144 proprietary rights by implementers or users of this specification 1145 can be obtained from the IETF Secretariat. 1147 The IETF invites any interested party to bring to its attention any 1148 copyrights, patents or patent applications, or other proprietary 1149 rights which may cover technology that may be required to practice 1150 this standard. Please address the information to the IETF Executive 1151 Director. 1153 Full Copyright Statement 1155 Copyright (C) The Internet Society (2003). All Rights Reserved. 1157 This document and translations of it may be copied and furnished to 1158 others, and derivative works that comment on or otherwise explain it 1159 or assist in its implementation may be prepared, copied, published 1160 and distributed, in whole or in part, without restriction of any 1161 kind, provided that the above copyright notice and this paragraph 1162 are included on all such copies and derivative works. However, this 1163 document itself may not be modified in any way, such as by removing 1164 the copyright notice or references to the Internet Society or other 1165 Internet organizations, except as needed for the purpose of 1166 developing Internet standards in which case the procedures for 1167 copyrights defined in the Internet Standards process must be 1168 followed, or as required to translate it into languages other than 1169 English. 1171 The limited permissions granted above are perpetual and will not be 1172 revoked by the Internet Society or its successors or assignees. 1174 This document and the information contained herein is provided on an 1175 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1176 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1177 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1178 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1179 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.