RFC 2583

Guidelines for Next Hop Client (NHC) Developers

📅 published May 1999, from ietf

Guidelines for Next Hop Client (NHC) Developers 🎀

bestie, this RFC is all about the NHC (Next Hop Client), and it's the one that makes ATM shortcuts actually work 💖 It was written by R. Carlson and L. Winkler (both from ANL 🌸), it's Informational (so it gives info and doesn't set an Internet standard), it's from May 1999, and the title block doesn't list anything it obsoletes or updates. Okay, let's get into it 🧚

Status of this Memo 📜

This memo gives info to the Internet community. It is not an Internet standard of any kind, and it can be shared freely with no limits 🦋

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

1. Abstract ✨

Okay, so the vibe here is: this doc gives guidelines for devs building Next Hop Resolution Protocol Clients (NHC) 💅 It assumes your clients are directly hooked up to an ATM based NBMA network, but the same principles apply to other NBMA networks too 🌈 The whole point is to define how the NHC code talks to the TCP/IP stack of the local host OS.

The NHC can send NHRP requests to a Next Hop Resolution Protocol Server (NHS) to resolve both inter and intra LIS addresses 🔥 The NHS reply can be positive (ACK), meaning a short-cut path is available, or negative (NAK), meaning no shortcut, so you have to use the routed path 😭 The NHC must cache (maintain state) for both the ACK and NAK replies so it uses the correct shortcut or routed path, and the NAK reply must be cached so it doesn't keep bugging the NHS when the routed path is being used 🙈

2. Overview 🌸

In the Classical IP over ATM model [1], an ATM attached host talks to an ATMARP server to resolve IP to ATM address semantics ✨ This model has the concept of a Logical IP Subnet (LIS), where intra LIS traffic uses direct PVCs/SVCs and inter LIS traffic uses IP routers to forward packets 🦋 It maps really neatly onto the usual LAN model of subnets and routers, so it's giving familiar 💅

The Next Hop Resolution Protocol (NHRP) [2] defines how the LIS model can be modified to allow direct ATM SVCs (shortcut paths) for inter LIS traffic 🔥 So nodes directly attached to an ATM network can skip the IP routers and set up a direct switched virtual circuit to improve performance when they need it 🚀

The NHS code replaces the ATMARP code in the ATMARP server 🫶 Each NHS serves a set of destination client hosts and works with other NHSs to resolve NHRP next hop requests inside their own logical ATM network 🌈 The NHC to NHS and NHS to NHS interactions are described in [2]. Other NHRP docs cover the general applicability [3] and the transition from ATMARP servers to NHSs [4] 📚

The NHC code replaces the ATMARP code in the local workstations 💖 It takes the destination IP address and maps it to the ATM End Station Address (AESA) for both intra and inter LIS destinations ✨ That returned AESA gets stored in a local cache table. The NHC also has to store the negative replies, so it doesn't keep making repeated NHS calls when it's using the routed path 🙈

This document describes a baseline method for caching the returned info. Other methods are allowed as long as they give the same functionality 🧚

3. IP Processing 🎀

In the Classical IP LIS model [1], the TCP/IP stack treats the ATM network as a simple data link layer protocol 💅 When an app sends data using Classical IP, IP does a routing table lookup to figure out whether the destination is reachable through a local interface, or whether an intermediate router is the next hop 🦋

If the destination is local (for example, in the same LIS as the source), the packet is passed to the local ATM interface with the next hop IP address set to the destination node's IP address 💖 Then the ATMARP table gets searched to find the ATM Address of the destination node. If there's no ATMARP table entry, an ATMARP request gets sent to the ATMARP server 😭 The server can reply with a positive (ACK) or negative (NAK) answer, depending on what it has in its cache right now. If it gets an ACK, the host's local ATMARP table gets filled in and the source can now send IP datagrams to the destination 🫶 If it gets a NAK, the calling app gets told about the error (for example, ICMP destination unreachable) 🙈

If the destination is remote (for example, in a different LIS from the source), the IP address of the next hop router is pulled from the IP routing table, and the ATM Address of that router is looked up in the ATMARP table 🌸 Since the router is in the same LIS as the source node, the ATMARP procedure above will find the correct ATM Address. Otherwise the packet gets marked as undeliverable and the user app gets notified of the error ⭐

The ATMARP service works exactly like the existing ARP service on Ethernet broadcast networks 🍓 ARP only tries to resolve addresses for nodes in a single IP subnet, so the ARP table only needs to keep positive answers. No state info is kept about failed mappings, which is a very relatable "don't hold onto the bad stuff" moment 💜

4. NHC Processing 🔥

This section briefly explains what a host needs in order to take advantage of shortcuts through the ATM network 🦋 On the host, an NHC process starts various NHRP requests so it can get access to the NHRP service 🧚 Inside the ATM subnetwork, the ATMARP server gets replaced with an NHS. As defined in [4], the NHS is required to respond to both ATMARP and NHRP Resolution requests ✨ On the nodes that want shortcut paths across the ATM subnetwork, the ATMARP client code has to be replaced with NHC code. That lets the source node ask for the ATM AESA of both local and remote nodes 💅 Finally, the source node has to be modified so it knows when to ask for the ATM AESA of a remote node, and when it should use the local LIS router instead 👑 The rest of this document covers those changes 🌈

The protocol processing described in [2] says a source may query an NHS for the ATM AESA of a destination node. But as [5] points out, just swapping the ATMARP client code for the NHC code isn't enough to get shortcut paths through the ATM network 🙈 The reason is that the source host will never ask the NHS for the ATM AESA of a node in a remote LIS. When the source checks the IP routing table, it does the local/remote test before the NHC code is processed. So the IP address of the next hop router gets used by the NHC instead of the IP address of the remote (inter LIS) host 😭 The NHC must ignore the result of the IP routing table lookup and do 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 [1].
  2. If not, send an NHRP message to the local NHS and try to set up a shortcut path. If that works, 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. Let the user application override the system default operation and explicitly request a shortcut or routed path for a flow 👑

This routed path state is required to be maintained in the same manner as the existing ATMARP service 🌸 That means a timer is used to expire old info, and some administrative function exists to manually delete data if needed ⏰

5. Need for State 💖

It's obvious that IP to ATM AESA mappings should be kept in a local cache to improve network performance 🚀 Today's ARP and ATMARP systems keep this soft state using timers that purge old or unused data ✨ The NHC will keep both inter and intra LIS IP to ATM Address mappings the same way. What's less obvious is that an NHC also needs to keep this same soft state for inter LIS mappings that use the routed path 🙈 If that state isn't maintained, the source node will send requests to the NHS asking whether a shortcut path can be set up every single time a packet is sent over the routed path 😭

Some features of this state are:

  1. Cache lookups must be fast, since they're done on every packet 🔥
  2. The cache lookup must be on the destination IP address instead of the next-hop router IP address 🎀
  3. Both ACK and NAK data should be cached for the length of the holding time parameter in the NHRP response 🦋

Since state has to be maintained, the questions of where to keep it, how to manually manage it, and how to selectively override it all need to be answered 💅 No matter where this state info lives, a method for manually examining and changing it must be provided. This is essential to make sure the network is operating properly 🫶

There are several possible locations for storing this state info:

  1. Store state in the ARP table. This is the traditional location for these IP to ATM address mappings. This table must be extended to handle caching negative (routed path) info. This solution gives you a system wide service that the NHC can use 🌈
  2. Store state in the IP routing table. This is the traditional location for local/remote state info ⭐
  3. Store state in an ATM MIB structure. This is the traditional location for storing ATM VCC data. It also gives a system wide service that's geared toward ATM services, and it avoids messing with the ARP table to hold negative data 🧚
  4. Store state in the TCP Process Control Block. This allows per-process tailoring of shortcut or routed path info. It 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 info 💜
  6. Store state in a newly defined table 🌸

The NHC should also support both local (per-process) and global (per-system) state 👑 That way you can have a system wide default while a specific app still tailors the operation for a specific task. For example, say a site runs both a DNS server and an 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 from a single client requires a global state (for example, use shortcut for FTP) and a local state (for example, use routed path for DNS) 🎀

5.1 Using TCP 💖

Okay bestie, TCP is a connection orientated protocol, and it keeps per-process state info in a TCP Protocol Control Block (PCB) 💅. That PCB can save the shortcut/routed path state. If you use a quad-state flag showing USE_SHORT_CUT, TRY_SHORT_CUT, USE_ROUTED_PATH, or TRY_ROUTED_PATH, each process gets to pick whatever service it wants ✨. The big perk is per-flow control over shortcut vs. routed path 🦋. The downside is that this PCB only gets created for TCP connections, so UDP connections only use the system default action 🥺.

A second option is to store this info in the socket PCB and use the socket function (setsockopt) to save it 👑. This lets both TCP and UDP apps set a per-flow action that overrides the system default. To turn this on, the IP kernel code needs to be modified so this quad-state flag can be set. The flag also has to be checked every time a packet is sent, so the stack can figure out whether the shortcut or routed path is being used 🔥.

5.2 Using UDP 🌸

UDP is a connectionless orientated protocol, and it doesn't provide any support for state info 💀. It relies on the application to supply the necessary state, so the big question is: where should the state live?! The user application could store it itself and pass it down to the kernel somehow 🧚. Another option is to store it in an ATM MIB structure. A third option is a socket option (setsockopt) that the user application can set to override the default behavior 🫶.

5.3 Using ICMP 🏓

In keeping with the tradition of using ICMP echo packets for Internet management functions (e.g. ping, traceroute), these apps need to be able to run over the shortcut and routed paths too 🙈. The user will need to be able to specify which path to use, and a default action needs to be defined too 💜.

6. Conclusions 👑

NHRP gives IP nodes using ATM networks some brand new services and functionality, and it's giving main character energy 🦋. To use these services, the client must store state info that describes whether a destination node is reachable via a shortcut or a routed path 💖.

The state info should be stored on a global per-application basis, with per-process override functionality ✨. This lets short lived functions (e.g. DNS requests) and long lived requests (e.g. ftp sessions) use different paths 🧚. Storing state based only on the destination address means every process has to use the same path, and that creates unreasonable demands on the network 💀. To pull this off, the /etc/services file should be modified to carry a new flag that indicates the per-application default (shortcut vs. routed path) behavior 🎀.

This state info is required so the client doesn't have to make a call to the NHS for every packet it sends along the routed path 🔥. It is recommended that the IP routing table be modified to support a new flag. This flag indicates whether the NHS returned an ACK or NAK to the NHRP request 🌈.

Also, application programmers and system administrators need to be able to explicitly request a specific service (e.g. use the routed path or shortcut path) 🍓. That includes being able to verify network operation by specifying how ICMP echo requests (e.g. ping, traceroute) are handled 🔍. The NHC must support manual setting of this state info, and a new socket option that lets the user specify the operation needs to be supported 💅.

To support this, a new socket option will be created so the user application can control the operation of a particular connection (flow) 🦋. This option lets the user 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, use it to deliver the data. If it doesn't exist, try to create it. If the shortcut cannot be created, fail the connection and notify the user 🚫
  • TRY_SHORT_CUT. If a shortcut path exists, use it to deliver the data. If it doesn't exist, try to 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 to create it. Use the routed path instead ✨

7. Security 🔒

The security issues for NHRP are addressed in other NHRP documents [2,3]. Some specific security issues for the NHC developer are discussed below, and bestie, these are serious 😭.

  • 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 🫶.

8. Authors' Addresses 🧚

Richard Carlson Argonne National Laboratory

EMail: RACarlson@anl.gov

Linda Winkler Argonne National Laboratory

EMail: lwinkler@anl.gov

9. References 📚

  • [1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
  • [2] Luciani, J., Katz, D., Piscitello, D., Cole B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
  • [3] Cansever, D., "NHRP Protocol Applicability Statement", RFC 2333, April 1998.
  • [4] Luciani, J., "Classical IP to NHRP Transition", RFC 2336, July 1998.
  • [5] Rekhter, Y. and D. Kandlur, "Local/Remote Forwarding Decision in Switched Data link Subnetworks", RFC 1937, May 1996.

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

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.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💖

📦 where this page comes from