RFC 2333

NHRP Protocol Applicability Statement

📅 published April 1998, from ietf

RFC 2333: NHRP Protocol Applicability Statement 🦋

Okay bestie, this one is all about NHRP (Next Hop Resolution Protocol) and where it's actually a good fit 💅 Here's the title block tea ☕:

  • RFC number: 2333 ✨
  • Title: NHRP Protocol Applicability Statement
  • Author: D. Cansever, GTE Laboratories, Inc. 🎀
  • Stream: Network Working Group 🌈
  • Category: Standards Track 👑
  • Date: April 1998 🍓
  • Obsoletes / Updates: neither is listed on this doc, so it isn't replacing or patching any older RFC 🙈

Status of This Memo 📜

Okay so this section says it's an Internet standards track protocol for the Internet community 🌸 and they're literally asking for discussion and suggestions for improvements 💬 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited 🦋

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

Abstract

The tea ☕: as required by the Routing Protocol Criteria [RFC 1264], this memo looks at how the Next Hop Resolution Protocol (NHRP) applies to routing IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, like ATM, SMDS and X.25 🌈

1. Protocol Documents 📚

The NHRP protocol description is defined in [1] 🧚 and the NHRP MIB description is defined in [2] 💜

2. Introduction 🌸

So this doc sums up the key features of NHRP and talks about the environments where the protocol is a perfect match 💖 Think of NHRP as a glow-up of Classical IP and ARP over ATM, which is defined in [3] ✨ and the Transmission of IP Datagrams over the SMDS Service, defined in [4] 🦋 It generalizes things in 2 distinct directions, and I'm obsessed with both 😭

First up, NHRP avoids the need to go through extra hops of routers when the Source and Destination belong to different Logical Internet Subnets (LIS) 🚫🛣️ Now, [3] and [4] say that when the source and destination are in different LISs, the source station has to forward data packets to a router that's a member of multiple LISs, even if both stations are on the same logical NBMA network 🙃 With NHRP, if the source and destination are on the same logical NBMA network, the source gets an inter-LIS address resolution mechanism. At the end of it, both stations can exchange packets without bouncing through intermediate routers 🔥 This is also called "short-cut" routing ⚡ If the destination isn't part of the logical NBMA network, NHRP hands the source the NBMA address of the current egress router towards the destination 🗺️

The second glow-up is that NHRP isn't locked to one NBMA technology 💅 [3] assumes an ATM network and [4] assumes an SMDS network at their respective subnetwork layers, but NHRP is its own girl 👑

NHRP is specified for resolving the destination NBMA addresses of IP datagrams over IP subnets inside a large NBMA cloud ☁️ It's also been designed to be extensible to network layer protocols other than IP, possibly with other network layer protocol specific additions 🌷

And here's the big application 🎀 The Multiprotocol Over ATM (MPOA) Working Group of the ATM Forum decided to adopt and integrate NHRP into its MPOA Protocol specification [5] 🤩 So NHRP will be used to resolve the ATM addresses of MPOA packets destined outside the originating subnet 🦋

3. Key Features 🔑

NHRP gives you a way to get the NBMA network address of the destination, or of a router along the path to it 🧭 It's not a routing protocol, but it can make use of routing information 💜 More on that in Section 5 ✨

The most prominent feature is that NHRP avoids extra router hops in an NBMA with multiple LISs 🙌 So if the destination is directly attached to the NBMA, NHRP gives the source the NBMA address of the destination itself 🎯 If the destination isn't attached to the NBMA, NHRP gives the source the NBMA address of an exit router that has connectivity to the destination 🚪 There can be multiple exit routers with connectivity to the destination, though 👯‍♀️ If NHRP uses a dynamic routing algorithm to do its job (which is necessary for robust and scalable operation 💪), then the exit router NHRP identifies reflects the selection made by the network layer dynamic routing protocol 🛤️ That selection often reflects something desirable, like picking the exit router that causes the fewest hops in the original routed path 🥇

NHRP is defined for avoiding extra hops when delivering IP packets with a single destination 🎯 That means it's not meant for direct use in a point-to-multipoint setting 🙅‍♀️ Still, elements of NHRP may be used in certain multicast scenarios to provide short cut routing, and that effort is discussed in [6] 🧚 In that case NHRP would avoid intermediate routers in the multicast path 🏃‍♀️ Scalability of short-cut paths in a multicast environment is still an open issue 🤔

NHRP can be used for host-host, host-router and router-host communications 💖 But when it's used in router-router communication, NHRP (as defined in [1]) can produce persistent routing loops if the underlying routing protocol loses information critical to loop suppression 😱 That can happen when router metrics change across autonomous system boundaries 🌪️ NHRP for router-router communication that avoids persistent forwarding loops will be covered in a separate document 📄

