Network Working Group                                         J. Luciani
Request for Comments: 2336                                  Bay Networks
Category: Informational                                        July 1998
        
Network Working Group                                         J. Luciani
Request for Comments: 2336                                  Bay Networks
Category: Informational                                        July 1998
        

Classical IP and ARP over ATM to NHRP Transition

ATM上的经典IP和ARP到NHRP的转换

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 (1998). All Rights Reserved.

版权所有(C)互联网协会(1998年)。版权所有。

Abstract

摘要

This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM.

本文件描述了通过ATM从ATMARP LIS[1]到NHRP LIS[2]网络模型的优雅过渡的方法和过程。

1. Introduction
1. 介绍

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [6].

本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时,应按照[6]中的说明进行解释。

ATMARP defines an initial application of classical IP and ARP in an ATM network environment configured as a LIS[1]. ATMARP only considers application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers operating in the "classical" LAN-based paradigm.

ATMARP定义了经典IP和ARP在配置为LIS的ATM网络环境中的初始应用[1]。ATMARP仅将ATM的应用视为直接替代连接IP终端站和路由器的“电线”和本地LAN段,这些路由器以“经典”LAN为基础运行。

The NBMA Next Hop Resolution Protocol (NHRP) allows a source station (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" toward a destination station. If the destination is connected to the NBMA subnetwork and direct communication is administratively allowed, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. For the purposes of this document, the NBMA network is of type ATM.

NBMA下一跳解析协议(NHRP)允许希望通过非广播多址(NBMA)子网进行通信的源站(主机或路由器)确定朝向目的站的合适“NBMA下一跳”的网络间层地址和NBMA地址。如果目的地连接到NBMA子网,并且管理上允许直接通信,则NBMA下一跳是目的地站本身。否则,NBMA下一跳是来自“最近”到目的站的NBMA子网的出口路由器。就本文件而言,NBMA网络为ATM类型。

It is reasonable to expect that ATMARP Clients and NHRP Clients will initially coexist within a LIS. Thus, it is necessary to define a graceful transition, including a period of coexistance, from the use of ATMARP to the use of NHRP for address resolution in the LIS [1][2]. In short, NHSs will be required to respond to ATMARP Client queries in a fashion which will permit continued use of the ATMARP Client within the LIS during the ATMARP to NHRP transition period. Note that this document places no protocol requirements upon ATMARP[1] servers.

可以合理预期,ATMARP客户机和NHRP客户机最初将在LIS内共存。因此,有必要定义一个优雅的过渡,包括共存期,从使用ATMARP到使用NHRP在LIS中解析地址[1][2]。简言之,NHS将被要求以允许在ATMARP到NHRP过渡期间在LIS内继续使用ATMARP客户端的方式响应ATMARP客户端查询。请注意,本文件未对ATMARP[1]服务器提出任何协议要求。

For the following, it will be assumed that the reader is familiar with the terminology as described in [1][2][3].

对于以下内容,假设读者熟悉[1][2][3]中所述的术语。

2. Service Requirements
2. 服务要求

If NHRP is to be used in a LIS then only NHSs will be used in the LIS; that is, there will not be a mixture of NHSs and ATMARP servers within the same LIS. Since ATMARP servers will not be able to understand NHCs and since, as described below, NHSs will respond to ATMARP Clients, this is a reasonable simplifying restriction.

如果在LIS中使用NHRP,则仅在LIS中使用NHSs;也就是说,在同一个LIS中不会混合使用NHSs和ATMARP服务器。由于ATMARP服务器无法理解NHC,并且如下文所述,NHS将响应ATMARP客户端,因此这是一个合理的简化限制。

This document will only address SVC based environments and will not address PVC environments. This document will refer only to ATM AAL5 as the NBMA and IP as the protocol layer since ATMARP only addresses these protocols.

本文档仅针对基于SVC的环境,而不针对PVC环境。本文件仅将ATM AAL5称为NBMA,将IP称为协议层,因为ATMARP仅处理这些协议。

2.1 NHRP Server Requirements
2.1 NHRP服务器要求

If NHRP Servers (NHS) are to be deployed in a LIS which contains both ATMARP Clients and NHRP Clients then NHSs MUST respond to ATMARP_Requests sent by ATMARP Clients in the same fashion that an ATMARP Server would respond as described in [1]. To do this, the NHS MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-AA-03, OUI=0x00-00-00, and ethertype=0x08-06. Further, the NHS MUST recognize the packet formats described in Section 8.7 of [1]. However, since this document does not extend to PVC environments,

如果NHRP服务器(NHS)部署在包含ATMARP客户端和NHRP客户端的LIS中,则NHS必须以ATMARP服务器响应[1]中所述的方式响应ATMARP客户端发送的ATMARP_请求。为此,NHS必须首先识别LLC=0xAA-AA-03、OUI=0x00-00-00和ethertype=0x08-06的LLC/SNAP ATMARP代码点。此外,NHS必须识别[1]第8.7节中描述的数据包格式。但是,由于本文件不适用于PVC环境,

NHSs MUST only receive/respond to values of ar$op of 1,2,10 (Decimal). If an NHS receives an ATMARP message with ar$op values other than those previously noted then the NHS MUST discard the packet and MUST NOT take any further action.

NHS必须仅接收/响应ar$op为1,2,10(十进制)的值。如果NHS接收到一条ATMARP消息,该消息的ar$op值与之前记录的值不同,则NHS必须丢弃该数据包,并且不得采取任何进一步的行动。

When an NHS receives a valid (as defined in the previous paragraph) ATMARP_Request packet, the NHS MUST follow the rules described in Section 8.4 of [1] with the following additional processing:

当NHS收到有效的(如前一段所定义)ATMARP_请求数据包时,NHS必须遵循[1]第8.4节所述的规则,并进行以下附加处理:

1) When an ATMARP_Request causes a new table entry in the NHS for an ATMARP Client, that table entry MUST be marked as being of type "ATMARP" so that it can be differentiated from an NHRP sourced entry.

