RFC925_成都软件开发公司

RFC925

作者：zhaozj
发表时间：2020-12-23 10:56
来源：未知

组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：15222775@61. (15222775@61. hbzzx2001@yahoo.com.cn) 译文发布时间：2001-11-24 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。 Network Working Group J. Postel Request for Comments: 925 ISI October 1984 多局域网地址解析（RFC925——Multi-LAN Address Resolution）备忘录状态此备忘录受Jeffery Mogul 在关于“互联网自网”的RFC917触发而作。在那个备忘录中，Mogul创建了一个多局域网环境下的“显式子网”应用案例。本备忘录中，我力求建造一个“透明子网”的案例。这个RFC建立了一个由ARP网组织提交的协议，并请求讨论和提交意见以便进一步改善。本备忘录的发行不受约束。目录介绍 1 概论 1 总结 6 术语表 6 参考文献： 8 介绍将一组局域网（LAN）作为单个互联网处理的问题已经引起广泛关注和兴趣。在同一地点内的局域网都给与一个截然不盒子同的网络号，这是不妥当的。令人满意的做法是，对人员，网关和外部主机而言，地点内各局域网间的细节是隐蔽的。面临的问题是最好怎么做，甚至上究竟怎么做。一个建议是使用“显式子网[1]"。显式子网方案是一个把互联网用于管理多个网络的机制应用到在一个网络内的各局域网的管理问题上的一个叫法。请注意，我强烈推荐另一个方法：使用一个由多局域网地址解析协议扩展所支持的“透明子网”。概论迅速复习一下地址解析协议（ARP）。广播型局域网上的每个主机不但知道它的局域网物理地址（HA）同时还知道它的互联网地址（IA）。当主机A得到主机B的IA 地址并向他发送一个数据报时，主机A必需知道与主机B相对应的HA。为了达到这个目的，ARP包A产生一个ARP包，其中含有它自身的IA和HA地址以及目标主机（主机B）的IA。主机A广播这个ARP包。收到此ARP包的主机检查此包，以确定它们是否为被寻主机。如果是，他们（实际只有主机B）发送一个地址指向发出请求者（主机A）的提供所需的HA地址的应答。现在，主机A已经取得了目的地（主机 B）的所有IA,HA地址了。为了将来使用，主机A将这条消息加到它的缓存中。注意，ARP实际上比这个简要概述更为概括。此备忘录的观点是扩展ARP，使得它能够在一个局域网互联环境中工作。为了弄明白他是怎样工作的，我们试想有一个“魔盒”，他就像一个平常主机一样连在两个或多个LAN上。各主机的行为应该与在基本ARP中的行为严格一致。当任何主机广播一个ARP请求时，盒子读取它（如同局域网上所有主机一样），盒子检查它的缓存，缓存中保存了每个局域网的IA:HA地址映射，然后判断它是否为正在寻找的那个（是，就给以答复）。情况1：要是在发出请求的局域网所对应的缓存中找到了这个主机映射时，盒子不应答。情况2：要是在非发出请求的局域网所对应的缓存中找到了这个主机映射时，盒子发出一个应答，给出他自己在发出请求的局域网内的HA地址。盒子作为目的主机的一个代理。情况3：要是任何缓存中都找不到那个映射，盒子必须尽力找出这个地址，然后象情况1或情况2那样做出反应。在情况3中，盒子不得不表演一些魔术：盒子保持一张被寻主机搜索表。每个表项包含被寻主机的HA地址以及原始请求主机的源地址和接收此ARP的接口。当情况3发生时，就检查这个搜索列表。如果被寻主机已经列入此搜索列表中，就结束；否则，传播此表。为了传播此搜索列表，先把一个表项写在这个搜索列表上，然后组织并在除了收到“引起搜索的ARP”包的接口之外的所有接口上发出这个ARP包。如果收到一个应答，信息会被输入到相应相应缓存中，相应表项在搜索列表中删除，然后象情况1或情况2那样给那个“引起搜索的ARP”一个回答。如果没有收到响应，停止并且不作任何事情——没有回答发给那个“引发”主机（表项仍然留在搜索列表中）。为了终止搜索，停止并且不作任何事情——没有回答发给那个“引发”主机（表项仍然留在搜索列表中）。缓存和搜索列表中的表项很可能超时。对于收到的每一个ARP请求，盒子还必须把发送主机的IA:HA地址映射放入接收它的局域网所对应的缓存中。多局域网地址解析这个计划使用的还是ARP,新的成分不过是“魔盒”（“基于ARP 的桥"）,它将ARP 请求中继到相邻局域网，以便将数据报中继到其他局域网上的主机而充当代理。细节主机的行为应该与在基本ARP中的行为严格一致。局域网由“魔盒”（一些象主机一样连到局域网上的与两个或更多局域网连接的计算机）。盒子执行一下程序。各个盒子为它所连接的每个局域网（或每个局域网接口）保持一个列表。因为表项回超时，所以表项应当是近期信息的缓存。这些表项是各个局域网的 IA:HA地址对。当一个ARP请求被任意一个主机广播时，盒子读取它（如同局域网上所有主机所作的那样）。另外，还要进行检查，看看他是否为被寻找机（如果是就应答）。盒子检查它为每个所连局域网保持的IA:HA地址映射表的缓存。情况1：要是在发出请求的局域网所对应的缓存中找到了这个主机映射时，盒子不应答（让被寻主机自己响应）。表项超时不再重置。情况2：要是在非发出请求的局域网所对应的缓存中找到了这个主机映射时，盒子发出一个应答，给出他自己在发出请求的局域网内的HA地址。表项超时不再重置。在这种情况下，盒子作为目的主机的一个代理。当一个IP数据报道打这个盒子时，盒子必须尽力用地址映射缓存中的信息去转发它。情况3：要是任何缓存中都找不到那个映射，盒子必须尽力找出这个地址，然后象情况1或情况2那样做出反应。盒子保持一张被寻主机（但没找到）搜索表。每个表项包含被寻主机的HA地址以及原始请求主机的源地址和接收此ARP的接口。当情况 3发生时，就检查这个搜索列表。如果被寻主机已经列入此搜索列表中，就结束；否则，传播此表。为了传播此搜索列表，先把一个表项写在这个搜索列表上，然后组织并在所有接口上发出这个ARP包。这些ARP请求含有盒子的HA,IA 地址，被寻主机的IA地址以及对被寻主机HA地址的请求。如果收到此ARP应答，此信息会被输入到相应缓存中，将相应表项在搜索列表中删除，然后象情况1或情况2那样给那个“引起搜索的ARP”主机一个回答。如果没有收到响应，停止并且不作任何事情——没有回答发给那个“引发”主机（表项仍然留在搜索列表中）。注意：盒子必须用它的ARP请求进行适当次数的尝试，如果普通主机ARP请求通常进行5次尝试，那么它也应为此ARP进行5 次尝试。为了终止搜索，停止并且不作任何事情——没有回答发给那个“引发” 主机（表项仍然留在搜索列表中）。不存在发送给ARP请求的否定性反馈信息，所以除了超时手段以外没法判断搜索的成功情况。对于收到的每一个ARP请求，盒子还必须把发送主机的IA:HA地址映射放入接收它的局域网所对应的缓存中。缓存和搜索列表中的表项可能超时。为了维护搜索列表而必须遵循的终止原则是：避免为一个没有响应的主机无穷尽地中继ARP请求。一旦主机列入搜索列表，ARP请求讲不被中继。如果一个停机的（或其他不响应ARP请求的）主机开机（或开始响应ARP请求），那末，在表项超时之前，对其他网络上的主机而言它一直是不可用的。对此问题有两个办法：第一是搜索列表表项超时周期变短。第二是让盒子为搜索列表表项周期性的发送ARP。方案中有几个超时。首先，主机尽力用ARP来进行地址解析。如果主机没有被响应，他们可能在得到之前进行多次尝试。我们还必须给主机在尝试其间的时间长度（把它称为时间T1）建立一个好的评估方法。其次，还有表项停留在列表中的时间或从盒子产生ARP道地址得到解析这段时间。称为时间T2。注意：这个时间段T2必须大于局域网最大回路中的T1时间之和。再次，表项在每个局域网的缓存中停留时间，称为时间T3。他们之间的关系必须满足：T!<T2<T3。一个建议是T1小于1分钟，T2小于10分钟，T3小于1小时。如果环境非常稳定，使T3变长可以导致搜索次数变少（ARP流量的开销变小）。如果环境不很稳定，使得T3变短能更快的适应变化。另外一个方案是，每次引用时缓存中表项的计时器，并建立一个较小的T3值。这会导致频繁使用的表项停留在缓存中，但很少使用的表项很快就会被丢掉。不幸的是，频繁使用和正确性之间不存在必然联系。它还会导致缓存中的一个过时表项保存很长一段时间表项，如果今已经收到地址映射ARP请求正好小于超时周期。处理定期的数据报时，盒子回消耗IP数据包的生存时间（TTL）和更新IP数据包的头部校验和。如果TTL变成0，数据包就会被丢弃（不转发）。 ARP（按照当前的定义）最好能得到最多的近期的和过时的信息。（存在连通回路的）复杂的多局域网环境中一个位于其他局域网上的主机可能得到两个（或更多）ARP请求的回答。第一个回答可能来自盒子，这是最有效的一个路径。这里暗示了一个ARP主机信息的改变，防止更迟的信息替代了第一个回答。可能出现的问题不合法的缓存表项如果错误的信息进入了缓存表项，它将逗留一些时间（T3）。旧信息的存在会阻止通信（一会儿），如果主机改变了它的HA：IA地址映射。取代缓存中的非法或超时表项的方法是，让盒子明确的把广播的ARP应答解释为请求一个已经用较新的HA:IA映射替换了原有的HA:IA映射的一个表项。还要一个重要的服务器，用于在他们出现时发送（广播ARP应答）。非ARP主机在同一局域网上全部为ARP主机或非ARP主机是不太实际的，所以只好寄希望于他们能够相互通信。所有主机为非ARP主机的情形将在下一个标题中得到考察。不能实现ARP的主机必须使用其它的地址映射方法。他们要末保存一个所有主机的完整表，要么通过某个协议访问服务器中的上述表，要么指望根据地址域中的分析所做的路由判断。非广播局域网如果盒子所连接的局域网不具备广播能力或者局域网上的主机不能响应 ARP，那么，为那个局域网（或可以从另一个地址算出的地址）建立一个静态或动态的HA:IA地址表。域网上的主机必须全部列于表内。当盒子可以找到地址映射并将另外发送一个ARP请求进入非广播局域网（只有在所有主机都列入表内而被寻主机位于非广播局域网上时才有可能发生）时，它改为专门给那个局域网上的每个盒子发送一个ARP类型请求。表的尺寸盒子中最坏的表尺寸是一个表为所有局域网中的主机数。即，为每个局域网接口所维护的表可能（在最坏的情况下）增大到位整个局域网上的每个主机建立一个表项。然而，这些表实际上满足当前通讯活动所需的表项的缓存，并且这个典型化的情况远远不是最坏的。大多数主机主要与他们局域网的主机通信而很少跟其他局域上的主机通信。局域网上的大部分通信是工作站主机和服务器主机之间的通信。我们期望包括主服务器主机和其他服务器主机的高频通信放入大部分盒子的列表中。无穷传输回路贯穿局域网互连集合的无穷传输回路的可能性可以通过维护盒子中的搜索列表和当一个地址请求收到而已列入列表中时终止搜索来避免。周期性数据包的传输回路不可能持续，因为盒子必然消耗TTL，当数据包的 TTL为0时就会被丢弃。为了进行调试，对一个盒子来说向其实现程序报告所有数据报被丢弃的原因是十分有用的。广播请注意广播实际上没有对透明子网或显式子网做任何事情。在[1]中已经讨论过，这里将再一次讨论。在[1]中指出的三个广播功能中的两个与这里的完全一致而且具有相同的结果。第三个也给于支持。对于IA地址解析的广播已经讨论过，显式子网和透明子网也是个较大的争论点，应当分别对待。它还暗示实际上我们并不需要广播技术，相反，多点播送技术具有跟好的功能。在接受广播技术之前了解一下互联网多点播送是如何工作的是明智之举。 IP网络如果使用了IA网络号且主机号全为1（如，36.255.255.255）,IP将向这个网络（即，本地局域网）的所有主机进行广播，这已经被预定好了。盒子将转发这个数据报。盒子将检查这个数据报，看它是否具有潜在的意义。为防止无穷传输回路，盒子必须维护一个当前广播列表。表中各项包含来自数据报头部的源IA和鉴定域。要是收到一个广播并且列表中已删除的一项项相匹配的话，不予转发。表项的超时时间为T2。本局域网 IA所有位均为一（如，255.255.255.255）预定用于仅向本局域网上的所有主机进行IP层广播。盒子不得转发此数据报。盒子必须检查此数据报对它的潜在意义。其他局域网由于一些局域网没有在IA中单独指示，所以不能用这种方法。一些人已经讨论过这个问题，认为它是一个无聊的功能。提供它的一个方法时，给每个想在其上广播的局域网建立一个特殊的IA。如， 36.255.255.128意味着在A局域网上广播而36.255.255.187意味着在B局域网上广播，等等。这些地址连接到具备专用解释的专用局域网上的盒子专门解释。其他盒子应向对待其他盒子一样来处理这些地址。专门解释这些地址的地方被转换成这个局域网的广播进行传播。讨论这个扩展ARP的要求是一般主机根本就不知道它位于多局域网环境中。若主机在分析它的IA:HA地址映射时本地缓存出现障碍，它也许能找到几个到同一HA的IA映射。并且他若采取计时测量，可能发现一些主机的延迟较其他短。进一步，它有可能找出这些发现之间的内在联系。但很少有主机会遇到这些麻烦。地址结构在显式子网方案中，有些IA位被专用于确定子网（如局域网）。地址分成网络，子网和主机域。通常，各域的应用似的地址空间内的分配地址密度有所下降，即地址空间的利用率网降低了。主要的实现问题可能出现，如果安装的子网多于规划的并且这样必须改变子网域。对于使用具有C类IA地址的现实子网方案而言看上去完全是不可能的。对于扩展ARP方案，地址中的网络和主机域是简单的。扩展ARP方案可用于任何类型的IA地址。主机重定位技术在显式子网方案中，当主机从一局域网拔出并插入另一个局域网时，它的IA 必须改变。对于扩展ARP方案，在这个情况下依旧使用原来的IA地址。通过各种情况的考察，我们看到实际上存在两个问题来： 1．如果目标位于本局域网或其他局域网上时，怎样找到主机？这种情况假定主机了解这两种情况的差异并且知道在那种情况下应该做什么用的事情？进一步而言，主机不但要知道是否要回答他而且还要知道怎样发送数据（如，直接给主机，或盒子）。这里要求主机不知道差异并且并且总做同一件事情。 2．连接局域网的盒子怎样了解哪一个盒子是到哪一个局域网的通道。 3．这种情况假定盒子需要一些拓扑知识并且互换关于连通性的盒子到盒子的协议信息。这里要求盒子不知道拓扑知识并且不用明确知道青它盒子的存在。这里暗示了存在的两个问题：首先，主机怎样进行路由；其次，盒子怎样进行路由。要求的策略大会每个问题运用一个方法，而且，应选一个方案，一部分来自一个方法一部分来自另一个方法。例如：在局域网内部使用ARP,让盒子发送ARP应答并且充当代理（象在扩展ARP方案中一样）。但通过盒子到盒子的协议来使用“哪个书记在哪儿”的信息进入各个盒子（如同显式子网方案一样）。有两个含有代码的地方：大量的主机和少量的盒子。考虑到显式子网方案和扩展ARP方案的交替使用，主机内的工作量重于盒子内的工作量。主机做什么？显式子网方案主机必须判断IA是位于局域网上还是位于其他局域网上。要是位于本局域网上，则使用某些程序去找到这个IA；要是位于其他局域网上，则使用某些程序去找到盒子的IA地址。扩展ARP方案无论哪一个情况都是使用ARP去获得IA:HA映射。盒子做什么？显式子网方案盒子必须判断主机是位于本地内的哪一个局域网上。它必须建立路由表以告诉每个局域网使用本的内的哪一个接口发送数据报。这个路由表必须保持直至过时，盒子到盒子协议于互联网上的网关到网关协议非常相似。扩展ARP方案盒子必须为每个相连的局域网的IA:HA映射维护缓存，还得保持一个搜索列表。他不用运行任何盒子到盒子协议甚至不知道任何其他盒子的存在。拓扑结构及其实现的复杂性树如果局域网和盒子组成树状结构，盒子就非常简单，根本不用保持搜索列表，因为不会有任何ARP请求回路来回移动。回路如果内部产生了回路，那末搜索表是必要的。如果拓扑保持的相当稳定，以至于不存在很长的回路（所有回路具有相同的尺寸），并且各局域网在延迟上保持兼容，那末这里描述的程序将工作的很好。复杂性如果结构非常复杂，结构不稳定，并/或有许多延迟差距很大的不同类型的局域网混合组成，那么使用盒子到盒子协议是比较好的选择。总结如果互联网组织能在多局域网问题上达成一致并用同一中声音催促工作站制造商建立基于此的解决方案，这是非常有益的。我强烈推荐在此详述的扩展ARP方案。我认为大部分工作站将连接到具有广播能力的局域网上。我认为大部分工作站将用于不使用显式子网方案的地方，并且将用在合适的（显式子网难以忍受的）C类IP 地址的环境中。因此我认为请制造商在工作站上支持ARP是最好的方法。我还认为我们应该开始工作并创造，开发，测试并生产“魔盒”，我如此强烈的建议是因为他们极其有用的。请注意：只各注释和[1]都没有提出一个详细的路由程序或盒子到盒子协议。这是因为这样一个路由程序是非常困难的问题。这里提供的建议将使我们着手用合理的方法应用多局域网环境。如果今后我们确定了一个用在盒子之间的路由程序，我们只需重做盒子而不必重做主机。术语表 ARP 地址解析协议（见[1]）。盒子魔盒。盒子（计算机）连接同一个网络的一个或多个局域网。还可以叫做“基于 ARP的桥”。桥一个节点（计算机），连接两个或多个管理上不易觉察的但物理上相隔甚远的子网，必要时自动转发数据报，但去他主机不知道它的存在。又叫做“软中继器”。数据报 IP层上的通信单元。显式子网一个子网，IP地址由一个子网地址域显式标示，并且对本的和外地网络来说都是可见的。网关一个节点（计算机）连接两个或多个易管理相隔甚远的网络和/或子网，转发主机传给它的数据报。 HA 硬件地址，此地专用于局域网的包内。主机号网络内部主机地址，IA的低字节部分。 IA 互联网地址，由IP定义。互连网互联网络（如著名的CATENET）的集合。一组使用IP进行互连的网络。 IP 互联网协议（见[3]）。 LAN 局域网。多局域网网络被视为一个网络的一组局域网，如，一般使用一个网络号。单个局域网即可以实显式子网或可以是透明子网。网络单一的互联网（很可能分成子网或有多个局域网组成），用单个网络号给于指示。网络号一个IP网络号，IA的高字节部分。包局域网硬件层的通信单元。子网一个网络的子网。网络（逻辑的或物理）的一部分。透明子网不用互联网地址表示的子网，因此对其他网络而言是不可见的（见多局域网网络）。 TTL IP的生存时间域。参考文献： [1] J. Mogul, "Internet Subnets", RFC-917, Stanford University, October 1984. [2] D. Plummer, "An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Addresses for Transmission on Ethernet Hardware", RFC-826, Symbolics, November 1982. [3] J. Postel, "Internet Protocol", RFC-791, USC-ISI, September 1981. RFC925——Multi-LAN Address Resolution 　　　　　　多局域网地址解析 1 RFC文档中文翻译计划