idnits 2.17.1 draft-ietf-v6ops-isp-scenarios-analysis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1258. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 623 has weird spacing: '...e based on a...' == Line 1215 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 (June 2004) is 7252 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2858' is mentioned on line 562, but not defined ** Obsolete undefined reference: RFC 2858 (Obsoleted by RFC 4760) == Missing Reference: 'RFC 2545' is mentioned on line 563, but not defined == Missing Reference: 'RADIUS' is mentioned on line 737, but not defined == Missing Reference: 'RFC3704' is mentioned on line 795, but not defined == Unused Reference: 'RFC2858' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC2545' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'BCP3704' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 1156, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 8 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 6 Communications 7 S. Park 8 Samsung Electronics 9 A. Baudot 10 France Telecom 11 P. Savola 12 CSC/Funet 13 Expires: December 2004 June 2004 15 Scenarios and Analysis for Introducing IPv6 into ISP Networks 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 or will be disclosed, and any of which I become aware will be 22 disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than a "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document first describes different scenarios for the 43 introduction of IPv6 into an ISP's existing IPv4 network without 44 disrupting the IPv4 service. Then, the scenarios for introducing IPv6 45 are analyzed and the relevance of already defined transition 46 mechanisms are evaluated. Known challenges are also identified. 48 Table of Contents 50 1. Introduction................................................2 51 1.1 Goal and Scope of the Document...........................2 52 2. Brief Description of a Generic ISP Network..................3 53 3. Transition Scenarios........................................4 54 3.1 Identification of Stages and Scenarios...................4 55 3.2 Stages...................................................5 56 3.2.1 Stage 1 Scenarios: Launch..............................5 57 3.2.2 Stage 2a Scenarios: Backbone...........................6 58 3.2.3 Stage 2b Scenarios: Customer Connection................6 59 3.2.4 Stage 3 Scenarios: Complete............................7 60 3.2.5 Stages 2a and 3: Combination Scenarios.................7 61 3.3 Transition Scenarios.....................................7 62 3.4 Actions Needed When Deploying IPv6 in an ISP's network...8 63 4. Backbone Transition Actions.................................9 64 4.1 Steps in the Transition of Backbone Networks.............9 65 4.1.1 MPLS Backbone.........................................10 66 4.2 Configuration of Backbone Equipment.....................10 67 4.3 Routing.................................................10 68 4.3.1 IGP...................................................11 69 4.3.2 EGP...................................................12 70 4.3.3 Transport of Routing Protocols........................12 71 4.4 Multicast...............................................13 72 5. Customer Connection Transition Actions.....................13 73 5.1 Steps in the Transition of Customer Connection Networks.13 74 5.1.1 Small end sites.......................................14 75 5.1.2 Large end sites.......................................15 76 5.2 User Authentication/Access Control Requirements.........15 77 5.3 Configuration of Customer Equipment.....................16 78 5.4 Requirements for Traceability...........................16 79 5.5 Ingress Filtering in the Customer Connection Network....17 80 5.6 Multihoming.............................................17 81 5.7 Quality of Service......................................17 82 6. Network and Service Operation Actions......................18 83 7. Future Stages..............................................18 84 8. Requirements for Follow-On Work............................19 85 9. Example Networks...........................................19 86 9.1 Example 1...............................................20 87 9.2 Example 2...............................................22 88 9.3 Example 3...............................................22 89 10. Security Considerations....................................23 90 11. Acknowledgements...........................................23 91 12. Informative References.....................................24 93 1. Introduction 95 1.1 Goal and Scope of the Document 96 When an ISP deploys IPv6, its goal is to provide IPv6 connectivity 97 and global address space to its customers. The new IPv6 service must 98 be added to an already existing IPv4 service, and the introduction of 99 IPv6 must not interrupt this IPv4 service. 101 An ISP offering IPv4 service will find different ways to add IPv6 to 102 this service. This document discusses a small set of scenarios for 103 the introduction of IPv6 into an ISP's IPv4 network. It evaluates the 104 relevance of the existing transition mechanisms in the context of 105 these deployment scenarios, and points out the lack of essential 106 functionality in these methods to the ISP's operation of an IPv6 107 service. 109 The document is focused on services that include both IPv6 and IPv4 110 and does not cover issues surrounding IPv6-only service. It is also 111 outside the scope of this document to describe different types of 112 access or network technologies. 114 2. Brief Description of a Generic ISP Network 116 A generic network topology for an ISP can be divided into two main 117 parts: the backbone network and customer connection networks. It 118 includes, in addition to these, some other building blocks such as 119 network and service operations. The additional building blocks used 120 in this document are defined as follows: 122 "CPE" : Customer Premises Equipment 124 "PE" : Provider Edge equipment 126 "Network and service operation" 127 : This is the part of the ISP's network that hosts the 128 services required for the correct operation of the 129 ISP's network. These services usually include 130 management, supervision, accounting, billing, and 131 customer management applications. 133 "Customer connection" 134 : This is the part of the network used by a customer 135 when connecting to an ISP's network. It includes the 136 CPE, the last hop link and the parts of the PE 137 interfacing to the last hop link. 139 "Backbone" : This is the rest of the ISP's network infrastructure. 140 It includes the parts of the PE interfacing to the 141 core, the core routers of the ISP, and the border 142 routers used to exchange routing information with 143 other ISPs (or other administrative entities). 145 "Dual-stack network": 146 A network that supports natively both IPv4 and 147 IPv6. 149 It is noted that, in some cases (e.g., incumbent national or 150 regional operators), a given customer connection network may have 151 to be shared between or among different ISPs. According to the type 152 of customer connection network used (e.g., one involving only layer 2 153 devices or one involving non-IP technology), this constraint may 154 result in architectural considerations relevant to this document. 156 The basic components in the ISP's network are depicted in Figure 1. 158 ------------ ---------- 159 | Network and| | | 160 | Service |--| Backbone | 161 | Operation | | |\ 162 ------------ ---------- \ 163 / | \ \ 164 / | \ \_Peering( Direct and 165 / | \ exchange points) 166 / | \ 167 / | \ 168 ---------- / ---------- \ ---------- 169 | Customer | / | Customer | \ | Customer | 170 |Connection|--/ |Connection| \--|Connection| 171 | 1 | | 2 | | 3 | 172 ---------- ---------- ---------- 173 | | | ISP's Network 174 ------------------------------------------------------- 175 | | | Customers' Networks 176 +--------+ +--------+ +--------+ 177 | | | | | | 178 |Customer| |Customer| |Customer| 179 | | | | | | 180 +--------+ +--------+ +--------+ 181 Figure 1: ISP Network Topology. 183 3. Transition Scenarios 185 3.1 Identification of Stages and Scenarios 187 This section describes different stages an ISP might consider when 188 introducing IPv6 connectivity into its existing IPv4 network and the 189 different scenarios that might occur in the respective stages. 191 The stages here are snapshots of the ISP's network with respect to 192 IPv6 maturity. Because the ISP's network is continually evolving, a 193 stage is a measure of how far along the ISP has come in terms of 194 implementing the functionality necessary to offer IPv6 to its 195 customers. 197 It is possible for a transition to occur freely between different 198 stages. Although a network segment can only be in one stage at a 199 time, the ISP's network as a whole can be in different stages. 200 Different transition paths can be followed from the first to the 201 final stage. The transition between two stages does not have to be 202 instantaneous; it can occur gradually. 204 Each stage has different IPv6 properties. An ISP can, therefore, 205 based on its requirements, decide which set of stages it will follow 206 and in what order to transform its network. 208 This document is not aimed at covering small ISPs, hosting providers, 209 or data centers; only the scenarios applicable to ISPs eligible for 210 at least a /32 IPv6 prefix allocation from a RIR are covered. 212 3.2 Stages 214 The stages are derived from the generic description of an ISP's 215 network in Section 2. Combinations of different building blocks 216 that constitute an ISP's environment lead to a number of scenarios 217 from which the ISP can choose. The scenarios most relevant to this 218 document are those that maximize ISP's ability to offer IPv6 to its 219 customers in the most efficient and feasible way. The assumption in 220 all stages is that the ISP's goal is to offer both IPv4 and IPv6 to 221 the customer. 223 The four most probable stages are: 225 o Stage 1 Launch 226 o Stage 2a Backbone 227 o Stage 2b Customer connection 228 o Stage 3 Complete 230 Generally, an ISP is able to upgrade a current IPv4 network to an 231 IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can 232 also be implemented at a small cost by adding simple tunnel 233 mechanisms to the existing configuration. When designing a new 234 network, Stage 3 might be the first and last step, because there are 235 no legacy concerns. Nevertheless, the absence of IPv6 capability in 236 the network equipment can still be a limiting factor. 238 Note that in every stage except Stage 1, the ISP can offer both IPv4 239 and IPv6 services to its customers. 241 3.2.1 Stage 1 Scenarios: Launch 242 The first stage is an IPv4-only ISP with an IPv4 customer. This is 243 the most common case today and the natural starting point for the 244 introduction of IPv6. From this stage, the ISP can move (undergo a 245 transition) from Stage 1 to any other stage with the goal of offering 246 IPv6 to its customer. 248 The immediate first step consists of obtaining a prefix allocation 249 (typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, 250 ARIN, LACNIC, RIPE, ...) according to allocation procedures. 252 The ISP will also need to establish IPv6 connectivity to its upstream 253 providers and peers; it is of utmost importance to require IPv6 254 transit when negotiating IP transit deals with the upstream ISPs. If 255 the upstream is not providing IPv6 connectivity at the moment, it may 256 be possible to temporarily obtain connectivity from some other ISP 257 nearby, possibly using a short configured tunnel. However, the 258 longer-term goal must be requiring and obtaining IPv6 connectivity 259 from the transit ISPs, because otherwise the quality of IPv6 260 connectivity will likely be poor. 262 Connectivity to peers can be typically established either directly or 263 at Internet Exchange Points (IX). Most IXs are using techniques 264 where IPv6 is easy to use, and many IXs already provide 265 infrastructure for IPv6 peerings. Such peerings can be done natively 266 using IPv6. Peerings over IPv6-in-IPv4 tunnels is also possible but 267 not recommended at least in the long term. Direct connectivity to 268 peers may be feasible when there is direct connectivity to the peer 269 for IPv4. 271 3.2.2 Stage 2a Scenarios: Backbone 273 Stage 2a deal with an ISP with IPv4-only customer connection networks 274 and a backbone that supports both IPv4 and IPv6. In particular, the 275 ISP has the possibility of making the backbone IPv6-capable through 276 either software upgrades, hardware upgrades, or a combination of 277 both. 279 Since the customer connections have not yet been upgraded, a 280 tunneling mechanism has to be used to provide IPv6 connectivity 281 through the IPv4 customer connection networks. The customer can 282 terminate the tunnel at the CPE (if it has IPv6 support) or at some 283 set of devices internal to its network. That is, either the CPE or a 284 device inside the network could provide global IPv6 connectivity to 285 the rest of the devices in the customer's network. 287 3.2.3 Stage 2b Scenarios: Customer Connection 289 Stage 2b consists of an ISP with an IPv4 backbone network and a 290 customer connection network that supports both IPv4 and IPv6. Because 291 the service to the customer is native IPv6, the customer is not 292 required to support both IPv4 and IPv6. This is the biggest 293 difference in comparison to the previous stage. The need to exchange 294 IPv6 traffic still exists but might be more complicated than in the 295 previous case, because the backbone is not IPv6-enabled. After 296 completing Stage 2b, the original IPv4 backbone is unchanged. This 297 means that the IPv6 traffic is transported either by tunneling over 298 the existing IPv4 backbone, or in an IPv6 overlay network more or 299 less separated from the IPv4 backbone. 301 Normally the ISP will continue to provide IPv4 connectivity using 302 private (NATted by the ISP) or public IPv4 address; in many cases, 303 the customer also has a NAT of his/her own, and if so, this likely 304 continues to be used for IPv4 connectivity. 306 3.2.4 Stage 3 Scenarios: Complete 308 Stage 3 can be said to be the final step in introducing IPv6, at 309 least within the scope of this document. This stage consists of 310 ubiquitous IPv6 service with native support for IPv6 and IPv4 in both 311 backbone and customer connection networks. It is identical to the 312 previous stage from the customer's perspective, because the customer 313 connection network has not changed. The requirement for exchanging 314 IPv6 traffic is identical to Stage 2. 316 3.2.5 Stages 2a and 3: Combination Scenarios 318 Some ISPs may use different access technologies of varying IPv6 319 maturity. This may result in a combination of the Stages 2a and 3: 320 some customer connections do not support IPv6, but others do; in both 321 cases the backbone is dual-stack. 323 This scenario is equivalent to Stage 2a, but it requires support for 324 native IPv6 customer connections on some access technologies. 326 3.3 Transition Scenarios 328 Given the different stages, it is clear that an ISP has to be able 329 to make a transition from one stage to another. The initial stage in 330 this document is IPv4-only service and network. The end stage is dual 331 IPv4/IPv6 service and network. 333 The transition starts with an IPv4 ISP and then moves in one of 334 three directions. This choice corresponds to the different 335 transition scenarios. Stage 2a consists of upgrading the backbone 336 first. Stage 2b consists of upgrading the customer connection 337 network. Finally, Stage 3 consists of introducing IPv6 in both the 338 backbone and customer connections as needed. 340 Because most ISP backbone IPv4 networks continually evolve (firmware 341 replacements in routers, new routers, etc.), they can be made ready 342 for IPv6 without additional investment (except staff training). This 343 may be a slower but still useful transition path, because it allows 344 for the introduction of IPv6 without any actual customer demand. This 345 process may be superior to doing everything at the last minute, which 346 may entail a higher investment. However, it is important to consider 347 (and to request from vendors) IPv6 features in all new equipment from 348 the outset. Otherwise, the time and effort required to remove non- 349 IPv6-capable hardware from the network may be significant. 351 3.4 Actions Needed When Deploying IPv6 in an ISP's network 353 Examination of the transitions described above reveals that it 354 is possible to split the work required for each transition into a 355 small set of actions. Each action is largely independent of the 356 others, and some actions may be common to multiple transitions. 358 Analysis of the possible transitions leads to a small list of 359 actions: 361 * Actions required for backbone transition: 363 - Connect dual-stack customer connection networks to other 364 IPv6 networks through an IPv4 backbone. 366 - Transform an IPv4 backbone into a dual-stack one. This 367 action can be performed directly or through intermediate 368 steps. 370 * Actions required for customer connection transition: 372 - Connect IPv6 customers to an IPv6 backbone through an IPv4 373 network. 375 - Transform an IPv4 customer connection network into a dual- 376 stack one. 378 * Actions required for network and service operation transition: 380 - Set up IPv6 connectivity to upstream providers and peers. 382 - Configure IPv6 functions into network components. 384 - Upgrade regular network management and monitoring 385 applications to take IPv6 into account. 387 - Extend customer management (e.g., RADIUS) mechanisms 388 to be able to supply IPv6 prefixes and other information 389 to customers. 391 - Enhance accounting, billing, etc. to work with IPv6 392 as needed. (Note: if dual-stack service is offered, this 393 may not be necessary.) 395 - Implement security for network and service operation. 397 Sections 4, 5, and 6 contain detailed descriptions of each action. 399 4. Backbone Transition Actions 401 4.1 Steps in the Transition of Backbone Networks 403 In terms of physical equipment, backbone networks consist mainly of 404 high-speed core and edge routers. Border routers provide peering 405 with other providers. Filtering, routing policy, and policing 406 functions are generally managed on border routers. 408 In the beginning, an ISP has an IPv4-only backbone. In the end, the 409 backbone is completely dual-stack. In between, intermediate steps may 410 be identified: 412 Tunnels Tunnels Dual Full 413 IPv4-only ----> or ---> or + Stack --> Dual Stack 414 dedicated IPv6 dedicated IPv6 routers 415 links links 416 Figure 2: Transition Path. 418 The first step involves tunnels or dedicated links but leaves 419 existing routers unchanged. Only a small set of routers then have 420 IPv6 capabilities. The use of configured tunnels is adequate during 421 this step. 423 In the second step, some dual-stack routers are added, progressively, 424 to this network. 426 The final step is reached when all or almost all routers are dual- 427 stack. 429 For many reasons (technical, financial, etc.), the ISP may progress 430 step by step or jump directly to the final one. One important 431 criterion in planning this evolution is the number of IPv6 customers 432 the ISP expects during its initial deployments. If few customers 433 connect to the original IPv6 infrastructure, then the ISP is likely 434 to remain in the initial steps for a long time. 436 In short, each intermediate step is possible, but none is mandatory. 438 4.1.1 MPLS Backbone 440 If MPLS is already deployed in the backbone, it may be desirable 441 to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 442 Label Switched Path (LSP) requires signaling through the MPLS 443 network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might 444 require upgrade/change in the MPLS core network. 446 An alternative approach is to use BGP for signaling or to perform, 447 for example IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some of 448 the multiple possibilities are preferable to others depending on the 449 specific environment under consideration; the approaches seem to be: 451 1) Require that MPLS networks deploy native IPv6 routing and 452 forwarding support. 454 2) Require that MPLS networks support native routing and setting 455 up of IPv6 LSPs, used for IPv6 connectivity. 457 3) Use only configured tunneling over IPv4 LSPs. 459 4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation 460 for IPv6 connectivity. 462 Approaches 1) and 2) are clearly the best target approaches. However, 463 approach 1) may not be possible if the ISP is not willing to add IPv6 464 support in the network, or if the installed equipment is not capable 465 of high performance native IPv6 forwarding. Approach 2) may not be 466 possible if the ISP is not willing or able to add IPv6 LSP set-up 467 support in the MPLS control plane. 469 Approach 4) can be used as an interim mechanism where other options 470 are unfeasible or undesirable for the reasons discussed above. 472 Approach 3) is roughly equivalent to approach 4) except that it does 473 not require additional mechanisms but may lack scalability in the 474 larger networks especially if IPv6 is widely deployed. 476 4.2 Configuration of Backbone Equipment 478 In the backbone, the number of devices is small and IPv6 479 configuration mainly deals with routing protocol parameters, 480 interface addresses, loop-back addresses, access control lists, etc. 482 These IPv6 parameters need to be configured manually. 484 4.3 Routing 485 ISPs need routing protocols to advertise reachability and to 486 find the shortest working paths, both internally and externally. 488 Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is 489 not usually used in service provider networks due to OSPF and IS-IS 490 being far superior IGPs. BGP is the only IPv4 EGP. Static routes also 491 are used in both cases. 493 Note that it is possible to configure a given network so that it 494 results in having an IPv6 topology different from its IPv4 topology. 495 For example, some links or interfaces may be dedicated to IPv4-only 496 or IPv6-only traffic, or some routers may be dual-stack whereas 497 others may be IPv4- or IPv6-only. In this case, routing protocols 498 must be able to understand and cope with multiple topologies. 500 4.3.1 IGP 502 Once the IPv6 topology has been determined, the choice of IPv6 IGP 503 must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not 504 appropriate in most contexts, due to RIPv2 not being appropriate 505 for IPv4 either, and is therefore not discussed here. The IGP 506 typically includes the routers' point-to-point and loop-back 507 addresses. 509 The most important decision is whether one wishes to have separate 510 routing protocol processes for IPv4 and IPv6. Separating them 511 requires more memory and CPU for route calculations, e.g., when the 512 links flap. On the other hand, separation provides a certain measure 513 of assurance that if problems arise with IPv6 routing, they will not 514 affect the IPv4 routing protocol at all. In the initial phases, if 515 it is uncertain whether joint IPv4-IPv6 networking is working as 516 intended, running separate processes may be desirable and easier to 517 manage. 519 Thus the possible combinations are: 521 - with separate processes: 522 o OSPFv2 for IPv4, IS-IS for IPv6 (only) 523 o OSPFv2 for IPv4, OSPFv3 for IPv6, or 524 o IS-IS for IPv4, OSPFv3 for IPv6 526 - with the same process: 527 o IS-IS for both IPv4 and IPv6 529 Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 530 topologies must be "convex," unless the multiple-topology IS-IS 531 extensions [MTISIS] have been implemented (note that using IS-IS for 532 only IPv4 or only IPv6 requires no convexity). In simpler networks or 533 with careful planning of IS-IS link costs, it is possible to keep 534 even incongruent IPv4/IPv6 topologies "convex." The convexity problem 535 is explained in more detail with an example in Appendix A. 537 When deploying full dual-stack in the short-term, using single- 538 topology IS-IS is recommended. This may be applicable particularly 539 for some larger ISPs. In other scenarios, determining between one or 540 two separate processes often depends on the perceived risk to the 541 IPv4 routing infrastructure, i.e., whether one wishes to keep them 542 separate for the time being. If that is not a factor, using a single 543 process is usually preferable due to operational reasons: not having 544 to manage two protocols and topologies. 546 The IGP is typically only used to carry loopback and point-to-point 547 addresses and doesn't include customer prefixes or external routes. 548 Internal BGP (iBGP), as described in the next section, is most often 549 deployed in all routers (PE and core) to distribute routing 550 information about customer prefixes and external routes. 552 Some of the simplest devices, e.g., CPE routers, may not implement 553 routing protocols other than RIPng. In some cases, therefore, it may 554 be necessary to run RIPng in addition to one of the above IGPs, at 555 least in a limited fashion, and then, by some mechanism, to 556 redistribute routing information between the routing protocols. 558 4.3.2 EGP 560 BGP is used for both internal and external BGP sessions. 562 BGP with multiprotocol extensions [RFC 2858] can be used for IPv6 563 [RFC 2545]. These extensions enable the exchange of IPv6 routing 564 information as well as the establishment of BGP sessions using TCP 565 over IPv6. 566 It is possible to use a single BGP session to advertise both IPv4 567 and IPv6 prefixes between two peers. However, the most common 568 practice today is to use separate BGP sessions. 570 4.3.3 Transport of Routing Protocols 572 IPv4 routing information should be carried by IPv4 transport and 573 similarly IPv6 routing information by IPv6 for several reasons: 575 * IPv6 connectivity may work when IPv4 connectivity is down 576 (or vice-versa). 577 * The best route for IPv4 is not always the best one for IPv6. 578 * The IPv4 and IPv6 logical topologies may be different, 579 because the administrator may want to assign different metrics 580 to a physical link for load balancing or because tunnels may be 581 in use. 583 4.4 Multicast 585 Currently, IPv6 multicast is not a major concern for most ISPs. 586 However, some of them are considering deploying it. Multicast is 587 achieved using the PIM-SM and PIM-SSM protocols. These also work with 588 IPv6. 590 Information about multicast sources is exchanged using MSDP in IPv4, 591 but MSDP is intentionally not defined for IPv6. Instead, one should 592 use only PIM-SSM or an alternative mechanism for conveying the 593 information [EMBEDRP]. 595 5. Customer Connection Transition Actions 597 5.1 Steps in the Transition of Customer Connection Networks 599 Customer connection networks are generally composed of a small set of 600 PEs connected to a large set of CPEs, and may be based on different 601 technologies depending on the customer type or size, as well as the 602 required bandwidth or even quality of service. Basically, public 603 customers or small/unmanaged networks connection networks usually 604 rely on a different technologies (e.g. dial-up or DSL) than the ones 605 used for large customers typically running managed networks. 606 Transitioning these infrastructures to IPv6 can be accomplished in 607 several steps, but some ISPs, depending on their perception of the 608 risks, may avoid some of the steps. 610 Connecting IPv6 customers to an IPv6 backbone through an IPv4 network 611 can be considered as a first careful step taken by an ISP to provide 612 IPv6 services to its IPv4 customers. In addition, some ISPs may also 613 choose to provide IPv6 service independently from the regular IPv4 614 service. 616 In any case, IPv6 service can be provided by using tunneling 617 techniques. The tunnel may terminate at the CPE corresponding to the 618 IPv4 service or in some other part of the customer's infrastructure 619 (for instance, on IPv6-specific CPE or even on a host). 621 Several tunneling techniques have already been defined: configured 622 tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], etc. 623 Some of them are based on a specific addressing plan independent of 624 the ISP's allocated prefix(es), while some others use a part of the 625 ISP's prefix. In most cases using ISP's address space is preferable. 627 A key factor is the presence or absence of NATs between the two 628 tunnel end-points. In most cases, 6to4 and ISATAP are incompatible 629 with NATs, and UDP encapsulation for configured tunnels has not been 630 specified. 632 Dynamic and non-permanent IPv4 address allocation is another factor a 633 tunneling technique may have to deal with. In this case the tunneling 634 techniques may be more difficult to deploy at the ISP's end, 635 especially if a protocol including authentication (like PPP for IPv6) 636 is not used. This may need to be considered in more detail. 638 However, NAT traversal can be avoided if the NAT supports forwarding 639 protocol-41 [PROTO41] and is configured to do so. 641 Firewalls in the path can also break tunnels of these types. The 642 administrator of the firewall needs to create a hole for the tunnel. 643 This is usually manageable, as long as the firewall is controlled by 644 either the customer or the ISP, which is almost always the case. 646 When the CPE is performing NAT or firewall functions, terminating the 647 tunnels directly at the CPE typically simplifies the scenario 648 considerably, avoiding the NAT and firewall traversal. If such an 649 approach is adopted, the CPE has to support the tunneling mechanism 650 used, or be upgraded to do so. 652 5.1.1 Small end sites 654 Tunneling considerations for small end sites are discussed in 655 [UNMANEVA]. These identify solutions relevant to the first category 656 of unmanaged networks. The tunneling requirements applicable in these 657 scenarios are described in [TUNREQS] 659 The connectivity mechanisms can be categorized as "managed" or 660 "opportunistic." The former consist of native service or a 661 configured tunnel (with or without a tunnel broker); the latter 662 include 6to4 and, e.g., Teredo -- they provide "short-cuts" between 663 nodes using the same mechanisms and are available without contracts 664 with the ISP. 666 The ISP may offer opportunistic services, mainly a 6to4 relay, 667 especially as a test when no actual service is offered yet. At the 668 later phases, ISPs might also deploy 6to4 relays and Teredo servers 669 (or similar) to optimize their customers' connectivity to 6to4 and 670 Teredo nodes. 672 It is to be noticed that opportunistic services are typically based 673 on techniques that don't use IPv6 addresses out of the ISP's 674 allocated prefix(es), and that the services have very limited 675 functions to control the origin and the number of customers connected 676 to a given relay. 678 Most interesting are the managed services. When dual-stack is not an 679 option, a form of tunneling must be used. When configured tunneling 680 is not an option (e.g., due to dynamic IPv4 addressing), some form of 681 automation has to be used. Basically, the options are either to 682 deploy an L2TP architecture (whereby the customers would run L2TP 683 clients and PPP over it to initiate IPv6 sessions) or to deploy a 684 tunnel configuration service. The prime candidates for tunnel 685 configuration are STEP [STEP] and TSP [TSP], which both also work in 686 the presence of NATs. Neither is analyzed further in this document. 688 5.1.2 Large end sites 690 Large end sites usually have a managed network. 692 Dual-stack access service is often a realistic possibility since the 693 customer network is managed (although CPE upgrades may be necessary). 695 Configured tunnels, as-is, are a good solution when a NAT is not in 696 the way and the IPv4 end-point addresses are static. In this 697 scenario, NAT traversal is not typically required. If fine-grained 698 access control is needed, an authentication protocol needs to be 699 implemented. 701 Tunnel brokering solutions, to help facilitate the set-up of a bi- 702 directional tunnel, have been proposed. Such mechanisms are typically 703 unnecessary for large end-sites, as simple configured tunneling or 704 native access can be used instead. However, if such mechanisms would 705 already be deployed, large sites starting to deploy IPv6 might be 706 able to benefit from them in any case. 708 Teredo is not applicable in this scenario as it can only provide IPv6 709 connectivity to a single host, not the whole site. 6to4 is not 710 recommended due to its reliance on the relays and provider- 711 independent address space, which make it impossible to guarantee the 712 required service quality and manageability large sites typically 713 want. 715 5.2 User Authentication/Access Control Requirements 717 User authentication can be used to control who can use the IPv6 718 connectivity service in the first place or who can access specific 719 IPv6 services (e.g., NNTP servers meant for customers only, etc.). 720 The former is described at more length below. The latter can be 721 achieved by ensuring that for all the service-specific IPv4 access 722 lists, there are also equivalent IPv6 access lists. 724 IPv6-specific user authentication is not always required. An example 725 is a customer of the IPv4 service automatically having access to the 726 IPv6 service. In this case the IPv4 access control also provides 727 access to the IPv6 services. 729 When a provider does not wish to give its IPv4 customers 730 automatic access to IPv6 services, specific IPv6 access control must 731 be performed in parallel with the IPv4 access control. This does not 732 imply that different user authentication must be performed for IPv6, 733 but merely that the authentication process may lead to different 734 results for IPv4 and IPv6 access. 736 Access control traffic may use IPv4 or IPv6 transport. For instance, 737 RADIUS [RADIUS] traffic related to IPv6 service can be transported 738 over IPv4. 740 5.3 Configuration of Customer Equipment 742 The customer connection networks are composed of PE and CPE(s). 743 Usually, each PE connects multiple CPE components to the backbone 744 network infrastructure. This number may reach tens of thousands or 745 more. The configuration of CPE is a difficult task for the ISP, and 746 it is even more difficult when it must be done remotely. In this 747 context, the use of auto-configuration mechanisms is beneficial, even 748 if manual configuration is still an option. 750 The parameters that usually need to be provided to customers 751 automatically are: 753 - The network prefix delegated by the ISP, 754 - The address of the Domain Name System server (DNS), 755 - Possibly other parameters, e.g., the address of an NTP 756 server. 758 When user identification is required on the ISP's network, DHCPv6 may 759 be used to provide configurations; otherwise, either DHCPv6 or a 760 stateless mechanism can be used. This is discussed in more detail in 761 [DUAL ACCESS]. 763 Note that when the customer connection network is shared between the 764 users or the ISPs, and not just a point-to-point link, authenticating 765 the configuration of the parameters (especially prefix delegation) 766 requires further study. 768 As long as IPv4 service is available alongside IPv6 it is not 769 required to auto configure IPv6 parameters in the CPE, except the 770 prefix, because the IPv4 settings may be used. 772 5.4 Requirements for Traceability 774 Most ISPs have some kind of mechanism to trace the origin of traffic 775 in their networks. This also has to be available for IPv6 traffic, 776 meaning that a specific IPv6 address or prefix has to be tied to a 777 certain customer, or that records of which customer had which 778 address or prefix must be maintained. This also applies to the 779 customers with tunneled connectivity. 781 This can be done, for example, by mapping a DHCP response to a 782 physical connection and storing the result in a database. It can also 783 be done by assigning a static address or prefix to the customer. A 784 tunnel server could also provide this mapping. 786 5.5 Ingress Filtering in the Customer Connection Network 788 Ingress filtering must be deployed towards the customers, everywhere, 789 to ensure traceability, to prevent DoS attacks using spoofed 790 addresses, to prevent illegitimate access to the management 791 infrastructure, etc. 793 Ingress filtering can be done, for example, by using access lists or 794 Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are 795 described in [RFC3704]. 797 5.6 Multihoming 799 Customers may desire multihoming or multi-connecting for a number of 800 reasons [RFC3582]. 802 Mechanisms for multihoming to more than one ISP are still under 803 discussion. One working model could be to deploy at least one prefix 804 per ISP, and to choose the prefix from the ISP to which traffic is 805 sent. In addition, tunnels may be used for robustness [RFC3178]. 806 Currently, there are no provider-independent addresses for end-sites. 807 Such addresses would enable IPv4-style multihoming, with associated 808 disadvantages. 810 Multi-connecting more than once to just one ISP is a simple 811 practice, and this can be done, e.g., by using BGP with public or 812 private AS numbers and a prefix assigned to the customer. 814 5.7 Quality of Service 816 In most networks, quality of service in one form or another is 817 important. 819 Naturally, the introduction of IPv6 should not impair existing 820 Service Level Agreements (SLAs) or similar quality assurances. 822 During the deployment of the IPv6 service, the service could be best- 823 effort or similar even if the IPv4 service has a SLA. In the end both 824 IP version should be treated equally. 826 IntServ and DiffServ are equally applicable to IPv6 as to IPv4 and 827 work in a similar fashion independent of IP version. Of these, 828 typically only DiffServ has been implemented. 830 Many bandwidth provisioning systems operate with IPv4 assumptions, 831 e.g., taking an IPv4 address or (set of) prefixes for which traffic 832 is reserved or preferred. These systems require special attention 833 when introducing IPv6 support in the networks. 835 6. Network and Service Operation Actions 837 The network and service operation actions fall into different 838 categories as listed below: 840 - Set up IPv6 connectivity to upstream providers and peers. 841 - IPv6 network device configuration: for initial configuration 842 and updates 843 - IPv6 network management 844 - IPv6 monitoring 845 - IPv6 customer management 846 - IPv6 network and service operation security 848 Some of these items will require an IPv6 native transport layer to 849 be available, whereas others will not. 851 As a first step, network device configuration and regular network 852 management operations can be performed over an IPv4 transport, 853 because IPv6 MIBs are also available over IPv4 transport. 854 Nevertheless, some monitoring functions require the availability of 855 IPv6 transport. This is the case, for instance, when ICMPv6 messages 856 are used by the monitoring applications. 858 The current inability on many platforms to retrieve separate IPv4 and 859 IPv6 traffic statistics from dual-stack interfaces for management 860 purposes by using SNMP is an issue. 862 As a second step, IPv6 transport can be provided for any of these 863 network and service operation facilities. 865 7. Future Stages 867 At some point, an ISP might want to transition to a service that is 868 IPv6 only, at least in certain parts of its network. Such a 869 transition creates many new cases into which continued maintenance of 870 the IPv4 service must be factored. Providing an IPv6-only service is 871 not much different from the dual IPv4/IPv6 service described in stage 872 3 except for the need to phase out the IPv4 service. The delivery of 873 IPv4 services over an IPv6 network and the phase out of IPv4 are left 874 for a subsequent document. Note that there are some services which 875 will need to maintain IPv4 connectivity (e.g., authorative and some 876 recursive DNS servers [DNSGUIDE]). 878 8. Requirements for Follow-On Work 880 This section tries to summarize the potential items requiring 881 specification in the IETF. 883 Work items for which concrete specifications for which an approach 884 was not yet apparent as of this writing are: 886 - A tunnel server/broker mechanisms for the cases where the customer 887 connection networks cannot be upgraded needs to be specified 888 [TUNREQS]. 889 - An IPv6 site multihoming mechanism (or multiple ones) need to be 890 developed. 892 Work items which were already fast in progress, as of this writing, 893 are: 895 - 6PE for MPLS was identified as a required mechanism, and this is 896 already in progress [BGPTUNNEL] 897 - IS-IS for Multiple Topologies was noted as a helpful mechanism in 898 certain environments; however, it is possible to use alternative 899 methods to achieve the same end, so specifying this is not strictly 900 required. 901 - Any-source Multicast can be accomplished using Embedded-RP 902 [EMBEDRP], already in progress. 904 9. Example Networks 906 In this section, a number of different example networks are 907 presented. These will not necessarily match any existing networks but 908 are intended to be useful even in cases in which they do not 909 correspond to specific target networks. The purpose of these examples 910 is to exemplify the applicability of the transition mechanisms 911 described in this document to a number of different situations with 912 different prerequisites. 914 The sample network layout will be the same in all network examples. 915 These should be viewed as specific representations of a generic 916 network with a limited number of network devices. A small number of 917 routers have been used in the examples. However, because the network 918 examples follow the implementation strategies recommended for the 919 generic network scenario, it should be possible to scale the examples 920 to fit a network with an arbitrary number, e.g. several hundreds or 921 thousands, of routers. 923 The routers in the sample network layout are interconnected with each 924 other as well as with another ISP. The connection to another ISP can 925 be either direct or through an exchange point. In addition to these 926 connections, a number of customer connection networks are also 927 connected to the routers. Customer connection networks can be, for 928 example, xDSL or cable network equipment. 930 ISP1 | ISP2 931 +------+ | +------+ 932 | | | | | 933 |Router|--|--|Router| 934 | | | | | 935 +------+ | +------+ 936 / \ +----------------------- 937 / \ 938 / \ 939 +------+ +------+ 940 | | | | 941 |Router|----|Router| 942 | | | | 943 +------+ +------+\ 944 | | \ | Exchange point 945 +------+ +------+ \ +------+ | +------+ 946 | | | | \_| | | | |-- 947 |Router|----|Router|----\|Router|--|--|Switch|-- 948 | | | | | | | | |-- 949 +------+ /+------+ +------+ | +------+ 950 | / | | 951 +-------+/ +-------+ | 952 | | | | 953 |Access1| |Access2| 954 | | | | 955 +-------+ +-------+ 956 ||||| ||||| ISP Network 957 ----|-----------|---------------------- 958 | | Customer Networks 959 +--------+ +--------+ 960 | | | | 961 |Customer| |Customer| 962 | | | | 963 +--------+ +--------+ 964 Figure 3: ISP Sample Network Layout. 966 9.1 Example 1 968 Example 1 presents a network built according to the sample network 969 layout with a native IPv4 backbone. The backbone is running IS-IS and 970 IBGP as routing protocols for internal and external routes, 971 respectively. Multiprotocol BGP is used to exchange routes over the 972 connections to ISP2 and the exchange point. Multicast using PIM-SM 973 routing is present. QoS using DiffServ is deployed. 975 Access 1 is xDSL connected to the backbone through an access router. 976 The xDSL equipment, except for the access router, is considered to be 977 layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically 978 assigned to the customer using DHCP. No routing information is 979 exchanged with the customer. Access control and traceability are 980 performed in the access router. Customers are separated into VLANs or 981 separate ATM PVCs up to the access router. 983 Access 2 is "fiber to the building or home" (FTTB/H) connected 984 directly to the backbone router. This connection is considered to be 985 layer-3-aware, because it is using layer 3 switches and it performs 986 access control and traceability through its layer 3 awareness by 987 using DHCP snooping. IPv4 addresses are dynamically assigned to the 988 customers using DHCP. No routing information is exchanged with the 989 customer. 991 The actual IPv6 deployment might start by enabling IPv6 on a couple 992 of backbone routers, configuring tunnels between them (if not 993 adjacent), and connecting to a few peers or upstream providers 994 (either through tunnels or at an internet exchange). 996 After a trial period, the rest of the backbone is upgraded to dual- 997 stack, and IS-IS without multi-topology extensions (the upgrade order 998 is considered with care) is used as an IPv6 and IPv4 IGP. When 999 upgrading, it's important to note that until IPv6 customers are 1000 connected behind a backbone router, the convexity requirement is not 1001 critical: the routers will just not be reachable using IPv6. That 1002 is, software supporting IPv6 could be installed even though the 1003 routers would not be used for (customer) IPv6 traffic yet. That way, 1004 IPv6 could be enabled in the backbone on a need-to-enable basis when 1005 needed. 1007 Separate IPv6 BGP sessions are built, similar to IPv4. Multicast 1008 (through SSM and Embedded-RP) and DiffServ are offered at a later 1009 phase of the network, e.g., after a year of stable IPv6 unicast 1010 operations. 1012 Offering native service as quickly as possible is considered most 1013 important. However, a 6to4 relay may be provided in the meantime for 1014 optimized 6to4 connectivity and it may also be combined with a tunnel 1015 broker for extended functionality. xDSL equipment, operating as 1016 bridges at Layer 2 only, does not require changes in CPE: IPv6 1017 connectivity can be offered to the customers by upgrading the PE 1018 router to IPv6. In the initial phase, only Router Advertisements are 1019 used; DHCPv6 Prefix Delegation can be added as the next step if no 1020 other mechanisms are available. 1022 The FTTB/H access has to be upgraded to support access control and 1023 traceability in the switches, probably by using DHCP snooping or a 1024 similar IPv6 capability, but it also has to be compatible with prefix 1025 delegation and not just address assignment. This could, however, lead 1026 to the need to use DHCPv6 for address assignment. 1028 9.2 Example 2 1030 In example 2 the backbone is running IPv4 with MPLS and is using OSPF 1031 and IBGP are for internal and external routes respectively. The 1032 connections to ISP2 and the exchange point run BGP to exchange 1033 routes. Multicast and QoS are not deployed. 1035 Access 1 is a fixed line, e.g., fiber, connected directly to the 1036 backbone. Routing information is in some cases exchanged with CPE at 1037 the customer's site; otherwise static routing is used. Access 1 can 1038 also be connected to a BGP/MPLS-VPN running in the backbone. 1040 Access 2 is xDSL connected directly to the backbone router. The xDSL 1041 is layer 2 only, and access control and traceability are achieved 1042 through PPPoE/PPPoA. PPP also provides address assignment. No routing 1043 information is exchanged with the customer. 1045 IPv6 deployment might start with an upgrade of a couple of PE routers 1046 to support [BGPTUNNEL], because this will allow large-scale IPv6 1047 support without hardware or software upgrades in the core. In a later 1048 phase native IPv6 traffic or IPv6 LSPs would be used in the whole 1049 network. In that case IS-IS or OSPF could be used for the internal 1050 routing, and a separate IPv6 BGP session would be run. 1052 For the fixed-line customers, the CPE has to be upgraded and prefix 1053 delegation using DHCPv6 or static assignment would be used. An IPv6 1054 MBGP session would be used when routing information has to be 1055 exchanged. In the xDSL case the same conditions for IP-tunneling as 1056 in Example 1 apply. In addition to IP-tunneling an additional PPP 1057 session can be used to offer IPv6 access to a limited number of 1058 customers. Later, when clients and servers have been updated, the 1059 IPv6 PPP session can be replaced with a combined PPP session for both 1060 IPv4 and IPv6. PPP has to be used for address and prefix assignment. 1062 9.3 Example 3 1064 A transit provider offers IP connectivity to other providers, but 1065 not to end users or enterprises. IS-IS and IBGP are used internally 1066 and BGP externally. Its accesses connect Tier-2 provider cores. No 1067 multicast or QoS is used. 1069 As this type of transit provider has a number of customers, which in 1070 turn have a large number of customers, it obtains an address 1071 allocation from a RIR. The whole backbone can be upgraded to dual- 1072 stack in a reasonably rapid pace after a trial with a couple of 1073 routers. IPv6 routing is performed using the same IS-IS process and 1074 separate IPv6 BGP sessions. 1076 The ISP provides IPv6 transit to its customers for free, as a 1077 competitive advantage. It also provides, at the first phase only, a 1078 configured tunnel service with BGP peering to the significant sites 1079 and customers (those with an AS number) which are the customers of 1080 its customers whenever its own customer networks are not offering 1081 IPv6. This is done both to introduce them to IPv6 and to create a 1082 beneficial side-effect: a bit of extra revenue is generated from its 1083 direct customers as the total amount of transited traffic grows. 1085 10. Security Considerations 1087 This document analyses scenarios and identifies some transition 1088 mechanisms that could be used for the scenarios. It does not 1089 introduce any new security issues. Security considerations of each 1090 mechanism are described in the respective documents. 1092 However, a few generic observations are in order. 1094 o introducing IPv6 adds new classes of security threats or 1095 requires adopting new protocols or operational models 1096 than with IPv4; typically these are generic issues, and 1097 to be further discussed in other documents, for example, 1098 [V6SEC]. 1100 o the more complex the transition mechanisms employed become, 1101 the more difficult it will be to manage or analyze their 1102 impact on security. Consequently, simple mechanisms are to 1103 be preferred. 1105 o this document has identified a number of requirements for 1106 analysis or further work which should be explicitly considered 1107 when adopting IPv6: how to perform access control over 1108 shared media or shared ISP customer connection media, 1109 how to manage the configuration management security on such 1110 environments (e.g., DHCPv6 authentication keying), and 1111 how to manage customer traceability if stateless address 1112 autoconfiguration is used. 1114 11. Acknowledgements 1116 This draft has greatly benefited from inputs by Marc Blanchet, Jordi 1117 Palet, Francois Le Faucheur, Ronald van der Pol and Cleve Mickles. 1119 Special thanks to Richard Graveman and Michael Lambert for 1120 proofreading the document. 1122 12. Informative References 1124 [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of 1125 RP in IPv6 Multicast Address" - 1126 Work in progress 1128 [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- 1129 ISIS: Multi Topology (MT) Routing in IS-IS" 1130 Work in progress 1132 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., Katz, D., 1133 "Multiprotocol Extensions for BGP-4" 1134 RFC 2858 1136 [RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol 1137 Extensions for IPv6 Inter-Domain Routing" 1138 RFC 2545 1140 [BCP3704] Baker, F., Savola, P., "Ingress Filtering for 1141 Multihomed Networks" 1142 RFC 3704 1144 [RFC3582] Abley, J., Black, B., Gill, V., "Goals for IPv6 Site- 1145 Multihoming Architectures" 1146 RFC 3582 1148 [RFC3178] Hagino, J., Snyder, H., "IPv6 Multihoming Support at 1149 Site Exit Routers" 1150 RFC 3178 1152 [RFC3056] Carpenter, B., Moore, K., "Connection of IPv6 Domains 1153 via IPv4 Clouds" 1154 RFC 3056 1156 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1157 "Remote Authentication Dial In User Service (RADIUS)", 1158 RFC 2865 1160 [BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., 1161 Le Faucheur, F., "Connecting IPv6 Islands across IPv4 1162 Clouds with BGP" 1163 Work in progress 1165 [DUAL ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., 1166 Takenouchi, A. 1167 "A Model of IPv6/IPv4 Dual Stack Internet Access 1168 Service" 1169 Work in progress 1171 [STEP] Savola, P. "Simple IPv6-in-IPv4 Tunnel Establishment 1172 Procedure (STEP)" 1173 Work in progress 1175 [TSP] Blanchet, M. "IPv6 Tunnel broker with Tunnel Setup 1176 Protocol (TSP)" 1177 Work in progress 1179 [TUNREQS] Durand, A., Parent, F. "Requirements for assisted 1180 tunneling" 1181 Work in progress 1183 [UNMANEVA] Huitema, C., Austein, R., Satapati, S., 1184 van der Pol, R. 1185 "Evaluation of Transition Mechanisms for Unmanaged 1186 Networks" 1187 Work in progress 1189 [PROTO41] Palet, J., Olvera, C., Fernandez, D. "Forwarding 1190 Protocol 41 in NAT Boxes" 1191 Work in progress 1193 [V6SEC] Savola, P. "IPv6 Transition/Co-existence Security 1194 Considerations" 1195 Work in progress 1197 [DNSGUIDE] Durand, A., Ihren, J. "DNS IPv6 transport operational 1198 guidelines" 1199 Work in progress 1201 [TEREDO] Huitema, C. "Teredo: Tunneling IPv6 over UDP through 1202 NATs" 1203 Work in progress 1205 Authors' Addresses 1207 Mikael Lind 1208 TeliaSonera 1209 Vitsandsgatan 9B 1210 SE-12386 Farsta, Sweden 1211 Email: mikael.lind@teliasonera.com 1213 Vladimir Ksinant 1214 Thales Communications 1215 160, boulevard de Valmy 1216 92704 Colombes, France 1217 Email: vladimir.ksinant@fr.thalesgroup.com 1219 Soohong Daniel Park 1220 Mobile Platform Laboratory, SAMSUNG Electronics. 1221 416, Maetan-3dong, Paldal-Gu, 1222 Suwon, Gyeonggi-do, Korea 1223 Email: soohong.park@samsung.com 1225 Alain Baudot 1226 France Telecom R&D 1227 42, rue des coutures 1228 14066 Caen - FRANCE 1229 Email: alain.baudot@rd.francetelecom.com 1231 Pekka Savola 1232 CSC/FUNET 1233 Espoo, Finland 1234 EMail: psavola@funet.fi 1236 Intellectual Property Statement 1238 The IETF takes no position regarding the validity or scope of any 1239 Intellectual Property Rights or other rights that might be claimed 1240 to pertain to the implementation or use of the technology described 1241 in this document or the extent to which any license under such rights 1242 might or might not be available; nor does it represent that it has 1243 made any independent effort to identify any such rights. Information 1244 on the procedures with respect to rights in RFC documents can be 1245 found in BCP 78 and BCP 79. 1247 Copies of IPR disclosures made to the IETF Secretariat and any 1248 assurances of licenses to be made available, or the result of an 1249 attempt made to obtain a general license or permission for the use of 1250 such proprietary rights by implementers or users of this 1251 specification can be obtained from the IETF on-line IPR repository at 1252 http://www.ietf.org/ipr. 1254 The IETF invites any interested party to bring to its attention any 1255 copyrights, patents or patent applications, or other proprietary 1256 rights that may cover technology that may be required to implement 1257 this standard. Please address the information to the IETF at ietf- 1258 ipr@ietf.org. 1260 Full Copyright Statement 1261 Copyright (C) The Internet Society (2004). This document is subject 1262 to the rights, licenses and restrictions contained in BCP 78, and 1263 except as set forth therein, the authors retain all their rights." 1264 The limited permissions granted above are perpetual and will not be 1265 revoked by the Internet Society or its successors or assignees. 1267 This document and the information contained herein are provided on an 1268 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1269 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1270 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1271 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1272 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1273 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1275 Appendix A: Convexity Requirements in Single Topology IS-IS 1277 The single-topology IS-IS convexity requirements could be summarized, 1278 from IPv4/6 perspective, as follows: 1280 1) "any IP-independent path from an IPv4 router to any other IPv4 1281 router must only go through routers which are IPv4-capable", and 1283 2) "any IP-independent path from an IPv6 router to any other IPv6 1284 router must only go through routers which are IPv6-capable". 1286 As IS-IS is based upon CLNS, these are not trivially accomplished. 1287 The single-topology IS-IS builds paths which are agnostic of IP 1288 versions. 1290 Consider an example scenario of three IPv4/IPv6-capable routers 1291 and an IPv4-only router: 1293 cost 5 R4 cost 5 1294 ,------- [v4/v6] -----. 1295 / \ 1296 [v4/v6] ------ [ v4 ] -----[v4/v6] 1297 R1 cost 3 R3 cost 3 R2 1299 Here the second requirement would not hold. IPv6 packets from R1 to 1300 R2 (or vice versa) would go through R3, which does not support IPv6, 1301 and the packets would get discarded. By reversing the costs between 1302 R1-R3, R3-R2 and R1-R4,R4-R2 the traffic would work in the normal 1303 case, but if a link fails and the routing changes to go through R3, 1304 the packets would start being discarded again.