idnits 2.17.1 draft-ietf-v6ops-isp-scenarios-analysis-02.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 == Line 1138 has weird spacing: '...ulevard de Va...' -- 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 (April 2004) is 7316 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) -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) Summary: 2 errors (**), 0 flaws (~~), 3 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 Thales Communications 6 S. Park 7 Samsung Electronics 8 A. Baudot 9 France Telecom 10 P. Savola 11 CSC/Funet 13 Expires: October 2004 April 2004 15 Scenarios and Analysis for Introducing IPv6 into ISP Networks 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document first describes different scenarios for the 40 introduction of IPv6 into an ISP's existing IPv4 network without 41 disrupting the IPv4 service. Then, this document analyses these 42 scenarios and evaluates the relevance of the already defined 43 transition mechanisms in this context. Known challenges are also 44 identified. 46 Table of Contents 48 1. Introduction................................................2 49 1.1 Goal and Scope of the Document...........................2 50 2. Brief Description of a Generic ISP Network..................3 51 3. Transition Scenarios........................................4 52 3.1 Identification of Stages and Scenarios...................4 53 3.2 Stages...................................................5 54 3.2.1 Stage 1 Scenarios: Launch..............................5 55 3.2.2 Stage 2a Scenarios: Backbone...........................6 56 3.2.3 Stage 2b Scenarios: Customer Connection................6 57 3.2.4 Stage 3 Scenarios: Complete............................6 58 3.2.5 Stages 2a and 3: Combination Scenarios.................7 59 3.3 Transition Scenarios.....................................7 60 3.4 Actions Needed When Deploying IPv6 in an ISP's network...7 61 4. Backbone Transition Actions.................................8 62 4.1 Steps in the Transition of Backbone Networks.............8 63 4.1.1 MPLS Backbone..........................................9 64 4.2 Configuration of Backbone Equipment.....................10 65 4.3 Routing.................................................10 66 4.3.1 IGP...................................................10 67 4.3.2 EGP...................................................12 68 4.3.3 Transport of Routing Protocols........................12 69 4.4 Multicast...............................................12 70 5. Customer Connection Transition Actions.....................12 71 5.1 Steps in the Transition of Customer Connection Networks.12 72 5.1.1 Small end sites.......................................14 73 5.1.2 Large end sites.......................................14 74 5.2 User Authentication/Access Control Requirements.........15 75 5.3 Configuration of Customer Equipment.....................15 76 5.4 Requirements for Traceability...........................16 77 5.5 Ingress Filtering in the Customer Connection Network....16 78 5.6 Multihoming.............................................16 79 5.7 Quality of Service......................................17 80 6. Network and Service Operation Actions......................17 81 7. Future Stages..............................................18 82 8. Example Networks...........................................18 83 8.1 Example 1...............................................19 84 8.2 Example 2...............................................21 85 8.3 Example 3...............................................21 86 9. Security Considerations....................................22 87 10. Acknowledgements...........................................22 88 11. Informative References.....................................22 90 1. Introduction 92 1.1 Goal and Scope of the Document 93 When an ISP deploys IPv6, its goal is to provide IPv6 connectivity 94 and global address space to its customers. The new IPv6 service must 95 be added to an already existing IPv4 service, and the introduction of 96 IPv6 must not interrupt this IPv4 service. 98 An ISP offering IPv4 service will find different ways to add IPv6 to 99 this service. This document discusses a small set of scenarios for 100 the introduction of IPv6 into an ISP's IPv4 network. It evaluates the 101 relevance of the existing transition mechanisms in the context of 102 these deployment scenarios, and points out the lack of essential 103 functionality in these methods to the ISP's operation of an IPv6 104 service. 106 The present document is focused on services that include both IPv6 107 and IPv4 and does not cover issues surrounding IPv6-only service. 108 It is also outside the scope of this document to describe different 109 types of access or network technologies. 111 2. Brief Description of a Generic ISP Network 113 A generic network topology for an ISP can be divided into two main 114 parts: the backbone network and customer connection networks. It 115 includes, in addition to these, some other building blocks such as 116 network and service operations. The additional building blocks used 117 in this document are defined as follows: 119 "CPE" : Customer Premises Equipment 121 "PE" : Provider Edge equipment 123 "Network and service operation" 124 : This is the part of the ISP's network that hosts the 125 services required for the correct operation of the 126 ISP's network. These services usually include 127 management, supervision, accounting, billing, and 128 customer management applications. 130 "Customer connection" 131 : This is the part of the network used by a customer 132 when connecting to an ISP's network. It includes the 133 CPE, the last hop link and the parts of the PE 134 interfacing to the last hop link. 136 "Backbone" : This is the rest of the ISP's network infrastructure. 137 It includes the parts of the PE interfacing to the 138 core, the core routers of the ISP, and the border 139 routers used to exchange routing information with 140 other ISPs (or other administrative entities). 142 "Dual-stack network": 143 A network that supports natively both IPv4 and 144 IPv6. 146 It is noted that, in some cases (e.g., incumbent national or 147 regional operators), a given customer connection network may have 148 to be shared between or among different ISPs. According to the type 149 of customer connection network used (e.g., one involving only layer 2 150 devices or one involving non-IP technology), this constraint may 151 result in architectural considerations relevant to this document. 153 The basic components in the ISP's network are depicted in Figure 1. 155 ------------ ---------- 156 | Network and| | | 157 | Service |--| Backbone | 158 | Operation | | |\ 159 ------------ ---------- \ 160 . / | \ \ 161 . / | \ \_Peering( Direct and IX ) 162 . / | \ 163 . / | \ 164 . / | \ 165 ---------- / ---------- \ ---------- 166 | Customer | / | Customer | \ | Customer | 167 |Connection|--/ |Connection| \--|Connection| 168 | 1 | | 2 | | 3 | 169 ---------- ---------- ---------- 170 | | | ISP's Network 171 ------------------------------------------------------- 172 | | | Customers' Networks 173 +--------+ +--------+ +--------+ 174 | | | | | | 175 |Customer| |Customer| |Customer| 176 | | | | | | 177 +--------+ +--------+ +--------+ 178 Figure 1: ISP Network Topology. 180 3. Transition Scenarios 182 3.1 Identification of Stages and Scenarios 184 This section describes different stages an ISP might consider when 185 introducing IPv6 connectivity into its existing IPv4 network and the 186 different scenarios that might occur in the respective stages. 188 The stages here are snapshots of the ISP's network with respect to 189 IPv6 maturity. Because the ISP's network is continually evolving, a 190 stage is a measure of how far along the ISP has come in terms of 191 implementing the functionality necessary to offer IPv6 to its 192 customers. 194 It is possible for a transition to occur freely between different 195 stages. Although a network segment can only be in one stage at a 196 time, the ISP's network as a whole can be in different stages. 197 Different transition paths can be followed from the first to the 198 final stage. The transition between two stages does not have to be 199 instantaneous; it can occur gradually. 201 Each stage has different IPv6 properties. An ISP can, therefore, 202 based on its requirements, decide which set of stages it will follow 203 and in what order to transform its network. 205 This document is not aimed at covering small ISPs, hosting providers, 206 or data centers; only the scenarios applicable to ISPs eligible for 207 at least a /32 IPv6 prefix allocation from a RIR are covered. 209 3.2 Stages 211 The stages are derived from the generic description of an ISP's 212 network in Section 2. Combinations of different building blocks 213 that constitute an ISP's environment lead to a number of scenarios 214 from which the ISP can choose. The scenarios most relevant to this 215 document are those that maximize ISP's ability to offer IPv6 to its 216 customers in the most efficient and feasible way. The assumption in 217 all stages is that the ISP's goal is to offer both IPv4 and IPv6 to 218 the customer. 220 The four most probable stages are: 222 o Stage 1 Launch 223 o Stage 2a Backbone 224 o Stage 2b Customer connection 225 o Stage 3 Complete 227 Generally, an ISP is able to upgrade a current IPv4 network to an 228 IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can 229 also be implemented at a small cost by adding simple tunnel 230 mechanisms to the existing configuration. When designing a new 231 network, Stage 3 might be the first and last step, because there are 232 no legacy concerns. Nevertheless, the absence of IPv6 capability in 233 the network equipment can still be a limiting factor. 235 Note that in every stage except Stage 1, the ISP can offer both IPv4 236 and IPv6 services to its customers. 238 3.2.1 Stage 1 Scenarios: Launch 239 The first stage is an IPv4-only ISP with an IPv4 customer. This is 240 the most common case today and the natural starting point for the 241 introduction of IPv6. From this stage, the ISP can move (undergo a 242 transition) from Stage 1 to any other stage with the goal of offering 243 IPv6 to its customer. 245 The immediate first step consists of obtaining a prefix allocation 246 (typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, 247 ARIN, LACNIC, RIPE, ...) according to allocation procedures. 249 3.2.2 Stage 2a Scenarios: Backbone 251 Stage 2a deal with an ISP with IPv4-only customer connection networks 252 and a backbone that supports both IPv4 and IPv6. In particular, the 253 ISP has the possibility of making the backbone IPv6-capable through 254 either software upgrades, hardware upgrades, or a combination of 255 both. 257 Since the customer connections have not yet been upgraded, a 258 tunneling mechanism has to be used to provide IPv6 connectivity 259 through the IPv4 customer connection networks. The customer can 260 terminate the tunnel at the CPE (if it has IPv6 support) or at some 261 set of devices internal to its network. That is, either the CPE or a 262 device inside the network could provide global IPv6 connectivity to 263 the rest of the devices in the customer's network. 265 3.2.3 Stage 2b Scenarios: Customer Connection 267 Stage 2b consists of an ISP with an IPv4 backbone network and a 268 customer connection network that supports both IPv4 and IPv6. Because 269 the service to the customer is native IPv6, the customer is not 270 required to support both IPv4 and IPv6. This is the biggest 271 difference in comparison to the previous stage. The need to exchange 272 IPv6 traffic still exists but might be more complicated than in the 273 previous case, because the backbone is not IPv6-enabled. After 274 completing Stage 2b, the original IPv4 backbone is unchanged. This 275 means that the IPv6 traffic is transported either by tunneling over 276 the existing IPv4 backbone, or in an IPv6 overlay network more or 277 less separated from the IPv4 backbone. 279 Normally the ISP will continue to provide IPv4 connectivity using 280 private (NATted by the ISP) or public IPv4 address; in many cases, 281 the customer also has a NAT of his/her own, and if so, this likely 282 continues to be used for IPv4 connectivity. 284 3.2.4 Stage 3 Scenarios: Complete 286 Stage 3 can be said to be the final step in introducing IPv6, at 287 least within the scope of this document. This stage consists of 288 ubiquitous IPv6 service with native support for IPv6 and IPv4 in both 289 backbone and customer connection networks. It is identical to the 290 previous stage from the customer's perspective, because the customer 291 connection network has not changed. The requirement for exchanging 292 IPv6 traffic is identical to Stage 2. 294 3.2.5 Stages 2a and 3: Combination Scenarios 296 Some ISPs may use different access technologies of varying IPv6 297 maturity. This may result in a combination of the Stages 2a and 3: 298 some customer connections do not support IPv6, but others do; in both 299 cases the backbone is dual-stack. 301 This scenario is equivalent to Stage 2a, but it requires support for 302 native IPv6 customer connections on some access technologies. 304 3.3 Transition Scenarios 306 Given the different stages, it is clear that an ISP has to be able 307 to make a transition from one stage to another. The initial stage in 308 this document is IPv4-only service and network. The end stage is dual 309 IPv4/IPv6 service and network. 311 The transition starts with an IPv4 ISP and then moves in one of 312 three directions. This choice corresponds to the different 313 transition scenarios. Stage 2a consists of upgrading the backbone 314 first. Stage 2b consists of upgrading the customer connection 315 network. Finally, Stage 3 consists of introducing IPv6 in both the 316 backbone and customer connections as needed. 318 Because most ISP backbone IPv4 networks continually evolve (firmware 319 replacements in routers, new routers, etc.), they can be made ready 320 for IPv6 without additional investment (except staff training). This 321 may be a slower but still useful transition path, because it allows 322 for the introduction of IPv6 without any actual customer demand. This 323 process may be superior to doing everything at the last minute, which 324 may entail a higher investment. However, it is important to consider 325 (and to request from vendors) IPv6 features in all new equipment from 326 the outset. Otherwise, the time and effort required to remove non- 327 IPv6-capable hardware from the network may be significant. 329 3.4 Actions Needed When Deploying IPv6 in an ISP's network 331 Examination of the transitions described above reveals that it 332 is possible to split the work required for each transition into a 333 small set of actions. Each action is largely independent of the 334 others, and some actions may be common to multiple transitions. 336 Analysis of the possible transitions leads to a small list of 337 actions: 339 * Actions required for backbone transition: 341 - Connect dual-stack customer connection networks to other 342 IPv6 networks through an IPv4 backbone. 344 - Transform an IPv4 backbone into a dual-stack one. This 345 action can be performed directly or through intermediate 346 steps. 348 * Actions required for customer connection transition: 350 - Connect IPv6 customers to an IPv6 backbone through an IPv4 351 network. 353 - Transform an IPv4 customer connection network into a dual- 354 stack one. 356 * Actions required for network and service operation transition: 358 - Configure IPv6 functions into network components. 360 - Upgrade regular network management and monitoring 361 applications to take IPv6 into account. 363 - Extend customer management (e.g., RADIUS) mechanisms 364 to be able to supply IPv6 prefixes and other information 365 to customers. 367 - Enhance accounting, billing, etc. to work with IPv6 368 as needed. (Note: if dual-stack service is offered, this 369 may not be necessary.) 371 - Implement security for network and service operation. 373 Sections 4, 5, and 6 contain detailed descriptions of each action. 375 4. Backbone Transition Actions 377 4.1 Steps in the Transition of Backbone Networks 379 In terms of physical equipment, backbone networks consist mainly of 380 high-speed core and edge routers. Border routers provide peering 381 with other providers. Filtering, routing policy, and policing 382 functions are generally managed on border routers. 384 In the beginning, an ISP has an IPv4-only backbone. In the end, the 385 backbone is completely dual-stack. In between, intermediate steps may 386 be identified: 388 Tunnels Tunnels 389 IPv4-only ----> or ---> or + DS -----> Full DS 390 dedicated IPv6 dedicated IPv6 routers 391 links links 392 Figure 2: Transition Path. 394 The first step involves tunnels or dedicated links but leaves 395 existing routers unchanged. Only a small set of routers then have 396 IPv6 capabilities. The use of configured tunnels is adequate during 397 this step. 399 In the second step, some dual-stack routers are added, progressively, 400 to this network. 402 The final step is reached when all or almost all routers are dual- 403 stack. 405 For many reasons (technical, financial, etc.), the ISP may progress 406 step by step or jump directly to the final one. One important 407 criterion in planning this evolution is the number of IPv6 customers 408 the ISP expects during its initial deployments. If few customers 409 connect to the original IPv6 infrastructure, then the ISP is likely 410 to remain in the initial steps for a long time. 412 In short, each intermediate step is possible, but none is mandatory. 414 4.1.1 MPLS Backbone 416 If MPLS is already deployed in the backbone, it may be desirable 417 to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 418 Label Switched Path (LSP) requires signaling through the MPLS 419 network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might 420 require upgrade/change in the MPLS core network. 422 An alternative approach is to use BGP for signaling or to perform, 423 for example IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some of 424 the multiple possibilities are preferable to others depending on the 425 specific environment under consideration; the approaches seem to be: 427 1) Require that MPLS networks deploy native IPv6 routing and 428 forwarding support. 430 2) Require that MPLS networks support native routing and setting 431 up of IPv6 LSPs, used for IPv6 connectivity. 433 3) Use only configured tunneling over IPv4 LSPs. 435 4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation 436 for IPv6 connectivity. 438 1) and 2) are clearly the best target approaches. However, 1) may 439 not be possible if the ISP is not willing to add IPv6 support in 440 the network, or if the installed equipment is not capable of high 441 performance native IPv6 forwarding. 2) may not be possible if the 442 ISP is not willing or able to add IPv6 LSP set-up support in the MPLS 443 control plane. 445 Approach 4) can be used as an interim mechanism where other options 446 are unfeasible or undesirable for the reasons discussed above. 448 Approach 3) is roughly equivalent to 4) except that it does not 449 require additional mechanisms but may lack scalability in the larger 450 networks especially if IPv6 is widely deployed. 452 4.2 Configuration of Backbone Equipment 454 In the backbone, the number of devices is small and IPv6 455 configuration mainly deals with routing protocol parameters, 456 interface addresses, loop-back addresses, ACLs, etc. 458 These IPv6 parameters need to be configured manually. 460 4.3 Routing 462 ISPs need routing protocols to advertise reachability and to 463 find the shortest working paths, both internally and externally. 465 Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is 466 not usually used in service provider networks. BGP is the only IPv4 467 EGP. Static routes also are used in both cases. 469 Note that it is possible to configure a given network so that it 470 results in having an IPv6 topology different from its IPv4 topology. 471 For example, some links or interfaces may be dedicated to IPv4-only 472 or IPv6-only traffic, or some routers may be dual-stack whereas 473 others may be IPv4 or IPv6 only. In this case, routing protocols must 474 be able to understand and cope with multiple topologies. 476 4.3.1 IGP 478 Once the IPv6 topology has been determined, the choice of IPv6 IGP 479 must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not 480 appropriate in most contexts and is therefore not discussed here. The 481 IGP typically includes the routers' point-to-point and loop-back 482 addresses. 484 The most important decision is whether one wishes to have separate 485 routing protocol processes for IPv4 and IPv6. Separating them 486 requires more memory and CPU for route calculations, e.g., when the 487 links flap. On the other hand, separation provides a certain measure 488 of assurance that if problems arise with IPv6 routing, they will not 489 affect the IPv4 routing protocol at all. In the initial phases, if 490 it is uncertain whether joint IPv4-IPv6 networking is working as 491 intended, running separate processes may be desirable and easier to 492 manage. 494 Thus the possible combinations are: 496 - with separate processes: 497 o OSPFv2 for IPv4, IS-IS for IPv6 (only) 498 o OSPFv2 for IPv4, OSPFv3 for IPv6, or 499 o IS-IS for IPv4, OSPFv3 for IPv6 501 - with the same process: 502 o IS-IS for both IPv4 and IPv6 504 Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 505 topologies must be "convex," unless the multiple-topology IS-IS 506 extensions [MTISIS] have been implemented (note that using IS-IS for 507 only IPv4 or only IPv6 requires no convexity). In simpler networks or 508 with careful planning of IS-IS link costs, it is possible to keep 509 even incongruent IPv4/IPv6 topologies "convex." The convexity problem 510 is explained in more detail with an example in Appendix A. 512 When deploying full dual-stack in the short-term, using single- 513 topology IS-IS is recommended. This may be applicable particularly 514 for some larger ISPs. In other scenarios, determining between one or 515 two separate processes often depends on the perceived risk to the 516 IPv4 routing infrastructure, i.e., whether one wishes to keep them 517 separate for the time being. If that is not a factor, using a single 518 process is usually preferable due to operational reasons: not having 519 to manage two protocols and topologies. 521 The IGP is typically only used to carry loopback and point-to-point 522 addresses and doesn't include customer prefixes or external routes. 523 Internal BGP (iBGP), as described in the next section, is most often 524 deployed in all routers (PE and core) to distribute routing 525 information about customer prefixes and external routes. 527 Some of the simplest devices, e.g., CPE routers, may not implement 528 routing protocols other than RIPng. In some cases, therefore, it may 529 be necessary to run RIPng in addition to one of the above IGPs, at 530 least in a limited fashion, and then, by some mechanism, to 531 redistribute routing information between the routing protocols. 533 4.3.2 EGP 535 BGP is used for both internal and external BGP sessions. 537 BGP with multiprotocol extensions [RFC 2858] can be used for IPv6 538 [RFC 2545]. These extensions enable the exchange of IPv6 routing 539 information as well as the establishment of BGP sessions using TCP 540 over IPv6. 541 It is possible to use a single BGP session to advertise both IPv4 542 and IPv6 prefixes between two peers. However, the most common 543 practice today is to use separate BGP sessions. 545 4.3.3 Transport of Routing Protocols 547 IPv4 routing information should be carried by IPv4 transport and 548 similarly IPv6 routing information by IPv6 for several reasons: 550 * IPv6 connectivity may work when IPv4 connectivity is down 551 (or vice-versa). 552 * The best route for IPv4 is not always the best one for IPv6. 553 * The IPv4 and IPv6 logical topologies may be different, 554 because the administrator may want to assign different metrics 555 to a physical link for load balancing or because tunnels may be 556 in use. 558 4.4 Multicast 560 Currently, IPv6 multicast is not a major concern for most ISPs. 561 However, some of them are considering deploying it. Multicast is 562 achieved using the PIM-SM and PIM-SSM protocols. These also work with 563 IPv6. 565 Information about multicast sources is exchanged using MSDP in IPv4, 566 but MSDP is intentionally not defined for IPv6. Instead, one should 567 use only PIM-SSM or an alternative mechanism for conveying the 568 information [EMBEDRP]. 570 5. Customer Connection Transition Actions 572 5.1 Steps in the Transition of Customer Connection Networks 574 Customer connection networks are generally composed of a small set of 575 PEs connected to a large set of CPEs, and may be based on different 576 technologies depending on the customer type or size, as well as the 577 required bandwidth or even quality of service. Basically, public 578 customers or small/unmanaged networks connection networks usually 579 rely on a different technologies (e.g. dial-up or DSL) than the ones 580 used for large customers typically running managed networks. 581 Transitioning these infrastructures to IPv6 can be accomplished in 582 several steps, but some ISPs, depending on their perception of the 583 risks, may avoid some of the steps. 585 Connecting IPv6 customers to an IPv6 backbone through an IPv4 network 586 can be considered as a first careful step taken by an ISP to provide 587 IPv6 services to its IPv4 customers. In addition, some ISPs may also 588 choose to provide IPv6 service independently from the regular IPv4 589 service. 591 In any case, IPv6 service can be provided by using tunneling 592 techniques. The tunnel may terminate at the CPE corresponding to the 593 IPv4 service or in some other part of the customer's infrastructure 594 (for instance, on IPv6-specific CPE or even on a host). 596 Several tunneling techniques have already been defined: configured 597 tunnels with tunnel broker, 6to4, Teredo, etc. Some of them are based 598 on a specific addressing plan independent of the ISP's allocated 599 prefix(es), while some others use a part of the ISP's prefix. In most 600 cases using ISP's address space is preferable. 602 A key factor is the presence or absence of NATs between the two 603 tunnel end-points. In most cases, 6to4 and ISATAP are incompatible 604 with NATs, and UDP encapsulation for configured tunnels has not been 605 specified. 607 Dynamic and non-permanent IPv4 address allocation is another factor a 608 tunneling technique may have to deal with. In this case the tunneling 609 techniques may be more difficult to deploy at the ISP's end, 610 especially if a protocol including authentication (like PPP for IPv6) 611 is not used. This may need to be considered in more detail. 613 However, NAT traversal can be avoided if the NAT supports forwarding 614 protocol-41 [PROTO41] and is configured to do so. 616 Firewalls in the path can also break tunnels of these types. The 617 administrator of the firewall needs to create a hole for the tunnel. 618 This is usually manageable, as long as the firewall is controlled by 619 either the customer or the ISP, which is almost always the case. 621 When the CPE is performing NAT or firewall functions, terminating the 622 tunnels directly at the CPE typically simplifies the scenario 623 considerably, avoiding the NAT and firewall traversal. If such an 624 approach is adopted, the CPE has to support the tunneling mechanism 625 used, or be upgraded to do so. 627 5.1.1 Small end sites 629 Tunneling considerations for small end sites are discussed in 630 [UNMANEVA]. These identify solutions relevant to the first category 631 of unmanaged networks. The tunneling requirements applicable in these 632 scenarios are described in [TUNREQS] 634 The connectivity mechanisms can be categorized as "managed" or 635 "opportunistic." The former consist of native service or a 636 configured tunnel (with or without a tunnel broker); the latter 637 include 6to4 and, e.g., Teredo -- they provide "short-cuts" between 638 nodes using the same mechanisms and are available without contracts 639 with the ISP. 641 The ISP may offer opportunistic services, mainly a 6to4 relay, 642 especially as a test when no actual service is offered yet. At the 643 later phases, ISPs might also deploy 6to4 relays and Teredo servers 644 (or similar) to optimize their customers' connectivity to 6to4 and 645 Teredo nodes. 647 It is to be noticed that opportunistic services are typically based 648 on techniques that don't use IPv6 addresses out of the ISP's 649 allocated prefix(es), and that the services have very limited 650 functions to control the origin and the number of customers connected 651 to a given relay. 653 Most interesting are the managed services. When dual-stack is not an 654 option, a form of tunneling must be used. When configured tunneling 655 is not an option (e.g., due to dynamic IPv4 addressing), some form of 656 automation has to be used. Basically, the options are either to 657 deploy an L2TP architecture (whereby the customers would run L2TP 658 clients and PPP over it to initiate IPv6 sessions) or to deploy a 659 tunnel configuration service. The prime candidates for tunnel 660 configuration are STEP [STEP] and TSP [TSP], which both also work in 661 the presence of NATs. Neither is analyzed further in this document. 663 5.1.2 Large end sites 665 Large end sites are usually running managed network. 667 Dual-stack access service is often a realistic possibility since the 668 customer network is managed (although CPE upgrades may be necessary). 670 Configured tunnels, as-is, are a good solution when a NAT is not in 671 the way and the IPv4 end-point addresses are static. In this 672 scenario, NAT traversal is not typically required. If fine-grained 673 access control is needed, an authentication protocol needs to be 674 implemented. 676 Tunnel brokering solutions, to help facilitate the set-up of a bi- 677 directional tunnel, have been proposed. Such mechanisms are typically 678 unnecessary for large end-sites, as simple configured tunneling or 679 native access can be used instead. However, if such mechanisms would 680 already be deployed, large sites starting to deploy IPv6 might be 681 able to benefit from them in any case. 683 Teredo is not applicable in this scenario as it can only provide IPv6 684 connectivity to a single host, not the whole site. 6to4 is not 685 recommended due to its reliance on the relays and provider- 686 independent address space, which make it impossible to guarantee the 687 required service quality and manageability large sites typically 688 want. 690 5.2 User Authentication/Access Control Requirements 692 User authentication can be used to control who can use the IPv6 693 connectivity service in the first place or who can access specific 694 IPv6 services (e.g., NNTP servers meant for customers only, etc.). 695 The former is described at more length below. The latter can be 696 achieved by ensuring that for all the service-specific IPv4 access 697 lists, there are also equivalent IPv6 access lists. 699 IPv6-specific user authentication is not always required. An example 700 is a customer of the IPv4 service automatically having access to the 701 IPv6 service. In this case the IPv4 access control also provides 702 access to the IPv6 services. 704 When a provider does not wish to give its IPv4 customers 705 automatic access to IPv6 services, specific IPv6 access control must 706 be performed in parallel with the IPv4 access control. This does not 707 imply that different user authentication must be performed for IPv6, 708 but merely that the authentication process may lead to different 709 results for IPv4 and IPv6 access. 711 Access control traffic may use IPv4 or IPv6 transport. For instance, 712 Radius traffic related to IPv6 service can be transported over 713 IPv4. 715 5.3 Configuration of Customer Equipment 717 The customer connection networks are composed of PE and CPE(s). 718 Usually, each PE connects multiple CPE components to the backbone 719 network infrastructure. This number may reach tens of thousands or 720 more. The configuration of CPE is a difficult task for the ISP, and 721 it is even more difficult when it must be done remotely. In this 722 context, the use of auto-configuration mechanisms is beneficial, even 723 if manual configuration is still an option. 725 The parameters that usually need to be provided to customers 726 automatically are: 728 - The network prefix delegated by the ISP, 729 - The address of the Domain Name System server (DNS), 730 - Possibly other parameters, e.g., the address of an NTP 731 server. 733 When user identification is required on the ISP's network, DHCPv6 may 734 be used to provide configurations; otherwise, either DHCPv6 or a 735 stateless mechanism can be used. This is discussed in more detail in 736 [DUAL ACCESS]. 738 Note that when the customer connection network is shared between the 739 users or the ISPs, and not just a point-to-point link, authenticating 740 the configuration of the parameters (especially prefix delegation) 741 requires further study. 743 As long as IPv4 service is available alongside IPv6 it is not 744 required to auto configure IPv6 parameters in the CPE, except the 745 prefix, because the IPv4 settings may be used. 747 5.4 Requirements for Traceability 749 Most ISPs have some kind of mechanism to trace the origin of traffic 750 in their networks. This also has to be available for IPv6 traffic, 751 meaning that a specific IPv6 address or prefix has to be tied to a 752 certain customer, or that records of which customer had which 753 address or prefix must be maintained. This also applies to the 754 customers with tunneled connectivity. 756 This can be done, for example, by mapping a DHCP response to a 757 physical connection and storing the result in a database. It can also 758 be done by assigning a static address or prefix to the customer. A 759 tunnel server could also provide this mapping. 761 5.5 Ingress Filtering in the Customer Connection Network 763 Ingress filtering must be deployed towards the customers, everywhere, 764 to ensure traceability, to prevent DoS attacks using spoofed 765 addresses, to prevent illegitimate access to the management 766 infrastructure, etc. 768 Ingress filtering can be done, for example, by using access lists or 769 Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are 770 described in [BCP38UPD]. 772 5.6 Multihoming 773 Customers may desire multihoming or multi-connecting for a number of 774 reasons [RFC3582]. 776 Mechanisms for multihoming to more than one ISP are still under 777 discussion. One working model could be to deploy at least one prefix 778 per ISP, and to choose the prefix from the ISP to which traffic is 779 sent. In addition, tunnels may be used for robustness [RFC3178]. 780 Currently, there are no provider-independent addresses for end-sites. 781 Such addresses would enable IPv4-style multihoming, with associated 782 disadvantages. 784 Multi-connecting more than once to just one ISP is a simple 785 practice, and this can be done, e.g., by using BGP with public or 786 private AS numbers and a prefix assigned to the customer. 788 5.7 Quality of Service 790 In most networks, quality of service in one form or another is 791 important. 793 Naturally, the introduction of IPv6 should not impair existing 794 Service Level Agreements (SLAs) or similar quality assurances. 796 During the deployment of the IPv6 service, the service could be best- 797 effort or similar even if the IPv4 service has a SLA. In the end both 798 IP version should be treated equally. 800 IntServ and DiffServ are equally applicable to IPv6 as to IPv4 and 801 work in a similar fashion independent of IP version. Of these, 802 typically only DiffServ has been implemented. 804 6. Network and Service Operation Actions 806 The network and service operation actions fall into different 807 categories as listed below: 809 - IPv6 network device configuration: for initial configuration 810 and updates 811 - IPv6 network management 812 - IPv6 monitoring 813 - IPv6 customer management 814 - IPv6 network and service operation security 816 Some of these items will require an IPv6 native transport layer to 817 be available, whereas others will not. 819 As a first step, network device configuration and regular network 820 management operations can be performed over an IPv4 transport, 821 because IPv6 MIBs are also available over IPv4 transport. 823 Nevertheless, some monitoring functions require the availability of 824 IPv6 transport. This is the case, for instance, when ICMPv6 messages 825 are used by the monitoring applications. 827 The current inability on many platforms to retrieve separate IPv4 and 828 IPv6 traffic statistics from dual-stack interfaces for management 829 purposes by using SNMP is an issue. 831 As a second step, IPv6 transport can be provided for any of these 832 network and service operation facilities. 834 7. Future Stages 836 At some point, an ISP might want to transition to a service that is 837 IPv6 only, at least in certain parts of its network. Such a 838 transition creates many new cases into which continued maintenance of 839 the IPv4 service must be factored. Providing an IPv6-only service is 840 not much different from the dual IPv4/IPv6 service described in stage 841 3 except for the need to phase out the IPv4 service. The delivery of 842 IPv4 services over an IPv6 network and the phase out of IPv4 are left 843 for a subsequent document. 845 8. Example Networks 847 In this section, a number of different example networks are 848 presented. These will not necessarily match any existing networks but 849 are intended to be useful even in cases in which they do not 850 correspond to specific target networks. The purpose of these examples 851 is to exemplify the applicability of the transition mechanisms 852 described in this document to a number of different situations with 853 different prerequisites. 855 The sample network layout will be the same in all network examples. 856 These should be viewed as specific representations of a generic 857 network with a limited number of network devices. A small number of 858 routers have been used in the examples. However, because the network 859 examples follow the implementation strategies recommended for the 860 generic network scenario, it should be possible to scale the examples 861 to fit a network with an arbitrary number, e.g. several hundreds or 862 thousands, of routers. 864 The routers in the sample network layout are interconnected with each 865 other as well as with another ISP. The connection to another ISP can 866 be either direct or through an exchange point. In addition to these 867 connections, a number of customer connection networks are also 868 connected to the routers. Customer connection networks can be, for 869 example, xDSL or cable network equipment. 871 ISP1 | ISP2 872 +------+ | +------+ 873 | | | | | 874 |Router|--|--|Router| 875 | | | | | 876 +------+ | +------+ 877 / \ +----------------------- 878 / \ 879 / \ 880 +------+ +------+ 881 | | | | 882 |Router|----|Router| 883 | | | | 884 +------+ +------+\ 885 | | \ | Exchange point 886 +------+ +------+ \ +------+ | +------+ 887 | | | | \_| | | | |-- 888 |Router|----|Router|----\|Router|--|--|Switch|-- 889 | | | | | | | | |-- 890 +------+ /+------+ +------+ | +------+ 891 | / | | 892 +-------+/ +-------+ | 893 | | | | 894 |Access1| |Access2| 895 | | | | 896 +-------+ +-------+ 897 ||||| ||||| ISP Network 898 ----|-----------|---------------------- 899 | | Customer Networks 900 +--------+ +--------+ 901 | | | | 902 |Customer| |Customer| 903 | | | | 904 +--------+ +--------+ 905 Figure 3: ISP Sample Network Layout. 907 8.1 Example 1 909 Example 1 presents a network built according to the sample network 910 layout with a native IPv4 backbone. The backbone is running IS-IS and 911 IBGP as routing protocols for internal and external routes, 912 respectively. Multiprotocol BGP is used to exchange routes over the 913 connections to ISP2 and the exchange point. Multicast using PIM-SM 914 routing is present. QoS using DiffServ is deployed. 916 Access 1 is xDSL connected to the backbone through an access router. 917 The xDSL equipment, except for the access router, is considered to be 918 layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically 919 assigned to the customer using DHCP. No routing information is 920 exchanged with the customer. Access control and traceability are 921 performed in the access router. Customers are separated into VLANs or 922 separate ATM PVCs up to the access router. 924 Access 2 is "fiber to the building or home" (FTTB/H) connected 925 directly to the backbone router. This connection is considered to be 926 layer-3-aware, because it is using layer 3 switches and it performs 927 access control and traceability through its layer 3 awareness by 928 using DHCP snooping. IPv4 addresses are dynamically assigned to the 929 customers using DHCP. No routing information is exchanged with the 930 customer. 932 The actual IPv6 deployment might start by enabling IPv6 on a couple 933 of backbone routers, configuring tunnels between them (if not 934 adjacent), and connecting to a few peers or upstream providers 935 (either through tunnels or at an internet exchange). 937 After a trial period, the rest of the backbone is upgraded to dual- 938 stack, and IS-IS without multi-topology extensions (the upgrade order 939 is considered with care) is used as an IPv6 and IPv4 IGP. When 940 upgrading, it's important to note that until IPv6 customers are 941 connected behind a backbone router, the convexity requirement is not 942 critical: the routers will just not be reachable using IPv6. That 943 is, software supporting IPv6 could be installed even though the 944 routers would not be used for (customer) IPv6 traffic yet. That way, 945 IPv6 could be enabled in the backbone on a need-to-enable basis when 946 needed. 948 Separate IPv6 BGP sessions are built, similar to IPv4. Multicast 949 (through SSM and Embedded-RP) and DiffServ are offered at a later 950 phase of the network, e.g., after a year of stable IPv6 unicast 951 operations. 953 Offering native service as quickly as possible is considered most 954 important. However, a 6to4 relay may be provided in the meantime for 955 optimized 6to4 connectivity and it may also be combined with a tunnel 956 broker for extended functionality. xDSL equipment, operating as 957 bridges at Layer 2 only, does not require changes in CPE: IPv6 958 connectivity can be offered to the customers by upgrading the PE 959 router to IPv6. In the initial phase, only Router Advertisements are 960 used; DHCPv6 Prefix Delegation can be added as the next step if no 961 other mechanisms are available. 963 The FTTB/H access has to be upgraded to support access control and 964 traceability in the switches, probably by using DHCP snooping or a 965 similar IPv6 capability, but it also has to be compatible with prefix 966 delegation and not just address assignment. This could, however, lead 967 to the need to use DHCPv6 for address assignment. 969 8.2 Example 2 971 In example 2 the backbone is running IPv4 with MPLS and is using OSPF 972 and IBGP are for internal and external routes respectively. The 973 connections to ISP2 and the exchange point run BGP to exchange 974 routes. Multicast and QoS are not deployed. 976 Access 1 is a fixed line, e.g., fiber, connected directly to the 977 backbone. Routing information is in some cases exchanged with CPE at 978 the customer's site; otherwise static routing is used. Access 1 can 979 also be connected to a BGP/MPLS-VPN running in the backbone. 981 Access 2 is xDSL connected directly to the backbone router. The xDSL 982 is layer 2 only, and access control and traceability are achieved 983 through PPPoE/PPPoA. PPP also provides address assignment. No routing 984 information is exchanged with the customer. 986 IPv6 deployment might start with an upgrade of a couple of PE routers 987 to support [BGPTUNNEL], because this will allow large-scale IPv6 988 support without hardware or software upgrades in the core. In a later 989 phase native IPv6 traffic or IPv6 LSPs would be used in the whole 990 network. In that case IS-IS or OSPF could be used for the internal 991 routing, and a separate IPv6 BGP session would be run. 993 For the fixed-line customers, the CPE has to be upgraded and prefix 994 delegation using DHCPv6 or static assignment would be used. An IPv6 995 MBGP session would be used when routing information has to be 996 exchanged. In the xDSL case the same conditions for IP-tunneling as 997 in Example 1 apply. In addition to IP-tunneling an additional PPP 998 session can be used to offer IPv6 access to a limited number of 999 customers. Later, when clients and servers have been updated, the 1000 IPv6 PPP session can be replaced with a combined PPP session for both 1001 IPv4 and IPv6. PPP has to be used for address and prefix assignment. 1003 8.3 Example 3 1005 A transit provider offers IP connectivity to other providers, but 1006 not to end users or enterprises. IS-IS and IBGP are used internally 1007 and BGP externally. Its accesses connect Tier-2 provider cores. No 1008 multicast or QoS is used. 1010 Even though the RIR policies on getting IPv6 prefixes require the 1011 assignment of at least 200 /48 prefixes to the customers, this type 1012 of transit provider obtains an allocation nonetheless, as the number 1013 of customers their customers serve is significant. The whole backbone 1014 can be upgraded to dual-stack in a reasonably rapid pace after a 1015 trial with a couple of routers. IPv6 routing is performed using the 1016 same IS-IS process and separate IPv6 BGP sessions. 1018 The ISP provides IPv6 transit to its customers for free, as a 1019 competitive advantage. It also provides, at the first phase only, a 1020 configured tunnel service with BGP peering to the significant sites 1021 and customers (those with an AS number) which are the customers of 1022 its customers whenever its own customer networks are not offering 1023 IPv6. This is done both to introduce them to IPv6 and to create a 1024 beneficial side-effect: a bit of extra revenue is generated from its 1025 direct customers as the total amount of transited traffic grows. 1027 9. Security Considerations 1029 This document analyses scenarios and identifies some transition 1030 mechanisms that could be used for the scenarios. It does not 1031 introduce any new security issues. Security considerations of each 1032 mechanism are described in the respective documents. 1034 However, a few generic observations are in order. 1036 o introducing IPv6 adds new classes of security threats or 1037 requires adopting new protocols or operational models 1038 than with IPv4; typically these are generic issues, and 1039 to be further discussed in other documents, for example, 1040 [V6SEC]. 1042 o the more complex the transition mechanisms employed become, 1043 the more difficult it will be to manage or analyze their 1044 impact on security. Consequently, simple mechanisms are to 1045 be preferred. 1047 o this document has identified a number of requirements for 1048 analysis or further work which should be explicitly considered 1049 when adopting IPv6: how to perform access control over 1050 shared media or shared ISP customer connection media, 1051 how to manage the configuration management security on such 1052 environments (e.g., DHCPv6 authentication keying), and 1053 how to manage customer traceability if stateless address 1054 autoconfiguration is used. 1056 10. Acknowledgements 1058 This draft has greatly benefited from inputs by Marc Blanchet, Jordi 1059 Palet, Francois Le Faucheur, Ronald van der Pol and Cleve Mickles. 1060 Special thanks to Richard Graveman and Michael Lambert for 1061 proofreading the document. 1063 11. Informative References 1065 [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of 1066 RP in IPv6 Multicast Address" - 1067 Work in progress 1069 [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- 1070 ISIS: Multi Topology (MT) Routing in IS-IS" 1071 Work in progress 1073 [RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, 1074 "Multiprotocol Extensions for BGP-4" 1075 RFC 2858 1077 [RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol 1078 Extensions for IPv6 Inter-Domain Routing" 1079 RFC 2545 1081 [BCP38UPD] F. Baker, P. Savola "Ingress Filtering for 1082 Multihomed Networks" 1083 Work in progress 1085 [RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- 1086 Multihoming Architectures" 1087 RFC 3582 1089 [RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at 1090 Site Exit Routers" 1091 RFC 3178 1093 [BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost, 1094 F. Le Faucheur "Connecting IPv6 Islands across IPv4 1095 Clouds with BGP" 1096 Work in progress 1098 [DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi 1099 "A Model of IPv6/IPv4 Dual Stack Internet Access 1100 Service" 1101 Work in progress 1103 [STEP] P. Savola, "Simple IPv6-in-IPv4 Tunnel Establishment 1104 Procedure (STEP)" 1105 Work in progress 1107 [TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup 1108 Protocol (TSP)" 1109 Work in progress 1111 [TUNREQS] A. Durand, F. Parent "Requirements for assisted 1112 tunneling" 1113 Work in progress 1115 [UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol, 1116 "Evaluation of Transition Mechanisms for Unmanaged 1117 Networks" 1118 Work in progress 1120 [PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding 1121 Protocol 41 in NAT Boxes" 1122 Work in progress 1124 [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security 1125 Considerations" 1126 Work in progress 1128 Authors' Addresses 1130 Mikael Lind 1131 TeliaSonera 1132 Vitsandsgatan 9B 1133 SE-12386 Farsta, Sweden 1134 Email: mikael.lind@teliasonera.com 1136 Vladimir Ksinant 1137 Thales Communications 1138 160, boulevard de Valmy 1139 92704 Colombes, France 1140 Email: vladimir.ksinant@fr.thalesgroup.com 1142 Soohong Daniel Park 1143 Mobile Platform Laboratory, SAMSUNG Electronics. 1144 416, Maetan-3dong, Paldal-Gu, 1145 Suwon, Gyeonggi-do, Korea 1146 Email: soohong.park@samsung.com 1148 Alain Baudot 1149 France Telecom R&D 1150 42, rue des coutures 1151 14066 Caen - FRANCE 1152 Email: alain.baudot@rd.francetelecom.com 1154 Pekka Savola 1155 CSC/FUNET 1156 Espoo, Finland 1157 EMail: psavola@funet.fi 1159 Intellectual Property Statement 1161 The IETF takes no position regarding the validity or scope of any 1162 intellectual property or other rights that might be claimed to 1163 pertain to the implementation or use of the technology described in 1164 this document or the extent to which any license under such rights 1165 might or might not be available; neither does it represent that it 1166 has made any effort to identify any such rights. Information on the 1167 IETF's procedures with respect to rights in standards-track and 1168 standards-related documentation can be found in BCP-11. Copies of 1169 claims of rights made available for publication and any assurances 1170 of licenses to be made available, or the result of an attempt made 1171 to obtain a general license or permission for the use of such 1172 proprietary rights by implementers or users of this specification 1173 can be obtained from the IETF Secretariat. 1175 The IETF invites any interested party to bring to its attention any 1176 copyrights, patents or patent applications, or other proprietary 1177 rights which may cover technology that may be required to practice 1178 this standard. Please address the information to the IETF Executive 1179 Director. 1181 Full Copyright Statement 1183 Copyright (C) The Internet Society (2003). All Rights Reserved. 1185 This document and translations of it may be copied and furnished to 1186 others, and derivative works that comment on or otherwise explain it 1187 or assist in its implementation may be prepared, copied, published 1188 and distributed, in whole or in part, without restriction of any 1189 kind, provided that the above copyright notice and this paragraph 1190 are included on all such copies and derivative works. However, this 1191 document itself may not be modified in any way, such as by removing 1192 the copyright notice or references to the Internet Society or other 1193 Internet organizations, except as needed for the purpose of 1194 developing Internet standards in which case the procedures for 1195 copyrights defined in the Internet Standards process must be 1196 followed, or as required to translate it into languages other than 1197 English. 1199 The limited permissions granted above are perpetual and will not be 1200 revoked by the Internet Society or its successors or assignees. 1202 This document and the information contained herein is provided on an 1203 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1204 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1205 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1206 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1207 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1209 Appendix A: Convexity Requirements in Single Topology IS-IS 1210 The single-topology IS-IS convexity requirements could be summarized, 1211 from IPv4/6 perspective, as follows: 1213 1) "any IP-independent path from an IPv4 router to any other IPv4 1214 router must only go through routers which are IPv4-capable", and 1216 2) "any IP-independent path from an IPv6 router to any other IPv6 1217 router must only go through routers which are IPv6-capable". 1219 As IS-IS is based upon CLNS, these are not trivially accomplished. 1220 The single-topology IS-IS builds paths which are agnostic of IP 1221 versions. 1223 Consider an example scenario of three IPv4/IPv6-capable routers 1224 and an IPv4-only router: 1226 cost 5 R4 cost 5 1227 ,------- [v4/v6] -----. 1228 / \ 1229 [v4/v6] ------ [ v4 ] -----[v4/v6] 1230 R1 cost 3 R3 cost 3 R2 1232 Here the second requirement would not hold. IPv6 packets from R1 to 1233 R2 (or vice versa) would go through R3, which does not support IPv6, 1234 and the packets would get discarded. By reversing the costs between 1235 R1-R3, R3-R2 and R1-R4,R4-R2 the traffic would work in the normal 1236 case, but if a link fails and the routing changes to go through R3, 1237 the packets would start being discarded again.