Imported Upstream version 0.13

2 files changed, 3752 insertions, 0 deletions

diff --git a/doc/draft-ietf-ion-r2r-nhrp-03.txt b/doc/draft-ietf-ion-r2r-nhrp-03.txt
new file mode 100644
index 0000000..8f80b36
--- /dev/null
+++ b/doc/draft-ietf-ion-r2r-nhrp-03.txt
@@ -0,0 +1,837 @@
+Internetworking Over NBMA                                  Yakov Rekhter
+INTERNET-DRAFT                                             Cisco Systems
+<draft-ietf-ion-r2r-nhrp-03.txt>                            Joel Halpern
+Expiration Date: November 1999            Institutional Venture Partners
+                                                                May 1998
+
+
+             NHRP for Destinations off the NBMA Subnetwork
+
+                     draft-ietf-ion-r2r-nhrp-03.txt
+
+
+1. Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.  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.''
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+2. Abstract
+
+   The NBMA Next Hop Resolution Protocol (NHRP) [1] specifies a
+   mechanism that allows a source station (e.g., a host or a router) on
+   an NBMA subnetwork to find the NBMA subnetwork address of a
+   destination station when the destination station is connected to the
+   NBMA subnetwork. For the case where the destination station is off
+   the NBMA subnetwork the mechanism described in [1] allows a node to
+   determine the NBMA subnetwork address of an egress router from the
+   NBMA subnetwork that is ``nearest'' to the destination station.  If
+   used to locate an egress router wherein the destination station is
+   directly behind the egress router, the currently documented NHRP
+   behaviors are sufficient.  However, as documented elsewhere [2],
+   there are cases where if used between routers for generalized
+   transit, NHRP can produce loops.
+
+
+
+
+Joel Halpern                                                    [Page 1]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+   This document describes extensions to the NBMA Next Hop Resolution
+   Protocol (NHRP) [1] that allow a node to acquire and maintain the
+   information about the egress router without constraining the
+   destination(s) to be directly connected to the egress router.
+
+
+3. CONVENTIONS
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+
+4. NHRP Target Information
+
+   The mechanism described in this document allows a node to find an
+   egress router for either a single destination, or a set of
+   destinations (where the set is expressed as a single address prefix).
+   Since a single destination is just a special case of a set of
+   destinations, for the rest of the document we will always talk about
+   a set of destinations, and will refer to this set as an ``NHRP
+   target''.
+
+   The NHRP target is carried in the NHRP Request,  Reply, and Purge
+   messages as an address prefix (using the Prefix Length field of the
+   NHRP Client Information Extension).  In order to ensure correctness,
+   a target may be replaced by an identical target with a longer prefix
+   length.  This replacement may be done at an intermediate or
+   responding NHS. Other than this increase of prefix length, no NHS
+   shall modify the NHRP target information in an NHRP message.
+
+   In general a router may maintain in its Forwarding Information Base
+   (FIB) routes whose Network Layer Reachability Information (NLRI) that
+   exhibits a subset relation. Such routes are called overlapping
+   routes. To expand upon this, entries in a FIB are often related, with
+   one entry being a prefix of another entry.  The longer prefix
+   therefore covers a set of routes that are a subset of the shorter
+   prefix. To provide correct forwarding in the presence of such
+   overlapping (or nested) routes this document constrains an NHRP
+   target by requiring that all the destinations covered by the target
+   must form a subset of the NLRI of at least one route in the
+   Forwarding Information Base (FIB) of the router that either
+   originates, or propagates an NHRP Request. That is, there must be at
+   least one route in the FIB which is a prefix of (or equal to) the
+   target of the request. For the rest of the document we'll refer to
+   this as the ``first NHRP target constraint''.  A station can
+   originate an NHRP Request, and a router can propagate an NHRP Request
+   only if the NHRP target of the Request does not violate the first
+
+
+
+Joel Halpern                                                    [Page 2]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+   NHRP target constraint.
+
+   If a received NHRP request does not meet this ``first NHRP target
+   constraint'' when received, the receiving router has two choices.  It
+   may answer the request, defining itself as the egress.  This is
+   compatible with the base NHRP specification, and preserves the
+   ``first NHRP target constraint''.  Alternatively, the router may
+   lengthen the received prefix until the first constraint is met. The
+   prefix is lengthened until the target falls within (or becomes equal
+   to) a FIB entry.
+
+   A route (from a local FIB) whose NLRI forms a minimal superset of all
+   the destinations covered by the NHRP target is called an ``NHRP
+   forwarding route''. This is the longest FIB entry that covers the
+   entire target. Observe that by definition the set of destinations
+   covered by an NHRP target always exhibits a subset relation to the
+   set of destinations covered by the NHRP forwarding route associated
+   with the target.
+
+   This document further constrains origination/propagation of NHRP
+   Requests by prohibiting the NHRP target (carried by a Request) to
+   form a superset of the destinations covered by any of the routes in
+   the local FIB.  Remembering that there are nested FIB entries, this
+   constraint says that there must not be a FIB entry which is itself a
+   subset of the target of the NHRP request.  If there were, there would
+   be some destinations within the request which would be forwarded
+   differently then others, preventing a single answer from being
+   correct. The constraint applies both to the station that originates
+   an NHRP Request and to the routers that propagate the Request. For
+   the rest of the document we'll refer to this constraint as the
+   ``second NHRP target constraint''. A station can originate an NHRP
+   Request, and a router can propagate an NHRP Request only if the NHRP
+   target of the Request does not violate the second NHRP target
+   constraint. The second NHRP target constraint guarantees that
+   forwarding to all the destinations covered by the NHRP target would
+   be accomplished via a single (common) route, and this route would be
+   the NHRP forwarding route for the target.
+
+   Again, if a received NHRP request does not meet the ``second NHRP
+   target constraint'', the router may either respond to the request,
+   providing its own NBMA address, or it may lengthen the prefix in the
+   request so as to meet the second constraint.
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                    [Page 3]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+5. NHRP Requester and Terminator Processing
+
+   The issue being addressed with the behaviors being mandated in this
+   document is to ensure that sufficient information is present and
+   processed to avoid NHRP shortcuts causing packet forwarding loops.
+
+   In order to do this, the requester and responder of the request must
+   undertake certain work, and any "border routers" in the forwarding
+   path must also perform certain additional work beyond checking the
+   target consistency with the FIB during request processing. This
+   border work suffices to detect any changes that would cause the path
+   selection to have failed the target constraints.
+
+   The work performed by the requester and responder consists of two
+   kinds of work.  One set is requester only work, and is required in
+   order to determine where the protocol boundaries are.  The other set
+   is the route monitoring work.
+
+
+5.1. NHRP IGP information
+
+   The primary cause of NHRP forwarding loops is the loss of information
+   at a routing protocol boundary.  Normally, such boundaries are
+   detected by the router at the boundary.  However, it is possible for
+   IGP boundaries to overlap.  Therefore, NHRP requesting Routers MUST
+   include the NHRP IGP Information extension (as defined in section 9).
+   This extension indicates what IGP the originator of the request uses.
+   A requesting router must always include this extension, since it is
+   not possible to tell a priori whether the eventual resolution of the
+   request will be a host or a router.
+
+   Because the entire BGP domain is consider one routing domain, the
+   extension also contains an indication as to whether the originator
+   was a BGP speaker.
+
+
+5.2. NHRP Requestor and Responder monitoring
+
+   NHRP requestors and responders are required to monitor routing to
+   maintain correct shortcut information.
+
+   Once a router that originates an NHRP Request acquires the shortcut
+   next hop information, it is essential for the router to be able to
+   detect any changes that would affect the correctness of this
+   information. The following measures are intended to provide the
+   correctness.
+
+   Both ends of a shortcut have to monitor the status of the route that
+
+
+
+Joel Halpern                                                    [Page 4]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+   was associated with the shortcut (the NHRP forwarding route). If the
+   status changes at the router that generated the NHRP Reply, this
+   router should send a Purge message, so that the NHRP Requester would
+   issue another NHRP. If the status changes at the Requester, the
+   Requester must issue another NHRP. This ensures that when both ends
+   of a shortcut are up, any changes in routing that impact forwarding
+   to any of the destinations in the NHRP target would result in a
+   revalidation (via NHRP) of the shortcut.  Note that in addition to
+   sending purges/reverifies in response to routing changes which
+   directly effect the NHRP target, there is one other case.
+
+   A router MUST perform the appropriate purge/reverification process if
+   it receives routing updates that cause an issued NHRP request to
+   violate either of the target constraints defined earlier.  This is
+   possible at an NHRP originator, and is more likely at border devices.
+
+   Once a shortcut is established, the Requester needs to have some
+   mechanism(s) to ensure that the other end of the shortcut is alive.
+   Among the possible mechanisms are: (a) indications from the Data Link
+   layer, (b) presence of traffic in the reverse direction that comes
+   with the Link Layer address of the other end, (c) keepalives sent by
+   the other end. This is intended to suppress black holes, when the
+   next hop router in the shortcut (the router that generated Reply)
+   goes down.
+
+   A requester should establish a shortcut only after the requester
+   determines that the information provided by NHRP is fairly stable.
+   This is necessary in order to avoid initiating shortcuts that are
+   based on transients in the routing information, and thus would need
+   to be revalidated almost immediately anyway. Thus, a router may wait
+   to use NHRP information if the underlying routing information has
+   recently changed.  If the routing protocol being used has a notion of
+   stability, it should be used.  Information in  a transient or
+   holddown state SHOULD NOT be used, and requests which need to be
+   processed based on such information SHOULD be discarded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                    [Page 5]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+6. Border Processing of NHRP Request
+
+   Processing of an NHRP Request is covered by two sets of rules: the
+   first set for IGP related processing, and the second set for BGP
+   related processing.  The rules for IGP processing relate to
+   determining where the IGP borders are (in particular in the case of
+   overlapping IGPs), and then for what must happen at said borders.
+
+
+6.1. Border Determination
+
+   When a router receives a request, and determines  that it is not the
+   NBMA exit router, it must perform a series of checks before
+   forwarding the request.
+
+   When a router receives such a Request, the router uses the NHRP
+   target and the NHRP IGP information  to check whether  (a) the first
+   and the second NHRP target constraints are satisfied, (b) the router
+   it is in the same routing domain as the originator of the Request,
+   and if yes, then whether (c) it is a border router for that domain.
+
+   When the NHRP target is checked against the forwarding database, a
+   determination must be made as to whether either of the target
+   constraints has been violated.  If they are violated, then the router
+   MAY either
+
+         o Extend the prefix so as to meet the constraints.
+
+         o reply to the request indicating that it is the destination
+
+         o return an error indicating which constraint was violated.
+
+   If the NHRP forwarding route indicates a next hop that is not on the
+   same NBMA as the interface on which the Request was received, the
+   router sends back an NHRP Reply and terminates the query.
+
+   If a router receives a request without IGP information, then it was
+   originated within this domain by a host.  If the router is an AS
+   Border Router (i.e. running BGP), and if the forwarding path exits
+   the AS, then it must behave as a border router for this request.
+   Otherwise, for requests without IGP information, the router is not a
+   border router.
+
+   For requests with IGP information, the router compares the forwarding
+   information against the IGP in the request.  If the forwarding entry
+   indicates that the next hop is to exit the AS (an AS Border Router),
+   then check the BGP behaviors below.
+
+
+
+
+Joel Halpern                                                    [Page 6]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+   When the IGP the next hop was learned from is the same IGP as
+   indicated in the request, then the NHS simply forwards the request.
+   [Of course, as per NHRP, it is free to respond indicating it is the
+   termination of the shortcut, for example when the Router/NHS is a
+   firewall.]
+
+   When the IGP the next hop was learned from is different from that
+   listed in the NHRP request, then this NHS is a border router for this
+   request.
+
+
+6.2. Border Behavior
+
+   In all cases, a border router has two choices.  It MAY terminate and
+   respond to the request, responding with its IP and NBMA address.
+
+   Alternatively, it MAY perform border propagation.
+
+
+6.2.1. Reorigination
+
+   Upon receiving an NHRP request for which the NHS is a border router,
+   if it chooses to propagate the request, it MUST originate a new NHRP
+   request.  This request will have a locally generated request
+   identifier, and the same NHRP target information as in the received
+   request.  The NHRP IGP Information will be the correct indication for
+   the outgoing interface, with BGP indication if the received request
+   had the BGP indication, or if this transition crosses the AS border.
+   All other extensions are copied from the incoming request to the new
+   request.
+
+
+6.2.2. Response Propagation
+
+   When an NHRP response is received for a propagated request, the
+   information is copies from the received request, and passed on in a
+   new NHRP response, responding to the originally received request.
+   The prefix length in the received response is copied to the new
+   response.  All extensions except the NHRP IGP Information are copied
+   to the new response.
+
+   In addition, the border router saves state about this information
+   exchange.  The saved state includes the NHRP target from the
+   response, with the NHRP prefix length that resulted from the
+   exchange.  It also includes the both the original requester, and the
+   identity of the responder.  These are used to generate appropriate
+   reverification and purges whenever routing changes in a way that
+   could effect the resolution.
+
+
+
+Joel Halpern                                                    [Page 7]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+6.3. Border Information
+
+   Sometimes the routing protocol will have provided the border router
+   with enough information to generate a response to an incoming NHRP
+   request.  In particular, the border router may have information about
+   IP prefix to NBMA address bindings.  If such information is present,
+   it may be used by a border router to produce an NHRP response without
+   actually propagating the request.  In such a case, that information
+   must be monitored for stability to maintain the correctness of the
+   shortcut.
+
+
+7. BGP Operation
+
+   While the NHRP mechanism described above is mostly constrained to the
+   routers within a single routing domain, the same mechanisms can be
+   used for shortcuts that span multiple domains.  In doing so, one
+   wants to produce as little additional overhead in the BGP space as
+   possible.
+
+   Therefore, we will treat the space over which BGP runs as a single
+   routing domain.  Care must be taken to propagate information across
+   the individual AS without error, and to indicate that one has
+   properly entered the BGP space.
+
+   Additional complexity in handling multi-domain shortcuts arise if
+   routing information gets aggregated at the border routers (which
+   certainly happens in practice). Since BGP is the major protocol that
+   is used to exchange routing information across multiple routing
+   domains, we'll restrict our proposal to the case where the routing
+   information exchange across domains' boundaries is controlled by BGP.
+
+   If both the source and the destination domains are on a common NBMA
+   network, and the path between these two domains is also fully within
+   the same NBMA network, then we have only three routing domains to
+   deal with: source routing domain, BGP routing domain, and destination
+   routing domain. If the destination domain is not on the same NBMA as
+   the source domain, then we need to deal only with two domains - the
+   source and the BGP. Note that we treat all routers that participate
+   in a single (common) instance of BGP as a single BGP routing domain,
+   even if these routers participate in different intra-domain routing
+   protocols, or in different instances of the same intra-domain routing
+   protocol. There are three aspects to consider.
+
+
+         (a) how a border router in the domain that the originator of
+               the Request is in handles the Request (crossing IGP/BGP
+               boundary),
+
+
+
+Joel Halpern                                                    [Page 8]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+         (b) how the Request is handled across the BGP domain, and
+               finally
+
+         (c) how a border router in the domain where the NHRP target is
+               in handles the Request (crossing BGP/IGP boundary).
+
+
+
+7.1. Handling NHRP Request at the source domain border router
+
+   When a border router receives an NHRP Request originated from within
+   its own (IGP) routing domain, the border router determines the NHRP
+   forwarding route for the NHRP target carried by the Request. If the
+   router already has the shortcut information for the forwarding route,
+   then the router uses this information to construct a Reply to the
+   source of the NHRP Request.  Otherwise, the router originates its own
+   NHRP Request.  The Request contains exactly the same NHRP target, as
+   was carried by the original Request;  The NHRP IGP Information will
+   indicate that the request was generated by BGP, and will indicate the
+   IGP of the BGP AS being entered.  While it is assumed that a BGP
+   transit AS will generally use only one IGP, the IGP information (and
+   border processing) is included to allow all cases. The newly
+   originated Request is sent to the next hop of the NHRP forwarding
+   route. Once the border router receives a Reply to its own Request,
+   the border router uses the next hop information from the Reply to
+   construct its own Reply to the source of the original NHRP Request.
+
+   If the border router later on receives a Purge message for the NHRP
+   forwarding route, the border router treats this event as if there was
+   a local change in the NHRP forwarding route (even if the there was no
+   changes in the route).
+
+   This is exactly the same behavior as all other border cases, and is
+   described here for completeness.
+
+
+7.2. Handling NHRP Request within the BGP domain
+
+   Routers within an AS will check the IGP, and perform appropriate
+   processing based on the IGP match.  In general, this will result in
+   normal forwarding of the NHRP request.
+
+   Therefore, the significant cases occur at the BGP speaking routers.
+   There are two conditions to check for, early exit of the NBMA, and
+   reachability aggregation.  Both of these conditions apply to
+   Autonomous systems that do not contain the NHRP target.
+
+
+
+
+
+Joel Halpern                                                    [Page 9]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+7.2.1. NBMA exit
+
+   The BGP router in deciding where to send the NHRP request will
+   determine what the correct exit from the autonomous system is.  It
+   will determine if that exit is within the NBMA.  If it is not within
+   the NBMA, then the router MUST respond to the NHRP request,
+   indicating its own IP and NBMA addresses as the correct termination
+   of the shortcut.  This is because the actual NBMA border device is
+   not in a position to monitor the topology properly.
+
+   BGP routers within an NBMA which are supporting R2R NHRP SHOULD be
+   configured to know where the NBMA border is. In the absence of such
+   configuration, requests from other router SHOULD be terminated at the
+   BGP router, since it can not tell what will be crossing the border.
+   A BGP router supporting R2R NHRP may be configured to assume that all
+   of its neighbors are within the NBMA, and therefore not perform such
+   early termination.
+
+
+7.2.2. Reachability Aggregation
+
+   BGP routers aggregate reachability.  If the router aggregates
+   reachability that includes the NHRP target, only this router has the
+   visibility to some of the topology changes that can affect the
+   correctness of the route.  Therefore, this router is a border router
+   for this NHRP request.
+
+   It must originate a new request, place the correct information in the
+   request, receive the response, and generate the correct response
+   towards the requester.  This aggregating router must also monitor
+   routing in case of changes which affect the request.
+
+   If the router later on receives a Purge message for the NHRP
+   forwarding route, the router treats this event as if there was a
+   change in the NHRP forwarding route (even if the there was no changes
+   in the route).
+
+   It should be noted that this conditions applies if the router COULD
+   aggregate relevant routing information, even if it currently does
+   not.
+
+
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                   [Page 10]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+7.3. Handling NHRP Request at the destination domain border router
+
+   When a border router receives an NHRP Request from a BGP speaker, and
+   the border router determines that all the destinations covered by the
+   NHRP target of the Request are within the (IGP) domain of that border
+   router, the border router determines the NHRP forwarding route for
+   the NHRP target carried by the Request. The newly formed Request
+   contains exactly the same NHRP target as the received Request; the
+   NHRP IGP Information indicates the IGP this router is using to select
+   the route to the destination.  The newly originated Request is sent
+   to the next hop of the NHRP forwarding route. Once the border router
+   receives a Reply to its own Request, the border router uses the next
+   hop information from the Reply to construct its own Reply to the
+   source of the original NHRP Request.
+
+   If the border router later on receives a Purge message for the NHRP
+   forwarding route, the border router treats this event as if there was
+   a change in the NHRP forwarding route (even if the there was no
+   changes in the route).
+
+
+8. More state, less messages
+
+   It should be possible to reduce the number of Purge messages and
+   subsequent NHRP messages (caused by the Purge messages) by
+   maintaining more state on the border routers at the source and
+   destination domains, and the BGP routers that perform aggregation
+   along the path from the source to the destination.
+
+   Specifically, on these routers it would be necessary to keep the
+   information about all the NHRP targets for which the routers maintain
+   the shortcut information.  This way when such a router determines
+   that the NHRP forwarding route (for which the router maintains the
+   shortcut information) changes due to some local routing changes, the
+   router could check whether these local changes impact forwarding to
+   the destinations covered by the NHRP targets.  For the targets that
+   are impacted by the changes the router would send Purge messages.
+
+   Note that this mechanism (maintaining NHRP targets) precludes the use
+   of Address Prefix Extension - the shortcut will be determined only
+   for the destinations covered by the NHRP target (so, if the target is
+   a single IP address, then the shortcut would be determined only for
+   this address).
+
+
+
+
+
+
+
+
+Joel Halpern                                                   [Page 11]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+9. NHRP IGP Information Extension 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
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   0-3  |C|u|        Type = 9           |        Length = 4             |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   4-7  |  flags      |b| Reserved      |        IGP ID                 |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+         C "Compulsory." If clear, and the NHS does not recognize the
+               type code, the extension maybe safely be ignored.  For
+               the IGP Information extension, this bit is clear.
+
+         u Unused and must be set to zero
+
+         Type The extension type code.  For the IGP Information
+               extension, this is 9.
+
+         Length the length in octets of the value.  For this extension,
+               this is 4.
+
+         flags Other than the "b" flag, these are reserved, SHALL be set
+               to 0 on transmission, and SHALL be ignored on reception.
+
+         b This flag indicates whether the request (or a predecessor
+               thereof) was originated by a BGP speaker.  Set (to 1) to
+               indicate that the BGP speaker has operated on this.
+               Clear (to 0) if not.
+
+         IGP ID This field indicates the IGP used by the request
+               originator.  The currently defined values are:
+
+                                    1 = RIP
+                                    2 = RIPv2
+                                    3 = OSPF
+                                    4 = Dual IS-IS
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                   [Page 12]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+10. IANA Considerations
+
+   This document defines an enumerated field for identifying IGPs in
+   router-to-router NHRP requests.  Since there may be additional IGPs
+   in use, a procedure is needed for allocating additional values.  The
+   IANA shall allocate values for this field as needed. Specifically,
+   when requested a value shall be allocated for an IGP for any layer 3
+   protocol for which there is a clear and stable definition of the
+   protocol.  An RFC is the best example of such stability.  Vendor
+   published specifications are also acceptable.  The IANA should avoid
+   issuing two values for the same protocol.  However, it is not
+   incumbent upon the IANA to determine if two similar protocols are
+   actually the same.
+
+
+11. Open issues
+
+   The mechanisms described in this document assume that certain routers
+   along a path taken by an NHRP Request would be required to maintain
+   state associated with the NHRP forwarding route associated with the
+   NHRP target carried by the Request. However, it is quite clear that
+   the router(s) may also lose this state. Further study of the impact
+   of losing the state is needed before advancing the use of NHRP for
+   establishing shortcuts among routers beyond Proposed Standard.
+
+   The mechanisms described in this document may result in a situation
+   where a router would be required to maintain NHRP peering with
+   potentially a fairly large number of other routers. Further study is
+   needed to understand the implications of this on the scalability of
+   the approach where NHRP is used to establish shortcuts among routers.
+
+   This document doesn't have a proof that the mechanisms described here
+   result in loop-free steady state forwarding when NHRP is used to
+   establish shortcuts among routers, however, a counterexample has not
+   yet been found.  Further analysis should be done as part of advancing
+   beyond Proposed Standard.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                   [Page 13]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+12. Security Considerations
+
+   Security is provided in the base NHRP protocol, using hop-by-hop
+   authentication.  There is no change to the fundamental security
+   capabilities provided therein when these extensions are used.  It
+   should be noted that the assumption of transitive trust that is the
+   basis of such security may well be significantly weaker in an inter-
+   domain environment, and administrators of border routers should take
+   this into consideration.  The hop-by-hop security model is used by
+   NHRP originally because there is no end-to-end security association
+   between the requesting and responding NHRP entities.  In this
+   environment there is the additional facet that intermediate NHS are
+   modifying the prefix length field of the CIE, thus changing the end-
+   to-end information.
+
+
+13. References
+
+   [1]  J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy.,
+   "NBMA Next Hop Resolution Protocol", RFC-2332, USC/Information
+   Sciences Institute, April 1998.
+
+   [2] D. Cansever., "NHRP Protocol Applicability Statement", RFC-2333,
+   USC/Information Sciences Institute, April 1998
+
+   [3] S. Bradner., "Key words for use in RFCs to Indicate Requirement
+   Levels", RFC-2119, USC/Information Sciences Institute, March 1997.
+
+
+14. Acknowledgements
+
+   The authors wish to Thank Curtis Villamizer for his contributions
+   emphasizing both the importance of the looping cases, and some
+   examples of when loops can occur.
+
+
+15. Author Information
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                   [Page 14]
+
+Internet Draft       draft-ietf-ion-r2r-nhrp-03.txt             May 1998
+
+
+   Joel M. Halpern
+   Institutional Venture Partners
+   3000 Sand Hill Road
+   Menlo Park, CA
+   Phone: (650) 926-5633
+   email: joel@mcquillan.com
+
+   Yakov Rekhter
+   cisco Systems, Inc.
+   170 Tasman Dr.
+   San Jose, CA 95134
+   Phone: (914) 528-0090
+   email: yakov@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joel Halpern                                                   [Page 15]
+
\ No newline at end of file
diff --git a/doc/rfc2332.txt b/doc/rfc2332.txt
new file mode 100644
index 0000000..eb79ee3
--- /dev/null
+++ b/doc/rfc2332.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Network Working Group                                         J. Luciani
+Request for Comments: 2332                                  Bay Networks
+Category: Standards Track                                        D. Katz
+                                                           cisco Systems
+                                                           D. Piscitello
+                                                   Core Competence, Inc.
+                                                                 B. Cole
+                                                        Juniper Networks
+                                                            N. Doraswamy
+                                                            Bay Networks
+                                                              April 1998
+
+
+                NBMA Next Hop Resolution Protocol (NHRP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+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.
+
+   Note that while this protocol was developed for use with NBMA
+   subnetworks, it is possible, if not likely, that it will be applied
+   to BMA subnetworks as well.  However, this usage of NHRP is for
+   further study.
+
+   This document is intended to be a functional superset of the NBMA
+   Address Resolution Protocol (NARP) documented in [1].
+
+
+
+
+Luciani, et. al.            Standards Track                     [Page 1]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   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 (see [13]).
+
+1. Introduction
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [15].
+
+   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.
+
+   One way to model an NBMA network is by using the notion of logically
+   independent IP 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 of a LIS are directly connected to the same
+          NBMA subnetwork.
+
+      3)  All hosts and routers outside of the LIS are accessed via
+          a router.
+
+      4)  All members of a LIS access each other directly (without
+          routers).
+
+   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
+
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                     [Page 2]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   configurations, hop-by-hop address resolution may not be sufficient
+   to resolve the "NBMA next hop" toward the destination station, and IP
+   packets may have multiple IP hops through the NBMA 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 while with the LIS model the outcome of the
+   "local/remote" forwarding decision is driven purely by addressing
+   information, with the LAG model the outcome of this decision is
+   decoupled from the 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. Within the parameters described in this document, NHRP
+   describes such a mechanism.  For example, when the 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 (in a connection-oriented NBMA subnetwork such as ATM).
+
+   Use of NHRP may be sufficient for hosts 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 with
+   existing ARP services [14].
+
+
+
+
+
+Luciani, et. al.            Standards Track                     [Page 3]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   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 (see [13]).
+
+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.)
+
+     The term "server", unless explicitly stated to the contrary, refers
+     to a Next Hop Server (NHS).  An NHS is an entity performing the
+     Next Hop Resolution Protocol service within the NBMA cloud.  An NHS
+     is always tightly coupled with a routing entity (router, route
+     server or edge device) although the converse is not yet guaranteed
+     until ubiquitous deployment of this functionality occurs.  Note
+     that the presence of intermediate routers that are not coupled with
+     an NHS entity may preclude the use of NHRP when source and
+     destination stations on different sides of such routers and thus
+     such routers may partition NHRP reachability within an NBMA
+     network.
+
+     The term "client", unless explicitly stated to the contrary, refers
+     to a Next Hop Resolution Protocol client (NHC).  An NHC is an
+     entity 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.
+
+
+
+
+
+Luciani, et. al.            Standards Track                     [Page 4]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   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 NHRP 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 support "classical" ARP service; however,
+   this will be the subject of a separate document [14].
+
+   An NHS maintains a cache which contains protocol layer address to
+   NBMA subnetwork layer address resolution information.  This cache can
+   be constructed from information obtained from NHRP Register packets
+   (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
+   packets, or through mechanisms outside the scope of this document
+   (examples of such mechanisms might include ARP[3] and pre-configured
+   tables).  Section 6.2 further describes cache management issues.
+
+   For a station within a given LIS to avoid providing NHS
+   functionality, there must be one or more NHSs within the NBMA
+   subnetwork which are providing authoritative address resolution
+   information on its behalf.  Such an NHS is said to be "serving" the
+   station.  A station on a LIS that lacks NHS functionality and is a
+   client of the NHRP service is known as NHRP Client or just NHCs.  If
+   a serving NHS is to be able to supply the address resolution
+   information for an NHC then NHSs must exist at each hop along all
+   routed paths between the NHC making the resolution request and the
+   destination NHC.  The last NHRP entity along the routed path is the
+   serving NHS; that is, NHRP Resolution Requests are not forwarded to
+   destination NHCs but rather are processed by the serving NHS.
+
+   An NHC also maintains a cache of protocol address to NBMA address
+   resolution information.  This cache is populated through information
+   obtained from NHRP Resolution Reply packets, from manual
+   configuration, or through mechanisms outside the scope of this
+   document.
+
+
+
+
+
+Luciani, et. al.            Standards Track                     [Page 5]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   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 destination's
+   address resolution information is already available in S's cache then
+   that information is used to forward the packet.  Otherwise, if the
+   next hop is reachable through one of its NBMA interfaces, S
+   constructs an NHRP 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 NHRP Resolution Reply (i.e., station S only wishes
+   to receive an NHRP Resolution Reply from an NHS serving the
+   destination NHC). Station S emits the NHRP Resolution Request packet
+   towards the destination.
+
+   If the NHRP Resolution Request is triggered by a data packet then S
+   may, while awaiting an NHRP Resolution Reply, choose to dispose of
+   the data packet in one of the following ways:
+
+     (a)  Drop the packet
+     (b)  Retain the packet until the NHRP Resolution Reply arrives
+          and a more optimal path is available
+     (c)  Forward the packet along the routed path toward D
+
+   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 NHRP Resolution Request for a given destination MUST NOT
+   be triggered on every packet.
+
+   When the NHS receives an NHRP Resolution Request, a check is made to
+   see if it serves station D.  If the NHS does not serve D, the NHS
+   forwards the NHRP Resolution Request to another NHS.  Mechanisms for
+   determining how to forward the NHRP Resolution Request are discussed
+   in Section 3.
+
+   If this NHS serves D, the NHS resolves station D's NBMA address
+   information, and generates a positive NHRP Resolution Reply on D's
+   behalf.  NHRP Resolution Replies in this scenario are always marked
+   as "authoritative".  The NHRP Resolution Reply packet contains the
+
+
+
+Luciani, et. al.            Standards Track                     [Page 6]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   address resolution information for station D which is to be 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.
+
+   A transit NHS receiving an NHRP Resolution Reply may cache the
+   address resolution information contained therein.  To a subsequent
+   NHRP Resolution Request, this NHS may respond with the cached, "non-
+   authoritative" address resolution information if the NHS is permitted
+   to do so (see Sections 5.2.2 and 6.2 for more information on non-
+   authoritative versus authoritative NHRP Resolution Replies).  Non-
+   authoritative NHRP Resolution Replies are distinguished from
+   authoritative NHRP Resolution Replies so that if a communication
+   attempt based on non-authoritative information fails, a source
+   station can choose to send an authoritative NHRP Resolution Request.
+   NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
+   cached information.
+
+   If the determination is made that no NHS in the NBMA subnetwork can
+   reply to the NHRP Resolution Request for D then a negative NHRP
+   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 NHRP Resolution Request (e.g.,
+   connectivity is lost).
+
+   NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
+   and NHRP Error Indications follow a routed path in the same fashion
+   that NHRP Resolution Requests and NHRP Resolution Replies do.
+   Specifically, "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 following exceptions: in the case of a NHRP Registration Reply
+   and in the case of an NHC initiated NHRP Purge Request, the packet is
+   always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if
+   one does not exists then one MUST be created.
+
+   NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
+   subnetwork however further study is being done in this area (see
+   Section 7).   Thus, the internetwork layer data traffic out of and
+   into an NBMA subnetwork always traverses an internetwork layer router
+   at its border.
+
+   NHRP optionally provides a mechanism to send a NHRP Resolution Reply
+   which contains aggregated address resolution information. For
+   example, suppose that router X is the next hop from station S to
+   station D and that X is an egress router for all stations sharing an
+
+
+
+Luciani, et. al.            Standards Track                     [Page 7]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   internetwork layer address prefix with station D.  When an NHRP
+   Resolution Reply is generated in response to a NHRP Resolution
+   Request, the responder may augment the internetwork layer address of
+   station D with a prefix length (see Section 5.2.0.1).  A subsequent
+   (non-authoritative) NHRP 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), 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.2 and 5.3.3).  The Route
+   Record extensions are the NHRP Forward Transit NHS Record Extension
+   and the NHRP Reverse Transit NHS Record Extension.  They contain the
+   internetwork (and subnetwork layer) addresses of all intermediate
+   NHSs between source and destination and between destination and
+   source respectively.  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 NHRP Forward Transit NHS Record Extension 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
+
+   NHRP 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 NHRP Resolution Request.
+   The NHS selection procedure typically involves applying a destination
+   protocol layer address to the protocol layer routing table which
+   causes a routing decision to be returned.  This routing decision is
+   then used to forward the NHRP Resolution Request to the downstream
+   NHS. The destination protocol layer address previously mentioned is
+   carried within the NHRP Resolution Request 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.
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                     [Page 8]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   Each NHS/router examines the NHRP 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 NHRP Resolution Request eventually arrives at a station that is
+   to generate an NHRP Resolution Reply.  This responding station
+   "serves" the destination.  The responding station generates an NHRP
+   Resolution Reply using the source protocol address from within the
+   NHRP packet to determine where the NHRP Resolution Reply should be
+   sent.
+
+   Rather than use routing to determine the next hop for an NHRP packet,
+   an NHS may use other applicable means (such as static configuration
+   information ) in order to determine to which neighboring NHSs to
+   forward the NHRP Resolution Request packet as long as such other
+   means would not cause the NHRP packet to arrive at an NHS which is
+   not along the routed path.  The use of static configuration
+   information for this purpose is beyond the scope of this document.
+
+   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
+   routers.  It is important that, in a given LIS/LAG which is using
+   NHRP, all NHSs within the LIS/LAG have at least some portion of their
+   resolution databases synchronized so that a packet arriving at one
+   router/NHS in a given LIS/LAG will be forwarded in the same fashion
+   as a packet arriving at a different router/NHS for the given LIS/LAG.
+   One method, among others, is to use the Server Cache Synchronization
+   Protocol (SCSP) [12].  It is RECOMMENDED that SCSP be the method used
+   when a LIS/LAG contains two or more router/NHSs.
+
+   During migration to NHRP, it cannot be expected that all routers
+   within the NBMA subnetwork are NHRP capable.  Thus, NHRP traffic
+   which would otherwise need to be forwarded through such routers can
+   be expected to be dropped due to the NHRP packet not being
+   recognized.  In this case, NHRP will be unable to establish any
+   transit paths whose discovery requires the traversal of the non-NHRP
+   speaking routers.  If the client has tried and failed to acquire a
+   cut through path then the client should use the network layer routed
+   path as a default.
+
+   If an NBMA technology offers a group, an anycast, or a multicast
+   addressing feature then the NHC may be configured with such an
+   address (appropriate to the routing realm it participates in) which
+   would be assigned to all NHS serving that routing realm.  This
+
+
+
+Luciani, et. al.            Standards Track                     [Page 9]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   address can then be used for establishing an initial connection to an
+   NHS to transmit a registration request.  This address may not be used
+   for sending NHRP requests.  The resulting VC may be used for NHRP
+   requests if and only if the registration response is received over
+   that VC, thereby indicating that one happens to have anycast
+   connected to an NHS serving the LIS/LAG.  In the case of non-
+   connection oriented networks, or of multicast (rather than anycast)
+   addresses, the addres MUST NOT be used for sending NHRP resolution
+   requests.
+
+   When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined
+   for the NHC directly to the NHC.  That is, the NHRP message MUST NOT
+   transit through any NHS which is not serving the NHC when the NHRP
+   message is currently at an NHS which does serve the NHC (this, of
+   course, assumes the NHRP message is destined for the NHC).  Further,
+   an NHS which serves an NHC SHOULD have a direct NBMA level connection
+   to that NHC (see Section 5.2.3 and 5.2.4 for examples).
+
+   With the exception of NHRP Registration Requests (see Section 5.2.3
+   and 5.2.4 for details of the NHRP Registration Request case), an NHC
+   MUST send NHRP messages over a direct NBMA level connection between
+   the serving NHS and the served NHC.
+
+   It may not be desirable to maintain semi-permanent NBMA level
+   connectivity between the NHC and the NHS.   In this case, when NBMA
+   level connectivity is initially setup between the NHS and the NHC (as
+   described in Section 5.2.4), the NBMA address of the NHS should be
+   obtained through the NBMA level signaling technology.  This address
+   should be stored for future use in setting up subsequent NBMA level
+   connections.  A somewhat more information rich technique to obtain
+   the address information (and more) of the serving NHS would be for
+   the NHC to include the Responder Address extension (see Section
+   5.3.1) in the NHRP Registration Request and to store the information
+   returned to the NHC in the Responder Address extension which is
+   subsequently included in the NHRP Registration Reply.  Note also
+   that, in practice, a client's default router should also be its NHS;
+   thus a client may be able to know the NBMA address of its NHS from
+   the configuration which was already required for the client to be
+   able to communicate.  Further, as mentioned in Section 4, NHCs may be
+   configured with the addressing information of one or more NHSs.
+
+4. Configuration
+
+   Next Hop Clients
+
+     An NHC connected to an NBMA subnetwork MAY be configured with the
+     Protocol address(es) and NBMA address(es) of its NHS(s).  The
+     NHS(s) will likely also represent the NHC's default or peer
+
+
+
+Luciani, et. al.            Standards Track                    [Page 10]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+     routers, so their NBMA addresses may be obtained from the NHC's
+     existing configuration.  If the NHC is attached to several
+     subnetworks (including logical NBMA subnetworks), the NHC should
+     also be configured to receive routing information from its NHS(s)
+     and peer routers so that it can determine which internetwork layer
+     networks are reachable through which subnetworks.
+
+   Next Hop Servers
+
+     An NHS is configured with knowledge of its own internetwork layer
+     and NBMA addresses.  An NHS MAY also be configured with a set of
+     internetwork layer address prefixes that correspond to the
+     internetwork layer addresses of the stations it serves. The NBMA
+     addresses of the stations served by the NHS may be learned via NHRP
+     Registration packets.
+
+     If a served NHC is attached to several subnetworks, the
+     router/route-server coresident with the serving NHS may also need
+     to be configured to advertise routing information to such NHCs.
+
+     If an NHS acts as an egress router for stations connected to other
+     subnetworks than the NBMA subnetwork, the NHS must, in addition to
+     the above, be configured to exchange routing information between
+     the NBMA subnetwork and these other subnetworks.
+
+     In all cases, routing information is exchanged using conventional
+     intra-domain and/or inter-domain routing protocols.
+
+5. NHRP Packet Formats
+
+   This section describes the format of NHRP packets.  In the following,
+   unless otherwise stated explicitly, the unqualified term "request"
+   refers generically to any of the NHRP packet types which are
+   "requests".  Further, unless otherwise stated explicitly, the
+   unqualified term "reply" refers generically to any of the NHRP packet
+   types which are "replies".
+
+   An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
+   Extensions Part.  The Fixed Part is common to all NHRP packet types.
+   The Mandatory Part MUST be present, but 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
+
+
+
+Luciani, et. al.            Standards Track                    [Page 11]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   of the Extensions Part is implied by ar$pktsz minus ar$extoff.  NHSs
+   may increase the size of an NHRP packet as a result of extension
+   processing, but not beyond the offered maximum packet size of the
+   NBMA network.
+
+   NHRP packets are actually members of a wider class of address mapping
+   and management protocols being developed by the IETF. A specific
+   encapsulation, based on the native formats used on the particular
+   NBMA network over which NHRP is carried, indicates the generic IETF
+   mapping and management protocol. For example, SMDS networks always
+   use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet
+   is preceded by the following LLC/SNAP encapsulation:
+
+   [0xAA-AA-03] [0x00-00-5E] [0x00-03]
+
+   The first three octets are LLC, indicating that SNAP follows.  The
+   SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
+   identifies the mapping and management protocol. A field in the Fixed
+   Header following the encapsulation indicates that it is NHRP.
+
+   ATM uses either LLC/SNAP encapsulation of each packet (including
+   NHRP), or uses no encapsulation on VCs dedicated to a single protocol
+   (see [7]).  Frame Relay and X.25 both use NLPID/SNAP encapsulation or
+   identification of NHRP, using 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 12]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+
+    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; i.e., if Ethertype or NLPID
+     codings exist then they are used on transmit rather than the
+
+
+
+Luciani, et. al.            Standards Track                    [Page 13]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+     ethertype.   If both Ethertype and NLPID codings exist then when
+     transmitting NHRP messages, the Ethertype coding MUST be used (this
+     is consistent with RFC 1483 coding).  So, for example, the
+     following codings exist for IP:
+
+       SNAP:      ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
+       NLPID:     ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
+       Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
+
+     and thus, since the Ethertype coding exists, it is used in
+     preference.
+
+   ar$hopcnt
+     The Hop count indicates the maximum number of NHSs that an NHRP
+     packet is allowed to traverse before being discarded.  This field
+     is used in a similar fashion to the way that a TTL is used in an IP
+     packet and should be set accordingly.  Each NHS decrements the TTL
+     as the NHRP packet transits the NHS on the way to the next hop
+     along the routed path to the destination.  If an NHS receives an
+     NHRP packet which it would normally forward to a next hop and that
+     packet contains an ar$hopcnt set to zero then the NHS sends an
+     error indication message back to the source protocol address
+     stating that the hop count has been exceeded (see Section 5.2.7)
+     and the NHS drops the packet in error;  however, an error
+     indication is never sent as a result of receiving an error
+     indication.  When a responding NHS replies to an NHRP request, that
+     NHS places a value in ar$hopcnt as if it were sending a request of
+     its own.
+
+   ar$pktsz
+     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 at
+     the fixed header.  If the packet is an odd number of bytes in
+     length then this calculation is performed as if a byte set to 0x00
+     is appended to the end of the packet.
+
+   ar$extoff
+     This field 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.
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 14]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   ar$op.version
+     This field indicates what version of generic address mapping and
+     management protocol is represented by this message.
+
+       0               MARS protocol [11].
+       1               NHRP as defined in this document.
+       0x02 - 0xEF     Reserved for future use by the IETF.
+       0xF0 - 0xFE     Allocated for use by the ATM Forum.
+       0xFF            Experimental/Local use.
+
+   ar$op.type
+     When ar$op.version == 1, this is the NHRP packet type: NHRP
+     Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
+     Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
+     Purge Reply(6), or NHRP Error Indication(7).  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 as
+     described in Section 9.
+
+   ar$shtl
+     Type & length of source NBMA address interpreted in the context of
+     the 'address family number'[6] indicated by ar$afn.  See below for
+     more details.
+
+   ar$sstl
+     Type & length of source NBMA subaddress interpreted in the context
+     of the 'address family number'[6] indicated by ar$afn.  When an
+     NBMA technology has no concept of a subaddress, the subaddress
+     length is always coded ar$sstl = 0 and no storage is allocated for
+     the subaddress in the appropriate mandatory part.  See below for
+     more details.
+
+   Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
+   T/L) and subnetwork layer subaddresses type/length fields (e.g.,
+   ar$sstl, Cli SAddr T/L) 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).
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 15]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   For NBMA technologies that use neither NSAP nor E.164 format
+   addresses, x = 0 SHALL be used to indicate the native form for the
+   particular NBMA technology.
+
+   If the NBMA network is ATM and a subaddress (e.g., Source NBMA
+   SubAddress, Client NBMA SubAddress) is to be included in any part of
+   the NHRP packet then ar$afn MUST be set to 0x000F; further, the
+   subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
+   T/L) and subnetwork layer subaddress type/length fields (e.g.,
+   ar$sstl, Cli SAddr T/L) MUST be coded as in [11].  If the NBMA
+   network is ATM and no subaddress field is to be included in any part
+   of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008
+   (E.164) accordingly.
+
+   The bottom 6 bits is an unsigned integer value indicating the length
+   of the associated NBMA address in octets. If this value is zero the
+   flag x is ignored.
+
+5.2.0 Mandatory Part
+
+   The Mandatory Part of the NHRP packet contains the operation specific
+   information (e.g., NHRP 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 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 different format
+   which is specified in that section.
+
+   The common header looks like the 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 |           Flags               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Request ID                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Source NBMA Address (variable length)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Source NBMA Subaddress (variable length)             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Source Protocol Address (variable length)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Destination  Protocol Address (variable length)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 16]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   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           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Client NBMA Address (variable length)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Client NBMA Subaddress (variable length)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Client Protocol Address (variable length)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                        .....................
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Code       | Prefix Length |         unused                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Maximum Transmission Unit    |        Holding Time           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Client NBMA Address (variable length)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Client NBMA Subaddress (variable length)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Client Protocol Address (variable length)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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.
+
+   Flags
+     These flags are specific to the given message type and they are
+     explained in each section.
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 17]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   Request ID
+     A value which, when coupled with the address of the source,
+     provides a unique identifier for the information contained in a
+     "request" packet.  This value is copied directly from an "request"
+     packet into the associated "reply".  When a sender of a "request"
+     receives "reply", it will compare the Request ID and source address
+     information in the received "reply" against that found in its
+     outstanding "request" list.  When a match is 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 "request" is transmitted.  The same value MUST be used
+     when resending a "request", i.e., when a "reply" has not been
+     received for a "request" and a retry is sent after an appropriate
+     interval.
+
+     It is RECOMMENDED that the initial value for this number be 0.  A
+     node MAY reuse a sequence number if and only if the reuse of the
+     sequence number is not precluded by use of a particular method of
+     synchronization (e.g., as described in Appendix A).
+
+   The NBMA address/subaddress form specified below allows combined
+   E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
+   subaddress concept, the subaddress field is 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 "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 "request".  If the field's length as
+     specified in ar$sstl is 0 then no storage is allocated for this
+     address at all.
+
+   For those NBMA technologies which have a notion of "Calling Party
+   Addresses", the Source NBMA Addresses above are the addresses used
+   when signaling for an SVC.
+
+   "Requests" and "indications" follow the routed path from Source
+   Protocol Address to 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 following
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 18]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   exceptions: in the case of a NHRP Registration Reply and in the case
+   of an NHC initiated NHRP Purge Request, the packet is always returned
+   via a direct VC (see Sections 5.2.4 and 5.2.5).
+
+   Source Protocol Address
+     This is the protocol address of the station which is sending the
+     "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 toward which a
+     "request" packet is sent.
+
+   Code
+     This field is message specific.  See the relevant message sections
+     below.  In general, this field is a NAK code; i.e., when the field
+     is 0 in a reply then the packet is acknowledging a request and if
+     it contains any other value the packet contains a negative
+     acknowledgment.
+
+   Prefix Length
+     This field is message specific.  See the relevant message sections
+     below.  In general, however, this fields is used to indicate that
+     the information carried in an NHRP message pertains to an
+     equivalence class of internetwork layer addresses rather than just
+     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 the
+     equivalence class.  If this field is set to 0x00 then this field
+     MUST be ignored and no equivalence information is assumed (note
+     that 0x00 is thus equivalent to 0xFF).
+
+   Maximum Transmission Unit
+     This field gives the maximum transmission unit for the relevant
+     client station.  If this value is 0 then either the default MTU is
+     used or the MTU negotiated via signaling is used if 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 CIE 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.
+
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 19]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   Cli Addr T/L
+     Type & length of next hop NBMA address specified in the CIE.  This
+     field is interpreted in the context of the 'address family
+     number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
+
+   Cli SAddr T/L
+     Type & length of next hop NBMA subaddress specified in the CIE.
+     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.
+
+   Cli Proto Len
+     This field holds the length in octets of the Client Protocol
+     Address specified in the CIE.
+
+   Preference
+     This field specifies the preference for use of the 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.
+
+   Client NBMA SubAddress
+     This is the client's NBMA subaddress.
+
+   Client Protocol Address
+     This is the client's internetworking layer address specified.
+
+   Note that an NHS may cache source address binding information from an
+   NHRP Resolution Request if and only if the conditions described in
+   Section 6.2 are met for the NHS.  In all other cases, source address
+   binding information appearing in an NHRP message MUST NOT be cached.
+
+5.2.1 NHRP Resolution Request
+
+   The NHRP Resolution Request packet has a Type code of 1. Its
+   mandatory part is coded as described in Section 5.2.0.1 and the
+   message specific meanings of the fields are as follows:
+
+   Flags - The flags field is coded as follows:
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 20]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |Q|A|D|U|S|       unused        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Q
+       Set if the station sending the NHRP Resolution Request is a
+       router; clear if the it is a host.
+
+     A
+       This bit is set in a NHRP Resolution Request if only
+       authoritative next hop information is desired and is clear
+       otherwise.  See the NHRP Resolution Reply section below for
+       further details on the "A" bit and its usage.
+
+     D
+       Unused (clear on transmit)
+
+     U
+       This is the Uniqueness bit. This bit aids in duplicate address
+       detection.  When this bit is set in an NHRP Resolution Request
+       and one or more entries exist in the NHS cache which meet the
+       requirements of the NHRP Resolution Request then only the CIE in
+       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 Resolution Request
+       because an entire subnet can be registered through use of the
+       Prefix Length in the CIE and the address of interest might be
+       within such a subnet. If the "uniqueness" bit is set and the
+       responding NHS has one or more cache entries which match the
+       request but no such cache entry has the "uniqueness" bit set,
+       then the 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 client must have the "uniqueness" bit set to zero in its NHRP
+       Resolution Request. Note that when this bit is set in an NHRP
+       Registration Request, only a single CIE may be specified in the
+       NHRP Registration Request and that CIE must have the Prefix
+       Length field set to 0xFF.
+
+     S
+       Set if the binding between the Source Protocol Address and the
+       Source NBMA information in the NHRP Resolution Request is
+       guaranteed to be stable and accurate (e.g., these addresses are
+       those of an ingress router which is connected to an ethernet stub
+       network or the NHC is an NBMA attached host).
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 21]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
+   Resolution Request.  If one is specified then that entry carries the
+   pertinent information for the client sourcing the NHRP Resolution
+   Request.  Usage of the CIE in the NHRP Resolution Request is
+   described below:
+
+     Prefix Length
+       If a CIE is specified in the NHRP Resolution Request then the
+       Prefix Length field may be used to qualify the widest acceptable
+       prefix which may be used to satisfy the NHRP Resolution Request.
+       In the case of NHRP Resolution Request/Reply, the Prefix Length
+       specifies the equivalence class of addresses which match the
+       first "Prefix Length" bit positions of the Destination Protocol
+       Address.  If the "U" bit is set in the common header then this
+       field MUST be set to 0xFF.
+
+     Maximum Transmission Unit
+       This field gives the maximum transmission unit for the source
+       station.  A possible use of this field in the NHRP Resolution
+       Request packet is for the NHRP Resolution Requester to ask for a
+       target MTU.
+
+     Holding Time
+       The Holding Time specified in the one CIE permitted to be
+       included in an NHRP Resolution Request is the amount of time
+       which the source address binding information in the NHRP
+       Resolution Request is permitted to cached by transit and
+       responding NHSs.  Note that this field may only have a non-zero
+       value if the S bit is set.
+
+     All other fields in the CIE MUST be ignored and SHOULD be set to 0.
+
+   The Destination Protocol Address in the common header of the
+   Mandatory Part of this message contains the protocol address of the
+   station for which resolution is desired.  An NHC MUST send the NHRP
+   Resolution Request directly to one of its serving NHSs (see Section 3
+   for more information).
+
+5.2.2 NHRP Resolution Reply
+
+   The NHRP Resolution Reply packet has a Type code of 2. CIEs
+   correspond to Next Hop Entries in an NHS's cache which match the
+   criteria in the NHRP Resolution Request.  Its mandatory part is coded
+   as described in Section 5.2.0.1.  The message specific meanings of
+   the fields are as follows:
+
+   Flags - The flags field is coded as follows:
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 22]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |Q|A|D|U|S|       unused        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Q
+       Copied from the NHRP Resolution Request.  Set if the NHRP
+       Resolution Requester is a router;  clear if it is a host.
+
+     A
+       Set if the next hop CIE in the NHRP Resolution Reply is
+       authoritative; clear if the NHRP Resolution Reply is non-
+       authoritative.
+
+       When an NHS receives a NHRP Resolution Request for authoritative
+       information for which it is the authoritative source, it MUST
+       respond with a NHRP Resolution Reply containing all and only
+       those next hop CIEs which are contained in the NHS's cache which
+       both match the criteria of the NHRP Resolution Request and are
+       authoritative cache entries.  An NHS is an authoritative source
+       for a NHRP Resolution Request if the information in the NHS's
+       cache matches the NHRP Resolution Request criteria and that
+       information was obtained through a NHRP Registration Request or
+       through synchronization with an NHS which obtained this
+       information through a NHRP Registration Request.  An
+       authoritative cache entry is one which is obtained through a NHRP
+       Registration Request or through synchronization with an NHS which
+       obtained this information through a NHRP Registration Request.
+
+       An NHS obtains non-authoritative CIEs through promiscuous
+       listening to NHRP packets other than NHRP Registrations which are
+       directed at it.  A NHRP Resolution Request which indicates a
+       request for non-authoritative information should cause a NHRP
+       Resolution Reply which contains all entries in the replying NHS's
+       cache (i.e., both authoritative and non-authoritative) which
+       match the criteria specified in the request.
+
+     D
+       Set if the association between destination and the associate next
+       hop information included in all CIEs of the NHRP Resolution Reply
+       is guaranteed to be stable for the lifetime of the information
+       (the holding time).  This is the case if the Next Hop protocol
+       address in a CIE 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
+
+
+
+Luciani, et. al.            Standards Track                    [Page 23]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+       when the destination is immediately adjacent to the egress router
+       through a non-NBMA interface).
+
+     U
+       This is the Uniqueness bit. See the NHRP Resolution Request
+       section above for details.  When this bit is set, only one CIE is
+       included since only one unique binding should exist in an NHS's
+       cache.
+
+     S
+       Copied from NHRP Resolution Request message.
+
+   One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
+   contains NHRP next hop information which the responding NHS has
+   cached and which matches the parameters specified in the NHRP
+   Resolution Request.  If no match is found by the NHS issuing the NHRP
+   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 use of NHRP by
+   minimal client implementations, the first CIE MUST contain the next
+   hop with the highest preference value so that such an implementation
+   need parse only a single CIE.
+
+     Code
+       If this field is set to zero then this packet contains a
+       positively acknowledged NHRP Resolution Reply.  If this field
+       contains any other value then this message contains an NHRP
+       Resolution Reply NAK which means that an appropriate
+       internetworking layer to NBMA address binding was not available
+       in the responding NHS's cache.  If NHRP Resolution Reply contains
+       a Client Information Entry with a NAK Code other than 0 then it
+       MUST NOT contain any other CIE.  Currently defined NAK Codes are
+       as follows:
+
+       4 - Administratively Prohibited
+
+         An NHS may refuse an NHRP Resolution Request attempt for
+         administrative reasons (due to policy constraints or routing
+         state).  If so, the NHS MUST send an NHRP Resolution Reply
+         which contains a NAK code of 4.
+
+       5 - Insufficient Resources
+
+         If an NHS cannot serve a station due to a lack of resources
+         (e.g., can't store sufficient information to send a purge if
+         routing changes), the NHS MUST reply with a NAKed NHRP
+         Resolution Reply which contains a NAK code of 5.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 24]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+       12 - No Internetworking Layer Address to NBMA Address Binding
+            Exists
+
+         This code states that there were absolutely no internetworking
+         layer address to NBMA address bindings found in the 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 responding
+         NHS's cache, however none of them had the uniqueness bit set.
+
+     Prefix Length
+       In the case of NHRP Resolution Reply, the Prefix Length specifies
+       the equivalence class of addresses which match the first "Prefix
+       Length" bit positions of the Destination Protocol Address.
+
+     Holding Time
+       The Holding Time specified in a CIE of an NHRP Resolution Reply
+       is the amount of time remaining before the expiration of the
+       client information which is cached at the replying NHS.  It is
+       not the value which was registered by the client.
+
+     The remainder of the fields for the CIE for each next hop are
+     filled out as they were defined when the next hop was registered
+     with the responding NHS (or one of the responding NHS's
+     synchronized servers) via the NHRP Registration Request.
+
+   Load-splitting may be performed when more than one Client Information
+   Entry is returned to a requester when equal preference values are
+   specified.  Also, the alternative addresses may be used in case of
+   connectivity failure in the NBMA subnetwork (such as a failed call
+   attempt in connection-oriented NBMA subnetworks).
+
+   Any extensions present in the NHRP Resolution Request packet MUST be
+   present in the NHRP Resolution Reply even if the extension is non-
+   Compulsory.
+
+   If an unsolicited NHRP Resolution Reply packet is received, an Error
+   Indication of type Invalid NHRP Resolution Reply Received SHOULD be
+   sent in response.
+
+   When an NHS that serves a given NHC receives an NHRP Resolution Reply
+   destined for that NHC then the NHS must MUST send the NHRP Resolution
+   Reply directly to the NHC (see Section 3).
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 25]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+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 has a Type code
+   of 3. Each CIE corresponds to Next Hop information which is to be
+   cached at an NHS.  The mandatory part of an NHRP Registration Request
+   is coded as described in Section 5.2.0.1.  The message specific
+   meanings of the fields are as follows:
+
+   Flags - The flags field is coded as follows:
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |U|         unused              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     U
+       This is the Uniqueness bit. When set in an NHRP Registration
+       Request, this bit indicates that the registration of the protocol
+       address is unique within the confines of the set of synchronized
+       NHSs.  This "uniqueness" qualifier MUST be stored in the NHS/NHC
+       cache.  Any attempt to register a binding between the protocol
+       address and an NBMA address when this bit is set MUST be rejected
+       with a Code of "14 - Unique Internetworking Layer Address Already
+       Registered" if the replying NHS already has a cache entry for the
+       protocol address and the cache entry has the "uniqueness" bit
+       set.  A registration of a CIE's information is rejected when the
+       CIE is returned with the Code field set to anything other than
+       0x00.  See the description of the uniqueness bit in NHRP
+       Resolution Request section above for further details.  When this
+       bit is set only, only one CIE MAY be included in the NHRP
+       Registration Request.
+
+   Request ID
+     The request ID has the same meaning as described in Section
+     5.2.0.1.  However, the request ID for NHRP Registrations which is
+     maintained at each client MUST be kept in non-volatile memory so
+     that when a client crashes and reregisters there will be no
+     inconsistency in the NHS's database.  In order to reduce the
+     overhead associated with updating non-volatile memory, the actual
+     updating need not be 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 value of the Request ID in the non-volatile memory
+     before using the Request ID for subsequent registrations.
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 26]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   One or more CIEs are specified in the NHRP Registration Request.
+   Each CIE contains next hop information which a client is attempting
+   to 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
+   NHRP Registration Request then it MAY code the Cli Addr T/L, Cli
+   SAddr T/L, and Cli Proto Len as zero which signifies that the client
+   address information is to be taken from the source information in the
+   common header (see Section 5.2.0.1).  Below, further clarification is
+   given for some fields in a CIE in the context of a NHRP Registration
+   Request.
+
+     Code
+       This field is set to 0x00 in NHRP Registration Requests.
+
+     Prefix Length
+
+       This field may be used in a NHRP Registration Request to register
+       equivalence information for the Client Protocol Address specified
+       in the CIE of an NHRP Registration Request In the case of NHRP
+       Registration Request, the Prefix Length specifies the equivalence
+       class of addresses which match the first "Prefix Length" bit
+       positions of the Client Protocol Address.  If the "U" bit is set
+       in the common header then this field MUST be set to 0xFF.
+
+   The NHRP Registration Request is used to register an NHC's NHRP
+   information with its NHSs.  If an NHC is configured with the protocol
+   address of a serving NHS then the NHC may place the NHS's protocol
+   address in the Destination Protocol Address field of the NHRP
+   Registration Request common header otherwise the NHC must place its
+   own protocol address in the Destination Protocol Address field.
+
+   When an NHS receives an NHRP Registration Request which has the
+   Destination Protocol Address field set to an address which belongs to
+   a LIS/LAG for which the NHS is serving then if the Destination
+   Protocol Address field is equal to the Source Protocol Address field
+   (which would happen if the NHC put its protocol address in the
+   Destination Protocol Address) or the Destination Protocol Address
+   field is equal to the protocol address of the NHS then the NHS
+   processes the NHRP Registration Request after doing appropriate error
+   checking (including any applicable policy checking).
+
+   When an NHS receives an NHRP Registration Request which has the
+   Destination Protocol Address field set to an address which does not
+   belong to a LIS/LAG for which the NHS is serving then the NHS
+   forwards the packet down the routed path toward the appropriate
+   LIS/LAG.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 27]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   When an NHS receives an NHRP Registration Request which has the
+   Destination Protocol Address field set to an address which belongs to
+   a LIS/LAG for which the NHS is serving then if the Destination
+   Protocol Address field does not equal the Source Protocol Address
+   field and the Destination Protocol Address field does not equal the
+   protocol address of the NHS then the NHS forwards the message to the
+   appropriate NHS within the LIS/LAG as specified by Destination
+   Protocol Address field.
+
+   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 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 to a lack of resources, the NHS
+   MUST reply with a NAK-ed Registration Reply of type Registration
+   Overflow.
+
+   In order to keep the registration entry from being discarded, the
+   station MUST re-send the NHRP Registration Request packet often
+   enough to refresh the registration, even in the face of occasional
+   packet loss. It is recommended that the NHRP Registration 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 to a client in response
+   to that client's NHRP Registration Request. If the Code field of a
+   CIE in the NHRP Registration Reply has anything other than zero in it
+   then the NHRP Registration Reply is a NAK otherwise the reply is an
+   ACK.  The NHRP Registration Reply has a Type code of 4.
+
+   An NHRP Registration Reply is formed from an NHRP Registration
+   Request by changing the type code to 4, updating the CIE Code field,
+   and filling in the appropriate extensions if they exist.  The message
+   specific meanings of the fields are as follows:
+
+   Attempts to register the information in the CIEs of an NHRP
+   Registration Request may fail for various reasons.  If this is the
+   case then each failed attempt to register the information in a CIE of
+   an NHRP Registration Request is logged in the associated NHRP
+   Registration Reply by setting the CIE Code field to the appropriate
+   error code as shown below:
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 28]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+     CIE Code
+
+       0 - Successful Registration
+
+         The information in the CIE was successfully registered with the
+         NHS.
+
+       4 - Administratively Prohibited
+
+         An NHS may refuse an NHRP Registration Request attempt for
+         administrative reasons (due to policy constraints or routing
+         state).  If so, the NHS MUST send an NHRP Registration Reply
+         which contains a NAK code of 4.
+
+       5 - Insufficient Resources
+
+         If an NHS cannot serve a station due to a lack of resources,
+         the NHS MUST reply with a NAKed NHRP Registration Reply which
+         contains a NAK code of 5.
+
+       14 - Unique Internetworking Layer Address Already Registered
+         If a client tries to register a protocol address to NBMA
+         address binding with the uniqueness bit on and the protocol
+         address already exists in the NHS's cache then if that cache
+         entry also has the uniqueness bit on then this NAK Code is
+         returned in the CIE in the NHRP Registration Reply.
+
+   Due to the possible existence of asymmetric routing, an NHRP
+   Registration Reply may not be able to merely follow the routed path
+   back to the source protocol address specified in the common header of
+   the NHRP Registration Reply.  As a result, there MUST exist a direct
+   NBMA level connection between the NHC and its NHS on which to send
+   the NHRP Registration Reply before NHRP Registration Reply may be
+   returned to the NHC.  If such a connection does not exist then the
+   NHS must setup such a connection to the NHC by using the source NBMA
+   information supplied in the common header of the NHRP Registration
+   Request.
+
+5.2.5 NHRP Purge Request
+
+   The NHRP Purge Request packet is sent in order to invalidate cached
+   information in a station.  The NHRP Purge Request packet has a type
+   code of 5.  The mandatory part of an NHRP Purge Request is coded as
+   described in Section 5.2.0.1.  The message specific meanings of the
+   fields are as follows:
+
+   Flags - The flags field is coded as follows:
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 29]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |N|         unused              |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     N
+       When set, this bit tells the receiver of the NHRP Purge Request
+       that the requester does not expect to receive an NHRP Purge
+       Reply.  If an unsolicited NHRP Purge Reply is received by a
+       station where that station is identified in the Source Protocol
+       Address of the packet then that packet must be ignored.
+
+   One or more CIEs are specified in the NHRP Purge Request.  Each CIE
+   contains next hop information which is to be purged from an NHS/NHC
+   cache.  Generally, all fields in CIEs enclosed in NHRP Purge Requests
+   are coded as described in Section 5.2.0.1.  Below, further
+   clarification is given for some fields in a CIE in the context of a
+   NHRP Purge Request.
+
+     Code
+       This field is set to 0x00 in NHRP Purge Requests.
+
+     Prefix Length
+
+       In the case of NHRP Purge Requests, the Prefix Length specifies
+       the equivalence class of addresses which match the first "Prefix
+       Length" bit positions of the Client Protocol Address specified in
+       the CIE.  All next hop information which contains a protocol
+       address which matches an element of this equivalence class is to
+       be purged from the receivers cache.
+
+     The Maximum Transmission Unit and Preference fields of the CIE are
+     coded as zero.  The Holding Time should be coded as zero but there
+     may be some utility in supplying a "short" holding time to be
+     applied to the matching next hop information before that
+     information would be purged; this usage is for further study. The
+     Client Protocol Address field and the Cli Proto Len field MUST be
+     filled in.  The Client Protocol Address is filled in with the
+     protocol address to be purged from the receiving station's cache
+     while the Cli Proto Len is set the length of the purged client's
+     protocol address.  All remaining fields in the CIE MAY be set to
+     zero although the client NBMA information (and associated length
+     fields) MAY be specified to narrow the scope of the NHRP Purge
+     Request if requester desires.  However, the receiver of an NHRP
+     Purge Request may choose to ignore the Client NBMA information if
+     it is supplied.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 30]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   An NHRP Purge Request packet is sent from an NHS to a station to
+   cause it to delete previously cached information.  This is done when
+   the information may be no longer valid (typically when the NHS has
+   previously provided next hop information for a station that is not
+   directly connected to the NBMA subnetwork, and the egress point to
+   that station may have changed).
+
+   An NHRP Purge Request packet may also be sent from an NHC to an NHS
+   with which the NHC had previously registered.  This allows for an NHC
+   to invalidate its registration with NHRP before it would otherwise
+   expire via the holding timer. If an NHC does not have knowledge of a
+   protocol address of a serving NHS then the NHC must place its own
+   protocol address in the Destination Protocol Address field and
+   forward the packet along the routed path.  Otherwise, the NHC must
+   place the protocol address of a serving NHS in this field.
+
+   Serving NHSs may need to send one or more new NHRP Purge Requests as
+   a result of receiving a purge from one of their served NHCs since the
+   NHS may have previously responded to NHRP Resolution Requests for
+   that NHC's NBMA information.  These purges are "new" in that they are
+   sourced by the NHS and not the NHC;  that is, for each NHC that
+   previously sent a NHRP Resolution Request for the purged NHC NBMA
+   information, an NHRP Purge Request is sent which contains the Source
+   Protocol/NBMA Addresses of the NHS and the Destination Protocol
+   Address of the NHC which previously sent an NHRP Resolution Request
+   prior to the purge.
+
+   The station sending the NHRP Purge Request MAY periodically
+   retransmit the NHRP Purge Request until either NHRP Purge Request is
+   acknowledged or until the holding time of the information being
+   purged has expired. Retransmission strategies for NHRP Purge Requests
+   are a local matter.
+
+   When a station receives an NHRP Purge Request, it MUST discard any
+   previously cached information that matches the information in the
+   CIEs.
+
+   An NHRP Purge Reply MUST be returned for the NHRP Purge Request even
+   if the station does not have a matching cache entry assuming that the
+   "N" bit is off in the NHRP Purge Request.
+
+   If the station wishes to reestablish communication with the
+   destination shortly after receiving an NHRP Purge Request, it should
+   make an authoritative NHRP Resolution Request in order to avoid any
+   stale cache entries that might be present in intermediate NHSs (See
+   section 6.2.2.).  It is recommended that authoritative NHRP
+   Resolution Requests be made for the duration of the holding time of
+   the old information.
+
+
+
+Luciani, et. al.            Standards Track                    [Page 31]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+5.2.6 NHRP Purge Reply
+
+   The NHRP Purge Reply packet is sent in order to assure the sender of
+   an NHRP Purge Request that all cached information of the specified
+   type has been purged from the station sending the reply.  The NHRP
+   Purge Reply has a type code of 6.
+
+   An NHRP Purge Reply is formed from an NHRP Purge Request by merely
+   changing the type code in the request to 6.  The packet is then
+   returned to the requester after filling in the appropriate extensions
+   if they exist.
+
+5.2.7  NHRP Error Indication
+
+   The NHRP Error Indication is used to convey error indications to the
+   sender of an NHRP packet.  It has a type code of 7.  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 |            unused             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Error Code          |        Error Offset           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Source NBMA Address (variable length)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Source NBMA Subaddress (variable length)             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Source Protocol Address (variable length)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Destination  Protocol Address (variable length)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Contents of NHRP Packet in error (variable length)      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Src Proto Len
+     This field holds the length in octets of the Source Protocol
+     Address.
+
+   Dst Proto Len
+     This field holds the length in octets of the Destination Protocol
+     Address.
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 32]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   Error Code
+     An error code indicating the type of error detected, chosen from
+     the following list:
+
+       1 - Unrecognized Extension
+
+         When the Compulsory bit of an extension in NHRP packet is set,
+         the NHRP packet cannot be processed unless the extension has
+         been processed.  The responder MUST return an NHRP Error
+         Indication of type Unrecognized Extension if it is incapable of
+         processing the extension.  However, if a transit NHS (one which
+         is not going to generate a reply) detects an unrecognized
+         extension, it SHALL ignore the extension.
+
+       3 - NHRP Loop Detected
+
+         A Loop Detected error is generated when it is determined that
+         an NHRP packet is being forwarded in a loop.
+
+       6 - Protocol Address Unreachable
+
+         This error occurs when a packet it moving along the routed path
+         and it reaches a point such that the protocol address of
+         interest is not reachable.
+
+       7 - Protocol Error
+
+         A generic packet processing error has occurred (e.g., invalid
+         version number, invalid protocol type, failed checksum, etc.)
+
+       8 - NHRP SDU Size Exceeded
+
+         If the SDU size of the NHRP packet exceeds the MTU size of the
+         NBMA network then this error is returned.
+
+       9 - Invalid Extension
+
+         If an NHS finds an extension in a packet which is inappropriate
+         for the packet type, an error is sent back to the sender with
+         Invalid Extension as the code.
+
+       10 - Invalid NHRP Resolution Reply Received
+
+         If a client receives a NHRP Resolution Reply for a Next Hop
+         Resolution Request which it believes it did not make then an
+         error packet is sent to the station making the reply with an
+         error code of Invalid Reply Received.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 33]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+       11 - Authentication Failure
+
+         If a received packet fails an authentication test then this
+         error is returned.
+
+       15 - Hop Count Exceeded
+
+         The hop count which was specified in the Fixed Header of an
+         NHRP message has been exceeded.
+
+   Error Offset
+     The offset in octets into the original NHRP packet in which an
+     error was detected.  This offset is calculated starting from the
+     NHRP Fixed Header.
+
+   Source NBMA Address
+     The Source NBMA address field is the address of the station which
+     observed the error.
+
+   Source NBMA SubAddress
+     The Source NBMA subaddress field is the address of the station
+     which observed the error.  If the field's length as specified in
+     ar$sstl is 0 then no storage is allocated for this address at all.
+
+   Source Protocol Address
+     This is the protocol address of the station which issued the Error
+     packet.
+
+   Destination 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 packet SHALL NEVER be generated in response
+   to another NHRP Error Indication packet.  When an NHRP Error
+   Indication packet is generated, the offending NHRP packet SHALL be
+   discarded.  In no case should more than one NHRP Error Indication
+   packet be generated for a single NHRP packet.
+
+   If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA
+   and Source Protocol address fields of a transiting NHRP Error
+   Indication packet then the NHS will quietly drop the packet and do
+   nothing (this scenario would occur when the NHRP Error Indication
+   packet was itself in a loop).
+
+   Note that no extensions may be added to an NHRP Error Indication.
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 34]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+5.3  Extensions Part
+
+   The Extensions Part, if present, carries one or more extensions in
+   {Type, Length, Value} triplets.
+
+   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               |        Length                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Value...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   C
+     "Compulsory."  If clear, and the NHS does not recognize the type
+     code, the extension may safely be ignored.  If set, and the NHS
+     does not recognize the type code, the NHRP "request" is considered
+     to be in error.  (See below for 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 in octets of the value (not including the Type and
+     Length fields;  a null extension will have only an extension header
+     and a length of zero).
+
+   When extensions exist, the extensions list is terminated by the Null
+   TLV, having Type = 0 and Length = 0.
+
+   Extensions may occur in any order, but any particular extension type
+   may occur only once in an NHRP packet unless explicitly stated to the
+   contrary in the extensions definition.  For example, the vendor-
+   private extension may occur multiple times in a packet in order to
+   allow for extensions which do not share the same vendor ID to be
+   represented.  It is RECOMMENDED that a given vendor include no more
+   than one Vendor Private Extension.
+
+   An NHS MUST NOT change the order of extensions.  That is, the order
+   of extensions placed in an NHRP packet by an NHC (or by an NHS when
+   an NHS sources a packet) MUST be preserved as the packet moves
+   between NHSs.  Minimal NHC implementations MUST only recognize, but
+
+
+
+Luciani, et. al.            Standards Track                    [Page 35]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   not necessarily parse, the Vendor Private extension and the End Of
+   Extensions extension.  Extensions are only present in a "reply" if
+   they were present in the corresponding "request" with the exception
+   of Vendor Private extensions.  The previous statement is not intended
+   to preclude the creation of NHS-only extensions which might be added
+   to and removed from NHRP packets by the same NHS; such extensions
+   MUST not be propagated to NHCs.
+
+   The Compulsory bit provides for a means to add to the extension set.
+   If the bit is set in an extension then the station responding to the
+   NHRP message which contains that extension MUST be able to understand
+   the extension (in this case, the station responding to the message is
+   the station that would issue an NHRP reply in response to a NHRP
+   request).  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 be returned,
+   unchanged, in the corresponding "reply" packet type.
+
+   If a transit NHS (one which is not going to generate a "reply")
+   detects an unrecognized extension, it SHALL ignore the extension.  If
+   the Compulsory bit is set, the transit NHS MUST NOT cache the
+   information contained in the packet and MUST NOT identify itself as
+   an egress router (in the Forward Record or Reverse Record
+   extensions).  Effectively, this means, if a transit NHS encounters an
+   extension which it cannot process and which has the Compulsory bit
+   set then that NHS MUST NOT participate in any way in the protocol
+   exchange other than acting as a forwarding agent.
+
+   The NHRP extension Type space is subdivided to encourage use outside
+   the IETF.
+
+     0x0000 - 0x0FFF         Reserved for NHRP.
+     0x1000 - 0x11FF         Allocated to the ATM Forum.
+     0x1200 - 0x37FF         Reserved for the IETF.
+     0x3800 - 0x3FFF         Experimental use.
+
+   IANA will administer the ranges reserved for the IETF as described in
+   Section 9. Values in the 'Experimental use' range have only local
+   significance.
+
+5.3.0  The End Of Extensions
+
+    Compulsory = 1
+    Type = 0
+    Length = 0
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 36]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   When extensions exist, the extensions list is terminated by the End
+   Of Extensions/Null TLV.
+
+5.3.1  Responder Address Extension
+
+    Compulsory = 1
+    Type = 3
+    Length = variable
+
+   This extension is used to determine the address of the NHRP
+   responder; i.e., the entity that generates the appropriate "reply"
+   packet for a given "request" packet.  In the case of an NHRP
+   Resolution Request, the station responding may be different (in the
+   case of cached replies) than the system identified in the Next Hop
+   field of the NHRP Resolution Reply.  Further, this extension may aid
+   in detecting loops in the NHRP forwarding path.
+
+   This extension uses a single CIE with the extension specific meanings
+   of the fields set as follows:
+
+   The Prefix Length fields MUST be set to 0 and ignored.
+
+   CIE Code
+     5 - Insufficient Resources
+       If the responder to an NHRP Resolution Request is an egress point
+       for the target of the address resolution request (i.e., it is one
+       of the stations identified in the list of CIEs in an NHRP
+       Resolution Reply) and the Responder Address extension is included
+       in the NHRP Resolution Request and insufficient resources to
+       setup a cut-through VC exist at the responder then the Code field
+       of the Responder Address Extension is set to 5 in order to tell
+       the client that a VC setup attempt would in all likelihood be
+       rejected; otherwise this field MUST be coded as a zero.  NHCs MAY
+       use this field to influence whether they attempt to setup a cut-
+       through to the egress router.
+
+   Maximum Transmission Unit
+     This field gives the maximum transmission unit preferred by the
+     responder.  If this value is 0 then either the default MTU is used
+     or the MTU negotiated via signaling is used if such negotiation is
+     possible for the given NBMA.
+
+   Holding Time
+     The Holding Time field specifies the number of seconds for which
+     the NBMA information of the responser is considered to be valid.
+     Cached information SHALL be discarded when the holding time
+     expires.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 37]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   "Client Address" information is actually "Responder Address"
+   information for this extension.  Thus, for example, Cli Addr T/L is
+   the responder NBMA address type and length field.
+
+   If a "requester" desires this information, the "requester" SHALL
+   include this extension with a 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 address, it SHALL use the same protocol address
+   consistently in all of the Responder Address, Forward Transit NHS
+   Record, and Reverse Transit NHS Record extensions.  The choice of
+   which of several protocol address to include in this extension is a
+   local matter.
+
+   If an NHRP Resolution Reply packet being forwarded by an NHS contains
+   a protocol address of that NHS in the Responder Address Extension
+   then that NHS SHALL generate an NHRP Error Indication of type "NHRP
+   Loop Detected" and discard the NHRP Resolution Reply.
+
+   If an NHRP 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 the address in the Next
+   Hop field).
+
+5.3.2  NHRP Forward Transit NHS Record Extension
+
+    Compulsory = 1
+    Type = 4
+    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 extension length field and the
+   ar$chksum fields SHALL be adjusted appropriately.
+
+   The responding NHS, as described in Section 5.3.1, 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 Address.
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 38]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   This extension uses a single CIE per NHS Record element with the
+   extension specific meanings of the fields set as follows:
+
+   The Prefix Length fields MUST be set to 0 and ignored.
+
+   CIE Code
+     5 - Insufficient Resources
+       If an NHRP Resolution Request contains an NHRP Forward Transit
+       NHS Record Extension and insufficient resources to setup a cut-
+       through VC exist at the current transit NHS then the CIE Code
+       field for NHRP Forward Transit NHS Record Extension is set to 5
+       in order to tell the client that a VC setup attempt would in all
+       likelihood be rejected; otherwise this field MUST be coded as a
+       zero.  NHCs MAY use this field to influence whether they attempt
+       to setup a cut-through as described in Section 2.2.  Note that
+       the NHRP Reverse Transit NHS Record Extension MUST always have
+       this field set to zero.
+
+   Maximum Transmission Unit
+     This field gives the maximum transmission unit preferred by the
+     transit NHS.  If this value is 0 then either the default MTU is
+     used or the MTU negotiated via signaling is used if such
+     negotiation is possible for the given NBMA.
+
+   Holding Time
+     The Holding Time field specifies the number of seconds for which
+     the NBMA information of the transit NHS is considered to be valid.
+     Cached information SHALL be discarded when the holding time
+     expires.
+
+   "Client Address" information is actually "Forward Transit NHS
+   Address" information for this extension.  Thus, for example, Cli Addr
+   T/L is the transit NHS NBMA address type and length field.
+
+   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 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.
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 39]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   If a "request" that is 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 "request".
+
+5.3.3  NHRP Reverse Transit NHS Record Extension
+
+    Compulsory = 1
+    Type = 5
+    Length = variable
+
+   The NHRP Reverse Transit NHS record contains a list of transit NHSs
+   through which a "reply" has traversed.  Each NHS SHALL append 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 responding NHS, as described in Section 5.3.1, 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 Address.
+
+   This extension uses a single CIE per NHS Record element with the
+   extension specific meanings of the fields set as follows:
+
+   The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
+
+   Maximum Transmission Unit
+     This field gives the maximum transmission unit preferred by the
+     transit NHS.  If this value is 0 then either the default MTU is
+     used or the MTU negotiated via signaling is used if such
+     negotiation is possible for the given NBMA.
+
+   Holding Time
+     The Holding Time field specifies the number of seconds for which
+     the NBMA information of the transit NHS is considered to be valid.
+     Cached information SHALL be discarded when the holding time
+     expires.
+
+   "Client Address" information is actually "Reverse Transit NHS
+   Address" information for this extension.  Thus, for example, Cli Addr
+   T/L is the transit NHS NBMA address type and length field.
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 40]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   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 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 "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 this information may be cached at intermediate NHSs;  if
+   so, the cached value SHALL be used when generating a reply.
+
+5.3.4 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" only.
+
+   The authentication is always done pairwise on an NHRP hop-by-hop
+   basis;  i.e., the authentication extension is regenerated at each
+   hop.  If a received packet fails the authentication test, the station
+   SHALL generate an Error Indication of type "Authentication Failure"
+   and discard the packet. Note that one possible authentication failure
+   is the lack of an Authentication Extension; the presence or absence
+   of the Authentication Extension is a local matter.
+
+5.3.4.1 Header Format
+
+   The authentication header has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 41]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Reserved                    | Security Parameter Index (SPI)|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Src Addr...                                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Security Parameter Index (SPI) can be thought of as an index into a
+   table that maintains the keys and other information such as hash
+   algorithm. Src and Dst communicate either offline using manual keying
+   or online using a key management protocol to populate this table. The
+   sending NHRP entity always allocates the SPI and the parameters
+   associated with it.
+
+   Src Addr a variable length field is the address assigned to the
+   outgoing interface. The length of the addr is obtained from the
+   source protocol length field in the mandatory part of the NHRP
+   header.  The tuple <spi, src addr> uniquely identifies the key and
+   other parameters that are used in authentication.
+
+   The length of the authentication data field  is dependent on the hash
+   algorithm used. The data field contains the keyed hash calculated
+   over the entire NHRP payload. The authentication data field is zeroed
+   out before the hash is calculated.
+
+5.3.4.2 SPI and Security Parameters Negotiation
+
+   SPI's can be negotiated either manually or using an Internet Key
+   Management protocol. Manual keying MUST be supported. The following
+   parameters are associated with the tuple <SPI, src>- lifetime,
+   Algorithm, Key. Lifetime indicates the duration in seconds for which
+   the key is valid. In case of manual keying, this duration can be
+   infinite. Also, in order to better support manual keying, there may
+   be multiple tuples active at the same time (Dst being the same).
+
+   Algorithm specifies the hash algorithm agreed upon by the two
+   entities. HMAC-MD5-128 [16] is the default algorithm. Other
+   algorithms MAY be supported by defining new values. IANA will assign
+   the numbers to identify the algorithm being used as described in
+   Section 9.
+
+   Any Internet standard key management protocol MAY so be used to
+   negotiate the SPI and parameters.
+
+
+
+Luciani, et. al.            Standards Track                    [Page 42]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+5.3.4.3 Message Processing
+
+   At the time of adding the authentication extension header, src looks
+   up in a table to fetch the SPI and the security parameters based on
+   the outgoing interface address. If there are no entries in the table
+   and if there is support for key management, the src initiates the key
+   management protocol to fetch the necessary parameters. The src
+   constructs the Authentication Extension payload and calculates the
+   hash by zeroing authentication data field. The result replaces in the
+   zeroed authentication data field. The src address field in the
+   payload is the IP address assigned to the outgoing interface.
+
+   If key management is not supported and authentication is mandatory,
+   the packet is dropped and this information is logged.
+
+   On the receiving end, dst fetches the parameters based on the SPI and
+   the ip address in the authentication extension payload. The
+   authentication data field is extracted before zeroing out to
+   calculate the hash. It computes the hash on the entire payload and if
+   the hash does not match, then an "abnormal event" has occurred.
+
+5.3.4.4 Security Considerations
+
+   It is important that the keys chosen are strong as the security of
+   the entire system depends on the keys being chosen properly and the
+   correct implementation of the algorithms.
+
+   The security is performed on a hop by hop basis. The data received
+   can be trusted only so much as one trusts all the entities in the
+   path traversed. A chain of trust is established amongst NHRP entities
+   in the path of the NHRP Message . If the security in an NHRP entity
+   is compromised, then security in the entire NHRP domain is
+   compromised.
+
+   Data integrity covers the entire NHRP payload. This guarantees that
+   the message was not modified and the source is authenticated as well.
+   If authentication extension is not used or if the security is
+   compromised, then NHRP entities are liable to both spoofing attacks,
+   active attacks and passive attacks.
+
+   There is no mechanism to encrypt the messages. It is assumed that a
+   standard layer 3 confidentiality mechanism will be used to encrypt
+   and decrypt messages.  It is recommended to use an Internet standard
+   key management protocol to negotiate the keys between the neighbors.
+   Transmitting the keys in clear text, if other methods of negotiation
+   is used, compromises the security completely.
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 43]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   Any NHS is susceptible to Denial of Service (DOS) attacks that cause
+   it to become overloaded, preventing legitimate packets from being
+   acted upon properly. A rogue host can send request and registration
+   packets to the first hop NHS. If the authentication option is not
+   used, the registration packet is forwarded along the routed path
+   requiring processing along each NHS. If the authentication option is
+   used, then only the first hop NHS is susceptible to DOS attacks
+   (i.e., unauthenticated packets will be dropped rather than forwarded
+   on). If security of any host is compromised (i.e., the keys it is
+   using to communicate with an NHS become known), then a rogue host can
+   send NHRP packets to the first hop NHS of the host whose keys were
+   compromised, which will then forward them along the routed path as in
+   the case of unauthenticated packets.  However, this attack requires
+   that the rogue host to have the same first hop NHS as that of the
+   compromised host. Finally, it should be noted that denial of service
+   attacks that cause routers on the routed path to expend resources
+   processing NHRP packets are also susceptable to attacks that flood
+   packets at the same destination as contained in an NHRP packet's
+   Destination Protocol Address field.
+
+5.3.5  NHRP Vendor-Private Extension
+
+    Compulsory = 0
+    Type = 8
+    Length = variable
+
+   The NHRP Vendor-Private Extension is carried in NHRP packets to
+   convey vendor-private information 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 Vendor ID in the payload are
+     vendor-dependent data.
+
+   This extension may be added to any "request" or "reply" packet and it
+   is the only extension that may be included multiple times.  If the
+   receiver does not handle this extension, or does not match the Vendor
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 44]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   ID in the extension then the extension may be completely ignored by
+   the receiver.  If a Vendor Private Extension is included in a
+   "request" then it must be copied to the corresponding "reply".
+
+6. Protocol Operation
+
+   In this section, we discuss certain operational considerations of
+   NHRP.
+
+6.1 Router-to-Router Operation
+
+   In practice, the initiating and responding stations may be either
+   hosts or routers.  However, there is a possibility under certain
+   conditions that a stable routing loop may occur if NHRP is used
+   between two routers.  In particular, attempting to establish an NHRP
+   path across a boundary where information used in route selection is
+   lost may result in a routing loop.  Such situations include the loss
+   of 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 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 to resolve the egress point when the destination
+   lies outside of the NBMA subnetwork, since such mechanisms will be
+   more tightly coupled to the state of the routing system and will
+   probably be less likely to 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 NHRP Resolution Replies
+     that they are actively using.  They also must cache "incomplete"
+     entries, i.e., those for which a NHRP Resolution Request has been
+     sent but those for which an NHRP Resolution Reply has not been
+     received.  This is necessary in order to preserve the Request ID
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 45]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+     for retries, and provides the state necessary to avoid triggering
+     NHRP 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 packet.
+
+     When a station has a co-resident NHC and NHS, the co-resident NHS
+     may reply to NHRP Resolution Requests from the co-resident NHC with
+     information which the station cached as a result of the co-resident
+     NHC making its own NHRP Resolution Requests as long as the co-
+     resident NHS follows the rules for Transit NHSs as seen below.
+
+   Serving NHSs
+
+     The NHS serving the destination (the one which responds
+     authoritatively to NHRP Resolution Requests) SHOULD cache protocol
+     address information from all NHRP Resolution Requests to which it
+     has responded if the information in the NHRP Resolution Reply has
+     the possibility of changing during its lifetime (so that an NHRP
+     Purge Request packet can be issued). The internetworking to NBMA
+     binding information provided by the source station in the NHRP
+     Resolution Request may also be cached if and only if the "S" bit is
+     set, the NHRP Resolution Request has included a CIE with the
+     Holding Time field set greater than zero (this is the valid Holding
+     Time for the source binding), and only for non-authoritative use
+     for a period not to exceed the Holding Time.
+
+   Transit NHSs
+
+     A Transit NHS (lying along the NHRP path between the source station
+     and the responding NHS) may cache source binding information
+     contained in NHRP Resolution Request packets that it forwards if
+     and only if the "S" bit is set, the NHRP Resolution Request has
+     included a CIE with the Holding Time field set greater than zero
+     (this is the valid Holding Time for the source binding), and only
+     for non-authoritative use for a period not to exceed the Holding
+     Time.
+
+     A Transit NHS may cache destination information contained in NHRP
+     Resolution Reply CIE if only if the D bit is set and then only for
+     non-authoritative use for a period not to exceed the Holding Time
+     value contained in the CIE.  A Transit NHS MUST NOT cache source
+     binding information contained in an NHRP Resolution Reply.
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 46]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+     Further, a transit NHS MUST discard any cached information when the
+     prescribed time has expired.  It may return cached information in
+     response to non-authoritative NHRP Resolution Requests only.
+
+6.2.2 Dynamics of Cached Information
+
+   NBMA-Connected Destinations
+
+     NHRP's most basic function is that of simple NBMA address
+     resolution of stations directly attached to the NBMA subnetwork.
+     These mappings are typically very static, and appropriately chosen
+     holding times will minimize problems in the event that the NBMA
+     address of a station must be changed. Stale information will cause
+     a loss of connectivity, which may be used to trigger an
+     authoritative NHRP Resolution Request and bypass the old data.  In
+     the worst case, connectivity will fail until the cache entry times
+     out.
+
+     This applies equally to information marked in NHRP Resolution
+     Replies as being "stable" (via the "D" bit).
+
+   Destinations Off of the NBMA Subnetwork
+
+     If the source of an NHRP Resolution Request is a host and the
+     destination is not directly attached to the NBMA subnetwork, and
+     the route to that destination is not considered to be "stable," the
+     destination mapping may be very dynamic (except in the case of a
+     subnetwork where each destination is only singly homed to the NBMA
+     subnetwork).  As such the cached information may very likely become
+     stale.  The consequence of stale information in this 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 taken when using the Prefix
+   Length field of a CIE, in particular with regard 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 of a set of destinations, but
+   suboptimal routing (e.g., extra internetwork layer hops through the
+   NBMA) can result.  To avoid this situation an NHS that wants to send
+   the Prefix Length MUST obey the following rule:
+
+     The NHS examines the Network Layer Reachability Information (NLRI)
+     associated with the route that the NHS would use to forward towards
+     the destination (as specified by the Destination internetwork layer
+
+
+
+Luciani, et. al.            Standards Track                    [Page 47]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+     address in the NHRP Resolution Request), and extracts from this
+     NLRI the shortest address prefix such that: (a) the Destination
+     internetwork layer address (from the NHRP Resolution Request) is
+     covered by the prefix, (b) the NHS does not have any routes with
+     NLRI which form a subset of what is covered by the 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 avoid NHRP stations choosing suboptimal transit paths when
+   overlapping prefixes are available.  This document specifies the use
+   of the prefix length only when all the destinations covered by the
+   prefix are "stable". That is, either:
+
+     (a) All destinations covered by the prefix are on the NBMA network,
+         or
+     (b) All destinations covered by the prefix are directly attached to
+         the NHRP responding station.
+
+   Use of the Prefix Length field of the CIE in other circumstances is
+   outside the scope of this document.
+
+6.4 Domino Effect
+
+   One could easily imagine a situation where a router, acting as an
+   ingress station to the NBMA subnetwork, receives a data packet, such
+   that this packet triggers an NHRP Resolution Request.  If the router
+   forwards this data packet without waiting for an NHRP transit path to
+   be established, then when the next router along the path receives the
+   packet, the next router may do exactly the same - originate its own
+   NHRP Resolution Request (as well as forward the packet).  In fact
+   such a data packet may trigger NHRP Resolution 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 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 NHRP
+   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 Resolution Requests.  Such a router avoids the NHRP
+   domino effect through administrative means.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 48]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+7. NHRP over Legacy BMA Networks
+
+   There would appear to be no significant impediment to running NHRP
+   over legacy broadcast subnetworks.  There may be issues around
+   running NHRP across multiple subnetworks. Running NHRP on broadcast
+   media has some interesting possibilities; especially 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. Discussion
+
+   The result of an NHRP Resolution Request depends on how routing is
+   configured among the NHSs of an NBMA subnetwork.  If the destination
+   station is directly connected to the NBMA subnetwork and the routed
+   path to it lies entirely within the NBMA subnetwork, the NHRP
+   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.
+
+9. IANA Considerations
+
+   IANA will take advice from the Area Director appointed designated
+   subject matter expert, in order to assign numbers from the various
+   number spaces described herein.  In the event that the Area Director
+   appointed designated subject matter expert is unavailable, the
+   relevant IESG Area Director will appoint another expert.  Any and all
+   requests for value assignment within a given number space will be
+   accepted when the usage of the value assignment documented.  Possible
+   forms of documentantion include, but is not limited to, RFCs or the
+   product of another cooperative standards body (e.g., the MPOA and
+   LANE subworking group of the ATM Forum).
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 49]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+References
+
+   [1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol
+   (NARP)", RFC 1735, December 1994.
+
+   [2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826,
+   November 1982.
+
+   [3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC
+   2225, April 1998.
+
+   [4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams
+   over the SMDS service", RFC 1209, March 1991.
+
+   [5] Protocol Identification in the Network Layer, ISO/IEC TR
+   9577:1990.
+
+   [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+   October 1994.
+
+   [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
+   Layer 5", RFC 1483, July 1993.
+
+   [8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
+   Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August
+   1992.
+
+   [9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
+   over Frame Relay", RFC 1490, July 1993.
+
+   [10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision
+   in Switched Data Link Subnetworks", RFC 1937, May 1996.
+
+   [11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
+   Networks", RFC 2022, November 1996.
+
+   [12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache
+   Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
+
+   [13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork",
+   Work In Progress.
+
+   [14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP
+   Transition", Work In Progress.
+
+   [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+   Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 50]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+   [16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing
+   for Message Authentication", RFC 2104, February 1997.
+
+Acknowledgments
+
+   We would like to thank (in no particular order) Thomas Narten of IBM
+   for his comments in the role of Internet AD, Juha Heinenan of Telecom
+   Finland and Ramesh Govidan of ISI for their work on NBMA ARP and the
+   original NHRP draft, which served as the basis for this work.
+   Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of
+   ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
+   Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
+   and Grenville Armitage of Bellcore should also be acknowledged for
+   comments and suggestions that improved this work substantially.  We
+   would also like to thank the members of the ION working group of the
+   IETF, whose review and discussion of this document have been
+   invaluable.
+
+Authors' Addresses
+
+   James V. Luciani                    Dave Katz
+   Bay Networks                        cisco Systems
+   3 Federal Street                    170 W. Tasman Dr.
+   Mail Stop: BL3-03                   San Jose, CA 95134 USA
+   Billerica, MA 01821                 Phone:  +1 408 526 8284
+   Phone:  +1 978 916 4734             EMail:  dkatz@cisco.com
+   EMail:  luciani@baynetworks.com
+
+   David Piscitello                    Bruce Cole
+   Core Competence                     Juniper Networks
+   1620 Tuckerstown Road               3260 Jay St.
+   Dresher, PA 19025 USA               Santa Clara, CA 95054
+   Phone:  +1 215 830 0692             Phone:  +1 408 327 1900
+   EMail: dave@corecom.com             EMail:  bcole@jnx.com
+
+   Naganand Doraswamy
+   Bay Networks, Inc.
+   3 Federal Street
+   Mail Stop: Bl3-03
+   Billerica, MA 01801
+   Phone:  +1 978 916 1323
+   EMail: naganand@baynetworks.com
+
+
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 51]
+
+RFC 2332                       NBMA NHRP                      April 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Luciani, et. al.            Standards Track                    [Page 52]
+