🚨 Loop alert: router-router NHRP as defined in [1] can produce persistent routing loops. Keep that in mind, bestie!

There's a special case of router-router communication where loops won't occur: when the destination host is directly adjacent to the non-NBMA interface of the egress router 🙌 If that adjacency is believed to be a stable topological configuration, then NHRP can safely be used in this router-router scenario ✅ If the NHRP Request has the Q bit set (meaning the requesting party is a router) and the destination is directly adjacent to the egress router in a stable configuration, the egress router can issue a corresponding NHRP reply 📨 If the destination isn't adjacent to the egress router and the Q bit is set in the Request, a safe mode for the egress router is to issue a negative NHRP Reply (NAK) for that particular request 🙅‍♀️ That way, the data packets are forced to follow the routed path 🛤️ Safe mode, periodt 🫶

Because NHRP has inter-LIS address resolution capability, communicating parties can exchange packets by fully using the special features of the NBMA network 🌈 One example is using QoS guarantees when the NBMA network is ATM 💅 Thanks to short-cut routing, ATM-provided QoS guarantees can be implemented without dealing with re-assembling and re-segmenting IP packets at each network layer hop 🤯 Iconic, honestly 👑

NHRP can be viewed as a client-server interaction 🧩 An NHRP Client is the one who issues an NHRP Request ✉️ An NHRP Server is the one who issues a reply to an NHRP Request, or the one who forwards a received NHRP Request to another Server 🔁 And yes, one NHRP entity can act as both a Client and a Server 🫶

4. Use of NHRP 🎀

Issuing an NHRP request is generally an application dependent action [7] 💅 For applications without particular QoS requirements that run for a short period of time, an NBMA short-cut may not be a necessity 🙈 When short-cuts come with a "cost," those applications may be better served by network layer hop-by-hop routing 🐢 That "cost" can be monetary, or it can be extra strain on the equipment that implements short-cuts 💸 So there's a trade-off between the "cost" of a short-cut path and its utility to the user ⚖️ Reference [7] proposes that this trade-off be addressed at the application level 🧠

In an environment of LANs and routers interconnected via dedicated links, the basic routing decision is whether to forward a packet to a router or broadcast it locally 📡 That local vs. remote decision is based on the destination address 📍 When you route IP packets over an NBMA network, though, there's potentially direct Source to Destination connectivity with QoS options 🤩 So the local vs. remote decision isn't as fundamentally important anymore 😌 The basic decision becomes short-cut vs. hop-by-hop network layer routing 🔀 And the relevant criterion becomes the applications' QoS requirements [7] 💖 NHRP is especially applicable where the local vs. remote decision is superseded by the short-cut vs. hop-by-hop decision 👑

Let's assume the trade-off favors a short-cut NBMA route 🛣️ An NHRP request can be issued by a variety of NHRP aware entities, including hosts and routers with NBMA interfaces 🖥️ If an IP packet traverses multiple hops before a short-cut path is established, there's a chance multiple short-cut paths could form 😬 To avoid that messy situation, a useful operation rule is to authorize only the following entities to issue an NHRP request and perform short-cut routing 🧹

  • i) The host that originates the IP packet, if the host has an NBMA interface 🖥️
  • ii) The first router along the routing path of the IP packet such that the next hop is reachable through the NBMA interface of that particular router 🛤️
  • iii) A policy router within an NBMA network through which the IP packet has to traverse 🧚‍♀️

5. Protocol Scalability 📈✨

okay so, quick reminder: NHRP is only for delivering IP packets with a single destination 💅, so this whole discussion is stuck in a unicast setting 🎀. NHRP's scalability can be looked at on three distinct levels:

  • Client level
  • LIS level
  • Domain level

Client level first 🌸. Here the scalability is affected by the processing and memory limits of the NIC that gives the interface to the NBMA network. When the NBMA network is connection oriented, like ATM, NIC limits can bound NHRP's scalability in certain apps 😭. Like, a server handling hundreds of requests per second over an ATM interface may be bounded by its NIC's performance characteristics. Same energy when the NHRP Client sits at an NBMA interface of a router: the memory and processing limits of the router's NIC may bound NHRP's scalability, because routers deal with an aggregation of traffic from multiple sources, which creates a potentially large number of SVCCs out of the router's NBMA interface 🧚.

LIS level is all about maintaining and delivering a sizable number of NBMA to Network layer address mappings inside large LISs 🍓. NHRP implementations can use the services of the Server Cache Synchronization Protocol (SCSP) [8], which allows multiple synchronized NHSs within an LIS, and that's how the scalability issue gets resolved 🫶.

