summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3582.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3582.txt')
-rw-r--r--doc/rfc/rfc3582.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc3582.txt b/doc/rfc/rfc3582.txt
new file mode 100644
index 0000000..eca64c2
--- /dev/null
+++ b/doc/rfc/rfc3582.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group J. Abley
+Request for Comments: 3582 ISC
+Category: Informational B. Black
+ Layer8 Networks
+ V. Gill
+ AOL Time Warner
+ August 2003
+
+
+ Goals for IPv6 Site-Multihoming Architectures
+
+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 (2003). All Rights Reserved.
+
+Abstract
+
+ This document outlines a set of goals for proposed new IPv6 site-
+ multihoming architectures. It is recognised that this set of goals
+ is ambitious and that some goals may conflict with others. The
+ solution or solutions adopted may only be able to satisfy some of the
+ goals presented here.
+
+1. Introduction
+
+ Site-multihoming, i.e., connecting to more than one IP service
+ provider, is an essential component of service for many sites which
+ are part of the Internet.
+
+ Current IPv4 site-multihoming practices have been added on to the
+ CIDR architecture [1], which assumes that routing table entries can
+ be aggregated based upon a hierarchy of customers and service
+ providers.
+
+ However, it appears that this hierarchy is being supplanted by a
+ dense mesh of interconnections [6]. Additionally, there has been an
+ enormous growth in the number of multihomed sites. For purposes of
+ redundancy and load-sharing, the multihomed address blocks are
+ introduced into the global table even if they are covered by a
+ provider aggregate. This contributes to the rapidly-increasing size
+ of both the global routing table and the turbulence exhibited within
+ it, and places stress on the inter-provider routing system.
+
+
+
+Abley, et al. Informational [Page 1]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+ Continued growth of both the Internet and the practice of site-
+ multihoming will seriously exacerbate this stress. The site-
+ multihoming architecture for IPv6 should allow the routing system to
+ scale more pleasantly.
+
+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 [2].
+
+ 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.
+ 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.
+
+3. Multihoming Goals
+
+3.1. Capabilities of IPv4 Multihoming
+
+ The following capabilities of current IPv4 multihoming practices
+ should be supported by an IPv6 multihoming architecture.
+
+3.1.1. Redundancy
+
+ By multihoming, a site should be able to insulate itself from certain
+ failure modes within one or more transit providers, as well as
+ failures in the network providing interconnection among one or more
+ transit providers.
+
+ Infrastructural commonalities below the IP layer may result in
+ connectivity which is apparently diverse, sharing single points of
+ failure. For example, two separate DS3 circuits ordered from
+ different suppliers and connecting a site to independent transit
+ providers may share a single conduit from the street into a building;
+ in this case, physical disruption (sometimes referred to as
+ "backhoe-fade") of both circuits may be experienced due to a single
+ incident in the street. The two circuits are said to "share fate".
+
+
+
+Abley, et al. Informational [Page 2]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+ The multihoming architecture should accommodate (in the general case,
+ issues of shared fate notwithstanding) continuity of connectivity
+ during the following failures:
+
+ o Physical failure, such as a fiber cut, or router failure,
+
+ o Logical link failure, such as a misbehaving router interface,
+
+ o Routing protocol failure, such as a BGP peer reset,
+
+ o Transit provider failure, such as a backbone-wide IGP failure, and
+
+ o Exchange failure, such as a BGP reset on an inter-provider
+ peering.
+
+3.1.2. Load Sharing
+
+ By multihoming, a site should be able to distribute both inbound and
+ outbound traffic between multiple transit providers. This goal is
+ for concurrent use of the multiple transit providers, not just the
+ usage of one provider over one interval of time and another provider
+ over a different interval.
+
+3.1.3. Performance
+
+ By multihoming, a site should be able to protect itself from
+ performance difficulties directly between the site's transit
+ providers.
+
+ For example, suppose site E obtains transit from transit providers T1
+ and T2, and there is long-term congestion between T1 and T2. The
+ multihoming architecture should allow E to ensure that in normal
+ operation, none of its traffic is carried over the congested
+ interconnection T1-T2. The process by which this is achieved should
+ be a manual one.
+
+ A multihomed site should be able to distribute inbound traffic from
+ particular multiple transit providers according to the particular
+ address range within their site which is sourcing or sinking the
+ traffic.
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al. Informational [Page 3]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+3.1.4. Policy
+
+ A customer may choose to multihome for a variety of policy reasons
+ beyond technical scope (e.g., cost, acceptable use conditions, etc.)
+ For example, customer C homed to ISP A may wish to shift traffic of a
+ certain class or application, NNTP, for example, to ISP B as matter
+ of policy. A new IPv6 multihoming proposal should provide support
+ for site-multihoming for external policy reasons.
+
+3.1.5. Simplicity
+
+ As any proposed multihoming solution must be deployed in real
+ networks with real customers, simplicity is paramount. The current
+ multihoming solution is quite straightforward to deploy and maintain.
+
+ A new IPv6 multihoming solution should not be substantially more
+ complex to deploy and operate (for multihomed sites or for the rest
+ of the Internet) than current IPv4 multihoming practices.
+
+3.1.6. Transport-Layer Survivability
+
+ Multihoming solutions should provide re-homing transparency for
+ transport-layer sessions; i.e., exchange of data between devices on
+ the multihomed site and devices elsewhere on the Internet may proceed
+ with no greater interruption than that associated with the transient
+ packet loss during the re-homing event.
+
+ New transport-layer sessions should be able to be created following a
+ re-homing event.
+
+ Transport-layer sessions include those involving transport-layer
+ protocols such as TCP, UDP and SCTP over IP. Applications which
+ communicate over raw IP and other network-layer protocols may also
+ enjoy re-homing transparency.
+
+3.1.7. Impact on DNS
+
+ Multi-homing solutions either should be compatible with the observed
+ dynamics of the current DNS system, or the solutions should
+ demonstrate that the modified name resolution system required to
+ support them is readily deployable.
+
+3.1.8. Packet Filtering
+
+ Multihoming solutions should not preclude filtering packets with
+ forged or otherwise inappropriate source IP addresses at the
+ administrative boundary of the multihomed site, or at the
+ administrative boundaries of any site in the Internet.
+
+
+
+Abley, et al. Informational [Page 4]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+3.2. Additional Requirements
+
+3.2.1. Scalability
+
+ Current IPV4 multihoming practices contribute to the significant
+ growth currently observed in the state held in the global inter-
+ provider routing system; this is a concern, both because of the
+ hardware requirements it imposes, and also because of the impact on
+ the stability of the routing system. This issue is discussed in
+ great detail in [6].
+
+ A new IPv6 multihoming architecture should scale to accommodate
+ orders of magnitude more multihomed sites without imposing
+ unreasonable requirements on the routing system.
+
+3.2.2. Impact on Routers
+
+ The solutions may require changes to IPv6 router implementations, but
+ these changes should be either minor, or in the form of logically
+ separate functions added to existing functions.
+
+ Such changes should not prevent normal single-homed operation, and
+ routers implementing these changes should be able to interoperate
+ fully with hosts and routers not implementing them.
+
+3.2.3. Impact on Hosts
+
+ The solution should not destroy IPv6 connectivity for a legacy host
+ implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other
+ basic IPv6 specifications current in April 2003. That is to say, if
+ a host can work in a single-homed site, it should still be able to
+ work in a multihomed site, even if it cannot benefit from site-
+ multihoming.
+
+ It would be compatible with this goal for such a host to lose
+ connectivity if a site lost connectivity to one transit provider,
+ despite the fact that other transit provider connections were still
+ operational.
+
+ If the solution requires changes to the host stack, these changes
+ should be either minor, or in the form of logically separate
+ functions added to existing functions.
+
+ If the solution requires changes to the socket API and/or the
+ transport layer, it should be possible to retain the original socket
+ API and transport protocols in parallel, even if they cannot benefit
+ from multihoming.
+
+
+
+
+Abley, et al. Informational [Page 5]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+ The multihoming solution may allow host or application changes if
+ that would enhance transport-layer survivability.
+
+3.2.4. Interaction between Hosts and the Routing System
+
+ The solution may involve interaction between a site's hosts and its
+ routing system; such an interaction should be simple, scalable and
+ securable.
+
+3.2.5. Operations and Management
+
+ It should be possible for staff responsible for the operation of a
+ site to monitor and configure the site's multihoming system.
+
+3.2.6. Cooperation between Transit Providers
+
+ A multihoming strategy may require cooperation between a site and its
+ transit providers, but should not require cooperation (relating
+ specifically to the multihomed site) directly between the transit
+ providers.
+
+ The impact of any inter-site cooperation that might be required to
+ facilitate the multihoming solution should be examined and assessed
+ from the point of view of operational practicality.
+
+3.2.7. Multiple Solutions
+
+ There may be more than one approach to multihoming, provided all
+ approaches are orthogonal (i.e., each approach addresses a distinct
+ segment or category within the site multihoming problem). Multiple
+ solutions will incur a greater management overhead, however, and the
+ adopted solutions should attempt to cover as many multihoming
+ scenarios and goals as possible.
+
+4. Security Considerations
+
+ A multihomed site should not be more vulnerable to security breaches
+ than a traditionally IPv4-multihomed site.
+
+ Any changes to routing practices made to accommodate multihomed sites
+ should not cause non-multihomed sites to become more vulnerable to
+ security breaches.
+
+
+
+
+
+
+
+
+
+Abley, et al. Informational [Page 6]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+5. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+6. Normative References
+
+ [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
+ Domain Routing (CIDR): an Address Assignment and Aggregation
+ Strategy", RFC 1519, September 1993.
+
+ [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
+ Lear, "Address Allocation for Private Internets", BCP 5, RFC
+ 1918, February 1996.
+
+ [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+ Addressing Architecture", RFC 3513, April 2003.
+
+ [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, December 1998.
+
+ [5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens,
+ "Basic Socket Interface Extensions for IPv6", RFC 3493, February
+ 2003.
+
+ [6] Huston, G., "Commentary on Inter-Domain Routing in the Internet",
+ RFC 3221, December 2001.
+
+
+
+
+
+
+
+Abley, et al. Informational [Page 7]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+7. Authors' Addresses
+
+ Joe Abley
+ Internet Software Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ Phone: +1 650 423 1317
+ EMail: jabley@isc.org
+
+
+ Benjamin Black
+ Layer8 Networks
+
+ EMail: ben@layer8.net
+
+
+ Vijay Gill
+ AOL Time Warner
+
+ EMail: vijaygill9@aol.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al. Informational [Page 8]
+
+RFC 3582 IPv6 Site-Multihoming Goals August 2003
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al. Informational [Page 9]
+