NHRP Protocol Applicability Statement
Extracted elements (20)
Frequent changes in the routed path on short time scales (seconds) negatively affect NHRP operation. In router-router scenarios, route instability can create persistent routing loops; in host-router or router-host scenarios, it causes repeated creation of short-lived short-cut paths, resulting in inefficiency.
NHRP does not replace existing routing protocols. IP routing first determines the proper path; NHRP then creates a short-cut overlay on that path. NHRP 'shortens' the routed path but is insufficient to suppress persistent forwarding loops in router-router communication when the underlying routing protocol loses loop-suppression information.
NHRP generalizes Classical IP and ARP over ATM (RFC 2225) and IP over SMDS (RFC 1209) in two directions: it avoids extra router hops when source and destination belong to different Logical Internet Subnets (LIS) on the same NBMA network, and it is not specific to any particular NBMA technology.
NHRP is designed for unicast (single-destination) IP packet delivery and is not intended for direct use in point-to-multipoint communication. Elements of NHRP may be used in certain multicast scenarios for short-cut routing, but scalability in multicast environments is described as an open issue.
NHRP is not a routing protocol but may use routing information. When NHRP uses dynamic routing to identify an egress router, the exit router selected reflects the dynamic routing protocol's choice, typically the one inducing the fewest hops on the original routed path.
NHRP scalability is analyzed at three levels: Client level (bounded by NIC processing and memory, especially for connection-oriented NBMA such as ATM with many SVCCs), LIS level (bounded by number of address mappings, addressable via SCSP for NHS synchronization), and Domain level (bounded by the scalability of the underlying routing protocol).
Short-cut routing is the most prominent feature of NHRP. When source and destination are on the same logical NBMA network but in different LISs, NHRP provides the source with the NBMA address of the destination (if directly attached) or of the optimal egress router (if not), allowing packets to bypass intermediate routers entirely.
Short-cut routing over ATM enables QoS guarantees to be fully utilized without re-assembling and re-segmenting IP packets at each network-layer hop, because the direct NBMA path bypasses intermediate routers.
To avoid multiple redundant short-cut paths being formed as a packet traverses multiple hops, only three categories of entities should be authorized to issue NHRP requests: (i) the originating host with an NBMA interface, (ii) the first router along the path whose next hop is on an NBMA interface, or (iii) a policy router within the NBMA network.
When used for router-router communication, NHRP (as defined in RFC 2332) can produce persistent routing loops if the underlying routing protocol loses information critical to loop suppression, such as when router metrics change across autonomous system boundaries. Work to address this is noted as in progress.
Whether to issue an NHRP request is application-dependent. For short-lived applications without strict QoS requirements, hop-by-hop routing may be preferable. The trade-off between the 'cost' of a short-cut path (monetary or equipment strain) and its utility should be resolved at the application level.
At the NHRP Domain level, if an NHRP Request reaches a router that does not implement NHRP, it will be silently discarded. Short-cuts cannot be established through such routers; connectivity falls back to hop-by-hop routing. For robust operation, virtually all routers within a logical NBMA network should be NHRP aware when dynamic routing is used.
NHRP implementations can use the Server Cache Synchronization Protocol (SCSP, RFC 2334) to maintain multiple synchronized Next Hop Servers (NHSs) within a single LIS, resolving the LIS-level scalability constraint for large address mapping tables.
Static routing can be used with NHRP instead of dynamic routing, in which case only the routers included in manually defined static paths need to be NHRP aware. However, static routing does not scale and can result in persistently suboptimal routes and negative failure modes if the destination is off the NBMA network.
The ATM Forum's Multiprotocol Over ATM (MPOA) Working Group adopted and integrated NHRP into its MPOA Protocol specification (af-mpoa-0087.000), using NHRP to resolve ATM addresses for MPOA packets destined outside the originating subnet.
If the Q bit is set in an NHRP Request and the destination is not directly adjacent to the egress router, the safe mode of operation for the egress router is to issue a negative NHRP Reply (NAK), thereby forcing data packets to follow the routed path and avoiding potential persistent loops.
NHRP uses a client-server model. An NHRP Client issues NHRP Requests; an NHRP Server issues replies or forwards requests to another server. A single NHRP entity may act as both Client and Server.
The Q bit in an NHRP Request indicates that the requesting party is a router. If the Q bit is set and the destination is directly adjacent to the egress router as a stable topological configuration, the egress router may issue a corresponding NHRP reply.
NHRP, as an address resolution protocol, is subject to server spoofing and denial-of-service attacks. NHRP provides authentication mechanisms to mitigate spoofing concerns; details are in RFC 2332, Section 5.3.4.
SCSP, as a database synchronization protocol used alongside NHRP, is subject to peer spoofing and denial-of-service attacks. SCSP provides authentication mechanisms; details are in RFC 2334, Section B.3.1.