Routing over Large Clouds Working Group                 James V. Luciani
INTERNET-DRAFT                                            (Bay Networks)
<draft-ietf-rolc-nhrp-08.txt>                                  Dave Katz
INTERNET-DRAFT
                                                         (cisco Systems)
<draft-ietf-rolc-nhrp-07.txt>
                                                        David Piscitello
                                                 (Core Competence, Inc.)
                                                              Bruce Cole
                                                         (cisco Systems)
                                                        James V. Luciani
                                                          (Ascom Nexion)
                                                  Expires December 1996

                NBMA Next Hop Resolution Protocol (NHRP)

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   This document describes the NBMA Next Hop Resolution Protocol (NHRP).
   NHRP can be used by a source station (host or router) connected to a
   Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
   internetworking layer address and NBMA subnetwork addresses of the
   "NBMA next hop" towards a destination station.  If the destination is
   connected to the NBMA subnetwork, then the NBMA next hop is the
   destination station itself.  Otherwise, the NBMA next hop is the
   egress router from the NBMA subnetwork that is "nearest" to the
   destination station.  NHRP is intended for use in a multiprotocol
   internetworking layer environment over NBMA subnetworks.

   This document is intended to be a functional superset of the NBMA
   Address Resolution Protocol (NARP) documented in [1].

   Operation of NHRP as a means of establishing a transit path across an
   NBMA subnetwork between two routers will be addressed in a separate
   document.

1. Introduction

   The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
   (a host or router), wishing to communicate over a Non-Broadcast,
   Multi-Access (NBMA) subnetwork, to determine the internetworking
   layer addresses and NBMA addresses of suitable "NBMA next hops"
   toward a destination station.  A subnetwork can be non-broadcast
   either because it technically doesn't support broadcasting (e.g., an
   X.25 subnetwork) or because broadcasting is not feasible for one
   reason or another (e.g., an SMDS multicast group or an extended
   Ethernet would be too large).  If the destination is connected to the
   NBMA subnetwork, then the NBMA next hop is the destination station
   itself.  Otherwise, the NBMA next hop is the egress router from the
   NBMA subnetwork that is "nearest" to the destination station.

   An

   One way to model an NBMA subnetwork may, in general, consist of multiple Local Address
   Groups (LAGs).  In network is by using the case notion of IP, a logically
   independent IP subnet
   (LIS) is an example of a LAG. subnets (LISs). LISs, as defined in [3] and [4], have
   the following properties:

      1)  All members of a LIS have the same IP network/subnet number
          and address mask.

      2)  All members within a LIS are directly connected to the same
          NBMA subnetwork.

      3)  All members outside of the LIS are accessed via a router.

      4)  All members within the LIS access each other directly
          (without routers)

   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 LIS's.  In multi-LIS
   configurations, hop-by-hop address resolution may not be sufficient
   to resolve the "NBMA next hop" toward the destination station, and IP
   packets may traverse have multiple IP hops through the NBMA subnetwork more than once.

   NHRP describes a next hop resolution method subnetwork.

   Another way to model NBMA is by using the notion of Local Address
   Groups (LAGs) [10]. The essential difference between the LIS and the
   LAG models is that relaxes while with the LIS model the outcome of the
   "local/remote" forwarding restrictions decision is driven purely by addressing
   information, with the LAG model the outcome of this decision is
   decoupled from the LIS model. addressing information and is coupled with the
   Quality of Service and/or traffic characteristics.  With the LAG
   model any two entities on a common NBMA network could establish a
   direct communication with each other, irrespective of the entities'
   addresses.

   Support for the LAG model assumes the existence of a mechanism that
   allows any entity (i.e., host or router) connected to an NBMA network
   to resolve an internetworking layer address to an NBMA address for
   any other entity connected to the same NBMA network.  This resolution
   would take place regardless of the address assignments to these
   entities. NHRP describes such a mechanism.  For example, when the
   internetwork
   internetworking layer address is of type IP, once the NBMA next hop
   has been resolved, the source may either start sending IP packets to
   the destination (in a connectionless NBMA subnetwork such as SMDS) or
   may first establish a connection to the destination with the desired
   bandwidth and QOS characteristics (in a connection-oriented NBMA
   subnetwork such as ATM).

   Use of NHRP in its most basic form provides a simple internetworking layer
   to NBMA subnetwork layer address binding service.  This may be sufficient for hosts which doing address resolution when
   those hosts are directly connected to an NBMA subnetwork, allowing
   for straightforward implementations in NBMA stations. NHRP also has
   the capability of determining the egress point from an NBMA
   subnetwork when the destination is not directly connected to the NBMA
   subnetwork and the identity of the egress router is not learned by
   other methods (such as routing protocols).  Optional extensions to
   NHRP provide additional robustness and diagnosability.

   Address resolution techniques such as those described in [3] and [4]
   may be in use when NHRP is deployed.  ARP servers and services over
   NBMA subnetworks may be required to support hosts that are not
   capable of dealing with any model for communication other than the
   LIS model, and deployed hosts may not implement NHRP but may continue
   to support ARP variants such as those described in [3] and [4].  NHRP
   is intended to reduce or eliminate the extra router hops required by
   the LIS model, and can be deployed in a non-interfering manner
   alongside existing ARP services.

   The operation of NHRP to establish transit paths across NBMA
   subnetworks between two routers requires additional mechanisms to
   avoid stable routing loops, and will be described in a separate
   document.

2. Overview

2.1 Terminology

   The term "network" is highly overloaded, and is especially confusing
   in the context of NHRP.  We use the following 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.)

2.2 Protocol Overview

   In this section, we briefly describe how a source S (which
   potentially can be either a router or a host) uses NHRP

     The term "server", unless explicitly stated to determine the "NBMA next hop" contrary, refers
     to destination D.

   For administrative and an 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 ubiquitous deployment of this functionality occurs.

     The term "client", unless explicitly stated to the contrary, refers
     to an Next Hop Resolution Protocol client (NHC).  An NHC is an
     entity which 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 which
     contains an NHRP entity.  Occasionally, the term station will
     describe a "user" of the NHRP client or service functionality; the
     difference in usage is largely semantic.

2.2 Protocol Overview

   In this section, we briefly describe how a source S (which
   potentially can be either a router or a host) uses NHRP to determine
   the "NBMA next hop" to destination D.

   For administrative and policy reasons, a physical NBMA subnetwork may
   be partitioned into several, disjoint "Logical NBMA subnetworks".  A
   Logical NBMA subnetwork is defined as a collection of hosts and
   routers that share unfiltered subnetwork connectivity over an NBMA
   subnetwork.  "Unfiltered subnetwork connectivity" refers to the
   absence of closed user groups, address screening or similar features
   that may be used to prevent direct communication between stations
   connected to the same NBMA subnetwork.  (Hereafter, unless otherwise
   specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
   subnetwork.)
   Placed within the NBMA subnetwork are one or more entities that
   implement the NHRP protocol.  Such stations which are capable of
   answering Next Hop Resolution Requests are known as "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
   cooperatively resolve the NBMA next hop within their logical NBMA
   subnetwork.  In addition to NHRP, NHSs may participate in protocols
   used to disseminate routing information across (and beyond the
   boundaries of) the NBMA subnetwork, and may support "classical" ARP
   service as well.

   An NHS maintains a "next-hop resolution" cache, which is a table of
   address mappings (internetwork layer address to NBMA subnetwork layer
   address).  This table can be constructed from information gleaned
   from NHRP Register packets (see Section 5.2.3 and 5.2.4), extracted
   from Next Hop Resolution Requests/Replies that traverse the NHS as
   they are forwarded, or through mechanisms outside the scope of this
   document (examples of such mechanisms include ARP [2, 3, 4] and pre-
   configured tables).  Section 6.2 further describes cache management
   issues.

   A host or router that is not an NHRP server must be configured with
   the identity of the NHS which serves it (see Configuration, Section
   4).

   [Note: for NBMA subnetworks that offer group or multicast addressing
   features, it may be desirable to configure stations with a group
   identity for NHSs, i.e., addressing information that would solicit a
   response from "all NHSs".  The means whereby a group of NHSs divide
   responsibilities for next hop resolution are not described here.]

   Whether or not a particular station within the NBMA subnetwork which
   is making use of the NHRP protocol needs to be able to act as an NHS
   is a local matter.  For a station to avoid providing NHS
   functionality, there must be one or more NHSs within the NBMA
   subnetwork which are providing authoritative NBMA information on its
   behalf.  If NHRP is to be able to resolve the NBMA address for
   stations that lack NHS functionality, these serving NHSs must exist
   along all routed paths between Next Hop Resolution Requesters and the
   station which cannot answer Next Hop Resolution Requests.

   The protocol proceeds as follows.  An event occurs triggering station
   S to want to resolve the NBMA address of a path to D.  This is most
   likely to be when a data packet addressed to station D is to be
   emitted from station S (either because station S is a host, or
   station S is a transit router), but the address resolution could also
   be triggered by other means (a routing protocol update packet, for
   example).  Station S first determines the next hop to station D
   through normal routing processes (for a host, the next hop may simply
   be the default router; for routers, this is the "next hop" to the
   destination internetwork layer address).  If the next hop is
   reachable through one of its NBMA interface, interfaces, S constructs an Next
   Hop Resolution Request packet (see Section 5.2.1) containing station
   D's internetwork layer address as the (target) destination address,
   S's own internetwork layer address as the source address (Next Hop
   Resolution Request initiator), and station S's NBMA addressing
   information.  Station S may also indicate that it prefers an
   authoritative Next Hop Resolution Reply (i.e., station S only wishes
   to receive a Next Hop Resolution Reply from the NHS-speaker that
   maintains the NBMA-to-internetwork layer address mapping for this
   destination).  Station S emits the Next Hop Resolution Request packet
   towards the destination, using the NBMA address of the next routed
   hop. destination.

   If the Next Hop Resolution Request is triggered by a data packet,
   station S may choose to dispose of the data packet while awaiting a
   Next Hop Resolution Reply in one of the following ways:

     (a)  Drop the packet
     (b)  Retain the packet until the Next Hop Resolution Reply arrives
          and a more optimal path is available
     (c)  Forward the packet along the routed path toward D

   The choice of which of the above to perform is a local policy matter,
   though option (c) is the recommended default, since it may allow data
   to flow to the destination while the NBMA address is being resolved.
   Note that an Next Hop Resolution Request for a given destination MUST
   NOT be triggered on every packet, though periodically retrying a Next
   Hop Resolution Request is permitted.

   When the NHS receives an Next Hop Resolution Request, a check is made
   to see if it "serves" station D, i.e., the NHS checks to see if there
   is a "next hop" entry for D in its next-hop resolution cache.  If the
   NHS does not serve D, the NHS forwards the Next Hop Resolution
   Request to another NHS.  (Mechanisms for determining how to forward
   the Next Hop Resolution Request are discussed in Section 3,
   Deployment.) Note that NHSs must be next hops to one another in order
   for forwarding of NHRP packets to be possible.

   If this NHS serves D, the NHS resolves station D's NBMA address, and
   generates a positive Next Hop Resolution Reply (denoted by a 0 Code
   in the reply) on D's behalf.  (Next Hop Resolution Replies in this
   scenario are always marked as "authoritative".)  The Next Hop
   Resolution Reply packet contains the next hop internetwork layer
   address and the NBMA address for station D and is sent back to S.
   (Note that if station D is not on the NBMA subnetwork, the next hop
   internetwork layer address will be that of the egress router through
   which packets for station D are forwarded.)

   An NHS receiving a Next Hop Resolution Reply may cache the NBMA next
   hop information contained therein.  To a subsequent Next Hop
   Resolution Request, this NHS may respond with the cached, non-
   authoritative, NBMA next hop information or with cached negative
   information, if the NHS is allowed to do so, see section 5.2.2 and
   6.2.  Non-
   authoritative  Non-authoritative Next Hop Resolution Replies are distinguished
   from authoritative Next Hop Resolution Replies so that if a
   communication attempt based on non-authoritative information fails, a
   source station can choose to send an authoritative Next Hop
   Resolution Request.  NHSs MUST NOT respond to authoritative Next Hop
   Resolution Requests with cached information.

     [Note: An Next Hop Resolution Reply can be returned directly to the
     Next Hop Resolution Request initiator, i.e., without traversing the
     list of NHSs that forwarded the Next Hop Resolution Request, if all
     of the following criteria are satisfied:

       (a) Direct communication is available via datagram transfer
           (e.g., SMDS) or the NHS has an existing virtual circuit
           connection to the Next Hop Resolution Request initiator or is
           permitted to open one.
       (b) The Next Hop Resolution Request initiator has not included the
           NHRP Reverse NHS record Extension (see Section 5.3.5).
       (c) The authentication policy in force permits direct
           communication between the NHS and the Next Hop Resolution
           Request initiator.

     The purpose of allowing an NHS to send a Next Hop Resolution Reply
     directly is to reduce response time.  A consequence of allowing a
     direct Next Hop Resolution Reply is that NHSs that would under
     normal circumstances be traversed by the Next Hop Resolution Reply
     would not cache next hop information contained therein.]

   The process of forwarding the Next Hop Resolution Request is repeated
   until the Next Hop Resolution Request is satisfied, or an error
   occurs (e.g., no NHS in the NBMA subnetwork can resolve the Next Hop
   Resolution Request.) If the determination is made that station D's
   next hop cannot be resolved, a negative Next Hop Resolution Reply
   (NAK) is returned.  This occurs when (a) no next-hop resolution
   information is available for station D from any NHS, or (b) an NHS is
   unable to forward the Next Hop Resolution Request (e.g., connectivity
   is lost).

   NHRP Registration Requests, NHRP Registration Replies, NHRP Purge Requests, NHRP Purge Replies,
   and NHRP Error Indications follow the routed path from sender to
   receiver in the same fashion that Next Hop Resolution Requests and
   Next Hop Resolution Replies do.  That is, "requests" and
   "indications" follow the routed path from Source Protocol Address
   (which is the address of the station initiating the communication) to
   the Destination Protocol Address.  "Replies", on the other hand,
   follow the routed path from the Destination Protocol Address back to
   the Source Protocol Address with the exceptions mentioned above where
   a direct VC may be created.

   Next Hop Resolution  In the case of a NHRP Registration
   Reply, the packet is always returned via a direct VC (see Section
   5.2.4).

   NHRP Requests and Next Hop Resolution NHRP Replies MUST NOT cross the borders of a
   logical NBMA subnetwork (an explicit NBMA subnetwork identifier may
   be included as an extension in the Next Hop Resolution Request, see
   section 5.3.2).  Thus, the internetwork layer traffic out of and into
   a logical NBMA subnetwork always traverses an internetwork layer
   router at its border.  Internetwork layer filtering can then be
   implemented at these border routers.

   NHRP optionally provides a mechanism to send a Next Hop Resolution
   Reply which contains aggregated NBMA next hop information.  Suppose
   that router X is the NBMA next hop from station S to station D.
   Suppose further that X is an egress router for all stations sharing
   an internetwork layer address prefix with station D.  When an Next
   Hop Resolution Reply is generated in response to a Next Hop
   Resolution Request, the responder may augment the internetwork layer
   address of station D with a prefix length (see Section 5.3.1). 5.2.0.1).  A
   subsequent (non-authoritative) Next Hop Resolution Request for some
   destination that shares an internetwork layer address prefix (for the
   number of bits specified in the prefix length) with D may be
   satisfied with this cached information.  See section 6.2 regarding
   caching issues.

   To dynamically detect subnetwork-layer filtering in NBMA subnetworks
   (e.g., X.25 closed user group facility, or SMDS address screens), as
   well as to
   trace the routed path that 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.4 and 5.3.5).  The Route
   Record extensions contain the internetwork (and subnetwork layer)
   addresses of all intermediate NHSs between source and destination (in
   the forward direction) and between destination and source (in the
   reverse direction).  When a source station is unable to communicate
   with the responder (e.g., an attempt to open an SVC fails), it may
   attempt to do so successively with other subnetwork layer addresses
   in the Route Record until it succeeds (if authentication policy
   permits such action).  This approach can find a suitable egress point
   in the presence of subnetwork-layer filtering (which may be
   source/destination sensitive, for instance, without necessarily
   creating separate logical NBMA subnetworks) or subnetwork-layer
   congestion (especially in connection-oriented media).

