From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4116.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc4116.txt (limited to 'doc/rfc/rfc4116.txt') diff --git a/doc/rfc/rfc4116.txt b/doc/rfc/rfc4116.txt new file mode 100644 index 0000000..e30b8ec --- /dev/null +++ b/doc/rfc/rfc4116.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group J. Abley +Request for Comments: 4116 ISC +Category: Informational K. Lindqvist + Netnod Internet Exchange + E. Davies + Independent Researcher + B. Black + Layer8 Networks + V. Gill + AOL + July 2005 + + + IPv4 Multihoming Practices and Limitations + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Multihoming is an essential component of service for many Internet + sites. This document describes some implementation strategies for + multihoming with IPv4 and enumerates features for comparison with + other multihoming proposals (particularly those related to IPv6). + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 1] + +RFC 4116 IPv4 Multihoming July 2005 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. IPv4 Multihoming Practices ......................................4 + 3.1. Multihoming with BGP .......................................4 + 3.1.1. Addressing Considerations ...........................4 + 3.1.2. AS Number Considerations ............................6 + 3.2. Multiple Attachments to a Single Transit Provider ..........6 + 3.3. NAT- or RFC2260-based Multihoming ..........................7 + 4. Features of IPv4 Multihoming ....................................7 + 4.1. Redundancy .................................................7 + 4.2. Load Sharing ...............................................8 + 4.3. Performance ................................................8 + 4.4. Policy .....................................................8 + 4.5. Simplicity .................................................9 + 4.6. Transport-Layer Survivability ..............................9 + 4.7. Impact on DNS ..............................................9 + 4.8. Packet Filtering ...........................................9 + 4.9. Scalability ................................................9 + 4.10. Impact on Routers ........................................10 + 4.11. Impact on Hosts ..........................................10 + 4.12. Interactions between Hosts and the Routing System ........10 + 4.13. Operations and Management ................................10 + 4.14. Cooperation between Transit Providers ....................10 + 5. Security Considerations ........................................10 + 6. Acknowledgements ...............................................10 + 7. Informative References .........................................11 + + + + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 2] + +RFC 4116 IPv4 Multihoming July 2005 + + +1. Introduction + + Multihoming is an important component of service for many Internet + sites. Current IPv4 multihoming practices have been added on to the + Classless Inter Domain Routing (CIDR) architecture [RFC1519], which + assumes that routing table entries can be aggregated based upon a + hierarchy of customers and service providers. + + Multihoming is a mechanism by which sites can satisfy a number of + high-level requirements. It is widely used in the IPv4 Internet. + There are some practical limitations, however, including concerns as + to how it would scale with future Internet growth. This document + aims to document common IPv4 multihoming practices and enumerate + their features for comparison with other multihoming approaches. + + There are a number of different ways to route and manage traffic in + and out of a multihomed site: the majority rely on the routing policy + capabilities of the inter-domain routing protocol, the Border Gateway + Protocol, version 4 (BGP) [RFC1771]. This document also discusses a + multi-homing strategy which does not rely on the capabilities of BGP. + +2. Terminology + + A "site" is an entity autonomously operating a network using IP, and + in particular, determining the addressing plan and routing policy for + that network. This definition is intended to be equivalent to + 'enterprise' as defined in [RFC1918]. + + A "transit provider" operates a site that directly provides + connectivity to the Internet to one or more external sites. The + connectivity provided extends beyond the transit provider's own site + and its own direct customer networks. A transit provider's site is + directly connected to the sites for which it provides transit. + + A "multihomed" site is one with more than one transit provider. + "Site-multihoming" is the practice of arranging a site to be + multihomed. + + The term "re-homing" denotes a transition of a site between two + states of connectedness, due to a change in the connectivity between + the site and its transit providers' sites. + + A "multi-attached" site has more than one point of layer-3 + interconnection to a single transit provider. + + Provider-Independent (PI) addresses are globally-unique addresses + which are not assigned by a transit provider, but are provided by + some other organisation, usually a Regional Internet Registry (RIR). + + + +Abley, et al. Informational [Page 3] + +RFC 4116 IPv4 Multihoming July 2005 + + + Provider-Aggregatable (PA) addresses are globally-unique addresses + assigned by a transit provider to a customer. The addresses are + considered "aggregatable" because the set of routes corresponding to + the PA addresses are usually covered by an aggregate route set + corresponding to the address space operated by the transit provider, + from which the assignment was made. + + Note that the words "assign" and "allocate" have specific meanings in + Regional Internet Registry (RIR) address management policies, but are + used more loosely in this document. + +3. IPv4 Multihoming Practices + +3.1. Multihoming with BGP + + The general approach for multihoming with BGP is to announce a set of + routes to two or more transit providers. This provides the rest of + the Internet with multiple paths back to the multihomed sites, and + each transit provider provides an additional possible path for the + site's outbound traffic. + +3.1.1. Addressing Considerations + +3.1.1.1. PI Addresses + + The site uses PI addresses, and a set of routes covering those PI + addresses is announced or propagated by two or more transit + providers. + + Using PI addresses has long been the preferred approach for IPv4 + multihoming. Until the mid-1990s this was relatively easy to + accomplish, as the maximum generally accepted prefix length in the + global routing table was a /24, and little justification was needed + to obtain a /24 PI assignment. Since then, RIR address management + policies have become less liberal in this respect. Not all RIRs + support the assignment of address blocks to small, multihomed end- + users, and those that do support it require justification for blocks + as large as a /24, which cannot be met by small sites. As a + consequence, PI addresses are not available to many sites who wish to + multihome. + + Each site that uses PI addresses introduces an additional prefix into + the global routing system. If this scheme for multihoming became + widespread, it would present scaling concerns. + + + + + + + +Abley, et al. Informational [Page 4] + +RFC 4116 IPv4 Multihoming July 2005 + + +3.1.1.2. PA Addresses + + The site uses PA addresses assigned by a single transit provider. + The set of routes covering those PA addresses (the "site route set") + is announced or propagated by one or more additional transit + providers. The transit provider which assigned the PA addresses (the + "primary transit provider") originates a set of routes which cover + the site route set. The primary transit provider often originates or + propagates the site route set as well as the covering aggregates. + + The use of PA addresses is applicable to sites whose addressing + requirements are not sufficient to meet the requirements for PI + assignments by RIRs. However, in the case where the site route set + is to be announced or propagated by two or more different transit + providers, common operational practice still dictates minimum /24 + prefixes, which may be larger than the allocation available to small + sites. + + There have been well-documented examples of sites filtering long- + prefix routes which are covered by a transit-providers aggregate. If + this practice were to become very widespread, it might limit the + effectiveness of multihoming using PA addresses. However, limited + filtering of this kind can be tolerated because the aggregate + announcements of the primary transit provider should be sufficient to + attract traffic from autonomous systems which do not accept the + covered site route set. The more traffic that follows the primary + transit provider's aggregate in the absence of the covered, more- + specific route, the greater the reliance on that primary transit + provider. In some cases, this reliance might result in an effective + single point of failure. + + Traffic following the primary transit provider's aggregate routes may + still be able to reach the multihomed site, even in the case where + the connection between the primary transit provider and the site has + failed. The site route set will still be propagating through the + site's other transit providers. If that route set reaches (and is + accepted by) the primary transit provider, connectivity for traffic + following the aggregate route will be preserved. + + Sites that use PA addresses are usually obliged to renumber if they + decide not to retain connectivity to the primary transit provider. + While this is a common requirement for all sites using PA addresses + (and not just those that are multihomed), it is one that may have + more frequent impact on sites whose motivation to multihome is to + facilitate changes of ISP. A multihomed site using PA addresses can + still add or drop other service providers without having to renumber. + + + + + +Abley, et al. Informational [Page 5] + +RFC 4116 IPv4 Multihoming July 2005 + + +3.1.2. AS Number Considerations + +3.1.2.1. Consistent Origin AS + + A multihomed site may choose to announce routes to two or more + transit providers from a globally-unique Autonomous System (AS) + number assigned to the site. This causes the origin of the route to + appear consistent when viewed from all parts of the Internet. + +3.1.2.2. Inconsistent Origin AS + + A multihomed site may choose to use a private-use AS number [RFC1930] + to originate routes to transit providers. It is normal practice for + private-use AS numbers to be stripped from AS_PATH attributes before + they are allowed to propagate from transit providers towards peers. + Therefore, routes observed from other parts of the Internet may + appear to have inconsistent origins. + + When using private-use AS numbers, collisions between the use of + individual numbers by different transit providers are possible. + These collisions are arguably best avoided by not using private-use + AS numbers for applications which involve routing across + administrative domain boundaries. + + A multihomed site may request that their transit providers each + originate the site's routes from the transit providers' ASes. + Dynamic routing (for the purposes of withdrawing the site's route in + the event that connectivity to the site is lost) is still possible, + in this case, using the transit providers' internal routing systems + to trigger the externally-visible announcements. + + Operational troubleshooting is facilitated by the use of a consistent + origin AS. This allows import policies to be based on a route's true + origin rather than on intermediate routing details, which may change + (e.g., as transit providers are added and dropped by the multihomed + site). + +3.2. Multiple Attachments to a Single Transit Provider + + Multihoming can be achieved through multiple connections to a single + transit provider. This imposes no additional load on the global + routing table beyond that involved in the site being single-attached. + A site that has solved its multihoming needs in this way is commonly + referred to as "multi-attached". + + + + + + + +Abley, et al. Informational [Page 6] + +RFC 4116 IPv4 Multihoming July 2005 + + + It is not a requirement that the multi-attached site exchange routing + information with its transit provider using BGP. However, in the + event of failure, some mechanism for re-routing inbound and outbound + traffic over remaining circuits is required. BGP is often used for + this purpose. + + Multi-attached sites gain no advantages from using PI addresses or + (where BGP is used) globally-unique AS numbers, and have no need to + be able to justify address assignments of a particular minimum size. + However, multi-attachment does not protect a site from the failure of + the single transit provider. + +3.3. NAT- or RFC2260-based Multihoming + + This method uses PA addresses assigned by each transit provider to + which the site is connected. The addresses are either allocated to + individual hosts within the network according to [RFC2260], or the + site uses Network Address Translation (NAT) to translate the various + provider addresses into a single set of private-use addresses + [RFC1918] within the site. The site is effectively singlehomed to + more than one transit provider. None of the transit providers need + to make any accommodations beyond those typically made for a non- + multihomed customer. + + This approach accommodates a wide range of sites, from residential + Internet users to very large enterprises, requires no PI addresses or + AS numbers, and imposes no additional load on the Internet's global + routing system. However, it does not address several common + motivations for multihoming, most notably transport-layer + survivability. + +4. Features of IPv4 Multihoming + + The following sections describe some of the features of the + approaches described in Section 3, in the context of the general + goals for multihoming architectures presented in [RFC3582]. Detailed + descriptions and rationale for these goals can be found in that + document. + +4.1. Redundancy + + All the methods described provide redundancy, which can protect a + site from some single-point failures. The degree of protection + depends on the choice of transit providers and the methods used to + interconnect the site to those transit providers. + + + + + + +Abley, et al. Informational [Page 7] + +RFC 4116 IPv4 Multihoming July 2005 + + +4.2. Load Sharing + + All of the methods described provide some measure of load-sharing + capability. Outbound traffic can be shared across ISPs using + appropriate exit selection policies; inbound traffic can be + distributed using appropriate export policies designed to influence + the exit selection of remote sites sending traffic back towards the + multihomed site. + + In the case of RFC2260/NAT multihoming, distribution of inbound + traffic is controlled by address selection on the host or NAT. + +4.3. Performance + + BGP-speaking sites can employ import policies that cause exit + selection to avoid paths known to be problematic. For inbound + traffic, sites can often employ route export policy, which affords + different treatment of traffic towards particular address ranges + within their network. + + It should be noted that this is not a comprehensive capability. In + general, there are many traffic engineering goals which can only be + loosely approximated using this approach. + + In the case of RFC2260/NAT multihoming in the absence of BGP routing + information, management of outbound traffic is not possible. The + path taken by inbound traffic for a particular session can be + controlled by source address selection on the host or NAT. + +4.4. Policy + + In some circumstances, it is possible to route traffic of a + particular type (e.g., protocol) via particular transit providers. + This can be done if the devices in the site which source or sink that + traffic can be isolated to a set of addresses to which a special + export policy can be applied. + + An example of this capability is the grouping of budget, best-effort + Internet customers into a particular range of addresses that is + covered by a route which is announced preferentially over a single, + low-quality transit path. + + In the case of RFC2260/NAT multihoming, policies such as those + described here can be accommodated by appropriate address selection + on the host or NAT. More flexible implementations may be possible + for sessions originated from the multihomed site by selecting an + appropriate source address on a host or NAT, according to criteria + such as transport-layer protocols and addresses (ports). + + + +Abley, et al. Informational [Page 8] + +RFC 4116 IPv4 Multihoming July 2005 + + +4.5. Simplicity + + The current methods used as multihoming solutions are not without + their complexities, but have proven to be sufficiently simple to be + used. They have the advantage of familiarity due to having been + deployed extensively. + +4.6. Transport-Layer Survivability + + All BGP-based multihoming practices provide some degree of session + survivability for transport-layer protocols. However, in cases where + path convergence takes a long time following a re-homing event, + sessions may time out. + + Transport-layer sessions will not, in general, survive over a re- + homing event when using RFC2260/NAT multihoming. Transport protocols + which support multiple volatile endpoint addresses may be able to + provide session stability; however, these transport protocols are not + in wide use. + + In all the methods described in this document, new transport-layer + sessions are able to be created following a re-homing event. + +4.7. Impact on DNS + + These multihoming strategies impose no new requirements on the DNS. + +4.8. Packet Filtering + + These multihoming practices do not preclude filtering of packets with + inappropriate source or destination addresses at the administrative + boundary of the multihomed site. + +4.9. Scalability + + Current IPv4 multihoming practices are thought to contribute to + significant observed growth in the amount of state held in the global + inter-provider routing system. This is a concern because of both the + hardware requirements it imposes and the impact on the stability of + the routing system. This issue is discussed in greater detail in + [RFC3221]. + + Of the methods presented in this document, RFC2260/NAT multihoming + and multi-attaching to a single transit provider provide no + additional state to be held in the global routing system. All other + strategies contribute to routing system state bloat. + + + + + +Abley, et al. Informational [Page 9] + +RFC 4116 IPv4 Multihoming July 2005 + + + Globally-unique AS numbers are a finite resource. Thus, widespread + multihoming that uses strategies requiring assignment of AS numbers + might lead to increased resource contention. + +4.10. Impact on Routers + + For some of the multihoming approaches described in this document, + the routers at the boundary of the multihomed site are required to + participate in BGP sessions with transit provider routers. Other + routers within the site generally have no special requirements beyond + those in singlehomed sites. + +4.11. Impact on Hosts + + There are no requirements of hosts beyond those in singlehomed sites. + +4.12. Interactions between Hosts and the Routing System + + There are no requirements for interaction between routers and hosts + beyond those in singlehomed sites. + +4.13. Operations and Management + + There is extensive operational experience in managing IPv4-multihomed + sites. + +4.14. Cooperation between Transit Providers + + Transit providers who are asked to announce or propagate a PA prefix + covered by some other (primary) transit provider usually obtain + authorisation first. However, there is no technical requirement or + common contractual policy which requires this coordination to take + place. + +5. Security Considerations + + This document discusses current IPv4 multihoming practices, but + provides no analysis of the security implications of multihoming. + +6. Acknowledgements + + Special acknowledgement goes to John Loughney for proof-reading and + corrections. Thanks also goes to Pekka Savola and Iljitsch van + Beijnum for providing feedback and contributing text. + + This work was supported by the US National Science Foundation + (research grant SCI-0427144) and DNS-OARC. + + + + +Abley, et al. Informational [Page 10] + +RFC 4116 IPv4 Multihoming July 2005 + + +7. Informative References + + [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless + Inter-Domain Routing (CIDR): an Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. + + [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 + (BGP-4)", RFC 1771, March 1995. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, + selection, and registration of an Autonomous System (AS)", + BCP 6, RFC 1930, March 1996. + + [RFC2260] Bates, T. and Y. Rekhter, "Scalable Support for Multi- + homed Multi-provider Connectivity", RFC 2260, + January 1998. + + [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the + Internet", RFC 3221, December 2001. + + [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- + Multihoming Architectures", RFC 3582, August 2003. + + + + + + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 11] + +RFC 4116 IPv4 Multihoming July 2005 + + +Authors' Addresses + + Joe Abley + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + USA + + Phone: +1 650 423 1317 + EMail: jabley@isc.org + + + Kurt Erik Lindqvist + Netnod Internet Exchange + Bellmansgatan 30 + Stockholm S-118 47 + Sweden + + Phone: +46 8 615 85 70 + EMail: kurtis@kurtis.pp.se + + + Elwyn B. Davies + Independent Researcher + Soham, Cambridgeshire CB7 5AW + UK + + Phone: +44 7889 488 335 + EMail: elwynd@dial.pipex.com + + + Benjamin Black + Layer8 Networks + + EMail: ben@layer8.net + + + Vijay Gill + AOL + 12100 Sunrise Valley Dr + Reston, VA 20191 + US + + Phone: +1 410 336 4796 + EMail: vgill@vijaygill.com + + + + + + +Abley, et al. Informational [Page 12] + +RFC 4116 IPv4 Multihoming July 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Abley, et al. Informational [Page 13] + -- cgit v1.2.3