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
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
IPv4多宿主实践和限制
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).
版权所有（C）互联网协会（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).
多宿主是许多互联网站点服务的重要组成部分。本文档描述了使用IPv4的多宿的一些实现策略，并列举了与其他多宿方案（特别是与IPv6相关的方案）进行比较的功能。
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
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
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.
多宿主是许多互联网站点服务的重要组成部分。当前的IPv4多主实践已添加到无类域间路由（CIDR）体系结构[RFC1519]，该体系结构假定可以根据客户和服务提供商的层次结构聚合路由表条目。
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.
多宿主是一种机制，通过这种机制，站点可以满足许多高级需求。它广泛应用于IPv4互联网。然而，也存在一些实际限制，包括它将如何随着未来互联网的增长而扩展。本文档旨在记录常见的IPv4多宿主实践，并列举它们的特性，以便与其他多宿主方法进行比较。
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.
有许多不同的方法来路由和管理多宿站点的进出流量：大多数方法依赖域间路由协议、边界网关协议版本4（BGP）[RFC1771]的路由策略功能。本文档还讨论了一种不依赖BGP功能的多归宿策略。
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].
“站点”是指使用IP自主操作网络的实体，尤其是确定该网络的寻址计划和路由策略的实体。该定义旨在等同于[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).
独立提供商（PI）地址是全球唯一的地址，不是由交通提供商分配的，而是由其他组织提供的，通常是区域互联网注册中心（RIR）。
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.
提供商可聚合（PA）地址是公交提供商分配给客户的全局唯一地址。这些地址被认为是“可聚合的”，因为与PA地址相对应的路由集通常由一个聚合路由集覆盖，该聚合路由集与公交服务提供商操作的地址空间相对应，从中进行分配。
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.
请注意，“分配”和“分配”在区域Internet注册表（RIR）地址管理策略中具有特定含义，但在本文档中使用更为松散。
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.
使用BGP进行多宿的一般方法是向两个或多个运输提供商宣布一组路线。这为Internet的其余部分提供了多条返回多址站点的路径，并且每个传输提供商为站点的出站流量提供了额外的可能路径。
The site uses PI addresses, and a set of routes covering those PI addresses is announced or propagated by two or more transit providers.
该站点使用PI地址，覆盖这些PI地址的一组路由由两个或多个公交提供商宣布或传播。
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.
长期以来，使用PI地址一直是IPv4多宿主的首选方法。在20世纪90年代中期之前，这相对容易实现，因为全局路由表中普遍接受的最大前缀长度是a/24，并且获得a/24 PI分配几乎不需要任何理由。此后，RIR地址管理政策在这方面变得不那么自由。并非所有RIR都支持将地址块分配给小型多址最终用户，而那些支持RIR的RIR则需要对像a/24这样大的地址块进行调整，这是小型站点无法满足的。因此，许多希望多址的站点无法使用PI地址。
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.
每个使用PI地址的站点都会在全局路由系统中引入一个额外的前缀。如果这种多宿主方案得到广泛应用，它将带来可伸缩性问题。
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.
该站点使用由单一交通服务提供商分配的PA地址。覆盖这些PA地址的路线集（“站点路线集”）由一个或多个额外的公交提供商宣布或传播。分配PA地址的公交服务提供商（“主要公交服务提供商”）发起一组覆盖站点线路集的线路。主要运输提供商通常发起或传播站点路线集以及覆盖聚合。
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.
PA地址的使用适用于地址要求不足以满足RIR PI分配要求的现场。然而，如果站点路由集将由两个或多个不同的公交服务提供商宣布或传播，通常的运营实践仍然要求最小/24前缀，这可能大于可用于小型站点的分配。
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.
有大量的证据表明，站点会过滤公交供应商集合中包含的长前缀路线。如果这种做法变得非常普遍，它可能会限制使用PA地址的多宿主的有效性。然而，这种有限的过滤是可以容忍的，因为主要交通服务提供商的总公告应足以吸引来自不接受覆盖站点路线集的自治系统的交通。在没有覆盖的、更具体的路线的情况下，主要交通服务提供商的总流量越大，对该主要交通服务提供商的依赖就越大。在某些情况下，这种依赖可能导致有效的单点故障。
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.
如果使用PA地址的站点决定不保留与主要交通服务提供商的连接，通常必须重新编号。虽然这是所有使用PA地址的站点（不仅仅是多址站点）的共同要求，但对于多址站点的动机是促进ISP变更的站点，这可能会产生更频繁的影响。使用PA地址的多址站点仍然可以添加或删除其他服务提供商，而无需重新编号。
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.
多宿站点可以选择从分配给站点的全局唯一自治系统（AS）编号向两个或多个公交提供商宣布路线。这使得从Internet的所有部分查看时，路由的来源看起来是一致的。
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.
多宿站点可以选择使用专用AS编号[RFC1930]来发起到公交提供商的路线。通常情况下，在允许AS_路径属性从传输提供商向对等方传播之前，私人使用AS号码是从AS_路径属性中剥离出来的。因此，从互联网其他部分观察到的路由可能具有不一致的来源。
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.
多宿站点可要求其公交服务提供商各自从公交服务提供商的ASE发起站点的路线。在这种情况下，仍然可以使用公交供应商的内部路由系统触发外部可见的公告，动态路由（用于在与站点的连接中断时撤回站点的路由）。
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).
通过使用一致的原点，可以方便地进行操作故障排除。这允许导入策略基于路线的真实来源，而不是中间路线的详细信息，中间路线的详细信息可能会发生变化（例如，当多宿站点添加和删除运输提供商时）。
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".
可以通过多个连接到一个公交服务提供商来实现多归属。这不会对全局路由表施加超出单个连接站点所涉及的额外负载。以这种方式解决其多主机需求的站点通常被称为“多连接”。
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.
不要求多连接站点使用BGP与其传输提供商交换路由信息。但是，在发生故障的情况下，需要一些机制在剩余电路上重新路由入站和出站流量。BGP通常用于此目的。
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.
多连接站点使用PI地址或（使用BGP时）全局唯一性作为数字没有任何优势，并且不需要能够证明特定最小大小的地址分配是合理的。但是，多重连接不能保护站点免受单一传输提供商故障的影响。
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.
此方法使用站点所连接的每个公交供应商分配的PA地址。地址根据[RFC2260]分配给网络内的各个主机，或者站点使用网络地址转换（NAT）将各种提供商地址转换为站点内的一组专用地址[RFC1918]。该站点实际上是由多个交通服务提供商单独托管的。除通常为非多宿客户提供的住宿外，任何交通服务提供商都不需要提供任何住宿。
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.
这种方法适应范围广泛的站点，从住宅互联网用户到非常大的企业，不需要PI地址或AS号码，并且不会对互联网的全局路由系统施加额外的负载。然而，它没有解决多宿的几个常见动机，最显著的是传输层生存能力。
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.
以下各节结合[RFC3582]中介绍的多主体系结构的一般目标，描述了第3节中所述方法的一些特征。这些目标的详细说明和基本原理可在该文件中找到。
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.
所有描述的方法都提供冗余，可以保护站点免受某些单点故障的影响。保护程度取决于运输供应商的选择以及将站点与这些运输供应商互连所用的方法。
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.
所描述的所有方法都提供了负载共享能力的一些度量。使用适当的出口选择策略，可以在ISP之间共享出站流量；可以使用适当的导出策略来分配入站流量，这些策略旨在影响将流量发送回多址站点的远程站点的出口选择。
In the case of RFC2260/NAT multihoming, distribution of inbound traffic is controlled by address selection on the host or NAT.
在RFC2260/NAT多宿的情况下，入站流量的分布由主机或NAT上的地址选择控制。
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.
讲BGP的网站可以采用导入策略，导致退出选择，以避免已知有问题的路径。对于入站流量，站点通常可以采用路由导出策略，该策略针对其网络中的特定地址范围提供不同的流量处理。
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.
在缺少BGP路由信息的RFC2260/NAT多宿的情况下，无法管理出站流量。特定会话的入站流量所采用的路径可以由主机或NAT上的源地址选择控制。
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).
在rfc226/NAT多宿主的情况下，诸如这里描述的那些策略可以通过主机或NAT上的适当地址选择来适应。根据传输层协议和地址（端口）等标准，通过在主机或NAT上选择适当的源地址，可以为源自多址站点的会话提供更灵活的实现。
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.
目前作为多归宿解决方案使用的方法并非没有复杂性，但已证明非常简单，可以使用。由于广泛部署，它们具有熟悉的优势。
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.
所有基于BGP的多宿主实践都为传输层协议提供了一定程度的会话生存能力。然而，在路径会聚在重新归宿事件之后需要很长时间的情况下，会话可能会超时。
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.
在使用RFC2260/NAT多宿主时，传输层会话通常不会在重新宿主事件中存活。支持多个易失性端点地址的传输协议可以提供会话稳定性；然而，这些传输协议并没有得到广泛使用。
In all the methods described in this document, new transport-layer sessions are able to be created following a re-homing event.
在本文档中描述的所有方法中，新的传输层会话都可以在重新引导事件之后创建。
These multihoming strategies impose no new requirements on the DNS.
这些多宿主策略对DNS没有新的要求。
These multihoming practices do not preclude filtering of packets with inappropriate source or destination addresses at the administrative boundary of the multihomed site.
这些多宿主实践并不排除在多宿主站点的管理边界过滤具有不适当源地址或目标地址的数据包。
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].
目前的IPv4多主实践被认为有助于全球提供商间路由系统中状态量的显著增长。这是一个值得关注的问题，因为它对硬件的要求以及对路由系统稳定性的影响。该问题在[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.
在本文档中介绍的方法中，RFC2260/NAT多主和多连接到单个运输提供商不会在全局路由系统中提供额外的状态。所有其他策略都会导致路由系统状态膨胀。
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.
全局唯一，因为数字是有限的资源。因此，使用需要分配AS编号的策略的广泛多宿可能会导致资源争用加剧。
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.
对于本文档中描述的一些多宿方法，多宿站点边界处的路由器需要参与与传输提供商路由器的BGP会话。站点内的其他路由器通常没有特殊要求，仅限于单宿站点中的路由器。
There are no requirements of hosts beyond those in singlehomed sites.
除了单宿站点中的主机之外，没有其他主机的要求。
There are no requirements for interaction between routers and hosts beyond those in singlehomed sites.
除了单宿站点中的路由器和主机之外，路由器和主机之间没有交互要求。
There is extensive operational experience in managing IPv4-multihomed sites.
在管理IPv4多址站点方面有丰富的运营经验。
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.
被要求宣布或传播由其他（主要）交通服务提供商覆盖的PA前缀的交通服务提供商通常首先获得授权。但是，没有技术要求或共同合同政策要求进行这种协调。
This document discusses current IPv4 multihoming practices, but provides no analysis of the security implications of multihoming.
本文档讨论了当前的IPv4多宿主实践，但没有分析多宿主的安全含义。
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.
特别感谢John Loughney进行校对和更正。还要感谢佩卡·萨沃拉和伊尔吉奇·凡·贝伊纳姆提供反馈和贡献文本。
This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
这项工作得到了美国国家科学基金会（研究资助SCIO 0427 144）和DNS OARC的支持。
[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.
[RFC1519]Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，BCP 6，RFC 1930，1996年3月。
[RFC2260] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998.
[RFC2260]Bates，T.和Y.Rekhter，“多宿多提供商连接的可扩展支持”，RFC 2260，1998年1月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]Huston，G.“互联网中域间路由的评论”，RFC3221，2001年12月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582]Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
Authors' Addresses
作者地址
Joe Abley Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市查特街950号Joe Abley Internet Systems Consortium，Inc.94063
Phone: +1 650 423 1317
EMail: jabley@isc.org
Phone: +1 650 423 1317
EMail: jabley@isc.org
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 Stockholm S-118 47 Sweden
Kurt Erik Lindqvist Netnod互联网交换台Bellmansgatan 30斯德哥尔摩S-118 47瑞典
Phone: +46 8 615 85 70
EMail: kurtis@kurtis.pp.se
Phone: +46 8 615 85 70
EMail: kurtis@kurtis.pp.se
Elwyn B. Davies Independent Researcher Soham, Cambridgeshire CB7 5AW UK
Elwyn B.Davies独立研究员Soham，英国剑桥郡CB7 5AW
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Benjamin Black Layer8 Networks
Benjamin Black Layer8网络
EMail: ben@layer8.net
EMail: ben@layer8.net
Vijay Gill AOL 12100 Sunrise Valley Dr Reston, VA 20191 US
维杰·吉尔AOL 12100日出谷雷斯顿博士，弗吉尼亚州，美国20191
Phone: +1 410 336 4796
EMail: vgill@vijaygill.com
Phone: +1 410 336 4796
EMail: vgill@vijaygill.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。