Network Working Group R. Carlson Request for Comments: 2583 ANL Category: Informational L. Winkler ANL May 1999 Guidelines for Next Hop Client (NHC) Developers 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 (1999). All Rights Reserved. 1], an ATM attached host communicates with an ATMARP server to resolve IP to ATM address semantics. This model supports the concept of a Logical IP Subnet (LIS) with intra LIS communications using direct PVCs/SVCs and inter LIS communications using IP routers to forward packets. This model easily maps to the conventional LAN model of subnets and routers. The Next Hop Resolution Protocol (NHRP)  defines how the LIS model can be modified to allow direct ATM SVCs (shortcut paths) for inter LIS traffic. With NHRP, nodes directly attached to an ATM network can bypass the IP routers and establish a direct switched virtual
circuit to improve performance when needed. The NHS code replaces the ATMARP code in the ATMARP server. Each NHS serves a set of destination client hosts and cooperates with other NHSs to resolve NHRP next hop requests within their own logical ATM network. The NHC to NHS and NHS to NHS protocol interactions are described in . Other documents in the NHRP series define the general applicability  and the transition from ATMARP servers to NHSs . The NHC code replaces the ATMARP code in the local workstations. This code will take the destination IP address and map it into the ATM End Station Address (AESA) for both intra and inter LIS destinations. The returned AESA will be stored in a local cache table. In addition to storing the positive replies, the NHC will need to store the negative replies to avoid making repeated NHS calls when using the routed path. This document describes a base line method for caching the returned information. Other methods may be used as long as the same functionality is provided. 1] the TCP/IP protocol stack treats the ATM network as a simple data link layer protocol. When an application sends data using the Classical IP protocol, IP performs a routing table lookup to determine if the destination is reachable via a local interface or whether an intermediate router is the next hop to the IP destination. If the destination is found to be local (e.g. in the same LIS as the source) the packet will be passed to the local ATM interface with the next hop IP address set to the destination nodes IP address. At this point the ATMARP table will be searched to determine the ATM Address of the destination node. If no ATMARP table entry is found an ATMARP request will be sent to the ATMARP server. This server can reply with a positive (ACK) or negative (NAK) answer depending on the current information it has in its cache. If an ACK is received the host's local ATMARP table is filled in appropriately and the source is now able to send IP datagrams to the destination. If a NAK is returned, the calling application is notified of this error condition (e.g., ICMP destination unreachable). If the destination is found to be remote (e.g., in a different LIS from the source) the IP address of the next hop router is extracted from the IP routing table and the ATM Address of this router is looked up in the ATMARP table. Since the router is in the same LIS
as the source node, the ATMARP procedure described above will find the correct ATM Address or the packet will be marked as undeliverable and the user application will be notified of the error. The ATMARP service functions exactly as the existing ARP service provided on Ethernet broadcast networks. Since the ARP service will only try and resolve addresses for nodes that are in a single IP subnet, the ARP table only needs to keep positive answers. No state information is retained about failed mappings. 4] the NHS is required to respond to both ATMARP and NHRP Resolution requests. In the nodes wishing to take advantage of shortcut paths across the ATM subnetwork, the ATMARP client code must be replaced with NHC code. This allows the source node to ask for the ATM AESA of both local and remote nodes. Finally the source node must be modified to know when it should ask for the ATM AESA of a remote node and when the local LIS router should be used. These modifications are described in the remainder of this document. The protocol processing described in  states a source may query a NHS for the ATM AESA of a destination node. However as is pointed out in , to achieve shortcut paths through the ATM network, it is not enough to simply replace the ATMARP client code with the NHC code. This is because the source host will never ask the NHS for the ATM AESA of a node in a remote LIS. When the source consults the IP routing table, it performs the local/remote test, before the NHC code is processed. As a result, the IP address of the next hop router will be used by the NHC instead of the IP address of the remote (inter LIS) host. The NHC code must ignore the result of the IP routing table lookup and perform its own local/remote test. The NHC must perform the following functions: 1. Test to see if the destination node is `local' to this LIS. If so use the existing ATMARP rules described in . 2. If not; send an NHRP message to the local NHS and attempt to setup a `shortcut' path. If successful; save the IP to ATM AESA mapping in the local NHC cache. 3. If not successful; use the routed path and save this state in the NHC cache so future requests don't test for a shortcut again.
4. Allow user application to override system default operation and explicitly request a shortcut or routed path for a flow. It is required that this routed path state will be maintained in the same manner as the existing ATMARP service. That is a timer will be used to expire old information and some administrative function exists to manually delete data if needed.
3. Store state in an ATM MIB structure. This is the traditional location for storing ATM VCC data. It also provides a system wide service that is geared toward ATM services. This avoids munging the `ARP' table to hold negative data. 4. Store state in the TCP Process Control Block. This allows a per process tailoring of shortcut or routed path information. This works well for TCP connections, but not UDP style services. 5. Store state in the socket structure. This also allows per process tailoring of the state information. 6. Store state in a newly defined table. The NHC should also support both local (per-process) and global (per-system) state. This would allow a system wide default while allowing a specific application to tailor the operation for a specific task. For example assume a site runs both a DNS server and FTP server on a single host. Inter LIS communications to the DNS server should take the routed path to avoid setup overhead. While an FTP session would benefit from the shortcut path to improve performance. Supporting both operations from a single client will require both a global state (e.g. use shortcut for FTP) and a local state (e.g. use routed path for DNS).
the user to specify the operation needs to be supported. To support this capability a new socket option will be created to allow the user application to control the operation of a particular connection (flow). This option will allow the user to specify that a connection use one of the following: * USE_SYSTEM_DEFAULT. Use the shortcut or routed path based on the system configuration information for this application. (This is the default behavior.) * USE_SHORT_CUT. If a shortcut path exists, then use it to deliver the data. If it doesn't exist, then try and create it. If the shortcut cannot be created, fail the connection and notify the user. * TRY_SHORT_CUT. If a shortcut path exists, then use it to deliver the data. If it doesn't exist, then try and create it. If the shortcut cannot be created, try using the routed path. * USE_ROUTED_PATH. Use the routed path regardless of whether a shortcut exists or not. * TRY_ROUTED_PATH. If a shortcut doesn't exist, don't try and create it, use the routed path instead. 2,3]. Some specific security issues for the NHC developer are discussed below. * Address spoofing at the IP or ATM layer may allow an attacker to hi-jack an IP connection or service. This threat may be reduced by limiting the scope of the ATM routing domain. In this way only trusted IP hosts will be able to reach and use the services of the NHS. * Denial of service attacks may be launched at both the IP and ATM layers of the NHS. At the ATM layer, the attacker may repeatedly generate signaling messages that consuming system resources thus preventing NHCs from using the NHS services. At the IP layer, the attacker may register false IP to ATM mappings thus preventing a NHC from registering the correct IP to ATM mapping. * When a NHC creates or accepts a short-cut path it bypasses the site border router. Therefore, any security features in the border router are also bypassed. This threat may be reduced by limiting the scope of the ATM routing domain, increasing
security features in the NHC host, allowing the NHS to evaluate security features when short-cut paths are requested or a compination of all of these methods.  Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.  Luciani, J., Katz, D., Piscitello, D., Cole B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.  Cansever, D., "NHRP Protocol Applicability Statement", RFC 2333, April 1998.  Luciani, J., "Classical IP to NHRP Transition", RFC 2336, July 1998.  Rekhter, Y. and D. Kandlur, "Local/Remote Forwarding Decision in Switched Data link Subnetworks", RFC 1937, May 1996.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.