3. Deployment

   Next Hop Resolution Requests traverse one or more hops within an NBMA
   subnetwork before reaching the station that is expected to generate a
   response.  Each station, including the source station, chooses a
   neighboring NHS to which it will forward the Next Hop Resolution
   Request.  The NHS selection procedure typically involves performing applying a
   routing decision based upon the network layer
   destination protocol layer address of to the protocol layer routing
   table which causes a routing decision to be returned.  This routing
   decision is then used to forward the Next Hop Resolution Request.  Ignoring error situations, Request to
   the downstream NHS. The destination protocol layer address previously
   mentioned is carried within the Next Hop Resolution Request eventually arrives at a station packet.
   Note that even though a protocol layer address was used to acquire a
   routing decision, NHRP packets are not encapsulated within a protocol
   layer header but rather are carried at the NBMA layer using the
   encapsulation described in Section 5.

   Each NHS/router examines the Next Hop Resolution Request packet on
   its way toward the destination.  Each NHS which the NHRP packet
   traverses on the way to the packet's destination might modify the
   packet (e.g., updating the Forward Record extension).  Ignoring error
   situations, the Next Hop Resolution Request eventually arrives at a
   station that is to generate an Next Hop Resolution Reply.  This
   responding station
   either serves the destination, or is the destination itself if both
   NHRP client and server functionality are co-resident in "serves" the same
   station. destination.  The responding station
   generates a Next Hop Resolution Reply using the source protocol
   address from within the NHRP packet to determine where the Next Hop
   Resolution Reply should be sent.

   The Next Hop Resolution Request packet is carried at the NBMA layer,
   with a destination NBMA address set to that of the locally determined
   NHS.  If the addressed NHS does not serve the destination address
   specified in the Next Hop Resolution Request, the Next Hop Resolution
   Request packet is routed at the network layer based upon the Next Hop
   Resolution Requester's destination address, and forwarded to the
   neighboring NHS determined by the

   Rather than use routing decision.  Alternately, to determine the next hop for an NHRP packet,
   an NHS may use static configuration information (or other applicable
   means) in order to determine to which neighboring NHSs to forward the
   Next Hop Resolution Request packet.  Each NHS/router examines the Next Hop Resolution Request
   packet on its way toward the destination, optionally modifying it on
   the way (such as updating the Forward Record extension), and
   continues to forward it until it reaches the NHS that serves  The use of static configuration
   information for this purpose is beyond the
   destination network layer address. scope of this document.

   In order to forward NHRP packets to a neighboring NHS, NHRP clients
   must nominally be configured with the NBMA address of at least one
   NHS.  In practice, a client's default router should also be its NHS.
   A client may be able NHS
   in that way a client may be able to derive know the NBMA address of its NHS
   from the configuration that which was already required for the client to
   be able to
   communicate with its next hop router.

   Forwarding communicate.

   The NHS serving a particular destination must lie along the routed
   path to that destination.  In practice, this means that all egress
   routers must double as NHSs serving the destinations beyond them, and
   that hosts on the NBMA subnetwork are served by routers that double
   as NHSs.  Also, this implies that forwarding of NHRP packets within
   an NBMA subnetwork requires a contiguous deployment of NHRP capable stations.
   routers.  During migration to NHRP, it cannot be expected that all stations
   routers within the NBMA subnetwork are NHRP capable.  Thus, NHRP
   traffic which would otherwise need to be forwarded through such stations
   routers can be expected to be dropped due to the NHRP packet not
   being unrecognized. recognized.  In this case, NHRP will be unable to establish any
   transit paths whose discovery requires the traversal of the non-NHRP
   speaking stations. routers.  If the client has tried and failed to acquire a
   cut through path the then the client should use the network layer routed
   path as a default.

   If a subnetwork offers a link layer group addressing or multicast
   feature, the client (station) may be configured with a group address
   assigned to the group of next-hop servers.  The path taken by client might then
   submit Next Hop Resolution Requests will normally be the
   same as to the path taken by data packets which are routed at group address, eliciting a
   response from one or more NHSs, depending on the
   network layer to response strategy
   selected.  Note that the desired destination.  (The paths may be
   different constraints described in situations where NHSs have been statically configured to
   forward traffic by other means.  For example, an Section 2 regarding
   directly sending Next Hop Resolution
   Request Reply may be forwarded to apply.

4. Configuration

   Clients

     To participate in NHRP, a group multicast address.)

   NHSs client connected to an NBMA subnetwork
     should acquire knowledge about destinations other NHSs serve as be configured with the NBMA address(es) of its NHS(s)
     (alternatively, it should be configured with a direct consequence means of participating in intra-domain and inter-
   domain routing protocol exchange.  In this case, acquiring
     them, i.e., the NHS serving group address that members of a
   particular destination must lie along NHS group use for
     the routed path to that
   destination.  In practice, this means that all egress routers must
   double as NHSs serving the destinations beyond them, and that hosts
   on purpose of address or next-hop resolution.)  The NHS(s) will
     likely also represent the client's default or peer routers, so
     their NBMA subnetwork are served by routers that double as NHSs.

   NHSs (and end stations) addresses may alternately be statically configured with obtained from the NBMA addresses of their neighbors, client's existing
     configuration.  If the identities of client is attached to several subnetworks
     (including logical NBMA subnetworks), the
   destinations client should also be
     configured to receive routing information from its NHS(s) and peer
     routers so that each it can determine which internetwork layer networks
     are reachable through which subnetworks.

   Next Hop Servers

     An NHS is configured with knowledge of them serves, its own internetwork layer
     and NBMA addresses and optionally a logical NBMA subnetwork identifier.  Such static configurations may be necessary
   in cases where NHSs do not contain network layer routing protocol
   implementations.

   If the NBMA subnetwork offers a link layer group addressing or
   multicast feature, the client (station) may identifier (see
     Section 5.3.2).  An NHS MAY also be configured with a
   group set of
     internetwork layer address assigned prefixes that correspond to the group
     internetwork layer addresses of next-hop servers.  The client
   might then submit Next Hop Resolution Requests to the group address,
   eliciting stations it serves. If a response from one or more NHSs, depending on the response
   strategy selected.  Note that served
     client is attached to several subnetworks, the constraints described in Section 2
   regarding directly sending Next Hop Resolution Reply may apply.

   NHSs NHS may also need to
     be deployed with the group or multicast address of
   their peers, and an NHS might use this as a means of forwarding Next
   Hop Resolution Requests it cannot satisfy configured to its peers.  This might
   elicit a response (to advertise routing information to such client.

     If an NHS acts as an egress router for stations connected to other
     subnetworks than the NHS) from one or more NHSs, depending on NBMA subnetwork, the response strategy.  The NHS would then forward the Next Hop
   Resolution Reply must, in addition to
     the Next Hop Resolution Request originator.  The
   purpose of using group addressing or a similar multicast mechanism in
   this scenario would above, be configured to eliminate exchange routing information between
     the need to preconfigure each NHS
   in a logical NBMA subnetwork with both the individual identities of and these other NHSs as well as subnetworks.

     In all cases, routing information is exchanged using conventional
     intra-domain and/or inter-domain routing protocols.

     The NBMA addresses of the destinations they serve.  It reduces stations served by the
   number of NHSs that might NHS may be traversed to process an Next Hop
   Resolution Request (in those configurations where NHSs either respond
   or forward learned
     via NHRP Register packets or manual configuration.

5. NHRP Packet Formats
   This section describes the multicast, only two NHSs would be traversed), and
   allows format of NHRP packets.  In the NHS that serves following,
   unless otherwise stated explicitly, the Next Hop Resolution Request originator unqualified term "request"
   refers generically to cache next hop information associated with any of the Next Hop Resolution
   Reply (again, within NHRP packet types which are
   "requests".  Further, unless otherwise stated explicitly, the constraints described in Section 2).

4. Configuration

   Stations

     To participate in NHRP, a station connected
   unqualified term "reply" refers generically to an NBMA subnetwork
     should be configured with the NBMA address(es) any of its NHS(s)
     (alternatively, it should be configured with a means of acquiring
     them, i.e., the group address that members of a NHS group use for
     the purpose of address or next-hop resolution.)  The NHS(s) will
     likely also represent the station's default or peer routers, so
     their NBMA addresses may be obtained from the station's existing
     configuration.  If the station is attached to several subnetworks
     (including logical NBMA subnetworks), the station should also be
     configured to receive routing information from its NHS(s) and peer
     routers so that it can determine NHRP packet
   types 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, a set of internetwork layer address prefixes
     that correspond to the internetwork layer addresses of the stations
     it serves, and a logical NBMA subnetwork identifier (see Section
     5.3.2).  If a served station is attached to several subnetworks,
     the NHS may also need to be configured to advertise routing
     information to such stations.

     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 these other subnetworks.

     In all cases, routing information is exchanged using conventional
     intra-domain and/or inter-domain routing protocols.

     The NBMA addresses of the stations served by the NHS may be learned
     via NHRP Register packets or manual configuration.

5. NHRP Packet Formats
   This section describes the format of NHRP packets. "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 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 minus
   20. ar$extoff.  NHSs
   may increase the size of an NHRP packet as a result of extension
   processing, but not beyond the offered maximum SDU size of the NBMA
   network.

   NHRP packets are encapsulated using the native formats used on the
   particular NBMA network over which NHRP is carried.  For example,
   SMDS networks always use LLC/SNAP encapsulation at the NBMA layer,
   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 NHRP (see [4]).

   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 a 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-independent fields always come first in the packet, and the
   protocol type/snap fields (ar$pro.type/snap) qualify the format of
   the protocol-specific fields.

5.1 NHRP Fixed Header

   The Fixed Part of the NHRP packet contains those elements of the NHRP
   packet which are always present and do not vary in size with the type
   of packet.

          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
     Defines the type of "link layer" addresses being carried.  This
     number is taken from the 'address family number' list specified in
     [6].  This field has implications to the coding of ar$shtl and
     ar$sstl as described below.

   ar$pro.type
     field is a 16 bit unsigned integer representing the following
     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.)

   ar$pro.snap
     When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
     being used to encode the protocol type. This snap extension is
     placed in the ar$pro.snap field.  This is termed 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. This is termed
     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. Additionally, where a protocol has
     valid short and long forms of identification, receivers MAY choose
     to recognize the long form.

   ar$hopcnt
     The Hop count indicates the maximum number of NHSs that an NHRP
     packet is allowed to traverse before being discarded.

   ar$pktsz
     The total length of the NHRP packet, in octets (excluding link
     layer encapsulation).

   ar$chksum
     The standard IP checksum over the entire NHRP packet (starting with
     the fixed header).  If only the hop count field is changed, the
     checksum is adjusted without full recomputation.  The checksum is
     completely recomputed when other header fields are changed.

   ar$extoff
     This field identifies the existence and location of NHRP
     extensions.  If this field is 0 then no extensions exist otherwise
     this field represents the offset from the beginning of the NHRP
     packet (i.e., starting from the ar$afn field) of the first
     extension.

   ar$op.version
     This field is set to 0x0001 0x01 for NHRP version 1.

   ar$op.type
     This is the NHRP packet type: NHRP Next Hop Resolution Request(1),
     NHRP Next Hop Resolution Reply(2), NHRP Registration Request(3),
     NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge
     Reply(6), or NHRP Error Indication(7).  Use of NHRP packet Types in
     the range 128 to 255 are reserved for research or use in other
     protocol development and will be administered by IANA.

   ar$shtl
     Type & length of source NBMA address interpreted in the context of
     the 'address family number'[6] indicated by ar$afn (e.g.,
     ar$afn=0x0003 for NSAP, ar$afn=8 for E.164).  When ar$afn=0x000F
     (E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl
     must be coded appropriately (see below).

   ar$sstl
     Type & length of source NBMA subaddress interpreted in the context
     of the 'address family number'[6] indicated by ar$afn (e.g.,
     ar$afn=0x000F for NSAP).  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.

   ar$shtl, ar$sstl, subnetwork layer addresses, and subnetwork layer
   subaddresses fields are coded as follows:

                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.

   In the case where the NBMA is ATM, if a subaddress is to be included
   then ar$afn MUST be set to 0x000F which means that if a subaddress
   exists then it is of type NSAP.

   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

5.2.0 Mandatory Part

   The Mandatory Part of the NHRP packet contains the operation specific
   information (e.g., Next Hop Resolution Request/Reply, etc.) and
   variable length data which is pertinent to the packet type.

5.2.0.1 Mandatory Part Format

   Sections 5.2.1 NHRP Next Hop Resolution Request

   The NHRP Next Hop Resolution Request packet through 5.2.6 have a very similar mandatory part.
   This mandatory part includes a common header and zero or more Client
   Information Entries (CIEs). Section 5.2.7 has a Type code of 1. different format
   which is specified in that section.

   The
   Mandatory Part has common header looks like the following format: following:

          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 |Q|A|P|B|       unused |           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 have the following 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Code       | Prefix Length |         unused                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Maximum Transmission Unit    |        Holding Time           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            unused  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source            Client NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source           Client NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source          Client Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .....................
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination    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)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meanings of the fields are as follows:

   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.

   NHRP Next Hop Resolution Request/Reply

   Flags

     Q
       Set if the station sending
     These flags are specific to the Next Hop Resolution Request is a
       router;  clear if the it is a host.

     A
       A response to a Next Hop Resolution Request may contain cached
       information. If an authoritative answer is desired, then this bit
       ("Authoritative") should be set.  If non-authoritative (cached)
       information is acceptable, this bit should be clear.

     P
       Unused (clear on transmit)

     B
       Unused (clear on transmit) given message type and they are
     explained in each section.

   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Next Hop Resolution Request and its associated Next Hop Resolution
     Reply, and any subsequent Purge.
     "request" packet.  This value can be used by is copied directly from an "request"
     packet into the
     source to aid in matching a Next Hop Resolution Request with associated "reply".  When a Next
     Hop Resolution Reply.  This value could also be sent across sender of a
     virtual circuit (in SVC environments) to aid "request"
     receives "reply", it will compare the Request ID and source address
     information in matching NHRP
     transactions with virtual circuits (this use the received "reply" against that found in its
     outstanding "request" list.  When a match is for further study). found then the
     "request" is considered to be acknowledged.

     The value is taken from a 32 bit counter that is incremented each
     time a new Next Hop Resolution Request "request" is transmitted.  The same value MUST be used
     when sending another Next Hop Resolution Request
     for the same destination when resending a previous Next Hop Resolution
     Request is still active or pending, "request", i.e., when retransmitting a
     Next Hop Resolution Request because a Next Hop Resolution Reply was "reply" has not received, or when refreshing an existing entry to avoid holding
     timer expiration.  A new value MUST be used when sending been
     received for a Next Hop
     Resolution Request when no cache entry is present, or "request" and a previous
     cache entry was deleted for any reason.

   Maximum Transmission Unit
     This field gives the maximum transmission unit for the target
     station.  This field retry is ignored in Next Hop Resolution Requests and
     should be set to 0.  A possible use of this field in the Next Hop
     Resolution Request packet is for the Next Hop Resolution Requester
     to ask for a target MTU.  This use is for further study.

   Holding Time sent after an appropriate
     interval.

   The Holding Time field specifies the number of seconds for which
     the client NBMA information (the information of the client issuing
     the Next Hop Resolution Request) is considered to be valid. The
     contents address/subaddress form specified below allows combined
   E.164/NSAPA form of this field along with the source address information
     MAY be cached by transit NHSs.  The holding time should be set to
     the remaining time left in NBMA addressing. For NBMA technologies without a
   subaddress concept, the client's registration with its
     server.  If this subaddress field is set to 0 then transit NHSs MUST not cache
     the client's NBMA information. always ZERO length and
   ar$sstl = 0.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which is sending the Next Hop Resolution Request. "request". If the field's length as specified
     in ar$shtl is 0 then no storage is allocated for this address at
     all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which is sending the Next Hop Resolution Request. "request".  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 which is sending the
     Next Hop Resolution Request.
     "request".  This is also the protocol address of the station toward
     which a "reply" packet is sent.

   Destination Protocol Address
     This is the protocol address of the station for toward which a
     "request" packet is sent.

   Code
     This field is message specific.  See the NBMA next
     hop relevant message sections
     below.  In general, this field is desired.

   (The NBMA address/subaddress form allows combined E.164/NSAPA form of
   NBMA addressing. For NBMA technologies without a subaddress concept, NAK code; i.e., when the subaddress field
     is always ZERO length and ar$sstl = 0.)

