Internetworking Over NBMA Working Group James V. Luciani INTERNET-DRAFT (Bay Networks) Expires November 1997 Classical IP to NHRP Transition Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 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. 1. Introduction 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. Issues raised by MAC level bridging and LAN emulation are beyond its scope. 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 Luciani [Page 1] INTERNET-DRAFT NBMA NHRP Expires November 1997 layer addresses and NBMA addresses of suitable "NBMA next hops" toward a destination station. If the destination is connected to the NBMA subnetwork, 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. It is reasonable to expect that ATMARP Clients and NHRP Clients will initially coexist within a LIS. Thus it is necessary to define a service transition and service coexistence document which describes the methods and procedures for the graceful transition from an ATMARP network model to an NHRP over ATM network model and the coexistence of these models within the same 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. For the following, it will be assumed that the reader is familiar with the terminology as described in [1][2][3]. 2. Service Requirements 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 since, as described below, NHSs will respond to ATMARP Clients, this is a reasonable simplifying restriction. 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 this ATMARP only addresses these protocols. 2.1 NHRP Server Requirements 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, 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 Luciani [Page 2] INTERNET-DRAFT NBMA NHRP Expires November 1997 packet and MUST NOT take any further action. 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: 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. 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. When an NHS receives an ATMARP_Request which causes an update to one of its cache entries then that entry is placed on a 20 minute timer as described in [1] since ATMARP has no concept of Holding Time fields. 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 "12 - No Internetworking Layer Address to NBMA Address Binding Exists" 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. 2.2 Multi-server environments Since NHRP works in a multi-server environment on a per LIS basis, it is useful to make a few comments about the cache synchronization necessary in a hybrid ATMARP/NHRP LIS. ATMARP and NHRP have different cache overwrite rules. An NHC is permitted to register its addresses with multiple NHSs while ATMARP Clients are not. The cache over-write rules are described in [1][2]. A simple rule of thumb for the synchronization of ATMARP initiated entries in an NHS is as follows: if it were the case that the LIS contained only a single server and, as a result of an ATMARP_Request, a cache update would occur Luciani [Page 3] INTERNET-DRAFT NBMA NHRP Expires November 1997 in that single server then in a multi-server environment the resultant cache update MUST be propagated to all NHSs in the LIS. Further information on cache over-write strategies for ATMARP and NHRP servers can be found in [3]. 3. Security Considerations 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. 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. 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. References [1] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [2] NBMA Next Hop Resolution Protocol (NHRP), Luciani, Katz, Piscitello, Cole, draft-ietf-rolc-nhrp-10.txt. [3] Server Cache Synchronization Protocol (SCSP) - NBMA, J. Luciani, G. Armitage, J. Halpern, Work In Progress. [4] Security Problems in the TCP/IP Protocol Suite, Bellovin, ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989. Acknowledgments TBD. Luciani [Page 4] INTERNET-DRAFT NBMA NHRP Expires November 1997 Author's Addresses James V. Luciani Bay Networks 3 Federal Street Mail Stop: BL3-04 Billerica, MA 01821 Phone: +1 508 916 4734 Email: luciani@baynetworks.com Luciani [Page 5]