Domain level is where it gets spicy 🌈. Network layer routing is used to resolve the NBMA address of a destination outside the LIS, so NHRP's scalability is closely tied to the scalability of the network layer routing protocol it uses. Dynamic network layer routing protocols are proven to scale well ⭐. So when you pair NHRP with dynamic routing algorithms, at the NHRP Domain level NHRP should scale in the same order as the routing algorithm, subject to the assumption that all the routers along the path are NHRP aware 👑. If an NHRP Request gets processed by a router that doesn't implement NHRP, it will be silently discarded 💀. Then short-cuts can't be implemented, and connectivity is provided on a hop-by-hop basis.

So when NHRP runs with dynamic network layer routing, a scaling requirement is that virtually all the routers within a logical NBMA network should be NHRP aware 🦋.

You can also use static routing with NHRP 🧸. Then not all the routers in the NBMA network need to be NHRP aware, because the routers that need to process NHRP control messages are specified by static routing. Routers that aren't in the manually defined static paths don't have to be NHRP aware. BUT static routing does not scale, ngl 🙈. And if the destination is off the NBMA network, static routing could result in persistently suboptimal routes. Static routing also has pretty negative failure modes, so be careful bestie 🥺.

6. Discussion 💬

okay, so NHRP does not replace existing routing protocols 🙅‍♀️. Routing protocols are the ones figuring out the proper path from a source host or router (or intermediate router) to a particular destination. If the routing protocol says the proper path goes through an interface to an NBMA network, then NHRP may be used at that NBMA interface to resolve the destination IP address into the corresponding NBMA address ✨. Of course, using NHRP is subject to the considerations we covered in Section 4.

Assuming NHRP is applicable and the destination address has been resolved, packets are forwarded using the data forwarding and path determination mechanisms of the underlying NBMA network 🚀. The order of operations is: route determination is done by IP routing, totally independent of NHRP. Then NHRP is used to create a short-cut track upon the path that the IP routing protocol determined. So yes, NHRP "shortens" the routed path 🦋.

Here's the tea 🍵: NHRP (as defined in [1]) is not sufficient to suppress persistent forwarding loops when used for router-router communication, if the underlying routing protocol loses information critical to loop suppression [9]. Work is in progress [10] to augment NHRP so it can be used for router-router communication without persistent forwarding loops 🔧.

When the routed path keeps changing on some relatively short time scale, like seconds, that situation will affect how NHRP operates 😵‍💫. In certain router-router operations, changes in the routed path could create persistent routing loops 🌀. In host-router or router-host communications, frequent changes in routed paths could result in inefficiencies, like frequently creating short-cut paths that are short lived 🙃.

7. Security Considerations 🚨

Alright security bestie, listen up 👀. NHRP is an address resolution protocol, and SCSP is a database synchronization protocol. Because of that, they're possibly subject to server (for NHRP) or peer (for SCSP) spoofing and denial of service attacks 😱. They both provide authentication mechanisms so they can be used in environments where spoofing is a concern 🔐. The details live in sections 5.3.4 in [1] and B.3.1 in [8].

There are no additional security constraints or concerns raised in this document that are not already discussed in the referenced sections. So go read those referenced sections, no cap 💖.

References 📚

  • [1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
  • [2] Greene, M., and J. Luciani, "NHRP Management Information Base", Work in Progress.
  • [3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
  • [4] Lawrance, J., and D. Piscitello, "The Transmission of IP datagrams over the SMDS service", RFC 1209, March 1991.
  • [5] Multiprotocol Over ATM Version 1.0, ATM Forum Document af-mpoa-0087.000
  • [6] Rekhter, Y., and D. Farinacci, "Support for Sparse Mode PIM over ATM", Work in Progress.
  • [7] Rekhter, Y., and D. Kandlur, "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", RFC 1937, May 1996.
  • [8] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
  • [9] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework Document", RFC 1932, April 1996.
  • [10] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork", Work in Progress.

Acknowledgements 🫶

The author acknowledges valuable contributions and comments from many participants of the ION Working Group, in particular from Joel Halpern of Newbridge Networks, David Horton of Centre for Information Technology Research, Andy Malis of Nexion, Yakov Rekhter and George Swallow of Cisco Systems and Curtis Villamizar of ANS 💜.

Author's Address 📮

Derya H. Cansever
GTE Laboratories Inc.
40 Sylvan Rd. MS 51
Waltham MA 02254

Phone: +1 617 466 4086
EMail: dcansever@gte.com

Copyright (C) The Internet Society (1998). 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. 🌈

📦 where this page comes from