idnits 2.17.1 draft-ietf-multi6-v4-multihoming-02.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 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 399. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 14) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 172 has weird spacing: '...Another possi...' == Line 256 has weird spacing: '...gestion contr...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2004) is 7102 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '1') (Obsoleted by RFC 4632) == Outdated reference: A later version (-01) exists of draft-ietf-multi6-things-to-think-about-00 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Site Multihoming in IPv6 (multi6) J. Abley 2 Internet-Draft Internet Systems Consortium, Inc. 3 Expires: April 17, 2005 B. Black 4 Layer8 Networks 5 V. Gill 6 AOL 7 K. Lindqvist 8 Netnod Internet Exchange 9 October 17, 2004 11 IPv4 Multihoming Motivation, Practices and Limitations 12 draft-ietf-multi6-v4-multihoming-02 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 17, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 Multihoming is an essential component of service for sites which are 48 part of the Internet. This draft describes some of the motivations, 49 practices and limitations of multihoming as it is achieved in the 50 IPv4 world today. The analysis is done in order to serve as 51 underlaying documentation to the discussions in the "Site multihoming 52 for IPv6" working group of the IETF, who are working to a longer term 53 solution to some of the issues that arise from doing multihoming in 54 the ways as are described here. 56 1. Introduction 58 Multihoming is an important component of service for many sites which 59 are part of the Internet. Current IPv4 multihoming practices have 60 been added on to the CIDR architecture [1], which assumes that 61 routing table entries can be aggregated based upon a hierarchy of 62 customers and service providers. 64 Multihoming is a mechanism by which sites can currently satisfy a 65 number of high-level requirements, and is widely used in the IPv4 66 network today. There are some practical limitations, however, 67 including concerns of how well (or, if) the current practice will 68 scale as the network continues to grow. 70 The preferred way to multihome in IPv4 is to announce an independent 71 block of address space over two or more ISPs using BGP. Until the 72 mid-1990s this was relatively easy to accomplish, as the maximum 73 generally accepted prefix length in the global routing table was a 74 /24, and little justification was needed to receive a /24. However, 75 RIR policies today do not generally support the assignment of 76 netblocks to small multi-homed end-users (e.g. those who might only 77 be able to justify a /24 assignment), and as a consequence 78 provider-independent (PI) space is not available to many sites who 79 wish to multi-home. 81 An alternative way to multihome in IPv4 is to get address space 82 allocated to the site from a upstream service provider. The site can 83 then subscribe to a second Internet connection from a second service 84 provider, and ask that the second service provider either announce or 85 accept the announcement over BGP of the address block allocated to 86 the site from the first service provider. 88 This second practice has two advantages and two disadvantages for the 89 multihomed site, as well for the Internet at large. The first 90 advantage is that this practice is applicable to sites whose 91 addressing requirements are not sufficient to meet the requirements 92 for PI assignments by RIRs. The second advantage is that even if the 93 more specific announcement is filtered, they are still reachable 94 over the primary ISP by virtue of the aggregate announced by this 95 ISP. Even when the circuit to the primary ISP is down, this often 96 works because the primary ISP will generally accept the announcement 97 over the secondary ISP, so traffic flows from the filtering network 98 to the primary ISP and then to the secondary ISP in order to arrive 99 at the multihomed network. While this is common, it is also not 100 universally true. 102 The first disadvantage with this approach is that the multihomed 103 network must depend on the primary ISP for the aggregate. If the 104 primary ISP goes down, this will impact reachability to networks that 105 filter. Most ISPs will cooperate with this "punching holes in an 106 aggregate" solution to multihoming, but some are reluctant. And when 107 the multihomed network leaves the primary ISP, they are generally 108 expected to return the address space because otherwise this ISP would 109 have to route traffic for a non-customer. The second disadvantage 110 with the approach of announcing more specific routes out of a PA 111 block, is that if the site were to change service provider away from 112 the provider that has allocated the PA block, they will have to 113 renumber. It is worth noting that the site can change all the other 114 service providers without having to renumber. 116 2. Terminology 118 A "site" is an entity autonomously operating a network using IP, and 119 in particular, determining the addressing plan and routing policy for 120 that network. This definition is intended to be equivalent to 121 "enterprise" as defined in [2]. 123 A "transit provider" operates a site that directly provides 124 connectivity to the Internet to one or more external sites. The 125 connectivity provided extends beyond the transit provider's own site. 126 A transit provider's site is directly connected to the sites for 127 which it provides transit. 129 A "multihomed" site is one with more than one transit provider. 130 "Site-multihoming" is the practice of arranging a site to be 131 multihomed. 133 The term "re-homing" denotes a transition of a site between two 134 states of connectedness due to a change in the connectivity between 135 the site and its transit providers' sites. 137 A "multi-attached" site is one with more than one point of layer-3 138 interconnection to a single transit provider. 140 3. Motivations for Multihoming 142 There exists a great wealth of reasons why any single person or 143 entity would like to multihome their network, in one way or the 144 other. The reasons for doing this, are to achieve one or more of the 145 goals as outlined in [5]. A more detailed analysis of the reasoning 146 behind multihoming configurations are considered out-of-scope for 147 this document. 149 4. Current methods used for IPv4 multihoming 151 There are a number of ways that a site which wishes to become 152 multihomed can achieve its objectives today using IPv4. These 153 methods can broadly be split into five categories as described below. 155 4.1 Multihoming with PI addresses and AS 157 The site uses provider-independent (PI) addresses assigned by an RIR. 158 The routes corresponding to the PI addresses are announced with an 159 origin AS associated with the multi-homed site to two or more transit 160 providers. 162 4.2 Multihoming with your own AS, but PA addresses 164 The site uses provider-aggregatable (PA) addresses assigned by one 165 transit provider. The routes corresponding to those PA addresses are 166 announced with an origin AS associated with the multi-homed site to 167 two or more transit providers. One of those transit providers 168 originates a covering supernet for the site's routes. 170 4.3 Multihoming with your own addresses, and private AS 172 Another possible way of multihoming is with addresses owned by the 173 site wishing to multihome, but advertising them without having a 174 public AS, or with no AS at all. This is done with the site either 175 sourcing the prefixes in a private AS [3], and having their upstreams 176 remove those on announcement to the rest of the world, or the 177 upstreams simply sourcing the prefixes in their AS and then routing 178 to the organization. 180 4.4 Multiple attachments to the same ISP 182 Fourth option is to have multiple connection to the same ISP. This 183 is fairly popular, but will not have an impact on the global routing 184 table as both paths are covered by the ISPs aggregate route. A site 185 that have solved their multihoming needs in this way is commonly 186 referred to as "multi-attached". 188 4.5 NAT or RFC2260 based multihoming 190 This last method might very well be the most commonly used method in 191 terms of volume. Simply because this is what most residential users 192 are normally referred to. However, this method is also in use by 193 very large enterprises, as this is an easy way for large enterprise 194 networks to avoid advertising multiple prefixes when they connect at 195 multiple locations. 197 This method uses addresses from each of the upstream that an 198 organization is connected to. Either the addresses are allocated to 199 nodes inside the network according to the proposal in [4], or the 200 site uses NAT to translate into private addresses inside the site. 202 5. Features of IPv4 Multihoming 204 The following section analyzes some of the features driving the 205 choices for various multihoming approaches in todays IPv4 Internet. 206 As the "Site multihoming for IPv6" working group progresses, they 207 will have to take similar considerations into account, learning from 208 IPv4. These considerations are listed in [5], and some of the 209 operational considerations that needs to be thought of for new 210 multihoming mechanisms can be found in [6]. Not all approaches 211 described in this document will support all the features listed 212 below. Particularly solutions based on RFC2260/NAT [4] based designs 213 will support a significantly smaller subset of these features. 215 5.1 Simplicity 217 The current methods used as multihoming solutions are not all without 218 complexity, but in practice it is quite straightforward to deploy and 219 maintain by virtue of the fact that they are well-known, tried and 220 tested. 222 5.2 Transport-Layer Survivability 224 The current multihoming solution provides session survivability for 225 transport-layer protocols in most cases; i.e. exchange of data 226 between devices on the multi-homed site network and devices elsewhere 227 on the Internet may proceed with no greater interruption than that 228 associated with the transient packet loss during a re-homing event. 229 However, there are cases where the current multihoming solutions does 230 not provide transport-layer survivability. One example is that due 231 to the large number of ASes in the current Internet routing table, 232 BGP convergence take longer and longer and the transport-layer might 233 time-out while waiting for BGP to converge. There are also BGP 234 implementations in wide use that will take a long time for failure 235 detection and that might cause TCP timeouts. 237 In the case a re-homing event occurs, new transport-layer sessions 238 are able to be created. 240 5.3 Inter-Provider Traffic Engineering 242 A multi-homed site may influence routing decisions beyond its 243 immediate transit providers by advertising a strategic mixture of 244 carefully-aimed long prefixes and covering shorter-prefix routes. 245 This precise effects of such egress policy are often difficult to 246 predict, but an approximation of the desired objective is often easy 247 to accomplish. 249 5.4 Load Control 251 The current multihoming solution places control of traffic flow in 252 the hands of the site responsible for the multi-homed 253 interconnections with transit providers. A single-homed client a 254 multi-homed site may vary the demand for traffic that they impose on 255 the site, and may influence differential traffic load between transit 256 providers; however, the basic mechanisms for congestion control and 257 route propagation are in the hands of the site, not the client. 259 5.5 Impact on Routers 261 The routers at the boundary of a multi-homed site are usually 262 required to participate in BGP sessions with the interconnected 263 routers of transit providers. Other routers within the site have no 264 special requirements beyond those of single-homed site routers. 266 5.6 Impact on Hosts 268 There are no requirements of hosts beyond those of single-homed sites 269 hosts. 271 5.7 Interactions between Hosts and the Routing System 273 There are no requirements for interaction between routers and hosts 274 beyond those of single-homed site routers and hosts. 276 6. Limitations of IPv4 Multihoming 278 6.1 Scalability 280 Current IPv4 multihoming practices contribute to the significant 281 growth currently observed in the state held in the global 282 inter-provider routing system; this is a concern both because of the 283 hardware requirements it imposes and also because of the impact on 284 the stability of the routing system. 286 The only method described in this document that doesn't add to the 287 growth of state in the global inter-provider routing system is the 288 RFC2260/NAT based method. The use of this method might explains the 289 relatively higher growth in multihomed sites, compared to the growth 290 of the state in the global inter-provider routing system. 292 These mechanisms also add to the consumption of public AS number 293 resources, when small site wishing to multihome obtain an AS number 294 specifically for only that purpose. Using a different mechanism 295 would help to conserve the 16-bit AS number space, and avoid the move 296 to 32-bit AS numbers. 298 This issue is discussed in great detail in [7]. 300 7. Security Considerations 302 This memo analyzes the IPv4 multihoming practices. This analysis 303 only includes the description of the mechanisms and partially how 304 they affect the availability of the site deploying the IPv4 305 multihoming mechanism. Other security properties of the IPv4 306 multihoming mechanisms are not analyzed. 308 8. IANA Considerations 310 This document requests no action by IANA. 312 9. Acknowledgements 314 Thanks goes to Pekka Savola and Iljitsch van Beijnum for providing 315 feedback and suggestions on the text as well as text. 317 10 Informative references 319 [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 320 Inter-Domain Routing (CIDR): an Address Assignment and 321 Aggregation Strategy", RFC 1519, September 1993. 323 [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. 324 Lear, "Address Allocation for Private Internets", RFC 1918, 325 February 1996. 327 [3] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, 328 and registration of an Autonomous System (AS)", RFC 1930, March 329 1996. 331 [4] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed 332 Multi-provider Connectivity", RFC 2260, January 1998. 334 [5] Black, B., Gill, V. and J. Abley, "Goals for IP Multihoming 335 Architectures", RFC 3582, August 2003. 337 [6] Lear, E., "Things MULTI6 Developers should think about", 338 Internet-Drafts draft-ietf-multi6-things-to-think-about-00, June 339 2004. 341 [7] Huston, G., "Analyzing the Internet's BGP Routing Table", 342 January 2001. 344 Authors' Addresses 346 Joe Abley 347 Internet Systems Consortium, Inc. 348 950 Charter Street 349 Redwood City, CA 94063 350 USA 352 Phone: +1 650 423 1317 353 EMail: jabley@isc.org 354 Benjamin Black 355 Layer8 Networks 357 EMail: ben@layer8.net 359 Vijay Gill 360 AOL 361 12100 Sunrise Valley Dr 362 Reston, VA 20191 363 US 365 Phone: +1 410 336 4796 366 EMail: vgill@vijaygill.com 368 Kurt Erik Lindqvist 369 Netnod Internet Exchange 370 Bellmansgatan 30 371 Stockholm S-118 47 372 Sweden 374 Phone: +46 8 615 85 70 375 EMail: kurtis@kurtis.pp.se 377 Intellectual Property Statement 379 The IETF takes no position regarding the validity or scope of any 380 Intellectual Property Rights or other rights that might be claimed to 381 pertain to the implementation or use of the technology described in 382 this document or the extent to which any license under such rights 383 might or might not be available; nor does it represent that it has 384 made any independent effort to identify any such rights. Information 385 on the procedures with respect to rights in RFC documents can be 386 found in BCP 78 and BCP 79. 388 Copies of IPR disclosures made to the IETF Secretariat and any 389 assurances of licenses to be made available, or the result of an 390 attempt made to obtain a general license or permission for the use of 391 such proprietary rights by implementers or users of this 392 specification can be obtained from the IETF on-line IPR repository at 393 http://www.ietf.org/ipr. 395 The IETF invites any interested party to bring to its attention any 396 copyrights, patents or patent applications, or other proprietary 397 rights that may cover technology that may be required to implement 398 this standard. Please address the information to the IETF at 399 ietf-ipr@ietf.org. 401 Disclaimer of Validity 403 This document and the information contained herein are provided on an 404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 406 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 407 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 408 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Copyright Statement 413 Copyright (C) The Internet Society (2004). This document is subject 414 to the rights, licenses and restrictions contained in BCP 78, and 415 except as set forth therein, the authors retain all their rights. 417 Acknowledgment 419 Funding for the RFC Editor function is currently provided by the 420 Internet Society.