idnits 2.17.1 draft-savola-multi6-nowwhat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2003) is 7680 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: 'MIPv6' is mentioned on line 131, but not defined == Unused Reference: 'MIPV6' is defined on line 521, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-multi6-v4-multihoming-00 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-v4-multihoming (ref. 'V4MULTI') == Outdated reference: A later version (-07) exists of draft-ietf-multi6-multihoming-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-multihoming-requirements (ref. 'GOALS') == Outdated reference: A later version (-04) exists of draft-coene-sctp-multihome-03 == Outdated reference: A later version (-02) exists of draft-teraoka-ipng-lin6-01 == Outdated reference: A later version (-03) exists of draft-huitema-multi6-hosts-01 == Outdated reference: A later version (-10) exists of draft-hain-ipv6-pi-addr-use-04 == Outdated reference: A later version (-01) exists of draft-savola-multi6-asn-pi-00 == Outdated reference: A later version (-05) exists of draft-ohta-e2e-multihoming-03 -- No information found for draft-py-mhap-01a - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: October 2003 5 April 2003 7 IPv6 Site Multihoming: Now What? 9 draft-savola-multi6-nowwhat-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices 35 cause a significant increase the routing table size, change rates and 36 instability, the tragedy of the commons by encouraging selfish 37 routing practices, the exhaustion of the 16-bit AS number space, and 38 may collapse the Internet interdomain routing architecture. 40 As there has been a desire to avoid similar problems as seen with 41 IPv4, the use of similar techniques to achieve site multihoming has 42 been prevented operationally in IPv6. However, the long effort to 43 proceed with other IPv6 multihoming mechanisms has produced lots of 44 heat but little light. This memo tries to list available techniques, 45 split the organizations to different types to separately examine 46 their multihoming needs, to look at the immediate and short-term 47 solutions for these organization types, and to list a few immediate 48 action items on how to proceed with IPv6 site multihoming. 50 Table of Contents 52 1. Introduction ............................................... 2 53 2. Site Multihoming Mechanisms ................................ 3 54 3. Classification of Sites and Motivations .................... 4 55 3.1. Classification ......................................... 4 56 3.1.1. Minimal ............................................ 5 57 3.1.2. Small .............................................. 5 58 3.1.3. Large .............................................. 6 59 3.1.4. International ...................................... 6 60 4. Choosing a Multihoming Mechanism ........................... 7 61 4.1. Viable Multihoming Mechanisms .......................... 7 62 4.1.1. Immediate Approaches ............................... 7 63 4.1.2. Short-term Approaches .............................. 7 64 4.1.3. Long Term Approaches ............................... 8 65 4.1.4. Conclusion on Approaches ........................... 8 66 4.2. Applicable Mechanisms for Site Types ................... 8 67 4.2.1. Minimal ............................................ 9 68 4.2.2. Small .............................................. 9 69 4.2.3. Large .............................................. 9 70 4.2.4. International ...................................... 10 71 5. Issues to Be Addressed ..................................... 10 72 6. Acknowledgements ........................................... 11 73 7. Security Considerations .................................... 11 74 8. References ................................................. 11 75 8.1. Normative .............................................. 11 76 8.2. Informative ............................................ 11 77 Author's Address ............................................... 13 78 A. Independence as a Multihoming Reason ....................... 13 79 B. Multi-connecting ........................................... 13 80 Intellectual Property Statement ................................ 14 81 Full Copyright Statement ....................................... 15 83 1. Introduction 85 Currently in IPv4, there seem to be three-four main mechanisms which 86 are used to achieve at least some of the multihoming benefits: 87 obtaining their own address space and AS number and advertising 88 those, advertising more specific routes with a different path, using 89 multi-connecting and leveraging NAT. 91 In IPv6, the first two of IPv4 mechanisms which are considered 92 architecturally unscalable have been operationally prevented for now 93 and the fourth does not exist. 95 IPv6 site multihoming effort has been in progress for many years 96 already, with little light but lots of heat. This memo tries to 97 increase the light, and show a few possible ways how to proceed with 98 site multihoming in a relatively qualitative fashion. 100 First, the multihoming mechanisms which have been proposed and 101 briefly considered are listed for reference; a more detailed 102 description and analysis is omitted [SMULTI]. 104 Then, a classification of sites and their multihoming motivations is 105 presented. This is done to break the "site" and "multihoming" 106 concepts to smaller, digestible pieces. 108 After that, the multihoming mechanisms are classified to immediate, 109 short-term, and long-term approaches; long-term approaches are 110 ignored when describing which techniques might fit for each 111 organization type. 113 Last, some short term issues to be addressed and things to be done, 114 are listed. 116 [V4MULTI] describes IPv4 multihoming properties. The motivations 117 section seems to be missing an important factor, the explicit desire 118 for operator-independence. This is described in Appendix A. 119 Similarly, multi-connecting -- which has typically been considered 120 out of scope -- is briefly described in Appendix B. 122 2. Site Multihoming Mechanisms 124 In [SMULTI], quite a few different site multihoming mechanisms have 125 been briefly described and analyzed: 127 o Transport solutions, including TCP modifications [TCP+] and SCTP 128 [SCTP], 130 o Locator/Identifier separation solutions, including HIP [HIP], 131 LIN6 [LIN6] and Mobile IPv6 [MIPv6]), 133 o Host-centric Multihoming [HC], 135 o Multihoming at Site Exit Routers [SITEEXIT], 137 o Geographic Address Allocation [GEO], 139 o Provider Independent Addressing Derived from AS Numbers [ASNPI], 140 o Multi-connecting (see Appendix B for introduction), and 142 o Other methods, including: Advertising more specific routes 143 [SPECIFIC], Multihoming with route aggregation [RAGGR], End-to- 144 end multihoming [END2END], Traffic steering using routing header, 145 Router renumbering [RR], and MHAP [MHAP]. 147 A degree of familiarity with at least the most important techiques is 148 assumed. The description and further analysis is out of scope. 150 3. Classification of Sites and Motivations 152 The different types of organizations are separated, and their 153 possible motivations explored separately. In this way, it's possible 154 to try to break the big "site" and "multihoming" concepts into 155 smaller pieces. 157 First, a rough classification is presented, and then each of the four 158 types are described at more length. 160 Analysis on which methods could suit each type best are described in 161 the next section. 163 3.1. Classification 165 A table of multihoming motivations and types of sites is created; it 166 is shown in the table below. 168 .--------------.------------.--------------. 169 | Independence | Redundancy | Load sharing | 170 .--------------+--------------+------------+--------------+ 171 |Minimal | no | no | no | 172 |Small | maybe | maybe | no | 173 |Large | maybe/yes | yes | maybe | 174 |International | yes | yes | yes | 175 '--------------'--------------'------------'--------------' 177 Note that the motivations "Performance" and "Policy" [V4MULTI] are 178 not included above: in practice, they do not seem to be prime 179 motivators, and it is difficult to gauge how desirable features they 180 are. 182 The term "IP-users" is used in the classifications below. This is 183 used to loosely refer to those people who have an operational need 184 for Internet access to get their work done. 186 The organizations are classified roughly in four categories: 188 1. Minimal: a very small or restricted end-site, for example a 189 typical home network, or a small office of less than 10 IP- 190 users, 192 2. Small: a small-to-mid-size enterprise, for example with less 193 than 50-150 IP-users, 195 3. Large: a large enterprise, for example a regional or national 196 enterprise of typically less than 1000 IP-users, and 198 4. International: a large or very large enterprise, with a 199 significant amount of international activity. 201 The distinction between the last two comes from the assumption that 202 an international organization is assumed to have major activity in 203 multiple countries or regions: in practice, one with a separate 204 significant Internet connectivity with different ISPs in many areas. 205 Naturally, even smaller organizations are likely to have some 206 relatively minor international activity, but these are not likely 207 counted as International. 209 Now, the reasons and motivations specific to each organization class 210 are described. These give a bit more elaboration on why the 211 categories were written down as they were. 213 3.1.1. Minimal 215 Very minimal end-sites, such as typical home networks or very small 216 enterprises, are quite small and typically do not include mission- 217 critical activities. 219 Naturally, anyone would be willing to achieve multihoming benefits, 220 but usually the associated costs, e.g. caused by obtaining physical 221 connectivity to two ISPs, do not justify it. 223 In the very rare case that some multihoming is required, it can be 224 done using the "Small" model. 226 3.1.2. Small 228 Small end-sites are typically small-to-mid-size enterprises, which 229 operate mainly in one geographical location; branch offices are also 230 possible, but these are typically handled using Virtual Private 231 Networks (VPNs) or similar. 233 Small end-sites typically use the Internet in such a manner that they 234 might find redundancy and independence important, depending on the 235 costs and complexity. However, typically an outage of some minutes 236 or rarely even hours is not yet critical, and due to the size, 237 operator-independence is not vital. 239 3.1.3. Large 241 Large end-sites are typically largish enterprises which operate in 242 one or typically more geographical locations, however, mostly inside 243 a region or a country. Relatively minor international branch offices 244 are possible, but there are no major internal, private interconnects 245 -- physical or link-layer connectivity that does not go through the 246 Internet -- to the offices in other countries. Typically, if there 247 are multiple locations inside a region, there are internal, private 248 interconnects between the locations. 250 Redundancy is very important due to increased size: longer outages 251 are unacceptable for productivity. Also, as the number of the nodes 252 in the site is quite high, the effort of renumbering is also high, 253 and some level of operator independence valuable but not always 254 strictly necessary if significant enough ISPs operate in the area. 255 Only in some relatively rare cases the network capacities or other 256 parameters are exceeded so that some form of load-sharing is 257 required. 259 3.1.4. International 261 International end-sites are typically large or very large enterprises 262 which have significant employment internationally, connect to the 263 Internet with high-speed links in each of these significant locations 264 and may often have internal, private interconnects in place. 266 Typically, ISPs are not global enough to supply connectivity to all 267 the locations, and being locked to scenic routing paths caused by 268 only a few regional ISPs is not considered a serious option. 270 As the international enterprise typically exceeds the geographic and 271 topological scope of any single ISP, and the network is so large, 272 operator independence is considered extremely important. Redundancy 273 is also critical. The required capacities and usage patterns may 274 vary a lot, but often also some form of load sharing is necessary: 275 all the traffic to the end-site cannot go through a single location, 276 and it might not be reasonable either, due to geography. 278 4. Choosing a Multihoming Mechanism 280 In the previous section organizations were split into four main 281 classifications; now it's possible to summarize the mechanisms and 282 see if particular mechanisms could be made to meet the organizations' 283 needs. 285 The first thing to realize is that the scope and breadth of 286 multihoming motivations and requirements vary a lot. It is highly 287 unlikely that an "one size fits all" solution could be found: indeed, 288 it seems fruitless to even try to look for one except possibly in 289 purely research terms. Further, generic solutions are not probable to 290 be found without larger architectural changes. 292 Therefore, by applying some rough classification one can hope to 293 break the problem space into pieces and try to evaluate whether 294 applicable solutions can be found for those pieces. 296 4.1. Viable Multihoming Mechanisms 298 First, it is important to take a look at and analyze different 299 solutions to see which mechanisms could be viable and how they could 300 be positioned. 302 A detailed analysis is omitted from this memo. 304 These are grouped to three categories: immediate, short-, and long- 305 term. The definitions of the latter two are intentionally left 306 vague, but short term solutions should not take more than 1-3 years 307 to implement and deploy, at most. 309 4.1.1. Immediate Approaches 311 Multi-connecting seems to be the only obvious way to work around 312 multihoming problems right now. 314 Host-centric multihoming and multihoming at site exit routers would 315 also be applicable -- to an extent -- immediately, if no ISP would 316 implement ingress filtering. 318 4.1.2. Short-term Approaches 320 Host-centric IPv6 multihoming and multihoming at site-exit routers, 321 fully fleshed out, are both short-term solutions; both still need 322 some work. 324 Provider independent addressing based on AS numbers is a short-term 325 solution; the same applies to advertising more specific routes, if 326 done from specific allocations to make them distinguishable. 328 Parts of multihoming with route aggregation, traffic steering using 329 routing header and router renumbering could be used in the short 330 term, but the mechanisms themselves are not usable. 332 4.1.3. Long Term Approaches 334 All transport solutions are only generally applicable in the long 335 term, if at all. 337 Identifier and locator separation solutions are long-term solutions; 338 HIP the most credible of them all. LIN6 has fundamental issues which 339 does not make it globally deployable. Mobile IPv6, if the address 340 ownership and key management issue could be worked around, could be a 341 short-term solution, a "hack". Architecturally, it seems a bit ill- 342 fit as a long-term solution. 344 Geographic address allocation is a long-term solution if it's 345 considered viable. 347 End-to-end multihoming is a long-term solution; it requires some 348 major changes in thinking, and may be difficult to accept. 350 MHAP is a long-term solution; it moves into an area where most do not 351 want to go architecturally, and it's likely it could not be made to 352 work in practice. 354 4.1.4. Conclusion on Approaches 356 In the following analysis, none of the long-term approaches are 357 seriously considered; they all need much more work to be adoptable. 359 Of the long-term solutions, it seems likely that at least identifier 360 and locator solutions will prevail in some form or another. However, 361 they do not solve the whole multihoming problem themselves. 363 4.2. Applicable Mechanisms for Site Types 365 Now, the mechanisms outlined in the multihoming analysis and 366 considered viable, above, are applied to the rough end-site 367 organization categories above. 369 4.2.1. Minimal 371 Minimal end-sites do not seem to require a multihoming mechanism. Of 372 course, some would still find one preferable. 374 If they would, one building on "host-centric multihoming" approach 375 would seem sufficient; this might not even be all too expensive using 376 e.g. multiple xDSL connections. 378 4.2.2. Small 380 Small end-sites might find a multihoming mechanism desirable for 381 redundancy and independence reasons. 383 The possible approaches are three-fold: 385 o multi-connecting to one ISP, if redundancy is important, 387 o host-centric multihoming, if independence is important, or 389 o multihoming at site exit routers, if both are important. 391 Multi-connecting or multihoming at site exit routers provide a very 392 extensive amount of redundancy and convergence; independence is 393 obtained by connecting to multiple ISPs and deploying IP addresses 394 from those, which would make the renumbering much less of a problem 395 if it had to be done. 397 Solving the multihoming problem of small end-sites with an approach 398 like "ASN-PI" or more specific routes is unscalable. 400 4.2.3. Large 402 Large end-sites typically require redundancy and possibly 403 independence, sometimes desiring load sharing as well. 405 Often, the same mechanisms applied to small end-sites will also 406 provide the sufficient level of redundancy and independence for also 407 large end-sites. 409 One might be able to handle the scalability issues associated with 410 approaches like "ASN-PI" with large end-sites, but such mechanisms 411 should be avoided. 413 4.2.4. International 415 International end-sites typically require redundancy, independence, 416 and load sharing. 418 As their geographical scope typically exceed ISPs', assigning 419 addresses from multiple ISPs, as with previous approaches, would lead 420 to suboptimal routing. 422 One approach would be to depend on a change of the IP addressing and 423 routing model: each significant international part of the 424 organization would obtain separate IP address assignments from the 425 local ISPs, and use an appropriate multihoming mechanism with that -- 426 probably like with large end-sites above -- and interconnect the 427 offices using mechanisms like VPN's; not even trying to obtain a 428 homogeneous address space for all of the company. 430 This would be a "divide-and-conquer" approach to the problem: break 431 it to smaller pieces and solve them independently. 433 If this approach can't be adopted, it seems the only realistic model 434 would be to use something like "ASN-PI", more specific routes or 435 separate address allocations, or similar. 437 5. Issues to Be Addressed 439 Now, a few relatively short-term action items are presented which 440 should be done as soon as possible. 442 o Update and finish documenting IPv4 multihoming practices 443 [V4MULTI], 445 o Further than that, try to gain a better understanding why certain 446 multihoming mechanisms are used with IPv4, 448 o Finish documenting the IPv6 multihoming goals [GOALS], 450 o Realize that certain problems like connection survivability may 451 not be strict requirements in all cases of site multihoming, and 452 that such problems could be worked around. 454 o Create a roadmap on how to proceed with multihoming solutions, 456 o Work on short-term solutions, in particular, fix [SITEEXIT] and 457 [HC] in the case that ISPs use ingress filtering and consider the 458 case when uplink MTU is not higher than the one used within the 459 site when using [SITEEXIT], 461 o Work on procedures to ensure the separation -- who is 462 "privileged" for which solution -- between different site types 463 and multihoming methods, if different techniques are necessary, 464 and 466 o Start documenting how to do renumbering, and how to make 467 renumbering easier; the renumbering doesn't have to work 468 perfectly or even well, as long as it is satisfactory for some 469 uses. 471 6. Acknowledgements 473 Most of the ideas on how to proceed originated in 2002 and in the 474 beginning of 2003. The ideas on how to proceed were discussed prior 475 to IETF56 in March 2003 with Tim Chown and Kurt Erik Lindqvist. 477 7. Security Considerations 479 This memo summarizes issues in IPv6 site multihoming and gives ideas 480 on the way forward. Many multihoming techniques have security 481 considerations which are not to be forgotten; they should be dealt 482 with in the respective specifications and remembered when analyzing 483 their applicability. Security is also an integral issue to consider 484 when considering the overall site multihoming landscape. However, in 485 itself, this memo does not present any security considerations. 487 8. References 489 8.1. Normative 491 [V4MULTI] Abley, J., Black, B., and Gill, V., "IPv4 Multihoming 492 Motivation, Practices and Limitations", 493 draft-ietf-multi6-v4-multihoming-00, expired, Jun 2001. 495 [GOALS] Abley, J., Black, B., and Gill, V., "Goals for IPv6 496 Site-Multihoming Architectures", draft-ietf-multi6- 497 multihoming-requirements-05.txt, work-in-progress, 498 Apr 2003. 500 8.2. Informative 502 [SMULTI] Savola, P., "Examining Site Multihoming in Finnish 503 Networks", MSc Thesis, http://staff.csc.fi/psavola/di.ps, 504 Apr 2003. 506 [TCP+] Tattam, P., "Preserving Active TCP sessions on Multihomed 507 IPv6 Networks", http://jazz-1.trumpet.com.au/ipv6-draft/ 508 preserve-tcp.txt, Aug 2001. 510 [SCTP] Coene, L. (ed.), "Multihoming issues in the Stream 511 Control Transmission Protocol", draft-coene-sctp- 512 multihome-03.txt, work-in-progress, Feb 2002. 514 [HIP] Moskowitz, R., "The Host Identity Payload Homepage", 515 http://homebase.htt-consult.com/HIP.html. 517 [LIN6] Tereoka, F., et al., "LIN6: A Solution to Mobility and 518 Multi-Homing in IPv6", draft-teraoka-ipng-lin6-01.txt, 519 expired, Aug 2001. 521 [MIPV6] Johnson, D., et al., "Mobility Support in IPv6", 522 work-in-progress, Feb 2003. 524 [HC] Huitema, C., Draves, R., "Host-Centric IPv6 Multihoming", 525 draft-huitema-multi6-hosts-01.txt, expired, Jun 2002. 527 [SITEEXIT] Hagino, J., Snyder, H., "IPv6 Multihoming Support at 528 Site Exit Routers", RFC3178, Oct 2001. 530 [GEO] Hain, T., "Application and Use of the IPv6 Provider 531 Independent Global Unicast Address Format", draft-hain- 532 ipv6-pi-addr-use-04.txt, work-in-progress, Apr 2003. 534 [ASNPI] Savola, P., "Multihoming Using IPv6 Addressing Derived 535 from AS Numbers", draft-savola-multi6-asn-pi-00.txt, 536 work-in-progress, Jan 2003. 538 [SPECIFIC] Lindqvist, K., "Multihoming in IPv6 by Multiple 539 Announcements of Longer Prefixes", 540 draft-kurtis-multihoming-longprefix-00.txt, 541 work-in-progress, Dec 2002. 543 [RAGGR] Yu, J., "IPv6 Multihoming with Route Aggregation", 544 draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt, 545 expired, Aug 2000. 547 [END2END] Ohta, M., "The Architecture of End to End 548 Multihoming", draft-ohta-e2e-multihoming-03.txt, 549 work-in-progress, Nov 2002. 551 [RR] Crawford, M., "Router Renumbering for IPv6", RFC2894, 552 Aug 2000. 554 [MHAP] Py, M., "Multi Homing Aliasing Protocol", 555 draft-py-mhap-01a.txt, expired, Apr 2002. 557 Author's Address 559 Pekka Savola 560 CSC/FUNET 561 Espoo, Finland 562 EMail: psavola@funet.fi 564 A. Independence as a Multihoming Reason 566 This is an excerpt from [SMULTI]. 568 Technical reasons for independence are mostly covered under 569 redundancy; independence here focuses on economic, political and 570 administrative perspectives. 572 Multihoming, especially with your own addresses can bring the 573 organization some degree of provider independence. If the 574 organization can just change its ISP's with minimal effort, one 575 undoubtedly has a better standing in the service agreement 576 negotiations, e.g. being able to get a cheaper price and requested 577 service agreement duration. ISP's could also just disappear, but in 578 most cases services usually continue uninterrupted in the event of 579 bankruptcy, mergers, etc. Also, especially some larger organizations 580 consider it important to stand on their own, so that they can't be 581 seen to depend on others. 583 An important factor for many, especially bigger sites, is also that 584 the renumbering in the event of a network service provider change is 585 considered too difficult and time-consuming, and it is desirable to 586 find mechanisms which do not require that; such feature is provided 587 by independence. 589 B. Multi-connecting 591 This is an excerpt from [SMULTI]. 593 Multi-connecting means connecting multiple times to a single ISP. By 594 some definition [V4MULTI], multi-connecting is not considered a 595 multihoming mechanism. However, it still deserves a brief 596 description. 598 Multi-connecting is typically achieved by having multiple site border 599 routers and connecting each of them to separate routers at the ISP, 600 usually in different locations. 602 Often, a routing protocol is run between the site and the ISP, to be 603 able to quickly detect errors in the connectivity and to switch to 604 alternative paths. Routing protocol used is often BGP with private 605 AS numbers. 607 Sometimes, typically when the ISP is also in charge of the management 608 of site border routers, some other protocols such as OSPF or IS-IS 609 are also possible -- this often requires strict filtering of 610 advertisements at the ISP end, to prevent compromising the ISP's core 611 routing system. In some cases, simply static routes may also be 612 possible; typically this requires a link-layer medium which provides 613 notifications if the end-to-end link-layer path becomes 614 nonoperational. 616 Multi-connection is a flexible mechanism and relatively easy to 617 accomplish: it requires no coordination between ISPs, no address 618 applications for provider independent address space, no AS number 619 applications for BGP AS numbers or the like. Yet it provides 620 protection from the most common set of problems. 622 If one link fails, the changes do not need to be propagated further 623 than the ISP; therefore, this is a very scalable approach when 624 considering the global routing table. 626 Intellectual Property Statement 628 The IETF takes no position regarding the validity or scope of any 629 intellectual property or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; neither does it represent that it 633 has made any effort to identify any such rights. Information on the 634 IETF's procedures with respect to rights in standards-track and 635 standards-related documentation can be found in BCP-11. Copies of 636 claims of rights made available for publication and any assurances of 637 licenses to be made available, or the result of an attempt made to 638 obtain a general license or permission for the use of such 639 proprietary rights by implementors or users of this specification can 640 be obtained from the IETF Secretariat. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights which may cover technology that may be required to practice 645 this standard. Please address the information to the IETF Executive 646 Director. 648 Full Copyright Statement 650 Copyright (C) The Internet Society (2003). All Rights Reserved. 652 This document and translations of it may be copied and furnished to 653 others, and derivative works that comment on or otherwise explain it 654 or assist in its implementation may be prepared, copied, published 655 and distributed, in whole or in part, without restriction of any 656 kind, provided that the above copyright notice and this paragraph are 657 included on all such copies and derivative works. However, this 658 document itself may not be modified in any way, such as by removing 659 the copyright notice or references to the Internet Society or other 660 Internet organizations, except as needed for the purpose of 661 developing Internet standards in which case the procedures for 662 copyrights defined in the Internet Standards process must be 663 followed, or as required to translate it into languages other than 664 English. 666 The limited permissions granted above are perpetual and will not be 667 revoked by the Internet Society or its successors or assignees. 669 This document and the information contained herein is provided on an 670 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 671 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 672 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 673 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 674 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 676 Acknowledgement 678 Funding for the RFC Editor function is currently provided by the 679 Internet Society.