5.2.2 NHRP Next Hop Resolution Reply

   The NHRP Next Hop Resolution Reply 0 in a reply then the packet has is acknowledging a type code of 2.  The
   Mandatory Part has the following 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 |Q|A|P|B|       unused          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Maximum Transmission Unit    |        Holding Time           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NH Addr T/L   | NH SAddr T/L |  NH Proto Len |  Preference   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop Protocol Address (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.

   Next Hop Resolution Request/Reply Flags

     Q
       Copied from the Next Hop Resolution Request.  Set if the Next Hop
       Resolution Requester is a router;  clear if it is a host.

     A
       Set if the next hop in the Next Hop Resolution Reply is
       authoritative; clear if the Next Hop Resolution Reply is non-
       authoritative.

     P
       Set if the Next Hop Resolution Reply is positive;  clear if the
       Next Hop Resolution Reply is negative.

     B
       Set if the association between the destination and the next hop
       information is guaranteed to be stable for the lifetime of the
       information (the holding time).  This is the case if the Next Hop
       protocol address identifies the destination (though it may be
       different in value than the Destination address if the
       destination system has multiple addresses) or if the destination
       is not connected directly to the NBMA subnetwork but the egress
       router to that destination is guaranteed to be stable (such as
       when the destination is immediately adjacent to the egress router
       through a non-NBMA interface).  This information affects caching
       strategies (see section 6.2).

     An NHS is not allowed to send a Next Hop Resolution Reply to an
     Next Hop Resolution Request for authoritative information with
     cached information, but may do so for an NHRP Next Hop Resolution
     Request which indicates a request for non-authoritative
     information. An NHS may send an Next Hop Resolution Reply to an
     Next Hop Resolution Request for non-authoritative information with
     authoritative information.

   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     Next Hop Resolution Request and its associated Next Hop Resolution
     Reply, and any subsequent Purge.  This value can be used by the
     source to aid in matching a Next Hop Resolution Request with a Next
     Hop Resolution Reply.  This value could also be sent across a
     virtual circuit (in SVC environments) to aid in matching NHRP
     transactions with virtual circuits (this use is for further study).

     The value is taken from a 32 bit counter that is incremented each
     time a new Next Hop Resolution Request is transmitted.  The same
     value MUST be used when sending another Next Hop Resolution Request
     for the same destination when a previous Next Hop Resolution
     Request is still active or pending, i.e., when retransmitting a
     Next Hop Resolution Request because a Next Hop Resolution Reply was
     not received, or when refreshing an existing entry to avoid holding
     timer expiration.  A new value MUST be used when sending a Next Hop
     Resolution Request when no cache entry is present, or a previous
     cache entry was deleted for any reason.

   Maximum Transmission Unit
     This field gives the maximum transmission unit for the Next Hop
     information supplied in the mandatory part of the packet.  If this
     value is 0 then either the default MTU is used or the MTU
     negotiated via signaling is used if such negotiation is possible
     for the given NBMA.

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the Next Hop NBMA information specified in the mandatory part of request and if
     it contains any other value the packet is considered to be valid.  Cached information SHALL be
     discarded when the holding time expires.  This field must be set to
     0 on contains a NAK.

   NH Addr T/L
     Type & length of next hop NBMA address specified in the mandatory
     part of the packet. negative
     acknowledgment.

   Prefix Length
     This field is interpreted in the context of the
     'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003
     for ATM).

   NH SAddr T/L
     Type & length of next hop NBMA subaddress specified in the
     mandatory part of message specific.  See the packet. This field relevant message sections
     below.  In general, however, this fields is interpreted in the
     context of the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0015 for ATM makes used to indicate that
     the address information carried in an E.164 and NHRP the
     subaddress an ATM Forum NSAP address).  When message pertains to an NBMA technology has
     no concept
     equivalence class of internetwork layer addresses rather than just
     a subaddress single internetwork layer address specified. All internetwork
     layer addresses that match the subaddress is always null with a
     length of 0.  When first "Prefix Length" bit positions
     for the specific internetwork layer address length is specified as 0 no storage
     is allocated for are included in the address.

   NH Proto Len
     equivalence class.

   Maximum Transmission Unit
     This field holds gives the length in octets of maximum transmission unit for the Next Hop Protocol
     Address specified in relevant
     client station.  If this value is 0 then either the mandatory part of default MTU is
     used or the packet (additional
     next hop entries may be specified in MTU negotiated via signaling is used if such
     negotiation is possible for the Additional Next Hop
     Entries Extension (see Section 5.2.9)).

   Preference
     This given NBMA.

   Holding Time
     The Holding Time field specifies the preference number of seconds for which
     the Next Hop entry NBMA information specified in the mandatory part of the packet.  This preference value CIE is
     relative considered to other Next Hop entries in this NHRP Next Hop Resolution
     Reply packet which may
     be by the Additional Next Hop Entries
     Extension (see Section 5.3.9) for the given internetworking
     protocol.  Higher values indicate higher preference.  Action taken valid.  Cached information SHALL be discarded when multiple next hop entries have the highest preference value is
     a local matter. Set holding
     time expires.  This field must be set to 0 on a NAK.

   Source NBMA Address
     The Source

   Cli Addr T/L
     Type & length of next hop NBMA address field is the address of the source station
     which sent the Next Hop Resolution Request. If the field's length
     as specified in ar$shtl is 0 then no storage is allocated for this
     address at all.

   Source NBMA SubAddress
     The Source NBMA subaddress the CIE.  This
     field is interpreted in the address context of the source
     station which sent the Next Hop Resolution Request. If the field's 'address family
     number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).

   Cli SAddr T/L
     Type & length as of next hop NBMA subaddress 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 which sent the Next Hop
     Resolution Request.

   Destination Protocol Address the CIE.
     This field is interpreted in the protocol address context of the station 'address family
     number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for which ATM makes
     the address an E.164 and the subaddress an ATM Forum NSAP address).
     When an NBMA next
     hop is desired.

     (The NBMA address/subaddress form allows combined E.164/NSAPA form technology has no concept of NBMA addressing. For NBMA technologies without a subaddress
     concept, subaddress, the
     subaddress field is always ZERO null with a length and ar$sstl =
     0.)

   The following is of 0.  When the Next Hop entry address
     length is specified as 0 no storage is allocated for the address.

   Cli Proto Len
     This field holds the length in octets of the Client Protocol
     Address specified in the Mandatory
   Part CIE.

   Preference
     This field specifies the preference for use of the packet:

     Next Hop specific CIE
     relative to other CIEs.  Higher values indicate higher preference.
     Action taken when multiple CIEs have equal or highest preference
     value is a local matter.

   Client NBMA Address
     This is the client's NBMA address of the station that is the next hop for
       packets bound for the internetworking layer address specified.

     Next Hop address.

   Client NBMA SubAddress
     This is the client's NBMA subaddress of the station that is the next hop
       for packets bound for the internetworking layer address
       specified.

     Next Hop subaddress.

   Client Protocol Address
     This is the client's internetworking layer address specifies the next hop.  This
       will be the address of the destination host if it is directly
       attached to the NBMA subnetwork, or the egress router if it specified.

   Note that an NHS SHOULD NOT cache source information which is
       not directly attached.

   There may be multiple Next Hop entries returned in the Next Hop
   Resolution Reply by including the Additional Next Hop Entries
   Extension.  See Section 5.3.9 for use of these entries.  The most
   preferable Next Hop must an
   NHRP message because this information could be specified inappropriately used
   to set up a cut-through without doing proper filtering along a routed
   path.  Further, in the mandatory part of the
   Next Hop Resolution Reply.

   Any extensions present case where a distributed router exists in the Next Hop Resolution Request packet MUST
   network, incorrect or incomplete information may be present included in the
   source information.

5.2.1 NHRP Next Hop Resolution Reply packet, except for
   the case of unrecognized non-Compulsory extensions.

   If an unsolicited Request

The NHRP Next Hop Resolution Reply packet is received,
   an Error Indication of type Invalid Next Hop Resolution Reply
   Received SHOULD be sent in response.

5.2.3 NHRP Registration Request

   The NHRP Registration Request is sent from a station to an NHS to
   notify the NHS of the station's NBMA information.  It packet has a Type code of 3. The Mandatory Part has 1. Its
mandatory part is coded as described in Section 5.2.0.1 and the following format:

          0                   1                   2                   3 message
specific meanings of the fields are as follows:

   Flags - The flags field is coded as follows:

      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 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Q|A|B|U|         unused        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Q
       Set if the station sending the Next Hop Resolution Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           unused              |    Register Holding Time      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Src Proto Len is a
       router;  clear if the it is a host.

     A
       This field holds bit is set in a Next Hop Resolution Request if only
       authoritative next hop information is desrired and is clear
       otherwise.  See the length in octets of NHRP Next Hop Resolution Reply section below
       for further details on the Source Protocol
     Address.

   Dst Proto Len "A" bit and its usage.

     B
       Unused (clear on transmit)

     U
       This field holds is the length Uniqueness bit. This bit aids in octets of the Destination Protocol
     Address. duplicate address
       detection.  When this bit is set in an NHRP Resolution Request ID
     A value which, when coupled with
       and one or more entries exist in the address NHS cache which meet the
       requirements of the source,
     provides a unique identifier for NHRP Resolution Request then only the information contained CIE in an
       the NHS's cache with this bit set will be returned.  Note that
       even if this bit was set at registration time, there may still be
       multiple CIEs that might fulfill the NHRP Registration Resolution Request packet.  This value is copied directly
     from
       because an NHRP Registration Request packet into entire subnet can be registered through use of the associated
     Registration Reply.  This value could also
       Prefix Length in the CIE and the address of interest might be sent across
       within such a virtual
     circuit (in SVC environments) to aid in matching subnet. If the NHRP
     transactions with virtual circuits (this use "uniqueness" bit is for further study).

   Register Holding Time
     The Register Holding Time field specifies set and the number of seconds for
       responding NHS has one or more cache entries which match the registered NBMA information is considered to be valid.
     Cached information SHALL be discarded when
       request but no such cache entry has the holding time
     expires.

   Source NBMA Address
     The Source NBMA address field is "uniqueness" bit set,
       then the address NHRP Resolution Reply returns with a NAK code of "13 -
       Binding Exists But Is Not Unique" and no CIE is included.  If a
       client wishes  to  receive  non- unique  Next  Hop Entries, then
       the source station
     which is sending client must have the "uniqueness" bit set to zero in its NHRP Registration
       Resolution Request.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which Note that when this bit is sending set in an NHRP
       Registration Request, only a single CIE may be specified in the
       NHRP Registration Request.  If Request and that CIE must have the
     field's length as Prefix
       Length field set to 0xFF.

   Zero or one CIEs (see Section 5.2.0.1) may be specified in ar$sstl an NHRP
   Next Hop Resolution Request.  If one is 0 specified then no storage is
     allocated for this address at all.

   Source Protocol Address
     This is that entry
   carries the protocol address of pertinent information for the station which is sending client sourcing the NHRP Registration
   Next Hop Resolution Request.

   Destination Protocol Address
     This is the protocol address  Usage of the NHS for which CIE in the source NBMA
     next hop information NHRP Next Hop
   Resolution Request is being registered.

   This packet described below:

     Prefix Length
       If a CIE is specified in the NHRP Next Hop Resolution Request
       then the Prefix Length field may be used to register a station's Protocol and NBMA
   addresses with its NHSs, as configured or known through conventional
   routing means.  This allows static configuration information to be
   reduced; qualify the NHSs need not widest
       acceptable prefix which may be configured with the identities of all
   of used to satisfy the stations that they serve.  If an NHS receives an NHRP
   Registration Request packet for a station that it does not serve and
   that packet has a Destination Protocol Address which is not Next Hop
       Resolution Request.  In the
   protocol address case of NHRP Next Hop Resolution
       Request/Reply, the NHS that is currently inspecting the packet
   then the NHS inspecting the packet MUST forward Prefix Length specifies the registration
   along equivalence class
       of addresses which match the routed path to first "Prefix Length" bit positions
       of the Destination Protocol Address.

   It is possible that a misconfigured station will attempt to register
   with the wrong NHS (i.e., one that cannot serve it due to policy
   constraints or routing state).  If this field is the case, the NHS MUST
   reply with a NAK-ed Registration Reply of type Can't Serve This
   Address.

   If an NHS cannot serve a station due set to a lack of resources, the NHS
       0x00 then this field MUST reply with a NAK-ed Registration Reply of type Registration
   Overflow.

   In order to keep be ignored.  If the registration entry from being discarded, "U" bit is set in
       the
   station common header then this field MUST re-send the NHRP Registration Request packet often
   enough be set to refresh 0xFF.

     Maximum Transmission Unit
       This field gives the registration, even in maximum transmission unit for the face source
       station.  A possible use of occasional
   packet loss. It is recommended that this field in the NHRP Registration Next Hop Resolution
       Request packet be sent at an interval equal to one-third of the Holding Time
   specified therein.

