idnits 2.17.1 draft-lind-v6ops-isp-scenarios-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.) ** There are 111 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (October 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Lind (ed.) 3 J. Mulahusic 4 Expires : April 2004 TeliaSonera 5 D. Park 6 Samsung Electronics 7 A. Baudot 8 France Telecom 9 P. Savola 10 CSC/Funet 11 October 2003 13 Scenarios for Introducing IPv6 into ISP Networks 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 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 describes different scenarios for the introduction of 39 IPv6 into an existing IPv4 ISP network without disrupting the IPv4 40 service. During the IPv6 introduction can the network go through 41 different stages. The first one is the initial stage of an IPv4-only 42 infrastructure, and the final one corresponds to a whole dual-stack 43 infrastructure enabling full coexistence of IPv4 and IPv6 traffic 44 and services. In between, typical intermediate stages involving 45 coexistence mechanism are identified. The scenarios depicted in this 46 document are describing the way to move along these different 47 possible stages. 49 Table of Contents 51 1. Introduction.................................................2 52 2. Scope of the document........................................3 53 3. Terminology used.............................................3 54 4. Brief description of a generic ISP network...................4 55 5. Scenarios....................................................6 56 5.1 Assumptions.............................................6 57 5.2 Customer requirements and ISP offerings.................7 58 5.3 Stage 1 Scenarios: Launch...............................8 59 5.4 Stage 2a Scenarios: Core................................9 60 5.5 Stage 2b Scenarios: Access..............................9 61 5.6 Stage 2a and 2b combination scenarios..................11 62 5.7 Stage 3 scenarios: Complete............................12 63 5.8 Impact on the "IT infrastructure"......................13 64 6. Transition Scenarios........................................14 65 7. Future Stages...............................................15 66 8. Example networks............................................15 67 8.1 Example 1..............................................16 68 8.2 Example 2..............................................17 69 8.3 Example 3..............................................17 70 8.4 Example 4..............................................18 71 9. Security Considerations.....................................18 73 1. Introduction 75 An ISP offering an IPv4 service will find that there are different 76 ways to add IPv6 to this service. During the introduction of IPv6 77 the network will go through different stages of IPv6 maturity. In 78 addition to this there has to be a transition between these stages 79 to make them feasible to implement. The main goal of this document 80 is to provide possible scenarios to the ISP when introducing IPv6 81 connectivity in the existing ISP IPv4 legacy network. 83 In this document different transition scenarios and situations 84 during the introduction of IPv6 are covered in a broader perspective 85 and deals only with a generic view of how an ISP network is built. 86 This should be seen as the starting point for further documentation 87 in a companion document of how the introduction of IPv6 can be done 88 in an ISP network. 90 2. Scope of the document 92 The scope of the document is to describe different cases for the 93 introduction of an IPv6 service in a generic IPv4 ISP network. This 94 means that the document will be limited to services that include 95 both IPv6 and IPv4 and will not cover issues surrounding an IPv6 96 only service. Therefore, the ISP network should be able to carry 97 IPv4 and IPv6 traffic without any distinction related to the version 98 of the protocol. 100 The different building blocks that will be considered are the 101 customer network, the access networks, the core network and exchange 102 points. 104 The network can be at a different stage relating to, either how far 105 it has adopted IPv6, or to how likely it may be upgraded to IPv6. We 106 will consider these stages, as well as the transition scenarios 107 between the different stages. 109 It is outside the scope of this document to describe different types 110 of access or network technologies. It is also outside of the scope 111 to propose different solutions. Solutions will be covered in a 112 separate document. 114 3. Terminology used 116 This section defines and clarifies the terminology used in this 117 document: 119 "CPE" : Customer Premise Equipment 121 "PE" : Provider Edge equipment 123 "Access" : This is the part of the network which is used by a 124 customer when connecting to an ISP network. It 125 includes the CPEs, the last hop links and the parts 126 of the PE interfacing to the last hop links. 128 "Core" : This is the rest of the ISP network infrastructure. 130 It includes the parts of the PE interfacing to the 131 core backbone, the core routers of the ISP and the 132 border routers used in order to exchange routing 133 information with other ISPs (or other administrative 134 entities). 136 "IT infrastructure" : 137 This is the part of the ISP network which hosts the 138 services required for the correct operation of the 139 ISP network. It usually includes DNS servers,Radius 140 servers, monitoring and configuration 141 applications... 143 "Dual network": A network which supports natively both IPv4 and 144 IPv6. 146 4. Brief description of a generic ISP network 148 A generic ISP network topology can be divided into two main parts; 149 the core network and the access networks connecting the customers. 151 The core network or the backbone is the part of the network that 152 interconnects the different access networks and provides transport 153 to the rest of the Internet via exchange points or other means. The 154 core network can be built on different technologies but in this 155 document the only interest is whether it is capable of carrying IPv6 156 traffic natively or not. Since there is no clear definition of core, 157 it is defined in this document as being all routers that are a part 158 of the same routed domain in the transport network. This means that 159 all routers up to the PE router are a part of the core. The PE 160 router can also be partially part of the core if it exchanges 161 routing information and transports traffic to and from the core. 163 The access networks provide connectivity to enterprise and private 164 customers. Other ISPs might as well be customers and connected to 165 the ISP's access network. As with the core the absence or presence 166 of native IPv6 capability is the only thing of real interest in the 167 access network technology. 169 It is noticeable that, in some cases (e.g. European legacy 170 operators), a given access network may have to be shared between 171 different ISPs. According to the type of the access network used 172 (e.g. involving only layer 2 devices, or involving non-IP 173 technology), this constraint result into architectural 174 considerations that may be relevant in the analysis document. 176 "IT infrastructure" building blocks refer to the basic main 177 functions needed for a regular backbone operation. This building 178 block is dealing with: network management, customers' authentication 179 and accounting, address assignment and naming. It represents the 180 minimum functions needed to provide a customer service, referring to 181 both network infrastructure operation, and administrative management 182 of customers. 184 It doesn't matter if these customer networks have a single node or a 185 large routed network. What is of interest is if routing information 186 is exchanged or not since it will affect the ISP's network. The 187 existence of customer placed equipment will also affect how a 188 service can be delivered. In addition to the ISP's actual network 189 components there are a lot of support and backend systems that have 190 to be considered. 192 ------------ --------- 193 | IT | | | 194 |infrastruct.|--| CORE | 195 | | | |\ 196 ------------ --------- \ 197 . / | \ \ 198 . / | \ \_Peering( Direct & IX ) 199 . / | \ 200 . / | \ 201 . / | \ 202 ------- / ------- \ ------- 203 | | / | | \ | | 204 |Access1|--/ |Access2| \--|Access3| 205 | | | | | | 206 ------- ------- ------- 207 | | | ISP Network 208 ------------------------------------------------------- 209 | | | Customer Networks 210 +--------+ +--------+ +--------+ 211 | | | | | | 212 |Customer| |Customer| |Customer| 213 | | | | | | 214 +--------+ +--------+ +--------+ 215 Figure 1: ISP network topology 217 5. Scenarios 219 The scenarios section describes different stages an ISP might 220 consider when introducing IPv6 connectivity in the existing IPv4 221 network and the different scenarios that might occur in the 222 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 5.1 Assumptions 242 The stages are derived from the generic description of an ISP 243 network in section 3. A combination of different building blocks 244 that constitute an ISP environment will lead to a number of 245 scenarios, which an ISP can choose from. The scenarios of most 246 relevance to this document are considered to be the ones that in the 247 most efficient and feasible way maximize the ability for an ISP to 248 offer IPv6 to its customers. 250 The most predominant case today is considered to be an operator with 251 a core and access IPv4 network delivering IPv4 service to a customer 252 that is running IPv4 as well. At some point in the future, it is 253 expected that the customer will want to have an IPv6 service, in 254 addition to the already existing IPv4 service. This IPv6 service may 255 be offered by the same ISP, or by a different one. Anyway the 256 challenge for the ISP is to deliver the requested IPv6 service over 257 the existing infrastructure and at the same time keep the IPv4 258 service intact. 260 5.2 Customer requirements and ISP offerings 262 Looking at the scenarios from the end customer's perspective there 263 might be a demand for three different services; the customer might 264 demand IPv4 service, IPv6 service or both services. This can lead 265 to two scenarios depending on the stage the ISP's network is in. 267 If an ISP only offers IPv4 or IPv6 service and a customer wants to 268 connect a device or network that only supports one service and if 269 that service is not offered, it will lead to a dead-end. If the 270 customer or ISP instead connects a dual stack device it is possible 271 to circumvent the lack of the missing service in the access network 272 by using some kind of coexistence mechanism. This scenario will 273 only be considered in the perspective of the ISP offering a 274 mechanism to bridge the access and reach the IPv6 core. 276 In the case where the customer connects a single stack device to a 277 corresponding single stack access network or when the customer 278 connects a single stack device to a dual stack access network is 279 covered by the all over dual stack case. Therefore, neither of these 280 cases need further be explored separately in this document but can 281 be seen as a part of a full dual stack case. 283 After eliminating a number of cases explained above, there are four 284 stages that are most probable and where an ISP will find its network 285 in. Which stage a network is in; depends on whether or not some 286 part of the network previously has been upgraded to support IPv6 or 287 if it is easier to enable IPv6 in one part or another. For 288 instance, routers in the core might have IPv6 support or might be 289 easily upgradeable, while the hardware in the access might have to 290 be completely replaced in order to handle IPv6 traffic. 292 Note that in every stage except Stage 1, the ISP can offer both IPv4 293 and IPv6 services to the customer. 295 The four most probable stages are: 297 o Stage 1 Launch 298 o Stage 2a Core 299 o Stage 2b Access 300 o Stage 3 Complete 302 Generally the ISP is able to upgrade current IPv4 network to 303 IPv4/IPv6 dual network via Stage 2b but the IPv6 service can also be 304 implemented at a small cost with simple tunnel mechanisms on the 305 existing system. When designing a new network Stage 3 might be the 306 first and last step since there is no legacy concerns. Absence of 307 IPv6 capability in the network equipment can still be a limiting 308 factor nevertheless. 310 5.3 Stage 1 Scenarios: Launch 312 The first stage is an IPv4 only ISP with an IPv4 customer. This is 313 the most common case today and has to be the starting point for the 314 introduction of IPv6. From this stage, an ISP can move (transition) 315 to any other stage with the goal to offer IPv6 to its customer. 317 The scenario and the immediate first step is to get a prefix 318 allocation (typically a /32) from the appropriate RIR according to 319 allocation process. For the IPv6 migration scenarios described in 320 this document, an ISP has to be able to exchange IPv6 traffic, e.g. 321 by connecting to an exchange, through a direct peering/transit or a 322 tunnel, prior to introducing customers in Stage2 and Stage 3. 324 Customer Access Core Exchange 325 +------+ +------+ +------+ +------+ 326 | | | | | | | IPv4 | 327 | IPv4 |---| IPv4 |---| IPv4 |---| + | 328 | | | | | | | IPv6 | 329 +------+ +------+ +------+ +------+ 330 <--------------IPv4--------------> 332 Figure 2. IPv4 network 334 5.4 Stage 2a Scenarios: Core 336 Stage 2a is an ISP with access networks that are IPv4 only and a 337 core that is IPv4 and IPv6. In particular, the ISP considers it 338 possible to make the core IPv6 capable either through software or 339 hardware upgrades. In this stage the customer should have support 340 for both IPv4 and IPv6 and use a tunneling mechanism to be able to 341 run the IPv6 service. To offer the IPv6 service, the ISP also has to 342 exchange IPv6 traffic with other ISPs e.g. by connecting to an IPv6 343 exchange point. In particular, An ISP has to provide IPv6 344 connectivity through its IPv4 access networks. 346 An ISP can consider two kinds of scenarios such as automatic tunnels 347 (e.g. provided by the 6to4 mechanism) and configured tunnels to 348 bring IPv6 connectivity on top of an IPv4 only service. Both 349 methods have advantages and limitations which are out of scope in 350 this document and will be covered in the analysis document. The 351 existence of NATs and firewalls in the path is also to be 352 considered. 354 Customer Access Core Exchange 355 +------+ +------+ +------+ +------+ 356 | | | | | | | IPv4 | 357 | Dual |---| IPv4 |---| Dual |---| + | 358 | | | | | | | IPv6 | 359 +------+ +------+ +------+ +------+ 360 <---------IPv4--------> 362 +=====================+ 363 IPv6 <---IPv6---> 364 +=====================+ 365 Tunnel via access network 367 Figure 3. Upgraded core 369 5.5 Stage 2b Scenarios: Access 371 Stage 2b is an ISP with a core network that is IPv4 and an access 372 network that is IPv4 and IPv6. Since the service to the customer is 373 native IPv6 there is no requirement for the customer to support both 374 IPv4 and IPv6. This is the biggest difference in comparison to the 375 previous stage. The need to exchange IPv6 traffic or similar still 376 exists but might be more complicated than in the previous case since 377 the core isn't IPv6 enabled. After completing stage 2b the original 378 IPv4 core still is unchanged. This doesn't imply that there is no 379 IPv6 core just that the IPv6 core is an overlay to or partially 380 separated from the IPv4 core. 382 Like in section 5.4 tunnels is a possible scenario and can be used 383 for IPv6 connectivity over the IPv4 network parts. Other forms of 384 transport over for example an MPLS enabled core are also possible 385 scenarios. 387 Generally, the ISP will continue providing IPv4 connectivity; in 388 many cases private addresses and NATs will continue to be used. 389 Access networks should make use of a mechanism to delegate a global 390 IPv6 address prefix from the ISP to the customer. 392 Customer Access Core Exchange 393 +------+ +------+ +------+ +------+ 394 | | | | | | | IPv4 | 395 | Dual |---| Dual |---| IPv4 |---| + | 396 | | | | | | | IPv6 | 397 +------+ +------+ +------+ +------+ 398 <---------IPv4--------> 400 +=====================+ 401 <---IPv6---> IPv6 402 +=====================+ 403 Tunnel via core network 405 Figure 4. Upgraded access 407 5.6 Stage 2a and 2b combination scenarios 409 Some ISPs may use different access technologies of varying IPv6 410 maturity. This may results in a combination of the former stages. 412 The case depicted in the figure 5 below, has no impact on stage 2a 413 since it results in interconnection a dual access network to a dual 414 core network. 416 Customer A Access 1 417 +------+ +------+ 418 | | | | 419 | Dual |---| Dual |---+ 420 | | | | | 421 +------+ +------+ | 422 | 423 Customer B Access 2 \ Core Exchange 424 +------+ +------+ +-+----+ +------+ 425 | | | | | | | IPv4 | 426 | Dual |---| IPv4 |---| Dual |---| + | 427 | | | | | | | IPv6 | 428 +------+ +------+ +------+ +------+ 429 <---------IPv4--------> 431 +=====================+ 432 IPv6 <---IPv6---> 433 +=====================+ 434 Tunnel via access network 436 Figure 5. Upgraded core with multiple access 438 The case depicted in the figure 6 below, results in tunnel chaining, 439 in order to keep independent access and core upgrade that may 440 happened according to totally different timeframe. 442 <--IPv4--> | <------IPv4-------> 444 +=========+ +==================+ 445 IPv6 IPv6 446 +=========+ +==================+ 447 Tunnel via Tunnel via 448 access network Core network 450 Customer Access 451 +------+ +------+ 452 | | | | 453 | Dual |---| IPv4 |---+ 454 | | | | | 455 +------+ +------+ | 456 \ 457 Customer Access | Core Exchange 458 +------+ +------+ +-+----+ +------+ 459 | | | | | | | IPv4 | 460 | Dual |---| Dual |---| IPv4 |---| + | 461 | | | | | | | IPv6 | 462 +------+ +------+ +------+ +------+ 463 <---------IPv4--------> 465 +=====================+ 466 <---IPv6---> IPv6 467 +=====================+ 468 Tunnel via access network 470 Figure 6. Upgraded access with upgrade core 472 5.7 Stage 3 scenarios: Complete 474 Stage 3 can be said to be the final step in introducing IPv6, at 475 least in the scope of this document. This is an all over IPv6 476 service with native support for IPv6 and IPv4 in both core and 477 access networks. This stage is identical to the previous stage in 478 the customer's perspective since the access network hasn't changed. 479 The requirement for exchanging IPv6 traffic is identical to stage 2. 481 Customer Access Core Exchange 482 +------+ +------+ +------+ +------+ 483 | | | | | | | IPv4 | 484 | Dual |---| Dual |---| Dual |---| + | 485 | | | | | | | IPv6 | 486 +------+ +------+ +------+ +------+ 487 <--------------IPv4--------------> 488 <--------------IPv6--------------> 490 Figure 7. Completely upgraded network 492 5.8 Impact on the "IT infrastructure" 494 The different stages above are dealing with fundamental issues such 495 as IPv6 connectivity and IPv6 traffic forwarding. 497 Some other background tasks must be realized in parallel to complete 498 the new IPv6 service. The main tasks identified are: 499 - Customer authentication and accounting 500 - Address assignment 501 - Network management 502 - Naming service 504 Customer authentication and accounting and address assignment are 505 relevant to the access network, and address assignment may have an 506 impact on the core network. 508 Network management is relevant to both access and core networks. 510 Naming service intends to address minimum DNS facilities an ISP may 511 have to provide. 513 From a general point of view these functions may be realized based 514 on an IPv4 transport layer, an IPv6 transport layer, or both. 516 A service, such as a web server, advertised by an IPv6 address must 517 be reachable from any IPv6 node. 519 6. Transition Scenarios 521 Given the different stages it is clear that the ISP has to be able 522 to transition from one stage to another. The initial stage, in this 523 document, is the IPv4 only service and network. The end stage is 524 the dual IPv4/IPv6 service and network. As mentioned in the scope, 525 this document does not cover the IPv6 only service and network and 526 its implications on IPv4 customers. This has nothing to do with the 527 usability of an IPv6 only service. 529 The transition starts out with the IPv4 ISP and then moves to one of 530 three choices. These choices are the different transition 531 scenarios. One way would be to upgrade the core first which leads to 532 stage 2a. Another way to go could be to upgrade the access network 533 which leads to stage 2b. The final possibility is to introduce IPv6 534 in the whole network at once which would lead to stage 3. 536 The choice is dependent on many different issues. For example it 537 might not be possible to upgrade the core or the access network 538 without large investments in new equipment which could lead to any 539 of the two first choices. In another case it might be easier to 540 take the direct step to a complete IPv6/IPv4 network due to routing 541 protocol issues or similar. 543 If a partially upgraded network (stage 2a or 2b) was chosen as the 544 first step, a second step remains before the network is all over 545 native IPv6/IPv4. This is the transition to an all over dual stack 546 network. This step is perhaps not necessary for stage 2b with an 547 already native IPv6 service to the customer but might still occur 548 when the timing is right. For stage 2a it is more obvious that a 549 transition to a dual stack network is necessary since it has to be 550 done to offer a native IPv6 service. 552 As most of the ISPs keep evolving continuously their core IPv4 553 networks (new firmware versions in the routers, new routers), they 554 will be able to get them IPv6 ready, without additional investment, 555 except the staff training. It may be a slower transition path, but 556 useful since it allows an IPv6 introduction without any actual 557 customer demand. This will probably be better than making everything 558 at the last minute with a higher investment. 560 7. Future Stages 562 After a while the ISP might want to transition to a service that is 563 IPv6 only, at least in certain parts of the network. This 564 transition creates a lot of new cases in which to factor in how to 565 maintain the IPv4 service. Providing an IPv6 only service is not 566 much different than the dual IPv4/IPv6 service described in stage 3 567 except from the need to phase out the IPv4 service. The delivery of 568 IPv4 services over an IPv6 network and the phase out is left for a 569 future document. 571 8. Example networks 573 In this section, a number of different network examples are 574 presented. They are only example networks and will not necessary 575 match to any existing networks. Nevertheless, the examples will 576 hopefully be useful even in the cases when they do not match the 577 target networks. The purpose of the example networks is to exemplify 578 the applicability of the transition mechanisms described in this 579 document on a number of different example networks with different 580 prerequisites. 582 The example network layout will be the same in all network examples. 583 The networks examples are to be seen as a specific representation of 584 the generic network with a limited number of network devices. An 585 arbitrary number (in this case 7) of routers have been selected to 586 represent the network examples. However, since the network examples 587 follow the implementation strategies recommended for the generic 588 network scenario, it should be possible to scale the example to fit 589 a network with an arbitrary number, e.g. several hundreds or 590 thousands, of routers. 592 The routers in the example are interconnected with each other as 593 well as with another ISP. The connection to another ISP can either 594 be a direct connection or through an exchange point. In addition to 595 these connections, there are also a number of access networks 596 connected to the routers. Access networks are normally connected to 597 the core via access routers, but can in some cases be directly 598 connected to the core routers. As described earlier in the generic 599 network scenarios, the access networks are used to connect the 600 customers. Access networks can, for example, be xDSL or cable 601 network equipment. 603 | 604 ISP1 | ISP2 605 +------+ | +------+ 606 | | | | | 607 |Router|--|--|Router| 608 | | | | | 609 +------+ | +------+ 610 / \ +----------------------- 611 / \ 612 / \ 613 +------+ +------+ 614 | | | | 615 |Router|----|Router| 616 | | | | 617 +------+ +------+\ 618 | | \ | Exchange point 619 +------+ +------+ \ +------+ | +------+ 620 | | | | \_| | | | |-- 621 |Router|----|Router|----\|Router|--|--|Switch|-- 622 | | | | | | | | |-- 623 +------+ /+------+ +------+ | +------+ 624 | / | | 625 +-------+/ +-------+ | 626 | | | | 627 |Access1| |Access2| 628 | | | | 629 +-------+ +-------+ 630 ||||| ||||| ISP Network 631 ----|-----------|---------------------- 632 | | Customer Networks 633 +--------+ +--------+ 634 | | | | 635 |Customer| |Customer| 636 | | | | 637 +--------+ +--------+ 639 Figure 2: ISP network example 641 8.1 Example 1 643 In example 1 a network built according to the example topology is 644 present with a native IPv4 core, the routers. The core is running 645 IS-IS and IBGP as routing protocol for internal and external routes 646 respectively. In the connection to ISP2 and the exchange point MBGP 647 is used to exchange routes. Multicast is present and is using PIM-SM 648 routing. QoS is present and is using DiffServ. 650 Access 1 is xDSL, connected to the core through an access router. 651 The xDSL equipment, except for the access router, is considered to 652 be layer 2 only, e.g. Ethernet or ATM. IPv4 addresses are 653 dynamically assigned to the customer using DHCP. No routing 654 information is exchanged with the customer. Access control and 655 traceability is done in the access router. Customers are separated 656 in VLANs or separate ATM PVCs up to the access router. 658 Access 2 is Fiber to the building/home connected directly to the 659 core router. The FTTB/H is considered to be layer 3 aware and 660 performs access control and traceability through its layer 3 661 awareness. IPv4 addresses are dynamically assigned to the customers 662 using DHCP. No routing information is exchanged with the customer. 664 8.2 Example 2 666 In example 2 the core is running IPv4 with MPLS. Routing protocols 667 used are OSPF and IBGP for internal and external routes. In the 668 connection to ISP2 and the exchange point BGP is used to exchange 669 routes. Multicast and QoS are not present. 671 Access 1 is a fixed line access, e.g. fiber, connected directly to 672 the core. CPE is present at the customer and routing information is 673 in some cases exchanged otherwise static routing is used. Access 1 674 can also be connected to BGP/MPLS-VPN running in the core. 676 Access 2 is xDSL connected directly to the core router. The xDSL is 677 layer 3 aware. Addresses are dynamically assigned using DHCP. Access 678 control is achieved on the physical layer and traceability is 679 achieved using DHCP snooping. No routing information is exchanged 680 with the customer. 682 8.3 Example 3 684 A transit provider offers IP connectivity to other providers, but 685 not to end users or enterprises. IS-IS and IBGP is used internally 686 and BGP externally. Its accesses connect Tier-2 provider cores. No 687 multicast or QoS is used. 689 8.4 Example 4 691 Yet another example, if needed. To be done. 693 9. Security Considerations 695 This document describes different scenarios for the introduction of 696 IPv6 in an IPv4 ISP network. Solutions are described in other 697 documents hence this document has no security considerations. 699 Intellectual Property Statement 701 The IETF takes no position regarding the validity or scope of any 702 intellectual property or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; neither does it represent that it 706 has made any effort to identify any such rights. Information on the 707 IETF's procedures with respect to rights in standards-track and 708 standards-related documentation can be found in BCP-11. Copies of 709 claims of rights made available for publication and any assurances 710 of licenses to be made available, or the result of an attempt made 711 to obtain a general license or permission for the use of such 712 proprietary rights by implementers or users of this specification 713 can be obtained from the IETF Secretariat. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights which may cover technology that may be required to practice 718 this standard. Please address the information to the IETF Executive 719 Director. 721 Full Copyright Statement 723 Copyright (C) The Internet Society (2003). All Rights Reserved. 725 This document and translations of it may be copied and furnished to 726 others, and derivative works that comment on or otherwise explain it 727 or assist in its implementation may be prepared, copied, published 728 and distributed, in whole or in part, without restriction of any 729 kind, provided that the above copyright notice and this paragraph 730 are included on all such copies and derivative works. However, this 731 document itself may not be modified in any way, such as by removing 732 the copyright notice or references to the Internet Society or other 733 Internet organizations, except as needed for the purpose of 734 developing Internet standards in which case the procedures for 735 copyrights defined in the Internet Standards process must be 736 followed, or as required to translate it into languages other than 737 English. 739 The limited permissions granted above are perpetual and will not be 740 revoked by the Internet Society or its successors or assignees. 742 This document and the information contained herein is provided on an 743 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 744 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 745 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 746 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 747 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Acknowledgements 751 This draft is a joint effort of the ISP design team. The team 752 consists of Jordi Palet, Suresh Satapati, Myung-Ki Shin, Vladimir 753 Ksinant, Cleve Mickles, Marc Blanchet, Soohong Daniel Park, Alain 754 Baudot and Mikael Lind 756 This draft has also greatly benefited from input by Margaret 757 Wasserman. 759 Authors' Addresses 761 Mikael Lind 762 TeliaSonera 763 Vitsandsgatan 9B 764 SE-12386 Farsta, Sweden 765 Email: mikael.lind@teliasonera.com 767 Jasminko Mulahusic 768 TeliaSonera 769 Vitsandsgatan 9B 770 SE-12386 Farsta, Sweden 771 Email: jasminko.mulahusic@teliasonera.com 773 Soohong Daniel Park 774 Mobile Platform Laboratory, SAMSUNG Electronics. 775 416, Maetan-3dong, Paldal-Gu, 776 Suwon, Gyeonggi-do, Korea 777 Email: soohong.park@samsung.com 779 Alain Baudot 780 France Telecom R&D 781 42, rue des coutures 782 14066 Caen - FRANCE 783 Email: alain.baudot@rd.francetelecom.com 785 Pekka Savola 786 CSC/FUNET 787 Espoo, Finland 788 EMail: psavola@funet.fi