RFC 2332
NBMA Next Hop Resolution Protocol (NHRP)
Okay bestie, let's start with the title block 🎀 This is RFC 2332, called "NBMA Next Hop Resolution Protocol (NHRP)", from the Network Working Group, dated April 1998. It's on the Standards Track 🦋 The authors are J. Luciani (Bay Networks), D. Katz (cisco Systems), D. Piscitello (Core Competence, Inc.), B. Cole (Juniper Networks), and N. Doraswamy (Bay Networks) 👑 The title block doesn't list any Obsoletes or Updates entries, so this one doesn't replace or change any other RFC. 💖
Status of this Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice 🔒
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract 🌸
Okay so this document describes the NBMA Next Hop Resolution Protocol (NHRP) 🦋 NHRP can be used by a source station (a host or a router) that's connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork. It helps that station figure out the internetworking layer address and the NBMA subnetwork addresses of the "NBMA next hop" on the way to a destination station 🎯 If the destination is connected to the NBMA subnetwork, the NBMA next hop is the destination station itself. If it isn't, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. NHRP is meant for a multiprotocol internetworking layer environment running over NBMA subnetworks 💅
Now here's the lowkey spicy part 👀 While this protocol was built for NBMA subnetworks, it is possible, if not likely, that it'll get applied to BMA subnetworks too. That usage of NHRP is for further study 🙈
This document is meant to be a functional superset of the NBMA Address Resolution Protocol (NARP) documented in [1] 🫶
Running NHRP to set up a transit path across an NBMA subnetwork between two routers will be covered in a separate document (see [13]) 📚
1. Introduction 💖
Let's talk keywords first. The BCP 14 keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are read the way [15] describes whenever they pop up in this document 📖
NHRP lets a source station (a host or a router) that wants to talk over a Non-Broadcast, Multi-Access (NBMA) subnetwork figure out the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" toward a destination station ✨ A subnetwork can be non-broadcast for two main reasons. Either it technically doesn't support broadcasting (like an X.25 subnetwork), or broadcasting just isn't feasible for one reason or another. For example, an SMDS multicast group or an extended Ethernet would be way too big 🙈 Same deal as before: if the destination is connected to the NBMA subnetwork, the NBMA next hop is the destination station itself. Otherwise, it's the egress router from the NBMA subnetwork that is "nearest" to the destination station 🎀
One way to model an NBMA network is with logically independent IP subnets (LISs). The LISs defined in [3] and [4] have these properties 🧚
1. All members of a LIS have the same IP network/subnet number and address mask.
2. All members of a LIS are directly connected to the same NBMA subnetwork.
3. All hosts and routers outside of the LIS are accessed via a router.
4. All members of a LIS access each other directly (without routers).
Here's the catch 👀 Address resolution as described in [3] and [4] only resolves the next hop address if the destination station is a member of the same LIS as the source station. Otherwise, the source station must forward packets to a router that is a member of multiple LISs. In multi-LIS setups, hop-by-hop address resolution may not be enough to resolve the "NBMA next hop" toward the destination station, and IP packets may take multiple IP hops through the NBMA subnetwork 😭
Another way to model NBMA is with Local Address Groups (LAGs) [10]. The big difference between the LIS and LAG models is this: with LIS, the "local/remote" forwarding decision is driven purely by addressing information. With LAG, that decision is decoupled from the addressing information and is coupled with the Quality of Service and/or traffic characteristics instead 💅 With the LAG model, any two entities on a common NBMA network could set up direct communication with each other, no matter what their addresses are 🦋
Supporting the LAG model assumes there's a mechanism that lets any entity (a host or a router) connected to an NBMA network resolve an internetworking layer address to an NBMA address for any other entity on that same NBMA network. This resolution happens regardless of how those entities were addressed. Within the parameters this document describes, NHRP is that mechanism 🔥 For example, when the internetworking layer address is of type IP, once the NBMA next hop is resolved, the source can either start sending IP packets to the destination (in a connectionless NBMA subnetwork like SMDS), or first set up a connection to the destination with the desired bandwidth (in a connection-oriented NBMA subnetwork like ATM) 💜
NHRP can be enough for hosts doing address resolution when those hosts are directly connected to an NBMA subnetwork, which keeps implementations in NBMA stations straightforward 🌸 NHRP can also work out the egress point from an NBMA subnetwork when the destination isn't directly connected to it and the egress router's identity wasn't learned by other methods (like routing protocols). Optional extensions to NHRP add extra robustness and diagnosability ✨
Address resolution techniques like the ones in [3] and [4] may already be in use when NHRP gets deployed. ARP servers and services over NBMA subnetworks may be required to support hosts that can't handle any communication model other than the LIS model. Deployed hosts might not implement NHRP and can keep supporting ARP variants like those in [3] and [4] 🫶 NHRP is meant to reduce or eliminate the extra router hops the LIS model requires, and it can be deployed in a non-interfering way alongside existing ARP services [14] 🧚
Running NHRP to set up transit paths across NBMA subnetworks between two routers needs extra mechanisms to avoid stable routing loops. That part will be described in a separate document (see [13]) 🔒
2. Overview 🎀
2.1 Terminology 📚
Real talk, the word "network" is super overloaded, and it's especially confusing in NHRP land. So here's how we use the terms 💖
- Internetwork layer--the media-independent layer (IP in the case of TCP/IP networks).
- Subnetwork layer--the media-dependent layer underlying the internetwork layer, including the NBMA technology (ATM, X.25, SMDS, etc.).
- The term "server", unless explicitly stated to the contrary, refers to a Next Hop Server (NHS). An NHS is an entity performing the Next Hop Resolution Protocol service within the NBMA cloud. An NHS is always tightly coupled with a routing entity (router, route server or edge device), although the converse is not yet guaranteed until this functionality is ubiquitously deployed 🦋 Heads up: the presence of intermediate routers that are not coupled with an NHS entity may preclude the use of NHRP when source and destination stations are on different sides of such routers, so those routers may partition NHRP reachability within an NBMA network 😭
- The term "client", unless explicitly stated to the contrary, refers to a Next Hop Resolution Protocol client (NHC). An NHC is an entity that initiates NHRP requests of various types in order to obtain access to the NHRP service 🌈
- The term "station" generally refers to a host or router that contains an NHRP entity. Sometimes "station" describes a "user" of the NHRP client or service functionality. The difference in usage is mostly semantic 💅
2.2. Protocol Overview 💖
Okay so this section is the big picture 🦋 It walks through how a source S (which can be either a router or a host, no cap) uses NHRP to figure out the "NBMA next hop" to destination D 🧚
First, the NBMA vibe check 🌸 For administrative and policy reasons, one physical NBMA subnetwork can be split into several disjoint "Logical NBMA subnetworks." A Logical NBMA subnetwork is a group of hosts and routers that share unfiltered subnetwork connectivity over an NBMA subnetwork. "Unfiltered subnetwork connectivity" just means there are no closed user groups, no address screening, and nothing similar that would stop stations on the same NBMA subnetwork from talking directly 🙈 From here on, unless I say otherwise, "NBMA subnetwork" means logical NBMA subnetwork, bestie 💅
Next, the cast of characters ✨ Placed inside the NBMA subnetwork are one or more entities that implement NHRP. The stations that can answer NHRP Resolution Requests are called "Next Hop Servers" (NHSs) 👑 Each NHS serves a set of destination hosts, which may or may not be directly connected to the NBMA subnetwork. NHSs work together to resolve the NBMA next hop within their logical NBMA subnetwork 🫶 NHSs may also support "classical" ARP service, but that's its own separate document [14], so we're not getting into it here 🎀
Each NHS keeps a cache 🧠 of protocol layer address to NBMA subnetwork layer address resolution information. That cache can be built from NHRP Register packets (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply packets, or through mechanisms outside the scope of this document (examples might include ARP[3] and pre-configured tables). Section 6.2 goes deeper on cache management 💜
Now, a station on a LIS that doesn't have NHS functionality but is a client of the NHRP service is called an NHRP Client, or just NHC 🍓 For that station to avoid providing NHS functionality, there must be one or more NHSs within the NBMA subnetwork providing authoritative address resolution information on its behalf. That NHS is said to be "serving" the station 🌈 If a serving NHS is going to supply address resolution information for an NHC, then NHSs must exist at each hop along all routed paths between the NHC making the resolution request and the destination NHC 😭 The last NHRP entity along the routed path is the serving NHS. In other words, NHRP Resolution Requests are not forwarded to destination NHCs. They get processed by the serving NHS instead ✨
NHCs have a cache too 🌸 It's a cache of protocol address to NBMA address resolution information, and it gets filled from NHRP Resolution Reply packets, from manual configuration, or through mechanisms outside the scope of this document.
Okay, here's the actual flow 🔥 An event happens that makes station S want to resolve the NBMA address of a path to D. This is most likely when a data packet addressed to station D is about to leave station S (either because S is a host, or because S is a transit router), but address resolution could also be triggered by other stuff, like a routing protocol update packet 🦋 Station S first figures out the next hop to station D through normal routing processes. For a host, the next hop may simply be the default router. For routers, it's the "next hop" to the destination internetwork layer address 💅 If the destination's address resolution information is already in S's cache, S uses that to forward the packet, easy. Otherwise, if the next hop is reachable through one of its NBMA interfaces, S builds an NHRP Resolution Request packet (see Section 5.2.1) 📦 It contains station D's internetwork layer address as the (target) destination address, S's own internetwork layer address as the source address (the Next Hop Resolution Request initiator), and station S's NBMA addressing information 🧚 S can also say it prefers an authoritative NHRP Resolution Reply, meaning S only wants a reply from an NHS serving the destination NHC 🫶 Then S sends the NHRP Resolution Request packet toward the destination 🚀
If an NHRP Resolution Request was triggered by a data packet, S can choose what to do with that packet while it waits for the NHRP Resolution Reply 🤔 Its options are:
- (a) Drop the packet
- (b) Retain the packet until the NHRP Resolution Reply arrives and a more optimal path is available
- (c) Forward the packet along the routed path toward D
Which one S picks is a local policy matter 💖 Option (c) is the recommended default, though, because it may let data keep flowing to the destination while the NBMA address is being resolved ✨ Also, be careful here, bestie 🙈 an NHRP Resolution Request for a given destination MUST NOT be triggered on every packet.
When an NHS gets an NHRP Resolution Request, it checks whether it serves station D 🔍 If the NHS doesn't serve D, it forwards the NHRP Resolution Request to another NHS. How it decides where to forward it is covered in Section 3 🦋
If this NHS does serve D, it resolves station D's NBMA address information and generates a positive NHRP Resolution Reply on D's behalf 👑 Replies in this situation are always marked as "authoritative" 💅 The NHRP Resolution Reply packet carries the address resolution information for station D, and it gets sent back to S. Also, if station D is not on the NBMA subnetwork, the next hop internetwork layer address will be the one for the egress router that packets for station D go through 🌈
A transit NHS that receives an NHRP Resolution Reply can cache the address resolution information in it 🧠 Later, for a subsequent NHRP Resolution Request, that NHS may answer with the cached, "non-authoritative" information, but only if it's allowed to (see Sections 5.2.2 and 6.2 for more on non-authoritative versus authoritative NHRP Resolution Replies) 🎀 Why bother separating them? Because if a communication attempt based on non-authoritative information fails, the source station can choose to send an authoritative NHRP Resolution Request instead. That's the whole point 😭 And an NHS MUST NOT respond to authoritative NHRP Resolution Requests with cached information. Hard rule, no exceptions 💀
If it's determined that no NHS in the NBMA subnetwork can reply to the NHRP Resolution Request for D, a negative NHRP Resolution Reply (NAK) gets returned 🙅♀️ That happens when (a) no next-hop resolution information is available for station D from any NHS, or (b) an NHS can't forward the NHRP Resolution Request (for example, connectivity got lost) 💔
Now, NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, and NHRP Error Indications follow a routed path the same way NHRP Resolution Requests and NHRP Resolution Replies do 🧚 More specifically, "requests" and "indications" follow the routed path from the Source Protocol Address (the address of the station starting the communication) to the Destination Protocol Address. "Replies" go the other way, following the routed path from the Destination Protocol Address back to the Source Protocol Address 🔄 There are two exceptions. For an NHRP Registration Reply, and for an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5). If one doesn't exist, then one MUST be created 🫶
NHRP Requests and NHRP Replies do NOT cross the borders of an NBMA subnetwork 🚧 Further study is being done in this area, though (see Section 7). So the internetwork layer data traffic going out of and into an NBMA subnetwork always goes through an internetwork layer router at its border 🌸
NHRP also optionally gives you a way to send an NHRP Resolution Reply that contains aggregated address resolution information 🍓 Here's an example: say router X is the next hop from station S to station D, and X is the egress router for every station sharing an internetwork layer address prefix with station D 👑 When an NHRP Resolution Reply is generated in response to an NHRP Resolution Request, the responder may augment station D's internetwork layer address with a prefix length (see Section 5.2.0.1). Then a subsequent (non-authoritative) NHRP Resolution Request for some destination that shares an internetwork layer address prefix with D (for the number of bits in the prefix length) can be satisfied with that cached info ✨ See section 6.2 for caching issues, iykyk 🙈
Last but not least, detection 🔍 To dynamically detect subnetwork-layer filtering in NBMA subnetworks (like the X.25 closed user group facility, or SMDS address screens), to trace the routed path an NHRP packet takes, or to provide loop detection and diagnostic capabilities, a "Route Record" may be included in NHRP packets (see Sections 5.3.2 and 5.3.3) 🦋 The Route Record extensions are the NHRP Forward Transit NHS Record Extension and the NHRP Reverse Transit NHS Record Extension. They carry the internetwork (and subnetwork layer) addresses of all intermediate NHSs between source and destination, and between destination and source, respectively 📜 If a source station can't communicate with the responder (say, an attempt to open an SVC fails), it may keep trying with other subnetwork layer addresses in the NHRP Forward Transit NHS Record Extension until one works, if authentication policy allows it 💅 This approach can find a suitable egress point despite subnetwork-layer filtering (which may depend on source/destination, for instance, without necessarily creating separate logical NBMA subnetworks) or subnetwork-layer congestion (especially in connection-oriented media) 🌈 Main character energy, honestly 👑
3. Deployment ✨
okay so NHRP Resolution Requests have to hop through one or more hops inside the NBMA subnetwork before they reach the station that's supposed to send back a response 🧚. Every station, including the source station, picks a neighboring NHS to forward the request to. The NHS selection usually goes like this: you take a destination protocol layer address and apply it to the protocol layer routing table, which gives you a routing decision 💅. That routing decision is then used to forward the NHRP Resolution Request to the downstream NHS. The destination protocol layer address I mentioned is carried inside the NHRP Resolution Request packet. ngl this part is kinda mind-bending: even though a protocol layer address was used to get that routing decision, NHRP packets are not encapsulated within a protocol layer header. They're carried at the NBMA layer using the encapsulation described in Section 5 🦋
Each NHS/router checks out the NHRP Resolution Request packet on its way toward the destination 👀. Each NHS the packet passes through on the way might modify it (for example, by updating the Forward Record extension). Ignoring error situations, the request eventually arrives at a station that's meant to generate an NHRP Resolution Reply. This responding station "serves" the destination, and it's giving main character energy 👑. It generates the NHRP Resolution Reply using the source protocol address from within the NHRP packet to figure out where the reply should be sent 💌
Rather than use routing to pick the next hop, an NHS may use other applicable means (such as static configuration information) to decide which neighboring NHSs to forward the NHRP Resolution Request packet to 🎀. It can do this as long as those other means wouldn't cause the NHRP packet to arrive at an NHS that's not along the routed path. Using static configuration information for this purpose is beyond the scope of this document, so we're leaving it there 🙈
The NHS serving a particular destination must lie along the routed path to that destination. In practice, this means all egress routers have to double as NHSs serving the destinations beyond them, and hosts on the NBMA subnetwork are served by routers that double as NHSs 🧚. This also implies that forwarding NHRP packets within an NBMA subnetwork requires a contiguous deployment of NHRP capable routers. It's important that, in a given LIS/LAG using NHRP, all NHSs within the LIS/LAG have at least some portion of their resolution databases synchronized. That way a packet arriving at one router/NHS in a LIS/LAG gets forwarded the same way as a packet arriving at a different router/NHS for that LIS/LAG 🫶. One method, among others, is the Server Cache Synchronization Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used when a LIS/LAG contains two or more router/NHSs 🌸
During migration to NHRP, it cannot be expected that all routers within the NBMA subnetwork are NHRP capable 😭. So NHRP traffic that would otherwise need to be forwarded through those routers can be expected to get dropped, because the NHRP packet isn't recognized. In this case, NHRP will be unable to establish any transit paths whose discovery requires traversing the non-NHRP speaking routers. If the client has tried and failed to acquire a cut through path, the client should use the network layer routed path as a default 🌈
If an NBMA technology offers a group, an anycast, or a multicast addressing feature, then the NHC may be configured with such an address (appropriate to the routing realm it participates in). That address would be assigned to all NHS serving that routing realm ✨. This address can then be used to set up an initial connection to an NHS so it can transmit a registration request. This address may not be used for sending NHRP requests. The resulting VC may be used for NHRP requests if and only if the registration response is received over that VC, which indicates that one happens to have anycast connected to an NHS serving the LIS/LAG 🦋. In the case of non-connection oriented networks, or of multicast (rather than anycast) addresses, the addres MUST NOT be used for sending NHRP resolution requests 💀
When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined for the NHC directly to the NHC. That means the NHRP message MUST NOT transit through any NHS that isn't serving the NHC, whenever the NHRP message is currently at an NHS that does serve the NHC (this, of course, assumes the NHRP message is destined for the NHC) 🙅♀️. Further, an NHS which serves an NHC SHOULD have a direct NBMA level connection to that NHC (see Section 5.2.3 and 5.2.4 for examples) 💖
With the exception of NHRP Registration Requests (see Section 5.2.3 and 5.2.4 for details of the NHRP Registration Request case), an NHC MUST send NHRP messages over a direct NBMA level connection between the serving NHS and the served NHC 🔥
It may not be desirable to keep semi-permanent NBMA level connectivity between the NHC and the NHS 🍓. In this case, when NBMA level connectivity is initially set up between the NHS and the NHC (as described in Section 5.2.4), the NBMA address of the NHS should be obtained through the NBMA level signaling technology. This address should be stored for future use in setting up subsequent NBMA level connections. A somewhat more information rich technique to get the address information (and more) of the serving NHS would be for the NHC to include the Responder Address extension (see Section 5.3.1) in the NHRP Registration Request. It would then store the information returned in the Responder Address extension, which is subsequently included in the NHRP Registration Reply 🧠. Also, in practice, a client's default router should also be its NHS. So a client may be able to know the NBMA address of its NHS from the configuration it already needed in order to communicate 💜. Further, as mentioned in Section 4, NHCs may be configured with the addressing information of one or more NHSs 🎀
4. Configuration ✨
Next Hop Clients
An NHC connected to an NBMA subnetwork MAY be configured with the Protocol address(es) and NBMA address(es) of its NHS(s) 🌸. The NHS(s) will likely also represent the NHC's default or peer routers, so their NBMA addresses may be obtained from the NHC's existing configuration. If the NHC is attached to several subnetworks (including logical NBMA subnetworks), the NHC should also be configured to receive routing information from its NHS(s) and peer routers. That way it can figure out which internetwork layer networks are reachable through which subnetworks 🗺️
Next Hop Servers
An NHS is configured with knowledge of its own internetwork layer and NBMA addresses 🧚. An NHS MAY also be configured with a set of internetwork layer address prefixes that correspond to the internetwork layer addresses of the stations it serves. The NBMA addresses of the stations served by the NHS may be learned via NHRP Registration packets 🦋
If a served NHC is attached to several subnetworks, the router/route-server coresident with the serving NHS may also need to be configured to advertise routing information to those NHCs 📡
If an NHS acts as an egress router for stations connected to other subnetworks than the NBMA subnetwork, the NHS must, in addition to the above, be configured to exchange routing information between the NBMA subnetwork and those other subnetworks 💅
In all cases, routing information is exchanged using conventional intra-domain and/or inter-domain routing protocols 🌈
5. NHRP Packet Formats ✨
This section describes the format of NHRP packets 📦. In the following, unless otherwise stated explicitly, the unqualified term "request" refers generically to any of the NHRP packet types which are "requests". Further, unless otherwise stated explicitly, the unqualified term "reply" refers generically to any of the NHRP packet types which are "replies" 💖
An NHRP packet consists of a Fixed Part, a Mandatory Part, and an Extensions Part. The Fixed Part is common to all NHRP packet types. The Mandatory Part MUST be present, but it varies depending on packet type. The Extensions Part also varies depending on packet type, and need not be present 🫶
The length of the Fixed Part is fixed at 20 octets. The length of the Mandatory Part is determined by the contents of the extensions offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part length is equal to total packet length (ar$pktsz) minus 20. Otherwise the mandatory part length is equal to ar$extoff minus 20. The length of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs may increase the size of an NHRP packet as a result of extension processing, but not beyond the offered maximum packet size of the NBMA network 📏
NHRP packets are actually members of a wider class of address mapping and management protocols being developed by the IETF 🧩. A specific encapsulation, based on the native formats used on the particular NBMA network over which NHRP is carried, indicates the generic IETF mapping and management protocol. For example, SMDS networks always use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet is preceded by the following LLC/SNAP encapsulation:
[0xAA-AA-03] [0x00-00-5E] [0x00-03]The first three octets are LLC, indicating that SNAP follows. The SNAP OUI portion is the IANA's OUI, and the SNAP PID portion identifies the mapping and management protocol. A field in the Fixed Header following the encapsulation indicates that it is NHRP 🎀
ATM uses either LLC/SNAP encapsulation of each packet (including NHRP), or uses no encapsulation on VCs dedicated to a single protocol (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or identification of NHRP, using an NLPID of 0x0080 and the same SNAP contents as above (see [8], [9]) 🌐
Fields marked "unused" MUST be set to zero on transmission, and ignored on receipt 🙈
Most packet types (ar$op.type) have both internetwork layer protocol-independent fields and protocol-specific fields. The protocol type/snap fields (ar$pro.type/snap) qualify the format of the protocol-specific fields 🧚
5.1 NHRP Fixed Header ✨
okay so the Fixed Part is the bit of the NHRP packet that's ALWAYS there 💖 no matter what kind of packet it is, and its size never changes. it's the reliable core, bestie, literally the foundation of the whole fit 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ar$afn 🌸 this one tells you what kind of "link layer" addresses are being carried 🦋 the number is taken from the 'address family number' list specified in [6]. it also has implications for how ar$shtl and ar$sstl get coded, which we'll get to in a sec 🫶
ar$pro.type 👑 this is a 16 bit unsigned integer, and it's sorting protocols into a whole organized number space:
0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs.
0x0100 to 0x03FF Reserved for future use by the IETF.
0x0400 to 0x04FF Allocated for use by the ATM Forum.
0x0500 to 0x05FF Experimental/Local use.
0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes.(based on the observations that valid Ethertypes are never smaller than 0x600, and NLPIDs never larger than 0xFF.) it's giving very clean sorting, no cap 💅
ar$pro.snap 🧚 okay so this one has two forms. when ar$pro.type has a value of 0x0080, a SNAP encoded extension is being used to encode the protocol type 💜 that extension goes in the ar$pro.snap field, and this is called the 'long form' protocol ID. if ar$pro != 0x0080 then the ar$pro.snap field MUST be zero on transmit and ignored on receive ✨ the ar$pro.type field itself identifies the protocol being referred to, and that's called the 'short form' protocol ID.
In all cases, where a protocol has an assigned number in the ar$pro.type space (excluding 0x0080) the short form MUST be used when transmitting NHRP messages. so if Ethertype or NLPID codings exist, they get used on transmit instead of the ethertype. if both Ethertype and NLPID codings exist, then when transmitting NHRP messages the Ethertype coding MUST be used (this is consistent with RFC 1483 coding) 🎀 so for example, the following codings exist for IP:
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00and thus, since the Ethertype coding exists, it is used in preference. literally the main character coding 💖
ar$hopcnt 🍓 the Hop count indicates the maximum number of NHSs that an NHRP packet is allowed to traverse before being discarded. it's used kind of like a TTL in an IP packet, so it should be set accordingly 🌈 each NHS decrements the TTL as the NHRP packet transits the NHS on the way to the next hop along the routed path to the destination. if an NHS receives an NHRP packet which it would normally forward to a next hop, and that packet contains an ar$hopcnt set to zero, then the NHS sends an error indication message back to the source protocol address stating that the hop count has been exceeded (see Section 5.2.7) and the NHS drops the packet in error 😭 however, an error indication is NEVER sent as a result of receiving an error indication. when a responding NHS replies to an NHRP request, that NHS places a value in ar$hopcnt as if it were sending a request of its own.
ar$pktsz 🦋 this is the total length of the NHRP packet, in octets, excluding link layer encapsulation 📏
ar$chksum 🔥 this is the standard IP checksum over the entire NHRP packet, starting at the fixed header. if the packet is an odd number of bytes in length, then this calculation is performed as if a byte set to 0x00 is appended to the end of the packet 🙈
ar$extoff 🧚 this field tells you whether NHRP extensions exist and where they are. if this field is 0 then no extensions exist, otherwise it's the offset from the beginning of the NHRP packet (starting from the ar$afn field) to the first extension 🌸
ar$op.version 💅 this field indicates which version of generic address mapping and management protocol is represented by this message 🫶
0 MARS protocol [11].
1 NHRP as defined in this document.
0x02 - 0xEF Reserved for future use by the IETF.
0xF0 - 0xFE Allocated for use by the ATM Forum.
0xFF Experimental/Local use.ar$op.type 🌈 when ar$op.version == 1, this is the NHRP packet type: NHRP Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6), or NHRP Error Indication(7). packet Types in the range 128 to 255 are reserved for research or use in other protocol development, and they're administered by IANA as described in Section 9 👑
ar$shtl 🎀 this is the type and length of the source NBMA address, interpreted in the context of the 'address family number' [6] indicated by ar$afn. more details below 💖
ar$sstl 🦋 this is the type and length of the source NBMA subaddress, interpreted in the context of the 'address family number' [6] indicated by ar$afn. when an NBMA technology has no concept of a subaddress, the subaddress length is always coded ar$sstl = 0 and no storage is allocated for the subaddress in the appropriate mandatory part. more details below ✨
Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddress type/length fields (e.g., ar$sstl, Cli SAddr T/L) are coded like this 🍓
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+The most significant bit is reserved and MUST be set to zero 🙈 the second most significant bit (x) is a flag indicating whether the address being referred to is in:
- NSAP format (x = 0).
- Native E.164 format (x = 1).
For NBMA technologies that use neither NSAP nor E.164 format addresses, x = 0 SHALL be used to indicate the native form for the particular NBMA technology 🌈
If the NBMA network is ATM and a subaddress (e.g., Source NBMA SubAddress, Client NBMA SubAddress) is to be included in any part of the NHRP packet, then ar$afn MUST be set to 0x000F. further, the subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddress type/length fields (e.g., ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. if the NBMA network is ATM and no subaddress field is to be included in any part of the NHRP packet, then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 (E.164) accordingly 💅
The bottom 6 bits is an unsigned integer value indicating the length of the associated NBMA address in octets. if this value is zero, the flag x is ignored 🫶
5.2.0 Mandatory Part 🧚
okay so the Mandatory Part is where the operation specific stuff lives (think NHRP Resolution Request/Reply, etc.) 💜 plus the variable length data that's relevant to the packet type. this is the main event, bestie 👑✨
5.2.0.1. Mandatory Part Format ✨
okay so sections 5.2.1 through 5.2.6 all share the same mandatory part, bestie 💅 it's a common header followed by zero or more Client Information Entries (CIEs). Section 5.2.7 is the main exception with its own format, which it spells out itself 🦋
The common header looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the CIEs look like this 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+okay now the fun part, what each field actually means 🧚
Src Proto Len This field holds the length in octets of the Source Protocol Address.
Dst Proto Len This field holds the length in octets of the Destination Protocol Address.
Flags These flags are specific to the given message type, and each section explains them. ✨
Request ID This is a value that, when paired with the source's address, gives a unique identifier for the info inside a "request" packet. ngl it's giving detective energy 🔍 The value gets copied straight from the "request" into the matching "reply". When a sender of a "request" gets a "reply", it checks the Request ID and source address in that "reply" against its outstanding "request" list. If it finds a match, the "request" counts as acknowledged 💖
The value comes from a 32 bit counter that goes up every time a new "request" is sent. The same value MUST be used when resending a "request", meaning when no "reply" has shown up for it and a retry goes out after an appropriate interval. Super important, don't skip it 🙈
It is RECOMMENDED that the initial value for this number be 0. A node MAY reuse a sequence number if and only if the reuse of the sequence number is not precluded by use of a particular method of synchronization (e.g., as described in Appendix A). 🌸
The NBMA address/subaddress form below lets you do a combined E.164/NSAPA form of NBMA addressing, which is so cute 🎀 For NBMA technologies without a subaddress concept, the subaddress field is always ZERO length and ar$sstl = 0.
Source NBMA Address This is the address of the source station that's sending the "request". If the length given in ar$shtl is 0, then no storage gets allocated for this address at all.
Source NBMA SubAddress This is the address of the source station that's sending the "request". If the length given in ar$sstl is 0, then no storage gets allocated for this address at all.
For NBMA technologies that have a notion of "Calling Party Addresses", the Source NBMA Addresses above are the addresses used when signaling for an SVC. 🦋
"Requests" and "indications" follow the routed path from Source Protocol Address to Destination Protocol Address. "Replies", on the other hand, follow the routed path from Destination Protocol Address back to Source Protocol Address, with these exceptions: for an NHRP Registration Reply, and for an NHC initiated NHRP Purge Request, the packet always comes back via a direct VC (see Sections 5.2.4 and 5.2.5). Plot twist 😭
Source Protocol Address This is the protocol address of the station that's sending the "request". It's also the protocol address of the station a "reply" packet gets sent back to.
Destination Protocol Address This is the protocol address of the station a "request" packet is sent toward.
Code This field is message specific, so check the relevant message sections below. Generally speaking it's a NAK code 💅 When this field is 0 in a reply, the packet is acknowledging a request. If it has any other value, the packet is a negative acknowledgment.
Prefix Length This field is also message specific, see the relevant message sections below. In general though, it's used to show that the info in an NHRP message is about an equivalence class of internetwork layer addresses, not just one single address. Every internetwork layer address that matches the first "Prefix Length" bit positions of the specific one is part of the equivalence class. If this field is set to 0x00, then this field MUST be ignored and no equivalence information is assumed (note that 0x00 is thus equivalent to 0xFF). Bestie, 0x00 and 0xFF hitting the same energy is a whole mood 🌈
Maximum Transmission Unit This field gives the maximum transmission unit for the relevant client station. If this value is 0, then either the default MTU is used, or the MTU negotiated via signaling is used, if that negotiation is possible for the given NBMA. ⭐
Holding Time The Holding Time field says how many seconds the Next Hop NBMA information in the CIE stays valid. Cached information SHALL be discarded when the holding time expires. This field must be set to 0 on a NAK. ⏳
Cli Addr T/L This is the type and length of the next hop NBMA address in the CIE. It gets interpreted in the context of the 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM). 🍓
Cli SAddr T/L This is the type and length of the next hop NBMA subaddress in the CIE. It gets interpreted in the context of the 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the subaddress an ATM Forum NSAP address). When an NBMA technology has no concept of a subaddress, the subaddress is always null with a length of 0. When the address length is specified as 0, no storage is allocated for the address. Lowkey a lot of rules, but they're all very clear 🫶
Cli Proto Len This field holds the length in octets of the Client Protocol Address specified in the CIE.
Preference This field sets how much a specific CIE is preferred over other CIEs. Higher values mean higher preference. What happens when multiple CIEs have equal or highest preference values is a local matter 👑
Client NBMA Address This is the client's NBMA address.
Client NBMA SubAddress This is the client's NBMA subaddress.
Client Protocol Address This is the client's internetworking layer address.
Okay, one more really important thing 🚨 An NHS may cache source address binding information from an NHRP Resolution Request if and only if the conditions described in Section 6.2 are met for the NHS. In all other cases, source address binding information appearing in an NHRP message MUST NOT be cached. Not me caching stuff I'm not supposed to cache 💀
5.2.1 NHRP Resolution Request
okay so the NHRP Resolution Request packet has a Type code of 1 🦋 its mandatory part is coded the way we covered in Section 5.2.0.1, and the message specific meanings of the fields are below 💅
Flags - the flags field is coded like this ✨
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Q Set if the station sending the NHRP Resolution Request is a router, clear if it is a host 🏠
A This bit gets set in an NHRP Resolution Request if only authoritative next hop information is wanted, and it's clear otherwise. Check the NHRP Resolution Reply section below for the full tea on the "A" bit and how it's used 🫶
D Unused (clear on transmit) 🫥
U This is the Uniqueness bit, and it helps with duplicate address detection 🔍 When this bit is set in an NHRP Resolution Request and one or more entries exist in the NHS cache that meet the requirements of the request, then only the CIE in the NHS's cache with this bit set will be returned. Even if this bit was set at registration time, there may still be multiple CIEs that could fulfill the request, because an entire subnet can be registered using the Prefix Length in the CIE, and the address of interest might be within that subnet 🌐 If the "uniqueness" bit is set and the responding NHS has one or more cache entries that match the request but none of them has the "uniqueness" bit set, then the NHRP Resolution Reply comes back with a NAK code of "13 - Binding Exists But Is Not Unique" and no CIE is included 🙅♀️ If a client wants to receive non-unique Next Hop Entries, then the client must have the "uniqueness" bit set to zero in its NHRP Resolution Request. Also, when this bit is set in an NHRP Registration Request, only a single CIE may be specified in that request, and that CIE must have the Prefix Length field set to 0xFF ✨
S Set if the binding between the Source Protocol Address and the Source NBMA information in the NHRP Resolution Request is guaranteed to be stable and accurate. For example, these addresses belong to an ingress router connected to an ethernet stub network, or the NHC is an NBMA attached host 🧚
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP Resolution Request. If one is included, that entry carries the pertinent information for the client that sent the request. Here's how the CIE gets used in the NHRP Resolution Request 💖
Prefix Length If a CIE is specified in the NHRP Resolution Request, the Prefix Length field may be used to qualify the widest acceptable prefix that can be used to satisfy the request. For NHRP Resolution Request and Reply, the Prefix Length specifies the equivalence class of addresses that match the first "Prefix Length" bit positions of the Destination Protocol Address. If the "U" bit is set in the common header, then this field MUST be set to 0xFF 🌸
Maximum Transmission Unit This field gives the maximum transmission unit for the source station. One possible use of this field in the NHRP Resolution Request packet is for the NHRP Resolution Requester to ask for a target MTU 📏
Holding Time The Holding Time specified in the one CIE that's allowed in an NHRP Resolution Request is the amount of time the source address binding information in the request is permitted to be cached by transit and responding NHSs ⏳ Note that this field may only have a non-zero value if the S bit is set 🍓
All other fields in the CIE MUST be ignored and SHOULD be set to 0 🫧
The Destination Protocol Address in the common header of the Mandatory Part of this message holds the protocol address of the station you want resolved 🎯 An NHC MUST send the NHRP Resolution Request directly to one of its serving NHSs (see Section 3 for more information) 👑
5.2.2 NHRP Resolution Reply
the NHRP Resolution Reply packet has a Type code of 2 🦋 CIEs line up with the Next Hop Entries in an NHS's cache that match the criteria in the NHRP Resolution Request 💅 Its mandatory part is coded as described in Section 5.2.0.1. Here are the message specific meanings of the fields 🎀
Flags - the flags field is coded like this 🌈
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Q Copied from the NHRP Resolution Request. Set if the NHRP Resolution Requester is a router, clear if it is a host 🏠
A Set if the next hop CIE in the NHRP Resolution Reply is authoritative, clear if the NHRP Resolution Reply is non-authoritative 🧐
When an NHS gets an NHRP Resolution Request for authoritative information and it's the authoritative source for that info, it MUST respond with an NHRP Resolution Reply that contains all and only the next hop CIEs in the NHS's cache that both match the criteria of the request and are authoritative cache entries. An NHS is an authoritative source for a NHRP Resolution Request if the information in its cache matches the request criteria and that information was obtained through an NHRP Registration Request, or through synchronization with an NHS that got the information through an NHRP Registration Request. An authoritative cache entry is one obtained through an NHRP Registration Request, or through synchronization with an NHS that obtained the information through an NHRP Registration Request 💫
An NHS picks up non-authoritative CIEs by promiscuous listening to NHRP packets, other than NHRP Registrations, that are directed at it 👀 An NHRP Resolution Request that asks for non-authoritative information should cause an NHRP Resolution Reply containing all entries in the replying NHS's cache (both authoritative and non-authoritative) that match the criteria in the request 🫶
D Set if the association between the destination and the associated next hop information in all CIEs of the NHRP Resolution Reply is guaranteed to stay stable for the lifetime of the information (the holding time) 🔒 That's the case if the Next Hop protocol address in a CIE identifies the destination (even if its value differs from the Destination address, because the destination system has multiple addresses), or if the destination isn't connected directly to the NBMA subnetwork but the egress router to that destination is guaranteed to be stable. An example of that second case is when the destination is immediately adjacent to the egress router through a non-NBMA interface 🛤️
U This is the Uniqueness bit. Check the NHRP Resolution Request section above for the details 🔍 When this bit is set, only one CIE is included, since only one unique binding should exist in an NHS's cache ☝️
S Copied from the NHRP Resolution Request message 🎀
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE contains NHRP next hop information that the responding NHS has cached and that matches the parameters in the NHRP Resolution Request 💖 If the NHS issuing the reply finds no match, then a single CIE is enclosed with a CIE Code set appropriately (see below), and all other fields MUST be ignored and SHOULD be set to 0 🙈 To help minimal client implementations out, the first CIE MUST contain the next hop with the highest preference value, so that such an implementation only needs to parse a single CIE 🧚
Code If this field is set to zero, then this packet contains a positively acknowledged NHRP Resolution Reply. If this field contains any other value, then the message contains an NHRP Resolution Reply NAK, which means that an appropriate internetworking layer to NBMA address binding wasn't available in the responding NHS's cache 🚫 If an NHRP Resolution Reply contains a Client Information Entry with a NAK Code other than 0, then it MUST NOT contain any other CIE. The NAK Codes currently defined are:
4 - Administratively ProhibitedAn NHS may refuse an NHRP Resolution Request for administrative reasons (due to policy constraints or routing state). If so, the NHS MUST send an NHRP Resolution Reply that contains a NAK code of 4 📜5 - Insufficient ResourcesIf an NHS can't serve a station because it lacks resources (for example, it can't store enough information to send a purge if routing changes), the NHS MUST reply with a NAKed NHRP Resolution Reply that contains a NAK code of 5 🥲12 - No Internetworking Layer Address to NBMA Address Binding ExistsThis code says there were absolutely no internetworking layer address to NBMA address bindings found in the responding NHS's cache 🫥13 - Binding Exists But Is Not UniqueThis code says there was one or more internetworking layer address to NBMA address bindings found in the responding NHS's cache, but none of them had the uniqueness bit set 🙅♀️
Prefix Length In an NHRP Resolution Reply, the Prefix Length specifies the equivalence class of addresses that match the first "Prefix Length" bit positions of the Destination Protocol Address 🌸
Holding Time The Holding Time in a CIE of an NHRP Resolution Reply is the amount of time left before the client information cached at the replying NHS expires. It is not the value the client registered ⏳
The rest of the fields in the CIE for each next hop are filled out the way they were defined when the next hop got registered with the responding NHS (or with one of the responding NHS's synchronized servers) through the NHRP Registration Request 📝
Load-splitting may be performed when more than one Client Information Entry is returned to a requester with equal preference values. The alternative addresses can also be used if there's a connectivity failure in the NBMA subnetwork, such as a failed call attempt in connection-oriented NBMA subnetworks 🔀
Any extensions present in the NHRP Resolution Request packet MUST be present in the NHRP Resolution Reply, even if the extension is non-Compulsory 🧩
If an unsolicited NHRP Resolution Reply packet is received, an Error Indication of type Invalid NHRP Resolution Reply Received SHOULD be sent in response 🚨
When an NHS that serves a given NHC receives an NHRP Resolution Reply destined for that NHC, the NHS must MUST send the NHRP Resolution Reply directly to the NHC (see Section 3) 👑
5.2.3 NHRP Registration Request ✨
okay so the NHRP Registration Request is how a station tells an NHS its NBMA info 💖 it has a Type code of 3, and each CIE is next hop info that the NHS should cache 🫶 the mandatory part is coded like in Section 5.2.0.1, and here's what the fields mean for this message:
Flags 🎀 the flags field is coded like this:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Uis the Uniqueness bit 🔥 when it's set in an NHRP Registration Request, it means the registration of the protocol address is unique within the synchronized NHSs. this "uniqueness" qualifier MUST be stored in the NHS/NHC cache. any attempt to register a binding between the protocol address and an NBMA address with this bit set MUST be rejected with a Code of "14 - Unique Internetworking Layer Address Already Registered" if the replying NHS already has a cache entry for that protocol address and the entry has the "uniqueness" bit set. a CIE's registration is rejected when the CIE comes back with the Code field set to anything other than0x00. see the uniqueness bit description in the NHRP Resolution Request section above for the full scoop. when this bit is set, only one CIE MAY be included in the NHRP Registration Request.
Request ID 🌸 the request ID means the same thing as in Section 5.2.0.1, but the request ID for NHRP registrations that each client keeps MUST be stored in non-volatile memory. that way, when a client crashes and reregisters, there's no mismatch in the NHS's database 😭 updating non-volatile memory is kinda expensive, so you don't have to save every single increment. you could save every 50 or 100 increments instead. then, after a crash, the client knows to add 100 to the non-volatile value before using the request ID for new registrations. genius, right? 👑
CIEs 🧚 one or more CIEs go in the NHRP Registration Request, and each one holds next hop info that the client is trying to register with its servers. generally, all the fields in CIEs inside NHRP Registration Requests are coded like in Section 5.2.0.1. BUT if a station is only registering itself, it MAY code the Cli Addr T/L, Cli SAddr T/L, and Cli Proto Len as zero. that signals the client address info should come from the source info in the common header (see Section 5.2.0.1). here's some extra clarity on a few CIE fields for this message:
Code: this is set to0x00in NHRP Registration Requests. 💅Prefix Length: this field may be used in an NHRP Registration Request to register equivalence info for the Client Protocol Address in the CIE. here, the Prefix Length gives the equivalence class of addresses that match the first "Prefix Length" bit positions of the Client Protocol Address. if the "U" bit is set in the common header, then this field MUST be set to0xFF.
The NHRP Registration Request is used to register an NHC's NHRP info with its NHSs. if an NHC is configured with the protocol address of a serving NHS, the NHC may put that NHS's protocol address in the Destination Protocol Address field of the common header. otherwise, the NHC must put its own protocol address in that field. 🦋
When an NHS gets an NHRP Registration Request whose Destination Protocol Address belongs to a LIS/LAG it serves, and that field equals the Source Protocol Address (which happens when the NHC put its own address there), or it equals the NHS's own protocol address, then the NHS processes the request after doing the appropriate error checking (including any policy checking) ✨
When an NHS gets an NHRP Registration Request whose Destination Protocol Address belongs to a LIS/LAG it serves, but the destination doesn't equal the Source Protocol Address and doesn't equal the NHS's protocol address, then the NHS forwards the message to the right NHS inside that LIS/LAG, based on the Destination Protocol Address 🌈
When an NHS gets an NHRP Registration Request whose Destination Protocol Address does NOT belong to a LIS/LAG it serves, the NHS forwards the packet down the routed path toward the right LIS/LAG 🚀
Misconfigured stations 💀 it's possible a misconfigured station tries to register with the wrong NHS (one that can't serve it because of policy constraints or routing state). if that happens, the NHS MUST reply with a NAK-ed Registration Reply of type Can't Serve This Address.
If an NHS can't serve a station because it's out of resources, the NHS MUST reply with a NAK-ed Registration Reply of type Registration Overflow.
Keeping registrations alive 🍓 so the registration entry doesn't get tossed, the station MUST re-send the NHRP Registration Request often enough to refresh it, even when a packet occasionally gets lost. it's recommended to send the NHRP Registration Request at an interval equal to one-third of the Holding Time in that request. the vibes are "refresh early, refresh often" 💜
5.2.4 NHRP Registration Reply 🦋
The NHRP Registration Reply is sent by an NHS to a client in response to that client's NHRP Registration Request. if the Code field of any CIE in the reply has something other than zero in it, the reply is a NAK. otherwise, it's an ACK. the NHRP Registration Reply has a Type code of 4. 🎀
You make an NHRP Registration Reply from an NHRP Registration Request by changing the type code to 4, updating the CIE Code field, and filling in the appropriate extensions if they exist. here's what the fields mean for this message:
Registering CIE info can fail for a bunch of reasons 😭 if that happens, each failed attempt gets logged in the NHRP Registration Reply by setting the CIE Code field to the matching error code:
0- Successful Registration: the CIE info was successfully registered with the NHS. ✨4- Administratively Prohibited: an NHS may refuse a registration attempt for administrative reasons (due to policy constraints or routing state). if it does, the NHS MUST send an NHRP Registration Reply that contains a NAK code of 4. 🙈5- Insufficient Resources: if an NHS can't serve a station because it's out of resources, the NHS MUST reply with a NAKed NHRP Registration Reply that contains a NAK code of 5. 💀14- Unique Internetworking Layer Address Already Registered: if a client tries to register a protocol address to NBMA address binding with the uniqueness bit on, and that protocol address already exists in the NHS's cache, then if that cache entry also has the uniqueness bit on, this NAK Code is returned in the CIE of the NHRP Registration Reply. 🔥
Asymmetric routing is a thing 🌀 because of it, an NHRP Registration Reply may not be able to just follow the routed path back to the source protocol address in the common header of the reply. so there MUST exist a direct NBMA level connection between the NHC and its NHS, on which the NHRP Registration Reply gets sent, before the reply can be returned to the NHC. if that connection doesn't exist, the NHS must set one up to the NHC using the source NBMA info from the common header of the NHRP Registration Request. the NHS basically does the legwork so the reply actually lands 💅🫶
me explaining the Purge Request like it's a group chat tea spill 💅
I'm going to keep every MUST, SHOULD, and MAY exactly where the original puts it, so the rules stay just as strict, bestie 🫶
5.2.5. NHRP Purge Request ✨
Okay so the NHRP Purge Request is the packet you send to make a station throw out its cached info 🧹 It has a type code of 5. Its mandatory part is coded the way we already went over in Section 5.2.0.1 🎀 Here's what each field means in this specific message:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+N When set, this bit tells the receiver of the NHRP Purge Request that the requester does not expect to receive an NHRP Purge Reply. If an unsolicited NHRP Purge Reply is received by a station where that station is identified in the Source Protocol Address of the packet then that packet MUST be ignored 🙅♀️
One or more CIEs are specified in the NHRP Purge Request. Each CIE contains next hop info that gets purged from an NHS/NHC cache 🗑️ Generally, all fields in CIEs enclosed in NHRP Purge Requests are coded as described in Section 5.2.0.1. Here's the extra detail for some CIE fields in a Purge Request 👀
Code This field is set to 0x00 in NHRP Purge Requests.
Prefix Length In the case of NHRP Purge Requests, the Prefix Length specifies the equivalence class of addresses that match the first "Prefix Length" bit positions of the Client Protocol Address in the CIE. All next hop info containing a protocol address that matches an element of this equivalence class is to be purged from the receiver's cache 💖
The Maximum Transmission Unit and Preference fields of the CIE are coded as zero. The Holding Time SHOULD be coded as zero, but there may be some utility in supplying a "short" holding time to be applied to the matching next hop info before that info would be purged; this usage is for further study 🔮 The Client Protocol Address field and the Cli Proto Len field MUST be filled in. The Client Protocol Address is filled in with the protocol address to be purged from the receiving station's cache, while the Cli Proto Len is set to the length of the purged client's protocol address 🧚 All remaining fields in the CIE MAY be set to zero, although the client NBMA information (and its associated length fields) MAY be specified to narrow the scope of the NHRP Purge Request if the requester wants 🎯 However, the receiver of an NHRP Purge Request MAY choose to ignore the Client NBMA information if it is supplied 🤷♀️
An NHRP Purge Request packet is sent from an NHS to a station to make it delete previously cached info 🧼 This happens when the info may no longer be valid (typically when the NHS previously gave next hop info for a station that isn't directly connected to the NBMA subnetwork, and the egress point to that station may have changed) 😭
An NHRP Purge Request packet may also be sent from an NHC to an NHS it had previously registered with 📝 This lets an NHC invalidate its registration with NHRP before it would otherwise expire via the holding timer 🌸 If an NHC doesn't know the protocol address of a serving NHS, then the NHC MUST place its own protocol address in the Destination Protocol Address field and forward the packet along the routed path. Otherwise, the NHC MUST place the protocol address of a serving NHS in this field 🛤️
Serving NHSs may need to send one or more new NHRP Purge Requests after receiving a purge from one of their served NHCs, since the NHS may have previously answered NHRP Resolution Requests for that NHC's NBMA info 🔁 These purges are "new" in that they are sourced by the NHS and not the NHC. That is, for each NHC that previously sent an NHRP Resolution Request for the purged NHC NBMA info, an NHRP Purge Request is sent that contains the Source Protocol/NBMA Addresses of the NHS and the Destination Protocol Address of the NHC that sent that Resolution Request before the purge 💜
The station sending the NHRP Purge Request MAY periodically retransmit the NHRP Purge Request until either the NHRP Purge Request is acknowledged or the holding time of the info being purged has expired ⏰ Retransmission strategies for NHRP Purge Requests are a local matter 🏠
When a station receives an NHRP Purge Request, it MUST discard any previously cached info that matches the info in the CIEs 🗑️✨
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even if the station doesn't have a matching cache entry, assuming the "N" bit is off in the NHRP Purge Request 💌
If the station wants to reestablish communication with the destination shortly after getting an NHRP Purge Request, it SHOULD make an authoritative NHRP Resolution Request so it avoids stale cache entries that might still be sitting in intermediate NHSs (see Section 6.2.2.) 🕵️♀️ It is RECOMMENDED that authoritative NHRP Resolution Requests be made for the duration of the holding time of the old info 🫶
5.2.6. NHRP Purge Reply ✨
Okay bestie, this one is so easy 🥹 The NHRP Purge Reply is sent to assure the sender of an NHRP Purge Request that all cached info of the specified type has been purged from the station that sent the reply 🧼 It has a type code of 6.
An NHRP Purge Reply is made from an NHRP Purge Request by just changing the type code from 5 to 6 🦋 Then the packet goes back to the requester, after filling in the appropriate extensions if any exist 💅
5.2.7. NHRP Error Indication ✨
The NHRP Error Indication is how you tell the sender of an NHRP packet that something went wrong 🚨 It has a type code of 7. Its Mandatory Part has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Src Proto Len This field holds the length in octets of the Source Protocol Address.
Dst Proto Len This field holds the length in octets of the Destination Protocol Address.
Error Code An error code indicating the type of error detected, chosen from the following list:
1 - Unrecognized Extension
When the Compulsory bit of an extension in an NHRP packet is set, the NHRP packet cannot be processed unless the extension has been processed. The responder MUST return an NHRP Error Indication of type Unrecognized Extension if it is incapable of processing the extension. However, if a transit NHS (one which is not going to generate a reply) detects an unrecognized extension, it SHALL ignore the extension 🙈
3 - NHRP Loop Detected
A Loop Detected error is generated when it is determined that an NHRP packet is being forwarded in a loop 🔁
6 - Protocol Address Unreachable
This error occurs when a packet is moving along the routed path and reaches a point where the protocol address of interest is not reachable 🧱
7 - Protocol Error
A generic packet processing error has occurred (e.g., invalid version number, invalid protocol type, failed checksum, etc.) 💀
8 - NHRP SDU Size Exceeded
If the SDU size of the NHRP packet exceeds the MTU size of the NBMA network, then this error is returned 📦
9 - Invalid Extension
If an NHS finds an extension in a packet that is inappropriate for the packet type, an error is sent back to the sender with Invalid Extension as the code 🙅♀️
10 - Invalid NHRP Resolution Reply Received
If a client receives an NHRP Resolution Reply for a Next Hop Resolution Request it believes it did not make, then an error packet is sent to the station making the reply, with an error code of Invalid Reply Received 😤
11 - Authentication Failure
If a received packet fails an authentication test, then this error is returned 🔐
15 - Hop Count Exceeded
The hop count specified in the Fixed Header of an NHRP message has been exceeded 🏃♀️
Error Offset The offset in octets into the original NHRP packet where an error was detected. This offset is calculated starting from the NHRP Fixed Header 📏
Source NBMA Address The Source NBMA address field is the address of the station that observed the error 👀
Source NBMA SubAddress The Source NBMA subaddress field is the address of the station that observed the error. If the field's length as specified in ar$sstl is 0, then no storage is allocated for this address at all 🫧
Source Protocol Address This is the protocol address of the station that issued the Error packet 📣
Destination Protocol Address This is the protocol address of the station that sent the packet which was found to be in error 🎯
An NHRP Error Indication packet SHALL NEVER be generated in response to another NHRP Error Indication packet. When an NHRP Error Indication packet is generated, the offending NHRP packet SHALL be discarded. In no case should more than one NHRP Error Indication packet be generated for a single NHRP packet 🛑
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA and Source Protocol address fields of a transiting NHRP Error Indication packet, then the NHS will quietly drop the packet and do nothing (this scenario would occur when the NHRP Error Indication packet was itself in a loop) 🌀
Note that no extensions may be added to an NHRP Error Indication ✋
5.3. Extensions Part ✨
okay bestie, the Extensions Part is the optional bit tacked onto the end of a packet 🎀 (only if it's there, lol). It carries one or more extensions, and each one is a {Type, Length, Value} triplet 🧚
Every extension looks like this 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each piece does 💅
- C (Compulsory) 🔥: if it's clear and the NHS doesn't recognize the type code, the extension can safely be ignored. If it's set and the NHS doesn't recognize the type code, the NHRP "request" is considered to be in error. (More details below, bestie.)
- u 🌸: unused, and it must be set to zero.
- Type 💜: the extension type code (see below). The type isn't qualified by the Compulsory bit, but it's totally orthogonal to it, so they're independent.
- Length 🍓: the length in octets of the value, not counting the Type and Length fields. A null extension only has an extension header and a length of zero.
When extensions exist, the list ends with the Null TLV, which has Type = 0 and Length = 0. ✨
Extensions can show up in any order, but any particular extension type can only appear once in an NHRP packet, unless the extension's definition explicitly says otherwise. For example, the vendor-private extension can show up multiple times so that extensions from different vendor IDs can all be represented. It is RECOMMENDED that a given vendor include no more than one Vendor Private Extension. 🦋
An NHS MUST NOT change the order of extensions. The order of extensions placed in an NHRP packet by an NHC (or by an NHS when an NHS sources a packet) MUST be preserved as the packet moves between NHSs. Minimal NHC implementations MUST only recognize, but not necessarily parse, the Vendor Private extension and the End Of Extensions extension. 🫶 Extensions only show up in a "reply" if they were in the matching "request", with the exception of Vendor Private extensions. This doesn't stop an NHS from creating NHS-only extensions that it adds to and removes from NHRP packets itself, but those extensions MUST not be propagated to NHCs. 🙈
The Compulsory bit is how you add to the extension set 👑. If it's set in an extension, the station responding to the NHRP message containing that extension MUST be able to understand it. (The responding station here is the one that would issue the NHRP reply to the request.) So, if it can't, the responder MUST return an NHRP Error Indication of type Unrecognized Extension. If the Compulsory bit is clear, the extension can be safely ignored. But if an ignored extension was in a "request", it MUST be returned, unchanged, in the corresponding "reply" packet type. 💖
Now, a transit NHS (one that's not going to generate a "reply") that runs into an unrecognized extension SHALL ignore it. If the Compulsory bit is set, though, the transit NHS MUST NOT cache the information in the packet, and it MUST NOT identify itself as an egress router (in the Forward Record or Reverse Record extensions). Basically, if a transit NHS hits an extension it can't process and the Compulsory bit is set, that NHS MUST NOT participate in any way in the protocol exchange except as a forwarding agent. Not it, bestie 💀
The NHRP extension Type space is split up so people outside the IETF can use it too 🌈
0x0000 - 0x0FFF Reserved for NHRP.
0x1000 - 0x11FF Allocated to the ATM Forum.
0x1200 - 0x37FF Reserved for the IETF.
0x3800 - 0x3FFF Experimental use.IANA will administer the ranges reserved for the IETF, as described in Section 9. Values in the "Experimental use" range only have local significance. 🧚
5.3.0. The End Of Extensions
Compulsory = 1
Type = 0
Length = 0When extensions exist, the extensions list is terminated by the End Of Extensions/Null TLV. That's the end of the line, bestie 🏁
5.3.1. Responder Address Extension
Compulsory = 1
Type = 3
Length = variableThis extension is how you figure out the address of the NHRP responder 🎯. The responder is the entity that generates the right "reply" packet for a given "request" packet. For an NHRP Resolution Request, the station responding might be different from the system named in the Next Hop field of the NHRP Resolution Reply (that happens with cached replies). This extension can also help detect loops in the NHRP forwarding path 🔁
This extension uses a single CIE, with the extension-specific meanings of the fields set like this ✨
The Prefix Length fields MUST be set to 0 and ignored. 🙈
CIE Code 💅
- 5 - Insufficient Resources: If the responder to an NHRP Resolution Request is an egress point for the target of the address resolution request (meaning it's one of the stations listed in the CIEs of an NHRP Resolution Reply), the Responder Address extension is in the NHRP Resolution Request, and there aren't enough resources to set up a cut-through VC at the responder, then the Code field of the Responder Address Extension is set to 5. This tells the client a VC setup attempt would most likely get rejected. Otherwise, this field MUST be coded as a zero. NHCs MAY use this field to influence whether they attempt to set up a cut-through to the egress router. 😭
Maximum Transmission Unit 🍓 This field gives the maximum transmission unit preferred by the responder. If this value is 0, then either the default MTU is used, or the MTU negotiated via signaling is used (if that negotiation is possible for the given NBMA).
Holding Time ⏳ The Holding Time field says how many seconds the responder's NBMA information is considered valid. Cached information SHALL be discarded when the holding time expires.
"Client Address" information is actually "Responder Address" information for this extension. So, for example, Cli Addr T/L is the responder NBMA address type and length field 🧠
If a "requester" wants this information, the "requester" SHALL include this extension with a value of zero. This means no storage gets allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out. ✨
If an NHS is generating a "reply" packet in response to a "request" that contains this extension, the NHS SHALL include this extension in the "reply", containing its protocol address. If an NHS has more than one protocol address, it SHALL use the same protocol address consistently in all of the Responder Address, Forward Transit NHS Record, and Reverse Transit NHS Record extensions. Which of several protocol addresses goes in this extension is a local matter 🏠
If an NHRP Resolution Reply packet being forwarded by an NHS contains that NHS's own protocol address in the Responder Address Extension, then that NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the NHRP Resolution Reply. Loop caught 🚨
If an NHRP Resolution Reply is being returned by an intermediate NHS based on cached data, it SHALL place its own address in this extension. That way it's different from the address in the Next Hop field 🦋
5.3.2. NHRP Forward Transit NHS Record Extension
Compulsory = 1
Type = 4
Length = variableThe NHRP Forward Transit NHS Record is basically a list of the transit NHSs a "request" has gone through 🗺️ Each NHS SHALL append a Forward Transit NHS element (described below) containing its Protocol address to the extension. The extension length field and the ar$chksum fields SHALL be adjusted to match 🧮
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension. 🙅♀️
On top of that, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address. 💫
This extension uses a single CIE per NHS Record element, with the extension-specific meanings of the fields set like this ✨
The Prefix Length fields MUST be set to 0 and ignored. 🙈
CIE Code 💅
- 5 - Insufficient Resources: If an NHRP Resolution Request contains an NHRP Forward Transit NHS Record Extension, and there aren't enough resources to set up a cut-through VC at the current transit NHS, then the CIE Code field for the NHRP Forward Transit NHS Record Extension is set to 5. This tells the client a VC setup attempt would most likely get rejected. Otherwise, this field MUST be coded as a zero. NHCs MAY use this field to influence whether they attempt to set up a cut-through as described in Section 2.2. Also, the NHRP Reverse Transit NHS Record Extension MUST always have this field set to zero. 🫠
Maximum Transmission Unit 🍓 This field gives the maximum transmission unit preferred by the transit NHS. If this value is 0, then either the default MTU is used, or the MTU negotiated via signaling is used (if that negotiation is possible for the given NBMA).
Holding Time ⏳ The Holding Time field says how many seconds the transit NHS's NBMA information is considered valid. Cached information SHALL be discarded when the holding time expires.
"Client Address" information is actually "Forward Transit NHS Address" information for this extension. So, for example, Cli Addr T/L is the transit NHS NBMA address type and length field 🧠
If a "requester" wants this information, it SHALL include this extension with a length of zero. Again, that means no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out. 🌸
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. Which of several Protocol addresses goes in this extension is a local matter 🏠
If a "request" being forwarded by an NHS contains that NHS's own Protocol Address in one of the Forward Transit NHS elements, then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "request". Same loop energy, different packet 🔁💀
5.3.3 NHRP Reverse Transit NHS Record Extension ✨
Compulsory = 1
Type = 5
Length = variableOkay so this one is the reverse trip receipt 🧾 It's a list of every transit NHS that a "reply" went through on the way back. Each NHS SHALL append its own Reverse Transit NHS element, which is its Protocol address, and the extension length field and ar$chksum SHALL be adjusted to match 💅
The responding NHS (the one described in Section 5.3.1) SHALL NOT update this extension. Hands off, periodt 🙅♀️
NHSs that are willing to act as egress routers for packets going from the source to the destination SHALL also include info about their NBMA Address. Main character energy 👑
This extension uses one CIE per NHS Record element, and the fields have extension-specific meanings:
The CIE Code and Prefix Length fields MUST be set to 0 and ignored. No exceptions, bestie 🎀
Maximum Transmission Unit This is the MTU the transit NHS prefers. If it's 0, then either the default MTU gets used, or the MTU negotiated via signaling gets used, as long as that negotiation is possible for the given NBMA 🦋
Holding Time This is how many seconds the NBMA info for the transit NHS counts as valid. Cached information SHALL be discarded when the holding time expires ⏳
"Client Address" info is really "Reverse Transit NHS Address" info in this extension. So for example, Cli Addr T/L is the transit NHS NBMA address type and length field 🌸
If a "requester" wants this info, it SHALL include this extension with a length of zero. This means no storage gets allocated for the Holding Time and Type/Length fields until the "Value" part of the extension is filled out. Lowkey genius 🧠
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. Which of several Protocol addresses goes in this extension is a local matter 🍓
If a "reply" being forwarded by an NHS already has that NHS's own Protocol Address in one of its Reverse Transit NHS elements, then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "reply". Loop = not it 🔁💀
Heads up: this info might get cached at intermediate NHSs. If it does, the cached value SHALL be used when generating a reply.
5.3.4 NHRP Authentication Extension 🔐
Compulsory = 1 Type = 7 Length = variableThe NHRP Authentication Extension rides along in NHRP packets to carry authentication info between NHRP speakers. It may be included in any NHRP "request" or "reply" only, and nothing else 🫶
Authentication is always done pairwise on an NHRP hop-by-hop basis. That means the authentication extension gets regenerated at each hop. If a received packet fails the authentication test, the station SHALL generate an Error Indication of type "Authentication Failure" and discard the packet. One possible failure is just not having an Authentication Extension at all. Whether it's present or absent is a local matter, so it's up to you 🙈
5.3.4.1 Header Format
The authentication header looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Security Parameter Index (SPI) is basically an index into a table that stores the keys and other info, like the hash algorithm. Src and Dst either set this up offline using manual keying, or online using a key management protocol. The sending NHRP entity is always the one that allocates the SPI and its parameters 🗝️
Src Addr is a variable length field holding the address assigned to the outgoing interface. Its length comes from the source protocol length field in the mandatory part of the NHRP header. The tuple <spi, src addr> uniquely identifies the key and other parameters used for authentication 💜
The length of the authentication data field depends on the hash algorithm in use. This field holds the keyed hash calculated over the entire NHRP payload, and it gets zeroed out before the hash is calculated 🧮
5.3.4.2 SPI and Security Parameters Negotiation
SPIs can be negotiated manually, or using an Internet Key Management protocol. Manual keying MUST be supported. The tuple <SPI, src> has these parameters: lifetime, Algorithm, and Key. Lifetime is how many seconds the key is valid for. With manual keying, that duration can be infinite. Also, to help manual keying along, there can be multiple tuples active at the same time (with the same Dst) ⏱️
Algorithm is the hash algorithm the two entities agree on. HMAC-MD5-128 [16] is the default. Other algorithms MAY be supported by defining new values. IANA will assign the numbers that identify the algorithm being used, as described in Section 9 🔢
Any Internet standard key management protocol MAY be used to negotiate the SPI and parameters too 🫧
5.3.4.3 Message Processing
When it's time to add the authentication extension header, src looks in a table to fetch the SPI and security parameters, based on the outgoing interface address. If the table has no entries, and key management is supported, src kicks off the key management protocol to grab the parameters it needs 📋
Then src builds the Authentication Extension payload and calculates the hash with the authentication data field zeroed out. The result goes into that zeroed field. The src address field in the payload is the IP address assigned to the outgoing interface 🌈
If key management isn't supported and authentication is mandatory, the packet gets dropped and this info gets logged 🪵
On the receiving end, dst fetches the parameters based on the SPI and the IP address in the authentication extension payload. The authentication data field gets pulled out before being zeroed out to calculate the hash. Then dst computes the hash over the entire payload. If the hash doesn't match, an "abnormal event" has happened 🚨
5.3.4.4 Security Considerations
Security is bestie-level serious here, so read this part closely 🔥
It's super important that the keys are strong, because the security of the whole system depends on keys being chosen properly and on the algorithms being implemented correctly 🔑
Security is done hop by hop. Data can only be trusted as much as you trust every entity along the path it took. A chain of trust gets built among the NHRP entities on the path of the NHRP Message. If security in one NHRP entity gets compromised, then security across the entire NHRP domain is compromised too 💀
Data integrity covers the entire NHRP payload. That guarantees the message wasn't modified, and that the source is authenticated as well. If the authentication extension isn't used, or if security is compromised, then NHRP entities are open to spoofing attacks, active attacks, and passive attacks 😭
There is no mechanism to encrypt the messages. It's assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate keys between neighbors. If other negotiation methods send the keys in clear text, the security is completely compromised 🙅♀️
Any NHS can be hit by Denial of Service (DOS) attacks that overload it and stop legitimate packets from being handled properly. A rogue host can send request and registration packets to the first hop NHS. If the authentication option isn't used, the registration packet gets forwarded along the routed path, and every NHS along the way has to process it. If the authentication option IS used, then only the first hop NHS is open to DOS attacks, because unauthenticated packets get dropped instead of forwarded 🛡️
If the security of any host gets compromised (meaning the keys it uses to talk to an NHS become known), then a rogue host can send NHRP packets to the first hop NHS of the compromised host. That NHS will then forward them along the routed path, same as with unauthenticated packets. But this attack only works if the rogue host has the same first hop NHS as the compromised host 🕵️♀️
Finally, DOS attacks that make routers on the routed path spend resources processing NHRP packets are also susceptable to attacks that flood packets at the same destination listed in an NHRP packet's Destination Protocol Address field 🌊
5.3.5 NHRP Vendor-Private Extension 🏷️
Compulsory = 0
Type = 8
Length = variableThe NHRP Vendor-Private Extension carries vendor-private info, or NHRP extensions, between NHRP speakers. It's the vendor's own little secret stash 🤫
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Vendor ID This is the 802 Vendor ID, as assigned by the IEEE [6] 🪪
Data Everything after the Vendor ID in the payload is vendor-dependent data 🎁
This extension may be added to any "request" or "reply" packet, and it's the only extension that can be included multiple times 🔁✨ If the receiver doesn't handle this extension, or doesn't match the Vendor ID in it, the receiver can totally ignore the extension. If a Vendor Private Extension shows up in a "request", then it must be copied to the corresponding "reply" 📬
6. Protocol Operation ⚙️
Okay, next up is the operational side of things. Here we talk about some of the operational considerations for NHRP 🦋
6.1. Router-to-Router Operation ✨
okay so the initiating and responding stations can be hosts OR routers 💅 but here's the tea: if NHRP runs between two routers, a stable routing loop can happen under certain conditions 😭. The danger zone is when you try to set up an NHRP path across a boundary where the info used for route selection gets lost. Examples are losing BGP path vector info, or mixing multiple routing protocols with dissimilar metrics (like RIP and OSPF) 🙈. In those situations, NHRP should not be used. You can dodge this if there are no "back door" paths between the entry and egress router that sit outside the NBMA subnetwork 🦋. Protocol mechanisms to relax these restrictions are still being investigated, so watch this space 👀.
Generally speaking, if routing protocols already have mechanisms for figuring out the egress point when the destination is outside the NBMA subnetwork, you should lean on those 🫶. They're more tightly coupled to the state of the routing system, and they're probably less likely to create loops. Main character routing energy ✨.
6.2. Cache Management Issues 🧚
Managing NHRP caches is a whole thing 💜. How it goes depends on the source station, the NHS serving the destination, and any intermediate NHSs, plus a bunch of other factors.
6.2.1. Caching Requirements 🌸
Source Stations
Source stations MUST cache all received NHRP Resolution Replies that they are actively using 💖. They also must cache "incomplete" entries, which are the ones where an NHRP Resolution Request was sent but no NHRP Resolution Reply has come back yet. Why? Because it keeps the Request ID around for retries, and it tracks the state needed so you don't fire off an NHRP Resolution Request for every single data packet headed to the same destination 🙈.
Source stations MUST purge expired information from their caches 🧹. And when an NHRP Purge Request packet arrives, source stations MUST purge the appropriate cached information 💅.
When a station has a co-resident NHC and NHS, the co-resident NHS can reply to NHRP Resolution Requests from that co-resident NHC with information the station cached because the co-resident NHC made its own NHRP Resolution Requests 🎀. This works as long as the co-resident NHS follows the rules for Transit NHSs, which we'll get to next 🫶.
Serving NHSs
The NHS serving the destination (the one that answers NHRP Resolution Requests authoritatively) SHOULD cache protocol address information from every NHRP Resolution Request it responded to, but only if the info in the NHRP Resolution Reply might change during its lifetime 🔥. That way an NHRP Purge Request packet can be issued when it does. The internetworking-to-NBMA binding info the source station put in the NHRP Resolution Request can also be cached, but only if and only if the "S" bit is set, the NHRP Resolution Request included a CIE with the Holding Time field set greater than zero (this is the valid Holding Time for the source binding), and it's only used non-authoritatively for a period that doesn't go past the Holding Time ⏳.
Transit NHSs
A Transit NHS (one sitting along the NHRP path between the source station and the responding NHS) may cache source binding info from the NHRP Resolution Request packets it forwards, if and only if the "S" bit is set, the NHRP Resolution Request included a CIE with the Holding Time field set greater than zero (the valid Holding Time for the source binding), and it's only for non-authoritative use for a period not exceeding the Holding Time 🦋.
A Transit NHS may cache destination info from an NHRP Resolution Reply CIE if and only if the D bit is set, and even then only for non-authoritative use for a period not exceeding the Holding Time value in that CIE 💜. A Transit NHS MUST NOT cache source binding info found in an NHRP Resolution Reply. Absolutely not, bestie 🙅♀️.
Also, a transit NHS MUST discard any cached info once the prescribed time has expired ⏰. It may return cached info in response to non-authoritative NHRP Resolution Requests only 🫶.
6.2.2. Dynamics of Cached Information 🌈
NBMA-Connected Destinations
NHRP's most basic job is simple NBMA address resolution for stations that are directly attached to the NBMA subnetwork ✨. These mappings are usually super static, and picking sensible holding times keeps things smooth if a station's NBMA address has to change 🌸. Stale info causes a loss of connectivity, though, and that can be used to trigger an authoritative NHRP Resolution Request that bypasses the old data 💀. In the absolute worst case, connectivity just fails until the cache entry times out 😭.
This applies equally to info marked "stable" (via the "D" bit) in NHRP Resolution Replies 🔥.
Destinations Off of the NBMA Subnetwork
Okay, so if the source of an NHRP Resolution Request is a host, the destination isn't directly attached to the NBMA subnetwork, and the route to that destination isn't considered "stable," the destination mapping can be very dynamic 🦋. The exception is a subnetwork where each destination is only singly homed to the NBMA subnetwork. Because of all that, the cached info very likely goes stale 🙈. The result is a suboptimal path, unless the internetwork has partitioned or some other routing failure happened 🍓.
6.3. Use of the Prefix Length field of a CIE 💅
You have to be careful when using the Prefix Length field of a CIE 🎀, especially about the prefix length being advertised and therefore how big the equivalence class it specifies is. Assuming the routers on the NBMA subnetwork are swapping routing info, an NHS shouldn't be able to create a black hole by advertising too big a set of destinations 🫶. But suboptimal routing can happen, like extra internetwork layer hops through the NBMA 🙈. To avoid that, an NHS that wants to send the Prefix Length MUST follow this rule:
The NHS looks at the Network Layer Reachability Information (NLRI) tied to the route the NHS would use to forward toward the destination (as specified by the Destination internetwork layer address in the NHRP Resolution Request). From that NLRI, it pulls out the shortest address prefix such that: (a) the Destination internetwork layer address from the NHRP Resolution Request is covered by the prefix, and (b) the NHS doesn't have any routes whose NLRI forms a subset of what the prefix covers. The prefix can then be used in the CIE.
The Prefix Length field of the CIE should be used with restraint 🌸, so NHRP stations don't end up picking suboptimal transit paths when overlapping prefixes are available 💜. This document only specifies using the prefix length when all the destinations covered by the prefix are "stable." That means either:
- (a) all destinations covered by the prefix are on the NBMA network, or
- (b) all destinations covered by the prefix are directly attached to the NHRP responding station.
Using the Prefix Length field of the CIE in any other circumstances is outside the scope of this document 🧚.
6.4. Domino Effect 🔥
Picture this: a router, acting as an ingress station to the NBMA subnetwork, gets a data packet, and that packet triggers an NHRP Resolution Request 😳. If the router forwards the data packet without waiting for an NHRP transit path to be established, then when the next router along the path gets the packet, it might do exactly the same thing and originate its own NHRP Resolution Request (while also forwarding the packet) 💀. In fact, one data packet could trigger NHRP Resolution Request generation at every router along the path through an NBMA subnetwork 😭. This is what we call the NHRP "domino" effect 🎲.
The NHRP domino effect is clearly undesirable 🙅♀️. At best, it causes excessive NHRP traffic. At worst, it causes an excessive number of virtual circuits to be established unnecessarily 💔. So it's important to take measures to avoid or suppress this behavior 🛡️. NHRP implementations for NHSs MUST provide a mechanism to address this problem ✨. One possible strategy is to configure a router so that its NHRP Resolution Request generation is driven only by traffic it receives over its non-NBMA interfaces (interfaces not attached to an NBMA subnetwork) 🦋. Traffic the router receives over its NBMA-attached interfaces wouldn't trigger NHRP Resolution Requests 🙈. A router set up this way avoids the NHRP domino effect through administrative means 👑.
7. NHRP over Legacy BMA Networks 🌈
There doesn't appear to be any significant impediment to running NHRP over legacy broadcast subnetworks 🎀. There may be issues around running NHRP across multiple subnetworks 🤔. Running NHRP on broadcast media has some interesting possibilities 👀, especially for setting up a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both end stations are legacy attached 🫶. This use of NHRP needs further research 🧪.
8. Discussion 💜
The result of an NHRP Resolution Request depends on how routing is configured among the NHSs of an NBMA subnetwork 🧠. If the destination station is directly connected to the NBMA subnetwork and the routed path to it lies entirely within the NBMA subnetwork, NHRP Resolution Replies always return the NBMA address of the destination station itself, not the NBMA address of some egress router 🌸. On the other hand, if the routed path exits the NBMA subnetwork, NHRP can't resolve the NBMA address of the destination, so it returns the address of the egress router instead 🦋. For destinations outside the NBMA subnetwork, egress routers and routers in the other subnetworks should exchange routing info so the optimal egress router can be found ✨.
Besides NHSs, an NBMA station could also be associated with one or more regular routers that act as "connectionless servers" for the station 🧚. The station can then choose to resolve the NBMA next hop, or just send packets to one of its connectionless servers 💅. The second option may be desirable if communication with the destination is short-lived and/or doesn't need much network resources 🌷. The connectionless servers could, of course, be physically integrated into the NHSs by adding internetwork layer switching functionality 🔥.
9. IANA Considerations 👑
IANA will take advice from the Area Director appointed designated subject matter expert 🫶, so numbers can be assigned from the various number spaces described here 🎀. If the Area Director appointed designated subject matter expert is unavailable, the relevant IESG Area Director will appoint another expert 🙏. Any and all requests for value assignment within a given number space will be accepted once the usage of the value is documented 🍓. Possible forms of documentation include, but aren't limited to, RFCs or the product of another cooperative standards body, like the MPOA and LANE subworking group of the ATM Forum 🌈.
References ✨
okay bestie, here are all the sources this spec leans on 📚 every single one is listed exactly as written:
- [1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol (NARP)", RFC 1735, December 1994.
- [2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826, November 1982.
- [3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
- [4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams over the SMDS service", RFC 1209, March 1991.
- [5] Protocol Identification in the Network Layer, ISO/IEC TR 9577:1990.
- [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
- [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
- [8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
- [9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
- [10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", RFC 1937, May 1996.
- [11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
- [12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
- [13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork", Work In Progress.
- [14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP Transition", Work In Progress.
- [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
Acknowledgments 🫶
okay the shoutouts are SO deserved 💖 we'd like to thank (in no particular order) Thomas Narten of IBM for his comments in the role of Internet AD, and Juha Heinenan of Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP and the original NHRP draft, which served as the basis for this work. Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, and Grenville Armitage of Bellcore should also be acknowledged for comments and suggestions that improved this work substantially. We would also like to thank the members of the ION working group of the IETF, whose review and discussion of this document have been invaluable 🌸🌈
Authors' Addresses 🎀
here's who to find if you want to chat with the people who made this happen 🧚
James V. Luciani Dave Katz
Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-03 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 978 916 4734 EMail: dkatz@cisco.com
EMail: luciani@baynetworks.com
David Piscitello Bruce Cole
Core Competence Juniper Networks
1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 327 1900
EMail: dave@corecom.com EMail: bcole@jnx.com
Naganand Doraswamy
Bay Networks, Inc.
3 Federal Street
Mail Stop: Bl3-03
Billerica, MA 01801
Phone: +1 978 916 1323
EMail: naganand@baynetworks.comFull Copyright Statement 💅
the legal bit, but make it cute 🦋 this is the copyright notice in full:
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
- ietf: rfc2332 1998-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms