Network Working Group J. Abley
Request for Comments: 3582 ISC
Category: Informational B. Black
Layer8 Networks
V. Gill
AOL Time Warner
August 2003
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
IPv6站点多主体系结构的目标
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.
版权所有（C）互联网协会（2003年）。版权所有。
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.
本文档概述了拟议的新IPv6站点多主体系结构的一组目标。人们认识到，这套目标是雄心勃勃的，有些目标可能与其他目标冲突。所采用的一个或多个解决方案可能只能满足此处提出的一些目标。
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.
站点多宿主，即连接到多个IP服务提供商，是许多作为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.
当前的IPv4站点多主实践已添加到CIDR体系结构[1]，该体系结构假定可以基于客户和服务提供商的层次结构聚合路由表条目。
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.
然而，这种层次结构似乎正在被密集的互联网络所取代[6]。此外，多址网站的数量也有了巨大的增长。出于冗余和负载共享的目的，将多址地址块引入全局表中，即使它们由提供程序聚合覆盖。这导致全局路由表的大小和其中显示的混乱迅速增加，并对提供商间路由系统造成压力。
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.
互联网的持续发展和站点多主的实践将严重加剧这种压力。IPv6的站点多主体系结构应允许路由系统更方便地扩展。
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].
“站点”是指使用IP自主操作网络的实体，尤其是确定该网络的寻址计划和路由策略的实体。该定义旨在等同于[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.
术语“重新归宿”表示由于站点与其运输提供商站点之间的连接发生变化，站点在两种连接状态之间的转换。
The following capabilities of current IPv4 multihoming practices should be supported by an IPv6 multihoming architecture.
IPv6多主体系结构应支持当前IPv4多主实践的以下功能。
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".
IP层下的基础设施共性可能导致连接明显多样化，共享单点故障。例如，从不同供应商订购的两个单独的DS3电路，并将一个站点连接到独立的公交供应商，可能会共用一条从街道到建筑物的导管；在这种情况下，两条电路的物理中断（有时称为“反铲衰退”）可能由于街道上的单一事件而发生。据说这两条赛道“命运相同”。
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 物理故障，如光纤切断或路由器故障，
o Logical link failure, such as a misbehaving router interface,
o 逻辑链路故障，如路由器接口行为异常，
o Routing protocol failure, such as a BGP peer reset,
o 路由协议故障，如BGP对等重置，
o Transit provider failure, such as a backbone-wide IGP failure, and
o 传输提供程序故障，例如主干网范围的IGP故障，以及
o Exchange failure, such as a BGP reset on an inter-provider peering.
o 交换失败，例如提供程序间对等上的BGP重置。
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.
通过多主，站点应该能够在多个交通服务提供商之间分配入站和出站流量。这一目标是为了同时使用多个运输提供商，而不仅仅是在一个时间间隔内使用一个提供商，在另一个时间间隔内使用另一个提供商。
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.
例如，假设站点E从公交提供商T1和T2获得公交，并且T1和T2之间存在长期拥塞。多宿体系结构应允许E确保在正常运行中，其流量不会通过拥挤的互连T1-T2。实现这一点的过程应该是手动的。
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.
多址站点应能够根据其站点内的特定地址范围，分配来自特定多个运输提供商的入站流量，该地址范围是流量的来源或来源。
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.
客户可能出于技术范围以外的各种政策原因（例如，成本、可接受的使用条件等）选择多家运营。例如，作为政策事项，ISP A的客户C可能希望将特定类别或应用的流量（例如，NNTP）转移到ISP B。出于外部政策原因，新的IPv6多主方案应为站点多主提供支持。
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.
新的IPv6多宿主解决方案的部署和操作（对于多宿主站点或互联网的其他部分）不应比当前的IPv4多宿主实践复杂得多。
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.
多归属解决方案应为传输层会话提供重新归属的透明度；i、 例如，在多宿站点上的设备和因特网上其他地方的设备之间的数据交换可以继续进行，而中断程度不超过在重新归宿事件期间与瞬时分组丢失相关联的中断。
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.
传输层会话包括涉及传输层协议（如TCP、UDP和SCTP over IP）的会话。通过原始IP和其他网络层协议进行通信的应用程序也可以享受重设主机的透明度。
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.
多归宿解决方案要么应与当前DNS系统的观测动态兼容，要么应证明支持它们所需的经修改的名称解析系统易于部署。
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.
多宿主解决方案不应排除在多宿主站点的管理边界或Internet上任何站点的管理边界过滤具有伪造或不适当源IP地址的数据包。
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].
当前的IPV4多主实践促进了目前在全球供应商间路由系统的状态中观察到的显著增长；这是一个值得关注的问题，既因为它强加的硬件要求，也因为对路由系统稳定性的影响。[6]中详细讨论了这个问题。
A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system.
新的IPv6多宿体系结构应可扩展，以适应数量级以上的多宿站点，而不会对路由系统提出不合理的要求。
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.
这些解决方案可能需要对IPv6路由器实现进行更改，但这些更改应该是次要的，或者以逻辑上独立的功能的形式添加到现有功能中。
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.
此类更改不应阻止正常的单主机操作，实现这些更改的路由器应能够与未实现这些更改的主机和路由器完全互操作。
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.
解决方案不应破坏实现RFC 3513[3]、RFC 2460[4]、RFC 3493[5]和2003年4月当前其他基本IPv6规范的传统主机的IPv6连接。也就是说，如果主机可以在单主机站点中工作，那么它应该仍然能够在多主机站点中工作，即使它不能从站点多主机中受益。
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.
如果解决方案需要更改套接字API和/或传输层，则应该可以并行保留原始套接字API和传输协议，即使它们无法从多宿主中获益。
The multihoming solution may allow host or application changes if that would enhance transport-layer survivability.
如果多宿主解决方案能够提高传输层的生存能力，则可以允许主机或应用程序更改。
The solution may involve interaction between a site's hosts and its routing system; such an interaction should be simple, scalable and securable.
解决方案可能涉及站点主机与其路由系统之间的交互；这种交互应该简单、可伸缩且安全。
It should be possible for staff responsible for the operation of a site to monitor and configure the site's multihoming system.
负责站点运行的员工应能够监控和配置站点的多主系统。
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.
应从操作实用性的角度检查和评估为促进多中心解决方案而可能需要的任何站点间合作的影响。
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.
如果所有方法都是正交的（即，每种方法都解决了站点多宿主问题中的一个不同部分或类别），则可能有多个多宿主方法。但是，多个解决方案将产生更大的管理开销，采用的解决方案应尽可能涵盖多个多主场景和目标。
A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site.
多宿主站点不应比传统的IPv4多宿主站点更容易受到安全漏洞的攻击。
Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches.
为适应多主机站点而对路由实践所做的任何更改都不应导致非多主机站点更容易受到安全漏洞的攻击。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[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.
[1] Fuller，V.，Li，T.，Yu，J.和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[2] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[5] Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[6] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[6] Huston，G.“因特网域间路由评论”，RFC 3221，2001年12月。
Joe Abley Internet Software Consortium 950 Charter Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市查特街950号Joe Abley互联网软件联盟，邮编94063
Phone: +1 650 423 1317
EMail: jabley@isc.org
Phone: +1 650 423 1317
EMail: jabley@isc.org
Benjamin Black Layer8 Networks
Benjamin Black Layer8网络
EMail: ben@layer8.net
EMail: ben@layer8.net
Vijay Gill AOL Time Warner
维杰·吉尔美国在线时代华纳
EMail: vijaygill9@aol.com
EMail: vijaygill9@aol.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。