NBMA Next Hop Resolution Protocol (NHRP)
Extracted elements (30)
NHRP Registration Replies cannot simply follow the routed path back to the source because asymmetric routing may prevent delivery. Therefore, a direct NBMA level connection between the NHC and its serving NHS MUST exist before an NHRP Registration Reply can be returned; if none exists, the NHS must establish one using source NBMA information from the Registration Request.
NHRP Requests and Replies do not cross the borders of an NBMA subnetwork; internetwork layer traffic out of or into an NBMA subnetwork always traverses an internetwork layer router at its border. Establishing transit paths across NBMA subnetwork borders requires additional loop-avoidance mechanisms addressed in a separate document.
Non-authoritative NHRP Resolution Replies are distinguished from authoritative replies so that if a communication attempt based on non-authoritative (cached) information fails, the source station can request authoritative information. A transit NHS gains non-authoritative entries by promiscuously listening to non-Registration NHRP packets.
NHRP is designed to be deployed in a non-interfering manner with existing ARP services (RFC 1577, RFC 2225). ARP servers may remain required for hosts that implement only the LIS model; NHRP reduces or eliminates the extra router hops the LIS model incurs without displacing existing ARP infrastructure.
When a protocol has an assigned number in the ar$pro.type space (excluding 0x0080), the short form MUST be used on transmit rather than SNAP encoding. If both Ethertype and NLPID codings exist, the Ethertype coding MUST be used, consistent with RFC 1483. For IP, ar$pro.type=0x0800 is the required encoding.
A station MUST re-send NHRP Registration Requests often enough to refresh registration before the Holding Time expires; it is recommended that the interval equal one-third of the Holding Time specified in the request.
An NHRP Error Indication SHALL NEVER be generated in response to another NHRP Error Indication. When an Error Indication is generated, the offending packet SHALL be discarded, and no more than one Error Indication may be generated per erroneous packet.
An NHRP Resolution Request for a given destination MUST NOT be triggered on every data packet. Resolution should be initiated only when address information is absent from the station's cache.
An NHS MUST NOT change the order of extensions in an NHRP packet. If a transit NHS encounters an unrecognized extension with the Compulsory bit set, it MUST NOT cache the packet's information and MUST NOT identify itself as an egress router; it may only act as a forwarding agent.
Any extensions present in an NHRP Resolution Request MUST be present in the corresponding NHRP Resolution Reply, even if the extension is non-Compulsory.
Cached NHRP next-hop information SHALL be discarded when the Holding Time expires. The Holding Time in a CIE specifies the number of seconds for which the Next Hop NBMA information is considered valid, and MUST be set to 0 on a NAK.
In an NHRP Resolution Reply, the first CIE MUST contain the next hop with the highest preference value, enabling minimal NHC implementations to parse only a single CIE.
In non-connection-oriented networks or when multicast (rather than anycast) addresses are used, NBMA group/multicast addresses MUST NOT be used for sending NHRP resolution requests.
It is RECOMMENDED that SCSP be used for NHS cache synchronization when a LIS/LAG contains two or more router/NHSs, ensuring packets arriving at different NHSs within the same LIS/LAG are forwarded consistently.
NHSs MUST NOT respond to authoritative NHRP Resolution Requests with cached (non-authoritative) information. Only information obtained through NHRP Registration or synchronization with an NHS that obtained it through Registration qualifies as authoritative.
The Request ID for NHRP Registrations maintained at each client MUST be kept in non-volatile memory so that after a crash and reregistration the NHS's database remains consistent. Updating non-volatile memory every 50–100 increments (with the client adding that delta after recovery) is suggested.
When a station receives an NHRP Purge Request it MUST discard all cached information matching the CIEs. An NHRP Purge Reply MUST be returned to the requester whenever the N bit is clear, even if no matching cache entry exists.
When an NHS serves a given NHC, the NHS MUST send NHRP messages destined for the NHC directly to the NHC without transiting through any other NHS that is not serving the NHC.
With the exception of NHRP Registration Requests, an NHC MUST send NHRP messages over a direct NBMA level connection between the serving NHS and the served NHC.
Client Information Entries (CIEs) are the variable-length records appearing in most NHRP message types and carry: Code (1 byte), Prefix Length (1 byte), Maximum Transmission Unit (2 bytes), Holding Time (2 bytes), Cli Addr T/L (1 byte), Cli SAddr T/L (1 byte), Cli Proto Len (1 byte), Preference (1 byte), followed by variable-length Client NBMA Address, Client NBMA SubAddress, and Client Protocol Address fields.
NHRP extensions are TLV-encoded with a 16-bit header: the high bit (C) is the Compulsory flag requiring the responding station to understand the extension or return an Unrecognized Extension error; bit 14 is unused (must be zero); bits 13–0 are the Type. The extensions list is terminated by the Null TLV (Type=0, Length=0).
The ar$hopcnt field limits the number of NHSs an NHRP packet may traverse, functioning like an IP TTL; each transit NHS decrements it. If ar$hopcnt equals zero on a packet that would normally be forwarded, the NHS MUST send a Hop Count Exceeded Error Indication back to the source and drop the packet.
The NHRP Error Indication (type code 7) carries: Src Proto Len, Dst Proto Len, Error Code (16-bit), Error Offset (16-bit from start of fixed header), source NBMA address and subaddress, source and destination protocol addresses, and the contents of the offending NHRP packet. Defined error codes include 1 (Unrecognized Extension), 3 (Loop Detected), 6 (Protocol Address Unreachable), 7 (Protocol Error), 8 (SDU Size Exceeded), 9 (Invalid Extension), 10 (Invalid Resolution Reply), 11 (Authentication Failure), 15 (Hop Count Exceeded).
The NHRP Resolution Reply (type code 2) CIE Code field carries NAK codes: 4 (Administratively Prohibited), 5 (Insufficient Resources), 12 (No binding exists), 13 (Binding exists but uniqueness bit not set). A zero code indicates a positively acknowledged reply; a NAK reply MUST NOT contain any other CIE.
The NHRP Resolution Request (type code 1) flags field carries: Q (sender is a router), A (only authoritative info desired), D (unused), U (uniqueness bit for duplicate address detection; when set, Prefix Length MUST be 0xFF), and S (source address binding is guaranteed stable).
IANA administers the NHRP extension Type space: 0x0000–0x0FFF (Reserved for NHRP), 0x1000–0x11FF (ATM Forum), 0x1200–0x37FF (IETF reserved, IANA-administered), 0x3800–0x3FFF (Experimental, local significance only). NHRP packet type values 128–255 in ar$op.type are also IANA-administered for research use.
The ar$op.version field identifies the protocol: 0 (MARS), 1 (NHRP per RFC 2332), 0x02–0xEF (IETF reserved), 0xF0–0xFE (ATM Forum), 0xFF (Experimental). The ar$pro.type field space assigns 0x0000–0x00FF to NLPIDs, 0x0400–0x04FF to ATM Forum, and 0x0600–0xFFFF to Ethertypes.
NHRP includes an Authentication Failure error code (11) for packets failing an authentication test, and defines an authentication extension mechanism. Without authentication, NHRP is vulnerable to spoofed Registration and Resolution messages that could redirect traffic or poison the NHS cache. The authentication extension (referenced in Section 5.3) provides per-packet integrity protection.
NBMA address type/length fields (ar$shtl, ar$sstl, Cli Addr T/L, Cli SAddr T/L) are 8-bit values: MSB MUST be zero (reserved), bit 6 (x) indicates address format (0=NSAP, 1=Native E.164), and bits 5–0 are an unsigned integer giving the address length in octets. If length is zero, the x flag is ignored.
The NHRP Fixed Header is exactly 20 octets and contains: ar$afn (16-bit address family number), ar$pro.type (16-bit protocol type), ar$pro.snap (40-bit SNAP extension), ar$hopcnt (8-bit hop count), ar$pktsz (16-bit total packet length), ar$chksum (16-bit IP checksum over entire packet), ar$extoff (16-bit extension offset from start of packet), ar$op.version (8-bit), ar$op.type (8-bit), ar$shtl (8-bit source NBMA address type/length), ar$sstl (8-bit source NBMA subaddress type/length).