1) 当ATMARP_请求导致在NHS中为ATMARP客户端创建新的表条目时,该表条目必须标记为“ATMARP”类型,以便与NHRP来源的条目区分开来。

2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if that ATMARP_Request contains an off-LIS protocol address. This should never happen because the IP stack on the requesting machine should automatically send the packet to the default router. If this does occur then the ATMARP_Request MUST cause an ATMARP_NAK to be sent to the originator.

2) 如果ATMARP_请求包含非LIS协议地址,则ATMARP_请求不得导致发送ATMARP_回复。这种情况永远不会发生,因为请求机器上的IP堆栈应该自动将数据包发送到默认路由器。如果确实发生这种情况,则ATMARP_请求必须导致将ATMARP_NAK发送给发起人。

In [1], an ATMARP_Request packet also serves as a registraion/registration-update packet which would cause a server to add an entry to a server's cache or to update a previously existing entry. When an NHS receives an ATMARP_Request which causes the creation of a new cache entry in the NHS or updates an existing entry then that cache entry will have a holding time of 20 minutes (this is the default value in [1]).

在[1]中,ATMARP_请求数据包还用作注册/注册更新数据包,这将导致服务器向服务器缓存添加条目或更新以前存在的条目。当NHS收到ATMARP_请求,导致在NHS中创建新的缓存条目或更新现有条目时,该缓存条目的保持时间为20分钟(这是[1]中的默认值)。

An NHS receiving an NHRP Resolution Request MUST NOT send a positive NHRP Resolution Reply for a station which registered via ATMARP if the station sending the NHRP Resolution Request is outside the LIS of the station which registered itself via ATMARP. This is because the station which registered via ATMARP is almost certainly not prepared to accept a cut-through. When this occurs, the replying NHS must send NHRP Resolution Reply which contains a CIE code of "4 - Administratively Prohibited" as described in [2]. This type of reply does not preclude the station sending the NHRP Resolution Request from sending its data packets along the routed path but it does preclude that station from setting up a cut-through VC.

