组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：熊继平（xiongjiping&nbsp;&nbsp;&nbsp;&nbsp;xjping@mail.ustc.edu.cn）<br />
译文发布时间：2002-5-13<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T.&nbsp;Bates<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2260&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
Category:&nbsp;Informational&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Rekhter<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;January&nbsp;1998<br />
<br />
对多宿主的多提供者连接的可扩展性支持<br />
（RFC2260&nbsp;——Scalable&nbsp;Support&nbsp;for&nbsp;Multi-homed&nbsp;Multi-provider&nbsp;Connectivity）<br />
<br />
本备忘录的状态<br />
本备忘录为Internet团体提供信息。它并没有给出任何类型的Inernet标准。本备忘录的发布不受任何限制。<br />
版权声明<br />
Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(1998)。版权所有。<br />
2.&nbsp;摘要<br />
本文档描述了连接到多个Internet服务提供商（ISPs）的多宿主机构（enterprises）的寻址和路由策略，这样做的目的是为了试图减轻此类机构在全球Internet路由体系中带来的路由负担。<br />
3.&nbsp;动机<br />
一个机构基于以下的一些原因可能会从多于一个Internet服务提供商（ISP）那里获得Internet的连通性。维护依靠多于一个ISP提供的连通性可以被看作到Internet的连通性更加可靠的一种方式。此时，若到其中某个ISP的连通性失效了，那么依靠到其它ISP（s）的连通性仍旧可以确保机构保持到Internet的连通性。除了可以提供更多的可靠的连通外，维护依靠多于一个ISP提供的连通性还可以允许机构在多个连接间分配负载。对于在地域上跨越较宽的那些企业，这能够带来更好的路由性。<br />
基于以上的考虑，在加上日渐降低的上网费用，会促使愈来愈多的机构成为连接到多个ISPs的多宿主网络。与此同时，这样的机构加在Internet路由系统上的路由负担也会变得越来越显著。为了扩展Internet，和能够支持这种机构的增长数量，需要有能够包含这种负担的一些机制。本文档假定在“默认－树”区域的路由器被要求维护一条每个连接到多个ISPs的多宿主机构的路由的这种实现并没有提供足够的伸缩性。此外，考虑到Internet本身的特点，本文档假定为此种机构处理路由的方法应该最小化在ISPs间，尤其是那些并没有和此类机构有直接连接的ISPs间需要协调的数目。<br />
对于连接到多个ISP的多宿主的这种驱动力因素是否能够完全只由连接到单个ISP的多宿主所代替，人们有着不同的观点，此替代将消除多宿主带给Internet路由系统的负面影响。关于此话题的讨论超出了此文档的范围。<br />
此文档的焦点在与能够减少连接到多个ISP的多宿主机构在Internet路由系统上带来的负担的路由和寻址策略。<br />
本文档所描述的策略同等的适用于IPv4和IPv6。<br />
4.&nbsp;地址分派和分配<br />
一个连接到一组ISP的多宿主机构将从每个它们的ISP（连接到N个ISP的机构将获得N个不同的地址块）中获得分派的一地址块（地址前缀）。那些ISP分派给机构的地址将要基于“地址－主导”（“address－leading”）策略【RFC2008】。<br />
机构可能实施的一个地址分配计划是使用一个节点到一个特定的ISP（到机构和ISP之间的相互连接）的拓扑上的接近作为一个如何为节点选择地址前缀的标准。一个特别的节点（主机）可能从一个单一前缀中获得多个地址或从不同的前缀获得多个地址。<br />
5&nbsp;&nbsp;路由信息交换<br />
一个机构和它的所有ISP之间的路由信息交换的问题可以分解为下面几个部分：<br />
a)&nbsp;一个机构的边缘路由器对一个ISP内的边缘路由器通告其可到达的信息。<br />
b)&nbsp;一个ISP内的边缘路由器对一个机构内的边缘路由器通告其可到达的信息。<br />
本文档重点讨论（a）；（b）只在需要时提及。<br />
5.1&nbsp;机构的边缘路由器广告的可达信息<br />
当连到一个特定ISP的机构边缘路由器发现机构和Internet之的所有ISP的连接处于活动状态时，此路由器只通告（向那个ISP的边缘路由器）此ISP分派给机构的地址前缀的可达性。这样一来，处于一个稳定的状态时，由机构引入它的ISP路由被它们的ISP集聚，并且不会被扩散到Internet的“默认－树”区域。<br />
当连到一个特定ISP的机构边缘路由器发现机构和Internet之的所有ISP的连接有一个或多个失效时，此路由器开始通告对那些ISP分派给机构的地址前缀的可达性。我们可以观察到在Internet上由于一个或多个ISP的失效导致所有的多宿主机构同时失去到Internet连接的这种可能性是微乎其微的。因此，在Internet上的“默认－树”区域上由于多宿主机构而造成的额外路由的平均数量可以预期只是这种机构总数中的一小部分。<br />
以上的描述的方法基于一个假设，即一个机构的边缘路由器具有一种机制，它能够判断（a）通过其它的一些边缘路由器到Internet的连通性是活动的还是失效的（b）连接到其它边缘路由器的ISP所分配给机构的地址前缀。一个这样可能机制可以由BGP【RFC1771】来提供。在这种情况下，在机构里的边缘路由器相互之间将会有一个IBGP对端（peering）。一旦一个边缘路由器判断出它依靠的EBGP对端（从它直接相连的ISP那）接收到的一组可到达的目的地的交集（intersection）和一组它从其它的边缘路由器（在同一个机构内）那依靠IBGP收到的可到达的目的地都为空时，此边缘路由器将开始向它的外部对端广告它到连接到其它边缘路由器的ISP所分派给机构的地址前缀的可达性。其它的边缘路由器会广告（依靠IBGP）由连接到此路由器的ISP分配给机构的地址前缀。这种方法被称为“自动路由注入（auto&nbsp;route&nbsp;injection）”。<br />
作为一个例子，考虑一个机构连到两个ISP，ISP-A和ISP-B。将机构连到ISP-A的机构边缘路由器表示为BR-A；将机构连到ISP-B的机构边缘路由器表示为BR-B。将ISP-A分派给机构的地址前缀表示为Pref-A；将ISP-B分派给机构的地址前缀表示为Pref-B。当BR-A从ISP-A那（依靠EBGP）收到的一组路由器与BR-A从BR-B那（依靠IBGP）收到的一组路由器信息有非空的交集时，BR-A只向ISP-A广告它到Pref-A的可到达性。当此交集为空时，BR-A将向ISP-A广告到Pref-A和Pref-B的可到达性。若交集继续为空，此过程会一直进行下去。一旦交集非空，BR-A将停止向ISP-A广告到Pref-A的可到达性（但会继续向ISP-A广告到Pref-A的可到达性）。下图1用图形的方式描述了这种方法。<br />
<br />
＋―――＋&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;ISP-A&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;ISP-B&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;ISP-A&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;ISP-B&nbsp;&nbsp;&nbsp;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋&nbsp;&nbsp;&nbsp;&nbsp;＋―――＋<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;/\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;/\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;/\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Pref-A&nbsp;&nbsp;&nbsp;&nbsp;(connection<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Pref-A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Pref-B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;Pref-B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;broken)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋――＋&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋――＋&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋――＋&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋――＋<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;BR-A|――――|BR-B&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;BR-A|――――&nbsp;|BR-B&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋――＋&nbsp;IBGP&nbsp;＋――＋&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;＋――＋&nbsp;IBGP&nbsp;＋――＋<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;非空交集&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;空交集<br />
图1&nbsp;广告可达性信息<br />
尽管实现的细节比较严格，为一大组路由器计算交集可能会潜在的成为一个费时的操作。一个对此的替代解决方法是利用从一个ISP（此ISP的主干路由，例如）接收到的一个选定的单个（或更多）地址前缀，并配置此机构边缘路由器以实现在选定前缀不在IBGP中时，路由的自动注入。我们假设ISP-B有一个众所周知的地址前缀，ISP-Pref-B用于其主干网。ISP-B向BR-B广告此地址前缀，BR-B接着依靠IBGP向BR-A广告此前缀。如果BR-A注意到ISP-Pref-B的撤回（withdraw），它将向ISP-A广告Pref-B。<br />
在本节介绍的实现可能产生少于在那些基于他们的地址前缀过滤的ISP面前的完全的Internet范围的连接性。然而，我们可以观察到这将会是一个问题，而不管机构如何建立它的路由和寻址。<br />
5.2&nbsp;进一步的改善<br />
在前面章节描述的实现允许显著的减少在Internet的“默认－树”区域由多宿主机构引入的路由负担。而在本节描述的实现则允许完全地消除这种影响。<br />
一个机构边缘路由器不仅维护和自己直接相连的ISP的边缘路由器，而且维护在一个或多个它们的边缘路由器直接连接到机构的其它的边缘路由器的ISP内的边缘路由器。我们成这样的对端为“非直连”EBGP。<br />
一个和一个特定的机构同时维护直连和非直连的EBGP对端的ISP将对这两个对端广告同一套路由。一个和一个ISP同时维护直连和非直连的EBGP对端的机构对那个ISP广告此ISP分派给机构的地址前缀。从直接相连的对端那接收到的路由应该较之从非直接相连的对端那收到的ISP的路由为首选。同样的从直接相连的对端那接收到的路由应该较之从非直接相连的对端那收到的机构的路由为首选。<br />
转发从非直接相连的对端那收到的路由应该用封装技术【RFC1773】来实现。<br />
作为一个例子，考虑一个机构连到两个ISP，ISP-A和ISP-B。把将机构连到ISP-A的机构边缘路由器表示为E-BR-A，把将连到E-BR-A的ISP-A边缘路由器称为ISP-BR-A；把将机构连到ISP-B的机构边缘路由器表示为E-BR-B,把将连到E-BR-B的ISP-B边缘路由器称为ISP-BR-B。将ISP-A分派给机构的地址前缀表示为Pref-A；将ISP-B分派给机构的地址前缀表示为Pref-B。E-BR-A维护和ISP-BR-A直接相连的EBGP对端并且向此对端广告到Pref-A的可达性。E-BR-A同时还维护和ISP-BR-B无直接相连的EBGP对端并且向此对端广告到Pref-B的可达性。E-BR-B维护和ISP-BR-B直接相连的EBGP对端并且向此对端广告到Pref-B的可达性。E-BR-B同时还维护和ISP-BR-A无直接相连的EBGP对端并且向此对端广告到Pref-A的可达性。<br />
当机构和这两个ISP（ISP-A和ISP-B）之间的的连通性起来时，目的地为具有Pref-A前缀的主机的流量将会通过ISP-A到ISP-BR-A到E-BR-A，并且最后到机构。同样的，目的地为具有Pref-B前缀的主机的流量将会通过ISP-B到ISP-BR-B到E-BR-B，并且最后到机构。现在，考虑当ISP-BR-B和E-BR-B之间的连接失效时会发生些什么。在这种情况下，到地址前缀为Pref-B的主机的流量按照原先的方法处理。但是，到地址前缀为Pref-A的主机的流量将会从ISP-B流向ISP-BR-B，ISP-BR-B将封装这些流量并传送到E-BR-A，在E-BR-A处，解封在ISP-BR-B封装的流量，然后发送到机构内。下图2以图形的方式描述了这种实现。<br />
使用这种方案，我们可以观察到没有由于多宿主机构而使得额外的路由信息不得不注入Internet的“默认－树”区域。另外，此策略并不会由于ISP基于它们的地址前追究而过滤掉路由的存在而失效。<br />
注意，一个ISP内的一组维护和机构内的边缘路由器非直连对端的路由器并没有严格的被限制为和机构的边缘路由器有直接对端的ISP的那些边缘路由器。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;ISP-A&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;ISP-B&nbsp;&nbsp;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+--------+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|ISP-BR-A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|ISP-BR-B|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+--------+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/+/&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/\&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Pref-B&nbsp;&nbsp;/+/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/+/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\./<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Pref-A&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/+/&nbsp;non-&nbsp;&nbsp;&nbsp;&nbsp;/.\<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;||&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/+/&nbsp;&nbsp;direct&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;/+/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EBGP&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-------+<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|E-BR-A|---------------|E-BR-B&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+------+&nbsp;&nbsp;&nbsp;&nbsp;IBGP&nbsp;&nbsp;&nbsp;+-------+<br />
图2&nbsp;依靠非直连EBGP广告的可达性信息。<br />
5.3&nbsp;综合两种方法<br />
我们能够观察到虽然在5.2节描述的实现允许完全的消除由于多宿主机构给Internet上的“默认－树”区域带来的路由负担，但它可能在链路失效时导致一个不是最优化的路由。这种非最优化可以通过结合5.2节描述的实现和5.1节描述的加一些轻微修改的实现来减轻。修改包括限制一个边缘路由器广告的额外路由器的范围，当路由器检测到通过它的其它边缘路由器到Internet连接性的问题时。一个限制这样的范围的方法是使用BGP团体属性（Community&nbsp;attribute）【RFC1997】。<br />
5.4&nbsp;稳定状态下的更佳（更优化的）路由<br />
本文档描述的实现假定，在一个稳定的状态下，一个机构的边缘路由器会向一个直接连接的ISP边缘路由器只广告此ISP分派给机构的地址前缀的可达性。这样做的结果便是由连接到此ISP的其它机构产生并路由到非其它地址前缀机构部分的流量不会在这个边缘路由器进入机构，这导致潜在的非优化路径。为了改变此情形，边缘路由器可以（处于稳定状态）不仅广告此和此路由直接相连的ISP分派的地址前缀，而且广告由一些其它ISP（和机构的其它边缘路由器直接相连）分派的地址前缀。这样的广告报文的分发应该要谨慎，否则这可能会导致在Internet的“默认－树”区域要维护显著增多的额外路由信息。一个限制这样的广告报文的分发的一种方法是使用BGP的团体属性【RFC1997】。<br />
6&nbsp;和其它实现方法的比较<br />
CIDR【RFC1518】建议了好几个为连接到多ISP的多宿主机构的可能的地址分派策略。以下简要的回顾目前正在使用的可选方法，并且拿它们和上面描述的实现加以比较。<br />
6.1&nbsp;解决方法1<br />
在【RFC1518】中建议的一个可能的解决方法是对于每一个各自独立的从它所连接的ISP那获得它的IP地址前缀空间的多宿主机构。这允许每个多宿主机构基于一个单一的前缀的IP分配和依靠一个单一前缀概况一组所有IP地址到机构的可达性信息。这种实现方法的优点在于机构的IP地址和任何特定的ISP的地址之间没有联系，由机构广告的可达性信息并不和除了默认路由外的任何其它路由聚合。这在Internet的“默认－树”区域0(N)的路由负担，其中N是穿过整个Internet的连接到多个ISP的多宿主机构的总体数目。<br />
作为一个结果，这种实现不能够被视为一个对除了提供高度足够程度的寻址信息集聚的机构外的所有机构都可行的可选方案。<br />
6.2&nbsp;解决方法2<br />
另外一个可行的解决方法，在【RFC1518】中建议的，是给每个多宿主机构基于其连接的多个ISP中的一个分派一个单一地址前缀。多宿主机构连接的其它ISP为组织维护一个路由表项地址前缀，这非常的有选择性在于其它的ISP被告知此路由并且会执行“代理”集聚。和此实现相关的大部分复杂性在于执行“代理”集聚的需求，而这正依次需要额外的ISP间的协调和更为复杂的路由器配置。<br />
7&nbsp;讨论<br />
在本文档描述的实现假定一个机构可能使用的地址是基于“地址主导（address&nbsp;lending）”策略分配。因而，只要一个机构改变它的ISP，此机构就会需要对它的部分网络进行重新编号，这些网络原先是用此ISP分配给机构的地址块进行的编号。然而，这些方面并不是多宿主所特有的，而应该认为是当前因特网公认的实际。本文档所描述的实现有效的消除了任何在单宿主和多宿主机构间的区别，这是在设计改变ISP时重编号的影响。<br />
本文档描述的实现也需要在机构内仔细的地址分配，这是由于地址分配会影响流量在机构和它的所有ISP间多个连接的分发。<br />
地址分配和重新编号的两个方面都会在使用网络地址转换（NAT）时设计到。在多宿主机构内使用NAT超出了此文档的讨论范围。<br />
使用自动路由注入（在5.1节所描述）增加了在Internet的默认树区域的路由数量，和使用提供者－无关地址相比（6.1节所描述的），这会在改变多宿主机构的连接性时收到影响。显而易见，使用自动路由注入，当一个多宿主机构失去它和它的所有ISP中的一个间的连通性时，自动注入路由不得不传播到所有在Internet的默认树区域内的路由器。相反，当一个机构使用提供者－无关地址时，只有一些（不是所有）在默认区域的路由器会看到在一个多宿主机构失去它和它的所有ISP中的一个间的连通性时路由的变化。<br />
为了减少由于链路失效带来的路由负担，自动注入路由不得不被广告直到依靠的其它连接（此连接先前失效且导致了自动路由注入）的连通性变得稳定。<br />
使用非直连的EBGP实现（在5.2节描述）允许消除由于在Internet的默认－树区域的多宿主机构而引起的路由变化。这也就是说，非直连EBGP实现有更好的特性，考虑到比使用提供者－无关地址（在6.1节所介绍的）更好的路由稳定性<br />
8&nbsp;多宿主ISP的应用<br />
在此文档中描述的实现可以应用到一个小到中等大小的ISP，此ISP连接到多个上行ISP。此ISP将会从它的多个上行ISP那获得一些地址块（地址前缀），并且将使用这些地址分配给它的客户。不管是自动路由注入，是非直连EBGP实现，还是两者的结合都可能被此ISP使用，当和它的上行ISP对端时。这样做会为它的客户提供路由能力而没有影响整个Internet路由体系的伸缩性。<br />
9&nbsp;安全性考虑<br />
由于非直连EBGP的实现（在5.2节描述）需要在彼此间超过一个IP跳数的路由器间的EBGP会话，维护这些会话的路由器应该为BGP对端认证使用一个恰当的认证机制。<br />
和IBGP对端相关的安全性，同彼此间超过一个IP跳数的路由器间的EBGP对端的安全性一样都超出了此文档的范围。<br />
10&nbsp;致谢<br />
此文档的作者没有对在此文档中描述的想法做任何版权所有的要求。任何先前考虑到这些方法的人都应该得到所有应得的权利。<br />
参考<br />
&nbsp;[RFC1518]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"An&nbsp;Architecture&nbsp;for&nbsp;IP&nbsp;Address<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Allocation&nbsp;with&nbsp;CIDR",&nbsp;RFC&nbsp;1518,&nbsp;September&nbsp;1993.<br />
&nbsp;[RFC1771]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"A&nbsp;Border&nbsp;Gateway&nbsp;Protocol&nbsp;4&nbsp;(BGP-4)",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;1771,&nbsp;March&nbsp;1995.<br />
[RFC1773]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hanks,&nbsp;S.,&nbsp;Li,&nbsp;T.,&nbsp;Farinacci,&nbsp;T.,&nbsp;and&nbsp;P.&nbsp;Traina,&nbsp;"Generic<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Routing&nbsp;Encapsulation&nbsp;over&nbsp;IPv4&nbsp;networks",&nbsp;RFC&nbsp;1773,&nbsp;October<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1994.<br />
[RFC1918]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rekhter,&nbsp;Y.,&nbsp;Moskowitz,&nbsp;B.,&nbsp;Karrenberg,&nbsp;D.,&nbsp;de&nbsp;Groot&nbsp;G.J.,&nbsp;and<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E.&nbsp;Lear,&nbsp;"Address&nbsp;Allocation&nbsp;for&nbsp;Private&nbsp;Internets",&nbsp;RFC&nbsp;1918,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;February&nbsp;1996.<br />
[RFC1997]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Chandra,&nbsp;R.,&nbsp;Traina,&nbsp;P.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"BGP&nbsp;Communities&nbsp;Attribute",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC&nbsp;1997,&nbsp;August&nbsp;1996.<br />
[RFC2008]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"Implications&nbsp;of&nbsp;Various&nbsp;Address<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Allocation&nbsp;Policies&nbsp;for&nbsp;Internet&nbsp;Routing",&nbsp;BCP&nbsp;7,&nbsp;RFC&nbsp;2008,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;October&nbsp;1996.<br />
作者地址：<br />
Tony&nbsp;Bates<br />
Cisco&nbsp;Systems,&nbsp;Inc.<br />
170&nbsp;West&nbsp;Tasman&nbsp;Drive<br />
San&nbsp;Jose,&nbsp;CA&nbsp;95134<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;tbates@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;Yakov&nbsp;Rekhter<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;170&nbsp;West&nbsp;Tasman&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;CA&nbsp;95134<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;yakov@cisco.com<br />
currently&nbsp;provided&nbsp;by&nbsp;the&nbsp;Internet&nbsp;Society.<br />
完整的版权声明<br />
Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2000)。版权所有。<br />
本文档及其译文可以拷贝和提供给他人，且其衍生物，如评论、解释或帮助实施的作品可以全部或部分地定制、拷贝、出版和发布，对此我们不加任何限制，前提是上述版权声明，及本段内容包含在所有的拷贝和派生作品中。然而，本文档本身不允许以任何方式修改，例如删除Internet社团或其他Internet组织的版权声明或参考，除非是为了开发Internet标准的需要。即便在这种情况下，也需要添加Internet标准中定义的版权声明，或者根据需要把他翻译成英语以外的其他语言。<br />
上述准许的有限许可是永久性的，&nbsp;无论是Internet社团以及其继承者或代理者都将不会废止这些许可。<br />
本文档及其中包含的信息基于“AS&nbsp;IS”提供，而且INTERNET社团和IETF拒绝所有授权、表达或影射，包括但不限于任何这里使用的消息的授权将不会违背任何版权或者隐含的商业性授权或对特定的合理目的。<br />
致谢<br />
目前，RFC编者活动的基金由Internet社团提供。<br />
RFC2260——Scalable&nbsp;Support&nbsp;for&nbsp;Multi-homed&nbsp;Multi-provider&nbsp;Connectivity&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;对多宿主的多提供者连接的可扩展性支持<br />
<br />
<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />
<br />