5.2.4 NHRP Registration Reply

   The NHRP Registration Reply is sent by an NHS for the Next Hop Resolution Requester to ask
       for a client in response
   to target MTU. In lieu of that client's NHRP Registration Request. If usage, the NAK Code field has
   anything CIE must be omitted.

     All other than 0 zero fields in it then the CIE MUST be ignored and SHOULD be set to 0.

5.2.2 NHRP Registration Next Hop Resolution Reply is
   a NAK otherwise the reply is an ACK.

The NHRP Registration Next Hop Resolution Reply packet has a Type code of 4. 2. CIEs
correspond to Next Hop Entries in an NHS's cache which match the
criteria in the NHRP Next Hop Resolution Request.  Its mandatory part has is
coded as described in Section 5.2.0.1.  The message specific meanings of
the following format:

          0                   1                   2                   3 fields are as follows:

   Flags - The flags field is coded as follows:

      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             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Request ID                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   NAK Code    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Q|A|B|U|         unused        |    Register Holding Time      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (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.

   Request ID
     A value which, when coupled with
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Q
       Copied from the address of Next Hop Resolution Request.  Set if the source,
     provides Next Hop
       Resolution Requester is a unique identifier for router;  clear if it is a host.

     A
       Set if the information contained next hop CIE in an
     NHRP Registration the Next Hop Resolution Reply packet.  This value is copied directly from
     an NHRP Registration Request packet into
       authoritative; clear if the associated NHRP
     Registration Reply.  This value could also be sent across a virtual
     circuit (in SVC environments) to aid in matching NHRP transactions
     with virtual circuits (this use Next Hop Resolution Reply is non-
       authoritative.

       When an NHS receives a Next Hop Resolution Request for further study).

   NAK Code
     If this field
       authoritative information for which it is set to zero then this packet contains the authoritative
       source, it MUST respond with a positively
     acknowledged NHRP Registration Reply.  If this field contains any
     other value then this contains an NHRP Registration Next Hop Resolution Reply NAK
       containing all and only those next hop CIEs which
     means that are contained
       in the internetworking layer to NBMA address binding was
     not stored at NHS's cache which both match the client's NHS.  Currently defined NAK Codes criteria of the Next Hop
       Resolution Request and are as
     follows:

       4 - Can't Serve This Address authoritative cache entries.  An NHS may refuse
       is an authoritative source for a Next Hop Resolution Request if
       the information in the NHS's cache matches the Next Hop
       Resolution Request criteria and that information was obtained
       through a NHRP Registration Request attempt for
         administrative reasons.  If so, the NHS MUST send or through synchronization
       with an NHS which obtained this information through a NHRP
       Registration Reply Request.  An authoritative cache entry is one which contains
       is obtained through a NAK code of 4.

       5 - NHRP Registration Overflow

         If Request or through
       synchronization with an NHS cannot serve which obtained this information
       through a station due NHRP Registration Request.

       An NHS obtains non-authoriative CIEs through promiscuous
       listening to NHRP packets other than NHRP Registrations which are
       directed at it.  A Next Hop Resolution Request which indicates a lack of resources,
         the NHS MUST reply with
       request for non-authoritative information should cause a NAKed NHRP Registration Next Hop
       Resolution Reply which contains a NAK code of 5.

   Register Holding Time
     The Register Holding Time field specifies the number of seconds for all entries in the replying NHS's
       cache (i.e., both authoritative and non-authoritative) which
       match the registered NBMA criteria specified in the request.

     B
       Set if the association between the destination and the next hop
       information is considered guaranteed to be valid.
     Cached information SHALL be discarded when stable for the lifetime of the
       information (the holding time
     expires.

   Source NBMA Address
     The Source NBMA address field time).  This is the address of the source station
     which sent case if the Next Hop Registration Request.

   Source NBMA SubAddress
     The Source
       protocol address identifies the destination (though it may be
       different in value than the Destination address if the
       destination system has multiple addresses) or if the destination
       is not connected directly to the NBMA subaddress field subnetwork but the egress
       router to that destination is guaranteed to be stable (such as
       when the subaddress of destination is immediately adjacent to the source
     station which sent egress router
       through a non-NBMA interface).  This information affects caching
       strategies (see section 6.2).

     U
       This is the Uniqueness bit. See the NHRP Resolution Request
       section above for details.  When this bit is set only, only one
       CIE is included since only one unique binding should exist in an
       NHS's cache.

   One or more CIEs are specified in the NHRP Next Hop Registration Request.  If Resolution Reply.
   Each CIE contains NHRP next hop information which the
     field's length as responding NHS
   has cached and which matches the parameters specified in ar$sstl is 0 then the NHRP
   Next Hop Resolution Request.  If no storage match is
     allocated for this address at all.

   Source Protocol Address
     This found by the NHS issuing
   the NHRP Next Hop Resolution Reply then a single CIE is enclosed with
   the a CIE Code set appropriately (see below) and all other fields
   MUST be ignored and SHOULD be set to 0.  In order to facilitate the protocol address
   use of the station which sent the NHRP
     Registration Request.

   Destination Protocol Address
     This is by minimal client implementations, the protocol address of first CIE MUST
   contain the NHS in which next hop with the client highest preference value so that such
   an implementation need parse only a single CIE.

     Code
       If this field is
     attempting set to register the client's NBMA information.

   This zero then this packet is used to register contains a station's Protocol and
       positively acknowledged NHRP Resolution Reply.  If this field
       contains any other value then this message contains an NHRP
       Resolution Reply NAK which means that an appropriate
       internetworking layer to NBMA
   addresses address binding was not available
       in the responding NHS's cache.  If NHRP Resolution Reply contains
       a Client Information Entry with its neighboring NHSs, a NAK Code other than 0 then it
       MUST NOT contain any other CIE.  Currently defined NAK Codes are
       as configured or known through
   conventional routing means. follows:

       12 - No Internetworking Layer Address to NBMA Address Binding
       Exists

         This allows static configuration
   information code states that there were absolutely no internetworking
         layer address to be reduced; NBMA address bindings found in the NHSs need not be configured with responding
         NHS's cache.

       13 - Binding Exists But Is Not Unique

         This code states that there were one or more internetworking
         layer address to NBMA address bindings found in the
   identities of all responding
         NHS's cache, however none of them had the stations that they serve. If an NHS receives
   an uniqueness bit set.

     Prefix Length
       In the case of NHRP Registration Request packet for a station that it does not
   serve and that packet has a Next Hop Resolution Reply, the Prefix Length
       specifies the equivalence class of addresses which match the
       first "Prefix Length" bit positions of the Destination Protocol Address which
       Address.

     Holding Time
       The Holding Time specified in a CIE of an NHRP Resolution Reply
       is not the protocol address amount of time remaining before the NHS that expiration of the
       client information which is currently inspecting cached at the
   packet then replying NHS.  It is
       not the NHS inspecting value which was registered by the packet MUST forward client.

     The remainder of the
   registration along fields for the routed path to CIE for each next hop are
     filled out as they were defined when the Destination Protocol
   Address.

   It is possible that a misconfigured station will attempt to send a
   Next Hop Registration Request to next hop was registered
     with the wrong responding NHS (i.e., (or one that cannot
   serve it due to policy constraints or routing state).  If this is of the
   case, responding NHS's
     synchronized servers) via the NHS MUST reply with a NAK-ed NHRP Registration Reply of
   type Can't Serve This Address.

   If an NHS cannot serve a station due Request.

   Load-splitting may be performed when more than one Client Information
   Entry is returned to a lack of resources, requester when equal preference values are
   specified.  Also, the NHS
   MUST reply with a NAK-ed NHRP Registration Reply alternative addresses may be used in case of type Registration
   Overflow.

   In order to keep the client's registration entry
   connectivity failure in the client's NHS
   from being timed out, the station MUST re-send NBMA subnetwork (such as a failed call
   attempt in connection-oriented NBMA subnetworks).

   Any extensions present in the NHRP Registration Next Hop Resolution Request packet often enough to refresh the registration entry, even MUST
   be present in the face of occasional packet loss. It is recommended that NHRP Next Hop Resolution Reply even if the
   extension is non-Compulsory.

   If an unsolicited NHRP Registration Request Next Hop Resolution Reply packet be sent at is received,
   an interval equal to
   one-third Error Indication of the Holding Time specified therein.

5.2.5 type Invalid Next Hop Resolution Reply
   Received SHOULD be sent in response.

5.2.3 NHRP Purge Registration Request

   The NHRP Purge Registration Request packet is sent in order to invalidate cached
   information in from a station.  The NHRP Purge Request packet station to an NHS to
   notify the NHS of the station's NBMA information.  It has a type Type code
   of 5. 3. Each CIE corresponds to Next Hop information which is to be
   cached at an NHS.  The Mandatory Part has mandatory part of an NHRP Registration Request
   is coded as described in Section 5.2.0.1.  The message specific
   meanings of the following format:

          0                   1                   2                   3 fields are as follows:

   Flags - The flags field is coded as follows:

      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 |Trgt Proto Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|         unused              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Target Protocol Address (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.

   Trgt Proto Len
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     U
       This field holds the length in octets of the Target Protocol
     Address.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which is sending the Uniqueness bit. When set in an NHRP Purge Request.

   Source NBMA SubAddress
     The Source NBMA subaddress field is Registration
       Request, this bit indicates that the address registration of the source
     station which is sending the NHRP Purge Request.  If its length as
     specified in ar$sstl is 0 then no storage is allocated for this
     address at all.

   Source Protocol Address
     The protocol
       address of the station which is sending unique within the NHRP Purge Request.

   Destination Protocol Address
     The address confines of the station that will set of synchronized
       NHSs.  This "uniqueness" qualifier MUST be receiving stored in the NHRP Purge
     Request.

   Target Protocol Address
     The address which is NHS/NHC
       cache.  Any attempt to be purged from register a binding between the receiver's database.

   An NHRP Purge Request packet is sent from protocol
       address and an NHS to a station to
   cause it to delete previously cached information.  This is done NBMA address when
   the information may this bit is set MUST be no longer valid (typically when rejected
       with a Code of "14 - Unique Internetworking Layer Address Already
       Registered" if the replying NHS already has
   previously provided next hop information for a station that is not
   directly connected to cache entry for the NBMA subnetwork,
       protocol address and the egress point to
   that station may have changed).

   An NHRP Purge Request packet may also be sent from a client to an NHS
   with which cache entry has the client had previously registered.  This allows for a
   client to invalidate it's "uniqueness" bit
       set.  A registration with NHRP before it would
   otherwise expire via the holding timer.

   The station sending the NHRP Purge Request MAY periodically
   retransmit of a CIE's information is rejected when the NHRP Purge Request until either NHRP Purge Request
       CIE is
   acknowledged or until returned with the Code field set to anything other than
       0x00.  See the holding time description of the information being
   purged has expired.  Retransmission strategies are uniqueness bit in NHRP
       Resolution Request section above for further
   investigation. details.  When a station receives an NHRP Purge Request, it MUST discard any
   previously cached information that matches the Target Protocol
   Address.

   An NHRP Purge Reply MUST this
       bit is set only, only one CIE MAY be returned for included in the NHRP Purge
       Registration Request.

   Request even
   if the station does not have a matching cache entry.

   If ID
     The request ID has the station wishes to reestablish communication with same meaning as described in Section
     5.2.0.1.  However, the
   destination shortly after receiving an request ID for NHRP Purge Request, it should
   make an authoritative Next Hop Resolution Request Registrations which is
     maintained at each client MUST be kept in order to avoid
   any stale cache entries non-volatile memory so
     that might when a client crashes and reregisters there will be present no
     inconsistency in intermediate NHSs
   (See section 6.2.2.).  It is recommended that authoritative Next Hop
   Resolution Requests the NHS's database.  In order to reduce the
     overhead associated with updating non-volatile memory, the actual
     updating need not be made done with every increment of the Request ID
     but could be done, for example, every 50 or 100 increments.  In
     this scenario, when a client crashes and reregisters it knows to
     add 100 to the duration value of the holding time of Request ID in the non-volatile memory
     before using the Request ID for subsequent registrations.

   One or more CIEs are specified in the old information.

5.2.6 NHRP Purge Reply

   The NHRP Purge Reply packet Registration Request.
   Each CIE contains next hop information which a client is sent in order attempting
   to assure register with its servers.  Generally, all fields in CIEs enclosed
   in NHRP Registration Requests are coded as described in Section
   5.2.0.1.  However, if a station is only registering itself with the sender of
   an
   NHRP Purge Registration Request then it MAY code the Cli Addr T/L, Cli
   SAddr T/L, and Cli Proto Len as zero which signifies that all cached information of the specified
   type has been purged client
   address information is to be taken from the station sending source information in the reply.  The NHRP
   Purge packet has
   common header (see Section 5.2.0.1).  Below, further clarification is
   given for some fields in a type code of 6.  The Mandatory Part has the
   following 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 |Trgt Proto Len |    unused     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Source NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source NBMA Subaddress (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Destination  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Target Protocol Address (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Src Proto Len
     This field holds the length CIE in octets of the Source Protocol
     Address.

   Dst Proto Len context of a NHRP Registration
   Request.

     Code
       This field holds the length is set to 0x00 in octets of the Destination Protocol
     Address.

   Trgt Proto Len NHRP Registration Requests.

     Prefix Length

       This field holds the length may be used in octets of a NHRP Registration Request to register
       equivalence information for the Target Client Protocol
     Address.

   Source NBMA Address
     The Source NBMA address field is specified
       in the address CIE of an NHRP Registration Request In the source station
     which sent the case of NHRP Purge Request.

   Source NBMA SubAddress
     The Source NBMA subaddress field is
       Registration Request, the address of Prefix Length specifies the source
     station equivalence
       class of addresses which sent match the NHRP Purge Request. first "Prefix Length" bit
       positions of the Client Protocol Address.  If its length as
     specified in ar$sstl this field is 0 set
       to 0x00 then this field MUST be ignored and no storage equivalence
       information is allocated for this
     address at all.

   Source assumed (i.e., only Client Protocol Address
     The address of the station which sent is
       bound to the NHRP Purge Request.

   Destination Protocol Address
     The address of NBMA information).  If the station which "U" bit is sending set in the NHRP Purge Reply.

   Target Protocol Address
     The address which
       common header then this field MUST be set to 0xFF.

   This packet is used to register a station's NHRP information with its
   NHSs, as configured or known through conventional routing means.
   NHSs may also be purged from configured with the receiver's database.

   An identities of stations that they
   serve.  If an NHS receives an NHRP Purge Registration Request packet is sent from which
   has the Destination Protocol Address field set to an address other
   than the NHS's own protocol address then the NHS to MUST forward the
   packet along the routed path toward the Destination Protocol Address.

   It is possible that a misconfigured station will attempt to
   cause it to delete previously cached information.  This is done when
   the information may be no longer valid (typically when register
   with the wrong NHS has
   previously provided next hop information for a station (i.e., one that is not
   directly connected cannot serve it due to policy
   constraints or routing state).  If this is the NBMA subnetwork, and case, the egress point to
   that station may have changed).

   An NHRP Purge Request packet may also be sent from NHS MUST
   reply with a client to NAK-ed Registration Reply of type Can't Serve This
   Address.

   If an NHS
   with which cannot serve a station due to a lack of resources, the client had previously registered.  This allows for NHS
   MUST reply with a
   client NAK-ed Registration Reply of type Registration
   Overflow.

   In order to invalidate it's keep the registration with NHRP before it would
   otherwise expire via entry from being discarded, the holding timer.

   The
   station sending MUST re-send the NHRP Purge Registration Request MAY periodically
   retransmit packet often
   enough to refresh the NHRP Purge Request until it is acknowledged, or until registration, even in the holding time face of the information being purged has expired.
   Retransmission strategies are for further investigation.

   When a station receives an NHRP Purge Request, it MUST discard any
   previously cached information occasional
   packet loss. It is recommended that matches the Target Protocol
   Address.

   An NHRP Purge Reply MUST Registration Request
   packet be returned as a result of receiving sent at an NHRP
   Purge Request even if the station does not have a matching cache
   entry.

   If the station wishes interval equal to reestablish communication with one-third of the
   destination shortly after receiving an Holding Time
   specified therein.

5.2.4 NHRP Purge Request, it should
   make Registration Reply

   The NHRP Registration Reply is sent by an authoritative Next Hop Resolution Request in order NHS to avoid
   any stale cache entries that might be present a client in intermediate NHSs.
   (See section 6.2.2.)  It is recommended response
   to that authoritative Next Hop
   Resolution Requests be made for the duration of client's NHRP Registration Request. If the holding time Code field of a
   CIE in the old information.

5.2.7 NHRP Error Indication

   The Registration Reply has anything other than 0 zero in
   it then the NHRP Error Indication Registration Reply is used to convey error indications to a NAK otherwise the
   sender of reply is
   an ACK.  The NHRP packet.  It Registration Reply has a type Type code of 6.  The Mandatory
   Part has 4.

   An NHRP Registration Reply is formed from an NHRP Registration
   Request by changing the following 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 type code to 4, updating the CIE 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 field,
   and filling in error (variable length)      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Src Proto Len
     This field holds the length appropriate extensions if they exist.  The message
   specific meanings of the fields are as follows:

   Attempts to register the information in octets the CIEs of an NHRP
   Registration Request may fail for various reasons.  If this is the Source Protocol
     Address.

   Dst Proto Len
     This field holds
   case then each failed attempt to register the length information in octets a CIE of
   an NHRP Registration Request is logged in the Destination Protocol
     Address.

   Error associated NHRP
   Registration Reply by setting the CIE Code
     An error code indicating field to the type of appropriate
   error detected, chosen from
     the following list:

       1 code as shown below:

     CIE Code

       0 - Unrecognized Extension

         When the Compulsory bit of an extension Successful Registration

         The information in NHRP packet is set, the CIE was sucessfully registered with the
         NHS.

       4 - Can't Serve This Address

         An NHS may refuse an NHRP packet cannot be processed unless Registration Request attempt for
         administrative reasons (due to policy constraints or routing
         state).  If so, the extension has
         been processed.  The responder NHS MUST return send an NHRP Error
         Indication Registration Reply
         which contains a NAK code of type Unrecognized Extension if it is incapable 4.

       5 - Registration Overflow

         If an NHS cannot serve a station due to a lack of
         processing resources,
         the extension.  However, if a transit NHS (one MUST reply with a NAKed NHRP Registration Reply which
         is not going to generate
         contains a reply) detects an unrecognized
         extension, it SHALL ignore the extension.

       2 NAK code of 5.

       14 - Subnetwork ID Mismatch

         This error occurs when the current station receives an NHRP
         packet whose Unique Internetworking Layer Address Already Registered
         If a client tries to register a protocol address to NBMA subnetwork identifier matches none of the
         locally known identifiers for
         address binding with the NBMA subnetwork uniqueness bit on which and the
         packet is received.

       3 - NHRP Loop Detected
         A Loop Detected error is generated when it is determined protocol
         address already exists in the NHS's cache then if that
         an NHRP packet cache
         entry also has the uniqueness bit on then this NAK Code is being forwarded
         returned in a loop.

       8 - NHRP SDU Size Exceeded

         If the SDU size of CIE in the NHRP packet exceeds Registration Reply.

   Due to the maximum SDU size possible existence of the NBMA network, this error is returned.

       9 - Invalid Extension

         If an NHS finds asymmetric routing, an extension in a packet which is inappropriate
         for NHRP
   Registration Reply may not be able to merely follow the packet type, an error is sent routed path
   back to the sender with
         Invalid Extension as source protocol address specified in the code.

       10- Invalid Next Hop Resolution Reply Received

         If common header of
   the NHRP Registration Reply.  As a client receives result, there MUST exist a Next Hop Resolution direct
   NBMA level connection between the client and its NHS on which to send
   the NHRP Registration Reply for before NHRP Registration Reply may be
   returned to the client.  If such a Next Hop
         Resolution Request which it believes it did connection does not make exist then an
         error packet is sent the
   NHS must setup such a connection to he client by using the station making source
   NBMA information supplied in the reply with an
         error code common header of Invalid Reply Received.

   Error Offset
     The offset in octets into the NHRP packet, starting at the
   Registration Request.

5.2.5 NHRP
     Fixed Header, at which the error was detected.

   Source NBMA Address Purge Request

   The Source NBMA address field NHRP Purge Request packet is the address sent in order to invalidate cached
   information in a station.  The NHRP Purge Request packet has a type
   code of the station which
     observed the error.

   Source NBMA SubAddress 5.  The Source NBMA subaddress field mandatory part of an NHRP Purge Request is the address coded as
   described in Section 5.2.0.1.  The message specific meanings of the station
     which observed the error.  If the field's length
   fields are as specified in
     ar$sstl follows:

   Flags - The flags field is coded as follows:

      0 then no storage is allocated for                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |N|         unused              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     N
       When set, this address at all.

   Source Protocol Address
     This is bit tells the protocol address 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 which issued where that station is identified in the Error
     packet.

   Destination Source Protocol
       Address
     This is the protocol address of the station which sent the packet
     which was found to be in error.

   An NHRP Error Indication then that packet SHALL NEVER must be generated ignored.

   One or more CIEs are specified in response
   to another NHRP Error Indication packet.  When an NHRP Error
   Indication packet is generated, the offending NHRP packet SHALL Purge Request.  Each CIE
   contains next hop information which is to be
   discarded.  In no case should more than one purged from an NHS/NHC
   cache.  Generally, all fields in CIEs enclosed in NHRP Error Indication
   packet be generated Purge Requests
   are coded as described in Section 5.2.0.1.  Below, further
   clarification is given for some fields in a single NHRP packet.

   If an NHS sees its own Protocol and NBMA Addresses CIE in the Source NBMA
   and Source Protocol address fields context 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 Purge Request.

     Code
       This field is set to an 0x00 in NHRP Error Indication.

5.3  Extensions Part Purge Requests.

     Prefix Length

       In the following, unless otherwise stated explicitly, case of NHRP Purge Requests, the term
   "request" refers generically to any Prefix Length specifies
       the equivalence class of addresses which match the first "Prefix
       Length" bit positions of the NHRP packet types Client Protocol Address specified in
       the CIE.  All next hop information which
   are "requests".  Also, unless otherwise stated explicitly, contains a protocol
       address which matches an element of this equivalence class is to
       be purged from the term
   "reply" refers generically receivers cache.  If this field is set to any 0x00
       then this field MUST be ignored and no equivalence information is
       assumed.

     The Maximum Transmission Unit and Preference fields of the NHRP packet types which CIE are
   "replies".
     coded as zero.  The Extensions Part, if present, carries one or more extensions in
   {Type, Length, Value} triplets.  Extensions are only present Holding Time should be coded as zero but there
     may be some utility in supplying a
   "reply" if they were present in "short" holding time to be
     applied to the corresponding "request";
   therefore, minimal NHRP station implementations matching next hop information before that do not act as an
   NHS
     information would be purged; this usage is for further study. The
     Client Protocol Address field and do not transmit extensions need not the Cli Proto Len field MUST be able to receive
   extensions.  An implementation that
     filled in.  The Client Protocol Address is incapable of processing
   extensions SHALL return an NHRP Error Indication of type Unrecognized
   Extension when it receives an NHRP packet containing extensions.

   Extensions have filled in with the following 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |C|u|        Type               |        Length                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Value...                              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C
     "Compulsory."  If clear, and
     protocol address to be purged from the receiving station's cache
     while the NHS does not recognize Cli Proto Len is set the type
     code, length of the extension may safely purged client's
     protocol address.  All remaining fields in the CIE MAY be ignored.  If set, and set to
     zero although the NHS
     does not recognize client NBMA information (and associated length
     fields) MAY be specified to narrow the type code, scope of the NHRP "request" Purge
     Request if requester desires.  However, the receiver of an NHRP
     Purge Request may choose to ignore the Client NBMA information if
     it is considered supplied.

   An NHRP Purge Request packet is sent from an NHS to be in error.  (See below for details.)

   u
     Unused and must be set a station to zero.

   Type
     The extension type code (see below).  The extension type
   cause it to delete previously cached information.  This is not
     qualified by done when
   the Compulsory bit, but information may be no longer valid (typically when the NHS has
   previously provided next hop information for a station that is orthogonal not
   directly connected to it.

   Length
     The length in octets of the value (not including the Type NBMA subnetwork, and
     Length fields;  a null extension will the egress point to
   that station may have only changed).

   An NHRP Purge Request packet may also be sent from a client to an extension header
     and NHS
   with which the client had previously registered.  This allows for a length of zero).

   When extensions exist,
   client to invalidate its registration with NHRP before it would
   otherwise expire via the extensions list holding timer.

   The station sending the NHRP Purge Request MAY periodically
   retransmit the NHRP Purge Request until either NHRP Purge Request is terminated by
   acknowledged or until the holding time of the Null
   TLV, having Type = 0 and Length = 0.

   Extensions may occur in any order, but any particular extension type
   (except information being
   purged has expired.  Retransmission strategies for the vendor-private extension) may occur only once in an NHRP packet.  The vendor-private extension may occur multiple times
   in Purge
   Requests are a packet local matter.

   When a station receives an NHRP Purge Request, it MUST discard any
   previously cached information that matches the information in order to allow for extensions which do not share the
   same vendor ID to
   CIEs.

   An NHRP Purge Reply MUST be represented.

   The Compulsory bit provides returned for a means to add to the extension set.
   If NHRP Purge Request even
   if the station does not have a matching cache entry assuming that the
   "N" bit is set, off in the NHRP message cannot be properly processed by Purge Request.

   If the station responding wishes to reestablish communication with the message (e.g., the station that would
   issue a
   destination shortly after receiving an NHRP Purge Request, it should
   make an authoritative Next Hop Resolution Reply Request in response order to a Next Hop
   Resolution Request) without processing the extension.  As a result,
   the responder MUST return an NHRP Error Indication of type
   Unrecognized Extension.  If the Compulsory bit is clear then the
   extension can be safely ignored; however, if an ignored extension is
   in a "request" then it MUST avoid
   any stale cache entries that might be returned, unchanged, present in the
   corresponding "reply" packet type.

   If a transit NHS (one which intermediate NHSs
   (See section 6.2.2.).  It is not going to generate a "reply")
   detects an unrecognized extension, it SHALL ignore the extension.  If recommended that authoritative Next Hop
   Resolution Requests be made for the Compulsory bit is set, duration of the transit NHS MUST NOT cache holding time of
   the
   information contained old information.

5.2.6 NHRP Purge Reply

   The NHRP Purge Reply packet is sent in order to assure the packet and MUST NOT identify itself as sender of
   an egress router (in NHRP Purge Request that all cached information of the Forward Record or Reverse Record
   extensions).  Effectively, this means, if a transit NHS encounters an
   extension which it cannot process and which specified
   type has been purged from the Compulsory bit
   set then that NHS MUST NOT participate in any way in station sending the protocol
   exchange other than acting as a forwarding agent.

5.3.0 reply.  The End Of Extensions

    Compulsory = 1
    Type = 0
    Length = 0

   When extensions exist, the extensions list NHRP
   Purge Reply has a type code of 6.

   An NHRP Purge Reply is terminated formed from an NHRP Purge Request by merely
   changing the End
   Of Extensions/Null TLV.

5.3.1  Destination Prefix Length

    Compulsory = 0
    Type = 1
    Length = 1

   This extension type code in the request to 6.  The packet is used then
   returned to indicate that the information carried requester after filling in an the appropriate extensions
   if they exist.

5.2.7  NHRP packet pertains Error Indication

   The NHRP Error Indication is used to an equivalence class convey error indications to the
   sender of internetwork layer
   addresses rather than just an NHRP packet.  It has a single internetwork layer address
   specified. All internetwork layer addresses that match the first
   "Prefix Length" bit positions for the specific internetwork layer
   address are included in type code of 7.  The Mandatory
   Part has the equivalence class. following 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Prefix Length 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)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the case of an Next Hop Resolution Request, if equivalence
   information is desired from the Next Hop Resolution Reply then the       Destination Prefix Length extension is included  Protocol Address (variable length)         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Contents of NHRP Packet in the Next Hop
   Resolution Request and the Prefix Length value is coded as 0xffff.
   For the Next Hop Resolution Reply, the Prefix Length is set to error (variable length)      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Src Proto Len
     This field holds the length in octets of the prefix Source Protocol
     Address.

   Dst Proto Len
     This field holds the length in octets of the Next Hop Destination Protocol Address present in
     Address.

   Error Code
     An error code indicating the
   mandatory part type of error detected, chosen from
     the packet.

   In following list:

       1 - Unrecognized Extension

         When the case Compulsory bit of an extension in NHRP Registration Request, if equivalence
   information packet is desired to set,
         the NHRP packet cannot be registered then processed unless the Destination Prefix
   Length extension is included in the has
         been processed.  The responder MUST return an NHRP Registration Request with Error
         Indication of type Unrecognized Extension if it is incapable of
         processing the Prefix Length value set extension.  However, if a transit NHS (one which
         is not going to generate a reply) detects an unrecognized
         extension, it SHALL ignore the length of extension.

       2 - Subnetwork ID Mismatch

         This error occurs when the prefix current station receives an NHRP
         packet whose NBMA subnetwork identifier matches none of the
   equivalence information
         locally known identifiers for the Source Protocol Address.  In Next Hop
   Registration Reply, NBMA subnetwork on which the Destination Prefix Length extension
         packet is merely
   copied unchanged.

   In the case of received.

       3 - NHRP Loop Detected

         A Loop Detected error is generated when it is determined that
         an Next Hop Purge Request, if equivalence information NHRP packet is desired then being forwarded in a loop.

       6 - Protocol Address Unreachable

         This error occurs when a packet it moving along the Prefix Length value is set to routed path
         and it reaches a point such that the length 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
   prefix SDU size of the Target Protocol Address which represents NHRP packet exceeds the
   equivalence information to be purged.  In Next Hop Purge Reply, MTU size of the
   Destination Prefix Length extension is merely copied unchanged.

5.3.2
         NBMA Subnetwork ID network then this error is returned.

       9 - Invalid Extension

    Compulsory = 1
    Type = 2
    Length = variable
   This

         If an NHS finds an extension in a packet which is used to carry one or more identifiers inappropriate
         for the NBMA
   subnetwork.  This can be used packet type, an error is sent back to the sender with
         Invalid Extension as the code.

       10- Invalid Next Hop Resolution Reply Received

         If a client receives a Next Hop Resolution Reply for a validity check to ensure that Next Hop
         Resolution Request which it believes it did not make then an
   NHRP
         error packet does not leave a particular NBMA subnetwork.  The
   extension is placed in a "request" packet sent to the station making the reply with an ID value
         error code of zero. Invalid Reply Received.

       11- Authentication Failure

         If a received packet fails an authentication test then this
         error is returned.

       14- Hop Count Exceeded

         The first NHS along hop count which was specified in the routed path fills Fixed Header of an
         NHRP message has been exceeded.

   Error Offset
     The offset in octets into the field with NHRP packet, starting at the
   identifier(s) for NHRP
     Fixed Header, at which the error was detected.

   Source NBMA subnetwork.

   Multiple NBMA Subnetwork IDs may be used as a transition mechanism
   while NBMA Subnetworks are being split or merged.

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    NBMA Subnetwork ID                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...

   Each identifier consists of a 32 bit globally unique value assigned
   to the Address
     The Source NBMA subnetwork.  This value may be chosen from the
   internetworking layer address space administered by field is the operators address of the station which
     observed the error.

   Source NBMA subnetwork if such an address can fit into a 32 bit field.
   This value SubAddress
     The Source NBMA subaddress field is used for identification only, not for routing or any
   other purpose.

   Each NHS processing a "request" or "reply" SHALL verify these values. the address of the station
     which observed the error.  If the value field's length as specified in
     ar$sstl is not zero and none 0 then no storage is allocated for this address at all.

   Source Protocol Address
     This is the protocol address of the values matches station which issued the NHS's
   NBMA Subnetwork ID, Error
     packet.

   Destination Protocol Address
     This is the NHS protocol address of the station which sent the packet
     which was found to be in error.

   An NHRP Error Indication packet SHALL return NEVER be generated in response
   to another NHRP Error Indication packet.  When an NHRP Error
   Indication to
   the entity identified in Source Protocol Address if the packet type is generated, the offending NHRP packet SHALL be
   discarded.  In no case should more than one NHRP Error Indication
   packet be generated for a "request" single NHRP packet.

   If an NHS sees its own Protocol and to NBMA Addresses in the Destination Source NBMA
   and Source Protocol Address if the packet
   type is address fields of a "reply".  The error indicated in this case is "Subnetwork
   ID Mismatch".  The transiting NHRP Error
   Indication packet is discarded by then the station sending NHS will quietly drop the packet and do
   nothing (this scenario would occur when the NHRP Error Indication.

   When Indication
   packet was itself in a loop).

   Note that no extensions may be added to an NHS is building NHRP Error Indication.

5.3  Extensions Part

   The Extensions Part, if present, carries one or more extensions in
   {Type, Length, Value} triplets.  Extensions are only present in a
   "reply" and the NBMA Subnetwork ID
   extension is if they were present in the correspond "request" then the NBMA
   Subnetwork ID extension SHALL corresponding "request";
   therefore, minimal NHRP client implementations which do not also act
   as an NHS and do not transmit extensions need not be copied from the "request" able to the
   "reply".

5.3.3  Responder Address Extension

    Compulsory = 1
    Type = 3
    Length = 4

   This extension receive
   extensions. The previous statement is used not intended to determine preclude the address
   creation of the NHS-only extensions which might be added to and removed
   from NHRP
   responder; i.e., packets by the entity same NHS; such extensions MUST not be
   propagated to clients.  An implementation that generates the appropriate "reply"
   packet for a given "request" packet.  In the case is incapable of
   processing extensions SHALL return an Next Hop
   Resolution Request, the station responding may be different (in the
   case of cached replies) than the system identified in the Next Hop
   field NHRP Error Indication of the Next Hop Resolution Reply.  Further, this extension may
   aid in detecting loops in the type
   Unrecognized Extension when it receives an NHRP forwarding path. packet containing
   extensions.

   Extensions have the following 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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |C|u|        Type               |           unused              |         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Res Addr T/L  | Res SAddr T/L| Res Proto Len |     unused    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Responder NBMA Address (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Responder NBMA Subaddress (variable length)        Length                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Responder Protocol Address (variable length)                         Value...                              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Holding Time
     The Holding Time field specifies the number of seconds for which

   C
     "Compulsory."  If clear, and the NBMA information is considered to be valid.  Cached information
     SHALL be discarded when NHS does not recognize the holding time expires.

   Res Addr T/L
     Type & length of type
     code, the responder NHS's NBMA address interpreted in extension may safely be ignored.  If set, and the context of NHS
     does not recognize the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0003 for ATM).  When type code, the address length is
     specified as 0 no storage NHRP "request" is allocated considered
     to be in error.  (See below for the address.

   Res SAddr T/L details.)

   u
     Unused and must be set to zero.

   Type &
     The extension type code (see below).  The extension type is not
     qualified by the Compulsory bit, but is orthogonal to it.

   Length
     The length of responder NHS's NBMA subaddress interpreted in the
     context octets of the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0015 for ATM makes value (not including the address an E.164 Type and the
     subaddress an ATM Forum NSAP address).  When an NBMA technology has
     no concept of
     Length fields;  a subaddress, the subaddress is always null with extension will have only an extension header
     and a length of 0. zero).

   When extensions exist, the address length extensions list is specified as terminated by the Null
   TLV, having Type = 0 no storage
     is allocated and Length = 0.

   Extensions may occur in any order, but any particular extension type
   (except for the address.

   Res Proto Len
     This field holds the length vendor-private extension) may occur only once in octets of responding NHS's Protocol
     Address.

   Responder NBMA Address
     This is the NBMA address of the responding NHS.

   Responder NBMA SubAddress
     This is an
   NHRP packet.  The vendor-private extension may occur multiple times
   in a packet in order to allow for extensions which do not share the NBMA subaddress of
   same vendor ID to be represented.

   The Compulsory bit provides for a means to add to the responding NHS.

   Responder Protocol Address
     This extension set.
   If the bit is set, the Protocol Address of NHRP message cannot be properly processed by
   the station responding NHS.

   If a "requester" desires this information, to the "requester" SHALL
   include this extension with a value of zero.  Note that this implies message (e.g., the station that no storage is allocated for would
   issue a Next Hop Resolution Reply in response to a Next Hop
   Resolution Request) without processing the Holding Time and Type/Length
   fields until extension.  As a result,
   the "Value" portion responder MUST return an NHRP Error Indication of type
   Unrecognized Extension.  If the extension Compulsory bit is filled out.

   If clear then the
   extension can be safely ignored; however, if an NHS ignored extension is generating
   in a "request" then it MUST be returned, unchanged, in the
   corresponding "reply" packet in response type.

   If a transit NHS (one which is not going to generate a "request"
   containing this "reply")
   detects an unrecognized extension, the NHS it SHALL include this extension,
   containing its protocol address in ignore the "reply". extension.  If an
   the Compulsory bit is set, the transit NHS has more
   than one protocol address, it SHALL use MUST NOT cache the same protocol address
   consistently
   information contained in all of the Responder Address, Forward NHS Record, packet and MUST NOT identify itself as
   an egress router (in the Forward Record or Reverse NHS Record extensions.  The choice of which of several
   protocol address to include in
   extensions).  Effectively, this extension is a local matter.

   If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS
   contains means, if a protocol address of that transit NHS in encounters an
   extension which it cannot process and which has the Responder Address
   Extension Compulsory bit
   set then that NHS SHALL generate an NHRP Error Indication of
   type "NHRP Loop Detected" and discard MUST NOT participate in any way in the Next Hop Resolution Reply.

   If an protocol
   exchange other than acting as a forwarding agent.

   Use of NHRP Next Hop Resolution Reply packet is being returned by an
   intermediate NHS based on cached data, it SHALL place its own address
   in this extension (differentiating it from Types in the address range 8192 to 16383 are reserved
   for research or use in other protocol development and will be
   administered by IANA.

5.3.0  The End Of Extensions

    Compulsory = 1
    Type = 0
    Length = 0

   When extensions exist, the Next
   Hop field).

5.3.4  NHRP Forward Transit NHS Record extensions list is terminated by the End
   Of Extensions/Null TLV.

5.3.1  Extension with Type 1 not assigned.

5.3.2  NBMA Subnetwork ID Extension

    Compulsory = 1
    Type = 4 2
    Length = variable

   The NHRP Forward Transit NHS record contains a list of transit NHSs
   through which a "request" has traversed.  Each NHS SHALL append to
   the extension a Forward Transit NHS element (as specified below)
   containing its Protocol address The

   This extension length field and the
   ar$chksum fields SHALL be adjusted appropriately.

   The responding NHS, as described in Section 5.3.3, SHALL NOT update
   this extension.

   In addition, NHSs that are willing is used to act as egress routers carry one or more identifiers for
   packets from the source NBMA
   subnetwork.  This can be used as a validity check to the destination SHALL include information
   about their ensure that an
   NHRP packet does not leave a particular NBMA Address. subnetwork.  The Forward Transit
   extension is placed in a "request" packet with an ID value of zero.
   The first NHS element has along the following form: routed path fills in the field with the
   identifier(s) for the NBMA subnetwork.

   Multiple NBMA Subnetwork IDs may be used as a transition mechanism
   while NBMA Subnetworks are being split or merged.

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           unused              |         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NHS Addr T/L  | NHS SAddr T/L| NHS Proto Len |     unused    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              NHS NBMA Address (variable length)               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              NHS                    NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             NHS Protocol Address (variable length) Subnetwork ID                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information is considered to be valid.  Cached information
     SHALL be discarded when the holding time expires.

   NHS Addr T/L
     Type & length of the transit NHS's NBMA address interpreted in the
     context of the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0003 for ATM).  When the address length is
     specified as 0 no storage is allocated for the address.

   NHS SAddr T/L
     Type & length of the transit NHS's NBMA subaddress 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
                                     ...

   Each identifier consists 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.

   NHS Proto Len
     This field holds the length in octets of the transit NHS's Protocol
     Address.

   NHS 32 bit globally unique value assigned
   to the NBMA Address subnetwork.  This is value may be chosen from the NBMA
   internetworking layer address space administered by the operators of
   the transit NHS.

   NHS NBMA SubAddress subnetwork if such an address can fit into a 32 bit field.
   This value is the NBMA subaddress of the transit NHS. used for identification only, not for routing or any
   other purpose.

   Each NHS Protocol Address
     This is the Protocol Address of the transit NHS.

   If processing a "requester" wishes to obtain this information, it "request" or "reply" SHALL include
   this extension with a length of zero.  Note that this implies that no
   storage is allocated for verify these values.
   If the Holding Time value is not zero and Type/Length fields
   until the "Value" portion none of the extension is filled out.

   If an NHS has more than one Protocol address, it SHALL use values matches the same
   Protocol address consistently in all of NHS's
   NBMA Subnetwork ID, the Responder Address,
   Forward NHS Record, and Reverse NHS Record extensions.  The choice of
   which of several Protocol addresses SHALL return an NHRP Error Indication to include
   the entity identified in this extension Source Protocol Address if the packet type
   is a
   local matter.

   If a "request" that is being forwarded by an NHS contains and to the Destination Protocol Address of that NHS if the packet
   type is a "reply".  The error indicated in one of this case is "Subnetwork
   ID Mismatch".  The packet is discarded by the Forward Transit NHS
   elements then station sending the NHS SHALL generate an
   NHRP Error Indication of type
   "NHRP Loop Detected" Indication.

   When an NHS is building a "reply" and discard the "request".

5.3.5  NHRP Reverse Transit NHS Record NBMA Subnetwork ID
   extension is present in the correspond "request" then the NBMA
   Subnetwork ID extension SHALL be copied from the "request" to the
   "reply".

5.3.3  Responder Address Extension

    Compulsory = 1
    Type = 5 3
    Length = variable

   The NHRP Reverse Transit NHS record contains a list

   This extension is used to determine the address of transit NHSs
   through which a the NHRP
   responder; i.e., the entity that generates the appropriate "reply" has traversed.  Each NHS SHALL append
   packet for a
   Reverse Transit NHS element (as specified below) containing its
   Protocol address to this extension.  The extension length field and
   ar$chksum SHALL be adjusted appropriately.

   The given "request" packet.  In the case of an Next Hop
   Resolution Request, the station responding NHS, as described may be different (in the
   case of cached replies) than the system identified in Section 5.3.3, SHALL NOT update
   this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to Next Hop
   field of the destination SHALL include information
   about their NBMA Address.

   The Reverse Transit NHS element has Next Hop Resolution Reply.  Further, this extension may
   aid in detecting loops in the following form: NHRP forwarding path.

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           unused              |         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NHS  Res Addr T/L  | NHS Res SAddr T/L| NHS Res Proto Len |     unused    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              NHS          Responder NBMA Address (variable length)             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              NHS         Responder NBMA Subaddress (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             NHS       Responder Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information is considered to be valid.  Cached information
     SHALL be discarded when the holding time expires.

   NHS

   Res Addr T/L
     Type & length of the responding responder NHS's NBMA address interpreted in
     the context of the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0003 for ATM).  When the address length is
     specified as 0 no storage is allocated for the address.

   NHS

   Res SAddr T/L
     Type & length of the responding responder NHS's NBMA subaddress 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 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.

   NHS

   Res Proto Len
     This field holds the length in octets of the transit responding NHS's Protocol
     Address.

   NHS

   Responder NBMA Address
     This is the NBMA address of the transit responding NHS.

   NHS

   Responder NBMA SubAddress
     This is the NBMA subaddress of the transit responding NHS.

   NHS

   Responder Protocol Address
     This is the Protocol Address of the transit responding NHS.

   If a "requester" wishes to obtain desires this information, it the "requester" SHALL
   include this extension with a length value of zero.  Note that this implies
   that 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 is generating a "reply" packet in response to a "request"
   containing this extension, the NHS SHALL include this extension,
   containing its protocol address in the "reply".  If an NHS has more
   than one Protocol protocol address, it SHALL use the same
   Protocol protocol address
   consistently in all of the Responder Address, Forward NHS Record, and
   Reverse NHS Record extensions.  The choice of which of several Protocol addresses
   protocol address to include in this extension is a local matter.

   If a "reply" that is an NHRP Next Hop Resolution Reply packet being forwarded by an NHS
   contains the Protocol
   Address of that NHS in one of the Reverse Transit NHS elements then
   the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
   Detected" and discard the "reply".

   Note that this information may be cached at intermediate NHSs;  if
   so, the cached value SHALL be used when generating a reply.

5.3.6  NHRP QoS Extension

    Compulsory = 0
    Type = 6
    Length = variable

   The NHRP QoS Extension is carried in Next Hop Resolution Request
   packets to indicate the desired QoS of the path to the indicated
   destination.  This information may be used to help select the
   appropriate NBMA Next Hop.

   It may also be carried in NHRP Register Request packets to indicate
   the QoS to which the registration applies.

   The syntax and semantics of this extension are TBD;  alignment with
   resource reservation may be useful.

5.3.7  NHRP Authentication Extension

    Compulsory = 1
    Type = 7
    Length = variable

   The NHRP Authentication Extension is carried in NHRP packets to
   convey authentication information between NHRP speakers.  The
   Authentication Extension may be included in any NHRP "request" or
   "reply".

   Except in the case of an NHRP Registration Request/Reply
   Authentication is done pairwise on an NHRP hop-by-hop basis;  i.e.,
   the authentication extension is regenerated at each hop. In the case protocol address of an NHRP Registration Request/Reply, the Authentication is checked
   on an end-to-end basis rather than hop-by-hop. If a received packet
   fails the authentication test, that NHS in the station Responder Address
   Extension then that NHS SHALL generate an NHRP Error Indication of
   type "Authentication Failure" "NHRP Loop Detected" and discard the packet.
   Note that one possible authentication failure Next Hop Resolution Reply.

   If an NHRP Next Hop Resolution Reply packet is the lack of being returned by an
   Authentication Extension;
   intermediate NHS based on cached data, it SHALL place its own address
   in this extension (differentiating it from the presence or absence of address in the
   Authentication Next
   Hop field).

5.3.4  NHRP Forward Transit NHS Record Extension is a local matter.

          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

    Compulsory = 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                     Authentication Type                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Authentication
    Type field identifies the authentication method in
   use.  Currently assigned values are:

   1 - Cleartext Password
   2 - Keyed MD5

   All other values are reserved. = 4
    Length = variable

   The Authentication Data field NHRP Forward Transit NHS record contains the type-specific
   authentication information.

   In the case of Cleartext Password Authentication, the Authentication
   Data consists of a variable length password.

   In the case of Keyed MD5 Authentication, the Authentication Data
   contains the 16 byte MD5 digest list of the entire NHRP packet, including
   the encapsulated protocol's header, with the authentication key
   appended transit NHSs
   through which a "request" has traversed.  Each NHS SHALL append to
   the end of the packet.  The authentication key is not
   transmitted with the packet.

   Distribution of authentication keys is outside extension a Forward Transit NHS element (as specified below)
   containing its Protocol address The extension length field and the scope of this
   document.

5.3.8  NHRP Vendor-Private Extension

    Compulsory = 0
    Type = 8
    Length = variable
   ar$chksum fields SHALL be adjusted appropriately.

   The NHRP Vendor-Private Extension is carried responding NHS, as described in NHRP Section 5.3.3, SHALL NOT update
   this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to
   convey vendor-private the destination SHALL include information or NHRP extensions between NHRP
   speakers.
   about their NBMA Address.

   The Forward Transit NHS element has the following form:

          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           unused              |  Data....         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor ID
     802 Vendor ID
         |  NHS Addr T/L  | NHS SAddr T/L| NHS Proto Len |     unused    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              NHS NBMA Address (variable length)               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |              NHS NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             NHS Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information is considered to be valid.  Cached information
     SHALL be discarded when the holding time expires.

   NHS Addr T/L
     Type & length of the transit NHS's NBMA address interpreted in the
     context of the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0003 for ATM).  When the address length is
     specified as 0 no storage is allocated for the address.

   NHS SAddr T/L
     Type & length of the transit NHS's NBMA subaddress 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 assigned by 0 no storage
     is allocated for the IEEE [6]

   Data
     The remaining octets after address.

   NHS Proto Len
     This field holds the Vendor ID length in octets of the payload are
     vendor-dependent data. transit NHS's Protocol
     Address.

   NHS NBMA Address
     This extension may be added to any "request" or "reply" packet and it is the only extension that may be included multiple times.  If NBMA address of the
   receiver does not handle this extension, or does not match transit NHS.

   NHS NBMA SubAddress
     This is the Vendor
   ID in NBMA subaddress of the extension then transit NHS.

   NHS Protocol Address
     This is the extension may be completely ignored by Protocol Address of the receiver. transit NHS.

   If a Vendor Private Extension "requester" wishes to obtain this information, it SHALL include
   this extension with a length of zero.  Note that this implies that no
   storage is included 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.  The choice of
   which of several Protocol addresses to include in this extension is a
   local matter.

   If a "request" then that is must be copied being forwarded by an NHS contains the
   Protocol Address of that NHS 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 corresponding "reply".