如果发送NHRP解决请求的站点位于通过ATMARP注册的站点的LIS之外,则接收NHRP解决请求的NHS不得向通过ATMARP注册的站点发送积极的NHRP解决回复。这是因为通过ATMARP注册的电台几乎肯定不准备接受直通。发生这种情况时,回复的NHS必须发送NHRP决议回复,其中包含CIE代码“4-行政禁止”,如[2]所述。这种类型的回复不会阻止发送NHRP解析请求的站点沿路由路径发送其数据包,但会阻止该站点设置直通VC。

2.2 Multi-server environments
2.2 多服务器环境

Since NHRP servers may work in a multi-server environment on a per LIS basis during the transition, it is necessary to know how cache synchronization occurs. These rules may be found in [5].

由于NHRP服务器在转换过程中可能会在基于每个LIS的多服务器环境中工作,因此有必要了解缓存同步是如何发生的。这些规则可在[5]中找到。

3. Security Considerations
3. 安全考虑

Not all of the security issues relating to IP over ATM are clearly understood at this time, due to the fluid state of ATM specifications, newness of the technology, and other factors.

由于ATM规范的流动性、技术的新颖性和其他因素,目前并非所有与IP over ATM相关的安全问题都被清楚地理解。

It is believed that ATM and IP facilities for authenticated call management, authenticated end-to-end communications, and data encryption will be needed in globally connected ATM networks. Such future security facilities and their use by IP networks are beyond the scope of this memo.

人们相信,在全球连接的ATM网络中,将需要用于认证呼叫管理、认证端到端通信和数据加密的ATM和IP设施。此类未来安全设施及其在IP网络中的使用超出了本备忘录的范围。

There are known security issues relating to host impersonation via the address resolution protocols used in the Internet [4]. No special security mechanisms have been added to ATMARP. While NHRP supplies some mechanisms for authentication, ATMARP does not. Since any security mechanism is only as good as its weakest link, it should be assumed that when NHRP and ATMARP exist with a given LIS, the security of a combination is only as good as that supplied by ATMARP.

通过互联网中使用的地址解析协议,存在与主机模拟相关的已知安全问题[4]。ATMARP中未添加任何特殊的安全机制。虽然NHRP提供了一些身份验证机制,但ATMARP没有。由于任何安全机制只与其最薄弱的环节一样好,因此应假设当NHRP和ATMARP与给定的LIS存在时,组合的安全性仅与ATMARP提供的安全性一样好。

References

工具书类

[1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.

[1] Laubach,M.和J.Halpern,“ATM上的经典IP和ARP”,RFC2225,1998年4月。

[2] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

[2] Luciani,J.,Katz,D.,Piscitello,D.,Cole,B.和N.Doraswamy,“NBMA下一跳解析协议(NHRP)”,RFC 2332,1998年4月。

[3] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.

[3] Luciani,J.,Armitage,G.,Halpern,J.和N.Doraswamy,“服务器缓存同步协议(SCSP)”,RFC 2334,1998年4月。

[4] Security Problems in the TCP/IP Protocol Suite, Bellovin, ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.

[4] TCP/IP协议套件中的安全问题,Bellovin,ACM计算机通信评论,第19卷,第2期,第32-48页,1989年。

[5] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, April 1998.

[5] Luciani,J.,“使用SCSP的分布式NHRP服务”,RFC 2335,1998年4月。

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[6] Bradner,S.,“RFC中用于表示需求水平的关键词”,RFC 211997年3月。

Acknowledgments

致谢

Thanks to Andy Malis for his input on this draft.

感谢Andy Malis对本草稿的投入。

Author's Addresses

作者地址

James V. Luciani Bay Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821 Phone: +1 978 916 4734 Email: luciani@baynetworks.com

James V.Luciani Bay Networks 3联邦街道邮件站:BL3-03马萨诸塞州Billerica 01821电话:+1 978 916 4734电子邮件:luciani@baynetworks.com

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (1998). All Rights Reserved.

版权所有(C)互联网协会(1998年)。版权所有。

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 assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。