doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

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]
+