5.3.9  Additional Next Hop Entries "request".

5.3.5  NHRP Reverse Transit NHS Record Extension

    Compulsory = 0 1
    Type = 9 5
    Length = variable

   This extension may be used to return multiple Next Hop entries in a
   single NHRP Reply packet.  This extension MUST only be used for
   positive replies.

   The preference values are used to specify the
   relative preference NHRP Reverse Transit NHS record contains a list of the entries contained in the extension.  The
   same next Hop transit NHSs
   through which a "reply" has traversed.  Each NHS SHALL append a
   Reverse Transit NHS element (as specified below) containing its
   Protocol address may be associated with multiple NBMA
   addresses.  Load-splitting may be performed over the addresses, given
   equal preference values, to this extension.  The extension length field and the alternative addresses may
   ar$chksum SHALL be used in
   case of connectivity failure in the NBMA subnetwork (such adjusted appropriately.

   The responding NHS, as a failed
   call attempt described in connection-oriented Section 5.3.3, SHALL NOT update
   this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to the destination SHALL include information
   about their NBMA subnetworks). Address.

   The following shows Reverse Transit NHS element has the format for additional Next Hop Entries: following form:
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Maximum Transmission Unit    |        Holding Time           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NH Addr T/L   | NH SAddr T/L |  NH Proto Len |  Preference   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop NBMA Address (variable length)              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop Protocol Address (variable length)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .....................
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Maximum Transmission Unit    |           unused              |         Holding Time          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  NH  NHS Addr T/L  | NH NHS SAddr T/L |  NH T/L| NHS Proto Len |  Preference     unused    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Next Hop              NHS NBMA Address (variable length)               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop              NHS NBMA Subaddress (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Next Hop             NHS Protocol Address (variable length)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An NHS is not allowed to reply to an NHRP request for authoritative
   information with cached information, but may do so for an NHRP
   Request which indicates a request for non-authoritative information.
   An NHS may reply to an NHRP request for non-authoritative information
   with authoritative information.

   Maximum Transmission Unit
     This field gives the maximum transmission unit for the target
     station.  If this value is 0 then either the default MTU is used or
     the MTU negotiated via signaling is used if such negotiation is
     possible for the given NBMA.
   Holding Time
     The Holding Time field specifies the number of seconds for which
     the Next Hop NBMA information specified in the Next Hop Entry is considered to be valid.  Cached information
     SHALL be discarded when the holding time expires.  This field must be set to 0 on a NAK.

   NH

   NHS Addr T/L
     Type & length of next hop the responding NHS's NBMA address specified in the Next Hop
     Entry.  This field is interpreted in
     the context of the 'address family number'[6] indicated by ar$afn
     (e.g., ar$afn=0x0003 for ATM).

   NH  When the address length is
     specified as 0 no storage is allocated for the address.

   NHS SAddr T/L
     Type & length of next hop the responding NHS's NBMA subaddress specified in the Next Hop
     Entry.  This field is 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.

   NH Proto Len
     This field holds the length in octets of the Next Hop Protocol
     Address specified in the Next Hop Entry.

   Preference
     This field specifies the preference of the specific Next Hop Entry
     relative to other Next Hop entries in this Next Hop Resolution
     Reply mandatory part or in the Additional Next Hop Entries
     Extension for the given internetworking protocol.  Higher values
     indicate higher preference.  Action taken when multiple next hop
     entries have the highest preference value length is a local matter.

   Next Hop specified as 0 no storage
     is allocated for the address.

   NHS Proto Len
     This field holds the length in octets of the transit NHS's Protocol
     Address.

   NHS NBMA Address
     This is the NBMA address of the station that is the next hop for
     packets bound for the internetworking layer address specified.

   Next Hop transit NHS.

   NHS NBMA SubAddress
     This is the NBMA subaddress of the station that is the next hop for
     packets bound for the internetworking layer address specified.

   Next Hop transit NHS.

   NHS Protocol Address
     This internetworking layer address specifies the next hop.  This
     will be is the address Protocol Address of the destination host if transit NHS.

   If a "requester" wishes to obtain this information, it SHALL include
   this extension with a length of zero.  Note that this implies that no
   storage is directly
     attached to allocated for the NBMA subnetwork, or Holding Time and Type/Length fields
   until the egress router if it "Value" portion of the extension is not
     directly attached.

6. filled out.

   If an NHS has more than one Protocol Operation

   In this section, we discuss certain operational considerations address, it SHALL use the same
   Protocol address consistently in all of
   NHRP.

6.1 Router-to-Router Operation

   In practice, the initiating Responder Address,
   Forward NHS Record, and responding stations may be either
   hosts or routers.  However, there Reverse NHS Record extensions.  The choice of
   which of several Protocol addresses to include in this extension is a possibility under certain
   conditions
   local matter.

   If a "reply" that is being forwarded by an NHS contains the Protocol
   Address of that NHS in one of the Reverse Transit NHS elements then
   the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
   Detected" and discard the "reply".

   Note that a stable routing loop this information may occur be cached at intermediate NHSs;  if NHRP is
   so, the cached value SHALL be used
   between two routers.  In particular, attempting to establish an NHRP
   path across when generating a boundary where information used in route selection reply.

5.3.6  NHRP QoS Extension

    Compulsory = 0
    Type = 6
    Length = variable

   The NHRP QoS Extension is
   lost may result carried in a routing loop.  Such situations include Next Hop Resolution Request
   packets to indicate the loss desired QoS of BGP the path vector information, to the interworking of multiple routing
   protocols with dissimilar metrics (e.g, RIP and OSPF), etc.  In such
   circumstances, NHRP should not be used. indicated
   destination.  This situation can information may be
   avoided if there are no "back door" paths between the entry and
   egress router outside of the NBMA subnetwork.  Protocol mechanisms to
   relax these restrictions are under investigation.

   In general it is preferable to use mechanisms, if they exist, in
   routing protocols used to resolve the egress point when the destination
   lies outside of help select the
   appropriate NBMA subnetwork, since such mechanisms will Next Hop.

   It may also be
   more tightly coupled carried in NHRP Register Request packets to indicate
   the state of QoS to which the routing system registration applies.

   The syntax and will
   probably semantics of this extension are TBD;  alignment with
   resource reservation may be less likely useful.

5.3.7  NHRP Authentication Extension

    Compulsory = 1
    Type = 7
    Length = variable

   The NHRP Authentication Extension is carried in NHRP packets to create loops.

6.2 Cache Management Issues
   convey authentication information between NHRP speakers.  The management of
   Authentication Extension may be included in any NHRP caches "request" or
   "reply".

   Except in the source station, case of an NHRP Registration Request/Reply
   Authentication is done pairwise on an NHRP hop-by-hop basis;  i.e.,
   the NHS serving authentication extension is regenerated at each hop. In the destination, and any intermediate NHSs case
   of an NHRP Registration Request/Reply, the Authentication is dependent checked
   on an end-to-end basis rather than hop-by-hop. If a number
   of factors.

   6.2.1 Caching Requirements

     Source Stations

     Source stations MUST cache all received Next Hop Resolution Replies packet
   fails the authentication test, the station SHALL generate an Error
   Indication of type "Authentication Failure" and discard the packet.
   Note that they are actively using.  They also must cache "incomplete"
     entries, i.e., those for which a Next Hop Resolution Request has
     been sent but which a Next Hop Resolution Reply has not been
     received.  This one possible authentication failure is necessary the lack of an
   Authentication Extension;  the presence or absence of the
   Authentication Extension is a local matter.

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                     Authentication Type                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Authentication Type field identifies the authentication method in order to preserve
   use.  Currently assigned values are:

   1 - Cleartext Password
   2 - Keyed MD5

   All other values are reserved.

   The Authentication Data field contains the Request ID
     for retries, and provides type-specific
   authentication information.

   In the case of Cleartext Password Authentication, the state necessary to avoid triggering
     Next Hop Resolution Requests for every data packet sent to Authentication
   Data consists of a variable length password.

   In the
     destination.

     Source stations MUST purge expired information from their caches.
     Source stations MUST purge case of Keyed MD5 Authentication, the appropriate cached information upon
     receipt Authentication Data
   contains the 16 byte MD5 digest of an the entire NHRP Purge Request packet.

     When a station has a co-resident client and NHS, packet, including
   the station may
     reply to Next Hop Resolution Requests encapsulated protocol's header, with information which the
     station cached as a result authentication key
   appended to the end of the station making its own Next Hop
     Resolution Requests and receiving its own Next Hop Resolution
     Replies as long as packet.  The authentication key is not
   transmitted with the station follows packet.

   Distribution of authentication keys is outside the rules for Transit NHSs
     as seen below.

     Serving NHSs scope of this
   document.

5.3.8  NHRP Vendor-Private Extension

    Compulsory = 0
    Type = 8
    Length = variable

   The NHS serving the destination (the one which responds
     authoritatively NHRP Vendor-Private Extension is carried in NHRP packets to Next Hop Resolution Requests) SHOULD cache
   convey vendor-private information about all Next Hop Resolution Requests to which it has
     responded if or NHRP extensions between NHRP
   speakers.

          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
     802 Vendor ID as assigned by the IEEE [6]

   Data
     The remaining octets after the information Vendor ID in the Next Hop Resolution Reply has payload are
     vendor-dependent data.

   This extension may be added to any "request" or "reply" packet and it
   is the possibility of changing during its lifetime (so only extension that an NHRP
     Purge Request packet can may be sent).  The NBMA information provided
     by included multiple times.  If the source station
   receiver does not handle this extension, or does not match the Vendor
   ID in the Next Hop Resolution Request extension then the extension may be
     cached for completely ignored by
   the duration of its holding time.  This information is
     considered to be stable, since it identifies receiver.  If a station directly
     attached to the NBMA subnetwork.  An example of unstable
     information Vendor Private Extension is NBMA information derived from included in a routing table, where
     that routing table information has not been guaranteed to
   "request" then is must be stable
     through administrative means.

     Transit NHSs

     A Transit NHS (lying along copied in the NHRP path between corresponding "reply".

5.3.9  Extension with Type 9 not assigned.

6. Protocol Operation

   In this section, we discuss certain operational considerations of
   NHRP.

6.1 Router-to-Router Operation

   In practice, the source station initiating and the responding NHS) may cache information contained in Next Hop
     Resolution Request packets that it forwards.  A Transit NHS stations may
     cache information contained in Next Hop Resolution Reply packets
     that it forwards only if be either
   hosts or routers.  However, there is a possibility under certain
   conditions that Next Hop Resolution Reply has the
     Stable (B) bit set.  It MUST discard any cached information whose
     holding time has expired.  It a stable routing loop may return cached occur if NHRP is used
   between two routers.  In particular, attempting to establish an NHRP
   path across a boundary where information used in
     response to non-authoritative Next Hop Resolution Requests only.

   6.2.2 Dynamics of Cached Information

   NBMA-Connected Destinations

     NHRP's most basic function route selection is that
   lost may result in a routing loop.  Such situations include the loss
   of simple NBMA address
     resolution BGP path vector information, the interworking of multiple routing
   protocols with dissimilar metrics (e.g, RIP and OSPF), etc.  In such
   circumstances, NHRP should not be used.  This situation can be
   avoided if there are no "back door" paths between the entry and
   egress router outside of stations directly attached to the NBMA subnetwork.
     These mappings  Protocol mechanisms to
   relax these restrictions are typically very static, and appropriately chosen
     holding times will minimize problems under investigation.

   In general it is preferable to use mechanisms, if they exist, in
   routing protocols to resolve the event that egress point when the NBMA
     address destination
   lies outside of a station must be changed.  Stale information the NBMA subnetwork, since such mechanisms will cause
     a loss of connectivity, which may be used
   more tightly coupled to trigger an
     authoritative Next Hop Resolution Request and bypass the old data.
     In state of the worst case, connectivity routing system and will fail until the cache entry
     times out.

     This applies equally
   probably be less likely to information marked create loops.

6.2 Cache Management Issues

   The management of NHRP caches in the source station, the NHS serving
   the destination, and any intermediate NHSs is dependent on a number
   of factors.

   6.2.1 Caching Requirements

     Source Stations

     Source stations MUST cache all received Next Hop Resolution Replies as being "stable" (via the "B" bit).

     This also applies equally well to source stations
     that they are routers
     as well as actively using.  They also must cache "incomplete"
     entries, i.e., those for which are hosts.

     Note that the information carried in the a Next Hop Resolution Request packet is always considered "stable" because it represents has
     been sent but which a station that Next Hop Resolution Reply has not been
     received.  This is directly connected necessary in order to preserve the NBMA subnetwork.

   Destinations Off of the NBMA Subnetwork

     If Request ID
     for retries, and provides the source of a state necessary to avoid triggering
     Next Hop Resolution Requests for every data packet sent to the
     destination.

     Source stations MUST purge expired information from their caches.
     Source stations MUST purge the appropriate cached information upon
     receipt of an NHRP Purge Request is packet.

     When a host station has a co-resident client and NHS, the
     destination is not directly attached station may
     reply to Next Hop Resolution Requests with information which the NBMA subnetwork,
     station cached as a result of the station making its own Next Hop
     Resolution Requests and receiving its own Next Hop Resolution
     Replies as long as the route to that destination is not considered to be "stable," station follows the
     destination mapping may be very dynamic (except in rules for Transit NHSs
     as seen below.

     Serving NHSs

     The NHS serving the case of a
     subnetwork where each destination is only singly homed (the one which responds
     authoritatively to the NBMA
     subnetwork).  As such the cached Next Hop Resolution Requests) SHOULD cache
     information may very likely become
     stale.  The consequence of stale about all Next Hop Resolution Requests to which it has
     responded if the information in this case will be a
     suboptimal path (unless the internetwork has partitioned or some
     other routing failure Next Hop Resolution Reply has occurred).

     Strategies for maintaining
     the possibility of changing during its lifetime (so that an NHRP cache
     Purge Request packet can be sent).  The NBMA information provided
     by the source station in the presence
     of dynamic routing changes will Next Hop Resolution Request may be discussed in a separate
     document.

6.3 Use of
     cached for the Destination Prefix Length Extension

   A certain amount duration of care needs its holding time.  This information is
     considered to be taken when using the Destination
   Prefix Length Extension, in particular with regard stable, since it identifies a station directly
     attached to the prefix
   length advertised (and thus the size of the equivalence class
   specified by it).  Assuming that the routers on the NBMA subnetwork
   are exchanging routing information, it should not be possible for an
   NHS to create a black hole by advertising too large subnetwork.  An example of unstable
     information is NBMA information derived from a set of
   destinations, but suboptimal routing (e.g., extra internetwork layer
   hops through the NBMA) can result.  To avoid this situation an NHS table, where
     that wants routing table information has not been guaranteed to send the Destination Prefix Length Extension MUST obey
   the following rule:

     The be stable
     through administrative means.

     Transit NHSs

     A Transit NHS examines the Network Layer Reachability Information (NLRI)
     associated with the route that (lying along the NHS would use to forward towards NHRP path between the destination (as specified by source station
     and the Destination internetwork layer
     address responding NHS) may cache information contained in Next Hop
     Resolution Request packets that it forwards.  A Transit NHS may
     cache information contained in the Next Hop Resolution Request), and extracts from this
     NLRI the shortest address prefix such that: (a) the Destination
     internetwork layer address (from Reply packets
     that it forwards only if that Next Hop Resolution Reply has the
     Stable (B) bit set.  It MUST discard any cached information whose
     holding time has expired.  It may return cached information in
     response to non-authoritative Next Hop Resolution Request) Requests only.

   6.2.2 Dynamics of Cached Information

   NBMA-Connected Destinations

     NHRP's most basic function is covered by that of simple NBMA address
     resolution of stations directly attached to the prefix, (b) NBMA subnetwork.
     These mappings are typically very static, and appropriately chosen
     holding times will minimize problems in the NHS does not have any routes with
     NLRI event that forms the NBMA
     address of a subset station must be changed.  Stale information will cause
     a loss of what is covered by the prefix. The
     prefix connectivity, which may then be used for to trigger an
     authoritative Next Hop Resolution Request and bypass the Destination Prefix Length
     Extension.

   The NHRP Destination Prefix Length Extension should be used with
   restraint, old data.
     In the worst case, connectivity will fail until the cache entry
     times out.

     This applies equally to information marked in order Next Hop Resolution
     Replies as being "stable" (via the "B" bit).

     This also applies equally well to avoid NHRP source stations choosing suboptimal
   transit paths when overlapping prefixes that are available.  This
   extension SHOULD only be used routers
     as well as those which are hosts.

     Note that the information carried in the Next Hop Resolution
     Request packet is always considered "stable" because it represents
     a Next Hop Resolution Reply when
   either:

     (a) All destinations covered by station that is directly connected to the prefix are on NBMA subnetwork.

   Destinations Off of the NBMA network, or
     (b) All destinations covered by Subnetwork

     If the prefix are source of a Next Hop Resolution Request is a host and the
     destination is not directly attached to the NHRP responding station.

   For other cases, there may be no single optimal transit path for
   destinations encompassed by the address prefix, NBMA subnetwork, and an NHRP station
   may fail to choose
     the optimal transit path simply because it route to that destination is not
   aware of all such paths.  So for cases not covered by (a) and (b), an
   Next Hop Resolution Reply packet should not include considered to be "stable," the NHRP
   Destination Prefix Length Extension.

6.4 Domino Effect

   One could easily imagine
     destination mapping may be very dynamic (except in the case of a situation
     subnetwork where a router, acting as an
   ingress station each destination is only singly homed to the NBMA subnetwork, receives a data packet,
     subnetwork).  As such
   that this packet triggers an Next Hop Resolution Request.  If the
   router forwards cached information may very likely become
     stale.  The consequence of stale information in this data packet without waiting for an NHRP transit case will be a
     suboptimal path (unless the internetwork has partitioned or some
     other routing failure has occurred).

6.3 Use of the Prefix Length field of a CIE

   A certain amount of care needs to be established, then taken when using the next router along the path
   receives Prefix
   Length field of a CIE, in particular with regard to the packet, prefix length
   advertised (and thus the next router may do exactly size of the same -
   originate its own Next Hop Resolution Request (as well as forward equivalence class specified by
   it).  Assuming that the
   packet).  In fact such a data packet may trigger Next Hop Resolution
   Request generation at every router along routers on the path through an NBMA
   subnetwork.  We refer to this phenomena as the NHRP "domino" effect.

   The NHRP domino effect is clearly undesirable.  At best it may result
   in excessive NHRP traffic.  At worst subnetwork are exchanging
   routing information, it may result in should not be possible for an excessive
   number of virtual circuits being established unnecessarily.
   Therefore, it is important to take certain measures NHS to avoid or
   suppress this behavior.  NHRP implementations for NHSs MUST provide create a
   mechanism to address
   black hole by advertising too large of a set of destinations, but
   suboptimal routing (e.g., extra internetwork layer hops through the
   NBMA) can result.  To avoid this problem.  It is recommended situation an NHS that
   implementations provide one or more of wants to send
   the Prefix Length MUST obey the following solutions.

   Possibly rule:

     The NHS examines the most straightforward solution for suppressing Network Layer Reachability Information (NLRI)
     associated with the domino
   effect route that the NHS would be to require transit routers to be preconfigured not use to
   originate forward towards
     the destination (as specified by the Destination internetwork layer
     address in the Next Hop Resolution Requests for data traffic which is
   simply being forwarded (not originated).  In Request), and extracts from this case
     NLRI the routers
   avoid shortest address prefix such that: (a) the Destination
     internetwork layer address (from the domino effect through an administrative policy.

   A second possible solution would be to require that when a router
   forwards an Next Hop Resolution Request, Request)
     is covered by the router instantiates prefix, (b) the NHS does not have any routes with
     NLRI that forms a
   (short-lived) state.  This state consists subset of what is covered by the route that was prefix. The
     prefix may then be used in the CIE.

   The Prefix Length field of the CIE should be used with restraint, in
   order to forward avoid NHRP stations choosing suboptimal transit paths when
   overlapping prefixes are available.  This document specifies the Next Hop Resolution Request.  If use
   of the router receives a
   data packet, and prefix length only when all the packet triggers an Next Hop Resolution Request
   generation destinations covered by the router,
   prefix are "stable". That is, either:

     (a) All destinations covered by the router checks whether prefix are on the route to
   forward NBMA network, or

     (b) All destinations covered by the Next Hop Resolution Request was recently used prefix are directly attached to forward
   some other Next Hop Resolution Request.  If so, then
         the router
   suppresses generation NHRP responding station.

   Use of the new Next Hop Resolution Request (but
   still forwards Prefix Length field of the data packet).  This solution also requires that
   when CIE in other circumstances is
   outside the scope of this document.

6.4 Domino Effect

   One could easily imagine a station attempts to originate situation where a router, acting as an Next Hop Resolution Request
   the
   ingress station should send to the NBMA subnetwork, receives a data packet, such
   that this packet triggers an Next Hop Resolution Request before Request.  If the
   router forwards this data packet that triggered without waiting for an NHRP transit
   path to be established, then when the origination of next router along the path
   receives the packet, the next router may do exactly the same -
   originate its own Next Hop Resolution
   Request.  Otherwise, unnecessary Request (as well as forward the
   packet).  In fact such a data packet may trigger Next Hop Resolution Requests
   Request generation at every router along the path through an NBMA
   subnetwork.  We refer to this phenomena as the NHRP "domino" effect.

   The NHRP domino effect is clearly undesirable.  At best it may
   still be generated.

   A third result
   in excessive NHRP traffic.  At worst it may result in an excessive
   number of virtual circuits being established unnecessarily.
   Therefore, it is important to take certain measures to avoid or
   suppress this behavior.  NHRP implementations for NHSs MUST provide a
   mechanism to address this problem. One possible strategy to address
   this problem would be to configure a router in such a way that Next
   Hop Resolution Request generation by the router would be driven only
   by the traffic the router receives over its non-NBMA interfaces
   (interfaces that are not attached to an NBMA subnetwork).  Traffic
   received by the router over its NBMA-attached interfaces would not
   trigger NHRP Next Hop Resolution Requests.  Just as in the
   first case, such  Such a router avoids the
   NHRP domino effect through administrative means.

   Lastly, rate limiting of Next Hop Resolution Requests may help to
   avoid the

7. NHRP domino effect.  Intermediate routers which would
   otherwise generate unnecessary Next Hop Resolution Requests may
   instead suppress such Next Hop Resolution Requests due to the
   measured Next Hop Resolution Request rate exceeding a certain
   threshold.  Of course, such rate limiting over Legacy BMA Networks

   There would have appear to be very
   aggressive in order to completely avoid the domino effect.  Further
   work is needed no significant impediment to analyze this solution.

7. 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 when setting up
   a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both
   end stations are legacy attached.  This use for NHRP requires further
   research.

8. Security Considerations

   As in any routing protocol, there are a number of potential security
   attacks possible.  Plausible examples include denial-of-service
   attacks, and masquerade attacks using register and purge packets.
   The use of authentication on all packets is recommended to avoid such
   attacks.

   The authentication schemes described in this document are intended to
   allow the receiver of a packet to validate the identity of the
   sender; they do not provide privacy or protection against replay
   attacks.

   Detailed security analysis of this protocol is for further study.

8.

9. Discussion

   The result of an Next Hop 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 the routed path to it lies entirely within the NBMA subnetwork,
   the Next Hop Resolution Replies always return the NBMA address of the
   destination station itself rather than the NBMA address of some
   egress router.  On the other hand, if the routed path exits the NBMA
   subnetwork, NHRP will be unable to resolve the NBMA address of the
   destination, but rather will return the address of the egress router.
   For destinations outside the NBMA subnetwork, egress routers and
   routers in the other subnetworks should exchange routing information
   so that the optimal egress router may be found.

   In addition to NHSs, an NBMA station could also be associated with
   one or more regular routers that could act as "connectionless
   servers" for the station.  The station could then choose to resolve
   the NBMA next hop or just send the packets to one of its
   connectionless servers.  The latter option may be desirable if
   communication with the destination is short-lived and/or doesn't
   require much network resources.  The connectionless servers could, of
   course, be physically integrated in the NHSs by augmenting them with
   internetwork layer switching functionality.

References

   [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
       Govindan, draft-ietf-rolc-nbma-arp-00.txt. RFC1735.

   [2] Address Resolution Protocol, David C. Plummer, RFC 826.

   [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.

   [4] Transmission of IP datagrams over the SMDS service, J. Lawrence
       and D. Piscitello, RFC 1209.

   [5] Protocol Identification in the Network Layer, ISO/IEC TR
       9577:1990.

   [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.

   [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen,
       RFC1483.

   [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
       A. Malis, D. Robinson, and R. Ullmann, RFC1356.

   [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
       A. Malis, RFC1490.

   [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks,
        Yakov Rekhter, Dilip Kandlur, RFCxxxx.

Acknowledgments

   We would like to thank 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, Joel Halpern
   of Newbridge, Paul Francis of NTT, Tony Li 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 Routing Over Large Clouds ION working group of
   the IETF, whose review and discussion of this document have been
   invaluable.

Authors' Addresses

   James V. Luciani                    Dave Katz                           David Piscitello
   Bay Networks                        cisco Systems                       Core Competence
   3 Federal Street                    170 W. Tasman Dr.                   1620 Tuckerstown Road
   Mail Stop: BL3-04                   San Jose, CA 95134 USA              Dresher, PA 19025 USA
   Billerica, MA 01821                 Phone:  +1 408 526 8284
   Phone:  +1 215 830 0692 508 439 4737             Email:  dkatz@cisco.com
   Email: dave@corecom.com  luciani@baynetworks.com

   David Piscitello                    Bruce Cole                          James V. Luciani
   Core Competence                     cisco Systems                       Ascom Nexion
   1620 Tuckerstown Road               170 W. Tasman Dr.                   289 Great Road
   Dresher, PA 19025 USA               San Jose, CA 95134 USA              Acton, MA 01720-4379 USA
   Phone:  +1 215 830 0692Phone:       Phone:  +1 408 526 4000             Phone:  +1 508 266 3450
   Email:  bcole@cisco.com dave@corecom.comEmail:       Email: luciani@nexen.com  bcole@cisco.com